Automatiser le remplissage des metas Yoast à l'import

Un import de plusieurs centaines de contenus laisse toujours la même question en suspens : les titres et descriptions destinés aux résultats de recherche. Les remplir à la main est hors de portée dès la centième fiche, et les laisser vides produit des pages dont le titre affiché dépend d'un modèle générique et dont la description est reprise au hasard dans le texte. Il existe trois voies pour traiter ce point, du plus simple au plus contrôlé : les modèles de titres et descriptions, l'alimentation des champs pendant l'import, et un traitement de rattrapage sur l'existant. Cet article détaille chacune, avec les champs concernés et les contrôles à mener ensuite.

Comprendre où vivent ces valeurs

Avant d'automatiser quoi que ce soit, il faut savoir précisément ce que l'on écrit et où. La confusion la plus fréquente porte sur la différence entre le modèle général, appliqué à tout un type de contenu, et la valeur individuelle enregistrée sur une publication précise. Les deux coexistent, la seconde primant sur la première, et beaucoup de traitements automatiques écrivent la mauvaise. Le réglage des modèles est présenté dans notre article sur la manière d'optimiser titres, metas et metadescriptions avec Yoast SEO.

Les champs de métadonnées individuelles

Chaque publication peut porter un titre et une description propres, enregistrés comme métadonnées de la publication avec des clés préfixées. Ces clés sont stables depuis longtemps et documentées, ce qui permet de les écrire directement. Une valeur vide signifie que le modèle général s'applique, ce qui est un comportement souhaitable et non un défaut. Écrire une chaîne vide et ne rien écrire du tout produisent d'ailleurs le même résultat visible, avec une différence de volume en base. Sur un catalogue important, cette différence se compte en dizaines de milliers de lignes inutiles.

Le modèle général par type

Le modèle définit la construction du titre pour tout un type de contenu, à partir de variables remplacées à l'affichage. Un modèle bien écrit couvre la majorité des besoins sans qu'aucune valeur individuelle ne soit nécessaire. C'est la voie à privilégier avant d'envisager le moindre traitement de masse, parce qu'elle se règle en une minute et se modifie ensuite pour l'ensemble du site. Beaucoup d'imports laborieux auraient pu être évités par un modèle correct. La question à se poser en premier est donc de savoir si les titres souhaités peuvent s'exprimer comme une formule appliquée à tous.

Les variables disponibles

Les modèles acceptent des variables représentant le titre de la publication, le nom du site, la catégorie principale, le séparateur, la date, et sur les produits certains attributs. Une variable personnalisée peut également être déclarée par du code, ce qui ouvre la porte à des constructions propres au projet. Cette possibilité est peu connue et elle résout beaucoup de cas que l'on croyait devoir traiter fiche par fiche. Elle demande une dizaine de lignes et elle vaut pour toutes les publications concernées. Elle présente en outre l'avantage décisif de rester modifiable ensuite, contrairement à des valeurs figées écrites une fois pour toutes.

Le comportement de la description

En l'absence de description renseignée, le moteur construit lui même un extrait à partir du contenu de la page, en fonction de la requête. Ce comportement n'est pas un défaut et il produit souvent un meilleur résultat qu'une description générique mal écrite. La description individuelle vaut donc surtout sur les pages où l'on souhaite maîtriser précisément le message, ce qui ne concerne pas l'ensemble d'un catalogue. Cette nuance change complètement l'ampleur du travail à prévoir. Elle conduit souvent à renoncer au remplissage systématique des descriptions, au profit d'un travail ciblé sur les pages qui comptent.

Les autres champs concernés

Au delà du titre et de la description, l'extension enregistre également la directive d'indexation, le mot clé principal, l'adresse canonique et les valeurs destinées au partage social. Un import peut avoir besoin d'alimenter certains d'entre eux, notamment la canonique sur les fiches dupliquées. Ces champs obéissent au même mécanisme de métadonnées et se traitent de la même façon. Il vaut mieux savoir qu'ils existent avant de découvrir leur absence après coup. La liste complète des clés employées est documentée et elle mérite d'être consultée avant d'écrire le moindre script.

Ce que l'interface fait en plus

La saisie manuelle depuis l'interface déclenche des traitements annexes, calcul d'indicateurs de lisibilité et mise à jour d'index internes. Une écriture directe en base ne les déclenche pas, ce qui peut laisser certains écrans incohérents. Cette différence est sans conséquence sur l'affichage public et elle explique des surprises dans l'administration. Les mécanismes d'import et d'export de ces valeurs sont détaillés dans notre article sur l'import export Yoast SEO et son onglet outils.

Alimenter pendant l'import

C'est la voie la plus propre, parce qu'elle traite la question au moment où toutes les données source sont disponibles.

Se brancher sur le bon événement

