HTTP 301 Moved Permanently: What It Means and When Servers Use It

When a server returns a 301 Moved Permanently response, it is telling the client: "The resource you requested has permanently moved to a different URL. Use the new one from now on." That is the entire message. One status code, one Location header, one clear instruction.

But the simplicity of the 301 hides a lot of nuance in how browsers cache it, how search engines process it, and how a misconfigured 301 can cause problems that persist long after you fix the server. This article covers the full picture.

For a comparison of 301 vs other redirect status codes, see our HTTP Redirect Guide and 301 vs 302 Redirects.

The HTTP response, line by line

Here is what a 301 response actually looks like on the wire:

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page
Content-Length: 0
Date: Mon, 14 Apr 2026 12:00:00 GMT
Cache-Control: max-age=31536000

The key parts:

• Status line (HTTP/1.1 301 Moved Permanently): The status code 301 tells the client this is a permanent redirect. The phrase "Moved Permanently" is the standard reason phrase, though clients rely on the numeric code, not the text.
• Location header: The URL the client should follow. This can be an absolute URL (https://example.com/new-page) or a relative path (/new-page). Absolute URLs are safer and more widely supported.
• Cache-Control: This header controls how long the browser remembers the redirect. More on caching below, because this is where most 301 problems originate.

The response body is typically empty or contains a short HTML page with a link to the new URL for clients that do not follow redirects automatically.

What the spec says

RFC 9110 (the current HTTP semantics specification) defines 301 in Section 15.4.2: [1]

The 301 (Moved Permanently) status code indicates that the target resource has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs.

Two things to note from the spec:

1. The redirect is permanent. Clients are expected to update bookmarks, links, and cached references.
2. The spec says clients "ought to" use the new URI. For browsers and search engines, this is effectively mandatory. They will follow it.

The spec also notes that for historical reasons, a client may change the request method from POST to GET when following a 301. If you need to preserve the POST method, use a 308 Permanent Redirect instead. For standard page-to-page redirects (GET requests), this distinction does not matter.

How browsers handle a 301

When a browser receives a 301:

1. It reads the Location header
2. It makes a new request to the URL in that header
3. It caches the redirect according to the Cache-Control and Expires headers
4. On subsequent visits to the original URL, it may skip the server entirely and redirect from cache

That last point is critical. Browsers cache 301 redirects aggressively. Chrome, Firefox, and Safari all cache 301s by default, and the cache can persist for days, weeks, or even months depending on the cache headers.

The caching problem

If you set up a 301 redirect and later realize you pointed it to the wrong destination, fixing the redirect on the server does not immediately fix it for users who already cached the old redirect. Their browsers will keep sending them to the wrong URL until the cache expires.

Day 1:  /old-page --301--> /wrong-page  (cached by browser)
Day 2:  You fix it on the server: /old-page --301--> /correct-page
Day 2+: User's browser still goes to /wrong-page from cache

This is why 301 redirects should be tested thoroughly before deployment. Undoing a cached 301 requires either waiting for the cache to expire or having affected users clear their browser cache manually.

To control how long browsers cache your 301, set an explicit Cache-Control header:

Cache-Control: max-age=86400

That gives you a 24-hour window. Long enough for search engines to register the redirect, short enough that a mistake is recoverable within a day. Some servers default to caching 301s indefinitely if no Cache-Control header is set.

How Google handles a 301

Google's crawler (Googlebot) processes 301 redirects in several stages: [2]

Crawling

When Googlebot encounters a 301, it follows the redirect to the new URL and crawls that page. It also records the redirect mapping in its internal systems. Googlebot will continue to periodically re-check the old URL to confirm the redirect is still in place, but the frequency of those checks decreases over time.

Indexing

After confirming the 301, Google replaces the old URL with the new URL in its index. This does not happen instantly. For well-known pages, the swap can happen within days. For less frequently crawled pages, it can take weeks.

During the transition period, you may see both the old and new URLs appearing in search results. This is normal and resolves on its own.

Link equity (PageRank)

Google confirmed that 301 redirects pass full ranking signals with no dampening factor. [3] All of the link equity, anchor text signals, and other ranking factors associated with the old URL transfer to the new URL through the 301.

This makes 301 the correct choice for any permanent URL change where you want to preserve your search rankings.

Removal of old URL

After a sustained period (typically a few months), Google drops the old URL from its index entirely and stops crawling it. The new URL fully inherits the old URL's position in search results.

Common use cases for 301

Domain migrations

Moving from oldbrand.com to newbrand.com. Every URL on the old domain gets a 301 to its equivalent on the new domain. This is the highest-stakes use of 301 redirects. See our site migration redirect checklist for the full process.

URL restructuring

Changing your URL scheme from /blog/2024/my-post to /articles/my-post. The old URL gets a 301 to the new one. If you are restructuring many URLs at once, watch for redirect chains forming when new redirects stack on top of old ones.

HTTP to HTTPS migration

After enabling HTTPS, all HTTP URLs should 301 to their HTTPS equivalents. This is one of the most common 301 implementations on the web. See HTTP to HTTPS Redirect Guide.

Consolidating duplicate content

When the same content is accessible at multiple URLs (with/without trailing slash, with/without www, with/without query parameters), 301 redirects consolidate them to a single canonical URL.

Removing old pages

When you delete a page that has backlinks or traffic, a 301 to the closest relevant replacement page preserves the link equity and gives users a useful destination instead of a 404.

301 vs other 3xx status codes

The full list of redirect status codes includes several alternatives to 301:

301 Moved Permanently   - Permanent, may change POST to GET
302 Found               - Temporary, may change POST to GET
303 See Other           - Temporary, always changes to GET
307 Temporary Redirect  - Temporary, preserves request method
308 Permanent Redirect  - Permanent, preserves request method

For standard website pages where all requests are GET, 301 and 302 are the only codes you need to think about. The decision between them is straightforward: use 301 when the move is permanent, 302 when it is temporary. For the detailed comparison, see 301 vs 302 Redirects.

Implementation examples

Apache (.htaccess)

# Single page redirect
Redirect 301 /old-page https://example.com/new-page

# Pattern-based redirect
RewriteEngine On
RewriteRule ^blog/(.*)$ /articles/$1 [R=301,L]

Nginx

# Single page redirect
location = /old-page {
    return 301 https://example.com/new-page;
}

# Pattern-based redirect
location /blog/ {
    rewrite ^/blog/(.*)$ /articles/$1 permanent;
}

Application-level (Node.js / Express)

app.get('/old-page', (req, res) => {
  res.redirect(301, '/new-page');
});

Cloudflare

Cloudflare Redirect Rules and Page Rules both support 301 redirects without touching your origin server. See our Cloudflare redirect guide for setup instructions.

Verifying a 301

Use curl to check the status code and destination:

curl -I https://example.com/old-page

The response should show:

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page

To follow the full redirect chain and see every hop:

curl -I -L https://example.com/old-page

If you see multiple 301 hops, you may have a redirect chain that needs flattening. For more testing methods, see How to Check URL Redirects.

Troubleshooting 301 issues

"I changed the redirect but users still go to the old destination"

Browser caching. The user's browser cached the original 301 and is not checking the server again. The user needs to clear their browser cache, or you need to wait for the cache TTL to expire. This is why setting a reasonable Cache-Control header matters.

"Google is still showing the old URL in search results"

Patience. Google can take days to weeks to process a 301 and update its index. Check Google Search Console to confirm Googlebot has crawled the old URL and followed the redirect. If it has, the index update will follow.

"My 301 is creating a redirect loop"

Your redirect rule is matching the destination URL and redirecting it again. This happens when rules are too broad. For example, redirecting all of /blog/* to /articles/* will loop if /articles/ also matches a blog redirect rule. See What Is a Redirect Loop for debugging steps.

"Link equity did not transfer after the 301"

Give it time. Equity transfer is not instant. If rankings have not recovered after 4-6 weeks, check that the redirect is a clean single-hop 301 (not a chain, not a 302 disguised as a 301), and that the destination page is indexable.

The bottom line

A 301 is the workhorse of web redirects. It is the correct choice for any permanent URL change, and Google treats it as a strong signal to transfer ranking equity to the new URL. The main thing to watch out for is caching: once a browser caches a 301, you cannot easily undo it. Test before you deploy, set reasonable cache headers, and keep your 301 redirects in place for as long as external links to the old URL might exist.

References

1. IETF, "RFC 9110 - HTTP Semantics, Section 15.4.2: 301 Moved Permanently," June 2022. https://httpwg.org/specs/rfc9110.html#status.301
2. Google, "Redirects and Google Search," Google Search Central, 2024. https://developers.google.com/search/docs/crawling-indexing/301-redirects
3. Gary Illyes, Google, "30x redirects don't lose PageRank anymore," Twitter/X, July 2016.