301 vs. 308 Redirects: Getting Site Migrations Right

Every site migration I’ve seen go wrong went wrong at the redirect map, not at the new design or the new hosting. Getting 301s and 308s right sounds like a solved problem — it’s one status code, how hard can it be — but the number of support tickets I’ve seen that trace back to a badly executed redirect suggests otherwise.

What Google actually says about the two

Google’s own documentation states it plainly: “the 301 and 308 status codes mean that a page has permanently moved to a new location.” For search purposes, Google treats both as equivalent signals of a permanent move — neither one is favored over the other in how Google Search interprets and consolidates ranking signals.

Where they genuinely differ is in the underlying HTTP specification, not in how Google’s crawler treats them for ranking. A 301 redirect historically allows (and in practice, often causes) clients to switch the request method to GET regardless of what the original request was. A 308 redirect explicitly requires the client to preserve the original HTTP method — so a POST request that gets redirected with a 308 stays a POST at the new URL, where a 301 might turn it into a GET. That distinction matters enormously for form submissions and API endpoints, and barely matters at all for a normal page-to-page content redirect, which is why most WordPress migrations default to 301s without issue.

Google’s actual migration guidance, in order

Google’s site-move documentation lays out a clear preference order for how to signal a URL change, and it’s worth following exactly as written rather than improvising:

1. A server-side permanent redirect — Google’s explicit recommendation “whenever possible,” because it’s the most reliable way to direct both Google Search and real visitors to the correct page.
2. A meta refresh, if a server-side redirect genuinely isn’t available.
3. A JavaScript redirect, as a last resort — Google will process it, but with more delay and more risk than a server-side redirect.
4. A visible link, if no redirect mechanism is possible at all.

Google also notes something that trips up a lot of people mid-migration: old URLs can keep showing up in search results for a period even after the new URLs are indexed and the redirects are live. Google describes this explicitly as normal, not a sign that something’s broken. I’ve had support conversations where someone panicked three days into a migration because the old URL still appeared in a Google search — that’s expected behavior, not a failure state.

A permanent redirect is the strongest signal you can give Google that a URL has genuinely moved. Everything else on this list is a fallback for when that’s not technically possible.

Where migrations actually break on WordPress

The mechanics of a redirect are simple. What goes wrong is almost always process, not syntax:

• Redirect chains. Old URL to interim URL to final URL, often built up over multiple past migrations nobody cleaned up. Each hop adds latency and dilutes signal clarity. Map every redirect straight to its true final destination.
• Redirecting everything to the homepage. The single most common mistake I see — instead of mapping old URLs to their actual new equivalents, someone sets a blanket rule sending every dead URL to the homepage “just in case.” This is a poor experience for both users and Google, and wastes the specific relevance signal a proper one-to-one redirect would have passed along.
• Missing the non-content URLs. Category pages, tag archives, author pages, and paginated URLs get forgotten because the focus is always on individual posts. If your URL structure for taxonomies changes too, those need mapping just as much as your posts do.
• Forgetting the XML sitemap. An old sitemap still referencing pre-migration URLs sends mixed signals — update or regenerate it as part of the same change, not as an afterthought.
• Testing on staging with redirects disabled, then forgetting to verify they actually fire correctly once the site goes live on production infrastructure, which sometimes handles redirects differently (server-level vs. plugin-level, for instance).

A practical migration checklist

For a typical WordPress-to-WordPress or platform-to-WordPress migration, the sequence that’s worked reliably for me:

1. Crawl the old site fully before touching anything, and export every live URL — you can’t map what you haven’t inventoried.
2. Build a one-to-one redirect map (old URL → specific new URL), not a set of generic pattern rules, wherever a true one-to-one equivalent exists.
3. Implement redirects server-side (via your webserver config or a well-supported redirect plugin) rather than through JavaScript.
4. Update the XML sitemap and internal links to point directly at new URLs — don’t rely on the redirect layer to clean up internal linking for you.
5. Submit the new sitemap in Search Console and monitor the Coverage and Page Indexing reports for a spike in “Page with redirect” or unexpected 404s.
6. Leave the redirects in place indefinitely. Removing them once “enough time has passed” is a common and unnecessary risk — there’s no real cost to keeping a working redirect live permanently.

None of this is complicated in isolation. What makes migrations risky is scale — a site with a few hundred URLs and a dozen taxonomies has a lot of individual mapping decisions, and it only takes a handful of missed ones to create a visible dent in traffic that takes weeks to fully diagnose.

One more detail worth checking: HTTP status during the transition

A redirect chain that briefly returns a soft error — a 200 status on a page that’s actually showing an error message, rather than a proper 4xx or a clean redirect — confuses crawlers in a way that’s harder to diagnose than a straightforward broken link. If your migration involves any custom middleware or a CDN layer sitting between WordPress and the visitor, it’s worth explicitly checking the actual HTTP status codes being returned during the cutover window, not just confirming that pages visually load correctly in a browser. A page that looks fine to a human but is technically returning the wrong status code can quietly confuse how Google interprets the whole migration.