Erriscope
EN
English Español Português (Brasil) Deutsch Français 日本語 한국어

HTTP 301 Moved Permanently: What It Means

DIRECT ANSWER

HTTP 301 Moved Permanently means the requested resource has been assigned a permanent redirect to another URL, usually identified by the `Location` response header. A 301 applies to the specific request that received it; it does not by itself mean the entire website is down. Check the exact URL, HTTP method, response headers and redirect destination before changing configuration.

Key takeaways

  • HTTP 301 is a permanent redirect for a requested resource, not automatically a site-wide failure.
  • The Location header normally identifies where the client should go next; inspect it along with caching and authentication headers.
  • DNS resolution and TLS negotiation can succeed even when the HTTP request receives a 301 response.
  • A redirect may be intentional because of canonical URLs, HTTP-to-HTTPS routing, hostname changes, authentication flows or application routing.
  • Site owners should identify whether the web server, application, reverse proxy, CDN or WAF generated the response before changing settings.
  • Test the same URL and method after any correction, and verify that related routes still return their intended statuses.
Updated 2026-09-24 · Editorial review pending HTTP & Server Errors
SA

Site Administrator

What this error means & how to recognize it

  • A browser, API client, monitoring service or HTTP checker reports 301 Moved Permanently.
  • A browser may automatically follow the redirect, show a different URL, or expose a redirect loop if the destination leads back to the original URL.
  • The response may include a Location header containing the redirect destination.
  • The behavior may occur only for one URL, hostname, HTTP method, authentication state, user agent or network path.
  • DNS may resolve successfully and TLS may complete successfully because the endpoint returned an HTTP response.
  • API clients or automated tools may stop at the 301 instead of following it, depending on their redirect settings.

Root causes, ordered by likelihood

  1. Intentional URL canonicalization: The site redirects an alternate hostname, path, trailing-slash form or other URL variant to its preferred address.
  2. Protocol or hostname migration: HTTP traffic may be redirected to HTTPS, or an old hostname may point to a replacement hostname.
  3. Application or framework routing: The application may redirect a route after a path change, login state change or resource relocation.
  4. Web-server, reverse-proxy or CDN rules: Infrastructure configuration may apply a redirect before the request reaches the application.
  5. Cached redirect behavior: A browser, intermediary cache or CDN may continue serving a previously cached redirect while configuration changes propagate.
  6. Method-specific behavior: A redirect rule may be appropriate for browser navigation but unsuitable for an API request or a method that must preserve its request semantics.
  7. Unexpected or conflicting rules: Multiple layers may redirect to different destinations, creating a chain or loop.

How to fix it

1Is the response really HTTP 301? Confirm the finalstatus and record every redirect hop.2Is the redirect expected? Compare the URL, hostname,protocol and method with the site’s routing policy.3What destination is supplied? Inspect the Locationheader and check for a wrong host, loop, chain orunavailable target.4Which layer generated it? Correlate the timestamp withapplication, server, proxy, CDN or WAF logs.5Does the issue affect one request or many? Comparerelated routes, methods, authentication states andclients.6What changed recently? Review deployment and routingchanges, then make one narrow authorized correction andretest.
Diagnostic flow at a glance — full detail in the steps below.

If you are visiting the site

  1. Check the exact address, including the hostname, path and protocol. Follow the redirect only if the destination is familiar and expected.
  2. If the destination requires an account, sign in through the site’s normal interface and retry. Do not submit credentials to an unfamiliar redirected domain.
  3. If a browser reaches the intended page, the 301 may be working as designed. If it loops, lands on the wrong host, or ends at a missing page, record the original URL and destination.
  4. For an API or automated client, check whether it follows redirects and whether the redirected URL is valid for the same request method and authentication context.
  5. Report the original URL, destination, approximate time, client type and observed status to the site owner. Do not share passwords, cookies or API secrets.

If you own or maintain the site

  1. Reproduce the exact request. Record the HTTP method, full URL, host, protocol, authentication state where relevant, final status and each redirect destination.
  2. Inspect the response headers, especially Location, cache-related headers, authentication-related headers and any header identifying a proxy or server layer.
  3. Determine which component produced the 301: application, web server, reverse proxy, CDN or WAF. Check the corresponding logs using the request timestamp and a request identifier if available.
  4. Compare the behavior with the intended routing design. Confirm whether the redirect is meant to handle a hostname change, HTTP-to-HTTPS policy, canonical path, moved resource or application flow.
  5. Check for redirect chains, loops, conflicting rules and an incorrect destination. Review recent deployments and changes to routing, authentication, caching, proxy or CDN configuration.
  6. Apply the narrowest authorized correction at the layer that generated the response. Avoid broad permission, security or redirect-rule changes when one route or condition is wrong.
  7. Retest the same URL and method from an appropriate client. Then test the destination, important related routes and relevant authenticated and unauthenticated cases.
  8. If a cached redirect is suspected, follow the site’s approved cache-invalidation process and account for its operational impact before making that change.

Prevention & how to verify the fix

  • Define and document intentional redirects, including old URLs, destinations, affected methods and ownership.
  • Keep web-server, application, reverse-proxy, CDN and WAF rules version controlled where supported.
  • Test canonical URLs, HTTP-to-HTTPS behavior, hostname changes, important API methods and authenticated routes after releases.
  • Monitor redirect rates, chains and loops by route and deployment rather than treating every 301 as an outage.
  • Keep request and infrastructure logs available long enough to correlate unexpected redirects.
  • Review cache behavior when changing redirect rules so stale responses do not obscure the result of a correction.

When to get outside help

Escalate when an unexpected 301 affects an important public route, produces a loop or long chain, sends users to an untrusted or incorrect host, affects many users, or requires changes to authentication, security, proxy, CDN or server configuration that you cannot safely validate. Provide sanitized request details, redirect destinations, timestamps, response headers and relevant logs. Never share passwords, cookies, API keys or other secrets.

Run a website check

Frequently asked questions

Does HTTP 301 mean the whole website is down?

No. A 301 describes the response to a particular HTTP request. It may affect one URL, hostname, method, client or authentication state while other parts of the site continue to work.

What does the Location header do in a 301 response?

It normally identifies the URL that the client should request next. Check that destination for the correct host, protocol and path, and look for chains or loops.

Can DNS and TLS be healthy when HTTP 301 is returned?

Yes. Successful DNS resolution and TLS negotiation are separate from the HTTP status returned by the endpoint. A 301 indicates that an HTTP-speaking endpoint responded with a redirect.

Why does a browser follow a 301 but my API client does not?

Browsers commonly follow redirects during navigation, while API clients may require redirect following to be enabled or may stop so the application can handle the destination explicitly. Check the client’s redirect behavior and the method and authentication requirements of the target.

Should a permanent redirect be changed to another status code?

Not automatically. First confirm the intended resource relationship, request method and client behavior. Changing a redirect status can affect navigation, caches, clients and search-engine processing, so make the change only when the routing design calls for it.

What should site owners check first?

Confirm the exact request and inspect the Location header, then identify which layer generated the response and correlate it with matching logs. Review recent routing, proxy, application and cache changes before editing configuration.

Further documentation