Een runbook om backlinks van websites te vinden zonder dat het model improvisatie toepast

Begin bij het falen dat je wilt voorkomen

Wanneer een toolresultaat ontbreekt, vult een assistent de leegte vaak in met iets plausibels. Vraag hem om backlinks van websites te vinden met niets bruikbaars voor zich, en het antwoord kan er net zo netjes uitzien als een echt antwoord. Dezelfde toon in beide gevallen. Elke regel in de onderstaande prompt sluit zo'n leegte.

Behandel de prompt als een runbook, niet als een spreuk. Elke genummerde regel komt overeen met iets dat in de praktijk fout gaat. Uitgeslagen calls komen eerst. Stille retries daarna, dan nummers die uit eerdere gesprekken bekend zijn, en tot slot een ontbrekende notitie over de maandelijkse refresh.

Waarom de prompt je gegevens niet kan bevatten

Een prompt stelt regels vast voor een chat. Het is geen gegevensbron. De drie punten hieronder behandelen waar mensen fout gaan, en elk punt eindigt met de oplossing.

Een prompt bevat regels, geen cijfers

Sommige mensen plakken een JSON-bestand in de prompt en verwachten dat elke nieuwe vraag het gebruikt. Een prompt stelt de regels vast voor een chat, en het is geen database. Als de cijfers belangrijk zijn, haal ze op. De assistent moet elke keer een call maken.

Citeer de call, niet het geheugen. De regels hierboven zeggen dit al, en een antwoord dat een call citeert, is eenvoudig te controleren. De custom GPT setup laat zien waar die regels thuishoren.

Scraping faalt waar de API niet faalt

Enkele mensen vragen of dezelfde cijfers ook uit een resultatenpagina kunnen worden gehaald. Een pagina scrapen werkt totdat de lay-out verandert. Lay-outs veranderen. Dan levert het script niets op, of de verkeerde kolom.

Een API-call retourneert elke keer dezelfde velden, vandaar dat de prompt ze kan benoemen. Stel dat je maandag een scraper test en die donderdag kapot is. Dat is een onderhoudstaak. Het is geen backlink-leeswerk, en de chat merkt het verschil niet. Als een collega toch wil scrapen, vraag hem dan de verwachte lay-out en de datum van controle te benoemen. Zonder dat is er niemand verantwoordelijk voor het falen.

Stille fouten en vendor-updates

Modellen veranderen, en ook de producten die ze omhullen. Een regel die in één versie werkte, kan in de volgende versie afwijken. Niets kondigt dit aan. De oplossing is saai: houd de onderstaande testset bij en voer deze uit na elke wijziging.

Houd dezelfde drie domeinen en dezelfde drie vragen aan. Als de receipts ophouden, zit de drift in de prompt of het model. Dateer het eerste foutieve antwoord. De changelog toont dan wat die week is veranderd.

Drie gewoontes die de prompt stil verstoren

In een lang gesprek leunt het model meer op recente tekst dan op je eerste bericht. De regels bovenaan vervagen. Begin een nieuwe chat voor elke klant.

Stel dat je een screenshot van de cijfers van een andere vendor in hetzelfde gesprek plakt. Het model kan de twee bronnen mengen, en je kunt ze daarna niet meer uit elkaar halen. Houd één bron per chat.

Enig compliment kan schadelijk zijn. Het model vertellen dat een cijfer overeenkomt met wat je verwachtte, leert het volgende antwoord om dezelfde kant op te leunen. Als een cijfer vreemd lijkt, zeg dat dan neutraal. Vraag om de actienaam. Als een antwoord fout gaat, vertelt de error table je of de fout in de prompt, de key of de data zit.

Data die in je notities thuishoren

Zet een versie en een datum bovenaan de prompt, bijvoorbeeld 2026-10-29, op dezelfde manier waarop je code tagt. Dan kun je, wanneer een antwoord in maart vreemd is, vertellen welke formulering het heeft opgeleverd.

