Naar de inhoud springen
Contentin
ContentinAanmelden

Veldmappen

Backlink Checker PageRank of DR: wat op te slaan in een veld

Je contentmodel heeft één nummer, één datum en één notitie nodig. Deze pagina toont het veldontwerp en een uitgewerkt voorbeeld met de DR-formule.

Miniature koperen schaal die twee verschillende metaalgewichten vergelijkt die rangschikkingsmetrieken vertegenwoordigen

Waarom PageRank geen veldoptie is

Mensen zoeken nog steeds naar een backlink Checker PageRank-tool, maar het publieke nummer is verdwenen. Google verwijderde de PageRank-weergave in de toolbar in 2016, en er kwam nooit een vervanging van Google zelf.

Wat overblijft zijn scores van leveranciers. Ahrefs heeft DR, Moz heeft DA, en wij publiceren onze eigen Domain Rating met een open formule. Kies er één en blijf daarbij. Twee in één kolom mengen maakt elke latere vergelijking zinloos.

Een praktische regel voor headless teams: sla op wat je weergeeft of filtert, en niets anders. Elk extra veld is één ding meer dat een editor kan verkeerd lezen, één kolom meer in een export, en één mapping meer die kapotgaat als je migreert van de ene CMS naar de andere.

Naamgeving doet ertoe. Noem het veld link_dr, niet authority. De eerste zegt van wie het nummer is. De tweede nodigt iemand uit om over een jaar een score van een andere leverancier te gebruiken.

Het veld vernoemen naar de bron

Noem het veld altijd naar de leverancier die het nummer heeft gegenereerd. Een veld met de naam link_dr vertelt de volgende lezer waar het cijfer vandaan komt, en voorkomt dat een latere switch naar een andere leverancier stilgaat.

Alleen het label gaat mee, het nummer niet. Ahrefs DR, Moz DA en onze eigen Domain Rating zijn verschillende metingen, dus een waarde die van de ene naar een veld met de naam van de andere wordt gekopieerd, zal de volgende lezer misleiden.

Kun je scores van twee leveranciers opslaan?

Dat kan, in twee velden met twee namen. De meeste teams hebben dit niet nodig, omdat twee nummers een vergelijking uitnodigen, en de vergelijking is de stap die fout gaat.

Als een stakeholder om beide vraagt, laat dan de twee formules naast elkaar zien. De schalen zijn anders gebouwd, en dat verschil verklaart de meeste verbazing.

Is de score hetzelfde in alle tools?

Nee. Een DR van de ene tool en een DA van een andere komen uit verschillende link-grafen en hebben verschillende formules, dus ze kunnen dezelfde richting op wijzen en het cijfer toch oneens zijn.

Onze eigen formule is publiek. De logaritmische schaal is de reden dat een sprong van 1.000 naar 100.000 verwijzende domeinen de score minder laat stijgen dan de ruwe aantallen suggereren.

Uitgewerkt voorbeeld: de formule op vijf verzonnen domeinen

Aantallen verwijzende domeinen zijn verzonnen ter illustratie. Formule: round(100 · log(ref_domains+1) / log(2·10^7)).
Verzonnen domeinVerwijzende domeinenDRVoorgestelde band
tiny-docs.example1014Laag
small-saas.example5023Laag
mid-blog.example1,00041Middel
big-publisher.example100,00068Hoog
theoretical-top.example20,000,000100Hoog
Getrapte stenen trap met gekleurde blokken die logaritmische groeibanden illustreren

Wat de tabel zegt over veldontwerp

De schaal is logaritmisch. Tien domeinen en 1.000 domeinen liggen 27 punten uit elkaar, terwijl 1.000 en 100.000 weer dezelfde afstand van elkaar liggen. Sla dus het integer op, maar lees het in bands.

Een band-veld helpt een editor vaak meer dan het ruwe nummer. Niemand kan iets met 41 versus 43. Ze kunnen wel iets met een label dat middel aangeeft. Houd het eenvoudig.

Datums zijn net zo belangrijk als scores. Een opgeslagen score zonder datum lijkt een live meting, en een jaar later zal iemand het in een vergadering citeren alsof het zo is. Stemp het, en verfris het op een schema dat je kunt benoemen, zoals de nightly bulk_dr sweep van de kostentabel.

Het notitieveld moet eenvoudig blijven, omdat het doel klein is. Eén zin is genoeg. Het doel is om de lezer eraan te herinneren dat de index ongeveer maandelijks verplaatst en dat Google Search Console Google's eigen visie vasthoudt.

Het veld eer houden in de tijd

Een veld dat één keer wordt geschreven en nooit opnieuw wordt bekeken, wordt stil een feit uit het verleden. De refresh-job is wat het een meting houdt, en het moet draaien op een schema dat je in één zin kunt benoemen.

Begin met het schema, omdat het alles bepaalt. Maandelijks past bij de index, en nightly runs voegen kosten toe zonder informatie, omdat de index ongeveer één keer per maand verplaatst.

Hoe vaak moet de score verfrist worden?

Maandelijks, in de meeste gevallen, omdat dat het ritme is van de index. Nightly sweeps hebben nog steeds zin voor een team dat een verse datum op elke entry wil, zelfs als het nummer niet is veranderd.

