Hackad WordPress-webbplats: så gör du, steg för steg

En röd varning i Chrome, en omdirigering till en främmande domän och en adminpanel där allt ser ut som vanligt. Akutgången för just en WordPress-webbplats: vad du inte får göra den första timmen, var infektionen faktiskt gömmer sig och hur du blir av med Googles varning.

En torsdagsmorgon ringer en kund och säger att Chrome visar en röd helskärmsvarning där din butik borde ligga; du öppnar webbplatsen i telefonen, och en och en halv sekund senare kastas webbläsaren vidare till en helt främmande domän, medan kontorsdatorn, där adminpanelen har stått öppen sedan i måndags, ser precis ut som den brukar. Så ser en hackad WordPress-webbplats oftast ut — inte som en sönderskriven startsida med angriparens signatur, utan som en webbplats som visar ett ansikte för ägaren och ett annat för besökaren, och därför går de första timmarna oftast åt till att diskutera om det över huvud taget finns ett problem.

Frågorna som får svar här ställs nästan alltid i den här ordningen: vad du får och inte får göra den första timmen, medan ingen ännu vet hur djupt angriparen har tagit sig; var i en WordPress-installation koden brukar ligga gömd, eftersom en sanering utan det svaret är ren gissning; och hur du får Google att ta bort varningen utan att förstöra ditt eget andra försök. Däremellan ligger steget som ägare hoppar över allra oftast — att byta inloggningsuppgifter vid rätt tidpunkt och i rätt ordning.

Allt som behöver göras de närmaste timmarna står här, och du ska inte behöva gå någon annanstans halvvägs. Utanför artikeln ligger bara det som blir aktuellt när webbplatsen fungerar igen — strategin för säkerhetskopior, härdningen och skyddet mot nästa gång, som ser likadant ut oavsett plattform — och en separat guide om det hänvisar vi till längre ned. Här handlar det om det som gör WordPress annorlunda: ekosystemet av tillägg, mappen wp-content, databastabellerna där en infektion överlever en filsanering, och kommandona som lovar mer än de faktiskt kontrollerar. I vår erfarenhet är det de fyra sakerna som avgör om en webbplats är ren efter en dag eller efter det tredje försöket.

Hackad WordPress-webbplats: radera ingenting den första timmen

Den första reaktionen är nästan alltid en av två — att öppna filhanteraren hos webbhotellet, hitta något främmande där och radera det, eller att trycka på knappen som återställer gårdagens säkerhetskopia. Vi ber dig låta bli båda, och skälet är praktiskt snarare än byråkratiskt. Brådskan är fullt begriplig, eftersom varje timme under den röda varningen kostar besökare, men det är just i brådskan som de två besluten fattas som drar ut en återställning från åtta timmar till en vecka, och båda är oåterkalleliga.

När de infekterade filerna är raderade försvinner också det enda underlag som vägen in senare bestäms utifrån: filernas ändringstider, innehållet i skripten angriparen laddade upp och raderna i serverns åtkomstlogg som sammanfaller med de tiderna. Utan vägen in är en sanering bara symptomlindring, och priset för det är mätt — i en studie av Google och University of California, Berkeley som omfattade 760 935 kapade webbplatser mellan juli 2014 och juni 2015 hackades 12 % av webbplatserna på nytt inom 30 dagar, eftersom bara symptomen och inte orsaken hade åtgärdats (Li m.fl., WWW 2016).

Det första arbetet är därför en fullständig kopia — alla filer och hela databasen i ett svep, innan en enda byte rörs, för den synliga omdirigeringen eller den sönderskrivna startsidan är sällan allt som pågår: enligt Sucuris siffror hade 49,21 % av de webbplatser som infekterades under 2023 minst en bakdörr (backdoor), och under året plockade deras team bort 21 062 sådana program (Sucuri, ”2023 Hacked Website & Malware Threat Report”, juni 2024). Förvara kopian utanför samma server, för det är där angriparen fortfarande har åtkomst.

