The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →A 301 redirect usually fails for one of five reasons: the rule is installed in a layer that never handles the request, its pattern does not match the old URL, the response lacks the intended Location header, another rule creates a loop or chain, or a browser/CDN is serving a cached response. Diagnose the actual HTTP response first, then fix the layer and rule that produced it.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
This guide shows how to verify every hop, identify the failing component, configure direct redirects in Apache or NGINX, account for CDN and proxy behavior, and clear the cache safely.
As an Amazon Associate I earn from qualifying purchases.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsWhat a working 301 must do
HTTP status code 301 means “Moved Permanently.” Google Search Central describes both 301 and 308 as signals that a page has permanently moved to a new location. A correct response tells the client where to go with a Location header, for example:
HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-pageThe client then requests the URL in Location. The destination should return a normal final response, usually 200, rather than another unnecessary redirect. A permanent redirect is not a meta-refresh, JavaScript navigation, HTML link, or an application page that happens to display the new content. Those alternatives do not provide the same server-side relocation signal to browsers and crawlers.
A 308 has the same permanent intent but preserves the request method and body. That distinction matters for non-GET requests such as POST. Use 301 when you intentionally want the conventional browser and search-engine behavior for a moved page; use 308 when method preservation is required and your clients support it.
Check the first response before changing any rule
Do not begin by editing rewrite files. First capture the response from the old public URL and every subsequent hop. A browser tab hides too much: it may follow redirects automatically, reuse a cached 301, or show a page generated by a different layer than the one you edited.
Use a header tool that shows intermediate responses
With curl, request headers and follow redirects while retaining each response:
curl -I -L https://example.com/old-pageFor a more explicit diagnostic, make a request without following redirects first:
curl -sS -D - -o /dev/null https://example.com/old-pageRecord the status line and Location value. Repeat the request for each URL in the sequence, or use -L and inspect all printed headers. A useful record has one row per hop:
| Hop | Status | Requested URL | Location | What to verify |
|---|---|---|---|---|
| 1 | 301 or deliberate 308 | Exact old URL | Intended destination | Rule matched and the redirect is server-side |
| 2 and later | 301, 302, 307, 308, or final status | Previous Location | Next destination, if any | No loop, accidental temporary hop, or unnecessary intermediate URL |
| Final | Usually 200 | Canonical destination | None required | Page is reachable and serves the expected content |
Check the complete URL, not just the path. Compare scheme (http versus https), hostname (such as www versus the apex domain), path, trailing slash, and query string. A redirect can have the right page name but still send visitors to the wrong host or silently discard tracking or functional parameters.
Recommended Free Tools
Interpret the result you actually received
- 200 with the old content: no redirect rule handled this request, or an application route took precedence.
- 301 with an empty or malformed Location: the redirect response is invalid or the target variable resolved to nothing.
- 301 to the wrong host, scheme, or path: the target is constructed incorrectly, or a normalization rule is rewriting it again.
- Repeated 301/302 responses: the chain is too long or a rule is handing the request to another redirecting layer.
- The same URL appears repeatedly: you have a circular redirect.
- The command is correct but a browser behaves differently: compare cache state and edge-versus-origin responses.
Find which layer answered the request
Redirects can be generated by application code, Apache, NGINX, a reverse proxy, or a CDN edge rule. The first layer that returns a response ends the request; downstream rules never get a chance to run.
Application routing
Framework middleware may redirect based on locale, authentication, trailing slashes, or canonical hosts. An application route can also return a 200 page for the old path before a web-server rule is evaluated, depending on the server configuration. Put a permanent move in the earliest reliable layer that owns the URL, and remove conflicting application logic.
Apache or NGINX
Server configuration is the right place when you control the virtual host or location handling the request. Confirm that you edited the active site, not an unused configuration file, and reload the service after validation. A rule in the wrong virtual host, directory, or server block cannot affect the public URL.
CDN or reverse proxy
A CDN can answer with a 301 at the edge without querying the origin. Cloudflare documents this behavior for its redirect features. Consequently, an origin rule may appear broken simply because the edge intercepted the request first. Inspect response headers that identify the serving layer, test the origin hostname or a controlled origin connection, and review edge redirect rules before changing application code.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →When the edge and origin intentionally have different hostnames, test both paths separately. A correct origin response does not prove that the public CDN URL returns the same status or Location.
Fix the most common failure patterns
No redirect: the old URL returns 200
A 200 response means the request was served normally. Check that the rule is loaded in the active virtual host or server block, that the pattern matches the exact path, and that an earlier route is not handling it first. Verify syntax and reload the service, then repeat the header test.
Rank #3
For a one-to-one move in Apache, a simple permanent redirect is often less error-prone than a broad rewrite:
Redirect permanent "/old-page" "https://example.com/new-page"If you need regular-expression matching or capture groups, use mod_rewrite deliberately:
Free tools Windows power users keep installed
One-click scans. No signup required.
RewriteEngine On
RewriteRule ^old-page/?$ https://example.com/new-page [R=301,L]The L flag stops Apache’s current rewrite pass after the match; it does not prevent another layer or a later request from redirecting again. Apache’s rewrite tracing can show which rule matched and what substitution was produced. Enable tracing temporarily, reproduce one request, and disable it afterward because verbose tracing can be expensive and noisy.
In NGINX, an exact path can be handled directly:
location = /old-page {
return 301 https://example.com/new-page;
}For a family of paths, use a carefully scoped regular expression or a rewrite:
location /old-section/ {
rewrite ^/old-section/(.*)$ https://example.com/new-section/$1 permanent;
}Validate the configuration before reloading:
nginx -tThen reload using your operating system’s service manager and retest the public URL. A successful syntax check only proves that the file parses; it does not prove that the request reaches that server block.
The destination is wrong
Read the literal Location value from the first response. Correct the host, scheme, path, slash convention, and query behavior there rather than assuming the browser will repair it. An explicit final URL is safer than concatenating untrusted host headers or ambiguous path variables.
Test representative query strings. Decide whether parameters must be preserved, removed, or replaced. A redirect that works for /old-page can still mishandle /old-page?ref=campaign. Verify that functional parameters survive when required and that obsolete tracking parameters are not accidentally promoted into the canonical URL.
A redirect loop occurs
Loops commonly result when two systems disagree about canonical form:
- HTTP redirects to HTTPS while the origin sees the proxy connection as HTTP and redirects back.
- The
wwwhost redirects to the apex domain while another rule sends the apex back towww. - One rule adds a trailing slash and another removes it.
- A locale rule sends the canonical language URL back to the locale selector.
- The CDN enforces one scheme while the origin enforces another.
Choose one owner for each normalization decision. If TLS terminates at a proxy, configure the origin to trust the proxy’s protocol header correctly and ensure the application or server knows that the original request was HTTPS. Exclude the already-canonical URL from the rule that creates the redirect. Then test every combination you support, including both schemes, both hostnames, slash variants, and representative locale paths.
The chain has too many hops
Chains occur after several migrations: an old HTTP URL redirects to HTTPS, then to www, then to a new directory, then to the final slug. Replace that sequence with one direct mapping from the old URL to the final canonical URL. Google warns that long redirect chains negatively affect crawling, and each extra hop increases latency and creates another place for a loop or failure.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Build a map of legacy URLs and collapse each row to its final destination. Keep intermediate rules only when an old URL genuinely cannot be mapped directly; otherwise remove them after the direct rule is live.
It works at the origin but not through the CDN
Compare headers from the origin and the public hostname. If the edge returns a different status or Location, inspect edge redirect products, page rules, worker or function code, cached objects, and host-header forwarding. An edge-generated 301 can prevent the request from reaching your server at all. Fix or remove the conflicting edge rule, then purge the affected cache entries.
The fix is deployed but the old behavior remains
Browsers and search engines may cache a 301 indefinitely. Apache explicitly warns that a browser is allowed to cache a 301 response indefinitely. CDNs can also cache redirect responses according to their settings. Test from a fresh private window, a different client, or a cache-bypassing request, but do not treat a private window as proof that every intermediary cache was bypassed.
After correcting the rule, purge the relevant CDN URL or cache zone using the provider’s controls. If an intermediate proxy is outside your control, allow for its cache lifetime and continue checking the live response from more than one network. Avoid repeatedly changing destinations on a production URL; cached permanent redirects can make each experiment harder to interpret.
Keep redirects direct and unambiguous
Use a redirect table before editing configuration:
| Old URL | Final canonical URL | Required status | Query-string decision | Owner |
|---|---|---|---|---|
/old-page |
https://example.com/new-page |
301 or deliberate 308 | Preserve or remove, explicitly decided | Origin or edge |
http://example.com/old-page |
https://example.com/new-page |
One direct hop where practical | Match the HTTPS rule | Single canonicalization layer |
Do not create separate competing rules for the same URL in the application, server, and CDN unless their responsibilities are clearly divided. If multiple layers must participate, document which layer owns scheme, host, slash, locale, and content moves.
Use logs and tracing to locate the mismatch
Access logs show whether the request reached the origin and which status it returned. Include the request host, path, query string, status, upstream status, response location when available, and cache indicator. Compare a request that returns 200 with one that should redirect. If the public request has no matching origin log entry, the edge or proxy answered it.
On Apache, rewrite tracing identifies the rule, condition, and substitution involved. On NGINX, inspect the active configuration rather than only the source include file, and use temporary logging for the relevant location. Remove diagnostic logging after the issue is resolved to avoid unnecessary volume and exposure of request data.
Why Search Console reports a redirect error
Search Console’s redirect-error category includes too many redirects, empty redirects, and circular redirects. Treat the report as a symptom to verify, not as a substitute for inspecting the HTTP exchange.
- Request the reported URL and capture every status and
Location. - Confirm the first response is a deliberate 301 or 308, not a 200, empty redirect, or unrelated temporary status.
- Follow the chain to a reachable final URL with valid content.
- Remove loops and collapse unnecessary hops.
- Check that the destination is not blocked, unavailable, or redirecting back to the source.
- Use URL Inspection or the appropriate Search Console report after the live response is corrected, then allow Googlebot to recrawl.
A 301 is a strong relocation signal, but indexing is processed separately. Google may continue showing an old URL for a period while it recrawls and evaluates the destination. Consistent canonical signals, a reachable final page, and a direct redirect give the crawler the clearest instructions.
Choosing where to implement a redirect
When more than one option is available, compare the control layer rather than choosing by habit:
| Layer | Best fit | Advantages | Risks and checks |
|---|---|---|---|
| Application | Rules requiring business or user data | Access to application logic and deployment workflow | May be slower, can be shadowed by routes, and is harder to diagnose if errors occur first |
| Apache or NGINX | Stable path-to-path and host normalization rules | Fast, server-side, observable in logs, and independent of page rendering | Requires access to the active virtual host or server block; syntax and rule order matter |
| CDN edge | Global redirects or traffic that should never reach origin | Can respond before origin, reducing latency and origin load | Edge rules can hide origin changes; cache purging and precedence must be understood |
| Reverse proxy | Centralized routing across services | One control point for multiple backends | Forwarded-protocol and host interpretation can create loops |
Prefer the layer that can produce one direct hop, match the exact old URL, expose useful logs, and provide a reliable cache-invalidation mechanism. Whichever layer you select, document it so a later migration does not add a second owner.
Quick Recap
A repeatable repair checklist
- Capture the old URL’s first response without relying on a browser’s rendered page.
- Verify the status is 301 or an intentional 308 and read the exact
Location. - Follow all hops to the final response and identify loops, empty targets, wrong hosts, or unnecessary intermediates.
- Determine whether the response came from the application, origin server, proxy, or CDN edge.
- Check the active configuration, rule order, path syntax, virtual host, server block, and query-string behavior.
- Replace multi-hop mappings with one direct old-to-final rule.
- Assign one owner to HTTPS, hostname, slash, locale, and content-move normalization.
- Validate configuration, reload the responsible service, and inspect origin logs.
- Purge relevant CDN caches and retest from a fresh cache context.
- Confirm the destination is reachable, then monitor Search Console for recrawl and resolution.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
