Durchsuchen eines URL-Backlink-Checkers ohne Lücken oder Endlosschleifen
Zeilen pro Aufruf, Seiten pro Abfrage und ein hartes Limit bei 50.000. Hier ist eine Schleife, die alle drei Werte beachtet und Ihnen mitteilt, wann Sie aufhören sollen.
Pro Aufrf werden bis zu 1.000 Zeilen zurückgegeben. Jeder Aufrf wird einmal abgerechnet, unabhängig von der Anzahl der Zeilen. Die tiefe Paginierung ist auf 50.000 Zeilen begrenzt, was 50 Aufrufen bei jeweils 1.000 Zeilen entspricht.
Warum Sortierung vor Paginierung kommt
Das Paginieren über einer unsortierten Liste ist die Ursache für Duplikate. Senden Sie immer sort und order zusammen mit page und per, damit Seite 3 bei jeder Anfrage in der Laufzeit dasselbe bedeutet.
Ein refdomains-Pull kostet 2 Credits pro Aufruf, also ergeben 50 Aufrufe 100 Credits, bzw. einen Cent. Selbst im schlimmsten Fall ist es günstig; die eigentliche Kostenursache ist eine Schleife, die nicht terminiert.
Die Sortierspalte wählen
Welche Spalte sortiert werden soll, hängt von der Fragestellung ab. Die größte Zahl zuerst ist die übliche Wahl für Audits, da das Limit dann den langen Schwanz abschneidet und nicht den Teil, der Sie interessiert.
Sortieren Sie nach einem Feld, das für Ihre Fragestellung nichts bedeutet, und das Limit kann die Zeilen entfernen, die Sie wollten. Ziehen Sie zuerst zehn Zeilen nach jeder möglichen Sortierung und prüfen Sie, welcher Ausschnitt das Limit übersteht.
Schreiben Sie die Entscheidung in den Bericht, damit die nächste Person weiß, warum das Limit dort abgeschnitten hat.
Zeilen, die sich während einer Laufzeit verschieben
Die Daten bewegen sich während einer Laufzeit nicht, es sei denn, der monatliche Neuaufbau landet mitten darin. Selten, aber real. Ein nächtlicher Job, der den Monatsanfang überschneidet, kann eine Seite aus dem alten Index und die nächste aus dem neuen Index zurückgeben. Notieren Sie daher die Startzeit in Ihrem Protokoll und vergleichen Sie.
Schreiben Sie die Startzeit an den Anfang des Protokolls und die Seitennummer auf jede Zeile. Dann weist ein Missmatch in der Ausgabe auf Timing-Probleme hin, nicht auf einen Parsing-Bug.
Wenn der Job geplant ist, vermeiden Sie eine Startzeit kurz vor einem wahrscheinlichen Neuaufbau. Ihre Protokolle zeigen einen Neuaufbau als Verschiebung der Gesamtzahlen zwischen zwei Läufen, die ansonsten übereinstimmen. Halten Sie die Gesamtzahlen in jeder Protokollzeile fest.
Ein Lauf, der einen Neuaufbau überschneidet, ist nicht standardmäßig falsch. Er ist nur inkonsistent. Markieren Sie solche Läufe im Protokoll und führen Sie den betroffenen Ausschnitt erneut durch, wenn dies für einen Bericht relevant ist.
Eine Paginierungsschleife, die endet
TypeScript für einen Node 20 Worker. Sie endet bei der ersten kurzen Seite, beim Limit oder bei jedem ok, das nicht wahr ist.
const BASE = "https://seomasters.dev/api.php";
const CAP = 50_000;
const PER = 1000;
export async function pullAll(domain: string, key: string) {
const rows: unknown[] = [];
for (let page = 1; rows.length < CAP; page++) {
const u = new URL(BASE);
u.search = new URLSearchParams({
action: "refdomains", q: domain,
page: String(page), per: String(PER),
sort: "dr", order: "desc",
}).toString();
const res = await fetch(u, { headers: { Authorization: `Bearer ${key}` } });
if (res.status === 401 || res.status === 402) throw new Error(`stop: HTTP ${res.status}`);
const body = await res.json();
if (!body.ok) throw new Error(JSON.stringify(body).slice(0, 300));
const chunk = findRows(body); // see note below
rows.push(...chunk);
if (chunk.length < PER) break; // short page means we are done
}
return rows;
}Fehlerbehebung bei einer Paginierungslaufzeit
| Was Sie sehen | Wahrscheinliche Ursache | Was zu tun ist |
|---|---|---|
| Seite 51 kommt leer oder mit Fehlern zurück | Sie haben das Limit von 50.000 erreicht | Verfeinern Sie mit einer anderen Aktion oder einer anderen sort, und fügen Sie dann nach ID zusammen |
| Dasselbe Domain auf zwei Seiten | Unsortierte Abfrage oder Index-Neuaufbau während des Laufs | Senden Sie sort und order; entfernen Sie Duplikate nach dem Domain-Schlüssel |
| Weniger Zeilen als die Dashboard-Gesamtzahl | Die Gesamtzahl bezieht sich auf den gesamten Graphen, der Pull ist begrenzt | Zeigen Sie "Top 50.000" im UI an |
| Schleife endet nie | Bedingungsprüfung prüft nur rows.length | Abbrechen bei einer kurzen Seite, wie oben beschrieben |
| Rechnung höher als erwartet | Wiederholen bei jedem Nicht-200 | Wiederholen Sie nur Netzwerkfehler, siehe Fehler |
Zeilen lesen, ohne Feldnamen zu erraten
Die findRows-Hilfsfunktion oben ist bewusst offen gelassen. Machen Sie einen echten Aufrf, schauen Sie sich das JSON an und schreiben Sie den Zugriff gegen das, was Sie sehen, statt gegen das, was ein Tutorial versprochen hat.
Für den günstigeren Cousin dieses Jobs, das gleichzeitige Scoring vieler Domains ohne jegliche Paginierung, lesen Sie das Bulk-DR-Skript.
Eine Antwort frieren
Frieren Sie sie dann mit einem Test ein. Speichern Sie eine Antwort als Fixture-Datei und prüfen Sie die Zeilenanzahl und die Schlüssel der ersten Zeile, damit eine zukünftige Änderung im CI fehlschlägt und nicht in einem Kunden-Dashboard.
Halten Sie die Fixture in der Versionskontrolle neben dem Test, damit ein Reviewer die Struktur sieht, die der Code erwartet, ohne etwas ausführen zu müssen.
Wenn die API später ein Feld hinzufügt, sagt Ihnen der Fixture-Diff, ob Ihr Zugriff es bemerkt hat oder es stillschweigend ignoriert hat.
Nennen Sie die Fixture nach der Abfrage, von der sie stammt, z. B. der Aktion, der Domain und der Sortierung. Eine Datei namens response1.json sagt dem nächsten Leser nichts darüber, was sie beweist.
Zählen Sie die gespeicherten Zeilen
Vergleichen Sie die gespeicherten Zeilen mit der Gesamtzahl, die die Schleife gemeldet hat. Eine Lücke bedeutet, dass eine Seite verloren gegangen ist, und eine Wiederholung bedeutet, dass eine Seite zweimal abgerufen und in eine Zeile eingefügt wurde.
Führen Sie diese Prüfung nach jedem Test-Pull durch, nicht nur nach dem ersten. Abweichungen in der Zählung sind meist das erste Symptom für eine geänderte Sortierung oder einen Neuaufbau mitten im Lauf.
Halten Sie die Zählung in derselben Protokollzeile wie die Seitennummer, damit die beiden auf einen Blick zusammen gelesen werden können.
Arbeit oberhalb des Limits aufteilen
Einige Fragestellungen wachsen über das Limit hinaus. Teilen Sie das Problem für Listen oberhalb des Limits, statt härter zu paginieren. Ziehen Sie die Top 50.000 nach einer Sortierung, und fragen Sie andere Aktionen nach den Heavy Hittern, da diese ebenfalls 2 Credits kosten und andere Fragen beantworten. Härteres Paginieren kommt nie an das Limit vorbei.
Die Top 50.000 nach einer Sortierung ziehen
Nehmen Sie das Limit als Tatsache der API. Ziehen Sie die Top 50.000 Zeilen nach einer Sortierung, speichern Sie sie und kennzeichnen Sie das Ergebnis in jedem Bericht als den oberen Ausschnitt.
Ein Dashboard, das eine begrenzte Zählung als vollständige Gesamtzahl darstellt, irreführt die Leser. Das Label kostet nichts, und ein URL-Backlink-Checker-Bericht liest sich ehrlicher damit.
Entscheiden Sie die Ausschnittgröße vor dem Lauf und schreiben Sie sie in den Berichtskopf, damit die Zahl nie größer aussieht, als sie ist. Eine Kopfzeile kostet nichts, und ein Leser, der später eine fehlende Zeile findet, wird Ihnen dafür danken.
Die Heavy Hitter mit einer anderen Frage befragen
anchors und toppages beantworten andere Fragen, z. B. welche Anchor Text dominiert oder welche Seiten die Links anziehen. Für eine Domain jenseits des Limits können diese Antworten wichtiger sein als die nächste Seite derselben Liste.
Halten Sie ihre Ergebnisse in eigenen Tabellen, keyed by Domain, damit ein späterer Pull derselben Domain sie ersetzen kann, ohne die Top-Slice-Zeilen zu berühren.
Jede zusätzliche Aktion kostet ihre eigenen Credits, also kalkulieren Sie sie vor dem Lauf, nicht nach Erhalt der Rechnung.
Eine kurze Liste der schwersten Domains, einmal monatlich gezogen, liefert oft nützlichere Kontextinformationen als eine längere Liste, die jede Nacht gezogen wird.
Nach dem Domain-Schlüssel zusammenführen
Wenn zwei Pulls sich überschneiden, führen Sie sie nach dem Domain-Schlüssel zusammen und behalten Sie den neueren Zeitstempel. Das Zusammenhängen hängt dann nicht davon ab, welcher Pull zuerst fertig war.
Protokollieren Sie, welcher Pull jede Zeile gewonnen hat. Wenn sich eine Zahl zwischen zwei Berichten verschiebt, sagt Ihnen dieses Protokoll, ob sich der Index oder das Zusammenführen geändert hat.
Halten Sie das Zusammenführen in einer einzigen Funktion mit einem Test, da dies der einzige Ort ist, an dem zwei Pulls aufeinandertreffen.
Fortsetzen nach einem Absturz
Abstürze passieren. Ein Deploy startet den Worker neu, ein Laptop schläft, eine VPN-Verbindung bricht ab und die Schleife stirbt auf Seite 31 von 50.
Speichern Sie die Seite nach jedem Aufruf
Persistieren Sie die letzte abgeschlossene Seitennummer nach jedem Aufrf. Starten Sie von dieser Nummer plus eins, nicht von oben, und Sie zahlen 2 Credits pro Seite, statt den gesamten Pull neu zu kaufen.
Speichern Sie es, nachdem die Antwort analysiert wurde, nicht vorher. Eine Seite, die Sie nicht lesen konnten, sollte erneut abgerufen werden, und eine gespeicherte Seitennummer muss immer Zeilen bedeuten, die Sie haben.
Ein Speichervorgang, der einmal pro Minute statt einmal pro Aufrf stattfindet, hinterlässt ein Fenster, in dem ein Absturz die Credit-Ausgabe wiederholen kann. Halten Sie den Schreibvorgang klein, damit er jedes Mal günstig ist.
Protokollieren Sie auch, wie lange jedes Speichern dauert, sowie wie lange jeder Aufrf dauert. Ein Speichervorgang, der mit dem Aufrf konkurriert, weist auf die Speicherschicht hin, und das ist es wert, zu beheben, bevor die Schleife wächst.
Upsert nach dem Domain-Schlüssel
Halten Sie einen idempotenten Schreibvorgang. Upsert jede Zeile nach ihrem Domain-Schlüssel, damit eine doppelt abgerufene Seite eine Zeile hinterlässt, nicht zwei.
Verwenden Sie denselben Schlüssel auf jedem Schreibpfad, einschließlich des manuellen Reparatur-Skripts. Zwei Schreibpfade mit zwei Schlüsseln sind die Ursache dafür, dass Duplikate einem Fortsetzen überleben.
Ein Reparatur-Skript wird oft in Eile nach einem fehlgeschlagenen Lauf geschrieben. Genau dann schleicht sich ein zweiter Schlüssel ein, also prüfen Sie es sorgfältig wie die Hauptschleife.
Ein Fortsetzen ablehnen, wenn sich die Sortierung geändert hat
Protokollieren Sie Sortierung und Reihenfolge zusammen mit der Seitennummer. Wenn jemand sort zwischen einem Absturz und dem Neustart ändert, bedeutet die gespeicherte Seitennummer nicht mehr denselben Ausschnitt. Lehnen Sie das Fortsetzen ab und starten Sie sauber.
Speichern Sie einen kleinen Fortsetzungsdatensatz mit der Sortierung, der Reihenfolge, der Seite und der Zeit. Die Schleife liest diesen Datensatz zuerst und weigert sich fortzufahren, wenn eines der Felder nicht mehr mit der Anfrage übereinstimmt, die sie als Nächstes stellen wird.
Ein abgelehntes Fortsetzen ist kein Fehler. Es ist die Schleife, die sagt, dass die gespeicherte Seite nicht mehr dieselben Zeilen bedeutet, und ein sauberer Neustart ist der günstigere Fehler.
Die Schleife in der Produktion ausführen
- 1
Mit einer kleinen Domain beginnen
Führen Sie die Schleife gegen eine Domain mit einigen hundert Zeilen aus, damit die Stop-Funktion für kurze Seiten ausgelöst wird und Sie den Exit-Pfad beobachten können.
- 2
Eine Seite manuell prüfen
Öffnen Sie eine gespeicherte Antwort und bestätigen Sie, dass der Zugriff die Zeilen noch liest. Verlassen Sie sich nicht auf ein Parsing, das Sie nicht selbst geprüft haben.
- 3
Die Limits in der Konfiguration halten
Legen Sie das Limit und die Seitengröße in einer Konfigurationsdatei ab, damit eine Änderung im Review sichtbar wird und nicht in einer Funktion versteckt bleibt.
- 4
Den Grund für das Ende der Schleife protokollieren
Notieren Sie, ob der Lauf auf einer kurzen Seite, am Limit oder aufgrund eines Fehlers endete. Diese drei Enden bedeuten unterschiedliche Dinge für den Leser des Protokolls.
