Do Lovable websites rank on Google? The problem and the fix

A single-page application has one HTML document. The server returns that same file for the home page, the contact page, a blog post or a product page. The file only contains a shell: a handful of meta tags, an empty container and a reference to a JavaScript bundle. Once the JavaScript runs in the browser, the router reads the URL and replaces the container's content with the right page.

For Google, this means deferred rendering. Crawling happens in two stages: the bot downloads the HTML, sees it is empty, then queues the URL so that a headless browser can execute the JavaScript later. That second pass is neither immediate nor guaranteed at the same pace as the first, and it is expensive on the search engine's side.

On top of that comes a subtler effect: crawl budget. A bot has a limited request volume per site, calibrated on domain authority. When every URL returns an identical document, the engine gets no novelty signal and no reason to dig further. On a recent domain the typical outcome is not rejection: it is a plain absence of crawling.

This is the point almost nobody explains, and it is the sharpest one. Answer-engine bots — GPTBot, ClaudeBot, PerplexityBot, CCBot and most of the collectors that feed language models — are plain HTTP clients. They request a URL, read the returned HTML and stop there. They ship no rendering engine and do not execute JavaScript.

On a single-page application without pre-rendering, these bots therefore receive an empty shell. Not thin content: nothing. Not one sentence from the page, no specific title, no table, no data. A company can have published fifty pages of solid content and remain entirely absent from these engines' answers, because from the collector's point of view that content never existed.

The contrast with Google is stark. Google usually renders the page eventually, late. AI engines get no second chance: whatever was missing from the first HTTP response never enters their corpus. As a growing share of searches moves to conversational interfaces, that silence costs more than a poor ranking.

The test takes two commands. Request two different URLs from the site while identifying as a bot, then compare what comes back. Open a terminal and run:

curl -s -A "GPTBot/1.0" https://your-domain.com/ | wc -c

curl -s -A "GPTBot/1.0" https://your-domain.com/another-page | wc -c

First compare the two byte counts. If they are strictly identical, both URLs serve the same file: the site is not pre-rendered. Then compare the title actually sent, using grep -o "<title>[^<]*" on each response. If both pages announce the home-page title, the diagnosis is confirmed.

A third check makes the demonstration final: request a URL that does not exist, such as /made-up-page-123. If it also answers with the same document and a 200 status, the site is serving an unlimited number of indexable copies of its home page. On a pre-rendered site, by contrast, each URL returns a different byte count and a different title, and the unknown URL is treated as an error.

Because the result is a folder of HTML files the client owns. At the end of the build, every public URL exists as a standalone file with its title, description, canonical tag, hreflang tags, JSON-LD and full text. Those files can be served from any static host, including one that is not ours.

So there is no subscription to renew, no middleman to query when a bot complains, and no application server to watch overnight. If the agency disappeared, the site would remain readable by search engines exactly as on delivery day. It is the same logic as the one described in our delivery methodology: what is delivered must remain usable without us.

Build-time pre-rendering has one honest trade-off: you must recompile to publish a content change. On a marketing site, a resource library or an editorial blog, that constraint is negligible. On an application whose public content changes several times an hour, server-side rendering becomes the right answer again — and we say so before the quote, not after.

The indexing report showed 8 indexed pages and 78 non-indexed pages. Of those 78, 76 were classified as "Discovered - currently not indexed", with "Last crawled: N/A". In other words, Google knew about these URLs from the sitemap but had never crawled a single one of them.

The decisive figure is the other one: zero pages under "Crawled - currently not indexed". That category holds pages Google downloaded and then set aside, usually for insufficient quality or duplication. It was empty. Google had therefore passed no judgement on the content: it had simply never looked.

This is an important operational distinction. A site rejected after crawling has a content problem, and rewriting the pages is the right answer. A site that was never crawled has an access problem, and no amount of extra content solves it while every URL serves the same file. We were in the second case, and the technical fix had to come first.

The temptation is strong: since the bot cannot see the content, you add a block of text into the document meant only for it, hidden from users by CSS or pushed off-screen. That practice has a name in Google's spam policies: hidden text. It is explicitly forbidden, just like showing different content to bots and to visitors.

The possible penalty is not a mere algorithmic adjustment but a manual action — a human decision targeting the site, with a reconsideration process to follow. The cost-benefit ratio is disastrous: you gamble the domain's entire visibility for content that pre-rendering would have made visible legitimately.

We deliberately describe no method for doing it. The useful rule is simple: what is sent to the bot must be exactly what the user sees. Pre-rendering respects that rule by construction, since it produces the HTML of the real page.

Static hosting generally returns the index.html file for any URL it does not know. On a single-page application, that means a made-up address answers with HTTP 200 carrying the home page's content, canonical tag and indexing directive. Every typo in an external link, every stale URL, every randomly generated address thus becomes an indexable copy of the site.

The fix belongs to the router, at the moment the application finds no matching route. Three moves are enough: replace the robots directive with noindex, nofollow; remove the canonical tag inherited from the static document, so the URL is not attributed to the home page; and replace the title with a real error title in the language of the requested URL.

One detail matters: the requested URL must stay in the address bar. Silently redirecting to the home page reproduces the problem in another form, since the engine then records a redirect from an address that should never have existed.

An obsolete sitemap, an old robots.txt or an orphaned page deleted from the repository often keeps being served in production. The reason is mechanical: a static deployment publishes the files present in the output folder, but does not necessarily erase those that were there before, and the delivery network's cache keeps the previous version for as long as it remains valid.

In practice, you can spend a day fixing a sitemap in the code without a single correction showing up online, because the old file is still being served. The right reflex is to verify each fix directly against the public URL, with curl, rather than in the repository.

When a file must disappear, overwrite it with valid empty content or replace it with a redirect rather than deleting it and hoping. Then always check what the address actually returns in production.