301 redirect

## Why it matters

The 301 is the workhorse of every site migration. Its permanence, though, is exactly what makes it risky. Browsers are allowed to cache a 301, so a mistaken one keeps firing for returning visitors long after you've fixed the server. Test any move with a temporary redirect first. Confirm it lands where you expect. Only then harden it to a 301.

## How it works

The server responds with a 301 status and a Location header pointing to the new address. The browser makes a fresh request to that address. Because the 301 is permanent, it may store the mapping and reuse it on later visits without asking the server again.

Search engines interpret the same response differently. Google's guidance is to use a permanent redirect for any move; it treats the 301 as the signal that the target is the canonical URL. Over time, it consolidates the old URL's signals onto the new one and removes the old address from the index.

Here's the catch: RFC 9110 allows a client to change a POST into a GET when following a 301 (for historical reasons). So a 301 is not safe for an endpoint that receives form or API submissions. That's exactly why the 308 exists. It's the permanent redirect that preserves the method and body.

## What doesn't matter

The redirect world carries more fear than warranted.

• A correctly used 301 doesn't leak ranking value. Google treats a permanent redirect as the signal for which URL to index and recommends permanent server-side redirects for moves. Signals move to the new URL rather than draining away. The real cost of redirects is latency and crawl budget; that's an argument against long chains, not against the 301 itself.
• There's no bonus for staying under some arbitrary redirect limit. Browsers and crawlers do follow a bounded number of hops, but the reason to collapse a chain is speed, not a Google penalty.
• Redirecting a batch of retired URLs to your homepage doesn't preserve their value. Google can treat a redirect to an unrelated page as a soft 404, the same as if the page were gone. Map each old URL to its closest match instead.

## Code example

A clean migration points every entry variant straight at the final URL in one hop.

# One rule, straight to the canonical HTTPS host. No extra hops.
server {
    listen 80;
    server_name scalpellabs.ai www.scalpellabs.ai;
    return 301 https://scalpellabs.ai$request_uri;
}
Copy

Confirm it's a single hop with curl. The -I flag shows headers only; -L would follow the chain if there were more.

$ curl -sI https://scalpellabs.ai/old-pricing
HTTP/2 301
location: https://scalpellabs.ai/pricing
Copy

The shape to avoid is a chain, where a protocol rule, a host rule, and a slug change each add a hop before reaching content.

# Avoid: http to https, then non-www to www, then the slug change
# as three separate 301s. That's three round trips for one move.
Copy

## How Scalpel shows it

Scalpel Redirects records every hop for your current tab and lays the chain out one card per hop. A 301 hop gets an amber status chip and a "301 Moved Permanently" connector. The toolbar badge shows the hop count, making a single-hop migration easy to tell apart from a chain that should be collapsed. The chain is observed from your browser navigation alone; nothing is sent to a server.