Blocs de contenu connexe : Règles de liaison interne

Un bloc de contenu connexe est un ensemble court de liens sélectionnés manuellement, placé à la fin du corps principal. Il conduit le lecteur vers la page suivante la plus utile et transmet l’autorité interne le long du même lien. Chaque destination doit avoir une raison éditoriale d’exister ; les balises partagées seules ne suffisent pas.

L’exemple rendu est délibérément modeste. Son titre explique le choix, chaque ancre prédit la destination et chaque raison indique au lecteur pourquoi cette page est la suivante. Le bloc ne rivalise pas avec l’article qu’il conclut.

Pourquoi cet élément est important

Terminer une page utile crée un point de décision. Le lecteur peut comprendre le sujet immédiat mais avoir encore besoin de l’appliquer, de comparer des options, d’apprendre un prérequis ou de se diriger vers un produit. Un bloc de contenu connexe réduit l’effort nécessaire pour trouver cette prochaine étape. Il propose un petit ensemble de parcours ciblés au moment où le lecteur est prêt à choisir, plutôt que de lui demander de revenir à la navigation globale ou de chercher à nouveau.

Le second rôle est architectural. L’autorité interne est l’importance et la pertinence contextuelle que les liens aident à distribuer entre les pages d’un même site. Un lien crée une arête entre deux documents. Sa position, son ancre et son explication indiquent aux systèmes de récupération ce que cette arête représente : quelle page est l’autorité large, laquelle couvre un sous-sujet et laquelle répond à un besoin adjacent.

L’extractibilité machine signifie qu’un système automatisé peut récupérer ces relations à partir du HTML sans deviner à partir de la mise en page. Une région de navigation sémantique, un titre visible, des liens explorables ordinaires, des ancres descriptives et un élément par destination exposent un ensemble propre d’énoncés source–relation–destination. Les carrousels uniquement JavaScript, les cartes uniquement images et les ancres génériques obscurcissent ces énoncés même lorsqu’ils semblent soignés.

Les deux rôles doivent survivre à la révision. Un bloc qui génère des clics mais envoie l’autorité vers des pages sans rapport endommage le modèle de contenu ; une carte de cluster correcte avec des liens non pertinents gaspille le point de décision du lecteur.

Quand l’utiliser

Utilisez cet élément lorsque la page a deux à cinq destinations suivantes crédibles et que la relation peut être énoncée en une ligne. Il appartient au contenu éducatif permanent, aux pages explicatives commerciales, aux comparaisons, aux pages produit et catégorie, aux pages de cas d’usage et aux études de cas lorsqu’une autre page fait véritablement avancer la même tâche ou décision.

Ne l’ajoutez pas simplement parce qu’un modèle a un espace vide. Une page de conversion à objectif unique avec une action nécessaire peut n’avoir besoin que de son appel à l’action de clôture. Un avis juridique, un écran de compte, un incident de support ou une page utilitaire courte peut n’avoir aucune continuation éditoriale sensée. Un index dont le corps principal consiste déjà en cartes de navigation n’a pas besoin d’une seconde liste les répétant.

Les erreurs courantes incluent :

• Un flux de balises répond à « qu’est-ce qui partage cette étiquette ? », pas à « que devrait faire ce lecteur ensuite ? ». Deux articles balisés « analytique » peuvent servir des publics et des étapes différents.
• Articles récents récompensent la date de publication plutôt que la pertinence. La récence est utile pour la découverte de l’actualité, mais ce n’est pas un modèle de relation.
• Articles populaires optimisent pour le trafic global, pas pour la question actuelle.
• Un plan de site en pied de page soutient une découverte large, pas un petit parcours choisi éditorialement.
• Un contrôle précédent/suivant reflète l’ordre de publication. Il compte seulement lorsque cet ordre est lui-même un cours ou une séquence délibérée.
• Les liens contextuels en ligne expliquent des termes ou soutiennent des affirmations au point de besoin. Ils complètent ce bloc mais ne remplacent pas son rôle de décision en fin de page.

La sélection est manuelle par défaut. Pour chaque lien proposé, l’éditeur enregistre une raison telle que « applique la méthode », « définit le prérequis », « compare les deux options introduites ici » ou « montre des preuves en pratique ». Si la raison est simplement « même balise », supprimez l’élément.

