WordPress Hosting

WordPress hosting ile sıradan hosting arasındaki fark nerede?

Şunu baştan söyleyelim. WordPress hosting çoğu zaman sıradan paylaşımlı hostingle aynı donanımda çalışır, fark yazılımdadır. Güncel PHP, açık OPcache, sunucu tarafında hazır bir sayfa önbelleği, WordPress'e göre yazılmış güvenlik kuralları ve birkaç yönetim aracı. WP hosting dediğimiz şey kabaca bunların toplamı. WordPress'in kendisi PHP ile MySQL ya da MariaDB çalıştıran her hostingde açılır ve paketler ancak trafik artıp önbelleğe giremeyen sayfalar çoğaldığında ayrışır.

Nedenini tek bir isteğin yolu gösterir. Sayfanın hazır HTML kopyası önbellekte duruyorsa web sunucusu onu olduğu gibi gönderir, PHP de veritabanı da devreye girmez. Kopya yoksa iş uzar. PHP, WordPress çekirdeğini, etkin eklentileri ve temayı yükler, veritabanına onlarca sorgu gönderir ve HTML'i sıfırdan kurar. WordPress için hosting ayarlamanın bütün mantığı, birinci yolu olabildiğince sık kullanıp ikincisini kısaltmaktır.

Bir de protokol tarafı var. HTTP/2, sayfanın CSS, JavaScript ve görsel dosyalarını tek bir TCP bağlantısı üzerinden paralel taşır. HTTP/3 ise UDP tabanlı QUIC protokolünü kullanır ve bağlantı kurulumunu TLS 1.3 el sıkışmasıyla birleştirir, paket kaybı yaşanan mobil ağlarda ilk bayt bu sayede daha erken gelir. Bunların ne kadar hazır geldiği Apache, nginx ve LiteSpeed arasında değişir.

Netx'te WordPress hosting paketleri cPanel sunucularında çalışıyor. Sayfadaki paket özelliklerinde de yazdığı gibi LiteSpeed web sunucusu ve LSCache önbelleği bütün paketlerde standart.

PHP-FPM, LSAPI ve sürüm seçimi

Pek kimsenin bakmadığı bir ayarla başlayalım. PHP işleyicisi, web sunucusunun PHP kodunu hangi modelle çalıştırdığını gösterir. Yaygın iki seçenek var. Biri PHP-FPM, yani nginx ve Apache ile kullanılan FastCGI süreç yöneticisi. Diğeri LSAPI, LiteSpeed'in PHP ile konuştuğu arayüz. Orada PHP işçilerini LiteSpeed yönetir. İkisi de her istekte yeni işlem açmak yerine bellekte bekleyen işçileri (worker) yeniden kullanır.

Peki bu neden umursanmalı? Çünkü işçi sayısı, aynı anda cevaplanabilecek önbelleksiz istek sayısının tavanıdır. Hepsi meşgulken gelen istek sıraya girer. Ziyaretçi bunu önce uzayan ilk bayt süresi (TTFB) olarak hisseder, yoğunluk sürerse 503 hatası, CloudLinux kullanan sunucularda ise 508 "Resource Limit Is Reached" sayfası görür. Paylaşımlı hostingte bu tavan hesap başına giriş süreci (EP) limitiyle uygulanır. Mantığını CloudLinux, CageFS ve LVE yazımızda anlattık.

Sürüm ise ertelendikçe büyüyen bir konu. Her PHP sürümü yaklaşık iki yıl aktif geliştirme, ardından iki yıl yalnız güvenlik yaması alır. Sonra bulunan açıklar kapanmaz. Yeni sürümler aynı kodu genellikle daha az CPU ile de çalıştırır, ama yükseltmeden önce staging kopyasında hata kaydını açıp kullanımdan kaldırılmış (deprecated) işlev uyarılarına bakmadan canlıya geçmeyin. Eski eklentiler tam burada kırılır.

cPanel'de sürümü MultiPHP Manager ekranından alan adı bazında seçersiniz. CloudLinux'lu sunucularda Select PHP Version ekranı aynı işi hesap bazında yapar. Paketinizde hangi sürümlerin açık olduğunu panelden ya da paket ayrıntısından kontrol edin.

