A 302 redirect is the HTTP status "302 Found" with a Location header. It tells clients the resource is temporarily available somewhere else. Because the move is meant to be temporary, search engines generally keep the original URL as the one to index and show. It suits short-lived detours, such as maintenance, A/B tests, or geo and login routing, and is the wrong choice for permanent URL changes.
How a 302 differs from a 301
Both send the visitor to a new URL, and a person in a browser would not notice a difference. The difference is the instruction to search engines. Google's documentation describes temporary redirects (302, 303, 307) as a weak signal that the redirect target should be canonical, while permanent ones are a strong signal.
In practice, if a 302 stays in place for a long time, Google may decide the move is effectively permanent and start indexing the destination. That is Google interpreting your intent, so it is better to state it correctly from the start.
HTTP/1.1 302 Found
Location: https://www.example.com/maintenance
Cache-Control: no-store302, 303 and 307
HTTP has several temporary redirect codes. A 307 Temporary Redirect is like a 302 but requires the client to reuse the same method and body. A 303 See Other tells the client to fetch the new URL with GET, often used after a form submission. For SEO purposes, Google treats all three as temporary.
Legitimate uses
A 302 is the right call when the original URL will come back and should stay the indexed version.
- Sending visitors to a maintenance page during an outage
- Redirecting logged-out users from app URLs to a login page
- Running a short split test where a variant lives on another URL
- Routing visitors to a seasonal promo page that will be removed
- Language or region routing for first-time visitors (with care, see below)
The SaaS pitfalls
Several common tools issue 302s by default. Some hosting platforms, auth middlewares and framework helpers use temporary redirects unless told otherwise, so a site migration done through them may be signaling "temporary" for every moved URL. Check the actual status code with a crawler or curl rather than trusting the config label.
Automatic redirects based on IP location or browser language can also stop Googlebot, which mostly crawls from the US, from ever seeing your other localized versions. Google recommends hreflang and visible language links over forced redirects for that reason.
Example
A migration done with the wrong code
A hypothetical HR SaaS, Peoplepath, moves its blog from blog.peoplepath.example to peoplepath.example/blog. The redirects are set up in an edge middleware that defaults to 307. Months later, Search Console still shows many old subdomain URLs as indexed, and some still appear in results.
Switching the middleware to a permanent redirect (308 or 301) gives Google a clear, strong signal. The old URLs then drop out as they are recrawled.
Common mistakes
Using 302 for permanent moves
This is the most common redirect error. If the old URL is never coming back, use a 301 or 308.
Forced geo or language redirects
Redirecting based on location can hide your localized pages from crawlers. Offer a banner or selector and use hreflang instead.
Forgetting temporary redirects exist
Temporary redirects set up for a campaign or outage often outlive their purpose. Audit them periodically and remove or convert them.
Questions
A 302 used for a genuinely temporary detour is fine. The risk comes from using one for a permanent move, which can leave the wrong URL indexed and slow consolidation.
Google has said it may, if the redirect stays long enough. It does not publish a timeframe, so do not rely on it.
Yes, a temporary redirect to the login page is normal. Better still, keep app URLs out of search with robots.txt or noindex where appropriate, so crawlers are not spending time on them.
