Single-Page Apps and SEO: Why Your AI-Built App Might Be Invisible to Google
How client-side rendering affects search visibility, and what to check if your AI-generated app isn't showing up in search results.
A lot of AI app builders generate single-page applications — a single HTML shell that loads JavaScript, which then renders everything client-side. This is fine for an internal tool or a logged-in dashboard, where search visibility doesn't matter. It's a real problem for marketing pages, landing pages, or anything you want to show up in search results.
Here's how Google handles JavaScript-rendered pages, what tends to go wrong, and what changes when you move to a framework built around server rendering.
How Google Crawls JavaScript-Rendered Pages
Google can render JavaScript, but it happens in a separate, delayed step from the initial crawl — pages are first crawled for their raw HTML, queued for rendering, and then rendered later to see the final content. This means a JS-rendered page can take significantly longer to be fully indexed than a page that's already complete HTML on the first request, and any errors in the render step can cause it to be skipped entirely.
What Breaks in a Client-Side-Rendered App
The most common issues: the initial HTML is essentially empty (just a script tag), so anything that depends on the rendering step succeeding is at risk; every route shares the same title and meta description because there's no per-route metadata generation; and content takes longer to become visible, which affects both crawlability and Core Web Vitals.
- Empty or near-empty initial HTML — content only appears after JavaScript runs
- Identical title/description across all routes
- No per-page structured data (FAQ, breadcrumbs, etc.)
- Slower perceived load time, affecting Core Web Vitals
How Server Rendering Fixes This
Next.js's App Router renders pages on the server (or at build time, for static pages) — so the initial HTML response already contains the actual content, with per-page metadata generated via generateMetadata and, for dynamic routes, generateStaticParams to pre-render every page. This is the same pattern used throughout this site's /hire, /locations, and /guides sections — each page has its own title, description, and structured data, pre-rendered as static HTML.
Migrating from a CSR SPA to Next.js
The good news is that most of the actual logic — components, state management, styling, business logic — carries over conceptually, since both are React. What changes is routing (file-based instead of a client-side router) and data fetching (server-side or static instead of client-only). For a marketing site or landing pages specifically, this is often a contained piece of work rather than a full rebuild of the whole app.
Frequently Asked Questions
Our app was built with Lovable or a similar tool — is it definitely invisible to Google?
Not necessarily invisible, but likely disadvantaged — Google can still attempt to render and index it, just slower and less reliably than a server-rendered equivalent. The practical impact depends on how much you need organic search to work for that app specifically.
Do we need to migrate the entire app, or just the public-facing pages?
Usually just the public-facing marketing/landing pages need to be crawlable — a logged-in dashboard or app interior doesn't need to rank in search, so it can often stay as-is.
How can we check if this is actually affecting our site?
Search Console's URL Inspection tool shows you the rendered HTML Google sees for a given page — if it's empty or missing your main content, that's a direct sign of this issue.
Related Reading
Not sure if your app's marketing pages are crawlable?
We can check what Google actually sees on your key pages, and scope a fix — often just for the public-facing routes, not the whole app.
See AI App Rescue