Fouten in de linkvolgorde: zeven bugrapporten met oplossingen

Waarom de oplossingen klein zijn

Merk op dat geen van hen een tweede abonnement nodig heeft. QA van gekochte links is vooral administratie, en de administratie die er toe doet, gebeurt op de leveringsdatum.

Wat geld kost is de late ontdekking. Altijd. Een batch van 40 links vooraf betaald, drie maanden later kapot gevonden, laat je ruziën over een garantieperiode die misschien al gesloten is. Voer de checks uit op dag 0, dag 30 en dag 60 en de periode werkt voor jou.

Voor een concreet schema met verzonnen maar aannemelijke getallen, zie het werkvoorbeeld met 40 links. Voor de termen in deze lijst is het glossarium één klik verwijderd.

Waar onze API de loop binnenkomt

Na de shell-loop, roep refdomains één keer aan voor het clientdomein en diff de hostlijst tegen de spreadsheet. Dat zijn 2 credits, $0.0002, en één verzoek dekt tot 1.000 rijen.

Hosts die in de spreadsheet staan en afwezig zijn in de lijst krijgen het label pending tot de volgende maandelijkse refresh. Hosts die in beide aanwezig zijn, worden cross-confirmed. Een korte lijst, netjes gelabeld, is de deliverable die je manager echt leest. Niemand opent de ruwe JSON, en dat hoeft ook niet. Houd de dump in opslag voor het geval een leverancier een rij zes weken later betwist.

Hoe lang een link order QA pass zou moeten duren

Link order QA kost minder tijd dan de meeste mensen veronderstellen. Tijd gaat naar één plek. Het schaalt met het aantal bron-URLs en met hoeveel ervan je handmatig leest, terwijl de grootte van de eigen website van de klant veel minder uitmaakt.

Tel de bron-URLs, niet de clientpagina's

Stel je een kleine zakelijke site van ongeveer 200 pagina's voor die 40 links van buitenaf heeft ontvangen. Het werk is de 40 bronpagina's plus de doel-URLs. De andere 200 pagina's aan de klantkant zijn niet onderdeel van een linkcheck. Stel dat die 40 links van 12 verschillende hosts komen. De fetch-loop draait dan 40 keer, één keer per URL, en de refdomains diff draait één keer per client. Als je dit zo telt, wordt de schatting aritmetiek.

Als iemand meerdere dagen werk citeert voor een linkcheck, vraag dan welke taken de offerte dekt. Een volledige site-audit en een linkcheck zijn verschillende taken, en slechts één van hen vereist een crawler van het hele domein.

Script de fetch, lees dan de uitzonderingen

De shell-loop in deze gids haalt elke bronpagina op en greps op de link. Een persoon leest alleen de rijen die het script niet kon bevestigen, zoals een missende anchor of een onverwachte rel-waarde.

Dat verplaatst de inspanning van het lezen van elke pagina naar het beslissen over een handvol rijen.

Wat een handmatige review nog toevoegt

Een handmatige review vangt wat een script niet kan. Voorbeelden zijn een link ingevoegd door JavaScript, een paywall of een lay-out die de anchor verbergt. Begroot dit voor de rijen die het meest belangrijk zijn, niet voor de hele spreadsheet.

Schrijf de begroting neer voordat het werk begint, zodat de review een eindpunt heeft. Een nuttige gewoonte is om drie of vier rijen handmatig te samplen na elke batch, niet elke rij, en te loggen welke rijen zijn gelezen.

Welke van de zeven bugs verschijnen eerst

Niet elke bug verschijnt op dag 0. Sommige wachten op een redirect, een plugin-update of een staging-regel die verandert. Weet welke laat zijn. Dat bepaalt de tweede en derde checkpoints.

Redirects en staging-regels verschijnen vroeg

Als de doel-URL twee keer redirect, of een staging-regel bots blokkeert, verschijnt het probleem meestal in de eerste week. Daarom behoort bug 5 tot het dag 0-script en niet tot een latere.

