Frontmatter de contenu : champs et métadonnées SEO

Le frontmatter est l’élément de page que les lecteurs ne voient jamais comme un bloc et dont tout système de publication dépend. Il donne à un document une identité, un contrat de rendu, un aperçu de recherche, un enregistrement de propriété, des dates et des entrées de schéma. Un frontmatter défectueux peut sélectionner le mauvais modèle, créer des conflits canoniques, perdre l’auteur ou émettre un balisage qui contredit la page.

Le spécimen concret est un enregistrement au niveau du document, présenté sous forme de code car le frontmatter ne doit pas devenir un bloc décoratif dans le corps.

+++
entity = "guide-how-to"
id = "reset-api-key"
title = "How to Reset an API Key"
seoTitle = "How to Reset an API Key Safely"
description = "Reset an API key safely, replace it in every dependent service, verify the new credential, and revoke the exposed key without avoidable downtime."
url = "/academy/reset-an-api-key/"
image = "/images/academy/reset-api-key.png"
imageAlt = "API key settings with the Rotate key action highlighted"
date = "2026-08-27 10:00:00"
updated = "2026-09-03 14:30:00"
author = "maya-chen"
reviewedBy = "alex-rivera"
keywords = [ "reset API key", "rotate API key", "revoke API key" ]
taxonomy = [ "security", "account-administration" ]
canonical = "https://amicited.com/academy/reset-an-api-key/"

[[faq]]
question = "Does rotating an API key revoke the old key immediately?"
answer = "Not necessarily. Confirm the provider's rotation behavior before changing dependent services."
+++

Pourquoi le frontmatter existe

Pour un lecteur, les métadonnées réduisent l’incertitude. Un titre précis définit le périmètre, une description utile mérite le clic, les identités rendent les affirmations imputables et les dates révèlent si l’information a pu vieillir. Ces signaux ne peuvent pas compenser un contenu faible, mais leur absence oblige le lecteur à deviner.

Pour les machines, le frontmatter remplace l’inférence par des valeurs nommées. Les modèles mappent les champs vers les titres de navigateur, les liens canoniques, les fiches personnes, les dates, les flux, les index et le JSON-LD sans avoir à analyser le texte en prose. C’est l’extractibilité machine : les faits importants ont un emplacement et un type cohérents.

Suivez les règles de rédaction des éléments : les métadonnées appartiennent au niveau du document ; les éléments destinés aux lecteurs appartiennent au corps. Une signature peut être générée à partir du frontmatter, mais son identifiant faisant autorité y reste.

Quand l’utiliser — et quand ne pas l’utiliser

Chaque page indexable a besoin d’un enregistrement de frontmatter pour l’identité, le rendu et le routage. Les brouillons en ont besoin lorsqu’ils entrent en production afin que la validation puisse échouer rapidement.

Ne cachez pas les faits d’un article dans le frontmatter. Les limitations de produit, les avertissements de sécurité, les divulgations d’affiliation, les méthodes et les sources doivent rester visibles là où les lecteurs peuvent les évaluer. Une valeur structurée ne remplace jamais une divulgation.

Les erreurs de justesse causent le plus de dégâts :

• Des étiquettes de navigation, des textes promotionnels et des légendes sociales qui varient indépendamment sont des paramètres de canal ; ne surchargez pas le champ title.
• Les faits organisationnels partagés sur l’ensemble du site appartiennent à l’enregistrement organisationnel du site, pas copiés dans chaque page où ils divergeront.
• Une section de questions-réponses appartient à [[faq]] seulement lorsque le même contenu est rendu visible. Une FAQ cachée uniquement dans le schéma est invalide.
• Une étiquette de sujet appartient à taxonomy ; elle ne doit pas remplacer l’entity qui identifie le type de publication du document.
• Une redirection appartient à la configuration de routage ou à un champ d’alias approuvé. Le canonical identifie la version préférée ; il ne redirige pas les visiteurs.

Où le placer

Le frontmatter commence au premier octet avec +++ et se termine à la délimitation correspondante avant le corps. Aucun en-tête, commentaire, note, shortcode ou bloc de métadonnées ne peut le précéder. Les champs et tableaux TOML appartiennent à l’intérieur de cet enregistrement unique.

Le corps commence après la délimitation fermante. Le frontmatter ne peut pas se situer entre le H1 et l’introduction, à côté d’une capture d’écran, à l’intérieur d’un composant ou à la fin. Un byte-order mark ou un commentaire parasite peut empêcher sa reconnaissance. Les clés en double, les délimitations YAML et les seconds blocs sont invalides.

Anatomie

La légende rendue reste dans la page afin de rester lisible et traduisible indépendamment de l’image :

1. Délimitation : les délimitations ouvrantes et fermantes +++ définissent la seule région de métadonnées.
2. Identité : entity, id, type et url indiquent aux systèmes ce qu’est le document et où il se trouve.
3. Découverte : title, seoTitle, description, image, imageAlt et keywords prennent en charge les aperçus et la récupération.
4. Provenance : date, updated, author et reviewedBy indiquent qui est responsable et quand le travail a été valablement modifié.
5. Classification : taxonomy relie la page à des collections de sujets contrôlées sans redéfinir son identité.
6. Contrôle des doublons : canonical nomme l’URL publique préférée lorsque des versions équivalentes sont accessibles ailleurs.
7. Collections structurées : chaque [[faq]] crée un enregistrement typé de question-réponse pour le rendu visible et le schéma.

Exemples de conception

Le frontmatter a des variantes de contrat de données, pas des styles visuels. Les captures d’écran associent les enregistrements sources à leur aperçu ou signature résultant.

Paramètres

Ce sont des limites éditoriales même si un analyseur accepte davantage. « Conditionnel » signifie requis lorsque sa condition énoncée est vraie.

Référence par champ

Cette référence définit le contrat de publication pour chaque champ. « Requis » signifie que la validation doit empêcher la publication lorsque le champ ou sa dérivation valide est absent. « Conditionnel » signifie que l’exigence est activée par un fait énoncé, comme le rendu d’une image ou la réalisation d’une révision indépendante. Une valeur par défaut n’est sûre que lorsqu’elle produit la même signification qu’un éditeur aurait choisie délibérément.

Identité et routage

title, h1 et seoTitle

