En sida för backlänkkontroll vid publicering, steg för steg
En webhook, ett HTTP-anrop, ett beslut. Denna runbok guidar ett headless CMS-team genom haken, anropen och felfallen.
Contentins forskningsgrupp ·
Bestäm vad grinden får göra
En backlänkkontroll i en lanseringsflöde är en liten uppgift. Håll den liten. Det svåra är att bestämma vad svaret får påverka, eftersom en länkgraf som uppdateras en gång i månaden inte kan stoppa en sida på egen hand.
Vi föreslår att grinden varnar, loggar och låter bygget fortsätta. Standardinställningar kan ändras. Hårda block hör till saker du kontrollerar, som trasig markup eller en saknad canonical-tag. Länkdata är en signal, och signaler förändras.
Skriv ner det. Gör det innan du kodar det. En policy på en rad, som "varna redaktören, tagga inlägget, stoppa aldrig lanseringen", sparar en lång diskussion kl. 18.00 på en lanseringsdag. Det berättar också för nästa ingenjör vilka fel som var avsedda och vilka som var buggar, vilket är viktigare än det låter. Granska det en gång i kvartalet.
Sex steg från publiceringsklick till lagrad anteckning
1
Välj utlösaren
Prenumerera på publiceringsevenemanget i ditt CMS. Contentful, Sanity och Strapi kan anropa en URL du äger när en post publiceras, och Storyblok och Payload erbjuder också webhooks eller hooks. Filtrera till de innehållstyper som innehåller utgående eller canonical-URL:er.
2
Reducera URL:en till en domän
API:et tar en domän i q, så https://www.example.com/blog/post?x=1 måste bli example.com först. Bestäm en gång hur du hanterar www och testa en riktig domän på den kostnadsfria domain-åtgärden innan du bygger något.
3
Kalla på den kostnadsfria åtgärden först
overview kostar ingenting. Om det kommer tillbaka tunt kan domänen vara ny eller helt enkelt okänd för vårt index. Det är inte bevis för något dåligt.
4
Använd krediter endast när en regel utlöses
När din regel säger att du ska titta närmare, anropa backlinks med per=100. Det är 2 krediter, oavsett antal rader, så be om en användbar sida med rader istället för tio små.
5
Skriv en anteckning, inte den råa JSON:en
Lagra en kort dom i ett fält i ditt eget system, plus datumet för kontrollen. Råa svar sväller in inlägg och åldras dåligt, eftersom indexet flyttas varje månad.
6
Misslyckas mjukt
HTTP 401 betyder att nyckeln saknas eller är felaktig, så varna en människa. HTTP 402 betyder att krediterna är slut. Alla andra fel: logga det, hoppa över kontrollen, låt publiceringen gå igenom.
Var nyckeln finns och vad en 402 ska göra
Varje betalt anrop innehåller din nyckel, antingen i query string eller i en Bearer-header. Föredra headern. En query string kan hamna i serverloggar och proxy-spår, och en header stannar vanligtvis utanför dem.
Lagra nyckeln som en hemlighet i ditt hostingplattform, aldrig i inlägget i sig. Redaktörer kan läsa alla fält de kan öppna, men en funktions miljö är vanligtvis synlig endast för de personer som hanterar lanseringar.
Var ska nyckeln bo?
En nyckel som läcker kan spendera saldot på ditt konto, så behandla den som ett lösenord. Håll den utanför lagret och utanför CMS:et, och rotera den om en loggfil någonsin visar den i klartext.
Tagga dina egna loggar med namnet på haken. Spendering blir då lätt att spåra tillbaka till en funktion, även när flera hooks delar samma konto.
Kan ett no-code-verktyg göra anropet?
Ja, när verktyget har ett steg för vanliga HTTP-förfrågningar. Många automatiseringsbyggare kan skicka en GET med en query string och läsa JSON:en tillbaka, så den kostnadsfria overview-åtgärden behöver ingen kod alls.
Börja med de kostnadsfria åtgärderna endast. Ett flöde som utlöses vid varje utkastsparning kan spendera krediter snabbare än en redaktör märker, så lägg till ett betalt steg när de kostnadsfria anropen har kört tyst en stund.
Vad ska en 402 utlösa?
En 402 betyder att saldot är tomt. Det säger inget om sidan. Hoppa över det betalda kontrollen, logga händelsen och skicka ett varningsmeddelande till den som fyller på kontot, låt sedan publiceringen gå igenom.
Ställ in en saldobegränsning väl över noll, så att varningen anländer medan det fortfarande finns tid att fylla på. En retry-loop hjälper inte här, eftersom varje anrop misslyckas på samma sätt tills någon lägger till kredit. Kostnadstabellen har siffrorna.
Testa de två anropen från en terminal
Kör dessa en gång mot en domän du känner till innan haken gör det för dig. Läs fältet _credits i det andra svaret.
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"
Vilken domän går in i q-parametern
API:et tar en bar domän i q, så en fullständig URL måste reduceras först. Skriv den reduceringen en gång, i en funktion. Testa den sedan på riktiga URL:er.
Relativa länkar och saknade scheman är de fall som vanligtvis bryter en hook. En reducering som fungerar på rena exempel kan fortfarande misslyckas med de rörliga URL:er en redaktör klistrar in kl. 17.00.
Ändrar www svaret?
Det kan det, och det ärliga sättet att ta reda på det är att fråga. Kör den kostnadsfria domänåtgärden på båda formerna av en webbplats du känner till, jämför sedan de två svaren sida vid sida.
Vilken regel du än väljer, skriv den i en kodkommentar så att nästa ingenjör inte behöver gissa. En kommentar kostar ingenting och sparar en lång diskussion senare.
Vad gäller för omdirigeringar och subdomäner?
Skicka värd som dina läsare faktiskt landar på, inte länken en redaktör klistrade in för år sedan. Om den länken omdirigeras, reducera den slutgiltiga adressen och ignorera hoppet emellan.
En blogg på en egen subdomän är en bedömningsfråga. Bestäm i förväg om den kontrolleras ensam eller tillsammans med sin överordnade domän, och skriv ner det valet bredvid regeln.
Checklista före lansering för haken
Haken utlöses endast vid publicering, inte vid varje utkastsparning
URL:en reduceras till en bar domän innan anropet
Kostnadsfria åtgärder körs först och krediter spenderas endast på en flagga
En 401 och en 402 har var sitt varsel och sitt eget meddelande
En timeout är inställd, så en långsamt API stannar aldrig en redaktör
Den lagrade anteckningen bär ett datum, så ingen misstar den för live-data
Samma inlägg publicerat två gånger debiteras inte två gånger (se mytlistan)
Vad som ska loggas, och vad som stannar utanför inlägget
En logglinje för varje hoppad kontroll är den billigaste revisionskedjan du kan bygga. Registrera post-ID:et, domänen du skickade, statuskoden och om ett betalt steg kördes. Ofta räcker det.
Den lagrade anteckningen förblir kort och daterad, enligt stegen ovan. Fullständiga svar hör hemma i dina egna loggar, om de hör hemma någonstans, eftersom de är stora och åldras snabbt.
Vilka fält hör hemma i en logglinje?
Börja med post-ID:et och publiceringsversionen. En upprepad webhook visas då som samma par två gånger, vilket är exakt vad du vill se.
Lägg till domänen, åtgärdens namn, statuskoden och tiden då anropet startade. Lämna nyckeln själv utanför, eftersom en logg som innehåller den blir en andra plats där hemligheter bor.
Hur länge ska en lagrad anteckning leva?
Så länge som inlägget gör, om inte en nyare kontroll ersätter den. Det viktiga är att en läsare kan se hur gammal anteckningen är, eftersom en anteckning från för några månader sedan läses som live-data.
Poängfältsguiden visar de fyra fälten vi föreslår för den anteckningen, inklusive datumet.
Testa haken på staging innan lansering
Kör dessa fyra kontroller innan någon förlitar sig på haken.
1
Spela upp en tidigare publicering
Utlösa haken med en kopia av en post du redan publicerat. Jämför den lagrade anteckningen med vad du förväntade dig, och bekräfta att samma post inte debiterades två gånger.
2
Försök en domän registrerad nyligen
Använd en partnerdomän som är ny för dig. Ett tomt eller tunt svar bör lagras som okänt, inte som ett misslyckande, och anteckningen bör säga det med raka ord.
3
Tvinga en 402 medvetet
Kör haken med en nyckel på ett testkonto vars saldo du har tömt. Bekräfta att hoppet, logglinjen och varningen alla utlöses, och att publiceringen fortfarande når bygget.
4
Läs meddelandet som redaktören ser
Be någon utanför teamet att läsa feltexten högt. Om de inte kan säga vad de ska göra härnäst, skriv om meddelandet innan lanseringsdagen. Efteranalysen visar vad ett vagt meddelande kostade ett uppfunnet team.
Vad haken inte kan se
Vårt index uppdateras ungefär en gång i månaden. En länk som lagts till efter den senaste uppdateringen visas inte, och en länk som tagits bort sedan kan fortfarande visas. För bevis samma dag, använd Länkar-rapporten i Google Search Console.
