Guide Astro SEO

TL;DR — Astro est un excellent choix pour le SEO. Par défaut, il construit vos pages en fichiers HTML simples à l’avance, si bien que lorsque Google (ou n’importe quel robot) arrive, votre contenu est déjà là : aucun JavaScript à attendre. C’est aussi très rapide. Le point à retenir : Astro vous donne un HTML propre, mais n’ajoute pas automatiquement le titre de vos pages, le sitemap ni les balises canoniques. Vous les configurez vous-même (c’est simple).

Ce que signifie « Astro SEO »

Astro est un cadre web pour créer des sites. Son idée centrale est « moins de JavaScript ». Alors que des cadres comme React ou Next.js construisent souvent la page dans le navigateur à l’aide de JavaScript, Astro construit vos pages en fichiers HTML simples au moment du build et n’envoie presque pas de JavaScript, sauf lorsqu’une partie de la page en a réellement besoin. Evidence for this claim Astro prerenders pages as static HTML by default and only sends client JavaScript for explicitly hydrated components. Scope: Astro default static output and islands architecture. Confidence: high · Verified: 2026-07-14 Astro: Why Astro

Cette différence suffit à expliquer pourquoi Astro est si favorable aux moteurs de recherche. Lorsqu’un moteur explore une page, il veut en lire le contenu. Sur un site très dépendant de JavaScript, le contenu n’est parfois pas encore dans la page : le robot doit d’abord exécuter JavaScript, ce qui peut être retardé. Avec Astro, le contenu est déjà dans le HTML au moment où la page se charge. Il n’y a rien à attendre.

J’exploite mon propre site, patrickstox.com, avec Astro : ce n’est donc pas une théorie pour moi. C’est réellement la pile sur laquelle je construis.

Pourquoi Astro est bon pour le SEO

• Le contenu se trouve immédiatement dans le HTML. Aucun délai de rendu, aucun contenu manquant.
• C’est rapide. Les sites Astro sont légers et obtiennent souvent de très bons résultats dans les métriques d’expérience de page de Google (Core Web Vitals).
• Chaque page possède sa propre vraie URL. Pas de routage sophistiqué d’application monopage susceptible d’embrouiller les robots.
• Le JavaScript ne se charge que là où il est nécessaire. Une galerie photo ou une zone de recherche peut rester interactive sans ralentir le reste de la page.

Ce qu’Astro ne fait PAS pour vous

C’est un point qui prête à confusion. « Astro est optimisé pour le SEO » n’est vrai qu’à moitié. Astro fournit une base propre, mais ne fait pas automatiquement les opérations suivantes :

• Écrire les titres et les descriptions meta de vos pages.
• Générer un sitemap (vous ajoutez pour cela une intégration officielle gratuite). Evidence for this claim Astro's official sitemap integration generates sitemap files from statically generated routes. Scope: Astro @astrojs/sitemap integration. Confidence: high · Verified: 2026-07-14 Astro: Sitemap integration
• Ajouter les balises canoniques (qui indiquent à Google la version « officielle » d’une page).
• Ajouter les données structurées (le code qui permet les résultats enrichis).
• Créer un fichier robots.txt.

Rien de tout cela n’est difficile : c’est simplement à vous de le configurer. Pensez à Astro comme à une excellente cuisine : les appareils sont remarquables, mais c’est toujours vous qui cuisinez.

La checklist de démarrage

• Ajouter un sitemap avec l’intégration officielle @astrojs/sitemap.
• Définir une URL title, description et canonical sur chaque page (généralement depuis un fichier de mise en page partagé).
• Utiliser le composant intégré <Image /> d’Astro pour les photos : il accélère leur chargement et empêche la page de sauter.
• Placer un fichier robots.txt dans votre dossier public/.

Pour la version approfondie — Server Islands, View Transitions, rendu statique contre rendu serveur et erreurs précises à éviter — passez à l’onglet Advanced. Pour comprendre comment les moteurs traitent JavaScript, consultez le SEO JavaScript.

TL;DR — Astro est particulièrement bien conçu pour le SEO : les pages et les endpoints sont pré-rendus en HTML statique par défaut, sans vague de file de rendu à attendre pour ce contenu — mais il s’agit d’une valeur par défaut, pas d’une garantie universelle, et le HTML statique ou serveur ne prouve pas à lui seul l’explorabilité, l’indexation, les positions ni les Core Web Vitals de vos URL de production. L’architecture en îlots n’hydrate que les composants auxquels vous ajoutez une directive client:* : tout le reste envoie du HTML sans son propre JavaScript d’hydratation, même si des scripts de page, d’autres îlots et des améliorations de routeur peuvent ajouter du JavaScript ailleurs dans la page. Astro ne génère pas automatiquement les balises meta, les canoniques, les sitemaps ni les données structurées : branchez-les explicitement, idéalement avec une validation par Content Collections + Zod. Les Server Islands (qui nécessitent un adaptateur) servent l’enveloppe statique avec son contenu de repli dans le document initial, puis récupèrent le contenu différé séparément — vérifiez ce qu’un robot donné récupère réellement au lieu de supposer. Les View Transitions utilisent history.pushState et sont compatibles avec le SEO; Google explore normalement les pages MPA sous-jacentes. J’utilise patrickstox.com avec Astro : les fonctions ci-dessous sont celles que j’emploie réellement, vérifiées sur le site déployé et non seulement en développement local.

Pourquoi Astro évite complètement le problème du rendu JavaScript

