What Changed With Lovable’s April 2026 SSR Update
On 20 April 2026, Lovable shipped server-side rendering for new projects via TanStack Start. This is a meaningful upgrade. Before this date, every Lovable project was a React single-page application (SPA), which means search engine crawlers received an empty HTML shell and had to wait for JavaScript to execute before seeing any content.
SSR changes that for new projects. Google now receives fully rendered HTML on the first request. No rendering queue. No JavaScript delay. Meta tags, headings, and internal links are all in the initial response. Google’s own JavaScript SEO documentation confirms that even when Googlebot does execute JavaScript, it happens in a secondary pass that can lag days or weeks behind the initial crawl. SSR removes that lag entirely.
That said, there are two things you need to know.
First, SSR only applies to projects created on or after 20 April 2026. If your Lovable app existed before that date, nothing has changed. You are still on client-side rendering (CSR), and everything in this guide still applies to you in full. Second, even with SSR, Lovable does not automatically generate correct SEO tags, sitemaps, or structured data. These still need to be prompted explicitly.
SSR solves the rendering problem. It does not solve the configuration problem. That is what this guide is for.
Why Lovable SEO Requires Deliberate Setup
Lovable gives you a flexible codebase. The SEO elements exist in the framework, but the agent does not set them up correctly unless you ask. By default, most Lovable apps have a generic title tag from the project name, a missing or duplicated meta description, no canonical tags, no per-page Open Graph tags, and a sitemap that may include incorrect or hallucinated URLs.
This is not a criticism of Lovable. It is the nature of building on a flexible AI agent. You get what you prompt for. And for SEO specifically, the default output is not enough.
The fix is simple: use the right prompts at the right time.
As I covered in my article on technical SEO fixes for AI-built websites, the fundamentals still apply whether the site came from Lovable, Bolt.new, or any other AI builder. The platform changes, but the SEO requirements do not.
Lovable SEO Prompts: The Complete Setup
Below are the exact prompts to use in Lovable for each SEO element. Use these in sequence. Start with the meta tag component, then work through each file and element.
Canonical Tags
A canonical tag is an HTML element in your page head that tells Google which URL is the authoritative version of a page. If you want a deeper explanation of how canonicalisation works and when to use it, the canonicalisation guide in the learn SEO section covers it in full. For Lovable specifically, it matters because your app may be accessible at both a staging URL (e.g. your-app.lovable.app) and your custom domain. Without a canonical, Google may index the wrong version, or split authority between both.
Use this prompt:
“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 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.”
Actionable tip: After implementing, open your deployed site in a browser, right-click, and select “View Page Source.” Search for canonical in the HTML. If you see it in the source without executing JavaScript, it is working correctly. If it only appears after the page loads, you have a JavaScript-rendered canonical, which is less reliable.
Meta Title and Meta Description
By default, Lovable sets the same meta title and description across all pages. This kills your SEO. Google needs unique, descriptive titles and descriptions per page to understand what each page is about and how to rank it.
Use this prompt:
“Create a reusable SEOHead component using react-helmet-async that accepts title, description, and canonical as props. Apply this component 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 individually:
“Set the meta title for [page name] to: [your title under 60 characters]. Set the meta description to: [your description under 155 characters]. The title should include the primary keyword for this page.”
Keep titles under 60 characters. Keep descriptions between 140 and 155 characters. Write the description as a clear value statement, not a summary. Include your target keyword in both.
Alt Attributes for All Images
Image alt text serves two purposes: accessibility for screen readers, and SEO signal for search engines. Google reads alt attributes to understand what an image depicts. Without them, your images contribute nothing to your rankings and may hurt your accessibility score.
Use this prompt:
“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 just repeat the filename. For decorative images, set alt=”” (empty string). For images that contain text, the alt attribute should include that text.”
Follow up with: “For all future images added to this project, ensure the alt attribute is always populated with a meaningful description before committing the change.”
Open Graph Tags for Every Page
Open Graph (OG) tags are meta tags in your HTML head that control how your page appears when shared on social platforms including LinkedIn, Slack, Discord, and Twitter/X. Without them, shared links produce blank previews, which reduces click-through rates and makes your brand look unfinished.
On CSR Lovable sites, OG tags rendered by JavaScript do not work for social sharing, because social crawlers do not execute JavaScript. SSR projects handle this natively, but you still need to set the right values.
Use this prompt:
“Add Open Graph meta tags to every page. For each page include: og:title (matching the meta title), og:description (matching the meta description), og:url (matching the canonical URL), og:image (a relevant image URL, at least 1200x630px), og:type (website for general pages, article for blog 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.”
Actionable tip: After deploying, paste your URL into the LinkedIn Post Inspector (linkedin.com/post-inspector/) and the Twitter Card Validator to confirm the preview renders correctly. If you are on CSR and the preview is blank, you need prerendering to serve static OG tags to social bots.
robots.txt
The robots.txt file sits at the root of your domain and tells search engine crawlers which pages they are allowed or not allowed to access. It does not control indexing, only crawling. But if it is misconfigured, Google may be blocked from pages you want indexed. For a full breakdown of how robots.txt and sitemaps work together, see the sitemaps and robots.txt guide.
Use this prompt:
“Generate a robots.txt file and place it in the /public folder. Allow all search engine crawlers to access the full site. Allow access to all JavaScript, CSS, and API endpoints needed for rendering. Include the URL of the sitemap at the bottom: Sitemap: https://yourdomain.com/sitemap.xml. Do not block any pages that should be publicly indexed.”
After generating, visit yourdomain.com/robots.txt in your browser to confirm it is live and the contents look correct. Test it using the robots.txt tester in Google Search Console.
XML Sitemap
An XML sitemap is a file that lists every URL on your site you want Google to crawl and index. Without one, Google discovers your pages by following links. With one, you tell Google exactly what exists and how recently it changed.
Use this prompt:
“Create a sitemap.xml file and place it in the /public folder. List all publicly indexable pages with their full URLs using the production domain [yourdomain.com]. Do not include any 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.”
The last part matters. Lovable has a known tendency to hallucinate URLs in manually constructed sitemaps. For any site with more than a handful of pages, a script-based approach that reads from your actual route tree is much more reliable.
After generating, submit the sitemap URL to Google Search Console under Indexing > Sitemaps.
llms.txt
The llms.txt file is a newer convention that helps AI language models understand your site’s structure and purpose. It functions similarly to robots.txt but for AI crawlers. ChatGPT, Perplexity, Claude, and other AI systems that crawl the web use this file to understand what your site is about and how to represent it in AI-generated responses.
This is particularly relevant for Lovable sites because, as I covered in the guide on SEO for Lovable websites, AI crawlers do not execute JavaScript. If your content is only visible after JavaScript runs, AI search engines will not see it. An llms.txt file gives them a fallback summary even when your content is not fully crawlable.
Use this prompt:
“Create an llms.txt file and place it in the /public folder. Include a brief plain-text description of what this website does, who it is for, and the key pages available. List the main URLs with a one-line description of each. Keep the tone factual and the language simple. This file helps AI language models understand your site when they cannot execute JavaScript to read the full content.”
Structured Data (JSON-LD)
JSON-LD structured data is a block of code added to your page that tells Google exactly what your content means. It powers rich results in search, including star ratings, FAQs, breadcrumbs, and product information. Google cannot guess this from content alone.
Use this prompt:
“Add JSON-LD structured data to the relevant pages. For the homepage, add Organisation schema with the business name, URL, logo, and contact information. For blog posts, add Article schema with headline, author, datePublished, and dateModified. For FAQ pages or sections, add FAQPage schema for each question and answer pair. Inject the JSON-LD in the page head using a script tag with type=’application/ld+json’.”
After deploying, validate your structured data using Google’s Rich Results Test at search.google.com/test/rich-results.
What SSR Still Does Not Fix for Lovable SEO
Even with the April 2026 SSR update, several SEO requirements remain your responsibility. SSR solves the rendering problem. It does not write your content, build your authority, or configure your technical files.
Domain authority still starts at zero. A new Lovable project on a fresh domain has no backlinks and no topical history. SSR does not change that. Building authority requires publishing consistent, useful content and earning links over time.
Content quality still determines rankings. Getting indexed is step one. Ranking for competitive terms requires content that clearly answers the search query better than what is already ranking. That is a content strategy problem, not a technical problem.
Sitemaps and robots.txt are not auto-generated correctly. Even on SSR projects, these files need to be explicitly prompted and verified. TanStack Start does not create them for you.
Core Web Vitals still matter. Google measures loading speed, visual stability, and interactivity as ranking signals. Run your Lovable site through Lighthouse monthly and address any issues flagged. Lovable includes a built-in Speed tool powered by Lighthouse; use it.
Existing CSR projects are unchanged. The SSR update applies only to projects created on or after 20 April 2026. If your Lovable app was built before that date, you need prerendering to fix the JavaScript rendering problem. Hado SEO, Prerender.io, and a Cloudflare Workers setup are the main options.
How to Verify Your Lovable SEO Setup
Prompting Lovable is not enough. You need to confirm each element is actually working before you submit to Google.
For meta tags and canonicals: open your deployed site, right-click the page, select “View Page Source,” and search for title, description, and canonical. If you see them in the raw HTML source, they are server-rendered and working. If the source shows an empty head and you only see these tags after the page loads, they are JavaScript-rendered, which is unreliable for CSR sites.
For Open Graph: use the LinkedIn Post Inspector and Twitter Card Validator. Paste your URL and check the preview. If it is blank, OG tags are not reaching social crawlers.
For robots.txt: visit yourdomain.com/robots.txt directly. Then verify it in Google Search Console using the robots.txt tester.
For sitemap: visit yourdomain.com/sitemap.xml. Check that every URL listed matches a real page on your production domain. Look for any lovable.app staging URLs that should not be there. Submit the sitemap to Google Search Console.
For structured data: use Google’s Rich Results Test. Enter each page URL and confirm the schema type and properties are detected correctly.
Actionable tip: Set up Google Search Console before doing anything else. Verify your domain, submit your sitemap, and check the Pages report after a week to see which pages Google has indexed. The Coverage report shows you exactly which pages have issues and why.
A Note on CSR Lovable Sites Built Before April 2026
If your Lovable project predates the SSR update, all the prompts above still apply. However, for meta tags and OG tags to reach crawlers, your pages need to be served as pre-rendered HTML. JavaScript-rendered tags are invisible to Google’s first crawl pass and invisible to social bots entirely.
The most practical fix is a prerendering layer. Services like Hado SEO and Prerender.io sit in front of your site at the DNS level. When a crawler or social bot requests a URL, they receive a pre-rendered static HTML version. Human visitors continue to see the full JavaScript app as normal. This approach works without rewriting your app. I compared both options in detail in the LovableHTML vs Prerender.io breakdown if you want to decide which suits your setup.
If you are getting the “Discovered, currently not indexed” status in Google Search Console, prerendering is likely the fix. Google found your page but could not fully process the JavaScript content, so it decided not to index it.
Conclusion
Lovable SEO is solvable. The April 2026 SSR update removed the biggest barrier for new projects. But even with SSR, the technical SEO elements covered in this guide still need to be set up deliberately. Canonical tags, per-page meta titles and descriptions, image alt attributes, Open Graph tags, robots.txt, sitemap.xml, llms.txt, and structured data all need to be prompted explicitly. None of them are configured correctly by default.
Use the prompts in this guide. Verify each element in your page source after deploying. Submit your sitemap to Google Search Console. Then monitor your indexing reports weekly for the first month.
Getting the fundamentals right is the difference between a Lovable app that sits unindexed and one that starts ranking within weeks of launch.
I am Rasesh Koirala, an ecommerce SEO consultant based in Sydney. If your Lovable site is not getting indexed, or you want someone to audit the full technical setup, get in touch. I work with founders and marketing teams to turn AI-built websites into sites that actually rank.
