页面构建器对抓取的影响，几乎可以压缩成一句话：它决定了正文和链接是在服务器那一侧就出现在 HTML 里，还是要等 JavaScript 跑完才有。构建器本身不排名、不收录，官方文档里也从来没有"某构建器对搜索更友好"这种说法；但它输出的东西落在哪个阶段，会直接决定抓取阶段能拿到多少信息。判断一个页面，不需要知道它用的是哪款构建器，只要看两处。
抓取会卡在三个位置
把官方描述的现象按位置排一下，问题只有三处。
- 第一处是正文缺席。如果页面采用了应用外壳模型，初始 HTML 里没有实际内容，Google 必须先执行 JavaScript 才能看到真正显示的东西。官方对这件事给的条件很明确：内容不出现在渲染后的 HTML 里，就无法被索引。
- 第二处是链接缺席。Google 一般只能抓取带
href属性的<a>元素，靠脚本事件触发跳转的写法无法被可靠解析。用 JavaScript 动态插入的链接可以，前提是仍然用标准标记。 - 第三处是状态被清空。官方写明 Web 渲染服务不会跨页面加载保留状态：本地存储、会话存储会被清空，HTTP Cookie 也会被清空。很多构建器的动效、筛选记忆、模块显隐都建在这上面。
构建器常见的三种输出形态
不用去猜构建器的名字，对着页面分三档就行。
| 形态 | 查看源代码能看到什么 | 优先核对项 |
|---|---|---|
| 服务端输出 | 正文文字、各模块 HTML 都在 | 标题标签、规范化地址、模块顺序是否重复输出 |
| 混合输出 | 主体在，个别动效区块只剩空容器 | 空容器里有没有真实链接，导航是不是完整的标准链接 |
| 客户端输出 | 只有一个外壳，正文文字搜不到 | 先决定这一页要不要改成服务端输出，再谈其他 |
WordPress 侧的背景只需要知道一句：官方主题开发手册把主题分成区块主题和经典主题两类，前者主要由 HTML 加主题配置文件构成，后者主要用 PHP、JavaScript 和 CSS 拼出来。同一套构建器在不同主题下落到哪种形态并不固定，所以分类是描述输出方式，不是给工具排座次。
怎么做：逐项核对渲染后 HTML
- 挑三类代表页面各两篇：首页、一篇长文、一个列表页。用查看源代码记录正文和链接的落点。
- 按上一段的表归档，只保留需要动手的那一类，不要一次性改全站。
- 需要动的页面，先把导航和正文里的链接全部改成带
href的标准元素，别的先放着。 - 涉及正文的页面，改成服务端输出；只做动效和视觉的区块可以保留客户端渲染。
- 静态资源文件名加内容指纹。官方在两份文档里都提到 Googlebot 缓存激进、渲染服务可能忽略缓存头从而用到过期资源。
顺序上，链接优先于正文。理由很实际：链接的改动小、可批量验证，而且它同时影响站内用户点击路径，不只为爬虫服务。
例外：服务端渲染也不等于没问题
把正文搬回 HTML 只解决了一半。几种情况依然会漏：页面状态码不对时，非 200 响应的页面渲染可能被跳过，而单页应用常见的问题正是错误页也返回 200，容易形成软 404；页面里如果有需要用户授权才能拿到的内容，官方明确说期待爬虫拒绝这类授权请求，所以不能把权限弹窗设计成获取内容的前置条件；内容如果依赖 WebSocket 之类的连接，官方也写了 Googlebot 只用 HTTP 请求，不支持其他连接方式，需要准备 HTTP 回退。
另一条边界要单独讲：官方建议继续做服务端渲染或预渲染，理由是对用户和爬虫都更快、且并非所有爬虫都能运行 JavaScript。这句话是给"反正 Google 能跑 JS"这类想法留的余量，不是说纯客户端渲染一定不行。官方也从未公布过渲染等待的时间上限，所以"超过几秒就抓不到"的说法在文档里找不到依据。
怎么验证有效
验证工具是官方在修复 JavaScript 抓取问题的说明里直接给出的两样：结构化数据测试工具与网址检查工具，能看到加载的资源、控制台输出与异常、以及渲染后的 DOM。JavaScript 搜索优化那份文档还补了一句：用了 Web 组件时，渲染阶段会展开影子 DOM 和轻量 DOM，展开后的内容才是在渲染后 HTML 里可见的，所以核对要对着展开后的结果看，别对着页面截图看。
复测节奏建议这样排：改链接后当天复测一次，改正文的第二天再测一次，然后隔一周看一次网址检查工具里的抓取状态。中间不要频繁改缓存策略，否则分不清是改动生效还是缓存刚好刷新。缓存与动态页面怎么分工，WordPress 加速先选插件还是调服务器：缓存、CDN 与动态页面怎么分工里有更细的拆法；构建器之外那些常被一起装的工具怎么定位，WordPress SEO 与性能优化：10 款工具的用途与选型注意事项按"看什么指标"给过判断口径。