前几天在看 GA 后台数据，随口问了自己一句：这些数字准不准？
一查，查出一个事故。
一、事情是怎么发现的
起因很简单：把 Search Console 的点击数据和 GA 的用户数放在一起看，发现对不上——这个正常，两个工具统计口径本来就不一样，我还专门写过一篇文章解释这件事。
但顺着这个话题继续往下查，我做了一件之前没做过的事：打开首页源代码，搜一下 GA 的追踪 ID。
没搜到。
首页，全站最重要的一个页面，完全没有 Google Analytics 代码。
二、复盘：GA 是怎么丢的
翻了一下 Git 提交记录，时间线很清楚：
- 5 月 13 日：全站添加 Google Analytics，首页当时是有的
- 6 月 4 日：首页做了一次视觉大改版，把整个页面的
<head>部分重写了一遍。改版当天的提交记录里，能清楚看到 GA 那几行代码被删掉了 - 6 月 4 日之后，一直到我发现问题：首页的源码里，GA 代码就一直是空的，中间没有任何一次提交把它加回来过
原因很典型：大改版容易把"看起来不重要"的代码顺手删掉。GA 那几行脚本混在一堆 meta 标签和 CSS 里，改版时重写 <head>，删除的时候没人特意留意它，加回来的时候也没人想起要补。而且这种问题不会报错、不会白屏、页面看起来完全正常——所以能一直没人发现。
三、更奇怪的是：丢失期间数据没有真的归零
复盘到这里，我以为故事就讲完了。结果去 GA 后台把时间范围精确设成"6月4日-7月10日"（也就是理论上完全没有 GA 代码的这段时间），发现首页这段时间还是有 72 次浏览记录。
这个和 Git 历史对不上——代码层面这段时间应该是 0。
最合理的解释是缓存：Cloudflare 的边缘节点，或者部分回头访客自己浏览器的缓存，在改版之后一段时间里，可能还在继续返回改版前的旧版页面（那个版本里 GA 代码还在）。直到缓存自然过期，或者被后续的新部署刷新掉，这部分"漏网"的访问才会真正停止被追踪。
所以真实情况更麻烦：不是"这5周数据完全没有"，而是"这5周的数据残缺不全、命中率不确定"——比彻底没有数据更难处理，因为你没法简单地把这段时间标记为"无效数据"直接排除，你甚至不知道哪些是真实数据、哪些是缓存的巧合。
四、审计之后，发现了更大的坑
首页的问题让我不放心，干脆把全站 147 个页面挨个查了一遍 GA 代码。结果比预想的严重得多：
- 71 个页面完全没有 GA，包括首页、首页预览版，以及内容库全部约 40 篇文章
- 76 个页面虽然有 GA，但位置不对——Google 官方要求代码要"紧跟
<head>之后"，但这 76 个页面全部是插在<head>快结束的位置，中间隔着几十到两万字符不等的 meta 标签和 CSS
内容库文章全军覆没的原因更根本：博客用 Hugo 生成，模板本身从第一天起就没有包含 GA 代码。也就是说，不是"改版删掉了"，是从来没加过——每篇新文章生成出来，天生就没有追踪代码，这个坑从内容库上线那天就一直在，只是首页的问题让我想起来去查全站，才把这个更大的坑一起挖出来。
五、怎么修的
两件事一起做，缺一个都还会再出问题：
修当下：写脚本批量处理144个文件——71个缺失的页面补上代码，76个位置不对的挪到 <head> 最前面，统一成同一个标准代码块。
修根因：Hugo 主题模板里加上 GA 代码。这一步比修复已有页面更重要——不然过阵子新文章一发布，同样的坑会原样再挖一次。
总结
这次事故给我的提醒，其实和内容质量、流量渠道都没关系，是三件更基础的事：
改版前后要有一份"不看页面样子"的检查清单。 视觉改版最容易出这类问题——页面看起来完全正常，出问题的是肉眼看不到的部分。GA 代码、结构化数据、canonical 标签，这些东西不会因为漏掉而让页面"看起来"有问题，所以必须专门检查，不能靠"看着没问题就是没问题"。
批量生成的内容，追踪代码要放在模板层，不能指望每次手动加。 如果当初 GA 是写进 Hugo 模板而不是每篇文章手动补，这个问题根本不会发生——那 40 篇文章不是被删掉了代码，是压根没人想起来要给模板加这一段。凡是会被复制、被批量生成的东西，凡是"每次都要记得手动做"的步骤，迟早会有一次忘记。
没查之前，不要假设"应该是好的"。 这次问题存在了至少5周，中间我看过好几次 GA 后台的数据，没有一次觉得不对劲——因为数据看起来是"正常"的，只是没意识到"正常"的数据背后可能有一部分是缓存的巧合，另一部分渠道可能完全是空的。定期去源码里搜一下追踪代码，比盯着后台数字曲线更可靠。