Un import déclenche une action après la création de chaque publication, à laquelle il est possible de se raccrocher. C'est à ce moment que les métadonnées doivent être écrites, avec l'identifiant de la publication et les données source encore en mémoire. Se brancher plus tard oblige à retrouver les données source, ce qui est nettement plus coûteux. Ce choix d'emplacement détermine la simplicité de tout le traitement. Les extensions d'import proposent généralement une accroche dédiée, préférable à l'accroche générique de sauvegarde qui se déclenche dans bien d'autres contextes.

Construire le titre depuis les données

Un titre de fiche produit peut se composer du nom, de la marque, d'une caractéristique différenciante et du nom du site. Cette construction se fait en une ligne à partir des colonnes du fichier importé. La contrainte de longueur impose de tronquer proprement, sur un mot entier plutôt qu'au milieu, ce qui demande quelques caractères de code supplémentaires. Le résultat est nettement supérieur à un modèle générique appliqué uniformément. Il faut néanmoins vérifier que chaque donnée employée est bien présente sur toutes les lignes, une marque vide produisant un titre bancal.

Écrire les métadonnées

La fonction native d'écriture de métadonnée suffit, avec la clé attendue par l'extension. Aucune interface particulière n'est nécessaire et cette écriture est parfaitement supportée. Il faut simplement écrire la valeur exacte que l'interface aurait enregistrée, sans échappement supplémentaire ni encodage particulier. Une comparaison avec une fiche saisie à la main confirme le format attendu en quelques secondes. Cette vérification préalable évite de découvrir après trois mille écritures que le format retenu n'était pas le bon.

Ne pas écraser l'existant

Un import récurrent, mettant à jour un catalogue chaque nuit, ne doit pas écraser les descriptions saisies à la main par l'équipe. Une condition vérifiant que le champ est vide avant d'écrire préserve ce travail. Cette précaution est indispensable dès que l'import tourne plus d'une fois, et elle est presque toujours oubliée lors du premier développement. Son absence détruit silencieusement des heures de travail éditorial. Le symptôme est particulièrement désagréable, puisque personne ne s'aperçoit de rien avant qu'un rédacteur ne cherche sa description.

Traiter par lot

Un import de dix mille fiches ne doit pas déclencher dix mille écritures isolées avec les traitements annexes associés. Désactiver temporairement les actions non nécessaires, puis les réactiver, réduit fortement la durée. Sur les volumes importants, l'écriture directe en base par lot devient préférable, avec les précautions correspondantes. Ce choix se pose au delà de quelques milliers de lignes. En dessous, la simplicité de la fonction native l'emporte largement sur le gain de temps espéré.

Journaliser ce qui a été écrit

Un compteur des valeurs écrites, des valeurs ignorées et des erreurs rencontrées permet de vérifier que le traitement a fait ce qu'il devait. Sans lui, l'import se termine sans erreur et personne ne sait combien de fiches ont réellement reçu leur titre. Ce journal tient en trois lignes et il évite de découvrir le problème un mois plus tard. Il sert également à documenter l'opération pour les imports suivants. Conserver ces compteurs d'un import à l'autre permet de repérer une dérive, par exemple un nombre croissant de fiches ignorées.

Rattraper l'existant

Sur un site déjà importé sans métadonnées, le traitement de rattrapage suit la même logique avec quelques précautions supplémentaires.

Mesurer d'abord

Une requête comptant les publications sans titre ni description renseignés donne l'ampleur du travail. Le résultat est souvent plus faible qu'attendu, une partie des contenus ayant été traitée manuellement. Ce comptage permet aussi de décider si un traitement automatique se justifie ou si une reprise ciblée suffit. Il prend deux minutes et il évite d'écrire un script pour quarante pages. Il donne aussi une indication sur la qualité du travail déjà mené, information utile lors d'une reprise de site.

Sauvegarder la table de métadonnées

Toute écriture de masse doit être précédée d'une copie de la table concernée, conservée sous un autre nom. Cette copie permet de revenir en arrière sur les valeurs écrasées par erreur. Elle coûte quelques mégaoctets et elle est la seule assurance réelle. Sur ce type de traitement, une condition mal écrite peut toucher plusieurs milliers de lignes en une seconde. La copie doit être conservée plusieurs semaines, les problèmes se découvrant parfois longtemps après.

Procéder par lots

Traiter cent publications, contrôler le résultat, puis continuer, permet d'arrêter au premier problème. Un traitement appliqué d'un coup à dix mille contenus rend le diagnostic impossible. Cette progression allonge l'opération d'une heure et elle la rend réversible à chaque étape. Commencer par les contenus les moins visibles limite l'exposition. Les pages les plus consultées se traitent en dernier, une fois le script éprouvé sur plusieurs lots.

Ne traiter que les champs vides

