Check my backlink returnerade inget: en feltabell

Regeln som täcker de flesta fall

Försök igen vid nätverksfel. Försök aldrig igen vid 401 eller 402. Den första typen löser sig på några sekunder; den andra kräver en människa, och att slå på den bara fyller dina loggar.

Varje JSON-svar innehåller ett ok-fält, och autentiserade svar lägger till _credits med anropskostnad och återstående balans. Kontrollera ok i bodyn även när HTTP-statusen ser bra ut.

Retry-tiderna nedan är vår ingenjörsrådgivning, inga dokumenterade gränser. API-dokumentationen vi har publicerar ingen rate limit, så bygg din egen takgräns och håll den blygsam.

Varför 401 och 402 aldrig försöks igen

En 401 är ett nyckelfel, och en 402 är ett balansfel. Inget av dessa löses mellan två försök en sekund apart, så ett försök igen skapar bara brus i dina loggar och inget annat.

Att vässa löser inte heller en 402. Balansen stannar där den är tills någon fyller på den från kontosidan, så det enda användbara svaret är ett tydligt meddelande och en varning till den som äger budgeten.

En 401 förtjänar en titt på header eller key-parametern, och en kontroll att nyckeln inte har bytts ut. Att försöka igen med samma felaktiga nyckel några gånger bevisar ingenting.

En dålig nyckel och en tom balans ser också olika ut i ditt dashboard. Placera dem på separata varningar, så att personen som fyller på inte vaknas av en nyckeltypsned, och personen som roterar nycklar inte blir uppringd för en balansfråga.

Nätverksfel och backoff

En timeout eller en connection reset kan lösas av sig själva, så det är de enda fallen som är värda ett nytt försök. Vänta 1, 2, 4 och sedan 8 sekunder, lägg till lite jitter, och sluta efter det fjärde försöket.

Dessa tidtagningar är vår rådgivning, inte en dokumenterad gräns. Håll din egen takgräns, logga varje retry, och varna när retries ökar, eftersom en ökande retry-takt vanligtvis är det första tecknet på ett upstream-problem.

Håll timeout på din sida explicit, i en namngiven konstant. En implicit standard som ändras vid en library-uppdatering är en vanlig anledning till att ett nightly-jobb börjar misslyckas på bara en maskin.

Övervaga upstream-svartiden samt felhastigheten. En långsam respons som aldrig misslyckas kan fortfarande binda upp dina workers, och en retry-loop gör den fördröjningen värre.

Normalisera domänen innan anropet

De flesta misslyckade anrop börjar i inmatningsrutan, inte i nätverket. Användare klistrar in vad de har kopierat, och din kod måste omvandla det till en bar domän innan API:et ser det.

Ta bort scheme och path

Ta bort scheme, alla paths och query string. En klistrad artikeladress blir till sin värd, och bara värden skickas upstream.

Gör värd till gemener också. Håll rensningen i en funktion, så att samma regel körs i formuläret, i batch-jobbet och i testerna.

Testa rensningen med fem eller sex verkliga klistrade indatap, inklusive en med en avslutande slash och en med en query string. Dessa fall avslöjar buggar som ett rent exempel aldrig visar.

Bestäm en gång vad du ska göra med www.

Välj en regel för www. och applicera den i en enda funktion, så att samma webbplats aldrig slås upp under två stavningar.

Skriv ner regeln bredvid funktionen. Nästa utvecklare som stöter på en vilseledande www kommer då att hitta beslutet, inte en andra åsikt.

Vilken regel du än väljer, håll den i en fil och skriv ett test för den. Testet är dokumentationen av beslutet, och det är kort.

Avvisa vad som inte kan vara en domän

Neka indatap med mellanslag eller tomma etiketter, och visa ett kort meddelande i formuläret. En avvisad sträng kostar ingenting, medan en dålig kostar ett misslyckat anrop och en förvirrad användare.

Avslutande punkter är det udda fallet. Ta bort en i slutet av värden och behandla allt annat som ogiltigt.

Visa avvisningen bredvid fältet, inte som en toast som försvinner. En användare som kan se vad som var fel kan fixa det i ett försök.

Tomma resultat och indexålder

När någon skriver in "check my backlink" i ditt formulär och får inget, är ett tomt svar inte alltid ett fel. Det betyder ofta att domänen är ny, för liten eller helt enkelt inte indexerad än, och skärmen bör säga vilket.

En helt ny webbplats

En webbplats som lanserades förra veckan kan ha inga hänvisande domäner i indexet. Visa "inte indexerad än" tillsammans med indexeringsdatumet, och erbjuda det gratis overview-anropet som en korskontroll.

Cacha inte det tomma svaret för länge. Några timmar är tillräckligt, och nästa ombyggnad kan ta in webbplatsen.

Berätta för besökaren när indexet senast byggdes om, med vanliga ord. Ett datum bredvid ett tomt svar förklarar gapet bättre än ett längre meddelande gör.

En enradig notering i ditt eget UI räcker här. Ingen förväntar sig ett live-index, och en enkel mening bredvid indexeringsdatumet läses som ärlig.

En siffra som skiljer sig från ett annat verktyg

Olika crawlers ser olika delar av webben. Läs DR-siffran som en position inom ett verktyg, och peka läsare till DR reference för formeln.

En kort notering under siffran sparar mer supporttid än någon mängd ursäkter i efterhand.

Om två avläsningar skiljer sig, jämför först antalet hänvisande domäner. DR-formeln är enkel, så de flesta oenigheter handlar om antalet.

Rader som slutar vid 50 000

När en lista slutar vid taket är svaret korrekt för vad API:et tillåter. Märk avskärningen och länka till paging notes istället för att försöka en djupare sida.

Djupare sidor bortom den punkten är inte en retry. De är en annan fråga, och att behandla dem som en är hur en loop körs i timmar.

Håll avskärningen synlig i exporten också, så att en kalkylblad som öppnas om en månad fortfarande visar att listan var begränsad.

Att visa radantalet bredvid tabellen gör en avskärning till en synlig fakta. En läsare som ser 50 000 rader vet att be om en smalare fråga.