URL canonique Next.js vers le mauvais domaine : les causes que nous avons testées

Lorsqu’une page Next.js génère une balise canonical pointant vers un ancien domaine, modifier metadataBase ne résout pas toujours le problème. Dans notre scénario utilisant une URL absolue, une base pourtant valide a laissé l’ancienne adresse intacte : il a fallu corriger alternates.canonical directement sur la page. Partez toujours de l’URL réellement émise par votre application, puis remontez jusqu’au réglage qui la fournit.

Ce que nous avons testé

Le 4 octobre 2026, nous avons monté un projet App Router dédié sous Next.js 15.5.22, React 19.2.6 et Node.js v25.2.1. Huit configurations ont été figées avant les mesures : un témoin valide et sept montages volontairement erronés. Chaque paire avant/après cohabite dans le même build de production et ne modifie qu’un seul paramètre de métadonnées ; le témoin demeure inchangé.

Nous avons interrogé chaque route à deux reprises — soit 32 réponses HTTP sur 16 URL —, puis inspecté les 16 documents rendus dans un navigateur. Chaque réponse a renvoyé un code 200 avec une seule balise canonical dans <head> ; les deux séries HTTP et le DOM concordaient parfaitement. Les sept anomalies injectées ont disparu après application de leur correctif respectif. Il s’agit d’un test de configuration contrôlé, et non d’une estimation de la fréquence de ces erreurs en production.

Les routes /cXX/before et /cXX/after isolent chaque cas de test. Leurs cibles canonical déclarées utilisent des domaines réservés example.com et des chemins produits de démonstration, distincts des URL locales du banc d’essai. L’ensemble du projet est balisé en noindex, nofollow.

Les huit configurations et les URL réellement émises

Un code HTTP 200 ne permettait pas de distinguer une configuration saine d’une configuration erronée : toutes les routes l’ont renvoyé. Contrôlez systématiquement l’URL canonique intégrale, chemin et préfixe de langue inclus. Dans le cas C04, Next.js a émis l’adresse d’accueil héritée sans barre oblique finale, ce qui restait une cible erronée pour la fiche produit.

Identifier le réglage responsable de la partie erronée

Mauvais domaine avec une URL canonique relative — C02, C05 et C08. Inspectez metadataBase dans le layout racine ainsi que dans les layouts imbriqués. Dans C05, la suppression de la surcharge imbriquée a laissé s’appliquer la base racine valide. Dans C08, une variable de build contrôlée injectait un domaine de prévisualisation ; lui substituer l’origine publique de production a corrigé la sortie.

Mauvais domaine avec une URL canonique absolue — C03. La page déclarait déjà une URL complète sur l’ancien domaine, qu’une metadataBase valide ne remplaçait pas. Modifiez cette valeur absolue — ou la fonction qui la génère —, puis inspectez à nouveau la balise émise.

Une fiche produit pointe vers la page d’accueil — C04. La page enfant héritait du canonical déclaré dans son layout parent. Définir un alternates.canonical propre à la page a rétabli le chemin produit attendu. Vérifiez tous les gabarits concernés au lieu de supposer qu’un réglage d’accueil deviendra spécifique à chaque route.

Bon domaine, mauvais chemin — C06 et C07. Un préfixe /catalog présent dans metadataBase subsistait dans l’URL finale bien que la valeur canonical commençât par /. Retirer ce préfixe parasite a corrigé C06, et rétablir le segment /fr manquant a corrigé C07. Conservez bien entendu tout préfixe requis par votre architecture réelle.

Un patron de configuration explicite à adapter

Pour un site servi à la racine de son domaine, déclarez l’origine de base dans le layout et le chemin relatif dans les métadonnées de chaque page. L’extrait ci-dessous reprend le patron corrigé du cas C02 : remplacez le domaine et le chemin d’exemple par votre URL publique cible (un site hébergé dans un sous-répertoire exigera sa propre convention de chemin).

// app/layout.tsx
export const metadata = {
  metadataBase: new URL("https://www.example.com"),
};

// app/products/widget/page.tsx
export const metadata = {
  alternates: { canonical: "/products/widget" },
};

Si votre page contient au contraire l’ancienne URL absolue illustrée ci-dessous, corriger le seul layout restera sans effet : dans C03, seule la mise à jour de ce champ canonical résout le problème.