Nästa samtal går till webbhotellet, och inte av artighet: de har åtkomstloggarna som i ditt eget konto oftast bara syns några dagar bakåt, och på en delad server måste de kontrollera om samma sak pågår i kontona bredvid. Tar webbplatsen emot betalningar eller personuppgifter ska den stängas av nu eller sättas i underhållsläge — varje besökare som knappar in sina kortuppgifter den närmaste timmen är ett eget problem som du ännu inte har. Underhållsläget kostar en dags omsättning; ett missat ögonblick kostar ett brev till kunderna.

Öppnas wp-admin inte längre — vilket händer på en hackad webbplats — går underhållsläget inte att slå på från panelen, och då återstår två vägar: en regel i .htaccess i webbplatsens rot som skickar alla utom din egen IP-adress till en statisk sida om tekniskt underhåll, eller en begäran i samma samtal om att webbhotellet stänger av kontot en tid. Det andra alternativet ser brutalt ut, men fungerar även när du inte längre kommer åt filerna.

Gårdagens säkerhetskopia ser ut som den snabbaste vägen tillbaka, och ibland är den det, men bara när du vet vilken dag angriparen tog sig in. I vår erfarenhet upptäcks en infektion betydligt senare än den började — koden ligger först tyst en tid och börjar sedan servera skräpsidor eller omdirigeringar — och det betyder att bakdörren med största sannolikhet redan finns i gårdagens kopia. En återställning döljer då symptomen i ett par timmar och sätter tillbaka webbplatsen i exakt det skick den en gång hackades i, och därför inleder vi återställning av hackade webbplatser normalt inom några timmar och börjar också i brådskan med en kopia i stället för en radering, även när kunden ringer och ber oss bara sanera alltihop fort.

Tecknen som avslöjar en hackad WordPress-webbplats

En omdirigering som slår till för en besökare som kommer från ett Google-resultat men inte när adressen skrivs in i adressfältet är inget missförstånd utan angriparens medvetna val: Googles riktlinjer mot skräppost räknar upp omdirigeringar som en egen kategori av hackat innehåll, där angripare lägger in kod som skickar en del av användarna vidare till skadliga sidor eller skräpsidor (Google Search Central, kontrollerat i augusti 2026). Det är ordet en del som vilseleder ägaren. Kontrollen tar en minut: öppna webbplatsen i ett inkognitofönster, leta sedan upp den i Googles resultat och öppna den därifrån, och upprepa båda i telefonen.

Den andra gruppen tecken sitter på administrationssidan och är betydligt mer konkret: wp-admin ger plötsligt 404, inloggningsformuläret laddas bara om efter ett korrekt lösenord, användarlistan innehåller ett administratörskonto som ingen i ditt team har skapat, eller så är webbplatsens adress under Inställningar → Allmänt inte längre din. I databasen är det sista tecknet bara två rader i tabellen wp_options — siteurl och home — och det är precis därför adressen du ser i inställningarna och adressen besökaren hamnar på kan gå isär.

Den tredje gruppen kommer utifrån och är den mest smärtsamma, eftersom någon annan berättar för dig hur din egen webbplats mår: webbhotellet stänger av kontot utan förvarning sedan det gått skräppost ur det, ett säkerhetsproblem dyker upp i Search Console, eller så står det ”Denna webbplats kan ha blivit hackad” bredvid din länk i sökresultatet — en text Google visar när den har skäl att tro att en angripare har ändrat befintliga sidor eller lagt till nya skräpsidor (Googles hjälp för Sök, kontrollerad i augusti 2026). Den texten sätter Google dit på eget initiativ, inte efter någons anmälan, och den dyker upp även när webbplatsen ser felfri ut för dig.

Namnen är ingen akademisk fråga, för det är på dem du kommer att söka och efter dem du bedömer om den du anlitar begriper ditt fall: Google namnger tre i sin dokumentation — gibberish hack, Japanese keyword hack och cloaked keywords and links hack, där angriparens sidor visar ett innehåll för sökmotorn och ett annat för besökaren. Branschens favorit ”pharma hack” kommer från säkerhetsföretaget Sucuri (2020) och finns ingenstans i Googles dokumentation. Den praktiska kontrollen är ändå densamma för alla tre: kör en site:-sökning på din egen domän, så ligger sidorna som ingen i ditt företag har skrivit framför dig. I den japanska varianten är de automatgenererade sidor med japanska rubriker, i slumpmässigt namngivna mappar på din domän.

