- Current-site evidence
- Content and journey plan
- Reviewed build
- Verified transition
Identify what needs to change and what is working
Start with the reasons for the redesign. An outdated appearance, confusing navigation and unreliable lead delivery are different problems. The project should name the desired improvement so decisions are not driven only by personal preference.
Review representative customer journeys. Can someone understand the service, compare relevant options and find the next step? Can the team update a price or publish a new project without disrupting the layout? These practical questions reveal requirements that a homepage mood board will miss.
Use available analytics, search information and business feedback carefully. A page with modest traffic may still serve an important customer or support task. A popular page may attract visitors who have little connection to the business. Interpret the evidence before deciding what to keep, rewrite or remove.
Preserve useful content, working routes and approved assets where they still serve the site. Redesign does not require discarding everything that came before.
Inventory the site before changing its structure
List the current pages, downloads, forms and important media. Include destinations linked from advertisements, email messages and external sites. The visible navigation may not reveal every URL people still use.
Assign a proposed outcome to each item: retained, revised, moved or retired for a stated reason. The owner should be able to review these decisions before implementation. Avoid silently deleting material because it does not fit the first design concept.
If URLs will change, prepare a specific mapping from old pages to appropriate new destinations. Google's site-move guidance recommends planning the mapping, testing the new site, implementing suitable redirects and monitoring the transition. Sending every old page to the homepage is not an equivalent replacement for a relevant destination.
Include images and documents in the transition plan when they are useful or receive links. A redesign can break a downloadable resource even while the main pages appear to work.
Organize content around customer decisions
Define the purpose of each key page and the relationship between pages. A service overview, a detailed explanation and a contact page should each help with a different part of the decision. Navigation labels should reflect what visitors recognize rather than internal department names.
Write or revise the essential content before treating the layout as final. The design needs to accommodate the real explanation, conditions and calls to action. Placeholder text can hide whether a section has a useful purpose.
Use authentic evidence the business has approved. Project photos, process details and verifiable credentials can support the offer. Do not fill a redesigned site with invented testimonials, client logos or numerical claims.
For location information, distinguish an actual office from a service area. A visual map or a list of cities should not imply staffed branches that do not exist. The redesign is an opportunity to correct ambiguity, not make it more attractive.
Design the system beyond the homepage
A website needs repeatable visual rules for headings, body text, buttons, forms, cards and navigation. Those rules should support different content lengths and page types without making every page look like a manually assembled exception.
Review the most demanding examples early. A long service title, an article with several headings or a form with an error state can expose weaknesses in the design system. A beautiful short sample does not prove the layout will work across the site.
Test the design at narrow and wide widths. Consider keyboard access, visible focus, text contrast and the way content behaves when enlarged. W3C's preliminary accessibility checks are useful starting points, but a first review is not a claim of comprehensive conformance.
Motion and media should support the task. If an effect delays access to the offer or makes the form difficult to use, revise it. The business's visual identity can be distinctive while the interface remains understandable.
Rebuild the inquiry path as a complete process
Review every contact action and its destination. A form needs clear labels, useful error messages and an accurate confirmation. A telephone link needs the correct number. A booking action needs to reflect whether it creates a confirmed appointment or only a request.
Verify receipt in the actual receiving system using controlled test information. A success animation is not proof that the inquiry reached the team. Define who receives the request and what happens if delivery fails.
Dappr offers its own CRM. Any connection to it should be confirmed as supported and included in the scope. Third-party CRM setup or migration is not assumed as part of a redesign.
Preserve or deliberately revise measurement. The new site should not count a button click as a completed lead merely because that event is easy to track. Define the business action and verify the implementation.
Plan performance, release and recovery
Review loading, interaction and layout stability using appropriate measurements and practical device checks. Google's Core Web Vitals help describe these aspects of experience, but a score alone does not prove the site meets its business purpose.
Keep a clear boundary between review and production. The owner should be able to inspect the new content and behavior before the site replaces the existing one. Identify the accounts, hosting settings and release responsibilities in the project plan.
Prepare a launch checklist tied to the actual scope: key routes, redirects where needed, forms, metadata, indexing settings and important downloads. Google notes that significant site moves can involve temporary search fluctuations, so avoid promising an uninterrupted ranking outcome.
Define a recovery plan appropriate to the platform and change. The team should know what can be restored and how to respond if a material launch problem appears. That decision belongs before release, not during an incident.
Deliver a site the business can maintain
Handover should explain how routine content is edited, which parts require development and who owns the relevant accounts. Include known limitations and the ongoing responsibilities for updates, security and content accuracy.
A redesign quote depends on the page inventory, content work, platform, integrations and transition requirements. Separate design, implementation, media production and ongoing maintenance when they are distinct. Dappr works with most website builders and can assess the existing platform before proposing a change.
Bring the current site, the main customer problems and the people responsible for content and inquiries. We can define a redesign around observable improvements and a reviewable transition rather than a promise that a new appearance alone will increase sales.
Questions before you begin
Do we need to change platforms during a redesign?
Not necessarily. First determine whether the current platform can support the required content and workflows. A platform move adds migration and training work and should solve a defined limitation.
Can we keep our existing URLs?
Often, when the current structure remains useful. If URLs change, map them to relevant new destinations and verify the transition. Do not change paths merely to make the project feel new.
Will a redesign preserve all search rankings?
No one can guarantee that. Careful content preservation, URL planning and technical checks can reduce avoidable problems, but search systems may reassess significant changes over time.
Is new copy included?
The proposal should specify it. Copy revision, expert interviews, original photography and technical implementation are different tasks. Review the existing material before assuming it can all be reused unchanged.
How do we know the new contact form works?
Test successful receipt and the staff handoff using controlled information, not just the visible confirmation. Include error behavior and the measurement event in the acceptance checks.