Destination not working – Google Ads

Destination not working

Google’s own name for the policy, and what you see when you hover over a disapproved ad. Advertisers post the fuller in-account message: “Unable to crawl your landing page on Desktop devices. HTTP error 403” (Google Ads Community thread 182805295, 7 October 2022), or the same ending “on iOS devices” (thread 234500394, 11 September 2023). Neither thread reports how it ended.

This is an ad disapproval, not a suspension. Google is telling you that when it went to look at your landing page, it did not get a working page back. The policy covers destinations that do not function properly or have been set up incorrectly, and destinations that return an HTTP error code for Google AdsBot web crawlers on common devices globally.

The second half catches people out, because that check is not made in your browser but by Google’s own crawler: even if your site or app seems to be working as intended, Google says to use common browsers and devices to test for any issues and look for HTTP errors as AdsBot sees them.

Checked against Google’s help pages on 23 September 2026. Google changes them without notice, so check the linked page before relying on a detail.

At a glance

• A disapproval, not a suspension

  A warning comes at least seven days prior to any suspension of your account.

• AdsBot does the checking

  Ads are disapproved when the destination errors when crawled by any of the AdsBot user agent strings.

• It often crawls from the US

  Keep the page reachable in your targeted locations and the US, where Google AdsBot often crawls.

• Usually the hosting, in our experience

  Security set too tight for the crawler; the fix goes through whoever runs the IT.

• You can test it in Chrome

  Google’s own instruction is to override your user agent to mimic the Google AdsBot web crawler.

On this page7 sections

What Google is actually checking

Google requires that your ad destination and contents work on common browsers and devices, and disapproves an ad for Destination not working if the destination returns an error when crawled by any of the Google AdsBot user agent strings.

The Destination not working page tables the specific errors: 4xx and 5xx responses, DNS failures with a firewall on your server or network among the listed causes, private IPs, timeouts, redirect loops and pages protected by a login screen — most of which a browser visitor would never see. Google also warns that the expanded URL shown in the Google Ads UI may be different from the destination for your ad.

The same block turns up under neighbouring labels, so check the same things whichever you were given. Destination not crawlable is the robots.txt and crawl-capacity one: Google’s examples are using exclusion files like robots.txt to restrict access to the majority or entirety of a site and site settings that allow less crawling than is required for the number of ads you run, and it names “robots.txt unreachable or timeouts reading robots.txt”. Destination not accessible covers location and crawl together, its examples including landing pages that are blocked from being crawled by Google AdsBot via the robots.txt file and server-side configurations that prevent Google AdsBot from accessing the landing page. Destination mismatch is a different problem — the crawler reached a page, just not the one your ad declared — and has its own guide.

When the site works for you but AdsBot cannot get in

Google addresses this case directly: if your website works for you but gets disapproved by Google Ads, your server’s security settings, firewalls or content management system plug-ins might be blocking the automated crawl system.

In our experience, that is usually what it is. It is the hosting: the protection and the security on it are over-secure, so the bots cannot crawl it, and someone from IT has to correct that, or the owner does it themselves. Advertisers land in the same place — one was told by their host that the fault was at their end (7 October 2022), another was still stuck at the end of their thread (opened 11 September 2023) — though neither thread reports how it finished.

Two mechanisms are worth knowing about before you start testing, both worded here as the company documenting them words them, not as a count of how often we see them.

• Bot protection on a CDN. Cloudflare says its free Bot Fight Mode identifies traffic matching patterns of known bots and challenges them, and that you cannot bypass or skip Bot Fight Mode using WAF custom rules or Page Rules. Under Attack mode makes Cloudflare present a Managed Challenge page and should only be used when a website is under a DDoS attack; left on afterwards, every crawl gets a challenge instead of the page. Two people answering an advertiser in October 2025 both found the site blocked by Cloudflare, though that thread does not say how it ended.
• Capacity, not a rule at all. Google’s Display & Video 360 troubleshooting, which covers the same requirement that your ad destination and creatives are crawlable by Google AdsBot web crawlers, lists the case where Google is crawling the page but the request takes too long to complete, and says frequent timeouts cause this disapproval. In the one thread we found that reports an outcome, the advertiser returned on 26 January 2025 to say their server had been over 90% of its capacity, and that buying more brought the ads back within hours.

How to let AdsBot in, and how to test it

Google’s instruction: contact your web developer to allowlist the AdsBot-Google and AdsBot-Google-Mobile user agents. Those are the two it documents for ad checks, and it publishes the strings they send.

