How to Do SEO for Lovable Websites

Updated 1 August 2026

The Big Change: Lovable Now Builds With TanStack Start

Lovable changed its default stack in 2026. New projects are now server side rendered and powered by TanStack Start, a full stack React framework with server side rendering, static generation, and client side rendering available per route.

The timeline is worth knowing, because it is a little unusual. Lovable actually shipped the change on 20 April 2026, but only announced it publicly on 13 May 2026. It is not clear why they rolled server side rendering out quietly for a few weeks before saying anything about it. Either way, the practical rule is simple: any project created on or after 20 April 2026 is server rendered by default.

In plain terms, if you spin up a brand new site today and simply say “build me a website”, Lovable will build it as an SSR site. Search engines receive real HTML on the first request instead of an empty shell that only fills in after JavaScript runs. That removes the single biggest SEO weakness the platform used to have.

Old Projects Are Not Automatically Upgraded

Here is the part that catches people out. As of now, Lovable has not found a way to add TanStack Start to existing projects. Anything created before 20 April 2026 keeps running as the same Vite single page application it always was. These sites receive some pre-rendering to help crawlers read them, but they are not converted to true SSR.

So there is no one click migration button. Your project sits in one of two camps: a newer TanStack Start build that is SSR, or an older build that is still CSR with pre-rendering bolted on.

Be Careful: Handing Over Old Files Still Builds CSR

This is the trap I see most often. If you take an old Lovable project’s files and feed them back into Lovable expecting a fresh SSR site, you will usually still get a client side rendered build. Importing old code carries the old architecture with it. The SSR default applies when Lovable generates the project structure itself, not when it is rebuilding around files you have supplied.

In other words, you cannot hand Lovable all of your existing files and expect it to turn a CSR site into an SSR one. The rendering model is baked into how the project was scaffolded.

What To Do If You Are Stuck On An Old Build

You have three realistic options:

• Keep using pre-rendering. For old builds, a pre-render layer is still the practical fix. It serves static HTML snapshots to bots while users keep the app experience. See my breakdown of Lovable HTML vs Prerender.io for how that works.
• Pay a migration service. Some specialised services and developers now advertise a paid migration from the old stack to TanStack Start. It can work, but read the scope carefully, because a partial conversion often leaves the same rendering gaps behind.
• Rebuild it fresh. Honestly, for many sites the cleanest path is to rebuild as a new TanStack Start project and move the content across. You get true SSR from the ground up rather than patching an architecture that was never meant to render on the server. If the site earns real traffic, treat it as a proper website migration so rankings carry over.

How To Tell Which Kind Of Lovable Site You Have

Before you spend money on anything, confirm what you are actually running. Three quick checks:

• Check the source code. Open the page, then view the raw HTML source (not the rendered DOM in dev tools). If your headings, paragraphs, and links are all present in that raw source, you are server rendered. If the source is mostly an empty <div id="root"> and a script bundle, you are still client side rendered.
• Ask Lovable directly. Ask the builder whether the project is on TanStack Start with SSR or the older Vite SPA setup. It will tell you which stack the project uses.
• Use a Google SERP simulator. Run the URL through a SERP or fetch and render tool and look at what a crawler sees. If the simulated view is blank or missing your content, that is exactly what Google struggles with too. You can start with my free SEO tools or Google’s own URL Inspection in Search Console.

Your Lovable SEO Checklist

Here is the whole job on one screen. Work down the list, and use the prompts and verification steps further down to action each item. If you can tick all of these, your Lovable site has the technical foundation it needs to get indexed and rank.

How SEO Works on Older (CSR) Lovable Websites

If you are on an older build, this is the behaviour to understand. The app loads a small HTML shell first. After that, JavaScript takes over routing and renders the actual content in the browser. This is client side rendering.

Google can index CSR websites, but it does not do it instantly.

According to Google Search Central documentation, JavaScript websites are indexed in two stages. First, Google crawls the initial HTML and understands the page structure. Second, Google comes back later to render JavaScript and extract the full content. That second pass can lag days or even weeks behind the first.

This process works reliably, but it affects speed of indexing. New pages may take days to appear instead of hours. Content updates may show later in search results. Rankings are not penalised, but freshness is delayed. For sites that publish frequently or rely on timely visibility, that delay matters, and it is the main reason the move to SSR is such a big deal.

SEO Problems That Remain Even On TanStack Start

