Web Migration and SEO: A Guide to Keeping Traffic | Ighenatt

40% of web migrations generate organic traffic drops that last more than a month. In the most severe cases, sites with years of accumulated rankings lose between 50% and 80% of their visibility in a matter of weeks. The worst part is that in most of these cases the cause is not a Google algorithm change or a manual penalty: it’s simply the lack of SEO planning before pressing the publish button. This guide explains how to avoid it.

Why web migrations are the most underestimated SEO risk

A web migration is any change that alters the way Google crawls, indexes or perceives your site’s URLs. The problem is that development and design teams often treat a migration as a purely technical project (and it is), but they ignore the fact that Google has built a trust model on existing URLs over months or years. When those URLs change without the correct signaling, that capital evaporates.

According to aggregated Ahrefs data on hundreds of analyzed migrations, sites that don’t implement an SEO plan before migrating lose between 20% and 80% of their organic traffic. Recovery, even in well-executed cases, takes between 3 and 6 months as Google Search Central itself acknowledges. For medium-sized sites, Google indicates that it can take “a few weeks” for most pages to be updated in the index, and for large sites it can take even longer.

The three most common types of migration, and their specific risks:

Domain change. This is the highest-impact migration. Google transfers accumulated authority to the new domain through 301 redirects, but the process is not immediate. Without correct use of the change of address tool in Google Search Console, the process slows down.

URL structure change. Redesigns that alter the directory hierarchy, remove descriptive slugs or change the URL pattern are the most frequent source of mass 404 errors. A store that goes from /category/product-name/ to /p/12345/ without mapping redirects destroys all the link equity of its product pages.

Migration to HTTPS. Although Google recommends HTTPS, a poorly executed migration generates mixed content (HTTP resources on HTTPS pages), poorly configured certificates and redirect chains that accumulate latency. This is the type of migration most underestimated by technical teams because it seems simple.

The critical difference between a “technical” migration and an “SEO” one: the technical one is considered complete when the new site works. The SEO one is considered complete when the new site maintains (or surpasses) the organic traffic of the previous one.

Pre-migration checklist: before touching anything

The most important work of the entire migration happens weeks before launch day. Without reference data, you can’t know if the migration was successful or detect what has broken.

1. Complete URL inventory. Use Screaming Frog to crawl the entire site and export all URLs returning a 200 status code. Filter by content type: pages, posts, categories, products, images. Save the file; it is your absolute reference.

2. Identify the highest-value URLs. Open Google Search Console and export the performance report filtered for the last 3 months. Sort by clicks. The 50-100 URLs with the most traffic are your absolute priority: they must have a correct 301 redirect without exception.

Supplement with Ahrefs or Semrush to identify URLs with the most external backlinks. A page with 200 backlinks lost in the migration represents a link equity loss that can take years to recover.

3. Capture the position baseline. Export a snapshot of current positions in GSC: keywords, average position, impressions and clicks. This document is your post-migration success measurement. Without it, you can’t demonstrate whether recovery is complete.

4. Verify the current sitemap and robots.txt. Download and review both files. Make sure the sitemap includes all important URLs and that robots.txt doesn’t block sections that should be indexed. Document the current configuration: you’ll need to correctly replicate it on the new site.

5. External backlink inventory. Export the backlink list from Ahrefs or Search Console. Identify the 20-30 domains that link most to your site. After the migration, consider contacting the most relevant ones to ask them to update their links to the new URLs. With correct redirects this is optional, but it does eliminate a redirect hop for those pages.

The technical SEO audit guide covers the review of your site’s current state as the first step before any migration.

The redirect map: how to plan it correctly

The redirect map is a document that relates each old URL to its new equivalent. It is not optional. It is the core of the entire SEO migration.

Recommended mapping template:

Column by column: the old URL is the one appearing in the Screaming Frog crawl and GSC reports. The new URL is its equivalent on the new site. The redirect code (301 for permanent, 410 for pages being permanently removed). The implementation and verification status.

