Sivusto ei anna ladata teemaa, koska tiedosto on liian suuri. Hakukoneet indeksoivat ylläpitosivuja, joiden ei pitäisi näkyä tuloksissa. Palvelinlokit näyttävät pääsy-yrityksiä wp-config.php-tiedostoon tuntemattomista IP-osoitteista. Kolme ongelmaa, yksi ratkaisu: .htaccess-tiedosto, joka on jo WordPress-sivustosi juurihakemistossa.

Olet todennäköisesti nähnyt sen, kun määritit selkeitä permalinkkejä. Mutta .htaccess-tiedoston ominaisuudet ulottuvat paljon pidemmälle: se hallitsee pääsyä, tietoturvaa, uudelleenohjauksia ja latausrajoituksia palvelintasolla. Ja toisin kuin tietoturvalisäosat, se ei lisää kuormaa PHP:lle.

Alla on neljä käytännön skenaariota, joita jokainen WordPress-ylläpitäjä kohtaa. Jokainen sisältää valmiin koodin, selityksen ja ohjeet siitä, mihin kohtaan se tarkalleen lisätään. Koodi on kirjoitettu Apache 2.4:lle (nykyinen versio vuonna 2026), mutta jokainen pätkä sisältää yhteensopivuuslohkon Apache 2.2:lle, joten sinun ei tarvitse miettiä, toimiiko se hostingissasi.

💡 Pikakatsaus:

• Nosta tiedostojen latausrajoituksia .htaccess- ja .user.ini-tiedostojen kautta PHP-FPM:ää varten.
• Estä hakukoneindeksointi palvelintasolla.
• Poista hakemistoselaus käytöstä yhdellä rivillä.
• Suojaa wp-config.php suoralta pääsyltä modernilla Apache 2.4 -syntaksilla.

1. Tiedoston enimmäislatauskoon kasvattaminen

Yrität asentaa teemaa tai lisäosaa, ja WordPress antaa virheen: "The uploaded file exceeds the upload_max_filesize directive in php.ini." Monen hostingin oletusraja on 2 Mt tai 8 Mt, eikä teema-arkistosi mahdu siihen.

Et voi muokata php.ini-tiedostoa jaetulla hostingilla. Mutta jos Apache toimii mod_php-moduulilla, voit nostaa rajaa suoraan .htaccess-tiedostosta. Avaa tiedosto sivustosi juuressa (FTP:n tai hostingin tiedostonhallinnan kautta) ja lisää tämä loppuun:

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

Ensimmäinen direktiivi asettaa POST-pyynnön enimmäiskoon, toinen yksittäisen ladattavan tiedoston enimmäiskoon. Molempien arvojen tulisi olla samat, tai post_max_size-arvon tulisi olla hieman suurempi.

Tarkista tulos: mene WordPressin hallintapaneeliin, Media → Lisää uusi. Nykyinen raja näkyy alareunassa.

Tärkeää: jos hostisi käyttää PHP-FPM:ää (mitä useimmat käyttävät vuonna 2026), .htaccess-tiedoston php_value-direktiivit eivät toimi. Tarkista: Työkalut → Sivuston kunto → Tiedot → Palvelin. Etsi FPM "Palvelinarkkitehtuuri"-riviltä. Tällaisessa hostingissa muuta rajaa sivuston juuressa olevan .user.ini-tiedoston kautta:

1
post_max_size = 100M
2
upload_max_filesize = 100M

Muoto on kuin php.ini-tiedostossa, käytössä on yhtäsuuruusmerkit php_value-merkinnän sijaan. Muutokset tulevat voimaan välittömästi ilman palvelimen uudelleenkäynnistystä. Jos juuressa ei ole .user.ini-tiedostoa, luo sellainen.

2. Hakukoneindeksoinnin estäminen

Tilanne: testisivusto alidomainissa, staging-kopio tai laskeutumissivu, jonka ei pitäisi näkyä Googlen tai Yandexin tuloksissa. Yksinkertainen robots.txt, jossa on Disallow: /, voidaan jättää huomiotta hakukoneissa: se on suositus, ei kielto.

Varma tapa on estää botit palvelintasolla. Klassinen lähestymistapa, jossa käytetään SetEnvIfNoCase-direktiiviä, toimii Apache 2.4:ssä yhteensopivuusmoduulin mod_access_compat kautta, mutta sitä pidetään vanhentuneena. Moderni menetelmä ohjaa botit, joilla on tyhjä User-Agent, uudelleen mod_rewrite-moduulin avulla:

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

Tässä on mitä tapahtuu: RewriteCond tarkistaa jokaisen pyynnön User-Agentin. Kun se havaitsee avainsanat bot, spider, crawler tai scanner (kirjainkoosta riippumatta [NC]-lipun ansiosta), palvelin palauttaa 403 Forbidden -virheen ([F]-lippu).

