SEO Astro : comment positionner un site Astro sur Google et le faire citer par les IA

Quiz rapide

Le SEO est-il fait pour vous, et comment commencer ?

Question 1 sur 425%

Les gens cherchent-ils sur Google ce que vous vendez ?

Oui, je penseNon, c'est nouveau ou très spécialiséJe ne sais pas

Le SEO Astro consiste à transformer ce HTML propre en pages qui se positionnent. Le guide de Google sur les bases du SEO JavaScript explique que le moteur traite les sites JavaScript en trois phases (exploration, rendu, indexation) et affirme que le rendu côté serveur ou le prérendu reste une très bonne idée, car tous les robots ne savent pas exécuter JavaScript. Astro part de cette position par défaut. Ce guide couvre le reste, réglage par réglage, chaque comportement étant vérifié dans la documentation officielle d'Astro. Pour la petite histoire, le site sorank.com que vous lisez tourne sur Astro.

Astro est-il bon pour le SEO ?

Oui, sur le plan technique. Astro rend les composants en HTML au moment de la compilation et retire le JavaScript que des frameworks comme React ou Vue enverraient normalement au navigateur. Il évite ainsi les problèmes classiques décrits dans notre guide du SEO JavaScript : coquilles HTML vides, contenu qui n'apparaît qu'après le rendu, liens qui ne sont pas de vraies balises d'ancre. Il évite aussi les pièges de routage d'une application monopage, puisque chaque route Astro est une vraie URL avec son propre fichier HTML.

Ce qu'Astro ne fait pas compte tout autant. Il n'y a ni extension SEO intégrée, ni méta-description automatique, ni balise canonique automatique, ni données structurées. Le tableau ci-dessous sépare ce que vous obtenez gratuitement de ce que vous devez construire.

Rendu statique ou serveur : quel mode choisir pour le SEO ?

La documentation d'Astro sur le rendu à la demande est claire : par défaut, les pages, les routes et les points d'accès d'API sont prérendus au moment de la compilation sous forme de pages statiques. Pour le SEO, la sortie statique est le choix le plus sûr : chaque URL est un fichier HTML terminé, servi depuis un réseau de diffusion, rapide et identique pour chaque visiteur et chaque robot.

Le rendu à la demande (côté serveur) demande un adaptateur pour votre hébergeur (Node, Netlify, Vercel ou Cloudflare, par exemple). Vous sortez alors une route du prérendu avec export const prerender = false, ou vous basculez tout le projet avec output: 'server' et vous réactivez le statique page par page. Les deux modes produisent un HTML complet, donc Google voit la même chose. Les différences se situent ailleurs :

• Vitesse : un fichier statique est servi immédiatement ; une page rendue par le serveur dépend du temps de réponse de celui-ci, qui pèse sur le Largest Contentful Paint.
• Fraîcheur : le rendu serveur convient aux pages qui changent sans cesse (stock, prix, résultats de recherche), pour lesquelles recompiler le site serait trop lent.
• Outils : certaines intégrations, comme le sitemap, ne voient pas les routes dynamiques rendues par le serveur (voir plus bas).

La règle à retenir : gardez en statique les pages commerciales, les articles de blog et la documentation, et ne rendez à la demande que les routes qui ont besoin de données en direct. La documentation d'Astro fait la même recommandation et conseille de garder le mode statique par défaut tant que la plupart des pages n'exigent pas un rendu à la demande.

Comment configurer les balises méta et les URL canoniques dans Astro ?

Créez un seul composant SEO (souvent appelé BaseHead ou Seo) et incluez-le dans le head de chaque mise en page. Il reçoit un titre, une description, une image facultative et un indicateur noindex facultatif, et produit :

