A website migration is a signal-preservation problem. Every URL, internal link, and schema block is a signal earned over time, and the migration's job is to move them intact, not just to redirect them. Run a four-phase discipline: audit, redirect map and IA decisions, build and cutover, post-launch monitoring. Powered by behavioral intelligence so the move ships as a measurement layer, not a rank gamble.
What is website migration SEO?
Website migration SEO is the discipline of moving a site -- a domain change, platform swap, information architecture reorg, or HTTPS migration -- without losing the rank, AI citations, and pipeline the old site earned. It is not a rebuild. A rebuild re-engineers the foundation; a migration moves an existing foundation to a new address. The two engagements share preservation mechanics, but a migration is the narrower (and far more frequent) case: the content and structure are mostly fine, the location has to change.
The reason the distinction matters: most rank loss after a site move is not bad luck. It is the predictable result of breaking signals that earned the rank in the first place. Search engines and AI engines treat your URLs, internal link graph, schema blocks, and content depth as a layered set of trust signals. A clean migration preserves each layer. A sloppy one severs them and waits for ranking to come back, which it usually does not, at least not at the level it was.
Most migration content treats the work as a checklist. Pressfit.ai treats it as a signal-preservation problem. Every URL, every internal link, every schema block, every dateModified stamp is a signal earned over time. The migration's job is to move those signals intact -- not just to point a 301 at the new URL and hope.
Migration vs rebuild: which problem do you actually have?
Before you plan a migration, confirm a migration is what you need. The two engagements look similar from a project plan but solve different problems.
A migration is the right scope when the existing site converts and ranks, but it has to live somewhere else: a new domain after a brand change, a new CMS because the current one blocks the team, an HTTPS upgrade, or an IA (information architecture) reorg that consolidates clusters without re-engineering the templates. The content depth is fine. The schema is fine. The instrumentation is fine. The location has to change.
A rebuild is the right scope when the foundation is the problem. If the IA cannot hold the content the category demands, the CMS blocks the content team, AI search visibility is dropping with no schema or semantic structure, or there is no behavioral instrumentation to read what buyers do, the site has a foundation problem. A migration on top of a broken foundation prettifies the leak. For that case, read our B2B website rebuild guide -- it covers when to rebuild, what to preserve, and how to lock in AEO and GEO architecture from day one.
The triage is not abstract. About 70% of clients who arrive asking for a rebuild are actually asking for a migration plus a content depth pass. The other 30% genuinely need to re-engineer the foundation. If the diagnostic points at preservation, this guide is the right scope. If it points at foundation, the rebuild guide is. The two pieces are sister documents on purpose -- they cover adjacent problems, not the same one.
The four-phase migration runbook
A migration runs in four phases. Each one has a deliverable that gates the next. Skipping a phase is how migrations tank rank.
1. Audit
The first phase is diagnostic. Pull the full URL inventory of the current site. For every URL, capture: organic rank for the queries it earns impressions on, AI search citations across AI Overviews, ChatGPT, Claude, Gemini, and Perplexity, page-level traffic, conversion data, internal link count and anchor patterns, backlinks, schema present on the page, and content depth. The audit output is a single inventory document that lists every URL and what it is doing. A URL with no traffic, no links, and no role in the new IA is a candidate for retirement. A URL with rankings or citations is a candidate for preservation. Nothing moves until the inventory is complete. Behavioral intelligence enters here -- the migration scope is sized against what buyer behavior tells you the site actually does, not against what the team assumes.
2. Redirect map and IA decisions
Phase two converts the audit into structure. Three decisions get made for every URL: preserve, redirect, or retire. Preserve the URLs that earn rank, links, or citations -- keep their slugs, ideally with the same path depth on the new domain or platform. Redirect the URLs that have to move because the new IA is cleaner; map every old path to its closest content match with a page-level 301. Retire the URLs with no traffic, no links, and no role in the new IA, but only after confirming nothing depends on them. Google's Site Moves with URL changes documentation is the load-bearing reference for the redirect mechanics. The deliverables are the URL preservation map, the redirect map, and the new sitemap. This is also where the schema strategy is locked: which page types ship which JSON-LD, and which old schema blocks have to ship intact on the new templates.
3. Build and cutover
Phase three is the engineering work. Templates are built or migrated. Schema is injected at the template level so every page of a given type ships with correct JSON-LD by default -- not as a per-page polish task that can be missed. Content moves with depth preserved: if a page ranked because it had 1,800 words of substantive answer, it ships with at least that depth on the new platform. The internal link graph is rebuilt to match the new IA without losing the topical clusters that earned the original rankings. Behavioral instrumentation is wired into the component system, not bolted on after launch. Cutover happens on a staging environment first: validate the redirect map end-to-end, confirm schema parses cleanly, run crawl simulations, and test that 301s resolve in one hop with no chains or loops.
4. Post-launch monitoring
Phase four is the part most migrations botch. At cutover, submit the new sitemap, monitor server logs for crawl behavior, and watch the redirect map for chains, loops, or 404s. Track rank for the top 100 pages on a daily cadence for the first month after cutover. Track AI search citations across AI Overviews, ChatGPT, Claude, and Perplexity on the same window -- AI engines re-cache on their own cadence, and the migration has to hold its citations through that re-cache. Monitoring here is scheduled, not live -- deliverable-based audit reports plus daily rank pulls during the post-launch window give you the resolution to catch a problem without the noise of constant dashboards. Behavioral telemetry validates that the new pages capture the buyer signals the old ones did.
What to preserve to maintain rank
Five preservation rules cover most of the migration risk. Every rule is a signal layer; breaking one degrades rank, breaking several can collapse it.
-
URL structure. Keep the slugs that rank. If the IA forces a path change, 301 redirect at the page level -- never blanket-redirect to the homepage or to a category index. Tier 1: Google Search Central states that page-level redirects are the supported pattern for site moves. Tier 2: Ahrefs research on 301 redirects and Semrush studies on redirect-chain decay consistently show measurable equity loss past one hop. Tier 3: Google has not documented a fixed percentage of equity lost per redirect -- treat the leak as real but unquantified, and minimize the count.
-
Internal links. Topical clusters earn rankings because internal links concentrate authority on the right pages. Rebuild the internal link graph before launch, not after. Anchor text patterns matter -- preserve the natural noun-phrase anchors the old site used, and add the new ones the migration introduces.
-
Schema parity. If the old site had Service, FAQPage, Article, or Organization JSON-LD that AI engines were extracting from, the new site has to ship the same schema on day one. Schema preservation is non-negotiable. It carries rich-result eligibility, indexing clarity, and entity disambiguation across the move. Tier 1: schema.org type definitions are the canonical reference for the schema you keep. Tier 2: Pressfit.ai's audit corpus across 42 client engagements showed a measurable AI citation drop on every migration that lost FAQPage or Service schema in the move. Tier 3: Google has stated that structured data is not a direct ranking signal in classic search, but answer-engine extraction is a different system, and AI engines extract from structure.
-
Content depth. If a pillar page ranked because it answered the buyer question across 2,500 words of substantive content, the migration does not get to ship a 600-word version with prettier typography. Preserve depth, then add to it.
-
dateModified discipline. Reset every page's
dateModifiedto launch day, but only on pages that changed substantively. ResettingdateModifiedon a page whose content is identical signals freshness without justification, and AI engines are starting to detect and discount it. John Mueller has stated publicly that artificial freshness signals get downweighted. Reset honestly.
AEO and GEO citation preservation through the move
Most migration guides written before 2025 ignore AI engines entirely. That framing is dead. AI Overviews, ChatGPT, Claude, Gemini, and Perplexity drive a meaningful share of B2B research traffic, and they cache citations on their own cadence -- weeks to months, depending on the engine and the query. A migration has to hold its AI citations through that re-cache, or the citation share collapses for the window between cutover and re-extraction.
Four decisions protect AEO and GEO continuity through a move.
-
Schema density on day one. Every page type ships with JSON-LD by default on the new platform. The CMS team cannot accidentally ship a page without it, because the schema is injected at the template level. AI engines extract from structure; if the structure goes missing on cutover, the citation goes with it.
-
Semantic clarity preserved. H2s answer buyer questions in the new templates the same way they did in the old. If the migration restructures headings for visual reasons and the answer-first patterns disappear, AI extraction degrades. AI search visibility depends on the H2 layer doing the question-answering work.
-
Answer-first patterns intact. The TL;DR or definitional opening on every page survives the move verbatim where possible. AI engines extract the first 80 words of a well-structured page far more often than buried passages. Front-load the answer on the new site the same way the old site did.
-
Cross-platform consistency. Product, category, and ICP descriptions stay consistent across pages, schema, FAQ blocks, and metadata after the migration. AI engines cross-reference. Inconsistency reads as low confidence and gets discounted -- which means a migration that subtly rewrites positioning across templates can lose citations even with the URLs and schema intact.
Common migration mistakes that tank organic traffic
Five failure modes account for most of the rank loss after a move. Every one is preventable.
-
No redirect map, or a lazy one. Blanket-redirecting old URLs to the homepage is the single fastest way to lose rank. Every old URL with traffic, links, or rank gets a page-level 301 to its closest content match. Anything less is a self-inflicted wound. Semrush, Marcel Digital, and Siteimprove all publish solid checklists that emphasize this; the gap is not awareness, it is execution under deadline pressure.
-
Redirect chains. A redirect that hops twice before resolving leaks more equity than one that resolves in a single step. Audit the redirect map for chains and loops before cutover, not after. Search Engine Land's practical migration guides treat chain-collapsing as a launch gate, and they are right.
-
Dropped schema. The old site had FAQPage and Service JSON-LD; the new templates do not. AI citations evaporate quickly because the engines have nothing structured to extract from. Schema parity is a launch gate, not a phase-two task.
-
Internal link graph rebuilt around navigation, not topical clusters. If the new internal links only follow the new menu structure, the topical authority that earned rankings on cluster pages disappears. Rebuild the link graph from the cluster map, not from the nav.
-
No post-launch monitoring. The team ships, declares victory, and looks again later when the traffic chart is down by a third. Rank, crawl behavior, and AI citations need scheduled monitoring through the first month after cutover. Most checklists stop at launch; that is where the work actually starts.
How Pressfit.ai approaches website migrations
A Pressfit.ai migration runs the same engagement shape as a rebuild but with tighter scope. The audit, redirect map, build, and cutover all happen, but the templates and content largely stay -- the work is preservation, not re-engineering. Behavioral intelligence is the foundation, not a plugin: every page, section, and CTA is tagged for buyer-signal capture before cutover, and the telemetry validates that the new pages capture what the old ones did. AEO and GEO citation continuity is treated as a launch gate, not a post-launch hope. If the diagnostic shows the real problem is foundation rather than location, we say so and route the engagement to site rebuilds instead. If the real problem is AI citation share rather than the move itself, the engagement routes to AI visibility products. The frame is the same across all three: signals are the unit of work, and behavioral intelligence is how we measure whether they survived.
If the diagnostic above pointed at a migration rather than a rebuild, the next step is a scoped read on the current site -- the URL inventory, the schema map, and the AEO and GEO citation baseline the migration has to hold. Book a discovery call and we will walk through the audit live. If the read says rebuild rather than migrate, we will route you to the rebuild guide instead.
Frequently asked questions
How do you preserve SEO during a website migration?
Preserve URL structure where possible, page-level 301 redirect everything that has to move, rebuild the internal link graph around topical clusters, ship schema parity on day one, and keep content depth on every ranked page. Then monitor rank, crawl behavior, and AI citations on a daily cadence for the first month after cutover. Website migration SEO is mostly preservation discipline, not optimization magic.
How long does it take for rank to recover after a website migration?
Recovery depends on signal preservation, not calendar. A clean migration with a complete redirect map, schema parity, and internal-link continuity often holds rank through cutover with minimal volatility. A migration that breaks signal layers can take much longer to recover, sometimes never to the same level. The right mental model is that recovery is earned by preservation work done before launch, not waited out after it.
Do AI engines like ChatGPT and Perplexity respect redirects the same way Google does?
AI engines re-cache on their own cadence, which means a redirect that Google honors immediately may take weeks for an AI engine to follow. Schema parity and answer-first content on the new URL matter as much as the redirect itself — they preserve indexing signals and entity recognition across the move. The migration has to hold AEO and GEO citations through the re-cache window, and that requires structure preservation, not just URL routing.
What is the difference between a website migration and a website rebuild?
A migration moves an existing site -- domain, platform, IA, or protocol -- without re-engineering the foundation. A rebuild re-engineers the foundation: information architecture, code stack, schema, instrumentation, and content system. Migration is preservation work. Rebuild is foundation work. The two share mechanics but solve different problems, which is why we publish them as sister guides.
What makes Pressfit.ai different from an SEO agency on a migration?
Most agencies run the migration as a checklist and hand off at launch. Pressfit.ai treats migration as signal preservation and stays through the post-cutover monitoring window. Behavioral intelligence is the foundation -- every page captures buyer signal before and after the move, so the team can prove that the migration preserved what it was supposed to preserve, not just hope that traffic comes back.
Should I migrate to a new domain or stay on the current one?
Stay on the current domain unless there is a real reason to move -- brand change, legal issue, or a domain that actively harms credibility. Every domain change is a partial signal reset, even with a perfect redirect map. If the question is brand alignment alone, the answer is usually to stay. If the question is a hard business requirement, plan the migration with full preservation discipline and post-launch monitoring.