📍 WDQWDWQD987AAAAA:216.73.217.146
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b117bc0b1ddb.html
📄

Google搜索技巧：重复页面怎样排查？先别急着改标题

排查重复页面，核心不是先改标题或正文，而是先把“Google 实际抓到了哪些 URL、这些 URL 是否内容相同”列清楚，再判断是技术重复、内容重复还是外链参数造成的重复。多人协作时，建议把这份 URL 清单作为交付物，谁改哪条、改完验证什么都写在同一张表里，能显著减少返工。

常见误解：重复页面就是两篇文章写得太像

很多人一发现排名波动，就认定是“内容重复”，直接去改标题、删段落。实际上 Google 判定重复时，先看的是 URL 层面的可抓取内容。以下情况都会造成重复页面，但处理方式完全不同：

• 同一内容可通过带 www 与不带 www 两个版本访问。
• 列表页分页、筛选参数、排序参数生成大量近似 URL。
• 商品或文章同时存在 PC 版与移动版独立 URL，且未做对应关系声明。
• 同一篇内容被复制到多个栏目路径下，正文几乎一致。
• 跟踪参数、会话 ID 被站内链接大量传播，形成参数化副本。

如果只改文字，不处理 URL 与链接入口，重复仍然存在。所以第一步是定位，不是改写。

用 Google 搜索技巧做初步定位

在 Google 中可以用 site: 限定站点，再配合引号精确匹配一段独特句子，观察返回了哪些 URL。例如某段话只在 A 页面出现，却搜出三条不同 URL，这三条就值得进入排查表。这一步只是线索，不是结论，因为 Google 返回的可能是已收录但已合并的版本。

更可靠的做法是结合 Search Console 的页面报告：查看“已编入索引”和“已发现但未编入索引”的 URL，重点看同一内容是否出现多个地址。多人协作时，把每条 URL 的抓取状态、规范标签、页面标题、是否被站内链接指向，分别填进表格，避免口头交接。

逐项检查：判断重复属于哪一类

按下面顺序核对，可以较快缩小范围：

1. 协议与主机名：http 与 https、带与不带 www 是否都能打开同一内容。若能，检查是否有一方做了跳转。
2. 末尾斜杠：/page 与 /page/ 是否返回同一内容且都返回 200。
3. 大小写：URL 路径大小写不同是否被当作不同页面。
4. 参数：筛选、排序、跟踪参数是否生成可抓取的独立页面。
5. 规范标签：每个副本页面的 <link rel="canonical"> 是否指向同一个首选 URL，且该 URL 本身可访问、返回 200。
6. 站内链接：导航、面包屑、分页是否同时指向多个副本版本。
7. 站点地图：提交的 sitemap 是否只包含首选 URL，还是把参数页也一并提交。

其中第 5 项最容易出错：规范标签指向了一个跳转地址或 404 地址，等于没有明确首选版本。判断结果时，只要发现同一内容存在两个以上返回 200 的 URL，就应进入处理流程。

有条件的正确处理方式

处理方式取决于重复的性质，不能一律用同一种手段：

• 协议、主机名、末尾斜杠造成的重复：用 301 跳转到首选版本，并更新站内链接与 sitemap。这是最干净的做法。
• 参数页只是同一内容的变体：优先在 Google Search Console 中使用参数处理相关设置，同时让站内链接只指向无参数版本；不要对有用筛选页一律屏蔽。
• 确实需要保留的多个入口：保留一个首选 URL，其余页面加规范标签指向它，并确保首选 URL 在站内被正常链接。
• 内容本身高度相似但各有搜索需求：考虑合并为一篇更完整的页面，而不是靠规范标签硬压，否则用户仍可能落到内容单薄的副本。

改动前后比较时要注意：搜索需求会随季节变化，数据采集口径也可能不同，所以不要用某一天的排名直接判定改动成功。更稳妥的是记录改动日期、涉及 URL、改动类型，再观察一段时间的抓取与展示变化。

协作交付时建议留下的记录

为了让接手的人不用重新排查，交付表至少包含：URL、当前返回状态码、规范标签指向、是否被站内链接、处理动作、处理日期、验证结果。每条记录对应一个明确结论，例如“已 301 至首选版本”或“保留并加规范标签”。这样下一轮检查时，只需核对状态是否仍然一致，而不必从头搜索。

下一步：先选一个内容重复最明显的栏目，按上面的检查顺序填出 URL 清单，确认首选版本后再统一修改站内链接与 sitemap。