Beyond 301 and 302: Client-Side Redirects

Most developers know about server-side redirects (301, 302, etc.) — but there's another category: client-side redirects. These are handled not by the server, but by the browser after the HTML page has been delivered. The two most common types are meta refresh redirects and JavaScript redirects.

While they can get the job done in certain situations, they carry significant trade-offs that make them poor substitutes for proper server-side redirects in most cases.

What Is a Meta Refresh Redirect?

A meta refresh redirect is an HTML tag placed in the <head> of a page that instructs the browser to navigate to a new URL after a specified delay.

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

In this example, the browser waits 5 seconds, then navigates to the new URL. Setting content="0" causes an immediate redirect.

Drawbacks of Meta Refresh

  • Poor user experience: A delay (even a short one) is jarring. Users see a blank or partially loaded page before being moved.
  • Weak SEO signal: Google has historically treated meta refresh with suspicion — especially when used with a 0-second delay, which can look like a cloaking technique.
  • No HTTP-level signal: The server still returns a 200 OK for the original page. Search engines must parse the HTML to discover the redirect, which is slower and less reliable.
  • Breaks browser back button: In many cases, users clicking "Back" are immediately sent forward again, trapping them in a loop.

What Is a JavaScript Redirect?

A JavaScript redirect uses client-side script to send the user to a new URL. The most common form is:

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

Or using replace (which removes the current page from browser history):

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

Drawbacks of JavaScript Redirects

  • Requires JavaScript execution: If a user has JavaScript disabled, the redirect never fires. More importantly, some bots and crawlers do not execute JavaScript at all — meaning they may never follow the redirect.
  • Delayed execution: Googlebot can render JavaScript, but it processes JS-rendered content in a second wave — sometimes days or weeks later. This creates indexing lag.
  • No link equity transfer: JavaScript redirects do not reliably pass link equity to the destination URL.
  • Accessibility concerns: Screen readers and assistive technologies may not handle JS-triggered navigation gracefully.

When Are Client-Side Redirects Acceptable?

Despite their drawbacks, there are narrow use cases where client-side redirects make sense:

  • Single Page Applications (SPAs): React, Vue, and Angular apps manage routing entirely in JavaScript. Server-side redirects are not always feasible, and frameworks handle this gracefully with proper routing libraries.
  • After form submissions: Redirecting a user to a "thank you" page after a form submission (where SEO is not a concern) is a common and acceptable JS redirect use case.
  • User-controlled navigation: Redirecting based on user preferences, login state, or language selection — scenarios where the destination cannot be known at the server level.

Server-Side vs. Client-Side: A Quick Comparison

Feature Server-Side (301/302) Meta Refresh JavaScript
HTTP Status Signal ✅ Yes ❌ No (returns 200) ❌ No (returns 200)
Link Equity Transfer ✅ Yes (301) ⚠️ Partial ❌ Unreliable
Works Without JS ✅ Yes ✅ Yes ❌ No
Crawlable by All Bots ✅ Yes ⚠️ Usually ⚠️ Depends on bot
Best for SEO ✅ Yes ❌ No ❌ No

The Verdict

For any redirect that matters to your SEO or user experience, always prefer a server-side 301 or 302. Reserve meta refresh and JavaScript redirects for specific application logic where server-side redirects are genuinely not viable — and always document why you chose a client-side approach so future developers understand the intent.