Hacket WordPress-nettsted: slik går du frem, steg for steg

En rød advarsel i Chrome, en videresending til et ukjent domene og et administrasjonspanel der alt ser ut som det pleier. Nødprosedyren for et WordPress-nettsted: hva du ikke skal gjøre den første timen, hvor infeksjonen faktisk gjemmer seg, og hvordan du blir kvitt Google-advarselen.

Torsdag morgen ringer en kunde og forteller at Chrome viser en rød fullskjermsadvarsel der nettbutikken din skulle ha vært; du åpner nettstedet på telefonen, og halvannet sekund senere kaster nettleseren deg videre til et domene du aldri har hørt om, mens kontormaskinen med administrasjonspanelet oppe siden mandag ser nøyaktig ut som den alltid har gjort. Slik ser et hacket WordPress-nettsted som regel ut — ikke en forside som er skjemmet og signert av angriperen, men et nettsted som viser eieren ett ansikt og de besøkende et annet, og derfor går de første timene som oftest med til å krangle om det i det hele tatt finnes et problem.

Spørsmålene denne artikkelen svarer på, blir vanligvis stilt i akkurat denne rekkefølgen: hva du har lov til og ikke har lov til å gjøre den første timen, mens ingen ennå vet hvor dypt angriperen kom inn; hvor i en WordPress-installasjon koden pleier å ligge gjemt, for uten det er opprydningen gjetning; og hvordan du får Google til å fjerne advarselen uten å ødelegge ditt eget forsøk nummer to. Midt imellom ligger steget eierne hopper over oftest — å bytte tilgangsdata på riktig tidspunkt og i riktig rekkefølge.

Alt som må gjøres de nærmeste timene, står her, og du skal ikke trenge å gå noe annet sted underveis. Utenfor artikkelen ligger bare det som er nyttig etter at nettstedet er oppe igjen — strategi for sikkerhetskopier, herding av systemet og beskyttelse mot neste gang, som er den samme uansett plattform — og vi peker på en egen veiledning om det lenger nede. Her handler det om det som gjør WordPress annerledes: økosystemet av utvidelser, mappen wp-content, databasetabellene der en infeksjon overlever en opprydning i filene, og kommandoene som lover mer enn de faktisk kontrollerer. Etter vår erfaring er det disse fire tingene som avgjør om et nettsted er rent etter én dag eller etter tredje forsøk.

Hacket WordPress-nettsted: den første timen sletter du ingenting

Den første reaksjonen er nesten alltid én av to — åpne filbehandleren hos webhotellet, finne noe ukjent der og slette det, eller trykke på knappen som gjenoppretter gårsdagens sikkerhetskopi. Vi ber deg la være med begge deler, og grunnen er praktisk, ikke byråkratisk. Hastverket er forståelig, for hver time under en rød advarsel koster deg besøkende, men det er nettopp i hastverket de to avgjørelsene tas som strekker en gjenoppretting fra åtte timer til en uke, og begge er uopprettelige.

Sletter du de infiserte filene, sletter du samtidig det eneste materialet som senere kan fastslå veien inn: tidspunktene for filendringer, innholdet i skriptene angriperen lastet opp, og oppføringene i serverens tilgangslogg som faller sammen med de samme tidspunktene. Uten veien inn fjerner en opprydning symptomer og ingenting mer, og prisen for det er målt — i en studie fra Google og University of California, Berkeley over 760 935 tilfeller av kapring mellom juli 2014 og juni 2015 ble 12 % av nettstedene kompromittert på nytt innen 30 dager, fordi symptomene og ikke årsaken var håndtert (Li mfl., WWW 2016).

Den første jobben er derfor en full kopi — alle filer og hele databasen i én operasjon, før et eneste byte er rørt, for den synlige videresendingen eller den skjemmede forsiden er sjelden alt som foregår: etter Sucuris tall ble det i 2023 funnet minst én bakdør (backdoor) på 49,21 % av de infiserte nettstedene, og i løpet av året fjernet teamet deres 21 062 av dem (Sucuri, «2023 Hacked Website & Malware Threat Report», juni 2024). Kopien oppbevarer du utenfor serveren selv, for det er der angriperen fortsatt har tilgang.

