适用读者：负责制造业 B2B 官网改版与维护的前端/全栈工程师、企业站 SEO 负责人，尤其是手里管着几十页设备选型列表、发现深层页面怎么都不收录的同学。

一个真实的场景：某做自动化输送设备的工厂官网，设备选型列表按品类分了 34 页，每页 20 个型号。运营在 Google 上搜自家主推的一款链板输送机型号，翻到第 7 页就再也翻不下去了——不是因为排名差，是因为第 8 页以后的所有分页在索引里根本不存在。GSC（Google Search Console）里一查，已提交 URL 210 条，已收录 46 条，收录率 21%。百度资源平台那边更难看，普通收录 300 多条提交，索引量长期停在两位数。这事儿不是内容不行，是分页的 SEO 处理从建站那天起就没做对。这篇文章把一次完整的诊断和修复过程拆开讲，包括 self-canonical、参数页 noindex、聚合页方案，以及 Google 和百度对分页行为上的差异。

一、先诊断：深分页为什么收录归零

改版接手时我做的第一件事不是改代码，是先摸清爬虫到底看到了什么。三个排查动作，按顺序来：

1. 抓取预算分析。在 GSC 的 Crawl Stats 报告里看爬虫每天在该域名抓了多少页、分布在哪里。结果很典型：日均抓取 800 次左右，其中 62% 花在了列表分页的翻页请求上（?page=3、?page=17 这类），留给详情页的配额反而少。
2. 内部链接结构检查。列表页的翻页组件只输出「上一页 / 下一页 / 尾页」三个链接，也就是说 Google 要想到第 20 页，得沿着 1→2→3 一路点过去。链接深度一深，爬虫就懒得走了。
3. 重复内容检测。把 34 个分页的 title 拉出来对比，全部是「输送设备系列 - XX机械 - 第 N 页」，除了页码没有任何差异。用 site: 指令配合页面标题搜索，Google 只索引了前几页，后面的直接被判定为低价值重复页跳过。

百度的情况比 Google 更极端。百度对动态参数 URL 的抓取意愿本来就低，加上这家官网的分页用的是 ?page=N&sort=asc 这种带排序参数的链接，同一个页面内容能生成好几个参数组合的 URL，百度蜘蛛在参数迷宫里来回打转，索引量自然上不去。

核心结论：分页收录差的根因通常不是内容问题，而是「链接可达性 + 参数扩散 + 重复判定」三件事叠加。 单独修任何一条，效果都有限。

二、机制剖析：搜索引擎怎么判定分页是重复内容

这一节讲机制，理解了机制才能判断方案的对错。

搜索引擎判断两个 URL 是否重复，用的是内容指纹（Content Fingerprint）加规范化信号（Canonicalization Signal）的组合。流程大致是这样：

flowchart LR
    A[爬虫抓取 URL] --> B[提取正文内容]
    B --> C[生成内容指纹]
    C --> D{指纹是否与已索引页面高度相似}
    D -- 是 --> E[进入 Canonical 收敛流程]
    D -- 否 --> F[正常进入索引]
    E --> G{页面是否声明 canonical}
    G -- 声明了 --> H{声明是否可信}
    G -- 未声明 --> I[引擎自行猜测规范页]
    H -- 可信 --> J[收敛到规范页<br>当前页不参与索引]
    H -- 不可信 --> I
    I --> K[可能选错规范页<br>或整组页面都不收录]

制造业列表页踩中的是哪一步？每页 20 个型号卡片，翻页后卡片内容全变了，但页面骨架——导航、侧栏筛选器、页头页脚、面包屑——占了页面文本量的绝大部分。指纹算法对正文主体的权重高，但当一个页面 80% 的文本和另一个页面一模一样时，相似度很容易越过判定阈值。title 又只有页码不同，等于自己递刀子。

再看 canonical 的坑。很多建站模板会输出这样的标签：

