流量来源统计方法，页面改名后怎样拼接前后统计记录
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f98a4cd263e2.html
📄
流量来源统计方法，页面改名后怎样拼接前后统计记录
页面改名后，旧路径和新路径的统计记录默认是两段互不相干的序列。拼接的目标不是把两段数字直接相加，而是先判断旧路径是否还有承接入口、新路径是否已经稳定接收同类流量，再决定用重定向映射、路径归并还是分段保留来对齐。判断错了，前后对比会把一次正常的路径迁移读成流量下跌。
先分清两种成立条件：旧路径还在承接，还是已经彻底退出
拼接方式取决于旧路径当前的角色，而不是取决于改名这个动作本身。
- 旧路径仍被外部引用：其他站点、书签、历史邮件、线下物料仍指向旧路径，服务器对旧路径返回重定向。此时旧路径的请求会持续一段时间，统计上应把旧路径视作新路径的入口，而不是一条独立渠道。
- 旧路径已无任何承接：旧路径直接返回失效状态，或从未被外部引用过。此时旧路径的记录只是历史存量，拼接时只做时间轴上的分段标注，不参与新路径的渠道构成。
这两种条件的代价不同。第一种要求你在统计配置里维护一张映射关系，映射一旦遗漏，重定向带来的流量会被记到旧路径名下，新路径看起来增长缓慢；第二种不需要映射，但前后两段的渠道结构无法直接比较，任何跨改名的同比都要注明断点。
选择依据：看入口来源和落地页维度是否可对齐
决定用哪种拼接方式前，先核对三个可观察的证据，它们比流量总数的涨跌更能说明问题。
- 入口来源维度：分别查看旧路径和新路径的来源分类。如果旧路径在改名后仍持续出现自然搜索、外链或直接访问，说明外部引用未清理干净。
- 落地页维度：站内统计通常按落地页分组。若旧路径的落地页记录在改名后迅速归零，同时新路径的落地页记录同步上升，可以判断迁移基本完成。
- 日志或请求记录：服务器请求记录能区分“访问旧路径后被重定向”和“直接访问新路径”。这两类在统计里常被合并，但诊断时应当分开看。
需要说明的是，第三方估算流量、搜索引擎报告和站内统计的口径并不一致。旧路径记录归零，既可能是迁移完成，也可能是统计配置漏掉了重定向后的落地页，还可能是抓取或采样周期变化。单一指标的归零不能单独证明处理正确，必须结合至少两个维度交叉确认。
实施动作：建立映射并验证一次，再决定是否合并
具体动作分三步，每一步的结果都会影响下一步。
第一步，列出旧路径到新路径的完整映射。包括带参数、带尾斜杠、大小写不同的变体。只映射主路径而漏掉参数变体，是拼接后数据对不上的常见原因。
第二步，在统计配置中把旧路径的访问归并到新路径。归并规则生效后，观察一到两个完整的统计周期。如果新路径的入口来源结构在归并前后基本一致，说明映射覆盖完整，可以按合并后的序列做趋势分析。
第三步，如果归并后新路径的来源结构发生明显跳变，例如某一类来源突然增多，说明旧路径原本承载了这部分流量，映射把它整体搬了过来。此时不应直接合并，而应在报告中保留“迁移前旧路径”和“迁移后新路径”两段，中间标注断点。
假设一个例子：某页面从 /old-name 改到 /new-name，只对主路径做了重定向，带查询参数的旧链接仍返回失效状态。归并后新路径的总量上升，但直接访问类来源占比下降。这个信号提示参数变体没有被覆盖，需要补齐映射后重新观察，而不是先下结论说改名损失了流量。
例外：改名同时改了栏目层级或站点结构
如果改名不只是页面标识变化，还伴随栏目层级调整，路径归并会掩盖结构变化带来的影响。此时更稳妥的做法是保留两段独立记录，在分析时用同一套入口来源维度分别描述，而不是强行拼成一条连续曲线。结构变动本身就会改变内部链接和导航入口，把它和改名混在一起合并，后续无法区分哪部分变化来自命名，哪部分来自层级。
拼接前后记录的核心不是让曲线看起来连续，而是让每一次对比都能追溯到具体的路径和来源。映射覆盖完整、来源结构稳定，才具备合并的条件；否则分段保留并标注断点，是更诚实的处理方式。
