Was das Lovable-SEO-Problem konkret war
Um die Tragweite des Problems zu verstehen, muss man die technische Architektur kennen, mit der Lovable bis April 2026 alle Projekte generierte: Vite-Single-Page-Applications mit React.
In dieser Architektur funktioniert das Laden einer Seite folgendermaßen: Der Browser fordert eine URL an. Der Server liefert eine fast leere HTML-Datei aus — meist nur etwa 1–2 Kilobyte groß, mit einem leeren <div id="root"> und einem JavaScript-Bundle-Tag. Erst nachdem das JavaScript-Bundle vollständig geladen und ausgeführt ist, baut React den eigentlichen Seiteninhalt im Browser auf. Das Ergebnis sieht für einen menschlichen Besucher genauso aus wie eine traditionell gerenderte Seite — aber der Weg dorthin ist fundamental anders.
Für Suchmaschinen ist dieser Weg problematisch. Die Crawler lesen zunächst das initial ausgelieferte HTML — und finden dort praktisch keinen Inhalt. Google hat seit etwa 2019 die Fähigkeit, JavaScript zu rendern und den nachgeladenen Content zu erfassen. Das funktioniert in der Praxis aber inkonsistent.
Konkret beobachtbare Symptome bei Vite-SPA-Sites waren:
Erstens, deutlich verzögerte Indexierung. Während traditionell server-gerenderte Seiten oft binnen 24–72 Stunden im Google-Index erschienen, dauerte das bei Vite-SPA-Sites häufig Wochen — manchmal Monate. Die Search Console zeigte Status wie „Erkannt, derzeit nicht indexiert" oder „Gecrawlt, aber nicht indexiert" über lange Zeiträume.
Zweitens, lückenhafte Indexierung. Häufig wurde nur die Startseite ranking-relevant erfasst, während Unterseiten — gerade dynamisch erzeugte oder deep-nested Routen — gar nicht oder nur teilweise im Index landeten. Sites mit zehn oder mehr Routen hatten oft nur zwei bis drei davon tatsächlich auffindbar bei Google.
Drittens, fehlende Rich Snippets. Auch wenn eine Seite indexiert war, fehlten oft die Anreicherungen — keine Sitelinks, keine FAQ-Snippets, keine Breadcrumb-Anzeige in den SERPs. Das senkte die Click-Through-Rate spürbar gegenüber Wettbewerbern mit traditionell gerenderten Sites.
Viertens, AI-Such-Systeme sahen praktisch nichts. ChatGPT, Claude, Perplexity und vergleichbare Systeme haben (bisher) keine vollständige JavaScript-Rendering-Fähigkeit. Sie crawlen das initial ausgelieferte HTML — und das war bei Vite-SPA-Sites praktisch leer. Konsequenz: Lovable-Sites wurden in AI-Antworten nicht zitiert, auch wenn sie inhaltlich relevant gewesen wären.
Ein konkretes Praxis-Beispiel zeigt das Ausmaß:
Eine typische Lovable-Vite-SPA-Site mit zehn Routen hatte beim Crawler-Test (Screaming Frog mit deaktiviertem JavaScript-Rendering) etwa 50–150 Bytes „echten" Body-Content pro Route — bestehend aus dem leeren Root-Div und dem Script-Tag. Im Vergleich dazu hatte eine traditionell server-gerenderte Site mit gleichem Inhalt etwa 8.000–15.000 Bytes pro Route.
Mit anderen Worten: Aus Suchmaschinen-Sicht war eine Vite-SPA-Site nahezu inhaltslos. Dass Google trotzdem teilweise indexierte, lag nur an der nachgelagerten JavaScript-Rendering-Pipeline — die aber nicht bei jeder Seite zuverlässig griff, nicht zeitnah lief, und bei AI-Such-Systemen gar nicht existiert.
Drei Diagnose-Schritte für eigene Lovable-Sites
Bevor man entscheidet, ob eine Migration nötig ist, muss man wissen, ob die eigene Site überhaupt betroffen ist — und wenn ja, wie schwer. Drei Diagnose-Schritte, die in einer halben Stunde durchführbar sind:
Diagnose-Schritt 1 — View-Source-Test
Der einfachste Test: Beliebige Lovable-Site öffnen, Rechtsklick → „Seitenquelltext anzeigen" oder Strg+U drücken. Es öffnet sich der rohe HTML-Quellcode, den der Server ausgeliefert hat. Wichtig: nicht „Element untersuchen" verwenden, denn das zeigt das gerenderte DOM, nicht das ausgelieferte HTML.
Was zu prüfen ist: Sieht man im Quelltext den eigentlichen Seiten-Content — also die Headlines, Texte, Listen? Oder sieht man nur ein leeres <div id="root"> plus ein JavaScript-Bundle-Tag?
Wenn der Content im Quelltext steht, ist die Site server-gerendert (oder pre-rendered). Wenn nur die leere Hülle zu sehen ist, ist die Site eine klassische SPA mit allen damit verbundenen SEO-Problemen.
Diagnose-Schritt 2 — Crawler-Test ohne JavaScript
Ein präziser Test mit Screaming Frog (kostenlos für bis zu 500 URLs):
1. Screaming Frog SEO Spider starten
2. Configuration → Spider → Rendering → JavaScript: deaktivieren
3. URL der Site eingeben, crawlen
4. Bei jeder URL prüfen:
- Word Count (Spalte „Word Count")
- Body Content (Spalte „Body Content" — falls aktiviert)
Bei einer gesunden Site sollten die Word Counts pro URL zwischen 200 und 2.000+ Wörtern liegen. Wenn alle URLs Word Counts unter 50 zeigen, ist die Site SPA-bedingt SEO-problematisch.
Alternative für Nutzer ohne Screaming Frog: Curl-Befehl im Terminal:
curl -A "Mozilla/5.0" https://meine-lovable-site.com/
Wenn der ausgegebene HTML-Code praktisch leer ist (nur Header, leeres Root-Div, Script-Tag), liegt das Problem vor.
Diagnose-Schritt 3 — Google Search Console Indexierungs-Status
In der Google Search Console unter „Seiten" prüfen:
- Wie viele URLs sind „indexiert"?
- Wie viele URLs sind „nicht indexiert" (mit Detail-Ursachen)?
- Welche Status-Hinweise zeigen sich? Häufige Indikatoren für SPA-Probleme sind „Erkannt, derzeit nicht indexiert" oder „Gecrawlt, aber nicht indexiert".
Wenn eine Site mehr als 50 % ihrer URLs als „nicht indexiert" zeigt, ist das ein deutlicher SPA-SEO-Indikator. Plus: in der Search Console unter „URL-Prüfung" einzelne URLs prüfen — dort zeigt Google explizit, welcher Inhalt erfasst wurde.
Was die Diagnose-Ergebnisse zusammen ergeben
Die drei Schritte zusammen geben ein klares Bild:
- Quelltext leer + Crawler zeigt 0–50 Wörter + Search Console zeigt 50%+ nicht indexiert: klassisches Vite-SPA-Problem, Migration sinnvoll
- Quelltext gefüllt + Crawler zeigt 200+ Wörter + Search Console zeigt >80% indexiert: bereits server-gerendert oder pre-rendered, Migration nicht nötig
- Mischbild (Quelltext leer, aber Search Console zeigt gute Indexierung): Google rendert JavaScript erfolgreich, aber AI-Such-Systeme bleiben außen vor
Was sich mit dem TanStack-Update technisch geändert hat
Lovable hat am 20. April 2026 die zugrunde liegende Architektur für neue Projekte fundamental gewechselt. Statt Vite-SPA mit React kommt jetzt TanStack Start mit Server-Side Rendering zum Einsatz.
Was TanStack Start technisch ist
TanStack Start ist ein Full-Stack-React-Framework, das ähnliche Probleme löst wie Next.js, Remix oder SvelteKit — aber mit einem expliziten Fokus auf moderne TypeScript-Integration und Type-Safety bei Routing. Es nutzt unter der Haube Nitro als Server-Engine (das gleiche Server-Framework, das auch Nuxt 3 nutzt) und kann auf verschiedenen Hosting-Plattformen deployed werden.
Für SEO sind drei technische Eigenschaften von TanStack Start entscheidend:
Erstens, echtes Server-Side Rendering. Wenn ein Browser eine URL anfordert, generiert TanStack Start auf dem Server das vollständige HTML — inklusive aller Seiteninhalte, Headings, Texte. Erst danach wird die Response ausgeliefert. Das bedeutet: Suchmaschinen-Crawler erhalten beim ersten Request bereits den kompletten Inhalt.
Zweitens, automatische Hydration auf Client-Seite. Nachdem das fertig gerenderte HTML im Browser ankommt, übernimmt React und „hydratisiert" die statische Markup mit interaktiver Funktionalität. Aus Nutzer-Sicht funktioniert die Seite anschließend wie eine normale interaktive Web-Anwendung — aber der initiale Render war server-seitig.
Drittens, type-safe Routing mit File-based Routes. TanStack Start nutzt eine Datei-basierte Routing-Konvention, ähnlich Next.js — Dateien im routes/-Ordner werden automatisch zu Routen. Das ermöglicht statische Site-Generierung für Routen, die das benötigen, plus dynamische Server-seitige Generierung für andere.
Was sich aus SEO-Sicht konkret ändert
Mit TanStack Start ändert sich das SEO-relevante Verhalten in fünf Punkten:
- HTML-Body bei initialem Request: bisher ~50–150 Bytes (leere Hülle), jetzt 5.000–50.000 Bytes (vollständiger Inhalt) — je nach Routen-Komplexität
- Time to First Byte (TTFB) bei Suchmaschinen-Crawlern: bisher relevant durch nachträgliches Rendering, jetzt direkt aussagekräftig
- Indexierungs-Geschwindigkeit: bisher Wochen, jetzt typischerweise 24–72 Stunden für neue URLs
- Rich-Snippet-Eligibility: bisher inkonsistent, jetzt durch saubere Schema.org-Implementation direkt nutzbar
- AI-Such-System-Sichtbarkeit: bisher praktisch null, jetzt vollständig
Was Lovable bei der TanStack-Implementierung richtig gemacht hat
Drei Aspekte der konkreten Lovable-TanStack-Implementierung sind bemerkenswert positiv:
Erstens, automatische Meta-Tag-Generierung pro Route. Lovable bietet jetzt Standard-Meta-Tags (Title, Description, Open Graph) als konfigurierbare Felder pro Seite. Das war in der Vite-SPA-Phase ein Schwachpunkt — Meta-Tags wurden client-seitig nachträglich gesetzt, was viele Crawler nicht mitbekommen haben.
Zweitens, JSON-LD-Schema-Support out of the box. Strukturierte Daten können jetzt deklarativ in Lovable-Beiträgen eingefügt werden, ohne komplexe Konfiguration.
Drittens, automatische Sitemap-Generierung. Lovable generiert eine sitemap.xml mit allen statisch generierten Routen plus hreflang-Alternates für mehrsprachige Sites — eine Funktion, die in der Vite-SPA-Phase manuell implementiert werden musste.
Wo Lovable noch Lücken hat
Drei Bereiche, in denen die TanStack-Implementierung trotz Verbesserungen noch nachzubessern ist: feingranulare Schema.org-Kontrolle (komplexe Schema-Konfigurationen sind oft manuell zu implementieren), Build-Performance bei großen Sites (50+ Routen können 5–15 Minuten Build-Zeit haben), und Headless-CMS-Integration (Strapi/Storyblok-Anbindungen müssen aktuell selbst orchestriert werden).
Warum bestehende Projekte nicht automatisch migriert werden
Eine der wichtigsten Erkenntnisse für Bestandskunden: Das TanStack-Update gilt nur für neue Projekte. Sites, die vor dem 20. April 2026 mit Lovable erstellt wurden, laufen weiterhin auf der Vite-SPA-Architektur und behalten alle damit verbundenen SEO-Probleme.
Warum gibt es keinen automatischen Migrations-Pfad
Die Gründe sind technisch nachvollziehbar, aber wirtschaftlich für Bestandskunden frustrierend:
Erstens, Architektur-Wechsel ist nicht per Update möglich. Vite-SPA und TanStack Start unterscheiden sich in Build-Pipeline, Routing-Konventionen, State-Management-Pattern und Component-Lifecycle. Ein automatischer Konverter müsste alle diese Aspekte verstehen — was technisch sehr aufwändig wäre und in vielen Fällen zu fehlerhaften Resultaten führen würde.
Zweitens, Custom Code wäre nicht migrierbar. Viele Lovable-Projekte enthalten Custom-Komponenten oder externen Code, der spezifisch auf Vite-SPA-Pattern abgestimmt ist. Ein automatischer Konverter müsste auch diesen Code anpassen — was unvorhersehbare Fehler erzeugen kann.
Drittens, Lovable hat sich für klare Trennung entschieden. Statt einen halbgaren Migrations-Pfad anzubieten, hat Lovable bewusst die saubere Trennung gewählt: alte Projekte bleiben auf alter Architektur, neue Projekte starten auf neuer.
Was das für Bestandskunden bedeutet
Wer eine Lovable-Site vor dem 20. April 2026 begonnen hat, steht vor einer Entscheidung: das Projekt manuell auf TanStack neu aufbauen, bei Vite-SPA bleiben und Pre-Rendering-Workarounds nutzen, oder die Plattform wechseln. Welche Option die richtige ist, hängt von der konkreten Mandate-Realität ab.
Drei Migrations-Pfade — mit ehrlichem Aufwand-Wirkung-Vergleich
Wer eine Migrations-Entscheidung treffen muss, sollte die drei Optionen ehrlich gegenüberstellen — mit realistischem Aufwand, realistischer Wirkung und realistischen Risiken.
Pfad 1 — Manueller Neuaufbau in frischem Lovable-Projekt
Aufwand: Bei einer Site mit 10–15 Routen typisch 12–25 Arbeitsstunden, verteilt über 2–3 Wochen — der wirtschaftliche Hauptvorteil von Lovable gegenüber klassischer Entwicklung. Bei größeren Sites (25+ Routen) oder komplexen Komponenten 25–50 Stunden und 3–5 Wochen. Diese Werte basieren auf eigenen Calvarius-Migrations-Projekten und schließen Iterations-Schleifen ein, die in der Praxis oft anfallen (Layout-Korrekturen, Animations-Tuning, Schema-Validierung).
Wirkung: Maximal. Site läuft danach vollständig auf TanStack Start mit allen SEO-Vorteilen. Indexierungs-Geschwindigkeit verbessert sich signifikant, AI-Such-System-Sichtbarkeit kommt vollständig.
Risiken: Inhalte müssen manuell übertragen werden, Custom-Komponenten ggf. neu gebaut, Design wirkt nach Migration oft leicht anders, alte und neue Site müssen währenddessen parallel gepflegt werden.
Wann sinnvoll: Wenn die Site wirtschaftlich relevant ist (mindestens 5–10 organische Leads pro Monat), wenn der Inhalt überschaubar groß ist (max 30–40 Routen), und wenn 4–8 Wochen Migrations-Zeitraum verfügbar sind.
Pfad 2 — Pre-Rendering-Workaround
Aufwand: Bei Standard-Setups mit Prerender.io oder Rendertron typisch 4–12 Stunden für Setup, plus laufende Kosten von 30–150 Euro pro Monat (je nach Site-Größe und Service-Tier).
Wirkung: Mittel. Suchmaschinen-Crawler bekommen vor-gerenderte HTML-Versionen, was die Indexierung deutlich verbessert. Echte Nutzer bekommen weiterhin die SPA-Version.
Risiken: AI-Such-Systeme funktionieren oft trotzdem nicht, Cloaking-Risiko (theoretisch), Pre-Render-Cache muss aktiv gepflegt werden, zusätzliche Architektur-Komplexität.
Wann sinnvoll: Wenn Migration aus Ressource-Gründen nicht möglich ist, wenn die Site klein ist (unter 20 Routen), wenn AI-Such-Sichtbarkeit nicht prioritär ist, wenn schnelle SEO-Verbesserung in 1–2 Wochen wichtiger ist als saubere Architektur. In der Praxis ist Pfad 2 selten die wirtschaftlich beste Wahl — der Aufwand-Vorteil gegenüber Pfad 1 ist mit Lovable so klein, dass die strukturellen Nachteile (begrenzte AI-Sichtbarkeit, laufende Service-Kosten) in den meisten Fällen schwerer wiegen.
Pfad 3 — Wechsel zu anderer Plattform
Aufwand: Sehr unterschiedlich. Bei Wechsel zu Next.js, Astro oder Nuxt 3 typisch 60–150 Stunden, je nach Site-Komplexität. Plus laufende Kosten für eigenes Hosting.
Wirkung: Maximal, mit zusätzlicher Flexibilität. Plattform-spezifische Limitierungen entfallen, eigene Architektur möglich.
Risiken: Höherer technischer Anspruch, Hosting-Komplexität, längere Time-to-Market, weniger No-Code-Flexibilität für Folge-Iterationen.
Wann sinnvoll: Wenn Lovable spezifische Limitierungen kritisch sind, die Site sehr individuell ist, ein erfahrenes Entwicklungs-Team verfügbar ist, oder langfristig maximale Kontrolle gewünscht ist.
Vergleichs-Tabelle
| Aspekt | Pfad 1 (Lovable-Neuaufbau) | Pfad 2 (Pre-Render) | Pfad 3 (Plattform-Wechsel) |
|---|---|---|---|
| Aufwand initial | 12–50h | 4–12h | 60–150h |
| Laufende Kosten | gleich wie Lovable | +30–150 EUR/Monat | eigenes Hosting |
| SEO-Wirkung | maximal | mittel | maximal |
| AI-Such-Sichtbarkeit | vollständig | partiell | vollständig |
| No-Code-Flexibilität | hoch | hoch | niedrig |
| Time-to-Production | wenige Tage | 1–2 Wochen | 4–10 Wochen |
Was über SSR hinaus für SEO konfiguriert werden muss
Server-Side Rendering ist die Voraussetzung — aber allein nicht ausreichend. Wer eine TanStack-Lovable-Site SEO-optimal aufsetzen will, muss zusätzlich neun Bereiche sauber konfigurieren.
Erstens — Heading-Hierarchie strukturell sauber halten. Pro Seite genau eine H1, klare H2-Strukturierung pro Sektion, H3 für Unter-Inhalte. Card-Headlines sollten H3 sein, nicht H2 — sonst entstehen 15–20 H2 pro Seite, was die SEO-Hierarchie schwächt.
Zweitens — Internal Linking strukturell aufbauen. Cross-Links zwischen verwandten Seiten sind ein wichtiger Ranking-Faktor. Bei Lovable müssen diese aktiv gepflegt werden — von der Hauptseite zu den Detailseiten, zwischen verwandten Detailseiten, von Service-Seiten zu Blog-Beiträgen.
Drittens — Schema.org-Markup vollständig implementieren. Lovable bietet Standard-Schemas (Organization, WebPage), aber komplexere Schema-Types brauchen manuelle Konfiguration: ProfessionalService oder LocalBusiness für die Site-weite Verortung, Service für jede Service-Detailseite, Article oder TechArticle für Blog-Beiträge, FAQPage für FAQ-Sektionen, BreadcrumbList für jede Seite mit Breadcrumb, Person für Author-Verweise.
Viertens — Canonical-URLs konsistent setzen. Pro Seite muss genau eine Canonical-URL existieren. Bei mehrsprachigen Sites zeigt jede Sprach-Version auf sich selbst als Canonical, mit hreflang-Alternates zu den anderen Sprachen.
Fünftens — sitemap.xml mit hreflang-Alternates. Die Sitemap muss alle relevanten URLs enthalten, mit <xhtml:link rel="alternate" hreflang="..." />-Tags für mehrsprachige Sites. Plus ein lastmod-Tag pro URL, das wirklich gepflegt wird.
Sechstens — robots.txt sauber konfigurieren. Lovable generiert eine Default-robots.txt, die meist okay ist. Aber prüfen: keine versehentliche Blockierung von /static/, /assets/ oder JavaScript-Dateien. Auch der Sitemap-Verweis muss korrekt sein.
Siebtens — Open Graph und Twitter Cards. Pro Seite muss og:title, og:description, og:url, og:image gesetzt sein. Plus twitter:card="summary_large_image" und entsprechende Twitter-Tags. Das og:image muss bewusst gestaltet werden, sonst zeigt jede Seite das gleiche Default-Bild.
Achtens — Performance-Metriken im Auge behalten. Core Web Vitals (LCP, INP, CLS) sind Ranking-Faktoren. TanStack Start hilft strukturell, aber Bilder, Fonts und Third-Party-Scripts können trotzdem Performance-Probleme machen. Lighthouse-Audits regelmäßig laufen lassen.
Neuntens — Content-Tiefe und Keyword-Disziplin. SSR allein bringt nichts, wenn die Inhalte zu dünn sind. Mindestens 300–500 Wörter pro relevanter Seite, Primär-Keyword in Title, H1 und ersten 100 Wörtern, Sekundär-Keywords organisch eingestreut. Bei Pillar-Content 1.500–5.000 Wörter.
AI-Suchsysteme — was sich für ChatGPT, Claude und Perplexity ändert
Eines der wichtigsten Argumente für die TanStack-Migration ist die AI-Such-System-Sichtbarkeit. Hier liegt die größte Veränderung — und gleichzeitig der größte Wettbewerbsvorteil für Sites, die früh auf SSR umstellen.
Wie AI-Such-Systeme heute Inhalte erfassen
ChatGPT, Claude, Perplexity und vergleichbare Systeme nutzen unterschiedliche AI-Crawler-Architekturen, aber haben drei Gemeinsamkeiten: Sie crawlen primär das initial ausgelieferte HTML (im Gegensatz zu Google haben die meisten AI-Crawler keine vollständige JavaScript-Rendering-Pipeline), sie bevorzugen klar strukturierte Inhalte, und sie zitieren Quellen unterschiedlich (ChatGPT mit aktiviertem Browsing, Perplexity prominent neben jeder Antwort, Claude weniger formalisiert).
Was AI-Such-Sichtbarkeit bei Vite-SPA bedeutete
Konkret: AI-Crawler haben bei Vite-SPA-Sites praktisch nichts gesehen. Wenn ein User ChatGPT fragt „welche Performance-Marketing-Agenturen gibt es in Würzburg", konnte ChatGPT keine Lovable-SPA-Site zitieren — selbst wenn sie inhaltlich perfekt zur Anfrage passte. Die Site existierte aus AI-Sicht praktisch nicht.
Was sich mit TanStack Start ändert
Mit echtem SSR sehen AI-Crawler den vollständigen Inhalt beim ersten Request. Das hat fünf konkrete Konsequenzen:
- Sites werden zitierbar in AI-Antworten — die Substanz ist erkennbar
- Konkrete Aussagen werden als Snippets verwendet — wer mit klaren, faktischen Aussagen schreibt, wird häufiger zitiert
- FAQ-Sektionen funktionieren als Antwort-Quellen — wenn ein User eine Frage stellt, die in einer FAQ-Sektion beantwortet ist, kann das AI-System direkt zitieren
- Author-Schema und Publisher-Verweise werden gewertet — AI-Systeme prüfen, wer Inhalte schreibt
- Aktualisierungs-Datum wird wichtiger — AI-Systeme bevorzugen aktuelle Inhalte für aktuelle Fragen
Was zusätzlich getan werden kann — über SSR hinaus
Drei Pattern, die in der Praxis AI-Such-Sichtbarkeit verbessern: klare Definitionen am Sektions-Anfang („X ist Y" als Eröffnungs-Satz), strukturierte FAQ-Sektionen mit FAQPage-Schema im JSON-LD, und konkrete Zahlen und Fakten („Sites mit 5.000+ monatlichen Conversions" funktioniert besser als „große Sites").
Häufige Fehler bei der Migration
Aus Praxis-Erfahrung mit mehreren TanStack-Migrations-Projekten — sieben Fehler, die immer wieder auftauchen und die wirtschaftlich schmerzhaft sind.
Fehler 1 — Migration ohne URL-Konsistenz. Beim Neuaufbau in einem frischen Lovable-Projekt werden URLs oft anders strukturiert als in der alten Site. Wenn diese URL-Änderungen nicht mit 301-Redirects abgesichert sind, verliert die Site ihre Search-Console-Historie und bestehende Backlinks zeigen ins Leere. Lösung: Vor Migration alle existierenden URLs dokumentieren, neue URLs definieren, 301-Redirects einrichten.
Fehler 2 — Heading-Hierarchie nicht migriert. Beim inhaltlichen Übertragen wird oft nur der Text kopiert, aber die Heading-Auszeichnungen gehen verloren oder werden inkonsistent neu vergeben. Lösung: Vor Migration Heading-Hierarchie pro Seite dokumentieren, beim Wiedereinbau exakt übernehmen.
Fehler 3 — Schema.org-Daten gehen verloren. JSON-LD-Strukturen, die in der alten Site manuell eingefügt waren, werden bei Migration oft vergessen. Lösung: Pro Seite prüfen, welche Schemas existieren, beim Wiedereinbau alle übertragen. Schema.org-Validator nach Migration durchlaufen.
Fehler 4 — Canonical-URLs zeigen ins Leere. Bei der Migration ändern sich die Canonical-URLs. Wenn alte Canonicals weiterhin in der Sitemap oder in JSON-LD-Schemas auftauchen, gibt es Indexierungs-Konflikte. Lösung: Alle Canonical-URLs nach Migration auf neuen Stand prüfen, Sitemap regenerieren.
Fehler 5 — hreflang-Tags inkonsistent. Bei mehrsprachigen Sites werden hreflang-Tags oft nicht oder unvollständig migriert. Konsequenz: Google indexiert beide Sprach-Versionen als getrennte, konkurrierende Sites. Lösung: Pro Seite hreflang-Tags zu allen Sprach-Versionen plus x-default sicherstellen — reziprok.
Fehler 6 — Performance-Optimierungen vergessen. TanStack Start ist strukturell schneller als Vite-SPA, aber Bilder, Fonts und Third-Party-Scripts können Performance trotzdem zerstören. Lösung: Bilder optimieren (WebP, korrekte Größen, lazy-loading), Fonts mit font-display: swap, Third-Party-Scripts minimieren oder asynchron laden.
Fehler 7 — Search Console nicht angepasst. Die alte Site bleibt nach Migration oft eine Weile in der Search Console — was zu Duplicate-Indexierung führen kann. Lösung: Search Console direkt nach Migration prüfen, alte und neue URL-Versionen aktiv managen, ggf. Domain-Migration formal in Search Console signalisieren.
Wann sich eine Migration nicht lohnt
Ehrlichkeits-Sektion: Nicht jede Lovable-Site profitiert von einer Migration. Drei Szenarien, in denen der Aufwand wirtschaftlich nicht gerechtfertigt ist.
Szenario 1 — Sehr kleine Site mit niedriger Performance-Erwartung. Wenn eine Lovable-Site nur 3–5 Routen hat und nicht primär als Lead-Generator funktioniert (z.B. eine reine Visitenkarten-Site, die hauptsächlich über direkten Domain-Aufruf besucht wird), ist Migration meist unwirtschaftlich.
Szenario 2 — Site, die ohnehin in 6–12 Monaten neu gebaut wird. Wenn ein Relaunch sowieso geplant ist, lohnt sich Zwischen-Migration nicht. Stattdessen das Relaunch-Projekt direkt auf TanStack aufsetzen — und in der Zwischenzeit mit Pre-Render-Workaround leben.
Szenario 3 — Site mit sehr individuellen Custom-Komponenten. Wenn die alte Lovable-Site stark mit Custom-Code angereichert ist, der spezifisch auf Vite-Pattern abgestimmt ist, kann der Migrations-Aufwand explodieren. In dem Fall ist Plattform-Wechsel zu Next.js, Astro oder ähnlich oft sinnvoller.
Wann sich Migration trotzdem lohnt — auch bei kleineren Sites
Wenn die Site wirtschaftlich relevant ist (auch nur 2–3 Leads pro Monat über organische Suche), wenn AI-Such-System-Sichtbarkeit strategisch wichtig ist, oder wenn die Site Teil eines größeren Marken-Auftritts ist, der konsistent erscheinen muss — dann lohnt sich Migration auch bei kleineren Setups.