WordPress etter installasjon: sjekkliste med 50 punkter for 2026

Mariusz Szatkowski

Sist verifisert: 13. oktober 2026

21 min lesetid

Guide

500+ WP-prosjekter

Sikkerhetsrevisor

Den “berømte 5-minuttersinstallasjonen” er et markedsføringsslagord, ikke en profesjonell standard. En standardinstallasjon av WordPress er “pratsom”, uoptimalisert og ofte usikker.

Som utviklere “installerer” vi ikke bare WordPress. Vi gjør det klart til å kjøre i et bestemt miljø. Denne guiden dekker de viktigste konfigurasjonskonstantene og herdingsteknikkene som bør inngå i grunnoppsettet for hvert kundeprosjekt i 2026.

#Konfigurere wp-config.php etter at WordPress er installert

Dette er hjernen i installasjonen din. Slutt å la den stå på standardinnstillingene.

#Sette WP_ENVIRONMENT_TYPE i wp-config.php

Fra WordPress 5.5 er WP_ENVIRONMENT_TYPE standard. Bruk den for å hindre at utviklingsfeil lekker ut i produksjon.

// I wp-config.php
define( 'WP_ENVIRONMENT_TYPE', 'production' ); // 'local', 'development', 'staging', 'production'

Deretter i koden din:

if ( wp_get_environment_type() === 'production' ) {
    // Slå på hurtigbuffer, slå av feilmeldinger
}

#Slå av filredigering og tvinge SSL i wp-config.php

Hindre at kunder (eller angripere) ødelegger nettstedet via administrasjonspanelet.

// Slå av filredigereren (tema-/utvidelsesredigerer)
define( 'DISALLOW_FILE_EDIT', true );

// Blokker installasjon/oppdatering av utvidelser (bra for uforanderlige utrullinger)
define( 'DISALLOW_FILE_MODS', true );

// Tving SSL i admin
define( 'FORCE_SSL_ADMIN', true );

#Slik begrenser du innleggsrevisjoner i WordPress

Databasedreperen. Trenger du virkelig 100 versjoner av “Om oss”-siden?

define( 'WP_POST_REVISIONS', 10 ); // Behold de siste 10
// ELLER
define( 'WP_POST_REVISIONS', false ); // Slå av helt (anbefales ikke)

#Slik slår du på WP_DEBUG_LOG uten å vise feil

Vis aldri feil i frontend. Logg dem.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/tmp/wp-errors.log' ); // Flytt loggen ut av den offentlige katalogen!
define( 'WP_DEBUG_DISPLAY', false );

// Logg SQL-spørringer for ytelsesfeilsøking (slå av i produksjon!)
define( 'SAVEQUERIES', false );

#Slik slår du av emoji og XML-RPC i WordPress

WordPress leveres med funksjoner som 90% av bedriftsnettsteder ikke trenger: emoji, oEmbeds og XML-RPC.

Ikke installer en utvidelse for å slå dem av. Lag en must-use-utvidelse (wp-content/mu-plugins/lean-core.php).

<?php
/* Plugin Name: Lean Core */

// 1. Slå av emoji (sparer en HTTP-forespørsel)
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );

// 2. Slå av XML-RPC (sikkerhet)
add_filter( 'xmlrpc_enabled', '__return_false' );

// 3. Fjern WP-versjonen (security by obscurity)
remove_action( 'wp_head', 'wp_generator' );

// 4. Slå av RSS-strømmer (hvis du bygger et enkelt bedriftsnettsted)
// function wppoland_disable_feed() {
//    wp_die( 'Ingen strøm her, besøk forsiden vår!' );
// }
// add_action('do_feed', 'wppoland_disable_feed', 1);

Til tross for navnet slår filteret xmlrpc_enabled i punkt 2 bare av XML-RPC-metoder som krever autentisering, for eksempel publisering. Pingbacks og andre metoder uten autentisering svarer fortsatt på xmlrpc.php. Å blokkere hele filen hører hjemme på webserveren, og bare hvis ingenting bruker den: Jetpack kobler for eksempel til via XML-RPC.

#Bytte salt-nøklene i wp-config.php

Du kjenner autentiseringsnøklene i wp-config.php.

define('AUTH_KEY',         'skriv inn din unike frase her');
// ...

