很多站長排查收錄問题时，會把注意力放在内容和外鏈上，却忽略了一個更靠前的环节：搜尋蜘蛛抓到的那個頁面，和你用浏览器打開看到的頁面，可能並不是同一份東西。以前端渲染為主、组件异步加载的站点，這種差异尤其明顯。
為什么會出現两份不一样的頁面
浏览器打開頁面时，會先拿到一份原始 HTML，然後执行其中的脚本、請求接口、再把内容逐步填進 DOM。用戶看到的是执行完成後的结果。搜尋蜘蛛也會执行脚本，但這件事成本高、需要排队，很多情况下它先接触到的是那份還没被填满的原始 HTML。
于是同一個 URL 就有了两種形態：原始 HTML 里的内容，和渲染後頁面里的内容。收錄判断建立在哪一份上，取决于引擎的處理能力、頁面重要程度和抓取配額。差异就是從這里開始的。
三種常见做法，收錄表現差別很大
客戶端渲染的單頁應用
原始 HTML 里往往只有一個空容器和几段脚本，标题、正文、内鏈都要等脚本执行完才出現。這類頁面的收錄通常最不稳定：可能被抓到，但索引里留下的内容很薄；也可能因為脚本里的連結没有被解析，導致整批 URL 迟迟等不到下一次抓取。
服務端渲染
服務器直接返回带内容的 HTML，用戶和蜘蛛拿到的是同一份，對收錄最友好。代價是每次訪問都要由服務端拼装頁面，运维成本相對高一些。
预渲染與静態化
在构建或請求时生成静態 HTML，兼顾响應速度和内容可见性，适合變動不频繁的列表頁、詳情頁。需要注意的是预渲染缓存要能跟着内容更新，否則索引里會長期停在一個舊版本上。
排查时按這個顺序看
- 先看原始 HTML。用查看源碼，而不是開發者工具的元素面板，確認标题、核心正文、主要内鏈是否已经在里面。元素面板展示的是渲染後的结果，容易造成誤判。
- 再看渲染後的结果。用搜尋平台提供的抓取測試或渲染截图功能，看蜘蛛执行脚本後實际拿到什么。两邊都看，才能判断差异有多大。
- 確認内鏈是否可见。如果列表頁的連結由脚本渲染生成，蜘蛛在第一步就可能看不到通往詳情的路径，URL 發現會因此變慢。
- 检查元信息。标题、描述、canonical 如果是脚本動態寫入的，要確認渲染後能被正确讀取，否則收錄後呈現的标题可能和你的预期不一致。
几個容易忽略的细节
- 首屏内容异步加载，蜘蛛抓取时接口尚未返回，頁面看起来就像被截断了。
- 依赖用戶交互才展開的内容，比如点击查看更多，蜘蛛通常不會主動去点。
- 脚本报错會让整頁渲染中断，线上偶發的接口故障就可能让一批頁面被抓成空壳。
- 同一套模板下個別頁面渲染失敗，往往只体現在收錄資料上，日常訪問未必能發現。
處理原則：關键内容不依赖脚本
不必追求所有内容都静態輸出，但要让决定收錄的那部分信息在不执行脚本的情况下也能讀到：頁面主题、核心正文的首段、指向下一层的連結、基本的元信息。這些是蜘蛛判断頁面價值、决定是否繼續爬取的依據。
如果短期内無法改造架构，至少保證三点：主要導航和列表連結是可抓取的普通連結；頁面有一個稳定的、與内容相符的标题；内容更新後预渲染或缓存能被触發刷新。做到這几点，收錄的波動通常會收敛不少。
抓取與收錄是两件事，但它們共用同一份輸入。你交到蜘蛛手里的那份 HTML，决定了它有没有東西可收。