Add to Preferred Sources
SEO for JavaScript websites means ensuring that Google can read the content your JavaScript creates — not just the near-empty HTML shell that most modern frameworks deliver to crawlers by default. For South African businesses running sites on React, Vue, Angular or Next.js, this is frequently the invisible reason a technically well-built site refuses to rank: search engine optimisation in South Africa depends on Googlebot being able to see what your users see, and with client-side rendering, those two views often differ completely.
The core challenge is timing. Google does not render JavaScript in the same pass it uses to crawl HTML. Pages that rely on JavaScript execution to display content get queued for a separate rendering process that can take days — and for low-authority or newer South African domains, some of that content never makes it into the index reliably at all.
On top of that, Practitioners who have analysed AI crawler traffic report that GPTBot, ClaudeBot and PerplexityBot read only the HTML in the initial server response and do not execute JavaScript — making client-side rendered content invisible to AI-powered search results regardless of your authority. Understanding how to improve crawlability for JavaScript-heavy sites starts with understanding the rendering mechanics that most developers never see in their local environment.
This guide covers the Googlebot rendering process, a practical rendering-mode decision table for South African site owners, the AI crawler visibility gap, and the specific technical fixes you can apply today — whether you are managing a legacy SPA or choosing a framework for a new build.
Quick Answer
SEO for JavaScript websites requires choosing a rendering mode that delivers complete HTML to Google on the first HTTP response. Static site generation (SSG) is the right default for most content — blog posts, product pages, category pages. Server-side rendering (SSR) suits pages where content must be fresh on every request. Client-side rendering (CSR) should be reserved for interactive elements that do not need to appear in search results.
Sites built as pure React, Vue or Angular SPAs without server rendering send an empty HTML shell to Googlebot, face delayed or incomplete indexing, and are invisible to AI search crawlers that never execute JavaScript.
In This Guide
How Googlebot Renders JavaScript
Choosing the Right Rendering Mode
AI Crawlers and the JavaScript Visibility Gap
Core Web Vitals and SA Performance Context
Is Google seeing your JavaScript site correctly?
Send us your URL and we will run a rendering audit — showing you exactly what Googlebot sees versus what your users see, and where the gaps are costing you rankings.
Request a Rendering AuditHow Googlebot Crawls and Renders JavaScript Websites
The JavaScript website pipeline has three phases — crawling, rendering and indexing — and the timing gap between them is where most search visibility problems on JavaScript-built sites originate. Google's own JavaScript SEO guide documents this sequence: Googlebot reads raw HTML in a first pass, queues pages for rendering in a headless Chromium instance, and finally passes the rendered output to the indexer.
Googlebot first checks robots.txt and crawls the page, reading whatever HTML is immediately available. Pages returning a 200 status code are then queued for rendering, where a headless Chromium instance executes JavaScript and builds the full DOM. The rendered version is then passed to the indexer.
The critical word there is "queued." Rendering does not happen immediately. A page crawled today may not have its JavaScript-rendered content indexed for days, and that queue is managed against a finite render budget — Googlebot's computational ceiling for processing JavaScript across your entire site.
Sitebulb's analysis of this rendering queue confirms that JavaScript-dependent content can wait days, sometimes weeks, before being fully rendered and indexed. Pages waiting in the queue often appear in Search Console as "Crawled — currently not indexed" — a status that can mislead teams into assuming a content or link problem when the issue is rendering. Delayed javascript websites indexing is one of the most common undiagnosed causes of under-performance on SA sites built with modern frameworks.
Key Takeaway: Two-Wave Indexing
Google effectively indexes your site in two waves: immediate indexing of raw HTML, and deferred indexing of JavaScript-rendered content. Practitioners describe this as the core challenge in javascript rendering seo: if your entire page content lives in the second wave, you are at the back of a queue — and low-authority domains in competitive SA niches may never clear it reliably.
Pure single-page applications built with React, Vue or Angular without server-side rendering send what practitioners describe as a near-empty HTML shell to Googlebot on the first pass. The shell typically contains the page frame, a script tag pointing to a JavaScript bundle, and very little else. All visible content — headings, body copy, product listings, service descriptions — only exists after the JavaScript executes. For ranking purposes, that content is invisible until rendering completes.
Which Rendering Mode Should You Choose?
The three JavaScript rendering modes carry fundamentally different SEO trade-offs, and the right choice depends on the content type, update frequency, and your site's authority level. Here is how they compare for South African sites:
| Rendering Mode | What Googlebot Receives | Indexing Speed | Best For | SA Context Note |
|---|---|---|---|---|
| SSG (Static Site Generation) | Complete HTML pre-built at deploy time | Fastest — no render queue | Blog posts, product pages, service pages, FAQs | Served from CDN edge; fastest for mobile users on variable SA connections |
| SSR (Server-Side Rendering) | Complete HTML generated on each request | Fast — no render queue | Personalised pages, real-time inventory, live pricing | Higher server cost but full content on first response; good for dynamic catalogues |
| CSR (Client-Side Rendering) | Near-empty HTML shell; content requires JS execution | Slowest — deferred to render queue | Private dashboards, authenticated user areas, interactive tools | Appropriate only when the content does not need to rank or be cited by AI engines |
The practical decision for most South African site owners working on SEO for JavaScript websites is: default to SSG for everything that needs to rank, use SSR for content that must be genuinely dynamic, and limit CSR to authenticated or non-indexable sections. Frameworks like Next.js, Nuxt.js and Astro make this hybrid approach straightforward — you can serve your blog and product pages as static HTML while keeping user-specific features client-side. If your site already runs on a JavaScript framework and pages are not getting indexed, our SEO services for South African businesses include technical checks on rendering and indexing.
What About Dynamic Rendering?
Dynamic rendering detects crawlers and serves pre-rendered HTML to bots while showing the JavaScript version to users. Google's documentation explicitly describes it as "a workaround and not a recommended solution" that "creates additional complexities and resource requirements." It can solve indexation problems in the short term, but SSR or SSG is the cleaner path. If you use dynamic rendering, ensure the content served to crawlers and users is substantially similar — serving completely different content to users and crawlers can be considered cloaking under Google's spam policies.
Key Takeaway: The Hybrid Model
The strongest JavaScript SEO architecture is a hybrid: SSG for static content (which is most of a typical business site), SSR for dynamic pages, and CSR only for interactive UI elements that are not meant to rank. Next.js, Nuxt.js and Astro all support this pattern out of the box.
AI Crawlers and the JavaScript Visibility Gap
Practitioners who have analysed AI crawler traffic report that GPTBot, ClaudeBot and PerplexityBot read only the HTML delivered in the initial server response and do not execute JavaScript — meaning they see the same near-empty shell that Googlebot's first wave sees, with no deferred rendering pass to follow. Unlike Googlebot, which queues JavaScript-dependent pages for a second rendering pass, these AI crawlers do not return.
The implication for South African businesses is direct: if you want your products, services or expertise to appear in AI-generated answers, your content must be in the HTML response that arrives before any JavaScript runs. This is not a future consideration — AI search traffic is already a measurable portion of referral visits for sites that have optimised for it. Sites running pure CSR are systematically excluded from this channel at the architectural level.
<div id="root"></div>The entire page content exists only after JavaScript executes. AI crawlers that skip JS execution index nothing meaningful from this page.
Full HTML with headings, body copy, structured data and canonical URLs in the initial response — before any JavaScript executes. Crawlers can index and potentially cite this content immediately.
Not sure how your JavaScript site appears to crawlers?
Share your site's URL and we will show you a side-by-side comparison of what users see versus what Googlebot and AI crawlers are indexing — no obligation.
Get a Crawler Visibility CheckCore Web Vitals and JavaScript Performance in the South African Context
Core Web Vitals are used by Google's ranking systems, and JavaScript architecture is one of the biggest levers for improving them. This makes the performance dimension of SEO for JavaScript websites particularly important in the South African context, where connections are less uniform than in markets Google's defaults are tuned to.
South Africa's median download speed was 24.0 Mbps in 2026 — below the global median of 33.9 Mbps, ranking 74th out of 119 countries measured (SpeedGEO, 2026). Urban mobile connections from providers like Vodacom average significantly higher, but the real-user field data that feeds Core Web Vitals assessments reflects your slowest visitors as well as your fastest.
Practitioners who analyse web performance find that a JavaScript bundle delivering acceptable load times on fast fibre connections can produce poor Largest Contentful Paint scores for users on slower mobile connections. South Africa's real-user speed mix — with significant variation below the national median — means SA sites are more exposed to this pattern than markets where connections are more uniform.
Load shedding has been largely resolved — South Africa recorded more than 400 consecutive days without outages from mid-May 2025, the longest such run in close to a decade. But the design principles it enforced remain sound: South African site operators who built for mobile-first, low-data-cost delivery during the outage years built faster sites by default, and faster sites rank better. A JavaScript-heavy SPA that requires a 2 MB bundle before a single product image loads is a problem in any connection environment.
Key Takeaway: Bundle Size Matters More Here
Code splitting, lazy-loading non-critical JavaScript, and serving pre-rendered HTML are not just developer best practices — they are South African ranking strategies. Google's Core Web Vitals field data reflects your actual visitors, not your test environment, and SA's real-user speed distribution makes JavaScript bloat a more costly problem than global averages suggest.
SEO for JavaScript Websites: Fixes to Apply Now
The highest-impact fixes for SEO on JavaScript-built South African sites address the configuration gaps that cause Googlebot to misread routing, miss canonical signals, or process incorrect status codes — most of these require one change in your framework setup rather than a full rebuild:
Fix routing to use the History API. Effective seo javascript crawling depends on Googlebot being able to resolve your routes without executing JavaScript. Google recommends client-side routing via the History API rather than hash-fragment URLs. A URL like /products/running-shoes is crawlable; a URL like /#/products/running-shoes is not reliably resolved by Googlebot. React Router, Next.js's Link component, Vue Router and Nuxt's router all output History API-compatible anchor tags by default — the issue arises when developers implement custom routing with fragments.
Set canonical URLs in HTML, not JavaScript. Google's guidance is explicit: canonical URLs should be present in the HTML <head> before JavaScript executes. Setting or overriding canonicals via JavaScript creates a race condition — if rendering is deferred, Googlebot may index a page without the canonical signal it needs, leading to duplicate content problems across paginated or filtered URLs.
Return meaningful HTTP status codes. Single-page applications often return a 200 status code for pages that do not exist, because the router handles 404 logic in the browser. Googlebot sees a 200 and attempts to index the error state. Your server or edge function needs to return actual 404 or 410 status codes for non-existent routes — this is a common technical gap on SPA builds that are later migrated to new frameworks.
Implement structured data in JSON-LD. Google can read JSON-LD structured data injected via JavaScript, but the safer pattern is to include it in the server-rendered HTML. For South African e-commerce sites using product and review schema, this means ensuring your SSR or SSG layer writes the JSON-LD into the initial HTML response rather than injecting it client-side.
Audit with the URL Inspection Tool. Google Search Console's URL Inspection Tool shows you the rendered version of any page as Googlebot sees it. For JavaScript sites, the gap between "page source" and "rendered HTML" reveals exactly which content is missing from the first-pass index.
Run your most important category and product pages through this tool before assuming they are indexed correctly. Searching for a unique phrase from that page in Google with quote marks is a faster initial check — if Google cannot return the page for text that exists only on that URL, it has not been indexed.
If you are on a framework that does not support SSR or SSG natively, consider migrating critical page templates to Next.js (React), Nuxt.js (Vue) or Astro. The website indexation gains from a rendering-mode migration directly address the indexation gap — the architectural bottleneck that limits how much of your content Google can reliably index, regardless of content quality. Running on a technical SEO foundation that serves complete HTML is the baseline — everything else is secondary.
Why South African Businesses Choose Growth Pulse Media
Growth Pulse Media was built by Dirk van Greuning, who scaled a large South African ecommerce operation before founding the agency. That background shapes how we approach technical problems: the goal is not a clean audit report, it is organic traffic that converts.
We have seen the rendering gap cost SA businesses real search visibility while they focused on content and links — and we know how to diagnose and fix it without disrupting an existing production site. Getting SEO for JavaScript websites right requires understanding how rendering decisions interact with crawl budgets, Core Web Vitals and the growing AI crawler ecosystem — not just a checklist pass.
Our SEO work for South African businesses covers the full technical layer — from rendering audits and crawl budget analysis to structured data implementation and framework migration planning. All work is executed in-house, and we deliberately limit our client load so that every account gets senior attention at every stage. If you are not getting the organic visibility your site quality should produce, the rendering architecture is usually the first place to look.
Who This Guide Is NOT For
Running a JavaScript site with unexplained ranking gaps?
Tell us about your current framework and we will give you a plain-language assessment of where the rendering gap is likely sitting and what a fix looks like.
Get a Technical SEO AssessmentFrequently Asked Questions
Can Google index JavaScript websites?
Yes — Google can index JavaScript websites, but the indexing happens in two waves. The first wave indexes whatever HTML is available immediately. The second wave renders JavaScript in a separate queue that can take days. Content that only exists after JavaScript executes may not appear in search results for several days after publication, and for low-authority sites, some JavaScript-rendered content may never be reliably indexed in a given crawl cycle.
Is React bad for SEO?
React itself is not bad for search engine optimisation — the problem is client-side rendering without any server-side layer. A React application built with Next.js using static site generation or server-side rendering delivers complete HTML to Googlebot on the first response and performs as well as any other modern framework. A plain React single-page application without SSR or SSG sends an empty HTML shell and relies entirely on the render queue.
What is the difference between SSR and SSG for SEO?
Server-side rendering (SSR) generates complete HTML on the server for each incoming request, so Googlebot always receives a full page. Static site generation (SSG) builds all pages as complete HTML files at deploy time and serves them from a CDN. For SEO, both deliver full content without requiring Googlebot to execute JavaScript. SSG has a speed advantage because no server computation happens at request time, but SSR is the right choice when page content must reflect real-time data — such as live inventory levels or personalised pricing.
How do I check if my JavaScript site has indexation problems?
Use Google Search Console's URL Inspection Tool on your most important pages. It shows both the crawled page source and the rendered version as Googlebot sees it. If the rendered version shows missing headings, body copy or product information that appears on the live site, your content is in the render queue and may not be indexed reliably. Searching for your page's unique copy in Google with quotes is a faster sanity check — if Google cannot return the page for text that only exists on that URL, it has not been indexed.
Do AI search engines crawl JavaScript websites?
Practitioners who have analysed AI crawler behaviour report that GPTBot, ClaudeBot and PerplexityBot do not execute JavaScript — they read only the HTML present in the initial server response. This means a client-side rendered site is effectively invisible to AI-powered search engines and answer engines, regardless of how well-optimised the content is once the JavaScript executes. For any South African business aiming to appear in AI-generated answers, server-rendered or statically-generated HTML is not optional.
Ready to Fix Your JavaScript Site's Search Visibility?
Growth Pulse Media audits JavaScript rendering setups for South African businesses — showing you exactly what Googlebot and AI crawlers see, where the gaps are, and what the fix looks like in your specific framework. All work is executed in-house with senior attention. No obligation — we will get back to you within 24 hours.
Book a Free Rendering Audit