Google Ads disapproved for malicious or unwanted software

“Malicious or unwanted software” reads like one rule. It is two, and they fail for opposite reasons. Working out which one applies to you is the whole first step, because a site that was never hacked can trigger the second one.

Google's Abusing the ad network policy states the first one plainly: “Intentional distribution of malicious software or ‘malware’ that may harm or gain unauthorized access to a computer, device, or network is not allowed.” The same page lists compromised sites alongside it, which is why the two disapproval strings get confused.

In practice almost every one of these on a legitimate business site comes down to one of four things, and all four are visible from outside the server.

• An injected script in the page source — obfuscated, often appended well below the visible markup, sometimes firing only for visitors arriving from an ad or a search engine.
• A hidden iframe sized to nothing or pushed off-screen, loading content from a domain you have never heard of.
• A third-party script whose vendor was compromised. Your code is clean; the chat widget, heatmap, or affiliate pixel it loads is not. This is the one that produces “but my site is clean”.
• A download you host or link to that an engine flags — an installer, a ZIP, a cracked plugin left in an uploads folder from years ago.

Scan the exact landing URL from the ad, not the homepage. Malspy reports the scripts the page loads and the domains behind them, flags hidden iframes, checks Google Safe Browsing plus six other blacklists, and lists the CMS and plugin versions the page exposes. Google's own Malware and Unwanted Software overview covers the categories its systems classify.

The cleanup itself, in the order that avoids a second disapproval, is in the compromised site guide — removing the payload without closing the entry point is what causes the reinfection that lands after you have already appealed.

This is the case people waste the most time on, because they keep scanning a clean site. Unwanted software is not a security finding. It is a disclosure and behaviour judgement about software your destination offers.

Google's Unwanted Software Policy identifies software as unwanted when it shows one or more of these characteristics:

• “It is deceptive, promising a value proposition that it does not meet.”
• “It tries to trick users into installing it or it piggybacks on the installation of another program.”
• “It doesn’t tell the user about all of its principal and significant functions.”
• “It affects the user’s system in unexpected ways.”
• “It is difficult to remove.”
• “It collects or transmits private information without the user’s knowledge.”
• “It is bundled with other software and its presence is not disclosed.”

The same policy organises its requirements under four headings — transparent installation and upfront disclosure, simple removal, clear behaviour, and snooping — plus a section on responsibility for third-party bundling.

There is no file to delete here. What changes is the page and the installer, measured against the seven characteristics above.

1. State every significant function before the download

   Not in the EULA and not after install. If the installer changes a browser setting, adds a background service, bundles a second product, or starts on boot, that belongs on the download page in plain text.

2. Unbundle, or disclose and make it skippable

   Undisclosed bundling is its own line in the policy. If a partner offer pays for the free tier, name it and let the user decline it in a single step.

3. Make removal trivial and document it

   A standard uninstaller that removes what was installed, and an uninstall page a user can find without contacting support.

4. Align the data story

   Everything the software collects or transmits must appear in your privacy policy, with notice and consent before collection starts. “Snooping” is a named section of the policy, not a general concern.

5. Make the ad, the landing page, and the product agree

   “Deceptive, promising a value proposition that it does not meet” is the first characteristic listed. A free-sounding ad for something that requires payment at step three fits it, however standard that funnel feels.

6. Appeal with the specifics

   Policy Manager → Appeal → Made changes to comply with policy. Unlike a malware case, here the detail is worth writing: name what you disclosed, what you unbundled, and what you removed.

Check which one you are dealing with before planning the work, because the ceiling is different.

A disapproved ad or keyword is contained: everything else in the account keeps serving and an appeal clears it. An account-level suspension stops everything, and the Abusing the ad network page classes these violations as egregious, with potential suspension on detection and without prior warning. Google's compromised-sites policy page states separately that a warning will be issued at least 7 days before any account suspension.

• Appealing first and fixing later. The review looks at the destination as crawled. An appeal filed over an unchanged page is a rejection with no information in it.
• Removing the download instead of fixing the disclosure. Works, and costs you the product. Worth doing deliberately, not as a reflex.
• Scanning a clean site repeatedly. If the string says unwanted software, no scanner on earth will return a finding. You are looking for a disclosure gap, not a file.
• Moving the ad to a new domain. For a malware case the flag follows the destination; for an unwanted-software case the same product on a new domain is the same product.
• Assuming an old cracked plugin in an uploads folder is harmless because nothing links to it. It is a hosted download on your domain, and engines index it.