- Google Ads destination not working means Google AdsBot hit an error on your landing page. Destination mismatch means the click landed on a different domain than your ad shows.
- Seeing both on the same day, on pages nobody edited, is a warning sign that something is redirecting your traffic away. That’s what happened here.
- In this case one login to the domain’s Cloudflare account deleted 30 DNS records and sent every page to a fake “verify you are human” page. We restored it about four hours after the attack.
- Google says it warns at least seven days before suspending an account under this policy. Fix first, then appeal only what’s actually fixed.
At about 1 pm on a Friday, every page on a client’s website started sending visitors somewhere else. Not to an error page. To a fake “verify you are human” screen that asked people to open their computer’s command box and paste in a line of code.
By mid-afternoon, Google had disapproved the ads. Each one carried two reasons: “Destination not working” and “Destination mismatch”.
It happened to a client we run Google Ads for. We’ve kept their name and business out of this. What follows is the real sequence, hour by hour. It’s also what we’d tell any business owner who logs in tomorrow to a Google Ads disapproved destination not working notice.
What Google Ads destination not working means, and why its twin matters
Google checks your landing page with its own crawler, Google AdsBot. It doesn’t load your Final URL the way you do. It loads the Expanded URL, which is your Final URL plus any tracking template or parameters.
If AdsBot gets an error back, such as a 404, a server error, a DNS failure or a redirect loop, you get “destination not working”. Google’s policy page lists these error types one by one. Most destination not working Google Ads cases are dull, like a typo in the URL or a page someone deleted.
A Google Ads destination mismatch is different. It means your ad says one domain, but the click ends up on another. A redirect to a different website is the classic cause.
Here’s the part nobody tells you. When destination not working and destination mismatch show up on the same day, on pages you didn’t touch, stop assuming it’s a settings mistake. Something may be sending your traffic away on purpose.
The case: a client’s Google Ads destination stopped working in one afternoon
What changed behind the scenes
Here’s how a Google Ads destination not working error can start nowhere near your website.
The website itself wasn’t the problem. When we loaded it straight from its own server, skipping the domain layer, the pages were clean.
The attack happened one level up, in the Cloudflare account that controls the domain’s DNS. Cloudflare itself wasn’t breached. One login was.
Someone logged into that account as the owner. Two-step verification wasn’t enforced on the account, so a login was all it took.
In about ten seconds they deleted every DNS record on the domain, 30 in total. Then they added a rule that redirected every page, on every path, to a lookalike security page on a domain they controlled.
Nobody picked this business out personally. A trusted domain with real visitors is simply useful to attackers.
Deleting the records took email down too. With the MX record gone, mail to the office address stopped arriving.
What Google saw, hour by hour
All times are US Eastern, Friday, October 30, 2026.
| Time | What happened | What Google Ads showed |
|---|---|---|
| ~1:00 pm | Attacker logs in, deletes 30 DNS records, adds the redirect | Ads still approved and spending |
| By ~4:30 pm | AdsBot follows the redirect and gets a 404 on the fake site | 3 ads disapproved: Google Ads destination not working and destination mismatch |
| ~4:30 pm | We spot the fake page and confirm where the redirect comes from | One ad group can’t serve |
| Soon after | Both live campaigns paused | No more spend on a broken site |
| ~5:15 pm | Records restored, redirect removed, site and email checked | Site loads normally again |
| That evening | Campaigns back on, appeals filed | Disapproved ads “under appeal” |
Scroll sideways to see the whole table.
The restore landed about four hours after the attack. Across the account, 63 sitelinks ended up with the same destination mismatch Google Ads had put on the ads.
The first hour: what we did before touching the website
We paused the spend first. That sounds obvious, but look at the table again. For a few hours some ads were still approved and still running, and any click on them went to a malware page. A Google Ads destination not working notice tells you something broke. It doesn’t stop the ads that haven’t been checked yet.
Then we made sure nobody “verified” anything. Security teams call this trick ClickFix. The fake page had already copied a command to the visitor’s clipboard, and pasting it runs malware that steals saved passwords.
Don’t click or paste anything. Just close the tab. If someone on your team did paste it, treat that computer as compromised and change their passwords from a different device.
Next came the question that decides everything else: where is the redirect coming from? If it’s on the web server, the host or developer fixes it. If it’s at the domain or CDN level, they can’t, no matter how long they look at the website files.
We checked the response headers before opening a single admin panel. The redirect came straight from Cloudflare’s CDN, not from the web server. That told us whose door to knock on.
Some hacks only redirect phones, or visitors arriving from a Google search. So test the way a customer actually arrives, not just from your laptop.
Fixing the cause, not the symptom
We didn’t want a shared password, so the owner sent us a member invite. It leaves a record of who did what.
Then we read the account’s audit log. It showed the login, the time, the deleted records and the new redirect rule. It also showed the login came from an internet connection in another state, nowhere near the owner.
That log is why the restore took minutes, not guesswork. It recorded what each deleted record had held. KLEXA rebuilt all 30 records to match the originals exactly, and then removed the redirect rule.
We didn’t stop at “the homepage loads”. We checked every page the ads point to, the sitelinks, the email records and the tracking.
The tracking check turned up an older, unrelated gap that we fixed separately. If you want that check spelled out, our guide to Google Ads conversion tracking walks through it.
Getting the ads approved again: appeal or edit?
When the site works again, Google gives you two routes to clear a Google Ads destination not working disapproval. You can file an appeal, which asks for a fresh review. Or you can edit the ad to point at a working page, and the edit triggers an automatic re-review.
We appealed, because the URLs were right all along. Only the domain had been hijacked.
There’s a judgment call here that most guides skip. For ads, the appeal screen lets you cover one ad group or a whole campaign. For sitelinks, it can cover every sitelink in the account. Go wide and you might sweep in assets that are still genuinely broken.
That nearly happened to us. The account had five old sitelinks pointing at pages that no longer exist.
A Google Ads appeal covering every “destination not working” sitelink would have included them.
And Google warns that appealing things you haven’t fixed can limit your ability to appeal later. So we appealed the mismatch, where every flagged sitelink now worked, appealed the ads for the whole campaign, and repointed two dead sitelinks to live pages.
One reassurance from Google’s policy page: it issues a warning at least seven days before suspending an account over this.
Why an uptime monitor would have said everything was fine
A basic uptime monitor asks one question: did the page answer? During the hijack it did. The redirect led to a fast, working page with a normal success code. The free plan of UptimeRobot, the monitor we tested, counts both redirects and success codes as “up”.
So the tool most businesses rely on would have stayed green the whole afternoon, while the Ads tab showed Google Ads destination not working errors.
What actually catches this is a check on the content and the domain: does the page still mention your business, and does it stay on your website? At KLEXA we now run that check on this client’s main pages and on our own site, and it alerts us when either answer changes.
How to stop your Google Ads destination not working again
Most of this is cheap. The expensive part is skipping it.
- Turn on two-step verification for the account that controls your domain and DNS. It makes this kind of takeover far harder.
- Do the same for your email. That inbox resets every other password you own.
- Give people their own logins with member access. Never pass one password around the office.
- Switch on change alerts in your DNS or CDN account, so a deleted record emails you.
- Watch your key landing pages for your business name and domain, not just “up or down”.
- Keep the domain and DNS logins in your own name, not only your web person’s. Then name one person who owns the renewals.
- Open the Ads tab each weekday and check for anything flagged, sitelinks included. It takes a minute.
If your ads are running but just not producing calls, that’s a different problem. Our Google Ads not working checklist is the better place to start.
Questions owners ask
Why are my Google Ads not showing when my website looks fine to me?
Google doesn’t check your site the way you do. AdsBot loads the full Expanded URL from Google’s servers, so a redirect, a firewall rule or a block on certain countries can fail for Google and still look fine on your phone. Check the disapproval reason in the Ads tab first. It usually names the error.
Google’s own test is to load the page in Chrome DevTools with the user agent set to AdsBot. Google also suggests Search Console for seeing where a URL really lands.
What’s the difference between destination not working and destination mismatch?
Destination not working means Google got an error, such as a 404 or a DNS failure. Destination mismatch means the click lands on a different domain than the one in your ad. Seeing both at once on untouched pages is a strong hint that something is redirecting your traffic away.
Can a hacked website get my Google Ads account suspended?
You won’t wake up to a Google Ads suspended notice overnight for this. Under the destination policy, Google says it will warn you at least seven days before any suspension. Fix the site, then appeal or edit the ads well inside that window. Repeated violations you don’t fix are what put an account at risk.
How long does a Google Ads appeal take after I fix the site?
Google’s destination policy pages don’t give a set time.
Once your Google Ads destination not working problem is fixed, file the appeal and watch the ad status in the Ads tab. If the original page will stay down, edit the ad to a working URL instead. That starts a review automatically.
Should I pause my campaigns while the site is broken?
Yes. In this case some ads stayed approved for hours after the site broke, and every click in that gap was wasted, or worse, sent to a harmful page.
Is a Google Ads compromised site disapproval the same thing?
No. That’s a separate Google label for hacked sites. In this case Google never used it. The ads were flagged only for destination not working and destination mismatch, because the hijack sat in front of the website, not inside it.
If your ads stopped this morning
When your Google Ads destination not working message shows up, start with the disapproval reason in the Ads tab.
Then work out where the problem lives before anyone starts editing the website. If you’d rather not do that alone, KLEXA can check the account and your landing pages with you, the same way we worked through this one. Book a 20-minute call and bring the error you’re seeing.