Lovable SEO Settings: The Checklist Behind a Site That Actually Indexes

Quick answer: a Lovable project created on or after 13 May 2026 is server-rendered, so Google already receives full HTML and the old advice about making the page visible to crawlers no longer applies. What decides whether the site indexes cleanly is the work Lovable does not do for you: a unique title, description and canonical on every route, one URL form with a trailing slash, a sitemap served as a real route rather than a page, a robots file that allows the crawlers you want, and a Search Console property on the published domain. Lovable's own documentation, read on 19 September 2026, says you do not need an external pre-rendering service and do not need an llms.txt file. This is the checklist I used to move 101 URLs onto Lovable with zero broken links, with the prompts to paste.

Check which stack your project is on before you touch anything

Lovable runs two architectures, and the SEO work differs for each. The documentation is precise about the split: "New Lovable apps created from May 13, 2026 use TanStack Start with server-side rendering (SSR)." Older projects run React with Vite, and for those Lovable serves what it calls on-request pre-rendering to verified crawlers, listed as Google, Bing, social-preview bots, and "AI engines like ChatGPT, Perplexity, Claude, Gemini". Everyone else, in Lovable's words, sees "the regular single-page app".

Find out which you have by asking the project chat a plain question: "What stack is this project on?" Lovable's upgrade documentation recommends exactly that. If the answer is React and Vite, you can move to TanStack Start from the same chat. Lovable says the upgrade "typically costs 10-35 credits", runs one project at a time, carries over "page titles, descriptions, social preview tags, and analytics scripts", and can be reverted from version history. The published site does not change until you republish, so you inspect the result in preview first. Lovable warns that some browser-dependent libraries may break server rendering, so test after upgrading.

Why upgrade a project that already pre-renders for Google? Because pre-rendering is conditional and server rendering is not. With TanStack Start every request, from a browser, a link previewer or an unverified crawler, gets the same finished HTML, which removes the whole class of "my tool says the page is empty" tickets I covered in why a vibe-coded site is not ranking. Lovable's own blog reports "an increase by 2.9% in organic search traffic for apps using pre-rendering and 98.5% in traffic from AI tools like ChatGPT and Perplexity" for existing apps; those are Lovable's numbers, not mine. Nothing below costs credits except Try to fix and the upgrade itself, so the list is the same whether you are on a paid plan or building on Lovable without burning credits.

What the free SEO and AI search review checks, and what it cannot see

Lovable ships a review panel under More, then SEO and AI search. Press Scan project the first time and Scan again after that. The documentation states that "Running an SEO and AI search review is free on all plans", that "Applying fixes with Try to fix uses regular message credits", and that "Semrush-powered SEO research has no additional cost through September 15, 2026". Two lines matter for sequencing: "Only publicly published apps can be indexed by search engines" and "Additional checks become available after your site is publicly published." Scan before publishing to catch code problems, publish, then scan again for the published-site checks.

Check	Passing finding in Lovable's panel	What a failure means for indexing
Indexing meta tags	"Home page is reachable"	A noindex tag or a blocked homepage. Fatal, and often left over from a "do not index the preview" instruction.
robots.txt	"Crawler rules look good"	File missing or blocking. Google treats a missing file as allow-all, so a wrong file is more dangerous than no file.
Sitemap	"Sitemap looks good"	Invalid XML, placeholder routes, relative URLs or a host that does not match the published domain.
Metadata	"Page metadata describes the site clearly"	Duplicate titles, placeholder text or weak descriptions. The most common failure on a fresh project.
Open Graph	"Social link previews look good"	"Shared links still show Lovable's branding" until og tags are set per route.
Structured data	Rich results markup present	JSON-LD that cannot be parsed, does not match the page, or is incomplete.
Content structure	"Homepage content and structure well-optimized"	"H1 is missing or too generic".
AI readiness	"AI assistants can see your site as Markdown"	A positive-only check. There is no failure state to fix.

The review is a good first pass and a poor last one. It leaves out page speed, content quality, search intent, competitors and backlinks, and it runs against the project as Lovable sees it, not against what Googlebot fetched from your domain. The last check is always URL Inspection in Search Console, where Google's JavaScript SEO guidance tells you to "look at the rendered HTML".

Per-route titles, descriptions and canonicals: the prompt to paste

