Google 恶意软件与垃圾软件排查指南

💡 核心摘要：Google 会检查网站是否托管会损害用户体验的软件、下载文件、扩展程序或移动应用。恶意软件通常会蓄意伤害设备、系统、应用或用户；垃圾软件则常通过欺骗、意外行为、浏览器设置更改、隐私泄露或误导性下载影响用户。站点一旦触发相关警告，应先在 Search Console 安全问题报告中确认可疑文件，修复软件和下载流程，再提交审核请求。

一、为什么恶意软件会影响搜索表现

恶意软件和垃圾软件首先是用户安全问题，但它也会直接影响搜索和转化。

如果 Google 发现网站托管了危险下载、欺骗性软件或会伤害用户体验的可执行文件，用户访问或下载时可能看到警告。即使搜索排名没有立刻变化，点击率、信任度和业务转化也会明显下降。

对软件下载站、SaaS 官网、插件站、工具站、移动应用官网、开源项目下载页、广告落地页和托管平台来说，这类风险尤其重要。

SEO 团队不能只检查页面内容，还要把下载文件、安装流程、扩展程序、广告素材和第三方组件纳入监控。

二、先区分恶意软件和垃圾软件

Google 官方把恶意软件和垃圾软件都归为会对网站访问者产生不良影响的可下载二进制文件或应用。

恶意软件通常具有更明显的伤害性，例如未经同意安装软件、植入病毒、破坏设备或危害用户数据。

垃圾软件不一定像病毒一样直接破坏系统，但它具有欺骗性、意外性，或会对用户浏览和计算体验造成负面影响。

常见垃圾软件行为包括：

擅自更改浏览器主页
修改默认搜索设置
捆绑安装用户不想要的组件
没有清楚披露就收集或泄露隐私数据
用误导性广告诱导下载
让卸载流程困难或带有恐吓性
虚假声称设备存在严重问题

这意味着，合规重点不是“软件是否有用”，而是“用户是否被清楚告知、是否主动同意、是否能控制和撤销”。

三、在 Search Console 中确认安全问题

如果网站触发相关问题，应先查看 Search Console 的安全问题报告。

这个报告可以列出网站上托管的可疑文件或相关安全问题。它是站点所有者确认 Google 发现了哪些风险的入口之一。

排查时建议记录：

受影响 URL
可疑文件路径
问题类型
首次发现时间
最近修改时间
文件来源
是否来自用户上传、第三方脚本、广告、下载包或部署流程

不要只删除报告中的单个文件。真正要确认的是：它为什么会出现在网站上，是否还有同源文件，是否会再次生成。

四、理解两类安全报告表述

Google 官方说明，在安全问题报告中，“恶意软件”通常指未经用户明确操作便会运行的网络恶意软件；“有害的下载内容”指必须由用户明确下载的恶意软件或垃圾软件。

这个区别有助于确定排查方向。

如果是未经用户操作就运行的恶意内容，要重点检查页面脚本、注入代码、iframe、重定向、广告代码和第三方资源。

如果是有害下载内容，要重点检查下载文件、安装包、捆绑组件、下载按钮、广告承诺、安装流程、代码签名和隐私披露。

两者都需要修复，但证据链不同。

五、不要用误导性下载广告

Google 官方指南强调，软件用途和意图必须如实告知用户。用户必须能够有意识地下载软件，并通过清楚的广告或按钮知道自己将下载什么。

高风险做法包括：

只有“下载”两个字，但没有说明下载内容
把播放按钮做成下载入口
模仿发布商页面，让用户以为能看视频，实际下载无关软件
用虚假系统警告诱导用户下载清理工具
把广告设计得像站点原生下载按钮

下载页应该明确写出软件名称、功能、版本、平台、文件大小、发布者和安装后会发生什么。

如果页面同时有广告和真实下载按钮，要避免广告误导用户点击错误下载。

六、软件行为必须和宣传一致

软件对外宣传什么，就应该实际提供什么。

如果程序会收集用户数据、投放广告、更改浏览器设置、安装扩展程序、启动后台服务或捆绑其他组件，就必须用用户能理解的语言说明。

