Külastate saiti, klõpsate lingil värskele artiklile ja teksti asemel näete valget lehte kirjaga „404 Page Not Found". Tuttav pilt.

Püsilinkide ülesehitus WordPressis on lihtne, kuid need lähevad katki murettekitavalt kergesti. Üks katkine plugin, ebaõnnestunud uuendus või juhuslik muudatus failis .htaccess ja kogu sait muutub katkiste URL-ide kogumiks. Ametliku WordPressi tugifoorumi andmetel kuuluvad püsilinkide struktuuri vead viie kõige sagedasema probleemi hulka.

Allpool on diagnostika- ja parandusalgoritm alates kiirest seadete lähtestamisest kuni serveri konfiguratsioonifailide käsitsi muutmiseni. Iga sammu on testitud reaalsetel saitidel. Paanika tühistatud.

💡 Kiirülevaade:

• Lähtesta püsilinkide seaded administraatoripaneelis ühe klõpsuga, enamiku saitide puhul kaob probleem koheselt
• Kui lähtestamine ei aidanud, nimeta .htaccess ümber ja lähtesta uuesti: WordPress loob puhta faili õigete ümberkirjutusreeglitega
• Kontrolli pluginaid elimineerimismeetodil: deaktiveeri kõik korraga ja luba need ükshaaval pärast iga püsilinkide lähtestamist
• Apache serveris luba käsitsi mod_rewrite ja lisa virtuaalhosti konfiguratsiooni AllowOverride All

Miks WordPressi püsilingid lakkavad töötamast

Püsilink on muutumatu URL postituse, lehe või kategooria jaoks. WordPress salvestab püsilinkide struktuuri andmebaasi ja serveerib „ilusaid" URL-e Apache veebiserveri mod_rewrite mooduli kaudu. Katkestus ükskõik millises selle ahela lülis tekitab 404 vea.

Uue plugina paigaldamine. Mõned pluginad segavad URL-ide moodustamise mehhanismi: nad kirjutavad ümber .htaccess-faili, lisavad oma ümbersuunamise reegleid või lähevad vastuollu juba aktiivsete laiendustega. SEO-pluginad, vahemällusalvestuse lahendused ja turvapluginad on erilises riskitsoonis, kuna need kõik töötavad URL-idega madalal tasemel.

Tuuma, teema või pluginate uuendamine. WordPressi suurem uuendus või PHP versiooni muutus hostingu keskkonnas muudab vanad pluginad ühildumatuks. Tulemuseks on konflikt, mis rikub ümberkirjutusreeglid. Turvauuendusi ei saa vahele jätta, kuid enne iga suuremat uuendust tehke varukoopia ja kontrollige ühilduvust lavastuskoopial.

Saidi kolimine uuele domeenile või serverisse. WordPressi migratsioon on üks levinumaid katkiste linkide põhjuseid. Absoluutsed teed muutuvad, serialiseeritud andmed andmebaasis ja veebiserveri seaded muutuvad. Isegi SSL-sertifikaadi lisamine pärast migratsiooni võib püsilingid katki teha, sest see nõuab .htaccess-faili muutmist HTTP→HTTPS ümbersuunamise jaoks. Kui te hiljuti kolisite WordPressi installatsiooni alamkataloogi, kontrollige püsilinkide struktuuri kohe pärast migratsiooni.

Varukoopia taastamine. Saidi taastamine varukoopiast äratab mõnikord ellu ka vanad probleemid. Kui varukoopia tehti enne püsilinkide seadistamist, tulevad 404 vead tagasi. Isegi arenenud varunduspluginad ei taga ümberkirjutusreeglite täiuslikku taastamist pärast keerulisi migratsioone.

*Rikutud .htaccess.* Fail .htaccess on ühenduslüli WordPressi ja Apache vahel. See salvestab mod_rewrite direktiivid, mis vastutavad „ilusa" URL-i eest. Plugin kirjutab sinna prahti, te kustutate faili kogemata FTP kaudu ja mõned hostingupaneelid lähtestavad selle seadete muutmisel. Ilma töötava .htaccess-failita muutuvad püsilingid kujule ?p=123.

Kuidas parandada katkised püsilingid: samm-sammuline juhend

Põhjused on käsitletud, nüüd liigume lahenduste juurde. Minge järjekorras: rakendage iga järgmist sammu ainult siis, kui eelmine ei aidanud.

Samm 1. Lähtesta püsilinkide seaded

