WordPress显示“此站点遇到了致命错误”，表示某次请求无法继续执行，并不直接证明网站被攻击。先记录发生时间和操作，再找同一时刻的PHP错误日志；页面上的通用提示不是根因。
先确定影响范围
分别检查首页、一个内页和后台。若只有某个编辑页面失败，优先关注该页面用到的模块；若前后台全部失败，检查刚发生的插件、主题、PHP或配置变更。不要同时升级所有组件，否则会失去可比较的起点。
有管理员恢复邮件时，只使用发给自己的有效恢复入口，不把链接贴入公开工单。恢复模式能帮助进入后台，但不代表所有访客的问题已经消失。
按证据缩小到一个组件
- 保存当前文件和数据库备份，记录插件版本及最后一次正常时间。
- 查看主机提供的PHP错误日志，找此次请求对应的首个致命错误。文件路径指向插件只是线索，仍要检查调用链，不能看到名字就删除。
- 在测试副本重现同样操作，单独停用疑似组件。前台已不可用且没有后台入口时，由维护人员通过文件管理器临时改名该插件目录；保留目录原名与内容。
- 恢复访问后检查该组件依赖、PHP兼容要求和官方更新说明。按需要更换兼容版本，而不是把临时停用当作最终修复。
- 逐项恢复其余功能，尤其是表单、结账及多语言入口。
日志应怎样使用
若必须开启WordPress调试日志，应把错误写入受保护日志，关闭前台显示，并在排查后撤销临时配置。日志可能含路径和业务数据，不能直接上传给不受控的公开服务。没有同一时间的日志时，先重现一次可控请求，避免拿几个月前的报错解释今天的问题。
怎样确认修好了
原来失败的操作能完成，前后台关键路径正常，重新请求后没有同类致命错误，才构成有效验证。仅刷新首页成功不够。
停用插件后正常，就能证明插件质量差吗？ 不能。冲突可能来自版本组合、自定义代码或资源限制。记录最小复现条件，才有条件判断根因。
参考资料
相关问题
本文为通用排查指南，依据所列官方资料整理；菜单名称和行为可能随版本及主机环境变化。配图为AI生成的概念示意，不是实际故障截图。
