Du besøker et nettsted, klikker på en lenke til en fersk artikkel, og i stedet for tekst ser du en hvit side med «404 Page Not Found». Et velkjent bilde.

Permalenker i WordPress er enkelt bygget opp, men ryker med skremmende letthet. En ødelagt plugin, en mislykket oppdatering eller en utilsiktet endring i .htaccess, så forvandles hele nettstedet til en samling ødelagte URL-er. Ifølge det offisielle WordPress-støtteforumet er feil i permalenkestrukturen blant de fem vanligste problemene.

Nedenfor finner du en diagnose- og reparasjonsalgoritme, fra en rask tilbakestilling av innstillinger til manuell redigering av serverkonfigurasjoner. Hvert trinn er testet på reelle nettsteder. Panikken er avlyst.

💡 Rask oversikt:

• Tilbakestill permalenkeinnstillingene i administrasjonspanelet med ett klikk, for de fleste nettsteder forsvinner problemet umiddelbart
• Hvis tilbakestillingen ikke virket, gi nytt navn til .htaccess og tilbakestill på nytt: WordPress oppretter en ren fil med korrekte omskrivingsregler
• Sjekk plugins ved hjelp av eliminasjonsmetoden: deaktiver alle samtidig og aktiver dem én etter én etter hver tilbakestilling av permalenker
• På Apache-server, aktiver mod_rewrite manuelt og legg til AllowOverride All i konfigurasjonen for den virtuelle verten

Hvorfor WordPress-permalenker slutter å virke

En permalenke er en uforanderlig URL for et innlegg, en side eller en kategori. WordPress lagrer permalenkestrukturen i databasen og serverer «pene» URL-er gjennom Apache-nettserverens mod_rewrite-modul. Et brudd i noen av leddene i denne kjeden produserer en 404.

Installering av en ny plugin. Noen plugins forstyrrer URL-dannelsesmekanismen: de skriver om .htaccess, legger til sine egne omdirigeringsregler eller kommer i konflikt med allerede aktive utvidelser. SEO-plugins, hurtigbufferløsninger og sikkerhetsplugins er i en spesiell risikosone, de jobber alle med URL-er på et lavt nivå.

Oppdatering av kjerne, tema eller plugins. En større WordPress-oppdatering eller en PHP-versjonsendring hos hostingleverandøren gjør gamle plugins inkompatible. Resultatet er en konflikt som knekker omskrivingsreglene. Du kan ikke hoppe over sikkerhetsoppdateringer, men før hver større oppdatering bør du ta en sikkerhetskopi og sjekke kompatibilitet på en testkopi.

Flytting av et nettsted til et nytt domene eller en ny server. WordPress-migrering er en av de vanligste årsakene til ødelagte lenker. Absolutte stier endres, serialiserte data i databasen og innstillinger for nettserveren endres. Selv å legge til et SSL-sertifikat etter migrering kan ødelegge permalenker, fordi det krever redigering av .htaccess for HTTP→HTTPS-omdirigering. Hvis du nylig flyttet en WordPress-installasjon til en underkatalog, sjekk permalenkestrukturen umiddelbart etter migrering.

Gjenoppretting av en sikkerhetskopi. Å gjenopprette et nettsted fra en sikkerhetskopi gjenoppliver noen ganger også gamle problemer. Hvis sikkerhetskopien ble tatt før du konfigurerte permalenker, kommer 404-ene tilbake. Selv avanserte backup-plugins garanterer ikke perfekt gjenoppretting av omskrivingsregler etter komplekse migreringer.

Korrupt .htaccess. Filen .htaccess er bindeleddet mellom WordPress og Apache. Den lagrer mod_rewrite-direktiver som er ansvarlige for «pene» URL-er. En plugin skriver søppel, du sletter filen ved et uhell via FTP, og noen hostingspaneler tilbakestiller den når du endrer innstillinger. Uten en fungerende .htaccess blir permalenker til ?p=123.

Slik fikser du ødelagte permalenker: trinn-for-trinn-veiledning

Vi har dekket årsakene, la oss nå gå over til løsningene. Gå frem i rekkefølge: bruk hvert neste trinn bare hvis det forrige ikke virket.

Trinn 1. Tilbakestill permalenkeinnstillingene

