Website Redesign SEO Checklist: How to Relaunch Without Losing Your Rankings

Most businesses lose search traffic for a boring reason. Not a penalty, not an algorithm update. A redesign. The new site looks better, the team is proud of it, and three weeks later someone notices the phone has gone quiet. The pages that used to rank were renamed, deleted, or quietly hidden from Google during the build, and nobody owned the handoff between the designers and whoever was supposed to think about search.

This is the checklist we run on every rebuild, split into before launch, launch day, and the first 30 days. None of it is exotic. It just has to be done, in order, by someone who will be around to check the results.

Before you touch anything: record what ranks today

You cannot protect what you have not measured. Before the first wireframe, export a snapshot of the current site from Search Console (Performance report, last 16 months, grouped by page) and from your analytics. You want a list of every URL that gets organic clicks, the queries it ranks for, and roughly how much traffic it brings.

Then crawl the live site and save the full list of URLs, titles, meta descriptions, H1s, canonical tags and structured data. This is your baseline. When something drops after launch, this file tells you what it looked like when it worked.

Decide what stays. Sort pages by organic traffic and by backlinks. Anything in the top tier keeps its content, its target query and ideally its URL. Pages with no traffic and no links are candidates to merge or retire, but retire them deliberately, with a redirect to the closest replacement, not by letting them 404.

Build the URL map and the 301 plan

If URLs will change at all (new structure, new CMS, trailing slashes, uppercase to lowercase), you need a complete old-to-new mapping before launch, not a best-effort list afterwards. Google's own site move documentation says to start from your sitemaps, server logs and analytics, then use the CMS to produce the full list, and to update internal links on the new site to point directly at the new URLs rather than relying on redirects.

Use server-side permanent redirects. Google recommends "HTTP permanent redirects if possible, such as 301 and 308", and says to keep them in place "for as long as possible, generally at least 1 year". Avoid chains. One hop from old to new is the goal. If a page is already redirecting from an earlier redesign, point the oldest URL straight at the newest one rather than stacking redirects.

A June 2026 update to that guide, covered by PPC Land, added a detail that trips up domain changes: both the old and new sites must be verified in Search Console before the move, including www and non-www variants, and if the domain is changing, the Change of Address tool should be submitted for every variant, "even if you're not actively using these variants". For a redesign on the same domain, you do not need Change of Address at all. You still need the redirects.

Carry over metadata and structured data on purpose

Templates generate titles, descriptions, headings and schema. If nobody tells the template what the old values were, the new site ships with "Home | Company Name" on every page and your carefully written titles are gone.

Go through the pages that matter and confirm the title tag, meta description and H1 either match the old version or are a deliberate improvement. Check canonical tags point to the page itself, not to the staging domain. Confirm the robots meta tag allows indexing on everything you want indexed.

Structured data deserves its own pass. If the old site had LocalBusiness, Organization, Product, FAQ or Article markup, the new one needs the same or better. Validate it with Google's Rich Results Test on staging and again on production.

This is where it helps that the people writing the templates are also responsible for search. When development and SEO sit with one team, "the canonical tag is wrong" is a five-minute fix, not a ticket that bounces between two vendors for a month.

Keep the staging site out of Google, then let the live site in

Staging environments leak into search results more often than you would think. A staging URL gets shared, something links to it, and suddenly Google indexes a duplicate of your entire site at staging.yourdomain.com.

Put a noindex tag on staging, or better, protect it with HTTP authentication so Google never sees it. Then, and this is the half people forget, make sure that noindex does not ship to production. We have seen relaunches where the whole site was invisible for a week because one environment variable kept the staging robots rule alive. Check the live homepage source and robots.txt within minutes of going live.

Hit Core Web Vitals before launch, not after

A redesign is your best chance to fix performance, and also the easiest way to make it worse. New fonts, hero videos, animation libraries and untested third-party scripts all add up.

Google's guidance in Search Central is specific: aim for Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1, measured at the 75th percentile of real visits. Google recommends that "site owners achieve good Core Web Vitals for success with Search", and the Core Web Vitals report in Search Console is where you will see how the new site is actually doing once it has traffic.

Test the key templates on staging with PageSpeed Insights on a throttled mobile connection. Fix image sizing, set explicit dimensions on images and embeds so the layout does not jump, and defer every script not needed for the first paint. It is far cheaper to do this before the design is signed off than to argue about removing a hero animation later.

Launch day: the 60-minute checklist

Launch during a quieter period if you can. Google's site move guidance suggests picking a time when traffic is naturally lower so that any hiccup affects fewer people.

Within the first hour after go-live, work through these in order. Confirm the production site returns 200 on the homepage and key pages, and that the noindex and robots.txt blocks are gone. Spot-check twenty redirects from your mapping, including a few deep pages and a few with query strings. Verify the canonical tags point to the live domain. Submit the new XML sitemap in Search Console (Google notes this "will help Google learn about the new URLs"), and request indexing on your five most important pages. Confirm analytics and tag manager are firing on the live domain and that form submissions still land in the inbox or CRM. Finally, re-crawl the site and compare against your pre-launch baseline for missing titles, broken internal links, and pages that became 404s.

If anything is wrong, fix it the same day. Google re-crawls important pages frequently, and the window where mistakes are cheap is short.

The first 30 days: watch, do not panic, but do act

Some movement is normal. Google has to re-crawl old URLs, follow the redirects, re-index the new ones and recompute signals. The documentation describes the healthy pattern plainly: traffic on the old URLs should go down while traffic on the new ones goes up. A short dip of a week or two is common even on a clean migration.

What is not normal is a sustained drop, or clicks disappearing from specific pages. So check these on a schedule. Daily for the first week: Search Console's Pages report for new "Not found (404)" and "Redirect error" entries, and the Performance report filtered to your top 20 pages. Weekly after that: the Core Web Vitals report once it has 28 days of data, the Sitemaps report to confirm discovered versus indexed counts are climbing, and a crawl of the live site for new redirect chains or orphaned pages.

When a top page loses clicks, the cause is almost always one of four things: the redirect goes to the wrong destination, the new page dropped the content or headings that earned the ranking, the page is noindexed or canonicalised elsewhere, or internal links to it vanished when the navigation was redesigned. Each is fixable in an afternoon if someone is watching.

Keep the redirects live for at least a year, as Google advises. Do not let a hosting change or a future tidy-up remove them.

Why this usually goes wrong, and how to avoid it

A redesign fails on SEO when it is treated as a design project with a technical afterthought. The fix is structural, not heroic: the same people who write the templates and configure the hosting should own the redirect map, the metadata, the performance budget and the 30-day monitoring. That is how the studio works, and it is why we push clients toward an ongoing SEO relationship rather than a one-off audit. An audit tells you what broke. A partner stops it breaking.

If you are also weighing whether the rebuild should be a template site or something custom, our breakdown of custom web app costs in 2026 covers what drives the price and when custom is worth it.

Next step

If you are planning a redesign, or you just launched one and the numbers look off, we will look at your Search Console data and your URL plan and send you a written recommendation. No charge, no obligation. Book a free call and bring your current sitemap.