Linkadvies verandert ook met Google. De core update van maart 2024 en de spam update van augustus 2025 hebben allebei veranderd waar mensen over links vroegen, en prompts die daarvoor zijn geschreven, gingen uit van aannames die niet meer golden. Beoordeel de regels twee keer per jaar.

Houd een korte changelog naast de prompt. Drie regels per wijziging is meer dan genoeg. Het verandert een mysterie in een diff.

Houd de testset klein en saai

De wekelijkse test werkt alleen als de testset hetzelfde blijft. Kies hem één keer, schrijf hem op en weersta de drang om domeinen te wisselen wanneer een resultaat vreemd lijkt.

Kies domeinen die je met het blote oog kunt beoordelen

Jouw eigen site is de eerste keuze, omdat je de links ervan beter kent dan wie ook. Een concurrent die je nauwlettend volgt komt op de tweede plaats. Een zeer grote site is een nuttige derde. De schaal ervan is eenvoudig in te schatten.

Vermijd een nieuw domein als test. De cijfers zijn ruisgevoelig. Een drift in het antwoord vertelt je weinig. Kies sites met een zichtbare geschiedenis. Neem één site op waarvan je de links handmatig hebt gelezen, omdat dit je ground truth is.

Stel dezelfde drie vragen in dezelfde woorden

Houd de formulering vast. Rating, top referring domains en anchors, elke week op dezelfde manier gesteld. Het veranderen van de formulering verandert het antwoord, en dan kun je niet zeggen of de data is veranderd of de vraag.

Bewaar de drie antwoorden als platte tekst naast de prompt. Over een maand zal een zij-aan-zij vergelijking meer vertellen dan elk geheugen over hoe de chat voelde.

Bepaal de prijs van de test voordat je hem uitvoert

Elke betaalde call in de test kost credits, dus de test heeft ook een prijs. De rating is gratis, wat twee betaalde vragen per domein overlaat.

Drie domeinen en twee betaalde vragen leiden tot zes calls van 2 credits elk, dus de wekelijkse test kost twaalf credits, ongeveer $0.0012. Schrijf dat cijfer op het testsheet en controleer het eenmaal per maand tegen het saldo.

Wat te doen als de test faalt

Een gefaalde test is informatie. Herschrijf als laatste. Controleer eerst de receipts, dan de statuscodes, dan de domeinspelling. Pas daarna die je de regels aanraakt.

Verander één regel tegelijk. Twee bewerkingen in één keer maken het volgende falen onverklaarbaar.

Bewaar het gefaalde antwoord ook. Plak het in de changelog met de datum en de regel die je hebt veranderd. Die registratie is de enige manier om een echte fix te onderscheiden van een gelukkig antwoord bij de volgende run.

Vragen die teams stellen over deze prompt

Kan ik de regels inkorten om tokens te besparen?

Dat kan, maar snijd woorden weg in plaats van regels. Elke genummerde regel sluit een fout die je je kunt voorstellen. Voeg twee regels samen die hetzelfde zeggen. Laat de receipts-regel met rust.

Vervangt de prompt het lezen van de data?

Nee. Het zorgt ervoor dat de assistent rapporteert wat hij heeft gelezen. Een rating en een lijst van referring domains vereisen nog steeds je ogen, vooral wanneer een cijfer je verbaast.

Welke actie moet de assistent eerst proberen?

Begin met overview, wat gratis is, en ga naar refdomains wanneer je de lijst nodig hebt. Rating en links beantwoorden verschillende vragen, dus één call dekt beide niet.

Hoeveel kost de wekelijkse test?

Met de bovenstaande testset, twee betaalde vragen voor elk van drie domeinen, gebruikt de test ongeveer twaalf credits. Dat is een klein aantal, en het is de moeite waard om het op te schrijven zodat de maandelijkse saldobalans een basis heeft.

Wat als het team een regel wil die de prompt niet heeft?

Voeg het toe aan de changelog met een datum en een reden, en test het vervolgens op de drie domeinen. Een nieuw limiet dat één keer is geschreven, is makkelijker te auditen dan een instructie die midden in een sessie wordt getypt.