A website redesign should begin with a record of what the current site does well. Search entry pages, useful content, existing links and working inquiry paths are business assets, even when the design looks dated.
Before I plan the new site, I identify what the existing one must not lose. Preservation and migration are part of the build, not cleanup after launch.
You cannot guarantee a redesign without ranking fluctuations. You can reduce avoidable risk by defining what will change, preserving useful information and assigning responsibility for launch checks before development begins.
The most expensive mistake is treating SEO as a finishing task after the new page structure has already been approved.
Decide whether you need a rebuild at all
An unclear service description, a broken form or weak evidence does not automatically require a new platform. A focused content or conversion project may address the problem more quickly.
Ask the project sponsor to complete this sentence: “The current website prevents us from doing , and the new website must allow us to do .”
Good answers name a capability: publishing service-specific content, maintaining a product catalog, routing inquiries or supporting a multilingual customer journey. “It needs to look more modern” can be a valid design goal, but it is not a complete commercial brief.
If the main uncertainty is whether the site is losing suitable customers, consider a conversion review before committing to a rebuild.
Make a preservation list, not just a new sitemap
Before planning new pages, identify the information and functionality that should survive the project.
For each important existing page, record its current purpose, relevant search queries, useful traffic, inquiry contribution where known, external links and associated downloads or forms. Also capture the content owner and any accuracy concerns.
Do not equate low measured traffic with no value. An infrequently visited technical page may help an important buyer complete due diligence. A page with many visits may attract an audience you do not serve.
Use the evidence to choose a treatment:
| Existing asset | Possible treatment | Approval question |
|---|---|---|
| Useful service page with a clear purpose | Preserve and improve | What genuinely needs to change? |
| Two overlapping pages | Consider consolidation | Does the combined page satisfy both audiences? |
| Outdated offer | Rewrite or retire | What should a previous visitor see instead? |
| Technical resource used by buyers | Preserve with an accountable owner | Is the information still valid? |
| Working contact path | Retain or replace with a tested equivalent | Who confirms delivery and routing? |
This table is a planning framework, not an instruction to preserve every old page forever.
Separate URL changes from visual changes
A new visual design does not inherently require new URLs. Ask why each proposed address change is necessary before adding migration work.
Where URLs do change, Google's site-move guidance recommends a mapping between old and new destinations and testing the move. Keep that mapping as an explicit deliverable rather than relying on someone to remember it during launch.
For permanently moved pages, Google's redirect guidance explains permanent redirects. Send users to the relevant replacement, not an unrelated destination. A deleted specialist article does not become meaningfully replaced by the homepage simply because the homepage exists.
Assign an owner to resolve uncertain mappings. The developer can implement the rule, but the business and content owner must decide what represents a valid replacement.
Turn requirements into acceptance tests
A project is easier to control when “SEO included” becomes a list of observable checks.
Examples of acceptance criteria include:
- A priority service is reachable through the intended navigation and contextual links.
- Its content still answers the approved buyer questions.
- Its title and description can be maintained by the content owner.
- Approved URL changes lead to the intended pages.
- The production site does not retain unintended staging restrictions.
- The intended inquiry route works on the agreed devices and delivers to the right team.
- Analytics distinguishes a successful request from a button click.
Canonical declarations should match the intended preferred pages. Google's canonicalization documentation describes how those signals are used; a canonical is not a universal repair for unrelated missing or merged content.
Keep technical acceptance separate from commercial success. Passing a redirect test proves the redirect works. It does not prove the new offer will attract more clients.
Put content ownership into the project plan
Redesigns often stall because the team approves layouts before anyone owns the words, product details or evidence required to fill them.
Agree who will supply and approve service scope, staff credentials, project examples, product specifications and legal or professional disclosures where applicable. Give those approvals dates that precede final QA.
Do not launch empty replacement pages simply because the visual design is complete. If a section is not ready, decide explicitly whether its existing version can remain available or whether launch should be staged.
For specialist services, the person approving marketing copy may not be qualified to approve technical or professional claims. Name the appropriate reviewer.
Organize launch around business continuity
Choose a release window when the team can monitor the site and respond. Identify who has authority to delay launch, resolve urgent issues and approve a rollback.
Have the agreed backups and rollback procedure tested by the technical owner. Include the content and integration state, not just the visual code. A rollback that restores the homepage but breaks the inquiry destination does not restore the customer journey.
Avoid changing the platform, offer, tracking definitions and every acquisition campaign at once unless the project requires it. Multiple simultaneous changes make commercial interpretation harder, even if each change is individually reasonable.
Review the launch at three levels
Functionality: Are pages available, customer actions working and requests reaching the correct destination?
Search continuity: Are important pages being discovered and indexed as intended? Investigate unexpected exclusions, missing destinations and material changes in relevant query coverage using Search Console and your crawl records.
Commercial behavior: Are suitable prospects progressing through the new journey? Compare equivalent traffic segments and account for seasonality, campaign changes and the length of the sales cycle.
A temporary movement in ranking is not by itself proof that the redesign failed. A persistent disappearance of a valuable service page deserves a different investigation from a change in broad informational traffic.
What should a redesign proposal include?
Look for a business brief, page plan, preservation and migration responsibilities, content ownership, testing criteria and handover. Agree ongoing support and integration work separately where necessary.
Explore conversion-focused website development and SEO strategy consulting. If you are planning a rebuild, send the current site and the capability you need to improve. That creates a more useful starting point than selecting a platform before defining the problem.
Continue the analysis
- Website Development for Professional Services: Plan the Client Journey
- SEO for Service Businesses: Build Demand for the Work You Want
- Conversion Rate Optimization Consultant: Audit, Test or Redesign?
Common questions
Does changing the design always hurt SEO?
No. The outcome depends on what changes and how the transition is handled. Avoid promising either an automatic improvement or a loss-free migration.
Should every old page redirect to the homepage?
No. Decide the appropriate treatment for each important URL. Relevant replacements and justified retirements require different handling.
