Website Redesign Checklist for Small Businesses

A website redesign can improve trust, speed, clarity, and lead generation. It can also remove useful content, break search URLs, disconnect analytics, and send enquiries into an inbox nobody checks.

The difference is usually preparation.

Treat the redesign as a controlled migration of a working business asset, not only a visual refresh. Preserve what already works, fix what evidence shows is weak, and verify the customer journey before changing DNS or announcing the launch.

Before choosing colours or layouts

Write down why the redesign is happening. Useful reasons are specific:

• the offer has changed and the current site no longer explains it;
• mobile visitors struggle to navigate or enquire;
• pages load slowly;
• the team cannot update content safely;
• the visual identity no longer matches the business;
• the current platform creates security or maintenance risk;
• important pages receive traffic but produce few enquiries.

“The website feels old” can be valid, but it is not enough to guide priorities. Define the business outcome: more qualified enquiries, clearer service positioning, easier recruitment, fewer support questions, or lower maintenance effort.

If the current site has visitors but few leads, diagnose why the website is not getting customers before assuming a full redesign is required.

Phase 1: Audit the current website

Create an inventory before anything is deleted.

Record pages and assets

List every public URL, page title, purpose, owner, traffic level, and desired action. Include landing pages that are not linked from the main navigation. Record downloadable files, images, videos, forms, integrations, legal pages, and language variants.

For each item, decide:

• Keep: still useful and accurate;
• Improve: useful purpose, weak execution;
• Merge: overlaps another page;
• Redirect: no longer needed, but has a replacement;
• Remove: no value, traffic, links, or legal reason to preserve it.

Do not judge only by page views. A low-traffic page may answer an important procurement question or support a high-value customer.

Preserve baseline data

Export or record:

• search queries and landing pages from Search Console;
• organic traffic and conversions by page;
• form submissions, booked calls, or sales attributed to the site;
• backlinks to important URLs;
• current Core Web Vitals and mobile performance;
• indexed pages and existing crawl issues.

This baseline lets you compare the redesign with the previous site. Without it, “the new site seems better” is the only conclusion available.

Confirm access and ownership

Before the project starts, confirm administrator access to:

• the domain registrar;
• DNS and CDN;
• hosting or deployment platform;
• analytics, Search Console, and tag management;
• email delivery and form integrations;
• the current CMS, source code, and repository;
• brand assets, photography, fonts, and licence records.

Your business should control its domain and core accounts. Avoid discovering during launch that a former provider or employee is the only administrator.

Phase 2: Define scope and content

Map the customer journey

Decide what each priority visitor needs to understand and do. A local service customer, a procurement manager, and a job applicant may need different paths.

For each important page, define:

1. the intended audience;
2. the question or problem bringing them there;
3. the proof they need;
4. the primary next action;
5. the person responsible for approving the content.

The homepage should not carry every detail. Use focused service pages, proof, FAQs, and contact pathways so visitors can find the right depth.

Write content before final design

Real content determines layout. Designing around placeholder paragraphs creates rework when the actual service explanation, testimonial, or legal disclosure is longer.

Prepare the page titles, headings, copy, calls to action, proof, image requirements, metadata, and internal links. Confirm whether prices use EUR and whether VAT is included or excluded for the target EU and North American audience.

Do not copy every old page automatically. Migration is a chance to remove duplication and outdated claims, but useful search intent and customer information should survive.

Set functional requirements

Document forms, booking, ecommerce, multilingual content, CRM, email marketing, analytics, consent management, accessibility, search, and staff workflows. Define what “working” means for each integration.

Separate launch requirements from later improvements. This protects the schedule and prevents optional ideas from blocking the core customer journey.

Phase 3: Design and build

Review structure before polish

Approve the sitemap, page goals, and rough layouts before investing in finished visual design. It is cheaper to change a wireframe than rebuild a polished page.

Check that navigation labels make sense to customers, not only to internal teams. Important information should not depend on a hover effect or complex animation.

Design for mobile and accessibility

