---
title: "Site Migration SEO for Nuxt Apps"
description: "Redirect maps, 301 status codes, and AI crawler checks that keep rankings and AI citations intact through a domain, URL, or framework move."
canonical_url: "https://nuxtseo.com/learn-seo/nuxt/launch-and-listen/site-migration"
last_updated: "2026-07-16"
---
- Map every old URL to exactly one new URL. `routeRules` redirects pass ranking signals cleanly when they're permanent, but the string shorthand defaults to a 307 temporary redirect, so use `{ redirect: { to: '...', statusCode: 301 } }` for a real migration.
- File the Change of Address tool in Search Console for domain changes; it forwards ranking signals for 180 days, well short of the year or more you should keep the actual redirects live.
- Recovery is slow: across 1,052 tracked migrations only 23% of sites recovered traffic within 90 days, and the median took 304 days.
- Search Console's Generative AI performance report can show AI Overview impressions by page, so you can compare old and new URLs after launch, though it's impressions-only and still rolling out to a subset of sites.
Poor site migrations destroy search rankings, and since AI Overviews and chatbot citations draw on the same crawled and indexed content, a bad migration can knock those out too. The fix for both is the same: map every old URL to exactly one new URL, redirect it correctly, and give Google time to process the change.
## Types of Migrations
**Domain change** (old.com → new.com): file the [Change of Address tool](https://support.google.com/webmasters/answer/9370220) in Search Console for every subdomain variant (www, non-www, and any others you use); it forwards ranking signals for 180 days, but keep the redirects themselves live much longer.
**Protocol change** (HTTP → HTTPS): update every canonical tag to the HTTPS version. Leaving canonicals pointed at HTTP while redirects send Google to HTTPS creates a loop.
**URL structure change** (`/blog/post` → `/posts/post`): the type most prone to redirect chains. Map every old URL to exactly one new URL, with no intermediate hops.
**Platform change** (WordPress → Nuxt, for example): a full HTML rewrite can change how crawlers and LLMs parse your content. Use [Schema.org](/learn-seo/nuxt/mastering-meta/schema-org) markup to keep the semantic structure consistent through the switch.
**Site redesign with the same URLs**: the lowest-risk migration since nothing needs to redirect, but still validate canonical tags and internal links against the new templates.
## Pre-Migration Checklist
1. **Crawl the old site completely.** Export every URL so you have a full inventory before anything changes.
2. **Export indexed URLs and AI Search data from Search Console.** Pull Performance data, including the AI Search Appearance filter, for a baseline.
3. **Document current rankings.** Export top pages from Performance; you'll need this for comparison after launch.
4. **Build a redirect mapping spreadsheet.** Three columns: Old URL, New URL, target status code. Map every URL, no exceptions.
For sites with 10,000+ pages, [Google suggests migrating in sections](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) and testing with a small section before moving the rest, though it notes a section move isn't fully representative of how a whole-site move behaves in Search.
## Redirect Mapping Strategy
**1:1 mapping** (preferred): each old URL redirects to exactly one new URL with equivalent content.
```text
/blog/vue-seo-guide → /guides/vue-seo
/products/item-123 → /products/item-123 (unchanged)
```
**Pattern-based redirects**: for systematic URL changes across a whole section, use `routeRules` with wildcard patterns instead of mapping every URL by hand.
**Deleted pages**: don't 404 a page that had traffic or backlinks. Redirect it to the closest relevant alternative. If nothing fits, return 410 (Gone) rather than 404 to signal the removal is permanent.
## Implementing Redirects in Nuxt
Nuxt handles redirects through `routeRules` in `nuxt.config.ts`. The string shorthand looks convenient but [defaults to a 307 temporary redirect](https://nitro.build/config#routerules), which doesn't pass ranking signals the way a permanent redirect does. Use the object form and set `statusCode: 301` explicitly for a real migration redirect.
### Single Redirects
```ts
// nuxt.config.ts
export default defineNuxtConfig({
routeRules: {
'/old-url': { redirect: { to: '/new-url', statusCode: 301 } }
}
})
```
### Pattern-Based Redirects
```ts
// nuxt.config.ts
export default defineNuxtConfig({
routeRules: {
'/blog/**': { redirect: { to: '/articles/**', statusCode: 301 } }
}
})
```
For large redirect maps, generate the `routeRules` object from your mapping spreadsheet at build time rather than hand-writing hundreds of entries.
## Avoid Redirect Chains
A chain forms when URL A redirects to B, which redirects to C, most often because a new migration redirect gets added on top of an old one. Each extra hop dilutes ranking signal and slows crawling.
```ts
// Bad: creates a chain
// Old redirect: /page-v1 → /page-v2
// New redirect: /page-v2 → /page-v3
// Result: /page-v1 → /page-v2 → /page-v3
// Good: point both directly at the final destination
export default defineNuxtConfig({
routeRules: {
'/page-v1': { redirect: { to: '/page-v3', statusCode: 301 } },
'/page-v2': { redirect: { to: '/page-v3', statusCode: 301 } }
}
})
```
Test every redirect before launch: it should return 301 and resolve to a 200 in a single hop.
## Update Canonical Tags & LLM Hints
When URLs change, canonical tags must point at the new URLs, not the redirected ones. If you use `nuxt-llms`, update your `llms.txt` sections too so AI crawlers, which read your raw HTML without executing JavaScript, find the current paths on their next fetch.
```ts
// nuxt.config.ts
export default defineNuxtConfig({
llms: {
sections: [
{ title: 'New Blog', links: [{ title: 'Posts', href: '/articles' }] }
]
}
})
```
## Post-Migration Steps
1. **Change of Address tool**: file it in Search Console immediately for domain moves. It forwards ranking signals for [180 days](https://support.google.com/webmasters/answer/9370220), so keeping the actual redirects live matters more than the tool itself.
2. **Submit the new sitemap** and remove the old one from `robots.txt`.
3. **Request indexing** for your homepage and top 10-20 pages in Search Console to speed up discovery.
4. **Check the Page Indexing report daily** for the first two weeks, watching for 404s, soft 404s, and redirect errors.
5. **Watch server capacity.** [Google crawls new sites more heavily right after a migration](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) since every redirected old-URL crawl adds to normal crawling of the new site.
6. **Monitor AI Overview impressions by page** with Search Console's Generative AI performance report, which launched in June 2026. It's impressions-only, filtered by page, country, device, and date, and still rolling out to a subset of sites, so treat it as a directional signal rather than a full picture.
## Recovery Timeline
Recovery is slower than most guides suggest. Across 1,052 tracked domain migrations, [SALT.agency found](https://salt.agency/blog/27-of-domain-migrations-recover-in-90-days/) only 5% of sites recovered within 30 days and 23% within 90 days; the median recovery time was 304 days, the mean 489 days. A separate [Search Engine Journal study of 892 migrations](https://www.searchenginejournal.com/study-how-long-should-seo-migration-take/492050/) found a mean recovery time of 523 days, with 17% never fully recovering after 1,000 days, an improvement on the 42% non-recovery rate from its earlier, smaller study.
A 10-30% traffic dip in the first two weeks is normal while Google discovers and processes your redirects. Beyond that, recovery time depends heavily on site size, redirect quality, and how much traffic came from external links pointing at the old URLs, which is why the ranges above vary so widely.
**Keep redirects for at least a year.** [Google's own guidance](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) is to keep them "for as long as possible, generally at least 1 year," and to keep them indefinitely if a URL still gets traffic. That's a separate clock from the Change of Address tool's 180-day signal-forwarding window: the tool speeds up the transition, the redirects themselves are what makes it permanent.
## Common Migration Mistakes
**Forgetting internal links**: your site's own internal links still point at old URLs, triggering unnecessary redirects on every click. Update them to point directly at new URLs, not through the redirect.
**Removing redirects too early**: traffic sources outside your control (old backlinks, bookmarks, third-party sites) use old URLs indefinitely. Keep redirects for years, not months.
**No redirect testing**: test redirects on staging before launch. Verify each returns 301 and resolves to 200 in one hop.
**Forgetting mobile/AMP URLs**: if you had separate mobile URLs (`m.example.com`) or AMP versions, redirect those too.
## Checklist
- Crawl the old site and export every URL before touching production
- Build a redirect mapping spreadsheet: old URL, new URL, target status code
- Use `routeRules` with `{ redirect: { to, statusCode: 301 } }`, not the 307-default string shorthand
- Point every redirect directly at its final destination, no chains
- Update canonical tags and `llms.txt` to the new URLs
- File the Change of Address tool in Search Console for domain changes
- Submit the new sitemap and remove the old one
- Check the Page Indexing report daily for the first two weeks
- Keep redirects live for at least a year