Link-Audit nach der Veröffentlichung mit GitHub Actions oder einem einfachen Cron-Job

Warum überhaupt ein Audit nach der Veröffentlichung durchführen?

Ein Gate sieht einen Entwurf. Ein Audit sieht, was die Live-Seite tatsächlich tut. Plugins schreiben Links um, Redakteure fügen Affiliate-Weiterleitungen über saubere URLs ein, und eine CDN-Migration kann einen Host in einen anderen verwandeln. Das alles existiert im Entwurfsstadium noch nicht, weshalb ein Post-Publish-Lauf der erste Ort ist, an dem dies sichtbar werden kann.

Ein nützliches Audit ist von Natur aus langweilig. Es läuft nach Zeitplan, schreibt eine Zeile und bleibt ruhig, es sei denn, eine Ausnahme tritt ein. Ruhe ist das Ziel. Ein Monat ruhiger Logs bedeutet, dass der Job funktioniert, nicht dass er untätig ist.

Es gibt keine offizielle Google Backlink-Checker-API für den allgemeinen Gebrauch, weshalb Teams stattdessen einen Drittanbieter-Link-Index aufrufen. Es ist unser eigener Crawler. Search Console zeigt Googles Sicht auf Ihre eigenen Links, und das Audit ergänzt dies, anstatt es zu ersetzen.

Wo der Job ausgeführt wird

Schreiben Sie den Trigger auf. Drei Setups decken die meisten Teams ab, und jeder davon führt dieselben Aufrufe aus. Das Log ist wichtiger als der Trigger, da Datum, URL und verwendete Credits jedes Mal dort landen sollten.

GitHub Actions für ein Repository

Wenn die Seite aus einem Repository erstellt wird, fügt ein geplanter Workflow den geringsten Reibungsverlust hinzu. Der Job lebt neben dem Code, und der Schlüssel befindet sich im Secret-Store des Repositories. Die Workflow-Datei weiter unten ist das Minimum, das Sie benötigen. Halten Sie sie im Repository, prüfen Sie sie wie jeden anderen Code auch, und pinnen Sie die Action-Versionen, auf die Sie sich verlassen.

Ein einfacher Server mit Cron

Teams, die bereits eine Maschine für ihren Build betreiben, können dieselben Befehle dort planen. Ein Tool wie n8n kann sie über einen Schritt „Befehl ausführen“ ausführen, oder eine crontab-Zeile kann sie direkt ausführen. In jedem Fall sollte der Job als Benutzer ausgeführt werden, der den Schlüssel lesen kann, aber sonst nichts.

Ein Webhook von Ihrem CMS

Einige CMS-Einrichtungen lösen einen Webhook aus, wenn ein Beitrag live geht, und dieses Ereignis kann das Audit starten. Die Prüfung wird dann im Moment der Veröffentlichung des Beitrags ausgeführt. Halten Sie auch einen geplanten Lauf vor, da ein verpasster Webhook einen Beitrag unkontrolliert lässt.

Welche Seiten zu prüfen sind

Beginnen Sie mit der Domain, die den Beitrag hostet. Führen Sie dann dasselbe Audit gegen zwei oder drei Wettbewerber durch, die Sie benchmarken möchten. Verwenden Sie dafür compare. Es nimmt bis zu 20 Domains für 1 Credit auf, sodass die Wettbewerbsprüfung fast nichts kostet.

Den langen Schwanz überspringen. Jede zusätzliche Seite fügt einem Log Rauschen hinzu, das eine Person lesen muss. Ein Benchmark von zwanzig unrelated Domains sagt Ihnen sehr wenig über Ihre eigene.

Den Schlüssel aus den Logs fernhalten

Ein geplanter Job liest seinen Schlüssel bei jedem Lauf, daher benötigt er keinen Anmelde-Schritt. Das Einzige, das geschützt werden muss, ist der Schlüssel selbst. Es gibt drei offensichtliche Lecks: ein Commit, eine gedruckte Umgebung und eine URL, die ein Proxy aufzeichnet. Schließen Sie jede davon.

Den Secret-Store verwenden, keine Datei im Repository

Fügen Sie den Schlüssel in den Secret-Store Ihres CI-Anbieters ein oder in eine Umgebungsdatei, die nur der Benutzer des Jobs lesen kann. Commiten Sie ihn niemals. Ein Schritt, der seine Umgebung ausgibt, wird ihn drucken, also schreiben Sie keinen solchen Schritt.

Den Schlüssel in einem Header senden

Der Bearer-Header hält den Schlüssel aus den meisten Access-Logs, da URLs aufgezeichnet werden, Header jedoch normalerweise nicht. Die Query-String-Form funktioniert ebenfalls, hinterlässt aber eine Kopie in jedem Proxy, der die Anfrage sieht.

Einschränken, wer den Store lesen kann

Gewähren Sie Lesezugriff nur den Personen, die den Job warten, und niemandem sonst. Überprüfen Sie diese Liste, wenn der Job die Hand wechselt.

Ein Schlüssel, den viele Personen lesen können, ist ein Schlüssel, der eines Tages irgendwo in einem Chat-Fenster eingefügt wird.