La sélection automatique est acceptable dans les archives d’actualités, les collections générées par les utilisateurs ou les inventaires trop volumineux et volatils pour une curation élément par élément. Même dans ce cas, exigez un ensemble candidat contrôlé, des exclusions pour l’URL actuelle et les pages expirées, une vérification de fraîcheur lorsque le temps compte, une pertinence au-delà d’une seule balise, un critère de départage stable et une surcharge éditoriale.

Où le placer

Placez le bloc après le corps principal complet et après le bloc de sources, mais avant l’appel à l’action de clôture. La raison est séquentielle : les sources closent l’obligation de preuve de la page actuelle ; le contenu connexe offre le prochain parcours d’apprentissage ou d’évaluation ; l’appel à l’action final propose le parcours commercial ou produit. Lorsqu’une page n’a pas de bloc de sources, le contenu connexe suit la dernière section substantielle.

Ne placez pas un second bloc de contenu connexe ailleurs sur la page. Ne le placez pas à côté d’une navigation précédent/suivant dupliquée, d’un nuage de balises dense ou d’une autre collection intitulée « Vous pourriez aussi aimer ». Une seule région de recommandation claire suffit.

Anatomie

Légende rendue :

1. Titre de section : nomme la relation, par exemple « Appliquez ce que vous avez appris » ou « Comparez les prochaines options ». Le générique « Connexe » est acceptable uniquement lorsque les destinations couvrent véritablement différentes actions.
2. Titre de l’élément : fournit l’ancre descriptive et prédit la valeur principale de la destination.
3. URL de destination : résout une URL interne canonique et explorable sans chaîne de redirection.
4. Vignette : distingue facultativement une destination lorsque l’imagerie porte des informations d’identification réelles.
5. Raison d’une ligne : explique facultativement pourquoi cette page est l’étape logique suivante ; elle est fortement recommandée lorsque la relation n’est pas évidente d’après le titre.
6. Limite du bloc : regroupe les liens comme navigation sans faire de la carte entière une cible de clic ambiguë.

La légende appartient à la page plutôt qu’à l’image afin qu’elle reste sélectionnable, traduisible et disponible pour les technologies d’assistance.

Exemples de conception

Les variantes changent la densité d’information, pas la logique éditoriale.

Texte seul : la valeur par défaut lorsque les titres de destination rendent la relation claire.

Avec raisons : la valeur par défaut pour différentes étapes du parcours. La raison ajoute la relation plutôt que de reformuler le titre.

Avec vignettes : réservé aux cas où l’imagerie originale aide à la reconnaissance. Les images ont besoin de dimensions et d’un texte alternatif utile, ou d’un texte alternatif vide lorsque le titre nomme déjà la destination.

Transversal : rend explicites les relations entre types de publication, éléments et applications métier. Il est généré à partir des métadonnées frontmatter révisées, pas des balises.

Paramètres

Deux éléments sont autorisés uniquement lorsque la page a une bifurcation étroite et crédible. Trois à cinq est la fourchette normale : suffisamment de choix pour servir différents besoins suivants, mais assez peu pour que chaque lien reste visible et intentionnel. Six est une exception stricte pour un pilier qui doit exposer un petit cluster complet. Plus de six devient un répertoire, affaiblit le signal éditorial de chaque arête et rend le balayage mobile coûteux.

Un attribut de titre omis peut être dérivé du premier titre dans le corps de l’élément. Ne fournissez pas les deux avec un texte différent. Une raison peut vivre dans l’attribut pour une phrase simple ou dans le corps lorsqu’elle nécessite une emphase en ligne ; elle ne doit pas apparaître deux fois.

Syntaxe et exemples de code

Le nom canonique du composant est related-content. Le formulaire ::item{} imbriqué maintient les champs de chaque destination ensemble et empêche les tableaux parallèles de se désaligner.

Directive Markdown portable

