website migration seo services
Website migration SEO services
The end-to-end engagement: benchmark what you have, map every URL that matters, prove parity on staging, hold the line on launch day, and track recovery against the number you started with.
- Definition
- Website migration SEO services — Website migration SEO services are engagements that protect organic search performance when a site changes domain, platform, URL structure or protocol. The scope is technical: benchmarking current performance, producing a redirect map, verifying crawl parity between the old and new build, monitoring the cutover, and tracking recovery against the pre-migration baseline.
Who this page is for
If you are replatforming, changing domain, restructuring URLs or consolidating two sites, and organic search sends traffic that matters to your business, this is the engagement built for that. Website migration SEO services exist because a migration compresses a year of technical risk into a single release, and the release date is usually set by people who are not thinking about crawl budget.
This is not a growth engagement. It has one measurable objective: the traffic you have before the migration is still there after it.
Why migrations lose traffic even when the plan looked fine
Migrations rarely fail on strategy. They fail on completeness. A redirect map that covers 94% of URLs sounds close to done, and in practice it means the remaining 6% — usually the deep, old, link-heavy pages nobody remembers — return 404s or land on a homepage catch-all.
The pattern repeats across almost every recovery project:
- The URLs that carry the most external links are rarely the URLs with the most traffic, so a map built from a traffic export alone misses them.
- Redirect rules written as patterns look complete until you test individual URLs against them, at which point the exceptions appear.
- Staging QA gets compressed when the build runs late, and parity checking is the first thing dropped because nothing is visibly broken.
- Nobody owns the decision about pages that have no equivalent on the new site, so the decision defaults to a catch-all at the last minute.
Each of these is preventable with a document and a deadline. That is most of what this engagement is.
What we take responsibility for
We own the specification and the verification. Your team owns implementation and the release itself.
That split matters. Handing implementation to an outside party mid-migration adds a handover cost and a communication path exactly when neither can be afforded. Your engineers already know the codebase, the deploy pipeline and the edge configuration. What they usually do not have is someone whose entire job is to know which of the ten thousand URLs actually matter and why.
The technical scope page sets out the crawl, redirect, log and rendering work in more depth. If you want to see the sequencing before talking to anyone, the phase-gated checklist is published in full.
The measurement problem nobody warns you about
Here is the part most migration plans get wrong, and it costs more arguments than it should.
After launch, the instinct is to compare this week’s traffic to last week’s. That comparison is close to meaningless. Google recrawls a site over days to weeks depending on its size and crawl frequency, so the first two weeks of post-launch data mix recrawled pages with pages Google has not looked at yet. Week-over-week movement in that window tells you almost nothing about whether the migration worked.
What does work is a matched cohort comparison: take the specific set of URLs that existed before, follow each to its new destination, and compare performance for that same set of pages before and after. If a URL 301s from A to B, its performance is the performance of B, not the absence of A.
Do that and the picture resolves quickly. Losses concentrate in identifiable cohorts — a template, a section, a set of pages that lost internal links — rather than appearing as a vague site-wide decline nobody can act on.
Working alongside an existing agency
Roughly half of these engagements run alongside an incumbent SEO agency, and the split that works is a clean one. They keep content, links and ongoing strategy. We take migration mechanics until 90 days after launch, then hand back.
What does not work is two parties both making technical recommendations to the same engineering team during the same sprint. Contradictory instructions land on one developer, that developer picks one, and nobody finds out which until something breaks. If your agency already has a named owner for the redirect map and a documented parity process, you may not need this at all — and we will tell you that rather than sell around it.
| Brought in | Still changeable | Already fixed | Realistic outcome |
|---|---|---|---|
| 8+ weeks out | URL structure, information architecture, template markup, rendering approach | Nothing significant | The migration is shaped around search, not repaired afterwards |
| 4–8 weeks out | Redirect map, canonical strategy, sitemap and internal link structure | URL patterns, taxonomy | Full coverage with some compromises where taxonomies do not line up |
| 1–3 weeks out | Redirect completeness, staging QA, launch sequence | Structure, templates, content decisions | Damage prevention rather than optimization |
| After launch | Redirect repairs, indexation fixes, reinstated content | Everything shipped | Recovery of most, though rarely all, of what was lost |
When this engagement fits
- Organic search is a material acquisition channel and a migration is scheduled or under discussion.
- The site has enough URLs that redirect mapping cannot be done by hand in an afternoon.
- There is an engineering team who can implement a specification, in-house or agency.
- Someone on your side owns the traffic number and can make content decisions.
When it does not
- The site gets almost no organic search traffic — the risk being managed is not there.
- You need someone to implement the redirects themselves rather than specify them.
- The migration is a handful of pages on a small brochure site with no external links.
- What you actually want is ongoing SEO growth work, which is a different engagement.
What happens in the first two weeks
The opening phase is deliberately front-loaded. Almost every expensive migration mistake is cheaper to avoid in week one than to repair in month three.
- 01
Access and baseline export
Read-only Search Console, analytics and server logs where available. We export URL-level performance for the last 12 months and freeze it as the benchmark.
Output Dated benchmark dataset
- 02
Full crawl of the current site
Every indexable URL, with status codes, canonicals, meta robots, titles, headings, internal link counts and structured data recorded per URL.
Output Production crawl export
- 03
Priority tiering
URLs ranked by organic clicks, referring domains and revenue where available. This decides what gets one-to-one mapping and what gets rule-based handling.
Output Tiered URL inventory
- 04
Structure review against the new build
The proposed new URL structure compared against the current one, with the mismatches flagged as decisions rather than left to a catch-all rule.
Output Structure findings with named owners
- 05
Risk register and timeline check
What could go wrong given this specific migration, what is already locked, and whether the launch date leaves time for the work that matters.
Output Risk register
Deliverables
What this engagement hands over
-
Discovery
Pre-migration benchmark
The frozen dataset every later comparison is made against: URL-level clicks and impressions for 12 months, indexable URL inventory, and the crawl state on a specific date.
-
Pre-launch
Redirect map
One row per old URL with destination, status code, priority tier and a reason wherever the mapping is not one-to-one. Delivered as a spreadsheet your engineers implement directly.
-
Staging QA
Crawl parity diff
Staging against production, field by field, with every difference marked fixed, accepted or unresolved before the go/no-go decision.
-
Launch day
Launch runbook
The cutover sequence with owners and timings, including DNS TTL changes, redirect verification, robots and sitemap steps, and the rollback trigger.
-
Recovery
Recovery report
Cohort performance against benchmark at 30, 60 and 90 days, with the remaining issues ranked by traffic at risk rather than by severity label.
Questions people ask before starting
What do website migration SEO services actually include?
Benchmarking current performance at URL level, crawling the existing site, producing a redirect map, reviewing the new URL structure, verifying crawl parity on staging, running the search side of launch day, and tracking recovery for 90 days. The output is documents and decisions your team implements.
How much of our team’s time does this take?
Less than people expect during discovery and more than they expect during staging QA. Budget a few hours a week from whoever owns the content decisions, and a concentrated block of engineering time when the redirect map lands and when parity findings need fixing before launch.
Do you need access to our server logs?
It is valuable but not required. Logs show how crawlers actually spend budget on your site, which no other data source reveals. If they are not accessible, we work from crawl data and Search Console instead and say so explicitly rather than guessing at crawl behavior.
What if the new URL structure is already decided?
That is the common case and it is workable. The engagement shifts from shaping the structure to protecting it: mapping completeness, canonical handling, internal linking and parity QA. We will still flag structural problems, but we will be honest about which ones are worth reopening the decision for.
Can you guarantee we will not lose traffic?
No, and neither can anyone else. Search results are not under any provider's control. What is controllable is whether every URL that earns traffic resolves correctly, whether the new site is crawlable and indexable, and whether problems are caught before launch instead of after.
How is this different from a general SEO retainer?
A retainer is about growth over quarters. This is about protection over a defined window with a fixed deadline. The skills overlap but the working rhythm does not: migration work is front-loaded, deadline-driven, and mostly finished within a few months of launch.
Start with the launch date
Tell us what is changing and when. We will tell you what is realistic in the time available before anyone discusses scope.
- Reply
- Typically within one business day.
- Hours
- Monday to Friday, 9am–6pm US Eastern.
- First call
- Scoping, not a pitch. No deck.