HTTP 301 Moved Permanently

To a browser: remember this, and go directly to the new URL next time. Browsers may cache a 301 for a long period, and clearing it requires clearing the user's cache — which you cannot do remotely.

To a search engine: index the target instead of the source. Google documents that 301s pass ranking signals to the new URL.

To an HTTP client library: follow the `Location` header, usually converting the method to GET for anything that was not GET or HEAD — which is the historical wrinkle 308 exists to fix.

302 Found: temporary. The original URL stays indexed, and clients keep asking for it.

307 Temporary Redirect: like 302, but guarantees the method and body are preserved. Use it when redirecting a POST.

308 Permanent Redirect: like 301, but also preserves the method. It is the modern permanent redirect for anything other than a plain page.

For ordinary page moves, 301 remains the best-understood choice across every consumer.

`curl -I https://example.com/old-page` prints the status and the `Location` header without following it. Adding `-L` follows the whole chain and prints each hop.

Check that the target is the final destination, not another redirect. Chains form when each migration adds a layer without collapsing the previous one.

Check that the path is preserved. A 301 that sends every old URL to the home page discards the mapping and, for search engines, looks much like a 404.

Using 301 for something temporary. Because it is cached, undoing it is slow and partly outside your control.

Redirecting everything to the home page during a migration. Each old URL should reach its equivalent, and where there is no equivalent, 404 or 410 is more honest.

Leaving internal links pointing at the redirect. The redirect exists for links you do not control; yours should point at the destination.

A 301 can be issued from several layers, and knowing which one produced it is most of the work of changing it.

The DNS provider or registrar, for domain forwarding. This is the layer that most often produces a 302 when a 301 was intended, because the control panel offers no choice.

The CDN or edge proxy — Cloudflare Page Rules, a Vercel or Netlify config, a Fastly VCL. Rules here fire before the origin is reached, so the application never sees the request and cannot explain the redirect.

The web server: an Apache `.htaccess` rule, an nginx `return 301`. Long-lived and easy to forget, because the file is rarely opened.

The application itself, in routing middleware. The most visible layer, and usually the last one a redirect should be added to, because it means the request travelled the whole way before being turned around.

When a redirect behaves in a way nobody can account for, it is almost always a rule in a layer nobody thought to look at.