Meta Refresh Redirect: How It Works and Why Server Redirects Beat It
A meta refresh is an HTML instruction (`<meta http-equiv="refresh" content="5; url=...">`) that tells the browser to load another URL after N seconds. It happens after the page is delivered and parsed, making it a client-side redirect rather than an HTTP one.
Why it matters
The myth is that meta refresh is "penalised"; the reality per Google is that it is treated as a redirect. The case against it is mechanics, not punishment. The user downloads and renders a page only to be sent somewhere else, delayed refreshes strand screen-reader and slow-connection users, and the redirect is invisible to anything that only reads HTTP (like many crawlers and API clients).
How it works
The browser receives and parses the full HTML page. When it encounters the meta refresh tag in the head, it reads the content attribute. If a delay is specified (e.g., 5), it waits that long. If a URL is included, it loads that URL. Instant meta refreshes (delay 0) feel immediate but still require the page to fully load first, making them slower than server redirects.
Google processes meta refreshes as redirects after rendering the page. An instant meta refresh is treated roughly like a permanent redirect, while a delayed one is weaker and less consistent. The delay, accessibility impact, and user experience cost are why Google recommends server redirects instead.
What does not matter
Meta refresh is not banned by Google and does not trigger a penalty. You can use it without fear of ranking loss. The issue is speed and UX, not a search algorithm rule. A static hosting provider with no server config access might use meta refresh as the only redirect option, and it works.
The delay value does not affect how Google treats the redirect. Google processes the tag as a signal regardless of the timeout. The delay only affects the user experience: a 0-second refresh is faster, a 5-second delay lets users read a "redirecting" message.
Code example
Good: Instant meta refresh when no server redirect is available.
<head>
<meta http-equiv="refresh" content="0; url=https://new-url.example.com" />
</head>
This reaches the browser in the full page response, so it's slower than a server 301 but faster than a delayed refresh.
Better: Server-side 301, which doesn't require the page to load.
return 301 https://new-url.example.com;
Broken: Delayed meta refresh that strands users on slow connections.
<meta http-equiv="refresh" content="5; url=https://example.com" />
Users on 2G connections or with accessibility tools wait 5 seconds to learn they're being sent elsewhere, and screen readers may not announce the target.
Most parsers accept variations in spacing and casing:
<!-- All of these are valid -->
<meta http-equiv="refresh" content="0; url=https://example.com" />
<meta http-equiv="refresh" content="0; URL=https://example.com" />
<meta http-equiv="refresh" content="0;url=https://example.com" />
<meta http-equiv="refresh" content="0" /> <!-- no URL, self-refresh -->
When to use meta refresh
Use it only when you genuinely have no server access, like static hosting with no redirect config. For everything else, a server 301 is worth the effort; it's faster for users and crawlers, and it won't confuse screen readers. If you're stuck with a meta refresh, use 0-second delay so at least it feels instant.