SEO Astro : comment faire remonter un site Astro dans les résultats

TL;DR : Astro vous donne une base SEO solide car il pré-génère le HTML statique et supprime par défaut le JavaScript côté client. Renseignez site dans astro.config.mjs, gardez le contenu indexable hors des composants client:only, puis configurez des métadonnées uniques, des canonicals absolus, un sitemap et un format d’URL cohérent. Ensuite, inspectez le HTML généré. Un arbre de composants “propre” ne prouve pas que la page déployée est crawlable.

Astro est bon pour le SEO, mais ne fait pas le SEO à votre place

La partie la plus forte du SEO dans Astro n’est pas un “package SEO”. C’est le modèle de rendu d’Astro.

« Par défaut, Astro rend automatiquement chaque composant UI en HTML & CSS uniquement, en supprimant automatiquement tout le JavaScript côté client. »

C’est la description d’Astro dans sa documentation sur l’architecture Islands. Astro hydrate uniquement les composants explicitement marqués pour s’exécuter dans le navigateur, et laisse le reste de la page en HTML statique.

Cette distinction compte parce que Google ne traite pas le fait de télécharger du JavaScript et de l’exécuter comme la même opération.

« Google traite les applications web en JavaScript en trois phases principales : 1. Crawl 2. Rendering 3. Indexing »

Google Search Central explique en plus qu’un Chromium “headless” rend la page une fois que les ressources de Google le permettent. Google peut rendre du JavaScript, mais le contenu qui n’existe qu’après exécution dépend de cette phase supplémentaire. Le mode HTML statique par défaut d’Astro supprime cette dépendance : le contenu utile peut déjà être présent dans la réponse. Notre guide SEO dédié au JavaScript détaille le mécanisme plus en profondeur.

C’est un avantage technique réel. Ce n’est pas un avantage automatique en termes de classement. Du HTML statique ne peut pas sauver des pages “thin”, des titres dupliqués, des liaisons internes faibles, une canonicalisation accidentelle, ou du contenu dont personne n’a besoin.

Astro fournit une plomberie inhabituellement solide. Il reste à la connecter.

Définissez d’abord l’URL du site en production

Avant d’ajouter un composant SEO, configurez site dans astro.config.mjs :

Définissez-le une seule fois dans votre configuration Astro pour que les canonicals et le sitemap pointent vers de vraies URL :

// astro.config.mjs
import { defineConfig } from 'astro/config';
import sitemap from '@astrojs/sitemap';

export default defineConfig({
  site: 'https://example.com',   // alimente les URLs canonicals et le sitemap
  integrations: [sitemap()],
});

La Configuration Reference d’Astro définit site comme l’URL finale déployée et précise qu’elle utilise cette valeur pour générer les URL de sitemap et les canonicals. Par défaut, c’est undefined, et Astro recommande fortement de le définir.

Une seule ligne pilote plusieurs systèmes :

• Astro.site reste indéfini sans cette configuration.
• @astrojs/sitemap en a besoin pour générer les URLs du sitemap.
• @astrojs/rss l’utilise pour créer les liens vers les articles.
• Les URLs canonical et des images sociales en ont besoin pour une origine de production fiable.

Nous avons vu l’image miroir de cette dépendance pendant notre migration de seojuice.io vers seojuice.com en janvier 2026. Les canonicals, les entrées de sitemap, les URL Open Graph et les références internes devaient converger vers une seule origine de production. Une migration rend le problème évident ; une valeur site oubliée masque la même classe d’erreur au sein d’un build par ailleurs “réussi”.

Définissez l’URL de production, construisez et inspectez le résultat avant de déboguer les intégrations en aval (une origine, plusieurs symptômes).

Construisez un seul composant head, pas des dizaines de variantes

Astro ne fournit pas d’abstraction “spéciale” pour les métadonnées. Les titres et descriptions sont de simples balises HTML. Pour la plupart des sites, la bonne approche maintenable est une mise en page partagée qui accepte des valeurs spécifiques de page via Astro.props.

Les première et troisième lignes sont des clôtures (frontmatter fences) d’Astro. Chaque page, ou chaque entrée de contenu, doit fournir son propre titre et sa propre description. Avoir une valeur de repli peut aider à détecter des données incomplètes, mais ne laissez pas une valeur par défaut au niveau du site devenir silencieusement les métadonnées de chaque URL.