SSR fixes the rendering problem. It does not fix everything. A server rendered Lovable site can still have plenty of SEO issues, because rendering is only one piece of technical SEO. These are the ones I check first on any Lovable project, old or new.

Robots.txt

Lovable does not always ship a considered robots.txt. Make sure yours allows crawlers to reach JavaScript, CSS, and any API endpoints needed for rendering, and that it is not accidentally disallowing whole sections. If you want visibility in AI answers, avoid blanket rules that block known LLM bots.

Canonical Tags

Every indexable page needs a self referencing canonical tag. On Lovable this is easy to miss, and without it you get duplicate content from routing and parameter variations, or from your site being reachable at both the lovable.app staging URL and your custom domain. Canonicals should be present in the server rendered HTML, not injected only after the page loads.

Internal Linking

Single page app patterns often rely on buttons and JavaScript click handlers instead of real links. Google needs crawlable anchor tags with proper href attributes. Check that your navigation, footer, and in content links are genuine <a> elements, because internal linking is how Google discovers pages and understands which ones matter.

Trailing Slash vs No Slash

This is a specific Lovable quirk worth calling out. Lovable tends to ignore the difference between a URL with a trailing slash and one without, so /pricing and /pricing/ both load the same content and neither redirects to the other.

Remember that the slash and non slash versions are two separate URLs as far as Google is concerned. You should only use one. Pick a single format, be consistent across every internal link and your sitemap, and 301 redirect the other version to it. I prefer every URL ending with a trailing slash and I keep the whole site consistent with that. Whichever you choose, your canonical tags must point at the chosen version too.

XML Sitemap

Many Lovable projects launch without a real XML sitemap. Create one that lists every indexable URL in your chosen slash format, keep it updated as pages are added, and submit it in Google Search Console. It is one of the fastest ways to get new pages found.

Titles and Meta Descriptions

Duplicate or missing title tags are common on generated sites. Give every page a unique title that matches search intent, and a clear meta description. Titles should be set in the server rendered HTML so Google reads the intended version rather than rewriting a duplicate.

Redirects and URL Hygiene

Use readable URLs that reflect page intent, and avoid hashes and unnecessary parameters. When you rename or remove a page, add a 301 redirect rather than leaving a dead route. Sloppy redirects and orphaned URLs quietly leak the authority you have earned.

Why Lovable SEO Needs Deliberate Setup

Lovable gives you a flexible codebase, and the SEO elements exist in the framework. The catch is that the agent does not configure them correctly unless you ask. By default, most Lovable apps ship with a generic title tag taken from the project name, a missing or duplicated meta description, no canonical tags, no per page Open Graph tags, and a sitemap that sometimes lists URLs which do not exist.

This is not a criticism of Lovable. It is the nature of building on a flexible AI agent: you get what you prompt for. As I covered in my article on technical SEO fixes for AI built websites, the fundamentals apply whether the site came from Lovable, Bolt.new, or any other builder. The platform changes, the SEO requirements do not. The fix is to use the right prompts at the right time.

The Exact Lovable Prompts to Fix Your SEO

Below are the prompts I use, in order. Run them in sequence in Lovable, starting with a reusable meta component, then work through each file and element. Replace the parts in [square brackets] with your own details.

1. Canonical tags

A canonical tag tells Google which URL is the authoritative version of a page. It matters on Lovable because your app is usually reachable at both a staging URL (your-app.lovable.app) and your custom domain, and without a canonical Google may index the wrong one or split authority between them. My canonicalisation guide explains the concept in full.

Add a canonical tag to the head of every page. The canonical URL should always point to the production domain [yourdomain.com], not the lovable.app staging URL. Make sure the canonical is set server-side or in the static HTML, not rendered by JavaScript after load.

For older CSR projects using react-helmet-async, add: Set the canonical tag as part of the SEOHead component and pass the canonical URL as a prop on each route.

2. Meta titles and descriptions

By default Lovable repeats the same title and description on every page, which kills your rankings. Google needs unique, descriptive titles and descriptions per page.

Create a reusable SEOHead component using react-helmet-async that accepts title, description, and canonical as props. Apply it to every page with unique, page-specific values. Remove any hardcoded title or description tags from index.html that would conflict with the component.

Then, for each page:

Set the meta title for [page name] to: [title under 60 characters]. Set the meta description to: [description under 155 characters]. The title should include the primary keyword for this page.

Keep titles under 60 characters and descriptions between 140 and 155. Write the description as a value statement, not a summary, and include the target keyword.

