Website Redesign SEO: How to Relaunch Without Losing Rankings

Why Redesigns Lose Rankings

A redesign changes more than the look of a site. New templates change the HTML search engines read, a new information architecture changes URLs and internal links, and a content pass changes what each page is about. Search engines reassess pages when those signals change, so some movement is normal even when the migration is handled well. Google’s site-move guide tells site owners to “expect temporary fluctuation in site ranking during the move”.

Losses that last are a different matter. They almost always come from one of a short list of causes:

• Old URLs removed without redirects. The links, bookmarks and search history attached to them now lead to 404 pages.
• Redirects to the wrong place. Sending many old URLs to the home page or another loosely related page confuses visitors and, in Google’s words, “might be treated as a soft 404 error”.
• Content cut for the new layout. Service details, pricing notes, answers to common questions and location information that the old pages ranked for, removed to make the new design cleaner.
• Weaker internal linking. A simplified navigation or footer that no longer links to pages that used to be one click from the home page.
• Staging settings shipped to production. A noindex rule, a robots.txt disallow, or canonical tags that still point at the staging host.

Every item on that list can be caught before launch. The rest of this guide is the order in which to look for them.

Define What the Redesign Changes

Start by writing down which layers of the site the project changes, because the risk rises with each one. A visual refresh on the same URLs and copy is a low-risk project. A new domain, a new CMS and a new URL structure launched on the same day is several migrations at once.

Google’s own advice is to separate these changes. Its site-move guide has a section headed “Change only one thing at a time”, which says that if you want to “move your site to a new domain name, change your content management system (CMS), and update your site to use a new layout, do them one at a time”. When everything changes on the same day and traffic drops, there is no clean way to tell which change caused it.

That is not always possible: clients often want the new brand, platform and design together. When it is not possible, the benchmark and the redirect map below matter more, not less.

Benchmark the Current Site

Record the current state of the site before anything changes. After launch, the benchmark is the only way to tell normal fluctuation from a real loss, and the old site will not be there to crawl again.

1. Crawl the live site and save every URL with its status code, title, meta description, main heading, canonical and word count.
2. Export Search Console performance data by page and by query. The Performance report only reaches back 16 months, so keep a copy outside the tool.
3. Export organic landing pages from analytics, with sessions and conversions for at least the last twelve months.
4. List the URLs other sites link to, from Search Console’s Links report or a backlink tool. Every one of these needs a redirect, whatever else changes.
5. Record the indexing baseline: the indexed page count in the Page indexing report and the Core Web Vitals status of each template.
6. Save the rendered HTML and structured data of each template so the new templates can be compared against them.

From this data, mark the pages that carry the site’s search traffic: those with meaningful organic clicks, conversions or external links. On most small-business sites that is a short list, and it is where most of the remaining migration effort should go.

Build the Redirect Map

The redirect map is a spreadsheet with one row for each old URL and a column for its new destination. In a redesign that changes URLs, it is the most important SEO deliverable in the project. Google’s guidance is direct: “It’s important to map your old site’s URLs to the URLs for the new site.”

• Map every known URL, not only the pages in the current navigation: the full crawl, the sitemap, the analytics export and the list of linked URLs. Old campaign landing pages and PDFs often carry external links.
• Redirect to the closest equivalent. Where content was merged, redirect the old pages to the page that now holds it. Where a page is retired with no replacement, return a 404 or 410 instead of redirecting it to the home page.
• Use server-side permanent redirects (301 or 308). Google uses a permanent redirect as a signal that the target should be canonical, and “301 and other permanent redirects don’t cause a loss in PageRank”. Temporary redirects (302 and 307) are followed, but not used as that signal.
• Redirect straight to the final URL. Where a chain cannot be avoided, Google advises keeping it “ideally no more than 3 and fewer than 5” hops long.
• Keep the redirects in place. Google recommends keeping them “for as long as possible, generally at least 1 year”, and suggests keeping them indefinitely for visitors who follow old links.

Then update the site itself to use the new URLs directly: internal links, canonical tags (each new page should carry a self-referencing canonical), hreflang annotations and XML sitemaps. Redirects exist for external links and bookmarks. The site’s own navigation should never depend on them.

Carry Over On-Page Signals

For each page on the priority list, compare the old and new versions before launch.

• Titles and meta descriptions. Keep the ones that perform. Rewrite them deliberately, not as a side effect of a new template default.
• Headings and body content. The topics, questions and details the page ranked for should still be on the page, even if the layout presents them differently.
• Internal links. Priority pages should receive at least as many internal links from the navigation, footer and body copy as they did before.
• Structured data. The same schema types as before, updated to the new URLs and validated on the new templates.
• Images. Alt text carried over, and files sized for the new layout rather than uploaded at full resolution.

A redesign is also a sensible time to fix what the benchmark showed was already broken: thin pages, duplicate titles, missing structured data. Log those changes separately. When you read the post-launch data, you will want to know which movements came from improvements and which came from the migration.

Protect and Test the Staging Site

The new site needs to stay out of search results while it is built, then become fully indexable the moment it launches. Google’s documentation states that robots.txt “is not a mechanism for keeping a web page out of Google”; for that, it points to a noindex rule or password protection. For a staging site holding unreleased client content, password protection is the safer choice, because it keeps out people as well as crawlers.

Whichever method you use, control it through environment configuration rather than hard-coding it into templates. A noindex written into a template is the one most likely to reach production. Before launch, crawl the staging site with authentication and confirm that:

• every old URL in the redirect map returns a single 301 to its intended new URL, and that URL returns 200;
• canonicals, hreflang, sitemap entries and structured data reference the production domain, not the staging host;
• each priority page’s title, headings and content match the comparison from the previous step;
• the key templates (home, service and location pages) perform acceptably in lab tests on a mobile profile.

Launch-Day Checklist

Google’s list of common migration mistakes opens with the one this checklist is built around: “Don’t forget to remove any noindex or robots.txt blocks that were only needed for the migration.”

Monitor the Weeks After Launch

Check the new site daily for the first week and weekly for the two months after that, comparing it against the benchmark.

• Page indexing report. New URLs moving into the index, and old URLs listed as “Page with redirect”. A rise in “Not found (404)” means the map missed some URLs; add redirects as they appear.
• Crawl stats and server logs. Googlebot requesting old URLs and receiving 301s, with no spike in server errors. Google says it “will crawl your new site more heavily than usual” after a migration, so the hosting needs headroom.
• Performance report. Clicks and impressions for the priority pages, compared page by page with the benchmark over equal date ranges, allowing for seasonality.
• Rankings for the queries each priority page held before launch.

Old URLs may also keep appearing in results for a while after the new ones are indexed, which Google describes as normal. A decline that is still deepening after several weeks, or one concentrated on particular pages, usually has a specific cause: a missing redirect, removed content, a lost internal link. The benchmark comparison is how you find it.

Scope SEO Into the Redesign Proposal

For an agency, migration work is easiest to protect when it is written into the proposal: a line item for the benchmark and the redirect map, a named owner for each step, and client sign-off on which URLs and content are changing. It also sets expectations. A client who was told in writing that rankings can fluctuate for several weeks reads a dip as part of the plan, not as a problem with the work.

A few weeks after launch, run a full technical SEO audit on the new site to catch what the launch checks missed, and review the new templates against Core Web Vitals once real-user data has accumulated.