重复网页（用户未选定规范网页）：原因与修复方法

“重复网页（用户未选定规范网页）”表示 Google 判定某个 URL 是另一个网页的副本，在它上面没有找到声明的规范网址，于是自行选择了在搜索中显示的版本。如果被标记的 URL 是本就不该有人访问的变体（例如带跟踪参数的副本或 HTTP 副本），而 Google 选择的正是您首选的网页，那么这就是预期的结果，无需任何操作。只有当 Google 选择了您不希望出现在搜索结果中的 URL，或者被标记的 URL 正是您希望获得排名的网页时，才需要修复。

Google 对这一状态的解释

该状态位于“网页索引编制”报告中列出网页未编入索引原因的表格里。Google 的“网页索引编制”报告文档（2026 年 10 月核对）指出，该网页是另一个网页的重复网页，但没有指明首选的规范网页。同一条目还说明，Google 不会在搜索中展示被标记的 URL，并将此描述为正常运作而非错误，同时给出 2 种解决办法：如果 Google 选错了 URL，就明确标记规范网址；如果该网页其实并不重复，就让内容产生实质性差异。

“重复”是 Google 把相似网页归为一组后做出的判断。“用户未选定规范网页”则表示被标记的 URL 没有向 Google 提供它能读取的规范网址，这一点把该状态与相邻的 2 个状态区分开来：

Google 关于规范化的文档补充说，声明的规范网址是“一种提示，而非规则”：在做出决定之前，Google 还会综合考虑重定向、sitemap 条目和 HTTPS。

重复 URL 从何而来

几乎每个被标记的 URL，都是同一个网页可以通过多个地址访问造成的。Google 的 URL 结构文档指出，它处理 URL 时区分大小写；Google 搜索中心在 2010 年 4 月发布的一篇关于末尾斜杠的博文也指出，Google 把 /shoes 和 /shoes/ 视为 2 个不同的 URL（网站根目录除外）。下面每一种差异，都会为同一内容生成一个新的 URL。

• 首选网页上没有规范网址。 如果您的网页没有声明规范网址，它的各个变体自然也没有，因此 Google 找到的每个副本都会落入此状态。以 WordPress 核心为例，它只在单篇文章和单个页面上输出 canonical 标记；归档、分类、标签和博客首页视图都没有，除非主题或插件另行添加。
• 协议和主机变体。 http:// 和 https://，或 www 与不带 www 的根域名，都返回 200 状态码，而没有重定向到同一个地址。
• 末尾斜杠和字母大小写。 /shoes、/shoes/ 和 /Shoes/ 返回的是同一个网页。
• 参数和不同视图。 ?utm_source= 之类的跟踪参数、排序和筛选选项、会话 ID，以及同一内容的打印视图或网格视图。
• 意外产生的副本。 对爬虫开放的网站演示版本（Google 的文档明确列为原因之一）、预发布环境主机，或仍在提供相同网页的旧域名。
• Google 无法读取的规范网址。 Google 只接受位于 <head> 中的 rel="canonical"；其网页元数据文档指出，如果 head 中出现无效元素（例如 iframe 或 img），Google 会认为 head 已经结束，并忽略其后的内容。放在这类元素之后的规范网址，实际上等同于不存在。
• 您认为互不相同的网页。 描述完全相同的不同颜色产品，或除城市名称外每句话都相同的门店页。

SEOReport 在 2026 年 5 月至 10 月间审计的 45 个外部网站中，有 14 个（31%）的首页在服务器返回的 HTML 中没有 canonical 标记，另有 1 个的首页包含不止一个。在同一样本中，45 个网站里有 2 个（4%）没有把 HTTP 重定向到 HTTPS。

这是问题吗？修复、不处理还是观察

结论取决于 Google 选择了哪个 URL，以及您是否希望被标记的 URL 出现在搜索中。

