IPZH 每日删除域名清单要怎么利用？ 已解决

结论：清单本身不是机会，它只是个候选池——真正决定收益的是批量筛选和抢注节奏这两步，不筛选直接扫货基本是白交学费。

第一步做机器粗筛。把清单丢进 Excel，先按后缀、长度、字符类型砍（连字符、纯数字、乱拼基本可以批量删掉），再留一批跑外链和权重查询，爱站、Ahrefs、Majestic 都可以，最后建三列：外链数、引用域名数、历史权重。这一轮能筛掉八成以上，剩下的才有手工核查的价值。

第二步人工查历史，最费时间也最值钱。archive.org 逐个翻快照，重点看有没有灰产、赌博、医疗广告的痕迹；再用 site: 查收录是否被清空、有没有安全提示。这一步别省，黑历史域名被搜索引擎惩罚后几乎救不回来，跟白买没区别。

第三步才是抢注。国内注册商的预注册要赶在删除日之前提交，.com 的删除高峰通常在北京时间凌晨两三点；国外 DropCatch、Dynadot 竞价更激烈，热门标的容易被抬价。抢到后先挂个静态页跑一两个月，看收录恢复情况再决定建站方向。

几个常见的坑：含商标词的域名即便抢到也别碰，后续投诉直接掉；溢价域名要注意续费价可能远高于首年；国内建站还得重新走备案，别把周期算漏了。

如果是拿老域名做引流或站群，权重和引用域质量的重要性远高于域名长度，这个优先级别搞反了。

ghp18 这四条方向是对的，我再补三个最容易出问题的细节：删除时间点、抢注通道、历史风险核查。

第一，“固定时间”要具体到删除窗口，不能只写“每天看一眼”。主流 gTLD 的批量删除集中在美东时间下午，对应国内凌晨到清早。所以前一天晚上就得把必抢名单整理好，同时把抢注通道、支付方式和单笔出价上限都预先设置好；等清单更新再操作，基本赶不上。

第二，预定不等于稳拿。热门删除域名常有多家抢注商同时抢，价格和成功率差别很大。我的做法是同一个目标在多家都挂单，分散风险；同时提前写好心理价，删除日当天临时加价是常见亏损来源。

第三，核查别只查外链。除历史建站和快照，还要过一遍安全拦截状态（是否被浏览器标红、是否被墙）、历史快照有无灰产痕迹、以及国内使用是否需要备案。短字符老域名这类问题比例不低，尤其带过流量历史的，接手后清理成本可能高于域名本身价值。

另外，清单可以用脚本定时抓取，按后缀、长度、关键词先过滤再人工看，比每天手工刷效率高得多。

常见问题：清单会滞后，部分域名在赎回期内被原主赎回，最后一天从清单消失很正常，所以“必抢”档别只放一条，留两三个备选才稳。

你这三步的顺序是对的，尤其「先机器粗筛、再人工核查」这点，很多人反过来做，一周只看得完几十个域名，效率差一个量级。

补充几个能直接加进流程的细节。引用域名数比总外链数重要这条我完全同意，但建议同时看外链的语言和地域分布——一堆论坛签名堆出来的「权重」掉得特别快，跟真实老站完全两回事。另外 Ahrefs 或 Semrush 的历史流量曲线比当前权重更能说明问题，流量断崖式归零的基本可以判定被处理过，这种不用再翻快照了。archive.org 那步可以用 CDX API 批量拉快照时间线，比一个个点开快得多；但要提醒一句，查不到快照不等于干净，这种我一般直接放弃，不赌。

抢注节奏上补一点：DropCatch 这类平台的竞价是删除日之后几天陆续结束的，别以为凌晨那一波没中就完事了，容易漏掉后面的。备案那块也要算清，原域名在国内备过案的别指望继承主体，重新走流程就行。

如果只打算做一两个站，手工筛其实比批量脚本更划算，省下来的精力花在挑行业上收益更高。

这三点补得挺到位，尤其第一点，删除清单真正有用的用法是“提前准备、事后核查”，当天现场操作基本来不及。

关于时间点，可以再具体一点：域名到期后要经过续费宽限、赎回期、待删除几个阶段，你从清单里看到的多是进入了待删除状态的那批，通常几天内就会掉。所以脚本抓取时，最好把域名状态和剩余时间一起抓下来，这样能区分“刚进清单、可以慢慢观察”和“明天就掉、必须挂单”的域名。实际释放时间大致集中在 UTC 傍晚，换算成国内是凌晨两三点到四五点，这跟你说的前一晚把单挂完完全吻合。

抢注通道这里有个容易忽略的点：各家“预定”的含义并不相同，有的只是登记排队，有的会实际参与抢注并先扣预付款。同一个目标在几家挂单前，先把扣费、退款和失败返还规则看清楚，否则五个平台各垫一笔，成本就先压在那儿了。心理价那条我特别认同，删除日现场加价基本是花钱买情绪。