Och så den obehagliga delen: ett rent skanningsresultat bevisar inte att webbplatsen är ren, eftersom en skanner bara ser det servern väljer att visa den, angriparens kod känner ofta igen skannrar och sökmotorernas robotar, och Googles guide till maskerade nyckelordssidor varnar för att hacket brukar döljas så att ägaren ska tro att problemet redan har gått över. Är skanningen ren men webbhotellet klagar på utgående e-post, tro på webbhotellet. Då är det läge för en säkerhetsgranskning av webbplatsen med manuell genomgång av filer och loggar, för en skanner svarar på om webbplatsen innehåller något ur en lista över kända mönster, inte på om någon fortfarande är inne.

Var risken i WordPress faktiskt sitter

I vår erfarenhet är orsaken, när den till slut hittas, nästan aldrig själva WordPress-kärnan. Patchstacks rapport ”State of WordPress Security in 2026” räknar 11 334 nya sårbarheter som offentliggjordes i ekosystemet kring WordPress under 2025 — 42 % fler än året innan — och det är fördelningen av den siffran som spelar roll för dig just nu: 91 % av dem satt i tillägg och 9 % i teman, medan det i själva WordPress-kärnan rapporterades sex under hela året, samtliga med låg prioritet. Nästan varje nyupptäckt sårbarhet sitter alltså inte i det WordPress du en gång installerade, utan i det som har skruvats fast på det genom åren.

Varje tillägg är en egen kodbas, skriven av en egen upphovsman med en egen — och ganska ofta redan övergiven — uppdateringsdisciplin, så en webbplats med fyrtio tillägg är inte en webbplats med en säkerhetsfråga utan en webbplats med fyrtio inbördes oberoende säkerhetsfrågor. I vår erfarenhet klarar sig en vanlig företagswebbplats alldeles utmärkt med tio till femton, och resten är kvar sedan uppgifter som alla för länge sedan har glömt bort: ett galleri som inte visas längre, ett formulär som ersatts av ett annat, en bildspelsmodul som den nuvarande designen inte använder. När vi tar över utveckling och förvaltning av WordPress-webbplatser är att skära ned antalet tillägg det första arbetet, inte det sista.

Och här är misstaget som återkommer oftare än något annat: det onödiga tillägget avaktiveras i stället för att raderas. Avaktiveringen säger åt WordPress att inte ladda det längre, men filerna ligger kvar på sin plats på servern, en del av dem är fortfarande nåbara direkt över HTTP, och för angriparens skript räcker det att känna till sökvägen. I juni 2021 dokumenterade Wordfence en aktivt utnyttjad nolldagssårbarhet i tillägget Fancy Product Designer, som i vissa konfigurationer gick att utnyttja även när tillägget var avaktiverat, och rådet blev att avinstallera det helt i stället för att stänga av det. Behöver du inte längre ett tillägg är dess plats inte gråmarkerad i listan, utan utanför servern.

Varför allt det här sker automatiskt och utan ett spår av personligt motiv förklaras av skalan: enligt W3Techs driver WordPress den 5 augusti 2026 41,2 % av alla webbplatser. I ett ekosystem av den storleken går varje offentliggjord sårbarhet i ett tillägg omedelbart att använda mot ett mycket stort antal likadant byggda webbplatser, och därför lönar det sig bättre att automatisera angreppen än att rikta dem — skriptet läser versionsnummer, inte företagsnamn. Ingen har valt just din webbplats, och det är precis därför en liten företagswebbplats utan kunddata och utan betalningar hackas lika lugnt som en stor webbutik.

Var angriparen gömmer koden i en WordPress-installation

Den första platsen vi öppnar är wp-content/uploads — en mapp som i grunden bara innehåller bilder, PDF-filer och video, och där ingen PHP-fil någonsin ska köras. Ligger det en fil med ändelsen .php där bland produktbilderna från 2019 har den inte hamnat där av en slump: nästan alltid är det antingen en uppladdare som angriparen använder för att få in nästa omgång filer på servern, eller ett skal som kör kommandon i din servers namn. Att problemet är verkligt och inte teoretiskt syns redan på att både Sucuri och Wordfence har en egen härdningsinställning som med en .htaccess-regel stänger av PHP-motorn i just den mappen.

