AI 回答中 URL 的五種寫法：歸一化後才有可比的分母

简介： 本文详解AI回答中URL归一化技术：针对同一页面因协议、www前缀、跟踪参数、短链、末尾斜杠等导致的上百种字符串变体，提出五步标准化流程（去协议、去www、去跟踪参数、去斜杠、统大小写），确保同页生成唯一键。实测902条引用归一为294页/143域，避免域名虚增、去重失效、同页多计三大误判，保障“页面数”“域名数”“同域多页率”等指标准确可比。（239字）

我们统计 AI 回答里的引用时，最容易被跳过的一步不是抓取，是给链接建键。同一个页面，在回答里能以上百种字符串出现；按字符串计数，等于给同一页发了上百个身份证。所有关于「多少来源」「多少页面」「平均每页被引几次」的说法，都得先过这一关。

所谓归一化，指的是在计数之前先给每个链接算一个稳定的键：同一个页面不管以哪种写法出现，都落到同一个键上。它不判断页面好坏，也不判断链接是否有效，只回答一个问题：这两条记录是不是同一页？

我们先摆一次实测的规模。自建采集库里带被引链接的记录 902 条，去重后是 294 个页面、143 个域名，查询日 2026-10-27。这三个数是同一批数据的三种计数方式，谁也不等于另一个。

一、五种写法是怎么长出来的

第一种是协议。同一个页面，有的回答给 http 开头的串，有的给 https 开头的串。服务器上通常 301 到同一处，字符串上却是两条。

第二种是主机名前缀。带 www 与不带 www 是两个主机名，但多数站点两者都通，落到同一份内容。

第三种是查询参数。这里最常见的是跟踪参数，来源标记、渠道标记、分享标记，一串串挂在问号后面。同一个页面经不同渠道分享，字符串就不同。

第四种是短链与跳转页。回答里有时给的是短链服务生成的短串，打开之后跳几次才到正文。短链的主机名与目标页的主机名完全不同，按字符串统计，一个页面会被算成两个域名。

第五种是末尾斜杠。带斜杠与不带斜杠，服务端一般返回同一份内容；写成目录加默认页（比如 /a/index.html）又是第三种写法。

我们这五步之外，还有一类大小写差异：主机名大小写不敏感，路径是否敏感要看服务器。这类问题不多，但会让去重差几个。

二、不归一化，会错在哪三处

不归一会错在哪？三处，每一处都很像真的。

第一处错在域名数。带 www 与不带 www 被当成两个站，短链主机名又被当成一个独立来源，域名数就这么一层层加上去。报告里写「覆盖多少个来源站」，实际是把同一个站数了两三遍。

第二处错在去重。同一条正文被不同问句召回到、又从不同渠道分享出去，字符串各不相同，去重形同虚设。分开报的「页面数」和「记录数」于是越来越接近，看上去像每条记录都来自不同页面。

第三处错在同页多计。一页被算成八条记录，页面层的集中度就被摊薄，算出来像是「引用很分散」；而真实情况往往是少数页面撑住了大部分引用。这个错最麻烦，因为它给出的结论方向是反的。

三处错叠在一起，还会带出第四个后果：跨期不可比。上一期没归一、这一期归了，两期的页面总数不能相减，趋势线会凭空多出一段增长。

三、归一化的五个步骤

第一步，去协议。只保留主机名、路径、查询三部分，协议不参与建键。这样 http 与 https 自动落到一起。

第二步，去 www。主机名去掉统一的 www 前缀，同时把主机名转成小写、去掉默认端口。这里要留一张我们自己的例外表：确实把 www 与裸域当两个站用的，写进例外，不合并。

第三步，去跟踪参数。按白名单保留决定内容的参数（文章编号、分页编号这类），白名单外的一律丢掉。跟踪参数与分页参数必须分开对待，分页参数丢掉会把不同内容并成一页，那是另一个方向的错。

第四步，去末尾斜杠。路径末尾的斜杠统一去掉，目录默认页（index 之类）也归到目录上。重复斜杠压成一个，百分号编码统一成大写。

第五步，统一大小写。协议与主机名一律小写；路径保留原样，因为有一部分服务器的路径是敏感的，强行转小写会把两个页面并成一个。放在最后，是因为前四步都会改动字符串。

我们走完五步，得到一串稳定的键。

四、归一化之后，三个指标怎么算

指标：定义 ｜ 单位 ｜ 常见错用
去重 URL 数：归一化键去重后的页面数 ｜ 页 ｜ 用原始串去重，等于没去重
去重域名数：归一化后的主机名去重 ｜ 站 ｜ 把短链主机名当独立来源站
同域多页率：去重 URL 数 ÷ 去重域名数 ｜ 页/站 ｜ 拿它当「内容质量」指标