Neste telefon går til webhotellet, og ikke av høflighet: de sitter på tilgangsloggene som din egen konto vanligvis bare viser noen få dager tilbake, og på en delt server må de kontrollere om det samme skjer hos naboene. Tar nettstedet imot betalinger eller personopplysninger, skal det stenges nå eller settes i vedlikeholdsmodus — hver besøkende som taster inn kortopplysninger den neste timen, er et eget problem du ennå ikke har. Vedlikeholdsmodus koster én dags omsetning; et forsømt øyeblikk koster et brev til kundene.

Hvis wp-admin ikke lenger lar seg åpne — det skjer på et hacket nettsted — får du ikke slått på vedlikeholdsmodus fra panelet, og da står to veier igjen: en regel i .htaccess i rotmappen som sender alle andre enn din egen IP-adresse til én statisk side med melding om teknisk arbeid, eller en forespørsel til webhotellet, i den samme samtalen, om å sperre kontoen en stund. Det andre alternativet ser brutalt ut, men det virker også når du ikke lenger kommer til filene.

Gårsdagens sikkerhetskopi ser ut som den raskeste veien tilbake, og av og til er den faktisk det, men bare når du vet hvilken dag angriperen kom inn. Etter vår erfaring blir en infeksjon oppdaget atskillig senere enn den startet — koden ligger stille en stund, og så begynner den å servere spamsider eller videresendinger — og det betyr at bakdøren høyst sannsynlig allerede ligger i gårsdagens kopi. Å gjenopprette den skjuler symptomene et par timer og setter nettstedet tilbake i nøyaktig den tilstanden det ble hacket i, og derfor starter vi gjenoppretting av hackede nettsteder som regel innen få timer og begynner med en kopi framfor en sletting, uansett hvor travelt det er — også når kunden ringer og ber oss bare rense alt sammen, fort.

Tegnene som røper at WordPress-nettstedet er hacket

En videresending som slår inn for en besøkende som kommer fra et Google-treff, men ikke når adressen skrives rett inn i adressefeltet, er ingen forglemmelse, men angriperens bevisste valg: i Googles retningslinjer mot spam står videresendinger som en egen kategori hacket innhold, der angripere legger inn kode som videresender bare noen av de besøkende til skadelige eller useriøse sider (Google Search Central, kontrollert i august 2026). Det er nettopp dette forbeholdet — at bare noen av dem rammes — som villeder eieren. Kontrollen tar ett minutt: åpne nettstedet i et inkognitovindu, finn det så i Googles resultater og åpne det derfra, og gjenta begge deler på telefonen.

Den andre gruppen tegn sitter på administrasjonssiden og er langt mer konkret: wp-admin gir plutselig 404, innloggingsskjemaet lastes bare inn på nytt etter et riktig passord, brukerlisten inneholder en administratorkonto ingen i teamet ditt har opprettet, eller adressen under Innstillinger → Generelt er ikke lenger din. I databasen er det siste tegnet bare to rader i tabellen wp_options — siteurl og home — og nettopp derfor kan adressen du ser i innstillingene, og adressen den besøkende havner på, være to forskjellige ting.

Den tredje gruppen kommer utenfra og er den vondeste, for det er en annen som forteller deg hvordan ditt eget nettsted står: webhotellet stenger kontoen uten forvarsel etter at det har gått spam ut av den, det dukker opp en sikkerhetssak i Search Console, eller merkelappen «Dette nettstedet kan være hacket» kommer opp ved siden av lenken din i resultatene, og den viser Google når selskapet mener at en angriper har endret eksisterende sider eller lagt til nye spamsider (Google Search Help, kontrollert i august 2026). Google setter den merkelappen på eget initiativ og ikke etter en klage, og den dukker opp også når nettstedet ser plettfritt ut for deg selv.

Navnene er ikke et akademisk spørsmål her, for det er dem du kommer til å søke på og dem du kommer til å vurdere en leverandør etter: Googles egen dokumentasjon navngir tre — gibberish hack, Japanese keyword hack og cloaked keywords and links hack, der sidene angriperen har laget, viser søkemotoren én ting og den besøkende noe helt annet. Bransjefavoritten «pharma hack» kommer fra sikkerhetsselskapet Sucuri (2020) og finnes ingen steder i Googles dokumentasjon. Den praktiske kontrollen er likevel den samme for alle tre: kjør et site:-søk på ditt eget domene, så ligger sidene ingen i selskapet ditt har skrevet, rett foran deg. I den japanske varianten er de automatisk genererte sider med japanske overskrifter, i tilfeldig navngitte mapper på ditt eget domene.