:::related-content{heading="Poursuivre avec le playbook" variant="reason"}
::item{title="Rédiger un guide pratique fiable" url="/seo-playbook/post-types/how-to-guide/" reason="Transformez les règles d'élément en une page pédagogique complète."}
::item{title="Structurer un guide ultime" url="/seo-playbook/post-types/ultimate-guide/" reason="Reliez cet élément à un pilier large et à ses rayons de soutien."}
::item{title="Construire une page cas d'usage" url="/seo-playbook/post-types/use-case-page/" reason="Portez l'intention éducative vers un public et un résultat spécifiques."}
:::

Shortcode Hugo

{{< related-content heading="Poursuivre avec le playbook" variant="reason" >}}
  {{< item title="Rédiger un guide pratique fiable" url="/seo-playbook/post-types/how-to-guide/" reason="Transformez les règles d'élément en une page pédagogique complète." />}}
  {{< item title="Structurer un guide ultime" url="/seo-playbook/post-types/ultimate-guide/" reason="Reliez cet élément à un pilier large et à ses rayons de soutien." />}}
  {{< item title="Construire une page cas d'usage" url="/seo-playbook/post-types/use-case-page/" reason="Portez l'intention éducative vers un public et un résultat spécifiques." />}}
{{< /related-content >}}

Il s’agit du contrat cible portable, et non d’une affirmation que ce dépôt enregistre le shortcode. L’exemple en direct utilise du HTML sémantique et n’ajoute aucune dépendance de mise en page.

Bloc ou shortcode WordPress

<!-- wp:amicited/related-content {"heading":"Poursuivre avec le playbook","variant":"reason"} -->
[related_item title="Rédiger un guide pratique fiable" url="/seo-playbook/post-types/how-to-guide/" reason="Transformez les règles d'élément en une page pédagogique complète."]
[related_item title="Structurer un guide ultime" url="/seo-playbook/post-types/ultimate-guide/" reason="Reliez cet élément à un pilier large et à ses rayons de soutien."]
[related_item title="Construire une page cas d'usage" url="/seo-playbook/post-types/use-case-page/" reason="Portez l'intention éducative vers un public et un résultat spécifiques."]
<!-- /wp:amicited/related-content -->

WordPress devrait utiliser un bloc dynamique enregistré avec des contrôles d’élément imbriqués. Le formulaire de shortcode est destiné aux systèmes qui ne peuvent pas stocker de blocs imbriqués et doit être enregistré avant la publication.

Exemples

Bon : chaque lien répond à un besoin suivant différent

:::related-content{heading="Mettez la méthode en pratique" variant="reason"}
::item{title="Exécuter la liste de contrôle QA pré-publication" url="/seo-playbook/process/checklists/pre-publish-qa/" reason="Vérifiez les liens, les preuves, l'accessibilité et la structure de la page avant la publication."}
::item{title="Construire un guide pratique" url="/seo-playbook/post-types/how-to-guide/" reason="Appliquez l'élément dans un format pédagogique complet."}
::item{title="Adapter le playbook pour le SaaS" url="/seo-playbook/business-types/saas/" reason="Traduisez les règles partagées en un parcours de contenu axé sur le produit."}
:::

Cela fonctionne car les destinations sont distinctes mais connectées : vérification, mise en œuvre et adaptation métier. Les ancres indiquent ce que chaque page offre, et les raisons expliquent la relation avec la page actuelle.

Mauvais : le widget de balises se fait passer pour une sélection éditoriale

:::related-content{heading="Vous pourriez aussi aimer"}
::item{title="Lire la suite" url="/blog/new-office/"}
::item{title="Cliquez ici" url="/features/ai-visibility/"}
::item{title="Dernier article" url="/blog/quarterly-roundup/"}
::item{title="SEO" url="/seo-playbook/"}
::item{title="Plus de SEO" url="/blog/old-seo-notes/"}
::item{title="Un autre article" url="/academy/how-to-export-prompt-data/"}
::item{title="Recommandé" url="/case-studies/hz-containers/"}
:::

L’exemple échoue même si chaque URL résout. Sept choix dépassent la fourchette. Les ancres ne prédisent pas la destination. Les destinations mélangent actualités de l’entreprise, produit, archive, académie et étude de cas sans raisons énoncées. « Dernier » est une règle de date, « SEO » est trop large, et rien ne prouve que les liens servent la prochaine tâche de ce lecteur.