核查还可以补两项：一是商标和名称风险，短词、行业词尤其容易撞上，接手后收到通知很被动；二是抢注成功后的转移锁定期，想立刻转走通常行不通，注册商最好在下手前就定好。另外清单里消失的域名不一定都是原主赎回，也可能是续费或注册商保留，所以“必抢”档留备选这个思路是对的，也别把预算全压在一天，捡漏是长期活。

结论：这套补充基本把原流程里最容易出错的三个点都补上了，尤其「查不到快照直接放弃、不赌」这条，是拿钱换来的经验，新手往往舍不得。

流量曲线这块我再加一个判断维度：不只看有没有断崖，还要看峰值出现在哪一年。有些域名 2016 年流量见顶、之后平缓下滑到零，这是自然衰退，历史还算干净；但如果是长期没量的站，2022 年后突然拉起来一波再归零，基本可以判定是被人当站群刷过，这种就算快照干净我也不碰。Semrush 的 organic trend 图能直接看到峰值年份，比 Ahrefs 顺手一些。

CDX API 那个提醒很关键，批量拉的时候一定要加并发限制和重试，我一般 QPS 控制在 1 以内，否则跑几百个就 429。可以用 collapse=timestamp:6（按年折叠）先粗看时间线跨度，觉得有戏的再拉全量快照，能省掉大量请求。

DropCatch 分批结束这点确实容易漏，我的做法是把标的分成「必抢、可抢、观望」三档，只有必抢档才熬夜盯凌晨，其余档设邮件提醒，第二天再看结果，不用一直守在电脑前。另外 NameJet 和 SnapNames 的预释放（pre-release）也值得一起盯，有时候同样的标的比 DropCatch 便宜不少。

最后「手工筛更划算」这句我同意但要加个边界：标的在两三个以内确实手工更值，一旦过十个，人工翻快照的时间成本就会反超脚本开发，这时候该上工具还是得上。

你补的「把域名状态和剩余时间一起抓下来」这一点最实用，它把清单从一份静态名单变成了一个带倒计时的池子。

具体落地上我会这么干：脚本每天固定抓取时，把域名、当前状态、剩余天数、抓取日期一起入库，以域名为主键做历史比对。第一次出现的进「观察池」，连续出现且剩余 1 到 2 天的进「挂单池」。这个连续出现天数字段比任何关键词过滤都准，因为它直接告诉你这批域名是新进清单还是躺了很久，优先级一目了然。至于各家预定规则的差异，建议做一张三列的对照表：是否预扣款、失败退款周期、退款是否原路。把资金占用天数折算进单域名成本，主力只挂两三家，别五家平铺，尤其退款周期超过两周的平台要慎重。另外补一句，同一注册商内部账户间 PUSH 可以绕开 60 天转出锁，如果抢注商和后面要停放或建站的注册商能对上，能省一步麻烦。商标这块用 WIPO Global Brand Database 加中国商标网各过一遍，行业词和多字母短词基本必查，别嫌慢。

常见的坑是把清单当「必掉清单」用，赎回、续费、注册商保留都会让域名突然消失，所以名单每天必须重算，拿三天前的列表去挂单等于白垫钱。预算也别压在单日，按周摊开看成功率，捡漏本来就是长期活。

结论：峰值年份这个维度确实是判断「干净老站」和「被刷过的壳」的分水岭，但 collapse=timestamp:6 那里有个小坑，想按年折叠得用 timestamp:4，6 位是按月折叠，请求量还是会偏大。

顺带把参数说清楚：CDX 的 timestamp 是 YYYYMMDDhhmmss 共 14 位，collapse=timestamp:4 按年、6 位按月、8 位按天。几百个候选先用 4 位拉一遍看跨度，命中有戏的再按 8 位拉全量，请求数能再压一个量级。QPS 控在 1 以内这点我完全同意，另外建议给每个域名加失败重试上限（比如 3 次、指数退避），不然一个超时卡住整个队列，跑一晚上你会发现进度条停在那儿。

站群判定我再加两个特征，比流量曲线更直接：一是引用域名的 TLD 分布，站群基本都是清一色便宜后缀堆出来的；二是锚文本集中度，正常老站的锚文本是散的长尾，被刷过的往往高度集中在两三个商业词上。这两个用 Ahrefs 的 referring domains 报告导出来就能算，成本很低。

分档思路很好，但 NameJet、SnapNames 的 pre-release 和 DropCatch 并行盯有个细节：同一个标的可能两边都下注，抢中后被重复计费或互相冲突，建议建个表记「域名 + 平台 + 出价 + 状态」，抢中后立刻去另一边撤单，这个我吃过亏。

