去年春天的一个周二早上，一位客户给我打来电话——声音里充满了恐慌。他运营一个房产信息网站，大约有42,000个页面，Google Search Console刚刚告诉他其中只有5,800个被索引了。他在短短一夜之间失去了大约86%的可索引页面。没有算法更新。没有人工操作。没有他记得的最近部署。就这样……消失了。
在Seahawk的12,000+个WordPress项目中，我看过这种情况无数次。最让人抓狂的是，大型网站的索引丢失很少只有一个原因。通常是三四个小故障悄悄叠加，直到某个环节崩溃。
以下是我实际的诊断方法。
---
从Google Search Console开始——但别止步于此
我做的第一件事总是在 Google Search Console 中打开"页面"报告。不是旧的覆盖范围报告——Google 在 2023 年更新了这个功能，新的"页面"视图以适当的原因代码细分了已索引和未索引的页面。在第一天截图。你需要一个基准。Pages report in Google Search Console. Not the old Coverage report — Google updated this in 2023, and the new Pages view breaks down indexed vs. non-indexed with proper reason codes. Take a screenshot on day one. You need a baseline.
原因代码至关重要。"已抓取——暂未编入索引"和"因'noindex'标签而被排除"是完全不同的问题。一个是质量信号问题；另一个是配置灾难。我见过开发人员同样对待这两种情况，浪费了数周时间追逐错误的问题。
我在大型网站上最常看到的原因
- 已抓取——暂未编入索引：Google 访问了该页面，但决定不值得索引。通常是内容过薄、接近重复，或没有获得反向链接或内部链接的页面。: Google visited the page but decided it wasn't worth indexing. Usually thin content, near-duplicates, or pages that don't earn backlinks or internal links.
- 已发现——暂未编入索引：Google 找到了该网址（可能来自你的站点地图），但还没有抓取它。这是抓取预算问题，不是内容问题。: Google found the URL (likely in your sitemap) but hasn't bothered to crawl it yet. This is a crawl budget problem, not a content problem.
- 因'noindex'标签而被排除：某人——可能是你，也可能是某个插件——添加了 noindex 指令。更多内容见下文。: Someone — possibly you, possibly a plugin — added a noindex directive. More on this below.
- 重复内容，Google 选择了其他规范标签：你的规范标签指向意外的位置，或 Google 正在覆盖它们。: Your canonical tags are pointing somewhere unexpected, or Google is overriding them.
- 页面有重定向：一个应该可被索引的页面正在重定向到某个地方，可能正确也可能不正确。: A page that should be indexable is redirecting somewhere, either correctly or incorrectly.
不要只看总数。为每个原因代码下载完整的 CSV 列表。在有 40,000 个页面的网站上，你需要能够排序和筛选。
---
爬虫预算是真实存在的，它会摧毁大型网站
早在2019年，Seahawk在一个大型电商客户项目上工作——大约28,000个产品页面——我们无法理解为什么Google每天只抓取大约3,000个页面。网站很快。网站地图很清晰。表面上一切看起来都没问题。
事实证明，该网站生成了数千个分面导航URL——?colour=red&size=large&sort=price——这些URL是可抓取的，没有正确规范化，在Googlebot到达真实产品页面之前就已经耗尽了它的抓取配额。?colour=red&size=large&sort=price — that were crawlable, not canonicalised properly, and eating through Googlebot's crawl allowance before it ever reached the real product pages.
爬虫预算本质上是Googlebot在给定时间内愿意在你的网站上抓取的URL数量。Google关于爬虫预算的官方文档确实值得阅读——他们对其工作原理很坦诚。简短版本是：如果你把它浪费在垃圾URL上，重要页面就不会被抓取。Google's own documentation on crawl budget is genuinely worth reading — they're honest about how it works. The short version: if you're wasting it on garbage URLs, the important pages don't get crawled.
如何真正审计爬虫预算
- 拉取你的服务器日志。不是Google的抓取统计数据——是实际的服务器日志。Screaming Frog Log File Analyser这类工具可以让你单独过滤Googlebot的访问。Screaming Frog Log File Analyser let you filter purely for Googlebot hits.
- 查看Googlebot访问中有多少百分比落在你真正关心的URL上。如果低于60%，你就有预算问题。
- 找出消耗最多抓取的URL模式。按频率排序。最常见的问题几乎总是：分面导航、分页存档上的分页、会话ID参数，以及空的分类/标签存档页面。
- 解决根源，而不仅仅是症状。在robots.txt中对永远不应该被抓取的参数进行Disallow。对其他一切使用rel="canonical"标签。
robots.txtfor parameters that should never be crawled. Canonical tags for everything else.
在那个电商项目上，我们通过robots.txt阻止了分面URL，并为所有过滤视图添加了rel="canonical"。在六周内，索引页面从8,000增加到24,000。内容相同。只是Googlebot最终到达了。robots.txt and added rel="canonical" to all filtered views. Within six weeks, indexed pages went from 8,000 to 24,000. Same content. Just Googlebot finally reaching it.
---
noindex 灾难（发生的频率比你想象的要高）
我需要谈论这个问题，因为我自己也经历过。不是我最闪耀的时刻。在 2021 年为一个新闻网站进行从测试环境到生产环境的迁移时，我们没有取消 WordPress 设置 → 阅读中的"阻止搜索引擎为该网站编制索引"选项。网站上线时带着全站 noindex。过了十一天，客户才注意到自然流量急剧下降。
WordPress 把这个复选框隐藏在没人想到的地方。而某些 SEO 插件——Yoast、Rank Math，甚至 AIOSEO——在文章类型级别、分类法级别和单个页面级别都有自己的 noindex 开关。其中任何一个都可能无声地对你网站的大片区域进行 noindex。
如何大规模检查 noindex
在完整网站上运行 Screaming Frog，并筛选返回 noindex 指令的页面。导出列表。然后与你的重要 URL 组进行交叉参照——产品页面、服务页面、博客文章，无论什么对业务很重要。noindex directive. Export the list. Then cross-reference against your important URL groups — product pages, service pages, blog posts, whatever matters to the business.
还要检查你在 yourdomain.com/robots.txt 处的 robots.txt。查找过于宽泛的 Disallow: 规则。我见过像 Disallow: /wp-content/ 这样的规则，它会阻止 Google 渲染页面所需的 CSS 和 JS——这可能导致渲染失败，看起来像索引问题，但实际上是 Googlebot 看到了一个损坏的页面。robots.txt at yourdomain.com/robots.txt. Look for overly broad Disallow: rules. I've seen rules like Disallow: /wp-content/ blocking CSS and JS that Google needs to render pages properly — which can cause rendering failures that look like indexation problems but are actually Googlebot seeing a broken page.
---
暗地里失效的规范标签
规范标签是大型 WordPress 网站上最隐蔽的索引杀手。因为它们单独看起来没问题，只有在大规模情况下才会暴露它们的危害。
我经常看到一个现象：一个使用 WooCommerce 的网站可以通过多个 URL 路径访问同一个产品——/product/red-shoes/、/product-category/footwear/red-shoes/ 和有时候的 /shop/red-shoes/。每个页面都有一个规范标签，但如果这些规范标签指向略有不同的 URL（HTTP vs HTTPS、是否带尾部斜杠、www vs non-www），Google 会将它们视为指向不同页面的信号，拒绝进行合并。/product/red-shoes/, /product-category/footwear/red-shoes/, and sometimes /shop/red-shoes/. Each one has a canonical tag, but if those canonicals point to slightly different URLs (HTTP vs HTTPS, trailing slash vs no trailing slash, www vs non-www), Google treats them as signals pointing to different pages and refuses to consolidate.
修复方法很平凡但很必要：
- 审计 WordPress 安装生成的每个 URL 结构。使用 Screaming Frog 的网站爬行功能→按"规范标签"筛选→导出。
- 检查是否存在协议不匹配、尾部斜杠差异和子域变体。
- 确保你的规范标签始终与你的首选 URL 完全匹配，逐个字符对应。
Rank Math 和 Yoast 都会自动生成规范标签，但这两个插件都不了解你的 .htaccess 重定向或 CDN 的 URL 规范化。你必须验证渲染后的规范标签，而不仅仅是插件认为它输出的内容。使用 httpstatus.io 这样的工具获取页面，并检查实际的响应头和 HTML。.htaccess redirects or your CDN's URL normalisation. You have to verify the rendered canonical, not just what the plugin thinks it's outputting. Fetch the page with a tool like httpstatus.io and inspect the actual response headers and HTML.
---
大型网站上的 XML 网站地图通常是错的
大多数 WordPress SEO 插件会自动生成网站地图。但大多数情况下它们也会包含你不想要在网站地图中的 URL——分页页面（/page/2/、/page/3/）、作者存档、只有两篇文章的标签页、附件页。/page/2/, /page/3/), author archives, tag pages with two posts on them, attachment pages.
网站地图应该是你最好的、最规范页面的精选列表。而不是 WordPress 曾经生成过的每个 URL 的转储。
我实际遵循的网站地图卫生规则
- 排除分页归档页面。总是这样做。
- 排除作者归档页面，除非这是一个多作者网站，且作者页面具有真实的内容价值。
- 排除标签归档，除非标签是由编辑管理的，且具有有意义的内容。
- 设定文章数量阈值——我通常排除任何少于五篇文章的归档页面。
- 将大型网站地图拆分为网站地图索引。保持单个网站地图文件在 10MB 以下且 URL 数量在 50,000 以下。Google 在这里记录了具体限制。documented limits here.
在这篇文章开头提到的房产列表网站上，网站地图有 41,000 个 URL，包括所有标签归档、每个分页页面，以及——说起来我还是有点难受——WordPress 登录页面。先清理它。总是这样做。
---
内部链接是一个索引问题
人们不认为内部链接是一个索引工具。他们应该这样认为。
如果一个页面没有内部链接指向它，Googlebot 可能根本找不到它——即使它在你的网站地图中。网站地图告诉 Google 某个 URL 存在。内部链接告诉 Google 某个 URL 很重要。这些是不同的信号。matters. Those are different signals.
在大型内容网站上，孤立页面随处可见。一篇三年前发布的博客文章，从文章存档中链接但从未从任何其他文章链接过，其爬取频率会随着时间推移降至几乎为零。
我使用 Screaming Frog 的"孤立页面"报告（在网站结构下）来识别网站地图中没有内部链接指向的页面。然后我回顾内容，找到添加链接的合理位置。不是强行添加的链接——是真正相关的链接。这需要时间，但索引影响是真实的。
---
系统诊断检查清单
如果我要把这个交给 Seahawk 的初级开发者，这是我让他们按顺序进行的步骤：
- 拉取 Google Search Console → 页面报告 → 下载所有未索引的 URL 及其原因代码。
- 检查 robots.txt 中是否有意外的广泛禁止。
robots.txtfor accidental broad disallows. - 验证 WordPress"阻止搜索引擎索引"复选框已关闭。
- 运行 Screaming Frog 并筛选页面级的 noindex 指令。
- 检查规范标签 — 检查渲染输出，而不是插件设置。
- 拉取服务器日志，检查 Googlebot 在不同 URL 类型中的爬取分布情况。
- 审核 XML 网站地图，查找垃圾 URL（分页、空存档、非规范变体）。
- 运行孤立页面报告，识别内部未链接的页面。
- 检查分面导航或基于参数的 URL 是否生成了重复的可爬取路径。
- 验证页面速度 — 持续超时的页面会被 Googlebot 降低优先级。
不要一次性尝试修复所有问题。修复一个类别的问题，等待三至四周让 Google 重新爬取，测量效果，然后处理下一个。如果你同时改变所有内容，你永远不会知道什么真正起作用了。
---
常见问题
页面为什么会在一周内被索引，然后在下一周被移除？
Google的索引并非静态的。它根据质量信号、内容新鲜度和爬虫效率不断重新评估页面。一个六个月前被索引的页面，如果没有获得任何外链、没有内部链接指向它，或者Google对你的域名的质量评估发生了变化，就可能被删除。这在网站迁移或重大内容改版后特别常见——Google会重新爬取、重新评估，有时会认为之前索引过的页面不再符合标准。
网站速度会影响索引吗？
会的，影响比大多数人意识到的要直接得多。如果页面响应缓慢——初始服务器响应始终超过2-3秒——Googlebot会降低爬取这些页面的优先级。在大规模情况下，这意味着慢页面根本无法足够频繁地被爬取以保持索引。在解决任何其他速度相关问题之前，先修复你的首字节时间(TTFB)。一个廉价的缓存插件如WP Rocket就能带来显著的改善。核心网页指标对排名很重要，但TTFB对爬取很重要。
网站地图中的页面过多会影响索引吗？
不会直接影响——但充斥着低质量URL的膨胀网站地图会削弱你发送给Google的信号。如果你的网站地图包含40,000个URL，其中30,000个是薄弱的存档页面，Google会学会把你的网站地图当作噪音。保持网站地图紧凑且高质量。把它看作编辑策展，而不是URL库存清单。
我应该使用Google的URL检查工具来手动请求索引吗？
对于单个重要页面——绝对应该。但不要尝试为成千上万的URL手动请求索引。这无法规模化，而且Google已经表示在长期内不会给手动请求的URL特殊待遇。修复基础的爬取和质量问题，让Google的自然爬取来完成工作。使用手动检查来验证特定页面是否可以被索引，而不是强制索引所有内容。can be indexed, not to force index everything.
---
诚实的真相是，索引诊断并不是令人兴奋的工作。它涉及电子表格、日志文件和大量的等待。但在大型网站上，即使恢复20%的丢失索引页面也能带来有意义的有机流量增长——在拥有40,000个页面的房产列表网站上，那是真金白银。在追求任何花哨的东西之前，先把基础做对。几乎永远不会是花哨的东西。