Meta Refresh and JavaScript Redirects Explained

Not all redirects happen on the server. Meta refresh tags and JavaScript redirects execute in the browser, after the page has already loaded. They are slower, less reliable, and worse for SEO than server-side redirects. But they exist for a reason, and understanding when (and when not) to use them matters.

Server-Side vs Client-Side Redirects

Server-side redirects (301, 302, 307, 308) happen before the browser renders anything. The server sends a 3xx status code with a Location header, and the browser follows it immediately.

Client-side redirects happen after the browser receives a 200 OK response and starts parsing the page. The redirect is triggered by HTML or JavaScript in the page content.

Server-side redirect:
  Browser requests /old-page
  Server responds: 301, Location: /new-page
  Browser requests /new-page
  Time: ~1 round trip

Client-side redirect:
  Browser requests /old-page
  Server responds: 200 OK, <html>...</html>
  Browser parses HTML, finds redirect instruction
  Browser requests /new-page
  Time: ~2 round trips + HTML parsing time

The performance difference is significant. A client-side redirect adds at minimum one extra round trip plus the time to download and parse the initial page.

Meta Refresh Redirects

The <meta> refresh tag is an HTML element that tells the browser to load a different URL after a specified delay:

<!-- Immediate redirect (0 second delay) -->
<meta http-equiv="refresh" content="0;url=https://example.com/new-page">

<!-- Delayed redirect (5 second delay) -->
<meta http-equiv="refresh" content="5;url=https://example.com/new-page">

The content attribute has two parts: the delay in seconds and the destination URL.

How Browsers Handle Meta Refresh

Browser receives the full HTML response (status 200)
Browser parses the <head> section and finds the meta refresh tag
After the specified delay, browser navigates to the new URL
The browser's back button behavior varies: some browsers add the original page to history, others do not

How Search Engines Handle Meta Refresh

Google treats a meta refresh with a 0-second delay similarly to a 301 redirect for indexing purposes, but with some important caveats:

Behavior	301 Server Redirect	Meta Refresh (0s)	Meta Refresh (5s+)
Status code sent	301	200	200
Link equity transfer	Yes, full	Partial, unreliable	Minimal or none
Indexing signal	Strong canonical signal	Weak canonical signal	Not treated as redirect
Crawl efficiency	One request	Two requests	Two requests + delay
User experience	Instant, invisible	Flash of old page	User sees old page for seconds

Google's position on meta refresh

Google's documentation states they can follow meta refresh redirects, but they prefer server-side redirects. A meta refresh is a weaker signal than a 301, and there is no guarantee Google will pass full link equity through it.

JavaScript Redirects

JavaScript redirects use browser APIs to navigate to a new URL:

// Most common method
window.location.href = "https://example.com/new-page";

// Alternative methods
window.location.replace("https://example.com/new-page");
window.location.assign("https://example.com/new-page");

// Using the top-level window (for frames/iframes)
window.top.location.href = "https://example.com/new-page";

The Difference Between location.href and location.replace

// Adds the current page to browser history
// User can press Back to return to the redirecting page
window.location.href = "https://example.com/new-page";

// Replaces the current page in browser history
// User pressing Back goes to the page BEFORE the redirecting page
window.location.replace("https://example.com/new-page");

For redirects, location.replace() is almost always the correct choice. Using location.href means the user presses Back and lands on the redirecting page again, which immediately redirects them forward, creating a broken Back button experience.

How Search Engines Handle JavaScript Redirects

Google renders JavaScript and can follow JavaScript redirects, but with limitations:

First crawl: HTML only

Googlebot initially crawls the page without executing JavaScript. It sees a 200 OK response with no redirect indication.

Second pass: JavaScript rendering

Google's rendering service executes the JavaScript and discovers the redirect. This may happen hours or days after the initial crawl.

Indexing decision

Google may or may not treat the JavaScript redirect as a canonical signal. The behavior is inconsistent and depends on Google's rendering queue and resources.

