SEO友好建站 - 怎样检查访问状态与错误页

📍 WDQWDWQD987AAAAA:216.73.217.162
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /980acd72f616.html
📄

SEO友好建站 - 怎样检查访问状态与错误页

检查访问状态与错误页，核心是确认每个重要URL返回的HTTP状态码是否符合预期：正常页面应为200，永久迁移应为301，暂时不可用应为503或302，而404和410只应出现在确实不存在的页面上。多人协作时，把这项检查做成可交付的清单，能避免“页面能打开但返回404”“旧链接跳转到错误页”这类返工。

从一个假设的交付场景说起

假设一个团队刚完成站点改版，A负责内容迁移，B负责前端路由，C负责上线。交付前C只点了首页和几个栏目页，看到都能打开就宣布完成。上线后一周，搜索流量下降，排查发现：旧文章链接被前端路由接管，服务器一律返回200，但页面显示的是“内容不存在”的提示。用户看到的是错误提示，搜索引擎拿到的却是正常状态码。

这个例子的关键错误是把“页面能显示”等同于“访问状态正确”。状态码由服务器响应头决定，和页面上渲染什么文字是两件事。检查时必须看响应头，而不是只看浏览器里有没有内容。

用命令行逐条核对状态码

最直接的方法是请求URL并只读取响应头。以下命令只取第一行状态信息，适合批量抽查：

curl -sI https://example.com/old-page | head -n 1

如果返回 HTTP/2 200，说明服务器认为该地址正常；返回 HTTP/2 404，说明资源不存在；返回 HTTP/2 301 并带有 location 头，说明是永久跳转。对一批URL，可以把地址写进文本文件，用循环逐条输出：

while read u; do echo -n "$u "; curl -sI "$u" | head -n 1; done < urls.txt

执行前先明确每个URL的预期状态，再和实际结果对比。没有预期值，看到200也不知道对不对。

检查清单：哪些URL必须验证

多人协作时，把这份清单拆成任务，每人负责一段，交付时附上命令输出或表格记录，比口头说“我测过了”更可靠。

常见错误与判断方法

错误一：软404。页面显示“找不到内容”，但状态码是200。判断方法是看响应头而非页面文字。修正方式是在服务器或应用层对不存在的内容返回404。

错误二：跳转链过长。A跳B、B跳C。判断方法是加 -L 参数跟踪跳转：curl -sIL https://example.com/a | grep -i "^HTTP\|^location"。链路过长会拖慢访问，也可能让爬虫放弃跟踪。

错误三：跳转到无关页面。旧文章301到首页。这会让用户和搜索引擎都得不到预期内容。判断方法是核对跳转目标与原页面主题是否一致。

错误四：错误页返回200且被索引。判断方法是查看错误页URL是否出现在站点地图或内部链接中。错误页不应主动提交给搜索引擎。

把检查固定成交付步骤

在多人协作中，建议把访问状态检查放在上线前和上线后各做一次。上线前用测试环境验证规则，上线后用正式域名抽查。记录格式可以很简单：URL、预期状态、实际状态、跳转目标、检查人。出现不一致时，先确认是服务器配置、应用路由还是CDN缓存导致的，再决定改哪一层。CDN可能缓存了旧的响应头，清理缓存后需要重新验证。

下一步：从站点地图和服务器访问日志中各取一批URL，按上面的清单跑一遍命令，把结果填入交付记录，再交给下一位协作者复核。

图1 图2
nginx