Ajanslar İçin WordPress Güncelleme ve Güvenlik Yönetimi Rehberi

Ajanslar Neden Profesyonel Bir WordPress Güncelleme ve Güvenlik Modeline İhtiyaç Duyar?

Bir ajans olarak 5–10 WordPress sitesini elde tutmak nispeten kolaydır. Ancak müşteri sayısı 30’u, 40’ı, 60’ı geçtiğinde işler tamamen operasyon problemine dönüşür: Hangi sitede hangi eklenti versiyonu var, hangisi PHP 7.4’te kalmış, hangi sitede otomatik güncelleme açık, hangi sitede kapalı, son tam yedek ne zaman alındı, kritik güvenlik açığı olan bir eklentiyi kaç sitede kullanıyorsunuz? Bu sorulara dakikalar içinde net yanıt veremiyorsanız, aslında bir WordPress güncelleme ve güvenlik yönetim sorununuz var demektir.

Bu makalede DCHost tarafında ajanslarla çalışırken sahada gördüğümüz gerçek sorunları ve bunlara ürettiğimiz pratik çözümleri toparlayacağız. Amaç; tek tek sitelerle uğraşmak yerine, onlarca WordPress kurulumunu ölçekli, tekrarlanabilir ve izlenebilir bir modelle yönetebilmenizi sağlamak. Envanter yönetimi, güncelleme akışı (staging–yedek–canlı), rol ve yetki tasarımı, güvenlik sertleştirme, yedek–rollback planı ve DCHost üzerinde kurulabilecek örnek bir ajans mimarisini adım adım konuşacağız.

Eğer zaten onlarca WordPress müşteriniz varsa, ya da önümüzdeki 6–12 ay içinde ölçeklenmeyi planlıyorsanız bu yazıyı, ajansınız için standart operasyon prosedürü (SOP) taslağı gibi düşünebilirsiniz.

1. Temel: Envanter ve Standart Olmadan Ölçek Olmaz

1.1. Site Envanteri ve Sınıflandırma

Öncelikle elinizde ne olduğunu bilmeniz gerekiyor. Basit ama çoğu ajansın atladığı adım bu. Bir tablo oluşturun (Google Sheets, Notion, Git repo içi YAML hiç fark etmez) ve her site için en az şu alanları kaydedin:

• Alan adı ve kısa açıklama (kurumsal site, blog, kampanya landing, WooCommerce vb.)
• WordPress çekirdek versiyonu (6.3, 6.4 vb.)
• PHP versiyonu ve hosting tipi (paylaşımlı, reseller, VPS, dedicated)
• Temalar (aktif tema, child theme kullanımı)
• Kritik eklentiler (WooCommerce, üyelik, ödeme, rezervasyon vb.)
• Son büyük çekirdek güncelleme tarihi
• Son tam yedek tarihi ve nerede tutulduğu
• Staging ortamı var mı, yok mu?
• İş kritik seviyesi (A: kritik, B: önemli, C: düşük)

İş kritik seviyesine göre siteleri A/B/C şeklinde sınıflandırmak, birazdan anlatacağımız güncelleme dalgaları ve bakım pencereleri için çok işinize yarayacak.

1.2. Eklenti ve Tema Politikası Olmadan Kaos Bitmez

Ajansların en büyük teknik borcu, müşteriye gelen her istekte rastgele eklenti kurması. Kısa vadede işi çözüyor, uzun vadede ise onlarca sitede farklı eklenti kombinasyonları, uyumsuzluklar ve güvenlik açıkları doğuyor. Bunun yerine:

• Onaylı eklenti listesi oluşturun. Form, cache, SEO, güvenlik, backup vs. her kategori için 1–2 tercih belirleyin.
• Yeni bir eklenti ihtiyacı çıktığında önce bu listeye ekleyin, test edin, sonra üretime alın.
• Uzun süredir güncellenmeyen veya bakım görmeyen eklentileri aşamalı olarak bırakmak için plan yapın.

