Google Ads Destination Not Working? Cloudflare Might Be Blocking It

1. Find the Error Behind the Disapproval

Open the affected ad in Google Ads and read its policy details. Copy the failed URL and look for an error code.

• 403: something refused access. Check Cloudflare and the server firewall.
• 404: that URL was not found. Check the address in the ad.
• 5xx or a timeout: the server could not complete the request. Check hosting and application errors.

Google's destination policy explains the requirement: the page must work for AdsBot on common devices globally. A 403 tells you access was refused, but the block could come from Cloudflare or the server behind it.

Use the URL from the ad when testing. If the ad uses a tracking template or a separate mobile URL, check those too. You might be opening /quote while Google is being sent through a tracking service that fails before it gets there.

Check whether the error belongs to a sitelink — one of the extra links beneath your ad. It has its own destination, which can be broken even when the main landing page works.

To run Google's URL test, edit the ad and open Ad URL options → Test. For a sitelink, open it under Assets. The test does not check policy compliance or support redirects, so have your developer check any redirect chain separately.

2. Look for AdsBot in Cloudflare

Select your website in Cloudflare, open Security Analytics, then the Events view.

Filter the user-agent field to contain:

1AdsBot-Google

That also catches AdsBot-Google-Mobile. The user agent is simply the name the crawler sends with its request.

Look for Block or Managed Challenge actions against the failed URL. Open an event and check the Service and Rule ID. Those tell you which protection stopped the request.

Keep the timestamp and Ray ID from the event if someone else manages the site. Send them those details with the failed URL so they can find the same request.

Nothing in the log? Try a shorter time window and fewer filters. Cloudflare's event log can be sampled, so it may not show every request. Your host can also check whether the server itself returned the error.

3. Change the Setting That Blocked It

The service named in the event decides the fix. There are three cases worth separating.

A firewall rule

Check the rule's conditions. A rule that blocks overseas visitors or challenges automated traffic can catch a crawler you need.

If you only advertise in Australia, it is tempting to block every other country. But Google's destination checks still need global access. Your advertising location settings do not control where AdsBot connects from.

Have your developer adjust the offending rule to permit the verified crawler traffic it should allow. They can use Cloudflare's verified-bot signal or Google's published crawler IP ranges.

One detail matters here: AdsBot uses Google's special-case crawler ranges. An IP list built only for Googlebot can leave AdsBot blocked.

Do not allow a request just because its user agent says AdsBot-Google. Anyone can send that name.

Bot Fight Mode

If the event says Bot Fight Mode, a WAF Skip rule will not fix it. Cloudflare does not support exceptions for ordinary Bot Fight Mode.

Turn it off if you have confirmed it is causing the failure, then choose bot protection that supports the exceptions your site needs.

Super Bot Fight Mode or a managed rule

These support exceptions. Use the Skip option for the feature responsible, limited to the traffic you need to let through.

The names are unhelpfully similar, but Bot Fight Mode and Super Bot Fight Mode do not have the same controls. Check which one is actually enabled before following a guide for the other.

4. If Cloudflare Is Letting It Through, Check robots.txt

Look for rules addressed to AdsBot-Google or AdsBot-Google-Mobile that disallow the landing page.

AdsBot ignores the general User-agent: * group, but it can obey rules written specifically for it. Adding an allow rule under Googlebot does not change AdsBot's instructions.

Search Console can be misleading here too. A successful live URL Inspection checks search access; it does not prove AdsBot can get in. If Search Console says the page is fine and Google Ads says it is broken, keep investigating AdsBot.

If both Cloudflare and robots.txt look correct, ask the host to check the failed request in its access logs. Server firewalls and application rules can also return a 403.

5. Test Again, Then Request Review

Once the block is fixed, repeat the URL test where supported and check the landing page on desktop and mobile. Have your developer recheck any tracking redirects too.

Then open Policy manager, find the affected ad and select Appeal. When you have changed the site to fix the issue, Google provides a Made changes to comply with policy option in its appeal process.

Check the ad's status after review. Other ads can keep spending while one is disapproved, so review the affected ads individually rather than assuming the whole account stopped.

If the error comes back, compare the new failure time with the logs. A server that struggles during busy periods or a rate limit that only catches bursts of requests can pass your manual test and fail later.

The prevention is straightforward: whoever changes Cloudflare needs to check Google Ads access afterwards. If your marketing team and hosting provider are separate companies, make that responsibility explicit in your website maintenance arrangements.