Configurer l’API Metadata Next.js : titres, URL canoniques et Open Graph

Utilisez l’API Metadata Next.js 16 pour les modèles de titres, URL canoniques, métadonnées dynamiques, visuels Open Graph et pages App Router alimentées par des données.

Équipe Adios16 juillet 2026Mise à jour 17 juillet 20269 min de lecture

Les métadonnées deviennent fiables lorsqu'elles proviennent des mêmes données de route et règles d'URL que la page visible. La duplication de cette logique dans un deuxième système côté client crée une dérive.

Utiliser les métadonnées comme données de route

Le titre, la description, l’URL canonique et l’image sociale décrivent une ressource précise. Générez-les près de la route qui la gère. Le layout racine fournit les valeurs stables par défaut du site ; les layouts imbriqués définissent les conventions de section ; les pages gèrent les valeurs propres à l’entité.

Cette hiérarchie réduit les répétitions et rend le titre final prévisible. Elle évite aussi de confier les métadonnées à un composant client après la première réponse. Les exports de métadonnées fonctionnent dans les Server Components, à la bonne limite pour l’accès aux données privées et les décisions d’URL canonique.

Définir de bonnes valeurs par défaut à la racine

Définissez metadataBase sur l’origine de production, puis utilisez des chemins relatifs pour les URL canoniques et images. Définissez le modèle de titre une seule fois, afin que les pages enfants ne fournissent que la partie pertinente. Les valeurs par défaut doivent être exactes pour les routes qui ne les remplacent pas, plutôt qu’un remplissage copié partout.

Gardez le nom du site stable dans les titres, visuels de partage et données structurées. Si staging et production nécessitent des origines publiques différentes, déterminez l’origine autorisée depuis la configuration de déploiement et échouez clairement si elle manque plutôt que d’émettre discrètement des URL localhost.

export const metadata = {
  metadataBase: new URL(process.env.NEXT_PUBLIC_SITE_URL),
  title: {
    default: "Northstar",
    template: "%s | Northstar",
  },
  openGraph: {
    siteName: "Northstar",
    type: "website",
  },
};

Générer les métadonnées des routes dynamiques

generateMetadata reçoit des paramètres de route asynchrones dans les projets App Router actuels. Récupérez l’entité, renvoyez un titre explicite de ressource introuvable si elle manque et construisez l’URL canonique depuis son slug durable. N’utilisez pas directement un nom d’affichage dans l’URL si les mêmes règles de création de slug n’ont pas créé la route.

La page et les métadonnées nécessitent souvent le même enregistrement. Enveloppez la fonction de données avec React cache pour la dédupliquer dans un passage de rendu, ou utilisez un cache persistant adapté si la durée de vie du contenu le justifie. L’objectif est une source de vérité unique, plutôt que deux appels API indépendants pouvant diverger.

import { cache } from "react";

const getPost = cache(async (slug: string) => {
  return db.post.findUnique({ where: { slug, published: true } });
});

export async function generateMetadata({ params }) {
  const { slug } = await params;
  const post = await getPost(slug);
  if (!post) return { title: "Article not found" };

  return {
    title: post.title,
    description: post.excerpt,
    alternates: { canonical: "/blog/" + post.slug },
  };
}

Écrire les règles canoniques avant le code

Décidez si le site utilise www, comment traiter les slashs finaux, quelle langue correspond à la page et si les filtres créent des ressources distinctes. Alignez ensuite les redirections, liens internes, URL du sitemap et métadonnées. Des URL canoniques assemblées séparément dans chaque page finiront par diverger.

Si le slug du contenu change, redirigez l’ancienne URL vers la nouvelle URL canonique et conservez un identifiant durable en base. Pour un contenu supprimé, décidez s’il existe un remplacement pertinent ; sinon, renvoyez un vrai 404 ou 410 plutôt qu’une page soft-404 avec un statut de succès.

—Une origine et un protocole privilégiés.
—Une règle unique pour les slashs finaux.
—Des variantes linguistiques explicites lorsque les pages traduites existent réellement.
—Un plan de redirection pour les slugs modifiés et les contenus retirés.

Créer des visuels de partage adaptés à la page

Les champs Open Graph et Twitter doivent utiliser le titre, une description concise et une image lisible après recadrage. Une image générique du site peut servir de secours, mais des visuels propres à l’entité sont utiles aux articles et produits. Fournissez les dimensions et un texte alt pertinent.

Les images statiques peuvent suivre la convention opengraph-image. Les routes dynamiques peuvent générer une image avec ImageResponse ou référencer celle de l’entité. Traitez la génération d’images comme du code de production : validez les titres longs, images absentes, chargements de polices et coûts d’exécution.

return {
  openGraph: {
    type: "article",
    title: post.title,
    description: post.excerpt,
    images: [{
      url: post.ogImage,
      width: 1200,
      height: 630,
      alt: post.title,
    }],
  },
};

Gérer robots et les entités manquantes sur le serveur

Un brouillon, un enregistrement privé ou une page de recherche interne ne doit pas devenir indexable sous prétexte que le navigateur le masque ensuite. Renvoyez les bonnes métadonnées et le bon statut depuis le serveur. Si une entité n’est pas publique, ne révélez pas son titre ni sa description dans les métadonnées avant le contrôle d’autorisation.

Les métadonnées robots ne contrôlent pas l’accès. Les routes privées exigent toujours authentification et autorisation. Pour les liens publics d’aperçu, utilisez des identifiants impossibles à deviner, noindex et des règles claires de cycle de vie, puis vérifiez l’absence de ces aperçus dans le sitemap et la navigation interne.

Tester le document rendu

Examinez le head dans le navigateur, mais récupérez aussi la réponse brute et consultez le code source. Confirmez que le titre final, la description, l’URL canonique, la directive robots, les valeurs Open Graph et le JSON-LD sont corrects pour une requête directe. Testez une entité connue, une entité manquante, un brouillon et un slug modifié.

Automatisez les éléments stables. Un test de bon fonctionnement de route peut vérifier le statut, l’URL canonique, un fragment du titre et l’absence d’origines d’aperçu. Gardez la revue de qualité du contenu humaine : un test prouve qu’une description existe, pas qu’elle est utile.

Vérifier les métadonnées avant la promotion du domaine

Déployez la candidate sur une route HTTPS générée par Adios et examinez son head avec la compilation de production. Gardez l’origine publique du site dans une configuration vérifiable et les valeurs sensibles du prestataire derrière des références aux secrets. Les journaux de compilation et d’exécution restent associés à la candidate si la génération des métadonnées échoue.

Une fois la version opérationnelle et ses métadonnées correctes, associez ou conservez le domaine personnalisé canonique. Le TLS géré et la promotion des versions gardent le nom d’hôte public associé à la version qui a réussi les contrôles, sans devoir modifier le DNS à chaque publication de contenu.

env:
  NEXT_PUBLIC_SITE_URL: https://www.example.com

runtime:
  name: node@24
  port: 3000
  health_path: /api/health

Tous les articles