Short version

New Lovable sites have served Google full HTML since May 13, 2026, because they run with server-side rendering. Older projects get pre-rendering for search engines. On our new test site, a sitemap, canonical URLs and structured data were still missing. An AI agent fixed that with one message through the Lovable MCP server, reviewed the code change, published and checked the live site again. Choosing keywords, confirming business facts and the share image stay human work.

Lovable SEO is less of a problem than many guides claim, but the work is not done once the site is built. A new Lovable site serves Google full HTML. What is often missing are the basics that help search engines: a sitemap, a canonical URL on every page and structured data about your business. An AI agent can add those pieces to your Lovable project on its own.

I tried that on a new test site in Lovable, a fictional bakery in Ghent, Belgium. Our agent checked the published site, sent Lovable one bundled instruction, reviewed the code change, published and checked the live HTML again. Below you see what Google got before and after, and what I deliberately did not leave to the agent.

Is Lovable good for SEO?

Many articles about Lovable SEO still describe an old situation. Lovable used to build React apps that only assembled their content in the browser, so a search engine first got an almost empty page. That no longer holds for new projects.

According to the Lovable SEO documentation, apps created from May 13, 2026 run on TanStack Start with server-side rendering. Every request gets fully rendered HTML, for people and for crawlers. Older React and Vite projects get pre-rendering: when a verified crawler from Google, Bing or an AI search engine arrives, Lovable renders the page on the server and returns that HTML.

Our test confirmed it. The test site Lovable built for us is a TanStack Start app. A plain curl without JavaScript returned the page title and the h1 right away. Every page also had its own title and meta description.

Being readable is not the same as being findable, though. Lovable itself says that every new project gets a robots.txt file, but not always a sitemap, and that the starting metadata is generic. According to the same documentation, the review in Lovable does not fully evaluate content, search intent, competitors or backlinks. That is where the real work is.

What was missing on a new Lovable site?

For the baseline, the agent checked the published test site with a few fixed curl checks: robots.txt, sitemap.xml and, for each page, the title, the canonical URL, the Open Graph tags and any JSON-LD. This is what the agent found:

  • No sitemap: /sitemap.xml returned a 404, and robots.txt did not point to a sitemap.
  • No canonical URL and no og:url on any of the three pages.
  • No structured data. For a bakery with an address and business hours, a Bakery block is the logical choice.
  • The same share image on every page: Lovable automatically puts a screenshot of the project in og:image.

None of these issues block Google. They do make it harder for Google to find your pages quickly, pick the right URL and understand your business details. On a three-page site, that is a minor issue. On a site with dozens of pages, a blog or several languages, it becomes a real problem.

How does an AI agent update your Lovable site?

Lovable has an official MCP server at mcp.lovable.dev. It lets an external AI agent, such as our agent Hermes, read projects, send messages to Lovable, fetch the code change and publish. So the agent does not edit the code directly. It gives Lovable a precise instruction and checks the result. This is how the workflow ran:

  1. Baseline on the live siteThe agent fetches robots.txt, the sitemap and the HTML of every page and notes what is missing. Free read actions come first, so no credits are wasted.
  2. One bundled instructionAll changes go to Lovable in a single message, with clear limits: no changes to the design or visible copy, and no facts that are not on the site.
  3. Review the code changeThe agent fetches the diff and checks whether Lovable did what was asked, and nothing more.
  4. Publish and measure againAfter publishing, the same checks run again on the live site. Only then does a change count as done.
  5. Request indexingOn a real client site with its own domain, the sitemap goes into Search Console and the changed pages get an indexing request. We deliberately skipped that for the test site on lovable.app.

In our test, the message to Lovable cost 1.3 credits. The free Lovable plan gives you only a few, so bundling pays off. The agent read the files first with the free read actions of the MCP server and only then sent one instruction.

The real run: before, instruction, diff and after

Below is the complete run from November 14, 2026, exactly as the agent ran it: the baseline on the published site, the message to Lovable, the final answer from Lovable, the full code change and the same checks after publishing. Nothing is shortened or rewritten.

After publishing, /sitemap.xml returned a 200 with a valid XML sitemap of the three pages. The sitemap was listed in robots.txt, every page had a canonical URL and an og:url pointing to itself, and the home page had a Bakery block with the address and business hours from the page. Monday is marked as closed with 00:00 to 00:00, as Google specifies in its local business guidelines.

What else the diff showed

Reviewing the diff is not a formality. Lovable did more than it was asked. It also added og:type and twitter:card to every page, wrote a new rule into its own AGENTS.md file, created a roadmap.md file and added a test file. The sitemap is also not a fixed list but is built from the routes of the app. A new page shows up in it automatically, as long as the code marks it as public.

Here, all of that is harmless, and the test on the business hours is even useful. On a client site, though, you want to see such extras before you publish. That is why the agent reviews every diff and notes what fell outside the instruction.

What does the agent do, and what stays human work?

An agent is strong at recurring work: running checks, sorting findings, writing one clear instruction, checking the change and measuring again. That is exactly the work that tends to get skipped on Lovable sites, because the site looks finished as soon as it is built.

I deliberately keep other decisions away from the agent:

  • Which keywords and pages matter. That takes knowledge of your customers and your offer.
  • Whether the facts are right. The agent only used details that were already on the site. On a real site, someone has to confirm the address and business hours.
  • The share image. In the test, og:image stayed an automatic screenshot. A good image for each page is design work.
  • The copy and the decision to publish.

That is also how our SEO AI agent works for clients: the agent prepares and carries out work within clear limits, everything is documented, and we check what goes live.

Lovable’s own review or an external agent?

Lovable has its own SEO and AI search review on the SEO & AI tab in Analytics. It checks the sitemap, robots.txt, metadata, structured data and canonical URLs, among other things, and can fix most issues in one click. For many small sites, that is a fine start. An external agent mainly adds value when you want more than a technical check.

AreaSEO review in LovableExternal AI agent via MCP
Technical checksSitemap, robots.txt, metadata, structured data, canonical URLsThe same basics, plus its own checks on the live HTML
ChangesTry to fix per finding or for all of them at onceOne bundled instruction with limits, then a diff review
Content and search intentNot fully, according to its own documentationBased on Search Console data and keyword research
Follow-upA new scan whenever you start oneA fixed cycle: measure, change, measure again
Who decidesYou, in the editorYou or we, after a documented proposal

So do use the Lovable review. If you want someone to follow your search traffic over time, match your copy to search intent and document every change, an agent with human oversight is the next step. If your site started as an AI design and you want it turned into a fast site of your own, take a look at turning an AI design into a website.

How do you get a Lovable site indexed by Google?

A sitemap only helps once Google reads it. So put your Lovable site on its own domain. Lovable itself says that a lovable.app address works well for demos and tests, but that you build search presence on a domain you own.

  1. Connect your own domain in Lovable and set it as the primary domain.
  2. Verify that domain in Google Search Console. Lovable has its own connector for this.
  3. Submit your sitemap and check that all public pages are in it.
  4. Use URL Inspection to request indexing for your most important pages.
  5. After a month, check again which pages are indexed and which searches they show up for.

If you want to keep up that rhythm without doing everything yourself every month, my guide on automating SEO with AI shows how such a cycle with an agent fits together.