Sürümün yanında üç değere de bakın. memory_limit, tek bir PHP isteğinin kullanabileceği en yüksek bellektir. WordPress ön yüz için WP_MEMORY_LIMIT değerini tek sitede 40 MB, multisite'ta 64 MB, yönetim paneli için WP_MAX_MEMORY_LIMIT değerini 256 MB varsayar ve PHP sınırı daha düşükse yükseltmeyi dener. max_execution_time bir betiğin en uzun çalışma süresidir. PHP varsayılanı 30 saniye, büyük içe aktarmalar ve eklenti tabanlı yedekler bu sürede kesilir. En çok kafa karıştıranı max_input_vars. Bir formla gönderilebilecek alan sayısını sınırlar, varsayılanı 1.000'dir. Büyük bir menüyü ya da çok varyasyonlu bir ürünü kaydederken son öğeler sessizce kayboluyorsa suçlu çoğu zaman budur.

Önbellek katmanları birbirinin yerini tutmaz

"Önbellek eklentisi kurdum, iş bitti" diye düşünmek kolay. Oysa WordPress'te birbirinin işini yapmayan dört katman var ve hızlı WordPress hosting büyük ölçüde bunlardan hangilerinin sunucu tarafında hazır geldiğiyle ölçülür.

En altta OPcache durur. PHP ile birlikte gelir ve derlenmiş bayt kodunu PHP işçilerinin paylaşılan belleğinde tutar, böylece önbelleksiz isteklerde dosyalar yeniden derlenmez. Tek tuzağı bellek. Ayrılan alan dolarsa derleme yeniden başlar ve kazanç erir.

Bir üst katman sayfa önbelleği. Üretilmiş HTML sayfanın tamamını web sunucusunda saklar. En büyük kazanç buradan gelir, ama yalnız herkese aynı görünen sayfalarda, yani oturum açmamış ziyaretçinin gördüklerinde. Giriş yapmış kullanıcının ekranı, sepet ve ödeme sayfası önbelleğin dışında kalmalı. LiteSpeed sunucularda bu katman LSCache'tir ve LiteSpeed Cache eklentisiyle yönetilir, yanına ikinci bir sayfa önbelleği eklentisi kurmak da en yaygın hatalardan biridir. Sonuç çift önbellek ve bir türlü güncellenmeyen sayfalar.

Nesne önbelleği başka bir derde çare. Sorgu sonuçlarını, seçenekleri ve transient verilerini tutar. WordPress'in kendi nesne önbelleği yalnız tek bir istek boyunca yaşar. wp-content klasörüne object-cache.php adlı drop-in dosyası eklendiğinde bu veriler Redis ya da Memcached gibi kalıcı bir bellek servisine yazılır ve sonraki istekler veritabanına uğramaz. Farkı en çok yönetim panelinde, WooCommerce'in sepet ve hesap sayfalarında, üyelik sitelerinde hissedersiniz. Şartı da sunucuda servisin çalışması. Eklenti tek başına kalıcı önbellek kuramaz. Redis'in paylaşımlı pakette olup olmadığını satın almadan önce sorun. Kurulum ve ölçüm adımları Redis nesne önbelleği rehberimizde.

En dışta tarayıcı ve CDN önbelleği var. Görselleri, CSS ve JavaScript dosyalarını, bazen de HTML'i tarayıcıda ya da kenar sunucularda saklar ve isteği sunucunuza hiç uğratmaz. Tekrar gelen ziyaretçide ve uzak lokasyonlarda işe yarar. Dosyayı değiştirdiğinizde sürüm parametresi eklemeyi ya da önbelleği temizlemeyi unutmayın.

Yavaşlık çoğu zaman veritabanında başlar

Sayfa önbelleğe girmiyorsa istek er geç veritabanına gider.

Yavaşlığın kaynağı da sanılanın aksine çoğu zaman işlemci değildir. Şişmiş tablolar ve dizinden yararlanamayan sorgular çok daha sık suçludur. Yükün büyük kısmını birkaç tablo taşır. İlk bakılacak yer wp_options. Burada otomatik yüklenen (autoload) seçenekler, hangi sayfa istenirse istensin her istekte belleğe alınır ve kaldırılan eklentilerden kalan kayıtlar da bu yükü büyütür. WordPress'in Site Sağlığı aracı, otomatik yüklenen verinin toplamı 800 KB'ı aştığında uyarı verir.

wp_postmeta başka türlü şişer. Özel alanlar, ürün özellikleri ve sayfa oluşturucuların verileri anahtar-değer biçiminde bu tabloda durur. Meta değerine göre süzen sorgular, mesela bir mağazadaki ürün filtreleri, tablo büyüdükçe yavaşlar. Revizyonlar da sessizce birikir. Her kaydetmede oluşan revizyon wp_posts tablosunu büyütür, süresi dolmuş transient kayıtları da cabası. wp-config.php'ye ekleyeceğiniz WP_POST_REVISIONS sabiti saklanacak revizyon sayısını sınırlar.

