JavaScript Redirects
What a JavaScript redirect is, how Google's render pipeline treats it differently from a server-side 301, when it's an acceptable last resort, and how to implement and detect one — plus where meta refresh and the History API fit.
1 evidence signal on this page
- Related live toolrobots.txt Tester
A JavaScript redirect sends users and crawlers to a new URL with client-side code (window.location.replace() or .href). It's the least reliable redirect type because Google only sees it after rendering — which can be delayed, or fail entirely, with no fixed timeline either way. Google's official order of preference is server-side (301/302/307/308) → meta refresh → JavaScript, and its docs say plainly: only use JS redirects if you can't do the other two. Once Google successfully interprets one, the target becomes a canonicalization signal — but that's not a proven guarantee of identical PageRank or ranking outcomes to a 301, so treat it as a last resort rather than a like-for-like swap. Use them on constrained platforms with no server access, for SPA error pages that point to a real 404, and little else. If you must use one, use window.location.replace() in the <head>, drop the source URL from your sitemap, and point internal links at the final destination. Meta refresh is a separate HTML-level redirect, and history.pushState()/replaceState() aren't redirects at all.
TL;DR — A JavaScript redirect uses code in the page to send you to a different URL after the page loads. It works for people, but search engines handle it less reliably than a “real” server redirect (a 301). If you can set up a 301 instead, do that. Save JavaScript redirects for when you have no other option.
What a JavaScript redirect is
A JavaScript redirect changes navigation through script execution rather than an HTTP 3xx response. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: JavaScript redirects Google can process JavaScript redirects but recommends server-side redirects when possible. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: Redirects and Search
There are two broad ways to send someone from one URL to another.
The first is a server-side redirect. Before the page even loads, the server says “that page moved — go here instead” using a status code like 301 (permanent) or 302 (temporary). The browser and the search engine both get that message immediately.
The second is a JavaScript redirect. The page loads normally, and then a bit of code runs in the browser and sends you somewhere else. Something like:
<script>
window.location.replace("https://example.com/new-page/");
</script>For a person clicking around, the two feel almost the same. For a search engine, they’re very different — and that difference is the whole reason this page exists.
Why search engines treat them differently
Google reads your page in stages. First it crawls (downloads the raw HTML). Later it renders the page — actually running the JavaScript, the way a browser would. A server-side 301 is visible in that first step. A JavaScript redirect isn’t visible until the rendering step, which can come much later — or, sometimes, not at all.
Google says it directly: “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects.” (Google Search Central)
So a JavaScript redirect isn’t bad — it’s just less reliable. Google will usually get there eventually, but a real 301 is faster and more certain.
The simple rule
- Can you set a 301 (or 302)? Do that. It’s the gold standard.
- Can’t touch the server, but can edit the HTML
<head>? A 0-second meta refresh is the next-best option. - Neither? Then a JavaScript redirect is a fine last resort.
A couple of things people get wrong:
- A meta refresh is not a JavaScript redirect. It’s a
<meta>tag in your HTML, and Google handles it earlier and more reliably than JS. history.pushState()is not a redirect. It just changes what’s in the address bar — it doesn’t send anyone anywhere, and search engines don’t follow it.
Want the render-pipeline timing, the implementation details, and how to find JS redirects in a crawl? Switch to the Advanced tab.
TL;DR — A JavaScript redirect is a client-side redirect (
window.location.replace(),.href,.assign()) that Google only processes after rendering — phase three of crawl → render → index. A server-side 301 is seen at crawl time; a JS redirect waits on the render queue, and Google gives no fixed timeline for that wait — it can be quick or it can take a long while, and rendering can fail outright. Google’s documented preference order is server-side → meta refresh → JavaScript, and the docs say to use JS redirects only when you can’t do the other two. Once Google successfully interprets one, the target becomes a permanent canonicalization signal — even Google used them on their own blog when nothing else worked — but that’s not documented proof of identical PageRank or ranking outcomes to a 301, so they’re a last resort, not a spam signal. The legitimate uses are constrained platforms with no server config and SPA error pages that point at a real 404. Implement withwindow.location.replace()in the<head>, drop the source from your sitemap, repoint internal links, and confirm Googlebot can fetch the JS. Meta refresh is HTML-level (0s = permanent, any delay = temporary), andhistory.pushState()/replaceState()aren’t redirects at all.
What counts as a JavaScript redirect
Script navigation depends on rendering and execution, so it is not protocol-equivalent to an HTTP redirect. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: JavaScript redirects Processing is possible, not an exact-timing or indexing guarantee. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: Redirects and Search
A JavaScript redirect navigates the browser to a new URL with client-side code. The common methods, and how they differ:
window.location.replace("url")— navigates and removes the original URL from session history. This is the one to use: the back button skips the redirect source instead of bouncing the user straight back.window.location.href = "url"— navigates but keeps the original in history, so the back button returns to the redirecting page (and can create a loop).document.location.hrefandwindow.location.assign("url")behave the same way.history.pushState()/history.replaceState()— not redirects. They rewrite the address bar without any navigation or HTTP signal, so crawlers don’t treat them as redirects. SPAs use them for in-app URL changes; they need real<a href>links (or actual navigations) to be crawlable.
The dividing line that matters: .replace(), .href, and .assign() all trigger
a real document navigation (the difference between them is only what happens to
session history), while pushState()/replaceState() never navigate at all —
they touch history state and the address bar and nothing else. None of the four is
an HTTP 301; “redirect” here is shorthand for client-side navigation, not a status
code.
Meta refresh (<meta http-equiv="refresh" content="0;url=...">) is often
lumped in with JS redirects, but it’s an HTML directive parsed before JavaScript
runs — a separate, more reliable category, covered below.
How Google processes a JavaScript redirect
This is the crux. Google’s pipeline runs in stages, and a JS redirect and a server-side redirect get caught at different ones:
- Crawl — Googlebot fetches the URL and reads the raw HTML. A server-side 301/302/307/308 is seen right here.
- Render queue — pages that return
200wait to be rendered. Google’s docs note the page “may stay on this queue for a few seconds, but it can take longer than that.” Google doesn’t publish a fixed service-level timeline beyond that, so treat the wait as unpredictable — it can be quick, or it can drag — rather than assuming any specific number of days or weeks. - Render + index — headless Chromium runs the JavaScript. This is the first moment a JS redirect exists as far as Google is concerned.
The same idea I make on Crawling and in JavaScript SEO applies here: rendering is a separate step from fetching, and anything that depends on it inherits that delay and that risk.
And the risk is real. Google: “While Google attempts to render every URL Googlebot crawled, rendering may fail for various reasons. This means that if you set a JavaScript redirect, Google might never see it if rendering of the content failed.” (Google Search Central) During the window before the redirect is processed — and forever, if rendering fails — Google may keep the empty source page in its index.
Google’s official preference order
The redirects documentation lays out a hierarchy from most to least reliable:
- Server-side redirects — 301/308 (permanent), 302/307 (temporary). Best for everything: seen at crawl time, unambiguous.
- Meta refresh — HTML-level. A 0-second meta refresh is treated as a permanent redirect (like a 301); any delayed meta refresh is treated as temporary.
- JavaScript redirects — last resort.
Google’s words: “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects.” Permanent redirects pass the canonical signal to the target; temporary ones keep the original in results. (How that interacts with canonical selection is over on Canonicalization.)
Does link equity pass through?
Google’s own redirects documentation lists JavaScript location navigation among its permanent redirection methods, and says the target becomes the canonicalization signal once Google has interpreted it — so the flat “JS redirects don’t pass PageRank” claim is false. What the documentation doesn’t establish is that the outcome is identical, immediate, or as reliable as a server-side 301 — it describes the canonical signal, not a guarantee of matching PageRank flow, ranking, or timing. The honest framing: a 301 passes the signal at crawl time with near-certainty; a JS redirect passes it only if and when rendering succeeds, and Google doesn’t promise the result will match a 301’s outcome one-for-one. That gap — not lost equity — is the real cost of choosing JavaScript.
This is also why JS redirects aren’t a penalty trigger on their own. They only become a spam problem when they’re used for cloaking — showing crawlers one page and redirecting users to something different, or sending mobile users to an unrelated domain. Google’s sneaky redirects policy is about that intent, not the technique.
When a JavaScript redirect is the right tool
There are legitimate cases:
- Constrained platforms. Some shared hosting, CDN, or CMS setups give you no access to server-side redirect rules. A JS redirect is a valid fallback — and notably, Google used JS redirects on their own Webmaster blog because, as Gary Illyes put it, “that was the only thing we could use for 1:1 redirects, and it works on Google” (OnCrawl).
- SPA error handling. Google explicitly endorses this: “Use a JavaScript
redirect to a URL for which the server responds with a
404HTTP status code.” (Google Search Central) A single-page app that resolves a bad route can redirect to a real 404 endpoint so Google processes the error correctly instead of indexing a soft 404.
For permanent URL migrations, this is not the tool — use a 301. I make the same point in site migrations: JavaScript redirects are a last resort, and Google may never see them.
Static site generators: the Hugo aliases trap
A common surprise: Hugo’s aliases: frontmatter has historically generated
meta refresh HTML pages, not server-side 301s — and other static generators
have done similar things by default. Generator defaults change between versions,
so check your current deployed version’s actual output rather than assuming; if
aliases: isn’t giving you 301s, you need platform-level redirect rules (Netlify
_redirects, Cloudflare Workers, Vercel vercel.json) plus (on Hugo)
disableAliases: true. I cover this in detail in
Hugo SEO.
Implementation best practices
If a JavaScript redirect is genuinely your only option:
- Use
window.location.replace(), not.href. As Search Engine Journal puts it, JS redirects “typically usewindow.location.replace()function rather thanwindow.location.hrefto avoid UX redirect loops” (SEJ). - Put it in the
<head>, not the<body>. Browsers parse HTML sequentially and run scripts as they hit them, so “position JavaScript redirects in the<head>tag rather than<body>to minimize delay” (OnCrawl). - Redirect to the final destination in one hop. A JS redirect to a page that itself 301s elsewhere makes a chain; chains waste crawl budget and can surface in GSC as a redirect error.
- Remove the source URL from your XML sitemap. Sitemaps should list canonical, indexable URLs — not redirecting ones.
- Repoint internal links at the destination, so they don’t route through the redirect at all.
- Make sure Googlebot can fetch the JS. If the redirect lives in an external
script blocked by
robots.txt, Google can’t render it and won’t see the redirect.
How to detect JavaScript redirects
They don’t announce themselves like a 301 in a header, so you have to render:
- A crawler with JS rendering on. OnCrawl recommends crawling with
“JavaScript rendering enabled (5-second timeout minimum)”; Screaming Frog and
Ahrefs Site Audit can both render. Without rendering, a JS-redirecting page just
looks like a normal
200. - Chrome DevTools. The Network tab (with “Preserve log”) shows the client-side navigation; the Redirect Path extension flags it too.
- In Search Console, a successfully processed JS redirect shows up under Page with redirect — the same status as any redirected URL, which is normal for non-canonical sources. That label isn’t guaranteed on any given check, though: it reflects whatever Google fetched, rendered, interpreted, and canonicalized at the sampled moment, so a URL can show a different status (or no redirect status yet) between checks without that being an error on your end.
What I’d actually do
Server-side first, every time. Meta refresh (0-second) when you can edit HTML but
not server config. JavaScript only when both are off the table — and then with
window.location.replace() in the <head>, a clean sitemap, and a check that the
redirect actually renders for Googlebot. For anything permanent or high-value, the
extra reliability of a 301 is worth almost any effort to obtain.
AI summary
A condensed take on the Advanced version:
- A JavaScript redirect is client-side (
window.location.replace(),.href,.assign()). It’s only processed after rendering — phase three of crawl → render → index — whereas a server-side 301 is seen at crawl time. - The render queue is the risk: a page “may stay on this queue for a few seconds, but it can take longer,” with no fixed service-level timeline, and rendering can fail entirely, in which case Google may never see the redirect and keeps the source page indexed.
- Google’s preference order: server-side (301/302/307/308) → meta refresh → JavaScript. Docs: “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects.”
- The target becomes a canonicalization signal once Google interprets a JS redirect — so the “JS redirects don’t pass PageRank” myth is false — but Google doesn’t document that the outcome matches a server-side redirect’s PageRank flow, ranking, or timing exactly. JS redirects aren’t a penalty trigger unless used for cloaking (sneaky redirects).
- Legitimate uses: constrained platforms (Google itself used them on their blog), and SPA error pages that redirect to a real 404 (Google-endorsed).
- Meta refresh ≠ JS redirect: it’s HTML-level; 0s = permanent, any delay =
temporary.
history.pushState()/replaceState()aren’t redirects — no HTTP signal, crawlers don’t follow them. - Hugo
aliases:are meta refresh, not 301s — a common trap on static generators. - Implementation:
window.location.replace()in the<head>, single hop to the destination, remove source from sitemap, repoint internal links, ensure Googlebot can fetch the JS. - Detection: crawl with JS rendering on, Chrome DevTools / Redirect Path, “Page with redirect” in GSC.
Official documentation
Primary-source guidance on redirects and JavaScript.
- Redirects and Google Search — the preference hierarchy (server-side → meta refresh → JavaScript), permanent vs. temporary handling, and the meta refresh delay rules.
- JavaScript SEO Basics — the render pipeline and the endorsed SPA-404 redirect use case.
- Fix search-related JavaScript problems — soft 404s, rendering, and debugging JS that Google can’t process.
- Sneaky redirects (spam policies) — when a redirect crosses into cloaking and becomes a policy violation.
Bing / Microsoft
- Bing Webmaster Help — entry point for Bing’s current guidance. (At the time of writing, Bing had no dedicated redirects help page at a stable URL; Bingbot renders JavaScript less reliably than Googlebot, which makes JS-only redirects riskier for Bing indexation.)
Quotes from the source
On-the-record statements from Google and the people who work on Search. Each Google-docs link is a deep link that jumps to the quoted passage.
Google — the preference order and the rendering risk
- “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects.” — Google Search Central docs. Jump to quote
- “While Google attempts to render every URL Googlebot crawled, rendering may fail for various reasons. This means that if you set a JavaScript redirect, Google might never see it if rendering of the content failed.” — Google Search Central docs. Jump to quote
Google — the endorsed SPA use case
- “Use a JavaScript redirect to a URL for which the server responds with a
404HTTP status code (for example/not-found).” — Google Search Central docs. Jump to quote
Gary Illyes, Google
- On JS redirects generally: “Js redirects are probably not a good idea though.” (July 8, 2020)
- On Google using them anyway when nothing else worked: “We used JS redirects on webmasters.googleblog.com because that was the only thing we could use for 1:1 redirects, and it works on Google.” Coverage
Search Engine Journal — implementation and link equity
- “JavaScript redirects typically use
window.location.replace()function rather thanwindow.location.hrefto avoid UX redirect loops.” Read - “JavaScript redirects are not SEO-friendly and should be avoided when alternatives exist… Only implement JavaScript redirects when server-side alternatives are genuinely unavailable.” Read
Redirect types — cheat sheet
When Google sees it, and how it’s treated
| Method | When Google sees it | Treated as | Reliability |
|---|---|---|---|
Server-side 301 / 308 | Crawl time | Permanent | Highest |
Server-side 302 / 307 | Crawl time | Temporary | Highest |
Meta refresh, 0 seconds | HTML parse time | Permanent | High |
Meta refresh, delayed (>0s) | HTML parse time | Temporary | High |
| JavaScript redirect | After rendering | Follows the navigation | Lowest |
history.pushState() / replaceState() | — | Not a redirect | n/a |
JavaScript redirect methods
| Code | History behavior | Use it? |
|---|---|---|
window.location.replace("url") | Removes source from history | Yes — recommended |
window.location.href = "url" | Keeps source (back-button loop) | Avoid for redirects |
window.location.assign("url") | Same as .href | Avoid for redirects |
document.location.href = "url" | Alias for .href | Avoid for redirects |
Fast facts
- Google’s order: server-side → meta refresh → JavaScript. Use JS only when the first two are impossible.
- Once interpreted, a JS redirect’s target is a canonicalization signal — the “JS redirects don’t pass PageRank” myth is false. Google doesn’t document that outcome as identical to a 301’s, so the real risk is delay / render failure, not a documented PageRank penalty.
- JS redirects are not a penalty unless used for cloaking.
- Hugo
aliases:= meta refresh, not 301. - A processed JS redirect appears as “Page with redirect” in GSC.
Should I use a JavaScript redirect? — decision checklist
Walk this top to bottom; stop at the first “yes.”
- Can I set a server-side
301/302/307/308? → Do that. Stop here. - Can I edit the HTML
<head>but not server config? → Use a 0-second meta refresh for permanent moves. Stop here. - Neither is possible (locked-down platform), or it’s a SPA error page that should hit a real 404? → A JavaScript redirect is acceptable. Continue.
If you’re using a JavaScript redirect
- Use
window.location.replace()(not.href/.assign()). - Place the script in the
<head>, as early as possible. - Redirect straight to the final destination — no chain through another redirect.
- Remove the source URL from your XML sitemap.
- Repoint internal links to the destination.
- Confirm the redirect’s JS is not blocked in
robots.txtso Googlebot can render it. - You are not showing crawlers one page and redirecting users elsewhere (cloaking).
- Verify by crawling with JS rendering on and checking “Page with redirect” in GSC.
The recommended JavaScript redirect
Put this in the <head> so it executes as early as possible in parse order:
<head>
<script>
window.location.replace("https://example.com/new-page/");
</script>
</head>replace() is the key choice — it drops the redirecting URL from session history,
so the back button doesn’t bounce the user straight back into the redirect.
The 0-second meta refresh (next-best when you can’t do server-side)
Not JavaScript, but the right fallback when you can edit HTML and not server config. A 0-second delay is treated by Google as a permanent redirect:
<head>
<meta http-equiv="refresh" content="0; url=https://example.com/new-page/">
</head>What NOT to use as a redirect
history.pushState() rewrites the address bar but performs no navigation and
sends no HTTP signal — crawlers won’t follow it:
// NOT a redirect — only changes the URL bar, no navigation happens
history.pushState({}, "", "/new-page/");If you need an SPA route change to be crawlable, give it a real <a href> link or
a genuine navigation, not just a History API call.
SPA error page → real 404 (Google-endorsed pattern)
When a single-page app resolves an unknown route, send it to an endpoint that
returns an actual 404 so Google processes the error instead of a soft 404:
// On an unresolved route in your SPA:
window.location.href = "/not-found"; // /not-found must return HTTP 404Patrick's relevant free tools
- Raw vs. Rendered HTML Checker — See what's in your page's initial HTML versus after JavaScript runs — headless-Chrome rendering only when the page actually needs it, a rendering-strategy verdict (SSR / prerendered / CSR / hybrid), ~15 calibrated JavaScript-SEO checks (noindex, canonicals, robots.txt blocking, links, soft 404s), a side-by-side raw-vs-rendered diff, and shareable reports.
- HTTP Status & Redirect Checker — Paste up to 500 URLs — status codes, full redirect chains, final destinations, per-hop and total latency, response-header evidence, canonical checks, and redirect-system clues. Filter, compare snapshots, and export CSV. No signup, nothing stored.
- robots.txt Tester — Test pages against bots with a matcher ported from Google's open-source robots.txt parser — a blocked/allowed matrix with the exact winning rule per cell, file lint, sitemap-conflict detection, a diff mode for proposed changes, and a separate live robots.txt fetch for each entered origin.
Tools for finding and checking JavaScript redirects
- Screaming Frog SEO Spider — enable JavaScript rendering (with a sufficient
rendering timeout) so JS-redirecting pages don’t just look like plain
200s. - Ahrefs Site Audit — renders pages and surfaces redirects, chains, and redirected internal links.
- Chrome DevTools — Network tab — turn on “Preserve log” and watch the client-side navigation fire.
- Redirect Path (Chrome extension) — flags client-side redirects alongside server-side ones in a quick popup.
- Google Search Console — URL Inspection — see how a single URL was crawled and rendered, and whether Google landed on “Page with redirect.”
- GSC — Page indexing report — “Page with redirect” lists redirected URLs; “Redirect error” surfaces chains and loops.
Mistakes to avoid with JavaScript redirects
- Using
window.location.href(or.assign()) instead of.replace()..hrefkeeps the redirecting page in session history, so the back button bounces the user straight back into the redirect — a loop. Do instead: usewindow.location.replace(), which drops the source from history. - Reaching for a JS redirect on a permanent, high-value migration when a 301 is available. JS redirects are only processed after rendering, which can be delayed or fail outright — the wrong risk to take on a page that matters. Do instead: use a server-side 301; save JavaScript for constrained platforms and SPA error pages.
- Chaining the JS redirect into another redirect instead of landing on the final destination in one hop. Chains waste crawl budget and can surface as a redirect error in GSC. Do instead: point the JS redirect straight at the destination URL.
- Leaving the source URL in the XML sitemap. Sitemaps should list canonical, indexable URLs, not redirecting ones. Do instead: remove the source from the sitemap once the redirect is live.
- Letting
robots.txtblock the script that fires the redirect. If Googlebot can’t fetch the JS, it can’t render the redirect, and the source page can sit indexed indefinitely. Do instead: confirm the script is crawlable — the robots.txt tester checks exactly this. - Assuming Hugo’s
aliases:frontmatter gives you a 301. It has historically generated a meta refresh HTML page, not a server-side redirect — verify your deployed version’s actual output rather than assuming. Do instead: use platform-level redirect rules (Netlify_redirects, Cloudflare Workers, Vercelvercel.json) plusdisableAliases: true, as covered in Hugo SEO. - Treating
history.pushState()/replaceState()as a redirect. They only rewrite the address bar — no navigation, no HTTP signal, and crawlers don’t follow them. Do instead: use a real<a href>link or an actual navigation for anything that needs to be crawlable. - Showing crawlers one page and sending users somewhere else (cloaking). This is what turns a legitimate JS redirect into a sneaky redirects policy violation — it’s about intent, not the technique. Do instead: send everyone, bots included, to the same destination.
Common issues with JavaScript redirects
The source URL stays indexed long after the redirect went live
- Likely cause: the page is still sitting in Google’s render queue, or rendering failed outright.
- Fix + check: run a Live Test in Google Search Console’s URL
Inspection tool on the source URL. If it hasn’t rendered yet, wait — Google
gives no fixed timeline for the render queue, so recheck periodically rather
than assuming a specific window. If rendering keeps failing, confirm the
redirect script isn’t blocked (see the
robots.txtissue below).
The back button returns straight to the redirecting page
- Likely cause: the redirect uses
window.location.hrefor.assign()instead of.replace(), so the source URL stays in session history. - Fix + check: switch the script to
window.location.replace(). Confirm by landing on the destination and pressing back — it should skip the redirect source entirely.
GSC shows “Crawled – currently not indexed” instead of “Page with redirect”
- Likely cause: Google hasn’t rendered the page yet, or rendering is failing for that URL.
- Fix + check: crawl the URL with a JS-rendering crawler (Screaming Frog or
Ahrefs Site Audit, rendering enabled) to confirm the redirect actually fires
client-side. Also check that the redirect script isn’t blocked in
robots.txt— the robots.txt tester confirms whether Googlebot can fetch it.
An unresolved SPA route shows up as a soft 404 in GSC
- Likely cause: the route redirects somewhere, but the destination doesn’t
actually return an HTTP
404status. - Fix + check: point the redirect at an endpoint that genuinely responds
with
404(Google’s endorsed pattern), then re-run URL Inspection to see the status change from soft 404 to a clean 404.
A JS-redirecting page still looks like a plain 200 in a crawl report
- Likely cause: the crawler ran without JavaScript rendering enabled, so it only saw the initial HTML response, not the client-side navigation.
- Fix + check: re-crawl with JS rendering turned on (a 5-second timeout minimum is a reasonable starting point) and confirm the redirect now shows up.
Proving the redirect actually took effect
| Test to run | Expected result | Failure interpretation | Monitoring window | Rollback trigger |
|---|---|---|---|---|
| robots.txt tester on the redirect script’s URL | Script is Allowed for Googlebot | Disallowed — Google can’t fetch the script, so it can never render the redirect | Immediate | Fix or remove the blocking robots.txt rule before relying on the redirect |
| Crawl the source URL with JS rendering enabled (Screaming Frog / Ahrefs Site Audit) | Crawler reports a client-side navigation to the intended destination | Page still reports a plain 200 with no navigation — rendering isn’t firing | Immediate (single crawl) | If it still doesn’t fire after fixing robots.txt, use a 0-second meta refresh or server-side redirect instead |
| GSC URL Inspection — Live Test on the source URL | Rendered result shows the redirect executing to the destination | Rendering fails, or the rendered HTML shows no navigation | Immediate for the live test itself | If Live Test repeatedly fails to render, treat this platform as unable to support a JS redirect — get server access or use meta refresh |
| GSC — Page indexing report for the source URL | Source URL is listed under “Page with redirect” | Still shows as indexed, “Crawled – currently not indexed,” or duplicate content | 2–4 weeks (indexing status updates on Google’s own schedule) | If still not classified as a redirect after 4+ weeks, revisit the render-blocking checks above |
| Manual back-button check in a browser after landing on the destination | Back button skips the source page entirely | Back button returns to the source page | Immediate | Switch the script from .href/.assign() to window.location.replace() |
Test yourself: JavaScript Redirects
Five quick questions on how JavaScript redirects work and when to use them. Pick an answer for each, then check.
Resources worth your time
My related writing
- JavaScript SEO Issues & Best Practices — the rendering side, which is why JS redirects carry their timing risk.
- The Beginner’s Guide to Technical SEO — where redirects and rendering fit in the bigger picture.
My speaking
- How Search Works (SlideShare) — my walkthrough of crawling, rendering, indexing, and ranking — the pipeline that makes a JS redirect a phase-three event. (My standing disclaimer applies: “This is my understanding of systems… not going to be 100% complete or accurate.”)
From around the industry
- Redirects and Google Search (Google Search Central) — the official preference hierarchy and permanent-vs-temporary handling.
- Sneaky redirects (Google Search Central) — the spam-policy line that separates a legitimate redirect from cloaking.
- JavaScript Redirects & SEO: When & How To Use Them (Search Engine Journal) — practical implementation guidance and the
replace()vs.hrefdistinction. - Are JavaScript Redirects SEO-Friendly? (Search Engine Journal) — the “avoid when alternatives exist” summary.
- JavaScript Redirects and SEO: The Ultimate Guide (OnCrawl) — head-placement guidance, detection tooling, and the full Gary Illyes quote.
- Are JavaScript Redirects Bad for SEO? (Conductor) — a concise FAQ-style answer for the informational query.
- A Guide to Redirect Types (Lumar) — broader redirect taxonomy with JS redirects in context.
JavaScript Redirect
A JavaScript redirect is a client-side redirect that uses code like window.location.replace() to send a visitor (and crawler) to a different URL. Because it only fires after the page is downloaded and rendered, Google prefers server-side and meta refresh redirects above it.
Related: Rendering, Canonicalization
JavaScript Redirect
A JavaScript redirect sends a user (and a search engine crawler) to a different URL using client-side JavaScript — most commonly window.location.replace() or window.location.href. Unlike a server-side redirect, which is communicated through an HTTP status code (301, 302, 307, 308) before any content is sent, a JavaScript redirect only fires after the browser has downloaded the HTML, parsed it, and executed the script.
That timing is the whole story for SEO. A server-side 301 is seen by Googlebot at crawl time; a JavaScript redirect isn’t processed until the page is rendered, which can happen seconds, hours, or longer after the crawl — and rendering isn’t guaranteed. Google’s own guidance is explicit: “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects.”
When Google does successfully render and process a JavaScript redirect, the target becomes a canonicalization signal, the same as a permanent server-side redirect — so the “JS redirects don’t pass PageRank” claim is false. Google doesn’t document that the resulting PageRank flow, ranking, or timing matches a server-side redirect exactly, though; the documented problem is the uncertainty of whether and when rendering succeeds, not a proven loss of equity — and other crawlers (notably Bingbot) render JavaScript less reliably than Google.
A meta refresh (<meta http-equiv="refresh">) is a separate, HTML-level redirect processed at parse time, not a JavaScript redirect; a 0-second meta refresh is treated as permanent, any delay as temporary. And history.pushState() / replaceState() are not redirects at all — they rewrite the address bar without issuing any HTTP signal, so crawlers don’t follow them.
Related: Rendering, Canonicalization
Build-time retrieval analysis plus live signals for this exact article. The automatic chunk report includes a deterministic readiness score and is ready without a model download.
Search Console
sampleGA4 traffic (28d)
sampleCloudflare traffic (7d)
sampledCrUX field data (28d, phone)
sampleGoogle NLP entities
localChangelog
Updated Jul 18, 2026.
Editorial summary and recorded change details.Summary
Walked back an unproven PageRank/ranking-parity claim to what Google actually documents (a canonicalization signal, not identical outcomes to a 301), removed a fixed 'seconds to weeks' render-queue timing claim Google doesn't publish, added a caveat that the GSC 'Page with redirect' label reflects a sampled state rather than a guarantee, softened a blanket claim about Hugo's aliases behavior to account for version drift, and added an explicit navigation-vs-history-state distinction for the JS redirect method table.
Change details
-
Does link equity pass through? now cites the verified canonicalization-signal claim instead of asserting PageRank flows 'comparably' to a server-side redirect; mirrored into the ai-summary, cheat-sheets, and both TLDRs.
-
Removed the unsupported 'anywhere from seconds to weeks for low-priority URLs' render-queue timing claim; Google documents no fixed timeline.
-
Added a caveat that the GSC 'Page with redirect' label reflects the sampled fetch/render/canonicalization state, not a permanent guarantee.
-
Softened the Hugo aliases claim from a blanket 'generates meta refresh' statement to account for version-to-version drift.
Full comparison unavailable — no prior snapshot was archived for this revision.