Lovable hat SSR ausgeliefert. Was es löst — und was nicht.

Seit einer Weile habe ich überlegt, von Lovable wegzumigrieren.

Nicht weil etwas kaputt war. Die App funktioniert. Das Design hält. Kunden mögen es. Aber dot2.solutions hatte ein SEO-Problem, das in die Architektur eingebacken war. Lovable lieferte als clientseitige SPA aus, was bedeutete, dass jeder Crawler, der zählt — Google, LinkedIns Preview-Bot und nun die ChatGPT- und Claude-Browsing-Agenten, die Antworten aus dem Live-Web beziehen — eine leere Div sah, bis JavaScript ausgeführt wurde. Kein Ranking. Keine GEO (generative engine optimization). Unsichtbar für die Modelle, die die Leute zunehmend statt zu suchen befragen.

Also habe ich begonnen, Alternativen zu evaluieren. Vercel mit einem Next.js-Rebuild war der naheliegende Pfad. Rocket.new sah interessant aus. Bolt.new war auf der Liste. Ich hatte einige Wochen Recherche hinter mir — ich habe schon eine Weile damit gekämpft.

Dann habe ich ein neues Lovable-Projekt geöffnet, um die KI zu fragen, ob sie etwas in Next.js rebuilden könnte. Hier ist, was sie zurückgesagt hat:

Ich kann das nicht in Next.js rebuilden — dieses Lovable-Projekt läuft auf TanStack Start (React 19 + Vite), nicht Next.js. Next.js wird hier nicht unterstützt. Die gute Nachricht: TanStack Start gibt dir alles, was du aufgelistet hast — SSR, file-based Routing, Per-Page-Meta, Server Functions, Edge-Deployment — also können wir deine App mit vollem SSR rebuilden, einfach mit TanStack Start statt Next.js.

So habe ich herausgefunden, dass Lovable leise SSR ausgeliefert hat.

Was sich tatsächlich geändert hat

Ab dem 20. April 2026 werden neue Lovable-Projekte auf TanStack Start mit vollständigem Server-Side Rendering ausgeliefert. Echtes HTML. Crawlbare Seiten. Meta-Tags, die beim ersten Durchlauf im Browser ankommen, nicht erst, nachdem JavaScript beschlossen hat, auszuführen.

TanStack Start ist ein Full-Stack-React-Framework auf Basis von Vite — demselben Tooling, das Lovable bereits nutzte. Anfang 2026 erreichte es den Release-Candidate-Status und gewinnt als glaubwürdige Alternative zu Next.js an Bedeutung. Anders als Next.js verfolgt es einen Client-First-Ansatz: Du schreibst eine SPA, und SSR wird als Ergänzung darüber geschaltet. Das passt viel besser zum von Lovable generierten Code als das server-first, React Server Components-Mental Model, das Next.js vorschreibt. Vermutlich deshalb hat Lovable es gewählt.

Die praktischen Gewinne für neue Projekte sind real — Googles Crawler bekommt echtes HTML beim ersten Laden, LLM-Browsing-Agenten erhalten eine Seite, die sie tatsächlich lesen und zitieren können, Social Cards funktionieren ohne Build-Time-Injection-Hacks, der First Paint ist schneller, weil Inhalt nicht auf JavaScript wartet, und Server Functions geben dir typsichere Backend-Aufrufe ohne separate API-Schicht.

Unter der Haube

Für alle, die sich fragen, was genau in der Box ist, hier der exakte Stack, mit dem ein frisches Lovable-Projekt heute ausgeliefert wird: React 19 mit TanStack Start auf Vite 7, TypeScript im Strict Mode, Tailwind v4 mit einem echten Design System (oklch-Tokens, Custom Typography), shadcn/ui auf Radix-Primitives, file-based Routing via TanStack Router, TanStack Query für Daten, und Cloudflare Workers Edge Deployment by default.

Einige dieser Entscheidungen zählen über SSR hinaus. Cloudflare Workers Edge bedeutet, dass Crawler und LLM-Agenten die Antwort in Millisekunden überall auf der Welt erhalten — und Antwortlatenz ist ein Ranking-Faktor. Die moderne Toolchain (Vite 7, TanStack-Ökosystem) hält Builds schnell und Output sauber, was zählt, wenn das Projekt wächst.

Ich habe das an einem frischen Projekt getestet, das ich hochgefahren habe — voller Inhalt im Response Body, Meta-Tags im Head, keine JavaScript-Ausführung nötig, um die Seite zu lesen. Die neuen Defaults liefern.

TanStack Start vs Next.js für SEO

Faire Frage, die ich während meiner Recherche ständig gestellt habe: Ist TanStack Start tatsächlich so gut wie Next.js für SEO, oder hat Lovable einfach die leichtere Option gewählt? So vergleichen sie sich auf dem, was zählt.

Bei den Fundamenten, die Rankings bewegen — SSR, crawlables HTML, Meta-Tags, Sitemaps — liegen sie gleichauf. Next.js hat mehr Out-of-the-Box-Komfort: Die <Image>-Komponente übernimmt Format-Konvertierung und Grössenanpassung für dich, ISR ist nativ, und die Metadata API ist gut dokumentiert. Das ist fair — Next.js gibt es länger, und Vercel hat massiv in die SEO-Oberfläche investiert.

