A JavaScript redirect is a client-side redirect that uses JavaScript code executed in the browser to navigate visitors from one URL to another. Instead of the server responding with an HTTP status code and a Location header before any content is delivered, as a server-side redirect does, a JavaScript redirect requires the browser to load the original page, execute the JavaScript code, and then initiate navigation to the destination.

JavaScript redirects are one of the two primary forms of client-side redirect alongside meta refresh redirects. Both share the same fundamental limitation, they require the original page to be loaded before the redirect can happen, but JavaScript redirects add an additional dependency on JavaScript being enabled and executed in the browser before navigation begins.

For the vast majority of redirect use cases, a JavaScript redirect is the wrong tool. It is slower than a server-side redirect, less reliable for SEO, dependent on JavaScript being available, and processed by search engines through a slower, less reliable rendering pipeline. Understanding exactly why, and when JavaScript redirects are genuinely appropriate, is important for anyone managing web redirects and technical SEO.

How a JavaScript redirect works

The mechanics of a JavaScript redirect differ fundamentally from a server-side redirect and involve more steps at every stage.

When a browser requests a URL that has a JavaScript redirect, the server responds with a 200 OK and delivers the full HTML of the page. The browser receives this response and begins parsing the HTML. When the JavaScript engine encounters the redirect code, either inline in the page or loaded from an external script file, it executes the navigation instruction and the browser navigates to the destination URL.

The most common JavaScript redirect implementations use the window.location object:

// Navigate to destination and add original URL to browser history
window.location.href = 'https://destination.com';

// Navigate to destination without adding original URL to browser history
window.location.replace('https://destination.com');

// Navigate to destination and add original URL to browser history
window.location.assign('https://destination.com');

// Navigate to destination and add original URL to browser history
window.location.href = 'https://destination.com';

// Navigate to destination without adding original URL to browser history
window.location.replace('https://destination.com');

// Navigate to destination and add original URL to browser history
window.location.assign('https://destination.com');

// Navigate to destination and add original URL to browser history
window.location.href = 'https://destination.com';

// Navigate to destination without adding original URL to browser history
window.location.replace('https://destination.com');

// Navigate to destination and add original URL to browser history
window.location.assign('https://destination.com');

Each of these methods triggers immediate navigation when executed. In practice they are typically placed in a script tag in the page head or wrapped in a DOMContentLoaded event listener to fire as soon as the DOM is ready.

A JavaScript redirect can also be conditional, executing only when certain criteria are met:

if (document.referrer.includes('specific-source')) {
  window.location.replace('https://destination.com/special-page');
} else {
  window.location.replace('https://destination.com');
}

if (document.referrer.includes('specific-source')) {
  window.location.replace('https://destination.com/special-page');
} else {
  window.location.replace('https://destination.com');
}

if (document.referrer.includes('specific-source')) {
  window.location.replace('https://destination.com/special-page');
} else {
  window.location.replace('https://destination.com');
}

This conditional capability is one of the genuinely useful properties of JavaScript redirects for specific use cases that server-side redirects cannot address.

window.location.href vs window.location.replace vs window.location.assign

The three primary JavaScript redirect methods differ in one important way: how they interact with the browser history.

window.location.href: assigns a new URL to the location object. The browser navigates to the new URL and adds the original URL to the browser history stack. Pressing the back button returns to the redirecting page, which causes the redirect to fire again. This can trap visitors in a redirect loop from their perspective: pressing back takes them to the redirecting page, which immediately redirects forward again.

window.location.replace: navigates to the new URL and replaces the current entry in the browser history rather than adding a new one. The original URL is removed from the history stack. Pressing the back button skips the redirecting page entirely and returns to whatever was before it. This is the closest JavaScript equivalent to a server-side redirect in terms of history behaviour and is the recommended method for redirect use cases.

window.location.assign: functionally identical to setting window.location.href. Navigates to the new URL and adds the original URL to the browser history. Included for completeness but offers no advantage over href assignment for redirect purposes.

For any JavaScript redirect that is replacing a page permanently or temporarily, rather than navigating within an application flow, window.location.replace is the correct choice because it does not create the back-button trap that href and assign produce.

JavaScript redirects and SEO

The SEO implications of JavaScript redirects are one of the most important topics in technical SEO and a source of significant confusion. Google can follow JavaScript redirects, but the way it does so is fundamentally different from how it handles server-side redirects, and those differences have real consequences.

Two-wave crawling: Googlebot processes pages in two waves. The first wave is a standard HTTP crawl: Googlebot fetches the URL, reads the HTML response, and follows any server-side redirects or links in the HTML. JavaScript is not executed in this first wave. The second wave involves rendering: Googlebot adds the page to a rendering queue, waits for resources to become available, and renders the page with a headless browser that executes JavaScript. JavaScript redirects are only discovered and followed in this second rendering wave.

The gap between the first and second wave can be hours, days, or longer depending on crawl queue depth, site crawl frequency, and available rendering resources. This means a JavaScript redirect may not be followed by Googlebot for a significant period after it is deployed, during which time the original URL continues to be treated as a live page with no redirect.

SEO equity transfer uncertainty: Google has stated it attempts to transfer link juice through JavaScript redirects but the transfer is less reliable than through a 301 redirect. Because the redirect is processed in the rendering wave rather than the crawl wave, and because the original URL returns a 200 OK rather than a 3xx status code, the signals are weaker and the equity transfer is not guaranteed to be complete.

Duplicate content risk: the original URL returns a 200 with content. Until Googlebot processes the rendering wave and follows the JavaScript redirect, it may index the original URL as a standalone page. If that page has similar content to the destination, both URLs can end up indexed creating a duplicate content issue.

