Google Ads Destination Not Working: How to Fix the Disapproval

What does the Google Ads destination not working disapproval mean and what should you do first?

The Google Ads destination not working disapproval means the page your ad points to returned an error to Google's ad crawler, AdsBot, or failed to work properly. The official policy name is "Destination not working." Google pauses or limits the ad. You fix the page, then resubmit the ad for review.

Stay calm. In most cases the cause sits on the server or in a security layer, not in your ad copy. Work through these steps in order:

1. Copy the final URL of the disapproved ad and open it in a private browser window.
2. If the page loads, the problem probably affects only Google's crawler. Check robots.txt, your firewall and any location rules.
3. If the page does not load, find the HTTP status code. 4xx and 5xx codes point to different causes.
4. Note the affected ads and URLs from the policy details in your account.
5. Fix the cause, test again, then save the ad to trigger a new review.

No step guarantees approval. However, once you find the real cause, the fix is often quick.

You also do not need to change your ad text or targeting. The policy covers destination access. Therefore, solve the page side first, then return to the ad side.

How is the Google Ads destination not working policy different from similar policies?

Google handles similar situations under several policy names. We could not verify translated names for every language, so we give the English names here. The message in your account may match any of them.

The fixes overlap a lot. The tests in this guide help with all three. Account-level or security violations follow a different path, so for those read our guide to suspended Google Ads accounts.

Note: Policy names and screen text can change over time. Treat the details in your own account and the official Destination not working policy page as the source of truth.

How does AdsBot check your landing page?

AdsBot is the Google crawler that reviews ad destinations. According to the official help page, Google checks whether the destination works on common devices around the world. A page that opens on your own laptop is not enough.

However, AdsBot does not behave like a regular visitor. Instead, it uses its own user agent and arrives from Google's IP ranges. So a security layer can let you in and still block AdsBot. The page looks healthy to you and broken to Google.

The developer documentation lists AdsBot among the special-case crawlers. You can read it on the Google special-case crawlers page. In practice, the two user agent names that matter for your site are AdsBot-Google and AdsBot-Google-Mobile.

Also, the crawler checks every final URL you submit. So if you run hundreds of ads, one broken template can hit all of them at once.

Because of this, do not fix just one ad in the account. Scan every ad, ad group and asset (for example sitelinks) that uses the same final URL. A single missed address can bring the problem back.

Why do server errors (4xx and 5xx) trigger the destination not working disapproval?

When AdsBot visits your page and receives a 404, 403 or 500 status, Google treats the destination as not working. The official policy page names this case directly. So the status code matters more than how the page looks.

• 404: The page was deleted, moved or mistyped in the campaign. Check the address spelling first.
• 403: The server or a security layer forbids the request. It may not recognize AdsBot.
• 500 and 502: The application or server code throws an error. Our guide to the 500 Internal Server Error helps here.
• 503: The server is temporarily unavailable. See our 503 Service Unavailable guide for details.

Some pages also return a 200 code while the content says "not found." This is a soft 404, and we cover it in our soft 404 guide. It may not trigger the disapproval every time, but it still hurts the ad experience.

In short, find the code first and the cause second. Random setting changes usually make things worse.

How does robots.txt block AdsBot?

The robots.txt file tells crawlers which parts of a site they may visit. Google's documentation says AdsBot ignores the global user agent group (the wildcard group). So a file that leaves Googlebot alone can still shut AdsBot out through a separate rule.

The reverse also happens. For example, say you blocked all bots during testing and forgot to remove the rule. After launch, your destination pages stay blocked. Copying a staging file to the live site is the classic version of this mistake.

Also, the official Destination not crawlable page lists restricting most of a site with robots.txt as a problem. It also names a robots.txt file that is unreachable or times out. So the file must respond, too.

Use this checklist:

• Does the file open at your domain root and respond fast?
• Does any rule block AdsBot-Google or AdsBot-Google-Mobile?
• Do any rules block the folders that hold your ad destinations?
• Did a broad rule survive from a test environment?

For the basics, read our robots.txt guide. For common errors, see our robots.txt mistakes article.

How do a firewall and WAF stop the Google Ads crawler?

A WAF, or web application firewall, blocks suspicious requests automatically. Bot protection works in a similar way. Because of this, these tools may treat AdsBot as unknown automated traffic and return a 403 or a challenge page.

The symptom is usually this: you see the page, but Google's crawler gets an error. Security plugins, CDN rules and rate limiters do this quietly. As a result, nobody notices until the campaign gets disapproved.

The official fix guidance suggests allowing the AdsBot-Google and AdsBot-Google-Mobile user agents in your server settings. Someone who understands your security setup should do this, because random new rules can open the door to real attacks.

Also review the default settings of any third-party protection tools. They sometimes change behavior after an update. For more background, read our ModSecurity and WAF guide.

Why do geo blocks and bot protection make a destination inaccessible?

