Website redesign checklist: keep your SEO and traffic

A website redesign checklist that protects your SEO has five jobs: record today’s traffic, list every URL, 301 redirect each changed URL to its closest new page, keep the staging site out of Google, and watch Google Search Console closely after launch. Get those right and any dip in traffic should be small and short.

Why does a website redesign lose traffic?

A website redesign loses traffic when search engines can’t connect old pages to new ones, or when pages that ranked lose the content, links or speed that made them rank. The new look is rarely the cause. The changes underneath it are.

The usual culprits:

• URLs change with no redirects. Links and bookmarks hit a 404, the “page not found” response a server sends when an address doesn’t exist.
• Pages that brought in traffic get cut in a content clean-up, because nobody checked the numbers first.
• Navigation shrinks, so pages that used to sit one click from the home page now have few internal links.
• A staging block goes live. A noindex tag or robots.txt rule meant for the test site ends up on the real one.
• Titles and copy get rewritten for style, and a page stops matching the searches it used to answer.
• New templates load slower or jump around while they load.

Say a 20-person law firm in Manchester (a hypothetical example) moves its family law page from /services/family-law.html to /family-law/ and forgets the redirect. Every directory listing and press mention now points at a 404. Google eventually drops the old URL, and the new one has to earn its place again.

What should you benchmark before a website redesign?

Benchmark every number you’ll judge the new site against: organic clicks and impressions by page, top search queries, conversions by landing page, Core Web Vitals and the pages other sites link to. Export them before work starts, because you can’t rebuild a baseline after launch.

Export these into one spreadsheet:

• Search Console Performance report: clicks, impressions, click-through rate and average position for the last 12 months, by page and by query.
• Analytics: sessions and conversions (form fills, calls, sales) by landing page.
• Core Web Vitals: the Search Console report plus PageSpeed Insights results for your main page templates.
• Links: the top linked pages from Search Console’s Links report.
• Rankings: positions for the 20 to 50 search terms that bring in customers.

Build a crawl and URL inventory

A URL inventory is a spreadsheet of every address on the current site, including PDFs and images that earn traffic or links. Google’s site-move guide suggests building it from your sitemaps, server logs, analytics, Search Console and a CMS export, since no single source catches everything.

Run a crawler such as Screaming Frog SEO Spider or Sitebulb over the live site, then merge in the other lists. Give each URL a row with its status code, title, organic clicks, linking sites and a decision: keep, merge or remove. That column becomes your redirect map.

If you’d like a second pair of eyes on the inventory or redirect plan before you commit, tell us what you’re redesigning.

How do you build a 301 redirect map?

A 301 redirect map is a two-column list pairing every old URL with its closest new URL, which your developer turns into permanent server-side redirects. Google recommends permanent redirects (301 or 308) that go straight to the final page and stay in place for at least a year.

A 301 redirect tells browsers and search engines that a page has moved for good, so ranking signals pass to the new address. Google treats 302, 303 and 307 as temporary, so the old URL usually stays in results. Here’s what a few rows look like:

Follow these rules when you fill it in:

1. Match one to one. Send each old URL to the page that answers the same question.
2. Skip the home page shortcut. Google advises against redirecting many pages to an irrelevant URL such as the home page.
3. Avoid chains. Point old URLs straight at the final page. Google suggests keeping any chain under 5 hops, ideally 3 or fewer.
4. Let dead pages die properly. Return a 404 or 410 for content you’ve removed with no replacement.
5. Fix internal links too. Update links inside the site to the new URLs instead of relying on redirects.
6. Keep redirects for a year or more. Google says to keep them as long as possible, “generally at least 1 year”.

Test the whole map on staging before launch by feeding the old URL list to your crawler in list mode. Every row should return a single 301 to the right page.

How do you migrate content without losing rankings?

Move ranking pages across with their substance intact: the same topic, title tag, main heading, body copy, internal links and structured data. Improve them after launch in small batches, so you can see what each change does.

Write these rules into the redesign brief:

• Keep what ranks. Don’t cut a 1,200-word service page to 300 words because the new layout looks cleaner.
• Carry the hidden parts over. Title tags, meta descriptions, image alt text, structured data and a self-referencing canonical tag (the tag that names a page’s preferred URL) all move with the page.
• Rebuild internal links. If a page drops out of the main menu, link to it from a hub page or related content.
• Change one big thing at a time. Switching domain, host and design in the same week makes any drop impossible to diagnose.

Sites that serve more than one country need one extra step. hreflang is a tag that tells Google which country or language version of a page to show to which searchers. If you run separate UK, Australian and Indian versions, Google’s guide says to update those annotations to the new URLs, or searchers in Sydney may land on the UK page.

A redesign is also the cheapest moment to fix accessibility and structure. Building to WCAG 2.2 AA now costs less than retrofitting later (our website accessibility requirements guide covers the rules by country). Clear, self-contained sections also make your pages easier for AI tools to quote, which our guide to getting cited in AI search explains.

How should you handle staging and launch day?

