Meta Refresh Redirect: What It Is and Why It Hurts SEO

What Is a Meta Refresh Redirect?

A meta refresh redirect is an HTML instruction that tells a browser to reload or navigate to a different URL after a set number of seconds. It lives inside the as a tag, and it's entirely client-side — the browser, not the server, decides when to act. That matters: a real server response (like a 301) happens before the page ever loads, while a meta refresh only fires once the HTML has already been downloaded and parsed.

Basic syntax with no delay:

With a delay, commonly used for "this page has moved" notices:

The number before the semicolon is the delay in seconds; 0 means immediate. MDN's reference on the http-equiv attribute and its broader meta element documentation cover this syntax and flag it as a legacy mechanism — useful in specific static-hosting scenarios, but rarely the right primary tool for redirecting traffic.

How Google Actually Interprets Meta Refresh (Instant vs. Delayed)

Google doesn't treat every meta refresh the same way. Per Google's own redirect documentation, a meta refresh with a 0-second delay is interpreted as a permanent redirect signal, functionally similar to a 301. A meta refresh with any delay greater than zero is treated as a temporary redirect, closer to a 302. Ahrefs' glossary entry on the meta redirect confirms the same instant-versus-delayed split, citing Google's guidance directly.

If you're asking "is meta refresh bad for SEO," the honest answer is: it depends on which version you're using and what you're trying to signal. Want Google to permanently consolidate ranking signals onto a new URL? An instant meta refresh can eventually achieve something close to what a 301 does. Want a temporary detour — say, during a migration test? A delayed one is the more accurate signal.

But "can work" isn't the same as "works well." Comparing meta refresh vs. 301 redirect head-to-head, the 301 wins on every practical dimension: it's faster (no HTML parse required), unambiguous to every crawler and browser, and doesn't rely on JavaScript-free rendering assumptions holding true across every bot. Google may treat a permanent meta refresh similarly to a 301, but it still has to discover and render the tag first — a step a real redirect skips entirely.

Why Meta Refresh Still Causes Problems

Even when Google interprets a meta refresh "correctly," it still introduces friction a server-side redirect avoids entirely.

Crawling and indexing take longer. A 301 is resolved in the HTTP response headers before any HTML is sent. A meta refresh requires Googlebot to fetch the page, parse the , find the tag, and then decide how to act — an extra round trip that delays indexing decisions and burns crawl budget, especially on large sites.

Link equity transfer is weaker and slower. Even with the permanent-redirect interpretation for 0-second refreshes, signal consolidation is less immediate and less reliable than with a proper 301. Chaining meta refreshes, or mixing them with other redirect types, compounds these problems — Google has publicly discouraged redirect chains of any kind, and meta refreshes are especially prone to getting tangled into them during site migrations.

Accessibility is the most underrated cost. MDN's http-equiv documentation flags refresh explicitly as a risk for screen reader users and people with low vision or cognitive disabilities: an automatic reload can interrupt someone mid-read, reset their scroll position, or fire before assistive technology has finished announcing the page. This is a failure WCAG guidance has long warned against, and it's a real barrier for real users, independent of any SEO impact.

Users bounce. A blank screen with "you will be redirected in 5 seconds" reads as broken or dated. Combined with the rendering delay, it's simply a worse experience than an instant, invisible redirect.

How to Find Meta Refresh Tags on Your Site

For a single page, detection is trivial. Right-click, choose "View Page Source" (or open DevTools and inspect the ), and search for http-equiv="refresh". If it's there, you'll see the delay value and destination URL right in the markup.

That works fine for one URL you're already suspicious about. It falls apart the moment you need to check a site with hundreds or thousands of pages — old migrated sections, legacy CMS templates, or pages built by a previous agency are the usual culprits, and nobody remembers where they all are. Site-wide crawling is the only way to detect meta refresh tags at scale: a crawler fetches every URL, parses the HTML, and flags any page carrying the tag, along with its delay setting and target. This is also where manual QA stops being realistic — you need something automated watching the whole domain, not just the pages you remember to check.

How to Replace Meta Refresh With a Proper Redirect

The standard fix is a server-side 301. On Apache, an .htaccess rule looks like:

Redirect 301 /old-page.html https://example.com/new-page

On Nginx, the equivalent lives in the server block:

rewrite ^/old-page.html$ https://example.com/new-page permanent;

Either way, the redirect happens in the HTTP response header, before any HTML is parsed — faster, unambiguous, and fully supported by every crawler and browser. That's the server-side redirect vs. meta refresh comparison in a nutshell: one is a protocol-level instruction, the other a page-level workaround.

There are narrow cases where a delayed meta refresh with a noindex tag is an acceptable stopgap — mainly static-hosting environments (some site generators, or platforms without server config access) where you genuinely can't issue a 301. Even then, treat it as temporary scaffolding, not a permanent architecture decision, and migrate to a real redirect as soon as server access allows. Meta refresh should be a last resort used deliberately, not a default because "it worked once."

For teams auditing redirect strategy as part of a larger technical cleanup, meta refresh is just one line item in a much longer checklist — see the full technical SEO audit framework for the broader picture, and the HTTP status code guide for why status codes matter beyond just redirects.

Frequently Asked Questions

Does Google penalize meta refresh redirects?

No, but Google doesn't treat them as favorably as a 301 either. A 0-second meta refresh is interpreted as a permanent redirect signal, while any delay is treated as temporary — neither triggers a manual penalty, but both introduce crawling delays and weaker signal transfer compared to a server-side redirect.

What's the difference between a meta refresh and a 301 redirect?

A 301 is a server-side HTTP status code returned before any page content loads, while a meta refresh is a client-side HTML tag that only executes after the browser has fetched and parsed the page. The 301 is faster, unambiguous to all crawlers, and the accepted standard; a meta refresh is a workaround best reserved for environments without server access.

Is it ever okay to use a meta refresh redirect?

Yes, but only as a last resort — typically on static-hosting platforms where you can't configure server-level redirects. There, a delayed meta refresh paired with a noindex tag is an acceptable temporary stopgap, not a permanent solution.

How do I find meta refresh tags on my website?

For a single page, view-source or inspect the and search for http-equiv="refresh". For an entire site, use a crawler that fetches every URL and flags the tag automatically, since manual checking doesn't scale past a handful of pages.

Does a meta refresh pass link equity to the new page?

Partially, and less efficiently than a 301. An instant meta refresh can consolidate signals similarly to a permanent redirect over time, but the transfer is slower and weaker than a direct 301, especially if the refresh is chained with other redirects.

What delay should I use if I have to keep a meta refresh temporarily?

Use a delay long enough to signal Google the move is temporary rather than permanent — anything above 0 seconds qualifies — while keeping it short enough not to frustrate users, typically a few seconds. Pair it with a noindex directive and plan to replace it with a proper 301 as soon as possible.

Manually viewing source is fine for checking one suspicious page, but it won't catch every meta refresh tag, redirect chain, or accessibility issue hiding across a full site. Run a free Optimevra audit — or explore the live demo — to see these issues flagged automatically, site-wide, in minutes.