Eski kurulumlarda bir sürpriz daha çıkabilir. InnoDB satır düzeyinde kilitler ve bir çökmeden sonra kendini toparlar. O kurulumlardan kalan MyISAM tabloları ise tablonun tamamını kilitler ve yoğun yazma anında sorguları sıraya sokar, bu yüzden yedek aldıktan sonra onları InnoDB'ye çevirmek yaygın bir iyileştirmedir. Disk türünü de hesaba katın. Veritabanı çok sayıda küçük, rastgele okuma yapar ve SSD ile NVMe arasındaki fark en çok bu iş yükünde ortaya çıkar.

Site türüne göre WordPress hosting paketi seçmek

Paket seçerken ilk akla gelen soru "Ayda kaç ziyaretçi alıyorum?" olur ve tek başına yanıltıcıdır. Asıl soru, sitenin ne kadarının önbellekten sunulabildiği, çünkü oturum, sepet ya da üyelik içeren bir site aynı trafikte bir blogdan çok daha fazla RAM ve eş zamanlı PHP işçisi ister.

Netx'in WordPress hosting paketleri site sayısı, disk alanı, RAM ve CPU değerlerine göre kademelenir, güncel değerler bu sayfadaki paket tablosunda. Site sayısını hesaplarken staging kopyalarını unutmayın. Hazırlık kopyası genellikle bir alt alan adında açılır ve kotadan düşebilir. Disk alanını da WordPress'in her görsel için ürettiği küçük boyutları ve önbellek dosyalarını sayarak planlayın.

Multisite için bir parantez açalım. Tek kurulumdan birden çok site yönetmek hostingten fazlasını ister. Alt dizin yapısında (alanadi.com/site2) ek DNS ayarı gerekmez. Alt alan adı yapısında (site2.alanadi.com) wildcard DNS kaydı ve wildcard SSL sertifikası şarttır. Her yeni alt site veritabanına yaklaşık on tablo ekler. Daha can sıkıcı olanı, ağ genelinde etkin bir eklentideki açığın bütün siteleri birden etkilemesi. Bağımsız müşterilerin sitelerini bu yüzden ayrı kurulumlarda tutmak bizce daha güvenli. Ayrıntılar multisite için hosting yazısında.

WooCommerce hosting neden ayrı düşünülmeli?

Bir kampanya sabahı hayal edin. Ürün sayfaları hızla açılıyor, ama ödeme adımı takılıyor. WooCommerce'te bu şaşırtıcı değil, çünkü sepet, ödeme ve hesabım sayfaları her ziyaretçi için ayrı üretilir ve sayfa önbelleğine giremez. Üstelik sepete ürün ekleyen ziyaretçi bir oturum çerezi alır ve birçok önbellek yapılandırması bu kişinin sonraki isteklerini de önbellek dışında işler. WooCommerce hosting bu yüzden aynı trafikteki bir içerik sitesine göre daha fazla eş zamanlı PHP işçisi, RAM ve veritabanı kapasitesi ister.

Gözden kaçan yükler de var. Mini sepet kullanan temalarda sepet parçacıkları (cart fragments) betiği önbelleğe alınmayan ek bir AJAX isteği gönderir. Mini sepete ihtiyacınız yoksa betiği yalnız gerekli sayfalarda yükleyin. Sipariş sayısı büyüdükçe yüksek performanslı sipariş depolaması (HPOS) işe yarar, siparişleri wp_posts ve wp_postmeta yerine kendi tablolarında tutarak sorgu yükünü hafifletir. Açmadan önce eklentilerinizin uyumluluğuna bakın.

Arka planda dönen işler ayrı bir konu. Sipariş e-postaları, stok senkronizasyonu ve abonelik yenilemeleri wp-cron'a bağlı Action Scheduler kuyruğunda çalışır. Zamanlanmış eylemler listesinde bekleyen iş sayısı sürekli artıyorsa kuyruk yetişemiyor demektir. Süresi dolan müşteri oturumlarını silen iş de zamanlanmış bir iştir, yani wp-cron çalışmazsa wp_woocommerce_sessions tablosu büyür ve sepet işlemleri yavaşlar.

Ödeme dönüşleri en sinsi arıza noktası. 3D Secure dönüş adresleri ve ödeme kuruluşunun gönderdiği bildirim (webhook) istekleri bir güvenlik kuralına ya da önbelleğe takılırsa para tahsil edilir, ama sipariş "ödeme bekleniyor" durumunda kalır.