Fakta: Når du endrer dem, logges alle brukere ut umiddelbart. Det er “atomknappen” hvis nettstedet er hacket. Profftips: Automatiser rotasjonen med et CLI-skript eller Vault hvis du drifter enterprise-nettsteder.

#Hva du bør sette i wp-config.php før nettstedet lanseres

Før lansering:

Sett WP_ENVIRONMENT_TYPE til production.
Sett DISALLOW_FILE_EDIT til true.
Begrens WP_POST_REVISIONS.
Flytt WP_DEBUG_LOG til en privat mappe.
Slå av emoji/XML-RPC i kode.

En godt konfigurert WordPress-instans er stille, sikker og rask.

#Hvilke permalenker du bør velge i WordPress

#Optimal permalenkestruktur

Innstillinger > Permalenker > Innleggsnavn

Hvorfor:

Kortere og mer lesbare URL-er
Bedre for SEO (søkeord i URL-en)
Lettere å huske og dele

En fersk installasjon har ofte lesbare permalenker allerede. Når serveren støtter URL-omskriving, setter installasjonsprogrammet /%year%/%monthnum%/%day%/%postname%/ (kjernefunksjonen wp_install_maybe_enable_pretty_permalinks()). Bytt til Innleggsnavn før det første innlegget publiseres: å endre strukturen på et nettsted i drift endrer adressen til hvert innlegg, og de gamle adressene trenger da omdirigeringer.

#Struktur for kategorier og stikkord

Opprett grunnleggende kategorier (3-7 hovedkategorier)
Definer hierarkiet (over- og underkategorier)
Velg en standardkategori (ikke “Ukategorisert”)
Planlegg en stikkordstrategi (valgfritt, 5-10 stikkord per innlegg)

#Medieinnstillinger og bildestørrelser i WordPress

#Bildestørrelser

Innstillinger > Media

Anbefalte innstillinger:

Miniatyrbilde: 150x150px (huk av for å beskjære miniatyrbildet til nøyaktige mål)
Middels: 300x300px
Stor: 1024x1024px
Full størrelse: alltid tilgjengelig

#Automatisk bildeoptimalisering

<?php
/* Plugin Name: Image Sizes */

add_action( 'init', function () {
    remove_image_size( '1536x1536' ); // WordPress 5.3+
    remove_image_size( '2048x2048' ); // WordPress 5.3+
} );

To linjer som er vanlige i kopier av denne kodebiten, er utelatt med vilje. wp_lazy_loading_enabled returnerer allerede true som standard (innebygd loading="lazy" siden WordPress 5.5), og filteret wp_image_editors bestemmer bare rekkefølgen WordPress prøver Imagick og GD i, som uansett er standardrekkefølgen. Ingen av dem optimaliserer noe ved opplasting. Bilder som er bredere eller høyere enn 2560 px, skaleres allerede ned ved opplasting gjennom filteret big_image_size_threshold.

#Slik slår du på WebP-opplasting i WordPress

add_filter( 'image_editor_output_format', function ( $formats ) {
    $formats['image/jpeg'] = 'image/webp';
    $formats['image/png']  = 'image/webp';
    return $formats;
} );

Kodebiten bruker ikke wp_upload_image_mime_transforms, et filter som ikke finnes i dagens WordPress-kjerne. image_editor_output_format har eksistert siden WordPress 5.8 og knytter en kildetype til typen WordPress lagrer genererte størrelser i; siden 6.7 gjør standardverdien allerede HEIC og HEIF om til JPEG, og kodebiten beholder de oppføringene. Imagick eller GD på serveren må støtte WebP. Verktøy > Nettstedshelse > Info > Mediehåndtering viser hva som støttes.

#Slik sikrer du WordPress etter installasjon

#Endre standard tabellprefiks

Under installasjonen: Skriv inn et eget prefiks i stedet for wp_ (for eksempel x7k9_, mysite_, proj23_)

Etter installasjonen (avansert):

// wp-config.php
$table_prefix = 'x7k9_';

RENAME TABLE wp_posts TO x7k9_posts;
RENAME TABLE wp_options TO x7k9_options;
-- ... gjenta for alle tabeller

