用前端框架搭站点的团队越来越多，頁面打開之後由脚本去請求接口，再把内容塞進 DOM。對訪客来说這没什么問题，看起来和普通頁面一样。但對搜尋蜘蛛来说，情况可能完全不同：它拿到的 HTML 里没有标题、没有正文、没有内鏈，只有几個空的容器节点。
這類問题最麻烦的地方在于它不會报错。站点监控顯示 200，頁面能正常打開，日誌里也看不到異常，于是渲染問题可以安静地存在好几年。
蜘蛛看到的内容和你看到的不一样
几種常见的情况：
- 整站客戶端渲染：HTML 只是一层壳，所有内容等脚本执行完才出現。搜尋引擎的渲染能力有限，排队也長，很多頁面可能等不到渲染那一步。
- 關键信息靠脚本注入：正文是静態的，但标题、描述、canonical 由脚本改寫，蜘蛛讀到的還是預設值。
- 内鏈寫在脚本里：導航、相關推荐通過点击事件跳轉，没有真正的 a 标簽，蜘蛛顺着連結爬不下去。
- 懒加载過了头：图片和列表在滚動或交互之後才出現，蜘蛛不滚動就看不到。
- 标簽頁與折叠内容：預設只渲染第一個标簽的内容，其余内容對訪客点開可见，對蜘蛛不可见。
怎么快速判断
- 打開頁面源碼（不是開發者工具里的 Elements 面板，那個顯示的是渲染後的结果），直接看服務器返回的 HTML。
- 在浏览器里關閉 JavaScript 再刷新，看還剩多少内容。
- 用命令行請求一次頁面，检查响應体里有没有正文文字和真實的連結。
- 在搜尋资源平台或第三方工具里看抓取快照，對比和真實頁面的差异。
- 抽查不同類型的模板：首頁、栏目頁、詳情頁、分頁，模板不同，問题也不同。
能做的調整
優先保證關键内容在 HTML 里
不必一步到位改成服務端渲染。先把最重要的部分静態輸出：頁面标题、正文主体、面包屑、主要導航、分頁連結。這些内容占了頁面價值的大部分，剩下的交互模块繼續用脚本也没關系。
给連結用真正的連結
列表頁、相關阅讀、翻頁這類需要被發現的入口，用 a 标簽寫 href，而不是靠点击事件跳轉。蜘蛛只認連結，不認按钮。
谨慎使用無限滚動
無限滚動對訪客体驗不错，但内容没有獨立 URL，也就無法單獨被抓取和引用。可以考虑保留分頁連結作為兜底，让每批内容都有一個真實地址。
別把 canonical 交给脚本
canonical、robots 元标簽、hreflang 這類指令，最好在服務端輸出。脚本注入的版本，蜘蛛不一定讀得到。
自查清單
- 關閉 JS 後，頁面是否還有可讀的标题和正文？
- 源碼里是否存在指向其他頁面的 a 标簽？
- 列表頁分頁是否是可点击的真實連結？
- canonical 與 meta robots 是否直接寫在返回的 HTML 里？
- 图片是否有 alt 與可解析的地址？
- 不同模板的渲染情况是否都抽查過？
需要說明的是，渲染方式只是抓取鏈路上的一环。如果頁面地址本身没有被暴露出来，蜘蛛连来都不會来，那属于 URL 發現的問题，蜘蛛池這類工具通常是在這個环节被讨论的。两者解决的不是同一件事，不要指望其中一個能补上另一個的缺口。
判断标准很简單：把 JavaScript 關掉，頁面還剩什么。剩得越少，風險越大。