現在用前端框架搭站很常见。頁面在浏览器里看着完整，正文、图片、评论区都在，但打開“查看網頁源代碼”，可能只剩一個空的挂载节点和几個脚本文件。對用戶来说没差別，對搜尋蜘蛛来说，這是一次几乎没有内容的訪問。渲染方式不是纯技術细节，它决定了蜘蛛能不能讀到你的正文，也决定了它能不能顺着頁面里的連結繼續發現更多 URL。
先分清：蜘蛛拿到的是哪一版 HTML
判断方法不复杂，把同一篇文章用两種方式各看一次：
- 查看網頁源代碼：拿到的是服務器最初返回的 HTML，接近蜘蛛第一次抓到时看到的東西。
- 检查元素（開發者工具）：看到的是脚本执行之後的 DOM，是你和用戶最终看到的样子。
如果源代碼里能讀到标题、正文主体和主要連結，說明頁面偏服務端渲染或静態直出，後續解析一般不會有太大障碍。如果源代碼里只有脚本、样式和一片空白容器，正文要等浏览器跑完脚本才出現，那就属于客戶端渲染，需要重点確認。
還要留意一点：不同搜尋引擎對脚本的處理能力並不相同，执行时机、等待时長、脚本請求是否被放行，都會影响结果。把關键内容完全交给脚本，等于把不确定性留给了自己。
三類最容易出問题的场景
正文全部由接口返回後注入
文章詳情、商品描述這類主体内容如果靠接口拉取再渲染，蜘蛛在没有执行脚本时拿到的就是一個空壳。标题可能還寫在静態部分，正文却是空的，頁面很难被判断為有實质内容。更麻烦的是，摘要、描述、结构化資料往往一並缺失。
連結是点击事件，不是常規 a 标簽
用事件绑定或前端路由代替常規的 a 标簽，用戶点击没問题，但頁面源碼里没有可识別的新地址。蜘蛛顺着連結爬行的路径就断了，很多本该被發現的頁面只能等 Sitemap 或外鏈来救。URL 發現效率一下降，新内容的收錄节奏自然變慢。
懒加载没有兜底
图片和長列表用懒加载本身没問题，問题在于把标题、價格、關键段落也放進“滚動才加载”的逻辑里。蜘蛛不滚動頁面，這部分内容就等于不存在。图片可以延迟加载来優化速度，正文和連結不行。
一份可以照着走的自查清單
- 随机挑 5 到 10 個不同類型的頁面（首頁、栏目頁、詳情頁、列表分頁），逐一對比源代碼與 DOM 的差异。
- 在浏览器禁用脚本後重新打開頁面，看還剩多少内容，剩下的部分就是最稳妥的底线。
- 检查詳情頁正文是否出現在源碼中，标题、描述、结构化資料是否同样可见。
- 检查導航和列表頁的連結是否為真實可点击的地址，而不是事件绑定。
- 用抓取工具或站長平台的抓取測試，看返回内容與浏览器看到的是否一致。
- 核對 robots.txt 是否誤拦了脚本、样式等渲染必需的资源文件。
其中第 2 條和第 6 條最容易被忽略。禁用脚本後的頁面虽然难看，但它能直接告诉你：哪些内容是“必须有脚本才能存在”的。
處理思路：让核心内容先出現在源碼里
不一定要把整站推倒重做，可以按投入從低到高排一下：
- 服務端渲染或静態直出：詳情頁、栏目頁這類内容型頁面優先改造，正文随 HTML 一起返回，後續的交互再交给前端。
- 预渲染：對更新频率不高的頁面，构建时生成一份 HTML 快照，成本相對可控。
- 關键内容降級：暂时無法改造的頁面，至少保證标题、正文首段、主要連結寫在静態部分。
- 补齐常規連結：導航、面包屑、相關推荐改用真實地址，保證爬行路径不断。
改造之後別只看首頁。挑几個深层頁面重新做一次源代碼對比，確認正文和連結确實出現在最初的 HTML 里，再观察日誌中蜘蛛的抓取情况有没有變化。
渲染方式的調整往往不會立刻带来可见變化，它更像是把一條原本时通时断的路修平。路修好了，蜘蛛愿不愿意多走，還取决于内容本身。
最後提醒一句：渲染只是内容能不能被讀到的前提，不是全部。正文是否有價值、頁面之間是否形成了合理的结构，仍然决定了這些被看到的 URL 能走多遠。把渲染問题解决掉，相当于把门槛降下来了，剩下的還是要回到内容和栏目本身。