去重 URL 数回答「有多少个页面被引过」。它适合看长尾，也适合算每页被引次数；分母必须是归一化之后的页面数，否则每页次数被系统性压低。

去重域名数回答「有多少个站在被引」。它适合看信源结构，对策略更有用，因为要动的是站。

同域多页率是两个数相除，单位是页每站。它回答的是：一个站是被整站引用，还是只被引了某一页。这个比值没有好坏含义，只描述形态。同域多页率高，说明这个站有多页被反复召回；低，说明引用集中在单页。

我们拿上面那批数算一遍：294 个页面除以 143 个域名，约 2.06 页每站。前 10 个域名合计被引 528 条，占 902 条的 58.5%，另外有 62 个域名只被引过 1 次。这三个数放在一起说明的是形态：少数站贡献多数引用，长尾里有很多只出现一次的站。同一口径下的三个读数可以并列，不能相除。

五、一个反例：八个参数页算成八个来源

我们看一个反例。假设一个站点的同一篇文章被八个渠道各分享一次，链接带八种不同的跟踪参数。归一化之前，这八条串是八个不同页面，去重后页面数加 8，域名数加 1，同域多页率被抬到 8。

同一次采集里若还有两条短链记录指向这一页，域名数会再加 1，短链主机名与目标站不同。于是同一篇文章在报告里变成了九个来源、十个页面。

归一化之后：五步走完，八条跟踪参数链接收敛成一条，两条短链在解析成功的前提下也收敛到同一条。页面数从 10 降到 1，域名数从 10 降到 1，同域多页率从 10 降到 1。

这个反例要说明「分母变了，指标才成立」，不是「数字变小了」。归一化之前算出的每页被引次数是 0.1，归一化之后是 1；两个数都不假，只是前者在给不存在的页面记账。

短链有个例外要写进口径：解析失败时不要猜，保留原始串并打一个标记，单独报出来。猜错比留空更糟，会被当成正常数据继续往上算。

六、可以直接跑的处理顺序

处理顺序比规则本身更容易出错，我把它固定成五步，写进脚本注释里。

第一步，原始串先落库，不许在抓取阶段就改写。改动只能生成新字段，不能覆盖原值，否则事后没法回答一个问题：这个键是怎么来的？

第二步，解析成五段：协议、主机、路径、查询、片段。不要用字符串拼接去处理链接，边界情况会把代码拖死。

第三步，按上面的五步规则生成键，同时把命中的规则名记下来（去协议、去 www、去参数、去斜杠、转小写）。

第四步，原始串与键两个字段都保留，报告里两个数都报。

第五步，所有下游计数只认键，不认原始串。要写进代码结构里，不能靠调用方自觉。

from urllib.parse import urlsplit, parse_qsl, urlencode

DROP_PARAMS = {"utm_source", "utm_medium", "utm_campaign", "from", "spm", "share_token"}
KEEP_PARAMS = {"id", "p", "page", "aid"}

def normalize(raw: str) -> str:
parts = urlsplit(raw.strip())
host = (parts.hostname or "").lower().removeprefix("www.")
path = "/".join(p for p in parts.path.split("/") if p)  # 压缩重复斜杠、去末尾斜杠
query = [(k, v) for k, v in parse_qsl(parts.query, keep_blank_values=True)
if k in KEEP_PARAMS and k not in DROP_PARAMS]
tail = urlencode(sorted(query))
return f"{host}/{path}" + (f"?{tail}" if tail else "")

我们这段代码只做示例，五步一一对应。上线前补两件事：短链解析（失败留原串加标记）、主机例外表（移动子域、独立的 www）。

七、边界

归一化不改变页面是否存在。键一样不代表链接能打开；404 归一化之后还是 404，链接失效要单独查。

它也不解决内容层的问题。同一个站点的移动子域与主域，是不是同一个「站」，这是口径选择，不是技术事实；选哪种都要写进口径卡，并且两期之间不许换。

短链解析有失败率，解析不到就留原串并标记，别把它当解析成功继续算。镜像站、内容搬运、软 404 这几类，归一化管不到，需要另外一层校验。

我们这套规则能保证的是分母稳定：同一批数据、同一份规则，谁来算都得到同一个键，进而得到同一组数。它保证不了归因——页面数变多不等于策略有效，两件事分开写。

数据口径
数据源：自建采集库 citations 表（项目 56）
查询日：2026-10-27
样本：带被引链接记录 902 条；归一化后去重页面 294 个、去重域名 143 个
口径：只统计回答里给出可点击链接的记录，按归一化键去重；同域多页率＝294 ÷ 143，是同一口径内的派生值，不与其它口径的数相除
局限：单日快照；短链在部分平台无法解析，按留原串计；低于二十条的分组只记数不下结论

本文含 AI 辅助生成内容，经人工核实。

笔者：从事 AI 回答采集与 URL 处理工程的技术作者。