Og så den ubehagelige delen: et rent skanneresultat beviser ikke at nettstedet er rent, for en skanner ser bare det serveren velger å vise den, angriperens kode kjenner ofte igjen både skannere og søkemotorroboter, og Googles veiledning om cloaked keywords and links hack advarer om at hacket gjerne blir skjult slik at eieren skal tro at problemet er over. Er skanningen ren mens webhotellet klager på utgående e-post, skal du tro på webhotellet. Da er det en sikkerhetsgjennomgang av nettstedet med manuell kontroll av filer og logger som er på sin plass, for en skanner svarer på om nettstedet inneholder noe fra en liste over kjente mønstre, ikke på om noen fortsatt er inne.

Hvor WordPress-risikoen faktisk ligger

Etter vår erfaring er årsaken, når den endelig blir funnet, nesten aldri WordPress-kjernen selv. Patchstacks rapport «State of WordPress Security in 2026» teller 11 334 nye sårbarheter som ble offentliggjort i WordPress-økosystemet i 2025 — 42 % flere enn året før — og det er fordelingen av det tallet som betyr noe for deg akkurat nå: 91 % av dem lå i utvidelser og 9 % i temaer, mens det i selve WordPress-kjernen ble rapportert bare seks gjennom hele året, alle med lav prioritet. Nesten hver eneste nyoppdagede sårbarhet ligger altså ikke i den WordPress du en gang installerte, men i det som er skrudd på den gjennom årene.

Hver utvidelse er en egen kodebase, skrevet av en egen utvikler med sin egen — og ganske ofte for lengst forlatte — oppdateringsdisiplin, så et nettsted med førti utvidelser er ikke et nettsted med ett sikkerhetsspørsmål, men med førti innbyrdes uavhengige. Etter vår erfaring klarer et vanlig bedriftsnettsted seg utmerket med ti til femten, og resten er rester etter oppgaver alle for lengst har glemt: et galleri som ikke vises lenger, et skjema som er erstattet av et annet, en bildekarusell dagens design ikke bruker. Når vi overtar utvikling og vedlikehold av WordPress-nettsteder, er det å kutte antallet utvidelser den første jobben og ikke den siste.

Og her er feilen som gjentar seg oftere enn noen annen: den unødvendige utvidelsen blir deaktivert i stedet for slettet — deaktivering forteller WordPress at den ikke skal lastes lenger, men filene blir liggende der de lå på serveren, en del av dem er fortsatt nåbare direkte over HTTP, og angriperens skript trenger bare å kjenne stien. I juni 2021 dokumenterte Wordfence en aktivt utnyttet nulldagssårbarhet i utvidelsen Fancy Product Designer, en feil som «i enkelte oppsett kan utnyttes selv om utvidelsen er deaktivert», og anbefalte å avinstallere den framfor å slå den av. Trenger du ikke utvidelsen lenger, hører den ikke hjemme grå i utvidelseslisten, men utenfor serveren.

Hvorfor alt dette skjer automatisk og uten noe personlig motiv bak, forklares av skalaen: etter tallene fra W3Techs drev WordPress 41,2 % av alle nettsteder 5. august 2026. I et økosystem av den størrelsen er hver offentliggjort sårbarhet i en utvidelse umiddelbart brukbar mot et svært stort antall likt bygde nettsteder, og derfor lønner det seg å automatisere angrepene framfor å sikte dem — skriptet leser versjonsnumre, ikke firmanavn. Ingen har valgt akkurat ditt nettsted, og nettopp derfor blir et lite bedriftsnettsted uten kundedata og uten betalinger hacket like rolig som en stor nettbutikk.

Hvor angriperen gjemmer koden i en WordPress-installasjon

Det første stedet vi åpner, er wp-content/uploads — en mappe som i praksis bare rommer bilder, PDF-filer og video, og der ingen PHP-fil noen gang skal kjøre. Ligger det en fil med endelsen .php der mellom produktbildene fra 2019, har den ikke havnet der ved et uhell: nesten alltid er den enten en opplaster angriperen bruker til å få neste runde filer inn på serveren, eller et skall som lar noen kjøre kommandoer med serverens rettigheter. At problemet er reelt og ikke teoretisk, ser du allerede av at både Sucuri og Wordfence har en egen herdingsinnstilling som med en regel i .htaccess slår av PHP-motoren i nettopp denne mappen.