Voer curl -I uit op je eigen URL op dezelfde dag dat de link live wordt gemeld.

Rel drift komt na plugin-updates

Een plugin-update kan een rel-attribuut herschrijven lang na levering. Een link die op dag 0 followed was, kan op dag 60 sponsored lezen, zonder dat iemand het artikel heeft aangeraakt.

Dus behoort de rel-check tot elke re-check, niet alleen tot de eerste. Parse het attribuut elke keer uit de opgehaalde HTML en vergelijk het met de bestelling.

Verkeerde URL's en verkeerde ratings worden gevonden in de spreadsheetfase

Bug 2, de startpagina in plaats van het betaalde artikel, en bug 4, het vergelijken van ratings over tools, worden meestal gevangen voordat er een fetch draait. Beide komen uit de spreadsheet zelf, dus ze zijn goedkoop te repareren op dat punt.

Repareer ze voordat de eerste scriptrun. Elke latere stap erft wat de spreadsheet zegt, en een fetch van de verkeerde URL retourneert een schoon ogend antwoord over de verkeerde pagina.

Een spreadsheet die een exacte bron-URL voor elke rij noemt, en één metric voor de rating, verwijdert twee van de meest voorkomende false alarms in het hele proces.

Vervangingen vereisen dezelfde zeven checks

Een vervangingslink is een nieuwe link. Het verdient dezelfde zeven checks als de eerste batch, en het start zijn eigen klok. Behandel de swap als een nieuwe orderregel. Geen patch.

Waar de oude rij niet wordt overgedragen

Het oude bewijs beschrijft een pagina die je link niet langer draagt. Het bewijst niets over de nieuwe. Houd het voor het geschilbestand en start een frisse set bewijs voor de vervanging.

Registreer beide bron-URLs in dezelfde rij, zodat het spoor later netjes leest.

Testen binnen het vervangingsvenster

Als het contract een venster noemt voor het wisselen van een dode link, test de swap binnen dat venster. Een vervanging getest op de laatste dag laat geen ruimte om een tweede probleem op te lossen.

Gebruik het venster als deadline voor het controleren, en boek de check voordat het sluit.

Het nieuwe domein opnieuw beoordelen

Een vervanging komt vaak van een ander domein, en dat domein kan een lagere rating dragen dan die welke het verving. Voer de floor-check opnieuw uit op de nieuwe host voordat je de swap accepteert.

Eén bulk_dr call dekt de hele lijst van vervangingen, dus er is weinig reden om het over te slaan.

Wat de spreadsheet van de manager zou moeten tonen

Een link order QA spreadsheet is de deliverable. Elke rij draagt één status en een paar data, en het bewijs zit achter de rij in opslag. Het bewijs blijft onzichtbaar. De manager leest de samenvatting.

Eén status per rij

Gebruik pass, pending of fail, en niets ertussen. Een rij die live is maar nog niet geïndexeerd, is pending, geen half-pass. Half-passes sturen de maandelijkse review terug in een discussie over formulering.

Als je een vierde staat nodig hebt, noem hem dan eerst in het contract.

Data naast elke status

Elke rij nodig de dag waarop je de pagina hebt opgehaald, de dag van de laatste refresh die je kende, en de dag van de volgende check. Die drie data beantwoorden de meeste vragen die een manager stelt.

Een rij zonder data nodigt uit tot de vraag of de check wel heeft plaatsgevonden.

De ruwe dump bewaren voor een geschil

Bewaar de opgeslagen HTML, de headerdumps en de API-responsen in een map die is genoemd naar de batch. Houd de map zo lang bewaard als een geschil nog open zou kunnen zijn, aangezien een leverancier een rij goed na de sluiting van de samenvatting kan betwisten.

Maak de map read-only zodra de batch sluit, zodat het bewijs overeenkomt met wat je hebt gerapporteerd.