在爬虫报告的第47000页左右，我认真考虑过转行。这个网站是一家英国大型电商目录，大约有91000个可索引的URL，但在过去六个月里一直停留在大约34000页的索引量上。没有增长。客户确信什么东西"坏了"。我告诉他们没有什么坏了。我说对了一半。
关键要点：在91000页的网站上，Googlebot爬取什么取决于你的架构告诉它什么：内部链接、网站地图规范和消除浪费决定了哪些页面被索引。On a 91,000-page site Googlebot crawls what your architecture tells it to: internal linking, sitemap discipline, and killing waste decide which pages get indexed.
那个项目改变了我对爬虫预算的整个理解。不是理论部分——我读过Google文档，看过Search Central视频，知道爬虫预算是什么。但是理解它和在规模上真正管理它是两码事。以下是我如果能回到2022年3月的那个星期二早上、第一次在Google Search Console中查看爬虫统计数据、感到胃部下沉时会对自己说的所有内容。was. But knowing it and actually managing it at scale are two wildly different things. What follows is everything I'd tell myself if I could go back to that Tuesday morning in March 2022 when I first pulled the crawl stats in Google Search Console and felt my stomach drop.
抓取预算实际上意味着什么（以及不意味着什么）
这是一直让人困惑的地方：抓取预算并不意味着"Google会为你索引的页面数量"。它大致指的是Googlebot在给定抓取窗口内会获取的URL数量，Google本身将其定义为抓取速率限制和抓取需求的组合。fetch within a given crawl window, which Google itself defines as a combination of crawl rate limit and crawl demand.
爬虫速率限制是Googlebot在不对你的服务器造成压力的情况下爬取的速度。爬虫需求是Google想要爬取的数量——由你的URL有多受欢迎和更新频率决定。将这两个因素相乘，你就能大致了解你的网站获得多少爬虫关注。wants to crawl -- driven by how popular your URLs are and how often they change. Multiply those two levers together and you have a rough sense of how much crawling attention your site gets.
对于大多数在1000页以下的网站，这无关紧要。Google会爬取所有内容。但一旦你有数万页——绝对是在超过六位数之后——Googlebot就开始做出选择。它会优先考虑。它会忽略。如果你没有设置它去优先考虑正确的内容，它会高兴地花时间爬取你的会话ID参数URL和筛选面向页面，而你的新产品在数周内无人问津。
这不是假设。这正是在那个 91,000 页项目上发生的事情。
无人警告我的分面导航问题
分面导航是我在大型网站上遇到的最严重的爬虫预算杀手。始终如此。每次都是。
这个目录网站有一个分面筛选系统——颜色、尺寸、材料、品牌——但没有配置任何URL参数处理。每个筛选组合都生成一个唯一的URL。你可以选择"蓝色"、"中等"、"棉"和"BrandX"，得到/shop?colour=blue&size=medium&material=cotton&brand=brandx。然后有人改变了顺序，得到/shop?size=medium&colour=blue&brand=brandx&material=cotton。不同的URL，相同的内容。/shop?colour=blue&size=medium&material=cotton&brand=brandx. Then someone flipped the order and got/shop?size=medium&colour=blue&brand=brandx&material=cotton. Different URL, identical content.
我运行了 Screaming Frog 爬虫（版本 18，处理 JavaScript 渲染的效果比旧版本好得多），发现筛选系统单独生成了超过 200,000 个 URL。Googlebot 在不断访问这些 URL。与此同时，数千个合法产品页面仍未被索引。
真正有效的解决方案
我们分两个阶段处理这个问题。首先，我在Google Search Console中配置了URL参数处理——将筛选参数标记为"不改变页面内容"，以指示Googlebot进行合并。其次，更重要的是，开发团队实施了适当的规范策略，将所有筛选组合指向基础类别页面。我们还对无法实际规范化的低价值筛选页面添加了noindex。noindex to low-value filtered pages that couldn't practically be canonicalised.
大约八周后，索引页面计数开始增长。不是爆炸性增长——而是稳定增长。这实际上是你想要的。索引页面的突然激增有时会触发Google的重新评估，而不是干净的成功。
Search Console 中的爬虫统计：大多数人忽视的数据
在过去三年中，我已审计了近80个网站的抓取问题。也许15%交给我的人曾查看过Search Console中的抓取统计报告。这个数字应该高得多。Crawl Stats report in Search Console. That number should be much higher.
爬虫统计报告显示你每天的平均爬虫请求、平均响应时间，以及——至关重要的——Googlebot实际爬取的内容按用途（发现与刷新）分解。如果你的"刷新"爬虫占主导地位而发现爬虫很少，Google就在花时间重新检查它已经知道的页面。而不是发现新的。这是个信号，你的内部链接可能很浅，或者你的XML网站地图没有起到任何有用的作用。
在91000页的项目中，我们每天大约有2400个爬虫请求。对于这样规模的网站，这意味着Google理论上需要大约38天爬取所有内容一次——假设每个请求都访问一个唯一、有用的页面。但事实并非如此。大约40%的爬虫请求命中了重定向链或参数膨胀的重复页面。
平均响应时间的重要性被严重低估了
在我职业生涯早期，我低估了一件事：Googlebot对服务器速度非常敏感。不是在排名方面（好吧，不是直接相关），而是在爬虫意愿方面。服务器慢会导致Googlebot退缩。Google会降低爬虫速率来避免对困顿的服务器造成压力。
这个目录类网站在高峰流量时，分类页面的首字节时间（TTFB）约为1.8秒。在客户从共享主机迁移到配备适当缓存的专用VPS后（使用WP Rocket进行页面缓存，Redis进行对象缓存），TTFB降到了400毫秒以下。在接下来的六周里，每天的爬虫请求数明显增加了。这当然是相关性，但我看过太多次这种模式，不能不重视它。
XML网站地图：别把它们当成形式化的东西
我继承的大多数网站地图都是错误的。不是完全错误——只是悄悄地、毫无用处地错误。
我经常看到的常见问题：
- 网站地图中包含返回404或301重定向的页面
- 网站地图中包含了 noindex 页面（这会让 Googlebot 困惑——你同时在说"爬取这个"和"不要索引这个"）
<lastmod>日期是静态的或根本错误的dates that are static or just wrong- 单个文件中包含 70,000+ 个网址的站点地图（限制是每个文件 50,000 个，大文件会减慢处理速度）
- 没有站点地图索引文件，只有一个庞大的 XML 文件
在大型目录项目中，网站地图在单个文件中包含了 91,000 个网址。它还包括曾经生成过的每个经过筛选的网址——其中 40,000 多个是 noindex 的。Googlebot 在处理这个庞大的文件后，才发现大多数网址根本不应该被爬取。双方都浪费了信号。
我们将站点地图架构重建为一个适当的站点地图索引，指向分段的子站点地图：一个用于核心分类页面，一个用于产品页面（由于数量庞大分为两个文件），一个用于编辑内容。每个文件都在 40,000 个网址以下。<lastmod>值根据数据库中的实际最后修改日期动态生成。没有无索引页面，没有重定向。<lastmod>values dynamically generated from the actual last-modified date in the database. No noindexed pages, no redirects.
Bing 网站管理员工具的数据（值得检查一下——Bing 有时会显示爬虫行为模式，暗示 Google 也在经历的结构问题）显示网站地图处理时间下降了超过 60%。
内部链接：你真正能控制的杠杆
直到 Seahawk 在 2020 年为一个媒体客户接手一个大型内容站点时——大约 65,000 篇文章——我才真正领会到这一点。该站点尽管拥有结构良好的网站地图和清晰的 URL 结构，但仍存在爬虫预算问题。问题出在内部链接深度上。数千篇文章实际上是孤立的——没有从任何已爬取页面指向它们的内部链接。
Googlebot不仅跟踪网站地图。它跟踪链接。如果一个页面只能通过网站地图条目发现，且没有内部链接，它会被降低优先级。这在官方文档中没有明确记录，但Google关于内部链接的指导明确指出，来自重要页面的可抓取链接是Googlebot如何优先考虑发现的方式。only follow sitemaps. It follows links. If a page is only discoverable through a sitemap entry and has zero internal links, it gets deprioritised. That's not officially documented in crisp terms, but Google's own guidance on internal linking makes clear that crawlable links from important pages are how Googlebot prioritises discovery.
对于那个媒体客户，我们使用Ahrefs的Site Audit工具审计了内部链接，发现了大约12,000篇文章只有三个或更少的内部链接指向它们。我们在CMS（WordPress，自定义Gutenberg块）中构建了一个自动化的"相关文章"模块，拉取上下文相似的内容。在随后的一个季度里，该网站的索引页面从41,000增长到超过58,000。域名权限相同。内容生产速率相同。只是内部链接更好了。WordPress, custom Gutenberg block) that pulled contextually similar content. Over the following quarter, indexed pages on that site climbed from 41,000 to over 58,000. Same domain authority. Same content production rate. Just better internal linking.
现在我在每次大型网站审计中使用的编号方法：
- 运行完整的Screaming Frog爬取并导出内部链接数据
- 识别每个入站内部链接少于三个的页面
- 与链接良好的页面进行交叉对比——找出主题群集are well-linked -- find topical clusters
- 从高流量页面向下构建对话上下文的内部链接到链接稀少的页面
- 在 Search Console 的网址检查工具中验证新链接的页面从"已发现 - 目前未编入索引"变为"已爬取"
Search Console 中的"已发现 - 目前未编入索引"状态是你的警示信号。它意味着 Google 知道该页面存在，但还没有优先级获取它。改进内部链接通常是解决这个问题最快的方法。
日志文件分析：令人不适但必要
说实话——日志文件分析是我多年来一直回避的东西。当爬虫工具已经为你提供了大部分信息时，这似乎是不必要的深入。我当时是错的。
日志文件告诉你 Googlebot 实际做了什么，而不是你从网站地图或爬虫工具推断出它做了什么。在一个项目中——一家拥有约 8,000 个产品文档页面的 SaaS 公司——日志分析显示 Googlebot 将近 30% 的爬虫时间花在了 /wp-admin/ 相邻网址和应该在 robots.txt 中被阻止的管理端资源上。没有人正确设置过这个。有四个月没有被爬取的文档页面。actually did, not what you infer it did from your sitemap or crawl tool. On one project -- a SaaS company with about 8,000 product documentation pages -- log analysis revealed Googlebot was spending nearly 30% of its crawl time on/wp-admin/adjacent URLs and admin-side assets that should have been blocked in robots.txt. Nobody had set that up properly. Documentation pages that hadn't been crawled in four months.
我用的工具是 Screaming Frog 的日志文件分析器。它不花哨，但很可靠。导入你的服务器日志，按 Googlebot 用户代理筛选，按 URL 点击频率排序。浮现出来的模式几乎总是很有启发意义的——几乎总是包括某些不应该被爬取的内容。 is the tool I use. It's not glamorous but it's reliable. Import your server logs, filter by Googlebot user agent, and sort by URL hit frequency. The patterns that emerge are almost always illuminating -- and almost always include something crawling that shouldn't be.
何时需要担心，何时可以放手
并非每个大型网站都需要积极的爬虫预算管理。如果你有10,000个页面，其中9,800个被索引，就别去动那些杠杆了。你会在不存在的地方制造问题。
爬虫预算管理变得真正值得花时间的情况是：
- 你有超过15,000个可索引页面
- 尽管新内容不断添加，但你的索引数量已经停滞
- 爬虫统计显示平均爬虫请求远低于你对页面量的预期
- 你会看到数千个 URL 处于"已发现——当前未被索引"或"已爬取——当前未被索引"状态
第二种状态——"已爬取——当前未被索引"——是不同的，值得单独区分。它意味着 Google 获取了该页面，但决定不索引它，通常是因为内容质量差或近似重复的问题。再多的爬虫预算优化也解决不了质量问题。
---
常见问题
抓取预算是否会影响小型网站？
很少有实际意义。如果你的网站少于 1,000 个页面且加载速度快，Google 几乎肯定会爬取所有内容，不管怎样。爬虫预算在规模化时才成为真正的关注点——通常是在 10,000 到 15,000 个页面以上的网站上，或者在大部分 URL 是动态生成的网站上。
直接提交网站地图能解决抓取预算问题吗？
不会。站点地图有助于发现——它告诉 Google 这些 URL 存在。但如果你的网站有结构问题（分面导航垃圾、服务器响应慢、内部链接浅），站点地图不会覆盖这些信号。可以把站点地图看作一个建议，而不是命令。
我如何检查Googlebot是否在浪费抓取预算抓取垃圾URL？
从Google Search Console中的"抓取统计"报告开始，查看哪些URL类型获得最多请求。然后交叉参考Screaming Frog爬行，以识别高流量的URL模式，这些模式可能是重复的、noindex的或低价值的。如果你有访问权限，日志文件分析将给你最精确的图景。
我应该使用`noindex`还是`robots.txt disallow`来节省抓取预算？
不同的工作需要不同的工具。robots.txt 中的 disallow 会阻止 Googlebot 完全获取该页面——节省爬虫预算，但意味着 Google 无法读取该页面上的任何信号。noindex 允许 Google 获取该页面，但告诉它不要在搜索结果中包含该页面。具体来说，对爬虫预算，disallow 在真正的垃圾 URL（管理路径、内部搜索结果）上更有效。对于你想让 Google 理解内容但不索引的过滤分面页面，noindex 加规范标签通常是正确的做法。Disallow in robots.txt prevents Googlebot from fetching the page at all -- saving crawl budget but meaning Google can't read any signals on that page.Noindex allows Google to fetch the page but tells it not to include the page in search results. For crawl budget specifically,disallow is more effective on truly junk URLs (admin paths, internal search results). For filtered facet pages where you want Google to understand the content but not index it,noindex with a canonical is usually the right call.
修复抓取预算问题后，多久能看到改善效果？
老实说，这取决于你的爬虫速率。在那个 91,000 页面的项目上，主要修复部署后，索引页面数的有意义的增长花费了大约六到八周。不要期望一夜之间的变化——Googlebot 需要重新爬取、重新评估，索引管道本身还有额外的延迟。
---
那个 91,000 页面的项目最后效果很好。索引页面在五个月内从 34,000 增加到略超过 71,000。不完美——确实有一些应该不被索引的真正质量差的产品页面——但重要的内容被找到了。客户停止问是否有什么坏了。我也停止在爬虫报告的第 47,000 页左右考虑改行。基本上。