WordPress Varsayılan .htaccess Dosyası: İçeriği ve Geri Yükleme

WordPress’in varsayılan .htaccess dosyası, /2026/10/yazi-adi/ gibi kalıcı bağlantıların 404 vermek yerine çözümlenmesi için yazılımın sitenizin köküne yazdığı kısa RewriteEngine bloğudur. Şöyle görünür:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Bu, WordPress’in Apache HTTP Server hakkındaki resmi kılavuzundan ve şık kalıcı bağlantılar HelpHub sayfasında belgelenen yeniden yazma mantığından alınan tam bloktur. RewriteBase değeriniz / değilse — örneğin WordPress bir alt klasöre kurulduğu için — bunun yerine o yola uyacaktır; bu da aynı şekilde normaldir ve WordPress’in kendisi tarafından üretilir.

Önemli noktalar

• WordPress bu bloğu otomatik olarak, yalnızca Apache ve LiteSpeed’de, dosya yazılabilir olduğunda ve Ayarlar > Kalıcı Bağlantılar’ı kaydettiğinizde üretir.
• Dosya eksik veya bozuksa, ana sayfa hariç tüm kalıcı bağlantılar 404 döndürür; çünkü yeniden yazma kuralları olmadan sadece ana sayfa bulunabilir.
• Sizin veya bir eklentinin eklediği her şey # BEGIN WordPress’in üstünde olmalı, işaretlerin içinde asla olmamalı — WordPress her kalıcı bağlantı kaydedişinde aralarındaki her şeyin üzerine yazar.

Dosyayı gerçek yolunuz ve ekstra kurallarla yeniden oluşturmanız mı gerekiyor? WordPress .htaccess oluşturucusu tarayıcınızda doğru bir dosya hazırlar.

Her satır ne yapar

RewriteEngine On, bu dizin için Apache’nin mod_rewrite modülünü etkinleştirir; bu satır olmadan aşağıdaki her şey işlevsizdir.

RewriteBase /, Apache’ye yeniden yazılan yolların site köküne göre olduğunu söyler. WordPress bunu sitenin gerçekte nerede yaşadığına göre ayarlar — bir alt klasör kurulumu / değil RewriteBase /blog/ alır.

RewriteRule ^index\.php$ - [L] etkisiz bir korumadır: istek zaten index.php ise yeniden yazma durur ve istek değişmeden geçer.

İki RewriteCond satırı gerçek mantıktır. %{REQUEST_FILENAME} !-f ve !-d, “bu istek gerçek bir dosyaya uymuyor VE gerçek bir dizine uymuyor mu?” diye sorar. Son kuralın tetiklenmesi için ikisinin de doğru olması gerekir — böylece gerçek bir görsel, bir CSS dosyası veya yüklenen bir PDF doğrudan sunulur ve asla WordPress’in yönlendirmesine dokunmaz.

RewriteRule . /index.php [L], kalıcı bağlantıları çalışır kılan kuraldır: önceki iki koşuldan sağ çıkan her şey — yani gerçek bir dosya veya klasör olmayan her şey — index.php’ye gönderilir ve WordPress’in kendi yönlendirmesi (WP_Query, yeniden yazma etiketleri) o URL’nin gerçekte hangi yazı, sayfa veya arşiv olduğuna karar verir.

WordPress bu dosyayı ne zaman yeniden oluşturur, ne zaman oluşturamaz

WordPress, ekranda hiçbir şey değişmese bile Ayarlar > Kalıcı Bağlantılar’ı açıp Değişiklikleri Kaydet’e her tıkladığınızda .htaccess’i kendisi yazmaya çalışır. Bu kaydetme işlemi, .htaccess’i yazmak için açmaya ve mevcut bloğu işaretler arasına yerleştirmeye çalışan flush_rewrite_rules()’u tetikler.

Bu girişim, dosyayı eksik veya güncel olmayan halde bırakarak şu durumlarda sessizce başarısız olur:

• Dosya veya üst klasörü, PHP’nin çalıştığı kullanıcı için yazılabilir değilse. Birçok paylaşımlı barındırmada PHP, dosyaları FTP ile yükleyen kullanıcıdan farklı bir sistem kullanıcısı olarak çalışır; bu yüzden bir FTP istemcisinde doğru görünen izinler WordPress’in yazmasını yine de engelleyebilir.
• nginx kullanıyorsanız. .htaccess yalnızca Apache ve LiteSpeed mekanizmasıdır (Apache’nin AllowOverride belgelerinin kendisi nedenini açıklar: nginx’te her istekte yeniden okunan dizin bazlı bir yapılandırma dosyası yoktur). nginx’teki eşdeğeri, yalnızca sunucuya erişimi olan birinin düzenleyebileceği server bloğu içindeki bir try_files yönergesidir; WordPress bunu sizin için asla yazamaz.
• Ana Apache yapılandırmasında siteniz için dizinin AllowOverride değeri None ise. Bu, bir .htaccess’in herhangi bir şeyin üzerine yazmasına izin veren ayardır; Apache belgeleri açıkça şunu söyler: AllowOverride None ile “.htaccess dosyaları tamamen yok sayılır” — WordPress kusursuz bir dosya yazabilir, ama bu ayar sunucu düzeyinde değiştirilene kadar hiçbir etkisi olmaz.
• Dosya silinmiş veya hiç var olmamışsa ve kaydetme işlemindeki bir şey yeniden oluşturmayı tetiklememişse — en yaygın sebep, kalıcı bağlantı yapısının zaten aynı olması ve WordPress’in yeniden yazılacak hiçbir değişiklik görmemesidir.

Elle nasıl geri yüklenir

Yazılar ve sayfalar 404 verirken ana sayfa hâlâ çalışıyorsa, bu eksik veya bozuk bir .htaccess’in imzasıdır. İki adımda çözün.

1. Önce tek tıkla çözümü deneyin. WordPress yönetim panelinde Ayarlar > Kalıcı Bağlantılar’a gidin ve hiçbir şeyi değiştirmeden Değişiklikleri Kaydet’e tıklayın. Dosya yazılabilirse, bu tek başına dosyayı yeniden oluşturur ve işiniz biter.

2. Bu çözmezse, dosyayı elle oluşturun. FTP/SFTP ile veya barındırıcınızın dosya yöneticisiyle bağlanın, WordPress’in kurulu olduğu klasöre gidin (wp-config.php’yi içeren klasör) ve .htaccess’in hiç var olup olmadığını kontrol edin — gizli bir dosyadır, bazı dosya yöneticileri varsayılan olarak gizler; “gizli dosyaları göster”i açın.

• Eksikse, tam olarak .htaccess adında yeni bir dosya oluşturun (.txt yok, noktadan önce hiçbir şey yok).
• Yukarıdaki varsayılan bloğu yapıştırın; WordPress bir alt klasördeyse RewriteBase’i buna göre ayarlayın.
• Kaydedin ve çalıştığını doğrulamak için bir yazının kalıcı bağlantısını yeniden yükleyin.

Bundan sonra hâlâ 404 alıyorsanız, neden “.htaccess eksik” olmaktan “.htaccess yok sayılıyor” olmaya değişmiştir — barındırıcınıza AllowOverride’ı sorun, çünkü Apache’nin yok saymakla görevlendirildiği bir dizindeki doğru bir dosya, dosya hiç yokmuş gibi davranır.

Kendi kurallarınız WordPress’in bloğuna karşı

Bir eklenti veya elle yapılan düzenleme kendi kurallarını ekleyebilir — yönlendirmeler, hotlink koruması, önbellek başlıkları. Bu, WordPress’in ürettiğinden ayrı, farklı bir bloktur ve ikisi asla çakışmamalıdır:

# Sizin veya bir eklentinin eklediği kurallar — WordPress işaretlerinin ÜSTÜNDE
<FilesMatch "\.(jpg|jpeg|png|gif)$">
    # örnek: hotlink koruması, önbellek kuralları vb.
</FilesMatch>

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