• Objectif — title donne au document son nom éditorial durable. h1 contrôle le titre principal de la page lorsque le contexte de mise en page nécessite un libellé différent. seoTitle contrôle le titre du navigateur/de la recherche lorsque le défaut a besoin d’un qualificatif concis ou d’un traitement de marque. Les séparer empêche qu’une étiquette de navigation, un titre de page et un aperçu de recherche soient forcés dans une seule chaîne maladroite.
• Type et format — Chacun est une chaîne en texte brut. title est la valeur source ; les remplacements absents doivent revenir à celle-ci. Le HTML, le Markdown, les décorations par emoji et les marques de troncature manuelle ne sont pas des valeurs valides.
• Requis ? — title est requis sur chaque page publique. h1 et seoTitle sont optionnels et doivent être omis lorsque title fonctionne dans les trois contextes.
• Limites — Utilisez 30–70 caractères pour title, 20–80 pour h1 et 30–60 pour seoTitle comme bandes éditoriales, et non comme une promesse qu’une interface de recherche affichera chaque caractère. Il doit y avoir un seul H1 rendu.
• Qui ou quoi le consomme — Modèles de page, titres de navigateur, adaptateurs de recherche et de réseaux sociaux, cartes de navigation, flux, headline du schéma, plans d’accessibilité et listages éditoriaux.
• Règles — Toutes les versions doivent identifier le même sujet, la même intention et le même périmètre. Une différence légitime résout une contrainte de canal : par exemple, le H1 peut dire « Comment faire pivoter une clé API sans temps d’arrêt », tandis que le titre SEO plus court dit « Rotation de clé API : guide étape par étape sécurisé ». La section Titre, H1 et titre SEO explique le test éditorial.
• Erreurs courantes — Répéter un mot-clé dans les trois variantes, mettre un suffixe de marque dans le H1, changer la promesse pour attirer les clics, intégrer l’année en cours alors que la page n’est pas maintenue annuellement, ou rédiger trois valeurs simplement parce que trois champs existent.

slug et url

• Objectif — Le slug est le dernier segment du chemin ; url est la route publique relative au site qui le contient. Ensemble, ils donnent à la page une adresse stable pour les lecteurs, les robots, les liens, les rapports et les migrations. La stabilité importe car chaque lien obtenu et chaque signet enregistré dépend de cette adresse.
• Type et format — Utilisez une chaîne de chemin en minuscules avec traits d’union, comme /academy/rotate-an-api-key/. Ce référentiel enregistre la route complète dans url ; un CMS qui a un champ slug séparé doit dériver le même segment final.
• Requis ? — Une route unique est requise pour chaque page publique. Elle peut être générée uniquement là où une section a une règle déterministe approuvée et des vérifications de collision ; les pages du playbook utilisent leurs valeurs url enregistrées.
• Limites — Préférez un slug court et lisible qui préserve le sujet distinctif, généralement trois à huit mots utiles. Supprimez la ponctuation et les modificateurs vides. Supprimez les mots vides comme « le » ou « un » uniquement lorsque le résultat reste naturel et non ambigu ; il n’y a pas de limite arbitraire de caractères qui justifie d’altérer le sens.
• Qui ou quoi le consomme — Routage Hugo, liens internes, fils d’Ariane, génération canonique, sitemaps, flux, analytiques, redirections et références externes.
• Règles — Traitez un slug publié comme un engagement permanent. Déterminez-le à partir du sujet durable, pas d’un titre de campagne ou d’une année transitoire. Lorsque le titre change mais que le sujet et l’intention ne changent pas, conservez l’ancien slug. Si la page change réellement d’adresse, créez la nouvelle route, conservez l’ancienne route dans aliases, mettez à jour les liens internes et testez la destination de redirection.
• Erreurs courantes — Régénérer le slug à chaque changement de titre, bourrer des synonymes dans le chemin, conserver des dates qui donnent un aspect obsolète à un contenu intemporel, utiliser des majuscules/minuscules mélangées ou des underscores, créer deux URL qui ne diffèrent que par une barre oblique finale, et changer une route sans préserver l’ancienne.

canonical

• Objectif — Un canonical identifie l’URL préférée parmi des versions équivalentes ou quasi équivalentes accessibles. Il consolide l’identité ; il ne déplace pas un visiteur et n’excuse pas une duplication incontrôlée.
• Type et format — Une URL absolue HTTPS, incluant l’hôte prévu et le chemin normalisé : https://amicited.com/academy/rotate-an-api-key/. Le modèle peut dériver une auto-référence à partir du permalien de la page lorsque le site a une seule politique d’hôte et de route digne de confiance.
• Requis ? — Chaque page indexable doit émettre un canonical. Le champ lui-même est conditionnel lorsqu’une valeur d’auto-référence correcte est dérivée automatiquement ; définissez-le explicitement pour un canonical inter-domaines ou exceptionnel approuvé.
• Limites — Exactement une cible canonique. La cible doit renvoyer un document indexable réussi, utiliser le protocole et l’hôte préférés, et représenter sensiblement le même contenu.
• Qui ou quoi le consomme — Le <link rel="canonical"> HTML, les moteurs de recherche, les vérifications de sitemap et de liens internes, les rapports de déduplication et les identifiants d’URL de schéma.
• Règles — Auto-référence par défaut. Utilisez un canonical inter-domaines uniquement lorsqu’un autre éditeur possède l’équivalent préféré et que les deux parties souhaitent une consolidation. Utilisez une redirection, pas un canonical, lorsque l’ancienne URL a été remplacée et que les utilisateurs doivent toujours atterrir sur la nouvelle. Maintenez l’alignement entre le canonical, l’URL du sitemap, le hreflang, les liens internes et l’identité du schéma.
• Erreurs courantes — Pointer chaque page paginée ou localisée vers un parent générique, canonicaliser un contenu distinct, cibler une redirection ou une page d’erreur, mélanger HTTP et HTTPS, utiliser le champ comme substitut d’un alias, et supposer que les directives canoniques sont garanties d’être respectées.

aliases

• Objectif — aliases préserve les routes qui identifiaient auparavant la même page, afin qu’un déplacement ne transforme pas les liens existants et les signets en impasses. Il enregistre l’historique des routes plutôt que de créer des identités indexables alternatives.
• Type et format — Un tableau TOML de chemins relatifs au site, par exemple aliases = [ "/blog/old-api-key-guide/" ]. Chaque valeur inclut une barre oblique au début et à la fin et doit être unique sur l’ensemble du site.
• Requis ? — Optionnel pour une nouvelle page ; requis chaque fois qu’une page publiée est déplacée d’un chemin que le site contrôlait.
• Limites — Incluez chaque ancien chemin connu de première partie qui reçoit encore des liens ou du trafic. N’ajoutez pas de variantes orthographiques spéculatives ou une liste illimitée d’URL de mots-clés.
• Qui ou quoi le consomme — La sortie d’alias de Hugo, le traitement des redirections de déploiement là où il est configuré, la QA de migration, les moniteurs de liens et les utilisateurs suivant d’anciennes URL. Comme Hugo peut émettre une page d’alias plutôt qu’une redirection HTTP au niveau de l’origine, le comportement de déploiement doit être vérifié plutôt que supposé.
• Règles — Une page déplacée maintient le fonctionnement de son ancien chemin. Chaque alias doit se résoudre en un saut vers la route canonique actuelle. Mettez à jour les liens internes vers la nouvelle URL même lorsque l’alias fonctionne, et préservez l’alias lors des modifications ultérieures à moins qu’un système de redirection documenté ne le remplace.
• Erreurs courantes — Supprimer l’ancienne page sans alias, chaîner l’ancien chemin vers un chemin intermédiaire vers le chemin actuel, traiter les alias comme des routes de publication en double, pointer plusieurs pages sans rapport vers une destination pratique, ou supposer que la sortie locale de Hugo prouve le statut HTTP de production.

