Site haritası, arama motorlarına sitenizdeki önemli sayfaların listesini sunan teknik bir dosyadır. Google bu dosyayı tarayarak URL’leri daha verimli keşfetmeye çalışır. Yeni bir WordPress sitesi kurduysanız veya içeriklerinizin dizine girmesini hızlandırmak istiyorsanız doğru yerdesiniz.

WordPress XML Site Haritası Nedir ve Ne İşe Yarar?

XML site haritası, sitenizdeki önemli URL’lerin yapılandırılmış bir listesini arama motorlarına sunan dosyadır. WordPress’te bu dosyaya genellikle `/sitemap.xml`, `/sitemap_index.xml` veya `/wp-sitemap.xml` adreslerinden ulaşılır. Google bu listeyi okuyarak hangi sayfaların taranması gerektiğine dair ipucu alır.

Site haritası bir sıralama faktörü değildir. Ancak Google’ın sayfaları keşfetmesine yardım ederek tarama bütçesini daha verimli kullanmasını sağlar. Bu fayda özellikle az dış bağlantıya sahip yeni sitelerde, çok sayfalı haber portallarında ve derin URL yapılarına sahip e-ticaret kurulumlarında belirginleşir.

Yeni yayınladığınız bir blog yazısı sosyal medyada henüz paylaşılmadıysa Google onu harici bir bağlantıdan keşfedemez. Güncel site haritasında bu URL zaten yer alıyorsa Googlebot içeriğe daha kısa sürede ulaşabilir. Yine de keşfedilmenin sıralamayı veya kalite değerlendirmesini doğrudan artırmadığını bilmelisiniz.

Yöntem 1: SEO Eklentisiyle XML Site Haritası Oluşturma

WordPress XML site haritası denildiğinde akla ilk gelen çözüm, popüler bir SEO eklentisiyle otomatik harita üretmektir. Yoast SEO ve Rank Math bu konuda en yaygın tercihler arasındadır. İkisi de site haritası oluşturma sürecini neredeyse hiç elle müdahale gerektirmeden yönetir.

Bu yönteme başlamadan önce yönetici hesabıyla WordPress paneline erişebildiğinizden ve eklenti kurma yetkinizin olduğundan emin olun. Ayrıca sitenin güncel bir yedeğini almak da sağlıklı olur. Eklenti kurulumu genellikle sorunsuzdur ancak özellikle düşük kaliteli barındırmalarda performans etkisi fark edilebilir. Site hızını etkileyen eklentileri anlatan WordPress Yavaş Eklentiler rehberi karar vermenize yardımcı olabilir.

1. WordPress yönetici panelinde Eklentiler > Yeni Ekle yolunu izleyin.
2. Arama kutusuna “Yoast SEO” veya “Rank Math” yazın.
3. İlgili eklentinin yanındaki Kur düğmesine, ardından Etkinleştir düğmesine tıklayın.
4. Yoast SEO kullanıyorsanız SEO > Ayarlar menüsüne girin.
5. Açılan ekranda Site Haritaları sekmesini bulun ve özelliğin açık olduğunu doğrulayın.
6. Rank Math kullanıyorsanız Rank Math > Sitemap Settings yolunu izleyin.
7. Tarayıcınızda Yoast için `/sitemap_index.xml`, Rank Math için `/sitemap.xml` adresini açın.
8. Ekranda URL listesinin yapılandırılmış biçimde göründüğünü kontrol edin.

Bu adımlar tamamlandığında eklenti; yazılar, sayfalar, kategori ve etiket arşivleri için otomatik olarak güncellenen haritalar üretir. Eklentinin en büyük avantajı, noindex eklediğiniz içerikleri ve gereksiz arşivleri haritadan çıkarabilmesidir. Bu ayarları da SEO menüsünden kontrol etmeniz gerekir.

Bazı site sahipleri birden fazla SEO eklentisini aynı anda kurar. Bu durum çakışan site haritası dosyalarına yol açabilir. Yoast ve Rank Math gibi eklentilerden yalnızca birini aktif tutmanız, hatalı URL listelerinin önüne geçer. Ayrıca eklentinin ürettiği harita adresinin arama motorlarına tanıtılması gerektiğini unutmayın.

Yöntem 2: WordPress’in Yerleşik Site Haritasını Kullanma

WordPress 5.5 sürümünden itibaren çekirdek yazılım, ek bir eklentiye gerek kalmadan `/wp-sitemap.xml` adresinde site haritası sunar. Bu yerleşik özellik; yazılar, sayfalar, kategoriler ve etiketler için temel bir index dosyası oluşturur. Kurulum sonrası el değmeden çalışır.

Yerleşik site haritasını etkinleştirmek için ayrı bir ayar yapmanız gerekmez. WordPress güncelse dosya otomatik olarak yayındadır. Yine de bazı durumlarda permalink yapısı bozulursa veya aynı adrese müdahale eden eski bir eklenti kalırsa dosya beklenen içeriği göstermeyebilir.

1. WordPress sürümünüzün 5.5 veya daha yeni olduğundan emin olun.
2. Tarayıcınızın adres çubuğuna `https://siteniz.com/wp-sitemap.xml` yazın.
3. Dosyanın XML formatında ve HTTP 200 durum koduyla açıldığını doğrulayın.
4. Gerekirse sitenizin robots.txt dosyasına `Sitemap: https://siteniz.com/wp-sitemap.xml` satırını ekleyin.
5. Aynı sitede eklenti tabanlı başka bir harita aktifse yalnızca birinin kullanıldığından emin olun.

Buradaki en kritik adım, robots.txt dosyasına doğru adresin yazılmasıdır. Yanlış protokol veya yanlış alan adı, Google’ın haritayı tamamen görmezden gelmesine neden olabilir. Yerleşik harita hakkında en güncel bilgi için resmi WordPress kaynağını WordPress.org adresinden takip edebilirsiniz.

Yerleşik harita çoğu küçük işletme ve kişisel blog için yeterlidir. Ancak özel gönderi türleri, medya dosyaları veya belirli taxonomiler için ayrıntılı kontrol sunmaz. Bu ihtiyaç ileride doğarsa eklenti tabanlı çözüme geçmeniz yerinde olur.

Yöntem 3: Manuel Özelleştirme Ne Zaman Gerekir?

Çok dilli siteler, özel gönderi türleri veya karmaşık filtreleme kuralları söz konusu olduğunda standart haritalar yetersiz kalabilir. Bu gibi durumlarda geliştiriciler WordPress hook’ları aracılığıyla haritaya URL ekleyip çıkarabilir. Manuel kod müdahalesi esneklik sağlar fakat ciddi hata riski taşır.

Hatalı yazılan bir PHP kodu, haritanızın boş görünmesine veya yanlış URL’ler listelenmesine neden olabilir. Bu yüzden yalnızca gerçekten ihtiyaç varsa manuel özelleştirmeye gidilmelidir. Çoğu site için eklentili veya yerleşik yöntem yeterli güvenlik ve güncellik sağlar.

Manuel müdahaleye karar verirseniz öncelikle sitenin tam yedeğini alın ve değişiklikleri test ortamında deneyin. `functions.php` dosyası üzerinde yapılan küçük bir hata, sitenin tamamını erişilemez hale getirebilir. Resmi WordPress geliştirici belgelerini WordPress Developer Resources üzerinden incelemeniz en doğrusu olacaktır.

Küçük bir blog için özel kod yazmak genellikle gereksiz iş yüküdür. Öncelikle işletmeye gerçek fayda sağlayacak iyileştirmelere odaklanın. Site haritanızın hızlı ve kesintisiz yanıt vermesi için güvenilir bir WordPress Hosting altyapısı da önemli bir temel oluşturur.

Site Haritasını Google’a Gönderme ve Doğrulama

WordPress tarafında harita hazır olduğunda sıra bu adresi Google’a tanıtmaktır. Google Search Console, site haritası gönderme ve izleme işini tek panelden yönetmenizi sağlar. Site henüz Search Console’a eklenmediyse önce mülk doğrulaması yapmanız gerekir.

1. Google Search Console hesabınıza giriş yapın.
2. Doğrulanmış sitenizi listeden seçin.
3. Sol menüden Dizin > Site Haritaları bölümüne gidin.
4. Kutuya haritanızın tam adresini yazın. Örneğin: `sitemap_index.xml` veya `wp-sitemap.xml`.
5. Gönder düğmesine tıklayın.
6. Birkaç dakika sonra sayfayı yenileyin ve durumun Başarılı olduğunu görün.
7. Varsa uyarı veya hata satırlarını inceleyerek ilgili URL’leri düzeltin.

Beklenen sonuç, Google’ın haritayı işleme koyması ve tarama kuyruğunu oluşturmasıdır. Bu işlem bazen dakikalar içinde tamamlanır, bazen yoğunluk nedeniyle daha uzun sürebilir. Search Console raporu üzerinden taranan URL ve dizine eklenen sayfa sayısını izleyebilirsiniz.

Site haritasını Bing’e de göndermek isterseniz Bing Webmaster Tools benzer bir süreç sunar. Süreç Google ile büyük ölçüde aynıdır ve ek bir teknik ayar gerektirmez. Ancak öncelikli hedef kitlenizin kullandığı arama motoruna odaklanmak yeterlidir.

Sık Karşılaşılan XML Site Haritası Hataları ve Çözümleri

WordPress XML site haritası süreçlerinde en sık karşılaşılan sorunlar genellikle birkaç tekrarlayan nedene dayanır. 404 ve 500 hataları bunların başında gelir. Bu sorunları tanımak, panikle yanlış müdahale yapmanızın önüne geçer.

404 Hata: Harita Bulunamadı

Bağlantı ayarınız bozulduğunda veya eklenti site haritasını yeniden üretemediğinde 404 hatası görürsünüz. Çözüm için WordPress yönetici panelinde Ayarlar > Kalıcı Bağlantılar ekranına gidip hiçbir değişiklik yapmadan Kaydet düğmesine basın. Bu işlem yeniden yazma kurallarını tazeleyerek çoğu 404 sorununu giderir.

Boş Site Haritası

Harita yüklenir ancak içinde hiç URL yoksa genellikle cache eklentisi veya noindex kuralı sorumludur. Cache eklentinizi geçici olarak devre dışı bırakın ve site haritası adresini yeniden kontrol edin. Ayrıca robotların içeriği engellemediğinden emin olmak için robots.txt dosyanızı gözden geçirin.

500 Internal Server Error

Sunucu tarafı kaynaklı bu hata çoğu zaman eklenti çakışmasından veya bozuk .htaccess dosyasından kaynaklanır. Site haritasına özel 500 hataları için daha kapsamlı çözüm adımlarına ihtiyacınız varsa WordPress 500 hatası çözümü rehberine bakabilirsiniz. Sunucu hata loglarını kontrol etmek de doğru teşhis için kritiktir.

Çok Fazla URL Uyarısı

Google tek bir site haritası dosyasında 50.000 URL veya 50 MB üst sınırını önerir. Büyük kataloglar bu sınırı aşarsa haritayı parçalara bölmek gerekir. SEO eklentileri bu bölme işini çoğu zaman otomatik yönetir. Yerleşik WordPress haritası da index biçimi sayesinde bu sorunu büyük ölçüde çözmüştür.

HTTP ve HTTPS Karışıklığı

Site haritası URL’leriniz farklı bir protokol içeriyorsa Google karışık sinyal alır. WordPress genel ayarlarındaki Site Adresi alanının geçerli SSL protokolünü kullandığından emin olun. Haritada listelenen adreslerin de tamamı bu protokole uygun olmalıdır.
Bu hataların çoğu, site haritası adresine elle yazılan yanlış bir karakterden bile kaynaklanabilir. Önce adres çubuğundaki URL’yi sadeleştirip test etmek faydalıdır. Sorun tekrarlıyorsa barındırma sağlayıcınızın destek ekibiyle hata loglarını paylaşmanız çözümü hızlandırır.

Hangi Yöntem Size Uygun?

Küçük kişisel bloglar, basit kurumsal tanıtım siteleri ve yeni başlayan kullanıcılar için WordPress’in yerleşik site haritası yeterlidir. Ek kurulum yapmadan çalışır ve temel URL listesi ihtiyacını karşılar. Gereksiz eklenti yükünden de kaçınmanızı sağlar.

Düzenli içerik üreten, e-ticaret ürünlerini yöneten veya SEO çalışmalarında sayfa bazlı ince ayarlara ihtiyaç duyan siteler için Yoast SEO veya Rank Math daha uygun olur. Eklentiler yalnızca harita üretmez; noindex kuralları, başlık önerileri ve yapılandırılmış veri gibi ek SEO kontrollerini de devreye alır.

Manuel özelleştirme ise kurumsal mimarisi farklı, çok dilli veya çok bölgeli yayın yapan sitelere hitap eder. Böyle bir ihtiyaç doğduğunda geliştirici desteği almak en sağlıklı yaklaşımdır. Genel site haritası stratejinizi daha geniş bir çerçevede planlamak isterseniz XML site haritası oluşturma rehberi size farklı platformları da kapsayan genel bir bakış sunar.

Hangi yöntemi seçerseniz seçin, haritayı Google Search Console’dan izlemeyi alışkanlık haline getirin. Düzenli kontrol, bir sorunu arama trafiğinizi etkilemeden yakalamanızı sağlar. Site haritası yalnızca bir başlangıçtır; asıl hedef daima kaliteli, erişilebilir ve hızlı içerik olmalıdır.

Sıkça Sorulan Sorular

WordPress XML site haritası adresini nasıl bulurum?

SEO eklentisi kullanıyorsanız eklentinin site haritası ayarlarında yazan adresi kullanın. Eklenti yoksa ve WordPress sürümünüz 5.5 veya daha yeniyse `https://siteniz.com/wp-sitemap.xml` adresini tarayıcınızda açın.

Site haritası olmadan Google sayfalarımı dizine alır mı?

Evet, Google sayfaları harici bağlantılar ve iç linkler aracılığıyla da keşfedebilir. Ancak site haritası, yeni ve az bağlantılı sayfaların Googlebot tarafından daha hızlı fark edilmesine yardımcı olur.

WordPress’te birden fazla site haritası olması sorun mudur?

Bir sitede birden fazla site haritası bulunması teknik olarak mümkündür. Ancak aynı URL’leri farklı biçimlerde listeleyen iki harita Google’ın kafasını karıştırabilir. Mümkünse yalnızca bir ana harita veya bir index dosyası kullanın.

Site haritasını ne sıklıkla güncellemeliyim?

WordPress yerleşik haritası ve SEO eklentileri, yeni içerik yayınladığınızda haritayı otomatik günceller. Manuel kod kullanıyorsanız her yeni yayından sonra harita yeniden üretilmelidir.

