Website redesign SEO checklist

Short answer. Before design starts, record what ranks and why: a full crawl, Search Console exports, your top pages and the links pointing at them. Keep every URL you can; map a redirect for every one you cannot. Keep the content and headings of ranking pages, build on a password-protected staging site, set a speed budget, and run a fixed launch-day list before and after you switch. Then watch Search Console weekly for 90 days. Details and sources below.

Redesign or migration? Use the right checklist

People use "redesign" and "migration" interchangeably. They are different jobs with different risks, and the second has its own guide.

If your project changes the domain, the platform or the URL structure on purpose, read the migration checklist first and use this one for the design and content half. If it changes none of those, this guide is enough.

Why redesigns lose traffic

In our experience the losses come from a short list of causes, none of them exotic:

• URLs change without anyone deciding they should: a new CMS adds or removes trailing slashes, a designer renames "treatments" to "services", or a blog moves from /blog/ to /news/.
• Content is cut. The brief says "cleaner, fewer words", and the 600-word page that ranked for "EICR certificate Croydon" becomes a 60-word card.
• Pages are merged into tabs or accordions on one URL, so six ranking pages become one.
• The staging site’s noindex tag or robots block ships to production.
• The new theme is heavier: a hero video, three font families and an untested slider push Core Web Vitals out of the "good" range.
• Internal links in the old navigation and footer disappear, so deep pages lose the paths Google used to reach them.
• Image file names and alt text are reset to defaults.
• Structured data from the old theme is not rebuilt on the new one (see the schema markup guide).

Every one of these is preventable with a baseline and a parity rule, which is what the rest of this checklist is.

Phase 1: the baseline, before anyone opens a design tool

You cannot protect what you have not measured. Collect the following and keep it somewhere the designer, the developer and you can all see.

1. A full crawl of the live site: every URL, its status code, title, H1, canonical, word count, inbound internal links and indexability. Export it.
2. Search Console exports from the Performance report: pages and queries, for the longest range the report allows, so you can see seasonality and not just last month.
3. A ranked list of your top pages by clicks and by conversions (from analytics), with the five searches that matter most to the business written at the top.
4. The Links report in Search Console, so you know which pages other sites link to. Those URLs must survive or be redirected.
5. Core Web Vitals field data for your key templates. The thresholds Google uses are LCP within 2.5 seconds, INP of 200 milliseconds or less and CLS of 0.1 or less, measured at the 75th percentile of page loads across mobile and desktop.
6. A copy of your current structured data output, your XML sitemap and your robots.txt.
7. Screenshots of the key pages, because you will be surprised how quickly nobody remembers what was there.

This baseline is also the evidence you will need if traffic dips after launch. Without it the conversation becomes a guess about whether the dip is the redesign, the season or Google.

Get your free SEO auditPlanning a redesign? The free SEO audit gives you a baseline from a person, with the three things the new site must keep, within two working days.

Phase 2: URL and content parity plan

The rule for URLs is simple: keep them. A URL that has ranked for five years carries history you cannot rebuild in a sprint. If a URL has to change, it goes on a redirect map, old URL to new URL, one to one, before build starts. Google’s guidance for moves with URL changes is to use server-side permanent redirects (301 or 308), pointed directly at the final destination so there are no chains. Google treats JavaScript redirects as a last resort because rendering can fail and the redirect may never be seen.

The rule for content is parity of intent. The new page must still answer the search the old page answered. Word count is not sacred; the topic, the H1, the supporting sections and the internal links are. Work through the top pages from your baseline and classify every element:

A Mayfair law firm we will keep anonymous moved eight practice-area pages into tabs on a single "Expertise" page during a rebrand. Eight ranking URLs became one, and the one answered none of the eight searches well. The fix was to restore eight pages under the new design, which is the fix for most tab-and-accordion redesigns: the design can group things visually while each still has its own URL.

Phase 3: build on staging without leaking or regressing

Staging must be invisible to Google and identical in behaviour to production. Those two aims conflict if you rely on robots.txt alone, because a URL blocked in robots.txt can still be indexed if Google finds a link to it. Google’s guidance for keeping a page out of results is a noindex rule that the crawler is allowed to read, not a robots.txt block. The simplest answer is password protection on the whole staging host, with no exceptions for "just the demo link".

