Lovable SEO in 2026: What Lovable Fixed, What It Didn't, and When to Move to Next.js

Quick answer: Lovable is much better for SEO than it was a year ago. According to Lovable's documentation, apps created from 13 May 2026 run on TanStack Start with server-side rendering, and older React + Vite apps hosted on Lovable are pre-rendered for verified search and AI crawlers. What Lovable still leaves to you: unique metadata for every page, structured data, a complete sitemap, internal linking and content worth ranking. And if you exported the code and host it yourself, none of Lovable's fixes apply. That last case is where most Lovable SEO problems live now.

I have a personal stake in this one. The site you are reading started life in December 2025 as a Lovable project, exported to GitHub and deployed on Vercel. In 2026 I moved it to Next.js. This guide covers what changed on Lovable's side since then, how to tell which situation your app is in, and when a migration is worth the effort.

Key Takeaways

• Lovable apps created from 13 May 2026 (later on Enterprise plans) are server-rendered: every request returns full HTML.
• Older React + Vite apps get on-request pre-rendering, but only on Lovable hosting and only for verified crawlers. Human visitors still get the single-page app.
• A Lovable app you exported and host on Vercel, Netlify or anywhere else gets none of this. Crawlers that do not run JavaScript see an empty page.
• Rendering makes pages readable, not rankable. Metadata, sitemaps, structured data, internal links and content are still your job.
• Moving to Next.js makes sense for content-heavy sites, multiple languages or when you have outgrown Lovable. For a small site on Lovable hosting, fixing metadata is usually enough.

What Lovable changed in 2026

Until this year, every Lovable app was a client-rendered React single-page app built with Vite. The server sent a nearly empty index.html, and the content only appeared once the JavaScript bundle ran in the browser. Google can render JavaScript, but rendering is a separate step that can happen later than the crawl, and many other crawlers never do it.

Lovable's SEO documentation now describes two fixes:

• Server-side rendering for new apps. Apps created from 13 May 2026 (22 June 2026 on Enterprise plans) use TanStack Start. Every request returns fully rendered HTML, for people and crawlers alike.
• Pre-rendering for older apps. Existing React + Vite apps are pre-rendered when a verified crawler requests a page: search engines, AI search crawlers, social preview bots and verified SEO tools. Everyone else still gets the normal single-page app.

You can also upgrade an existing project to TanStack Start from inside Lovable. According to the docs, the upgrade leaves your published site unchanged until you publish again.

Lovable has added an SEO and AI search review as well. It creates a robots.txt for new projects, though not always a sitemap, and it flags the generic metadata every project starts with. Those are useful defaults, but the docs are clear that each page still needs its own Open Graph tags.

Which kind of Lovable app do you have?

Most of the confusion about Lovable SEO comes from people describing different setups. Find yours first.

Three ways to check:

1. Look at the code. A src/routes/ folder with a __root.tsx file and a generated routeTree.gen.ts means TanStack Start. A src/main.tsx that mounts an App component with React Router means the older client-rendered setup.
2. Use Search Console, not View Source. On Lovable hosting, older apps are only pre-rendered for verified crawlers, so View Source in your browser shows the empty shell even when Google gets full HTML. In Search Console, run URL Inspection on a page, choose Test live URL, then View tested page to see the HTML and screenshot Google actually got.
3. Fetch the page raw. For a self-hosted app, curl -s https://yourdomain.com/pricing | grep "a sentence from that page" tells you whether the text is in the HTML. If it is not, any crawler that skips JavaScript sees nothing.

Why the self-hosted export is the trap

Lovable's pre-rendering is a feature of Lovable's hosting. The documentation only covers Lovable-hosted projects. If you exported an older app to GitHub and deploy the Vite build to Vercel or Netlify, which is exactly what I did with this site, you are back to a classic client-rendered SPA. That has three consequences:

• Google indexes you later and less reliably. Googlebot renders JavaScript, but every page's content depends on that rendering step succeeding. Slow scripts, blocked resources and runtime errors all turn into missing content.
• AI search cannot see you. Vercel's analysis of AI crawler traffic from December 2024 found that none of the major AI crawlers execute JavaScript, including OpenAI's GPTBot, OAI-SearchBot and ChatGPT-User, and Anthropic's ClaudeBot. They fetch HTML and read what is in it. A client-rendered page gives them nothing to cite.
• Every link preview looks the same. In a single-page app, per-page titles and Open Graph tags usually only exist after JavaScript runs. Slack, LinkedIn and WhatsApp read the static index.html, so every shared link shows your homepage title and image.

What Lovable still does not do for you

Server-side rendering answers one question: can a crawler read the page? It does not answer whether the page deserves to rank. Even on the newest Lovable stack, these are on you:

• A unique title and meta description for every page. Lovable's starting metadata is generic, and a single-page app that never sets per-page tags ends up with the same title on every URL, which is exactly what this site had.
• Open Graph tags per page, so shared links show the right title, description and image.
• A complete sitemap with every indexable URL and honest last-modified dates.
• One canonical domain. Connect a custom domain and make sure the lovable.app address is not competing with it.
• Structured data for your organisation, products, articles and FAQs.
• Internal linking. Pages nobody links to are pages Google treats as unimportant.
• Content with a reason to exist. A thin landing page that renders perfectly is still a thin landing page.

