Lovable SEO: 43 deutschsprachige Websites im Test und was du vor dem Livegang prüfst

Ja, Lovable-Websites können bei Google gefunden werden und ranken wie andere Web-Apps. Was ein Crawler bekommt, hängt aber vom Stack ab: Apps, die seit dem 13. Mai 2026 erstellt wurden, rendern jede Seite auf dem Server. Ältere Apps entstehen erst im Browser, und Lovable schickt nur verifizierten Crawlern wie Google und Bing eine vorgerenderte Kopie. Wir haben am 16. Oktober 2026 43 deutschsprachige Lovable-Websites geprüft. Die neueren lieferten fertigen Text und echte 404-Fehler. Die Lücken lagen meist bei Dingen, die du selbst erledigen musst: Sprachangabe, Sitemap, Canonical auf der eigenen Domain und, bei älteren Apps, ein Impressum, das ohne JavaScript leer bleibt.

Kurz gesagt: Was für Lovable-Websites bei Google gilt

• Neuere Apps, erstellt ab dem 13. Mai 2026 (in Enterprise-Workspaces ab dem 22. Juni 2026), laufen auf TanStack Start mit serverseitigem Rendering, kurz SSR. Jeder Besucher und jeder Crawler bekommt eine fertige Seite.
• Ältere Apps laufen auf React und Vite und werden im Browser gebaut. Eine vorgerenderte Kopie bekommen nur verifizierte Crawler: Suchmaschinen wie Google und Bing, die Crawler von KI-Suchen, Vorschau-Bots sozialer Netzwerke und laut Lovable inzwischen auch verifizierte SEO-Tools. Alle anderen bekommen eine fast leere Seite.
• Seit dem 28. Juli 2026 kannst du eine ältere App direkt im Projekt auf TanStack Start umstellen.
• Die Grundlagen bleiben deine Aufgabe: Titel und Beschreibung pro Seite, die richtige Sprachangabe, robots.txt, Sitemap, Canonical-Tags und echte 404-Fehler.
• Eigene Domain: Lovable leitet zwischen verbundenen Domains nur mit 302 weiter, nicht mit 301. Canonical und Sitemap müssen deshalb selbst auf deine Domain zeigen.
• Impressum und Cookies: Prüf, ob dein Impressum ohne JavaScript lesbar ist und welche Cookies schon beim ersten Aufruf gesetzt werden. Lovables eigene Besucherstatistik setzt eines.

Wenn dir Begriffe wie Crawling, Rendering und Indexierung neu sind, lies zuerst unseren Ratgeber SEO einfach erklärt.

Neuer oder alter Stack? So erkennst du deine App

Drei kurze Prüfungen zeigen dir den Stack:

1. Quelltext ansehen: Öffne eine veröffentlichte Seite und drück Strg+U, am Mac Wahl+Befehl+U. Stehen deine Überschriften und Texte im Quelltext, rendert die Seite auf dem Server. Siehst du fast nur ein leeres <div id="root"></div> und ein Skript unter /assets/, ist es der ältere Stack.
2. Erfundene Adresse aufrufen: Öffne mit F12 die Entwicklertools, Reiter „Netzwerk“, und ruf eine Adresse auf, die es nicht gibt, etwa mit dem Pfad /gibt-es-nicht. Steht beim ersten Eintrag der Statuscode 404, ist alles richtig. Ältere Apps antworten mit 200 und zeigen trotzdem eine Fehlerseite.
3. Im Code nachsehen: Bei TanStack-Start-Projekten steht im Code-Tab des Editors in der Datei package.json der Eintrag @tanstack/react-start. Du kannst Lovable auch im Chat fragen, welchen Stack dein Projekt nutzt.

In unserem Test passten die ersten beiden Prüfungen immer zusammen: Alle 26 Websites mit Text im Quelltext antworteten auf die erfundene Adresse mit 404, alle 16 mit leerer Hülle mit 200.