Neljä mallia riittää estämään kaikki suuret hakukoneet: Googlebot, YandexBot, Bingbot, Yahoo Slurp ja kymmenet vähemmän tunnetut. Jokaisen botin listaaminen erikseen on turhaa: pelkällä Googlella on useita kymmeniä User-Agent-muunnelmia eri palveluille (haku, kuvat, video, AdsBot).

Haluatko estää vain Yandexin ja jättää Googlen rauhaan? Kavenna mallia:

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

^-symboli tarkoittaa "merkkijonon alkua". Ilman sitä sääntö koskisi myös botteja, joiden User-Agentissa on yandex jossain keskellä.

Tärkeää: jos WordPress käyttää jo mod_rewrite-moduulia selkeisiin permalinkkeihin, RewriteEngine On -lohko on jo .htaccess-tiedostossa. Älä kopioi sitä; lisää vain uudet RewriteCond- ja RewriteRule-rivit olemassa olevien WordPress-sääntöjen jälkeen, mutta ennen sulkevaa </IfModule>-tagia.

Tarkista .htaccess-tiedosto muutosten jälkeen virheiden varalta: kirjoitusvirhe direktiiveissä kaataa sivuston 500-virheellä. Voit tarkistaa syntaksin online-validaattorilla tai apachectl configtest -komennolla (ei saatavilla kaikilla hosteilla). Lataa aina varmuuskopio nykyisestä .htaccess-tiedostostasi ennen muokkaamista.

3. Hakemistoselauksen poistaminen käytöstä

Mene sivustollesi osoitteeseen /wp-content/uploads/. Jos 403-virheen sijaan näet tiedostolistauksen, hakemistoselaus on käytössä. Tämä on tietoturva-aukko: kuka tahansa voi tutkia kansiorakennettasi, löytää haavoittuvan lisäosan tai lukea ladatun PDF-dokumentin.

Se poistetaan käytöstä yhdellä rivillä .htaccess-tiedostossa:

1
Options -Indexes

Lisää se tiedoston alkuun, ennen WordPress-sääntöjä. Nyt kun joku yrittää avata hakemiston, jossa ei ole index-tiedostoa, palvelin palauttaa 403 Forbidden -virheen.

Useimmilla nykyaikaisilla hosteilla tämä asetus on oletuksena käytössä, mutta tarkista silti, varsinkin jos sivusto on siirretty palvelimelta toiselle tai työskentelet VPS:n kanssa, jossa Apache on määritetty manuaalisesti.

4. Wp-config.php-tiedoston suojaaminen suoralta pääsyltä

wp-config.php on WordPressin tärkein tiedosto. Se sisältää tietoturva-avaimet, tietokantataulujen etuliitteen ja tietokantatunnukset: tietokannan nimen, käyttäjän, salasanan ja palvelimen.

Itse tiedosto on kirjoitettu PHP:llä ja palauttaa tyhjän sivun, kun se avataan suoraan selaimessa, koska WordPress-moottori ei suorita sitä. Mutta jos PHP-käsittely on tilapäisesti pois käytöstä palvelimella (määritysvirhe, moduulipäivitys), wp-config.php-tiedoston sisältö voitaisiin tarjota raakatekstinä. Tietokannan salasanan kera.

Estämme pääsyn .htaccess-tiedoston kautta. Useimmat internetin artikkelit tarjoavat vanhentunutta Apache 2.2 -syntaksia, joka ei toimi Apache 2.4.6:ssa ja sitä uudemmissa. Tässä on moderni versio taaksepäin yhteensopivuudella:

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-lohko tarkistaa mod_authz_core-moduulin (joka esiteltiin Apache 2.4.6:ssa) olemassaolon. Jos moduuli puuttuu, käytetään Apache 2.2 -syntaksia. Jos se on läsnä, käytetään modernia Require all denied -direktiiviä. Yksi koodilohko toimii molemmissa Apache-versioissa.

Sääntöjen lisäämisen jälkeen mikä tahansa selainpyyntö wp-config.php-tiedostoon saa 403 Forbidden -vastauksen, vaikka PHP-käsittelijä ei toimisi. WordPress käyttää tiedostoa suoraan tiedostojärjestelmän kautta, joten sääntö ei vaikuta sivuston toimintaan.

Samaa lähestymistapaa voidaan soveltaa mihin tahansa luottamukselliseen tiedostoon: korvaa wp-config.php tarvitsemallasi tiedostonimellä, kuten phpinfo.php tai .env.

⁉️🤔 Usein kysytyt kysymykset

Pärjääkö WordPressissä ilman.htaccessia?

