WordPress 网站无法访问？故障修复指南

网站中断可能由 DNS、主机、证书、WordPress、近期部署或某项集成引起。更改文件或恢复备份前，先确认哪些部分受影响。记录故障开始时间、错误信息和近期变更，再选择风险最低、范围最小的恢复措施。

如果网站处理订单、预约或重要信息，应尽快通知业务负责人和主机服务商，并记录决策及对客户的影响。如果怀疑网站遭到入侵，请按事件响应流程处理，并在清理前保留证据。

1. 确认故障范围

使用另一台设备和网络访问网站。测试主域名和一个已知页面；只有在安全的情况下才比较 HTTP 和 HTTPS。记录浏览器 DNS 错误、连接超时、证书警告、服务器错误、空白页、重定向循环或 WordPress 错误等具体表现。确认所有访客都受影响，还是只有已登录的会话异常。

查看主机服务状态，并询问服务商服务器、账户资源限制、数据库或网络是否出现问题。服务不稳定时，不要反复刷新结账页面或重复提交表单。

确认域名没有过期，权威 DNS 记录仍指向预期服务。检查近期的 DNS、名称服务器、CDN、防火墙和主机变更。DNS 缓存更新可能需要时间，因此应记录实际查询使用的解析器和返回结果，避免反复更改设置。

请主机服务商检查资源限制、Web 服务器和 PHP 错误日志、数据库、磁盘空间及账户状态。5xx 响应通常表示服务器端问题，但状态码本身不能说明具体原因。证书警告应从证书和主机名层面排查，不要让访客绕过警告继续访问。

将故障时间与插件、主题、WordPress、PHP、配置、DNS 和部署变更对照。如果网站负责人已有经过测试的回滚流程，可针对与故障时间相符的变更执行回滚。没有备份和明确恢复方法时，不要停用所有插件或直接修改线上文件。

如果 WordPress 显示致命错误，请结合主机日志和 WordPress 调试指南排查。调试输出应保持私密，并关闭面向访客的错误显示。维护模式或恢复模式可能有帮助，但无法解决服务器或 DNS 故障。

回滚或维修前，先保存当前文件、数据库和相关日志。确认要恢复的备份、备份日期，以及之后新增的订单或内容可能造成的数据损失。条件允许时，先在暂存环境测试恢复。如果事件涉及安全问题，不要把可能已受感染的备份当作干净版本。

一次只做一项可控变更，并记录下来。不要运行不熟悉的 SQL、递归修改文件权限，也不要在未核对版本和主机恢复方案前替换核心文件。如果无法确认数据完整性或访问权限，请升级处理。

测试重要页面、登录、表单、邮件发送、结账或预约、支付回调、搜索、定时任务及第三方集成。确认 HTTPS、重定向、规范网址、分析和监控正常。检查服务器日志是否仍有重复错误，并请另一位同事走查主要用户流程。

如果 Google Search Console 报告安全问题，应先完成修复，再按 Google 的流程申请复核。重新开放网站并不代表搜索警告或索引会立即恢复。

保存最新的异地备份并定期测试恢复。维护域名、DNS、主机和应用负责人及紧急联系人清单。重要更新先在暂存环境测试，并使用能识别故障层级的监控。预先约定谁可以批准回滚，以及需要保留哪些证据。

先确认故障原因和备份状态。近期备份也可能包含同一故障或仍在活动的入侵。检查备份日期、完整性和潜在数据损失；条件允许时，先在受控环境测试恢复。

部署后，清理缓存可能纠正过期页面，但无法修复 DNS、不可用的服务器、故障数据库或已被入侵的文件。先定位出错的环节。

如果交易受到影响、涉及安全或数据风险、回滚后故障再次出现，或必须冒险修改线上网站才能排查，请尽快升级处理。要求服务方说明证据、范围、恢复方案和维修后的检查。