Keep the staging site behind a password so search engines can’t crawl it, then remove the password and every noindex rule at launch and work through a fixed list of checks. A leftover block or a missing redirect file can cost you rankings until someone spots it.

Keep the staging site out of Google

A staging site is a private copy of the new website where you build and test before launch. Google’s guidance for private content is to password-protect it, and that’s the safest option for staging too.

Add a noindex rule as a backup, either as a robots meta tag or an X-Robots-Tag HTTP header. Don’t block staging in robots.txt as well: Google can only obey a noindex tag on a page it’s allowed to crawl. On its own, robots.txt doesn’t keep a page out of search results. Google notes that a blocked page can still appear if other pages link to it.

Launch-day checks

• Remove the staging password and every noindex tag, then check the live robots.txt file.
• Deploy the redirects and test your top 50 old URLs by traffic.
• Confirm canonical tags point at the live domain, not the staging address.
• Submit the new XML sitemap in Search Console and keep the old one, so you can watch old URLs drop out.
• Check that analytics, conversion tracking and every form work.
• Make sure every page loads over HTTPS with no mixed-content warnings.
• If the domain changed, use Search Console’s Change of Address tool; Google says it’s only needed for domain or subdomain moves.

What Core Web Vitals should the redesigned site hit?

A redesigned site should meet Google’s “good” thresholds for all three Core Web Vitals: Largest Contentful Paint of 2.5 seconds or less, Interaction to Next Paint of 200 milliseconds or less and Cumulative Layout Shift of 0.1 or less. Google measures them at the 75th percentile of real page loads, on mobile and desktop separately.

Thresholds are from web.dev, checked on 6 November 2026. INP replaced First Input Delay (FID) as a Core Web Vital on 12 March 2024, so a checklist that still mentions FID is out of date.

Google says it highly recommends good Core Web Vitals for success with Search. Redesigns tend to hurt them in predictable ways: a large hero video slows LCP, chat widgets and sliders slow INP, and late-loading fonts or cookie banners push content around (CLS). Test your main templates with Lighthouse in Chrome DevTools on staging, because field data in Search Console only arrives after real visitors use the new site.

How do you monitor a redesign in Google Search Console?

Check Search Console daily for the first week and weekly for the next two months, comparing every figure with your pre-launch benchmark. Google says a small to medium site can take a few weeks for most pages to move, and that visibility may fluctuate during the move.

Here’s what to look at, and when:

• Days 1 to 7: the Page indexing report for jumps in 404 errors or pages excluded by noindex, the Sitemaps report, and URL Inspection on your 10 most valuable pages.
• Weeks 2 to 8: the Performance report, comparing the weeks since launch with the same stretch before it, filtered by page. Old URLs should fade as new ones pick up the clicks.
• Months 2 to 6: the Core Web Vitals report, queries you’ve lost, and links that still point at old URLs.

How much of a drop is normal? In a March 2026 Shopify article, SEO strategist Greg Bernhardt calls a 0% to 20% change in organic traffic in the first month typical. He treats a 60% fall by day six as a sign of a real problem, and redirect errors on more than 1% of URLs as a sign the map is wrong. Treat those as one practitioner’s rules of thumb, not Google policy.

The full website redesign checklist

Work through these 24 steps in order. The first six happen before anyone opens a design tool.

1. Before: export 12 months of Search Console performance data by page and query.
2. Before: export analytics traffic and conversions by landing page.
3. Before: record Core Web Vitals for your main page templates.
4. Before: crawl the site and build a full URL inventory, including PDFs and images.
5. Before: mark each URL keep, merge or remove, based on traffic and links.
6. Before: list the pages other sites link to most.
7. Build: keep existing URLs wherever you can.
8. Build: write the 301 redirect map, one old URL to one new URL.
9. Build: carry over titles, headings, copy, alt text, structured data and canonicals.
10. Build: update hreflang for every country or language version.
11. Build: add internal links to pages that drop out of the main menu.
12. Build: password-protect staging and add noindex as a backup.
13. Build: test the redirect map on staging with a crawler.
14. Build: test Core Web Vitals and WCAG 2.2 AA on staging.
15. Launch: remove the password and every noindex tag.
16. Launch: check the live robots.txt file.
17. Launch: deploy redirects and test your top 50 old URLs.
18. Launch: submit the new XML sitemap and keep the old one for tracking.
19. Launch: confirm analytics, conversion tracking and forms.
20. Launch: use Change of Address if the domain changed.
21. After: check Page indexing and 404 errors daily for a week.
22. After: compare Performance data with your benchmark weekly for two months.
23. After: ask the sites behind your best backlinks to update them.
24. After: keep the redirects live for at least a year.

What to do next

Start with the benchmark and the URL inventory. They take a few hours and turn every later decision (what to keep, what to redirect, whether launch went well) into a comparison with real numbers.

If you’re planning a redesign and want it built with redirects, staging and launch checks handled from the start, talk to us about your project. If you’re still at the budgeting stage, our guide to how much a website costs breaks down prices in the USA, UK, Australia and India.