Aynı mantığı temalar için de uygulayın. Özellikle hazır tema pazarlarından alınan dev temalar (page builder, yüzlerce modül vb.) güncelleme ve güvenlik tarafında ciddi risk getiriyor. Mümkün olduğunca child theme + hafif tema yaklaşımını standart haline getirin.

1.3. PHP ve MySQL Versiyon Stratejisi

Sitenin WordPress çekirdeğini güncel tutarken PHP versiyonunu geride bırakmak da yaygın bir hata. Ajans olarak bir versiyon matrisi belirleyin ve “tüm siteler minimum PHP X, WP Y sürümünde olmalı” gibi hedefler koyun. Bu konuda detaylı bir çerçeveye ihtiyacınız varsa PHP versiyon ve eklenti seçimi rehberimizdeki uyum matrisi sizin için çok faydalı olacaktır.

2. Güvenli Güncelleme Akışı: Staging, Yedek, Canlı

2.1. Staging Ortamı Olmadan Büyük Güncelleme Yapmayın

Özellikle WooCommerce, üyelik ve rezervasyon sistemli sitelerde doğrudan canlıda çekirdek veya büyük eklenti güncellemesi yapmak, ajans–müşteri ilişkisini tek hamlede bozabilecek kadar risklidir. En sağlıklı yaklaşım, her kritik site için bir staging ortamı tanımlamaktır.

Staging’i ister subdomain (staging.marka.com) ister ayrı bir alan adında kurgulayın; önemli olan veri ve dosya senkronizasyonunu kontrol edebilmenizdir. paylaşımlı hosting kullandığınız senaryolarda paylaşımlı hosting’de WordPress staging ortamı kurma rehberimiz size adım adım yol gösterebilir.

2.2. Her Güncelleme Öncesi Otomatik Yedek Zorunlu

Güncelleme sürecini standardize etmek için ajans içinde şu kuralı netleştirin:

• Geri dönebileceğin bir yedeğin yoksa, büyük güncelleme yok.

İdeal akış şu şekilde olabilir:

1. Staging ortamını canlı ile senkronize et (veritabanı + wp-content).
2. Staging üzerinde tam yedek al (dosya + veritabanı, tercihen dış depolamaya).
3. Güncellemeleri staging’de uygula, kritik kullanıcı senaryolarını test et.
4. Her şey yolundaysa canlıda tam yedek al.
5. Canlıda güncellemeyi uygula ve temel smoke testleri yap.

Burada yedek stratejisini yalnızca güncelleme öncesi değil, genel olarak da ele almak önemli. Ayrıntılı bir çerçeve için WordPress yedekleme stratejileri rehberimizi mutlaka incelemenizi öneririz.

2.3. Otomatik ve Manuel Güncelleme Dengesini Kurmak

WordPress çekirdeği ve bazı eklentiler için otomatik güncellemeler faydalı olabilir, ancak ajans tarafında şu prensiple ilerlemek daha güvenli:

• Güvenlik yamaları (minor security releases) mümkünse otomatik.
• Büyük sürüm güncellemeleri (major release) staging üzerinden, manuel onaylı.
• WooCommerce, ödeme gateway’leri, üyelik, rezervasyon gibi kritik eklentiler daima manuel ve staging’de test edilerek.

wp-config.php içinde çekirdek otomatik güncelleme davranışını kod seviyesinde kontrol edebilirsiniz; ancak kritik olan, ajans içinde hangi site tipinde hangi politikanın uygulanacağını net yazılı hale getirmek.

2.4. WooCommerce ve Yüksek Trafikli Siteler İçin Özel Akış

WooCommerce mağazalarında güncelleme, SEO odaklı bir blog sitesine göre çok daha risklidir: stok, sipariş, ödeme, kupon, kargo entegrasyonları, muhasebe API’leri vb. devrededir. Bu tip siteler için şu ek önlemleri almanızı öneririz:

• Bakım penceresini, sitenin en düşük trafik aldığı saatlerde planlayın.
• Canlıda bakım sayfası açmadan önce, staging’de tam sipariş akışını (sepete ekleme, ödeme, e-posta bildirimi) test edin.
• Güncelleme sonrası en az 24 saat boyunca log’ları ve hata bildirimlerini yakından izleyin.

WooCommerce özelinde güncelleme öncesi dikkat etmeniz gereken noktalar için ayrıca WooCommerce güncellemelerini güvenle yapmak rehberimizi de sürecinize dahil edebilirsiniz.

3. Onlarca WordPress Sitesi İçin Ölçeklenebilir Operasyon Modeli

3.1. Reseller mı, VPS mi? Ajans Tarafında Doğru Zemin

Güncelleme ve güvenliği ölçekli yönetmenin ilk adımı, altyapıyı da ölçeklenebilir kurmaktır. 20–30 siteye kadar iyi tasarlanmış bir reseller hosting yapısı çoğu küçük ajans için yeterli olabilir. Ancak CPU, RAM, disk IO ve network tarafında daha sıkı kontrol ihtiyacınız varsa, ajans tarafında tek bir güçlü VPS veya birkaç VPS ile kendi çok kiracılı yapınızı kurmak daha sağlıklı olacaktır.

Bu kararı verirken ajansların en sık sorduğu soruları ve tipik senaryoları ajanslar için reseller hosting mi VPS mi rehberimizde detaylıca ele aldık. Daha ileri ölçekte, 20+ WordPress sitesini tek altyapıda taşıyan ajanslar için ise 20+ WordPress sitesini tek altyapıda yönetme makalesindeki örnek mimariler size iyi bir çerçeve sunacaktır.

3.2. WP-CLI ile Toplu Güncelleme ve Rutine Bağlama

VPS veya dedicated sunucu üzerinde çoklu WordPress kurulumunuz varsa, WP-CLI kullanmak işleri dramatik şekilde hızlandırır. Basit bir betikle:

• Belirli bir dizin altındaki tüm WordPress kurulumlarını bulabilir,
• Her biri için çekirdek, eklenti ve tema güncellemelerini sırayla çalıştırabilir,
• Her sitenin güncelleme özetini log dosyasına yazabilirsiniz.

Burada kritik nokta, skriptin körlemesine çalışmaması. Örneğin:

• Sadece staging kurulumlarında otomatik güncelleme, canlıda manuel tetikleme,
• Kritik eklentileri (örn. WooCommerce) exclude edip ayrı akışla yönetme,
• Güncelleme öncesi otomatik yedek tetikleyen hook’lar.

Bunların hepsi bir bash script + WP-CLI kombinasyonuyla mümkün. Önemli olan, ajans içinde bir “,update-playbook.sh” standardınızın olması ve herkesin bunu kullanması.

3.3. Git Tabanlı Akışlar ve CI/CD

Biraz daha olgun ajanslarda WordPress projeleri Git repoları üzerinden yönetiliyor. Özellikle custom tema ve özel eklentiler geliştiriyorsanız, Git tabanlı akış neredeyse zorunlu hale geliyor. Bu durumda:

• Kod (tema, özel eklentiler, muhtemelen muhtasar wp-config) repoda tutulur.
• Medya dosyaları ve müşteri içeriği prod üzerinde kalır.
• Güncelleme süreci, önce staging ortamına otomatik deploy (Git push → CI → staging), testler, ardından üretim deploy şeklinde işler.

Bu yapıyı DCHost üzerindeki VPS’lerde rahatlıkla kurabilirsiniz. İsterseniz panel üzerinden, isterseniz tamamen SSH ve Git ile ilerleyebilirsiniz. Git ile WordPress ve PHP sitelerini otomatik deploy etme rehberimiz bu konuda iyi bir başlangıç noktası sunuyor.

3.4. Ajans İçin Bakım Takvimi ve Güncelleme Dalgaları

