WordPress插件：报告页数与实际对象数量不一致怎样去重
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /cfd738c37a3a.html
📄
WordPress插件：报告页数与实际对象数量不一致怎样去重
先确认一件事：报告里的“页数”和数据库里的“对象数量”通常不是同一种计数。去重之前，要把报告口径和实际对象口径对齐；对齐之后仍不一致，才考虑是不是同一对象被重复计入。下面按“报告来自插件自身统计”和“报告来自外部抓取或导出”两种情况，分别说明该查什么、该做什么。
先判断报告页数统计的是哪一层对象
报告页数可能统计的是文章、页面、自定义文章类型条目、分类法术语，也可能是这些对象在前台的公开 URL。一个条目如果同时出现在归档页、分页和单页，报告可能把它算成多次，而数据库里只有一条记录。反过来，一个条目如果被拆成多语言版本或多站点副本，数据库里会有多条记录，报告却可能合并成一条。
可核对的证据是：在数据库或导出文件里按对象类型分别计数，再与报告的分项数字对照。如果报告只给一个总数，先找它是否提供按类型、按状态、按语言的拆分。没有拆分时，用同一批对象的标识字段（如 ID、slug、GUID）做集合比对，而不是直接比较总数。这一步决定后面是改统计口径，还是真的需要合并重复对象。
情况一：报告来自插件自身统计，先查计数口径
插件在后台展示的页数，往往受状态和可见性过滤影响。草稿、待审、回收站、私密、定时发布这些状态是否计入，不同插件处理方式不同。如果报告把草稿也算作页，而实际对象数量只统计已发布条目，两者必然对不上。
动作上，先在同一筛选条件下导出一份对象清单，字段至少包含 ID、类型、状态、slug、父级关系。然后用 ID 去重，得到唯一对象数；再用 slug 去重，得到唯一公开地址数。两个数字分别与报告对照，就能判断差异来自状态过滤还是地址展开。这一步的结果会直接决定下一步：如果差异只来自草稿，改筛选条件即可；如果 slug 也有重复，才进入合并流程。
例外是分页和归档。归档页本身不是独立对象，如果报告把它算进去，去重时应当排除，而不是去数据库里删条目。
情况二：报告来自外部抓取或导出，先查标识字段
外部工具抓到的页数，通常以 URL 为准。同一对象可能因为带参数、带尾斜杠、http 与 https 混用、大小写不同而被算成多条。这时去重的依据不是标题或正文，而是规范化后的 URL 或对象 ID。
动作上，先对 URL 做规范化：统一协议、去掉跟踪参数、统一尾斜杠规则、统一大小写。规范化后再按 URL 去重，得到唯一地址数。如果这个数字仍大于数据库唯一对象数，再检查是否存在同一内容被发布到多个地址的情况，比如多语言副本或多站点同步。此时的选择取决于业务意图：多语言副本是有意保留的，不应合并；纯重复发布才应合并或重定向。
假设一个站点有 100 条已发布文章，外部报告显示 130 个 URL。规范化后剩 105 个，其中 5 个是同一文章的参数变体。那么真正需要处理的重复是 5 个地址变体，而不是 30 条内容。这个假设只用于说明比较方法，不代表任何真实站点的数字。
去重动作与验证：先小范围，再决定是否批量
确定重复类型后，按以下顺序执行，每一步都留下可回退的记录：
- 导出待处理对象的 ID、slug、状态和引用关系。
- 在暂存环境或单条对象上执行一次合并或重定向，观察前台地址、后台列表和报告数字的变化。
- 确认唯一对象数下降、有效地址仍可访问后，再扩大到同类型对象。
- 处理后重新生成报告，比较去重前后的唯一对象数，而不是只看总数是否变化。
如果处理后报告页数没有下降，先别急着重复操作。合理解释包括：报告有缓存未刷新、统计口径仍包含归档页、或去重只改了显示层而没有改计数层。请求量或抓取量归零也不能单独证明处理正确，它可能只是抓取被暂停或报告延迟。
什么情况下不该去重
多语言版本、多站点副本、有意保留的别名地址、以及作为独立对象存在的落地页，都属于不应合并的例外。判断依据是业务上是否需要独立维护这两条记录。如果两条记录需要分别编辑、分别设置权限或分别统计转化，就保留；如果只是同一内容的重复暴露，才合并或做规范化重定向。
最后，报告页数与实际对象数量不一致时，优先修正统计口径，再处理真实重复。口径没对齐就批量删除或合并，会把本来正常的对象误伤，后续恢复成本远高于先做一次集合比对。
