Linkaudit na publicatie met GitHub Actions of gewone cron
De post is live en de pipeline is nog niet klaar. Dit runbook voegt een gescheduled audit toe die linkgegevens per site registreert en alleen een persoon informeert als er iets mis lijkt te zijn.
SEOBlogBot research team ·
Waarom überhaupt auditen na publicatie
Een gate ziet een draft. Een audit ziet wat de live site daadwerkelijk doet. Plugins herschrijven links, editors plakken affiliate-omleidingen over schone URLs, en een CDN-migratie kan één host in een andere veranderen. Niets daarvan bestaat in de draftfase, vandaar dat een post-publish run de eerste plek is waar het naar voren kan komen.
Een nuttige audit is saai door ontwerp. Hij draait op een schema, schrijft één regel en blijft stil tenzij er een uitzondering optreedt. Stilte is het doel. Een maand stille logs betekent dat de taak werkt, niet dat hij inactief is.
Er is geen officiële Google backlink checker API voor algemeen gebruik, vandaar dat teams een third-party link index aanspreken. Het is onze eigen crawler. Search Console toont Googles weergave van je eigen links, en de audit vult dit aan in plaats van het te vervangen.
Waar de taak draait
Schrijf de trigger op. Drie setup's dekken de meeste teams, en elke setup voert dezelfde calls uit. De log is belangrijker dan de trigger, omdat de datum, de URL en de gebruikte credits elke keer daar moeten landen.
GitHub Actions voor een repository
Als de site bouwt vanuit een repository, voegt een gescheduled workflow de minste wrijving toe. De taak leeft naast de code, en de sleutel zit in de secret store van de repository. Het workflow-bestand hieronder is het minimum dat je nodig hebt. Houd het in de repository, beoordeeld als elke andere code, en pin de action-versies waarop je vertrouwt.
Een gewone server met cron
Teams die al een machine voor hun build onderhouden, kunnen dezelfde commando's daar plannen. Een tool zoals n8n kan ze uitvoeren via een Execute Command-stap, of een crontab-regel kan ze direct uitvoeren. Op beide manieren moet de taat draaien als een gebruiker die de sleutel kan lezen en niets anders.
Een webhook van je CMS
Sommige CMS-setup's sturen een webhook wanneer een post live gaat, en dat evenement kan de audit starten. De check draait dan op het moment dat de post publiek is. Houd ook een gescheduled run aan, omdat een enkele gemiste webhook een post ongecontroleerd laat.
Het runbook, in volgorde
01
Trigger op publicatie en opnieuw 30 dagen later
Een run direct na de publicatie van de post controleert de outbound hosts. Een tweede run een maand later leest refdomains voor jouw site, omdat de index ongeveer maandelijks ververst en een eerdere read niets nieuws zou tonen.
02
Roep eerst de gratis overview aan
action=overview retourneert de kopcijfers van de site zonder kosten. Sla ze op als de baseline-rij voor deze run, met de datum ernaast.
03
Haal de betaalde lijsten alleen op bij wijziging
Als de overview verschilt van vorige maand, roep dan refdomains (2 credits) en anchors (2 credits) aan en diff ze tegen de opgeslagen lijsten.
04
Schrijf één regel naar een log
Datum, post-URL, uitgevoerde calls, _credits saldo. Een gewone CSV die naar een private repo wordt gecommit is genoeg.
05
Alert alleen op uitzonderingen
HTTP 401, HTTP 402, een lege resultaat voor een site die vorige maand rijen had, of een rating-daling van 10 punten of meer.
Welke sites auditen
Begin met het domein dat de post host. Voer daarna dezelfde audit uit tegen twee of drie peers die je wilt benchmarken. Gebruik daarvoor compare. Het kost maximaal 20 domeinen voor 1 credit, dus de peer-check kost bijna niets.
Sla de lange staart over. Elke extra site voegt ruis toe aan een log die een persoon moet lezen. Een benchmark van twintig ongerelateerde domeinen vertelt je weinig over jouw eigen site.
De sleutel buiten de logs houden
Een gescheduled job leest zijn sleutel bij elke run, dus het heeft geen sign-in stap nodig. Het enige dat je moet beschermen is de sleutel zelf. Er zijn drie voor de hand liggende lekken: een commit, een afgedrukte omgeving en een URL die een proxy registreert. Sluit elk van deze.
Gebruik de secret store, geen bestand in de repo
Plak de sleutel in de secret store van je CI-provider, of in een environment-bestand dat alleen de gebruiker van de job kan lezen. Commit het nooit. Een stap die zijn omgeving echoot zal het afdrukken, dus doe dat niet.
Stuur de sleutel in een header
De Bearer-header houdt de sleutel buiten de meeste access logs, omdat URLs worden geregistreerd en headers meestal niet. De query-string-vorm werkt ook, maar laat een kopie achter in elke proxy die het verzoek ziet.
Beperk wie de store kan lezen
Geef leestoegang aan de mensen die de job onderhouden en aan niemand anders. Beoordeel die lijst wanneer de job van eigenaar wisselt.
Een sleutel die veel mensen kunnen lezen is een sleutel die op een dag in een chatvenster wordt geplakt.
Valideer het antwoord voordat je het opschrijft
Een antwoord dat aankomt is nog geen antwoord dat je kunt gebruiken. Gebruik elke keer dezelfde volgorde. Schrijf alleen wat slaagt, en log de rest. Een afgewezen antwoord is bewijs, en de volgende persoon die de job debugt zal dat willen zien.
Controleer eerst de status en ok
Lees de HTTP-statuscode, dan het ok veld in de body. Een 200 met ok ingesteld op false is nog steeds een mislukte call, en de log moet dat zeggen.
Parse de JSON voordat je iets schrijft
Bevestig dat de body geldige JSON is voordat je iets unzipt, parse of append. Een afgekapte download kan gebeuren op een wispelturige runner. Een kaputt bestand dat naar de log wordt geschreven ziet er goed uit totdat iemand het opent.
Behandel een lege lijst als een vraag
Een leeg resultaat voor een site die vorige maand rijen had is een vraag, geen feit. Controleer de spelling van het domein, inclusief een voorloop www., voordat iemand een alert krijgt.
Een workflow-bestand om vanaf te starten
Sla de sleutel op als een repository secret met de naam SBB_KEY. De cron-uitdrukking draait op de eerste van elke maand om 06:00 UTC.
Index verversing in uitvoering of typo in het domein
Probeer het over een dag opnieuw; controleer op www.
Rating is een paar punten verschoven
Maandelijkse verversing
Niets doen; kijk naar de trend
Rating daalde met 10+
Links verloren of grote verandering in verversing
Haal refdomains op en diff ze
Cron op een gewone server
Dezelfde commando's draaien vanuit een crontab-regel. Houd de sleutel in een environment-bestand dat alleen de gebruiker van de job kan lezen, en log naar een bestand dat je roteert.
Kosten en waar ze te lezen zijn
Een maandelijkse audit voor één site kost 4 credits als je beide lijsten ophaalt, wat $0.0004 is. De overview call is gratis. Een maand zonder wijziging kost dus niets boven de gratis overview.
Als je team tien posts per dag publiceert over meerdere sites, is de audit nog steeds één maandelijkse taak per site, niet één taak per post. Dat houdt het aantal klein en de log leesbaar.
Als je een tweede site toevoegt, kopieer dan de taak in plaats van deze te verbreden. Eén workflow per domein houdt de log per site en maakt een fout makkelijk traceerbaar naar de eigenaar.
De hogere kosten zijn meestal de minuten van je CI-provider, niet onze credits. De cost table zet beide lijsten naast elkaar, zodat je kunt beslissen welke je eerst wilt optimaliseren.
Laat de eerste run _credits printen. Vertrouw het antwoord boven elke tabel. De gate guide behandelt de check aan de draft-kant die hieraan voorafgaat.
De GitHub schedule draait in UTC, dus een start om 06:00 valt op een ander lokaal uur voor elk team. Schrijf de tijdzone in het runbook zodat niemand verrast wordt door de log.
Vragen over het uitvoeren van de audit
De meeste van deze vragen komen van teams die de taak net voor de eerste keer hebben gescheduled.
Is dit een google backlink checker API?
Het is een audit gebouwd op onze eigen API, geen Google-product. Google publiceert geen algemene backlink API, dus de cijfers komen van onze eigen crawler en onze eigen index.
Kan de audit bij elke build draaien?
Dat kan, maar een maandelijkse refdomains pull hoeft niet bij elke build te draaien. Roep de gratis overview aan bij elke publicatie, en de betaalde pulls één keer per maand.
Heb ik de audit nog nodig als ik een gate heb?
Ja, als je publiceert via plugins of een CDN. De gate ziet je draft, en de audit ziet de live pagina. Elke vangt fouten op die de ander niet kan zien.
Wat als de taak halverwege faalt?
Schrijf het resultaat van elke stap naar zijn eigen bestand, zodat een mislukte pull de overview intact laat. Run opnieuw vanaf de mislukte stap in plaats van vanaf het begin, wat voorkomt dat je voor dezelfde pull betaalt.
Hoeveel credits moet ik per site reserveren?
Reserveer 4 credits per site per maand voor de twee betaalde pulls, plus wat je gate uitgeeft aan drafts. De gratis overview voegt niets toe aan dat bedrag, en de log vertelt je het echte totaal.
Waarom verschillen twee runs een paar dagen uit elkaar?
De index ververst ongeveer één keer per maand, dus dag-tot-dag veranderingen zijn meestal ruis. Vergelijk de snapshot van deze maand met die van vorige maand voordat je een incident opent.
Runbook goedkeuring
De secret bestaat en de workflow is één keer handmatig gedraaid.
Het logbestand registreert datum, URL, calls en _credits.
Iemand is eigenaar van het alert kanaal.
De taat behandelt maandelijkse data als maandelijk.
