Website Migration SEO Checklist: How to Redesign Without Losing Rankings

68% of website migrations result in organic traffic loss. Some lose 10% to 20% for a few weeks — a temporary dip that recovers. Others lose 40% to 80% and never recover because the damage is structural: missing redirects, deleted content, broken internal links, and stripped metadata. The difference between a migration that preserves rankings and one that destroys them is not talent or budget — it is process. Every successful migration follows the same checklist. Every failed one skipped steps on that checklist.

This guide covers the complete migration process in three phases: pre-launch preparation, launch day execution, and post-launch monitoring. Revenue Group has managed over 40 website migrations without a single significant traffic loss because we follow this exact sequence for every project. For ongoing technical SEO support beyond migration, see our technical SEO services.

Phase 1: Pre-Launch Preparation (4 to 6 Weeks Before Launch)

Step 1: Crawl and Inventory the Existing Site

Before you change anything, document exactly what exists. Crawl the entire current site using Screaming Frog, Sitebulb, or Ahrefs Site Audit. Export a complete list of every URL, its title tag, meta description, H1, word count, and canonical tag. This inventory becomes your baseline — the map of what Google currently knows about your site. Revenue Group's migration projects begin with a crawl that typically reveals 15% to 25% more pages than the client was aware of, including old blog posts, orphaned landing pages, and PDF files that still receive organic traffic.

Step 2: Identify High-Value Pages

Pull organic traffic data from Google Analytics and Google Search Console for the past 12 months. Identify every page that receives organic traffic — even pages receiving only 5 to 10 visits per month. Cross-reference with backlink data from Ahrefs or Semrush to identify pages with inbound links regardless of traffic. These high-value pages are your migration priorities. A page with 200 monthly organic visitors and 15 referring domains represents years of accumulated SEO equity that a missed redirect would erase. Revenue Group color-codes pages into three tiers: critical (top 20% of traffic or 10+ backlinks), important (measurable traffic or 1-9 backlinks), and low-priority (no traffic and no backlinks). Critical pages get individual attention during migration. Low-priority pages get bulk redirect treatment.

Step 3: Build the Redirect Map

The redirect map is a spreadsheet with two columns: old URL and new URL. Every page on the old site gets mapped to its equivalent on the new site. If a page is being removed, it gets redirected to the most relevant remaining page. If multiple old pages are being consolidated into one new page, all old URLs redirect to the consolidated page. The redirect map is the single most important document in the migration — Revenue Group requires client sign-off on the map before any development work begins because a wrong redirect is harder to detect and fix than a missing one.

Common redirect map mistakes: redirecting all old pages to the homepage (Google treats this as a soft 404, and you lose all page-specific rankings), using 302 temporary redirects instead of 301 permanent redirects (302s do not pass full link equity), and creating redirect chains (page A redirects to page B which redirects to page C — each hop loses approximately 10% of link equity). For understanding when a full rebuild is the right approach versus a simpler redesign, see our guide on rebuild vs. redesign decisions.

Step 4: Preserve On-Page SEO Elements

For every page that ranks well, document and preserve these elements on the new version: the exact title tag (or an improved version that keeps the primary keyword), the meta description, the H1 heading, the overall content structure and word count, internal links within the content, and schema markup. Redesigning the visual layout is fine — changing the heading structure, removing content sections, or rewriting title tags on ranking pages introduces unnecessary ranking risk. Revenue Group transfers all on-page SEO elements from the old page inventory to the new site specifications, ensuring that the content Google is ranking remains intact even as the design changes around it.

Phase 2: Launch Day Execution

Step 5: Implement All Redirects Before Going Live

Every redirect in the map must be active the moment the new site goes live. There should be zero time between the old site going down and the redirects being in place. Revenue Group implements redirects on the new hosting environment and tests them against the staging URL before switching DNS. For Netlify and similar platforms, redirects go in a _redirects file or netlify.toml configuration. For Apache servers, redirects go in .htaccess. For Nginx, they go in the server configuration. The redirect method varies by platform, but the requirement is absolute: all redirects must be functional at launch. Testing means running the full redirect map through a redirect checker tool and verifying that every old URL returns a 301 status code pointing to the correct new URL.

Step 6: Submit the New Sitemap

Generate a new XML sitemap containing only the new URLs (not the old ones) and submit it to Google Search Console immediately after launch. Also submit the sitemap to Bing Webmaster Tools. The sitemap tells search engines which pages exist on the new site and accelerates the reindexing process. Revenue Group submits the new sitemap and simultaneously requests indexing for the 10 to 20 highest-traffic pages using the URL Inspection tool in Search Console — this prioritizes Google's recrawling of the most important pages.

Step 7: Update Internal Links

Internal links on the new site should point directly to new URLs, not to old URLs that then redirect. While redirects pass link equity, each redirect hop introduces a small delay and a minor equity loss. More importantly, internal links pointing to redirected URLs indicate to Google that the site's own internal structure is not aware of its current URL architecture — a minor negative quality signal. Revenue Group audits every internal link on the new site before launch, replacing any that point to old URLs or external redirects.

