脱离 WordPress 之后，SEO 那摊活到底谁来干
离开 WordPress 后，SEO 并没有消失；变化的是技术卫生、上线检查和长期责任由谁接住。
AI × WordPress 系列 · 第 5/8 篇
离开 WordPress 后，SEO 并没有消失；变化的是技术卫生、上线检查和长期责任由谁接住。查看系列目录
上一篇《AI 时代做独立站，你可能根本不需要 WordPress》讨论了新站的另一条路。接下来最现实的问题是：
道理我懂了，可离开 WordPress，Yoast 那些插件也没了。SEO 那一摊子活，到底谁来干？
这个担心很真实。做惯了 SEO 的人，多少都有一种肌肉记忆：一说 SEO，就想到先装插件。
但 Yoast 从来没有替你做过真正的 SEO。它做的是“技术卫生”。真正影响排名的那些活，一直是你在干，跟用不用 WordPress 没多大关系。
把这件事想明白，“谁来干”就没那么难回答了。
一、插件这些年到底替你干了什么
把 Yoast、Rank Math 这类插件的功能摊开看，无非是给页面生成 meta 标题和描述、处理 canonical 标签、维护 sitemap、输出结构化数据、管理 robots 规则。
这些工作有一个共同点：规则很明确。meta 怎么拼，canonical 指向哪里，sitemap 什么时候更新，规则一旦定好，插件就能自动执行。
但插件不会替你判断关键词，也不会规划内容，更不会直接把排名做上去。它解决的是另一件事：让搜索引擎顺利抓取、理解和索引页面。我把它叫作技术卫生。做好了不一定马上带来增长，做错了却可能直接影响收录。
真正让排名往上走的，是看 GSC 里的 query、判断搜索意图、决定写什么、改什么、怎么做内链，然后等一轮收录，再回头看数据。这套循环，插件从来没替你跑过。 老读者应该熟悉，我之前写 GSC query 的文章讲的就是这件事。
所以，所谓“脱离 WP 之后 SEO 谁来干”，其实包含三摊活：技术卫生、需要长期跟进的流程，以及真正的 SEO。
真正的 SEO 还是你做。技术卫生大部分可以交给 AI。最容易漏掉的，是那些要跨几周甚至几个月盯着看的流程。
二、技术卫生可以交给 AI，但有五件事得由你决定
脱离 WordPress 后，技术卫生归前端代码管。页面渲染时输出 meta 和 canonical，构建时生成 sitemap，再从内容数据里生成结构化数据。
听起来像是要自己写一堆代码，很麻烦。不过这两年情况变了：规则明确、模式固定的代码，正是 AI 擅长写的。让 Codex 给 Next.js 或 Astro 站配置 meta 和自动更新的 sitemap，通常很快就能做出一个可用版本。
问题在于，“能用”和“写对”不是一回事。
这里面大部分是执行工作，AI 可以接走；但下面五件事本质上是业务决策。AI 会给你一个答案，却不知道哪个答案适合你的站。更麻烦的是，这些地方出错时往往不会立刻报警，要过一两个月才会在数据里露出来。
第一，canonical 难的不是标签，而是规则。 首页加一个 canonical 谁都会，真正要想清楚的是分页、参数 URL 和筛选页分别指向哪里。规则错了，页面可能被判定为重复内容，信号也会被拆散。
第二，hreflang。 外贸站几乎绕不开它。AI 生成的多语言标注经常有互指不完整、语言代码错误、页面对应关系不一致等问题。页面表面上完全正常，Google 却可能直接忽略标注，语言和地区版本的匹配就这样悄悄失效。
第三，结构化数据用什么类型。 该用 Article 还是 Product，FAQ 应该挂在哪一层，这是内容判断，不是代码判断。AI 完全可能生成一段语法正确、校验工具全绿，但类型选错、Google 不采用的 schema。
第四，robots 要跟环境对应。 测试站应该挡爬虫，正式站应该放开。部署时一旦弄反，“正式站带着 noindex 上线”这种事故就会发生。上过线的人大多见过。
第五，渲染方式。 靠搜索流量吃饭的内容页，优先考虑静态生成或服务端渲染。纯客户端渲染并非一定不能收录，但你得确认 Googlebot 渲染后能看到完整的正文、链接和元信息。验收分两步：先看页面源代码里有没有正文，再用 Search Console 的网址检查工具确认 Google 实际看到了什么。
这五类问题，很多出现在让 AI 从零手写标签的时候。今年初有人整理过一份“LLM 和 vibe coding 常犯的 SEO 错误”清单，canonical 缺失、hreflang 乱写都排在前面。
好在成熟方案已经有了。Next.js 的 Metadata API、Astro 的 SEO 组件包，已经把很多规则封装成现成组件，连“noindex 时是否省略 canonical”这类细节也考虑到了。与其让 AI 手写所有标签，再由你逐个挑错，不如在需求里直接要求它使用成熟组件。
这样能消掉一大批实现错误。最后真正留给你的，是组件无法替你做的决定：canonical 按什么规则，schema 选什么类型，多语言站点怎么组织。
简单说，AI 负责用成熟组件把代码写出来，你负责做决定和验收。
也别把它理解成“配置一次，以后就不用管”。每次上线、改版或增加页面类型，都要重新检查。模板一改，canonical、schema 和 robots 都可能跟着出问题。
三、AI 不会主动替你盯几周后的结果
这一点是我自己踩过坑之后才看明白的，也是现在很多“AI 做 SEO”的讨论里很少提到的部分。
用 AI 做一段时间的网站，你会发现：on-page 和 technical 这类一次性任务，它做得很好；但需要跨越时间、持续跟进的事情，它经常漏掉。
说两个我自己遇到过的例子。
一个是版本迭代和 301。代码站改起来太顺手，上线几个版本很正常，每次改版都可能更换一批 URL。可没有人会自动提醒你：关键页面的 301 做了吗？
老 URL 可能已经被收录，有外链，也正在带来流量。改版后直接变成 404，流量和索引的连续性都会受影响。这种错误不会当场报警。等你从 GSC 看出来，通常已经漏了几周。
另一个是新站索引。新站上线后收录迟迟不涨，在脱离 WP 的新技术栈里并不少见。
我的习惯是，上线后先用 Screaming Frog 爬一遍整站。 它会从爬虫的视角检查 URL、状态码、canonical、meta、内链和渲染结果。上一节提到的五个决策点，大部分都能在这一遍检查里暴露出来。
AI 写出的代码看起来没问题，不代表爬虫看到的也没问题。Screaming Frog 做的，就是换成爬虫的眼睛再验收一次。
确认没有硬伤后，再进入持续观察：看 GSC 的“页面索引”报告、Sitemap 状态和网址检查结果。难点不在检查一次，而在于上线后连续看几周，再根据变化决定下一步。AI 不会在第三周主动跑来提醒你：“索引好像不对，查一下吧。”
我一开始以为这是因为 AI 记不住，后来发现不完全是。现在的 AI 能读代码仓库，也能翻历史记录。它真正缺的是三样东西：历史基线、时间触发和责任闭环。
没有历史基线，它不知道什么发生了变化；没有时间触发，它不会在上线一周或三周后回来复查；没有责任闭环，即使查到异常，它也不会自动决定接下来由谁排查、什么时候复验。
AI 可以做检查，但持续性得靠流程。
所以，在脱离 WordPress 之前，先把这些事情写进运维清单：上线后用 Screaming Frog 做全站体检；每次改版检查 301 映射；每周查看页面索引报告；提前写好收录异常的排查顺序。同时保留旧 URL 清单和版本记录，让 AI 每次检查时都有基线可比。
清单不需要很复杂，但必须独立于 AI 存在，并且真的有人执行。对 SEO 从业者来说，这恰恰是换到新技术栈后最不能丢的一部分，也最容易淹没在“AI 什么都能做”的兴奋里。
四、真正的 SEO 从来就没在插件手里
再回想一下，你平时做 SEO，时间到底花在了哪里？
盯 GSC 的 query，判断哪个词有机会；决定单独写一篇 blog，还是在现有页面补 FAQ；给服务页增加内链；按两周一轮的节奏改内容，再用数据判断这次到底改对了没有。
这些事，在 WordPress 里要做，换了技术栈照样要做。变的只是发布内容的后台，判断和迭代的循环没有变。
如果新站的内容结构更干净，接口也更适合 AI，这套循环甚至能跑得更快。AI 可以根据 GSC query 批量整理机会、诊断页面、生成修改初稿。但写什么、先改哪一页、把资源投到哪里，最后还是由你决定。这套方法在老 WordPress 站的 AI 提效文章里讲过，放到新栈上一样成立。
所以，离开 WordPress 并不等于失去 SEO 能力。技术卫生可以让 AI 接走大半，你负责验收和维护流程。真正的 SEO，也就是数据判断和内容迭代，本来就在你手上。
五、有一种情况，我劝你先别换
说了这么多“能接住”，最后还是得泼一盆冷水，因为这决定了你现在该不该换技术栈。
如果你连 GSC 数据驱动的内容循环都还没跑起来，比如主服务页没出词，出了词没人看，看了也不知道怎么改，那么问题并不在 WordPress。换成什么技术栈都解决不了。
这时候更实际的做法，是留在现有网站上，先把内容循环跑通。《老 WordPress 站想用 AI 提效，先分清哪些能碰、哪些碰都别碰》详细写了老站的做法。先把风险低、收益明确的部分用起来。等循环真正转起来，你对数据和内容也有了手感，再决定要不要换载体。到那时，这个选择反而简单。
最后
脱离 WordPress 后，SEO 的分工并不复杂。
技术卫生交给 AI 写进代码，你把住五个决策点，并在每次上线时重新验收。301、索引和 GSC 观察这类跨时间的工作，要提前写进运维清单，保留可比较的历史基线。至于真正的 SEO，仍然在你手上，因为它从来就没被插件接走过。
插件给人的安全感，往往比它实际承担的工作更大。看清这一点，选什么技术栈就自由多了。
对还没跑通 SEO 循环的团队来说，直接换栈不是第一优先级。先在现有 WordPress 站上把 AI 提效流程跑起来，通常更稳。
如果你需要进一步梳理 SEO 责任，可以查看 Grace Qu 的海外增长范围与预约方式。预约时带上网站地址、GSC 现状、准备采用的技术栈和预计上线时间。