Why does Google Ads say 'Destination not working' when my landing page loads fine?
Because Google judges the page by what its crawler, AdsBot, gets back, not by what your browser shows. Google disapproves ads whose destination doesn't work, or returns an HTTP error such as 403, 404 or 500 to AdsBot on common devices. A page can load for you and still fail for AdsBot when a firewall or bot protection blocks crawlers, a country block shuts out the US (where AdsBot often crawls from), a redirect loops or breaks, or DNS is wrong. Test the exact URL as AdsBot, fix the block, then appeal the disapproval.
As of October 2026.
Before you start
- The exact URL Google checked. That is the Expanded URL: your final URL plus any tracking template and parameters. Google notes the Expanded URL shown in Google Ads may differ from your ad's destination, so test the full URL the ad uses.
- Whoever runs your site, CDN or firewall, and their logs. Most fixes happen there.
- What's at stake. Google says these violations won't lead to suspension without a warning at least 7 days before.
Step 1: Read the exact disapproval reason
Go to Ads in the Campaigns menu and hover over the disapproval in the Status column. For more detail, add the Policy details column (Columns icon, then Attributes). Policy manager, under Troubleshooting in the Tools menu, lists policy issues across the account.
Check that the reason really is Destination not working. Its neighbors need different fixes:
| Disapproval | What Google means |
|---|---|
| Destination not working | The page doesn't function, or returns an HTTP error to AdsBot |
| Destination not crawlable | robots.txt, or site settings that allow too little crawling, keep AdsBot out |
| Destination not accessible | The page can't be reached in the targeted location, or AdsBot can't crawl it |
| Destination mismatch | The display URL's domain doesn't match the final URL, or a redirect goes to another domain |
Step 2: Match the error to Google's list
In a notice posted September 30, 2026, Google said it had updated its Destination not working article "to provide additional examples for destination issues" and that "This does not change enforcement of the policy." The article covers two kinds of failure:
- Pages that don't work or are set up wrong, such as "You've reached this page in error", "Whoops! Nothing to see here!" or "Site Under Construction", even with no error code.
- Pages that return an HTTP error to AdsBot "on common devices globally", such as 403, 404 or 500.
The disapproval names the error AdsBot got. Google's list includes:
| Error | What it means |
|---|---|
| HTTP 4xx or 5xx response | Your server returned an error; a typo in the URL gives a 404 |
| DNS error | Wrong DNS settings, an expired or unregistered domain, or a firewall stopping Google connecting |
| Redirect URL too long, empty or bad | A CMS adding redundant information, misconfigured redirect rules, or typos |
| Server redirects too often | A redirect loop |
| Malformed HTTP response | An app crash, faulty server software, or a server low on memory |
| Timeout reading page, Private IP, Page requires authentication | The server was too slow, sits behind a firewall or router, or needs a login |
Step 3: Test the URL the way AdsBot sees it
An error for either of Google's two AdsBot user agents gets the destination disapproved:
- Desktop:
AdsBot-Google (+http://www.google.com/adsbot.html) - Mobile, as Google prints it:
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)
Google's test uses Chrome DevTools:
- In Chrome, click the 3-dot icon, select More tools, then Developer tools, then Network conditions.
- Under "Caching", select Disable cache.
- Under "User agent", uncheck Use browser default and paste one of the strings above into "Enter a custom user agent".
- Load the Expanded URL. It should load "exactly like it would with your browser's default user agent" and return HTTP 200 (check the Network tab). Repeat with the other string.
This test has a blind spot. The request still comes from your own IP address and country, so it can't show a block based on IP, country or bot verification. Two checks can:
- Your server, CDN or firewall logs. Find AdsBot requests and the status code each got. User agents can be spoofed, so verify the IP: a reverse DNS lookup should end in googlebot.com, google.com or googleusercontent.com, and a forward lookup on that name should return the same IP. AdsBot's names look like
rate-limited-proxy-***-***-***-***.google.com, and its IP ranges are in Google's special-crawlers.json file. - Search Console's URL Inspection live test, which Google's policy help also suggests, for a URL in a property you own. It uses Google-InspectionTool, a common crawler, not AdsBot, which comes from a different IP range, so a pass is a good sign, not proof.
Step 4: Fix what blocks AdsBot
Google's own diagnosis: "If your website works for you but gets disapproved by Google Ads, your server's security settings, firewalls, or Content Management System (CMS) plugins might be blocking the automated crawl system." It asks you to allowlist the AdsBot-Google and AdsBot-Google-Mobile user agents and keep the site reachable globally. Since user agents can be faked, an allow rule that also checks Google's IP ranges or a verified-bot flag is safer.
Firewalls and bot protection
Cloudflare lists Google AdsBot as a verified bot ("Advertising & Marketing") and says verified bots have "historically" been "excluded in default bot configurations across all plans," so look first at rules you added. Security > Analytics > Events shows which service acted on a request.
- Custom rules that block or challenge countries, IP ranges or user agents can catch AdsBot. Cloudflare's own example exempts verified bots:
(ip.src.country in {"US" "MX"} and not cf.client.bot). - Bot Fight Mode, Cloudflare's free bot product, can't be bypassed or skipped with WAF custom rules or Page Rules. If it is challenging AdsBot, turn it off (Security Settings, filter by Bot traffic) or move to Super Bot Fight Mode.
- Super Bot Fight Mode (Pro, Business and Enterprise) has a Verified bots grouping you can set to Allow, and supports custom rules with the Skip action for exceptions.
Vercel lists Google AdsBot as a verified bot and says Attack Mode and its bot protection let verified bots through unchallenged, though a WAF custom rule matching a user agent can still block them.
If you use a CMS security plugin, which Google names as a possible cause, check whether it blocks AdsBot.
Country blocks and redirects
Google says to keep landing pages accessible globally, "especially in your targeted locations and the United States (where Google AdsBot often crawls from)." If you block countries outside your sales region, exempt verified Google crawlers, or AdsBot can get a 403 your team never sees. A message like "This site is not accessible in your location" brings Destination not accessible, and a geo-redirect to another domain can bring Destination mismatch. Follow every redirect hop with the AdsBot user agent too: a loop shows as "Server redirects too often".
Tracking templates, robots.txt and servers
- Tracking templates. The Expanded URL includes your tracking template, so test it as AdsBot. Google says to check whether a click tracker is affecting crawl capacity, and to use a Google-certified third-party tracker.
- robots.txt. Google says AdsBot ignores the global
User-agent: *group, so a blanket disallow doesn't block it, but a group namingAdsBot-GoogleorAdsBot-Google-Mobiledoes. A robots.txt block, or a robots.txt file Google can't read, can bring Destination not crawlable instead. - Servers and logins. For 5xx errors, timeouts and malformed responses, check the server's error logs from around the disapproval. A page behind a login or on a private IP can't be checked; point the ad at a public page.
Step 5: Request a review
Fixing the page doesn't approve the ad: after you fix the destination, Google says, "you'll need to file an appeal."
- Go to Troubleshooting in the Tools menu, then Policy manager.
- On the Policy issues tab, select Appeal on the affected ad.
- Under "Reason for appealing", select Made changes to comply with policy, or Dispute decision if the page was never broken.
- Select Submit.
You can also appeal from the Ads page (check the ads, select Edit, then Appeal policy decision), or edit the ad to use a working final URL, which Google reviews again automatically. Google's pages differ on timing: its Destination not crawlable page says a re-review typically takes 24 to 48 hours, its review status page says most reviews finish within one business day, and its Search troubleshooting guide allows up to 5 business days for new accounts.
Google's appeal rules:
- Appeal in batches by ad group or campaign; appealing every ad in the account at once can take longer.
- Each ad gets 3 appeals. After 3 unsuccessful ones, you need customer support.
- Wait at least 24 hours between appeals for the same ads, or they can be marked Duplicate.
- If you fixed the page but the appeal fails or is a duplicate, "make a minor edit to your ad's text or final URL and save it to force the system to perform a new crawl."
- Since July 21, 2026, decisions more than 6 months old can't be appealed from the account; contact Google Ads support.
- Track appeals on the Appeal history tab in Policy manager. "In progress" means check back in 24 hours.
Common problems
| Problem | Why it happens | Fix |
|---|---|---|
| Only some ads are disapproved | They may use different final URLs, sitelinks or tracking templates | Test each ad's Expanded URL |
| Disapprovals right after a big upload | Google says a large volume of new ads can limit efficient crawls (under Destination not crawlable) | Split uploads into smaller batches over several days |
| Many ads disapproved at once, and every test passes | It may be on Google's side: on April 14, 2026, PPC News Feed reported Google Ads incorrectly disapproving ads for Destination not working while the sites worked, citing PPC specialists' complaints | Appeal; PPC News Feed recommended submitting the ads for review |
Sources
- Update to Destination not working article (Sept 2026) - Advertising Policies Help, checked October 27, 2026
- Destination not working - Advertising Policies Help, checked October 27, 2026
- Destination requirements - Advertising Policies Help, checked October 27, 2026
- Destination not accessible - Advertising Policies Help, checked October 27, 2026
- Destination not crawlable - Advertising Policies Help, checked October 27, 2026
- Destination mismatch - Advertising Policies Help, checked October 27, 2026
- Override user agent with Chrome DevTools - Advertising Policies Help, checked October 27, 2026
- Fix a disapproved ad or appeal a policy decision - Advertising Policies Help, checked October 27, 2026
- Check the review status of an ad or asset - Google Ads Help, checked October 27, 2026
- How to fix Google Ads Search campaign not running or low traffic - Google Ads Help, checked October 27, 2026
- Expanded URL: Definition - Google Ads Help, checked October 27, 2026
- Google Special-Case Crawlers - Google Crawling Infrastructure, checked October 27, 2026
- Google Common Crawlers - Google Crawling Infrastructure, checked October 27, 2026
- Verify Requests from Google Crawlers and Fetchers - Google Crawling Infrastructure, checked October 27, 2026
- URL Inspection tool - Search Console Help, checked October 27, 2026
- Verified bots - Cloudflare Docs, checked October 27, 2026
- Bot Fight Mode - Cloudflare Docs, checked October 27, 2026
- Super Bot Fight Mode - Cloudflare Docs, checked October 27, 2026
- Allow traffic from search engine bots - Cloudflare Docs, checked October 27, 2026
- Bot Management - Vercel Docs, checked October 27, 2026
- Attack Mode - Vercel Docs, checked October 27, 2026
- False Destination Not Working Disapprovals Bug (PPC News Feed, April 14, 2026), checked October 27, 2026