My migration: this site, from a Lovable SPA to Next.js

This site began in December 2025 from Lovable's Vite, React and shadcn/ui template, exported to GitHub and deployed on Vercel. It used React Router for its pages and nothing to manage the document head, so every URL shared one index.html. Every page had the same title, Rahul | Build + Solve - Portfolio, and the body was an empty <div id="root"> until the JavaScript ran. Lovable's pre-rendering did not exist yet, and it would not have applied to a site hosted on Vercel anyway.

For a portfolio with a handful of sections, that would have been tolerable. But this site is how I find clients, and it was going to need dozens of indexable pages: service pages, case studies, comparison guides and this blog, with the main pages in six languages. Pre-rendering would have made the HTML readable. It would not have given me per-page metadata, hreflang between languages, a sitemap generated from the content, or structured data that differs by page type. So I moved it to the Next.js App Router in stages during 2026. The Next.js setup went in at the end of April, and the last of the Vite setup was gone by mid-July.

Today every page has its own title, description and canonical URL. The sitemap is generated from the content, with last-modified dates taken from git history rather than the build date. Service pages, articles and case studies each carry their own JSON-LD. The home and service pages exist in six languages with a full hreflang cluster. When I checked in late October 2026, Search Console's URL Inspection reported every page I sampled, including services, case studies, articles and a German service page, as Submitted and indexed, with Google choosing the same canonical I declared.

I am not going to claim the migration made the site rank. It is a new domain, and authority is a separate, slower problem. What the migration did was remove rendering as a reason for Google to ignore a page, which is the precondition for everything else.

Your options, compared

What a move from Lovable to Next.js involves

The code Lovable writes is ordinary React and TypeScript, so a migration is real engineering rather than a rewrite from zero. The usual breakpoints:

1. Keep your URLs. List every live URL first. Each one should exist at the same path afterwards, or get a permanent redirect.
2. Move the routes. React Router routes become folders in the App Router, and links switch from React Router's components to next/link.
3. Separate server and client code. Anything that touches window, document or localStorage either moves into a client component or runs after the page loads. Most "window is not defined" build errors come from here.
4. Rename environment variables. Vite exposes VITE_ variables to the browser; Next.js uses NEXT_PUBLIC_. Only rename the ones that are genuinely safe to ship to the browser.
5. Rework Supabase auth for the server. If the app uses Supabase, switch to the @supabase/ssr package so sessions live in cookies that both the server and the browser can read.
6. Add the SEO layer. Per-route metadata, sitemap.ts, robots.ts and JSON-LD, which is the part that justified the move in the first place.
7. Verify before you switch DNS. Crawl the preview deployment, compare titles and status codes against the old site, and run URL Inspection on the new pages once they are live.

When not to bother

• The app lives behind a login. Dashboards and account pages are not meant to rank. Only your marketing pages matter for SEO, and those can live on a separate site while the app stays in Lovable.
• The app is new, hosted on Lovable and has a handful of pages. It is already server-rendered. Fix the metadata, add a sitemap, write better pages and move on.
• You have not validated the product yet. A migration is a poor use of money before you know people want what you are building.

FAQ

Is Lovable good for SEO? For apps created from 13 May 2026 and hosted on Lovable, the rendering side is solved: pages are server-rendered. Older apps on Lovable hosting are pre-rendered for crawlers. Self-hosted exports of older apps are not, and they behave like any client-rendered single-page app.

Does Lovable use Next.js? No. New Lovable apps use TanStack Start, and older ones use React with Vite. You can move the code to Next.js yourself, or have a developer do it.

Why is Google not indexing my Lovable site? Check four things in this order: whether you are on a custom domain rather than the lovable.app address, what URL Inspection shows Google receiving, whether your sitemap lists the page, and whether the page has enough unique content to be worth indexing. Rendering is only one of the possible causes.

Do I need Prerender.io or another pre-rendering service for Lovable? Not on Lovable hosting: Lovable's documentation says hosted projects do not need an external pre-rendering service. If you self-host an older React + Vite export, you need pre-rendering, server-side rendering or a migration.

Can ChatGPT and other AI search tools read my Lovable app? On Lovable hosting, Lovable says published apps return readable HTML to AI crawlers. A self-hosted client-rendered app is a different story: Vercel's crawler analysis found that the major AI crawlers do not run JavaScript.

How long does a Lovable to Next.js migration take? It depends on the number of routes and how much logic lives in the browser. A small marketing site can take days; an app with authentication, payments and many routes takes weeks. Keeping the URLs and getting authentication right take more of the time than moving the pages.

About the Author

Rahul Singh Negi is a freelance full-stack developer who builds and rescues SaaS products, MVPs and Flutter apps. He moved this site from a Lovable export to Next.js, and he takes Lovable, Bolt and FlutterFlow apps to production for founders. For the technical SEO side on its own, see technical SEO services.