外链吧 - 怎样检查跳转链与落地页

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

外链吧 - 怎样检查跳转链与落地页

检查跳转链与落地页，核心是沿着“外链点击后实际经过的每一跳”走一遍，确认三件事：跳转是否按预期发生、每一跳是否可达、最终落地页内容与链接预期是否一致。最实用的做法是先用浏览器开发者工具的 Network 面板看完整请求链，再用命令行工具批量验证状态码，最后人工核对落地页。下面按决策顺序展开。

先判断：你需要检查的是哪一种跳转

“跳转链”在实际项目里至少对应三种情况，检查方法不同：

301/302 服务器跳转：外链直接指向一个会返回 3xx 状态码的 URL，浏览器自动跳到目标页。需要看响应头里的 Location 和状态码。
前端脚本跳转：页面先返回 200，再由 JavaScript 执行 window.location 或 meta refresh 跳转。这类跳转在纯 HTTP 状态码检查里看不到，必须用能执行脚本的工具。
落地页内部再跳转：落地页加载后又触发一次跳转，比如地域重定向、登录墙、App 唤起。用户最终看到的页面和最初请求的页面不是同一个。

判断属于哪一种，最直接的方法是打开浏览器开发者工具的 Network 面板，勾选 “Preserve log”（保留日志），然后访问外链目标 URL，观察请求列表里是否出现多次文档请求以及各自的 Status Code。

用浏览器手动走一遍完整链路

这是成本最低、信息最全的一步，适合单条或少量链接的核查：

打开开发者工具，切到 Network 面板，清空记录，勾选保留日志。
在地址栏输入外链指向的 URL 并回车，不要直接在外链所在页面点击，避免来源信息干扰判断。
观察文档请求（Document 类型）列表：第一个请求的状态码是多少，是否有 301、302、307、308；后续请求的 URL 是什么。
点开每个 3xx 请求，在 Headers 里找 Location，确认它指向的地址是否符合预期。
如果状态码全是 200 但页面地址变了，检查是否是脚本跳转，可在 Sources 面板搜索 location、replace、meta refresh。
链路走完后，核对最终落地页的标题、主内容、语言版本、是否要求登录，是否与投放或外链描述的页面一致。

适用条件：链接数量少、需要看渲染后效果、需要判断是否被登录墙或地域逻辑拦截。代价是逐条操作，无法批量。

用命令行批量核对状态码与跳转目标

链接数量较多时，命令行能快速筛出异常项。以 curl 为例，只看响应头、跟随跳转并输出每一跳：

curl -sIL -o /dev/null -w "%{url_effective} %{http_code} %{num_redirects}\n" "https://example.com/path"

这条命令会输出最终 URL、最终状态码和跳转次数。把一批 URL 写进文件后循环执行，就能得到一张表。判断规则可以这样定：

最终状态码不是 200（或预期的 3xx 之外的正常码）：标记为待查。
跳转次数明显多于预期，比如超过 2 次：检查是否存在跳转链过长或循环跳转。
最终 URL 与预期落地页不一致：确认是配置错误还是有意为之。
出现 404、410、500：分别对应目标页不存在、已删除、服务端错误，处理方式不同。

注意：curl 默认不执行 JavaScript，所以它只能验证服务器跳转，验证不了前端脚本跳转。要覆盖脚本跳转，需要能用无头浏览器执行页面的工具，或者回到浏览器手动确认。这是选择工具时的关键分界。

落地页要核对哪些项目

跳转链通了不等于落地页合格。落地页检查应围绕“用户点进来能不能得到他预期的东西”展开：

内容匹配：落地页主题是否与外链所在页面的描述、锚文本一致。不一致会造成用户立刻跳出。
可访问性：是否需要登录、是否被地域限制、是否弹窗遮挡主要内容、移动端是否可正常阅读。
链接自身状态：页面内主要按钮和导航是否可达，是否有失效链接。
重复与规范：同一内容是否存在多个 URL 版本，页面是否声明了规范地址，避免权重分散。
加载表现：首屏内容是否在合理时间内出现。若跳转链本身很长，叠加加载慢，用户流失会更明显。

这里的判断依据是用户视角，不是权重视角。跳转次数、状态码、页面内容三者要一起看，单独看任何一项都可能误判。

按代价选择检查方案

三种常见做法的取舍：

纯手动浏览器检查：信息最全，能发现脚本跳转和渲染问题，但只能小批量，耗时随链接数线性增长。
纯命令行状态码检查：速度快、可批量，但漏掉所有依赖 JavaScript 的跳转和渲染后才出现的问题。
两者结合：先用命令行筛出状态码异常和跳转次数异常的链接，再对这批链接用浏览器逐条确认。这是多数项目在准确性和成本之间较平衡的做法。

如果项目里外链数量很少且经常变动，直接手动检查即可；如果外链数量大、需要定期复查，则应建立可重复执行的批量检查流程，并把结果留档，便于对比两次检查之间哪些链接发生了变化。

下一步：挑出你当前项目里点击量或重要性最高的若干条外链，按上面的顺序跑一遍，把最终落地页 URL、跳转次数、最终状态码记录成一张表，再决定哪些需要修改跳转配置、哪些需要更换落地页。