今年三月我第一次打开 Google Search Console 的「手动操作」页面，看到一条红色的「纯垃圾外链」标记悬在两个中文站上。那一天的感受很难形容：站点还能打开，日志里还有爬虫，但搜索流量已经连续两周下滑，我一开始以为是算法更新，换关键词、改标题、加内链，全都无效。直到点开这个平时几乎不会看的页面。
这篇文章讲的是之后的处理过程：怎么读这条通知、怎么自查、怎么清理、怎么提交复审，以及在这期间怎么判断哪些伤害是真的。整个过程用了六周，两个站分别在提交后第九天和第十六天解除。我把能复用的部分整理下来，希望别人遇到时少绕弯路。
一、先分清是「手动操作」还是「算法影响」
这两件事在 Search Console 里长得完全不一样，处理方式也完全不同，第一步就必须分清：
- 手动操作：出现在「安全和手动操作」→「手动操作」里，有明确的名称（比如「纯垃圾外链」「用户生成的垃圾内容」「隐藏的文字或链接」），一般伴有「影响范围」说明。这是人工或规则审核的结果，会一直挂着直到你处理并复审通过。
- 算法影响：不会在这里出现任何通知。流量下滑要去「效果」报告里看，通常表现为全站或某个主题集群同时下降，且时间点和官方公布的核心更新日期吻合。
我当时的误判就在这里：先按算法问题处理了两周，改了一堆页面标题和描述，指标毫无起色。回头看，如果第一天先看这个页面，能省两周。现在我把这个页面加进了每月固定检查项，和证书到期、磁盘使用率放在一起。
二、读通知：名称背后对应的具体问题
不同类型的通知，自查的方向完全不同。我遇到的是「纯垃圾外链」，但常见的还有几种，各自对应不同的定位方法：
# 导出外链数据做排查（以 Search Console 导出为起点）
# 需要关注的字段：来源域名、链接数、首次发现时间、目标页面
# 站点侧先统计一下自己有多少页面被大量外链指向
grep -c 'href=' /var/log/nginx/access.log # 粗看是否有异常来源读通知要看三件事：名称（问题类型）、影响范围（是整站还是部分页面）、样例链接（Search Console 会给几个具体 URL，这是最有价值的线索）。样例链接指向的往往不是流量最大的页面，而是当时最容易被利用的页面——我这边是评论区和用户投稿页。
还有一点容易忽略：通知里如果写了「影响整个网站」，那这条标记会影响全站所有页面；只写「影响部分网页」，影响范围就有限。我其中一个站是前一种，另一个是后一种，处理优先级因此不同。
三、自查：先弄清「外链」和「内容」是两件事
拿到通知之后，最忌讳的动作是立刻开始删页面、改模板。先要判断问题到底出在「外部有人给链接」还是「自己的内容有问题」，这两者的处理路径完全相反。
判断方法很简单，看通知的类型和样例链接：
- 如果样例指向的是自己的正常文章，且这些页面内容质量没问题：大概率是外链问题，你被动中枪。清理方向是「拒绝外链」，而不是改内容。
- 如果样例指向的是评论区、投稿页、搜索结果页、标签聚合页：通常是这些页面上出现了大量用户生成的垃圾内容或隐藏链接，需要处理的是这些「可被注入」的入口。
- 如果样例指向自己批量生成的低质量页面：这是内容问题，只有删除或大幅改写一条路。
我那两个站属于第二种：评论区没有审核，被脚本刷了几万条带链接的垃圾评论，页面被渲染出来之后就是一堆外链。这解释了为什么「页面还正常、流量却掉了」——页面对人正常，对搜索引擎是一片垃圾。
四、清理：分「止血」和「治疗」两步
止血指的是立刻关掉被利用的入口，让新的垃圾进不来；治疗指的是把已经产生的垃圾清掉。顺序不能反，否则一边清一边进，永远清不完。
止血（当天就该做）：
- 评论区改成「先审核后展示」，或者直接关闭匿名评论。
- 所有能提交内容并立即展示的入口（留言、投稿、站内搜索页结果、标签页）加一层过滤，含链接的提交进人工队列。
- 搜索结果页、标签聚合页、分页过深的列表页统一加
noindex，这些页面本来就不该进索引。
# Nginx 层对可疑提交做速率限制（示例）
limit_req_zone $binary_remote_addr zone=comment:10m rate=1r/s;
location = /comment.php {
limit_req zone=comment burst=5 nodelay;
include fastcgi_params;
}治疗（一到三天）：
- 把垃圾评论、垃圾投稿全部删除，并且删除时确保数据库里真的删掉了，而不是只在前台隐藏。
- 检查有没有被注入的隐藏链接：
display:none里的<a>、颜色和背景同色的文字、font-size:0的内容。这类东西在数据库里是明文，用 SQL 查比肉眼翻页面快得多。 - 如果站点曾被人挂过黑页或跳转脚本，要一起清理，残留一个就可能让复审不过。
清理之后必须自己验证一遍：抽查二十个原样例链接，确认页面上再无相关外链；grep 一遍数据库，确认没有残留的垃圾关键词。我第一轮复审没过，就是因为有两个页面还残留着垃圾评论的 review 队列里未审核的记录——前台看不见，后台还在。
五、外链的处置：拒绝文件怎么用才不伤自己
外链类的问题，最终要靠 Search Console 的「拒绝链接」文件。这是一份明文域名清单，告诉搜索引擎「这些域名的链接我不认」。但它是个双刃剑，用错了会连自己的正常外链一起否掉。
我的做法分三步：
- 先看数据：导出「链接」报告里的「最常链接到你的网站」和「最常链接的示例」，按链接数量排序。垃圾外链通常呈现非常明显的特征——域名是随机字符串、后缀集中、指向页面分散、发现时间集中在某几天。
- 只拒绝「明确是垃圾」的域名：宁可少拒绝，不要多拒绝。一个域名如果既有可能是同行推荐也可能是垃圾农场，就先不拒绝，等下一轮观察。我第一版拒绝文件列了 400 多个域名，其中至少三分之一是我不确定的，后来砍到 160 个。
- 拒绝文件要维护，不是一次性的：它不会自动过期。如果某个域名后来变成了正常站点，或者你自己买了这个域名，要记得从文件里移除。这点几乎没人提，但代价很实在——有人拒绝了自己后来买的域名，白丢权重。
关于「毒外链到底有没有伤害」，我的观察是：搜索引擎对外链的算法处理能力已经很强，绝大多数垃圾外链会自动被忽略。真正会触发手动操作标记的，通常是规模巨大且集中在某个时间点、或者配合了站内可注入入口的那一类。所以遇到「少量垃圾外链」不用慌，遇到「几万条集中涌入」才需要动手。
六、提交复审：说清楚做了什么，比说抱歉有用
复审请求是一个表单，只有一个输入框。很多人写「我已清理垃圾外链，请重新审核」，这种基本不会过，因为没有提供任何可核实的信息。
我的写法固定成三段，每段都有具体内容：
- 问题成因：一句话说清楚漏洞在哪。比如「评论区缺少审核机制，被自动化脚本提交约两万条含链接的垃圾评论，渲染在 37 个文章页上」。
- 已做的处理：分条列出动作和时间。关闭匿名评论、删除全部垃圾评论、删除 37 个页面上的残留、提交拒绝文件包含 160 个域名、给搜索结果页和标签页加 noindex。
- 防止复发：写清楚现在的新机制，比如评论全部先审后发、提交接口加了速率限制和关键词过滤、每月固定检查一次后台未审核队列。
提交之后不要天天查。第一次复审的结果一般在几天到两周之间回来，我两个站分别是第九天和第十六天。期间继续正常更新内容，不要停更——我判断停更会让复查时看到的站点状态更差。
七、复审没过怎么办
我的第一个站第一次没过，通知里写的是「仍然发现类似问题」。这种回复信息量很低，只能自己重新排查。后来发现两处漏网：一个是提交表单的「成功提示页」被搜索引擎索引了上千个，页面上带着用户填的内容；另一个是几个旧文章的评论区虽然在模板上关了，但历史上渲染出来的静态快照还被缓存着。
处置方法是：先按「样例链接」重新抓一遍，看通知里给的例子和第一次是否一样。如果一样，说明那块根本没清干净，回去找同一个位置；如果换了新的链接，说明问题面比想的更大，要扩大排查范围。
第二次提交时，我在「已做的处理」里加了一句「已确认所有样例链接页面不再包含相关外链，并已排查全站同类入口共 11 处」。这次过了。信息的具体程度，直接决定审核的人能不能快速核实。
八、这段经历里最值钱的三条经验
第一，把所有「能被用户写入并公开展示」的入口列一遍，这是所有这类问题的共同源头。评论、留言、投稿、站内搜索、用户主页、标签、甚至 404 页面里的搜索框回显，都要过一遍。我后来的做法是在后台做一个清单，每加一个功能就回去看一眼这个清单。
第二，降权不一定有通知，但有通知一定要先看通知。流量下滑时，第一件事是打开手动操作页面和「安全问题和手动操作」里的所有项目，三十秒就能排除一种可能，没有任何理由跳过。
第三，清理要彻底到「审核者能核实」的程度。自己觉得清干净了不算，要让一个不熟悉你站点的人，按你写的说明能逐项对上。这条不只适用于申诉，也适用于所有排障汇报。
九、小结：入口比外链更值得管
事后复盘，我那两个站的问题从来不是「有人给我发了垃圾外链」，而是「我给了别人往我页面上写字的地方却没管」。外链是结果，可注入入口是原因。把入口管住，外链的问题会在源头消失；只清外链不管入口，下一批垃圾三个月内还会回来。
现在我给所有新站上的第一个功能不是统计、不是缓存，而是评论审核开关和提交频率限制。这听起来一点都不性感，但它是过去几年里唯一真正救过我流量的配置。