Website redesign SEO checklist: how to migrate without losing rankings

A website redesign SEO checklist exists for one reason: a new design, platform or domain changes the URLs, content and code your rankings were built on, and every unplanned change is a chance to lose traffic. You can redesign a website without losing SEO if you benchmark what ranks today, map every old URL to its new home with a 301 redirect, keep the content that earns traffic, and keep staging out of Google until launch. This guide covers that process in six phases, with the checks I run and the mistakes behind most post-launch drops.

Quick answer. Before launch: crawl the old site, export Search Console data, list every URL with traffic or backlinks, and map each one to a new URL. On launch day: switch on server-side 301 redirects, remove staging noindex rules, submit the new sitemap and test every redirect. After launch: check Search Console indexing, 404s and queries daily for two weeks, then weekly for three months. Keep redirects for at least a year.

Does changing your website affect SEO?

Yes, almost always, and the size of the effect depends on what changes. A visual refresh on the same URLs, with the same text and similar HTML, is low risk. Risk rises sharply when you change URLs, remove or merge pages, rewrite copy, switch CMS, change domain, or move from server-rendered HTML to a JavaScript framework. Google's site move documentation (opens in a new tab) says to expect temporary ranking fluctuation even on a well-run move, and that a medium-sized site can take a few weeks or more for new URLs to replace the old ones.

Google has spent months or years learning what each URL is about. A redesign asks it to relearn that, and your job is to make the relearning trivial.

How to redesign a website without losing SEO

To redesign a website without losing SEO, keep three things stable that Google relies on: the URLs (or a 301 redirect from every old URL to its closest new page), the content that each ranking page carries, and HTML that crawlers can read without running JavaScript. The design itself can change freely. The phases below are how I make sure those three hold, from benchmarking before the work starts to monitoring for 90 days after launch.

Why redesigns lose traffic

Most drops after a relaunch come from a short list of causes, usually because design, development and SEO were handled by people who never compared notes.

Phase 1: benchmark before you touch anything

You cannot tell whether a migration worked without a "before" picture, and once the old site is gone you cannot crawl it again.

Save everything in one dated folder. The Search Console interface exports at most 1,000 rows, so for larger sites pull the data through the Search Console API.

Phase 2: URL mapping and the 301 redirect plan

The URL map is the core of any SEO migration plan: a spreadsheet with one row per old URL and a decision on every row.

Rules for filling it in:

1. Keep URLs unchanged wherever you can. The safest redirect is the one you never need.
2. Redirect one to one, to the closest match. Google advises against redirecting many old URLs to one irrelevant page such as the homepage.
3. Remove deliberately. A page with no traffic, no links and no replacement can return 404 or 410. Google treats both the same way.
4. No chains. If /a already redirects to /b from an older redesign, point /a straight at the new URL.
5. Cover every variant and file. HTTP and HTTPS, www and non-www, trailing slashes, index.php paths, query-string URLs like ?page_id=42, plus PDFs and images that have links or image traffic.

Redirect on the server, not in JavaScript. On Apache:

# .htaccess in the site root
RewriteEngine On
RewriteRule ^services/web-design\.html$ /services/website-design/ [R=301,L]
RewriteRule ^news/(.*)$ /blog/$1 [R=301,L]

On Nginx, a map (in the http context) keeps hundreds of redirects readable:

map $uri $redirect_to {
    /services/web-design.html   /services/website-design/;
    /about-us.php               /about/;
}

server {
    # ...
    if ($redirect_to) {
        return 301 $redirect_to;
    }
}

In Laravel, Route::permanentRedirect('/about-us.php', '/about'); returns a 301 and is fine for a handful of URLs. For hundreds, I keep the map in a database table and check it in middleware before the 404 response.

Then test the whole list. This script reads a two-column CSV (old URL, expected new URL, both absolute, no header row) and prints only failures:

#!/usr/bin/env bash
while IFS=, read -r old new; do
  new=${new%$'\r'}   # strip Windows line endings from Excel exports
  read -r code target <<< "$(curl -s -o /dev/null -w '%{http_code} %{redirect_url}' "$old")"
  read -r final hops <<< "$(curl -s -o /dev/null -L -w '%{http_code} %{num_redirects}' "$old")"
  if [ "$code" != "301" ] || [ "$target" != "$new" ] || [ "$final" != "200" ] || [ "$hops" != "1" ]; then
    echo "FAIL $old -> $code $target (final $final after $hops hops, expected $new)"
  fi
done < redirects.csv

Phase 3: content and on-page parity

Rankings belong to content, not URLs. If the new page says less, it usually ranks for less. For each page on your top traffic list, compare old and new:

• Body copy. Same topics, same depth. "Cleaner" designs often cut the paragraphs that answered long-tail queries. Check rewritten copy against the queries from your Phase 1 export.
• Titles and meta descriptions. Carry them over unless there is a reason to change them. Changing titles and URLs at the same moment makes a drop impossible to diagnose.
• H1 and headings. New templates often turn the H1 into a logo or slider caption.
• Internal links. Menus, footers and related-post blocks change in redesigns. A page that loses most of its internal links loses visibility.
• Structured data. Organization, LocalBusiness, Product, Article and BreadcrumbList markup must be rebuilt in the new templates and validated with the Rich Results Test (opens in a new tab).
• Canonicals and hreflang. Every one must point at the new final URL, never at the old domain or at staging.

