Domain Redirect Not Working? 7 Fixes That Work (2026)

You set up the redirect, typed the old address into your browser, and landed right back where you started. A domain redirect not working is rarely a mystery, though. The request is being stopped at one of four layers (your browser, DNS, a proxy like Cloudflare, or the web server), and a single terminal command tells you which one.

Quick Answer: Run curl -I http://olddomain.com. A 301 with the right Location: header means the redirect works and your browser is replaying a cached answer, so retest in a private window. No response at all points to DNS. A 200 means the server never ran your rule: check where the rule sits in .htaccess, or whether Cloudflare is actually proxying the domain.

Last verified: September 2026, against cPanel & WHM 136 and Cloudflare Single Redirects (Page Rules are now deprecated).

Our engineers resolve 20-30 client issues every day, and redirects that look perfect in a settings screen but do nothing in real life turn up in that queue constantly. This guide follows the same order we work through on a live ticket, written so you can run every step yourself.

Why a Domain Redirect Not Working Comes Down to Four Layers

A redirect is only an instruction, and something has to receive the request before it can obey it. When yours fails, the request is being answered (or dropped) before it reaches the rule you wrote.

As of September 2026, a web redirect can be answered by four parties in a fixed order: the browser's cache, DNS, a reverse proxy such as Cloudflare, and the origin web server. A 301 cached by the browser replays with zero network requests, so a rule you already fixed on the server can keep looking broken for days on the one laptop you test from.

That ordering gives you a shortcut we call the Four-Layer Redirect Check. Work down the list and stop at the first layer that fails:

1. Browser. Does a private window, or your phone on mobile data, behave differently?
2. DNS. Does dig +short olddomain.com return the IP of the server holding your rule?
3. Proxy. If the domain runs through Cloudflare, is its DNS record proxied (orange cloud)?
4. Server. Does curl -I http://olddomain.com come back 301 or 200?

Anything below the first failing layer can wait. People lose whole evenings rewriting perfectly good .htaccess rules on a domain that was never pointed at the server.

Pro Tip: Use curl -IL (capital L) to follow the full chain. More than two hops means you've built a redirect chain, and every extra hop adds a round trip before the page starts loading. If your time to first byte is already creeping up, this guide to fixing high TTFB in WordPress shows where those milliseconds go.

What Causes a Redirect to Fail? The Pattern We See

Most failed redirects we investigate aren't broken rules. They're correct rules that never get the chance to run. Match your symptom below, then jump to the fix with the same number.

| Symptom you see | Layer at fault | First thing to check | Go to | |---|---|---|---| | Works in a private window, not your normal browser | Browser cache | curl -I or another device | Fix 1 | | Rule saved in cPanel Redirects, inner page still loads | .htaccess rule order | Rule position vs # BEGIN WordPress | Fix 2 | | "This site can't be reached" on the old domain | DNS | dig +short olddomain.com | Fix 3 | | HTTP forwards fine, HTTPS shows a certificate warning | Registrar forwarding / SSL | Certificate on the old domain | Fix 4 | | Cloudflare rule saved, nothing happens | Proxy status | Orange vs grey cloud | Fix 5 | | ERR_TOO_MANY_REDIRECTS | Redirect loop | Cloudflare SSL mode, force-HTTPS rules | Fix 6 | | Bare domain redirects, www doesn't | Missing www record or certificate | dig and the certificate for www | Fix 7 |

In our experience, the first two rows cover most of the redirect tickets we open: a cached 301 on the owner's own laptop, or a cPanel rule parked underneath WordPress's rewrite block. Registrar forwarding that silently fails over HTTPS comes next, and it's the one most troubleshooting guides skip entirely.

According to Hostaccent's support-queue data (September 2026), SSL problems make up about 20% of our monthly tickets. A fair share of those turn out to be redirect problems in disguise: a forwarded domain with no certificate, or a force-HTTPS rule fighting a proxy that already forces HTTPS.

◆ Professional help available

Still blocked at Cloudflare?

Send the error code, affected hostname, and recent DNS or SSL changes. We will separate edge, origin, firewall, and certificate causes before proposing work.

Request Cloudflare help→Explore Cloudflare support↗Hosted elsewhere? One-time paid support is available after scope and price confirmation.

How to Fix Each Cause, Step by Step

Start with the fix that matches your row in the table. Each one ends with a quick way to confirm it worked, so you're never left guessing.

Fix 1: It works on my phone but not my laptop. Why?

Your laptop cached the old answer. Browsers store 301 responses aggressively, often with no expiry, and replay them without contacting the server. Any earlier test can stick, including a wrong redirect you've since corrected.

In Chrome, open DevTools (F12), right-click the reload button and choose Empty Cache and Hard Reload. Firefox and Safari need the site's data cleared from settings. The faster route is to stop testing in that browser at all, because curl and a private window don't carry the cache.

