How to troubleshoot a website that won’t open after setting up a 301 redirect?

If the website becomes inaccessible after setting up a 301 redirect, first determine where the request stops: the old URL does not respond, multiple URLs keep redirecting back and forth, or the request reaches the new URL but the new site returns an error. The commonly seen search term “301エラー” does not mean that 301 itself is a fault; 301 indicates a permanent redirect. The issues to investigate are the redirect rules, destination URL, and request path.

Record the complete redirect path before changing the relevant configuration. Adjusting DNS records, certificates, and rewrite rules at the same time makes it harder to identify the source of the problem.

First, check where the request stops

Open your browser’s developer tools, go to the “Network” panel, enable “Preserve log,” and revisit the full URL that is causing the problem. Pay particular attention to the status code and the Location response header, which indicates the address of the next redirect.

• Too many redirects message: Check whether two URLs are redirecting to each other or the same URL keeps redirecting back to itself.
• A 404 or 5xx error appears after the redirect: The request has reached the destination. Check the page path, application service, or gateway.
• Certificate error, domain resolution failure, or connection timeout: Resolve the certificate, DNS, or network issue first. The request may not have reached the 301 rule.

If you have access to a command line, use curl -I https://old.example.com/path to view the response headers, then use curl -IL --max-redirs 10 https://old.example.com/path to inspect the redirect chain. Some sites handle HEAD requests differently. If the results are unclear, use the browser’s actual GET request as the reference, or check with curl -sS -D - -o /dev/null URL.

If a redirect loop occurs, check the protocol, domain, and proxy configuration first

Common loops include HTTP redirecting to HTTPS and then back to HTTP, or the www and non-www versions of a domain redirecting to each other. For example, if the server redirects example.com to www.example.com, while the website’s admin settings redirect the latter back to the former, the browser cannot reach the page.

First, decide on a single canonical URL, then check that the CDN, load balancer, server, and website admin settings all use the same destination. Rules can work together across multiple layers, but they must not point to different domains or protocols.

If the website uses a reverse proxy, also check how the origin server determines the protocol used by visitors. A visitor may access the CDN over HTTPS while the CDN connects to the origin server over HTTP. If the origin server only checks its own connection, it may keep requiring a redirect to HTTPS, creating a loop.

In this case, verify the origin protocol and whether the application correctly recognizes protocol information passed by trusted proxies, such as X-Forwarded-Proto. Do not trust this request header from arbitrary sources; restrict it to trusted proxies.

Even if the rules do not redirect back and forth, check their matching scope and execution order

Back up the existing configuration before making changes, then check the server rewrite rules, control panel redirects, application plugins, and CDN rules one by one. Look for these three issues in particular:

• The destination still matches the original rule: The rule redirects all requests to a particular address but does not exclude the destination address itself.
• Wildcard or regular expression scope is too broad: A homepage redirect rule unintentionally affects product pages, the admin area, APIs, or static resources.
• Incorrect path concatenation: Directories are duplicated, slash handling is inconsistent, or a capture group is referenced incorrectly, causing the request to go to a nonexistent page.

If access is restored after temporarily disabling a rule, that only indicates that the rule or its interaction with other rules is causing the problem. Continue investigating the trigger conditions instead of deleting necessary domain canonicalization settings outright. With Apache, check rule order and inheritance; with Nginx, also check how server, location, and rewrite directives interact. Check the configuration syntax before reloading it.

If the destination URL is inaccessible, check DNS, certificates, and page mapping

Visit the full address in Location directly. If the destination is also inaccessible, continue troubleshooting the destination site rather than repeatedly changing the old site’s 301 redirect.

When migrating a domain, check that the new domain’s A, AAAA, or CNAME records point to the intended service. If both IPv4 and IPv6 are configured but one is unavailable, some networks may work while others fail.

For HTTPS, keep in mind that the browser must complete the TLS handshake with the old domain before it can receive the 301 response from that domain. Therefore, even if the old domain is only used for redirects, it still needs a valid, matching certificate. Check both the www and non-www entry points; a valid certificate on the destination site does not replace the certificate required by the old domain.

If the homepage works but product pages or multilingual pages return 404 errors, check the mapping between old and new paths. A 301 only tells the browser to request a new address; it does not create pages automatically. When migrating an international trade website, prioritize mapping old product pages, category pages, and language pages to their corresponding content instead of redirecting everything to the homepage.

What if the server is fixed but the browser still fails?

A 301 redirect may be cached by the browser or CDN. If the command line returns the correct result but your usual browser still redirects to the old destination, retest using a fresh browser profile or another device, then clear the cache for the relevant domain. If you disable the cache in developer tools, keep the tools open.

The CDN may also continue returning an old redirect response. Clear the cache for the affected URLs. If the browser automatically upgrades HTTP to HTTPS, HSTS may be involved. Check the actual network request rather than assuming it is a cached 301 in every case.

During the adjustment, you can first use a temporary redirect where appropriate to verify the destination and path, then switch to a 301 once everything is stable. Any cached permanent redirects must still be handled separately.

After access is restored, verify that business entry points work

Retest HTTP and HTTPS, www and non-www, the homepage, product detail pages, and language directories at a minimum. Also follow old links from advertising landing pages or search results. The final page should load properly, and the redirect path should be as direct as possible, without unnecessary intermediate steps.

If inquiry forms, shopping carts, or payment callbacks are involved, test the submission process separately. In some clients, a 301 may change a POST request to GET. Such endpoints should not use ordinary page redirect rules without further consideration. If the request method must be preserved, assess whether a 307 or 308 is appropriate in light of the application logic.

Also check that advertising parameters are preserved and that internal links and sitemaps have been updated. If you use a website-building platform, provide the service provider with the affected URL, redirect chain, time of occurrence, and recent configuration changes. This can help identify more quickly which platform, CDN, or server layer needs to be changed.