Technical SEO Field Reference, Question 22 of 66. The interview answer, checked against what Google currently documents.
Use a temporary redirect, usually a 302, when you want visitors sent elsewhere but the original URL kept in Google’s results, and you intend to bring the original back. Google documents two such cases: a test that sends users from an original URL to a variation, and a service that is temporarily unavailable. A temporary redirect is not a hedge for a move you have not decided on.
The question sounds like a trick, because the obvious advice is to use a permanent redirect for everything. It is meant to find out whether you understand why a temporary one exists at all.
The answer is not “when in doubt”. It is a specific intention: this URL is staying, the destination is temporary, and I know when I will remove the redirect.
Why the temporary redirect decision matters
The risk with a temporary redirect is not that it fails. It is that it succeeds, and nobody removes it.
A test finishes, a service comes back, a promotion ends, and the redirect stays in the config for a year. By then it is a permanent move wearing a temporary label, and the original URL it was protecting may be quietly losing the traffic it was meant to keep.
Interviewers ask this to find out whether you plan the end of a redirect at the same time as its start.
What Google says about a temporary redirect
Google’s redirects documentation says temporary redirects show the source page in search results, and that the indexing pipeline does not use them as a signal that the target should be canonical. Its own example is a service that is temporarily unavailable: send users to a page that explains what is happening, without compromising the original URL in search results (page last updated 14 April 2026).
The clearest documented case is testing. Google’s guidance on website testing says that if you redirect users from the original URL to a variation, you should “use a 302 (temporary) redirect, not a 301″. The reason it gives is that this tells search engines the redirect is temporary and that they should keep the original URL in the index. The same guidance recommends rel=”canonical” on the variation URLs pointing at the original, not noindex, and says to run the experiment only as long as necessary (page last updated 10 December 2025).
For a site that is shut, a redirect is not Google’s recommendation. The guidance on pausing a website says to return an informational page with a 503 status for a closure of one or two days, and to provide an indexable home page as a placeholder, with a 200 status, for longer closures.
The interview answer for a temporary redirect
I would use a temporary redirect when the original URL must stay in search and the redirect has an end date. The documented cases are A/B tests that send users to a variation URL, and a page or service that is temporarily replaced by an explanation. In both cases I would use a 302, or a 307 if preserving the request method matters, because Google treats them the same, as the HTTP redirects question covers. I would remove the redirect when the reason ends, and for a full closure I would use a 503 or an indexable placeholder home page, not a redirect.
When a temporary redirect fits
A pricing page example of a temporary redirect
Say /pricing/ is being tested against a new layout at /pricing-b/. Half of visitors are sent to the variation by the testing tool.
I would check four things before launch. The redirect returns a 302, which I would confirm with a header check. The variation carries a canonical pointing at /pricing/. The variation is not in the sitemap, because a sitemap listing it would send the opposite signal. And the test has an end date.
When the test ends, I would remove the redirect first. If the variation wins, I would put the winning content on the original URL and retire the variation, instead of leaving a redirect to it in place. That is my interpretation, because it keeps the URL that already has history. If I wanted the variation URL to become the main page, that would be a permanent move, so I would switch to a 301 and treat it as a new decision.
How a temporary redirect behaves alongside other signals
The documented value of a temporary redirect is that the source stays in view. That only works while the redirect is genuinely temporary. Google’s documentation says the target might still be indexed if other canonicalisation signals are present. If internal links, the sitemap and canonical annotations all point at the target, the redirect type will not rescue the source.
A redirect left in place after its purpose has ended is just a mislabelled permanent move. Nothing in the documentation I read says Google will fix the label for you, so I treat the end date as part of the implementation, not an afterthought. A reminder in the project plan is as important as the rule itself.
What to check on a temporary redirect while it is live
While the redirect is live, I would check that the status is still a 302 after every deploy, because server rules get rewritten. I would check that the source URL is still the one indexed, using URL Inspection on the original. And I would check that nothing else, such as internal links or the sitemap, has started pointing at the destination.
When the end date arrives, I would remove the rule, retest the original URL with curl, and confirm it returns a 200 with the content I expect.
The interview trap on the temporary redirect
The trap is using a 302 as a way of avoiding a decision. In a migration, a team that is unsure about the new structure picks a temporary redirect because it feels reversible. If the move is intended, that gives Google the wrong statement, and the old URLs may keep appearing. It is the failure mode described in the previous question on 301 and 302.
The second trap is reciting “302 for anything temporary” and stopping. The better answer names the situation, the end date and the check afterwards. It also knows that a closure is a 503 job, not a redirect job.
Takeaway
Use a temporary redirect when the original URL must stay in search and the redirect has an end date.
Put the end date in the plan, check the status after every deploy, and remove the rule when the reason ends.
Have questions about this topic? Contact The GEO Lab · Return to homepage