Vérification des backlinks de page à la publication, étape par étape

Définir les actions de la barrière

Une vérification des backlinks de page dans un flux de release est une petite tâche. Gardez-la simple. La partie difficile consiste à décider quelles réponses sont autorisées à changer, car un graphe de liens actualisé mensuellement ne peut pas faire obstacle à une page à lui seul.

Nous suggérons que la barrière avertisse, consigne et laisse la build continuer. Les valeurs par défaut peuvent évoluer. Les blocages stricts concernent ce que vous contrôlez, comme un balisage cassé ou une balise canonique manquante. Les données de liens sont un signal, et les signaux évoluent.

Notez-le. Faites-le avant de coder. Une politique d'une ligne telle que « avertir l'éditeur, taguer l'entrée, ne jamais bloquer le déploiement » évite un long débat à 18 h le jour de la mise en production. Cela indique aussi au prochain ingénieur quelles erreurs étaient prévues et lesquelles sont des bugs, ce qui est plus important qu'il n'y paraît. Révisez-la une fois par trimestre.

Où stocker la clé et comportement en cas de 402

Chaque appel payant transmet votre clé, soit dans la chaîne de requête, soit dans un en-tête Bearer. Privilégiez l’en-tête. Une chaîne de requête peut finir dans les journaux serveur et les traces proxy, tandis qu’un en-tête y reste généralement inaccessible.

Stockez la clé en tant que secret dans votre plateforme d’hébergement, jamais dans l’entrée elle-même. Les rédacteurs peuvent lire tout champ accessible, mais l’environnement d’une fonction est généralement visible uniquement par les personnes qui gèrent les déploiements.

Où doit résider la clé ?

Une clé divulguée peut épuiser le solde de votre compte : traitez-la comme un mot de passe. Conservez-la hors du dépôt et hors du CMS, et faites-la tourner si un fichier journal l’affiche en clair.

Étiquetez vos journaux avec le nom du hook. Le suivi des dépenses devient alors aisé pour une fonction donnée, même lorsque plusieurs hooks partagent le même compte.

Un outil no-code peut-il effectuer l’appel ?

Oui, lorsque l’outil dispose d’une étape de requête HTTP simple. De nombreux créateurs d’automatisation peuvent envoyer un GET avec une chaîne de requête et lire la réponse JSON, ce qui rend l’action d’aperçu gratuit entièrement dépourvue de code.

Commencez par les actions gratuites uniquement. Un flux déclenché à chaque sauvegarde de brouillon peut consommer des crédits plus vite qu’un rédacteur ne s’en rend compte ; ajoutez une étape payante une fois que les appels gratuits ont fonctionné sans incident pendant un certain temps.

Quel déclencheur pour un 402 ?

Un 402 signifie que le solde est vide. Cela n’indique rien sur la page. Sautez le contrôle payant, journalisez l’événement et envoyez une alerte à la personne qui recharge le compte, puis laissez la publication s’effectuer.

Définissez une alarme de solde bien au-dessus de zéro, afin que l’avertissement arrive alors qu’il reste encore du temps pour recharger. Une boucle de retry ne servira à rien ici, car chaque appel échouera de la même manière jusqu’à ce que du crédit soit ajouté. Le tableau des coûts contient les chiffres.

Quel domaine placer dans le paramètre q

L’API attend un domaine nu dans q, il faut donc d’abord réduire une URL complète. Écrivez cette réduction une fois, dans une seule fonction. Testez-la ensuite sur des URL réelles.

Les liens relatifs et les schémas manquants sont les cas qui cassent généralement un hook. Une réduction qui fonctionne sur des exemples propres peut encore échouer sur les URL désordonnées qu’un rédacteur colle à 17 heures.

Le www modifie-t-il la réponse ?

C’est possible, et la manière honnête de le vérifier est de poser la question. Lancez l’action gratuite sur les deux formes d’un site que vous connaissez, puis comparez les deux réponses côte à côte.

Quelle que soit la règle que vous choisissez, notez-la dans un commentaire de code pour que le prochain développeur n’ait pas à deviner. Un commentaire ne coûte rien et évite une longue discussion plus tard.

Et pour les redirections et les sous-domaines ?

Envoyez l’hôte sur lequel vos lecteurs atterrissent réellement, et non le lien qu’un rédacteur a collé il y a des années. Si ce lien fait une redirection, réduisez l’adresse finale et ignorez le saut intermédiaire.

Un blog sur un sous-domaine relève d’un jugement. Décidez à l’avance s’il est vérifié seul ou avec son domaine parent, et notez ce choix à côté de la règle.

Ce qu’il faut journaliser, et ce qui reste hors de l’entrée

Une ligne de journal pour chaque vérification ignorée est la piste d’audit la moins chère que vous puissiez mettre en place. Enregistrez l’ID de l’entrée, le domaine envoyé, le code de statut et si une étape payante a été exécutée. En général, c’est suffisant.

La note stockée reste courte et datée, comme le recommandent les étapes ci-dessus. Les réponses complètes doivent être conservées dans vos propres logs, si elles doivent l’être quelque part, car elles sont volumineuses et vieillissent rapidement.

Quels champs doivent figurer dans une ligne de journal ?

Commencez par l’ID de l’entrée et la version de publication. Un webhook répété apparaîtra alors comme la même paire deux fois, ce qui est exactement ce que vous voulez voir.

Ajoutez le domaine, le nom de l’action, le code de statut et l’heure de début de l’appel. Excluez la clé elle-même, car un journal qui la contient devient un deuxième endroit où les secrets sont stockés.

Combien de temps doit vivre une note stockée ?

Aussi longtemps que l’entrée existe, sauf si une vérification plus récente la remplace. L’important est qu’un lecteur puisse déterminer l’âge de la note, car une note datant de plusieurs mois peut être confondue avec des données en temps réel.

Le guide du champ score présente les quatre champs que nous suggérons pour cette note, y compris la date.