Web Sitesi Bakım Hizmeti Nedir? Neleri Kapsar, Ne Zaman Gerekir?

Kısa cevap: Web sitesi bakım hizmeti, yayındaki bir sitenin güvenli, hızlı ve işini yapar durumda kalması için düzenli aralıklarla yapılan teknik ve içerik işlerinin toplamıdır: yazılım, eklenti ve tema güncellemeleri, yedekleme ve geri yükleme testi, güvenlik taraması, çalışma süresi izleme, SSL ve alan adı takibi, hız ölçümü, kırık bağlantı ve form testleri, içerik ve yasal metin güncellemeleri. Yeni özellik eklemek ya da tasarımı değiştirmek bakım değil geliştirmedir; bakımın amacı var olanı bozulmadan çalışır tutmaktır. Siteniz satış, teklif ya da randevu topluyorsa, WordPress gibi eklentili bir altyapıda çalışıyorsa veya ekibinizde bu işleri her hafta takip edecek biri yoksa bakım bir tercih olmaktan çıkar. ikas ve Shopify gibi hazır platformlarda sunucu ve çekirdek yazılım platformun sorumluluğundadır, ama tema, uygulama, içerik, alan adı ve form tarafı yine sizdedir.

Bir web sitesi yayına alındığı gün "bitmiş" sayılır, oysa asıl ömrü o gün başlar. Kullandığı yazılımlar güncellenir, tarayıcılar ve arama motorları kurallarını değiştirir, sertifikaların süresi dolar, ekipte çalışan değişir, formun bildirim gönderdiği adres artık kimse tarafından okunmaz. Aşağıda bakımın kapsamını, hangi işin hangi sıklıkla yapılacağını, bakım sözleşmesinde nelere bakmanız gerektiğini, fiyatlandırma modellerini ve kendiniz uygulayabileceğiniz bir kontrol listesini bulacaksınız.

Web sitesi bakım hizmeti nedir, neden gerekir?

Web sitesi bakım hizmeti, sitenin teknik altyapısını, güvenliğini, performansını ve içeriğini belirli bir takvime göre kontrol eden, küçük sorunları büyümeden gideren ve her ay ne yapıldığını raporlayan sürekli bir hizmettir. Tek seferlik bir iş değil, bir abonelik ya da saat havuzu gibi işleyen bir sorumluluk paylaşımıdır. İyi kurgulanmış bir bakımda neyin kimde olduğu, bir sorun çıktığında kimin ne kadar sürede müdahale edeceği ve hangi işlerin ek ücrete tabi olduğu yazılıdır.

Bakımın değeri genellikle bir şey bozulduğunda anlaşılır. Site açılmıyorsa, ödeme sayfası hata veriyorsa ya da Google arama sonuçlarında "bu site saldırıya uğramış olabilir" uyarısı çıkıyorsa, o noktada yapılan iş artık bakım değil acil müdahaledir ve hem daha pahalı hem daha stresli olur. Bakım, bu anların sayısını azaltmanın ve yaşandığında süresini kısaltmanın yoludur.

Yayındaki bir site neden kendiliğinden eskir?

Siteniz siz hiçbir şeye dokunmasanız da eskir, çünkü üzerinde çalıştığı her katman sizden bağımsız olarak değişir. En sık karşılaşılan nedenler şunlardır:

• Eklenti ve tema açıkları: Patchstack'in State of WordPress Security in 2026 raporuna göre WordPress ekosisteminde 2025 yılında 11.334 yeni güvenlik açığı bildirildi; bu, 2024'e göre yaklaşık %42'lik bir artış. Yeni açıkların %91'i eklentilerde, %9'u temalarda bulundu, WordPress çekirdeğinde ise yalnızca 6 düşük öncelikli açık raporlandı.
• Yamanın gecikmesi: Aynı rapora göre açıkların %46'sı kamuoyuna duyurulduğu anda geliştiricisinden düzeltme almamıştı. Yoğun istismar edilen açıklarda toplu saldırıya geçiş süresinin medyanı 5 saat olarak ölçüldü. Yani "ayda bir bakarız" yaklaşımı, kritik eklentilerde yetersiz kalabilir.
• Sunucu yazılımı sürümleri: PHP gibi sunucu dillerinin her sürümünün bir destek ömrü vardır. php.net'in destek tablosuna göre PHP 8.2'nin güvenlik desteği 31 Aralık 2026'da bitiyor; desteği biten sürümde çalışan bir site, yeni açıklara karşı yama almaz.
• Tarayıcı ve sertifika kuralları: SSL sertifikalarının azami geçerlilik süresi 2026'dan itibaren kademeli olarak kısalıyor. Elle yenilenen bir sertifika, eskisinden daha sık yenilenmek zorunda.
• Arama motoru ölçütleri: Google'ın sayfa deneyimi ölçütleri değişebilir; 2024'te etkileşim ölçümü için INP metriği FID'in yerini aldı. Dün iyi görünen bir sayfa, bugün yeni ölçütte zayıf kalabilir.
• Mevzuat: Kişisel Verileri Koruma Kurulu'nun 2026/347 sayılı ilke kararı gibi düzenlemeler, sitedeki aydınlatma ve onay metinlerinin yeniden ele alınmasını gerektirebilir.
• İçeriğin kendisi: Telefon numarası, adres, çalışma saati, kampanya, fiyat, ekip ve belge bilgileri zamanla geçerliliğini yitirir. Ziyaretçi için eski bilgi, bozuk bir sayfa kadar güven kaybettirir.

Bakım hizmeti en çok kimler için gereklidir?

Her site aynı yoğunlukta bakıma ihtiyaç duymaz. Bakım ihtiyacı; sitenin size ne kadar iş getirdiği, kaç farklı yazılım parçasından oluştuğu ve ekibinizin teknik kapasitesi arttıkça büyür. Aşağıdaki durumlardan ikisi ya da daha fazlası sizin için geçerliyse düzenli bir bakım planı şarttır:

• Site üzerinden doğrudan satış, ödeme, rezervasyon ya da randevu alıyorsunuz.
• Teklif ve iletişim formları satış ekibinizin ana müşteri kaynağı.
• WordPress, WooCommerce ya da benzeri bir içerik yönetim sisteminde 15-20'den fazla eklenti kullanıyorsunuz.
• Reklama düzenli bütçe ayırıyorsunuz; site bir saat kapalı kalsa harcamanın bir kısmı boşa gidiyor.
• Siteyi yapan kişi ya da firma artık ulaşılabilir değil ve sitenin nasıl kurulduğunu kimse tam bilmiyor.
• Siteniz kullanıcı hesabı, üye girişi ya da müşteri paneli gibi kişisel veri tutan bölümler içeriyor.

Hangi içerik yönetim sistemini kullandığınızın bakım yüküne etkisi büyüktür. Bu farkı merak ediyorsanız CMS seçimi rehberimizde platformları bakım ihtiyacı açısından da karşılaştırdık.

Bakım ile yeni geliştirme ve yenileme arasındaki fark nedir?

Bakım var olan sitenin aynı işi güvenle yapmaya devam etmesini sağlar; yeni geliştirme siteye daha önce olmayan bir yetenek ekler; yenileme (redesign) ise sitenin tasarımını, yapısını ya da altyapısını baştan ele alır. Üçü farklı bütçe, farklı ekip ve farklı başarı ölçütü ister. Sözleşmelerdeki anlaşmazlıkların büyük kısmı da bu ayrımın baştan yazılmamasından çıkar.

Sitenin tamamen yenilenmesi gerektiğine ne zaman karar verileceğini, geçişte SEO'nun nasıl korunacağını web sitesi yenileme rehberimizde ayrıca anlattık; burada yalnızca yayındaki sitenin bakımına odaklanıyoruz. Yeni bir işlev ya da sıfırdan bir site ihtiyacınız varsa bu da bakım bütçesinden değil, özel yazılım ve web sitesi geliştirme kapsamında planlanmalıdır.

Gri alan: küçük değişiklik talepleri bakım mıdır?

Kampanya bannerını değiştirmek, bir hizmet sayfasına yeni paragraf eklemek ya da formdaki bir alanın adını düzeltmek çoğu bakım paketinde "içerik güncellemesi" olarak yer alır. Forma yeni bir adım eklemek, yeni bir sayfa şablonu tasarlamak ya da sitenin bir CRM programına veri göndermesini sağlamak ise geliştirmedir. Basit bir ayrım ölçütü kullanabilirsiniz:

• Mevcut şablon ve bileşenlerle, kod yazmadan yapılabiliyorsa: bakım (içerik güncellemesi).
• Yeni bir şablon, yeni bir bileşen ya da yeni bir veri akışı gerekiyorsa: geliştirme.
• Birden çok sayfanın görünümünü ya da menü yapısını değiştiriyorsa: küçük çaplı yenileme, ayrı teklif.