Kampanyadan önce yükü mutlaka deneyin. Katalog önbellekten sunulsa bile aynı dakikada ödeme yapan müşteri sayısı paketin işçi sınırına dayanır. Bir de hukuki taraf var. Müşteri adı, adresi ve sipariş geçmişi kişisel veridir, 6698 sayılı Kişisel Verilerin Korunması Kanunu kapsamındaki saklama ve aktarım yükümlülüklerini hukuk danışmanınızla değerlendirin. Mağazaya özgü kaynak ihtiyaçları WooCommerce hosting gereksinimleri yazısında, mağaza odaklı paketler e-ticaret hosting sayfasında.

Hızlı WordPress hosting nasıl ölçülür?

Hız konusunda herkesin bir hissi vardır, bize ise sayı lazım. Hızlı WordPress hosting, önbellekli sayfada düşük, önbelleksiz sayfada da kabul edilebilir bir TTFB üretir. TTFB (Time to First Byte), isteğin gönderildiği andan yanıtın ilk baytının geldiği ana kadar geçen süredir ve sunucunun sayfayı üretme süresini de içerir.

Core Web Vitals'ta hostinge en doğrudan bağlı metrik LCP'dir (Largest Contentful Paint). En büyük görselin ya da metin bloğunun görüntülenme süresini ölçer, 2,5 saniye ve altı iyi sayılır ve TTFB'deki her gecikme ona eklenir. INP (Interaction to Next Paint) etkileşime tepki süresidir. 200 milisaniye ve altı iyidir, çoğunlukla da JavaScript yüküne bağlıdır. CLS (Cumulative Layout Shift) öğelerin kaymasını ölçer, eşiği 0,1'dir ve hostingten çok temayla ilgilidir. Google bu eşikleri ziyaretlerin 75. yüzdelik dilimine göre değerlendirir. TTFB'nin kendisi Core Web Vitals'ın parçası değil, ama Google'ın yönergeleri 0,8 saniye ve altını iyi kabul ediyor.

Sunucunun nerede durduğu da bu süreye girer. Yeni bir HTTPS bağlantısında ilk bayttan önce üç gidiş-dönüş gerekir: TCP bağlantısı, TLS 1.3 el sıkışması ve isteğin kendisi. Sunucu uzaklaştıkça her biri uzar. HTTP/3 bu toplamdan bir gidiş-dönüşü düşürür.

Ölçerken sırayı karıştırmayın. Önce önbellekli bir sayfanın TTFB değerini birkaç kez ölçün, ilk ölçüm önbelleği doldurduğu için sonrakileri esas alın. Sonra önbelleğe girmeyen bir sayfaya, örneğin sepete, hesabım sayfasına ya da oturum açıkken herhangi bir sayfaya geçin, çünkü hostingin ham PHP ve veritabanı gücünü asıl bu sayı gösterir. Yüksek çıkarsa Query Monitor gibi bir eklentiyle yavaş sorguları ve en çok zaman harcayan eklentiyi bulun. PageSpeed Insights'ta laboratuvar puanına değil, gerçek kullanıcılardan toplanan saha verisine (CrUX) bakın. Search Console'daki Core Web Vitals raporu da bu veriye dayanır ve son 28 günü kapsar. Hostingin payını koddan ayırmanın yolu LCP ve INP'de hostingin payı yazısında.

Güvenlikte işin hangi kısmı sizde?

Ele geçirilen WordPress sitelerinde suçlu nadiren çekirdektir. Kapıyı genellikle güncellenmemiş bir eklenti, unutulmuş bir tema ya da zayıf bir yönetici şifresi açar. Hosting hesapları birbirinden yalıtır ve zararlı dosyaları tarar, uygulama katmanındaki disiplin ise site sahibinde kalır.

Sunucu tarafında, sayfada da belirtildiği gibi, Netx'in hosting sunucularında CageFS etkin. CloudLinux'un bu sanal dosya sistemi her hesaba yalnız kendi dosyalarını gösterir, aynı sunucudaki başka bir hesap sizin dosyalarınıza erişemez. Paketlerde antivirüs ve antispam koruması da var. Ama açık konuşalım, tarama zararlı dosyayı bulur, içeri girdiği açığı kapatmaz.

Gerisi sizde ve çoğu alışkanlık meselesi. WordPress çekirdeğinin küçük güvenlik sürümleri varsayılan olarak kendiliğinden kurulur. Eklenti ve temalar için haftada bir kontrol günü belirleyin, güvenlik yaması içeren güncellemeyi ise o günü beklemeden uygulayın. Kullanmadığınız eklentiyi devre dışı bırakmak yetmez, silin. Eklentinin dosyaları sunucuda durdukça açıklı bir dosya doğrudan adresiyle çağrılabilir. Lisanssız (nulled) tema ve eklentilere hiç bulaşmayın, bunlarda arka kapı yaygındır ve güncelleme gelmez.

