WordPress bakım planında neler olmalı? Kapsam rehberi

WordPress bakım planı, güncelleme yapılacak bileşenlerin, alınacak yedeklerin, geri dönüş yönteminin, çalışması kontrol edilecek işlemlerin ve sorumlu kişilerin birlikte tanımlandığı hizmet kapsamıdır. Yalnız eklenti listesindeki güncelleme düğmesine basmak, çalışan bir bakım sürecinin tamamı değildir. Plan, sitenin müşteri talebi veya sipariş alma işlevini sürdürebilmesini hedefleyen somut kontroller içermelidir.

Kurumsal bir tanıtım sitesiyle sürekli sipariş alan WooCommerce mağazasının veri kaybı toleransı ve çalışma koşulları aynı olmayabilir. Bu nedenle her siteye aynı sıklık ve aynı teslim listesi uygulanmaz. Aşağıdaki tablolar örnek kapsam ve kontrol önerileridir; belirli bir müşteri sözleşmesi, kesintisizlik garantisi veya bütün güvenlik sorunlarını engelleyecek bir paket olarak sunulmaz.

İlk adım: Bakımı yapılacak sistemi envantere alın

Alan adı, barındırma, DNS, e-posta, WordPress yönetimi, tema, eklentiler ve dış servisler aynı kişinin kontrolünde olmayabilir. Önce hangi bileşenin nerede yönetildiğini belirleyin. Sitenin kimin adına kayıtlı olduğu ile ajansın çalışma erişimini ayırın. İşletmenin kendi hesaplarına ulaşamaması, sıradan bir içerik değişikliğinde bile gereksiz bağımlılık yaratabilir. Bakım hizmeti bu sahipliği belirsiz bırakmamalıdır.

Envanterde kullanılan bileşenin adı kadar işlevi de yer almalı. Bir eklenti iletişim formu, bir başkası ödeme veya önbellek için kullanılıyor olabilir. Listeyi yalnız sürüm numaralarından oluşturmak, bir değişiklik sonrasında hangi müşteri işleminin etkilenebileceğini göstermez. Bileşen, görev, lisans sorumlusu ve kritik bağlantılar aynı kayıtta tutulduğunda planın kapsamını değerlendirmek kolaylaşır. Gereksiz bileşenler de bu incelemede görünür hale gelebilir.

Envanter kalemi	Sorulacak soru	Kayda geçirilecek bilgi
Alan adı ve DNS	Yenilemeyi ve kayıtları kim yönetiyor?	İşletme sahibi, sağlayıcı, sorumlu
Barındırma	Hangi ortam ve kaynaklar kullanılıyor?	Sağlayıcı, destek yolu, ortamlar
WordPress ve bileşenler	Hangi parça hangi işlevi sağlıyor?	Görev, sürüm, bağımlılık, lisans
İş akışları	Hangi işlemin çalışması kritik?	Form, sipariş, arama veya üyelik
Yedek ve kurtarma	Nasıl geri dönülecek?	Kapsam, saklama, erişim, deneme

Yedek dosyası bulunmasıyla geri yükleme hazırlığı farklıdır

Bir panelde “yedek alındı” yazması, sitenin ihtiyaç duyulduğunda eksiksiz geri getirilebildiğini tek başına göstermez. Hangi dosyaların ve hangi veritabanının bulunduğu, yedeğin ne zaman alındığı, nerede saklandığı ve kimin erişebildiği bilinmelidir. Sitenin içeriği, yüklenen görselleri ve yapılandırması farklı kaynaklarda bulunabilir. Yedek kapsamını yalnız tek bir klasör adına bakarak tamamlanmış saymayın.

WordPress’in resmî yedekleme belgesi, sitenin dosyaları ile veritabanını birlikte ele alır ve güncelleme öncesinde yedeklemeyi vurgular. Sıklık, sitedeki değişim miktarına göre belirlenmelidir. Bu rehberdeki bakım planı için önemli olan, yedeğin geri dönüşte kullanılabilecek kapsamda bulunması ve kurtarma adımlarının yalnız bir kişinin hafızasında kalmamasıdır.

