Site migrations are one of the highest-risk operations in digital marketing. One wrong redirect, one missed canonical tag, one overlooked URL change—and months of organic search equity evaporates in days. I have overseen more than 200 site migrations across my agency career. The ones that go wrong are almost never caused by bad content or weak backlinks. They are caused by preventable technical mistakes that the team either did not know to look for or decided to skip under time pressure.
This checklist is built from those 200+ migrations. Every item has been tested in production. Skip any of them at your own risk.
Pre-Migration SEO Audit: Know What You Are Protecting
Before touching a single file or updating a DNS record, you need a complete inventory of your current SEO assets. This is not optional. You cannot protect what you have not measured.
Export your top 500 pages by organic traffic, organized by landing page, organic sessions, and current keyword rankings. Use Google Search Console, Google Analytics 4 (if you still have organic data there), and your rank tracking tool. The goal is to know exactly which pages drive traffic, which keywords they rank for, and what your current visibility looks like in every geographic and language market you serve.
Pull your complete backlink profile. Every redirect plan starts with understanding which pages have the most link equity pointing to them. A page with 200 referring domains pointing to it needs a 301 redirect. A page with zero backlinks and zero traffic can be handled differently. Without this data, you are guessing.
Crawl your current site with Screaming Frog or Sitebulb. Export every URL—canonical tags, status codes, page titles, meta descriptions, H1s, and internal link structure. You need this as your baseline. When something breaks post-migration, this crawl is what tells you exactly what went wrong.
Document your current site architecture. Which pages are top-level? Which are nested? What is your URL structure? What subdomains are in use? Note every parameter, every hyphenation pattern, every trailing slash behavior. This documentation becomes your migration blueprint.
URL Mapping: The Most Critical Document You Will Create
URL mapping is the process of matching every old URL to its new equivalent. This is not optional and it is not automatic. It requires human analysis for every URL that matters.
For each page with organic traffic or backlinks, create a row in a spreadsheet with: the old URL, the new URL, the redirect type (301 for permanent moves, 302 for temporary), the reason for the mapping decision, and any special notes about pagination, query parameters, or URL variations.
URL mapping is where most migrations go wrong. The common mistakes are: mapping a page to the homepage instead of the relevant new page (splits link equity across the entire site instead of preserving it), mapping to a 404 page, mapping to a URL that will also be changing in a future phase, and not accounting for URL parameter variations that all need individual redirects.
Test your URL mapping before launch. Do not wait until the migration day to find out your mapping document has errors. Run simulations against your staging environment and verify every redirect resolves correctly.
Technical SEO: The Infrastructure Checklist
Redirect Implementation
Every mapped URL needs a server-level redirect from the old URL to the new URL. Do not rely on meta refresh or JavaScript redirects for SEO-critical pages. These are ignored by search engine bots and pass little to no link equity.
For Apache servers, your .htaccess file needs to be configured with RewriteRule directives that handle the old URL patterns. For Nginx, you need location blocks with permanent redirects. For IIS, you need web.config with httpRedirect elements. Each server type has its own syntax, and each has its own failure modes. If you are not comfortable with server configuration, hire someone who is. A malformed .htaccess file can take your entire site offline.
Implement wildcard redirects where appropriate. If you are changing from /blog/ to /insights/ and all your blog URLs follow the pattern /blog/post-name, a single wildcard redirect rule covers hundreds of pages. But wildcard redirects need careful testing—wildcard rules can create redirect chains if not written precisely.
Canonical Tags
After migration, every page on your new site must have a self-referencing canonical tag pointing to its own URL. If you use a CDN or have multiple server environments, make sure the canonical tag reflects the canonical (public) URL, not the internal server URL.
Check that there are no conflicting canonical signals—no canonical pointing to an old URL, no canonical pointing to a redirect chain, no canonical pointing to the homepage for pages that should have their own canonical identity.
Hreflang Tags
If you operate in multiple languages or regions, hreflang tags need to be audited post-migration. Every hreflang annotation must reference the correct canonical URL on the new site. Migrations that span protocol changes (HTTP to HTTPS) or domain changes are particularly prone to hreflang breakage because the URLs in every hreflang declaration must be updated.
Use an hreflang validation tool to check your entire site after migration. The technical SEO audit should include hreflang verification for any international site.
XML Sitemaps
Generate new XML sitemaps reflecting the new site structure. Every canonical URL should appear in the sitemap exactly once. URLs that return 404, 301, or 302 should not appear in the sitemap. Submit the new sitemaps to Google Search Console and Bing Webmaster Tools.
Update your robots.txt to reference the new sitemap location. If your robots.txt is blocking the sitemap or referencing old sitemap URLs, search engines will not discover your new pages efficiently.
Schema Markup and Structured Data
Every piece of structured data on your site references URLs—organization URLs, article URLs, product URLs, breadcrumb URLs. After a migration, every URL in every piece of structured data must be updated to reflect the new URL structure. A single structured data block pointing to a 404 page can create indexing problems.
Run your new URLs through Google’s Rich Results Test and Schema Markup Validator to confirm all structured data is valid and error-free.
The Migration Window: Execution Strategy
Migration day is not the time to experiment. Here is the sequence that minimizes risk.
First, take your current site offline as a backup image or archive. Download a complete static copy. If something goes wrong during migration, you need a way to restore the current state instantly. Do not skip this step.
Second, update your DNS. Point your domain to the new server. DNS propagation takes time—up to 48 hours, though most changes resolve within a few hours. During the propagation window, some users and search engine bots will hit the old server and some will hit the new one. Your redirect rules on both servers need to be active during this window.
Third, verify redirect chains are resolving correctly. A redirect chain—where URL A redirects to URL B which redirects to URL C—is a performance and SEO problem. Use Screaming Frog to crawl your new site and verify that every redirected URL resolves in a single hop.
Fourth, monitor Search Console for indexing signals. Within 24-48 hours of migration, Googlebot should start crawling your new URLs and following redirects from your old URLs. If you are not seeing crawling activity on your new URLs, something in your server configuration is blocking access. Check robots.txt, firewall rules, server authentication, and DNS resolution.
Post-Migration Monitoring: What to Watch For
The first two weeks after migration are critical. Set up monitoring before you migrate, not after.
Track organic traffic daily. Look for sudden drops in sessions from specific pages or keyword clusters. A drop in overall organic traffic is normal in the first 48 hours as DNS propagates and bots re-crawl. Sustained drops beyond day three indicate a problem.
Monitor Search Console for index coverage issues. New 404 errors, crawl errors, and canonical warnings that were not present before migration need immediate investigation. Every 404 on a page that previously received organic traffic should be traced to its root cause—usually a missing redirect or incorrect URL mapping.
Track keyword rankings weekly. You will see volatility in the first 4-6 weeks post-migration. Some keywords will recover quickly; others will fluctuate. What you are watching for is a sustained downward trend that indicates the migration has damaged your visibility. Our SEO services team tracks these signals continuously during post-migration periods.
Monitor Core Web Vitals. A migration often involves infrastructure changes—new hosting, new CDN, new server configuration. These changes can affect page load speed, Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint. All four metrics influence Google rankings. Monitor them post-migration and address any regressions immediately.
Common Migration Mistakes and How to Avoid Them
The site migration that kills rankings usually falls into one of these categories.
Migrating without a complete URL inventory is the number one cause of losses. If you do not know every URL that exists, you cannot redirect every URL that matters. The ones you forget become 404s, and 404s on high-traffic pages equal immediate ranking loss.
Changing too many things simultaneously. If you are migrating to a new domain, a new CMS, a new URL structure, and new hosting at the same time, you have no way to isolate what caused a problem if something goes wrong. Where possible, phase migrations: domain change first, then URL structure, then platform. Each phase should be stable for at least two weeks before the next.
Not setting up proper monitoring in advance. Post-migration problems that are caught within 48 hours are usually fixable. Problems that are discovered three weeks later because nobody was watching are often irreversible.
Forgetting about internal links. After migration, all internal links should point to the new URLs. Any internal link that still points to an old URL creates an unnecessary redirect hop, slows page load, and dilutes link equity. Run a site crawl of the new site and identify every internal link that points to an old URL. Fix them programmatically.
Ready to dominate AI search? Get your free GEO audit →
Case Study: The Migration That Should Have Failed
We took over a migration mid-disaster. A mid-sized e-commerce site had migrated to a new platform and lost 67% of organic traffic in three weeks. When we audited what happened, we found four problems: 400+ product pages had been redirected to the homepage instead of their new URLs, canonical tags were pointing to old URLs, the XML sitemap was still referencing the old domain, and the robots.txt was blocking the new sitemap.
We fixed all four issues over a 10-day period. Within six weeks, the site had recovered 89% of its pre-migration organic traffic. The remaining 11% never came back—the damage to some long-tail keyword rankings was permanent because the old pages had been removed without redirect coverage.
The lesson: a migration is only as good as its preparation. You cannot fix mistakes after they have been live for weeks. The fix has to happen before launch.
When to Hire Outside Help
If your site has more than 500 indexed URLs, more than 10,000 monthly organic sessions, or operates in multiple languages or regions, you need a dedicated technical SEO resource managing your migration. Not a developer who “knows a bit about SEO.” Not a marketing manager who will handle it on the side. A specialist who has managed migrations at your scale before and knows where the failure points are.
The cost of a failed migration—in lost traffic, lost revenue, and recovery effort—dwarfs the cost of proper migration support. We have written about this in our SEO consulting services in more detail, but the short version is: if you have meaningful organic traffic to protect, treat migration as a surgical procedure, not a move.
Frequently Asked Questions
How long does a site migration take to fully recover from an SEO perspective?
Most sites see ranking recovery within 4-8 weeks if the migration is executed correctly. Some competitive keywords may take 3-4 months to fully stabilize. If you have not recovered 80%+ of your pre-migration organic traffic within 90 days, something in your migration plan needs to be re-examined.
Should I use 301 or 302 redirects for a site migration?
Use 301 redirects (permanent) for any page that is moving to a new URL permanently. This tells search engines to transfer link equity from the old URL to the new one. Only use 302 redirects if the move is genuinely temporary—which is rare in site migrations. 302 redirects do not pass link equity and can cause ranking instability over time.
What happens to my backlinks after a site migration?
Well-implemented 301 redirects preserve the link equity of backlinks pointing to old URLs. However, some backlinks will be lost over time as sites update or remove links. Our backlink services include monitoring and outreach to reclaim lost links during migration periods.
Can I migrate my site without losing rankings?
Yes, with proper preparation. The migrations that lose rankings are ones where redirects are missing, canonical tags are broken, or URL mapping is incomplete. A meticulously planned migration with comprehensive URL mapping, thorough redirect implementation, and active post-migration monitoring can preserve nearly all pre-migration SEO equity.
Should I migrate to HTTPS before or after changing my domain?
We recommend migrating to HTTPS as a separate phase before a domain change. HTTPS migration on its own carries relatively low risk. Combining HTTPS migration with a domain change multiplies the complexity and the risk. Sequence your changes.
How do I know if my migration was successful?
Success metrics: organic traffic returns to within 10% of pre-migration levels within 8 weeks. Core Web Vitals remain stable or improve. No sustained increase in 404 errors for previously indexed pages. Keyword rankings recover for all top 20 pages. Index coverage in Search Console shows no new errors for pages that previously indexed successfully.
Ahrefs vs Semrush vs Moz: The Ultimate SEO Tool Comparison 2026
Ahrefs, Semrush, and Moz have dominated the SEO tool market for over a decade. But…
Read More →
Video SEO: Schema, Transcripts, and Signals That Get Videos Ranked
Video content now dominates search. Google surfaces video results in over 26% of all search…
Read More →
Technical SEO for AI Crawlers: Configuring Sites for GPTBot, ClaudeBot, Perplexitybot
AI crawlers are now a significant and growing portion of web traffic, and most sites…
Read More →-
By Guy Sheetrit
- May 19, 2026
By Guy Sheetrit