不要把重要行为写成无关紧要的小字，也不要把会影响浏览体验的功能包装成“优化”“增强”“免费加速”这类模糊说法。

用户判断是否安装软件，需要知道：

软件的核心用途
会安装哪些组件
会修改哪些设置
会收集哪些数据
会展示哪些广告或通知
是否包含第三方组件
如何跳过可选组件
如何卸载并恢复设置

透明披露是降低垃圾软件风险的基础。

七、浏览器和系统更改必须让用户批准

如果软件会修改浏览器主页、默认搜索、新标签页、代理、证书、启动项或系统设置，用户必须能提前看到并明确批准。

官方特别强调，如果程序会更改 Chrome 设置，应使用对应的 Settings API，并遵循规范的扩展程序安装流程。

不要通过绕过浏览器界面、隐藏选项、禁用提醒或技术注入的方式改变用户环境。

高风险行为包括：

静默更改默认搜索引擎
静默安装扩展程序
禁用浏览器或系统提醒
阻止用户重置浏览器设置
通过代理、DLL 或补丁改变浏览器行为
安装根证书来拦截 TLS/SSL 流量

这些行为即使出于“功能实现”目的，也可能被视为对用户不友好或有害。

八、不要制造恐慌式提示

Google 官方明确反对软件虚假描述设备状态。

例如，不应声称用户设备存在严重安全问题、病毒感染或性能危机，除非有真实、可解释、可验证的依据。

尤其要谨慎这些类型的软件或页面：

电脑清理工具
注册表清理工具
系统优化工具
杀毒或安全扫描工具
手机加速工具
驱动更新工具
浏览器修复工具

如果你宣传“免费”，就必须确保宣传的服务和组件确实不需要付费。不能先用恐慌提示吸引安装，再在核心功能处收费或诱导购买。

九、保护用户数据并使用加密传输

软件或移动应用只有在用户数据与功能相关时，才应传输用户私密数据，而且必须让用户知情。

涉及个人或敏感数据时，应使用加密方式传输，例如 HTTPS。

需要重点检查：

是否收集邮箱、手机号、账号信息
是否读取已安装应用、文件或设备标识
是否上传浏览记录或搜索记录
是否向第三方发送数据
是否在隐私政策和应用内清楚披露
是否超出已发布功能所需范围

隐私披露不能只放在难以找到的页面里。用户应在数据收集发生前知道它的目的。

十、下载文件和安装包要做供应链检查

网站所有者有时并不知道自己托管的下载文件会被视为恶意软件或垃圾软件。这通常发生在供应链和打包流程中。

常见风险包括：

第三方安装器捆绑了不合规组件
旧版本安装包包含高风险行为
镜像站点文件被替换
用户上传的可执行文件未经过扫描
广告下载按钮指向第三方安装器
开源项目被二次打包后加入额外组件
CDN 或对象存储中的文件权限过宽

建议为所有可执行文件建立文件清单，记录哈希、版本、签名、来源、发布时间和扫描结果。

十一、代码签名不是强制但很重要

Google 官方说明，未签名二进制文件不一定会因此被标记为垃圾软件，但建议程序拥有有效且可验证发布者信息的代码签名。

代码签名的价值在于提升发布者可信度，并帮助用户、浏览器和操作系统识别文件来源。

对软件下载站来说，还应保证：

下载页显示发布者信息
文件签名与发布者一致
文件哈希可供校验
历史版本可追溯
镜像文件没有被替换
第三方组件来源明确

如果文件没有签名，更要在下载页和安装流程中减少用户疑虑，并加强供应链检查。

十二、捆绑组件也要符合规范

Google 官方提醒，如果软件捆绑了其他软件组件，站点或软件发布者要负责确保这些组件也符合要求。

这点很容易被忽视。很多风险不是主程序造成的，而是捆绑安装器、广告 SDK、浏览器扩展、插件或可选组件造成的。

检查捆绑组件时，要确认：