UPDATE x7k9_options SET option_name = 'x7k9_user_roles' WHERE option_name = 'wp_user_roles';
UPDATE x7k9_usermeta SET meta_key = CONCAT('x7k9_', SUBSTRING(meta_key, 4)) WHERE meta_key LIKE 'wp\_%';

WordPress har ingen konstant DB_PREFIX: prefikset ligger i variabelen $table_prefix. Å gi nytt navn bare til tabellene stenger administratorene ute, fordi roller og rettigheter lagres under nøkler med prefiks i options (wp_user_roles) og usermeta (wp_capabilities, wp_user_level). Det er dette de to UPDATE-setningene retter. Veiledningen Hardening WordPress behandler et eget prefiks som tilsløring: det kan stoppe noen automatiserte SQL-injeksjonsangrep som forutsetter wp_, og erstatter ikke å rette sårbar kode.

#Beskytte filen wp-config.php

# .htaccess (rotkatalogen, helt øverst i filen)
<Files "wp-config.php">
Require all denied
</Files>

Order allow,deny er syntaks fra Apache 2.2 og virker på Apache 2.4 bare gjennom kompatibilitetsmodulen. Veiledningen Hardening WordPress oppgir formen Require all denied over og setter den helt øverst i .htaccess i rotkatalogen. Nginx ignorerer .htaccess-filer, så på Nginx hører samme regel hjemme i server-blokken.

#Blokkere tilgang til kataloger

# wp-content/uploads/.htaccess
Options -Indexes

# .htaccess (rotkatalogen, utenfor # BEGIN WordPress og # END WordPress)
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>

WordPress skriver om alt mellom markørene # BEGIN WordPress og # END WordPress hver gang permalenkene lagres, så denne blokken står utenfor dem, i .htaccess i rotkatalogen og ikke i wp-includes/: stiene i reglene er relative til nettstedets rot. På multisite hindrer linjen ^wp-includes/[^/]+\.php$ ms-files.php i å levere bilder, og veiledningen Hardening WordPress sier at linjen skal tas bort der, på bekostning av noe beskyttelse.

#Begrense påloggingsforsøk

<?php
/* Plugin Name: Login Security */

function wppoland_login_key() {
    return 'login_attempts_' . md5( $_SERVER['REMOTE_ADDR'] );
}

add_filter( 'authenticate', function ( $user ) {
    if ( (int) get_transient( wppoland_login_key() ) >= 5 ) {
        return new WP_Error( 'too_many_attempts', 'For mange påloggingsforsøk. Prøv igjen om en time.' );
    }
    return $user;
}, 30 );

add_action( 'wp_login_failed', function () {
    $key = wppoland_login_key();
    set_transient( $key, (int) get_transient( $key ) + 1, HOUR_IN_SECONDS );
} );

remove_action( 'wp_head', 'wp_generator' );
add_filter( 'the_generator', '__return_empty_string' );

Å telle mislykkede forsøk i wp_login_failed og kalle wp_die() der virker ikke. Den hooken kjører etter passordsjekken, så et riktig passord logget fortsatt inn etter fem feil. Filteret authenticate med prioritet 30 kjører etter at kjernen har sjekket brukernavn og passord, og en WP_Error som returneres der, stopper påloggingen. Bak en CDN eller omvendt proxy inneholder REMOTE_ADDR adressen til proxyen, og alle besøkende ville dele én teller: i slike oppsett begrenser du pålogginger i proxyen eller med fail2ban på serveren.

#Tofaktorautentisering (2FA)

WordPress-kjernen har ingen andre faktor. Utvidelsen Two Factor, publisert på WordPress.org under kontoen WordPress.org, legger til autentiseringsapper (TOTP), koder på e-post og reservekoder, og hver bruker slår den på i sin egen profil. Veiledningen Hardening WordPress anbefaler totrinnsautentisering som et ekstra lag i tillegg til passordet. Kodebiten under gjør noe mindre: den avviser passord kortere enn 12 tegn når en profil lagres.

// Krev sterke passord
add_action('user_profile_update_errors', function($errors) {
    $password = $_POST['pass1'];
    if (!empty($password) && strlen($password) < 12) {
        $errors->add('password_error', 'Passordet må ha minst 12 tegn.');
    }
});

