ErrorBase
Independent technical referenceOfficial site
  • Software and digital services
  • HTTP service

301

HTTP 301 Moved Permanently status: target assigned new URI

Verified with sources2 sourcesReviewed Oct 19, 2026
Technician coming? See the 2 steps they must show you

Risk level

Low

Usually safe to check without specialist tools.

Urgency

Medium

Quick answer

HTTP 301 Moved Permanently indicates that the target resource has been assigned a new permanent URI. Check the Location header field in the 301 response to confirm the destination URI and update saved links or client endpoints if the move is intentional.

Safety first

Stop and check this first

  • Do not attempt to deploy an unverified 301 redirect without explicit cache controls on temporary maintenance routes, because browsers and shared caches heuristically store 301 responses even without Cache-Control headers.

Safe checks you can perform

  • Verify the Location header destination and fragment inheritance
  • Retest the original URI in a fresh private session without cache
  • Check whether a POST request is rewritten to GET after the 301 hop

Leave these tasks to a qualified professional

  • Do not attempt this professional task: Correct the permanent redirect map and cache headers on origin and CDN
  • Do not attempt this professional task: Switch POST endpoints from 301 to 308 or update client target URIs

What a technician must be able to justify

Technician visit

These are the steps they must carry out and show you. Tick them as they work: if steps are skipped, do not accept a part swap.

These are not instructions for opening or handling the equipment yourself. They are the checks that should support a technical conclusion.

  1. Correct the permanent redirect map and cache headers on origin and CDN

    What they doHave the site or platform administrator audit the server and CDN rewrite rules so each legacy URI issues a single 301 hop to its canonical permanent URI with appropriate Cache-Control headers.

    They must show youa single-hop HTTP trace from the old URI to the final 200 destination with no intermediate redirect hops.

    In writingthe updated rewrite rule, the canonical Location URI, and the Cache-Control max-age policy applied.

  2. Switch POST endpoints from 301 to 308 or update client target URIs

    What they doHave the application developer update callers to send POST requests directly to the new permanent URI, or configure the server to return status 308 (Permanent Redirect) instead of 301 on endpoints that must preserve POST.

    They must show youan access log or trace demonstrating the POST request and payload arriving intact at the new permanent URI.

    In writingthe list of endpoints updated to 308 or the client release version pointing directly to the new URI.

Before accepting a part or repair

Nothing has been shown yet. Do not accept a part swap based on the code alone.

Follow these steps

Note: Follow the documented order. An error code identifies the affected system, but it does not prove by itself which part has failed.

  1. Verify the Location header destination and fragment inheritance

    No special tools

    Who:
    You or your developer can inspect the redirect hop in the browser Network tab.
    How:
    Trigger the request with network recording open, select the 301 response, and read the Location header field and final destination URI.
    Result that matters:
    Whether the Location URI reference resolves to the expected permanent resource or enters a redirection cycle.
    If the Location URI loads the matching page in a single hop, that confirms a normal permanent move and means you should update bookmarks or client links.
    If the Location chain repeats a previously visited URI, that confirms a cyclical redirection loop in the server or CDN routing rules.
    Evidence to keep:
    Record the original target URI, the exact Location header value, and the HTTP status of each hop.

    Evidence: RFC 9110 section 15.4.2 - 301 Moved Permanently · RFC 9110 section 15.4 - Redirection 3xx · RFC 9110 section 10.2.2 - Location

  2. Retest the original URI in a fresh private session without cache

    No special tools

    Who:
    You can run this check using a private browser window or a cache-bypassing client request.
    How:
    Open the original URI in a clean private window or with DevTools 'Disable cache' enabled and compare the response with your normal browser profile.
    Result that matters:
    Whether the origin server still emits status 301 live or only your local cache is replaying a stored 301.
    If the private session receives a 200 response while your regular profile still redirects, that isolates the issue to a heuristically cached 301 response.
    If the clean session receives the exact same 301 and Location header, that rules out local browser caching and confirms the server or CDN is actively sending the redirect.
    Evidence to keep:
    Save screenshots or HAR entries from both the cached profile and the clean session with timestamps.

    Evidence: RFC 9110 section 15.4.2 - 301 Moved Permanently

  3. Check whether a POST request is rewritten to GET after the 301 hop

    Tools required

    Who:
    Your web or API developer inspects the network trace and destination server access log.
    How:
    Compare the HTTP method and Content-Length header on the initial request to the old URI against the redirected request sent to the Location URI.
    Result that matters:
    Whether the user agent changed the request method from POST to GET and stripped content-specific header fields.
    If the initial request was POST and the follow-up request arrived as GET, that confirms method conversion under 301 semantics caused the write or form failure.
    If both requests used GET and the destination still failed, that rules out POST-to-GET conversion and points to the destination URI handler.
    Evidence to keep:
    Keep the paired request and response headers for both hops, including method, URI, and Content-Type.

    Never replay production payment or state-changing POST payloads repeatedly against live endpoints while diagnosing redirect method changes.

    Evidence: RFC 9110 section 15.4.2 - 301 Moved Permanently · RFC 9110 section 15.4 - Redirection 3xx

