Rendu, métadonnées et Core Web Vitals, lus sur les pages publiques
Auditez ce que votre site Next.js livre aux moteurs de recherche.
Vous gérez un site Next.js, ou vous en avez hérité, et vous voulez savoir ce que le moteur de recherche analyse vraiment. L'évaluation gratuite examine votre page d'accueil et jusqu'à huit pages choisies au hasard, puis vous donne une note sur 100, explications à l'appui. Elle n'accède jamais à votre code source, ne se connecte jamais et ne consulte jamais vos statistiques. Donc vous n'avez rien à lui transmettre.
Sur cette page 8 sections
- 01Quels sont les éléments vérifiés lors d'un audit SEO Next.js ?
- 02Le mode de rendu change-t-il ce que reçoit Google ?
- 03Comment l'API Metadata détermine-t-elle vos titres, vos URL canoniques et vos balises Open Graph ?
- 04Pourquoi les sites Next.js échouent-ils aux Core Web Vitals ?
- 05Quelles erreurs d'App Router cachent des pages aux moteurs de recherche ?
- 06Comment vérifier un site Next.js depuis l'extérieur en deux minutes ?
- 07Vos questions, nos réponses
- 08À lire ensuite
Quels sont les éléments vérifiés lors d'un audit SEO Next.js ??
Votre audit vérifie ce que chaque page échantillonnée renvoie à un robot d'indexation : le code HTML de votre réponse, les balises de votre en-tête, vos signaux d'indexation et le poids de vos scripts. Faites un test simple. Affichez le code source de votre page d'accueil et cherchez votre titre principal. Vous le trouvez ? Votre serveur l'a bien envoyé. Si vous ne voyez qu'une balise `div` vide et une série de scripts (ce qui arrive souvent), votre contenu dépend de JavaScript.
L'évaluation analyse les en-têtes de réponse, le balisage, les données structurées, les balises de titre, le poids des scripts et des images, ainsi que les directives robots et canoniques de votre page d'accueil et d'un maximum de huit pages échantillonnées. Ces données alimentent huit critères pondérés qui déterminent votre score, dont l'architecture (15 %), les performances (15 %), le référencement (12 %) et le schéma (10 %). Elle n'accède jamais à votre dépôt de code. Chaque résultat montre ce qu'un robot d'indexation perçoit de votre site, pas le fichier source d'origine. Or les moteurs de recherche ne lisent pas votre code non plus : pour vous, c'est précisément cette analyse externe qui compte.
Le mode de rendu change-t-il ce que reçoit Google ??
Oui. Votre mode de rendu décide si la réponse initiale contient votre texte ou seulement une structure vide que Google devra générer plus tard. Ouvrez l'une des URL de vos articles et vérifiez que votre code HTML contient bien le corps du texte. En rendu statique, vous générez ce code HTML à l'avance et vous le mettez en cache ; en rendu dynamique, votre serveur le produit à chaque requête. Dans les deux cas, vous servez du balisage, et c'est tout ce qui compte.
Les ennuis commencent quand vous ne comptez que sur la récupération côté client. Si vous forcez une page en mode « client » ou chargez votre contenu dans `useEffect`, Googlebot voit « Chargement… » à la place de votre contenu. Next.js choisit une stratégie pour chacune de vos routes. Un seul appel à une API dynamique, comme celles qui lisent les cookies ou les en-têtes, change le mode de cette route. Vous pouvez donc vous retrouver avec un site hybride sans l'avoir décidé.
Google exécute votre JavaScript, mais il met d’abord vos pages en file d’attente après la première réponse 200, et l’attente peut dépasser quelques secondes. Sa documentation continue de présenter le pré-rendu côté serveur comme une excellente idée. Tous les robots n’exécutent pas le JavaScript. Ne comptez pas sur eux pour lancer vos scripts. L’évaluation vérifie, route par route, le contenu de votre réponse : vous voyez ainsi ce que vous envoyez sur chacune.
Comment l'API Metadata détermine-t-elle vos titres, vos URL canoniques et vos balises Open Graph ??
Vos balises « head » viennent de l’objet « metadata » ou de la fonction « generateMetadata » que vous exportez dans un fichier « layout.js » ou « page.js ». Ouvrez la section « head » d’une page de second niveau de votre site. Cherchez-y votre titre et votre lien canonique, puis votre balise « og:image ». Vous relisez ainsi vos exportations telles qu’elles sortent. Ce que vous voyez là correspond exactement à ce que l’évaluation lit sur votre page.
Votre fonction `generateMetadata` peut récupérer des données et lire les métadonnées de la page parente. Vous pouvez donc compléter une image Open Graph commune au lieu de l’écraser. Définissez `alternates.canonical`, et Next.js écrit votre lien canonique ; définissez `openGraph.images`, et il écrit votre `og:image`. Les URL d’images doivent être absolues, donc définissez `metadataBase` avec `new URL(...)`. Votre `title.template` ne s’applique qu’aux segments enfants : il ignore la page du segment où vous le définissez, et cela surprend facilement. Des titres qui semblent faux ? Vérifiez l’endroit où vous l’avez défini.
Avec des métadonnées statiques, le même titre se retrouve souvent sur plusieurs pages, et il arrive qu’une balise canonique manque ou qu’une balise `og:image` soit relative. L’évaluation liste ces défauts sur les pages échantillonnées de votre site ; vous rattachez ensuite chaque manque à l’exportation concernée. Ouvrez le fichier de cette page et vérifiez ce que vous exportez. Chaque défaut vient d’une exportation que vous avez faite, ou oubliée.
Pourquoi les sites Next.js échouent-ils aux Core Web Vitals ??
Votre site Next.js échoue aux Core Web Vitals quand vos données de terrain indiquent un LCP supérieur à 2,5 secondes, un INP supérieur à 200 millisecondes ou un CLS supérieur à 0,1. Vercel indique que, sur les pages où l’élément LCP était une image, 35 % de ces images avaient une URL source introuvable dans le code HTML initial. Vérifiez chez vous. Cherchez dans le code HTML initial l’URL de votre plus grande image visible au premier écran.
Le poids des scripts et l’hydratation pèsent sur votre INP, qui a remplacé le FID en mars 2024. Selon Vercel, si vous enveloppez vos blocs de page principaux dans Suspense, ils s’hydratent séparément, ce qui améliore votre INP. Pour le CLS, les causes sont plus directes : images servies sans dimensions, contenu injecté, polices Web chargées. Vérifiez ces trois points dans vos modèles.
L’évaluation analyse le poids des scripts et des images de vos pages, mais ne fournit aucune donnée de terrain. Or Google classe vos pages dans les résultats de recherche à partir des données de terrain recueillies sur 28 jours. Un test Lighthouse propre ne suffit pas. Même un bon score en laboratoire peut cacher un mauvais mois. Lancez ensuite le test Core Web Vitals et vérifiez vos propres données de terrain.
Quelles erreurs d'App Router cachent des pages aux moteurs de recherche ??
Vous cachez des pages aux moteurs de recherche quand vous n’affichez le contenu que côté client, quand vous ajoutez « noindex » par erreur, quand vous bloquez l’exploration là où vous vouliez appliquer « noindex », ou quand vous laissez des URL en double sans balises « canonical ». Ouvrez votre fichier robots.txt : bloquez-vous les chemins vers vos fichiers JavaScript ou CSS ? Consultez ensuite l’en-tête de votre page principale et cherchez une balise méta « robots ». Une seule ligne de trop à cet endroit suffit à réduire votre travail à néant, et on s’en aperçoit rarement à temps.
Dans votre App Router, vous définissez l’attribut « noindex » au niveau de la page avec une exportation de métadonnées : robots: { index: false, follow: false }. Si cette URL reste dans votre plan du site, vos signaux se contredisent. Bloquez-la aussi dans votre fichier robots.txt, et Google risque de ne jamais explorer la page : votre attribut « noindex » passera alors inaperçu. Les deux mesures s’annulent.
Vérifiez d'abord que votre environnement de préproduction n'est pas indexé [l'erreur classique]. L'évaluation analyse les balises « robots » et les signaux canoniques de votre page d'accueil, puis ceux des pages échantillonnées. Le rapport remonte donc les balises « noindex » posées par erreur, les balises canoniques absentes et les pages coquilles rendues côté client. Mais il a une limite nette : il ne voit pas les routes situées hors de cet échantillon. Pour celles-là, la vérification vous revient.
Comment vérifier un site Next.js depuis l'extérieur en deux minutes ??
Lancez l'évaluation gratuite sur votre URL, puis saisissez votre adresse e-mail professionnelle. En deux minutes environ, vous obtenez un score sur 100, avec les éléments qui justifient chaque pilier. Commencez simple : collez l'URL de votre page d'accueil. Et comparez ce que le rapport indique sur le rendu et les balises d'en-tête avec ce que vous voyez dans « Afficher la source », sur l'une de vos pages de second niveau. Votre adresse e-mail ne sert d'ailleurs qu'à une chose [recevoir le lien vers le rapport, une seule fois]. Vous pouvez lancer trois analyses par heure et par connexion.
Commencez par votre score, avant même de lire le détail. Entre 80 et 100, votre situation est satisfaisante ; entre 60 et 79, elle est critique ; entre 40 et 59, elle est à risque ; entre 0 et 39, c'est une situation d'ancienneté. Lisez ensuite vos résultats pilier par pilier et notez les éléments qui touchent au rendu, aux balises canoniques ou au poids des scripts. Ce sont eux qui désignent les corrections au plus fort impact sur votre site.
Mais vos prochaines vérifications sortent du périmètre de cette analyse. L'évaluation ne lit que vos pages publiques [sans accès interne] : elle ne peut donc confirmer ni vos données de performance sur le terrain, ni votre source. Vous voulez mesurer des temps de chargement ? Lancez le test Core Web Vitals. Vous voulez savoir comment les systèmes d'IA interprètent vos pages ? Lancez l'audit SEO IA.
Vos questions, nos réponses.
01Next.js est-il mauvais pour le SEO ?
Non. Next.js peut envoyer du code HTML entièrement rendu, et Google exécute aussi le JavaScript, mais via une file d'attente qui peut dépasser quelques secondes [ce qui retarde d'autant la découverte de votre contenu]. Le risque est ailleurs : une route récupère son contenu côté client et renvoie une structure vide. L'évaluation vérifie donc route par route si les pages échantillonnées transmettent bien du contenu dans la réponse.
02L'analyse lit-elle mon code source Next.js ?
Non. L'outil analyse seulement ce que vos pages publiques exposent : en-têtes de réponse, balisage, données structurées, titres, poids des scripts et des images, signaux robots et URL canoniques. Il ne se connecte pas à votre site, ne consulte pas vos données d'analyse, ne récupère aucune donnée de performance sur le terrain et n'interroge personne. En clair, chaque résultat décrit ce que reçoit un robot d'exploration. Rien de plus.
03Faut-il privilégier l'exportation statique ou le rendu côté serveur pour le SEO ?
Les deux méthodes conviennent pour le référencement. L'exportation statique [configurée avec l'option output: 'export' depuis Next.js 13.3] génère un fichier HTML par route ; le rendu côté serveur, lui, génère le code HTML à chaque requête. Mais le point décisif est plus simple : la réponse doit contenir votre contenu, vos titres et vos balises canoniques. Vérifiez-le directement dans le code source de la page, pour chaque type de route.
04Combien de fois pouvez-vous lancer l'analyse ?
Vous pouvez lancer trois vérifications par heure et par connexion. Chacune dure environ deux minutes, reste gratuite et demande une adresse e-mail professionnelle [le lien vers le rapport n'y est envoyé qu'une seule fois]. Chaque vérification analyse votre page d'accueil et jusqu'à huit pages choisies au hasard. Déployez un correctif, puis relancez l'analyse. Et en comparant les résultats, vous voyez immédiatement si la modification a bien été prise en compte.
Sources
Les faits de cette page proviennent des documents ci-dessous, vérifiés le 2026-10-25. Les chiffres sur l'analyse elle-même décrivent son fonctionnement.
Analyse automatisée gratuite