R
Redirect Tracer

HTML Meta Refresh Redirect: Syntax and When to Use

How the HTML meta refresh redirect works, the correct syntax, how search engines treat it, when it makes sense, and when server-side redirects are the better choice.

The HTML meta refresh tag is one of the oldest ways to redirect a web page. It works by embedding a redirect instruction directly in the page's HTML, telling the browser to navigate to a different URL after a specified delay. Unlike server-side redirects (301, 302), which happen at the HTTP level before the page loads, a meta refresh redirect requires the browser to download the HTML first and then follow the instruction.

Meta refresh redirects still work in every modern browser, but they come with tradeoffs that make server-side redirects the better choice in most situations. This article covers the syntax, how search engines interpret meta refresh, the cases where it makes sense, and when to avoid it. For a comparison of all redirect methods, see Redirect Methods Compared.

The Syntax

The meta refresh tag goes inside the <head> section of an HTML document:

<!DOCTYPE html>
<html>
<head>
  <meta http-equiv="refresh" content="0;url=https://example.com/new-page">
  <title>Redirecting...</title>
</head>
<body>
  <p>This page has moved. If you are not redirected automatically,
  <a href="https://example.com/new-page">click here</a>.</p>
</body>
</html>

The content attribute has two parts separated by a semicolon:

  • The delay (in seconds): 0 means redirect immediately. 5 means wait five seconds before redirecting.
  • The URL: The destination URL, prefixed with url=.

Variations in Syntax

The syntax is forgiving. All of the following work in modern browsers:

<!-- Standard syntax -->
<meta http-equiv="refresh" content="0;url=https://example.com/new-page">

<!-- With quotes around the URL -->
<meta http-equiv="refresh" content="0;url='https://example.com/new-page'">

<!-- Space after semicolon -->
<meta http-equiv="refresh" content="0; url=https://example.com/new-page">

<!-- Uppercase -->
<meta http-equiv="refresh" content="0;URL=https://example.com/new-page">

The most reliable and widely supported syntax is the first example: no quotes around the URL, no space after the semicolon.

Refresh Without a URL

If you omit the URL, the meta refresh tag reloads the current page:

<meta http-equiv="refresh" content="30">

This reloads the page every 30 seconds. This pattern was once used for live scoreboards, stock tickers, and news feeds before JavaScript-based solutions became standard. It is now considered a poor practice because it disrupts screen readers, wastes bandwidth, and resets the user's scroll position.

How Search Engines Treat Meta Refresh Redirects

Google has stated that it processes meta refresh redirects, but the treatment depends on the delay value.

Zero-Second Delay

A meta refresh with a 0-second delay is treated similarly to a permanent redirect. Google follows it, passes ranking signals, and generally indexes the destination URL instead of the source URL. This is the closest a meta refresh can get to a server-side 301 redirect.

However, "similarly" is not "identically." Google's documentation recommends server-side redirects as the preferred method. A 0-second meta refresh works, but it is a second-tier signal compared to a proper 301.

Short Delays (1-5 Seconds)

Meta refresh tags with short delays are usually followed by Google, but the treatment becomes less predictable. Google may or may not treat them as redirects for ranking purposes. Some short-delay meta refreshes are treated as redirects; others are treated as separate pages with a link to the destination.

Long Delays (5+ Seconds)

Meta refresh tags with delays of five seconds or more are generally not treated as redirects by Google. Instead, Google may index the source page as its own entity and treat the destination URL as a regular link. This means no ranking signal transfer and no URL consolidation.

Other Search Engines

Bing follows meta refresh redirects with short delays but has less documentation about exactly how it treats them. Historically, Bing has been less consistent than Google in following client-side redirects.

Yandex and Baidu also process meta refresh, but their handling varies. If you are optimizing for search engines beyond Google, server-side redirects are the safest choice.

Always use 0 seconds for SEO redirects

If you must use a meta refresh for a redirect that search engines need to follow, always set the delay to 0. Anything longer risks the redirect being ignored for ranking purposes.

When Meta Refresh Makes Sense

Despite being inferior to server-side redirects in most ways, there are specific situations where meta refresh is the right (or only) tool.

Static Hosting Without Server Access

If your site is hosted on a platform that does not give you access to server configuration (no .htaccess, no nginx.conf, no redirect rules), a meta refresh in an HTML file may be your only option for redirecting a specific page.

