Headless WordPress 不是不能用，但它把风险换了个位置：WordPress 变成纯数据源，页面由另一个应用渲染，于是"内容在不在最终 HTML 里"这件事的责任从 CMS 转移到了你手上。官方在这件事上的口径是明确的——服务端渲染或预渲染仍然是值得做的做法，理由是对用户和对爬虫都更快，而且并非所有爬虫都能运行 JavaScript。所以真正的问题不是"能不能抓"，而是"你的渲染层有没有把内容送进 HTML"。
数据从哪来，页面由谁生成
WordPress 官方 REST API 手册对这套接口的描述是：它为应用提供与站点交互的接口，通过收发 JSON 对象来交换数据，并且是区块编辑器的基础。手册还写明了两条对 Headless 特别关键的属性——内容在站点上公开的，一般可以通过 REST API 公开访问；而私密内容、密码保护内容、内部用户、自定义文章类型及其元数据，只有在通过身份验证、或者你明确开放时才可获取。
这两句连起来读，Headless 的一个常见误解就解决了：REST API 暴露的是内容数据，主题模板、页头页尾、面包屑这类由主题输出的东西不在 JSON 里。换了渲染层之后，原本靠主题模板输出的那些部分，得由新的一层补上，否则丢的是结构而不是内容。
官方提醒的三个具体故障点
Google 关于修复 JavaScript 抓取问题的文档里有三条与 Headless 高度相关的说明。
- 状态不保留。文档写明 Web 渲染服务每次加载 URL 的方式与普通浏览器相同、会跟进服务器端和客户端的重定向，但不会跨页面加载保留状态：本地存储和会话存储会被清空，HTTP Cookie 同样会被清空。任何"先存一个标记再加载内容"的设计在抓取侧就是空的。
- 连接方式受限。文档写明 Googlebot 用 HTTP 请求获取内容，不支持其他类型的连接方式，例如 WebSocket 或 WebRTC。需要这类连接的交互必须有 HTTP 回退。
- 权限请求会被拒绝。文档写明期待爬虫拒绝用户权限请求，因为需要用户权限的特性对爬虫没有意义。摄像头这类能力不能做成获取内容的前置条件。
再加上一条来自JavaScript 搜索优化说明的判定标准：内容不出现在渲染后的 HTML 里，Google 就无法索引它。Headless 站最常见的失败就是这一条——浏览器里看一切正常，渲染后的 HTML 却只有外壳。
怎么做：输出前自查五项
- 正文落在服务端还是客户端。正文放在服务端渲染的初始 HTML 里最稳；只做局部交互的部分可留在客户端。
- 链接用标准元素。官方对链接的要求是 Google 一般只能抓取带
href属性的<a>元素，靠脚本事件触发的写法无法被可靠解析；用 JavaScript 动态插入的链接可以，但必须是标准标记。 - 别用地址片段路由。官方文档写明，建议在单页应用里用 History API 实现不同视图之间的路由，不要用地址片段加载不同内容；同时也提到早期的 AJAX 抓取方案自 2015 年起已经废弃，不能依赖它。
- 规范地址只留一个，且优先在 HTML 里给。官方在 JavaScript 说明里写明，最好的方式是用 HTML 指定规范地址；如果确实要用 JavaScript，要保证设置的值与原始 HTML 里指定的一致，而且页面上只能有一个规范标签。
- 静态资源加内容指纹。官方提到 Googlebot 缓存激进、渲染服务可能忽略缓存头从而用到过期的 JavaScript 或 CSS，把内容指纹写进文件名可以避免这个问题。
例外：这套判断什么时候不成立
有几类情况不用按上面的清单逐项排查。站内容量很小、只有十几篇静态页面且本身就在服务端输出时，虽然是 Headless 架构，抓取侧风险和普通静态站没有区别。WordPress 不参与前台渲染的服务也没有讨论价值，因为页面输出路径没变。
另外要划清两条边界。其一，官方从未公布过"Headless 架构对收录或排名的影响幅度"，也没有公布渲染等待的时间上限，所以"Headless 对搜索更友好"或"一定掉收录"在文档里都读不出来。其二，WordPress 官方文档只描述 WordPress 自身怎么工作，它不对任何搜索排名或收录结果作承诺；上面所有关于抓取与索引的判断都来自 Google 文档，两者不能混写成"WordPress 官方说 Headless 有利于搜索"。
验证要分渲染层和数据层两路
验证分两层。渲染层用官方推荐的网址检查工具和结构化数据测试工具，看渲染后的 DOM 里有没有正文、有没有标准链接、地址变化后拿到的是不是对应内容。数据层核对接口：确认公开内容能取到、私密内容确实被拦住——后者关系到权限边界，和搜索无关但同样要查。为 SEO 关闭 WordPress REST API？先查编辑器和前台依赖讲的就是关闭前要核对哪些依赖；在 Headless 场景里这个顺序要反过来——先确认谁在用，再用它。
实操排期建议：先挑三类页面各两篇抽样，看源代码确认正文落点；把要改的页面列成清单，按"链接优先、正文其次"的顺序动手；改完当天复测渲染后 HTML，一周后再看抓取状态。资源缓存与前端文件层的处理，WordPress 速度优化：缓存、数据库与前端文件的按需优化指南有分层做法；为什么这套架构里的自定义内容类型值得优先排查，WordPress 为什么便于做 SEO：5 项优势及使用条件里讲过其中的取舍关系。