A clear engagement from the start
Choose an independent migration review or support across the full migration. The proposal identifies the domains, templates, markets and release milestones covered.
Timing and delivery
Aligned to your delivery milestones. A plan review can be a standalone engagement; full support runs from baseline and requirements through an agreed post-launch validation window.
You work directly with Rob alongside your nominated lead and implementation specialists. Your written scope sets the remote meeting schedule, review points and handover, so everyone knows what to expect.
How the work runs
Establish what must survive
Inventory URLs, valuable landing pages, templates, search demand and reporting. Agree the baseline and identify the changes that could affect acquisition.
You receive: Baseline, priority URL groups and migration risk register.
Set requirements with the delivery team
Review information architecture, content decisions, URL changes, redirects, canonicals, international relationships and rendering. Give design and engineering clear acceptance criteria.
You receive: SEO requirements, mapping rules and named decision owners.
Review staging and launch readiness
Test representative journeys and templates, validate mapping exceptions and document unresolved issues. Provide an evidence-based SEO launch recommendation to the release owner.
You receive: Staging findings and a launch checklist with escalation responsibilities.
Validate the release
Check the live implementation, triage unexpected behaviour and compare agreed page groups against the baseline. Review reporting continuity before attributing performance changes.
You receive: Launch validation, issue log and post-launch handover.
Inside your delivery pack
Baseline and risk register
A record of the current site and the changes that could affect search, organised by template, page group and business priority.
Requirements your developers can use
Examples, expected behaviour and test criteria for URL mapping, redirects, crawl controls, rendering, canonicals and relevant international signals.
Staging and launch evidence
Review findings with severity, owners and launch implications, plus an agreed process for exceptions and escalation.
Post-launch validation
Checks and comparisons over the agreed window, with findings handed to your team and any further investigation scoped explicitly.
A launch decision your team can act on
Illustrative staging finding for a fictional ecommerce migration, not a reported client outcome.
- Finding
- A priority category URL redirects to the homepage instead of its agreed replacement.
- Evidence
- Old URL, expected destination, actual response chain, mapping row and the affected page group.
- Owner and action
- Engineering corrects the mapping rule; the content owner confirms that the destination satisfies the same customer need.
- Acceptance criteria
- The old URL reaches the approved, indexable destination without a loop or unnecessary chain. Relevant links and canonical signals agree.
- Release decision
- Retest affected mappings and record the remaining risk for the release owner before sign-off.
What your team needs to provide
- A project owner and a confirmed or provisional release plan.
- Access to the existing site, staging environment, URL inventories and available analytics.
- A development team responsible for code, redirects, hosting and deployment.
- Content and design owners able to resolve requirements before launch.
Scope and responsibilities
- Your release owner makes the launch and rollback decisions; I advise on SEO readiness.
- Website design, development and deployment are delivered by your team unless separately agreed.
- Launch attendance, out-of-hours availability and the monitoring window must be booked explicitly.
- A migration can experience search volatility. The work reduces avoidable risk and helps identify issues; it cannot guarantee unchanged traffic.
We confirm review rounds and the clarification window in the proposal. If requirements change, we agree the effect on fees and delivery dates before additional work begins.
Scope, fee and next steps
Pricing follows the migration scope and the stages you need. Domain count, URL and template complexity, languages, staging access, delivery schedule and post-launch coverage affect the quote. An independent review can be scoped separately from full delivery support.
Share your website, what you need to decide and your preferred timing. Include an indicative budget if you have one. You will get a reply within one working day to explore the fit, then an agreed scope and fee before any work starts.
Planning a major website change?
Use the website change guide collection to identify the decisions, owners and tests your project needs, from a CMS replacement to a multi-site consolidation.
When your migration changes existing URLs, test the redirect map before launch to check each old address against its intended destination.
Search risk begins before launch
By the time your new site reaches staging, decisions about content, navigation and platform behaviour may already be expensive to revisit. Bringing SEO into planning helps you identify what must be preserved, what can change and how your team will recognise a problem.
Already underway? You can still get a review of the highest-risk gaps and a priority list for the time you have left. Your team gets a clear view of the evidence, unresolved issues and decisions needed before launch.
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
Your small redesign may need a review at a few key milestones. A large replatforming may need support from discovery through launch and validation. You agree coverage around the scale of the change, your delivery team and the risks involved.
What this helps you achieve
- 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.