A redesign should solve a business or operational problem. “The site looks old” may be true, but it does not tell the team which content to preserve, which journey is broken or whether the platform needs to change.

Small businesses have limited time for parallel content, design and technical work. A useful checklist protects what already works, removes avoidable scope and makes launch responsibilities explicit.

Use this guide before requesting proposals, during implementation and again before the redesigned website goes live.

Confirm that a redesign is the right intervention

Begin with evidence. Review customer questions, form quality, mobile behaviour, analytics, search queries and the editing workflow.

A redesign may be justified when:

  • Visitors cannot quickly understand the offer
  • Navigation reflects the organisation rather than customer needs
  • Important pages are difficult to use on mobile
  • Content updates require risky manual work
  • The current theme or frontend is unsupported
  • Pages are inconsistent because no reusable system exists
  • Required integrations cannot be maintained reliably
  • The brand or service model has materially changed

A focused improvement may be enough when the problem is one form, a slow template or unclear copy. Do not rebuild a working system to solve a contained issue.

Define the redesign goal and boundaries

Choose a small set of priorities. Examples include clarifying services, improving mobile navigation, creating an editable case-study system or replacing an unsupported theme.

State what is not changing. The business may keep its brand, domain, CRM and core content while rebuilding the frontend. Boundaries help providers recommend an appropriate scope instead of assuming every part of the website is open for replacement.

The website redesign service explains how a design refresh, frontend rebuild and platform migration differ.

Inventory the existing website

Create a spreadsheet or document containing every important URL and its purpose. Include analytics and search information if available, but do not delete a page simply because recent traffic is low; it may support a customer journey or external link.

Record:

  • URL
  • Page type
  • Primary topic
  • Current title and description
  • Organic traffic or impressions, if available
  • External links, if known
  • Conversion or navigation role
  • Keep, improve, merge or remove decision
  • New destination URL

This inventory becomes the basis for content migration and redirects.

Review navigation around customer questions

Small-business websites often organise pages according to internal departments or every service variation. Visitors usually arrive with simpler questions: Can you solve this problem? Do you work in my context? What proof exists? What happens next?

Test whether the navigation supports those questions. Reduce competing labels and create a clear route from service explanation to proof and contact.

Do not hide important information behind clever menu names. Familiar language is usually more useful than novelty in primary navigation.

Audit content before redesigning layouts

A new design cannot compensate for unclear service descriptions. Review each important page for audience, purpose, evidence and next action.

Mark content that is:

  • Accurate and worth preserving
  • Useful but poorly structured
  • Duplicated across several pages
  • Unsupported by evidence
  • Outdated or no longer offered
  • Missing entirely

Write or approve priority content early. Real headings and service descriptions influence layout, component size and responsive behaviour.

Decide between refresh, rebuild and migration

A design refresh keeps the platform and improves visual hierarchy, components and content. A frontend rebuild replaces implementation while preserving useful content and systems. A migration moves content and functionality to a different platform.

Choose the smallest intervention that removes the real constraint.

Migration becomes reasonable when the team cannot publish safely, the existing technology is unsupported or required functionality cannot be delivered responsibly. It is not automatically required because another platform appears more modern.

Choose the platform around ownership

Ask who updates the website after launch. A visual marketing team may prefer Webflow. A business with established publishing and plugin requirements may prefer WordPress. A product-oriented site with custom functionality may justify Next.js. Ecommerce operations may make Shopify the practical choice.

Compare:

  • Editor workflow
  • Required integrations
  • Hosting and security responsibility
  • Custom functionality
  • Design control
  • Developer availability
  • Ongoing licences
  • Migration complexity

The Webflow and WordPress comparison provides a deeper CMS decision framework.

Protect mobile content and actions

Do not treat mobile as a smaller desktop screenshot. Decide which information appears first, how navigation opens, where forms place errors and whether sticky actions cover content.

Test:

  • Long service names
  • Contact and phone actions
  • Form input and validation
  • Tables or comparison content
  • Image crops
  • Menu keyboard behaviour
  • Intermediate tablet widths
  • Landscape orientation where relevant

Use representative devices and real content. A layout that works only at a design frame width is not responsive.

Include accessibility during component design

Accessibility decisions become expensive when deferred. Establish focus styles, contrast, heading hierarchy, form labels and keyboard behaviour while building shared components.

