A temporary redirect is an HTTP redirect that tells browsers and search engines a URL has moved to a different location for now, but the original URL is still valid and is expected to become active again. Unlike a permanent redirect, a temporary redirect does not tell search engines to update their index or transfer SEO equity to the destination. The original URL is preserved exactly as it is.

When a browser encounters a temporary redirect it follows it automatically and loads the destination page. But unlike a permanent redirect, it does not cache the new location. Every visit to the original URL results in a fresh request to the server, which checks whether the redirect is still in place and responds accordingly.

How a temporary redirect works

When a visitor or web crawler requests a URL that has a temporary redirect in place, the server responds with a 3xx status code and a Location header pointing to the temporary destination. The browser follows the location and loads the page at the new URL.

The critical difference from a permanent redirect is what happens next. Because the redirect is temporary, the browser does not store the destination as the new address for that URL. On the next visit, the browser makes a fresh request to the original URL again. This means the server is consulted on every visit, which gives you full control to change or remove the redirect at any time without worrying about cached redirects persisting in browsers.

Search engines behave similarly. Googlebot and other web crawlers follow temporary redirects but continue to index the original URL and return to crawl it on future visits. They treat the destination as a temporary location rather than the canonical address.

Which status codes are temporary redirects

There are three HTTP status codes that signal a temporary redirect:

• 302 redirect: the original and most widely used temporary redirect. Introduced in HTTP/1.0, it is broadly supported across all browsers, crawlers, and HTTP clients. In practice most browsers switch the request method from POST to GET when following a 302, which is acceptable for most standard use cases.

• 303 redirect: a temporary redirect that explicitly switches the follow-up request to GET regardless of the original method. Introduced in HTTP/1.1 to formalise the method-switching behaviour that browsers were already doing with 302. Used primarily in the Post/Redirect/Get pattern after form submissions.

• 307 redirect: a temporary redirect that strictly preserves the original HTTP request method. Introduced in HTTP/1.1 alongside the 303 to provide a temporary redirect that genuinely preserves POST, PUT, and DELETE requests through the redirect. Used primarily in API and application contexts where method preservation matters.

For standard browser-facing temporary redirects where method handling is not a concern, the 302 is the default choice. For application and API contexts, choose between 303 and 307 based on whether you need method switching or method preservation.

Temporary redirects and SEO

The SEO implications of temporary redirects are the most important reason to understand the difference between temporary and permanent. Search engines treat temporary and permanent redirects very differently.

With a temporary redirect, search engines keep the original URL in their index, continue crawling it on future visits, and do not transfer link juice or ranking signals to the destination URL. From Google’s perspective, the original URL is still the authoritative address for that content, the destination is just where it happens to be living right now.

This is the correct behaviour when the redirect is genuinely temporary. But it becomes a serious problem when a temporary redirect is used by mistake for a permanent move. In that scenario search engines keep indexing the old URL, SEO equity never transfers to the new URL, and rankings can stagnate or decline as the old URL gradually loses relevance without its content.

The rule is simple and worth repeating: if a move is permanent, use a permanent redirect. If it is temporary, use a temporary redirect. Mismatching the redirect type to the intent is one of the most common and costly SEO mistakes in redirect management.

When to use a temporary redirect

A temporary redirect is appropriate any time a URL is being redirected for a defined, limited period after which the original URL will return to normal. Common use cases include:

• Site maintenance: redirecting visitors to a holding page or status page while performing maintenance on a site or specific section. Because the original URL will be restored when maintenance is complete, a temporary redirect preserves its place in search engine indexes.

• A/B testing: sending a portion of traffic to an alternative version of a page to test performance, design, or messaging. Since the test will end and traffic will return to the original URL, a temporary redirect is appropriate and avoids permanently altering the SEO status of either URL.

• Seasonal campaigns: redirecting a permanent URL to a seasonal landing page during a promotional period, with the intention of reverting to the original content after the campaign ends.

• Temporary content moves: moving content to a different URL while a page is being redesigned or rebuilt, with a clear plan to restore or redirect permanently once the work is complete.

• Login and authentication flows: web frameworks commonly use 302 and 303 redirects after form submissions and login events to implement the Post/Redirect/Get pattern, preventing duplicate form submissions on page refresh.

• Geo and device redirects: temporarily routing users to region-specific or device-specific pages based on their location or device type during a campaign or rollout period.

Temporary redirects and caching

One of the key practical advantages of temporary redirects over permanent redirects is that they are not cached by browsers. This gives you complete control over the redirect at all times.

With a permanent redirect, once a browser has cached the destination, removing the redirect on the server does not immediately restore access to the original URL for users who have already visited. The cached redirect persists until it expires or the user clears their cache.

With a temporary redirect, no caching occurs. The moment you remove or change the redirect on the server, all subsequent visits to the original URL behave as though the redirect never existed. This makes temporary redirects far safer to use in situations where you are not completely certain about the final destination or duration of the redirect.

This is also why temporary redirects are the safer default when you are unsure whether a move is permanent or temporary. It is straightforward to upgrade a 302 to a 301 once you are certain the move is permanent. Converting a cached 301 back to a temporary redirect is far more disruptive.

How long is too long for a temporary redirect

There is no hard rule on how long a temporary redirect can remain in place before it should be converted to a permanent one. However there are some practical guidelines worth following.

Google has stated that if a temporary redirect remains in place long enough, it may begin to treat the destination as the canonical URL anyway, but this behaviour is unpredictable and not something to rely on. If a situation that started as temporary becomes permanent, update the redirect to a 301 as soon as that decision is made rather than leaving a 302 in place indefinitely.

A good rule of thumb is that any redirect expected to last longer than a few weeks should be evaluated carefully. If there is no clear end date and no plan for the original URL to return, it is almost certainly a permanent move and should be treated as one.

Common mistakes with temporary redirects

• Using a temporary redirect for a permanent move: the most damaging mistake in redirect management. SEO equity does not transfer, the original URL stays indexed, and rankings suffer over time. Always audit your redirects to ensure temporary and permanent types are being used correctly.

• Leaving temporary redirects in place indefinitely: a redirect set up for a two-week campaign that is still running two years later is a liability. Audit your redirects regularly and clean up anything that has outlived its original purpose.

• Using 302 when 307 is needed: if your application relies on POST requests being preserved through a redirect, a 302 will not reliably do this. Use a 307 to guarantee method preservation across all compliant clients.

• Creating redirect chains: chaining multiple temporary redirects adds latency on every visit since each hop requires a fresh server request. Keep redirects direct and audit for redirect chains regularly.

• Not having a plan for the original URL: every temporary redirect should have a clear end condition. What happens to the original URL when the redirect is removed? Where does traffic go? Defining this upfront avoids confusion and technical debt later.