Vérifiez ce que livre votre site Astro, île par île.

Astro est-il bon pour le SEO ??

Oui, Astro peut vous aider à obtenir un site optimisé pour les moteurs de recherche : par défaut, il transforme les composants d’interface de votre site en HTML et CSS, puis retire le JavaScript côté client. Affichez le code source de votre page d’accueil. Et lisez la réponse brute (pas celle réinterprétée dans l’inspecteur). Vous devriez y voir votre titre et votre méta-description, mais aussi votre lien canonique et votre balise h1.

Un robot d’indexation récupère vos titres et vos contenus, puis suit vos liens, sans rendre la page. Astro publie sur sa propre page d’accueil un graphique selon lequel 71 % des sites Astro réels respectent les Core Web Vitals. Mais ce chiffre vient du fournisseur. Voyez-y un simple indicateur, pas un verdict définitif, et vérifiez vos pages avant de vous y fier les yeux fermés.

Astro n’écrit pas vos métadonnées, et votre fichier de configuration ne change rien au SEO. Les balises de titre et les balises méta, c’est vous qui les placez dans l’en-tête de la page (le plus souvent dans votre mise en page commune). Donc votre score dépend de vos modèles et de ce que vous y avez mis. L’évaluation parcourt vos pages. Elle vous indique clairement le pilier qui présente des lacunes.

Que changent les îles pour les robots et les Core Web Vitals ??

Avec les « islands », le robot d’indexation lit le HTML brut de chaque composant de vos pages. Seuls ceux auxquels vous ajoutez une directive « client: » chargent du JavaScript dans le navigateur de vos visiteurs. Et c’est là que se situe votre coût, pas ailleurs.

Cherchez dans vos modèles les attributs « client:load », « client:idle » et « client:visible ». Vos composants « client:idle » attendent que le navigateur soit inactif, ceux en « client:visible » attendent d’entrer dans la zone d’affichage. Mais avec « client:load » sur votre élément « hero », le script s’exécute dès le premier chargement (au détriment du reste). Votre page en a-t-elle vraiment besoin ? Souvent, la réponse est non.

Vérifiez ce que contient votre HTML. Votre texte et votre image principale doivent apparaître dans la source : web.dev recommande de charger l’image la plus volumineuse avec un élément `img` et les attributs `src` ou `srcset`, pas avec JavaScript. Les Core Web Vitals mesurent le chargement, l’interactivité et la stabilité visuelle ; chacun de vos choix pèse sur au moins l’un d’eux. L’évaluation prend en compte le poids des scripts envoyés par vos pages. Mais elle ne peut pas, en revanche, décrire l’expérience réelle de vos visiteurs. Web.dev précise que les mesures en laboratoire ne remplacent pas celles du terrain. Vérifiez donc vos données de terrain.

Comment les mises en page et les collections de contenu gèrent-elles les titres, les URL canoniques et le schéma ??

Votre mise en page commune gère ces trois éléments. Vous définissez une seule fois, dans l’en-tête, votre titre, vos balises méta, votre lien canonique et votre JSON-LD, et toutes les pages que vous créez en héritent. Donc une erreur à cet endroit ne reste jamais isolée (elle se répercute partout). Elle touche tout votre site.

Ouvrez votre fichier de mise en page et cherchez trois éléments : un titre et une description transmis comme propriétés, une balise canonique générée à partir des paramètres de votre site, un script JSON-LD. Pour les URL canoniques, renseignez l’URL de déploiement dans l’option « site » du fichier astro.config.mjs. Vous pouvez aussi définir « base » et « trailingSlash ». Mais sans l’option « site », vos URL canoniques n’ont aucune base pour être générées.

Vos collections couvrent l’autre moitié que vous contrôlez. Astro s’en sert pour organiser le contenu Markdown, le valider et en vérifier le type. Vous pouvez ainsi exiger une description ou une date dans votre schéma avant la compilation. Certains thèmes, comme Casper, indiquent que leurs collections sont validées avec Zod en plus de JSON-LD : vérifiez si c’est le cas pour le vôtre. L’évaluation vérifie la présence de données structurées dans votre HTML final. Elle ne vérifie pas le modèle qu’on vous a promis (une promesse ne produit pas de balisage).

Astro vs Next.js : lequel envoie le moins au navigateur ??

D’après les comparaisons disponibles, Astro envoie moins de JavaScript à vos pages que Next.js. Vercel précise par ailleurs que les deux outils fournissent du HTML généré côté serveur, ce qui permet aux moteurs de recherche d’indexer vos pages dans les deux cas. C’est généralement la première inquiétude des utilisateurs. Et avec Next.js, vos pages resteront visibles.

