Lovable et le SEO : ce qu'il faut corriger avant de publier

Oui, un site créé avec Lovable peut être indexé et bien se positionner sur Google. Ce que reçoit un robot dépend toutefois de l'âge de l'appli : depuis le 13 mai 2026, les nouvelles applis sont rendues sur le serveur. Les plus anciennes se construisent dans le navigateur, et Lovable n'envoie une copie pré-rendue qu'aux robots qu'il a vérifiés, comme ceux de Google et de Bing. Le 17 octobre 2026, nous avons récupéré 18 sites Lovable en français, sans puis avec JavaScript. Le rendu fonctionne ; ce qui manque, ce sont surtout des réglages qui vous reviennent : langue de la page, sitemap, balise canonical et domaine propre.

En bref : ce que Google reçoit d'un site Lovable

• Applis créées depuis le 13 mai 2026 (le 22 juin 2026 pour les espaces Enterprise) : elles tournent sur TanStack Start, avec un rendu côté serveur (SSR). Visiteurs et robots reçoivent tous une page complète.
• Applis plus anciennes : elles tournent sur React et Vite. Lovable sert une copie pré-rendue aux seuls robots vérifiés : moteurs de recherche (Google, Bing), robots des recherches IA (ChatGPT, Perplexity, Claude, Gemini), robots d'aperçu des réseaux sociaux et, selon sa documentation, des « outils SEO vérifiés » qu'elle ne nomme pas. Les autres reçoivent une page presque vide.
• Depuis le 28 juillet 2026, une ancienne appli peut passer à TanStack Start dans le projet lui-même.
• Les bases restent à votre charge : titre et description de chaque page, attribut lang, robots.txt, sitemap, balise canonical et vraies erreurs 404.
• Domaine personnalisé : Lovable redirige entre vos domaines avec une 302, jamais une 301. La canonical et le sitemap doivent donc désigner eux-mêmes votre domaine.

Si les mots exploration, rendu et indexation vous sont nouveaux, commencez par notre guide c'est quoi le SEO.

Appli récente ou ancienne : trois vérifications

1. Le code source. Affichez la source d'une page publiée (Ctrl+U dans Chrome sous Windows, Option+Commande+U sur Mac). Si vos textes y figurent, la page est rendue sur le serveur. Si vous ne voyez guère qu'un <div id="root"></div> vide et un script sous /assets/, c'est l'ancienne pile.
2. Une adresse inventée. Ouvrez les outils de développement (F12), onglet Réseau (Network), puis une adresse qui n'existe pas, par exemple /cette-page-n-existe-pas. La première ligne doit afficher 404. Les anciennes applis répondent 200, même avec une page d'erreur à l'écran.
3. Le code du projet. Dans l'onglet Code de l'éditeur, le package.json d'un projet TanStack Start contient @tanstack/react-start. Vous pouvez aussi demander à Lovable, dans le chat, quelle pile utilise votre projet.

Dans notre test, la deuxième vérification a toujours séparé les deux familles : les 12 applis récentes répondaient 404 à l'adresse inventée, les 6 anciennes 200.

Notre test : 18 sites Lovable en français, avec et sans JavaScript

Le 17 octobre 2026, nous avons repris dans l'index public de Common Crawl (collecte de septembre 2026) les 20 adresses lovable.app dont le contenu est détecté comme français et qui y comptent le plus de pages. Pour chacune, une requête par adresse : robots.txt, page d'accueil sans JavaScript, la même page dans un navigateur avec JavaScript, une adresse inventée et /sitemap.xml. Nous avons écarté deux sites rédigés surtout en anglais. Restent 18 sites : 12 applis récentes et 6 anciennes ; deux redirigent vers leur propre nom de domaine.

Trois limites. Nous ne sommes pas un robot vérifié : nous avons vu ce que reçoivent les outils SEO et les petits robots, pas la copie pré-rendue que les anciennes applis envoient à Google. Certaines adresses lovable.app peuvent être des brouillons ; nous savons seulement qu'elles étaient publiques. Et l'échantillon n'est pas tiré au hasard : les chiffres valent pour notre test, pas pour tous les sites Lovable.

Nos deux relevés précédents allaient dans le même sens : 9 sites lovable.app en anglais le 13 octobre 2026, et 43 sites germanophones d'Allemagne, d'Autriche et de Suisse le 16 octobre 2026.

Applis récentes : du HTML complet et de vraies erreurs 404

Sur 10 des 12 applis récentes, le titre principal (H1) et le texte arrivaient dès le premier HTML, sans JavaScript ; en médiane, le HTML des 12 contenait plus de 3 500 caractères de texte et 35 liens. Sur une onzième, à peu près la moitié du texte n'apparaissait qu'avec JavaScript. La douzième n'affichait qu'une page d'introduction avec un bouton pour continuer : aucun texte dans le HTML et pas un seul lien, même après JavaScript. Or Google ne suit que les éléments <a> munis d'un attribut href.

Les 12 répondaient à l'adresse inventée par une vraie 404. Tous les robots reçoivent donc la même page que vos visiteurs, ce que Google préfère : selon son guide sur JavaScript, « l'affichage côté serveur ou le pré-affichage reste recommandé », car le site est plus rapide et tous les robots n'exécutent pas JavaScript.

Une appli récente n'est pas prête pour autant :

• 3 des 12 n'avaient pas de robots.txt, alors que Lovable dit en créer un avec chaque nouveau projet.
• 2 des 12 n'avaient pas de sitemap.xml.
• 4 des 12 n'avaient pas de balise canonical dans le HTML, et 2 autres n'indiquaient que le chemin relatif /.
• 5 des 12 déclaraient l'anglais comme langue de la page.

Vraie 404, robots.txt et sitemap réunis : 9 des 18 sites, tous des applis récentes. Dans le relevé allemand, c'était 11 sites sur 43 ; dans le relevé anglais, aucun sur 9.

Anciennes applis : une page vide pour les robots non vérifiés

Sans JavaScript, les 6 anciennes applis n'envoyaient ni H1, ni texte, ni lien : seulement l'élément root vide et des scripts. S'y ajoutent deux problèmes que Google décrit lui-même :

• Toutes les adresses répondent 200. Les 6 ont répondu 200 à notre adresse inventée, avec la même coquille vide et le titre de la page d'accueil. Google met en garde contre ces erreurs soft 404 dans les applications à page unique et propose deux parades : une redirection JavaScript vers une adresse qui répond 404, ou une balise noindex ajoutée par JavaScript sur la page d'erreur.
• Un noindex dans le HTML d'origine peut amener Google à sauter l'exécution du JavaScript ; le retirer ensuite par JavaScript risque de ne pas suffire.

La copie pré-rendue que reçoivent les robots vérifiés correspond à ce que Google appelle l'affichage dynamique. Il le décrit comme « une solution de contournement et non pas une solution à long terme » et conseille plutôt l'affichage côté serveur, l'affichage statique ou l'hydratation. Ce n'est pas de la dissimulation (cloaking) tant que le contenu reste similaire. Lovable précise que le contenu chargé plus tard peut manquer dans la copie.

Pour voir ce que Google reçoit vraiment, ouvrez l'outil d'inspection d'URL de la Search Console, cliquez sur « Tester l'URL active », puis sur « Afficher la page testée » : vous obtenez la capture d'écran et le code HTML. Lovable renvoie lui-même vers cet outil.

Passer à TanStack Start : quand et comment

Si le trafic venant de Google, de Bing ou des recherches IA compte pour vous, nous conseillons la migration : ensuite, tout le monde reçoit la même page complète, et les pages inexistantes renvoient de vraies 404. Trois façons de la lancer, chacune avec une confirmation : taper / dans le chat et choisir Migrate to TanStack Start ; cliquer sur Migrate dans Project settings → General → Project actions ; ou le demander à Lovable, qui affiche une carte avec le bouton Start migration.

