A domain migration plan template structures every step from pre-launch audits through post-migration monitoring. Without a documented framework, migrations lose traffic and rankings through missed redirects, indexing gaps, and untracked errors that compound over weeks.
A complete domain migration template divides the work into pre-launch audits, migration execution, and post-launch monitoring. Pre-launch tasks include crawling the old domain to capture every indexed URL, mapping redirects one-to-one or pattern-based, verifying canonical tags on staging, and exporting baseline analytics segments. Execution tasks cover DNS cutover timing, 301 implementation methods, Search Console property setup for the new domain, and XML sitemap submission. Post-launch monitoring lists daily crawl error checks, organic traffic comparison by landing page, ranking position tracking for priority terms, and backlink update outreach. Each task needs a responsible party, a deadline, and a binary completion checkbox. Templates that combine checklist rows with decision trees handle edge cases: subdomain consolidations, HTTPS migrations bundled with domain changes, and multi-region ccTLD shifts all require conditional logic the template must surface.
Redirect logic dictates whether a migration preserves rankings or scatters authority. The template must include a redirect inventory sheet: old URL, new URL, redirect type (301 permanent, 302 temporary if testing), and match type (exact, pattern, wildcard). Start by exporting all URLs from Google Search Console performance report and server access logs, not just the sitemap, because discontinued pages with backlinks still pass equity if redirected correctly. Pattern-based redirects work for predictable structures—category page migrations or date-based blog archives—but require regex validation in staging to prevent redirect loops. Orphaned URLs with no logical new-home still need a destination: either the most relevant category page or a custom landing page explaining the content shift. The template should flag high-authority old URLs separately, typically those with referring domains above a threshold you define during the audit, so redirect accuracy receives manual verification rather than batch processing.
Testing on staging prevents production disasters. The template checklist must include crawling the staged new domain with Screaming Frog or Sitebulb to confirm every old URL returns a 301 to the mapped new URL, no redirect chains exist, canonical tags point to the new domain consistently, and hreflang annotations (if applicable) reference new URLs. Verify analytics and tag manager containers fire correctly on staging by checking the dataLayer or using browser extensions, then cross-reference goal completions in a test Google Analytics 4 property. Run a small sample of old URLs through curl or a redirect checker tool to confirm HTTP response codes and final destinations match the map. Staging should mirror production server configuration—same CMS version, same CDN rules, same robots.txt directives—or discrepancies emerge only after DNS changes, when rollback costs multiply. The template needs a staging sign-off row that blocks DNS cutover until all validation cells show green.
DNS propagation is not instant; the template must define a cutover window and a rollback decision tree. Schedule the switch during low-traffic periods to minimize revenue exposure and allow real-time monitoring without alarm fatigue. Lower TTL (time to live) values on DNS records 48 hours before cutover so changes propagate faster if rollback becomes necessary. The template should list rollback triggers: 404 error rate exceeding twice the pre-migration baseline within the first hour, organic landing page traffic dropping below half of the trailing seven-day average within 24 hours, or complete indexing failure where Search Console shows zero impressions after 72 hours. Define who holds rollback authority—typically a joint call between the SEO lead and the technical lead—and document the exact DNS revert procedure, including nameserver changes and CDN cache purges. Rollback is not failure; it is damage control when unforeseen conflicts surface, and having the criteria pre-written prevents panic decisions.
The first 90 days determine whether a migration succeeded or quietly bled equity. The template should prescribe daily tasks for week one: check Google Search Console for crawl errors and index coverage drops, compare organic sessions by landing page against the week prior to migration, and scan server logs for 404 spikes or redirect loops. Week two through week four, shift to every-other-day monitoring, adding ranking position checks for your top 50 keywords and reviewing external backlink destinations in Ahrefs or Semrush to identify high-authority links still pointing to old URLs that need outreach. Months two and three move to weekly reviews, tracking overall organic traffic recovery curves and submitting any lingering old URLs for re-crawling if they remain indexed. The template needs a final sign-off milestone at day 90: organic traffic at or above pre-migration levels, old domain deindexed or showing zero impressions, and no outstanding redirect errors. Only then does migration monitoring shift to standard ongoing SEO cadence.
Not all migrations follow identical paths; the template must accommodate domain-to-domain, HTTP-to-HTTPS combined with domain change, subdomain consolidation, and international ccTLD shifts. Domain-only migrations keep content URLs identical except for the root, simplifying redirect patterns but requiring meticulous Search Console property verification. HTTPS-plus-domain migrations need protocol redirect testing and HSTS header implementation checks added to the staging section. Subdomain consolidations—moving blog.oldsite.com to newsite.com/blog—require path rewrite rules and careful canonical management to avoid duplicate content during the transition. International migrations involve hreflang tag updates and geotargeting settings in Search Console, plus monitoring organic traffic by country to catch regional indexing issues. The template should include a migration-type selector at the top that conditionally shows or hides task blocks, preventing teams from skipping critical steps unique to their scenario or wasting time on irrelevant checks.
A downloadable domain migration template in spreadsheet format provides immediate structure. The first tab should be the master checklist with columns for task description, responsible party, deadline, status, and notes. Subsequent tabs cover the redirect map (old URL, new URL, redirect type), pre-migration URL inventory (URL, impressions last 90 days, backlinks, redirect destination), staging validation results (URL, HTTP code, redirect chain length, canonical), and post-migration monitoring logs (date, metric, value, threshold, flag). Freeze header rows and apply conditional formatting to status columns so incomplete critical-path tasks highlight in red. Include a notes section on each tab explaining what good looks like: a redirect map with zero null new URLs, a staging validation tab showing all 301s and zero 302s, a monitoring log where traffic variance stays within fifteen percent week-over-week after day thirty. Adaptation means deleting irrelevant sections for simpler migrations and expanding monitoring frequency for high-traffic properties, but the core structure—audit, map, validate, execute, monitor—remains constant across every domain change.
Planning and redirect mapping usually require one to three weeks depending on site size and URL complexity. Staging validation adds another week. The actual DNS cutover happens in minutes, but meaningful post-migration monitoring spans 90 days to confirm organic traffic stabilizes and old URLs fully deindex. Rush migrations that skip staging or compress planning windows encounter redirect errors and indexing gaps that extend recovery timelines by months.
Failing to maintain a comprehensive redirect map causes the most lasting damage. Teams often redirect only sitemap URLs or top landing pages, ignoring discontinued pages with backlinks or old URLs still indexed in Google. Those orphaned URLs lose link equity permanently. The second common error is insufficient post-migration monitoring—teams assume success after 48 hours when ranking and traffic impacts often emerge gradually over weeks.
Yes, verify both domains in Search Console before migration and keep both properties active for at least 90 days after cutover. The old property shows residual impressions and crawl errors as Google transitions indexing, helping you identify redirect gaps or URLs that failed to migrate. The new property tracks index coverage growth and new organic queries. Once the old domain shows zero impressions for two consecutive weeks, you can archive that property.
Technically possible but risky. Changing both domain and URL paths multiplies redirect complexity and makes it harder to isolate the cause of traffic drops. If you must bundle them, map every old URL individually rather than relying on pattern redirects, test exhaustively on staging, and extend post-migration monitoring to 120 days. When feasible, migrate the domain first with identical URL paths, stabilize traffic, then tackle URL restructuring as a separate project months later.
Redirect them to the most relevant existing page—usually a parent category, related topic cluster, or the homepage if no logical alternative exists. Avoid deleting them outright or serving 404s if they carry backlinks or residual search impressions, because that wastes link equity. For clusters of discontinued content, create a custom landing page explaining the content consolidation and linking to the updated resources, then redirect the old URLs there.
Organic traffic to the new domain should match or exceed pre-migration levels when segmented by landing page, not just aggregate sessions. The old domain shows zero impressions in Search Console. Crawl coverage in the new property reaches parity with the old property's indexed URL count before migration. Ranking positions for priority keywords stabilize within historical variance ranges. External backlink tools show referring domains resolving to new URLs rather than old ones. If all five hold true, the migration succeeded.