- Policy evaluates a destination's behaviour as a whole, not a block of HTML: how the same URL behaves across countries, devices and clients is all in scope.
- Consistency is both the most important requirement and the most severely enforced. What the advertisement promises and what the audience receives must match, and what the checking system receives must match what the audience receives. The second kind of mismatch falls under the circumventing systems policy, where enforcement usually lands at account level rather than on a single advertisement.
- Redirects are entirely permitted. What creates a violation is not the presence of a redirect but a redirect whose outcome depends on who is asking. Chain length is a separate issue: every additional hop is one more place where a timeout, a certificate problem or a dropped parameter can make a destination look broken.
- A destination-not-working disapproval rarely means the page is down; it usually means the checking conditions differ from the self-test ones — a geographic rule, a consent gate, a certificate gap, or content that only appears after script execution. Reproduce from the target country with a plain client.
- Transparency is the easiest group to fix and the most frequently overlooked: a working way to make contact, a clear statement of who operates the business, and a privacy policy wherever personal information is collected. Missing items here cause more disapprovals than most advertisers expect.
What the policy evaluates is behaviour, not a document
The starting point for understanding destination policy is being clear about what it examines. It is not evaluating a static document; it is evaluating what happens when someone visits a URL. The distinction sounds like a matter of phrasing, but it determines whether a great many problems can be explained at all. The same URL may return different results in the United States and in Germany, may take a different branch on mobile than on desktop, and may present entirely different content to a browser executing JavaScript than to an automated client that only retrieves HTML. All of these fall inside the scope, because all of them are genuine behaviour of that URL.
Two practical consequences follow. First, self-testing has to reproduce the serving conditions rather than the advertiser's own browsing environment; nearly every "it opens fine for me" traces back to this, because a domestic address, a familiar browser carrying cookies and an already-warm CDN edge all differ from the checking side. Second, any logic that decides what to return based on the identity of the visitor needs its policy position established before deployment. Where that boundary falls is set out in the Google Ads circumventing systems policy.
Consistency: two directions, one principle
The consistency requirement runs in two directions, and most attention goes to only the first. The first is consistency between the advertisement and the destination: the product, price, offer and availability promised in the advertisement must genuinely exist on the page and be obtainable there. Promoting an item the page does not carry, quoting a price that differs at checkout, or advertising a free trial when the page offers only paid plans all belong to this group. Judgements here are comparatively straightforward and enforcement is mild — typically the advertisement or ad group is disapproved and can be resubmitted once corrected.
The second direction is consistency between what different requesters receive: the content served to the checking system must be the same content served to the audience. The severity here is in an entirely different class, not because the harm is larger but because of what the harm is aimed at. If a URL can present one page to a checking system and another to the audience, the entire premise of pre-publication review collapses. Enforcement therefore tends not to operate on a single advertisement but at account level, and appeals are markedly harder. How these differences are identified, and where the common false positives arise, is covered in how ad platforms detect page differences, with the full version of the boundary in the red lines.
Judgements in this second direction do not depend on the implementation. A server-side branch, an edge rule, an intermediate redirect page and a script that runs only for some requests are the same thing from a policy perspective: the test is whether the decision about what to return depends on who is requesting. That is why "this is a standard geographic redirect" rarely helps as an argument — geographic redirection is compliant in itself, and the question is whether the same mechanism also separates the checking side from the audience side. Where that line sits is set out in compliant personalisation versus differentiated delivery.
Redirects: what is permitted and what is not
Redirects are explicitly permitted and are close to unavoidable in a normal serving path: tracking redirects, canonical host redirects, language and region redirects and link shorteners are all everyday components. Policy is not concerned with whether a redirect exists but with two specific properties.
The first is whether the endpoint is singular. A redirect chain, however many hops it contains, should converge on the same endpoint for every visitor. If the endpoint depends on properties of the requester — and particularly on whether the request looks like a check — it falls into the second kind of inconsistency described above, regardless of how it is built. An intermediate page is not itself a problem; what matters is what the intermediate page decides. The common structures at this layer and the trade-offs between them are covered in compliant page delivery: redirects, static pages and proxies.
The second is the length and stability of the chain — a purely engineering concern that accounts for a substantial share of destination-not-working disapprovals. Every extra hop adds a stage that can time out, a hostname the certificate may not cover, and a rewrite rule that can drop parameters. Fetches on the checking side run on a tight timeout budget, so a four-hop chain that feels instantaneous in a browser can fail there outright. Compressing to one or two hops, confirming every hostname is inside the certificate's coverage, and verifying the final URL opens on its own with no parameters removes most of this category.
Reachability: why "it works for me" is not evidence
The reachability requirement is simple in itself: the destination must load and function in every region being targeted, on both desktop and mobile. The difficulty is in the verification conditions. Each of the situations below produces a result that works locally and fails on the checking side, and none of them is visible from the advertiser's own machine.
Geographic rules are the most common. Security products, content delivery configurations and compliance modules frequently block by country, and the rule lists are rarely audited. If a single targeted country matches such a rule, the destination is a block page for that side. Consent gates are the second. Where a cookie consent component renders no main content until consent has been given, a request that carries no cookies and clicks nothing receives an all but blank page. The privacy requirements behind those gates have to be met as well, and they are covered in landing page requirements under privacy regulation.
Certificates are the third: if one hostname in the chain is outside the certificate's coverage, a browser may show nothing unusual because the result is cached or an exception was once accepted, while an automated client fails outright. Rendering dependence is the fourth: where the main content only appears after script execution and the fetch does not execute it or times out, what comes back is an empty shell. This one is also the most easily mistaken for a consistency problem, since from the checking side "the audience sees a full page and I see an empty one" is hard to separate from deliberate differentiation. Returning the core content without script execution resolves the reachability risk and the misclassification risk together.
In practice a self-test should originate from the targeted country, use a plain client, carry no cookies, and separately confirm that the final URL opens with no parameters attached. If any of those four conditions is unmet the result cannot be treated as evidence that the page is fine. The same approach applied to other platforms is covered in TikTok Ads landing page requirements and Pinterest Ads landing page requirements.
Transparency: three easy requirements that get skipped
This group is not complicated and is cheap to fix, yet missing items here account for a real share of disapprovals. The first is business identity: the page must make clear who is providing the product or service, including a company name and the necessary address information. The second is a working means of contact, with the emphasis on working — an address that does not exist, a number nobody answers and a form that errors on submission all produce the same outcome as having no contact details at all.
The third is a privacy policy. Any page that collects personal information — a contact form, a subscription, a registration, any component asking for an email address or phone number — needs one, stating what is collected, how it is used and how to get in touch to exercise rights over it. A landing page carrying a lead form with no privacy policy is among the most common direct disapprovals and among the quickest to fix. Where the page also includes a payment step, pricing, billing period and refund terms have to be stated clearly; vague pricing and unclear automatic renewal terms are another recurring group.
Restricted categories: eligibility comes before the page
One class of destination problem cannot be solved by editing the page, because the problem is not the page but the eligibility. Financial services, healthcare, gambling, crypto assets and legal services require prior certification or a local licence in most markets, and until that is held no amount of compliance work on the page will get it through. The practical lesson here is about sequence: confirm the category rules and certification requirements for the target market first, then invest in the page, rather than the other way round.
A separate group covers functional prohibitions that apply regardless of category: downloads that begin automatically on arrival, overlays that cannot be dismissed, interface elements imitating system notifications, fabricated countdowns or stock figures, and behaviour that makes the browser difficult to leave. These appear under various headings in the policy text, but they share a property: each removes control from the visitor. The judgements involved and the forms they usually take are covered in doorway pages and sneaky redirects.
How the requirements are actually verified
Verification is carried out by several different stages, and understanding the differences between them explains a number of apparently contradictory outcomes. The first stage is an automated fetch at submission: fast, broad in coverage, limited in patience for rendering, and non-interactive. What it sees is close to the raw response. The second is sampled manual inspection, where the page is genuinely opened, clicked through and taken to the end of the flow, which surfaces problems the fetch cannot see — a form that does not actually work, or a checkout price that differs from the advertisement.
The third is ongoing re-checking, which is the one most often overlooked: an approved advertisement does not mean the destination is exempt from then on. Pages are fetched again repeatedly, so a page that was compliant at launch and was later modified — or whose behaviour was changed by a third-party script — can be disapproved weeks afterwards for no apparent reason. The fourth is complaint- and signal-driven inspection, triggered by visitor feedback or anomalous metrics.
These four stages explain two frequent puzzles. The first is why a destination that was fine last week is disapproved now: usually re-checking, combined with something on the page having changed — including third-party script updates that sit outside the advertiser's own version control. The second is why an identical page passed under another account: sampling and signal-driven stages are not exhaustive by design, so passing once does not establish compliance, only that this check did not select it. The account-level enforcement logic is covered in why Google Ads accounts get suspended.
Treating the destination as something to monitor
Because re-checking is continuous and page behaviour drifts over time, a destination is better treated as something under ongoing observation than as a one-off deliverable. Four things are usually worth checking on a schedule: whether the final URL returns a 200 with complete content from each targeted country; whether the hop count and per-hop certificate status of the redirect chain are still sound; whether the response without script execution still contains the core information; and whether the inventory of third-party scripts on the page has changed unexpectedly.
All four can be automated at low cost, and between them they cover the most common causes of failure. Waiting until an advertisement is disapproved means reconstructing what happened with no log from the checking side, which usually costs several times as much time. How to read this kind of monitoring data is covered in reading traffic routing analytics, and the structural differences between a safe page and a real page in safe page versus real page structure.
A closing note on priority. Among destination problems, consistency failures carry the heaviest consequences and the slowest recovery; reachability failures are the most common and the fastest to fix; transparency failures are the cheapest and the least excusable; and category eligibility is the least negotiable. Working through them in that order usually locates the cause faster than reading the policy text clause by clause. The gap between the written policy and how it is applied in practice is covered in Google Ads page consistency compliance.
FAQ
Does Google Ads require the landing page URL to match the display URL?
The display URL and the final URL must share the same root domain, and the landing page has to be the page the advertisement is genuinely about. Parameters, subdirectories and tracking templates are all normal and do not cause a problem on their own. What does cause a problem is a destination resolving to a different site than the display URL implies, or a page whose subject is unrelated to the promoted product. The check is whether the audience arrives where the advertisement said they would, not string equality between two URLs.
Why is my landing page marked as not working when it opens fine for me?
Because the checks are not run from your machine. A destination is fetched from several countries, on desktop and mobile user agents, and by systems that may not execute the same client-side code a browser does. So a geographic rule serving a block page to another country, a consent gate returning nothing to a request without cookies, a certificate that does not cover one hostname in the chain, or content that only appears after script execution will each make a page work for you and fail on the checking side. Reproducing the fetch from the target country with a plain client is usually the fastest way to see what the check saw.
Are redirects allowed on a Google Ads landing page?
Redirects are ordinary and permitted — tracking redirects, canonical host redirects and locale redirects all included. The line falls at what the redirect decides. One that resolves to the same destination for everyone is fine; one that sends the checking system to a different page than the audience receives is a violation regardless of technique. Chains are also worth keeping short, because each additional hop adds a point where a timeout, a certificate problem or a dropped parameter can make the destination look broken.
What does the circumventing systems policy have to do with landing pages?
It is the policy covering destinations that present different content depending on who is asking. Serving one version to an automated check and another to the audience falls under it, as does concealing the true destination behind an intermediate page. The consequence is more severe than a normal disapproval because the policy addresses the integrity of the review process itself, and enforcement is frequently applied at account level rather than to the individual advertisement.
Do I need a privacy policy on the landing page?
A privacy policy is required whenever the page collects personal information, which includes any contact form, newsletter signup or account registration, and in practice it is expected on most commercial destinations. Alongside it, the page should make the identity of the business clear and provide a working way to make contact. These transparency requirements are checked more often than advertisers expect, and a missing privacy policy on a page with a lead form is one of the more common straightforward disapprovals.