Je préfère valider les métadonnées obligatoires pendant le build plutôt que de découvrir des omissions des semaines plus tard dans Search Console. Si une page publique n’a ni titre ni description, faire échouer le build est souvent le comportement le plus “aimable”.

Faut-il utiliser le package astro-seo ?

Le package communautaire astro-seo peut encapsuler les balises courantes. Installez-le avec npm install astro-seo, importez SEO depuis le package, puis rendez le composant à l’intérieur de la balise head du document. Son dépôt liste la prise en charge de titres, descriptions, canonicals, directives robots, Open Graph, cartes Twitter, modèles de titres, alternates de langue et balises personnalisées.

Soyez précis sur ce que c’est : astro-seo est un composant tiers maintenu par jonasmerlin, et non une intégration officielle @astrojs. Je l’utiliserais seulement si son API supprime une répétition réellement pénible. Pour un petit site marketing, un composant head local est souvent plus simple à auditer et plus difficile à “dépasser” (moins de dépendances peut être un avantage, pas une préférence esthétique).

Garder les métadonnées sociales à côté des métadonnées de recherche

Open Graph et les cartes Twitter sont des balises meta standard. Générez-les dans le même composant head partagé afin que le titre de la page, la description, l’URL canonical et l’image ne dérivent pas de manière indépendante. Les images sociales doivent utiliser des URL absolues basées sur Astro.site : des chemins relatifs sont une cause fréquente du fait qu’un aperçu fonctionne sur un service et échoue sur un autre.

Générer les canonicals à partir de l’origine de production et du chemin actuel

Astro expose les deux valeurs nécessaires pour une canonical. Astro.site renvoie une URL basée sur le site de production configuré, tandis que Astro.url représente l’URL de la requête courante.

Le Reference API officielle donne ce modèle :

Ce modèle combine le chemin courant avec l’origine de production, ce qui évite qu’un hostname de développement ou d’aperçu devienne canonical juste parce qu’il a servi la requête (les hôtes d’aperçu ne devraient pas “voter”).

Notez que le modèle utilise Astro.url.pathname, et non l’URL complète de la requête. Il supprime donc les paramètres de requête. C’est généralement correct pour les paramètres de tracking et les pages de contenu “ordinaires”, mais pas universellement. La pagination, les collections filtrées et les pages vraiment distinctes paramétrées exigent une politique canonical explicite.

Une canonical n’est pas un marqueur générique “SEO activé”. C’est une déclaration sur l’URL qui représente la version faisant autorité d’une page. Vérifiez la valeur finale.

Faire des slash de fin un choix délibéré

L’option trailingSlash d’Astro a pour défaut ignore. Les réglages always et never imposent une forme pour les routes en rendu à la demande de production, tandis que le défaut accepte les deux formes en développement et en rendu à la demande.

Pour la sortie statique, le comportement des fichiers générés et du host influence aussi le résultat. Choisissez une forme canonique, générez les liens internes dans cette forme et testez comment le host déployé gère les deux variantes. Modifier uniquement le paramètre Astro ne garantit pas que chaque host statique applique les redirections que vous attendez.

L’objectif, c’est l’alignement : les liens internes, les canonicals, les entrées de sitemap et les redirections doivent tous pointer vers la même forme d’URL. Notre guide SEO pour développeurs couvre la discipline d’implémentation plus large derrière cette décision.

Installer l’intégration sitemap officielle

Lancez npx astro add sitemap pour installer l’intégration officielle @astrojs/sitemap d’Astro.

D’après la documentation officielle sur les sitemaps, l’intégration a besoin de l’URL du site déployé, en commençant par http:// ou https://. Sans site, elle ne génère pas de sitemap.

Après un build, Astro ajoute sitemap-index.xml et sitemap-0.xml au répertoire de sortie. L’index référence les fichiers sitemap numérotés. La limite par défaut est de 45 000 entrées par fichier ; au-delà, davantage de fichiers numérotés sont créés (45 000 est un seuil de découpage, pas une recommandation pour “fabriquer” des pages).