Toute la difficulté du SEO JavaScript vient de la seconde vague. Google récupère d’abord votre HTML brut, puis met la page en file pour un rendu ultérieur dans Chromium sans interface — et cette file constitue le risque. Les documents de Google l’expliquent ainsi : “Googlebot queues all pages with a 200 HTTP status code for rendering unless a robots meta tag tells Google not to index the page. The page may stay on this queue for a few seconds, but it can take longer than that.” (traduction) : « Googlebot met en file pour le rendu toute page dont le statut HTTP est 200, sauf si une balise meta robots lui indique de ne pas l’indexer. La page peut rester dans cette file quelques secondes, mais l’attente peut être plus longue. » Pour une SPA rendue côté client, votre contenu n’existe pas avant cette phase de rendu.

Le mode de sortie par défaut d’Astro est statique : les pages et les endpoints sont pré-rendus dans un fichier HTML complet au moment du build. Pour une route qui utilise cette valeur par défaut, le HTML brut est la page rendue. Evidence for this claim Astro uses static output and prerenders routes at build time by default. Scope: Astro default output mode; routes can opt out of prerendering. Confidence: high · Verified: 2026-07-14 Astro: On-demand rendering Il n’y a aucune seconde vague à attendre pour cette route, puisqu’il ne reste rien à exécuter. Googlebot voit tout le contenu dès la première récupération. Comme l’écrit Joost de Valk (fondateur de Yoast) : “From an SEO perspective, static HTML on a CDN is a better starting point than most CMSes will ever give you.” (traduction) : « Du point de vue du SEO, un HTML statique sur un CDN constitue un meilleur point de départ que ce que la plupart des CMS pourront jamais offrir. »

C’est le comportement par défaut, pas une propriété universelle de chaque route. Avec output: 'server', la valeur par défaut devient un rendu à la demande (nous y revenons plus bas); même dans un projet statique par défaut, un adaptateur permet à une route donnée de désactiver le pré-rendu avec export const prerender = false. Rien de tout cela n’est garanti par la seule architecture : le HTML statique ou serveur, les îlots et les adaptateurs ne garantissent pas l’explorabilité, l’indexation, les positions ni les Core Web Vitals — tout dépend de la route déployée et du robot précis. Vérifiez-les au lieu de supposer que le cadre s’en charge.

Cela aide aussi les robots qui ne peuvent pas effectuer de rendu. Google le dit clairement : “not all bots can run JavaScript” (traduction) : « tous les robots ne peuvent pas exécuter JavaScript » — et c’est la réalité de 2026 pour la plupart des robots d’IA et de nombreux outils tiers. La sortie HTML d’abord d’Astro est lisible par chacun d’eux lorsqu’elle est effectivement pré-rendue, pas seulement par Googlebot. (C’est le même point que je soulève dans le SEO d’un CMS headless : le mode de rendu fait partie du produit.)

Architecture en îlots : du JS uniquement là où vous le demandez

Astro rend vos composants en HTML et, selon ses propres termes, envoie “just HTML & CSS, stripping out all client-side JavaScript automatically.” (traduction) : « uniquement du HTML et du CSS, en retirant automatiquement tout le JavaScript côté client ». L’interactivité est opt-in. Vous marquez un composant avec une directive client:* — client:load, client:idle ou client:visible — et seul cet îlot est hydraté avec JavaScript. Tout le reste demeure du HTML statique. Evidence for this claim Astro client directives selectively hydrate interactive islands while other components remain static HTML. Scope: Astro islands and client directives. Confidence: high · Verified: 2026-07-14 Astro: Islands

Pour le SEO, c’est presque idéal. Le contenu que Googlebot doit indexer est du HTML simple, et vos widgets interactifs ne l’alourdissent pas. client:visible est particulièrement utile : un composant sous la ligne de flottaison ne commence même pas son hydratation avant d’être visible au défilement, et ne bloque donc jamais votre LCP. Le concept vient de Jason Miller (créateur de Preact), qui le décrit comme “rendering HTML pages on the server, and inject[ing] placeholders or slots around highly dynamic regions.” (traduction) : « rendre des pages HTML sur le serveur et injecter des espaces réservés ou des emplacements autour de régions très dynamiques ».

Deux nuances méritent une formulation précise, car les comparatifs les confondent souvent :

• client:only est différent. Contrairement à client:load/client:idle/client:visible, un composant client:only ignore entièrement le rendu serveur : il ne produit aucun HTML côté serveur. Tout contenu indexable placé uniquement dans un composant client:only ne se trouve donc pas dans le document récupéré par Googlebot; il n’existe qu’après l’hydratation du navigateur. N’y placez pas votre contenu principal.
• Il s’agit d’hydratation sélective, pas de reprise d’exécution. Astro relance le code client de chaque îlot depuis zéro dans le navigateur; il ne reprend pas un état d’exécution sérialisé sur le serveur comme le ferait un modèle de reprise (celui de Qwik, par exemple). Les deux mécanismes sont souvent confondus dans les articles, mais ils ne sont pas identiques.

Un composant non hydraté ne résume pas tout le JavaScript d’une page. « Zéro JS » décrit un composant sans directive client:* : Astro peut encore envoyer des balises <script> au niveau de la page, le routeur des View Transitions et d’autres îlots ailleurs sur la même page. Décrivez ce qui est envoyé par composant ou par route, pas comme une affirmation générale sur toute la page.

Ce qu’Astro ne génère PAS automatiquement

Astro produit un HTML sémantique propre — et rien d’autre en matière de SEO. Il n’y a par défaut ni métadonnées, ni canonique, ni sitemap, ni données structurées. Le mythe selon lequel « Astro est automatiquement optimisé pour le SEO » est exactement cela, un mythe. Vous devez prendre en charge :

• Les balises meta (titre, description, Open Graph, Twitter).
• Les URL canoniques.
• Le sitemap (via l’intégration officielle).
• Les données structurées / JSON-LD.
• robots.txt.

Astro est la meilleure base que j’aie utilisée, mais c’est une base, pas une maison terminée.