Yedeğin tutulduğu yerle asıl sitenin çalıştığı ortamın aynı sorunlardan etkilenip etkilenmeyeceğini değerlendirin. Sadece aynı sunucudaki bir kopyaya dayanmak, bazı arıza türlerinde yeterli olmayabilir. Buna karşılık yedekleri kontrolsüz biçimde birçok kişisel hesaba dağıtmak da doğru bir kayıt düzeni oluşturmaz. Saklama yeri, erişim yetkisi, süre ve eski kopyaların yönetimi bakım kapsamında açıkça tanımlanmalıdır. Gereksiz müşteri verisini farklı ortamlara kopyalamayın.

Veri kaybı ve geri dönüş beklentisini işletmeyle konuşun

Bir günlük içerik kaybı kurumsal bir sitede yeniden hazırlanabilecek birkaç metin anlamına gelebilir. Aynı süre aktif mağazada yeni siparişleri, stok hareketlerini veya müşteri kayıtlarını kapsayabilir. Bu yüzden “günlük yedek var” ifadesinin işletmenin ihtiyacına uygun olup olmadığı ayrıca konuşulur. Hangi verinin ne kadar süre geriden gelebileceği ve geri dönüşün iş üzerindeki etkisi somut senaryolarla değerlendirilmelidir.

Kurgusal bir örnekte, sabah alınan yedekten akşam geri dönüldüğünde gün içinde oluşmuş siparişler ne olacak? Eski dosyalarla yeni sipariş verisinin nasıl bir arada ele alınacağı bilinmiyorsa bütün veritabanını geri almak beklenmeyen kayıplara neden olabilir. Bu rehber canlı veritabanında işlem talimatı değildir; mağaza için geri dönüş stratejisinin sipariş ve stok akışını bilen sorumlularla hazırlanması gerektiğini gösterir.

Güncelleme kapsamını ve karar sorumlusunu belirleyin

WordPress çekirdeği, tema ve eklentiler ayrı güncelleme kaynaklarına sahiptir. Kullanılan yazılımın destek durumu, gerekli düzeltmeler ve bağımlılıklar birlikte değerlendirilmelidir. Bir güncellemenin bulunmasıyla sitenin bütün bileşenlerinin aynı anda kontrolsüz biçimde değiştirilmesi aynı yaklaşım değildir. Güncelleme öncesinde mevcut durumun kaydı, geri dönüş hazırlığı ve sonrasında yapılacak kritik testler belirli olmalıdır. Önemli düzeltmeleri sırf aylık rapor gününü beklemek için erteleyen bir plan kurulmaz.

WordPress güncelleme belgesi, işlem öncesinde yedek alınmasını önerir ve çekirdek dosyalara yapılan değişikliklerin güncellemede kaybolabileceğini açıklar. Bu nedenle özelleştirmelerin nerede bulunduğu envanterde bilinmelidir. Güncel sürüm numarası burada sabitlenmemiştir; uygulama tarihinde geçerli yayınlar ve kullanılan bileşenlerin uyumluluğu kontrol edilir. İşletmenin ihtiyacına göre test ve yayın sırası ayrıca belirlenir.

Bir bakım teklifinde güncellemeyi kimin onayladığı ve sorun görülürse kimin karar verdiği anlaşılmalı. İşletme temsilcisinin her teknik ayrıntıyı değerlendirmesi beklenmeyebilir; buna karşılık müşteri işlemlerini etkileyecek bir değişiklikte iletişim yolu belli olmalıdır. Sorumluluklar yazılı değilse, hata sırasında herkesin başka bir kişiden yanıt beklediği bir durum oluşabilir. Bakım planının değeri, normal günler kadar bu karar anlarında da ortaya çıkar.

