WORDPRESS HOSTİNG NEDİR, SIRADAN HOSTİNGTEN FARKI NE?

WordPress hosting, pazarlama dilinde sıkça kullanılan ama teknik karşılığı çoğu zaman anlatılmayan bir etikettir. Kimi sağlayıcıda normal paylaşımlı paketin üzerine yapıştırılmış bir isimden ibarettir, kimi sağlayıcıda ise gerçekten farklı bir altyapı sunar. Farkı anlamanın yolu vaatlere değil, ölçülebilir kalemlere bakmaktan geçer: PHP sürümü, PHP worker sayısı, önbellek katmanı, staging ortamı ve yedek politikası. Aşağıda WordPress hosting 2026'da nasıl seçilir sorusunu resmi gereksinimlerden başlayarak yanıtlıyoruz: hangi özellik gerçekten fark yaratıyor, hangi vaat sadece pazarlama cümlesi ve satın almadan önce nereye bakmanız gerekiyor. Kısa cevap: paketin adına değil, ölçüsüne bakın.

WordPress Hosting'i Sıradan Hostingten Ayıran Ne?

Teknik olarak WordPress her standart PHP ve MySQL sunucusunda çalışır, yani özel bir paket almadan da site yayınlayabilirsiniz. Fark, sunucunun WordPress'in davranışına göre ayarlanmış olup olmamasındadır. Gerçek bir WordPress paketinde şunları ararsınız: WordPress'e uygun PHP sürümü ve bellek limiti, sayfa önbelleği ile object cache, WP-Cron'un sistem cron'una devredilmesi, staging ortamı, günlük yedek ve geri dönüş, WordPress farkındalığı olan bir güvenlik katmanı. Etiketin kendisi hiçbir şey garanti etmez; "WordPress hosting" yazan bir paket, arka planda normal paylaşımlı barındırma olabilir. Ayırt etmenin en hızlı yolu, sağlayıcıya somut sorular sormaktır: PHP sürümü kaç, kaç PHP worker veriyorsunuz, sunucu tarafında hangi önbellek var, staging var mı, yedek günlük mü ve geri dönüş self servis mi. Yanıtları net vermeyen bir sağlayıcı, muhtemelen farkı da sunmuyordur. Hosting türlerinin genel çerçevesini hosting nedir rehberimizde, sağlayıcı karşılaştırmasını ise en iyi hosting firmaları yazımızda ele aldık.

WordPress'in Resmi Sunucu Gereksinimleri

Karar vermenin en sağlam zemini tahmin değil, resmi belge. WordPress.org'un gereksinimler sayfasına göre önerilen yapı PHP 8.3 veya üzeri, MariaDB 10.11 ve üzeri ya da MySQL 8.0 ve üzeri, sunucu yazılımı olarak Apache veya Nginx ve her kurulum için HTTPS. Aynı sayfa, WordPress'in hâlâ PHP 7.4 ve MySQL 5.5.5 gibi eski sürümlerde çalışabildiğini ama bunların destek dışı olduğunu ve güvenlik riski taşıdığını belirtiyor. Pratik anlamı şudur: bir sağlayıcı size PHP 7.x veriyorsa ya da PHP sürümünü panelden değiştirmenize izin vermiyorsa, orada durup düşünün. Kontrolü kendiniz yapabilirsiniz: WordPress yönetim panelinde Araçlar bölümündeki Site Sağlığı ekranı PHP ve veritabanı sürümünü gösterir. Barındırma seçerken sorulacak ilk soru fiyat değil, hangi PHP sürümünü ve hangi veritabanı motorunu sunduklarıdır.

Karşılaştırma tablolarında neredeyse hiç görünmeyen bir ayrıntı daha var: "PHP 8 destekliyoruz" cümlesi tek başına hiçbir şey söylemez, çünkü 8 serisinin alt sürümleri aynı takvimde desteklenmiyor. PHP'nin resmi destek takvimine göre tablo şöyle:

• PHP 8.2: aktif desteği bitti, yalnızca güvenlik yaması alıyor, o da 31 Aralık 2026'da kapanıyor.
• PHP 8.3: aktif desteği bitti, güvenlik yaması 31 Aralık 2027'ye kadar sürüyor.
• PHP 8.4: 31 Aralık 2026'ya kadar aktif destekte.
• PHP 8.5: 31 Aralık 2027'ye kadar aktif destekte.

