链接可抓取怎么检查：导航到 JS 链接排查（2026）
链接可抓取会直接影响发现和抓取。本文从导航、按钮、卡片和 JavaScript 链接入手，讲清检查顺序。
链接可抓取会直接影响发现和抓取。本文从导航、按钮、卡片和 JavaScript 链接入手，讲清检查顺序。
很多网站的收录问题，表面上像是“Google 没来抓”。往下查，常常不是抓取频次不够，而是链接本身就不够可抓。导航写成了按钮，卡片跳转靠 JavaScript 事件，分页只在滚动后才出现，重要页面藏在表单、弹窗、tab 或搜索结果后面。用户点得开，不代表 Google 找得到。
Google 在 Make your links crawlable 文档里把原则讲得很直白：最稳的做法，是使用带真实 `href` 的 `` 元素，并且让目标 URL 是一个搜索系统能解析的地址。反过来，如果页面跳转靠 `onclick`、`javascript:`、按钮事件、表单提交或别的交互逻辑兜底，Google 对这些链接的发现能力就会明显变差。
这篇文章只讲一件事：链接可抓取到底怎么查。不是讲文案，不是讲点击率，而是讲发现路径。导航、正文内链、按钮、卡片、面包屑、分页、JavaScript 路由、筛选和 tab，哪些写法更稳，哪些写法最容易让重要页面变成孤立页。
很多团队检查页面时，重点放在“这个 URL 能打开”。这只是第一步。SEO 里更关键的一步，是“Google 到底能不能顺着站内链接把它发现出来”。如果页面只能靠站内搜索、用户筛选、脚本点击、登录后菜单、弹窗入口才能看到，那它就算存在，也可能长期处在弱发现状态。
这也是为什么 孤立页排查、JavaScript SEO 渲染排查 和链接可抓取，实际上是一条线。页面不是突然丢的。很多时候，是一开始就没被好好连上。
Google 官方文档给出的建议并不复杂。核心就三条：
这里最常被忽略的一点，是“可抓取链接”和“能点击的东西”不是一回事。一个 `div`、`span`、`button`，再加上再漂亮的样式和事件，也不自动等于可抓取链接。前端看的是交互成立，搜索系统看的是链接关系成立。
| 写法 | 用户能不能点 | Google 发现稳定性 |
|---|---|---|
| <a href=”/product/”> | 能 | 通常最稳 |
| <button onclick=”go(‘/product/’)”> | 能 | 不稳 |
| <a href=”javascript:void(0)”> | 能 | 不推荐 |
| 滚动后异步插入链接 | 通常能 | 取决于渲染与暴露方式 |
另一个常见问题，是把路由状态写进 fragment，也就是 `#` 后面。Google 在分页和 URL 相关文档里都强调过，fragment 不适合拿来承载你希望被单独发现的重要内容。用户能切换，不代表搜索系统会把它当成一个新的可发现目标。
| href 写法 | 建议程度 | 原因 |
|---|---|---|
| `/service/seo-audit/` | 推荐 | 目标明确，可抓取，可复用 |
| `#case-list` | 谨慎 | 更适合页内定位，不适合承载新页面发现 |
| `javascript:void(0)` | 不推荐 | 实际跳转依赖脚本，不是稳定发现路径 |
| 空 href 或省略 href | 不推荐 | 链接语义不完整，搜索系统难以判断目标 |
现代前端里常见一种说法：我们用了 History API，地址栏会变，所以没问题。这个判断只说对一半。`pushState` 和 `replaceState` 确实能帮助你把前端状态变成更像真实页面的 URL，但前提是这个 URL 本身要稳定、可访问，而且页面里要有正常链接能指过去。
Google 在 JavaScript SEO basics 和 URL structure best practices 里都给过相近的原则：地址要能被理解，状态不要全藏在脚本里。如果 History API 只是帮用户“看起来换了页”，却没有任何静态链接、稳定 URL 和一致的服务端响应，那发现问题还是会在。
换句话说，History API 是增强，不是替代。它可以让体验更顺，但不能替代真正的链接网络。
主导航、二级导航、移动端折叠菜单，是最不该出问题的地方，但现实里偏偏最常出问题。原因很简单：设计和前端都爱在这里加动画、加展开层、加交互状态。结果菜单看着很完整，底层却未必留下稳定链接。
常见问题有这些：
如果核心栏目都这么做，搜索系统的第一层发现路径就已经弱了。站点结构再好，也很难完全发挥出来。这个问题和我们站里那篇 网站架构 SEO 是直接相连的。
面包屑也是同理。很多站把面包屑做成纯文本，或者把中间层级做成不可点击状态。这样用户也许还能看懂层级，但 Google 失去了一条很稳定的上下级链接路径。Google 在 Breadcrumb 文档 里讲的是结构化数据，但背后逻辑一样：层级关系应该清楚、可解释、可被解析，而不是只有视觉提示。
很多团队误会成“按钮不能用”。不是这个意思。按钮当然可以用，尤其是在交互控制、筛选展开、提交动作里。但如果一个重要页面的访问，只能靠按钮事件触发跳转，而没有任何等价的真实链接，那 SEO 风险就起来了。
Google 在 JavaScript SEO basics 里反复强调，基础发现路径不要过度依赖复杂脚本行为。换成更直白的话：按钮可以保留，但重要路径最好还有 `` 这条主路。
很多企业站喜欢做大卡片。产品卡片、案例卡片、文章卡片，整块都能点，用户体验上没毛病。但开发实现时，常见两种风险：
第一种是典型的不可抓取风险。第二种虽然比第一种好一点，但链接信号仍然偏弱，尤其当标题链接被样式压得很深、很隐蔽时，站内链接网络就不够清楚。
更稳的做法，通常是让卡片里的主标题或核心区域直接使用清楚的 ``，而不是只靠脚本接管整个卡片点击。
很多企业站把大量内容藏在站内搜索和筛选里。产品型号靠搜索框搜，案例靠行业下拉框筛，下载资料靠选择器切换。用户当然能用。但从 SEO 角度看，这些入口默认都不等于稳定内链。
Google 并不会像真实用户那样主动去提交表单、尝试筛选组合、输入关键词再一路点开结果。这也是为什么只把页面放进搜索结果里，不给它稳定栏目页、正文内链、相关页入口，最后很容易变成弱发现页。类似问题，和 Faceted Navigation 这条线其实是同一个根。
更稳的做法通常是这样：搜索和筛选可以保留，但真正重要的集合页、详情页、专题页，仍然要通过导航、列表页、正文推荐、面包屑或分页等稳定链接系统露出来。
很多人把分页当成另一个话题。其实分页能不能被发现，本质上仍然是链接可抓取问题。Google 在 Pagination and incremental page loading 文档里说得很清楚：Google 通常通过 `` 发现分页页，不会替你点按钮。
所以如果你的“下一页”“加载更多”只是一个脚本按钮，或者无限滚动到底才懒加载下一批结果，那后续内容的发现链路就会变得很脆。这个问题，我们刚写完的 分页和无限滚动指南 会继续往下拆。
现在很多站用 React、Vue、Next.js、Nuxt 或别的前端框架。路由切换很丝滑，页面也确实在变。问题是，有些实现只是前端状态切换，不一定留下稳定、可请求、可内链的 URL。搜索系统看到的，有时只是一个外壳。
Google 在 Fix search-related JavaScript problems 和前面的 JavaScript SEO 文档里都在强调：URL、链接、状态码、canonical 这些基础信号，要能在渲染链里站得住。否则页面再丰富，发现还是会断。
如果你的网站大量依赖客户端渲染，还应该顺手检查两件事。第一，初始 HTML 里是否已经露出关键链接。第二，渲染后 DOM 里的链接有没有被延迟到用户交互之后才出现。很多项目的问题，不是完全没有链接，而是链接出现得太晚，太依赖动作。
| 实现方式 | 用户体验 | SEO 稳定性 |
|---|---|---|
| 服务端已输出主链接 | 稳 | 通常最好 |
| 渲染后自动补出链接 | 一般没问题 | 取决于执行与抓取时机 |
| 点击后才注入链接 | 用户可用 | 风险高 |
| 只改前端状态，不暴露 URL | 看起来顺 | 风险高 |
企业站很爱把内容塞进 tab。产品参数一个 tab，案例一个 tab，下载一个 tab，FAQ 一个 tab。用户端看很整齐。但如果这些内容对应的是独立价值页面，却没有真实链接，只能在当前页点击切换，那它们就不会自然形成新的发现路径。
这类问题常见于：
这里不是说 tab 不能用，而是说别拿 tab 代替站内链接体系。展示层可以收纳，发现层还是要把路修出来。
链接可抓取解决的是“能不能走到”，锚文本解决的是“走过去后大概是什么”。Google 在 anchor text and placement 相关说明里讲得很明确：描述性锚文本更有帮助。对站内发现来说，这一点尤其值钱。
如果一个页面到处都只被写成“查看更多”“点此了解”“Read More”，Google 当然未必完全看不懂，但这条站内路径的语义会明显更弱。相反，像“技术 SEO 审计清单”“JavaScript SEO 渲染排查”“Google Ads 转化追踪指南”这类锚文本，既更利于用户判断，也更利于搜索系统理解页面关系。
这里不用走极端，不是每条内链都要堆关键词。更重要的是别把所有重要链接都写成空泛按钮文案。
更实用的排查顺序，通常是这样：
到了这一步，很多“收录异常”问题就会开始变具体。不是抽象地说“Google 怎么不抓我”，而是能明确地说“这个栏目只有按钮，没有链接”“这个分页只有滚动事件，没有下一页地址”“这个案例页只在筛选里出现，没有正文内链”。问题一旦具体，修起来就快。
如果要做得再稳一点，建议把 Search Console 也一起拉进来。用 URL Inspection 抽查几个典型 URL，看 Google 选到的 canonical、抓取状态和最后看到的页面有没有偏差。这样就不会只停留在“我们觉得没问题”。
还有一个常见误区：觉得反正 URL 已经进 sitemap 了，就算没有很好内链也无所谓。这个判断不稳。站点地图当然有帮助，Google 在 Build and submit a sitemap 文档里也一直建议提交 sitemap。但 sitemap 更像补充线索，不是替代站内导航、正文内链和分页关系的主系统。
一个页面如果只存在于 sitemap，却在站内几乎没有任何真实入口，它依然更容易变成弱信号页面。换句话说，sitemap 可以告诉 Google “有这么个 URL”，但站内链接网络才更像在说“这个 URL 在整站里处在什么位置，和谁有关系，值不值得经常走”。
链接不可抓，不只是单页损失。它会连带带出三个后果：
所以这篇文章最好和 Orphan Pages、Crawl Budget、服务器日志分析 这几篇一起看。它们不是平行话题，而是一套发现路径治理的不同切面。
最后给一个更落地的执行顺序。很多团队一发现链接问题，就想一次性全站大翻修。没这个必要。更值钱的修法，通常是先抓最影响发现效率的地方。
因为前面几层，决定的是整站最粗的发现主干。主干顺了，很多深层页自然会更容易被带出来。主干都没修好，就先去抠边角组件，通常不划算。
最后说个很现实的点。链接可抓取问题，很多时候不是要推翻页面设计，也不是要重做整站交互。大量问题只需要改输出方式：把按钮外面补上真实链接，把卡片主标题改成 ``，把分页补成可访问 URL，把动态菜单改成更稳定的链接暴露。
也就是说，这不是“SEO 要求牺牲前端体验”。更准确地说，是前端体验和搜索发现可以同时存在，但前提是别把真正的链接关系藏起来。用户看到的是页面，Google 看到的是路径。路径顺了，很多抓取和收录问题自然就轻了。