一个条目从上架到下架要过七道闸：目录站内容生命周期全景

很多目录站的运营流程是自然长出来的：先做了提交表单，被灌了一堆垃圾之后加审核，条目多了之后加巡检，出事了再加下架。结果是各个环节之间存在大量缝隙——没人管那些「已经通过但还没上架」的条目，也没人说得清一条三个月前的记录还算不算有效。

把它拆成七道闸，每道闸只回答一个问题，缝隙就看得见了。

图片来源：网络，版权归原作者所有，侵权请联系删除

第一道：提交

回答「这条数据是不是人填的、填得全不全」。这一层的技术手段已经比较成熟：蜜罐字段、时间锁（秒填的表单一律拒）、字段格式校验、以及按 IP 和账号分级限速，触发时返回 429 并带上 Retry-After。

验证码放最后，只在前面几层都通过、但仍然可疑时才弹。一上来就弹验证码，既伤真实用户，又挡不住真有动机的脚本。

这关要记：提交时间、来源、原始字段快照。后面任何一道闸出问题，都要能回溯原始数据。

第二道：自动预检

回答「这条数据有没有硬伤」。域名能不能解析、HTTP 状态码是不是 200、有没有备案信息、是否命中已有的重复条目（文本相似度阈值可以设 0.8，超过就打回）、简介里有没有明显的极限词。

这一关的价值是把人工从机械劳动里解放出来。做得好的话能挡掉七成以上的无效提交，审核只需要看剩下的三成。

第三道：人工审核

回答「这个站是不是它自己说的那样」。人工只看机器判断不了的三件事：站点实际性质与描述是否一致、条目归属的分类是否正确、简介里有没有机器读不出来的夸大表述。

拒稿理由必须写到「对方看了知道改哪里」的程度。「不符合要求」这种回复只会招来重复提交和投诉。

这关要记：审核人、判定结论、拒稿理由。理由留下来还有一个用处——统计高频拒稿原因，反过来优化第二道的自动预检规则。

第四道：上架

回答「它该以什么形态出现在站上」。这一道经常被忽略，但它是 SEO 相关度最高的一环：URL 怎么生成、主分类选哪个（多分类归属时只能有一个主地址）、面包屑走哪条路径、结构化数据标什么类型、sitemap 加不加、要不要主动推送。

规则要提前定死，不能每条临时决定。否则同类条目会出现多种 URL 形态和标记方式，后面统一起来成本很高。

第五道：定期巡检

回答「它还活着吗」。检查四样：域名是否还能访问、页面内容是否发生了实质性变化、有没有被挂马或被标记风险、之前记录的关键信息（名称、域名、性质）是否还成立。

巡检周期按条目重要性分档，不要一刀切。权重高的条目一个月一次，长尾条目一个季度一次足够。

注意误判：临时维护、限流、部分地区不可达都会造成假阳性。规则上要求连续多次失败才标记，不要一次失败就下架。

第六道：变更处理

回答「它变了，站上的信息要不要跟着变」。改名、换域名、性质变化、服务范围调整，这几种情况各有各的处理方式。

这里最容易被忽略的是页面上的日期要和实际变更对齐。只改了页面上的一个数字却更新了日期，属于假更新；反过来内容实质改了却不更新，又浪费了一次重新评估的机会。

第七道：下架与退场

情况	处理方式	不要这么做
临时维护，很快恢复	503 加 Retry-After，sitemap 保留	直接删条目
站点关停，确定不回来	410 Gone	301 到首页
性质变了，不再符合收录标准	404 或 410，从 sitemap 移除	留着壳页面返回 200
内容违规，需要立即处理	先下架再沟通，留快照存证	先沟通等回复

哪几道最容易形同虚设

第五道和第六道。巡检需要定时器和存储结果，变更处理需要比对逻辑，两样都不是上线时必须有功能，于是经常被无限延后。结果是站内挂着一批三年前录入、早就失效的条目。

判断方法很简单：抽样一百条条目，人工核一遍域名和信息是否还有效。失效率超过一成，问题就在巡检这一环，而不是提交审核那一环——再严的审核也拦不住时间。

一句话总结

前四道决定新内容的质量上限，后三道决定老内容的质量下限。目录站做久了，后者的影响更大，因为条目是只增不减的。