Sites statiques et Astro 7 min
Site statique avec Astro : pourquoi migrer, et sans perdre son SEO
Un site statique est un site dont les pages sont fabriquées à l'avance, au moment de la publication, puis servies telles quelles par un réseau de diffusion : aucune base de données ni code exécuté à chaque visite. Avec un générateur comme Astro, il remplace un WordPress ou un Drupal en fin de vie en gardant les mêmes adresses et le même contenu, et il supprime l'essentiel de la maintenance.
Ce qu’un site statique veut dire en 2026
Un site sous WordPress, Drupal ou Joomla fabrique chaque page au moment où un visiteur la demande : le serveur exécute du PHP, interroge une base de données, assemble le gabarit, puis envoie le résultat. Ce mécanisme a un coût à chaque visite, une surface d’attaque permanente, et une dette de mises à jour que quelqu’un doit payer chaque mois.
Un site statique inverse l’ordre : les pages sont fabriquées une fois, au moment de la publication, et le résultat est un dossier de fichiers HTML, CSS et images. Ce dossier est copié sur un réseau de diffusion (CDN) qui le sert tel quel, depuis le point le plus proche du visiteur. Rien ne s’exécute côté serveur, parce qu’il n’y a plus de serveur applicatif.
Le terme prête à confusion : « statique » ne veut pas dire figé ni sans interactions. Un formulaire, une recherche interne, un calculateur ou un espace client restent possibles. Ils sont branchés sur des services dédiés, page par page, au lieu d’imposer une application complète à tout le site.
Ce que ça change, mesuré plutôt que promis
La vitesse. Google fixe trois seuils pour ses Core Web Vitals : un affichage du contenu principal en moins de 2,5 secondes, une réaction aux interactions sous 200 millisecondes, et une stabilité visuelle inférieure à 0,1 (web.dev, seuils officiels). Un site statique bien construit les atteint sans effort exotique, parce qu’il n’envoie ni JavaScript inutile ni page assemblée à la volée. Sur la page d’accueil du site que vous lisez, construit avec Astro, la mesure Lighthouse 12 du 3 septembre 2026 en mobile simulé donne 0 milliseconde de blocage du fil principal et 322 Ko chargés au total. À l’autre bout de notre portefeuille, notre boutique en ligne sur Shopify, mesurée avant sa refonte, affichait un score mobile de 65, un contenu principal affiché à 8,4 secondes et une page de 4,2 Mo. La différence ne vient pas du talent des équipes : elle vient de ce que le navigateur reçoit.
La sécurité. Drupal 7 est en fin de vie depuis le 5 janvier 2025 (drupal.org) : plus aucun correctif de sécurité, sur un système que plus personne ne corrige. Un site statique n’a ni base de données à protéger, ni panneau d’administration exposé, ni extension à patcher. Ce qui reste à sécuriser est la chaîne de publication, qui vit dans un dépôt Git avec des accès nominatifs.
Le coût de possession. Un site statique coûte son hébergement, souvent quelques euros par mois, et zéro licence. Les heures de maintenance mensuelle (mises à jour du cœur, des extensions, du thème, sauvegardes de la base, redémarrages) disparaissent avec le serveur applicatif. Ce qui subsiste, c’est le travail éditorial, celui que vous voulez payer.
La disponibilité. Un dossier de fichiers se sert depuis n’importe quel hébergeur, y compris celui que vous avez déjà, derrière votre CDN actuel. Pour une entreprise qui doit rester lisible depuis des réseaux qui bloquent les scripts tiers (la Chine continentale en est l’exemple courant), c’est décisif : polices auto-hébergées, aucun appel à Google, aucune dépendance qui ralentit ou casse l’affichage.
Astro, en cinq points techniques
Astro est un générateur de sites orienté contenu. Sa version courante est la 7 (dépôt npm, 3 septembre 2026). Ce site tourne sur Astro 5 et notre site immobilier sur Astro 7. Cinq choix techniques expliquent pourquoi nous l’avons retenu.
- Du HTML par défaut, du JavaScript sur demande. Astro rend les composants au moment de la construction et n’envoie aucun JavaScript au navigateur tant qu’un composant n’en réclame pas. C’est l’architecture en îlots : un formulaire ou une carte interactive embarque son propre code, chargé quand il devient visible. Le reste de la page est inerte et immédiat.
- Le contenu validé par un schéma. Les pages et articles sont déclarés dans des collections de contenu avec un schéma : un article sans titre, sans description ou sans date ne se construit pas. Ce qui se vérifiait à la main sur une check-list devient impossible à oublier.
- Une source de contenu au choix. Des fichiers Markdown dans le dépôt, un CMS headless comme Sanity, une base de données ou une API : Astro lit tout au moment de la construction. Le choix dépend de qui publie et à quelle fréquence, pas de l’outil.
- Statique ou serveur, page par page. Un site peut être entièrement statique, ou rendu à la demande là où le contenu change à chaque minute. Notre site immobilier utilise le rendu serveur parce que ses annonces changent chaque jour. Ce site est entièrement statique. Même outil, même code.
- Le socle SEO produit par le code. Routes par langue, hreflang réciproques, sitemap réel, données structurées par gabarit, images converties et redimensionnées à la construction : rien de tout cela ne dépend d’une extension à installer ni d’un réglage à ne pas oublier.
Le flux de travail : publier, c’est fusionner
La partie la moins visible d’une migration est celle qui décide de la suite. Avec un site statique dans un dépôt Git, chaque modification passe par un aperçu en ligne et par des contrôles automatiques avant la mise en ligne : liens morts, pages sans titre, sitemap, adresses. Une publication est une fusion. Un retour arrière est une commande. Personne n’a besoin d’un outil installé sur son ordinateur, et un article publié dans six mois suit exactement le même chemin qu’aujourd’hui.
C’est aussi ce qui rend un moteur de contenu possible : notre moteur SEO et GEO écrit ses brouillons directement dans le dépôt, et la relecture humaine est la revue de la modification avant fusion.
La migration, étape par étape
Le risque numéro un d’une migration n’est pas technique, il est dans les adresses. Toute URL perdue sans redirection est du trafic détruit, et un site de dix ans en a des centaines qui reçoivent encore des visites ou des liens. La méthode que nous appliquons tient en quatre étapes.
- L’inventaire. Crawl du site actuel, sitemap réellement servi, seize mois de Search Console, et la liste des pages à ne pas casser : celles qui reçoivent du trafic ou des liens entrants, avec leur poids. Le contrat d’adresses est écrit avant de construire une seule page.
- La construction. Le contenu est extrait et repris à l’identique, contrôlé page par page. Le design est conservé ou amélioré gabarit par gabarit. Les redirections sont posées sur une préproduction que vous visitez.
- La recette. Un diff de crawl compare l’ancien site et le nouveau, page par page : titres, descriptions, canoniques, liens internes, statuts HTTP. La matrice d’adresses doit être verte avant toute bascule.
- La bascule. Mise en ligne, redirections actives, surveillance pendant quatorze jours de la Search Console et des erreurs, l’ancien site prêt à revenir. La mesure avant et après dit ce que la migration a changé.
Nous exécutons cette méthode en ce moment pour une agence digitale d’une vingtaine de personnes basée à Shanghai : un site de 233 adresses sous Drupal 7, dix-sept ans d’historique, une contrainte d’accessibilité depuis la Chine, une migration vers Astro à adresses inchangées. La bascule est prévue à l’automne 2026. Les mesures seront publiées ici, avant et après, quand elles existeront.
Quand il ne faut pas migrer
Un site statique n’est pas la réponse à tout, et nous préférons le dire avant le devis.
- Une boutique en ligne transactionnelle (panier, stock, paiement, comptes clients) relève d’une plateforme e-commerce, pas d’un générateur de pages. Le catalogue peut être statique, la transaction non.
- Une application avec des utilisateurs connectés qui lisent et écrivent des données à chaque minute a besoin d’un rendu serveur ou d’une application. Astro sait le faire, mais ce n’est plus une migration statique.
- Une équipe de dix rédacteurs qui publient chaque jour a besoin d’un outil d’édition : c’est le cas du site headless avec Astro et Sanity, qui garde le statique côté visiteur et ajoute un CMS côté équipe.
Dans les trois cas, l’audit le dit avant que vous n’engagiez quoi que ce soit.
Ce que ça coûte
La migration vers un site statique avec Astro est une offre à périmètre fermé : à partir de 5 900 € hors TVA pour un site jusqu’à cent pages, quatre semaines, adresses conservées, recette par diff de crawl et bascule surveillée. Un site neuf, sans existant à reprendre, relève du site vitrine, à partir de 3 900 €. Dans les deux cas, ce qui reste ensuite, c’est l’hébergement et le contenu.
Questions fréquentes
Vais-je perdre mon référencement en migrant ? Pas si les adresses sont traitées avant de construire : inventaire, pages à ne pas casser, redirections posées avant la bascule, diff de crawl après. Une migration qui commence par le design et finit par les redirections est celle qui perd du trafic.
Puis-je encore modifier mon site moi-même ? Oui. Soit directement dans les fichiers, avec un aperçu automatique et une formation, soit dans un CMS headless si plusieurs personnes publient. Le choix se fait au cadrage, pas par défaut.
Un site statique peut-il avoir un formulaire, une recherche, un espace client ? Oui, chacun branché sur un service dédié : les formulaires de ce site enregistrent chaque demande en base avant d’envoyer l’email, la recherche interne d’un site de contenu se construit en index à la publication, et un espace client se rend côté serveur sur les seules pages qui en ont besoin.
Pourquoi Astro plutôt que Next.js ou un autre framework ? Parce qu’un site de contenu n’a pas besoin d’une application. Astro produit du HTML, n’envoie du JavaScript que là où un composant en a besoin, et lit le contenu de n’importe quelle source. Nous l’utilisons sur nos propres sites depuis 2025 : c’est un choix éprouvé en exploitation, pas une préférence de mode.