不少站点為了交互体驗，把正文、列表、詳情都交给 JavaScript 在浏览器里生成。對用戶来说這没問题，但對搜尋蜘蛛来说，第一次請求拿到的 HTML 可能只有框架和占位符。如果蜘蛛没有繼續执行脚本，或者执行到一半超时，頁面在它眼里就接近空壳。

為什么 JavaScript 渲染容易让蜘蛛空手而归

主流搜尋引擎具备执行 JavaScript 的能力，但和真實用戶浏览器相比，仍有一些限制：渲染队列需要排队，执行時間有上限，外部脚本、接口請求也可能被拦截。结果就是：用戶能看到内容，蜘蛛看到的却是初始 HTML。

• 關键正文寫在 JS 模板里，初始 HTML 没有對應文字。
• 接口需要登入態或特定請求头，蜘蛛請求直接失敗。
• 脚本文件被 robots.txt 或防火墙拦截，渲染流程中断。
• 懒加载触發條件依赖滚動或点击，蜘蛛不一定會操作。

自查时先做這几件事

不用一上来就改架构，先確認問题是否存在。

1. 用浏览器禁用 JavaScript，或者用纯文本模式訪問几個代表性頁面，看還剩多少可讀内容。
2. 查看頁面源代碼，而不是审查元素。源代碼里若没有标题、正文、連結，說明它們是後注入的。
3. 用搜尋资源平台的 URL 检查工具，對比原始 HTML 和渲染後 HTML。
4. 在服務器日誌或抓取日誌里，看蜘蛛請求接口和脚本时返回的狀態碼。

常见問题與處理方向

正文完全依赖客戶端渲染

如果詳情頁、文章頁的正文只在 JS 执行後出現，優先考虑服務端渲染、静態生成或预渲染。至少让初始 HTML 包含标题、核心段落和主要内鏈。對已经上线的頁面，可以先做關键頁面的预渲染，再逐步迁移。

接口和资源被挡在门外

检查 robots.txt、WAF、CDN 規則是否誤伤了蜘蛛需要的接口或脚本。接口返回 403、401 或 5xx，渲染自然失敗。可以按 User-Agent 和 IP 段做白名單，但不要為了放行蜘蛛而把整個接口暴露给任意請求。

懒加载與無限滚動

图片懒加载一般問题不大，正文懒加载就要小心。如果第二屏之後的内容必须滚動才加载，蜘蛛可能只拿到首屏。可以考虑首屏直出、分頁連結，或者用 Intersection Observer 之外的可抓取兜底方案。

動態注入的 meta 和連結

有些站点用 JS 動態寫入 canonical、robots meta、hreflang。搜尋引擎虽然可能执行，但延迟和冲突會让規則不稳定。重要指令尽量放在服務端輸出的 HTML 里，避免同一頁面出現两套信号。

一份简化的自查清單

• 代表性頁面在禁用 JS 後是否還有核心内容？
• 原始 HTML 是否包含标题、描述、canonical、主要内鏈？
• 渲染所需的脚本和接口是否對蜘蛛可訪問？
• 是否有接口返回错誤或超时？
• 分頁、篩選、詳情頁是否存在無限滚動遮挡？
• 日誌里蜘蛛是否频繁請求脚本和接口，却很少抓到内容頁？

渲染問题没有一刀切的答案。先確認蜘蛛實际看到了什么，再决定用服務端渲染、预渲染還是降級方案。不要指望改完立刻被大量收錄，抓取和索引都需要時間。

把 JavaScript 渲染自查纳入常規站点巡检，和死鏈、Sitemap、响應速度放在同一張清單里。蜘蛛能稳定拿到内容，後續的 URL 發現和栏目运营才有讨论的基础。