How to fix a Google Ads "compromised site" disapproval

Google's policy defines it in one sentence: “A compromised site is a site or destination whose code has been manipulated to act in ways that benefit a third party without the knowledge of the site or destination's owner or operator.”

Read that carefully, because two words in it decide how long this takes you. The policy is about code, not about your business, your offer, or your ad copy. And it is about the destination — the page the ad actually lands on, plus everything that page pulls in.

The same policy page lists what Google is looking for: scripts that transmit user data without consent, card skimmers, malware installers, pop-up redirects, and content management systems with a known vulnerability that has already been exploited.

This is the single most common reason people spend a week on this. You open the page, it loads normally, nothing is defaced, so the disapproval feels like an error. It usually is not. Four things routinely trigger it on a site that looks perfectly healthy:

There is a fifth case worth separating out, because the fix is different: the page itself is clean and so is everything it loads, but another page on the same domain is infected. Google's crawl covers the destination and the domain around it, so a forgotten staging subfolder or an old campaign landing page can stop ads pointing at a page that was never touched.

These two get conflated constantly, and they have nothing to do with each other. Sort this out before you start, because the work is completely different.

If both are true at once — and that happens, because the same stolen credentials often open both doors — treat the account first. Cleaning a site while someone else still has your ad account only gives them a working landing page again.

Four sources, and they do not always agree. Checking all four is what stops you from cleaning the wrong thing.

1. Google Ads Policy Manager

   Tools → Troubleshooting → Policy Manager. Filter to disapproved and read the exact reason string. “Compromised site” and “Malicious or unwanted software” are different policies with different fixes — if yours says the second one, use the malicious software guide instead.

2. Search Console → Security issues

   This is the report that names affected URLs and the category Google assigned. If you have never verified the property, do it now; without it you are guessing for the rest of this process.

3. Safe Browsing site status

   Google's Safe Browsing site status checker tells you whether the domain is flagged in the list that browsers use. A clean result here with a live Ads disapproval means the ad crawl found something Safe Browsing has not listed — which is normal, they are separate systems.

4. Scan the exact landing URL from the ad

   Not your homepage — the full URL in the ad, query string and all. Malspy checks Google Safe Browsing and six other blacklists, lists the scripts the page loads and which domains they come from, flags hidden iframes, and reports the CMS and plugin versions the page exposes.

Google's own remediation list for this policy is short: remove the code that refers to the compromised domains, work through Help for Hacked Websites, run the Security Issues report, check Safe Browsing, and update your CMS, themes, and plugins to current versions.

In practice that order plays out like this:

1. Take a copy before you touch anything

   Files and database. You are about to delete things, and the copy is also the only evidence of how the entry point worked if you need it later.

2. Remove the injected code, then find how it got in

   Deleting the payload stops the disapproval. It does not stop the reinfection. A vulnerable plugin, a leaked SFTP credential, or a web shell left in an upload directory will put the same code back, sometimes within hours, and the second disapproval lands after you have already filed your appeal.

3. Audit every third-party script on the destination

   Remove anything you do not recognise, and anything you recognise but no longer use. Each one is a domain whose owner can hand your page to someone else.

4. Rotate credentials and invalidate sessions

   CMS admins, database users, hosting panel, SFTP keys, and any API or salt values your framework uses for sessions. Remove admin accounts you cannot account for.

5. Update the stack

   Core, themes, plugins. Google names an exploited vulnerable CMS as a trigger for this policy, so a current version is part of the remediation and not a separate task.

6. Re-scan and compare

   Same URL, same tool as Step 1. You want the findings list to be empty, not shorter.

This is the step that gets skipped, and skipping it is why people appeal three times and conclude the system is broken.

Google's compromised-sites policy page tells you to resubmit after cleanup and to allow up to 72 hours for the recrawl. An appeal reviewed against a cached crawl from before your fix is an appeal against the infected version of the page. It gets rejected, and the rejection tells you nothing about whether your cleanup worked.

Hover the ad's status and click Appeal, or open Policy Manager and appeal from there. Google offers two options and they are not interchangeable:

Track the outcome in Policy Manager rather than waiting for an email. Google does not publish a turnaround time for these reviews, so any number you read elsewhere is somebody else's anecdote, not a commitment.

The full ordering and the common ways an appeal gets rejected are in the appeal guide.

Google's two policy pages read differently on this, and the difference matters, so here is both without smoothing it over.

The compromised sites policy page states that “a warning will be issued at least 7 days prior to any suspension of your account.” The broader Abusing the ad network page, which covers both compromised sites and malicious software, classes these as egregious violations with potential account suspension on detection and without prior warning.

Each of these gets tried first because it is quick, and each one costs you a day.

• Pausing or deleting the ad. The ad was the symptom. The destination is what got flagged, and the flag stays on the destination.
• Swapping in a different landing page URL. The policy covers the destination and the domain around it. A new path on the same infected domain inherits the problem, and repeatedly rotating URLs to keep ads running looks like evasion.
• Appealing with an explanation. An automated crawl found code. Nothing you write changes what the next crawl sees.
• Restoring a backup without dating it. If the backup predates the infection you are fine. If it postdates it you have just reinstalled the payload, and you now also believe the site is clean.

Worth being straight about this, because it changes what you do next. An external scan sees what a visitor's browser sees: the rendered page, the scripts it loads, the domains those come from, the blacklist status of your domain, and the software versions the page advertises.

It cannot see:

• Server-side code, so a PHP backdoor that only activates for a specific request parameter is invisible from outside.
• Files that are present but never loaded by the page you scanned — a shell sitting in an uploads directory produces no external symptom until something calls it.
• Database-stored payloads on pages you did not scan, which is the usual shape of a mass-injection across a CMS.

So a scan is the right first step and the wrong only step. It tells you fast whether something is wrong and usually points at the file or the third-party domain. Confirming the site is clean means also looking at server-side files, access logs, and scheduled tasks — which needs server access, not a scanner.

The expensive part of this was never the cleanup. It was the days the campaign was down while you worked out what was wrong. Two things shorten that for next time.

Monitor the destination, not the homepage. Your ad spend points at specific URLs. Those are the ones worth checking on a schedule, and a change in the script list is the earliest signal you will get — it shows up before a blacklist entry and well before a disapproval.

Keep the third-party script list short and reviewed. Every tag on a landing page is a domain that can be compromised on your behalf. The ones that cause this are almost always tools nobody has opened in a year.

Malspy can watch a domain on a schedule and alert on a change, which is the version of this that does not depend on remembering. The site compromise check walks through reading a scan result if you want to interpret one properly first.