WordPress Hosting nedir?

WordPress hosting tam olarak neyi ayarlar?

WordPress hosting, sunucunun ve üzerindeki yazılım katmanının tek bir uygulamanın davranışına göre önceden ayarlandığı barındırma biçimidir. Genel amaçlı bir hosting size boş bir alan ve bir PHP çalışma ortamı verir; ne kuracağınızı bilmediği için ortalamaya göre ayarlanmıştır. WordPress hosting ise ne kuracağınızı zaten bilir: bir PHP uygulaması, bir MySQL/MariaDB veritabanı, ağırlıklı olarak okuma yapan bir trafik profili, wp-admin üzerinden çalışan bir yönetim arayüzü ve sürekli güncellenen bir eklenti ekosistemi.

Bu bilgi somut ayarlara dönüşür. Sayfa önbelleği bir eklentiyle uygulamanın içinde değil, sunucu seviyesinde (NGINX FastCGI cache veya LiteSpeed LSCache) yapılır; böylece istek PHP'ye hiç uğramadan yanıtlanır. Redis bir object cache olarak devreye girer ve tekrarlayan WP_Query ile transient sorgularını bellekten karşılar. PHP-FPM worker sayısı, OPcache ayarları ve MariaDB'nin buffer pool'u WordPress'in bellek profiline göre düzenlenir. Üstüne bir de operasyonel katman gelir: staging ortamı, snapshot'lı otomatik güncelleme ve WordPress'e özgü saldırılara karşı hazır güvenlik kuralları.

Yani WordPress hosting'in özü yeni bir teknoloji icat etmek değil; her site sahibinin tek tek kurmaya çalıştığı bu yapılandırmayı sizin için varsayılan hâline getirmek. Altyapı tarafındaki temeller için Bilgi Merkezi · Cloud & Altyapı ve Önbellekleme & Redis rehberlerine bakabilirsiniz.

Neden WordPress sitenize özel bir hosting tercih etmelisiniz?

Bu sorunun cevabı tek bir cümleye sığmıyor, çünkü kazanç birden fazla yerden geliyor. Sitenizin günlük hayatında karşılığı olan başlıklarla gidelim:

• Aynı donanımla çok daha fazla ziyaretçi — sayfa önbelleği sunucu seviyesinde çalıştığında istek PHP'ye ve veritabanına hiç inmez. Bu tek değişiklik, aynı kaynakla 5–10 kat daha fazla eşzamanlı kullanıcıya yanıt verebilmek anlamına gelir. Kampanya günlerinde siteyi ayakta tutan şey genelde daha büyük sunucu değil, bu katman.
• Güncellemeler kumar olmaktan çıkar — güncelleme öncesi otomatik snapshot alınır, sonrasında site sağlık kontrolünden geçer; bir şey bozulursa değişiklik geri alınır. "Eklentiyi güncelleyip beklemek" yerine, geri dönüşü hazır bir süreç devreye girer.
• Saldırganın bildiği kapılar önceden kapanır — WordPress'e yönelen saldırılar rastgele değil; wp-login.php, xmlrpc.php, uploads/ klasörü ve eski eklentiler üzerinden gelir. WordPress hosting bu noktaları varsayılan olarak sıkılaştırır.
• Eklenti yığınınız hafifler — önbellek, yedekleme ve görsel optimizasyonu sunucu tarafında yapıldığında bu işler için kurduğunuz üç beş eklentiye gerek kalmaz. Her kaldırılan eklenti, bir bakım yükü ve bir güvenlik açığı adayı daha az demek.
• Deneyip geri alabileceğiniz bir yer olur — staging ortamı, tema ve eklenti değişikliklerini canlı siteyi riske atmadan denemenizi sağlar. Bir WooCommerce checkout değişikliğini ilk kez müşterinin üzerinde test etmek zorunda kalmazsınız.
• Destek WordPress'in dilini konuşur — "sitem yavaşladı" dediğinizde konuşma cache hit oranından, yavaş sorgulardan ve eklenti çakışmasından başlar. Her gün aynı uygulamayla çalışan bir ekip sorunu tanıdığı için daha hızlı çözer.

Hız farkı tam olarak nereden geliyor?

WordPress'te bir sayfanın açılma süresi, isteğin kaç katmandan kaçabildiğiyle doğru orantılı. Genel amaçlı bir kurulumda her istek en uzun yolu yürür: web sunucusu, PHP-FPM, WordPress'in kendi yükleme zinciri, eklentiler, sonra veritabanı. Önbellek doğru katmanda çalıştığında bu zincirin tamamı devre dışı kalır ve sayfa doğrudan diskten servis edilir.

genel amaçlı hosting
  istek → Apache → PHP-FPM → WordPress → MySQL → yanıt
                    her istekte baştan

WordPress hosting
  istek → NGINX / LSCache HIT → yanıt
                    PHP hiç çalışmaz

  istek → NGINX MISS → PHP-FPM + OPcache → WordPress
                                  ↓
                        Redis object cache HIT → yanıt
                                  ↓ MISS
                             MariaDB (tuned)

