QA-Fehler bei Link-Reihenfolgen: sieben Bug-Reports mit Lösungen

Warum die Lösungen klein sind

Beachten Sie, dass keine davon ein zweites Abonnement benötigt. QA von gekauften Links ist im Wesentlichen Buchhaltung, und die relevante Buchhaltung findet am Auslieferungsdatum statt.

Was Geld kostet, ist die späte Entdeckung. Immer. Ein Batch von 40 Links, der im Voraus bezahlt wurde und drei Monate später als defekt erkannt wird, führt dazu, dass Sie über einen Garantiezeitraum streiten, der möglicherweise bereits abgelaufen ist. Führen Sie die Prüfungen am Tag 0, Tag 30 und Tag 60 durch, und der Zeitraum kommt Ihnen zugute.

Für einen konkreten Zeitplan mit erfundenen, aber plausiblen Zahlen siehe das 40-Link-Arbeitsbeispiel. Für die in dieser Liste verwendeten Begriffe ist das Glossar nur einen Klick entfernt.

Wo unsere API in die Schleife eingreift

Rufen Sie nach der Shell-Schleife refdomains einmal für die Client-Domain auf und vergleichen Sie die Host-Liste mit der Tabelle. Das sind 2 Credits, $0.0002, und eine Anfrage deckt bis zu 1.000 Zeilen ab.

Hosts, die in der Tabelle vorhanden sind, aber nicht in der Liste, erhalten die Kennzeichnung pending bis zum nächsten monatlichen Refresh. Hosts, die in beiden vorhanden sind, werden gegenseitig bestätigt. Eine kurze, sauber beschriftete Liste ist das Deliverable, das Ihr Manager tatsächlich liest. Niemand öffnet das rohe JSON, und niemand sollte müssen. Bewahren Sie den Dump in der Speicherung auf, falls ein Vendor eine Zeile sechs Wochen später anzweifelt.

Wie lange ein QA-Durchlauf für Link-Bestellungen dauern sollte

QA von Link-Bestellungen dauert weniger Zeit, als die meisten annehmen. Die Zeit fließt an eine Stelle. Sie skaliert mit der Anzahl der Quell-URLs und damit, wie viele davon manuell gelesen werden, während die Größe der eigenen Website des Clients eine viel geringere Rolle spielt.

Zählen Sie die Quell-URLs, nicht die Client-Seiten

Stellen Sie sich eine kleine Business-Website mit etwa 200 Seiten vor, die 40 externe Links erhalten hat. Die Arbeit betrifft die 40 Quell-Seiten plus die Ziel-URLs. Die anderen 200 Seiten auf Client-Seite sind nicht Teil einer Link-Prüfung. Angenommen, diese 40 Links stammen von 12 verschiedenen Hosts. Die Fetch-Schleife läuft dann 40 Mal, einmal pro URL, und der refdomains-Diff läuft einmal pro Client. Auf diese Weise wird die Schätzung zu einfacher Arithmetik.

Wenn jemand mehrere Arbeitstage für eine Link-Prüfung veranschlagt, fragen Sie, welche Aufgaben das Angebot abdeckt. Eine vollständige Site-Audit und eine Link-Prüfung sind unterschiedliche Aufgaben, und nur eine von ihnen erfordert einen Crawler für die gesamte Domain.

Skripten Sie den Fetch, lesen Sie dann die Ausnahmen

Die Shell-Schleife in diesem Leitfaden ruft jede Quell-Seite ab und grept nach dem Link. Eine Person liest nur die Zeilen, die das Skript nicht bestätigen konnte, wie z. B. einen fehlenden Anchor oder einen unerwarteten rel-Wert.

Das verlagert den Aufwand vom Lesen jeder Seite hin zur Entscheidung über eine Handvoll Zeilen.

Was eine manuelle Überprüfung noch beiträgt

Eine manuelle Überprüfung erfasst, was ein Skript nicht kann. Beispiele sind ein durch JavaScript injizierter Link, eine Paywall oder ein Layout, das den Anchor verbirgt. Planen Sie das Budget für die Zeilen, die am wichtigsten sind, nicht für das gesamte Blatt.

Schreiben Sie das Budget vor Arbeitsbeginn auf, damit die Überprüfung einen Endpunkt hat. Eine nützliche Gewohnheit ist, nach jedem Batch drei oder vier Zeilen manuell zu stichprobenartig zu prüfen, nicht jede Zeile, und zu protokollieren, welche Zeilen gelesen wurden.

Welcher der sieben Bugs tritt zuerst auf

Nicht jeder Bug zeigt sich am Tag 0. Einige warten auf eine Umleitung, ein Plugin-Update oder eine Änderung der Staging-Regel. Wissen Sie, welche spät auftreten. Das prägt den zweiten und dritten Kontrollpunkt.

Umleitungen und Staging-Regeln zeigen sich früh

Wenn die Ziel-URL zweimal umleitet oder eine Staging-Regel Bots blockiert, tritt das Problem normalerweise in der ersten Woche auf. Deshalb gehört Bug 5 in das Skript für Tag 0 und nicht in ein späteres.

