使用 Better Search Replace 清理 WordPress 文章中的 ChatGPT 跟踪参数

最近整理博客外部链接时，我发现部分链接可能带有下面这段跟踪参数：

?utm_source=chatgpt.com

例如：

https://bigmodel.cn/special_area?utm_source=chatgpt.com

这类参数通常不会影响页面访问，但会让链接显得冗长，也没有必要保留。因此，我准备使用 WordPress 的 Better Search Replace 插件，将文章中的 ?utm_source=chatgpt.com 批量替换为空。

不过，在实际操作过程中，我先遇到了请求处理失败的问题，随后又发现数据库中并没有匹配到需要替换的内容。

一、最初选择全部数据表，处理请求失败

我最初在 Better Search Replace 中填写了以下内容：

• 搜索：?utm_source=chatgpt.com
• 替换为：留空
• Run as dry run：勾选

为了确认整个数据库中是否存在这段参数，我还选择了几乎所有数据库表。

运行以后，插件没有返回搜索结果，而是提示：

处理请求时出错。尝试减少“最大页面大小”，或联系支持。

出现这个问题并不代表搜索内容填写错误，更可能是因为一次选择的数据表太多。

我的 WordPress 数据库中包含大量文章、文章元数据、Yoast SEO 索引以及其他插件数据。其中：

• wp_posts 约为 357.52 MB；
• wp_postmeta 约为 180.56 MB；
• 还包含评论、分类、用户、Yoast SEO 等大量数据表。

一次扫描全部数据表，会明显增加 PHP、数据库和服务器的处理压力，也更容易触发超时或者请求大小限制。

二、文章内容主要保存在 wp_posts 表中

这次的目标只是清理博客文章内容中的跟踪参数，因此没有必要扫描全部数据库表。

WordPress 的文章正文、标题、摘要、页面、修订版本等内容，主要保存在 wp_posts 表中。

因此，我重新运行 Better Search Replace，并且只选择：

wp_posts

其他设置保持不变：

• 搜索：?utm_source=chatgpt.com
• 替换为：留空
• Case-Insensitive：不勾选
• Replace GUIDs：不勾选
• Run as dry run：继续勾选

这里必须继续保留 Run as dry run。

预演模式只会检查数据库中能够匹配多少处内容，不会真正修改数据库。确认结果没有问题以后，再取消勾选并执行正式替换，会更加安全。

三、只选择 wp_posts 后，预演成功完成

重新运行以后，Better Search Replace 不再出现请求处理错误，并成功返回了预演结果：

DRY RUN: 1 tables were searched, 0 cells were found that need to be updated, and 0 changes were made.

也就是：

• 搜索了 1 个数据表；
• 找到 0 个需要更新的单元格；
• 实际修改 0 处。

这说明只选择 wp_posts 的处理方式是可行的，之前的错误确实与扫描的数据表范围过大有关。

不过，本次搜索并没有找到完全匹配的 ?utm_source=chatgpt.com。

由于预演结果为 0，因此没有必要取消 Run as dry run 后再次执行正式替换。即使正式运行，也不会修改任何内容。

四、为什么没有搜索到匹配内容

数据库中没有搜索到这段参数，可能有几种原因。

1. 历史文章中的参数已经被清理

我在后续整理博客时，已经开始主动删除外部链接中的跟踪参数。

因此，原本带有 ?utm_source=chatgpt.com 的链接，可能已经在编辑文章时被修改为干净链接。

例如：

https://bigmodel.cn/special_area

2. 参数不是链接中的第一个查询参数

当 utm_source 是链接中的第一个参数时，通常会写成：

?utm_source=chatgpt.com

但如果前面已经存在其他查询参数，则可能写成：

&utm_source=chatgpt.com

在 WordPress 的 HTML 内容中，还可能保存为：

&utm_source=chatgpt.com

这几种形式并不等同于 ?utm_source=chatgpt.com，因此本次精确搜索不会匹配到它们。

3. 实际链接使用了其他来源参数

部分链接也可能带有其他跟踪参数，例如：

• utm_medium
• utm_campaign
• utm_content
• utm_term

只搜索 utm_source=chatgpt.com，不会发现其他类型的参数。

五、是否应该直接搜索 utm_source=chatgpt.com

为了扩大匹配范围，也可以尝试搜索：

utm_source=chatgpt.com

这样无论参数前面是 ?、& 还是 &，都可能被搜索出来。

不过，不建议直接将这段内容批量替换为空。

例如，原始链接是：

https://example.com/?id=123&utm_source=chatgpt.com

只删除 utm_source=chatgpt.com 后，链接可能变成：

https://example.com/?id=123&

虽然多数情况下仍然可以访问，但结尾会留下多余的 &。

如果数据库中确实存在不同形式的参数，更稳妥的方式是分别预演：

• ?utm_source=chatgpt.com
• &utm_source=chatgpt.com
• &utm_source=chatgpt.com

确认每一种形式的匹配数量和所在内容后，再决定是否分别替换。

六、使用 Better Search Replace 时需要注意什么

1. 先备份数据库

Better Search Replace 会直接修改数据库。

即使只是删除一个简单参数，也应该先通过 UpdraftPlus、WP-CLI 或服务器管理工具创建数据库备份。

2. 第一次必须使用预演模式

先勾选 Run as dry run，查看：

• 搜索了多少个表；
• 找到了多少个单元格；
• 哪些数据库字段存在匹配内容。

确认结果合理后，才取消预演并执行正式替换。

3. 不要无目的地选择全部数据表

如果目标是修改文章正文，通常只需要检查 wp_posts。

只有在明确知道链接可能保存在文章元数据、插件设置或其他位置时，才需要继续检查：

• wp_postmeta
• wp_options
• 其他相关插件数据表

一次选择全部数据表，不但处理时间更长，也更容易出现超时和服务器错误。

4. 不要勾选 Replace GUIDs

文章的 guid 字段主要用于标识内容，不应该因为普通链接清理而修改。

因此，本次操作不需要勾选 Replace GUIDs。

5. 预演结果为 0 时不要继续正式替换

预演已经显示没有匹配内容，正式运行也不会产生变化。

此时应该检查搜索字符串是否准确，或者继续预演其他可能存在的参数形式，而不是反复执行正式替换。

七、这次操作的最终结果

这次使用 Better Search Replace 清理 ?utm_source=chatgpt.com，最终没有真正修改数据库。

但是，通过这次测试可以确认：

1. 扫描全部数据库表容易触发请求处理错误；
2. 只处理文章内容时，选择 wp_posts 即可；
3. 正式替换前应该始终先运行预演；
4. 本次数据库中没有发现完全匹配的 ?utm_source=chatgpt.com；
5. 预演结果为 0，因此不需要继续执行正式替换。

以后整理博客内容时，我会继续使用干净的外部链接。

对于 utm_source、utm_medium、utm_campaign 等跟踪参数，只要不是页面正常访问或功能所必需，就会在发布文章前直接删除，避免以后再通过数据库批量清理。