Birkaç teknik ayar daha. xmlrpc.php çoğu sitede gereksiz yere açıktır. XML-RPC'nin system.multicall yöntemi tek istekte yüzlerce şifre denemesine izin verir, pingback özelliği de başka sitelere yönelik saldırılarda yansıtıcı olarak kullanılabilir. Mobil uygulama ya da XML-RPC kullanan bir eklentiniz yoksa erişimi engelleyin. Dosya izinlerinde klasörler 755, dosyalar 644, wp-config.php 440 veya 400 olmalı, 777 hiçbir dosyada kullanılmaz. wp-config.php'ye DISALLOW_FILE_EDIT sabitini eklerseniz panelden tema ve eklenti kodu düzenleme kapanır.

Giriş ekranı son halka. Yönetici hesaplarında iki adımlı doğrulamayı açın, "admin" gibi tahmin edilebilir kullanıcı adlarını kaldırın, başarısız giriş denemelerini sınırlayın ve her kullanıcıya yalnız ihtiyaç duyduğu rolü verin. Kontrollerin tam listesi WordPress güvenliği yazımızda.

Yedek, geri yüklenebildiği kadar yedektir

Hiç denenmemiş bir yedek, açıkçası bir umuttan ibarettir.

WordPress'te yedek, veritabanının, wp-content klasörünün (yüklemeler, temalar, eklentiler) ve wp-config.php dosyasının aynı ana ait kopyasıdır. Çekirdeği her zaman yeniden indirebilirsiniz, veritabanı ve yüklediğiniz dosyalar ise yalnız yedekten döner. Planı iki soruyla kurun. En fazla ne kadarlık veri kaybına katlanabilirsiniz? Buna RPO (Recovery Point Objective) denir ve günde bir yedek alınan bir mağazada son yedekten sonra gelen siparişler geri yüklemede kaybolur. Site en fazla ne kadar kapalı kalabilir? Bu da RTO (Recovery Time Objective). Geri yüklemeyi panelden kendiniz başlatabiliyorsanız kısa, destek talebi gerekiyorsa daha uzun olur.

Temel çerçeve 3-2-1 kuralı. Üç kopya, iki farklı ortam, biri bulunduğu sunucunun dışında. Hosting yedeği sunucu düzeyinde alınır ve PHP süre sınırına takılmaz. Eklenti yedeği ise PHP içinde çalışır, büyük sitelerde zaman aşımına uğrayabilir ve aynı hesapta saklanıyorsa hesapla birlikte kaybolur, o yüzden onu hosting dışındaki bir depolamaya gönderin. Geri yüklemeyi de en az üç ayda bir staging kopyasında deneyin.

Netx'te WordPress hosting hesapları haftalık olarak yedeklenir. Daha sık yedek gereken özel paket ve isteklerde günlük yedekleme hizmeti ayrıca satın alınabilir. Haftalık yedeğin anlamı şu: en kötü durumda bir haftalık veri kaybını kabul etmiş olursunuz. Sipariş alan bir mağaza için bu uzun bir süre. Mağaza veritabanı, içerik sitesininkinden daha sık yedeklenmeli. Günlük yedekleme hizmeti ya da hosting dışına düzenli aldığınız bir veritabanı yedeği bu süreyi kısaltır. Saklama süresini ve geri yüklemenin panelden yapılıp yapılamadığını paket ayrıntısında kontrol edin.

Bir hatırlatma daha. Hizmet sözleşmesine göre ödenmeyen hizmet vadeden 5 gün sonra durdurulur, sonraki 15 gün içinde de veriler silinebilir. Hosting dışında güncel bir kopya tutmanın nedenlerinden biri de bu. Yöntemlerin karşılaştırması WordPress yedekleme yazımızda.

Güncellemeyi canlı sitede denemeyin

Cuma akşamı canlı sitede toplu güncelleme düğmesine basmak, hafta sonunu riske atmanın en kısa yoludur.

Staging (hazırlık ortamı) tam da bu yüzden var. Canlı sitenin ayrı bir adreste çalışan kopyasıdır. Eklenti güncellemesi, tema değişikliği ya da PHP sürüm yükseltmesi önce burada denenir, sorun çıkmazsa canlıya aktarılır. cPanel ortamında kopyalama için ya bir klonlama eklentisi ya da WP Toolkit gibi, kurulumdan senkronizasyona, toplu güncellemeden güvenlik sıkılaştırmaya kadar pek çok işi tek ekranda toplayan bir yönetim aracı kullanılır. Ama hangi aracın kurulu olduğu sunucudan sunucuya değişir. Klonlama, senkronizasyon ya da güncellemeyi önce kopyada deneyen akıllı güncelleme gibi işlevler de lisans düzeyine bağlıdır. Paketinizde neyin açık olduğunu destek ekibine sorun. Akış ise hep aynıdır.