Rastgele güncelleme yapmak yerine, bunu aylık veya iki haftalık bakım pencerelerine bağlamak, hem iç operasyonu hem de müşteri iletişimini rahatlatır. Örnek bir model:

• Hafta 1: Geliştirme ortamı ve staging sitelerde güncellemeler + testler.
• Hafta 2: C seviyesi (düşük kritik) sitelerde canlı güncellemeler.
• Hafta 3: B seviyesi (önemli) sitelerde canlı güncellemeler.
• Hafta 4: A seviyesi (kritik) sitelerde, sıkı bakım pencereleriyle güncelleme.

Bu sayede aynı problemi tüm müşteri portföyünüzde aynı anda yaşamaz, olası sorunları daha dar bir grupta görüp diğer dalgalara geçmeden çözme şansı bulursunuz.

4. Güvenlik Yönetimi: Katmanlı Savunma Olmadan Güncelleme Yetmez

4.1. Sunucu ve Panel Tarafı Sertleştirme

WordPress çekirdeğini güncellemek tek başına güvenlik demek değildir. Altındaki sunucu ve kontrol paneli zayıfsa, güncel bir WordPress bile kolay hedef haline gelebilir. Ajans olarak şu adımları standartlaştırmanızı öneririz:

• cPanel veya benzeri panel kullanıyorsanız; 2FA, IP kısıtlama ve yetki yönetimi için cPanel hesap güvenliği sertleştirme rehberindeki adımları uygulayın.
• VPS kullanıyorsanız; sshd_config, firewall, fail2ban gibi temel sertleştirme adımlarını, VPS güvenlik kontrol listemizde anlattığımız şekilde kurun.
• HTTP güvenlik başlıkları (HSTS, CSP, X-Frame-Options vb.) için, HTTP güvenlik başlıkları rehberimizdeki ayarları ajans standardı haline getirin.

4.2. WordPress İçinde Güvenlik Sertleştirme

Güncel bir WordPress çekirdeği üzerine şu adımları da eklemeniz gerekir:

• Giriş URL’sini gizlemekle yetinmeyin; 2FA, IP kısıtlama, reCAPTCHA ve XML-RPC korumasını WordPress güvenli giriş mimarisi rehberindeki pratiklerle tamamlayın.
• Dosya izinlerini, salt keys, wp-config.php sertleştirme ve XML-RPC yapılandırmalarını ajans genelinde standartlaştırın. Bunun için WordPress güvenlik sertleştirme kontrol listemizi doğrudan SOP’nize kopyalayabilirsiniz.
• Tüm müşterilerde asgari bir WAF ve brute-force korumasını zorunlu hale getirin (panel WAF’i, sunucu WAF’i veya CDN WAF’i olabilir).

4.3. Eklenti Kaynakları ve Lisans Yönetimi

Null (kırılmış) tema ve eklentiler, ajans tarafında gördüğümüz en tehlikeli pratiklerden biri. Sadece güvenlik açığı değil, bilerek eklenmiş backdoor ve spam linkleri de beraberinde getiriyor. Ajansın iç politikasında şunu netleştirin:

• Null tema/eklenti kesinlikle yasak.
• Müşteri lisansları merkezi bir yerde takip edilir (lisans anahtarları, süre bitiş tarihleri).
• Lisans süresi dolan eklenti/tema için proaktif uyarı ve aksiyon planı vardır.

4.4. İzleme, Uyarı ve Güvenlik Olayı Yönetimi

Güncelleme ve güvenlik yönetimini ölçekli hale getirmenin bir ayağı da izleme ve alarm sistemidir. Temel olarak:

• Uptime ve SSL bitiş tarihlerini merkezi izlemeniz,
• Alan adı süresi, DNS değişikliği ve nameserver değişiklikleri için alarm kurmanız,
• Temel WordPress güvenlik olaylarını (çoklu başarısız login, şüpheli dosya değişiklikleri vb.) toplayıp bildirim almanız gerekir.