#Slik gjør du WordPress raskere etter installasjon

#Grunnleggende databaseoptimalisering

// I wp-config.php
// Begrens innleggsrevisjoner
define('WP_POST_REVISIONS', 10);

// Tøm papirkurven automatisk etter 7 dager
define('EMPTY_TRASH_DAYS', 7);

// Slå av filredigereren (sikkerhet + ytelse)
define('DISALLOW_FILE_EDIT', true);

#Rydde i databasen

wp transient delete --expired
wp post list --post_type=revision --format=count
wp db optimize

Den fjernede mu-utvidelsen slettet transienter ved å sammenligne option_value med nåværende tid, men utløpstiden ligger i egne _transient_timeout_-rader, så den slettet feil rader. Kjernen gjør allerede denne jobben: wp-admin/admin.php planlegger en daglig hendelse delete_expired_transients (hoppes over når en vedvarende objekthurtigbuffer holder transientene), og en daglig hendelse wp_scheduled_auto_draft_delete fjerner automatiske utkast eldre enn sju dager. Med WP_POST_REVISIONS satt trenger heller ikke revisjoner en slette-cron. Kjør WP-CLI-kommandoene over for hånd når en database ser oppblåst ut.

#Optimalisere Heartbeat API

add_filter( 'heartbeat_settings', function ( $settings ) {
    $settings['interval'] = 120; // standard: 60
    return $settings;
} );

add_action( 'init', function () {
    if ( ! is_admin() ) {
        wp_deregister_script( 'heartbeat' );
    }
}, 1 );

Standardintervallet for Heartbeat er 60 sekunder (mainInterval i heartbeat.js), ikke 15, så den tidligere verdien 60 endret ingenting. Heartbeat senker seg også selv til 120 sekunder når nettleserfanen er skjult. I redigeringsverktøyet bærer den innleggslåser, så et lengre intervall forsinker varselet om at noen andre redigerer samme innlegg.

#Fjerne RSD-, kortlenke- og REST API-lenker fra wp_head

// I mu-plugin: wp-content/mu-plugins/disable-bloat.php
<?php
/* Plugin Name: Disable Bloat */

// Slå av emoji
remove_action('wp_head', 'print_emoji_detection_script', 7);
remove_action('wp_print_styles', 'print_emoji_styles');

// Slå av XML-RPC
add_filter('xmlrpc_enabled', '__return_false');

// Slå av RSD-lenken
remove_action('wp_head', 'rsd_link');

// Slå av Windows Live Writer-lenken
remove_action('wp_head', 'wlwmanifest_link');

// Slå av kortlenken
remove_action('wp_head', 'wp_shortlink_wp_head');

// Slå av REST API-lenken (hvis du ikke bruker den)
remove_action('wp_head', 'rest_output_link_wp_head');

#Grunnleggende SEO-innstillinger i WordPress

#Nettstedstittel, slagord og synlighet for søkemotorer

Innstillinger > Generelt:
- Nettstedstittel: [Ditt merkenavn]
- Slagord: én kort setning, eller tomt

Innstillinger > Lesing:
- Synlighet for søkemotorer: la "Be søkemotorer om ikke å indeksere dette nettstedet" være UAVKRYSSET

Kjernen skriver ikke ut noen metabeskrivelse, så slagordet er ikke en. På nye installasjoner starter feltet tomt, og temaer kan vise det i toppteksten eller i tittelen. Metabeskrivelsen kommer fra en SEO-utvidelse eller fra temaet. Avkrysningsboksen for synlighet for søkemotorer ligger under Lesing, ikke Generelt, og mens den er krysset av, slår WordPress også av sitt eget nettstedskart.

#SEO-vennlig permalenkestruktur

Innstillinger > Permalenker > Innleggsnavn

#XML-nettstedskart

add_filter( 'wp_sitemaps_post_types', function ( $post_types ) {
    unset( $post_types['portfolio'] ); // fjerne en innholdstype fra nettstedskartet
    return $post_types;
} );

Kjernens nettstedskart på /wp-sitemap.xml har vært på som standard siden WordPress 5.5, så lenge nettstedet er synlig for søkemotorer. Det tar med alle offentlige innholdstyper, også egne, så den gamle linjen $post_types[] = 'portfolio' var unødvendig og i tillegg feil: matrisen inneholder WP_Post_Type-objekter med navnet som nøkkel. Filteret er nyttig den andre veien, for å ta en type ut av nettstedskartet.

