个人网站搭建：怎样检查访问状态与错误页
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6c9400068542.html
📄
个人网站搭建：怎样检查访问状态与错误页
检查访问状态与错误页，核心是分别验证“网络能否到达服务器”“服务器返回什么状态码”“页面内容是否完整”这三层。交付时不要只凭“我这边能打开”就验收，而应让协作方提供可复现的检查记录：访问地址、检查时间、使用的网络、返回状态码、错误页截图或响应内容。这样出现返工时，能快速判断是域名解析、服务器、程序还是页面资源的问题。
先定验收标准：什么才算“访问正常”
多人协作最容易返工的环节，是每个人对“正常”的理解不同。建议在交付前写清四项验收依据：
- 状态码：正常页面返回
200；跳转返回301或302；不存在页面返回404；服务器故障返回5xx。 - 访问范围：首页、栏目页、文章页、表单页分别抽查，不能只测首页。
- 网络环境：至少覆盖宽带与移动网络两种，必要时增加目标用户所在地区。
- 错误页表现：错误页是否显示自定义内容、是否仍带导航、是否返回正确状态码，而不是一律返回
200。
验收标准写进交付清单后，责任就清楚了：解析问题归域名与 DNS 配置，程序报错归开发，静态资源缺失归前端或部署环节。
用浏览器开发者工具查看状态码与失败资源
这是最直接、可当场复现的方法。打开页面后按 F12，切换到网络面板，刷新页面，逐项检查：
- 看第一条文档请求的状态码。若为
200，说明主文档正常返回；若为404，通常是路径或路由配置问题。 - 看是否有
3xx跳转链。跳转层数过多，可能拖慢访问，也可能造成循环跳转。 - 看图片、样式、脚本的请求。若主文档是
200，但多个资源是404，页面会“能打开但样式错乱”，这属于典型的交付返工点。 - 看控制台报错。脚本报错与状态码问题是两类现象，不要混为一谈。
判断结果时注意：主文档 200 不等于页面完全正常；资源 404 也不等于整站不可访问。把两类问题分开记录，修复责任才不会互相推诿。
用命令行做可留档的批量检查
命令行检查的好处是结果可复制、可粘贴进交付记录。常见做法是查看响应头：
curl -I https://example.com
返回内容中第一行包含状态码，例如 HTTP/1.1 200 OK。若需要跟随跳转，可加 -L；若只想看最终状态码，可只提取首行。检查多个页面时，把地址写进文本文件，逐行执行并保存输出，比口头说“都测过了”更可靠。
需要区分的是：命令行返回 200，只说明服务器对该请求返回了正常响应，不代表浏览器端渲染、登录状态、表单提交都正常。因此命令行适合做批量状态巡检，浏览器适合做交互与资源检查，两者互补。
错误页要单独验证，不能只看“打不开”
错误页检查常被忽略，但它直接影响用户体验和后续排查。建议按以下检查项逐条确认：
- 访问一个确定不存在的地址，确认返回
404而非200。若返回200，搜索引擎可能把错误页当成正常页面。 - 确认自定义错误页包含返回首页或栏目的入口，避免用户进入死胡同。
- 模拟服务器错误时，确认
5xx页面不暴露数据库账号、文件路径、框架版本等敏感信息。 - 检查错误页在移动端的显示是否正常，避免只测桌面端。
如果错误页由托管平台或 CDN 提供，需确认自定义页面是否已生效。这里不假设任何平台的具体设置位置，直接以实际访问结果为准：访问不存在地址，看返回状态码和页面内容是否符合预期。
把检查结果写成可交接的记录
多人协作时，检查结论要能交接。推荐每条记录包含：检查地址、检查时间、网络环境、状态码、异常资源、截图或命令输出、初步判断、责任人。例如：
假设某文章页主文档返回 200，但封面图请求返回 404。记录为“页面可访问，封面资源缺失，疑似上传路径或文件名大小写不一致，责任归内容或前端”，而不是笼统写“页面有问题”。
下一步：在交付前挑首页、一个栏目页、一个详情页和一个不存在的地址，按上述四类记录各测一遍，把结果附在交付说明里，再让协作方复核。这样验收有依据，返工也能定位到具体环节。
