What the Lovable SEO problem concretely was
To understand the scope of the problem, you need to know the technical architecture Lovable used to generate all projects until April 2026: Vite single-page applications with React.
In this architecture, loading a page works as follows: The browser requests a URL. The server delivers an almost empty HTML file — usually only about 1–2 kilobytes, with an empty <div id="root"> and a JavaScript bundle tag. Only after the JavaScript bundle is fully loaded and executed does React build the actual page content in the browser. The result looks the same to a human visitor as a traditionally rendered page — but the path there is fundamentally different.
For search engines, this path is problematic. Crawlers initially read the originally delivered HTML — and find practically no content there. Google has had the ability to render JavaScript and capture loaded content since around 2019. In practice, this works inconsistently.
Concretely observable symptoms with Vite SPA sites were:
First, significantly delayed indexing. While traditionally server-rendered pages often appeared in the Google index within 24–72 hours, this often took weeks with Vite SPA sites — sometimes months. Search Console showed statuses like "Discovered, currently not indexed" or "Crawled, but not indexed" for long periods.
Second, patchy indexing. Often only the homepage was captured ranking-relevant, while subpages — especially dynamically generated or deeply nested routes — didn't end up in the index at all or only partially. Sites with ten or more routes often had only two or three of them actually findable on Google.
Third, missing rich snippets. Even when a page was indexed, the enrichments were often missing — no sitelinks, no FAQ snippets, no breadcrumb display in the SERPs. This noticeably lowered the click-through rate compared to competitors with traditionally rendered sites.
Fourth, AI search systems saw practically nothing. ChatGPT, Claude, Perplexity, and comparable systems (so far) don't have full JavaScript rendering capability. They crawl the initially delivered HTML — and on Vite SPA sites, that was practically empty. Consequence: Lovable sites weren't cited in AI answers, even when they would have been content-relevant.
A concrete practical example shows the extent:
A typical Lovable Vite SPA site with ten routes had about 50–150 bytes of "real" body content per route in a crawler test (Screaming Frog with JavaScript rendering disabled) — consisting of the empty root div and the script tag. By comparison, a traditionally server-rendered site with the same content had about 8,000–15,000 bytes per route.
In other words: From a search engine perspective, a Vite SPA site was almost contentless. That Google still partially indexed was only due to the downstream JavaScript rendering pipeline — which didn't reliably catch every page, didn't run promptly, and doesn't exist at all for AI search systems.
Three diagnostic steps for your own Lovable sites
Before deciding whether a migration is necessary, you need to know whether your own site is actually affected — and if so, how severely. Three diagnosis steps that can be performed in half an hour.
Diagnostic Step 1 — View Source Test
The simplest test: Open any Lovable site, right-click → "View Page Source" or press Ctrl+U. The raw HTML source code that the server delivered opens. Important: don't use "Inspect Element" — that shows the rendered DOM, not the delivered HTML.
What to check: Do you see the actual page content in the source — headlines, texts, lists? Or do you only see an empty <div id="root"> plus a JavaScript bundle tag?
If the content is in the source, the site is server-rendered (or pre-rendered). If only the empty shell is visible, the site is a classic SPA with all associated SEO problems.
Diagnostic Step 2 — Crawler Test Without JavaScript
A precise test with Screaming Frog (free for up to 500 URLs):
1. Start Screaming Frog SEO Spider
2. Configuration → Spider → Rendering → JavaScript: disable
3. Enter site URL, crawl
4. For each URL, check:
- Word Count (column "Word Count")
- Body Content (column "Body Content" — if activated)
For a healthy site, word counts per URL should be between 200 and 2,000+ words. If all URLs show word counts below 50, the site is SPA-related SEO-problematic.
Alternative for users without Screaming Frog: Curl command in terminal:
curl -A "Mozilla/5.0" https://my-lovable-site.com/
If the output HTML is practically empty (only header, empty root div, script tag), the problem exists.
Diagnostic Step 3 — Google Search Console Indexing Status
In Google Search Console under "Pages," check:
- How many URLs are "indexed"?
- How many URLs are "not indexed" (with detailed causes)?
- What status indicators appear? Common indicators for SPA problems are "Discovered, currently not indexed" or "Crawled, but not indexed."
If a site shows more than 50 percent of its URLs as "not indexed," that's a clear SPA SEO indicator. Plus: in Search Console under "URL Inspection," check individual URLs — there Google explicitly shows what content was captured.
What the diagnostic results yield together
The three steps together give a clear picture:
- Source code empty + crawler shows 0–50 words + Search Console shows 50%+ not indexed: classic Vite SPA problem, migration sensible
- Source code filled + crawler shows 200+ words + Search Console shows >80% indexed: already server-rendered or pre-rendered, migration not necessary
- Mixed picture (source empty, but Search Console shows good indexing): Google renders JavaScript successfully, but AI search systems remain excluded
What changed technically with the TanStack update
Lovable fundamentally changed the underlying architecture for new projects on April 20, 2026. Instead of Vite SPA with React, TanStack Start with server-side rendering is now used.
What TanStack Start technically is
TanStack Start is a full-stack React framework that solves similar problems as Next.js, Remix, or SvelteKit — but with explicit focus on modern TypeScript integration and type safety in routing. Under the hood, it uses Nitro as the server engine (the same server framework that Nuxt 3 uses) and can be deployed on various hosting platforms.
For SEO, three technical properties of TanStack Start are decisive:
First, real server-side rendering. When a browser requests a URL, TanStack Start generates the complete HTML on the server — including all page contents, headings, texts. Only then is the response delivered. That means: search engine crawlers receive the complete content at the first request.
Second, automatic hydration on the client side. After the fully rendered HTML arrives in the browser, React takes over and "hydrates" the static markup with interactive functionality. From a user perspective, the site then functions like a normal interactive web application — but the initial render was server-side.
Third, type-safe routing with file-based routes. TanStack Start uses a file-based routing convention, similar to Next.js — files in the routes/ folder automatically become routes. This enables static site generation for routes that need it, plus dynamic server-side generation for others.
What concretely changes from an SEO perspective
With TanStack Start, the SEO-relevant behavior changes in five points:
- HTML body at initial request: previously ~50–150 bytes (empty shell), now 5,000–50,000 bytes (complete content) — depending on route complexity
- Time to First Byte (TTFB) for search engine crawlers: previously relevant due to subsequent rendering, now directly meaningful
- Indexing speed: previously weeks, now typically 24–72 hours for new URLs
- Rich snippet eligibility: previously inconsistent, now directly usable through clean Schema.org implementation
- AI search system visibility: previously practically zero, now complete
What Lovable did right with the TanStack implementation
Three aspects of the concrete Lovable TanStack implementation are remarkably positive:
First, automatic meta tag generation per route. Lovable now offers standard meta tags (title, description, Open Graph) as configurable fields per page. That was a weakness in the Vite SPA phase — meta tags were set client-side after the fact, which many crawlers didn't pick up.
Second, JSON-LD schema support out of the box. Structured data can now be inserted declaratively into Lovable posts, without complex configuration.
Third, automatic sitemap generation. Lovable generates a sitemap.xml with all statically generated routes plus hreflang alternates for multilingual sites — a function that had to be manually implemented in the Vite SPA phase.
Where Lovable still has gaps
Three areas where the TanStack implementation, despite improvements, still needs refinement:
First, fine-grained Schema.org control. While simple schema types (Organization, WebPage) are set automatically, more complex schema configurations (FAQPage with dynamic Q&A pairs, Article with author reference, BreadcrumbList) often have to be implemented manually.
Second, build performance for large sites. Sites with 50+ routes can have build times of 5–15 minutes, which is impractical for ongoing iterations. There's still optimization potential here.
Third, headless CMS integration. Anyone wanting to integrate Strapi, Storyblok, or another headless CMS currently has to orchestrate that themselves — Lovable offers no out-of-the-box integration.
Why existing projects aren't automatically migrated
One of the most important insights for existing customers: The TanStack update only applies to new projects. Sites created with Lovable before April 20, 2026 continue running on the Vite SPA architecture and retain all associated SEO problems.
Why is there no automatic migration path
The reasons are technically understandable, but economically frustrating for existing customers:
First, architecture changes aren't possible via update. Vite SPA and TanStack Start differ in build pipeline, routing conventions, state management patterns, and component lifecycle. An automatic converter would have to understand all these aspects — which would be very technically complex and would lead to faulty results in many cases.
Second, custom code wouldn't be migratable. Many Lovable projects contain custom components or external code that's specifically tuned to Vite SPA patterns. An automatic converter would also have to adjust this code — which can produce unpredictable errors.
Third, Lovable opted for clean separation. Instead of offering a half-baked migration path, Lovable consciously chose clean separation: old projects stay on the old architecture, new projects start on the new.
What this means for existing customers
Anyone who started a Lovable site before April 20, 2026 faces a decision:
First, manually rebuild the project on TanStack. That means: keep the site concept, but technically completely redo it in a fresh Lovable project. Existing content is manually transferred, components are partially rebuilt, the design is often slightly revised (because TanStack components partially have different conventions).
Second, stay with Vite SPA and use workarounds. Pre-rendering services like Prerender.io or Rendertron can offer a workaround — they crawl the site server-side and deliver pre-rendered HTML versions to search engine crawlers, while real users get the SPA version. That partially solves the SEO problems, but not for AI search systems and with additional complexity.
Third, switch platforms. Anyone facing greater effort with Lovable migration anyway can also switch to another platform (Webflow, classic Next.js, Astro). This option pays off when the site is very individual or specific Lovable limitations are critical.
Which option is right depends on the concrete mandate reality. In the next section, we go through the three migration paths in detail.
Three migration paths — with honest effort-impact comparison
Anyone making a migration decision should honestly compare the three options — with realistic effort, realistic impact, and realistic risks.
Path 1 — Manual Rebuild in Fresh Lovable Project
Effort: For a site with 10–15 routes, typically 12–25 working hours, distributed over 2–3 weeks — the main economic advantage of Lovable over classic development. For larger sites (25+ routes) or complex components, 25–50 hours and 3–5 weeks. These values are based on Calvarius' own migration projects and include iteration loops that often occur in practice (layout corrections, animation tuning, schema validation).
Impact: Maximum. Site then runs completely on TanStack Start with all SEO advantages. Indexing speed improves significantly, AI search system visibility comes completely.
Risks:
- Content has to be manually transferred — error risk with large sites
- Custom components may need to be rebuilt
- Design often appears slightly different after migration, because TanStack components partially have different conventions
- During migration: maintaining old and new site in parallel
When sensible: When the site is economically relevant (at least 5–10 organic leads per month), when the content is reasonably sized (max 30–40 routes), and when 2–3 weeks of migration time are available.
Path 2 — Pre-Rendering Workaround
Effort: With standard setups using Prerender.io or Rendertron, typically 4–12 hours for setup, plus ongoing costs of EUR 30–150 per month (depending on site size and service tier).
Impact: Medium. Search engine crawlers receive pre-rendered HTML versions, which significantly improves indexing. Real users continue to get the SPA version.
Risks:
- AI search systems often still don't function — they usually don't use the pre-render service
- Cloaking risk (theoretically, in practice uncritical with clean setup)
- Pre-render cache must be actively maintained — otherwise outdated content
- Additional architectural complexity
When sensible: When migration isn't possible for resource reasons, when the site is small (under 20 routes), when AI search visibility isn't a priority, when quick SEO improvement in 1–2 weeks is more important than clean architecture. In practice, Path 2 is rarely the economically best choice — with Lovable, the effort advantage over Path 1 is so small that the structural disadvantages (limited AI visibility, ongoing service costs) outweigh it in most cases.
Path 3 — Switch to Other Platform
Effort: Very variable. When switching to Next.js, Astro, or Nuxt 3, typically 60–150 hours, depending on site complexity. Plus ongoing costs for own hosting.
Impact: Maximum, with additional flexibility. Platform-specific limitations disappear, custom architecture possible.
Risks:
- Higher technical demand — Lovable handles a lot of things you have to orchestrate yourself with Next.js/Astro
- Hosting costs and complexity
- Longer time-to-market
- Less no-code flexibility for follow-up iterations
When sensible: When specific Lovable limitations are critical, when the site is very individual, when an experienced development team is available, when long-term maximum control is desired.
Comparison Table
| Aspect | Path 1 (Lovable Rebuild) | Path 2 (Pre-Render) | Path 3 (Platform Switch) |
|---|---|---|---|
| Initial effort | 12–50h | 4–12h | 60–150h |
| Ongoing costs | same as Lovable | +EUR 30–150/month | own hosting |
| SEO impact | maximum | medium | maximum |
| AI search visibility | complete | partial | complete |
| No-code flexibility | high | high | low |
| Time-to-Production | a few days | 1–2 weeks | 4–10 weeks |
What needs to be configured for SEO beyond SSR
Server-side rendering is the prerequisite — but not sufficient on its own. Anyone wanting to set up a TanStack-Lovable site SEO-optimally must additionally configure nine areas cleanly. This list is based on practical experience with several TanStack-Lovable migrations and is the most common source of "SSR is there, but the site still isn't ranking" problems.
First — keep heading hierarchy structurally clean
One H1 per page exactly, clear H2 structuring per section, H3 for sub-content. No H4 or deeper without urgent reason. What Lovable often gets wrong here: H2 headings for card headlines, leading to 15–20 H2s per page — which weakens the SEO hierarchy. Card headlines should be H3, not H2.
Second — build internal linking structurally
Cross-links between related pages are an important ranking factor. With Lovable, these have to be actively maintained — from the main page to detail pages, between related detail pages, from service pages to blog posts, etc. A sitelinks test in Search Console shows whether the internal linking structure is recognized cleanly.
Third — implement Schema.org markup completely
Lovable offers standard schemas (Organization, WebPage), but more complex schema types need manual configuration. Concretely:
- ProfessionalService or LocalBusiness for site-wide localization
- Service for each service detail page
- Article or TechArticle for blog posts
- FAQPage for FAQ sections
- BreadcrumbList for every page with breadcrumb
- Person for author references (when multiple authors exist)
These schemas must be filled with real, consistent data. Wrong or incomplete schemas can be ignored or negatively rated by Google.
Fourth — set canonical URLs consistently
Per page, exactly one canonical URL must exist. With multilingual sites, each language version points to itself as canonical, with hreflang alternates to the other languages. Common error: canonical points to the default language instead of the respective language version — leading to indexing conflicts.
Fifth — sitemap.xml with hreflang alternates
The sitemap must contain all relevant URLs, with <xhtml:link rel="alternate" hreflang="..." /> tags for multilingual sites. Plus a lastmod tag per URL that's actually maintained (not hardcoded to build date).
Sixth — configure robots.txt cleanly
Lovable generates a default robots.txt, which is usually okay. But check: no accidental blocking of /static/, /assets/, or JavaScript files. Sitemap reference must also be correct.
Seventh — Open Graph and Twitter Cards
Per page, og:title, og:description, og:url, og:image must be set. Plus twitter:card="summary_large_image" and corresponding Twitter tags. Lovable often sets this automatically — but the og:image must be deliberately designed, otherwise every page shows the same default image.
Eighth — keep performance metrics in mind
Core Web Vitals (LCP, INP, CLS) are ranking factors. TanStack Start helps structurally, but images, fonts, and third-party scripts can still cause performance problems. Run Lighthouse audits regularly.
Ninth — content depth and keyword discipline
SSR alone brings nothing if the content is too thin. At least 300–500 words per relevant page, primary keyword in title, H1, and first 100 words, secondary keywords organically distributed. For pillar content, 1,500–5,000 words.
AI search systems — what changes for ChatGPT, Claude, and Perplexity
One of the most important arguments for the TanStack migration is AI search system visibility. This is where the biggest change lies — and at the same time the biggest competitive advantage for sites that switch to SSR early.
How AI search systems currently capture content
ChatGPT, Claude, Perplexity, and comparable systems use different crawler architectures, but have three commonalities:
First, they primarily crawl the initially delivered HTML. Unlike Google, most AI crawlers don't have a complete JavaScript rendering pipeline. ChatGPT uses a crawler called GPTBot, which can increasingly process JavaScript but not reliably. Claude (Anthropic) uses ClaudeBot with similar limitations. Perplexity uses PerplexityBot.
Second, they prefer clearly structured content. AI systems decompose content into semantic snippets that get cited in responses. Clearly organized heading hierarchies, semantically correct HTML tags, and FAQ structures are preferentially processed.
Third, they cite sources differently. ChatGPT with active browsing cites sources directly with reference. Perplexity shows sources prominently next to each answer. Claude cites sources when relevant, but less formalized. For sites that want to be cited, this is an important traffic channel.
What AI search visibility meant with Vite SPA
Concretely: AI crawlers saw practically nothing on Vite SPA sites. When a user asks ChatGPT "what performance marketing agencies are there in Würzburg," ChatGPT couldn't cite a Lovable SPA site — even when it would have been content-perfect for the request. The site practically didn't exist from an AI perspective.
What changes with TanStack Start
With real SSR, AI crawlers see the complete content at the first request. This has five concrete consequences:
- Sites become citable in AI responses — the substance is recognizable
- Concrete statements get used as snippets — those who write with clear, factual statements get cited more often
- FAQ sections function as answer sources — when a user asks a question that's answered in a FAQ section, the AI system can cite directly
- Author schema and publisher references get evaluated — AI systems check who writes content
- Update date becomes more important — AI systems prefer current content for current questions
What can additionally be done — beyond SSR
Three patterns that improve AI search visibility in practice:
First, clear definitions at section beginnings. "X is Y" or "X means Y" as opening sentence of a section. AI systems recognize definitions and use them for "what is X" questions.
Second, structured FAQ sections with FAQPage schema. A standalone FAQ section at the end of substantive posts, with FAQPage schema in JSON-LD. This is a direct source signal for AI responses.
Third, concrete numbers and facts. "Sites with 5,000+ monthly conversions" works better than "large sites." AI systems prefer quantified statements because they're better suited for factual responses.
Common errors during migration
From practical experience with several TanStack migration projects — seven errors that come up repeatedly and are economically painful.
Error 1 — Migration without URL consistency
When rebuilding in a fresh Lovable project, URLs are often structured differently than in the old site. Example: old URL /services/seo-marketing, new URL /leistungen/seo-ai-seo. If these URL changes aren't secured with 301 redirects, the site loses its Search Console history and existing backlinks point into nothing.
Solution: Document all existing URLs before migration, define new URLs, and set up 301 redirects in a dedicated redirects.json or in the Lovable setup. Check Search Console after migration for whether redirects work.
Error 2 — Heading hierarchy not migrated
When transferring content, often only the text is copied, but the heading designations (H1, H2, H3) are lost or inconsistently reassigned. This weakens the SEO structure.
Solution: Document heading hierarchy per page before migration, take it over exactly when rebuilding. Check with HeadingsMap extension after migration.
Error 3 — Schema.org data gets lost
JSON-LD structures that were manually inserted in the old site (e.g., service schema, FAQ schema) are often forgotten during migration. Lovable default schemas don't suffice for complex sites.
Solution: Check per page which schemas exist, transfer all when rebuilding. Run Schema.org validator (validator.schema.org) after migration.
Error 4 — Canonical URLs point into nothing
During migration, canonical URLs change. If old canonicals continue to appear in the sitemap or in JSON-LD schemas, there are indexing conflicts.
Solution: Check all canonical URLs after migration for current state. Regenerate sitemap. Check Search Console for whether canonical problems are reported.
Error 5 — hreflang tags inconsistent
With multilingual sites, hreflang tags are often not or incompletely migrated. Consequence: Google indexes both language versions as separate, competing sites.
Solution: Per page, ensure hreflang tags to all language versions plus x-default. Reciprocal — when DE points to EN, EN must also point to DE.
Error 6 — Performance optimizations forgotten
TanStack Start is structurally faster than Vite SPA, but images, fonts, and third-party scripts can still destroy performance. If no optimization happens, the new site can even be slower than the old one.
Solution: Optimize images (WebP, correct sizes, lazy-loading), fonts with font-display: swap, minimize or asynchronously load third-party scripts. Lighthouse audit after migration.
Error 7 — Search Console not adjusted
The old site often remains in Search Console for a while after migration — which can lead to duplicate indexing. Plus the new site may need to be re-verified.
Solution: Check Search Console directly after migration, actively manage old and new URL versions, formally signal domain migration in Search Console if applicable.
When migration isn't worth the effort
Honesty section: Not every Lovable site benefits from a migration. Three scenarios where the effort isn't economically justified.
Scenario 1 — Very small site with low performance expectation
When a Lovable site only has 3–5 routes and doesn't function primarily as a lead generator (e.g., a pure business card site visited mainly through direct domain access), migration is usually uneconomical. SEO isn't the decisive success factor here.
Scenario 2 — Site that will be rebuilt anyway in 6–12 months
When a relaunch is planned anyway (e.g., due to brand change, service expansion), interim migration isn't worthwhile. Instead, set up the relaunch project directly on TanStack — and live with pre-render workaround in the meantime.
Scenario 3 — Site with very individual custom components
When the old Lovable site is heavily enriched with custom code that's specifically tuned to Vite patterns, migration effort can explode. In that case, platform switch to Next.js, Astro, or similar is often more sensible — because the custom code structure can be better recreated there.
When migration is still worthwhile — even with smaller sites
When the site is economically relevant (even just 2–3 leads per month through organic search), when AI search system visibility is strategically important, or when the site is part of a larger brand presence that must appear consistent — then migration is worthwhile even with smaller setups.