Un site Lovable se référence-t-il ? Le problème et la solution

Une application monopage n'a qu'un seul document HTML. Le serveur renvoie ce même fichier pour la page d'accueil, pour la page de contact, pour un article de blog ou pour une fiche produit. Ce fichier ne contient qu'une coquille : quelques balises meta, un conteneur vide et une référence vers un paquet JavaScript. Le routeur, une fois le JavaScript exécuté dans le navigateur, lit l'URL et remplace le contenu du conteneur par la bonne page.

Pour Google, cela se traduit par un rendu différé. L'exploration se fait en deux temps : le robot télécharge d'abord le HTML, constate qu'il est vide, puis met l'URL dans une file d'attente de rendu pour qu'un navigateur sans interface exécute le JavaScript plus tard. Ce second passage n'est ni immédiat ni garanti au même rythme que le premier, et il coûte cher côté moteur.

S'y ajoute un effet plus insidieux : le budget d'exploration. Un robot dispose d'un volume de requêtes limité par site, calibré sur l'autorité du domaine. Quand chaque URL renvoie un document identique, le moteur n'a aucun signal de nouveauté et rien qui justifie d'aller plus loin. Sur un domaine récent, le résultat typique n'est pas un rejet : c'est une absence pure et simple d'exploration.

C'est le point que presque personne n'explique, et c'est pourtant le plus tranchant. Les robots des moteurs de réponse — GPTBot, ClaudeBot, PerplexityBot, CCBot et la plupart des collecteurs qui alimentent les modèles de langage — sont des clients HTTP simples. Ils demandent une URL, lisent le HTML renvoyé et s'arrêtent là. Ils n'embarquent pas de moteur de rendu et n'exécutent pas de JavaScript.

Sur une application monopage sans pré-rendu, ces robots reçoivent donc une coquille vide. Pas un contenu appauvri : rien. Aucune phrase de la page, aucun titre spécifique, aucun tableau, aucune donnée. Une entreprise peut avoir publié cinquante pages de contenu solide et rester totalement absente des réponses générées par ces moteurs, parce que ce contenu n'a jamais existé du point de vue du collecteur.

La différence de traitement avec Google est nette. Google finit souvent par rendre la page, avec du retard. Les moteurs IA, eux, n'ont pas de seconde chance : ce qu'ils n'ont pas reçu dans la première réponse HTTP n'entre jamais dans leur corpus. À l'heure où une part croissante des recherches passe par des interfaces conversationnelles, ce silence coûte davantage qu'un mauvais classement.

Le test tient en deux commandes. Il consiste à demander deux URLs différentes du site en se présentant comme un robot, puis à comparer ce qui revient. Ouvrez un terminal et lancez :

curl -s -A "GPTBot/1.0" https://votre-domaine.fr/ | wc -c

curl -s -A "GPTBot/1.0" https://votre-domaine.fr/une-autre-page | wc -c

Comparez d'abord les deux tailles en octets. Si elles sont rigoureusement identiques, les deux URLs servent le même fichier : le site n'est pas pré-rendu. Comparez ensuite le titre réellement envoyé, avec grep -o "<title>[^<]*" sur chacune des deux réponses. Si les deux pages annoncent le titre de l'accueil, le diagnostic est confirmé.

Un troisième contrôle rend la démonstration définitive : demandez une URL qui n'existe pas, par exemple /page-inventee-123. Si elle répond elle aussi avec le même document et un code 200, le site sert une infinité de copies indexables de sa page d'accueil. À l'inverse, sur un site pré-rendu, chaque URL renvoie un poids différent, un titre différent, et l'URL inconnue est traitée comme une erreur.

Parce que le résultat est un dossier de fichiers HTML que le client possède. À la fin de la compilation, chaque URL publique existe sous forme de fichier autonome, avec son titre, sa description, sa balise canonical, ses hreflang, son JSON-LD et son texte complet. Ces fichiers se servent depuis n'importe quel hébergement statique, y compris ailleurs que chez nous.

Il n'y a donc pas d'abonnement à renouveler, pas d'intermédiaire à interroger quand un robot se plaint, et pas de serveur applicatif à surveiller la nuit. Si l'agence disparaît, le site continue d'être lisible par les moteurs exactement comme le jour de la livraison. C'est la même logique que celle décrite dans notre méthodologie de livraison : ce qui est livré doit rester exploitable sans nous.