Unser Test: 43 deutschsprachige Lovable-Websites

Am 16. Oktober 2026 haben wir 43 öffentlich erreichbare deutschsprachige Websites aus Deutschland, Österreich und der Schweiz, die bei Lovable gehostet sind, je einmal ohne JavaScript und einmal in einem Browser mit JavaScript abgerufen und dazu robots.txt, Sitemap, eine erfundene Adresse sowie Impressum und Datenschutzerklärung geprüft.

Gefunden haben wir sie über eine Websuche nach typischen deutschen Begriffen wie Impressum, Termin vereinbaren, Praxis oder Handwerk und im öffentlichen Verzeichnis madewithlovable.com. 35 laufen unter einer lovable.app-Adresse, 8 unter einer eigenen Domain. 5 stammen aus Österreich, 3 aus der Schweiz. Meist sind es kleine Betriebe wie Restaurants, Salons, Praxen, Handwerker und Agenturen, dazu einige Web-Apps. 10 von 53 Kandidaten haben wir vorher aussortiert: 4 waren offline, 3 liefen nicht mehr bei Lovable, 3 waren nicht deutschsprachig.

Drei Grenzen: Wir sind kein verifizierter Crawler und haben gesehen, was SEO-Scanner und kleinere Bots bekommen; die vorgerenderte Kopie, die ältere Apps an Google schicken, konnten wir nicht abrufen. Viele lovable.app-Adressen können Entwürfe oder Designvorschläge sein, wir wissen nur, dass sie öffentlich erreichbar waren. Und die Auswahl ist keine Zufallsstichprobe: Die Zahlen gelten für unseren Test, nicht für alle Lovable-Websites. Namen nennen wir nicht.

Neuere Apps: fertiges HTML und echte 404-Fehler

Die 26 Websites auf TanStack Start schickten Hauptüberschrift und Text schon im ersten HTML, ohne JavaScript. Im Median waren das 3.789 Zeichen Text und 27 Links. Nur bei einer kam fast die Hälfte des Textes erst mit JavaScript dazu. Die erfundene Adresse beantworteten alle 26 mit einem echten 404.

Damit bekommen alle Crawler dieselbe Seite wie deine Besucher. Google nennt serverseitiges Rendering oder Pre-Rendering in seiner Anleitung zu JavaScript-SEO „trotzdem eine sehr gute Option“, weil die Website schneller wird und nicht alle Bots JavaScript ausführen können.

Fertig ist eine neuere App damit aber nicht:

• 8 der 26 hatten keine robots.txt, obwohl Lovable laut Doku jedem neuen Projekt eine anlegt. Ob die Datei gelöscht wurde oder die Projekte aus der Zeit vor dieser Regel stammen, wissen wir nicht.
• Nur 11 der 26 hatten eine sitemap.xml.
• 13 der 26 meldeten im Code Englisch als Sprache der Seite.
• 14 der 26 hatten kein Canonical-Tag auf der Startseite.

Alles zusammen, also echte 404-Fehler, robots.txt und Sitemap, hatten nur 11 der 43 Websites. Alle 11 waren neuere Apps.

Ältere Apps: leere Hülle für alle, die nicht verifiziert sind

Bei den 16 älteren Apps sah es ohne JavaScript ganz anders aus. Keine einzige schickte eine Hauptüberschrift im HTML. Bei neun bestand der ganze sichtbare Text aus den zwei Wörtern „Edit with“ vom Lovable-Abzeichen, bei den anderen sieben gab es gar keinen. Im Median enthielt das HTML einen einzigen Link. Erst im Browser mit JavaScript erschien die eigentliche Seite, und bei vier Websites wechselte dabei sogar der Titel.

Dazu kommen zwei Probleme, die Google selbst beschreibt:

• Jede Adresse antwortet mit 200. Alle 16 älteren Apps beantworteten unsere erfundene Adresse mit 200 statt 404. Google warnt vor solchen Soft-404-Fehlern in Single-Page-Apps und nennt zwei Auswege: eine JavaScript-Weiterleitung auf eine Adresse, die mit 404 antwortet, oder ein noindex per JavaScript auf der Fehlerseite. Soft-404-Fehler meldet Google in der Search Console.
• Ein noindex im ersten HTML kann laut Google dazu führen, dass die Seite gar nicht gerendert wird. Es per JavaScript wieder zu entfernen, funktioniert dann womöglich nicht.

Google, Bing und die anderen verifizierten Crawler bekommen von Lovable eine vorgerenderte Kopie. Google nennt dieses Muster dynamisches Rendering: eine fertige Fassung für Crawler, eine JavaScript-App für Menschen. Es sei eine Behelfslösung gewesen und keine langfristige Lösung, schreibt Google, und empfiehlt stattdessen serverseitiges Rendering, statisches Rendering oder Hydration. Cloaking ist es laut Google nicht, solange die Inhalte ähnlich sind. Laut Lovable landen Inhalte, die mit der Seite laden, meist in der Kopie; später nachgeladene Inhalte können fehlen.

Was Google tatsächlich bekommt, siehst du im URL-Prüftool der Search Console: Klick auf „Live-URL testen“ und dann auf „Getestete Seite anzeigen“, dort findest du das HTML und einen Screenshot. Lovable verweist selbst auf diesen Weg.

Lovable hat seine SEO-Doku zwischen dem 13. und dem 16. Oktober 2026 umgeschrieben. Neu ist: Auch „verifizierte SEO-Tools“ bekommen die Kopie. Welche das sind, steht dort nicht, und die Seite zum Hosting schreibt weiterhin, SEO-Scanner von Drittanbietern seien keine verifizierten Crawler und könnten Seiten als leer melden. Ebenfalls neu: Wer eine Seite als Markdown anfordert, bekommt auf beiden Stacks eine Markdown-Fassung; so lesen laut Lovable KI-Assistenten deine Website. Wie man sie anfordert, beschreibt die Doku nicht.

Upgrade auf TanStack Start: wann es sich lohnt

Wenn dir Besucher aus Google, Bing oder KI-Suchen wichtig sind, empfehlen wir das Upgrade. Danach bekommen alle dieselbe fertige Seite, und fehlende Seiten liefern echte 404-Fehler. Seit dem 28. Juli 2026 geht das direkt im bestehenden Projekt:

• im Chat / eintippen und Migrate to TanStack Start wählen,
• in Project settings → General → Project actions bei Migrate to TanStack Start auf Migrate klicken,
• oder Lovable im Chat darum bitten; vor dem Start erscheint eine Karte mit dem Knopf Start migration.

Laut Lovable gilt dabei:

• Das Upgrade verbraucht Credits wie andere Änderungen, je nach Größe des Projekts.
• Deine veröffentlichte Website bleibt unverändert, bis du neu veröffentlichst. Zurück kommst du über die Versionsgeschichte.
• Titel, Beschreibungen, Vorschau-Tags und Analyse-Skripte zieht Lovable in die neue Vorlage um.
• Manche Code-Bibliotheken funktionieren nur im Browser und können das Rendering auf dem Server stören. Teste deshalb vor dem Veröffentlichen jede Seite.

Ein Muss ist das Upgrade nicht. Ältere Apps werden weiter vorgerendert, und laut Lovable brauchen bei Lovable gehostete Projekte keinen externen Prerendering-Dienst. Dieses Vorab-Rendering gehört aber zum Hosting von Lovable. Hostest du den Export einer älteren App woanders, prüf dort mit „Live-URL testen“, was Google bekommt.

