Sait ei lase teemat üles laadida, sest fail on liiga suur. Otsingumootorid indekseerivad administraatori lehti, mis ei tohiks tulemustes kuvada. Serveri logid näitavad tundmatutelt IP-delt pärit juurdepääsukatseid failile wp-config.php. Kolm probleemi, üks lahendus: .htaccess fail, mis juba asub teie WordPressi saidi juurkataloogis.

Olete seda ilmselt näinud, kui seadistasite ilusaid püsilinke. Kuid .htaccess võimalused ulatuvad sellest palju kaugemale: see kontrollib juurdepääsu, turvalisust, ümbersuunamisi ja üleslaadimispiiranguid serveri tasemel. Ja erinevalt turvapluginatest ei lisa see PHP-le koormust.

Allpool on neli praktilist stsenaariumi, millega iga WordPressi administraator kokku puutub. Igaüks sisaldab kasutusvalmis koodi, selgitust ja juhiseid selle täpseks paigutamiseks. Kood on kirjutatud Apache 2.4 jaoks (praegune versioon 2026. aasta seisuga), kuid iga näide sisaldab ühilduvusplokki Apache 2.2 jaoks, nii et te ei pea muretsema, kas see teie hostingul töötab.

💡 Kiirülevaade:

• Failide üleslaadimislimiitide suurendamine .htaccess ja .user.ini kaudu PHP-FPM jaoks.
• Otsingumootorite indekseerimise blokeerimine serveri tasemel.
• Kataloogide sirvimise keelamine ühe reaga.
• wp-config.php kaitsmine otsese juurdepääsu eest, kasutades kaasaegset Apache 2.4 süntaksit.

1. Maksimaalse faili üleslaadimismahu suurendamine

Proovite installida teemat või pluginat ja WordPress kuvab veateate: „Üleslaaditud fail ületab php.ini failis määratud upload_max_filesize direktiivi." Paljude hostide vaikimisi limiit on 2 MB või 8 MB ja teie teema arhiiv ei mahu sinna.

Jagatud hostingus ei saa te php.ini redigeerida. Kuid kui Apache töötab mod_php mooduliga, saate limiiti tõsta otse .htaccess kaudu. Avage fail oma saidi juurkataloogis (FTP või hostingu failihalduri kaudu) ja lisage see lõppu:

1
<IfModule mod_php.c>
2
    php_value post_max_size 100M
3
    php_value upload_max_filesize 100M
4
</IfModule>

Esimene direktiiv määrab POST-päringu maksimaalse suuruse, teine määrab ühe üleslaaditava faili maksimaalse suuruse. Mõlemad väärtused peaksid olema võrdsed või post_max_size peaks olema veidi suurem.

Kontrollige tulemust: minge WordPressi administraatori paneeli, Meedia → Lisa uus. Praegune limiit kuvatakse allosas.

Oluline: kui teie host kasutab PHP-FPM-i (mida enamik 2026. aastal teeb), siis php_value direktiivid .htaccess failis ei tööta. Kontrollimiseks: Tööriistad → Saidi tervis → Info → Server. Otsige FPM-i realt „Serveri arhitektuur". Sellise hostingu puhul muutke limiiti saidi juurkataloogis oleva .user.ini faili kaudu:

1
post_max_size = 100M
2
upload_max_filesize = 100M

Vorming on nagu php.ini, võrdusmärkidega, mitte php_value. Muudatused rakenduvad koheselt, serveri taaskäivitust pole vaja. Kui juurkataloogis pole .user.ini faili, looge see.

2. Otsingumootorite indekseerimise blokeerimine

Olukord: testisait alamdomeenil, staging-koopia või sihtleht, mis ei tohiks Google'i ega Yandexi tulemustes ilmuda. Lihtne robots.txt reaga Disallow: / võivad otsingumootorid ignoreerida: see on soovitus, mitte keeld.

Kindel meetod on blokeerida robotid serveri tasemel. Klassikaline lähenemine SetEnvIfNoCase abil töötab Apache 2.4-s ühilduvusmooduli mod_access_compat kaudu, kuid seda peetakse aegunuks. Kaasaegne meetod suunab tühja User-Agentiga robotid ümber mod_rewrite abil:

1
RewriteEngine On
2
RewriteCond %{HTTP_USER_AGENT} (bot|spider|crawler|scanner) [NC]
3
RewriteRule .* - [F,L]

Toimub järgmine: RewriteCond kontrollib iga päringu User-Agenti. Kui see tuvastab märksõnad bot, spider, crawler või scanner (tõstutundetu tänu lipule [NC]), tagastab server veakoodi 403 Forbidden (lipp [F]).