Kiireim ja ohutuim meetod. WordPress salvestab püsilinkide struktuuri andmebaasi ja seadete salvestamisel genereerib see ümberkirjutusreeglid uuesti. Arendajad nimetavad seda protsessi „ümberkirjutusreeglite tühjendamiseks".

Minge administraatoripaneeli, navigeerige Seaded → Püsilingid:

Lülituge ajutiselt mõnele muule struktuurile, näiteks „Lihtne" asemel „Postituse nimi", ja klõpsake Salvesta muudatused. Seejärel taastage algne valik ja salvestage uuesti. Te ei pea seadeid jäädavalt muutma: oluline on salvestamise fakt, mis sunnib WordPressi reegleid uuesti üles ehitama.

Laadige sait uuesti ja kontrollige, kas postitused avanevad. Töötab? Probleem lahendatud. Ei, liikuge edasi.

Samm 2. Kontrolli ja taasloo.htaccess fail

Kui lähtestamine ei aidanud, on probleemi allikas peaaegu kindlasti failis .htaccess. Fail asub saidi juurkataloogis, samas kohas kus wp-config.php ning kaustad wp-content ja wp-includes.

Ühenduge serveriga FTP (FileZilla, WinSCP) või hostingupaneeli failihalduri kaudu:

Leidke .htaccess, paremklõpsake ja nimetage see ümber .htaccess_old-iks. Ärge kustutage faili, see võib sisaldada kriitilisi reegleid nagu HTTP→HTTPS ümbersuunamine või tihendamise seaded:

Pärast ümbernimetamist ei näe WordPress enam vana faili. Minge administraatoripaneeli ja lähtestage püsilingid nagu 1. sammus, süsteem loob uue puhta .htaccess-faili õigete ümberkirjutusreeglitega. Hoidke vana faili varukoopiana alles.

Samm 3. Leia konflikti põhjustav plugin

Kas probleem ilmnes pärast konkreetse plugina paigaldamist? Deaktiveerige see ja lähtestage püsilingid uuesti, tõenäoliselt sellest piisab.

Kui süüdlane on teadmata, kasutage elimineerimismeetodit:

Deaktiveerige kõik pluginad korraga. Lähtestage püsilingid. Kontrollige saiti: kui see töötab, on probleem ühes pluginas. Lubage need ükshaaval, pärast igaühte lähtestades seaded ja kontrollides saiti. Plugin, mille järel lingid uuesti katki lähevad, on põhjus.

Asendage leitud konfliktne plugin alternatiiviga WordPress.org kataloogist. Teavitage probleemist arendajat: sageli on nad ühildumatustest teadlikud ja oskavad soovitada lahendust.

Samm 4. Seadista server: AllowOverride ja mod_rewrite

Kui eelmised sammud ei aidanud ja te kasutate Apachet, võib probleem olla virtuaalhosti seadetes.

Esiteks veenduge, et mod_rewrite moodul on lubatud. Just see muudab „ilusad" URL-id päringuteks, millest WordPress aru saab. Kontrollige ja aktiveerige see käsuga:

1
sudo a2enmod rewrite

Kui moodul oli juba lubatud, kuvatakse hoiatus, see on normaalne. Nüüd taaskäivitage Apache:

1
sudo systemctl restart apache2

CentOS/RHEL puhul on taaskäivitamise käsk erinev:

1
sudo systemctl restart httpd

Teine nõutav komponent on AllowOverride All direktiiv. See lubab .htaccess-failil serveri konfiguratsiooni saidi kataloogi piires üle kirjutada. Avage Apache konfiguratsioonifail: Ubuntus on see /etc/apache2/sites-available/your-site.conf, CentOS-is /etc/httpd/conf/httpd.conf. Leidke <Directory> sektsioon ja viige see järgmisele kujule:

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

Asendage tee /var/www/your-site/ tegeliku teega WordPressi juurkataloogini teie serveris. Pärast muutmist taaskäivitage Apache ülaltoodud käsuga, seejärel lähtestage püsilingid administraatoripaneelis.

Need kaks serveripoolset tegevust, AllowOverride All pluss mod_rewrite, katavad praktiliselt kõik ülejäänud katkiste püsilinkide stsenaariumid Apache puhul.

Video: püsilinkide taastamine samm-sammult

Kui eelistate lugemise asemel vaatamist, siis siin on lühike juhend, mis näitab kogu protsessi alates püsilinkide seadete lähtestamisest kuni .htaccess-faili taastamiseni reaalsel saidil:

⁉️🤔 Korduma kippuvad küsimused

Miks püsib 404 viga ka pärast püsilinkide lähtestamist?