La condition doit porter sur l'absence de valeur, y compris le cas d'une chaîne vide enregistrée, qui n'est pas équivalent à l'absence de ligne. Une requête ne testant que l'existence de la ligne laissera de côté les publications portant une valeur vide. Ce détail explique des rattrapages qui paraissent ne rien faire. Un test sur les deux cas règle la question. Il vaut mieux le vérifier sur un échantillon avant de lancer le traitement complet, l'écart pouvant représenter la moitié des lignes concernées.

Contrôler les longueurs

Un titre dépassant la longueur affichée est tronqué dans les résultats, ce qui produit une coupure au milieu d'un mot. Le traitement doit donc borner la valeur produite, en coupant sur un séparateur plutôt qu'au caractère près. Cette contrainte se vérifie après coup par une requête listant les valeurs les plus longues. Elle attrape les cas particuliers que la construction générique n'avait pas prévus. Les noms de produits très longs sont les premiers concernés et ils se corrigent par une règle de troncature adaptée.

Vérifier l'unicité

Un titre identique sur trois cents fiches signale une construction trop générique, souvent parce qu'une variable était vide sur ces fiches. Une requête groupant par titre et comptant les occurrences fait apparaître ces cas immédiatement. Ce contrôle est le plus révélateur de tous et il prend une requête. Il conduit régulièrement à revoir la formule de construction plutôt qu'à corriger fiche par fiche. Ajouter une donnée différenciante, référence ou contenance, suffit en général à rétablir l'unicité.

Vérifier le résultat

Un traitement de masse doit être contrôlé autrement que par un coup d'œil sur trois pages, sans quoi les défauts se découvrent par une chute de trafic.

Contrôler le rendu public

La vérification porte sur ce que le visiteur reçoit, donc sur le code source de quelques pages représentatives. Une valeur écrite en base et non reprise à l'affichage signale un problème de clé ou de priorité entre modèle et valeur individuelle. Ce contrôle prend trente secondes par page et il est le seul qui compte réellement. Il doit être fait en navigation privée pour écarter tout effet de cache. Un vidage du cache de page avant la vérification évite par ailleurs de conclure trop vite à un échec du traitement.

Explorer le site en entier

Un outil d'exploration extrait les titres et descriptions de toutes les pages et permet de repérer les valeurs vides, dupliquées ou trop longues. Ce tableau, obtenu en quelques minutes, constitue le meilleur contrôle disponible après un traitement de masse. Il révèle presque toujours une famille de pages mal traitée, ce qui est une bonne nouvelle puisqu'une seule correction règle l'ensemble. Conserver l'export obtenu permet de comparer après correction et de mesurer le gain.

Suivre les rapports de recherche

Les outils pour webmasters signalent les titres et descriptions qu'ils jugent problématiques et affichent le taux de clic par page. Une baisse de ce taux après le traitement indique que les nouveaux titres sont moins engageants que ce que le moteur produisait lui même. Cette mesure demande plusieurs semaines de recul et elle est la seule qui juge le résultat sur son effet réel. Elle conduit parfois à retirer des descriptions plutôt qu'à en ajouter. Ce constat surprend et il est parfaitement cohérent avec la façon dont le moteur construit ses extraits.

Accepter que le moteur réécrive

Un titre renseigné n'est pas toujours celui qui s'affiche, le moteur pouvant le remplacer par un autre jugé plus pertinent pour la requête. Ce comportement est documenté et il concerne une part significative des résultats. S'en agacer ne sert à rien ; ce qui compte est de fournir une valeur correcte, le remplacement n'intervenant en général que lorsque la valeur fournie est faible ou inadaptée. Cette réalité relativise l'effort à consacrer aux pages secondaires.

Documenter la construction retenue

Une note indiquant comment les titres sont composés, à partir de quelles données et avec quelles règles de troncature, permet de reproduire le traitement lors de l'import suivant. Sans elle, chaque import redémarre par une phase de rétro ingénierie. Cette note doit accompagner le script lui même. Elle évite aussi qu'une reprise manuelle ne s'écarte du modèle sans que personne ne s'en aperçoive. Une page de documentation interne, accessible aux rédacteurs, remplit parfaitement ce rôle.

Prévoir la reprise éditoriale

Les valeurs générées sont correctes et elles ne remplacent pas un travail rédactionnel sur les pages qui comptent. Identifier les cinquante pages les plus consultées et y reprendre titre et description à la main produit un gain sans commune mesure avec un traitement générique appliqué partout. Cette hiérarchisation est le meilleur usage possible du temps disponible, et elle vaut mieux que n'importe quel effort réparti uniformément. Elle distingue un travail utile d'un simple remplissage, comme nous le rappelons dans notre article sur la façon de compléter la meta box de Yoast. Le tri se fait sur les pages qui reçoivent déjà des impressions, celles pour lesquelles une amélioration du titre produit un effet mesurable en quelques semaines plutôt qu'en plusieurs mois.