頁面在浏览器里打開得好好的，收錄表現却一直不理想，這類現象里有一部分原因出在渲染方式上。搜尋引擎抓取一個 URL 时，第一步拿到的是服務器返回的 HTML 响應，而不是你在浏览器里看到的最终样子。把内容寫進頁面，是浏览器执行脚本之後才發生的事，這两件事之間隔着一步。
抓取拿到的和你看到的，往往不是同一個東西
一次抓取大致是這样走的：請求 URL、拿到响應、解析 HTML、從里面提取正文、标题、連結等信号。如果响應里已经有這些内容，流程到此基本完成。如果响應里只有一段脚本，真正的内容要执行脚本之後才生成，那么頁面會被放進渲染队列，等资源到位、脚本执行完，才有机會被讀懂。
渲染本身並不是缺陷，現在的搜尋引擎确實具备执行 JavaScript 的能力。問题在于渲染有排队、有资源依赖、也有失敗的可能。頁面越依赖脚本，中間环节越多，内容被完整讀到的确定性就越低。
能被抓取，不代表内容已经被讀到。抓取记錄里出現了一個 URL，只說明對方来過了，不說明它看懂了頁面上有什么。
先判断：你的頁面到底依不依赖渲染
- 關閉 JavaScript 再看一遍。在浏览器里禁用脚本後刷新頁面，如果正文、标题、主要栏目入口都消失了，說明關键内容主要靠客戶端生成。
- 看網頁源代碼，而不是审查元素。右键查看源代碼得到的是服務端返回的原始 HTML；開發者工具里看到的是脚本执行後的 DOM，两者经常差別很大。
- 直接看响應内容。用命令行請求一次，或在抓取測試類的工具里查看返回的 HTML，判断其中是否包含實质文字。
- 對照搜尋结果里的标题和摘要。如果展示的标题是預設标题、摘要也含糊，值得回头確認服務端到底輸出了什么。
這几條都是排查方向，用来缩小范围，不等于據此就能得出收錄结论。
要改的话，優先動這几處
把關键内容放進首次响應
标题、正文主体、發布時間、列表項、面包屑這類决定頁面主题的内容，尽量由服務端輸出。常见做法是服務端渲染、预渲染或静態化，具体選哪種取决于站点架构，不必一步到位，先把最重要的模板改掉即可。
站内連結用真連結
導航和列表如果靠脚本绑定点击事件跳轉，抓取阶段可能看不到可跟進的地址。用带 href 的連結标簽，能让 URL 發現這條路径稳一些，也让頁面层級更清楚。
別把重要内容藏在交互之後
需要点击、滚動、切換标簽才會出現的内容，在第一次响應里通常是缺失的。如果這部分内容對判断頁面主题重要，尽量让它預設可见，或至少保證有一個不需交互的直出版本。
保證渲染所需资源可訪問
脚本和样式文件如果被拦截，渲染可能無法完成。检查相關目錄是否被規則挡住，接口請求是否對抓取方開放。這一步只是减少渲染失敗的可能，並不意味着内容一定會被采纳。
几個容易走偏的想法
- 渲染一次就够了。渲染结果通常不會被長期儲存，頁面更新後仍要重新走一遍流程。
- 提交了地址就會收錄。提交解决的是發現，不解决服務端返回空壳的問题。
- sitemap 能补上内容。它只列地址，不携带頁面正文。
- 只要脚本能跑就没問题。脚本能跑和抓取方能跑，是两碼事。
小结
並非所有脚本渲染的頁面都會出問题，很多站点也确實能被正常處理。但如果收錄节奏長期偏慢，而服務端返回的 HTML 里几乎没有内容，這往往是值得優先處理的一环。把關键内容前移到首次响應，是在不改變内容质量的前提下，减少一道不确定性的做法。至于最终是否收錄、如何展示，仍由搜尋引擎自行判断。