Backlink checker PageRank eller DR: vad som ska lagras i ett fält

Varför PageRank inte är ett fältalternativ

Folk söker fortfarande efter ett verktyg för backlink checker PageRank, men det offentliga numret är borta. Google tog bort PageRank-visningen i verktygsfältet 2016, och ingen ersättning kom någonsin från Google själva.

Det som finns kvar är leverantörernas poäng. Ahrefs har DR, Moz har DA, och vi publicerar vår egen Domain Rating med en öppen formel. Välj en och stanna kvar. Att blanda två i en kolumn gör varje senare jämförelse meningslös.

En praktisk regel för headless-team: lagra det du kommer att visa eller filtrera på, och inget annat. Varje extra fält är en sak till att en redaktör kan missförstå, en kolumn till i en export, och en mappning till som går sönder när du migrerar från ett CMS till ett annat.

Namngivning betyder något. Döp fältet till link_dr, inte authority. Det första säger vems nummer det är. Det andra inbjuder någon att byta till en annan leverantörs poäng om ett år.

Att döpa fältet efter dess källa

Döp fältet efter leverantören som producerade numret, varje gång. Ett fält som heter link_dr berättar för nästa läsare varifrifra figuren kom, och det stoppar ett senare byte till en annan leverantör från att ske tyst.

Endast etiketten överförs, och numret gör det inte. Ahrefs DR, Moz DA och vår egen Domain Rating är olika mätningar, så ett värde som kopieras från ett till ett fält döpt efter ett annat vilseleder nästa läsare.

Kan du lagra två leverantörers poäng?

Du kan, i två fält med två namn. De flesta team behöver det inte, eftersom två nummer inbjuder till en jämförelse, och jämförelsen är det steg som går fel.

Om en intressent ber om båda, visa dem de två formlerna sida vid sida. Skalorna är byggda på olika sätt, och den skillnaden förklarar de flesta överraskningarna.

Är poängen densamma över verktygen?

Nej. En DR från ett verktyg och en DA från ett annat kommer från olika länkgrafer och olika formler, så de kan peka i samma riktning och ändå vara olika i siffrorna.

Vår egen formel är offentlig. Log-skalan är anledningen till att ett hopp från 1 000 till 100 000 hänvisande domäner flyttar poängen mindre än de råa talen antyder.

Vad tabellen säger om fältutformning

Skalan är logaritmisk. Tio domäner och 1 000 domäner är 27 poäng ifrån varandra, medan 1 000 och 100 000 är samma avstånd igen. Så lagra helttalet, men läs det i band.

Ett bandfält hjälper ofta en redaktör mer än det råa numret. Ingen kan agera på 41 mot 43. De kan agera på en etikett som säger medel. Håll det enkelt.

Datum betyder lika mycket som poäng. En lagrad poäng utan datum ser ut som en liveavläsning, och ett år senare kommer någon att citera den i ett möte som om den vore det. Stämpla den, och uppdatera den på ett schema du kan namnge, till exempel den nattliga bulk_dr-sväpningen från kostnadstabellen.

Noteringsfältet bör förbli enkelt, eftersom dess uppgift är liten. En mening räcker. Dess uppgift är att påminna läsaren om att indexet rör sig ungefär månadsvis och att Google Search Console innehåller Googles egen syn.

Att hålla fältet ärligt över tid

Ett fält som skrivs en gång och aldrig ses över blir tyst ett faktum om det förflutna. Uppdateringsjobbet är det som håller det till en avläsning, och det bör köras på ett schema du kan namnge med en mening.

Börja med schemat, eftersom det sätter allt annat. Månadsvis matchar indexet, och nattliga körningar tillför kostnad utan att tillföra information, eftersom indexet rör sig ungefär en gång i månaden.

Hur ofta ska poängen uppdateras?

Månadsvis, i de flesta fall, eftersom det är rytmen indexet följer. Nattliga sväpningar gör fortfarande mening för ett team som vill ha ett färskt datum på varje post, även när numret inte har flyttat sig.

Kostnad är inte anledningen att hålla tillbaka. En nattlig bulk_dr-anrop på upp till 2 000 domäner kostar ett kredit, och kostnadstabellen listar resten.

Vad ska jobbet göra med ett saknat värde?

Lämna den gamla poängen och det gamla datumet på plats, och markera försöket som misslyckat i ditt eget logg. Att skriva ett tomt värde över en bra avläsning ser prydligt ut, men det raderar den enda historik du har.

Ett saknat värde och en nolla är olika fakta. Din fälttyp bör hålla isär dem, så att en redaktör aldrig läser ett glapp som ett dåligt betyg.

Hur håller du varje batch under gränsen?

Dela upp listan i bitar på högst 2 000 domäner, och skicka ett anrop per bit. Håll bitstorleken i en enda konstant, så att en ändring av gränsen påverkar en enda rad.

Logga antalet domäner som skickades och antalet lagrade avläsningar. En mismatch mellan de två är den första ledtråden till att en batch gick fel.

Vad en redaktör bör se bredvid poängen

En redaktör läser fältet på några sekunder, så fältet måste svara på några sekunder. Visa bandet först, datumet andra och helttalet sist, eftersom det är ordningen en stressad läsare behöver dem i.

Etiketten betyder lika mycket som layouten. Ett fält som heter link_dr_band som säger medel berättar läsaren inget om indexet, så noteringen bredvid måste bära den varningen.

Ska bandet färga posten?

En färgad badge kan hjälpa en stressad redaktör, men den kan också få en medelavläsning att se ut som ett misslyckande. Håll färgerna till bandnamnen, och undvik rött för allt utom ett hårt problem.

Bandet är ett råd för en granskning, inte en regel för publicering. Säg det i etiketten bredvid, så att en grön eller amber badge aldrig läses som ett godkännande.

När samma band visas på många poster, kontrollera regeln innan du kontrollerar posterna. Ett band som flaggar halva webbplatsen berättar vanligtvis om tröskeln, inte om innehållet.

Vad ska stå i noteringen när datumet är gammalt?

Ett gammalt datum ska ändra noteringen, inte dölja poängen. En rad som säger att avläsningen är äldre än den senaste uppdateringen berättar för redaktören vad som ska göras, vilket är att kolla igen innan man litar på den.

Generera den raden i din kod, så att varje post säger det på samma sätt. Handskrivna noter drar ifrån sig, och efter några månader kommer ingen ihåg vad de skulle säga.