This is where most Lovable projects are wrong. A single-page app ships one index.html with one title, and a project upgraded from that era often still carries one static tag set. TanStack Start fixes the mechanism: each route file can export a head function that returns a meta array for title, description and Open Graph, a links array for the canonical, and a scripts array for JSON-LD. The framework's SEO guide calls head "your primary tool for SEO" and shows it reading loaderData, so a blog post's title and excerpt drive its own tags rather than a hard-coded string.

You do not need to write that code. Paste this into the project chat, adjusting the domain:

"For every route in this project, add a head export that sets a unique page title under 60 characters, a meta description under 155 characters written from that page's own content, a self-referencing canonical link that uses https://www.example.com with a trailing slash, and og:title, og:description, og:type and og:image values for the page. Read the values from the route's loader data where the page is dynamic, such as blog posts and category pages. Add a JSON-LD script of type Article for blog posts and WebPage for other pages, with the same title and description as the meta tags. Do not set the same title or description on two routes, and do not use the preview domain anywhere in a canonical or Open Graph URL."

Then check three things in the published HTML, not the preview. The canonical must name the production domain; one that still points at a preview host tells Google the copy on your own domain is the duplicate. The homepage title and every inner page title must differ, which is the single most common metadata failure the review reports. The Open Graph image must be an absolute URL, because, as Lovable's blog puts it, social previewers "read meta tags from the HTML directly, so a client side-rendered app shows a generic preview even when the page has perfectly good title and description tags set per page".

If you are choosing a builder rather than fixing one, this per-route control was one axis in my Lovable versus Webflow comparison for client sites and the wider look at AI website builders: Webflow exposes the fields in a panel, Lovable gives them to you when asked.

Trailing slashes and the twin URL problem

Pick one URL form and make the framework enforce it. TanStack Start has a trailing-slash setting; I run this site with slashes always on, because that is what the WordPress URLs had and I wanted 101 addresses to stay byte-identical through the move. The choice matters less than consistency, because every route that answers at two addresses is a duplicate pair Google has to resolve.

Here is the behaviour to know about. On my build, static prerendered pages answer 200 at the no-slash address as well as the slash address, with no redirect between them. That is harmless only because the no-slash copy carries a canonical pointing at the slash URL, so Google consolidates the pair without being asked. If your canonicals are missing or wrong, the same behaviour produces the Search Console status I unpack in the post on duplicate pages without a user-selected canonical: Google picks one twin for you, and it may not be the one your internal links use. Practical rule: every internal link uses the form you chose.

Sitemap and feed URLs need to be server routes, not pages

This is the item I learned the hard way and have not seen in another guide. With trailing slashes enforced, the framework's redirect to the slash form runs before any route loader. A route defined as a page at /sitemap.xml never gets to return XML: the request is redirected to /sitemap.xml/ first, and Google's fetcher receives a 307 and then an HTML page. The same happens to an RSS feed.

The fix is to define those URLs as server routes, which answer at the request level before the page router applies its rules. On this site both the sitemap and the feed are server routes, the sitemap is generated from the same content index the pages use, and the prerender list comes from that index too, so a post that exists is in the sitemap and is prerendered, and a post that does not exist is in neither. Lovable's review checks the sitemap for "invalid XML, placeholder routes, relative URLs, and host mismatches", and its documentation adds the sequencing point: "Google fetches the sitemap from your live site, so unpublished routes won't be submitted." Publish, then submit.

When you ask Lovable for the sitemap, state the constraint: "Serve sitemap.xml and the RSS feed as server routes so the trailing-slash redirect does not apply to them, generate the URL list from the same data the pages use, and use the production domain with trailing slashes in every entry." Then fetch the published sitemap and confirm it is XML with a 200 status.

robots.txt: where it lives and what to allow

A static file in the project's public folder is served at the domain root, the only location Google honours. Two decisions go into it. The first is what to disallow, and for most Lovable sites the answer is nothing: there is no admin area, and the server-function paths the app calls should stay open. Google's robots documentation is blunt that the file "is not a mechanism for keeping a web page out of Google" and that a page disallowed in robots.txt "can still be indexed if linked to from other sites", so anything you want out of the index needs a noindex tag, not a robots rule.

The second decision is which AI crawlers to allow, which is policy rather than engineering. On this site I chose to allow every named search and AI crawler explicitly, with a group for each of 63 user agents and an allow-all catch-all, because the site exists to be cited. The bot list, the reasoning, and the case for blocking some of them on a publisher site are in whether you should block AI crawlers. Whatever you decide, put the sitemap line in the file with the full production URL, because Google says the sitemap address "must be a fully-qualified URL".

