Svårighetsgradstabell

Kontroll av dåliga baklänkar: diffa snapshots i SQLite

Inget skript kan avgöra att en länk är toxisk för just dig. Det kan visa vilka hänvisande domäner som är nya, vilka som försvunnit och vilka som ser märkliga ut för att läsas igenom manuellt.

Stenvålt med lerplattor och en mässpassare som mäter datapunkter

Svårighetsgradstabell för nya hänvisande domäner

Våra egna tumregler för prioritering, inte en definition från Google
NivåSignalÅtgärd
IgnoreraNy domän, DR över 30, ankare är ditt varumärke eller en ren URLLogga det, gå vidare
Titta50 eller fler nya domäner på en vecka från en TLD du aldrig riktat in dig påÖppna tio av dem
Titta nogaExakt matchande ankare på 20 eller fler nya domänerKontrollera ankarmolnet, hitta källan
AgieraNätverk som ser ut att vara betalt eller hackade sidor som pekar mot digDokumentera det; överväg en disavow-fil endast om du också har en manuell åtgärd
VäntaEn domän försvann denna månadKontrollera igen efter nästa månatliga uppdatering

Varför diffa istället för att skanna en gång

En enda snapshot berättar vad som finns. En diff berättar vad som har ändrats, och det är där problemen visar sig.

Google har sagt i flera år, sedan Penguin 4.0-släppet i september 2016 och igen i uppdateringen för länkskum i december 2022, att de främst ignorerar skumma länkar istället för att straffa dem. SpamBrain utför det arbetet. Så en översvämning av skräp är oftare brus än ett hot, och diffen sparar dig främst från att reagera på brus.

Behåll din egen historik. Sviterna skriver över sina.

Bygg historiktabellen i fyra steg

Diffen fungerar bara om varje körning landar i samma tabell, i samma form. Dessa steg håller det så.

01

Skapa tabellen en gång

Kör en create-if-not-exists-sats med de kolumner du behöver: dagen, domänen och poängen. Behåll den i skriptet, så att en ny maskin kan bygga om samma tabell utan manuella steg.

02

Infoga en rad per domän per dag

Använd en parametriserad infogning och commita en gång per körning. En enda commit håller en krasch från att lämna halva dagen i filen.

03

Skydda mot en andra körning

Ta bort dagens rader innan du infogar, eller lägg till en unik nyckel på dag och domän. En omkörning samma dag ersätter då raderna istället för att fördubbla dem.

04

Jämför med föregående dag i filen

Välj det senaste tidigare datumet med ett max(day)-filter, inte igår. Jämförelsen förblir korrekt när en vecka hoppades över.

diff.py

Två tabeller skulle vara snyggare. En räcker för en hobby-miljö: en rad per domän per snapshotdatum.

python
import json, sqlite3, sys, datetime
db = sqlite3.connect('links.db')
db.execute('create table if not exists snap(day text, dom text, dr int)')
rows = json.load(open(sys.argv[1]))
day = datetime.date.today().isoformat()
db.executemany('insert into snap values (?,?,?)',
               [(day, r.get('domain'), r.get('dr')) for r in rows])
db.commit()
prev = db.execute('select max(day) from snap where day < ?', (day,)).fetchone()[0]
if prev:
    new = db.execute('select dom from snap where day=? except select dom from snap where day=?', (day, prev)).fetchall()
    gone = db.execute('select dom from snap where day=? except select dom from snap where day=?', (prev, day)).fetchall()
    print(len(new), 'new,', len(gone), 'gone')

Felsökning av diffen

SymtomTrolig orsakÅtgärd
Hundratals 'borta' över en nattIndexuppdateringen bytte ut urvaletJämför månatligt, inte dagligen
Varje domän ser ny utTabellen var tom eller day-formatet ändradesKontrollera select distinct day
DR-kolumnen är helt NULLRadens fältnamn skiljer sig från drSkriv ut en rå rad och justera
Dubbletter efter en omkörningSamma dag infogades två gångerTa bort den dagen först, eller lägg till en unik nyckel
Antal under totalPagineringen slutade för tidigtFixa loopen i Actions runbook
Trädgårdsmästare som observerar bryn med en lup för att jämföra tillväxtmönster

Att välja tröskelvärden från din egen historik

En tröskel kopierad från ett blogginlägg är en gissning om någon annans webbplats. En kontroll av dåliga baklänkar är bara så användbar som dess gränser, och din egen historik berättar vad som är normalt för din domän.

Börja med att logga några månader utan att agera på något. Låt det slå sig. Skriv sedan ner den typiska veckovisa svängningen. Först då sätter du gränserna i svårighetsgradstabellen.

Börja med en baslinje

Registrera antalet nya och borta för varje körning utan att reagera på dem. Några månaders tyst loggning ger dig ett intervall som tillhör din domän och ingen annans.

När baslinjen finns tillgänglig sticker en enskild dålig vecka ut mot den, och du kan förklara skillnaden utan att gissa. Det är hela poängen med baslinjen.

Välj en varning per signal

Varje signal i tabellen får en tröskel, en ägare och en åtgärd. En signal med tre varningar är en signal ingen läser, och varningarna hamnar att ignoreras tillsammans.

Skriv varningen bredvid dess signal i koden, så att tabellen på denna sida och skriptet aldrig skiljer sig åt.

Gå tillbaka till gränserna varje kvartal

Din webbplats växer, och så gör dess normala. Kontrollera gränserna var tredje månad, och skriv anledningen bredvid varje ändring, så att historiken förklarar sig själv senare.