<!-- 典型错误示例：所有分页的 canonical 都写死了第 1 页地址 -->
<!-- 错误后果：第 2 页之后的内容被整组收敛、不参与索引 -->
<link rel="canonical" href="https://example.com/products?page=1" />
<!-- 正确写法应为当前页自身地址，如 products?page=3 就指向 page=3 -->

这是典型的「全站 canonical 指向首页分页」错误——所有分页都告诉搜索引擎「请把第 1 页当作我」。后果是两种引擎处理方式还不一样：

• Google 大多数时候会尊重这个声明，于是第 2 页到第 34 页的内容直接不参与索引，但第 1 页又只装得下 20 个型号，剩下的型号等于集体消失。
• 百度对跨页 canonical 的信任度更低，常见行为是干脆整组页面都压缩掉，索引量归零。

正确做法是分页 self-canonical：每个分页声明自己是自己的规范页。 第 3 页就声明 href="...?page=3"。这套打法 Google 在官方文档里是认可的分页处理方式之一，百度这边实测也吃这套。

还有一个机制层面的点：链接深度影响抓取优先级。Google 的抓取调度会参考 URL 距首页的链接距离，理论上没有硬性上限，但实践中超过四五层内链距离的页面，被重抓的周期会拉得非常长。34 页的纯「上一页/下一页」链式结构，尾部页面的链接深度是 34 层——这就是「翻到第 7 页就搜不到」的结构性原因。

三、修复方案一：self-canonical 与翻页链接改造

动手改三处：canonical 输出、翻页组件、title 模板。

3.1 后端模板输出 self-canonical

这家官网用的是 PHP 模板 + Nginx，改动点在列表页控制器。下面是核心逻辑（PHP 7.4，Laravel 8 的 Blade 模板，Nginx 1.20 环境）：

    // 列表页控制器：规范化分页参数并输出 canonical
public function listAction(Request $request)
{
    // 只保留合法参数，杜绝任意参数组合生成新 URL
    $page = max(1, (int) $request->query->get('page', 1));
    // 排序参数白名单，非法值一律回落默认，防止参数扩散
    $allowedSort = ['default', 'price_asc', 'newest'];
    // 用严格比较防止 0 / '0' 这类弱类型值混进白名单
    $sort = in_array($request->query->get('sort', 'default'), $allowedSort, true)
        ? $request->query->get('sort', 'default')
        : 'default';

    // 第 1 页去掉 page 参数，避免 /products?page=1 与 /products 双 URL
    $canonicalParams = [];
    // 大于 1 的页码才携带 page 参数，保证 URL 形态不重复
    if ($page > 1) {
        $canonicalParams['page'] = $page;
    }
    // 排序视图不单独抢索引，canonical 统一指向不带 sort 的地址
    $canonical = $this->generateUrl('product_list', $canonicalParams);

    // 渲染列表模板，把规范地址一并传给模板层输出
    return $this->render('product/list.html.twig', [
        'products' => $repo->findByPage($page, 20, $sort),
        'canonicalUrl' => $canonical, // 传给模板输出 link 标签
    ]);
}

模板里对应的输出：

