How to Remove a 301 Redirect and Clear It From Every Cache

Why a 301 is hard to take back

A 301 status says a page has moved permanently. Every system that sees it is entitled to believe that, and many of them remember it. Removing the rule on your server only changes what the server says from now on. It does not reach the copies already stored elsewhere:

• Browsers. A 301 is cacheable by default under the HTTP standard. Chrome, Edge, Firefox and Safari all store it, and if the response had no caching headers they may keep reusing it without asking your server again, often until the cache is cleared.
• Page caches. WordPress caching plugins, LiteSpeed Cache, Varnish and hosting caches can hold the redirect response and keep serving it.
• CDNs. Cloudflare and other CDNs can cache a redirect your origin sent, and their own redirect rules run before your server sees the request.
• Search engines. Google treats a 301 as a strong signal that the destination is the canonical URL, and it keeps that view until it recrawls the old address and sees it has changed.

So removing a 301 is three jobs: delete the rule at every place it lives, clear every cache you control, and manage the caches you do not control. This guide covers all three.

Find where the redirect lives

Start with a fresh request from the command line, which bypasses your browser's memory:

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

The headers usually point to the layer that sent it:

On your own server, search the configuration directly. On a Plesk server, for example:

sudo grep -rn "old-page" /var/www/vhosts/example.com/httpdocs/.htaccess
sudo nginx -T 2>/dev/null | grep -n "old-page"
sudo grep -rn "old-page" /var/www/vhosts/system/example.com/conf/

In WordPress, check redirect plugins and also the old slug records WordPress keeps when you rename a post:

wp db query "SELECT post_id, meta_value FROM $(wp db prefix)postmeta WHERE meta_key = '_wp_old_slug';"

Delete the rule at its source

Remove the rule from each place you found it, one layer at a time, and retest with curl after each change.

Apache and .htaccess

Delete or comment out the matching Redirect, RedirectMatch or RewriteRule line, together with any RewriteCond lines that belong only to it. Changes take effect on the next request.

nginx and Plesk

Remove the return 301 or rewrite ... permanent line, then test and reload:

sudo nginx -t && sudo systemctl reload nginx

On Plesk, also check the Additional nginx directives and Additional Apache directives boxes, and the preferred domain setting in Hosting settings, which creates its own www or non-www redirect. See redirects on Plesk.

WordPress

Delete the rule in your redirect plugin or SEO plugin. If WordPress itself is redirecting a renamed post, remove its old slug record:

wp post meta delete 123 _wp_old_slug old-page

Replace 123 with the post ID. See redirects in WordPress.

Cloudflare, cPanel and site builders

Delete the matching Single Redirect, Bulk Redirect list entry or Page Rule in Cloudflare; see redirects on Cloudflare. In cPanel, remove it in the Redirects tool and check the lines have gone from .htaccess. On Wix, Squarespace and Webflow, delete it in the redirect settings and publish the site if the platform needs it.

Clear the caches you control, and manage the rest

Once the rule is gone, purge every cache between your server and the visitor, for both the old URL and its destination:

• The CMS page cache or caching plugin.
• Any server cache, such as LiteSpeed, Varnish or the host's own cache.
• The CDN cache. In Cloudflare, use Purge Custom URL under Caching and enter the full old URL.
• Your own browser. Clear cached files, or test in a private window.

Retest with curl until the old URL returns 200 and the cache headers show a fresh response.

Visitors' browsers

You cannot clear other people's browsers. Visitors who received the 301 may keep being sent to the destination until their cache drops it. There are two ways to soften that.

First, if the old URL and its destination are on the same site, the destination page can send a Clear-Site-Data header, which asks the browser to empty its cache for your site. Chrome and Edge support it, and support in other browsers varies, so treat it as a help rather than a guarantee. Use it for a short period only, because it clears every cached file for the site, not just the redirect:

Clear-Site-Data: "cache"

Second, if the destination page is not needed in its own right, it can send visitors back with a temporary redirect to a slightly different address, so they do not hit their stored 301 again:

# nginx, on the destination page, for a limited time
location = /new-page/ {
    return 302 /old-page/?restored=1;
}

The query string makes it a new address that is not in the browser's cache. Give the old page a canonical tag pointing at /old-page/ so search engines ignore the parameter.

Let search engines catch up

Google keeps the destination as the indexed URL until it recrawls the old address and sees a normal page. To speed that up:

• Make sure the old URL returns 200, has a self-referencing canonical tag and has no noindex.
• Add it back to your XML sitemap and remove the destination if that page is no longer wanted.
• Change internal links so they point at the old URL again.
• Inspect the old URL in Search Console, run a live test and request indexing.

If the destination page should no longer exist, return a 404 or 410 for it, or point its canonical tag at the restored page. The canonicals guide explains how these signals combine.

A worked example

A page at /pricing/ was redirected to /plans/ by mistake during a redesign. curl shows a 301 with cf-ray and x-redirect-by: redirection headers. Two layers are involved: the Redirection plugin in WordPress and a Cloudflare redirect rule added while testing.

The plugin rule is deleted first. curl still shows the 301, now without the WordPress header, which confirms Cloudflare is answering. The Cloudflare rule is deleted, then https://www.example.com/pricing/ and /plans/ are purged from the Cloudflare cache and the WordPress page cache is cleared. curl now returns 200 for /pricing/.

The owner's browser still goes to /plans/, which is expected: it cached the 301. A private window shows the correct page, and clearing the browser cache fixes his own view. /pricing/ goes back in the sitemap, the menu link is restored, and indexing is requested in Search Console. Within a week Google shows /pricing/ again.

The fix, step by step

Edge cases worth knowing

• A 308 behaves like a 301. It is also permanent and cached the same way, so the same steps apply.
• HSTS is not a redirect rule. If the redirect you want gone is http to https, and the site sends HSTS, browsers upgrade to https internally regardless of the server. That is intended; do not try to remove it unless you are leaving https, which you should not.
• Whole-domain redirects. If a whole domain was redirected, visitors' browsers may have cached a 301 for every page they visited. Expect the effect to fade over weeks rather than hours.
• Apps and in-app browsers. Some apps keep their own caches. Testing in one browser does not show what every visitor sees.

Avoiding the problem next time

Use a 301 only for moves you are sure are permanent. For anything that might be undone, such as a campaign page, seasonal offer or test, use a 302 or 307, which browsers and search engines treat as temporary. The 302 versus 301 guide explains which to choose.

If you must use a 301 that might change, send a short cache lifetime with it so browsers check again:

# Apache: 301 that browsers recheck after an hour
<If "%{REQUEST_URI} == '/old-page/'">
    Header always set Cache-Control "max-age=3600"
</If>
Redirect 301 /old-page/ /new-page/

# nginx
location = /old-page/ {
    add_header Cache-Control "max-age=3600" always;
    return 301 /new-page/;
}

Keep a written list of every redirect and the layer it lives in, so removing one later means one change in one place. If a redirect you add later refuses to work, see 301 redirect not working.