1. Canlı sitenin yedeğini alın.
2. Siteyi staging adresine klonlayın. Kopyada arama motoru görünürlüğünü kapatın, adresi de parolayla koruyun.
3. Kopyada giden e-postayı kapatın ve ödeme yöntemlerini test moduna alın. Bunu atlarsanız gerçek müşterilerinize bildirim gidebilir.
4. Güncellemeleri kopyada uygulayın, ardından iletişim formunu, girişi, sepeti ve ödemeyi tek tek deneyin.
5. Canlıya aktarmadan önce yalnız dosyaları mı, veritabanını da mı taşıyacağınıza karar verin.
6. Aktarımdan sonra önbelleği temizleyin ve hata kaydını 24 saat izleyin.

Beşinci adımı hafife almayın. Veritabanını senkronize ederseniz, kopyayı aldığınız andan sonra canlıda oluşan siparişlerin, yorumların ve form kayıtlarının üzerine yazılır. Tema ve eklenti değişikliklerinde yalnız dosyaları aktarmak bu yüzden daha güvenlidir. Kurulum ve ilk ayarlar için cPanel'de WordPress kurulumu rehberine bakabilirsiniz.

WordPress sitesini taşırken DNS'e en son dokunun

Taşımada en sık görülen hata, DNS'i erkenden değiştirmektir. Kesintisiz bir geçişin tek şartı var. Site, alan adı yeni sunucuyu göstermeden önce orada eksiksiz test edilmiş olmalı. Gerisi dosya, veritabanı ve wp-config.php aktarımı, en sonda da DNS kaydının yeni IP adresine çevrilmesi.

1. Geçişten 24–48 saat önce A kaydının TTL değerini 300 saniyeye düşürün.
2. Eski hostingte dosyaların ve veritabanı dökümünün tam yedeğini alın. Mağazanız varsa sipariş kaybetmemek için kısa bir bakım penceresi planlayın.
3. Yeni hostingte alan adını, boş bir veritabanını ve veritabanı kullanıcısını oluşturun. PHP sürümünü eski ortamla uyumlu seçin.
4. Dosyaları yükleyin, veritabanını içe aktarın ve wp-config.php içindeki DB_NAME, DB_USER, DB_PASSWORD ve DB_HOST değerlerini güncelleyin.
5. Alan adı ya da protokol değişiyorsa adresleri serileştirilmiş veriyi koruyan bir araçla değiştirin. WordPress'in resmi komut satırı aracı WP-CLI, güncelleme ve kullanıcı işlemlerinin yanında bu işi de search-replace komutuyla yapar. Düz SQL ile yapılan değiştirme serileştirilmiş dizelerin uzunluk bilgisini bozar ve widget ile tema ayarlarını kaybettirir.
6. Bilgisayarınızın hosts dosyasına yeni IP adresini yazın ve siteyi DNS'e dokunmadan açın. Girişi, formları, görselleri, kalıcı bağlantıları ve sepet akışını kontrol edin.
7. DNS kaydını değiştirin. Alan adı doğrulamalı ücretsiz SSL sertifikası çoğu zaman ancak alan adı yeni sunucuyu gösterdikten sonra alınabilir, o yüzden sertifikayı bu adımın hemen ardından kurun.
8. E-postayı taşımıyorsanız MX kayıtlarına dokunmayın. Taşıyorsanız posta kutularını ayrıca planlayın.
9. Eski hostingi, yeni sunucuda birkaç gün hatasız çalıştığını görmeden kapatmayın.

Kaynak sunucu da cPanel ise iş kolaylaşır, çünkü tam hesap yedeği dosyaları, veritabanlarını ve e-posta kutularını tek arşivde taşır. Farklı bir panelden geliyorsanız yönetim araçlarının ya da taşıma eklentilerinin içe aktarma işlevi iş görür. Taşıma desteğinin neleri kapsadığını (e-posta kutuları, birden çok site, veritabanı boyutu) satın almadan önce satış ekibine sorun. Üç taşıma yöntemini WordPress taşıma rehberinde karşılaştırdık.

wp-cron ve e-posta: sessizce bozulan iki şey

İkisi de gürültü yapmadan bozulur ve fark ettiğinizde genellikle bir şey çoktan kaçmıştır.

