---
title: "Site Migration SEO for Nuxt Apps"
description: "Map old URLs, test permanent redirects, and monitor discovery through a domain, URL, or framework move."
canonical_url: "https://nuxtseo.com/learn-seo/nuxt/launch-and-listen/site-migration"
last_updated: "2026-10-08"
---

> Index of every page on this site: [llms.txt](https://nuxtseo.com/llms.txt)

::key-takeaways
- Map moved URLs to relevant replacements. Use explicit permanent redirects; Nitro’s string shorthand defaults to temporary 307
- File the Change of Address tool in Search Console for eligible domain or subdomain moves after redirects are live; it forwards site signals for 180 days, well short of the year or more you should keep the actual redirects live.
- Processing and traffic changes vary by migration. Google does not publish a universal recovery deadline
- 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 available globally since August 31, 2026.
::

A migration can disrupt discovery, links, and search appearance. Map old URLs to relevant replacements, test redirects, and monitor Google's processing. Different AI services can use different indexes; citations are not guaranteed to carry over.

## Types of Migrations

**Domain change** ([old.com](http://old.com) → [new.com](http://new.com)): file the [Change of Address tool](https://support.google.com/webmasters/answer/9370220) in Search Console for the eligible old domain and subdomain properties you moved. Verify ownership of both properties with the same account. A submission does not move subdomains automatically. The tool forwards site signals for 180 days, but keep the redirects themselves live much longer.

**Protocol change** (HTTP → HTTPS): update every canonical tag to the HTTPS version. Conflicting canonical and redirect signals can complicate your preference; those signals alone do not create a redirect loop.

**URL structure change** (`/blog/post` → `/posts/post`): check for redirect chains. Map each moved URL to a relevant replacement, with no intermediate hops.

**Platform change** (WordPress → Nuxt, for example): a full HTML rewrite can change how crawlers and LLMs parse your content. Check visible content and [Schema.org](https://nuxtseo.com/learn-seo/nuxt/mastering-meta/schema-org) markup against the new templates. Markup must still match the page.

**Site redesign with the same URLs**: unchanged URLs need no move redirects. Validate canonical tags, content, and internal links against the new templates.

## Pre-Migration Checklist

1. **Inventory the old site.** Export URLs observed by a configured crawl and combine them with the publishing and route inventories. Crawl limits, access controls, and missing links can leave URLs undiscovered.
2. **Save available Search Console observations.** Export available page-indexing examples and Performance data for a baseline. These exports do not provide an exhaustive inventory of indexed URLs. Compare them with your crawl and publishing inventory. Applicable Search Console Performance history covers [16 months](https://gscdump.com/learn-google-search-console/limits/16-month-data-retention), so the pre-migration numbers age out if you don't save them.
3. **Document current rankings.** Export top pages from Performance; you'll need this for comparison after launch. Add a [Search Console annotation](https://gscdump.com/learn-google-search-console/performance/custom-annotations) on launch day so the change sits beside the traffic chart.
4. **Build a redirect mapping spreadsheet.** Three columns: Old URL, New URL, target status code. Record every inventoried URL’s outcome: unchanged, redirected to a relevant replacement, or removed with 404/410.

For large sites, [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.

```
/blog/vue-seo-guide → /guides/vue-seo
/products/item-123 → unchanged URL, no redirect
```

**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**: redirect when a relevant replacement exists. If none fits, return 404 or 410. Previous traffic or backlinks do not justify an unrelated redirect.

## 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 expresses a temporary move rather than a permanent canonicalization signal. 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 hop adds a request and can delay navigation. Point directly to the final destination.

```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 the intended 301 or 308 and resolve to a 200 in a single hop.

## Update Canonical Tags & LLM Hints

When URLs change, update canonical preferences and internal links to the intended current destinations. If you publish llms.txt, update its links using the [checked guide](https://nuxtseo.com/learn-seo/nuxt/controlling-crawlers/llms-txt). Provider rendering and retrieval capabilities vary; this file does not guarantee discovery or citations.

## Post-Migration Steps

1. **Change of Address tool**: use it after redirects are live for eligible domain or subdomain moves. It does not apply to protocol, path, or www-only changes. It forwards site 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 important changed pages. A request does not guarantee immediate crawling or indexing.
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 available globally since August 31, 2026, so treat it as a directional signal rather than a full picture.

## Recovery Timeline

Google processes migrations on its own schedule. Monitor reported indexing, redirects, and traffic trends. Compare reported changes with the migration inventory and response tests.

Traffic changes vary by site and migration. Google does not document a universal percentage dip or fixed recovery time.

**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 site-signal window: the tool and HTTP redirects serve different parts of the move.

[Reported site-move observations](https://www.seroundtable.com/google-crawling-indexing-serving-data-42225.html) put typical processing at 1 to 3 months, with slow cases reaching 6 months to over a year. These figures do not promise traffic recovery. Keep checking redirects and dated URL observations; [Google Search timelines](https://nuxtseo.com/learn-seo/google-search-timelines) explains the separate processing stages.

## 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 the intended 301 or 308 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

::checklist{#site-migration-nuxt}
- Combine observed crawl URLs with publishing and route inventories; record access and discovery limits
- 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
- Use Change of Address after eligible domain/subdomain moves; exclude protocol, path, and www-only 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
::

## Sitemap

See the full [sitemap](https://nuxtseo.com/sitemap.md) for all pages.