The official policy lists messages such as "this site is not accessible in your location" as violations. So if your site opens only from one country and Google crawls from another, you have a problem.

This usually happens with setups like these:

• Security rules that allow traffic from selected countries only.
• Bot protection that shows a challenge to every visitor.
• Hosting settings that block foreign IP addresses in bulk.
• Entry screens that require a language or region choice before the page loads.

However, your destination must open from every location where you show the ad. So if you set geo limits, keep them consistent with your campaign targeting.

Note: Showing Google one version and users another (cloaking) breaks the rules and counts as circumventing systems. The right path is an access setting that serves the same content to both.

How do redirect chains and loops trigger the disapproval?

Suppose the ad URL redirects to a second address, and that one redirects to a third. AdsBot may never reach the end of the chain. In a loop, the page never loads at all. Google sees both as a destination that does not work.

Common sources include stacked redirects from HTTP to HTTPS, from non-www to www, and from a slash-less address to a slash version. Tracking links can also add a step.

The fix is simple. First, use the final address directly in the ad. That way AdsBot reaches the destination in one step. You can find details in our guides on the redirect chain and the redirect loop error.

Here is a practical tip. Paste the campaign final URL into a browser and watch the address bar. If it changes, put the changed address into the campaign.

How do login, cookie and age walls break the destination?

Suppose the page needs a login, a cookie consent or a birth date. AdsBot cannot pass those steps. It sees a barrier screen instead of your real content. As a result, Google may judge the destination as not working or not accessible.

A cookie banner alone is not the problem. The problem starts when no content loads until the visitor accepts it. In other words, a script that hides the whole page leaves the crawler with a blank screen.

• Load and show the content even before consent is given.
• Do not use pages that require a login as ad destinations. Use a public landing page.
• Skip age gates for products that do not need them.
• If content sits behind a form, show a summary and description first.

That way both Google and the visitor understand what the page offers.

Can an SSL error cause the destination not working disapproval?

Yes, it can. A certificate that expired, does not match the domain or has an incomplete chain triggers a browser warning. If AdsBot cannot set up a secure connection, it cannot reach the page.

For example, typical causes include an expired certificate, a certificate that covers only the non-www address, and mixed content. Another common mistake is to connect a new subdomain to an ad without adding its certificate.

To fix it, first check the certificate validity and the domains it covers. Then confirm whether renewal runs automatically. We explain the steps in our guide to the "your connection is not private" error.

We are not a hosting company and we do not run servers. So you may need to finish the last step with your hosting provider. We help on the diagnosis and ad side.

Finally, set a reminder before the certificate expires. That single habit prevents most SSL-related disapprovals.

How does a page that breaks on mobile fail the destination check?

The official policy expects the destination to work on common browsers and devices. So a page that looks perfect on desktop can still show up blank, shifted or unclickable on mobile.

For example, common mobile breakages include:

• Rules that redirect mobile users to a separate address and then throw an error.
• Pop-ups that cover the whole screen and never close.
• Scripts that fail to load and leave the page empty.
• Very heavy images that make the page time out.

So when you test, try a real phone on a mobile data connection too. If speed is the issue, read our guide on why a website is slow.

Page experience also affects ad quality. We cover that link in our Quality Score guide.

How do you test that your destination really works?

One test is not enough. Instead, you need to try different locations, devices and clients. Follow this order:

1. Open the page in a private window and note the final address in the address bar.
2. Open the browser developer tools, go to the network tab and read the status code of the main document.
3. Open the page on a phone using mobile data, then compare it with Wi-Fi.
4. Try the page from another country through a VPN or with a colleague abroad.
5. Use the URL inspection idea in Search Console to see how Google fetches the page.

URL inspection shows whether Google can crawl a page. It relies on Googlebot, not AdsBot. Even so, it catches shared problems such as 403 errors, robots.txt rules and server errors. We explain the tool in our Search Console guide.

Note: Your test result and Google's verdict can differ. So also search your server logs for the AdsBot user agents.

The official help page also suggests Chrome developer tools and Google Search Console for testing.

Write the tests down in a small table: date, device, location, status code and result. After a change, you can then compare quickly and see whether the problem returned.

Which symptom points to which cause and fix?

The table below matches a symptom to a likely cause. Use it as a quick diagnostic guide. The tests give you the final answer.

This table shortens diagnosis, so you do not lose time in the wrong place.

The first row deserves extra attention. If you see the page fine and Google gets an error, normal browser tests mislead you. In that case server logs and security settings give the real clue.

Also, several symptoms can appear together. For example, a redirect chain may end in a 403. So after you fix one symptom, run the whole test again.

How do you request a re-review after you fix the google ads destination not working problem?

Once the page works, you trigger a new review by saving the ad or its final URL again. The official help pages describe editing the ad in your account and saving it. Menu names can change, so find the relevant area in your own account.

