Verificarea backlink-urilor la publicare, pas cu pas
Un webhook, un apel HTTP, o decizie. Acest manual ghidează o echipă CMS headless prin hook, apeluri și cazurile de eroare.
Echipa de cercetare Contentin ·
Stabiliți ce poate face poarta
O verificare a backlink-urilor într-un flux de lansare este o sarcină mică. Păstrați-o simplă. Partea dificilă este să decideți ce răspuns este permis să se schimbe, deoarece un graf de link-uri care se reîmprospătează lunar nu poate respinge o pagină pe cont propriu.
Sugerăm ca poarta să avertizeze, să înregistreze și să permită continuarea build-ului. Valorile implicite se pot schimba. Blocările stricte aparțin lucrurilor pe care le controlați, cum ar fi markup-ul defect sau lipsa tag-ului canonical. Datele despre link-uri sunt un semnal, iar semnalele se pot deforma.
Scrieți politica. Faceți acest lucru înainte de a scrie codul. O politică pe un rând precum „avertizează editorul, marchează intrarea, nu opriți niciodată deploy-ul” salvează o discuție lungă în ora 18:00 în ziua lansării. De asemenea, îi spune următorului inginer care erori au fost intenționate și care bug-uri, lucru care contează mai mult decât pare. Revedeți-o o dată pe trimestru.
Șase pași de la clicul de publicare la nota stocată
1
Alegeți declanșatorul
Abonați-vă la evenimentul de publicare al CMS-ului dvs. Contentful, Sanity și Strapi pot apela o URL pe care o dețineți când o intrare este publicată, iar Storyblok și Payload oferă, de asemenea, webhooks sau hook-uri. Filtrați tipurile de conținut care conțin URL-uri outbound sau canonice.
2
Reduceți URL-ul la un domeniu
API-ul acceptă un domeniu în q, așa că https://www.example.com/blog/post?x=1 trebuie să devină mai întâi example.com. Decideți o dată cum tratați www și testați un domeniu real pe acțiunea gratuită domain înainte de a construi orice.
3
Apelați mai întâi acțiunea gratuită
overview nu costă nimic. Dacă răspunsul este slab, domeniul poate fi nou sau pur și simplu necunoscut indexului nostru. Acesta nu este dovada a ceva rău.
4
Cheltuiți credite doar când se declanșează o regulă
Când regula dvs. spune să priviți mai îndeaproape, apelați backlinks cu per=100. Costă 2 credite, indiferent de numărul de rânduri, așa că cereți o pagină utilă de rânduri în loc de zece pagini mici.
5
Scrieți o notă, nu JSON-ul brut
Stocați un verdict scurt într-un câmp al dvs., împreună cu data verificării. Răspunsurile brute umflă intrările și se învechesc rapid, deoarece indexul se schimbă în fiecare lună.
6
Eșuați fin
HTTP 401 înseamnă că cheia lipsește sau este greșită, așa că alertați un om. HTTP 402 înseamnă că creditele s-au epuizat. Orice altă eroare: înregistrați-o, sari peste verificare, permiteți publicarea.
Unde se află cheia și ce ar trebui să facă un 402
Fiecare apel plătit conține cheia dvs., fie în șirul de interogare, fie într-un header Bearer. Preferați header-ul. Un șir de interogare poate ajunge în jurnalele serverului și în trace-urile proxy-ului, iar un header de obicei rămâne în afara lor.
Stocați cheia ca un secret în platforma dvs. de hosting, niciodată în intrarea însăși. Editorii pot citi orice câmp pe care îl pot deschide, dar mediul unei funcții este de obicei vizibil doar persoanelor care gestionează deploy-urile.
Unde ar trebui să trăiască cheia?
O cheie care scurge poate cheltui soldul din contul dvs., așa că tratați-o ca pe o parolă. Țineți-o în afara repository-ului și în afara CMS-ului și rotiți-o dacă un fișier log o afișează vreodată în text simplu.
Marcați jurnalele proprii cu numele hook-ului. Cheltuielile sunt apoi ușor de urmărit până la o singură funcție, chiar și când mai multe hook-uri împart același cont.
Poate un instrument no-code să facă apelul?
Da, atunci când instrumentul are un pas de cerere HTTP simplu. Multe platforme de automatizare pot trimite un GET cu un șir de interogare și pot citi JSON-ul înapoi, astfel încât acțiunea gratuită overview nu necesită deloc cod.
Începeți doar cu acțiunile gratuite. Un flux care se declanșează la fiecare salvare a unui draft poate cheltui credite mai repede decât observă un editor, așa că adăugați un pas plătit odată ce apelurile gratuite au rulat liniștit pentru o perioadă.
Ce ar trebui să declanșeze un 402?
Un 402 înseamnă că soldul este gol. Nu spune nimic despre pagină. Sari peste verificarea plătită, înregistrează evenimentul și trimite o singură alertă persoanei care alimentează contul, apoi permite publicarea.
Stablește o alarmă de sold mult deasupra zero, astfel încât avertismentul să ajungă în timp ce mai este timp pentru alimentare. Un ciclu de reîncercare nu va ajuta aici, deoarece fiecare apel eșuează în același mod până când cineva adaugă credit. Tabelul de costuri are cifrele.
Testează cele două apeluri din terminal
Rulează aceste o dată împotriva unui domeniu pe care îl cunoști înainte ca hook-ul să o facă pentru tine. Citește câmpul _credits din al doilea răspuns.
bash
# free, no key
curl -s "https://contentin.app/api.php?action=overview&q=example.com"
# 2 credits, key in a header
curl -s -H "Authorization: Bearer sk_live_..." \
"https://contentin.app/api.php?action=backlinks&q=example.com&per=100"
Ce domeniu se introduce în parametrul q
API-ul acceptă un domeniu simplu în q, așa că un URL complet trebuie mai întâi redus. Scrie această reducere o dată, într-o singură funcție. Apoi testeaz-o pe URL-uri reale.
Link-urile relative și schemele lipsă sunt cazurile care de obicei strică un hook. O reducere care funcționează pe exemple curate poate încă eșua pe URL-urile dezordonate pe care le lipsește editorul la ora 17:00.
Se schimbă răspunsul dacă este www?
Poate, iar modul onest de a afla este să întrebi. Rulează acțiunea gratuită domain pe ambele forme ale unui site pe care îl cunoști, apoi compară cele două răspunsuri unul lângă celălalt.
Indiferent de regula pe care o alegi, scrie-o într-un comentariu de cod astfel încât următorul inginer să nu trebuiască să ghicească. Un comentariu nu costă nimic și salvează o discuție lungă mai târziu.
Ce despre redirectări și subdomenii?
Trimite gazda pe care ajung efectiv cititorii tăi, nu link-ul pe care l-a lipit editorul acum câțiva ani. Dacă acel link face redirect, reduce adresa finală și ignoră hop-ul intermediar.
Un blog pe un subdomeniu este o decizie de judecată. Decide din timp dacă este verificat separat sau împreună cu domeniul părinte și scrie acea alegere lângă regulă.
Listă de verificare pre-lansare pentru hook
Hook-ul se declanșează doar la publicare, nu la fiecare salvare a draft-ului
URL-ul este redus la un domeniu simplu înainte de apel
Acțiunile gratuite rulează prima dată, iar creditele se cheltuiesc doar pe un flag
Un 401 și un 402 au fiecare propria alertă și propriul mesaj
Se setează un timeout, astfel încât un API lent să nu blocheze niciodată un editor
Nota stocată are o dată, astfel încât nimeni să nu o confunde cu date live
Aceeași intrare publicată de două ori nu facturează de două ori (vezi lista de mituri)
Ce să înregistrezi și ce să lași în afara intrării
O linie de log pentru fiecare verificare sărită este cea mai ieftină urmă de audit pe care o poți construi. Înregistrează ID-ul intrării, domeniul trimis, codul de status și dacă un pas plătit a rulat. De obicei, asta este suficient.
Nota stocată rămâne scurtă și datată, așa cum spun pașii de mai sus. Răspunsurile complete aparțin propriilor dvs. jurnale, dacă aparțin undeva, deoarece sunt mari și se învechesc rapid.
Ce câmpuri aparțin unei linii de log?
Începe cu ID-ul intrării și versiunea de publicare. Un webhook repetat va apărea apoi ca aceeași pereche de două ori, ceea ce este exact ceea ce vrei să vezi.
Adaugă domeniul, numele acțiunii, codul de status și ora la care a început apelul. Lasă cheia în sine în afara, deoarece un log care o conține devine un al doilea loc unde trăiesc secretele.
Cât ar trebui să trăiască o notă stocată?
Atât timp cât intrarea trăiește, decât dacă un control mai nou o înlocuiește. Ceea ce contează este ca un cititor să poată spune cât de veche este nota, deoarece o notă din acum câteva luni se citește ca date live.
Ghidul câmpului scor arată cele patru câmpuri pe care le sugerăm pentru acea notă, inclusiv data.
Testează hook-ul pe staging înainte de lansare
Rulează aceste patru verificări înainte ca cineva să se bazeze pe hook.
1
Rejoacă o publicare trecută
Declanșează hook-ul cu o copie a unei intrări pe care ai publicat-o deja. Compară nota stocată cu ceea ce te așteptai și confirmă că aceeași intrare nu a fost facturată de două ori.
2
Încearcă un domeniu înregistrat recent
Folosește un domeniu partener care este nou pentru tine. Un răspuns gol sau slab ar trebui stocat ca necunoscut, nu ca o eroare, iar nota ar trebui să spună acest lucru în cuvinte simple.
3
Forțează un 402 în mod intenționat
Rulează hook-ul cu o cheie pe un cont de test al cărui sold l-ai golit. Confirmă că skip-ul, linia de log și alerta se declanșează toate, și că publicarea ajunge încă la build.
4
Citește mesajul pe care îl vede editorul
Cere cuiva din afara echipei să citească textul de eroare cu voce tare. Dacă nu pot spune ce să facă mai departe, rescrie mesajul înainte de ziua de lansare. Post-mortem arată cât a costat un mesaj vag o echipă inventată.
Ce nu poate vedea hook-ul
Indexul nostru se reîmprospătează aproximativ o dată pe lună. Un link adăugat după ultima reîmprospatare nu va apărea, iar un link eliminat de atunci poate încă să apară. Pentru dovadă în aceeași zi, folosește raportul Links din Google Search Console.