SEO des sites statiques : Jamstack, SSG et comment être trouvé

TL;DR : Le SEO des sites statiques commence par un avantage concret : un contenu important peut être livré sous forme de HTML pré-généré, au lieu d’attendre que du JavaScript s’exécute. En revanche, Astro, Hugo, 11ty, Gatsby, Jekyll et les exportations statiques de Next.js ne résolvent pas automatiquement les canonicals, les métadonnées, les données structurées, les redirections, les liens internes, ni les widgets rendus côté client qui masquent du contenu aux crawlers. Il faut juger le HTML déployé, pas l’étiquette du framework.

Ce que les sites statiques gagnent vraiment « gratuitement »

Un générateur de site statique comme Astro, Hugo, 11ty, Jekyll, Gatsby ou Next.js en mode export statique exécute des modèles et le contenu pendant le build. Il produit des fichiers HTML, ainsi que le CSS, le JavaScript et les assets nécessaires à chaque page. La couche d’hébergement peut servir ces fichiers sans requêter une base de données ni rendre la page à chaque requête.

C’est important parce que Google traite les pages via le crawl, le rendu, l’indexation et le service. Notre guide sur comment fonctionne l’indexation Google décrit ces étapes en détail. L’avantage du site statique est plus simple : si le texte et les liens sont déjà présents dans le HTML téléchargé, Google n’a pas besoin de JavaScript pour les découvrir.

« Gardez à l’esprit que le rendu côté serveur ou la pré-rénédérisation restent une très bonne idée : votre site sera plus rapide pour les utilisateurs et les crawleurs, et tous les bots ne peuvent pas exécuter JavaScript. »

Cette formulation est celle de Google Search Central dans Understand the JavaScript SEO basics. C’est aussi l’argument le plus solide en faveur du SEO des sites statiques : la pré-génération supprime une dépendance. Elle ne fabrique pas la pertinence, l’autorité, l’écriture utile ou une architecture cohérente (et je confierais volontiers ces quatre points à une commande de build).

Les fichiers statiques se mettent aussi facilement en cache aux bords CDN. En supprimant le rendu à la demande, vous éliminez une source de latence et de risques d’échec. La documentation Web Vitals de Google définit « une bonne performance » comme un LCP inférieur ou égal à 2,5 secondes, un INP de 200 millisecondes ou moins, et un CLS de 0,1 ou moins. Ces seuils sont évalués au 75e percentile, séparément pour le trafic mobile et le trafic desktop.

Ne traduisez pas tout ça par « les sites statiques passent automatiquement les Core Web Vitals ». Une image héro de 3 Mo, des polices bloquantes pour le rendu, des scripts tiers et un gros bundle d’hydratation peuvent tout de même ruiner le LCP ou l’INP. L’architecture statique vous donne de la marge pour performer. Elle n’impose pas un budget d’assets.

Et la vitesse ne fait pas classer une page non pertinente. C’est une question d’infrastructure, pas un substitut à la demande, au contenu ou aux liens.

Le test « view-source » repère la plus grosse défaillance Jamstack SEO

Un site statique peut tout de même être une application JavaScript qui porte une « coque statique ».

Les îlots Astro, les widgets React, les grilles de produits chargées côté client, les composants d’avis, les commentaires et les listes « charger plus » peuvent ne se remplir qu’après l’hydratation. Si le contenu pertinent pour le SEO arrive via une requête d’API côté navigateur, il est absent de la réponse initiale. Vous retombez alors dans le JavaScript SEO, même si le déploiement contient bien des fichiers HTML.

Google décrit directement le problème « app-shell » : « le HTML initial ne contient pas le contenu réel », donc Google doit exécuter du JavaScript avant de voir le contenu généré. Sa documentation indique aussi qu’une page peut rester dans la file de rendu « quelques secondes, mais cela peut être plus long ». Certains bots ne peuvent tout simplement pas exécuter JavaScript.

Ouvrez l’URL déployée et utilisez view-source. Ne vous fiez pas au panneau Elements dans DevTools : il montre le DOM après que les scripts l’ont modifié. Recherchez dans la source le titre principal, plusieurs phrases distinctives, les liens importants, les détails produit et les attributs alt des images.

S’ils manquent, déplacez les données dans le build. Récupérez-les pendant la génération et rendez l’article, la liste, les avis ou les informations produit dans le HTML émis. Gardez le JavaScript côté navigateur pour l’interactivité, pas pour fournir le contenu principal. Notre guide framework explique comment garder le contenu Next.js, React et Nuxt du bon côté de cette frontière.