#Grunnleggende bildeoptimalisering for SEO

En vanlig kodebit fyller tomme ALT-attributter med vedleggets tittel og lager titler fra filnavn. Det siste gjør kjernen allerede: media_handle_upload() henter vedleggets tittel fra filnavnet. Det første gir ALT-tekster som “IMG_2041”, som en skjermleser leser opp og som ikke sier noe om bildet. Skriv ALT-teksten per bilde i mediebiblioteket, og la den stå tom for rent dekorative bilder.

#Slik tar du sikkerhetskopi av WordPress

#Automatiske kopier av databasen

# crontab -e (nettstedets bruker, ikke root)
15 3 * * * cd /var/www/example/public && wp db export /home/example/backups/db-$(date +\%F).sql --quiet && find /home/example/backups -name 'db-*.sql' -mtime +7 -delete

Den tidligere mu-utvidelsen skrev dumper til wp-content/uploads/backups, en offentlig mappe der alle som gjetter det datobaserte filnavnet, kan laste ned databasen. Den sendte også databasepassordet på kommandolinjen til mysqldump, der andre brukere på serveren ser det i prosesslisten, og den var avhengig av WP-Cron, som bare kjører når noen besøker nettstedet. En system-cronjobb med wp db export skriver utenfor webroten og kjører til riktig tid.

#Sette opp eksterne kopier

Anbefalte løsninger:

UpdraftPlus: gratisversjonen holder for små nettsteder
BlogVault: betalt, men svært pålitelig
WPvivid: et godt gratis alternativ

Konfigurasjon:

Daglig kopi (database)
Ukentlig kopi (fullstendig)
Oppbevaring: minst 30 dager
Ekstern plassering: Google Drive, Dropbox, S3

#Konfigurere SMTP i WordPress

#SMTP i stedet for mail()

// I wp-config.php eller en mu-plugin
define('SMTP_USER', '[email protected]');
define('SMTP_PASS', 'your-password');
define('SMTP_HOST', 'smtp.gmail.com');
define('SMTP_PORT', '587');
define('SMTP_SECURE', 'tls');
define('SMTP_FROM', '[email protected]');
define('SMTP_NAME', 'Ditt nettsted');

// I mu-plugin
add_action('phpmailer_init', function($phpmailer) {
    $phpmailer->isSMTP();
    $phpmailer->Host = SMTP_HOST;
    $phpmailer->SMTPAuth = true;
    $phpmailer->Username = SMTP_USER;
    $phpmailer->Password = SMTP_PASS;
    $phpmailer->SMTPSecure = SMTP_SECURE;
    $phpmailer->Port = SMTP_PORT;
    $phpmailer->From = SMTP_FROM;
    $phpmailer->FromName = SMTP_NAME;
});

#Slik sender du en test-e-post fra WordPress

add_action( 'admin_init', function () {
    if ( isset( $_GET['test_email'] ) && current_user_can( 'manage_options' ) ) {
        $sent = wp_mail( get_option( 'admin_email' ), 'Test email', 'Dette er en testmelding sendt fra WordPress.' );
        wp_die( $sent ? 'OK' : 'wp_mail() returned false' );
    }
} );

admin_init utløses også ved forespørsler til admin-ajax.php fra besøkende som ikke er logget inn, så uten rettighetssjekken kunne hvem som helst få nettstedet til å sende e-post. Med WP-CLI er samme test én linje: wp eval 'var_dump( wp_mail( get_option( "admin_email" ), "Test", "Test" ) );'.

#Overvåking av WordPress og feillogging

#Feillogging

// I wp-config.php
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', '/var/log/wp-errors.log'); // Utenfor den offentlige katalogen
define('WP_DEBUG_DISPLAY', false);

// Logging av SQL-spørringer (bare i feilsøkingsmodus)
// define('SAVEQUERIES', true);

#Oppetidsovervåking

Anbefalte verktøy:

UptimeRobot
Pingdom (betalt, men mer avansert)
Better Uptime (moderne alternativ)

#Logge administratorinnlogginger og innleggsendringer

