先别把整次发布回滚。更稳的做法是:在发布记录里找出草稿混入的时间窗,然后按“是否可被访问、是否进入索引候选、是否被站内链接或站点地图引用”三条线分别圈定范围。范围清楚后,再决定哪些内容保留、哪些改写后重发、哪些直接退出。
草稿能造成多大影响,取决于它当时处于哪种状态。常见有三种:
判断动作很具体:抽几条草稿地址,用无登录状态的浏览器请求一次,记录返回状态和正文是否可见;再在站内搜索该地址,看是否有页面链接到它。如果站内搜索能命中,说明它已经进入引用网络,影响范围要按“被引用”这一档处理,而不是按“临时文件”处理。
逐条翻草稿容易漏,尤其是批量发布时。更可靠的是先定时间窗:找到发布任务开始和结束的时间戳,把这段时间内新增或变更的地址全部列出。然后对每个地址做两件事:
如果草稿只是独立地址、没有任何入口,影响范围通常限于它自身;如果它被挂进了分类页或推荐位,影响范围就扩大到那些入口页,因为入口页的链接结构变了。此时要优先处理入口页,而不是只删草稿本身。
这里有一个容易误判的点:某条草稿的请求量归零,不等于它从未被处理。也可能是采集工具没有覆盖、日志采样缺失,或者它本来就没有搜索需求。反过来,某条草稿出现少量请求,也不必然说明它已进入索引,可能只是内部访问或爬虫试探。把请求量当作唯一证据,容易把范围圈错。
圈定范围之后,每条草稿面临三种处理,适用前提不同:
一个假设例子:某次发布混入了五条草稿,其中两条被栏目页引用,三条是独立地址。处理时先把两条从栏目页移除,再判断它们是否值得改写;三条独立地址若确认无引用,可直接退出。这样做的结果是把工作量集中在两个入口页上,而不是平均分配给五条草稿。下一步再检查入口页是否恢复正常链接,而不是继续追查那三条独立地址。
处理完成后,验证要围绕“入口是否恢复、地址是否返回预期状态、站点地图是否更新”展开,而不是盯着某一天的流量数字。一次改动前后的比较,需要考虑季节、搜索需求变化和数据采集差异;请求量下降或上升都不能单独证明处理正确。
实际动作可以这样安排:先确认被引用页面不再指向草稿地址,再确认草稿地址本身返回预期状态,最后看站点地图和站内搜索是否还有残留入口。如果这三步都通过,影响范围基本闭合;如果还有入口残留,说明范围圈小了,需要回到引用关系那一层重新排查。验证周期不必设固定天数,按发布频率和抓取节奏安排即可,不要承诺某个日期前一定恢复。