JavaScript redirects and crawling
A JavaScript redirect changes the location in script (for example via window.location) and only executes after the page is fetched and rendered. Google can follow JavaScript redirects once it renders the page, but its guidance is to prefer server-side HTTP redirects because they are processed immediately and unambiguously. JavaScript redirects add latency and depend on successful rendering.
What this means
A JavaScript redirect navigates the browser to a new URL using script, commonly by assigning to window.location. Unlike an HTTP redirect carried in response headers, it only fires after the page is downloaded and the script executes.
Google renders pages and can therefore follow JavaScript redirects, but only as part of the rendering pass, which happens after the initial fetch. That makes the redirect later and less certain than a server-side 301/302 that is delivered before any HTML.
Why server-side is preferred
Google's documentation lists redirect types in order of preference: server-side HTTP redirects are clearest, meta refresh is acceptable, and JavaScript redirects are a fallback when the others are not possible. The reason is processing certainty and speed — an HTTP redirect needs no rendering.
JavaScript redirects also fail if the script does not run: a rendering error, a CSP that blocks the script, or a timeout can leave the crawler on the original URL. For permanent moves especially, a 301 consolidates signals far more reliably.
- JavaScript redirects fire only after rendering, not at the HTTP layer
- Google can follow them but prefers server-side HTTP redirects
- They fail if the script is blocked or rendering errors out
- For permanent moves, a 301 is the reliable choice
Diagnosing and replacing
If a JavaScript redirect is being honoured inconsistently, check whether the page renders cleanly for crawlers using the URL Inspection live test, and whether CSP or a script error prevents the redirect from running.
Where you control the server, replace JavaScript redirects with HTTP redirects. Reserve JavaScript redirects for cases driven by client state that the server cannot know, and ensure the target is reachable and indexable.
How it appears in analytics and logs
A JavaScript redirect only resolves after a crawler renders the page, so it is processed later than an HTTP redirect and depends on the script running successfully. Google can follow it but treats it as a weaker, slower routing signal.
Diagnostic use case
Diagnose why a JavaScript-based redirect is being picked up slowly or inconsistently, and decide when to migrate it to a server-side HTTP redirect for reliable crawl behavior.
What WebmasterID can help detect
WebmasterID records crawler requests to source and destination URLs server-side, so you can confirm whether crawlers actually rendered the page and followed the JavaScript redirect to the target.
Common mistakes
- Using a JavaScript redirect for a permanent move where a 301 would consolidate signals reliably.
- Not accounting for CSP or script errors that prevent the redirect from running.
- Assuming crawlers process JavaScript redirects as fast as HTTP redirects.
- Chaining a JavaScript redirect through additional client-side hops.
Privacy and accuracy notes
JavaScript redirect detection inspects your page logic, not visitors. WebmasterID treats it as a crawl-routing topic and never ties redirect logic to visitor identity.
Related pages
- Meta refresh redirects and crawlers
A meta refresh redirect uses an HTML meta tag to send the browser to another URL after a delay. Google can follow meta refreshes, but its guidance is to prefer server-side HTTP redirects (301/302) because they are clearer, faster, and unambiguous. An instant (zero-delay) meta refresh is treated more like a redirect, while a delayed one is weaker and can confuse users and crawlers.
- Redirect best practices for crawlers
Good redirects keep crawlers and link equity flowing to the right destination. The essentials: use 301 or 308 for permanent moves and 302 or 307 only for genuinely temporary ones, redirect each old URL directly to its final target in a single hop, map to the closest equivalent page rather than dumping everything on the homepage, and avoid loops. These choices preserve indexing signals and conserve crawl budget.
- JavaScript rendering and crawling
Content injected by JavaScript is not in the initial HTML, so a crawler must render the page to see it. Rendering is more expensive than fetching HTML, and not all crawlers render. Server-side rendering (SSR) or prerendering puts content in the HTML directly, reducing dependence on the crawler's render step.
- Website observability
Confirm crawlers rendered the page and followed the redirect target.
Sources and verification notes
- Google Search Central — Redirects and Google SearchJavaScript redirects supported as a fallback; HTTP redirects preferred.
- MDN — Window: location property
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.