Other search engines are worse at JavaScript

Bing and other search engines have limited JavaScript rendering capabilities. A JavaScript redirect that Google might follow could be completely invisible to Bing. If you rely on JavaScript redirects, assume that non-Google search engines will not follow them.

Trace your redirect chains

Find redirect loops, broken chains, and unnecessary hops instantly.

When Client-Side Redirects Are Acceptable

Despite the drawbacks, there are legitimate use cases:

1. No Server Access

If you are on a static hosting platform (GitHub Pages, Netlify static sites) or a CMS that does not allow server configuration, client-side redirects may be your only option.

<!-- Static HTML page that redirects -->
<!DOCTYPE html>
<html>
<head>
  <meta http-equiv="refresh" content="0;url=https://example.com/new-page">
  <title>Redirecting...</title>
</head>
<body>
  <p>Redirecting to <a href="https://example.com/new-page">the new page</a>.</p>
</body>
</html>

2. Conditional Redirects Based on Client State

Redirects that depend on browser capabilities, screen size, or client-side state that the server cannot detect:

// Redirect based on JavaScript support detection
if (!window.CSS || !CSS.supports('display', 'grid')) {
  window.location.replace('/legacy-browser');
}

3. Single Page Applications (SPAs)

In SPAs, client-side routing handles navigation. A "redirect" within an SPA is really a route change, not an HTTP redirect. This is a different concept entirely and is fine.

4. Post-Authentication Redirects in Client-Side Auth Flows

OAuth callbacks and similar flows sometimes require client-side redirects to handle tokens in URL fragments:

// After OAuth callback with token in hash
const token = window.location.hash.split('=')[1];
if (token) {
  sessionStorage.setItem('token', token);
  window.location.replace('/dashboard');
}

When Client-Side Redirects Are NOT Acceptable

Permanent URL Changes

If a URL has permanently moved, use a 301. A meta refresh or JavaScript redirect will lose SEO equity and confuse search engines.

Site Migrations

Never rely on client-side redirects for domain or URL structure migrations. The SEO cost is too high. Use server-side 301 redirects.

HTTP to HTTPS Enforcement

HTTPS enforcement must happen at the server or CDN level. A client-side redirect means the initial HTTP request completes before the redirect, exposing the user to potential man-in-the-middle attacks during that first request.

Any High-Traffic Page

The performance cost of an extra round trip multiplied by thousands of daily visitors adds up quickly. Use a server-side redirect.

Detection and Auditing

Client-side redirects are harder to detect than server-side ones because they do not appear in HTTP headers:

# This will NOT detect client-side redirects
curl -I https://example.com/page
# Shows 200 OK even if the page has a meta refresh

# To detect meta refresh, download the full page
curl -s https://example.com/page | grep -i "meta.*refresh"

# To detect JavaScript redirects, download and search
curl -s https://example.com/page | grep -i "location\.\(href\|replace\|assign\)"

A proper redirect tracing tool should detect both server-side and client-side redirects by rendering the page, not just following HTTP headers.

The Bottom Line

Use server-side redirects (301, 302, 307, 308) whenever possible. Use meta refresh only when you have no server access and need a simple redirect. Use JavaScript redirects only for client-state-dependent routing. Never use client-side redirects for permanent URL changes, site migrations, or SEO-critical pages.

Method	Speed	SEO	Reliability	Use When
301/302 (server)	Fastest	Best	Most reliable	Always, if possible
Meta refresh (0s)	Slow	Acceptable	Good	No server access
Meta refresh (5s+)	Very slow	Poor	Good	Almost never
JavaScript redirect	Slow	Poor	Unreliable without JS	Client-state dependent routing

If the server can do the redirect, let the server do the redirect. Client-side redirects are the fallback, not the default.

Never miss a broken redirect

Trace redirect chains and detect issues before they affect your users and SEO. Free instant tracing.