Linux hosting üzerinde pratik htaccess kuralları

Siteniz yönlendirme yapmıyorsa veya 500 hatası alıyorsanız, muhtemelen htaccess'teki tek bir satır sorunu çözmeye ya da daha kötü hale getirmeye yeter. Bu kılavuz, yürütme sırasını ve temel kuralları gösterir.

6 dk Güncellendi 22 Sep 2026

Siteyi açıyorsunuz ve sayfa beyaz. Ya da daha kötüsü: tarayıcı 500 Internal Server Error diyor ve hiçbir log da bir şey söylemiyor. Bu işareti gördüğüm on vakadan dokuzunda, public_html kök dizinindeki .htaccess dosyası suçluydu; fazladan bir satır, yanlış bir boşluk veya RewriteEngine On'dan sonra gelmeyen bir kural. Bu kılavuz, gerçek hata ayıklama sırasında karşılaştığınız şeylerdir.

htaccess nedir ve satır sırası neden önemlidir

.htaccess dosyası, Apache veya LiteSpeed web sunucusunun her istekte okuduğu ve PHP'ye ulaşmadan önce çalıştırdığı basit bir metin dosyasıdır. Yani içine yazdığınız her satır, her ziyareti etkiler. Bu özellik, yanlış bir satırın tüm siteyi erişilemez hale getirmesine neden olur.

Yürütme sırası yukarıdan aşağıyadır ve eşleşen ilk kural kazanır. Genel bir yönlendirmeyi bir istisnadan önce yazarsanız, istisna asla çalışmaz. Bunu pratikte çok görüyorum: biri her şeyin HTTPS'ye gitmesini istiyor, ancak robots.txt dosyasını veya /.well-known/acme-challenge/ yolunu hariç tutmamış ve ardından otomatik SSL yenileme başarısız oluyor.

Blokların doğru sırası

  1. Temel ayarlar: Options -Indexes, varsayılan kodlama
  2. Zorunlu yönlendirmeler (HTTPS, www kaldırma veya ekleme)
  3. WordPress veya framework yeniden yazma kuralları
  4. Dosya ve dizin koruması
  5. Başlıklar ve önbellek

301 yönlendirmeyi doğru yazın

En yaygın iş, tüm trafiği HTTPS sürümüne ve tek bir alan adına taşımaktır. Bu bloğu dosyanın üstüne koyun:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

Çoğu kişinin gözden kaçırdığı nokta: [OR] bayrağı yalnızca art arda gelen iki RewriteCond arasında çalışır, üç arasında değil. Üçüncü bir koşul eklerseniz mantık değişir ve yönlendirme döngüsel hale gelir. İşareti de açıktır: tarayıcı ERR_TOO_MANY_REDIRECTS der ve site açılmaz.

Belirli bir sayfayı taşımak için, yeniden yazmadan daha basit olan Redirect kullanın:

Redirect 301 /old-page.html https://www.example.com/new-page/

Bu satır yalnızca tam yol için çalışır ve alt yolları etkilemez. Tüm bir dizinin taşınmasını istiyorsanız, RedirectMatch 301 ^/old-folder/(.*)$ /new-folder/$1 yazın. Site alan adını tamamen değiştiriyorsanız, her şeyden önce SEO kaybı olmadan alan adı değiştirme kılavuzunu okuyun; bu aşamada yanlış yönlendirme, yıllara dayanan sıralamaları yok edebilir.

Dizin ve hassas dosyaların korunması

wp-config.php dosyası, wp-includes dizini ve .sql veya .zip yedek dosyaları dışarıdan erişilebilir olmamalıdır. Bu bloğu kök dizine koyun:

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

<FilesMatch "\.(sql|bak|log|env)$">
  Require all denied
</FilesMatch>

Apache 2.2 sürümünde Require all denied komutu desteklenmez ve Order allow,deny ile Deny from all yazmanız gerekir. Sunucunuz Apache 2.4 ve üzeriyse (ki neredeyse her yerde öyle), aynı Require doğrudur. Bu ikisini karıştırmak, hiçbir açıklama olmadan 500 hatası verir.

Bir dizini parola ile korumak için önce parola dosyasını oluşturun:

htpasswd -c /home/user/.htpasswd admin

Ardından aynı dizindeki .htaccess dosyasına:

AuthType Basic
AuthName "Restricted"
AuthUserFile /home/user/.htpasswd
Require valid-user

AuthUserFile yolu mutlak olmalıdır. Göreli yol, en sık yapılan hatalardan biridir ve sonucu "yanlış parola" mesajı değil, 500 hatasıdır.

Özel hata sayfası ve başlıklar

Sunucunun varsayılan 404 sayfası, kullanıcıya kötü bir deneyim sunar. Bir 404.html dosyası oluşturun ve şu satırı ekleyin:

ErrorDocument 404 /404.html
ErrorDocument 403 /403.html

Yol, dosyaya göre değil alan adı köküne göre olmalıdır. ErrorDocument 404 404.html yazarsanız (baştaki eğik çizgi olmadan), Apache bunu düz metin olarak döndürür ve kullanıcı bir satır metin görür.

Güvenlik ve önbellek başlıkları için mod_headers modülü gereklidir:

<IfModule mod_headers.c>
  Header set X-Content-Type-Options "nosniff"
  Header set X-Frame-Options "SAMEORIGIN"
  <FilesMatch "\.(css|js|jpg|png|webp|woff2)$">
    Header set Cache-Control "max-age=2592000, public"
  </FilesMatch>
