Website Redesign Checklist: When and How to Redesign

A redesign is one of the few website projects that can make things worse. A new site can look better, load faster and still lose a third of its organic traffic in the first month, because nobody mapped the old URLs, the staging site was indexed or the tracking stopped working on launch day. The design was fine. The process was not.

This guide is a practical website redesign checklist for business owners and marketing teams. It covers how to tell when a redesign is really needed, how it differs from a refresh or a rebuild, what to prepare before design starts, how to protect SEO during the migration, what to check on launch day and what to monitor in the first 90 days. It reflects how we run redesign projects as part of our corporate website development work.

Signs it’s time to redesign your website

Not every website problem needs a redesign. But some signals are hard to fix with small changes. Here are the common triggers and how to check each one.

Outdated design. The site looks like it was made several years ago, and visitors notice. Check: compare your site side by side with three direct competitors and ask a few customers which looks more credible.

Poor mobile experience. Text is too small, buttons are hard to tap, menus or forms are awkward on a phone. Check: look at the share of mobile traffic in GA4 and compare conversion rates for mobile and desktop. A large gap usually points to a mobile UX problem.

Low conversion rate. Traffic is stable, but leads or sales do not grow. Check: review funnels in GA4 and session recordings to see where visitors drop off. If the problems are in structure and navigation rather than one form, a redesign may be justified.

Slow load times. Core Web Vitals stay poor despite optimization. Check: the Core Web Vitals report in Google Search Console and PageSpeed Insights for key templates. If the cause is the theme or architecture, a redesign or rebuild is often cheaper than endless patches.

Rebranding. A new name, positioning or visual identity needs a site that reflects it. A logo swap on an old structure rarely works.

CMS limitations. The marketing team cannot create pages, landing pages or translations without a developer, or the CMS no longer receives updates. Check: list the tasks your team cannot do in the current system and how long they wait for developers.

Technical debt. Every update breaks something, the code is hard to maintain and maintenance costs keep growing. When the cost of keeping the old site alive approaches the cost of building a new one, it is time to plan.

If two or three of these signs apply, a redesign is likely worth it. If only one does, a targeted fix may be enough.

Build the business case before the brief. A redesign competes for budget with ads, sales and product work, so it helps to write down the expected return. Describe the problem in numbers (conversion rate, lead volume, bounce rate on key pages, time the team spends on manual updates), the outcome you expect and how you will measure it. Add the cost of doing nothing: lost leads, rising maintenance, missed opportunities in new markets. A one-page business case makes approval easier and gives the project a clear goal that guides every later decision.

Redesign vs refresh vs rebuild

“Redesign” can mean very different projects. Choosing the right type of project is the first step of any website redesign strategy, because it defines scope, risk and budget.

The choice between a refresh and a redesign is often the most important one. A refresh keeps everything search engines already understand and changes what users see. A full redesign or replatforming changes much more, so it needs a full SEO migration plan.

Another decision at this stage is whether to keep a template-based site or move to a custom one. We compared both options in detail in our article on custom website vs template website. To see what different types of redesigns look like in practice, see our corporate website development page.

Before the redesign: audit and planning checklist

This is the most important stage. Most redesign problems that appear after launch were created here, when the team skipped the audit or did not write down what must be preserved. Each block below is a checklist.

Set goals and KPIs

☐ Write down why you are redesigning: more leads, higher conversion rate, better mobile experience, support for new markets, lower maintenance cost

☐ Turn each goal into a measurable KPI: conversion rate, number of leads, revenue, average session duration on key pages

☐ Record a GA4 baseline for the last 12 months: traffic by channel, conversions, top pages, device split

☐ Agree who will judge success and when: 30, 60 and 90 days after launch

Without a baseline, nobody will be able to say whether the redesign worked.

Audit current performance

☐ Export data from GA4: top landing pages, conversion paths, pages with high exit rates

☐ Export data from Google Search Console: queries, pages, clicks, impressions, average position

☐ Crawl the current site with Screaming Frog or a similar crawler: all URLs, titles, meta descriptions, H1, canonicals, status codes, internal links

☐ Review heatmaps and session recordings for key pages

☐ Note what works well and must not be lost: high-converting pages, well-ranking content, useful features

Inventory content and top pages

☐ Run a content audit: decide for each page whether to keep, update, merge or remove it

☐ Mark top landing pages by organic traffic and conversions. These pages need the most care during migration

