KapsuleHost, her web sitesine .htaccess dosyasını okumayan yüksek performanslı bir web sunucusuyla hizmet verir, bu nedenle o dosyaya eklediğiniz kurallar hiçbir etki yaratmaz: bu kılavuz bunun bir WordPress sitesi için ne anlama geldiğini açıklar ve her işi onun yerine yapan KPanel ayarını gösterir.
Paylaşımlı bir cPanel barındırma hizmetinden geçtiyseniz, .htaccess muhtemelen yönlendirmeleri, HTTPS zorlamasını, özel hata sayfalarını ve bot engellemelerini yaptığınız yerdi. Bunların hepsi KapsuleHost'ta hâlâ çalışır. Sadece bir metin dosyası yerine KPanel'de ayarlanırlar ve sunucu düzeyinde uygulandıkları için hem daha hızlıdırlar hem de bir yazım hatasıyla sitenizi bozamazlar.
.htaccess Burada Neden İşe Yaramıyor
.htaccess, Apache web sunucusu için dizin başına yapılandırma dosyasıdır. Apache onu her istekte yeniden okur, bu da onu hem kullanışlı hem de yavaş yapan şeydir.
KapsuleHost, Apache çalıştırmaz. Siteniz, yapılandırmasını yalnızca başlangıçta bir kez yükleyen, olay güdümlü bir web sunucusu tarafından sunulur ve bu, buradaki sitelerin yük altında daha hızlı yanıt vermesinin büyük bir nedenidir. O sunucunun dizin başına geçersiz kılma dosyasına karşılık gelen bir özelliği yoktur, bu yüzden .htaccess dosyasını hiçbir zaman açmaz.
Bir KapsuleHost sitesinde .htaccess dosyasına kural eklemek sessizce başarısız olur. Hiçbir hata vermez, hiçbir uyarı çıkmaz ve dosya tam olarak bıraktığınız yerde kalır. Kurallar yalnızca hiç çalışmaz. "Bunu .htaccess dosyanıza ekleyin" diyen bir WordPress eğitimi takip ediyorsanız, bunun yerine aşağıdaki tabloda KPanel karşılığını bulun.
İyi haber şu ki, bu durum, klasik .htaccess korku hikâyesinin tam tersidir: dosyadaki bir sözdizimi hatası sitenizi burada çökertemez, çünkü onu hiç kimse ayrıştırmaz.
Onsuz Hâlâ Çalışan Şeyler
Kalıcı bağlantılar. Bir WordPress sitesinin Apache'de .htaccess dosyasına ihtiyaç duymasının en yaygın tek nedeni, okunabilir kalıcı bağlantılardır (pretty permalinks). KapsuleHost'ta yeniden yazma (rewrite), sitenizin sunucu yapılandırmasına dahil edilmiştir, bu yüzden /2026/07/my-post/, hiçbir .htaccess bloğu olmadan WordPress üzerinden çözümlenir. Kalıcı bağlantılar 404 hatası veriyorsa, neden başka bir şeydir: bkz. WordPress Kalıcı Bağlantı Sorunlarını Giderme.
WordPress'in dosyaya yazması. WordPress ve bazı eklentiler, Apache varsaydıkları için .htaccess dosyasına hâlâ # BEGIN/# END blokları yazar. Bu zararsızdır. Dosya gerçektir, yazılabilirdir ve dosya yöneticisinde görürsünüz. Sadece bir okuyucusu yoktur.
"Sıkılaştırma uygulandı" bildiren güvenlik eklentileri. .htaccess dosyasını düzenleyerek xmlrpc.php veya wp-config.php dosyasını kilit altına aldığını iddia eden eklentiler, bu platformda aslında hiçbir şeyi korumamıştır. Bunun yerine, sunucuda eşdeğer kuralları uygulayan sitenin kendi Güvenlik sekmesini kullanın.
Yaygın .htaccess Kuralları İçin KPanel Karşılıkları
Bunların her biri sitenin kendisinde yer alır: Web Siteleri, ardından siteniz, ardından gösterilen sekme.
| .htaccess'te yazacağınız şey | KPanel'de nerede yer alıyor |
|---|---|
HTTPS'yi zorlamak için RewriteCond %{HTTPS} off | Ayarlar, ardından Behavior altında HTTPS Zorla |
Redirect 301 /old /new | Ayarlar, ardından Yönlendirmeler |
ErrorDocument 404 /404.html | Ayarlar, ardından Hata sayfaları |
Bir klasörü parola korumak için AuthType Basic | Ayarlar, ardından Parola koruması |
Bir adresi engellemek için Require not ip 203.0.113.4 | WordPress, ardından Güvenlik |
Tarayıcıları (crawler) engellemek için RewriteCond %{HTTP_USER_AGENT} (BadBot) | Performans, ardından Tarayıcılar |
DirectoryIndex index.php index.html | Serving altında Ayarlar, ardından Dizin dizini |
Sıkıştırma ve önbellekleme için mod_deflate / mod_expires | Zaten etkin. Sıkıştırma ve önbellek başlıkları sunucuda ayarlanır |
Bunlardan ikisi, .htaccess sürümünün hiçbir zaman yapamayacağı kadar çok şey yapar. Yönlendirmeler, tam yolları, sondaki eğik çizgi önekli (trailing-slash) yolları ve /blog/* gibi joker karakterleri destekler ve KPanel, kaydettikten sonra yönlendirmeyi canlı olarak doğrular. Hata sayfaları gerçek durum kodlarıyla sunulur, bu yüzden özel bir 404 sayfası, arama motorları için üzerinde özür yazan bir 200 yerine, hâlâ gerçek bir 404'tür.
Dosyayı Bulma ve Okuma
Genellikle bir eklentinin içine ne yazdığını görmek veya kuralları KPanel'de yeniden oluşturmadan önce kopyalamak için .htaccess dosyasına hâlâ bakmak isteyebilirsiniz.
WordPress sekmesinden
- KPanel oturumunuzu açın ve sol kenar çubuğunda Web Siteleri öğesine tıklayın.
- İstediğiniz siteye tıklayın.
- WordPress sekmesini, ardından wp-config bölümünü açın.
.htaccesspaneline kadar aşağı kaydırın. İçerik salt okunur olarak gösterilir, değiştirmeniz gerekirse bir Edit düğmesi bulunur.
Dosya yöneticisinden
- Siteyi açın, ardından Ayarlar, ardından Dosya Yöneticisi.
- Araç çubuğunda Gizli Dosyaları Göster öğesine tıklayın. Nokta ile başlayan dosyalar varsayılan olarak gizlidir, bu yüzden bunu yapmadan
.htaccessgörünmez. - Yerleşik düzenleyicide açmak için
.htaccessöğesine tıklayın.
Dosya, sitenizin kök dizininde, wp-config.php ve wp-content ile birlikte bulunur. Düzenleyici ve izin kontrolleri hakkında tam ayrıntı için bkz. Dosya Yöneticisini Kullanma.
Site kökünde herhangi bir şeyi düzenlemeden önce, okunmayan bir dosya olsa bile, bir yedek alın. Hiçbir maliyeti yoktur ve tek bir tıklamayla eski haline dönmenizi sağlar. Bkz. Yedek Alma.
Varsayılan WordPress Bloğu
Referans olması için, bu WordPress'in kendisi için yazdığı bloktur. Bir Apache sunucusunda kalıcı bağlantıları yönetir. KapsuleHost'ta ise işlevsizdir ve silinmesi hiçbir şeyi bozmaz:
# 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
Siteyi ileride bir Apache sunucusuna taşıyabilecekseniz, yerinde bırakın. Kalıcı bağlantı ayarlarınızı bir sonraki kaydedişinizde WordPress onu zaten yeniden yazacaktır.
Kuralları Taşıyorsanız
Bir siteyi cPanel'den aktardığınızda, eski barındırmayı iptal etmeden önce eski .htaccess dosyasını açın ve satır satır inceleyin:
- Yönlendirmeler. Her bir
RedirectveyaRewriteRulekuralını Ayarlar, ardından Yönlendirmeler içinde yeniden oluşturun. Kural başına bir satır. Kalıcı bir taşıma için 301, değişiklik tersine dönebilirse 302 seçin. - HTTPS zorlaması. Silin. Bunun yerine sitenin Ayarlar bölümünde HTTPS Zorla öğesini etkinleştirin.
- IP engelleri. IP engelleme panelinde, WordPress, ardından Güvenlik içinde yeniden oluşturun.
- Önbellekleme ve sıkıştırma başlıkları. Bunları silin. Sizin için zaten halledilir ve eski bir barındırmadan kalan güncelliğini yitirmiş
mod_expireskuralları, kafa karıştırıcı önbellek davranışının yaygın bir kaynağıdır. - Bir eklentinin yazdığı her şey. Göz ardı edin. Eklentiyi yeni sitede yeniden kurun ve kendi işini kendisinin yapmasına izin verin.
Taşıma işleminiz dosyanın kendisini korur, bu yüzden listeyi incelerken hiçbir şey kaybolmaz. Tam taşıma kılavuzu için: Bir Web Sitesini cPanel'den Taşıma.
Sorun Giderme
".htaccess'e bir yönlendirme ekledim ve hiçbir şey olmadı." Beklenen durum budur. Bunu Ayarlar, ardından Yönlendirmeler içinde ekleyin. Oradaki Status sütunu, yönlendirmenin canlı olarak doğrulanıp doğrulanmadığını size söyler.
"Bir eklenti sitemin sıkılaştırıldığını söylüyor ama bir tarayıcı buna katılmıyor." Eklenti, okunmayan .htaccess kuralları yazmış. Gerçekten uygulanan korumalar için sitenin Güvenlik sekmesini kontrol edin.
"Eski barındırıcımın .htaccess dosyasında anlamadığım kurallar vardı." Bunları körü körüne kopyalamayın. Dosyayı ekleyerek bir destek talebi açın, hangilerinin bir KapsuleHost karşılığı olduğunu ve hangilerinin yalnızca paylaşımlı bir Apache sunucusunu telafi ettiğini size söyleyelim.
"Kalıcı bağlantılar bozuk." Bu burada bir .htaccess sorunu değildir. WordPress Kalıcı Bağlantı Sorunlarını Giderme sayfasına gidin veya sitenin WordPress sekmesinden, ardından Hızlı İşlemler, ardından Yeniden Yazım Kurallarını Temizle ile yeniden yazım kurallarını temizleyin.