Web Hosting & cPanel

    cPanel'de .htaccess Dosyası Nerede? Görünmüyorsa Ne Yapmalı?

    cPanel'de gizli .htaccess dosyasını görünür yapma, yoksa oluşturma ve güvenli düzenleme yöntemleri.

    12 dk okuma Güncellendi: 11 Ağustos 2026

    Bir rehber okuyorsunuz ve şu cümleyle karşılaşıyorsunuz: ".htaccess dosyanıza şu satırı ekleyin." cPanel'i açıyorsunuz, Dosya Yöneticisi'ne giriyorsunuz, public_html içine bakıyorsunuz ve .htaccess dosyası görünmüyor. Klasörde wp-config.php var, index.php var, wp-content var ama aradığınız dosya yok. Panik yapmayın: dosya büyük olasılıkla oradadır, sadece gizlidir. Adı noktayla başlayan her dosya Linux'ta gizli kabul edilir ve cPanel Dosya Yöneticisi varsayılan ayarında bunları listelemez.

    Bu yazıda önce gizli dosyaları nasıl görünür yapacağınızı anlatacağım; sonra dosya gerçekten yoksa sıfırdan nasıl oluşturulacağını, panelin "noktayla başlayan dosya adı" konusunda çıkardığı zorluğu nasıl aşacağınızı, düzenlemeden önce nasıl doğru yedek alacağınızı ve en önemlisi hatalı bir satır yüzünden site 500 hatası verdiğinde nasıl geri döneceğinizi göstereceğim. Bu son kısım, çoğu Türkçe anlatımda eksik olan ve gerçekte insanları en çok zorlayan bölümdür. Yıllardır destek tarafında gördüğüm .htaccess vakalarının çoğu, düzenlemenin kendisinden değil, düzenleme bozulunca geri dönülecek bir kopya bırakılmamış olmasından kaynaklanır.

    .htaccess Dosyası Nedir ve Neden Görünmez#

    .htaccess, Apache ve LiteSpeed sunucularında dizin başına yapılandırma dosyasıdır. İçine yazdığınız yönergeler, bulunduğu klasör ve tüm alt klasörleri için geçerli olur. Yönlendirmeler, HTTPS zorlaması, hata sayfaları, dizin listelemesini kapatma, IP engelleme, önbellek başlıkları ve WordPress'in kalıcı bağlantı kuralları hep bu dosyada durur.

    Görünmemesinin sebebi basit: Unix dünyasında adı nokta ile başlayan dosyalar "dotfile" sayılır ve varsayılan listelemelerde gizlenir. Bu dosya adının kendisinden gelen bir kuraldır, cPanel'e ya da hosting sağlayıcınıza özgü bir davranış değildir. Aynı sebeple .user.ini, .well-known, .git ve .env gibi öğeler de listede görünmez. Bu, taşımalarda sessiz bir tuzak yaratır: gizli dosyaları göstermeden yaptığınız bir kopyalama, yönlendirmelerinizi ve SSL doğrulama klasörünüzü arkada bırakır.

    Dosyanın etkin olabilmesi için sunucu tarafında AllowOverride ayarının açık olması gerekir. Paylaşımlı hostinglerin neredeyse tamamında bu açıktır; kendi sunucunuzu yönetiyorsanız Apache sanal sunucu bloğunda şu satır bulunmalıdır:

    <Directory /home/kullanici/public_html>
        AllowOverride All
    </Directory>
    

    Nginx kullanıyorsanız .htaccess hiç okunmaz. Nginx bu dosya biçimini desteklemez; aynı işleri sunucu yapılandırma dosyasında tanımlarsınız. Bu yüzden "kurallarım hiçbir şey yapmıyor" diyorsanız önce hangi web sunucusunun çalıştığını doğrulayın.

    cPanel'de Gizli Dosyaları Gösterme#

    Gizli dosyaları görünür yapmak Dosya Yöneticisi'nin ayarlar penceresinden yapılır ve tercihi bir kez ayarlamanız yeterlidir:

    1. cPanel ana ekranında Dosyalar grubundan Dosya Yöneticisi'ni açın.
    2. Sağ üst köşedeki Ayarlar (Settings) düğmesine tıklayın.
    3. Açılan pencerede Gizli Dosyaları Göster (dotfiles) kutusunu işaretleyin.
    4. Kaydet'e basın. Liste yenilenir ve .htaccess artık public_html içinde görünür.

    Ayar hesabınıza kayıtlı kaldığı için bir daha uğraşmazsınız. FTP tarafında ise ayar istemcide bulunur; çoğu istemcide sunucu menüsü altında "gizli dosyaları göstermeye zorla" benzeri bir seçenek vardır ve açık değilse dosya listede çıkmaz. Dosya Yöneticisi arayüzünün genel kullanımı için cPanel dosya yöneticisi yazısı iyi bir başlangıç noktasıdır.

    SSH erişiminiz varsa gizleme sorunu hiç yaşanmaz, çünkü -a bayrağı gizli dosyaları da listeler:

    cd ~/public_html
    ls -la | grep htaccess
    

    Çıktıda şuna benzer bir satır görürseniz dosya yerindedir:

    -rw-r--r--  1 kullanici kullanici  424 Aug 11 10:22 .htaccess
    

    .htaccess Dosyası Gerçekten Yoksa Nasıl Oluşturulur#

    Gizli dosyaları açtınız ve dosya hâlâ yok mu? Bu normaldir. .htaccess zorunlu bir dosya değildir; statik bir sitede ya da henüz kalıcı bağlantı ayarı yapılmamış bir WordPress kurulumunda hiç oluşmamış olabilir. Sıfırdan oluşturmak için:

    1. Dosya Yöneticisi'nde public_html klasörüne girin (doğru klasörde olduğunuzdan emin değilseniz public_html nedir yazısına bakın).
    2. Üst menüden + Dosya (New File) düğmesine tıklayın.
    3. Dosya adı olarak .htaccess yazın; oluşturulacağı yolun /public_html olduğunu doğrulayın.
    4. Yeni Dosya Oluştur'a basın.
    5. Oluşan dosyayı seçip Düzenle (Edit) ile açın ve içeriği yazın.

    Bir WordPress sitesinde dosyayı sıfırdan yazıyorsanız, kalıcı bağlantıların çalışması için gereken standart blok şudur:

    # 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 bloğu yazdıktan sonra WordPress panelinde Ayarlar → Kalıcı Bağlantılar sayfasına girip hiçbir şey değiştirmeden Kaydet'e basmak iyi bir alışkanlıktır; WordPress dosyayı kendi biçimiyle yeniden yazar ve yazma izni olup olmadığını da böylece test etmiş olursunuz.

    Panel Noktayla Başlayan Dosya Adını Kabul Etmiyorsa#

    Bazı panel sürümlerinde ve bazı FTP istemcilerinde adı yalnızca noktayla başlayan bir dosya oluşturmak engellenir ya da dosya oluşturulur oluşturulmaz listeden kaybolur. İki güvenilir yol vardır:

    Yeniden adlandırma yöntemi. Önce htaccess.txt adında normal bir dosya oluşturun, içeriğini yazıp kaydedin, sonra dosyayı seçip Yeniden Adlandır ile .htaccess yapın. Yeniden adlandırma neredeyse her arayüzde noktayla başlayan ada izin verir.

    Terminal yöntemi. cPanel'de Terminal özelliği açıksa ya da SSH erişiminiz varsa tek komutla oluşturabilirsiniz:

    cd ~/public_html
    touch .htaccess
    chmod 644 .htaccess
    

    Masaüstünde dosya oluşturup yüklemeye çalışmak en sorunlu yoldur, çünkü Windows Gezgini adı noktayla başlayan dosya oluşturmayı engeller ve Not Defteri kaydederken sessizce .txt uzantısı ekler. Sunucuda .htaccess.txt adında bir dosya oluşur, hiçbir işe yaramaz ve siz kuralların neden çalışmadığını ararsınız.

    Düzenlemeden Önce Yedek Alma#

    .htaccess düzenlemesinin altın kuralı şudur: dosyayı açmadan önce bir kopyasını alın. Bu tek adım, bu yazıdaki geri alma bölümünü çoğu zaman gereksiz kılar.

    En pratik yol Dosya Yöneticisi'nde dosyayı seçip Kopyala (Copy) demek ve hedef adı htaccess-yedek-2026-08-11 gibi tarihli, noktasız bir ad yapmaktır. Noktasız olması önemlidir: adı .htaccess-yedek yaparsanız dosya hâlâ gizli kalır ve panik anında yine göremezsiniz. SSH ile aynı iş şu şekilde yapılır:

    cd ~/public_html
    cp .htaccess htaccess-yedek-$(date +%F).txt
    

    Yedek dosyasını .txt uzantısıyla ve web kökünde bırakmanın küçük bir yan etkisi vardır: adresi tahmin eden biri içeriğini okuyabilir. .htaccess içinde parola bulunmaz ama IP engelleri ve yönetim yolları gibi bilgiler bulunabilir. Uzun süre saklayacaksanız yedeği public_html dışına, ev dizinine taşıyın.

    Yedekleme yoluNe kadar sürerNe zaman tercih edilir
    Dosya Yöneticisi'nde KopyalaBirkaç saniyeTek satırlık hızlı düzenlemeler
    SSH ile cpBirkaç saniyeTerminal erişimi olanlar
    Tam hesap yedeğiDakikalarBüyük yapılandırma değişikliği öncesi
    Sürüm notu (dosya içine yorum)AnındaNeyi neden eklediğinizi hatırlamak için

    Son satır küçük ama değerlidir: eklediğiniz her bloğun üstüne tarihli bir yorum satırı bırakın.

    # 2026-08-11 - eski urunler dizini yeni katalog sayfasina yonlendirildi
    Redirect 301 /urunler /katalog
    

    Altı ay sonra dosyaya baktığınızda bu satırın neden orada olduğunu hatırlamak, o satırı silip silmeyeceğinize karar vermenin tek yoludur.

    Hatalı .htaccess Yüzünden Site 500 Hatası Verirse#

    .htaccess içindeki tek bir yazım hatası sitenin tamamını 500 Internal Server Error ile kapatır. Bu davranış bilinçlidir: sunucu anlamadığı bir yapılandırmayı görmezden gelmez, isteği reddeder. Kötü haber şu ki hata sayfası size hangi satırın bozuk olduğunu söylemez. İyi haber ise geri dönmenin çok kolay olmasıdır.

    Adım adım kurtarma sırası:

    1. Dosyayı devre dışı bırakın. Dosya Yöneticisi'nde .htaccess dosyasını seçin, Yeniden Adlandır deyin ve adını htaccess-bozuk yapın. Site anında açılıyorsa sorunun kaynağı kesinleşmiştir.
    2. Yedeği geri koyun. Aldığınız htaccess-yedek-...txt dosyasını .htaccess olarak yeniden adlandırın. Site eski hâline döner.
    3. Yedek yoksa dosyayı sıfırdan kurun. WordPress kullanıyorsanız yukarıdaki standart bloğu yazın; statik bir siteyse boş bir .htaccess da tamamen geçerlidir.
    4. Suçlu satırı bulun. Bozuk dosyayı bir metin düzenleyicide açın ve blokları teker teker geri ekleyip her eklemeden sonra siteyi yenileyin. Hata döndüğü an suçlu son eklediğiniz bloktur.
    5. Hata günlüğüne bakın. cPanel'de Ölçümler → Hatalar ekranı ya da ~/logs altındaki hata günlüğü, satır numarasını verebilir.

    Günlükte tipik olarak şuna benzer satırlar görürsünüz:

    Günlük satırıGerçek anlamı
    Invalid command 'RewriteRule'mod_rewrite yüklü değil ya da <IfModule> bloğu yok
    .htaccess: Option Indexes not allowed hereAllowOverride bu yönergeye izin vermiyor
    Syntax error on line 1414. satırda kapanmamış tırnak veya yanlış yazılmış yönerge
    Request exceeded the limit of 10 internal redirectsKendi kendini tekrarlayan yönlendirme döngüsü

    Son satır, RewriteRule ile HTTPS zorlaması yazıp koşulu yanlış kuran herkesin başına gelir; tarayıcı tarafında bu durum genellikle "çok fazla yönlendirme" hatasıyla görünür. 500 hatasının .htaccess dışındaki nedenleri için 500 internal server error çözümü yazısında bellek limiti, PHP hatası ve izin kaynaklı senaryolar da ele alınıyor.

    .htaccess Dosyasının Doğru Konumu ve İzinleri#

    Dosyanın hangi klasörde olduğu, ne yaptığı kadar önemlidir. Kurallar bulunduğu klasörden aşağı doğru geçerlidir; yukarı doğru etki etmez.

    KonumEtki alanıTipik kullanım
    public_html/.htaccessTüm ana siteHTTPS zorlama, genel yönlendirme
    public_html/blog/.htaccessYalnız blog klasörüKlasöre özel kural, parola koruma
    public_html/ikincisite.com/.htaccessYalnız ek alan adıO sitenin kendi kuralları
    public_html/wp-admin/.htaccessYönetim paneliYönetim paneline IP kısıtı

    Alt klasördeki bir .htaccess, üsttekinin aynı yönergesini ezer ama tamamını iptal etmez; ikisi birlikte uygulanır. Bu yüzden "kuralı yazdım ama çalışmıyor" durumlarında alt klasörde çakışan bir dosya olup olmadığına bakmak gerekir. Ek alan adı ve alt alan adı klasörlerinin nerede açıldığını hatırlamıyorsanız alt alan adı oluşturma yazısı klasör yerleşimini netleştirir.

    İzin tarafında doğru değer 644'tür. Dosyayı 666 ya da 777 yapmayın; yazılabilir bir yapılandırma dosyası, sunucuya sızan bir betiğin ilk hedefidir. 400 ya da 600 gibi çok kısıtlı değerler ise web sunucusunun dosyayı okumasını engelleyebilir ve yine 500 hatası üretir.

    chmod 644 ~/public_html/.htaccess
    

    Sık Kullanılan Bloklar ve Sınırları#

    Aşağıdaki bloklar günlük hayatta en çok ihtiyaç duyulanlardır. Her birini dosyanın sonuna değil, mantıklı bir sırayla ekleyin: yönlendirme kuralları yeniden yazma kurallarından önce gelmelidir.

    HTTPS'e zorlama:

    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
    

    Dizin listelemeyi kapatma:

    Options -Indexes
    

    Özel hata sayfası:

    ErrorDocument 404 /404.html
    

    Belirli bir dosyayı erişime kapatma:

    <Files "yapilandirma.ini">
    Require all denied
    </Files>
    

    Bu son blokta dikkat edilecek nokta sözdiziminin Apache sürümüne göre değişmesidir; eski Order deny,allow biçimi güncel sunucularda çalışmayabilir ve Invalid command hatası verir. İkisini aynı dosyada karıştırmayın. Yönlendirme kurallarını elle yazmak istemiyorsanız htaccess yönlendirme üretici aracıyla kuralı oluşturup dosyaya yapıştırabilir, robots dosyanız için de robots.txt üretici aracını kullanabilirsiniz. Yönlendirme mantığının ayrıntıları için htaccess yönlendirme yazısına bakın.

    WordPress .htaccess Dosyasını Kendi Yeniden Yazarsa#

    WordPress, kalıcı bağlantı ayarlarını her kaydettiğinizde # BEGIN WordPress ve # END WordPress işaretleri arasındaki bölümü yeniden yazar. Bu iki satırın arasına yazdığınız her şey er ya da geç silinir. Kendi kurallarınızı bu bloğun dışına, tercihen dosyanın en üstüne yazın:

    # 2026-08-11 - kendi kurallarim
    Options -Indexes
    ErrorDocument 404 /404.html
    
    # BEGIN WordPress
    # ... WordPress buraya kendi kurallarini yazar ...
    # END WordPress
    

    Bazı güvenlik ve önbellek eklentileri de kendi blok işaretlerini ekler. Aynı dosyada üç dört blok görmek normaldir; önemli olan hangi bloğun kime ait olduğunu yorum satırlarından takip edebilmektir. Eklentiyi kaldırdığınızda bloğun otomatik silinmediği durumlar da olur, bu yüzden temizlik yaparken önce yine yedek alın.

    Kuralın Gerçekten Çalıştığını Nasıl Doğrularsınız#

    Bir kuralı yazdıktan sonra tarayıcıda sayfayı yenileyip "oldu galiba" demek yanıltıcıdır, çünkü tarayıcı önbelleği özellikle 301 yönlendirmelerini uzun süre saklar. Bir kez 301 gördükten sonra tarayıcı bir daha sunucuya sormaz ve siz kuralı silseniz bile yönlendirme çalışmaya devam ediyormuş gibi görünür.

    Doğru test yöntemi, isteği önbelleksiz ve başlıklarıyla birlikte görmektir. SSH erişiminiz varsa:

    curl -I https://alanadiniz.com/eski-sayfa
    

    Çıktının ilk satırında durum kodunu, Location satırında ise nereye yönlendirildiğini görürsünüz:

    HTTP/2 301
    location: https://alanadiniz.com/yeni-sayfa
    

    SSH yoksa tarayıcının geliştirici araçlarında Ağ (Network) sekmesini açıp "önbelleği devre dışı bırak" kutusunu işaretlemek aynı bilgiyi verir. Test ederken gizli sekme kullanmak da önbellek etkisini büyük ölçüde ortadan kaldırır.

    Yönlendirme yazarken en sık yapılan üç hata şunlardır: kuralın sonuna [L] bayrağını koymamak ve sonraki kuralların da işlemesine izin vermek; RewriteBase değerini alt klasörde yanlış bırakmak; ve aynı adresi hem kendine hem başka bir hedefe yönlendiren iki kural yazıp döngü oluşturmak. Döngü durumunda tarayıcı sayfayı hiç açmaz ve fazla yönlendirme uyarısı verir; bu durumda son eklediğiniz bloğu geçici olarak yorum satırına almak (# ile başlatmak) sorunu anında yalıtır.

    Sıkça Sorulan Sorular#

    htaccess dosyası cPanel'de neden görünmüyor#

    Dosya adı noktayla başladığı için gizli sayılır ve Dosya Yöneticisi varsayılan ayarında gizli dosyaları listelemez. Sağ üstteki Ayarlar penceresinden "Gizli Dosyaları Göster" seçeneğini işaretlediğinizde dosya listede belirir. Bu tercih hesabınıza kaydedilir, her seferinde tekrar açmanız gerekmez. FTP kullanıyorsanız aynı ayarın istemci tarafında da açık olması gerekir.

    htaccess dosyası hiç yoksa site çalışır mı#

    Evet, .htaccess zorunlu bir dosya değildir ve olmadan da site sorunsuz açılır. Statik HTML sitelerin çoğunda hiç bulunmaz. Ancak WordPress'in yazı adresi biçimi, özel yönlendirmeler, HTTPS zorlaması ve dizin koruması gibi işlevler bu dosyaya bağlıdır; bunlara ihtiyacınız olduğunda dosyayı kendiniz oluşturmanız gerekir.

    htaccess dosyasını düzenledikten sonra site 500 hatası veriyor ne yapmalıyım#

    Önce dosyanın adını htaccess-bozuk gibi bir şeye çevirerek devre dışı bırakın; site açılıyorsa sorun kesinlikle bu dosyadadır. Sonra düzenleme öncesi aldığınız yedeği .htaccess olarak geri adlandırın. Yedeğiniz yoksa dosyayı boş bırakabilir ya da platformunuzun standart bloğunu yeniden yazabilirsiniz. Hatalı satırı bulmak için blokları teker teker geri ekleyip her adımda siteyi yenileyin.

    htaccess dosyasının izni kaç olmalı#

    Doğru izin 644'tür; yani sahibi okuyup yazabilir, diğerleri yalnızca okur. 666 veya 777 gibi yazılabilir değerler ciddi güvenlik riski yaratır çünkü sunucuya sızan bir betik yapılandırmanızı değiştirebilir. Çok kısıtlı değerler ise web sunucusunun dosyayı okumasını engelleyip 500 hatasına yol açar. Değeri Dosya Yöneticisi'ndeki İzinler ekranından ya da chmod 644 komutuyla ayarlayabilirsiniz.

    Her klasöre ayrı htaccess koyabilir miyim#

    Evet, her klasörün kendi .htaccess dosyası olabilir ve kuralları bulunduğu klasörle alt klasörleri için geçerlidir. Alt klasördeki dosya, üsttekinin aynı yönergesini kendi kapsamında ezer; ezilmeyen yönergeler ise birlikte uygulanmaya devam eder. Bu yüzden bir kuralın neden çalışmadığını ararken alt klasörlerde çakışan bir dosya olup olmadığını da kontrol etmek gerekir.

    Nginx sunucuda htaccess çalışır mı#

    Hayır, Nginx .htaccess dosyasını hiç okumaz; bu biçim Apache ve LiteSpeed'e özgüdür. Nginx altında aynı işleri sunucu yapılandırma dosyasındaki location blokları ve rewrite yönergeleriyle tanımlarsınız ve bu değişiklikler sunucu yeniden yüklenerek uygulanır. Paylaşımlı hostinglerin çoğu Apache veya LiteSpeed çalıştırdığı için .htaccess orada geçerlidir; kendi sunucunuzda Nginx varsa kuralları taşımanız gerekir.

    Windows'ta htaccess dosyası nasıl oluşturulur#

    Windows Gezgini adı yalnızca noktayla başlayan dosya oluşturmaya izin vermez, bu yüzden dosyayı sunucuda oluşturmak en sağlıklı yoldur. cPanel Dosya Yöneticisi'nde "+ Dosya" ile adını doğrudan .htaccess verebilir ya da önce htaccess.txt oluşturup yeniden adlandırabilirsiniz. Yerelde hazırlamanız gerekiyorsa Not Defteri yerine uzantı eklemeyen bir kod düzenleyici kullanın; aksi hâlde dosya sunucuya .htaccess.txt olarak çıkar ve hiçbir etkisi olmaz.

    Kapanış#

    .htaccess konusunda takılmanın nedeni neredeyse hiçbir zaman yönergelerin zorluğu değildir; dosyanın gizli olması, panelin noktayla başlayan ad konusunda çıkardığı zorluk ve bozulduğunda geri dönecek bir kopyanın bulunmamasıdır. Gizli dosya gösterimini bir kez açtığınızda birinci sorun kalıcı olarak biter. "Önce kopyala, sonra düzenle" alışkanlığını edindiğinizde ikinci sorun da biter; en kötü senaryoda dosyayı yeniden adlandırıp siteyi otuz saniyede ayağa kaldırırsınız. Blokları tarihli yorum satırlarıyla işaretlemek ise altı ay sonraki halinize yapabileceğiniz en iyi iyiliktir.

    Bu dosyayla uğraşırken hangi klasörde olduğunuzu netleştirmek isterseniz public_html nedir yazısı yapıyı baştan kurar. Sitenizin bu tür ayarlarını kendiniz yönetmek yerine hazır ve doğru yapılandırılmış bir ortamda çalışmak istiyorsanız cPanel'li web hosting paketleri gerekli modülleri açık şekilde sunar; WordPress kuruyorsanız WordPress hosting tarafında kalıcı bağlantı ve önbellek kuralları hazır gelir. Yönlendirme ve güvenlik kurallarını sizin yerinize kurup takip etmesini istediğiniz bir yapı arıyorsanız WordPress bakım hizmeti bu işi düzenli olarak üstlenir.

    htaccessdosya yöneticisicPanel

    Uygulamaya geçmeye hazır mısınız?

    NVMe SSD, ücretsiz SSL ve %99.9 uptime garantisiyle Clou.TR hosting ve sunucu çözümleriyle projenizi hayata geçirin.