Hvordan blokkere Digital Ocean-boter i WordPress

Hvis GA4-rapportene viser plutselige topper fra ukjente regioner, identiske øktlengder eller landingssider som ingen deler, ser du ofte på boter som likevel utløser analyse-taggen. Målet er ikke å blokkere alle crawlere. Målet er å kutte søppelet som forstyrrer beslutninger, og la Googlebot, Bingbot og ekte besøkende være i fred.

Denne gjennomgangen gjelder WordPress på en DigitalOcean-droplet (eller en lignende VPS) med nginx, eventuelt fail2ban, og GA4. Den behandler robots.txt, serverbrannmurer, WordPress-plugins og CDN-verktøy mot boter som ulike lag med ulike oppgaver. Trenger du arbeid med crawling og siteringer utover trafikkhygiene, kan du lese mer om SEO- og GEO-optimeringstjenestene hos WPPoland.

#Hvorfor dårlige boter blåser opp Google Analytics

GA4 teller et treff når en nettleser (eller en hodeløs nettleser som oppfører seg som en) kjører taggen din og sender hendelser. Det betyr at tre ulike grupper dukker opp på ulike steder:

• Skrapere som kjører JavaScript og klikksvindelverktøy kan vises i GA4 som økter, sidevisninger og til og med konverteringer hvis de treffer de riktige URL-ene.
• Enkle HTTP-skrapere kjører ofte ikke JavaScript i det hele tatt, så de går helt utenom GA4 og laster likevel PHP, MySQL og alle maler uten cache på serveren.
• Navngitte søkecrawlere skal vises i serverlogger og i Search Console, ikke som en stor andel av “Brukere” i GA4.

Når gruppen som kjører JavaScript vokser, begynner anskaffelses- og engasjementsrapportene å skli. Fluktfrekvens og gjennomsnittlig engasjementstid ser rare ut. Betalte og organiske rapporter blir støyete. Team begynner å optimalisere for trafikk som aldri kjøper noe.

Vanlige former for dårlig trafikk (uten å finne på konkrete IP-er):

• Høyt forespørselsvolum fra et lite sett sky-ASN-er, uten referrer og med rare User-Agents
• Gjentatte treff på /wp-login.php, xmlrpc.php, spørringer som lister opp forfattere eller gamle plugin-stier
• Økter som bare lander på tynne URL-er og spretter ut på under ett sekund, men likevel lager page_view-hendelser i GA4
• “Organisk” trafikk som i samme periode aldri stemmer med søkedataene i Search Console

Skyleverandører som DigitalOcean og AWS har mange legitime nettsteder. De har også skrapere. Den overlappingen er grunnen til at generelle regler som “sperr hele /16” er risikable. Velg kilder du har bekreftet i dine egne logger framfor lister kopiert fra gamle blogginnlegg.

#Slik oppdager du bot-trafikk i GA4 og serverlogger

Endring uten utgangspunkt er historiefortelling. Samle et utgangspunkt på minst sju dager hvis du kan, eller en hel arbeidsuke hvis trafikken er sesongpreget.

#Slik ser du bot-trafikk i GA4-rapporter

Lag en enkel sammenligningsvisning før du endrer nginx eller fail2ban:

1. Noter Brukere, Økter, Engasjerte økter og Visninger for de siste 7 og 28 dagene.
2. Åpne Trafikkanskaffelse og se etter kilder med absurd engasjement (engasjementstid nær null, nær 100 % fluktfrekvens på alle landingssider).
3. Sjekk Teknologi > Nettleser og Enhet for tomme, ukjente eller tydelig skriptstyrte klienter.
4. Se under Landingsside etter stier bare boter liker (/?author=1, gammelt spam i parametere, produkt-ID-er som ikke finnes).
5. Eksporter eller ta skjermbilde av perioden, slik at du senere kan sammenligne likt med likt (samme lengde, samme fordeling av ukedager).

GA4 fjerner allerede kjente boter selv (mer om det i neste avsnitt), men den listen fanger ikke alle plagsomme klienter som kjører JavaScript. Behandle GA4 som ett signal, ikke det eneste.

