抓取和渲染不是同一件事
搜尋引擎處理一個 URL 大致分两步：先請求地址拿到 HTML 源碼，再由渲染服務排队执行頁面里的 JavaScript，得到一份渲染後快照，用這份快照来理解頁面内容。第二步是有成本的：要排队、要消耗资源，還可能因為脚本报错、静態资源被拦、接口要求登入等原因失敗。一旦失敗，搜尋引擎手上就只剩那份初始 HTML。
所以，当正文、商品信息、文章列表全靠脚本注入，而初始 HTML 里只有一副空骨架时，頁面能不能被正确理解就成了看运气的事。
先確認初始 HTML 里有什么
最直接的自查方式是看源碼。注意要用浏览器里真正查看網頁源代碼的功能，而不是開發者工具中那個 Elements 面板，後者顯示的是渲染之後的结果。也可以用命令行工具請求一遍，把返回的 HTML 儲存下来慢慢看。
- 正文首段、标题、摘要是否出現在源碼里？
- 列表頁的條目是不是已经是真實的 a 标簽，並且带 href？
- 图片地址、图片說明文字是否在源碼里？
- 面包屑、内容内鏈、分頁連結是否在源碼里？
如果源碼里几乎什么都没有，再禁用浏览器 JavaScript 刷新一次，看看頁面還剩多少可用信息。這個無 JS 版本，大致就是最坏情况下搜尋引擎看到的样子。
几個常见的踩坑点
robots.txt 把脚本和样式挡在门外
這條比較隐蔽。有些站点為了省资源，在 robots.txt 里屏蔽了脚本目錄、样式目錄或相關後缀。结果是渲染服務拿到了 HTML，却执行不了脚本、看不到样式，渲染结果自然一团乱。检查一下規則里有没有誤伤静態资源。
内容藏在交互後面
選項卡、折叠面板、轮播图、加载更多按钮，這些内容用戶点得出来，但渲染快照通常不會主動去点。懒加载也是同理：图片地址寫在自定义属性里，只有滚動到位置才赋值给 src。對于希望被理解的内容，尽量让它預設就存在于文档结构中，用样式控制顯隐，而不是由脚本决定它是否存在。
客戶端路由缺少真實地址
單頁應用切換頁面时，可能只改了地址栏的狀態，並没有一份獨立可訪問的 HTML。搜尋引擎需要能通過一個真實 URL 直接拿到這份内容。如果某條内容只能靠先進入首頁再层层点击才能到達，被發現和更新的效率都會下降。
接口與登入態
内容通過接口异步获取时，要確認這個接口對未登入的匿名請求同样返回内容，且不依赖本地临时令牌。渲染服務没有你的登入凭證。
渲染發生在排队之後
即便一切正常，渲染通常也晚于首次抓取。對新發布、时效性强的頁面，尽量让正文在初始 HTML 里就位，別把新鲜度完全押在渲染队列上。
用現成工具做對比
- 搜尋引擎站長平台的網址检查功能，通常能分別查看抓取到的 HTML 和渲染後的 HTML，两者差异一目了然。
- 部分平台提供 URL 检查與截图，可以直接看渲染结果是否完整。
- 抓取诊断類工具可以模拟一次抓取，查看返回的内容和狀態碼。
- 服務器日誌里筛渲染相關請求，观察脚本和样式是否被真實拉取過，有没有大量 403 或 404。
可以落地的處理顺序
- 先放開脚本與样式的抓取，這一步成本最低，收益往往不小。
- 把核心頁面的主要内容改為服務端渲染或静態生成，至少保證首屏與正文在 HTML 中。
- 列表、分頁、内鏈统一使用带真實 href 的 a 标簽。
- 折叠、選項卡類内容改為預設存在于 HTML，用样式隐藏。
- 為重要頁面准备站点地图入口，為渲染失敗留一條兜底路径。
- 上线後定期抽查，比較初始 HTML 與渲染快照的差异，別等到收錄出問题才回头排查。
渲染是辅助，不是地基。把希望被理解的内容優先放進初始 HTML，剩下的再交给渲染去补。
不必為了這件事把整站重寫。挑出流量和轉化最重要的那批頁面，先把它們的内容落到源碼里，其余按優先級逐步處理，通常比一次大改更可控。