Det andre stedet er wp-content/mu-plugins. Utvidelser som legges der, blir aktivert automatisk, de kan ikke deaktiveres fra administrasjonspanelet, og — det som betyr mest i denne sammenhengen — de dukker ikke opp i den vanlige utvidelseslisten, så en eier kan sitte i månedsvis og se på et tilsynelatende rent panel; i juli 2025 beskrev Sucuri nøyaktig et slikt tilfelle, med en bakdør i den mappen. Ved siden av den kontrollerer vi alltid .htaccess, både i rotmappen og i undermappene, for en videresending som bare slår inn for besøkende fra en søkemotor eller bare på mobile enheter, er som oftest skrevet der — og det er grunnen til at ditt eget nettsted ser helt normalt ut for deg.

Kode blir også skrevet inn i de første linjene av eksisterende og fullstendig legitime filer, oftest øverst i wp-config.php og i temaets functions.php, og den ser nesten aldri ut som skadelig kode: det er én lang linje med et kall til base64_decode, gzinflate eller eval, etterfulgt av hundrevis av tomme linjer slik at filen ser ferdig ut i redigeringsprogrammet. Derfor er det mer verdt å sammenligne filene med en ren original enn å lese dem: den linjen finner ingen med øyet, for ingen ruller en fil ned til linje ni hundre.

Og så er det databasen, der en filskanner ikke ser etter, og der tre steder må kontrolleres: radene siteurl og home i wp_options, som angriperen skriver om for at sidene dine skal laste ressursene sine fra en fremmed server; tabellen wp_users, der det gjerne dukker opp en administratorkonto med et troverdig navn; og innholdet i wp_posts, der skjulte lenker og iframe-kode blir bygd inn midt i gamle artikler ingen åpner lenger. Blir filene renset mens injeksjonen blir liggende i databasen, er infeksjonen tilbake samme dag. Selve raden kjører ikke — den blir lest og kjørt ved hver sidelasting av en liten laster i temaets functions.php eller i mu-plugins — og sammen setter de to tilbake de slettede filene raskere enn du rekker å kontrollere resultatet. Nettopp derfor er filer og database én jobb for oss i gjenoppretting av hackede nettsteder, ikke to.

Sammenligning av filene mot kontrollerte originaler

Det første verktøyet vi tar fram når den fulle fil- og databasekopien er sikret, er wp core verify-checksums: den sammenligner hashverdien til hver fil med kontrollsummene WordPress.org publiserer, og viser straks hvilke filer som er endret og hvilke som ikke har noe i installasjonen å gjøre. Problemet begynner der rekkevidden slutter — kommandoen kontrollerer bare wp-admin/, wp-includes/ og wp-*-filene i rotmappen, mens kildekoden bevisst hopper over hele wp-content, altså utvidelser, temaer og opplastinger (kildekoden til WP-CLIs checksum-command, sett 5. august 2026). Den samme kildekoden utelater én rotfil for seg — wp-config.php — så filen som oftest får kode skrevet inn i de første linjene, er usynlig for kontrollen. Et rent resultat fra kommandoen betyr ikke et rent nettsted.

For utvidelser finnes en egen kommando, wp plugin verify-checksums, men også den sammenligner filene bare med kontrollsummene i WordPress.org-repositoriet, så en kommersiell utvidelse du har kjøpt av utvikleren, blir rett og slett hoppet over; for temaer finnes det ingen tilsvarende kommando i WP-CLI-dokumentasjonen i det hele tatt (WP-CLI-dokumentasjonen, sett 5. august 2026). Verken temaer eller utvidelser kjøpt utenfor repositoriet lar seg dermed kontrollere automatisk, og wp core verify-checksums utelater hele wp-content — nettopp den delen av koden der alle de 11 334 sårbarhetene Patchstack talte opp for 2025 oppsto, bortsett fra kjernens seks. På nettstedene vi overtar, er det gjerne temaet som er det ene ingen noen gang har kontrollert.