Check that information does not rely on colour alone and that motion respects user preferences. Images that communicate content need useful alternative text; decorative media should not add noise.

Automated tools can identify some issues. Manual keyboard and content review remain necessary.

Set a performance budget before adding effects

Large hero media, multiple font families, tracking scripts and animation libraries can make performance difficult before development begins.

Agree on priorities:

  • Main page imagery
  • Required font weights
  • Essential third-party tools
  • Video behaviour
  • Animation purpose
  • Analytics ownership

Measure important templates in production conditions. Do not remove business-critical functionality only to improve an isolated score, but do not allow every third-party request to be treated as free.

The website speed guide explains Core Web Vitals and practical performance work in more detail.

Plan SEO migration before launch

Preserve important URLs where possible. When a URL must change, map one permanent redirect to the closest relevant destination. Do not redirect every removed page to the homepage.

Verify:

  • Unique titles and descriptions
  • Canonical URLs
  • Heading hierarchy
  • Crawlable internal links
  • Structured data that matches visible content
  • XML sitemap
  • Robots rules
  • Image alternative text
  • Staging noindex controls
  • Production indexability

No redesign guarantees higher rankings. Migration planning reduces avoidable technical loss while content quality and authority remain separate concerns.

Preserve analytics and lead routing

Record current analytics properties, tag-manager containers, conversion events and form destinations. Test them in the production environment with consent behaviour where relevant.

Submit a real test lead and confirm who receives it. Check spam handling, success messages and failure states. A beautiful contact form that silently loses enquiries is not a successful launch.

Prepare redirects and a rollback plan

The redirect map should be reviewed before deployment. Keep a copy of the existing website and configuration where possible. Document DNS, hosting and domain access.

Agree on:

  • Who can deploy
  • Who can update DNS
  • How the previous version can be restored
  • Who monitors forms and errors
  • Which issues block launch
  • Who decides whether to roll back

A small business should not discover during an incident that the domain is owned by a former supplier.

Review relevant project evidence carefully

Look for projects with a similar platform, content model or customer journey. Ask what the provider personally delivered and which results can be verified.

The GrowthMaze Webflow case study documents responsive Webflow and CMS-related delivery. It does not attach unsupported traffic or conversion claims to the project.

Pre-launch checklist

Before publishing, verify:

  • Priority pages have approved content
  • Navigation and footer links work
  • Forms validate and deliver correctly
  • Phone and email links work
  • Responsive layouts use real content
  • Keyboard navigation and focus are visible
  • Images have correct dimensions and alternative text
  • Titles, descriptions and canonicals are correct
  • Redirects resolve to relevant pages
  • Sitemap contains canonical URLs
  • Staging controls are removed from production
  • Analytics and consent behaviour are verified
  • Legal pages are current
  • CMS editors have access and guidance
  • Backups and rollback ownership are documented

Post-launch checklist

During the first days and weeks:

  • Crawl the public site for broken links
  • Monitor form delivery
  • Review Search Console indexing and crawl reports
  • Check redirect errors
  • Review field performance data when available
  • Fix production-only layout issues
  • Confirm editors can complete routine updates
  • Record improvement requests separately from launch defects

Do not judge SEO impact from a few days of fluctuating data. Preserve a baseline and review trends over an appropriate period.

Conclusion

A small-business redesign succeeds when it improves communication and ownership without losing valuable content or creating an unmaintainable platform. The checklist protects the less visible work that makes a visual redesign reliable.

If your current site needs a refresh, rebuild or careful migration, review website redesign services or send the current website and constraints.

Frequently asked questions

How do I know whether to redesign or rebuild my website?

Redesign within the existing platform when its content and technical foundation remain suitable. Rebuild when the implementation blocks essential responsive, maintenance or functionality improvements.

Will changing platforms hurt SEO?

It can create risk if URLs, content, canonicals and redirects are handled poorly. A planned migration can preserve important signals, but no provider can guarantee unchanged rankings.

Should a small business keep every old page?

No. Keep or improve pages with a clear user, search or business purpose. Merge overlapping content and redirect removed URLs to the closest relevant destination.

What should be monitored immediately after launch?

Monitor forms, errors, redirects, indexing, analytics and important page journeys. Production issues should be separated from later feature ideas.