{# Twig 模板：每个分页输出指向自身的 canonical，即 self-canonical #}
{# 同时输出 prev/next 辅助信号（Google 已不用，百度仍参考，留着无害） #}
{# canonicalUrl 由控制器传入，第 1 页时不含 page 参数 #}
<link rel="canonical" href="{{ canonicalUrl }}" />
{# 上一页存在才输出 prev，避免首页输出无效空链接 #}
{% if prevUrl %}
<link rel="prev" href="{{ prevUrl }}" />
{% endif %}
{# 下一页存在才输出 next，尾页自然为空 #}
{% if nextUrl %}
<link rel="next" href="{{ nextUrl }}" />
{% endif %}

注意第 1 页的处理：/products 和 /products?page=1 是两个 URL、同一份内容，canonical 必须统一收敛到 /products，否则又制造出一组重复页。

3.2 翻页组件改造：压缩链接深度

纯链式翻页是深分页收录差的最大帮凶。改法是「数字分页 + 跳页锚点 + 分段聚合」三件套：

flowchart TD
    L[设备选型列表首页] --> A[1 2 3 4 5 数字页码<br>直接可达前 5 页]
    L --> B[分品类聚合页 A 系列]
    L --> C[分品类聚合页 B 系列]
    A --> D[10 20 30 跳页锚点]
    B --> E[品类内再分 3-4 页<br>链接深度最多 3 层]
    C --> E
    D --> F[深层分页<br>链接深度压缩到 2-3 层]
    E --> F

改造前后的内部链接结构对比，直接看数据：

title 模板的改法很简单：从「系列名 - 第 N 页」改成「系列名 - 第 N 页（型号区间）」，比如「输送设备系列 - 第 8 页（链板机 DX-201 ~ DX-220）」。每页 title 出现了不同的型号关键词，既缓解重复判定，又能吃到长尾搜索流量。这一步零开发成本，是所有改动里性价比最高的。

四、修复方案二：参数页 noindex 与聚合页方案

4.1 排序和筛选参数页的 noindex 策略

?sort=price_asc 这类 URL 打开的是同一批设备的不同视图，内容主体与默认视图高度重合。让它们参与索引只会稀释权重。处理原则：

• 排序视图：canonical 指向默认视图 + 响应头加 X-Robots-Tag: noindex, follow。用响应头而不是 meta 标签，是因为这类 URL 往往来自前端 JS 动态拼接，模板层不一定能控制到 head。
• 筛选视图（如按功率段筛选后只有 5 个型号）：筛选结果如果对应真实的搜索需求（比如「食品级链板机」），值得独立成静态化落地页；纯技术性筛选（功率 3.5kW-4kW）则 noindex。
• 百度特别处理：百度对 noindex 的响应比 Google 慢，通常要 4-8 周才会逐步清出索引。别指望改完一周看效果，那段时间里索引量曲线先降后稳是正常现象。

Nginx 层的做法（Nginx 1.20，直接在 server 块加 map）：

# Nginx 配置：对带排序参数的列表页输出 noindex 响应头
map $args $robots_header {
    # 默认视图不加限制，返回空字符串则不输出该头
    default                         "";
    # 命中 sort 参数时返回 noindex，follow 表示链接权重仍可传递
    "~*(^|&)sort="                  "noindex, follow";
    # 预留：filter 参数同样处理，避免组合 URL 进索引
    "~*(^|&)filter="                "noindex, follow";
}

server {
    location /products {
        # 空字符串时 Nginx 不会输出该响应头，不影响正常页面
        add_header X-Robots-Tag $robots_header always;
        # always 确保即使命中 4xx/5xx 也带上头，便于批量排查
        # 常规转发逻辑交给 PHP 入口处理
        try_files $uri /index.php?$query_string;
    }
}

4.2 「查看全部」聚合页：给深层内容一个短链入口

分页方案解决的是「已生成的页面怎么被正确收录」，聚合页解决的是「深层内容怎么被更快发现」。这家官网最终上的是品类聚合页：每个设备系列一个「查看全部」页面，一次性列出该系列全部型号（这个系列最多的一个品类 140 个型号，页面体积实测 380KB，可接受），每个型号卡片链接到详情页。

结构关系用时序图表达更清楚：

sequenceDiagram
    participant U as 用户/爬虫
    participant H as 首页
    participant S as 系列聚合页(查看全部)
    participant D as 型号详情页
    U->>H: 进入首页
    H->>S: 品类入口(链接深度1)
    S->>D: 型号卡片直链(链接深度2)
    Note over D: 原链式结构下详情页深度达 6-36 层<br>统一压缩到 2 层
    U->>S: 长尾搜索如 "DX-220 链板机参数"
    S-->>U: 聚合页承接型号名搜索流量

聚合页本身做 self-canonical，与分页系列并存不冲突：搜索引擎会把两者当作同一批内容的不同视图，通常选择信息密度更高的聚合页参与排名——这正是我们想要的，型号名长尾词的落地页从「第 17 页」变成了「聚合页」。

聚合页要注意分批渲染：140 个型号如果一次性同步输出，首屏会慢。我们用了首屏 30 个服务端渲染 + 剩余懒加载的方案，但懒加载的型号卡片必须保留在初始 HTML 的 noscript 或隐藏区块里，否则爬虫不执行滚动，等于白做。这一点当时踩过坑，上线两周后 GSC 显示爬虫只看到 30 个型号，改回初始 HTML 全量输出（只是视觉上折叠）才恢复正常。

五、效果验证：GSC 与百度资源平台收录对照

修复是分四周推的：第 1 周 self-canonical 和 title 模板，第 2 周翻页组件和聚合页，第 3 周 Nginx 参数 noindex，第 4 周在两个平台分别提交重抓。

两个平台的行为差异值得记下来：

• Google：改完 canonical 后约 10 天开始批量重新评估，第 4 周收录曲线明显抬升，对 prev/next 完全无视（2019 年起已不使用），但对 self-canonical 和内链结构响应很快。
• 百度：收录变化滞后 3-6 周，noindex 参数页的清理尤其慢。另外百度蜘蛛对聚合页的抓取频次明显高于深分页，聚合页上线后抓取日志里 m.baidu.com 的请求占比上升了一截。
• 共同点：两边都吃内链结构这一套。跳页锚点上线后，第 20 页以后的页面被抓到的间隔从「基本抓不到」缩短到几天内。

中间踩的一个坑值得说：第 3 周我曾把 noindex 同时也写进了 meta 标签，结果发现某个分页因为模板变量拼错，把正常页也带上了 noindex，三天内收录掉了十几条。教训是 noindex 这类「减法」信号务必逐页抽查，用 curl -sI https://example.com/products?page=5 | grep -i robots 批量过一遍响应头再收工。

六、误区澄清与趋势

几个高频误区，挨个说清：

• 「分页应该全部 noindex」——错。分页是详情页的发现通道，全 noindex 等于切断爬虫进入深层内容的路径，除非你有一套覆盖完整的聚合页/站点地图兜底。
• 「rel=prev/next 能解决收录」——Google 早已不用，百度参考价值也有限。它是锦上添花的辅助信号，不是主方案。
• 「无限滚动页面对 SEO 无害」——如果滚动加载的内容不在初始 HTML 里，对爬虫就是不存在的。要么做分页兜底，要么全量输出后视觉折叠。
• 「收录上来了就完事」——收录只是入场券。制造业官网真正的排名资产是型号参数页，分页和聚合页的任务是把爬虫高效地送到那里。

趋势上提一句：这类结构化、参数清晰的工业品类数据，恰恰也是生成式引擎检索（GEO，Generative Engine Optimization）最依赖的语料基础——把分页和重复内容理顺，等于同时给 AI 搜索引擎铺了路。传统 SEO 做扎实的站点，往 GEO 迁移的成本天然更低。

如果你也在管一个几十页的工业站，欢迎在评论区聊聊你遇到的收录怪现象，参数 URL 的花样比这篇文章里多得多。

参考与延伸

1. Google Search Central — Consolidate duplicate URLs（canonical 与重复内容官方指南）：https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls
2. Google Search Central — Crawl Stats（抓取统计报告说明）：https://developers.google.com/search/docs/monitoring-debugging/crawl-stats
3. 百度搜索资源平台 — 搜索规范之网页规范：https://ziyuan.baidu.com/wiki/2534
4. web.dev — Discover（内链与页面发现机制）：https://web.dev/how-search-works/

分页SEO｜canonical｜重复内容｜制造业B2B｜Google Search Console｜百度收录｜参数页noindex｜技术SEO