2022年，一位英国电商运营商给我打来电话，他们大约有14,000个产品页面，非常愤怒因为在六周内他们的自然流量下降了34%。没有手动惩罚。没有算法公告。只是一次缓慢而无声的崩溃。我们用Screaming Frog运行了一次完整爬取，在90分钟内找到了问题：他们的分页自动生成了数千个近似重复的URL，Google爬取了所有这些URL而不是真实的产品页面，他们的抓取预算完全耗尽了。浪费。每个月都在浪费。
关键要点：审计一个10,000页的网站不只是更大规模的小网站审计——失败模式涉及爬虫预算、模板和大规模索引，检查清单也相应改变。
这就是大型网站SEO的问题所在。问题的理解难度并不高，只是其后果会大得离谱。一个规范标签在20页网站上配置错误很烦人。但在14,000页的网站上，它可能会悄悄地扼杀你的整个索引。
这是我在Seahawk Media使用的审计清单，用于网站超过10,000页时。没有特定的重要性顺序，因为每个大型网站都有自己独特的灾难层级。
---
从抓取预算开始，而不是关键词
大多数人通过查看排名来开始大型网站审计。顺序错了。完全错了。排名取决于索引，索引取决于抓取预算。修正操作顺序。
抓取预算，简单说就是：在给定时间内Googlebot将在你的网站上爬取的URL数量。Google关于抓取预算的官方文档非常值得阅读，他们对什么会浪费预算的说明很具体。
什么在消耗你的预算？
先从服务器日志开始。不是GSC数据，是实际的服务器日志。我用GoAccess快速分析大型日志文件，因为它能处理大量数据而不出问题。你要找的是：
- 分面导航URL（例如 /shoes?colour=red&size=10&sort=price）
- 追加到URL的会话ID
- 无限滚动或"加载更多"实现生成的唯一参数字符串
- 重复的分页URL（/page/1 和 /）都被抓取
- 未被屏蔽的内部搜索结果页面
任何超过10,000页且拥有活跃分面导航的网站几乎肯定在大量浪费抓取预算。几乎肯定会。解决方案不是什么高大上的方法，就是在robots.txt中对参数模式进行disallow，或者理想情况下，通过GSC进行适当的URL参数处理，并在分面页面本身上使用规范标签。
在2021年初，Seahawk有一个家具零售商客户，拥有23,000个产品URL。表面上看起来没问题。但他们的日志分析显示Googlebot在分面过滤器组合上花费了61%的爬取访问，这些组合没有搜索需求，也没有唯一内容。他们的真实产品页面大约每14天才被爬取一次。我们将分面参数切换为noindex、follow，并在robots.txt中disallow了繁重的组合模式。在6周内，真实产品页面的平均爬取频率下降到每3-4天一次。
---
索引审计：Google索引中实际包含了什么？
site:yourdomain.com在Google中给出一个粗略数字。不要为了精确性而依赖它，但这是一个快速的合理性检查。与GSC的索引覆盖率报告进行交叉参考。
"你想要索引的页面"和"Google已索引的页面"之间的差距就是金矿所在。在大型网站上，这个差距往往很大，完全可以避免。
你关心的四种状态
- 已索引，没有问题，可以了，放着不管
- 已排除：noindex，是有意的吗？确认一下是否故意设置的
- 已排除：已抓取但当前未建立索引，这是应该让你警觉的情况
- 已排除：已发现但未抓取，抓取预算问题，回到第一部分重新处理
"已抓取，目前未编入索引"是谷歌的说法：我来过，我看了，我决定不费事了。这通常意味着内容薄弱、近似重复内容，或质量信号太弱，导致谷歌主动选择跳过。在产品页面上，这种情况经常发生在自动生成的描述上，通常是三句样板文字。谷歌见过成千上万个"此产品有多种颜色可选，3-5个工作日内发货"这样的版本。它不想再看到一个。
---
大规模规范标签
规范链接是我在大型网站上看到最严重的自我伤害的地方。不是因为它们很复杂，它们并不复杂，而是在10,000+个页面的规模下，单个模板错误会立即在数千个URL上传播。
我经常看到的两种失败：
自我引用的规范标签实际上没有指向正确的位置。典型例子：分页类别页面，其中page/2的规范标签指向自己，而不是page/1或根类别。将其乘以400个每个有8页分页的类别页面，你就会有2,800多个页面的规范信号被破坏。
规范链接链。页面A指向页面B，页面B指向页面C。Google会跟随规范链接，但并不热情。三跳已经很勉强了。我见过有些网站在多年的迁移和重新设计中积累了五跳链。Screaming Frog的"Canonical"标签可以直接显示这一点，导出它，筛选出这些链。
对每个模板类型分别运行完整的规范审核。产品页面。类别页面。博客文章。标签存档。作者页面。每个模板都有自己的失败模式，你不会从随机样本中捕捉到所有模式。
---
XML Sitemaps：比人们想的更重要
在10,000+个页面的规模下，单个网站地图文件开始成为问题。Google的限制是每个网站地图文件50,000个URL或50MB，但达到这个限制不是关键点。关键是一个包含40,000个URL的单一网站地图难以监控，当出现问题时难以调试。
拆分它。使用网站地图索引文件指向分段的网站地图：
- 产品网站地图
- 分类网站地图
- 博客/编辑网站地图
- 品牌或制造商页面网站地图（如适用）
为什么分段很重要？因为当出现问题时（而且一定会出现），你可以隔离问题。如果Google突然没有抓取你的新产品页面，你可以在GSC中查看产品网站地图的抓取日期并从那里开始调试。一个单一的网站地图让你无处可查。
还有：只在你的sitemap中包含你实际想要索引的URL。这听起来很明显。但你会惊讶。我审计过的网站，其sitemap是由插件自动生成的，包含了标签页面、作者档案、附件页面和其他半打URL类型，但它们都设置了noindex。完全是无用的噪音。
如果你还在处理结构化数据，用Google的Rich Results Test验证你的网站地图，并在浏览器中检查原始网站地图传递，确保你的服务器返回200，而不是301链或者更糟的404。
---
大规模内部链接：被低估的利器
PageRank 仍然真实存在。它通过内部链接流动。在大型网站上，你的内部链接架构实际上决定了哪些页面拥有权重，哪些页面是在角落里默默死去的孤立页面。
Seahawk在2023年有一个出版客户，大约有18,000篇文章跨越新闻和生活方式垂直领域。他们的漏斗顶部分类页面获得了不错的流量。但他们更深层的存档内容，来自2015年到2019年仍然有真实搜索需求的内容，几乎无人问津。不是因为内容不好。而是因为没有东西链接到它。他们重新设计了分类导航三次，每次，更早的内容都被埋得更深一层。
解决方案很不起眼：我们使用自定义 WordPress 插件建立了一个程序化内部链接策略，该插件识别具有相关关键词重叠的文章，并插入上下文链接。他们存档内容的点击深度从主页平均的 7.2 次点击降低到 3.1 次。在随后的一个季度，这些页面的有机展示次数上升了 28%。
这是大型网站的快速内部链接检查清单：
- 你想被索引的任何页面不应该距离主页超过 3 次点击
- 孤立页面（零个内部链接指向它们）应该被视为紧急情况，而不是待办事项
- 面包屑导航算作内部链接，确保它实施正确并使用真实的锚文本，而不仅仅是带有通用标签的"分类>子分类"
- 检查只有一个内部链接指向它们的页面，这几乎和孤立页面没有好多少
---
规模化结构化数据和Schema
如果你有 10,000+ 个产品页面，但其中没有一个都有包含 Offer、Review 和 AggregateRating 属性的 Product schema，那你就是在浪费搜索结果页面的位置。
但规模化的结构化数据也带来了自己的审计需求。模板中的一个schema错误意味着数千个无效的标记实例。我用两个工具结合来检查结构化数据：用Google的Rich Results Test进行单个URL采样，以及在Screaming Frog中进行爬虫级schema提取（Configuration → Custom Extraction → XPath for JSON-LD blocks）以获得所有页面类型的整体视图。
需要查看的内容：
- 缺少必需属性（尤其是产品页面上的 price 和 priceCurrency，这些是常见的遗漏）
- 不匹配的结构化数据（schema说的是一个产品名称，而<title>说的是另一个）
- 已弃用的schema类型、DataFeedElement 和一些较旧的 itemscope microdata 模式值得审计清理
- 审查违反Google评论摘要准则的schema、被标记为第三方的第一方评论，或来自微小样本量的汇总评分
---
规模化页面速度：不要审计你无法修复的内容
Core Web Vitals 很重要。但有个事实没人经常提：审计 10,000 个页面的 CWV，然后试图修复每个单独的 URL，这是徒劳之举。你应该按模板审计，然后按模板修复。
从PageSpeed Insights或WebPageTest针对每种模板类型运行20-30个URL的样本。如果你的产品页面平均LCP为4.8秒，那是一个模板级别的问题。解决方案在于你的图像传输管道、关键CSS或服务器响应时间，而不是修改单个页面。
特别是在大型 WordPress 网站上（这是我们在 Seahawk 处理的大部分工作），规模上的常见罪魁祸首是：
- 未优化的 WooCommerce 产品图片在没有 WebP 转换的情况下被提供
- 来自作用域不当的插件 enqueue 的 HTTP 请求过多，这些脚本在很多页面上并不需要
- 未随站点增长而扩展的托管套餐，在2,000个产品时还不错的计划在12,000个产品时通常会崩溃
先把托管搞对。其他一切都是装饰。
---
重定向审计：迁移债务问题
大型网站积累重定向链的方式就像老房子积累破旧的电路。每次重新设计、每次域名迁移、每次 URL 重构都会增加另一层。在四五年后，发现四五跳深的重定向链并不罕见。
每一次跳转都会浪费时间。每一次跳转都会削弱传递的PageRank信号。而且一些本来打算临时使用的很久远的302重定向仍然存在，造成了永久性的伤害。
我的流程：
- 用Screaming Frog爬取，导出所有3xx响应
- 筛选重定向链（A → B → C，或更长的链）
- 更新所有源链接，使其直接指向最终目的地
- 确认最终目的地返回的是200，而不是另一个重定向
- 标记任何应该是301但现在是302的重定向，并在服务器级别进行更改
还要检查：你的XML sitemap网址是否返回重定向？这很常见。Sitemap应该只包含返回200的URL。如果你的sitemap充满了301重定向，你就是在替Google做工作，而且做得很糟糕。
---
FAQ
一个10,000+页面的网站进行技术SEO审计需要多长时间?
说实话，这取决于网站的仪表化程度有多好。如果他们正确设置了GSC、可访问服务器日志，且Screaming Frog爬取时不会对自身进行速率限制，那么彻底的审计的数据收集和分析阶段需要我大约3-5个工作日。报告还要另外1-2天。任何声称能在一个下午完成有意义的大型网站审计的人，那是在抽样，而不是审计。
我需要审计每一个页面还是可以从样本中进行?
从模板而不是单个页面开始工作。拥有12,000个产品页面的网站通常只有4-6个有意义的页面模板。彻底审计每种模板类型，使用具有代表性的样本（最少20-30个URL），你的发现将适用于整个模板。例外是孤立页面识别和重定向链发现，这些需要完整的爬取覆盖，而不是抽样。
大多数大型网站中单一影响最大的修复是什么?
爬取预算，十次有九次。具体来说，是阻止或规范化没有搜索需求且没有唯一内容的分面导航URL。我见过这个单一修复在拥有大型目录的电商网站上比任何其他改动都更能产生效果。这是无聊的工作，robots.txt编辑、规范标签、参数配置，但通常比任何内容或链接建设工作都能更快地产生成果。
对于大型网站,我应该使用Screaming Frog还是Sitebulb?
两个都不错。我大部分爬虫工作都用 Screaming Frog，因为多年使用后我非常熟悉它的导出格式，它的自定义提取选项很出色。Sitebulb 的可视化层确实更好，它的审计报告对客户来说也更易读。对于超过 50,000 页的网站，你也可以看看 DeepCrawl（现在是 Lumar），它是基于云端的爬虫工具，不依赖你本地机器的 RAM。
大型网站审计中最常被忽视的问题是什么?
内部链接深度。每个人都会检查破损链接和规范标签。但很少有人系统地识别距离首页有六七次点击的页面,并问为什么他们期望这些页面能在竞争激烈的关键词上获得排名。点击深度是爬虫优先级和权威分配的代理指标。每次都要审计它。
---
大型网站SEO不是一个不同的学科，而是在忽视后果复利增长的规模上运用相同的原则。上面的清单不会保持静态。每个网站都有其特有的混乱。但如果你按照爬取预算、索引、规范标签、网站地图、内部链接、结构化数据、页面速度和重定向的大致顺序来工作，你会在查看单个关键词之前就找到80%的问题所在。
从基础设施开始。排名随之而来。