Test ortamı gerçekten neyi temsil ediyor?

Bir test kopyası kullanılıyorsa canlı sitenin hangi özelliklerini temsil ettiği bilinmelidir. Tema düzeni aynı olabilir; ödeme, e-posta, stok veya dış sistem bağlantıları farklı çalışabilir. Bu farklar kayıt altına alınmadan test sonucu canlıya doğrudan genellenmemelidir. Test ortamında gerçek müşteriye bildirim gönderilmesi veya canlı stokların değiştirilmesi gibi yan etkilerin nasıl önlendiği de sorumlular tarafından belirlenmelidir.

Test kopyasını herkese açık bir müşteri veri arşivine dönüştürmeyin. Erişim kapsamı ve kullanılacak örnek veri, bakımın gerektirdiği kadar olmalıdır. Testin tamamlanması da yalnız ekran görüntüsü almak değildir. Hangi işlevin hangi örnekle denendiği, beklenen sonuç ve gözlenen sonuç kaydedilir. Test ortamının kontrol edildiği tarih ile canlıdaki son değişiklik arasında fark varsa testin güncelliği yeniden değerlendirilir.

İşletmenin para veya talep kazandığı akışları kontrol edin

Bakım sonrasında ana sayfanın açılması yeterli olmayabilir. Bir ajans sitesi için teklif formu, bir mağaza için ürün seçimi ve sipariş adımları, üyelik sitesi için giriş ve erişim akışı kritik olabilir. Kontrol listesini sitenin iş modelinden çıkarın. Ziyaretçinin görünen başarı mesajıyla işlemin arka tarafta kayıt altına alınması veya bildirimin ulaşması farklı aşamalardır; mümkün olduğunda uygun test yöntemiyle ayrı değerlendirilir.

Gerçek müşterilere deneme bildirimleri göndermek veya izinsiz gerçek ödemeler yapmak standart bakım kontrolü gibi planlanmamalıdır. Test alıcısı, test verisi ve gerekli durumlarda sağlayıcının uygun deneme yöntemi önceden belirlenir. İşletmenin bütün formlarını her gün aynı kişiymiş gibi doldurmak yerine hangi testin ne zaman ve hangi yan etkiyle çalıştığı bilinmelidir. Başarılı kontrolün kanıtı ve başarısızlıkta izlenecek yol raporda yer almalıdır.

Site türü	Kritik kontrol örneği	Yalnız şu işaret yeterli değildir
Kurumsal site	Formun kayıt ve bildirim akışı	Düğmenin ekranda görünmesi
WooCommerce mağazası	Seçenek, sepet ve uygun sipariş denemesi	Ana sayfanın açılması
Randevu sitesi	Uygunluk ve kayıt sonucunun doğrulanması	Takvimin yüklenmesi
Üyelik sitesi	Yetkiye uygun giriş ve içerik erişimi	Giriş formunun çizilmesi

Otomatik güncellemeyi sorumluluk listesinden çıkarmayın

Otomatik güncelleme açık olması, o bileşenin bakım kapsamında artık izlenmeyeceği anlamına gelmez. Sonucun görülmesi, başarısız denemelerin fark edilmesi ve beklenmeyen değişikliklerin değerlendirilmesi gerekir. WordPress’in otomatik güncelleme belgesi, eklenti ve tema güncellemelerinin ayarlarını ve zamanlanmış görevlerle ilişkisini açıklar. Kullanılan ortamda işleyişin ne olduğu doğrulanmadan yalnız açık bir anahtara güvenilmemelidir.

Otomasyonun hangi işleri yaptığı, hangi işlerin insan değerlendirmesi istediği ve kimin bildirim aldığı bir tabloda görülebilir. Bu tablo gereksiz onay adımları üretmek için değil, müdahale gerektiğinde iletişimin doğru kişiye ulaşması içindir. İşlem kaydı bulunmayan bir otomasyonun ne zaman çalıştığını ve neyi değiştirdiğini anlamak zorlaşır. Bakım raporunda yalnız “otomatik” yazmak yerine gözlenmiş sonuçların yer alması gerekir.