3. Image alt attributes

Alt text helps screen readers and gives Google a signal about what each image shows.

Audit every image tag in the codebase and add a descriptive alt attribute to any that are missing one. Alt text should describe what the image shows, not repeat the filename. For decorative images set alt="" (empty string). For images that contain text, include that text in the alt attribute.

4. Open Graph and Twitter cards

Open Graph tags control how your page looks when shared on LinkedIn, Slack, Discord, and X. On older CSR sites, OG tags rendered by JavaScript do not work at all for sharing, because social crawlers never execute JavaScript.

Add Open Graph meta tags to every page: og:title, og:description, og:url (matching the canonical), og:image (at least 1200x630px), og:type (website for pages, article for posts), and og:site_name. Also add Twitter Card tags: twitter:card set to summary_large_image, twitter:title, twitter:description, and twitter:image. Apply these through the SEOHead component so each page has unique values.

5. robots.txt

The robots.txt file controls what crawlers may access. Misconfigured, it can quietly block pages you want indexed. The sitemaps and robots.txt guide covers how the two work together.

Generate a robots.txt file in the /public folder. Allow all search engine crawlers to access the full site, including the JavaScript, CSS, and API endpoints needed for rendering. Add the sitemap URL at the bottom: Sitemap: https://yourdomain.com/sitemap.xml. Do not block any pages that should be publicly indexed.

6. XML sitemap

Create a sitemap.xml file in the /public folder. List all publicly indexable pages using the production domain [yourdomain.com]. Do not include lovable.app staging URLs, admin pages, thank-you pages, or noindex pages. Add a lastmod date for each URL. If the site has more than 15 pages, generate the sitemap programmatically from the route definitions rather than hardcoding each URL.

That last line matters. Lovable has a known habit of inventing URLs in hand built sitemaps, so for anything beyond a few pages, generate it from the actual route tree rather than letting the agent list them from memory.

7. llms.txt

An llms.txt file is a plain text summary that helps AI systems like ChatGPT, Perplexity, and Claude understand your site even when they cannot execute the JavaScript that renders it.

Create an llms.txt file in the /public folder. Include a brief plain-text description of what this website does, who it is for, and the key pages, with a one-line description of each. Keep the language simple and factual.

8. Structured data (JSON-LD)

JSON-LD tells Google what your content means and powers rich results such as star ratings, FAQs, and breadcrumbs.

Add JSON-LD structured data to the relevant pages. Homepage: Organisation schema with name, URL, logo, and contact info. Blog posts: Article schema with headline, author, datePublished, and dateModified. FAQ sections: FAQPage schema for each question and answer. Inject it in the head using a script tag with type="application/ld+json".

See my schema markup guide for which types to use where.

On Page SEO for Lovable Websites

On page SEO helps search engines understand what each page is about.

Page Titles

Each page must have a unique title tag. Titles should reflect search intent and include primary keywords naturally. Google rewrites titles when they are missing or duplicated, which reduces control over messaging.

Meta Descriptions

Meta descriptions do not affect rankings directly, but they influence click through rate. Write clear summaries that explain value and relevance. Descriptions should be rendered consistently and not rely on client side updates only.

Heading Structure

Use one H1 per page. Support it with logical H2 and H3 headings. Avoid using headings purely for styling. Headings communicate structure to search engines and assistive technologies.

Rich Results and Social Optimisation

Structured data and social metadata improve how your pages appear outside standard blue links.

Structured Data

Add JSON LD schema for relevant content types. Common examples include articles, software applications, FAQs, and organisations. If you are unsure how to implement it, this guide on schema markup covers the basics.

Pages with valid structured data are eligible for enhanced search features, which can lift click through rate even when the ranking position stays the same. Validate yours with Google’s Rich Results Test.

Open Graph and Twitter Cards

Define Open Graph and Twitter Card metadata to control how pages appear when shared on social platforms. This improves engagement and referral traffic without extra advertising spend.

Performance and Mobile Experience

Performance affects SEO and user behaviour.

Google confirmed in 2021 that Core Web Vitals are ranking signals. Slow JavaScript execution can harm both metrics and conversions. web.dev’s reference on Core Web Vitals is the most up to date source for thresholds and measurement methods, and I have also written a simpler breakdown on Core Web Vitals if you want the SEO angle first.

