不少站点換成前端框架渲染之後，运营同学會發現一個現象：頁面在浏览器里看起来正常，導航、列表、詳情連結都能点，但搜尋蜘蛛似乎只抓到很少的URL。問题往往不在内容质量，而在于連結是否出現在抓取工具拿到的那份HTML里。這一篇從JavaScript渲染與首屏連結的角度，聊聊URL發現在實际运营中的常见坑與處理办法。
一、蜘蛛先拿到的是“第一份HTML”
当抓取工具請求一個URL时，首先得到的是服務器直接返回的HTML。如果連結是由JS在浏览器执行後才插入DOM的，那么這份原始HTML里可能一個可抓取的a标簽都没有。搜尋引擎具备一定的渲染能力，但渲染需要額外排队、消耗资源，並且不一定對所有URL都触發。把關键的導航與列表連結放在首屏HTML中，仍然是最稳的做法。
二、几種容易漏掉連結的寫法
- 單頁路由只靠 history.pushState：頁面切換没有整頁請求，連結由JS生成。若列表頁首屏不輸出a标簽，次級URL就很难被發現。
- 用 div 或 span 加 click 事件代替 a 标簽：视觉上是連結，语义上不是，抓取工具無法顺着它走。
- 滚動到可视区才插入連結：無限加载、懒加载列表，第一屏之外的條目往往依赖滚動事件。
- 選項卡、折叠面板里的内容延迟渲染：預設隐藏的栏目内容，可能只在点击後才去請求資料。
- JS拼接URL时參數或路径出错：相對路径基准不對、中文未编碼、多余的#号，都會让連結指向無效地址。
三、自查方法
- 用 curl 或浏览器的“查看網頁源代碼”看原始HTML，確認導航、分類、分頁連結是否在其中。
- 在浏览器中禁用JavaScript，重新打開頁面，观察還能不能走通主要路径。
- 把服務器日誌里實际被請求的URL與站内連結清單做比對，找出只存在于JS里的那部分。
- 抽查渲染後的DOM與原始HTML的差异，差异過大的頁面要重新评估渲染方案。
四、可落地的折中做法
没有必要為了抓取把整站改成服務端渲染，但可以把“連結出口”這部分單獨做静態化：
- 主導航、面包屑、栏目列表、分頁组件由服務端輸出，其余交互用JS增强。
- 列表頁至少輸出第一頁與翻頁入口，深分頁可用带普通參數的連結。
- 對确實依赖JS的站点，考虑服務端渲染或预渲染，让首屏HTML包含核心連結。
- 用Sitemap补充那些不方便放進HTML的URL，但它只是补充，不能替代站内連結。
五、几個容易被忽略的邊界
一是渲染後的内容與原始HTML差別不要太大，否則容易被判為向抓取工具和用戶展示不同内容。二是渲染會消耗资源，頁面响應耗时上升反而會影响抓取效率，需要權衡。三是移動端與桌面端如果使用不同的渲染策略，連結结构要保持一致。四是上线新模板後，最好固定一個抽查時間点，用日誌复核URL發現是否變差。
把連結放在HTML里，比让蜘蛛去执行一段脚本要可靠得多。技術選型可以灵活，但核心入口要保持简單。