One Lovable-specific note: on older React and Vite projects a robots.txt that allows a crawler does not make Lovable serve it the pre-rendered page. Those are two different gates. On TanStack Start there is one gate, because everyone gets the same HTML.

Structured data and Open Graph, per route and matching the page

The review flags "existing JSON-LD that cannot be parsed, does not match the visible page, or is incomplete", and the middle clause is the one to respect. Structured data that describes a page differently from its visible text is worse than none. Generate the JSON-LD from the same data as the meta tags, which the head prompt above already does, and keep the types honest: Article for posts, WebPage for static pages, FAQPage only where the questions are printed on the page, and never a rating block for something nobody rated.

Lovable's documentation says generic markup "is not required", which is correct; where it earns its place is the FAQ and article types that map onto real page content, the blocks answer engines lift most readily. For Open Graph the documentation's line is the whole rule: "unique og:title, og:description, and og:image values per route".

Connect Search Console and set the right expectation

Connect a custom domain first; Lovable's FAQ puts it plainly: "A custom domain helps you build search presence on a domain you control." Then verify that domain in Search Console, submit the sitemap URL, and leave it alone. The review shows the connection state once the site is public. Lovable's estimate of what happens next is the one to give a client: 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." A new domain with no links pointing at it sits at the slow end for reasons that have nothing to do with Lovable, which is why the two Search Console statuses that frighten people most, Discovered and Crawled but not indexed, have their own posts on this site.

Use URL Inspection on three pages after the first crawl: the homepage, one dynamic page such as a post, and one you expect to be thin. Confirm the title, the canonical and the body text are in the rendered HTML. Google's guidance is 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 means the crawl phase already has your content, and the inspection confirms nothing in your code undid that.

What the host controls and you cannot

Some behaviours are Lovable's, and no project setting changes them. From the live checks I ran on this site after the cutover:

• The www form of the domain redirects to the apex with a 302, not a 301. Lovable sets this redirect; the project cannot change the status code.
• Static files served from the public folder carry no cache headers, and a _headers file in that folder is ignored.
• Chrome receives HTML and JavaScript uncompressed while other clients receive compressed responses, which shows up as a slower first paint in Lighthouse.

None of these stops a page indexing. They matter for performance scores, and the remedy, if one is needed, is a CDN in front of the host rather than a code change.

The 12-point Lovable SEO checklist

Step	What to do	How to verify on the published site
1. Stack	Ask "What stack is this project on?" Upgrade to TanStack Start if it is React and Vite.	View source: the article text is in the HTML, not an empty root element.
2. Custom domain	Connect your own domain before building links or citations.	Canonicals and sitemap entries use that domain.
3. Titles	Unique title per route, under 60 characters, from the page's own data.	No two pages share a title; the metadata check passes.
4. Descriptions	Unique description per route, under 155 characters, no placeholder text.	No duplicate-description warnings after the first crawl.
5. Canonicals	Self-referencing canonical on every route, production domain, chosen slash form.	No-slash and slash URLs point at the same canonical.
6. One URL form	Set trailing slashes once; write every internal link in that form.	Crawl the site; every internal link resolves without a redirect.
7. Sitemap	Server route, generated from the content index, production domain, published before submission.	The sitemap URL returns XML with a 200 status, not a 307 or an HTML page.
8. robots.txt	File in public, full sitemap URL, allow the crawlers you want, disallow nothing you need indexed.	The file loads at the domain root; the crawler check passes.
9. Open Graph	og:title, og:description and an absolute og:image per route.	A shared link previews your page, not Lovable's branding.
10. Structured data	JSON-LD generated from the same data as the meta tags; honest types only.	No unparseable or mismatched JSON-LD in the review.
11. Search Console	Verify the published domain, submit the sitemap, inspect three URLs.	Rendered HTML in URL Inspection shows title, canonical and body text.
12. Second scan	Run the review again after publishing and after any route change.	Published-site checks appear and pass.

The short version

