Meta Refresh Redirect: Why It Hurts SEO and What to Use Instead
A meta refresh redirect is an HTML tag that automatically redirects a user from one page to another after a specified delay. Unlike a proper server-side redirect, it is implemented at the HTML level and has significant SEO drawbacks: it passes link equity less reliably, creates a poor user experience, can be flagged as a spam technique, and is disliked by accessibility standards. In virtually every case where a redirect is needed, a server-side 301 redirect is the correct technical choice. Understanding meta refresh redirects helps you recognize and eliminate them during a technical SEO audit.
What Is a Meta Refresh Redirect?
A meta refresh redirect uses the <meta http-equiv="refresh" content="0;url=https://newpage.com"> tag in a page's <head> to redirect the browser to a different URL. The content attribute specifies the delay in seconds before the redirect fires — content="0" redirects instantly, while content="5" waits 5 seconds. A refresh tag without a URL (content="30") simply reloads the current page after the specified interval, which is sometimes used for dashboards or live feeds. Both forms are technically a meta refresh, but the redirect form is the one with significant SEO implications.
How Google Treats Meta Refresh Redirects
Google has stated that it follows meta refresh redirects and attempts to pass PageRank through them, similar to a 301 redirect. However, the PageRank transfer through meta refresh is less reliable than through a proper HTTP 301. When the delay is 0 seconds, Google generally treats it similarly to a redirect. When the delay is greater than 0 seconds, Google may index both the source page and the destination, creating duplicate content issues. Historically, Google's guidelines listed meta refresh redirects as a cloaking or deceptive redirect technique that can result in manual penalties if used to show different content to users versus crawlers.
User Experience Problems with Meta Refresh
Meta refresh redirects create several user experience issues. When a user clicks the browser's back button after being meta-refreshed, the browser returns to the source page, which immediately redirects them forward again — creating a "back button trap" that prevents users from navigating away. With delayed meta refreshes, users see a blank or transitional page with no progress indicator, which is disorienting. Screen readers and assistive technologies handle meta refreshes poorly. The W3C Web Content Accessibility Guidelines (WCAG) explicitly list meta refresh as a failure point for Success Criterion 2.2.2 (Pause, Stop, Hide) when used without user control. These UX failures increase bounce rates and harm engagement signals.
When Meta Refresh Is Sometimes Found
Meta refresh redirects appear in specific situations: legacy CMS platforms that don't provide server-side redirect configuration, shared hosting environments with no .htaccess or server configuration access, URL shortener tools built on simple HTML, page builders that implement redirects through HTML rather than server configuration, and older e-commerce platforms during migrations. Some developers use meta refresh for post-form-submission redirects — a pattern that should be replaced with a proper HTTP 303 or 302 response followed by a redirect to a confirmation page. Identifying these legacy implementations is part of a thorough technical SEO audit.
How to Find Meta Refresh Redirects on Your Site
Screaming Frog SEO Spider identifies meta refresh tags in the "Response Codes" section — filter for "Meta Refresh" in the Content tab. The tool shows both the source URL and the target URL, along with the delay value. You can also search your codebase with a grep command: grep -r "http-equiv=.refresh" /path/to/templates. For large sites with dynamic pages, crawl with Screaming Frog or Sitebulb to catch meta refresh tags in rendered HTML. Google Search Console's Coverage report may show meta refresh source pages as indexed separately from their destinations if the delay is greater than zero.
Replacing Meta Refresh with Proper 301 Redirects
For every meta refresh redirect, the correct replacement is a server-side 301 redirect. On Apache, use .htaccess: Redirect 301 /old-page https://yourdomain.com/new-page. On Nginx, use return 301 https://yourdomain.com/new-page; in the location block. For WordPress, use the Redirection plugin. For static site hosts like Netlify or Vercel, use the _redirects file or vercel.json redirects configuration. After implementing server-side redirects, remove the meta refresh tags from the HTML. Verify the old URL now returns a 301 HTTP status code using curl -I https://yourdomain.com/old-page before removing the meta tag safety net.
JavaScript Redirects vs Meta Refresh vs HTTP 301
Three types of client-side redirects exist: meta refresh, JavaScript redirects (window.location.href = 'https://newpage.com'), and HTTP 301 server redirects. All three have different SEO implications. HTTP 301 is the gold standard — instant, reliable, full PageRank transfer, no duplicate content risk. Meta refresh passes equity unreliably, creates UX issues, and risks duplicate indexing. JavaScript redirects depend on Googlebot executing JavaScript — it does for most major JavaScript, but there is a processing delay of days to weeks before JavaScript redirects are followed and indexed. For any permanent URL change, always use HTTP 301. JavaScript and meta refresh redirects are acceptable only as temporary fallbacks when server access is unavailable.
Meta Refresh for Page Auto-Reload: SEO Considerations
A meta refresh without a URL (<meta http-equiv="refresh" content="60">) reloads the current page on an interval. This is sometimes used for live data dashboards, scoreboards, or status pages. From an SEO perspective, auto-reloading pages that contain unique content are generally harmless since no redirect occurs. However, frequent auto-reloads increase server load, burn through CDN bandwidth unnecessarily, and create a poor user experience. Modern alternatives like WebSockets, Server-Sent Events (SSE), or periodic fetch() calls update page content dynamically without reloading the entire page, providing a better user experience and lower server overhead.
Monitoring After Removing Meta Refresh Redirects
After replacing meta refresh redirects with 301s, monitor Google Search Console Coverage report for any new 404 errors that may indicate the 301 redirect was not implemented correctly. Use the URL Inspection tool to verify that the old URL returns a 301 and that the new URL is properly indexed. Check the Performance report for changes in impressions and clicks on affected pages over the following 2–4 weeks. Expect Google to consolidate any duplicate index entries (source page and destination page) into the destination URL as it recrawls and processes the new server-side redirects. Link equity consolidation typically completes within 4–6 weeks for well-crawled sites.