htaccess Nereye Yüklenir? Kök Dizin Nedir?

".htaccess dosyam çalışmıyor" şikayetlerinin büyük bölümü, kuralların sözdiziminden değil konumdan kaynaklanır. Yönlendirme yazılmış, test edilmiş; ama site hiçbir şeyi uygulamıyor. Bunun en yaygın sebebi, dosyanın etki etmesi gereken dizinde değil, bir üst seviyede ya da yanlış bir klasörde olmasıdır.

Doğru konumu belirlemek için önce Apache'nin web kökü (document root) kavramını anlamak gerekiyor. Bu kavram barındırma türüne ve sunucu yapılandırmasına bağlı olarak değişir — paylaşımlı hostingde public_html iken VPS'te /var/www/html olabilir, yerel geliştirme ortamında ise bambaşka bir yere işaret eder.

Web kökü (document root) nedir?

Apache bir domain için gelen istekleri karşıladığında, dosyaları belirli bir dizinden sunar. Bu dizin document root olarak adlandırılır ve sunucu yapılandırmasındaki DocumentRoot direktifiyle tanımlanır.

DocumentRoot "/var/www/html"

Ziyaretçi https://example.com/hakkinda.html adresini açtığında Apache, document root altındaki hakkinda.html dosyasını bulup sunar. Kök dizinin dışındaki dosyalara bu yolla erişilemez. Web köküne yerleştirilen .htaccess dosyası da bu mantığa göre çalışır — koyulduğu dizinden itibaren aşağıya doğru tüm isteklere etki eder.

Yanlış dizine konan kural hiçbir şey yapmaz.

Paylaşımlı hostinglerde DocumentRoot satırına doğrudan erişemezsiniz; sağlayıcı bunu otomatik ayarlar ve genellikle public_html dizinini web kökü olarak atar. VPS veya dedicated sunucularda ise /etc/apache2/sites-enabled/ ya da /etc/httpd/conf/httpd.conf altındaki VirtualHost tanımlarında bu satırı kendiniz görebilir, gerekirse değiştirebilirsiniz.

Kök dizin, yalnızca .htaccess için değil, robots.txt ve sitemap.xml gibi dosyaların da zorunlu olarak bulunması gereken yerdir. Bu dosyalar alt dizinlere koyulduğunda arama motorları onları bulamaz. robots.txt oluşturduğunuzda elde ettiğiniz dosya da web kökünün doğrudan içine yerleştirilmelidir.

Barındırma türüne göre kök dizin nerede?

Barındırma sağlayıcısına göre klasör adı ve yolu değişir. En yaygın konumlar şunlardır:

• cPanel tabanlı shared hosting → public_html/
• Plesk tabanlı hosting → httpdocs/
• DirectAdmin → public_html/
• CyberPanel → /home/example.com/public_html/
• Ubuntu/Debian VPS (varsayılan Apache) → /var/www/html/
• CentOS/RHEL VPS → /var/www/html/
• XAMPP (Windows) → C:\xampp\htdocs\
• WAMP (Windows) → C:\wamp64\www\
• Laragon → C:\laragon\www\

FTP ile bağlandığınızda sunucudaki ev dizinine düşersiniz; bu dizin çoğunlukla web kökü değildir. cPanel hostinglerde FTP bağlantısı /home/kullanici/ dizinine açılır, web kökü ise bir seviye aşağıdaki public_html/ klasörüdür. .htaccess dosyasını ev dizinine yanlışlıkla bırakan kullanıcılar kuralların neden çalışmadığını anlayamazlar — çünkü site yine de açılır, sadece kurallar uygulanmaz.

Hangi dizinin web kökü olduğundan emin değilseniz, barındırma kontrol panelinizin dosya yöneticisinde index.html veya index.php dosyasının bulunduğu klasöre bakın. .htaccess, o dosyayla aynı dizine gider.

Bu dosya yalnızca Apache'de çalışır

Nginx kullanan bir sunucuya geçiş yaptıysanız ya da hosting sağlayıcınız Nginx tabanlı bir yapı sunuyorsa, .htaccess dosyası hiçbir işlev görmez. Nginx bu dosyayı tanımaz; kurallar sessizce görmezden gelinir, hata da üretmez. Nginx'te eşdeğer yapılandırma nginx.conf veya ilgili site tanımı dosyasına server {} bloğu olarak yazılır ve yeniden yükleme gerektirir — dizin bazlı dinamik kural dosyası desteği mimari olarak yoktur.

WordPress kullananlar için ayrı bir durum var: WordPress, her kaydetme işleminde kök .htaccess dosyasını yeniden yazmaya çalışır. Elle eklediğiniz kurallar, WordPress'in kendi bloğunun (# BEGIN WordPress / # END WordPress) dışında kalıyorsa korunur. Bu bloğun içine elle kural yazarsanız, bir sonraki WordPress güncellemesinde kaybolabilir; permalink ayarlarını her değiştirdiğinizde de aynı durum geçerlidir.

Alt dizinlere ayrı htaccess yerleştirmek

