很多站点在浏览器里打开一切正常，但抓取到的 HTML 里几乎没有正文。问题往往不在服务器，而在于页面把关键内容交给了 JavaScript 在客户端拼装。做一次渲染自查不需要多高深的技术，只要愿意用最朴素的方式，看一遍原始响应。
先确认：蜘蛛看到的和你看到的是不是同一份东西
浏览器会执行脚本、加载样式、填充内容，你看到的是渲染之后的结果；而抓取拿到的第一手资料，是服务器返回的原始 HTML。如果正文、主要链接、标题层级都只在渲染之后才出现，那么后续的索引、内链传递和内容判断都会打折扣。
自查方法很朴素：
- 用命令行请求页面，把返回的 HTML 存成文件，直接在文本里搜索正文中的几个关键词。
- 在浏览器里禁用 JavaScript 再打开同一地址，看还能剩下多少内容。
- 查看源代码，确认导航与列表里有没有完整的 a 标签 href，而不是只有 onclick 或 data-href。
四类最常见的坑
一、链接不是链接
用 div 加点击事件来实现跳转，人点得动，抓取端读不到。列表页、导航、相关推荐里如果大量使用这种写法，等于把内链入口关掉了。可点击的元素应当有真实的 href，脚本只负责增强体验。
二、正文靠懒加载或交互才出现
折叠面板、标签切换、点击展开全文才显示的内容，如果默认不输出到 HTML，就等同于不存在。更稳的做法是把首屏核心内容直接服务端输出，交互只影响展示顺序。
三、元信息与结构化数据由脚本注入
标题、描述、canonical、结构化数据如果全靠脚本写入 head，容易因为执行失败或时机不对而丢失。这些关键信息建议在服务端就写进 HTML，脚本只做兜底。
四、无限滚动与加载更多
滚动自动加载的列表，抓取端很难完整遍历。保留可访问的分页地址，或者在列表里提供下一页的真实链接，让列表有终点可走。
一份可执行的自查清单
- 取一篇文章页、一个列表页、一个首页，分别保存原始 HTML。
- 检查原始 HTML 中是否包含正文主体、主标题和主要导航链接。
- 检查是否有可读的 title、description 与 canonical。
- 确认分页或加载更多背后存在真实 URL。
- 确认关键的 CSS 与 JS 没有被 robots 规则挡住，渲染所需资源能正常获取。
- 对比原始 HTML 与渲染后的文本差异，差异越大越值得优先处理。
改的时候按顺序来
优先解决内容有没有的问题，再解决好不好看的问题。顺序大致是：先让正文和链接出现在服务端返回的 HTML 里，再处理元信息，最后才考虑渲染性能与资源体积。
- 能用服务端渲染或预生成的部分，尽量前置。
- 必须靠脚本的部分，保证首次渲染不依赖用户点击。
- 避免把大段正文藏在需要授权或二次请求的接口后面。
改完怎么验证
- 用搜索平台提供的网址检查工具，对比原始 HTML 与渲染后 HTML。
- 观察抓取记录中该目录返回的内容体积是否回到合理水平。
- 过一段时间再看索引与展现的变化，不要指望当天见效。
渲染方案没有绝对优劣，稳定和可预期更重要。技术再新，如果抓取端每次拿到的内容都不一样，站点运营就很难做长期判断。
最后提醒一句：渲染自查不是一次性任务。前端框架升级、组件重写、加载策略调整，都可能让原本正常的页面重新变回空壳。把它放进改版流程里，比事后排查省事得多。