Technical SEO Field Reference, Question 20 of 66. The interview answer, checked against what Google currently documents.
Google groups redirects into permanent and temporary. For HTTP redirects, it treats 301 and 308 alike, and 302 and 307 alike. Permanent redirects signal that the destination should become canonical. Temporary redirects are intended to preserve the source URL in search, although other canonical signals can affect the outcome. Google also recognises meta refresh, HTTP refresh and JavaScript redirects. Server-side HTTP redirects have the highest chance of being interpreted correctly.
Ask someone to name the main HTTP redirects relevant to SEO and you will usually get four numbers: 301, 302, 307 and 308.
That is a reasonable start. I would then want to hear when they would use each one and how they would check the implementation.
A browser reaching the right page does not tell us whether the redirect sends the right signal to Google.
Why HTTP redirect types matter
A permanent move can work perfectly for visitors while the server still describes it as temporary. Everyone reaches the new page, the ticket gets closed, and the original URL remains in search longer than expected.
The interview question tests whether you can connect the status code to the intended outcome.
I would expect someone to explain the permanent and temporary groups, recognise redirects outside HTTP status codes, and check what the server actually returns.
This question covers the available methods. The next two look more closely at choosing between permanent and temporary redirects, including when a temporary redirect is appropriate.
What Google says about HTTP redirects
Google’s redirect guidance starts with which URL you want shown in search.
Its permanent group includes 301 and 308, zero-second meta and HTTP refresh redirects, and JavaScript location changes. Its temporary group includes 302, 303 and 307, plus meta and HTTP refresh redirects with a delay above zero seconds.
The methods are listed in order of how reliably Google can interpret them. Server-side redirects come first. Google recommends JavaScript redirects only when server-side or meta refresh redirects are not possible, because a rendering failure can prevent it from seeing the redirect.
The HTTP status code documentation adds a practical detail: Google treats 307 as equivalent to 302, and 308 as equivalent to 301. Their HTTP meanings still differ, so the code should suit the request and other clients using the site.
The interview answer for HTTP redirects
I would keep the answer fairly short:
The main HTTP redirects are 301 and 308 for permanent moves, and 302 and 307 for temporary moves. Google also lists 303 as temporary.
Google treats 301 and 308 alike, and 302 and 307 alike. Within each pair, the choice depends on HTTP behaviour, including whether the request method must be preserved.
I would use a server-side redirect wherever possible, then check the response code, destination and any intermediate hops. Meta refresh and JavaScript redirects are alternatives, with JavaScript a last resort because it depends on rendering.
That gives the interviewer something to follow up on beyond a list of numbers.
Types of HTTP redirects Google recognises
I would mention 303 because Google includes it. I would not choose it for a routine SEO redirect without an application requirement behind it.
A homepage example with HTTP redirects
Say a report flags a 307 on the HTTP version of a homepage. Someone proposes changing it to a 301 because “307 isn’t SEO friendly”.
Before changing the configuration, I would check where that 307 comes from.
A browser can display an internal redirect when it upgrades an HTTP request to HTTPS through HSTS. That does not establish which status code the server returns. I would confirm it in DevTools before relying on it.
I would also request the HTTP URL directly and inspect the response headers:
curl -I http://example.com/If the server already returns a 301 to the correct HTTPS URL, I would not change it on the strength of a browser-generated 307.
If the server itself returns a 302 or 307 for a permanent move, I would change the rule to reflect that intention. The next question covers the difference between 301 and 302 in more detail.
The mechanics behind HTTP redirect codes
The distinction within each pair comes from HTTP semantics.
A 307 or 308 preserves the request method and body. That can matter when a request contains a form submission or an API payload. With 301 and 302, clients can change a POST request to GET when following the redirect.
For an ordinary page request, Google’s permanent or temporary classification is usually the main SEO decision. For the application handling that request, method preservation may also determine which code is appropriate.
Redirect chains need checking too. Google documents a default limit of up to 10 hops for its crawlers, with differences between products. Googlebot generally follows 10 when crawling ordinary web content. It ignores content returned by the redirecting URL and processes the final destination’s content.
I would not treat that limit as a target. During a cleanup, I would normally redirect the old URL straight to its intended destination. Every intermediate rule is another place for the chain to go wrong.
What I would check in practice for HTTP redirects
I would start with the old URL and inspect the status code and Location header. Then I would follow the destination and repeat until I reached the intended final page.
curl -I is a convenient first check, but it sends a HEAD request. If the result looks unexpected, I would also inspect a GET response:
curl -sS -D - -o /dev/null http://example.com/I would check that the final page returns the expected response and contains the replacement content. A redirect reaching a 200 page can still send people to the wrong destination.
In Search Console, “Page with redirect” is expected for an old URL that should redirect. I would investigate if that status appeared against a URL we intended to keep available as its own page. Google’s report also notes that the destination may or may not be indexed.
For a removed page with no suitable replacement, I would consider whether a 404 or 410 is the correct response. The question on when 404 errors matter for SEO covers that decision.
Where the redirect consolidates duplicate URLs, I would also check the supporting signals described in the canonical hint question.
The interview trap on HTTP redirects
The answer can go off course when someone starts assigning different amounts of “link equity” to each redirect code without a source.
For this question, I would explain Google’s documented treatment of the codes and the intended canonical outcome. I would not add unsupported percentages or promises about signal transfer.
Dismissing every meta refresh or JavaScript redirect is another mistake. Google recognises both. The implementation choice needs to account for how reliably Google can discover and process the redirect.
Takeaway
Decide whether the move is permanent or temporary, then choose the appropriate method.
Check the actual response and follow it to the final destination. The redirect is ready when the code, destination and intended search behaviour agree.
Have questions about this topic? Contact The GEO Lab · Return to homepage