#Slik finner du bot-IP-er i nginx-tilgangslogger

På DigitalOcean har du som regel nginx-tilgangslogger og, hvis det er slått på, fail2ban-jails. Nyttige sjekker:

# Vanligste adresser i siste tilgangslogg (juster stien)
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

# Stier som ser ut som sonderinger
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -40

# User-Agents som dominerer
awk -F\" '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

Koble toppene i GA4 til tidsstemplene i disse loggene. Hvis GA4 hopper klokken 03:00 UTC og tilgangsloggen viser de samme IP-ene som hamrer på xmlrpc.php, har du et serverproblem som analysefiltre alene ikke løser.

Noter også CPU-belastningen og lengden på PHP-FPM-køen under toppen. Bot-støy som aldri når GA4, kan likevel tømme en liten droplet.

#Filtrerer GA4 bot-trafikk automatisk

Delvis. Googles hjelpeartikkel om trafikk fra kjente boter sier at GA4 automatisk utelater trafikk fra kjente boter og edderkopper. Listen bak kombinerer Googles egen forskning med International Spiders and Bots List, som vedlikeholdes av Interactive Advertising Bureau (IAB).

To detaljer på den siden er viktige her. Du kan ikke slå av utelatelsen, og du kan ikke se hvor mye trafikk den har fjernet. Når GA4 fortsatt viser søppeløkter, sto altså ikke disse klientene på listen: vanligvis hodeløse nettlesere på leide servere som kjører taggen din som en vanlig besøkende. Den automatiske utelatelsen gjør heller ingenting med forespørsler som ikke kjører JavaScript, fordi GA4 aldri mottar dem.

Det er dette gapet resten av guiden handler om. GA4 tar seg av crawlere som sier hvem de er; serveren og edgen din må ta seg av klienter som skjuler hva de er.

#Slik utelater du bot-IP-områder med datafiltre i GA4

Datafiltre i GA4 finnes i tre typer: utviklertrafikk (feilsøkingsmodus), intern trafikk (etter IP-adresse eller område) og uønskede vertsnavn. Det finnes ingen bot-type, så det eneste IP-baserte verktøyet er filteret for intern trafikk.

Det virker i to trinn, beskrevet i Googles veiledning for å definere intern trafikk. Først åpner du Data streams under Data collection and modification i Admin, velger nettstrømmen, går til Configure tag settings, deretter Define internal traffic, og oppretter en regel. Hendelser som treffer, får parameteren traffic_type. Standardverdien er internal, men du kan sette din egen, for eksempel bot_do, slik at en bot-regel aldri blandes med kontorregelen din. IP-betingelser godtar eksakt treff, begynner med, slutter med, inneholder, et CIDR-område eller et regulært uttrykk. I andre trinn oppretter du under Data filters et filter av typen Internal Traffic som utelater denne traffic_type-verdien.

Begrensninger du bør kjenne før du stoler på det:

• En eiendom kan ha høyst 10 datafiltre.
• Hvert filter er Testing, Active eller Inactive. I testmodus merkes treffende hendelser med dimensjonen Test data filter name, som du kan se på i Explore før noe fjernes.
• Et aktivt filter endrer innkommende data permanent og gjelder ikke historiske data. Ifølge Google kan det ta 24 til 36 timer før et filter virker.
• For en midlertidig visning uten datatap viser Google til rapportfiltre.

En tryggere rekkefølge: hold en bot-IP-regel i testmodus en hel uke, sammenlign de merkede øktene med det nginx-loggen viser for de samme adressene, og slå på aktiv modus først når den merkede trafikken tydelig er søppel. Hold regellisten kort og noter når hvert område ble lagt til. Og husk hva dette filteret er: en rapportkorrigering. Forespørslene treffer fortsatt nginx, PHP og MySQL; GA4 slutter bare å telle dem.

#Slik sjekker du hvem som eier en IP før du blokkerer den

Én adresse i en logg sier lite før du vet hvem som annonserer den. whois gir deg registeroppføringen. Data-API-et til RIPEstat gir rutingbildet, altså prefikset og det autonome systemet (AS) som annonserer det akkurat nå:

whois 5.101.96.1 | grep -iE "orgname|org-name|netname"
curl -s "https://stat.ripe.net/data/network-info/data.json?resource=5.101.96.1"
curl -s "https://stat.ripe.net/data/as-overview/data.json?resource=AS14061"

Da vi kjørte de to API-kallene 14. oktober 2026, returnerte RIPEstat prefikset 5.101.96.0/21 annonsert av AS14061, og oppga DIGITALOCEAN-ASN, DigitalOcean, LLC som innehaver av AS14061. Endepunktet network-info er gratis og svarer for adresser fra alle regionale registre, ikke bare RIPE.

Les CIDR-suffikset før du limer inn et område noe sted. Tallet etter skråstreken er antallet faste prefiksbiter, så en /24 rommer 256 adresser, en /16 rommer 65 536 og en /14 rommer 262 144. Én gammel linje som deny from 104.236.0.0/16 stenger ute 65 536 adresser, nesten alle uten forbindelse til klienten som plaget deg.

#Hvor finner du de gjeldende IP-områdene til DigitalOcean

DigitalOcean publiserer adresseområdet sitt som en CSV-fil, lenket som DigitalOcean IP Ranges i plattformdokumentasjonen, og oppgir at filen oppdateres automatisk. Hver rad inneholder prefiks, landkode, region, by og postnummer.

14. oktober 2026 inneholdt filen 1 234 prefikser, 148 av dem IPv6. Fordelt på land var 654 rader i USA, 224 i Nederland, 111 i Tyskland, 90 i Singapore og 67 i Storbritannia. Den spredningen er det praktiske argumentet mot generell blokkering: de samme prefiksene huser droplets for byråer, SaaS-verktøy, oppetidsovervåking, CI-runnere og helt vanlige bedrifter, ved siden av skraperne.

Bruk filen til oppslag, ikke som sperreliste. Når én adresse dominerer tilgangsloggen, sjekk om den ligger i DigitalOceans adresseområde:

curl -s -o do-ranges.csv https://www.digitalocean.com/geo/google.csv
python3 -c 'import csv,ipaddress,sys; nets=[ipaddress.ip_network(r[0]) for r in csv.reader(open("do-ranges.csv")) if r]; ip=ipaddress.ip_address(sys.argv[1]); print(any(ip in n for n in nets))' 5.101.96.1

En True forteller deg at klienten kjører på en DigitalOcean-server. Den forteller ikke at klienten er ondsinnet; det avgjør oppførselen i loggen.

#Kan robots.txt blokkere dårlige boter

robots.txt er en frivillig protokoll. Samarbeidsvillige crawlere leser den og hopper over stier som er sperret. Misbrukende klienter ignorerer den.

Bruk robots.txt til å veilede gode boter:

• Sperr staging-stier, URL-er for søkeresultater og admin-endepunkter du ikke vil ha indeksert
• Vær forsiktig med crawl-delay og brede Disallow-regler; for mye sperring kan skjule sider du fortsatt vil ha i søk
• Legg sensitive områder bak autentisering, ikke bare bak en Disallow-linje

Ikke forvent at en Disallow-regel stopper credential stuffing mot /wp-login.php. Den forespørselen ser i praksis aldri i robots.txt. Brannmur, ratebegrensning og autentisering hører hjemme på serveren eller på edgen.

En praktisk fordeling:

#Slik verifiserer du Googlebot før du blokkerer en IP

Å blokkere Googlebot etter User-Agent-strengen er et klassisk selvmål. Forfalskede Googlebot-strenger er vanlige; ekte Googlebot verifiseres med omvendt DNS og bekreftelse i motsatt retning. Google beskriver fremgangsmåten i Bekreft Googlebot.

Før du avviser en IP som utgir seg for å være Googlebot:

1. Kjør omvendt DNS-oppslag på IP-en.
2. Bekreft at vertsnavnet slutter på et Google-domene som Google dokumenterer.
3. Slå opp vertsnavnet vanlig vei og bekreft at det gir den opprinnelige IP-en.
4. Først da behandler du klienten som Googlebot (eller ikke).