The 1:1 rule. Each old URL must point to exactly one new URL. Never redirect multiple old URLs to the homepage: Google treats this as a soft 404 and doesn’t pass link equity. If an old page has no direct equivalent, find the new site page most closely matching it thematically.

Special cases requiring attention:

Pagination. Pagination URLs (/blog/page/2/) generally don’t need redirects if the new structure maintains the same logic. If it changes, map them to the first page of each section.

URL parameters. Many sites have URLs with tracking or filter parameters: ?utm_source=, ?color=red. Define in GSC which parameters Google can ignore to avoid duplicate content. They don’t need individual redirects.

Ecommerce facets. Filter URLs in online stores (/sneakers/?size=42&color=black) represent a complex case. If the new site uses the same facet structure, no mapping is needed. If the filter architecture changes, consult an SEO specialist before proceeding.

Pages being removed. If a page has no reasonable equivalent on the new site, use a 410 (Gone) code instead of redirecting to a generic page. The 410 tells Google the page was intentionally removed and to stop crawling it, which is cleaner than an irrelevant redirect.

Technical implementation of 301 redirects

Once you have the complete and verified redirect map, implementation varies depending on the server technology.

Apache (.htaccess). The most common option on shared hosting. Redirect rules are written directly in the .htaccess file:

Redirect 301 /old-page/ https://yourdomain.com/new-page/

For mass redirects with patterns, use mod_rewrite:

RewriteRule ^old-category/(.*)$ /new-category/$1 [R=301,L]

Nginx (nginx.conf). On VPS or dedicated servers with Nginx, redirects go in the server block:

return 301 https://yourdomain.com/new-page/;

CMS (WordPress, Shopify, etc.). Plugins like Redirection (WordPress) or the native redirect management in Shopify allow implementing the map without server access. They are slower than server-level redirects but valid for most sites.

Most frequent implementation errors:

Redirect chains. If URL A redirects to B, and B redirects to C, Googlebot must make two extra requests. Google tolerates chains of up to 5 hops, but each additional hop adds latency and may lose some authority. Before launch, use Screaming Frog in “Follow redirects” mode to detect chains and short-circuit them.

Redirect loops. A redirects to B, B redirects to A. Screaming Frog detects these as red errors. They usually occur in .htaccess implementations with contradicting rules.

Redirects pointing to 404s. The redirect exists, but the destination URL returns 404. This is more damaging than having no redirect because Google reaches the new URL and finds an error. Verify all destination URLs before launch.

Sites with multiple language versions have an added layer: hreflang implementation covers that case in detail.

Launch day: validation protocol

Launch day is not the time to improvise. Have this 10-point checklist prepared and execute it in order:

1. Verify that robots.txt doesn’t block indexation. The most catastrophic and frequent error: the new site launched with Disallow: / in robots.txt, a common staging environment measure that someone forgot to revert. Check it at yourdomain.com/robots.txt before any other action.

2. Confirm that noindex tags are removed. Similar to the previous point: verify with Screaming Frog that no important page has <meta name="robots" content="noindex">.

3. Verify a sample of 20 critical redirects. Manually check the 20 URLs with the most traffic from the baseline. Use an HTTP header check tool to confirm they return 301 and that the destination is correct.

4. Confirm there are no redirect loops. Run a quick crawl with Screaming Frog on the main URLs.

5. Verify the SSL certificate. If this is a migration to HTTPS, check that the certificate is valid for the main domain and any subdomains you use.

6. Detect mixed content. With the browser console (F12 → Console) open the main pages and verify there are no resources loading via HTTP on HTTPS pages.

7. Submit the updated sitemap to GSC. Go to Search Console → Sitemaps → submit the new sitemap URL. If the domain has changed, do this from the new domain’s property.

