Site Migration SEO for Vue Apps

A migration can disrupt discovery, links, and search appearance. Map URL outcomes, test redirects, and monitor processing. A citation or ranking is not guaranteed to carry over.

Types of Migrations

Each migration type affects SEO differently:

Domain change (old.com → new.com): file the Change of Address tool in Search Console after an eligible domain or subdomain move. Verify both properties with the same account. A submission does not move subdomains automatically. The tool forwards site signals for 180 days; keep HTTP redirects much longer.

Protocol change (HTTP → HTTPS): update every canonical tag to the HTTPS version. Conflicting preferences do not themselves create a redirect loop. Update the signals consistently; Change of Address does not apply to this protocol-only move.

URL structure change (/blog/post → /posts/post): map each moved URL to a relevant replacement, with no intermediate hops. Change of Address does not apply to a path-only move.

Platform/framework change: compare old and new published inventories. Record unchanged paths and any moved or removed content. A framework change alone does not require different URLs.

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

Pre-Migration Checklist

Start here before touching production:

1. Crawl the old site completely. Use Screaming Frog or similar. Combine the crawl with the publishing inventory; a crawl can miss unlinked URLs.
2. Save available Search Console observations. Export available page-indexing examples and Performance data. These reports are not an exhaustive inventory of indexed URLs; compare them with the crawl and publishing inventory. Applicable Search Console Performance history covers 16 months, so the pre-migration numbers age out if you don't save them.
3. Document current rankings. Export Search Console Performance for your top pages so you have something to compare against after launch. Add a Search Console annotation 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 each URL as unchanged, redirected to a relevant replacement, or removed with 404/410.

For large sites, Google suggests migrating in sections 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

Mapping is where migrations succeed or fail.

1:1 mapping (preferred): each old URL redirects to exactly one new URL with identical or similar content.

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

Pattern-based redirects: for systematic URL changes, use regex or route patterns to redirect an entire section at once.

/blog/:slug → /articles/:slug
/category/:cat/page/:num → /c/:cat?page=:num

Deleted pages: redirect to a relevant replacement when one exists. Otherwise return 404 or 410. Previous traffic or backlinks do not justify an unrelated redirect.

Implementing Redirects in Vue

Google prefers permanent HTTP redirects for permanent moves; Google supports 301 and 308. Google can process some JavaScript redirects, but those depend on rendering. Vue does not own the HTTP response; implement moves in the host or application server.

Express Server

Install Express in your app’s server project. This setup targets Express 5.2.1 and belongs before the existing Vue SSR/static handler. Deploy domain-move rules on the old host. The example retains query strings by app policy and encodes the captured slug as one path segment; change that policy deliberately if needed.

pnpm add express

import express from 'express'

const app = express()

function withQuery(targetPath: string, originalUrl: string) {
  const query = new URL(originalUrl, 'https://old.example.com').search
  return `${targetPath}${query}`
}

app.get('/old-url', (req, res) => {
  res.redirect(301, withQuery('/new-url', req.originalUrl))
})

app.get('/blog/:slug', (req, res) => {
  const target = `/posts/${encodeURIComponent(req.params.slug)}`
  res.redirect(301, withQuery(target, req.originalUrl))
})

const redirects: Record<string, string> = {
  '/old-page-1': '/new-page-1',
  '/old-page-2': '/new-page-2',
  '/company/about': '/about'
}

app.use((req, res, next) => {
  const target = redirects[req.path]
  if (target)
    return res.redirect(301, withQuery(target, req.originalUrl))
  next()
})

These handlers do not start a server or supply destination pages. Keep your app’s existing listener and rendering handler. Verify real destination responses separately.

Vite Server

Vite’s development server is not your production redirect layer. Configure redirects on the actual deployed host or use the Express integration above. Verify HTTP responses against that deployment.

H3 Server (Nitro/Nuxt)

