Python批量查询域名权重：归一化、限速重试与CSV落表

1. 把“权重”这个词掰开看

先把话说前头：不管外面怎么吹，权重从来不是搜索引擎官方公布的指标。我在圈里摸爬滚打这些年，每隔一段时间就会被问到同一个问题——“我这站权重多少？”问的人里有刚接手的运营，有准备买站的投资人，也有做了七八年还在拿权重当KPI的老手。这个指标被神化得太久了，久到很多人已经忘了它是怎么来的。所以这篇东西不打算复述那些“权重高就是好”的空话，而是把权重查询这件事从头到尾拆一遍：它到底是怎么算出来的、哪些场合值得看一眼、哪些场合纯属自我安慰，以及怎么用几十行脚本把几十上百个域名一次性查完、落成一张能直接拿去决策的表。内容偏实操，写脚本的部分你可以直接复制走改改就能跑；不写代码的部分，也尽量把判断逻辑讲清楚，方便你拿去跟同事或客户解释。

1.1 权重的真实来源：一个第三方推算出来的“印象分”

业内说的“X度权重”，严谨点讲叫第三方预估权重。官方口径里没有这个东西，它是查询平台自己搭了一套模型算出来的：先爬取大量关键词的排名结果，把目标域名在词库中出现的排名位置统计出来，再拿关键词的预估搜索量乘以对应位置的预估点击率，估出一个“预估自然流量”，最后按流量分段映射成 0 到 9 的整数等级。换句话说，权重是流量的粗糙量化，而不是排名能力本身。

用个生活里的类比：外卖平台上的“店铺评分 4.8 分”并不是这家店的口感客观值，它是根据评价数量、好评率、复购率倒推出来的一个印象分。你看到 4.8 会默认它不难吃，但你不会知道它家招牌菜到底合不合你口味。权重也是这个逻辑——它告诉你“这个站在词库和流量估算上大概处于什么量级”，但它不会告诉你这些流量是哪些词带来的、词是商业词还是垃圾词、流量是真人还是刷出来的。搞明白这一层，后面的所有讨论才有意义。

还有一个必须记住的特性：权重是会跳的。平台的词库每周在更新，搜索量指数每季度在调整，模型参数也会改。所以同一个站在不同时间查，出现 1 到 2 级的波动非常正常。有人看到自己站从 3 掉到 2 就慌得不行，其实大概率只是词库采样变了。真正值得警惕的是连续两三周单向下滑，那才可能是站本身出了问题。

1.2 权重真正有用的三个场景，以及四个交智商税的场景

说它有用，是在这几个具体环节里有用：

• 大规模初筛。手上握着几百个候选域名，不管是做行业站群调研、竞品盘点，还是收购前的第一轮筛选，权重是最快的一刀切工具。几百个域名按权重排序，前 20% 拎出来细看，剩下的先放一边，效率提升非常明显。
• 友情链接与内容置换的第一层过滤。对方报过来一个站，权重 5，你至少知道它不是刚上线的空壳；权重 0 但对方自称“新站高潜力”，那就要多问几句了。
• 降权与异常的早期信号。给重点站做一条权重曲线，配合收录量、索引词数一起看，某天开始权重掉、收录也掉，基本可以判定是被处理了，比等流量报表出来早好几天。

说它没用，是在这几个地方：

• 拿它当排名保证。权重 4 的站照样有词上不去，权重 2 的站照样有词排第一，因为权重是结果不是原因。
• 拿它当精确流量值。权重 5 的站日流量可能是 800，也可能是 6000，跨行业差异巨大。
• 只看权重不看词库结构。一个权重 4 的站，词库里 90% 是“XX是什么意思”“XX怎么读”这类无商业价值的泛词，跟一个权重 3 但词全是产品型号的站，变现能力天差地别。
• 拿它判断“这站是不是作弊”。刷出来的权重和真流量在数值上可以一模一样，必须结合收录速度、外链结构、页面质量一起看。

1.3 为什么“一键批量查询”值得自己动手

手工查一个域名大概 15 到 20 秒：打开平台、输入、等结果、把数字抄进表格，还得来回切换两三个平台交叉核对。五十个域名就是十几分钟纯机械劳动，中间还会抄错两个。如果要同时看两家搜索引擎的权重，时间直接翻倍。我这次做的是一个能一口气跑几百个域名的小脚本，输入一份纯文本域名清单，输出一张带权重、查询状态、查询时间的表格。实跑下来，500 个域名大约 15 分钟跑完，全程不用盯着，跑完直接出表。这个投入产出比对经常做域名筛选的人来说非常划算，所以下面把整个过程完整写出来。

