Website Redesign Checklist: 15 Things to Review Before You Start

I treat a website redesign like a controlled shutdown, not a mood board exercise. If you skip the checklist, the bills arrive later.

Before I sign off on a redesign, I want to know four things: what business problem the work solves, which pages cannot afford to break, how the mobile experience feels on a real phone, and what proof will tell us the project was worth the effort.

“Design is not just what it looks like and feels like. Design is how it works.” – Steve Jobs

The pressure is not theoretical. Google’s site-move guidance exists because URL changes can quietly damage visibility if they are handled casually, and web.dev’s performance guide is a reminder that speed belongs in planning, not in launch-week excuses.

This checklist walks through 15 things to review before you start. If you want help scoping the work, use our contact page or return to the home page for the wider picture.

Notebook checklist, laptop, and wireframe sketches for a website redesign

Quick View: The 15 Items in Order

Phase	What you are checking	Why it matters
Goal setting	The business outcome, audience, and success metrics	Stops the project from becoming a cosmetic reset with no decision behind it
Content and navigation	Pages, menu structure, and page priorities	Protects useful content and reduces clutter
Mobile and speed	Responsive layout, tap targets, and page performance	Keeps the redesign usable on the devices people actually use
Forms and tracking	Enquiry paths, calls to action, analytics, and events	Makes sure the site still captures leads and data after launch
Launch and aftercare	Redirects, checks, and post-launch monitoring	Prevents the common launch-day mess from becoming a month-long problem

Terms Worth Defining First

There is no glamour in this section. There is only fewer misunderstandings later.

Term	Plain meaning	Why it matters in a redesign
CMS	Content management system	The tool that lets you edit pages without rebuilding the site every time
CTA	Call to action	The button or link that asks a visitor to do something useful
SEO	Search engine optimization	The discipline of helping search engines understand and surface your pages
QA	Quality assurance	The final checking phase before anything goes live
Redirect	A URL forward from one address to another	How you keep traffic and search value when page addresses change

For accessibility basics, I keep the W3C’s introduction to web accessibility close at hand. It is a plain reminder that redesigns should help more people use the site, not fewer.

1. Define the Goal of the Redesign

Every redesign needs a reason that a business owner can say out loud without using design vocabulary. If the answer is “because the site feels old,” you do not yet have a project. You have a preference.

1) State the business outcome

Write one sentence that explains what the redesign must improve. That might be more qualified enquiries, clearer service pages, a better mobile experience, easier editing for staff, or a site that finally matches the business it represents.

Replace vague goals with a concrete business result.
Choose one primary outcome before you discuss layouts.
Make sure every later decision can point back to that outcome.

2) Identify the audience and the jobs they need done

A redesign should make the visitor’s next step easier. That sounds obvious until a menu grows six items longer and no one can find the service page anymore. Define the main visitor groups and the two or three things each group wants to do quickly.

List the main audience types in plain English.
Write the top tasks each audience needs to complete.
Remove pages or sections that do not help those tasks.

3) Decide how success will be measured

Success needs a number or at least a clearly visible signal. That does not mean the redesign needs a fantasy dashboard. It means you should know what to watch after launch so the project can be judged honestly.

Pick a baseline before work begins.
Decide which metrics matter most, such as enquiries, time on task, or page completion.
Agree on what “better” actually looks like before the build starts.

I have never seen a smooth redesign begin with layout choices. The clean ones begin with a decision. The rest are just expensive surprise packages.

2. Audit Content, Pages, and Navigation

If the old site has been collecting pages for years, the redesign is the moment to sort the useful from the merely existing. Content inventories are unglamorous, but so is editing bad navigation at 10 p.m. after launch.

4) Inventory every important page

Make a list of the pages that drive traffic, enquiries, trust, or support. Include page title, current URL, purpose, owner, and a note about whether the page needs to be kept, rewritten, merged, or removed.

List the pages that already perform well.
Mark pages that are outdated, duplicated, or too thin to keep.
Check whether any important page is buried too deeply in the site.

5) Trim pages that no longer help

Redesigns are often burdened by the sentence “we might need this later.” Usually, the site does not. Use the redesign to eliminate pages that duplicate information or confuse the visitor’s path.

Merge overlapping pages where the same answer appears twice.
Remove low-value pages that distract from the main offer.
Keep anything with real authority, traffic, or customer utility.

6) Rebuild the navigation around priority

The menu is not a storage unit. It is a decision about what matters most. Put the highest-value pages first and make the labels obvious enough that a visitor does not have to decode your brand strategy before clicking.

Keep top-level navigation lean.
Use clear labels instead of clever ones.
Make sure the path to contact or enquiry is easy to find from every major page.

When I review a menu, I ask a simple question: if the user has ten seconds and no patience, can they still find the path that pays the bills?

3. Review Mobile Usability and Page Speed

This is where many redesigns say one thing and do another. Teams promise a “clean new site,” then produce one that looks acceptable on a giant monitor and awkward on an ordinary phone. That is not a redesign. That is a desktop-only confession.

7) Test the site on real mobile devices

Do not rely only on emulator screenshots. Open the current site on a phone and walk through the main journey yourself. Check the home page, service pages, contact page, and any form or checkout flow that matters.

Test on at least one iPhone and one Android device if possible.
Check whether important text fits comfortably without zooming.
Look for sticky elements that block buttons or forms.

8) Check tap targets, spacing, and reading flow

Mobile usability is not only about whether the layout shrinks. It is about whether the page still feels intentional when a thumb is doing the navigation. Buttons need space. Links need room. Paragraphs need a reading rhythm that works on a narrow screen.

Make buttons large enough to tap without precision surgery.
Avoid clusters of links that become unusable on small screens.
Keep headings and body text readable without awkward line breaks.