Inspectez plusieurs entrées après le déploiement. Vérifiez le protocole, le hostname, les chemins, la convention des slash et la présence éventuelle de pages privées ou utilitaires. Ouvrez aussi l’index du sitemap et suivez ses liens enfants. J’ai déjà vu des fichiers sitemap techniquement valides déployés sur des chemins testés par personne.

Un sitemap aide à la découverte ; il ne force pas l’indexation. Pour la suite du processus, voir comment fonctionne l’indexation Google.

Le piège “Astro island” est spécifiquement client:only

Les islands d’Astro ne sont pas mauvais pour le SEO par nature. Dire l’inverse mélange une hydratation sélective avec du rendu “client-only”.

La référence des directives d’Astro précise que client:only “ignore le rendu HTML côté serveur et ne rend que dans le client”. Tout ce qui est dans ce composant est absent du HTML rendu initialement côté serveur et dépend de l’exécution de JavaScript.

Ne mettez pas le corps d’un article, des descriptions produit, des réponses FAQ, la navigation principale, des liens internes ou tout autre contenu indexable à l’intérieur de client:only. Réservez-le aux interfaces qui ne peuvent pas se rendre côté serveur et dont le contenu ne doit pas apparaître dans la réponse initiale.

client:load, client:idle et client:visible sont différents. Ils rendent d’abord le HTML initial côté serveur, puis contrôlent le moment où l’hydratation a lieu. Le problème n’est pas React, Vue, Svelte ou les islands en elles-mêmes. Le problème, c’est de sauter le rendu serveur ou de charger le texte essentiel uniquement dans le navigateur.

D’après ce que nous observons sur les sites testés avec SEOJuice, l’échec révélateur sur les builds basés sur frameworks JavaScript n’est souvent pas un sitemap manquant. C’est plutôt une page qui semble complète dans le navigateur, alors que le corps de texte réellement utile manque dans la réponse HTML brute. Dans Astro, une seule frontière client:only est un premier endroit évident à inspecter, même si le chargement de données “browser-only” peut produire le même résultat.

J’ai déjà fait cette erreur en ne consultant que la page rendue. Plus précisément, j’ai examiné ce que le navigateur a reconstruit, pas ce que le serveur a renvoyé. Regarder la source de la réponse aurait mis fin à l’enquête bien plus tôt. C’est exactement le même échec “app-shell” discuté dans nos meilleures pratiques SEO pour les applications monopages (SPA).

Utilisez la sortie statique sauf si le rendu à la demande résout un problème réel

« Par défaut, tout votre site Astro sera pré-généré, et des pages HTML statiques seront envoyées au navigateur. »

Cela vient du guide de rendu à la demande d’Astro. Le mode par défaut output: 'static' génère les pages au moment du build. C’est le choix évident pour la documentation, les articles, les landing pages et le contenu produit qui ne dépend pas de données spécifiques à la requête.

output: 'server' rend les pages à la demande et nécessite un adapter pour l’environnement cible, comme Node, Netlify, Vercel ou Cloudflare. Le rendu côté serveur peut renvoyer un HTML complet et n’est pas intrinsèquement plus mauvais pour le SEO. Il ajoute simplement de l’infrastructure d’exécution, de la latence et une surface d’échec supplémentaire. Utilisez-le parce que la page en a besoin, pas parce que le SSR semble plus “capable”.

Vous pouvez mélanger les deux comportements. En mode statique, exportez prerender = false pour une page qui doit être rendue à la demande. En mode serveur, exportez prerender = true pour une page qui doit être générée à l’avance.

De vieux tutoriels recommandent peut-être output: 'hybrid'. Astro 5 a “replié” l’ancien comportement hybride dans 'static'. Le guide de mise à niveau vers Astro 5 décrit 'hybrid' et 'static' comme fusionnés dans une seule configuration statique. Les projets actuels devraient utiliser static ou server avec des surcharges prerender au niveau des pages.

Ajoutez un flux RSS si le site publie un contenu récurrent

Astro fournit le package officiel @astrojs/rss pour générer des flux via des endpoints API. Installez-le avec npm install @astrojs/rss, puis créez un endpoint du type src/pages/rss.xml.js qui renvoie l’assistant RSS avec site: context.site et les éléments du flux.

