Your Google Ads advert is disapproved for “Destination not working”, but the page opens when you check it. That is a reason to investigate the exact visit Google is trying to make. Opening your homepage in a familiar browser does not test the full route behind the advert.
Start with the rejected URL and error details. Then check tracking, redirects and access from outside your normal browsing session. Keep the evidence together so your ads manager, developer and hosting provider can work on the same problem.
There is a timely reason to revisit this advice: Google’s update posted on 30 September 2026 added examples to its destination troubleshooting guidance. Google explicitly says this did not change policy enforcement. It is a clarification, so there is no new deadline to prepare for.
Record the actual disapproval before changing anything
In Google Ads, find the affected advert and inspect its Status information. Add the Policy details column if you need a clearer view across several ads. Google’s current repair and appeal guide explains both routes.
Our suggested investigation record contains:
- The advert, campaign and affected asset, if a sitelink is involved.
- The exact policy label and any technical error shown.
- The final URL, separate mobile URL if configured, and expanded URL where available.
- The applicable tracking template and parameters.
- When you noticed the problem, with the time zone recorded.
- Recent website releases, domain changes, redirects or security-rule changes.
Pick one affected advert as the starting point. Compare it with an unaffected advert only where the destinations or settings differ meaningfully. A working advert that points to another section of the website may help narrow the investigation.
Test the full advertising URL
The visible address in an advert is not enough. The final URL identifies the landing page; the expanded URL combines it with applicable tracking templates and parameters. Google’s destination-not-working guidance requires the destination to function for AdsBot on common devices globally. Its examples include broken or unfinished pages and HTTP errors such as 403, 404 and 500.
Ask your ads manager to identify the route actually configured for the affected advert. Check keyword-level destinations and sitelinks where relevant, rather than assuming everything uses the campaign’s usual page.
Then compare the plain landing-page address with the configured advertising route. For example, a service page might load normally, while the same page with tracking parameters takes a different route through your website. That is a test case to investigate, not proof that the tracking platform is at fault.
Keep a copy of the existing settings before any repair. Change the part supported by the evidence, then repeat the same test. Changing several URL settings at once makes it harder to establish what fixed the problem.
Check that redirects preserve the promised destination
A page that eventually loads can still present a different policy problem. Google’s destination-mismatch policy covers inconsistent display and destination domains, redirects from the final URL to a different domain, and tracking routes that lead to different content. Certain cross-domain redirects have exceptions with prior approval; that is not a general permission to send visitors elsewhere.
For your repair, ask for the complete redirect chain: the starting address, each intermediate address and the final page. Check whether a recent domain move, URL shortener or location-based redirect explains the difference. A working replacement should still deliver what the advert promises.
Find the failure your browser is hiding
Use a private browser window and a real phone as practical checks. Where possible, compare your office connection with mobile data. Record which address you used and what happened. These checks give your developer repeatable examples; they do not establish how every Google crawl behaves.
Ask the developer or host to inspect the response from the affected route, including redirects and the returned page content. Useful questions include:
- Does the fault occur on the plain URL, the parameterised URL or an intermediate redirect?
- Does it happen every time, or only during certain periods?
- Does being logged in change the result?
- Is the visitor receiving the intended service page, an access challenge or maintenance content?
- Which layer generated the response: the application, hosting platform or security service?
A screenshot is useful, but include the test address and timestamp. “It works for me” leaves the next person guessing which page, network and session were tested.
Investigate geographical access separately from campaign targeting
Google’s destination-accessibility guidance tells advertisers to check global access, particularly their targeted locations and the United States, where AdsBot often crawls. It also identifies server security settings, firewalls and CMS plugins as possible blockers.
A UK-only delivery area does not by itself justify blocking overseas visitors from reading the landing page. Describe service or delivery restrictions in the customer journey, and have your developer investigate whether a separate access rule is preventing review. Do not broaden your advertising audience simply to troubleshoot website access.
Check AdsBot access without dismantling site security
If the policy label is “Destination not crawlable”, follow that evidence. Google’s crawlability guidance identifies restrictions in robots.txt and failures to retrieve that file as possible causes. Your developer should examine both the landing page and the crawler’s access to robots.txt.
There is an important detail for this check. Google’s current special-case crawler documentation lists AdsBot-Google and AdsBot-Google-Mobile, and says they ignore the global user-agent group, *. Checking only a generic rule or ordinary Googlebot access can therefore leave the AdsBot question unresolved.
Ask your developer to identify the relevant crawler-specific rules and any separate security decisions. The aim is to explain a particular blocked request and make a focused correction. Keep unrelated protection in place.
Verify requests before trusting a crawler name
A request calling itself AdsBot is not sufficient evidence of its origin. Google documents verification using reverse and forward DNS, or its published crawler IP ranges. AdsBot belongs to the special-case crawler group, which has its own ranges.
Ask the host to connect a verified request with its timestamp, requested URL, response and any matched blocking rule. Changing a browser’s user-agent can help investigate one condition, but it does not reproduce the network origin of a genuine Google request. Treat it as a diagnostic clue.
Use the Google Ads landing-page test with its limits in mind
Google Ads provides a landing-page and tracking-URL test at several account levels. Its results can identify an unreachable page, a missing page or a URL mismatch. Save the detailed result for the affected route.
Google also says the test does not check policy violations, does not support redirects and does not catch every parallel-tracking error. A “Page found” result is therefore useful evidence, not an approval certificate. If the result is inconclusive, combine it with browser checks and the host’s request evidence rather than repeatedly pressing Test.
Request review after the cause is fixed
First repeat the failing test and confirm that the intended page loads. Then use the appropriate review route. Saving an edited advert resubmits it for review; where you have repaired the destination or believe the decision was mistaken, the current Google guide explains how to appeal through Policy manager.
Select “Made changes to comply with policy” or “Dispute decision” to match what happened. Keep your investigation record available if support needs it.
The same guide currently limits each ad to three appeals and says to wait at least 24 hours between appeals for the same ads or campaigns. Since 21 July 2026, in-account appeals are unavailable for decisions made more than six months earlier; Google directs those issues to support. Avoid repeated submissions while you are still diagnosing the fault.
Agree what counts as a completed repair
Our recommended handover is a short record showing the original failure, the cause found, the change made and the result of repeating the test. Include the affected URLs so someone can check the work later.
After review, verify the advert’s status and test the customer route through to the intended enquiry, booking or purchase action. Approval and a usable customer journey are separate checks. If you changed tracking during the repair, include measurement in that handover too.
This work often crosses the boundary between paid media management and website development. Give one person responsibility for collecting the evidence and confirming completion, so the issue does not drift between suppliers.
If your ads are disapproved despite the page appearing to work, talk to BuzzBoost. Share the affected landing-page address and exact policy message so we can discuss the clearest next step.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
