Lovable hat jetzt SSR. Sichtbar in der KI-Suche sind Sie damit noch nicht.
Seit dem 13. Mai 2026 werden neue Lovable-Apps standardmäßig serverseitig gerendert. Die leere HTML-Hülle, die Lovable-Seiten für KI-Crawler unlesbar machte, ist bei neuen Projekten Geschichte, und ältere Projekte liefern verifizierten Crawlern jetzt vorgerenderte Seiten aus. Das Rendering-Problem ist gelöst. Sichtbarkeit in der KI-Suche ist ein anderes Problem, und laut Lovables eigener Dokumentation bleibt es Ihres.
Dieser Artikel begann im April als Warnung. Ein Gründer zeigte mir seine Lovable-Seite, und jeder Crawler-Test lieferte ein leeres Div zurück, wo der Inhalt stehen sollte. Dann kam Lovables Fix, und die Warnung brauchte eine Überarbeitung. Hier steht, wie die Lage heute ist.
Was Lovable im Mai 2026 behoben hat
Bis zum Frühjahr war jedes Lovable-Projekt eine React-Single-Page-App. Der Server schickte ein leeres <div id="root"></div>, und JavaScript baute die Seite im Browser zusammen. Für Menschen in Ordnung, für KI-Crawler nutzlos. Glenn Gabe von GSQi hat in Tests bestätigt, dass ChatGPT, Perplexity und Claude rohes HTML abrufen und kein JavaScript ausführen. Was in der ersten Antwort fehlt, existiert für sie nicht.
Zwei Änderungen haben diese Ära beendet, beide in Lovables Changelog dokumentiert:
- Neue Apps ab dem 13. Mai 2026 laufen auf TanStack Start mit serverseitigem Rendering. Jede Anfrage liefert vollständig gerendertes HTML, an Menschen wie an Crawler. Enterprise-Workspaces folgten am 22. Juni.
- Ältere React-plus-Vite-Apps erhalten On-Request-Prerendering auf ihren öffentlich deployten URLs. Lovable liefert verifizierten Crawlern einen gerenderten Schnappschuss aus: Google, Bing, Social-Preview-Bots und KI-Engines wie ChatGPT, Perplexity, Claude und Gemini.
Wer heute eine Lovable-Seite veröffentlicht, ist für die großen KI-Engines lesbar. Wer Ihnen etwas anderes erzählt, arbeitet mit Informationen von vor Mai. Das gilt auch für ältere curl-Tests: Ein externer Scanner ist kein verifizierter Crawler und bekommt auf älteren Seiten weiterhin die leere Hülle. Über das, was die echten Bots sehen, sagt das nichts aus.
Wo die Lücken bleiben
Rendering ist der Boden, nicht die Decke. Drei Lücken bleiben.
Die Liste verifizierter Crawler ist kurz. Das Prerendering älterer Seiten deckt eine benannte Liste von Bots ab, sonst nichts. Kleinere KI-Engines, Agent-Browser, die für ihre Nutzer recherchieren, und jeder Abrufer außerhalb der Liste bekommen weiterhin die leere Hülle. Nur neue TanStack-Start-Apps liefern vollständiges HTML an jeden Besucher. Das Prerendering gilt zudem nur für öffentlich deployte URLs, Previews und unveröffentlichte Projekte bleiben unsichtbar.
Metadaten, Schema und Sitemaps bleiben Handarbeit. Lovables Dokumentation listet auf, was Sie weiterhin selbst anstoßen müssen: eindeutige Titel und Beschreibungen pro Route, strukturierte Daten, Sitemap-Pflege, robots.txt-Regeln und Open-Graph-Tags. Die Plattform kann viele dieser Korrekturen anwenden, wenn Sie ihren Agenten darum bitten. Von selbst stellt sie sie nicht bereit. Der unabhängige Leitfaden von Rasesh Koirala kommt zum selben Ergebnis: SSR erzeugt weder korrekte SEO-Tags noch strukturierte Daten.
Gerendertes HTML ist noch kein zitierfähiges HTML. KI-Engines zitieren Seiten, die eine Frage im ersten klaren Satz beantworten und deren Abschnitte auch als Auszug für sich stehen, mit Schema-Markup für die Entitäten. Das ist redaktionelle Arbeit. Kein Rendering-Modus nimmt sie Ihnen ab, weder bei Lovable noch anderswo.
| Ebene | Stand nach dem Update |
|---|---|
| Vollständiges HTML für Google, Bing und große KI-Engines | Bei neuen Apps gelöst; ältere Apps für verifizierte Bots abgedeckt |
| Vollständiges HTML für andere Agenten und Scanner | Nur neue Apps; ältere Apps liefern weiter die leere Hülle |
| Titel und Meta-Beschreibungen pro Route | Handarbeit, pro Route anstoßen und prüfen |
| Strukturierte Daten | Handarbeit |
| Sitemap-Pflege und robots.txt | Handarbeit |
| Answer-First-Struktur im Content | Redaktionelle Arbeit, fortlaufend |
Wann sich eine Migration zu Next.js weiterhin lohnt
Das Argument für einen eigenen Next.js-SSG-Code hat sich verschoben. Rendering ist nicht mehr der Hauptgrund. Eigentum ist es. Sie bekommen ein Standard-Repository, mit dem jeder Entwickler und jeder Coding-Agent arbeiten kann, statische Seiten mit starken Core Web Vitals ohne Feintuning und keine Abhängigkeit von der Rendering-Pipeline oder Crawler-Liste einer Plattform. Wenn Lovable seinen Stack erneut ändert, ist das deren Roadmap-Entscheidung, nicht Ihre.
Der DIY-Weg mit Claude Code oder OpenAI Codex funktioniert unverändert: Code exportieren, vom Agenten als Next.js-App-Router-Projekt mit statischer Generierung neu bauen lassen, jede Datei prüfen, zu GitHub pushen, auf Vercel deployen, DNS umstellen. Planen Sie echte Zeit für die Prüfung ein. Als Cloudflares Entwickler Anfang des Jahres Next.js mit KI-Coding-Agenten nachgebaut haben, lieferten sie in einer Woche und berichteten trotzdem von stetigem manuellem Korrekturbedarf. Der Agent übernimmt die Routinearbeit. Die Urteilsfragen bleiben bei Ihnen.
Was das für Sie heißt, wenn Sie mit Lovable gebaut haben
Drei Prüfungen, der Reihe nach. Erstens: Wann wurde Ihr Projekt erstellt? Vor dem 13. Mai 2026 heißt, Ihre öffentliche Seite liefert echtes HTML an die großen verifizierten Crawler und eine leere Hülle an alle anderen. Entscheiden Sie, ob dieser Rest für Ihr Geschäft zählt. Zweitens: Öffnen Sie den Quelltext und suchen Sie pro Route nach Titel, Meta-Beschreibung und Schema. Fehlen sie, rettet Sie kein Rendering-Modus, weil nichts da ist, das zitiert werden könnte. Drittens: Klären Sie, wozu die Seite da ist. Eine Broschüre läuft auf Lovables Standardeinstellungen inzwischen gut. Ein Wachstumskanal braucht die Metadaten-, Schema- und Content-Ebene, die sich weiterhin nicht von selbst baut.
Diese Ebene ist unsere Arbeit. webentity migriert Lovable-Seiten als einmalige Lieferung in einen sauberen Next.js-SSG-Code. Sie bekommen das Repository, das Deployment und die DNS-Übergabe, und der Code bleibt danach mit Claude Code oder Codex bearbeitbar, weil es ein Standard-Next.js-Projekt ist. Ist die Website ein Wachstumskanal, hält der Grow-Plan die Schema- und Content-Arbeit nach dem Launch täglich in Bewegung. Sehen Sie, was wir bauen und wie es bei Alveni funktioniert hat.