1. la balise title, unique par page, avec le mot-clé principal près du début ;
2. la méta-description, écrite à la main pour chaque page (c'est votre extrait dans les résultats) ;
3. la balise canonique, construite en URL absolue à partir d'Astro.url.pathname et de la valeur site de votre configuration ;
4. les balises Open Graph et sociales (titre, description, image, URL) pour les aperçus de liens ;
5. une balise meta robots quand une page doit rester hors de l'index.

Renseignez d'abord l'option site dans astro.config.mjs : la canonique, le sitemap et les balises sociales en dépendent. Choisissez ensuite une règle trailingSlash ('always' ou 'never') et tenez-vous-y, pour que /blog/article et /blog/article/ ne se concurrencent jamais comme deux versions de la même page. Retirez les paramètres d'URL de la canonique pour que les paramètres de suivi ne créent pas de doublons.

Comment générer un sitemap et un robots.txt avec Astro ?

Utilisez l'intégration officielle documentée sur la page @astrojs/sitemap. La commande npx astro add sitemap l'installe et l'ajoute à votre configuration. Elle exige l'option site et, à la compilation, écrit un fichier sitemap-index.xml qui renvoie vers des fichiers numérotés (sitemap-0.xml, puis d'autres sur les gros sites). Chaque fichier contient jusqu'à 45'000 entrées par défaut, valeur réglée par l'option entryLimit. Si le format vous est nouveau, notre fiche de glossaire sur le sitemap XML explique comment Google l'utilise.

Trois réglages comptent pour le SEO :

• filter : une fonction qui reçoit l'URL de chaque page ; renvoyez false pour les pages de remerciement, la recherche interne, les brouillons ou tout ce qui porte un noindex, afin que le sitemap ne liste que des URL indexables.
• i18n : associe vos dossiers de langue à des codes de langue et ajoute les alternatives hreflang à chaque entrée.
• customPages : ajoute les URL que l'intégration ne peut pas découvrir seule.

Pour le robots.txt, un fichier statique dans le dossier public suffit sur la plupart des sites. Si son contenu diffère entre préproduction et production, générez-le plutôt depuis un point d'accès (src/pages/robots.txt.ts). Dans les deux cas, ajoutez une ligne Sitemap qui pointe vers sitemap-index.xml, et testez le résultat avec un vérificateur de robots.txt avant la mise en ligne. La même technique produit un fichier llms.txt ; notre guide pour installer un fichier llms.txt détaille son contenu.

Comment gérer le hreflang et un site multilingue dans Astro ?

Le routage i18n intégré d'Astro gère la partie URL. Dans la configuration, vous déclarez une defaultLocale et une liste de locales, et vous choisissez si la langue par défaut reçoit aussi un préfixe (prefixDefaultLocale). Des fonctions comme getRelativeLocaleUrl construisent les liens localisés, et Astro.currentLocale indique à chaque page sa langue.

Le guide de routage ne traite pas des balises hreflang dans le head : prévoyez de les écrire vous-même dans le composant SEO. Pour chaque page, un lien alternatif par version linguistique, plus un x-default, tous en URL absolues, et chaque version doit lister toutes les autres (liens de retour). Les générer à partir de la même liste de langues que le routage évite l'erreur la plus courante, une alternative qui pointe vers une page inexistante. Pour vérifier la logique sur quelques URL, notre générateur de balises hreflang produit le jeu complet de balises d'une page. Activez ensuite l'option i18n du sitemap comme second signal.

Quel est l'effet des images et des îlots sur la vitesse et les Core Web Vitals ?

La vitesse est le domaine où Astro gagne le plus de terrain, et cela se voit dans les Core Web Vitals. Le guide des images d'Astro décrit le composant Image d'astro:assets : il optimise les images locales, convertit leur format, ajoute le chargement différé et le décodage asynchrone, et déduit les dimensions de l'image pour éviter le décalage de mise en page (CLS). L'attribut alt y est obligatoire, ce qui impose une règle de base du SEO des images. Le composant Picture va plus loin et sert de l'AVIF ou du WebP avec une image de repli.

Deux habitudes complètent le tableau. Gardez dans src les images à optimiser (les fichiers du dossier public sont servis tels quels, sans traitement). Et ne différez pas le chargement de l'image principale en haut de page : chargez-la immédiatement pour qu'elle ne retarde pas le Largest Contentful Paint.

L'architecture en îlots tient le JavaScript sous contrôle. Un composant reste du HTML statique tant que vous n'ajoutez pas de directive client : client:load l'hydrate tout de suite, client:idle quand le navigateur est libre, client:visible seulement quand il entre dans la zone visible. Réserver client:load à ce qui doit réagir immédiatement (un menu, un panier) est le moyen le plus simple de protéger l'Interaction to Next Paint. Les îlots serveur (server:defer) chargent un bloc personnalisé après la page mise en cache, sans ralentir le contenu principal.

Comment ajouter des données structurées à un site Astro ?

Astro n'a pas de fonction dédiée aux schémas, ce qui vous laisse un contrôle total. Construisez un objet JavaScript par type de page (Article, Product, Organization, BreadcrumbList, FAQPage) et placez-le dans une balise script de type application/ld+json, avec la directive set:html et JSON.stringify pour que le JSON ne soit pas échappé. Alimentez-le avec les mêmes données de frontmatter ou de collection que la page visible : le balisage correspond alors toujours à ce que voient les utilisateurs, une exigence des consignes de Google sur le balisage schema.

Pour rédiger le JSON d'un nouveau type de page, notre générateur de schema gratuit fournit un bloc valide de départ, que vous transformez ensuite en modèle. Validez un échantillon de pages compilées avec le test des résultats enrichis de Google après chaque modification du modèle.

Comment gérer les redirections lors d'une migration vers Astro ?

La migration depuis WordPress ou Next.js est le moment le plus risqué pour un site Astro. Conservez chaque URL qui reçoit du trafic ou des backlinks, et associez les autres une par une à leur équivalent le plus proche avec des redirections permanentes, comme l'explique notre guide des redirections SEO.

La configuration d'Astro accepte un objet redirects qui associe les anciens chemins aux nouveaux. Avec un adaptateur, ils deviennent de vraies redirections HTTP. Sur une compilation purement statique, Astro écrit à la place une page HTML avec une balise meta refresh, que Google suit mais traite comme un signal plus faible qu'une 301 côté serveur. Pour un site statique, déclarez les redirections dans le format de votre hébergeur (un fichier _redirects sur Netlify ou Cloudflare Pages, un fichier vercel.json sur Vercel) afin que les robots reçoivent une vraie 301.

Comment Astro aide-t-il le SEO et le GEO ?

Être cité par ChatGPT, Perplexity ou Gemini commence par être lisible. Beaucoup de robots d'IA récupèrent le HTML brut sans exécuter JavaScript : un site qui livre tout son texte dès la première réponse, comme Astro par défaut, lève un obstacle que les sites rendus côté client gardent encore. Des intertitres propres, des paragraphes qui répondent d'emblée, des données structurées et un fichier llms.txt rendent ensuite chaque page plus facile à citer.

Après la mise en ligne, mesurez au lieu de deviner. Le tableau de bord GEO et SEO de Sorank réunit vos données Search Console et vos visites venues des assistants IA, pour vérifier que le nouveau site garde ses positions.

La qualité technique ne rapporte qu'avec du contenu à positionner. Le générateur d'articles de blog IA de Sorank écrit et publie des articles optimisés pour Google et pour les IA, et se connecte à un site sur mesure, comme un projet Astro, par webhook.

Astro vous donne par défaut un HTML rapide et explorable ; le positionnement dépend toujours des balises head, du sitemap, du hreflang, des données structurées et des redirections que vous ajoutez. Mettez en place le composant SEO partagé et le sitemap en premier, puis reprenez le tableau ci-dessus avant la mise en ligne.