wp-cron'un adı yanıltabilir. Gerçek bir sistem zamanlayıcısı değildir, zamanlanmış işleri ziyaretçi isteğiyle tetikleyen bir mekanizmadır. Her sayfa yüklemesinde zamanı gelmiş bir iş var mı diye bakılır. Az ziyaret alan sitede işler gecikir ve zamanladığınız yazı vaktinde yayımlanmaz. Çok ziyaret alan sitede ise aynı kontrol boşuna yük üretir.

Kalıcı çözüm basit. wp-config.php'ye DISABLE_WP_CRON sabitini true değeriyle ekleyin, sonra cPanel'deki Cron Jobs (Zamanlanmış Görevler) ekranında wp-cron.php adresini 5 ya da 15 dakikada bir çağıran bir görev tanımlayın. WP-CLI kullanılabiliyorsa görev wp cron event run --due-now komutu da olabilir. WooCommerce'in Action Scheduler kuyruğu, yedek eklentileri ve bülten gönderimleri bu düzene bağlıdır. Ayrıntılar wp-cron'un çalışma mantığını anlattığımız yazıda.

E-postada durum daha da sinsi. WordPress iletileri wp_mail() işleviyle gönderir ve bu işlev varsayılan olarak PHP'nin mail() işlevini kullanır, gönderen adresi de wordpress@alanadiniz biçiminde olur ve ileti kimlik doğrulaması olmadan çıkar. SPF, DKIM ve DMARC denetiminden geçemeyen iletiler büyük posta sağlayıcılarında spam klasörüne düşer ya da doğrudan reddedilir. Kaybolan sipariş onaylarının ve gelmeyen şifre sıfırlama e-postalarının en yaygın nedeni budur.

Düzeltmesi birkaç adım. Formlar ve WooCommerce bildirimleri için alan adınıza ait bir posta kutusu açın ve bir SMTP eklentisiyle kimlik doğrulamalı gönderime geçin. 587 numaralı port STARTTLS, 465 numaralı port doğrudan TLS kullanır. DNS bölgesine gönderen sunucuyu kapsayan SPF kaydını ve DKIM anahtarını ekleyin. DMARC politikasını p=none ile başlatıp raporlar temizlendikçe quarantine ve reject düzeyine yükseltin. Deneme iletisinin başlıklarında spf=pass, dkim=pass ve dmarc=pass sonuçlarını görün. Toplu bülteni de işlem e-postalarından ayırın, paylaşımlı hostingin gönderim sınırları toplu e-postaya uygun değildir. Kayıtların yazımı örnekleriyle SPF, DKIM ve DMARC yazımızda.

500 hatası ve beyaz ekranda ilk bakılacak yer

Ekranda yalnız "500 Internal Server Error" yazıyorsa tahmin yürütmek kolay. Yapmayın. Bu hatanın ve beyaz ekranın en sık nedeni bir eklentinin, temanın ya da PHP sürüm değişikliğinin ürettiği ölümcül PHP hatasıdır ve teşhis hata kaydıyla başlar.

WordPress ölümcül bir hata yakaladığında ziyaretçiye "Bu web sitesinde kritik bir hata oluştu" mesajını gösterir ve yönetici e-postasına, hatalı eklentiyi duraklatıp panele girmenizi sağlayan bir kurtarma modu bağlantısı yollar. E-posta gönderimi bozuksa bu bağlantı da gelmez.

Hata kaydı için wp-config.php'de WP_DEBUG ve WP_DEBUG_LOG sabitlerini true, WP_DEBUG_DISPLAY sabitini false yapın, böylece hatalar ziyaretçiye gösterilmeden wp-content/debug.log dosyasına yazılır. cPanel'deki Errors (Hatalar) ekranı da web sunucusunun son hata kayıtlarını gösterir. Teşhis bitince kaydı kapatıp dosyayı silin, açık kalan bir debug.log dışarıdan okunabilir.

Bellek sınırını yükselttiniz ve hata bu kez daha yüksek bir değerde mi tekrar etti? O zaman sorun sınırda değil. Bir eklenti belleği sızdırıyordur, çözüm de o eklentidedir. Sıralı teşhis WordPress 500 hatası ve beyaz ekran yazısında.

Paylaşımlı hosting ne zaman dar gelir?

Önce tatsız gerçek. Yavaş bir sorgu daha büyük bir sunucuda da yavaştır, yalnız daha pahalıya çalışır. Taşınmadan önce yavaşlığın bir eklentiden gelmediğinden emin olun. Paylaşımlı WordPress hosting, darboğaz sitenin kodu değil hesap sınırları olduğunda yetmez. Önbellek ve sorgu iyileştirmelerine rağmen normal trafikte CPU, RAM ya da eş zamanlı işlem sınırına düzenli dayanıyorsanız sıradaki adım VPS ya da VDS'tir.