Le contrat de cluster

Un cluster thématique est un groupe planifié de pages autour d’un sujet. Son pilier est la page large qui organise le sujet ; ses rayons sont des pages plus étroites qui répondent à des parties de celui-ci. Le bloc de contenu connexe transforme ce plan en véritables liens HTML :

• Chaque rayon renvoie vers son pilier. Cela indique aux lecteurs où appartient la réponse étroite et empêche le rayon de devenir un point d’arrivée isolé.
• Le pilier renvoie vers chaque rayon actuel. Lorsque le cluster a plus de six rayons, utilisez des sections organisées dans le corps du pilier plutôt que de forcer l’ensemble complet dans un seul bloc de contenu connexe.
• Les liens latéraux connectent un rayon à un autre uniquement lorsqu’un lecteur peut énoncer la relation de prochaine étape. Partager un parent n’est pas suffisant.
• Chaque arête est bidirectionnelle lorsque les deux directions aident un lecteur. L’ancre et la raison inverses peuvent différer car le parcours diffère.
• La suppression, la fusion ou la redirection d’une page déclenche une révision de chaque arête stockée qui y pointe.

Dans ce playbook, une page de type de publication renvoie vers les éléments qu’elle requiert et vers les types d’entreprise qui l’adaptent. Une page d’élément renvoie vers les types de publication qui l’utilisent. Ces relations sont générées à partir des métadonnées frontmatter révisées selon les règles transversales : le tableau postTypes de cette page est la source de ses liens vers les types de publication, tandis que les métadonnées du type de publication correspondant fournissent l’arête de retour. La génération gère le rendu ; les éditeurs décident toujours si la relation appartient aux métadonnées.

Les règles d’écriture des éléments plus larges régissent la manière dont ces métadonnées restent portables. Ne réparez jamais une relation éditoriale manquante en ajoutant une balise et en espérant qu’un widget choisira correctement.

Règles de texte d’ancrage

Le texte d’ancrage est le libellé visible et cliquable d’un lien. Rédigez-le de sorte qu’un lecteur puisse prédire la destination sans lire l’URL. « Construire un guide pratique » est utile ; « lire la suite », « cliquez ici », « en savoir plus » et une URL nue ne le sont pas.

Variez naturellement les ancres tout en préservant le sujet de la destination. « Créer un guide pratique » et « structurer un guide pédagogique » fonctionnent ; des synonymes de mots-clés sans rapport, non. Ne promettez jamais un modèle, un calculateur, un prix, une étude ou une liste de contrôle que la destination ne possède pas.

À l’intérieur du bloc, les ancres des titres doivent être uniques. Si deux destinations utiliseraient le même titre, ajoutez le public, la méthode ou le résultat distinctif. Gardez la raison facultative en dehors de l’ancre afin que la cible de clic reste concise et que les listes de liens des technologies d’assistance restent utiles.

Balisage schema et accessibilité

Aucun type spécial JSON-LD n’est requis. JSON-LD est un format basé sur script pour les données structurées, et Schema.org est le vocabulaire partagé couramment encodé avec celui-ci. Les liens restent normalement partie de l’Article, TechArticle, Product ou WebPage englobant. N’inventez pas de type schema RelatedContent.

Un ItemList peut décrire le bloc uniquement lorsqu’il s’agit véritablement d’une liste éditoriale ordonnée ou nommée et que la politique de schema à l’échelle du site l’exige. S’il est utilisé, itemListElement doit correspondre à l’ordre, aux URLs et aux noms des éléments visibles. N’ajoutez pas de destinations cachées ou d’évaluations synthétiques. Un fil d’Ariane est une relation différente et ne doit pas absorber ces liens.

L’accessibilité commence par un point de repère <nav>, c’est-à-dire une région que les technologies d’assistance peuvent identifier comme navigation. Donnez-lui un titre visible connecté via aria-labelledby ; ARIA est l’ensemble d’attributs utilisé pour exposer les noms et états d’interface lorsque le HTML natif seul a besoin d’aide. Utilisez une <ul> car l’ordre ne véhicule normalement aucun classement. Préservez le focus clavier visible, faites du titre le lien principal et évitez d’imbriquer une carte interactive dans un autre lien.