Die Antwort validieren, bevor Sie sie aufschreiben

Eine eingetroffene Antwort ist noch keine nutzbare Antwort. Verwenden Sie immer dieselbe Reihenfolge. Schreiben Sie nur das durch, was besteht, und protokollieren Sie den Rest. Eine abgelehnte Antwort ist ein Beweis, und die nächste Person, die den Job debuggt, wird dies sehen wollen.

Zuerst Status und ok prüfen

Lesen Sie den HTTP-Statuscode, dann das Feld ok im Body. Ein 200 mit ok gleich false ist immer noch ein fehlgeschlagener Aufruf, und das Log sollte dies so angeben.

JSON parsen, bevor etwas geschrieben wird

Bestätigen Sie, dass der Body gültiges JSON ist, bevor Sie etwas entpacken, parsen oder anhängen. Ein abgeschnittener Download kann auf einem instabilen Runner passieren. Eine defekte Datei, die ins Log geschrieben wird, sieht in Ordnung aus, bis jemand sie öffnet.

Eine leere Liste als Frage behandeln

Ein leeres Ergebnis für eine Seite, die letzten Monat noch Zeilen hatte, ist eine Frage, keine Tatsache. Prüfen Sie die Schreibweise der Domain, einschließlich eines führenden www., bevor jemand eine Warnung erhält.

Kosten und wo sie nachzulesen sind

Ein monatliches Audit für eine Seite kostet 4 Credits, wenn Sie beide Listen abrufen, was 0,0004 $ entspricht. Der Übersichtsaufruf ist kostenlos. Ein Monat ohne Änderung kostet daher nichts darüber hinaus.

Wenn Ihr Team zehn Beiträge pro Tag über mehrere Seiten veröffentlicht, ist das Audit immer noch ein monatlicher Job pro Seite, nicht ein Job pro Beitrag. Das hält die Anzahl klein und das Log lesbar.

Wenn Sie eine zweite Seite hinzufügen, kopieren Sie den Job, anstatt ihn zu erweitern. Ein Workflow pro Domain hält das Log pro Seite und macht einen Fehler leicht auf seinen Besitzer zurückverfolgbar.

Die höheren Kosten sind normalerweise die Minuten Ihres CI-Anbieters, nicht unsere Credits. Die Kostentabelle stellt beide Zeilen nebeneinander, sodass Sie entscheiden können, welche zuerst optimiert werden soll.

Lassen Sie den ersten Lauf _credits ausgeben. Vertrauen Sie der Antwort mehr als jeder Tabelle. Die Gate-Anleitung behandelt die Entwurfsprüfung, die dieser vorausgeht.

Der GitHub-Schedule läuft in UTC, daher landet ein Start um 06:00 Uhr in einer anderen lokalen Stunde für jedes Team. Schreiben Sie die Zeitzone in das Runbook, damit niemand durch das Log überrascht wird.

Fragen zum Ausführen des Audits

Die meisten dieser Fragen stammen von Teams, die den Job zum ersten Mal geplant haben.

Ist dies eine Google Backlink-Checker-API?

Es ist ein Audit, das auf unserer eigenen API aufgebaut ist, kein Google-Produkt. Google veröffentlicht keine allgemeine Backlink-API, daher stammen die Zahlen von unserem eigenen Crawler und unserem eigenen Index.

Kann das Audit bei jedem Build ausgeführt werden?

Das geht, aber ein monatlicher refdomains-Abruf muss nicht bei jedem Build ausgeführt werden. Führen Sie die kostenlose Übersicht bei jeder Veröffentlichung aus und die bezahlten Abrufe einmal im Monat.

Brauche ich das Audit immer noch, wenn ich ein Gate habe?

Ja, wenn Sie über Plugins oder ein CDN veröffentlichen. Das Gate sieht Ihren Entwurf, und das Audit sieht die Live-Seite. Jede fängt Fehler ab, die die andere nicht sehen kann.

Was passiert, wenn der Job mittendrin fehlschlägt?

Schreiben Sie das Ergebnis jedes Schritts in eine eigene Datei, damit ein fehlgeschlagener Pull die Übersicht intakt lässt. Führen Sie den fehlgeschlagenen Schritt erneut aus, anstatt von vorne zu beginnen, um zu vermeiden, für denselben Pull doppelt zu bezahlen.

Wie viele Credits sollte ich pro Seite einplanen?

Planen Sie 4 Credits pro Seite und Monat für die beiden bezahlten Abrufe ein, plus alles, was Ihr Gate für Entwürfe ausgibt. Die kostenlose Übersicht fügt dieser Zahl nichts hinzu, und das Log zeigt die tatsächliche Gesamtsumme.

Warum stimmen zwei Runs, die einige Tage auseinanderliegen, nicht überein?

Der Index aktualisiert sich etwa einmal im Monat, daher sind tägliche Änderungen normalerweise Rauschen. Vergleichen Sie die Momentaufnahme dieses Monats mit der vom letzten Monat, bevor Sie einen Vorfall eröffnen.