J’ai échoué à ce test sur des pages qui semblaient parfaitement complètes dans Chrome. Le navigateur avait récupéré les données assez vite pour que rien ne paraisse anormal lors de la vérification, tandis que la view-source ne contenait guère plus qu’un élément racine et des références de scripts. Une coche verte de déploiement n’est pas un test d’indexation (et, malheureusement, « ça marche sur ma machine » non plus).

Cette distinction compte le plus pour moi lors des audits SEOJuice sur les sites statiques. Le choix du framework attire beaucoup l’attention, mais le crawler reçoit une réponse HTTP, pas vos intentions d’architecture.

Le travail SEO que votre générateur vous laisse

Générer et inspecter la sitemap XML

Le comportement des sitemaps varie selon le générateur. Hugo génère sitemap.xml par défaut ; sa documentation inclut même une section sur la désactivation de la génération de sitemap, ce qui prouve que la fonctionnalité est activée tant que vous ne la coupez pas.

Une sitemap minimale valide comporte un bloc url par page :

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2026-07-19</lastmod>
  </url>
</urlset>

Astro adopte une approche différente. Sa documentation sur la sitemap indique que @astrojs/sitemap a besoin de l’URL du site déployé avant de pouvoir générer une sitemap. Une fois configurée, l’intégration ajoute un index de sitemap et des fichiers sitemap au répertoire de sortie.

Pour les autres générateurs, consultez la documentation actuelle et l’écosystème de plugins plutôt que de supposer qu’une sitemap existe. Le test n’est pas de savoir si une dépendance apparaît dans votre fichier package. Le test consiste à vérifier que la sitemap déployée se charge, renvoie le bon type de contenu, et contient bien les URLs de production que vous voulez réellement indexer.

Puis inspectez un exemple. Repérez les hôtes de staging, les variantes de slash non canoniques, les URLs avec paramètres, les sections manquantes et les pages qui devraient être exclues. Une sitemap peut être syntaxiquement correcte tout en décrivant le mauvais site.

Astro mérite une attention particulière, car l’URL du site configurée sert aussi à construire des URLs absolues. Notre checklist SEO pour Astro traite les sitemaps, les canonicals et les problèmes spécifiques aux « îlots » plus en profondeur.

Construire les canonicals à partir de l’URL de production

En général, les générateurs de sites statiques ne décident pas vos URLs canoniques à votre place. Votre mise en page doit créer un canonical pour chaque page indexable en utilisant l’URL de base de production et le chemin normalisé de la page. Un domaine de staging ou une valeur localhost « injectée » dans la production pointe les moteurs de recherche vers la mauvaise version.

Les canonicals relatifs posent aussi une ambiguïté évitable. Construisez des URLs absolues, puis définissez une seule politique pour les slash finaux, les fichiers index et la casse des URL. Votre canonical, vos liens internes, les entrées de sitemap et vos règles de redirection doivent être cohérents entre eux.

Nous avons déplacé SEOJuice de seojuice.io vers seojuice.com en janvier 2026. La navigation visible était la partie facile. La vraie surface de migration incluait les balises canonical, les entrées de sitemap, les liens internes, les URLs des données structurées, les références d’assets et les redirections au niveau du host. Un ancien hostname intégré dans un modèle partagé peut être recopié dans chaque page générée avant que quelqu’un s’en rende compte (une manière particulièrement efficace de scaler une erreur).

Je ne fais pas confiance à un composant canonical universel recopié entre frameworks. Les paths de base, le comportement des slash, les helpers d’URL et les variables d’environnement diffèrent. Inspectez le HTML final à la dernière URL. Les templates ne sont que des détails d’implémentation ; c’est le résultat déployé que les crawlers reçoivent.

Arrêter de diffuser un seul titre sur tout le site

Les titres de page, les meta descriptions, les champs Open Graph et les balises sociales proviennent souvent des « front matter » passées à une mise en page partagée. Si le front matter est absent ou que le fallback est trop large, des centaines de pages peuvent hériter d’un seul titre générique.

Rendez les métadonnées essentielles explicites dans le modèle de contenu. Donnez à chaque page indexable un titre unique et descriptif, ainsi qu’une description pertinente. Définissez une logique de fallback pour les cas prévisibles, mais ne laissez pas une chaîne de marque à l’échelle du site devenir silencieusement le titre de toutes les pages.

Puis, crawlez le site construit pour repérer les doublons, les zones vides, les balises mal formées et les valeurs anormalement longues. La génération statique crée de la cohérence, y compris des défauts cohérents.

Ajoutez des données structurées à la page « réelle »

Google Search Central définit les données structurées comme « un format standardisé pour fournir des informations sur une page et classifier le contenu de la page ». Google recommande le JSON-LD et précise que le balisage doit être placé sur la page qu’il décrit.

