BlogSEO technique
Un site Next.js bien référencé techniquement livre son contenu principal dans le HTML, donne à chaque page un titre, une description et une URL canonique uniques, renvoie les bons codes HTTP et reste rapide pour les utilisateurs réels. Next.js fournit les outils pour tout cela ; encore faut-il les configurer et vérifier le résultat.
Sommaire de l’article
1. Rendu : le contenu doit être dans le HTML
- Privilégiez le rendu statique ou serveur pour les pages qui doivent être trouvées : avec l’App Router, les composants serveur sont le comportement par défaut, et le HTML envoyé contient déjà le texte.
- Évitez le contenu important chargé uniquement côté client : un texte qui n’apparaît qu’après un appel effectué dans le navigateur peut être indexé avec retard, ou pas du tout. Réservez les composants client à l’interactivité (formulaires, filtres, menus).
- Vérifiez en affichant le code source de la page (et non l’inspecteur) : titres, paragraphes et liens doivent y figurer.
2. Métadonnées, URL canoniques et redirections
Titre et description uniques
L’API Metadata de Next.js permet de définir un objet metadata statique dans chaque page ou layout, ou une fonction generateMetadata quand le titre dépend des données (fiche produit, article). Chaque page doit avoir son propre titre et sa propre description, qui décrivent réellement son contenu ; un modèle de titre défini dans le layout racine évite d’oublier le nom de marque.
Canonical et barre oblique finale
- Déclarez l’URL canonique de chaque page (champ alternates.canonical) pour indiquer la version de référence quand plusieurs URL affichent le même contenu (paramètres de tri, de suivi, pagination).
- Choisissez une convention pour la barre oblique finale (option trailingSlash dans next.config) et appliquez-la partout : URL canoniques, sitemap, liens internes. Une incohérence crée des doublons et des redirections inutiles.
Nom d’hôte unique
Le site ne doit répondre que sur une seule version : HTTPS, avec ou sans « www ». Les autres variantes redirigent de façon permanente, en une seule étape, vers la version choisie. Cette redirection se configure le plus souvent au niveau de l’hébergeur, du proxy ou du CDN.
3. Exploration : robots.txt, sitemap et hreflang
- robots.txt : avec l’App Router, un fichier app/robots.ts génère ce fichier. Il sert à orienter l’exploration, pas à masquer une page : pour exclure une page de l’index, utilisez la balise meta robots noindex, et ne bloquez pas cette page dans robots.txt, sinon le moteur ne verra jamais la consigne.
- sitemap.xml : un fichier app/sitemap.ts peut générer le sitemap à partir de vos données (pages, articles, produits). N’y listez que des URL canoniques qui renvoient un code 200 et sont indexables.
- hreflang : pour un site multilingue, chaque version linguistique déclare ses équivalents (champ alternates.languages de l’API Metadata, ou dans le sitemap), de façon réciproque, avec une version par défaut si nécessaire.
4. Données structurées JSON-LD
Les données structurées aident les moteurs à comprendre la nature d’une page. Les types les plus utiles pour un site d’entreprise :
- Organization sur la page d’accueil : nom, logo, coordonnées, profils officiels.
- BreadcrumbList sur les pages intérieures, cohérent avec le fil d’Ariane affiché.
- Article sur les articles de blog : titre, date de publication et de mise à jour, auteur.
Règle essentielle : ne balisez que ce qui est visible sur la page et vrai. Des avis, prix ou questions absents de la page enfreignent les consignes de Google et peuvent entraîner la perte des résultats enrichis. Dans Next.js, le JSON-LD s’insère dans une balise script de type application/ld+json rendue côté serveur.
5. Codes HTTP et liens internes
- Une vraie erreur 404 : une page inexistante doit renvoyer le code 404, pas une page « introuvable » servie en 200 (ce que Google appelle une soft 404). Dans l’App Router, la fonction notFound() et le fichier not-found s’en chargent.
- Des redirections permanentes pour les URL déplacées : lors d’une refonte, chaque ancienne URL doit rediriger vers sa nouvelle équivalente, pas vers l’accueil. Next.js utilise par défaut le code 308 pour les redirections permanentes (option redirects de next.config, fonction permanentRedirect) ; Google le traite comme un 301.
- Des liens HTML réels : les moteurs suivent les éléments a avec un attribut href. Le composant next/link produit bien ce type de lien ; évitez en revanche la navigation déclenchée uniquement par un clic JavaScript sur un bouton ou un div.
- Des ancres descriptives : « tarifs de la création de site e-commerce » informe mieux que « en savoir plus ».
6. Images, polices et poids du JavaScript
Images
- Utilisez next/image, ou à défaut des attributs width et height explicites, pour réserver l’espace de l’image et éviter les décalages de mise en page.
- Servez des formats modernes (WebP, AVIF) aux dimensions réellement affichées ; next/image le fait automatiquement selon le navigateur.
- Chargez en différé les images situées sous la ligne de flottaison, mais jamais l’image principale du haut de page (souvent l’élément LCP) : next/image propose une option pour la charger en priorité.
- Renseignez un texte alternatif utile pour les images porteuses d’information.
Polices
Hébergez les polices sur votre propre domaine, par exemple avec next/font qui les télécharge au moment du build et évite une connexion vers un service tiers. Limitez le nombre de graisses, et choisissez une stratégie font-display (swap par exemple) pour que le texte reste lisible pendant le chargement.
JavaScript
Chaque bibliothèque ajoutée côté client alourdit la page et retarde sa réactivité. Gardez dans les composants serveur tout ce qui n’a pas besoin d’interactivité, chargez les scripts tiers (analytics, chat, publicité) avec next/script et une stratégie de chargement adaptée, et contrôlez régulièrement la taille des bundles.
7. Core Web Vitals : mesurer ce que vivent les utilisateurs
Les Core Web Vitals sont trois indicateurs d’expérience utilisateur définis par Google. Les seuils « bons », évalués au 75e percentile des visites :
- LCP (Largest Contentful Paint, affichage du plus grand élément) : 2,5 secondes ou moins.
- INP (Interaction to Next Paint, réactivité aux interactions) : 200 millisecondes ou moins.
- CLS (Cumulative Layout Shift, stabilité visuelle) : 0,1 ou moins.
Distinguez les données de laboratoire (Lighthouse, PageSpeed Insights en simulation), utiles pour diagnostiquer, des données de terrain (rapport Core Web Vitals de la Search Console, données CrUX), qui reflètent les utilisateurs réels et servent de référence. Un bon score Lighthouse ne garantit pas de bons résultats de terrain sur des mobiles modestes. Pour aller plus loin, voir notre guide pour optimiser la vitesse de votre site web.
8. Accessibilité et suivi dans la durée
Les points communs entre accessibilité et SEO
- Une hiérarchie de titres logique (un seul h1, puis h2 et h3 dans l’ordre).
- Un attribut lang correct sur la balise html, cohérent avec la langue de la page.
- Des textes alternatifs pertinents et des libellés explicites pour les liens et les boutons.
- Des éléments HTML sémantiques (nav, main, article) plutôt qu’une succession de div.
Ces bonnes pratiques servent d’abord les utilisateurs ; elles rendent aussi la structure de la page plus lisible pour les moteurs et les assistants IA.
Search Console et contrôles réguliers
- Validez votre domaine dans Google Search Console et soumettez le sitemap.
- Utilisez l’outil d’inspection d’URL pour voir le HTML rendu par Google et l’état d’indexation d’une page précise.
- Surveillez le rapport d’indexation des pages : pages exclues, erreurs 404, doublons sans canonical choisie par l’utilisateur, soft 404.
- Rejouez cette checklist après chaque refonte, migration ou changement de configuration important.
9. Récapitulatif et limites
| Point | Bonne pratique | Comment vérifier |
|---|---|---|
| Rendu | Contenu principal rendu côté serveur ou statique | Code source de la page, inspection d’URL |
| Métadonnées | Titre et description uniques par page | Code source, exploration du site avec un crawler |
| Canonical | Une URL de référence, convention de barre oblique unique | Code source, inspection d’URL (canonical choisie par Google) |
| Nom d’hôte | HTTPS et une seule variante www ou sans www | Tester les variantes dans le navigateur ou avec un outil d’en-têtes HTTP |
| robots.txt et sitemap | Générés par app/robots.ts et app/sitemap.ts, URL canoniques uniquement | Ouvrir /robots.txt et /sitemap.xml, rapport Sitemaps de la Search Console |
| hreflang | Déclarations réciproques entre versions linguistiques | Code source ou sitemap, crawler |
| Données structurées | Organization, BreadcrumbList, Article, conformes au contenu visible | Test des résultats enrichis, validateur Schema.org |
| Codes HTTP | 404 réelles, redirections permanentes en une étape | Outil d’en-têtes HTTP, rapport d’indexation |
| Liens internes | Éléments a avec href, ancres descriptives | Code source, crawler |
| Images et polices | Dimensions réservées, formats modernes, polices auto-hébergées | PageSpeed Insights, onglet Réseau du navigateur |
| Core Web Vitals | LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 au 75e percentile | Rapport Core Web Vitals de la Search Console, PageSpeed Insights |
Ce que cette checklist ne garantit pas
Ces points éliminent les obstacles techniques qui empêchent une page d’être explorée, comprise et indexée ; ils ne garantissent ni un classement, ni un volume de trafic. La pertinence du contenu, sa qualité, la concurrence sur vos requêtes et la réputation du site pèsent au moins autant. Le SEO technique est une condition nécessaire, pas suffisante : il se combine avec une stratégie de contenu et un accompagnement SEO, GEO et AEO suivi dans le temps, comme nous l’expliquons dans notre article sur le SEO, le GEO et l’AEO.
Sources et références
Votre site Next.js est en ligne, en refonte ou en projet ? Nous pouvons passer cette checklist en revue avec vous et prioriser les corrections qui comptent vraiment.