flowchart TD
    A["URL 被标记为：重复网页（用户未选定规范网页）"] --> B["网址检查：查看 Google 选择的规范网址"]
    B --> C{"Google 选择的是您希望出现在搜索中的 URL 吗？"}
    C -->|是| D{"您的链接或 sitemap 是否指向被标记的 URL？"}
    D -->|否| E["不处理：副本已按预期被过滤"]
    D -->|是| F["让链接和 sitemap 指向首选 URL"]
    C -->|否| G{"内容真的相同吗？"}
    G -->|否| H["让各网页产生实质性差异"]
    G -->|是| I["声明首选 URL：规范网址、重定向、链接、sitemap"]
    F --> J["测试实际网址，然后验证修复"]
    H --> J
    I --> J

如何确认是哪一种原因

1. 按模式给示例分组。 示例表最多显示 1,000 行，而且不一定列出所有受影响的 URL，因此请寻找模式（全是 http://、全是 ?utm_、全是大写），而不是去数数量。
2. 检查一个被标记的 URL。 在网址检查工具中，比较“用户声明的规范网址”和“Google 选择的规范网址”。对于此状态，已编入索引的结果中，用户声明的规范网址通常显示为“无”。如果“测试实际网址”现在显示了一个规范网址，说明它是在 Google 上次抓取该 URL 之后才添加的。
3. 逐字符比较这 2 个 URL。 协议、主机、字母大小写、末尾斜杠和参数。差异在哪里，原因就在哪里。
4. 找出 Google 在哪里遇到了这个变体。 在检查结果中，“引荐网页”显示 Google 可能用来发现该 URL 的网页，“站点地图”则列出包含该 URL 的所有 sitemap。
5. 像爬虫一样抓取这些变体。 浏览器会隐藏重定向，原始响应则不会。

# Status code and redirect target for each variant of one page
for u in http://example.com/shoes/ https://example.com/shoes/ \
         https://www.example.com/shoes https://www.example.com/Shoes/ \
         "https://www.example.com/shoes/?utm_source=newsletter"; do
  curl -s -o /dev/null -w "%{http_code} -> %{redirect_url}  $u\n" "$u"
done

# The canonical tag in the HTML the server returns, before any JavaScript runs
curl -s https://www.example.com/shoes/ | grep -io '<link[^>]*canonical[^>]*>'

每个变体都应当以 301 重定向到首选 URL，或者返回 200 并通过规范网址指向它。返回 200 却没有规范网址的变体，可能会一直落在此状态中。

如何逐一修复这些原因

缺少规范网址。 为每个可编入索引的网页设置使用绝对 URL 的自引用规范网址，并放在服务器所发送 HTML 的 <head> 中靠前的位置。Google 的文档同时推荐自引用形式和绝对 URL。

<head>
  <meta charset="utf-8">
  <link rel="canonical" href="https://www.example.com/shoes/">
  <title>Trail running shoes</title>
</head>

规范网址应根据网页自身的首选地址生成，绝不能根据请求的 URL 生成。如果模板直接回显请求地址，/shoes/?utm_source=newsletter 就会把自己声明为规范网址，这些变体可能因此转入“重复网页（Google 选择的规范网页与用户指定的不同）”，而不是被合并。

协议和主机变体。 用一次保留路径和查询字符串的 301 重定向处理所有变体。在 nginx 上，HTTP 部分的配置如下；HTTPS 根域名的 server 块也要加上同样的 return 行。

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

除非存在冲突（例如证书无效，或从 HTTPS 重定向回 HTTP），Google 会优先选择 HTTPS 网页作为规范网页。请让每个变体一次跳转直达最终地址；我们的重定向链指南说明了协议、主机和斜杠规则分别添加时，是如何叠加成重定向链的。

末尾斜杠和字母大小写。 选定一种写法，把另一种用 301 重定向过去，并让 CMS 按这种写法生成链接。Google 的 URL 指南建议统一使用一种字母大小写。