Vorsicht bei älteren Anleitungen: Mehrere deutsche Ratgeber zu Lovable und SEO, die wir am 16. Oktober gelesen haben, schreiben noch, ältere Projekte ließen sich nicht oder nur schwer umstellen. Zwei datieren den Wechsel auf den 20. April 2026. Laut Lovable ist TanStack Start seit dem 13. Mai der Standard für neue Apps.

Titel, Beschreibung und Vorschaubild für jede Seite

Titel und Meta Description erzeugt Lovable laut Doku beim Bauen für jede Seite einzeln, dazu ein Favicon. Das Vorschaubild für soziale Netzwerke wählt Lovable beim Ausliefern: ein Bild, das du festgelegt hast, oder den neuesten Screenshot deiner App. Ändern kannst du das über den Chat, auch für einzelne Unterseiten; das verbraucht Credits und wird mit dem nächsten Veröffentlichen live. Kontrollieren kannst du es im Publish-Dialog: Im Menü ⋮ findest du Social & search appearance mit den Karten Social und Search.

Bei den neueren Apps in unserem Test hatten alle 26 einen eigenen Titel. Bei den älteren fanden wir Reste der Vorlage:

• 4 Websites hießen im Titel noch „Lovable App“, eine trug nur ihren Hostnamen.
• Eine hatte als Beschreibung noch „Lovable Generated Project“, 3 deutsche Websites eine englische Meta Description.
• 3 nutzten Lovables Standard-Vorschaubild.

Über beide Stacks hinweg stand auf 9 Websites im Meta-Tag author noch Lovable, auf 12 verwies twitter:site auf ein Konto von Lovable. Das schadet nicht, zeigt aber, dass niemand die Vorlage angepasst hat. Das Abzeichen „Edit with Lovable“ war auf 25 der 43 Websites sichtbar. Ausblenden kannst du es ab dem Pro-Tarif unter Project settings → General → Publishing → Hide Lovable badge.

Lovables SEO-Prüfung meldet unter anderem doppelte Titel über mehrere Routen und Platzhaltertexte. Wie lang ein Titel sein darf, bevor Google ihn kürzt, steht in unserem Ratgeber zum SEO-Title.

Sprachangabe im Code: 20 von 43 Websites melden Englisch

Ganz oben im HTML steht, in welcher Sprache eine Seite geschrieben ist, etwa <html lang="de">. In unserem Test meldeten 20 der 43 deutschsprachigen Websites im ersten HTML lang="en", 13 neuere und 7 ältere Apps. Bei 2 änderte JavaScript die Angabe danach auf de, 18 blieben auch im Browser bei Englisch. Von den 5 österreichischen Websites meldeten 4 Englisch, von den 3 Schweizer eine. Keine Website nutzte einen Ländercode wie de-AT oder de-CH.

Google selbst liest die Angabe nicht: Google bestimmt die Sprache laut eigener Doku am sichtbaren Inhalt und verwendet keine Sprachangaben auf Codeebene wie das lang-Attribut. Trotzdem lohnt sich die Korrektur, denn Screenreader wählen damit die richtige Aussprache. Mehr dazu steht in unserem Ratgeber Internationales SEO. Lovables SEO-Prüfung meldet laut Doku, wenn das Attribut fehlt. Ob sie auch ein falsches en auf deutschem Text erkennt, steht dort nicht. Bitte Lovable also selbst, lang="de" zu setzen, und prüf das Ergebnis im Quelltext.

de genügt für eine deutschsprachige Website, auch in Österreich und der Schweiz. Ländercodes brauchst du erst, wenn du Länderfassungen per hreflang miteinander verbindest.

Mehrsprachige Websites: 4 der 43 Websites hatten hreflang-Angaben, alle mit x-default. Eine verwies per hreflang auf ihre eigenen lovable.app-Adressen, die auf die eigene Domain umleiten. Eine andere hatte nach dem Laden jede Angabe doppelt, einmal mit und einmal ohne Schrägstrich am Ende. Laut Google nennt jede Fassung sich selbst und alle anderen, im HTML, im HTTP-Header oder in der Sitemap. Wie du Sprach- und Länderfassungen wie de-AT und de-CH richtig verbindest, zeigt unser Ratgeber zu hreflang, x-default und Canonical.

