Gekochte links worden niet weergegeven: zes mythes, zes reproduceer-stappen

De drie mythes die de meeste discussies veroorzaken

Gekochte links die niet worden weergegeven is meestal een timingkwestie voordat het een fraudeskwestie is. Drie van de mythes in de tabel verdienen een nadere beschouwing, omdat elke een ticket in de verkeerde richting stuurt.

Een 200-response maakt de link niet geldig

Een status van 200 vertelt je dat de server antwoordde. Het zegt niets over de markup in het antwoord. Een pagina kan een 200 retourneren en toch noindex bevatten, of een canonical-tag die naar een ander adres verwijst.

Lees de HTML die de server daadwerkelijk heeft verzonden, en lees vervolgens de headerdump voor een X-Robots-Tag. Beide kunnen een probleem verbergen dat de statuscode nooit laat zien.

Een verwijderde link is niet altijd een bedrog

Wanneer een link verdwijnt, is de eerste gok meestal de leverancier. De veelvoorkomender oorzaken zijn saai: een sitemigratie, een editor die oude artikelen verwijdert, of een CMS-update die markup verwijdert die het niet herkent.

Controleer het webarchief voor de verwijderingsdatum voordat je de leverancier mailt. Als de captures laten zien dat de pagina is gewijzigd na jouw plaatsing, wordt de vraag wanneer het is veranderd, niet wie het heeft gedaan.

Twee tools die het niet eens zijn, gedragen zich normaal

Twee linktools die het niet eens zijn over één domein, werken beide goed. Elke tool heeft zijn eigen crawler, zijn eigen schema en zijn eigen regels voor wat als een link wordt geteld. Een verschil van een paar hosts is gebruikelijk.

Noem één tool als referentie in het ticket, en houd de anderen als context. Meng hun aantallen niet in één kolom.

Search Console werkt op zijn eigen klok

Het linkrapport in Search Console is een aparte pipeline met een eigen vertraging, en het kan de gegevens die het toont steekproefsgewijs selecteren. Een link die daar ontbreekt, kan nog steeds zichtbaar zijn bij een verse fetch, en een link die daar zichtbaar is, kan er een tijdje over doen om te verschijnen.

Vergelijk de rapportdatum met de plaatsingsdatum en vermeld beide in het ticket. Houd de leverancier niet aan een venster dat het rapport nooit heeft beloofd.

De verwachte tijdlijn van de eerste week

Dag 0, de leverancier rapporteert dat de link live is. Haal hem op. Jouw taak is om hem diezelfde dag op te halen en de HTML op te slaan. Een opgeslagen kopie is meer waard dan een screenshot.

Geef het tijd. Binnen de eerste maand heeft onze crawler de pagina misschien wel of niet bezocht. Als de refresh al heeft plaatsgevonden vóór de plaatsing, zie je niets tot de volgende keer, dus een belletje op dag 10 kan legitiem geen resultaat opleveren. Log het als 'in behandeling' in plaats van 'mislukt'.

Voer het uit na de volgende refresh. Roep backlinks aan voor je domein en zoek naar de bronhost. Als deze nu ontbreekt, heb je een echt verschil. Ga er dieper op in: haal de pagina opnieuw op, controleer op een gewijzigde anchor, een nieuwe rel-waarde of een redirect. De glossary beschrijft elk van die tests.

Timingvoorbeelden, gemarkeerd als hypothetisch

De onderstaande voorbeelden zijn hypothetisch. Ze tonen hoe hetzelfde lege resultaat anders leest afhankelijk van wanneer de link is geplaatst.

Een link geplaatst net na een refresh

Stel je een link voor die de dag na een maandelijkse refresh is geplaatst. Zijn eerste echte kans om te verschijnen is de refresh daarna, bijna een volledige cyclus later. Een leeg resultaat in de tussentijd is het schema zoals ontworpen.

Markeer de rij als 'in behandeling' en noteer beide data. Niemand zou een leverancier moeten jagen op een rij die de index nog niet had kunnen zien.

Een link geplaatst net voor een refresh

Stel je nu het tegenovergestelde voor. Een link gaat live een paar dagen voor de volgende refresh. Het kan verschijnen bij die refresh, of het kan vertraging oplopen tot de volgende. In beide gevallen is een miss na één refresh een zwak signaal.

Een link die na twee refreshes nog steeds afwezig is

Stel dat dezelfde link nog steeds afwezig is na twee refreshes, terwijl de pagina een 200 retourneert en de anchor in de opgeslagen HTML staat. Nu heeft de rij een echt verschil. Controleer robots.txt, login-walls en noindex voordat je de index de schuld geeft.

Pas dan verdient de controle met een tweede bron uit de stopregel zijn kosten.

Houd één rij per refresh bij in het logboek, met de datum waarop je de pagina hebt opgehaald en het resultaat van elke controle. Over twee refreshes is dat logboek het verschil tussen een vermoeden en een record. Schrijf het ticket als een lijst van gedateerde observaties, niet als een conclusie over de leverancier.

Wanneer stoppen met wachten

Twee refreshes. Dat is onze vuistregel, geen Google-regel, en je kunt het uitrekken voor langzaam bewegende niches waar publishers zelden een pagina wijzigen. Als de pagina live is, indexeerbaar en gevolgd zoals afgesproken, maar twee maandelijkse refreshes hem nog steeds missen, kan de bronpagina onbereikbaar zijn voor crawlers, achter een login zitten of geblokkeerd zijn in robots.txt.

Test op dat punt met een tweede gegevensbron. Ahrefs of Semrush zal dat doen. Die van ons alleen is niet genoeg. Onenigheid over drie indexes is zeldzaam voor een normale publieke pagina. Eendrachtigheid over afwezigheid is sterk bewijs en behoort tot het cost-aware re-check plan.

Als de link live is en alleen vindbaar door fetchen, accepteer dat en ga verder. Indexvragen over de pagina zelf gaan naar de runbook for traffic drops als de rankings ook zijn verplaatst.