Runbook

Audit des liens post-publication avec GitHub Actions ou un cron simple

L'article est en ligne et le pipeline n'est pas terminé. Ce runbook ajoute un audit planifié qui enregistre les données des liens par site et signale à une personne uniquement lorsque quelque chose semble incorrect.

Équipe de recherche SEOBlogBot · Mis à jour 2026-10-29

Établi d'atelier avec roue de calendrier, jetons de crédit et cloche d'alerte en style low-poly

Pourquoi auditer après la publication ?

Une porte de validation voit un brouillon. Un audit voit ce que le site en ligne fait réellement. Les plugins réécrivent les liens, les éditeurs collent des redirections affiliées à la place d'URL propres, et une migration de CDN peut transformer un hôte en un autre. Rien de tout cela n'existe au stade du brouillon, c'est pourquoi un run post-publication est le premier endroit où cela peut apparaître.

Un audit utile est ennuyeux par conception. Il s'exécute sur un calendrier, écrit une ligne et reste silencieux à moins qu'une exception ne se produise. Le silence est l'objectif. Un mois de logs silencieux signifie que le travail fonctionne, et non qu'il est inactif.

Il n'existe pas d'API Google Backlink Checker officielle pour un usage général, c'est pourquoi les équipes appellent un index de liens tiers. C'est notre propre crawler. Search Console affiche la vue de Google sur vos propres liens, et l'audit la complète plutôt qu'il ne la remplace.

Où s'exécute le job

Notez le déclencheur. Trois configurations couvrent la plupart des équipes, et chacune effectue les mêmes appels. Le journal est plus important que le déclencheur, car la date, l'URL et les crédits utilisés doivent y figurer à chaque fois.

GitHub Actions pour un dépôt

Si le site est construit à partir d'un dépôt, un workflow planifié ajoute le moins de friction possible. Le job vit à côté du code, et la clé est stockée dans le magasin de secrets du dépôt. Le fichier de workflow ci-dessous est le minimum nécessaire. Gardez-le dans le dépôt, révisé comme tout autre code, et figez les versions d'action sur lesquelles vous vous appuyez.

Un serveur simple avec cron

Les équipes qui maintiennent déjà une machine pour leur build peuvent planifier les mêmes commandes là-bas. Un outil comme n8n peut les exécuter via une étape Execute Command, ou une ligne crontab peut les exécuter directement. Dans les deux cas, le job doit s'exécuter en tant qu'utilisateur capable de lire la clé et rien d'autre.

Un webhook depuis votre CMS

Certaines configurations de CMS déclenchent un webhook lorsqu'un article est publié, et cet événement peut lancer l'audit. La vérification s'exécute alors au moment où l'article est public. Gardez également un run planifié, car un seul webhook manqué laisse un article sans vérification.

Le runbook, dans l'ordre

Déclencher à la publication et à nouveau 30 jours plus tard

Un run juste après la mise en ligne de l'article vérifie les hôtes sortants. Un second run un mois plus tard lit refdomains pour votre site, car l'index se rafraîchit environ mensuellement et une lecture plus tôt ne montrerait rien de nouveau.

Appelez d'abord le résumé gratuit

action=overview renvoie les chiffres clés du site sans coût. Enregistrez-les comme la ligne de référence pour ce run, avec la date à côté.

Ne récupérez les listes payantes qu'en cas de changement

Si le résumé diffère du mois dernier, appelez refdomains (2 crédits) et anchors (2 crédits) et comparez-les aux listes stockées.

Écrivez une ligne dans un journal

Date, URL de l'article, appels effectués, solde _credits. Un CSV simple commité dans un dépôt privé suffit.

Alertez uniquement en cas d'exception

HTTP 401, HTTP 402, un résultat vide pour un site qui avait des lignes le mois dernier, ou une baisse de rating de 10 points ou plus.

Balances en laiton équilibrant une grande plante contre deux petites plantes identiques

Quels sites auditer