Den andra platsen är wp-content/mu-plugins. Det som läggs där aktiveras automatiskt, går inte att avaktivera från adminpanelen och — vilket är det viktigaste i sammanhanget — syns inte i den vanliga listan över tillägg, så en webbplatsägare kan i månader titta på en till synes ren panel; i juli 2025 beskrev Sucuri exakt ett sådant fall, med en bakdörr i den mappen. Vid sidan av den kontrollerar vi alltid .htaccess, både i roten och i undermapparna, eftersom en omdirigering som bara slår till för besökare från en sökmotor eller bara i mobilen oftast är skriven där — och det är skälet till att du ser din egen webbplats som fullständigt normal.

Kod skrivs också in i de första raderna i befintliga, fullt legitima filer, oftast överst i wp-config.php och i temats functions.php, och den ser nästan aldrig ut som skadlig kod: det är en enda lång rad med ett anrop till base64_decode, gzinflate eller eval, följd av hundratals tomma rader så att filen ska se slut ut i redigeraren. Därför är en jämförelse mot ett rent original mer värd än att läsa: den raden hittar ingen med ögat, för ingen rullar en fil ned till rad niohundra.

Och så finns databasen, dit en filskanner inte tittar och där tre ställen ska kontrolleras: raderna siteurl och home i wp_options, som angriparen skriver om för att dina sidor ska hämta sina resurser från någon annans server; tabellen wp_users, där det brukar dyka upp ett administratörskonto med ett trovärdigt namn; och innehållet i wp_posts, där dolda länkar och iframe-kod byggs in mitt i gamla artiklar som ingen längre öppnar. Saneras filerna men injektionen ligger kvar i databasen är infektionen tillbaka samma dag. Raden i sig körs inte — den läses och startas vid varje sidladdning av en liten laddare i temats functions.php eller i mappen mu-plugins — och tillsammans återskapar de två de raderade filerna snabbare än du hinner kontrollera resultatet. Just därför är filer och databas ett enda arbete för oss i återställning av hackade webbplatser, inte två.

Jämförelse av filerna mot verifierade original

Det första verktyget vi tar till när den fullständiga kopian av filer och databas är säkrad är wp core verify-checksums: det jämför varje fils hashvärde mot kontrollsummorna som WordPress.org publicerar och visar direkt vilka filer som har ändrats och vilka som över huvud taget inte hör hemma i installationen. Problemet börjar där räckvidden tar slut — kommandot kontrollerar bara wp-admin/, wp-includes/ och wp-*-filerna i roten, medan hela mappen wp-content, alltså tillägg, teman och uppladdningar, medvetet hoppas över i källkoden (källkoden till WP-CLI:s checksum-command, läst den 5 augusti 2026). Samma källkod utesluter dessutom en enskild fil i roten, wp-config.php, så just den fil vars första rader oftast bär den injicerade koden är osynlig för kontrollen. Ett rent resultat från kommandot betyder alltså inte en ren webbplats.

För tillägg finns ett eget kommando, wp plugin verify-checksums, men även det jämför filerna enbart mot kontrollsummorna i katalogen på WordPress.org, så ett kommersiellt tillägg som du har köpt av utvecklaren hoppas helt enkelt över; för teman finns inget motsvarande kommando alls i WP-CLI:s dokumentation (WP-CLI:s dokumentation, läst den 5 augusti 2026). Varken teman eller tillägg som köpts utanför katalogen går alltså att kontrollera automatiskt, och wp core verify-checksums utelämnar hela wp-content — den del av koden där alla utom kärnans sex av de 11 334 sårbarheter Patchstack räknade för 2025 uppstod. På de webbplatser vi tar över brukar temat vara det enda som ingen någonsin har granskat.

