很多人把注意力放在“投了多少 URL”上，却忽略了另一個更關键的問题：搜尋蜘蛛顺着入口頁進来之後，能不能在頁面上找到下一條連結。投放只是把门打開，頁面輸出方式才决定蜘蛛能在站内走多遠。
入口頁之後的路径由頁面结构决定
蜘蛛池里的每一個入口頁，通常承担两個任務：一是让蜘蛛確認這個 URL 可訪問、有内容；二是提供足够明确的下一步。如果頁面上只有一段文字和图片，没有任何可跟随的連結，這次抓取大概率就止步于此，後面的深层頁面仍然要靠下一轮投放去碰运气。
這里说的“連結”，指的是搜尋蜘蛛在解析 HTML 时能直接讀到的連結，而不是用戶点击後才由脚本生成的東西。
三種常见的頁面輸出方式
- 静態 HTML：連結直接寫在 HTML 里，蜘蛛抓取源碼即可获得，维護成本也最低。
- 服務端渲染：頁面由後端拼装後輸出完整 HTML，蜘蛛拿到的東西和浏览器首次加载看到的接近，連結同样可讀。
- 纯前端 JS 渲染：HTML 里只有容器和脚本，連結在脚本执行後才出現。蜘蛛對 JS 的执行程度有限，且往往有等待時間限制，结果是頁面看起来正常，連結却不一定被發現。
三種方式没有绝對的好坏，但對“URL 發現”這件事，可讀連結越靠前，效率通常越稳定。
連結可见性自查清單
- 連結是否為标准 a 标簽，href 指向完整的绝對 URL，而不是依赖点击事件。
- 連結是否被 onclick、data-href 之類的属性取代，真實地址藏在脚本里。
- 是否只在 noscript 段落里放連結——部分抓取並不會执行這一段。
- 是否放在需要点击展開的折叠面板、Tab 或彈窗中。
- 是否使用了相對路径且基准地址不明确，容易拼接出错誤 URL。
- 是否所有連結都指向同一個中間跳轉頁，深层地址一個都没暴露。
懒加载與無限滚動要單獨處理
图片懒加载對連結發現影响不大，但連結懒加载影响很大：列表項滚動到视口才插入的連結，蜘蛛通常不會主動滚動。同理，無限滚動的列表如果只加载首屏，後面的内容對蜘蛛等于不存在。
- 给列表加一個不依赖脚本也能訪問的分頁入口，例如“下一頁”連結。
- 把關键的深层連結放一份在首屏 HTML 中，哪怕视觉上隐藏或折叠。
- 用 sitemap 补齐那些确實無法在頁面暴露的 URL，作為兜底而不是唯一手段。
渲染方式的取舍
把連結做成“用戶点得到”還不够，要让它“源碼里讀得到”。這两件事在静態頁面上往往是同一件事，在前端渲染頁面里经常是两回事。
如果站点本身是前端框架搭建，不必為了蜘蛛池把整站重寫。更划算的做法通常是：對需要被發現的列表頁、聚合頁做服務端渲染或预渲染，把連結輸出到首屏 HTML；强交互的部分繼續保留 JS 渲染。资源有限时，優先保證入口頁和列表頁的可讀性，比追求全站改造成本更低。
几個容易踩的誤区
- 認為蜘蛛會像真實浏览器一样完整执行所有脚本、等待所有异步請求。
- 把連結全部寫進 JS 數组里動態生成，HTML 源碼中一個都看不到。
- 用 JS 跳轉代替服務端跳轉，蜘蛛可能停在跳轉前那一頁。
- 頁面能正常打開就認為没問题，從未看過頁面源碼里到底有什么。
上线前的检查步骤
- 用浏览器查看頁面源代碼，而不是只看開發者工具里的元素面板。
- 在源碼中搜尋目标深层 URL 的片断，確認它以連結形式存在。
- 關閉 JavaScript 後再打開頁面，看還剩多少可跟随的連結。
- 抽查几個連結是否返回正常狀態碼，避免連結指向死路。
- 记錄這次改動，後續观察日誌中深层 URL 的出現频率是否變化。
頁面輸出方式不會直接决定结果，但它决定了蜘蛛每一次到訪能被利用到什么程度。把連結放在源碼里能讀到的地方，是投入产出比較高的一步，剩下的交给時間和持續观察。