Before you touch a redirect, answer one question: is the original page gone for good, or is a link simply pointing visitors somewhere else for now? That single decision determines whether you need a 301 redirect or a 302 redirect, and it shapes how search engines and browsers treat the page afterwards.

A 301 redirect tells browsers and search engines a page has moved permanently and the new address should replace the old one everywhere, while a 302 redirect says the move is temporary and the original address should stay in use. Get this right and visitors land in the correct place, link equity moves where it should, and your site avoids the messy signals that come from mismatched redirects.
This matters beyond website pages too. A business running a branded link, a QR code on a flyer, or a shortened link in a social bio relies on the destination staying reachable even when the underlying page changes behind the scenes. Understanding the difference between a permanent redirect and a temporary one helps you make that call with confidence, whether you are migrating a site or just updating where a link sends people. If you manage an r.nz link through Registry, you can change the destination page at any time without needing to touch the public link itself, which is a related but distinct kind of flexibility from choosing an HTTP status code during a website migration.
What Do 301 and 302 Tell Browsers?

A 301 and a 302 are both HTTP status codes, three-digit responses a server sends before a browser loads a page. The number itself carries meaning: anything starting with 3 signals a redirect, and the exact code tells the browser (and any search engine crawler) how to treat the move.
How Does an HTTP Redirect Work?
When someone requests a URL, the server can respond with content directly (status 200) or redirect them elsewhere. An HTTP redirect response carries a 3xx status code and a Location header pointing to the new address. The browser then makes a second request to that new URL automatically, usually in a fraction of a second.
What Changes When a Move Is Permanent or Temporary?
The distinction between permanent and temporary redirects is a statement about the original address, not a promise about how long the redirect itself stays active. A permanent redirect says the old URL is finished and the new one takes over; a temporary redirect says the old URL remains the real destination and the detour will end. As http.dev explains, permanent redirects let search engines replace the old address in the index, while temporary redirects keep the original address indexed and expect traffic to return there eventually.
Caching follows the same logic. A 301 response is cacheable by default, so a browser that has seen one stops asking the old address altogether, which is exactly why getting the choice wrong on a permanent redirect can be awkward to undo later. A 302 is not cached by default, so a change of destination takes effect on the very next request rather than being locked into a visitor’s browser.
301 and 302 at a Glance
| 301 Redirect | 302 Redirect | |
|---|---|---|
| Meaning | Moved permanently | Found (temporary) |
| Browser caching | Cached by default | Not cached by default |
| Search engine treatment | Replaces old URL in index over time | Keeps original URL indexed |
| Typical use | Domain or URL migration | Maintenance, A/B test, short-term swap |
| Reversing it | Can be slow due to caching | Takes effect quickly |
When Should You Use Each Redirect?

The right redirect depends on whether the original URL is ever coming back into use. Permanent moves such as a site migration, domain migration, or HTTP to HTTPS migration call for a 301; short-term situations such as site maintenance or A/B testing call for a 302.
Use a 301 for a Lasting Page or Domain Move
A 301 is the right choice whenever a URL structure change is final: you have renamed a page, merged two pages, moved to a new domain, or retired a URL for good with no plan to bring it back. This covers most real-world website changes, from a rebrand to cleaning up outdated content that now lives at a cleaner address.
Use a 302 for a Short-Term Detour
A 302 fits situations where the original page is temporarily unavailable but will return, such as a maintenance window, a seasonal out-of-stock product page, or one leg of an A/B test. Because the original URL stays indexed, search engines keep treating it as the canonical page, which is exactly the point when the change is genuinely short-lived.
One common misconception worth correcting: a 302 is not guaranteed to stay uncached forever just because it lacks caching by default. Browsers and intermediate caches can still hold onto a 302 if the server sends explicit cache headers telling them to, so relying on “302s are always fresh” as a rule of thumb is not entirely safe.
How Should an Editable Branded Link Be Treated?
A branded short link, such as an r.nz subdomain, behaves differently to a page-level redirect inside a single website. With Registry, the link itself (for example, yourbrand.r.nz) stays fixed while you update the destination page from the dashboard as your website, offer, or campaign changes, which is useful for signage, QR codes, and printed materials where reprinting is impractical. That is a separate question to the 301-versus-302 decision you make when restructuring pages within a site you control, and this article does not claim a specific status code applies to Registry’s own redirect links.
How Do Redirects Affect Search Visibility?