robots.txt und Sitemap: was Lovable anlegt und was fehlt

Lovables SEO-Doku sagt seit ihrer Überarbeitung im Oktober 2026: Lovable legt mit jedem neuen Projekt eine robots.txt an, aber nicht immer eine Sitemap, und die Metadaten am Anfang sind allgemein gehalten. Das passt zu unserem Test:

• robots.txt: 35 der 43 Websites hatten eine, alle 16 älteren und 18 der 26 neueren Apps. 15 davon waren Lovables unveränderte Standarddatei: fünf Gruppen für Googlebot, Bingbot, Twitterbot, facebookexternalhit und alle anderen, jede mit Allow: /, ohne Zeile Sitemap:. Das schadet nicht, verschenkt aber den Hinweis auf die Sitemap.
• Sitemap-Zeile: 18 robots.txt-Dateien nannten eine Sitemap, 7 davon auf einem anderen Host, etwa einer älteren Domain, einer ganz anderen Domain oder der lovable.app-Adresse einer Website mit eigener Domain.
• sitemap.xml: 19 der 43 Websites hatten eine, mit zusammen 1.789 Adressen. 8 dieser 19 Sitemaps hatten Fehler: 6 listeten Adressen auf einem anderen Host, 2 nur relative Pfade ohne Domain. Laut Google gehören in eine Sitemap vollständige, absolute URLs, und Lovables SEO-Prüfung meldet relative URLs und fremde Hosts ebenfalls.
• Gesperrte Seiten: 2 robots.txt-Dateien sperrten /impressum und /datenschutz für alle Crawler. Warum das nicht hilft, steht im Abschnitt zum Impressum.

Umlaute in Adressen: Keine der 1.789 Sitemap-Adressen enthielt einen Umlaut oder ein prozentkodiertes Zeichen. Die Pfade waren durchweg umschrieben, etwa zu ueber, koeln, muenchen oder aerzte. Google empfiehlt Wörter in der Sprache deiner Leser und erlaubt solche Umschreibungen; Umlaute in Links werden prozentkodiert. Was das für deine Keywords bedeutet, erklärt unser Ratgeber Keywords platzieren.

Eigene Domain: 302, Canonical und die lovable.app-Adresse

Eigene Domains gibt es bei Lovable nur in bezahlten Tarifen. Du wählst eine primäre Domain, und alle anderen verbundenen Domains leiten mit einem 302 dorthin weiter, also vorübergehend. Eine 301-Weiterleitung zwischen den Domains eines Projekts unterstützt Lovable nicht, damit du die primäre Domain später wieder ändern kannst. Die Projektadresse unter lovable.app lässt sich laut Doku nicht entfernen. Die Weiterleitung von www auf die Hauptdomain ist standardmäßig eingeschaltet.

In unserem Test antworteten alle 5 lovable.app-Adressen, die zu einer Website mit eigener Domain gehören, mit 302: für Startseite, robots.txt, Sitemap und erfundene Adresse. Google folgt einem 302, wertet ihn laut eigener Doku aber nicht als Signal, dass das Ziel die kanonische Adresse ist. Die alte Adresse kann also im Index bleiben.

Umso wichtiger sind die anderen Signale. Bei 2 der 8 Websites mit eigener Domain zeigten aber Canonical, Sitemap-Zeile und Sitemap-Adressen noch auf die lovable.app-Adresse, die ihrerseits auf die Domain umleitet. Insgesamt hatten nur 15 der 43 Websites ein Canonical im ersten HTML, 7 davon nur als relativen Pfad /. Bei einer älteren App zeigte das Canonical im HTML auch auf den Unterseiten, die wir geöffnet haben, auf die Startseite, und JavaScript fügte ein zweites hinzu. Google rät zu absoluten Adressen im Canonical und, falls JavaScript es setzt, zu genau einem Tag pro Seite.