TanStack Start hält bei den Fundamenten mit und schlägt Next.js bei Deployment-Flexibilität. Nitro erlaubt Shipping auf Cloudflare, Netlify, Deno, Bun, Node oder sonstwo ohne Lock-in. Das Framework bringt zudem einen LLM-Optimierungs-Guide in seiner offiziellen Doku mit, was ein kleines, aber erzählendes Signal ist, dass das Team über die Zukunft der Suche nachdenkt, nicht nur über ihre Vergangenheit. Und für ein Lovable-generiertes Projekt ist die Vite-basierte Toolchain eine sauberere Passform als Next.js' dogmatisches Build-System.

Für eine Site, die auf Google ranken und von LLMs zitiert werden soll, erledigen beide den Job. Keiner ist ein Kompromiss.

Was sich nicht geändert hat

Hier ist der Haken, den die KI nicht freiwillig genannt hat: Wenn dein Lovable-Projekt vor dem 20. April existierte, läufst du noch auf dem alten clientseitigen Vite-Template. Kein Migrationsbutton. Kein automatisierter Upgrade-Pfad. Lovable hat bestehende Projekte nicht automatisch migriert — und das ist konsistent damit, wie Framework-zu-Framework-Migrationen typischerweise ablaufen, weil sie nie vollständig automatisiert sind. Unterschiedliche Routing-Semantiken, unterschiedliche Data-Loading-Patterns, unterschiedliche Komponenten-Grenzen, unterschiedliche Build-Outputs.

Was bedeutet: Das SEO- und GEO-Problem, das mich fast von der Plattform getrieben hätte, sitzt immer noch dort auf dem alten Stack.

Was ich konkret tun würde

Ich bin genau in dieser Situation, also hier ist der Plan, den ich umsetze.

Blog zu Ghost umziehen. Diese Woche.

Das ist der Ort, an dem SEO- und GEO-Geschwindigkeit tatsächlich zählen. Marketing-Sites ranken für Branded Searches — dein Name, deine Firma, deine Services. Dieser Traffic landet, sobald die Leute bereits wissen, dass du existierst. Der Blog ist der Ort, an dem du um Long-Tail-Search konkurrierst, um LLM-Zitationen und um Content, der sich vervielfacht. Ghost ist SSR-nativ, speziell für Content gebaut, und liefert Structured Data, RSS, korrekte Meta-Tags und saubere URLs ohne eigenen Bauaufwand. Löse zuerst die Content-Schicht.

Für die bestehende Marketing-Site — Workarounds gibt es.

Ich habe meine gebaut, und sie halten. Ob ein kompletter Rebuild auf dem neuen Stack sich lohnt, hängt davon ab, wie viel die alte Architektur dich tatsächlich kostet. Für dot2.solutions reichen meine Workarounds aus, sodass ein Rebuild nicht dringend ist. Für content-lastigere Projekte — besonders Kundensites, bei denen organische Suche der primäre Akquisitionskanal ist — lohnt sich der Rebuild, und ich plane genau das für mehrere meiner Projekte.

Für neue Projekte einfach auf Lovable bauen.

Der grösste Grund, den ich woanders gesucht habe, ist weg. SEO und GEO sind nun auf Plattformebene gelöst. Das ändert die Rechnung für jeden, der Lovable vor sechs Monaten abgelehnt hat, weil seine Site nicht ranken würde.

Wo mich das lässt

Das, was mich fast von Lovable getrieben hätte, ist gelöst. Ich bleibe.

Neue Kundenprojekte werden auf dem neuen Stack gebaut. Einiges meiner bestehenden Arbeit bleibt auf dem alten Stack mit Workarounds. Der Blog zieht diese Woche zu Ghost um, weil dort Content-Geschwindigkeit tatsächlich zählt.

Und das, worüber ich wirklich begeistert bin: Ghost stellt eine vollständige Admin API bereit — programmatisches Erstellen, Bearbeiten und Verwalten des gesamten Zugriffs auf alles auf der Plattform. Was bedeutet, dass ich meinen kompletten Blog-Workflow direkt in Lovable rebuilden kann, mit Ghost als SSR-natives Content-Backend. Beide Plattformen spielen ihre Stärken aus. Wird grossartig.

Die Content- und Wissensschicht bleibt mein Eigentum — kein Plattform löst diesen Teil für dich. Aber die Infrastrukturschicht ist gerade merklich besser geworden, und das ändert, wer auf dieser Plattform sein sollte. Wenn du Lovable abgelehnt hast, weil deine Site nicht ranken oder in einer KI-Antwort auftauchen würde, lohnt sich ein neuer Blick.

Was als Nächstes kommt

Ich werde teilen, wie die Migration tatsächlich läuft — das Ghost-Setup, der Lovable-getriebene Publishing-Workflow und was unterwegs bricht. Wenn du dieselben Entscheidungen abwägst, folge auf LinkedIn oder schreib mir.