為什么入口頁會出現「空壳」

越来越多的入口頁用前端框架搭建：導航、列表、正文都由脚本在浏览器里拼出来。用浏览器訪問时一切正常，但蜘蛛發起的是一次普通的 HTTP 請求，它首先拿到的只是服務端返回的原始 HTML。如果這份 HTML 里既没有實质内容，也没有可以跟随的連結，後續的抓取與 URL 發現都會受影响。

需要說明的是，部分搜尋引擎的蜘蛛具备渲染能力，但渲染通常排在队列里，存在明顯延迟，而且每個 URL 的渲染预算有限。把關键内容放在脚本执行之後，等于把不确定性留给了自己。

三種常见的情况

一、内容全部由脚本生成

原始 HTML 里只有一個空的容器和一段脚本，标题、正文、内部連結都要等脚本跑完才出現。這類頁面在原始响應中几乎是空白的。

二、正文在 HTML 里，連結靠脚本注入

這是更隐蔽的一種：頁面文字能抓到，但導航、分頁、相關推荐是脚本渲染的。蜘蛛顺着原始 HTML 走不到更深一层，URL 發現自然就慢下来。

三、懒加载與延迟渲染

列表滚動到底部才加载下一屏，或者内容延迟一段時間才出現。蜘蛛通常不會滚動，也不會等待太久，看到的就是第一屏甚至空白。

怎么確認自己的入口頁有没有問题

• 用 curl 或類似工具請求一次 URL，检查返回的原始 HTML 里有没有正文關鍵詞和 a 标簽。
• 在浏览器里禁用 JS 再打開頁面，如果呈現空白或没有任何連結，問题基本可以確認。
• 對比服務端日誌：如果蜘蛛對 JS、CSS 等静態资源的請求占比異常高，說明它可能在尝试渲染。
• 抽查若干入口頁，看 title、h1、正文首段是否直接出現在 HTML 源碼中。

几種務實的處理方式

• 服務端渲染：首屏内容由服務端直出，脚本只做交互增强，這是最稳妥的做法。
• 预渲染：在构建阶段或請求时生成静態 HTML，作為蜘蛛看到的版本。
• 關键連結静態化：導航、分頁、列表連結尽量用原生 a 标簽寫在 HTML 中，不要依赖点击事件跳轉。
• noscript 兜底：放一段最基础的内容與連結，成本低，對不执行脚本的蜘蛛有帮助。
• 控制首屏依赖：把决定頁面主题的文字、标题放在靠前位置，不必等所有资源加载完毕。

几個容易踩的坑

不要因為某一次抓取看起来正常，就假设渲染一定會發生。是否渲染、何时渲染，並不完全由自己掌握。

• 把入口頁做成加载中的骨架屏，原始 HTML 里就是一片占位块。
• 用按钮加事件代替連結，源碼里没有可供跟随的 href。
• 以為提交了 sitemap 就足够，頁面本身缺少連結出口，發現效率依然有限。

寫在最後

入口頁的核心任務是把蜘蛛接進来、把 URL 送出去。凡是需要脚本执行才能看到的内容和連結，都值得先問一句：如果這段脚本不執行，頁面還剩什么。答案越具体，入口頁就越可靠。