开发者的浏览器能看到正文，并不代表每次抓取都能得到同样的内容。页面可能依赖登录态、接口返回、脚本下载或用户点击。排查 JavaScript SEO 时，需要把初始响应、渲染后的页面，以及搜索平台实际看到的结果分开检查。
先确认正文在哪一步出现
选择一个正常文章 URL，查看初始 HTML 是否已经包含主标题、主要正文和相关链接，再与浏览器执行脚本后的 DOM 比较。如果初始内容只有空容器，记录补齐正文所需的脚本和接口。Google 可以渲染许多 JavaScript 页面，但其他抓取器能力不同，服务端渲染或预渲染仍值得根据业务需要评估。
这不意味着有 JavaScript 就一定影响收录。传统 WordPress 文章也可能用脚本加载评论、图片和目录；要区分主要内容与辅助交互，避免为了改造而改造。
用三类地址做检查
| 地址 | 预期结果 | 常见问题 |
|---|---|---|
| 真实存在的文章 | 正文完整且无需登录 | 接口依赖 Cookie 或被访问控制拒绝 |
| 站内导航目标 | 直接打开也能显示内容 | 只在单页应用内部跳转时正常 |
| 不存在的文章 | 明确错误状态 | 所有地址都返回200和空壳 |
链接、状态码和元数据分别核对
导航应提供可提取的真实链接目标，不能完全依赖没有 href 的点击事件。服务端要能处理文章深层路径的直接访问；如果正文已删除，不应只在前端显示“没有找到”而持续把它当成功页面返回。可结合软404排查检查错误模板。
查看初始与渲染后页面中的 title、canonical 和 robots 是否互相冲突。尤其不要在初始响应中写入 noindex，再指望脚本移除它后一定被索引。多个组件分别生成 canonical 时，也要防止最终出现多个相互矛盾的值。
不要只在自己的登录状态下验收
- 以普通公开访客打开地址，检查接口和资源是否需要额外身份信息。
- 查看控制台和网络错误，定位脚本失败、跨域问题或资源误拦。
- 用搜索平台提供的 URL 检查功能核对渲染后的主要内容。
- 检查页内链接能否直接打开，而非只能从首页一路点击进入。
- 用不存在的地址确认错误页没有伪装成正常正文。
若失败来自防护挑战，先用WAF 抓取误拦定位方法检查规则，不要对所有带爬虫名称的请求无条件放行。
修复后保留一组回归样本
选正常文章、分页、旧地址跳转和不存在页面作为固定样本，每次前端发布后复核。记录看到的正文版本和错误类型，避免只保存一个“成功”截图。渲染恢复解决的是内容可见性，是否进入索引仍由搜索引擎结合页面质量等因素决定。
参考资料
作者：lgd。资料核对：2026-10-08。本文采用 AI 辅助整理；示例用于说明方法，不代表本站实测数据。
