JavaScript redirect: the server says 200, the JS sends elsewhere

In brief

The page responds 200 with content but its JavaScript redirects the browser elsewhere: Google only follows it after rendering (delayed, or never) and AI systems read the original HTML, not the destination. Replace it with a real 301/302 server-side redirect, or render the final content directly.

WarningP1 — Direct ranking

What is it?

The page responds 200 with content, but its JavaScript redirects the browser to another URL.

Why it hurts SEO and AI

The server signals no redirect (no 3xx): to the HTTP fetch and to AI systems, this page is normal content — which they read and may index or cite — while humans get sent elsewhere. Google can follow a JavaScript redirect, but only after rendering the page, in a delayed second wave: it may index the wrong page in the meantime, and never sees the redirect if rendering fails. AI systems, which read the raw HTML, do not follow it at all. A JavaScript redirect is therefore an ambiguous, fragile signal, often inherited from an SPA router or a forgotten `window.location`.

When it is NOT a problem

  • A redirect triggered by a user action (form, login) on a page not meant for indexing.
  • A purely internal app page (dashboard, account area) outside the indexing scope.
  • The target is the localized version of the same page (language redirect), not a content change.
Before
<!-- /promo responds 200 but -->
<script>window.location.href = '/shop'</script>
After
GET /promo
-> HTTP/1.1 301 Moved Permanently
Location: https://site.com/shop

A real server-side redirect is seen immediately by Google and AI systems; the JavaScript window.location is seen late, or never.

How to fix it

  1. Compare the raw HTML (200) with the browser render: does the page load content before a script sends it elsewhere?
  2. Locate the JavaScript redirect (SPA router, window.location, delayed meta refresh).
  3. Replace it with a server-side 301 (permanent) or 302 (temporary) redirect, or serve the final content directly on the requested URL.
  4. Re-crawl to confirm the server returns the right status, with no leftover JavaScript redirect.

This scan checks the HTTP status, noindex and canonical of every page

Is this issue on your site?

Does one of your pages redirect in JavaScript without telling the server? Enter a URL: Seogard compares the raw HTML (200) with the real render and spots redirects only the browser runs. Free, no credit card.

By clicking Scan, I certify that I own this site or have permission to crawl it.

  • No credit card
  • Result in ~30 s

What you get back

Machines and humans see the same page: no more indexing of the wrong URL, no more AI systems reading content that does not match the destination.

Seogard catches this regression automatically — through its monitoring for your metas and canonicals.

Frequently asked questions

Does Google follow JavaScript redirects?

Yes, but only after rendering the page, in a delayed second wave: it may index the wrong page in the meantime, and never sees the redirect if rendering fails.

Do AI systems follow a JavaScript redirect?

No: ChatGPT, Perplexity and the like read the raw HTML and barely run it; they see the original page, not the destination.

Related rules

Page redirectedA page still declared in your sitemap has started redirecting to another URL: the sitemap presents an address that bounces as canonical. Intentional removal — take it out of the sitemap; otherwise, often a broken route. A page that is redirected AND removed from the sitemap is a clean removal: no alert. Broken redirectA cleanly removed page (redirect + removed from the sitemap) now returns a 4xx error: its redirect broke. Link equity from backlinks pointing to the old URL is no longer passed — typically a refactor that deleted the redirect rule or its target. Broken SSRThe HTML returned by the server (SSR) is almost empty even though the page works in the browser. Google indexes an empty page.

Updated July 10, 2026