Définir ce que le lien doit faire avant d’accepter la suggestion
Une IA vous propose de préciser le texte d’un lien WordPress et de « mesurer les clics ». Dans l’aperçu, le nouveau libellé est plus clair et le lien ouvre encore la bonne page. La suggestion a pourtant ajouté un attribut ping. Dans un navigateur qui le prend en charge et l’autorise, l’activation du lien peut alors déclencher une requête supplémentaire vers une adresse de suivi. Le navigateur peut afficher la destination normale dans sa barre d’adresse pendant que cette autre requête part en arrière-plan.
Le premier contrôle porte sur le besoin éditorial. Demandez ce que la proposition était autorisée à changer. Dans notre exemple, le texte « Consulter les horaires » peut devenir « Consulter les horaires de l’atelier ». L’adresse des horaires, le lien vers le plan et le comportement réseau attendu sont déjà établis. Aucun changement de mesure n’a été demandé. Écrivez cette décision avant de comparer les deux versions. Elle permet à une autre personne de savoir pourquoi le nouveau libellé peut être retenu et l’attribut de suivi doit être écarté.
L’attribut href donne la destination de navigation. L’attribut ping peut indiquer une ou plusieurs adresses séparées par des espaces. Une adresse de suivi peut utiliser le même domaine que la page, et son nom peut sembler banal. Le domaine seul ne suffit donc pas à qualifier le changement. Examinez la fonction de l’adresse et la raison pour laquelle elle figure dans le lien. Il est possible qu’une mesure ait été prévue ailleurs dans le site. Conservez les comportements qui font partie du témoin, puis examinez précisément l’ajout proposé.
Ce guide traite d’une proposition accompagnée de HTML ou appliquée à un bloc qui accepte ce balisage. Si votre outil fournit du texte brut et que vous remplacez les mots dans l’éditeur visuel, vous n’avez aucune raison de coller son exemple HTML. Si la suggestion a déjà été appliquée, partez d’une révision connue et du rendu actuel. Deux états séparés permettent de décider où commence la différence.
Préparer un témoin que personne ne peut confondre avec le suivi
Dans une instance locale, créez un article fictif sur la visite d’un atelier. Ajoutez deux pages de destination. La première contient le titre « Horaires fictifs » et la seconde le titre « Plan fictif ». Les deux doivent être faciles à reconnaître sans s’appuyer uniquement sur un code HTTP. Un document d’erreur personnalisé ou une redirection pourrait aussi aboutir à une réponse qui paraît réussie. Le titre et l’adresse finale vous aident à confirmer l’objet réellement ouvert.
Créez ensuite deux liens dans un bloc HTML personnalisé sur la copie. Le lien principal ouvre les horaires et le lien témoin ouvre le plan. Relevez les deux textes et les deux adresses. Copiez le corps du bloc dans un fichier local ou repérez une révision qui le contient. Pour garder le test lisible, évitez de modifier l’ordre des liens, leurs destinations ou la structure de la page pendant la comparaison. Le lien témoin répond à une question simple. La requête imprévue suit-elle seulement le lien modifié ou apparaît-elle aussi avec un lien intact ?
Utilisez une adresse fictive distincte, comme /collecte-fictive, pour représenter le suivi dans la copie. Elle ne doit correspondre à aucun collecteur réel. Le vérificateur fourni intercepte cette requête dans Chrome avant qu’elle atteigne le serveur de test. Si vous reproduisez le contrôle sans ce vérificateur, laissez l’adresse fictive et travaillez dans une instance isolée qui ne transmet rien vers l’extérieur. Inspectez les adresses avant le premier clic. Pour une proposition qui contient déjà un domaine réel ou un identifiant, préparez le témoin avec des valeurs inventées avant d’activer le lien.
Séparez les fichiers de travail. Conservez la version de référence, la proposition brute et la version corrigée. Les captures utiles montrent les deux destinations légitimes et le nom de l’attribut, sans recopier les identifiants d’un outil de mesure. Ainsi, la personne qui relit peut reproduire le mécanisme sans disposer du site initial, du compte de l’éditeur ou du service qui a proposé le texte.
Comparer le code enregistré avec le lien affiché
Dans la copie qui contient la proposition, sélectionnez le bloc visé et lisez le HTML. Repérez d’abord l’élément a qui porte le texte des horaires. Relevez la destination href, le texte situé entre les balises et les attributs ajoutés. Le fragment ci-dessous illustre l’état à refuser. Les chemins sont fictifs. Dans le bac à sable fourni, WordPress génère des adresses de pages selon leurs identifiants.
Vous devriez pouvoir expliquer les changements séparément. Le texte s’allonge pour préciser de quels horaires il s’agit. La destination garde le même sens et la même adresse. L’attribut supplémentaire désigne une seconde adresse. Si la proposition contient plusieurs URL dans ping, relevez chacune dans la copie de travail. Pour ce cas, aucune de ces notifications ne fait partie du changement validé. Vous pouvez décider de conserver le texte seul sans importer le reste de la balise.
Regardez aussi l’élément dans la page côté visiteur. L’éditeur vous montre ce qui est enregistré, tandis que le document reçu indique ce que le navigateur peut utiliser. Un filtre WordPress, le rôle de la personne qui enregistre ou un composant qui reconstruit le lien peut modifier le résultat. Si ping est présent dans le brouillon mais absent du HTML rendu, gardez cette observation. L’ajout mérite d’être écarté dans la source que vous acceptez. Il n’y a pas lieu d’affirmer que ce navigateur a envoyé une notification.
Si l’attribut apparaît seulement côté visiteur, repérez le composant qui fournit l’élément. Le lien peut venir d’un modèle, d’une composition partagée ou d’un ajout fait au moment de l’affichage. Avant de changer un réglage partagé, vérifiez quelles autres pages l’utilisent. Une correction du texte dans le corps de l’article ne peut pas retirer un attribut que la page reçoit d’un autre emplacement.
<a href="/horaires-fictifs/" ping="/collecte-fictive">
Consulter les horaires de l’atelier
</a>Observer le clic et la requête dans la copie isolée
Le panneau Réseau du navigateur permet de distinguer la navigation et les requêtes qui l’accompagnent. Dans Chrome, ouvrez ce panneau avant le clic. Activez la conservation du journal pour que le changement de page ne l’efface pas. Attendez que la page soit prête, effacez la liste précédente, puis activez le lien vers les horaires une seule fois. Relevez l’adresse et le titre de la page ouverte. Dans la liste des requêtes, cherchez ensuite le chemin fictif du suivi et examinez la méthode HTTP. Si le navigateur affiche une ligne bloquée, précisez qu’il a tenté la requête et que celle-ci n’a pas atteint un destinataire.
La recette automatisée utilise un navigateur séparé et n’autorise que la lecture des trois documents WordPress nécessaires. Le blocage intervient avant tout accès au chemin de suivi. Avec la proposition, Chrome prépare un POST de type ping vers /collecte-fictive pendant que le document des horaires s’ouvre. L’activation du lien du plan aboutit à sa page sans ce POST. JavaScript est désactivé pour isoler le comportement natif de ce lien. Dans un site réel, un script peut lui aussi créer une requête au clic. Il faut donc attribuer la requête au bon mécanisme avant de choisir la correction.
Revenez sur la page de départ avant d’activer le témoin. Effacez ou séparez les observations des deux activations. Si vous utilisez un filtre dans l’onglet Réseau, vérifiez qu’il n’a pas masqué le document ouvert ou une requête d’un autre type. Notez aussi la version du navigateur. La présence de ping dans le HTML suffit à constater l’ajout, même si une configuration, une règle ou un autre navigateur empêche son exécution. Dans ce cas, consignez l’attribut visible et le résultat réseau séparément.
La chronologie aide à départager les causes. Une requête apparue avant l’activation peut appartenir au chargement de la page. Dans cet exercice, le même chemin apparaît uniquement avec l’état qui contient ping, au clic sur le lien concerné. Si vous observez la même requête avec le lien témoin ou après retrait de l’attribut, cherchez une source commune avant de conclure. Une mesure peut être déclenchée par le thème ou une autre intégration et mérite alors son propre test.
Reprendre le libellé depuis le bloc sain
Pour corriger la suggestion, repartez de la version de référence. Appliquez uniquement le nouveau texte approuvé. Dans un bloc édité visuellement, gardez le lien existant et modifiez son libellé. Dans le bloc HTML de l’exercice, vous pouvez aussi retirer le seul attribut ping de la balise contrôlée, puis vérifier qu’il reste un lien complet. Comparez ensuite href, le texte et l’absence de ping dans le code enregistré et dans la page. Un attribut vide ou commenté n’est pas nécessaire. La correction attendue donne une balise lisible avec la destination et le libellé utiles.
Si l’éditeur ne vous permet pas de modifier ce balisage, transmettez le repère du lien et l’écart observé à la personne qui gère la source du bloc. Une capacité d’édition plus large n’est pas nécessaire pour rédiger le nouveau libellé. Si le lien vient d’une zone partagée, corrigez à l’endroit où l’attribut a été ajouté et vérifiez au moins une autre occurrence de cette zone. Un lien indépendant vers la même destination peut rester tel quel. Deux liens qui ont le même href peuvent provenir de blocs et de modèles différents.
Rechargez la copie corrigée comme un visiteur. Le lien des horaires doit afficher le texte retenu et atteindre la même page. Le lien du plan sert à vérifier qu’aucune autre action n’a été entraînée par la correction. Reprenez la séquence réseau dans les mêmes conditions que pour l’état avec la proposition. Comparez le chemin et le type de requête qui vous intéressent. Le total des ressources chargées n’est pas un critère de réussite. Il peut changer à cause d’une image ou d’un style sans rapport avec le lien.
Si le site dispose déjà d’une mesure prévue, demandez à la personne qui en a la charge de fournir la liste des comportements attendus dans l’environnement de travail. Un contrôle sur le seul attribut ping permet de vérifier le retrait de cet ajout. Pour modifier une autre forme de mesure, partez de cette source et de sa propre référence. Vous évitez de retirer un fonctionnement existant en cherchant à corriger une proposition ponctuelle.
Rétablir l’état antérieur et vérifier le lien témoin
Faites le retour arrière sur la copie. Dans notre scénario, la révision saine contient le libellé « Consulter les horaires » et la même destination. Après restauration, comparez les deux liens, leurs attributs et leurs destinations. Le vérificateur compare l’empreinte du contenu WordPress enregistré et le fragment HTML public. Il répète aussi les activations. Un résultat valide revient à l’état de départ et n’ajoute aucune requête vers le chemin fictif.
Sur un article qui contient d’autres modifications utiles, restaurez la version précédente du lien seul si la révision complète effacerait un travail indépendant. Gardez la copie du bloc sain pour retrouver les anciennes valeurs. Si le changement a été appliqué dans un modèle ou un contenu partagé, restaurez la source correspondante. Vérifiez de nouveau la page de départ et une autre page qui utilise cette source. La révision de l’article ne suffit pas à établir l’état d’un composant enregistré ailleurs.
Dans la recette, les quatre états ont tous ouvert les horaires et le plan. Une seule tentative vers la collecte fictive est apparue, dans l’état qui contient la proposition. Le test a intercepté cette tentative avant tout envoi. Le libellé corrigé a été conservé sans ce comportement, puis la révision a rétabli le texte initial. Cette comparaison montre pourquoi le journal réseau complète la lecture du lien. Le test vérifie le cœur WordPress et le navigateur de la recette. Les réglages visuels de l’éditeur et les extensions de mesure restent à contrôler sur leur propre environnement.
Consigner ce qui peut être repris lors de la prochaine relecture
Dans la fiche de décision, indiquez l’article, le bloc et le lien concernés. Conservez une phrase pour la modification acceptée et une autre pour celle qui a été écartée. Ajoutez la destination contrôlée, la présence de l’attribut dans la proposition et le résultat de l’essai isolé. Précisez si la requête a été interceptée ou si vous avez uniquement observé le HTML. La décision pourra être comprise même si la suggestion originale n’est plus disponible dans l’éditeur.
Pour les lots de suggestions, commencez par les liens dont les destinations sont déjà connues. Comparez le nom du lien, son href et les nouveaux attributs avant de tester le clic. Si une proposition change à la fois le lien et le contenu autour, demandez une validation distincte pour chaque changement. Un texte plus clair n’autorise pas automatiquement un ajout technique. Vous pouvez reprendre le texte dans le bloc existant et appliquer la même recette à un deuxième lien de contrôle.
Si la proposition visait réellement à mesurer des clics, le choix du mécanisme relève d’un autre travail. Le registre de cette relecture doit simplement indiquer ce qui a été observé et ce qui a été appliqué au lien. L’équipe qui reprend le dossier pourra reproduire le défaut avec les deux destinations fictives. Elle disposera aussi de la version corrigée et de la révision saine pour comparer les résultats sans utiliser l’outil qui a fait la proposition.