用户是否能清楚看到每个组件
用户是否能轻松跳过可选安装
组件是否有独立说明
组件是否会更改浏览器或系统设置
组件是否会收集或发送数据
组件是否能完整卸载
组件来源是否可信

不要把责任外包给第三方安装器。用户是从你的网站下载的，风险也会影响你的网站。

十三、Chrome 扩展程序要走合规安装流程

如果二进制文件会安装 Chrome 扩展程序或改变 Chrome 功能，必须遵循 Chrome 的分发和安装规则。

关键原则包括：

扩展程序应托管在 Chrome 应用商店
扩展程序默认处于停用状态
用户需要通过授权流程启用扩展程序
扩展程序不得禁止 Chrome 显示设置更改提醒
卸载主程序时应指导用户移除相关扩展
不得通过未授权方式静默安装扩展

如果软件绕过 Chrome 的安装机制，可能被标识为高风险。

对 SEO 和站点运营团队来说，扩展程序下载页、安装说明和卸载说明都应清楚、完整、可验证。

十四、移动应用也要避免欺骗和越权

移动应用相关风险不仅发生在 Google Play，也可能发生在应用官网、APK 下载页、第三方分发页和广告落地页。

Google 官方强调，移动应用应清楚披露数据收集目的，不得假冒其他品牌或应用，不得展示与应用功能不符的广告，不得在未经同意的情况下下载其他应用，不得模拟操作系统或其他应用提示。

移动应用下载页应重点检查：

应用名称和图标是否可能让用户误认
功能承诺是否真实
权限申请是否和功能相关
数据收集是否清楚披露
广告和弹窗是否标明来源
是否诱导安装其他应用
卸载和取消授权是否清晰

如果应用已在 Google Play 分发，还必须符合 Play 的开发者政策和分发协议。

十五、移动应用警告的处理方式

官方说明，如果移动应用显示警告消息，需要通过相应申诉流程处理。

在提交申诉前，应先完成内部排查：

确认具体版本和下载渠道
检查是否有第三方 SDK 或广告 SDK 触发风险
检查是否有越权收集或传输数据
检查是否模拟系统提示或其他品牌
检查是否在后台下载其他应用
检查隐私披露和权限说明是否充分
更新受影响版本并停止分发旧版本

不要在没有修复根因时直接申诉。审核通常看的是问题是否已经真实解决。

十六、修复后提交审核请求

Google 官方说明，网站或应用符合相关指南后，可以在 Search Console 的安全问题报告中提交审核请求。

提交前建议准备：

受影响 URL 和文件列表
已删除或替换的文件
修复的漏洞或流程问题
第三方组件审查结果
新下载包的签名、哈希和版本
更新后的披露、安装和卸载说明
防止复发的监控措施

审核请求应简洁说明根因、修复动作和防复发措施。不要只写“已修复”，要让审核人员能理解你解决了什么。

十七、建立下载安全监控流程

如果你的网站提供下载，建议把下载安全纳入固定流程。

所有可执行文件发布前做安全扫描
记录文件哈希、签名、版本和来源
下载页明确说明软件名称、功能、发布者和版本
广告和下载按钮不得误导
安装流程清楚披露组件、数据收集和系统更改
可选组件默认不强迫安装，并可轻松跳过
卸载流程清楚、完整、无恐吓
定期检查 Search Console 安全问题报告
监控服务器和 CDN 中新增可执行文件
发现警告后先下线风险文件，修复根因，再提交审核

这套流程能降低下载页、安装包和第三方组件触发安全警告的概率。

十八、完整排查清单

查看 Search Console 安全问题报告
确认问题是网络恶意软件还是有害下载内容
列出所有受影响 URL、文件和版本
检查下载按钮、广告和落地页是否误导
检查软件功能和宣传是否一致
检查浏览器、系统、扩展程序和证书更改是否清楚披露并经用户批准
检查是否存在恐慌式提示或虚假安全声明
检查用户数据收集、披露和加密传输
检查捆绑组件、SDK、广告和第三方安装器
检查代码签名、哈希和供应链来源
更新或移除风险文件
修复导致风险文件出现的发布流程
提交审核请求并持续监控