网站建设中：怎样检查访问状态与错误页
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /854ea3b449ec.html
📄
网站建设中：怎样检查访问状态与错误页
检查访问状态与错误页，核心是让每个可访问地址都能被独立请求、记录状态码，并由非开发人员按同一份清单验收。适用前提是页面已经部署到测试或正式环境，且你只检查真实返回结果，不靠浏览器“看起来正常”来判断。验收信号是：关键页面返回 200，错误页返回 404 或 410，权限不足返回 401 或 403，服务异常返回 5xx，并且每种状态都有对应页面或明确处理。
先确定要检查哪些地址
多人协作时，返工往往来自“谁都不知道该测哪些链接”。先让内容、开发、运营各自提交一份地址清单，再合并去重。清单至少包含：首页、栏目页、详情页、搜索页、登录后页面、表单提交后的结果页、文件下载地址、旧地址或已删除内容地址。对每个地址标注预期状态码和预期落地页，例如“已删除文章：预期 404，展示错误页并提供返回首页链接”。
判断结果时，如果实际状态码与预期不一致，不要直接改代码，先确认是路由配置、权限中间件、重定向规则还是服务器配置造成。同一个现象可能有多个解释，例如页面显示“找不到”但状态码是 200，这可能是前端路由兜底，也可能是服务器把所有请求都返回了首页，需要看响应头才能区分。
用请求工具读取真实状态码
浏览器地址栏能打开页面，不等于状态码正确。可以用命令行工具逐条请求，例如：
curl -I https://example.com/old-page
重点看第一行状态码和 Location 响应头。若返回 301 或 302，要记录跳转目标；若返回 200 但内容是错误提示，说明状态码与内容不匹配，需要修正。批量检查时，可以把地址写入文本文件，用脚本逐行请求并输出“地址 + 状态码”，再由人工核对预期值。
适用条件是你能访问目标环境，并且请求不会被登录墙或防护策略拦截。如果返回 403，先确认是权限策略还是防护拦截；如果返回 5xx，先看服务日志，不要只在前端反复刷新。
错误页要检查内容与状态码是否一致
错误页不只是“显示一句抱歉”。检查项包括：
- 404 页面是否返回 404 状态码，而不是 200。
- 410 页面是否用于已永久删除的内容，并返回 410。
- 401 与 403 是否区分“未登录”和“已登录但无权限”。
- 5xx 页面是否避免暴露堆栈、数据库语句或服务器路径。
- 错误页是否提供返回首页、返回上一级或搜索入口。
验收时，让不参与开发的人按清单逐项打开，记录“地址、预期状态、实际状态、页面截图、处理人”。如果错误页由前端框架渲染，要额外确认服务器返回的状态码是否正确；如果错误页由服务器配置，要确认静态资源路径不会再次触发错误。
把检查结果变成可交付记录
交付清楚的关键是留下可复查的记录，而不是口头说“我测过了”。建议用一张表，列为：地址、预期状态码、实际状态码、跳转目标、错误页截图、发现时间、处理状态。每次修改后只复测受影响地址和相邻入口，例如改了栏目路由，就复测栏目页、栏目下详情页和旧栏目地址。
判断是否可以交付，看三个信号：关键地址全部符合预期；错误页状态码与内容一致；清单上有明确处理人和复测结果。若某个地址暂时无法确定预期状态，先标记为待确认，不要用“应该没问题”通过验收。
下一步怎么做
先建立一份包含预期状态码的地址清单，再用请求工具逐条核对，把不一致项分配给对应处理人，修改后按同一清单复测。这样能把访问状态与错误页检查变成可重复的交付步骤，减少多人协作中的返工。
