Start with the server response, not the policy text. If the final URL returns a 4xx or 5xx status, fails on a common browser or device, or redirects somewhere unexpected, you have a technical destination failure. If the page loads normally for users but Google still disapproves it, the likely cause is a Destination Requirements policy issue such as mismatch, crawl blocking or unacceptable content.
Why does the same error label cover two different problems?
Google Ads groups several unrelated failures under one Destination Requirements policy. The policy covers destinations that do not work, destinations that do not match the ad, destinations that cannot be crawled, destinations that are not accessible, poor destination experience, insufficient original content, app store violations, unacceptable URLs, unrecognised apps and phone number problems (Destination requirements, Google Ads Policy Help).
That breadth is the source of most confusion. A checkout page returning a 503 and a page whose offer contradicts the ad text can both surface as a destination problem, yet they need opposite fixes. One is infrastructure; the other is editorial or policy compliance.
The policy also states that violations will not lead to immediate account suspension without prior warning, and that a warning will be issued at least seven days before any suspension (Destination requirements). That gives you a window to diagnose properly rather than panic-editing the account.
What does a technically broken destination actually look like?
A broken destination is a page a normal user cannot reliably reach or use. The policy requires that the ad destination and its contents work on common browsers and devices (Destination requirements).
Typical technical signatures:
- The final URL returns a 404, 410, 500, 502 or 503.
- The page loads on desktop but breaks on mobile, or the reverse.
- A redirect chain loops, dead-ends, or lands on an unrelated domain.
- The page requires a login, a region, or a browser feature that blocks the click.
- The page loads but shows an error message or empty content.
That last case matters because a 200 status is not proof of health. Google's crawling documentation notes that a 2xx success code does not guarantee indexing (How HTTP status codes affect Google's crawlers, Google Search Central). The same logic applies to your ad destination: a server saying "OK" while serving a broken template is still a broken destination.
Server errors also have a crawling consequence. The same documentation states that 5xx and 429 errors prompt Google's crawlers to temporarily slow down, and that already indexed URLs are preserved in the index for Google Search (How HTTP status codes affect Google's crawlers). So a flaky origin can degrade both your ads and your organic visibility at the same time.
How do I check the destination the way a reviewer would?
Work through the URL in layers, and record what you find at each layer.
- Resolve the final URL. Take the exact final URL from the ad, not the display URL. Follow every redirect manually and note each hop, its status code and its destination host.
- Check status codes. Use a header inspection tool or your browser's network panel. Record the status of the first response and the final response.
- Test the user agent. The policy article includes a section on overriding the user agent with Chrome DevTools (Destination requirements). Use it to load the page as a mobile browser and as a Googlebot-style crawler. If the page behaves differently for each, you have found a cloaking-adjacent or bot-blocking problem.
- Test geography and device. Load the page from the countries you target. A page that works in the UK and fails in the US, or the reverse, points to a geo-block, a CDN rule or a consent wall rather than a policy judgement.
- Compare ad promise to page content. Read the ad headline, the offer and the landing page side by side. If they describe different products, prices or conditions, you are in destination mismatch territory.
- Check crawlability. Confirm the URL is not blocked by robots.txt, a firewall rule or a bot challenge that a reviewer would also hit.
Example (hypothetical): An advertiser runs a US campaign pointing to a seasonal offer page. The page returns 200 on desktop, but the mobile user agent receives a 302 to the site homepage because of a device-detection rule. The ad is disapproved for a destination problem. The fix is the device rule, not the ad copy.
When is it a policy issue rather than a technical one?
If the page loads cleanly for a normal user in the target country on a common device, and the ad is still disapproved, treat it as a policy question. The Destination Requirements article lists the categories to check: destination mismatch, destination not crawlable, destination not accessible, destination experience, insufficient original content, app or web store policy violation, unacceptable URL, unrecognised app, unverified phone number and unacceptable phone number (Destination requirements).
Two of these are frequently misread. "Destination not accessible" can mean a login wall or a region lock rather than a server outage. "Destination experience" is about how usable the page is once reached, not whether it responds. Neither is fixed by resubmitting the ad.
A decision table you can reuse
| Signal | Likely category | First action |
|---|---|---|
| 4xx or 5xx on final URL | Technical | Fix the server or the URL |
| 200 but empty or error content | Technical | Fix the template or content render |
| Different response per user agent | Technical or cloaking risk | Remove device or bot-specific branching |
| Redirect to unrelated domain | Technical or unacceptable URL | Correct the redirect target |
| Page loads, offer differs from ad | Policy: mismatch | Align ad and page |
| Page loads, login or geo wall | Policy: not accessible | Remove the barrier for the target market |
| Page loads, thin or duplicated content | Policy: original content | Improve the page itself |
| Page loads, phone number problem | Policy: phone number | Verify or replace the number |
Use the table to decide who fixes it: an engineer, a content editor, or a policy reviewer inside your own team. Most wasted time in this area comes from sending a policy problem to an engineer, or a server problem to a copywriter.
What should I document before appealing or editing?
Keep a short evidence file per disapproved ad: the exact final URL, the status code of each redirect hop, screenshots of the page on desktop and mobile, the user agent used, the country tested from, and the date and time of the test. If you later request a review, this record shows you tested the destination rather than assuming it was fine.
If the destination is also your organic landing page, the same evidence helps there. A page that fails for ads often fails for search too, which is why store owners who cannot see their site in results should check availability and indexing before assuming a ranking problem — see Why is my online store not showing on Google?.
How does this connect to measurement and click paths?
Destination health is upstream of every conversion metric. If a page intermittently fails, your reported conversion rate is measuring a broken funnel, not user intent. Teams that already track post-click behaviour, for example through the approach described in One-Click YouTube Shorts Ads: Measuring the Path From Discovery to Site, can add a destination status check to the same routine.
What remains uncertain?
Google does not publish a complete list of every technical condition that triggers a destination disapproval, and the policy article describes categories rather than an exhaustive test suite. The exact thresholds for "insufficient original content" or "destination experience" are not quantified in the official text. Reviewers may also see a different page state than you do, depending on timing, region and device. Treat any single test as evidence, not proof, and retest after changes.
Follow-up questions
Can a page be disapproved for a destination problem even when it returns a 200 status?
Yes. A 200 response only means the server answered. If the content is an error message, an empty template or a soft 404-style page, the destination can still fail the requirement that it be functional and useful (How HTTP status codes affect Google's crawlers; Destination requirements).
Does a destination disapproval mean my account will be suspended immediately?
No. The policy states that violations of this policy won't lead to immediate account suspension without prior warning, and that a warning will be issued at least 7 days prior to any suspension of your account (Destination requirements). Use that period to diagnose and document the fix.