Audit link post-publicare cu GitHub Actions sau cron simplu
Postarea este live, iar pipeline-ul nu este finalizat. Acest manual adaugă un audit programat care înregistrează datele linkurilor per site și informează o persoană doar când ceva pare greșit.
Echipa de cercetare SEOBlogBot ·
De ce auditați după publicare
O poartă vede un draft. Un audit vede ce face de fapt site-ul live. Pluginurile rescriu linkurile, editorii lipesc redirectări affiliate peste URL-uri curate, iar o migrare CDN poate transforma un host în altul. Nimic din acestea nu există în stadiul de draft, motiv pentru care un rulaj post-publicare este primul loc în care pot apărea.
Un audit util este plictisitor prin design. Rulează la intervale, scrie o singură linie și rămâne în tăcere decât dacă se declanșează o excepție. Tăcerea este obiectivul. O lună de jurnale liniștite înseamnă că jobul funcționează, nu că este inactiv.
Nu există un API oficial Google Backlink Checker pentru uz general, motiv pentru care echipele apelează la un index de linkuri terț. Este crawler-ul nostru. Search Console arată perspectiva Google asupra linkurilor tale, iar auditul completează această perspectivă, nu o înlocuiește.
Unde rulează jobul
Notează declanșatorul. Trei configurații acoperă majoritatea echipelor, iar fiecare rulează aceleași apeluri. Jurnalul este mai important decât declanșatorul, deoarece data, URL-ul și creditele utilizate trebuie să ajungă acolo de fiecare dată.
GitHub Actions pentru un repository
Dacă site-ul se construiește dintr-un repository, un workflow programat adaugă cea mai mică frecare. Jobul trăiește lângă cod, iar cheia se află în stocul de secrete al repository-ului. Fișierul de workflow de mai jos este minimul necesar. Păstrează-l în repository, revizuit ca orice alt cod, și fixează versiunile de acțiuni pe care te bazezi.
Un server simplu cu cron
Echipele care dețin deja o mașină pentru build pot programa aceleași comenzi acolo. Un instrument precum n8n le poate rula printr-un pas Execute Command, sau o linie crontab le poate rula direct. În orice caz, jobul ar trebui să ruleze ca un utilizator care poate citi cheia și nimic altceva.
Un webhook de la CMS-ul tău
Unele configurații CMS generează un webhook când o postare devine live, iar acest eveniment poate declanșa auditul. Verificarea rulează atunci când postarea este publică. Păstrează și un rulaj programat, deoarece un singur webhook ratat lasă o postare neauditată.
Manualul de execuție, în ordine
01
Declanșare la publicare și din nou la 30 de zile
Un rulaj imediat după ce postarea este live verifică hosturile outbound. Un al doilea rulaj la o lună distanță citește refdomains pentru site-ul tău, deoarece indexul se reîmprospătează aproximativ lunar, iar o citire anterioară nu ar arăta nimic nou.
02
Apelă mai întâi overview gratuit
action=overview returnează cifrele principale ale site-ului fără cost. Stochează-le ca rândul de bază pentru acest rulaj, alături de dată.
03
Extrage listele plătite doar la schimbare
Dacă overview-ul diferă de luna trecută, apelează refdomains (2 credite) și anchors (2 credite) și compară cu listele stocate.
04
Scrie o singură linie într-un jurnal
Dată, URL postare, apeluri efectuate, balanța _credits. Un CSV simplu commitat într-un repo privat este suficient.
05
Alertează doar la excepții
HTTP 401, HTTP 402, un rezultat gol pentru un site care avea rânduri luna trecută, sau o scădere a ratingului cu 10 puncte sau mai mult.
Ce site-uri să auditezi
Începe cu domeniul care găzduiește postarea. Apoi rulează același audit împotriva a două sau trei parteneri pe care vrei să îi benchmark-uiești. Folosește compare pentru asta. Acceptă până la 20 de domenii pentru 1 credit, astfel încât verificarea partenerilor costă aproape nimic.
Sari peste coada lungă. Fiecare site suplimentar adaugă zgomot într-un jurnal pe care o persoană trebuie să îl citească. Un benchmark de douăzeci de domenii neînrudite îți spune foarte puțin despre al tău.
Menținerea cheii în afara jurnalelor
Un job programat își citește cheia la fiecare rulare, astfel încât nu are nevoie de un pas de autentificare. Singurul lucru de protejat este cheia însăși. Are trei scurgeri evidente: un commit, un mediu tipărit și un URL pe care un proxy îl înregistrează. Închide fiecare una.
Folosește stocul de secrete, nu un fișier în repo
Lipește cheia în stocul de secrete al furnizorului CI, sau într-un fișier de mediu pe care doar utilizatorul jobului îl poate citi. Nu-l commit niciodată. Un pas care face echo la mediul său va tipări cheia, deci nu scrie unul.
Trimite cheia într-un header
Headerul Bearer menține cheia în afara majorității jurnalelor de acces, deoarece URL-urile sunt înregistrate, iar headerurile de obicei nu. Forma query-string funcționează și ea, dar lasă o copie în fiecare proxy care vede cererea.
Limitează cine poate citi stocul
Oprește accesul de citire persoanelor care întrețin jobul și nimănui altcuiva. Revizuiește această listă când jobul trece la altcineva.
O cheie pe care mulți oameni o pot citi este o cheie care va ajunge lipită într-o fereastră de chat într-o zi.
Validează răspunsul înainte să îl scrii
Un răspuns care ajunge nu este încă un răspuns pe care îl poți folosi. Folosește o ordine de fiecare dată. Scrie doar ce trece și loghează restul. Un răspuns respins este dovadă, iar următoarea persoană care debug-uiește jobul va vrea să îl vadă.
Verifică statusul și ok mai întâi
Citește codul de status HTTP, apoi câmpul ok din body. Un 200 cu ok setat la false este tot o apelare eșuată, iar jurnalul ar trebui să spună asta.
Analizează JSON înainte de orice scriere
Confirmă că body-ul este JSON valid înainte să dezarhivezi, să analizezi sau să adaugi orice. Un download trunchiat poate apărea pe un runner instabil. Un fișier corupt scris în jurnal arată bine până când cineva îl deschide.
Tratează o listă goală ca pe o întrebare
Un rezultat gol pentru un site care avea rânduri luna trecută este o întrebare, nu un fapt. Verifică ortografia domeniului, inclusiv www. la început, înainte ca cineva să primească o alertă.
Un fișier de workflow de la care să începi
Stochează cheia ca un secret de repository numit SBB_KEY. Expresia cron rulează în prima zi a fiecărei luni la 06:00 UTC.
Index în curs de reîmprospătare sau greșeală de tastare în domeniu
Reîncearcă într-o zi; verifică pentru www.
Ratingul s-a mutat câțiva puncte
Reîmprospătare lunară
Nu face nimic; uită-te la trend
Ratingul a scăzut 10+
Linkuri pierdute sau o schimbare mare de reîmprospătare
Extrage refdomains și compară
Cron pe un server simplu
Aceleași comenzi rulate dintr-o linie crontab. Păstrează cheia într-un fișier de mediu pe care doar utilizatorul jobului îl poate citi și loghează într-un fișier pe care îl rotești.
Costuri și unde să le citești
Un audit lunar pentru un site costă 4 credite când extragi ambele liste, ceea ce este $0.0004. Apelul overview este gratuit. O lună fără schimbare costă deci nimic în plus.
Dacă echipa ta publică zece postări pe zi pe mai multe site-uri, auditul rămâne un job lunar per site, nu un job per postare. Acest lucru menține numărul mic și jurnalul lizibil.
Când adaugi un al doilea site, copiază jobul în loc să îl lărgești. Un workflow per domeniu menține jurnalul per site și face un eșec ușor de urmărit înapoi la proprietarul său.
Costul mai mare este de obicei minutele furnizorului tău CI, nu creditele noastre. Tabelul de costuri pune ambele linii una lângă alta, astfel încât să poți decide care să o optimizezi mai întâi.
Cere ca primul rulaj să tipărească _credits. Ai încredere în răspuns mai presus de orice tabel. Ghidul de poartă acoperă verificarea din faza de draft care vine înainte de aceasta.
Programarea GitHub rulează în UTC, astfel încât un start la 06:00 ajunge la o oră locală diferită pentru fiecare echipă. Scrie fusul orar în manualul de execuție astfel încât nimeni să nu fie surprins de jurnal.
Întrebări despre rularea auditului
Majoritatea acestor întrebări vin de la echipe care tocmai au programat jobul pentru prima dată.
Este acesta un API Google Backlink Checker?
Este un audit construit pe propriul nostru API, nu un produs Google. Google nu publică un API general de backlinkuri, astfel încât cifrele vin de la crawler-ul nostru și indexul nostru.
Poate auditul să ruleze la fiecare build?
Poate, dar o extragere lunară refdomains nu trebuie să ruleze la fiecare build. Rulează overview gratuit la fiecare publicare, iar extragerile plătite o dată pe lună.
Am nevoie încă de audit dacă am o poartă?
Da, dacă publici prin pluginuri sau un CDN. Poarta vede draftul tău, iar auditul vede pagina live. Fiecare prinde eșecuri pe care celălalt nu le poate vedea.
Ce se întâmplă dacă jobul eșuează pe jumătate?
Scrie rezultatul fiecărui pas într-un fișier separat, astfel încât o extragere eșuată să lase overview-ul intact. Re-rulează de la pasul eșuat, nu de la început, ceea ce evită plata pentru aceeași extragere de două ori.
Câte credite ar trebui să bugetez pentru fiecare site?
Bugetează 4 credite per site pe lună pentru cele două extrageri plătite, plus orice cheltuie poarta ta pe drafturi. Overview-ul gratuit nu adaugă nimic la această cifră, iar jurnalul îți spune totalul real.
De ce se ceartă două rulări la câteva zile distanță?
Indexul se reîmprospătează aproximativ o dată pe lună, astfel încât schimbările de zi cu zi sunt de obicei zgomot. Compară snapshot-ul acestei luni cu cel al lunii trecute înainte să deschizi un incident.
Semnătura manualului de execuție
Secretul există și workflow-ul a rulat o dată manual.
Fișierul jurnal înregistrează data, URL-ul, apelurile și _credits.
