Website redesign checklist: 35 checks before you launch

Redesigns cause more sudden traffic collapses than algorithm updates do. Not because the new site is uglier or slower, but because a redesign quietly changes the two things Google actually depends on: the URLs and the crawl instructions. A core update hits a whole industry and gets discussed for weeks. A redesign that shipped with a leftover staging noindex tag hits one business, silently, and nobody notices until enquiries stop.

The mistakes are boring and repeatable. That is good news, because a boring repeatable mistake can be caught by a checklist. What follows is 35 checks, grouped by when they have to happen, ordered roughly by how much damage they prevent.

The two-minute version

If you only do four things: export every current URL with its traffic before anything changes, build a redirect map that sends each retired URL to its closest real equivalent, delete the staging noindex before launch, and check Search Console every day for the first two weeks. Those four cover most of the catastrophic outcomes.

Everything else on this list is either protecting something that already earns you money, or catching a small break before it compounds. The order matters more than the count. A perfect design system on a site whose robots.txt still says Disallow: / is worth nothing.

What actually goes wrong

Three failure modes account for most redesign disasters, and all three are launch-day problems rather than design problems.

1. 1The staging noindex ships. Almost every staging environment carries a robots meta tag or an X-Robots-Tag header telling search engines to stay away, and it belongs there. The failure is that it goes live with the code. Google obeys it, drops the pages over the following days, and the site vanishes from search while looking perfectly healthy to every human who visits it. This is the single most expensive mistake in this article.
2. 2The redirect map is unfinished, or points everywhere at the homepage. New CMS, new URL structure, and 400 old URLs get a blanket redirect to /. Google treats a redirect to an irrelevant page much like a soft 404, so the accumulated signals on those old URLs are simply lost. The pages that earned rankings for years are gone even though the content still exists somewhere on the new site.
3. 3Content that earned traffic gets cut for being 'off-brand'. Redesigns are usually driven by how the site looks, and the long, unglamorous page that answers a specific question is exactly the kind of page a design refresh deletes. It was also the page bringing in organic visitors. If rankings fell after your rebuild, why rankings drop and how to diagnose it walks through separating a redesign cause from an update cause.

A redesign does not lose rankings because it looks different. It loses them because the URLs moved and nobody wrote down where.

Phase 1: before you change anything (checks 1-8)

This phase is pure record-keeping and it is the phase people skip. Everything here exists so that in six weeks you can answer the question "was this page always like that?" Without a baseline, every post-launch problem becomes an argument instead of a fix. Do all eight before a single template is touched.

1. 1Export every URL currently on the site, with its traffic and entry counts for the last 12 months. Twelve months, not three, so seasonal pages appear.
2. 2Record the ranking and impression baseline from Search Console: queries, pages, average position, impressions. Export it, do not screenshot it. You will want to filter it later.
3. 3Inventory the pages that actually produce enquiries. Usually a handful of service pages, one or two articles, and the contact page. These are the pages that must not change URL, and if they must, they get redirects tested twice.
4. 4Save the current title tag and meta description for every page. When the new CMS regenerates titles from a template, this file is how you notice.
5. 5Note the current indexed count in Search Console's Pages report, including the valid/excluded split and the reasons given. It is your after-launch comparison number.
6. 6Take a full backup you have actually tested: files and database, downloaded somewhere off the server. An untested backup is a hope, not a backup.
7. 7Record current Core Web Vitals from field data, not just a lab score. LCP, INP and CLS at the 75th percentile of real visits over the trailing 28 days. If the old site passed and the new one does not, you need to know which of the three moved.
8. 8List every third-party script currently loading: analytics, tag manager, chat widget, booking embed, pixels, review widgets, font hosts. Each one is something that can silently fail to be reinstalled, and half of them are things marketing added without telling anyone.

If you are still deciding whether the redesign is warranted at all, the honest signs a site needs rebuilding is a better starting point than this checklist. Plenty of sites need three fixes, not a rebuild.

Phase 2: build (checks 9-18)

The build phase is where you decide how much damage launch day is allowed to do. A policy decided in week one costs nothing. The same decision made the night before launch costs a week of traffic.

One note on the sitemap: do not spend time tuning changefreq or priority values. Google has said it ignores both. A clean, accurate URL list with real lastmod dates is the whole job.

Phase 3: launch day (checks 19-27)

Launch day has a specific character: everyone is looking at the design and nobody is looking at the headers. Assign these nine checks to one named person and have them confirm each in writing. Do them in this order, because 19 outranks everything.