• AdsBot-Google, the desktop one, which Google says checks desktop web page ad quality. robots.txt token: AdsBot-Google. Full string: AdsBot-Google (+http://www.google.com/adsbot.html)
• AdsBot-Google-Mobile, the mobile web one, which checks mobile web page ad quality. Token: AdsBot-Google-Mobile. Full string: Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; AdsBot-Google-Mobile; +http://www.google.com/mobile/adsbot.html)

Both appear in Google’s special-case crawler documentation, published so that a web developer or a web server host can use the User Agent to configure the crawl rules for a site — send your host that page.

Two things about robots.txt catch people out. A blanket rule aimed at every crawler does not shut AdsBot out: Google says AdsBot ignores the global robots.txt user agent with the ad publisher’s permission, and its robots.txt specification says user agent specific groups and global groups are not combined. The line that blocks it is a group naming AdsBot-Google. And a robots.txt Google cannot fetch is as bad as one that says no: for the first 12 hours, Google stops crawling the site while it keeps retrying.

At the firewall, a user agent allow rule is a start but not proof, because Google warns that the user agent string can be spoofed. Its documented check is DNS: run a reverse DNS lookup on the accessing IP address from your logs, confirm the name is a Google one, then run a forward lookup on that name and check it returns the same IP. AdsBot’s reverse DNS mask matches names beginning rate-limited-proxy- and ending google.com, because the special-case crawlers may ignore robots.txt rules and so they operate from a different IP range to the common ones; Google publishes those ranges in a special-crawlers.json file on the same page.

Here is how to find out what is blocking it. The last two steps are for whoever looks after your hosting.

1. Read the exact wording first.

   Go to Ads within the Campaigns menu and hover over the disapproval reason for more information. “HTTP error 403” and “timeout” point in very different directions, and Google asks you to check your destination to determine if a technical issue is causing the disapproval first.

2. Check which address is being crawled.

   Follow your final URL through every redirect and test where it actually lands. If that is somewhere your ad never declared, you have a different disapproval: see Destination mismatch.

3. Load the page as AdsBot.

   In Chrome DevTools, open Network conditions, tick Disable cache, untick “Use browser default” under User agent and paste in the desktop string above to mimic the Google AdsBot web crawler. Display & Video 360 gives the same test, saying to update the user agent path to that string and reload, and adds that ad landing pages must be publicly accessible and that CAPTCHA makes the destination pages uncrawlable. A challenge page, CAPTCHA, login box, 403 or blank page is your answer.

4. Open your robots.txt.

   Look for a group naming AdsBot-Google or AdsBot-Google-Mobile that then disallows everything, and check if the subdomain has a separate robots.txt file when the landing page lives on one. No robots.txt at all is fine: Google’s crawlers are allowed by default for the paths not covered by other rules.

5. Check it from outside your own country.

   Google asks you to keep your landing pages accessible globally and suggests testing with Google Search Console (URL inspection tool); Display & Video 360 says to check for geo-restrictions that might be blocking Google’s crawlers and geo-target the campaign instead.

6. Ask your host or IT for the crawler’s log lines.

   Word it like this: “please send me every request since the ads were disapproved with AdsBot-Google or AdsBot-Google-Mobile in the user agent, and the status code returned to each.” If those show 403, 429, 503 or nothing while ordinary visitors get 200, the block is on your side. Google says not to use 401 and 403 status codes for limiting the crawl rate, and that its crawlers read the 429 status code as a signal that the server is overloaded.

7. Lift the block at the right layer, rather than switching protection off.

   On Cloudflare’s free Bot Fight Mode the setting itself has to change, because you cannot bypass or skip Bot Fight Mode using WAF custom rules or Page Rules. On paid Super Bot Fight Mode you choose how your domain should respond to various types of traffic per bot grouping, verified bots among them — Cloudflare’s legacy categories name “Google Adsbot” there — and configure exceptions with a Skip rule.

Is this a suspension?

Not on its own: a disapproved ad will not serve until the policy violation is fixed and the ad is reviewed again, and the account keeps running. Every page in the destination family carries the same alert, that a warning will be issued at least seven days prior to any suspension of your account, and Google’s suspensions overview agrees that it is for repeat violations that a warning comes first.

Two points here are absences rather than Google statements. Google publishes the policies where your account will be suspended immediately without prior warning under the heading which policies are considered to be egregious, and destination requirements is not on it. Its enforcement page says this strike-based system applies to the following policies and names a set that does not include it either. Both lists were checked live on 23 September 2026, and Google can change either.

Google does ask you to clear it up rather than leave a pile of disapproved ads: if you cannot fix the violations, remove the ad to help prevent your account from becoming suspended in the future for repeated policy violations. If it is already suspended, start with the first 24 hours and why accounts get suspended.

The appeal route

• Fixed it? Edit and save the ad: Google re-reviews it automatically, which typically takes 24 to 48 hours, and they can run again if it finds them compliant. No appeal needed.
• Certain it is a mistake? Appeal from Policy manager, under Troubleshooting in the Tools menu — but confirm first, as Google asks, that the page loads consistently and that server-side configurations allow Google AdsBot full access.
• Appeal failed or marked a duplicate? Google says to edit the ad’s text or final URL and save it to force the system to perform a new crawl rather than appeal again, and to wait at least 24 hours between appeals. Each ad is limited to three, and from 21 July 2026 the in-account appeal will not be available for policy decisions made more than six months prior.

Before you write one, read what the appeal form asks and why appeals get rejected.

Frequently asked questions

My site loads perfectly. Why does Google say the destination is not working?

The check is a crawl, not a browser visit: Google says that if your website works for you but gets disapproved by Google Ads, your security settings, firewalls or CMS plug-ins might be blocking the automated crawl system.

Which user agents do I need to allow?

Both of them — Google’s instruction is to allowlist the AdsBot-Google and AdsBot-Google-Mobile user agents, with the full strings on its user agent page.

Does a robots.txt rule that blocks all crawlers block AdsBot too?

No — Google says AdsBot ignores the global robots.txt user agent with the ad publisher’s permission, so it takes a group naming AdsBot-Google.

Can I allow Google’s IP addresses instead?

You can, but Google warns that the user agent string can be spoofed and says to verify with a reverse DNS lookup on the accessing IP address, then a forward lookup back.

Should I turn my firewall or security plugin off?

No. In our experience it is the hosting’s security being over-secure for the crawler, and the fix is narrow enough for whoever runs your IT to make. Switching protection off wholesale swaps one problem for a worse one.