流量检查：如何确认链接指向目标域名

什么算作跳转到目标域名

当用户经过所有重定向后打开目标主机上的页面时，流量才算到达目标域名。仅仅检查插入直播描述、个人资料或广告中的地址是不够的：链接可能经过短链接服务、跟踪器、旧域名、中间落地页或地理重定向。

不仅要检查域名本身，还要检查其变体：带www和不带www、HTTP和HTTPS、主域名和子域名。site.example、www.site.example和promo.site.example这些地址可能属于同一个项目，但对浏览器、分析和日志来说，它们是不同的主机。

以受众打开链接的方式打开链接

从实际放置位置点击链接：从直播描述、个人资料、置顶消息、帖子或广告中。页面加载后，检查地址栏。重要的是浏览器中最终保留的URL，而不是发布内容中的原始地址。

• 将最终主机与落地页域名进行核对。
• 检查路径：链接可能指向正确的域名，但却是过时的板块。
• 确保移动端跳转不会进入技术子域名。
• 比较带UTM标记和不带UTM标记的链接结果。
• 检查所有跳转后广告系列参数是否保留。

手动检查的不足：它只展示一种场景——你的浏览器、设备、地区和cookie集。对部分受众来说，规则可能有所不同。

在浏览器和通过curl检查整个重定向链

进行技术检查时，使用带-I和-L参数的curl：该命令会显示响应头并跟随重定向。查找301、302、307、308状态码和Location头。它们显示服务器在每一步将用户导向哪个地址。

要在真实浏览器中检查，请打开开发者工具，进入Network选项卡并启用Preserve log。然后打开原始链接。在请求列表中可以看到重定向、最终文档以及页面加载后执行的请求。

1. 启用Preserve log，以免列表在重定向后被清空。
2. 如有必要，禁用浏览器缓存。
3. 从发布内容中打开原始链接，或将其粘贴到新选项卡中。
4. 找到状态码为3xx的响应。
5. 将每一步的Request URL与Location值进行核对。
6. 检查状态码为200的最后一个文档的域名和URL。

链中的旧域名何时正常，何时是错误

链中的旧域名并不总是意味着问题。迁移后，old-site.example/stream → site.example/stream这样的路径是正常的：旧地址接收请求并永久将用户重定向到新网站的对应页面。最终域名正确，路径保留，UTM标记没有丢失。

Bug是指old-site.example/stream指向新网站首页、另一个落地页或让用户留在旧域名上的情况。另一个问题是重定向后问号后面的字符串丢失：用户到达了正确的页面，但分析丢失了utm_source、utm_medium和utm_campaign。

不仅要检查最终域名，还要检查带参数的路径。跳转到没有所需页面或标记的site.example，可能和跳转到他人主机一样严重地扭曲广告系列数据。

考虑JavaScript重定向和链接参数

curl适合查看服务器响应，但并不总能发现页面加载后由脚本启动的重定向。浏览器中的DevTools有助于发现这种场景：首先打开中间页面，然后脚本更改地址或将用户发送到另一个域名。

在Network中，不仅要检查主文档，还要检查其加载后地址变化的时刻。如果UTM标记丢失，请比较原始URL、Location值和地址栏中的最终字符串。这样可以了解重定向规则在哪一步丢弃了参数。

不加检查地传递所有参数的不足：多余的服务值可能进入目标域名。对于重要链接，应提前确定哪些标记、促销码和联盟参数必须保留。

检查应用内置浏览器

社交网络、即时通讯工具和流媒体平台通常不在设备的主浏览器中打开链接，而是在内置浏览器中打开。这种浏览器可能传递不同的user-agent、限制脚本、不保存cookie或以不同方式处理重定向。

直接从链接所在平台的应用中打开链接。然后通过“在浏览器中打开”选项（如果可用）重复测试。比较最终域名、路径、UTM标记以及表单、支付或授权的行为。

在内置浏览器中检查的不足：并非所有应用都允许查看技术请求链。但它仍然很重要，因为移动受众经常以这种方式跳转。

比较来自不同地区和条件的跳转

如果网站使用地理重定向、CDN或不同版本的落地页，请通过VPN、代理或所需地区的远程设备重复检查。比较最终域名、路径、URL参数和落地页内容。

不仅要检查国家，还要检查浏览器语言、授权状态、cookie和设备类型。这些条件可能影响路由：例如，来自某一地区的用户被发送到本地子域名，而没有cookie的访客被发送到通用落地页。

VPN和代理的不足：它们并不总能完全复现真实观众的条件。地理位置可能通过多个信号确定，因此这种测试确认了可能的问题，但并不能覆盖全部受众。

在Yandex Metrica和GA4中确认域名

在Yandex Metrica中查看入口页面和页面URL报告。按完整地址或所需域名筛选数据，然后添加按UTM标记、来源或广告系列的分段。这样可以查看特定投放后访问从哪个主机开始。

在GA4中，进行此类检查时使用Hostname维度，并结合落地页、会话来源和广告系列。比较有多少会话到达主域名、旧地址和重要子域名。如果代码安装在多个主机上，报告会快速显示流量混合情况。

分析的不足：由于拦截器、禁用JavaScript或页面在代码加载前关闭，计数器无法记录部分访问。此外，对于根本没有安装计数器的域名，数据也无济于事。

检查服务器日志中的请求

服务器日志确认哪些请求实际到达了网站基础设施。检查需要包含时间、Host、URL、响应码、user-agent和referer（如果传递）的字段。查找链接启动期间的请求，并单独查看对旧域名和目标域名的请求。

301、302、307和308响应将显示服务器重定向了用户。对目标主机的200状态请求将确认页面是从所需域名提供的。如果日志中有跳转到旧主机的记录，但没有对新主机的请求，请检查重定向规则和可能的连接错误。

日志的不足：其中会包含机器人、扫描器和技术请求。从应用和即时通讯工具跳转时referer经常缺失，因此并不总能还原特定访问的来源。

在报告中区分主域名和子域名

落地页、个人中心、支付和知识库可能位于不同的子域名上。如果在没有分段的情况下将它们汇总到一个报告中，可能会忽略直播中的链接指向promo.site.example而非主站，或在了解优惠之前指向checkout.site.example的情况。

为目标主机创建单独的分段，并保留项目所有域名的总报告。前者有助于控制落地流量，后者可以查看用户在落地页、支付和个人中心之间的路径。

过度严格筛选的不足：子域名之间的正常跳转可能从报告中消失，漏斗将看起来是断裂的。

投放前链接检查清单

• 从受众看到链接的位置打开链接。
• 检查地址栏中的最终域名、路径和参数。
• 通过curl或Network查看3xx链和Location头。
• 确保旧域名在重定向时保留路径和UTM标记。
• 在应用的内置浏览器中重复跳转。
• 如果使用地理规则，检查另一个地区。
• 启动后在分析中核对Hostname和落地页。
• 通过服务器日志确认对所需主机的请求。

更换域名、CDN、落地页或重定向规则后，请同时检查新链接和旧链接。旧的直播描述、视频和置顶帖子可能继续将受众引导到过时的路径。