Quick Answer: A compromised site Google Ads disapproval means Google's crawler found hacked code on your landing page or somewhere in its redirect chain. To fix it: read the exact flagged domain in Policy Manager, remove the injected files and database entries, verify with Search Console Security Issues and Safe Browsing, then appeal using "Made changes to comply with policy". Google allows up to 72 hours to recrawl.
Last verified: September 2026, against Google's current Compromised sites policy, WordPress 7.0 and PHP 8.5.
Your ads stopped. Your traffic stopped. And the site loads perfectly when you open it in your own browser. That combination is exactly what this policy produces, and it lands in our queue regularly among the 20-30 client issues our engineers work through every day. What follows is the same sequence we run on a live site, written so you can do it yourself without paying anyone.
What a Compromised Site Google Ads Disapproval Actually Means
Google's ad crawler found code on your destination, or on something that destination loads, that behaves in a way you never authorised: an injected script, a hidden iframe, a silent redirect, a skimmer on a checkout form. The Google Ads compromised site policy covers destinations that have been hijacked or hacked, and it explicitly includes sites running a CMS with a known vulnerability that has been exploited.
Two details in the current policy matter more than most of what is written about this.
First, this violation does not kill your account on the spot. Google's compromised sites policy states that a warning is issued at least 7 days before any account suspension. Several popular articles still describe instant termination with no notice. That is fear, not policy, and panicking into a rushed rebuild usually costs more than the hack did.
Second, the flag follows the destination, not your ad copy. If the final URL passes through a tracking template, a UTM-tagged variant, a link shortener or a third-party form host, every hop in that chain is in scope. If your account shows ads disapproved for malicious software rather than the compromised site label, treat it the same way: the cleanup and the appeal are identical.
Why Google Flagged a Site That Looks Perfectly Clean
Five causes cover nearly every case, and only two of them are visible when you open your homepage. As of September 2026 the pattern runs: exploited plugin or theme code, a conditional injection that fires only for certain visitors, a hijacked third-party script, a leftover backdoor or rogue admin account from an earlier breach, and a redirect added inside the ad itself rather than on the site.
Ranked by how often each one shows up in support work:
- Vulnerable plugin, theme or CMS core. A hacked WordPress site rarely announces itself. Attackers scan for a public vulnerability within hours of disclosure and drop a small loader file.
- Conditional (cloaked) injection. The malicious script serves only to Googlebot, to mobile user agents, or to visitors arriving from search. Your browser sees a clean page. Google does not.
- Hijacked third-party script. A chat widget, analytics tag or font CDN that changed hands or got compromised upstream.
- Leftover backdoor. The visible malware got cleaned last time, the backdoor did not, and the site reinfects itself days later.
- A redirect inside the ad. Nothing on your server is infected at all. The tracking template or a stale UTM destination points somewhere it should not.
Across the 4,000+ sites Hostaccent has migrated since 2016, the injections our team finds most often sit in three places: a stray PHP file in wp-content/uploads, an appended line at the top of index.php, and a base64 blob stored in the wp_options table.
Why can't I see the malware when I visit my own site?
Because you are the wrong visitor. Cloaked injections check the user agent, the referrer, or a cookie before deciding what to serve, so an admin on a desktop browser gets the clean version every time. Fetch the page the way Google does and the extra script usually appears immediately.
Insider Insight: Before you trust any scanner, run
curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" -sL https://yourdomain.com | grep -i "<script"and compare it against the same request with a normal browser agent. A difference between those two outputs is the whole diagnosis.
The 3-Surface Sweep: Find and Remove What Google Flagged
Work three surfaces in order: the browser, the server, and the account layer. Skipping the third is why cleanups fail twice. Budget about 2 minutes for the first surface, most of your time on the second, and 10 minutes on the third. Google's own Help for Hacked Websites documentation follows the same broad shape.
Surface 1: the browser
Open Policy Manager, filter on "Policy Details: Compromised site", and read the disapproval detail. Google often names the offending domain. Write it down, because it is the string you will grep for. Then open the landing page in DevTools, check the Network tab for hosts you do not recognise, and repeat the Googlebot fetch above. Finally, open the ad itself and check its tracking template and final URL.
Surface 2: the server
This is where the actual removal happens. Over SSH, start with what changed recently:
bashfind /home/user/public_html -type f -name "*.php" -mtime -14 grep -rl "eval(base64_decode\|gzinflate(base64\|str_rot13(" /home/user/public_html --include=*.php
Then verify your core and plugin files against the official ones: wp core verify-checksums and wp plugin verify-checksums --all. Any modified core file is a finding, not a maybe. Check .htaccess for user-agent conditions you did not write, check wp_options for injected script tags, and check crontab for a job that reinstalls the payload. If FTP itself is refusing you mid-incident, clear that first with FTP 530 Login Authentication Failed: How to Fix It.
Pro Tip: Delete malicious files, never comment them out. A commented payload still matches Google's pattern detection on the next crawl, and we have seen appeals rejected for exactly that. If you have a backup that predates the infection, restoring it beats manual cleanup, as long as you patch the entry point afterwards.
Live site and no time to experiment? Our engineers clean this exact class of infection for a small one-time fee, and you see the precise quote before anyone touches your server. Hosted with Hostaccent? Then a cleanup like this is simply covered by support, free. Have an engineer fix it.
Surface 3: the account layer
Run wp user list --role=administrator and remove accounts nobody recognises. Rotate the database password, regenerate the salts in wp-config.php, revoke application passwords and API keys, and change SSH and FTP credentials. If you tighten file permissions here and your own pages start returning errors, work through 403 Forbidden Error: How to Fix It (Step-by-Step 2026).
Is this still affecting your store?
Tell us which customer journey is failing and what changed. We can investigate the application, payment, database, and hosting layers without moving your store.
Prove the Site Is Clean, Then Request the Review
Google re-crawls before it re-approves, so your job is to make the clean version the only version it can find. Purge every cache layer you run: page cache plugin, server-side cache, CDN. Then confirm two independent sources agree the site is clean, gather your evidence, and request a review in Google Ads once. Reviews typically complete inside the 72-hour window Google publishes.
The verification order that works:
- Search Console, Security Issues report. If it lists anything, fix that first and request the Search Console review separately. Ad approval will not outrun a live security issue.
- Safe Browsing. Check the domain in Google Safe Browsing. A domain on that list must be cleared there before ads resume, and clearing it is a separate appeal filed through Search Console.
- Your own Googlebot fetch. Same command as before. The extra script should be gone from both outputs.
- Screenshots. Capture the clean Security Issues panel and the Safe Browsing result with visible timestamps.
Only then, in Policy Manager, hover the ad status, click Appeal, and choose "Made changes to comply with policy". Add a short note saying what you removed and when.
Of the 20-30 client issues Hostaccent's engineers resolve daily, as of September 2026 the recurring pattern in these cases is impatience: the site gets cleaned properly, then someone submits four appeals in ninety minutes. In our experience the cleanup that fails twice is almost always the one where a cache layer or a CDN was still serving the infected HTML.
Pro Tip: Appeal once, then wait the full 72 hours. Repeated appeals resubmit the same destination to the same system and gain you nothing. If it is still disapproved after that window, contact Google Ads support with your timestamped evidence rather than clicking again.
Keep the Flag Off: What Actually Holds
Prevention here is unglamorous and it works: patch fast, reduce what you run, and keep a backup you have actually restored from. Sites that get flagged twice are nearly always running software that went unpatched for months, on a PHP branch that stopped receiving fixes. WordPress 7.0 shipped in May 2026, and PHP 8.2 drops out of security support on 31 December 2026.
The short list, in the order it pays off:
- Update within days, not quarters. Enable automatic minor updates and review majors on staging.
- Stay on a supported PHP branch. Check yours against the supported PHP versions table; 8.4 and 8.5 are the sane defaults right now.
- Cut plugin count. Every abandoned plugin is a future disclosure with your domain attached.
- Two-factor on every admin account, no shared logins, and follow the WordPress hardening documentation for file permissions and the disallow-file-edit constant.
- Offsite daily backups you have test-restored. An untested backup is a rumour.
- A WAF in front, with file-change monitoring behind it.
If updates keep slipping because nobody owns them, managed WordPress hosting exists for precisely that failure mode. Running a store raises the stakes again, and the Ecommerce Hosting Checklist: 12 Must-Haves Before Launch covers what to have in place before the next campaign. If you put the site behind a proxy afterwards and SSL starts misbehaving, Cloudflare Error 526: How to Fix Invalid SSL Fast (2026) is the fastest route out, and the Domain & Hosting Buying Guide: What to Check First is worth reading before you move anything.
Your Next Step: Ads Running, and a Site That Stays Clean
A compromised site Google Ads flag is recoverable, and staying off the list is the easier half. If you fixed it yourself, do one thing this week: test a restore from your backup, because the cleanup that costs you nothing is the one you never have to perform manually. On a managed stack, this class of problem is support's job rather than yours. Hostaccent has been hosting since 2016, UK-incorporated since 2018, with 24/7 support from our own engineers and a 30-day money-back guarantee. Start on the Economy plan at $1.99/mo, which renews at the same $1.99/mo. One caveat: it is sized for a single site, so several client projects belong on Standard. Still stuck? Open a ticket and you will see the exact quote before anyone touches your server.
Frequently Asked Questions About Compromised Site Google Ads
How long does a compromised site Google Ads review take?
Google asks for up to 72 hours to recrawl and re-evaluate a landing page after you submit the appeal, and straightforward cases usually clear inside that window. Complex ones run longer, especially where the injection was conditional or the domain also sits on the Safe Browsing list, because two separate systems have to clear it. Submit once with a short note describing what you removed, then wait the full window before doing anything else.
Can Google suspend my whole Google Ads account for this?
It can, but not silently for this policy. Google's compromised sites documentation states that a warning is issued at least 7 days before any account suspension, which gives you a real window to clean the site properly. Ignore that warning, or get flagged repeatedly for the same destination, and suspension becomes likely. Treat the first disapproval as the deadline it actually is, rather than a glitch to appeal your way around.
My security scanner says the site is clean. Why is it still disapproved?
Because most scanners request pages the way a desktop browser does, and plenty of injections only fire for other visitors: Googlebot, mobile user agents, or people arriving from a search result. Fetch your own landing page with a Googlebot user agent and then with a mobile one, and compare the HTML. Also check the ad's tracking template and final URL, since the flagged domain sometimes lives there and never touched your server.
Should I keep clicking appeal until the ads go live?
No. Each appeal resubmits the same destination to the same review system, so repeated attempts without a real change gain nothing and just reset your place in the queue. Fix the root cause, verify with Search Console and the Safe Browsing status checker, purge every cache layer, then appeal once with a brief description of what you removed. If it is still disapproved after 72 hours, contact support with your evidence.
Do I have to rebuild the landing page or the whole site?
Usually not. A targeted cleanup plus a full credential rotation resolves most cases. Rebuilding makes sense in two situations: the infection reached your database and you have no clean backup, or the site runs abandoned plugins that nobody maintains any more. Restoring a pre-infection backup beats manual removal when that backup predates the injection, though you still have to patch the hole the attacker came through.
Will moving to a new host or a new domain clear the flag?
Moving hosts clears nothing by itself, because the flag attaches to the content and the domain rather than the server. Migrate the same infected files and the same code gets crawled at the new address. Switching domains is worse: it reads as evasion, and Google's abusing the ad network rules cover that behaviour directly. Clean first, verify, appeal, and migrate afterwards if your current setup genuinely caused the problem.
Discussion
Have a question or tip about this topic? Share it below — your comment will appear after review.