Still not solved

If the error persists, stop here. See what the technician must do and show you.

Where this code applies

A code is meaningful only inside the right product and version context.

Primary scope

System
Software and digital services
Brand
HTTP
Product type
HTTP service

Known code variants

  • 301 Dauerhaft verschoben
  • 301 Déplacé définitivement
  • 301 Moved Permanently
  • 301 Movido permanentemente
  • 301 Spostato definitivamente
  • código 301 Epson
  • EcoTank 301 dispositivo de memoria
  • EcoTank 301 memory device
  • Epson 301
  • Epson error code 301
  • Epson ET-5800 301
  • Epson ET-5805 301
  • Epson L6550 301
  • événement Fronius 301
  • événement SMA 301
  • evento Fronius 301
  • evento SMA 301
  • Fronius Ereignis 301
  • Fronius event 301
  • Fronius inverter 301
  • Fronius Symo / Eco 301
  • Fronius Wechselrichter 301
  • HTTP 301
  • HTTP status 301
  • inversor Fronius 301
  • inversor SMA 301
  • inverter Fronius 301
  • inverter SMA 301
  • No hay suficiente espacio de almacenamiento para guardar los datos en el dispositivo de memoria
  • onduleur Fronius 301
  • onduleur SMA 301
  • SMA Ereignis 301
  • SMA event 301
  • SMA inverter 301
  • SMA Wechselrichter 301
  • Sunny Tripower X 301
  • There is not enough storage space available to save the data in the memory device

What it means

Defined in RFC 9110 Section 15.4.2, HTTP 301 (Moved Permanently) signals that the origin server has assigned a new permanent URI to the target resource and provides the preferred destination in the Location header field (Section 10.2.2). A 301 response is heuristically cacheable unless restricted by explicit cache controls, and for historical reasons a user agent may rewrite a POST request into a GET request when following the redirect. Receiving status 301 alone does not prove an application outage, because it represents normal permanent URI routing unless the Location chain loops or drops a required POST body.

Warnings and stop conditions

  • Lowsource verified

    Do not attempt to deploy an unverified 301 redirect without explicit cache controls on temporary maintenance routes, because browsers and shared caches heuristically store 301 responses even without Cache-Control headers.

    Evidence: RFC 9110 section 15.4.2 - 301 Moved Permanently

Symptoms and causes

Probable causes · in order

  • Intentional permanent URI migration configured on the serverCommon

    The site or API owner assigned a new permanent URI to the target resource and configured the server to send status 301 with the preferred new URI reference in the Location header field.

    Evidence: IANA HTTP Status Code Registry · RFC 9110 section 15.4.2 - 301 Moved Permanently

  • POST request converted to GET across a 301 redirect hopPossible

    Because RFC 9110 Section 15.4.2 allows a user agent to change the request method from POST to GET after a 301 response, form submissions or API writes sent to the old URI arrive at the new URI as GET without their request body.

    Evidence: RFC 9110 section 15.4.2 - 301 Moved Permanently · RFC 9110 section 15.4 - Redirection 3xx

  • Heuristically cached 301 redirect stored in browser or proxy cachePossible

    Under RFC 9110 Section 15.4.2, a 301 response is heuristically cacheable, so a browser or intermediate cache can continue redirecting requests to an old Location target even after the origin server rule is removed.

    Evidence: RFC 9110 section 15.4.2 - 301 Moved Permanently

  • Cyclical Location rules creating a 301 redirection loopPossible

    When two or more rewrite rules point back to a previously visited URI, the client detects a cyclical redirection loop as described in RFC 9110 Section 15.4 and aborts the request.

    Evidence: RFC 9110 section 15.4 - Redirection 3xx · RFC 9110 section 10.2.2 - Location

Virtual technician

Does 301 still appear after these checks?

Answer a few questions to narrow down the likely cause and the safest next action. Guidance only - it never replaces a professional.

Start diagnosis

Sources and technical references

  1. 1

    IANA HTTP Status Code Registry

    Internet Assigned Numbers Authority · 2025 · standard

  2. 2

    RFC 9110 - HTTP Semantics

    IETF / RFC Editor · 2022 · standard

Sources: IANA HTTP Status Code Registry · RFC 9110 - HTTP Semanticsreviewed 2026-10-19 · verified

Was this entry useful?