Website redesign checklist: before, during and after launch

Most redesigns that go wrong were decided badly in the first two weeks, not in the build. The goals were vague, nobody listed the content, or the URLs changed without a plan. This website redesign checklist is the order we work in on brand website projects: what to settle before anyone opens a design tool, what to check during design and build, and what to do on launch day and in the month after. Tick it off in order. Each stage depends on the one before it.

If you are still deciding whether you need a redesign at all, start with how often you should redesign your website. This post assumes the decision is made.

01Before you start: the redesign audit

Write down what the current site does before you decide what the new one should do. Teams skip this because they already know what they dislike. That is exactly why it matters: dislikes are opinions, and the audit is the evidence.

• Goals. Name two or three outcomes the new site must improve, such as qualified enquiries, demo requests or sign ups, and write down today's number for each. Without a baseline you cannot tell whether the redesign worked.
• Analytics check. Confirm that tracking records those outcomes correctly now. A broken form event before launch looks like a failed redesign after it.
• Top pages. Export the pages that earn the most organic traffic, the most conversions and the most backlinks. These are the pages you cannot afford to lose.
• Search Console baseline. Save the queries, clicks and indexed page count from the last three months, so you have something to compare against after launch.
• What works. Note the pages, sections and phrases that already perform. A redesign is not a reason to throw them away.
• What is broken. Slow templates, pages the team avoids editing, forms that go nowhere. List them with a link each.

02Content inventory and site structure

Content is what delays launches. Designs get approved in weeks, then the project waits months for copy.

• Inventory. List every URL on the current site in a spreadsheet, with its traffic and a decision next to it: keep, rewrite, merge or remove.
• Owners and dates. Give every page that needs new copy a named writer and a due date, before design starts.
• New structure. Draft the sitemap of the new site from what buyers look for, not from your org chart. Every important page from the inventory should have a home in it.
• URLs. Keep the URLs that earn traffic wherever you can. Every URL you change is a redirect you have to get right.
• Real content in designs. Design with the real headings and copy, or at least real lengths. Lorem ipsum hides the pages that will not fit.

03Scope, brief and budget

• Write the brief. Goals, audience, scope, must keep, must change, constraints and who signs off. Our guide to writing a website design brief covers each section.
• Platform. Decide whether the CMS stays or changes, based on who edits the site and how often. Changing platform turns a redesign into a migration, with more risk.
• One decision maker. Name the person who signs off each stage. Redesigns stall when five people have a veto and nobody has the final word.
• Out of scope. Write down what this project will not do. It is the cheapest way to protect the timeline.
• Phases. Agree the stages and what each one hands over before the next begins. Ours are set out on our process page.

04Design and build checks

Most of these cost little during the build and a lot after launch.

• Components, not pages. Design the parts every page is built from, so new pages later do not need a designer each time.
• Mobile first in review. Review every template at phone width, where most visitors will see it, not only on a large screen.
• Accessibility. Check contrast, focus states, headings and form labels as you build, not in a final audit. Our website accessibility checklist has the full list.
• Speed budget. Agree limits for images, fonts and scripts per page, and measure each template against them. The Core Web Vitals checklist explains what to measure.
• CMS editing. Have the people who will edit the site try it on staging before launch. If they struggle in training, they will avoid it in production.
• Forms and integrations. Send a test through every form to the real inbox or CRM, and check that consent and analytics behave as the policies say.

05SEO and redirects in a redesign

This is where a redesign loses traffic it earned over years. Google's guide to moving a site with URL changes sets out the rules, and they apply to a redesign whenever URLs change:

• Map every old URL to its closest new one, starting with the pages that earn traffic. Include images and files that rank or get linked.
• Permanent server side redirects, such as 301 or 308, straight to the final URL. No chains, and no sending many old pages to the home page.
• Keep redirects for at least a year. Google says generally at least one year, so it has time to move signals to the new URLs.
• Carry over what ranks: titles, headings, body content and internal links on the pages that bring traffic.
• Update canonicals, internal links and the sitemap to the new URLs, so nothing on the new site points at a redirect.

Even with all of that, expect rankings to move while Google recrawls. The same guide says a medium sized site can take a few weeks or more before the new URLs show, and larger sites longer. If you are changing platform or domain as well, work through our website migration SEO checklist, which covers the extra steps.

06Launch day

• Freeze content on the old site a day or two before, so nothing is published that the new site does not have.
• Launch early in the week, in working hours, with the people who can fix things available.
• Redirects live. Test the top 50 old URLs by hand straight after launch, and run a crawler over the full list.
• Indexing allowed. Check that the staging "noindex" setting did not come with you. It is easy to miss and it hides the whole site from search.
• Sitemap submitted in Search Console, and robots.txt reviewed.
• Forms and tracking. Send one more real test through every form and confirm the conversion arrives in analytics.

07The first 30 days after launch

• Daily for the first week: Search Console errors, 404s in the server logs, form deliveries.
• Weekly for a month: compare clicks, indexed pages and your goal numbers against the baseline you saved before the project.
• Fix 404s that matter with new redirects as you find them.
• Collect editor feedback and fix what slows the team down while the project is still fresh.
• Hand over a maintenance schedule. A new site starts drifting the day it launches. Our website maintenance checklist is the one we use.

08What we never cut from a website redesign checklist

If time is short, protect three things: the baseline numbers, the redirect map and the content owners. Almost everything else can be fixed after launch. Those three cannot, because you only get one chance to measure the old site, one launch day for the redirects, and one project schedule that the copy either fits or breaks.

If you would like a studio to run this list with you, tell us about the project. We will tell you honestly if a smaller fix would do the job.