Aşağıdaki 15 adım, taşıma öncesi hazırlıktan yayın sonrası kontrollere kadar tüm süreci kapsar. Adımları atlamadan uygularsanız sitenizin kesintisiz geçiş yapma olasılığı belirgin şekilde artar. Önce yedek almayı, sonra taşıma işlemini, en son da doğrulama testlerini ele alacağız.

Taşıma Öncesi Hazırlık Adımları

Taşıma başlamadan önce yapacağınız hazırlık, sürecin geri kalanını doğrudan etkiler. Bu aşamada amacınız mevcut verileri güvence altına almak ve yeni ortamı tanımaktır.

Adım 1: Tam Yedek Alın

Taşımanın ilk kuralı, her şeyin bir kopyasını almaktır. Web sitenizin iki temel bileşeni vardır: dosyalar ve veritabanı. Dosyalar genellikle FTP veya dosya yöneticisi ile indirilir; veritabanı ise phpMyAdmin veya benzeri bir araçla dışa aktarılır.

WordPress kullanıyorsanız bir yedekleme eklentisi ile hem dosyaları hem veritabanını tek pakette alabilirsiniz. Yedeği aldıktan sonra dosya boyutunu ve içeriğini kontrol edin. Boş veya eksik yedek, taşımanın ilerleyen adımlarında geri dönüşü olmayan sorunlara yol açar. Farklı firmadan hosting taşıma rehberi bu konuda daha geniş bir çerçeve sunar.

Adım 2: Yeni Hosting Hesabını Hazırlayın

Yeni hosting paketinizi oluşturduktan sonra kontrol paneline erişimi test edin. Geçici URL veya ön izleme adresi genellikle hosting panelinden verilir. Bu adres, DNS değişikliği yapmadan önce siteyi test etmenizi sağlar.

Yeni sunucunun disk alanı, PHP sürümü ve veritabanı limiti gibi özelliklerini not edin. Özellikle e-ticaret sitelerinde yüksek trafik ve çok sayıda ürün görseli için NVMe SSD depolama ve yeterli RAM önem kazanır.

Adım 3: PHP Sürümü ve Yazılım Uyumluluğunu Kontrol Edin

Mevcut sitenizin hangi PHP sürümünde çalıştığını öğrenin. Yeni sunucudaki PHP sürümü farklıysa bazı eklentiler veya temalar uyumsuzluk yaşayabilir. Özellikle eski yazılım kullanan sitelerde bu durum sık görülür.

PHP sürümünü değiştirmeniz gerekiyorsa önce sitenizin tüm bileşenlerinin desteklediğinden emin olun. PHP sürümü değiştirme uyumluluk kontrol listesi bu konuda ayrıntılı bir yol haritası sunar. Uyumsuz bir eklenti, sitenin beyaz ekran vermesine neden olabilir.

Adım 4: DNS ve Alan Adı Erişim Bilgilerini Hazırlayın

Alan adınızın yönetim paneline giriş yapabildiğinizi doğrulayın. DNS kayıtlarını değiştirmek için genellikle alan adı kayıt firmasının paneli kullanılır. Bu bilgilere erişiminiz yoksa taşıma işlemi gecikir.

Ayrıca mevcut DNS kayıtlarının bir dökümünü alın. A, AAAA, MX, TXT ve CNAME kayıtlarını not edin. Bu kayıtları yeni sunucuya aktarırken eksiksiz olması, e-posta ve alt alan adlarının sorunsuz çalışmasını sağlar.

Adım 5: E-posta Hesaplarını ve Yönlendirmeleri Listeleyin

Web sitesi taşınırken e-posta hesapları genellikle gözden kaçar. Ancak işletmeler için e-posta kesintisi, site kesintisinden daha kritik olabilir. Tüm e-posta adreslerini, takma adları ve yönlendirmeleri listeleyin.

E-postaları yeni sunucuya taşımak için IMAP senkronizasyonu veya posta kutusu yedekleme araçları kullanabilirsiniz. Bu listeyi Adım 9’da e-postaları aktarırken kullanacaksınız.

Taşıma İşlemi Adımları

Hazırlık tamamlandığında asıl taşıma başlar. Bu aşamada dosyaları ve veritabanını yeni sunucuya aktarır, ardından siteyi geçici adreste test edersiniz. DNS değişikliği en sona bırakılır.

Adım 6: Dosyaları Yeni Sunucuya Aktarın

FTP veya SFTP kullanarak yedeklediğiniz dosyaları yeni sunucudaki ilgili dizine yükleyin. Kök dizin genellikle public_html veya httpdocs adını taşır. Aktarım sırasında bağlantının kopmaması için kararlı bir internet bağlantısı kullanın.

Büyük sitelerde dosya sayısı fazla olduğundan aktarım uzun sürebilir. Bu durumda dosyaları sıkıştırıp tek bir arşiv olarak yüklemek daha hızlı ve güvenilirdir. Arşivi sunucuda açarak dizin yapısını koruyabilirsiniz.

Adım 7: Veritabanını İçe Aktarın ve Bağlantı Ayarlarını Güncelleyin

Yedeklediğiniz veritabanını yeni sunucudaki veritabanı yönetim aracına içe aktarın. Ardından sitenizin yapılandırma dosyasındaki veritabanı adı, kullanıcı adı ve şifre bilgilerini güncelleyin. WordPress için bu dosya genellikle wp-config.php dosyasıdır.

Ayrıca veritabanındaki eski URL adreslerinin yeni geçici adresle değiştirilmesi gerekebilir. WordPress için arama-değiştirme araçları bu işlemi kolaylaştırır.

Adım 8: Siteyi Geçici URL Üzerinden Test Edin

DNS değişikliği yapmadan önce siteyi geçici adres üzerinden kapsamlı şekilde test edin. Ana sayfa, iç sayfalar, görseller, menüler ve formlar tek tek kontrol edilmelidir. E-ticaret sitesinde ödeme adımları da dahil edilmelidir.

Bu test, taşıma sonrası karşılaşacağınız sorunları erken yakalamanızı sağlar. Hata alırsanız sunucu hata günlüklerini inceleyin. Çoğu sorun, eksik dosya veya yanlış izinlerden kaynaklanır.

Adım 9: E-posta Hesaplarını Yeni Sunucuya Taşıyın

Adım 5’te listelediğiniz e-posta hesaplarını yeni sunucuda oluşturun. Gelen kutusundaki eski iletileri korumak istiyorsanız IMAP taşıma yöntemini kullanın. Bu yöntem, iletileri sunucudan sunucuya kopyalar.

E-posta gönderimi için SMTP ayarlarının yeni sunucuda doğru yapılandırıldığından emin olun. WordPress SMTP ayarları rehberi e-posta gönderim sorunlarının çözümünde size yardımcı olabilir.

Adım 10: DNS Kayıtlarını Güncelleyin

Tüm testler başarılı olduğunda sıra DNS değişikliğine gelir. Alan adı yönetim panelinizden A ve AAAA kayıtlarını yeni sunucunun IP adresine yönlendirin. MX kayıtlarını da e-posta hizmeti için güncelleyin.

Bu süre içinde bazı ziyaretçiler eski sunucuya, bazıları yeni sunucuya ulaşabilir. Bu nedenle eski sunucuyu hemen kapatmayın; birkaç gün daha açık tutmak güvenlidir.

Taşıma Sonrası Kontroller

DNS yayıldıktan sonra siteniz yeni sunucudan yayın yapmaya başlar. Ancak süreç burada bitmez. Bu aşamada güvenlik, SEO ve performans kontrolleri yapılmalıdır.

Adım 11: SSL Sertifikasını Yeniden Kurun ve Doğrulayın

Yeni sunucuda SSL sertifikanızı kurun. Sertifika genellikle Let’s Encrypt gibi ücretsiz bir kaynaktan veya hosting panelinden otomatik alınabilir. Sertifika kurulduktan sonra sitenin tüm sayfalarında kilit simgesinin göründüğünü doğrulayın.

Karışık içerik uyarısı alıyorsanız bazı görsel veya dosyalar hâlâ HTTP üzerinden yükleniyor demektir. Bu bağlantıları HTTPS olarak güncelleyin. Aksi halde tarayıcılar sayfayı güvenli göstermez.

Adım 12: 301 Yönlendirmelerini ve Kalıcı Bağlantıları Kontrol Edin

Taşıma sırasında URL yapısını değiştirdiyseniz eski adreslerden yeni adreslere 301 yönlendirmesi ekleyin. 301 yönlendirmesi, arama motorlarına sayfanın kalıcı olarak taşındığını söyler ve SEO değerini korur.

WordPress kullanıyorsanız kalıcı bağlantı ayarlarını yeniden kaydederek .htaccess dosyasının güncellenmesini sağlayabilirsiniz.

Adım 13: Site Hızını ve Performansını Test Edin

Yeni sunucudaki hız, eski sunucudan farklı olabilir. Sayfa yükleme süresini ölçmek için çeşitli çevrimiçi araçlar kullanın. Core Web Vitals rehberi, hangi metriklerin önemli olduğunu ayrıntılı şekilde açıklar.

Yavaş yükleme, kullanıcı deneyimini ve dönüşümü olumsuz etkiler. Önbellekleme, görsel optimizasyonu ve içerik dağıtım ağı gibi yöntemlerle hızı iyileştirebilirsiniz. Yeni sunucunun NVMe SSD kullanması da bu süreçte belirgin fark yaratır.

Adım 14: Google Search Console’da Adres Değişikliği Bildirin

Alan adınız değişmediyse bu adım genellikle gerekmez. Ancak siteyi farklı bir alan adına taşıdıysanız Google Search Console’da adres değişikliği aracını kullanın. Bu araç, Google’ın dizinini yeni adresinize göre güncellemesine yardımcı olur.

Google’ın resmi arama dokümantasyonu site taşıma süreçleri için güncel yönergeler sunar. Ayrıca yeni XML site haritanızı da Search Console’a gönderin.

Adım 15: Kesintisiz İzleme ve Son Testleri Yapın

Taşımadan sonraki ilk hafta sitenizi düzenli olarak izleyin. Ziyaretçi trafiği, hata günlükleri ve sunucu kaynak kullanımı gözlemlenmelidir. Özellikle e-ticaret sitelerinde sipariş bildirimlerinin ve ödeme onaylarının çalıştığını test edin.

Form gönderimleri, üyelik kayıtları ve e-posta bildirimleri de kontrol edilmelidir. Bu testlerden geçen bir site, taşıma sürecini başarıyla tamamlamış sayılır. Sorun çıkarsa erken müdahale ile büyümeden çözebilirsiniz.

Taşıma Tamamlandı: Sonraki Adımlar

Taşıma işlemi tamamlandıktan sonra eski sunucuyu hemen kapatmayın. DNS önbelleğinin tamamen temizlenmesi ve tüm ziyaretçilerin yeni adrese yönlenmesi birkaç gün sürebilir. Bu süre zarfında eski sunucu açık kalırsa hiçbir ziyaretçi hata sayfasıyla karşılaşmaz.

Ardından düzenli yedekleme planı oluşturun. Otomatik yedekleme, ileride yaşanabilecek veri kayıplarına karşı en etkili güvencedir. Ayrıca yeni sunucunun güvenlik duvarı, yazılım güncellemeleri ve izleme araçlarını da aktif tutun.

Eğer yeni bir hosting altyapısı seçme aşamasındaysanız, sitenizin ihtiyacına uygun Linux hosting veya WordPress hosting paketlerini değerlendirebilirsiniz. Doğru altyapı, taşımanın uzun vadeli başarısını belirleyen temel unsurlardan biridir.

Sıkça Sorulan Sorular

Taşıma sırasında sitem ne kadar süre erişilemez?

Doğru planlama ile site hiç kesintiye uğramayabilir. Geçici URL üzerinde test yaptıktan sonra DNS değişikliği yaparsanız ziyaretçiler yayılma süresi boyunca eski veya yeni sunucudan sorunsuz erişir.

Eski hosting hesabını ne zaman iptal etmeliyim?

DNS değişikliğinden en az 48-72 saat sonra eski hesabı iptal edin. Bu süre, tüm internet servis sağlayıcılarının DNS önbelleğini güncellemesi için yeterlidir. E-postalarınızı da yeni sunucuya taşıdığınızdan emin olun.

Taşıma sonrası e-posta gönderimi çalışmıyorsa ne yapmalıyım?

Önce MX kayıtlarının yeni sunucuya doğru yönlendiğini kontrol edin. Ardından SMTP ayarlarını ve gönderim portlarını doğrulayın. E-posta sorunları genellikle yanlış DNS kaydı veya eksik kimlik doğrulamasından kaynaklanır.

Taşıma SEO sıralamamı etkiler mi?

URL yapısı aynı kaldığı ve 301 yönlendirmeleri doğru yapıldığı sürece sıralama genellikle korunur. Google’ın yeni sunucuyu tanıması birkaç hafta sürebilir, bu normaldir. Bu süreçte site hızının düşmemesi büyük önem taşır.

Bu süreç yalnızca sürüm numarasını değiştirmekten ibaret değildir. Temanızın, eklentilerinizin ve özel kodlarınızın hedef PHP sürümüyle çalışıp çalışmayacağını bilmeniz gerekir. Aşağıdaki kontrol listesi, işlemi hatasız tamamlamanız için gereken tüm adımları içerir.

PHP Sürümü Neden Önemlidir?

PHP, sunucu tarafında çalışan ve WordPress, Joomla, PrestaShop gibi birçok altyapının temelini oluşturan betik dilidir. Hosting hesabınızda seçilen PHP sürümü, sitenizin kodunun hangi kurallarla çalışacağını belirler. Eski sürümler güvenlik yamaları almadığı için saldırıya açık hale gelir.

Güncel bir PHP sürümü aynı kodu daha hızlı işleyebilir. Bu durum sayfa açılış süresini kısaltır ve sunucu kaynaklarının daha verimli kullanılmasını sağlar. Ancak her sürüm atlaması, eski yazılmış fonksiyonların kaldırılması nedeniyle uyumluluk sorunu yaratabilir. Bu yüzden sürüm yükseltme işlemi bilinçli yapılmalıdır.

Örneğin PHP 7.4 destek süresi sona erdiği için artık güvenlik güncellemesi almaz. Böyle bir sürümde kalan site, çalışmaya devam etse bile bilinen açıklara karşı korunmasız olur. Sürüm seçiminde uygulamanızın gereksinimlerini ve PHP 8.5’in web sitelerine etkisi gibi güncel gelişmeleri birlikte değerlendirin.

Değiştirmeden Önce Yapılacaklar

Öncelikle mevcut PHP sürümünüzü öğrenin. Bunun için hosting panelinizde ilgili alan adının ayarlarına bakabilir veya geçici bir PHP bilgi dosyası oluşturabilirsiniz. Bilgi dosyası, sitenin hangi sürümle çalıştığını doğrudan gösterir.