Legg aldri inn en regel som “avvis hvis User-Agent inneholder Googlebot” som sikkerhetstiltak. Den blokkerer den ekte crawleren når noen forfalsker strengen et annet sted, og den stopper ikke forfalskere som bruker en annen streng.

Samme forsiktighet gjelder Bingbot og andre navngitte crawlere du bryr deg om. Bruk tillatelseslister for verifiserte crawler-områder bare når du vedlikeholder dem nøye; til alt annet er oppførselsbasert ratebegrensning bedre.

#Slik ratebegrenser du boter på DigitalOcean med nginx og fail2ban

På en typisk LEMP-droplet er nginx det billigste stedet å kaste ut misbruk, før PHP-FPM og WordPress-autoload starter.

#nginx limit_req for wp-login.php og xmlrpc.php

Modulen ngx_http_limit_req_module begrenser forespørselsraten per nøkkel (vanligvis IP). Et forsiktig mønster for innlogging og XML-RPC ser slik ut:

# http-kontekst
limit_req_zone $binary_remote_addr zone=wp_login:10m rate=1r/s;
limit_req_zone $binary_remote_addr zone=wp_xmlrpc:10m rate=1r/s;

# eksempler for server / location
location = /wp-login.php {
    limit_req zone=wp_login burst=5 nodelay;
    include fastcgi_params;
    # ... eksisterende PHP-handler ...
}

location = /xmlrpc.php {
    limit_req zone=wp_xmlrpc burst=2 nodelay;
    # Mange nettsteder returnerer 403 her hvis de ikke trenger XML-RPC
}

Juster ratene ut fra utgangspunktet ditt. En redaksjon med mange redaktører bak felles NAT trenger høyere burst enn et visittkortnettsted. Logg avvisninger fra limit_req og se etter falske treff fra kontorets utgående IP-er.

Andre nginx-vaner som hjelper på DO-droplets:

• Slå av eller stram kraftig inn xmlrpc.php hvis du ikke bruker det
• Ratebegrens POST til admin-ajax.php fra anonyme klienter når plugins tillater det
• Avslutt TLS i nginx (eller hos Cloudflare) og hold bare nødvendige porter åpne i DigitalOceans skybrannmur

#fail2ban-jails for WordPress-innlogging og sonderingsstier

fail2ban følger med på logger og legger inn midlertidige brannmursperrer når et filter treffer. Typiske jails for WordPress ser etter gjentatte 401/403/404 på innloggings- og sonderingsstier i nginx-loggene. Hold jails smale:

• Utesteng i minutter eller timer, ikke for alltid, til du stoler på filteret
• Unnta kontorets VPN og overvåkingstjenester
• Sjekk på nytt etter oppdateringer av WordPress eller plugins som endrer loggformatet

fail2ban er svært god mot støyende skannere. Den er en dårlig erstatning for å fikse et eksponert plugin-endepunkt som svarer 200 på hver sondering.

#Hvilke porter du bør åpne i DigitalOceans skybrannmur

Bruk DO-brannmuren (eller tilsvarende) til å åpne 22/80/443 for hele verden bare hvis du må, og velg nøkkelbasert SSH fra kjente IP-er. Nettverkssperrer stopper pakker før nginx. De bør likevel ikke være “sperr alle DigitalOcean-/16 på jorden”, som vil treffe kunder, byråer og CI-runnere hos samme leverandør.

#Stopper brannmur-plugins for WordPress bot-trafikk

Plugins som Wordfence, Sucuri og solide sikkerhetspakker gir innloggingsbeskyttelse, skanning etter skadevare og applikasjonsregler. De hjelper. De kjører likevel først etter at nginx har tatt imot tilkoblingen og PHP har startet.

Forbehold som betyr noe når du rydder i analysen:

• CPU-kostnad: hver blokkerte forespørsel har likevel betalt for en PHP-oppstart, med mindre noe avviste den tidligere.
• Falske treff: aggressive regler som “blokker ukjente land” eller “blokker alle sky-ASN-er” kan stenge ute frilansere, byråer og betalingsleverandører.
• Overlapp med edge-WAF: dupliserte regler i Cloudflare og i pluginet gjør feilsøking vanskeligere når en legitim bruker blir utfordret to ganger.
• Loggstøy: plugin-logger og GA4 vil være uenige fordi de ser ulike lag.

