有些頁面用浏览器打開一切正常，但在搜尋结果里标题、摘要、正文都不完整，甚至迟迟不被收錄。排查时先別急着改 robots 或 canonical，一個常见原因是：正文並不在服務器返回的初始 HTML 里，而是靠 JavaScript 在浏览器中渲染出来的。
抓取、渲染、索引不是同一件事
搜尋引擎拿到一個 URL 後，大致會经歷获取初始 HTML、進入渲染队列、执行 JavaScript 得到完整 DOM、再從渲染结果中提取内容這几個环节。初始 HTML 和渲染後的 DOM 是两個不同的视图：前者决定第一眼能看到什么，後者才接近用戶看到的样子。
問题在于渲染是有成本的。渲染队列可能被延後，也可能因為頁面太重、脚本报错、接口被拦截而拿不到内容。這时抓取记錄里顯示“已抓取”，索引里却可能只有标题和少量文字，甚至被判定為内容不足。
先確認初始 HTML 里到底有什么
這一步的目标很朴素：不看浏览器渲染後的样子，只看服務器原始返回。
- 用查看網頁源代碼（view-source）或關閉 JavaScript 後打開頁面，看正文是否還在；
- 用 curl 或抓取工具直接請求 URL，把返回内容存下来搜尋關鍵詞；
- 在搜尋平台的網址检查里查看“已抓取的 HTML”和渲染後的截图，两者對照；
- 對比日誌中该 URL 的抓取時間與索引内容，判断是没抓到，還是抓到了没更新。
哪些寫法最容易让正文“看不见”
- 整頁由前端框架客戶端渲染，HTML 里只有一個挂载节点；
- 正文通過接口异步获取，而接口需要登入態、特定 UA 或 Referer 才返回資料；
- 内容懒加载，只有滚動到可见区域才注入 DOM；
- 需要点击“展開全文”“加载更多”才能看到主体内容；
- 關键文本寫在图片里，或依赖 Canvas 绘制。
這些寫法對真實用戶未必是問题，但它們把内容的可见性押在了渲染环节上。
處理顺序建议
- 把核心内容放回初始 HTML。标题、正文主体、主要内鏈、结构化資料，尽量由服務端直接輸出。
- 關键頁面優先服務端渲染或预渲染。詳情頁、商品頁、文章頁的正文，通常比交互组件更值得優先保障。
- 懒加载可以保留，但別用在首屏核心内容上。次要模块、评论区、推荐位後置可以接受，主体内容不建议。
- 動態渲染作為過渡而不是终点。如果短期無法改造前端，可以针對爬虫返回渲染後的 HTML，但要保證與用戶看到的内容一致，並设定登出計划。
- 改完之後分開核對。先確認初始 HTML 已含正文，再看抓取是否更新，最後看索引中的内容是否同步。
核對时別只看一個视图
站内搜尋、網址检查、抓取日誌、缓存快照给出的信息各不相同，單一来源容易誤判。比較稳妥的做法是：同一批頁面取几個样本，记錄改造前後的初始 HTML 内容、抓取時間和索引中的正文片段，用同一口径對比。
如果正文必须依赖渲染才會出現，那么收錄速度、索引完整度和後續更新都會多一层不确定性。能提前寫進初始 HTML 的内容，尽量不要留到最後。
最後提醒一点：渲染资源是有限的，把所有内容都交给 JavaScript 並不會让頁面更“現代”，只會多给搜尋引擎一次取舍的机會。先把最重要的正文稳定輸出出来，其余問题往往就好谈得多。