Ce que fait exactement tag.html
Comparé à category.html, qui gouverne les archives de catégorie, tag.html occupe la même place mais pour les archives d’étiquette (le taxonomie native post_tag). Les deux fichiers sont indépendants : un thème peut très bien définir category.html sans jamais créer tag.html, et inversement. WordPress ne fusionne jamais ces deux taxonomies dans un seul gabarit tant que les fichiers propres à chacune existent ou n’existent pas séparément.
Comme pour les catégories, deux niveaux plus spécifiques existent : tag-{slug}.html pour une étiquette identifiée par son slug, et tag-{id}.html pour son identifiant numérique. En leur absence, tag.html s’applique à toutes les étiquettes du site sans distinction.
Comportement réel et cas limites
À la différence d’une catégorie, une étiquette n’a pas de hiérarchie parent-enfant : chaque étiquette est un terme isolé, ce qui simplifie la logique de tag.html par rapport à un éventuel category.html qui devrait tenir compte de sous-catégories imbriquées. En revanche, un site qui utilise des dizaines, voire des centaines d’étiquettes différentes, verra toutes ces pages passer par le même fichier tag.html si aucun fichier plus spécifique n’est créé, ce qui est presque toujours le cas en pratique tant les étiquettes sont nombreuses et changeantes.
Un cas limite fréquent : une étiquette renommée dans l’administration ne change pas le slug qui sert de base à un éventuel fichier tag-{slug}.html, sauf modification manuelle du permalien du terme. Un intégrateur qui cible une étiquette par son ancien slug peut donc continuer de voir son fichier spécifique s’appliquer même après un changement de libellé visible.
Il faut également garder à l’esprit que le contenu d’un fichier tag.html reste totalement libre : rien n’oblige à en faire une copie allégée de category.html. Un thème éditorial peut par exemple choisir d’y afficher un nuage des autres étiquettes proches, une fonctionnalité rarement pertinente sur une page de catégorie plus généraliste. Cette liberté explique pourquoi deux thèmes très proches visuellement peuvent malgré tout traiter très différemment leurs pages d’étiquette, sans qu’aucun des deux ne soit pour autant en tort vis-à-vis de la hiérarchie officielle.
Cas concret : un blog qui traitait étiquettes et catégories de façon identique
Un thème éditorial affichait ceci dans son dossier de gabarits :
theme/
templates/
index.html
archive.html
category.html
Faute de tag.html, chaque page d’étiquette retombait sur archive.html, qui affichait un simple titre générique « Archives » sans mentionner le nom de l’étiquette consultée, alors que category.html affichait correctement le nom de chaque catégorie. La création d’un tag.html reprenant un bloc Titre d’archive dédié a rétabli la cohérence attendue par les rédacteurs, sans dupliquer le contenu de category.html.
Pièges fréquents
- Supposer que category.html couvre aussi les étiquettes, ce qui n’est jamais le cas quelle que soit la configuration du thème
- Créer tag-{slug}.html pour une étiquette ponctuelle, puis oublier que toutes les autres continuent de dépendre du tag.html générique
- Négliger tag.html sur un site où les étiquettes servent en réalité de rubriques éditoriales à part entière, avec un besoin d’habillage propre
Quand tag.html ne suffit pas
Sur un site où une poignée d’étiquettes fonctionnent comme de véritables dossiers thématiques mis en avant (une étiquette « Dossier spécial » avec une image de couverture, par exemple), un tag-{slug}.html dédié à cette étiquette précise reste préférable à un tag.html unique chargé de conditions pour distinguer ce cas des autres.
En résumé
Une étiquette n’est pas une catégorie au rabais : elle mérite son propre gabarit, même sobre, plutôt qu’un repli générique qui efface son nom à l’écran.
Distinguer tag.html de category.html, et savoir jusqu’où va leur repli commun vers archive.html, permet de traiter chaque taxonomie native selon ses besoins réels plutôt que par simple habitude héritée des thèmes classiques.
