Lovable Website selbst hosten — warum es nicht so einfach ist und wie man es richtig macht

Lovable ist beeindruckend. In wenigen Minuten entsteht eine vollständige Website — mit Design, Inhalt und Struktur. Viele meiner Kunden haben genau dort angefangen. Das Problem: Lovable hostet auf der eigenen Infrastruktur, du bist abhängig vom Abo, und die generierten Seiten sind technisch gesehen Single Page Applications (SPAs) — was für SEO und Performance alles andere als ideal ist.

Wer seine Lovable-Website auf eigenem Hosting betreiben möchte, stellt schnell fest: es ist nicht damit getan, die Dateien einfach hochzuladen.

Was Lovable im Hintergrund erzeugt

Lovable generiert React-Apps mit Vite. Das bedeutet:

• Alle Seiten werden client-seitig gerendert — der Browser baut die Seite auf, nicht der Server
• Die gesamte App steckt in einer einzigen index.html
• Routing läuft über JavaScript (react-router-dom), nicht über echte Dateipfade
• Google Fonts werden vom CDN geladen
• Es gibt keine serverseitige SEO — kein <title>, keine <meta description> pro Seite beim ersten Laden

Das Problem beim einfachen Hochladen

Wenn du die Lovable-Ausgabe (den dist/-Ordner) einfach auf normales Webhosting lädst, passiert folgendes:

• Routing bricht zusammen — /leistungen zeigt 404, weil keine physische Datei existiert
• Google indexiert nur eine Seite — der Crawler sieht überall dieselbe leere index.html
• PageSpeed schlägt Alarm — keine Core Web Vitals Optimierung, kein Preloading, kein statisches HTML
• Google Fonts blockieren das Laden — DSGVO-Problem als Bonus

Das ist kein Fehler von Lovable — es ist einfach nicht für klassisches Shared Hosting konzipiert.

Was ist mit Prerendering? (und warum ich es nicht empfehle)

Google und viele KI-Tools empfehlen häufig Prerendering als schnelle Lösung: Ein Tool wie Prerender.io oder ein eigener Puppeteer-Server rendert die SPA im Hintergrund und liefert dem Googlebot eine fertige HTML-Version. Klingt clever — und in der Theorie funktioniert es.

In der Praxis habe ich damit schlechte Erfahrungen gemacht. Google hat die Seiten trotzdem nicht vollständig indexiert. Der Crawler konnte nicht den kompletten Seiteninhalt lesen, obwohl das Prerendering technisch aktiv war. Das Ergebnis: Seiten ranken kaum oder gar nicht, weil Google intern anscheinend eine andere Version sieht als das, was das Prerender-Tool liefert.

Dazu kommt: Prerendering ist ein Workaround, kein echter Fix. Du fügst eine weitere Infrastruktur-Schicht hinzu, die gewartet werden muss, zusätzliche Kosten verursacht und bei Updates von Lovable wieder außer Sync geraten kann. Das Problem — JavaScript-gerenderte Inhalte — wird damit nicht gelöst, sondern nur kaschiert.

Meine Empfehlung: Prerendering überspringen und direkt auf statisches HTML setzen. Astro macht genau das, aber ohne den Overhead.

Die richtige Lösung: Migration zu Astro

Astro ist ein Static Site Generator, der React-Komponenten unterstützt — aber das Richtige damit macht. Statt einer SPA generiert Astro echte HTML-Dateien pro Seite. Das Ergebnis:

• Jede Seite hat ihre eigene index.html mit vollständigem Inhalt
• Google kann jede Seite einzeln crawlen und indexieren
• <title> und <meta description> werden pro Seite serverseitig gesetzt
• Ladezeiten unter 1 Sekunde sind die Regel, nicht die Ausnahme
• Läuft auf jedem normalen Webhosting — kein Node.js, kein spezieller Server nötig

Der Migrationsprozess umfasst mehr als nur Code-Umschreiben: Lokale Fonts statt Google CDN, PHP-Mailer für Kontaktformulare, .htaccess für korrektes Routing, FAQPage-Schema für Rich Snippets in Google.

Was ist mit Content-Management?

Für viele Unternehmen reicht eine statische Astro-Website völlig aus — Texte und Bilder ändern sich selten, und Änderungen können direkt im Code vorgenommen werden.

Wer aber regelmäßig Inhalte wie Blogbeiträge, Angebote oder News selbst pflegen möchte, ohne in den Code eingreifen zu wollen, kann ein Headless CMS einbinden:

• TinaCMS — visueller Editor direkt auf der Website, kostenlos nutzbar
• Decap CMS (ehemals Netlify CMS) — einfaches Git-basiertes Interface, Open Source
• Sanity — mächtiges CMS für komplexere Projekte mit eigenem Studio

Der Vorteil: Das CMS verwaltet nur den Inhalt. Die Website bleibt statisch, schnell und SEO-optimiert. Kein WordPress, keine Plugins, keine Sicherheitsupdates.

Wann macht eine Migration Sinn?

• Du hast eine Lovable-Website und willst nicht dauerhaft Abo zahlen
• Deine Website rankt nicht bei Google, obwohl der Inhalt gut ist
• PageSpeed zeigt schlechte Werte und du weißt nicht warum
• Du willst volle Kontrolle über Hosting, Datenschutz und Performance

Meine Erfahrung: allinkl Hosting + Astro = SEO-Erfolg

Ich habe selbst bereits mehrere Websites auf allinkl-Hosting migriert und betreibe auch meine eigene Website d1ma.de auf diesem Weg. Das Ergebnis spricht für sich: Seiten, die vorher bei Google kaum sichtbar waren, ranken jetzt auf den ersten Positionen — ohne bezahlte Anzeigen, ohne Tricks.

allinkl ist deutsches Hosting mit PHP-Support, was genau das richtige für statische Astro-Sites mit PHP-Kontaktformular ist: schnell, DSGVO-konform, und kein Overhead durch unnötige Serverinfrastruktur. Die kombinierten Vorteile aus technisch sauberem HTML, lokalem Font-Hosting und korrekt aufgebautem SEO zahlen sich direkt in Rankings aus.

Was ich anbiete

Ich migriere Lovable-Websites zu Astro — mit vollständiger SEO-Optimierung, lokalem Font-Hosting (DSGVO-konform), korrektem Routing und optionaler CMS-Anbindung. Das Ergebnis läuft auf deinem eigenen Hosting (z. B. allinkl), ohne Abhängigkeit von externen Diensten oder monatlichen Abo-Kosten.

Wenn du wissen willst, was für deine Website konkret möglich ist: kostenlose Erstanalyse anfragen.