name: wp-site-health-auditordescription: “Turns a WordPress Site Health report into a risk-tiered, backup-first fix plan with exact WP-CLI/PHP snippets. Use for site health, recommended improvements, or critical issue reports.”category: developmentrisk: criticalsource: selfsource_type: selfdate_added: “2026-07-03”author: whoisabhishekadhikaritags: [wordpress, site-health, wp-cli, seo, performance, security, hardening]tools: [claude, cursor, codex, gemini]WP Site Health 审计器何时使用本技能用户粘贴 WordPress Site Health 报告工具 Site Health以文本或截图形式用户粘贴原始 Site Health 调试信息工具 Site Health 信息并询问哪里有问题用户提到 WordPress 站点的站点健康、“建议改进或严重问题”用户要求基于该界面清理、加固或加速 WP 安装将 WordPress Site Health 报告严重问题 / 建议改进 / 已通过测试转化为按优先级、风险分级排列的修复计划——然后执行安全修复并将其余部分以精确的命令或代码形式移交。⚠️ 安全——在接触任何文件之前请阅读本技能会编辑wp-config.php、.htaccess和php.ini等效设置并删除插件和主题。三者都距离白屏死机或上传路径损坏只有一次错误编辑之遥。即使是一行更改即使用户很着急也绝不要跳过本节。在任何编辑或删除之前按此顺序在 Web 根目录之外备份你要接触的特定文件而不只是某处有备份umask 077 backup_dir../wp-site-health-backups/$(date %Y%m%d-%H%M%S) mkdir -p $backup_dir cp -p wp-config.php $backup_dir/wp-config.php cp -p .htaccess $backup_dir/.htaccess如果没有 shell 访问权限先告诉用户通过 SFTP/主机文件管理器下载当前文件在他们确认已拥有该文件之前不要继续。在删除任何插件或主题或运行wp search-replace之前确认存在完整的站点/数据库备份。如果用户没有备份且有备份插件处于活动状态UpdraftPlus 等先触发备份wp updraftplus backup或该插件自己的 WP-CLI 命令或让他们点击立即备份并等待确认后再继续。绝不未经--dry-run就运行wp search-replace并且在进行真实运行之前始终向用户展示 dry-run 输出。此命令会就地重写数据库——错误的模式可能会损坏它接触的每个表中的序列化数据。编辑任何 PHP 文件后在重新加载站点之前先 lintphp -l wp-config.php对于.htaccess更改可用时运行apachectl configtest或立即检查站点。wp-config.php中的语法错误会立即导致整个站点宕机。不要为了省一步而跳过 lint 检查。一次只改一件事然后在做下一个更改之前验证站点仍然可以加载首页 wp-admin。不要将多个第 2 级文件编辑批量到一次通过中——如果出了问题你要知道是哪个更改造成的。每次编辑都向用户提供精确的回滚命令cp ../wp-site-health-backups/timestamp/wp-config.php wp-config.php即使没有出错也要说明这一点——它只占一行却能在以后挽救一位惊慌的用户。如果用户说直接做吧跳过备份——仍然在编辑序列中静默创建备份并告诉他们你做了。完全拒绝跳过步骤 1 或步骤 4无论紧急程度如何这两步都是不可协商的因为失败模式损坏的wp-config.php、站点宕机比备份花费的十秒钟糟糕得多。概述Site Health 界面是诊断性的而非指示性的。它告诉站点所有者存在问题例如你应该使用持久对象缓存但不告诉如何修复而且它把一键安全停用插件的项目与需要主机级更改php.ini、对象缓存后端或纯信息性SQL Server 版本——无需操作的项目混在一起。本技能安全地解决这些问题。阶段 1 — 解析报告输入通常是以下之一从工具 Site Health状态选项卡复制的纯文本从工具 Site Health 信息调试数据导出复制的纯文本状态选项卡的截图WP-CLI 输出wp site-health check不是核心命令提前说明这一点不要凭空编造一个——见阶段 4精确提取三个类别使用 WordPress 的标签严重问题红色——始终先修复始终在接触前确认。建议改进黄色——实际工作的主体按下面的风险级别分类。已通过测试绿色——跳过。除非用户要求不要修复或重新验证已通过的测试。不要给绿色项目编造问题——一个常见的失败模式是把SQL Server 已是最新当作需要处理的事情。它不是。如果报告是截图在分类之前逐字转写项目标题 类别标签安全/性能/SEO/隐私——不要改写 WordPress 生成的标题它用于阶段 3 中的修复查找。如果没有粘贴报告而用户只是说审计我的站点健康请他们粘贴状态选项卡文本最快而不是猜测——Site Health 结果是特定于主机和配置的猜测会浪费一轮对话。阶段 2 — 风险分级分类在接触任何东西之前将每个未通过的项目归类到三个级别之一。对于第 1 级数量为 3 项以上的任何情况先将此分类表展示给用户——不要静默开始停用插件。第 1 级 — 安全、可逆、可在 wp-admin 或通过 WP-CLI 自动修复无数据丢失风险、无停机、完全可逆。在删除任何内容之前仍按安全部分备份。用户确认项目列表后直接修复。移除不活动的插件/主题它们没有运行停用已经发生——这只是删除死代码在生产环境中关闭WP_DEBUG显示WP_DEBUG_DISPLAY如果用户仍想记录日志则不是WP_DEBUG本身启用搜索引擎索引 / 修复 robots 可见性开关将站点副标题从又一个 WordPress 站点更新第 2 级 — 需要主机/服务器级访问 — Claude 起草更改用户或主机应用无法纯粹从 wp-admin 修复需要 php.ini、.htaccess、wp-config.php 或托管面板访问。起草精确的片段说明它的位置提醒用户上面的备份 lint 步骤并标记可能需要服务器重启或主机支持工单。固定链接结构更改迁移——没有重定向现有 URL 会损坏应用前需要重定向计划和 CDN/缓存刷新post_max_sizeupload_max_filesize不匹配持久对象缓存不可用Redis/Memcached未检测到页面缓存PHP 版本/模块更改HTTPS/SSL 配置由防火墙或安全插件阻止导致的 Loopback/REST API 失败第 3 级 — 信息性 / 取决于主机无修复存在或无需修复仅作为信息报告。不要尝试修复除非被直接要求也不要建议修复。已经是最新的 SQL Server 版本提示自动加载选项可接受类型的接近通过的信息已通过测试中已经绿色的任何内容阶段 3 — 按项目分类的修复配方将 WordPress 生成的项目标题不区分大小写的子串匹配即可匹配到下面的配方。下面的每个配方都假定已针对该文件遵循了安全部分。如果项目与这里的任何内容都不匹配明确说明而不是编造修复——Site Health 的项目集合会随 WP 核心版本变化此列表并非详尽无遗更完整的列表包括罕见项目见references/catalog.md。你应该移除不活动的插件/主题 — 第 1 级# 先确认存在完整站点备份安全步骤 2 wp plugin list --statusinactive --fieldname wp plugin delete plugin-slug wp theme list --statusinactive --fieldname wp theme delete theme-slug如果活动主题是子主题绝不删除活动主题的父主题。如果 Twenty Twenty-Five或当前默认核心主题是唯一的后备主题绝不删除它——WordPress 需要至少一个主题损坏时的后备即使不活动也建议保留一个捆绑的默认主题。删除前与用户确认确切的插件/主题名称——不活动不等于未使用某些插件有意保持不活动状态作为分阶段回滚。post_max_size 小于 upload_max_filesize — 第 2 级这会破坏大文件上传在达到文件大小限制之前POST 数据就被截断了。通过将post_max_size提升到 upload_max_filesize来修复通常为表单开销留出余量。在哪里设置选择主机支持的任一方式按偏好顺序主机控制面板 PHP 设置cPanel “选择 PHP 版本” 选项、Plesk 等——无需代码最安全的选择完全跳过文件备份步骤。php.ini如果用户有服务器访问权限——先备份cp php.ini php.ini.bak-timestampupload_max_filesize 64M post_max_size 128M.htaccess仅 Apache mod_php不用于 PHP-FPM/nginx——先备份php_value upload_max_filesize 64M php_value post_max_size 128M格式错误的.htaccess指令可能让整个站点 500。重新加载前可用时运行apachectl configtest或保存后立即检查线上站点。.user.iniCGI/FastCGI 主机不用于 mod_php——先备份在 WordPress根目录创建或编辑.user.iniupload_max_filesize 64M post_max_size 128M⚠️不要为这些指令在wp-config.php中使用ini_set()——upload_max_filesize和post_max_size是PHP_INI_PERDIR这意味着它们只能在请求开始之前设置php.ini、.htaccess、.user.ini。对两者的ini_set()调用都会静默失败使问题得不到修复。始终将post_max_size设置为严格大于upload_max_filesize。先确认当前值wp cli info不显示这些——检查phpinfo()或主机面板而不是假设默认值。你应该使用持久对象缓存 — 第 2 级需要在服务器级安装缓存后端Redis 或 Memcached——这不是仅靠插件就能凭空创造的东西。与用户的主机确认 Redis 或 Memcached 是否可用许多托管 WP 主机包含其一。如果可用安装 drop-in 客户端插件Redis Object Cache 或 WP RedisRedis或Memcached Object CacheMemcached。wp plugin install redis-cache --activate然后wp redis enable。这会在wp-content/中写入一个object-cache.phpdrop-in——确认没有覆盖现有的object-cache.php先用ls wp-content/object-cache.php检查如果存在启用前备份它。如果不可用这是托管层级限制——如实报告而不是试图伪造修复不要主动建议更换主机只标记为阻塞项。未检测到页面缓存 — 第 2 级检查主机是否提供服务器级页面缓存许多托管 WP 主机提供它可能已经在活动但没有报告 Site Health 查找的响应头——在安装冗余插件之前值得与主机确认。如果没有安装一个页面缓存插件不是整套插件栈——WP Super Cache、W3 Total Cache或主机推荐的。wp plugin install wp-super-cache --activate然后从其设置界面启用缓存跨缓存插件没有可靠的 WP-CLI 开关——将手动步骤标记给用户。避免堆叠两个缓存插件如果已有一个在活动但未被检测到在添加另一个之前先检查插件自己的状态页。某些缓存插件还会向.htaccess写入规则——在激活前按安全部分先备份它。你的站点未设置为输出调试信息 — 通常已通过如果失败 — 第 1 级先备份wp-config.php编辑后 lint// wp-config.phpdefine(WP_DEBUG,false);// set to true only while actively debuggingdefine(WP_DEBUG_DISPLAY,false);// never show errors to visitorsdefine(WP_DEBUG_LOG,true);// logs to wp-content/debug.log insteadREST API / loopback 请求 / 后台更新失败 — 第 2 级通常是安全插件、防火墙或.htaccess规则阻止了内部请求。步骤逐个暂时停用安全/防火墙插件每次之后重新检查 Site Health。检查主机级防火墙Cloudflare、Sucuri、主机 WAF没有阻止站点调用自身。如果失败项是后台更新验证wp-config.php没有错误地设置define(DISALLOW_FILE_MODS, true)。在移除/编辑该行之前备份。HTTPS 未完全生效 — 第 2 级wp option get siteurl wp option get home两者都必须是https://。还要检查混合内容内容/主题中硬编码的 http://。确认存在完整的数据库备份然后先 dry-run 再真正应用wp search-replace http://olddomain.com https://olddomain.com --dry-run只有在用户审查了 dry-run 输出并确认替换计数和匹配行看起来正确之后才移除--dry-run。阶段 4 — 不要编造的内容截至撰写本文时WordPress 核心中没有wp site-healthWP-CLI 命令——不要伪造一个。修复通过上面的特定命令应用而不是单次审计并修复的 CLI 调用。在用户或重新运行 Site Health确认之前不要声称修复已完成——服务器级更改第 2 级尤其可能因主机限制而静默应用失败。不要猜测 PHP/服务器值当前upload_max_filesize、缓存后端可用性等——询问或让用户检查phpinfo()/ 主机面板而不是假设存在常见的默认值。无论如何都不要跳过或走捷径安全部分包括这是一个小更改——文件损坏风险不会随编辑大小缩放wp-config.php中丢失一个分号与大型编辑一样致命。阶段 5 — 输出格式向用户提供分类表项目 | 类别 | 级别 | 一行修复摘要第 1 级修复直接执行删除前确认 备份展示前后对比第 2 级修复精确片段 确切位置 备份命令 lint/验证命令 回滚命令 说明可能需要主机重启或支持工单在用户确认站点仍可加载之前不要将这些标记为完成第 3 级 / 未识别项目每个一行仅信息性建议在第 1/2 级更改后重新运行 Site Health 以确认黄色项目清除。保持整个响应可快速扫描——这是清单不是文章。使用表格 上面的简短配方块而不是散文段落除非用户要求对特定项目进行更多解释。示例示例Site Health 报告你应该使用持久对象缓存分类 → 第 2 级需要服务器级 Redis/Memcached请用户与其主机确认 Redis 是否可用如果可用运行wp plugin install redis-cache --activate wp redis enable验证ls wp-content/object-cache.php存在重新运行 Site Health 以确认项目清除示例Site Health 报告你的站点未设置为输出调试信息分类 → 第 1 级安全可通过 wp-config.php 恢复备份wp-config.phpumask 077 backup_dir../wp-site-health-backups/$(date %Y%m%d-%H%M%S) mkdir -p $backup_dir cp -p wp-config.php $backup_dir/wp-config.php编辑并 lintdefine(WP_DEBUG,false);define(WP_DEBUG_DISPLAY,false);验证php -l wp-config.php通过确认站点首页 wp-admin 仍然加载最佳实践✅ 每次编辑前备份特定文件——cp只需几秒恢复一个死掉的站点需要数小时✅ 一次只改一件事并在每次更改之间验证站点加载✅ 编辑wp-config.php后、重新加载站点前始终运行php -l✅ 先使用--dry-run运行wp search-replace并向用户展示输出❌ 绝不在一次通过中批量处理多个第 2 级文件编辑——你不会知道哪个更改破坏了站点❌ 绝不跳过备份步骤即使是一行注释更改参考references/catalog.md— 较少见 Site Health 项目的扩展列表SEO 类别项目如 llms.txt生成、隐私项目、较罕见的安全项目带相同的级别分类用于包含上面未涵盖项目的报告。常见陷阱把每个黄色项目都当作可操作— 某些建议改进如持久对象缓存是主机级的可能无法修复。始终先按级别分类再行动。没有重定向计划就更改固定链接— 在已索引的站点上切换到文章名会破坏每个现有 URL。始终先规划 301 重定向。对上传限制使用ini_set()—upload_max_filesize和post_max_size是PHP_INI_PERDIRini_set()静默失败。改用php.ini、.htaccess或.user.ini。跳过wp search-replace的 dry-run— 错误的模式可能损坏序列化数据。未经--dry-run绝不运行它。安装两个缓存插件— 堆叠页面缓存插件会导致冲突和隐蔽 bug。如果已有一个在活动但未被检测到调试它而不是添加另一个。局限性自身无法对线上站点执行任何操作——每个 WP-CLI/PHP 片段都是为用户或其主机起草运行的本技能没有用户实际服务器的 shell 访问权限。无法验证当前的 PHP/服务器值上传限制、缓存后端可用性、HTTPS 状态——依赖用户检查phpinfo()或主机面板后报告的内容。不涵盖多站点特定的 Site Health 变体或 WooCommerce 特定的健康检查两者都会增加本技能配方列表不包含的额外项目。项目目录主文件 references/catalog.md反映的是 2026 年年中 WordPress 核心的Site Health 检查——项目标题/措辞会随核心版本变化因此未匹配的项目应报告为未匹配而不是强行套用最接近的配方。不替代完整的安全审计或入侵扫描——Site Health 标记的是配置卫生问题而不是站点已被入侵的迹象。相关技能security-hardening— 用于超越 Site Health 表面检查的更深入 WordPress 安全审计wp-performance— 用于 Site Health 标记解决后的针对性性能优化 wp-site-health-auditor - SKILL
name: wp-site-health-auditordescription: “Turns a WordPress Site Health report into a risk-tiered, backup-first fix plan with exact WP-CLI/PHP snippets. Use for site health, recommended improvements, or critical issue reports.”category: developmentrisk: criticalsource: selfsource_type: selfdate_added: “2026-07-03”author: whoisabhishekadhikaritags: [wordpress, site-health, wp-cli, seo, performance, security, hardening]tools: [claude, cursor, codex, gemini]WP Site Health 审计器何时使用本技能用户粘贴 WordPress Site Health 报告工具 Site Health以文本或截图形式用户粘贴原始 Site Health 调试信息工具 Site Health 信息并询问哪里有问题用户提到 WordPress 站点的站点健康、“建议改进或严重问题”用户要求基于该界面清理、加固或加速 WP 安装将 WordPress Site Health 报告严重问题 / 建议改进 / 已通过测试转化为按优先级、风险分级排列的修复计划——然后执行安全修复并将其余部分以精确的命令或代码形式移交。⚠️ 安全——在接触任何文件之前请阅读本技能会编辑wp-config.php、.htaccess和php.ini等效设置并删除插件和主题。三者都距离白屏死机或上传路径损坏只有一次错误编辑之遥。即使是一行更改即使用户很着急也绝不要跳过本节。在任何编辑或删除之前按此顺序在 Web 根目录之外备份你要接触的特定文件而不只是某处有备份umask 077 backup_dir../wp-site-health-backups/$(date %Y%m%d-%H%M%S) mkdir -p $backup_dir cp -p wp-config.php $backup_dir/wp-config.php cp -p .htaccess $backup_dir/.htaccess如果没有 shell 访问权限先告诉用户通过 SFTP/主机文件管理器下载当前文件在他们确认已拥有该文件之前不要继续。在删除任何插件或主题或运行wp search-replace之前确认存在完整的站点/数据库备份。如果用户没有备份且有备份插件处于活动状态UpdraftPlus 等先触发备份wp updraftplus backup或该插件自己的 WP-CLI 命令或让他们点击立即备份并等待确认后再继续。绝不未经--dry-run就运行wp search-replace并且在进行真实运行之前始终向用户展示 dry-run 输出。此命令会就地重写数据库——错误的模式可能会损坏它接触的每个表中的序列化数据。编辑任何 PHP 文件后在重新加载站点之前先 lintphp -l wp-config.php对于.htaccess更改可用时运行apachectl configtest或立即检查站点。wp-config.php中的语法错误会立即导致整个站点宕机。不要为了省一步而跳过 lint 检查。一次只改一件事然后在做下一个更改之前验证站点仍然可以加载首页 wp-admin。不要将多个第 2 级文件编辑批量到一次通过中——如果出了问题你要知道是哪个更改造成的。每次编辑都向用户提供精确的回滚命令cp ../wp-site-health-backups/timestamp/wp-config.php wp-config.php即使没有出错也要说明这一点——它只占一行却能在以后挽救一位惊慌的用户。如果用户说直接做吧跳过备份——仍然在编辑序列中静默创建备份并告诉他们你做了。完全拒绝跳过步骤 1 或步骤 4无论紧急程度如何这两步都是不可协商的因为失败模式损坏的wp-config.php、站点宕机比备份花费的十秒钟糟糕得多。概述Site Health 界面是诊断性的而非指示性的。它告诉站点所有者存在问题例如你应该使用持久对象缓存但不告诉如何修复而且它把一键安全停用插件的项目与需要主机级更改php.ini、对象缓存后端或纯信息性SQL Server 版本——无需操作的项目混在一起。本技能安全地解决这些问题。阶段 1 — 解析报告输入通常是以下之一从工具 Site Health状态选项卡复制的纯文本从工具 Site Health 信息调试数据导出复制的纯文本状态选项卡的截图WP-CLI 输出wp site-health check不是核心命令提前说明这一点不要凭空编造一个——见阶段 4精确提取三个类别使用 WordPress 的标签严重问题红色——始终先修复始终在接触前确认。建议改进黄色——实际工作的主体按下面的风险级别分类。已通过测试绿色——跳过。除非用户要求不要修复或重新验证已通过的测试。不要给绿色项目编造问题——一个常见的失败模式是把SQL Server 已是最新当作需要处理的事情。它不是。如果报告是截图在分类之前逐字转写项目标题 类别标签安全/性能/SEO/隐私——不要改写 WordPress 生成的标题它用于阶段 3 中的修复查找。如果没有粘贴报告而用户只是说审计我的站点健康请他们粘贴状态选项卡文本最快而不是猜测——Site Health 结果是特定于主机和配置的猜测会浪费一轮对话。阶段 2 — 风险分级分类在接触任何东西之前将每个未通过的项目归类到三个级别之一。对于第 1 级数量为 3 项以上的任何情况先将此分类表展示给用户——不要静默开始停用插件。第 1 级 — 安全、可逆、可在 wp-admin 或通过 WP-CLI 自动修复无数据丢失风险、无停机、完全可逆。在删除任何内容之前仍按安全部分备份。用户确认项目列表后直接修复。移除不活动的插件/主题它们没有运行停用已经发生——这只是删除死代码在生产环境中关闭WP_DEBUG显示WP_DEBUG_DISPLAY如果用户仍想记录日志则不是WP_DEBUG本身启用搜索引擎索引 / 修复 robots 可见性开关将站点副标题从又一个 WordPress 站点更新第 2 级 — 需要主机/服务器级访问 — Claude 起草更改用户或主机应用无法纯粹从 wp-admin 修复需要 php.ini、.htaccess、wp-config.php 或托管面板访问。起草精确的片段说明它的位置提醒用户上面的备份 lint 步骤并标记可能需要服务器重启或主机支持工单。固定链接结构更改迁移——没有重定向现有 URL 会损坏应用前需要重定向计划和 CDN/缓存刷新post_max_sizeupload_max_filesize不匹配持久对象缓存不可用Redis/Memcached未检测到页面缓存PHP 版本/模块更改HTTPS/SSL 配置由防火墙或安全插件阻止导致的 Loopback/REST API 失败第 3 级 — 信息性 / 取决于主机无修复存在或无需修复仅作为信息报告。不要尝试修复除非被直接要求也不要建议修复。已经是最新的 SQL Server 版本提示自动加载选项可接受类型的接近通过的信息已通过测试中已经绿色的任何内容阶段 3 — 按项目分类的修复配方将 WordPress 生成的项目标题不区分大小写的子串匹配即可匹配到下面的配方。下面的每个配方都假定已针对该文件遵循了安全部分。如果项目与这里的任何内容都不匹配明确说明而不是编造修复——Site Health 的项目集合会随 WP 核心版本变化此列表并非详尽无遗更完整的列表包括罕见项目见references/catalog.md。你应该移除不活动的插件/主题 — 第 1 级# 先确认存在完整站点备份安全步骤 2 wp plugin list --statusinactive --fieldname wp plugin delete plugin-slug wp theme list --statusinactive --fieldname wp theme delete theme-slug如果活动主题是子主题绝不删除活动主题的父主题。如果 Twenty Twenty-Five或当前默认核心主题是唯一的后备主题绝不删除它——WordPress 需要至少一个主题损坏时的后备即使不活动也建议保留一个捆绑的默认主题。删除前与用户确认确切的插件/主题名称——不活动不等于未使用某些插件有意保持不活动状态作为分阶段回滚。post_max_size 小于 upload_max_filesize — 第 2 级这会破坏大文件上传在达到文件大小限制之前POST 数据就被截断了。通过将post_max_size提升到 upload_max_filesize来修复通常为表单开销留出余量。在哪里设置选择主机支持的任一方式按偏好顺序主机控制面板 PHP 设置cPanel “选择 PHP 版本” 选项、Plesk 等——无需代码最安全的选择完全跳过文件备份步骤。php.ini如果用户有服务器访问权限——先备份cp php.ini php.ini.bak-timestampupload_max_filesize 64M post_max_size 128M.htaccess仅 Apache mod_php不用于 PHP-FPM/nginx——先备份php_value upload_max_filesize 64M php_value post_max_size 128M格式错误的.htaccess指令可能让整个站点 500。重新加载前可用时运行apachectl configtest或保存后立即检查线上站点。.user.iniCGI/FastCGI 主机不用于 mod_php——先备份在 WordPress根目录创建或编辑.user.iniupload_max_filesize 64M post_max_size 128M⚠️不要为这些指令在wp-config.php中使用ini_set()——upload_max_filesize和post_max_size是PHP_INI_PERDIR这意味着它们只能在请求开始之前设置php.ini、.htaccess、.user.ini。对两者的ini_set()调用都会静默失败使问题得不到修复。始终将post_max_size设置为严格大于upload_max_filesize。先确认当前值wp cli info不显示这些——检查phpinfo()或主机面板而不是假设默认值。你应该使用持久对象缓存 — 第 2 级需要在服务器级安装缓存后端Redis 或 Memcached——这不是仅靠插件就能凭空创造的东西。与用户的主机确认 Redis 或 Memcached 是否可用许多托管 WP 主机包含其一。如果可用安装 drop-in 客户端插件Redis Object Cache 或 WP RedisRedis或Memcached Object CacheMemcached。wp plugin install redis-cache --activate然后wp redis enable。这会在wp-content/中写入一个object-cache.phpdrop-in——确认没有覆盖现有的object-cache.php先用ls wp-content/object-cache.php检查如果存在启用前备份它。如果不可用这是托管层级限制——如实报告而不是试图伪造修复不要主动建议更换主机只标记为阻塞项。未检测到页面缓存 — 第 2 级检查主机是否提供服务器级页面缓存许多托管 WP 主机提供它可能已经在活动但没有报告 Site Health 查找的响应头——在安装冗余插件之前值得与主机确认。如果没有安装一个页面缓存插件不是整套插件栈——WP Super Cache、W3 Total Cache或主机推荐的。wp plugin install wp-super-cache --activate然后从其设置界面启用缓存跨缓存插件没有可靠的 WP-CLI 开关——将手动步骤标记给用户。避免堆叠两个缓存插件如果已有一个在活动但未被检测到在添加另一个之前先检查插件自己的状态页。某些缓存插件还会向.htaccess写入规则——在激活前按安全部分先备份它。你的站点未设置为输出调试信息 — 通常已通过如果失败 — 第 1 级先备份wp-config.php编辑后 lint// wp-config.phpdefine(WP_DEBUG,false);// set to true only while actively debuggingdefine(WP_DEBUG_DISPLAY,false);// never show errors to visitorsdefine(WP_DEBUG_LOG,true);// logs to wp-content/debug.log insteadREST API / loopback 请求 / 后台更新失败 — 第 2 级通常是安全插件、防火墙或.htaccess规则阻止了内部请求。步骤逐个暂时停用安全/防火墙插件每次之后重新检查 Site Health。检查主机级防火墙Cloudflare、Sucuri、主机 WAF没有阻止站点调用自身。如果失败项是后台更新验证wp-config.php没有错误地设置define(DISALLOW_FILE_MODS, true)。在移除/编辑该行之前备份。HTTPS 未完全生效 — 第 2 级wp option get siteurl wp option get home两者都必须是https://。还要检查混合内容内容/主题中硬编码的 http://。确认存在完整的数据库备份然后先 dry-run 再真正应用wp search-replace http://olddomain.com https://olddomain.com --dry-run只有在用户审查了 dry-run 输出并确认替换计数和匹配行看起来正确之后才移除--dry-run。阶段 4 — 不要编造的内容截至撰写本文时WordPress 核心中没有wp site-healthWP-CLI 命令——不要伪造一个。修复通过上面的特定命令应用而不是单次审计并修复的 CLI 调用。在用户或重新运行 Site Health确认之前不要声称修复已完成——服务器级更改第 2 级尤其可能因主机限制而静默应用失败。不要猜测 PHP/服务器值当前upload_max_filesize、缓存后端可用性等——询问或让用户检查phpinfo()/ 主机面板而不是假设存在常见的默认值。无论如何都不要跳过或走捷径安全部分包括这是一个小更改——文件损坏风险不会随编辑大小缩放wp-config.php中丢失一个分号与大型编辑一样致命。阶段 5 — 输出格式向用户提供分类表项目 | 类别 | 级别 | 一行修复摘要第 1 级修复直接执行删除前确认 备份展示前后对比第 2 级修复精确片段 确切位置 备份命令 lint/验证命令 回滚命令 说明可能需要主机重启或支持工单在用户确认站点仍可加载之前不要将这些标记为完成第 3 级 / 未识别项目每个一行仅信息性建议在第 1/2 级更改后重新运行 Site Health 以确认黄色项目清除。保持整个响应可快速扫描——这是清单不是文章。使用表格 上面的简短配方块而不是散文段落除非用户要求对特定项目进行更多解释。示例示例Site Health 报告你应该使用持久对象缓存分类 → 第 2 级需要服务器级 Redis/Memcached请用户与其主机确认 Redis 是否可用如果可用运行wp plugin install redis-cache --activate wp redis enable验证ls wp-content/object-cache.php存在重新运行 Site Health 以确认项目清除示例Site Health 报告你的站点未设置为输出调试信息分类 → 第 1 级安全可通过 wp-config.php 恢复备份wp-config.phpumask 077 backup_dir../wp-site-health-backups/$(date %Y%m%d-%H%M%S) mkdir -p $backup_dir cp -p wp-config.php $backup_dir/wp-config.php编辑并 lintdefine(WP_DEBUG,false);define(WP_DEBUG_DISPLAY,false);验证php -l wp-config.php通过确认站点首页 wp-admin 仍然加载最佳实践✅ 每次编辑前备份特定文件——cp只需几秒恢复一个死掉的站点需要数小时✅ 一次只改一件事并在每次更改之间验证站点加载✅ 编辑wp-config.php后、重新加载站点前始终运行php -l✅ 先使用--dry-run运行wp search-replace并向用户展示输出❌ 绝不在一次通过中批量处理多个第 2 级文件编辑——你不会知道哪个更改破坏了站点❌ 绝不跳过备份步骤即使是一行注释更改参考references/catalog.md— 较少见 Site Health 项目的扩展列表SEO 类别项目如 llms.txt生成、隐私项目、较罕见的安全项目带相同的级别分类用于包含上面未涵盖项目的报告。常见陷阱把每个黄色项目都当作可操作— 某些建议改进如持久对象缓存是主机级的可能无法修复。始终先按级别分类再行动。没有重定向计划就更改固定链接— 在已索引的站点上切换到文章名会破坏每个现有 URL。始终先规划 301 重定向。对上传限制使用ini_set()—upload_max_filesize和post_max_size是PHP_INI_PERDIRini_set()静默失败。改用php.ini、.htaccess或.user.ini。跳过wp search-replace的 dry-run— 错误的模式可能损坏序列化数据。未经--dry-run绝不运行它。安装两个缓存插件— 堆叠页面缓存插件会导致冲突和隐蔽 bug。如果已有一个在活动但未被检测到调试它而不是添加另一个。局限性自身无法对线上站点执行任何操作——每个 WP-CLI/PHP 片段都是为用户或其主机起草运行的本技能没有用户实际服务器的 shell 访问权限。无法验证当前的 PHP/服务器值上传限制、缓存后端可用性、HTTPS 状态——依赖用户检查phpinfo()或主机面板后报告的内容。不涵盖多站点特定的 Site Health 变体或 WooCommerce 特定的健康检查两者都会增加本技能配方列表不包含的额外项目。项目目录主文件 references/catalog.md反映的是 2026 年年中 WordPress 核心的Site Health 检查——项目标题/措辞会随核心版本变化因此未匹配的项目应报告为未匹配而不是强行套用最接近的配方。不替代完整的安全审计或入侵扫描——Site Health 标记的是配置卫生问题而不是站点已被入侵的迹象。相关技能security-hardening— 用于超越 Site Health 表面检查的更深入 WordPress 安全审计wp-performance— 用于 Site Health 标记解决后的针对性性能优化