WordPress .htaccess Dosyası: Kullanım Rehberi

WordPress kurulumunun kalbinde yatan pek çok dosya vardır ama çoğu kullanıcının varlığından bile haberdar olmadığı, buna rağmen sitenin ayakta kalmasında kritik rol oynayan bir tanesi öne çıkar: .htaccess. Adının başındaki nokta, onu FTP istemcilerinde ve dosya yöneticilerinde varsayılan olarak gizler. Tam da bu görünmezlik yüzünden, çoğu sorun ancak bir şeyler ters gittiğinde — kalıcı bağlantılar bozulduğunda, yazılar 404 verdiğinde ya da site aniden 500 hatası döndürdüğünde — fark edilir.

Bu rehberde .htaccess dosyasının ne işe yaradığını, varsayılan WordPress kurallarının satır satır ne anlama geldiğini, güvenlik ve performans için hangi eklemeleri güvenle yapabileceğinizi ve en sık karşılaşılan hataları nasıl çözeceğinizi tek tek ele alacağız. Amacımız, bu dosyayı korkulacak bir şey olmaktan çıkarıp bilinçli kullanabileceğiniz bir araca dönüştürmek.

.htaccess Dosyası Nedir ve Ne İşe Yarar?

.htaccess, “hypertext access” ifadesinin kısaltmasıdır ve Apache web sunucusuna ait dizin düzeyinde bir yapılandırma dosyasıdır. Ana sunucu yapılandırmasını değiştirmeden, yalnızca bulunduğu klasör ve alt klasörler için özel kurallar tanımlamanıza olanak tanır. WordPress, sunucu genelinde yönetici yetkisi gerektirmeden URL’leri yeniden yazabilmek için bu mekanizmadan yararlanır.

Burada önemli bir ayrımın altını çizmek gerekir: .htaccess yalnızca Apache (ve büyük ölçüde uyumlu olan LiteSpeed) sunucularında geçerlidir. Eğer siteniz saf Nginx üzerinde çalışıyorsa, .htaccess dosyası hiçbir işe yaramaz; kurallar Nginx’in kendi yapılandırma bloklarına taşınır. Alastyr altyapısında olduğu gibi LiteSpeed web sunucusu kullanıldığında ise .htaccess sözdizimi Apache ile büyük oranda uyumludur, dolayısıyla bu rehberdeki kuralların ezici çoğunluğu doğrudan çalışır.

.htaccess ile yapabileceğiniz başlıca işler şunlardır:

• URL yeniden yazma: Kalıcı bağlantıların “temiz” görünmesini sağlar (ör. ?p=123 yerine /blog/htaccess-rehberi).
• Yönlendirmeler: 301 ve 302 yönlendirmeleriyle eski adresleri yenilerine bağlar, HTTP→HTTPS geçişi yapar.
• Erişim kontrolü: Belirli dosya veya dizinlere erişimi IP’ye ya da kimlik doğrulamaya göre kısıtlar.
• Güvenlik sertleştirmesi: Hassas dosyaları gizler, dizin listelemesini kapatır.
• Performans: Tarayıcı önbellekleme ve GZIP sıkıştırma başlıkları tanımlar.

WordPress Varsayılan .htaccess Bloğu

WordPress, Ayarlar → Kalıcı Bağlantılar sayfasında “Değişiklikleri Kaydet” düğmesine bastığınızda kök dizine standart bir .htaccess bloğu ekler. Kurulum kök dizinde ise dosya genellikle wp-admin ve wp-content klasörlerinin yanında yer alır. WordPress 6.9 ve sonrası dahil olmak üzere bu blok yıllardır geriye dönük uyumludur ve şöyle görünür:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Bu satırların her biri belirli bir görevi yerine getirir:

Satır	Anlamı
# BEGIN / # END WordPress	WordPress’in kendi yönettiği bölgenin sınırlarını işaretler. Bu iki yorum arasına elle yazdığınız her şey, ayarlar yeniden kaydedildiğinde silinebilir.
<IfModule mod_rewrite.c>	Kuralları yalnızca mod_rewrite modülü etkinse çalıştırır; modül yoksa hata vermez, kuralları atlar.
RewriteEngine On	URL yeniden yazma motorunu devreye alır.
RewriteBase /	Yeniden yazma kuralları için temel yolu belirler. Kök dizinde “/”, alt dizinde ise “/klasoradi/” olur.
RewriteRule ^index.php$ – [L]	index.php’ye doğrudan gelen istekleri olduğu gibi bırakır ve işlemi sonlandırır.
RewriteCond … !-f / !-d	İstenen adres gerçek bir dosya (-f) veya dizin (-d) değilse koşulu sağlar. Yani var olan görseller ve CSS dosyaları yeniden yazılmaz.
RewriteRule . /index.php [L]	Geri kalan tüm istekleri WordPress’in ana giriş noktası olan index.php’ye yönlendirir. WordPress’in “güzel URL” sihri buradan gelir.

