.htaccess Dosyası WordPress İçin Ne İşe Yarar?
Apache tabanlı hosting ortamlarında .htaccess, dizin bazında sunucu davranışını değiştirmek için kullanılan bir yapılandırma dosyasıdır. WordPress kurulumlarında bu dosyanın en kritik görevi, gelen istekleri index.php üzerinden WordPress'in yönlendirme (routing) mantığına aktarmaktır. Bu sayede WordPress, /2026/07/yazi-basligi/ gibi okunabilir bir adresi doğru içerikle eşleştirebilir. Bu işlevi sağlayan bölüm, dosyanın içinde # BEGIN WordPress ile # END WordPress arasında yer alır.
BEGIN/END WordPress Bloğu Nedir?
Bu iki işaret arasındaki bölüm, elle yazılmış bir öneri değil; WordPress çekirdeğinin kendisinin ürettiği gerçek koddur. Yönetim panelinde Ayarlar → Kalıcı Bağlantılar (Permalinks) sayfasını her kaydettiğinizde, dosya yazılabilir durumdaysa WordPress bu bloğu otomatik olarak yeniden üretir. Standart, tekli bir WordPress kurulumunda blok şu şekildedir:
# 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 WordPressBu blok bir eklenti tarafından bozulduysa, yanlışlıkla silindiyse ya da bir sunucu taşıma sırasında kayboldsa, wp-admin'e girip Kalıcı Bağlantılar sayfasını yeniden kaydetmeye gerek kalmadan, yukarıdaki metni doğrudan .htaccess dosyasına yapıştırmak aynı sonucu verir.
Pretty Permalink'ler Neden mod_rewrite Gerektirir?
WordPress'in varsayılan bağlantı yapısı ?p=123 gibi bir sorgu dizesi (query string) kullanır; bu adresler doğrudan PHP tarafından işlenir ve herhangi bir yeniden yazma kuralına ihtiyaç duymaz. Ancak Kalıcı Bağlantılar ayarından "Yazı adı" gibi okunabilir bir yapı seçildiğinde, sunucunun /2026/07/yazi-basligi/ gibi bir adresi fiziksel bir dosya veya dizin olarak aramadan doğrudan index.php'ye yönlendirmesi gerekir. Bunu sağlayan Apache modülü mod_rewrite'tır; BEGIN/END WordPress bloğundaki RewriteCond ve RewriteRule satırları tam olarak bu işi yapar: istenen adres gerçek bir dosya veya dizine karşılık gelmiyorsa (!-f, !-d), isteği index.php'ye aktarır ve WordPress kalan işi kendi içinde çözer.
Örnek: Bir İsteğin index.php'ye Ulaşması
Yukarıdaki bloğun pratikte ne yaptığını somutlaştırmak için bir istek örneği üzerinden gidelim. Bir ziyaretçi ornek.com/2026/07/yazi-basligi/ adresini açtığında sunucu üzerinde bu isimde ne fiziksel bir dosya ne de bir dizin bulunur. RewriteCond %{REQUEST_FILENAME} !-f ve RewriteCond %{REQUEST_FILENAME} !-d satırları tam olarak bunu kontrol eder: istenen yol gerçek bir dosyaya (!-f) ya da dizine (!-d) karşılık gelmiyorsa, hemen altındaki RewriteRule . /index.php [L] satırı devreye girer ve isteği index.php'ye yönlendirir. Bu noktadan sonra WordPress'in kendi içindeki sorgu ayrıştırıcısı (query parser), URL'deki tarih ve yazı adı bilgisini okuyarak doğru içeriği veritabanından çeker. Eğer istenen dosya gerçekten sunucuda varsa, örneğin /wp-content/uploads/gorsel.jpg gibi statik bir dosyaysa, bu koşullar sağlanmadığı için istek doğrudan o dosyaya gider ve WordPress hiç devreye girmez.
Multisite: Alt Dizin mi, Alt Alan Adı mı?
WordPress Multisite kurulumlarında .htaccess kuralları, ağdaki alt sitelerin nasıl adreslendiğine göre farklılaşır. İki yaygın yöntem vardır: alt dizin (ornek.com/site2/) ve alt alan adı (site2.ornek.com).
| Özellik | Alt Dizin (Subdirectory) | Alt Alan Adı (Subdomain) |
|---|---|---|
| Site adresi örneği | ornek.com/site2/ | site2.ornek.com |
| Alt site ayrımı nasıl yapılır | .htaccess kurallarındaki ek yakalama grupları ile | DNS/vhost seviyesinde, .htaccess'ten önce |
| Kural karmaşıklığı | İsteğin hangi alt siteye ait olduğunu ayırt etmek için ekstra ([_0-9a-zA-Z-]+/)? grupları ve ayrı bir trailing-slash kuralı içerir | DNS ayrımı zaten yapıldığı için daha sade; subdirectory kurallarına benzer ama ek gruplar ve trailing-slash kuralı yoktur |
Alt dizin kurulumlarında sunucunun, gelen bir isteğin ana siteye mi yoksa bir alt siteye mi ait olduğunu URL'nin kendisinden anlaması gerekir. Bu yüzden kurallara ([_0-9a-zA-Z-]+/)? gibi ekstra yakalama grupları eklenir; böylece /site2/wp-admin/ gibi bir istek doğru şekilde wp-admin/ dizinine yönlendirilir. Bu blok ayrıca /wp-admin isteklerine sondaki eğik çizgiyi (trailing slash) otomatik olarak ekleyen ayrı bir RewriteRule de içerir. Alt alan adı kurulumlarında ise bu ayrım DNS/vhost seviyesinde zaten yapıldığından, .htaccess kurallarının bu ek karmaşıklığa ihtiyacı yoktur.
Opsiyonel Sertleştirme: Erişim Kısıtlama ve HTTPS Yönlendirmesi
BEGIN/END WordPress bloğunun dışında, WordPress çekirdeğinin bir parçası olmayan ama yaygın olarak önerilen iki ek blok daha vardır.
- wp-config.php ve .htaccess erişimini kapatma:
<Files wp-config.php>ve<Files .htaccess>blokları,Deny from alldirektifiyle bu iki dosyanın tarayıcıdan doğrudan istenmesini engeller. Veritabanı kimlik bilgilerini barındıran wp-config.php'nin ve yönlendirme kurallarını içeren .htaccess'in dışarıdan görüntülenmemesi, yaygın ve önerilen bir sertleştirme adımıdır. - HTTPS'e zorlama:
RewriteCond %{HTTPS} offkontrolüyle HTTP üzerinden gelen istekleri 301 yönlendirmesiyle HTTPS'e taşıyan ek bir blok. Bu da çekirdeğin bir parçası değildir, sertifikası olan siteler için yaygın bir ek kuraldır.
Sık Yapılan Hatalar
- Özel kuralları
# BEGIN WordPressve# END WordPressişaretlerinin içine eklemek: Kalıcı Bağlantılar sayfası her kaydedildiğinde bu blok WordPress tarafından tamamen yeniden yazılır ve araya eklenen özel satırlar silinir. Özel kurallar bloğun öncesine ya da sonrasına eklenmelidir. - Sunucuda
mod_rewritemodülünün etkin olmadığını fark etmeden pretty permalink'lerin çalışmasını beklemek; modül etkin değilse isteklerindex.php'ye ulaşmaz ve 404 hataları alınır. - WordPress'i bir alt dizine taşıdıktan sonra
RewriteBasedeğerini güncellememek; bu durumda yönlendirme yanlış dizine işaret etmeye devam eder. - Bir sunucu taşıma ya da yedekten geri yükleme sonrasında eski, hedef kurulumla uyumsuz bir .htaccess dosyasını olduğu gibi geri yüklemek ve ardından tüm iç sayfalarda 404 hatasıyla karşılaşmak.
Kurulum tipinize (tekli site, alt dizin multisite, alt alan adı multisite) uygun doğru bloğu, isteğe bağlı sertleştirme ve HTTPS yönlendirmesiyle birlikte saniyeler içinde üretin.
Doğru bloğu elle yazmak yerine kurulum tipinizi seçip üretilen metni doğrudan .htaccess dosyanıza yapıştırmak, hem hata riskini azaltır hem de wp-admin'e giriş yapamadığınız durumlarda (örneğin bir taşıma sonrası site erişilemez olduğunda) hızlı bir kurtarma yolu sağlar.