Bu ayrımı sözleşmeye örneklerle yazmak, ay sonunda "bu da bakıma dahil değil miydi?" tartışmasını önler. Hazır bir sistem mi yoksa size özel bir yazılım mı kullandığınız da bu sınırı etkiler; iki yaklaşımın uzun vadeli bakım yükünü hazır site mi özel yazılım mı yazımızda karşılaştırdık.

Web sitesi bakımı neleri kapsar?

Eksiksiz bir web sitesi bakımı on üç ana kalemden oluşur: güncellemeler, yedek ve geri yükleme testi, güvenlik taraması, çalışma süresi izleme, SSL ve alan adı takibi, hız, kırık bağlantılar, form ve e-posta testleri, içerik güncellemeleri, SEO sağlık kontrolü, yasal metinler, erişilebilirlik ve erişim yönetimi. Her teklifte hepsi bulunmaz; önemli olan hangisinin dahil, hangisinin hariç olduğunu bilmenizdir. Aşağıdaki tablo, teklif karşılaştırırken kullanabileceğiniz bir kapsam haritasıdır.

Aylık bakım raporunda neler görmelisiniz?

Bakım hizmetinin görünür çıktısı rapordur; rapor yoksa yapılan işi denetleyemezsiniz. İyi bir aylık rapor kısa olur ama şu soruları cevaplar:

• Bu ay hangi yazılım, eklenti ve temalar hangi sürümden hangi sürüme güncellendi, güncellenmeyenler neden bekletildi?
• Kaç yedek alındı, nerede saklanıyor, en son geri yükleme testi ne zaman yapıldı ve sonucu ne oldu?
• Ay boyunca toplam kesinti süresi ve kesintilerin nedeni neydi?
• Güvenlik taramasında bulgu var mı, varsa nasıl kapatıldı?
• Hız ölçümleri bir önceki aya göre nasıl değişti?
• Formlar test edildi mi, bildirimler doğru adrese ulaştı mı?
• Bu ay açılan destek talepleri, yanıt ve çözüm süreleri, kalan saat havuzu ne durumda?
• Önümüzdeki ay için önerilen ama onay bekleyen işler neler?

Rapordaki en değerli bölüm çoğu zaman sonuncusudur: bakım ekibinin gördüğü ama kapsam dışı olduğu için yapmadığı işler. Örneğin artık güncellenmeyen bir eklentinin yerine yenisini koymak ya da desteği bitmek üzere olan bir PHP sürümünden geçiş planlamak.

Çekirdek, eklenti ve tema güncellemeleri nasıl güvenle yapılır?

Güncellemeler önce yedek alınarak, sürüm notları okunarak ve canlı siteyle aynı olan bir test ortamında denenerek yapılır; ancak kritik akışlar (form, sepet, ödeme, üye girişi) test edildikten sonra canlıya alınır. "Güncelle" düğmesine canlı sitede toplu basmak bakım sayılmaz, risktir. Güncellemeyi hiç yapmamak ise daha büyük bir risktir; doğru yol ikisinin arasındaki disiplinli süreçtir.

Test ortamı (staging) nedir, neden gerekir?

Test ortamı, canlı sitenizin birebir kopyası olan ama yalnızca sizin ve bakım ekibinizin görebildiği ayrı bir adrestir. Güncellemeler önce burada yapılır; bir eklenti diğeriyle çakışıyorsa ya da tema yeni sürümde bozuluyorsa bunu müşterileriniz değil, siz görürsünüz. Test ortamının arama motorlarına kapalı olması ve canlı siteye aktarım sırasında bu kapatma ayarının canlıya taşınmaması gerekir; staging'deki "dizine ekleme" engelinin yanlışlıkla canlıya geçmesi, bakımda en sık görülen SEO kazalarından biridir.

Güvenli güncelleme sırası adım adım

1. Canlı sitenin tam yedeğini alın ve yedeğin tamamlandığını doğrulayın.
2. Bekleyen güncellemelerin listesini çıkarın, her birinin sürüm notlarını okuyun; "güvenlik düzeltmesi" ya da "büyük sürüm" ibaresi olanları işaretleyin.
3. Test ortamını canlı siteyle eşitleyin ve güncellemeleri önce orada, mümkünse tek tek yapın.
4. Ana sayfa, en çok ziyaret alan üç sayfa, iletişim ve teklif formları, arama, sepet, ödeme ve üye girişi akışlarını deneyin.
5. Tarayıcı konsolunda ve sunucu hata kayıtlarında yeni hata olup olmadığına bakın.
6. Sorun yoksa güncellemeleri canlıya alın; yoğun saatler yerine trafiğin en düşük olduğu zaman dilimini seçin.
7. Canlıda aynı kritik akışları bir kez daha test edin ve sonraki 24-48 saat hata kayıtlarını ve çalışma süresini izleyin.
8. Geri dönüş planını hazır tutun: hangi yedekten, kaç dakikada geri dönüleceği önceden bilinmelidir.

Otomatik güncelleme açılmalı mı?

WordPress 5.5 sürümünden bu yana yöneticiler eklenti ve temalar için otomatik güncellemeyi tek tek açabiliyor; WordPress bu kontrolleri varsayılan olarak günde iki kez çalıştırıyor. Otomatik güncelleme, küçük ve az bağımlılığı olan eklentilerde ve güvenlik yamalarında zaman kazandırır. Buna karşılık e-ticaret, sayfa oluşturucu, üyelik ve ödeme eklentileri gibi sitenin iskeletini taşıyan bileşenlerde büyük sürüm geçişlerini otomatiğe bırakmak yerine test ortamında denemek daha güvenlidir. Hangi eklentinin otomatik, hangisinin elle güncelleneceğini bir listede tutmak, bakım ekibi değişse bile kararın kaybolmamasını sağlar.

PHP ve veritabanı sürümleri de güncelleme kapsamındadır

Eklentileri güncel tutup sunucudaki PHP sürümünü unutmak sık yapılan bir hatadır. WordPress'in resmi gereksinim sayfası PHP 8.3 ve üzerini, MySQL 8.0 ya da MariaDB 10.11 ve üzerini öneriyor; eski sürümlerin hâlâ çalıştığını ama resmi destek ömrünü tamamladığı için sitenizi güvenlik açıklarına açık bırakabileceğini belirtiyor. Kasım 2026 itibarıyla PHP 8.2 kullanan siteler için yıl sonu bir eşik: bu sürümün güvenlik desteği 31 Aralık 2026'da bitiyor. Sürüm geçişi de önce test ortamında, eklenti uyumluluğu kontrol edilerek yapılmalıdır; bazı barındırma firmaları eski sürümleri belirli bir tarihten sonra kendiliğinden yükseltebildiği için bu tarihleri takip etmek de bakımın işidir.

Kullanılmayan eklentiyi devre dışı bırakmak yetmez

Devre dışı bırakılmış bir eklentinin dosyaları sunucuda durmaya devam eder ve bazı açıklar eklenti etkin olmasa bile istismar edilebilir. Bakımda üç ayda bir eklenti envanteri çıkarılmalıdır: kullanılmayanlar silinir, uzun süredir güncelleme almayan ya da dizinden kaldırılmış eklentilerin yerine bakımı süren alternatifler planlanır, aynı işi yapan iki eklenti varsa biri kaldırılır. Eklenti sayısını azaltmak hem güvenlik yüzeyini küçültür hem de güncelleme süresini kısaltır.

Yedekleme neden geri yükleme testi olmadan eksik kalır?

Bir yedek ancak geri yüklenebildiği kanıtlandığında işe yarar; bu yüzden bakımda yedekleme ve geri yükleme testi tek bir kalem olarak ele alınmalıdır. Pratikte en sık görülen sorun yedeğin hiç alınmaması değil, alınan yedeğin eksik, bozuk ya da sitenin bulunduğu sunucuyla birlikte erişilemez olmasıdır. Kriz anında ilk kez geri yükleme denemek, yangın çıktığında yangın tüpünün dolu olup olmadığını kontrol etmeye benzer.

Neyi yedeklemelisiniz?

"Siteyi yedekledik" ifadesi çoğu zaman yalnızca dosyaları kapsar. Eksiksiz bir yedek şu parçaları içermelidir:

• Veritabanı: Sayfalar, ürünler, siparişler, üyeler, form kayıtları ve ayarlar burada durur. E-ticarette en hızlı değişen ve en değerli parçadır.
• Yüklenen dosyalar: Görseller, PDF katalog ve belgeler, videolar.
• Tema ve özel kod: Özellikle size özel yazılmış şablonlar ve alt tema dosyaları.
• Yapılandırma: Sunucu ve uygulama ayar dosyaları. Bu dosyalar şifre ve anahtar içerebileceği için yedeğin kendisi de korunmalı, şifreli saklanmalıdır.
• DNS kayıtları: Alan adı yönlendirmeleri, e-posta kayıtları (MX, SPF, DKIM, DMARC). Bir panel değişikliğinde kaybolduklarında e-posta da durur.
• Hazır platform verisi: ikas ya da Shopify gibi altyapılarda sunucu yedeği platformun işidir, ama ürün, müşteri ve sipariş verisinin düzenli dışa aktarımı ile tema kopyaları sizin kontrolünüzde olmalıdır.

3-2-1 kuralı, RPO ve RTO ne anlama gelir?

Yedekleme planı kurarken yaygın olarak kullanılan 3-2-1 kuralı şöyle özetlenir: verinin en az 3 kopyası olsun, bu kopyalar 2 farklı ortamda dursun ve en az 1 kopya sitenin bulunduğu sunucudan ve hesaptan bağımsız bir konumda saklansın. İki terim de planın hedefini netleştirir. RPO (Recovery Point Objective), en fazla ne kadarlık veri kaybını göze alabileceğinizdir; günlük yedek alıyorsanız en kötü durumda bir günlük siparişi ya da form kaydını kaybedersiniz. RTO (Recovery Time Objective) ise bir felaketten sonra sitenin en geç ne kadar sürede yeniden çalışması gerektiğidir.

Tablodaki süreler örnek hedeflerdir; doğru değer, bir saatlik veri ya da kesinti kaybının işletmenize maliyetine göre belirlenir. Saklama süresi uzun tutulmalıdır, çünkü bazı enfeksiyonlar haftalarca fark edilmez ve son yedeklerin hepsi zaten bulaşmış olabilir.

Geri yükleme testi nasıl yapılır?

1. Rastgele bir yedek seçin; en yenisini değil, birkaç gün öncesine ait olanı.
2. Yedeği canlı siteye değil, ayrı bir test ortamına geri yükleyin.
3. Sitenin açıldığını, görsellerin yüklendiğini, son eklenen içeriklerin yerinde olduğunu kontrol edin.
4. Bir form doldurun, bir test siparişi oluşturun, yönetim paneline giriş yapın.
5. Geri yüklemenin başından sonuna kaç dakika sürdüğünü not edin; bu, gerçek RTO'nuzdur.
6. Eksik ya da hatalı çıkan parçayı yedekleme planına ekleyin ve testi tarihiyle birlikte rapora yazın.

Barındırma firmasının yedeği neden tek başına yetmez?

Barındırma firmalarının aldığı yedekler değerlidir ama çoğu zaman aynı veri merkezinde, aynı hesap altında durur ve saklama süresi kısadır. Hesap askıya alınırsa, ödeme aksarsa ya da hesap ele geçirilirse bu yedeklere de ulaşamayabilirsiniz. Bu nedenle en az bir kopyanın farklı bir sağlayıcıda, işletmenizin kontrol ettiği bir depolama alanında durması gerekir.

Güvenlik taraması ve kötü amaçlı yazılım temizliği bakımın neresinde durur?

Bakım kapsamındaki güvenlik işi; mevcut sitenin düzenli taranması, şüpheli değişikliklerin erken fark edilmesi ve bir bulaşma olduğunda sitenin temizlenip saldırganın girdiği kapının kapatılmasıdır. Güvenlik duvarı, yetkilendirme modeli ve sunucu sertleştirmesi gibi koruma mimarisinin kurulması ise ayrı bir güvenlik çalışmasıdır. O tarafı web sitesi güvenliği rehberimizde ayrıntılı anlattık; burada bakım rutini içindeki yerine bakıyoruz.

Barındırma firmasının korumasına tamamen güvenmek de yeterli değildir. Patchstack'in aynı raporunda yer alan testte, barındırma firmalarının standart savunmaları denenen güvenlik açığı saldırılarının yalnızca %26'sını engelledi. Bu, sunucu tarafındaki korumanın değersiz olduğu anlamına gelmez; uygulama katmanındaki açıkların ancak güncelleme ve tarama disipliniyle kapanabileceğini gösterir.

Sitenizin ele geçirildiğini gösteren işaretler

• Google arama sonuçlarında sitenizin altında "bu site saldırıya uğramış olabilir" türünde bir uyarı görünmesi.
• Mobilden ya da arama sonuçlarından gelen ziyaretçilerin başka sitelere yönlendirilmesi; siz doğrudan girdiğinizde ise her şeyin normal görünmesi.
• Search Console'da sizin oluşturmadığınız, yabancı dilde ya da alakasız konularda yüzlerce yeni sayfa görünmesi.
• Yönetim panelinde tanımadığınız yönetici kullanıcılar ya da sizin yüklemediğiniz eklentiler olması.
• Sunucu kaynak kullanımında ya da giden e-posta sayısında açıklanamayan artış.
• Barındırma firmasından "hesabınızdan spam gönderiliyor" uyarısı gelmesi.

Kötü amaçlı yazılım temizliğinde doğru sıra

1. Kanıtı korumak için mevcut durumun bir kopyasını alın; ardından gerekiyorsa siteyi bakım moduna alın.
2. Bulaşmanın ne zaman başladığını tahmin edin ve o tarihten önceki temiz bir yedek olup olmadığını kontrol edin.
3. Saldırganın giriş noktasını bulun: güncellenmemiş bir eklenti, zayıf şifre, sızmış bir FTP hesabı ya da açık bir yükleme formu.
4. Siteyi temiz yedekten geri yükleyin ya da bulaşmış dosyaları temizleyin; çekirdek dosyaları resmi kaynaktan yeniden yükleyin.
5. Tüm yönetici, veritabanı, FTP, barındırma ve API şifrelerini değiştirin; tanımadığınız kullanıcıları silin.
6. Giriş noktasını kapatın; açık kapatılmadan yapılan temizlik birkaç gün içinde tekrar eder.
7. Search Console'daki güvenlik sorunları raporunu kontrol edin, sorun giderildiyse incelemeyi isteyin.
8. Olayı, tarihlerini ve alınan önlemleri kayıt altına alın; kişisel veri etkilendiyse yasal bildirim yükümlülüklerini bir hukukçuyla değerlendirin.

Çalışma süresi (uptime) izleme nasıl kurulur?

Çalışma süresi izleme, sitenizin dışarıdan belirli aralıklarla (genellikle her 1-5 dakikada bir) kontrol edilmesi ve erişilemediğinde ya da beklenen içeriği göstermediğinde sorumlu kişilere anında bildirim gönderilmesidir. Amacı kesintiyi müşteriden ya da satış ekibinden değil, ilk dakikalarda izleme sisteminden öğrenmektir. Özellikle mesai dışı ve hafta sonu kesintileri izleme olmadan saatlerce fark edilmeyebilir.

Sözleşmelerde sıkça görülen yüzdelerin pratikte ne kadar kesintiye karşılık geldiğini bilmek, teklifleri doğru okumanızı sağlar. Aşağıdaki tablo 30 günlük bir ay (43.200 dakika) ve 365 günlük bir yıl (525.600 dakika) üzerinden hesaplanmıştır.

İzlemeyi kurmanın adımları

1. Dış bir izleme servisi seçin; sitenin kendi sunucusunda çalışan bir izleme, sunucu çöktüğünde sizi uyaramaz.
2. Yalnızca ana sayfayı değil, iletişim formu, ürün listesi ve ödeme adımı gibi iş açısından kritik sayfaları ayrı ayrı ekleyin.
3. Durum kodu kontrolüne ek olarak anahtar kelime kontrolü kurun: sayfa "200 OK" dönerken boş bir ekran ya da veritabanı hata mesajı gösterebilir. Sayfada mutlaka bulunması gereken bir ifadeyi (ör. firma adınız ya da "Sepete ekle") arayın.
4. Kontrolün birden fazla konumdan yapılmasını sağlayın; tek bir noktadaki ağ sorunu yanlış alarm üretmesin.
5. Bildirimi en az iki kişiye ve iki kanala (e-posta ile birlikte SMS ya da anlık mesaj) gönderin.
6. Aynı panelde SSL ve alan adı bitiş tarihi uyarılarını da açın.
7. Her kesintiden sonra nedenini ve süresini kayda geçirin; aylık raporda bu kayıtlar görünmelidir.

Barındırma SLA'sındaki %99,9 ile bakım SLA'sı aynı şey mi?

Hayır. Barındırma firmasının çalışma süresi taahhüdü yalnızca sunucunun ayakta olmasını kapsar; siteniz bir eklenti hatası yüzünden boş sayfa gösteriyorsa sunucu "çalışıyor" sayılır. Bakım SLA'sı ise sorun bildirildikten ya da izleme alarm verdikten sonra bakım ekibinin ne kadar sürede yanıt vereceğini ve çözüm için çalışmaya başlayacağını tanımlar. Sözleşmeyi okurken planlı bakım çalışmalarının hesaba dahil edilip edilmediğine ve oranın aylık mı yıllık mı hesaplandığına da bakın; yıllık %99,9, tek bir ayda saatlerce kesintiye izin verebilir.