Commencez par le domaine qui héberge l'article. Ensuite, lancez le même audit contre deux ou trois pairs que vous souhaitez comparer. Utilisez compare pour cela. Il prend jusqu'à 20 domaines pour 1 crédit, donc la vérification des pairs coûte presque rien.

Ignorez la longue traîne. Chaque site supplémentaire ajoute du bruit à un journal qu'une personne doit lire. Une comparaison de vingt domaines non liés vous apprend très peu sur le vôtre.

Garder la clé hors des journaux

Un job planifié lit sa clé à chaque exécution, il n'a donc pas besoin d'une étape de connexion. La seule chose à protéger est la clé elle-même. Elle a trois fuites évidentes : un commit, un environnement imprimé et une URL qu'un proxy enregistre. Fermez chacune d'elles.

Utilisez le magasin de secrets, pas un fichier dans le dépôt

Collez la clé dans le magasin de secrets de votre fournisseur CI, ou dans un fichier d'environnement que seul l'utilisateur du job peut lire. Ne la committez jamais. Une étape qui affiche son environnement l'imprimera, donc n'en écrivez pas une.

Envoyez la clé dans un en-tête

L'en-tête Bearer garde la clé hors de la plupart des journaux d'accès, car les URL sont enregistrées et les en-têtes généralement non. La forme query-string fonctionne aussi, mais elle laisse une copie dans chaque proxy qui voit la requête.

Limitez qui peut lire le magasin

Donnez l'accès en lecture aux personnes qui maintiennent le job et à personne d'autre. Révisez cette liste lorsque le job change de main.

Une clé que beaucoup de gens peuvent lire est une clé qui finira collée dans une fenêtre de chat un jour.

Validez la réponse avant de l'écrire

Une réponse qui arrive n'est pas encore une réponse que vous pouvez utiliser. Utilisez un ordre à chaque fois. N'écrivez que ce qui passe, et journalisez le reste. Une réponse rejetée est une preuve, et la prochaine personne qui déboguera le job voudra la voir.

Vérifiez d'abord le statut et ok

Lisez le code de statut HTTP, puis le champ ok dans le corps. Un 200 avec ok défini à false est toujours un appel échoué, et le journal doit le dire.

Analysez le JSON avant toute écriture

Confirmez que le corps est un JSON valide avant de décompresser, analyser ou ajouter quoi que ce soit. Un téléchargement tronqué peut se produire sur un runner instable. Un fichier corrompu écrit dans le journal semble correct jusqu'à ce que quelqu'un l'ouvre.

Traitez une liste vide comme une question

Un résultat vide pour un site qui avait des lignes le mois dernier est une question, pas un fait. Vérifiez l'orthographe du domaine, y compris un www. leading, avant qu'une alerte ne soit déclenchée.

Un fichier de workflow à partir duquel commencer

Stockez la clé en tant que secret de dépôt nommé SBB_KEY. L'expression cron s'exécute le premier de chaque mois à 06:00 UTC.

yaml

name: monthly-link-audit
on:
  schedule:
    - cron: '0 6 1 * *'
  workflow_dispatch: {}
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Overview (free)
        run: |
          curl -fsS "https://seoblogbot.com/api.php?action=overview&q=example.com" > overview.json
      - name: Refdomains (2 credits)
        env:
          SBB_KEY: ${{ secrets.SBB_KEY }}
        run: |
          curl -fsS -H "Authorization: Bearer $SBB_KEY" \
            "https://seoblogbot.com/api.php?action=refdomains&q=example.com&per=500" > refdomains.json
      - name: Log credits
        run: jq -r '._credits' refdomains.json >> credits.log

Ce qui peut mal tourner et ce que montre le journal