// I mu-plugin: wp-content/mu-plugins/activity-log.php
<?php
/* Plugin Name: Activity Log */

add_action('wp_login', function($user_login, $user) {
    error_log('User logged in: ' . $user_login . ' from IP: ' . $_SERVER['REMOTE_ADDR']);
}, 10, 2);

add_action('save_post', function($post_id, $post, $update) {
    if ($update && $post->post_status === 'publish') {
        error_log('Post updated: ' . $post->post_title . ' by user: ' . get_current_user_id());
    }
}, 10, 3);

#Hva du bør sjekke før du lanserer et WordPress-nettsted

#Sjekkliste før lansering

#Teste sjekksummer og filtilgang med WP-CLI og curl

# WP-CLI-tester
wp core verify-checksums
wp plugin verify-checksums --all
wp db check

# Sikkerhetstester
curl -I https://ditt-nettsted.no/wp-admin/install.php # gir siden "Allerede installert" med mindre serveren blokkerer den
curl -I https://ditt-nettsted.no/wp-config.php # 403 med <Files>-regelen; uten den en tom side

#Hvilke WordPress-innstillinger du bør endre etter installasjon

Tre skjermbilder under Innstillinger har standardverdier som betyr noe før den første besøkende kommer. Dokumentasjonen for skjermbildet Generelt beskriver hvert felt.

Generelt. Velg tidssonen som en by, ikke som en UTC-forskyvning. En by følger sommertid, en fast forskyvning gjør det ikke, og planlagte innlegg publiseres da en time feil halve året. Nettstedsspråket du setter her, er språket i kontrollpanelet. En ny e-postadresse for administrasjon gjelder ikke med en gang: WordPress sender en bekreftelseslenke til den nye adressen og holder den gamle aktiv til lenken klikkes, så bruk en innboks noen leser. La Medlemskap (“Alle kan registrere seg”) være av med mindre nettstedet trenger åpen registrering, og hvis det gjør det, behold Abonnent som standardrolle for nye brukere.

Lesing. Her ligger avkrysningsboksen for synlighet for søkemotorer. Staging-kopier bør ha den krysset av, produksjon skal ikke. Innstillingen lagres i databasen og følger med hver kopi av databasen: sjekk den etter hver flytting fra staging til produksjon.

Diskusjon. En ny installasjon har kommentarer og pingbacks åpne som standard, manuell godkjenning av kommentarer slått av og “Kommentarforfatteren må ha en tidligere godkjent kommentar” slått på. På et firmanettsted uten kommentarer stenger du dem her før publisering. Innstillingen gjelder nye innlegg; eksisterende innlegg beholder sin egen status.

#Slik leser du Nettstedshelse etter at WordPress er installert

Verktøy > Nettstedshelse kjører en rekke kontroller og sorterer resultatene i kritiske problemer og anbefalte forbedringer (dokumentasjonen for Site Health). På et nytt nettsted er de nyttige kontrollene de som innstillingene i denne artikkelen berører:

Feilsøking aktivert. Med WP_DEBUG_LOG på blir kontrollen kritisk når PHP-feilloggen ligger inne i WordPress-katalogen, fordi loggen da kan lastes ned. Derfor peker loggstien lenger opp i artikkelen ut av den offentlige mappen.
Synlighet for søkemotorer. Flagges så lenge “Be søkemotorer om ikke å indeksere” er krysset av (kontroll lagt til i WordPress 6.9).
Åpen registrering med en privilegert standardrolle. Flagges når hvem som helst kan registrere seg med en rolle over Abonnent (siden WordPress 7.0).
Bakgrunnsoppdateringer, automatiske oppdateringer av utvidelser og temaer, planlagte hendelser, loopback-forespørsel. Feiler disse, kjører verken automatiske oppdateringer eller WP-Cron-jobber.
HTTPS-status, vedvarende objekthurtigbuffer, sidehurtigbuffer. Kontroller av driftsmiljøet. De to hurtigbufferkontrollene er anbefalinger, ikke feil.

Fanen Info viser serverdata (PHP-versjon og utvidelser, databaseversjon, støtte i bilderedigereren, konstanter som WP_DEBUG_LOG og WP_ENVIRONMENT_TYPE) og har en knapp som kopierer alt til utklippstavlen. Limt inn i en henvendelse sparer det en runde med spørsmål fra driftsleverandøren.

