WordPress .htaccess Bozuldu! Varsayılan WordPress .htaccess Kodları

Tepki Ver

WordPress siteniz 500 Internal Server Error veriyorsa veya alt sayfalar 404'e düştüyse .htaccess dosyanız bozulmuş demektir. Çözüm için: FTP veya cPanel Dosya Yöneticisi ile sitenin kök dizinine (public_html) bağlanın. Gizli dosyaları görünür yapıp mevcut .htaccess dosyasının adını değiştirerek yedekleyin veya dosyayı tamamen silin. Aynı dizinde .htaccess adında tertemiz bir dosya oluşturun. Sitenizin türüne uygun (standart veya multisite) orijinal WordPress kod bloğunu içine yapıştırıp kaydedin.

Sinyaller kırmızıya döndü, sunucu odasında alarm çalıyor ve WordPress siten muhtemelen şu an ya koca bir “Internal Server Error (500)” hatası veriyor ya da ana sayfa dışındaki tüm linklerde “404 Not Found” duvarı örüyor. Sakin oluyoruz. Klavyeden elini yavaşça çek, derin bir nefes al. Dünyanın sonu gelmedi, veritabanın sapasağlam yerinde duruyor. Sadece sunucunun kalbindeki o meşhur, huysuz ve ultra hassas trafik polisi, yani .htaccess dosyan bozuldu.

Yüklediğin sinsi bir eklenti, sunucu taşırken araya sıkışan bozuk bir karakter ya da elinin yanlışlıkla dokunduğu bir kod satırı bu dosyayı çorbaya çevirdi. Ama şanslısın; çünkü şu an siteportal.net’tesin ve o tıkalı damarı saniyeler içinde açıp siteni eski akıcı günlerine döndüreceğiz. Terminali veya FTP istemcini hazırla, operasyon başlıyor.

Geliştiricilerin ve sistem yöneticilerinin en zamansız anlarda karşılaştığı o meşhur kabus: Sitede her şey yolunda giderken aniden beliren bir 500 hatası ya da alt sayfalara tıklayınca karşına çıkan o soğuk 404 ekranı. WordPress ekosisteminde bu iki senaryonun arkasındaki gizli suçlu neredeyse her zaman aynıdır: Karakter yapısı delinmiş, eklentiler tarafından tecavüze uğramış bir .htaccess dosyası.

.htaccess (Hypertext Access), Apache ve LiteSpeed web sunucularının sitenin kök dizininde aradığı, kalıcı bağlantılardan güvenliğe, önbelleklemeden yönlendirmelere kadar her şeyi yöneten ultra güçlü bir konfigürasyon dosyasıdır. Bu dosya o kadar hassastır ki, içine yazılacak fazladan bir boşluk veya yanlış bir karakter sunucunun beynini yakmaya fazlasıyla yeter.

Eğer siten şu an sana kapıyı kapattıysa, arkana yaslan. Bu rehberde bozulan .htaccess dosyasını nasıl bulacağını, nasıl sıfırlayacağını ve WordPress altyapına uygun (Single site, Multisite, Subdomain) o orijinal, tertemiz fabrika ayarı kodları nasıl enjekte edeceğini adım adım göreceğiz.

1.FTP veya Kontrol Paneline Sızın:

FileZilla gibi bir FTP istemcisiyle ya da hosting panelinin (cPanel, Plesk) Dosya Yöneticisi (File Manager) uygulamasıyla sunucuna root veya kullanıcı olarak bağlan. Sitenin ana kodlarının barındığı kök dizine, yani genelde public_html veya httpdocs klasörünün içine gir.

2.Gizli Dosyaları Görünür Yapın:

Klasöre girdiğinde .htaccess dosyasını göremiyorsan panik yapma. Dosyanın başındaki nokta (.) işareti, onun Linux sistemlerde gizli bir dosya olduğunu gösterir. cPanel kullanıyorsan sağ üstteki Ayarlar (Settings) butonuna bas ve “Gizli Dosyaları Göster (Show Hidden Files – dotfiles)” kutucuğunu işaretleyip kaydet.

3.Bozuk Dosyayı İmha Edin (Yedekleyerek!):.

Mevcut bozuk .htaccess dosyasını bul. Ne olur ne olmaz diye sağ tıklayıp bilgisayarına indirmeyi (yedeklemeyi) unutma. Yedekledikten sonra sunucudaki o bozuk dosyayı tamamen sil veya adını htaccess_bozuk.txt olarak değiştir. Sitenin ana sayfasını yenile; eğer 500 hatası gittiyse suçluyu kesin olarak teşhis ettik demektir.

4.Tertemiz Bir .htaccess Dosyası Yaratın:

Şimdi kök dizinde boş bir yere sağ tıkla ve “Yeni Dosya Oluştur” de. Dosyanın adını milimetrik olarak aynen şöyle yaz: .htaccess (Başındaki noktayı sakın unutma ve sonuna .txt gibi uzantılar ekleme).

5.Orijinal WordPress Kodlarını Enjekte Edin:

Oluşturduğun boş dosyayı bir metin düzenleyiciyle aç. Aşağıdaki WordPress kurulum türüne uygun olan orijinal kod bloğunu kopyala, dosyanın içine yapıştır ve kaydet. Siten anında tıkır tıkır çalışmaya başlayacaktır!