Rådene i WordPress-håndboken om herding gjelder fortsatt: hold kjerne og plugins oppdatert, gi databasebrukere minst mulig rettigheter og begrens filrettigheter. Et brannmur-plugin erstatter ikke det grunnleggende.

Praktisk rekkefølge:

1. Fiks eksponerte endepunkter og svake påloggingsdata.
2. Legg til ratebegrensning i nginx og fail2ban for støyende stier.
3. Legg til en WordPress-brannmur for applikasjonsbevisste regler og varsler.
4. Legg til Cloudflares bot-verktøy hvis du allerede bruker CDN-et.

#Slik blokkerer du boter med Cloudflare før de når WordPress

Hvis nettstedet ligger bak Cloudflare, bruk bot-dokumentasjonen deres i stedet for å finne på User-Agent-sperrelister på serveren. Edge-regler kan:

• Utfordre eller blokkere åpenbart automatisert trafikk før den når DigitalOcean
• Ratebegrense bestemte stier (/wp-login.php, /xmlrpc.php)
• Slippe gjennom verifiserte søkemotorboter når du konfigurerer det nøye

nginx-regler på serveren betyr fortsatt noe som forsvar i dybden hvis noen går utenom proxyen (grå sky i DNS, direkte server-IP). I full proxy-modus låser du droplet-brannmuren slik at bare Cloudflares IP-områder (eller admin-IP-ene dine) kan snakke med port 80/443.

Cloudflare gjør ikke GA4 nøyaktig av seg selv. Det reduserer misbrukende treff som ellers ville ha kjørt tagger eller tømt PHP. Mål både edge-analysen og GA4 etter at du endrer Bot Fight Mode eller WAF-regler, fordi utfordringer også kan endre hvordan ekte brukere fullfører en økt.

#Slik utfordrer du DigitalOcean-trafikk med WAF custom rules i Cloudflare

WAF custom rules i Cloudflare kan treffe nettverket en forespørsel kommer fra. Feltet heter ip.src.asnum og inneholder AS-nummeret til klientens IP, og nettverket til DigitalOcean er AS14061. Én regel rettet mot AS-et erstatter manuelt vedlikehold av 1 234 prefikser.

Hold omfanget smalt. En regel som bare berører DigitalOcean-trafikk på stiene boter misbruker, ser slik ut:

(ip.src.asnum eq 14061 and http.request.uri.path in {"/wp-login.php" "/xmlrpc.php"})

Velg Managed Challenge som handling, ikke Block. En person som jobber via en VPN som kjører på en droplet, kommer gjennom utfordringen; et enkelt skript gjør det som regel ikke. Block avslutter forespørselen, og fordi Cloudflare evaluerer custom rules i rekkefølge, stopper den også alle senere custom rules for den forespørselen.

Abonnementet avgjør hvor mange slike regler du har råd til. Cloudflare oppgir 5 custom rules på Free, 20 på Pro, 100 på Business og 1 000 på Enterprise, og regex-operatoren bare på Business og Enterprise. I en gratis sone gir én regel for ASN-utfordringen på innloggingsstier fire regler igjen til problemer du ikke kan løse på serveren.

#Bør du blokkere IP-områdene til DigitalOcean og AWS

Eldre råd limte lange deny from-lister for hele DigitalOcean- eller AWS-områder inn i .htaccess. Den tilnærmingen eldes dårlig:

• Leverandørenes områder endrer seg
• Legitim trafikk deler de samme områdene
• Apache-syntaksen deny gjør ingenting nyttig hvis du leverer WordPress via nginx uten Apache

Hvis du fortsatt bruker Apache, velg bekreftede enkeltadresser eller små CIDR-blokker fra dine logger, ikke en kopiert gigaliste:

# Bare et eksempel på formen - bytt ut med IP-er du har bekreftet i egne logger
# RequireAll / Require avhenger av autorisasjonssyntaksen i Apache 2.4
<RequireAll>
    Require all granted
    # Require not ip 203.0.113.10
