301 Redirect Not Working? 6 Common Causes and Fixes

You set up a domain redirect, waited for propagation, tested the old URL — and nothing happens. The page either stays the same, throws an error, or loops endlessly.

Redirect failures are frustrating, and they cost you more than just time. Every broken redirect means lost traffic, broken backlinks, and a poor experience for anyone clicking an old link. For businesses relying on organic search, a misconfigured redirect can quietly bleed SEO value for weeks before anyone notices.

The good news: most redirect failures come from just a handful of causes. This guide walks through each one, from DNS issues to server config mistakes, with concrete steps to diagnose and fix them.

#1 DNS Hasn't Propagated Yet#

The problem: You pointed your domain's DNS records to the redirect service or new server, but visitors still see the old site.

Why it happens: DNS changes don't take effect instantly. Every DNS record has a TTL (Time to Live) value — usually 300 seconds (5 minutes) to 86,400 seconds (24 hours). Until the old TTL expires worldwide, DNS resolvers around the internet keep serving the old IP address.

How to diagnose:

• Run dig example.com in your terminal and check the ANSWER section — is the IP the old one or the new one?
• Use a global DNS propagation checker like whatsmydns.net to see propagation status across different regions
• Check your domain's TTL in your DNS provider's settings

How to fix:

• Lower the TTL before the planned change and allow the previous TTL to expire first. Lowering it after resolvers have cached the old record does not shorten that existing cache entry.
• Compare the authoritative DNS answer with answers from recursive resolvers. Timing depends on the previous TTL and the provider; waiting a fixed number of hours does not establish that the records are correct.
• If propagation seems stuck, check that you updated records at the correct DNS provider (the one where your nameservers point, not necessarily your domain registrar)

#2 .htaccess Syntax Errors#

The problem: You added a redirect rule to your .htaccess file, but the server returns a 500 Internal Server Error, ignores the rule entirely, or applies it incorrectly.

Why it happens: Apache's mod_rewrite is powerful but unforgiving. A single missing space, wrong flag, or conflicting rule can break the entire configuration. Common mistakes include:

• Missing RewriteEngine On at the top of the rules block
• Using http:// instead of https:// in the target URL
• Check the syntax for the directive you are using. In a per-directory .htaccess RewriteRule pattern, Apache removes the leading slash; rules in other contexts can behave differently.
• Conflicting rules that override each other due to ordering

How to diagnose:

• Check your server's error log — Apache logs exact line numbers for syntax errors
• Temporarily rename .htaccess to something else — if the error goes away, your .htaccess is the culprit

How to fix:

• Start with a minimal rule and test before adding complexity
• Correct syntax for a basic 301 redirect:

apacheRedirect 301 /old-page https://example.com/new-page

• For regex-based redirects with mod_rewrite:

apacheRewriteEngine On
RewriteRule ^old-path/(.*)$ https://example.com/new-path/$1 [R=301,L]

• If your site runs on Nginx instead of Apache, .htaccess files are ignored entirely — you need to add rules in the server block configuration instead

#3 Redirect Chain or Loop#

The problem: The redirect starts but never reaches the destination — the browser eventually shows "too many redirects" or the page takes forever to load.

Why it happens: A redirect chain happens when URL A redirects to B, B redirects to C, and so on. A loop happens when the chain circles back to an earlier URL. Both are common during website migrations when old redirects and new redirects overlap without cleanup.

How to diagnose:

• Open Chrome DevTools → Network tab → reload the page — examine the 3xx chain of requests
• If you see the same URL appearing twice in the chain, that's a loop
• Enter the URL in our redirect speed test to see every hop, its status code and where it ends up

How to fix:

• Map out every active redirect rule you have — in .htaccess, CMS plugins, CDN edge rules, and the redirect management tool
• Remove intermediate rules that are no longer needed. Consolidate chains into a single direct redirect (A → D instead of A → B → C → D)
• If using WordPress, check all active plugins — caching plugins, SEO plugins, and security plugins can all add conflicting redirect rules

#4 Caching Ghosts#

The problem: You updated or removed a redirect, but visitors still get redirected to the old destination.

Why it happens: Browsers, CDN edge nodes, and server-level caches aggressively cache 301 redirects. Once a browser sees a 301, it may remember that redirect indefinitely — even after you've changed it. The same applies to CDN caches like Cloudflare, which may serve stale redirect responses from edge nodes.

How to diagnose:

• Compare a private-window result with a normal session and a command-line request. A difference suggests browser state or cache, but it is not by itself a complete diagnosis.
• Use curl -I https://example.com/old-page to see the actual server response headers without browser interference
• Check the Cache-Control and Age headers in the response

How to fix:

• Clear your browser's cached images and files, or keep testing in a private window
• Purge your CDN's cache for the old URL; most CDNs let you purge a single URL
• For future redirects, use 302 (temporary) during testing, then switch to 301 (permanent) only when you're confident the destination is correct
• Add explicit cache headers: Cache-Control: no-cache, max-age=0 for redirects you expect to change

#5 Mixed HTTP/HTTPS Issues#

The problem: Your redirect target uses HTTPS, but the redirect sends traffic to the HTTP version, or vice versa. Visitors see a certificate warning or a broken page.

Why it happens: This is one of the most overlooked redirect failure modes. You set up a redirect from http://old-domain.com to http://new-domain.com, but the new domain enforces HTTPS via HSTS. The browser makes one redirect, then immediately gets redirected again to HTTPS — or worse, the HTTPS version of the old domain has an expired or mismatched certificate.

