Website Redesign Without Losing SEO: A 15-Step Migration Checklist

Why do websites lose rankings after a redesign?

Because a redesign changes far more than the look. To a visitor, the new site has fresh colors and better photographs. To a search engine, it may be a different set of addresses, different words on each page, different internal links and a different speed. Google has spent years learning what your old pages were about. A careless launch asks it to start again.

The pattern is familiar to anyone who does this work. A company launches a handsome new site on a Friday. Two weeks later, calls and form enquiries from search are down by a large share, and nobody can say why. The cause is nearly always one of five things.

• URLs changed and nothing redirects. Old addresses in Google's index, in other sites' links and in customers' bookmarks now return a 404 error.
• Content was cut. A 900-word service page became a 60-word panel with a large image. The words that ranked are gone.
• Titles and headings were rewritten or lost. Templates shipped with default titles such as Home or Services.
• The staging block went live. A noindex tag or a robots.txt rule meant for the test site was copied to production.
• The site got slower. Heavy scripts, uncompressed video and layout shifts replaced a plain, quick page.

Is this a redesign, a migration or both?

It helps to name what you are changing, since each kind of change carries a different risk. Google's documentation separates site moves with URL changes from site moves without them, and the guidance for each is different.

A visual redesign on the same platform, with the same addresses and content, is low risk. A platform change, say from WordPress to Shopify or to a custom build, usually alters URL patterns whether you intend it or not. A restructure merges, splits or renames pages. A domain change moves everything to a new address. A hosting change keeps the URLs and moves the servers.

Many projects do three of these at once: new design, new platform and new structure. That is where trouble comes from, since if traffic falls you cannot tell which change caused it. Where the business allows, separate them. Move platform with the same URLs and content first, let it settle, then restructure. Google makes a similar point for large sites, suggesting a move one section at a time so problems are easier to spot.

Phase 1: What should you record before touching anything? (Steps 1 to 4)

You cannot protect what you have not measured. The first phase is an inventory, and it takes a day or two for a typical small business site.

Step 1: List every URL. Crawl the current site with a tool such as Screaming Frog, and combine that with the URLs in your XML sitemap, in Google Search Console's performance report and in your analytics. Google's own guidance suggests sitemaps, server logs and analytics as sources. The crawl alone will miss orphan pages that still receive traffic.

Step 2: Find the pages that matter. Export the last 12 to 16 months from Search Console: clicks, impressions and queries by page. Mark the pages that bring search visitors, the pages that bring leads or sales, and the pages other websites link to. On most sites a small group of pages earns most of the organic traffic. Those are the ones to guard most closely.

Step 3: Save what is on those pages. For each important page, record the title tag, meta description, H1, main headings, word count, structured data and internal links pointing to it. A full crawl export does most of this. Keep a complete backup of the old site as well, so that anything lost can be recovered.

Step 4: Take a benchmark. Note current rankings for your main queries, organic sessions and conversions by page, the count of indexed pages and your Core Web Vitals. After launch, this is the baseline that tells you whether a change is noise or a problem.

Phase 2: How do you plan URLs and redirects? (Steps 5 to 8)

This phase decides the outcome more than any other. It is spreadsheet work, and it is worth doing slowly.

Step 5: Keep URLs where you can. An address that does not change needs no redirect and carries no risk. Changing /services/roof-repair/ to /roofing/repair/ because it looks tidier is rarely worth it. Change URLs when the structure is truly wrong, not for taste.

Step 6: Build a redirect map. For every URL that will change or disappear, write the old address and the new one in two columns. Each old page should point to its closest equivalent: the old roof repair page to the new roof repair page. Google specifically warns against redirecting many old URLs to one irrelevant destination, such as the home page. A page with no successor can go to its parent category, or be allowed to return a 404 if it had no traffic and no links.

Step 7: Choose the right kind of redirect. Google's documentation is direct: use a permanent server-side redirect whenever possible. That means a 301 or 308 status. A permanent redirect tells Google to show the new address in results, while a temporary one (302) tells it to keep the old one. JavaScript redirects are described as a last resort. Avoid chains as well. Each old URL should reach its destination in a single hop, and Google advises keeping any chain to fewer than five, ideally no more than three.