Kontrollsummene er derfor et utgangspunkt og ikke en metode: kjernen og utvidelsene kurerer vi ikke, vi erstatter dem, det vil si laster ned de samme versjonene fra den opprinnelige kilden og skriver over mappene i sin helhet framfor fil for fil. Fra den gamle installasjonen beholder vi wp-content/uploads, og det bare etter en kontroll av at det ikke ligger PHP-filer mellom bildene — av samme grunn som gjør det verdt å slå av PHP-motoren i den mappen i det hele tatt. Temaet gjenoppretter vi fra versjonskontroll hvis det finnes noen; finnes det ikke, tar vi utviklerens egen kopi og legger tilpasningene på igjen bevisst, én om gangen, for bare da kan vi si senere hvilken linje på nettstedet som er vår og hvilken som ikke er det.

Å finne den ene stygge linjen og slette den høres billigere ut, og nettopp derfor er det den mest gjentatte feilen av alle: en angriper legger sjelden igjen bare én vei inn, og én ubemerket bakdør gjør alt det andre arbeidet forgjeves. Koden kan være delt over flere filer, gjemt bak et kall til base64 eller gzinflate, skrevet inn i opsjonstabellen i databasen eller lagt i den samme mu-plugins-mappen som administrasjonspanelet ikke viser. Et søk etter et mønster finner det du allerede kjenner igjen; en fullstendig utskifting kvitter deg også med det du ikke kjenner igjen.

Det finnes også arbeid vi ikke gjør på dette stadiet: vi stoler ikke på en utvidelse som tilbyr å «reparere» infiserte filer med ett trykk, for den arbeider ut fra den samme listen over kjente mønstre, og dessuten i det samme miljøet som angriperen fortsatt har tilgang til. Vi sammenligner heller ikke filer for hånd når nettstedet er på størrelse med et vanlig visittkortnettsted eller en blogg, for en fersk installasjon med innholdet flyttet over krever færre timer enn å sammenligne to kataloger linje for linje, og resultatet lar seg kontrollere. Grundig manuell sammenligning hører hjemme der temaet eller en utvidelse er unik og versjonskontroll mangler; hvordan sikkerhetskopiene skal håndteres for at det valget i det hele tatt skal finnes, har vi beskrevet i den generelle gjenopprettingsveiledningen.

Nøkler, økter og passord: hva hver av dem faktisk gjør

Autentiseringsnøklene og saltet i wp-config.php krypterer ingenting, uansett hva nesten hver eneste veiledning påstår: WordPress bruker dem som grunnlag for nøkkelen som funksjonen wp_generate_auth_cookie() signerer autentiseringskapselen med, ved hjelp av HMAC-SHA256, mens selve informasjonskapselen er ren tekst med brukernavn, utløpstidspunkt og et økttoken (WordPress Developer Resources, sett 5. august 2026). Byttes disse verdiene, blir derfor hver signatur som er utstedt tidligere, umulig å verifisere, og serveren avviser hver eneste informasjonskapsel som er delt ut fram til da, selv der økten formelt sett ikke er utløpt.

Den praktiske følgen er nøyaktig den et innbrudd krever: WordPress' offisielle dokumentasjon beskriver bytte av nøkler som måten å kaste ut alle som ennå måtte være innlogget (WordPress.org, «FAQ My site was hacked», oppdatert 26. juli 2026), så holder angriperen en gyldig økt, tar den slutt i samme øyeblikk. Sammen med øktene blir også hvert utstedte nonce-token ugyldig, så skjemaer som er påbegynt og halvferdige steg i en bestilling brytes der og da — tidspunktet for byttet velger vi bevisst, ikke tilfeldig midt i en arbeidsdag.

Bytte av nøkler og salt endrer ikke ett eneste passord. Passordhashene bygger WordPress med bcrypt og et eget tilfeldig salt for hvert passord, uten forbindelse til konstantene i wp-config.php (funksjonen wp_hash_password(); bcrypt som standard siden WordPress 6.8), så en angriper som kjenner administratorens passord eller har rukket å lage seg en konto, logger rett og slett inn på nytt etter nøkkelbyttet. Passordene byttes for seg og alle sammen, også de ingen liksom kjenner, og samtidig går du gjennom brukerlisten på jakt etter kontoer ingen i teamet ditt har opprettet.

Listen over tilgangsdata slutter ikke med WordPress: i den samme runden byttes passordet til kontrollpanelet hos webhotellet, tilgangsdataene for FTP og SFTP, passordet til databasebrukeren sammen med den tilhørende oppføringen i wp-config.php, og SSH-nøklene, som ikke byttes slik et passord byttes, men genereres på nytt, med den gamle offentlige nøkkelen slettet fra filen authorized_keys på serveren. Til slutt byttes alle API-nøklene som er lagret på nettstedet — betalingsløsningen, tjenesten for e-postutsending, integrasjonene mot frakt og regnskap — for de blir gjerne liggende urørt lengst: ingen ser dem på en skjerm fra dag til dag.