Apache bir isteği işlerken web kökünden başlayarak hedef URL'nin bulunduğu dizine kadar yolu tarar ve bu yol üzerindeki tüm .htaccess dosyalarını sırayla okuyup uygular. Kök dizindeki kurallar en geniş kapsamı oluşturur; alt dizindeki dosyalar bu kuralların üzerine ek tanımlar getirebilir ya da bazılarını yerel olarak geçersiz kılabilir.

Kök dizinde şu kural tanımlı olsun:

Options -Indexes

Bu kural, tüm alt dizinlerde klasör içeriklerinin listelenmesini engeller. Eğer yalnızca /dosyalar/ dizininde listeleme açık olsun istiyorsanız, o klasöre ayrı bir .htaccess koyup Options +Indexes yazabilirsiniz. Diğer dizinler kök kuralını izlemeye devam eder.

Bu hiyerarşi hem esneklik hem de karmaşıklık getirir. Özellikle yönlendirme kurallarında hangi dosyada ne tanımladığınızı takip etmezseniz çakışmalar yaşanabilir. Aynı URL için hem kök dizinde hem alt dizinde RewriteRule varsa, Apache önce alt dizin dosyasını uygular. Bir kural beklediğiniz gibi çalışmıyorsa, üst seviyedeki .htaccess dosyalarında çakışan bir tanım olup olmadığını kontrol edin.

Kural çakışması debug sürecini karmaşıklaştırır.

Mümkün olduğunda tüm kuralları tek bir kök .htaccess dosyasında toplamak, hangi kuralın nerede devreye girdiğini takip etmeyi kolaylaştırır. Alt dizin dosyaları yalnızca gerçekten farklı davranış gerektiğinde — örneğin belirli bir dizinde farklı bir önbellekleme politikası ya da erişim kısıtlaması tanımlanacaksa — kullanılmalıdır.

FTP ile yüklerken dikkat edilecekler

.htaccess dosyasıyla ilgili en sık karşılaşılan pratik sorunlardan biri, dosyanın FTP istemcisinde görünmemesidir. Dosyayı sunucuya yükledikten sonra klasörü yenileyin ama göremiyorsanız, istemcinizin "gizli dosyaları göster" seçeneğini etkinleştirin. FileZilla'da bu ayar Sunucu → Gizli Dosyaları Zorla Göster menüsündedir; WinSCP'de ise bağlantı ayarlarından etkinleştirilir.

Windows'ta dosyayı oluşturup yüklemeden önce de bir sorun çıkabilir. Not Defteri gibi bazı uygulamalar uzantısız dosya kaydetmeye izin vermez ve dosyayı .htaccess.txt olarak kaydeder. Sunucuya gönderilen dosyanın adı .htaccess değil .htaccess.txt olursa Apache onu tanımaz. Dosya adını FTP istemcisinde sunucu tarafında yeniden adlandırabilirsiniz; ya da oluştururken metin editöründe dosya türünü "Tüm Dosyalar (*.*)" seçip adı tam olarak .htaccess yazmalısınız.

Bir de kodlama sorunu var: .htaccess dosyası UTF-8 BOM olmadan kaydedilmelidir. Bazı Windows editörleri varsayılan olarak BOM ekler. BOM içeren dosyalar Apache'de parse hatası üretebilir ve 500 Internal Server Error döner.

Dosya çalışmıyorsa ilk kontrol noktaları

Konumu doğrulayıp dosyayı doğru yüklemenize rağmen kurallar hiçbir şey yapmıyorsa sırayla şunlara bakın:

• AllowOverride direktifi — Apache'nin .htaccess dosyalarını işlemesi için sunucu yapılandırmasında AllowOverride All tanımlı olması gerekir. AllowOverride None varsa dosya orada durur ama hiç okunmaz. Paylaşımlı hostinglerde bu genellikle açık gelir; VPS'te kendiniz ayarlamanız gerekir.
• mod_rewrite modülü — Yönlendirme kuralları mod_rewrite modülüne bağımlıdır. Modül yüklü değilse RewriteEngine On içeren tüm kurallar sessizce atlanır. Ubuntu üzerinde sudo a2enmod rewrite komutuyla etkinleştirilir.
• Sözdizimi hatası — Tek bir yazım hatası 500 Internal Server Error'a yol açabilir. Apache hata logları (/var/log/apache2/error.log veya hosting kontrol panelindeki log görüntüleyici) tam satır numarasını ve hata mesajını gösterir.
• Dosya adı kontrolü — Sunucu üzerinde dosya adının gerçekten .htaccess olduğunu teyit edin; .htaccess.txt veya htaccess (nokta olmadan) olması çok yaygın bir hatadır.

Yanlış konuma koyma durumu 500 hatası vermez. Kurallar sessizce görmezden gelinir ve site normal çalışmaya devam eder. htaccess olmadan sitenin nasıl davrandığını inceleyen yazıda da bu ayrım ele alınıyor — dosya yoksa Apache yine de işlev görür, ama kural uygulaması olmaz.

Doğru konumu bulduktan sonra ne yazacağınıza karar vermek için htaccess yapılandırmanızı oluşturabilirsiniz; yönlendirme, önbellekleme, sıkıştırma ve güvenlik kuralları hazır kalıplarla üretilebilir. Doğru konumu bulmak sorunun yarısını çözer; geri kalan yarısı çoğunlukla AllowOverride ayarından veya modül eksikliğinden çıkar.