Kurulum Türüne Göre Orijinal WordPress .htaccess Kodları

WordPress, sitenin yapısına göre farklı yönlendirme kuralları kullanır. Siten standart bir tekli site mi, yoksa subdomain/subfolder tabanlı bir çoklu site (Multisite) mi? Aşağıdaki kutulardan sana uygun olanı seç ve kopyala.

1. Standart (Tekli) WordPress Kurulumları İçin .htaccess Kodu

Eğer normal, standart bir blog, kurumsal site veya tek bir domain altında çalışan WooCommerce mağazası yönetiyorsan, aradığın o kutsal ve tertemiz kod bloğu tam olarak budur:

# BEGIN WordPress
# "BEGIN WordPress" ve "END WordPress" arasındaki çizgiler dinamik olarak filtrelenir.
# Bu çizgiler arasındaki kuralları değiştirmek sadece WordPress üzerinden yapılmalıdır.

<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

2. WordPress Multisite (Çoklu Site – Subdirectory) .htaccess Kodu

Eğer WordPress siteni [siteniz.com/site1](https://siteniz.com/site1), [siteniz.com/site2](https://siteniz.com/site2) şeklinde alt klasörlere bölünmüş bir ağ (Multisite) olarak kurguladıysan, sunucunun trafiği doğru klasörlere dağıtması için şu kodları kullanmalısın:

# BEGIN WordPress Multisite Subdirectory
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# Ekstra eğik çizgi eklemelerini organize et
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]
# END WordPress Multisite Subdirectory

3. WordPress Multisite (Çoklu Site – Subdomain) .htaccess Kodu

Eğer siten site1.siteniz.com, site2.siteniz.com şeklinde alt alan adları (Subdomain) üzerinden dönen devasa bir Multisite ağıysa, Apache ve LiteSpeed sunucularının rotayı şaşırmaması için bu kod bloğunu yapıştırmalısın:

# BEGIN WordPress Multisite Subdomain
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# wp-admin klasör yönlendirmelerini düzene sok
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]
# END WordPress Multisite Subdomain

.htaccess Neden Bozulur ve Bu Krizden Nasıl Korunursun?

Dosyayı sıfırladın, siten jet gibi açıldı ve derin bir nefes aldın. Peki bu sinsi dosya neden durup dururken bozuldu? Gelecekte aynı sunucu krizini yaşamamak için şu detaylara dikkat etmelisin:

  1. Agresif Güvenlik ve Önbellek Eklentileri: Cache (önbellekleme) ve güvenlik eklentileri (Wordfence, iThemes Security vb.) optimizasyon veya IP engelleme yaparken bu dosyaya yüzlerce satır kod yazar. Eklentiyi panelden aniden silersen veya güncelleme yarıda kalırsa, o kodlar içeride yarım yamalak kalır ve sunucuyu kilitler.
  2. Hatalı İzin Seviyeleri (File Permissions): .htaccess dosyasının yazma izni (CHMOD) çok gevşek bırakılırsa, sisteme sızan basit bir zararlı yazılım (malware) bu dosyayı manipüle edebilir.
  3. Manuel Kod Düzenleme Hataları: Kodların arasına eklediğin Türkçe karakterler, yanlış yönlendirme (301) sözdizimleri (syntax) sunucu seviyesinde ölümcüldür.

💡 Teknik İpucu (Expert Box)

Bunu biliyor muydunuz? .htaccess dosyanızın tekrar sinsi eklentiler veya kötü niyetli yazılımlar tarafından bozulmasını engellemenin en profesyonel yolu, dosyayı sıfırladıktan sonra üzerine kilit vurmaktır. FTP üzerinden .htaccess dosyasına sağ tıklayıp “Dosya İzinleri” (File Permissions) menüsünü açın. Standart değer olan 644 iznini 444 (Sadece Okunabilir – Read Only) olarak değiştirin. Bu hamleyle sunucuya şu emri verirsiniz: “Bu dosyayı ben dahil hiç kimse, hiçbir eklenti değiştiremez, sadece sunucu okuyabilir.” İleride yeni bir eklenti kurup ayar yapacağınız zaman izni tekrar geçici olarak 644 yapmayı unutmayın!

Sonuç: Siber Kalenizi Canlandırdınız

Gördüğün gibi, WordPress’in en korkutucu sunucu hatalarından biri olan .htaccess bozulmaları, aslında HTTP protokolünün ve Apache/LiteSpeed mimarisinin kurallarını bildiğinde 5 dakikada alt edilebilecek yapısal bir pürüzdür. Fabrika ayarı temiz kodları içeri fırlatıp, dosya izinlerini optimize ettiğinde siten hem 500 hatalarından kurtulur hem de kalıcı bağlantı (permalink) yapısını kusursuz şekilde işlemeye devam eder.

Sen dosyayı sıfırladıktan sonra sitendeki o can sıkıcı 500 veya 404 hatası tamamen ortadan kalktı mı? Kodları yapıştırırken sunucu mimarinde bir çakışma yaşadın mı? Yorumlara yaz, sunucu loglarını ve konfigürasyon detaylarını birlikte inceleyelim!

Yazar Profili
SitePortali Yönetici Tüm Yazılar

Kullanıcıya ait herhangi bir sosyal medya veya iletişim bilgisi bulunmamaktadır.

37 Yazı

Bir Yorum Yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Benzer Yazılar