TL;DR
JavaScript-based redirects don’t pass PageRank reliably because Googlebot processes them differently than server-side 301 redirects. When your SPA or JavaScript framework redirects users via window.location or router.push, Google may see the original page content, not follow the redirect, and link equity stays trapped on a page that actually redirects everyone away. After months of waiting for rankings to consolidate, you discover Google never received the redirect signal.
The Conversation
Marcus, frontend developer at a B2B SaaS startup, React SPA with client-side routing, intermediate SEO knowledge, merged two products six months ago but rankings haven’t consolidated: We merged two products into one about six months ago. Old product pages redirect to the new combined product page. But rankings still haven’t consolidated. The old URLs rank separately, sometimes competing with the new page for the same queries. Our marketing team is frustrated because we expected the backlink value to transfer.
SDC SEO Brain: Six months is long enough that something is fundamentally broken in how Google is processing these redirects. How exactly are the redirects implemented? Server-side 301s or JavaScript redirects?
Marcus: JavaScript. Our React router checks if you hit an old product URL and redirects to the new one using history.push. We also have a useEffect hook that fires window.location for some legacy paths.
SDC SEO Brain: That’s your problem. Both of those are client-side redirects that happen after the page loads and JavaScript executes. Googlebot loads your page, sees whatever content renders initially, and may not wait for or follow the JavaScript redirect. From Google’s perspective, both pages exist independently with their own content.
Marcus: But the redirect works perfectly. Users get sent to the right place within milliseconds.
SDC SEO Brain: Users wait for JavaScript to execute in their browsers. Googlebot’s rendering process is fundamentally different. It captures page state at specific moments during its rendering pipeline and may not track navigation changes the way a user’s browser does over time. The redirect happens in the browser environment, but Google’s crawler might not register it as an HTTP redirect relationship.
Marcus: I don’t understand. Google renders JavaScript now. They’ve been doing it for years.
SDC SEO Brain: Google renders JavaScript to see content, not to follow every possible navigation path. When Googlebot requests your old URL, it gets your HTML, executes JavaScript, and takes snapshots of what renders. If your initial render shows old product content before the redirect fires, that’s what Google indexes. Even if the redirect happens, Google might not interpret it as a canonical redirect signal the way it interprets a 301.
Marcus: So Google thinks both pages have different content?
SDC SEO Brain: Either Google sees both pages as independent entities with their own content, or Google sees the old page content and doesn’t realize a redirect is happening at all. Either way, the fundamental problem is the same: link equity isn’t consolidating. Backlinks pointing to your old URLs aren’t being credited to your new URL because Google doesn’t see a redirect relationship between them.
Marcus: We have some valuable backlinks to the old product pages. Those are just sitting there doing nothing?
SDC SEO Brain: Worse than nothing. They’re supporting rankings for pages that redirect users away immediately. The old pages might rank, users click, get redirected, but the ranking value stays attributed to URLs that functionally don’t exist for users anymore.
Marcus: How do we fix this?
SDC SEO Brain: Implement server-side redirects. When a request comes to your old URL, the server returns a 301 status code pointing to the new URL before any HTML is rendered. Googlebot receives the redirect instruction immediately in the HTTP response headers and follows it. This is how redirects pass PageRank, through HTTP-level redirect signals.
Marcus: We’re a serverless SPA deployed on Vercel. There’s no traditional server processing requests. Everything routes to our single-page app.
SDC SEO Brain: Serverless doesn’t mean you can’t control HTTP responses. On Vercel, you configure redirects in vercel.json. Those redirects execute at Vercel’s edge network before your SPA even loads. Same concept works on Netlify with redirects file or netlify.toml, Cloudflare Pages with redirects, or AWS CloudFront with Lambda@Edge.
Marcus: So I’d add redirect rules to vercel.json and the SPA never loads for old URLs?
SDC SEO Brain: Exactly. The redirect happens at the infrastructure level. The browser makes a request, receives a 301 response with Location header pointing to the new URL, and immediately requests the new URL. Your React app loads on the new URL. The client-side router never has to handle the redirect because it already happened before any JavaScript executed.
Marcus: I have maybe 40 old URLs that need redirects. Is that manageable in a config file?
SDC SEO Brain: 40 is fine. Vercel.json supports pattern matching too, so if your old URLs follow a structure like /old-product/feature-name, you can write one redirect rule with a wildcard instead of 40 individual rules. Check Vercel’s documentation for redirect syntax with path parameters.
Marcus: What about our internal links? Our blog posts and help docs still link to old URLs in some places.
SDC SEO Brain: Those create redirect chains now. User clicks internal link, hits 301, loads new page. That works but adds latency and the redirect chain slightly dilutes the link equity transfer. Update internal links to point directly to new URLs. Don’t rely on redirects for internal navigation.
Marcus: Our content team uses a CMS. Updating all those links manually would take forever.
SDC SEO Brain: Run a search-and-replace in your CMS database or use your CMS’s built-in link management if it has one. Many CMSs have plugins for bulk link updates. This is a one-time cleanup that prevents ongoing redirect chain overhead.
Marcus: How do I verify the redirect is actually server-side now?
SDC SEO Brain: Use curl from command line. Run curl -I followed by your old URL. The -I flag shows response headers only. You should see HTTP/1.1 301 Moved Permanently with a Location header pointing to your new URL. If you see HTTP/1.1 200 OK, the redirect isn’t happening at the server level and your SPA is loading instead.
Marcus: What if I see a 308 instead of 301?
SDC SEO Brain: 308 is fine. It’s the permanent redirect equivalent that preserves the HTTP method. For SEO purposes, 301 and 308 are functionally equivalent for passing PageRank. Avoid 302 and 307, which are temporary redirects that don’t pass full link equity.
Marcus: After I implement server redirects, how long until Google recognizes them and consolidates rankings?
SDC SEO Brain: Google needs to recrawl the old URLs, receive the 301 response, and update its understanding of the redirect relationship. For a site your size, expect a few weeks for Google to process the redirects, then another few weeks to months for rankings to consolidate as Google reevaluates the link equity distribution. You’ve had these as separate pages for six months, so there’s accumulated confusion to unwind.
Marcus: Should I keep the JavaScript redirects as backup after implementing server-side?
SDC SEO Brain: You can remove them. Server-side redirects catch requests before JavaScript runs. The JavaScript redirect would only trigger if someone somehow bypassed the server redirect, which shouldn’t happen in normal flow. Removing the JavaScript redirect simplifies your code and eliminates the possibility of conflicting redirect behaviors.
Marcus: Our SEO tool still shows the old URLs as having backlinks. Will that update?
SDC SEO Brain: Third-party SEO tools have their own crawling schedules. They’ll eventually see the 301s and update their data, but this can take weeks or months. The important thing is that Google sees the redirects. Use Search Console to verify how Google is handling your URLs. The URL Inspection tool will show if Google is following the redirect.
FAQ
Q: Why don’t JavaScript redirects pass PageRank?
A: JavaScript redirects happen after page load, in the browser environment. Googlebot may not track browser navigation changes the same way users experience them. Server-side 301s communicate redirect relationships in HTTP response headers before any page content loads, which Google definitively processes as a redirect signal for link equity transfer.
Q: Can Googlebot follow JavaScript redirects at all?
A: Sometimes, but unreliably. Google’s rendering can detect some JavaScript navigations, but this isn’t guaranteed and shouldn’t be relied upon for SEO-critical redirects. The redirect might be detected or it might not, depending on timing, render budget, and other factors Google doesn’t disclose.
Q: How do I implement server-side redirects for a serverless SPA?
A: Use your hosting platform’s redirect configuration. Vercel uses vercel.json, Netlify uses redirects or netlify.toml, Cloudflare Pages uses redirects. These execute at the edge before your SPA loads and return proper HTTP redirect responses.
Q: What’s the difference between 301, 302, 307, and 308 redirects for SEO?
A: 301 and 308 are permanent redirects that pass full link equity. 302 and 307 are temporary redirects that historically haven’t passed link equity reliably. Google has said they now treat all redirects similarly, but using 301 or 308 for permanent moves is still best practice.
Q: How long until rankings consolidate after fixing redirects?
A: Expect several weeks for Google to recrawl and process the redirects, then additional weeks to months for rankings to fully consolidate. The longer the pages existed as separate entities, the longer consolidation typically takes.
Summary
JavaScript redirects via client-side routing don’t reliably communicate redirect relationships to Google. Googlebot may see original page content rather than following the navigation, leaving link equity trapped on pages that redirect users away.
Server-side 301 redirects send redirect instructions in HTTP response headers before any page content loads. Google definitively processes these as redirect signals and passes PageRank to the destination URL.
Serverless SPAs can implement server-side redirects through hosting platform configuration files. Vercel, Netlify, Cloudflare Pages, and similar platforms all support redirect rules that execute at the edge before your application loads.
After implementing server redirects, update internal links to point directly to new URLs. Redirect chains add latency and can slightly dilute the link equity transfer.
Verify with curl that your redirects return HTTP 301 or 308 status codes. HTTP 200 responses mean the redirect is still happening in JavaScript, not at the server level, and Google likely isn’t receiving the redirect signal.
Sources
- Google Search Central: Redirects and SEO
- Google Search Central: JavaScript SEO basics
- Vercel Documentation: Redirects configuration
- HTTP Specification: 301 and 308 status codes