An HTTP status code that permanently redirects a request while requiring the client to preserve its method and request body at the new URL.
An HTTP status code that permanently redirects a request while requiring the client to preserve its method and request body at the new URL. This guide focuses on the decision, the checks, and the limits that matter in a real review.
What a 308 redirect controls
HTTP 308 is a permanent redirect defined for a case where the request method matters. The response supplies a new location and tells a conforming client to repeat the request there without changing its method or body. That makes it useful for a permanent move of an API endpoint or form handler where POST, PUT, PATCH, or DELETE semantics must survive the move. It does not rewrite application data, validate the destination, or repair a broken route design. For ordinary document pages reached with GET, 301 is usually the clearer operational choice because the method-preservation property adds no reader-facing value.
Choose the status from the change’s intent
Decide permanence before choosing a number. A 308 says that the old address has been replaced, while 307 communicates a temporary move with method preservation. A 301 also expresses a permanent move, but historical client behaviour can turn a non-GET request into GET. Search engines document permanent redirects as consolidation signals, but a status code does not guarantee when crawling or canonical selection will change. Keep the old URL in the migration inventory until its destination, internal links, canonical policy, and crawl response have been checked.
Implement and test a permanent move
Start with a small URL map: old endpoint, intended final endpoint, reason, and owner. Configure one direct 308 from each retired method-sensitive route to its relevant replacement; avoid sending unrelated requests to a home page. Test an actual request method in a non-production environment, then inspect response status and Location without automatically following it. Repeat with redirect following enabled and verify that the final handler receives the expected method. Finally crawl the old URL list, update internal references to the final URL, and monitor server and search-console evidence separately.
- Define the URL or page set and the expected behaviour.
- Test a representative sample and preserve the raw response or rendered evidence.
- Fix one controllable cause at a time, then retest the same scope.
- Record gaps, exceptions, and follow-up checks rather than calling missing data a pass.
Failure modes and review checks
The common mistake is treating 308 as an SEO upgrade. It is a transport decision, not a ranking tactic. Another is testing only a browser navigation, which exercises GET rather than the POST or PUT path that justified 308. Redirect chains, loops, a missing Location header, a destination returning an error, or a cached old response all need separate investigation. In migrations I map every retired URL to one relevant final destination, then crawl the map to remove chains and loops before I call the work complete. Record what was checked and what was unavailable; a successful one-off request is not coverage of the full route set.
Caching deserves its own check. A permanent response can remain in browser or intermediary caches after a configuration rollback, so test from a clean client and record response cache directives when they matter. Do not vary a redirect merely by user-agent in an attempt to satisfy old clients: that makes the route difficult to reproduce and can create inconsistent crawler evidence. If compatibility forces a fallback, document which clients need it and keep the final URL policy the same for every ordinary requester.