Test common viewport sizes and real devices. Confirm readable text, sufficient contrast, visible keyboard focus, descriptive form labels, logical heading order, useful alternative text, and controls large enough to operate.

Accessibility is a process, not a final automated score. Automated checks help, but keyboard and screen-reader testing of the main journeys catches issues tools miss.

Build performance into the system

Choose appropriate image formats and sizes, limit fonts and scripts, reserve media dimensions, and avoid loading every third-party tool on every page. Performance is cheaper to design in than to repair after launch.

Use the slow website guide to review common bottlenecks. If comparing different delivery models, the agency, freelancer, and WaaS guide can help match the build to your internal capacity.

Phase 4: Protect search visibility

A redesign does not automatically improve SEO. Search performance can fall when URLs change, content is reduced, internal links disappear, or the new site becomes harder to crawl.

Before launch:

• keep valuable URLs unchanged where practical;
• map every changed or removed URL to the most relevant replacement;
• implement permanent redirects without chains;
• retain useful titles, headings, content, and internal links;
• create canonical URLs and an XML sitemap;
• ensure production pages can be indexed;
• remove staging noindex rules and block staging itself appropriately;
• verify structured data against visible content;
• provide a useful 404 page.

Do not redirect every removed page to the homepage. A relevant replacement is better for both visitors and search engines; when no replacement exists, an honest not-found response may be more appropriate.

Phase 5: Test before launch

Use a launch checklist with a named owner for every item.

Content and navigation

• Proofread priority pages and metadata.
• Test every header, footer, button, and internal link.
• Confirm contact details, opening hours, legal entity, and pricing.
• Verify image alt text and downloadable files.

Leads and integrations

• Submit every form using realistic test data.
• Confirm successful delivery, autoresponders, CRM records, and thank-you pages.
• Test booking, checkout, newsletter, telephone, and email links.
• Verify spam protection without making the form unnecessarily difficult.

Technical quality

• Test current versions of major browsers and common mobile devices.
• Check HTTPS, redirects, canonical URLs, robots directives, and sitemap.
• Verify analytics and consent behaviour.
• Check layout stability and key page performance.
• Confirm backups or a rollback path for the launch.

Phase 6: Launch carefully

Choose a period when the team can monitor the site and respond. Reduce DNS TTL in advance if the migration requires a DNS change, but do not change records until the destination, certificates, redirects, and rollback plan are ready.

Immediately after launch:

1. test the homepage and primary conversion paths on the public domain;
2. crawl the live site for broken links and unexpected status codes;
3. verify redirects from old URLs;
4. confirm analytics and Search Console access;
5. submit or refresh the XML sitemap;
6. watch error logs, form delivery, indexing, and performance.

Keep the old site or a recoverable backup available until the new site has been verified. Do not rely on memory to reconstruct missing content after launch.

Phase 7: Review after launch

Check performance and conversions over a meaningful period, accounting for seasonality and campaign changes. Review priority pages after the first week, first month, and first quarter.

Look for:

• lost or rising organic landing-page traffic;
• form or booking completion changes;
• unexpected 404s and redirect errors;
• customer questions that reveal unclear content;
• performance regressions introduced by new marketing tools;
• pages with traffic but weak next-step engagement.

A redesign launch is a new baseline, not the end of the website’s life. Assign responsibility for ongoing content, monitoring, updates, and incident response. The website maintenance guide explains what that ownership should include.

The compact redesign checklist

Before approving launch, confirm that you have:

• a written business objective and success measure;
• a complete URL and content inventory;
• baseline traffic, conversion, and search data;
• control of domain, infrastructure, analytics, and source assets;
• approved audience, sitemap, content, and page actions;
• tested mobile, accessibility, speed, forms, and integrations;
• a redirect map for every changed URL;
• verified analytics, consent, metadata, sitemap, and indexing rules;
• a launch owner, monitoring window, backup, and rollback plan;
• a named person or provider responsible after launch.

The safest redesign preserves evidence, ownership, and customer pathways while changing the parts that truly need improvement. A better-looking site is welcome; a more reliable business asset is the real goal.