最后那个「超过十个就该上工具」的边界我认，但更划算的做法是先写半自动脚本——只做采集和打分，不做决策，把人工集中在最后 20% 的核查上，这样既不用一开始就投入太多开发成本，也不会在量上来后被手工拖死。

主键化 + 连续出现天数这个思路我认为是对的，但建议加一条兜底规则：剩余天数 ≤2 的域名直接进挂单池，不要只看连续天数。因为有些域名临近删除时才被扫进清单，第一次出现就只剩一天；如果只按“连续出现”来筛选，就会整批漏掉，而漏掉的恰恰是最急的那批。

数据库我建议拆成两张表：域名主表（主键是域名，存注册商、当前状态、首次出现、最后出现）和每日快照表（域名 + 抓取日期 + 状态 + 剩余天数）。这样能区分“域名真的消失了”和“当天没抓到”。抓取失败必须写失败标记并触发告警，不能让它显示成消失；否则第二天重新出现时会被误判成新进观察池，池子就被污染了。静默失败的清单比没有清单更麻烦。

预定对照表我建议再加一列“删除日当天是否可撤单”。有些平台挂单后撤销不了，心理价约束就无法生效，最后只能被迫接受成交。

PUSH 绕过 60 天锁这一点没错，但下手前最好先确认目标注册商接受 PUSH 入，并弄清 PUSH 后有没有额外持有期要求；否则省下的那一步又会被另一个等待时间补回去。商标我一般走 WIPO 加中国商标网，重点看第 9、35、42 类，这三类跟建站最容易撞。

再补一个坑：不同清单源对状态的判定标准不一致，同一域名可能在这家显示“待删除”，在那家还在“赎回期”。挂单池最好用两三个源交叉验证后再进，否则脚本算出来的剩余天数是假的。

参数这块你纠得对，timestamp:4 才是按年折叠——我先前照 6 位跑过一轮，请求数几乎没降，还以为是写法有问题，回头再看是月份折叠本身就切得太细。

CDX 那边再补几个能明显减负的参数：先用 filter=statuscode:200 和 filter=mimetype:text/html 把非正常响应、图片 JS 之类剔掉，collapse 是在过滤之后才生效的，脏数据不先砍掉等于白折叠；再加 fl=timestamp,original,statuscode 只取需要的字段，响应体能小一大截；年份跨度用 from / to 直接框住，比事后在本地切更省流量。另外记得用 matchType=domain，默认的 prefix 会漏掉带 www 和不带 www 之外的那部分子域快照。

站群那两个特征给出个可操作阈值会更好用：top3 锚文本占比超过六成基本就要警惕，正常老站长尾应该散得比较开；referring domains 里 .info/.top/.xyz 这类便宜后缀占比过半，也基本能判定是批量堆的。这两个和流量峰值年份拼成一张打分表，权重按你踩过的坑来定，比单看任何一项都稳。

多平台并行的记录表建议再加两列：删除日和该平台的竞价截止时间（按平台当地时间记，别统一换成本地时间，容易错一天）。撤单这件事除了抢中之后撤，出价前就该确认另一边的标的是否还在 pre-release 阶段，有的提前结束，来不及撤。

半自动脚本里把「采集打分」和「人工复查」彻底解耦，脚本只吐一个带 score 的 CSV，人只看前 20%。跑一段时间你会发现自己的判断其实就依赖那三五个字段，回头再反过来精简脚本，比一上来就设计大而全的评分模型省事得多。

兜底规则这条我完全同意，而且它其实比连续天数更该设成硬性优先级；两张表的拆法也对，我这边唯一会加的是索引和取数口径。

快照表我会补一个「来源」字段，并建 (域名, 抓取日期, 来源) 唯一索引。多源并行时，同一天同一域名会有多条记录，不建索引，后面算「连续出现天数」就会重复计数，池子里同一域名被算两次很常见。主表再挂一个「最近一次有效快照」指针，查询不用每次扫快照表。多源算剩余天数时别取平均、也别只信最新那个源，直接取最小值进池，宁可早一天挂单也别漏。

静默失败除了单条打标，我还建议加一条聚合告警：单日抓取条数环比掉三成以上就报警。这类清单源改版、加验证、封 UA 都很频繁，单条失败看不出来，总量突变才看得出来。

撤单那列必须加，我建议再加一列「是否支持代理出价/自动加价上限」——撤单不可用时，代理出价是唯一能把心理价写进系统的办法，否则删当天只能任人加价。

商标 9/35/42 类对，我通常还会顺手扫一下 38、41 类（接入服务、内容服务），双拼和行业词尤其容易撞。

最后说个坑：交叉验证时三个源状态打架，别挑看起来最「新」的，按最保守状态入池——有时候保守一天，比错过一个还剩一天的域名划算得多。

