In this article
The SEO question for any AI-generated site reduces to one thing: what does a crawler actually receive at your URL? Everything else — titles, structured data, internal links — only matters once the content is in the response. This is an audit you can run in about fifteen minutes on a real URL, plus an honest split between what Lovable’s own documentation states and what only a test on your project can answer.
Key takeaways
- Rendering mode is the first check, not the last. It decides whether anything else is visible.
- Lovable documents two different behaviours depending on how the app was built, and the difference is significant.
- Every check below runs against your own URL with tools you already have.
- Claims about your specific project cannot be settled from vendor documentation — the framework separates the two deliberately.
What the documentation actually states
Lovable’s SEO documentation makes a distinction its marketing does not: newer apps use server-side rendering via TanStack Start, while older React and Vite applications pre-render for verified crawlers and serve a client-side shell to everything else.
Read that second behaviour carefully, because it is the important one. Pre-rendering for verified crawlers means a crawler that identifies itself and passes verification receives rendered HTML. Anything that does not — an AI assistant fetching the page, a preview bot, a link unfurler, a checker that does not announce itself — can receive a near-empty shell. That is not a defect, it is a documented design choice, but it means "it works in Google" and "it works everywhere" are separate questions with separate answers.
The audit, in order
1. Fetch the raw HTML without JavaScript
View source rather than inspecting the DOM — the inspector shows you the page after scripts have run, which is exactly what you are trying to exclude. Search the raw response for a distinctive sentence from your main body copy. If it is there, the content is server-rendered or pre-rendered for you. If the response is a small shell of script tags, the content only exists after execution, and every subsequent check is conditional on whichever consumer happens to execute JavaScript.
2. Repeat it as a plain client
The same request without a browser user agent tells you what a non-verified consumer receives. If step one showed content and step two shows a shell, you have found the pre-rendering boundary described in the documentation. That is precisely the case worth knowing about, because AI assistants and social unfurlers sit on the wrong side of it.
3. Check one title and description per URL
Confirm that each page has its own title and meta description rather than a single set inherited across the whole app. Single-page application shells commonly ship one title for every route unless the framework is explicitly configured otherwise.
4. Confirm one H1 and a real heading order
One H1 per page, and H2s that describe sections rather than being chosen for size. This is the cheapest structural check available and it is wrong surprisingly often on generated pages.
5. Validate structured data against the rendered HTML
Structured data injected only after JavaScript execution is not reliably seen. Check that the JSON-LD is present in the raw response from step one, and that what it says matches the visible page — Google’s structured data guidance is explicit that markup must reflect visible content.
6. Read robots.txt and the sitemap as a stranger
Fetch both at their canonical paths. Confirm the sitemap lists the URLs you actually want indexed, that they return 200 rather than redirecting, and that robots.txt does not disallow a path that now holds real content — a template copied from an older project is the usual culprit.
7. Check canonicals and redirects
Each URL should declare itself canonical unless it is deliberately a duplicate. Then confirm the trailing-slash and non-canonical variants resolve with a single permanent redirect rather than a chain.
Verified from documentation, versus needs a project-level test
This split is the point of the article, so it is worth stating without hedging.
Verified from Lovable’s own documentation: that newer apps use server-side rendering via TanStack Start; that older React and Vite apps pre-render for verified crawlers and otherwise serve a client-side shell. Both statements come from the vendor’s SEO documentation, read on August 30, 2026.
Needs a test on your own project: which of those two behaviours your specific app uses; whether your pages carry unique titles and descriptions; whether your structured data appears in the raw response; whether your sitemap and robots.txt are correct; whether your canonicals are clean. None of these can be answered from any vendor’s documentation, including this article, because they depend on how your project was built and configured.
You will notice there are no scores here, and no ranking or traffic figures. None were measured. A number invented to make an audit feel authoritative is worse than no number, because it survives being quoted long after anyone remembers it was invented.
What to do with the result
If step one shows a shell, the fix is architectural rather than editorial: no amount of keyword work compensates for content that is not in the response. If steps one and two disagree, decide deliberately whether being readable only by verified crawlers is acceptable for your business — for a marketing site that wants to be quoted by AI assistants, it usually is not, which is the subject of AI visibility. If everything passes, the remaining work is ordinary and ongoing, and that is covered under SEO automation.
When to run it again
Every answer this audit produces has a shelf life, because rendering behaviour is a property of the build rather than of the account. A framework upgrade, a migration between app generations, or a change in how a page fetches its data can all move a route from server-rendered to client-only without anything in the interface announcing it. The audit is cheap enough to repeat, so repeat it: after any framework or platform upgrade, after adding a route that loads its content differently from the rest, and before any launch that matters commercially.
Record the date you ran it alongside the result. An audit without a date is indistinguishable from a guess six months later, and the whole point of testing your own project rather than reading a vendor page is that you end up holding evidence rather than an impression.
Frequently asked questions
Is Lovable good for SEO?
It depends on which rendering path your app uses, and the documentation states two different ones. Newer apps are server-rendered. Older React and Vite apps pre-render for verified crawlers and serve a client-side shell to everything else. Run step one and step two above on your own URL rather than accepting a general answer.
Why check without a browser user agent?
Because pre-rendering for verified crawlers means the response depends on who is asking. A browser and a verified search crawler may both receive content while an AI assistant or a link unfurler receives a shell. Comparing the two requests is what makes that boundary visible.
Do I need paid tools for this audit?
No. View source, a command-line fetch and a structured-data validator cover all seven checks. The audit was written that way so the result is reproducible by anyone reading it.
Does this article score Lovable’s SEO?
No, and deliberately. No project-level tests were run, so any score would be invented. The article separates what the vendor documents from what your own project must be tested for, which is the useful distinction.
Does structured data still count if it is added by JavaScript?
Treat it as unreliable. Confirm the markup is present in the raw response and that it describes what a visitor can actually see, which is what Google’s structured data guidance requires.
Written by Vincent Chen, who is accountable for the claims on this page.
Sources
Written by
Founder of PolyDraft and CEO of BlackMonolith, Inc.