type et layout

• Objectif — Ces champs sélectionnent le contrat de rendu. type place une page dans une classe de contenu avec des modèles et un comportement partagés ; layout demande un modèle spécifique au sein de cette classe. Une sélection correcte garantit que la page reçoit la navigation, l’emplacement de contenu, les assets et le comportement de schéma prévus.
• Type et format — Chaînes enregistrées en minuscules. Cette page utilise type = "academy". Une valeur layout est un nom de base de modèle tel que single, sans extension de fichier ni traversée de chemin.
• Requis ? — type est requis lorsque l’emplacement du contenu n’implique pas de manière sûre le type prévu ou lorsque le contrat du playbook l’impose. layout est optionnel et doit être omis lorsque le modèle par défaut du type est correct.
• Limites — Une valeur pour chaque champ, choisie uniquement parmi les modèles maintenus par le site. Une nouvelle valeur est un changement d’ingénierie, pas une improvisation éditoriale.
• Qui ou quoi le consomme — L’ordre de recherche de Hugo, les modèles, la sélection partielle, l’inclusion CSS et JavaScript, les adaptateurs de schéma et les règles de validation.
• Règles — Choisissez le type de publication et le contrat de rendu avant la rédaction. Utilisez layout uniquement pour une variante légitime prise en charge ; ne l’utilisez pas pour compenser un contenu qui appartient à un autre type. Vérifiez qu’une substitution existe et accepte la structure du frontmatter de la page.
• Erreurs courantes — Confondre l’entity éditoriale avec le type Hugo, nommer un fichier de modèle qui n’existe pas, copier un type de page d’atterrissage sur un document d’académie, se fier à l’inférence de dossier lors d’une migration, et introduire des noms de layout ponctuels qui contournent les améliorations partagées.

Découverte

description

• Objectif — La description aide un chercheur qualifié ou un destinataire de partage à décider si cette page répond au besoin. C’est un texte d’aperçu, pas une introduction condensée et pas un lieu pour prouver la pertinence par la répétition.
• Type et format — Une phrase en texte brut. Elle doit nommer le terme principal naturellement, énoncer la valeur concrète et ajouter un périmètre, un public, une méthode ou un résultat utile.
• Requis ? — Requis pour chaque page indexable dans ce playbook.
• Limites — 150–160 caractères, espaces inclus. C’est une bande de cohérence éditoriale, pas une garantie d’affichage : les moteurs de recherche peuvent la tronquer ou réécrire l’extrait à partir du contenu du corps lorsqu’un autre passage correspond mieux à la requête.
• Qui ou quoi le consomme — Balises méta-description, descriptions par défaut Open Graph et Twitter, cartes de listage, flux, aperçus CMS, vérifications de qualité de recherche, et parfois description du schéma.
• Règles — Rédigez pour un clic du bon lecteur. Rendez la phrase suffisamment spécifique pour distinguer la page d’un autre résultat avec un titre similaire. La section Règles de description ci-dessous donne la justification et les tests de rejet.
• Erreurs courantes — Dupliquer le titre, lister des mots-clés, commencer par « Découvrez tout sur », faire une affirmation non étayée de meilleur ou plus rapide, utiliser un appel à l’action vague, dépasser la bande à cause d’un suffixe de marque invisible, ou supposer que le texte rédigé doit apparaître textuellement dans les résultats de recherche.

keywords

• Objectif — Dans ce référentiel, keywords enregistre l’ensemble compact de requêtes et de terminologie utilisé pour la QA éditoriale, la recherche dans le corpus, l’analyse de couverture et les outils internes. Il aide les éditeurs à reconnaître le langage qu’une page doit utiliser avec précision ; ce n’est pas une promesse d’inclure chaque phrase mécaniquement.
• Type et format — Un tableau de chaînes en langage naturel, ordonnées du terme principal aux variantes significatives et à la terminologie étroitement liée.
• Requis ? — Requis selon ce playbook, y compris pour les pages dont les modèles publics ne restituent pas les valeurs.
• Limites — Six à huit entrées distinctes. Chaque entrée doit représenter une phrase de requête réelle ou un terme nécessaire, pas une variation au niveau du token.
• Qui ou quoi le consomme — Validateurs éditoriaux, inventaires de contenu, analyse de recherche et d’opportunité, récupération interne et outils de migration. Les moteurs de recherche publics n’utilisent pas ce champ comme signal de classement simplement parce qu’il existe.
• Règles — Gardez l’ensemble centré sur le périmètre d’une seule page. Fusionnez les doublons de casse, de ponctuation, de singulier/pluriel et d’ordre de mots trivial. Utilisez les phrases pour vérifier la couverture et la terminologie, jamais pour dicter une densité artificielle.
• Erreurs courantes — Traiter le champ comme le mécanisme obsolète de classement par méta-mots-clés, ajouter des dizaines de variantes, répéter le titre sous forme de huit quasi-doublons, insérer des noms de concurrents que le corps ne mentionne pas, et laisser le tableau remplacer une taxonomie appropriée ou des cibles de prompt.

targetPrompts

• Objectif — targetPrompts enregistre les questions ou demandes complètes qu’une personne peut donner à un système d’IA générative et pour lesquelles cette page devrait être une source utile. Les cibles de prompt préservent le contexte conversationnel que les phrases de mots-clés courtes omettent.
• Type et format — Un tableau de chaînes complètes en langage naturel, par exemple targetPrompts = [ "Comment faire pivoter une clé API sans temps d'arrêt ?", "Que dois-je vérifier avant de révoquer une ancienne clé API ?" ]. Conservez le libellé tel qu’un utilisateur le demanderait, y compris le public, les contraintes ou la comparaison souhaitée.
• Requis ? — Conditionnel pour les pages incluses dans le suivi de prompts ou un programme de visibilité IA ; optionnel lorsqu’aucun ensemble de prompts suivi n’existe.
• Limites — Utilisez un petit ensemble intentionnel, normalement un prompt principal et jusqu’à quatre variantes significatives. Un prompt peut être plus long qu’un mot-clé car ses qualificatifs portent l’intention.
• Qui ou quoi le consomme — Briefs de contenu, workflows de suivi de prompts, audits de récupération et de couverture, surveillance des réponses IA et évaluation éditoriale. Il n’est pas rendu comme texte de recherche caché.
• Règles — Séparez les prompts par besoin d’information réel, pas par ponctuation. Un mot-clé comme « rotation de clé API » nomme un sujet ; « Comment une équipe SaaS peut-elle faire pivoter une clé API sans interrompre les intégrations ? » nomme un public, une tâche et une contrainte. La page doit répondre honnêtement à chaque prompt stocké.
• Erreurs courantes — Copier le tableau de mots-clés dans ce champ, fabriquer des dizaines de variations syntaxiques, enregistrer des prompts plus larges que la page, utiliser des prompts comme titres de corps indépendamment du flux de lecture, et prétendre à une couverture de prompt alors que la réponse dépend d’informations que la page ne fournit pas.