Kontrollsummor är därför en utgångspunkt och ingen metod: kärnan och tilläggen botar vi inte, vi byter ut dem, alltså laddar ned samma versioner från originalkällan och skriver över mapparna i sin helhet i stället för fil för fil. Från den gamla installationen behåller vi wp-content/uploads, och även den först efter en kontroll av att det inte ligger PHP-filer bland bilderna — av precis samma skäl som gör det värt att stänga av PHP-motorn i den mappen över huvud taget. Temat återställer vi från versionshanteringen om det finns någon; finns den inte tar vi utvecklarens egen kopia och lägger på anpassningarna medvetet, en i taget, eftersom det bara är så vi senare kan säga vilken rad på webbplatsen som är vår.

Att leta rätt på den dåliga raden och radera den låter billigare, och det är just därför det är det mest upprepade misstaget av alla: en angripare lämnar sällan en enda väg in, och en enda obemärkt bakdörr gör allt det övriga arbetet meningslöst. Koden kan vara uppdelad på flera filer, gömd bakom ett anrop till base64 eller gzinflate, inskriven i databasens tabell över inställningar eller placerad i samma mapp mu-plugins som adminpanelen inte visar. En sökning efter mönster hittar det du redan känner igen; ett fullständigt utbyte befriar dig också från det du inte känner igen.

Det finns också arbete vi inte utför i det här skedet: vi förlitar oss inte på ett tillägg som erbjuder sig att ”laga” infekterade filer med ett klick, eftersom det arbetar mot samma lista över kända mönster och dessutom i samma miljö som angriparen fortfarande har åtkomst till. Vi jämför inte heller filer för hand när webbplatsen har omfånget av ett vanligt visitkort eller en blogg, för en färsk installation med innehållet överflyttat kräver färre timmar än att jämföra två kataloger rad för rad, och resultatet går att kontrollera. En noggrann manuell jämförelse hör hemma där temat eller ett tillägg är unikt och versionshantering saknas; hur du hanterar säkerhetskopior för att det valet över huvud taget ska finnas har vi beskrivit i den allmänna återställningsguiden.

Nycklar, sessioner och lösenord: vad var och en faktiskt gör

Autentiseringsnycklarna och saltet i wp-config.php krypterar ingenting, vad än nästan varenda guide påstår: WordPress använder dem som grund för nyckeln som funktionen wp_generate_auth_cookie() signerar autentiseringskakan med, med HMAC-SHA256, medan kakan i sig är klartext med användarnamn, giltighetstid och en sessionstoken (WordPress Developer Resources, läst den 5 augusti 2026). Byter du de värdena blir därför varje tidigare utfärdad signatur omöjlig att verifiera, och servern avvisar varenda kaka som delats ut fram till dess, även om sessionen formellt inte har gått ut.

Den praktiska följden är precis den som behövs vid ett intrång: den officiella WordPress-dokumentationen beskriver ett byte av nycklarna som sättet att kasta ut alla som fortfarande kan vara inloggade (WordPress.org, ”FAQ My site was hacked”, uppdaterad den 26 juli 2026), så håller angriparen en giltig session tar den slut i samma ögonblick. Tillsammans med sessionerna blir också alla utfärdade nonce-tokens ogiltiga, och därför avbryts påbörjade formulär och halvfärdiga kassasteg just då — tidpunkten för bytet väljer vi medvetet, inte slumpvis mitt på en arbetsdag.

Ett byte av nycklar och salt ändrar inte ett enda lösenord. WordPress bygger lösenordshashar med bcrypt och ett eget slumpmässigt salt för varje lösenord, utan koppling till konstanterna i wp-config.php (funktionen wp_hash_password(); bcrypt som standard sedan WordPress 6.8), så en angripare som kan administratörens lösenord eller hunnit skapa ett konto åt sig loggar helt enkelt in igen efter nyckelbytet. Lösenorden byts separat och allihop, även de som ingen förmodas känna till, och samtidigt går du igenom användarlistan på jakt efter konton som ingen i ditt team har skapat.

Listan över inloggningsuppgifter slutar inte med WordPress: i samma svep byts lösenordet till webbhotellets kontrollpanel, uppgifterna för FTP och SFTP, databasanvändarens lösenord tillsammans med motsvarande rad i wp-config.php, samt SSH-nycklarna, som inte byts som ett lösenord utan genereras på nytt, varvid den gamla publika nyckeln raderas ur serverns fil authorized_keys. Sist byts alla API-nycklar som ligger på webbplatsen — betalväxelns, e-posttjänstens, frakt- och bokföringsintegrationernas — eftersom de brukar bli orörda längst: ingen ser dem på någon skärm till vardags.