<?php phpinfo(); ?>

Bu kodu phpinfo.php adıyla sitenizin kök dizinine yükleyip tarayıcıdan açtığınızda sürüm bilgisini görürsünüz. İşlem bitince dosyayı silmeyi unutmayın.

Aşağıdaki adımları sırayla tamamlayın:

1. Dosya ve veritabanı yedeğini hosting panelinden alın.
2. Tüm tema ve eklentilerin güncel olduğundan emin olun.
3. Eklenti geliştiricisinin sayfasından hedef PHP sürümüyle uyumluluğu kontrol edin.
4. Mümkünse canlı site yerine bir alt alan adında veya test ortamında deneme yapın.
5. Değişiklik öncesi mevcut PHP sürümünü not edin.

KeyHelp Panelinde PHP Sürümü Değiştirme

KeyHelp, alan adı bazlı PHP sürümü yönetimine izin veren bir kontrol panelidir. Panel sürümüne göre menü adları küçük farklılıklar gösterebilir. Genel akış şu şekildedir:

1. KeyHelp paneline kullanıcı bilgilerinizle giriş yapın.
2. Sol menüden veya ana ekrandan ilgili alan adını seçin.
3. PHP ayarları bölümünü açın.
4. Açılır listeden istediğiniz PHP sürümünü seçin.
5. Değişikliği kaydedin ve birkaç saniye bekleyin.

KeyHelp bazı yapılandırmalarda PHP-FPM kullanır. Bu nedenle sürüm seçimi, sitenin çalışma biçimini doğrudan değiştirir. Panelinizde seçenekler farklı görünüyorsa KeyHelp’in resmi sitesinden güncel dokümantasyona bakın. KeyHelp üzerine WordPress kurulumuyla ilgili adımları da KeyHelp WordPress kurulum rehberinde bulabilirsiniz.

cPanel ve Plesk’te PHP Sürümü Değiştirme

cPanel’de iki farklı yol vardır. Tek alan adı için Select PHP Version aracını, birden fazla alan adı için MultiPHP Manager aracını kullanabilirsiniz. İkinci araç, tüm hesaplara veya seçili alan adlarına toplu sürüm atamanıza olanak tanır.

Plesk panelinde ise Websites & Domains bölümünden ilgili siteye girin. Ardından PHP Settings sekmesini açın. Burada PHP sürümünü seçebilir, ayrıca bellek limiti ve hata gösterimi gibi ayarları düzenleyebilirsiniz.

Bazı sunucularda .htaccess dosyasına elle satır eklemek de mümkündür. Ancak bu yöntem her hosting paketinde çalışmaz ve panel ayarıyla çakışabilir. Panel üzerinden seçim yapmak her zaman daha güvenlidir.

Değiştirdikten Sonra Test Edilecekler

Sürüm değişikliğini kaydettikten sonra tarayıcı önbelleğini temizleyin. Siteyi yeni bir tarayıcı sekmesinde açın ve aşağıdaki kontrol listesini uygulayın:

• Ana sayfa, iç sayfalar ve admin paneli açılıyor mu?
• İletişim formu ve arama gibi özellikler çalışıyor mu?
• Ödeme veya üyelik adımları sorunsuz ilerliyor mu?
• Mobil görünümde bozulma var mı?
• Hata günlüğünde yeni uyarılar oluştu mu?

Site hızındaki değişimi görmek için geçişten birkaç saat sonra ölçüm yapın. PHP sürümü değiştirmek SEO sıralamasını doğrudan etkilemez; ancak site hızlanırsa dolaylı olumlu etki görülebilir. Bu konudaki ayrıntıları hosting değişikliği sonrası SEO kaybı rehberinde inceleyebilirsiniz.

Sık Karşılaşılan Hatalar ve Çözümleri

Sürüm değişikliği sonrası karşılaşabileceğiniz yaygın sorunları ve çözüm yollarını bilmek süreci hızlandırır.

• Beyaz ekran veya 500 hatası: Hata günlüğünü kontrol edin. Sorun genellikle eski bir eklentiden kaynaklanır. Eklentileri klasör adını değiştirerek devre dışı bırakın.
• Kaldırılmış fonksiyon uyarısı: Kodda artık desteklenmeyen bir fonksiyon kullanılıyordur. Temayı veya eklentiyi güncelleyin.
• Veritabanı bağlantı hatası: PHP uzantısı eksik olabilir. Panelden mysqli veya pdo_mysql uzantısının açık olduğunu kontrol edin.
• Site yavaşladı: Yeni sürümde opcache veya benzeri önbellek ayarı kapalı kalmış olabilir.

Hangi PHP Sürümünü Seçmelisiniz?

Genel kural, uygulamanızın desteklediği en güncel PHP sürümünü seçmektir. Güncel sürümler güvenlik yamaları alır ve daha iyi performans sunar. Ancak özel yazılmış eski bir sistem kullanıyorsanız uygulamanın belgelediği sürüm sınırına uyun.

WordPress ve çoğu modern içerik yönetim sistemi yeni PHP sürümlerini destekler. Yine de kurulu eklentilerinizin tamamı aynı uyumu göstermeyebilir. Güncel desteklenen sürüm listesini PHP’nin resmi sitesinden kontrol edin.

Birden fazla site yönetiyorsanız ve her siteye farklı PHP sürümü atamanız gerekiyorsa Linux Reseller hesabı bu işi panelden kolayca yönetmenizi sağlar. Her müşteri sitesini kendi PHP sürümüyle çalıştırabilirsiniz.

Sıkça Sorulan Sorular

PHP sürümünü değiştirdikten sonra eski sürüme dönebilir miyim?

Evet, çoğu hosting panelinde aynı menüden önceki sürümü seçerek geri dönebilirsiniz. Ancak geri dönüşten önce soruna neden olan eklentiyi veya temayı belirlemeniz kalıcı çözüm sağlar.

Hosting panelinde PHP seçeneği görünmüyor, ne yapmalıyım?

Bazı hosting paketlerinde PHP sürümü sabit olabilir veya destek ekibinin değiştirmesi gerekebilir. Hosting sağlayıcınızın destek ekibine mevcut paketinizin sürüm değiştirmeye izin verip vermediğini sorun.

PHP sürümü değiştirmek site hızını gerçekten artırır mı?

Eski bir sürümden güncel bir sürüme geçmek işlem süresini kısaltabilir. Ancak hız kazancı sitenin koduna, eklentilerine ve sunucu kaynaklarına göre değişir.

PHP sürümü değişikliği SEO sıralamalarını etkiler mi?

Doğrudan bir ceza söz konusu değildir. Site hızlanır ve hata sayısı azalırsa dolaylı olarak olumlu etkisi olabilir.

Ayarları doğru uyguladığınızda ilk bayt süresi (TTFB) kısalır, sayfa açılış hızı artar ve Core Web Vitals değerleri iyileşir. Çok ürünlü bir mağazada tek bir cache ayarı bile ölçülebilir fark yaratır.

PrestaShop Hızlandırma İçin Ön Hazırlık

Canlı mağazada değişiklik yapmadan önce dosyaların ve veritabanının tam yedeğini alın. CCC ayarları ve sunucu cache değişiklikleri görünümü geçici olarak bozabilir. Yedeğiniz varsa geri dönüş birkaç dakika sürer.

Mağazanız kurulum aşamasında temel yapılandırmayı kaçırdıysanız önce PrestaShop Kurulumu: 2025 İçin Adım Adım E-Ticaret Rehberi içindeki temel kontrol listesini gözden geçirin. Doğru kurulan altyapı, hızlandırma çalışmasını kolaylaştırır.

Başlamadan önce şu ön koşulları tamamlayın:

• PrestaShop yönetim paneline ve gerekirse FTP veya SSH erişimine sahip olun.
• Dosyaların ve veritabanının güncel yedeğini alın.
• PageSpeed Insights veya benzeri bir araçla mevcut hız skorunu kaydedin.
• Büyük değişiklikler sırasında mağazayı bakım moduna alın.
• Tarayıcı cache’inden etkilenmemek için testleri gizli pencerede yapın.

Yönetim Panelinde Cache ve Debug Ayarları

PrestaShop hızlandırma için ilk bakılması gereken yer “Gelişmiş Parametreler > Performans” sayfasıdır. Burada hem debug modunu kontrol eder hem de sitenin genel önbellek davranışını belirlersiniz. Sürüme göre menü adları küçük farklılıklar gösterebilir.

1. Yönetim panelinde Gelişmiş Parametreler > Performans bölümünü açın.
2. Debug modu kapalı değilse kapatın. Debug modu üretim ortamında hem güvenlik riski oluşturur hem de sayfayı yavaşlatır.
3. Cache bölümünde “Önbelleği kullan” seçeneğini etkinleştirin.
4. Sunucunuz Redis veya Memcached destekliyorsa ilgili seçeneği seçin. Destek yoksa “Dosya sistemi” seçeneği güvenli bir başlangıçtır.
5. Kaydedin ve sayfanın altındaki cache temizleme butonuna tıklayın.

Smarty Şablon Önbelleği ve CCC Ayarları

Smarty, PrestaShop’un şablon motorudur. Şablonların her ziyarette yeniden derlenmesi sayfayı belirgin biçimde yavaşlatır. Üretim ortamında yalnızca dosyalar değiştiğinde derleme yapan seçenek kullanılmalıdır.

1. Aynı performans sayfasındaki Smarty bölümünü bulun.
2. “Şablonları yalnızca dosyalar güncellendiğinde yeniden derle” seçeneğini seçin.
3. “Şablonları her çağrıda derle” seçeneğini canlı mağazada kullanmayın.
4. CCC bölümünde CSS için akıllı cache ve JavaScript için akıllı cache seçeneklerini etkinleştirin.
5. HTML sıkıştırma ve satır içi JavaScript sıkıştırma seçeneklerini açın.
6. JavaScript’i sayfa sonuna taşıma seçeneğini yalnızca tema mobilde sorunsuzsa açık bırakın.
7. Ayarları kaydedin ve Smarty cache’ini temizleyin.

CCC ayarları dosyaları birleştirir, sıkıştırır ve tarayıcı önbelleğine alır. Bazı özel temalar ve modüller bu ayarlarla uyumsuz olabilir. Sayfa düzeni bozulursa JavaScript birleştirmeyi önce kapatın, ardından CSS ayarını geri alın.

Sunucu Tarafı Cache ve Sıkıştırma

Mağaza içi ayarlar kadar sunucu tarafı cache de önemlidir. PHP OPcache, derlenmiş PHP kodunu bellekte tutar ve her istekte yeniden derlemeyi önler. Redis ise sık kullanılan verilere bellekten hızlı erişim sağlar.

VPS veya dedicated sunucu kullanıyorsanız PHP yapılandırmanıza şu OPcache değerlerini ekleyebilirsiniz:

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=2

Paylaşımlı hosting kullanıyorsanız OPcache’in açık olup olmadığını hosting sağlayıcınıza sorun. PrestaShop panelinde Redis veya Memcached seçeneğini görmüyorsanız sunucuda bu hizmetler veya gerekli PHP uzantıları kurulu olmayabilir. Bu durumda dosya tabanlı cache kullanmaya devam edin.

Sıkıştırma için GZIP veya Brotli desteği sunucu seviyesinde açılmalıdır. Barındırma altyapısı zayıfsa yazılım ayarları tek başına darboğazı çözmeyebilir. Performans odaklı e-ticaret hosting kaynakları, bu optimizasyonlarla daha uyumlu çalışır.

Apache sunucularda manuel .htaccess düzenlemesi yapacaksanız şu satırları kullanabilirsiniz:

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType text/css "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType image/svg+xml "access plus 1 month"
</IfModule>
<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css application/javascript application/json image/svg+xml
</IfModule>

PrestaShop .htaccess dosyasını yeniden ürettiğinde manuel eklemeleriniz silinebilir. Sunucu seviyesinde yapılandırma mümkünse daha kalıcıdır. Depolama tarafında NVMe SSD kullanılması, ürün görsellerinin ve veritabanı verilerinin diskten daha hızlı okunmasını sağlar. Ayrıntılı karşılaştırma için NVMe SSD Nedir? Web Sitenizin Performansını Neden Uçurur? yazısına bakabilirsiniz.

Görsel ve Veritabanı Optimizasyonu

PrestaShop mağazalarında yavaşlığın önemli bir bölümü büyük ürün görsellerinden kaynaklanır. Görselleri WebP formatına dönüştürmek, JPEG veya PNG’ye göre çoğu durumda daha düşük dosya boyutuyla benzer görüntü kalitesi sunar. PrestaShop’un destekleyen sürümlerinde WebP seçeneği görsel ayarlarından etkinleştirilebilir.

• Ürün görsellerini yüklemeden önce sıkıştırın ve aşırı yüksek çözünürlükten kaçının.
• WebP desteği varsa etkinleştirin; eski tarayıcı için dönüşüm politikasını kontrol edin.
• Tema lazy load destekliyorsa görseller için ertelemeli yüklemeyi açın.
• Kullanılmayan eski ürün görsellerini ve kopya dosyaları temizleyin.
• Ana görsel boyutlarını temanın ihtiyacına uygun şekilde sınırlayın.

Veritabanı tarafında ziyaretçi ve bağlantı kayıtları zamanla birikir. Tablo ön ekiniz genellikle ps_ şeklindedir. Temizlikten önce mutlaka yedek alın ve aşağıdakine benzer sorguları yalnızca tablo adınızı doğruladıktan sonra çalıştırın:

DELETE FROM ps_connections WHERE date_add < DATE_SUB(NOW(), INTERVAL 90 DAY);
DELETE FROM ps_guest WHERE date_add < DATE_SUB(NOW(), INTERVAL 90 DAY) AND id_customer = 0;

Düzenli veritabanı bakımı, sipariş geçmişini ve müşteri kayıtlarını etkilememeli ancak gereksiz ziyaretçi izlerini azaltmalıdır. Bu işlemi bakım modunda yapmanız olası tablo kilitlenmelerini önler.

Sık Yapılan Hatalar ve Sorun Giderme

Hızlandırma sırasında en çok karşılaşılan sorunlar cache boşaltılmaması veya uyumsuz CCC ayarlarıdır. Hata çözümünde önce en son yaptığınız değişikliği geri alın, ardından cache temizleyip test edin.

• Sayfa düzeni bozuldu: CCC içinde önce JavaScript birleştirmeyi, sonra CSS birleştirmeyi kapatın.
• Değişiklikler görünmüyor: PrestaShop cache’ini boşaltın ve tarayıcıyı gizli pencerede açın.
• Redis seçeneği kaydedilmiyor: PHP Redis uzantısının ve Redis hizmetinin sunucuda çalıştığını doğrulayın.
• .htaccess sonrası hata alınıyor: Yedek .htaccess dosyasını geri yükleyin veya PrestaShop’un SEO ve URL bölümünden yeniden üretin.
• Yönetim paneli yavaş: Gereksiz modülleri kapatın, zayıf hosting kaynaklarını gözden geçirin.