La documentation Astro RSS exige un site configuré, car cette origine sert à générer les liens vers les articles. C’est encore une raison de traiter site comme une configuration fondamentale plutôt que comme une option spécifique au sitemap.

Inspectez le site généré, pas seulement les composants source

Les composants d’Astro peuvent avoir l’air corrects alors que la sortie déployée est fausse. Construisez et déployez, puis vérifiez :

1. La réponse HTML brute contient le contenu principal et les liens importants.
2. Chaque page indexable a un titre et une meta description adaptés.
3. La canonical est absolue, utilise HTTPS et pointe vers le hostname de production.
4. Les canonicals, les liens internes, les redirections et les URLs du sitemap partagent la même convention de slash.
5. Les images Open Graph et Twitter utilisent des URLs absolues de production.
6. sitemap-index.xml existe et référence des sitemaps enfants accessibles.
7. Aucun contenu indexable n’existe uniquement à l’intérieur des composants client:only.
8. Les pages prévues pour être statiques apparaissent bien dans le build généré.
9. Les hôtes d’aperçu et de staging ne s’annoncent pas eux-mêmes comme canonicals.
10. Les redirections se comportent comme attendu sur la plateforme d’hébergement réelle.

Utilisez “view source”, récupérez l’URL sans dépendre de l’exécution dans le navigateur, puis inspectez les fichiers déployés. Le panneau Elements des DevTools affiche le DOM après exécution : c’est utile, mais ça répond à une question différente (je me surprends encore à vérifier la mauvaise en premier).

Astro gère bien la base du rendu. Le travail récurrent, c’est de maintenir les métadonnées, les liens internes, le schéma (schema) et la cohérence des pages à mesure que le site grandit. SEOJuice peut tourner sur Astro via un snippet JavaScript et appliquer en continu des correctifs sur le site, comme les liens internes, les titres et descriptions meta, le balisage schema et le texte alternatif des images. Le audit SEO gratuit est aussi un moyen sans inscription d’inspecter les métadonnées et canonicals effectivement livrés.

Ce n’est pas un substitut à la définition de site, à la génération d’un sitemap, ni au fait de garder le contenu indexable dans le HTML initial. L’automatisation doit s’ajouter par-dessus un build correct.

Questions fréquentes

Astro est-il bon pour le SEO ?

Oui. Astro pré-génère du HTML statique et supprime par défaut le JavaScript côté client, ce qui permet d’avoir le contenu présent dans la réponse initiale au lieu de dépendre de la phase de rendu différé du JavaScript de Google. Le classement dépend toujours du contenu utile, des métadonnées, du maillage interne, des canonicals et des autres choix d’implémentation.

Comment ajouter des titres et descriptions meta dans Astro ?

Ajoutez des balises standards title et meta-description dans un layout partagé, puis passez des valeurs uniques via Astro.props pour chaque page. Le package communautaire astro-seo est une autre option, mais ce n’est pas une intégration officielle d’Astro.

Comment ajouter un sitemap à un site Astro ?

Lancez npx astro add sitemap et définissez site sur l’URL déployée dans astro.config.mjs. Ensuite, un build émet sitemap-index.xml et sitemap-0.xml. Sans configuration du site, l’intégration ne peut pas générer le sitemap.

Comment définir des URL canonicals dans Astro ?

Utilisez le modèle documenté par Astro : créez une URL avec new URL(Astro.url.pathname, Astro.site), puis affichez cette valeur dans une balise de lien canonical. Définissez d’abord site, car Astro.site est sinon indéfini.

Quelle est la différence entre la sortie statique et la sortie SSR dans Astro ?

output: 'static' est le défaut et pré-génère les pages en HTML au moment du build. output: 'server' rend à la demande et nécessite un adapter. Vous pouvez mélanger le comportement par page avec prerender = false en mode statique ou prerender = true en mode serveur.

Pourquoi mon sitemap Astro ou ma canonical URL ne fonctionne pas ?

Vérifiez d’abord site. Il est indéfini par défaut, alors que la génération du sitemap, Astro.site, la construction des canonicals, les liens RSS vers les articles et de nombreuses URL sociales absolues en dépendent. Définissez-le sur l’origine HTTPS finale, reconstruisez, puis inspectez la sortie générée.