How to diagnose:

• Check both http:// and https:// versions of your source URL
• Look for mixed-content warnings in the browser console
• Check if HSTS is enforced (check for the Strict-Transport-Security response header)

How to fix:

• Always redirect to the full HTTPS URL: https://new-domain.com/page instead of just new-domain.com/page
• Ensure every domain in the chain has a valid SSL certificate installed
• If redirecting from an old domain, make sure the old domain also has SSL coverage — even if it only serves redirects
• Use a single canonical protocol (always HTTPS) everywhere in your redirect rules

#6 Wrong Redirect Type#

The problem: Your redirect works, but search engines aren't passing link equity, or visitors can't bookmark the destination properly.

Why it happens: Different HTTP status codes tell browsers and search engines different things about the redirect:

• 301 (Moved Permanently): Passes most link equity. Use for permanent moves like domain changes or restructuring
• 302 (Found): Temporary. Google usually keeps the old URL indexed, so ranking signals stay there. Use only for temporary redirects like A/B tests or seasonal landing pages
• 307 (Temporary Redirect): Similar to 302 but preserves the HTTP method. Used for temporary API redirects
• Meta refresh: An HTML redirect, not an HTTP one. Google reads an instant (0-second) meta refresh as permanent and a delayed one as temporary, but it only works after the page loads, so use a server-side redirect when you can

How to diagnose:

• Check the response status code using curl -I https://example.com/old-page
• Look for the Location header and the 3xx status code in the first line of the response

How to fix:

• Use 301 or 308 for permanent moves to a relevant replacement. If a page is removed without a suitable replacement, a 404 or 410 can be appropriate instead of an unrelated redirect.
• Use 302 or 307 only for genuinely temporary redirects (promotions, maintenance pages, A/B testing)
• Avoid meta refresh (<meta http-equiv="refresh">) for important URLs; use a real HTTP 301 instead
• Choose the status according to whether the move is permanent or temporary, then verify the behavior. Do not assume that every temporary response causes a fixed loss of SEO value.

How to Prevent Redirect Failures#

The diagnosis and fix cycle for redirect issues is time-consuming. Here's how to avoid most of them upfront:

• Test with curl before launching: Run curl -IL https://source-url.com to verify the full redirect chain before announcing any URL change
• Keep a redirect map: Document every redirect rule. When you migrate or restructure, update the map. This prevents accidental chains and orphaned rules
• Use a dedicated redirect management platform: Managing redirects through .htaccess, WordPress plugins, or server config files works — until it doesn't. When you have dozens or hundreds of redirects, the manual approach breeds errors. A dedicated platform gives you visual debugging of redirect chains, automatic HTTPS handling, analytics on redirect traffic, bulk import and export, and audit logs to track changes.
• Set low TTLs before making DNS changes: Lower your TTL to 300 seconds at least 24 hours before any planned DNS update
• Test on a staging environment: Never deploy redirect changes directly to production without testing the full path
• Map each old URL to its closest new page: sending everything to the home page "works" technically, but visitors and search engines lose the page they were looking for

The RedirHub Approach: Skip the Guesswork#

Redirect failures can occur with any setup. A managed service can reduce the server configuration you operate, but DNS records, certificate prerequisites, cached responses and destination availability still need attention.

RedirHub answers redirects from its own edge network, separate from your web server. There are no .htaccess files to break and no server to restart when you add a rule. You manage redirects in a dashboard, HTTPS is issued automatically with free SSL certificates for root and www, and large moves can be loaded with a CSV redirect import instead of hand-written rules.

How that maps to the causes above:

• DNS setup: use the required values in Connect DNS. Root domains use the shown A and verification TXT records; supported subdomains use CNAME. Existing DNS cache entries still need to expire.
• .htaccess errors: there is no server config to edit. You fill in Redirect from, Redirect to and Redirect type, and What happens previews where sample URLs will land before you save.
• Chains: every redirect lives in one Links list, so you can point old URLs straight at the final destination instead of stacking rules in several places.
• Caching: changes take effect on our side as soon as you save. Browsers that already cached an old 301 can still remember it, so test changes in a private window or with curl.
• HTTPS: certificates are issued and renewed automatically for both root and www, so the old domain works on https:// too.
• Status codes: choose 301, 302, 307 or 308 per redirect, and see the code next to each sample URL before you create it.

If you have one site on a server you control, fixing the rule there is free and quick. A redirect service pays off when you manage many domains or a site migration with thousands of URLs, where hand-maintained rules are where chains and typos creep in. Plans start at $49/month (Core) with a 14-day free trial.

Quick-Reference Checklist#

• Does DNS for the old domain point where the redirect is configured? (dig or a DNS checker)
• Does curl -IL https://old-url show a 301 on the first hop and the right final URL?
• Do http://, https://, www and non-www all redirect?
• Is there only one hop to the final URL, with no loop?
• Does the old domain have a valid certificate?
• Did you test in a private window to rule out a cached redirect?
• Does each old page go to its matching new page, not the home page?

Still stuck? Sometimes the problem is infrastructure-level — conflicting CDN rules, server-level rewrites overriding application-level rules, or DNS settings at the registry level. If you've gone through this checklist and the redirect still isn't working, a visual redirect diagnostics tool can show you exactly what's happening at each hop.