Neljast mustrist piisab kõigi suuremate otsingumootorite blokeerimiseks: Googlebot, YandexBot, Bingbot, Yahoo Slurp ja kümned vähemtuntud. Iga roboti eraldi loetlemine on mõttetu: ainuüksi Google'il on mitukümmend User-Agenti variatsiooni erinevate teenuste jaoks (otsing, pildid, video, AdsBot).

Soovite blokeerida ainult Yandexi, jättes Google'i puutumata? Kitsendage mustrit:

1
RewriteEngine On
2
RewriteCond %{HTTP_USER_AGENT} ^Yandex [NC]
3
RewriteRule .* - [F,L]

Sümbol ^ tähendab „stringi algus". Ilma selleta püüaks reegel kinni ka robotid, mille User-Agenti keskel on yandex.

Oluline: kui WordPress juba kasutab mod_rewrite ilusate püsilinkide jaoks, on RewriteEngine On plokk .htaccess failis juba olemas. Ärge dubleerige seda; lisage lihtsalt uus RewriteCond ja RewriteRule pärast olemasolevaid WordPressi reegleid, kuid enne sulgevat </IfModule> silti.

Pärast muudatuste tegemist kontrollige .htaccess faili vigade suhtes: kirjaviga direktiivides viib saidi 500 veaga alla. Süntaksit saate kontrollida veebivalidaatori või käsuga apachectl configtest (pole kõigil hostidel saadaval). Enne redigeerimist laadige alati alla oma praeguse .htaccess varukoopia.

3. Kataloogide sirvimise keelamine

Minge oma saidile aadressil /wp-content/uploads/. Kui näete 403 vea asemel failide loendit, on kataloogide sirvimine lubatud. See on turvaauk: igaüks saab uurida teie kaustastruktuuri, leida haavatava plugina või lugeda üleslaaditud PDF-dokumenti.

See keelatakse ühe reaga .htaccess failis:

1
Options -Indexes

Lisage see faili algusesse, enne WordPressi reegleid. Nüüd, kui keegi proovib avada kataloogi ilma indeksfailita, tagastab server veakoodi 403 Forbidden.

Enamikul kaasaegsetel hostidel on see valik vaikimisi lubatud, kuid kontrollige igaks juhuks, eriti kui sait on serverite vahel liikunud või töötate VPS-iga, kus Apache oli käsitsi seadistatud.

4. Wp-config.php kaitsmine otsese juurdepääsu eest

wp-config.php on kõige olulisem WordPressi fail. See sisaldab turvavõtmeid, tabeli prefiksit ja andmebaasi volitusi: andmebaasi nime, kasutajat, parooli ja hosti.

Fail ise on kirjutatud PHP-s ja tagastab brauseris otse avamisel tühja lehe, sest WordPressi mootor ei käivita seda. Kuid kui PHP töötlemine on serveris ajutiselt keelatud (konfiguratsioonitõrge, mooduli uuendamine), võidakse wp-config.php sisu serveerida lihttekstina. Koos andmebaasi parooliga.

Blokeerime juurdepääsu .htaccess kaudu. Enamik internetis leiduvaid artikleid pakub aegunud Apache 2.2 süntaksit, mis ei tööta Apache 2.4.6 ja uuemates versioonides. Siin on kaasaegne versioon tagasiühilduvusega:

1
<Files wp-config.php>
2
    # Apache 2.2
3
    <IfModule !mod_authz_core.c>
4
        Order Deny,Allow
5
        Deny from all
6
    </IfModule>
7
 
8
    # Apache 2.4+
9
    <IfModule mod_authz_core.c>
10
        Require all denied
11
    </IfModule>
12
</Files>

IfModule plokk kontrollib mod_authz_core mooduli olemasolu (kasutusele võetud Apache 2.4.6). Kui moodul puudub, rakendub Apache 2.2 süntaks. Kui see on olemas, kasutatakse kaasaegset Require all denied direktiivi. Üks koodiplokk töötab mõlema Apache versiooniga.

Pärast reeglite lisamist saab iga brauseripäring wp-config.php failile vastuseks 403 Forbidden, isegi kui PHP töötleja ei tööta. WordPress pääseb failile ligi otse failisüsteemi kaudu, seega reegel saidi tööd ei mõjuta.

Sama lähenemine kehtib iga konfidentsiaalse faili puhul: asendage wp-config.php vajaliku failinimega, näiteks phpinfo.php või .env.

