Migrer vers un site statique avec Astro sans perdre son SEO

Ce qu’un site statique veut dire en 2026

La différence tient au moment où chaque page est fabriquée. Un site statique inverse l’ordre :

La fabrication à la demande a un coût à chaque visite, une surface d’attaque permanente, et une dette de mises à jour que quelqu’un doit payer chaque mois.

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 officiels pour ses Core Web Vitals :

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 des sites que nous accompagnons, une boutique en ligne cliente 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 le portail immobilier que nous opérons pour un client sur Astro 7. Cinq choix techniques expliquent pourquoi nous l’avons retenu.

1. 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.
2. 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.
3. 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.
4. Statique ou serveur, page par page. Un site peut être entièrement statique, ou rendu à la demande là où le contenu change à chaque minute. Ce portail immobilier utilise le rendu serveur parce que ses annonces changent chaque jour. Ce site est entièrement statique. Même outil, même code.
5. 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 suit trois étapes :

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.

1. 01L’inventaire.

   Nous crawlons le site actuel, relevons le sitemap réellement servi et seize mois de Search Console, et dressons 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.

2. 02La 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.

3. 03La 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.

4. 04La bascule.

   Le nouveau site est mis en ligne, redirections actives. La Search Console et les erreurs sont surveillées pendant quatorze jours, et l’ancien site reste 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 : 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

Sources

1. Trois seuils officiels (nouvel onglet)web.dev
2. Drupal.org (nouvel onglet)drupal.org
3. Architecture en îlots (nouvel onglet)docs.astro.build