1. 1Remove the staging noindex. Check the rendered HTML of the live homepage and at least four inner pages for a robots meta tag, and check the HTTP response headers for X-Robots-Tag. It hides in both places, and the header version leaves no trace in the page source. Do this first, verify it twice, and do not take a developer's word for it.
2. 2Verify robots.txt on the production domain is the production file. Staging files usually disallow everything, and copying the environment across is how that file travels.
3. 3Test the redirect map with a real checker, not by clicking a few links. You want the status code and the final destination for each URL, including the ones nobody remembers.
4. 4Confirm that URLs which genuinely no longer exist return a 404 or 410. A pretty 'page not found' template that returns HTTP 200 is a soft 404 factory.
5. 5Check HTTPS end to end: valid certificate, correct hostnames covered, HTTP redirecting to HTTPS in one hop, no mixed-content warnings from old asset paths.
6. 6Submit an actual form and confirm the email arrives at the real inbox, not the developer's. Then submit a second one from a phone. Broken forms after launch are the failure that costs money fastest and shows no symptoms.
7. 7Verify analytics and Search Console are firing on the new build: correct property, correct domain, verification method intact. Domain-property verification through DNS survives a rebuild. A verification file in the web root usually does not.
8. 8Submit the new sitemap in Search Console and confirm it is read without errors.
9. 9Open the site on a real phone on mobile data, not desktop dev tools on office wifi. Tap the phone number, tap the menu, scroll to the bottom, submit the form. Google's Mobile-Friendly Test and the Mobile Usability report were both retired on 1 December 2023, so a real device is now the test.

Phase 4: the first two weeks (checks 28-35)

Recovery from a redesign problem is fast if you catch it in days and painful if you catch it in months. Search Console data lags by a couple of days, and index changes take longer than that to settle, so expect movement and watch the shape of it rather than reacting to one bad morning.

1. 1Check Search Console daily for the first two weeks. Coverage and Pages reports first, performance second. New error types matter more than small impression dips.
2. 2Watch the indexed count against your pre-launch number. A gradual drift as old URLs drop out is expected. A cliff is a noindex or a robots.txt problem, and it is the pattern to panic about.
3. 3Hunt new 404s in Search Console's not-found report and in your server logs. Server logs catch the URLs Google has not recrawled yet, which is most of them in week one.
4. 4Re-check Core Web Vitals from field data once enough real visits have accumulated. Targets are LCP at or under 2.5s, INP at or under 200ms, CLS at or under 0.1, at the 75th percentile over a rolling 28 days. Poor is LCP over 4s, INP over 500ms, CLS over 0.25. Because the window rolls, a fresh build takes weeks to show a clean reading.
5. 5Confirm enquiries are arriving at the same rate as before, by counting them yourself rather than trusting a dashboard. Compare like-for-like weekdays.
6. 6Check that your top landing pages still rank for the queries they ranked for. Filter your exported baseline to the top 20 pages and compare query by query.
7. 7Find and flatten redirect chains that emerged after launch. Old URL to interim URL to final URL happens whenever a second round of edits lands, and each hop is avoidable latency.
8. 8Keep the old site's analytics access and your exports for at least a year. Comparison data you deleted is the reason so many post-redesign arguments end in guesswork.

If something is clearly wrong and you cannot tell what, work through the technical issues worth finding first rather than changing things at random. Post-launch is exactly when random changes destroy your ability to diagnose anything.

How the four phases compare in risk

Notice which row is unrecoverable. It is the one that costs nothing to do and feels like admin.

A realistic launch sequence

Order the day so that the irreversible checks happen while people are still awake and available.

1. 1Freeze content changes on the old site and take a final URL export and backup.
2. 2Deploy to production with the site still behind whatever access control you use.
3. 3Remove the staging noindex and confirm the production robots.txt, before opening access.
4. 4Open access, then immediately run redirects, forms, HTTPS and analytics checks.
5. 5Submit the sitemap and request indexing on your five most important URLs.
6. 6Do the real-phone pass on mobile data.
7. 7Write down the time of launch. You will need it to read the Search Console graphs later.

If the redesign is being handled by an agency, ask which of the 35 they own and which you own. The gap in that answer is where launches go wrong. Our own website design and website development work treats the redirect map and the launch-day verification as part of the build rather than an optional extra, because retrofitting it afterwards is always more expensive.

Questions people actually ask

How long should traffic take to recover after a redesign?

If the URLs were preserved and redirects are correct, most sites see a small wobble for a week or two while Google recrawls, then a return to normal. Days to weeks, not months. If you are still meaningfully down after four to six weeks, it is not settling, it is a problem: usually redirects pointing at the wrong pages, content that got cut, or pages that are not indexable at all.

Should I keep the same URLs even if they are ugly?

Yes, in almost every case. An ugly URL that has ranked for three years is worth more than a tidy one that starts from zero, and readable slugs are a mild usability nicety rather than a ranking factor. Change URLs when the site structure genuinely changes meaning, not because the new CMS prefers a different pattern.

Can I launch a redesign in stages instead?

Often yes, and it is usually the safer choice. Ship templates and design changes first while URLs stay identical, then migrate structure separately if you must. Two smaller changes are diagnosable. One big simultaneous change means that when traffic drops you have no idea which half caused it.

Do I need to tell Google about the redesign?

There is nothing to announce if the domain is unchanged: correct redirects and a fresh sitemap are the notification. If the domain itself changes, use the Change of Address tool in Search Console alongside the redirects. Start at Search Console (opens in a new tab) if the property is not verified yet.

What if the old site's pages were genuinely bad?

Retiring weak pages is fine and often correct. Do it as a deliberate decision with a redirect to the most relevant surviving page, and do it as a separate step from the redesign so you can see its effect. What you should not do is delete pages in bulk because they did not fit a new template, then wonder about the traffic.