So machst du es richtig:

• Das Canonical jeder Seite zeigt als vollständige Adresse auf die Seite selbst, unter deiner eigenen Domain.
• Die Sitemap enthält nur Adressen deiner Domain, und die Zeile Sitemap: in der robots.txt nennt dieselbe Domain.
• Du bestätigst deine Domain in der Search Console und reichst die Sitemap dort ein. Nach einem Domainwechsel musst du laut Lovable neu bestätigen.

Wie Canonical-Tags funktionieren, erklärt unser Ratgeber zum Canonical-Tag. Was 301, 302, 307 und 308 bedeuten und wie du einen Umzug planst, steht im Ratgeber zum Website-Relaunch.

Impressum und Datenschutzerklärung: auffindbar und lesbar?

Keine Rechtsberatung: Wir beschreiben nur, was wir technisch gesehen haben. Ob dein Impressum vollständig ist, klärst du mit einer Fachperson.

In Deutschland verlangt § 5 DDG von geschäftsmäßigen digitalen Diensten bestimmte Angaben, etwa Name, Anschrift und E-Mail-Adresse, die leicht erkennbar, unmittelbar erreichbar und ständig verfügbar sein müssen. Das Digitale-Dienste-Gesetz gilt seit dem 14. Mai 2024 und hat das Telemediengesetz (TMG) abgelöst. Für Österreich und die Schweiz gelten eigene Regeln; einen Überblick gibt unser Ratgeber Internationales SEO.

Das haben wir gefunden:

• Link auf der Startseite: 27 der 43 Startseiten hatten einen Link mit dem Wort „Impressum“, 22 auf eine eigene Seite und 5 auf einen Abschnitt derselben Seite. 16 hatten keinen. Einen Link zur Datenschutzerklärung hatten 26. Von den 8 Websites aus Österreich und der Schweiz hatten 5 keinen Impressum-Link.
• Lesbar ohne JavaScript: 20 Impressumsseiten haben wir geöffnet, alle antworteten mit 200. Bei den 11 neueren Apps und der Website mit eigenem Vorab-Rendering stand der Text schon im HTML. Bei den 8 älteren Apps stand dort nichts vom Impressum, und 7 davon schickten sogar den Titel der Startseite mit. Der Text erschien erst mit JavaScript. Was Google über die vorgerenderte Kopie bekommt, konnten wir nicht prüfen; jedes nicht verifizierte Programm sieht eine leere Seite.
• Gesetzesverweise: 9 der 20 Impressumsseiten nannten das TMG, 7 davon nur das TMG. Das DDG nannten 8. Eine österreichische Website verwies auf das E-Commerce-Gesetz und das Mediengesetz.
• Gesperrt oder ausgeschlossen: 2 Websites sperrten /impressum und /datenschutz in der robots.txt, 4 setzten auf dem Impressum noindex. Das noindex ist eine bewusste Entscheidung. Eine Sperre in der robots.txt hält eine Seite laut Google dagegen nicht zuverlässig aus der Suche: Verlinken andere Seiten darauf, kann die Adresse trotzdem erscheinen, nur ohne Beschreibung. Dafür empfiehlt Google noindex oder einen Passwortschutz.

In Lovables Beschreibung der SEO-Prüfung kommen Impressum und Datenschutzerklärung nicht vor. Prüf deshalb selbst: Verlinke beide Seiten auf jeder Seite mit echten Links, sperr sie nicht in der robots.txt, und stell bei einer älteren App per Upgrade oder mit „Live-URL testen“ sicher, dass der Text ankommt.

Cookies, Google Fonts und Lovables Besucherstatistik

