My Lovable Site Is Not Showing on Google: What to Check, in Order

Lovable is the AI app builder at lovable.dev. You pressed Publish, the address loaded, and a week later the site still was not in Google. Search for lovable seo problems and most of what ranks will tell you the cause is rendering, then sell you a service that fixes rendering. On Lovable hosting, as of 25 August 2026, that is the wrong cause, and the thing that says so is Lovable’s own documentation.

A published Lovable site missing from Google is usually a sitemap problem, a duplicate title, a robots rule, or a waiting period that has not run out yet. Lovable hosting already returns readable pages to search crawlers. Check the publish state, the crawler view, the sitemap and Search Console before you buy anything.

What Lovable hosting returns to a crawler was read out of Lovable’s own hosting, SEO and custom-domain documentation on 25 August 2026, and what Google does with what it gets back was read out of Google Search Central and Search Console help on the same day. No project was built or scanned for this page, and no ranking claim rests on a tool that is not one of those two sources.

First: is the site actually on an address Google is allowed to index?

Three kinds of address can never rank, whatever else you fix: an unpublished project, a private project, and a branded workspace URL. Lovable’s documentation says so in one sentence. Check which address you are actually looking at before you touch a title tag or a sitemap.

Lovable’s SEO documentation, read 25 August 2026, puts all three in a single line: “Only publicly published apps can be indexed by search engines. Private or unpublished projects, and branded workspace URLs (https://{app-name}.{workspace-subdomain}.lovable.app), are never indexable.” If your site lives on a branded workspace address, no amount of metadata work changes the outcome, and the next step is a published lovable.app URL or a custom domain instead.

The preview inside the editor is not the address Google visits, and what separates a preview from the published site explains why the two disagree. A preview pane can look perfect while the published snapshot is weeks behind it.

A domain can also be fully set up and serving nothing. Lovable’s custom-domain documentation lists a status called Ready, defined as “Domain is correctly configured, but your project isn’t published yet. Domain will start serving automatically when you publish.”

Then the trap that catches people who already did the work. Lovable’s hosting documentation states it plainly: “The published site is a snapshot. Changes you make after publishing don’t affect the live site until you open the Publish dialog again and click Publish changes, so you can keep building without breaking what your visitors see.” Fix your titles in the editor yesterday and skip the publish, and Google is still reading the old ones. Loadable and findable are two different finishing lines, and what pressing Publish actually puts on the internet is worth understanding before you debug what Google did with it.

If the Publish button itself never finishes, none of this applies yet, because there is no address for Google to visit: a publish that will not complete is its own diagnosis.

What happens between your published page and a Google result

Google fetches your address, reads the HTML it gets back, then puts the page in a queue to run its JavaScript before indexing it. That queue is normal and its wait is not fixed. Nothing in that sequence is broken by default on a published Lovable site.

Google’s JavaScript SEO basics guide, read 25 August 2026, describes the whole thing in three phases: “Crawling”, “Rendering”, “Indexing”. The crawl fetches your URL and parses whatever HTML comes back, which for a lot of AI-built sites is close to empty, because the words are assembled in the visitor’s browser rather than sent ready-made. Google’s own wording for that case is “Some JavaScript sites may use the app shell model where the initial HTML does not contain the actual content and Google needs to execute JavaScript before being able to see the actual page content that JavaScript generates.” What happens next is the part the panic usually skips: “Googlebot queues all pages with a 200 HTTP status code for rendering, unless a robots meta tag or header tells Google not to index the page”, then “Once Google’s resources allow, a headless Chromium renders the page and executes the JavaScript.” Google runs the code. The only honest caveat is the wait, and Google states it without a number: “The page may stay on this queue for a few seconds, but it can take longer than that.”

Single page app SEO, and whether that is still your problem

Single page app SEO was Lovable’s real problem until 2026. It is now a question about which of two stacks your project runs on, and the vendor documents both. Neither of them needs an outside rendering service to be readable by Google.

Lovable’s hosting documentation, read 25 August 2026, splits its projects in two. “Apps created from May 13, 2026 use server-side rendering: every visitor and crawler receives fully rendered pages.” For anything older, the same page says “Older apps serve rendered pages to verified search engines, social preview bots, and AI crawlers, so your content is indexed and link previews work.” Its SEO page then spells out who counts as verified on that older stack: Google and Bing, the social preview bots, and four AI engines it names one by one.

A free SEO checker is not on the list, and that is where the confusion gets manufactured. Lovable states the consequence directly.

Third-party SEO scanner tools are not verified crawlers, so they may report your pages as empty even though Google, social platforms, and AI search engines see the full content.

So the reader runs a checker, the checker reports an empty page, and the pages they find next all agree with the checker. Two of those, both read on 25 August 2026, still describe Lovable the way it worked before the change. Encited’s guide, dated 11 March 2026, builds twelve numbered fixes on the claim that “When a crawler visits your page, the initial HTML it receives is an empty shell”, ends at a section headed The Fix: Prerender Your Lovable Site, and never mentions the May change. Prerender.io’s guide, updated 17 June 2026, does acknowledge that Lovable shipped its own rendering, but dates it to “after April 20, 2026”, calls the reception “mixed”, and still lists prerendering as fix number one. Neither page is linked here, and neither company is acting in bad faith. They are describing a product that changed under them.

None of which makes server rendering worthless. Google says the opposite: “Keep in mind that server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript.” Server rendering is better, and on Lovable hosting it is already there, so buying a second copy of it does not move your site into the index.

The cost of the wrong cause is real. One Lovable owner, writing publicly, put their decision like this: “I am migrating off lovable slowly but surely due to SSR. And I know I am not the only one.” They may well have other reasons to go, and a move is a legitimate choice. Rendering, on its own, stopped being one of them this year.

Whether an indexing problem is on its own a good enough reason to leave Lovable is a stay-or-go decision rather than a repair, and it is weighed against the same two stacks over here.

The four things Lovable does not set for you

Rendering is handled. Titles, canonical URLs, the sitemap and robots.txt are still yours, and Lovable’s own review names the exact ways each one fails. A page can be perfectly readable to Google and still be missing all four of those.

Lovable’s SEO and AI search review lists what it checks and how each check fails. Read as a list of causes rather than a list of features, it is the most useful inventory on this page.

Google’s guidance on the first row is one sentence long: “Unique, descriptive <title> elements and meta descriptions help users quickly identify the best result for their goal.” Per route, not per site. This is the failure that survives every migration, because no platform writes it for you. One owner of an AI-built research site went looking for their article pages in Google, found them missing, and traced it to the per-page titles and descriptions not reaching Google consistently. That app was built on Base44, which is the point: the symptom belongs to the pattern, not to the builder.

The robots.txt row deserves more weight than its size suggests. Lovable reserves its highest severity for exactly this class of thing: “Reserved for problems that can effectively hide your site from search engines, such as a sitewide noindex tag, a homepage that will not load, robots.txt blocking crawlers on a live site, or an X-Robots-Tag: noindex header on a server-rendered published deployment.”

A noindex tag has a second edge that surprises developers, never mind founders. Google warns that “When Google encounters the noindex tag, it may skip rendering and JavaScript execution, which means using JavaScript to change or remove the robots meta tag from noindex may not work as expected.” Code that strips the tag after the page loads may never get the chance to run.

One more thing about the review itself: it is on demand. Lovable’s SEO documentation says “SEO & AI search reviews run on demand and analyze your code, preview deployment, and, once publicly published, your live site. Lovable does not rerun reviews automatically when you publish.” As of 25 August 2026 that documentation describes no way to schedule one, so a green result from three weeks ago is not evidence about the site today.

Lovable app not indexed: read it in Search Console instead of guessing

Search Console names the reason instead of leaving you to guess. Seven statuses from Google’s own Page Indexing report cover the shapes this problem takes, and each points at a different action. URL Inspection shows the raw HTML Google received, which settles the argument with your scanner.

Every status name and definition below is quoted from Google’s Page Indexing report help page and its URL Inspection tool help page, both read 25 August 2026.

URL Inspection is what ends the argument with a scanner. Google describes the tool as one that “provides information about Google’s indexed version of a specific page, and also allows you to test whether a URL might be indexable”, and its View crawled page panel shows “the raw HTML returned, the HTTP headers, JavaScript console output, and any page resources loaded”. That is Google telling you what Google got from your address, which no third-party tool can do for you. Use it sparingly: “There is a daily limit of inspection requests for each property that you own.”

Then the part nobody wants. Google’s recrawl guidance sets the window at “Crawling can take anywhere from a few days to a few weeks”, and closes the obvious workaround: “Keep in mind that there’s a quota for submitting individual URLs and requesting a recrawl multiple times for the same URL won’t get it crawled any faster.” Lovable’s own answer agrees in shape: “Indexing can take from a few hours to a few days, and sometimes longer depending on Google’s crawl schedule and your site’s authority.”

Google still shows the old lovable.app address, not my domain

Two addresses serving the same pages is a canonical question, and Google decides it. Lovable redirects between connected project domains temporarily and documents that it does not do permanent ones. You can point Google at the right host, then wait, because this one moves on Google’s schedule.

Lovable’s custom-domain documentation is specific about what happens between domains attached to a project. “If a domain is primary, all other connected domains redirect to it using a 302 temporary redirect.” It then explains the choice: “Lovable hosting does not support 301 permanent redirects between connected project domains. Primary domains can be changed, so Lovable uses temporary redirects to keep domain changes reversible.”

The default project address is a separate case. The same documentation says “Currently, there is no way to remove the xxx.lovable.app project URL from your project”, and that setting a custom domain as primary “allows visitors to access your app from a branded URL instead of the default xxx.lovable.app project URL”. As of 25 August 2026, Lovable’s custom-domain documentation does not state what the default lovable.app address serves once a custom domain is primary. It neither says the old address keeps serving nor says it stops, and that gap is not mine to fill by guessing.

On Google’s side, its canonicalization guidance, read 25 August 2026, ranks the signals: redirects are “A strong signal that the target of the redirect should become canonical”, a rel="canonical" annotation is “A strong signal that the specified URL should become canonical”, and a sitemap entry is a weak one. Its instruction is “Use permanent redirects to tell Google that a redirected URL is a worse version than the URL it redirects to.” As of 25 August 2026 that page names permanent redirects and makes no equivalent statement about temporary ones, which is an absence in Google’s documentation rather than a claim that a 302 gets ignored. Leave the question open and Google settles it for you: “if you don’t specify a canonical URL, Google will identify which version of the URL is objectively the best version to show to users in Search.”

Four things you can do today. Set one custom domain as primary. Verify that host in Search Console, which is what Lovable tells you to do anyway: “After your domain becomes Live, run an SEO review and verify the domain in Google Search Console.” Point every route’s canonical at that host, then publish and submit the sitemap from it, because “Google fetches the sitemap from your live site, so unpublished routes won’t be submitted.” Then inspect one important URL on the old address and read which URL Google has selected as canonical. That last step is the only one that tells you whether Google has understood the change.

Your options, ranked by what you can do without a developer

Seven options, cheapest and most reversible first. The first four need no new tool and no developer. Moving to another host and framework is last because it is the largest change and the one that carries none of the other fixes with it.

Before the list, the sentence that removes the most expensive option from most people’s shortlist. Asked directly whether an external prerendering service is needed, Lovable’s SEO documentation answers: “Lovable-hosted projects do not need an external pre-rendering service for search engines or AI crawlers.”

1. 01 Publish the project publicly, and get it onto an address that can be indexed at all.
2. 02 Run Lovable's SEO and AI search review. Running the review is free on all plans, applying its fixes uses regular message credits, and it does not rerun itself when you publish.
3. 03 Set a title, a description and a canonical URL for every route, fix the sitemap and the crawler rules, then publish again so the live snapshot actually carries them.
4. 04 Verify the right host in Google Search Console, submit the sitemap from the live site, and inspect your three or four most important URLs.
5. 05 Wait out the documented window before treating any of this as broken: days to weeks by Google's account, hours to days by Lovable's.
6. 06 Upgrade an older project to TanStack Start. The upgrade runs inside your existing project, uses credits, and leaves the published site unchanged until you publish again.
7. 07 Move to a host and a framework that render on the server. Largest change, least reversible, and it fixes none of options three or four for you.

Options one to four are the whole job for most sites, and they are the four nobody is selling. Option six is the vendor’s own path for older projects, and Lovable’s wording of it, “The upgrade runs in your existing project, uses credits, and leaves your published site unchanged until you publish again”, is worth reading twice: the live site does not change under your feet, and the cost lands in credits rather than a subscription.

Option seven is where the caution belongs. One founder rebuilt a site off a hosted builder onto a coding agent and came out the other side with several broken deploys and a search-indexing problem still waiting for them. Another rebuilt a company site on Lovable and reported the result as full server-side rendering with the search side in place. Neither story is an argument about hosting. Both are arguments about whether the titles, the sitemap and the canonical URLs got written, on whichever platform you end up on.

Moving the frontend to Vercel needs different build settings for each of the two Lovable stacks, and both sets are already written down; this page stops at the decision and does not run the move. Picking an exit route, and getting the database and the accounts out with the code, is a longer sequence than a rendering change, and the routes off Lovable are laid out separately. If the destination is moving the same project to a coding agent or running the exported code on hosting you control, the same warning applies: neither of those writes a title tag.

When none of this is the problem

Sometimes the page is crawled, indexable, and still not chosen. Google says so in its own status definitions, and it also says asking again will not change the answer. A new site with a handful of pages and nothing linking to it is a content question wearing a technical costume.

Two Google sentences carry this section. The Page Indexing report defines Crawled - currently not indexed as “The page was crawled by Google but not indexed. It may or may not be indexed in the future; no need to resubmit this URL for crawling.” And the recrawl guidance is blunt about what a request buys you: “Requesting a crawl does not guarantee that inclusion in search results will happen instantly or even at all. Our systems prioritize the fast inclusion of high quality, useful content.”

Lovable draws the same line around its own responsibility, in the sentence that follows all its rendering claims: “Readable pages are the baseline. How well they rank depends on their content, metadata, and structure.” Readable is the floor. Nobody, including the vendor, is promising the ceiling.

If the app itself is the worry rather than the search result, whether the app is fit for real customers is a different check with a different order. And if your pages are indexed but not ranking, that is a content project, and it runs on a slower clock than any of the seven options above.

Common questions about a Lovable site not showing on Google

Eight questions people actually type into Google when a published site does not show up, answered for a Lovable site specifically rather than as general search advice, and none of them repeating a section above word for word.

Is Lovable bad for SEO?

Not for rendering, as of 25 August 2026. Lovable’s hosting documentation says apps created from 13 May 2026 server-render every request, and older apps serve rendered pages to verified crawlers. What Lovable does not write for you is the per-route titles, descriptions, canonical URLs, sitemap and crawler rules, and those are what usually keep a published site out of the index.

Are Lovable websites good for SEO?

They can be, and the platform is no longer the limiting factor. Lovable’s own documentation treats a readable page as the floor and puts ranking down to content, metadata and structure. Getting read by Google is handled. Getting chosen by Google is the same work it is on any other host.

How do I fix Lovable SEO?

In this order: publish publicly, run Lovable’s free SEO and AI search review, fix the titles, descriptions, canonical URLs, sitemap and crawler rules it flags, publish again so the live snapshot carries the changes, then verify the site in Search Console and submit the sitemap.

Why is my Lovable app not indexed?

Open Search Console and read the status rather than guessing at it, because each status has a different cause. Discovered - currently not indexed means Google has not crawled it yet. Crawled - currently not indexed means Google read the page and passed on it. URL blocked by robots.txt and URL marked ‘noindex’ are self-explanatory and are the two worth ruling out first, because either one hides the page completely.

How long does it take Google to index a new Lovable site?

Google’s documented window is a few days to a few weeks; Lovable’s is a few hours to a few days, and sometimes longer, depending on the crawl schedule and the site’s authority. Requesting a recrawl repeatedly does not shorten either one, because Google applies a quota to individual URL submissions and says asking again for the same URL will not get it crawled any faster.

My SEO checker says my page is empty. Does Google see an empty page too?

Probably not, and the checker is the wrong witness. Lovable’s hosting documentation says third-party SEO scanners are not verified crawlers and can report an empty page while Google, social platforms and AI search engines get the full content. Settle it with URL Inspection in Search Console, whose View crawled page panel shows the raw HTML Google actually received from your address.

Do I need a prerendering service for a Lovable site?

On Lovable hosting, the vendor’s documented answer is no for both search engines and AI crawlers. If you have moved the frontend somewhere else, rendering becomes a property of the new host and framework, and the answer depends on what you moved to.

Will moving off Lovable fix my indexing?

Only the rendering half, and on Lovable hosting that half is already done. A new host does not write your titles, your canonical URLs, your sitemap or your crawler rules, which is where the problem usually lives. Whether to move is a bigger question than indexing, and when moving off an AI builder is worth it weighs it properly.