Le sitemap : @astrojs/sitemap

Installez-le avec npx astro add sitemap. Il explore les routes générées statiquement et émet au moment du build un sitemap-index.xml ainsi que des fichiers sitemap-0.xml découpés. Deux points piègent souvent les utilisateurs : Evidence for this claim Astro's official sitemap integration generates sitemap files from statically generated routes. Scope: Astro @astrojs/sitemap integration. Confidence: high · Verified: 2026-07-14 Astro: Sitemap integration

• Vous devez définir site: dans astro.config.mjs. Sans cette valeur, l’intégration génère silencieusement un résultat vide. C’est la cause la plus fréquente du « où est mon sitemap ? ».
• Vous devez ajouter vous-même la ligne du sitemap dans robots.txt. Astro ne le fait pas.

Pour garder le contrôle, filter() exclut des routes (pages d’aperçu ou brouillons — c’est exactement ce que j’utilise sur ce site), serialize() permet de définir lastmod, changefreq et priority, et l’option i18n émet des entrées hreflang dans le sitemap. C’est ce que spécifient les documents actuels de @astrojs/sitemap; vérifiez votre version installée si elle est ancienne, car le comportement de l’intégration a déjà changé entre versions majeures.

La limite qui piège le plus : la découverte de l’intégration vise les routes générées statiquement. Si certaines URL n’existent qu’à l’exécution — routes rendues côté serveur (output: 'server') ou générées à la demande plutôt qu’au moment du build — ne supposez pas qu’elles figurent dans le sitemap. Ajoutez-les explicitement avec customPages, puis ouvrez réellement sitemap-index.xml après un build pour confirmer leur présence. Ne prenez pas pour acquis que « l’intégration s’en charge » lorsqu’il ne s’agit pas d’une route statique de build.

Balises meta et canoniques : le modèle BaseLayout

Astro n’a pas de composant <Head> spécial : vous contrôlez directement <head> dans les fichiers .astro. Le modèle courant (et celui que j’utilise) est un unique BaseLayout.astro qui reçoit title, description et canonicalURL comme props et écrit l’en-tête. Définissez explicitement le canonique sur chaque page et gardez-le cohérent avec og:url. Une bibliothèque n’est pas nécessaire, mais le paquet communautaire astro-seo (npm) est un wrapper pratique à un composant pour le titre, la description, OG, Twitter et le canonique si vous le souhaitez.

Content Collections comme filet de sécurité SEO

C’est une fonction SEO sous-estimée d’Astro. Les Content Collections constituent une couche de contenu typée pour votre Markdown/MDX/JSON, avec validation de schéma par Zod. Vous pouvez ainsi rendre les champs title et description obligatoires; si une page en oublie un, le build échoue. Il est alors impossible d’envoyer par accident une page sans titre. Les fonctions de requête (getCollection(), getEntry()) produisent les pages statiques au moment du build, donc la sortie déployée est du HTML simple. Et puisque MDX conserve le Markdown brut comme source de vérité, ces fichiers forment aussi un contenu source propre pour les robots d’IA et les motifs de type llms.txt. Ce site même repose sur des Content Collections avec un frontmatter validé par Zod.

astro:assets : des images bien faites (avec un piège)

Le composant <Image /> convertit automatiquement en WebP, déduit les dimensions pour “avoid Cumulative Layout Shift (CLS).” (traduction) : « éviter le décalage cumulatif de mise en page (CLS) », définit loading="lazy" par défaut et exige alt — l’absence de alt est une erreur de compilation. <Picture /> étend ce comportement avec des éléments <source> AVIF/WebP et une solution de repli.

Le piège : le loading="lazy" automatique est mauvais pour votre image LCP (généralement l’image hero). Le chargement différé de l’image la plus importante retarde son affichage. Pour les images au-dessus de la ligne de flottaison, remplacez-le par loading="eager" et fetchpriority="high". Les images distantes ont besoin d’un width et d’un height explicites.

Server Islands : ce que voient réellement les robots

Les Server Islands (Astro 4.12+) sont la fonction que la plupart des guides concurrents décrivent mal. Avec server:defer, un composant est rendu sur le serveur indépendamment de la page principale. L’enveloppe statique est servie immédiatement; selon les documents Astro : “Your page will be rendered immediately with any specified fallback content as a placeholder. Then, the component’s own contents are fetched on the client and displayed when available.” (traduction) : « Votre page est rendue immédiatement avec le contenu de repli spécifié comme espace réservé. Le contenu propre au composant est ensuite récupéré côté client et affiché lorsqu’il est disponible. »

Deux points doivent être exacts. Premièrement, les Server Islands nécessitent un adaptateur : c’est une fonction à la demande, pas un résultat produit par un build entièrement statique. Deuxièmement, la séquence est la suivante : le document initial envoie le contenu de repli que vous avez configuré, puis le contenu réel de l’îlot est récupéré par une requête indépendante sur son propre endpoint, après le chargement de la page. C’est une limite ferme de ce que contient le premier document; je ne généraliserais pas au comportement ultérieur de chaque robot sans tester directement vos URL déployées.

La conséquence SEO est concrète : le HTML statique lu par un robot lors de la première récupération contient le contenu de repli, pas celui de l’îlot différé. C’est parfait pour l’usage prévu des Server Islands : les informations personnalisées liées à la session (état de connexion, panier, recommandations) qui ne devraient de toute façon ni être mises en cache ni indexées. C’est inadapté au contenu indexable principal. Placez tout ce qui doit être positionné dans le modèle Astro principal, et laissez les Server Islands gérer les éléments dynamiques autour.

Modes de sortie : statique ou serveur, avec remplacement par route

