Do you really need a full redesign?
An ageing website does not always need to be replaced entirely. A redesign becomes relevant when several problems accumulate: difficult administration, an inconsistent content structure, ineffective user journeys, significant technical debt, fragile integrations, accessibility issues or an architecture that can no longer evolve safely.
If the foundation is still sound and the problem is limited to a few pages, SEO, performance or a specific journey, targeted improvements may be faster and less risky than rebuilding the whole platform. A Drupal audit or broader current-state audit can help make that decision before a rebuild starts.
Before choosing a CMS, framework or new visual identity, establish what already works, what must be preserved and what is actually preventing the site from evolving.
Checklist before you start
1. Clarify business objectives
List the actions the website must support: enquiries, registrations, appointments, sales, applications, downloads or access to important information. A redesign without clear objectives can move problems around instead of solving them.
2. Inventory existing content
Identify what should be kept, merged, rewritten or removed. Include documents, media, forms and multilingual content. This prevents important information from being forgotten when the new structure is designed.
3. Identify pages that already attract search traffic
An old-looking page may still perform well in search. Before changing URLs or removing content, identify pages receiving impressions, clicks or inbound links and preserve that value when the content remains relevant.
4. Prepare URLs and redirects
Map old URLs to their new destinations. Any useful page that moves or disappears should have a logical destination. Redirects improvised during launch are a common source of 404 errors and avoidable SEO losses.
5. Inventory critical forms and user journeys
Contact, quote requests, registrations, applications, search and private areas should all be identified and tested. Document required fields, notifications, recipients, consent requirements and third-party integrations.
6. Map integrations and APIs
CRM, ERP, newsletters, payments, authentication, analytics and business tools may be invisible in a mockup but essential to operations. Document flows, responsibilities and dependencies before changing the architecture.
7. Review accounts, roles and editorial workflows
Who can create, review, translate and publish? A redesign is a good opportunity to simplify permissions and editorial processes. It should not replace a familiar workflow with a more complicated administration experience.
8. Treat multilingual as architecture
Languages are more than translated text. Preserve relationships between language versions, URLs, language switching, metadata and hreflang, and decide which content genuinely needs to exist in each language.
9. Include accessibility from the start
Contrast, keyboard navigation, heading structure, alternative text, forms and interactive components should be considered before final polish. Accessibility is easier to build into components than to retrofit after design decisions are fixed. An accessibility, SEO and optimisation approach works best when it starts during scoping.
10. Measure performance and Core Web Vitals where relevant
Record a baseline before the redesign: page weight, images, third-party scripts, loading behaviour and available field metrics. This helps separate content, theme, hosting and external-service problems and lets you verify whether the new site actually improves them.
11. Review security, maintenance and technical debt
List versions, modules or extensions, custom developments, abandoned dependencies and recurring maintenance tasks. A visual redesign that keeps an increasingly difficult technical foundation only solves part of the problem.
12. Prepare post-launch measurement
Decide before launch what you will monitor afterwards: 404s, indexing, forms, conversions, performance, logs and key-page behaviour. Launch is not the end of a redesign; it is the start of validating it under real conditions.
What a useful pre-redesign audit should deliver
A useful audit should not be just a long defect list. It should support decisions.
- Current-state inventory
- Know what should be kept, migrated or removed.
- Prioritised risks
- Identify threats to SEO, data, security or business continuity.
- Quick wins
- Fix issues that may not require a full redesign.
- Prioritised backlog
- Turn findings into an ordered action plan.
- Target scope
- Separate essential work from desirable and later improvements.
- Validation plan
- Define how content, journeys, SEO and rendering will be checked before and after launch.
Drupal, a framework or something else: choose after the need is clear
Technology comes after the analysis. Drupal can be particularly relevant when a project relies on structured content, multiple languages, editorial roles and approval workflows. A highly specific business application may instead justify Symfony or Laravel. In other situations, improving the current platform remains the best decision.
The useful question is therefore not “which technology is best?” but “which architecture meets the need with an acceptable level of complexity, governance and maintenance?”. Our services cover both project scoping and progressive modernisation.
Launch without breaking SEO
Before switching over, verify redirects, canonical URLs, language variants and hreflang, the sitemap, essential metadata and the pages that already generate traffic. After launch, monitor 404 errors, indexing and conversion journeys rather than waiting for a visibility drop before investigating.
When not to do a full redesign
A full redesign may be unnecessary when the technical foundation is still maintainable and targeted changes can solve the real problem: improving a journey, correcting SEO issues, optimising performance, updating the design system or simplifying administration.
In that case, an audit followed by a prioritised improvement backlog can avoid a longer and riskier project without proportional benefit. When rebuilding is justified, our Drupal website redesign approach starts from that scoping work.
Turn the diagnosis into an action plan
Not sure whether you need targeted improvements or a full redesign? Start with an audit of the existing site and turn the findings into a prioritised backlog before choosing the technology or rebuilding scope. Tell us about your project.