Cluster index
Migration types we handle
Every migration type fails in its own way. Find the one you are running — each page covers the specific risks, the sequence that works, and what to verify 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.
Not sure which one you are running?
Most real migrations are two or three of these at once — a replatform that also changes URLs, or a domain change bundled with a design refresh. Describe the move and we will tell you which risks stack.
- Reply
- Typically within one business day.
- Hours
- Monday to Friday, 9am–6pm US Eastern.
- First call
- Scoping, not a pitch. No deck.