The website redesign checklist

The pattern repeats constantly. A business launches a new site everyone is pleased with, and four to six weeks later enquiries have dried up. The design review passed. The migration did not happen. Below is what should be done before, during, and after launch, in the order it should happen.

Before you design anything, find out what is working

You cannot protect what you have not measured. Before any design work begins, export the data that tells you which pages matter. Google Search Console shows which pages earn impressions and clicks and for which queries. Analytics shows which pages people actually land on and which produce enquiries. Crawl the existing site to get a complete URL inventory. The output you want is a simple list of every page that earns traffic or conversions, which becomes the protected list. Cutting a page that quietly brought in two enquiries a month is invisible at design time and expensive afterwards.

1. 01Export twelve months of Search Console performance data by page and by query.
2. 02Export analytics landing page data with conversions, not just sessions.
3. 03Crawl the full site to inventory every URL, including ones nobody remembers.
4. 04List every page with backlinks pointing to it, since those are the hardest to replace.
5. 05Record current Core Web Vitals so you can prove the new site is faster.
6. 06Screenshot or archive key pages so you can compare content before and after.

Map every URL before launch, not after

This is the step that prevents the traffic collapse, and it is the one most often left until the week of launch when there is no time for it. Build a spreadsheet with every old URL in one column and its new destination in the next. Every single one needs a destination, and that destination should be the closest genuine equivalent rather than the homepage. Redirecting everything to the homepage is technically a redirect and practically a deletion, because search engines treat a mass redirect to an irrelevant page as a soft 404. Use permanent 301 redirects, not temporary 302s, since only the permanent form passes accumulated ranking signals reliably.

The pre-launch checklist

• Every old URL mapped to a new destination with a 301 redirect, tested in a staging environment.
• Redirect chains collapsed, so no URL redirects to another redirect.
• Page titles and meta descriptions written for every page, not inherited from a template.
• Canonical tags pointing to the correct version of each page.
• Structured data implemented and validated with a testing tool.
• XML sitemap regenerated to reflect the new structure only.
• Robots.txt checked, and any staging-site blocking rules removed before going live.
• Analytics and conversion tracking installed and verified with a test conversion.
• Every form submitted end to end, confirming the email actually arrives.
• Core Web Vitals measured on the staging site and compared with the old one.
• Accessibility checked: contrast, keyboard navigation, focus states, alt text.
• Tested on a real mid-range phone on mobile data, not only in a desktop browser.
• SSL certificate valid, and all internal links using https.
• 404 page in place that helps people rather than dead-ending them.

The first fortnight after launch

Migration problems are cheap to fix in week one and expensive in month three, so the monitoring period is not optional. Submit the new sitemap in both Google Search Console and Bing Webmaster Tools on launch day. Watch the coverage and crawl error reports daily for the first week: a spike in 404 errors means a redirect was missed, and the report will tell you exactly which URL. Watch impressions rather than rankings, because impressions move first. Some fluctuation is normal for a week or two as engines recrawl. A sustained drop after three weeks is a problem, not settling.

1. 01Submit the new XML sitemap to Google Search Console and Bing Webmaster Tools.
2. 02Check crawl errors daily for the first week and fix every 404 that appears.
3. 03Verify redirects are firing correctly by testing a sample of old URLs by hand.
4. 04Confirm analytics is recording traffic and conversions properly.
5. 05Compare Core Web Vitals against the old site and record the improvement.
6. 06Re-test every form a week after launch, because mail delivery problems often appear late.
7. 07Watch Search Console impressions weekly for two months before drawing conclusions.

When a redesign is the wrong answer

Sometimes the honest advice is not to redesign. If the site is reasonably modern and the real problems are slow loading, unclear messaging, thin content, or a buried contact path, targeted fixes cost a fraction of a rebuild and address the actual cause. A full redesign is warranted when the underlying technology genuinely constrains you, when the brand has moved on, when the structure cannot accommodate what the business now does, or when the site is actively costing credibility. Diagnose before prescribing, because a redesign that fixes appearance while leaving the real problem untouched is an expensive way to stand still.