Güvenlik kontrolünün kapsamını somutlaştırın

“Güvenlik dahil” ifadesini açık işlere ayırın. Kullanıcı ve erişim incelemesi, desteklenmeyen bileşenlerin belirlenmesi, yedeklerin erişim düzeni ve gözlenen anormalliklerin değerlendirilmesi aynı kapsamda mı? Bir araç kullanılıyorsa hangi uyarıları ürettiği ve kimin bunları değerlendirdiği anlaşılmalı. Bir taramanın belirli bir anda sorun bulmaması, sitenin her durumda güvenli olduğu garantisi olarak sunulmamalıdır. Araç sonucu ile uzman incelemesinin kapsamı da ayrı belirtilir.

Bakım için erişim sağlarken işletme sahibinin hesabını kontrolsüz paylaşmak yerine görev için gerekli erişim düzeni planlanır. Eski çalışanların veya hizmeti biten tarafların erişimlerinin ne zaman gözden geçirileceği belirlenir. Hesap sahipliği, çalışma yetkisi ve kurtarma yolları aynı kişisel e-posta adresinde belirsiz biçimde toplanmamalıdır. Bu rehberde gerçek hesap veya güvenlik ayarı değiştirilmez; teklif aşamasında sorulacak sorumluluk soruları tarif edilir.

Lisans, barındırma ve dış servis bedellerini ayırın

Bakım hizmeti bedeline her tema, eklenti, barındırma veya e-posta aboneliğinin dahil olduğu varsayılmamalıdır. Lisans yenilemelerini kimin yaptığı, hesabın kime ait olduğu ve hizmet sona erdiğinde kullanımın nasıl sürdüğü önceden konuşulmalı. Aynı kapsamı iki farklı kalemde tekrar ücretlendirmemek gerekir. Bir sağlayıcının sunduğu sunucu yedeğiyle ajansın doğruladığı geri dönüş hizmeti farklı işlerse bunun farkı açıklanmalıdır.

Fiyat karşılaştırırken yalnız aylık tutara bakmak eksik kalır. Dahil çalışma süresi, desteklenen alan adı ve ortam sayısı, kritik akış kontrolleri, rapor ve müdahale kapsamı aynı olmalıdır. Ucuz görünen bir teklif yalnız güncelleme düğmesini kapsarken başka bir teklif test ve geri dönüş hazırlığını içeriyor olabilir. Kesin fiyat bu rehberde verilmez; mevcut sitenin durumu ve ihtiyaçları görülmeden bütün projelere aynı kapsam sözü verilmemelidir.

Hata düzeltmesiyle yeni özellik talebini ayırın

Çalışan bir formun bakım işleminden sonra bozulmasıyla yeni bir teklif hesaplayıcısı geliştirilmesi farklı işlerdir. Bakım kapsamında giderilecek sorunlar ve ayrıca teklif verilecek geliştirmeler önceden tarif edilmelidir. Tasarım yenilemesi, yeni dil, yeni entegrasyon veya çok sayıda ürün girişi otomatik olarak standart bakım işi kabul edilmemeli. Buna karşılık teslim edilmiş işteki hata, belirsiz bir adla sürekli yeni hizmete dönüştürülmemelidir.

İçerik güncellemeleri için de sınır bulunmalı. Ayda kaç küçük düzenleme yapılacağı, görsellerin kimden geleceği ve metin üretiminin dahil olup olmadığı netleşir. Talebin kapsamı değiştiğinde uygulanacak değerlendirme yöntemi bilinmelidir. Böylece işletme her küçük işlemde beklenmeyen ek bedelle karşılaşmaz, bakım ekibi de sınırsız geliştirme beklentisiyle çalışmaz. Sınırların anlaşılır olması, hizmetin takibini ve önceliklendirmesini kolaylaştırır.