2. 整体设计与技术选型

2.1 四条路线的取舍：为什么最后选了自建脚本

动手之前我把常见方案都过了一遍，各自的短板很明显：

我选自建，核心原因不是省钱，而是字段可控。现成工具给你什么字段你就只能看什么，而实际做判断时我需要的是“两个搜索引擎权重 + 查询状态 + 查询时间戳 + 是否曾用名”这一整套，甚至要把历史结果存下来做趋势。另外，批量查询本质上是高频请求别人家的服务，额度限制和频率限制是绕不开的，脚本里可以自己控制节奏，比在工具里被动等额度更从容。

注意：批量查询第三方平台的数据，一定要把请求频率压到对方能接受的水平。二三十分钟跑完几百个域名，对你没什么损失，对平台是压力。控制在每个域名间隔 1.5 到 3 秒、单线程或最多两三个并发，既跑得完，也不至于给对方添麻烦。

2.2 技术栈选择：为什么是 Python

选 Python 有三个很实际的理由。第一，字符串清洗和正则处理是它的强项，而域名归一化这一步几乎全是正则活；第二，请求库成熟，处理超时、重试、会话复用都是几行代码的事；第三，标准库自带 CSV 读写，不用装任何东西就能出表，脚本拷到任何一台装好 Python 的机器上都能跑。

如果你更熟悉其他语言，逻辑完全一样，照着改就行，真正值钱的是流程设计而不是语法。我给脚本定的依赖原则是：能用标准库解决就不装第三方包，最后只用了requests一个外部库，剩下的re、csv、time、random、urllib.parse全是自带的。这样迁移成本最低，同事接手也不用配一堆环境。

2.3 一条数据从输入到落表要过七道关

整条链路我拆成了七步，每一步都有人为决策点，不是纯粹的技术实现：

1. 输入清单整理：从表格、聊天记录、竞品报告里把域名抠出来，先堆成一列纯文本。
2. 域名归一化：去协议、去路径、去端口、转小写、处理 www，这一步不做，后面全是重复查询和查不到。
3. 去重：归一化之后再去重，能省掉 10% 到 20% 的无用请求。
4. 请求构造：UA、Referer、语言头、超时时间，这些直接决定你能拿到数据还是拿到一堵墙。
5. 限速与重试：随机间隔、指数退避、连续失败熔断。
6. 结果解析：优先找结构化字段，退而求其次用锚定正则，查不到就记 NULL，绝不能记 0。
7. 落表与标记：输出 CSV，加一列状态位，方便事后筛出需要人工复核的行。

这里面第 2 步和第 6 步是最容易翻车、也最容易被忽略的两步，下一节专门展开。

3. 细节决定成败：三个最容易翻车的地方

3.1 域名归一化：五花八门的输入怎么变标准域名

真实场景里的输入有多乱，你可能想象不到。同一批清单里出现过这些形态：https://www.abc.com/about?x=1、ABC.COM、abc.com/、www。abc。com（中文句号）、abc.com:8080、带空格的、带换行的、带备注的、甚至有人把网址和“权重3左右”写在同一行。如果原样丢进查询接口，结果是查询成功率只有六成，剩下四成全是因为格式不对返回空值。

所以归一化的规则要定死：

import re from urllib.parse import urlsplit def normalize(raw: str): if not raw: return None s = raw.strip().lower() # 中文标点、全角字符先统一 s = s.replace("。", ".").replace("．", ".").replace("：", ":") # 干掉所有空白（含全角空格） s = re.sub(r"\s+", "", s) if not s.startswith(("http://", "https://")): s = "http://" + s host = urlsplit(s).hostname or "" host = host.rstrip(".") # 去掉尾部点 if host.startswith("www."): host = host[4:] # 统一成裸域再查 if not re.fullmatch(r"(?:[a-z0-9-]+\.)+[a-z]{2,24}", host): return None # 明显不是域名，直接丢弃 return host

关于www.要不要去掉，这里有个判断依据：大多数查询接口把www.abc.com和abc.com当成两个不同实体，如果你不统一，就会出现“裸域有权重、www 是 0”的诡异结果。稳妥做法是统一成裸域查询；少数站确实把主域重定向到 www 且数据只挂在 www 上，所以我在最终跑批次时会额外对权重为空的行补查一次带 www 的形态，命中就取较大值。这一步让我的最终成功率从 82% 提到了 94%。

