Jan-Willem Bobbink

Posted on Feb 1

Why Lovable.dev sites struggle with search engine and LLM indexing

#architecture #javascript #llm #react

Lovable.dev's pure client-side rendering architecture creates significant SEO challenges because search engines receive only an empty HTML shell when crawling these React applications. Google takes approximately 9x longer to index JavaScript-heavy pages compared to static HTML, and other search engines—including AI crawlers—often cannot render the content at all. The platform itself acknowledges these limitations, noting that indexing can take "days instead of hours" and that social media previews are broken by default.

This problem isn't unique to Lovable.dev—it affects most single-page applications (SPAs) built with React, Vue, or Angular that rely on client-side JavaScript to render content. The solutions range from implementing server-side rendering to using prerendering services, with SEO experts like Jan-Willem Bobbink consistently recommending SSR as the safest approach for SEO-critical sites.

Lovable.dev's technical architecture creates an empty-shell problem

Lovable.dev generates React applications using a modern but SEO-problematic stack: React with TypeScript, Vite for builds, Tailwind CSS with shadcn/ui components, and React Router for client-side navigation. The platform exclusively produces client-side rendered (CSR) single-page applications with no built-in server-side rendering options.

When a search engine crawler visits a Lovable.dev site, it receives HTML that looks essentially like this:

<html>
<head><title>Loading...</title></head>
<body>
  <div id="root"></div>
  <script src="/bundle.js"></script>
</body>
</html>

All meaningful content—text, images, navigation, metadata—exists only after JavaScript executes in the browser. Lovable's own documentation acknowledges this limitation: "Platforms like Facebook, X/Twitter, and LinkedIn do not wait for content to render, so they only see the initial HTML page structure."

The platform offers workarounds but no native fix. Users can export their code to GitHub and deploy elsewhere, use prerendering services like Prerender.io or LovableHTML ($9+/month), or migrate entirely to Next.js—though this breaks Lovable's visual editor functionality.

Google's two-wave indexing creates multi-day delays

Google processes JavaScript websites through a three-phase pipeline: crawling, rendering, and indexing. When Googlebot first visits a CSR page, it captures the raw HTML immediately but places the page in a rendering queue for JavaScript execution. Google's Tom Greenaway confirmed at Google I/O that "the final render can actually arrive several days later."

This creates what researchers call "flaky indexing." The same page might appear differently on different crawl attempts. Some pages get fully indexed while others remain partially indexed or show errors like "Crawled – currently not indexed" in Search Console. A study by Onely demonstrated that Google takes up to 9 times longer to properly render JavaScript pages than static HTML.

The crawl and render budget problem

Search engines allocate finite computational resources for JavaScript execution. Sites that exceed their rendering budget experience up to 40% lower indexation rates and 23% decreased organic traffic. Heavy JavaScript bundles—particularly common in React applications—can cause Google to abandon rendering entirely before completion.

Each JavaScript file competes for crawl budget allocation. Framework files (React, Redux), third-party scripts (analytics, ads), and component libraries all require HTTP requests and processing time. Failed rendering attempts waste budget without producing successful indexing.

Beyond Google: other crawlers struggle more

While Googlebot uses an evergreen Chromium browser for rendering, other crawlers have more limited capabilities:

Crawler	JavaScript Support	Implication
Googlebot	Full (with delays)	Content eventually indexed
Bingbot	Limited	Microsoft recommends dynamic rendering
DuckDuckBot	Minimal	Requires static content
AI Crawlers (GPTBot, ClaudeBot)	None	Completely miss CSR content
Social Media Bots	None	Broken link previews

Bing's official documentation explicitly states: "In order to increase the predictability of crawling and indexing by Bing, we recommend dynamic rendering as a great alternative for websites relying heavily on JavaScript." Tests by Screaming Frog found that Angular.io—a JavaScript-heavy site—shows "problematic indexing issues" in Bing with missing canonical tags, meta descriptions, and H1 elements.

Six specific indexing challenges affect Lovable.dev sites

1. Metadata and title tags aren't visible to crawlers

Meta tags generated client-side may not be processed during the first crawl. The <title> tag must exist before JavaScript execution for proper indexing. Social media crawlers don't execute JavaScript at all, which is why Lovable sites often display generic or incorrect information when shared on Facebook, Twitter, or LinkedIn.

