网站被DDoS打到停机，服务恢复正常后很多人以为事情就此结束，其实搜索端的账才刚开始算。本文用 10 个问答讲清收录恢复的完整顺序：攻击期间该给什么状态码、恢复后先做什么、为什么有些操作会让掉收录变得更严重。
Q：网站被DDoS打停几天，收录真的会掉吗？
- 会，但这通常不是「惩罚」，而是抓取机制的自然结果。
- 搜索引擎按抓取预算分配资源。某个站连续抓取失败，预算就会被挪给别的站，重访间隔从一天拉长到一周甚至更久。
- 更严重的是：长期返回服务器错误的页面，会被判定为不可用，逐步从索引里移除。停得越久、状态码越糟，移除得越快。
- 还有一层隐性损失：停机期间产生的新内容没被收录，对应的长尾词位置被同行拿走，这个回来得更慢。
- 真正决定伤害大小的不是停机时长本身，而是这几天你返回了什么状态码。
Q：攻击期间到底该返回什么状态码？
- 503 加 Retry-After，没有第二个正确答案。503 的语义就是「服务暂时不可用」，Retry-After 告诉爬虫多久之后再来。
- 不要返回 404：那等于告诉搜索引擎这些页面没了，索引会被直接清掉。
- 不要返回 500 / 502 / 504：这些是「服务器坏了」的信号，比 503 伤害大得多。
- 也不要 200 返回一个空白页或纯报错文本，空页面会被判成低质内容。
- 用 301 跳到别处更不可取，跳转链条一多，权重传递会被打折扣。
- 维护开关做成一行可切换的，攻击来了立刻生效：
# 存在 /etc/nginx/maintenance.on 这个文件就进入维护模式
server {
location / {
if (-f /etc/nginx/maintenance.on) {
return 503;
}
# 正常业务配置
}
error_page 503 /maint.html;
location = /maint.html {
internal;
root /var/www/static;
add_header Retry-After 3600 always;
add_header Cache-Control "no-store" always;
}
}- Retry-After 建议给 1800 到 7200 秒。给太短会让爬虫频繁重试、反过来加重源站负担；给太长又会让它彻底不来。
Q：攻击期间能不能用 robots.txt 全站 Disallow？
- 不建议，这是恢复期最容易被踩的坑。
- 全站 Disallow 之后爬虫拿不到内容，已收录的页面会被逐步移除。等你放开 robots，一切要从头爬，等于把停机时间人为拉长一倍。
- 而且 robots 只约束守规矩的爬虫，攻击者根本不看这个文件。
- 正确做法：robots.txt 保持正常，用 503 表达「暂时不可用」。这两者的区别在于，503 保留了页面的存在性，Disallow 则是主动让页面消失在索引里。
- 如果只是某个目录要临时关闭，可以精确 Disallow 该目录，但同样有移除风险，能不用就不用。
Q：攻击停了，第一步该确认什么？
- 先确认服务真的恢复了，再谈收录。顺序错了会白忙一场。
- 四个检查项：多线路拨测是否都是 200、源站日志里可疑请求是否消失、首字节时间是否回到正常水位、CDN 有没有把错误页缓存下来。
- 最后一项是最常见的坑。攻击时 503 页面被 CDN 缓存，攻击停了用户还是看到 503，直到缓存自然过期，白白多损失好几天。
- 缓存规则里必须写明「只缓存 200，不缓存 4xx/5xx」：
# 4xx/5xx 一律不进缓存
map $upstream_status $skip_cache {
default 0;
~^[45] 1;
}
proxy_no_cache $skip_cache;
proxy_cache_bypass $skip_cache;
proxy_cache_valid 200 301 302 10m;
proxy_cache_valid 404 1m;
# 事后排查：响应头里有没有命中缓存
curl -sI https://www.example.com/ | grep -iE "x-cache|age|via"- 确认被污染后要主动刷新（按 URL 或全量），别等它自己过期。
Q：收录恢复的操作顺序是什么？
- 第一步，清掉 CDN 与本地缓存里的错误页，确保核心页面返回 200。
- 第二步，检查 robots.txt 和 sitemap 能正常访问，sitemap 里不要留 404 / 5xx 的地址。
- 第三步，在搜索资源平台重新提交 sitemap。同一个账号一天别重复提交多次，重复提交不会更快。
- 第四步，用平台的抓取诊断或 URL 检查，提交首页加几个核心栏目页，看抓取是否成功、渲染有没有问题。
- 第五步，把攻击期间下掉的内链、首页入口恢复回去。很多人只记得改回来，忘了内部链接还断着。
- 第六步，保持站点稳定，这时候最忌讳的就是顺手改个版。
- 记住一点：提交不是加速包，它只是让爬虫早点知道你已经回来了。
Q：为什么不能等它自己来抓？
- 因为重访间隔可能已经被拉长了。原本一天来三次，停机一周后可能变成一周来一次，纯等自然恢复要拖几周。
- 主动提交能明显缩短发现周期，但要克制：不要一口气提交几千个 URL，异常提交行为本身会被降权处理。先交首页和核心页，让抓取预算慢慢回来。
- 也别去买所谓「快速收录」「包上首页」的服务，多数是垃圾外链或镜像站，短期看着有量，长期是负资产。
Q：恢复期能不能改版、改标题、改 URL？
- 都尽量不要。攻击、改版、改 URL 三重叠加，爬虫很难判断这个站到底稳不稳定。
- 确需改 URL 的，用 301 永久跳转，并保留至少六个月（权重传递慢的站要一年）。同时更新 sitemap 和站内所有指向旧地址的链接。
- 标题可以微调，但不要批量改；导航结构、模板、栏目划分在恢复期一律不动。
- 恢复期最需要传递的信号是「稳定」：稳定的 200、稳定的更新节奏、稳定的结构。任何剧烈变化都会推迟恢复。
Q：怎么判断收录已经在回来了？
- 看五个指标：蜘蛛抓取次数、抓取异常数、索引量、展现量、sitemap 提交成功率。
- 日志层面最直接、也最快能看到变化，统计蜘蛛 UA 的日均抓取量和状态码分布：
# 每日蜘蛛抓取次数（第 4 列是时间，取日期部分）
grep -i "baiduspider" /var/log/nginx/access.log | \
awk '{print $4}' | cut -d: -f1 | sort | uniq -c
# 蜘蛛拿到的状态码分布，200 占比是核心指标
grep -i "baiduspider" /var/log/nginx/access.log | \
awk '{print $9}' | sort | uniq -c | sort -rn
# 只看异常，快速定位是否还有 5xx
grep -i "baiduspider" /var/log/nginx/access.log | awk '$9 ~ /^5/' | tail -50- 经验值：蜘蛛的 200 比例从六成回到 95% 以上，通常一周内能看到索引回升；索引量的恢复一般比抓取恢复滞后一到三周。
- 如果两周过去抓取量还是上不来，问题多半不在收录，而在站点本身：要么还有未清理的错误页，要么结构变了。
Q：为什么有的站一周就恢复，有的掉半年？
- 站点权重与历史稳定性：长期稳定运行的站，短期故障影响小；本来就不稳的站，一次长停可能就是最后一根稻草。
- 更新频率：日更站抓取预算本来就高，恢复快；半年不更新的站预算极低，回来很慢。
- 停机时长与状态码：503 停一周，和 502 停一周，结果完全不同。
- 内容质量底子：本身靠采集拼凑的站，长停之后很可能直接掉出索引，因为没有不可替代的内容支撑。
- 新站最吃亏，没有历史信任度可透支，恢复周期普遍更长。
Q：还有什么补充建议？
- 预防远比恢复便宜：把 503 维护页提前做好、开关一行能切、CDN 不缓存错误页、蜘蛛抓取成功率纳入监控。
- 建议加一条告警：蜘蛛请求的 5xx 比例连续十分钟超过 20% 就报警。这条比看流量曲线更早发现问题。
- 每次故障都留一份记录：什么时候开始、返回了什么状态码、什么时候恢复、观察到哪些指标变化。下次遇到同样的情况，处置会快得多。
- 最后一句判断：收录恢复不是提交出来的，是稳定运行换来的。工具只能缩短发现时间，真正决定结果的是站点恢复之后能不能一直稳定。