How 307 and 308 work
Every request to a server carries a method as well as an address. Asking to read a page is one method; submitting a form with data attached is another. When a redirect sends the request somewhere else, that method either travels with it or it does not.
The older redirect codes were vague on this point, and browsers settled it by convention rather than by rule: a form submission that met a 301 or a 302 was commonly turned into a plain page request, and the submitted data was dropped. That behaviour became so widespread it could not be changed, so two stricter codes were defined instead. A 307 is a temporary redirect that must keep the method; a 308 is a permanent redirect that must keep the method.
The mapping is easy to hold in your head. In terms of what they mean for search, 308 sits alongside 301 as the permanent one, and 307 sits alongside 302 as the temporary one. The difference is only about what happens to the request itself.
Why 307 and 308 matter
They matter most where data is being sent, not where pages are being read. Forms, checkouts, payment callbacks and interfaces between systems all rely on the method surviving the hop. A submission that quietly becomes a page request arrives empty, which produces the sort of bug where a form works on one address and fails on another for no visible reason.
You will also meet a 307 without anyone having set one. When a site is on the browser’s list of addresses that must always be secure, the browser rewrites the request itself before it leaves the machine, and the developer tools record that as an internal 307. It is the browser’s own note to itself, not a response from your server, which is why it will not appear in a crawl. It is worth recognising when you are debugging HTTPS.
Common mistakes with 307 and 308
The first is reaching for them when an ordinary page has moved. For a normal URL change, a 301 remains the sensible choice: every plugin, hosting panel, crawler and report handles it without ambiguity, and there is no method to preserve when someone is simply reading a page.
The second is treating the internal 307 in developer tools as a server problem. Nothing on your server produced it, and no redirect needs removing. Chasing it wastes an afternoon.
The third is assuming a plugin can set them. Most redirect plugins offer permanent and temporary and nothing else, so where a 308 is genuinely required it usually has to be configured on the server or at the CDN by a developer.
How to act on it
Keep the everyday rule simple: pages that move for good get a 301, pages that move for now get a 302. Reach for 308 or 307 only when a request carries data — a form endpoint, an API path, a payment return address — and losing that data would break something.
When you do use one, test it by making the real request rather than by opening the URL in a browser, because a browser only ever reads pages. And record the choice somewhere your developer will find it, since a redirect nobody understands tends to be replaced with the wrong one at the next redesign.