批量导入时同名文章怎么处理，按标题查重该放在哪一步

批量导入内容时库里已经存在同题文章该怎么处理，答案是先查后写：搜索端会看到多个近似页面，站内锚文本与站点地图同时把权重摊薄，读者也难判断哪一篇是现行版本。合理顺序是先查重、再提交、后核对，按标题查重的接口调用该放在哪一步也就有了结论——放在拼装数据之前，而不是等报错再回头清理。

重复内容带来的三类后果

第一类是收录分散。同一主题的两篇页面互相竞争，外部链接与内部链接的指向被分开，两处都难做上去。第二类是维护分裂。改版时只改了一篇，另一篇继续以旧口径对外，读者拿到的答案不一致。第三类是统计失真。浏览量与引用被拆到两个地址上，后续判断内容质量时读数偏低。

来源不同，重复的形态也不同。迁移历史内容容易带出旧版本；多来源采集容易带出同题异构；多人协作时改名与新建混用，也会出现标题相近而正文不同的情况。

先查重再提交的顺序

第一步是把待导入条目的标题整理成清单，保留原始标题与规范化后的对比键，避免只差一个空格或标点就被当成两篇。第二步逐条调用查询接口，确认这个标题在库里是否已经存在，把结果分成新增、可更新、需人工判断三类。第三步才拼装正文、分类与标签并提交。

站内提供文档内容的导入接口，路径为 /api/import/archive，同时支持按标题查询是否已存在，这两件事配合起来才能把判重放在写入之前。如果只做写入不做查询，重复会在正式库里出现；如果只做查询不落库，冲突清单还得人工处理一遍。

三条批量路线的差异

压缩包与表格两条路线各有适用面：前者把附件与图片一起带过来，后者胜在结构清晰、便于人工核对。接口路线的成本在于要自己写重试与分批逻辑，好处是判重可以做到每一条上。

分批提交时留出核对间隔。一次推入全部内容再回头排查，重复与错挂分类会混在一起；按批次推进，每批导完检查数量与状态，问题能定位到批内。

导入后的状态检查

导入完成后先看状态分布。文档状态分为正式文档、草稿、待发布与回收站四类，批量写入的结果应当先落在草稿，确认无误后再放开，避免半成品直接进入对外可见范围。草稿可以通过预览参数查看呈现效果，不必先发布。

再检查删除记录。已删除文档进入的是回收站而不是物理删除，这一步决定了误删能不能找回，也意味着重复内容清理后仍要在回收站里确认一次，别留着占位。对分类、标签与站点地图的呈现做一次抽样，看新导入的条目是否按预期出现在列表与导航中。

核对完成再逐批放开状态，最后触发一次链接推送，让新内容与更新内容被搜索引擎及时感知。

常见问题

标题相近但不完全相同算重复吗？ 按规范化后的对比键判断，只差标点与空格的应视为同一篇，正文主题不同的另说，需要人工决定。

导入失败要不要整批重来？ 不建议。按批定位失败条目，剔除或修正后单独重试，避免已成功部分被重复写入。

先查重会不会拖慢导入？ 多一次查询调用，但省掉事后清理，整体更省时间，尤其在上千条规模时差别明显。