Bu bloğu doğrudan düzenlemenizi tavsiye etmiyorum. Ek kurallar eklemek istiyorsanız, onları her zaman # END WordPress satırının altına yazın. Böylece kalıcı bağlantıları her kaydettiğinizde WordPress kendi bloğunu güncellese bile, sizin eklediğiniz satırlar korunur.

Dosya Nerede ve Nasıl Düzenlenir?

.htaccess dosyası WordPress kurulumunuzun kök dizinindedir. Ona üç yoldan ulaşabilirsiniz:

• cPanel / Plesk / DirectAdmin dosya yöneticisi: Kontrol panelinizin dosya yöneticisinde “gizli dosyaları göster” seçeneğini işaretleyerek dosyayı görüntüleyip düzenleyebilirsiniz.
• FTP / SFTP istemcisi: FileZilla gibi bir istemcide gizli dosyaların gösterilmesini etkinleştirin, dosyayı bilgisayarınıza indirin, düzenleyin ve geri yükleyin.
• SSH ile: Sunucuya SSH erişiminiz varsa nano ya da vim gibi bir düzenleyiciyle doğrudan müdahale edebilirsiniz.

Hangi yöntemi seçerseniz seçin, tek bir altın kural var: düzenleme öncesi mutlaka bir yedek alın. Dosyanın bir kopyasını .htaccess.bak olarak saklayın. Tek bir yazım hatası bile tüm siteyi “500 Internal Server Error” ile çökertebileceğinden, hata durumunda yedeği geri yüklemek sizi dakikalar içinde kurtarır.

Güvenlik İçin .htaccess Kuralları

.htaccess, WordPress sertleştirmesinin en pratik araçlarından biridir. Aşağıdaki kuralları # END WordPress satırının altına ekleyerek yaygın saldırı yüzeylerini kapatabilirsiniz. Modern sunucular Apache 2.4 kullandığından, örneklerde güncel Require sözdizimini tercih ediyorum; eski “Order allow,deny” yapısı artık kullanımdan kaldırılmaya aday olduğu için bundan kaçınmanızı öneririm.

wp-config.php Dosyasını Koruyun

Veritabanı kullanıcı adı ve parolasını barındıran wp-config.php, sitedeki en hassas dosyadır. Doğrudan erişimi tamamen kapatın:

<Files wp-config.php>
Require all denied
</Files>

Dizin Listelemesini Kapatın

Bir klasörde index dosyası yoksa, Apache varsayılan olarak klasör içeriğini listeler. Bu, saldırganlara sitenizin yapısı hakkında bilgi sızdırır. Tek satırla engelleyin:

Options -Indexes

xmlrpc.php Üzerinden Yapılan Saldırıları Durdurun

xmlrpc.php, kaba kuvvet ve DDoS amplifikasyon saldırılarında sıkça kötüye kullanılır. Uzaktan yayın veya Jetpack gibi hizmetleri kullanmıyorsanız erişimi kapatabilirsiniz:

<Files xmlrpc.php>
Require all denied
</Files>

Nokta ile Başlayan Gizli Dosyaları Koruyun

.htaccess’in kendisi dahil, nokta ile başlayan yapılandırma dosyalarının dışarıdan okunmasını engelleyin:

<FilesMatch "^.">
Require all denied
</FilesMatch>

wp-content İçinde PHP Çalıştırmayı Engelleyin

Yüklemeler klasörüne sızdırılan zararlı bir PHP dosyasının çalıştırılmasını önlemek için, wp-content/uploads dizinine ayrı bir .htaccess ekleyip PHP yürütmesini kapatabilirsiniz:

<FilesMatch ".(php|php7|phtml)$">
Require all denied
</FilesMatch>

Bu tür kurallar iyi bir ilk savunma hattıdır; ancak .htaccess tek başına bir güvenlik duvarının yerini tutmaz. Alastyr sunucularında, uygulama düzeyindeki bu tedbirlerin ötesinde Imunify360 ve CageFS ile çift katmanlı WAF ve hesap izolasyonu, ağ katmanında ise Voxility 1 Tbps üzeri L3-L4 anti-DDoS koruması devreye girer. Yani .htaccess ile sitenizi sertleştirirken, altta çalışan altyapı da sizi kritik saldırı türlerine karşı korumaya devam eder.

Performans İçin .htaccess Kuralları

