WordPress sikkerhet & ytelse, Komplett administratorguide 2025

Å drive et profesjonelt WordPress-nettsted er mer enn å skrive innhold. Det er kontinuerlig arbeid på tre pilarer: Sikkerhet, Synlighet (Analytikk/SEO) og Ytelse. Denne artikkelen bygger videre på en kurspresentasjon og sjekker hver anbefaling mot offisiell dokumentasjon: WordPress Advanced Administration Handbook, sikkerhetssiden på WordPress.org, serverkravene, OWASP og Googles egen dokumentasjon. Hver seksjon gir steg du kan ta i bruk i dag.

#WordPress sikkerhet uten dyre plugins

Mange tror dyre “Security Pro” plugins er nødvendige for å sikre WordPress. Det er en myte. De sterkeste beskyttelsene fungerer på servernivå, før en forespørsel i det hele tatt kjører PHP. En lagdelt tilnærming som starter i infrastrukturen og går opp mot applikasjonen, er mer pålitelig enn å stole på plugins alene.

#Oppdateringer, ubrukte plugins og nulled-temaer

Oppdateringer: Ifølge sikkerhetssiden på WordPress.org er det bare den nyeste WordPress-versjonen som har offisiell støtte; sikkerhetsteamet (over 50 eksperter, ifølge samme side) tilbakefører rettelser til eldre versjoner kun som en tjeneste. Herdingsveiledningen legger til to fakta: automatiske oppdateringer har eksistert siden WordPress 3.7, og detaljer om rettede sårbarheter blir som regel offentlige. En gammel versjon blir altså lettere å angripe for hver uke den står uoppdatert.

PHP: De offisielle kravene anbefaler PHP 8.3 eller nyere, MySQL 8.0 eller nyere (eller MariaDB 10.11 eller nyere) og HTTPS-støtte. WordPress kjører fortsatt på PHP 7.4 og MySQL 5.5.5, men begge har nådd slutten av levetiden, og siden advarer selv om at de kan utsette nettstedet for sårbarheter. Står serveren din fortsatt på PHP 7.x, er oppgraderingen første oppgave.

Temaer og plugins: Slett (ikke bare deaktiver) alt du ikke bruker. Hver fil på serveren er en mulig angrepsvei. Deaktiverte plugins kan fortsatt kjøres hvis en angriper ber om filene deres direkte, så full fjerning er det eneste trygge valget.

Kilde: Last aldri ned “Premium gratis” plugins fra torrenter (Nulled). En nulled-kopi er kode endret av en ukjent tredjepart, som du ikke kan revidere og som ikke får oppdateringer. Den offisielle veiledningen sier at WordPress bare skal lastes ned fra WordPress.org; for plugins og temaer er det tilsvarende den offisielle katalogen eller utviklerens egen side.

#Hvilke wp-config.php-innstillinger øker sikkerheten

Legg disse linjene i konfigurasjonsfilen for å blokkere typiske angrep:

// Blokker filredigering fra admin
define( 'DISALLOW_FILE_EDIT', true );

// Tving SSL for innlogging og panel
define( 'FORCE_SSL_ADMIN', true );

// Endre databaseprefiks (gjør dette KUN under installasjon!)
$table_prefix = 'wp_a1b2_'; // I stedet for standard wp_

DISALLOW_FILE_EDIT fjerner rettighetene edit_themes, edit_plugins og edit_files fra alle brukere. Herdingsveiledningen er tydelig på grensen: konstanten stopper ikke opplasting av skadelige filer, men stenger en vanlig vei etter at en administratorkonto er stjålet. Om prefikset forklarer samme veiledning at mange publiserte SQL-injeksjonsangrep forutsetter wp_, så et annet prefiks blokkerer i det minste en del av dem. Det erstatter ikke forberedte spørringer i koden.

#Slik deaktiverer du XML-RPC og begrenser revisjoner

// I wp-config.php: begrens revisjoner
define( 'WP_POST_REVISIONS', 5 );

// I en mu-plugin, ikke i wp-config.php
add_filter( 'xmlrpc_enabled', '__return_false' );
remove_action( 'wp_head', 'wp_generator' );

To rettelser til kodesnutter som sirkulerer på nettet. For det første finnes det ingen konstant XMLRPC_ENABLED i WordPress; det som finnes er filteret xmlrpc_enabled (siden versjon 3.5), og det deaktiverer bare metoder som krever autentisering. Pingbacks svarer fortsatt. Bruker du ikke XML-RPC, blokker xmlrpc.php på serveren, slik regelen under gjør. For det andre virker ikke remove_action() i wp-config.php, fordi WordPress-funksjonene ikke er lastet ennå på det tidspunktet; kallet hører hjemme i en plugin eller i wp-content/mu-plugins/.

