个人站封禁未知 Query String：反跟踪有理，照搬会出事

一个个人网站，把 URL 里多出来的问号参数挡在门外。

2026 年 5 月 8 日，chrismorgan.info 作者 Chris Morgan 宣布，对本站启用“禁止未授权 query string”的规则。也就是说，带未知查询参数的链接，比如被外部平台追加了 ref=、utm_source=，以后可能被拒绝，或不再保证兼容。

这不是浏览器新规，也不是搜索引擎政策变化。它只是一个个人站站长在服务器配置里划线：我的 URL，不接受外部随手贴上来的跟踪尾巴。

我更在意的是这条边界。反跟踪有理，但不能把它误读成“所有 query string 都该被封”。

Morgan 封的不是问号，而是外部强加的跟踪

Morgan 的不满很具体：他反感别人给他的 URL 添加跟踪信息。

在他看来，如果自己需要知道访问来源，可以看 HTTP Referer header。若 Referer 缺失，通常也有合理原因。可能是浏览器策略，可能是用户设置，也可能是来源站点出于隐私考虑做了限制。

这是一种很个人站的判断。

目前 chrismorgan.info 不使用 query string。Morgan 也说，如果未来需要使用，只会允许已知参数。规则实现位置在他的 Caddyfile，本质上是个人网站层面的服务器配置决策。

几个点要分清：

这里最容易讲歪。

Query string 本身不是脏东西。站内搜索、分页、筛选、登录跳转、支付回调、A/B 测试、缓存破坏，很多网站都靠它承载状态。

Morgan 反对的是外部平台给他的链接加料，不是宣布 Web 上所有问号参数都不合法。

真冲突是归因便利，撞上站点控制权

UTM 参数常用于营销归因。邮件、广告、社交分发、分析工具都爱用它。它能回答一个运营问题：这次访问从哪来，哪条活动有效。

对平台和增长团队来说，这很方便。对独立站作者来说，它可能是另一回事：链接还是自己的，尾巴却是别人挂上的。

冲突就在这里。

平台想要可量化，站长想要可控，用户想要少被追踪。三方需求并不一致。

个人站可以更硬一点。内容少，路径短，历史包袱轻。Morgan 能说“我不用 query string，所以未知参数都不要”。这叫约法三章。

但换成新闻站、电商、SaaS 产品，就没这么简单。

一个电商站可能要用参数做筛选和排序。一个 SaaS 可能要靠参数处理登录回跳。一个媒体站可能要兼顾搜索索引、分享卡片、缓存和广告归因。粗暴封掉未知参数，可能不是反跟踪，而是自伤。

对普通访问者也有影响。别人分享给你的链接，如果被平台自动加了跟踪参数，可能会打不开，或跳不到预期页面。用户未必知道问题出在 URL 后面那串字符上，只会觉得“这个站坏了”。

所以这件事的启发，不是让所有站长立刻封问号。

它提醒独立站站长和 Web 开发者做一件更实际的事：清点自己到底接受哪些参数，哪些只是外部平台塞进来的噪音。

独立站可以收紧，复杂网站更适合清洗

如果你维护的是个人博客、作品页、文档站，且站点本身不依赖 query string，可以考虑更严格的策略。

动作可以很具体：列出允许参数；拒绝或重定向未知参数；对 utm_*、fbclid、gclid 这类常见营销参数单独处理；同时检查旧链接、缓存规则和静态资源请求。

如果你维护的是商业网站，不建议直接照搬。

更稳的路线是清洗，而不是封死。比如保留业务参数，剥离统计参数；在日志层忽略营销尾巴；在重定向时输出干净 URL；对支付、登录、搜索、分页等路径留出明确白名单。

可以按这个顺序排查：

接下来真正该看两件事。

一是更多独立站会不会把“URL 不接受外部附加物”写成明确规则。若只是个人站声明，它是合理的边界管理。

二是工具链会不会给站长更细的选项。比如自动清洗常见跟踪参数、保留功能参数、避免破坏缓存和搜索。只有做到这一步，反跟踪才不至于变成兼容性事故。

回到开头那个问号。

Morgan 拦下的不是一个字符，而是外部平台默认可以改写链接用途的习惯。个人站有权说不。复杂网站也该说清楚：哪些参数为功能服务，哪些只是跟踪负担。