Selon la documentation de Lovable (libellés de l'interface en anglais) :

• La plupart des migrations coûtent 10 à 35 crédits, selon la taille du projet.
• Le site publié ne change pas avant la prochaine publication, et l'historique des versions permet de revenir en arrière.
• Titres, descriptions, balises de partage et scripts de mesure d'audience sont repris.
• Certaines bibliothèques ne fonctionnent que dans le navigateur et peuvent casser le rendu côté serveur : testez chaque page avant de publier.

La migration n'est pas obligatoire : les anciennes applis restent pré-rendues pour les robots vérifiés, et un projet hébergé chez Lovable n'a pas besoin, selon lui, d'un service de pré-rendu externe. Ce pré-rendu fait partie de l'hébergement : si vous hébergez ailleurs l'export d'une ancienne appli, vérifiez sur place avec « Tester l'URL active ».

Langue, titre et description : les réglages par défaut à corriger

L'attribut lang, en haut du HTML, indique la langue de la page, par exemple <html lang="fr">. Dans notre test, 6 des 18 sites en français déclaraient lang="en" (5 applis récentes et une ancienne), et JavaScript ne corrigeait la valeur sur aucun. Même constat ailleurs : 20 sites germanophones sur 43, et 8 sites hispanophones sur 19 dans notre relevé espagnol du 17 octobre.

Google n'en tient pas compte : il détermine la langue d'après le contenu visible et ignore l'attribut lang. La correction reste utile, car les lecteurs d'écran s'en servent pour choisir la prononciation. L'audit de Lovable signale un attribut manquant ; sa documentation ne dit pas s'il repère un en sur un texte français. Demandez donc à Lovable d'écrire lang="fr" et vérifiez dans le code source. fr suffit, y compris pour un site belge, suisse ou québécois ; les codes régionaux servent surtout dans les balises hreflang (voir notre guide sur le SEO international).

Lovable génère le titre et la description de chaque page pendant la construction. L'image de partage est choisie au moment de servir la page : celle que vous avez demandée, ou la dernière capture d'écran de l'appli. Les modifications passent par le chat, consomment des crédits et n'arrivent en ligne qu'à la publication suivante. Pour contrôler le résultat : menu ⋮ de la fenêtre de publication, puis Social & search appearance.

Dans notre échantillon, aucun titre n'était resté « Lovable App », contrairement à 4 anciennes applis du relevé allemand, mais 2 sites indiquaient encore Lovable comme auteur dans leurs métadonnées. Le badge « Edit with Lovable » restait visible sur 7 des 18 sites ; à partir de l'offre Pro, il se masque sous Project settings → General → Publishing → Hide Lovable badge. Pour la longueur idéale d'un titre, voir notre guide sur la balise title.

Site en plusieurs langues : 2 des 18 sites avaient des balises hreflang. Les règles de Google valent aussi pour Lovable : une adresse par langue, pas de redirection automatique selon la langue du navigateur, et chaque version cite elle-même et toutes les autres. Notre guide sur la balise hreflang montre comment faire, avec fr-BE, fr-CH ou fr-CA si vous visez ces pays séparément.

robots.txt et sitemap : ce que Lovable crée, ce qui manque

Depuis la refonte de sa page SEO en octobre 2026, Lovable écrit qu'il crée un robots.txt avec chaque nouveau projet, mais pas toujours un sitemap, et que les métadonnées de départ restent génériques. Dans notre test :

• robots.txt : 15 sites sur 18, dont les 6 anciennes applis ; 14 y indiquaient un sitemap avec une ligne Sitemap:.
• sitemap.xml : 16 sites sur 18.
• Sitemaps fautifs : un sitemap ne contenait que des chemins relatifs. Sur les deux sites redirigés vers leur propre domaine, le sitemap listait encore les adresses lovable.app, qui redirigent elles-mêmes.

Google demande des URL absolues et complètes dans un sitemap, et l'audit de Lovable signale lui aussi les URL relatives et les adresses sur un autre hôte. Dans la ligne Sitemap:, nommez le sitemap de votre domaine définitif.

Domaine personnalisé : la 302, la canonical et l'adresse lovable.app

Les domaines personnalisés demandent une offre payante. Vous choisissez un domaine principal, et les autres domaines connectés y redirigent avec une 302, une redirection temporaire. Lovable ne permet pas de 301 entre les domaines d'un projet, pour que vous puissiez changer de domaine principal plus tard. L'adresse lovable.app du projet ne peut pas être supprimée.

Google suit une 302, mais ne la prend pas comme un signal que la cible est l'adresse canonique : l'ancienne adresse peut rester dans les résultats. Les autres signaux comptent donc double. Or, sur les deux sites de notre test redirigés en 302 vers un domaine propre, le sitemap et la ligne Sitemap: désignaient encore l'adresse lovable.app, et sur l'un des deux la canonical aussi. Le relevé allemand montrait la même erreur sur 2 des 8 sites à domaine propre.

Deux autres sites répondaient normalement sur leur adresse lovable.app, sans redirection, avec une canonical vers un domaine propre mais un sitemap rempli d'adresses lovable.app : des signaux contradictoires. Selon Lovable, si aucun domaine principal n'est défini, tous les domaines connectés servent le projet de la même façon.

La bonne configuration :

• définissez votre domaine comme domaine principal dans Project → Settings → Domains ;
• donnez à chaque page une canonical absolue vers elle-même, sur ce domaine ;
• ne listez dans le sitemap que des adresses de ce domaine ;
• validez le domaine dans la Search Console et soumettez-y le sitemap ; après un changement de domaine, Lovable demande de refaire la validation.

Notre guide sur la balise canonical explique les règles de base, et celui sur la migration SEO les redirections 301, 302, 307 et 308.

Pages légales et cookies : deux points à vérifier

Ce n'est pas un conseil juridique : nous décrivons seulement ce que nous avons observé.

Pages légales. Sur une ancienne appli, chaque adresse renvoie une coquille vide, mentions légales et politique de confidentialité comprises ; le texte n'arrive qu'avec JavaScript ou dans la copie pré-rendue. Dans notre relevé allemand, aucune des 8 pages légales d'anciennes applis ouvertes n'avait son texte dans le HTML. Reliez ces pages depuis chaque page par de vrais liens et ne les bloquez pas dans le robots.txt.

Cookies. La mesure d'audience intégrée de Lovable (le script /~flock.js) tournait sur les 18 sites, et un cookie session-id était présent dès le premier chargement, sans aucun clic ; l'hébergement plaçait en plus un cookie __dpl. Nous avions vu session-id sur 41 des 43 sites germanophones. Lovable écrit que sa mesure compte le trafic, pas les personnes, et ne construit pas de profils ; les pages de sa documentation que nous avons lues ne parlent pas de cookies. Elle se désactive sous Project settings → General → Publishing → Visitor analytics. Par ailleurs, 13 des 18 sites chargeaient des polices depuis les serveurs de Google dès la première visite, et 3 seulement affichaient un bandeau cookies. La question du consentement est juridique : faites-la vérifier avant la mise en ligne.

L'audit SEO de Lovable et la Search Console

Depuis octobre 2026, les outils SEO sont sous More → Analytics, onglet SEO & AI. Run SEO scan lance l'audit, inclus dans toutes les offres ; seuls Try to fix et Try to fix all consomment des crédits. Selon la documentation consultée le 17 octobre 2026, l'audit contrôle le code (viewport, attribut lang, métadonnées, Open Graph, données structurées, titres, textes alternatifs), l'aperçu (page d'accueil, robots.txt, sitemap.xml) et, une fois le site publié, le noindex et la version Markdown destinée aux robots d'IA. Il ne juge ni la qualité du contenu, ni l'intention de recherche, ni la vitesse : pour celle-ci, Lovable renvoie vers PageSpeed Insights.