SSL sertifikası ve alan adı yenilemesi nasıl takip edilir?

SSL sertifikası ve alan adı, bitiş tarihleri ayrı ayrı izlenerek, otomatik yenileme açık tutularak ve yenilemenin bağlı olduğu ödeme yöntemi ile iletişim e-postası düzenli kontrol edilerek takip edilir. İkisi de sessizce biter: sertifika bittiğinde tarayıcılar ziyaretçiye tam sayfa güvenlik uyarısı gösterir, alan adı bittiğinde ise yalnızca site değil aynı alan adını kullanan kurumsal e-posta da durur. Alan adı, barındırma ve SSL'in temel kavramlarını domain, hosting ve SSL altyapı rehberimizde anlattık; burada bakım sırasında neyin izleneceğine odaklanıyoruz.

SSL sertifika süreleri neden kısalıyor?

Tarayıcı üreticileri ve sertifika otoritelerinin oluşturduğu CA/Browser Forum, Nisan 2025'te kabul edilen SC-081v3 kararıyla herkese açık SSL/TLS sertifikalarının azami geçerlilik süresini kademeli olarak kısalttı. Takvim şöyle: 15 Mart 2026'dan itibaren 398 günden 200 güne, 15 Mart 2027'den itibaren 100 güne, 15 Mart 2029'dan itibaren 47 güne. Ücretsiz sertifika sağlayıcısı Let's Encrypt de azami sertifika ömrünü Şubat 2028'e kadar 45 güne indirmeyi planladığını duyurdu.

Bunun bakım açısından anlamı açık: yılda bir kez elle sertifika yenileme dönemi kapanıyor. Ayrıca Let's Encrypt, sertifika bitiş uyarısı e-postalarını 4 Haziran 2025'te sonlandırdı. Otomatik yenileme bir nedenle çalışmazsa (sunucu taşındı, DNS değişti, yenileme görevi bozuldu) artık sizi e-postayla uyaran bir mekanizma yok; bitiş tarihini bağımsız bir izleme aracıyla takip etmek gerekiyor.

Alan adı yenilemesinde en sık görülen tuzaklar

• Kayıtlı e-posta eski bir çalışana ait: Yenileme hatırlatmaları kimsenin okumadığı bir kutuya gider.
• Kartın süresi dolmuş: Otomatik yenileme açık görünür ama ödeme alınamadığı için gerçekleşmez.
• Alan adı başkasının hesabında: Siteyi yapan firmanın ya da ayrılan bir çalışanın kişisel hesabında kayıtlı alan adını yenilemek ya da taşımak haftalar sürebilir.
• Otomatik yenileme kapalı: Özellikle kampanyayla alınmış alan adlarında ilk dönem sonunda otomatik yenileme kapalı kalabilir.
• Yan alan adları unutulmuş: Markanızın farklı uzantıları (.com, .com.tr gibi) ana siteye yönlendiriliyorsa onların süresi de takip edilmelidir; boşa düşen bir uzantı başkası tarafından alınabilir.
• Ek süreye güvenmek: Kayıt kuruluşlarının bitişten sonra tanıdığı ek süreler sınırlıdır ve geri alma ücreti normal yenilemeden yüksek olabilir.

Alan adının bitiş tarihini kayıt kuruluşunuzun panelinden kontrol edin ve takvime en az 60 ve 30 gün önce hatırlatma koyun. Markanızın diğer uzantılardaki (.com, .com.tr, .net gibi) durumunu görmek ve boşta kalan bir uzantıyı başkası almadan önce fark etmek için aşağıdaki domain sorgulama aracından yararlanabilirsiniz.

Hız ve Core Web Vitals bakımda nasıl izlenir?

Hız bakımı, sitenin gerçek kullanıcı verisiyle ölçülen Core Web Vitals değerlerinin her ay kontrol edilmesi, bozulma görüldüğünde nedeninin (yeni görsel, yeni eklenti, yeni pazarlama etiketi, sunucu yükü) bulunup giderilmesidir. Hız optimizasyonu bir kez yapılıp biten bir proje değildir; site her içerik ve her yeni araçla yavaş yavaş ağırlaşır. Bakımın görevi bu kaymayı erken yakalamaktır.

Google'ın web.dev üzerindeki Core Web Vitals tanımına göre bir sayfanın iyi sayılması için üç ölçütün de sayfa yüklemelerinin 75. yüzdelik diliminde aşağıdaki eşikleri karşılaması gerekir. INP, 2024'te etkileşim ölçütü olarak FID'in yerini aldı.

Site hızı neden zamanla bozulur?

• Pazarlama ekibinin yüklediği yüksek çözünürlüklü görseller ve videolar.
• Her biri kendi JavaScript dosyasını getiren yeni eklentiler, uygulamalar ve sohbet araçları.
• Reklam ve analiz için eklenen, zamanla sayısı artan etiketler (pixel, dönüşüm kodları, ısı haritası araçları).
• Veritabanında biriken eski sayfa revizyonları, geçici kayıtlar ve spam yorumlar.
• Bir güncellemeyle sıfırlanan ya da bozulan önbellek ayarları.
• Trafik büyürken aynı kalan sunucu kaynakları.

Aylık hız kontrolü nasıl yapılır?

1. Search Console'daki Core Web Vitals raporunu açın; "zayıf" ya da "iyileştirme gerekli" grubuna yeni URL düşüp düşmediğine bakın.
2. Ana sayfa, bir kategori ya da hizmet sayfası ve bir ürün ya da blog sayfası olmak üzere en az üç şablonu PageSpeed Insights ile ölçün.
3. Saha verisi (gerçek kullanıcılar) ile laboratuvar verisini ayrı okuyun; sıralamayı ve kullanıcı deneyimini saha verisi yansıtır.
4. Sonuçları önceki ayın değerleriyle aynı tabloda karşılaştırın; tek bir ölçümden değil eğilimden karar verin.
5. Kötüleşme varsa o ay yapılan değişiklikleri (yeni eklenti, yeni etiket, yeni görsel) listeleyin; neden çoğunlukla oradadır.

Core Web Vitals değerlerinin sıralamayla ilişkisini, PageSpeed Insights raporunun nasıl okunacağını ve teknik iyileştirmeleri site hızı ve Core Web Vitals rehberimizde ayrıntılı bulabilirsiniz.

Kırık bağlantılar, 404 hataları ve SEO sağlık kontrolü nasıl yapılır?

Kırık bağlantılar ve 404 hataları her ay bir site taraması ve Search Console raporlarıyla bulunur; değer taşıyan eski adresler en yakın karşılığına kalıcı (301) yönlendirmeyle bağlanır, karşılığı olmayanlar ise dürüstçe 404 olarak bırakılır. SEO sağlık kontrolü de aynı ziyarette yapılır: dizine ekleme durumu, site haritası, robots.txt, canonical etiketleri ve yapısal veri hataları gözden geçirilir. Bu kontrol, organik trafiğin sessizce erimesini önleyen en ucuz sigortadır.

Google'ın HTTP durum kodları belgesine göre 4xx kodu dönen adresler dizine eklenmez, daha önce dizinde olanlar da zamanla dizinden çıkarılır. Sayfanın "200 OK" dönüp içeriğinin boş ya da hata mesajı olması ise Search Console'da "soft 404" olarak raporlanır. Yani sorun yalnızca kullanıcının kırık sayfaya düşmesi değil; o adrese gelen bağlantı değerinin ve trafiğin de kaybolmasıdır.

404 hataları nereden gelir?

• Silinen ya da adı değiştirilen ürün, kategori ve hizmet sayfaları.
• Menüde, alt bilgide ya da eski blog yazılarında unutulan iç bağlantılar.
• Başka sitelerin sizin eski adreslerinize verdiği bağlantılar.
• Platform değişikliğinde yeni adres yapısına taşınmayan sayfalar.
• Kampanya bitince kaldırılan açılış sayfalarına giden reklam ve e-posta bağlantıları.

Hangi 404 yönlendirilmeli, hangisi bırakılmalı?

Dış bağlantı alan, hâlâ trafik getiren ya da reklamlarda kullanılan bir adres kaldırıldıysa, içeriğe en yakın sayfaya 301 yönlendirmesi yapın: eski ürün yeni modeline, kaldırılan hizmet ana hizmet sayfasına. Gerçekten karşılığı olmayan, trafik almayan adresleri 404 ya da 410 olarak bırakmak doğrudur. Bütün kırık adresleri toplu olarak ana sayfaya yönlendirmek kolay bir çözüm gibi görünür ama Google bunları çoğu zaman soft 404 sayar ve ziyaretçi de aradığını bulamaz. Yönlendirmeleri bir tabloda tutun; zincirleme yönlendirme (A'dan B'ye, B'den C'ye) oluştuğunda tek adıma indirin.