Confiance et provenance

date et updated

• Objectif — date préserve la date de première publication de la page ; updated indique la dernière modification substantielle ou révision achevée. Deux champs préservent l’historique tout en montrant si les informations sur lesquelles les lecteurs s’appuient ont changé.
• Type et format — Chaînes d’horodatage selon la convention du site, YYYY-MM-DD HH:MM:SS. Gardez une politique de fuseau horaire cohérente dans l’ensemble du corpus afin que les flux et les comparaisons restent déterministes.
• Requis ? — date est requis pour les pages éditoriales publiées. updated est optionnel jusqu’à ce qu’un changement qualifiant se produise, puis requis si la page présente une date modifiée.
• Limites — Une valeur chacun. updated ne peut pas précéder date ni se situer dans le futur. Une correction effectuée quelques minutes après la publication peut encore être documentée, mais les révisions de routine d’un brouillon avant publication ne créent pas de date de mise à jour.
• Qui ou quoi le consomme — Signatures visibles et indicateurs de fraîcheur, flux, sitemaps, datePublished et dateModified du schéma, audits de récence, tri et files d’attente éditoriales.
• Règles — Réinitialisez updated pour une correction factuelle, une instruction modifiée, des preuves nouvelles ou supprimées, un périmètre révisé, une recommandation matériellement modifiée, ou une révision documentée d’affirmations sensibles au temps. Ne le réinitialisez jamais pour de la ponctuation, du formatage, un travail de modèle ou une modification d’horodatage uniquement. Voir Dates, auteurs et relecteurs pour la justification de la politique.
• Erreurs courantes — Écraser la date originale lors d’une mise à jour, antidater une page pour la faire paraître récente, augmenter les dates sans diff de contenu, traiter un déploiement automatisé comme une mise à jour éditoriale, et ne pas enregistrer ce qui a changé dans l’historique des mises à jour maintenu.

author

• Objectif — author relie le document à l’entité personne responsable de son travail. Le lien donne au lecteur et à la machine un chemin depuis une page porteuse d’affirmations vers une identité, une expertise et d’autres travaux maintenus.
• Type et format — Un identifiant d’auteur stable qui se résout via le registre des auteurs du site vers une URL de profil et un enregistrement Personne. Par exemple, author = "maya-chen" est valide uniquement si cet identifiant se résout ; un nom d’affichage comme "Maya Chen, Experte SEO" n’est pas un substitut au lien d’entité.
• Requis ? — Requis pour les pages éditoriales substantielles. Les pages transactionnelles peuvent utiliser un propriétaire organisationnel gouverné uniquement lorsque le modèle et la politique prennent en charge ce type d’entité.
• Limites — Un responsable principal par défaut ; utilisez un tableau d’identifiants documenté uniquement lorsque le schéma et les modèles de signature prennent en charge une véritable co-écriture.
• Qui ou quoi le consomme — Signatures visibles, liens de profil d’auteur, schéma Article, flux, rapports de propriété éditoriale, workflows de révision et graphes d’entités.
• Règles — Résolvez l’identifiant avant publication. Le profil doit identifier la même personne que celle montrée dans la signature et rester maintenu. Créditez la personne responsable du contenu, pas celle qui l’a simplement téléchargé.
• Erreurs courantes — Saisir un nom non lié, utiliser « Admin » ou une équipe éditoriale inventée, attribuer un cadre éminent qui n’a pas écrit le travail, permettre à un identifiant de se résoudre en l’absence de profil, et changer la paternité pour suggérer une expertise qui n’a pas été impliquée.

reviewedBy, reviewedAt et reviewScope

• Objectif — Ces champs enregistrent une révision indépendante distincte de la paternité. reviewedBy identifie l’entité de révision ; reviewedAt indique quand la révision a été achevée ; reviewScope précise ce que le relecteur a vérifié, afin que le badge n’implique pas une approbation au-delà des preuves.
• Type et format — reviewedBy est un identifiant stable se résolvant vers un profil de personne maintenu. reviewedAt utilise le format d’horodatage du site. reviewScope est un énoncé concis en texte brut comme « Étapes de rotation des identifiants et précautions de sécurité ».
• Requis ? — Conditionnel lorsque la loi, la politique de risque, la sensibilité du sujet ou la spécification du type de publication exige une révision indépendante. Lorsque reviewedBy est présent, la date et le périmètre de révision sont requis comme données d’enregistrement de révision, même si un modèle particulier les stocke dans un enregistrement éditorial connecté plutôt que dans le frontmatter public.
• Limites — Nommez uniquement les relecteurs réels. Le périmètre doit être suffisamment spécifique pour révéler les exclusions sans devenir un rapport de révision. Un relecteur doit avoir une compétence pertinente et ne doit pas simplement dupliquer le rôle d’auteur.
• Qui ou quoi le consomme — Composants « Revue par », jointures d’entités personne, audits de gouvernance, portes de publication à haut risque, provenance structurée et journaux de mise à jour.
• Règles — Effectuez la révision après que le contenu est stable, capturez les conclusions et la résolution dans l’historique éditorial, et révisez lorsque des modifications ultérieures affectent le périmètre révisé. Indépendant signifie que le relecteur teste le travail plutôt que d’approuver son propre brouillon.
• Erreurs courantes — Traiter la révision éditoriale comme une révision experte, afficher un relecteur sans date ni périmètre, nommer quelqu’un qui n’a jamais vu la version finale, laisser le badge après une réécriture matérielle non révisée, et suggérer une approbation légale, médicale ou technique en dehors du périmètre déclaré.

Média et social

image et imageAlt

• Objectif — image sélectionne l’asset principal et social représentatif ; imageAlt fournit l’alternative textuelle fonctionnelle lorsque cet asset est rendu comme contenu de page significatif. Garder la paire ensemble empêche l’imagerie de découverte de devenir une omission d’accessibilité.
• Type et format — image est un chemin de site résoluble ou une URL absolue approuvée. imageAlt est un texte brut décrivant l’information utile de l’image dans son contexte de page, pas son nom de fichier ou son mot-clé cible.
• Requis ? — Conditionnel selon le type de publication et le modèle. Si la page nécessite une image principale ou une image sociale dédiée, image est requis. imageAlt est requis chaque fois que cette image est rendue de manière informative ; un rendu purement décoratif doit utiliser un attribut alt vide dans le modèle, pas un texte descriptif inventé.
• Limites — Utilisez un asset représentatif. Pour la compatibilité sociale, fournissez une source de 1200 × 630 pixels dans le ratio de recadrage attendu, éloignez le contenu important des bords et gardez imageAlt concis — normalement 5–160 caractères. Le fichier doit exister avant d’être référencé.
• Qui ou quoi le consomme — Composants principaux, cartes de listage, balises Open Graph et Twitter, champs d’image de schéma, flux, pipelines d’images, lecteurs d’écran lorsqu’il est visible, et QA d’assets.
• Règles — Choisissez une image qui reste communicative après un recadrage centré et à la taille d’une vignette. Décrivez sa fonction dans son contexte : « Paramètres de clé API avec l’action Rotation de clé mise en évidence » est utile ; « Clé API » ne l’est pas. Ne placez pas d’affirmations essentielles uniquement dans les pixels.
• Erreurs courantes — Référencer un asset prévu qui n’existe pas, utiliser un logo comme image de chaque article, intégrer un petit texte qui devient illisible dans les partages, écrire « image de », bourrer des mots-clés dans le texte alternatif, et supposer que le texte alternatif social et le texte alternatif d’image visible se comportent de manière identique sur toutes les plateformes.

