Du besöker en webbplats, klickar på en länk till en färsk artikel och istället för text möts du av en vit sida med "404 Page Not Found". En välbekant syn.

Permalänkar i WordPress är enkelt uppbyggda, men går sönder med skrämmande lätthet. En trasig plugin, en misslyckad uppdatering eller en oavsiktlig ändring i .htaccess, och hela webbplatsen förvandlas till en samling brutna URL:er. Enligt det officiella supportforumet för WordPress är fel i permalänkstrukturen bland de fem vanligaste problemen.

Här följer en diagnos- och reparationsalgoritm, från en snabb återställning av inställningar till manuell redigering av serverkonfigurationer. Varje steg har testats på riktiga webbplatser. Ingen panik.

💡 Snabb översikt:

• Återställ permalänkinställningarna i adminpanelen med ett klick, för de flesta webbplatser försvinner problemet direkt
• Om återställningen inte fungerade, byt namn på .htaccess och återställ igen: WordPress skapar en ren fil med korrekta omskrivningsregler
• Kontrollera plugins genom uteslutningsmetoden: avaktivera alla på en gång och aktivera dem en efter en efter varje permalänkåterställning
• På Apache-server, aktivera mod_rewrite manuellt och lägg till AllowOverride All i den virtuella värdens konfiguration

Varför WordPress permalänkar slutar fungera

En permalänk är en oföränderlig URL för ett inlägg, en sida eller en kategori. WordPress lagrar permalänkstrukturen i databasen och serverar "snygga" URL:er via Apache-webbserverns mod_rewrite-modul. Ett brott i någon länk i denna kedja ger en 404.

Installation av en ny plugin. Vissa plugins stör URL-skapandemekanismen: de skriver om .htaccess, lägger till egna omdirigeringsregler eller hamnar i konflikt med redan aktiva tillägg. SEO-plugins, cachelösningar och säkerhetsplugins är i en särskild riskzon, de arbetar alla med URL:er på en låg nivå.

Uppdatering av kärnan, temat eller plugins. En större WordPress-uppdatering eller en PHP-versionsändring hos webbhotellet gör gamla plugins inkompatibla. Resultatet är en konflikt som kraschar omskrivningsreglerna. Du kan inte hoppa över säkerhetsuppdateringar, men före varje större uppdatering, gör en säkerhetskopia och kontrollera kompatibiliteten på en staging-kopia.

Flytt av webbplatsen till en ny domän eller server. WordPress-migrering är en av de vanligaste orsakerna till brutna länkar. Absoluta sökvägar ändras, serialiserad data i databasen och webbserverinställningar ändras. Även att lägga till ett SSL-certifikat efter migrering kan förstöra permalänkar, eftersom det kräver redigering av .htaccess för HTTP→HTTPS-omdirigering. Om du nyligen flyttade en WordPress-installation till en underkatalog, kontrollera permalänkstrukturen omedelbart efter migreringen.

Återställning av en säkerhetskopia. Att återställa en webbplats från en säkerhetskopia återuppväcker ibland också gamla problem. Om säkerhetskopian gjordes innan du konfigurerade permalänkar, återkommer 404-felen. Inte ens avancerade backup-plugins garanterar perfekt återställning av omskrivningsregler efter komplexa migreringar.

Skadad .htaccess. Filen .htaccess är länken mellan WordPress och Apache. Den lagrar mod_rewrite-direktiv som ansvarar för "snygga" URL:er. En plugin skriver skräp, du råkar ta bort filen via FTP, och vissa webbhotellspaneler återställer den när inställningar ändras. Utan en fungerande .htaccess förvandlas permalänkar till ?p=123.

Hur man fixar trasiga permalänkar: steg-för-steg-guide

Vi har täckt orsakerna, nu går vi vidare till lösningar. Gå i ordning: tillämpa varje nästa steg endast om det föregående inte fungerade.

Steg 1. Återställ permalänkinställningarna

