Back to blog

Lovable SEO Update (May 2026): TanStack SSR, Prerendering, SEO Review, and Semrush — Honest Breakdown

5/14/2026·by Aki from LovableHTML

Lovable just officially announced four SEO features. Three share the same limitation — they only work for static pages. Here's what each one actually fixes, what's still broken on dynamic content, and what it means for your site.

Lovable.dev shipped four SEO features this week. Three of them share the same architectural limitation: they only run at publish time, on static pages. If your site has a CMS-driven blog, a directory, or anything fetched at runtime, the update largely passes you by.

Update (May 14, 2026, evening): Multiple users on r/lovable and X are now reporting that the new native prerendering isn't actually returning rendered HTML — Googlebot-UA requests are still hitting empty <div id="root"> shells, even on the static homepage and marketing pages the feature was supposed to cover. If the reports hold up, the announcement landed before the feature actually shipped to production. We're tracking the threads and will update this post as Lovable responds. If you're on Lovable, run the curl test below on your own domain to confirm what your site is serving right now.

Lovable announced a batch of SEO-related features that the community has been asking about for over a year:

1. TanStack Start SSR — now officially supported (the rollout that quietly started in April is confirmed).
2. Native prerendering for sites on the old Vite SPA stack.
3. An SEO & AI search review that audits your site from inside the Lovable builder.
4. A Semrush connector for keyword research and "build a landing page" suggestions in chat.

This is the first time Lovable has officially put SEO infrastructure on the roadmap, and that matters — the SEO problem on Lovable has been the loudest open complaint in the community for over a year. But three of the four features ship with the same caveat — they're static-page only. Anything dynamic (CMS blogs, directory listings, database-driven catalogs, anything pulled from an API at runtime) sits on the wrong side of the line. Here's the honest read.

TL;DR