Permanent and temporary redirects send different canonicalization signals to search engines, which influences which URL gets indexed and how link signals flow between old and new pages. Neither status code guarantees a specific outcome on its own; Google still evaluates content, consistency, and other signals before deciding.
Which URL Might Google Index?
A 301 sends a strong signal that the destination URL should become the canonical version, and Google often treats it that way, according to Moz’s guide to redirection. A 302 sends a weaker signal, and search engines tend to keep the original URL as the indexed one while treating the destination as temporary.
It is worth being precise here: a 301 is a strong hint, not a command. Google can still choose a different canonical URL if other signals, such as a conflicting canonical tag or inconsistent internal links, point elsewhere. Checking what Google actually selected, rather than assuming the redirect alone settled it, avoids surprises.
What Happens to Backlinks and Ranking Signals?
A 301 is designed to carry link equity, the accumulated ranking value from backlinks, from the old URL to the new one, according to Moz. A 302 does not transfer that value in the same way, because the old URL is expected to remain the live, indexed page.
Search engines take time to discover a redirect and credit the new page with the old page’s trust and rankings, a process that can run longer on pages Googlebot visits infrequently. During that window, organic traffic to the moved page can dip slightly before settling, which is normal rather than a sign something has gone wrong.
How Do You Keep Migration Signals Consistent?
Canonical tags, your XML sitemap, and your redirects all need to agree, or Googlebot receives mixed signals about which URL matters. If a redirected URL still sits in your sitemap, or a canonical tag points somewhere a 301 does not, crawl budget gets spent untangling the contradiction instead of indexing new content.
Keep internal links updated to point directly at the new URLs rather than relying on redirects to catch every click. This reduces unnecessary hops and helps both users and crawlers reach the right page on the first try, a point covered in more detail in this guide to how domain redirects work.
How Can You Set Up and Check a Redirect?

Checking a redirect properly means looking at the first server response, the final destination, and what Google has actually indexed, as three separate checks rather than one glance at the address bar. Tools such as a redirect checker, Screaming Frog, Rank Math, and Google Search Console each answer a different part of that question.
Check the First Response, Not Just the Destination
The address bar only shows you where you ended up, not the status code the server sent along the way. A redirect checker or browser developer tools will show the actual HTTP status code, which matters because a page that looks right can still be returning the wrong code, for example a 302 where a 301 was intended.
Avoid Chains, Loops and Irrelevant Destinations
A redirect chain happens when URL A sends to B, which sends to C, and each extra hop costs load time and a portion of transferred value. Googlebot follows a limited number of hops in a chain before giving up, so keeping redirects to a single step from old URL to final destination protects both speed and crawl budget, as detailed on http.dev.
A redirect loop, where A sends to B and B sends back to A, stops the page loading altogether; browsers give up after a set number of hops and show an error. Equally, redirecting everything to a homepage instead of a genuinely relevant page risks Google treating the destination as a soft 404, a page that looks live but offers no real match for what was requested, which erases the value a proper redirect was meant to preserve.
Check Caching and Search Results Separately
Browser caching and search indexing are two different systems, and confirming one does not confirm the other. Clearing your browser cache or testing in a private window shows you the live server response, while Google Search Console’s URL Inspection tool shows you which URL Google has actually chosen as canonical, information you cannot get from a browser test alone. Running both checks after a migration or a bulk URL structure change is the most reliable way to confirm the move landed the way you intended, and it is a habit worth building into every site maintenance routine involving 404 errors or outdated content clean-up.
Choose the Status That Matches the Move
A 301 fits a permanent move: a page, section, or whole domain that is not coming back to its old address. A 302 fits a genuine short-term detour, such as maintenance or a time-boxed test, where the original URL should stay the one search engines treat as current.
Neither code forces a particular outcome on its own. Google can still select a different canonical URL, caching behaviour can vary depending on the headers a server sends, and the only way to know what actually happened is to check the first response, the final destination, and the canonical URL Google Search Console reports. A branded link whose destination you can update, such as an r.nz subdomain managed through subdomain redirect tools, solves a related but separate problem: keeping a printed or shared link usable without touching a status code at all.
Frequently Asked Questions
Does a 302 redirect hurt SEO?
A 302 does not damage SEO when it matches a genuinely temporary situation, such as maintenance or an A/B test. Problems arise when a 302 is left in place for a move that turns out to be permanent, because the original URL keeps getting indexed while the new one struggles to accumulate ranking signals.
Can Google index the destination of a 302 redirect?
Google can index a 302’s destination, but it tends to keep the original URL as the canonical, indexed version because the redirect signals the move is temporary. This is a tendency rather than a rule, since Google weighs other signals too, so checking the URL Inspection tool in Google Search Console confirms what actually happened for a specific page.
Is a 301 redirect difficult to undo?
A 301 can be awkward to reverse because browsers cache it aggressively by default, meaning visitors who already followed it may keep landing on the new URL even after you remove the redirect. Clearing the cache or waiting it out resolves this for individual visitors, but it is one reason to be confident a move is permanent before setting a 301.
Which redirect should I use when changing a short link’s destination?
Updating where a branded short link points, such as an r.nz subdomain, is handled through the dashboard rather than by choosing an HTTP status code yourself. This is a different task to migrating pages on a website you manage directly, where you select between a 301 and 302 based on whether the original URL is staying or going for good.
When should I use a 307 or 308 instead?
Use a 307 or 308 when the redirected request is not a simple page load but something like a form submission or API call that must keep its original method, such as POST. A 307 is the temporary, method-preserving equivalent of a 302, and a 308 is the permanent, method-preserving equivalent of a 301, as described by http.dev’s breakdown of redirect status codes.