No permanent redirect signal: JavaScript does not have an equivalent to the 301 status code. There is no way to tell search engines through a JavaScript redirect whether the move is permanent or temporary. Search engines must infer this from context: the rendering wave result, the presence of canonical tags, the pattern of other signals on the page. A server-side 301 is unambiguous. A JavaScript redirect is not.

Other search engines: while Google’s JavaScript rendering capabilities are relatively advanced, other search engines, Bing, DuckDuckGo, and others, have less sophisticated JavaScript rendering pipelines. A JavaScript redirect that Google follows correctly may not be followed at all by other crawlers, meaning the original URL stays indexed in those engines indefinitely.

JavaScript redirects and browser compatibility

JavaScript redirects depend on JavaScript being enabled and executable in the browser. This introduces a reliability gap that does not exist with server-side redirects or meta refresh redirects.

JavaScript disabled: if a visitor has JavaScript disabled in their browser, a JavaScript redirect does not fire. The visitor remains on the original page and sees whatever content is there, which in a pure redirect setup is typically a blank or minimal page. The percentage of visitors with JavaScript disabled is small, typically under 1%, but non-zero, and for high-traffic sites even a small percentage represents real visitors who hit dead ends.

Script loading failures: if the JavaScript file containing the redirect code fails to load, due to network issues, ad blockers, script errors, or CDN failures, the redirect does not fire. Server-side redirects have no equivalent failure mode, the redirect happens at the server level before any external resources are involved.

Script execution errors: a JavaScript error occurring before the redirect code executes prevents the redirect from firing. In a production environment this is uncommon but possible, particularly in complex JavaScript applications where many scripts interact.

Performance and loading order: if the redirect JavaScript is in an external file or positioned late in the page, it may load slowly, particularly on slow connections or low-powered devices. The visitor may see a partially rendered page for a noticeable duration before the redirect fires.

JavaScript redirects and HTTPS

JavaScript redirects have no special interaction with HTTPS handling. The redirect fires after the page loads, at which point the connection is already established over whatever protocol the original URL uses. A JavaScript redirect from an HTTP page to an HTTPS destination requires the browser to make a separate HTTPS request to the destination, but the JavaScript itself does not handle SSL termination or certificate validation.

For HTTP to HTTPS redirects, one of the most important redirect use cases, a JavaScript redirect is a particularly poor choice. The HTTP page loads before the redirect fires, meaning the initial connection is unsecured. Any content loaded with the HTTP page, images, scripts, stylesheets, is loaded insecurely. A server-side redirect handles HTTP to HTTPS at the connection level before any content is delivered, ensuring the entire session is secure from the first request.

When JavaScript redirects are legitimate

Despite the disadvantages, there are specific scenarios where JavaScript redirects are the appropriate or unavoidable tool.

No server access: on hosting environments with no server-side redirect configuration, simple HTML hosts, certain static platforms, basic shared hosting, JavaScript is sometimes the only available redirect mechanism. A JavaScript redirect is better than no redirect at all, though migrating to proper hosting is the correct long-term solution.

Conditional client-side logic: redirecting based on conditions that are only known in the browser, user authentication state stored in local storage or cookies, browser feature detection, client-side A/B test assignments, time zone or locale, requires client-side logic. The server cannot know these conditions without a round trip, and some cannot be communicated to the server at all. JavaScript is the appropriate layer for these decisions.

Single-page application routing: SPAs handle navigation through JavaScript and the browser History API. Within a SPA, navigating from one route to another involves JavaScript updating the URL; this is the expected architecture for SPA routing rather than a redirect workaround. For direct URL requests and initial page loads, server-side rendering or static generation with proper server-side redirects should still handle SEO-critical URL changes.

Post-authentication and post-action flows: redirecting after a client-side authentication flow completes, checking a JWT in local storage, verifying a session cookie, completing an OAuth callback, is a legitimate JavaScript redirect use case. The destination depends on client-side state that the server may not have at request time.

Progressive enhancement: a page that implements both a server-side redirect and a JavaScript redirect as redundancy: the server-side redirect handles most cases, the JavaScript fires for edge cases where the server redirect did not catch the request. This is unusual but occasionally relevant in complex infrastructure.

Replacing JavaScript redirects with server-side redirects

Wherever a JavaScript redirect exists for a use case that does not genuinely require client-side logic, replacing it with a server-side redirect is straightforward and always worth doing.

Identify the source URL: the page containing the JavaScript redirect. Identify the destination, the URL being navigated to in the JavaScript code. Determine the appropriate HTTP status code: 301 for permanent moves, 302 for temporary. Configure the redirect at the server layer: .htaccess, Nginx config, CDN rule, or redirect management platform. Remove the JavaScript redirect code from the source page. Verify using browser developer tools that the URL now returns a 3xx status code rather than a 200.

For JavaScript redirects embedded in complex application code, post-login flows, SPA routing, the replacement requires more careful consideration of the application architecture. In these cases the JavaScript redirect is often legitimate and the goal is not to remove it but to ensure server-side redirects also exist for the SEO-critical paths that crawlers and direct link visitors use.

Identifying JavaScript redirects

JavaScript redirects can be identified through several approaches.

Browser developer tools: a URL that returns a 200 OK in the Network tab but causes the browser to navigate to a different URL is likely using a client-side redirect, either JavaScript or meta refresh. Viewing the page source and searching for window.location or location.replace confirms a JavaScript redirect.

Disabling JavaScript: loading the URL with JavaScript disabled in the browser prevents JavaScript redirects from firing. If the page loads normally with JavaScript disabled but redirects with it enabled, the redirect is JavaScript-based.

curl: curl -I https://example.com/page returns only the server response headers. A JavaScript redirect returns a 200 OK with no Location header; the redirect instruction is in the page body, not the server response. A server-side redirect returns a 3xx status code and Location header immediately.