Administraatoripaneeli kaudu lähtestamine kirjutab ümberkirjutusreeglid andmebaasis ümber. Kuid kui .htaccess on füüsiliselt kirjutamiseks ligipääsmatu, valed juurdepääsuõigused, ei saa WordPress faili serveris uuendada. Kontrollige õigusi: tavaliselt on vaja 755 kataloogidele ja 644 failidele. Samuti veenduge, et .htaccess füüsiliselt eksisteerib: pärast ümbernimetamist 2. sammus loob WordPress järgmisel lähtestamisel uue faili. Lähtestamine ise ei muuda olemasolevate postituste URL-e ega riku indekseerimist.

Kas ma võin lihtsalt.htaccess-i kustutada?

Ei. Ilma .htaccess-ita Apache serveris langeb WordPress tagasi „lihtsatele" linkidele nagu ?p=123, see on inetu ja kahjustab SEO-d. Õige järjekord: nimetage vana fail ümber, säilitades varukoopia, seejärel lähtestage püsilinkide seaded administraatoripaneelis. WordPress loob uue .htaccess-faili automaatselt. Ärge kunagi kustutage faili ilma taastamise võimaluseta: see võib sisaldada kriitilisi HTTP→HTTPS ümbersuunamise reegleid või tihendamise seadeid.

Mida teha, kui sait on Nginx-il?

Nginx-il ei ole .htaccess-faili, kõik ümberkirjutusreeglid on kirjutatud serveri konfiguratsiooni. WordPressi standardne plokk: location / { try_files $uri $uri/ /index.php?$args; }. Kontrollige saidi konfiguratsioonifaili (tavaliselt /etc/nginx/sites-available/your-site), lisage see plokk server sektsiooni ja laadige Nginx uuesti: sudo systemctl reload nginx. Sammud 1 ja 3, linkide lähtestamine ja pluginate kontrollimine, töötavad Nginx-i puhul täpselt samamoodi nagu Apache puhul.

Milline plugin põhjustab kõige sagedamini püsilinkide katkiminekut?

Statistiliselt juhivad SEO-pluginad, need manipuleerivad otseselt URL-idega, ja vahemällusalvestuse lahendused: need loovad lehtedest staatilisi koopiaid ja võivad katkise versiooni „meelde jätta". Kolmandal kohal on turvapluginad, mis muudavad .htaccess-faili, et blokeerida kahtlaseid päringuid. Pärast vahemällu salvestava plugina keelamist tühjendage kindlasti brauseri vahemälu või avage sait inkognito režiimis, staatiline vahemällu salvestatud versioon 404 veaga võidakse kuvada isegi pärast parandamist.

Kas ma pean kontrollima andmebaasi terviklikkust?

Harvadel juhtudel on põhjuseks rikutud wp_options tabel, kus hoitakse püsilinkide seadeid. Kui ükski kirjeldatud meetoditest ei aidanud, minge phpMyAdminisse, leidke wp_options tabel ja kontrollige kirjet option_name = 'rewrite_rules'. Kui väärtus näeb välja nagu praht või rikutud serialiseeritud objekt, kustutage see kirje ja seejärel lähtestage püsilinkide seaded administraatoripaneelis. WordPress loob ümberkirjutusreeglid nullist uuesti. Enamik kasutajaid ei vaja seda sammu: valdav enamus probleeme lahendatakse meetoditega 1-3.

Mida teha, kui miski ei aidanud

Oleme läbinud tee lihtsast seadete lähtestamisest Apache ja Nginx serveri konfiguratsioonini. Absoluutse enamuse saitide puhul lahendab üks neist meetoditest probleemi.

Kui 404 vead endiselt püsivad, võtke ühendust oma hostinguteenuse tehnilise toega. Kirjeldage probleemi ja loetlege sammud, mida olete juba teinud. Sageli peitub põhjus hostingukeskkonna eripärades: mod_rewrite on teenusepakkuja tasemel keelatud, mittestandardne PHP-FPM konfiguratsioon või kohandatud tulemüürireeglid, mis blokeerivad päringuid failile index.php. Hostingu tugi näeb serveri poolt, mis on teie eest varjatud, ja lahendab sellised probleemid minutitega.

Peamine reegel, mida tasub meeles pidada: lähtesta püsilingid → nimeta.htaccess ümber → lähtesta uuesti. See kahest tegevusest koosnev järjestus parandab enamiku juhtumeid ega nõua ei eriteadmisi ega serveripääsu. Alustage sellest järgmisel korral ja tõenäoliselt ei pea te kaugemale minema.