Website Redesign Checklist: What to Do Before, During and After

Traffic drops after a redesign are almost never caused by the design. They’re caused by URLs that changed without redirects, content that got "tidied up" out of existence, or a staging noindex that shipped to production.

Here’s the checklist we work through on every rebuild.

Before: understand what you already have

Crawl the existing site. Export every URL with its status code, title, and word count. This is your inventory and your redirect source.

Pull twelve months of data. From Search Console: every page with impressions and clicks. From analytics: every page with meaningful traffic or conversions. Any page on either list is a page you must not casually delete.

Identify what earns. Usually 10–20% of pages generate almost all organic value. Mark them. These pages get protected, not "refreshed for consistency".

List your inbound links. Pages with external links have value that doesn’t transfer by itself. They need redirects even if you’re removing the content.

Record a performance baseline. Core Web Vitals, page weight, server response time. You want to be able to prove the new site is faster, and to notice if it isn’t.

Agree what the redesign is for. "It looks dated" is a real reason, but it isn’t measurable. Add something you can check afterwards: more enquiries, better mobile conversion, faster publishing, lower bounce on service pages.

During: build without breaking

Keep URLs where you can. Changing URL structure for tidiness is the most expensive aesthetic decision available. Only change them when there’s a real reason.

Map every old URL to a new one. One-to-one where possible. Never redirect everything to the homepage — search engines treat that as a soft 404, and users hate it.

Preserve content depth. If an old page ranked with 1,200 words answering a question, the new version needs to answer it at least as well. Design-led rewrites tend to cut the substance and keep the adjectives.

Carry the metadata across. Titles and descriptions that already work shouldn’t be regenerated from a template.

Build for the crawler. Make sure content is in the server-rendered HTML. Modern frameworks can render everything client-side; search engines can execute JavaScript, but you’re adding a dependency you don’t need.

Keep staging out of the index. Password-protect it. robots.txt alone doesn’t reliably prevent indexing, and a public staging site can compete with your live one.

Launch: the pre-flight checks

Run through this the morning of launch, not the evening after:

• robots.txt allows crawling and points at the sitemap
• no stray noindex on production templates
• canonical tags point to the live, correct URL on every page type
• the XML sitemap contains only indexable 200-status URLs
• every redirect returns 301, with no chains and no loops
• 404 page returns an actual 404 status, not 200
• HTTPS everywhere, with HTTP redirecting once
• one hostname only — pick www or non-www and redirect the other
• analytics and conversion tracking fire on the new templates
• forms submit and arrive where they’re supposed to
• structured data validates
• Search Console and analytics have the new property set up

After: watch for four weeks

Week one. Check coverage reports daily. Crawl the live site and compare against your redirect map. Look for 404s in server logs — real ones show up here before they show up anywhere else.

Week two. Compare rankings for your protected pages. A small dip while search engines re-process the site is normal. A sustained drop on a specific template is a signal.

Week three to four. Re-measure Core Web Vitals with field data, not just lab tools. Check conversion rate against the baseline — this is where design changes show their real effect.

Throughout. Keep the old site’s crawl export. When someone asks "did this page exist before?", you’ll have the answer in seconds.

The one that catches everyone

Old sitemaps, old internal links and old hardcoded URLs in email templates, PDFs and ad campaigns. Redirects handle them, which is exactly why nobody notices when the redirects are wrong. Test a sample by hand.

---

If you’re planning a rebuild and want the technical side handled properly, that’s what our technical SEO and web development work covers. If you’ve already relaunched and traffic dropped, an SEO audit will usually find the cause within a day.