Champs Open Graph et Twitter Card

• Objectif — Les métadonnées sociales contrôlent la façon dont une URL est résumée lors du partage. Un titre, une description, une URL, un type et une image cohérents aident les destinataires à reconnaître la page avant de cliquer et réduisent la probabilité qu’une plateforme sélectionne un asset non pertinent.
• Type et format — Dans ce référentiel, les modèles dérivent og:title et twitter:title de title, les descriptions de description, les URLs du permalien, og:type du contexte de mise en page, et les deux balises d’image de image avec un repli du site. twitter:card est émis comme summary_large_image. Ce sont des balises générées, pas des champs de frontmatter en double par défaut.
• Requis ? — Les balises de sortie sont requises sur les pages publiques. Les substitutions séparées sont optionnelles et ne doivent être introduites que via un contrat de modèle documenté ; les champs ad hoc non pris en charge comme ogTitle ne font rien.
• Limites — Un aperçu cohérent par page et une image représentative de 1200 × 630. Gardez le libellé dérivé dans les bandes de titre et de description, puis testez le comportement réel de recadrage et de superposition sur les principales surfaces de partage.
• Qui ou quoi le consomme — Réseaux sociaux, clients de messagerie, déplieurs de liens, extensions de navigateur, outils de collaboration et débogueurs d’aperçu de partage.
• Règles — Préférez la dérivation afin que les affirmations de recherche et sociales restent alignées. Ne remplacez que lorsque le contexte social a réellement besoin d’un cadrage différent et que le modèle le prend en charge. Une mauvaise image coûte en reconnaissance et en confiance : le destinataire peut voir une interface obsolète, un autre produit, une affirmation trompeuse ou un recadrage qui cache le sujet.
• Erreurs courantes — Rédiger des champs qu’aucun modèle ne lit, permettre à un repli global de masquer un élément principal requis manquant, utiliser un portrait ou une petite image pour une carte large, modifier le texte social pour faire une promesse plus forte que la page, et valider uniquement la source HTML plutôt qu’un aperçu récupéré.

Classification

taxonomy, categories et tags

• Objectif — La classification relie une page à des collections gouvernées de sujets, formats, publics ou produits. Elle alimente des archives et des filtres utiles uniquement lorsque chaque vocabulaire a une signification déclarée ; sinon les étiquettes deviennent un tas de synonymes incontrôlé.
• Type et format — Tableaux de slugs enregistrés en minuscules. Utilisez taxonomy pour le vocabulaire de sujet contrôlé du référentiel. Utilisez categories uniquement pour une petite hiérarchie éditoriale mutuellement compréhensible et tags uniquement pour un vocabulaire transversal gouverné lorsque ces taxonomies sont configurées.
• Requis ? — Conditionnel selon le type de publication et la conception des archives. Les pages éditoriales porteuses de sujet nécessitent normalement un ou plusieurs termes contrôlés ; les pages utilitaires peuvent n’en nécessiter aucun. Un champ ne doit pas être rempli simplement parce qu’un CMS l’expose.
• Limites — Pour la taxonomie générale, une à cinq valeurs par vocabulaire contrôlé. Chaque terme a besoin d’une définition, d’un propriétaire et d’une règle de fusion. Créez une archive indexable uniquement lorsque le terme représente une demande durable des lecteurs et que l’archive peut offrir une introduction unique, un inventaire cohérent, des liens internes et une maintenance continue.
• Qui ou quoi le consomme — Pages d’archive, fils d’Ariane, filtres, systèmes de contenu connexe, navigation à facettes, audits de contenu et segmentation analytique.
• Règles — Choisissez le terme enregistré le plus étroit qui regroupe précisément la page. Gardez les singuliers/pluriels, les abréviations et les variantes orthographiques mappés à une valeur canonique. Décidez si les archives sont indexables au niveau du vocabulaire, pas balise par balise après une création accidentelle.
• Erreurs courantes — Utiliser seo, SEO, search-optimization et search engine optimization comme valeurs séparées, ajouter des balises ponctuelles pour décrire chaque nom, confondre un type d’entreprise avec un sujet, générer des archives indexables de faible qualité, et supprimer des termes sans migrer leurs membres.

Clés de jointure du playbook

• Objectif — playbookPillar, playbookFamily, playbookWave, postTypes, elements, businessTypes, journeyStage et amicitedFeatures sont des clés de jointure typées. Elles permettent à une page source d’apparaître dans des bibliothèques et matrices générées sans que les éditeurs aient à copier des cartes manuellement. Cette page est l’exemple concret : son pilier identifie un élément, sa famille regroupe les directives de métadonnées, et son tableau postTypes déclare les spécifications qui la consomment.
• Type et format — Les clés singulières utilisent des slugs enregistrés en minuscules : playbookPillar et playbookFamily sont des chaînes, playbookWave est un entier, et journeyStage est une chaîne contrôlée. Les clés relationnelles — postTypes, elements, businessTypes et amicitedFeatures — sont des tableaux de slugs enregistrés provenant de leurs registres respectifs.
• Requis ? — playbookPillar et playbookWave sont requis sur les enregistrements du playbook. playbookFamily est requis lorsque le pilier a des familles gouvernées. Les jointures de tableaux et journeyStage sont conditionnels : ne renseignez que les relations que le contrat de page prend réellement en charge.
• Limites — Un pilier, une famille au sein de ce pilier, une vague et une étape de parcours, sauf si le modèle autorise explicitement plusieurs étapes. Les tableaux contiennent des clés enregistrées uniques, pas des étiquettes d’affichage, du texte en prose ou des URL.
• Qui ou quoi le consomme — Listings du hub du playbook, matrices inter-piliers, filtres, cartes relationnelles, rapports d’exhaustivité, vues par vague de publication et outils internes qui trouvent les capacités AmICited pertinentes.
• Règles — Validez chaque valeur par rapport au registre canonique. La direction compte : une page de type de publication liste ses elements requis ; une page d’élément liste les postTypes applicables ; une page de type d’entreprise liste les types de publication utiles. Traitez les étiquettes comme de la présentation et les clés comme des données durables. Renommez une clé uniquement via une migration qui met à jour chaque côté de la jointure.
• Erreurs courantes — Inventer des quasi-synonymes, stocker des titres au lieu de slugs, mélanger des entiers et des chaînes pour les vagues, ajouter une relation parce que deux pages se mentionnent mutuellement, permettre à des tableaux réciproques de se contredire, et créer un balisage de listage maintenu manuellement qui s’éloigne des métadonnées.