Aylık SEO sağlık kontrol listesi

• Search Console'da "Sayfalar" raporunda dizine eklenmeyen sayfa sayısında ani artış var mı?
• Site haritası güncel mi, hata veriyor mu, silinen sayfaları hâlâ içeriyor mu?
• robots.txt dosyasında ya da sayfa etiketlerinde yanlışlıkla bırakılmış bir "noindex" ya da engelleme var mı?
• Canonical etiketleri doğru adresi gösteriyor mu; http ile https, www ile www'suz sürümler tek adrese mi toplanıyor?
• Başlık ve açıklama etiketi boş ya da kopya olan yeni sayfalar eklenmiş mi?
• Yapısal veri (ürün, SSS, yerel işletme) raporlarında yeni hata var mı?
• Güvenlik sorunları ve elle işlem raporları temiz mi?

Search Console raporlarını hiç kullanmadıysanız Google Search Console rehberimiz iyi bir başlangıçtır. Yılda bir ya da büyük değişikliklerden sonra ise aylık kontrolün ötesine geçen kapsamlı bir teknik SEO denetimi yapılmasını öneririz.

Formlar ve e-posta teslimi neden düzenli test edilmeli?

Formlar ve bildirim e-postaları, hata mesajı vermeden bozulabildikleri için düzenli test edilmelidir: ziyaretçi formu doldurur, "teşekkürler" mesajını görür, ama talep hiçbir zaman satış ekibinin kutusuna ulaşmaz. Bu tür bir arıza haftalarca fark edilmeyebilir, çünkü bozuk bir form şikâyet üretmez, yalnızca sessizlik üretir. B2B işletmelerde ve hizmet firmalarında sitenin en değerli parçası çoğu zaman formdur.

Formlar neden sessizce bozulur?

• Formun e-posta göndermek için kullandığı hesabın şifresi değişti ya da hesap kapatıldı.
• Kurumsal e-posta sağlayıcısı değişti, ama sitenin gönderim ayarları eski sağlayıcıya göre kaldı.
• Alan adının SPF, DKIM ya da DMARC kayıtları eksik veya hatalı; bildirimler spam klasörüne düşüyor ya da reddediliyor.
• Spam koruması (reCAPTCHA gibi) anahtarının süresi doldu ya da yanlış alan adına tanımlı.
• Bir eklenti güncellemesi form eklentisiyle çakıştı.
• Bildirimin gittiği adres işten ayrılan bir çalışana ait.
• Formdan CRM, WhatsApp ya da tablo programına giden entegrasyon koptu.

E-posta kimlik doğrulaması artık bir tercih değil. Google'ın e-posta gönderen yönergeleri, Gmail adreslerine gönderim yapan tüm göndericilerden SPF veya DKIM kurmasını, günde 5.000'den fazla ileti gönderen toplu göndericilerden ise SPF, DKIM ve DMARC'ın üçünü birden istiyor. Sitenizin bildirim e-postaları da bu kurallara tabi olan alan adınızdan çıkar; DNS kayıtlarında yapılan bir değişiklik form bildirimlerini doğrudan etkileyebilir. Kurumsal e-postanın temel kurulumunu kurumsal e-posta rehberimizde anlattık.

Form testi adım adım