Führen Sie curl -I am selben Tag, an dem der Link als live gemeldet wird, auf Ihrer eigenen URL aus.

Rel-Drift kommt nach Plugin-Updates

Ein Plugin-Update kann ein rel-Attribut lange nach der Auslieferung überschreiben. Ein Link, der am Tag 0 gefolgt wurde, kann am Tag 60 als sponsored gelesen werden, ohne dass jemand den Artikel berührt.

Deshalb gehört die rel-Prüfung zu jeder Nachprüfung, nicht nur zur ersten. Analysieren Sie das Attribut jedes Mal aus dem abgerufenen HTML und vergleichen Sie es mit der Bestellung.

Falsche URLs und falsche Ratings werden auf Tabellenebene gefunden

Bug 2, die Startseite statt des bezahlten Artikels, und Bug 4, das Vergleichen von Ratings über Tools hinweg, werden normalerweise erkannt, bevor ein Fetch läuft. Beide stammen aus der Tabelle selbst, daher sind sie in diesem Stadium kostengünstig zu beheben.

Beheben Sie sie vor dem ersten Skriptlauf. Jeder spätere Schritt übernimmt, was die Tabelle sagt, und ein Fetch der falschen URL liefert eine saubere Antwort über die falsche Seite.

Eine Tabelle, die für jede Zeile eine exakte Quell-URL und eine Metrik für das Rating angibt, beseitigt zwei der häufigsten Fehlalarme im gesamten Prozess.

Ersatzlinks benötigen dieselben sieben Prüfungen

Ein Ersatzlink ist ein neuer Link. Er verdient dieselben sieben Prüfungen wie der erste Batch, und seine eigene Uhr beginnt zu ticken. Behandeln Sie den Austausch als neue Bestellzeile. Kein Patch.

Warum die alte Zeile nicht übernommen wird

Die alte Evidenz beschreibt eine Seite, die Ihren Link nicht mehr enthält. Sie beweist nichts über den neuen. Bewahren Sie ihn für die Streitdatei auf und beginnen Sie mit einem frischen Satz von Beweisen für den Ersatz.

Notieren Sie beide Quell-URLs in derselben Zeile, damit die Spur später klar lesbar ist.

Tests innerhalb des Ersatzzeitraums

Wenn der Vertrag einen Zeitraum für den Austausch eines toten Links vorsieht, testen Sie den Austausch innerhalb dieses Zeitraums. Ein Ersatz, der am letzten Tag getestet wird, lässt keinen Spielraum, um ein zweites Problem zu beheben.

Nutzen Sie den Zeitraum als Frist für die Prüfung und buchen Sie die Prüfung, bevor sie abläuft.

Das Rating der neuen Domain erneut bewerten

Ein Ersatz stammt oft von einer anderen Domain, und diese Domain kann ein niedrigeres Rating haben als die, die sie ersetzt hat. Führen Sie die Floor-Prüfung erneut auf dem neuen Host durch, bevor Sie den Austausch akzeptieren.

Ein einzelner bulk_dr-Aufruf deckt die gesamte Liste der Ersatzlinks ab, daher gibt es wenig Grund, ihn zu überspringen.

Was die Tabelle des Managers zeigen sollte

Eine Link-Bestellungs-QA-Tabelle ist das Deliverable. Jede Zeile enthält einen Status und einige Daten, und die Evidenz liegt hinter der Zeile in der Speicherung. Die Evidenz bleibt unsichtbar. Der Manager liest die Zusammenfassung.

Ein Status pro Zeile

Verwenden Sie pass, pending oder fail, und nichts dazwischen. Eine Zeile, die live ist, aber noch nicht indexiert wurde, ist pending, kein halber Durchgang. Halbe Durchgänge führen die monatliche Überprüfung zurück in eine Argumentation über die Formulierung.

Wenn Sie einen vierten Zustand benötigen, benennen Sie ihn zuerst im Vertrag.

Daten neben jedem Status

Jede Zeile benötigt den Tag, an dem Sie die Seite abgerufen haben, den Tag der letzten Aktualisierung, von der Sie wussten, und den Tag der nächsten Prüfung. Diese drei Daten beantworten die meisten Fragen, die ein Manager stellt.

Eine Zeile ohne Daten lädt zur Frage ein, ob die Prüfung überhaupt stattgefunden hat.

Den Rohdump für einen Streitfall aufbewahren

Speichern Sie den gespeicherten HTML-Code, die Header-Dumps und die API-Antworten in einem Ordner, der nach dem Batch benannt ist. Bewahren Sie den Ordner so lange auf, wie ein Streitfall noch eröffnet werden könnte, da ein Vendor eine Zeile gut nach Abschluss der Zusammenfassung in Frage stellen kann.

Machen Sie den Ordner schreibgeschützt, sobald der Batch schließt, damit die Evidenz mit dem übereinstimmt, was Sie gemeldet haben.