Search risk begins before launch
Most migration failures are not caused by one missing redirect. They happen because search requirements arrive after the design, platform and content decisions have already been made. The safest projects establish what must be preserved, what will intentionally change and how the team will recognise a problem.
I join at the stage where I can still influence requirements. If the project is already moving, I identify the highest-risk gaps and help the team concentrate effort where it can still change the outcome.
A migration baseline that makes later comparisons meaningful
Before launch, we capture the state of the current site. The baseline normally groups URLs by commercial role, template and search demand so that changes can be assessed at a useful level. Rankings alone are not enough; the evidence can also include crawlability, indexation, internal linking, traffic, conversions and server behaviour.
That baseline becomes the reference for launch monitoring. It helps distinguish a genuine migration issue from seasonality, reporting changes or unrelated market movement.
Requirements, staging QA and launch control
The work covers the relationships that search engines need to follow: URLs, redirects, canonicals, hreflang, navigation, structured data, sitemaps, robots controls and rendered content. Checks are prioritised around important templates and journeys rather than treating every URL as equally valuable.
- Requirements agreed with product, design, content and engineering
- URL mapping rules with exceptions reviewed deliberately
- Staging access and crawl controls checked without leaking test URLs
- Template comparisons across old and new versions
- Launch checklist with owners, timings and rollback decisions
- Post-launch crawl, redirect, indexation and performance monitoring
Support proportionate to the change
A small redesign may need a review at a few decisive points. A large replatforming may require ongoing involvement across discovery, requirements, delivery, launch and recovery. I shape the engagement around the risk and the delivery team rather than imposing a fixed audit template.
What you receive
- Current-site benchmark covering rankings, traffic, indexation and priority page groups
- Risk register and SEO requirements for the proposed design or platform
- URL inventory, mapping logic and redirect validation
- Staging reviews for templates, rendering, metadata, canonicals and crawl controls
- Launch-day checks and an agreed escalation process
- Post-launch monitoring with comparisons against the baseline
What the work is designed to change
- SEO requirements enter the project before expensive decisions are fixed
- Teams know which URLs, templates and signals matter most
- Launch issues are found quickly and assigned clearly
- Performance is judged against an agreed baseline rather than memory
Common questions
When should SEO become involved in a website migration?+
Before the information architecture, URL structure, platform behaviour and content scope are fixed. Early involvement is normally cheaper and creates more options than correcting avoidable problems after launch.
Can you review an existing migration plan?+
Yes. I can provide an independent risk review, identify missing requirements and help prioritise the remaining work even when delivery is already underway.
Do you stay involved after launch?+
Yes. Post-launch validation is part of responsible migration support. The duration depends on the site and the risks, but the team should know what will be checked, how often and what would trigger action.