Auch hier gilt: keine Rechtsberatung, nur Beobachtungen. Wir haben jede Startseite mit geleertem Browser einmal geladen, ohne zu klicken, und Cookies sowie Anfragen an fremde Server ausgewertet.

• Lovables Besucherstatistik lief auf 41 der 43 Websites, eingebunden als Skript /~flock.js. Auf allen 41 lag danach ein Cookie namens session-id mit einer zufälligen Sitzungskennung, von der Website selbst gesetzt und gültig für 30 Minuten. So steht es auch im Code des Skripts, den wir am 16. Oktober gelesen haben. In den Projekteinstellungen heißt die Funktion Visitor analytics und ist standardmäßig eingeschaltet.
• Ein zweites Cookie, __dpl, setzte Lovables Hosting auf 39 der 43 Websites zusammen mit der Seite. Wofür es dient, beschreibt die Doku nicht. Auf 7 der 8 Websites mit eigener Domain kam __cf_bm von Cloudflare dazu. Cloudflare beschreibt es als Cookie für die Bot-Erkennung, das nach 30 Minuten ohne Aktivität abläuft.
• Google Fonts luden 21 der 43 Websites direkt von Googles Servern. Lovable schreibt, dass es Google Fonts selbst einbindet; web-sichere Schriften wie Arial oder Georgia laden laut Lovable keine externen Ressourcen.
• Werbung und Statistik: 4 Websites luden schon beim ersten Aufruf Dienste von Google für Werbung oder Statistik, eine davon zusätzlich Pixel von Meta, LinkedIn und Pinterest, eine andere Contentsquare. Eine fünfte lud die Web-Statistik von Cloudflare. 14 Websites schickten keine einzige Anfrage an einen fremden Server.
• Cookie-Hinweise zeigten 14 der 43 Websites, alle selbst gebaut; keine lud das Skript einer bekannten Consent-Plattform. Auf einer Website stand im Hinweis, sie verwende keine Cookies, während session-id schon gesetzt war.

Lovable schreibt, die Besucherstatistik messe den Verkehr insgesamt, nicht einzelne Personen, und erstelle keine Profile von Besuchern. Von Cookies steht in den Seiten der Doku, die wir dazu gelesen haben, nichts. Abschalten kannst du die Statistik unter Project settings → General → Publishing → Visitor analytics; danach sammelt Lovable laut Doku keine Daten mehr. Ob dann auch das Cookie wegfällt, siehst du in den Entwicklertools unter „Anwendung“ und „Cookies“.

In Deutschland regelt § 25 TDDDG, wann das Speichern von Informationen auf dem Gerät eine Einwilligung braucht und wann es ohne geht, weil es für einen ausdrücklich gewünschten Dienst unbedingt erforderlich ist. Ob das für session-id, __dpl oder __cf_bm zutrifft und wie du Schriften und externe Dienste einbindest, ist eine rechtliche Frage. Lass das prüfen, bevor du live gehst.

Bilder, Überschriften und strukturierte Daten: was schon gut läuft

Einiges erledigte Lovable in unserem Test zuverlässig:

• Alt-Attribute: Die 43 Startseiten enthielten nach dem Laden 825 Bilder, jedes mit einem alt-Attribut. 41 davon waren leer, das Bild ist damit als Schmuck markiert. Laut Google ist der Alt-Text das wichtigste Attribut für Bilder; stopf ihn aber nicht mit Keywords voll. Ob die Texte gut sind, sagt die Zahl nicht, das musst du selbst lesen.
• Eine Hauptüberschrift pro Seite: Nach dem Laden hatte jede der 43 Startseiten genau eine H1.
• Strukturierte Daten: 20 der 43 Websites hatten JSON-LD, 18 davon schon im ersten HTML. Meist waren es Untertypen von LocalBusiness wie Restaurant, Bakery, Physician oder HairSalon, auf 6 Websites kam FAQPage dazu. Fehlerhaftes JSON fanden wir nicht.