Le mode de sortie par défaut d’Astro est static : les pages et les endpoints sont pré-rendus en HTML lors du build. Définissez output: 'server' dans astro.config.mjs pour passer par défaut au rendu à la demande : les pages sont rendues pour chaque requête (avec un adaptateur), ce qui convient à l’authentification, aux données en temps réel ou à la personnalisation au-delà des Server Islands. Dans les deux cas, vous pouvez remplacer le défaut par route : dans un projet statique par défaut, export const prerender = false active le rendu à la demande; dans un projet serveur par défaut, export const prerender = true réactive le pré-rendu au moment du build. Ainsi, « mon site est statique » ou « mon site est en SSR » est rarement vrai pour toutes les routes : vérifiez le réglage par route, pas seulement la configuration de niveau supérieur.

Du point de vue du seul SEO, le HTML pré-rendu et le HTML à la demande sont équivalents — tous deux fournissent un HTML complet à la première requête d’un robot, une fois que vous avez confirmé que la route renvoie un statut 200 avec tout son balisage. Les routes à la demande peuvent envoyer leur HTML en flux, et des données lentes ou des conditions réseau peuvent retarder des morceaux ultérieurs; une réponse en flux ne prouve donc pas automatiquement que tout le contenu est arrivé : vérifiez-le, ne le supposez pas. La différence réelle est opérationnelle : le contenu pré-rendu reste fixe jusqu’au prochain build (ou à une actualisation d’exécution configurée séparément) et est servi depuis le bord CDN; le contenu à la demande reste actuel, mais dépend de la santé de l’adaptateur et de l’exécution en production. N’en faites pas une décision SEO : choisissez selon l’actualité des données et l’exploitation, puis validez les routes déployées, les statuts, les redirections et les en-têtes de réponse plutôt que d’extrapoler depuis le développement local.

View Transitions : compatibles avec le SEO malgré l’impression d’application monopage

