Redirect Types & Concepts
What is a meta refresh redirect?
A meta refresh redirect is a type of URL redirect implemented through an HTML meta tag in the head of a web page rather than through a server-side HTTP response. Instead of the server immediately responding with a 3xx status code and a Location header before the page loads, the server returns the page with a 200 OK and the browser reads the meta tag in the HTML, waits for the specified delay, and then navigates to the destination URL.
The meta tag that triggers the redirect looks like this:
The content attribute defines two things: the delay in seconds before the redirect fires, and the destination URL. In the example above the browser waits five seconds then navigates to https://destination.com. Setting the delay to zero fires the redirect as soon as the browser parses the tag.
Meta refresh redirects were one of the earliest redirect mechanisms on the web, predating the widespread adoption of server-side HTTP redirects in modern infrastructure. Today they are considered a poor practice for almost every use case and have been largely replaced by proper server-side redirects. Understanding what they are, why they exist, and why they should almost never be used is useful for anyone working with web redirects and SEO.
How a meta refresh redirect works
The mechanics of a meta refresh redirect differ fundamentally from a server-side redirect and that difference has significant consequences.
With a server-side redirect, a 301, 302, or any other 3xx redirect, the redirect happens before any page content is delivered. The server receives the request, checks its redirect rules, and responds immediately with a redirect status code and Location header. The browser follows the location and loads the destination. The original page HTML is never sent to the browser and never rendered.
With a meta refresh redirect the sequence is entirely different. The server receives the request and responds with a 200 OK, indicating success, followed by the full HTML of a page containing the meta refresh tag. The browser receives this response, begins parsing the HTML, finds the meta tag in the head, reads the delay and destination, and starts a timer. When the timer expires, whether that is zero seconds or five seconds or any other value, the browser navigates to the destination URL.
This means several things. The original page is loaded and rendered, at least partially, before the redirect fires. The server is serving a page that it is immediately redirecting away from. The browser and search engines receive a 200 OK for the original URL rather than a redirect status code. And there is a delay, however brief, between the request being fulfilled and the visitor reaching the intended destination.
Meta refresh redirects and SEO
Meta refresh redirects are significantly inferior to server-side redirects for SEO and should not be used for any redirect scenario where SEO matters.
No clear permanent or temporary signal: server-side redirects use specific HTTP status codes to communicate permanence. A 301 tells search engines the move is permanent and SEO equity should transfer. A 302 tells them it is temporary. A meta refresh tag carries no equivalent signal; it is a page instruction, not an HTTP response code. Search engines must infer the intent from context rather than reading a definitive status code.
Unreliable SEO equity transfer: because there is no clear permanent redirect signal, link juice transfer through a meta refresh is unreliable. Google has stated it attempts to follow meta refresh redirects and transfer some equity, but the transfer is less reliable and potentially less complete than with a 301 redirect. For any URL with meaningful backlink equity, using a meta refresh rather than a 301 risks losing some or all of that value.
Crawl budget waste: Googlebot and other web crawlers load the original page, parse the HTML to find the meta tag, and then follow the redirect to the destination. This is a two-step process that consumes more crawl resources than a direct server-side redirect that resolves in a single hop.
Duplicate content risk: because the original URL returns a 200 OK rather than a redirect status code, search engines may index the original URL separately from the destination. If both the original and destination pages are indexed with similar content, this creates a duplicate content issue that a proper redirect would have prevented.
Delayed index update: because the SEO signal from a meta refresh is weaker and less clear than a server-side redirect, search engines typically take longer to update their index to reflect the change. A 301 redirect is processed and acted upon relatively quickly. A meta refresh may be treated with more uncertainty.
Meta refresh redirects and user experience
Beyond SEO, meta refresh redirects create a noticeably worse user experience than server-side redirects in most scenarios.
Visible delay: even a zero-second meta refresh delay involves the browser loading the original page, parsing the HTML, and then initiating navigation to the destination. This creates a perceptible flash or blank moment that a server-side redirect eliminates entirely. A non-zero delay is even more disruptive: visitors see the original page briefly or for an extended period before being redirected, which is confusing and unprofessional.
Back button behaviour: meta refresh redirects with a non-zero delay create a problematic back button experience. When a visitor uses the browser back button to return to the previous page, they may find themselves stuck in the redirect again as the browser navigates back to the redirecting page and the meta refresh fires again. Server-side redirects handle back button navigation cleanly because the browser understands the redirect and can navigate past it correctly.
Accessibility concerns: visitors using screen readers or assistive technologies may encounter issues with meta refresh redirects. Some screen readers read the content of the redirecting page before the redirect fires, which can be disorienting. The Web Content Accessibility Guidelines specifically address meta refresh, noting that timed redirects can interfere with accessibility.
No redirect notification: visitors who land on a page with a meta refresh have no way to know they are about to be redirected until it happens. A page that loads and then suddenly navigates away can be alarming or confusing, particularly with longer delays.
When meta refresh redirects are used
Given the clear disadvantages, why do meta refresh redirects exist and when are they still encountered?
Legacy systems with no server-side access: the most legitimate historical use case. Early web hosting environments and simple HTML-only sites had no way to configure server-side redirects. The meta refresh tag was the only available mechanism for redirecting visitors. Many of these legacy implementations still exist on the web despite the hosting landscape having evolved dramatically.
Content management systems with limited redirect support: some older CMS platforms and website builders did not expose server-side redirect configuration to users, offering meta refresh as the only redirect option. This has become increasingly rare as modern platforms universally support proper redirect management.
Intentional delayed redirects: one of the few scenarios where a non-zero delay meta refresh might be used deliberately is to show a message before redirecting. For example, a page that says “This page has moved. You will be redirected in 5 seconds.” This can be useful for communicating a move to visitors but should always be accompanied by a canonical tag pointing to the destination and ideally supplemented with a server-side redirect.
Simple HTML pages without server access: developers building static HTML pages on hosting environments where server configuration is not accessible, shared hosting with no .htaccess support, certain static hosting platforms, may use meta refresh as a fallback when no server-side option is available. This is a genuinely constrained scenario where meta refresh is better than nothing, though the correct solution is to migrate to hosting that supports server-side redirects.
Meta refresh vs JavaScript redirects
Meta refresh redirects and JavaScript redirects are both client-side redirect mechanisms that operate after the page has been delivered to the browser rather than at the server level. They share several characteristics and limitations.
Both are slower than server-side redirects because they require the browser to load the original page before navigating away. Both return a 200 OK on the original URL rather than a redirect status code. Both are less reliable for SEO equity transfer than 301 redirects. And both should be replaced with server-side redirects wherever possible.
The key differences are in how they are implemented and how search engines handle them.
A meta refresh is implemented as an HTML tag and is processed by the browser’s HTML parser as soon as the tag is encountered in the page head. It does not require JavaScript to be enabled and works in all browsers including those with JavaScript disabled.
A JavaScript redirect is implemented as code that runs in the browser’s JavaScript engine. It requires JavaScript to be enabled: if a visitor has JavaScript disabled, the redirect does not fire and they remain on the original page. Search engines can generally execute JavaScript and follow JavaScript redirects, but the processing is slower and less reliable than HTML-level or server-level redirects.
For SEO, Google has indicated it treats a zero-delay meta refresh similarly to a server-side redirect in terms of following it and potentially passing equity, but less reliably than a true 301. JavaScript redirects are followed by Googlebot but are processed in a second rendering wave after the initial crawl, meaning there can be a significant delay between a page being crawled and the JavaScript redirect being followed.
Neither should be used when a server-side redirect is available. When they must be used, a zero-delay meta refresh is marginally preferable to a JavaScript redirect from an SEO standpoint because it is processed faster and does not depend on JavaScript execution.
How to identify a meta refresh redirect
Meta refresh redirects are visible in the HTML source of the redirecting page. Viewing the page source (right-click and View Page Source in most browsers) and searching for http-equiv="refresh" in the head section reveals whether a meta refresh is in use.
In browser developer tools, a meta refresh redirect does not appear as a separate network request the way a server-side redirect does. The original page loads as a 200 OK and then a new navigation event begins when the meta refresh fires. This is another way to identify a meta refresh: if a URL shows a 200 in the network tab but the browser ends up on a different URL, the redirect is likely a meta refresh or JavaScript redirect rather than a server-side redirect.
Replacing a meta refresh with a server-side redirect
Wherever a meta refresh redirect exists and server access is available, replacing it with a proper server-side redirect is straightforward and always worth doing.
On Apache servers a 301 redirect can be added to the .htaccess file. On Nginx it goes in the server config block. On most modern hosting platforms, CMS tools, and redirect management services, redirects can be configured through a control panel without touching server configuration files directly.
The steps are simple. Identify the source URL: the page currently containing the meta refresh tag. Identify the destination URL: the value in the url= part of the meta refresh content attribute. Configure a 301 redirect from the source to the destination at the server level. Remove the meta refresh tag from the source page HTML; it is no longer needed. Verify the redirect is working correctly using browser developer tools or a redirect checker.