Champs dérivés et structurels

schemaType

• Objectif — schemaType sélectionne le mappage de données structurées pris en charge le plus spécifique qui décrit avec précision la page visible. Il indique à l’adaptateur de schéma quel contrat de vocabulaire appliquer ; il ne transforme pas la page en cette chose par la seule déclaration.
• Type et format — Un nom de type Schema.org enregistré tel que Article, sélectionné parmi les types que l’adaptateur du site prend en charge. La casse et l’orthographe doivent correspondre au registre.
• Requis ? — Conditionnel. Définissez-le lorsque plusieurs mappages de schéma sont valides pour le même type Hugo ou lorsque le contrat du type de publication nécessite un type explicite. Sinon, laissez le modèle dériver sa valeur par défaut sûre.
• Limites — Un type de page principal, avec des entités imbriquées créées par l’adaptateur à partir du contenu réel. Le type sélectionné doit satisfaire toutes les propriétés requises et correspondre à ce qu’un lecteur peut voir.
• Qui ou quoi le consomme — Adaptateurs JSON-LD, validation des résultats enrichis, QA de contenu et rapports d’inventaire de schéma.
• Règles — Choisissez en fonction de la fonction de la page et des preuves visibles, pas de la fonctionnalité de recherche qu’un éditeur souhaite. Une page de guide pratique sans procédure visible complète ne peut pas gagner en précision en définissant un type de guide pratique. Gardez les URL, dates, personnes et images du schéma synchronisées avec leurs champs sources.
• Erreurs courantes — Sélectionner un type plus spécifique sans son contenu requis, émettre plusieurs types principaux conflictuels, copier une valeur de schéma depuis un modèle sans rapport, supposer qu’une syntaxe valide garantit l’éligibilité, et placer dans le JSON-LD des affirmations que les lecteurs ne peuvent pas inspecter.

Temps de lecture

• Objectif — Le temps de lecture donne au lecteur une estimation approximative de l’effort. Il est dérivé du corps final rendable afin que l’estimation change lorsque la charge de lecture réelle change.
• Type et format — Un nombre entier calculé de minutes produit à partir de la politique de comptage de mots du pipeline de contenu. Les blocs de code, tableaux, légendes et médias intégrés doivent suivre une règle de comptage documentée.
• Requis ? — L’affichage est optionnel selon le modèle. Un champ de frontmatter rédigé n’est pas autorisé comme source de vérité.
• Limites — Arrondissez de manière cohérente et appliquez un minimum d’affichage raisonnable comme une minute. L’hypothèse précise de mots par minute importe moins que d’utiliser la même méthode sur l’ensemble du site et d’étiqueter le résultat comme une estimation.
• Qui ou quoi le consomme — En-têtes de page, cartes, flux, segmentation analytique et lecteurs décidant de commencer un long guide.
• Règles — Calculez après que les shortcodes et les régions exclues sont traités selon la politique du site. Recalculez à chaque construction. Si une vidéo ou une tâche interactive modifie matériellement le temps d’achèvement, étiquetez cela séparément plutôt que de corrompre le temps de lecture.
• Erreurs courantes — Rédiger readingTime = 8, oublier de le mettre à jour après une réécriture, présenter une fausse précision, compter la navigation et les éléments standard, et traiter un guide pratique à forte exécution comme huit minutes de lecture plus aucun temps de tâche.

[[faq]]

• Objectif — [[faq]] stocke des paires de questions et réponses visibles une seule fois afin que la page et toute donnée structurée FAQ éligible ne puissent pas diverger.
• Type et format — Un tableau TOML de tables ; chaque élément contient une question en texte brut et une answer autonome.
• Requis ? — Conditionnel lorsque de véritables questions de suivi subsistent après le contenu principal. Ce n’est jamais requis simplement pour remplir un modèle ou poursuivre une fonctionnalité de recherche.
• Limites — Normalement quatre à huit éléments utiles sur les pages du playbook. Chaque question apparaît une fois, et chaque réponse doit être complète sans dépendre de l’ordre de l’accordéon.
• Qui ou quoi le consomme — Rendu FAQ visible, schéma FAQPage le cas échéant, navigation de page, QA de contenu et extraction de réponses.
• Règles — C’est un contrat de référence croisée : suivez Pourquoi la FAQ réside dans le frontmatter et les directives FAQ ultérieures plutôt que de maintenir des copies visibles et de schéma séparées. Stockez uniquement les questions que chaque lecteur peut consulter sur la page.
• Erreurs courantes — Réponses cachées uniquement dans le schéma, titres en double déguisés en questions, réponses promotionnelles, affirmations non étayées, JSON-LD obsolète, et traiter l’éligibilité aux résultats de recherche comme garantie.

[[lnks]]

• Objectif — [[lnks]] enregistre chaque lien interne gouverné utilisé dans le corps, associant son ancre visible à une destination et une description maintenue. L’enregistrement rend les liens inspectables sans analyser le HTML rendu et prend en charge la migration et la QA.
• Type et format — Un tableau TOML de tables avec text, path et title. text est l’ancre visible exacte, path est une URL relative au site avec barre oblique au début et à la fin, et title est la description de la page de destination.
• Requis ? — Requis pour chaque lien interne du corps gouverné par cette convention de contenu. Les liens profonds d’application et les sources externes suivent leurs propres enregistrements et ne sont pas déguisés en entrées [[lnks]].
• Limites — Un enregistrement par occurrence de lien dans le corps lorsque la même ancre peut pointer vers différentes destinations ; sinon, les enregistrements en double exacts doivent être supprimés. La destination doit exister ou être dans le registre de slugs canoniques approuvé pour la publication coordonnée.
• Qui ou quoi le consomme — Validation des liens internes, migration de contenu, analyse relationnelle, génération de titres de lien le cas échéant, et révision éditoriale.
• Règles — Faites correspondre text à l’ancre du corps textuellement, y compris la casse et la ponctuation à l’intérieur du lien. Utilisez le chemin canonique relatif au site. Rédigez title comme une description précise de la destination, pas comme des instructions pour la page actuelle. Mettez à jour l’enregistrement et le corps ensemble.
• Erreurs courantes — Utiliser une valeur text plus longue que l’ancre réelle, inventer un slug non enregistré, omettre une barre oblique finale, enregistrer un ancien chemin de redirection, décrire la source au lieu de la destination, et laisser un enregistrement après la suppression de son lien dans le corps.

Requis versus optionnel selon le type de publication