If the Vue app uses an H3/Nitro backend, follow the checked Nuxt redirect guide for its released handler and route-rule boundaries. Plain Vue does not supply Nitro middleware or a server directory automatically.

Avoid Redirect Chains

A chain forms when URL A redirects to B, which redirects to C, most often because a new migration redirect gets layered on top of an old one. Each hop adds a request and can delay navigation. Do not assign a fixed ranking loss to a hop.

Common scenario: you have an old redirect (A → B) and add a new migration redirect (B → C), and now you have a chain: A → B → C.

Fix: point every redirect directly at the final destination, consolidating old and new redirects into single-hop redirects.

// Bad: creates a chain
// Old redirect: /page-v1 → /page-v2
// New redirect: /page-v2 → /page-v3
// Result: /page-v1 → /page-v2 → /page-v3

// Good: consolidate
const redirects = {
  '/page-v1': '/page-v3', // direct to final
  '/page-v2': '/page-v3'
}

Test redirects before launch: each permanent move should return 301 or 308 and resolve to a 200 in one hop.

Update Canonical Tags

When URLs change, canonical tags must point at the new URLs. A canonical tag pointing to a redirected URL sends an indirect preference; it does not itself create an HTTP loop. Point to the intended current equivalent URL.

<!-- Bad: canonical points to old URL -->
<link rel="canonical" href="https://example.com/old-url">

<!-- Good: canonical points to new URL -->
<link rel="canonical" href="https://example.com/new-url">

This setup excerpt requires Unhead installed on the Vue app and runs inside a component setup. A fixed URL is appropriate only for that specific page:

import { useHead } from '@unhead/vue'

useHead({
  link: [
    { rel: 'canonical', href: 'https://example.com/new-url' }
  ]
})

Scan the staging site before launch to confirm every canonical points at a new URL, not an old one.

Post-Migration Steps

The hours after migration are when problems surface.

1. Update the Search Console property. For eligible domain/subdomain moves, use Change of Address after redirects are live. It forwards site signals for 180 days. Exclude protocol, path, and www-only moves.
2. Submit the new sitemap. Generate it with the new URLs, submit in Search Console, and remove the old one from robots.txt.
3. Request indexing of key pages. In Search Console, request indexing for infrequent, important changes. A request does not guarantee crawling or indexing.
4. Check the Page Indexing report daily. Watch for 404s, soft 404s, redirect errors, and pages Google isn't following, for at least the first two weeks.
5. Watch server capacity. Google crawls new sites more heavily right after a migration since every redirected old-URL crawl adds to normal crawling of the new site.
6. Compare organic traffic before and after. Set up a date comparison in your analytics tool and track organic sessions specifically, separate from other channels.
7. 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 moves on its own schedule. Traffic and indexing changes vary by migration. Inspect response failures, canonical preferences, links, and reported indexing states rather than expecting a fixed percentage dip or deadline.

Keep redirects for at least a year. Google’s guidance recommends keeping them as long as possible, generally at least one year. Keep useful old links working longer. This differs from Change of Address’s 180-day site-signal window.

Reported site-move observations 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 explains the separate processing stages.

Common Migration Mistakes

Redirect chains: add requests and delay navigation. Consolidate old and new redirects into single-hop redirects.

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 updating canonical URLs: canonical tags should point at the intended current equivalent URL; a redirected preference does not itself create an HTTP loop. Update canonicals alongside redirects, not after.

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.

Client-side redirects: use permanent HTTP redirects for permanent moves when possible. JavaScript redirects depend on rendering; they are not equivalent to an immediate HTTP 301/308.

No redirect testing: test redirects on staging before launch. Verify each returns 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.

Using Nuxt?

Nuxt applications should use server middleware for redirects. One thing to watch: Nuxt's routeRules string shorthand (redirect: '/new-url') defaults to a 307 temporary redirect, not a permanent one; use the object form ({ redirect: { to: '/new-url', statusCode: 301 } }) for a real migration redirect.

For full Nuxt migration guides, see the Launch & Listen section.

Checklist