If your Lovable app isn't showing on Google, the usual cause is client-side rendering: Googlebot, GPTBot and ClaudeBot receive an almost empty HTML page, because the content is drawn by JavaScript in the browser. Fix it in this order: make sure robots.txt, noindex tags and your domain aren't blocking anything, put a prerender layer in front as a quick patch, then move the pages that need to rank to server rendering on Next.js or TanStack Start. Prerendering can get you indexed. It's rarely the right place to stop.
The same applies to Bolt or v0 apps that render on the client. Here's how I'd work through it.
Why is my Lovable app not showing on Google?
Most of the time it's because the content is rendered by JavaScript in the browser instead of being sent in the HTML. A client-rendered React app hands the browser a near-empty HTML file with a <div id="root"> and a script tag. Your headings, copy and links only show up once that JavaScript runs.
Google can run JavaScript, but it does it in a second pass. Google's JavaScript SEO basics explain that pages go into a rendering queue, and say server-side or pre-rendering is "still a great idea" because "not all bots can run JavaScript."
AI crawlers are stricter. Vercel's analysis of AI crawler traffic found that GPTBot and ClaudeBot don't execute JavaScript at all. To them, a client-rendered page is the empty shell and nothing more. So even if Google gets round to indexing your Lovable app, ChatGPT and Claude may still have nothing to quote.
Is my Lovable, Bolt or v0 app actually client-rendered?
A Lovable app created from May 13, 2026 is server-rendered. Older Lovable apps, and Vite builds exported from Lovable or Bolt, usually aren't. Lovable changed its rendering in 2026, so it comes down to when the app was made and where it's hosted. Lovable's SEO documentation says apps created from May 13, 2026 use TanStack Start with server-side rendering. Older React and Vite apps get pre-rendered on request, but only for verified crawlers and only on Lovable-hosted public URLs.
| Your setup | What crawlers get | Likely fix |
|---|---|---|
| New Lovable app (TanStack Start), hosted on Lovable | Full HTML from the server | Rendering is fine. Check metadata, domain, links |
| Older Lovable app (React + Vite), hosted on Lovable | Pre-rendered HTML for verified bots only | Upgrade to TanStack Start, or rebuild key pages |
| Lovable or Bolt code exported and hosted on Netlify, Vercel or Cloudflare as a Vite build | Usually the empty shell | Prerender now, server rendering soon |
| v0 or Next.js code where pages fetch content in the browser | Shell plus "Loading..." | Move data fetching to the server |
Don't guess. Test it.
How do I check what Google and AI crawlers see?
Look at the raw HTML with view-source, then at the rendered result in Google Search Console's URL Inspection. If your H1 text isn't in the raw source, crawlers that skip JavaScript can't see it. The four checks below take about 15 minutes.
- 1
View the raw source
Open view-source: on a key page and search for your H1 text. If it isn't in the raw HTML, crawlers that skip JavaScript can't see it.
- 2
Run URL Inspection
In Google Search Console, run a live test and open the rendered HTML and screenshot. A blank or half-loaded screenshot points to a rendering problem.
- 3
Check crawler access
Run your domain through the AI Crawler Checker to see whether robots.txt lets 14 AI crawlers in, which rule decides it, and whether you have an llms.txt and sitemap.
- 4
Read the Page indexing report
Look for 'Excluded by noindex', 'Crawled - currently not indexed' and duplicate canonical issues. Each one has a different fix.
Step 1: Are robots.txt, noindex or your domain blocking you?
Quite often, yes. A leftover robots.txt rule, a sitewide noindex tag or a lovable.app workspace URL will keep a Lovable app out of Google however well it renders. Rule these out before you pay for anything. They're cheap to fix and common on AI-built apps:
- robots.txt blocks crawlers. A leftover
Disallow: /from staging, or a rule that blocks GPTBot or ClaudeBot when you actually want AI citations. My free AI Crawler Checker shows which bots are allowed and which line decides it. - A noindex tag on every page. Lovable's SEO documentation lists this as a high-impact issue, along with a robots.txt that blocks crawlers on a live site.
- You're on a Lovable URL, not your own domain. Lovable's docs say branded workspace URLs never appear in search, and recommend connecting a custom domain. When you move, make sure the old lovable.app address redirects and your canonical tags point to the new domain.
- Every route shares one title and description. If every page says "My App", Google has no reason to index more than one of them.
- No sitemap, or a sitemap full of placeholder routes.
What about llms.txt? It's optional. Lovable's docs say a missing llms.txt isn't a problem, and nothing guarantees an AI crawler will read it. I still publish one on mohitgoyal.in, because my home page is a chat interface and I want a clean, quotable text version for assistants that don't run JavaScript. It costs nothing. It also won't fix a rendering problem.
If your pages show "Crawled - currently not indexed" and the HTML looks fine, that's usually about quality or duplication, not rendering. I cover it in how to fix Crawled - currently not indexed.
Step 2: Is a prerender service a good quick fix?
As a quick patch for a client-rendered Lovable app, yes. Prerender.io's published plans start at $59 a month. Just don't treat it as the permanent answer. A prerender service runs a headless browser, saves the finished HTML of each page and serves that copy to bots, while people still get the normal app. You add middleware or a proxy and leave the app code alone.
Here's what Prerender.io's pricing page lists:
| Plan | Price per month | Renders included | Cache expiry |
|---|---|---|---|
| Starter | $59 | 30,000 | 24 hours to 7 days |
| Growth | $169 | 100,000 | 12 hours to 14 days |
| Pro | $419 | 500,000 | 6 hours to 30 days |
The same page lists extra renders at $2.25 per 1,000 on Starter. There are cheaper options too: Encited lists self-serve plans from $19 to $349 a month. And if you're on an older Lovable app hosted by Lovable, you may not need any of these, because Lovable already pre-renders for verified crawlers.
Prerendering makes sense if you have a small marketing site, content that rarely changes, and a launch or fundraise next week.
When is a prerender add-on not enough?
Once real-user Core Web Vitals, fast-changing content or a large number of URLs start to matter. A prerender layer changes what bots see. It doesn't change the site. You'll outgrow it if any of these apply:
- Real users still wait for JavaScript. Core Web Vitals are measured on real visitors, and they still get the client-rendered app. A slow LCP stays slow. Only bots get the fast copy.
- Late-loading content goes missing. Lovable's docs warn that content that loads late may be missing from the pre-rendered page. Pricing tables, reviews and product data fetched after load are the usual casualties.
- Only verified bots get the HTML. On Lovable's setup, unverified bots and link checkers see the single-page app. Every new AI crawler is one more bot you're hoping gets recognised.
- Content changes faster than the cache. Stale prices or stock in Google's copy cause trust and compliance headaches. Shorter caches mean more renders, which means a bigger bill.
- You have hundreds or thousands of URLs. Programmatic pages, listings and blogs push you into higher tiers, and the monthly fee never stops.
- Two versions to debug. When rankings drop, you have to check whether the bot copy and the live page still match.
A prerender layer is rented, not owned
If the content you need to rank depends on a third-party cache staying in sync, you have a monthly cost and a single point of failure. Treat it as a bridge to server rendering, not the destination.
Step 3: Should I move to server rendering on Next.js or TanStack Start?
For any page that has to rank on Google or get cited by ChatGPT and Claude, yes. That's the lasting fix. With server rendering, every request returns finished HTML, whether it comes from a person, Googlebot or an AI crawler. There's one version of the page, it's fast on the first visit and there's no add-on to pay for.
| Option | Best for | Trade-off |
|---|---|---|
| Lovable's TanStack Start upgrade | Staying in Lovable and keeping the AI workflow | Still tied to the platform and its credits |
| TanStack Start, owned code | React apps with a lot of interactivity that need SSR without big changes to routing | Smaller ecosystem than Next.js |
| Next.js | Marketing sites, blogs and SaaS front ends that need a CMS, static pages and SEO | More rework if your app relies on client-only patterns |
I go through the two frameworks side by side in Next.js vs TanStack Start.
My own site runs on TanStack Start. mohitgoyal.in is a React app with a chat that answers as me, built on the Claude API and Firestore, which is about as JavaScript-heavy as a portfolio gets. The facts still had to be readable without anyone running that chat. So every service, project and free tool has its own URL, and a plain-text llms.txt and llms-full.txt sit alongside them for crawlers that don't execute JavaScript. That's how I'd think about any rebuild: decide which content needs a real URL and real HTML, and which can stay interactive.
You rarely need to rewrite the whole app. The usual split is server-rendered marketing pages, pricing, blog and docs, with the logged-in product left as a client app on a subdomain or under /app.
How long does a fix take, and what changes the cost?
Fixing robots.txt, metadata and the domain is usually a day's work, and a prerender layer can go live the same day. A server-rendered rebuild on Next.js or TanStack Start depends on what you're moving:
- Number of public templates. Ten distinct page types take more work than ten pages on one template.
- Where the content lives. Content hardcoded in components moves fast. Content in Supabase or a CMS needs data fetching on the server.
- Client-only libraries. Anything that touches
windowon load has to be reworked. - URL changes. If URLs change, you need a redirect map and a Search Console check after launch.
Whichever route you take, don't expect results overnight. Lovable's docs note that new pages can take days, sometimes longer, to get indexed. Submit the sitemap and request indexing for your key pages.
What should I ask a developer before they touch it?
Ask them to prove the fix in the raw HTML, and to tell you exactly which pages will be server-rendered and who owns the code afterwards. These are the questions I'd want answered:
- Will you show me the raw HTML of a key page before and after the fix?
- Which pages will be server-rendered, and which will stay client-side?
- Will any URLs change, and where's the redirect map?
- How will titles, canonicals, Open Graph tags and structured data be set for each route?
- How will you check Core Web Vitals on real devices after launch?
- Who owns the code and the hosting account at the end?
If the answer to the first question is "we'll add a plugin", keep looking.
What should I do next?
Run your domain through the AI Crawler Checker and open view-source on your most important page. If the content isn't in the HTML and that page needs to rank, I can move it to server rendering on Next.js or TanStack Start without throwing away what you've built. Have a look at my Next.js and React websites service, or technical SEO and Core Web Vitals if you only need the indexing sorted. Then book a 20-minute call and send me the URL.