Confirm: curl -I http://olddomain.com shows 301 and the correct Location:.

Fix 2: Move the cPanel rule above the WordPress block

This is the classic redirect not working in cPanel case. The Domains » Redirects tool writes its rule at the bottom of public_html/.htaccess. On a WordPress site, the # BEGIN WordPress block above it sends every request for a non-existent path to index.php and stops processing with the [L] flag, so a redirect for /old-page never runs. The homepage may still redirect, which makes the bug look random.

1. In cPanel's File Manager, open Settings and tick Show Hidden Files.
2. Back up first: download .htaccess, or run cp .htaccess .htaccess.bak over SSH.
3. Cut the RewriteCond and RewriteRule lines cPanel added at the bottom and paste them above # BEGIN WordPress, directly under a RewriteEngine On line.

A whole-domain move should look like this:

apacheCopy
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?olddomain\.com$ [NC]
RewriteRule ^(.*)$ https://newdomain.com/$1 [R=301,L]

# BEGIN WordPress

Keep your rule outside the BEGIN and END WordPress markers, because WordPress rewrites everything between them whenever you save permalinks. The Apache mod_rewrite documentation explains each flag, and our 301 redirect htaccess examples cover single pages, trailing slashes and HTTPS.

Confirm: curl -I http://olddomain.com/old-page returns 301, not 200.

Fix 3: Point the old domain's DNS at the server holding the rule

A server-side redirect only runs if the old domain resolves to that server. Run dig +short olddomain.com A. Blank output means there's no A record, and an unfamiliar IP means the domain still points at an old host.

Add or correct the @ A record at whichever provider your nameservers actually point to. Editing DNS at the registrar does nothing if the nameservers sit at Cloudflare, and vice versa. The cPanel documentation covers the Zone Editor if your host runs your DNS. Resolvers hold the old answer for the record's TTL, commonly 3,600 seconds, so give it about 1 hour before retesting. Still stuck after that? Work through why a domain isn't propagating, and for a subdomain see these subdomain DNS and hosting fixes.

Confirm: dig +short returns your hosting IP.

Fix 4: Domain forwarding not working on HTTPS

When domain forwarding not working shows up only on https://, the redirect isn't the problem. TLS is. The browser finishes a certificate handshake before it sends the HTTP request, and if the forwarding server has no certificate for your domain, the connection dies with a privacy warning.

As of 2026, many registrar forwarding services redirect plain HTTP only and never issue a certificate for the forwarded domain, so any visitor arriving on https:// sees a security warning instead of the 301. Hosting the redirect on a server or proxy that issues a free Let's Encrypt certificate fixes it for good.

You have two clean options:

• Add the old domain to your hosting account as an alias or addon domain, let AutoSSL issue the certificate, then add the rule from Fix 2. If the certificate refuses to issue, these AutoSSL fixes cover the usual blockers.
• Or proxy the domain through Cloudflare (Fix 5), which issues an edge certificate automatically.

Then switch off the registrar forwarding so the two don't compete.

Confirm: curl -I https://olddomain.com returns 301 with no certificate error.

Fix 5: Cloudflare redirect rule does nothing

Cloudflare only applies rules to traffic it proxies. With a grey-cloud (DNS only) record, visitors go straight to your origin and the rule never runs. Cloudflare's own Page Rules troubleshooting guide names this as the most common reason forwarding fails.

For a parked domain with no server behind it, add an A record for @ pointing to 192.0.2.1 (a reserved placeholder address) and a CNAME for www, both set to Proxied. Build the rule with Single Redirects under Rules, since Page Rules are deprecated. Two gotchas: only the first matching rule runs, and the Free plan allows 10 Single Redirect rules per zone.

Confirm: the curl -I response includes server: cloudflare alongside your 301.

Fix 6: Break a domain redirect loop

A domain redirect loop ends in ERR_TOO_MANY_REDIRECTS once Chrome gives up after 20 hops. The loop we untangle most on Cloudflare-fronted sites: SSL mode is set to Flexible, so Cloudflare talks to your server over HTTP, your server's force-HTTPS rule bounces the visitor back to https://, and round it goes.

Set SSL/TLS to Full (strict) with a valid certificate on the origin. Then hunt for rules that disagree: Cloudflare adding www while .htaccess strips it, or a WordPress Site Address that doesn't match your redirect target. Run curl -IL and read the Location: headers; a loop shows the same two URLs alternating. Our guide to redirecting HTTP to HTTPS on Apache, Nginx and Cloudflare has loop-safe rules for each stack.

Live site and no time to experiment? Our engineers fix redirect loops and broken forwarding for a small one-time fee, and you'll see the exact quote before anyone touches your server. Hosted with Hostaccent already? Then issues like this are simply covered by support, free. Have an engineer fix your redirect

