Your Domain Migration SEO Checklist (Don’t Skip Step 4)
Domain migrations seem simple on paper. Point the old domain to the new one, set up redirects, and you’re all set. But many migrations lose significant traffic in the first month, not because the technical execution was wrong, but because teams overlook HTTPS setup or launch before the timing is right. Here’s the timeline that keeps your migration from losing traffic.
Why Timing Breaks Migrations
Most domain migration guides present the process as a flat checklist, as if every step carries the same weight. In practice, migrations hinge on steps that take time no matter how well you execute them.
DNS changes can take up to 48 hours to propagate globally depending on TTL settings and ISP caching behavior. SSL certificates need to be provisioned before traffic arrives at the old domain. Search engines need weeks to recrawl and reindex your site under the new domain.
Launching on Friday afternoon without accounting for these delays means discovering by Monday morning that a portion of users still hit the old server, HTTPS redirects show certificate errors, or paid advertising campaigns are broken because campaign URLs weren’t included in the redirect mapping.
The solution is a timeline based approach that accounts for propagation windows and coordinates multiple teams (IT, marketing, legal) around specific deployment windows rather than vague “launch day” instructions.
Pre-Migration: Day -7
Step 1: Complete URL Inventory
Export every URL that receives meaningful traffic from your analytics platform. Include product pages, blog posts, landing pages, resource downloads, and any pages linked from email campaigns or paid advertising.
Use tools like Screaming Frog, sitemap exports, or Google Analytics filtered by traffic volume to build this list. Your deliverable is a spreadsheet with three columns: old URL, new URL, and redirect type (301 permanent redirect).
Start this step seven days before migration because stakeholders need time to review the mapping and identify any URLs that serve active marketing campaigns or customer commitments.
Step 2: Reduce DNS TTL to 300 Seconds
DNS TTL (Time To Live) controls how long DNS records are cached before resolvers query for updated information. Default TTL values are typically 3600 seconds (1 hour) or 86400 seconds (24 hours).
Before migrating, reduce your DNS TTL to 300 seconds (5 minutes). This change enables faster rollback if something goes wrong during migration. More importantly, it ensures that once you update DNS records, the change propagates faster than it would with a 24 hour TTL.
Critical timing requirement: after reducing the TTL, wait the full duration of your old TTL before proceeding. If your current TTL is 24 hours, reduce it to 300 seconds and then wait 24 hours. This ensures that all cached DNS records expire and pick up the new lower TTL value.
You can check your current TTL using the dig command or online DNS lookup tools. Change the TTL value in your domain registrar’s DNS settings or with your DNS hosting provider.
Step 3: Build Redirect Mapping (Day -5)
Map each old URL to its corresponding destination on the new domain. This step requires careful attention to preserve user experience and SEO value.
Homepage should redirect to homepage, not to a subdirectory or section page. Product pages should map to their equivalent products on the new domain, not all redirect to the homepage. Blog posts should preserve deep links where equivalent content exists on the new domain.
For sites with thousands of pages, use pattern matching or wildcards where the URL structure is consistent. For example, if all blog posts follow /blog/post-title on both domains, a single wildcard rule can handle the entire blog section.
Document campaign URLs separately. Marketing teams often use specific URLs in email campaigns, paid search ads, and social media that need to remain functional after migration.
Step 4: Provision HTTPS Certificates ⚠️
This is the most commonly skipped step in domain migrations, and it causes the majority of post migration failures.
Why this matters: the SSL/TLS handshake occurs before any redirect code can execute. If the certificate doesn’t exist for the domain users request, browsers show security warnings and users leave before the redirect runs. For a detailed technical explanation of why HTTPS redirects fail without pre-provisioning, see ourTechnical Guide to URL Redirects in 2026.
The problem: when you update DNS to point your old domain to a redirect service or new server, HTTPS traffic requires a valid SSL certificate for the old domain before the redirect can execute. If the certificate doesn’t exist, browsers show security warnings and users leave before the redirect runs.
Domain registrar “forwarding” features typically handle HTTP redirects but do not provision SSL certificates for HTTPS. This causes HTTP redirects to work while HTTPS traffic fails with certificate errors.
DNS configured redirect services provision certificates during setup, before any traffic arrives. When you update DNS and traffic begins flowing to the redirect service, the certificate already exists and is valid for the domain users requested.
Provision certificates at least 24 hours before changing DNS records. While certificate provisioning typically completes within minutes through services like Let’s Encrypt, the 24 hour buffer accounts for any DNS verification requirements and ensures certificates are active before migration day.
For technical details on why HTTPS redirects break without pre provisioning, see Why HTTPS Redirects Break (And How DNS Fixes It).
Migration Day: Day 0
Step 5: Implement Redirects (9:00 AM)
Configure your redirect rules in whichever system you chose during planning. Test both HTTP and HTTPS before updating DNS.
For HTTP testing, use curl or similar command line tools to verify the redirect destination and response code. For HTTPS testing, use a browser to check for certificate errors or warnings.
Watch for these issues:
Redirect chains: old domain redirects to intermediate domain, which then redirects to final destination. This slows load times and risks losing link authority. Fix chains so the old domain redirects directly to the final destination.
Certificate errors: if HTTPS shows certificate warnings, revisit Step 4. The certificate either wasn’t provisioned or isn’t valid for the requested domain name.
Wrong destinations: spot check important URLs to ensure they land on the correct pages. Pay special attention to product pages and high traffic blog posts.
Step 6: Update DNS (10:00 AM)
Update your DNS A record to point to the redirect service or new server IP address. Make this change through your domain registrar’s control panel or DNS hosting provider.
Verify the change using dig olddomain.com or online DNS lookup tools. You should see the new IP address, though propagation to all resolvers worldwide will take time.
DNS propagation can take anywhere from minutes to 48 hours depending on ISP caching policies and TTL settings. Even with a reduced TTL of 300 seconds, some ISPs ignore published TTL values and cache DNS records according to their own policies. This is why you reduced your TTL seven days ago and why you’re monitoring carefully over the next 48 hours.
Step 7: Monitor Traffic Patterns (Day 0 through Day 2)
Watch real time analytics for both your old and new domains. Traffic to the new domain should gradually increase while traffic to the old domain decreases toward zero.
Check for unexpected 404 errors on the new domain. These indicate URLs that weren’t included in your redirect mapping or mapping errors. Check for certificate errors in server logs or browser testing.
After 24 hours, traffic to the old domain should be minimal. If more than 10% of traffic still hits the old domain after 24 hours, DNS propagation is slower than expected in certain regions. This is normal in some cases but worth monitoring.
Use Google Analytics real time reporting and server access logs to track this transition. If you see problems, the reduced TTL from Step 2 enables faster rollback by changing DNS back to the old IP address.
Post-Migration: Week 1
Step 8: Google Search Console (Day 2)
Add your new domain to Google Search Console if you haven’t already. Verify ownership using DNS verification, HTML file upload, or your preferred method.
Submit a change of address through Search Console’s change of address tool. This informs Google that you’ve intentionally moved domains and helps preserve your search rankings during the transition.
Monitor crawl errors and indexation status in Search Console. According to Google’s official documentation, a medium sized website can take a few weeks for most pages to move in the search index. Larger sites can take longer.
Temporary traffic fluctuations can occur during this period. Search engines need time to recrawl the old domain, follow redirects, and reindex content under the new domain. Even when redirects are implemented correctly, traffic patterns may shift temporarily during the reindexing window. Monitor your analytics closely during the first month to identify any issues requiring attention.
Step 9: Update Citations and References (Day 3 through Day 7)
Update your domain everywhere it appears outside your direct control:
Social media profiles and bios need the new domain. Email signatures across the company should reflect the new domain. Paid advertising campaigns must be updated or they’ll continue sending traffic to the old domain, wasting ad spend.
For backlinks from other websites, 301 redirects handle this automatically. High authority sites may warrant outreach to request link updates, but redirects preserve link authority so this isn’t urgent for most backlinks.
Step 10: Restore DNS TTL (Day 7)
After seven days of stable operation with no rollback requirements, increase your DNS TTL back to 3600 seconds (1 hour) or 86400 seconds (24 hours).
Higher TTL values reduce DNS query load on your nameservers and improve resolution speed for users since DNS resolvers cache records longer. Only restore the TTL once you’re confident the migration is stable and won’t need rapid DNS changes.
Common Migration Failures
Understanding typical failure patterns helps you avoid them:
Launching before TTL expires. Teams reduce DNS TTL but don’t wait for the old TTL to expire before migrating. Result: Some users’ DNS resolvers still have the old IP cached for hours or days, causing a split where some traffic goes to the old server and some to the new one. Solution: Wait the full old TTL duration after reducing the value.
Skipping certificate pre provisioning. Teams implement redirects but don’t provision HTTPS certificates before changing DNS. Result: HTTPS traffic shows security warnings, users leave before the redirect executes. Solution: Provision certificates at least 24 hours before DNS changes.
Forgetting marketing campaign URLs. Teams map main site pages but miss URLs used in active email campaigns or paid ads. Result: Campaign URLs break, wasted ad spend, confused users. Solution: Audit all URLs in active marketing channels before building redirect mapping.
No rollback plan. Teams have no documented procedure for reverting DNS changes if something breaks. Result: Extended downtime while figuring out how to fix issues. Solution: Reduced TTL provides faster rollback capability. Document the exact steps to revert DNS to previous values.
Friday afternoon launches. Teams launch late Friday, discover issues over the weekend with minimal staff available. Result: Problems persist for 48 to 72 hours before full team can address them. Solution: Launch Tuesday through Thursday morning when full teams are available to monitor and respond.
Ready to Migrate?
For domain migrations requiring bulk redirect management with automatic HTTPS certificate provisioning, redirect.pizza provides DNS level redirect services with Let’s Encrypt integration.
