Un lundi matin, un fondateur de SaaS m’envoie une capture de sa Search Console. Une seule URL indexée. Un LCP à 5,4 s. Son site ? Une page unique, construite avec React, hébergée sur Vercel. Il pensait que « une seule page, c’est plus simple pour le SEO ». Il avait raison sur un point : c’est plus simple de tout casser d’un coup.
La promesse du site monopage est séduisante : un seul point d’entrée, pas de navigation complexe, un déploiement léger. Mais cette architecture concentre tous les signaux de classement sur une unique URL. Si vos Core Web Vitals sont mauvais sur cette page, ils le sont sur 100 % de votre site. Il n’y a pas de moyenne qui sauve la mise, pas de page secondaire qui rattrape un LCP désastreux. Chaque milliseconde de TTFB, chaque frame bloquée, chaque octet superflu se retrouve sous le regard unique de Googlebot.
La fausse promesse du site monopage
On imagine souvent qu’une architecture d’une seule page élimine les problèmes de crawl. En réalité, elle les condense. Là où un site multi-pages peut amortir une erreur de configuration sur une URL secondaire, le site monopage met toute son autorité dans un seul fichier. Si le rendu est bloqué, Google ne voit rien. Si le contenu principal arrive après trois secondes de JavaScript, le LCP dépasse les seuils et la page entre dans une zone grise où le classement devient instable.
Le pire, c’est qu’on confond « simple » avec « rapide ». Une page statique de 100 Ko qui affiche du texte et une image est effectivement simple. Une page unique qui charge un bundle React de 380 Ko, qui attend une API distante pour afficher son contenu et qui lazy-load l’image au-dessus de la ligne de flottaison est tout sauf simple. Elle est lourde, lente, et opaque pour les robots.
J’ai vu trop de projets partir sur un create-react-app sans réfléchir au mode de rendu. Le site finit par ressembler à une coquille vide que Googlebot doit remplir lui-même en exécutant du JavaScript. Résultat : un délai de crawling augmenté et une indexation partielle, même sur une page unique. Vous perdez le contrôle sur ce que Google voit, et vous ne le découvrez que dans les rapports « Détectée, actuellement non indexée ».
Pourquoi Googlebot voit du blanc avant de voir du contenu
Ouvre l’onglet Network des DevTools, coche « Disable cache », recharge la page. Ce que tu vois : un fichier HTML de 2 Ko qui appelle un bundle JavaScript, qui lance ensuite plusieurs appels API. Pendant ce temps, Googlebot observe une page blanche. Certes, Google exécute le JavaScript, mais avec un délai. Le temps que le bundle soit parsé, que les données arrivent, que le DOM soit construit, le LCP est déjà au-delà de 3 secondes.
Le problème n’est pas que Googlebot ne sache pas exécuter du JS. Il le fait, mais son budget de rendu n’est pas infini. Sur une page unique, ce budget est consommé en une seule fois. Si le blocage est trop long, la page peut être traitée comme un contenu faible, sans que le vrai contenu textuel soit correctement associé aux signaux de pertinence.
La solution évidente consiste à envoyer un HTML complet dès la première réponse. Pour un site monopage, cela signifie recourir à un rendu serveur, à une génération statique, ou à un pré-rendu. Par exemple, utiliser Next.js avec getStaticProps ou faire générer le fichier HTML via un outil de prerendering avant déploiement. L’objectif : que Googlebot reçoive le contenu lisible immédiatement, sans exécuter une ligne de JavaScript. L’interactivité vient dans un second temps, hydratée proprement après le chargement.
En poussant l’analyse, si votre store Zustand (ou Redux) charge tout l’état initial dans le bundle principal, vous alourdissez encore l’hydratation. Le state management React avec Zustand peut être un levier, mais mal configuré, il injecte du poids inutile dans le premier chargement. La technique consiste à ne transmettre que l’état critique pour le premier rendu, et à charger le reste de manière asynchrone.
Le LCP assassin : l’image héro qui tue tout
Sur une page unique, l’image principale fait office de vitrine. La plupart du temps, c’est un fichier PNG de 2 Mo, chargé sans fetchpriority, lazy-loadé par défaut alors qu’il est au-dessus de la ligne de flottaison. Le LCP grimpe immédiatement à 4,8 s, et le site devient invisible pour les requêtes concurrentielles.
Voici un extrait typique qu’on trouve dans le code :
<img src="/hero.png" loading="lazy" alt="produit" />Trois corrections suffisent à ramener le LCP sous 2,5 s.
D’abord, convertir l’image en WebP ou AVIF avec un outil comme sharp ou squoosh. On passe de 2 Mo à environ 300 Ko sans perte visible. Ensuite, supprimer loading="lazy" pour l’image visible sans scroll. Enfin, ajouter fetchpriority="high" et un link rel="preload" ciblé dans le <head> :
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">
<img src="/hero.webp" alt="produit" fetchpriority="high" width="1200" height="800">En local, sur un réseau 4G simulé, je suis passé de 4,2 s à 1,9 s de LCP sur un site monopage de démonstration. L’effet n’est pas marginal : c’est le passage d’une page « à améliorer » à une page « bonne » dans le rapport Core Web Vitals.
Autre piège classique : les polices web chargées en blocage. Une @font-face qui utilise font-display: swap évite l’affichage de texte invisible pendant le chargement. Sans cela, le texte reste masqué jusqu’à ce que la police arrive, retardant encore le FCP et le LCP sur un écran où le texte fait partie du contenu principal.
INP : le cauchemar caché derrière un bouton
Le site monopage n’est pas exempt de problèmes d’interaction. Un formulaire de contact, un menu hamburger, un carrousel : si le thread principal est encombré par un long script, l’Interaction to Next Paint explose. Un INP à 350 ms, ce n’est pas rare sur une page unique lourde, surtout si un script tiers (chat, analytics) bloque la main thread. Le remède : déférer les scripts non critiques avec type="module" ou async, et éviter les longs calculs synchrones pendant le chargement initial.
Ce que la Search Console raconte quand tu n’as qu’une URL
Avec une seule URL, le crawl budget n’est plus un problème de dispersion : il est réglé sur un seul fichier. Mais la fréquence de crawl dépend de la réactivité du serveur et de la qualité de la page. Si le TTFB est élevé, Googlebot espace ses visites. La page peut rester plusieurs jours sans être actualisée, même si le contenu a changé.
L’absence de liens internes prive la page d’ancres textuelles variées, qui aident Google à comprendre le contexte. Une page unique qui utilise des ancres (par exemple /#services) n’envoie pas d’URL distincte à l’index. Les fragments sont ignorés pour l’indexation. Par conséquent, Google ne peut pas associer des requêtes différentes à des sections précises de la page, ce qui limite le champ sémantique qu’elle peut couvrir.
L’internationalisation d’une page unique mérite une attention particulière. Sans URL alternatives, les balises hreflang doivent pointer vers la même page avec un paramètre ou un sous-domaine, ce qui est rarement une configuration propre. Mieux vaut prévoir une version par langue, même si chaque version reste une page unique dans sa langue.
Le rendu hybride pour sauver une page unique
La clé est de produire un HTML riche dès le serveur, sans renoncer à l’interactivité. Les frameworks comme Next.js permettent de générer la page à la compilation (getStaticProps) ou à la demande (getServerSideProps), et d’hydrater uniquement les îlots interactifs qui en ont besoin. Même Astro, avec son principe de zéro JavaScript par défaut, devient un choix pertinent pour une landing page.
Prenons un cas concret. Une landing de SaaS avec une section témoignages qui nécessite un carrousel. Plutôt que de charger React pour toute la page, on peut générer le markup statique au build, puis monter un composant React uniquement pour le carrousel, en utilisant astro add react. Le HTML livré contient déjà le contenu textuel ; le JavaScript arrive ensuite et s’attache à l’élément cible.
Quand on teste cette approche, on passe un temps certain à analyser les bundles. Que vous utilisiez Claude Code ou Cursor IDE, l’essentiel est d’obtenir un arbre de dépendances propre et un premier chargement inférieur à 100 Ko de JavaScript. La console Lighthouse devient votre tableau de bord, et chaque commit se vérifie avec un npm run build et une inspection du dossier out.
L’erreur serait de penser que le rendu hybride est réservé aux sites complexes. Une page unique peut bénéficier exactement des mêmes gains : un LCP qui tombe sous 2 secondes, une indexation instantanée, et un INP qui ne bouge pas. L’investissement en temps de configuration est minimal par rapport au risque d’être invisible sur les requêtes stratégiques.
Questions fréquentes
Faut-il un sitemap pour un site d’une seule page ?
Oui. Un sitemap contenant l’URL unique et la date de dernière modification aide Google à détecter plus vite les mises à jour. Sans cela, le moteur peut conserver une version en cache obsolète, surtout si la page est lourde.
Une page unique est-elle désavantagée pour le référencement local ?
Pas intrinsèquement, mais elle rend difficile l’intégration de données structurées distinctes pour chaque établissement si vous avez plusieurs adresses. Mieux vaut créer une page par lieu si le SEO local est prioritaire.
Peut-on utiliser des ancres pour simuler des pages internes ?
Non. Google ne traite pas les fragments comme des URL distinctes pour l’indexation. Utiliser des ancres peut améliorer la navigation utilisateur, mais cela ne remplace pas une architecture multi-pages quand elle est nécessaire.