.htaccess yalnızca güvenlik değil, sayfa hızı için de kullanılır. İki temel teknik öne çıkar: tarayıcı önbellekleme ve GZIP sıkıştırma.

Tarayıcı Önbellekleme (Expires Başlıkları)

Görsel, CSS ve JavaScript gibi statik dosyaların ziyaretçinin tarayıcısında saklanma süresini belirleyerek tekrarlayan istekleri azaltır:

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
</IfModule>

GZIP Sıkıştırma

Metin tabanlı dosyaları sunucudan gönderilmeden önce sıkıştırarak dosya boyutunu tipik olarak %70-80 oranında küçültür:

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/css application/javascript
</IfModule>

Burada önemli bir not: Alastyr’ın kullandığı LiteSpeed + LSCache altyapısında, önbellekleme ve sıkıştırma zaten sunucu düzeyinde ve daha verimli biçimde ele alınır. Bu durumda .htaccess’e elle önbellek kuralları eklemek çoğu zaman gereksiz, hatta çakışmaya yol açabilecek bir işlemdir. LSCache eklentisi bu ayarları sizin yerinize yönetir; dolayısıyla LiteSpeed üzerinde çalışıyorsanız önce eklentinizin sunduğu seçenekleri değerlendirmeniz daha doğru olur.

Yönlendirmeler ve HTTPS Zorlaması

.htaccess, SEO açısından kritik olan yönlendirmeleri yönetmenin de standart yoludur. Kalıcı olarak taşınan bir adresi 301 ile yeni adrese bağlamak, hem ziyaretçiyi hem de arama motorlarını doğru yere iletir:

Redirect 301 /eski-sayfa /yeni-sayfa

Tüm trafiği HTTPS’e zorlamak isterseniz — ki günümüzde bu bir zorunluluktur — şu kuralı kullanabilirsiniz:

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

WordPress kalitesinde bir barındırmada SSL sertifikası genellikle ücretsiz sağlanır ve otomatik yenilenir. Alastyr’da tüm paketlerde ücretsiz SSL standart olarak sunulur; yine de özel doğrulamalı veya kuruluş onaylı sertifika ihtiyaçları için SSL sertifikası seçeneklerine göz atabilirsiniz.

Sık Karşılaşılan .htaccess Hataları

Belirti	Olası Neden ve Çözüm
Ana sayfa açılıyor ama iç sayfalar 404	Kalıcı bağlantı kuralları eksik. Ayarlar → Kalıcı Bağlantılar sayfasında “Değişiklikleri Kaydet” ile bloğu yeniden oluşturun.
500 Internal Server Error	.htaccess’te sözdizimi hatası ya da desteklenmeyen bir modül. Yedeği geri yükleyin veya dosyayı geçici olarak yeniden adlandırın.
Değişiklikler etkisiz kalıyor	Sunucuda AllowOverride kapalı olabilir ya da LiteSpeed önbelleği devrede. Barındırma sağlayıcınıza danışın.
Dosya hiç görünmüyor	Gizli dosya olduğu için dosya yöneticisinde “gizli dosyaları göster” seçeneğini açın; yoksa kalıcı bağlantıları kaydederek oluşturun.

Bu hataların çoğu, dosyanın gizliliğinden ve tek bir hatalı satırın tüm siteyi etkileyebilmesinden kaynaklanır. Düzenli yedekleme ve dikkatli düzenleme, sorunların büyük bölümünü baştan önler. Alastyr’da günlük otomatik yedekleme standart olduğu için, .htaccess kaynaklı bir aksaklıkta önceki günün sürümüne dönmek her zaman mümkündür.

Doğru Barındırma, .htaccess Deneyimini Belirler

.htaccess’in ne kadar sorunsuz çalışacağı büyük ölçüde altındaki barındırma altyapısına bağlıdır. Modüllerin (mod_rewrite, mod_deflate, mod_expires) etkin olması, AllowOverride ayarlarının izin vermesi ve sunucunun güncel bir Apache/LiteSpeed sürümünde çalışması, yazdığınız kuralların çalışıp çalışmayacağını doğrudan etkiler.

Alastyr’ın WordPress hosting ve genel hosting paketlerinde LiteSpeed + LSCache, CloudLinux + CageFS ve PHP sürüm seçici hazır gelir; İzmir’deki kendi veri merkezinde, N+1 yedekli, Tier III standartlarında bir altyapıda barındırılır. Bu ortam, .htaccess ile yapacağınız her düzenlemenin öngörülebilir ve güvenli biçimde işlemesini sağlar. Daha fazla kaynağa ve tam yönetim özgürlüğüne ihtiyaç duyanlar ise VPS sunucu ya da bulut sunucu seçenekleriyle Apache/LiteSpeed yapılandırmasının tamamına doğrudan hakim olabilir.