Step 8: Plan the content, not only the layout. Give designers the list of important pages with their word counts and headings, and agree that this content will be kept or improved. A redesign is a fine time to rewrite weak pages. It is a poor time to delete strong ones. If two pages are being merged, the new page should cover both subjects.

• One row per old URL: old address, new address, redirect type, owner, tested yes or no.
• Map page to equivalent page, never everything to the home page.
• 301 or 308, server-side, one hop.
• Include old URLs from earlier redesigns that still redirect, and point them straight at the final address.

Phase 3: What should be checked on staging? (Steps 9 to 11)

A staging site is a private copy of the new website. It is where problems are cheap to fix.

Step 9: Keep staging out of search, properly. Password protection is the cleanest way. If you use a noindex tag, note Google's warning that noindex only works when the page is not blocked by robots.txt, since a blocked page cannot be read. Whatever method you use, write it on the launch checklist in capital letters, since removing it is the step most often forgotten.

Step 10: Crawl staging and compare. Run the same crawler over the new site and set the two exports side by side. Check that every important page exists, has a unique title and one H1, kept its main content, carries its structured data, has a self-referencing canonical tag and is linked from the navigation or from related pages. Check that images have alt text and that no page is orphaned.

Step 11: Test redirects and speed. Load the redirect map into the staging server and test every row automatically. Each old URL should return a 301 to the intended page, which should return 200. Then measure performance on a mid-range phone. Google's stated targets for good Core Web Vitals are a Largest Contentful Paint within 2.5 seconds, an Interaction to Next Paint under 200 milliseconds and a Cumulative Layout Shift under 0.1. Check accessibility at the same stage, using our ADA website compliance checklist.

Phase 4: What happens on launch day? (Steps 12 and 13)

Launch on a weekday morning, at a quiet time for your business, when the people who can fix things are at their desks. Avoid the eve of a holiday and your peak season.

Step 12: Run the launch list in order. Put the new site live with redirects active. Remove the staging block and confirm it is gone by viewing the page source and the live robots.txt file. Spot-check twenty old URLs by hand. Submit the new XML sitemap in Search Console. Use the URL Inspection tool on the home page and your top pages to confirm Google can fetch and index them. Confirm analytics, conversion tracking, forms, phone links and checkout all work, since a broken form is as costly as a lost ranking.

Step 13: Update what points at you. Internal links should go straight to the new addresses, not through redirects. Update the website link on your Google Business Profile, social profiles, email signatures, advertising campaigns and the main directories. For the handful of other websites that send you the most visitors, ask them to update their links, as Google's guidance suggests.

If you are changing hosting at the same time, Google suggests lowering the DNS time-to-live value about a week ahead so the switch spreads faster, and notes that a temporary drop in Googlebot's crawl rate right after launch is normal.

Phase 5: What should you watch after launch? (Steps 14 and 15)

Step 14: Monitor daily for two weeks, then weekly. In Search Console, watch the Pages report for a rise in not found (404) errors, pages excluded by noindex and redirect errors. Watch the performance report for the pages you marked as important. Check server logs or your 404 report for old addresses people are still requesting, and add redirects for any you missed. Every migration misses a few.

Some movement is normal. Google's documentation says to expect temporary fluctuation in ranking during a move, and that for a small to medium-sized site it can take a few weeks for most pages to be processed, with larger sites taking longer. A dip that recovers within that time is the system catching up. A page that vanishes entirely, or a drop confined to one section, points to a specific fault you can find.

Step 15: Keep the redirects. Google advises keeping redirects for at least a year, and suggests keeping them indefinitely for the sake of visitors who follow old links. Do not let them lapse when the old hosting account is closed or a plugin is removed. Put the redirect map in version control or a shared document, since the next redesign will need it.

A real example: how we moved pages on our own website

