這個問题在蜘蛛池的日常运维里出現得比想象中频繁：入口頁本身返回 200，没有 noindex，連結也是實打實的 a 标簽，可日誌里就是只有頁面開头那部分 URL 被反复抓，後面的連結像根本不存在。很多时候原因不在連結寫法，而在頁面体积和連結所在的位置。

先说结论

搜尋引擎抓一個頁面时，並不是文件多大就完整解析多大。抓取模块把 HTML 拿回来之後，會交给解析模块提取連結，而解析环节通常存在大小上限或分块策略。超出范围的那部分内容可能只是被存下来，不參與連結提取，里面的 URL 自然也就不會進入待抓队列。

這個上限各家引擎都没有公開，而且會随版本調整，所以別去找一個精确的 KB 數去卡线。更實用的做法是：让頁面尽量小，让重要連結尽量靠前。

体积為什么會成為問题

對大頁面做完整解析，成本遠高于小頁面：内存占用高、解析耗时長、還容易被大量堆砌連結的頁面拖累。所以引擎在解析這一环做限制是很自然的设計，而不是针對谁。

三個常见的卡点

• 解析字节上限：超過阈值的部分不進入連結提取流程。
• 抓取超时：頁面太大導致下载或處理超时，這次抓取可能被记作失敗，連結一條都没入队。
• 结构错誤提前中断：未閉合的标簽、错誤的嵌套，會让解析器提前結束，後面的内容直接讀不到。

哪些寫法最容易让連結排到後面

• 把大量内联 CSS 或 JS 直接寫在 head 里，正文連結被推到很遠的位置。
• 一個入口頁一次性輸出几千上萬條連結，既不拆頁也不做篩選。
• 導航、面包屑、推荐位、友鏈区层层堆叠，目标連結被压到頁面最底部。
• 用 base64 内嵌图片，一張图就能顶掉几十 KB 的解析額度。
• 大量重复的模板代碼、空标簽、注释，把有效内容稀释掉。

怎么判断自己的入口頁是否踩线

不需要猜，用几個简單動作就能驗證：

• 看頁面未压缩和压缩後的大小，压缩前後差距過大的頁面，往往内联代碼太多。
• 用抓取工具取原始 HTML，確認目标連結确實出現在源碼里，而不是只存在于渲染後的 DOM。
• 看服務器日誌，統計單次抓取中同一個會话訪問了多少條 URL，如果每次都是固定的前一小段，就值得警惕。
• 把頁面尾部几條 URL 單獨拿出来提交，观察是否會被抓。能抓，說明 URL 本身没問题，問题在入口頁。

處理思路

先给頁面瘦身

把能外鏈的 CSS、JS 移出去，图片改用獨立文件地址，删掉用不上的模板区块和注释。這一步往往就能把体积降下来一大截，而且不影响頁面功能。

把關键連結前置

把最需要被發現的 URL 放在主要内容的靠前位置，次要的導航和推荐位往後放。連結顺序是可以人為安排的，別让模板结构决定優先級。

拆頁而不是堆頁

如果一個入口頁要承载上千條連結，拆成多個分頁或按分類分成若干頁，每頁控制在合理的連結數量内。分頁之間用可抓取的連結互连，比一個巨大的單頁更稳。

用 sitemap 和提交兜底

入口頁連結只是發現渠道之一。把同一批 URL 放進 sitemap，或通過提交接口推送，可以让發現不再完全依赖某一個頁面的解析结果。多條路並行，單個环节出問题时不至于全盘停摆。

两個常见誤解

• 「頁面越大内容越多，蜘蛛越喜欢」——對發現連結這件事来说恰恰相反，越大越容易被截断。
• 「連結堆得越多發現越快」——只有被真正解析到的連結才算數，堆在阈值之外的部分等于不存在。

入口頁的目的不是把 URL 堆满，而是让该被發現的 URL，出現在搜尋蜘蛛一定會讀到的那一段里。

小结

入口頁返回正常、連結是标准 a 标簽，不代表連結就一定會被提取。先確認頁面体积和連結位置是否越界，再考虑連結寫法和提交方式，排查顺序會更清楚。把頁面做小、把重要連結放前、把發現渠道分散，是這三件事里投入产出比最高的组合。