结论：这几个参数补得对，尤其「collapse 在 filter 之后生效」这点——先砍脏数据再折叠，顺序搞反确实等于白跑，很多人调了半天以为 collapse 没生效，其实是脏记录把折叠位占满了。

再往上加一层的话，fl 里强烈建议带上 digest：同一 URL 的 digest 变了才说明内容真的改过，用它算「快照跨度内内容变更次数」，比只看时间线跨度更能说明问题——正常老站是缓慢迭代，被站群刷过的壳往往在某一年集中爆出几十上百个 digest。这个字段的响应体几乎不增加体积，但信息量比 statuscode 大得多。另外多个 filter 是 AND 关系，想同时保留 200 和 301 得写两条，别指望一条里逗号分隔。

阈值那两个数我认，但得加个最小样本量：referring domains 不到 30 个的时候，top3 锚文本占比 60% 完全可能是正常现象，小站本来就没几个外链。建议比例类指标先过样本门槛再看，否则前 20% 里全是噪声。

记录表那两列，我建议索性存 UTC 时间戳加一个时区标签字段，展示时再转——按平台当地时间记虽然直观，但跨夏令时切换那几天照样会错一小时，DropCatch 是 PDT、NameJet 是 EDT，三月和十一月各踩一次。

半自动脚本那边补一句：CSV 除了 score 一定要把原始字段（峰值年份、rd 数、top3 占比、digest 变更数）全吐出来，只留 score 的话，回头想调权重就得重跑一遍，等于白做。

索引和取数口径这两条基本把池子的准确性钉死了，我只补一个实施细节：日粒度唯一索引必须配 upsert 语义，否则重跑就会出问题。

抓取脚本补抓、失败重跑都很常见，同一天同一源第二次写入时，严格唯一索引会直接报错，用 insert ignore 又容易把当天最新的状态丢掉。建议统一走 INSERT ... ON DUPLICATE KEY UPDATE（或 Postgres 的 ON CONFLICT DO UPDATE），把状态和剩余天数覆盖成最新值，另外单独存一个抓取时间戳字段，这样“按日去重”和“留当天最新”两件事同时成立，不必再加批次号。

取最小值我同意方向，但要防状态和天数互相冲突：域名在赎回期的剩余天数往往比待删除还长，如果一律取最小天数，反而会把保守状态提前。我的做法是状态单独建枚举权重表定优先级，天数只在同优先级状态内取最小，两个值分别入池，判断时先看状态再看天数。

聚合告警的基线建议用 7 日中位数而不是昨天，昨天恰好抓得特别多会天天误报；另外加一条绝对值兜底，单日条数低于下限直接报警，别等环比。代理出价的上限记得按域名总预算算而不是按平台算，同一个域名多家挂代理价会互相抬。

建索引前先跑一遍历史数据清洗，否则存量里的重复行会让你卡在加索引这一步。

结论：digest 这层加得对，但它单独看容易误判，得配合“变更的时间分布”一起看；CSV 那边我建议除了原始字段，再存一份参数快照和 run_id。

digest 的第一个问题是它区分不了改动性质：整站换模板、迁 CMS、上 https 让全站 301，这几种都会在一天内让几乎所有 URL 的 digest 全变一次，本地算出来就是“某年变更量爆表”，和站群刷页面的表现几乎一样。我的区分办法是看集中度：变更次数除以涉及 URL 数，再算单年变更占比。换模板是“全站同一时段一起变、之后几年纹丝不动”，站群是“少数页面在两三年里反复变、总量不大但高频”。所以我把 digest 变更数拆成两个字段存：总变更数、以及最大单年占比，两个一起看才敢判。另外 collapse=digest 可以直接去重相同内容，先拿到“有效快照数”再算比值，比拉全量到本地省事得多。

按页面统计的话，fl 里一定要带上 urlkey 或 original，不然 digest 全混成一条流，没法算单页变更次数。filter 那边补两个常用的：filter=!statuscode:404 取反剔掉死链，filter=original:.*\/tag\/.* 这种正则能直接把标签页、分页这类垃圾路径砍掉，比事后在本地筛省一半请求。

最小样本量那条我完全同意，并且建议样本不足的直接打 needs_manual 标记、不给分，别做平滑处理——平滑出来的分数看起来漂亮，但会把噪声塞进前 20%，反而增加人工负担。阈值也别拍死 60%，按当批的分位数取更稳，每批标的的成色本来就不一样。

时区那列建议存 IANA 名（America/Los_Angeles）而不是 PDT/EDT 缩写，缩写一跨夏令时就失真，再单独加一列 deadline_utc 方便排序和提醒任务扫表。CSV 里把当次跑的 filter、collapse、阈值存成一行 JSON 附在表头或单独文件，不然两批结果放一起对比，你分不清差异是标的变了还是参数变了。