把目标連結用 JavaScript 動態寫進頁面，是很多入口頁的常见做法：模板里只放一段脚本和一個資料源，連結在浏览器执行後才出現。問题是，搜尋蜘蛛看到的往往不是你浏览器里看到的那份 DOM。是否被發現，取决于搜尋引擎的渲染能力、你的脚本寫法，以及連結出現的时机。
搜尋蜘蛛看到的是源碼還是渲染後的頁面
主流搜尋引擎的抓取大致分两步：先抓原始 HTML，再在满足條件时排队做 JS 渲染。渲染不是每次抓取都會發生，它更慢、成本更高，通常只在原始 HTML 内容不足、或頁面被認為值得渲染时才触發。
這意味着：
- 連結寫在 HTML 源碼里，被發現的机會相對稳定；
- 連結靠 JS 生成，等于把發現机會押在對方的渲染队列上，延迟可能從几小时變成几天，甚至压根不渲染；
- 如果原始 HTML 只是一個空白容器，渲染又失敗，那這個入口頁對搜尋蜘蛛来说基本等于没有連結。
哪些 JS 寫法相對容易被處理
同样是 JS 生成連結，寫法差別很大：
- 服務端渲染或静態生成：脚本只是辅助，連結實际已经在返回的 HTML 里，這是最稳的做法；
- 首屏同步寫入 DOM：脚本在頁面加载早期就把連結节点插入文档，渲染时通常能抓到；
- 依赖用戶交互：点击“加载更多”、滚動到底部才出現連結。搜尋蜘蛛一般不會滚動或点击，這類連結基本不會被發現；
- 二次异步請求後拼装：等接口返回再插入連結，渲染超时或接口慢，都可能让連結错過這次渲染。
容易被誤判的几種情况
還有個更隐蔽的問题：日誌里有搜尋蜘蛛訪問，不代表連結被發現了。它可能只是抓了外壳 HTML，没有执行脚本，也没有再回来渲染。
判断依據不是“有没有来”，而是“渲染後的頁面里有没有出現目标連結，以及目标 URL 後面有没有被抓取记錄”。
另外，渲染通常是分批、限量的。如果你的入口頁數量很多、结构又高度相似，渲染资源會被摊薄，連結出現的速度會更慢，甚至只有其中一部分被處理。
怎么自己驗證
- 用搜尋引擎官方的 URL 检查、實时測試類工具，看渲染後的 HTML 里是否包含目标連結；
- 用命令行工具或關閉 JS 的浏览器訪問入口頁，對比源碼與渲染结果的差异；
- 看服務器日誌：目标連結對應的抓取請求有没有出現，間隔是否合理；
- 對比同一批連結中“寫在 HTML 里”和“JS 生成”两组的抓取覆盖率，差异會說明問题。
實际建议
如果入口頁的目的是让搜尋蜘蛛發現 URL，核心思路是不要给抓取增加額外门槛：
- 關键連結尽量直接輸出在 HTML 源碼里，不要只存在于脚本變量中；
- JS 只用来做分頁、折叠這類锦上添花的功能，不要用来承载唯一入口；
- 如果必须用 JS，至少保證首屏渲染就能拿到連結，並留一個 HTML 版兜底；
- 不要指望渲染能弥补结构問题，它解决的是“能不能讀”，不是“一定讀、马上讀”。
最後要提醒的是，無论入口頁怎么寫，它做的只是把 URL 摆到搜尋蜘蛛面前，發現和收錄是两件事。目标頁面本身的质量、可訪問性、是否有獨立價值，才是决定它會不會被收錄的主要因素。入口頁能做的，是別让目标 URL 在第一步就掉队。