There is a particular sequence of events that happens to a lot of people who build on Lovable, and it goes like this.
You finish the app. You are pleased with it. Somebody in a comment section tells you that you need to think about SEO, so you go and find a free SEO checker, paste in your URL, and press the button. The report comes back and it is alarming. No content found. Empty page. Cannot be indexed. Missing headings.
You conclude that Lovable has produced something fundamentally broken, and you spend the next several days reading articles about server-side rendering and wondering whether you need to rebuild the whole thing in Next.js.
Almost certainly, you do not. And the reason is written plainly in Lovable's own documentation, where very few people go looking.
What the checker was actually looking at
Lovable's documentation says this about its pre-rendering, and the wording matters:
Pre-rendering is only served to verified crawlers: Google, Bing, social-preview bots, and AI engines like ChatGPT, Perplexity, Claude, and Gemini. Third-party SEO scanners will see the regular SPA shell, not the pre-rendered HTML.
So there are two different versions of your site being served, depending on who is asking. Google asks, and gets real HTML with your content in it. A random SEO tool asks, and gets the JavaScript shell, because it is not on the verified list.
The tool then reports, accurately, that it found nothing. It is not lying. It is telling you the truth about what it received, which happens to be a completely different thing from what Google received.
This is worth understanding properly, because the panic it causes is real and the rebuild it sometimes triggers is expensive and unnecessary.
The same applies to the "view page source" test that gets recommended everywhere, including in general guides we have written ourselves. Your browser is not a verified crawler either. You will see the shell too.
How to actually check, in about a minute
Do not use a third-party scanner to answer this question about a Lovable app. Use Google itself, which is the only opinion that counts.
The site: search. Type site:yourdomain.com into Google. This lists what Google has actually indexed from your domain. If your pages are there, the conversation is over and your rendering is fine.
The URL Inspection tool in Google Search Console. Paste a specific URL, then choose to test the live URL, then look at the rendered HTML that Google itself fetched. This is the definitive answer, because it is Google showing you what Google got. Nothing else comes close as evidence.
Fetch as a known crawler. If you are comfortable on a command line, request your page with a Googlebot user agent string and read what comes back. You will see the pre-rendered version rather than the shell.
If all three of those show your content, your app is being read correctly and you can stop worrying about rendering entirely.
The date that splits every Lovable app in two
There is a second thing worth knowing, because it determines which situation you are in.
According to Lovable's documentation, apps created from 13 May 2026 use TanStack Start with server-side rendering. In their words, every request returns fully rendered HTML, for humans and crawlers alike. There is no split between what a person sees and what a bot sees. Everyone gets real HTML.
Apps created before that date get the other arrangement, the on-request pre-rendering described above, served to the verified crawler list only.
Both of these work. But they behave differently under inspection, and knowing which one you have tells you how to interpret what you are seeing:
- Built after 13 May 2026? View source will show your content, because everyone gets the rendered version. If it does not, something genuinely is wrong and worth investigating.
- Built before? View source will show a shell, and this is expected and fine. Only Google's own tools will show you the truth.
If you cannot remember when you started the project, the view-source test itself will tell you which one you have.
So what actually still needs doing
Here is the part that matters, because rendering was probably never your problem, and while everybody argues about it the real gaps sit untouched.
Lovable's documentation is direct about the limits of what it handles automatically. Sitemaps, robots.txt and metadata, in their words, are not always generated up front. That leaves you four jobs.
1. A sitemap, generated from your real data
There is likely no /sitemap.xml on your app right now. Go and check by visiting that path.
If your app has pages driven by a database, guides, listings, profiles, articles, then a hand-written sitemap will be out of date within a week. Generate it from the same source the pages come from, so that it cannot drift. An edge function producing XML from your database is the usual approach and it is not much work.
Then submit it in Google Search Console. A sitemap nobody has been told about does very little.
2. Different meta tags on every route
This is the big one, and it is the most common real defect in Lovable apps.
By default a Lovable app ships one set of meta tags in index.html. Every route shares one title, one description, one Open Graph image. So a search engine sees your ten pages and reads ten identical labels, which looks a great deal like one page repeated ten times.
Lovable's documentation is explicit that unique og:title, og:description and og:image values per route are your responsibility. Ask Lovable for a small hook that sets document metadata per page, then call it at the top of every page component with values specific to that page.
Write the titles as answers, not slogans. A page that explains one thing should be titled after the thing it explains.
3. Structured data, added deliberately
Lovable's review tooling flags pages that qualify for a Google Search feature but carry no markup for it. That flagging is useful, but the markup itself is something you have to ask for.
Homepage gets SoftwareApplication. Guides get Article. Anything with genuine questions and answers gets FAQPage. Add Organization once, with your logo and social profiles, so the entity behind the app is unambiguous to a machine.
4. More than one page
No amount of technical work fixes a site that only talks about one subject. If your Lovable app is a single screen, then there is precisely one search you could ever appear for, and it is almost certainly the most competitive phrasing in your category.
This is a content problem rather than a Lovable problem, and it is genuinely the largest opportunity most people have. We have written about it separately in Your App Has One Page. That Is Why Nobody Finds It.
The short version
If you build on Lovable, the rendering is very likely handled, either by server-side rendering on newer apps or by crawler-targeted pre-rendering on older ones. The free SEO checker that frightened you was reading the shell, because it is not on the verified crawler list, and Lovable says so in its own documentation.
Check with Google's own tools instead. Then go and spend your effort where the actual gaps are: a sitemap generated from your data, unique metadata per route, structured data you asked for on purpose, and considerably more than one page.
Want a second pair of eyes?
If you would rather have somebody go through your Lovable app with you and show you exactly what Google and the AI assistants are receiving, we are glad to do that on a call.
Related reading: