Pourquoi votre site Lovable n'apparaît pas sur Google

Votre site Lovable est en ligne, et les retours sont bons. Puis vous tapez le nom de votre entreprise dans Google, et vous ne trouvez rien, ou seulement la page d'accueil. C'est fréquent, et cela ne veut pas dire que vous avez mal fait. La cause tient en partie à la façon dont ce type d'app est construit, et en partie à quelques bases dont tout nouveau site a besoin. Ce guide explique les deux, vous montre comment voir ce que Google voit, et liste ce que vous pouvez faire.

Comment est construit un site Lovable, en termes simples

Lovable crée des applications web avec React, un outil très répandu pour construire des écrans en JavaScript. Par défaut, les apps construites ainsi sont des applications d'une seule page (on parle de SPA) : le serveur envoie un petit fichier HTML presque vide, et un gros fichier JavaScript. Le navigateur exécute le JavaScript, et c'est seulement à ce moment que les textes, les images et les boutons apparaissent. On appelle cela le rendu côté client : la page est construite dans le navigateur du visiteur, pas sur le serveur.

Pour une personne, cela fonctionne bien. Après le premier chargement, le passage d'une page à l'autre est rapide. Mais un robot d'indexation (le programme qu'un moteur de recherche envoie lire vos pages) reçoit d'abord ce petit fichier HTML. S'il est presque vide, le robot doit exécuter le JavaScript pour voir votre contenu, sinon il ne voit rien.

Ce n'est pas propre à Lovable : tout site construit comme une application d'une seule page, à la main ou avec un autre outil d'IA, part du même point.

Ce que voient les moteurs de recherche et les outils d'IA

Google sait exécuter le JavaScript, et il voit souvent le contenu des applications d'une seule page. Mais il le fait en général dans un second temps, si bien que les nouvelles pages peuvent mettre plus longtemps à apparaître. Une erreur dans le JavaScript, ou un contenu qui se charge tard, peut aussi faire que Google en voit moins qu'un visiteur.

D'autres lecteurs sont moins patients. Beaucoup de robots d'IA (des programmes qui collectent des pages pour les outils d'IA) n'exécutent pas le JavaScript : ils lisent seulement le premier fichier HTML. C'est aussi le cas des aperçus de liens dans la plupart des réseaux sociaux et des messageries. Quand ce fichier est presque vide, ils risquent d'obtenir :

• Peu ou pas de texte. À la place de vos mots, il n'y a qu'une boîte vide. Un outil d'IA ne peut ni citer ni recommander ce qu'il ne peut pas lire.
• Le même aperçu pour toutes les pages. Partagez votre page de tarifs dans une messagerie : elle affiche le titre et l'image de votre page d'accueil.
• Aucun chemin vers vos autres pages. Si les liens entre les pages n'existent qu'une fois le JavaScript exécuté, un robot qui ne l'exécute pas ne trouve aucun lien à suivre.

Les bases qui manquent souvent

Beaucoup de nouveaux sites, quel que soit l'outil utilisé, oublient aussi quelques points simples. Ce sont souvent eux la vraie raison de l'absence sur Google.

• Pas de Search Console. La Google Search Console est l'outil gratuit de Google pour les propriétaires de sites. Sans elle, vous ne savez pas quelles pages Google connaît, et vous ne pouvez pas lui demander d'en lire une nouvelle.
• Pas de sitemap. Un sitemap est un fichier qui liste toutes les pages que vous voulez faire trouver, en général à l'adresse votresite.com/sitemap.xml. Sans lui, Google doit découvrir vos pages tout seul.
• Un seul titre et une seule description pour toutes les pages. Si chaque page porte le titre de la page d'accueil, Google a du mal à les distinguer, et il risque de n'en montrer qu'une.
• Pas de vraie adresse pour chaque page. Chaque page a besoin de sa propre adresse, comme /tarifs ou /a-propos. Les adresses qui contiennent un signe # (comme /#/tarifs) sont en général traitées par Google comme une seule et même page.
• Un premier chargement lent. Le navigateur doit télécharger et exécuter le JavaScript avant de pouvoir afficher quoi que ce soit. Les grandes images et les fichiers lourds le ralentissent encore, surtout sur téléphone.
• Des pages qui n'existent pas s'affichent quand même. Dans beaucoup d'applications d'une seule page, une mauvaise adresse affiche malgré tout une page, souvent vide ou identique à l'accueil. Google peut alors trouver beaucoup d'adresses avec le même contenu.
• Votre propre domaine n'est pas relié. Ce que Google apprend sur votre site est lié à l'adresse qu'il voit : reliez donc tôt votre propre nom de domaine.

Comment voir ce que Google voit vraiment

Pas besoin de lire du code pour cela. Faites ces vérifications dans l'ordre :

• Cherchez votre site. Tapez site:votredomaine.com dans Google. Vous voyez les pages présentes dans son index (sa liste de pages connues). S'il n'y en a qu'une, ou aucune, vous avez une première réponse.
• Regardez le premier fichier HTML. Ouvrez votre site sur un ordinateur, faites un clic droit sur la page et choisissez d'afficher le code source. C'est ce que reçoit un robot avant toute exécution du JavaScript. Si vous y lisez vos propres textes, tant mieux. Si vous voyez surtout du code, c'est ce que lisent beaucoup d'outils d'IA.
• Utilisez l'outil d'inspection d'URL de la Search Console. Collez l'adresse d'une page dans la barre de recherche en haut, puis lancez un test en direct. Vous voyez si la page peut être indexée, et vous pouvez regarder la page telle que Google l'a construite, avec son HTML et une capture d'écran.
• Partagez un lien dans une messagerie. Comparez les aperçus de deux pages différentes. Si les deux affichent le même titre et la même image, les aperçus de liens ne lisent que votre premier fichier HTML.

Premières corrections : les bases, quel que soit l'outil

Ces étapes aident n'importe quel site. Vous pouvez demander la plupart d'entre elles avec des mots simples dans l'outil que vous avez utilisé, ou les confier à la personne qui travaille sur votre code.

• Donnez à chaque page sa propre adresse, et reliez vos pages entre elles par des liens normaux.
• Écrivez un titre et une description pour chaque page. Le titre dit en quelques mots de quoi parle la page. La description est le court texte que Google peut afficher dessous.
• Ajoutez un sitemap et envoyez-le dans la Search Console.
• Faites afficher une vraie page "introuvable" aux mauvaises adresses, avec le code qui indique aux moteurs de recherche que la page n'existe pas (un 404).
• Allégez le premier chargement, avec des images plus légères et moins d'extensions lourdes.
• Écrivez de vrais textes. Un moteur de recherche a besoin de mots pour comprendre ce que vous proposez et à qui. Une grande image et une seule phrase lui donnent très peu.

Après un changement, relancez l'inspection d'URL et demandez à Google d'indexer la page, puis laissez passer quelques semaines.

Si votre site vit de la recherche : servez du HTML prêt

Pour beaucoup de fondateurs, les bases suffisent. Le site sert de porte d'entrée : les gens arrivent par un lien, une publicité ou le bouche-à-oreille, et c'est l'app qui fait le travail. Mais si les gens doivent vous trouver sur Google, par exemple pour une boutique, un service local, un annuaire ou un blog, il est plus sûr que chaque page publique arrive en HTML déjà prêt, avec son texte, son titre et sa description à l'intérieur. Google, les robots d'IA et les aperçus de liens lisent alors tous la même page complète.

Il existe deux façons courantes de le faire :

• Le pré-rendu. Les pages sont transformées à l'avance en fichiers HTML terminés, au moment où le site est construit. Cela convient aux pages qui ne changent pas à chaque minute : page d'accueil, pages de services, articles.
• Le rendu côté serveur. Le serveur construit la page à chaque demande, puis l'envoie prête. Cela convient aux contenus qui changent souvent, comme des fiches produits ou des annonces. Des frameworks comme Next.js savent faire les deux.

Selon la façon dont votre app est construite, ce changement peut être petit ou important. Parfois, on peut ajouter une étape de pré-rendu au projet actuel. Parfois, le plus simple est de séparer le site : les pages publiques (accueil, services, tarifs, blog) passent sur une base qui sert du HTML prêt, et l'app derrière la connexion reste où elle est. Les pages derrière une connexion n'ont de toute façon pas besoin d'être sur Google. Quand cela a du sens, l'app entière peut être déplacée : notre guide pour héberger soi-même une application Lovable ou Bolt explique ce que cela implique.

Un visiteur voit votre site après l'exécution du JavaScript. Beaucoup de robots ne voient que ce qui vient avant.

Est-ce une raison de ne pas utiliser Lovable ?

Non. Lovable est très bon dans ce pour quoi il est fait : construire vite une app qui fonctionne, à partir d'une conversation, avec un design soigné. Pour un produit où les gens se connectent et accomplissent des tâches, une application d'une seule page est un choix normal et solide. Si vous hésitez encore entre plusieurs outils, notre comparatif de Lovable, Bolt et Cursor explique ce que chacun fait le mieux.

Les outils évoluent vite : consultez la documentation actuelle de Lovable pour savoir ce qu'il propose aujourd'hui pour la recherche. Les vérifications ci-dessus marchent quel que soit l'outil. Si vous préparez aussi l'arrivée de vrais utilisateurs, notre guide pour lancer une app Lovable auprès de vrais utilisateurs liste les autres points à vérifier.

En résumé

Un site Lovable est en général absent de Google pour deux types de raisons : des bases qui manquent, et des pages qui arrivent presque vides pour les lecteurs qui n'exécutent pas le JavaScript. Réglez d'abord les bases, puis vérifiez avec l'inspection d'URL ce que Google voit vraiment. Si vos clients vous trouvent par la recherche, servez vos pages publiques en HTML prêt. Si vous voulez qu'on regarde l'app dans son ensemble, découvrez comment nous finissons les apps Lovable pour de vrais utilisateurs.