本文约 2,754 字，预计阅读 7 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：批量导入的内容，标题全是一个模子
标题重复最常见的来源是批量导入：采集的文章、按模板生成的页面、产品变体页、以及被反复复制的”教程（一）（二）（三）”。站长往往要等收录异常才察觉——新发的文章不收录，或者搜索结果里出现的总是同一个旧页面。百度的处理逻辑是：标题与内容高度相似的页面只保留最有代表性的一个，其余的进入低优先级，实际上等于不收录。
原理分析：什么程度的重复会被处理
| 重复类型 | 百度处理方式 | 是否需处理 |
|---|---|---|
| 标题完全相同、内容不同 | 保留其一，其余降权 | 必须改 |
| 标题相同、内容也高度相似 | 判定为重复页面 | 合并或 301 |
| 标题高度相似（差一两个字） | 视为同类，分散权重 | 建议改 |
| 标题不同但内容重复 | 按内容相似度处理 | 需合并 |
| 分类/标签页标题模板化 | 低质量聚合页 | 考虑 noindex |
需要说明的是，百度不会因为你有两个页面标题相同就惩罚整站。影响是局部的：这组重复页面里只有一个能拿到好的展现。所以排查的价值在于”把被埋没的页面救出来”，而不是避免什么惩罚。
保姆级实操
步骤 1：先用 SQL 把重复标题全部揪出来。 后台肉眼扫不现实，直接查数据库最快：
-- 找出已发布内容中重复出现的标题及其数量
SELECT post_title, COUNT(*) AS cnt,
GROUP_CONCAT(ID ORDER BY ID SEPARATOR ',') AS ids,
MIN(post_date) AS first_date,
MAX(post_date) AS last_date
FROM wp_posts
WHERE post_type = 'post'
AND post_status = 'publish'
GROUP BY post_title
HAVING cnt > 1
ORDER BY cnt DESC, last_date DESC
LIMIT 100;
步骤 2：进一步找”高度相似”的标题。 完全相同只是冰山一角，去掉序号与标点后的重复更常见：
-- 去掉常见序号与标点后比较，找出近似重复标题
SELECT REGEXP_REPLACE(
REGEXP_REPLACE(post_title, '[（(]?[0-9一二三四五六七八九十]+[)）]?', ''),
'[[:space:][:punct:]]', ''
) AS norm_title,
COUNT(*) AS cnt,
GROUP_CONCAT(post_title SEPARATOR ' || ') AS variants
FROM wp_posts
WHERE post_type = 'post'
AND post_status = 'publish'
GROUP BY norm_title
HAVING cnt > 1
ORDER BY cnt DESC
LIMIT 50;
注：REGEXP_REPLACE 需要 MySQL 8.0 及以上。低版本可用 REPLACE 嵌套做粗筛，或把标题导出后用脚本处理。
步骤 3：分类决策——合并还是改写。 拿到列表后逐组判断：
- 内容重复度高（>70% 相似）→ 保留质量最好的一篇，其余 301 到它；
- 内容不同但标题相同 → 改写标题，让每组标题都能独立表意；
- 都是薄内容且无流量 → 直接删除或
noindex。
步骤 4：批量改写标题。 少量用后台改，量大用 WP-CLI：
# 按 ID 批量更新标题（先备份数据库）
wp db export before-title-fix.sql
# 单条更新，标题里补上区分维度
wp post update 1234 --post_title="WordPress 缓存插件对比：WP Rocket 与 W3 Total Cache" --quiet
# 批量：从 ids.txt 读取，按规则追加后缀
while read -r id; do
old=$(wp post get "$id" --field=post_title)
new="${old}（进阶篇）"
wp post update "$id" --post_title="$new" --quiet
echo "$id 已改：$old -> $new"
done < ids.txt
步骤 5：处理合并后的 URL。 被合并的页面不要直接删除就完事，用 301 指向保留页。WordPress 里可以用重定向插件管理，或在 nginx 层配置（写法见 WordPress 301 重定向设置）。删掉不重定向等于制造一批死链。
步骤 6：清理源头。 排查为什么会重复：是导入脚本没做去重、还是编辑流程没有标题查重环节。在发布流程里加一步”标题是否已存在”的检查，比事后治理便宜得多。
步骤 7：复查收录。 改完两周后，搜索被改写的标题，确认新标题已被百度采用、页面能正常展现。
常见踩坑
- 只改标题不改内容，两个页面内容仍高度相似，问题没解决。
- 合并页面时直接删除，不做 301，制造死链并浪费已有外链。
- 用 SQL 直接 UPDATE 改标题，绕过 WordPress 的缓存与钩子，导致 sitemap 里的 lastmod 不更新。
- 批量改标题前没备份，改错无法回滚。
- 一次性改上千个标题，触发百度对站点的大规模重判，短期波动剧烈。
- 案例： 某站从旧系统导入 800 余篇内容，导入脚本给每篇标题都加了同一个站点后缀，导致约 120 组标题重复。站长用 SQL 定位后分三批处理，每批间隔一周：先合并内容重复的（约 40 组），再改写标题相同的（约 50 组），其余 noindex。两个月后这组页面的收录率从 22% 升到 68%。
- 忽略标签页与分类页的模板化标题重复，只处理文章。
- 改标题后没有主动推送，等待自然抓取，周期拉长。
总结
排查流程是固定的：SQL 找完全相同 → 归一化后找近似 → 按内容相似度决定合并还是改写 → 合并页做 301 → 改完主动推送 → 在发布流程里加查重。判断标准只有一条：如果把你站上这篇的标题单独放到结果页，用户能不能看出它和另一篇的区别？看不出来就得改。改标题的写法规则见 百度搜索结果点击率优化。