Pratikte iki sayı belirleyici oluyor: cache hit oranı ve TTFB. Hit oranı %95'in üzerindeyse ziyaretçilerin neredeyse tamamı en kısa yoldan yanıt alır; bizim hedefimiz cache hit'te 100 ms altı TTFB. Hit oranı düşükse sebebi genellikle donanım değil yapılandırma: yanlış ayarlanmış bir TTL, önbelleği gereksiz yere devre dışı bırakan bir eklenti ya da her sayfaya çerez basan bir tema. Bunlar WordPress'i tanıyan bir kurulumda baştan doğru ayarlanır. Ölçümün nasıl yapıldığını Performans & Web Vitals rehberimizde ayrıntılı anlatıyoruz.

Bir güncelleme siteyi bozduğunda ne oluyor?

WordPress dünyasında kesintilerin en yaygın sebebi saldırı değil, güncelleme. Bir eklentinin yeni sürümü temayla çakışır, ölümcül bir PHP hatası çıkar ve site beyaz ekrana düşer. Genel amaçlı bir hosting'de bu noktada elinizde genellikle dünkü bir yedek ve bir telefon görüşmesi olur.

WordPress hosting bu senaryoyu bir sürece dönüştürür: güncelleme öncesi tam snapshot alınır, güncelleme uygulanır, ardından site otomatik sağlık kontrolünden geçer — HTTP 200 dönüyor mu, kritik sayfalar yükleniyor mu, ölümcül bir PHP hatası var mı. Kontrol başarısızsa değişiklik otomatik geri alınır ve panelinize bildirim düşer. Riskli gördüğünüz eklentiler içinse önce staging'de test, sonra üretime aktarma yolu var: tek tıkla canlı sitenin kopyası oluşur, arama motorlarına kapalı ve şifre korumalı çalışır; sonuçtan memnunsanız dosyaları, veritabanını ya da ikisini seçerek canlıya taşırsınız.

Yedek tarafında aradığınız asıl güvence "yedek alıyoruz" cümlesi değil, geri dönüşün ne kadar sürdüğü. Günlük snapshot ve 7 gün rotasyon standart; önemli olan bunu istediğiniz anda dakikalar içinde uygulayabilmek. Sürekliliğin genel çerçevesi için Yedekleme & Felaket Kurtarma rehberine göz atabilirsiniz.

WordPress'e özel saldırılara karşı ne değişiyor?

WordPress internetin çok büyük bir bölümünü çalıştırdığı için otomatik saldırı araçlarının da varsayılan hedefi. Bu araçlar sizin sitenizi tanımaz; yalnızca WordPress'in alışkanlıklarını bilir ve hep aynı kapıları dener. İyi haber şu: hedef listesi tahmin edilebilir olduğu için savunma da hazır yapılabilir.

• Giriş denemeleri sınırlanır — wp-login.php sunucu seviyesinde hız sınırına alınır, başarısız denemeler IP bazında bloklanır. Parola tahmini saldırıları ek bir eklenti gerektirmeden durur.
• XML-RPC varsayılan olarak kapalı — ihtiyacınız varsa açılır, yoksa kapalı durur. Bu tek ayar, hem brute-force hem de yükseltmeli saldırılar için kullanılan bir kanalı kapatır.
• Yükleme klasöründe kod çalışmaz — wp-content/uploads içinde PHP yürütülmesi engellenir. Bir görselin arkasına gizlenmiş dosyanın çalıştırılması böylece baştan imkânsız hale gelir.
• Dosya değişiklikleri izlenir — core, tema ve eklenti dosyalarındaki beklenmedik değişiklik dakikalar içinde alarm üretir. Bir sızma erken yakalandığında kaybın büyüklüğü tamamen değişir.
• Bilinen eklenti açıkları edge'de engellenir — OWASP Core Rule Set'in yanında WordPress'e özel kurallar çalışır; imzası bilinen istismar girişimleri siteye ulaşmadan durur.
• Sertifika işi kendiliğinden yürür — Let's Encrypt sertifikaları otomatik kurulur ve yenilenir. Sertifika ömürleri kısalırken bunu elle takip etmenin neden sürdürülemez olduğunu ayrı bir yazıda ele aldık.

Bunların hiçbiri egzotik bir teknoloji değil; hepsi WordPress'i tanıyan birinin zaten yapacağı ayarlar. Fark, bu ayarların sizi bekleyen bir yapılacaklar listesi olarak değil, hesabınız açıldığı anda hazır gelmesinde. Konunun temelleri için Web Uygulama Güvenliği rehberimize bakabilirsiniz.

WooCommerce mağazanız için neden daha da önemli?