#Slik blokkerer du sensitive filer med .htaccess

.htaccess filen (på Apache/LiteSpeed) er din første vokter. Sett opp regler som blokkerer tilgang til sensitive filer før noe PHP-kode kjører.

Blokker tilgang til sensitive filer (syntaks for Apache 2.4, slik den offisielle veiledningen bruker):

<FilesMatch "(^\.|wp-config\.php|xmlrpc\.php)">
Require all denied
</FilesMatch>

Direktivene Order deny,allow og Deny from all hører til Apache 2.2; på Apache 2.4 fungerer de bare via kompatibilitetsmodulen mod_access_compat. Blokker xmlrpc.php bare hvis ingenting bruker den: WordPress-appen eller Jetpack kan være avhengig av den.

Begrens wp-login.php etter IP, hvis du jobber fra faste adresser. Dette er eksempelet fra den offisielle veiledningen mot brute force, med dokumentasjonsadresser du bytter ut med dine egne:

<Files "wp-login.php">
Require ip 203.0.113.15 203.0.113.16
</Files>

#Hvilke filrettigheter WordPress trenger

Herdingsveiledningen gir konkrete verdier: mapper på 755 og filer på 644, som også er det automatiske oppdateringer setter. Rotmappen, wp-admin/, wp-includes/ og wp-content/plugins/ skal bare være skrivbare for brukerkontoen din; wp-content/ i tillegg for webserveren. For wp-config.php anbefales 440 eller 400, slik at bare eieren og webserveren kan lese den. Veiledningen nevner også muligheten for å flytte filen én mappe over installasjonen, med forbeholdet at noen eksperter mener gevinsten er liten.

find /sti/til/wordpress/ -type d -exec chmod 755 {} \;
find /sti/til/wordpress/ -type f -exec chmod 644 {} \;
chmod 440 /sti/til/wordpress/wp-config.php

Samme prinsipp gjelder databasen: vanlig drift trenger bare SELECT, INSERT, UPDATE og DELETE, men veiledningen fraråder å fjerne ALTER eller DROP, fordi oppdateringer og enkelte plugins endrer skjemaet. En egen databasebruker per nettsted koster derimot ingenting.

#HTTP-sikkerhetshoder i .htaccess

Legg til hoder som beskytter mot vanlige angrep som clickjacking og MIME-sniffing. Verdiene følger OWASP HTTP Headers Cheat Sheet:

# Sikkerhetshoder
Header set X-Content-Type-Options "nosniff"
Header set X-Frame-Options "SAMEORIGIN"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set Permissions-Policy "geolocation=(), camera=(), microphone=()"
Header set X-XSS-Protection "0"
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
Header unset X-Powered-By

Mange eldre guider anbefaler X-XSS-Protection: 1; mode=block. OWASP sier det motsatte: ikke send hodet, eller sett det til 0, fordi nettleserfilteret det slo på kunne skape XSS-problemer på ellers trygge sider. Ekte vern mot XSS er en Content Security Policy som ikke tillater innebygd JavaScript. OWASP foretrekker DENY eller CSP-direktivet frame-ancestors framfor X-Frame-Options; SAMEORIGIN er det vanlige kompromisset i WordPress fordi Customizer laster nettstedet i en iframe fra samme domene. Vær forsiktig med HSTS: et utløpt sertifikat stenger besøkende ute i hele max-age-perioden, så slå det på først når HTTPS virker på alle underdomener.

#Tofaktorautentisering (2FA) i WordPress

Slå på 2FA for alle administratorkontoer. Den offisielle veiledningen mot brute force sier det rett ut: WordPress-kjernen leveres ikke med 2FA, så du trenger en pålitelig plugin eller identitetsleverandør. Plugins som Two Factor (vedlikeholdt av WordPress-bidragsytere), WP 2FA eller Google Authenticator gir denne funksjonen. Samme veiledning legger til tre tiltak: ikke bruk brukernavnet admin, bruk lange og unike passord med passordbehandler, og begrens antall forespørsler mot wp-login.php og xmlrpc.php i kanten av nettet (WAF eller CDN) eller i webserveren, fordi en sikkerhetsplugin fortsatt bruker PHP-ressurser under et stort angrep.

