老 WordPress 站想用 AI 提效，先分清哪些能碰、哪些碰都别碰
对已经有收录、排名和运营习惯的老站，先分清内容层和结构层，再决定 AI 能接到哪里。
AI × WordPress 系列 · 第 6/8 篇
对已经有收录、排名和运营习惯的老站，先分清内容层和结构层，再决定 AI 能接到哪里。查看系列目录
先说个我们接触到的同行案例。
他做独立站起步早，用 WordPress 加 builder 搭的站，跑了几年，攒下了一些权重。AI 起来之后，他想把原来靠运营的活儿尽量交给 AI，写文章、做 SEO，连页面也开始全用 AI 来写。方向没错，但他舍不得那个有权重的老站，又想把 AI 生成的页面塞回去，最后只能用 Bricks 一层层往里嵌。结果站越来越重，打开越来越慢，流畅性肉眼可见地往下掉。
后来复盘，他其实踩了一个很典型的坑：把"用 AI 提效"直接理解成了"让 AI 去改我的站"。
可提效的杠杆不止一块。有安全的一块，也有危险的一块。他一上来就去碰了最危险的那块——动站的结构，还把最安全、最快见效的那一块搁在一边没吃。有权重的站尤其得把这两块分清楚，不然效没提成，先把老本搭进去了。
这篇就讲清楚：哪些能放开让 AI 去干，哪些碰都别碰。
一、先分清：你想让 AI 干的活，是"内容"还是"结构"
判断其实很简单，就看一件事：这个活儿，碰不碰你的主题、builder 和模板文件。
不碰的，是内容层的活——写文章、扩内容、做 SEO 诊断、解读数据。这些产出最后都是走 WordPress 后台正常发布的文章和内容，站的地基一点没动，风险很低。
碰的，是结构层的活——建页面、改主题、往 builder 里嵌代码。这些一旦出错，影响的可能不是一个页面，而是一组页面甚至整个站。对有权重的站来说，这是高风险区。
大部分人的顺序是反的：一上来就惦记着让 AI 建页面、改站（结构层），却没意识到内容层那块又安全又快的红利根本没吃。有权重的站，正确的顺序应该倒过来——先把内容层吃满，结构层能不碰就不碰，要碰也得踩着边界走。
下面分开说。
二、先把内容层吃满，这是最安全、也最快见效的一块
内容层别只理解成"让 AI 帮我写文章"。真正值钱的，是把 AI 接进你原本那套靠 GSC 数据驱动的打法里，让"数据 → 选题 → 写 → 审 → 迭代"这个循环转起来，而全程不碰站的一根结构。
起点是 GSC 的数据，不是拍脑袋让 AI 写。
你的主服务页上线跑一段时间，谷歌会给你跑出一批 query。先判断这些词是不是这个页面的核心词：如果跑出来的就是页面原本要打的词，说明页面没跑偏，继续观察就行；如果跑出来的是某个模块的词，或者是一条明显更细的长尾，那反而是机会——它在告诉你，谷歌看到了这块内容的需求。
这里就是 AI 该上场的地方。
那些跑出来的长尾，尤其是完整的问句、一看就是用户在搜索框里打出来的（现在很多是 AI 用户提问带出来的），正是让 AI 去写专门 blog、或者补进 FAQ 模块的好素材。一种做法是让 AI 顺着这些词批量生成内容初稿，反过来补主服务页的话题权威，同时在 blog 里做一条转向服务页的内链。这样出来的每一篇，都不是 AI 拍脑袋写的，选题是数据给的，方向是你定的。
AI 在内容层，主要可以用来做三件事。
一是顺着 GSC 跑出的词写和扩内容，前面说的就是这件。二是做内容审核和 SEO 诊断——让 AI 对着你的页面，从技术和内容两头挑问题，而且它能形成逻辑闭环，比如你调了第三个模块，它会提醒你第六个模块也得跟着改，这个在实际用起来挺省心的。三是帮你读数据，GSC 的效果报告拉出来做 compare，看清这段时间到底掉的是什么、涨的是什么，再结合像 Clarity 这类工具看用户在页面上的真实访问路径，把"哪里出了问题"先定位出来，再针对性去改。
这一整套下来，你会发现一个关键点：它的产出，全是走 WordPress 后台正常发布的文章和内容，不碰主题、不碰 builder、不动一行模板。 所以对有权重的站，它几乎是零结构风险的。这才是你该第一时间吃满的红利，而不是急着让 AI 去动站。
最后提醒一句：内容层的迭代别太频繁。 谷歌收录和重新评估是有周期的，你改完得给它时间。除非发现内容严重跑偏，否则不要一直改来改去；需要跨时间观察的 SEO 责任，可以配合阅读《脱离 WordPress 之后，SEO 那摊活到底谁来干》。
三、再说结构层：想让 AI 建页面，先看你的站是什么搭的
内容层吃满之后，如果你确实还要让 AI 去建页面、动结构，那先停一下，看清楚你的站是用什么搭的——这一步直接决定 AI 能不能接、怎么接。
如果你的站是用主题或者 Gutenberg 做的，相对好办，可以走比较可控的路子，比如写个 skill 让 AI 把最终内容直接写进 WordPress 的文章表，或者把常用模块封成区块。如果是 Elementor，现在已经有 MCP 这类工具，能让 AI 直接操作它的原生能力。
真正麻烦的是 Brizy、Bricks 这类 builder，目前对 AI 并不友好，硬把 AI 生成的代码往里塞，大概率就是开头那个同行的下场。这种情况有个更现实的办法，有同行给过一手经验：
我这站是前两年用 builder 做的，用了 codex 之后让 AI 先读源码生成就不会出问题了。
也就是先让 AI 读懂你现有 builder 输出的结构，再顺着那个结构去生成，而不是硬塞一套它自己的代码。实在不行，就给它一个参考页面，让它照着做一个类似的，可执行性反而更高。
如果你用的是 Brizy，可以再进一步，做一个"翻译层"。
Brizy 麻烦在它存的不是原生 HTML，而是一套序列化数据，block 的 HTML 代码被封装在里面，AI 没法直接读写。但这个问题有个挺干净的解法：让 Codex 帮你做一个小插件，专门当中间层做双向转换。
进的方向，AI 只管生成标准 HTML，插件负责把它转换成 Brizy 的封装格式写进去；出的方向，AI 要读现有页面时，不用靠截图去视觉分析，插件直接把 block 里解析好的 HTML 递给它。这样一来，AI 从头到尾读的、写的都是它最熟的 HTML，Brizy 那套私有格式的脏活，全部固化在插件里，做一次，以后一直用。 不做这层其实也行——聪明点的 AI 每次会自己写临时脚本来转换，但每次都要多烧好几倍的 token，等于把一次性成本变成了每次都付的税。
有一点必须当成底线来做：这个插件要直接操作数据库，绕开了 WordPress 正常的写入校验，所以备份不是可选项——每次写入前自动备份、随时能回滚，这个方案才敢用在有权重的站上。
这块的具体做法在《AI 生成页面之后，怎么落到 WordPress 里》讲得更细，这里不再展开。
四、一条红线：有权重的站，这几件事碰都别碰
前面说了能碰的，这里说几件我认为有权重的站碰都别碰的。
别让 AI 直接改正式站的主题，尤其是 parent theme。 主题文件一改，可能牵动一整组页面，而且主题一更新，你手改的东西还会被覆盖。真要动，也得放在 child theme、在测试站上、备份和回滚都备好了再动，绝不在正式站上直接让 AI 改。
别为了尝鲜某个新东西，就去迁站、换架构。 这段时间新东西很多，看到别人用 Astro、看到 Cloudflare 出的那些新 CMS，容易心动。但那是"脱离 WordPress"，是新站或者没有权重包袱的人该考虑的路。你一个有权重的老站去干这个，本质是迁站，是拿排名去赌，风险远大过那点新鲜感。新站与老站的边界，可以对照什么情况下不必使用 WordPress。
别把重代码的页面硬嵌进 builder。 这就是开头那个翻车案例的根子。builder 本身嵌套层级就深，你再往里塞一堆代码，页面只会越来越重，加载变慢、Core Web Vitals 变差，SEO 反而先受了害。提效的初衷是好的，落地方式错了，结果是南辕北辙。
最后
其实提效和保权重这两件事，根本不冲突，关键就在分层：内容层放开吃，结构层踩着边界走，红线的地方绝不碰。
如果你也有一个跑了几年、舍不得动的老站，可以从内容层开始——先把 AI 接进 GSC 数据驱动的循环，再根据主题、builder、备份和回滚条件决定结构层能不能动。
继续阅读
- 上一篇：脱离 WordPress 之后，SEO 那摊活到底谁来干
- 下一篇：AI 维护是个黑盒？几百个产品的多语言站怎么建
- 老站是否要重做：同行开始用 AI 快速产出内容，十年 WordPress 老站该重做吗？
- 查看 AI × WordPress 完整系列
问题同时跨技术和增长？
如果既要判断 WordPress 主题、builder、权限和回滚，又要处理 GSC、内容与现有流量，先查看两位专家的业务范围：技术选型、系统架构和 AI 接入由 Django Wong 承接；Google SEO、B2B 内容策略和 AI 搜索可见性由 Grace Qu 承接。跨两个方向时，在预约说明里写清当前最主要的卡点即可。