Technical SEO for website migrations · United States
SEO migration services that protect the traffic you already have
We work with US companies replatforming, changing domains or restructuring URLs, and our job is narrow: make sure the search traffic you have today is still there the week after launch.
- The first conversation is a scoping call. No deck, no proposal until we both know the scope.
- We work alongside your existing developers and agency rather than replacing them.
- If your migration already happened and traffic dropped, that is a different engagement — say so and we will start there.
- Definition
- SEO migration services — SEO migration services are specialist technical engagements that protect organic search traffic when a website changes address, platform or structure. The work covers redirect mapping, crawl parity checks between the old and new site, staging QA, launch-day monitoring and post-launch recovery tracking against a pre-migration benchmark.
The failure modes
What actually goes wrong during a migration
Migrations rarely fail because someone forgot SEO existed. They fail in specific, repeatable mechanical ways, usually in the last two weeks before launch when the schedule tightens and QA gets compressed. These are the five that account for most of the damage we are called in to reverse.
-
Failure 01
Unmapped URLs redirect to the homepage
When a URL has no counterpart on the new site, the fastest fix is a catch-all rule pointing everything to `/`. Google treats a redirect to an irrelevant page as a soft 404, so the old URL loses its rankings and the homepage gains nothing. A single catch-all rule can silently erase years of accumulated link equity across thousands of URLs.
A redirect only passes signals when the destination is a close content match. Homepage catch-alls are treated as soft 404s.
-
Failure 02
Redirect chains stack up during staging
Old URL redirects to interim URL redirects to new URL redirects to the trailing-slash variant. Googlebot follows up to ten hops in a chain before giving up, so a four-hop chain still resolves — but every hop costs crawl budget, adds latency for real users, and gives more places for a rule to break later.
Googlebot follows up to 10 redirect hops. Aim for exactly one, and never ship more than two.
-
Failure 03
Index bloat arrives with the new platform
Replatforming often introduces faceted URLs, pagination parameters, session IDs or tag archives that the old site never had. The crawler spends its budget on near-duplicates instead of the pages that earn money, and the new site looks thinner to Google than the old one despite having more content.
Compare indexable URL counts before and after. A large unexplained increase is index bloat, not growth.
-
Failure 04
Content that used to be in the HTML is now rendered by JavaScript
Moving from a server-rendered CMS to a JavaScript framework can move body copy, internal links and canonical tags out of the initial HTML response. Google will usually render it eventually, but rendering is queued and not guaranteed, and internal links that only exist after hydration are discovered slowly if at all.
View source, not inspect element. If the copy and the internal links are not in the raw HTML, treat discovery as a risk.
-
Failure 05
Staging gets indexed, or production inherits staging directives
Two versions of the same failure. Either the staging site was linked from somewhere and got indexed as a duplicate, or the `noindex` header that protected staging shipped to production with the release. The second one is the more expensive: a site-wide `noindex` on launch day can deindex a site within days.
robots.txt Disallow does not prevent indexing of a linked URL. Protect staging with HTTP authentication instead.
Scope
What we take responsibility for
-
Website migration SEO services
The full engagement, from pre-migration benchmarking through to 90-day recovery tracking. This is the one most companies need.
website migration seo services -
Technical SEO migration services
Crawl parity, redirect architecture, log-file analysis, rendering checks and indexation control — the technical scope written out in full.
technical seo migration services -
Choosing an SEO migration agency
For buyers comparing providers: engagement models, what to look for, and the questions that separate real process from a deck.
seo migration agency -
Working with an SEO migration consultant
Solo-expert engagement: direct access, advisory retainer options, and what a consultant-led migration looks like week to week.
website migration seo consultant -
SaaS SEO migration services
Docs subdomains, subfolder consolidation, product-led URL sprawl and the long-tail traffic that SaaS sites quietly depend on.
saas seo migration services -
SEO migration audit
Productized pre-launch and post-launch audits. Fixed scope, findings ranked by traffic at risk, no retainer attached.
seo website migration audits -
SEO tool migration
Moving rank tracking, backlink monitoring and reporting between platforms without breaking year-over-year comparability.
seo tool migration -
Moz to Semrush: what transfers and what does not
What carries across between Moz and Semrush, which metrics are not comparable, and the SEOmoz naming question answered honestly.
moz to seomoz migration
Process
How a migration engagement runs
Five phases, run in order, each with a condition that has to be true before the next one starts. The order matters: benchmarking after launch tells you nothing, and a redirect map written after the URL structure is locked is a much harder document to produce.
- 01
Discovery and benchmarking
6–10 weeks before launchEstablish what "no loss" means in numbers before anything changes. We export Search Console performance at URL level, crawl the current site in full, pull server logs if they are available, and record the indexable URL inventory. This becomes the baseline every later measurement is compared against.
Gate A frozen benchmark: URL inventory, clicks and impressions per URL, and the current crawl state, all dated.
- 02
Crawl parity and redirect mapping
4–8 weeks before launchMap every old URL that matters to exactly one new URL. Priority comes from organic clicks, referring domains and revenue, not from the CMS's page tree. Where no equivalent page exists on the new site, that becomes a content decision with a deadline rather than a redirect rule invented at the last minute.
Gate A reviewed redirect map covering every URL with organic clicks or external links in the last 12 months.
- 03
Staging QA
1–3 weeks before launchCrawl the staging site behind authentication and diff it against the production crawl: titles, headings, canonicals, meta robots, internal link counts, structured data, hreflang. The diff finds the things nobody thought to test, which is usually where the damage is.
Gate A parity diff with every unexplained difference either fixed or accepted in writing.
- 04
Launch day
Cutover windowDNS TTL lowered in advance, redirects verified against the live host as soon as it resolves, robots.txt and meta robots checked on production, sitemaps resubmitted, and Change of Address filed if the domain changed. This is a monitoring shift, not a strategy session.
Gate A sampled redirect test passing on the live host, and no accidental noindex or Disallow in production.
- 05
Recovery tracking
30 / 60 / 90 days after launchCompare performance against the frozen benchmark on a matched cohort of URLs, not week over week. Watch Googlebot's hit distribution shift from old URLs to new ones in the logs. Fix what the data surfaces: chains introduced by later releases, pages that lost internal links, templates that lost their canonical.
Gate Googlebot requests predominantly hitting new URLs, and cohort performance back within the pre-migration range.
Have a launch date already?
Send it over with what is changing. We will tell you what is realistic in the time left, before anyone talks about scope or fees.
- Reply
- Typically within one business day.
- Hours
- Monday to Friday, 9am–6pm US Eastern.
- First call
- Scoping, not a pitch. No deck.
Cluster
Which kind of migration are you running?
Every migration type fails in its own way. Each of these covers the specific risks, the sequence that works, and what to check before launch.
- Domain name change Every historical signal has to be forwarded at once, with no partial credit for near-complete coverage.
- HTTP to HTTPS Four reachable host variants competing as duplicates, with the canonical decided by inference rather than by you.
- URL structure change Old and new taxonomies rarely reconcile, and every unresolved mismatch defaults to a catch-all rule at the last minute.
- Subdomain to subfolder Every URL on the subdomain changes host at once, and the routing layer becomes a shared dependency between two platforms.
- Site consolidation Two sets of pages ranking for overlapping topics must become one, and every merge decision permanently discards something.
- Replatform / CMS move Templates, markup, rendering and internal linking all change at once while everyone focuses on the URLs that did not.
- WordPress to headless Yoast or RankMath still shows green in the admin while producing no output at all on the live front end.
- Shopify migration The platform dictates URL paths, so every product and category URL changes even when nobody planned a restructure.
- International and hreflang One broken URL in an hreflang cluster invalidates the annotations for every language version in that cluster.
- Design refresh Everything that carried ranking signals lives in templates, and a redesign rebuilds every template at once.
| Migration type | Primary risk | What matters most | Typical volatility window |
|---|---|---|---|
| Domain name change | Every URL changes host at once; historical signals must be forwarded | Complete redirect map plus Change of Address | 4–12 weeks |
| Replatform, URLs unchanged | Templates change; rendering, markup and internal links change with them | Crawl parity diff between staging and production | 2–6 weeks |
| URL structure change | Mapping ambiguity where old and new taxonomies do not line up | One-to-one mapping decisions with named owners | 4–10 weeks |
| HTTP to HTTPS | Mixed content, canonical drift and duplicate host variants | Single canonical host enforced at the edge | 1–4 weeks |
| Site consolidation | Two ranking sets merging into one; keyword cannibalization | Consolidation plan that decides which page wins each topic | 8–16 weeks |
| Subdomain to subfolder | Path-based routing, caching and analytics all change at once | Reverse proxy configuration and a clean redirect layer | 4–12 weeks |
Deliverables
What you actually receive
Named artifacts, not a monthly report. Everything here is a file or a dashboard your team keeps and can act on without us in the room.
-
Pre-launch
Redirect map
One row per old URL: destination, status code, priority tier, and the reason where the mapping is not one-to-one. Handed over as a spreadsheet your engineers can implement directly.
-
Staging QA
Crawl parity diff
A field-by-field comparison of staging against production — titles, canonicals, meta robots, headings, internal link counts, structured data — with every difference marked fixed, accepted or unresolved.
-
Discovery
Log-file analysis
How crawlers currently spend their budget on your site, which sections they ignore, and where the new structure will change that. Requires server log access; we will tell you early if it is not available.
-
Launch day
Launch runbook
The cutover sequence with owners and timings: DNS TTL changes, redirect verification, robots.txt checks, sitemap resubmission, Change of Address filing, and the rollback trigger.
-
Discovery
Pre-migration benchmark
The frozen dataset every later comparison is made against — URL-level clicks and impressions, indexable URL inventory, and the crawl state on a specific date.
-
Recovery
Post-launch monitoring dashboard
Cohort performance against benchmark at 30, 60 and 90 days, redirect health, indexation counts and Googlebot hit distribution across old and new URLs.
Do this yourself
Run this before you hire anyone
You can assess most of your own migration risk in an afternoon with tools you already have. Do this first. It will tell you whether you need help, and it will make any conversation you have with a provider substantially more useful.
- Export your top URLs by clicks In Search Console, open Performance, set the date range to the last 12 months, switch to the Pages tab and export. Take the URLs that make up the top 80% of clicks — usually far fewer pages than people expect.
- Add the URLs with external links Pull the pages on your site with the most referring domains from any backlink tool. These often have almost no organic clicks and are therefore missing from step one, but they carry the equity that keeps the rest of the site ranking.
- Check each one against the new structure For every URL in the combined list, name its destination on the new site. Not a rule that might cover it — the specific destination. Count how many you cannot answer.
- Test the redirects that already exist Run the same list through a bulk redirect checker against staging or the live site. Record the final status code and the number of hops for each. Anything that is not a single hop to a 200 is a finding.
Reading the result If you can name a destination for every URL and every test returns one hop to a 200, your migration risk is mostly operational and you may not need outside help. If more than about 10% of that list has no named destination, the redirect map does not exist yet, and the launch date is the wrong thing to be discussing.
Who this is for
This is a specialist engagement, not a general SEO retainer. It fits companies where organic search is a material channel and a migration is already scheduled or under discussion — typically a marketing lead who owns the traffic number working with an engineering team who owns the release.
The common pattern is that the replatform has a business case behind it, the timeline is fixed, and nobody in the room has run a migration of this size before. That is a reasonable position to be in. It becomes an expensive one when the SEO conversation starts after the URL structure is already built.
Working alongside your existing team
We do not replace your developers, your agency or your in-house SEO. The work produces documents and decisions that your team implements — a redirect map your engineers ship, a parity diff your QA process absorbs, a runbook your release manager owns on cutover day.
Where there is already an agency in place, the split that works is usually clean: they keep content, links and ongoing strategy, and we take the migration mechanics for the duration. Two teams doing technical SEO on the same site during a migration is how contradictory instructions reach the same engineer in the same week.
Straight answers
The questions people hesitate to ask
We are launching in three weeks. Is it too late?
No, but the scope changes. Three weeks out, the useful work is a redirect map for the URLs that carry your traffic and links, a staging parity check, and a launch-day runbook. Deep structural recommendations are not actionable at that point, and pretending otherwise wastes your money. Say the date up front and we will tell you what is realistic.
Should we hire an agency or a consultant for this?
It depends on how much of the work your team can absorb. An agency makes sense when you need implementation capacity as well as direction. A consultant makes sense when you have engineers who can ship and need someone accountable for the specification and the QA. Migration work is heavier on judgment than on hours, which is why it suits consultant-shaped engagements more often than people expect.
We already have an SEO agency. Why would we need this?
Often you do not. Ask your current agency two questions: who is producing the redirect map, and what is the crawl parity process before launch. If both have clear answers with named owners, you are covered. If the answer is that they will "review the site after launch", that is a monitoring arrangement, not migration coverage.
We already migrated and traffic dropped. Can this be fixed?
Usually yes, and usually more of it than people expect. Recovery work starts with a forensic pass — what changed, which URL cohorts lost visibility, and whether the losses track redirect failures, indexation changes or a genuine content reduction. That is a different engagement from a pre-launch one and it starts with a diagnosis, not a plan.
Our developers say the redirects are handled.
They may well be. The question is not whether redirect rules exist, but whether every URL that earns traffic resolves in one hop to a relevant page. Take a hundred URLs from your Search Console export, run them through a bulk checker against staging, and count the exceptions. That test takes twenty minutes and settles the question either way.
What you can check before hiring anyone
There are no client logos on this page. Named references and outcome data are shared under NDA on request, and only where the client has agreed in writing. What you can assess in the meantime is the method: the full pre-launch checklist is published, the phase structure states its exit criteria, and the engagement shape and minimum useful scope are written down rather than quoted on a call.
Ask any migration provider for the same three things. A provider who cannot show you a redirect-mapping method before you sign will not produce one after.
Questions people ask before starting
What are SEO migration services?
SEO migration services are specialist engagements that protect organic search traffic when a site changes domain, platform or URL structure. The work is technical rather than editorial: benchmarking current performance, mapping redirects, checking crawl parity between old and new, monitoring the launch and tracking recovery against the pre-migration baseline.
When should we bring in migration SEO support?
Before the new URL structure is finalized, which is usually six to ten weeks before launch. That is the last point at which structural recommendations are still cheap to act on. After the structure is locked, the work shifts from shaping the migration to protecting it, which is still valuable but narrower.
How long does organic traffic take to recover after a migration?
For a well-executed migration, expect volatility for two to six weeks and a return to the previous range within one to three months. Domain changes and consolidations sit at the longer end. Recovery timelines depend on site size, crawl frequency and how completely the redirect map covers URLs that earned links.
Will we lose rankings during the migration?
Some short-term movement is normal even when everything is done correctly, because Google has to recrawl and reprocess the site at its own pace. What is avoidable is permanent loss, which almost always traces back to unmapped URLs, redirect chains, accidental noindex directives or content that quietly disappeared in the move.
Do you work with our developers or replace them?
We work with them. The deliverables are specifications, maps and QA passes that your engineering team implements as part of the release. Replacing a team that already knows the codebase mid-migration adds risk rather than removing it, and the handover cost is rarely worth it.
What is a redirect map and why does it matter so much?
A redirect map is a row-per-URL document stating where each old URL goes on the new site, what status code is used and why. It matters because it is the only artifact that makes redirect coverage checkable. Without one, nobody can answer whether a specific URL was handled — including the person who wrote the rules.
Can you help if the migration already happened?
Yes. Post-migration recovery is a substantial part of this work. It starts with a forensic comparison of before and after at URL level to separate redirect failures from indexation problems and from genuine content loss, because those three have completely different fixes and are easy to confuse.
Do you handle international sites and hreflang?
Yes. International migrations carry extra failure modes: hreflang annotations that point at redirected or missing URLs, return-tag mismatches, and country subfolders that get consolidated without a plan. These need checking as part of the parity diff, not as an afterthought once the launch is done.
Is SEO tool migration the same thing?
No, and it is worth separating them. Website migration means the site itself moves. SEO tool migration means moving your rank tracking, backlink monitoring and reporting from one platform to another, where the problem is data portability and metric comparability rather than search visibility.
What do you need from us to get started?
Read-only access to Google Search Console, an export of the current URL inventory or permission to crawl the site, the proposed new URL structure if it exists, and the launch date. Server log access is valuable where it is available but is not a requirement to start.
Tell us the launch date
Start with the date and what is changing. We will tell you what is realistic in the time available, and whether you need this at all — sometimes the honest answer is that your team has it covered and you only need a second pair of eyes on the redirect map.
- Reply
- Typically within one business day.
- Hours
- Monday to Friday, 9am–6pm US Eastern.
- First call
- Scoping, not a pitch. No deck.