At a glance
The short answer
A redesign needs an inventory before design work and a checked mapping of old pages to new ones before launch. Preserve useful content and URLs, test contact routes and assign responsibility for problems. Preparation reduces avoidable errors, but it cannot guarantee unchanged search rankings.
Decide what actually needs to change
An outdated appearance, a difficult publishing system and an unclear service structure are different problems. For each one, describe how you will recognise an improvement. Examples include a team being able to replace project images, visitors finding the service scope, or an enquiry reliably reaching the right person.
Not every improvement requires a new domain or new URL paths. Separate necessary changes from visual preferences. If several systems must be replaced together, identify dependencies and assign responsibility for every connection. A redesign proposal should distinguish content transfer, technical migration, new functionality and ongoing support so that essential work does not fall between suppliers.
Assess existing content by purpose and value
Build a shared inventory of existing pages and important downloads. Add available search information, internal links and feedback from sales. A rarely visited page may answer an important question immediately before an order. Visitor counts alone are therefore a poor basis for deciding what to remove.
Our suggested approach is to give every row an editorial decision, an owner and a review status. This keeps unresolved content visible before the publication deadline instead of leaving it for someone to discover afterwards.
| Field | Example decision |
|---|---|
| Existing URL | Which page or file is available today? |
| Purpose | Explain an offer, support a decision, show work |
| Action | Retain, revise, combine or remove |
| New URL | Specify the exact destination and language |
| Review | Content approved, technically checked, owner assigned |
Derive redirects from the content decisions
For a permanent URL change, Google recommends permanent server-side redirects; status codes 301 and 308 indicate a permanent move.
Evaluate each destination as a visitor following an old link. Will they find the expected service and essential information? If several old pages become one explanation, that explanation needs to fulfil their shared purpose. Choosing a blanket destination does not resolve an unclear content decision.
Include the mapping as a separate acceptance document. Ask a subject owner to approve the destination and a technical owner to check the actual request. Record exceptions with reasons.
Sources for this section
Align language versions and preferred URLs
Canonical annotations identify preferred URLs; hreflang connects genuine language alternatives through reciprocal references. These annotations serve different purposes.
For German and English websites, the mapping should cover more than the homepages. Check a service, a guide and a project alongside their translated counterparts. A language switch should preserve the visitor's task. If a translation is unfinished, record it as outstanding content rather than treating it as a completed alternative.
Also compare phone numbers, service limitations, forms and contact ownership. Fluent translation is not sufficient when it describes something unavailable in that market.
Sources for this section
Test complete customer journeys before launch
A finished homepage is not a completed acceptance review. Choose tasks customers actually need to perform and work through them on a phone and using a keyboard. Use representative content and a complete test enquiry. Record whether the intended recipient receives the message, rather than merely confirming that a form is visible.
- Find a service through navigation and relevant internal links.
- Follow an old URL to a destination with the right information.
- Open a project and begin a relevant enquiry from it.
- Change language and continue the same task.
- Submit a form, understand the confirmation and check message delivery.
- Document owners, unresolved defects and the publication decision.
Treat publication as a separate work package
Google's move guidance covers preparation, URL mapping, redirects and subsequent monitoring. Temporary ranking changes remain possible.
Agree a launch window when the relevant people are available. The launch record should identify access arrangements, the approved version, known limitations and the person handling corrections. Decide in advance which failures would justify stopping the launch or restoring the previous version.
Check the intended search access for public destination pages. A current sitemap helps communicate URLs but does not guarantee indexing. After publication, recheck the same representative pages. A successful preview review does not establish that the production configuration and delivery work as intended.
Sources for this section
Investigate changes after launch
Compare errors, organic landing pages and qualified enquiries with the recorded baseline. Investigate a decline by affected page, language and time period first. A broken contact route calls for a different response from seasonal demand. Keep the change log and URL inventory available so that the team can distinguish these possibilities.
Define the follow-up scope: who reviews reports, who fixes issues and when are unresolved matters discussed? Published project examples can show design and structure. Establishing that a redesign improved search reach or business results needs additional measurement with an appropriate baseline and a clearly defined outcome.
A closer look
Common questions
Must every URL change during a redesign?
No. Useful, understandable URLs can often remain in place. Change them for a stated purpose and with a checked destination mapping, rather than simply because the design is new.
When is the migration complete?
When the agreed content and customer journeys have been checked, technical issues are being addressed and ongoing monitoring has an assigned owner. The publication date alone does not establish that search engines have finished processing the changes.
Put it into practice
Your next step.
Editorial responsibility: Bissolux. Linked original sources support the provider-specific statements. Examples, priorities and recommendations are our editorial assessment. Features and policies may change after the review date.
All guides