Website Redesign Checklist: The Seven Steps I Run From Brief to Launch

This is the checklist I run on every site I build. It shows what happens at each step and what I'll need from you. Use it with me or with anyone else; the steps are the same.

The list is for redesigns and for first websites. If you don't have a site yet, skip the inventory in step two and start with a content plan for the first release. There's no reason to invent a migration where nothing exists.

1. I write the brief around what customers need to do

"Make us look more modern" is a fair design goal, but it isn't a project. Before I scope anything, I want to know what the site has to do for a customer. A services firm might need visitors to work out whether their project is a fit, see relevant work, and send an inquiry with enough detail for a useful reply. A product launch needs an explanation, a purchase path and dependable access after payment. Both have a homepage and a contact page. They are not the same job.

What I'll ask you for: the main audience and the decision you want them to make, the essential actions and where their results should go, the budget, any hard dates, and a name beside four roles: who owns the content, who approves it, who builds it and who says go on launch day. I also write down what's still undecided. An unknown integration named now is far cheaper than one discovered in week five.

My website cost guide explains how I tell a focused improvement, a new site, a redesign and a separate system apart. This checklist should fit the project you actually need.

2. I inventory what the current site does well

For a redesign, I collect the important URLs, content, files, forms and integrations. I start with the sitemap and a crawl, then add landing-page data, referral links, campaign destinations and what your team knows about how customers use the site.

Traffic is a clue, not the whole story. A project page you link in proposals matters even if search never sends anyone to it. A quiet service page may bring fewer visitors and better inquiries than a popular general page.

Every important page gets a decision: keep, improve, consolidate, move or retire. When an address changes, I write down where it goes. Google's site-move guidance describes mapping old addresses to relevant new pages, updating internal links and testing the redirects, and it warns against sending unrelated old pages to the homepage. Google: planning a site move

What I'll ask you for: analytics access, any campaign or referral links you know about, and ten minutes on which pages actually matter to sales.

3. I plan the content before anyone approves a layout

Each page gets a purpose, an audience, source material, an owner, a next action and a status: ready, being written, needs review, or deferred on purpose. Then I choose real content for the design. A real service description, a real project with a long title, a product with actual options. Empty headings and perfectly cropped stock photos hide the decisions that make a design work day to day.

For a first website, a small set of complete pages is a strong launch. I don't create thin pages to make the navigation look bigger.

What I'll ask you for: the services, prices, qualifications and claims you're prepared to publish; images you have the right to use; and a decision on who writes anything that's missing. If that's me, it goes in the proposal.

4. I review the design through complete journeys

I review the homepage, but I also review how someone arrives directly on a service page, a project or a guide from search. Many visitors never see the homepage before deciding whether to contact you.

I walk the primary task on the design: can a reader understand the offer, judge whether it fits, find the evidence and reach the next step? I check phone layouts with real text and real forms. I check motion with motion turned off, because copy and controls have to work either way.

What I'll ask you for: feedback tied to the task, not the color. "A customer can't tell which service applies to them" gives me something to fix. Reviewing the same few representative pages each round keeps us from starting over every time.

5. I have the actual editor make an actual change

Before launch, the person who will update the site adds or changes something typical. A project page is a good test: title, summary, category, images, preview, publish. Then they fix a mistake. Can they save a draft without publishing? Does a long title still fit? Can they tell what's editable and what's part of the shared design?

On WordPress, I curate the editor so the team can change content without breaking the layout. WordPress documents block locking and editor curation for exactly this; the account permissions still get designed separately. WordPress: curating the editor

What I'll ask you for: the name of the person who will edit the site, and thirty minutes of their time on staging.

6. I track every handoff until nothing is left open

Some work runs in parallel. Some can't start until a decision lands. A layout can't be signed off while the content that has to fit it is unknown.

I built this board so you can see the handoffs on a project like yours. It starts with a fictional redesign. Open each handoff, set its status, and replace the example notes with your own. It flags the earliest unresolved handoff without pretending to audit your website.

"Needs work" is useful when it names the missing decision and its owner. A row of green checkmarks with no evidence behind them is not.

Before launch, I test the whole site on a protected staging address. I run a controlled inquiry all the way to the inbox or CRM record, not just to the thank-you screen. I check content, links and images; keyboard use, forms, zoom and motion; and the addresses and indexing settings on the important pages. W3C's first-review checks are part of my accessibility pass, and I'm clear that passing them is a start, not a complete audit. W3C WAI: Easy Checks

For performance, I keep lab results and real-visitor data separate. PageSpeed Insights reports both where they exist, and a brand-new site won't have field data yet. Google: PageSpeed Insights

7. I launch it as one coordinated change, then hand it an owner

Launch day is a written list: code, content, domain records, hosting, redirects, mail settings, integration credentials. Each line has a name for who makes the change and a name for who verifies it. Before the window opens, I confirm account access with a named owner on your side, a backup and recovery path, a plan for inquiries arriving during the switch, and a rollback decision that keeps any new customer data.

If you're changing hosting but keeping your company email, I review the mail records separately. Moving a website does not have to mean moving your inbox.

After launch, I check the agreed pages and tasks on the live URLs: the right content, the old addresses behaving as planned, the production indexing settings, and an inquiry arriving where it should. I write down anything unresolved with an owner and a date. Search visibility can move after a big change, so I watch for specific faults before blaming the redesign for every wobble.

Then the site needs an ongoing owner. Ongoing website management is how I do that for clients who want it: a scoped monthly plan for upkeep, content changes and the next improvement.

What I'll ask you for: a person available on launch day to test the live inquiry path and make the go or no-go call.