3.2 请求头与参数构造：看起来最简单的部分最容易出问题

很多人脚本跑出来一片空白，第一反应是“接口变了”，实际上八成是请求头太假。默认的python-requests/2.x这个 UA 在某些站点的第一层过滤里就会被拦。最少要补齐三样：一个常见的桌面浏览器 UA、一个Accept-Language: zh-CN（不写的话有些站点会走国际版逻辑，返回结构都不一样）、以及一个同域的Referer。

超时时间给 10 秒比较合适。给 3 秒会有一批慢响应被误判为失败，白跑；给 30 秒又会让个别卡死的请求拖住整个批次。参数方面，绝大多数查询接口就是domain加一个可选的查询类型，用 GET 走查询字符串即可，参数值记得做 URL 编码，虽然归一化之后一般不会出现特殊字符，但保留这个习惯能少踩坑。

提示：一定要用requests.Session()复用连接，而不是每次requests.get。几百次请求下，复用连接能把整体耗时压掉三到四成，对一个要跑十几分钟的批次来说差别很大。

3.3 限速、重试与熔断：让脚本能安心跑一整晚

限速不是礼貌问题，是能不能跑完的问题。我的设置是：每个域名之间随机睡 1.5 到 3 秒，用随机数而不是固定值，是因为固定间隔的请求节奏太规整，容易触发频控；随机间隔更像人操作。重试采用指数退避：第一次失败等 1 秒，第二次 2 秒，第三次 4 秒，再加一点随机抖动，避免多个域名在同一秒集中重试。

另外加了一个熔断条件：连续 3 个域名都返回空结果，就整体暂停 60 秒。这个逻辑救过我一次——某次跑到第 120 个域名时开始连续空返回，我以为是域名本身有问题，熔断暂停后再继续，后面的数据全正常了，说明那 60 秒里对方在限流。没有熔断的话，那一段会白白烧掉三四十个域名，最后还得把这段全部重跑。

3.4 结果解析：宁可记 NULL，也不要记成 0

解析的原则只有一条：“查不到”和“权重是 0”是两件完全不同的事，绝对不能混。这一条听起来是常识，但我见过太多表格把空值填成 0，最后一排序，一批本来很好的站排到最后，决策直接错掉。

实现上分两级。第一级找结构化数据：现在多数页面会有一个 JSON 数据块或者带>def parse_weight(html: str): # 一级：结构化字段 m = re.search(r'"br"\s*:\s*(\d{1,2})', html) if m: return int(m.group(1)) # 二级：锚定“权重”附近的数字 for anchor in re.finditer(r"权重", html): window = html[anchor.end(): anchor.end() + 200] m2 = re.search(r"\b(\d{1,2})\b", window) if m2 and 0 <= int(m2.group(1)) <= 10: return int(m2.group(1)) return None

4. 从零到跑通：完整脚本与实操记录

4.1 环境准备与依赖安装

只装一个包，剩下的用标准库：

python -m venv venv source venv/bin/activate # Windows 下是 venv\Scripts\activate pip install requests

目录结构就三个文件：domains.txt（一列一个域名，随便多乱都行）、query_weight.py（主脚本）、weight_result.csv（跑完自动生成）。

4.2 核心代码分段说明

查询函数是整个脚本的骨架，重点在重试和返回值的语义：

import random, time, re, csv, requests HEADERS = { "User-Agent": ("Mozilla/5.0 (Windows NT 10.0; Win64; x64) " "AppleWebKit/537.36 (KHTML, like Gecko) " "Chrome/124.0.0.0 Safari/537.36"), "Accept-Language": "zh-CN,zh;q=0.9", "Referer": "https://example.com/", } def query_weight(session, domain, retry=3): """返回 (权重, 状态)。权重查不到时返回 (None, 'null')， 绝不返回 0，方便后续人工复核。""" params = {"domain": domain} for i in range(retry): try: r = session.get("https://example.com/api/weight", params=params, headers=HEADERS, timeout=10) if r.status_code == 429: time.sleep(30 + random.uniform(0, 10)) continue if r.status_code == 200 and r.text: w = parse_weight(r.text) return (w, "ok") if w is not None else (None, "null") except requests.RequestException: pass time.sleep(2 ** i + random.uniform(0, 1)) return None, "fail"

