300个页面和3000个页面，SEO有什么区别？

最直观的差别出现在构建脚本上：300 页全量构建几秒结束，3000 页要跑几分钟，而且你会第一次认真考虑增量构建。这个工程上的分岔点，恰好也是 SEO 上的分岔点。

300 页时，"被发现"这件事几乎不用管

两层分类目录加首页导航，爬虫两三跳就能走完全站。sitemap 提交一次，之后主要靠内链自己跑。这个阶段出问题，八成是内容本身，不是结构。

到了 3000 页，第一件事就变成抓取预算。Google 不会承诺把你每个页面都重抓一遍，它按 URL 的"重要度"排优先级。重要度怎么来？主要是内链——被多少页面链、链的位置有多浅。

3000 页必须把内链深度压在 3 跳以内

具体做法是在构建时算一遍链接图。把所有页面数据放在 SQLite 里，页面表存 id、category、slug、related_ids，构建时用一条递归查询算出每个页面从首页出发的最短跳数，超过 3 的直接让构建失败并报警。

这个检查一定要自动化。手工抽查在 3000 页规模上毫无意义——你根本不知道漏的是哪几百页。底部页面长期停在"已发现 – 尚未抓取"，几乎都是因为埋得太深，不是因为内容差。

到 3000 页，sitemap 该拆的是类型不是数量

先纠正一个常见误判：3000 页离 Google 的单文件上限（50,000 条 URL、未压缩 50MB）还很远，不需要分片。

但按类型拆成 sitemap-guides.xml、sitemap-tools.xml 有明确的诊断价值——Search Console 里可以分别看每一份的索引率。工具页 92%、指南页只有 40%，问题范围一下就锁定了。混在一个文件里，你只能看到一个总数，然后花一下午手工抽查。格式规范和 index 文件的写法在 Sitemap 与 robots.txt 里。

3000 页时，结构化数据从可选项变成必选项

300 页的时候，就算一条 JSON-LD 都不加，靠正文和标题 Google 也能大致判断页面主题。3000 页不一样——模板生成的页面在措辞上高度相似，Google 分不清这一页和那一页的差别，结构化数据就成了唯一的显式区分信号。

工具页标 WebApplication，指南页标 TechArticle，带步骤的加 HowTo，每页的 name 和 description 必须由模板里的独立字段生成，不能全站共用一个默认值。类型选择和字段写法可以参考 JSON-LD 里的分类型模板。

3000 页一定是模板生成的，差别在于有没有增量

300 页还可以半手写，3000 页只能是数据驱动。这本身不是问题——Omni Calculator 就是把计算器抽象成一份配置，页面由模板生成，撑起 30 多种语言、2026 年 6 月估算访问约 1429 万。Inch Calculator 更极端，只做尺寸和工程量估算这一类，同月访问 459 万。

Omni Calculator 首页的 Ecology 分类只挂着 34 个计算器，是整张网格里最小的分类之一。

它们没被判定为违规，是因为模板出来的每一个页面，参数、公式、解释文本都不同。用户落到一个具体估算需求上时，拿到的是别处没有的东西。

Google 的 Scaled Content Abuse（4.6.5）针对的是"大量低投入、低原创性、无编辑的内容"，MC Created with Little Effort（4.6.6）针对复制、改写、AI 生成且无增量的页面。判断的是增量，不是页面数。而 Helpful Content 系统在 2025 年已经升级为整站级信号——3000 页里混进一批空壳，被拖累的是另外那 2900 页。口径在 Google Search Central 的政策部分写得很清楚。

300 页该做的事，恰恰是 3000 页的前置条件

如果你手上是 300 页，值得现在就做的只有一件：把关键词到 URL 的映射写成一份表，一格一个查询，不允许两个页面抢同一个查询。

这份表在 300 页时是排重工具，在 3000 页时是生产规格。没有它，扩到 3000 页之后你连"哪个页面该删"都判断不了，只能靠感觉。而靠感觉删页面，删掉的往往是有流量的那批——因为它们看起来"太相似了"。

扩页面之前先把这张表补齐，是两种规模之间唯一真正通用的准备工作。剩下的差异，等页面数真涨上去了再处理也来得及。

Omni Calculator 访问量约 1429 万（Semrush 2026 年 6 月估算）、Inch Calculator 459 万（同期）；Google 内容政策编号 4.6.5、4.6.6 引自 Search Central 垃圾内容政策。