Gå ut fra at angriperen har en full kopi av databasen, for det er det billigste steget i hele angrepet: alt som har ligget der — kundenes e-postadresser, ordrehistorikk, passordhasher og nøklene som er skrevet inn i innstillingene til utvidelser — må regnes som havnet i fremmede hender. Er noen av disse passordene brukt et annet sted også, er det stedet kompromittert, og det er som regel her samtalen flytter seg fra nettstedet over til e-postkontoene, regnskapssystemet og butikkens betalingskonto.

Rekkefølgen betyr like mye som selve listen: nøkler og passord byttes etter at bakdørene er tatt ut, for ellers leser angriperen de nye verdiene rett ut av wp-config.php eller fanger simpelthen opp den neste innloggingen. Nettopp denne linjen — full kopi først, så årsaken, så opprydningen og aller sist tilgangsdataene — er der en gjenoppretting på egen hånd oftest stopper opp eller går i surr, og derfor tar vi dette stadiet på oss selv og leverer til slutt en skriftlig rapport over hva som ble endret, når og hvorfor.

Slik får du Google-advarselen fjernet, og hva du gjør etterpå

Rapporten over sikkerhetsproblemer i Google Search Console er det eneste stedet der du kan se hva Google faktisk har funnet på nettstedet ditt: den navngir trusseltypen og viser et utvalg av de berørte sidene, og hva den besøkende ser akkurat nå, følger av det. Trusseltypen endrer likevel ikke hva den besøkende ser: Chrome sorterer ikke lenger overskriften i advarselen etter om det er funnet phishing, skadevare eller uønsket programvare, men viser den samme fullskjermsadvarselen i alle tilfeller — på norsk med overskriften «Farlig nettsted» — og den slipper rett og slett ingen inn på nettstedet, mens merkelappen «Dette nettstedet kan være hacket», som allerede er nevnt, bare er en tekstlinje ved siden av lenken i resultatene og lar seg klikke forbi (Googles hjelpeside for Chrome om farlige nettsteder, kontrollert i august 2026). De eldre overskriftene som varierte med trusseltypen — «Deceptive site ahead», for eksempel — bruker Chrome ikke lenger, selv om de fortsatt står igjen i deler av Googles dokumentasjon. Den første blokkerer, den andre advarer, og det endrer hvor mye tid du i praksis har.

Før du ber Google om en ny vurdering, må du være sikker på at nettstedet virkelig er rent og ikke bare ser rent ut i din egen nettleser. Googles veiledning om cloaked keywords hack advarer uttrykkelig om at angripere forsøker å gi inntrykk av at en side allerede er slettet eller reparert, så hver eneste tidligere spamside må kontrolleres med URL-inspeksjonsverktøyet, som viser Googlebots utsikt og ikke din. Det andre steget folk hopper over oftest, er eierlisten: ved Japanese keyword hack legger angriperen seg selv til som verifisert eier i Search Console (Googles dokumentasjon på web.dev), og så lenge han ikke er tatt av den listen, vet han nøyaktig like mye om tilstanden på nettstedet ditt som du gjør.

Knappen du skal se etter, ligger i rapporten over sikkerhetsproblemer og ber om en ny sikkerhetsvurdering av nettstedet — det er ikke den forespørselen om ny behandling som Google bruker ved manuelle tiltak. I selve forespørselen er tre ting verdt å skrive: hva som ble funnet, hvordan angriperen kom inn, og hva som konkret er gjort for å lukke det. Noen frist lover vi ikke, for det gjør ikke Google heller: dokumentasjonssiden om sosial manipulering sier at en vurdering kan ta flere dager, mens hjelpesiden om sikkerhetsproblemer i Search Console opererer med fra noen få dager til noen få uker (begge kontrollert i august 2026). Nevner noen konkrete 24 eller 72 timer for deg, gjentar de et tall som ikke står i noen Google-kilde.