批处理主循环里做四件事：归一化去重、逐个查询、随机限速、实时打印进度。进度打印别省，跑十几分钟的东西，没有进度输出你根本不知道它是在跑还是卡死了。

def run_batch(in_path="domains.txt", out_path="weight_result.csv"): session = requests.Session() seen, rows, null_streak = set(), [], 0 with open(in_path, encoding="utf-8") as f: raw_list = [line for line in f if line.strip()] for idx, raw in enumerate(raw_list, 1): d = normalize(raw) if not d or d in seen: continue seen.add(d) w, status = query_weight(session, d) if status == "null": null_streak += 1 if null_streak >= 3: print(f"[熔断] 连续空返回，暂停 60 秒 @ {d}") time.sleep(60) null_streak = 0 else: null_streak = 0 rows.append({ "domain": d, "weight": w if w is not None else "", "status": status, "ts": time.strftime("%Y-%m-%d %H:%M:%S"), }) print(f"{idx}/{len(raw_list)} {d:<32} {status:<5} {w}") time.sleep(random.uniform(1.5, 3.0)) with open(out_path, "w", newline="", encoding="utf-8-sig") as f: writer = csv.DictWriter(f, fieldnames=["domain", "weight", "status", "ts"]) writer.writeheader() writer.writerows(rows) print(f"完成，共 {len(rows)} 条，输出至 {out_path}")

最后那行utf-8-sig是个小细节，加了之后表格软件打开中文不会乱码，不加的话在部分环境下第一行变成乱码，虽然不影响数据但看着很难受。想双击运行的话，在 Windows 上再补一个run.bat，内容就一行python query_weight.py & pause，pause一定要加，否则跑完窗口闪退，你连结果都看不到。

4.3 一次 500 域名的实跑记录：耗时与失败率

我把手上一个行业调研的清单拉出来跑了一遍，500 个域名，混合了新站、老站、子域、带路径的脏数据。实测结果如下：

那 27 条老版本记录里的空值，我抽出 10 条人工复核了，其中 8 条确实是未被收录的新注册域名，2 条是子域名（blog.abc.com这类），主域有权重但子域在原平台没单独统计。这说明结果表里的空值不是错误，而是有价值的信息本身——它告诉你“这个域名在公开数据里几乎不存在”，对判断站点新旧程度很有参考价值。

耗时上有个可以优化的点：如果把随机间隔压到 1 秒，总耗时可到 9 分钟左右，但我不建议这么做，尤其是一次性跑上百个域名的时候，稳比快重要得多。真要赶时间，把批次拆成两半、隔开几小时跑，比提高频率安全。

4.4 结果处理：分级、交叉验证、导出

拿到原始表之后不要直接看，加两列加工字段会好用很多。第一列是分档：0 到 1 记“低”、2 到 3 记“中”、4 以上记“高”，排序时按档看更符合直觉。第二列是是否需要复核：状态为 null 且域名长度较短（说明可能是主域）的，标记出来人工过一遍。

第二个搜索引擎的权重我是单独跑一遍脚本、把接口换掉、结果存成另一个 CSV，最后按域名做一次关联。两个引擎的权重不一致是常态，一般差 1 到 2 级都很正常，差 3 级以上就值得点进去看看，通常是某个引擎的词库覆盖不同，或者站点在某个引擎上有明显的地域或内容偏向。这种差异本身就是信息，别急着“取平均值”，平均出来的数字没有任何含义。

5. 常见问题与排查实录

5.1 常见现象速查表

5.2 三次真实排查过程

第一次是脚本刚写完，跑 20 个测试域名，结果 20 个全空。我一开始怀疑接口变了，把返回内容打印出来一看，是一段“请开启 JavaScript”的提示页——典型的 UA 拦截。换成完整浏览器 UA 之后立刻正常。这个坑提醒我：脚本拿不到数据时，第一件事永远是打印原始返回内容，不要靠猜。大多数人卡在这一步是因为只看了“解析失败”，没看“返回了什么”。

第二次是批量跑到 120 多条时开始连续空返回，我以为是这批域名都比较新，差点就认了。后来加了个简单的判断：把连续空返回的域名单独存一份，跑完再补查，结果补查时九成都有了数据。这说明是频控而非域名问题。于是我加了熔断逻辑，之后同类问题再没出现过。这个经验很值钱——连续失败往往不是数据的问题，是节奏的问题。

