301 Redirect Not Working: How to Find and Fix the Cause

Why a 301 redirect seems not to work

A 301 redirect tells browsers and search engines that a page has moved permanently to a new address. When you add one and the old URL still loads, or you remove one and it keeps redirecting, the cause is nearly always one of three things:

1. A cache is answering instead of your server. Browsers store 301 responses and reuse them without asking again. Page caches and CDNs can also hold the old response.
2. Another rule handles the request first. A CMS, plugin, hosting panel or CDN rule catches the URL before your redirect gets the chance, or sends it somewhere else afterwards.
3. The rule is in the wrong place or the wrong format. An .htaccess rule on an nginx server, a path entered with the domain on a site builder, or a pattern that does not quite match the URL being requested.

The first job is to stop guessing which. The browser is the worst tool for this, because it shows what it remembers. A command-line request shows what the server actually sends now.

How to test a redirect properly

Request the old URL with curl, which never caches redirects:

curl -sI https://www.example.com/old-page

A working redirect returns something like:

HTTP/2 301
location: https://www.example.com/new-page/
server: nginx

To follow the whole chain and see each step, add -L and filter the output:

curl -sIL https://www.example.com/old-page | grep -iE '^(HTTP/|location:|server:|x-redirect-by:|cf-)'

Read the result against this table:

The headers often tell you which layer answered. cf-ray means Cloudflare, x-redirect-by: WordPress or a plugin name means the CMS, and the server header shows whether Apache, nginx or LiteSpeed sent it. Test every variant too: http and https, with and without www, and with and without a trailing slash, because a rule often matches only one of them.

Apache, .htaccess, nginx and Plesk

Apache and .htaccess

For .htaccess rules to work at all, three things must be true: the server runs Apache or LiteSpeed, the virtual host allows overrides with AllowOverride All (or at least FileInfo), and for RewriteRule the rewrite module is enabled, with RewriteEngine On in the file. A quick test is to put a deliberate typo at the top of .htaccess: if the site does not return a 500 error, the file is not being read.

Common mistakes in the rule itself:

• A leading slash in the pattern. In .htaccess, RewriteRule patterns are matched without the leading slash, so ^/old-page$ never matches. Use ^old-page/?$.
• Rules below the WordPress block. WordPress sends every request that is not a real file to index.php. Put redirects above # BEGIN WordPress.
• Query strings. RewriteRule does not see anything after the ?. Match it with a RewriteCond %{QUERY_STRING} line.
• Mixing modules. Redirect 301 lines and RewriteRule lines are handled by different Apache modules. Mixing them for the same URLs gives results that are hard to predict; pick one.

nginx

nginx does not read .htaccess files at all. If the server header says nginx and Apache is not running behind it, every rule in .htaccess is ignored. Redirects go in the server block, and nginx must be reloaded after each change:

sudo nginx -t && sudo systemctl reload nginx

Plesk

On Plesk with nginx in front of Apache, .htaccess works for most pages, because nginx passes them to Apache. But if Serve static files directly by nginx is switched on under Apache and nginx Settings, requests for files such as .pdf or .jpg never reach Apache, so .htaccess redirects for them do nothing. Put those redirects in the Additional nginx directives box instead. On a Plesk site running nginx only, all redirects must go there. See redirects on Plesk and redirects on Apache.

Cloudflare, cPanel, WordPress and site builders

Cloudflare

Cloudflare Redirect Rules only act on traffic that passes through Cloudflare, so the DNS record for the hostname must be proxied, shown by the orange cloud. A grey-cloud record goes straight to your server and ignores every Cloudflare rule. Rules also run in order, so an earlier rule can catch the request first. Check Single Redirects, Bulk Redirects and any old Page Rules for overlapping matches. Purge the cache for the URL after changing anything. See redirects on Cloudflare.

cPanel

The Redirects tool under Domains writes lines into the .htaccess file of the domain's document root. The usual reasons it fails are choosing the wrong domain from the list, the www option not matching how visitors arrive, and the wildcard box being ticked or left unticked by mistake. Open .htaccess in File Manager afterwards and check the generated RewriteCond and RewriteRule lines sit above the WordPress block.

WordPress

Redirect plugins only run when WordPress loads, so a page cache plugin or server cache can serve the old page without WordPress ever seeing the request. Clear the page cache after adding a redirect. WordPress also redirects old post slugs on its own, which can override or confuse a plugin rule. See redirects in WordPress.

Wix, Squarespace and Webflow

On all three, enter the old path without the domain, match the trailing slash exactly as the old URL had it, and check that no live page still sits at the old path.

Working redirect rules

One page on Apache

RewriteEngine On
RewriteRule ^old-page/?$ /new-page/ [R=301,L]

# BEGIN WordPress
...

A whole domain on Apache

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

One page on nginx

location = /old-page {
    return 301 /new-page/;
}

A whole domain on nginx

server {
    listen 443 ssl;
    server_name old-example.com www.old-example.com;
    # ssl_certificate lines for the old domain go here
    return 301 https://new-example.com$request_uri;
}

$request_uri keeps the path and query string, so every old page goes to its matching new page. The old domain still needs a valid certificate, or browsers stop with a security warning before they ever see the redirect.

A worked example

A business renames its services page from /services-old/ to /services/ and adds this to .htaccess:

# BEGIN WordPress
...
# END WordPress
RewriteRule ^/services-old/$ /services/ [R=301,L]

The old URL still loads. curl returns 200. There are two faults. The rule sits below the WordPress block, so WordPress has already taken the request, and the pattern starts with a slash, so it would not match in .htaccess anyway. Moving the rule above # BEGIN WordPress and changing it to ^services-old/?$ gives a 301 in curl straight away.

The owner's browser, however, now loops between the two pages. Earlier that week he had tested a redirect from /services/ to /services-old/, and the browser cached it. A private window shows the redirect working correctly, and clearing the browser cache fixes his own view.

The fix, step by step

Edge cases worth knowing

• The old URL is a real file or folder. If a file or directory still exists at the old path, some setups serve it before the rewrite runs. Remove or rename it.
• Redirects that only work on http. A rule placed in the port 80 server block, or a CDN rule limited to http, does nothing for https visitors. Check both.
• Case differences. URLs are case-sensitive on most servers. Add [NC] on Apache, or a case-insensitive match on nginx, if old links use mixed case.
• Encoded characters. Paths with spaces or accented letters arrive encoded, for example %20. Match the form the server actually receives.
• Google still shows the old URL. That is not a broken redirect. Search engines take days or weeks to recrawl and update results.

Keeping redirects reliable

1. Keep each redirect in one place only: the server, the CMS or the CDN. Write down which layer you use so the next person does not add a competing rule elsewhere.
2. Point every redirect at the final URL, so a later change does not create a chain.
3. Keep a simple list of old and new URLs, and test it with a curl loop after every hosting move, plugin change or redesign.
4. Update internal links to the new URL rather than relying on the redirect for your own menus and content.

If you later need to undo a permanent redirect, the guide to removing a 301 redirect covers the caches involved. For larger moves, see migration redirects.