#Slik tar du sikkerhetskopi av WordPress

Den offisielle veiledningen for sikkerhetskopi deler jobben i to deler som hører sammen: databasen (innlegg, kommentarer, innstillinger) og filene (kjerne, plugins, temaer, opplastinger). En kopi av bare databasen gjenoppretter ikke nettstedet. Anbefalt hyppighet: ukentlig for små nettsteder, daglig for nettsteder med mye aktivitet, og alltid før en oppgradering. Behold 3 til 5 nylige kopier på ulike steder og ulike medier. Ved gjenoppretting legger du tilbake filene først og importerer databasen etterpå; har tilgangsdataene endret seg, oppdaterer du wp-config.php. Herdingsveiledningen legger til at kopiene bør krypteres, med uavhengige hasher lagret for å bevise at ingen har endret dem.

#Hvilke OWASP Top 10 2025 risikoer gjelder WordPress

Sikkerhetssiden på WordPress.org sier at sikkerhetsteamet herder kjernen mot trusler som OWASP Top Ten. Utgaven fra 2025 fungerer godt som sjekkliste for en administrator, fordi flere kategorier handler om valg i kontrollpanelet eller på serveren, ikke i kjernekoden:

Om logger forklarer herdingsveiledningen at serverlogger viser IP, tidspunkt og handling, og avslører forsøk på XSS, filinkludering, katalogtraversering og brute force. Den anbefaler verktøy som OSSEC og å filtrere bort støy, slik at viktige varsler ikke drukner.

#Google Search Console og GA4 for WordPress

Du kan ikke administrere det du ikke måler. Google Search Console (GSC) og Google Analytics 4 (GA4) er bedriftens øyne og ører.

#Hva du bør sjekke i Google Search Console hver uke

Det eneste stedet Google “snakker” med deg om siden din. For enhver WordPress-administrator som bryr seg om synlighet i søk, er det det viktigste verktøyet.

1. Sitemap: Sørg for at du har sendt inn sitemap-et ditt (vanligvis domene.no/sitemap_index.xml, generert av SEO-pluginen). Sjekk at alle viktige URL-er er med og at det ikke finnes behandlingsfeil.
2. Indekseringsfeil: Sjekk “Sider”-seksjonen ukentlig. Se etter 404 og 5xx feil. En 404 på en URL som får lenker eller trafikk er et tapt besøk; en gjentatt 5xx peker mot et serverproblem.
3. Core Web Vitals: GSC vil fortelle deg direkte om siden laster raskt nok (LCP), svarer på interaksjoner i tide (INP) og er visuelt stabil (CLS). Følg med på feltdata fra ekte brukere, for det er dem rapporten teller.

#Hvilke grenseverdier for Core Web Vitals en side må oppfylle

Ifølge web.dev har en side gode Core Web Vitals når den oppfyller alle tre grenseverdiene ved 75-persentilen av sidelastinger, målt hver for seg på mobil og datamaskin:

75-persentilen betyr at de fleste besøk må nå grenseverdien, ikke bare gjennomsnittet. Derfor gir ikke en rask labtest fra ditt eget kontor noen garanti for en grønn rapport i GSC.

#Slik setter du opp nøkkelhendelser i GA4

GA4 er forskjellig fra gamle UA. Den fokuserer på hendelser i stedet for sidevisninger, og det endrer hvordan du måler om et nettsted lykkes.

• Ikke bare mål “besøk”. Konfigurer nøkkelhendelser: skjemainnsending, telefonklikk, PDF-nedlasting. Google har gitt begrepet nytt navn: det som før het konverteringer i GA4, heter nå nøkkelhendelser, og “konvertering” er forbeholdt måling knyttet til Google Ads.
• Husk GDPR. Consent Mode v2 sender besøkendes samtykkevalg videre til Google-taggene. Ifølge Googles dokumentasjon legger versjon 2 til parameterne ad_user_data og ad_personalization ved siden av de eksisterende ad_storage og analytics_storage. Consent Mode erstatter ikke samtykkebanneret eller det rettslige grunnlaget, den sørger bare for at taggene respekterer brukerens valg.
• Legg inn egne hendelser for dine forretningsmål: tilbudsforespørsler, nyhetsbrevpåmeldinger, WhatsApp-klikk, timebestillinger.

#Gjør WordPress raskere med hosting og caching

En rask side gir bedre brukeropplevelse og bedre Core Web Vitals, som Google måler i GSC-rapporten beskrevet over.

