Transactionnel/Expert · P1
SEO Next.js
Next.js fournit tout ce qu'il faut pour un site indexable, mais le choix du mode de rendu reste à faire route par route, et une erreur de configuration suffit à servir une page vide. Les points sensibles sont le choix entre rendu statique, rendu serveur et rendu client, la génération des métadonnées, et la cohérence des canonical. Le contrôle se fait toujours sur le HTML servi.
Périmètre
Ce que couvre cette prestation
Audit et correction SEO d'une application Next.js : stratégie de rendu, métadonnées, canonical, sitemap, revalidation et performance d'hydratation.
Inclus
- Mode de rendu par route et cohérence avec l'intention
- Métadonnées générées côté serveur, y compris pour les routes dynamiques
- Canonical auto-référentes et gestion des paramètres
- Sitemap et robots générés depuis les données réelles
- Revalidation et fraîcheur des pages statiques
- Composants client isolés et volume de JavaScript envoyé
- Images et stabilité visuelle
- Contrôles automatisés sur le HTML servi
Hors périmètre
- Migration de version majeure sans besoin identifié
- Rendu dynamique externe, inutile avec les capacités du framework
Problèmes traités
Ce qui amène généralement à cette page
Une route censée être statique est rendue côté client
Un composant client placé trop haut dans l'arbre suffit à vider le HTML servi d'une partie de son contenu.
Les métadonnées manquent sur les routes dynamiques
Sans génération explicite par route, les pages dynamiques héritent de métadonnées génériques, voire d'aucune.
Le contenu statique est périmé
Une revalidation mal réglée sert longtemps un contenu obsolète, avec des dates et des prix incohérents.
Livrables
Ce que vous recevez
-
Matrice de rendu par route
Mode retenu, justification, et contenu attendu dans la réponse serveur.
-
Spécification des métadonnées
Title, description, canonical et données structurées par type de route, y compris dynamique.
-
Plan de revalidation
Fraîcheur attendue par type de contenu et mécanisme associé.
-
Contrôles d'intégration continue
Tests sur le HTML servi : H1 unique, métadonnées présentes, contenu principal non vide.
Méthode
Comment on procède
-
Inspecter le HTML servi route par route
C'est la seule mesure fiable : la configuration déclarée peut différer du résultat.
-
Classer les routes par intention
Indexable ou non, stable ou dépendante de la requête, publique ou privée.
-
Remonter les frontières client
Isoler l'interactivité le plus bas possible dans l'arbre pour préserver le HTML servi.
-
Automatiser le contrôle
Les règles obtenues deviennent des tests exécutés à chaque build.
Preuves
Ce qui est vérifiable
- Ce site est construit avec une architecture statique comparable et vérifie en intégration continue que chaque page sert son contenu principal.
- Les contrôles utilisés ici sont réutilisables sur un projet Next.js : ils lisent le HTML produit, indépendamment du framework.
- L'écart entre configuration déclarée et HTML réellement servi est mesurable avec l'outil d'extraction publié ici.
Les chiffres cités proviennent des exports Search Console de ce domaine datés du 26 octobre 2026, publiés avec leurs limites sur la page études de cas. Aucun résultat client n'est publié sans accord et sans fenêtre de mesure explicite.
Cas d'usage
Situations typiques
Site de contenu en Next.js
Rendu statique avec revalidation et métadonnées générées par route.
Catalogue avec pages dynamiques
Arbitrage entre génération au build et rendu à la demande selon le volume.
Application avec zone publique et privée
Séparation stricte des stratégies de rendu.
Limites et cas où cela ne s'applique pas
- Le rendu à la demande a un coût d'exécution qui croît avec le trafic.
- Une mauvaise frontière client peut annuler le bénéfice du rendu serveur : le contrôle doit être automatisé.
- Les évolutions de version majeure modifient les API de métadonnées et de cache.
Questions fréquentes
Faut-il tout rendre côté serveur ?
Non. Le rendu statique est préférable quand le contenu est stable : il est plus rapide et moins coûteux. Le rendu à la demande se justifie quand la page dépend de la requête ou doit être immédiatement à jour.
Comment gérer les canonical ?
En les générant côté serveur, auto-référentes, à partir d'une URL de base unique, et en excluant les paramètres non significatifs. Une canonical calculée côté client n'est pas fiable.
Comment éviter les régressions ?
Par des tests sur le HTML produit au build : présence d'un H1 unique, des métadonnées et du contenu principal. C'est exactement ce qui est en place sur ce site.
Pour aller plus loin
Pages et outils liés
Diagnostic
Diagnostiquer un projet Next.js
Une réponse argumentée sous deux jours ouvrés, avec un premier avis sur le maillon qui bloque. Pas de prise de rendez-vous imposée avant d'avoir compris le contexte.