The Website Redesign Checklist We Actually Use

Redesigns go wrong in a predictable way. The new site looks better, everyone's pleased for a fortnight, and then someone notices organic traffic is down 40% and nobody can say exactly when it started.

It's almost never the design. It's a URL that changed without a redirect, a staging site that got indexed, or a page that used to rank and quietly stopped existing. This checklist exists because those failures are boring, avoidable, and expensive.

Before: record the baseline

You cannot tell whether a redesign worked if you didn't write down what it replaced. Capture these before a single design file opens:

• Organic sessions, month by month, for the last 13 months — you need last year's same month for comparison
• Your top 50 landing pages by organic traffic, with their entry keywords
• Current conversion rate, per page, for whatever counts as a conversion
• Core Web Vitals from Search Console field data, not lab data
• Total indexed pages, and how many are getting impressions

Take screenshots of the analytics views, not just the numbers. Reporting tools change and you'll want the receipt in six months.

Before: inventory every URL

This is the single most important item on the list and it's the one most often skipped.

Crawl the existing site — Screaming Frog, Sitebulb, whatever you have — and export every URL. Then supplement it, because a crawl misses things:

• Search Console's page report, which knows about URLs your crawl can't reach
• Server logs, for pages with no internal links but real traffic
• Your backlink tool, for URLs other sites point at
• Old sitemap files, including ones nobody's regenerated in two years

On a property client's site this exercise turned up around 300 sold-listing URLs that had been configured to return 404 on the day of sale. Four years of accumulated links, thrown away automatically. Recovering them was one of the highest-value things in that project and none of it would have surfaced from a crawl alone.

Before: decide what dies

Not every page should survive. Go through the inventory and mark each URL:

• Keep — has traffic, links, or a job to do
• Merge — thin, overlapping with something better; redirect into the survivor
• Rewrite — right topic, bad execution; keep the URL, replace the content
• Retire — genuinely obsolete, no traffic, no links; 410 or redirect to the nearest relevant page

Be honest in the merge column. Three thin pages about the same service compete with each other, and merging them into one substantive page usually outperforms all three combined. Just make sure the URL you keep is the one with the links.

During: build the redirect map as you go

The redirect map is a spreadsheet with two columns: old URL, new URL. Every single row from your inventory needs a destination. Not the homepage — the closest equivalent page. Mass-redirecting to the homepage is treated as a soft 404 and loses the value you were trying to keep.

Rules we hold to:

• 301, not 302, unless the change is genuinely temporary
• One hop. Redirect chains dilute and slow things down; if an old URL already redirects, point the new rule at the final destination
• No redirect loops — sounds obvious, happens constantly with trailing-slash and case rules
• Test the map on staging with a crawler before launch, not after

If the URL structure doesn't need to change, don't change it. "Nicer URLs" is rarely worth the risk on a site with existing authority.

During: keep what already ranks

Designers rewrite headings. It's an instinct. But if a page ranks for a term, its title tag and H1 are part of why.

Before rewriting any page in the top-50 list, check what it ranks for. Then either keep the title and H1 close to the original, or make the change deliberately and accept a few weeks of movement. What you don't want is thirty page titles changing as a side effect of a tone-of-voice pass nobody connected to search performance.

Same goes for internal links. A page's rankings depend partly on how many internal links point at it and what they say. New navigation that drops a section from the menu quietly demotes everything in it.

During: keep staging out of the index

Every agency has done this once. Staging site indexed, duplicate content everywhere, and a period of confusion while Google decides which version is canonical.

Use HTTP authentication on staging. Not robots.txt, not a meta noindex — actual authentication, because those two can be misconfigured and often are. And check before launch whether any staging URLs are already indexed; if they are, remove them through Search Console rather than hoping.

Launch day: the verification pass

Launch in the morning, not on Friday afternoon. Then, in this order:

1. Crawl the live site and confirm zero unexpected 404s or 500s
2. Spot-check 20 redirects from the map by hand, including the deepest URLs
3. Confirm robots.txt allows crawling and doesn't still carry the staging block
4. Check every canonical tag points at the live URL, not staging
5. Confirm the noindex tag from staging is gone. Check the built HTML, not the CMS setting
6. Submit the new sitemap in Search Console
7. Verify analytics and conversion events fire on the new templates — they break on redesigns more often than not
8. Test every form, including the failure paths. Submit an invalid payload and confirm you see a real error rather than a false success
9. Run Lighthouse on mobile for four page types and record the numbers

That's about two hours of work. It's the cheapest insurance in the project.

After: the 30-day watch list

Expect movement. On a small site, a week or two. On a large catalogue, three to six weeks while everything gets recrawled. A 10–20% dip in the first fortnight is normal and usually recovers.

What isn't normal, and what to check weekly:

• Coverage errors in Search Console. A spike in "not found" means a redirect is missing.
• Indexed page count. If it drops sharply and stays down, something is blocking crawling.
• Top landing pages. Compare against your baseline list. A page that vanished entirely is a specific, fixable problem.
• Conversion rate per template. Aggregate numbers hide a single broken template.
• 404 logs. Real user traffic hitting missing pages, which is your redirect map's homework marked for you.

If traffic hasn't recovered after six weeks, stop waiting and audit. It's a problem, not a settling period.

What this costs in time

The checklist above adds roughly a week of work to a redesign — two days of inventory and baseline, two days of redirect mapping and testing, half a day on launch verification, and an hour a week for a month afterwards.

One redesign we were asked to rescue had skipped all of it. Recovering the lost traffic took four months and cost more than the original build. A week up front is a good trade.

We run this on every migration we do. If you're planning a redesign and want a second pair of eyes on the URL inventory before you commit, get in touch — it's a short piece of work and it's the part that decides the outcome.