8. Use the change of address tool (only if changing domain). In GSC → Settings → Change of address. Only valid for complete domain changes, not for URL structure changes within the same domain.

9. Request indexation of main pages. Use the URL inspection tool in GSC to request indexation of your homepage, main service pages and most important posts.

10. Monitor errors in real time during the first 4 hours. Keep the GSC coverage report and server logs open. The first problems usually appear in the hours following launch.

Post-migration monitoring: the critical 90 days

Work doesn’t end on launch day. Most migration problems are detected in the following weeks, not at the moment of launch.

Week 1-2: 404 errors and broken redirects. Googlebot starts crawling the new site immediately. 404 errors appear in the “Not found pages” report in GSC. Review it daily during the first week. Any URL with historical traffic appearing as 404 needs an urgent redirect.

Set up an alert in Google Search Console to receive notifications of new crawl errors. Also activate alerts for sudden session drops in Google Analytics 4 (Reports → Custom alerts).

Week 3-4: indexation problems in the Coverage Report. From the third week, the GSC coverage report starts reflecting the real state of the new site. Frequent problems at this stage: pages marked as “Discovered, currently not indexed” (Google found them but hasn’t processed them yet), pages with incorrect canonical, and detected duplicates.

Compare the total number of indexed pages with the pre-migration baseline. A drop of 15-20% can be temporary (Google still re-processing); a drop of 50%+ requires immediate investigation.

Month 2: position recovery. Compare the GSC performance report with the position baseline captured before migrating. Identify keywords that have lost more than 5 positions. For each one, verify that the corresponding URL is correctly indexed and that the redirect from the equivalent old content works.

A well-migrated site should recover 80-90% of its original positions by the end of the second month. If recovery is lower, check whether there are canonical conflicts between old URLs (still receiving backlink traffic) and new ones.

Month 3: recovered vs lost backlinks analysis. With Ahrefs or Semrush, compare the current backlink profile with the one before migration. Backlinks pointing to old URLs will keep passing authority as long as the 301 redirects are active; Google recommends keeping redirects active for at least a year. “Lost” backlinks (those pointing to pages now returning 404) are the ones you need to recover by contacting the linking domains.

The article on what is technical SEO explains the principles that make a migration possible without visibility losses.

The failed migration case: what to learn

The most common pattern we see in migrations with severe traffic losses always follows the same structure. A business with 3-5 years of web presence decides to completely overhaul its image and technology. The project is managed as a design and development project: new CMS, new visual architecture, new “cleaner” URL system. SEO doesn’t enter the conversation until the new site is ready to publish.

On launch day, the new site is visually impeccable. But in the following 3 weeks, organic traffic drops 60%. Investigation reveals three simultaneous errors: blog URLs changed from /blog/post-title/ to /news/2024/post-title/ without any redirects, service pages completely changed structure and also have no redirects, and the new server’s robots.txt blocked indexation for 5 days because no one verified it after launch.

Recovery took 8 months. With a prior SEO plan, it would have taken 6-8 weeks.

The three errors that always repeat:

First, treating SEO as a layer applied after, not as a design constraint. URL architecture decisions must be consulted with SEO before development is advanced, not the day before launch.

Second, having no reference data. Without the prior crawl, without the position baseline, without the backlink inventory, you can’t measure the impact or prioritize recovery.

Third, not assigning responsibility for post-launch monitoring. The migration “ends” on publication day for the development team, but for SEO it starts that day. Someone must review GSC daily for the first 4 weeks.

With the right preparation, a web migration is an opportunity: clean up URL architecture, eliminate duplicate content, improve internal linking structure. Sites that migrate with SEO planning don’t just preserve their traffic; they often exceed it within 6-12 months.

If you’re planning a web migration and want to make sure you don’t lose the rankings you’ve built, our SEO migration service includes pre-migration audit, complete redirect mapping, technical validation in staging and intensive monitoring during the 90 days following launch.