蜘蛛拿到的是源码，不是你的屏幕
很多人判断入口页是否合格，靠的是自己用浏览器打开看一眼：链接都在，排版正常，就认为没问题。但抓取程序拿到的通常是服务器返回的原始 HTML，而不是你渲染完成、滚动到底、点开所有折叠面板之后看到的那一屏。两者之间的差距，往往就是出链有没有被提取到的差距。
所以判断入口页的链接可见性，标准只有一个：在不执行 JavaScript、不滚动、不点击的情况下，源码里能不能直接读到指向目标页的 a 标签和 href。能读到，就属于稳定可提取；读不到，就得看清楚是哪种写法把它藏起来了。
三种常见的「链接藏在交互后面」写法
折叠与展开面板
把链接放进「展开更多」「查看全部」的面板里，只要默认状态下这些 a 标签仍然写在 HTML 中，只是被 CSS 隐藏，一般不影响提取。真正有风险的是那种点击后才由脚本插入 DOM 的面板：源码里只有一段脚本，一个链接都没有。
点击加载更多
「加载更多」按钮本身不会触发抓取。如果后续链接必须点一次按钮才拼接出来，那么没被点到的部分等于不存在。把分批加载改成首屏静态输出、后续用真实分页地址承接，是更稳妥的做法。
前端框架渲染的路由链接
单页应用里，导航和列表常常由框架在浏览器端渲染。抓取程序如果不做渲染，看到的可能是一个空壳容器。对入口页来说，关键出链更适合服务端渲染或直接静态输出，把动态渲染留给不承担发现任务的交互部分。
懒加载影响的是图片，不是链接
需要区分清楚：图片懒加载用 data-src 替换 src，和链接提取没关系，a 标签本身没有原生的懒加载属性。会出问题的是那种把「滚动到可视区域才创建链接节点」当成优化手段的写法——这就等于把链接交给滚动行为来决定，而抓取过程通常不会替你滚到底。
换句话说，页面体积的优化不该以牺牲链接的静态可读性为代价。图片可以懒加载，链接最好一开始就在。
自查步骤
- 直接用浏览器的「查看网页源代码」，而不是开发者工具里的 Elements 面板。
- 在源码中搜索目标页的路径或特征词，确认 href 实际存在。
- 禁用 JavaScript 后重新打开页面，看导航和列表是否还有链接。
- 用抓取工具或文本浏览器请求一次，数一数提取到的内部链接数量。
- 和页面上肉眼可见的链接数量做对比，差距大的部分就是需要整改的地方。
落地建议
- 承担发现任务的入口页，出链尽量写在静态 HTML 里，不依赖交互触发。
- 确实需要折叠时，保持节点在源码中存在，只做样式层面的隐藏。
- 分批列表用真实分页 URL，不要用无地址的按钮拼接。
- 每次改版后重跑一次源码自查，避免新的前端写法把链接又藏回去。
链接可见性只是入口页的基础条件之一，它决定的是「能不能被发现」，并不等于「一定会被抓取，更不等于被收录」。把基础做扎实，剩下的交给时间和整体站点质量。