By Mehdi HassanPlenty of startup marketing sites are built like apps: a React single-page application where the server sends an almost empty HTML shell and JavaScript fills in everything else. For a logged-in product, that's fine. For pages that need to rank in Google and be quoted by ChatGPT or Perplexity, it's a real risk.
This guide explains how different crawlers handle JavaScript, which rendering approach marketing pages should use and how to check what a crawler actually sees. It sits under our technical SEO guide for marketing websites, which covers the other basics.
Can search engines and AI crawlers read JavaScript content?
Google can read most JavaScript-rendered content, but not instantly and not always. Many AI crawlers, including those used by answer engines, generally fetch the HTML and don't execute JavaScript at all. So content that depends on client-side rendering is partly visible to Google and often invisible to AI search.
Crawler type | Runs JavaScript? | What it means for you |
|---|---|---|
Googlebot | Yes, in a later rendering pass | Indexed, but with delay and some failures |
Bingbot | Partly | Don't rely on it for core content |
AI search and training crawlers | Generally no | Raw HTML is all they get |
Social link previews | No | Open Graph tags must be in the HTML |
The practical conclusion is simple. If a sentence matters for search, it needs to be in the HTML the server sends. That includes headlines, body copy, pricing, FAQ answers, internal links and structured data.
How does Google handle JavaScript?
Google processes JavaScript pages in stages: it crawls the HTML, queues the page for rendering in a headless Chrome, then indexes the rendered result. Content in the initial HTML can be processed right away. Content that needs rendering waits in the queue.
Google's documentation on JavaScript SEO describes this crawl, render and index flow, and it's generally reliable for well-built pages. Problems appear at the edges. Scripts that time out, content loaded only after a scroll or click, links built from click handlers instead of anchor tags, and APIs that block Googlebot can all leave the rendered page incomplete. You'll often see these as pages stuck in crawled, currently not indexed in Search Console. Our guide to pages not indexed by Google covers that status.
Why can't AI crawlers see client-side content?
Most AI crawlers skip JavaScript because rendering is expensive. Fetching HTML is cheap and fast. Running a full browser for every page costs far more compute, so crawlers that gather pages for AI search and training generally read the raw response and move on.
For a client-side React app, the raw response is often a div with an id of root and a script tag. To those crawlers, your pricing page has no prices and your guide has no words. That's why answer engines sometimes describe a company using third-party sources instead of its own site. Our deeper guide on server-side rendering for AI crawlers goes into the crawler-by-crawler detail, and answer-first page structure covers what to write once crawlers can read the page.
Hypothetical example: a pricing page only Google can see
For example, suppose a SaaS company's pricing page fetches plan data from an API in the browser and renders the table with React. In the browser it looks perfect.
Googlebot renders it and indexes the prices, a few days after each change. An AI crawler fetching the same URL gets the page shell: the navigation, a heading and an empty container. When someone asks an answer engine how much the product costs, it can't quote the company's own page, so it falls back to an outdated review site.
Moving the plan data into the build, or fetching it on the server, puts the full table in the HTML and fixes both problems.
SSR vs CSR vs SSG: which is best for SEO on marketing pages?
For marketing pages, static site generation is the best default, server-side rendering is right when a page needs fresh per-request data, and client-side rendering should be limited to interactive parts. Both SSG and SSR send complete HTML, so every crawler can read the content.
Approach | How it works | SEO for marketing pages | Best for |
|---|---|---|---|
Static generation (SSG) | HTML built ahead of time and served from a CDN | Excellent | Home, features, blog, pricing |
Incremental or on-demand regeneration | Static pages rebuilt when content changes | Excellent | CMS-driven pages that change often |
Server-side rendering (SSR) | HTML built on each request | Excellent, if fast | Personalized or real-time pages |
Client-side rendering (CSR) | Browser builds the page with JavaScript | Weak and risky | Logged-in app, dashboards |
Hybrid | Server HTML plus client components | Excellent when copy is server-rendered | Most modern marketing sites |
Webflow and Framer publish static HTML, so the main risk there is content loaded by embeds. In Next.js, the App Router renders on the server by default, but a stray client-side data fetch can still move content out of the HTML. Our guide to static vs server rendering in Next.js explains how to choose per route, and the Next.js SEO checklist covers metadata and sitemaps.
How do you check what a crawler sees on your page?
Check what crawlers see by looking at the raw HTML response and at Google's rendered view. If your key content is in the raw HTML, every crawler gets it. If it only appears in the rendered view, only Google does.
View the page source
Open view-source in your browser, not the element inspector. Search for a sentence from the middle of the page and for your main heading.
Fetch with JavaScript off
Disable JavaScript in your browser's developer settings and reload. What remains is roughly what a non-rendering crawler gets.
Use a command-line fetch
Request the URL with curl or a similar tool and check the response for your copy, links and JSON-LD.
Run URL Inspection
In Search Console, inspect the URL and view the crawled page's HTML and screenshot to confirm Google's rendered version is complete.
Crawl with rendering on and off
Run a site crawler twice and compare word counts and links per page. Big differences show where JavaScript is doing the work.
What JavaScript SEO mistakes are common on marketing sites?
The most common JavaScript SEO mistakes are content fetched in the browser, links that aren't real anchor tags and metadata set by client scripts. Each one hides something from at least some crawlers, and each is easy to miss because the page looks fine in a browser.
- Client-side data fetching for copy, pricing, testimonials or blog content.
- Click-handler navigation instead of anchor tags with href values, which crawlers can't follow.
- Titles, canonicals and schema set by JavaScript after load, so the initial HTML disagrees with the rendered page.
- Tabs and accordions that load content on click rather than hiding content that's already in the HTML.
- Infinite scroll on blog indexes with no paginated URLs for crawlers to follow. Give crawlers paginated URLs with real links as well.
- Blocking script or API URLs in robots.txt, which stops Google rendering the page properly.
How do you fix a marketing site built as a single-page app?
Fix a single-page-app marketing site by moving the public pages onto a framework that renders HTML on the server or at build time, while the logged-in product stays as it is. You don't need to rewrite the app, only separate the marketing pages from it.
The usual path is to rebuild the marketing pages in Next.js or a site builder, serve them on the main domain and keep the app on a subdomain or a separate path. URLs often change in the process, so treat it as a migration and build a redirect map first. Our guide to moving a React SPA to an SEO-friendly site walks through that separation step by step, and our guide to running Webflow and Framer on the same domain covers the subdomain and reverse-proxy options.
