JavaScript redirects: when Google sees them, and not

A JavaScript redirect changes the page's address from a script once the page loads, usually by setting window.location. Google treats it as a permanent redirect, but advises "Only use JavaScript redirects if you can't do server-side or meta refresh redirects", because if rendering fails, "Google might never see it." Of the kinds of redirect, it is least certain.

How a JavaScript redirect works

The server sends an ordinary page with a success status, and a script in that page sends the browser elsewhere. Google's documentation on redirects, last updated on 2026-04-14 and checked on 2026-10-09, describes setting "the location property to the redirect target URL in a script block in the HTML head," and gives this example:

<script>
  window.location.href = "https://www.example.com/newlocation";
</script>

Nothing in the response says "redirect". The status is 200, there is no Location header, and the move exists only for a client that runs the script.

Why Google may not see it

Google reads JavaScript in a separate step from fetching the page. Its documentation says it "interprets and executes JavaScript using the Web Rendering Service once crawling of the URL has completed," and that "rendering may fail for various reasons." The consequence is stated in the same paragraph: "if you set a JavaScript redirect, Google might never see it if rendering of the content failed."

Its guide to JavaScript SEO, last updated on 2026-03-04, describes the same split: Googlebot queues pages "for both crawling and rendering," and it is "not immediately obvious when a page is waiting for crawling and when it is waiting for rendering." A server redirect is understood at the first step; a JavaScript redirect waits for the second.

When Google does see it, it reads it as permanent: the redirects documentation lists "JavaScript location" among the permanent methods, after server redirects and instant meta refresh.

When a JavaScript redirect is the right tool

It is right when the decision can only be made in the browser, or when nothing earlier in the chain can be changed.

• Client-side routing. A single-page application that decides in the browser that an address no longer exists.
• Errors in client-rendered pages. Google's JavaScript SEO guide suggests, to avoid soft 404s, "Use a JavaScript redirect to a URL for which the server responds with a 404 HTTP status code (for example /not-found)."
• No access to the server or the HTML head. A hosted page where only scripts can be added.

The guide's own example of the error case:

window.location.href = '/not-found'; // redirect to 404 page on the server.

For a page that has simply moved, none of these applies, and a server redirect is the better answer.

Changing the address is not a redirect

Single-page applications often change the address in the browser's bar without loading anything, through the History API. Google's JavaScript SEO guide recommends exactly that for navigation: "For single-page applications with client-side routing, use the History API to implement routing between different views of your web app."

That is routing, not redirection. The address changes because the user moved within the application, and no old address is being retired. When an address in such an application has genuinely moved or no longer exists, the same guide is frank about the limits: in client-side routing, "using meaningful HTTP status codes can be impossible or impractical." That is the situation in which a JavaScript redirect earns its place, as the example above shows.

Where the application has a server in front of it, the server can still answer old addresses with a proper status code before any script runs. The guide's own reminder applies: "you can use HTTP status codes to tell Googlebot if a page has moved to a new URL." Use that wherever the server knows the answer, and keep script redirects for the cases it does not.

Compared with server and meta refresh redirects

Google ranks the methods by how likely it is to interpret them correctly, and a JavaScript redirect comes after both alternatives: a server-side redirect first, then a meta refresh, then JavaScript. The meta refresh page compares the first two; the difference here is that a JavaScript redirect also needs the script to run.

All three can be read as permanent. Only the server redirect works before anything on the page is loaded, which is why the 301 redirect remains the default for a moved page.

Not every client runs the script

Google renders pages; not every crawler or tool does. A client that reads the HTML without executing scripts sees a normal page and no redirect at all. How machines that do not run JavaScript receive pages, and how a site can serve them a finished page instead of an empty shell, is the subject of BotBridge.

Checking a JavaScript redirect

Compare the raw response with the rendered page. The raw response should show 200, the page's HTML and the script; the rendered result should end on the new address. If the move is meant to be permanent and the server can be changed, this check is also the moment to replace the script with a server redirect.

How a trace counts a script redirect as a hop of its own, and why it costs a full page load, is covered under redirect tracing.

FAQ