Website Redesign Checklist for Small Businesses

A small-business website redesign should begin with goals and an inventory, then move through content, structure, design, development, migration, testing and launch. The checklist below helps you preserve what works, assign responsibility and test the customer journey before changing the live site.

Do not treat it as a list of features to buy. Use it to ask whether each decision supports customers, staff and the business.

1. Define why the website is being redesigned

• Write down the business problem in plain language.
• Identify the customers and tasks affected.
• Separate evidence from preferences.
• Choose a few outcomes you can assess.
• Record what is outside the project.

“Make it modern” is not enough. A clearer goal might be: “Help commercial customers find the correct service and request a site visit comfortably from a phone.”

Establish a baseline using enquiries, important page visits, form completion, customer questions and known faults. If data is incomplete, say so rather than inventing an expected improvement.

Thinking about your own rebuild?

Tell us about your business, your current website and what you would like to improve. We will help you work out the next step.

Tell us about your project↗

2. Audit the existing website

Create a list of every page, file and important function. Give each page a keep, improve, combine, replace or remove decision.

Record:

• the current URL and page purpose;
• important search visits and external links;
• enquiries or sales it supports;
• content owner and last meaningful review;
• photographs, downloads and permissions;
• forms, bookings and other integrations;
• accessibility, mobile and performance problems.

Use our guide to what to keep when replacing an old website before removing content or changing addresses.

3. Confirm ownership and access

Make sure the business can access the domain registrar, hosting, content system, analytics, Search Console and connected services.

Record who owns each account, who pays for it and how access will be transferred if a supplier changes. Do not send passwords through ordinary project documents.

Export the existing DNS records and identify email-related entries. The website launch should not interrupt business email.

4. Agree the audience and customer journeys

List the main customer groups and what each needs to do. Examples include checking service coverage, comparing options, seeing relevant work and requesting a quote.

Map the shortest sensible journey from arrival to action. Include people who land on a service page from search rather than beginning on the homepage.

Test the old site with someone unfamiliar with the business. Their hesitation can reveal confusing labels and missing information.

5. Plan the page structure and navigation

• Give important services useful dedicated pages where appropriate.
• Use labels customers understand.
• Keep navigation focused on common tasks.
• Avoid near-identical location pages with little genuine local value.
• Plan breadcrumbs and internal links for deeper content.
• Check that every page has a clear way forward.

A sitemap is a planning tool as well as a search file. It should show how subjects relate and expose gaps before design work begins.

6. Prepare and approve the content

Write for an intelligent customer, not for the internal organisation chart. Explain what the service includes, who it suits, where it is available and what happens next.

Check every factual claim. Obtain permission for testimonials and project photographs. Keep alternative text descriptive and avoid using images of text for essential information.

Google recommends helpful, reliable, people-first content in its content guidance. Useful specificity is more valuable than repetitive keyword phrases.

Assign one person to consolidate feedback. Endless comments from several uncoordinated reviewers can delay approval and produce contradictory copy.

7. Define functional requirements

List what the site must actually do:

• enquiry forms and delivery rules;
• bookings, payments or ecommerce;
• searchable content or filters;
• integrations with CRM or email systems;
• multilingual content;
• staff editing and approval needs;
• downloads, accounts or protected areas;
• analytics and consent.

Distinguish launch requirements from later improvements. Ask how each third-party tool affects privacy, accessibility, performance and ongoing cost.

8. Choose technology around the requirements

The platform should support the content, editing, functions and maintenance arrangements at a sensible cost.

Keeping WordPress can be appropriate when its editor and integrations suit the team and the setup can be maintained reliably. Astro can suit content-led business sites where much of the page can be delivered as lightweight HTML. Neither platform guarantees speed, rankings or enquiries.

Ask who will handle updates, backups, security and future edits. Confirm how the finished site can be moved if the relationship ends.

9. Set the visual direction

Use approved branding, readable type, clear hierarchy and consistent components. Design representative real pages rather than only a polished homepage.

Check layouts for long headings, error messages, missing images, narrow screens and enlarged text. Avoid approving mock-ups that contain placeholder copy when the real content is much longer.

Compare the scope using our explanation of a website refresh versus a redesign.

10. Build accessibility into the work

