Decide what is changing
A visual refresh with unchanged URLs is different from a new domain, rewritten catalogue or replacement CMS. We identify changes to URLs, content, templates, navigation, tracking and infrastructure before treating the project as a standard migration.
The SEO work should begin while the new structure is still being planned. Once important content has disappeared from the build, repairing the consequences is usually harder than preventing them.
Build the migration inventory
We combine the available crawl, sitemaps, search data, analytics and relevant link information to understand the current site. Each important URL needs a clear decision: retain, move, consolidate or intentionally retire.
A redirect map should connect an old page to the closest appropriate destination. Sending every retired URL to the homepage avoids neither customer confusion nor the need for a meaningful content decision.
Check the new website before launch
- Important content and customer journeys remain available.
- Titles, headings, canonical URLs and internal links use the intended destinations.
- Language versions and structured data still describe the right pages.
- Redirect rules work without unnecessary chains.
- Staging restrictions will not accidentally remain on the public release.
- Analytics and enquiry, booking or purchase measurement work in the new journey.
Give launch a clear owner
We agree who changes redirects, deploys the site, verifies critical journeys and decides whether a fault justifies rollback. The launch checklist should be specific enough to use under pressure, including access and dependencies on hosting, developers or booking providers.
Where practical, separating major changes can make diagnosis easier. A simultaneous domain move, redesign, content rewrite and tracking replacement creates more uncertainty than a controlled sequence.
Monitor and resolve after the move
Post-launch work checks real responses, redirect behaviour, missing pages and measurement, then follows the available search evidence as the new URLs are processed. Some fluctuation may occur; nobody can promise a migration with no search impact.
We record changes and exceptions so the team can distinguish an expected transition from a release fault. Send the old site, proposed structure, staging access and planned launch date early enough for findings to influence the build.
Include the business owner in launch decisions so technical completion does not obscure an interrupted customer journey.
Common questions
Do unchanged URLs eliminate migration risk?
They reduce one source of change, but content, rendering, navigation and tracking can still change. The acceptance checks should cover the actual release.
Should old content be deleted?
Not simply because it is old. Assess usefulness, search demand, links and the current business purpose before deciding what to retain or consolidate.
Can you work alongside the new website developer?
Yes. The migration plan should be part of their build and release requirements, with named owners for implementation and validation.