# BEGIN WordPress ile # END WordPress arasına yerleştirilen her şey, biri bir dahaki Kalıcı Bağlantılar ekranını kaydettiğinde sessizce silinir; çünkü WordPress o bütün bölümü kendisine ait sayar ve tamamen yeniden yazar. Bu, “özel kuralım kayboldu” şikayetinin en yaygın sebebidir — kasıtlı olarak kaldırılmamıştır, sadece WordPress’in kendisine ait saydığı bir bloğun içindeydi. Özellikle yönlendirmeler için, nereye ait olduklarını ve döngülerden nasıl kaçınılacağını öğrenmek üzere doğru yapılmış WordPress .htaccess yönlendirme kurallarına bakın.

Dosyayı düzenledikten hemen sonra ani bir 500 Internal Server Error almanın da en yaygın sebebidir: farklı bir Apache sürümü için yazılmış bir forum gönderisinden kopyalanan bir kural (2.2’nin Order/Deny sözdizimi ile 2.4’ün Require sözdizimi karıştırılmış) tüm dosyanın ayrıştırılmasını bozar, altındaki WordPress bloğu da dahil, ve dokunduğunuz kısım değil, sitenin tamamı çöker.

Varsayılan bloğun ötesinde

Varsayılan blok yalnızca kalıcı bağlantı yönlendirmesini halleder. Hassas dosyalara erişimi sıkılaştırmak veya saldırı yüzeyini gerçekten azaltan birkaç .htaccess kuralı eklemek istiyorsanız — /uploads’ta PHP çalıştırmayı engellemek, wp-config.php’ye doğrudan istekleri reddetmek — gerçekten yardımcı olan WordPress .htaccess güvenlik kurallarına bakın. Ve kalıcı bağlantılar başka bir nedenle 404 veriyorsa — yanlış kalıcı bağlantı yapısı, eski kuralları sunan bir önbellek katmanı, alt dizinlerde çoklu site çatışmaları — çalışmayan WordPress kalıcı bağlantıları diğer nedenleri ele alır.

Sıkça sorulan sorular

WordPress varsayılan .htaccess dosyası nedir? Kalıcı bağlantıların 404 vermek yerine index.php’ye çözümlenmesi için WordPress’in # BEGIN WordPress ile # END WordPress arasına yazdığı RewriteEngine bloğudur.

WordPress’in tam varsayılan .htaccess kodu nedir? RewriteEngine On, RewriteBase /, index.php için bir geçiş kuralı, isteğin gerçek bir dosya veya dizin olmadığını kontrol eden iki koşul ve diğer her şeyi index.php’ye gönderen son bir kural. Tam blok bu kılavuzun başında verilmiştir.

Ana sayfa hariç tüm yazılarım neden 404 veriyor? Ana sayfa hiçbir yeniden yazma kuralı olmadan bulunabilir; diğer her kalıcı bağlantının bunlara ihtiyacı vardır. Apache’de eksik veya bozuk bir .htaccess tam olarak bu örüntüyü üretir.

WordPress .htaccess’i otomatik olarak yeniden oluşturur mu? Sadece dosya yazılabilirse — Ayarlar > Kalıcı Bağlantılar’ı yeniden kaydetmek bunu tetikler. Dosya yazılabilir değilse, otomatik üretmeyen bir barındırmada eksikse veya AllowOverride kapalıysa, WordPress bunu sizin için düzeltemez ve dosyayı elle oluşturmanız veya düzeltmeniz gerekir.

nginx’te neden bir WordPress .htaccess dosyası yok? .htaccess yalnızca Apache ve LiteSpeed’de çalışır. nginx’te dizin bazlı bir yapılandırma dosyası yoktur ve .htaccess’i tamamen yok sayar; aynı yönlendirme nginx’in server bloğunda bir try_files kuralı olarak yazılır.

Kalıcı bağlantıları kaydettikten sonra .htaccess’im neden bozuldu? Özel bir kural, # BEGIN WordPress / # END WordPress işaretlerinin üstüne değil içine yerleştirildi ve WordPress bir dahaki kalıcı bağlantı kaydedişinde o bölümün tamamının üzerine yazdı.

---

Varsayılan kalıcı bağlantı bloğu ile gerçekten gereken güvenlik veya yönlendirme kurallarını birleştiren temiz, doğru bir .htaccess oluşturun — ücretsiz WordPress .htaccess oluşturucusuyla.