Le client qui avait un site, mais pas d’existence sur Google

Un cabinet de conseil en stratégie financière basé à Lyon - disons cabinet A - décide en septembre 2025 de refondre son site via Lovable. Budget : quasi nul. Délai : deux semaines. Résultat visuel : propre, sobre, crédible. Trois mois plus tard, zéro trafic organique. Zéro. Pas “peu”, pas “faible” - littéralement aucune page indexée sur les 11 que compte le site.

Ce n’est pas un cas isolé. En auditant 12 sites générés par Lovable, Bolt ou v0 pour des clients PME entre octobre 2025 et avril 2026, j’ai retrouvé le même schéma structurel à des degrés variables. Voici ce que les données montrent - sans filtre.

Ce que Googlebot voit réellement

Le problème fondamental de Lovable, Bolt et v0 n’est pas esthétique. C’est architectural. Les trois outils génèrent par défaut des Single Page Applications (SPA) en rendu client-side (CSR). Concrètement : quand Googlebot arrive sur ta homepage, il reçoit un fichier HTML quasi vide. Le contenu réel - titres, textes, liens internes - est stocké dans des bundles JavaScript qui se chargent dans le navigateur après le crawl initial.

Merebase a documenté ce comportement en 2025 sur Lovable, Bolt et Base44 : les balises H1 et H2 sont masquées ou chargées trop tard, les JSON-LD structured data utilisent des types de schémas non supportés par Google, et les fichiers robots.txt contiennent des redondances qui perturbent l’indexation. John Mueller (Google Search Advocate) a confirmé en 2025 que le rendu JS différé reste un problème réel, particulièrement pour les nouveaux domaines avec un crawl budget limité.

Sur mes 12 sites audités, voici la distribution :

Ce dernier point est souvent sous-estimé. Quand un commercial partage le site sur LinkedIn depuis son téléphone, l’aperçu est vide - pas de titre, pas d’image, pas de description. C’est un signal de défiance immédiat pour le prospect.

Les Core Web Vitals : là où ça fait vraiment mal

Google confirme officiellement que les Core Web Vitals sont un facteur de classement. Les seuils “Good” : LCP < 2,5 s, INP < 200 ms, CLS < 0,1. Depuis mars 2024, FID a été remplacé par INP (Interaction to Next Paint), une métrique qui pénalise davantage les SPAs à hydration lente - précisément le profil des sites générés par ces outils.

Sur les 12 sites audités (données de terrain CrUX quand disponibles, données lab PageSpeed sinon) :

LCP (Largest Contentful Paint)

Le LCP dégradé sur les SPAs React s’explique mécaniquement : le navigateur doit télécharger, parser et exécuter le bundle JS avant d’afficher l’élément le plus grand de la page - souvent le hero image ou le titre H1. Sans SSR, ce chemin critique est incompressible.

INP et CLS

Le seul site du panel à passer tous les seuils “Good” était un site v0 dont le développeur avait configuré manuellement le pipeline SSG via GitHub + Vercel - exactement la configuration décrite par Till Freitag comme le seul moyen d’obtenir des performances correctes avec ces outils.

Les positions SERP : ce que ça donne 3-6 mois après lancement

Sur les 8 sites du panel pour lesquels j’avais accès à Google Search Console sur une période de 3 à 6 mois post-lancement :

Le cabinet A de Lyon ? Après intervention (migration vers Astro + déploiement SSG, voir plus bas), il est passé de 0 à 14 pages indexées en 6 semaines. Mais ça n’avait plus grand-chose à voir avec Lovable à ce stade.

Ce que font Framer et Wix par comparaison

Il faut être précis : le problème n’est pas “l’IA génère de mauvais sites”. Le problème est l’architecture CSR par défaut. La comparaison directe entre builders montre que Framer et Wix gèrent nativement le SSR/SSG, contrairement à Lovable qui exporte du code React CSR brut. Durable génère les balises meta automatiquement - mais avec un contenu générique qui ne différencie pas.

Framer, en particulier, produit des scores Core Web Vitals nettement supérieurs sur les mêmes types de contenus, précisément parce que son infrastructure de rendu est maîtrisée côté plateforme. La contrepartie : tu ne possèdes pas ton code, et les options d’export sont limitées.

C’est le trade-off fondamental des builders “hosted” vs. les outils comme Lovable qui exportent du code React : l’un te donne la performance out-of-the-box, l’autre te donne la propriété du code mais te laisse gérer les conséquences techniques.

Ce que Google dit de son côté

Aucune optimisation spécifique n’est requise pour les AI Overviews - les fondamentaux SEO classiques restent prioritaires. Crawlabilité (robots.txt propre, CDN bien configuré), liens internes découvrables, structured data valides. Google ne fait aucune exception pour les sites générés par IA. Les mêmes critères s’appliquent.

Un point souvent ignoré : les sites déployés sur Vercel ou Netlify avec une mauvaise configuration CDN peuvent bloquer Googlebot sans que le propriétaire du site s’en rende compte. Search Engine Land signale qu’depuis novembre 2024, les données HTTP Archive montrent une baisse mesurable du taux de canonical links valides, corrélée à la prolifération des SPAs générées par IA.

Ce qu’il faut retenir concrètement

Si tu envisages de lancer un site avec Lovable, Bolt ou v0, voici les 5 vérifications non négociables avant de te déclarer “prêt à indexer” :

  1. SSG activé : ton site doit générer du HTML statique, pas une SPA React CSR. La configuration Lovable + GitHub + Vercel avec SSG est documentée - elle demande 2-4 heures de travail technique.
  2. Balises <title> et <meta description> dans le HTML statique : vérifie avec un curl ou via l’outil d’inspection de Search Console (option “HTML rendu vs. HTML brut”).
  3. Sitemap XML soumis : générer et soumettre un sitemap n’est pas automatique sur ces outils. C’est une action manuelle.
  4. Structured data validés : utilise le Rich Results Test de Google pour vérifier que tes JSON-LD utilisent des types reconnus.
  5. Open Graph fonctionnels : teste sur opengraph.xyz avant tout lancement.

Sur les 12 sites audités, aucun n’avait coché ces 5 points au moment du lancement. C’est cohérent avec ce que décrit l’article sur le vrai coût d’un DIY IA : le temps de correction post-lancement est systématiquement sous-estimé. Et si tu veux comprendre quelle stack évite structurellement ces problèmes, la comparaison WordPress vs. Astro en 2026 est un bon point de départ.

Un site IA bien configuré peut avoir d’excellents Core Web Vitals et une indexation correcte - le site v0 + SSG du panel en est la preuve. Mais “bien configuré” demande précisément le type d’expertise que ces outils prétendent rendre inutile.

Un projet web en tête ?

Yoann ou Dan vous répondent directement. Premier échange sans engagement.

Prendre rendez-vous