301 Moved Permanently: what the response means, and what a 301 does for SEO

301 Moved Permanently is the response a server sends when a URL has moved for good. The browser goes to the new address, Google treats the move as a strong signal to show the new URL instead of the old one, and links to the old URL keep their value. The word that causes trouble is “permanently”. Browsers may cache a 301, so a wrong one keeps sending people to the wrong page after you fix it. And AI assistants may cite your old URLs for years. This post covers what the response means, what it does for SEO, how long to keep it, and how to set one up. To see what any URL returns right now, paste it into the free redirect checker.

Sources: Google^[8][7]; Ahrefs, from 16 million URLs cited by AI assistants^[10]. The 30 days is the Cache-Control header on the 301 Google sent us when we requested one of its own moved help pages on 2 October 2026. It is shown in full below.

What 301 Moved Permanently means

The HTTP standard, RFC 9110, defines it in one sentence. The 301 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”^[1]. The server names the new address in a Location header. The browser follows it without asking and shows the new URL in the address bar.

Here is a real one. On 2 October 2026 we requested the old address of Google’s page about HTTP status codes. Google had moved the page, and this is what came back, shortened to the lines that matter:

$ curl -sI https://developers.google.com/search/docs/crawling-indexing/http-network-errors
HTTP/1.1 301 Moved Permanently
location: /crawling/docs/troubleshooting/http-status-codes
cache-control: private, max-age=2592000

Three lines are worth reading. The status line says the move is permanent. The location says where to go. It can be a relative path, as here, and the client resolves it against the old URL^[1]. And cache-control says a browser may reuse this answer for 2,592,000 seconds, which is 30 days, without asking Google again. That last line is the one most people never look at. It comes up again below.

The method can change. That is what 308 is for.

The standard has one note that matters for developers: “For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 308 (Permanent Redirect) status code can be used instead”^[1]. Browsers do change it. Under the Fetch Standard, a POST answered with a 301 is sent again as a GET^[3]. A form posted to a moved URL arrives without its data.

A 308 also means “moved for good”, but it forbids that change^[4]. Pages that people and crawlers read are fetched with GET, so for them the two codes behave the same, and Google lists a 308 as “Equivalent to 301”^[7]. Use 308 when forms or APIs post to the moved URL. The temporary codes are a different question, covered in 301 vs 302.

Why a wrong 301 is hard to take back

“Permanent” has a practical meaning in browsers. RFC 9110 says “A 301 response is heuristically cacheable”^[1]. So a browser may store the redirect and reuse it without contacting your server, even if you never sent a caching header. The caching standard leaves the details to each cache. It “does not provide specific algorithms” for that guess. It only suggests a cap, with 10% of the time since the response was last modified as “a typical setting”^[2]. No major browser publishes the exact rule it uses for redirects. You cannot predict how long a cached 301 lives.

Here is the consequence. Send a 301 by mistake, then delete the rule, and every browser that already cached it keeps going to the wrong page. You cannot reach those browsers. Clearing your own cache fixes it for you and nobody else. Google’s advice fits: “Use permanent redirects when you’re sure that the redirect won’t be reverted”^[6].

You can limit the damage before it happens. An explicit lifetime overrides the guessing: a cache “MUST NOT use heuristics” when the response states one^[2]. Send Cache-Control: max-age=3600 with a new redirect, and the response “remains fresh until N seconds after the response is generated”^[5], here one hour. After that the browser asks again. Raise the lifetime once you are sure. Google uses 30 days on the redirect above.

What a 301 redirect does for SEO

Most 301 redirect SEO advice comes down to a few sentences in Google’s documentation. Here is what they say, and what they don’t.

It moves the URL in results. For a permanent redirect, “Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical”^[6]. Google’s crawler documentation calls a 301 a “strong signal” and a 302 a “weak signal”. It also ignores any content on the redirecting URL itself^[7].

It carries the links. Canonicalization exists so search engines can “consolidate the signals they have for the individual URLs (such as links to them) into a single, preferred URL”^[9]. On PageRank, Google’s site move guide is direct: “Don’t worry about link credit. 301 and other permanent redirects don’t cause a loss in PageRank”^[8]. Google’s main redirects page doesn’t mention PageRank at all, so the site move guide is the one to quote.

It is a signal, not a command. Google keeps both URLs on file. One becomes canonical. The other becomes an “alternate name”, which “may appear in search results when a user’s query hints that they might trust the old URL more”. After a domain move, Google says it is “very likely” the old URLs will still show now and then^[6]. An old URL in results a month after a move is normal, not a failure.

It takes time. “For medium-sized websites, it can take a few weeks or more for Google to gradually start showing the new URLs instead of the old ones (and for larger sites, even longer)”^[8]. Expect rankings to move around while that happens.

How long to keep a 301

Google’s answer, from its guide to site moves: “Keep the redirects for as long as possible, generally at least 1 year. This timeframe allows Google to transfer all signals to the new URLs, including recrawling and reassigning links on other sites that point to your old URLs.” It adds: “From users’ perspective, consider keeping redirects indefinitely”^[8].

Our view is simpler: keep them for good. The old URL lives on in places you cannot edit. Links on other sites, old newsletters, PDFs, bookmarks, and AI answers built from older data (more on that below). A redirect rule costs almost nothing to keep. Deleting it turns every one of those references into a 404.

What you can retire is your own need for it. Each redirect is an extra round trip, so Google suggests updating “your own links and any high-volume links from other websites to point to the new URLs”^[8]. Internal links, canonical tags and the sitemap should all use the new URL. The 301 is for everyone else.