9) Measure speed before the redesign starts

Before anyone changes the visual system, capture the current speed baseline. Use the public tools you trust, then compare the new site against the old one after launch. If the redesign gets prettier and slower, you have paid more for less. A classic business maneuver, but not a good one.

Run a speed check on the homepage and key landing pages.
Note any heavy images, scripts, or layout shifts.
Retest the same pages after the redesign is live.

Google’s PageSpeed Insights and the Lighthouse overview are useful references if you need a practical baseline before the project starts.

4. Check Forms, Calls to Action, and Tracking

A redesign is only successful if visitors can still do something useful with it. If the enquiry form breaks, the call-to-action disappears, or the tracking is missing, the site may look impressive while silently failing the business. An elegant failure is still a failure.

10) Test every form and confirmation path

Every form should work from start to finish. Submit test enquiries, confirm error handling, and make sure the user sees a clear success message or thank-you state. Do not assume a form works because the button looks brave.

Check that required fields are clearly marked.
Verify that confirmations appear after submission.
Make sure notifications reach the right inbox or workflow.

11) Review every major call to action

Calls to action should be easy to spot and easy to understand. If the page asks visitors to get in touch, request a quote, or review services, that action should be obvious. No scavenger hunts. The website already has enough jobs.

Confirm the strongest CTA on each major page.
Check that button text says what happens next.
Make sure the CTA is repeated where a busy reader might need it again.

12) Verify tracking and analytics

Redesigns often go live with the right pages and the wrong data. That is how teams argue about performance for a quarter. Confirm that analytics, conversion events, and form tracking still work after the new design is deployed.

Check that the main analytics tag is still present.
Verify any key conversion events or thank-you page tracking.
Make sure no duplicate tags are inflating the numbers.

If you want a plain-language reason to care about this step, the W3C accessibility intro and Google’s URL-change guidance both point in the same direction: a site should be understandable, trackable, and usable before it is promoted.

5. Plan Launch, Redirects, and Post-Launch Checks

The final phase is where the expensive mistakes usually show up. A redesign does not end when the new theme is published. It ends when the old URLs are handled, the key pages still work, and the first week of traffic tells a calm story instead of a panic one.

13) Build a launch checklist before launch day

Write down the launch steps before anyone is tired, rushed, or waiting on the client call. A launch checklist should cover content, design, forms, tracking, redirects, and a rollback path if something serious happens.

List every task that must be complete before go-live.
Assign a person to each step.
Include the checks that are easy to forget when the clock is running.

14) Map redirects before URLs change

If page addresses are changing, map the old URL to the new one before launch. Do not wait until someone reports a 404 page from a bookmarked link or a search result that no longer lands where it should.

Create a redirect list for every moved or removed page.
Prioritise pages with links, traffic, or historical value.
Test the redirects after launch, not just in the spreadsheet.

Google’s site-move guidance is still the cleanest public reference here: map the change, execute the redirects, then verify that the right pages are being found again.

15) Monitor the first week after launch

The first week matters because launch errors are often small, boring, and costly. Watch for broken links, missing imagery, form failures, unusual traffic drops, and pages that no longer behave the way the old site did.

Check top pages in the browser and in analytics.
Fix any broken internal links or missing assets quickly.
Review the most important enquiries and conversions daily for the first few days.

This is also the moment to listen to real user behaviour instead of internal opinions. A redesign can survive a meeting. It has to survive visitors.

Two Model References Worth Keeping Open

I do not treat external references as decoration. I treat them as the restraint that keeps a project honest.

Google Search Central: site moves with URL changes – useful when you need to protect search visibility during a redesign.
Chrome Lighthouse overview – useful when you need a straightforward pre-launch performance check.
W3C accessibility introduction – useful when you need to check whether the new site will be easier to use, not just easier to admire.
web.dev performance learning path – useful when you want a practical grounding in why speed matters to users.

Three Mistakes That Waste Time and Budget

Most redesign problems are not exotic. They are ordinary, repeated, and expensive because nobody stopped them early enough.

Starting with visuals instead of decisions

If the first meeting is about colours, hero images, and button styles, the team is already skipping the harder work. Visual direction matters, but it should come after the business case, the audience, and the page priorities are clear. Otherwise the project becomes a long conversation about taste, and taste is a poor project manager.

Define the problem before the design mood board.
Set the page priorities before the wireframes.
Use design to support the decision, not replace it.

Rebuilding everything just because it exists

New does not automatically mean better. A redesign should keep the pages and paths that still work, then improve the ones that do not. If a page still brings enquiries, still answers a real customer question, or still earns links, it deserves a careful review rather than a reflexive deletion.

Keep pages with useful traffic or trust value.
Rewrite what is weak instead of replacing what is strong.
Use the audit to simplify, not to create a second cluttered site.

Waiting until launch to think about redirects and tracking

This is the expensive one. If redirects and tracking are handled at the end, teams are forced to improvise when the new site is already live. That is how traffic gets lost, forms stop reporting, and everyone starts checking logs with the enthusiasm of accountants on a holiday weekend.

Map redirects while the content inventory is still open.
Confirm analytics and conversion tracking before launch day.
Test the key journeys again after publication.

What to Do Next

If you need the short version, here it is: define the goal, clean the content, test the mobile experience, verify forms and tracking, and plan redirects before anyone starts arguing over fonts.

Set the redesign goal in one sentence.
Audit the pages and navigation before the visual work begins.
Test mobile usability and page speed early.
Check forms, CTAs, and analytics before launch.
Map redirects and monitor the first week after go-live.

If the project still feels vague, slow it down and resolve the decisions first. A redesign is cheaper when the priorities are clear. If you want a second set of eyes, use the contact page. If you want the broader context first, start from the home page.