本文约 3,091 字，预计阅读 8 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：流量一夜归零，才发现被挂了风险提示
一个本来每天几百 IP 的 WordPress 站，某天百度带来的流量直接掉到个位数。站长用手机搜自己的品牌词，发现结果标题下面多了一行灰字提示”该网站可能存在风险，请勿轻信”；用浏览器点进去，直接跳到百度的安全拦截提示页，只有手动点击”忽略警告继续访问”才能进站。用户不会点那一下，流量就这么断了。这类标记来自百度的网址安全检测体系（对外常称百度网址安全中心，申诉入口可通过百度搜索”百度网址安全中心”进入，也可在百度搜索资源平台查看站点安全相关提示；入口地址会随平台改版调整，以当前官方页面为准）。触发原因绝大多数不是”百度看你不顺眼”，而是站点真的出了问题：被挂马、被植入暗链、被跳转到博彩或钓鱼页、或被利用做钓鱼页面中转。也有少数是误判或被同服务器其他站点牵连。处理这件事有一条铁律——先清干净再申诉，顺序反了一定二次被标。本文按这个顺序展开，并给出可以直接在服务器上跑的排查命令。
原理分析：风险标记是怎么产生和解除的
百度的网址安全检测是一套”扫描—判定—提示—复检”的闭环。扫描端会从页面内容、跳转行为、外链指向、脚本特征等维度识别风险；一旦判定为挂马、钓鱼、欺诈或违规内容，就会在搜索结果与访问链路两处加提示。理解这个闭环，才能理解为什么”删掉恶意文件”常常不够。
| 环节 | 发生什么 | 站长可控动作 |
|---|---|---|
| 扫描 | 抓取页面与脚本，识别恶意特征 | 无法控制，只能保证内容干净 |
| 判定 | 命中挂马/钓鱼/欺诈等类型 | 查看提示文案推断类型 |
| 提示 | 搜索结果风险提示 + 访问拦截页 | 无 |
| 申诉 | 提交整改说明，请求复检 | 清马、修漏洞后提交 |
| 复检 | 重新扫描，通过后撤销提示 | 保持站点持续干净 |
关键在于”持续”。复检不是看你提交申诉那一刻的状态，而是看后续一段时间内的扫描结果。这就是为什么很多站长清完马立刻申诉、通过没几天又被标记——漏洞没补，攻击者又进来了。另一个常被忽略的点是扫描的特征库包含”行为”而不只是”文件”：页面里一段从外部域名加载的 JS、一条按 UA 判断的条件跳转、数据库里被注入的隐藏链接，都会命中，即使 PHP 文件本身是干净的。所以排查必须覆盖文件、数据库、服务器配置、外部资源四处。
保姆级实操
步骤 1：确认标记类型与影响范围
用无痕窗口搜索 site:你的域名，看结果里是否有风险提示文字；直接访问首页与几个高频落地页，看是否被拦截；再用 curl 带百度蜘蛛 UA 请求一次，确认是否存在针对蜘蛛的差异内容（这类”劫持蜘蛛”的挂马最隐蔽）。
步骤 2：全站排查恶意文件与近期改动
先整站打包备份（含数据库），再定位异常。下面这组命令用于找出近期被修改的 PHP 文件与常见后门特征，是最快缩小范围的方式：
# 1. 找出最近 7 天内被修改过的 PHP 文件
find /home/www/mimangfei.com -type f -name "*.php" -mtime -7 -print
# 2. 搜索常见后门函数特征（只筛查，不自动修改）
grep -rn --include="*.php" -E "base64_decode|eval\(|assert\(|gzinflate|str_rot13|create_function" /home/www/mimangfei.com/wp-content | head -50
# 3. 检查是否有可疑的跳转脚本或外域加载
grep -rn --include="*.php" -E "header\s*\(\s*['\"]Location" /home/www/mimangfei.com/wp-content | head -30
# 4. 用百度蜘蛛 UA 请求首页，比对与浏览器看到的内容是否一致
curl -A "Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)" -sL https://mimangfei.com/ | head -60
步骤 3：清马并修补入口漏洞
确认恶意文件后，不要手工改代码，优先用同版本官方包覆盖 WordPress 核心、重装主题与插件、删除不认识的上传目录文件。同时必须找出入口：把 WordPress 核心、主题、插件全部升到最新版；检查管理员账号，删除可疑用户并重置密钥（wp-config.php 里的 AUTH_KEY 等八项）；确认 wp-content/uploads 不可执行 PHP；排查服务器上的其他站点是否同样被入侵，避免交叉感染。
步骤 4：清理数据库与外部资源中的残留
恶意内容常藏在 wp_posts 正文里的隐藏链接、wp_options 里的注入脚本、以及 CDN 或对象存储的缓存文件。用 SQL 抽样检查是否含可疑外域关键词，并清空 CDN 缓存与页面缓存插件的缓存。
步骤 5：提交申诉并等待复检
站点确认干净后，通过百度网址安全中心的申诉入口提交域名、风险页面地址、整改说明（说明发现问题的时间、清理措施、漏洞修补情况）。申诉后在观察期内保持站点稳定、不要再出现新风险内容，通常数日内会完成复检。若未通过，按反馈继续清理再提。
步骤 6：恢复后加固
开启文件完整性监控（核心文件被改动时告警）、限制后台登录尝试、给服务器加 WAF 或对 /wp-admin 做访问限制、定期备份。恢复流量还需要配合重新推送：把主要页面通过 API 主动推送接口再提交一次，加速索引状态刷新。
常见踩坑
- 先申诉后清马：申诉时站点仍有恶意内容，等于自证未整改，还会拖长复检周期。
- 只删恶意文件不补漏洞：绝大多数二次被标源于此，攻击者用的是同一个入口。
- 漏掉数据库注入：文件干净了，正文里的隐藏外链照样命中风险特征。
- CDN 缓存了恶意页面：源站清干净，用户和蜘蛛拿到的仍是缓存的恶意版本。
- 同服务器其他站点没处理：共享主机上邻居站被挂马，IP 与目录权限问题会让你反复中招。
- 案例：某 WordPress 站点发现被标风险后，站长只删掉了根目录下一个可疑 PHP 文件就提交申诉，三天后提示解除；但两周后再次被标，流量二次归零。事后排查发现攻击者利用的是一个早已停止维护的旧插件上传漏洞，恶意代码被写进了
wp_options的一条记录里，每次页面渲染时动态加载外部 JS。清除数据库注入、删除该插件并对 uploads 目录禁用 PHP 执行后，才真正稳定下来。这个案例说明：清理必须覆盖”文件 + 数据库 + 配置 + 缓存”四个层面。
总结
处理风险提示的判断标准只有一条：站点是否已经干净到经得起任何一次扫描。先备份，再排查，再清马，再补漏洞，最后才申诉——顺序不能变。申诉材料的重点不是措辞，而是把”做了哪些清理、堵了哪个入口”写具体，这对复检通过率影响最大。恢复之后要做两件长期的事：一是建立文件与数据库的变更监控，二是把主动推送和站点安全检测纳入日常巡检，让问题在影响流量之前被发现。关于把清理后的页面重新送进索引，可以配合百度主动推送接口接入与配额管理；涉及的站点安全与算法层面的关联，可延伸阅读百度天网算法与站点安全的关系；日常巡检的抓手则可以参考百度搜索资源平台站点验证与抓取诊断。
