Paid Search

What Google's Destination Mismatch Policy Change Means for Advertisers

June 2026·5 min read

Google has confirmed it will update its Destination Mismatch policy in early July 2026. The change allows a final URL to redirect to a different domain in specific cases, provided the advertiser has prior approval from Google. Previously, this was a hard line - the URL you declared in your ad had to be the URL where users landed. No exceptions.

The update is narrow in scope. It is not a blanket permission to redirect wherever you like. Approval must be sought and granted before the redirect is in place. But even that limited shift is worth paying attention to, particularly if you manage accounts with complicated URL structures, affiliate arrangements, or multi-brand portfolio setups.

Why the Original Policy Existed

The destination mismatch rule was built around user trust and ad quality. If your ad says it is taking someone to one domain and the redirect drops them somewhere else entirely, that is a transparency problem - and a potential fraud vector. Google's quality systems are set up to verify that the displayed URL, the final URL, and the actual landing page domain are all consistent.

From a tracking standpoint, cross-domain redirects have always created headaches anyway. GA4 session data can fragment when a user passes through an intermediate domain without proper cross-domain configuration in place. GTM-based tracking can drop parameters. If the redirect strips UTM values or breaks the measurement chain, your cost-per-acquisition data becomes unreliable before the user has even reached your landing page.

So the existing restriction was not arbitrary. It protected both users and the integrity of performance data. Any relaxation of that policy needs to be approached carefully, and advertisers should not assume that getting approval from Google automatically resolves their measurement obligations.

Who This Change Is Likely Aimed At

The practical use cases for approved cross-domain redirects are fairly specific. Think of large advertisers running campaigns through intermediary booking or transaction platforms - sectors like travel, financial services, or insurance, where the brand takes the click but a third-party platform completes the transaction on a separate domain. Or franchise models where a national brand drives paid traffic that resolves to a local partner's subdomain or separate URL.

There are also lead generation setups where the advertiser operates multiple brands or product lines across separate domains, and wants to route traffic dynamically based on audience signals or geography. Until now, doing this cleanly within Google Ads policy required workarounds - landing page infrastructure that technically lived on the declared domain before pushing users onward, for instance.

The approval requirement suggests Google wants to maintain oversight rather than open a door that bad actors could walk through. The legitimate use cases are real, but so is the potential for misuse. That balance is probably why this has been a hard restriction for so long.

The Tracking and Attribution Risk You Cannot Ignore

If you are planning to use this policy change to route paid traffic across domains, your measurement setup needs to be watertight before you do anything else. Cross-domain tracking in GA4 requires explicit configuration - you need to add the destination domain as an authorised cross-domain domain in your GA4 property settings, and ensure your GTM implementation is carrying session data across the boundary correctly.

Server-side tracking becomes significantly more important in a cross-domain scenario. If you are relying on browser-based GTM tags to fire conversion events, a domain change in the redirect chain introduces another point of failure. A server-side container that owns the conversion signal - rather than depending on the user's browser to execute JavaScript on a domain you do not control - is a much more robust architecture for this kind of setup.

You should also audit how your Google Ads conversion tracking is configured. If conversions are firing on the destination domain and that domain is different from your final URL, you need to verify that the gclid parameter is being carried through the redirect and associated correctly. Without that, Smart Bidding loses the conversion signal it needs to optimise, and your reported CPA will not reflect reality.

Campaign Structure Implications

For accounts running Performance Max, the final URL expansion feature already allows Google to override your declared URL and send users to other pages on the same domain. Introducing approved cross-domain redirects into that mix raises questions about how PMax will handle destination signals when the actual landing domain differs from what is set at the asset group level. It is worth watching how Google's guidance develops on this before restructuring campaigns around the new policy.

For standard search campaigns, the practical implication is more straightforward. If you have been maintaining separate campaigns for separate domains when a single campaign with an approved redirect could serve the same purpose, there may be structural simplification on offer. But simpler is not always better - consolidated campaigns can obscure performance differences between destinations, and if the domains serve meaningfully different audiences or products, separation usually produces better data.

What to Do Before July

If this change is relevant to your account, the first step is identifying which campaigns or ad groups would benefit from an approved cross-domain redirect - and being honest about whether the benefit is operational convenience or genuine campaign performance. Those are different things.

The second step is auditing your tracking infrastructure now, not after you have restructured. Confirm your GA4 cross-domain configuration, check that gclid parameters survive any redirects in your current setup, and assess whether a server-side tracking layer is needed before you introduce additional domain complexity.

Google's approval process is the variable none of us can fully plan around yet. The criteria for what qualifies as an approved use case have not been published in detail at this stage. Keep an eye on the updated policy documentation when it goes live in July, and do not assume approval is automatic - build the tracking infrastructure first so you are ready to move quickly if approval is granted.