很多站点把正文、列表甚至連結都交给前端 JS 渲染，浏览器里看着正常，爬虫拿到的却是一份空壳。结果就是：頁面能打開，日誌里也有抓取记錄，但迟迟不進索引。
第一步：先看爬虫拿到的是什么
排查的起点不是改代碼，而是確認爬虫實际看到的 HTML。用查看源碼、命令行請求或搜尋引擎提供的網址检查工具，看原始响應里有没有正文和連結，不要只看浏览器渲染後的结果。
- 原始 HTML 里有正文和連結：問题更可能出在内容质量或索引取舍上。
- 原始 HTML 里只有挂载点和提示文案：收錄慢大概率就是渲染問题。
三種常见情况
1. 内容完全由接口拉取
HTML 只剩一個空容器，正文靠頁面加载後再請求接口填充。搜尋引擎执行 JS 需要額外队列和延迟，也會消耗抓取资源，新頁面的等待時間往往比静態輸出的頁面長得多。
2. 内容存在，但要交互才出現
标簽頁切換、折叠面板、点击“查看更多”才加载的段落，在初始渲染里通常並不存在。用戶看得见，爬虫看不见，收錄自然無從谈起。
3. 内容可见，連結不可發現
列表用 div 加点击事件實現，没有 a 标簽和 href。爬虫即使渲染了頁面，也缺少可跟随的 URL，新地址只能依赖 sitemap 被發現，收錄速度會被拉長。
按這個顺序處理
- 關键内容服務端輸出：正文、标题、面包屑、主要連結放在首屏 HTML 里，前端再接管交互。
- 連結用真實的 a 标簽：href 指向可抓取的地址，不要只用 JS 跳轉。
- 分頁與列表给稳定地址：無限滚動配合分頁 URL，让翻頁内容有入口。
- sitemap 兜底：重要 URL 放進 sitemap，但不要用它替代站内連結。
- 提交後看日誌：观察抓取频次和狀態碼變化，再决定是否繼續調整。
几個容易忽略的细节
- 懒加载的图片和文本若在 DOM 中完全缺失，等于没發布。
- 正文分散在 iframe 或多個组件里拼接，可能被拆散甚至丢失。
- 接口或 CDN 超时導致渲染失敗时，返回的可能仍是一個 200 的空壳頁。
- 移動端與桌面端渲染结果差异過大，會让抓取到的版本不一致。
蜘蛛池、抓取工具之類的手段提高的是被訪問的机會，解决不了“爬虫看不到内容”這件事。内容可见性和連結可發現性没做好，抓取再多也不會自動變成索引。
怎么確認改動是否生效
對比修改前後同一 URL 的原始响應，確認正文和連結已出現在 HTML 中；再结合服務端日誌，看這類地址的抓取是否稳定、有没有 4xx 或 5xx。索引變化通常滞後，不必每天盯着查。若内容本身可替代、與站内已有頁面高度重复，即便渲染問题解决了，也不一定被收錄，這时要把精力放回内容規划和 URL 收敛上。