#Hvilken hosting trenger en rask WordPress-side

Du kan ikke optimalisere en side på hosting til 50kr/år. Den offisielle optimaliseringsveiledningen peker på at en server med SSD- eller NVMe-disker, mer CPU og mer minne kan utgjøre en stor forskjell. Se etter hosting med:

• NVMe-disker for rask database-I/O.
• Redis/Memcached støtte (database i RAM) for object caching.
• LiteSpeed (LSCache) eller Nginx server for effektiv håndtering av forespørsler.

Samme veiledning gir to råd som ofte glemmes: ikke kjør DNS eller e-postserver på WordPress-serveren. Til kontaktskjemaer bruker du en skjemaplugin med en ekstern utsendingstjeneste.

#Slik optimaliserer du bilder i WordPress

Bilder er som regel de tyngste ressursene på en side, og LCP-elementet er ofte et bilde.

• Lazy Loading: WordPress gjør dette som standard siden versjon 5.5, men optimaliseringsplugins gir mer kontroll over iframes og video. Ikke bruk lazy loading på hovedbildet som vises ved lasting, for det forsinker LCP.
• Formater: Bruk WebP eller AVIF. Ifølge Google er tapsbasert WebP 25 til 34 % mindre enn en sammenlignbar JPEG ved lik SSIM-kvalitet, og tapsfri WebP 26 % mindre enn PNG.
• Dimensjoner: Ikke last opp bilder på 4000px til en blogg der tekstbredden er 800px. Skaler ned før opplasting.

#Sidecache og objektcache (Redis) i WordPress

Siden din skal ikke generere PHP for hver besøkende. Bruk caching på flere nivåer:

• Page Cache: Lagrer ferdig HTML på serverdisken for umiddelbare svar. Den offisielle optimaliseringsveiledningen sier at caching av sider som statiske filer kan gjøre ganske statiske sider flere hundre ganger raskere.
• Object Cache (Redis): Holder resultater fra databasespørringer i minnet. Avgjørende for WooCommerce og store sider der de samme spørringene gjentas hele tiden.
• OPcache: Holder kompilert PHP-kode i minnet; den offisielle veiledningen nevner den som en akselerator som gjør alle PHP-filer raskere, ikke bare WordPress.
• Nettleserbuffer: Sett utløpshoder slik at nettlesere lagrer statiske filer lokalt.

#CDN og edge computing for WordPress

For nettsteder med internasjonalt publikum speiler et CDN som Cloudflare bilder og andre statiske filer på servere nær hver bruker; den offisielle veiledningen beskriver det som svaret på geografisk avstand mellom server og besøkende. Edge computing går et steg videre og kjører serverlogikk nær brukeren for å kutte ventetid. Et CDN med WAF er også rett sted for å begrense forespørsler mot wp-login.php.

#Slik finner du hvilken plugin som gjør WordPress treg

Den offisielle optimaliseringsveiledningen foreslår en enkel metode: deaktiver plugins én etter én og mål serverytelsen etter hver endring. Hvis én av dem veier tungt, les dokumentasjonen, spør i supportforumet eller finn et alternativ med lignende funksjoner. Utviklerverktøyene i Firefox eller Chrome har ytelsespaneler som holder til en første måling. For databasen anbefaler samme veiledning InnoDB, standardmotoren i MySQL, og å konvertere gamle MyISAM-tabeller.

#Løpende overvåking av ytelse

Sett opp ytelsesovervåking med verktøy som DebugBear eller SpeedCurve. De oppdager ytelsesregresjoner automatisk, slik at du kan handle før brukerne merker noe.

#Hvor ofte bør du vedlikeholde WordPress

Å ta vare på et WordPress-nettsted er en prosess, ikke en engangshandling. Sett opp en fast plan:

• Daglig: Sjekk backups (automatisk) på nettsteder med mye aktivitet og følg med på sikkerhetsvarsler.
• Ukentlig: Oppdater plugins, sjekk GSC, les feillogger og ta den ukentlige sikkerhetskopien på små nettsteder.
• Månedlig: Gjør hastighetsaudit, brukergjennomgang (har noen uten tillatelse admin-tilgang?) og databaseopprydding.
• Kvartalsvis: Full sikkerhetsrevisjon, gjennomgang av installerte plugins, testgjenoppretting av én kopi og oppdatering av beredskapsplanen.

Sikkerhet og ytelse er ikke prosjekter med sluttdato, men løpende prosesser.