参数和不同视图。 只要干净 URL 上有正确的自引用规范网址，跟踪参数问题就能解决，因为所有带参数的副本都会指向这个干净的网页。不要再在站内链接到带参数的 URL，把会话 ID 移到 Cookie 中，并为打印视图和其他视图设置指向主网页的规范网址。不要用 robots.txt 隐藏重复内容：Google 指出，被屏蔽的 URL 仍可能在没有内容的情况下被编入索引，而且 Google 无法读取它不能抓取的网页上的规范网址。Google 也不建议在网站内部用 noindex 来选择规范网址，而网址移除工具会隐藏一个 URL 的所有版本。

意外产生的副本。 把预发布环境主机放在登录验证之后；对旧域名逐页进行重定向。

并非重复的网页。 为每个网页提供其他网页所没有的内容：规格参数、库存情况、本地信息。Google 的问题排查文档指出，修改之后，网页可能还会在重复网页组中停留最多 2 周。

统一所有信号。 在您的 XML sitemap 中只列出首选 URL，站内链接也要指向规范网址所声明的同一个 URL。Google 提醒不要在 sitemap 中写一个 URL，而在 rel="canonical" 中写另一个。我们关于与网页本身相矛盾的 sitemap 的分析和 canonical 标记指南讨论了其他冲突情形。

如何验证修复

1. 对一个被标记的 URL 及其首选网页运行“测试实际网址”。实际测试会显示用户声明的规范网址；但按照 Google 的说法，它无法预测 Google 最终会选择哪个 URL。
2. 对几个重要的首选网页使用“请求编入索引”；该功能有每日配额。
3. 当这一模式的所有实例都修复后，在该状态上点击“验证修复”。Google 的文档指出，验证通常最多需要约 2 周，有时会更久；如果 Google 发现仍有未修复的实例，验证就会停止。
4. URL 通常会转移到其他状态，而不是直接消失。现在会重定向的变体会显示为“网页会自动重定向”；带有 Google 认可的规范网址的变体，通常会出现在“备用网页（有适当的规范标记）”下。这两种都是副本的正常状态。
5. 几周后，再次检查您的首选网页，确认“Google 选择的规范网址”与您声明的 URL 一致。

Search Console 告诉您 Google 把哪些 URL 归为副本，却不会告诉您是哪项全站设置在持续产生它们。完整的 SEOReport 诊断会从外部检查这些全站性来源：www 和根域名同时提供网站内容、HTTP 没有重定向到 HTTPS、sitemap、canonical 与 hreflang 中的 URL 末尾斜杠写法不统一，以及首页没有 canonical 或有不止一个。它还会列出近似重复的文章。带参数的副本和没有 canonical 的内页，仍需借助网址检查工具和上述检查来排查。检查每个模板的各种变体是一项全站性工作，这也是一次 AI 聊天会话很少能完成它的原因。

常见问题

这个状态会影响我的排名吗？

Google 认为这属于正常运作，一定程度的重复内容也很常见。代价出现在两种情况下：Google 选择了您不希望出现在搜索结果中的 URL，或者抓取时间被耗费在副本上。Google 指出，规范网页的抓取频率最高，重复网页的抓取频率则较低。

为什么报告中列出了我的网站从未链接过的 URL？

Google 会通过外部链接、带参数的推广活动链接、旧的 sitemap 以及网站的早期版本发现 URL。只要干净 URL 上有正确的 canonical，无论这些副本来自哪里，都能得到处理。

修复后，重复的 URL 应该从 Search Console 中消失吗？

通常它们会转到其他状态下继续显示，正如上面的验证步骤所述。一个未编入索引的 URL，只有在您希望它出现在搜索中时才需要关注，这与判断已抓取 - 尚未编入索引时所用的标准相同。

这个状态在其他语言的 Search Console 中叫什么？

根据 Google 各语言版本的帮助页面（2026 年 10 月核对），它在英文界面中为 "Duplicate without user-selected canonical"，在德语中为 "Duplikat – vom Nutzer nicht als kanonisch festgelegt"，在西班牙语中为 "Duplicada: el usuario no ha indicado ninguna versión canónica"，在法语中为 "Page en double sans URL canonique sélectionnée par l'utilisateur"。无论哪种语言，其含义和修复方法都完全相同。