Le <ClientRouter /> d’Astro (anciennement <ViewTransitions />) fournit une navigation douce de type SPA à l’aide de l’API View Transitions du navigateur et de la History API. Le fait clé : la navigation utilise history.pushState, exactement ce que Google recommande pour la navigation côté client — Google avertit que les URL fondées sur un fragment (#hash) sont quelque chose qu’il “can’t reliably resolve.” (traduction) : « ne peut pas résoudre de manière fiable ». Surtout, les View Transitions améliorent l’expérience dans le navigateur : lorsqu’il explore, Googlebot demande chaque URL et reçoit une page HTML normale et complète; la MPA sous-jacente reste intacte. Les transitions ne changent que ce que voit l’utilisateur dans le navigateur.

Donc non, les View Transitions ne transforment pas votre site Astro en SPA et ne cassent pas le SEO. Une lacune à noter : les documents View Transitions d’Astro n’ont aucune section SEO, ce qui explique peut-être la persistance du mythe « cela casse le SEO ». Pour vérifier votre propre site, récupérez directement quelques URL et confirmez que chacune renvoie un HTML complet : contrôlez votre déploiement au lieu de vous en remettre à une supposition.

Erreurs SEO courantes avec Astro

1. Supposer qu’Astro s’occupe du SEO. Il s’occupe du HTML. Les meta, canoniques, sitemap et schéma vous reviennent.
2. Oublier site: dans la configuration : votre sitemap ne se génère silencieusement pas.
3. Ne pas ajouter le sitemap à robots.txt : Astro ne le fera pas.
4. Charger l’image LCP en différé : remplacez le héros par eager + fetchpriority.
5. Placer du contenu indexable dans une Server Island : les robots voient le repli, pas le contenu, et les Server Islands nécessitent d’abord un adaptateur.
6. Poursuivre un score Lighthouse parfait et s’arrêter là. La vitesse est un signal de classement, pas le signal de classement. Une page rapide mais vide ne se positionne pas : le contenu, les liens et l’E-E-A-T font toujours l’essentiel du travail.
7. Placer du contenu indexable uniquement dans un composant client:only. Contrairement aux autres directives client:*, client:only ignore totalement le rendu serveur : il n’y a aucun HTML pour ce composant avant l’hydratation du navigateur.
8. Traiter « Astro est statique et rapide » comme une garantie de résultat. Le HTML statique ou à la demande, les îlots et les adaptateurs sont des mécanismes; ils ne garantissent pas à eux seuls l’explorabilité, l’indexation, les positions ni les Core Web Vitals. Validez la route déployée et non le schéma d’architecture.

Où ce sujet se place dans le cluster

Astro est une réponse particulière et exceptionnellement favorable au SEO aux questions que pose le SEO JavaScript sur le rendu, et un frontend courant pour les configurations de CMS headless. La performance rejoint directement les Core Web Vitals du cluster des performances web, tandis que la discipline consistant à vérifier si le contenu se trouve bien dans le HTML est la même que dans les clusters d’exploration et d’indexation.

Anti-patterns SEO avec Astro

Voici des erreurs concrètes que je vois sur les sites Astro, pas des hypothèses. Chaque point relève de la prévention et non du diagnostic : détectez-le avant la mise en production.

Traiter Astro comme « optimisé pour le SEO » dès l’installation

Astro fournit un HTML statique rapide et propre, ce qui constitue réellement une grande avance, mais ce n’est pas la même chose que des balises meta, des canoniques, un sitemap ou des données structurées. Pourquoi c’est incorrect : des équipes publient des pages sans <title> différente, sans canonique et sans sitemap parce qu’« Astro s’occupe du SEO », puis s’étonnent que l’indexation ne se déroule pas comme prévu. À faire : branchez dès le premier jour les props title/description/canonical de BaseLayout.astro, ajoutez @astrojs/sitemap et traitez ces éléments comme des étapes de build obligatoires, pas comme des valeurs par défaut.

Oublier site: dans astro.config.mjs

C’est le signalement le plus courant lorsqu’un sitemap est vide. Pourquoi c’est incorrect : @astrojs/sitemap a besoin d’une URL de site absolue pour construire les entrées <loc> absolues; sans site: défini, l’intégration ne produit rien en silence (ni erreur ni avertissement). À faire : définissez site: dans astro.config.mjs avant d’installer l’intégration du sitemap, puis vérifiez après le prochain build que sitemap-index.xml contient réellement des URL.

Oublier le sitemap dans robots.txt

Installer @astrojs/sitemap n’ajoute pas de ligne Sitemap: à robots.txt : c’est une étape manuelle distincte que beaucoup supposent automatique. Pourquoi c’est incorrect : les moteurs peuvent encore trouver le sitemap si vous l’envoyez dans Search Console, mais vous perdez le chemin de découverte passive utilisé par d’autres robots (et par les robots liés à Bing/IndexNow). À faire : ajoutez Sitemap: https://yoursite.com/sitemap-index.xml à votre robots.txt dans public/ et confirmez sa résolution après le déploiement.

Laisser loading="lazy" par défaut sur l’image hero

Le composant <Image /> d’Astro charge par défaut les images en différé, ce qui convient aux images sous la ligne de flottaison mais pas à celle qui constitue généralement votre LCP. Pourquoi c’est incorrect : le chargement différé du héros empêche le navigateur de commencer rapidement sa requête et dégrade directement votre score de Largest Contentful Paint. À faire : remplacez explicitement l’image hero ou située au-dessus de la ligne de flottaison par loading="eager" et fetchpriority="high", tout en laissant les autres images utiliser le chargement différé par défaut.

Placer du contenu indexable dans une Server Island

server:defer est destiné au contenu personnalisé lié à la session — panier, état de connexion, recommandations — et non à ce que vous voulez positionner. Pourquoi c’est incorrect : le HTML statique qu’un robot lit contient le contenu de repli défini pour l’îlot, et non ce qui est récupéré côté client après le chargement; tout contenu principal placé là est donc invisible aux moteurs lors du premier crawl. À faire : gardez le contenu à positionner dans le modèle Astro principal et réservez les Server Islands aux éléments dynamiques et personnalisés qui ne doivent de toute façon pas être indexés.

Supposer qu’un score Lighthouse rapide est la ligne d’arrivée

Les sites Astro obtiennent presque par défaut de bons Core Web Vitals et il est tentant de s’arrêter là. Pourquoi c’est incorrect : la vitesse est un signal de classement parmi d’autres; une page rapide, vide ou mince ne dépassera pas une page plus lente mais dotée d’un meilleur contenu, de liens et d’une profondeur thématique plus solide. À faire : considérez la performance comme une base obtenue gratuitement avec Astro, puis consacrez l’effort d’optimisation à la qualité du contenu, au maillage interne et au travail sur les meta/données structurées qu’Astro ne réalise pas pour vous.

Supposer que « statique par défaut » vaut pour chaque route

Le mode de sortie statique d’Astro est la valeur par défaut, pas une propriété universelle : output: 'server' l’inverse, et prerender peut être défini par route dans les deux sens. Pourquoi c’est incorrect : les équipes décrivent tout leur site comme « statique » ou « SSR » à partir de la configuration supérieure sans vérifier les routes individuelles, puis sont surprises qu’une route se comporte différemment en production. À faire : examinez le réglage prerender de chaque route concernée et validez la réponse réelle (statut, balisage complet, redirection) sur l’URL déployée plutôt que le fichier de configuration.

Placer le contenu uniquement dans un composant client:only

client:only n’est pas identique à client:load/client:idle/client:visible : il ignore entièrement le rendu serveur. Pourquoi c’est incorrect : un composant utilisant client:only ne produit aucun HTML sur le serveur; tout contenu indexable qui y est placé uniquement est invisible pour un robot lisant la réponse brute, et il est facile d’utiliser client:only par « simplicité » sans voir le coût SEO. À faire : rendez le contenu principal dans un composant rendu côté serveur ou dans le modèle de page; réservez client:only aux widgets d’interaction qui ne contiennent rien d’indexable.

Résumé par IA

Version condensée de la version Advanced :

• Le mode de sortie par défaut d’Astro pré-rend du HTML statique au moment du build : pour une route qui utilise ce défaut, le HTML brut est la page finale et le problème de « seconde vague » de la file de rendu de Google ne s’applique pas. C’est un défaut, pas une propriété universelle : output: 'server' l’inverse et prerender peut remplacer le choix par route dans les deux sens.
• L’architecture en îlots n’hydrate que les composants marqués avec client:*; un composant sans cette directive envoie du HTML sans son propre JavaScript d’hydratation (Astro peut toutefois ajouter des scripts de page, d’autres îlots et du JavaScript de routeur ailleurs). client:only est l’exception : il ignore entièrement le rendu serveur, donc le contenu indexable ne doit pas y vivre seul. Il s’agit d’hydratation sélective, pas de reprise d’exécution. client:visible empêche le JavaScript situé sous la ligne de flottaison de bloquer le LCP.
• Astro ne génère rien automatiquement pour le SEO : balises meta, canoniques, sitemap, données structurées et robots.txt sont toutes des étapes de build explicites. Dire qu’Astro est automatiquement optimisé pour le SEO est un mythe.
• @astrojs/sitemap découvre les routes générées statiquement; vous devez définir site: dans la configuration (sinon il ne fait rien en silence), ajouter vous-même la ligne du sitemap à robots.txt et ajouter explicitement les URL disponibles uniquement à l’exécution avec customPages.
• Content Collections + Zod peuvent rendre title et description obligatoires, ce qui fait échouer le build lorsqu’une page les oublie : c’est un filet de sécurité SEO.
• astro:assets et <Image> convertissent en WebP, définissent les dimensions (ce qui évite le CLS), chargent en différé par défaut et exigent alt. Remplacez le comportement par défaut de l’image LCP avec loading="eager" + fetchpriority="high".
• Les Server Islands (server:defer) nécessitent un adaptateur, servent immédiatement l’enveloppe statique et son contenu de repli dans le document initial, puis récupèrent l’îlot séparément. Les robots qui lisent ce premier document voient le repli, pas l’îlot : n’y placez jamais de contenu indexable.
• Les sorties statique et à la demande (serveur) sont équivalentes pour le SEO une fois vérifiées : toutes deux livrent un HTML complet à la première requête, mais les routes à la demande peuvent envoyer un flux; confirmez donc que la réponse arrive complète. Choisissez le mode selon l’actualité des données et l’exploitation, pas selon le SEO.
• Les View Transitions (<ClientRouter />) utilisent history.pushState et sont compatibles avec le SEO; Google explore normalement les pages MPA sous-jacentes. Il s’agit d’une amélioration côté navigateur, pas d’une conversion en SPA.
• Rien de tout cela ne garantit un résultat : HTML statique ou serveur, îlots et adaptateurs sont des mécanismes, pas une preuve d’explorabilité, d’indexation, de positions ou de Core Web Vitals. Validez la route déployée.
• Astro affiche de très bons Core Web Vitals dans son propre benchmark de 2023 : plus de 50 % des sites Astro ont passé l’évaluation CWV de Google, bien au-dessus de la référence industrielle de l’époque; considérez-le comme un point de données daté, non comme une garantie actuelle.

Documentation officielle

Documentation de première main d’Astro et des moteurs de recherche.

Astro

• Architecture en îlots — comment Astro retire le JavaScript côté client et n’hydrate que les composants interactifs.
• Référence des directives de modèle — client:load/idle/visible/only et server:defer, y compris ce que client:only ignore.
• Optimisation des images (astro:assets) — les composants <Image>/<Picture>, WebP, les dimensions et le CLS.
• @astrojs/sitemap — génération automatique du sitemap, filter, serialize et i18n.
• Server Islands — server:defer, l’adaptateur requis, le contenu de repli et la récupération différée côté client.
• Rendu à la demande — les modes de sortie static/server, le prerender par route et l’envoi du HTML en flux.
• Référence du routage — la manière dont les pages et endpoints sont pré-rendus par défaut.
• Référence de l’API d’exécution Astro — la gestion de Response/des redirections et les statuts par défaut.
• Content Collections — contenu typé avec validation de schéma Zod.
• View Transitions — <ClientRouter /> et navigation par History API.

Google

• Comprendre les bases du SEO JavaScript — la file de rendu, les liens explorables, la History API et la réserve « tous les robots n’exécutent pas JavaScript ».
• Guide détaillé du fonctionnement de Google Search — exploration, rendu, indexation et endroit où le SSG supprime l’étape de rendu.

Bing / Microsoft

• IndexNow / indexnow.org — le protocole push qui s’accorde bien avec un déploiement Astro statique (branchez-le à l’étape de publication pour que Bing et Yandex soient informés immédiatement des nouvelles URL).

Citations de la source

Déclarations attribuées provenant des documents Astro, de Google et de praticiens nommés. Chaque lien vers un moteur ou une documentation pointe directement vers le passage cité.

Google — la file de rendu qu’Astro évite

• “Googlebot queues all pages with a 200 HTTP status code for rendering unless a robots meta tag tells Google not to index the page. The page may stay on this queue for a few seconds, but it can take longer than that.” (traduction) : « Googlebot place toute page au statut HTTP 200 dans une file de rendu, sauf si une balise meta robots lui demande de ne pas l’indexer. Elle peut y attendre quelques secondes, voire davantage. » Accéder à la citation
• “not all bots can run JavaScript” (traduction) : « tous les robots ne peuvent pas exécuter JavaScript » — c’est pourquoi une sortie HTML d’abord aide au-delà de Googlebot. Accéder à la citation

Documents Astro — îlots, images, sitemaps et Server Islands

• “just HTML & CSS, stripping out all client-side JavaScript automatically.” (traduction) : « uniquement du HTML et du CSS, en retirant automatiquement tout le JavaScript côté client » — à propos de l’architecture en îlots. Accéder à la citation
• “infers image dimensions to avoid Cumulative Layout Shift (CLS).” (traduction) : « déduit les dimensions des images pour éviter le décalage cumulatif de mise en page (CLS) » — à propos du composant Image. Accéder à la citation
• “Your page will be rendered immediately with any specified fallback content as a placeholder. Then, the component’s own contents are fetched on the client and displayed when available.” (traduction) : « votre page est rendue immédiatement avec le contenu de repli spécifié comme espace réservé; le contenu propre au composant est ensuite récupéré côté client et affiché lorsqu’il est disponible » — à propos des Server Islands. Accéder à la citation

Jason Miller (créateur de Preact, à l’origine de l’expression « architecture en îlots »)

• L’hydratation sélective fonctionne en “rendering HTML pages on the server, and inject[ing] placeholders or slots around highly dynamic regions.” (traduction) : « rendant des pages HTML sur le serveur et injectant des espaces réservés ou des emplacements autour de régions très dynamiques ». — cité dans les documents Astro sur l’architecture en îlots.

Joost de Valk (fondateur de Yoast SEO)

• “From an SEO perspective, static HTML on a CDN is a better starting point than most CMSes will ever give you.” (traduction) : « du point de vue du SEO, un HTML statique sur un CDN est un meilleur point de départ que ce que la plupart des CMS pourront jamais offrir ». — Joost.blog : Astro SEO Complete Guide

Checklist SEO Astro

Un passage de contrôle pour confirmer qu’un site Astro est réellement configuré pour la recherche, et ne repose pas seulement sur une bonne base :

• site: est défini dans astro.config.mjs (sans lui, le sitemap ne se génère pas, silencieusement).
• @astrojs/sitemap est installé et la référence du sitemap est ajoutée manuellement à robots.txt.
• Un robots.txt existe dans public/ et ne bloque rien de ce que vous voulez indexer.
• Chaque page définit un title et une description uniques (idéalement via un BaseLayout.astro partagé).
• Un canonique auto-référent se trouve sur chaque page et correspond à og:url.
• Les Content Collections utilisent un schéma Zod qui rend title/description obligatoires (le build échoue s’ils manquent).
• Les images utilisent <Image /> / <Picture />; toutes possèdent alt (son absence est de toute façon une erreur de compilation).
• L’image LCP/hero remplace le chargement différé par défaut par loading="eager" et fetchpriority="high".
• Aucun contenu indexable ne se trouve dans une Server Island (server:defer) : les robots voient le repli et les Server Islands nécessitent un adaptateur.
• Aucun contenu indexable ne se trouve uniquement dans un composant client:only : le rendu serveur est ignoré, donc il n’y a pas de HTML avant l’hydratation du navigateur.
• Pour toute route qui utilise output: 'server' ou prerender = false, confirmez que les URL uniquement disponibles à l’exécution sont ajoutées explicitement au sitemap (customPages) : la découverte automatique vise les routes générées statiquement.
• Les données structurées (JSON-LD) se trouvent dans le <head> rendu côté serveur.
• Si <ClientRouter /> est activé, contrôlez quelques URL pour confirmer que chacune renvoie encore un HTML complet lors d’une récupération directe.
• Pour les routes à la demande ou serveur : récupérez directement une URL de production et confirmez le statut, les redirections et le HTML complet de la réponse; n’extrapolez pas depuis le développement local, car l’adaptateur et l’exécution peuvent se comporter différemment.

Les modèles mentaux

1. Le HTML brut est la page terminée — pour le défaut de cette route. Le mode de sortie statique d’Astro signifie qu’il n’y a aucune vague de rendu à attendre pour une route pré-rendue : ce que Googlebot récupère est ce qui est indexé. C’est une valeur par route, pas une garantie pour tout le site (output: 'server' et prerender peuvent la modifier); contrôlez la route et non seulement la configuration supérieure. Lorsqu’elle s’applique, View Source est la vérité (l’inverse d’une SPA CSR), mais confirmez d’abord qu’elle s’applique avant d’en faire un fait.

2. Une base, pas une finition, et pas une garantie de résultat. Astro fournit gratuitement du HTML propre et de solides mécanismes de performance. Tout ce qui signale une signification aux moteurs — meta, canonique, sitemap, schéma — est une étape explicite à ajouter. « Bonne architecture » ≠ « terminé », et aucune des deux ne prouve l’explorabilité, l’indexation ou les positions : il faut encore les valider sur le site déployé.

3. Les îlots sont additifs — sauf client:only. L’interactivité se pose au-dessus du HTML, jamais à sa place, pour client:load/client:idle/client:visible : ces directives ajoutent du JS à un composant sans retirer son contenu de la base explorable. client:only rompt ce schéma : le rendu serveur est entièrement ignoré, ce n’est donc pas un ajout, mais un véritable manque dans le HTML statique si vous ne prévoyez rien. L’hydratation des îlots est sélective, pas une reprise d’exécution : ne confondez pas les deux.

4. L’enveloppe statique est ce que voient les robots. Pour les Server Islands, le robot lit le contenu de repli de l’enveloppe statique, pas le contenu différé. Règle de décision : le contenu indexable va dans le modèle principal; le contenu personnalisé ou dynamique va dans l’îlot.

5. Une amélioration du navigateur ≠ un changement structurel. Les View Transitions modifient l’expérience du navigateur (navigation douce via history.pushState), mais pas l’expérience d’exploration (chaque URL reste une page HTML complète). Les améliorations qui laissent la MPA sous-jacente intacte sont compatibles avec le SEO.

6. Valider au moment du build. Content Collections + Zod transforment « pensez à ajouter un titre » en « le build ne partira pas sans titre ». Placez les exigences SEO dans le système de types et elles cessent d’être des oublis possibles.

Fiche mémo SEO Astro

Ce qui est automatique et ce qui vous revient

Modes de sortie

Directives d’îlot

• client:load — hydrater immédiatement.
• client:idle — hydrater lorsque le navigateur est inactif.
• client:visible — hydrater lorsque le composant entre dans la fenêtre (idéal sous la ligne de flottaison; protège le LCP).
• client:only — ignore entièrement le rendu serveur. Aucun HTML pour ce composant avant l’hydratation du navigateur; contrairement aux autres, cette directive n’est pas additive.

Règles rapides

• site: absent → aucun sitemap (silencieusement).
• Contenu indexable dans une Server Island → le robot voit le repli; les Server Islands nécessitent un adaptateur.
• Contenu indexable uniquement dans client:only → aucun HTML, définitivement.
• Le sitemap couvre les routes statiques → ajoutez les URL uniquement à l’exécution avec customPages.
• Les View Transitions utilisent history.pushState → compatibles SEO, avec une MPA sous-jacente.
• Le rendu statique ou serveur et les îlots sont des mécanismes, pas des garanties : validez la route déployée, son statut et son HTML complet avant d’affirmer un résultat.
• Une page rapide mais vide ne se positionne toujours pas : la vitesse est un signal, pas le signal.

Auditer le HTML produit par Astro

Exécutez ceci après astro build. Le script vérifie l’artefact reçu par les robots, pas l’arbre des composants source :

find dist -name '*.html' -type f | while IFS= read -r file; do
  canonicals=$(grep -Eio '<link[^>]+rel=["'"']canonical["'"'][^>]*>' "$file" | wc -l | tr -d ' ')
  titles=$(grep -Eio '<title>[^<]*</title>' "$file" | wc -l | tr -d ' ')
  if [ "$canonicals" -ne 1 ] || [ "$titles" -ne 1 ]; then
    printf '%s\ttitles=%s\tcanonicals=%s\n' "$file" "$titles" "$canonicals"
  fi
done

Un résultat vide signifie que chaque fichier HTML généré possède exactement un titre et un canonique; cela ne vérifie pas si leurs valeurs sont correctes, donc échantillonnez-les séparément. Ce contrôle ne couvre que l’artefact de build : il ne dit rien des routes à la demande (output: 'server') ni des Server Islands, qui n’existent pas comme fichiers statiques.

Contrôler les routes en production

Pour tout ce qui est rendu à la demande — routes output: 'server', prerender = false par route ou Server Islands — le contrôle de sortie précédent ne suffit pas. Vérifiez plutôt la réponse réellement déployée :

# Replace with your real URLs
for url in "https://example.com/" "https://example.com/some-server-route/"; do
  echo "== $url =="
  curl -sS -D - -o /dev/null "$url" | grep -Ei '^(HTTP|location|cache-control):'
done

Recherchez le statut attendu (200 pour une page active, un vrai code de redirection si elle redirige; ne supposez pas 302 ou 301 sans vérifier) et confirmez que curl -sS "$url" renvoie bien tout le balisage, pas une enveloppe de repli, si vous contrôlez une page qui inclut une Server Island. Faites ce test en production, pas avec astro dev : le comportement de l’adaptateur et de l’exécution peut différer en local.

Outils pour un site Astro

• @astrojs/sitemap — l’intégration officielle du sitemap (astro add sitemap). N’oubliez pas site: dans la configuration.
• **astro-seo (npm) — composant communautaire facultatif qui regroupe le titre, la description, Open Graph, les cartes Twitter et le canonique dans une seule balise.
• **astro-seo-schema (npm) — aide typée pour les données structurées JSON-LD dans Astro.
• **astro:assets <Image> / <Picture> — optimisation d’image intégrée (WebP/AVIF, dimensions, chargement différé et contrôle de alt).
• Inspection d’URL (Google Search Console) — confirmez que votre contenu se trouve dans le HTML exploré (avec Astro, il devrait déjà être présent dans View Source : un contrôle rapide).
• Un robot d’exploration JavaScript — Ahrefs Site Audit ou Screaming Frog pour vérifier la parité entre HTML brut et HTML rendu (les routes pré-rendues devraient correspondre; confirmez-le au lieu de le supposer, et contrôlez séparément les routes à la demande ou les Server Islands).
• IndexNow — associez-le à l’étape de déploiement ou de publication pour que Bing et Yandex soient informés immédiatement des nouvelles pages statiques.

Testez vos connaissances : Astro SEO

Cinq questions rapides sur l’effet de l’architecture Astro sur le SEO. Choisissez une réponse, puis vérifiez votre choix.

Ressources à consulter

Mes articles connexes

• SEO JavaScript : guide définitif — les bases du rendu qui expliquent pourquoi la sortie HTML d’abord d’Astro constitue un tel avantage.
• Guide du SEO technique pour débutants — la place du choix de cadre dans une vue d’ensemble plus large.

Mes présentations

• How Search Works (SlideShare) — mon parcours de l’exploration, du rendu, de l’indexation et du classement, c’est-à-dire le pipeline que le défaut SSG d’Astro court-circuite. (Réserve permanente : “This is my understanding of systems… not going to be 100% complete or accurate.” (traduction) : « voici ma compréhension des systèmes; elle ne sera ni complète ni exacte à 100 %. »)

À travers le secteur

• Documents Astro : architecture en îlots — l’explication de référence sur la manière dont Astro retire le JavaScript côté client.
• Documents Astro : @astrojs/sitemap — configuration officielle, exigence de site: et options filter/serialize/i18n.
• Documents Astro : Server Islands — server:defer, contenu de repli et comportement de récupération côté client que les robots ne voient pas.
• Joost de Valk : Astro SEO Complete Guide — le guide pratique le plus solide, par le fondateur de Yoast, avec de bons conseils sur les usages modernes prêts pour l’IA et IndexNow.
• Google Search Central : comprendre les bases du SEO JavaScript — la file de rendu, les liens explorables et les conseils sur la History API suivis par les View Transitions d’Astro.
• Astro : rapport de performance des cadres web 2023 — les données Core Web Vitals comparant Astro à d’autres cadres.
• Search Engine Journal : Core Web Vitals, WordPress et Astro — couverture indépendante de la comparaison de performance entre Astro et WordPress.

Statistiques à citer

Tous les chiffres ci-dessous proviennent du rapport Astro 2023 sur la performance des cadres web (et de sa couverture par SEJ); considérez-les comme des repères de 2023, pas comme des chiffres actuels.

• Plus de 50 % des sites Astro réussissent l’évaluation Core Web Vitals de Google — au-dessus de la moyenne industrielle d’environ 40,5 %; Astro et SvelteKit étaient les seuls grands cadres à dépasser cette référence (Next.js environ 25 %, Nuxt environ 20 %). Source
• Taux de réussite INP de 68,8 % pour Astro — attribué à l’architecture MPA (pas de navigation pilotée par JavaScript), qui laisse le thread principal disponible. Source
• Poids médian d’une page de 1,65 MB — le plus léger de l’ensemble de données. Source
• LCP : environ 0,44 s pour Astro contre environ 0,81 s pour WordPress — environ 46 % plus rapide dans la comparaison du rapport. Couverture

Journal des modifications