A JavaScript redirect is a redirect performed by a script in the visitor’s browser: the page starts to load, a line of code such as window.location.replace() runs, and the browser is sent to a different address. Unlike a server redirect, the original page has to be downloaded and its code run before anything happens.
How a JavaScript redirect works
With a server redirect such as a 301, the server answers the request for the old URL with a status code and the new address, and never sends the old page at all. Every browser, search engine and link checker understands that instantly.
A JavaScript redirect works differently. The server returns the old page with a normal 200 status, as if everything were fine. Only when the browser runs the script does the visitor get moved on. Google can follow these, because it renders pages and runs their scripts, but that rendering step can happen after the initial crawl, so the redirect may be noticed later. Google’s own guidance is to use a JavaScript redirect only when a server-side or meta refresh redirect is not possible.
Many other crawlers do not run JavaScript at all. Some search engines, link-checking tools, social media preview bots and several crawlers used by AI tools fetch the raw HTML only. To them, the old URL is just a page, often an empty one, with no instruction to go anywhere.
Why it matters
Redirects exist to carry visitors and search value from an old address to a new one. A JavaScript redirect does this less reliably and more slowly. If it is the only redirect in a site move, some signals may take longer to consolidate, and tools that do not render will report the old URLs as live, thin pages.
They also slow visitors down. The browser downloads the old page, its scripts and sometimes its tracking before moving on, which adds a noticeable delay on mobile connections.
JavaScript redirects tend to appear on UK sites in a few predictable places: website builders that only let you add custom code to the page, single-page apps that route visitors after a login check, consent or country selectors that bounce people to another version, and old campaign landing pages someone “switched off” with a script rather than a proper rule.
Common mistakes
- Using JavaScript when the server could do it. Most hosts, CMSs and CDNs offer proper 301 rules; check before reaching for a script.
- Chaining script redirects with server ones. A server redirect to a page that then redirects by script creates a slow redirect chain that is hard to spot.
- Redirecting based on location or device. Sending visitors elsewhere by IP or screen size can hide content from Googlebot and confuse people who want the original page.
- Leaving the old page indexable. Because the old URL returns 200 with real content, it may stay in the index alongside the new one.
How to act on it
Crawl your site twice, once with JavaScript rendering off and once with it on, and compare. URLs that only redirect in the rendered crawl are using script redirects. Replace each with a server-side 301 where your platform allows it, and point internal links straight at the final URL.
If you genuinely cannot set server rules, use window.location.replace() as early in the page head as possible, add a canonical tag pointing at the destination, and include a plain link to the new page for anyone whose browser does not run the script. When redirects form part of a site move or rebuild, I plan and test them as part of website migration SEO.