Then test what the design has done to performance. Set a budget per template against the Core Web Vitals thresholds above and measure in the lab before launch and in the field after. Google’s page experience guidance is to aim for good Core Web Vitals and a page that works on mobile, which is how Google predominantly crawls and indexes under mobile-first indexing. A theme that looks superb on a 27-inch monitor and loads a 4MB hero video on a bus in Lewisham has failed the test that counts.

If the new design relies on JavaScript to render content, check that the rendered HTML Google sees contains the text and links. Google’s JavaScript SEO basics explain how rendering works and why server-side or static rendering is safer for content that must be indexed.

• Staging behind authentication, not just robots.txt.
• Redirect map loaded and tested on staging with a script, not by clicking.
• Canonicals point to the production domain, not the staging one, at launch (a common leftover).
• Structured data rebuilt and validated (see the schema guide).
• Core Web Vitals within budget on the home, service and article templates on a throttled mobile profile.
• All forms, tracking and consent tools tested; a redesign is the most common moment analytics silently stops.
• If hosting changes, lower the DNS TTL in advance, as Google’s guidance for moves without URL changes recommends, so the switch propagates faster.

Launch day: the sixty-minute list

Launch on a Tuesday or Wednesday morning, never a Friday, so the people who can fix things are around for the two days after. Run this list in order, and then run it again an hour later.

1. Remove the noindex rule and any staging robots.txt. Load the live robots.txt in a browser and read it.
2. Check the home page and ten key pages for a self-referencing canonical to the live domain.
3. Request a crawl of the redirect map: every old URL returns a single 301 or 308 to the right new URL, no chains, no loops.
4. Regenerate the XML sitemap with the new URLs only, submit it in Search Console, and check it returns 200. Google’s sitemap guidance explains what the file is for and how to submit it.
5. Use URL Inspection in Search Console on the top twenty pages from your baseline; confirm each is indexable and that the rendered page shows the content.
6. Load the top twenty pages on a phone, including forms and the booking or enquiry flow.
7. Confirm analytics and conversion tracking fire on a test enquiry.
8. Check the structured data on three templates in the Rich Results Test.
9. Run a fresh full crawl and compare it with the baseline: titles, H1s, word counts, internal link counts, status codes.
10. Write down the launch time. Every chart you read for the next 90 days will be annotated with it.

Ninety days of monitoring

Google’s own timing guidance for site moves is that for a medium-sized site it can take a few weeks or more for new URLs to be shown, and longer for larger sites. A redesign that kept its URLs should settle faster, but the same discipline applies.

Two signals from Google’s documentation help you read the charts. First, 5xx and 429 errors make Google’s crawlers slow down, and pages that keep failing are eventually dropped from the index, so a server struggling under the new theme shows up in rankings later. Second, a page that returns 200 but looks like an error or is empty is reported as a soft 404; redesigns that replace content with a "coming soon" placeholder hit this constantly.

Three London redesigns and what they teach

The Islington restaurant

The new site put the menu in a PDF behind a button. The old HTML menu pages had ranked for dish-level searches. Lesson: anything that ranks stays as crawlable HTML, however the designer wants it to look.

The Wimbledon physiotherapy clinic

A beautiful new theme shipped with a layout shift on every page as web fonts loaded late. Field CLS went past 0.1 and the mobile booking button jumped under thumbs. Lesson: a speed budget per template, tested on a throttled phone profile before launch.

The Canary Wharf recruitment firm

Staging was blocked in robots.txt only. A client shared the staging link on LinkedIn, Google indexed thirty staging URLs, and the launch created duplicates. Lesson: password protection, and canonical tags that point to production.

Who does what

A redesign has three parties and the SEO work falls between them unless someone owns it. Our website design service builds with this checklist inside the process, and our technical SEO service can sit alongside another studio’s design work as the person holding the baseline. If you are doing it yourself, the baseline and the launch list above are the two things not to skip. Not ready to talk? Score your own site in five minutes before and after the redesign and compare.