La matrice applique les contrats ci-dessus aux douze types de publication actuellement déclarés par cet élément. R signifie requis, C signifie conditionnel selon les règles du champ, D signifie sortie requise qui peut être dérivée en toute sécurité, et O signifie optionnel. « Identité » inclut entity, id, title, type et la route stable. « Découverte » inclut description et keywords ; les prompts cibles restent conditionnels pour chaque ligne. aliases est toujours conditionnel à un déplacement, tandis que le temps de lecture rédigé n’est jamais requis.

« Relecteur conditionnel » n’est pas une permission de sauter la révision là où l’exactitude ou le risque commercial l’exige. Les pages meilleur-X et alternatives nécessitent une révision indépendante car leurs recommandations peuvent influencer matériellement une décision et changent souvent à mesure que les produits, prix et éligibilités évoluent. Pour les autres lignes, c’est la politique de risque, et non le temps disponible d’un éditeur, qui active l’exigence. De même, un canonical marqué D est toujours requis dans le HTML rendu ; seule la saisie dans le frontmatter peut être omise lorsque le modèle peut générer l’auto-référence correcte.

Validation du frontmatter

La validation doit rejeter les défauts déterministes automatiquement et réserver le jugement pour les questions qui dépendent du sens, des preuves ou de la compétence professionnelle. La scission empêche deux échecs opposés : demander aux relecteurs de détecter une syntaxe qu’un analyseur peut parfaitement détecter, et prétendre qu’une règle de comptage de caractères peut décider si un texte est honnête.

Exécutez les vérifications déterministes avant la révision éditoriale afin que le relecteur voie un enregistrement cohérent. Ensuite, révisez le HTML rendu, pas seulement le frontmatter : une valeur source valide reste un défaut de production si le modèle sélectionné l’ignore, la mappe vers la mauvaise balise, cache la provenance requise ou génère un canonical qui diverge de la route publique. La publication n’est complète que lorsque le comportement de la source, du rendu et de la destination concordent.

Le champ entity

entity répond à « de quel type de publication exact ce document est-il une instance ? » Il ne répond pas à « quel sujet cette page aborde-t-elle ? » Cette distinction importe car deux documents peuvent traiter le même sujet tout en remplissant des fonctions différentes. Une entrée de glossaire définit le « diagnostic » ; un article de blog peut rapporter un changement dans les directives de diagnostic. Si les deux utilisent entity = "diagnosis", les systèmes en aval ne peuvent pas choisir de manière fiable le bon modèle, les bonnes règles de validation, le bon groupe d’analytiques ou la bonne migration.

Utilisez le préfixe de groupe plus le slug du type de publication pour les variantes au sein d’une famille : guide-how-to, guide-ultimate, comparison-a-vs-b et comparison-alternatives-to-x. Utilisez le nom nu pour un type autonome : product-page ou case-study. Enregistrez l’identifiant une fois, gardez-le stable et ne le changez jamais parce que le sujet ou la requête cible change. Placez les concepts de sujet dans taxonomy et le langage de requête dans keywords.

Titre, H1 et titre SEO

Ces valeurs peuvent différer selon le contexte mais doivent décrire la même page. title est la valeur par défaut durable. h1 est le titre visible et peut être plus naturel dans son contexte. seoTitle dessert le navigateur et les résultats de recherche et peut ajouter un différenciateur concis, une année légitime ou un suffixe de marque.

Par exemple, title = "Rotation de clé API", h1 = "Comment faire pivoter une clé API sans temps d'arrêt" et seoTitle = "Rotation de clé API : guide étape par étape sécurisé" s’alignent sur une même tâche. « Outil de sécurité gratuit » comme titre SEO serait trompeur car cela change la promesse. Ne créez pas de différences uniquement pour insérer plus de mots-clés.

Règles de description

La description existe pour aider un lecteur qualifié à décider de cliquer. Restez dans 150–160 caractères, incluez le terme principal naturellement, énoncez l’avantage concret de la page et ajoutez un qualificatif significatif tel que le public, le périmètre ou le résultat. Rédigez une phrase fluide, pas une liste de mots-clés.

Le terme confirme la pertinence ; la répétition n’apporte aucune valeur. Ne dupliquez pas le titre, n’utilisez pas « Découvrez tout sur », ne faites pas de superlatifs non étayés et ne terminez pas en milieu de phrase. Les systèmes de recherche peuvent encore sélectionner un texte visible différent pour une requête.

Dates, auteurs et relecteurs

date préserve l’horodatage de première publication. updated enregistre la dernière modification substantielle : une correction factuelle, de nouvelles preuves, des instructions modifiées, un périmètre révisé, une recommandation modifiée ou une révision complète qui confirme les affirmations sensibles au temps. Enregistrez ce qui a changé dans l’historique éditorial lorsque la politique l’exige.

Corriger une ponctuation, changer un style de bouton, reconstruire un modèle ou toucher à l’horodatage seul ne réinitialise pas updated. Avancer une date sans travail derrière est une violation de politique car cela indique aux lecteurs et aux machines que le contenu a été rafraîchi alors qu’il ne l’a pas été. C’est une fausse déclaration, pas une tactique de croissance.

Les champs d’auteur et de relecteur portent des identités responsables dans les signatures et les données structurées. L’auteur est responsable du travail. Utilisez reviewedBy uniquement lorsqu’une révision qualifiée a eu lieu, et liez les deux identifiants à des profils maintenus. La page des fondements de la confiance explique comment la paternité, les dates, les preuves et la clarté des entités soutiennent la confiance sans garantir les classements.

Pourquoi la FAQ réside dans le frontmatter

Une FAQ est un contenu visible et une collection structurée. La stocker une fois dans [[faq]] permet au modèle de restituer l’accordéon et le FAQPage JSON-LD identique, empêchant ainsi un schéma caché obsolète.

Incluez de véritables questions de suivi visibles pour chaque lecteur. Ne dupliquez pas les titres, ne cachez pas de promotions dans les réponses et ne balisez pas des questions non affichées. Un balisage valide ne garantit pas une fonctionnalité de recherche.

Syntaxe et exemples de code

Le contrat multiplateforme mappe des champs, pas un composant visible. L’enveloppe portable suivante n’est valide que dans un fichier d’échange dont l’importateur reconnaît les directives de métadonnées.

:::frontmatter{entity="guide-how-to" id="reset-api-key" title="How to Reset an API Key"}
description: Reset an API key safely, replace it in dependent services, verify it, and revoke the exposed key without avoidable downtime.
author: maya-chen
:::

Elle doit être normalisée en métadonnées de page natives lors de l’importation. Elle n’est pas valide dans le corps d’un article de production. Dans Hugo, le mappage correct est le TOML entre les délimitations +++ au premier octet, comme montré dans le spécimen concret. Il n’y a délibérément pas de shortcode {{< frontmatter >}} : un shortcode s’exécuterait trop tard et dans la mauvaise région du document.

Dans WordPress, mappez les mêmes champs canoniques vers les champs de publication enregistrés et les métadonnées de publication, par exemple post_title, post_excerpt, post_name, _amicited_entity, _amicited_author et _amicited_reviewed_by. Un commentaire tel que <!-- wp:amicited/frontmatter --> ou un shortcode [frontmatter] est invalide car il crée un bloc de corps plutôt que des métadonnées de document. Les importateurs et éditeurs peuvent présenter un panneau de métadonnées, mais les valeurs stockées doivent rester attachées à l’enregistrement de publication.