1. Sitedeki tüm formların listesini çıkarın: iletişim, teklif, randevu, bülten, iş başvurusu, bayi başvurusu.
2. Her formu masaüstünden ve mobilden, farklı bir e-posta adresiyle gerçekten doldurun.
3. Bildirim e-postasının doğru kişiye, makul sürede ve gelen kutusuna (spam değil) ulaştığını kontrol edin.
4. Formu dolduran kişiye giden otomatik yanıtın çalıştığına ve içeriğinin güncel olduğuna bakın.
5. Kaydın CRM'e, tabloya ya da WhatsApp bildirimine düştüğünü doğrulayın.
6. Analiz aracında form gönderim olayının (ör. GA4'te lead olayı) tetiklendiğini kontrol edin.
7. KVKK aydınlatma bağlantısının ve varsa ayrı açık rıza kutusunun doğru metne gittiğini kontrol edin.
8. Test kayıtlarını silin ya da test olarak işaretleyin ki satış raporlarını kirletmesin.

Bu testi her ay ve her güncellemeden sonra tekrarlayın. Bir formun bozuk kaldığı her gün, o günün potansiyel taleplerinin kaybı demektir.

İçerik güncellemeleri bakımın parçası mıdır?

Evet, ama sınırı net çizilmiş biçimde: mevcut sayfalardaki metin, görsel, iletişim bilgisi, kampanya ve belge değişiklikleri bakımın parçasıdır; yeni içerik üretmek, metin yazarlığı, çeviri ya da yeni sayfa tasarlamak ise ayrı hizmetlerdir. Eski içerik, bozuk bir sayfa kadar güven kaybettirir. Ziyaretçi yanlış bir telefon numarası ya da geçmiş bir kampanya gördüğünde sitenin terk edildiğini düşünür.

Hangi içerikler en hızlı eskir?

• Telefon, adres, harita konumu, çalışma saatleri ve WhatsApp hattı.
• Fiyat, kampanya ve indirim duyuruları; süresi dolmuş geri sayım şeritleri.
• Ekip sayfası, yönetici isimleri ve unvanlar.
• Kalite belgeleri, sertifikalar ve bunların geçerlilik tarihleri.
• Başlığında ya da metninde yıl geçen yazılar ve "yeni" diye anılan ürünler.
• Sosyal medya bağlantıları ve kapatılmış hesaplar.
• Referans ve proje listeleri, ürün stok ve teslim süresi bilgileri.
• Katalog ve teknik föy PDF'leri.

İçerik güncellemesini bakım paketine nasıl yazmalısınız?

İçerik işlerini sözleşmede belirsiz bırakmak, iki tarafı da zorlar. Pratik bir yöntem, bakım paketine aylık belirli sayıda ya da belirli süre içerik güncellemesi koymak ve neyin bu kapsama girdiğini örneklerle yazmaktır. Mevcut bir sayfadaki metni değiştirmek, banner görselini yenilemek, PDF kataloğu güncellemek, ekip sayfasına kişi eklemek kapsam içinde olabilir. Sıfırdan yeni bir hizmet sayfası yazmak, fotoğraf çekimi, çok dilli içerik ya da yeni bir kampanya açılış sayfası tasarlamak ise ayrı tekliflenir. Üç ayda bir yapılacak kısa bir içerik taraması, hangi sayfaların güncellenmesi gerektiğini listeleyen bir rapor üretmelidir; güncelleme kararını ve metnin doğruluğunu ise işletme verir.

İçerik güncellenirken arama motorları için işaretlemelerin de güncel kalması gerekir: ürün fiyatı, stok durumu ya da işletme çalışma saati yapısal veriyle de işaretliyse ikisi birbirini tutmalıdır. Sayfadaki bilgi değiştiğinde işaretleme eski kalırsa arama sonuçlarında yanlış fiyat ya da saat görünebilir.

KVKK metinleri ve erişilebilirlik neden bakım takvimine girer?

KVKK metinleri ve erişilebilirlik bakım takvimine girer, çünkü ikisi de sitede yapılan her değişiklikle bozulabilir: yeni bir form, sohbet aracı ya da reklam etiketi eklendiğinde aydınlatma metni ve çerez envanteri artık gerçeği yansıtmaz; yeni yüklenen görseller ve sayfalar da erişilebilirlik kurallarını farkında olmadan ihlal edebilir. Yasal metinlerin içeriği hukukçunun işidir, ama bu metinlerin sitedeki gerçek veri akışıyla uyumlu kalmasını izlemek bakımın işidir.

Önemli not: Bu bölüm genel bilgilendirme amaçlıdır, hukuki tavsiye değildir. Sitenize özel aydınlatma, açık rıza ve çerez metinlerinin son halini bir avukat ya da KVKK danışmanıyla birlikte belirleyin.

KVKK tarafında bakım neyi kontrol eder?

Kişisel Verileri Koruma Kurulu'nun 18.02.2026 tarihli ve 2026/347 sayılı ilke kararı, 24 Mart 2026'da Resmî Gazete'de yayımlandı. Kurumun kamuoyu duyurusuna göre aydınlatma metni ile açık rıza metni ayrı ayrı düzenlenmeli, aydınlatma veri işlemeye başlamadan önce yapılmalı ve aydınlatma metni için kişiden onay değil yalnızca okunduğuna dair beyan alınabilir. Formlarında tek kutuyla "okudum ve onaylıyorum" diyen sitelerin bu yapıyı gözden geçirmesi gerekir.

Bakım rutininde KVKK açısından şunlar kontrol edilir:

• Siteye son üç ayda eklenen form, sohbet aracı, analiz ya da reklam etiketi var mı; varsa aydınlatma ve çerez metinlerinde yer alıyor mu?
• Çerez bandı zorunlu olmayan çerezleri onay gelmeden çalıştırıyor mu?
• Formlarda aydınlatma bağlantısı ile isteğe bağlı açık rıza kutusu birbirinden ayrı mı?
• Form kayıtları ve başvurular için bir saklama ve silme rutini işliyor mu?
• Yönetim paneline erişen kullanıcılar ve yetkileri güncel mi?

Bir e-ticaret sitesinde bulunması gereken diğer yasal metinleri e-ticaret sözleşmeleri ve yasal metinler rehberimizde listeledik; çerez metninizi hazırlamak ya da güncellemek için çerez politikası oluşturucuyu başlangıç taslağı olarak kullanabilirsiniz.

Erişilebilirlik tarafında bakım neyi kontrol eder?

Erişilebilirlik, görme, işitme, hareket ya da bilişsel farklılığı olan kişilerin sitenizi kullanabilmesidir ve çoğunlukla içerik eklendikçe bozulur. Avrupa Birliği'nde 2019/882 sayılı Direktif ile getirilen Avrupa Erişilebilirlik Yasası 28 Haziran 2025'ten beri uygulanıyor ve AB'deki tüketicilere hizmet veren e-ticaret sitelerini kapsıyor; hizmet sunan mikro işletmeler ise bu yükümlülüklerden muaf tutuluyor. AB'ye doğrudan satış yapıyorsanız kendi durumunuzu bir uzmanla değerlendirmeniz gerekir. Türkiye'de satış yapan bir site için de erişilebilirlik, daha fazla müşteriye ulaşmanın ve formların daha kolay doldurulmasının yoludur.

Üç ayda bir yapılacak hızlı bir erişilebilirlik kontrolü şunları kapsar: yeni görsellerde anlamlı alternatif metin olup olmadığı, metin ve arka plan kontrastı, sitenin yalnızca klavyeyle gezilebilmesi, form alanlarının etiketli olması, hata mesajlarının yalnızca renkle değil metinle de verilmesi ve videolarda altyazı. Ölçütlerin ayrıntısını ve test yöntemlerini web erişilebilirliği rehberimizde anlattık.

Haftalık, aylık ve yıllık bakım takvimi nasıl olmalı?

İyi bir bakım takvimi işleri sıklığa göre beş katmana ayırır: sürekli çalışan otomatik izleme, haftalık güncelleme ve yedek kontrolü, aylık performans, form ve SEO kontrolü, üç ayda bir yapılan derin kontroller ve yılda bir yapılan stratejik gözden geçirme. Her işin yanında sorumlunun (bakım ekibi mi, işletme mi) yazılı olması, takvimi kâğıt üzerinde kalmaktan kurtarır. Aşağıdaki tabloyu kendi sitenize göre uyarlayarak kullanabilirsiniz.

Kampanya dönemlerinde değişiklik dondurma

Satışın yoğunlaştığı dönemlerden önce büyük güncellemeleri durdurmak, bakım takviminin en çok ihmal edilen kuralıdır. Kasım ayındaki indirim günleri, yılbaşı ya da sektörünüzün sezonu gibi dönemlerden bir-iki hafta önce sitede büyük sürüm güncellemesi, tema değişikliği ya da yeni eklenti kurulumu yapılmamalıdır. Bu sürede yalnızca kritik güvenlik yamaları uygulanır. Dondurma başlamadan önce tam yedek alınır, ödeme ve sepet akışları test edilir, sunucu kaynakları beklenen trafiğe göre gözden geçirilir. Kampanya hazırlığının diğer adımlarını Efsane Cuma ve Black Friday hazırlık rehberimizde bulabilirsiniz.

Bakım takvimini kim tutmalı?

Bakımı dışarıdan alsanız bile işletmede takvimin sahibi olan bir kişi bulunmalıdır. Bu kişinin teknik olması gerekmez; aylık raporu okuyup onay bekleyen işlere karar vermesi, alan adı ve lisans yenileme tarihlerini bilmesi ve içerik değişikliklerini bakım ekibine iletmesi yeterlidir. Sorumluluğun iki taraf arasında boşa düştüğü yer, genellikle "onlar takip ediyordur" diye düşünülen yerdir.

WordPress ile ikas ve Shopify'da bakım nasıl farklılaşır?

WordPress gibi kendi sunucunuzda çalışan sistemlerde bakımın tamamı sizin ya da bakım ekibinizin sorumluluğundadır; ikas ve Shopify gibi hazır (SaaS) platformlarda ise sunucu, çekirdek yazılım ve altyapı güvenliği platformun işidir, bakım tema, uygulama, içerik, veri ve entegrasyonlara odaklanır. Bu fark bakımın yükünü ciddi ölçüde azaltır ama sıfırlamaz. Hazır platform kullanan işletmelerin en sık yaptığı hata, "platform her şeyi hallediyor" varsayımıyla tema ve uygulama tarafını kendi haline bırakmaktır.

WordPress'te bakım neden daha yoğundur?

WordPress'in esnekliği, onlarca bağımsız geliştiricinin yazdığı eklentilerden gelir; bakım yükü de aynı yerden doğar. Her eklenti ayrı bir güncelleme takvimi, ayrı bir güvenlik geçmişi ve diğer eklentilerle ayrı bir uyum riski demektir. Bunun üzerine sunucu, PHP sürümü, veritabanı ve önbellek katmanları eklenir. WooCommerce ile e-ticaret yapan bir sitede ödeme, kargo ve fatura eklentileri de devreye girdiği için haftalık güncelleme disiplini neredeyse zorunludur. İki altyapının bakım ve toplam maliyet açısından farkını ikas mı WooCommerce mu karşılaştırmamızda ele aldık.

Shopify'da tema güncellemesi nasıl işler?

Shopify'ın tema güncelleme belgesine göre tema geliştiricisinin yayımladığı yeni sürümler canlı temanızı kendiliğinden değiştirmez; güncelleme, adının başında "Updated copy of" ifadesi bulunan bir taslak tema olarak kitaplığınıza eklenir ve siz yayınlayana kadar canlı mağaza değişmez. Shopify'ın otomatik uyguladığı güncellemeler yalnızca hata ve güvenlik düzeltmeleridir. Tema editörüyle yapılan ayarlar yeni sürüme taşınır; koda doğrudan yapılan değişiklikler ise yeni sürümle çakışmıyorsa taşınır, çakışıyorsa elle aktarılması gerekir. Shopify bu yüzden güncellemeden önce özelleştirilmiş kodun bir kopyasının saklanmasını öneriyor.

Uygulamalar da ayrı bir bakım kalemidir. Shopify'ın uygulama kaldırma rehberi, bazı uygulamaların temaya eklediği kodun uygulama kaldırıldığında otomatik olarak silinmediği konusunda uyarıyor. Denenip bırakılan her uygulama, temada hız ve hata riski taşıyan bir iz bırakabilir; bakımda üç ayda bir uygulama listesi ve temadaki artık kodlar gözden geçirilmelidir. Bir uygulamayı kaldırmadan önce geliştiricisinin kaldırma talimatlarına bakmak bu izi azaltır.

ikas'ta bakım nelere odaklanır?

ikas'ta sunucu ve platform yazılımının güncellenmesi ikas'ın sorumluluğundadır; mağaza sahibinin bakım listesi tema, içerik, veri ve entegrasyon tarafında yoğunlaşır. Özel tema kodu kullanan mağazalarda tema değişiklikleri önce kopya üzerinde denenmeli, hazır temada ise tema editörüyle yapılan değişikliklerin mobil görünümü bozmadığı kontrol edilmelidir. Tema editörünün sınırlarını ve özel tasarımın ne zaman gerektiğini ikas tema editörü rehberimizde anlattık. Bunun dışında aylık olarak şu kalemlere bakılması önerilir:

• Kurulu uygulamaların hâlâ kullanılıp kullanılmadığı ve verdikleri izinler.
• Silinen ya da adı değişen ürün ve kategoriler için yönlendirmelerin eklenip eklenmediği.
• Ödeme, kargo, e-fatura ve pazaryeri entegrasyonlarının hatasız çalıştığı; sipariş ve stok aktarımında gecikme olup olmadığı.
• Personel hesaplarının ve yetkilerin güncelliği, ayrılan çalışanların erişiminin kapatılması.
• Görsel boyutları, eklenen pazarlama etiketleri ve sayfa hızı.

ikas partneri olarak bu işleri mağaza sahibiyle birlikte nasıl yürüttüğümüzü ikas partneri sayfamızda görebilirsiniz.

Bakım sözleşmesinde nelere bakılmalı?

Bir bakım sözleşmesinde en çok şu maddelere bakılmalıdır: kapsamın ve kapsam dışı işlerin açık listesi, yanıt ve çözüm sürelerini tanımlayan SLA, öncelik seviyeleri, çalışma saatleri, raporlama, yedek politikası, değişiklik onayı, güvenlik olayı prosedürü, kişisel verilerin korunması, hesapların ve erişimin kimde olduğu, fesih ve devir koşulları. Bu maddelerin her biri, bir sorun yaşandığında tarafların neye göre hareket edeceğini belirler. Sözleşme ne kadar kısa olursa olsun, belirsizlik bırakmaması uzunluğundan daha önemlidir.

Önemli not: Aşağıdaki maddeler genel bilgilendirme amaçlıdır. Sözleşmenizin son halini, işletmenize özgü riskleri bilen bir avukatla birlikte belirleyin.

Yanıt süresi ile çözüm süresi aynı şey değildir

SLA maddelerinde en sık karıştırılan iki kavram yanıt ve çözüm süresidir. Yanıt süresi, bildiriminize bir uzmanın dönüş yapıp çalışmaya başlaması için geçen süredir; çözüm süresi ise sorunun giderilmesine kadar geçen süredir ve sorunun niteliğine bağlı olduğu için genellikle taahhüt edilmez ya da hedef olarak yazılır. Öncelik seviyelerini örneklerle tanımlamak, her iki taraf için de beklentiyi netleştirir. Aşağıdaki süreler yalnızca örnektir; sizin için doğru süreler sitenin iş açısından kritikliğine göre belirlenir.

Hesaplar ve erişim kimde olmalı?

Sitenizle ilgili tüm hesapların sahibi işletmeniz olmalı, bakım ekibi bu hesaplara kendi kullanıcısıyla, sınırlı yetkiyle erişmelidir. Alan adının, barındırma ya da platform hesabının, Google Analytics, Search Console, Google İşletme Profili, Meta işletme hesabı, kurumsal e-posta yönetim paneli ve ödeme altyapısının işletme adına kayıtlı olması ve en üst yetkinin işletmede kalması, bakım firmasını değiştirdiğinizde işlerin aksamamasını sağlar. Şifre paylaşmak yerine her platformun kullanıcı ekleme özelliğini kullanın; böylece kimin ne yaptığı kayıt altında kalır ve ayrılıkta yalnızca o kullanıcıyı kapatmanız yeter. Hesapların, alan adının ve iş verisinin sizin adınıza olması, bakım ilişkisinin en temel güvencesidir.

Sözleşme taslağınızı oluştururken web yazılım hizmet sözleşmesi oluşturucusundan yararlanabilir, çıkan taslağı avukatınızla gözden geçirebilirsiniz.

Web sitesi bakım ücreti hangi modellerle belirlenir?

Web sitesi bakım ücreti genellikle dört modelden biriyle belirlenir: kapsamı sabit aylık paket, her ay belirli saatin kullanılabildiği saat havuzu, her işin ayrı fiyatlandığı iş başına ücretlendirme ve sabit bir temel paketle saat havuzunu birleştiren karma model. Hangisinin size uygun olduğu, sitenizin ne sıklıkla değiştiğine ve kesintinin size maliyetine bağlıdır. Tutarlar sitenin yapısına, kapsamına ve SLA seviyesine göre çok değiştiği için burada rakam vermiyoruz; teklifleri aynı kapsam listesi üzerinden karşılaştırmanız daha sağlıklı sonuç verir.

Bakım ücretini neler belirler?

• Altyapı türü: kendi sunucunuzdaki WordPress, hazır platform ya da özel yazılım.
• Eklenti, uygulama ve entegrasyon sayısı.
• Sitenin e-ticaret, üyelik ya da müşteri paneli gibi işlem yapan bölümleri olup olmadığı.
• Talep edilen yanıt süreleri ve mesai dışı destek.
• Yedek sıklığı ve saklama süresi.
• İçerik güncellemesinin pakete ne kadar dahil olduğu.
• Raporlamanın ayrıntısı ve toplantı sıklığı.
• Sitenin mevcut durumu: uzun süre bakımsız kalmış bir sitenin ilk ayı genellikle temizlik ve envanter çıkarma işidir.

Teklifleri nasıl karşılaştırmalısınız?

Fiyatı düşük bir bakım paketi çoğu zaman yalnızca "güncelleme düğmesine basmak" anlamına gelir; test ortamı, geri yükleme testi, form testi ve rapor yoksa bu fiyatın karşılığı da sınırlıdır. Teklifleri karşılaştırırken yukarıdaki kapsam tablosunu her firmaya gönderin ve her kalemin karşısına "dahil", "hariç" ya da "ek ücretli" yazmalarını isteyin. Böylece aynı işin fiyatlarını karşılaştırmış olursunuz. Site kurulumu ve yenileme maliyetlerinin genel çerçevesini web tasarım fiyatları rehberimizde bulabilirsiniz.

Bakımsızlığın maliyeti nedir? Dört örnek senaryo

Bakımsızlığın maliyeti; kesinti süresince kaybedilen satış ya da talepler, boşa giden reklam harcaması, acil müdahale ve temizlik masrafı ile kaybedilen arama görünürlüğünün toparlanma süresinin toplamıdır. Bu maliyet çoğu zaman bir yıllık bakım bütçesini tek bir olayda aşar, ama faturası "bakım" başlığıyla gelmediği için görünmez kalır. Kendi rakamlarınızla hesap yapmak için basit bir formül kullanabilirsiniz:

Olay maliyeti = (saatlik ortalama ciro ya da talep değeri × fark edilmeyen kesinti süresi × kayıp oranı) + boşa giden reklam harcaması + müdahale ve toparlanma maliyeti

Aşağıdaki senaryolardaki tüm rakamlar örnektir; yalnızca yöntemi göstermek için seçilmiştir. Kendi sipariş, talep ve marj verilerinizi yerine koyarak hesaplayın.

Senaryo 1: SSL sertifikası hafta sonu doldu

Kendi sunucusunda çalışan bir e-ticaret sitesinde otomatik sertifika yenilemesi, birkaç ay önce yapılan bir sunucu taşımasından sonra sessizce çalışmayı bırakmış olsun. Sertifika cuma akşamı bitiyor, sorun pazartesi sabahı fark ediliyor: yaklaşık 60 saat, yani 2,5 gün. Site günde ortalama 40 sipariş alıyor, ortalama sepet 1.200 TL. Tarayıcıların tam sayfa güvenlik uyarısı yüzünden ziyaretçilerin %80'inin vazgeçtiğini varsayalım.

• Beklenen sipariş: 40 × 2,5 = 100 sipariş.
• Kaybedilen sipariş: 100 × 0,80 = 80 sipariş.
• Kaybedilen ciro: 80 × 1.200 TL = 96.000 TL.
• Bu sürede durdurulmayan reklamlar: günlük 2.500 TL × 2,5 gün = 6.250 TL, büyük kısmı uyarı ekranına harcandı.

Önleyici iş: bağımsız bir izleme aracında sertifika bitiş uyarısı ve dakikalık çalışma süresi kontrolü.

Senaryo 2: Kayseri'deki bir makine üreticisinin teklif formu üç hafta sessiz kaldı

Kayseri'de endüstriyel ekipman üreten bir firma, yurt içi ve yurt dışı taleplerinin çoğunu sitesindeki teklif formundan alıyor olsun. Kurumsal e-posta sağlayıcısı değiştirildiğinde formun gönderim ayarı güncellenmemiş; ziyaretçi teşekkür mesajını görüyor ama talep kimseye ulaşmıyor. Sorun, bir müşterinin telefonla "teklif bekliyoruz" demesiyle üç hafta sonra fark ediliyor. Firma ayda ortalama 12 teklif talebi alıyor, taleplerin %15'i siparişe dönüyor, ortalama sipariş tutarı 250.000 TL ve brüt kâr marjı %20.

• Üç haftada kaçan talep: yaklaşık 9.
• Talep başına beklenen brüt kâr: 0,15 × 250.000 TL × 0,20 = 7.500 TL.
• Kaçan beklenen brüt kâr: 9 × 7.500 TL = 67.500 TL.

Bu hesap, cevapsız kaldığı için rakibe yönelen müşterilerin ileride getireceği tekrar siparişleri içermiyor. Önleyici iş: aylık form testi ve e-posta altyapısı değiştiğinde zorunlu form kontrolü. Üretici firmaların sitelerinde formun ve ürün kataloğunun önemini B2B web sitesi tasarımı rehberimizde ayrıca ele aldık.

Senaryo 3: Güncellenmeyen bir eklentiden spam yönlendirmesi

Kurumsal bir hizmet sitesinde, bir yıldır güncellenmeyen bir form eklentisindeki açıktan siteye kötü amaçlı kod yerleştirilmiş olsun. Mobilden arama sonucuyla gelen ziyaretçiler kumar sitelerine yönlendiriliyor; site sahibi masaüstünden doğrudan girdiği için bir şey görmüyor. İki hafta sonra Google arama sonuçlarında uyarı çıkıyor ve organik trafik hızla düşüyor.

• Doğrudan maliyet: acil temizlik, şifrelerin yenilenmesi, açığın kapatılması ve Search Console incelemesi için planlı bakımdan pahalı acil müdahale.
• Dolaylı maliyet: uyarının kalkması ve trafiğin toparlanması sürecinde kaybedilen talepler; aylık 400 organik ziyaretten %2 dönüşümle 8 talep alan bir sitede, iki aylık toparlanma döneminde trafiğin yarıya inmesi yaklaşık 8 talebin kaybı demektir.
• Görünmeyen maliyet: yönlendirilen ziyaretçilerin markaya güveni.

Önleyici iş: haftalık güncelleme, günlük tarama ve eklenti envanterinin üç ayda bir temizlenmesi.

Senaryo 4: Alan adı yenilenmedi, e-posta da durdu

Alan adı, siteyi yıllar önce kuran ve artık çalışılmayan bir firmanın hesabında kayıtlı olsun; yenileme hatırlatmaları o firmanın kutusuna gidiyor. Alan adı süresi dolduğunda site kapanıyor ve aynı alan adını kullanan tüm kurumsal e-postalar da gelmemeye başlıyor. Alan adını geri almak için eski firmaya ulaşmak, kayıt kuruluşuyla yazışmak ve gerekirse geri alma ücreti ödemek gerekiyor; bu süre boyunca müşteri, tedarikçi ve banka yazışmaları kesintiye uğruyor.

Bu senaryonun maliyeti, kesinti süresinden çok kontrol kaybından gelir. Önleyici iş: alan adının işletme adına ve işletmenin kontrol ettiği bir hesapta kayıtlı olması, otomatik yenilemenin ve ödeme yönteminin yılda bir kontrol edilmesi.

Bakımı kendiniz mi yapmalısınız, hizmet mi almalısınız?

Bakımı kendiniz yapabilirsiniz; siteniz az değişiyorsa, hazır bir platformda çalışıyorsa ve ekibinizde her hafta düzenli olarak bir-iki saat ayırabilecek, test ortamı ve yedek kavramlarına hâkim biri varsa. Site satış ya da talep topluyorsa, WordPress gibi eklentili bir altyapıdaysa ya da kesintinin bir saati bile size ciddi kayıp yazdırıyorsa bakım hizmeti almak, riski uzmanlığı olan bir ekiple paylaşmanın daha güvenli yoludur. Aşağıdaki tablo bu kararı hızlandırır.

İkisinin arası da mümkündür: önleyici işleri (güncelleme, yedek, izleme, tarama) bir bakım ekibine bırakıp içerik güncellemelerini ekibinizde yapabilirsiniz. Bu durumda yetkilerin ayrılması ve kimin neyi değiştirdiğinin kayıt altında olması önem kazanır.

Kendiniz yapacaksanız: aylık bakım kontrol listesi

Aşağıdaki listeyi her ayın ilk iş gününde baştan sona uygulayın; işaretlediğiniz maddeleri tarihiyle birlikte basit bir tabloya not edin.

Üç ayda bir bu listeye geri yükleme testi, eklenti envanteri, erişilebilirlik kontrolü ve şifre denetimini ekleyin. Bir maddeyi üst üste iki ay atladığınızı fark ederseniz, bu bakımın dışarıdan alınması gerektiğinin işaretidir.

Web sitesi bakımında en sık yapılan hatalar nelerdir?

Web sitesi bakımında en sık yapılan hatalar; güncellemeleri test etmeden canlıda yapmak, yedeği hiç geri yüklemeyi denememek, kesintiyi müşteriden öğrenmek ve hesapları üçüncü kişilere bırakmaktır. Bu hataların ortak noktası, sorun çıkana kadar görünmemeleridir. Aşağıdaki listeyi kendi düzeninizle karşılaştırın:

• Canlıda toplu güncelleme: Tüm eklentileri aynı anda canlı sitede güncellemek; bir sorun çıktığında hangisinin neden olduğunu bulmak saatler alır.
• Test edilmemiş yedek: Yedeğin alındığını varsaymak ama geri yüklemeyi hiç denememek.
• Tek konumda yedek: Yedeğin yalnızca sitenin bulunduğu sunucuda durması.
• Güncellemeyi tamamen kapatmak: "Site bozulmasın" diye güncelleme yapmamak; bu, bilinen açıkları bilerek açık bırakmaktır.
• Staging ayarının canlıya taşınması: Test ortamındaki arama motoru engelinin canlı siteye geçmesi ve organik trafiğin haftalar içinde düşmesi.
• Formu test etmemek: Formun ekranda "gönderildi" demesini çalıştığının kanıtı saymak.
• Hesapların ajans ya da eski çalışan adına olması: Alan adı, barındırma ya da analiz hesabının işletmenin kontrolünde olmaması.
• Kampanya öncesi büyük değişiklik: İndirim döneminden birkaç gün önce tema değiştirmek ya da yeni eklenti kurmak.
• Raporsuz bakım: Ne yapıldığını gösteren aylık rapor istememek; yapılmayan işi fark etmenin başka yolu yoktur.
• Bakım ile geliştirmeyi karıştırmak: Yeni özellik taleplerini bakım saatinden karşılamaya çalışıp önleyici işlere zaman bırakmamak.

Alis Dijital'den nasıl destek alabilirsiniz?

Alis Dijital, Kayseri merkezli, 10 yıllık deneyime sahip bir e-ticaret, dijital pazarlama ve yazılım ajansıdır; ikas partneri ve Shopify Partner olarak çalışıyor, son 5 yılda 200+ markayla iş birliği yaptık. Yayındaki sitelerde güncelleme, yedek ve geri yükleme testi, izleme, form ve e-posta kontrolleri, hız ve SEO sağlık takibi ile aylık raporlamayı kapsayan bakım süreçleri kuruyoruz; hesapların, alan adının ve iş verisinin sizin adınıza kalmasını sürecin başında netleştiriyoruz.

Yeni bir site ya da mevcut sitenize eklenecek işlevler için özel yazılım ve web sitesi hizmetimizi inceleyebilirsiniz. Kocasinan'daki ofisimizde yüz yüze görüşmek isterseniz Kayseri web tasarım ve panel, entegrasyon ya da otomasyon ihtiyaçları için Kayseri yazılım geliştirme sayfalarımıza göz atabilirsiniz. Sitenizin mevcut durumunu konuşmak için iletişim sayfasından bize ulaşabilirsiniz.

Özet: 30 günde bakım düzenini kurmak için yol haritası

Bakımsız kalmış bir siteyi düzenli bakıma almak için her şeyi aynı anda yapmanız gerekmez. Aşağıdaki sırayı izlerseniz bir ay içinde sağlam bir temel kurarsınız:

1. 1. hafta, envanter: Alan adı, barındırma, platform, analiz ve e-posta hesaplarının kimin adına olduğunu listeleyin; işletme adına olmayanları devralın. Eklenti, uygulama, form ve entegrasyon listesini çıkarın.
2. 1. hafta, güvence: Tam yedek alın, bir kopyasını sunucu dışına taşıyın ve çalışma süresi ile SSL ve alan adı bitiş izlemesini kurun.
3. 2. hafta, güncelleme: Test ortamı oluşturun, bekleyen güncellemeleri orada deneyip canlıya alın; kullanılmayan eklentileri silin, PHP sürümünüzün destek tarihini kontrol edin.
4. 3. hafta, iş akışları: Tüm formları test edin, e-posta kimlik doğrulama kayıtlarını kontrol edin, kırık bağlantıları ve Search Console hatalarını giderin.
5. 4. hafta, ölçüm ve plan: Hız ölçümlerini kayda geçirin, KVKK ve içerik taramasını yapın, ardından yukarıdaki takvimi kendi sitenize göre doldurup her işin sorumlusunu yazın.
6. Sonrası: Her ay kontrol listesini uygulayın, üç ayda bir geri yükleme testi yapın, yılda bir sözleşmeyi ve kapsamı gözden geçirin.

Bakım, sitenin büyümesini sağlayan işlerin üzerinde durduğu zemindir. Reklam, SEO ya da yeni özellik yatırımı, ancak site her gün açık, hızlı ve formları çalışır durumdayken karşılığını verir.