On a Lovable project started after 13 May 2026, rendering is solved and the platform says so in writing: no external pre-rendering, no llms.txt, full HTML on every request. What is not solved for you is everything Google reads inside that HTML. Give every route its own title, description and self-referencing canonical on the production domain. Choose one slash form and enforce it in the framework and in every link. Serve the sitemap and any feed as server routes so the slash redirect cannot swallow them, generated from the same content index as the pages. Put a robots file at the root that allows what you want cited and links the sitemap. Then verify in Search Console, not in the editor. If the project is still on React and Vite, the upgrade removes the verified-crawler condition that makes third-party tools report an empty page. Everything here was read from Lovable's documentation and the framework's documentation on 19 September 2026, and the first-party checks are the ones I ran on this site after moving it.

Frequently asked questions

Does Lovable have built-in SEO settings?

Lovable has a free SEO and AI search review under More, then SEO and AI search, which scans indexing tags, robots.txt, sitemap, metadata, Open Graph, structured data and homepage structure, and can apply fixes with credits. There is no panel of per-page fields; titles, descriptions and canonicals live in each route's code, which you can ask the project chat to write.

Is a Lovable site server-side rendered?

Projects created from 13 May 2026 use TanStack Start with server-side rendering, so every request receives full HTML. Older React and Vite projects get pre-rendering served only to crawlers Lovable has verified. Ask the chat "What stack is this project on?" and upgrade from the same chat if needed.

How do I set a different title and meta description on each page in Lovable?

Ask the project to add a head export to every route that sets a unique title, description, canonical and Open Graph values, reading from loader data on dynamic pages. TanStack Start's head function supports a meta array, a links array for the canonical and a scripts array for JSON-LD. Verify in the published page source, not in the preview.

Why does my Lovable site show Lovable's branding when shared on social media?

The route has no og:title, og:description or og:image, or the image URL is relative. Social previewers read the tags straight from the HTML, and Lovable's review reports this as "Shared links still show Lovable's branding". Add per-route Open Graph tags with an absolute image URL and test one link in a chat app.

Does a Lovable site need a sitemap, and how should it be served?

Yes. With trailing slashes enforced, serve sitemap.xml and any RSS feed as server routes, because the framework's slash redirect runs before page loaders and would turn a page-based sitemap into a redirect. Generate the URL list from the same data the pages use, publish, then submit it in Search Console, since Google fetches the sitemap from the live site.

Do I need Prerender.io or another pre-rendering service for Lovable?

No. Lovable's documentation states that "Lovable-hosted projects do not need an external pre-rendering service for search engines or AI crawlers." Newer projects are server-rendered for every request, and older ones are pre-rendered for verified crawlers. If a tool shows an empty page, check the live URL in Search Console before paying for a service.

Does Lovable need an llms.txt file for AI search?

Lovable says no: "Lovable does not require llms.txt, and the SEO & AI search review does not treat a missing file as a problem." Its AI readiness check confirms that assistants can read the site as Markdown. You can add one, and this site does, but it is not a condition of being read or cited.

How long does it take for a Lovable site to appear on Google?

Lovable's documentation says 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." A new domain with no inbound links sits at the slow end. Publishing, submitting the sitemap and verifying Search Console are the only steps that speed it up from your side.

How much does the TanStack Start upgrade cost in Lovable?

Lovable's documentation says the upgrade "typically costs 10-35 credits", that anyone who can edit the project can start it on any plan, and that titles, descriptions, social tags and analytics scripts carry over. You can revert from version history, and the published site is unchanged until you republish.

Why do my no-slash and slash URLs both return 200 on Lovable?

Static prerendered pages on the host answer at both forms without a redirect. That is harmless when each copy carries a canonical pointing at your chosen form, because Google consolidates the pair. It becomes a duplicate problem only when canonicals are missing or point at the preview domain.

Transparency: every statement about Lovable's behaviour in this article was read from Lovable's own documentation and blog on 19 September 2026, and the TanStack Start details from the framework's documentation the same day. The migration described is this site, which I own, and the checks quoted were run on it after the cutover. Where Lovable publishes nothing, this article says so rather than substituting an estimate. I build and repair Lovable sites for clients, which is a commercial interest you should weigh when reading the recommendations above. There are no affiliate or tracking links on this page.

About the author. Ashikur Rahman is a solo SEO and AI search specialist who has worked in search since 2017, with an LLB and an LLM in International Law and a practice focused on medical, dental and legal businesses. He migrated this site, 101 URLs, from WordPress to Lovable and TanStack Start in September 2026 and published the method. He runs Proximity Ranker and writes at hey-ash.com.