Bir içerik sitesinde önbellek işini kolayca yapar: sayfa herkese aynı görünür, bir kez üretilir, herkese aynı kopya gider. Mağazada durum değişir; sepet, checkout ve hesap sayfaları her ziyaretçiye özeldir. Bu sayfalar yanlışlıkla önbelleğe alındığında hızlı görünen bir mağazada müşteriler birbirinin sepetini görebilir. Bu yüzden WooCommerce için doğru yapılandırma önbelleği kapatmak değil, bypass kurallarını doğru kurmaktır: sepet, ödeme ve oturum açmış kullanıcı önbelleğin dışında kalır, kataloğun geri kalanı önbellekten uçar.

İkinci mesele yoğunluk. Mağazalar trafiği düz almaz; kampanya duyurusundan sonraki ilk yarım saat yılın geri kalanından bambaşka davranır. Bu tür planlı yoğunluklarda kapasitenin önceden hazırlanması, trafik patladığında yatay ölçeklendirmenin devreye girmesi ve sepet ile checkout adım sürelerinin ayrı ayrı izlenmesi gerekir. Genel amaçlı bir paketle bunların hiçbiri imkânsız değil, ama hepsini kendiniz kurmanız ve o gece başında beklemeniz gerekir.

Genel amaçlı hosting hangi durumlarda yeterli olur?

Dürüst olmak gerekirse her site için WordPress hosting'e ihtiyaç yok. Ayda birkaç yüz ziyaretçi alan tek sayfalık bir tanıtım sitesi çalıştırıyorsanız fark çoğu zaman hissedilmez. Benzer şekilde, kendi altyapısını kurmayı bilen ve bunu zaten yapan bir ekibiniz varsa cloud hosting ya da VPS üzerinde tam denetim daha mantıklı olabilir; o durumda istediğiniz şey hazır yapılandırma değil, ham kapasitedir.

Terazinin diğer tarafına ise şunlar ağırlık yapıyor: siteniz gelir üretiyorsa, bir saatlik kesintinin gerçek bir maliyeti varsa, site üzerinde birden fazla kişi çalışıyorsa, WooCommerce ya da üyelik gibi önbelleğe duyarlı bir katman varsa ve sunucu ayarlarıyla uğraşmak istemiyorsanız — fark çok hızlı kendini gösterir. Basit bir ölçüt: sitenin çalışmadığı bir saat sizi maddi olarak ya da itibar olarak üzüyorsa, o site artık ayarlanmış bir altyapıyı hak ediyor.

Mevcut WordPress sitenizi taşımak ne kadar sürer?

Bu noktada en sık duyduğumuz çekince geçişin kendisi oluyor: "site kapanır mı, e-postalar bozulur mu, SEO'm etkilenir mi?" İşleyiş şöyle: önce sitenizin bir kopyası hedef sunucuda kurulur ve geçici bir alt alan adında test edilir. Veritabanı canlıyla senkronize tutulur, DNS TTL'i geçiş öncesinde düşürülür. Geçiş anında son veri farkı aktarılır, trafik yeni sunucuya yönlenir ve eski sunucu bir süre yedek olarak ayakta kalır — bir sorun çıkarsa geri dönüş anında mümkün.

Tipik bir WordPress sitesi bu yolla 1–4 saat içinde, ziyaretçi kesinti hissetmeden taşınır; dosyalar, veritabanı, e-posta yapılandırması ve SSL sertifikası dahil. Bizde geçiş ücretsiz, birden fazla siteyi aynı pencerede taşımak da mümkün. Sonrasındaki ilk 30 gün yakın takipte geçer: cache TTL'leri, bypass kuralları, görsel optimizasyonu ve alarm eşikleri sitenizin gerçek trafiğine göre ayarlanır.

Peki geriye ne kalıyor?

WordPress hosting'i özel kılan şey daha güçlü bir makine değil; sitenizin hangi uygulamayı çalıştırdığını bilen ve buna göre ayarlanmış bir yığın. Önbellek doğru katmanda, güncelleme geri alınabilir bir süreçte, güvenlik kuralları saldırganın denediği yerlerde ve alarmlar sizin yerinize birinin telefonunda. Bunların hepsini kendiniz de kurabilirsiniz — soru kurulabilir olup olmadığı değil, bu işi üstlenmek isteyip istemediğiniz.

Sitenizi nerede barındıracağınıza karar verirken bize en sağlıklı gelen yaklaşım şu: paketin özellik listesini değil, kendi haftanızı düşünün. Geçen ay kaç kez eklenti güncellemesinden sonra siteyi kontrol etmek zorunda kaldınız, kaç kez "yavaşladı mı acaba" diye merak ettiniz, yedekten dönmeyi en son ne zaman denediniz? Bu soruların cevabı, hangi hosting biçimine ihtiyacınız olduğunu fiyat tablosundan daha net söyler.

Bizim tarafta paketin içinde tam olarak neyin olduğunu, hangi hedeflere ölçülebilir biçimde bağlı kaldığımızı ve neyi neden yapmadığımızı WordPress Hosting sayfamızda ayrıntılı anlatıyoruz. Mevcut kurulumunuza birlikte bakıp nerede kazanç olduğunu görmek isterseniz, ilk görüşme bizden.