React Helmet can manage meta tags dynamically, but must be combined with SSR for full effectiveness with search engines.

2. Structured data often goes unseen

Search Engine Journal reports that "structured data added only through client-side JavaScript is invisible to most AI crawlers." While Googlebot can eventually process JavaScript-generated JSON-LD, the rendering delays and potential failures create inconsistency. Rich results may not appear if schema markup isn't in the initial HTML.

3. Internal links may not be crawlable

Links created via onclick events or addEventListener are not crawlable. Google ignores URL fragments (#), meaning SPAs using hash-based routing appear as a single URL. A case study documented by Momentic found that a React website lost 51% of traffic partly because "link types that were not crawlable" were implemented as click events rather than proper <a href> elements.

4. Core Web Vitals suffer under client-side rendering

Largest Contentful Paint (LCP) typically performs poorly with CSR because content loads only after JavaScript execution. With pure client-side rendering, the LCP element doesn't exist in initial HTML—JavaScript must build the DOM first, creating significant render delays. The target is 2.5 seconds or less; CSR sites often exceed this.

Cumulative Layout Shift (CLS) increases as JavaScript-rendered content causes elements to shift during load. Brands optimizing their rendering approach report 67% reduction in layout shifts.

5. Mobile-first indexing amplifies the problem

Google primarily uses mobile Googlebot for indexing. Mobile devices have slower processors and limited bandwidth, making JavaScript execution significantly slower. Industry guidelines recommend keeping JavaScript bundles under 100-170KB minified and gzipped for initial load—a threshold many React applications exceed.

6. AI search visibility is nearly zero

Modern AI assistants like ChatGPT, Claude, and Perplexity rely on crawlers that don't execute JavaScript. Vercel research found that most AI crawlers "only fetch static HTML and bypass JavaScript." Lovable's documentation acknowledges: "Many AI systems don't reliably see dynamically rendered content, so they may miss your pages or only see partial content."

Jan-Willem Bobbink's framework for JavaScript SEO

Jan-Willem Bobbink, founder of notprovided.eu and an SEO consultant with 30 years of web development experience, has become a leading voice on JavaScript SEO. At BrightonSEO 2019, he presented findings from building 10 websites using the 10 most popular JavaScript frameworks—conducting hands-on testing rather than relying on client data alone.

His observation that JavaScript framework adoption among clients jumped from 28% in 2016 to 65% in 2019 underscores why this expertise matters. His ten core recommendations provide a practical framework for addressing JavaScript SEO challenges.

Bobbink's primary recommendation: server-side rendering

"Server Side Rendering (SSR) is just the safest way to go," Bobbink states. "For SEO you just don't want to take a risk Google sees anything else than a fully SEO optimized page in the initial crawl." He specifically recommends Next.js as an SEO-friendly framework for React development.

His preferred approach is a hybrid model: "Content and important elements for SEO are delivered as Server Side Rendered and then you sprinkle all the UX/CX improvements for the visitors as a Client Side Rendered 'layer.'"

Critical technical warnings from Bobbink

Data persistence creates ranking risks. "Googlebot is crawling with a headless browser, not passing anything to the next successive URL request." Sites using cookies, local storage, or session data to populate SEO elements—like personalized product links—have lost rankings because crawlers don't carry this data between requests.

Unit test your SSR implementation. Bobbink shared a case where broken SSR caused two weeks of visibility loss. He recommends Jest for Angular and React testing, and vue-test-utils for Vue applications.

Monitor prerendering services for failures. Services like Prerender.io can fail silently. He advocates monitoring tools like ContentKing, Little Warden, PageModified, and SEORadar to detect when rendered pages differ from expectations.

Why Bobbink advises against dynamic rendering

Despite Google historically promoting dynamic rendering, Bobbink advises against it due to outdated content issues. Cached rendered pages can serve stale prices, ratings, or stock information in rich snippets—creating poor user experiences and potential policy violations.

Solutions for improving Lovable.dev site indexability

Option 1: Migrate to Next.js for proper SSR

The most comprehensive solution involves exporting Lovable code to GitHub and converting to Next.js. Tools like "ViteToNext.AI" and "next-lovable" facilitate this migration. Next.js provides:

Server-side rendering via getServerSideProps for dynamic content
Static site generation via getStaticProps for content that doesn't change frequently
Incremental Static Regeneration (ISR) for automatic page updates without full rebuilds
Built-in metadata API for proper SEO tags in initial HTML
Native sitemap and robots.txt generation

The trade-off: Lovable's visual editor no longer functions after migration.

Option 2: Implement prerendering services

Prerendering services intercept crawler requests and serve pre-rendered HTML while users receive the normal JavaScript application.

Prerender.io (industry leader): Starts at $9/month for 3,000 renders, with average delivery time of 0.03 seconds. Supports Google, Bing, and AI crawlers. Requires Cloudflare Workers or similar proxy configuration.

LovableHTML: Built specifically for Lovable.dev sites at $9+/month.

Rendertron: Google's open-source solution. Free but requires self-hosting and DevOps expertise.

Option 3: Add SSR via Vike

Vike (formerly vite-plugin-ssr) can add server-side rendering to existing Vite projects. This preserves the React Router structure but requires VPS deployment rather than Lovable's built-in hosting.

Option 4: Islands architecture with Astro

For content-heavy sites, Astro provides an alternative approach: render pages as static HTML with isolated "islands" of interactivity that hydrate independently. This ships zero JavaScript by default, adding client-side code only where interactivity is required.

Google's official recommendations for JavaScript sites

Google Search Central documentation, updated in December 2025, provides clear guidance for JavaScript-heavy websites.

Dynamic rendering is now deprecated as a long-term strategy. Google explicitly states: "Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines. Instead, we recommend that you use server-side rendering, static rendering, or hydration as a solution."

Don't block JavaScript resources. Ensure robots.txt allows all JavaScript files, CSS files, and API endpoints needed for rendering. Blocking these prevents Google from understanding pages.

Use proper HTML links. Links must be implemented as <a href> elements, not <span onclick> or JavaScript event handlers. Google may not follow programmatically triggered navigation.

Place metadata in initial HTML. Canonical URLs and robots directives should exist in server-rendered HTML. Google advises: "You shouldn't use JavaScript to change the canonical URL to something else than the URL you specified as the canonical URL in the original HTML."

HTTP status codes matter. Pages returning non-200 status codes may skip JavaScript execution entirely. Use proper 404s for missing pages rather than soft 404s.

Practical implementation priorities for Lovable.dev users

For sites where SEO is a primary growth channel, the recommended approach depends on project scale and resources:

Scenario	Recommended Solution
New SEO-critical project	Build with Next.js instead of Lovable
Existing Lovable site, limited budget	Implement Prerender.io or LovableHTML
Large site with development resources	Migrate to Next.js with SSR/SSG hybrid
Content marketing focus	Consider Astro for static generation

Lovable acknowledges that SSR "may help" for very large sites, projects where organic search is the primary growth channel, highly competitive verticals, and sites prioritizing AI/LLM visibility. For applications where SEO matters less than rapid development—internal tools, authenticated dashboards, or apps primarily shared via direct links—Lovable's CSR architecture presents fewer concerns.

Conclusion

The core tension with Lovable.dev is architectural: the platform optimizes for rapid full-stack application development using client-side rendering, while search engines and AI crawlers work best with server-rendered content. This isn't a bug but a fundamental trade-off inherent to the platform's design.

The practical path forward depends on priorities. Teams needing strong SEO should either avoid Lovable.dev for those projects, implement prerendering services immediately, or plan for eventual migration to SSR frameworks like Next.js. Jan-Willem Bobbink's hybrid approach—server-rendered SEO elements with client-side UX enhancements—represents the industry consensus on balancing searchability with interactivity.

As AI-powered search grows in importance, the inability of AI crawlers to execute JavaScript makes this problem increasingly urgent. Sites invisible to ChatGPT, Claude, and Perplexity miss a growing discovery channel. Google's December 2025 deprecation of dynamic rendering as a long-term strategy signals that the search giant expects sites to solve JavaScript SEO at the source through proper SSR implementation rather than workarounds.

DEV Community