Include semantic headings, keyboard operation, visible focus, useful labels, understandable errors, alternative text, contrast and reflow from the beginning.

The WCAG 2.2 quick reference provides criteria and techniques. Automated checks help find some faults, but manual keyboard, zoom and interaction testing are also necessary.

Accessibility is not a final plugin or a single score. Content, design and code all contribute.

11. Set performance expectations

Decide which representative pages will be measured and under what conditions. Include the homepage, a service page, an article and any page with important third-party functionality.

Optimise images, fonts and scripts. Reserve image dimensions to reduce layout movement. Load non-essential features only when justified.

Use PageSpeed Insights for diagnostics and real-user information where available, but do not promise a permanent score. Device, network, location and content changes all affect results.

12. Protect search visibility

Before changing URLs or content:

• export current URLs;
• identify valuable search pages and external links;
• preserve useful titles, headings and subject matter;
• prepare one-to-one redirect mappings;
• update internal links and canonical URLs;
• generate the correct XML sitemap;
• remove unintended staging restrictions at launch;
• monitor Search Console afterwards.

Follow our guide to redesigning without losing Google rankings. Rankings can fluctuate during a migration, and no responsible provider should guarantee a position.

13. Protect staging and manage changes

Build the replacement separately while the old website remains live. Protect the staging environment with appropriate access controls and prevent it from being indexed.

Agree how content changes made during development will reach the new site. A brochure website may need a final comparison; a shop or membership site needs a more detailed data synchronisation plan.

14. Test the complete website

Test content and behaviour at desktop and mobile widths. Include:

• navigation, breadcrumbs and internal links;
• forms from validation through inbox delivery;
• bookings, payments and account journeys;
• keyboard order and visible focus;
• zoom, reflow and screen-reader-informed checks;
• missing pages and error handling;
• images, downloads and external links;
• metadata, canonical URLs and structured data;
• analytics and consent behaviour;
• redirects from important old URLs;
• domain, HTTPS and email after launch.

Use realistic devices and tasks. A successful automated check does not prove that the enquiry reaches the correct person.

15. Prepare launch and rollback plans

Name the person making the change, the person testing it and the person authorised to restore the old site if necessary.

Choose a launch time when relevant staff are available. Save the previous configuration and a recoverable backup. Lower DNS time-to-live only when the launch plan requires it and the team understands the consequences.

After launch, check high-value pages, forms, redirects, analytics, Search Console and business email. Record issues and ownership rather than relying on a group chat.

16. Agree ownership and ongoing responsibility

The proposal should explain ownership of code, content and third-party assets; hosting and renewal costs; support boundaries; backup arrangements; and how the business can move elsewhere.

Plan who will review content, test forms and maintain dependencies after launch. A website starts ageing again as soon as nobody owns those responsibilities.

Questions to ask before approval

1. Which business and customer problems will this solve?
2. Which pages and assets are being preserved?
3. Who owns the domain and connected accounts?
4. What is included in content writing and migration?
5. Which URLs will change, and where will they redirect?
6. How will accessibility and performance be tested?
7. Who confirms forms and integrations work?
8. What happens if launch fails?
9. What will ongoing maintenance cost?
10. Who owns the finished website?

Frequently asked questions

How long should a small-business redesign take?

It depends on page count, content readiness, functionality, decisions and migration risk. Ask for milestones and responsibilities rather than relying on a universal duration.

Should every old page be copied?

No. Preserve useful purposes and assets, then improve, combine or remove content deliberately. Plan redirects for changed addresses where a relevant destination exists.

Can the old site remain live?

Usually, yes. Develop the replacement separately, protect staging and switch only after approval and testing.

Will a redesign improve SEO?

It can help when it improves useful content, internal structure, mobile usability or technical faults. It can also damage visibility if valuable pages and URLs are removed carelessly.

Use the checklist to control the project

Plan changes to content, customer tasks and technology together. Check that the redesign improves the experience while protecting the business during the switch.

Use the complete guide to upgrading an outdated business website for more context. Afterworks can prepare a separate working replacement for you to inspect; explore website rebuilds or contact us to discuss your checklist.

• website redesign
• website checklist
• small business websites
• website migration
• website planning