Key Takeaways
- A meta refresh redirect uses
<meta http-equiv="refresh" content="0; url=https://destination.com/">in the HTML<head>— not the HTTP response layer - Immediate meta refresh (delay=0) passes some PageRank, but Google recommends server-side 301 redirects for permanent moves — they pass equity more reliably
- Delayed meta refresh (delay > 0, e.g. 5 seconds) is explicitly called out in Google's quality guidelines as a deceptive pattern when used to show different content before redirecting
- JavaScript redirects (
window.location) are similarly treated — Google can execute them but with a rendering delay; server redirects are always faster - Use the Redirect Tracer to check whether a URL is doing a server-side redirect (visible in HTTP response headers) or a meta/JS redirect (only visible after HTML parsing)
How Meta Refresh Works
Add this to the <head> of an HTML page:
<meta http-equiv="refresh" content="5; url=https://new-destination.com/">The content attribute has two parts: the number before the semicolon is the delay in seconds before the redirect fires, and url= sets the destination. With content="0; url=...", the redirect fires immediately with no visible delay to the user.
Browsers display the original page briefly before redirecting — or immediately for delay=0. Users on slow connections may see the intermediate page flash before being sent to the destination. This intermediate exposure is exactly what Google's quality systems pay attention to.
How Google Treats Meta Refresh for SEO
Google can follow meta refresh redirects. Immediate (delay=0) meta refreshes do pass PageRank — but less reliably than HTTP 301 redirects, and with more processing overhead for Googlebot. The reason is straightforward: a 301 is communicated in the HTTP response headers, which Googlebot reads before parsing any HTML. A meta refresh requires Googlebot to fetch the page, parse the HTML, find the meta tag, and then follow the redirect. That's a slower and less authoritative signal.
Delayed meta refreshes (delay > 0) are treated with considerably more suspicion. Google's quality guidelines note that redirecting users after a delay is a pattern associated with cloaking and deceptive redirects — where the page shown to Googlebot differs from what users eventually see after the timer runs out.
The bottom line: for permanent moves, use HTTP 301 server redirects. Meta refresh is acceptable only for situations where you have no control over the server configuration — for example, redirecting from a static page hosted on a platform that does not support server-level redirects.
Delayed Meta Refresh — the Spam Signal
Delayed meta refresh (showing an intermediate page for 3–10 seconds before redirecting) appears in two well-known problematic patterns that Google's spam detection actively looks for:
Cloaking attempt: The intermediate page is optimised with rich content to attract organic search traffic. After a delay, users are silently redirected to a different (often lower-quality or monetised) page. Googlebot sees the content-rich intermediate; users get the destination. This is a direct violation of Google's spam policies.
Parasite SEO pages: Low-quality intermediate pages accumulate PageRank from inbound links, then pass users on to another site via the delayed refresh. The intermediate page captures the ranking signal without delivering the value.
If your site uses delayed meta refresh for entirely legitimate purposes — such as "this page has moved, you'll be redirected in 5 seconds" — the practical risk is low. But switching to a server 301 eliminates the risk entirely and is objectively better for users. There is no scenario in which a delayed meta refresh is the best technical choice.
JavaScript Redirects vs Meta Refresh vs 301
All three redirect types are encountered in the wild. The table below shows how they differ on dimensions that matter for SEO.
| Redirect type | Speed | Equity transfer | Googlebot handling |
|---|---|---|---|
| HTTP 301 (server) | Instant | Reliable, full | First HTTP response — fastest |
| HTTP 302 (temporary) | Instant | Minimal | First HTTP response |
| Meta refresh (delay=0) | After HTML parse | Partial | Requires HTML fetch + parse |
| Meta refresh (delayed) | After delay | Unreliable | Treated as suspicious |
| JavaScript redirect | After JS execution | Partial | Requires full render |
JavaScript redirects (window.location = "..." or window.location.replace("...")) are handled by Google in a similar way to meta refresh: Google can execute them, but only after the full render cycle. Google's crawler operates a two-wave indexing process — first it fetches and indexes the raw HTML, then it queues the page for rendering with a headless browser. A JavaScript redirect will only be followed in the second wave, introducing a potential delay of days between discovery and equity transfer. Server 301s are processed in the first wave, immediately.
Checking What Type of Redirect a URL Is Doing
The HTTP status code in a server response tells you whether a 3xx redirect is happening at the server layer. But a meta refresh or JavaScript redirect returns a 200 — the page loads successfully and the redirect happens after HTML or JS execution. The Redirect Tracer shows the HTTP response status for each hop in a redirect chain:
- A 301 appears as an HTTP status code in the first response — the chain entry shows status 301 and a Location header pointing to the next URL
- A meta refresh appears as a 200 response — the chain stops there from an HTTP perspective, but the actual redirect only fires once a browser (or Googlebot's renderer) parses the HTML
- A JavaScript redirect also appears as a 200 initially, with the redirect logic buried in inline or linked scripts
If a URL returns 200 in the Redirect Tracer but you expected a 301, the redirect is almost certainly a meta refresh or JavaScript redirect. Inspect the HTML source — look for <meta http-equiv="refresh" in the <head>, or search for window.location in the page's scripts.
When Meta Refresh Is Acceptable
There are a small number of situations where meta refresh is the only option available:
- You control static HTML files but not the server configuration — for example, a simple file hosting service, a CDN bucket serving static assets, or a platform like GitHub Pages with no .htaccess support
- The redirect is immediate (delay=0)
- The destination is the permanent intended URL — not a temporary location
In every other case, replace meta refresh with a 301. It is better for SEO, faster for users, and requires no additional maintenance. There is no meaningful advantage to keeping a meta refresh in place once you have server access.
If you are auditing a site that uses meta refresh redirects and need to identify all instances quickly, crawl the site with the Link Checker to find 200-status pages in redirect chains — then inspect those pages' source HTML for meta refresh tags. The Redirect Tracer will confirm which hops are server-side and which are HTML-based.
Check Whether Your Redirects Are Server-Side or HTML-Based
Free, no signup. The Redirect Tracer follows each hop in a redirect chain and reports the HTTP response status — instantly showing whether a URL is doing a proper 301 or a meta/JS redirect.
Try the Redirect Tracer Free →Affiliate disclosure: Some links on this page may be affiliate links. We only mention tools we've personally used and have an honest opinion about. Affiliate revenue helps keep ByteWaveNetwork's tools free and maintained. We are not paid by any of the tools compared in this article for favorable coverage.