SSG et SEO : quel avantage ?

Le HTML est prêt dès la première requête : les moteurs reçoivent le contenu complet sans exécuter de JavaScript. Temps de réponse minimal, bon pour le crawl et les Core Web Vitals. Idéal pour les pages ciblées (PSEO, landing).

Comment mettre à jour le contenu d'un site SSG ?

Soit en relançant un build (déploiement), soit en utilisant l'ISR (Incremental Static Regeneration) : la page est régénérée en arrière-plan après un délai (ex. 1 h). Pour du contenu éditorial, un CMS headless déclenche souvent un rebuild ou une revalidation.

SSG vs WordPress : que choisir ?

WordPress génère les pages à la requête (ou via cache). Le SSG (Next.js, etc.) génère tout au build : plus rapide et plus sécurisé (pas de PHP en production). Le SSG convient si vous acceptez un workflow de publication via build/déploiement ; WordPress reste pratique pour une mise à jour très fréquente sans technique.

Qu'est-ce que SSG (Static Site Generation) ?

C'est comme préparer les plats à l'avance et les garder sous cloche : le HTML est déjà prêt sur le CDN quand le client commande. Le serveur ou le CDN envoie alors un fichier déjà prêt : temps de réponse minimal, charge serveur faible, idéal pour le référencement et la vitesse. Next.js, Gatsby, Astro proposent du SSG. Adapté aux sites à contenu stable (vitrine, blog, documentation) ; pour du contenu très dynamique (stock, prix en direct), on combine SSG avec revalidation (ISR) ou des zones dynamiques. Pour une vitrine ou un blog, voir création de site internet.

Comment ça marche ?

Lors du build, le framework génère un fichier HTML (et assets) pour chaque page définie (routes statiques, ou toutes les entrées d'un blog). Ces fichiers sont déployés sur un serveur ou un CDN. À la requête, le serveur renvoie le fichier tel quel, sans exécuter de logique métier. Option ISR : régénérer en arrière-plan après un délai (ex. 3600 s).

L'Impact Business

Un site en SSG est rapide et peu coûteux à héberger (CDN statique). C'est la base de la stratégie PSEO (pages statiques ciblées géographiquement ou thématiquement). Pour un blog, une vitrine ou des landing pages, le SSG offre le meilleur rapport performance / coût. Les mises à jour se font au rebuild ou via une revalidation incrémentale (ISR). Un site entièrement servi en fichiers statiques affiche couramment un TTFB sous 100 ms depuis un CDN, ce qui place souvent le LCP dans la zone « bon » sans serveur d'application à chaque clic — et divise parfois par deux ou trois la facture d'hébergement par rapport à une ferme de workers PHP à la requête.

Bonnes pratiques vs Erreurs communes

✅ À faire : Choisir le SSG pour le contenu stable. Utiliser getStaticPaths avec fallback si besoin. Activer l'ISR (revalidate) pour un contenu qui change périodiquement. Héberger sur un CDN pour maximiser la vitesse.
❌ À éviter : Utiliser du SSG pour des pages qui doivent afficher des données en temps réel (stock, prix) sans prévoir de zone dynamique ou de revalidation. Builds très longs si des milliers de pages sans découpage.

Prompt IA

Contexte : site [vitrine / blog / landing PSEO], contenu [statique / mis à jour quotidiennement]. Explique le SSG en une phrase. Compare SSG vs SSR pour ce cas : quand régénérer les pages (build, ISR, à la demande) ? Donne un exemple de configuration Next.js (getStaticPaths, revalidate) pour [nombre de pages / fréquence de mise à jour].