Redesign your website without losing what already works

A redesign is worth considering when the site no longer supports the business: visitors struggle to find information, mobile use is awkward, updates are risky, performance is weak, the visual identity feels disconnected, or the current structure cannot accommodate new services. Age alone is not the deciding factor. The evidence should come from usability, analytics, search visibility, maintenance effort and business priorities.

A refresh changes surface-level presentation while preserving most structure. A redesign rethinks information architecture, content hierarchy, interface patterns and user journeys. A rebuild replaces significant technical foundations such as the CMS, templates, codebase, integrations or hosting architecture. Many projects combine redesign and rebuild, but the distinction helps define scope and risk.

It can if URLs, content, internal links, metadata or indexation signals are changed without a migration plan. A well-managed redesign inventories existing pages, identifies valuable rankings and backlinks, maps old URLs to relevant destinations, preserves useful content, validates canonical tags and sitemaps, and monitors search performance after launch.

Stable, descriptive URLs should usually remain when the page purpose remains the same. Changing a URL creates migration work and introduces risk without automatically improving rankings. URLs should change when the new information architecture genuinely requires it, when the old address is misleading, or when multiple weak pages are being consolidated into one stronger resource.

Yes. The appropriate replacement depends on publishing frequency, editorial workflow, integrations, security requirements and maintenance capacity. Some organizations benefit from WordPress. Others are better served by a lean static or custom architecture. Content, media and URLs can be migrated independently of the original platform when the transition is planned carefully.

Content should be evaluated page by page. Some material may only need clearer headings and formatting. Other pages may need consolidation, expansion, factual updates or complete replacement. The goal is not to rewrite everything for the sake of activity; it is to ensure every retained page has a clear audience, purpose and next step.

A focused small-business redesign may take several weeks, while a large content migration or custom platform may take several months. Timing depends on audit depth, stakeholder approvals, content readiness, functionality, integrations, accessibility requirements and the number of migration decisions. The schedule should include discovery, prototyping, development, content migration, testing and post-launch validation.

Usually yes. Development should occur in a protected staging environment or separate build so the public site remains available. The launch plan then coordinates backups, deployment, DNS or hosting changes, redirects, testing and rollback. Content that changes frequently may require a final migration window before launch.

Each old page should receive an intentional decision. It may be retained, merged into a stronger page, redirected to a close replacement, archived, or removed. Redirecting every retired URL to the homepage is poor practice because it ignores relevance. Pages with traffic, links or business value deserve especially careful review.

Not always. A website can apply an existing identity more consistently without a full rebrand. However, if the business name, positioning, audience, services or visual system are changing, those decisions should be resolved early enough to guide content and interface design. The website should not be forced to invent unresolved brand strategy during development.

Success is measured against the goals established before design begins. Relevant indicators may include completed enquiries, qualified leads, task completion, engagement with important pages, search visibility, page speed, accessibility defects, support requests and time required to maintain content. A visual before-and-after comparison is not enough.

Testing should cover navigation, forms, email delivery, responsive layouts, keyboards, focus states, contrast, images, downloads, metadata, structured data, redirects, canonicals, analytics, consent controls, browser compatibility and performance. The team should also verify ownership of domains, hosting, backups and third-party accounts.