SSR helps here too, because sending real HTML up front usually improves your Largest Contentful Paint. Still, optimise bundle size, lazy load non critical components, and compress assets, and always test performance on mobile devices, not only desktops. Lovable includes a built in Speed tool powered by Lighthouse, so run it monthly and act on what it flags.

GEO: Make Lovable Content AI and LLM Friendly

Generative engine optimisation focuses on making content usable by AI systems and large language models.

AI Bot Access

Ensure robots.txt allows known AI crawlers. Blocking them limits visibility in AI generated answers and summaries.

LLM Quotable Content Patterns

Write concise explanations, definitions, and step by step sections. AI systems prefer clear, factual blocks they can quote directly.

Static LLM Friendly Summary Page

Create a static summary page that explains your product, features, and use cases in plain language. This page should load without heavy JavaScript and act as a reference source, and it pairs well with the llms.txt file above.

How to Verify Your Lovable SEO Setup

Prompting Lovable is not enough. Confirm each element is actually in the served HTML before you submit anything to Google.

• Meta tags and canonicals: open the page, right click, choose View Page Source, and search the raw HTML for title, description, and canonical. If they are in the source, they are server rendered and reliable. If they only appear after the page loads, they are JavaScript rendered, which is a problem on CSR sites.
• Open Graph: paste the URL into the LinkedIn Post Inspector and the X card validator. A blank preview means your OG tags are not reaching social crawlers.
• robots.txt and sitemap: visit yourdomain.com/robots.txt and yourdomain.com/sitemap.xml directly, and check every sitemap URL is a real page on your production domain, with no staging URLs.
• Structured data: run each page through Google’s Rich Results Test and confirm the schema type and properties are detected.

Set up Google Search Console before anything else. Verify your domain, submit your sitemap, and check the Pages report after a week to see which pages Google has actually indexed and which have issues.

Monitoring and Maintenance

SEO for Lovable websites is not a one time task.

Google Search Console Setup

Set up GSC to monitor indexing, crawl errors, and Core Web Vitals. Pay close attention to the Pages report and the URL Inspection tool, which shows you exactly how Google renders each page.

Suggested Maintenance Schedule

Review indexing reports weekly. Check performance metrics monthly. Audit technical SEO quarterly or after major releases. Consistent monitoring prevents small issues from turning into long term visibility losses.

Solving Lovable SEO: SSR First, Prerender If You Have To

The most reliable way to fix Lovable’s old SEO limitations is to render on the server, and that is now the default for new projects.

New Builds: TanStack Start SSR

If you are starting fresh, let Lovable build on TanStack Start and keep it server rendered. Search engines receive fully rendered HTML on the first crawl, which removes indexing delays and improves freshness. Then spend your effort on the checklist and prompts above, because those are the issues SSR does not solve on its own.

Old Builds: Prerendering

Prerender.io and similar tools generate static HTML snapshots for search engine bots while keeping the SPA experience for users. For an existing CSR Lovable site that cannot be upgraded in place, this is still the fastest way to solve JavaScript rendering issues without rewriting the whole application, and it is often the right move for sites that already have traffic to protect.

One tell to watch for: if Google Search Console shows pages as “Discovered, currently not indexed”, prerendering is very often the fix. It means Google found the page but did not fully process the JavaScript, so it chose not to index it. Prerender.io, LovableHTML, and a Cloudflare Workers setup are the main options, and I compare two of them in the LovableHTML vs Prerender.io breakdown.

Final Thoughts

Lovable websites can rank well in Google, but they need intentional SEO support. The 2026 move to TanStack Start SSR removed the biggest obstacle for new projects, yet rendering was only ever one part of the job. Robots, canonicals, internal links, trailing slashes, sitemaps, and structured data all still decide whether your site actually earns visibility.

One last thing SSR does not do: it does not build authority or write your content for you. A brand new Lovable site on a fresh domain starts with zero backlinks and no topical history, and getting indexed is only step one. Ranking for anything competitive still comes down to content that answers the query better than what is already there, plus links earned over time.

If you are building or scaling a Lovable app and want predictable organic growth, SEO decisions should be part of the development process, not an afterthought. Work out which stack you are on first, tick off the checklist, then fix the fundamentals in the right order.

I am Rasesh, a Sydney based SEO consultant with over 10 years of experience working with JavaScript heavy websites, SaaS platforms, and modern web applications. If you need help fixing indexing delays, migrating an old build to SSR, or planning SEO for React based projects, you can get in touch or explore more resources on raseshkoirala.com.