Bu konuda ajanslara özel olarak hazırladığımız müşteri sitelerini izleme ve alarm mimarisi rehberini altyapınızın ayrılmaz bir parçası haline getirmenizi öneririz.

5. Yedekleme, Rollback ve Felaket Senaryolarına Hazırlık

5.1. 3-2-1 Yedekleme Kuralını Ajans Standardı Yapmak

Onlarca WordPress sitesi yöneten bir ajans için “yedek var mı?” sorusu “evet” veya “hayır” ile bitmemeli. Soru şu olmalı: Kaç kopya, nerede, ne kadar geriye gidebiliyoruz ve geri dönüş testleri yapıldı mı? Sağlıklı bir modelde:

• En az 3 kopya (canlı + farklı disk + uzak lokasyon),
• En az 2 farklı medya (örneğin NVMe disk + object storage),
• En az 1 kopya farklı veri merkezinde veya hesapta tutulur.

Bu 3-2-1 modelini hem panel yedekleri hem de VPS düzeyinde kendi otomasyonlarınızla kurabilirsiniz. Detaylı strateji ve maliyet dengesi için 3-2-1 yedekleme stratejisi rehberimizi ajans planlamanıza dahil etmenizi öneririz.

5.2. Rollback Planı Olmadan Güncelleme Yapmış Sayılmazsınız

Güncelleme sonrası sorun çıktığında “yedek var” demek yetmez; nasıl döneceğinizi de net bilmelisiniz. Ajans içinde şu soruların cevabı yazılı olsun:

• Rollback’i kim, hangi yetkilerle yapacak?
• DNS veya CDN tarafında bir değişiklik gerekiyorsa kim devreye girecek?
• Müşteriye ne kadar sürede “sorun tespit edildi, geri alıyoruz” bilgisini ileteceksiniz?

Bu planı önceden yazmak, özellikle yüksek cirolu müşterilerde kriz anında ajansı korur. Felaket kurtarma tarafında daha kapsamlı bir bakış açısına ihtiyacınız varsa, felaket kurtarma planı rehberimiz iyi bir temel sunar.

5.3. Yedekten Geri Dönüş Testi Yapmadan Kendinize Güvenmeyin

Çok yaygın bir sahne: Yıllardır “yedek alıyoruz” denen sistemde, ilk ciddi sorunda yedeklerin ya bozuk olduğu ya da eksik dosya içerdiği ortaya çıkıyor. Ajans tarafında her çeyrekte en az 1–2 gerçek geri yükleme testi yapmanızı öneririz:

• Rastgele 1–2 site seçin.
• Yedekten staging veya test alanına tam geri yükleme yapın.
• Siteyi gezerek, formları doldurarak, giriş yaparak çalıştığını doğrulayın.

Bu testler, script’lerdeki hataları, eksik cron’ları ve depolama limitlerini daha problem olmadan yakalamanızı sağlar.

6. Ajans Operasyonunda Roller, Yetkiler ve Dokümantasyon

6.1. Kim, Ne Zaman, Neyi Güncelleme Yetkisine Sahip?

Tek kişilik freelance dönemi geride kaldığında, ajans içi rol ve yetki yönetimi kritik hale gelir. Önerilen yapı:

• Teknik lider / DevOps: Güncelleme stratejisini belirler, script’leri ve otomasyonları yazar.
• Uygulama geliştiriciler: Tema / eklenti kod değişikliklerini yapar, staging testlerinden sorumludur.
• Destek ekibi: Basit güvenlik güncellemeleri, küçük eklenti güncellemeleri ve izleme uyarılarına ilk müdahaleyi yapar.

Canlı ortamda büyük güncellemeleri herkesin yapmasına izin vermek yerine, belirli bir çekirdekle sınırlamak uzun vadede ajansı pek çok hatadan korur.

6.2. Müşteri İletişimi ve SLA’ler