☐ List pages with backlinks from other sites. Losing them without a redirect means losing link equity

☐ Identify thin, outdated or duplicate content that can be merged or removed

Keep analytics continuous. Write down which GA4 events, conversions and Google Tag Manager tags exist today, and how they map to the new site. If form names, button IDs or URL patterns change, tracking breaks silently and you lose the ability to compare before and after. Plan the new tracking setup in the same document as the URL map.

Research users and competitors

☐ Interview several customers and sales or support staff: what do people look for on the site, what confuses them, what is missing

☐ Review support requests and common questions

☐ Analyze three to five competitors: structure, offer, content, how they present cases and prices

☐ Write down conclusions as requirements, not as “we liked this design”

Define scope, budget and timeline

☐ Prepare a design brief: goals, audience, brand, content, functionality, constraints. Our guide on how to write a design brief explains what to include

☐ Draft a new sitemap based on the content audit and user research

☐ Define which features, integrations and languages are in scope

☐ Agree on budget and timeline with a buffer for risks

For complex sites, it pays to start with a separate discovery phase: a short project that turns goals and research into requirements, structure and a realistic estimate before design starts.

Website redesign project plan template

A simple plan keeps everyone aligned. You can use this template as a starting point and adapt it to your project:

Add a RACI matrix for key decisions: who is responsible, who approves, who must be consulted and who only needs to be informed. This avoids the common situation where design is approved by one person and rejected by another a week before launch.

Content is the most underestimated part. Design and development are usually planned carefully, while content is expected to “come later”. In practice, content is what most often delays a launch. New page texts, case studies, images, translations and approvals take weeks, especially when several departments are involved. Assign a content owner, make a content inventory with a status for every page, and start writing as soon as the sitemap is approved. Designing with real content rather than placeholder text also produces better layouts, because headings, lists and images are designed for what will actually be on the page.

Design and development checklist

Once the plan is approved, the project moves into design and development. Use this checklist to make sure nothing important is missed.

☐ Information architecture. The new structure follows the sitemap from the planning stage and is tested with users or at least with tree testing.

☐ Wireframes. Key templates (home, service or category, product or case, contact) are approved as wireframes before visual design starts.

☐ Design system. Components, typography, colors and states are documented, so new pages stay consistent after launch.

☐ Mobile-first. Layouts are designed for small screens first and then extended for larger ones.

☐ Accessibility. Contrast, font sizes, focus states, form labels and keyboard navigation meet WCAG requirements.

☐ CMS choice. The platform fits your team and plans: WordPress for flexibility and a large ecosystem, Webflow for visual editing and speed of launch, headless CMS for complex multi-channel projects. We compared the two most common options in WordPress vs Webflow.

☐ Staging environment. The new site is built on a staging server closed from indexing and protected with a password or IP restriction.

☐ Performance budget. Limits for page weight, number of scripts and Core Web Vitals targets are agreed in advance and checked during development.

☐ Content migration. Content is moved and reviewed page by page, with titles, meta descriptions and images updated where needed.

☐ Forms and integrations. CRM, email marketing, payment, chat and other integrations are connected and tested on staging.

Good design and development teams work together from the wireframe stage, not one after the other. Our UI/UX design services include design systems and handoff that developers can implement without guesswork.

Agree on decision-makers early. Redesigns attract opinions from everyone: founders, sales, marketing, product, sometimes investors. Define who gives feedback at each stage and who makes the final call. Collect feedback in one place, against the goals from the brief, not personal taste. This alone can save weeks of back-and-forth.

SEO checklist for a website redesign

This is the most detailed part, and for good reason. SEO is where most redesign traffic losses happen, and most of them are preventable. The checklist below shows how to redesign a website without losing search traffic. It also works as a migration checklist when you change platforms.

URL mapping and 301 redirects

☐ Export every URL of the old site from the crawl, GA4, Search Console and the sitemap. Combine the lists, because each source misses some pages

☐ Create a URL map: old URL, new URL, status (keep, redirect, remove)

☐ Set up 301 redirects from every changed old URL to the most relevant new page, not to the homepage

☐ Avoid redirect chains (A to B to C) and loops. Each old URL should redirect directly to its final destination

☐ Keep URLs unchanged wherever possible. The best redirect is the one you do not need

☐ For removed pages with no equivalent, decide between a redirect to a parent category and a 410 or 404 status

On-page elements and structured data

