The lazy take on JavaScript redirects is that Google “handles them now,” so it doesn’t matter which method you use. That’s half true and dangerously incomplete. Google can render and follow a client-side redirect — but “can follow, eventually, on a delay you don’t control” is a very different promise than a server returning a clean 301 before a single byte of HTML ships. The gap between those two behaviors is where link equity leaks, migrations stall, and rankings slip for reasons that never show up in a redirect audit that only checks whether the final URL loads.
This guide is the version I’d give a client mid-migration: how the mechanism actually works, the specific decision rule for when client-side redirects are acceptable, a worked example of the failure mode, and the honest cases where they’re genuinely the right tool.
How a JavaScript redirect actually works
A client-side redirect runs in the browser after the page has already loaded. There is no redirect in the HTTP response — the server returns a normal 200 OK with a real HTML document, and only once the JavaScript executes does the browser navigate elsewhere. The three common methods are not interchangeable:
window.location.replace('/new-url')— swaps the current entry so Back doesn’t return to the redirecting page. This is the closest analog to a server redirect and the one to prefer if you must do this client-side.window.location.href = '/new-url'(or.assign()) — navigates but leaves the old URL in history, so the user’s Back button bounces them straight back into the redirect. That creates a trap loop.window.location = '/new-url'— the terse form, behaves likehref.
The distinction matters because search engines and users experience these differently. replace() signals “this page was never a real destination”; href signals “here’s a second page you can go back to.” If you’re going to redirect client-side at all, use replace().
Why Google follows them — but slowly, and on its own schedule
Googlebot indexes in two waves. The first wave reads the raw HTML your server returns. Because the redirect lives in a script rather than the response header or the initial markup, that first pass sees a normal page, not a redirect. The redirect is only discovered in the second wave, when the URL reaches the Web Rendering Service and Chromium actually executes the JavaScript. That render step is queued, and the queue is not instant — for most sites it’s hours, but for large or low-priority sites it can stretch to days.
So the accurate mental model is: a server-side 301 is understood the instant Google fetches the URL, while a client-side redirect is understood only after a rendering pass that happens whenever Google gets around to it. On a five-page site that delay is invisible. On a 40,000-URL migration, you’ve just added a rendering-queue bottleneck to every single redirected page, and the consolidation of signals to the new URLs drags out across weeks instead of days. This is why rank tracking matters during a move: SEO Rocket’s top-100 rank tracking shows you whether the new URLs are actually gaining positions or stalling in the render queue, which a single-day spot check would hide entirely.
The default rule: server-side beats client-side almost every time
Here’s the decision rule I actually use. Ask one question: do you control the server or CDN response for the old URL?
- Yes → use a server-side 301 (permanent) or 302 (temporary). Full stop. This is the answer for the overwhelming majority of redirects: retiring a page, changing a URL structure, moving to HTTPS, consolidating duplicates.
- No, but you control the edge → use a CDN/edge redirect rule (Cloudflare Rules, a Vercel/Netlify redirect config, an Nginx or Apache directive). Still server-side from Google’s perspective — the redirect is in the HTTP response.
- No server or edge control at all → only then does a client-side redirect become the pragmatic fallback, and you accept the trade-offs knowingly.
The reason server-side wins isn’t dogma. A 301 in the response header transfers ranking signals cleanly and immediately, works for every crawler and bot regardless of whether it runs JavaScript, and costs the user zero rendering time. A client-side redirect gives up all three of those advantages to buy convenience.
A worked example: the backlink that stopped counting
Say you move /old-guide to /new-guide, and /old-guide has 12 referring domains pointing at it — the exact links that got it ranking. You implement the move with window.location.href in a script on the old page.
A human clicking one of those backlinks lands on /old-guide, waits for the page to load, then gets bounced to /new-guide. Fine. But many of the tools that evaluate those links don’t execute JavaScript: some link crawlers, several social preview fetchers, and Google’s own first-wave pass all see /old-guide as a live 200 page with content, not as a redirect. Until the render queue catches the redirect, Google may treat the link equity as still belonging to the old URL — or, worse, see two near-identical live pages and pick the wrong canonical. The new page’s rankings underperform for weeks, and the “audit” passes because a browser check confirms the redirect fires. A single server-side 301 would have transferred those 12 links the moment Google refetched the URL.
Redirect chains and loops: the crawl-budget tax
Client-side redirects are especially prone to becoming chains because they’re often bolted on by different teams over time — a client-side redirect points at a URL that itself has a server 301, which points at a canonical, which has a trailing-slash rewrite. Every hop adds latency for users and dilutes signal for crawlers, and Google will stop following long chains before it reaches the destination. Worse, using location.href instead of replace() can create a genuine loop when the destination conditionally sends the user back. Keep every redirect to a single hop, point the old URL directly at the final canonical, and never mix client-side and server-side redirects on the same path.
The hidden costs users and analytics pay
Because a client-side redirect requires the page to load before it fires, the user pays for a full render they’ll never see. On a slow connection that’s a visible flash of the wrong page and a hit to Largest Contentful Paint and Cumulative Layout Shift — two of the Core Web Vitals Google measures. Analytics take collateral damage too: the intermediate URL frequently fires its own pageview before the redirect executes, inflating session counts and corrupting attribution so you can’t tell which entry points actually convert. Server-side redirects have none of these side effects because the browser never renders the intermediate page at all.
Meta refresh is the worst of both worlds
A <meta http-equiv="refresh" content="0;url=/new"> tag is the client-side cousin people reach for when they can’t run scripts. Google does sometimes treat an instant (0-second) meta refresh as roughly equivalent to a 301, but “sometimes” is the problem — it’s ambiguous by design, slower than a header redirect, and any non-zero delay is explicitly discouraged in Google’s own guidance because it degrades the user experience. If you’re already editing the page’s HTML to add a meta refresh, you almost always have enough access to configure a real redirect instead. Treat meta refresh as a last resort below even a scripted redirect.
Where JavaScript redirects are genuinely the right call
They’re not always wrong. There are real cases where client-side is the only honest option or the correct one:
- Post-authentication routing — sending a logged-in user to a dashboard after a form submit is application logic, not an SEO redirect, and belongs in JavaScript.
- Single-page apps — client-side routing within a SPA is expected; just make sure indexable URL changes are backed by real, crawlable routes.
- Personalization you never want indexed — routing based on cart state, session, or A/B bucket where the target shouldn’t accrue ranking signals anyway.
- Hosted platforms with zero server access — some site builders genuinely don’t expose redirect rules, making a
replace()the only lever you have.
The common thread: client-side redirects are fine when the redirect is about the user’s journey, not about consolidating search equity. The moment link equity or indexing is on the line, move it server-side.
The geo, device, and hreflang trap
Auto-redirecting visitors by detected country, language, or device with JavaScript is one of the most common ways sites accidentally hide content from Google. Googlebot crawls predominantly from US IPs and doesn’t set the locale you might key off, so a client-side geo-redirect can shunt the crawler into the wrong regional version — or a loop — and leave your other locales uncrawled. The correct pattern is to let all versions be independently crawlable, connect them with hreflang annotations, and offer users a suggestion banner to switch regions rather than a forced client-side redirect. Forced locale redirects and hreflang are fundamentally at odds.
How to audit the JavaScript redirects on your site
A redirect audit that only confirms “the final page loads in my browser” will miss every problem above, because your browser runs JavaScript and Google’s first pass doesn’t. Audit the way a crawler sees it:
- Fetch old URLs without executing JavaScript and check the raw HTTP status — anything returning 200 where you expected a redirect is a client-side redirect masquerading as a live page.
- Trace every redirect to its destination and flag any path with more than one hop.
- Cross-check that redirected old URLs aren’t still indexed alongside their targets in Search Console’s coverage report.
This is exactly the kind of check a real crawler catches and a spot-check misses. SEO Rocket’s site audit runs an actual crawler over your site — not a JavaScript-rendered browser view — so client-side redirects, redirect chains, and orphaned old URLs surface as issues instead of hiding behind a redirect that “works when I click it.” It’s the difference between auditing what users see and auditing what Google’s first indexing wave sees.
Frequently asked questions
Do JavaScript redirects pass link equity like a 301?
Eventually and imperfectly. Once Google renders the page and follows a replace()-style redirect, it generally consolidates signals, but the transfer is delayed by the render queue and invisible to non-rendering crawlers in the meantime. A server-side 301 passes equity immediately and universally, which is why it’s the default for anything link-related.
Are JavaScript redirects bad for SEO?
Not inherently — they’re a worse tool for the specific job of consolidating search signals, and a perfectly fine tool for user-journey routing. The problem is using them as a substitute for a 301 when you actually have server or edge access to do the redirect properly.
Is a 301 or 302 better when I switch to server-side?
Use 301 for permanent moves — retiring a URL for good, a migration, an HTTPS switch — so Google transfers signals to the new URL. Use 302 only when the move is genuinely temporary and you want the original URL to keep its ranking. Picking 302 for a permanent move slows consolidation.
How long until Google processes a client-side redirect?
It depends on your site’s render-queue priority — hours for small, frequently crawled sites, potentially days for large or lower-priority ones. There’s no fixed SLA, which is precisely why you shouldn’t rely on the timing for anything that affects revenue, like a migration.
The bottom line
JavaScript redirects aren’t forbidden and they aren’t a trick — they’re a fallback that trades immediacy, universality, and clean analytics for the convenience of not touching the server. The rule is simple: if you control the response, redirect server-side with a 301 and move on; reserve client-side redirects for user-journey routing and the genuine cases where you have no other lever. The playbook I’ve run across 1,000,000+ ranking pages treats redirects as plumbing you get right once — clean, single-hop, and server-side wherever equity is on the line — so you’re never debugging a ranking dip that a header would have prevented.
