Birden Fazla Web Sitesini Tek Panelden Yönetmek

Üç site yönetirken her birine ayrı ayrı giriş yapmak can sıkıcıdır; otuz site yönetirken bu, işin kendisini yiyen bir yüke dönüşür. Tek panelden yönetim, bu yükü tek bir ekrana, tek bir takvime ve tek bir kontrol listesine indirmenin adıdır. Bu yazıda neyin merkezileştirilebileceğini, hangi yaklaşımların olduğunu, nereden başlanacağını ve sık yapılan hataları ele alıyoruz.

Tek panelden yönetim tam olarak ne demek?

"Tek panel" kavramı çoğu zaman yanlış anlaşılır. Bütün sitelerin aynı sunucuda olması ya da aynı yazılımla kurulmuş olması gerekmez. Asıl kastedilen, sitelerin durumunu görmek ve tekrarlayan işleri yapmak için her birine ayrı ayrı girmek zorunda kalmamaktır. Bir panel en az şu soruları tek bakışta yanıtlayabilmelidir:

• Hangi sitelerde bekleyen eklenti, tema veya çekirdek güncellemesi var?
• Son yedek ne zaman alındı ve yedek başarılı mı?
• Şu anda erişilemeyen ya da yavaşlayan bir site var mı?
• SSL sertifikası ya da alan adı süresi dolmak üzere olan site hangisi?
• Hangi sitede beklenmedik bir yönetici hesabı, değişmiş bir dosya ya da güvenlik uyarısı var?

Bu soruların cevabını tek ekranda gördüğünüzde, iş "her siteyi tek tek kontrol etmek" olmaktan çıkar, "sadece sorunlu olanlara bakmak" haline gelir. Verimlilik kazancının büyük kısmı buradan gelir: dikkatinizi tüm sitelere eşit dağıtmak yerine, yalnızca istisnalara yöneltirsiniz.

Neler merkezileştirilebilir, neler merkezileştirilmemeli?

Her işi tek panele toplamak cazip görünür, ama bazı işler sitenin kendi bağlamında yapılmayı hak eder. Aşağıdaki tablo pratikte iyi işleyen bir ayrımı gösteriyor:

Genel kural şudur: tekrarlı, ölçülebilir ve geri alınabilir işler merkezileştirilir; yaratıcı ve bağlama bağlı işler sitenin kendisinde kalır.

Dört temel yaklaşım

1. Hazır çoklu site yönetim araçları

WordPress ekosisteminde bu iş için olgunlaşmış araçlar vardır. MainWP kendi sunucunuza kurduğunuz, açık kaynaklı bir "kontrol sitesi" mantığıyla çalışır; yönettiğiniz her siteye küçük bir bağlantı eklentisi (child) kurulur. ManageWP ve InfiniteWP gibi alternatifler de benzer bir modeli bulut veya kendi barındırma seçenekleriyle sunar. Bu araçların ortak gücü; toplu güncelleme, yedekleme, uptime kontrolü ve güvenlik taramasını tek arayüzde toplamalarıdır.

Zayıf yanları ise bağımlılıktır: panel aracının kendisi bir tek hata noktası olur ve yalnızca WordPress siteleri için tasarlanmışlardır. Statik siteleriniz, özel yazılımlarınız veya farklı bir CMS ile kurulmuş siteleriniz varsa bu araçlar resmin sadece bir kısmını gösterir.

2. Sunucu paneli seviyesinde yönetim

cPanel/WHM, Plesk veya benzeri sunucu panelleri, aynı sunucudaki birçok siteyi hesap bazında yönetmenizi sağlar. Alan adı, e-posta, veritabanı, SSL ve sunucu tarafı yedekleme buradan yapılabilir. Uygulama katmanında (örneğin bir eklentinin güncel olup olmadığı) ise sınırlı görünürlük sunarlar. Bazı paneller WordPress için ek araç setleri sunsa da çoğu senaryoda sunucu paneli ile uygulama paneli birbirini tamamlar, birbirinin yerine geçmez.

3. Komut satırı ve betikler

Teknik ekipler için en esnek yol, WP-CLI gibi komut satırı araçlarını SSH üzerinden betiklerle çalıştırmaktır. Örneğin bir döngüyle tüm sitelerde bekleyen eklenti güncellemelerini listelemek birkaç satırlık bir iştir:

for site in /var/www/*/; do
  echo "== $site"
  wp plugin list --update=available --path="$site" --fields=name,version,update_version
done

Bu yöntem ücretsizdir, şeffaftır ve her adımı kontrol etmenizi sağlar. Bedeli ise bakım yüküdür: betikleri yazmak, hata durumlarını yönetmek ve sonuçları okunabilir bir rapora dönüştürmek size kalır.

4. Kendi paneliniz

Belirli bir noktadan sonra bazı ekipler, kendi iş akışlarına göre şekillenmiş bir iç panel kurar. Bu panel genellikle farklı kaynaklardan (uptime servisi, yedekleme hedefi, sunucu metrikleri, analiz araçları) veri toplar ve tek bir tabloda gösterir. Her şeyi sıfırdan yazmak gerekmez; çoğu zaman mevcut araçların API'lerini bir araya getiren ince bir katman yeterlidir. Bu yaklaşım, özellikle farklı teknolojilerle kurulmuş sitelerin bir arada yönetildiği durumlarda anlamlıdır.

Bir yaklaşım seçmek için karşılaştırma

Çoğu küçük ekip için en mantıklı başlangıç, hazır bir çoklu site aracı ile dışarıdan çalışan bir uptime servisini birleştirmektir. Site sayısı ve çeşitlilik arttıkça betikler eklenir; kendi panel ihtiyacı ise genellikle ancak süreçler oturduktan sonra ortaya çıkar.

Adım adım kurulum planı

1. Envanter çıkarın. Her site için alan adı, barındırma yeri, CMS ve sürümü, yönetici hesapları, alan adı ve SSL bitiş tarihleri, sorumlu kişi ve müşteri bilgisi tek bir tabloda toplansın. Envanteri olmayan bir panel, neyi kaçırdığınızı söyleyemez.
2. Siteleri risk grubuna ayırın. E-ticaret ve form alan siteler "kritik", kurumsal tanıtım siteleri "standart", arşiv niteliğindekiler "düşük" gibi. Güncelleme ve yedekleme sıklığını bu gruplara göre belirleyin.
3. İzlemeyi önce kurun. Herhangi bir otomasyondan önce, sitelerin ayakta olup olmadığını dışarıdan gören bir izleme kurun. Böylece sonraki adımlarda bir şey bozulursa ilk siz fark edersiniz. Ayrıntılar için uptime izleme rehberine bakabilirsiniz.
4. Yedeklemeyi doğrulayın. Toplu güncellemeye geçmeden önce her sitenin güncel ve geri yüklenebilir bir yedeği olduğundan emin olun. Yedekleme ve güvenlik yazımız bu adımı detaylandırıyor.
5. Güncellemeleri gruplar halinde yapın. Önce düşük riskli birkaç sitede deneyin, sorun yoksa diğerlerine geçin.
6. Haftalık özet rapor oluşturun. Panel ne kadar iyi olursa olsun, haftada bir kez "neler değişti, neler bekliyor" özetine bakmak, gözden kaçan işleri yakalar.

Panelde mutlaka görmeniz gereken göstergeler

Bir panelin değerini, gösterdiği veri miktarı değil, sizi harekete geçiren uyarıların doğruluğu belirler. Aşağıdaki göstergeler, sitelerin çoğu için yeterli bir başlangıç setidir:

• Erişilebilirlik: son 24 saat ve son 30 gün içindeki kesintiler.
• Yanıt süresi eğilimi: tek bir ölçüm değil, haftalık eğilim. Yavaşça artan yanıt süresi genellikle büyüyen bir veritabanına veya şişen bir eklentiye işaret eder.
• Bekleyen güncelleme sayısı: özellikle güvenlik yaması içeren güncellemeler ayrıca işaretlenmeli.
• Son başarılı yedek tarihi: "yedek alınıyor" değil, "en son ne zaman başarıyla alındı".
• Sertifika ve alan adı bitiş tarihleri: 30 gün kala uyarı vermesi iyi bir pratiktir.
• Disk kullanımı: dolmak üzere olan bir disk, hem yedeklerin hem veritabanının sessizce bozulmasına yol açabilir.

Güvenlik: tek panel, tek anahtar demektir

Tüm sitelere erişebilen bir panel, saldırgan için de en değerli hedeftir. Bu yüzden panelin kendisi, yönettiği sitelerden daha sıkı korunmalıdır:

• Panel girişinde iki aşamalı doğrulama zorunlu olsun.
• Mümkünse panele yalnızca belirli IP adreslerinden veya bir VPN üzerinden erişilsin.
• Her ekip üyesinin kendi hesabı olsun; ortak şifre kullanılmasın. Kim neyi değiştirdi, kayıt altında olsun.
• Panelin sitelere bağlanmak için kullandığı anahtarlar ve parolalar düz metin dosyalarda değil, bir parola yöneticisinde veya gizli bilgi kasasında tutulsun.
• Panel aracının kendisi de güncel tutulsun; çoğu zaman en çok unutulan güncelleme, panelin kendi güncellemesidir.

Sık yapılan hatalar

Her şeyi otomatik güncellemeye açmak. Otomatik güncelleme küçük yamalar için harikadır, ama büyük sürüm geçişleri (örneğin bir sayfa oluşturucunun ana sürümü) bir siteyi görsel olarak bozabilir. Büyük sürümler için önce test edip sonra yaymak daha güvenlidir. Bu konuyu WordPress bakım otomasyonu yazısında ayrıca işledik.

Uyarı yorgunluğu. Her küçük olay için bildirim gönderen bir panel bir süre sonra görmezden gelinir. Uyarıları önem derecesine göre ayırın: kesinti ve başarısız yedek anında, bekleyen güncellemeler günlük özet olarak gelsin.

Envanterin güncel tutulmaması. Siteler eklenir, taşınır, kapatılır; envanter güncellenmezse panel olmayan siteleri izler, var olanları kaçırır.

Tek kişiye bağımlılık. Paneli yalnızca bir kişi biliyorsa, o kişi izindeyken yaşanan bir kesinti büyür. Kısa bir çalışma kılavuzu yazmak bu riski büyük ölçüde azaltır.

İçerik ve SEO tarafı da aynı mantıkla yönetilebilir

Teknik bakım merkezileştiğinde, sıradaki darboğaz genellikle içerik ve arama görünürlüğüdür. Çok sayıda sitenin teknik SEO hatalarını, sıralama değişimlerini ve içerik takvimini site site takip etmek, güncellemeleri tek tek yapmak kadar yorucudur. Bu tarafı otomatikleştirmek isteyenler için DexterGPT gibi siteyi tarayıp teknik hataları düzelten, makale üretip WordPress'e yayınlayan ve sıralamaları günlük takip eden araçlar, teknik paneli tamamlayan bir katman olarak düşünülebilir. Burada da aynı ilke geçerlidir: otomasyon işi hızlandırır, ama yayına çıkan her içeriğin bir insan tarafından gözden geçirilmesi gerekir. Bu dengeyi yapay zekâ ile içerik üretimi yazımızda ayrıntılı anlattık.

Sonuç

Tek panelden yönetim, bir araç seçmekten çok bir çalışma düzeni kurmaktır. Envanter, izleme, yedek, kademeli güncelleme ve haftalık özet; bu beş parça yerine oturduğunda hangi aracı kullandığınız ikincil hale gelir. Küçük başlayın, önce görünürlüğü sağlayın, sonra otomasyonu adım adım ekleyin.

Sık sorulan sorular

Kaç siteden sonra tek panele geçmek mantıklı?

Kesin bir eşik yok, ama genellikle beş-altı siteden sonra her birine ayrı giriş yapmak zaman kaybı olarak hissedilmeye başlar. Site sayısından bağımsız olarak, müşterilerinize bakım taahhüdü veriyorsanız merkezi izleme baştan kurulmalıdır.

Farklı CMS'lerle kurulmuş siteler aynı panelde yönetilebilir mi?

Uptime, SSL, alan adı ve yedek durumu gibi altyapı göstergeleri CMS'den bağımsızdır ve tek panelde izlenebilir. Güncelleme gibi uygulama katmanı işleri ise her CMS için ayrı araç veya betik gerektirir.

Panel aracı çökerse siteler etkilenir mi?

İyi tasarlanmış bir yapıda hayır. Panel sitelere bağlanan bir yönetim katmanıdır; siteler kendi başına çalışmaya devam eder. Yine de panel çalışmadığı sürede izleme ve otomatik işler duracağı için, panelin kendisi de izlenmelidir.

İlgili rehberler

• BakımWordPress Bakım ve Güncelleme Otomasyonu Rehberi
• İzlemeUptime İzleme Rehberi ve Kesinti Uyarıları
• AjansAjans ve Freelancer İçin Müşteri Sitelerini Yönetmek