Use a 301 for a migration. The reason is simple once you see it: a migration is a permanent move, and a 301 is the permanent redirect. It tells search engines and browsers that the page has moved for good, so they update to the new URL and transfer the ranking signals to it. A 302 is a temporary redirect, which tells search engines the move is only for now, so they keep the original URL indexed and do not commit signals to the new one in the same way. For a permanent change of address, which is what a migration is, that is the wrong message. The classic and costly mistake is using a 302 for a permanent move, often by accident because a platform or plugin defaults to 302, which can leave your old URLs indexed, your new URLs uncredited, and your rankings stranded on addresses you no longer use. So the rule is simple: permanent move, 301; genuinely temporary detour, 302. WPBuildAI scans your site and returns the URL list, so you can map every old URL to its new one and apply a 301 to each, not a 302.
Google tightened this guidance in June 2026: its site move documentation now asks you to file Change of Address requests for every subdomain and both the www and non-www variants of the old domain, so picking 301 over 302 is only half the job if the variants you never use are still answering on their own.
What the two codes actually mean
The numbers are status codes a server returns to say this page is somewhere else now, but they carry different meanings. A 301 means moved permanently: the resource has a new home, and clients should use the new URL from now on. A 302 means found, or moved temporarily: the resource is briefly somewhere else, but the original URL is still the real one and should be kept. As the redirects guide describes, search engines read these meanings literally, so the choice is not cosmetic. It is a statement of intent: permanent or temporary. Everything about which to use in a migration follows from matching that statement to the truth of what you are doing.
Why a migration is a 301 situation
A migration changes your URLs for good. You are not briefly serving pages from another address while you fix something; you are moving to a new structure, platform, or domain that you intend to keep. That is the definition of permanent, so it calls for the permanent redirect. A 301 tells search engines to drop the old URL, adopt the new one, and carry the accumulated ranking to it, which is exactly the outcome a migration needs, as the site move guide describes. Using a 301 aligns the technical signal with your actual intent, so search does what you want without guessing. For the overwhelming majority of migration redirects, 301 is simply correct.
What goes wrong with a 302
The trouble with a 302 in a migration is that it tells a lie by accident: it says this move is temporary when it is not. Search engines, taking it at face value, keep the old URL in the index as the canonical one and hold back from fully crediting the new URL, because they expect the page to return to the original address. The consequences are the ones you migrated to avoid: old URLs lingering in results, new URLs underperforming, and ranking signals not consolidating where you want them. Because the page still loads for visitors through the redirect, nothing looks broken, so the error can persist unnoticed while rankings quietly fail to move. This is why a 302 on a permanent move is a silent, common, and damaging mistake.
The accidental 302
Most 302 mistakes are not deliberate; they are defaults. Some platforms, plugins, and quick redirect tools create a 302 unless you specifically choose a 301, because a temporary redirect is the safer default for short term use. During a migration, where you may be setting up many redirects quickly, it is easy to accept that default without noticing, and end up with a whole site of temporary redirects for a permanent move. So part of using 301s correctly is verifying that the redirects you created are actually 301s, not assuming the type. Check the status code your redirects return, because the difference between 301 and 302 is invisible to a visitor and only shows in the response itself.
When a 302 is genuinely right
To be fair to the 302, it has correct uses, just rarely in a migration. A 302 is right when a move really is temporary: a page briefly redirected during maintenance, a short term promotional redirect you will remove, or an A/B test where you do not want search to replace the original. In those cases you want search to keep the original URL, which is exactly what a 302 preserves. The test is honest intent: will the original URL come back as the real one? Yes means a 302, no means a 301. A migration almost always fails that test, because the old URLs are not coming back, which is why migration redirects are 301s even though the 302 is a legitimate tool elsewhere.
Do not rely on Google reinterpreting a 302
You may read that Google can eventually treat a long lasting 302 as if it were permanent, and that is true to a degree, but it is a poor plan. Relying on it means hoping search figures out your real intent over time, which is slower and less certain than stating that intent directly with a 301. There is no reason to introduce ambiguity and delay into a migration when the correct code removes both. This is especially true at scale, since Web Almanac 2024 (HTTP Archive) shows how many URLs a site has, and you do not want hundreds or thousands of redirects depending on reinterpretation. Use the 301 so the move is unambiguous from day one, rather than leaning on an eventual guess.
Steps to get redirect types right in a migration
- Map every old URL to its new address before launch.
- Use a 301 for each, since the migration is permanent.
- Verify the status code your redirects actually return, not the default.
- Reserve 302 for genuinely temporary detours, not the move itself.
- Confirm each 301 resolves in a single hop to the right page.
- Recheck after launch that old URLs return 301s and new URLs return 200.
Worked example: catching a sitewide 302 default
Imagine a team migrating to a new platform who set up redirects quickly using a tool that defaulted to 302. The pages all loaded through the redirects, so the launch looked fine, but weeks later the old URLs were still in the index and the new URLs were not gaining ground. Checking the status codes revealed the cause: every redirect was a 302, telling search the permanent move was temporary. They reissued all the redirects as 301s, confirmed each returned a 301 and resolved in one hop to the correct page, and over the following recrawls the old URLs dropped out and the new ones took up the rankings. Nothing about the content or the destinations had changed; only the redirect type was wrong, which is why verifying the code matters as much as setting the redirect, alongside knowing how completely a 301 transfers value.
Limitation: the right code still needs the right target
It is fair to note that choosing 301 over 302 is necessary but not sufficient. A 301 only helps if it points at the correct equivalent page; a 301 to the homepage or to an unrelated page is read as a soft 404 and does not transfer value, no matter how correct the status code. So the redirect type and the redirect target are two separate decisions that both have to be right. Use a 301, and point it at the true new home of the page. And for pages that are genuinely gone with no equivalent, the question shifts from 301 versus 302 to whether to return a 404 or 410, covered in 404 vs 410 for deleted pages. The code states the intent; the target delivers the value.
Common mistakes
- Using a 302 for a permanent move, often via a platform default.
- Assuming a redirect is a 301 without verifying the status code.
- Relying on Google to eventually reinterpret a long 302 as permanent.
- Pointing a correct 301 at the homepage instead of the true equivalent.
- Mixing 301s and 302s across a migration without checking which is which.
Key points
For a migration, use a 301, because the move is permanent and a 301 is the permanent redirect that transfers ranking to the new URL. A 302 is temporary and tells search to keep the old URL indexed, so using it for a permanent move strands rankings on old addresses, a common accidental error when platforms default to 302. Reserve the 302 for genuinely temporary detours, verify that your migration redirects actually return 301s rather than trusting defaults, and do not rely on Google reinterpreting a long lived 302. Remember that the right code still needs the right target, a one to one redirect to the true new page, not the homepage. Start from a complete URL map so every old address gets a correct 301, the same foundation as managing how many redirects are too many. WPBuildAI scans your site and returns the URL list, so you can map every old URL to its new one and apply a 301 to each, not a 302. Send your web address for a free analysis.
Not affiliated with WordPress, Lovable, Webflow, Shopify, Wix, or Squarespace.