PrestaShop cache klasörünü elle temizlemek gerekirse SSH veya dosya yöneticisinden üretim cache klasörünü boşaltabilirsiniz. Bu işlem yalnızca panelden cache temizlenemediğinde yapılmalıdır:

rm -rf var/cache/prod/*
rm -rf var/cache/dev/*

Hangi Ayarları Ne Zaman Kullanmalısınız?

Düşük trafikli ve paylaşımlı hosting üzerindeki bir mağazada dosya tabanlı cache, CCC ve görsel optimizasyonu yeterli başlangıç noktasıdır. Trafik arttıkça Redis, OPcache, CDN ve HTTP/2 gibi sunucu seviyesi iyileştirmeler daha fazla fark yaratır.

Önce yönetim panelinden cache ve CCC ayarlarını yapın. Ardından görselleri hafifletin ve veritabanını temizleyin. Sunucu erişiminiz varsa OPcache değerlerini ekleyin, Redis destekli bir yapıya geçin. Her aşamada hız testlerini yinelenen ölçümlerle karşılaştırın.

PrestaShop hızlandırma tek seferlik bir iş değil, sürekli bir kontroldür. Yeni modül ekledikçe, tema güncelledikçe ve ürün sayısı büyüdükçe bu ayarları gözden geçirmek gerekir.

Sıkça Sorulan Sorular

PrestaShop cache ayarı nereden yapılır?

Yönetim panelinde “Gelişmiş Parametreler > Performans” bölümünden cache ayarları yapılır. Burada genel önbellek, Smarty şablon cache’i ve CCC seçenekleri bir arada bulunur.

CCC ayarları her temada açılmalı mı?

Çoğu modern temada güvenle çalışsa da özel veya eski temalarda JavaScript birleştirme sorun çıkarabilir. Önce JavaScript birleştirmeyi tek başına açıp mobil sayfaları kontrol etmek en güvenli yoldur.

PrestaShop Redis desteklemiyor ne yapmalıyım?

Sunucuda Redis hizmeti veya PHP Redis uzantısı yoksa panelde seçenek görünmeyebilir. Dosya tabanlı cache kullanmaya devam edin veya hosting sağlayıcınızdan Redis desteğini etkinleştirmesini isteyin.

Cache temizliği ne sıklıkla yapılmalı?

Tema, modül veya ürün düzenlemeleri yaptıktan sonra cache temizleyin. Sorun yaşanmayan günlerde düzenli temizlik şart değildir; gereksiz temizlik cache’in faydasını azaltır.

PrestaShop hızlandırma için sunucu mu yazılım mı daha önemli?

İkisi birlikte çalışır. Yazılım ayarları kötü zemin üzerinde yalnızca sınırlı iyileştirme sağlar. Yavaş disk, düşük bellek veya eski PHP sürümü varsa önce sunucu kaynakları düzeltilmelidir.

Çoğu WordPress sitesinde veritabanının önemli bir bölümü yayınlanan içerik değil; eski revizyonlar, spam yorumlar, çöp kutusu bekleyen kayıtlar ve süresi dolmuş geçici verilerden oluşur. Bunları kontrollü biçimde silmek, sitenin güncel içeriğine zarar vermeden boyutu ciddi oranda düşürebilir.

Neden Veritabanını Küçültmelisiniz?

WordPress veritabanı; yazıları, sayfaları, yorumları, kullanıcıları, tema ayarlarını ve eklenti verilerini tek bir yapıda tutar. Site yayında kaldıkça bu yapı büyür. Asıl sorun, her yazı güncellemesiyle oluşan revizyonların ve silindi sanılan kayıtların çöp kutusunda birikmesidir.

Site taşırken veritabanı dosyası büyüdükçe yükleme süresi uzar. Bazı hosting panellerinde phpMyAdmin üzerinden yüklenebilecek SQL dosyası için sınır bulunur. Büyük dosya, bu sınırı aştığında taşıma yarıda kalır veya tablolar eksik aktarılır. Küçültülmüş bir veritabanı hem daha hızlı yüklenir hem de taşıma sırasında karşılaşılan bellek ve zaman aşımı hatalarını azaltır.

Başlamadan Önce: Ön Koşullar ve Yedek Alma

Temizliğe başlamadan önce şu erişimlerden birinin olması yeterlidir:

• Sunucuda SSH erişimi ve WP-CLI
• Hosting panelindeki phpMyAdmin erişimi
• Veritabanı yönetimi için yönetici yetkisine sahip bir WordPress kullanıcısı

Erişim türü ne olursa olsun ilk adım daima tam yedek almaktır. Hem dosyaları hem veritabanını yedekleyin. WP-CLI kullanıyorsanız aşağıdaki komut veritabanını bulunduğunuz klasöre dışa aktarır:

wp db export yedek-oncesi.sql

Ayrıca hosting panelinizden tam yedek almanız, olası bir sorunda dosya ve veritabanını birlikte geri yükleyebilmenizi sağlar. WordPress site taşıma sürecinin genel adımlarını da bilmiyorsanız, önce WordPress site taşıma rehberine göz atmanız işinizi kolaylaştırır.

WordPress Veritabanı Küçültme İçin En Hızlı Yol: WP-CLI

WP-CLI, WordPress yönetimini komut satırından yapmaya yarayan resmi bir araçtır. Arayüz üzerinden dakikalarca sürebilecek temizlik işlemlerini genellikle saniyeler içinde tamamlar. Öncelikle hangi tablonun ne kadar yer kapladığını görmek faydalıdır:

wp db size --tables

Bu komut, temizlik öncesi ve sonrası karşılaştırma yapmak için iyi bir başlangıç noktasıdır. Ardından sırasıyla şu işlemleri uygulayabilirsiniz:

1. Revizyonları temizleyin: WordPress, her kaydetmede bir revizyon oluşturur. Yıllar içinde yüzlerce gereksiz revizyon birikebilir.

wp post delete $(wp post list --post_type='revision' --format=ids) --force

2. Otomatik taslakları silin: Kaydedilmeden kalan otomatik taslaklar da zamanla yer kaplar.

wp post delete $(wp post list --post_status=auto-draft --format=ids) --force

3. Spam ve çöp kutusundaki yorumları temizleyin: Spam klasörü, büyük sitelerde veritabanının en hızlı şişen bölümlerinden biridir.

wp comment delete $(wp comment list --status=spam --format=ids) --force
wp comment delete $(wp comment list --status=trash --format=ids) --force

4. Süresi dolmuş geçici verileri temizleyin: Transient, WordPress’in geçici olarak sakladığı önbellek kayıtlarıdır. Süresi dolanlar güvenle silinebilir.

wp transient delete --expired

5. Tabloları optimize edin: Silinen kayıtların bıraktığı boş alanları temizler.

wp db optimize

phpMyAdmin ile Manuel Temizlik

Sunucuya SSH erişiminiz yoksa hosting panelindeki phpMyAdmin aracı aynı işlemi manuel olarak yapmanızı sağlar. phpMyAdmin, MySQL veritabanlarını tarayıcı üzerinden yönetmeye yarayan web tabanlı bir araçtır. Site dosyalarınıza dokunmadan yalnızca veritabanına müdahale eder.

Aşağıdaki adımları uygulamadan önce veritabanını dışa aktardığınızdan emin olun:

1. Hosting panelinden phpMyAdmin’i açın ve WordPress veritabanını seçin.
2. Tablo listesinde her tablonun boyutunu ve satır sayısını inceleyin.
3. SQL sekmesine geçin ve aşağıdaki sorguları tek tek çalıştırın.

Revizyonları silmek için:

DELETE FROM wp_posts WHERE post_type = 'revision';

Çöp kutusundaki yazıları silmek için:

DELETE FROM wp_posts WHERE post_status = 'trash';

Spam ve çöp kutusundaki yorumları silmek için:

DELETE FROM wp_comments WHERE comment_approved IN ('spam', 'trash');

Sorgular bitince phpMyAdmin’in tablo listesine dönün. Temizlediğiniz tabloları işaretleyip Optimize tablo seçeneğini uygulayın. Bu işlem, silme sonrasında kalan boş alanı geri kazandırır.

Eklentiyle Güvenli Temizlik

Komut satırı veya SQL sorgusu kullanmak istemiyorsanız, güvenilir bir temizlik eklentisi de aynı sonucu verir. Yaygın kullanılan seçenekler şunlardır:

• WP-Optimize: Veritabanı temizliği, tablo optimizasyonu ve temel önbellek özellikleri sunar.
• Advanced Database Cleaner: Planlı temizlik ve eski kayıtları düzenli olarak silme konusunda esneklik sağlar.
• WP-Sweep: Revizyon, çöp kutusu ve spam yorum temizliğini sade bir arayüzle yapar.

Eklenti kullanırken temizlik alanlarını tek tek seçmek önemlidir. Bilmediğiniz bir tablo veya kayıt grubunu seçmeyin. Temizlik tamamlandıktan sonra eklentiyi devre dışı bırakmak da sitenin gereksiz yük taşımasını engeller. WordPress yavaş eklentiler rehberi, hangi tür eklentilerin performansı düşürdüğünü anlamanıza yardımcı olabilir.

Hangi Veriler Güvenle Silinir?

Temizliğin en kritik kısmı, neyi silip neyi koruyacağınızı bilmektir. Aşağıdaki kayıtlar çoğu WordPress sitesinde güvenle temizlenebilir:

• Eski yazı revizyonları
• Çöp kutusundaki yazı ve sayfalar
• Spam ve çöp kutusundaki yorumlar
• Süresi dolmuş geçici veriler
• Kullanılmayan eklentilerden kalan temizlenebilir kayıtlar

Buna karşılık şu tablolara ve kayıtlara dokunmayın:

• Yayınlanmış yazı, sayfa ve ürünlerin bulunduğu tablolar
• Kullanıcı hesapları ve şifre bilgileri
• WooCommerce sipariş, müşteri ve stok verileri
• Eklentilerin aktif ayarlarını tutan tablolar
• Site adı, adresi ve kalıcı bağlantı ayarları gibi temel seçenekler

Özellikle wp_options tablosu, WordPress’in kalbi sayılır. İçinde hem kritik ayarlar hem de geçici veriler bulunur. Hangi seçeneklerin fazla yer kapladığını şu sorguyla görebilirsiniz:

SELECT option_name, LENGTH(option_value) AS boyut
FROM wp_options
WHERE autoload = 'yes'
ORDER BY boyut DESC
LIMIT 20;

Bu liste yalnızca inceleme amaçlıdır. Büyük görünen bir kaydı, ne işe yaradığını doğrulamadan silmeyin. Özellikle eklenti ayarları, tema ayarları ve site kimliğiyle ilgili seçenekler kritik olabilir.

Tablo Optimizasyonu ve Overhead Temizliği

Silinen kayıtlar veritabanından hemen tamamen yok olmaz. Bazı depolama yapılarında tablo içinde boş alan kalır. Bu boş alana overhead denir. Overhead, tablo boyutunu olduğundan büyük gösterir ve yedek dosyasının gereksiz yere şişmesine neden olabilir.

Overhead’i temizlemek için WP-CLI kullanıyorsanız yukarıdaki wp db optimize komutu yeterlidir. phpMyAdmin kullanıyorsanız tablo listesinde Overhead sütununu kontrol edin. Boş alanı olan tabloları işaretleyip Optimize tablo seçeneğini uygulayın.

Site Taşırken Yapılmaması Gerekenler

Veritabanı küçültme işlemi dikkatli yapılmadığında taşımayı kolaylaştırmak yerine yeni sorunlar yaratır. Şu hatalardan kaçının:

• Yedeksiz temizlik yapmak: Yanlış bir sorgu, canlı sitenin içeriğini geri alınamaz biçimde silebilir.
• Tablo ön ekini varsaymak: Her WordPress kurulumunda wp_ olmayabilir. Ön eki kontrol etmeden sorgu çalıştırmayın.
• Bilinmeyen tabloları silmek: Eklentinin kullandığı tabloyu silmek, eklentinin çalışmasını bozabilir.
• Canlı sitede uzun süre bakım yapmak: Taşıma öncesi temizlik, mümkünse test ortamında denenmelidir.
• Temizlik sonrası testi atlamak: Yeni sunucuya aktardıktan sonra yazıların, yorumların ve eklentilerin doğru çalıştığını kontrol edin.

Özellikle taşıma sırasında eklenti kaynaklı hatalar sık görülür. WordPress site taşıma sırasında eklentilerin neden çöktüğünü anlatan rehbere göz atmak, taşıma sürecini daha sorunsuz hale getirir.

Sık Karşılaşılan Sorunlar ve Çözümleri

Temizlik ve taşıma sürecinde en sık karşılaşılan sorunlar genellikle boyut, zaman aşımı ve erişim kaynaklıdır.

phpMyAdmin içe aktarma sırasında zaman aşımı yaşıyorum

SQL dosyanız hâlâ büyükse hosting panelinizin dosya yöneticisiyle yüklemek yerine komut satırından içe aktarma yapmayı deneyin. WP-CLI erişiminiz varsa şu komut kullanılabilir:

wp db import tasima-oncesi.sql

Komut, dosya adını doğru yazdığınızda phpMyAdmin arayüzündeki birçok zaman aşımı sorununu ortadan kaldırır.

Yanlış bir sorgu çalıştırdım, ne yapmalıyım?

Hemen yeni işlem yapmayı bırakın ve temizlik öncesi aldığınız yedeği geri yükleyin. Bu nedenle yedek dosyasının yalnızca sunucuda değil, kendi bilgisayarınızda da bir kopyasının bulunması önemlidir.

Veritabanı temizlenmesine rağmen boyut hâlâ büyük

Büyük boyutun kaynağı her zaman çöp veriler değildir. E-ticaret siparişleri, üyelik kayıtları, form gönderimleri veya log tabloları doğası gereği büyük olabilir. Yayınlanan içeriğe ve iş verisine dokunmadan yalnızca güvenli alanları temizlediğinizden emin olun.

Taşıma sonrası 500 hatası alıyorum

Yanlış tablo ön eki, eksik tablo veya bozuk veritabanı dosyası bu hataya yol açabilir. Veritabanını yeniden dışa aktarıp doğru biçimde içe aktardıktan sonra sorun devam ediyorsa WordPress 500 hatası çözüm rehberine başvurabilirsiniz.

Hangi Yöntemi Seçmelisiniz?

Yöntem seçimi tamamen erişim düzeyinize ve teknik alışkanlığınıza bağlıdır. SSH ve WP-CLI erişiminiz varsa komut satırı en hızlı ve en kontrollü yoldur. Yalnızca hosting paneli erişiminiz varsa phpMyAdmin ile SQL sorguları yeterli olur. Teknik sorgularla uğraşmak istemiyorsanız, güvenilir bir temizlik eklentisi de işi görür.

Hangi yöntemi seçerseniz seçin sıra aynı kalmalıdır: yedek alın, gereksiz kayıtları temizleyin, tabloları optimize edin ve sonucu test edin. Site taşıdıktan sonra yeni sunucuda da hızlı depolama ve düşük gecikme istiyorsanız, performans odaklı WordPress barındırma seçeneklerini değerlendirebilirsiniz.

Sıkça Sorulan Sorular

Veritabanı küçültme site hızını artırır mı?

Boyut tek başına hızı belirlemez. Ancak gereksiz kayıtlar nedeniyle şişen tablolar ve bakımsız bir veritabanı, bazı sorguları yavaşlatabilir. Küçültme özellikle yedek alma ve site taşıma süresini kısaltır.

phpMyAdmin yerine WP-CLI kullanmak daha mı güvenli?

İkisi de doğru kullanıldığında güvenlidir. WP-CLI, tekrar eden işlemleri daha hızlı tamamlar ve hata mesajlarını genellikle daha net gösterir. phpMyAdmin ise sunucuya SSH erişimi olmayan kullanıcılar için pratik bir alternatiftir.

Revizyonları silmek SEO’ya zarar verir mi?

Hayır. Revizyonlar yayınlanan içeriğin eski kopyalarıdır ve ziyaretçiler tarafından görülmez. Güncel yazı ve sayfa içeriği değişmediği sürece SEO açısından bir kayıp oluşmaz.

Taşımadan önce tüm eklenti tablolarını silebilir miyim?

Hayır. Aktif eklentilerin ayarları kaybolur ve site taşındığında eklentiler sıfırdan yapılandırılmak zorunda kalır. Yalnızca kullanılmayan, tamamen kaldırılmış eklentilerden kalan tablolar temizlik adayı olabilir.

Veritabanı boyutu ne kadar olduğunda taşımada sorun çıkar?

Bu, hosting sağlayıcısının belirlediği içe aktarma sınırına ve disk kotasına göre değişir. Kesin bir rakam vermek yerine, mevcut hosting panelinizin phpMyAdmin içe aktarma limitini kontrol etmeniz en doğru yaklaşımdır.

Bu yazıda iki çözümü kurulum, yönetim yükü, kaynak tüketimi ve saldırı önleme yetenekleri üzerinden karşılaştıracağız. Sunucunuzun yapısına ve yönetim alışkanlığınıza uygun seçimi netleştirmenize yardımcı olacak kriterleri bulacaksınız.

Imunify360 ve CSF Nedir?

Imunify360, Linux sunucuları korumak için geliştirilen ticari bir güvenlik platformudur. Firewall, web uygulama güvenlik duvarı (WAF), antivirüs, şüpheli dosya algılama ve ağ saldırı engelleme modüllerini tek bir panelde birleştirir. Özellikle CloudLinux, cPanel, Plesk ve DirectAdmin ortamlarıyla sıkı entegre çalışır. Güncel lisans ve uyumluluk bilgileri için Imunify360’ın resmi sayfası kontrol edilebilir.

CSF yani ConfigServer Security & Firewall, iptables tabanlı ücretsiz bir firewall ve süreç izleme aracıdır. Linux Malware Detect ise kısaca Maldet olarak bilinir ve sunucudaki dosyaları tarayarak zararlı yazılımları, web shell’leri ve tehlikeli betikleri bulmaya odaklanır. İkili, VPS ve dedicated sunucu yöneticilerinin yaygın kullandığı klasik bir güvenlik katmanıdır. CSF’nin özelliklerine ConfigServer’ın CSF sayfası üzerinden ulaşabilirsiniz.

Karar Özeti: Hangi Durumda Hangisi?

Yönetilen hesap sayısı fazlaysa ve müşterilere otomatik koruma vaadi sunmanız gerekiyorsa Imunify360 daha tutarlı bir seçimdir. Tek sunucuda birkaç site barındıran bir ajans veya geliştirici iseniz CSF + Maldet genellikle yeterli olur.

Bu seçimde maliyet tek başına belirleyici değildir. Otomasyon, zaman, destek ihtiyacı ve saldırı yüzeyi de kararın bir parçasıdır. Aşağıdaki tablo temel ölçütleri yan yana görmenizi sağlar.

Kriter Bazlı Karşılaştırma

Imunify360’ın Güçlü ve Zayıf Yönleri

Imunify360’ın en büyük avantajı dağınık güvenlik araçlarını tek panelde birleştirmesidir. Saldırılar, zararlı dosyalar ve engellenen IP’ler aynı arayüzden izlenir. Bu durum özellikle birden fazla sunucu yöneten hosting firmalarında ciddi zaman kazandırır.

Güçlü yönler:

• SQL enjeksiyonu, XSS ve benzeri web saldırılarını WAF katmanında azaltır.
• Zararlı yazılımları otomatik algılayıp karantinaya alabilir.
• Bulut tabanlı tehdit istihbaratı sayesinde yeni imzalar hızla dağıtılır.
• Grafik arayüz, güvenlik olaylarını hızlı yorumlamayı kolaylaştırır.

Zayıf yönler:

• Ticari maliyet oluşturur; ölçek büyüdükçe lisans gideri artabilir.
• Belirli panel ve dağıtımlara bağımlıdır.
• Kapalı kutu yapısı nedeniyle çok özel kural yazmak sınırlıdır.
• Düşük kaynaklı sunucularda sürekli çalışan ajan fark edilebilir bir yük oluşturur.

CSF + Maldet’in Güçlü ve Zayıf Yönleri

CSF, sunucu seviyesinde oldukça esnek bir kontrol sağlar. Kendi port kurallarınızı, bağlantı limitlerinizi ve IP engelleme stratejilerinizi doğrudan yapılandırabilirsiniz. Maldet ise tarama odaklı yapısıyla barındırılan sitelerdeki zararlı dosyaları tespit etmeye çalışır.

Güçlü yönler:

• Ücretsizdir ve geniş bir topluluk kullanıcı tabanına sahiptir.
• iptables üzerinden düşük seviyeli erişim kuralları yazılabilir.
• Sunucuya özel ince ayar yapmak kolaydır.
• Temel kaynak kullanımı genellikle düşüktür ve kontrol edilebilir.

Zayıf yönler:

• WAF sağlamadığı için uygulama katmanı saldırılarını tek başına durdurmaz.
• Otomatik tehdit istihbaratı sınırlıdır.
• Tarama zamanlamaları ve sonuçları elle yönetilir.
• Yanlış yazılan bir kural sunucuya erişiminizi tamamen kapatabilir.

Kurulum ve Yönetim Yükü

Imunify360 kurulumu tek komutla başlasa da lisans aktivasyonu, panel entegrasyonu ve modül ayarları belirli bir zaman alır. Buna karşın kurulum tamamlandıktan sonra günlük yönetim çoğunlukla panelden izleme ve hızlı müdahaleye dayanır.

CSF + Maldet tarafında CSF kurulumu basit olsa da Maldet’i eklemek ve imza güncellemelerini düzenli hale getirmek gerekir. Fail2ban gibi ek araçlarla boşlukları kapatmak da çoğu kurulumda kaçınılmazdır. Sıfırdan güvenli bir sunucu yapılandırıyorsanız Ubuntu 22.04 / 24.04 İlk Sunucu Kurulumu ve Temel Güvenlik Ayarları rehberi sağlam bir başlangıç sunar.

CSF + Maldet kurulumunu adım adım ilerletmek istiyorsanız ClamAV + Maldet + Custom DB ile Ücretsiz Imunify360 Alternatifi yazımızda yapılandırma detaylarını bulabilirsiniz.

Güvenlik Yaklaşımlarındaki Temel Fark

Imunify360, saldırıyı önceden tespit etmeye odaklanır. Bulut tabanlı imzalar ve davranış analizi sayesinde yeni ortaya çıkan bir web shell veya bilinen bir saldırı kalıbı hızla engellenebilir. Bu model, yüzlerce hesabın barındırıldığı ortamlarda büyük avantaj sağlar.

CSF + Maldet daha çok statik kurallar ve düzenli taramalar üzerine kuruludur. Zararlı yazılım genellikle tarama yapıldıktan sonra tespit edilir. Bu yüzden gerçek zamanlı koruma önceliğinizse Imunify360 daha güçlü bir varsayılan sunar. Buna karşın sisteminize hâkim olmak ve her kuralı kendiniz yönetmek istiyorsanız CSF’nin sunduğu kontrol daha değerlidir.

Kaynak Tüketimi ve Performans Etkisi

Imunify360’ın koruma ajanı sürekli çalışır. 1-2 GB RAM’e sahip küçük sunucularda bu yük belirginleşebilir. Kurulumdan sonra sunucu performansını izlemek ve gerekirse tarama zamanlarını ayarlamak önemlidir.

CSF kendisi genellikle hafif bir yapıya sahiptir. Asıl kaynak tüketimi Maldet taramaları sırasında ortaya çıkar. Büyük dizinler tarandığında CPU ve disk I/O değerleri yükselebilir. Taramayı gece saatlerine koymak, sitelerinizi yavaşlatmadan güvenlik kontrolü yapmanın en pratik yoludur.

WordPress sitelerinde güvenlik aracının yarattığı ek yükü ölçmek için WordPress CPU Kullanımı Masterclass yazısı kararınızı destekleyebilir.

Hangi Senaryoda Ne Kullanılmalı?

• Paylaşımlı hosting sağlayıcısı: Imunify360, hesap başına oluşan tehditleri tek panelden izlemek ve otomatik engellemek için daha uygundur.
• Tek WordPress VPS’i yöneten ajans: CSF + Maldet genellikle yeterli olur. Ekstra WAF ihtiyacı, uygulama katmanında ayrı bir çözümle karşılanabilir.
• E-ticaret sitesi işleten girişimci: İşlem güvenliği öncelikse Imunify360’ın WAF katmanı avantaj sağlar. Bütçe kısıtlıysa CSF + Maldet ile düzenli uygulama güncellemesi şarttır.
• Reseller hosting müşterisi: Müşteri hesaplarını ayırmak ve her hesabı güvende tutmak isteyen reseller’lar için Imunify360 daha verimli bir izleme sunar.
• Kendi altyapısını yöneten tek yönetici: CSF + Maldet düşük maliyet ve yüksek kontrol isteyen bu senaryoda güçlüdür.

Sunucu Güvenliğinde Kararınızı Netleştirin

Kararı netleştirmek için dört soruyu cevaplayın: Kaç hesap barındırıyorsunuz, aylık güvenlik bütçeniz nedir, sunucu paneliniz hangisi, güvenlik olaylarına ne kadar zaman ayırabilirsiniz? Cevaplar çoğunlukla Imunify360 veya CSF + Maldet yönünde güçlü bir işaret verir.

İki çözümü de önce test ortamında denemek en sağlıklı yoldur. Özellikle canlı sunucuda kural değişikliği yapmadan önce yedek almak ve geri alabilir durumda olmak gerekir. Seçimden sonra sunucu altyapınızın güncel paketlerle yönetiliyor olması da güvenlik yazılımı kadar değerlidir. Sunucuyu kendiniz yönetmek istemiyorsanız Linux Hosting paketlerine göz atabilirsiniz.

Sıkça Sorulan Sorular

CSF ve Imunify360 aynı sunucuda birlikte kullanılabilir mi?

Genellikle önerilmez. Imunify360 kendi firewall modülünü içerir. İki firewall aynı anda kural uygularsa çakışma ve beklenmeyen erişim sorunları yaşanabilir. Geçiş döneminde ayrı bir test sunucusu kullanmak daha güvenlidir.

Imunify360 ücretsiz mi?

Hayır, ticari bir üründür. Lisanslama modeli sunucu adedine ve barındırılan hesap sayısına göre değişebilir. Güncel fiyat bilgisi için Imunify360’ın resmi sayfası kontrol edilmelidir.

CSF + Maldet web uygulama saldırılarını engeller mi?

CSF ağ seviyesinde IP engelleme yapar. Ancak SQL enjeksiyonu veya XSS gibi uygulama katmanı saldırılarını süzen bir WAF değildir. Bu tür tehditler için uygulama güncellemeleri ve ek önlemler gerekir.

Maldet ile ClamAV aynı araç mıdır?

Hayır. Linux Malware Detect, ClamAV motorunu kullanabilen ancak kendi web shell imzalarını da ekleyen bir tarama aracıdır. İkisini birlikte kullanmak daha kapsamlı tarama sağlayabilir.

Imunify360 hangi ortamlarda çalışır?

En yaygın olarak CloudLinux, cPanel, Plesk ve DirectAdmin ortamlarında kullanılır. Kurulumdan önce dağıtımınızın ve panel sürümünüzün desteklendiğini resmi belgelerden doğrulamanız gerekir.

Aşağıda iki seçeneği performans, güvenlik, yönetim ve maliyet kriterlerine göre karşılaştırıyoruz. Böylece hangi aşamada VPS’e geçmeniz gerektiğini de net biçimde göreceksiniz.

PrestaShop İçin Hızlı Karar: Hangisi Size Uygun?

PrestaShop için VPS mi hosting mi kararında en belirleyici faktör trafik ve sipariş yoğunluğudur. Günlük birkaç yüz ziyaretçi alan yeni bir mağaza için paylaşımlı hosting yeterlidir. Günlük binlerce ziyaretçi, yoğun kampanya dönemleri veya özel cron görevleri söz konusuysa VPS’e yönelmek daha sağlıklıdır.

Aşağıdaki tablo iki seçeneği ana kriterlerde özetler. Kendi mağazanızın önceliklerini düşünerek okumanız, kararı netleştirir.

İki altyapı arasındaki genel farkları VPS ve paylaşımlı hosting karşılaştırması yazısında daha ayrıntılı bulabilirsiniz. PrestaShop’a özel nüansları ise aşağıdaki bölümlerde ele alıyoruz.

PrestaShop’un Kaynak Gereksinimleri

PrestaShop, PHP ile çalışan ve MySQL veya MariaDB veritabanı kullanan açık kaynaklı bir e-ticaret platformudur. Her PrestaShop sürümü belirli bir PHP ve veritabanı sürüm aralığını destekler. Kurulumdan önce resmi PrestaShop sürüm notlarını kontrol etmeniz gerekir.

Bu gereksinimleri hem paylaşımlı hosting hem VPS karşılayabilir. Asıl fark, kaynakların ne kadarının sitenize ayrıldığıdır. Paylaşımlı ortamda kotanız sınırlıdır, VPS’te ise belirlenen kapasite doğrudan size aittir.

PrestaShop mağazalarında ürün sayısı arttıkça veritabanı sorguları çoğalır. Çok sayıda ürün, kategori ve eş zamanlı ziyaretçi aynı anda sunucuyu zorlar. Bu nedenle RAM, CPU ve özellikle disk hızı önem kazanır. NVMe SSD gibi hızlı disk teknolojisi, veritabanı okuma sürelerini belirgin biçimde düşürür.

Teknik gereksinimlerin tam listesini PrestaShop Hosting Gereksinimleri yazısında ayrıntılı biçimde ele aldık. Bu liste, altyapınızın PrestaShop ile uyumlu olup olmadığını hızla kontrol etmenizi sağlar.

Paylaşımlı Hosting PrestaShop İçin Yeterli mi?

Paylaşımlı hosting, bir sunucunun kaynaklarını birden fazla web sitesinin ortak kullandığı altyapıdır. PrestaShop mağazaları için uygun fiyatlı ve yönetimi kolay bir başlangıç noktasıdır. Yeni açılan mağazaların büyük bölümü bu çözümle sorunsuz çalışır.

Ancak komşu siteler CPU veya disk I/O tükettiğinde mağazanız yavaşlayabilir. Bu yüzden sıradan bir hosting yerine e-ticaret için optimize edilmiş paketleri tercih etmek önemlidir. PrestaShop için yapılandırılmış e-ticaret hosting paketleri, kaynakları mağaza ihtiyacına göre dengeler.

Paylaşımlı hostingin güçlü yönleri genel olarak şöyledir:

• Düşük başlangıç maliyeti
• Panel üzerinden kolay yönetim
• Otomatik yedekleme ve temel güvenlik önlemleri
• Teknik sunucu bilgisi gerektirmemesi

Zayıf yönleri ise kaynakların paylaşılması, sınırlı özelleştirme ve yüksek trafikte yetersiz kalabilmesidir. Düşük trafikli bir mağazada bu dezavantajlar genellikle hissedilmez.

VPS Ne Zaman Gerekli Olur?

VPS, fiziksel sunucunun sanal parçalara bölünmesiyle oluşturulan izole bir sunucudur. Size ayrılmış CPU, RAM ve disk alanı sunar. PrestaShop mağazanız büyüdüğünde veya özel yapılandırma gerektirdiğinde VPS devreye girer.

VPS’e geçişi gerektiren durumlar şunlardır:

• Günlük binlerce ziyaretçi ve yüksek sipariş hacmi
• Black Friday gibi yoğun kampanya dönemleri
• Özel PHP ayarları veya ek modül gereksinimleri
• Birden fazla mağaza ya da ek uygulama çalıştırma ihtiyacı
• Tam sunucu kontrolü ve özel güvenlik kuralları talebi

VPS’e geçmeden önce trafik verilerinizi ve sunucu kaynak kullanımınızı ölçün. Tahminle değil, gerçek veriyle karar vermek gereksiz maliyeti önler.

Performans ve Ölçeklenebilirlik

Performans, PrestaShop mağazalarında dönüşümü doğrudan etkiler. Yavaş açılan bir sayfa sepet terk oranını artırır. Bu yüzden altyapı seçerken yalnızca bugünü değil, büyüme planınızı da düşünmeniz gerekir.

Paylaşımlı hostingde performans genellikle planın CPU ve RAM kotasıyla sınırlıdır. VPS’te ise daha yüksek ve istikrarlı performans elde edersiniz. Kaynak kullanımınız arttığında VPS’i dikey olarak büyütmek de mümkündür.

Kesintisiz çalışma süresi performans kadar önemlidir. Uptime kavramını ve %99,9 çalışma süresini ayrı bir yazıda açıkladık. Özellikle e-ticaret siteleri için uptime garantisi sunan sağlayıcıları tercih etmelisiniz.

Güvenlik ve Kaynak İzolasyonu

Güvenlik, e-ticaret siteleri için kritik bir konudur. Paylaşımlı hostingde saldırıya uğrayan başka bir site, aynı sunucudaki diğer hesapları dolaylı biçimde etkileyebilir. VPS’te ise her hesap kendi sanal ortamında izole çalışır.

Ancak VPS kullanıyorsanız güvenlik güncellemelerini ve sunucu yapılandırmasını siz veya hizmet aldığınız yönetim ekibi takip etmelidir. Paylaşımlı hostingde bu sorumluluk büyük ölçüde sağlayıcıdadır. Yani izolasyon avantajı, beraberinde ek yönetim sorumluluğu getirir.

Paylaşımlı hosting kullanıyorsanız alabileceğiniz pratik önlemleri Paylaşımlı Hosting Güvenlik Rehberi yazısında bulabilirsiniz. Bu önlemler, ortak barındırma ortamındaki riskleri azaltmanıza yardımcı olur.

Yönetim Kolaylığı ve Teknik Bilgi

Paylaşımlı hostingde sunucu yönetimiyle uğraşmazsınız. Panel üzerinden dosya, veritabanı ve e-posta işlemlerini yaparsınız. Günlük işleriniz mağaza yönetimine odaklanır.

VPS’te ise işletim sistemi, web sunucusu ve güvenlik duvarı gibi katmanları yönetmeniz gerekir. Teknik ekibi olmayan mağazalar için yönetilen VPS veya yönetilen e-ticaret hosting daha az risklidir. Yönetilen çözümde sağlayıcı; güncelleme, yedekleme ve temel güvenlik işlemlerini üstlenir.

Bu noktada kendi yetkinliğinizi değerlendirin. Sunucu yönetimi tecrübeniz yoksa yönetilmeyen VPS almak yerine yönetilen bir çözüm seçmek uzun vadede daha verimlidir.

Maliyet Karşılaştırması

Paylaşımlı hosting başlangıç maliyeti açısından daha avantajlıdır. VPS ise daha yüksek bir aylık ücret gerektirir. Ancak maliyeti yalnızca barındırma ücreti olarak düşünmeyin.

Yönetilmeyen VPS kullanıyorsanız sunucu yönetimi için harcadığınız zamanı veya dış kaynak maliyetini de hesaba katın. Öte yandan yüksek trafikte yavaş kalan bir paylaşımlı hosting, kaybedilen satışlarla daha pahalıya gelebilir.

Karar verirken aylık fiyata değil, toplam sahip olma maliyetine odaklanın. Küçük bir mağaza için VPS’in ek yönetim yükü gereksiz olabilir. Büyüyen bir mağaza içinse paylaşımlı hostingden kaynaklanan yavaşlık daha büyük bir maliyet yaratır.

Hangi Senaryoda Hangisini Seçmeli?

Senaryoya göre net öneriler şöyledir:

• Yeni açılan mağaza, düşük trafik: Paylaşımlı e-ticaret hosting yeterli.
• Büyüyen mağaza, günlük binlerce ziyaretçi: VPS veya yönetilen VPS daha uygun.
• Yoğun kampanya dönemleri: VPS veya kaynakları artırılabilen hosting tercih edin.
• Özel modül veya PHP ayarı gerektiren mağaza: VPS şart.
• Birden fazla mağaza veya ek uygulama: VPS daha verimli.

Karar verirken mevcut trafiğinizi, sipariş sayınızı ve büyüme hedefinizi ölçün. Hangi seçeneği seçerseniz seçin, PrestaShop sürüm gereksinimlerini karşılayan ve NVMe SSD gibi hızlı disk teknolojisi kullanan bir sağlayıcı seçin. Bu iki kriter, mağazanızın uzun vadeli sağlığını belirleyen temel unsurlardır.

Sıkça Sorulan Sorular

Paylaşımlı hosting PrestaShop için yavaş kalır mı?

Hayır, kaliteli bir paylaşımlı hosting düşük ve orta trafikli mağazalar için yeterli hız sunar. Ancak yoğun trafikte veya kaynakları zorlayan modüllerde yavaşlama yaşanabilir.

VPS’e geçiş zamanı nasıl anlaşılır?

Sayfa açılış süreleri uzuyorsa, sık sık kaynak limiti uyarısı alıyorsanız veya kampanya dönemlerinde site yanıt vermiyorsa VPS’e geçiş zamanı gelmiş olabilir.

Yönetilen VPS ile yönetilmeyen VPS arasındaki fark nedir?

Yönetilen VPS’te sağlayıcı sunucu güncellemelerini, güvenlik yamalarını ve izlemeyi üstlenir. Yönetilmeyen VPS’te bu görevler size aittir.

PrestaShop için NVMe SSD hosting yeterli mi?

NVMe SSD, veritabanı okuma hızını artırır ve PrestaShop performansına olumlu yansır. Küçük ve orta ölçekli mağazalar için yeterli olabilir; büyüyen mağazalarda VPS’e geçiş gerekebilir.

WordPress 6.3 ve sonrasındaki sürümler, yerleşik performans iyileştirmeleriyle eklenti kullanmadan da somut kazanç sağlar. Aşağıdaki yedi yöntem, uygulama kolaylığı ve TTFB üzerindeki etkisine göre sıralanmıştır; her başlıkta yöntemin kime uygun olduğunu ve nelere dikkat etmeniz gerektiğini bulacaksınız.

TTFB Nedir ve WordPress’te Neden Yükselir?

TTFB (Time to First Byte), tarayıcının sayfa isteği göndermesiyle sunucudan gelen ilk baytın alınması arasındaki süredir. WordPress’te bu süre; DNS çözümlemesi, TLS el sıkışması, sunucunun PHP’yi başlatması, veritabanı sorguları ve tema/eklenti kodunun çalışması gibi adımları kapsar. Bu kavramı daha önce TTFB nedir yazısında ayrıntılı ele almıştık.

WordPress sitelerde TTFB’nin yükselmesinin birkaç tipik nedeni vardır. Paylaşımlı ve yetersiz kaynaklı sunucular, eski PHP sürümleri, önbelleğin kapalı olması, şişmiş veritabanı ve fazla sayıda eklenti en sık görülen sebeplerdir. Tarayıcı, sunucu ilk baytı ne kadar geç gönderirse sayfa içeriği de o kadar geç oluşmaya başlar.

TTFB’yi Düşüren 7 Performans Ayarı

1. Sayfa Önbelleğini (Page Cache) Etkinleştirin

Sayfa önbelleği, sunucunun ürettiği son HTML çıktısını bir kopya olarak saklar. Sonraki ziyaretçi aynı sayfayı istediğinde sunucu PHP’yi ve veritabanını yeniden çalıştırmak yerine bu hazır kopyayı doğrudan gönderir. Bu sayede TTFB, dinamik sayfa üretim süresinin büyük kısmından kurtulur.

WP Super Cache, W3 Total Cache, WP Rocket ve LiteSpeed Cache bu iş için yaygın kullanılan eklentilerdir. Sunucu düzeyinde önbellek kurulabilen bazı Linux hosting panellerinde ise Nginx FastCGI cache gibi yöntemler daha tutarlı sonuç verir. Bu yöntem özellikle anonim ziyaretçi trafiği yüksek bloglar ve kurumsal siteler için uygundur; oturum açmış kullanıcılar için genellikle devre dışı kalır ve içerik güncellendiğinde önbelleği temizlemeniz gerekir.

2. Güncel PHP Sürümü ve OPcache Kullanın

PHP, WordPress’in temel çalışma dilidir ve her istekte tema, çekirdek ve eklenti kodlarını işler. Güncel PHP 8.x sürümleri, eski sürümlere göre aynı işi daha az bellek ve daha kısa sürede tamamlar. OPcache ise derlenmiş PHP betiklerini bellekte tutarak her istekte yeniden derleme maliyetini ortadan kaldırır.

Hosting panelinizden PHP sürümünü değiştirebilir ve OPcache durumunu kontrol edebilirsiniz. KeyHelp gibi panellerde bu ayar genellikle birkaç tıkla yapılır. PHP sürümünü yükseltmeden önce eski tema ve eklentilerin uyumluluğunu bir test ortamında doğrulayın; OPcache ayarları için PHP’nin OPcache belgeleri yol göstericidir.

3. Veritabanını Temizleyin, Autoload Edilen Seçenekleri Azaltın

WordPress, her sayfa yüklendiğinde wp_options tablosundaki autoload seçeneklerini okur. Eklentiler zamanla bu tabloya çok sayıda gereksiz kayıt bırakabilir. Ayrıca revizyonlar, geçici veriler (transient), spam yorumlar ve sahipsiz meta kayıtları veritabanını şişirerek sorgu süresini uzatır.

WP-Optimize veya Advanced Database Cleaner gibi araçlarla düzenli temizlik yapabilirsiniz. Revizyon sayısını sınırlamak için wp-config.php dosyasına şu satırları ekleyebilirsiniz:

define('WP_POST_REVISIONS', 5);
define('AUTOSAVE_INTERVAL', 180); // saniye cinsinden

Bu yöntem özellikle yıllardır kullanılan, çok eklenti kurulup kaldırılmış ve önbelleğe rağmen yavaş hissedilen siteler için uygundur. Ancak temizlik öncesinde mutlaka tam yedek alın.

4. Kalıcı Nesne Önbelleği (Redis/Memcached) Ekleyin

WordPress’in varsayılan nesne önbelleği, istek sona erdiğinde verilerini kaybeder. Redis veya Memcached gibi kalıcı nesne önbellekleri, sık kullanılan veritabanı sorgularını ve seçenekleri RAM üzerinde tutar. Böylece özellikle önbelleğe alınmamış dinamik sayfalarda TTFB belirgin şekilde düşer.

Redis Object Cache gibi bir eklenti, sitenizi sunucudaki Redis hizmetine bağlar. Bu yöntem özellikle WooCommerce sepeti, üyelik sistemi veya çok sayıda oturum açmış kullanıcısı olan siteler için uygundur. Tamamen statik ve sayfa önbelleği kullanan küçük bir blogda getirisi sınırlı kalabilir; kurulumda sunucu desteği gerekir.

5. CDN ile İçerikleri Ziyaretçiye Yaklaştırın

CDN, site içeriklerini dünyanın farklı bölgelerindeki sunucularda kopyalayarak ziyaretçiye en yakın konumdan yanıt verir. TTFB ölçümü kullanıcının bulunduğu konuma göre değiştiği için, sunucunuz Almanya’daysa ve ziyaretçileriniz ABD’deyse aradaki mesafe TTFB’yi yükseltir. Bazı CDN’ler ek yapılandırmayla HTML çıktısını da uç sunucularda önbelleğe alabilir.

Statik dosyaları CDN’den sunmak sayfa yükleme süresini iyileştirir; HTML için ise genellikle edge caching veya full-page cache ayarı gerekir. Bu yöntem özellikle uluslararası ziyaretçisi olan siteler ve yoğun trafik dalgalanmaları yaşayanlar için uygundur. Eksisi, dinamik sayfalarda HTML önbelleğinin dikkatli kurulması gerekmesidir.

6. Hafif Tema ve Az Sayıda Eklenti Kullanın

Çok amaçlı temalar ve sayfa oluşturucular, çok sayıda stil dosyası ve script yüklemenin yanı sıra sunucu tarafında da fazladan PHP işlemi çalıştırır. Her aktif eklenti, WordPress’in istek döngüsüne yeni kancalar ve bazen veritabanı sorguları ekler. Bu yük, özellikle paylaşımlı sunucularda TTFB’ye doğrudan yansır.

Query Monitor eklentisiyle hangi eklenti veya sorgunun yavaşladığını tespit edebilirsiniz. Kullanılmayan eklentileri devre dışı bırakıp hafif bir tema tercih etmek sadece TTFB’yi değil, genel Core Web Vitals değerlerini de iyileştirir. Siteyi yavaşlatan eklentileri tespit etmek için WordPress yavaş eklentiler rehberine bakabilirsiniz. Bu yöntem her site için uygundur; maliyeti, tema değişikliğinin tasarım tarafında ek iş çıkarabilmesidir.

7. WordPress 6.3+ Yerleşik Performans Özelliklerini Değerlendirin

WordPress 6.3, görseller için fetchpriority desteği, iyileştirilmiş lazy loading ve script yükleme stratejileri gibi performans kazanımları getirdi. Sonraki sürümlerde de WordPress performans ekibi iyileştirmelere devam etti. Bu özellikler, ek eklenti kurmadan özellikle görsel ağırlıklı ve blok tema kullanan sayfalarda fark yaratır.

Deneysel özellikleri erken denemek isterseniz WordPress performans ekibinin geliştirdiği Performance Lab eklentisini kullanabilirsiniz. Güncel sürümü kullanmak ve tema/eklenti uyumluluğunu korumak bu yöntemin temel koşuludur. WordPress 6.2.2 sürümündeki performans iyileştirmelerini daha önce ilgili sürüm notu yazımızda incelemiştik. Ayrıntılı gelişmeler için WordPress’in resmi performans blogu takip edilebilir.

TTFB Ölçümü: Değişimi Doğru Takip Edin

Her optimizasyondan önce ve sonra TTFB’yi aynı koşullarda ölçmeniz gerekir. Chrome DevTools’un Network sekmesi, PageSpeed Insights, WebPageTest ve GTmetrix bu konuda yaygın kullanılan araçlardır. WebPageTest, farklı coğrafi konumlardan ölçüm yaparak sunucu konumunun etkisini daha net gösterir.

Tek bir ölçüm yanıltıcı olabilir. Aynı konumdan birkaç ölçüm alıp ortanca değere bakmak daha tutarlıdır. Google’ın web.dev performans belgeleri, sunucu yanıt süresinin nasıl değerlendirildiği konusunda güncel bilgi sunar.

Hangi Yöntemler Size En Çok Kazandırır?

Yedi yöntemin hepsini aynı anda uygulamak yerine ölçüm, uygulama ve yeniden ölçüm döngüsüyle ilerleyin. Önce sayfa önbelleğini açın; çoğu site için en büyük TTFB düşüşü burada gerçekleşir. Ardından PHP sürümünü güncelleyip veritabanını sadeleştirin.

Dinamik sayfalarınız fazlaysa Redis nesne önbelleği, ziyaretçileriniz farklı ülkelerdeyse CDN devreye girmelidir. Tüm bu ayarlara rağmen TTFB yüksek kalıyorsa sunucu kaynakları yetersiz olabilir. Bu durumda daha güçlü bir WordPress hosting paketi değerlendirilebilir.

Sıkça Sorulan Sorular

TTFB için ideal bir değer var mı?

Kesin ve her site için geçerli tek bir sayı yoktur. Google Lighthouse, sunucu yanıt süresini denetler; daha düşük TTFB her zaman daha hızlı ilk içerik oluşumu anlamına gelir. Güncel eşik değerleri için Lighthouse’un resmi belgelerine bakmanız daha sağlıklı olur.

Eklenti satın almadan TTFB düşürülebilir mi?

Evet. Sayfa önbelleği, güncel PHP, OPcache ve veritabanı temizliği gibi adımlar ücretsiz araçlarla ya da doğrudan hosting panelinden yapılabilir. Ücretli eklentiler çoğu zaman bu ayarları tek arayüzde toplar; ancak temel iyileştirmeler için zorunlu değildir.

Sunucu değiştirmeden TTFB düşürülebilir mi?

Genellikle evet. Özellikle önbellekleme, PHP güncellemesi ve veritabanı temizliği aynı sunucu üzerinde büyük fark yaratabilir. Ancak sunucu CPU ve bellek olarak ciddi şekilde yetersizse yazılımsal ayarlar bir yere kadar etki eder.

TTFB düştükten sonra Google sıralaması hemen yükselir mi?

Doğrudan ve anında bir sıralama garantisi yoktur. TTFB’nin düşmesi sayfa deneyimini ve Core Web Vitals değerlerini iyileştirir; bu da dolaylı olarak SEO performansını destekleyebilir. Sıralama, içerik kalitesi ve alaka düzeyi gibi birçok faktörün birlikte değerlendirilmesiyle değişir.

Amacınız temiz ve güvenli bir WAF (Web Application Firewall) kurulumu elde etmek. Yanlış pozitifler, yani normal kullanıcı hareketlerinin saldırı sanılması, e-ticaret sitelerinde sipariş kaybına, web uygulamalarında ise kullanıcı şikayetlerine yol açar. Aşağıda kurulumdan kural dışlama tekniklerine kadar her adımı uygulamalı olarak bulacaksınız.

Ön Koşullar

Başlamadan önce sunucunuzda aşağıdaki bileşenlerin hazır olduğundan emin olun. Eksik bir bileşen varsa kurulum adımları yarıda kalabilir veya yanlış sonuçlar verebilir.

• ModSecurity kurulu ve aktif: Apache için mod_security2, Nginx için libModSecurity veya ModSecurity-nginx modülü gerekir. ModSecurity nedir ve yapılandırması yazısında temel kurulumu bulabilirsiniz.
• OWASP CRS paketi indirilmiş: Kuralların güncel sürümünü resmi GitHub deposundan veya paket yöneticinizden alabilirsiniz. Sürüm numarasını mutlaka resmi kaynaktan kontrol edin.
• Yapılandırma dosyalarına erişim: Sunucu üzerinde root veya sudo yetkisine sahip olmanız gerekir.
• Log okuma aracı: Hata loglarını rahatça inceleyebilmek için terminal erişimi veya bir log görüntüleyici yeterlidir.

Yukarıdaki hazırlıklar tamamsa kuruluma geçebilirsiniz. ModSecurity’nin sürümüne bağlı olarak dosya yolları değişebilir; bu rehberde en yaygın varsayılan yolları kullanacağız.

OWASP CRS Kurulumu

OWASP CRS, ModSecurity’nin işleyeceği kural dosyalarından oluşur. Kurulum süreci, bu kural dosyalarını indirip ModSecurity’ye tanıtmayı kapsar. Paket yöneticiniz CRS paketini sunuyorsa bu adım daha kısa sürecektir.

1. OWASP CRS paketini resmi GitHub deposundan indirin veya paket yöneticinizle kurun. Örneğin git clone komutu ile indirebilir veya dağıtımınızın deposundan apt install modsecurity-crs gibi bir komut çalıştırabilirsiniz.
2. İndirilen klasör içindeki crs-setup.conf.example dosyasını crs-setup.conf olarak kopyalayın. Bu dosya CRS’in çalışma modunu belirleyen ana yapılandırma dosyasıdır.
3. ModSecurity ana yapılandırma dosyanıza Include satırlarını ekleyin. CRS kural dosyalarının sırayla yüklenmesini sağlayan Include direktifleri şu şekilde olabilir:

Include /etc/modsecurity/crs/crs-setup.conf
Include /etc/modsecurity/crs/rules/*.conf

Dosya yollarını kendi sisteminize göre güncelleyin. Doğru Include sıralaması kritik önem taşır: önce crs-setup.conf yüklenmeli, ardından kural dosyaları gelmelidir.

Kurulumu doğrulamak için Apache veya Nginx servisini yeniden başlatın. Hata almadıysanız CRS artık aktiftir. Ancak varsayılan ayarlar çoğu uygulama için oldukça sıkı olabilir; bu yüzden bir sonraki bölümde temel yapılandırmayı ele alıyoruz.

Temel ModSecurity Yapılandırması

OWASP CRS yüklendikten sonra sıra gelen isteklerin nasıl değerlendirileceğini belirlemeye gelir. CRS, anomali skorlama adı verilen bir model kullanır. Her istek çeşitli kurallar tarafından incelenir ve riskli bulunan her hareket için istek bir puan toplar.

Anomali skorlama modelinde iki önemli değer vardır: inbound anomaly score threshold ve paranoia level. Eşik değeri, bir isteğin engellenmesi için toplam skorunun ulaşması gereken seviyeyi belirler. Paranoya seviyesi ise ne kadar şüpheci davranılacağını kontrol eder.

crs-setup.conf dosyasında aşağıdaki ayarları düzenleyebilirsiniz:

SecAction \
  "id:900000,\
   phase:1,\
   nolog,\
   pass,\
   t:none,\
   setvar:tx.blocking_paranoia_level=1,\
   setvar:tx.inbound_anomaly_score_threshold=5,\
   setvar:tx.outbound_anomaly_score_threshold=4"

Bu örnekte paranoia level 1 olarak ayarlanmıştır; bu en az yanlış pozitif üreten, dolayısıyla başlangıç için en uygun seviyedir. Eşik değeri 5, orta düzey bir koruma sağlar. Daha sıkı koruma istiyorsanız paranoia level’ı 2 veya 3’e yükseltebilirsiniz; ancak bu yanlış pozitif riskini artırır.

Önerilen yaklaşım şudur: önce paranoia level 1 ile başlayın, logları izleyin, uygulamanızın normal davranışını öğrenin. Ardından gerekiyorsa kademeli olarak seviyeyi yükseltin. Böylece güvenlik ile kullanılabilirlik arasında sağlıklı bir denge kurarsınız.

Yanlış Pozitifleri Tespit Etme

Yanlış pozitif, normal bir kullanıcının isteğinin saldırı olarak işaretlenmesidir. Örneğin bir kullanıcının adres alanına “select” kelimesini içeren bir sokak adı yazması, SQL enjeksiyon kuralını tetikleyebilir. Bu tür durumları tespit etmek için logları doğru okumak gerekir.

ModSecurity loglarında engellenen her istek için bir ModSecurity: Access denied satırı görürsünüz. Bu satırın hemen üstünde veya altında hangi kuralın tetiklendiğini gösteren bir Matched "Operator ..." against ... ifadesi yer alır. Tetiklenen kuralın ID’sini not edin; örneğin 941160 gibi.

tail -f /var/log/apache2/error.log | grep -i modsecurity

Yukarıdaki komutla canlı log izleyebilirsiniz. Yanlış pozitif olduğunu düşündüğünüz isteği bulduğunuzda, kullanıcının gerçekte ne yaptığını anlamak için REQUEST_URI ve ARGS değerlerine bakın. Kullanıcı masum bir form dolduruyorsa bu bir yanlış pozitiftir.

Test modunda çalışmak da tespiti kolaylaştırır. SecRuleEngine DetectionOnly olarak ayarlandığında ModSecurity yalnızca loglar, istekleri engellemez. Bu sayede kullanıcıları etkilemeden kuralları değerlendirebilirsiniz.

Yanlış Pozitifleri Azaltma Yöntemleri

Yanlış pozitifleri azaltmanın birden çok yolu vardır. Hangi yöntemi seçeceğiniz, tetiklenen kuralın türüne ve etkilenen uygulamanın ihtiyacına bağlıdır. Aşağıda en yaygın ve etkili üç yöntemi uygulamalı olarak anlatıyorum.

1. Kural Dışlama (Rule Exclusion)

Belirli bir kuralın belirli bir sayfa veya parametre için devre dışı bırakılması en hedefli çözümdür. Tüm uygulamayı kuralın dışında bırakmak yerine yalnızca sorunlu bölgeyi istisna tutarsınız.

Örneğin, 941160 numaralı SQL enjeksiyon kuralı, /yorum-ekle sayfasındaki mesaj parametresinde sürekli yanlış tetikleniyorsa şu kural dışlamayı kullanabilirsiniz:

SecRule REQUEST_URI "@beginsWith /yorum-ekle" \
  "id:10001,\
   phase:1,\
   pass,\
   nolog,\
   ctl:ruleRemoveById=941160"

Bu örnek yalnızca /yorum-ekle sayfasına gelen isteklerde 941160 kuralını devre dışı bırakır. Diğer sayfalarda kural çalışmaya devam eder. Böylece güvenlikten ödün vermeden yanlış pozitifi giderirsiniz.

2. Kural Hedefini Güncelleme

Bazen kural doğru çalışıyordur ancak yanlış bir alanı inceliyordur. Örneğin, kural tüm argümanları tararken yalnızca kullanıcı adı alanında sorun çıkarıyordur. SecRuleUpdateTargetById ile kuralın incelediği hedefleri değiştirebilirsiniz.

SecRuleUpdateTargetById 942100 "!ARGS:aciklama"

Bu satır, 942100 numaralı kuralın aciklama parametresini incelemesini engeller. Kural diğer parametreleri taramaya devam eder. Bu yöntem, kuralı tamamen kapatmaktan daha güvenlidir.

3. Anomali Skor Eşiğini Ayarlama

Yanlış pozitifler çok sayıda farklı kuraldan geliyorsa ve her biri küçük puanlar topluyorsa, eşik değerini bir miktar yükseltmek toplu bir rahatlama sağlayabilir. Ancak bu yöntem dikkatli kullanılmalıdır, çünkü gerçek saldırıların da engellenme ihtimalini azaltır.

Varsayılan eşik 5’tir. Bu değeri 8’e yükseltmek, düşük skorlu isteklerin engellenmesini önler. Yine de bu değişikliği yalnızca diğer yöntemler yetersiz kaldığında yapın ve logları yakından izleyin.

Yanlış pozitif azaltma sürecinde en doğru sıra şudur: önce kural dışlama, sonra hedef güncelleme, en son eşik ayarı. Böylece koruma seviyesini mümkün olduğunca yüksek tutarsınız.

Sık Karşılaşılan Sorunlar ve Çözümleri

CRS yapılandırma sürecinde bazı hatalar tekrar tekrar karşımıza çıkar. Bunları baştan bilmek, sorun giderme süresini kısaltır. İşte en sık görülen sorunlar ve pratik çözümleri.

1. Kurallar hiç çalışmıyor: SecRuleEngine değerini kontrol edin. On yerine Off veya DetectionOnly olabilir. Ayrıca Include satırlarının doğru yüklendiğinden emin olun.
2. Çok fazla yanlış pozitif var: Paranoya seviyesini 1’e düşürün ve eşik değerini kontrol edin. Loglarda en çok tetiklenen kural ID’lerini tespit edip hedefli dışlamalar uygulayın.
3. Kural dışlama çalışmıyor: Dışlama kuralının ID’sinin (örneğin 10001) benzersiz olduğundan emin olun. Ayrıca dışlama kuralının, engelleyen kuraldan önce çalıştığından emin olun; faz sırası kritik önemdedir.
4. Loglar çok kalabalık: SecAuditLogParts ayarını düzenleyerek yalnızca gerekli bölümleri loglayın. Gereksiz detayları kapatmak performansı da artırır.
5. Web sunucusu yeniden başlatılamıyor: Büyük olasılıkla yapılandırma dosyasında bir sözdizimi hatası var. apachectl configtest veya Nginx için nginx -t komutuyla hatayı bulun.

Bu sorunlardan herhangi biriyle karşılaşırsanız yapılandırma dosyalarınızı adım adım gözden geçirin. Çoğu hata, basit bir yazım hatası veya eksik Include satırından kaynaklanır.

Sıkça Sorulan Sorular

OWASP CRS ile ModSecurity arasındaki fark nedir?

ModSecurity, istekleri analiz eden motor; OWASP CRS ise bu motora yüklenen kural setidir. ModSecurity tek başına hiçbir isteği engellemez; hangi isteklerin saldırı sayılacağını CRS belirler.

Paranoya seviyesi 4’e çıkarılmalı mı?

Hayır, çoğu uygulama için paranoia level 4 aşırı sıkıdır ve çok sayıda yanlış pozitif üretir. Yalnızca çok yüksek güvenlik gerektiren, kullanıcı etkileşimi az olan sistemlerde tercih edilmelidir.

Yanlış pozitifleri tamamen ortadan kaldırmak mümkün mü?

Bir WAF’ta yanlış pozitifleri tamamen sıfıra indirmek pratikte mümkün değildir. Amaç, yanlış pozitifleri kabul edilebilir bir düzeye çekmek ve meşru kullanıcıların işlemlerini etkilememektir.

Kural dışlamalarını nereye yazmalıyım?

Kendi özel dışlama kurallarınızı ayrı bir dosyada tutmanız önerilir. Bu dosyayı CRS kural dosyalarından sonra Include edin; böylece güncellemelerde özel kurallarınız kaybolmaz.

Hangi Yöntemi Seçmelisiniz?

Doğru yöntem, karşılaştığınız yanlış pozitifin türüne bağlıdır. Tek bir kural tek bir sayfada tetikleniyorsa kural dışlama en temiz çözümdür. Birden çok kural aynı parametreye takılıyorsa hedef güncelleme daha uygun olur. Eşik ayarı ise son çare olarak düşünülmelidir.

OWASP CRS + ModSecurity ikilisi, doğru yapılandırıldığında web uygulamalarınız için güçlü bir güvenlik katmanı oluşturur. Ancak kurulumdan sonra sürekli log izleme ve ince ayar yapma disiplini gerektirir. CRS’in yeni sürümleri çıktıkça kuralları güncellemeyi ve dışlamalarınızı gözden geçirmeyi ihmal etmeyin.

Daha geniş bir güvenlik stratejisi için Mod Security yapılandırması ipuçları yazısını inceleyebilirsiniz. Barındırma tarafında güvenliği önceden sağlanmış bir altyapı arıyorsanız Linux Hosting paketlerimizde ModSecurity ve temel güvenlik önlemleri hazır olarak sunulur.

Doğru hosting seçimi yalnızca kurulumu değil, mağaza hızını, güvenliğini ve ödeme süreçlerinin kesintisiz çalışmasını da etkiler. PHP sürümü, bellek limiti ve web sunucusu ayarları en çok hata veren alanlar arasındadır.

PrestaShop Resmi Minimum Gereksinimler

PrestaShop’un resmi dokümantasyonu, kurulum için gereken minimum PHP ve MySQL sürümlerini açıkça belirtir. Güncel PrestaShop 8.x sürümleri PHP 8.1 ve üzeriyle çalışacak şekilde geliştirilmiştir. Eski PrestaShop 1.7 sürümleri PHP 7.2 ile de kurulabilir ancak güvenlik yamaları ve yeni modüller için güncel PHP sürümü şarttır.

Veritabanı tarafında MySQL 5.6 veya MariaDB desteklenir. Web sunucusu olarak Apache, Nginx ve IIS kullanılabilir. Apache kullanıyorsanız mod_rewrite modülü mutlaka aktif olmalı; Nginx kullanıyorsanız PrestaShop’un dost URL kurallarını sunucu bloğuna eklemeniz gerekir. PrestaShop kurulumu sırasında kök dizine .htaccess dosyası yazabilmeli veya Nginx için uygun izinler tanımlanmalıdır.

Zorunlu PHP eklentileri şunlardır: PDO MySQL, cURL, GD, Intl, Zip, DOM, Fileinfo, MBString, JSON ve OpenSSL. Çoğu güncel hosting panelinde bu eklentiler varsayılan olarak açıktır. Yine de php.ini veya kontrol panelinden doğrulama yapmanızda fayda var. Güncel resmi gereksinim listesini PrestaShop’un sistem gereksinimleri sayfasından kontrol edebilirsiniz.

CPU, RAM ve Disk Planlaması

PrestaShop’un minimum çalışma eşiği düşüktür ancak mağaza büyüdükçe sunucu kaynak ihtiyacı belirgin şekilde artar. Küçük bir mağaza için ilk kurulumda 2 GB RAM ve 10-20 GB NVMe disk çoğu senaryoda yeterli olur. Orta ölçekli bir mağazada 4 GB RAM tercih edilmeli; yoğun trafik alan veya çok sayıda modül kullanan mağazalarda ise 8 GB ve üzeri RAM düşünülmelidir.

Disk alanı en çok göz ardı edilen kaynaktır. PrestaShop her ürün için birden fazla boyutta görsel üretir. Yedekleme dosyaları, geçici dosyalar ve modül paketleri de disk tüketir. 500 ürün altı bir mağazada bile 10 GB altındaki alanlar kısa sürede yetersiz kalabilir. Kaynak planlamasını ürün adedi ve beklenen trafik üzerinden yapmak istiyorsanız e-ticaret sunucu kaynak hesaplama rehberine göz atabilirsiniz.

CPU tarafında ise tek bir güçlü çekirdek performansı, çok sayıda zayıf çekirdekten daha önemlidir. PrestaShop’un önyüzü ve yönetim paneli dinamik PHP işlemlerine dayanır. AMD Ryzen gibi yeni nesil işlemcilere sahip sunucular, e-ticaret iş yüklerinde belirgin hız farkı yaratır.

PHP Yapılandırması ve Zorunlu Eklentiler

PHP ayarları, PrestaShop kurulum hatalarının en sık kaynağıdır. Sunucunuzdaki php.ini dosyasında şu değerleri kontrol etmeniz gerekir:

• memory_limit: en az 256M, önerilen 512M
• max_execution_time: 300 saniye civarı
• max_input_vars: 5000 veya daha fazla
• upload_max_filesize: 16M veya ihtiyaca göre daha yüksek
• post_max_size: upload boyutundan büyük olmalı

Max_input_vars değeri çok sayıda ürün özelliği, kategori ve dil içeren mağazalarda kritik önem taşır. Düşük tutulursa ürün kaydederken form verileri sessizce kesilebilir. OpCache ise PHP kodunun derlenmiş halini bellekte tutarak sayfa üretim süresini düşürür. OpCache.enable=1 ve opcache.memory_consumption=128 veya 256 değerleri başlangıç için uygundur.

Ayarları değiştirdikten sonra PHP-FPM veya Apache servisini yeniden başlatmalısınız. Kontrol paneli kullanıyorsanız bu değerleri panel arayüzünden de yönetebilirsiniz. PrestaShop’u ilk kez kuracaksanız kurulumun tam adımlarını PrestaShop kurulum rehberinde bulabilirsiniz.

MySQL ve Veritabanı Optimizasyonu

PrestaShop veritabanı yoğun bir uygulamadır. Ürünler, kategoriler, müşteriler, siparişler ve istatistikler sürekli olarak veritabanına yazılır. InnoDB depolama motoru kullanılmalı ve sunucuda yeterli miktarda innodb_buffer_pool_size ayrılmalıdır.

Küçük mağazalarda 128-256 MB buffer pool başlangıç için yeterli olabilir. Büyük mağazalarda bu değer, veritabanı boyutunun önemli bir kısmını RAM’de tutacak şekilde artırılmalıdır. Yavaş sorgu loglarını izlemek ve yoğun sorguları optimize etmek mağaza hızını doğrudan iyileştirir. Veritabanında büyük bir işlem yapmadan önce mutlaka yedek alın.

PrestaShop yönetim panelindeki “Gelişmiş Parametreler” bölümünden veritabanı yedekleme ve optimizasyon araçlarına erişebilirsiniz. Büyük mağazalarda harici bir yedekleme planı da oluşturmak gerekir çünkü panel içi yedekler bazen zaman aşımına uğrayabilir.

Apache mi Nginx mi? Web Sunucusu Seçimi

Her iki web sunucusu da PrestaShop’u başarıyla çalıştırabilir. Apache, .htaccess dosyaları sayesinde yönlendirme ve ek kural tanımlamayı basit hale getirir. PrestaShop’un dost URL özelliğini kullanabilmek için mod_rewrite modülü aktif olmalıdır. Paylaşımlı hosting ortamlarında Apache genellikle varsayılan seçenektir.

Nginx ise aynı donanımla daha fazla eşzamanlı istek yönetebilir. Bu avantajı yaşamak için Nginx ile PHP-FPM birlikte kullanılmalıdır. Nginx kullanıyorsanız PrestaShop panelinin “SEO & URL’ler” bölümünden dost URL ayarını açtıktan sonra sunucu bloğuna uygun rewrite kurallarını eklemeniz gerekir. Bu kurallar resmi PrestaShop dokümantasyonunda paylaşılır.

Hangi sunucuyu seçerseniz seçin, yönlendirme kurallarının eksik olması ürün sayfalarında 404 hatalarına neden olur. Kurulumdan hemen sonra birkaç kategori ve ürün sayfasını test etmek bu sorunu erken yakalamanızı sağlar.

Cache, SSL ve Modern Protokol Desteği

PrestaShop performansı büyük ölçüde cache katmanlarına bağlıdır. PHP OpCache mutlaka açık olmalı; ayrıca PrestaShop yönetim panelinden Smarty cache ve tema önbelleği etkinleştirilmelidir. Bu iki katman, dinamik sayfa üretim süresini belirgin şekilde kısaltır. Çok yoğun mağazalarda Redis veya Memcached gibi bir önbellek sistemi de kullanılabilir.

SSL sertifikası artık bir seçenek değil zorunluluktur. Ödeme adımları ve müşteri hesap sayfaları yalnızca HTTPS altında güvenli kabul edilir. Let’s Encrypt gibi ücretsiz sertifika sağlayıcıları bu ihtiyacı maliyetsiz karşılar. Sertifikanın yanında sunucunun HTTP/2 veya HTTP/3 desteklemesi, statik dosyaların daha hızlı yüklenmesini sağlar. HTTP/3 QUIC etkinleştirme rehberi bu konuda adım adım yol gösterir.

Cache ayarlarını yaptıktan sonra mağazanızı farklı bir tarayıcıda veya gizli pencerede test edin. Bazı değişiklikler oturum açmış yönetici hesabında görünmeyebilir.

PrestaShop Hosting Seçerken Nelere Dikkat Etmeli?

Birçok ucuz paylaşımlı hosting paketi PrestaShop’u “çalıştırır” ancak mağaza hızı ve güvenliği için yeterli olmayabilir. Hosting seçerken şu kriterleri değerlendirin:

• PHP bellek limiti ve CPU/IO kısıtlamaları
• Mod_rewrite veya Nginx yönlendirme desteği
• NVMe SSD disk kullanımı
• Otomatik yedekleme ve uptime garantisi
• PrestaShop güncellemeleri için teknik destek

PrestaShop kurulduktan sonra düzenli bakım ve güvenlik güncellemeleri gerekir. Bu işleri manuel yönetmek yerine, PrestaShop’a uygun hazırlanmış bir e-ticaret odaklı hosting paketi iş yükünüzü azaltır. Sunucu kaynağının yetersiz kalması durumunda mağaza yavaşlar ve ödeme adımlarında hatalar artar. Genel e-ticaret altyapısı hakkında daha geniş bir bakış için e-ticaret siteleri için sunucu gereksinimleri yazısını da inceleyebilirsiniz.

Sıkça Sorulan Sorular

PrestaShop için hangi PHP sürümü gerekir?

PrestaShop 8.x için PHP 8.1 veya üzeri önerilir. Eski 1.7 sürümleri PHP 7.2 ile çalışabilir ancak güvenlik ve performans için güncel PHP sürümü kullanmalısınız.

PrestaShop’u paylaşımlı hostingde çalıştırabilir miyim?

Evet, sunucu kaynakları yeterliyse paylaşımlı hostingde çalışabilir. Ancak yoğun trafik ve büyük katalog için VPS veya bulut sunucu daha istikrarlı sonuç verir. Özellikle memory_limit ve CPU kısıtlamalarını kontrol edin.

PrestaShop için kaç GB disk alanı yeterli olur?

Küçük bir mağaza için 10 GB başlangıçta yeterli olabilir. Ürün görselleri, yedekler ve modüller zamanla bu alanı doldurabilir. Mümkünse 20 GB ve üzeri bir plan tercih edin.

PrestaShop kurulumunda en sık hangi hatalar görülür?

En sık “PHP memory_limit yetersiz” ve “intl eklentisi eksik” hataları görülür. PHP eklentilerini ve bellek limitini kontrol ederek çoğu kurulum sorununu çözebilirsiniz.

Hangi Yapılandırma Size Uygun?

PrestaShop’un istediği sunucu koşulları başlangıçta zorlayıcı görünmez. Asıl fark, mağaza trafiği ve ürün sayısı arttıkça ortaya çıkar. Küçük bir katalogla başlıyorsanız güncel PHP, yeterli bellek ve NVMe disk sunan bir hosting planı iyi bir temel oluşturur. Büyük bir katalog veya yüksek trafik hedefliyorsanız, kaynakların kolayca artırılabildiği bir altyapı düşünün.

Sunucu tarafında yapacağınız her iyileştirme, müşteri deneyimini ve dönüşüm oranını doğrudan etkiler. Minimum gereksinimlere değil, mağazanızın büyüme planına göre seçim yapın. Kuruluma başlamadan önce PrestaShop’un resmi gereksinimlerini ve yukarıdaki kontrol listesini eksiksiz tamamladığınızdan emin olun.