#Slik fungerer automatiske oppdateringer på et nytt WordPress-nettsted

Det finnes tre nivåer, som stilles inn på ulike steder (Configuring automatic background updates):

Mindre kjerneversjoner (sikkerhet og vedlikehold) installeres automatisk, og har gjort det siden WordPress 3.7.
Større kjerneversjoner. På nettsteder installert med WordPress 5.6 eller nyere starter valget auto_update_core_major som aktivert. Nettsteder oppgradert fra en eldre versjon har det ikke satt. Konstanten WP_AUTO_UPDATE_CORE overstyrer begge: true for alle versjoner, 'minor' bare for mindre versjoner, false slår av kjerneoppdateringer i bakgrunnen.
Utvidelser og temaer. Automatiske oppdateringer er av som standard og slås på per utvidelse eller tema i skjermbildene Utvidelser og Temaer, en funksjon som kom i WordPress 5.5.

DISALLOW_FILE_MODS (punkt 5 i sjekklisten) gjør mer enn å skjule knappene for installasjon og oppdatering. Kjernen sjekker wp_is_file_mod_allowed( 'automatic_updater' ) før hver bakgrunnsoppdatering, så konstanten stopper også automatiske sikkerhetsversjoner. Det er greit når hver oppdatering kommer gjennom en utrulling. Uten en slik prosess blir nettstedet stående på versjonen det ble rullet ut med, til noen ruller ut igjen.

#Bør du slå av programpassord i WordPress

Programpassord, innført i WordPress 5.6, lar et eksternt verktøy autentisere seg mot REST API med brukernavnet og et generert passord i stedet for kontopassordet (dokumentasjonen for Application Passwords). Hver bruker oppretter og tilbakekaller dem i sin egen profil. Et nytt passord vises én gang, lagres som hash og står oppført med dato og IP-adresse for siste bruk. Kjernen tilbyr funksjonen bare på nettsteder med HTTPS eller når WP_ENVIRONMENT_TYPE er local.

La den være på når en mobilapp, et utrullingsverktøy eller en integrasjon snakker med REST API. På et nettsted uten noe av dette slår ett filter den av for alle brukere:

add_filter( 'wp_is_application_passwords_available', '__return_false' );

Ved mistanke om innbrudd tilbakekaller du programpassordene i tillegg til å bytte salt-nøklene. Nye nøkler avslutter alle påloggingsøkter, men programpassord hashes med en fast nøkkel som ikke avhenger av saltene, så de virker til noen tilbakekaller dem.

#Slik setter du opp personvernerklæringen i WordPress

Installasjonsprogrammet oppretter en side “Personvernerklæring” som utkast og tilordner den under Innstillinger > Personvern, et skjermbilde som kom i WordPress 4.9.6 (dokumentasjonen for personverninnstillingene). Utkastet inneholder foreslåtte overskrifter og eksempeltekst, ikke en ferdig erklæring. Samme skjermbilde lar deg velge en annen side og lenker til veiledningen for personvernerklæringen, der kjernen og utvidelser som registrerer foreslått tekst med wp_add_privacy_policy_content(), beskriver hva de lagrer.

To ting følger av dette. Utkastet er ikke offentlig før noen redigerer og publiserer det. Og temaer skriver ut lenken til erklæringen med the_privacy_policy_link(), som ikke viser noe så lenge den tilordnede siden ikke er publisert, så en lenke som “mangler” i bunnteksten betyr som regel en upublisert side. Verktøy > Eksporter personopplysninger og Verktøy > Slett personopplysninger håndterer forespørsler om innsyn og sletting for dataene WordPress og samarbeidende utvidelser lagrer.

#Oppsummering: sjekklisten med 50 punkter

#Sikkerhet (1-15)