Pratik karşılığı net: 2026 kapandığında PHP 8.2 üzerinde kalan bir site, WordPress çalışmaya devam etse bile artık yamalanmayan bir yorumlayıcının üstünde duruyor olacak. Sağlayıcıya sorulacak doğru soru "PHP 8 var mı" değil, panelden hangi alt sürümleri seçebildiğiniz ve yeni bir sürüm çıktığında bunun ne kadar sürede eklendiğidir. Yanıt "otomatik güncelliyoruz" ise, bir örnek isteyin.

WordPress.org'un Önerilen Listesi: İçeride Kim Var?

WordPress.org'un hosting sayfasında yalnızca üç sağlayıcı yer alıyor: Pressable, Bluehost ve Hostinger. Liste beklenenden çok daha kısa, kendi hakkındaki şeffaflığı da ilginç. Sayfanın kendisi seçim sürecini kendi ifadesiyle tamamen keyfi olarak tanımlıyor ve ölçütler arasında WordPress.org'a katkı, müşteri tabanı büyüklüğü, otomatik kurulum kolaylığı, GPL uyumu ve hatta WordPress kelimesinin doğru büyük harfle yazılması gibi maddeler sayılıyor. Aynı sayfa ticari ilişkiyi de açıkça beyan ediyor: bazı sağlayıcılar bu sayfa üzerinden gelen satışın bir kısmını WordPress.org'a bağışlıyor ve Pressable'ın Automattic'e ait olduğu belirtiliyor. Doğru okuma şu: listede olmak bir performans garantisi değil, listede olmamak da kötü sağlayıcı anlamına gelmiyor. Listeyi bir başlangıç noktası olarak kullanın, karar ölçütü olarak değil.

Yönetilen WordPress Hosting Ne Satın Alıyor?

Yönetilen (managed) paketlerin fiyat farkı çoğunlukla donanımdan değil, operasyondan gelir. Aldığınız şey şudur: çekirdek ve eklenti güncellemelerinin izlenmesi, sunucu düzeyinde WordPress'e ayarlanmış önbellek, hazır staging ortamı, günlük otomatik yedek ve tek tıkla geri dönüş, WordPress'e özgü saldırı kalıplarını tanıyan güvenlik katmanı ve WordPress bilen bir destek ekibi. Yönetilen paketlerin bilinen kısıtları da var: eklenti kara listeleri (özellikle önbellek ve yedek eklentileri), sınırlı sunucu erişimi ve ziyaret bazlı fiyatlandırma. Karar kuralı basit: kendi bakımınızı yapacak teknik zamanınız ve bilginiz varsa yönetilen paketin priminden tasarruf edebilirsiniz; yoksa yönetilen paket aslında bir bakım hizmeti satın almaktır ve çoğu işletme için ucuz kalır. Yönetilen paket alırken hangi eklentilerin yasaklı olduğunu ve trafik aşımında ne olduğunu mutlaka önceden sorun. Kendi durumunuzu hızlı test etmek isterseniz şu soruyu yanıtlayın: son üç ayda WordPress güncellemelerini kim yaptı ve bir şey bozulduğunda kaç saatte toparlandı? Yanıt "kimse" ya da "günlerce" ise, primi ödemek yapmadığınız bakımın maliyetinden ucuza gelir.

Otomatik Güncelleme: WordPress Zaten Neyi Kendi Yapıyor?

Sağlayıcıların en çok pazarladığı özellik otomatik güncellemedir, ama WordPress'in kendisi bunun bir kısmını zaten yapıyor. Resmi geliştirici dokümantasyonuna göre küçük çekirdek sürümleri ve çeviri dosyaları varsayılan olarak otomatik güncelleniyor; WordPress 5.6 sonrasındaki yeni kurulumlarda büyük çekirdek sürümleri de varsayılan olarak otomatik geliyor. Asıl boşluk eklenti ve temalardadır: bunlar varsayılan olarak otomatik güncellenmez, tek istisna WordPress.org tarafının kritik güvenlik açıkları için tetiklediği özel durumlardır. Güvenlik açıklarının ezici çoğunluğunun eklentilerden geldiğini WordPress rehberimizde ele almıştık; dolayısıyla bir sağlayıcının otomatik güncelleme vaadini değerlendirirken tek soru şudur: eklentileri de güncelliyor mu, güncelledikten sonra siteyi test ediyor mu ve bir şey bozulursa geri alabiliyor mu. Test ve geri dönüş olmadan yapılan otomatik eklenti güncellemesi, çözdüğünden fazla sorun çıkarabilir.