⁉️🤔 Korduma kippuvad küsimused

Kas ma saan WordPressis üldse ilma.htaccessita hakkama?

Jah, kui teie sait töötab Nginxil, mitte Apache'il. Nginx ei toeta .htaccess faili; kõik reeglid määratakse serveri konfiguratsioonis (nginx.conf või fail kataloogis sites-available/). Jagatud hostingus on peaaegu alati Apache ja .htaccess on saadaval. Nginxiga VPS-is viiakse reeglid server {} sektsiooni: süntaks on erinev, kuid loogika on sama. Näiteks Options -Indexes Nginxi vaste on autoindex off;.

Mida teha, kui sait jookseb pärast.htaccess muutmist 500 veaga kokku?

Taastage kohe .htaccess varukoopia, mille enne redigeerimist tegite (te ju tegite selle?). Looge FTP kaudu ühendus, kustutage muudetud .htaccess ja laadige üles salvestatud originaal. Sait taastub koheselt. 500 viga pärast .htaccess redigeerimist on peaaegu alati põhjustatud kirjaveast direktiivis või konstruktsioonist, mida teie Apache'i versioon ei toeta.

Miks php_value.htaccess failis minu hostingus ei tööta?

Tõenäoliselt kasutab teie host mod_php asemel PHP-FPM-i. Kontrollige: Tööriistad → Saidi tervis → Info → Server. Kui real „Serveri arhitektuur" kuvatakse FPM, ignoreeritakse php_value direktiivi .htaccess failis. Kasutage saidi juurkataloogis .user.ini faili (vt 1. jaotist) või võtke ühendust oma hostingu toega. VPS-is muudetakse limiite PHP-FPM poolis (www.conf), kuid see nõuab serveri konfiguratsioonile juurdepääsu.

Kuidas kontrollida, kas.htaccess tegelikult töötab?

Lihtsaim test on 3. jaotise reegel (Options -Indexes). Külastage /wp-content/uploads/ enne ja pärast selle lisamist. Kas enne oli failide loend ja nüüd on 403 viga? Fail töötab. Teine meetod: lisage .htaccess failile rida tahtliku süntaksiveaga ja avage sait. 500 viga kinnitab, et Apache loeb .htaccess faili. Eemaldage testrida kohe pärast kontrollimist.

Kas selle artikli koodi on turvaline kasutada reaalsel saidil?

Jah, kõik esitatud näited on testitud Apache 2.4-ga (praegune versioon 2026. aasta seisuga) ja sisaldavad ühilduvusplokke Apache 2.2 jaoks. Ainus kohustuslik nõue: enne mis tahes .htaccess redigeerimist laadige faili praegune versioon oma arvutisse alla. See viiesekundiline toiming säästab tunde taastamist kirjavea korral. Ja ärge redigeerige .htaccess faili pluginatega; kasutage ainult FTP-d või oma hostingu failihaldurit: plugin võib lisada escapimise, mis lõhub süntaksi.

Kuidas erineb selles artiklis kirjeldatud wp-config.php kaitsmise lähenemine sellest, mida teised saidid kirjutavad?

Enamik artikleid kopeerib Apache 2.2 süntaksit: Order allow,deny ja Deny from all. Need direktiivid kuuluvad mod_access_compat moodulisse, mis on Apache 2.4-s aegunud ja võib kaasaegsetes serverites olla keelatud. Meie näide kasutab Require all denied moodulist mod_authz_core, mis on praegune standard Apache 2.4.6 ja uuemate versioonide jaoks. Samal ajal säilitab <IfModule> plokk funktsionaalsuse vanematel serveritel.

Mida oma.htaccess konfiguratsioonile kohe lisada

.htaccess fail on kompaktne, kuid võimas. Neljast kirjeldatud tehnikast kaks sulgevad haavatavused minimaalse vaevaga: kataloogide sirvimise keelamine ja wp-config.php kaitsmine. See on üks rida ja üks koodiplokk, mille saate kohe lisada ja need ei mõjuta saidi tööd.

Üleslaadimislimiidi suurendamine aitab iga kord, kui WordPress keeldub teemat või pluginat üles laadimast. Ja indekseerimise blokeerimine serveri tasemel on viimane kaitseliin privaatsetele ja testsaitidele.

Hoidke .htaccess varukoopiat enne iga redigeerimist. Süntaksiviga viib saidi koheselt alla ja see on sama kiiresti parandatav, kui teil on koopia käepärast. Seda reeglit silmas pidades muutub .htaccess hirmutavast failist töötavaks tööriistaks.