Sinyaller genelde birlikte gelir. Kaynak kullanım grafiğinde, ortada ne saldırı ne kampanya varken, işlem ya da CPU sınırına her gün ulaşılır ve ödeme, hesabım, yönetim paneli gibi önbellek dışı sayfalarda TTFB yoğun saatlerde belirgin biçimde yükselir. Action Scheduler kuyruğunda bekleyen işler gün içinde erimez. Bazen de ihtiyaç teknik bir bileşendir. Size ayrılmış bir Redis, ürün araması için Elasticsearch ya da OpenSearch, özel PHP uzantıları veya sunucu düzeyinde özel yönlendirme kuralları paylaşımlı ortamda sunulmaz. Root erişimi, sürüm kontrolünden otomatik dağıtım ya da siteye özel IP adresi isteyen entegrasyonlar da sizi aynı kapıya getirir.

VPS, fiziksel bir sunucunun sanallaştırılarak bölünmüş bir parçasıdır ve kaynaklar diğer sanal sunucularla paylaşılabilir, VDS'te ise işlemci ve bellek size ayrılır. Netx'in VDS paketlerinde diskler NVMe Enterprise SSD. Hazır yapılandırmalar VDS sanal sunucu sayfasında. vCore, RAM ve NVMe disk miktarını tek tek seçmek isterseniz VDS Sihirbazı size özel bir yapılandırma çıkarır. Sanal sunucuda işletim sistemi güncellemesi, güvenlik duvarı, PHP ayarları ve yedekleme artık sizin işinizdir. Bunları devretmek isterseniz sunucu yönetimi hizmetimiz var. Trafiğe ve WooCommerce yüküne göre karar tablosu WordPress için VPS mi hosting mi yazısında.

Satın almadan önce sorulacak sorular

Paket tablosu disk, RAM ve site sayısını gösterir. Günlük işletimi asıl etkileyen ayarların çoğu ise orada yazmaz. Hangi sağlayıcıyla konuşursanız konuşun, şu soruların cevabını yazılı olarak alın.

• Hazırlık kopyası için hangi araç sunuluyor ve kopya site kotasına sayılıyor mu?
• Hangi PHP sürümleri açık, memory_limit ve max_input_vars değerlerini değiştirebiliyor musunuz, SSH ve WP-CLI erişimi var mı?
• Eş zamanlı işlem ve CPU sınırı ne? Sınır aşıldığında site yavaşlıyor mu, yoksa doğrudan 508 hatası mı veriyor?
• Sunucu düzeyinde sayfa önbelleği var mı, paylaşımlı pakette Redis ya da Memcached bulunuyor mu? Netx paketlerinde LiteSpeed ve LSCache standart.
• Yedek ne sıklıkla alınıyor, ne kadar saklanıyor, hosting dışında kopyası var mı ve geri yüklemeyi panelden kendiniz yapabiliyor musunuz?
• Ücretsiz SSL sertifikası otomatik yenileniyor mu, multisite alt alan adı yapısı için wildcard sertifika seçeneği var mı?
• SMTP kimlik doğrulaması, gönderim sınırı ve SPF ile DKIM kayıtlarının yönetimi nasıl işliyor?
• Yazılı bir uptime taahhüdü var mı? Netx bütün ürünlerinde %99,9 taahhüt eder, bu da 30 günlük bir ayda yaklaşık 43 dakikalık kesinti payı demektir.
• Taşıma desteği neyi kapsıyor ve siteyi DNS değişmeden önce yeni sunucuda test edebiliyor musunuz?
• Yenilemede hangi fiyat uygulanıyor, ödeme gecikirse hizmet hangi koşulla durduruluyor? Netx'te yenilemede güncel fiyatlandırma geçerlidir, hosting ürünlerinde 14 gün iptal hakkı vardır, faturalar TL kesilir ve ödeme kredi kartı ya da havale/EFT ile yapılır.
• Sağlayıcının yasal durumu ne? Netx Bilişim A.Ş. İstanbul Ataşehir merkezlidir, 5651 sayılı Kanun kapsamında BTK belgeli yer sağlayıcıdır ve ISO/IEC 27001 ile ISO 9001 belgelerine sahiptir.
• Türkçe teknik destek hangi kanallardan veriliyor ve WordPress eklenti ya da tema sorunları destek kapsamına giriyor mu?