内容站被 SQL 注入改成推广页，事后排查收录影响要看哪几处

内容站被 SQL 注入把页面改成推广页之后，事后排查收录影响要看哪几处？先看被改页面有没有进入索引，再看被覆盖的内容能不能找回，最后才处理入口。顺序反了会出现最糟的结果：页面修好了，但带推广内容的版本还留在检索结果里持续导流。2026 年 5 月的一起公开监测可以作为样本：一款内容系统的高危注入漏洞被用于未授权获取站点数据，在 5 月 7 日至 17 日这十天内，七百多个站点的页面被投毒成推广页。这类事件的处置难点从来不在修复本身，而在收录侧的清理。

先圈定被改动的页面范围

范围靠证据而不是猜测，三条线索并用。

数据层看写入痕迹：数据库里标题、摘要、正文与模板字段的近期修改时间，按异常时段做区间筛选，一次注入常常覆盖成批记录而不是单条。

页面层看内容差异：把推广特征词（导流链接、与业务无关的品牌词、异常联系方式）作为筛选条件，在库内文本上跑一遍，找出被改写与被植入两类记录，植入通常发生在模板或附加字段里，只查正文会漏。

外部层看索引清单：用站点地图列出的地址和实际收录的地址做对照，差集里既有历史遗留问题，也有本次被收录的异常页。这一步的产出是一张待处理清单，范围不明就动手清理，很容易只处理了一半。

确认这些页面有没有被收录

被改但从未被收录，影响是短期的；被收录之后即使恢复原文，异常版本还会持续存在一段时间。确认方法有三层：

先看索引结果里是否还能检索到推广版本的标题或描述片段，这是最直接的证据。再看抓取日志里攻击之后对应路径的抓取记录，有抓取说明有机会入库。最后看站内是否有指向这些地址的链接，内部链接会持续给抓取方提供入口。

处置上要同时切断这三条：改内容、去掉内部指向、对确实不该存在的地址返回明确状态而不是照常渲染成页面。只改内容不改指向，等于留着入口等它被抓第二次。

找回被覆盖内容的两条路径

第一条是回收站。删除正式文档在这类系统里是移入回收站而不是物理删除，如果攻击动作表现为删旧建新，回收站里通常能找到被删的原版本，恢复速度远快于从备份里捞。

第二条是整站备份。回收站覆盖不到的情况是原地改写——内容被更新而不是被删除，这时需要按备份恢复指定记录，或者从备份里取出原文再逐条比对回写。备份必须包含静态文件，否则恢复正文时模板与附件仍是攻击者改过的状态，看起来修好了实际还在漏。

两条路径的共同前提是事前有可用备份。事后再找备份文件，往往会遇到「有导出但没带模板」或「备份早于内容改动」的情况，恢复点选不对，等于把攻击内容一起放回去，所以恢复前要先在隔离环境确认备份的时间点与内容状态。

把入口堵住：查询拼接与表单

注入的根因在查询构造方式。可写的入口都要按同一标准复核：查询参数走参数化绑定，不接受把用户输入直接拼进语句；表单入口做字段校验与长度限制，并接入人机验证挡住批量提交；展示侧对输出做转义，把跨站脚本与注入分开处理，只挡一层会留下另一层。

内置能力上，接口认证与敏感词过滤、防采集干扰码属于不同职责：认证决定谁能写，过滤决定写进来的内容怎么处理，干扰码针对已被取走的内容。三者都要，但排查时要分别验证，不能因为开了其中一项就假定另一项也生效。

最后是权限面。能被写入的字段越少，可被覆盖的内容越少；高危操作单独设开关、默认不暴露，能把这类事件的直接影响面压小。

常见问题

改了内容还要不要提交重新收录？ 需要，先清掉指向异常页的内部链接，再走覆盖层动作，顺序反了会把异常地址再送一遍。

没有备份怎么办？ 优先查回收站与历史版本记录；都没有时，只能从公开检索缓存里逐页取回原文，成本高且不完整。

多久能确认清理干净？ 以索引清单为准：连续两个抓取周期里异常地址不再出现，才算处理完成。

被植入的导流链接在模板里怎么办？ 按文件层面排查模板与附加字段，只清数据库会留下复发入口。