Önbellek Katmanları: LiteSpeed, FastCGI ve Object Cache

WordPress her sayfa isteğinde PHP çalıştırıp veritabanına sorgu attığı için önbellek en yüksek getirili performans kalemidir. Üç katman vardır. Sayfa önbelleği, üretilen HTML'i saklayıp aynı sayfayı PHP çalıştırmadan sunar; sunucu tarafında LiteSpeed'in LSCache'i ya da Nginx FastCGI önbelleği bunu yapar. Object cache, tekrarlayan veritabanı sorgularının sonucunu bellekte tutar ve Redis ya da Memcached ile çalışır; özellikle dinamik ve giriş yapılmış sayfalarda fark yaratır. Tarayıcı önbelleği ise statik dosyaları ziyaretçide tutar. Burada bilinmesi gereken kritik bir ayrıntı var: LiteSpeed Cache eklentisinin otomatik sayfa önbelleği ve akıllı temizleme özellikleri yalnızca LiteSpeed tabanlı sunucularda ya da QUIC.cloud ile çalışır; Apache veya Nginx üzerinde eklentiyi kursanız da yalnızca genel özellikleri (küçültme, tembel yükleme gibi) kullanabilirsiniz. Yani eklentiyi kurmak yetmez, sunucunun onu desteklemesi gerekir.

PHP Worker: WordPress Hosting'de Asıl Darboğaz

Paket karşılaştırmalarında en az konuşulan ama en belirleyici kalem PHP worker sayısıdır. PHP worker, gelen bir isteği işleyen tek bir PHP sürecidir; eşzamanlı ziyaretçilerde her önbelleklenmemiş istek bir worker'a atanır ve tüm worker'lar meşgulse yeni istekler sırada bekler. Sonuç, sunucu kaynağı boşta olsa bile sitenin yavaşlaması ya da hata vermesidir. Kritik nokta şudur: sayfa önbelleği devredeyse ziyaretçilerin çoğu PHP'ye hiç dokunmaz, dolayısıyla worker ihtiyacı düşer. Önbelleklenemeyen işlemler ise doğrudan worker tüketir: sepet ve ödeme sayfaları, giriş yapmış kullanıcılar, site içi arama, form gönderimleri ve yönetim paneli işlemleri. Dolaşımda "blog için 4, e-ticaret için 6 worker yeterlidir" gibi rakamlar var, ancak bunların hiçbiri sağlayıcı belgelerine dayanmıyor; bu yüzden sabit bir sayı vermek yanıltıcı olur. Doğru yaklaşım sağlayıcıya kaç worker verdiğini sormak, sınırı aşınca ne olduğunu öğrenmek ve trafiğiniz büyüdükçe worker kullanımını izlemektir.

TTFB ve Sunucunun Hıza Katkısı

Hosting seçiminin performansa etkisini ölçmenin en doğrudan yolu sunucu yanıt süresine bakmaktır. web.dev'in TTFB rehberine göre 800 milisaniye ve altı iyi, 800 ile 1800 milisaniye arası iyileştirme gerektiren, 1800 milisaniyenin üzeri kötü kabul edilir. Aynı kaynak, TTFB'nin bir Core Web Vitals metriği olmadığını ama FCP ve LCP'den önce geldiğini belirtiyor; yani sunucu yavaşsa kullanıcı deneyimi metrikleri de peşinden bozulur. Core Web Vitals eşiklerini ve iyileştirme yollarını ayrı bir rehberde ele aldık. Sunucu tarafında TTFB'yi belirleyen üç şey var: PHP ve veritabanı sürümü, sayfa önbelleğinin devrede olup olmadığı ve ziyaretçiye fiziksel yakınlık. Test yaparken tek bir ölçümle karar vermeyin; farklı saatlerde ve önbellek boşken de ölçün, çünkü önbellekli bir sayfanın TTFB'si sunucunun gerçek kapasitesini gizler.

Staging, Yedek ve Geri Dönüş