第三次比较隐蔽：某批数据里有一批域名权重显示为 0，我觉得奇怪，因为其中几个站我确定是有流量的。查了解析逻辑才发现，页面在这些域名上返回的结构略有不同，我的正则锚到了页面上另一个数字（一个统计计数），刚好是 0。这就是为什么强调“锚定上下文”。改法是把锚点窗口从 200 字符缩到 80 字符，并且要求数字前面不能紧跟字母或斜杠。

5.3 把查询结果变成判断：几条交叉验证规则

单看权重容易误判，我总结了三条自己一直在用的交叉规则，写出来供参考：

• 权重 + 收录量一起看。权重 3 但收录只有几十条，多半是刚起来的站或者内容极少的站；权重 3 但收录几万条，说明内容量在那儿，但流量没起来，可能是词太偏。
• 权重 + 域名年龄一起看。新注册域名很快就有 3 级以上权重，需要多看两眼，正常站点的权重爬升是有过程的；反过来，一个七八年的老域名权重是 0，要么是废弃站，要么是历史上有问题被处理过。
• 两个引擎的权重差值。两边都在 4 以上，说明站的整体质量在那；一边 5 一边 1，通常说明这个站的流量结构单一，只被某一家收录得好，抗风险能力差。

6. 权重之外：我在实际项目里怎么用这套表

6.1 换链接与站点评估的评分卡

我现在评估一个置换或合作对象，权重只占三成，剩下的七成看别的。我做了一张简单的评分卡：权重分档（0 到 3 分）、收录量（0 到 3 分）、词库结构（0 到 3 分，看商业词占比）、更新频率（0 到 2 分，看近三个月有没有新内容）、页面质量（0 到 2 分，看有没有大量低质聚合页）。十三分制，8 分以上才会进入下一轮沟通，6 到 8 分待定，6 分以下直接跳过。这套标准比单纯看权重靠谱得多，也让我少踩了好几次“权重挺高但内容全是搬运”的坑。

有一点特别提醒：不要用权重作为唯一报价依据。有些站主会把自己的权重报得比实际高，甚至用不同的查询平台口径来谈。谈之前自己跑一遍脚本，两个引擎都查一遍，数据摆在桌上，后面的话就好说了。

6.2 权重曲线：比单次查询有用十倍的东西

单次数值只反映当下，真正有决策价值的是曲线。我的做法很简单：把每次跑出来的 CSV 全部留着，文件名带日期，隔一周跑一次同样的清单，用表格软件的透视功能拉出每个域名的历史序列。这条曲线能提前暴露很多问题：某站权重连续三周从 4 掉到 2，同时收录从 8 万掉到 3 万，基本可以判定是被处理了，这种站在谈合作时要多留个心眼；反过来某站权重三个月从 1 稳步爬到 3，收录也在涨，说明运营是持续的，这种站反而是性价比最高的合作对象。

维护这个清单的成本极低：每周花两三分钟跑一遍脚本，一年多下来积累的趋势数据，比任何第三方报告都贴合自己的业务场景。

6.3 几条踩过的坑，写下来省你时间

• 别把权重当流量。我早期做过一次投放测算，按权重估流量，结果偏差三倍多，后来老老实实看第三方流量估算和关键词词库，才把误差压下来。
• 别在白天高频跑批量。对方平台白天负载高，响应慢、限流严，同样的脚本放到深夜跑，成功率和速度都明显更好。
• 结果表一定要带时间戳。我吃过一次亏：一份旧 CSV 和新数据混在一起分析，得出“某站权重掉了 2 级”的错误结论，其实是半年前的旧数据。加上时间戳列之后这类问题彻底消失。
• 留一份原始返回内容。调试阶段建议把每次请求的返回内容按域名存成文件，出问题时能直接回看，比重新跑一遍省事得多。稳定运行之后可以关掉，但前两周强烈建议开着。
• 域名清单要版本化。我自己维护的清单目录里，每批任务一个文件夹，里面放输入清单、输出结果、当时的备注。半年后回头看，你才知道当初为什么把这个站筛掉了。

这个内容后续还可以往两个方向延伸：一是把查询结果接到一份简单的自动化报告里，每周定时跑、自动生成对比表；二是在权重之外再补几个维度（收录量、索引词数、域名年龄），做成一张完整的站点体检表，那样这套脚本的价值就不只是“查权重”，而是变成了一个小型的站点数据中台。我个人在实际操作中的体会是，工具本身不值钱，值钱的是你清楚每个数字的边界在哪里、什么时候不该信它。权重就是典型例子：它是个很好用的筛子，但你绝不能把它当成结论。