Den snabbaste och säkraste metoden. WordPress lagrar permalänkstrukturen i databasen, och när inställningar sparas regenereras omskrivningsreglerna. Utvecklare kallar denna process "flush rewrite rules".

Gå till adminpanelen, navigera till Inställningar → Permalänkar:

Växla tillfälligt till en annan struktur, till exempel "Standard" istället för "Inläggsnamn", och klicka på Spara ändringar. Återgå sedan till det ursprungliga alternativet och spara igen. Du behöver inte ändra inställningarna permanent: det som spelar roll är själva sparandet, vilket tvingar WordPress att bygga om reglerna.

Ladda om webbplatsen och kontrollera om inlägg öppnas. Fungerar det? Problemet löst. Nej, gå vidare.

Steg 2. Kontrollera och återskapa.htaccess-filen

Om återställningen inte hjälpte ligger källan till problemet nästan säkert i .htaccess. Filen finns i webbplatsens rot, på samma plats som wp-config.php och mapparna wp-content och wp-includes.

Anslut till servern via FTP (FileZilla, WinSCP) eller filhanteraren i webbhotellspanelen:

Hitta .htaccess, högerklicka och byt namn på den till .htaccess_old. Ta inte bort filen, den kan innehålla kritiska regler som HTTP→HTTPS-omdirigering eller komprimeringsinställningar:

Efter namnbytet slutar WordPress att se den gamla filen. Gå till adminpanelen och återställ permalänkar som i Steg 1, systemet kommer att skapa en ny, ren .htaccess med korrekta omskrivningsregler. Behåll den gamla filen som en säkerhetskopia.

Steg 3. Hitta den motstridiga pluginen

Uppstod problemet efter installation av en specifik plugin? Avaktivera den och återställ permalänkarna igen, troligtvis räcker det.

När den skyldige är okänd, använd uteslutningsmetoden:

Avaktivera alla plugins på en gång. Återställ permalänkar. Kontrollera webbplatsen: om den fungerar ligger problemet i en av pluginsen. Aktivera dem en efter en, och efter varje återställ inställningarna och kontrollera webbplatsen. Pluginen efter vilken länkarna går sönder igen är orsaken.

Ersätt den funna motstridiga pluginen med ett alternativ från WordPress.org-katalogen. Rapportera problemet till utvecklaren: ofta känner de till inkompatibiliteter och kan föreslå en lösning.

Steg 4. Konfigurera servern: AllowOverride och mod_rewrite

Om tidigare steg inte hjälpte och du använder Apache, kan problemet ligga i den virtuella värdens inställningar.

Se först till att modulen mod_rewrite är aktiverad. Det är den som omvandlar "snygga" URL:er till frågor som WordPress förstår. Kontrollera och aktivera den med kommandot:

1
sudo a2enmod rewrite

Om modulen redan var aktiverad visas en varning, det är normalt. Starta nu om Apache:

1
sudo systemctl restart apache2

På CentOS/RHEL är omstartskommandot annorlunda:

1
sudo systemctl restart httpd

Den andra nödvändiga komponenten är direktivet AllowOverride All. Det tillåter .htaccess-filen att åsidosätta serverkonfigurationen inom webbplatskatalogen. Öppna Apaches konfigurationsfil: på Ubuntu är det /etc/apache2/sites-available/your-site.conf, på CentOS är det /etc/httpd/conf/httpd.conf. Hitta sektionen <Directory> och ändra den till denna form:

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

Ersätt sökvägen /var/www/your-site/ med den faktiska sökvägen till WordPress rotmapp på din server. Efter redigering, starta om Apache med kommandot ovan och återställ sedan permalänkar i adminpanelen.

Dessa två serveråtgärder, AllowOverride All plus mod_rewrite, täcker praktiskt taget alla återstående scenarier med trasiga permalänkar på Apache.

Video: steg-för-steg-återställning av permalänkar

Om du föredrar att titta snarare än att läsa, här är en kort guide som visar hela processen från att återställa permalänkinställningar till att återställa .htaccess på en riktig webbplats:

⁉️🤔 Vanliga frågor

Varför kvarstår 404-felet efter återställning av permalänkar?

Återställning via adminpanelen skriver om omskrivningsreglerna i databasen. Men om .htaccess är fysiskt otillgänglig för skrivning, felaktiga åtkomsträttigheter, kan WordPress inte uppdatera filen på servern. Kontrollera rättigheter: vanligtvis krävs 755 för kataloger och 644 för filer. Se också till att .htaccess fysiskt existerar: efter namnbyte i Steg 2 skapar WordPress en ny vid nästa återställning. Själva återställningen ändrar inte URL:er för befintliga inlägg och förstör inte indexering.

Kan jag bara ta bort.htaccess?

Nej. Utan .htaccess på en Apache-server faller WordPress tillbaka på "enkla" länkar som ?p=123, detta är fult och skadar SEO. Rätt ordning: byt namn på den gamla filen samtidigt som du behåller en säkerhetskopia, återställ sedan permalänkinställningarna i adminpanelen. WordPress skapar en ny .htaccess automatiskt. Ta aldrig bort filen utan möjlighet att återställa: den kan innehålla kritiska regler för HTTP→HTTPS-omdirigering eller komprimeringsinställningar.

Vad gör man om webbplatsen ligger på Nginx?

På Nginx finns ingen .htaccess-fil, alla omskrivningsregler skrivs i serverkonfigurationen. Standardblocket för WordPress: location / { try_files $uri $uri/ /index.php?$args; }. Kontrollera webbplatsens konfigurationsfil (vanligtvis /etc/nginx/sites-available/your-site), lägg till detta block i server-sektionen och ladda om Nginx: sudo systemctl reload nginx. Steg 1 och 3, återställning av länkar och kontroll av plugins, fungerar för Nginx exakt likadant som för Apache.

Vilken plugin förstör oftast permalänkar?

Statistiskt sett leder SEO-plugins, de manipulerar URL:er direkt, och cachelösningar: de skapar statiska kopior av sidor och kan "minnas" den trasiga versionen. På tredje plats kommer säkerhetsplugins som modifierar .htaccess för att blockera misstänkta förfrågningar. Efter att ha inaktiverat en caching-plugin, se till att rensa webbläsarens cache eller öppna webbplatsen i inkognitoläge, en statisk cachad version med 404 kan visas även efter fix.

Behöver jag kontrollera databasens integritet?

I sällsynta fall är orsaken en korrupt wp_options-tabell där permalänkinställningarna lagras. Om ingen av de beskrivna metoderna hjälpte, gå till phpMyAdmin, hitta tabellen wp_options och kontrollera posten med option_name = 'rewrite_rules'. Om värdet ser ut som skräp eller ett korrupt serialiserat objekt, ta bort denna post och återställ sedan permalänkinställningarna i adminpanelen. WordPress kommer att återskapa omskrivningsregler från grunden. De flesta användare behöver inte detta steg: den överväldigande majoriteten av problem löses med metod 1-3.

Vad du ska göra om inget hjälpte

Vi har gått från en enkel återställning av inställningar till serverkonfiguration för Apache och Nginx. För den absoluta majoriteten av webbplatser löser en av dessa metoder problemet.

Om 404-fel fortfarande finns kvar, kontakta ditt webbhotells tekniska support. Beskriv problemet och lista de steg du redan har utfört. Ofta ligger orsaken i webbhotellsmiljöns särdrag: mod_rewrite inaktiverad på leverantörsnivå, icke-standardiserad PHP-FPM-konfiguration eller anpassade brandväggsregler som blockerar förfrågningar till index.php. Webbhotellets support ser serversidan som är dold för dig och löser sådana problem på minuter.

Huvudregeln värd att komma ihåg: återställ permalänkar → byt namn på.htaccess → återställ igen. Denna sekvens av två åtgärder fixar de flesta fall och kräver varken specialkunskaper eller serveråtkomst. Börja med den nästa gång, och troligtvis behöver du inte gå längre.