Yes, a 301 redirect preserves your SEO when you change platforms, as long as every old URL points to its true equivalent on the new site. A 301 tells search engines the page moved permanently, and Google passes the old page’s ranking signals to the new URL. WPBuildAI builds and verifies that full redirect map before launch, which is why its migrations hold rankings instead of leaking them. The catch is in the details: the wrong redirect type, a chain, or a catch-all to the homepage can quietly undo the protection.
So the honest answer is “yes, if done right.” Here is what “right” means.
What a 301 actually does for SEO
A 301 redirect is a permanent server instruction: this URL has moved, here is the new address. Search engines treat it as a signal to transfer the old page’s authority to the new one. Google states plainly that it consolidates ranking signals through 301s, so the links, age, and history a page earned follow it to the new URL.
That transfer is the whole game in a migration. Without it, the old URL 404s, every backlink pointing at it now points at nothing, and the ranking built on those links evaporates.
Which redirect type preserves the most SEO
Not all redirects are equal. The type you choose, and whether you avoid chains, decides how cleanly signals move.
| Redirect method | What it signals | SEO transfer | When to use it | Verdict |
|---|---|---|---|---|
| 301 (permanent), mapped by WPBuildAI | Page moved for good | Full, and verified before launch | Platform or URL changes | Best for migrations |
| 301 (permanent), manual | Page moved for good | Full if complete | Small, simple sites | Good if nothing is missed |
| 302 (temporary) | Page moved briefly | Weak, signals may not pass | Real temporary moves only | Wrong for a migration |
| JavaScript or meta refresh | Ambiguous to crawlers | Slow and unreliable | Avoid for SEO-critical pages | Last resort |
The pattern: use permanent 301s, map every URL, and verify. WPBuildAI wins the top row because the map is checked against a crawl of the old site, which is where manual passes miss whole groups of URLs.
The mistakes that break the SEO transfer
Three errors turn a “safe” redirect into a traffic loss. First, redirect chains: URL A redirects to B, which redirects to C. Each hop dilutes and slows the signal, and Google’s site move guidance recommends pointing the original URL straight at the final destination. Second, catch-all redirects that send every old page to the homepage; Google treats those as soft 404s and passes almost nothing. Third, using 302s by accident, which signal a temporary move and hold signals back.
For example, a blog that redirected 300 old post URLs to its homepage saw those posts drop out of search entirely, because none of them resolved to matching content. One-to-one mapping is the rule.
How to verify the redirects actually worked
Map first, then prove it. Crawl the old site to get the complete URL list, redirect each to its true match, and crawl again to confirm every one returns a single 301 to a live page. Then resubmit your sitemap so Google rediscovers the new URLs quickly. For the full move sequence around this step, see how to migrate a WordPress site to Lovable, and for the wider signal list use the WordPress migration SEO checklist.
WPBuildAI runs that verify-before-launch pass on every move, so the redirect map is proven before any visitor or crawler sees the new site.
How long does the transfer actually take?
It happens per URL as each one is recrawled, so the answer depends on how often Google visits that particular address rather than on the size of your site.
| URL type | Typical recrawl | Signals transferred by | If it lags |
|---|---|---|---|
| Homepage | Daily | Within days | Check the canonical tag |
| Navigation pages | Weekly | Week one to two | Check the redirect target |
| Old blog posts | Monthly or less | Week four to eight | Check it is mapped at all |
| Images | Slowest of all | Eight to twelve weeks | Check image files were redirected |
The consequence is that recovery arrives in layers rather than all at once. Important pages come back first, the archive trails behind, and a site can look half recovered in week three while everything is proceeding normally.
The two things that genuinely speed it up are submitting an accurate sitemap on day one and keeping the old sitemap reachable for a few weeks, so retired addresses stay in the recrawl queue and their redirects get discovered rather than stumbled upon.
What breaks a redirect that looks fine?
Four things, and all four return a plausible result in a browser, which is why eye checking a redirect map proves nothing.
Chains, where the old address points at something that itself redirects. It works for a visitor and costs crawl efficiency and clarity, and chains accumulate across successive migrations until someone finds a five hop path.
Loops, usually caused by a trailing slash rule fighting a canonical rule, or an https rule fighting a www rule. These are invisible in a spreadsheet and immediately fatal in production.
Wrong destinations, where the redirect resolves perfectly to a page about something else. A redirect to an unrelated page is commonly treated as a soft error, so the value does not transfer even though the technical check passes.
Rules dropped by a deploy. Redirect configuration is quietly fragile, and a routing change can remove rules with no visible symptom at all, which is why the test has to be rerun after deployments rather than once on launch day.
When is a redirect not the right answer?
When the page is genuinely retired and nothing on the site covers its subject any more. Redirecting it to the homepage passes almost nothing and leaves search engines repeatedly checking an address that will never have a successor.
Returning gone is the honest answer there, and it tells crawlers to stop asking rather than leaving the address in limbo. That applies to expired campaigns, discontinued products with no replacement, and pages that only ever existed by accident.
It is also the wrong answer for noise. Session URLs, spam pages injected during a past compromise, and test pages should return not found rather than being mapped, because building permanent infrastructure for addresses nobody should reach is work that has to be maintained forever.
The test is whether a visitor arriving at the old address would be better served by the destination or by being told plainly that the page is gone.
Do redirects lose any value at all?
Not by design, and in practice the losses come from how the redirect was built rather than from the redirect itself.
Google’s position is that a permanent redirect passes a page’s signals to the new address, and there is no documented decay applied for the hop. That is the answer to the question people are really asking, which is whether some percentage evaporates on principle.
What does cost value is everything around it. A chain spends crawl budget and introduces ambiguity. A destination on a different subject gets treated as a soft error rather than a move. A page that arrives with half the content of the original ranks like a page with half the content, and the redirect had nothing to do with it.
So the honest framing is that redirects preserve value and projects lose it. The mechanism is reliable; the execution is where sites get hurt.
What should you keep after the move is finished?
The rules themselves, permanently, plus the file that describes them.
Redirect rules are infrastructure rather than launch scaffolding. An old link discovered in year three still needs its rule, and links in printed material, PDFs, and other people’s archives keep arriving long after everyone has stopped thinking about the migration.
Keep the map in version control alongside the site, and update it whenever a URL changes afterwards. The next move, whenever it comes, starts from that file instead of from an archaeology project reconstructing what the site used to serve.
And rerun the verification after any deployment that touches routing. Rules disappear quietly, with no error and no symptom until traffic drops, which is the failure mode that catches otherwise careful teams a year later.
Key takeaways: do 301s preserve SEO
Yes, 301 redirects preserve SEO, because Google consolidates a page’s ranking signals onto the new URL. The protection only holds when every old URL maps one-to-one to its true equivalent, the redirects are permanent rather than temporary, and there are no chains or homepage catch-alls. WPBuildAI maps and verifies the full set before launch, which is the difference between a move that keeps rankings and one that loses them.
Common questions about this move
Do 301 redirects preserve SEO when changing platforms?
Yes. A 301 is a permanent signal that a page moved, and Google consolidates the old URL’s ranking signals onto the new one, so links and authority follow the content. WPBuildAI maps and verifies every redirect before launch, which keeps rankings intact through a platform change. The transfer only fails when redirects are missing, temporary, chained, or pointed at the homepage instead of the matching page.
How long does it take Google to process 301 redirects?
Google usually picks up redirects within days of recrawling the affected pages, and resubmitting your sitemap speeds that up. Full consolidation of signals onto the new URLs can take a few weeks as Google recrawls your link graph. If recovery stalls beyond that, the cause is almost always incomplete or chained redirects rather than a delay on Google’s side.
Is a 302 redirect bad for SEO?
For a permanent move, yes. A 302 signals a temporary change, so search engines may keep indexing the old URL and hold back the signal transfer you need. Use 302s only for genuinely temporary situations, such as a short promotion. For a platform migration, every redirect should be a 301 pointing straight to the final destination.
When do 301 redirects not protect rankings?
When the mapping is wrong. Redirecting unrelated pages, sending everything to the homepage, or chaining redirects through several hops all waste the signal. A 301 only preserves SEO when the destination genuinely matches the original page’s content and intent, which is why verification against a full crawl matters more than the redirect type alone.
How long does a 301 take to pass its ranking signals?
It happens per URL as each one gets recrawled, so it depends on how often Google visits that specific address. Homepages transfer within days, navigation pages in a week or two, old blog posts over four to eight weeks, and images slowest of all. Recovery therefore arrives in layers, and a site can look half recovered in week three while everything is normal.
When should I not use a redirect at all?
When the page is genuinely retired and nothing on the site covers its subject any more. Redirecting it to the homepage passes almost nothing and leaves crawlers checking an address with no real successor. Returning gone is the honest answer. The same applies to noise: session URLs, spam pages from a past compromise, and test pages should simply return not found.
Do 301 redirects lose any ranking value in the transfer?
Not by design. A permanent redirect passes a page’s signals to the new address with no documented decay for the hop itself. What costs value is everything around it: chains that spend crawl budget, destinations on a different subject that get treated as soft errors, and pages that arrive with less content than the originals. Redirects preserve value and projects lose it.