WordPress'te güncelleme kaynaklı bozulma sık görüldüğü için staging ve yedek pazarlık konusu değildir. Staging, sitenizin canlıya dokunmayan bir kopyasıdır; eklenti güncellemelerini, tema değişikliklerini ve PHP sürüm yükseltmelerini önce orada denersiniz. Yedekte sorulacak dört soru vardır: sıklık nedir, yedek nerede saklanır, kaç gün geriye gidebilirsiniz ve geri dönüşü kendiniz yapabiliyor musunuz. Sunucuyla aynı diskte tutulan yedek gerçek bir yedek sayılmaz, çünkü sunucu düzeyinde bir sorun yedeği de götürür. Geri dönüşün self servis olması kritiktir; destek talebi açıp saatlerce beklemek, bir e-ticaret sitesinde doğrudan gelir kaybıdır. Bir de zamanlanmış görev ayrıntısı var: WordPress'in resmi dokümantasyonuna göre WP-Cron gerçek bir sistem cron'u değildir, her sayfa yüklenişinde görev listesini kontrol ederek çalışır, dolayısıyla düşük trafikli sitelerde yedekleme gibi zamanlanmış görevler saatlerce gecikebilir. İyi bir sağlayıcı WP-Cron'u devre dışı bırakıp gerçek sistem cron'u tanımlamanıza izin verir.

Ne Zaman Paylaşımlı Yeter, Ne Zaman VPS Gerekir?

Ziyaretçi sayısına dayalı kesin eşikler dolaşımda olsa da bunların otoriter bir kaynağı yok ve kaynaklar birbiriyle çelişiyor, dolayısıyla sayı vermek yanıltıcı olur. Karar için trafik yerine davranışa bakmak daha doğru. Paylaşımlı paket şu durumda yeterlidir: içeriğin büyük kısmı statik ve önbelleklenebilir, giriş yapan kullanıcı yok ya da çok az, trafik dalgalanması sert değil. VPS ya da yönetilen pakete geçiş şu sinyallerde gerekir: önbelleklenemeyen sayfa oranı yüksek (üyelik, sepet, kişiselleştirilmiş içerik), yoğun saatlerde site yavaşlıyor ya da 5xx hataları görülüyor, PHP worker limitine düzenli takılıyorsunuz, TTFB önbelleksiz ölçümde 800 milisaniyenin üzerinde kalıyor. Geçişi trafik hedefine göre değil, ölçtüğünüz soruna göre yapın. Erken geçiş gereksiz maliyet, geç geçiş ise kayıp müşteri anlamına gelir.

Tablodaki en pahalı satır bakım yüküdür, çünkü fiyat etiketi olmayan tek kalem odur. VPS'in aylık ücreti yönetilen paketten düşük çıkabilir, ama güncelleme, güvenlik ve yedek işini birinin yapması gerekir; o birinin saati de maliyettir. Sunucuyu kendiniz yönetmeye karar verdiyseniz sağlayıcı seçimini VPS sunucu firmaları karşılaştırmamızda ele aldık. Kararsız mısınız? Önce mevcut paketinizde önbelleği ve PHP sürümünü düzeltip bir ay ölçün; sorun çoğu zaman paketin sınıfı değil, yapılandırmasıdır.

WooCommerce Neden Ayrı Bir Problem?

E-ticaret, WordPress hosting denklemini kökten değiştirir çünkü mağazanın kritik sayfaları önbelleklenemez. Sepet, ödeme ve hesap sayfaları her ziyaretçi için farklıdır, dolayısıyla her istek PHP çalıştırır ve worker tüketir; blogda yüz ziyaretçi sunucuyu yormazken mağazada aynı sayı worker limitini doldurabilir. WooCommerce'in resmi sunucu gereksinimleri de daha yüksektir: PHP 8.3 ve üzeri (PHP 8.4'e kadar test edilmiş), WordPress 6.9 ve üzeri, MySQL 8.0 ya da MariaDB 10.6 ve üzeri, en az 256 MB WordPress bellek limiti ve HTTPS. Bellek satırı sessiz bir tuzak barındırıyor: WordPress'in resmi yapılandırma dokümantasyonuna göre WordPress varsayılan olarak PHP'ye 40 MB, çoklu site kurulumunda 64 MB ayırmayı dener. WooCommerce'in istediği 256 MB, tek site varsayılanının altı katından fazlası. Paylaşımlı paketlerde PHP bellek limiti çoğu zaman bunun altında kilitlidir ve panelden yükseltilemez; mağaza kurmadan önce sorulacak somut soru budur. Pratik sonuçlar şunlar: mağazada object cache neredeyse zorunludur, worker sayısı bloga göre daha yüksek olmalıdır ve yedek sıklığı sipariş kaybını önleyecek düzeyde olmalıdır. Platform seçimini henüz yapmadıysanız, WooCommerce ile barındırmalı alternatifler arasındaki farkı Shopify ve WooCommerce karşılaştırmamızda ele aldık.