L’objet doit correspondre au contenu visible et inclure toutes les propriétés requises pour être éligible aux mises en avant dans la recherche. L’éligibilité n’est pas une garantie de rich result. Le schéma clarifie le sens pour les machines ; il ne force pas Google à décorer un résultat.

Générez les données structurées à partir de la même source que la page visible, autant que possible. Dupliquer les noms de produits, les prix, les dates et les informations d’auteur dans des champs manuels séparés crée une dérive. Validez des types de pages représentatifs après le déploiement, pas seulement le modèle JSON-LD pris isolément.

Écrire les bases, sans glamour

Vous avez toujours besoin d’un fichier robots.txt correct, de textes alternatifs utiles pour les images, de niveaux de titres cohérents, d’ancrages descriptifs et de liens internes. La génération statique n’empêche pas les pages orphelines. Une URL peut exister dans le répertoire de sortie et dans la sitemap tout en restant déconnectée des parcours que suivent les utilisateurs et les crawlers.

D’après ce que nous observons sur les sites audités avec SEOJuice, c’est souvent à ce moment-là que la « architecture clean » s’arrête d’aider. Le site se construit vite et se sert vite, mais les pages liées ne sont pas connectées, la couverture des métadonnées est irrégulière, et du contenu ancien se retrouve plusieurs niveaux plus loin que n’importe quelle page actuelle. Aucun de ces défauts ne nécessite une migration de framework. Il faut de la maintenance.

Du travail fastidieux, pour l’essentiel. Mais très impactant.

Les redirections appartiennent à l’hôte ou au CDN

Un déploiement 100 % statique n’exécute aucun routeur d’application côté serveur pour chaque requête. Les redirections doivent donc être gérées au niveau de l’hébergement ou du CDN, pas dans un composant côté client.

La documentation de Netlify indique que son moteur de redirections traite la première règle correspondante, de haut en bas, et utilise 301 par défaut. L’ordre des règles compte. Un wildcard large au-dessus d’une règle de migration spécifique peut intercepter la requête en premier.

Vercel expose les redirections, les URLs propres et le comportement des slash via la configuration du projet. Cloudflare Pages prend aussi en charge un fichier _redirects, mais son défaut est 302 plutôt que 301 chez Netlify. Spécifiez le statut explicitement quand il s’agit d’un déplacement permanent (j’ai dû vérifier deux fois cette différence ; des noms de fichiers identiques encouragent la mauvaise hypothèse).

Conservez la carte des redirections à côté de la source et testez les anciennes URLs après le déploiement. Couvrez les pages renommées, les articles fusionnés, les variantes de domaine, les changements de protocole et la politique de slash final que vous avez choisie. Testez le statut renvoyé et la destination, y compris les chaînes de redirections.

Un routeur côté client qui voit un ancien chemin et modifie l’URL du navigateur n’est pas équivalent. La réponse d’origine reste en 200 ou 404, et les clients qui n’exécutent pas JavaScript ne reçoivent jamais la redirection prévue.

Les fonctionnalités dynamiques sont OK en dehors du chemin de contenu principal

Les formulaires peuvent utiliser une fonctionnalité de l’hôte, un endpoint tiers ou une fonction serverless. L’interaction liée à l’envoi n’est pas du contenu indexable, mais la page doit contenir un texte pré-rendu expliquant ce que fait le formulaire.

La recherche côté client peut s’appuyer sur un index local ou une API hébergée. Les résultats de recherche ne devraient généralement pas devenir le seul moyen de découvrir votre contenu. Chaque résultat important doit avoir sa propre URL statique et au moins un lien interne crawlable en dehors de l’interface de recherche.

Les commentaires et les widgets d’avis demandent plus d’attention. S’ils s’hydratent après le chargement, leur contenu peut ne pas exister dans le HTML initial. Quand les avis soutiennent réellement une page produit, rendez le contenu pertinent pendant le build et générez des données structurées exactes à partir de la même source.

La personnalisation, les recommandations et les expériences peuvent rester côté client si la page principale n’en dépend pas. Ma règle est directe : décidez du contenu indexable pendant le build ; ajoutez une interaction optionnelle dans le navigateur.

Un process de release qui détecte les défauts SEO statiques

1. Build avec une configuration de production. Vérifiez que le vrai hostname et le base path sont disponibles pour les templates.
2. Inspectez le HTML brut. Contrôlez les titres, descriptions, canonicals, titres (headings), liens, alt text, JSON-LD et le contenu principal.
3. Ouvrez la sitemap et robots.txt. Vérifiez qu’ils sont déployés et cohérents en interne.
4. Désactivez JavaScript. Confirmez que l’information principale et la navigation restent disponibles.
5. Testez les anciennes URLs. Vérifiez que l’hôte renvoie le statut attendu et la destination finale.
6. Mesurez des pages représentatives. Comparez-les aux seuils LCP, INP et CLS au lieu de supposer que « statique » signifie « rapide ».
7. Crawl après le déploiement. Recherchez les métadonnées dupliquées, les canonicals manquants, les pages orphelines, les liens cassés et les codes de statut inattendus.