Kyllä, jos sivustosi toimii Nginxillä Apachen sijaan. Nginx ei tue .htaccess-tiedostoa; kaikki säännöt asetetaan palvelimen määrityksissä (nginx.conf tai tiedosto sites-available/-kansiossa). Jaetulla hostingilla kyseessä on lähes aina Apache, ja .htaccess on käytettävissä. VPS:llä, jossa on Nginx, säännöt siirretään server {} -osioon: syntaksi on erilainen, mutta logiikka on sama. Esimerkiksi Nginx-vastine Options -Indexes -direktiiville on autoindex off;.

Mitä teen, jos sivusto kaatuu 500-virheellä.htaccess-tiedoston muuttamisen jälkeen?

Palauta välittömästi .htaccess-tiedoston varmuuskopio, jonka teit ennen muokkaamista (teithän sellaisen?). Yhdistä FTP:llä, poista muokattu .htaccess ja lataa tallennettu alkuperäinen. Sivusto palautuu heti. 500-virhe .htaccess-tiedoston muokkaamisen jälkeen johtuu lähes aina kirjoitusvirheestä direktiivissä tai rakenteesta, jota Apache-versiosi ei tue.

Miksi php_value.htaccess-tiedostossa ei toimi hostingissani?

Todennäköisesti hostisi käyttää PHP-FPM:ää mod_php:n sijaan. Tarkista: Työkalut → Sivuston kunto → Tiedot → Palvelin. Jos FPM näkyy "Palvelinarkkitehtuuri"-rivillä, .htaccess-tiedoston php_value-direktiivit jätetään huomiotta. Käytä .user.ini-tiedostoa sivuston juuressa (katso osio 1) tai ota yhteyttä hosting-tukeen. VPS:llä rajoja muutetaan PHP-FPM-poolissa (www.conf), mutta tämä vaatii palvelimen määritysoikeudet.

Miten varmistan, että.htaccess todella toimii?

Yksinkertaisin testi on osion 3 sääntö (Options -Indexes). Vieraile osoitteessa /wp-content/uploads/ ennen sen lisäämistä ja sen jälkeen. Oliko siellä tiedostolistaus ennen, ja nyt 403-virhe? Tiedosto toimii. Toinen tapa: lisää .htaccess-tiedostoon rivi, jossa on tahallinen syntaksivirhe, ja avaa sivusto. 500-virhe vahvistaa, että Apache lukee .htaccess-tiedostoa. Poista testirivi välittömästi tarkistuksen jälkeen.

Onko turvallista käyttää tämän artikkelin koodia tuotantosivustolla?

Kyllä, kaikki annetut koodinpätkät on testattu Apache 2.4:llä (nykyinen versio vuonna 2026) ja ne sisältävät yhteensopivuuslohkot Apache 2.2:lle. Ainoa pakollinen vaatimus: ennen jokaista .htaccess-muokkausta lataa tiedoston nykyinen versio tietokoneellesi. Tämä viiden sekunnin toimenpide säästää tunteja palauttamisessa kirjoitusvirheen sattuessa. Äläkä muokkaa .htaccess-tiedostoa lisäosien kautta; käytä vain FTP:tä tai hostingin tiedostonhallintaa: lisäosa saattaa lisätä escapauksen, joka rikkoo syntaksin.

Miten tämän artikkelin lähestymistapa wp-config.php:n suojaamiseen eroaa siitä, mitä muilla sivustoilla kirjoitetaan?

Useimmat artikkelit kopioivat Apache 2.2 -syntaksia: Order allow,deny ja Deny from all. Nämä direktiivit kuuluvat mod_access_compat-moduuliin, joka on vanhentunut Apache 2.4:ssä ja saatetaan poistaa käytöstä nykyaikaisilla palvelimilla. Meidän koodinpätkämme käyttää Require all denied -direktiiviä mod_authz_core-moduulista, joka on nykyinen standardi Apache 2.4.6:lle ja sitä uudemmille. Samalla <IfModule>-lohko säilyttää toiminnallisuuden vanhemmilla palvelimilla.

Mitä lisätä.htaccess-määritykseesi juuri nyt

.htaccess-tiedosto on kompakti mutta tehokas. Neljästä kuvatusta tekniikasta kaksi sulkee haavoittuvuuksia minimaalisella vaivalla: hakemistoselauksen poistaminen käytöstä ja wp-config.php-tiedoston suojaaminen. Se on yksi rivi ja yksi koodilohko, jotka voit lisätä heti, eivätkä ne vaikuta sivuston toimintaan.

Latausrajan nostaminen auttaa aina, kun WordPress kieltäytyy lataamasta teemaa tai lisäosaa. Ja indeksoinnin estäminen palvelintasolla on viimeinen puolustuslinja yksityisille ja testisivustoille.

Pidä varmuuskopio .htaccess-tiedostosta ennen jokaista muokkausta. Syntaksivirhe kaataa sivuston välittömästi, ja se korjataan yhtä välittömästi, jos sinulla on kopio käsillä. Tämä sääntö mielessä .htaccess muuttuu pelottavasta tiedostosta toimivaksi työkaluksi.