• TanStack SSR is now official — but it's still selective SSR, and most projects users spin up today are still being created on the old Vite + React Router stack. In our own testing this week, every fresh Lovable project we created (4–6 across multiple days) came out on the old stack — not one shipped TanStack Start by default. Same caveats as the partial rollout I covered last month.
• Native prerendering is the biggest win — but only for static pages (those written into your project as code). Any page pulling content from a CMS, database, or API at runtime — blogs, directories, dynamic catalogs — stays client-rendered and stays invisible to crawlers.
• SEO review is a useful in-builder audit — but it only inspects the static pages Lovable can see at publish time. Dynamic routes aren't deeply analyzed.
• AI search visibility (the structured-markdown + semantic-HTML claim) also runs at publish time. Same limitation: static pages get the treatment, dynamic ones don't.
• Semrush connector is convenient and needs no Semrush account — but in our testing, each invocation costs 10 Lovable credits (Lovable's page says "regular build credits" without naming a number).
• Net effect: SEO for Lovable just got materially better for static-only sites. For content-driven sites and AI visibility (ChatGPT, Perplexity, Claude) on dynamic routes, most teams still need a runtime prerender layer.

1. TanStack Start SSR — officially official, for new projects only

The rollout that started in April 2026 is now public. Lovable confirmed they're shipping new projects on TanStack Start with server-side rendering. Existing projects do not get SSR — Lovable's own FAQ explicitly rules it out: "Existing projects get pre-rendering automatically. Full SSR is currently only available for new projects built on TanStack Start."

The catch, which still applies after the official announcement:

• Selective SSR is the default. TanStack Start lets each route opt into SSR, CSR, or hybrid rendering. Lovable's generator currently treats most routes as hybrid — meaning crawlers get the route shell, but the content of the page (hero copy, pricing, testimonials, anything fetched from a hook) may still hydrate after JavaScript runs.
• The new template isn't the default for everyone yet. Most projects users spin up today are still going out on the old Vite + React Router stack. In our own testing across 4–6 fresh projects this week, none of them shipped on TanStack Start — every single one came out on the old Vite + React Router template. Lovable hasn't published a timeline for the new stack becoming universal.
• No migration path for existing projects. If your site was built before the rollout, you're on the Vite SPA stack and you stay there. Existing projects get the new native prerendering (see section 2 below) but not full SSR. The only way to land on TanStack Start today is to start a new project from scratch.

How to tell which stack your Lovable project is on

Two checks, neither takes more than 30 seconds:

1. File-system check (most reliable). Open your project's /src directory. If you see router.tsx and routeTree.gen.ts, you're on TanStack Start with SSR. If you only see App.tsx + main.tsx and a react-router-dom import (or BrowserRouter/Routes in your App.tsx), you're still on the Vite + React Router stack.

2. View Source check. Open your live site, right-click → View Source (not Inspect Element — that lies to you by showing the rendered DOM). Search for your hero copy, pricing copy, and anything else you want indexed. If those strings aren't in the raw HTML, those sections are still being rendered client-side regardless of which stack you're on.

For the full breakdown of what selective SSR means for crawlers, see Lovable vs WordPress for SEO and content.

2. Native prerendering — real, but static-only (and maybe not even that, yet)

This is the announcement most Lovable users have been waiting for, and on paper it's a legitimate win — with a sharp architectural limitation, plus an early signal that the feature may not yet be working in production at all (see the update at the top of this post).

What Lovable says the feature does: when you publish, Lovable prerenders the static routes in your project into HTML and serves that HTML to crawlers. Static = pages that exist as code in your project — your homepage, your /about, your /pricing, your /features. These should get clean HTML on first request. Googlebot would be happy. Social link previews would finally work.

What users are actually reporting (May 14): even on freshly-published static pages, Googlebot-UA curls are still coming back with empty <div id="root"> shells. If that holds up, the announced feature shipped to the marketing page before it shipped to the rendering pipeline. Verify on your own site with the curl test below before you assume your homepage is now indexed.

What it doesn't do: dynamic content is still broken.

For a marketing-only site with a handful of static pages, this is enough. Lovable's prerendering will get you indexed, get your link previews working, and remove the worst of the SPA SEO penalty.

For anything content-heavy, anything with a blog connected to a headless CMS, anything pulling product data from an API — the dynamic pages still ship as <div id="root"> to crawlers. They still take days or weeks to get indexed by Google. They are still completely invisible to AI crawlers like OAI-SearchBot, PerplexityBot, and ClaudeBot, which don't execute JavaScript at all.

Why this matters more than it sounds

The pages most Lovable site owners actually want indexed — the blog posts driving organic search, the directory entries that match long-tail queries, the dynamically-generated landing pages — are exactly the pages Lovable's native prerendering doesn't cover.

You can verify this on your own site: take a dynamic URL from your Lovable site (a blog post pulled from a CMS, a product page), curl it with a crawler user agent, and look at what comes back:

curl -A "Googlebot" -L https://yoursite.com/blog/some-post

If you see your content, great — that route is being prerendered. If you see <div id="root"> with no real content, you're still on the wrong side of the SEO line for that page.

For full-site prerendering that catches both static and dynamic content — including pages that fetch from a CMS or an API at runtime — you need a runtime prerender layer that intercepts crawler requests and renders on-demand. That's what LovableHTML does at the DNS level: every route on your domain, static or dynamic, gets clean HTML for crawlers. No build-time gymnastics, no "I need to refactor my data fetching" rewrites.

3. SEO & AI search review — useful, but static-only

Lovable now ships an in-builder SEO & AI search review. Trigger it from chat and Lovable audits your site for the common technical SEO issues — performance, metadata, heading structure, image alt text, canonical tags, Open Graph tags, robots, sitemap — and offers one-click fixes that consume your regular build credits.

For a marketing-only Lovable site, this is genuinely useful. Free on every plan, including the free tier. Same one-click-fix workflow as the rest of the Lovable builder.

Where it stops being useful: dynamic pages. Lovable's review inspects your project the same way Lovable's prerendering renders it — at publish time, against the static routes Lovable can see in code. Pages whose content is fetched at runtime from a CMS, database, or API aren't deeply audited. The review will tell you your homepage has the right meta tags. It won't tell you whether your individual blog posts at /blog/[slug] are returning empty HTML to Googlebot.

That's not Lovable's fault — auditing dynamic pages requires a crawler running from outside the builder, hitting your live URLs as Googlebot would. It's a different category of tool. (It happens to be what LovableHTML's SEO Spider does: full-site crawler-based audit covering 30+ technical issues across every route, static or dynamic.)

4. Semrush connector — handy, costs real credits

The fourth feature in the batch: Lovable now integrates with Semrush so you can run keyword research and ask "what should I rank for?" directly inside the Lovable chat.

The mechanics:

• No Semrush account required. Lovable handles the authentication on the backend — you don't need to bring your own seat.
• Each invocation costs 10 Lovable credits — we measured this in our own testing. Lovable's marketing page describes it as "regular build credits" without naming a number; in practice, asking Semrush a question consumes 10 credits per call. A serious keyword research session — pulling rankings, competitor analysis, suggestion lists — can burn through credits faster than building a feature.
• Free promotional window through August 15, 2026. Lovable is currently waiving the credit cost during the launch period. After August 15, expect the 10-credit-per-call cost to kick in.

Honest take: the Semrush connector is a quality-of-life feature, not an SEO feature. It doesn't make your site easier to find. It makes it easier to plan content from inside Lovable instead of context-switching to Semrush in another tab. For light keyword research it's fine and currently free. For heavy ongoing use, the credit math eventually pushes you back to using Semrush directly (or a free alternative like Google Search Console + Ahrefs Free).

What this means if your site is on Lovable today

The decision tree got a little simpler after this announcement, but it still has branches. Here's how to read it:

If your Lovable site is static-only — marketing pages, a portfolio, a few content pages written into the project as code:

Lovable's native prerendering plus an SSR migration (if/when you get bumped to the TanStack template) is probably enough. Verify your pages are actually being rendered by running them through a crawler simulator or curl with a Googlebot user agent. If your content shows up, you're set.

If your Lovable site has dynamic content — a blog from a headless CMS, a directory pulled from Supabase, products from an API, anything generated at runtime:

Lovable's native prerendering will not cover those pages. You have two real options:

1. Rebuild the dynamic routes as static by pre-fetching all content at build time. This works if your content changes infrequently (a few times a month) but breaks down fast at scale.
2. Add a runtime prerendering layer that intercepts crawler requests and renders any route — static or dynamic — to clean HTML. This is what LovableHTML does. DNS-level setup, no code changes, no rebuild required, covers every route on your site.

If you care about AI visibility (ChatGPT, Perplexity, Claude citations):

Lovable's announcement page claims AI search optimization via "structured markdown output, semantic HTML, and structured data." Important fine print: this runs at publish time, same as the other features — so it applies to static pages only. AI crawlers like OAI-SearchBot, PerplexityBot, and ClaudeBot mostly don't execute JavaScript, which means dynamic routes still ship as empty shells to them regardless of how clean the static-page markup is. If your blog or directory is where you'd want to be cited, a runtime prerender is still the only path.

For the full technical picture of how AI crawlers behave on React sites, see How to Get Your Pages Indexed by ChatGPT, Perplexity, and Other AI Search Engines.

The unifying pattern: static-only

Three of the four announced features — prerendering, the SEO review, and the AI-search-visibility markup — all run at the same moment in the lifecycle: publish time, against the static routes Lovable can see in your project's code.

Build-time/publish-time tooling is the easy half of the SEO problem. It's what every static site generator has done for a decade. Runtime prerendering of dynamic content — pages whose HTML depends on data fetched at the moment of the request — is the hard half, and it's the half that matters most for content-driven sites, AI visibility, and any project past a handful of static pages.

This is the first time Lovable has officially shipped SEO infrastructure, and it's a real shift in priorities at the company. Acknowledging the problem publicly with four named features is meaningful. But two architectural realities still hold: at publish time, Lovable can only render what it can see — anything fetched at runtime stays invisible — and as of May 14 evening, early Reddit reports suggest the publish-time pipeline itself may not yet be returning rendered HTML even for the static pages it was supposed to cover.

The optimistic case is that Lovable just made SEO better for small static sites. The realistic case is that they made an announcement and the implementation is still catching up. Either way, for anything with dynamic content — CMS-driven blogs, directories, runtime-fetched anything — the case for a runtime prerender layer is the same or stronger than it was last week. Lovable's own update has now mapped exactly where the gap sits.

Frequently asked questions

Does Lovable's new prerendering work for blog posts pulled from a CMS?

No. Lovable's native prerendering is build-time, meaning it only catches pages that exist as static routes in your project at publish time. Blog posts fetched from Sanity, Contentful, Notion, Supabase, or any other headless source at runtime are not prerendered and remain invisible to crawlers. (Separately, as of May 14 evening users are reporting that even static pages aren't currently being served as rendered HTML — see the update at the top of this post.)

What about ChatGPT and Perplexity — do they see the new prerendered pages?

For static pages, yes — the same HTML served to Googlebot is served to AI crawlers like OAI-SearchBot, PerplexityBot, and ClaudeBot. For dynamic pages, no — those remain client-side React and AI crawlers don't execute JavaScript.

How do I know if I have the new TanStack Start template?

Open your live site, right-click → View Source (not Inspect Element). If your visible content is in the HTML response, you have at least partial SSR. If you see only <div id="root"> and a bundle import, you're still on the Vite SPA stack. You can also run your URL through our Crawler Simulator to see exactly what Googlebot and AI crawlers receive.

Does Lovable's SEO review cover my dynamic pages?

No. The in-builder SEO review inspects the static routes Lovable can see at publish time — your homepage, your /about, your /pricing, etc. Pages whose content is fetched from a CMS, database, or API at runtime aren't deeply analyzed. To audit dynamic routes you need a crawler-based audit that hits your live URLs from outside the builder, like LovableHTML's SEO Spider.

Is the Semrush connector worth using?

It's currently free through August 15, 2026, with no Semrush account required — so for light keyword research while the promo is running, it's a clear win. After that, in our testing each invocation consumes 10 Lovable credits, which adds up fast for ongoing research. The same data is available in dedicated SEO tools or Google Search Console for free.

Do I still need LovableHTML if I'm on the new prerendering?

If your site is genuinely static — marketing pages only, no CMS, no database-driven content — Lovable's native prerendering may be enough. If you have a blog from a headless CMS, a directory, a catalog, user-generated content, or anything fetched at runtime, you still need a runtime prerender layer to make those routes crawlable. LovableHTML covers every route on your domain, static or dynamic, with a DNS-level setup that takes 5–10 minutes.

What changed compared to the partial SSR rollout in April?

The April rollout was unannounced, partial, and inconsistent across accounts. The May 14, 2026 announcement makes the rollout official, opens migration requests for existing projects, and adds three adjacent features (native prerendering, SEO & AI search review, Semrush connector). The fundamental architecture is the same — selective SSR with TanStack Start, plus publish-time tooling for everything else — and the partial-rollout caveats still apply: most new projects are still being created on the old Vite SPA template.