Redirects Using Meta Refresh: Why and How to Replace Them

What this check flags

This audit hint fires when a crawler requests a URL, receives a normal 200 response, and then finds a meta refresh directive inside the returned HTML that sends the browser somewhere else. In other words, the page pretends to be a real page at the HTTP level but behaves like a redirect at the content level. Sitebulb classifies this as an Insight rather than a hard error, but its advice is unambiguous: ideally remove the meta refresh and use a 301 permanent redirect instead. Each flagged URL is a place where a redirect decision was made in the wrong layer of the stack.

How meta refresh differs from a real HTTP redirect

An HTTP redirect happens at the protocol level. The server answers the request with a 301 or 302 status code and a Location header, and the client immediately requests the new URL. Nothing needs to be downloaded, parsed, or rendered. A meta refresh is the opposite: it is a client-side instruction buried in the document. The browser or crawler must download the full HTML, parse the head, discover the refresh directive, and only then start a second request. That makes it slower for users, more expensive for crawlers, and ambiguous for search engines, because the original URL never returns a redirect status code at all. It returns 200, which is the signal for "this is a live, indexable page."

That ambiguity has real consequences. Sitebulb notes that search engines may not always follow the meta refresh instruction, that there is no guarantee link equity will be passed on, and that both the old and new URLs can end up sitting in the index together. A clean 301 removes all of that doubt with a single unambiguous status code.

What Google says

Google's redirect documentation does handle meta refresh. It distinguishes two kinds: an instant meta refresh (a zero-second delay that fires as soon as the page loads) is interpreted as a permanent redirect, while a delayed meta refresh is treated as a temporary one. So Google will usually do something sensible with these pages. But the same documentation is explicit about the preferred approach: use server-side HTTP redirects, ideally permanent ones like 301 or 308, whenever your platform allows it. Meta refresh is listed as an alternative for situations where server-side redirects are not possible, not as an equivalent option. If you control the server, there is no reason to settle for the fallback.

Why accessibility hates timed refreshes

The W3C documents meta refresh with a time delay as WCAG failure F40 (timed meta redirect) and F41 (timed meta reload). The problem is the countdown. A delayed redirect is an unexpected change of context: a screen reader user may still be partway through the page when the browser suddenly jumps somewhere else and the reader starts over from the top. Users with cognitive or motor impairments may not have time to read or act on the interstitial content. Developers cannot predict how much time any given user needs. The W3C does carve out one exception: a zero-second meta refresh is acceptable because it is instant and never perceived as a change of context. But at that point you are simulating a redirect badly, and a real 301 is strictly better.

How to diagnose it

Open the flagged URL list from your crawler and inspect one of the pages. You can confirm the pattern from the command line: curl -sI https://example.com/old-page/ will show a 200 status (not a 3xx), and curl -s https://example.com/old-page/ | grep -i refresh will reveal the meta tag. Note the delay value and the destination URL for each page. Also check whether the destination itself is final, so you do not create a chain when you convert the redirect. The typical offender looks like this:

<!-- Bad: client-side redirect inside a 200 page -->
<meta http-equiv="refresh" content="5; url=https://example.com/new-page/">

How to fix it

Remove the meta refresh tag from the page and implement the same hop as a server-side 301. On Apache or LiteSpeed hosting (including most cPanel setups), add a rule to your .htaccess file:

# Good: permanent server-side redirect in .htaccess
Redirect 301 /old-page/ https://example.com/new-page/

# Or with mod_rewrite for pattern matching:
RewriteEngine On
RewriteRule ^old-section/(.*)$ https://example.com/new-section/$1 [R=301,L]

On nginx, use a return directive in the server block: location = /old-page/ { return 301 https://example.com/new-page/; }. On WordPress, a redirect manager such as the one built into Rank Math or the Redirection plugin lets you create 301 rules without touching server config; just remember to delete the meta tag from the page template afterward so you do not stack two redirects. Once deployed, verify with curl -sI that the old URL now returns 301 with the correct Location header, and recrawl to confirm the hint clears.

When is meta refresh acceptable?

Almost never. The one defensible case is a static hosting environment where you genuinely cannot configure server responses and no platform-level redirect feature exists. Even then, use a zero-second delay so Google treats it as permanent and so you stay clear of the WCAG timed-redirect failures, and add a plain link to the destination as a fallback. If you have .htaccess access, an nginx config, or a CMS redirect manager, you have no excuse: use the server.

FAQ