Utgå från att angriparen har en fullständig kopia av databasen, för det är det billigaste steget i hela angreppet: allt som har legat i den, inklusive kundernas e-postadresser, orderhistoriken, lösenordshasharna och nycklarna som skrivits in i tilläggens inställningar, ska betraktas som hamnat i främmande händer. Har något av de lösenorden använts någon annanstans är även den platsen komprometterad, och det är oftast här samtalet flyttar från webbplatsen till e-postkonton, bokföringssystemet och butikens betalkonto.

Ordningen är lika viktig som själva listan: nycklar och lösenord byts efter att bakdörrarna är borttagna, för annars läser angriparen de nya värdena rakt av i wp-config.php eller fångar helt enkelt upp nästa inloggning. Just den här raden — först en fullständig kopia, sedan orsaken, sedan saneringen och allra sist inloggningsuppgifterna — är där en återställning i egen regi oftast stannar av eller trasslar ihop sig, och därför tar vi det här skedet på oss själva och lämnar till sist en skriftlig rapport över vad som ändrades, när och varför.

Så får du bort Googles varning, och vad du gör därefter

Avsnittet ”Säkerhetsproblem” i Google Search Console är det enda stället där du kan se vad Google faktiskt har hittat på din webbplats: där anges typen av hot och ett urval av de drabbade sidorna, och av det följer också vad besökaren ser just nu. Typen av hot ändrar däremot inte vad besökaren ser: Chrome sorterar inte längre varningens rubrik efter om det handlar om nätfiske, skadlig programvara eller oönskad programvara, utan visar i samtliga fall samma helskärmsvarning — på svenska ”Farlig webbplats” — som helt enkelt inte släpper in någon på webbplatsen, medan den redan nämnda texten ”Denna webbplats kan ha blivit hackad” i sökresultatet bara är en rad bredvid länken som går att klicka sig förbi (Googles hjälpsida om farliga webbplatser i Chrome, kontrollerad i augusti 2026). De äldre rubrikerna som skilde sig åt efter typ av hot — ”Deceptive site ahead”, till exempel — använder Chrome inte längre, även om de fortfarande går att hitta i delar av Googles dokumentation. Den första blockerar, den andra varnar, och det avgör hur mycket tid du egentligen har.

Innan du trycker på ”Begär granskning” måste du vara säker på att webbplatsen verkligen är ren och inte bara ser ren ut i din egen webbläsare. Googles guide till hacket med maskerade nyckelord varnar uttryckligen för att angripare försöker ge intryck av att en sida redan är raderad eller lagad, och därför måste varje före detta skräpsida kontrolleras med URL-inspektionsverktyget, som visar Googlebots vy och inte din. Det andra steget som hoppas över oftast är ägarlistan: vid Japanese keyword hack lägger angriparen till sig själv som verifierad ägare i Search Console (Googles dokumentation på web.dev), och så länge det kontot står kvar på listan vet angriparen precis lika mycket om webbplatsens tillstånd som du.

Knappen du letar efter heter ”Begär granskning” och sitter i rapporten Säkerhetsproblem, inte i den begäran om omprövning som Google har reserverat för manuella åtgärder, och tre saker är värda att skriva in i begäran: vad som hittades, hur angriparen tog sig in och vad som konkret har gjorts för att stänga vägen. Någon tidsram lovar vi inte, eftersom Google inte gör det heller: dokumentationssidan om social manipulering skriver att en granskning kan ta flera dagar, medan hjälpsidan om säkerhetsproblem i Search Console anger ”allt från ett par dagar till ett par veckor” (båda kontrollerade i augusti 2026). Nämner någon bestämda 24 eller 72 timmar är det en siffra som inte finns i någon Google-källa.

Brådskan i det här steget kostar mer än väntan gör. I samma studie från Google och University of California, Berkeley fick 80 % av webbplatsägarna sin webbplats godkänd som ren redan vid första försöket, medan de återstående 20 % behövde flera försök, och mediantiden de lade på att kamma ut koden angriparen lämnat efter sig var en hel vecka. Uppgifterna är från 2014–2015 och ska läsas så, men aritmetiken har inte ändrats: en avslagen begäran betyder att varningen ligger kvar ännu en omgång, och andra gången är du inte längre den som söker för första gången.

