不少站点把正文和導航交给前端框架渲染，浏览器里看一切正常，但搜尋蜘蛛第一次請求时拿到的往往只是一個空壳容器。抓取和收錄之間隔着渲染這一步，如果渲染没有被执行，或者渲染结果里缺少關键信息，頁面就可能在“已發現”“已抓取未编入索引”這些狀態上長期停留。
抓取时先看到的是原始 HTML
蜘蛛請求一個 URL 时，拿到的是服務器直接返回的 HTML 源碼。脚本、样式、接口資料會在之後由渲染环节處理。這個环节可能被排队，也可能因為资源被 robots.txt 拦截、接口超时或脚本报错而失敗。因此判断一個頁面對收錄是否友好，第一步不是看浏览器，而是看“不执行 JS 的原始响應里還剩什么”。
三類最常见的 JS 收錄問题
正文由脚本注入
如果文章主体靠接口返回資料再插入 DOM，原始 HTML 里只有空标簽，蜘蛛在渲染前看到的正文接近為空。這類頁面容易被当作低质量或空白頁處理，即使後来渲染成功，早期信号也可能已经影响了判断。
連結由脚本生成
導航、列表頁、相關推荐如果用脚本拼接連結，或者只绑定点击事件，原始 HTML 里就没有可跟随的 href。URL 發現的入口被卡住，新頁面進入抓取队列的時間會明顯拉長，收錄节奏自然跟着慢。想让 URL 稳定被發現，服務端輸出的内鏈和 sitemap 仍然是主要渠道。
元信息由脚本寫入
canonical、robots meta、hreflang 這類指令如果由脚本在渲染後插入，能否被正确讀取存在不确定性。索引归属和抓取控制都依赖這些信号，最好直接寫在初始 HTML 的 head 里。
自查方法
- 用 curl 或浏览器的“查看網頁源代碼”，確認不执行 JS 时能否看到标题、正文摘要和主要連結。
- 對比原始 HTML 與渲染後的 DOM，列出只在渲染後出現的正文、連結和指令。
- 在服務器日誌中区分普通抓取與渲染請求，看渲染請求是否被拦截、是否返回 4xx 或 5xx。
- 用抓取诊断工具查看渲染後的代碼，確認蜘蛛實际拿到的版本。
處理顺序建议
- 把标题、正文和主要内鏈改為服務端輸出或预渲染輸出，保證初始 HTML 里就有可讀内容。
- 内鏈使用标准連結标簽，避免纯脚本跳轉，让 URL 發現不依赖渲染。
- canonical、robots meta 等指令直接寫在初始 HTML 中，减少解析歧义。
- 确實無法改造的頁面，可以用预渲染或動態渲染過渡，但要让渲染结果與用戶看到的内容保持一致。
- 改造後用 URL 检查工具和日誌复核，观察一段時間内抓取频次與索引狀態的變化。
渲染改造能改善蜘蛛拿到的内容，但不等于一定被收錄，最终仍取决于頁面自身的價值和站点整体质量。
收錄是一條鏈條：URL 被發現、被抓取、被渲染、被评估。JS 頁面容易在渲染這一环掉队，而問题通常在日誌和原始 HTML 里才看得出来。把“不执行脚本时能看到什么”列為常規检查項，比事後反复提交更有效。