Send each URL to its closest match

A 301 promises that the content now lives somewhere else. Google checks the promise. “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error.” Merged content is the exception: if several old pages became one new page, they can all point to it^[8].

When there is no equivalent, a 404 or 410 is the honest answer. Google treats every 4xx code except 429 the same way, and a URL that returns one is removed from the index^[7]. That beats a redirect to a page that doesn’t answer the visitor’s question.

Chains: collapse every old URL to one hop

A chain forms when redirects pile up over the years. A typical case: one year /pricing moves to /plans. Two years later /plans moves to /pricing-plans. Both rules still run, so an old link now takes two hops, and a third if it starts on http.

Google’s crawlers follow “up to 10 redirect hops” by default^[7], but its site move guide asks for less: “we advise redirecting to the final destination directly. If this is not possible, keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5. Chaining redirects adds latency for users, and not all user agents and browsers support long redirect chains”^[8].

The fix is a habit. Whenever you add a redirect from B to C, search your rules for anything that points at B and point it at C instead. Paste old URLs into the bulk mode of the redirect checker to find the ones with more than one hop. If two rules point at each other, you have a loop, not a chain. The ERR_TOO_MANY_REDIRECTS guide covers those.

301s, AI crawlers and AI answers

Start with what is not known. No AI company publishes how its crawler handles a 301, how many hops it follows, or when it swaps a URL it has already cited for the new one. Anyone who gives you a number is guessing. What can be measured points one way.

AI answers cite old URLs. Ahrefs checked 16 million URLs cited by ChatGPT, Perplexity, Copilot, Gemini, Claude and Mistral. AI assistants sent visitors to 404 pages 2.87 times as often as Google Search. ChatGPT was highest: 1.01% of the URLs people clicked and 2.38% of all cited URLs returned a 404^[10]. Ahrefs suspects part of the cause is URLs that “may have existed at one time, but have since been deleted or moved (without redirecting the original page)”, especially when an assistant answers from its own memory instead of a fresh search. That is the authors’ reading, not a proven cause, and it is a vendor study.

The reasoning holds even without the numbers. A model trained before your move knows the old URL. An answer built from that memory links to it. If the 301 is still in place, the click lands on the right page. If it isn’t, the click lands on a 404. That is the strongest reason to keep redirects for years, not months.

Only server-side redirects reach every crawler. Vercel’s study of AI crawler traffic on its network found that “none of the major AI crawlers currently render JavaScript”, naming OpenAI’s, Anthropic’s and Perplexity’s crawlers among them^[11]. A redirect done in JavaScript leaves those crawlers on the old page. Even Google says to “only use JavaScript redirects if you can’t do server-side or meta refresh redirects”^[6]. No AI company documents whether its crawler follows a meta refresh either. A 301 or 308 from the server needs no rendering at all.

Redirects already take a share of their crawling. In the same study, 14.36% of the ChatGPT crawler’s fetches went on following redirects, against 1.49% for Googlebot^[11]. Collapsing chains to one hop is the part of that you control.

One more check is worth doing. Some firewalls and bot-protection rules treat crawlers differently from browsers. The redirect checker repeats each chain as GPTBot, ClaudeBot, PerplexityBot and Googlebot. It sends their user-agent strings from our own server, so treat a difference as a lead and confirm it in your logs. The log file analysis guide shows how.

How to check a URL’s 301

A browser never shows you the 301. It follows it before the page loads. To see it, ask the server directly from a terminal:

# One response: the status line, Location and Cache-Control
curl -sI https://example.com/old-page

# Follow every hop, printing each status line and Location
curl -sIL https://example.com/old-page | grep -i "^HTTP\|^location"

Read three things. The status code: 301 or 308 for a permanent move. The Location: the final URL, not another redirect. And the Cache-Control lifetime, if there is one. The redirect checker does the same in the browser, for up to 10 URLs at a time.

Setting up a 301 on your server

The rule everywhere: name the code. Several common tools send a temporary redirect unless you ask for a permanent one. Pick your platform.

# One page
Redirect 301 /old-page https://www.example.com/new-page

# A whole folder, keeping the rest of the path
RedirectMatch 301 ^/blog/(.*)$ https://www.example.com/articles/$1

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

# A whole folder, keeping the rest of the path
rewrite ^/blog/(.*)$ /articles/$1 permanent;

module.exports = {
  async redirects() {
    return [
      // Sends 308 Permanent Redirect
      { source: "/old-page", destination: "/new-page", permanent: true },
      // Sends a literal 301, for clients that need one
      { source: "/blog/:slug", destination: "/articles/:slug", statusCode: 301 },
    ];
  },
};

add_action( 'template_redirect', function () {
    if ( is_page( 'old-page' ) ) {
        wp_safe_redirect( home_url( '/new-page/' ), 301 );
        exit;
    }
} );

A site migration checklist

A migration is where 301s are won or lost: a new domain, a new CMS, or a new URL structure. Google’s advice is to change one thing at a time and to map every old URL before you switch anything on^[8]. Your ticks are saved in this browser only.

Finding redirects across a whole site

Checking the URLs you remember is the easy part. The redirects that cost you are often the ones nobody remembers, such as a sitemap that still lists an old slug. CoreCited’s Site Audit runs a “Clean 200 response” check on every page it audits, and groups the pages that only answer after a redirect into one task, with the fix: point links and the sitemap at the final URL.

Questions people ask

Sources