Müdahale süresini sonuç garantisiyle karıştırmayın

Bir bildirim alındıktan sonra ilk değerlendirmenin ne zaman yapılacağıyla sorunun kesin çözülme süresi aynı değildir. Sorun barındırma, dış servis veya başka bir yazılım sağlayıcısına bağlı olabilir. Çalışma saatleri, acil durum tanımı, iletişim kanalı ve yedek sorumlu açıkça yazılmalı. “Hızlı destek” gibi tek başına ölçülemeyen ifadeler yerine hangi aşamada hangi yanıtın beklendiği anlaşılmalıdır.

Kritik kesinti, görsel düzeltme ve yeni özellik aynı öncelikte ele alınmaz. İşletmeyle örnek olaylar üzerinden öncelik tanımı yapılabilir. Müşteri talebi alamayan form ile tek bir metindeki yazım hatası farklı iş etkisine sahiptir. Ancak yüksek öncelik verilmesi, kaynağı bilinmeyen bir sorunun dakikalar içinde çözüleceğine söz vermek anlamına gelmez. İlk inceleme, geçici çözüm ve kalıcı düzeltme ayrı kaydedilebilir.

Aylık rapor yapılan işi görünür kılmalı

Örneğin kurgusal bir kurumsal sitede iletişim formunun bildirimi ulaşmıyor olsun. İş kaydı, yalnız “form kontrol edildi” demek yerine hangi başvuru yolunun incelendiğini, onaylı test alıcısını ve beklenen sonucu belirtir. Formun kayıt oluşturması, ziyaretçiye yanıt vermesi ve bildirimin ilgili kanala aktarılması ayrı gözlemlerdir. Bir aşama doğrulanamadıysa raporda bilinmiyor olarak kalır; varsayımla başarılı yazılmaz. Gerçek müşteri bilgisi de örnek rapora gereksiz yere eklenmez.

Kaydın sonunda yapılan değişiklik, kontrol zamanı ve açık iş bulunabilir. Bildirim sağlayıcısından yanıt bekleniyorsa bu bağımlılık belirtilir; sorun çözüldü diye kapatılmaz. İşletme temsilcisi böylece neyin tamamlandığını ve hangi adımın beklediğini görebilir. Aynı sorun tekrarlandığında önceki işlem ve sonuç kayıtları yeni incelemeye dayanak olur. Bu örnek, gerçek bir müşteride yapılmış işlem veya elde edilmiş sonuç iddiası değildir; raporun nasıl somutlaştırılabileceğini gösterir.

Raporu yalnız eklenti sürümlerinin uzun bir listesine dönüştürmeyin. Yapılan değişiklik, nedeni, öncesindeki hazırlık, test edilen akış ve sonuç aynı kayıtta bulunmalı. Gözlenen bir sorun varsa hangi aksiyonun alındığı ve hangi işin beklediği anlaşılır olmalıdır. İşlem yapılmayan bir bileşende bunun nedeni kaydedilebilir. Gelecek ayın gereksinimleriyle tamamlanan işler birbirine karıştırılmadan sunulur.

Rapor alanı	Örnek kayıt biçimi
İşlem	Bileşen güncellemesi veya belirli hata incelemesi
Gerekçe	Gözlenen sorun, gerekli düzeltme veya planlı bakım
Hazırlık	Uygun yedek, kapsam ve test ortamı bilgisi
Kontrol	Kritik akış, örnek senaryo ve gözlenen sonuç
Bekleyen iş	Sorumlu, bağımlılık ve sonraki değerlendirme

