HTTP 301 Moved Permanently

HTTP 301 Moved Permanently is the standard way to tell clients and search engines that a resource has permanently moved to a new URL. The client SHOULD use the new URL for all future requests. Search engines transfer link equity (PageRank) to the new URL, making 301 the primary tool for URL migration, domain changes, and site restructuring. Critically, many browsers change POST to GET on 301 redirects — if method preservation matters, use 308 instead.

Debug HTTP 301 live

Analyze real 301 behavior — headers, caching, CORS, redirects

Open Inspector →

Try it (live endpoint)

Response includes the status code, standard headers (including Content-Type), and a small diagnostic JSON body describing the request and returned status.

Simulator URL (copy in the app after load — not a normal link):

https://httpstatus.com/api/status/301

Example request:

curl -i "https://httpstatus.com/api/status/301"

Try in playground

Meaning

The URL of the requested resource has been changed permanently.

What it guarantees

A different URI is involved to complete the intent.

What it does NOT guarantee

All clients will automatically follow the redirect.
The redirect target is safe to cache unless headers allow it.

When to use this status

Permanent URL changes (canonicalization, domain migration).
SEO canonical redirects where the new URL should receive indexing signals.
Consolidating duplicate paths into a single canonical endpoint.

When NOT to use this status (common misuses)

Redirecting without a stable Location target.

Clients fail to follow; crawlers lose canonical signals.

Using 301/302 for non-GET methods without understanding method rewriting.

Clients can drop bodies or change methods, causing data loss and client bugs.

Redirect loops or long chains.

Crawlers waste crawl budget; clients hang; retries amplify load.

Critical headers that matter

Location

Tells clients where to go next.

Redirects fail or loop; crawlers lose canonical target.

Cache-Control

Controls whether redirects are cached.

Temporary redirects become sticky; permanent redirects never stick.

Vary

Prevents caches mixing redirect variants.

CDNs serve the wrong redirect for different hosts/headers.

Tool interpretation

Browsers

Follows Location for navigations; redirect caching can make behavior sticky. Redirect code choice affects method/body handling.

API clients

May not auto-follow; strict clients require explicit redirect handling. Incorrect redirect semantics can drop bodies or change methods.

Crawlers / SEO tools

Uses redirects for canonicalization; long chains/loops waste crawl budget and dilute signals.

Uptime monitors

Typically marks success; advanced checks may flag header anomalies or latency.

CDNs / reverse proxies

Can cache redirects; Location/Vary/Cache-Control correctness drives global consistency.

Inspector preview (read-only)

On this code, Inspector focuses on semantics, headers, and correctness warnings that commonly affect clients and caches.

Signals it will highlight

Status semantics vs method and body expectations
Header sanity (Content-Type, Cache-Control, Vary) and evidence completeness
Redirect chain length, loops, Location presence, protocol safety

Correctness warnings

No common correctness warnings are specific to this code.

Guided Lab outcome

Reproduce HTTP 301 Moved Permanently using a controlled endpoint and capture the full exchange.
Practice distinguishing status semantics from transport issues (redirects, caching, proxies).
Validate redirect correctness (Location, hop count, protocol safety) and SEO impact.

Technical deep dive

301 Moved Permanently (RFC 7231 Section 6.4.2) requires the server to include a Location header with the new URI. Historical behavior: despite the spec allowing the redirect to preserve the method, virtually all browsers and HTTP clients convert POST/PUT to GET when following a 301. This is why 308 Permanent Redirect was created. SEO impact: Google treats 301 as a signal to transfer PageRank to the new URL, typically within days. Chain multiple 301s and you lose small amounts of equity at each hop. Caching: 301 responses are cacheable by default — browsers remember the redirect. Set Cache-Control: no-cache if the redirect might change.

Real-world examples

Common 301 Moved Permanently scenario 1

When a server returns 301 Moved Permanently, it signals specific behavior that clients and intermediaries must handle correctly. For example, in web applications, this status is commonly encountered during URL routing, content negotiation, or resource management operations.

CDN and proxy behavior with 301

CDNs and reverse proxies handle 301 Moved Permanently according to their configuration. The caching and forwarding behavior depends on whether the status is cacheable by default (per RFC 7231) and the presence of Cache-Control headers. Misconfigured intermediaries can cause redirect loops or cache stale redirects.

API design with 301 Moved Permanently

In RESTful API design, 301 Moved Permanently serves a specific semantic purpose. API gateways may intercept and modify these responses for versioning, rate limiting, or traffic management. Understanding when to use 301 versus similar status codes is critical for correct client behavior.

Framework behavior

Express.js (Node)

Express: res.redirect(301, 'https://new-url.com'). For 301/308 permanent: ensure the Location header is correct as browsers may cache it permanently.

Django / DRF (Python)

Django: return HttpResponseRedirect('/new-url/', status=301) or use the shortcut redirect() with permanent parameter for 301/308.

Spring Boot (Java)

Spring: return ResponseEntity.status(301).header("Location", "/new-url").build(). Spring's RedirectView can be configured with specific status codes.

FastAPI (Python)

FastAPI: return RedirectResponse(url='/new-url', status_code=301). For API redirects, ensure the client follows redirects with method preservation when using 307/308.

Debugging guide

Check the Location header value — typos or relative URLs in Location can cause redirect loops or 404s
Verify caching behavior: cacheable by default — check Cache-Control headers
Test with curl -v -L to follow redirects and see the full chain
Check for redirect chains — each hop adds latency; aim for direct redirects
Monitor for method change (POST→GET) which is common with 301

Code snippets

Node.js

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

Python

from fastapi.responses import RedirectResponse

@app.get('/old-path')
async def old_path():
    return RedirectResponse('/new-path', status_code=301)

Java (Spring)

@GetMapping("/old-path")
public ResponseEntity<Void> oldPath() {
    return ResponseEntity.status(301)
        .header("Location", "/new-path")
        .build();
}

func oldPathHandler(w http.ResponseWriter, r *http.Request) {
	http.Redirect(w, r, "/new-path", 301)
}

FAQ

When should I use 301 Moved Permanently vs other redirect codes?

301 Moved Permanently is permanent and may change the HTTP method. Choose based on permanence (will the redirect stay?) and method preservation (does POST need to stay POST?).

How do search engines handle 301 Moved Permanently?

Search engines transfer link equity and update their index to the new URL within days to weeks.

Is 301 Moved Permanently cacheable?

Yes, 301 is cacheable by default per RFC 7234. Browsers and CDNs may cache this redirect permanently unless Cache-Control headers say otherwise.

What are common pitfalls with 301 Moved Permanently?

Common issues include: redirect loops (A→B→A), missing Location header, relative vs absolute URLs in Location, unexpected method change from POST to GET, and excessive redirect chains that add latency.