När varningen är borta är arbetet ändå inte slut, för angriparens sidor ligger kvar i indexet, och de får inte omdirigeras till startsidan — de ska svara med 404 eller 410 så att Google plockar bort dem helt, medan borttagningsverktyget i Search Console bara gömmer dem en tid. Placeringarna kommer inte tillbaka med ett vred: sidorna måste indexeras om, och det sker i Googles takt och inte i din. Hur du använder loggfiler och säkerhetskopior i det här skedet, så att utgångsläget blir bättre nästa gång, har vi beskrivit i en separat guide om återställning av hackade webbplatser.

När du ska sluta göra det själv, och vad det kostar

En erfaren webbplatsägare gör en del av det som står här på egen hand, och det säger vi rakt ut även till dem som ringer oss med Search Console öppen och det skyldiga tillägget redan utpekat. Är infektionen en sönderskriven startsida, syns det i loggfilerna vilket tillägg som släppte in den, finns det inga främmande administratörer i användarlistan och finns det en kopia från i går som någon faktiskt en gång har återställt i en testmiljö, då köper åtta betalda timmar dig en lugnare natt, inte ett snabbare resultat.

Det finns fyra situationer där vi rekommenderar att du stannar, och den första är en ny infektion efter saneringen: hackas webbplatsen en andra gång är det ingen otur utan ett bevis på att vägen in fortfarande står öppen, och en tredje sanering i samma miljö kommer att kosta precis lika mycket som de två första. Den andra är minsta skugga av misstanke om kund- eller betalningsuppgifter, eftersom det vid sidan av det tekniska arbetet också uppstår skyldigheter mot tillsynsmyndigheten och tidsfrister som ingen god vilja i världen förlänger. Den tredje är en webbplats som företaget tjänar pengar på varje dag, och den fjärde är ren tidsbrist: en sanering är inte intellektuellt svår, men den är lång, enformig och förlåter inte en enda överhoppad fil.

Vår återställning av hackade webbplatser kostar 90 € per timme exkl. moms, med ett minimum på åtta arbetstimmar som betalas i förskott. Arbetet inleder vi normalt inom några timmar efter förfrågan, och hela processen från start till överlämning tar vanligtvis 8–72 timmar, där skillnaden mellan åtta och sjuttiotvå timmar nästan alltid ligger i hur djupt angriparen hann rota sig och hur gammal den senaste rena kopian är. Minimitiden är ingen marknadsföringssiffra: en fullständig kopia, jakten på orsaken i loggfilerna, saneringen och kontrollen ryms sällan på mindre.

Ordningen är densamma som beskrivits ovan, bara utan din helg i den. Innan vi rör något tar vi en fullständig kopia av filerna och databasen, så att incidenten över huvud taget går att utreda i efterhand, och först därefter isoleras webbplatsen; sedan saneras den från skadlig programvara och bakdörrar, databasen kontrolleras, inloggningsuppgifter och nycklar byts, orsaken till intrånget hittas och stängs, begäran om granskning lämnas in till Google och övervakningen sätts upp, och till sist får du en skriftlig rapport över vad som hände och vad som ändrades. Fungerar webbplatsen inte just nu, eller är du osäker på vad du ser, kan du beställa en akut kontroll av webbplatsen, så säger vi om det här alls är något att betala för.

I många fall är det rätta svaret ändå inte en återställning, utan det som kommer efter den: har en webbplats samlat på sig tjugo tillägg där ingen längre minns skälet till hälften av dem, ligger problemet i förvaltningen, och det löses av utveckling och förvaltning av WordPress-webbplatser, inte av ännu en saneringsomgång om ett halvår. Den billigaste timmen i hela den här historien är den som lagts i förväg: att radera ett oanvänt tillägg ur wp-content/plugins i stället för att avaktivera det, och en säkerhetskopia som någon en gång faktiskt har återställt i en testmiljö, kostar tillsammans mindre än en av våra arbetsdagar.