Alt text pour les pages catégorie et archive WordPress
Les posts individuels et les pages produit sont là où la plupart des plugins d'alt text font leur meilleur travail. Le contenu passe par le filtre the_content, les métadonnées SEO sont disponibles, et le chemin de rendu est prévisible. Les pages catégorie, les archives de tags, les archives par date et les pages de taxonomie personnalisées sont une autre histoire.
Comment les pages archive rendent les images
Quand WordPress rend une page catégorie ou archive, il n'utilise pas le même flux de contenu qu'un post individuel. Les pages archive affichent une liste d'extraits ou de résumés de posts, chacun avec une image mise en avant (si le thème le supporte). Les images mises en avant sont rendues via le filtre post_thumbnail_html, tandis que les extraits de contenu peuvent ou non passer par the_content selon le thème.
La différence critique est le contexte. Sur un post individuel, il y a un contexte clair : le post lui-même, avec son titre, son focus keyword et son contenu. Sur une page catégorie, il y a plusieurs posts, chacun avec ses propres métadonnées.
Ce que Bialty couvre sur les archives
Bialty se branche sur the_content et post_thumbnail_html. Pour les pages archive où le thème rend les images mises en avant via la fonction standard post_thumbnail_html, Bialty peut injecter l'alt text basé sur les métadonnées du post individuel. Chaque vignette sur la page catégorie recevrait l'alt text de son propre post.
Ça fonctionne quand le thème suit les conventions WordPress. Beaucoup de thèmes modernes le font.
Cependant, certains thèmes rendent les vignettes d'archive via du code de template personnalisé qui contourne le filtre standard. Dans ces cas, Bialty n'a pas accès à l'élément image au moment du rendu.
Ce que Bialty ne couvre pas
Les images hors du flux standard de contenu et de vignettes sont au-delà du périmètre par défaut de Bialty. Ça inclut les images de header de catégorie définies par le thème, les images de bannière personnalisées, les images rendues par des widgets dans les zones sidebar ou footer, et toute image produite par des fonctions de template personnalisées.
Ce n'est pas une limitation propre à Bialty — ça s'applique à tout plugin qui se branche sur les filtres de contenu WordPress. La page de compatibilité documente cette frontière explicitement.
Comment gérer l'écart
Pour les pages archive où Bialty ne couvre pas certaines images, les options sont simples. Si le thème supporte des champs personnalisés ou des plugins d'image de catégorie, définissez l'alt text directement via l'interface du thème. Si les images sont codées en dur dans le template, ajoutez l'attribut alt directement dans le fichier de template.
Pour la plupart des sites, les vignettes d'archive sont le type d'image le plus important sur ces pages, et Bialty les gère quand le thème utilise le rendu standard. Les cas particuliers sont habituellement un petit nombre d'images qui peuvent être gérées manuellement.
Audit pratique pour les pages archive
Ouvrez une page catégorie publiée dans un navigateur et inspectez les éléments image. Pour chaque image, vérifiez si l'attribut alt contient du texte généré par Bialty, la valeur originale de la Médiathèque, ou rien du tout.
Purgez le cache avant de tester — le HTML périmé du cache est le faux négatif le plus courant sur les pages archive.
L'attente réaliste
Bialty est conçu pour le rendu de contenu individuel : posts, pages et produits. Sa couverture sur les pages archive est un bonus qui fonctionne quand le thème coopère, pas une fonctionnalité garantie. La documentation officielle est transparente sur cette frontière.
Pour les éditeurs qui ont besoin d'une couverture d'alt text complète incluant les mises en page d'archive personnalisées, la stratégie est : laisser Bialty gérer ce qu'il peut via les hooks standards, puis couvrir le reste manuellement. C'est la même approche en couches qui fonctionne à toutes les échelles.