// C03 — before
alternates: {
  canonical: "https://old.example.com/products/widget"
}

// C03 — after
alternates: {
  canonical: "https://www.example.com/products/widget"
}

Contrôler le build de production et le DOM du navigateur

1. Lancez un build de production avec la configuration d’origine publique prévue, et testez également l’URL déployée dès lors que l’hébergeur, un middleware ou un CDN peuvent modifier la réponse.
2. Enregistrez la réponse HTTP brute et inspectez les éléments <link rel="canonical"> dans <head> : vérifiez l’attribut href complet, le nombre de balises et la présence éventuelle d’un en-tête HTTP Link fournissant une autre URL canonique.
3. Dans les outils de développement du navigateur, inspectez le document rendu : l’expression console ci-dessous liste les balises et leur emplacement. Tout écart entre le HTML brut et le DOM appelle un diagnostic séparé.
4. Rejouez ces vérifications après correction sur des fiches détail, des routes imbriquées et des pages traduites — pas uniquement sur la page d’accueil — en consignant l’URL observée en regard de la cible attendue.

Array.from(document.querySelectorAll('link[rel="canonical"]'))
  .map(link => ({
    href: link.getAttribute("href"),
    inHead: link.closest("head") !== null
  }));

Le cas C08 teste une variable d’environnement de build, et non l’infrastructure de Vercel. La protection contre l’indexation des environnements de prévisualisation relève d’un sujet distinct : Vercel documente l’ajout par défaut d’un en-tête noindex sur ses previews ainsi qu’une exception pour les domaines personnalisés rattachés à une branche hors production. Inspectez toujours les en-têtes réels de votre déploiement avant d’en tirer une conclusion liée à l’hébergeur.

• Vercel : indexation des déploiements preview

Ce que cette expérience ne permet pas de conclure

Ces résultats portent sur une version logicielle précise, des exports statiques de métadonnées et un serveur de production local : nous n’avons testé ni le streaming de métadonnées, ni le Pages Router, ni l’ensemble des plateformes de déploiement. Émettre l’URL canonique attendue ne garantit ni que Google la retiendra, ni qu’il indexera la page ou améliorera son positionnement. Google décrit la canonicalisation comme un arbitrage fondé sur de multiples signaux ; contrôlez séparément l’URL retenue dans la Search Console.

• Documentation métadonnées Next.js 15
• Google : consolider les URL dupliquées (canonical)

Données, banc d’essai et consignes de reproduction

Reproduction complémentaire le 13 octobre 2026 : nous avons figé à l’identique le banc d’essai archivé dans un commit Git avant de le recompiler. Les 32 relevés HTTP de balises canonical et les 16 inspections du DOM ont exactement reproduit les résultats initiaux. L’archive téléchargeable inclut ces preuves datées séparément, sans modifier l’étude du 4 octobre.

Le dossier de preuves rassemble le protocole figé, les empreintes des fichiers sources, les résultats observés et un banc d’essai exécutable. Le collecteur automatise les contrôles HTTP, tandis que l’inspection dans le navigateur fait l’objet d’une étape documentée à part. Les dépendances directes sont figées, mais l’archive autonome ne verrouille pas l’intégralité des dépendances transitives.

• Résultats observés · JSON
• Méthode et étapes de reproduction · TXT
• Banc d’essai, collecteur et preuves initiales · ZIP

Lorsque l’anomalie touche plusieurs gabarits

Formalisez un ticket précis : URL concernée, balise canonical émise, cible attendue, réglage responsable et test de relecture. Si le problème traverse plusieurs layouts, routes traduites ou variables de déploiement, notre audit SEO Next.js cartographie ces dépendances et livre un plan de correctifs priorisé.

• Audit SEO Next.js : périmètre et livrables
• Contrôles d’indexation Google pour Next.js

Si vos balises de métadonnées apparaissent dans <body>, notre expérience Next.js sur neuf conditions distingue le HTML reçu du DOM navigateur et confronte l’emplacement de la balise canonical aux exigences de Google.

• Métadonnées Next.js dans le body : neuf conditions testées

• Indexation Google : diagnostiquer l’étape suivante