Certains points fonctionnaient déjà bien dans notre test : les 194 images des pages d'accueil avaient toutes un attribut alt, chaque page d'accueil avait exactement un H1 après chargement, et 13 sites sur 18 avaient des données structurées.

Search Console : Lovable valide votre site avec la balise HTML de Google et peut soumettre le sitemap depuis le chat. Publiez d'abord, car Google lit le sitemap sur le site en ligne. Les projets non publiés ou à accès restreint n'apparaissent jamais dans les résultats. Depuis le 14 octobre 2026, Lovable se connecte aussi à Bing Webmaster Tools, pour suivre clics et exploration et envoyer adresses et sitemaps à Bing.

Checklist avant de publier

1. Identifiez la pile : code source et adresse inventée.
2. Migrez une ancienne appli vers TanStack Start, testez chaque page, puis publiez.
3. Langue : lang="fr" dans l'élément <html>, vérifié dans le code source.
4. Titre et description propres à chaque page, et une image de partage à vous.
5. robots.txt avec une ligne Sitemap: sur votre domaine définitif.
6. sitemap.xml avec des adresses absolues de ce domaine.
7. Canonical absolue, une seule par page, sur ce domaine.
8. Test 404 : une adresse inventée doit répondre 404.
9. Liens sous forme de vrais <a href>, menu et pages d'introduction compris.
10. Pages légales reliées depuis chaque page, avec leur texte dans le HTML.
11. Cookies et services tiers vérifiés au premier chargement, puis avec un juriste.
12. Search Console : validation, sitemap, puis « Tester l'URL active » sur les pages importantes.
13. En dernier, l'audit SEO de Lovable : corrigez, publiez, relancez le scan.