</IfModule>

2592000 sayısı 30 güne eşittir. Statik dosyalar için bu sayı mantıklıdır, ancak index.html veya değişebilecek herhangi bir şey için bir aylık önbellek, kullanıcının bir aya kadar eski sürümü görmesi anlamına gelir. Burada hata yaparlar: biri sitenin stilini değiştirir, siteyi yeniler, değişikliği görmez ve yüklenmediğini düşünür. Aslında tarayıcı önbelleğidir.

500 hatası: nereye bakmalı

Site 500 verdiğinde, ilk iş dosyayı geçici olarak devre dışı bırakmaktır:

mv .htaccess .htaccess.bak

Site açılırsa, sorun kesinlikle o dosyadadır. Şimdi satır satır geri alın veya sondan yorum satırı haline getirin. Üç yaygın neden:

  • Modülü sunucuda kurulu olmayan komut, örneğin PHP'yi FastCGI ile çalıştıran sunucularda php_value
  • Windows editörüyle kaydedilmiş dosyanın başındaki boşluk veya görünmez karakter (örneğin BOM)
  • <IfModule> içine alınmamış ve modülü devre dışı olan bir kural

İkinci maddeyi ciddiye alın. Dosyayı file .htaccess ile kontrol edin; UTF-8 Unicode (with BOM) görürseniz, BOM'u kaldırın. Bu fazladan bir bayt, tüm siteyi çökertir ve logda da özel bir şey görmezsiniz.

Hata WordPress'teyse ve 500 değil beyaz sayfa alıyorsanız, sorun giderme yolu farklıdır; WordPress ve PHP'de beyaz sayfa sorununu giderme kılavuzu bunu adım adım ele alır.

htaccess ve hosting kaynak sınırlamaları

Az söylenen bir nokta: .htaccess her istekte okunur ve onlarca ağır kuralınız varsa, yanıt süresini etkiler. Kaynakların birkaç site arasında paylaşıldığı paylaşımlı hosting'de bu etki daha çok göze çarpar. Sitenin yavaşladığını görüyor ve htaccess kurallarını yeni eklediyseniz, önce Entry Process kavramını ve ziyaretten farkını anlayın; yavaşlık sorunu başka bir yerden olabilir.

Pratikte çoğu site 30 satırdan az htaccess'e ihtiyaç duyar. Dosyanız 200 satırı geçtiyse, işin bir kısmı muhtemelen sunucu düzeyinde veya uygulama kodunda yapılmalıdır. Linux hosting üzerinde kuralları alan adı düzeyinde yönetebilirsiniz, ancak trafik ve genel yapılandırma ihtiyacı paylaşımlı hosting sınırını aştıysa, özel sunucu daha mantıklı bir seçenektir çünkü orada ayarları her dizinde değil, bir kez httpd.conf içinde yazarsınız.

Kaydetmeden önce şunları yapın

Her zaman sağlam dosyanın bir yedeğini bulundurun. Her değişiklikten önce cp .htaccess .htaccess.backup yapın. FTP'niz varsa, FTP hesabı yönetimi kılavuzu dosyayı sorunsuz şekilde nasıl indirip yükleyeceğinizi gösterir. Yönlendirmeleri test etmek için tarayıcının gizli modunu kullanın, çünkü normal tarayıcıdaki 301 önbelleği neredeyse temizlenmez ve sizi yanıltır.

Ve alan adının doğru sunucuya işaret ettiğinden emin değilseniz veya sorunun DNS'te olduğunu düşünüyorsanız, htaccess'e dokunmadan önce bir kez DNS ve ağ kontrol aracını kontrol edin. "htaccess sorunu" olarak bildirilen vakaların yarısı aslında yanlış A kaydıdır.

Sık sorulan sorular

htaccess değişikliğinden sonra site neden 500 hatası veriyor?

Neredeyse her zaman şu üç nedenden biridir: modülü sunucuda etkin olmayan komut, dosyanın başındaki BOM karakteri veya </IfModule> eksikliği gibi bir sözdizimi hatası. Dosyayı mv .htaccess .htaccess.bak ile geçici olarak kenara alın; site açılırsa, sorun kesinlikle o dosyadadır.

htaccess'te Redirect ve RewriteRule arasındaki fark nedir?

Redirect sabit ve basit yollar içindir ve alt yolları etkilemez. RewriteRule, RewriteCond ile birleşir ve protokol, alan adı veya tarayıcı türü gibi karmaşık koşulları destekler. Tek bir sayfayı taşımak için birincisini, koşullu mantık için ikincisini kullanın.

htaccess Nginx üzerinde çalışır mı?

Hayır. Nginx htaccess dosyasını okumaz ve kurallar yapılandırma dosyasının server bloğuna yazılmalıdır. Web sunucusu Nginx olan bir hosting'deyseniz, kuralların sunucu düzeyinde uygulanmasını panelden veya destek ekibinden istemelisiniz.

htaccess'in siteyi yavaşlattığını nasıl anlarım?

Dosyayı geçici olarak devre dışı bırakın ve yanıt süresini bir hız ölçüm aracıyla karşılaştırın. Fark belirginse, yinelenen kuralları veya ağır koşulları kaldırın. Çoğu durumda htaccess'in hız üzerindeki etkisi önemsizdir ve yavaşlık eklentilerden veya veritabanı sorgularından kaynaklanır.

Bu sayfa yardımcı oldu mu?