同一个页面，用浏览器打开，和用抓取工具拿到的东西，可能完全不是一回事。前者是脚本跑完之后的成品，后者往往只是服务端返回的那一份 HTML。理解这两者的差别，能解释不少“内容明明有、蜘蛛却没抓到”的情况。
抓取通常分两步：先拿 HTML，再排队渲染
搜索引擎的处理流程可以粗略拆成两段：第一段是抓取原始 HTML，解析其中的文字与链接；第二段是当页面必须依赖 JS 才能显示主要内容时，把它放进渲染队列，用类似浏览器的环境再跑一遍。两段之间可能有间隔，渲染资源也有限，并不是每个 URL 都会被立刻渲染。
这意味着，如果关键内容、列表项和链接只在渲染之后才出现，蜘蛛发现 URL 的时间会被拉长，有些页面会一直排在队列后面等。
容易被漏掉的三类内容
- 由 JS 写入的正文、价格或参数，首轮 HTML 里只是个空容器。
- 点击“加载更多”或滚动才出现的列表项，链接不在初始 HTML 中。
- 用脚本拼接出来的导航与分页，抓取时拿不到可跟随的 href。
这些做法在用户体验上未必有问题，但对 URL 发现和抓取路径来说，等于把入口藏在了第二步之后。
内链最好写在初始 HTML 里
链接是抓取路径的基础。用 a 标签加可解析的 href 输出的链接，从首轮抓取起就能被跟随；依赖点击事件或 JS 跳转的“伪链接”，首轮通常看不到。列表页、栏目页的翻页如果做成脚本按钮，抓取深度就容易卡在第一页。
判断标准很简单：把页面源码里的 JS 都拿掉，还能不能顺着链接走到目标页。走得到，抓取路径就算通了。
怎么自查渲染依赖程度
- 关闭浏览器 JS，看页面还剩多少正文和可点链接。
- 查看“查看页面源代码”，而不是开发者工具 Elements 面板里的内容。
- 用抓取工具对比首轮 HTML 与渲染后的差异，重点看列表页和详情页。
- 结合服务端日志，确认渲染类请求的量级是否正常。
改造的优先级
不必全站改成服务端渲染，先处理影响 URL 发现的位置：首页与栏目页的分发链接、列表页的分页链接、详情页的正文与面包屑。这几处能用服务端输出，抓取路径通常会顺畅不少。延后加载的模块，可以保留一个可抓取的入口链接，或至少留出稳定的锚点位置。
几个常见误解
- 以为“用户能看到就一定被抓到”，忽略了渲染并非每次都会发生。
- 以为提交了 Sitemap 就等于很快被处理，Sitemap 只解决发现，不决定抓取和渲染顺序。
- 以为渲染队列是即时且无限的，实际上它有资源限制和优先级安排。
改完之后观察一段时间的日志：被抓取的 URL 数量和类型有没有变化，渲染相关请求是否减少。抓取是渐进的过程，效果通常不会在改完当天就体现，需要持续对照数据来确认。