現在不少頁面依赖 JavaScript 来拼装内容：導航由组件渲染，列表從接口拉取，正文也可能在客戶端才注入。對用戶来说這没什么問题，但對搜尋引擎来说，蜘蛛第一次拿到的往往只是一個骨架 HTML。如果内容只存在于渲染之後，收錄的判断就會整体往後拖。
蜘蛛其實會看到两份頁面
理解這個問题，先要分清两份東西：
- 原始 HTML：服務器返回的第一版，通常只有 head、少量占位节点和脚本引用，正文位置是空的。
- 渲染後的 DOM：搜尋引擎用無头浏览器执行 JS 後得到的版本，這才是它真正拿去判断内容的版本。
两份之間的差异越大，從抓取到進入索引之間隔的時間通常越長。抓取成功並不等于收錄，渲染失敗或渲染结果為空，頁面都會停在索引之外。這也是抓取與收錄最容易被混為一谈的地方。
容易卡住的几個位置
初始 HTML 里几乎没有正文
- 正文完全靠 JS 注入，初始 HTML 里只有一個空容器；
- 文章列表由接口返回，HTML 中没有任何連結；
- 标题、描述、结构化信息也在客戶端拼装。
這種情况下，頁面能否被理解，几乎全押在渲染這一步上。
渲染要用的資料被挡住了
如果 robots.txt 屏蔽了接口路径，或者接口需要登入態、特定請求头、特定来源，渲染器拿不到資料，渲染出来的就是空壳。這属于站点自己阻断了自己，和内容质量没關系，但表現上會被当成收錄問题。
内容要交互才出現
点击“展開更多”、切換标簽頁、滚動到頁面底部才加载的内容，渲染器不一定會执行這些動作。未触發的那部分内容，基本不會被纳入判断范围，連結也同样不會被發現。
渲染超时或资源阻塞
首屏脚本太重、第三方资源長時間不返回、渲染队列等待過久，都可能让渲染被提前結束，拿到的只是半成品。表現就是：同一個頁面，有时能收錄，有时迟迟不動。
怎么判断自己是不是這種情况
- 用平台自带的 URL 检查工具，對比“已抓取的 HTML”和“渲染後的 HTML”，看正文是否真的出現；
- 在浏览器里關閉 JavaScript，或直接查看頁面源代碼，確認核心内容是否存在于初始 HTML；
- 看服務器日誌里该 URL 的抓取频次、返回狀態和资源請求情况，判断是否有接口請求失敗；
- 抽查一批核心頁，不要只看首頁或某一個模板。
處理顺序建议
- 優先让核心内容頁做到服務端渲染或预渲染，至少保證正文和主要内鏈出現在初始 HTML 中；
- 把主内容、面包屑、分頁連結這類用于 URL 發現的元素放在初始 HTML，而不是等脚本补上；
- 检查接口是否被 robots 規則挡住，確認渲染器能正常取到資料；
- 精简首屏脚本和第三方依赖，减少渲染超时的概率；
- 以上都確認後，再谈 sitemap 提交和内鏈引導，顺序反了容易白等。
sitemap、内鏈、外鏈解决的是“让蜘蛛知道並找到 URL”；頁面能不能進索引，還要看渲染出来的内容是否可讀、是否有獨立價值。两件事分開看，排查才不會被带偏。
如果你的站点收錄數字長期偏低，又刚好是前後端分离的架构，建议先把渲染這條鏈路走通再看別的原因。很多看起来像收錄策略的問题，源头其實在内容根本没被渲染出来。