GitHub Pages, for example, does not support server-side redirects for individual pages (though it supports custom 404 pages and some redirect configuration through plugins like Jekyll's redirect-from gem). For a simple static HTML page that needs to redirect, a meta refresh works.

Client-Controlled Pages

In some CMS environments, content editors can edit HTML but cannot configure server redirect rules. A meta refresh tag in the page content lets non-technical users set up redirects without involving a developer or system administrator.

Redirect with a Message

If you want to show the user a message before redirecting (such as "This page has moved to a new location. You will be redirected in 5 seconds."), a meta refresh with a delay provides that experience. This is sometimes used during site migrations to give users a heads-up that bookmarks should be updated.

This pattern is falling out of favor. Most users find the delay annoying, and if the redirect is permanent, there is no benefit to making them wait. But it still appears on some institutional and government websites.

Email and Document Links

Some email clients and PDF readers do not follow server-side redirects well. A meta refresh on a landing page can serve as a fallback for environments where HTTP redirect headers are not processed normally.

When to Avoid Meta Refresh

SEO-Critical Redirects

For any redirect where preserving search rankings matters, use a server-side 301. A meta refresh is a weaker signal, adds page load time, and introduces uncertainty about how search engines will treat it. Domain migrations, URL restructuring, and content consolidation should always use server-side redirects.

High-Traffic Pages

Every meta refresh redirect requires the browser to download the HTML page before following the redirect. On a server-side redirect, the browser receives the redirect instruction in the HTTP headers and follows it without downloading any content. For high-traffic pages, this difference in bandwidth and load time adds up.

Accessibility

Screen readers announce the content of the meta refresh page before following the redirect. For a 0-second redirect, this is a brief flash of content. For longer delays, the screen reader reads the page content, then the page changes, and the screen reader starts over on the new page. This is disorienting for users who rely on assistive technology.

The W3C Web Content Accessibility Guidelines (WCAG) 2.1 Success Criterion 3.2.5 advises against using meta refresh redirects because they initiate a change of context that the user did not request. Server-side redirects are transparent to assistive technology.

Mobile Performance

Mobile users on slow connections experience the delay most acutely. A meta refresh redirect adds the time to download the source page's HTML on top of the delay value on top of the time to load the destination page. A server-side redirect eliminates the first two steps.

Meta Refresh vs Other Client-Side Redirects

JavaScript Redirects

JavaScript redirects use window.location to navigate:

<script>
  window.location.href = "https://example.com/new-page";
</script>

JavaScript redirects are even less reliable than meta refresh for SEO. Not all crawlers execute JavaScript, and the redirect only works if JavaScript is enabled in the browser. However, JavaScript redirects offer more flexibility: you can redirect conditionally, pass data through the redirect, or redirect based on client-side state.

Server-Side Redirects

Server-side redirects (301, 302, 307, 308) are the gold standard. They are faster (no HTML download needed), better supported by search engines, transparent to assistive technology, and configurable at the server or CDN level. Use server-side redirects whenever you have access to server configuration.

For a detailed comparison of all methods, see Meta and JavaScript Redirects and Redirect Methods Compared.

Implementation Examples

Static Site Generator (Hugo, Jekyll, Eleventy)

If your static site generator does not have a redirect plugin, create a redirect page manually:

<!-- /old-page/index.html -->
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta http-equiv="refresh" content="0;url=/new-page/">
  <link rel="canonical" href="/new-page/">
  <title>Redirecting</title>
</head>
<body>
  <p>This page has moved to <a href="/new-page/">/new-page/</a>.</p>
</body>
</html>

The rel="canonical" link tag reinforces the redirect signal to search engines by declaring the destination as the canonical version of the content.

WordPress Without Plugin Access

If you cannot install a redirect plugin and cannot edit .htaccess, add a meta refresh to the page template:

<?php
// In a custom page template
get_header();
?>
<meta http-equiv="refresh" content="0;url=<?php echo esc_url('/new-page/'); ?>">
<p>Redirecting to <a href="/new-page/">/new-page/</a>...</p>
<?php get_footer(); ?>

This is a workaround, not a best practice. Use a redirect plugin or .htaccess rules if at all possible. See the WordPress Redirect Guide.

Testing Meta Refresh Redirects

Test that your meta refresh redirects work as expected:

# curl does not follow meta refresh redirects by default
# It only follows HTTP redirects with -L
# To see the meta refresh tag in the HTML:
curl -s https://example.com/old-page | grep -i "meta.*refresh"

Since curl does not follow meta refresh redirects, you need to test in a browser or use a tool like Redirect Tracer that can detect both server-side and client-side redirects.

In Chrome DevTools, open the Network tab and navigate to the old URL. You will see the initial page load (200 response with the meta refresh HTML) followed by a navigation to the destination URL. This two-step process is what distinguishes meta refresh from server-side redirects.

References

  1. HTML Standard, "Pragma directives: http-equiv=refresh," WHATWG. https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv-refresh
  2. Google, "Redirects and Google Search," Google Search Central, 2024. https://developers.google.com/search/docs/crawling-indexing/301-redirects
  3. W3C, "Web Content Accessibility Guidelines (WCAG) 2.1, Success Criterion 3.2.5," 2018. https://www.w3.org/TR/WCAG21/#change-on-request
  4. IETF, "RFC 9110 - HTTP Semantics, Section 15.4: Redirection 3xx," June 2022. https://httpwg.org/specs/rfc9110.html#status.3xx

Check how your redirects actually behave

Whether you use meta refresh or server-side redirects, Redirect Tracer shows every hop, status code, and response header in the chain.

Try Redirect Tracer

Related Articles