Vérificateur de mauvais backlinks : diff des instantanés dans SQLite
Aucun script ne peut déclarer un lien toxique pour vous. Il peut vous indiquer quels domaines référents sont nouveaux, lesquels ont disparu et lesquels semblent assez étranges pour être lus à la main.
Équipe éditoriale Linkzoid ·
Tableau de sévérité pour les nouveaux domaines référents
Nos propres règles empiriques pour le triage, pas une définition de Google
Niveau
Signal
Action
Ignorer
Nouveau domaine, DR supérieur à 30, l'anchor text est votre marque ou une URL brute
Journalisez-le, passez à autre chose
Regarder
50 domaines nouveaux ou plus en une semaine provenant d'un TLD que vous ne ciblez pas
Ouvrez-en dix
Regarder attentivement
Même anchor text exact sur 20 domaines nouveaux ou plus
Vérifiez le nuage d'anchors, trouvez la source
Agir
Réseau ressemblant à un achat de liens ou pages piratées pointant vers vous
Documentez-le ; envisagez un fichier disavow uniquement si vous avez également une action manuelle
Attendre
Un domaine a disparu ce mois-ci
Revérifier après le prochain rafraîchissement mensuel
Pourquoi un diff plutôt qu'un scan unique
Un instantané unique vous dit ce qui est présent. Un diff vous dit ce qui a changé, et c'est là que les problèmes apparaissent.
Google a indiqué pendant des années, depuis la sortie de Penguin 4.0 en septembre 2016 et à nouveau lors de la mise à jour sur le spam des liens en décembre 2022, qu'il ignore principalement les liens spammy au lieu de les punir. SpamBrain effectue ce travail. Ainsi, une inondation de déchets est plus souvent du bruit qu'une menace, et le diff vous épargne principalement d'une réaction à ce bruit.
Conservez votre propre historique. Les suites écrasent les leurs.
Construire la table d'historique en quatre étapes
Le diff ne fonctionne que si chaque run atterrit dans la même table, avec la même structure. Ces étapes maintiennent cette configuration.
01
Créer la table une fois
Exécutez une instruction create-if-not-exists avec les colonnes dont vous avez besoin : le jour, le domaine et le score. Gardez cela dans le script, afin qu'une nouvelle machine reconstruise la même table sans étape manuelle.
02
Insérer une ligne par domaine par jour
Utilisez une insertion paramétrée et validez une fois par run. Une seule validation empêche qu'un crash ne laisse une demi-journée inachevée dans le fichier.
03
Se prémunir contre un deuxième run
Supprimez les lignes du jour avant d'insérer, ou ajoutez une clé unique sur le jour et le domaine. Un rerun le même jour remplace alors les lignes au lieu de les doubler.
04
Comparer avec le jour précédent sur le fichier
Sélectionnez la date antérieure la plus récente avec un filtre max(day), pas la date d'hier. La comparaison reste correcte lorsqu'une semaine a été sautée.
diff.py
Deux tables seraient plus propres. Une suffit pour une configuration de hobby : une ligne par domaine par date d'instantané.
python
import json, sqlite3, sys, datetime
db = sqlite3.connect('links.db')
db.execute('create table if not exists snap(day text, dom text, dr int)')
rows = json.load(open(sys.argv[1]))
day = datetime.date.today().isoformat()
db.executemany('insert into snap values (?,?,?)',
[(day, r.get('domain'), r.get('dr')) for r in rows])
db.commit()
prev = db.execute('select max(day) from snap where day < ?', (day,)).fetchone()[0]
if prev:
new = db.execute('select dom from snap where day=? except select dom from snap where day=?', (day, prev)).fetchall()
gone = db.execute('select dom from snap where day=? except select dom from snap where day=?', (prev, day)).fetchall()
print(len(new), 'new,', len(gone), 'gone')
Dépannage du diff
Symptôme
Cause probable
Correction
Des centaines de 'disparus' du jour au lendemain
Le rafraîchissement de l'index a échangé l'échantillon
Comparer mensuellement, pas quotidiennement
Chaque domaine semble nouveau
La table était vide ou le format du champ day a changé
Vérifiez select distinct day
Colonne DR toute à NULL
Le nom du champ de la ligne diffère de dr
Imprimez une ligne brute et ajustez
Doublons après un rerun
Même jour inséré deux fois
Supprimez ce jour en premier, ou ajoutez une clé unique
Choisir des seuils à partir de votre propre historique
Un seuil copié depuis un article de blog est une supposition concernant le site de quelqu'un d'autre. Un vérificateur de mauvais backlinks n'est utile que dans la mesure de ses limites, et votre propre historique vous dit à quoi ressemble la normale pour votre domaine.
Commencez par enregistrer quelques mois sans agir sur quoi que ce soit. Laissez s'établir la situation. Ensuite, notez l'évolution hebdomadaire typique. Ce n'est qu'après cela que vous définissez les limites dans le tableau de sévérité.
Commencer par une ligne de base
Enregistrez les comptes de nouveaux et disparus pour chaque run sans réagir. Quelques mois de journalisation calme vous donnent une fourchette qui appartient à votre domaine et à personne d'autre.
Une fois la ligne de base établie, une seule mauvaise semaine se détache contre elle, et vous pouvez expliquer la différence sans deviner. C'est tout l'intérêt de la ligne de base.
Choisir une alarme par signal
Chaque signal du tableau reçoit un seuil, un propriétaire et une action. Un signal avec trois alarmes est un signal que personne ne lit, et les alarmes finissent par être ignorées ensemble.
Écrivez l'alarme à côté de son signal dans le code, afin que le tableau sur cette page et le script ne divergent jamais.
Revoir les limites chaque trimestre
Votre site grandit, et sa normale aussi. Revérifiez les limites tous les trois mois, et notez la raison à côté de tout changement, afin que l'histoire s'explique d'elle-même plus tard.
Lire le tableau de sévérité en pratique
Le tableau est une aide au triage, pas un jugement. Chaque ligne vous indique où regarder, et la colonne action vous empêche de chercher précipitamment un fichier disavow.
Travaillez de haut en bas. La plupart des semaines se terminent à Ignorer ou Regarder. Une ligne Regarder commence par quelques minutes de lecture, et une ligne Regarder attentivement commence par une revue plus longue des anchors. Ne sautez pas de lignes parce que la semaine était chargée. Une ligne sautée est celle où l'inondation passe inaperçue.
Échantillonner avant de décider
Ouvrez dix des domaines signalés et lisez les pages. Une inondation qui s'avère être un seul scraper de répertoires est un problème différent d'une inondation de blogs non liés, et seules les pages permettent de les distinguer.
Enregistrer vos décisions
Conservez une ligne par décision : le domaine, le niveau, ce que vous avez vérifié et ce que vous avez fait. La prochaine personne à lire le journal, y compris vous-même dans le futur, obtient le raisonnement sans réunion.
Un résumé mensuel de ces lignes prend peu de temps et constitue une bonne première ébauche de revue.
Ce que cela ne peut pas vous dire
Il ne peut pas prouver qu'un lien vous nuit. Personne en dehors de Google ne le peut, et le rapport d'actions manuelles de Search Console est le seul endroit où une pénalité est indiquée.
Il ne peut pas non plus voir les liens plus récents que le dernier rafraîchissement. Pour des preuves plus fraîches, demandez aux personnes qui gèrent le site de lien, ou lisez vos logs serveur pour les referrers. Notre note sur le timing va plus loin.
Si vous voulez le côté anchors, anchor_cloud coûte 2 crédits et regroupe le texte par fréquence, ce qui est le moyen le plus rapide de repérer un amoncellement de correspondances exactes.
Liens arrivés entre les rafraîchissements
Tout ce qui est plus récent que le dernier rafraîchissement est manquant des deux côtés du diff. Un lien qui apparaît et disparaît à l'intérieur d'une fenêtre de rafraîchissement ne s'affiche jamais du tout, c'est pourquoi la comparaison devrait s'exécuter mensuellement.
Anchors qui vous semblent incorrects
Un diff voit le domaine, pas la phrase autour du lien. Deux anchors identiques sur deux pages différentes peuvent signifier des choses très différentes, alors gardez la vérification des anchors comme une étape manuelle séparée.
Choix de stockage pour une configuration de hobby
SQLite est la base de données la plus simple qui réponde toujours à une question de diff avec une seule requête. Elle vit dans un seul fichier, donc elle s'intègre dans le repo ou un dossier de sauvegarde sans serveur.
Les fichiers JSON datés fonctionnent aussi. C'est plus lent à interroger, mais plus facile à ouvrir dans un éditeur de texte quand quelque chose semble incorrect. Dans les deux cas, copiez le store dans un second endroit avant tout nettoyage, et gardez la copie pendant un trimestre complet avant de supprimer quoi que ce soit.
Quand un fichier suffit
Une table avec une colonne jour couvre un seul site pendant des années. Le fichier reste petit, et les requêtes sur cette page ne nécessitent aucun réglage.
Quand passer à un serveur
Une fois que plusieurs personnes écrivent dans le même historique, un fichier sur une machine devient le goulot d'étranglement. À ce stade, une base de données gérée est le choix honnête, et le schéma reste le même.
Jusqu'alors, un fichier dans le repo est la chose la plus simple qui survive à un changement d'ordinateur portable.
Brancher le diff à un job hebdomadaire
Exécutez diff.py juste après l'étape de snapshot. Imprimez les comptes, et sortez avec un code non nul lorsque new dépasse une limite que vous avez choisie, disons 200 en une semaine pour un petit site. Le job devient rouge, et GitHub vous envoie un email. Simple.
Choisissez la limite à partir de votre propre historique. Après deux mois, vous savez si 15 nouveaux domaines par semaine est normal ou un pic, et tout nombre fixe copié depuis un article de blog est une supposition.
Les semaines calmes sont la norme.
Questions sur les mauvais liens, répondues simplement
Existe-t-il un vérificateur de mauvais backlinks fiable ?
Aucun outil ne peut étiqueter un lien comme nuisible avec certitude, car seul Google sait comment il traite chacun d'eux. Un script peut révéler des modèles dignes d'être lus : inondations soudaines, anchors exacts répétés, TLD étranges. Vous prenez la décision après avoir ouvert les pages.
Devrais-je disavouer ce que le diff signale ?
Rarement. Google a indiqué qu'il ignore largement les liens spammy, et un fichier disavow est destiné à des cas tels qu'une action manuelle ou un désordre de liens payants que vous avez créé vous-même. Documentez d'abord, et vérifiez Search Console avant de soumettre quoi que ce soit.
À quelle fréquence devrais-je l'exécuter ?
Snapshot hebdomadaire, revue mensuelle. L'index se rafraîchit environ une fois par mois, donc un diff quotidien compare principalement une table avec elle-même. Une revue mensuelle correspond aux données et réduit le bruit.
Quelles colonnes la table devrait-elle conserver ?
Conservez le jour, le domaine, le DR et une colonne source. Ajoutez l'anchor uniquement si vous récupérez aussi les anchors. Plus de colonnes semblent exhaustives, mais chaque champ supplémentaire est un autre qui peut dériver entre les runs.
Puis-je diff deux suites l'une contre l'autre ?
Vous pouvez comparer leurs comptes pour le même site, mais les deux résultats ne correspondront pas. Exécutez le diff à l'intérieur d'une seule source, et comparez la direction du changement entre les sources, la même règle qui s'applique partout sur ce site.
Que se passe-t-il si un domaine part puis revient le mois suivant ?
Il apparaît comme disparu puis comme nouveau, ce qui est du bruit. Comptez les retours séparément, ou comparez trois mois à la fois, afin qu'un domaine qui disparaît pour un rafraîchissement ne déclenche pas une revue.