1. First confirm that the page opens on every device and from every location.
2. Open the disapproved ad, re-enter the URL or save it without changes.
3. Wait for the status to update. The time depends on your account and on review load.
4. If it is still disapproved, read the reason in the details again.

A fix may not apply to every ad. Therefore, check each disapproved ad group one by one.

We cannot promise a timeline or an approval, because Google runs its own review process. Still, when the fix is right, the re-review often goes your way.

What if you fixed the page but the disapproval stays?

First make sure you fixed what Google actually sees. Often the problem sits in a layer that opens for you and stays closed to AdsBot. Then find the response code that your server gave to AdsBot requests.

If you still cannot solve it, contact Google Ads Support and share the technical details you found. The official policy page also points to support for disputes.

However, some people suggest opening a new account or building tricks that show Google a different page. Google treats these as attempts to circumvent its systems. They put your account at far greater risk. We do not recommend them.

So look for a fix inside the rules. Also stay away from strangers who promise to "recover" an account for money. Never share access to your account with them. If an agency needs access, grant it through the official invitation.

If the disapproval grows into a suspension, read our suspended account guide.

Does a broken destination put your account at risk?

A single broken page usually affects only that ad. But if you leave the same problem unfixed across many ads, violations pile up. According to the official page, a violation does not bring an immediate suspension. Google issues a warning first.

However, constantly broken destinations hurt campaign performance and quality signals. If a visitor you paid for lands on an error page, your budget goes to waste.

• Assign someone to watch the warning emails.
• If disapprovals rise, investigate the root cause.
• Instead of only pausing and waiting, find and fix the cause.
• Keep a log so you do not repeat the same mistake.

That way a small issue closes before it grows.

How do monitoring and uptime checks prevent bulk disapprovals?

The best way to prevent disapprovals is to spot the problem before Google does. So set up a simple monitoring routine.

• Keep the final URLs of your ads in one list.
• Use an uptime service that checks the status code of those addresses on a schedule.
• After every site release, open the main ad destinations by hand.
• Add AdsBot to your test list whenever you change robots.txt or security rules.
• Write the certificate expiry date into your calendar.

Also, before you launch a campaign, open each new destination in a private window, on a phone and on another network. That way you catch the error before the ad goes live.

Example scenario: An online store updates its infrastructure over the weekend and adds a new security rule. On Monday morning all ads show as disapproved. With regular checks, the team would have caught the problem on Saturday.

Can tracking templates and UTM parameters trigger the disapproval?

Indirectly, yes. The official Destination not crawlable page lists click trackers that reduce crawl capacity as an example. Tracking services that redirect too much can slow AdsBot down or block it.

For example, the error often appears in setups like this: a third-party tracking address sits in the middle, redirects late or throws an error. Then the problem is not your page. It is the tracking path.

As a fix, keep the final URL clean, add parameters only as needed and cut tracking steps where you can. To build parameters consistently, use our UTM builder tool.

Also make sure the address with parameters opens the same page. Some servers return an error for unknown parameters. Add that to your test.

In summary, the Google Ads destination not working message often hides a small, overlooked link in the chain. So follow the chain end to end, from ad to page.

How does an old product or campaign page cause this disapproval?

The most common ecommerce scenario starts when a product leaves stock and you delete its page. However, the ad still points to that address. Then the page returns a 404, and Google says the destination is not working.

Seasonal campaign pages cause the same trouble. The campaign ends, you remove the page, but the ad group stays on. Example scenario: a store removes its sale page on the end date, and the next morning dozens of ads show as disapproved.

• Before you remove a page, list the ads that point to it.
• If a product is only out of stock for a while, keep the page and offer alternatives.
• For a permanent removal, pause the ad and plan a redirect to a relevant page.
• If you redirect, choose a single-step redirect to a closely related page.

Also, if a site relaunch changes the URL structure, update all ad addresses in bulk.

What should you do with the campaign while the problem remains?

A disapproved ad does not run anyway. However, other ads in the same campaign may keep running. If one still points to a broken address, your budget flows to a page that cannot welcome visitors.

So first find which ads share the same destination. If the problem is widespread, pausing the campaign until the fix is done is often healthier. After you fix and test the page, turn the campaign back on.

Then write a timeline: when the problem began, which change preceded it and what you fixed. That record saves time when you talk to support and when the next incident hits.

Note: Whether to pause or continue depends on your account situation. Decide together with your team.

How does our team help with destination problems?

At Talha Aslan and team, we often see these disapprovals in the gap between technical diagnosis and the ad account. The ad side shows the detail, but the cause sits in the server or the security layer.

Instead of guessing, we classify the problem and write down clearly who needs to do what. We do not run servers. So we work on hosting-side changes together with your provider or your development team.

For regular account management and destination checks, take a look at our Google Ads management service.

Note: Other platform verifications also depend on domain ownership, so keep your DNS access in order. Our Meta domain verification guide can help there. We guarantee no outcome, but we try to make the process clear.