Le texte alternatif des vignettes ne doit pas dupliquer le titre lié. Utilisez un texte alternatif vide pour une vignette décorative. Lorsque l’image apporte des informations distinctes, décrivez uniquement ces informations. Le bloc doit rester complet avec les images ou JavaScript désactivés, et il ne doit pas déplacer le focus clavier lorsque les recommandations se rafraîchissent.

Règles d’écriture

Utilisez trois à cinq éléments par défaut, deux pour une bifurcation étroite, et pas plus de six pour un besoin documenté de petit cluster. Rédigez un titre de deux à huit mots, des ancres de titre de trois à douze mots et des raisons facultatives de huit à vingt-deux mots. Les raisons utilisent une phrase, une voix active et une relation concrète : appliquer, comparer, vérifier, définir, diagnostiquer ou voir des preuves.

Chaque élément a besoin d’une raison éditoriale distincte dans le modèle de contenu, même lorsque la raison n’est pas affichée. Révisez les titres après que les titres des destinations changent. Utilisez des URL internes canoniques avec des barres obliques de début et de fin. Supprimez les paramètres de suivi, les fragments qui n’identifient pas des sections stables, les redirections et les liens revenant à la page actuelle.

Ne placez jamais de publicités, de biographies d’auteur, de boutons de suivi social, de formulaires d’inscription, de nuages de balises, de promotions sans rapport ou de citations de sources à l’intérieur de cet élément. Ne mélangez pas des lectures externes avec des prochaines étapes internes ; les preuves externes appartiennent au bloc de sources. N’utilisez pas de badges tels que « meilleur », « populaire » ou « recommandé » à moins que la page ne définisse et ne soutienne la base de sélection.

Le ton doit être utile et spécifique, pas urgent. Évitez « à lire absolument », « à ne pas manquer », la rareté artificielle et les affirmations selon lesquelles la destination est complète à moins que sa portée ne soutienne ce mot. Le bloc recommande un parcours ; il ne fabrique pas d’importance.

Types de publication qui l’utilisent

Le tableau postTypes du frontmatter est la source de vérité pour les relations transversales suivantes.

Tous les candidats n’ont pas besoin d’être rendus sur chaque page. Le type de publication définit la relation éligible ; l’éditeur de la page sélectionne les destinations qui ont du sens pour le sujet et le parcours réels.

Liste de contrôle QA

• Le bloc apparaît une fois, après les sources et avant l’appel à l’action de clôture.
• La page contient deux à cinq liens, ou une raison documentée pour en utiliser six.
• Chaque élément a une raison éditoriale enregistrée au-delà d’une balise, d’une catégorie ou d’une date de publication partagée.
• Chaque ancre prédit ce que la destination offre réellement et évite « lire la suite », « cliquez ici » et autres formulations génériques.
• L’ensemble respecte le contrat de cluster : rayon vers le haut, pilier vers le bas, et latéral uniquement lorsqu’il est véritablement connexe.
• L’URL actuelle est exclue, les destinations sont canoniques et aucun lien ne repose sur une redirection ou un paramètre de suivi.
• Le frontmatter du contenu connexe correspond aux liens transversaux rendus.
• Le bloc reste lisible, navigable et complet sans vignettes ni JavaScript.
• La région de navigation a un titre visible et un nom accessible ; le focus clavier est visible.
• Les vignettes existent, ajoutent une valeur d’identification, réservent des dimensions et utilisent un texte alternatif correct.
• Les raisons ajoutent une relation de prochaine étape au lieu de répéter les titres.
• Les sources, publicités, formulaires, liens sociaux et promotions sans rapport restent en dehors du bloc.
• Toute donnée structurée ItemList correspond exactement aux éléments et à l’ordre visibles.
• Le rendu mobile expose chaque titre et raison sans carrousel horizontal caché.

Un réviseur devrait rejeter les liens seulement plausibles. Chacun doit être la bonne prochaine étape, exprimer une véritable arête architecturale et rester clair en HTML.

FAQ

Le modèle de l’académie affiche les entrées FAQ à partir du frontmatter.