Kosten zijn geen reden om achter te blijven. Een nightly bulk_dr call van maximaal 2.000 domeinen kost één credit, en de kostentabel somt de rest op.

Wat moet de job doen met een ontbrekende waarde?

Laat de oude score en de oude datum op hun plaats, en markeer de poging als mislukt in je eigen log. Een lege waarde schrijven over een goede meting ziet er netjes uit, maar wist de enige geschiedenis die je hebt.

Een ontbrekende waarde en een nul zijn verschillende feiten. Je veldtype moet ze uit elkaar houden, zodat een editor een gat nooit leest als een slechte score.

Hoe houd je elke batch onder de limiet?

Splits de lijst in chunks van maximaal 2.000 domeinen, en stuur één call per chunk. Houd de chunkgrootte in één constante, zodat een wijziging in de limiet één regel raakt.

Log het aantal verzonden domeinen en het aantal opgeslagen metingen. Een mismatch tussen de twee is het eerste teken dat een batch fout ging.

Wat een editor naast de score zou moeten zien

Een editor leest het veld in een paar seconden, dus het veld moet in een paar seconden antwoord geven. Toon de band eerst, de datum tweede en het integer laatste, omdat dat de volgorde is waarin een drukke lezer ze nodig heeft.

Het label is net zo belangrijk als de lay-out. Een veld met de naam link_dr_band dat middel aangeeft vertelt de lezer niets over de index, dus de notitie ernaast moet die kanttekening dragen.

Moet de band de entry kleuren?

Een gekleurd badge kan een drukke editor helpen, maar het kan ook een middel lezen laten lijken op een falen. Houd de kleuren bij de bandnamen, en vermijd rood voor alles behalve een hard probleem.

De band is advies voor een review, geen regel voor de publish. Zeg dat in het label erna, zodat een groen of amber badge nooit wordt gelezen als een pass.

Wanneer dezelfde band op veel entries verschijnt, controleer de regel voordat je de entries controleert. Een band die de helft van de site markeert vertelt je meestal iets over de drempel, niet over de content.

Wat komt er in de notitie wanneer de datum oud is?

Een oude datum moet de notitie veranderen, niet de score verbergen. Een regel die zegt dat de meting ouder is dan de laatste refresh vertelt de editor wat te doen, namelijk opnieuw controleren voordat je erop vertrouwt.

Genereer die regel in je code, zodat elke entry het op dezelfde manier zegt. Handgeschreven notities wijken af, en na een paar maanden weet niemand meer wat ze moesten zeggen.

Een schets van een contentmodel

Veldnamen zijn van ons ter illustratie. Contentful, Sanity, Strapi en Payload declareren velden op hun eigen manier, dus vertaal.

json
{
  "link_dr": 41,
  "link_dr_band": "middle",
  "link_checked_on": "2026-10-29",
  "link_check_note": "Index refreshes monthly. Verify in Search Console."
}
Houten sorteerbak met vier compartimenten waar edelstenen in worden gegoten

De response mappen naar die vier velden

  1. 1

    Roep een gratis actie één keer aan

    Voer overview uit op een bekend domein en lees de JSON met het oog. Controleer de echte veldnamen in de response, omdat deze pagina ze niet voor je opsomt.

  2. 2

    Kies de DR-waarde

    Kopieer de score van 0 tot 100 naar een integer-veld. Verwerp alles buiten dat bereik zodat een slecht gevormde response de entry niet kan bereiken.

  3. 3

    Leid de band af in je eigen code

    Onder de 20 is laag, 20 tot 50 is middel, boven de 50 is hoog. De drempels zijn een suggestie en behoren tot je team, niet tot de API.

  4. 4

    Stempel de datum

    Schrijf de datum van vandaag naast de score. De index ververst ongeveer maandelijks, dus de datum is onderdeel van de data.

Vier velden en de vraag die elk beantwoordt

Elk veld beantwoordt één vraag die een editor zal stellen.

link_dr

Het integer-score van 0 tot 100. Het beantwoordt hoe sterk het domein er op de schaal uitziet.

link_dr_band

Een eenvoudig label zoals laag, middel of hoog. Het beantwoordt of een persoon dichterbij moet kijken, zonder dat iemand een nummer hoeft te lezen.

link_checked_on

De datum van de meting. Het beantwoordt hoe oud het nummer is, wat belangrijker is dan de meeste teams verwachten.

link_check_note

Eén zin over de index. Het beantwoordt wat de score niet kan tonen, zoals de maandelijkse refresh en de vertraging voor nieuwe links.

Velden om over te slaan

  • Ruwe backlink-rijen: ze verouderen snel en vullen de entry op
  • Ankerlijsten, tenzij een mens ze controleert (zie de runbook)
  • Een pass of fail boolean: het nodigt uit tot een harde blokkade
  • Vendor scores van twee tools in één kolom
Eén kanttekening bij het voorbeeld

De vijf domeinen hierboven bestaan niet, en de aantallen zijn gekozen om de rekenkunde zichtbaar te maken. Voor echte cijfers, voer de gratis DR checker uit op je eigen site.