Fix 7: www redirect not working, but the bare domain is fine

A www redirect not working almost always means one of two missing pieces. Either www has no DNS record (dig +short www.olddomain.com comes back empty), or the certificate doesn't cover www, so HTTPS fails before any rule runs.

Add a CNAME for www pointing to the bare domain, then reissue the certificate so both names are on it. Check what the certificate covers with:

bashCopy
echo | openssl s_client -connect www.olddomain.com:443 -servername www.olddomain.com 2>/dev/null | openssl x509 -noout -ext subjectAltName

Also confirm your rule matches both hostnames: ^(www\.)?olddomain\.com$ does, while ^olddomain\.com$ misses www.

Confirm: all four versions (http and https, with and without www) return 301.

How to Confirm the Redirect Works (and Keep It Working)

A redirect is confirmed when curl shows every entry point reaching the final URL with a 301, whatever your browser claims.

As of 2026, a healthy domain redirect sends all four entry points (http and https, with and without www) plus any deep URL to the matching page on the new domain in no more than 2 hops, finishing on a 200 status. Test one deep link such as /blog/some-post too. If it lands on the homepage instead of the matching page, fix that before search engines notice.

For a full domain move, file the change in Google Search Console's Change of Address tool and keep the redirects live for at least 1 year, which matches Google's guidance for site moves. Keep the old domain registered as well. If it lapses, the redirect dies with it, along with every backlink still pointing there.

One lesson from the 4,000+ site migrations Hostaccent has handled since 2016: write the redirect map before you switch DNS, not the morning after, when crawlers have already found a wall of 404s.

Insider Insight: Give every redirect exactly one owner. Pick the registrar, Cloudflare or .htaccess, add a comment beside the rule saying why it exists, and delete the duplicates. Nearly every loop we've traced started as two layers doing the same job.

Your Next Step: A Redirect That Stays Fixed

Fixed it? Now that you know most failures come from a correct rule running at the wrong layer, keep each redirect in one place and test it with curl rather than your browser. On a well-managed host, untangling DNS, SSL and .htaccess conflicts is support's job, and your time goes back to your site. Hostaccent's shared hosting comes with free Let's Encrypt SSL, 24/7 human support from our own engineers, and a 30-day money-back guarantee. The Economy plan at $1.99/mo renews at the same $1.99/mo, so you can start on the Economy plan knowing the price holds. It's sized for a single site, so if you run several, Standard fits you better.

Still stuck? A domain redirect not working after all seven fixes usually means two layers are fighting each other. Open a ticket with our engineers: a small one-time fee, with the exact quote in front of you before any work starts.

Frequently Asked Questions

Why is my domain redirect not working after I set it up in cPanel?

Usually because cPanel's Redirects tool appends the rule to the bottom of your .htaccess file, below WordPress's rewrite block. WordPress catches the request first and stops processing, so your rule never runs for inner pages. Move the rule's RewriteCond and RewriteRule lines above "# BEGIN WordPress", save, and test with curl -I instead of your browser. If curl still returns 200, check that the domain's DNS points to that hosting account.

How long does a domain redirect take to start working?

A redirect added in cPanel or Cloudflare works within seconds, because it's a server or edge rule rather than a DNS change. Delays come from elsewhere. If you also changed DNS records, resolvers can keep the old answer for the record's TTL, often 3,600 seconds, and nameserver changes can take 24-48 hours. If curl shows the 301 but your browser doesn't, the browser cache is holding you up, not propagation.

Why does my domain forwarding work on HTTP but not HTTPS?

The browser needs a valid certificate for the old domain before it will even request the redirect. Many registrar forwarding services don't issue one, so HTTPS visitors get a privacy warning and never reach the 301. Host the redirect somewhere that issues a free Let's Encrypt certificate instead, such as your hosting account through AutoSSL or a domain proxied through Cloudflare, then switch off the registrar forwarding so the two don't clash.

How do I fix a domain redirect loop?

Run curl -IL on the URL and read the Location headers. If the same two URLs keep alternating, two layers disagree. The most common cause is Cloudflare's Flexible SSL mode combined with a force-HTTPS rule on your server, and switching Cloudflare to Full (strict) with a valid origin certificate ends it. Otherwise, look for www and non-www rules pointing in opposite directions, or a WordPress Site Address that doesn't match your redirect target.

Should I use a 301 or 302 redirect for a domain?

Use a 301 for any permanent move, such as a rebrand or merging domains, because it tells search engines to pass ranking signals to the new address. Use a 302 while you're still testing. Browsers cache 301s aggressively, so a mistake made with a 301 can stick on visitors' devices long after you've fixed it. Once the 302 behaves correctly for every variant, switch it to a 301 and leave it in place.