Exemples

Correct : un enregistrement cohérent et responsable

entity = "guide-how-to"
id = "rotate-api-key"
title = "How to Rotate an API Key"
description = "Rotate an API key safely, update every dependent service, verify the replacement, and revoke the old credential without avoidable downtime."
url = "/academy/rotate-an-api-key/"
date = "2026-08-27 10:00:00"
updated = "2026-09-03 14:30:00"
author = "maya-chen"
reviewedBy = "alex-rivera"
keywords = [ "rotate API key", "API key rotation", "revoke API key", "credential security", "API security", "secret rotation" ]
taxonomy = [ "security", "account-administration" ]
canonical = "https://amicited.com/academy/rotate-an-api-key/"

Ceci identifie une variante de guide pratique, préserve l’historique, nomme les personnes responsables et sépare le sujet de l’identité de la page. L’horodatage de mise à jour est soutenu par un changement d’instruction documenté et une révision.

Incorrect : le titre répété comme description

title = "How to Rotate an API Key"
description = "How to Rotate an API Key"

La description n’apporte aucun bénéfice, périmètre ou raison de cliquer. Elle gaspille également l’espace d’aperçu qui pourrait distinguer cette page de tout autre résultat utilisant le même titre.

Incorrect : une entité réutilisée sur deux types de publication

# entrée de glossaire
entity = "diagnosis"

# guide éditorial
entity = "diagnosis"

Le sujet partagé a remplacé l’identité du type de publication. Utilisez des valeurs enregistrées comme glossary-term et guide-ultimate, puis attribuez « diagnosis » via la taxonomie ou les mots-clés.

Incorrect : une date de mise à jour sans diff de contenu

date = "2026-01-15 09:00:00"
updated = "2026-08-27 10:00:00" # seule la date a changé

Aucune modification ou révision substantielle ne soutient l’affirmation de fraîcheur. Gardez updated inchangé ou omis jusqu’à ce qu’un changement réel existe et puisse être inspecté dans l’historique éditorial.

Balisage de schéma et accessibilité

Les métadonnées fournissent des valeurs ; le modèle reste responsable du HTML sémantique, du focus, du contraste, de la finalité des liens et du texte alternatif.

Règles de rédaction

• Gardez les identifiants stables, en minuscules et sûrs pour les machines. Ne recyclez jamais un id et ne changez pas silencieusement entity après publication.
• Utilisez du texte brut dans les champs de type titre. Le HTML, les liens Markdown, les décorations par emoji et les sauts de ligne forcés n’ont pas leur place dans les chaînes de métadonnées.
• Gardez la description à 150–160 caractères et les tableaux de mots-clés à six à huit phrases distinctes pour ce playbook.
• Utilisez des personnes réelles enregistrées pour les champs d’auteur et de relecteur. Ne créez jamais de relecteur de complaisance ou d’identité générique « Équipe éditoriale » à moins qu’il ne s’agisse d’une entité responsable maintenue.
• Utilisez une taxonomie contrôlée. Les variantes orthographiques et les doublons singulier/pluriel créent des archives fragmentées.
• Ne référencez que des images qui existent et pour lesquelles vous avez les droits de publication. imageAlt décrit le contenu informatif de l’image, pas son objectif SEO.
• Gardez les réponses FAQ directes et autonomes. Les affirmations nécessitent toujours les mêmes preuves et divulgations que la prose ailleurs sur la page.
• Ne placez jamais de secrets, notes privées, jetons d’accès, instructions d’embargo, données personnelles ou affirmations juridiques non révisées dans un frontmatter publiable.

Quels types de publication utilisent le frontmatter, et où

Chaque type de publication utilise le frontmatter au premier octet. La profondeur requise change avec le risque, l’intention et le schéma plutôt qu’avec la conception visuelle.

Liste de contrôle QA

• Le fichier commence-t-il par +++, contient-il du TOML valide et ferme-t-il l’enregistrement avant le contenu du corps ?
• entity est-elle un identifiant de type de publication exact enregistré plutôt que le sujet, la campagne ou le nom du site ?
• id est-il unique et stable, et url correspond-il au registre de slugs canoniques ?
• title, le h1 optionnel et le seoTitle optionnel décrivent-ils la même page sans changements trompeurs de périmètre ?
• La description fait-elle 150–160 caractères, contient-elle le terme principal naturellement et offre-t-elle une raison concrète de cliquer ?
• Chaque image référencée existe-t-elle, et imageAlt est-il précis pour l’image qui est rendue ?
• La date de publication est-elle préservée, et chaque valeur updated est-elle soutenue par un diff substantiel ou une révision documentée ?
• Les identifiants d’auteur et de relecteur se résolvent-ils en des profils réels maintenus, et le relecteur nommé a-t-il réellement révisé le travail ?
• Les mots-clés sont-ils limités à six à huit phrases utiles et les valeurs de taxonomie sont-elles tirées de vocabulaires contrôlés ?
• Le canonical utilise-t-il HTTPS, se résout-il vers la page préférée et concorde-t-il avec le sitemap et les liens internes ?
• Chaque élément [[faq]] contient-il une question utile et une réponse autonome qui sont rendues visiblement avec un libellé identique ?
• Le JSON-LD généré correspond-il au contenu visible, utilise-t-il des identifiants stables et passe-t-il la validation syntaxique sans revendiquer des types non pris en charge ?
• Les secrets, notes éditoriales privées, affirmations non étayées et divulgations réservées au corps sont-ils absents de l’enregistrement ?

FAQ

Le frontmatter est-il visible sur la page publiée ?

L’enregistrement source est caché, mais les modèles peuvent restituer le titre, les personnes, les dates et la FAQ. D’autres champs alimentent les aperçus, les balises canoniques, les flux, les sitemaps, le schéma et les systèmes internes.

Le champ entity doit-il contenir le sujet ou le type de publication ?

Il identifie le type de publication exact. Les sujets partagés appartiennent à la taxonomie et aux mots-clés, pas à la place de l’identité du document.

Le titre, le H1 et le titre SEO peuvent-ils être différents ?

Oui. Le H1 peut être plus naturel à la lecture et le titre SEO peut ajouter un différenciateur, mais toutes les versions doivent faire la même promesse.

Quand la date de mise à jour doit-elle changer ?

Modifiez-la après une révision ou une édition factuelle substantielle. Ne la modifiez pas pour la ponctuation, le style, le travail de modèle ou un simple rafraîchissement de date.

Pourquoi les questions FAQ sont-elles stockées dans le frontmatter ?

Le tableau structuré permet à une seule source de restituer à la fois la FAQ visible et le FAQPage JSON-LD correspondant. Cela empêche le schéma de diverger de ce que les lecteurs peuvent inspecter.