Le benchmark des sites de documentation publié par Tech Insider en septembre 2026 relève environ 12 Ko de JavaScript pour Astro, contre environ 187 Ko pour Next.js. Une vidéo de Devsplainers affiche respectivement 1,75 Ko et 168 Ko sur une page d'accueil. Et votre propre accueil accuse-t-il un écart comparable ? Kunal Ganglani chiffre le coût du routeur et de l'hydratation de Next.js entre 80 et 150 Ko sur un site marketing type : un bon ordre de grandeur pour situer vos pages. Les chiffres varient selon les sources et les sites. Mais aucun ne mesure le vôtre. Avant de vous fier à une moyenne, testez votre propre site : seul le résultat de votre build fait foi.

Vercel rappelle d'ailleurs que les meilleurs taux de réussite d'Astro aux Core Web Vitals, dans les données d'HTTP Archive, tiennent surtout aux profils de sites créés avec chaque framework. Cela ne dit toujours rien de votre build. Pour mesurer votre cas, suivez la méthode de LogRocket : lancez « astro build » puis servez vos fichiers avec « npx serve dist », ou compilez Next.js avec l'option « output: 'export' » et servez votre répertoire « out ». L'évaluation inspecte le code que vos pages servent vraiment en production, donc vous obtenez vos mesures réelles, pas celles d'un benchmark. Comparez votre version compilée à ce que vous mettez en ligne. Et l'écart entre les deux vous donne votre réponse.

Où les sites Astro perdent-ils généralement des points ??

Sur Astro, vos points se perdent presque toujours dans vos gabarits et votre contenu, rarement dans la mécanique de rendu. Le HTML sort déjà par défaut. Regardez donc d'abord les pages que vous avez rédigées, pas le framework : c'est là que votre site se joue.

Commencez par votre plan du site. L'intégration @astrojs/sitemap génère des entrées pour vos routes statiques, y compris celles issues de getStaticPaths(), mais elle ne sait pas en créer pour vos routes dynamiques en mode SSR. Vous servez des routes à la demande ? Ajoutez-les au plan par un autre moyen. Ouvrez ensuite vos pages traduites et contrôlez vos balises hreflang [c'est vite oublié]. Vos balises canoniques pointent-elles vers un hôte erroné ou vers une variante avec un slash final incorrect ?

Passez ensuite aux images dans votre balisage. Le composant « Image » d'Astro renseigne automatiquement la largeur et la hauteur, ce qui évite tout décalage cumulatif de mise en page (Cumulative Layout Shift). Une balise `img` écrite à la main ne garde que les attributs que vous lui avez donnés. Vos pages perdent des points quand votre balisage JSON-LD est incomplet ou absent, ou quand un titre se répète d'une page à l'autre. Même sanction pour un composant « client:load » qui n'a jamais eu besoin d'interactivité. Et l'évaluation détaille les preuves relevées pour chaque pilier : vous n'avez pas à deviner d'où viennent vos scores.

Comment vérifier un site Astro depuis l'extérieur ??

Pour tester votre site Astro de l'extérieur, regardez ce qu'il renvoie sur le réseau. Téléchargez vos pages, puis vérifiez vos en-têtes HTTP, votre balisage, vos données structurées, vos balises title, le poids de vos scripts et de vos images, ainsi que vos directives robots et canoniques. Lancez la commande « curl » sur votre page d'accueil. Titre, URL canonique, balise h1 et JSON-LD doivent tous figurer dans la première réponse. Sinon, aucun robot d'indexation ne les trouvera non plus, et le problème ne sera pas cosmétique.

Ouvrez ensuite votre fichier robots.txt et l'URL de votre plan du site. Répétez le contrôle sur quelques gabarits représentatifs, un article ou une fiche produit par exemple, puis sur votre page traduite. Un correctif de mise en page peut très bien fonctionner sur un modèle et échouer sur un autre. Donc ne validez pas seulement la page qui vous arrange.

L'évaluation gratuite s'en charge pour vous. Elle analyse votre page d'accueil et jusqu'à huit pages tirées au hasard, puis note votre site sur huit critères pondérés. Vous obtenez un score sur 100 en deux minutes environ. Indiquez votre adresse e-mail professionnelle : le lien vers votre rapport vous parvient une seule fois. La limite est de trois évaluations par heure et par connexion. L'outil ne se connecte pas à votre site et n'utilise ni vos statistiques ni vos données de terrain. Mais complétez-le par vos propres mesures sur le terrain.

Vos questions, nos réponses.

À lire ensuite.

1. 01Audit SEO Next.jsMode de rendu, métadonnées, coût d'hydratation.
2. 02Audit SEO de CMS headlessRendu, URL canoniques, aperçus, données structurées du modèle.
3. 03Test Core Web VitalsLCP, INP et CLS d'après ce que la page livre.