Performans ve SEO verileri raporda varsa ölçümün kapsamı ve zamanı belirtilir. Tek bir laboratuvar hız puanı bütün kullanıcıların deneyimi değildir; bir günlük sıralama hareketi de bakımın tek başına sonucu olarak sunulmaz. Web sitesi hızı rehberindeki gibi temsilî ekranlar ve uygun ölçümler birlikte değerlendirilir. Teknik sorun görülmüşse gerekçeli düzeltme yapılır; sırf yeni tarih yazmak için içerik değiştirilmez.

Geri yükleme denemesi ve hizmet teslimini planlayın

Uygun bir test ortamında geri dönüş sürecinin denenmesi, kurtarma notlarının eksik yerlerini gösterebilir. Denemede hangi yedeğin kullanıldığı, hangi verinin geri geldiği ve hangi bağlantıların tekrar kontrol edildiği kaydedilir. Bu, canlı siteyi plansız olarak eski bir kopyayla değiştirme çağrısı değildir. Özellikle mağazada işlem sırasında oluşan yeni verinin korunması ayrı bir tasarım gerektirir ve ilgili sorumlularla değerlendirilir.

Hizmet sona erdiğinde işletmenin hangi kayıtları alacağı da baştan belirlenmelidir. Güncel envanter, lisans sahipliği, gerekli erişimlerin işletmeye teslimi, yedek politikası ve açık iş listesi anlaşılır olmalı. Çalışma yetkisinin kaldırılmasıyla işletmenin kendi hesabını kaybetmesi aynı şey değildir. Teslim süreci yalnız bir şifre mesajına indirgenmemeli; gizli bilgilerin paylaşım yöntemi de uygun biçimde ele alınmalıdır.

Teklif karşılaştırırken bu soruları sorun

• Bakım hangi alan adını, ortamları ve yazılım bileşenlerini kapsıyor?
• Yedekte dosya ve veritabanı birlikte bulunuyor mu; geri dönüş nasıl doğrulanıyor?
• Sipariş veya talep verisi kaybı beklentisi nasıl ele alınıyor?
• Güncelleme sonrasında hangi müşteri işlemleri test ediliyor?
• Otomasyonun sonucu ve başarısızlık uyarıları kim tarafından izleniyor?
• Lisans, barındırma, e-posta ve dış servis bedelleri nasıl ayrılıyor?
• Hata düzeltmesiyle yeni geliştirme talebinin sınırı nedir?
• Destek saatleri, ilk değerlendirme süresi ve acil durum kapsamı belli mi?
• Rapor ve hizmet sonu tesliminde hangi kayıtlar işletmeye veriliyor?

Sitenizin bakım kapsamını netleştirelim

WordPress web tasarım ve geliştirme hizmetimizde mevcut yapının sürdürülebilirliği de değerlendirilir. WooCommerce kullanıyorsanız mağaza geliştirme kapsamıyla ürün, sipariş ve entegrasyon ihtiyaçlarını birlikte konuşabiliriz. Teknik erişim veya tarama sorunu varsa teknik SEO incelemesi ayrı bir ihtiyacı ele alır; bütün işler belirsiz bir bakım başlığında toplanmaz.

Proje formunda mevcut site adresinizi, kullandığınız temel işlevleri ve bakımda yaşadığınız sorunu paylaşın. İlk değerlendirme için yönetici şifresi göndermeniz gerekmez. Önce mevcut kapsamı ve sorumluları belirleyelim; ardından gerekli bakım, test ve destek işlerini yazılı teklif üzerinde netleştirelim. Sitenin durumu görülmeden kesintisizlik, güvenlik veya sıralama garantisi verilmez.

Kaynaklar ve kontrol tarihi

2 Kasım 2026 tarihinde WordPress site bakım belgesi, güncelleme belgesi, yedekleme el kitabı ve otomatik güncelleme açıklaması kontrol edildi. Eski bakım belgesindeki genel takvim ifadeleri her site için sabit bir güncelleme sıklığı olarak aktarılmadı. Envanter tabloları, kapsam soruları, rapor ve kabul önerileri bu rehberin özgün çalışma çerçevesidir.