Meta Refresh Test
The Meta Refresh Test scans the <head> of any URL for <meta http-equiv="refresh"> tags that trigger a client-side redirect after a delay.
- Results in seconds
- Pass / fail + fix guidance
- No account required
The Meta Refresh Test scans the <head> of any URL for <meta http-equiv="refresh"> tags that trigger a client-side redirect after a delay. While Google can sometimes interpret meta refresh as a 301 when the delay is zero, it is universally a poor substitute for a proper server-side redirect — slower for users, weaker for SEO, and a known cause of unintentional duplicate content. This tool surfaces every meta refresh on the page and gives you the exact server-side replacement.
What This Tool Checks
- Presence of <meta http-equiv="refresh"> tag
- Delay value (0 = instant, anything else hurts UX)
- Target URL of the refresh
- Cross-origin refresh destinations
- Refresh used as a "temporary maintenance" page
- Combination of meta refresh + JavaScript redirect
Why It Matters for SEO
Meta refresh is a relic of the late 1990s. Google treats a 0-second meta refresh as a 301 in most cases, but anything longer is treated as a soft 302 and passes far less link equity. From a UX perspective, meta refresh visibly delays the user and can confuse the back button. Server-side 301 redirects are faster, clearer to crawlers, and the universally recommended replacement.
How to Fix It
Replace every meta refresh with a server-side 301 redirect at the web server, application or CDN level (Apache .htaccess, Nginx config, Cloudflare Page Rule). Remove the <meta http-equiv="refresh"> tag from the HTML. Verify with the URL Redirect Checker that the new redirect is a clean single-hop 301.
How It Works
We fetch the page, parse the <head> for any <meta http-equiv="refresh"> elements, and report the URL the user will be sent to plus the delay before redirect fires. Cross-origin redirects, non-zero delays and chained refreshes are flagged for replacement.
Common Mistakes to Avoid
- Using meta refresh because the team has no access to server config
- Non-zero delay creating a confusing "redirecting in 5 seconds" experience
- Meta refresh + canonical tag pointing at conflicting URLs
- Old "domain has moved" splash pages still using meta refresh
- Forgetting that meta refresh breaks the browser back button
Quick Checklist
- No <meta http-equiv="refresh"> tags in production HTML
- All redirects implemented server-side as 301s
- Old "this page has moved" splash pages converted to 301s
- Internal links updated to final URLs
- Verified clean redirect chain via the redirect checker
Put your whole site on autopilot — SEO and AI search
PositionMySite monitors every signal on this page across your entire website 24/7 — plus keyword rankings, competitor moves and AI-search readiness (llms.txt, schema, ChatGPT & Gemini visibility). When something breaks, you know before Google does.
Every feature unlocked · No commitment · Cancel anytimeFrequently Asked Questions
An HTML tag (<meta http-equiv="refresh" content="0;url=...">) that tells the browser to load a different URL after a delay. It is a client-side redirect implemented in HTML rather than at the server.
It is acceptable when the delay is zero (Google may treat it as a 301), but always inferior to a real server-side 301. With any delay it becomes a soft 302 that leaks link equity.
Late 1990s and early 2000s, when developers without server-config access needed a way to redirect URLs. Modern hosting universally supports server-side redirects, so meta refresh is no longer needed.
Configure the redirect at your web server (Apache RewriteRule, Nginx return 301, Express res.redirect(301, ...)) or at your CDN (Cloudflare Page Rule, CloudFront function). Remove the meta tag from the HTML afterwards.
Yes. The visible delay before redirect fires increases the user's perceived load time and can affect Largest Contentful Paint on the source URL. A real 301 redirect avoids this entirely.