Check my backlink hat nichts zurückgegeben: Eine Fehlerübersicht

Die Regel, die die meisten Fälle abdeckt

Wiederholen Sie Netzwerkfehler. Wiederholen Sie niemals 401 oder 402. Die erste Art behebt sich selbst innerhalb von Sekunden; die zweite erfordert einen Menschen, und das ständige Wiederholen füllt nur Ihre Logs.

Jede JSON-Antwort enthält ein Feld ok, und authentifizierte Antworten fügen _credits mit den Kosten des Aufrufs und dem verbleibenden Guthaben hinzu. Prüfen Sie ok im Antwortkörper, auch wenn der HTTP-Status korrekt aussieht.

Die unten genannten Wiederholungszeiten sind unsere ingenieurtechnische Empfehlung, keine dokumentierten Limits. Die von uns vorliegende API-Dokumentation veröffentlicht kein Rate Limit, also erstellen Sie Ihre eigene Obergrenze und halten Sie sie bescheiden.

Warum 401 und 402 nie wiederholt werden

Ein 401 ist ein Schlüsselproblem, und ein 402 ist ein Guthabenproblem. Keines von beiden klärt sich zwischen zwei Versuchen im Abstand einer Sekunde, sodass eine Wiederholung nur Rauschen in Ihren Logs erzeugt.

Warten behebt auch kein 402. Das Guthaben bleibt unverändert, bis jemand es über die Kontoseite auflädt. Die einzige sinnvolle Reaktion ist eine klare Meldung und eine Benachrichtigung für die verantwortliche Person.

Ein 401 verdient eine Prüfung des Headers oder des Schlüsselparameters sowie die Überprüfung, ob der Schlüssel nicht ersetzt wurde. Dieselben falschen Schlüssel mehrmals zu wiederholen, beweist nichts.

Ein falscher Schlüssel und ein leeres Guthaben sehen in Ihrem Dashboard auch unterschiedlich aus. Legen Sie separate Warnungen an, damit die Person, die das Guthaben auflädt, nicht durch einen Tippfehler geweckt wird und die Person, die Schlüssel rotiert, nicht wegen des Guthabens alarmiert wird.

Netzwerkfehler und Backoff

Ein Timeout oder eine Verbindungsunterbrechung kann von selbst behoben werden, daher sind dies die einzigen Fälle, die einen weiteren Versuch wert sind. Warten Sie 1, 2, 4 und dann 8 Sekunden, fügen Sie etwas Jitter hinzu und stoppen Sie nach dem vierten Versuch.

Diese Zeiten sind unsere Empfehlung, kein dokumentiertes Limit. Halten Sie Ihre eigene Obergrenze ein, protokollieren Sie jede Wiederholung und alarmieren Sie bei steigenden Wiederholungsraten, da eine steigende Wiederholungsrate meist das erste Anzeichen für ein Problem in der Upstream-Infrastruktur ist.

Halten Sie das Timeout auf Ihrer Seite explizit in einer benannten Konstanten. Ein implizites Standardwert, der sich bei einer Library-Aktualisierung ändert, ist eine häufige Ursache dafür, dass ein nächtlicher Job nur auf einer einzigen Maschine zu fehlerhaften Ergebnissen führt.

Beobachten Sie auch die Antwortzeit des Upstreams sowie die Fehlerquote. Eine langsame Antwort, die nie fehlschlägt, kann Ihre Worker trotzdem blockieren, und eine Wiederholungsschleife verschlimmert diese Verlangsamung noch.

Normalisieren Sie die Domain vor dem Aufruf

Die meisten fehlgeschlagenen Aufrufe beginnen im Eingabefeld, nicht im Netzwerk. Benutzer fügen ein, was sie kopiert haben, und Ihr Code muss dies in eine reine Domain umwandeln, bevor die API sie sieht.

Schema und Pfad entfernen

Entfernen Sie das Schema, jeden Pfad und die Abfragezeichenfolge. Eine eingefügte Artikeladresse wird zu ihrem Host, und nur der Host geht nach oben.

Konvertieren Sie den Host auch in Kleinbuchstaben. Halten Sie die Bereinigung in einer Funktion, damit dieselbe Regel im Formular, im Batch-Job und in den Tests ausgeführt wird.