✅ Sett et eget tabellprefiks (ved installasjon, med $table_prefix)
✅ Velg sterke passord (minst 12 tegn)
✅ Endre brukernavnet admin
✅ Slå av filredigereren i administrasjonen
✅ Blokker installasjon av utvidelser (valgfritt; stopper også automatiske oppdateringer)
✅ Tving SSL i administrasjonspanelet
✅ Beskytt wp-config.php med .htaccess
✅ Blokker tilgang til kataloger (no indexes)
✅ Begrens XML-RPC (filteret dekker bare autentiserte metoder; behold det for Jetpack)
✅ Skjul WordPress-versjonen
✅ Begrens påloggingsforsøk
✅ Sett opp tofaktorautentisering (utvidelsen Two Factor)
✅ Roter autentiseringsnøklene (salts) jevnlig
✅ Installer et SSL-sertifikat
✅ Sett opp beskyttelse på servernivå (brannmur, begrensning av påloggingsforsøk)

#Ytelse (16-25)

✅ Begrens innleggsrevisjoner (5-10)
✅ Slå av emoji
✅ Slå av ubrukte funksjoner (XML-RPC, RSD)
✅ Optimaliser bildestørrelser
✅ Sjekk at lat innlasting er aktiv (standard siden 5.5)
✅ Sett opp hurtigbuffer (objektbuffer, sidebuffer)
✅ Optimaliser Heartbeat API
✅ Slå på GZIP/Brotli-komprimering
✅ Sett opp CDN (valgfritt)
✅ Optimaliser databasen (automatisk opprydding)

#SEO (26-35)

✅ Velg permalenkestrukturen “Innleggsnavn”
✅ Sett nettstedstittel og slagord (slagordet er ikke en metabeskrivelse)
✅ Sjekk kjernens nettstedskart på /wp-sitemap.xml
✅ Legg nettstedet til i Google Search Console
✅ Sett opp Google Analytics / GA4
✅ Skriv ALT-tekst for hvert bilde
✅ Lag kategoristrukturen
✅ Sett opp brødsmuler
✅ Legg til Organization-skjema
✅ Klargjør Open Graph-metatagger

#Sikkerhetskopier (36-42)

✅ Sett opp automatiske kopier av databasen
✅ Sett opp ukentlige fullstendige kopier
✅ Oppbevar kopiene et eksternt sted
✅ Test gjenoppretting fra kopi
✅ Angi oppbevaringstid for kopier (minst 30 dager)
✅ Dokumenter gjenopprettingsrutinen
✅ Kontroller integriteten til kopiene jevnlig

#Innhold og funksjonalitet (43-50)

✅ Lag grunnleggende sider (Om oss, Kontakt, Personvernerklæring)
✅ Sett opp navigasjonsmenyer
✅ Test alle skjemaer
✅ Sett opp SMTP for e-post
✅ Lag en egen 404-side
✅ Legg til favicon og PWA-ikoner
✅ Kjør ytelsestester
✅ Dokumenter konfigurasjonen

Se vår sikkerhetsrevisjon av WordPress hvis du vil få oversikt over risikoer og beskyttelse på nettstedet.

#Forskjeller i wp-config.php mellom staging og produksjon

Denne guiden setter WP_DEBUG to ganger med ulike verdier: true i avsnittet om feilsøking og false i avsnittet om overvåking. Begge er riktige, hver for sitt miljø, og derfor bør ikke den samme kopien av wp-config.php havne uendret på både staging og produksjon. Før du flytter filen mellom servere, gå gjennom disse konstantene:

WP_ENVIRONMENT_TYPE: staging på testkopien, production på det levende nettstedet. Alle betingelser som bygger på wp_get_environment_type() avhenger av denne verdien.
WP_DEBUG: på i staging, av i produksjon. WP_DEBUG_DISPLAY forblir false begge steder, og loggen havner utenfor den offentlige katalogen.
SAVEQUERIES: bare mens du leter etter trege spørringer, aldri i produksjon.
DISALLOW_FILE_MODS: blokkerer i produksjon installasjon og oppdatering av utvidelser fra administrasjonen, så oppdateringer går via utrulling eller WP-CLI. Avklar dette med kunden før vedkommende legger merke til at oppdateringsknappen mangler.
Autentiseringsnøkler: genereres tilfeldig for hver installasjon. En kopi av produksjon på staging får sitt eget sett, og produksjonsnøklene lar du være i fred, fordi en endring logger ut alle brukere.

Når filen er flyttet, kjører du wp core verify-checksums og wp plugin verify-checksums --all fra avsnittet om tester før lansering.