Why does the change of address tool block URLs with parameters?

What exactly does the change of address tool check?

The Search Console change of address tool performs a precise technical validation before accepting a migration request. It verifies that the homepage of the source site redirects to the homepage of the target site, with no additions or modifications.

If the redirect points to a URL with URL parameters (like ?utm_source=migration or ?ref=old-site), the tool blocks the process. This check applies from the homepage — regardless of whether your internal redirects are perfect.

Why is there this restriction on parameters?

Google applies a logic of strict matching to prevent abuse and ensure that the migration is legitimate. A change of address must indicate a simple relocation of content, not a transformation or manipulation.

Adding parameters — even benign ones like tracking — creates a different URL in Google's eyes. The tool interprets this as non-compliance with the one-to-one rule. This rigid approach prevents sites from attempting to migrate to ambiguous structures or exploiting the tool for misguided purposes.

Does this rule only apply to the homepage?

Mueller's statement clarifies that the check is made on the homepage. This serves as the initial checkpoint. If this redirection fails due to parameters, the tool refuses to proceed.

For internal pages, the tolerance remains unclear. The tool does not explicitly document whether it checks each URL or just the homepage. In practice, it's best to apply the rule everywhere: redirect cleanly, without parameters, to avoid any blocking.

• The tool requires a strict 301 redirect from the homepage to the new homepage, without any parameters added.
• URL parameters — tracking, session, referral — break the one-to-one logic and trigger an automatic rejection.
• This check specifically concerns the homepage, but prudence advises applying the same rule to all redirects.
• No documented tolerance for canonical or systematic tracking parameters.

Is this restriction consistent with ground observations?

Absolutely. Practitioners' feedback confirms that the change of address tool systematically rejects migrations where the homepage redirects with added parameters. No known exceptions, even for legitimate cases of internal tracking.

This behavior aligns with Google's philosophy of clean migration: a change of address should be a relocation, not a structural overhaul. The rigidity of the tool forces SEOs to clean up their redirects before submitting.

What areas of uncertainty remain?

Mueller does not specify whether the tool checks only the homepage or audits a sample of internal pages. [To be verified]: no official documentation details the depth of this check.

Another ambiguity: what happens if the parameter already exists on the old site? If the old homepage redirects to a new homepage with the same parameter (e.g., ?lang=fr to ?lang=fr), will the tool still refuse? The statement does not clarify this. As a precaution, remove any parameters from the target.

In what cases does this rule pose a problem?

Sites using systematic tracking (e-commerce platforms, SaaS) face this constraint. If their architecture requires session or source parameters, they cannot use the change of address tool.

Alternative: handle the migration manually via 301 redirects, bypassing the tool. This is longer, but it avoids blockage. The risk? Losing the effect of explicit signaling that the tool sends to Google to accelerate the reevaluation of the new site.

What needs to be done concretely before submitting a change of address?

Ensure that the 301 redirect from your old homepage points to the new homepage without any parameters. Test with a redirect checking tool (Screaming Frog, curl, Redirect Path) to confirm that the target URL is clean.

If your platform automatically adds parameters (tracking, session, language), temporarily disable them or configure an exception for the homepage. The goal: a direct redirect, with no additions, to https://newsite.com/ and nothing else.

What mistakes should absolutely be avoided?

Never redirect the homepage to a URL containing UTM, referral, or session parameters. Even if these parameters seem harmless, the tool detects them and blocks the process.

Another trap: redirecting to a canonical version with a parameter. Example: oldsite.com/ → newsite.com/?version=desktop. Even if the canonical tag points to the version without the parameter, the tool checks the destination of the redirect, not the canonical. Result: rejection.

How can I check that my site is compliant?

Before submitting the request in Search Console, conduct a manual test. Load your old homepage in a browser with private browsing and observe the address bar after the redirect. If it contains the slightest ? or &, correct it.

Also use the Network tab in DevTools to trace the chain of redirects. A clean chain: direct 301 from oldsite.com/ to newsite.com/, final status 200, no parameters in sight. Any deviation signals a potential problem.

• Check the 301 redirect of the homepage with a dedicated tool (Screaming Frog, curl)
• Ensure that the target URL contains no parameters (?utm, ?ref, ?session, etc.)
• Temporarily disable automatic tracking parameters on the homepage
• Test the redirect in private browsing to confirm the final URL
• Monitor the complete chain of redirects via DevTools (Network)
• Document the configuration for quick rollback if necessary