今天继续对 WordPress 生产站进行一次比较系统的整理。
这一次并不是为了追求后台所有项目全部变成绿色，而是借助 WordPress 的“站点健康”页面，把一些已经长期遗留下来的主题、插件和配置重新检查一遍。
最开始进入“工具 → 站点健康”时，后台一共显示了 6 个“推荐的改进”。
其中包括：
- 您应该移除未启用的插件
- 您应该移除未启用的主题
- 陈旧的 SQL 服务器
- 您的站点已设置为将错误日志保存到可公开读写的文件中
- 评论分成多个页面
- 您的文章和页面的链接中没有您的文章名
这些项目并不意味着网站已经出现故障。
WordPress 自己也把它们归类为“推荐的改进”，而不是严重问题。因此这一次的原则一直是：
能明确判断已经没有用途的，就清理；涉及生产架构、历史 URL 或数据库大版本的，则不为了消除提示而强行修改。
一、先清理已经不用的旧主题
当前站点正式使用的是 Twenty Twenty-Five。
服务器上此前还保留了：
- Twenty Fifteen
- Twenty Twenty-One
- Twenty Twenty-Two
- Twenty Twenty-Three
- Twenty Twenty-Four
通常 WordPress 会建议保留一个备用默认主题，不过对当前这个站点来说意义不大。
Twenty Twenty-Five 已经通过站点编辑器进行了大量布局和样式调整，即便当前主题真的出现异常，也不会直接在生产环境中临时切换到另一个默认主题继续运行。
因此最终决定只保留 Twenty Twenty-Five，把另外 5 个已经不用的主题全部删除。
执行：
wp --allow-root theme delete twentyfifteen twentytwentyfour twentytwentyone twentytwentythree twentytwentytwo最终：
Success: Deleted 5 of 5 themes.清理后，服务器中只剩当前实际启用的 Twenty Twenty-Five。
二、逐个判断未使用插件，而不是看到“未启用”就全部删除
插件的处理比主题复杂得多。
有些插件虽然当前处于停用状态，但以后还可能重新使用；另一些插件虽然处于启用状态，却可能已经没有实际价值。
因此这一次没有简单按照“启用”和“停用”来判断，而是逐个确认用途。
最终删除的插件包括：
SyntaxHighlighter Evolved
GoLang Brush for SyntaxHighlighter Evolved
WP-Cumulus
Ad Inserter
Classic Editor
Focus Mode – Reading Experience Optimizer
Kill 429
Microsoft Clarity
Nimble Page Builder
AI Provider for Google
Secure SVG
Disable Google Fonts一共清理了 12 个插件。
其中有几个比较值得单独记录。
三、SyntaxHighlighter Evolved 正式退出
SyntaxHighlighter Evolved 过去长期承担博客代码高亮功能。
不过现在站点已经迁移到 Code Block Pro。
旧文章的代码块也已经经过此前一系列迁移和兼容处理，因此 SyntaxHighlighter Evolved 和对应的 GoLang Brush 都没有继续保留的必要。
这两个插件与 WP-Cumulus 一起删除：
wp --allow-root plugin delete syntaxhighlighter golang-brush-for-syntaxhighlighter-evolved wp-cumulus结果：
Success: Deleted 3 of 3 plugins.这也意味着此前持续很长时间的 SyntaxHighlighter Evolved 清理工作终于正式收尾。
四、删除已经没有使用场景的后台工具
随后又删除了：
Ad Inserter
Classic Editor
Focus Mode – Reading Experience Optimizer
Kill 429
Microsoft Clarity
Nimble Page Builder这些插件要么对应过去已经结束的功能，要么现在的站点架构已经不再使用。
执行完成后：
Success: Deleted 6 of 6 plugins.另外，AI Provider for Google 与 Secure SVG 也已经没有继续启用的必要。
因此先停用，再删除：
wp --allow-root plugin deactivate ai-provider-for-google secure-svg
wp --allow-root plugin delete ai-provider-for-google secure-svg五、Disable Google Fonts 也可以退出了
这个插件比较特殊。
它最初存在的原因，是避免页面加载 Google Fonts。
对于主要访问来源位于中国大陆的网站来说，直接依赖 Google Fonts 一直存在加载失败或延迟的问题。
但是现在重新检查前台后发现，即使临时停用 Disable Google Fonts，页面也没有实际加载：
fonts.googleapis.com
fonts.gstatic.com也就是说，当前 Twenty Twenty-Five 和现有站点配置本身就已经没有依赖远程 Google Fonts。
因此这个插件继续存在已经没有实际意义。
最终也将其删除。
以后即便重新使用特殊字体，我仍然更倾向于使用 WordPress 字体库或本地托管，而不是重新依赖远程 Google Fonts。
六、有些插件虽然暂时不用，但仍然选择保留
这次并没有为了让插件列表变得更短，就把所有工具全部删除。
例如 Better Search Replace 偶尔仍然会用于生产维护，因此继续保留。
Regenerate Thumbnails 同样保留。
不过这次也顺便确认了一件事情：
Regenerate Thumbnails 并不是图片压缩插件。
它的主要功能是按照 WordPress 当前注册的图片尺寸重新生成缩略图，并不会自动把几 MB 的原始 JPG、PNG 压缩成更小的文件。
因此，虽然站点当前确实存在一些几 MB 的历史原图，但仅仅为了提升网站速度，没有必要今天直接运行一次全站 Regenerate Thumbnails。
尤其目前首页已经正常输出响应式图片和 srcset，浏览器并不是简单地在所有位置直接加载原始大图。
这一项因此继续保留工具，但暂不执行批量重新生成。
七、WP-PageNavi 最终确认仍然在使用
WP-PageNavi 一开始也是一个比较难判断的插件。
主题和 MU Plugin 中没有直接找到明显调用，因此一度怀疑它可能已经没有用途。
但直接检查生产首页和第二页后，可以看到实际前台 HTML 中仍然存在：
page-numbers
page-numbers current
page-numbers dots
wp-pagenavi因此可以确认：
WP-PageNavi 现在仍然参与生产站前台分页。
这一插件继续保留。
八、Cloudflare 插件暂时保持停用
清理完成后，普通插件中只剩一个停用插件：
cloudflareCloudflare 插件现在没有启用，主要是因为站点已经拆分出了 www、en、admin 等不同域名，缓存和 CDN 架构比以前复杂得多。
目前没有必要为了让站点健康少显示一条提醒，就强行重新启用。
同样也不急着删除。
因此现在 WordPress 仍然会提示：
您应该移除未启用的插件这是一个明确知道原因并主动接受的提示。
九、顺便把 Akismet 更新到最新版
完成插件整理后重新查看插件列表，发现 Akismet 是唯一存在可用更新的插件：
akismet 5.7.1 available因此执行：
wp --allow-root plugin update akismet升级结果：
插件升级成功。
Success: Updated 1 of 1 plugins.
akismet 5.7.1 → 5.7.2至此，当前 20 个启用插件都已经是最新状态。
十、关闭已经没有必要长期开启的 WordPress 调试日志
站点健康中的另一项安全提示是：
您的站点已设置为将错误日志保存到可公开读写的文件中检查当前配置：
wp --allow-root eval 'foreach (["WP_DEBUG","WP_DEBUG_LOG","WP_DEBUG_DISPLAY","SCRIPT_DEBUG","SAVEQUERIES"] as $c) { echo $c."=".(defined($c) ? var_export(constant($c), true) : "未定义").PHP_EOL; }'得到：
WP_DEBUG=true
WP_DEBUG_LOG='/data/wwwroot/www.shuijingwanwq.com/wp-content/slytranslate-debug.log'
WP_DEBUG_DISPLAY=false
SCRIPT_DEBUG=false
SAVEQUERIES=未定义进一步检查 wp-config.php：
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', __DIR__ . '/wp-content/slytranslate-debug.log' );
define( 'WP_DEBUG_DISPLAY', false );这个日志此前用于 SlyTranslate 和 WordPress 翻译链路排查。
但是现在相关问题已经基本稳定，继续让生产站长期保持 WP_DEBUG=true 已经没有必要。
因此先备份 wp-config.php，然后调整为：
WP_DEBUG=false
WP_DEBUG_LOG=false
WP_DEBUG_DISPLAY=false再次检查后：
WP_DEBUG=false
WP_DEBUG_LOG=false
WP_DEBUG_DISPLAY=false这一项站点健康提示随后正常消失。
十一、重新评估评论功能是否还有必要继续开放
站点健康中还有一项来自 Yoast SEO 的提示：
评论分成多个页面检查当前配置：
page_comments = 1
comments_per_page = 50
default_comments_page = newest也就是说，站点此前确实启用了评论分页。
不过继续往下排查时，我开始重新考虑一个更根本的问题：
现在这个站点还有没有继续开放文章评论的必要？
目前网站已经使用页面缓存，同时前面还有 CDN。
评论本身属于需要即时写入和即时展示的动态功能，而页面缓存和 CDN 的设计目标恰恰是尽可能减少回源并长期复用页面。
评论提交以后，如果页面缓存或 CDN 仍然保存旧版本，访客很可能看不到刚刚提交的内容。
当然可以继续为评论单独设计缓存清理机制，但这又意味着需要额外维护一套缓存失效链路。
而目前我已经保留 Contact Form 7，后续也计划从 go-dev 等项目页面提供一个更容易访问的联系入口。
因此评论功能本身的必要性已经明显降低。
十二、最近所谓的“评论”，实际上全部都是 Pingback
为了避免误删真实的读者互动，先检查最近 20 条已经批准的评论。
最开始看起来数量还不少，而且全部发生在当天。
但是作者名称非常奇怪，几乎全部都是文章标题。
进一步把 comment_type 加入检查以后，结果非常清楚：
pingback
pingback
pingback
pingback
...最近 20 条全部都是 Pingback。
也就是说，这些并不是真实访客在文章下面留下的评论。
这进一步坚定了关闭评论功能的决定。
十三、关闭所有文章和页面的评论与 Pingback/Trackback
最终同时调整了默认配置和现有内容。
新的文章和页面默认关闭：
default_comment_status = closed
default_ping_status = closed同时对已有文章和页面批量关闭：
comment_status = closed
ping_status = closed执行结果：
已关闭评论及 Pingback/Trackback 的文章/页面数量：2909这里特别重要的一点是：
只是关闭入口，没有删除任何历史评论数据。
随后再次验证：
default_comment_status=closed
default_ping_status=closed
仍开放评论的文章/页面=0
仍开放 Pingback/Trackback 的文章/页面=0因此现在的状态非常明确：
新文章不会默认开放评论，已有文章也全部关闭，Pingback 和 Trackback 同样全部关闭，但数据库中的历史评论仍然完整保留。
十四、同时关闭评论分页
既然评论入口已经整体关闭，那么继续保留评论分页设置也没有意义。
执行：
wp --allow-root option update page_comments 0结果：
Success: Updated 'page_comments' option.Yoast SEO 的：
评论分成多个页面随后也从站点健康中消失。
十五、没有为了立即生效而清空全站缓存
这里还有一个值得记录的生产运维细节。
评论关闭以后，理论上可以通过清空 W3 Total Cache，让所有页面立即重新生成。
但我最终没有这么做。
原因是这个站点已经有大量历史页面。
如果直接执行全量缓存清理，会让大量页面在短时间内重新回源和生成，再叠加 CDN 缓存失效，很容易形成一次明显的 CPU 峰值。
此前服务器本身就有 CPU 告警机制，因此完全没有必要为了让一个已经从数据库层面关闭的评论入口立刻消失，而主动制造这种负载。
所以这里继续采用：
让旧页面缓存自然过期。
这是今天整个整理过程中一个很重要的原则：
生产环境里，“立即看到变化”并不总比“平稳地自然完成变化”更重要。
十六、MySQL 5.7 的提示暂时不处理
站点健康还有一项：
陈旧的 SQL 服务器检查数据库版本：
wp --allow-root eval 'global $wpdb; echo "数据库服务器版本：".$wpdb->db_version().PHP_EOL;'结果：
数据库服务器版本：5.7.32当前使用的是阿里云 RDS。
因此这已经不是修改 WordPress 配置就能解决的问题，而是涉及 RDS 数据库大版本升级。
MySQL 5.7 确实已经比较老，但数据库升级需要考虑：
- WordPress 与插件兼容性
- RDS 升级路径
- 数据库备份
- 回滚方案
- 升级窗口
- 生产业务影响
没有必要为了让 Site Health 少一条黄色提醒，今天临时推进数据库大版本升级。
因此这一项明确记录下来，但暂时不处理。
十七、固定链接同样不为了 SEO 提示而修改
Yoast SEO 剩下的另一条提示是：
您的文章和页面的链接中没有您的文章名检查当前 WordPress 固定链接：
wp --allow-root option get permalink_structure结果：
/%year%/%monthnum%/%day%/%post_id%/例如现在文章 URL 会类似于：
/2026/08/19/xxxxx/而 Yoast 更推荐：
/%postname%/或者至少在 URL 中包含 %postname%。
但对于一个已经运行多年、拥有大量历史文章和搜索引擎索引的网站来说，这个建议不能机械执行。
如果现在修改固定链接结构，将涉及：
- 大量历史 URL 改变
- 301 重定向
- Google、Bing 等搜索引擎重新处理
- 已存在的外部链接
- 社交平台历史链接
- WordPress 内部链接
- CDN 缓存
- SEO 波动
相比之下，“URL 中包含文章名”带来的理论 SEO 收益远远不足以覆盖一次全站 URL 迁移的风险。
所以这一项也明确选择：
保持现有固定链接结构，不修改。
十八、最终从 6 个推荐项减少到了 3 个
完成以上整理以后，再次进入 WordPress 站点健康。
原来的 6 项已经减少到 3 项。
已经解决的是：
您应该移除未启用的主题
您的站点已设置为将错误日志保存到可公开读写的文件中
评论分成多个页面现在剩下：
您应该移除未启用的插件
陈旧的 SQL 服务器
您的文章和页面的链接中没有您的文章名而这 3 项目前全部属于有意识地保留。
第一个，是暂时保留处于停用状态的 Cloudflare 插件。
第二个，是当前阿里云 RDS 仍然运行 MySQL 5.7.32，数据库大版本升级以后再单独规划。
第三个，是为了维护多年积累的历史 URL 稳定性，不修改现有固定链接结构。
因此这一次最终没有继续追求：
0 个推荐的改进而是停在：
3 个推荐的改进十九、站点健康不是“必须清零”的任务列表
经过这一次整理，我对 WordPress Site Health 的理解也更加明确。
它更像是一份：
需要人工判断的检查清单。
有些提示非常值得处理，例如：
- 已废弃的主题
- 已废弃插件
- 长期开启的生产调试日志
- 已经不再需要的评论分页
但也有一些提示只能作为建议，例如：
- 数据库大版本
- 固定链接设计
- 特殊用途下暂时停用的插件
如果单纯为了让后台显示“完美”，去升级数据库、改变全站 URL，甚至破坏现有生产架构，反而本末倒置。
所以今天最终得到的不是一个“所有黄色提示全部消失”的后台。
而是一个更清楚的状态：
哪些问题已经真正解决，哪些提示是明确评估以后主动接受的。
对长期运行的生产 WordPress 站点来说，我认为后者比单纯追求一个漂亮的 Site Health 数字更重要。
需要长期技术维护或远程问题排查？
我是拥有 15+ 年经验的 PHP / Go 后端工程师，长期关注已有系统维护、Bug 修复、性能优化、服务器排查、WordPress 网站维护和小功能迭代。
如果你的项目遇到以下情况，可以先从一次小问题排查开始合作：
- ✅ PHP / Laravel / Yii2 老项目无人维护
- ✅ Go / Gin 后端接口需要排查或优化
- ✅ WordPress 网站访问慢、报错或插件冲突
- ✅ Nginx / MySQL / Redis / Linux 服务器异常
- ✅ CDN / Cloudflare / DNS / HTTPS 配置问题
- ✅ 需要长期远程技术支持或兼职维护
更多介绍请查看：关于我 & 合作
微信：13980074657
邮箱：shuijingwanwq@gmail.com
Telegram：@shuijingwan
GitHub：https://github.com/shuijingwan