Indexation Google pour Next.js : le guide complet pour l'App Router et le Pages Router
Navigue entre SSG, SSR, ISR et composants client pour rendre chaque route découvrable par Google
Dans ce guide
Next.js est le framework React le plus populaire pour les apps en production, et son modèle de rendu — qui couvre SSG, SSR, ISR et rendu côté client — crée à la fois des opportunités puissantes et des pièges d'indexation subtils. Certaines routes servent du HTML parfait dès la première requête ; d'autres envoient une coquille vide qui exige l'exécution de JavaScript.
Ce guide couvre à la fois l'App Router et le Pages Router, en passant en revue la Metadata API, generateStaticParams, les sitemaps programmatiques avec sitemap.ts, la configuration de robots.ts, les données structurées et les pièges spécifiques qui font apparaître les pages Next.js vides à Googlebot.
Les stratégies de rendu et leur impact sur l'indexation
Next.js propose quatre stratégies de rendu, et chacune a des implications différentes pour la façon dont Googlebot voit (ou non) ton contenu.
Static Site Generation (SSG) est la référence pour l'indexation. Les pages sont rendues en HTML complet au moment du build et servies en fichiers statiques. Googlebot reçoit du HTML entièrement formé immédiatement — aucune exécution JavaScript requise. Dans l'App Router, tout Server Component qui n'appelle pas de fonctions dynamiques (comme cookies(), headers() ou searchParams) est rendu statiquement par défaut. Dans le Pages Router, tu obtiens du SSG en exportant getStaticProps.
Server-Side Rendering (SSR) génère du HTML à chaque requête. Googlebot reçoit du HTML complet comme avec le SSG, mais la page n'est pas mise en cache (sauf si tu ajoutes des en-têtes de cache). Le SSR est déclenché dans l'App Router en utilisant des fonctions dynamiques ou en définissant export const dynamic = "force-dynamic" sur un segment de route. Dans le Pages Router, tu utilises getServerSideProps. Le SSR est fiable pour l'indexation mais plus lent que le SSG parce que chaque requête de crawl déclenche un rendu complet.
Incremental Static Regeneration (ISR) est un hybride : la page est générée statiquement au build, servie depuis le cache et régénérée en arrière-plan après un intervalle configurable. Dans l'App Router, l'ISR s'obtient en définissant export const revalidate = 3600 (en secondes) sur une page ou un layout. Dans le Pages Router, tu ajoutes revalidate à la valeur de retour de getStaticProps. L'ISR est excellent pour l'indexation — Googlebot reçoit du HTML statique rapide, et le contenu reste raisonnablement frais.
Le rendu côté client (CSR) est là où les problèmes d'indexation surgissent. Si un composant est marqué "use client" et récupère des données dans un hook useEffect, le HTML initial envoyé au navigateur (et à Googlebot) ne contient rien d'autre qu'un état de chargement. Si Googlebot peut exécuter du JavaScript jusqu'à un certain point, il le traite dans une passe d'indexation secondaire qui peut arriver des heures ou des jours plus tard — et le fetch de données complexe côté client échoue souvent silencieusement dans l'environnement de rendu de Google.
La règle : tout contenu que tu veux indexer doit être présent dans le HTML initial rendu côté serveur, pas chargé via du JavaScript côté client après hydration.
La Metadata API : generateMetadata et metadata statique
L'App Router a introduit une puissante Metadata API qui remplace l'ancien composant <Head> du Pages Router. Il y a deux façons de définir les métadonnées : les exports statiques et la fonction dynamique generateMetadata.
Pour la metadata statique, exporte un objet metadata depuis n'importe quel fichier page.tsx ou layout.tsx. Ça marche bien pour les pages avec une metadata connue et fixe.
Pour les routes dynamiques où la metadata dépend des données (comme un slug d'article de blog), utilise generateMetadata. Cette fonction async reçoit les params de la route et peut récupérer des données pour construire la metadata dynamiquement.
Point critique : generateMetadata tourne sur le serveur, donc elle s'exécute toujours pour les requêtes Googlebot. Si tu définis plutôt la metadata dans un composant "use client" en utilisant document.title ou un gestionnaire de head tiers, Googlebot peut ne pas la capter pendant son parse HTML initial. Définis toujours la metadata via la Metadata API côté serveur.
La Metadata API supporte la gamme complète de meta tags :
titleetdescriptionopenGraphettwitterpour le partage socialrobotspour le contrôle de l'indexationalternatespour les hreflang et URLs canoniquesverificationpour Google Search Consoleiconspour les favicons
Pour les URLs canoniques, utilise le champ alternates.canonical. Pour les pages avec des variantes linguistiques, remplis alternates.languages avec une map des codes locale vers les URLs.
Dans le Pages Router, la metadata est gérée en important Head depuis "next/head" et en plaçant des meta tags à l'intérieur, dans ton composant. Bien que ça marche encore, il y a des limitations : le contenu de Head n'est traité qu'après le rendu React, et les composants Head complexes imbriqués peuvent mener à de la duplication de tags. Si tu démarres un nouveau projet, utilise la Metadata API de l'App Router.
Générer des sitemaps avec sitemap.ts et sitemap.xml
L'App Router de Next.js supporte la génération programmatique de sitemap via un fichier spécial sitemap.ts (ou sitemap.xml/route.ts) placé dans le répertoire app. L'approche la plus simple est de créer app/sitemap.ts qui exporte une fonction par défaut renvoyant un tableau d'entrées de sitemap.
Cela génère /sitemap.xml automatiquement. La fonction tourne au moment de la requête en développement et au build en production (pour les exports statiques) ou à chaque requête (pour le rendu dynamique).
Pour les gros sites avec plus de 50 000 URLs, utilise le pattern de sitemap index. Crée app/sitemap.ts qui renvoie un sitemap index pointant vers plusieurs sous-sitemaps, puis crée des route handlers individuels pour chaque sous-sitemap (par exemple, app/sitemaps/[id]/route.ts). La spec sitemap de Google autorise jusqu'à 50 000 URLs par fichier sitemap et jusqu'à 500 fichiers sitemap dans un index.
L'erreur cruciale que font les devs est d'oublier d'inclure les routes dynamiques dans le sitemap. Si ton app a une route comme /blog/[slug], la fonction sitemap doit interroger ta base de données ou CMS pour obtenir chaque slug valide et générer des URLs pour chacun. Lister simplement /blog/[slug] dans le sitemap n'a aucun sens — Google a besoin des vraies URLs résolues.
Dans le Pages Router, il n'y a pas de génération de sitemap intégrée. Tu as deux options :
- Utiliser le package npm
next-sitemap(génère les sitemaps au build en lisant ton répertoire pages et la sortie degetStaticPaths) - Créer une route API custom à
pages/api/sitemap.tsqui génère du XML dynamiquement
Le package next-sitemap est le choix le plus courant et supporte les sitemaps côté serveur, la génération de robotsTxt et le split multi-sitemap.
Routes dynamiques : generateStaticParams et comportement de fallback
Les routes dynamiques (app/blog/[slug]/page.tsx) sont la source la plus courante de trous d'indexation dans les applications Next.js. Sans une configuration correcte, les routes dynamiques peuvent ne pas être pré-rendues au build, ce qui veut dire que Googlebot rencontre soit un 404 soit un état de chargement à la première visite.
Dans l'App Router, exporte une fonction generateStaticParams depuis ta page dynamique pour pré-rendre des chemins spécifiques au build. Chaque slug renvoyé par cette fonction devient une page générée statiquement.
Mais qu'en est-il des slugs qui n'existent pas dans generateStaticParams ? Ça se contrôle via l'export dynamicParams :
- `dynamicParams = true` (par défaut) — Next.js tente de rendre côté serveur les slugs non matchés à la demande et met en cache le résultat
- `dynamicParams = false` — les slugs non matchés renvoient un 404
Pour le SEO, le défaut (true) est généralement correct parce qu'il permet au contenu nouvellement publié d'être rendu sans un rebuild complet.
Dans le Pages Router, l'équivalent est getStaticPaths avec un paramètre fallback :
- `fallback: false` — renvoie 404 pour les chemins inconnus
- `fallback: true` — rend une page de chargement à la première requête (Googlebot voit l'état de chargement, ce qui est terrible pour l'indexation)
- `fallback: "blocking"` — bloque la réponse jusqu'à ce que la page soit entièrement rendue, puis la met en cache
Pour le SEO, utilise toujours `fallback: "blocking"` dans le Pages Router.
L'interaction entre generateStaticParams et l'ISR est importante. Si tu définis revalidate sur une page dynamique, les pages pré-rendues sont régénérées en arrière-plan après la période de revalidation. Les nouveaux slugs absents de generateStaticParams sont rendus à la première requête (si dynamicParams est true) puis mis en cache via ISR. Cette combinaison te donne le meilleur des deux mondes : service statique rapide pour les pages connues et rendu à la demande pour le nouveau contenu.
robots.ts, règles noindex et contrôle du crawl
L'App Router supporte un fichier robots.ts à app/robots.ts qui génère programmatiquement /robots.txt.
Considérations spécifiques à Next.js pour robots.txt :
- Bloque toujours les routes
/api/(elles renvoient du JSON, pas du HTML) - Bloque
/_next/data/(données JSON pour la navigation côté client qui ne devraient pas être indexées comme pages autonomes) - Bloque toute route de dashboard authentifiée
- NE bloque PAS
/_next/static/— ça contient les fichiers CSS et JS dont Googlebot a besoin pour rendre tes pages correctement
Pour le contrôle noindex au niveau de la page, utilise le champ robots dans la Metadata API. Définis robots: { index: false } dans l'export metadata de toute page que tu veux exclure des résultats de recherche. C'est approprié pour :
- Les pages d'authentification (
/login,/register) - Les dashboards utilisateurs
- La documentation d'API derrière une authentification
- Toute page avec du contenu personnalisé
Middleware (middleware.ts à la racine du projet) peut aussi affecter l'indexation. Si ton middleware effectue des redirections pour l'authentification ou la détection de locale, assure-toi que Googlebot n'est pas piégé dans des boucles de redirection.
Un pattern sûr et courant est un middleware qui redirige les utilisateurs non authentifiés de /dashboard vers /login — c'est bien parce que tu veux que /dashboard soit noindex de toute façon. Mais un middleware qui redirige selon la géolocalisation peut piéger Googlebot (qui crawle depuis des IPs basées aux US) à toujours voir la version US, empêchant les autres versions de locale d'être indexées.
Teste le comportement de ton middleware avec l'outil Inspection d'URL de Google Search Console pour voir exactement ce que Googlebot rencontre.
Données structurées et Open Graph pour les rich results
Les données structurées (JSON-LD) sont essentielles pour obtenir des rich results dans Google : étoiles d'avis, accordéons FAQ, fils d'Ariane, dates de publication d'articles, et plus. Dans l'App Router, l'approche la plus propre est de créer un Server Component JsonLd qui rend une balise <script type="application/ld+json">.
Ce composant devrait accepter des props typées correspondant aux types Schema.org (Article, FAQPage, Product, BreadcrumbList, Organization) et les sérialiser dans la balise script. Comme c'est un Server Component, le JSON-LD est présent dans le HTML initial que reçoit Googlebot — aucune exécution côté client nécessaire.
Pour les balises Open Graph, utilise le champ openGraph dans ton export Metadata API. Inclus :
og:titleetog:descriptionog:image(avec dimensions)og:url,og:typeetog:locale
Pour les Twitter Cards, utilise le champ twitter. Ces balises doivent être présentes dans le <head> du HTML, ce que la Metadata API gère automatiquement.
Une erreur courante dans les apps Next.js est de générer les données structurées côté client. Si tu utilises un composant "use client" pour récupérer les avis produits puis générer un bloc JSON-LD avec la note agrégée, le parse HTML initial de Googlebot peut ne pas inclure les données structurées. Génère toujours les données structurées dans des Server Components ou dans `generateMetadata`. L'outil Rich Results Test de Google te laisse tester des URLs spécifiques pour vérifier que tes données structurées sont visibles aux crawlers.
Les données structurées de fil d'Ariane sont particulièrement précieuses pour les apps Next.js avec des routes imbriquées. Si la structure de ton app est /blog/categorie/slug-article, génère un schéma BreadcrumbList avec des items pour Accueil, Blog, la page catégorie et l'article courant. Ça donne à Google des informations explicites de hiérarchie de navigation et peut résulter en un affichage de fil d'Ariane dans les résultats de recherche au lieu de l'URL brute.
Guide étape par étape
Audite ta stratégie de rendu route par route
Vérifie next.config.ts pour les réglages d'output globaux. Passe en revue chaque page.tsx et classifie-la : fonctions dynamiques = SSR, export revalidate = ISR, generateStaticParams = pré-rendu, "use client" avec fetch de données dans useEffect = CSR (risque d'indexation). Construis un tableau de chaque route, sa stratégie et si le contenu critique apparaît dans le HTML initial.
Implémente la Metadata API sur chaque route
Pour chaque page.tsx et layout.tsx dans ton App Router, ajoute soit un export metadata statique soit une fonction generateMetadata. Au minimum, chaque page a besoin d'un title et d'une description uniques.
- Pour ton layout racine (
app/layout.tsx), définis une metadata par défaut en utilisant le champtitle.template(par exemple,title: { template: "%s | TonApp", default: "TonApp" }) - Pour les routes dynamiques comme
/blog/[slug], implémentegenerateMetadataqui récupère le contenu et renvoie une metadata spécifique à la page - Ajoute
alternates.canonicalà chaque page pour définir l'URL canonique explicitement - Si ton app supporte plusieurs langues, remplis
alternates.languages
Ne définis pas la metadata dans des composants "use client" — utilise toujours les exports metadata côté serveur.
Crée sitemap.ts et robots.ts
Crée app/sitemap.ts qui exporte une fonction async par défaut renvoyant un tableau d'entrées de sitemap. Interroge ta base de données ou CMS pour tout le contenu dynamique (articles de blog, pages produits, pages catégories) et génère une URL complète pour chacun.
Définis les valeurs de priorité :
- 1.0 pour la page d'accueil
- 0.8-0.9 pour les pages d'atterrissage clés
- 0.5-0.7 pour le contenu régulier
Inclus les dates lastModified pour chaque entrée.
Crée app/robots.ts qui renvoie des règles bloquant /api/, /_next/data/, /admin/ et toute route authentifiée, tout en autorisant tout le reste et en spécifiant l'URL de ton sitemap.
Déploie et vérifie que /sitemap.xml renvoie du XML valide et que /robots.txt renvoie des directives valides en les visitant dans ton navigateur.
Pré-rends les routes dynamiques avec generateStaticParams
Exporte generateStaticParams depuis chaque route dynamique pour pré-rendre les chemins valides au build. Combine avec dynamicParams: true et revalidate pour que le nouveau contenu soit rendu côté serveur à la première requête et mis en cache via ISR. Dans le Pages Router, utilise fallback: "blocking" au lieu de fallback: true pour éviter de servir des états de chargement à Googlebot.
Déplace le contenu critique hors des Client Components
Passe en revue chaque composant "use client" qui affiche du contenu que tu veux indexer. Si le composant récupère des données avec useEffect, useSWR ou React Query et les rend côté client, Googlebot peut ne pas voir ce contenu.
Pattern de refactor : déplace le fetch de données vers un Server Component parent et passe les données en props au composant client. Le composant client peut encore gérer l'interactivité (gestionnaires de clic, état), mais le contenu initial doit être présent dans le HTML rendu côté serveur.
Test : désactive JavaScript dans ton navigateur et charge chaque page. Ce que tu vois sans JavaScript est approximativement ce que Googlebot voit lors de son parse HTML initial.
Ajoute des données structurées pour des rich results
Crée un Server Component réutilisable pour les données structurées JSON-LD. Ajoute les types de schéma appropriés :
- Articles de blog — schéma
Articleavecheadline,author,datePublished,dateModifiedetimage - Pages produits — schéma
Productavecname,description,priceetaggregateRating - Toutes les pages imbriquées — schéma
BreadcrumbListpour la hiérarchie de navigation - Page d'accueil — schéma
Organization
Valide chaque implémentation de données structurées en utilisant le Rich Results Test de Google en saisissant tes URLs live. Corrige toute erreur ou avertissement avant de passer à la suite.
Souviens-toi : toutes les données structurées doivent être dans des Server Components pour qu'elles apparaissent dans le HTML initial.
Soumets les URLs critiques via IndexBolt et surveille
Soumets ta page d'accueil, tes pages d'atterrissage clés et ton contenu prioritaire via IndexBolt. Pour une nouvelle app, 20-50 URLs amorcent la compréhension de Google avec des jours d'avance. Surveille dans l'Inspection d'URL de Search Console — vérifie que le fetch de page montre du HTML complet, pas des états de chargement. Investigue toute route « Découverte, actuellement non indexée » pour des problèmes de rendu.
Problèmes courants et comment les résoudre
Les pages affichent un contenu vide ou des spinners de chargement à Googlebot
Cause : Le contenu est récupéré dans un composant "use client" via useEffect ou une bibliothèque de fetch côté client. Le HTML initial rendu côté serveur contient seulement l'état de chargement (un spinner, un skeleton ou un div vide). Le parse HTML initial de Googlebot ne voit aucun contenu, et sa passe de rendu JavaScript secondaire peut échouer à cause d'authentification API, de problèmes CORS ou de timeout de rendu.
Solution : Déplace le fetch de données vers des Server Components ou utilise generateStaticParams avec génération statique. Passe les données en props aux composants client qui ont besoin d'interactivité. Pour le Pages Router, utilise getStaticProps ou getServerSideProps au lieu du fetch côté client. Teste en affichant le source de la page (pas le DOM rendu dans DevTools) — le source devrait contenir le texte de ton vrai contenu.
Les routes dynamiques renvoient 404 pour les pages absentes de generateStaticParams
Cause : La route dynamique a export const dynamicParams = false défini, ce qui signifie que tout slug non renvoyé par generateStaticParams produit un 404. Dans le Pages Router, getStaticPaths avec fallback: false se comporte pareil. Le contenu nouvellement publié qui n'était pas présent au build est inaccessible.
Solution : Définis dynamicParams à true (le défaut) et ajoute une période revalidate pour que les pages nouvellement générées soient mises en cache via ISR. Dans le Pages Router, passe de fallback: false à fallback: "blocking". Ensuite, assure-toi que ton sitemap.ts interroge dynamiquement tout le contenu actuel pour que les nouvelles pages apparaissent dans le sitemap même si elles n'ont pas été pré-rendues au build.
Le sitemap n'inclut pas les pages générées dynamiquement
Cause : Le fichier sitemap.ts a été écrit avec une liste statique d'URLs et n'interroge pas la base de données ou le CMS pour le contenu dynamique. Ou le sitemap a été généré au build via next-sitemap mais le build n'a pas été relancé après la publication de nouveau contenu. Les nouveaux articles de blog, pages produits ou pages catégories manquent du sitemap.
Solution : Réécris sitemap.ts pour interroger dynamiquement ta source de contenu (base de données, API CMS headless ou système de fichiers) à chaque requête. Pour les sites basés sur ISR, définis revalidate sur la route du sitemap pour qu'il se régénère périodiquement. Si tu utilises next-sitemap dans le Pages Router, configure la génération de sitemap côté serveur ou mets en place un cron job pour déclencher des rebuilds quand le contenu change.
Les redirections du middleware empêchent Googlebot d'accéder aux pages spécifiques à une locale
Cause : Le middleware de détection de locale lit l'en-tête Accept-Language ou utilise la géolocalisation par IP pour rediriger les visiteurs vers un chemin spécifique à une locale (par exemple, /en-us/, /fr/). Googlebot crawle principalement depuis des IPs basées aux US avec des en-têtes anglais, donc il est toujours redirigé vers la version anglaise US. Les pages pour les autres locales ne sont jamais crawlées ni indexées.
Solution : Ne redirige pas Googlebot selon la géolocalisation ou Accept-Language. À la place, sers le contenu de la locale par défaut et appuie-toi sur les balises hreflang (définies via alternates.languages dans la Metadata API) pour signaler à Google les variantes de locale. Dans ton middleware, tu peux vérifier l'User-Agent pour Googlebot et sauter les redirections de locale pour lui, ou mieux encore, utiliser hreflang comme signal principal de locale et n'utiliser les redirections middleware que comme commodité pour les vrais utilisateurs.
Les fichiers loading.tsx affichent du contenu placeholder qui se fait indexer
Cause : L'App Router de Next.js utilise loading.tsx pour afficher une UI de chargement instantanée via React Suspense pendant qu'une page est en cours de rendu. Si la page utilise du SSR (rendu dynamique), la requête initiale de Googlebot peut recevoir le contenu de loading.tsx au lieu de la vraie page. C'est particulièrement probable pour les pages avec un fetch de données lent.
Solution : Pour les pages avec du contenu SEO critique, préfère la génération statique ou l'ISR au rendu dynamique. Si le rendu dynamique est nécessaire, assure-toi que le fetch de données se termine rapidement (sous 5 secondes) pour que la réponse en streaming délivre le vrai contenu avant le timeout de Googlebot. Envisage de déplacer le fetch de données lourdes dans des composants client qui enrichissent la page après que le contenu critique rendu côté serveur soit déjà présent.
Le composant Image de Next.js génère des URLs qui encombrent le budget de crawl
Cause : Le composant Image de Next.js optimise les images via les chemins /_next/image?url=...&w=...&q=... Chaque combinaison de largeur et de qualité génère une URL unique. Si ces URLs ne sont pas bloquées dans robots.txt, Googlebot peut dépenser du budget de crawl à récupérer les endpoints d'optimisation d'image plutôt que le vrai contenu de page.
Solution : Ajoute Disallow: /_next/image à ton fichier robots.ts pour empêcher Googlebot de crawler directement les URLs d'optimisation d'image. Les vraies images référencées dans les balises <img> de tes pages restent découvrables et indexables via le HTML de tes pages. Cela économise un budget de crawl significatif sur les sites riches en images.
Astuces pro
Tu as déployé une nouvelle app Next.js ou ajouté des routes dynamiques ? Google peut mettre des semaines à découvrir des pages rendues à la demande. Utilise IndexBolt pour pousser tes pages fraîchement construites directement dans la file d'indexation de Google — particulièrement critique pour les routes SSR et ISR qui n'ont aucune empreinte d'URL au moment du build.
100 crédits gratuits. Aucune carte bancaire requise. Résultats en moins de 24 heures.
Questions fréquentes
Googlebot exécute-t-il le JavaScript dans les applications Next.js ?+
Oui, Googlebot a un moteur de rendu JavaScript basé sur une version récente de Chromium. Cependant, le rendu JavaScript a lieu dans une **passe d'indexation secondaire** qui peut avoir lieu des heures voire des jours après le crawl HTML initial. Cela signifie que le contenu qui n'apparaît qu'après l'exécution de JavaScript est indexé avec un délai — et le fetch de données complexe côté client (en particulier vers des APIs authentifiées) peut échouer complètement dans l'environnement de rendu de Google. Pour une indexation fiable, assure-toi que tout le contenu critique est présent dans le HTML initial rendu côté serveur en utilisant des Server Components, getStaticProps ou getServerSideProps.
Devrais-je utiliser l'App Router ou le Pages Router pour un meilleur SEO ?+
L'**App Router** a un outillage SEO supérieur, incluant la Metadata API intégrée, sitemap.ts, robots.ts et les Server Components qui rendent le contenu côté serveur par défaut. Le **Pages Router** fonctionne bien pour le SEO mais demande plus de travail manuel : tu as besoin du composant next/head pour la metadata, de packages tiers comme next-sitemap pour les sitemaps, et getStaticProps/getServerSideProps pour le rendu côté serveur. Pour les nouveaux projets, l'App Router est le choix évident. Pour les projets Pages Router existants, il n'y a pas d'urgence à migrer — concentre-toi à t'assurer que tu as un bon getStaticProps/getServerSideProps en place et un sitemap qui fonctionne.
Comment l'ISR affecte-t-il l'indexation Google ?+
L'Incremental Static Regeneration est **excellent pour l'indexation**. Googlebot reçoit instantanément du HTML statique mis en cache (un temps de réponse rapide améliore l'efficacité du crawl), et le contenu se régénère en arrière-plan pour rester frais. La seule considération est la période de revalidation : si tu définis revalidate à 3600 (une heure), les changements de contenu peuvent prendre jusqu'à une heure pour apparaître dans la page cachée. Pour le contenu sensible au temps, utilise une période de revalidation plus courte ou déclenche la revalidation à la demande via des webhooks. Du point de vue de Google, les pages ISR se comportent identiquement aux pages statiques — elles sont rapides, entièrement rendues et fiables.
Mes pages Next.js affichent « Découverte, actuellement non indexée » dans Search Console. Pourquoi ?+
Ce statut signifie que Google a trouvé l'URL (via ton sitemap ou tes liens internes) mais ne l'a pas encore rendue ni indexée. Pour les apps Next.js, ça arrive couramment quand : (1) la page utilise du rendu côté client et le crawl HTML initial de Googlebot n'a trouvé aucun contenu, alors il a dépriorisé la page ; (2) la page a du contenu pauvre que Google considère comme de faible valeur ; (3) ton site est nouveau et Google n'a pas encore alloué assez de budget de crawl ; ou (4) la page a une balise canonique pointant ailleurs. Utilise l'outil Inspection d'URL pour récupérer la page comme Googlebot et examine le HTML rendu. S'il est vide ou montre un état de chargement, tu as un problème de rendu à corriger.
Comment gérer les URLs canoniques dans Next.js pour les pages avec des paramètres de requête ?+
Dans la Metadata API de l'App Router, définis `alternates: { canonical: "https://tondomaine.com/page" }` sans les paramètres de requête. Cela dit à Google que l'URL de base est la version canonique, quels que soient les paramètres de tracking, de pagination ou de filtre qui y sont ajoutés. Pour les pages où les paramètres de requête créent un contenu vraiment différent (comme des résultats de recherche paginés), soit tu génères des URLs canoniques uniques pour chaque page (`alternates: { canonical: "https://tondomaine.com/search?page=2" }`), soit tu utilises une canonique unique pointant vers la page 1 et tu t'appuies sur les liens internes pour que Google découvre les pages suivantes.
Puis-je utiliser IndexBolt avec Next.js pour accélérer l'indexation de nouvelles pages ?+
Absolument. IndexBolt est particulièrement précieux pour les applications Next.js parce que beaucoup de sites Next.js utilisent l'ISR ou le rendu à la demande, ce qui signifie que les nouvelles pages n'ont pas d'URLs statiques que Google découvre via le crawl traditionnel. Après avoir publié du nouveau contenu, utilise l'API ou le tableau de bord IndexBolt pour soumettre les URLs directement dans le pipeline d'indexation de Google. C'est particulièrement efficace pour les pages produits e-commerce générées à la demande, les nouveaux articles de blog dans un setup CMS headless, ou les pages d'atterrissage déployées dans le cadre d'un lancement de fonctionnalité. Le mode Normal fonctionne pour le contenu de routine ; utilise le mode Instant pour les lancements de produits ou les pages sensibles au temps.