☐ Transfer or improve titles and meta descriptions for every page, especially top landing pages

☐ Make sure each page has one H1 that reflects its topic

☐ Set canonical tags to the new URLs, not to the staging domain or old addresses

☐ For multilingual sites, check hreflang tags on every language version

☐ Transfer structured data: Organization, Breadcrumb, Article, Product, FAQ and others used on the old site

☐ Keep the content that ranks. Rewriting a page that ranks well for important queries is a risk, so make changes deliberately

Internal links and site architecture

☐ Update internal links in content and navigation to point directly to new URLs, not through redirects

☐ Make sure important pages are reachable within a few clicks from the homepage

☐ Find orphan pages, which have no internal links, and either link them or remove them

☐ Check that the new navigation still links to the pages that brought the most traffic

Crawling and indexing controls

☐ Keep noindex and password protection on staging, and remove noindex from production on launch day. Forgetting this is one of the most common and most damaging launch mistakes

☐ Prepare a new XML sitemap with only canonical, indexable URLs that return 200

☐ Check robots.txt on the new site so it does not block important sections, CSS or JavaScript

☐ Run a crawl comparison: crawl the staging site and compare it with the crawl of the old site. Look for missing pages, changed titles, broken links and new errors

A careful redesign does not guarantee that rankings will not move at all. Some fluctuation in the first weeks is normal while search engines process the changes. What the checklist prevents is a lasting drop.

Special cases: domain, protocol and language changes. Some redesigns also change the domain, move from HTTP to HTTPS or restructure language versions. These need extra care:

• New domain. Redirect every old URL to its exact counterpart on the new domain, keep the old domain registered and redirecting for years, and use the Change of Address tool in Google Search Console.

• Language structure. When language versions move, for example from subdomains to subfolders, update hreflang on every page, redirect old language URLs one-to-one and check that each language has its own sitemap entries.

• Merged sites. When several sites are combined into one, map each old site separately and expect a longer period of ranking fluctuation.

In these cases, do not combine too many changes on the same day if you can avoid it. Fewer simultaneous changes make problems easier to diagnose.

Launch day checklist

A website relaunch should be a calm, planned event. Choose a day with low traffic and a team available to fix issues, and avoid Fridays and holidays.

☐ QA testing. Check key templates and user flows on the production server: navigation, search, forms, checkout if you have one

☐ Cross-browser testing. Check the site in current versions of Chrome, Safari, Firefox and Edge, on desktop and on real phones

☐ Form and tracking tests. Submit every form and confirm that leads arrive. Check Google Tag Manager, GA4 events and conversions, and ad platform tags

☐ Redirect testing. Test a sample of old URLs, especially top landing pages and pages with backlinks, and confirm they return 301 to the correct new page

☐ Indexing settings. Confirm noindex is removed, robots.txt is correct, canonicals point to production URLs

☐ Sitemap submission. Submit the new XML sitemap in Google Search Console

☐ SSL and domain. Confirm HTTPS works everywhere and the www or non-www version redirects correctly

☐ Rollback plan. Keep the old site and its database ready to restore, and agree in advance who decides on a rollback and under what conditions

Tell people about the relaunch. A new site is a reason to contact customers and partners. Announce it by email and on social media, brief the sales and support teams on what changed and where things are now, and update links in ads, email signatures, social profiles, Google Business Profile and directories. Old links in ads are especially costly: they send paid traffic through redirects or, worse, to pages that no longer exist.

After launch: what to monitor in the first 90 days

The launch is not the end of the project. The first three months show whether the redesign achieved its goals and catch problems while they are still easy to fix.

Collect user feedback actively: ask customers and sales staff what they think of the new site, and watch session recordings on new templates. Small fixes in the first weeks often have a large effect.

At the end of 90 days, prepare a short report: what changed in traffic, conversions and performance, what worked, what did not and what goes into the next iteration. If we had to sum up this guide in three rules: measure before, protect what works, and keep improving after launch.

If traffic drops after launch. Some fluctuation is normal, but a sharp drop that lasts more than a couple of weeks needs a diagnosis. Compare organic traffic by landing page before and after launch to see which pages lost the most. For those pages, check that the old URL redirects with a 301 to the right new page, that the new page is indexable (no noindex, not blocked in robots.txt, correct canonical), that its title and main content still match the queries it used to rank for, and that internal links still point to it. In most cases the cause is one of these, and fixing it restores traffic over the following weeks.