搜尋引擎處理一個頁面，通常可以粗略分成两段：先抓取服務器返回的 HTML，再根據资源情况执行頁面里的脚本進行渲染。如果正文、連結、規范标簽這些東西只在渲染後才出現，收錄环节就要多等一步，甚至可能等不到。
抓取與渲染不是一回事
抓取阶段拿到的是原始 HTML，搜尋引擎會把它存下来做初步解析，包括提取連結、识別文本、判断頁面是否有實质内容。渲染阶段則要下载 JS、CSS 等资源，在類似浏览器的环境里执行，才能看到最终頁面。這两步之間存在時間和资源成本，不同搜尋引擎對渲染的支持程度和排队策略也不一样。
于是會出現一種情况：你在浏览器里看頁面完全正常，蜘蛛抓到的却是一個只有容器标簽的空壳。這不是頁面坏了，而是它把内容放在了抓取环节看不见的位置。
三種渲染方式在收錄上的差別
客戶端渲染
HTML 里只有一個挂载节点，正文由脚本從接口取資料後寫入。抓取阶段看不到正文，連結也提取不到。能不能進入索引，取决于搜尋引擎是否愿意為這個頁面付出渲染成本，越深层、越不被重视的頁面越容易被跳過。
服務端渲染與静態生成
HTML 里直接带正文和連結，渲染只是补充。這類頁面在抓取阶段就能被理解，收錄路径相對短，也更容易被内鏈發現。
混合渲染
首屏由服務端輸出，後續内容靠脚本加载。首屏正文和主導航能進 HTML 一般問题不大，但如果列表、分頁、相關推荐全靠客戶端拉取，連結發現會受影响，深层頁面可能長期停留在未被發現的狀態。
怎么確認蜘蛛拿到的内容
- 查看頁面源代碼，確認正文是否真的出現在源碼里，而不是只在開發者工具的元素面板中。
- 用不执行脚本的方式請求 URL，對比返回的 HTML 與浏览器渲染後的文本差异。
- 翻服務器日誌，看 JS、CSS 和接口請求里有没有蜘蛛的訪問记錄。如果這些资源從没被請求過，說明渲染大概率没有發生。
- 使用抓取工具或搜尋平台提供的抓取測試，對比原始 HTML 與渲染後 HTML 的文本量。
几個容易忽略的细节
- 内鏈由脚本生成。蜘蛛拿不到連結，URL 發現這一环就断了，頁面可能一直停在未發現狀態。
- 正文藏在标簽頁、折叠面板或点击展開的区域里，渲染後存在，但是否被当作正文處理，取决于具体實現。
- 分頁列表靠滚動加载，下一頁連結不在 HTML 中，深层頁面缺少入口。
- canonical、robots meta 由脚本動態插入，初始 HTML 里缺失时，判断依據會變得模糊。
- 接口返回 403 或需要登入態，渲染时取不到資料，頁面渲染出来仍是空的。
建议的處理顺序
- 先把正文、标题、canonical 和内鏈放進服務端返回的 HTML，這是成本最低、收益最明确的一步。
- 把列表頁和分頁連結改成服務端輸出，至少保證第一頁之後的入口能被抓到。
- 對确實没法改架构的部分，再考虑预渲染或静態化，優先覆盖有收錄價值的頁面。
- 改完之後不要只看一次结果，隔一段時間對比日誌里渲染资源請求是否出現變化。
一個简單的判断标准：在不执行脚本的情况下，如果頁面的主要内容和連結都在，收錄环节就少了一道不确定的關卡。