Audit Domain Variants Before a Google Site Migration
Google updated its site-move documentation on June 17, 2026, with a detail that matters during domain migrations: verify and submit Change of Address requests for all relevant old-domain variants, including www, non-www, and subdomains—even when some variants are not actively used.
That guidance does not apply to every URL change. A move from www.example.com to example.com on the same domain is host normalization, not a domain migration. Google says not to use Change of Address for that situation. Use permanent redirects, canonical URLs, internal links, and sitemap entries that consistently identify the preferred host.
For WordPress and WooCommerce operators, the risk is mixed signals. A site may appear to work in a browser while old properties, redirects, canonical tags, robots controls, sitemaps, or paid landing pages still point to different locations.
Need help checking this on your WordPress, Google Ads, Analytics, local SEO, or website setup? Splinternet Marketing can review the issue and help you prioritize the next fix.
Classify the move before touching Search Console
Document the exact old and new locations before changing DNS, hosting, or WordPress settings:
- HTTP and HTTPS versions
- www and non-www hosts
- Subdomains such as shop, blog, staging, regional, or mobile hosts
- Important WordPress and WooCommerce paths, including products, categories, services, landing pages, media files, PDFs, and posts
For a domain-to-domain move, verify the old and new properties in Search Console using the same Google account. Google’s Site Moves and Migrations guidance says to handle all relevant old-domain subdomain variants, including www and non-www, even if they are unused. The Change of Address tool documentation also explains that the tool works at the domain level, does not automatically move subdomains below the specified domain, and moves all protocols of the source property.
For HTTP-to-HTTPS changes, Google says not to use Change of Address. For a same-domain www-to-non-www move, use redirects and canonicalization instead.
What to do next
A small team can complete this preflight and post-launch audit within a week:
- Build the URL map. Export URLs from the current sitemap, WordPress database, analytics, Search Console, and server logs. Include high-value product, service, lead-generation, image, JavaScript, CSS, and PDF URLs. Map each old URL to its closest relevant destination.
- Test direct redirects. Request representative URLs from every old host and protocol. Confirm a direct server-side 301 or 308 response to the correct destination. Check for chains, loops, mixed HTTP/HTTPS behavior, incorrect host targets, and redirects that send unrelated pages to the homepage. Google’s Redirects and Google Search documentation identifies 301 and 308 as permanent server-side redirects.
- Align the new site. Update self-referencing canonicals, internal links, hreflang annotations if applicable, Open Graph URLs, structured data URLs, and sitemap entries. Use the preferred absolute URLs in the sitemap, not duplicate host or protocol variations.
- Inspect crawl controls. Review production robots.txt, meta robots, X-Robots-Tag headers, staging protections, CDN rules, firewall settings, and deployment variables. A forgotten noindex directive or staging block can prevent the new site from being processed as intended.
- Submit and monitor. Submit the new sitemap in Search Console. A sitemap helps Google discover URLs but does not guarantee crawling or indexing. Use URL Inspection on priority pages and monitor indexing, redirect errors, crawl activity, server logs, and conversion-critical landing pages across both old and new properties.
Keep old-domain redirects active for as long as possible and generally for at least one year during a domain migration. Google notes that this gives its systems time to recrawl URLs and transfer signals. Update internal links, ad campaigns, email templates, profiles, and high-value external links so users do not depend on redirects indefinitely.
Also avoid combining a domain move with a major redesign, URL restructuring, and full content rewrite unless the business accepts additional troubleshooting complexity. Google’s migration guidance recommends keeping the site architecture similar where possible because changing several major variables at once makes failures harder to isolate.
The practical standard is simple: the browser, server response, HTML, sitemap, Search Console properties, internal links, and paid landing pages should all point to the same intended canonical location. Audit that consistency before launch—not after organic visibility, product discovery, or lead-generation performance begins to move.
Sources
Need help checking this on your WordPress, Google Ads, Analytics, local SEO, or website setup? Splinternet Marketing can review the issue and help you prioritize the next fix.
This article is for informational purposes only and reflects general marketing, technology, website, and small-business guidance. Platform features, policies, search behavior, pricing, and security conditions can change. Verify current requirements with the relevant platform, provider, or professional advisor before acting. Nothing in this article should be treated as legal, tax, financial, cybersecurity, or other professional advice.
Editorial note: Splinternet Marketing articles are researched from cited platform, documentation, regulatory, and industry sources. AI may assist with drafting and review; final content is checked for source support, practical usefulness, and platform/date accuracy before publication.