Testen Sie die Bereinigung mit fünf oder sechs echten eingefügten Eingaben, darunter eine mit einem abschließenden Schrägstrich und eine mit einer Abfragezeichenfolge. Diese Fälle decken die Fehler auf, die ein sauberes Beispiel nie zeigt.

Entscheiden Sie einmal, was mit www. zu tun ist.

Wählen Sie eine Regel für www. und wenden Sie sie in einer einzigen Funktion an, damit dieselbe Seite nie unter zwei Schreibweisen abgefragt wird.

Schreiben Sie die Regel neben die Funktion. Der nächste Entwickler, der auf einen fehlgeleiteten www-Stoß stößt, findet dann die Entscheidung, nicht eine zweite Meinung.

Welche Regel Sie auch wählen, halten Sie sie in einer Datei und schreiben Sie einen Test dafür. Der Test ist die Aufzeichnung der Entscheidung und er ist kurz.

Verwerfen Sie, was keine Domain sein kann

Verweigern Sie Eingaben mit Leerzeichen oder leeren Labels und zeigen Sie eine kurze Nachricht im Formular an. Eine abgelehnte Zeichenfolge kostet nichts, während eine schlechte einen fehlgeschlagenen Aufruf und einen verwirrten Benutzer kostet.

Abschließende Punkte sind der Sonderfall. Entfernen Sie einen am Ende des Hosts und behandeln Sie alles andere als ungültig.

Zeigen Sie die Ablehnung neben dem Feld an, nicht als Toast, der verschwindet. Ein Benutzer, der sehen kann, was falsch war, behebt es im ersten Versuch.

Leere Ergebnisse und das Indexalter

Wenn jemand „check my backlink“ in Ihr Formular eingibt und nichts erhält, ist eine leere Antwort nicht immer ein Fehler. Sie bedeutet oft, dass die Domain neu, zu klein oder einfach noch nicht im Index ist, und der Bildschirm sollte anzeigen, welcher Fall vorliegt.

Eine brandneue Seite

Eine letzte Woche gestartete Seite kann keine Verweisdomänen im Index haben. Zeigen Sie „noch nicht indexiert“ zusammen mit dem Indexdatum an und bieten Sie den kostenlosen overview-Aufruf als Kreuzprüfung an.

Kacheln Sie diese leere Antwort nicht lange. Ein paar Stunden reichen aus, und der nächste Neuaufbau kann die Seite einbringen.

Teilen Sie dem Besucher mit, wann der Index zuletzt neu aufgebaut wurde, in klaren Worten. Ein Datum neben einer leeren Antwort erklärt die Lücke besser als eine längere Nachricht.

Eine einzeilige Notiz in Ihrer eigenen Benutzeroberfläche reicht hier aus. Niemand erwartet einen Live-Index, und ein einfacher Satz neben dem Indexdatum wirkt ehrlich.

Eine Zahl, die mit einem anderen Tool nicht übereinstimmt

Verschiedene Crawler sehen verschiedene Teile des Webs. Lesen Sie die DR-Zahl als Position innerhalb eines Tools und verweisen Sie Leser auf die DR-Referenz für die Formel.

Eine kurze Notiz unter der Zahl spart mehr Support-Zeit als jede Menge Entschuldigungen im Nachhinein.

Wenn zwei Messwerte abweichen, vergleichen Sie zuerst die Anzahl der Verweisdomänen. Die DR-Formel ist einfach, daher beruhen die meisten Uneinigkeiten auf der Anzahl.

Zeilen, die bei 50.000 enden

Wenn eine Liste an der Obergrenze endet, ist die Antwort korrekt für das, was die API erlaubt. Kennzeichnen Sie den Cut-off und verlinken Sie die Paginierungshinweise, anstatt eine tiefere Seite zu versuchen.

Tiefere Seiten jenseits dieses Punktes sind keine Wiederholung. Sie sind eine andere Abfrage, und die Behandlung als eine ist der Grund, warum eine Schleife stundenlang läuft.

Halten Sie den Cut-off auch im Export sichtbar, damit eine Spreadsheet, die einen Monat später geöffnet wird, immer noch zeigt, dass die Liste begrenzt war.

Die Anzeige der Zeilenanzahl neben der Tabelle macht einen Cut-off zu einer sichtbaren Tatsache. Ein Leser, der 50.000 Zeilen sieht, weiß, dass er eine engere Frage stellen sollte.