Astro et le SEO : ce que le framework fait seul, et ce qui reste à faire.

« Astro, c’est bon pour le SEO ? » La réponse courte est oui. La réponse utile est plus longue : Astro règle très bien une partie du travail, et ne touche pas du tout au reste.

Ce qu’Astro fait pour vous, sans rien installer#

Il sert une page déjà prête. Un site Astro est construit à l’avance : quand Googlebot arrive, le texte, les titres et les liens sont dans le HTML. Google traite le JavaScript en trois temps, exploration, affichage puis indexation, et une page qui attend son affichage « peut rester dans cette file d’attente pendant quelques secondes ou pendant plus de temps ». Avec Astro, le contenu est lisible dès la première phase.

C’est ce que la documentation de Google sur le JavaScript conseille en toutes lettres : « l’affichage côté serveur ou le pré-affichage reste recommandé, car il permet aux utilisateurs et aux robots d’exploration d’accéder à votre site plus rapidement ».

Il n’envoie pas de JavaScript par défaut. Une page sans script s’affiche et réagit vite, ce que mesurent les Core Web Vitals. Le JavaScript n’arrive que là où vous le demandez, composant par composant.

Il stabilise les images. Le composant d’image d’Astro inscrit les dimensions de chaque image et la convertit dans un format léger. La page ne saute pas pendant le chargement, ce qui règle l’essentiel du CLS.

Score SEO Lighthouse médian : 100 pour les sites Astro, 92 pour les sites WordPress.

HTTP Archive Tech Report, septembre 2026, mobile.

Ce chiffre, tiré du HTTP Archive Tech Report, dit que les bases techniques sont en place. Il ne dit rien de plus, et c’est l’objet de la suite.

Ce qu’il faut ajouter, et qui ne vient pas tout seul#

Astro ne fournit ni gestionnaire de balises, ni sitemap, ni données structurées. Tout cela s’ajoute une fois, au bon endroit. Un paquet communautaire, astro-seo, regroupe les balises courantes dans un composant : pratique, mais il ne fait rien de plus qu’un gabarit bien écrit.

Ces points viennent de la documentation d’Astro : le routage multilingue, disponible depuis la version 3.5, construit les adresses mais pas les balises hreflang, et l’intégration de sitemap ne couvre pas les pages générées à la demande côté serveur.

Ce qu’on a réglé sur astro4b.com#

Ce site tourne sous Astro. Voici ce qu’on a ajouté au framework, et pourquoi.

Un seul gabarit pour toutes les balises. Title, description, canonique, hreflang français, anglais et x-default, Open Graph et Twitter sont écrits une fois. Chaque page lui passe ses valeurs. Une page oubliée est impossible : elle hérite du gabarit.

---
const { title, description, path, frPath, enPath } = Astro.props;
const url = (p) => new URL(p, Astro.site).href;
---
<title>{title}</title>
<meta name="description" content={description} />
<link rel="canonical" href={url(path)} />
<link rel="alternate" hreflang="fr" href={url(frPath)} />
<link rel="alternate" hreflang="en" href={url(enPath)} />
<link rel="alternate" hreflang="x-default" href={url(frPath)} />

Des sitemaps construits par le site lui-même. Deux routes génèrent un sitemap par langue et un index qui les regroupe. Chaque article y déclare l’adresse de sa traduction, ce qui répète dans le sitemap l’information des balises hreflang.

Des champs SEO vérifiés avant la mise en ligne. Le schéma des articles limite la description à 160 caractères et le titre SEO à 65. Un dépassement fait échouer la construction du site. C’est arrivé en réécrivant notre article sur les Core Web Vitals : une description et un titre trop longs, bloqués avant d’atteindre Google.

Des données structurées reliées entre elles. Chaque article déclare son auteur par un identifiant unique, le même en français et en anglais, qui renvoie vers sa page. L’organisation, le site, le fil d’Ariane et les FAQ suivent le même principe.

Une image de partage par article, générée pendant la construction à partir du titre et du chiffre clé de l’article.

Une page 404 hors index. Elle ne déclare ni canonique ni hreflang. On l’a corrigé en octobre : la canonique pointait vers une adresse qui n’existait pas.

Les pièges propres à Astro#

Le slash final. Par défaut, Astro accepte les deux formes d’adresse. Mais sur Cloudflare Pages, un lien vers /configurateur est redirigé vers /configurateur/ avec une redirection 308. Chaque clic interne passait donc par une redirection : on a corrigé 92 liens dans 29 fichiers. Forcer l’option trailingSlash aurait été plus simple, mais chez nous elle faisait échouer en développement les sitemaps et les images de partage. On écrit donc chaque lien avec son slash.

Les composants interactifs qui rapportent du JavaScript. Astro n’envoie pas de script par défaut, mais chaque composant marqué pour s’exécuter dans le navigateur en ajoute. Un carrousel ou un widget chargé dès l’ouverture de la page suffit à perdre l’avantage sur les Core Web Vitals.

Le contenu chargé après coup. Un texte récupéré par un composant interactif une fois la page ouverte n’est pas dans le HTML de départ. Il dépend du rendu JavaScript de Google, et de son délai.

Le multilingue sans hreflang. Le routage d’Astro donne de belles adresses /en/… et laisse croire que le travail est fait. Sans balises hreflang, Google voit deux pages proches sans savoir qu’elles se traduisent.

Ce qu’aucun framework ne fera#

Le choix des requêtes, la réponse à l’intention de recherche, la qualité du contenu, le maillage entre vos pages et les liens que d’autres sites vous font. C’est là que se joue l’essentiel du classement, et Astro n’y touche pas plus que WordPress.

C’est aussi pourquoi comparer Astro et WordPress sur le seul SEO technique ne suffit pas à choisir. Astro retire des obstacles. Il ne remplace pas le travail éditorial.

Questions fréquentes#

Vous avez un site qui ne décolle pas malgré un bon contenu ? Le socle technique est peut-être en cause. Le configurateur vous donne le prix d’un site Astro réglé de cette façon, et si vous partez de WordPress, la refonte WordPress reprend vos contenus et vos redirections.