Step 8: Verify Technical Foundation

Before announcing the launch, verify these technical elements: robots.txt is not blocking any important pages (a common staging-to-production error where the staging robots.txt that blocks all crawling gets deployed to production), canonical tags point to the correct new URLs (not leftover canonicals pointing to old URLs or the staging domain), Google Analytics and Search Console tracking code are installed and reporting, and SSL is active on all pages with proper HTTP-to-HTTPS redirects. Revenue Group runs a post-launch crawl of the new site within 30 minutes of going live to catch any of these issues before Google's next crawl. For broader visibility issues, see our guide on why websites do not show up on Google.

Phase 3: Post-Launch Monitoring (First 90 Days)

Step 9: Monitor Crawl Errors Daily for 2 Weeks

Check Google Search Console's Coverage report daily for the first 14 days after launch. Any spike in 404 errors indicates pages that visitors and Google are trying to reach that do not exist on the new site — each one is a missed redirect that needs to be fixed immediately. The first 48 hours are critical because Google typically recrawls recently changed sites within 24 to 48 hours of detecting the DNS change. Revenue Group sets up automated alerts for 404 spikes in Search Console and fixes any new errors within 4 hours of detection during the first two weeks.

Step 10: Compare Traffic Week Over Week

Compare organic traffic for the first week post-launch against the same week in the previous month. A drop of up to 10% is normal fluctuation during the reindexing period. A drop of 10% to 20% warrants investigation — check for missing redirects, deindexed pages, or crawl errors. A drop over 20% indicates a structural migration error that requires immediate diagnosis. Revenue Group provides daily traffic reports to clients during the first two weeks post-migration, with a full analysis at the 30-day mark comparing pre-migration and post-migration performance across all tracked keywords.

Step 11: Validate Redirect Map Completeness

At the 30-day mark, run a full crawl of the old site's URL list and verify that every URL either redirects correctly or returns a 410 (intentionally removed) status. Cross-reference Search Console's 404 report with the original page inventory. Any page that appears in the 404 list and had traffic or backlinks needs a redirect added retroactively. Revenue Group performs this validation at 30 and 90 days post-launch, catching late-appearing crawl errors from pages that Google did not recrawl immediately.

Step 12: Monitor Keyword Rankings

Track rankings for your top 50 to 100 keywords weekly for the first 90 days. Some fluctuation is expected during reindexing, but any keyword that drops more than 10 positions and does not recover within 2 weeks needs investigation. Common causes: the page targeting that keyword was not properly redirected, the new version of the page has different or less content, the title tag or H1 was changed and no longer targets the keyword, or the new page's internal link structure provides less authority than the old one. For a deep dive into all the technical factors that affect rankings, see our guide on Core Web Vitals optimization.

The Migration Types That Need Extra Care

Not all migrations carry the same risk. A visual redesign on the same domain with the same URL structure is the lowest-risk migration — you are changing the design but keeping everything Google cares about intact. A domain change (moving from olddomain.com to newdomain.com) is higher risk because you are asking Google to transfer all authority from one domain to another, a process that can take 3 to 6 months to fully settle. A platform change (moving from WordPress to Squarespace, for example) is moderate risk because URL structures, internal linking, and technical capabilities often differ between platforms.

The highest-risk migration is a combined change: new domain, new platform, new URL structure, and new content simultaneously. Revenue Group strongly recommends against changing more than two variables at once. If you must change domain, platform, and URLs, keep the content identical for the first 90 days, then make content changes after rankings have stabilized. Changing everything at once makes it impossible to diagnose the cause if traffic drops — you cannot determine whether the loss is from missing redirects, changed content, or domain authority transfer delays when all three changed simultaneously.

What to Do If Traffic Drops Post-Migration

If organic traffic drops more than 15% in the first week, work through this diagnostic sequence: first, crawl the old URL list and identify every URL returning a 404 or improper redirect — fix these immediately. Second, check robots.txt to confirm the production site is not blocking crawlers. Third, verify canonical tags are pointing to the correct new URLs, not old URLs or the staging domain. Fourth, check for a noindex meta tag on critical pages — this sometimes persists from the staging environment. Fifth, compare the content of your top 10 traffic pages old versus new — if significant content was removed during the redesign, that content needs to be restored or the ranking loss is expected and permanent.

Revenue Group's emergency migration recovery protocol can diagnose and resolve most traffic drops within 72 hours. The most common cause — accounting for 62% of migration-related traffic losses — is missing or incorrect redirects. The second most common cause (18%) is content changes on ranking pages. The third (12%) is technical errors like blocked crawling or canonical misconfiguration. The remaining 8% are domain-authority transfer delays that resolve naturally over 4 to 8 weeks. The faster you identify and fix the cause, the faster the recovery — Google responds to corrections within days, not weeks, when the fix is technically clean.