Ajans tarafında işleri profesyonelleştirmenin en görünür adımı, müşteriye açık ve yazılı bir bakım/güvenlik paketi sunmaktır. Örneğin:

• Aylık çekirdek/eklenti güncelleme pencereleri,
• Güvenlik yamalarına maksimum reaksiyon süresi (ör. kritik açıkta 48 saat içinde yama),
• Yedek saklama süresi ve geri yükleme SLA’sı.

Bunu sadece satış dokümanı olarak değil, iç operasyonun da üzerinde yürüyeceği bir zemin olarak düşünün.

6.3. Yazılı Prosedürler (SOP) Olmadan İşler Kişiye Bağımlı Kalır

Bu makaledeki başlıkları ajansınız için birer SOP (Standard Operating Procedure) haline getirin:

• “WordPress çekirdek ve eklenti güncelleme prosedürü”,
• “WooCommerce siteleri için özel güncelleme prosedürü”,
• “Güvenlik olayı (hack, malware) yönetim prosedürü”,
• “Yedekten geri dönüş prosedürü”.

Her yeni ekip üyesi bu dokümanlarla işe başlarsa, güncelleme ve güvenlik yönetimi kişiye değil, ajansın sistemine bağlı hale gelir.

7. DCHost Üzerinde Ajanslar İçin Örnek WordPress Mimarisi

DCHost olarak ajanslarla çalışırken sık önerdiğimiz, pratik bir örnek yapıdan da bahsedelim. Elbette her ajansın ihtiyaçları farklı, ama şu model çoğunlukla iyi çalışıyor:

• 1 adet performanslı VPS: NVMe disk, yeterli vCPU ve RAM ile ajansa özel WordPress barındırma platformu.
• Panel + reseller yapısı: Müşteri başına ayrı hesap açarak güvenlik ve kaynak izolasyonu sağlamak.
• Merkezi WP-CLI ve backup script’leri: Tüm siteleri tek yerden görmek, güncellemek ve yedeklemek.
• İzleme ve alarm entegrasyonları: Uptime, SSL, alan adı süresi ve kaynak kullanımı için merkezi izleme.

Daha büyük ajanslarda buna ek olarak, staging için ayrı bir VPS, yoğun WooCommerce siteleri için ayrı bir veritabanı sunucusu veya nesne önbellek (Redis) sunucusu gibi katmanlar da ekliyoruz. Yani hedef; ajansın satış ve geliştirme ekipleri müşteriye odaklanırken, WordPress güncelleme ve güvenlik süreçlerinin standart ve tekrarlanabilir bir altyapı üzerinde akması.

8. Sonuç: Ajansınız İçin Yol Haritası

Onlarca WordPress sitesini uzun vadede sağlıklı yönetmenin yolu, tek tek sitelerle boğuşmaktan değil, güncelleme ve güvenliği bir operasyon problemi olarak görüp sistem kurmaktan geçiyor. Envanter çıkarma, eklenti/tema politikası, staging–yedek–canlı akışı, WP-CLI ve Git ile otomasyon, katmanlı güvenlik, 3-2-1 yedekleme ve net dokümantasyon adımlarını tamamladığınızda; “Şu eklentide kritik açık çıktı, bizde kaç sitede var?” sorusunun yanıtı dakikalar içinde elinizde olur.

DCHost tarafında amacımız, ajansların bu yolculuğu tek başına, deneme–yanılmayla yaşamasını engellemek. Yeni bir ajans altyapısı kuruyor, mevcut yapınızı VPS’e taşımayı planlıyor ya da sadece WordPress güncelleme ve güvenlik süreçlerinizi standardize etmek istiyorsanız, sizinle teknik detay konuşmaktan memnuniyet duyarız. İhtiyaçlarınızı birlikte analiz edip, ajansınıza özel, sürdürülebilir bir WordPress güncelleme ve güvenlik yönetimi mimarisi tasarlayabiliriz.