Länkrevision efter publicering med GitHub Actions eller vanlig cron
Inlägget är live och pipeline-processen är inte avslutad. Denna körbok lägger till en schemalagd revision som registrerar länkdata per webbplats och meddelar en person endast när något verkar felaktigt.
SEOBlogBot forskningsgrupp ·
Varför göra en revision efter publicering överhuvudtaget
En kontrollpunkt ser ett utkast. En revision ser vad den live-sajten faktiskt gör. Insticksmoduler kan skriva om länkar, redaktörer kan klistra in affiliate-omdirigeringar över rena URL:er, och en CDN-migrering kan ändra en värd till en annan. Inget av detta finns i utkaststadiet, vilket är varför en körning efter publicering är den första platsen där detta kan visas.
En användbar revision är tråkig av design. Den körs enligt schema, skriver en rad och håller tyst såvida inget undantag utlöses. Tystnad är målet. En månad med tysta loggar betyder att jobbet fungerar, inte att det är inaktivt.
Det finns ingen officiell Google Backlink Checker API för allmänt bruk, vilket är varför team använder ett tredjeparts länkindex istället. Det är vår egen crawler. Search Console visar Googles vy av dina egna länkar, och revisionen kompletterar den snarare än att ersätta den.
Var jobbet körs
Skriv ner utlösaren. Tre uppsättningar täcker de flesta team, och varje en kör samma anrop. Loggen är viktigare än utlösaren, eftersom datum, URL och använda krediter ska landa där varje gång.
GitHub Actions för ett arkiv
Om sajten byggs från ett arkiv lägger en schemalagd workflow till minst friktion. Jobbet finns bredvid koden, och nyckeln ligger i arkivets hemliga lagring. Workflow-filen längre ner är det minimum du behöver. Behåll den i arkivet, granskad som annan kod, och lås versionsnumren för de åtgärder du är beroende av.
En vanlig server med cron
Team som redan håller en maskin för sin byggprocess kan schemalägga samma kommandon där. Ett verktyg som n8n kan köra dem via ett steg för att utföra kommandon, eller en crontab-rad kan köra dem direkt. På båda sätten bör jobbet köras som en användare som kan läsa nyckeln och inget annat.
En webhook från ditt CMS
Vissa CMS-uppsättningar utlöser en webhook när ett inlägg publiceras, och den händelsen kan starta revisionen. Kontrollen körs då i ögonblicket som inlägget blir offentligt. Behåll en schemalagd körning också, eftersom en enda missad webhook lämnar ett inlägg okontrollerat.
Körboken, i ordning
01
Utlös vid publicering och igen 30 dagar senare
En körning direkt efter att inlägget är live kontrollerar de externa värdarna. En andra körning en månad senare läser refdomains för din webbplats, eftersom indexet uppdateras ungefär en gång i månaden och en tidigare läsning skulle visa inget nytt.
02
Anropa den fria översikten först
action=overview returnerar webbplatsens sammanfattningsnummer utan kostnad. Spara dem som grundraden för denna körning, med datumet bredvid.
03
Hämta de betalda listorna endast vid förändring
Om överskikten skiljer sig från förra månaden, anropa refdomains (2 krediter) och anchors (2 krediter) och jämför med de sparade listorna.
04
Skriv en rad till en logg
Datum, inläggets URL, gjorda anrop, _credits-saldo. En vanlig CSV som commitas till ett privat arkiv räcker.
05
Varna endast vid undantag
HTTP 401, HTTP 402, ett tomt resultat för en webbplats som hade rader förra månaden, eller en betygsminskning på 10 poäng eller mer.
Vilka webbplatser att revidera
Börja med domänen som värdar inlägget. Kör sedan samma revision mot två eller tre konkurrenter som du vill jämföra dig med. Använd compare för det. Det tar upp till 20 domäner för 1 kredit, så kontrollen av konkurrenterna kostar nästan ingenting.
Hoppa över den långa svansen. Varje extra webbplats tillför brus till en logg som en person måste läsa. En jämförelse av tjugo orelaterade domäner berättar mycket lite om din egen.
Att hålla nyckeln borta från loggarna
Ett schemalagt jobb läser sin nyckel vid varje körning, så det behöver aldrig ett inloggningssteg. Det enda att skydda är nyckeln i sig. Den har tre uppenbara läckage: en commit, en utskriven miljö och en URL som en proxy registrerar. Stäng varje en.
Använd den hemliga lagringen, inte en fil i arkivet
Klistra in nyckeln i din CI-leverantörs hemliga lagring, eller i en miljöfil som endast jobbets användare kan läsa. Commita den aldrig. Ett steg som skriver ut sin miljö kommer att skriva ut den, så skriv inte ett sådant.
Skicka nyckeln i en header
Bearer-headern håller nyckeln borta från de flesta åtkomstloggar, eftersom URL:er registreras medan headers vanligtvis inte gör det. Query-string-formen fungerar också, men den lämnar en kopia i varje proxy som ser begäran.
Begränsa vem som kan läsa lagringen
Ge läsrättigheter till de personer som underhåller jobbet och ingen annan. Granska den listan när jobbet byter ägare.
En nyckel som många kan läsa är en nyckel som en dag kommer att klistras in i ett chattfönster.
Validera svaret innan du skriver ner det
Ett svar som anländer är inte ännu ett svar du kan använda. Använd en ordning varje gång. Skriv endast vad som godkänns, och logga resten. Ett avvisat svar är bevis, och nästa person som felsöker jobbet kommer att vilja se det.
Kontrollera status och ok först
Läs HTTP-statuskoden, sedan ok-fältet i kroppen. En 200 med ok satt till false är fortfarande ett misslyckat anrop, och loggen bör säga så.
Parsera JSON:n innan något skrivs
Bekräfta att kroppen är giltig JSON innan du packar upp, parserar eller lägger till något. En avbruten nedladdning kan hända på en instabil runner. En trasig fil som skrivs till loggen ser bra ut tills någon öppnar den.
Behandla en tom lista som en fråga
Ett tomt resultat för en webbplats som hade rader förra månaden är en fråga, inte en fakta. Kontrollera stavningen av domänen, inklusive en inledande www., innan någon får en varning.
En workflow-fil att börja med
Spara nyckeln som en arkivhemlighet med namnet SBB_KEY. Cron-uttrycket körs den första i varje månad kl. 06:00 UTC.
Förlorade länkar eller en stor uppdateringsförändring
Hämta refdomains och diff:a
Cron på en vanlig server
Samma kommandon körs från en crontab-rad. Behåll nyckeln i en miljöfil som endast jobbets användare kan läsa, och logga till en fil du roterar.
Kostnader och var du kan läsa dem
En månatlig revision för en webbplats kostar 4 krediter när du hämtar båda listorna, vilket är $0.0004. Översiktsanropet är gratis. En månad utan förändring kostar därför inget utöver det.
Om ditt team publicerar tio inlägg om dagen över flera webbplatser är revisionen fortfarande ett månatligt jobb per webbplats, inte ett jobb per inlägg. Det håller antalet litet och loggen läsbar.
När du lägger till en andra webbplats, kopiera jobbet snarare än att utvidga det. En workflow per domän håller loggen per webbplats och gör ett misslyckande lätt att spåra tillbaka till dess ägare.
Den större kostnaden är vanligtvis din CI-leverantörs minuter, inte våra krediter. Kostnadstabellen sätter båda raderna sida vid sida, så att du kan bestämma vilken du ska justera först.
Be den första körningen att skriva ut _credits. Lita på svaret snarare än någon tabell. Portkontrollguiden täcker kontrollen i utkaststadiet som kommer före denna.
GitHub-schemat körs i UTC, så en start kl. 06:00 landar vid en annan lokal tid för varje team. Skriv ner tidszonen i körboken så att ingen blir överraskad av loggen.
Frågor om att köra revisionen
De flesta av dessa frågor kommer från team som precis har schemalagt jobbet för första gången.
Är detta en google backlink checker API?
Det är en revision byggd på vår egen API, inte en Google-produkt. Google publicerar ingen allmän backlink-API, så siffrorna kommer från vår egen crawler och vårt eget index.
Kan revisionen köras vid varje bygg?
Det kan det, men en månatlig refdomains-hämtning behöver inte köras vid varje bygg. Kör den fria översikten vid varje publicering, och de betalda hämtningarna en gång i månaden.
Behöver jag fortfarande revisionen om jag har en portkontroll?
Ja, om du publicerar via insticksmoduler eller en CDN. Portkontrollen ser ditt utkast, och revisionen ser den live-sidan. Var och en fångar misslyckanden som den andra inte kan se.
Vad händer om jobbet misslyckas mitt i?
Skriv varje stegs resultat till sin egen fil, så att ett misslyckad hämtning lämnar översikten intakt. Kör om från det misslyckade steget snarare än från toppen, vilket undviker att betala för samma hämtning två gånger.
Hur många krediter ska jag budgetera för varje webbplats?
Budgetera 4 krediter per webbplats och månad för de två betalda hämtningarna, plus vad din portkontroll spenderar på utkast. Den fria översikten lägger inget till det beloppet, och loggen visar den verkliga totalen.
Varför håller två körningar några dagar ifrån varandra inte med varandra?
Indexet uppdateras ungefär en gång i månaden, så dagliga förändringar är vanligtvis brus. Jämför denna månads ögonblicksbild med förra månadens innan du öppnar en incident.
Körboksgodkännande
Hemligheten finns och workflow har körts en gång för hand.
Loggfilen registrerar datum, URL, anrop och _credits.
Någon äger varningskanalen.
Jobbet behandlar månatliga data som månatliga.
Ett misslyckande av revisionen i sig sidar en person.
