越来越多站点用前端框架搭建，頁面在浏览器里看着完整，但交给搜尋引擎的原始 HTML 可能只有一個空 div 和一段脚本。蜘蛛並不總是执行 JavaScript，即便执行，也有渲染队列和超时限制。這份自查清單，帮你在上线前後確認一件事：蜘蛛看到的和用戶看到的，是不是同一個頁面。
蜘蛛看到的和你看到的，可能不是同一個頁面
浏览器打開頁面，脚本跑完，内容填進来，一切正常。查看源代碼，却是空的。搜尋引擎抓取通常分两步：先取原始 HTML，再排队渲染。第二步不是必然發生，也可能延迟數天。所以把關键内容只交给客戶端渲染，等于把可见性押在一個不确定的环节上。
第一件事：確認抓取结果長什么样
- 用 curl 或“查看網頁源代碼”看原始 HTML，不要看開發者工具里的 Elements 面板，那里是渲染後的 DOM。
- 用搜尋引擎提供的 URL 检查工具，對比“已抓取的 HTML”和“渲染後的 HTML”。
- 在抓取日誌里看返回字节數。列表頁只有几 KB，而正常情况下應该有几十 KB，往往就是空壳。
關键内容要能脱离脚本存在
标题、正文、内鏈
頁面标题、H1、主体正文、面包屑、主導航連結，尽量由服務端直出。這些是搜尋引擎理解頁面主题和站点结构的基础，不该依赖脚本执行完毕才出現。
用真連結，而不是点击事件
用 a href 指向真實 URL，不要用 div 加 onclick，也不要用 hash 路由来跳轉。蜘蛛跟着 href 走，跟着脚本走不一定。如果用了前端路由，保證直接訪問深层 URL 也能返回對應内容，而不是落到 404 或首頁。
渲染时机與超时
如果必须客戶端渲染，把首屏内容的請求放在最前面，別等用戶交互、滚動到底部，或者某個統計脚本返回後才發起。渲染時間過長，蜘蛛可能在超时後放弃，留下一條“已抓取但内容為空”的记錄。
图片與懒加载
懒加载優先用原生 loading="lazy"，或至少保證首屏图片不带 lazy。用脚本動態插入 src 的图片，可能永遠不出現在抓取结果里。图片本身也別忘补 alt。
预渲染、SSR 與静態化的取舍
- 内容型頁面（文章、商品、栏目）優先考虑服務端渲染或静態生成，改動成本一次，收益長期。
- 交互密集的後台頁、工具頁，客戶端渲染問题不大，本来也不需要被抓。
- 预渲染适合頁面數量不多、更新不频繁的站点，注意构建後要有机制触發重新生成。
- 無论選哪種方案，保持同一套 URL，別让渲染方案變更顺带改了地址结构。
几個常见誤区
- “浏览器能打開就行”——用戶能打開，和蜘蛛能拿到，是两回事。
- “提交了站点地图就没事”——地图只告诉地址，不解决内容為空。
- “先上线再说”——空壳頁面會被抓取记錄，之後再补渲染，還要等下一轮。
可以照做的检查顺序
- 挑 5 到 10 個代表性頁面：首頁、栏目頁、詳情頁、分頁。
- 逐個查看原始 HTML，確認核心文字和内鏈是否可见。
- 對比渲染前後的 HTML，找出差异最大的模块。
- 检查導航與列表是否為真連結，直接訪問深层 URL 能否正常返回。
- 检查懒加载與图片资源是否可抓。
- 在抓取日誌和站長工具里复核，记錄改動前後抓取体积的變化。
判断标准很简單：把 JavaScript 關掉，頁面還剩下多少有用信息？剩下的那部分，才是蜘蛛稳定能拿到的部分。
小结
客戶端渲染本身不是错，把關键内容全押在渲染之後才是風險。先让标题、正文、内鏈這些基础信息在服務端可见，再逐步優化渲染性能和加载顺序，站点结构對蜘蛛来说會清晰得多，排查問题也更容易定位。