Lancez ce process pour les types de pages, pas seulement pour la page d’accueil. Les articles de blog, les pages produit, la pagination, les archives par tags, les pages de documentation et les pages d’atterrissage utilisent souvent des mises en page différentes. Une homepage saine ne vous apprend presque rien sur un millier d’URLs générées.

Pour les migrations, conservez la liste des anciennes URLs et testez-la automatiquement après la release. Pendant la migration de domaine SEOJuice, nous avons appris que les contrôles de migration doivent couvrir ce que les utilisateurs ne peuvent pas voir autant que ce qu’ils voient. Les canonicals et les identifiants des données structurées sont faciles à rater lors d’une revue visuelle.

Où SEOJuice s’insère, et où il ne s’insère pas

SEOJuice applique en continu des liens internes, des titres et descriptions meta, du balisage schema, et le texte alternatif des images à un site en production. Il peut être installé via un extrait JavaScript ou un plugin WordPress/CMS, et un plan gratuit est disponible sans carte bancaire.

Il existe une frontière importante pour les sites statiques. Les métadonnées injectées par extrait, le schema et les liens dépendent du rendu côté client : ils ne sont donc pas présents dans l’étape de crawl HTML d’origine et peuvent être indisponibles pour certains bots qui n’exécutent pas JavaScript. Gardez dans le HTML généré le contenu principal, les canonicals, les titres et descriptions essentiels, ainsi que le JSON-LD critique, chaque fois que vous contrôlez le build. Utilisez l’extrait pour un travail progressif « on-page » qui se dégrade correctement, pas comme excuse pour livrer une coquille vide.

SEOJuice ne remplace pas non plus votre sitemap, vos redirections CDN, l’architecture de build ou votre stratégie de contenu. Si vous voulez identifier les éléments manquants dans la couche on-page, commencez par le audit SEO gratuit. Corrigez d’abord les problèmes structurels dans le build, puis automatisez la couche répétitive lorsque ce compromis a du sens.

Questions fréquentes

Les sites statiques sont-ils bons pour le SEO ?

Oui, comme architecture de départ. Le HTML pré-rendu supprime la dépendance au rendu JavaScript pour le contenu présent dans la source, tandis que la distribution via CDN rend plus simple l’obtention de bonnes performances. Mais vous avez toujours besoin de contenu pertinent, de métadonnées, de canonicals, d’une sitemap, de données structurées, de liens internes et de redirections.

Les sites statiques ont-ils besoin d’une sitemap XML ?

Oui. Hugo génère sitemap.xml par défaut, alors qu’Astro nécessite son intégration sitemap et une URL de site configurée. Les autres générateurs peuvent nécessiter une configuration spécifique au projet ou un plugin. Inspectez la sitemap déployée plutôt que de supposer que le build l’a créée correctement.

Le Jamstack est-il bon pour le SEO ?

Le Jamstack peut offrir les mêmes avantages de balisage pré-rendu et de livraison via CDN que d’autres architectures statiques. Le risque apparaît quand du contenu important est chargé via des APIs côté navigateur. S’il manque dans le HTML généré, Google doit exécuter du JavaScript pour le voir, et d’autres bots peuvent le rater complètement.

Comment mettre en place des redirections sur un site statique ?

Configurez-les au niveau de l’hôte ou du CDN. Netlify prend en charge _redirects et netlify.toml, Vercel utilise la configuration du projet, et Cloudflare Pages supporte un fichier _redirects. Indiquez délibérément des codes de statut permanents, gardez les règles versionnées et testez la réponse HTTP après le déploiement.

Google indexe-t-il le JavaScript sur les sites statiques ?

Google peut rendre du JavaScript, mais ce rendu intervient après le crawl et peut être différé. Google note aussi que tous les bots ne peuvent pas exécuter JavaScript. Si le contenu principal n’apparaît qu’après l’hydratation, rendez-le dans le HTML généré plutôt que de dépendre de l’exécution dans le navigateur.

Les sites statiques ont-ils toujours besoin de balises meta et de balises canonical ?

Oui. Les générateurs de sites statiques ne créent pas de façon fiable des titres, descriptions, balises Open Graph ou URLs canoniques uniques pour chaque projet. Générez-les à partir des données de page, utilisez l’URL de base de production pour des canonicals absolus, puis inspectez le HTML final pour repérer les doublons ou des valeurs de staging.

Retournez le contenu traduit dans des balises