<meta http-equiv="refresh" content="0;url=...">. It works, but it is a weaker, slower, less reliable way to redirect than a proper server-side 301. If this check flagged one, replace it with a real HTTP redirect wherever you can.The meta refresh is one of the oldest tricks in web history, older than the CSS box model. You drop a tag in the head of a page and the browser reloads to a new URL after a set number of seconds. It still works in every browser today. That is exactly why it survives in codebases: it needs no server access, no config file, no htaccess. Anyone who can edit HTML can write one. The problem is that "it works" and "it is the right way to redirect for SEO" are two different claims, and the meta refresh only satisfies the first.
What a meta refresh is
It is an HTML tag in the document head:
<meta http-equiv="refresh" content="0;url=https://example.com/new-page">
The content attribute holds two things: a delay in seconds, then a URL to send the browser to. A delay of 0 means redirect immediately. Any number higher than that means the current page shows for that many seconds first, then the browser navigates away. You have seen the delayed version on "you are being redirected, click here if nothing happens" pages.
The critical distinction: this is a client-side redirect. The server sends back a normal 200 OK with a full HTML page, and the browser reads the tag and decides to navigate somewhere else. Compare that to a server-side 301 or 302, where the server never sends page content at all, it just returns a redirect status code and a Location header, and the browser follows it before rendering anything.
Server-side versus meta refresh
Why it matters for SEO
Google can and does follow meta refreshes. John Mueller has said an instant meta refresh, delay zero, is treated similarly to a 301. So this is not a catastrophe. But "similar to" is not "the same as," and the meta refresh loses on several practical fronts:
- It is slower. The browser has to download the whole page, parse the head, and then navigate. A server redirect happens before any content is sent. On a slow connection the user sees a flash of the wrong page, or worse, sits on it for the delay you set.
- The signal is ambiguous. A 301 is an unambiguous "permanent, pass the equity." A meta refresh has no permanence code. Google has to infer intent from the delay value. Zero delay reads like a redirect, a non-zero delay reads more like a temporary interstitial.
- It does not exist for non-HTML. You cannot meta refresh a PDF or an image. Server redirects handle everything.
- It is a known spam pattern. Delayed meta refreshes and JavaScript redirects were long abused for cloaking and doorway pages, so search engines scrutinize them more than a clean 301.
- It can break the back button. A user who lands on the refreshing page and hits back gets bounced forward again, trapping them.
When a meta refresh is acceptable
There are legitimate cases. If you have zero server access, no htaccess, no redirect plugin, no CDN rules, and you need to move one page, a delay-zero meta refresh is a reasonable stopgap. Some payment and OAuth flows use short delayed refreshes to show a "processing" state. And a genuinely informational "your download is starting" page with a visible delay is a real UX pattern, not an SEO redirect at all. The check flags meta refreshes because most of them are lazy substitutes for a proper redirect, not because every single one is wrong.
How to detect them
| Tool | How |
|---|---|
| Screaming Frog | Crawl the site, open the Response Codes tab, filter by "Redirection (Meta Refresh)". It lists every page with the tag and its target. |
| Sitebulb | Flags meta refresh redirects in its indexability and redirect reports alongside the delay value. |
| View source | Search the raw HTML head for http-equiv="refresh". Quick spot check for a single page. |
| curl | curl -s https://example.com/page | grep -i refresh shows the tag from the raw response. |
| GSC URL Inspection | Shows how Google resolved the URL and whether it treated it as a redirect. |
How to fix it
- Confirm the intent. Is this meant to be a permanent redirect? Then it wants a 301. Temporary? A 302. A real interstitial? Then it might be fine as is.
- Replace with a server-side redirect. On Apache, an htaccess rule:
Redirect 301 /old-page https://example.com/new-page. On Nginx, areturn 301in the server block. On WordPress, a redirect plugin. On a CDN, an edge redirect rule. - Remove the meta tag from the old page once the server redirect is live, so you do not stack two redirects on top of each other.
- Test the response.
curl -sI https://example.com/old-pageshould now return301and aLocationheader, with no page body. - Recrawl in Screaming Frog to confirm the meta refresh count is zero and every redirect resolves in a single hop.
- Use a server-side 301 for permanent moves
- Reserve meta refresh for cases with no server access
- Set delay to 0 if you must use one for a redirect
- Point the target directly at the final URL, no chains
- Verify with a curl of the response headers after the fix
- Use a delayed meta refresh to move real pages
- Stack a meta refresh on top of a server redirect
- Chain a meta refresh into another redirect
- Use it for anything that is not HTML
- Assume it passes equity exactly like a clean 301
What good looks like
Zero meta refresh redirects in your crawl. Every intentional redirect is a single-hop server-side 301 or 302 that returns the right status code with a Location header and no page body. The only http-equiv="refresh" tags left, if any, are genuine user-facing interstitials with a visible delay and a manual click-through link, not silent SEO redirects.
FAQ
Does Google follow meta refresh redirects?
Does a meta refresh pass link equity?
Is a meta refresh the same as a JavaScript redirect?
Are meta refreshes ever fine to keep?
Meta refreshes, chains, loops, and mismatched status codes quietly leak crawl budget and ranking signal. Our audit maps every redirect on your site and shows you exactly which ones to rewrite as clean single-hop 301s.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