Sıkça Sorulan Sorular

.htaccess dosyasını silersem ne olur?

Dosyayı silerseniz WordPress’in kalıcı bağlantıları çalışmaz ve iç sayfalar 404 hatası verir. Ancak dosya kalıcı olarak kaybolmaz: Ayarlar → Kalıcı Bağlantılar sayfasına gidip “Değişiklikleri Kaydet” düğmesine bastığınızda WordPress varsayılan bloğu yeniden oluşturur. Elle eklediğiniz özel kurallar ise geri gelmez, bu yüzden düzenleme öncesi yedek almanız önemlidir.

.htaccess dosyasını neden göremiyorum?

Dosya adı bir nokta ile başladığı için Unix tabanlı sistemlerde gizli dosya sayılır ve FTP istemcileri ile dosya yöneticilerinde varsayılan olarak görünmez. Kontrol panelinizin dosya yöneticisinde ya da FTP istemcinizde “gizli dosyaları göster” seçeneğini etkinleştirdiğinizde dosya görünür hale gelir.

Değişikliklerimi neden # BEGIN WordPress bloğunun dışına yazmalıyım?

WordPress, kalıcı bağlantıları her kaydettiğinizde # BEGIN WordPress ve # END WordPress yorumları arasındaki içeriği kendi kurallarıyla yeniden yazar. Bu bloğun içine eklediğiniz özel satırlar bu sırada silinir. Kurallarınızı # END WordPress satırının altına yazarsanız kalıcı olurlar.

.htaccess Nginx sunucularında çalışır mı?

Hayır. .htaccess yalnızca Apache ve büyük oranda uyumlu olan LiteSpeed web sunucularında geçerlidir. Saf Nginx üzerinde çalışan sitelerde bu dosya dikkate alınmaz; aynı kuralların Nginx’in kendi yapılandırma bloklarına taşınması gerekir. Alastyr LiteSpeed kullandığından, Apache söz dizimindeki kuralların ezici çoğunluğu doğrudan çalışır.

“Order allow,deny” mi yoksa “Require” mi kullanmalıyım?

Modern sunucular Apache 2.4 kullanır ve bu sürümde “Order”, “Allow”, “Deny” direktifleri kullanımdan kaldırılmaya aday olarak işaretlenmiştir. Yeni kurallar yazarken güncel “Require all denied” veya “Require all granted” sözdizimini tercih etmeniz önerilir. Eski ve yeni direktifleri aynı dosyada karıştırmaktan kaçının.

.htaccess düzenlemesi sonrası sitem 500 hatası verdi, ne yapmalıyım?

Bu hata neredeyse her zaman .htaccess’teki bir sözdizimi hatasından ya da sunucuda desteklenmeyen bir modülden kaynaklanır. Aldığınız yedeği geri yükleyin; yedek yoksa dosyayı geçici olarak .htaccess_eski gibi yeniden adlandırıp siteyi ayağa kaldırın, ardından son eklediğiniz satırları tek tek gözden geçirin.

LiteSpeed kullanıyorsam önbellek kurallarını elle eklemeli miyim?

Genellikle gerek yoktur. LiteSpeed ve LSCache, önbellekleme ile sıkıştırmayı sunucu düzeyinde ve daha verimli biçimde yönetir. Elle eklenen mod_expires veya mod_deflate kuralları çoğu zaman gereksizdir, hatta çakışmaya yol açabilir. Önce LSCache eklentisinin sunduğu ayarları değerlendirmeniz daha doğru olur.

.htaccess tek başına sitemi güvende tutar mı?

Hayır. .htaccess ile yapılan sertleştirme değerli bir ilk savunma hattıdır, ancak tam bir güvenlik çözümü değildir. Kapsamlı koruma için uygulama düzeyinde bir WAF, hesap izolasyonu ve ağ katmanında anti-DDoS gibi katmanlara ihtiyaç vardır. Alastyr altyapısında Imunify360, CageFS ve Voxility anti-DDoS bu katmanları .htaccess’in ötesinde tamamlar.

Yükleme klasöründe PHP çalıştırmayı engellemek güvenli mi?

Evet, wp-content/uploads gibi kullanıcı yüklemelerinin bulunduğu dizinlerde PHP yürütmesini kapatmak yaygın ve güvenli bir uygulamadır. Bu klasörlerde normalde çalıştırılabilir PHP dosyası bulunmaz; bu yüzden PHP yürütmesini engellemek, oraya sızdırılabilecek zararlı bir dosyanın çalıştırılmasını önler ve meşru işleyişi bozmaz.