Türkiye'de Barındırma: Konum, Gecikme ve Denge

Yerli mi yabancı mı sorusunun tek bir doğru cevabı yok, denge kurmak gerekiyor. Türkiye'ye fiziksel yakınlık ağ gecikmesini düşürür ve ziyaretçilerinizin tamamı Türkiye'deyse bu ölçülebilir bir kazançtır. Yerli sağlayıcıların ikinci avantajı Türkçe destek, TL ile faturalama ve yerel ödeme yöntemleridir. Karşı tarafta yurt dışı sağlayıcılar genellikle daha modern altyapı, daha şeffaf teknik dokümantasyon ve daha gelişmiş panel sunar. Sık rastlanan bir yanlışı düzeltelim: yurt dışı sağlayıcıların Türkiye'de veri merkezi olduğu iddiaları çoğu zaman doğru değildir, sağlayıcının resmi lokasyon listesini kendiniz kontrol edin. Coğrafi mesafenin etkisini bir CDN büyük ölçüde azaltabilir, dolayısıyla sunucu konumu tek başına belirleyici değildir. Kişisel veri işliyorsanız verilerin nerede tutulduğu ayrıca değerlendirilmesi gereken bir konudur ve teknik bir tercihten çok hukuki bir sorudur; kurumsal bir projede bunu hukuk danışmanınızla netleştirin.

Fiyat Tuzakları ve Satın Alma Öncesi Kontrol Listesi

Hosting fiyatlandırması bilinçli olarak karşılaştırmayı zorlaştıracak biçimde kurulur. En yaygın dört tuzak şunlar: tanıtım fiyatı ile yenileme fiyatı arasındaki büyük fark, çünkü ilan edilen düşük fiyat çoğu zaman uzun bir ilk dönem taahhüdüne bağlıdır ve yenilemede katlanır; sınırsız vaadi, çünkü hiçbir paket gerçekten sınırsız değildir ve sınır adil kullanım politikasında gizlidir; ücretli eklentiler, yani yedek, SSL ya da göç için ayrıca ücret alınması; ve iade koşullarındaki istisnalar. Satın almadan önce şu listeyi doğrudan sağlayıcıya sorun ve yanıtları yazılı alın.

• PHP sürümü: hangi alt sürümler sunuluyor, panelden değiştirebiliyor musunuz?
• PHP worker: kaç tane veriliyor, limit aşılınca istek kuyruğa mı giriyor yoksa hata mı dönüyor?
• Önbellek: sunucu tarafında sayfa önbelleği var mı, object cache için Redis ya da Memcached sunuluyor mu?
• Staging: panelde hazır mı, canlıya geri aktarım tek tıkla mı?
• Yedek: sıklık nedir, nerede saklanıyor, kaç gün geriye gidebiliyorsunuz, geri dönüş self servis mi?
• Ticari koşullar: göç ücretsiz mi, yenileme fiyatı ne kadar, trafik aşımında ne oluyor?

Sıralamayı da doğru kurun: önce resmi gereksinimleri karşılamayan paketleri eleyin, sonra worker ve önbellek yanıtlarına göre daraltın, fiyatı en sona bırakın. Fiyatla başlayan her karşılaştırma altı ay sonra taşınma faturası olarak geri döner. Kendi sitenizi yeni kuruyorsanız süreci baştan sona web sitesi kurma rehberimizde anlattık; toplam bütçeyi planlıyorsanız web sitesi fiyatları yazımız barındırma dışındaki kalemleri de gösteriyor. Elinizdeki paketten emin değil misiniz? Yukarıdaki altı soruyu bugün mevcut sağlayıcınıza gönderin; dönen yanıtlar kararınızı büyük ölçüde sizin yerinize verecektir.