</RequireAll>

I nginx bruker du deny i en geo/map-blokk eller fail2ban, og legger igjen en kort kommentar med dato og grunn til sperren. Gå gjennom sperrene hvert kvartal.

Publiser eller stol aldri på tabeller med “kjente bot-IP-er” fra tilfeldige innlegg uten å verifisere dem. De blir utdaterte og gir sideskader.

Hvor IP-blokkering kommer til kort, viste angrepet på Read the Docs i juni 2026, som David Fischer beskrev 8. september 2026. På det meste kom det over 5,5 millioner forespørsler i minuttet, omtrent 100 ganger normal trafikk, i nesten ti dager, fra millioner av unike IP-adresser i hundrevis av nettverk (ASN-er). Angriperne gikk etter 404-stier og 302-omdirigeringer som ikke lå i cache; teamet flyttet omdirigeringene ut til Cloudflare-kanten på rundt en halvtime, og ifølge Fischer var det trolig en “penalty box”-regel som gjorde størst forskjell, en regel som ratebegrenser klienter som samler mange 404- eller omdirigeringssvar. Hans første lærdom er at “IP-blokkering er foreldet ved distribuerte angrep” (egen oversettelse), og den strengeste reaksjonen Read the Docs bruker, er en JavaScript-utfordring. På WordPress gjelder samme logikk: cache 404-svar og omdirigeringer i kanten og ratebegrens mistenkelige klienter i stedet for å blokkere hele skyområder.

#Slik sjekker du i GA4 at bot-trafikken har gått ned

Etter at du har innført ratebegrensning eller sperrer, vent like lenge som utgangsperioden (7 eller 28 dager). Sammenlign deretter:

1. Brukere / Økter / Engasjerte økter: se etter at søppelvolumet faller mens engasjerte økter holder seg eller øker.
2. Landingssider: sonderings-URL-er skal krympe i GA4 hvis klientene kjørte JS; i nginx-loggene skal de krympe uansett.
3. Trafikkanskaffelse: mystiske kilder uten engasjement skal falle.
4. Servermålinger: travle PHP-FPM-arbeidere og 5xx-rater utenfor arbeidstid skal roe seg hvis misbruket mot serveren var reelt.
5. Search Console: crawlstatistikk og dekning skal ikke kollapse. Gjør de det, har du trolig blokkert en ekte crawler; rull tilbake og verifiser Googlebot ordentlig.

Noter endringsdatoen i GA4 (Admin > Merknader, eller teamets endringslogg), slik at du senere husker hva som flyttet kurven.

Hvis GA4 knapt rører seg mens avvisningene i nginx øker, kjørte botene aldri taggen din. Det er likevel en gevinst for serverhelsen, selv om analysekurven ser rolig ut.

Hvis GA4 faller kraftig og crawlfeilene i Search Console øker, fjern den siste deny-regelen først. Ren analyse er verdiløs hvis indekseringen går i stykker.

#Sjekkliste for å stoppe bot-trafikk i WordPress

Gå gjennom den i rekkefølge:

1. Lag et GA4-utgangspunkt (7/28 dager) og et utvalg av nginx-tilgangslogger.
2. Avklar om støyen kjører JS (GA4) eller bare treffer serveren (logger).
3. Stram inn ratebegrensningen for xmlrpc.php og innlogging i nginx.
4. Legg til fail2ban-jails for gjentatte sonderinger; unnta dine egne IP-er.
5. Hold robots.txt til råd for crawlere, ikke til sikkerhetsteater.
6. Legg til eller juster en WordPress-brannmur uten å blokkere hele skyleverandører.
7. Slå eventuelt på Cloudflares bot- og WAF-kontroller hvis nettstedet allerede bruker Cloudflare.
8. Mål GA4 og logger på nytt over en tilsvarende periode; følg med på Search Console.

Vil du ha hjelp til å gå gjennom crawlerstøy, serverregler og analysehygiene sammen med bredere SEO- og GEO-arbeid, er det et bedre valg enn å lime evige sperrelister inn i WordPress-roten. Utforsk også våre WordPress-utviklingstjenester for å løfte prosjektet ditt.