Symptôme	Cause probable	Premier mouvement
HTTP 401	Secret manquant ou révoqué	Recréez le secret, exécutez workflow_dispatch
HTTP 402	Les crédits sont épuisés	Rechargez depuis la page de compte, relancez
Lignes vides pour un site connu	Rafraîchissement de l'index en cours ou faute de frappe dans le domaine	Réessayez dans un jour ; vérifiez le `www.`
Le rating a bougé de quelques points	Rafraîchissement mensuel	Ne rien faire ; regardez la tendance
Le rating a chuté de 10+	Perte de liens ou gros changement de rafraîchissement	Récupérez `refdomains` et comparez

Cron sur un serveur simple

Les mêmes commandes s'exécutent depuis une ligne crontab. Gardez la clé dans un fichier d'environnement que seul l'utilisateur du job peut lire, et journalisez dans un fichier que vous faites tourner.

Balance en pierre avec un poids lourd et un plat vide dans un éclairage pastel

Coûts et où les lire

Un audit mensuel pour un site coûte 4 crédits lorsque vous récupérez les deux listes, soit 0,0004 $. L'appel de résumé est gratuit. Un mois sans changement ne coûte donc rien au-delà de cela.

Si votre équipe publie dix articles par jour sur plusieurs sites, l'audit reste un job mensuel par site, et non un job par article. Cela garde le compte petit et le journal lisible.

Lorsque vous ajoutez un deuxième site, copiez le job plutôt que de l'élargir. Un workflow par domaine garde le journal par site et rend un échec facile à retracer jusqu'à son propriétaire.

Le coût plus élevé est généralement les minutes de votre fournisseur CI, et non nos crédits. Le tableau des coûts met les deux lignes côte à côte, afin que vous puissiez décider laquelle optimiser en premier.

Demandez au premier run d'imprimer _credits. Faites confiance à la réponse plutôt qu'à tout tableau. Le guide de la porte couvre la vérification côté brouillon qui précède celle-ci.

Le schedule GitHub s'exécute en UTC, donc un démarrage à 06:00 atterrit à une heure locale différente pour chaque équipe. Écrivez le fuseau horaire dans le runbook pour que personne ne soit surpris par le journal.

Questions sur l'exécution de l'audit

La plupart de ces questions proviennent d'équipes qui viennent de planifier le job pour la première fois.

S'agit-il d'une API Google Backlink Checker ?

C'est un audit construit sur notre propre API, pas un produit Google. Google ne publie pas d'API backlink générale, donc les chiffres proviennent de notre propre crawler et de notre propre index.

L'audit peut-il s'exécuter avec chaque build ?

Oui, mais un pull refdomains mensuel n'a pas besoin de s'exécuter à chaque build. Exécutez le résumé gratuit à chaque publication, et les pulls payants une fois par mois.

Ai-je toujours besoin de l'audit si j'ai une porte ?

Oui, si vous publiez via des plugins ou un CDN. La porte voit votre brouillon, et l'audit voit la page en ligne. Chacun détecte des échecs que l'autre ne peut pas voir.

Que se passe-t-il si le job échoue à mi-parcours ?

Écrivez le résultat de chaque étape dans son propre fichier, afin qu'un pull échoué laisse le résumé intact. Relancez depuis l'étape échouée plutôt que depuis le début, ce qui évite de payer pour le même pull deux fois.

Combien de crédits dois-je budgétiser par site ?

Budgétisez 4 crédits par site par mois pour les deux pulls payants, plus ce que votre porte dépense sur les brouillons. Le résumé gratuit n'ajoute rien à ce chiffre, et le journal vous indique le total réel.

Pourquoi deux runs quelques jours d'écart ne sont-ils pas d'accord ?

L'index se rafraîchit environ une fois par mois, donc les changements jour par jour sont généralement du bruit. Comparez l'instantané de ce mois-ci avec celui du mois dernier avant d'ouvrir un incident.

Validation du runbook

Le secret existe et le workflow a été exécuté une fois à la main.
Le fichier journal enregistre la date, l'URL, les appels et _credits.
Quelqu'un est responsable du canal d'alerte.
Le job traite les données mensuelles comme mensuelles.
Un échec de l'audit lui-même appelle une personne.