Sitenizi HTTP'den HTTPS'ye taşıdınız ama eski linkler hâlâ güvensiz versiyona gidiyor. Ya da www'lu ve www'suz adresler ayrı ayrı indeksleniyor, Google bunları iki farklı site olarak görüyor. Belki de sunucunuzdaki klasör yapısı dışarıdan görünür durumda ve biri /uploads/ dizinine girip tüm dosyalarınızı listeleyebiliyor.
Bu sorunların hepsinin ortak çözümü tek bir dosyada gizli: .htaccess. Apache sunucularda dizin düzeyinde yapılandırma yapmanızı sağlayan bu dosya, adını "Hypertext Access" ifadesinden alır. Küçük bir metin dosyası ama URL yönlendirmeden güvenliğe, performanstan hata sayfalarına kadar geniş bir kontrol alanı sunar.
htaccess tam olarak ne işe yarar?
htaccess, Apache web sunucusunun dizin bazında yapılandırılmasını sağlayan bir dosya. Ana sunucu yapılandırma dosyasına (httpd.conf) erişiminiz olmadığında — ki paylaşımlı hosting kullanıyorsanız genellikle yoktur — htaccess devreye girer. Dünya genelinde web sunucularının yaklaşık %30'u hâlâ Apache kullanıyor, dolayısıyla htaccess bilgisi hâlâ güncel ve geçerli.
Dosya adı nokta ile başlar: .htaccess. Unix/Linux sistemlerde bu gizli dosya demek. Windows'ta oluşturmak biraz farklıdır, dosya adını tırnak içinde ".htaccess" yazmanız gerekir çünkü Windows uzantısız dosyaya izin vermez. Küçük bir detay ama ilk kez karşılaşanları şaşırtır. macOS'ta da Finder varsayılan olarak nokta ile başlayan dosyaları gizler — Terminal'den ls -la ile görebilirsiniz.
Değişiklikler ne zaman geçerli olur? Hemen. Apache her istek geldiğinde ilgili dizindeki htaccess dosyasını baştan okur ve kuralları uygular. Sunucuyu yeniden başlatmaya gerek yok — dosyayı kaydettiniz mi, bir sonraki istekte yeni kurallar devrede. Bu arada httpd.conf değişiklikleri için sunucu restart şart, aradaki fark bu.
Temel kullanım alanları
htaccess dosyasıyla yapabilecekleriniz oldukça geniş:
- URL yönlendirme (301, 302 redirect)
- HTTPS ve WWW zorlama
- GZIP/Deflate sıkıştırma
- Tarayıcı önbellekleme (browser cache)
- Dizin listeleme engelleme
- Hotlink koruması
- Özel hata sayfaları (404, 403, 500)
- IP bazlı erişim kontrolü
- Kötü bot engelleme
Kısacası, sunucu davranışını kontrol etmek için ihtiyaç duyacağınız çoğu şey htaccess ile mümkün. Hatta bazı hosting panelleri arka planda sizin yerinize htaccess kuralları yazıyor — cPanel'deki "Redirects" menüsü mesela tam olarak bunu yapıyor.
URL yönlendirme nasıl yapılır?
En yaygın kullanım alanı burası. Site taşıma, domain değişikliği, URL yapısı güncelleme — hepsinde 301 yönlendirmeler kritik rol oynar. Yanlış yaparsanız hem SEO değerinizi kaybedersiniz hem de kullanıcılar kırık linklerle karşılaşır.
HTTPS zorlama
Google, HTTPS'yi sıralama faktörü olarak kullanıyor. SSL sertifikanız varsa ama HTTP versiyonu hâlâ erişilebilir durumdaysa, tüm trafiği HTTPS'ye yönlendirmeniz gerekir:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]RewriteCond %{HTTPS} off satırı, gelen isteğin HTTPS olmadığını kontrol eder. Koşul sağlanırsa RewriteRule devreye girer ve kullanıcıyı aynı URL'nin HTTPS versiyonuna yönlendirir. [L,R=301] bayrakları ise bunun kalıcı bir yönlendirme olduğunu ve son kural olduğunu belirtir.
WWW tercihi
siteniz.com ve www.siteniz.com — Google'ın gözünde iki farklı site. Birini diğerine yönlendirmezseniz duplicate content sorunu kaçınılmaz. WWW'suz versiyona yönlendirmek için:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [L,R=301]Tersi de mümkün — WWW'lu versiyonu tercih ediyorsanız kuralı tersine çevirmeniz yeterli. Hangisini seçtiğiniz önemli değil, tutarlı olmanız önemli.
Tekil sayfa yönlendirme
Eski bir URL'yi yeni adresine yönlendirmek basit:
Redirect 301 /eski-sayfa.html https://www.siteniz.com/yeni-sayfa.htmlTek satır, tek iş. Site taşıma sırasında onlarca, hatta yüzlerce yönlendirme gerekebilir. Her birini tek tek yazmak yerine toplu yönlendirme oluşturabilirsiniz.
Performans ayarları
Yönlendirme dışında htaccess'in bir de performans tarafı var. Sıkıştırma ve önbellekleme — bu ikisi doğru ayarlandığında sayfa yükleme süresini ciddi ölçüde düşürür. Google'ın Core Web Vitals metrikleri de bu ayarlardan doğrudan etkilenir.
GZIP sıkıştırma
Sunucudan gönderilen dosyaları sıkıştırarak boyutlarını %60-70 oranında azaltabilirsiniz. Özellikle metin tabanlı dosyalarda fark dramatik — 150 KB'lık bir CSS dosyası sıkıştırmayla 45 KB'a düşebilir. HTML, CSS, JavaScript ve JSON dosyaları sıkıştırmaya çok uygun:
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/json
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE image/svg+xml
</IfModule><IfModule mod_deflate.c> kontrolü önemli. Sunucuda mod_deflate modülü yüklü değilse Apache bu kuralları atlar, 500 hatası vermez. Görseller zaten sıkıştırılmış formatta — JPEG, PNG, WebP'yi listeye eklemeyin, ters etki yapar. Hatta dosya boyutu artabilir, sıkıştırılmış veriyi tekrar sıkıştırmaya çalışmak CPU'yu boşuna yorar.
Browser cache ayarları
İlk ziyarette tarayıcı her şeyi indirir. İkinci ziyarette neden aynısını yapsın? Mantıksız.
Tarayıcı önbelleğini kullanarak tekrar eden indirmeleri ortadan kaldırabilirsiniz. htaccess ile dosya türlerine göre farklı önbellek süreleri tanımlamak mümkün:
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/html "access plus 1 hour"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType font/woff2 "access plus 1 year"
</IfModule>HTML dosyaları sık değişir, kısa tutulur. CSS ve JavaScript genellikle ayda bir güncellenir — 1 ay makul bir süre. Görseller ve fontlar nadiren değiştiği için 1 yıl verilebilir. Bu ayarların gerçekten işe yarayıp yaramadığını performans testinde doğrudan görebilirsiniz.
Güvenlik yapılandırması
Burası işin ciddiye binen kısmı. htaccess, sunucu düzeyinde güvenlik önlemleri almanızı sağlar — uygulama katmanından farklı olarak Apache isteği daha kodunuza ulaşmadan engeller. Yani PHP, Python veya Node.js'iniz ne kadar güvenli olursa olsun, sunucu katmanında açık bırakırsanız bir anlamı kalmaz.
Dizin listeleme engelleme
Varsayılan Apache ayarlarında, bir dizinde index.html dosyası yoksa Apache klasör içeriğini listeler. Biri /uploads/ adresine girerse tüm dosyalarınızı görebilir. Çözüm?
Options -IndexesTek satır. Dizin listelemesi devre dışı, kullanıcı 403 Forbidden hatası alır. Bu kadar basit olması insanı şaşırtıyor ama Apache'nin güzelliği de burada — karmaşık sorunlara kısa çözümler.
Hassas dosyaları koruma
htaccess dosyasının kendisini de korumalısınız. İçinde sunucu kurallarınız, yönlendirmeleriniz ve güvenlik ayarlarınız var — bunları dışarıdan kimse görmemeli:
<Files .htaccess>
Order allow,deny
Deny from all
</Files>Aynı yöntemle .env, .git, .sql gibi hassas dosyaları da engelleyebilirsiniz. Özellikle .env — API anahtarları, veritabanı şifreleri, üçüncü parti servis bilgileri hep orada durur. Koruma altına almadıysanız şu an durup bunu yapmanız iyi olur.
Hotlink koruması
Başka siteler görsellerinizi kendi sayfalarında kullanıyorsa, her görüntülenme sizin sunucunuzdan bant genişliği tüketir. Buna hotlinking denir. Popüler bir görseliniz varsa aylık gigabyte'larca gereksiz trafik oluşabilir — ve bunun faturasını siz ödersiniz. htaccess ile engellemek mümkün:
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https://(www\.)?siteniz\.com [NC]
RewriteRule \.(jpg|jpeg|png|gif|webp)$ - [F,NC,L]Bu kural, görsellerinize yalnızca kendi domaininizden erişime izin verir. Dışarıdan gelen isteklere Apache 403 döner. Boş referer'a neden izin veriyoruz? Bazı güvenlik yazılımları ve RSS okuyucuları referer göndermez, onları engellemek istemezsiniz.
Hata sayfaları tanımlama
Kullanıcı var olmayan bir sayfaya girdiğinde ne olur? Apache'nin varsayılan hata sayfası çıkar. Beyaz arka plan, "Not Found" yazısı — sanki 1998'e dönmüş gibi. Profesyonel görünmez, kullanıcıyı kaybedersiniz.
Özel hata sayfaları tanımlayarak bu deneyimi tamamen değiştirebilirsiniz:
ErrorDocument 404 /404.html
ErrorDocument 403 /403.html
ErrorDocument 500 /500.html404 sayfanızda ana sayfaya dönüş linki, arama kutusu veya popüler sayfalar listesi bulunmalı — kullanıcıyı sitede tutmak için bir fırsat. 500 hatası içinse basit bir "Teknik sorun yaşanıyor" mesajı yeterli, zaten o noktada yapabileceğiniz fazla bir şey yok.
Yaygın hatalar ve çözümleri
htaccess ile uğraşırken bir şeylerin ters gitmesi kaçınılmaz. Herkes en az bir kere siteyi çökertmiştir — önemli olan hızlı toparlamak.
500 Internal Server Error
En küçük syntax hatası tüm siteyi çökertebilir. Bir virgül, bir boşluk — bu kadarı yeterli. Cuma akşamı deploy yapıp pazartesi fark ettiğiniz türden bir felaket.
Sıkça karşılaşılan nedenler:
- Yazım hatası (
RewriteEnginyerineRewriteEngine) - Eksik modül (
mod_rewriteyüklü değil amaRewriteRulekullanılmış) - Yanlış regex pattern
- Sonsuz döngü oluşturan yönlendirmeler
Teşhis basit: htaccess dosyasını geçici olarak .htaccess_backup olarak yeniden adlandırın. Site düzeldi mi? Sorun orada. Sonra kuralları tek tek geri ekleyerek hangisinin patladığını bulursunuz. Apache'nin error log'una bakmak da işe yarar — /var/log/apache2/error.log genellikle tam satır numarasını gösterir.
Sonsuz yönlendirme döngüsü
HTTPS ve WWW kurallarını birlikte kullanırken dikkatli olun. İki kural birbirini tetiklerse tarayıcı "Bu sayfa yönlendirme döngüsüne girdi" hatası verir. Sinir bozucu. Kuralları birleştirmek çok daha güvenli:
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^(.*)$ https://siteniz.com/$1 [L,R=301]Bu tek kural hem HTTP'yi HTTPS'ye hem de WWW'yu non-WWW'ya yönlendirir. İki ayrı kural yerine tek kuralla gitmek döngü riskini ortadan kaldırır.
Dosyanın yanlış konumda olması
htaccess dosyası sitenizin kök dizininde olmalı — paylaşımlı hostinglerde bu genellikle /public_html/ dizini. Dosyayı /home/kullanici/ gibi bir üst dizine koyarsanız? Çalışmaz. Sessizce görmezden gelinir. FTP ile bağlanıp doğru konumu kontrol edin.
Apache vs Nginx: htaccess gerekli mi?
htaccess yalnızca Apache sunucularda çalışır. Nokta.
Nginx kullanıyorsanız bu dosyayı tamamen görmezden gelir — kendi yapılandırma dosyası (nginx.conf) vardır, syntax'ı bambaşkadır. Sunucunuzun hangisi olduğunu bilmiyorsanız sunucu bilgilerinizi kontrol edebilirsiniz. HTTP yanıt başlıklarındaki Server alanı bunu gösterir.
OpenLiteSpeed gibi Apache uyumlu sunucular htaccess dosyasını kısmen destekler. Temel kurallar çalışır — yönlendirme, cache gibi — ama bazı gelişmiş özellikler farklılık gösterebilir. Sunucunuz OpenLiteSpeed ise her kuralı ekledikten sonra test etmenizde fayda var. Biz de SeoDenetim'de OpenLiteSpeed kullanıyoruz ve bazı mod_rewrite kurallarının farklı davrandığını ilk elden deneyimledik.
Performans meselesi de var. htaccess dosyası her istekte baştan okunur — yani saniyede 100 istek alan bir sitede Apache bu dosyayı saniyede 100 kez parse eder. Yüksek trafikli sitelerde bu ek yük oluşturabilir. Sunucu yapılandırma dosyasına (httpd.conf) doğrudan erişiminiz varsa kuralları oraya taşımak daha verimli olur. Paylaşımlı hostinglerde bu seçenek genellikle mevcut değil, htaccess tek çözüm olarak kalır.
htaccess dosyası Apache sunucularda vazgeçilmez bir araç — URL yönlendirmeden güvenliğe, performanstan hata yönetimine kadar sunucu davranışını dizin düzeyinde kontrol etmenizi sağlar. Dosyayı oluştururken dikkatli olun, küçük bir syntax hatası tüm siteyi erişilemez yapabilir. Her değişiklikten önce mevcut dosyanızı yedekleyin, kuralları tek tek ekleyin ve her adımda test edin. Manuel yazmak yerine hazır şablonlarla da güvenli şekilde oluşturabilirsiniz.