Hastverk i dette steget koster mer enn det å vente gjør. I den samme studien fra Google og University of California, Berkeley fikk 80 % av eierne nettstedet erklært rent allerede ved første forsøk, mens de øvrige 20 % trengte flere, og mediantiden de brukte på å gre ut koden angriperen hadde lagt igjen, var en hel uke. Dataene er fra 2014–2015 og skal leses som det, men regnestykket har ikke endret seg: en avvist forespørsel betyr at advarselen blir stående enda en runde, og andre gangen er du ikke lenger en førstegangssøker.

Når advarselen er borte, er arbeidet likevel ikke ferdig, for sidene angriperen laget, blir liggende i indeksen, og de skal ikke videresendes til forsiden — de må gi 404 eller 410 for at Google skal fjerne dem helt, mens fjerningsverktøyet i Search Console bare skjuler dem en stund. Rangeringen kommer ikke tilbake med et bryterslag: sidene må indekseres på nytt, og det skjer i Googles tempo og ikke i ditt. Hvordan du bruker loggfiler og sikkerhetskopier i dette stadiet, slik at utgangspunktet blir bedre neste gang, har vi beskrevet i en egen veiledning om gjenoppretting av hackede nettsteder.

Når du bør slutte å gjøre det selv, og hva det koster

En erfaren nettstedseier gjør deler av dette selv, og det sier vi rett ut også til folk som ringer oss med Search Console åpen og den skyldige utvidelsen allerede funnet. Er infeksjonen én skjemmet forside, viser loggfilene hvilken utvidelse som slapp den inn, står det ingen fremmede administratorer i brukerlisten, og finnes det en sikkerhetskopi fra i går som noen faktisk har gjenopprettet i et testmiljø, da kjøper åtte betalte timer deg roligere søvn og ikke et raskere resultat.

Det er fire situasjoner der vi anbefaler å stoppe, og den første er ny infeksjon etter en opprydning: blir nettstedet hacket for andre gang, er det ikke et spørsmål om uflaks, men et bevis på at veien inn fortsatt står åpen, og en tredje opprydning i det samme miljøet koster nøyaktig like mye som de to første. Den andre er enhver skygge av mistanke om kunde- eller betalingsdata, for der kommer det plikter overfor tilsynsmyndigheten i tillegg til det tekniske arbeidet, og frister som ingen velvilje forlenger. Den tredje er et nettsted bedriften tjener penger på hver eneste dag, og den fjerde er ren mangel på tid: en opprydning er ikke intellektuelt vanskelig, men den er lang, ensformig og tilgir ikke én eneste fil du hopper over.

Gjenoppretting av hackede nettsteder koster hos oss 90 € i timen uten mva., med et minimum på åtte arbeidstimer som betales på forskudd. Arbeidet starter vi som regel innen få timer etter henvendelsen, og hele prosessen fra start til overlevering tar vanligvis 8–72 timer; forskjellen mellom åtte og syttito timer ligger nesten alltid i hvor dypt angriperen rakk å slå seg ned og hvor gammel den siste rene kopien er. Minimumet er ikke et markedsføringstall: en full kopi, jakten på årsaken i loggfilene, opprydningen og kontrollen får sjelden plass på mindre.

Rekkefølgen er den samme som over, bare uten helgen din i den. Før vi rører noe som helst, tar vi en full kopi av filene og databasen, slik at hendelsen i det hele tatt lar seg undersøke i ettertid, og først da blir nettstedet isolert; derfra blir det renset for skadevare og bakdører, databasen kontrollert, tilgangsdata og nøkler byttet, veien inn funnet og lukket, forespørselen om ny vurdering sendt til Google og overvåkingen satt opp, og til slutt får du en skriftlig rapport om hva som skjedde og hva som ble endret. Ligger nettstedet nede akkurat nå, eller er du usikker på hva du ser på, kan du bestille en hastesjekk av nettstedet, så sier vi fra om det i det hele tatt er noe her å betale for.

I mange tilfeller er det riktige svaret likevel ikke gjenoppretting, men det som kommer etter den: har et nettsted samlet på seg tjue utvidelser der ingen lenger husker grunnen til halvparten, ligger problemet i vedlikeholdet, og det løses av utvikling og vedlikehold av WordPress og ikke av enda en opprydningsrunde et halvt år fram i tid. Den billigste timen i hele denne historien er den som er brukt på forhånd: å slette en ubrukt utvidelse fra wp-content/plugins i stedet for å deaktivere den, og en sikkerhetskopi noen faktisk har gjenopprettet i et testmiljø én gang, koster til sammen mindre enn én av våre arbeidsdager.