蜘蛛拿到的是源碼，不是你的屏幕
很多人判断入口頁是否合格，靠的是自己用浏览器打開看一眼：連結都在，排版正常，就認為没問题。但抓取程序拿到的通常是服務器返回的原始 HTML，而不是你渲染完成、滚動到底、点開所有折叠面板之後看到的那一屏。两者之間的差距，往往就是出鏈有没有被提取到的差距。
所以判断入口頁的連結可见性，标准只有一個：在不执行 JavaScript、不滚動、不点击的情况下，源碼里能不能直接讀到指向目标頁的 a 标簽和 href。能讀到，就属于稳定可提取；讀不到，就得看清楚是哪種寫法把它藏起来了。
三種常见的「連結藏在交互後面」寫法
折叠與展開面板
把連結放進「展開更多」「查看全部」的面板里，只要預設狀態下這些 a 标簽仍然寫在 HTML 中，只是被 CSS 隐藏，一般不影响提取。真正有風險的是那種点击後才由脚本插入 DOM 的面板：源碼里只有一段脚本，一個連結都没有。
点击加载更多
「加载更多」按钮本身不會触發抓取。如果後續連結必须点一次按钮才拼接出来，那么没被点到的部分等于不存在。把分批加载改成首屏静態輸出、後續用真實分頁地址承接，是更稳妥的做法。
前端框架渲染的路由連結
單頁應用里，導航和列表常常由框架在浏览器端渲染。抓取程序如果不做渲染，看到的可能是一個空壳容器。對入口頁来说，關键出鏈更适合服務端渲染或直接静態輸出，把動態渲染留给不承担發現任務的交互部分。
懒加载影响的是图片，不是連結
需要区分清楚：图片懒加载用 data-src 替換 src，和連結提取没關系，a 标簽本身没有原生的懒加载属性。會出問题的是那種把「滚動到可视区域才建立連結节点」当成優化手段的寫法——這就等于把連結交给滚動行為来决定，而抓取過程通常不會替你滚到底。
換句话说，頁面体积的優化不该以牺牲連結的静態可讀性為代價。图片可以懒加载，連結最好一開始就在。
自查步骤
- 直接用浏览器的「查看網頁源代碼」，而不是開發者工具里的 Elements 面板。
- 在源碼中搜尋目标頁的路径或特征词，確認 href 實际存在。
- 禁用 JavaScript 後重新打開頁面，看導航和列表是否還有連結。
- 用抓取工具或文本浏览器請求一次，數一數提取到的内部連結數量。
- 和頁面上肉眼可见的連結數量做對比，差距大的部分就是需要整改的地方。
落地建议
- 承担發現任務的入口頁，出鏈尽量寫在静態 HTML 里，不依赖交互触發。
- 确實需要折叠时，保持节点在源碼中存在，只做样式层面的隐藏。
- 分批列表用真實分頁 URL，不要用無地址的按钮拼接。
- 每次改版後重跑一次源碼自查，避免新的前端寫法把連結又藏回去。
連結可见性只是入口頁的基础條件之一，它决定的是「能不能被發現」，並不等于「一定會被抓取，更不等于被收錄」。把基础做扎實，剩下的交给時間和整体站点质量。