Le pré-rendu au build a une contrepartie honnête : il faut recompiler pour publier une modification de contenu. Sur un site vitrine, un catalogue de ressources ou un blog éditorial, cette contrainte est négligeable. Sur une application dont le contenu public change plusieurs fois par heure, le rendu serveur redevient le bon choix, et nous le disons avant le devis plutôt qu'après.

Le rapport d'indexation affichait 8 pages indexées et 78 pages non indexées. Sur ces 78, 76 étaient classées en « Détectée, actuellement non indexée », avec la mention « Dernière exploration : Sans objet ». Autrement dit, Google connaissait ces URLs par le sitemap, mais ne les avait jamais explorées une seule fois.

Le chiffre décisif est l'autre : zéro page en « Explorée, actuellement non indexée ». Cette catégorie regroupe les pages que Google a téléchargées puis écartées, généralement pour insuffisance de qualité ou duplication. Elle était vide. Google n'avait donc porté aucun jugement sur le contenu : il n'avait tout simplement jamais regardé.

C'est une distinction opérationnelle importante. Un site rejeté après exploration a un problème de contenu, et réécrire les pages est la bonne réponse. Un site jamais exploré a un problème d'accès, et aucune quantité de contenu supplémentaire ne le résout tant que chaque URL sert le même fichier. Nous étions dans le second cas, et c'est la correction technique qui devait venir en premier.

La tentation est forte : puisque le robot ne voit pas le contenu, on ajoute dans le document un bloc de texte destiné uniquement à lui, masqué à l'utilisateur par du CSS ou placé hors écran. Cette pratique porte un nom dans les règles anti-spam de Google : le texte caché. Elle est explicitement interdite, au même titre que la présentation d'un contenu différent aux robots et aux visiteurs.

La sanction possible n'est pas un simple réajustement algorithmique mais une action manuelle, c'est-à-dire une décision humaine visant le site, avec une procédure de réexamen à la clé. Le rapport coût-bénéfice est catastrophique : on met en jeu la visibilité entière du domaine pour un contenu que le pré-rendu aurait rendu visible légitimement.

Nous ne décrivons volontairement aucune méthode pour le faire. La règle utile à retenir est simple : le contenu envoyé au robot doit être exactement celui que voit l'utilisateur. Le pré-rendu respecte cette règle par construction, puisqu'il produit le HTML de la page réelle.

Un hébergement statique renvoie généralement le fichier index.html pour toute URL qu'il ne connaît pas. Sur une application monopage, cela signifie qu'une adresse inventée répond en HTTP 200 avec le contenu de l'accueil, sa balise canonical et sa directive d'indexation. Chaque faute de frappe dans un lien externe, chaque URL périmée, chaque adresse générée au hasard devient ainsi une copie indexable du site.

La correction se fait côté routeur, au moment où l'application constate qu'aucune route ne correspond. Trois gestes suffisent : remplacer la directive robots par noindex, nofollow ; supprimer la balise canonical héritée du document statique, pour ne pas attribuer cette URL à la page d'accueil ; et remplacer le titre par un vrai titre d'erreur dans la langue de l'URL demandée.

Un détail compte : l'URL demandée doit rester affichée. Rediriger silencieusement vers la page d'accueil reproduit le problème sous une autre forme, puisque le moteur enregistre alors une redirection depuis une adresse qui n'aurait jamais dû exister.

Un sitemap obsolète, un ancien fichier robots.txt ou une page orpheline supprimés du dépôt continuent souvent d'être servis en production. La raison est mécanique : un déploiement statique publie les fichiers présents dans le dossier de sortie, mais n'efface pas nécessairement ceux qui y figuraient auparavant, et le cache du réseau de diffusion conserve la version précédente pendant sa durée de validité.

Concrètement, on peut passer une journée à corriger un sitemap dans le code sans qu'aucune des corrections n'apparaisse en ligne, parce que l'ancien fichier est toujours servi. Le réflexe correct est de vérifier chaque correction directement sur l'URL publique, avec curl, plutôt que dans le dépôt.

Quand un fichier doit disparaître, il vaut mieux l'écraser par un contenu vide et valide, ou le remplacer par une redirection, que le supprimer et espérer. Et systématiquement contrôler ensuite ce que renvoie l'adresse en production.