Fyrvaktare som skannar horisonten med kikare och ankar på arbetsbänk

Att läsa svårighetsgradstabellen i praktiken

Tabellen är ett prioriteringshjälpmedel, inte en dom. Varje rad berättar var du ska titta, och åtgärdkolumnen håller dig från att dra fram en disavow-fil i panik.

Arbeta från toppen. De flesta veckor slutar vid Ignorera eller Titta. En Titta-rad startar några minuters läsning, och en Titta noga-rad startar en längre granskning av ankarna. Hoppa inte över rader eftersom veckan var stressig. En hopprad rad är veckan då översvämningen går obmärkt.

Prova innan du bestämmer

Öppna tio av de flaggade domänerna och läs sidorna. En översvämning som visar sig vara en enda katalogskrapare är ett annat problem än en översvämning av orelaterade bloggar, och bara sidorna skiljer dem åt.

Registrera vad du bestämde

Behåll en rad per beslut: domänen, nivån, vad du kontrollerade och vad du gjorde. Nästa person som läser loggen, inklusive framtida du, får resonemanget utan ett möte.

En månatlig sammanfattning av dessa rader tar lite tid, och det gör ett bra första utkast av en granskning.

Vad detta inte kan berätta för dig

Det kan inte bevisa att en länk skadar dig. Ingen utom Google kan det, och rapporten om manuella åtgärder i Search Console är den enda platsen där ett straff anges.

Det kan heller inte se länkar som är yngre än den senaste uppdateringen. För färskare bevis fråga de som driver den länkande webbplatsen, eller läs dina serverloggar för referrerne. Vår notering om timing går djupare.

Om du vill ha sidan med ankare kostar anchor_cloud 2 krediter och grupperar text efter frekvens, vilket är det snabbaste sättet att upptäcka en exakt-match-stöta.

Länkar som anländer mellan uppdateringarna

Allt som är yngre än den senaste uppdateringen saknas på båda sidor av diffen. En länk som dyker upp och försvinner inom ett uppdateringsfönster visas aldrig alls, vilket är jämförelsen bör köras månatligt.

Ankare som ser fel ut för dig

En diff ser domänen, inte meningen runt länken. Två identiska ankare på två olika sidor kan betyda mycket olika saker, så behåll ankarkontrollen som ett separat, manuellt steg.

Lagringsval för en hobby-miljö

SQLite är den enklaste databasen som fortfarande svarar på en diff-fråga med en fråga. Den bor i en enda fil, så den passar i repo eller en backup-mapp utan en server.

Daterade JSON-filer fungerar också. Det är långsammare att fråga, men enklare att öppna i en texteditor när något ser fel ut. Oavsett hur, kopiera lagret till en andra plats innan någon rensning, och behåll kopian i en hel kvartal innan du tar bort något.

När en fil räcker

En tabell med en dag-kolumn täcker en enskild webbplats i år. Filen förblir liten, och frågorna på denna sida behöver ingen justering.

När du ska flytta till en server

När flera personer skriver till samma historik blir en fil på en maskin flaskhalsen. Vid det laget är en hanterad databas det ärliga valet, och schemat förblir detsamma.

Tills dess är en fil i repo det enklaste som överlever en bärdatorbyte.

Koppla diffen till en veckovis jobb

Kör diff.py direkt efter snapshot-steget. Skriv ut antalen, och avsluta med en icke-noll kod när new korsar en gräns du valt, säg 200 på en vecka för en liten webbplats. Jobbet blir rött, och GitHub mejlar dig. Enkelt.

Välj gränsen från din egen historik. Efter två månader vet du om 15 nya domäner i veckan är normalt eller en topp, och vilket fast nummer som kopieras från ett blogginlägg är en gissning.

Tysta veckor är normen.

Frågor om dåliga länkar, svarade rakt på

Finns det en tillförlitlig kontroll av dåliga baklänkar?
Inget verktyg kan märka en länk som skadlig med säkerhet, eftersom bara Google vet hur det behandlar varje en. Ett skript kan lyfta fram mönster som är värda att läsa: plötsliga översvämningar, upprepade exakta ankare, märkliga TLD:er. Du tar beslutet efter att ha öppnat sidorna.
Ska jag disavow vad diffen flaggar?
Sällan. Google har sagt att de i huvudsak ignorerar skumma länkar, och en disavow-fil är avsedd för fall som en manuell åtgärd eller en betald länk-rus som du skapat själv. Dokumentera först, och kontrollera Search Console innan du skickar in något.
Hur ofta ska jag köra det?
Snapshot veckovis, granskning månatlig. Indexet uppdateras ungefär en gång i månaden, så en daglig diff jämför oftast en tabell med sig själv. En månatlig granskning matchar datan och håller nere bruset.
Vilka kolumner ska tabellen behålla?
Behåll dagen, domänen, DR och en källa-kolumn. Lägg till ankaret endast om du också hämtar ankare. Fler kolumner känns noggranna, men varje extra fält är ett till som kan sväva mellan körningar.
Kan jag diffa två sviter mot varandra?
Du kan jämföra deras antal för samma webbplats, men de två resultaten kommer inte att matcha. Kör diffen inuti en källa, och jämför förändringsriktningen över källor, samma regel som gäller överallt på denna webbplats.
Vad händer om en domän lämnar och sedan återkommer nästa månad?
Den visas som borta och sedan som ny, vilket är brus. Räkna återkommande separat, eller jämför tre månader i taget, så att en domän som försvinner för en uppdatering inte utlöser en granskning.