Den raskeste og sikreste metoden. WordPress lagrer permalenkestrukturen i databasen, og når du lagrer innstillinger, regenererer den omskrivingsreglene. Utviklere kaller denne prosessen «flush rewrite rules».

Gå til administrasjonspanelet, naviger til Innstillinger → Permalenker:

Bytt midlertidig til en hvilken som helst annen struktur, for eksempel «Enkel» i stedet for «Innleggsnavn», og klikk Lagre endringer. Gå deretter tilbake til det opprinnelige alternativet og lagre på nytt. Du trenger ikke å endre innstillingene permanent: det som betyr noe, er selve lagringen, som tvinger WordPress til å gjenoppbygge reglene.

Last nettstedet på nytt og sjekk om innlegg åpnes. Virker det? Problem løst. Nei? Gå videre.

Trinn 2. Sjekk og gjenskap.htaccess-filen

Hvis tilbakestillingen ikke hjalp, ligger kilden til problemet nesten helt sikkert i .htaccess. Filen ligger i nettstedets rot, på samme sted som wp-config.php og mappene wp-content og wp-includes.

Koble til serveren via FTP (FileZilla, WinSCP) eller filbehandleren i hostingspanelet:

Finn .htaccess, høyreklikk og gi den nytt navn til .htaccess_old. Ikke slett filen, den kan inneholde kritiske regler som HTTP→HTTPS-omdirigering eller komprimeringsinnstillinger:

Etter navneendringen slutter WordPress å se den gamle filen. Gå til administrasjonspanelet og tilbakestill permalenker som i Trinn 1, systemet vil opprette en ny, ren .htaccess med korrekte omskrivingsregler. Behold den gamle filen som en sikkerhetskopi.

Trinn 3. Finn den motstridende pluginen

Oppsto problemet etter at du installerte en bestemt plugin? Deaktiver den og tilbakestill permalenker på nytt, mest sannsynlig er det nok.

Når synderen er ukjent, bruk eliminasjonsmetoden:

Deaktiver alle plugins samtidig. Tilbakestill permalenker. Sjekk nettstedet: hvis det fungerer, ligger problemet i én av pluginene. Aktiver dem én etter én, og etter hver enkelt tilbakestiller du innstillingene og sjekker nettstedet. Pluginen som gjør at lenkene ryker igjen, er årsaken.

Erstatt den funnet, motstridende pluginen med et alternativ fra WordPress.org-katalogen. Rapporter problemet til utvikleren: ofte vet de om inkompatibiliteter og kan foreslå en løsning.

Trinn 4. Konfigurer serveren: AllowOverride og mod_rewrite

Hvis de foregående trinnene ikke hjalp og du bruker Apache, kan problemet ligge i innstillingene for den virtuelle verten.

Først må du forsikre deg om at mod_rewrite-modulen er aktivert. Det er den som forvandler «pene» URL-er til spørringer WordPress forstår. Sjekk og aktiver den med kommandoen:

1
sudo a2enmod rewrite

Hvis modulen allerede var aktivert, vil en advarsel vises, det er normalt. Start nå Apache på nytt:

1
sudo systemctl restart apache2

På CentOS/RHEL er omstartskommandoen annerledes:

1
sudo systemctl restart httpd

Den andre nødvendige komponenten er direktivet AllowOverride All. Det tillater .htaccess-filen å overstyre serverkonfigurasjonen innenfor nettstedets katalog. Åpne Apaches konfigurasjonsfil: på Ubuntu er det /etc/apache2/sites-available/your-site.conf, på CentOS er det /etc/httpd/conf/httpd.conf. Finn <Directory>-seksjonen og bring den til denne formen:

1
<Directory /var/www/your-site/>
2
    AllowOverride All
3
</Directory>

Erstatt stien /var/www/your-site/ med den faktiske stien til WordPress-rotmappen på serveren din. Etter redigering starter du Apache på nytt med kommandoen ovenfor, og tilbakestiller deretter permalenker i administrasjonspanelet.

Disse to serverhandlingene, AllowOverride All pluss mod_rewrite, lukker praktisk talt alle gjenværende scenarier for ødelagte permalenker på Apache.

Video: trinnvis gjenoppretting av permalenker

Hvis du foretrekker å se fremfor å lese, her er en kort veiledning som viser hele prosessen fra tilbakestilling av permalenkeinnstillinger til gjenoppretting av .htaccess på et ekte nettsted:

⁉️🤔 Ofte stilte spørsmål

Hvorfor forblir 404-feilen etter tilbakestilling av permalenker?

Tilbakestilling via administrasjonspanelet skriver om omskrivingsreglene i databasen. Men hvis .htaccess er fysisk utilgjengelig for skriving, feil tilgangsrettigheter, kan ikke WordPress oppdatere filen på serveren. Sjekk rettighetene: vanligvis kreves 755 for mapper og 644 for filer. Forsikre deg også om at .htaccess fysisk eksisterer: etter navneendring i Trinn 2 oppretter WordPress en ny ved neste tilbakestilling. Selve tilbakestillingen endrer ikke URL-ene til eksisterende innlegg og ødelegger ikke indeksering.

Kan jeg bare slette.htaccess?

Nei. Uten .htaccess på en Apache-server faller WordPress tilbake til «enkle» lenker som ?p=123, dette er stygt og skader SEO. Riktig rekkefølge: gi den gamle filen nytt navn mens du beholder en sikkerhetskopi, og tilbakestill deretter permalenkeinnstillingene i administrasjonspanelet. WordPress vil opprette en ny .htaccess automatisk. Slett aldri filen uten mulighet til å gjenopprette: den kan inneholde kritiske regler for HTTP→HTTPS-omdirigering eller komprimeringsinnstillinger.

Hva gjør jeg hvis nettstedet er på Nginx?

På Nginx finnes det ingen .htaccess-fil, alle omskrivingsregler er skrevet i serverkonfigurasjonen. Standardblokken for WordPress: location / { try_files $uri $uri/ /index.php?$args; }. Sjekk nettstedets konfigurasjonsfil (vanligvis /etc/nginx/sites-available/your-site), legg til denne blokken i server-seksjonen og last Nginx på nytt: sudo systemctl reload nginx. Trinn 1 og 3, tilbakestilling av lenker og sjekking av plugins, fungerer for Nginx nøyaktig på samme måte som for Apache.

Hvilken plugin ødelegger oftest permalenker?

Statistisk sett leder SEO-plugins, de manipulerer URL-er direkte, og hurtigbufferløsninger: de lager statiske kopier av sider og kan «huske» den ødelagte versjonen. På tredjeplass kommer sikkerhetsplugins som endrer .htaccess for å blokkere mistenkelige forespørsler. Etter å ha deaktivert en hurtigbuffer-plugin, sørg for å tømme nettleserbufferen eller åpne nettstedet i inkognitomodus, en statisk bufret versjon med 404 kan vises selv etter fiksing.

Må jeg sjekke databaseintegriteten?

I sjeldne tilfeller er årsaken en korrupt wp_options-tabell der permalenkeinnstillingene er lagret. Hvis ingen av de beskrevne metodene hjalp, gå til phpMyAdmin, finn wp_options-tabellen og sjekk oppføringen med option_name = 'rewrite_rules'. Hvis verdien ser ut som søppel eller et korrupt serialisert objekt, slett denne oppføringen og tilbakestill deretter permalenkeinnstillingene i administrasjonspanelet. WordPress vil gjenskape omskrivingsreglene fra bunnen av. De fleste brukere vil ikke trenge dette trinnet: det store flertallet av problemer løses med metode 1-3.

Hva du skal gjøre hvis ingenting hjalp

Vi har gått fra en enkel tilbakestilling av innstillinger til konfigurasjon av Apache- og Nginx-servere. For det absolutte flertallet av nettsteder løser én av disse metodene problemet.

Hvis 404-ene fortsatt er der, kontakt teknisk support hos hostingleverandøren din. Beskriv problemet og list opp trinnene du allerede har utført. Ofte ligger årsaken i spesifikke forhold ved hostingsmiljøet: mod_rewrite deaktivert på leverandørnivå, ikke-standard PHP-FPM-konfigurasjon eller tilpassede brannmurregler som blokkerer forespørsler til index.php. Hostingsupporten ser serversiden som er skjult for deg og løser slike problemer på minutter.

Hovedregelen det er verdt å huske: tilbakestill permalenker → gi nytt navn til.htaccess → tilbakestill på nytt. Denne sekvensen av to handlinger fikser de fleste tilfeller og krever verken spesialkunnskap eller servertilgang. Start med den neste gang, så slipper du mest sannsynlig å gå videre.