We can show this with our own site, since anyone can check it. Our location pages used to live in nested folders, with addresses such as /locations/india/maharashtra/pune/. Before that, the same pages sat under /india/. In 2026 we replaced many of them with flat addresses, so the Pune page became /digital-marketing-agency-in-pune/.

That left two generations of old URLs for each page. We did not keep a hand-written redirect file, since hand-written files drift out of date. A script runs before every build and regenerates the redirects from the list of replaced pages. For each one it writes a 301 from the /locations/ address and another from the older /india/ address, both pointing straight at the final URL. If an older manual rule points at a page that has since been replaced, the script re-points it at the replacement, so no old address takes two hops. At the time of writing that produces more than sixty redirects.

A second script audits the finished site after each build. It fails the build if any internal link points at a page that does not exist, if a page lacks a title or has more than one H1, or if the breadcrumb trail does not match the URL. The XML sitemap gives each page its own last-modified date, and that date changes only when the page itself does.

You can test it: request quaventotechnologies.com/locations/india/maharashtra/pune/ and you will receive a single 301 to the new address. The scale is small, but the method is the one in this checklist: map every old URL, redirect once, check automatically and keep the rules for good. It is also why we favor redirect rules generated from data over rules typed by hand.

What about Shopify, WordPress and other platform changes?

Platform moves deserve a note of their own, since the platform often dictates the URL pattern. Shopify, for example, places products under /products/ and collections under /collections/, and you cannot change that. A store moving to it from another system will see most of its addresses change, so the redirect map is not optional. Shopify has a built-in redirect manager that accepts a bulk upload.

WordPress is more flexible, and its permalink settings can often reproduce your old pattern exactly, which removes the need for most redirects. Check trailing slashes and letter case, since /About and /about/ may be treated as different addresses.

Sites built with JavaScript frameworks need one further check: that the main content and links are present in the HTML the server sends, not only after scripts run. Use the URL Inspection tool to view the rendered page as Google sees it. Our comparison of Next.js and WordPress covers the trade-offs, and AI crawlers, which often do not run scripts at all, make this matter more, as our AI search optimization guide explains.

The 15-step checklist in one place

Print this or paste it into your project plan. Give each step an owner and a date.

• 1. List every URL from a crawl, the sitemap, Search Console and analytics.
• 2. Mark the pages that bring search traffic, leads and inbound links.
• 3. Save titles, descriptions, headings, content and structured data. Back up the old site.
• 4. Record benchmark rankings, traffic, conversions, indexed pages and Core Web Vitals.
• 5. Keep existing URLs wherever possible.
• 6. Map every changed URL to its closest new equivalent.
• 7. Use server-side 301 or 308 redirects, one hop each.
• 8. Carry important content into the new design, and merge with care.
• 9. Keep staging out of search, and note how to undo it.
• 10. Crawl staging and compare with the old site page by page.
• 11. Test every redirect, plus speed and accessibility.
• 12. Launch on a quiet weekday, remove the block, submit the sitemap, inspect key URLs and test forms.
• 13. Update internal links, profiles, ads and your most valuable inbound links.
• 14. Watch Search Console and 404 logs daily for two weeks, then weekly.
• 15. Keep redirects for at least a year, preferably for good.

What should you ask a web agency before a redesign?

Whoever builds the new site, put these questions to them before signing. The answers will tell you whether search has been considered or will be discovered after launch.

Who is responsible for the redirect map, and when will I see it? Will existing URLs be kept where possible? How will the content of my top pages be carried over? How is the staging site blocked from search, and who removes the block? What do you check on launch day, and who is watching Search Console in the weeks after? What happens if organic traffic falls?

A team that does this routinely will have a written process and will show it to you. A team that says the new site will be better for SEO because it is modern has not answered the question. Our guides to hiring an offshore web development company and choosing a digital marketing agency list further checks.

We build and migrate websites for US businesses from Pune, India, working remotely, and the checklist above is the one we follow. If you are planning a redesign, send us your current site through the contact page and we will tell you, in writing, which pages we would protect first. Our web design for US businesses and SEO services for US businesses pages describe how we work.