My on-page SEO checklist covers what each of these elements should contain.

Phase 4: staging QA and the noindex pitfalls

Staging creates two opposite failures: staging gets indexed before launch, or staging's "do not index" settings travel to production.

Protect staging with HTTP authentication, not robots.txt. Disallow: / stops crawling, not indexing, so a linked staging URL can still appear in results. A password stops both. If you also want a noindex, send it as a header so it never lives in the template code:

server {
    server_name staging.example.com;
    auth_basic           "Staging";
    auth_basic_user_file /etc/nginx/.htpasswd;
    add_header X-Robots-Tag "noindex, nofollow" always;
}

Google's noindex documentation (opens in a new tab) is explicit that a noindex only works if the page is not blocked by robots.txt, because a blocked page is never fetched.

Phase 5: launch-day checklist

Launch early in the week at a low-traffic time, with the developer available for the rest of the day.

Domain moves: Search Console Change of Address

If the domain changes (say oldbrand.com to newbrand.com), verify both domains in Search Console under the same Google account, put the 301s live, then run the Change of Address tool (opens in a new tab) from the old property. It checks that the old homepage redirects to the new one and shows a move notice for 180 days.

• It is only for domain or subdomain changes, not HTTP to HTTPS, www to non-www, or path changes. Google picks those up from redirects.
• It does not cover subdomains automatically. Submit each variant of the old domain, including www.
• Bing Webmaster Tools has its own Site Move tool. Add the new site there too.
• Google's Change of Address help asks for redirects for at least 180 days and the old domain kept for at least a year, and the site move guide says at least a year for redirects. I keep them permanently: the cost is a domain renewal, and old backlinks never stop arriving.

Change one thing at a time where you can. A new domain, CMS and URL structure in one release is three migrations stacked together, and if traffic drops you will not know which one caused it.

Phase 6: monitoring the first 90 days

Googlebot crawls a moved site more heavily for a while, so make sure the server can take it. Then check on a schedule:

If you keep the old sitemap submitted for a few weeks, its indexed count should fall towards zero as the new one rises: a simple visual check that the move is being processed.

Platform-specific notes

WordPress to a custom build. WordPress creates URLs you may not know you had: category and tag archives, author pages, /page/2/ pagination, attachment pages and ?p=123 links. Pull them from the database and sitemap, not just a crawl. SEO plugins also produced schema and Open Graph tags the new build must replace.

CodeIgniter to Laravel. Older CodeIgniter apps often have index.php in URLs (/index.php/products/view/12) and numeric IDs. If the Laravel version uses clean slugs, every ID needs a lookup redirect. The CodeIgniter 3 to 4 migration guide covers the code side, and URL handling is a large part of any CodeIgniter to Laravel migration.

HTTP to HTTPS. Redirect every HTTP URL to its HTTPS version in one hop and update canonicals and internal links. No Change of Address is needed.

If traffic drops after launch: a recovery plan

A dip in the first weeks is normal. A cliff in the first days, or a steady decline after a month, is not. Check in this order:

1. Indexing blocks. "Excluded by noindex" and "Blocked by robots.txt" in the Page indexing report. Fast to fix, and the most common cause of a cliff. Pages that land in "Crawled, currently not indexed" instead need the fixes in my crawled, currently not indexed guide.
2. Redirect failures. Export 404s from Search Console and logs, map them, add redirects.
3. Where clicks were lost. Compare the Performance report by page. Losses concentrated on a few pages point to content or redirects on those pages. Losses spread evenly point to rendering, internal linking or speed.
4. Content gaps. Compare old and new copy on the biggest losers (the Wayback Machine helps if you saved nothing) and restore what was cut.

Recovery usually follows as Google recrawls the fixed pages, but no one can promise a timeline or a full return. That is why the planning is cheaper than the fix.

The complete website redesign SEO checklist

A summary to share with your team. It works as a website migration checklist for replatforms and domain moves too:

Launching a brand-new site with no history to protect? Use the website launch SEO checklist instead.

Frequently asked questions

Will redesigning my website hurt my SEO?

It does not have to. A redesign hurts SEO when URLs change without redirects, content is removed, or indexing settings are wrong at launch. Keep URLs where possible, redirect the rest one to one, and preserve the content that ranks, and most sites see only a short fluctuation.

How long does it take to recover rankings after a website migration?

Google says a small or medium site can take a few weeks or more for new URLs to fully replace old ones, and large sites longer. If something went wrong, recovery only starts once the cause is fixed and the pages are recrawled.

How long should I keep 301 redirects after a redesign?

At least a year, per Google's site move guidance, and ideally permanently. Backlinks, bookmarks and old emails keep sending people to old URLs for years, and a redirect rule costs almost nothing to keep.

Is a website migration SEO checklist different from a redesign checklist?

Not much. A redesign changes design, templates and often content, while a migration changes platform, URLs, domain or protocol. Most redesigns include some migration, so the same phases apply.

A migration is one of the few SEO projects where the developer and the SEO really should be the same person. If you want this website redesign SEO checklist handled end to end, from URL map to launch checks, that is what my SEO website migration service covers, and a technical SEO audit is the place to start if the new site is already live.