Prüf selbst noch die Links: Google folgt laut eigener Doku nur <a>-Elementen mit href-Attribut. Menüpunkte, die nur per Skript auf einen Klick reagieren, zählen nicht.

Lovables SEO-Prüfung und die Search Console

Die SEO-Werkzeuge liegen seit Mitte Oktober 2026 unter More → Analytics → SEO & AI; der alte Eintrag More → SEO & AI search führt nur noch dorthin. Die Prüfung startest du dort mit Run SEO scan. Sie ist in allen Tarifen enthalten, nur Try to fix und Try to fix all verbrauchen normale Credits. Laut Doku (Stand 16. Oktober 2026) prüft sie im Code Viewport, lang-Attribut, Metadaten, Open-Graph-Tags, strukturierte Daten, Überschriften und Alt-Texte, in der Vorschau Startseite, robots.txt und sitemap.xml, auf der veröffentlichten Website noindex und die Markdown-Fassung für KI-Crawler, und mit verbundener Search Console auch deren Einrichtung.

Typische Meldungen heißen etwa „Duplicate titles across routes“, „Canonical URLs point to the homepage“ oder „Shared links still show Lovable's branding“. Nicht oder nur teilweise bewertet werden laut Doku unter anderem Ladegeschwindigkeit, Inhaltsqualität und Suchintention; für die Geschwindigkeit verweist Lovable auf PageSpeed Insights, Lighthouse läuft nicht mehr mit.

Search Console: Lovable bestätigt deine Website mit Googles HTML-Tag und kann die Sitemap aus dem Chat einreichen. Veröffentliche vorher, denn Google liest die Sitemap von der Live-Website. Bei einer lovable.app-Adresse kannst du keine DNS-Einträge setzen, dort bleibt nur eine URL-Präfix-Property. Für deine eigene Domain geht auch eine Domain-Property, die alle Subdomains und Protokolle umfasst und per DNS bestätigt wird. Unveröffentlichte Projekte, Projekte mit eingeschränktem Zugriff und Adressen unter einer Workspace-Domain von Lovable erscheinen laut Doku nie in der Suche.

Seit dem 14. Oktober 2026 lässt sich in Lovable auch Bing Webmaster Tools anbinden, mit Klicks, Impressionen, Suchanfragen und Crawling-Statistiken. Adressen und Sitemaps kannst du darüber ebenfalls an Bing senden.

Checkliste vor dem Livegang

1. Stack prüfen: Quelltext ansehen und eine erfundene Adresse aufrufen.
2. Ältere App umstellen: Upgrade auf TanStack Start, danach jede Seite testen und erst dann veröffentlichen.
3. Titel und Beschreibung für jede Seite, ohne Reste wie „Lovable App“, dazu ein eigenes Vorschaubild.
4. Sprache setzen: lang="de" im <html>-Element, im Quelltext kontrolliert.
5. robots.txt mit einer Zeile Sitemap: auf deiner endgültigen Domain.
6. sitemap.xml mit vollständigen Adressen deiner endgültigen Domain.
7. Canonical auf jeder Seite als vollständige Adresse auf der endgültigen Domain, genau ein Tag pro Seite.
8. 404-Test: Eine erfundene Adresse muss mit 404 antworten.
9. Impressum und Datenschutzerklärung auf jeder Seite verlinkt, ihr Text im Quelltext, nicht in der robots.txt gesperrt.
10. Cookies und fremde Dienste beim ersten Aufruf in den Entwicklertools ansehen und rechtlich klären lassen.
11. Links als echte <a href>-Links, nicht als Knöpfe mit Skript.
12. Search Console verbinden, Sitemap einreichen und wichtige Seiten mit „Live-URL testen“ ansehen.
13. Zum Schluss Lovables SEO-Prüfung laufen lassen, Meldungen beheben, veröffentlichen und noch einmal scannen.