What Is a 301 Error? (Spoiler: It's Not Actually an Error)

Search "301 error" and you will find millions of results from people trying to fix something that is not broken. A 301 is not an error. It is a redirect. It is the server telling your browser: "This page has permanently moved to a new address. Go there instead."

But people keep calling it a "301 error" because that is how it feels when something goes wrong. A page you expected to load sends you somewhere unexpected. A website you manage is throwing 301s in a crawl report and you do not know why. An SEO audit flags hundreds of 301s in red.

This article explains what a 301 actually is, why people confuse it with an error, and when a 301 really does signal a problem you need to fix.

For the full technical breakdown of the 301 status code, see 301 Moved Permanently Explained. For a comparison with temporary redirects, see 301 vs 302 Redirects.

Why people call it a "301 error"

HTTP responses come with three-digit status codes. The ones that start with 4 (like 404 Not Found) and 5 (like 500 Internal Server Error) are actual errors. They mean something went wrong.

Status codes starting with 3 are redirects. They mean the resource exists, but at a different address. The server is helping you get there. That is not an error. It is a feature.

But most people do not memorize HTTP status code ranges. They see a three-digit number in a tool or error log, and their brain files it under "error." Google Search Console groups redirects alongside crawl issues. SEO tools flag 301s in yellow or red warning colors. Browser developer tools show 301 responses in a different color than 200 OK responses.

The language around 301s reinforces the confusion. People talk about "fixing 301 errors" when they mean "fixing a broken redirect." They talk about "301 error codes" when they mean "301 status codes." The terminology is wrong, but it is everywhere.

Here is the reality: a 301 by itself is perfectly normal. Every major website uses hundreds or thousands of them. Google, Amazon, Wikipedia. They all return 301 redirects constantly. The 301 only becomes a problem when the redirect is misconfigured.

What a 301 actually does

When your browser requests a URL and the server responds with a 301, the exchange looks like this:

GET /old-page HTTP/1.1
Host: example.com

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

Your browser reads the Location header and makes a new request to /new-page. This happens automatically. The user typically never notices because the redirect completes in milliseconds.

The "Moved Permanently" part tells the browser (and search engines) that this change is intentional and long-term. The browser can cache the redirect so it does not need to check the old URL again. Search engines transfer ranking signals from the old URL to the new one. [1]

For the full HTTP specification details, see our HTTP Redirect Guide.

When a 301 is completely normal

Most 301s are intentional and correct. Here are situations where 301s are expected and healthy:

HTTP to HTTPS. Every request to http://example.com should 301 to https://example.com. This is standard security practice and Google expects it.

www to non-www (or vice versa). Sites pick one canonical version of their domain. The other version 301s to the canonical one. www.example.com might 301 to example.com, or the other way around.

Old URLs after a site redesign. When you restructure your site's URLs, 301 redirects send visitors (and link equity) from the old URLs to the new ones. This is exactly what 301s are designed for.

Trailing slash normalization. /about might 301 to /about/ (or the reverse). This keeps your site consistent and avoids duplicate content issues.

Domain changes. When a company rebrands, every URL on the old domain 301s to the equivalent page on the new domain.

If you see 301s in a crawl report and they fall into one of these categories, there is nothing to fix. The redirects are working as intended.

When a 301 actually signals a problem

There are real situations where a 301 indicates something has gone wrong. These are the "301 errors" people are actually worried about.

Redirect loops

A 301 that points to a URL that 301s back to the original creates an infinite loop. The browser follows the redirects until it gives up and shows an error like ERR_TOO_MANY_REDIRECTS in Chrome.

/page-a --301--> /page-b --301--> /page-a --301--> (loop forever)

This is one of the most common redirect problems. It often happens when conflicting redirect rules exist in different parts of your stack (server config, CDN, application code). See What Is a Redirect Loop for causes and fixes.

Redirect chains

A redirect chain is when a 301 points to another 301, which points to another 301, before finally reaching the destination.

/old-page --301--> /newer-page --301--> /newest-page --301--> /current-page

Each hop adds latency. Search engines follow chains, but they can lose patience after multiple hops. The fix is to update the first redirect to point directly to the final destination. See Redirect Chains Explained for details.

Wrong destination

The redirect works, but it sends users to the wrong page. This is a configuration mistake. Someone set up the 301 with an incorrect destination URL. The redirect itself is technically fine. The problem is where it goes.

This is especially damaging when the destination is a 404 page. Users get redirected only to hit a dead end. Search engines see the 301 and try to transfer equity to a page that does not exist.

Accidental 301s

Sometimes a redirect rule is too broad and matches URLs it should not. A rule meant to redirect /blog/old-post to /articles/old-post might accidentally match /blog/contact and redirect that too.

# Too broad: redirects everything under /blog/
RewriteRule ^blog/(.*)$ /articles/$1 [R=301,L]

If /articles/contact does not exist, users who visit /blog/contact will get a 301 to a 404. Two problems stacked on top of each other.

301s where 302s should be

A 301 is permanent. A 302 is temporary. If you use a 301 for a redirect that you plan to reverse later (seasonal content, A/B tests, temporary maintenance pages), you create a problem. Browsers cache 301s aggressively. When you remove the redirect, users who cached it will still be redirected until their browser cache expires.

This is hard to undo because you cannot clear other people's browser caches. For the difference between permanent and temporary redirects, see 301 vs 302 Redirects.

How to check if a 301 is working correctly

Using curl

The quickest way to check a redirect from the command line:

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

This returns the response headers without downloading the body. You should see:

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

Using browser developer tools

Open DevTools (F12), go to the Network tab, and load the URL. The redirect response will appear in the request list with a 301 status code. Click it to see the Location header and caching headers.

Using Redirect Tracer

For a visual breakdown of the entire redirect chain with status codes, response headers, and timing for each hop, run the URL through Redirect Tracer. This is faster than reading raw curl output when you are checking multiple URLs or debugging chains.

What search engines think about 301s

Google treats a 301 as a signal to transfer ranking signals from the old URL to the new URL. This is well-documented and has been confirmed repeatedly by Google engineers. [1]

A single, clean 301 redirect is the best way to move a page without losing search rankings. Google will:

1. Follow the redirect to the new URL
2. Transfer link equity (PageRank) to the new URL
3. Eventually drop the old URL from the index and show the new URL in search results

This process takes time. You might see both URLs in Google's index during the transition. That is normal and resolves on its own.

The situations where 301s hurt your SEO are the problem scenarios described above: loops, long chains, redirects to 404s, and using 301 when you meant 302. A clean 301 to the right destination is always good for SEO.

How to audit your site for 301 problems

If you are worried about "301 errors" on your site, here is what to actually check:

Check for redirect chains. Crawl your site and look for any redirect that goes through more than one hop. Flatten chains so every redirect points directly to the final destination.

Check for redirect loops. Look for any URL that never reaches a final 200 OK response. These need to be fixed immediately because the affected pages are completely inaccessible.

Check destinations. Verify that every 301 redirect leads to a page that returns 200 OK. A 301 that leads to a 404 or another error is worse than no redirect at all.

Check for unintended 301s. Compare your intended redirect rules against what actually happens. Broad regex patterns in redirect rules can match URLs you did not expect.

Check cache headers. Make sure your 301 responses include a Cache-Control header with a reasonable max-age. This gives you the ability to correct mistakes within a bounded window.

The bottom line

A 301 is a redirect, not an error. It is the standard way to permanently move a URL on the web. Every website uses them. Search engines expect them. Browsers handle them automatically.

The only time you need to worry about a 301 is when the redirect itself is broken: it loops, it chains through too many hops, it goes to the wrong destination, or it was supposed to be temporary. Fix those specific problems. Leave the healthy 301s alone.

References

1. IETF, "RFC 9110 - HTTP Semantics, Section 15.4.2: 301 Moved Permanently," June 2022. https://httpwg.org/specs/rfc9110.html#status.301