Website redesign services that build on what works.
Your existing site has a history worth understanding. WebXd helps you improve confusing pages, update the presentation, and make important tasks easier to complete. We start by deciding what should stay, then plan the changes and the transition around the people who already depend on your website.
Let the current site inform the next one.
A dated homepage is visible. The reason people abandon a task can be harder to see. Before choosing new layouts, we review the pages visitors use, the questions your team receives, and the steps that lead to an inquiry or another important action. Those findings give the redesign a purpose.
Your site may already have useful guides, recognizable language, and dependable routes to popular resources. We record those strengths alongside confusing navigation and content that has become inaccurate. Where data is available, we use it to check assumptions. Where it is missing, we identify the questions that need investigation.
Bring evidence you already have
- The current website and the pages your team considers essential
- Analytics or search reports, if available
- Recurring visitor questions and examples of unfinished tasks
- Publishing constraints and systems the site connects to
Match the redesign to the problem.
A redesign does not have to replace everything. We can define a focused change or a broader rebuild of the experience, depending on what the review reveals. The scope should explain which templates change, which content needs attention, and which existing features are worth keeping.
Refresh the presentation
A visual refresh suits a site with useful content and a sensible structure. Typography, spacing, imagery, and reusable page components can change while familiar navigation remains. We still check the updated pages on smaller screens and test the actions visitors rely on.
Repair a key journey
A focused redesign can address a service inquiry, resource search, or other priority task. We examine the route into the page, clarify the information, and improve the next step. That lets your team tackle a specific obstacle while retaining the rest of the site.
Reshape the wider site
A broader redesign may reorganize navigation and rebuild several page types when the current structure no longer fits. We create a content inventory and agree on what to retain, revise, merge, or retire. Platform replacement is a separate decision based on publishing and technical requirements.
Make the route clearer. Keep the useful destination.
Imagine a learning organization with guides that people regularly bookmark. Its resource page groups everything into a long list under internal department names. A visitor looking for a practical guide has to open several pages to work out which one applies. The useful material exists, but the route needs work.
The redesigned concept groups guides by the visitor’s task, adds a short description, and gives the main resource a visible next step. The guide itself keeps its familiar address. This is a design example to explain the decision, not a client result or a claim about conversion improvement.
Keep
- The useful guide and its public address
- Language returning visitors recognize
- The destination of the existing resource link
Change
- Department labels that obscure the task
- The long, undifferentiated resource list
- A next step that is difficult to spot
/resources/getting-started/Keep important routes open.
Visitors arrive through bookmarks, search results, and links from other websites. A new layout should account for those entry points. We include content decisions and URL handling in the redesign plan so a page removed from the menu does not disappear from consideration.
Useful content
Before removing or merging a page, we review its purpose and the information it provides. Important search landing pages deserve particular attention. We compare the proposed content with the existing page so a cleaner layout does not accidentally remove an answer people came to find.
Public addresses
Keep existing URLs when they still make sense. If a page moves permanently, map its old address to the most relevant replacement and test the redirect. Update internal links and check canonical tags and indexing settings. A retired page with no suitable replacement needs its own decision.
Working connections
An inquiry should reach the intended team after the redesign. We document the forms and connected systems within the agreed scope, then test delivery and tracking in the new experience. Access to the relevant accounts and a named owner for each connection help make those checks meaningful.
| Existing URL | Decision | Reason |
|---|---|---|
/resources/getting-started/ | Keep the address | Retain the guide; improve its entry point |
/about/our-services/ | Move to /services/ | Redirect directly to the relevant replacement |
/events/old-workshop/ | Review for retirement | Check its value and whether a replacement exists |
Make launch a decision with evidence.
The redesign needs a transition plan as well as a design approval. We agree on content responsibilities, review checkpoints, and launch ownership in the project scope. Your team should know what is ready, what remains open, and who can respond if an important task stops working.
Review the preview
Use a staging version to review real content and complete priority tasks. Check mobile layouts, keyboard access, and links alongside the visual design. Resolve issues that block essential journeys before approval. Record lower-priority improvements separately so they do not obscure the launch decision.
Control the switch
Plan the content freeze, capture a recoverable version of the existing site, and confirm who handles the release. Test changed URLs and check that the public site can be indexed. Decide the response to a failed launch before the switch, including any content that could change during it.
Check the live experience
After release, repeat the important journeys on the public site and verify agreed forms and tracking. Review errors and search visibility as new pages are processed. Hand over the change record and publishing guidance, with ongoing monitoring or maintenance responsibilities defined in the proposal.
The handover should leave you with
- An agreed content inventory and record of changed URLs
- The approved layouts and reusable components within scope
- Evidence that priority journeys and connections were checked
- Publishing guidance, account ownership, and a support contact
Questions about the site you already have.
Can we keep our current CMS?
Yes, if it can support the agreed design and publishing needs. We review the current setup before recommending a change. A redesign can retain the CMS while updating templates and content. If the platform creates a significant constraint, we can discuss that as a separate workstream with its own requirements.
Will a redesign affect our search rankings?
Search visibility can change when content, structure, or URLs change. We plan around important existing pages and check the technical details of the transition. Rankings cannot be guaranteed to stay unchanged. The practical aim is to reduce avoidable problems and make changes traceable when reviewing performance after launch.
Can we improve the website in phases?
A phased approach can work when each release leaves visitors with a coherent experience. We can prioritize a page type or journey and define how the old and updated areas connect. Shared navigation and content dependencies need review first. The release plan should make each phase useful on its own.
What determines the cost and schedule?
The estimate depends on the existing site’s condition, the number of distinct templates, and the content and functionality that change. Integration testing and URL work also affect scope. We confirm milestones after reviewing those requirements and your approval process. A target date helps us discuss priorities and dependencies.
What should we prepare for the first conversation?
Share your website address and a few examples of what frustrates visitors or your team. Include any launch deadline and the pages or functions that must remain available. You do not need a finished specification. Those details help us discuss the right starting point and identify the access needed for a review.