Web Sitesi Bakımı ve Teknik Destek

Kısa cevap: Web sitesi bakımı, site yayına girdikten sonra güvenli ve çalışır kalması için yapılan düzenli teknik işlerdir: çekirdek, tema ve eklenti güncellemeleri, veri tabanı ve dosya yedekleri, güvenlik kontrolü, PHP sürümü ve SSL sertifikası takibi, form ve ödeme testleri. Teknik destek ise bir şey bozulduğunda kimin, hangi kanaldan ve hangi kapsamda müdahale edeceğidir. WordPress’in kendi rehberi küçük siteler için haftalık, yoğun siteler için günlük yedek ve her güncellemeden önce bir yedek önerir. Bakımı yapılmayan bir site çoğu zaman bir gecede çökmez; eklentiler eski kalır, yedekler ihmal edilir, formlar fark edilmeden bozulur.

Web sitesi bakım ve desteği, siteniz teslim edildikten sonra güvenli, erişilebilir ve çalışır kalması için yapılan düzenli teknik işlemlerdir. Sorun fark edildiğinde kayıp çoktan yaşanmış olabilir.

Sitenin yayına girmesi işin bittiği anlamına gelmez. WordPress, e-ticaret, randevu veya teklif formu kullanan sitelerde teslim sonrası dönem; satış, operasyon ve itibar üzerinde doğrudan etkilidir. Bu yazıda bakımın kapsamını, önlediği riskleri ve işletmeniz için gereken seviyeyi açıklıyoruz.

Öne Çıkanlar

• Web sitesi bakımı; güncelleme, yedekleme, güvenlik kontrolü, performans takibi ve sorun müdahalesini birlikte kapsar.
• Güncellenmemiş eklentiler ve temalar, WordPress sitelerinde güvenlik açığı ve uyumluluk riski yaratır.
• Yedek iki parçadır: veri tabanı ve dosyalar. İkisi de gerekir ve her güncellemeden önce alınmalıdır.
• PHP 8.2’nin güvenlik desteği 31 Aralık 2026’da bitiyor. SSL sertifikalarının azami geçerlilik süresi de kısalıyor; yenileme otomatik olmalıdır.
• WordPress’in otomatik güncellemesi yalnızca ölümcül PHP hatasında geri alınır. Bozulan bir formu yakalamaz; güncellemeler test edilmelidir.
• Sipariş, randevu veya teklif alan sitelerde bakım maliyeti; kesinti sırasında kaçan taleplerle birlikte değerlendirilmelidir.

Web Sitesi Bakımı Nedir?

Web sitesi bakımı, site çevrimiçi kaldığı sürece yapılan tekrar eden teknik işlerin tamamıdır. Bu işler bir kez yapılıp bitmez. Altyapınız, eklentileriniz, sunucu ayarlarınız ve içerikleriniz zaman içinde değişir.

Bakımın amacı basittir: Sitenizin çalıştığını varsaymak yerine, bunu düzenli olarak kontrol etmektir.

Düzenli bakım sürecinde genellikle şu işler yer alır:

• WordPress, tema ve eklenti güncellemeleri: Eski sürümlerin oluşturduğu güvenlik ve uyumluluk risklerini azaltır.
• Dosya ve veri tabanı yedekleri: Hata, saldırı veya yanlış işlem sonrası geri dönüş noktası sağlar.
• Güvenlik kontrolleri: Zararlı yazılım, şüpheli dosya değişikliği ve saldırı belirtileri izlenir.
• Sunucu ve sertifika takibi: PHP sürümünün destek süresi ve SSL sertifikasının yenilenmesi kontrol edilir.
• Performans takibi: Açılış hızı, gereksiz yükler ve teknik darboğazlar kontrol edilir.
• Form ve kritik akış testleri: Teklif formu, sipariş adımları, ödeme ve randevu süreci düzenli doğrulanır.
• İçerik ve bağlantı kontrolleri: Bozuk bağlantılar, eski kampanya sayfaları ve hatalı bilgiler düzeltilir.
• Teknik müdahale: Sorun oluştuğunda neyin değiştiği bulunur ve güvenli biçimde düzeltilir.

Bu işlemlerin bazıları yönetim panelinden yapılabilir. Ancak mesele yalnızca “güncelle” düğmesine basmak değildir. Güncellemenin sitenin başka bölümlerini bozup bozmadığını da kontrol etmek gerekir.

Bir web sitesi bakım planı, sitenizin çalışmasını umut etmeyi değil, düzenli olarak doğrulamayı sağlar.

Web Sitesi Bakımı Olmadan Ne Olur?

Bakım eksikliği çoğu zaman görünmeden başlar. Site açılır, birkaç sayfa çalışır ve işletme sahibi sorun olmadığını düşünür. Ancak ziyaretçinin gördüğü ekran ile arka planda biriken teknik borç aynı şey değildir.

Aşağıdaki dört sorun, bakımı ihmal edilen sitelerde en sık görülür.

Güvenlik açıkları birikir

WordPress esnek bir sistemdir. Tema, eklenti ve entegrasyonlarla genişler. Eski sürümler kullanılmaya devam edildiğinde bu esneklik, saldırı yüzeyini büyütür. Google, kaçırılan güvenlik güncellemelerini ve güvensiz tema ile eklentileri sitelerin ele geçirilmesinin başlıca yolları arasında sayar (web.dev). En sık açıklar ve kapatma adımları için WordPress güvenlik açıkları yazısına bakabilirsiniz.

Güncellenmeyen bir eklenti, kötü niyetli erişim için açık oluşturabilir. Bu yalnızca ana sayfanın değiştirilmesi anlamına gelmez. Spam sayfalar açılabilir, ziyaretçiler zararlı adreslere yönlendirilebilir, yönetici hesapları ele geçirilebilir. Google, ele geçirilmiş sayfaları arama sonuçlarında uyarı etiketiyle gösterebilir; tarayıcılar da ziyaretçiye uyarı amaçlı bir geçiş sayfası açabilir (Search Console Yardım).

Varsayımsal bir örnek: Bir mobilya mağazasının WordPress sitesi aylardır güncellenmiyor. Yoğun satış döneminde siteye yetkisiz erişim sağlanıyor ve sipariş formu çalışmaz hale geliyor. Sorun fark edilene kadar ziyaretçiler ürünleri inceleyebiliyor, ancak talep bırakamıyor.

Böyle bir arızada teknik sorun tek maliyet değildir. Asıl maliyet, işletmenin fark etmeden kaybettiği taleplerdir.

Site yavaşlar ve ziyaretçi kaybeder

Bir site ilk yayına çıktığında hızlı olabilir. Zamanla yeni görseller yüklenir, kullanılmayan eklentiler eklenir, veri tabanı büyür ve eski kod parçaları birikir. Bunların hiçbiri tek başına felaket yaratmaz. Birlikte ise sayfa açılışını belirgin biçimde yavaşlatırlar.

Yavaşlık üç alanda maliyet yaratır:

• Ziyaretçi daha sayfa açılmadan çıkar.
• Form, ürün veya iletişim bilgisine ulaşmak zorlaşır.
• Arama tarafında sayfa deneyimi zayıflayabilir. Google, Core Web Vitals metriklerinin sıralama sistemlerinde kullanıldığını söyler; ancak tek bir “sayfa deneyimi” sinyali yoktur (Google Search Central).

Bu fark özellikle mobil bağlantılarda belirgindir. Ofiste hızlı internet kullanan ekip, sitenin sorununu görmeyebilir. Potansiyel müşteri ise ürün sayfasının açılmasını beklemez. Sekmeyi kapatır ve başka bir seçeneğe gider. Hızın arama ve dönüşüm üzerindeki etkisini site hızı yazısında ayrıca ele aldık.

Bu nedenle performans takibi yalnızca teknik bir kontrol değildir. Reklam bütçesiyle sitenize getirdiğiniz ziyaretçilerin, sayfa açılmadığı için kaybolup kaybolmadığını gösterir.

Eklenti çakışmaları kritik akışları bozar

Eklentiler WordPress sitelerine işlev kazandırır. Ödeme altyapısı, form, kargo, randevu, güvenlik ve SEO araçları çoğunlukla eklentilerle çalışır. Ancak bir eklenti güncellemesinin diğer sistemlerle sorunsuz çalışacağı garanti değildir. Daha az ve daha iyi bakılan eklenti kullanmak bu riski baştan küçültür; seçim ölçütleri WordPress eklenti seçimi yazısında.

Otomatik güncellemeden sonra şu sorunlar ortaya çıkabilir:

• Ödeme adımı hata verir.
• İletişim formu e-posta göndermeyi bırakır.
• Kayıt veya randevu talebi kaydedilmez.
• Yönetim paneli erişilemez hale gelir.
• Sayfa beyaz ekran verir.
• Mobil menü veya ürün varyasyonları çalışmaz.

Varsayımsal bir örnek: Online kurs satan bir eğitim firmasının ödeme eklentisi, bir güncellemeden sonra sepet bileşeniyle çakışıyor. Hafta sonu boyunca kayıt alınamıyor. Sorun teknik olmanın ötesine geçer. İşlem yapamayan yüksek niyetli ziyaretçiler nedeniyle doğrudan gelir kaybı oluşur.

Doğru bakım süreci, güncellemeleri canlı sitede deneme yanılmayla uygulamak değildir. Önce yedek alınır. Mümkünse test ortamında kontrol yapılır. Ardından canlı site güncellenir ve kritik akışlar yeniden test edilir.

Kesinti uzadıkça maliyet büyür

Siteniz tamamen kapandığında veya kritik bir işlev çalışmadığında her saat önemlidir. Daha tehlikeli olan ise sitenin kısmen bozulmasıdır.

Varsayımsal bir örnek: Bir diş kliniğinin randevu formu günlerdir çalışmıyor. Ana sayfa açık, telefon numarası görünüyor ve site normal çalışıyor gibi duruyor. Bu yüzden teknik sorun hemen anlaşılmıyor. Ancak dönüşüm verileri incelendiğinde randevu taleplerindeki düşüş ortaya çıkar.

Kısmi kesintilerde ziyaretçi hata mesajı bırakmaz. Genellikle doğrudan ayrılır. Bu nedenle bakım planında yalnızca “site açık mı?” kontrolü yeterli değildir. Formlar, telefon bağlantıları, ödeme ekranları ve randevu adımları da test edilmelidir.

WordPress Sitelerinde Bakım Neden Daha Kritiktir?

WordPress’in avantajı, işletmenin siteyi yönetebilmesidir. İçerik eklenir, ürün güncellenir, kampanya sayfası açılır ve yeni işlevler eklenir. Ancak bu yapı düzenli teknik denetim gerektirir.

WordPress çekirdeği, tema ve eklentiler ayrı ayrı güncellenir. Bir bileşendeki değişiklik, diğerleriyle uyumu etkileyebilir. Eski sürümde kalmak güvenlik riski doğurur; WordPress’in kendi güvenlik rehberine göre eski sürümler artık güvenlik güncellemesi almaz (WordPress Developer). Her güncellemeyi kontrol etmeden canlıya almak da çalışma riski yaratır. Bu yüzden özel WordPress sitelerinde bakımı, güncellemeyi ve güvenliği tek yerden izleyen yönetimli barındırma seçeneği sunuyoruz.

WordPress otomatik güncellemesi nasıl çalışır?

WordPress’in güncelleme davranışı bileşene göre değişir (WordPress Developer, WordPress.org):

• Çekirdek: Küçük sürümler ve çeviriler varsayılan olarak kendiliğinden güncellenir. WordPress 5.6 ve sonrasıyla kurulan sitelerde büyük sürümler de otomatik güncellenir.
• Eklenti ve tema: WordPress 5.5’ten beri otomatik güncelleme her eklenti ve tema için tek tek açılır. Eklentiler ekranında “Otomatik güncellemeyi aç” bağlantısı bunun içindir. Güncellemeler günde iki kez kontrol edilir ve sonuç yöneticiye e-postayla bildirilir.
• Geri alma: WordPress 6.6’dan beri bir eklentinin otomatik güncellemesi ölümcül PHP hatasına yol açarsa WordPress önceki sürüme döner ve yöneticiye e-posta gönderir (WordPress 6.6). Bu kontrol, ana sayfaya yapılan bir istekte ölümcül hata arar (Make WordPress Core). Çalışmayan bir formu ya da ödeme adımını bu yüzden yakalamayabilir.

Bu yüzden iki yanlış yaklaşım sık görülür:

1. Hiç güncelleme yapmamak: Site bir süre çalışır, sonra açıklar ve uyumsuzluklar birikir.
2. Her güncellemeyi otomatik kabul etmek: Güncelleme uygulanır, ancak formun ya da ödeme akışının bozulduğu saatler sonra fark edilir.

Doğru yöntem kontrollü güncellemedir. Güncellemeden önce yedek alınır, kritik eklentiler değerlendirilir. Güncelleme tamamlandıktan sonra sitenin temel akışları kontrol edilir.

Bu durum e-ticaret sitelerinde daha da önemlidir. Ödeme entegrasyonu, sipariş e-postaları, stok davranışı ve kargo bağlantıları küçük bir uyumsuzluktan etkilenebilir. Sipariş alan bir mağazada “sonra bakarız” yaklaşımı işlem kaybına yol açar.

PHP Sürümü ve SSL Sertifikası: Gözden Kaçan İki Tarih

Bakım konuşulurken eklentiler akla gelir. Sunucu tarafındaki iki tarih ise çoğu zaman unutulur.

PHP sürümünüz hâlâ destek alıyor mu?

WordPress PHP ile çalışır ve her PHP sürümünün bir destek bitiş tarihi vardır (PHP.net):

PHP sürümü	Güvenlik desteği
8.1	31 Aralık 2025’te sona erdi
8.2	31 Aralık 2026’da bitiyor
8.3	31 Aralık 2027’ye kadar
8.4	31 Aralık 2028’e kadar

Desteği biten sürüm artık güvenlik yaması almaz (PHP.net). WordPress resmi olarak PHP 8.3 veya üstünü, MySQL 8.0 ya da MariaDB 10.11 ve üstünü ve HTTPS desteğini önerir. Daha eski kurulumlar çalışmaya devam edebilir, ancak WordPress bunların resmi destek süresinin dolduğunu ve sitenizi güvenlik açıklarına açık bırakabileceğini belirtir (WordPress.org).

PHP sürümü yükseltmeden önce de yedek alınmalıdır. Eski bir eklenti yeni PHP sürümüyle uyumsuz olabilir.

SSL sertifikası kendiliğinden yenileniyor mu?

SSL/TLS sertifikalarının azami geçerlilik süresi kademeli olarak kısalıyor. CA/Browser Forum kararıyla bu süre 15 Mart 2026’dan itibaren 200 gün, 15 Mart 2027’den itibaren 100 gün, 15 Mart 2029’dan itibaren 47 gündür (CA/Browser Forum).

Ücretsiz sertifika sağlayan Let’s Encrypt bugün 90 günlük sertifika veriyor. Varsayılan süre 10 Şubat 2027’den itibaren 64 güne iniyor; Şubat 2028’de 45 gün planlanıyor (Let’s Encrypt, Let’s Encrypt Docs). Sabit aralıklarla yenileyen eski kurulumlar bu değişiklikte sorun çıkarabilir.

Kısacası yılda bir elle yenilenen sertifika dönemi bitti. Otomatik yenilemenin çalıştığını kontrol etmek artık bakımın parçasıdır. HTTPS’in temelleri için SSL ve site güvenliği yazısına bakabilirsiniz.

Web Sitesi Bakımı ve Teknik Destek Kapsamı

Her sitenin ihtiyacı aynı değildir. Yalnızca kurumsal bilgi veren bir siteyi, her gün sipariş alan bir WooCommerce mağazasıyla aynı bakım seviyesinde yönetmek doğru olmaz.

Yine de bakım kapsamı değerlendirilirken şu başlıklar açıkça belirtilmelidir:

Bakım alanı	Neyi korur?	Kontrol edilmesi gereken nokta
Yedekleme	Veri ve dosya kaybı	Yedek sıklığı, saklama yeri, geri yükleme yöntemi
Güncelleme	Güvenlik ve uyumluluk	Güncelleme öncesi yedek ve sonrası test
Güvenlik	Yetkisiz erişim ve zararlı yazılım	Tarama, kullanıcı yetkileri, iki adımlı doğrulama
Sunucu ve PHP	Güvenlik yaması ve uyumluluk	PHP sürümünün destek tarihi
SSL sertifikası	Güvenli bağlantı	Otomatik yenilemenin çalışması
Performans	Açılış hızı ve kullanıcı deneyimi	Görseller, eklentiler, veri tabanı, sunucu kaynakları
Form testi	Talep ve randevu kaybı	E-posta teslimi, doğrulamalar, yönlendirmeler
E-ticaret testi	Sipariş kaybı	Sepet, ödeme, sipariş bildirimi, stok ve kargo akışı
Teknik destek	Sorun çözme süresi	Kim müdahale eder, hangi kanaldan, hangi kapsamda?

Bakım teklifi yalnızca “güncelleme yapılır” cümlesinden oluşuyorsa eksiktir. Güncelleme sonrası neyin test edileceği, yedeğin nerede tutulacağı, sorun halinde kimin müdahale edeceği ve hangi işlerin kapsam dışında olduğu da yazılmalıdır.

Belirsiz retainer burada da sorun yaratır. Her ay ödeme yapıp hangi kontrollerin gerçekten yapıldığını bilmemek, bakım planı değildir. Yapılan iş görünür ve izlenebilir olmalıdır.

İşletmeniz Ne Kadar Bakıma İhtiyaç Duyuyor?

Bakım ihtiyacı, site türüne göre değil; sitenin işletmeniz içindeki işlevine göre belirlenir. Siteniz satış, randevu veya talep topluyorsa kesintinin maliyeti doğrudan daha yüksektir.

Karar vermek için şu soruları yanıtlayın:

Siteniz işlem alıyor mu?

Her gün sipariş, randevu, kayıt veya teklif formu alan bir site kritik kabul edilmelidir. Bu sitelerde yedekleme daha sık yapılmalı, form ve ödeme akışları düzenli olarak test edilmelidir.

Yalnızca kurumsal bilgi veren bir site daha düşük işlem riski taşıyabilir. Ancak iletişim formu, telefon bağlantısı, harita ve temel sayfalar işletmenin ilk temas noktalarıdır. Bunların bozulması da güven kaybına yol açar.

Son güncellemeniz ne zaman yapıldı?

Bu soruya net yanıt veremiyorsanız bakım durumu belirsizdir. Uzun süredir güncellenmeyen tema ve eklentiler, hem güvenlik hem uyumluluk açısından incelenmelidir.

İlk adım rastgele güncelleme yapmak değildir. Önce sitenin mevcut durumu tespit edilir:

• Hangi WordPress sürümü kullanılıyor?
• Sunucuda hangi PHP sürümü çalışıyor ve destek süresi ne zaman bitiyor?
• Hangi eklentiler aktif?
• Hangileri gereksiz veya terk edilmiş?
• Son yedek ne zaman alınmış?
• Formlar ve e-posta bildirimleri çalışıyor mu?
• Yönetici hesaplarına kimlerin erişimi var?

WordPress’in Site sağlığı ekranı bu listenin bir bölümünü sizin için çıkarır. Eski PHP sürümünü, bekleyen eklenti güncellemelerini, çalışmayan arka plan güncellemelerini ve ziyaretçiye açık hata gösterimini kritik sorun olarak listeler (WordPress.org). Bu kontrol, bakım sürecinin başlangıç noktasıdır.

Son yedeğiniz ne zaman alındı?

Bir yedek, ancak geri yüklenebiliyorsa değerlidir. Hosting panelinde bir yedek dosyası görmek yeterli değildir. Dosyaların ve veri tabanının birlikte saklandığı, gerektiğinde geri dönebileceğiniz bir yapı gerekir.

WordPress’in yedekleme rehberi bu konuda nettir: Yedek iki parçadır, veri tabanı ve dosyalar; ikisi de gerekir. Küçük siteler için haftalık, yoğun siteler için günlük yedek önerilir. Her güncellemeden önce mutlaka yedek alınır ve en az 3–5 güncel yedek farklı yerlerde saklanır (WordPress Developer).

E-ticaret sitesinde her gün sipariş oluşuyorsa eski bir yedeğe dönmek, son günlerdeki sipariş ve müşteri verilerini kaybetme riski taşır. Sürekli değişen siteler daha sık yedeklenmelidir.

Sitenizde değişiklik yapabilecek kişi var mı?

WordPress paneline erişiminizin olması, her teknik sorunu çözebileceğiniz anlamına gelmez. İçerik değiştirmek ile tema dosyası, güvenlik açığı veya ödeme eklentisi sorununu çözmek farklı işlerdir.

İşletme içinde bu sorumluluğu üstlenecek teknik bir kişi yoksa açık bir destek kanalı daha önemlidir. Sorun anında kime yazacağınızı ve hangi bilgileri paylaşacağınızı önceden bilmek, kesinti süresini azaltır.

Siteniz Çöktüğünde Uygulanacak Acil Adımlar

Siteniz erişilemez hale geldiyse ilk amaç her ayarı rastgele değiştirmek değildir. Sorunun kaynağını, durumu büyütmeden anlamak gerekir. Panikle yapılan yanlış bir işlem geri dönüşü zorlaştırabilir.

Şu sırayı takip edin:

1. Hosting ve alan adı durumunu kontrol edin. Hesap askıya alınmış mı, disk alanı dolmuş mu, sunucu tarafında bir hata var mı bakın.
2. Son değişikliği not edin. Yeni eklenti, güncelleme, tema düzenlemesi veya DNS değişikliği yapıldıysa sorunun kaynağı olabilir.
3. Güncel yedeği doğrulayın. Geri yükleme kararı vermeden önce hangi tarihe döneceğinizi ve ne kaybedebileceğinizi netleştirin.
4. Son güncellenen bileşeni devre dışı bırakın. Sorun bir güncellemeden hemen sonra başladıysa, ilgili eklenti veya tema bileşeni incelenmelidir.
5. Hata mesajlarını saklayın. Ekran görüntüsü, hata kodu ve son yapılan işlemler teknik müdahaleyi hızlandırır.
6. Güvenlik kontrolü yaptırın. Yetkisiz erişim şüphesi varsa yalnızca siteyi geri açmak yeterli değildir. Zararlı dosyalar, kullanıcı hesapları ve şifreler de kontrol edilmelidir. Search Console’daki Güvenlik sorunları raporu, Google’ın sitenizde ele geçirilmiş içerik veya kötü amaçlı yazılım bulup bulmadığını gösterir (Search Console Yardım).
7. Kritik akışları yeniden test edin. Site açıldıktan sonra form, ödeme, e-posta bildirimi ve mobil görünüm kontrol edilmelidir.

Sorun çözüldüğünde süreç bitmez. Sorunun neden oluştuğunu bulmak gerekir. Aynı eklenti, aynı kullanıcı erişimi veya aynı yedekleme eksikliği sürüyorsa bir sonraki kesinti yalnızca zaman meselesidir.

Web Sitesi Bakım Maliyeti Nasıl Değerlendirilmeli?

Web sitesi bakım maliyetini yalnızca aylık ücret üzerinden değerlendirmek yanıltır. Asıl soru şudur: Siteniz birkaç saat ya da birkaç gün çalışmazsa işletmenize ne olur?

Bu hesabı yaparken şunları göz önünde bulundurun:

• Günlük ortalama kaç form, sipariş veya randevu alıyorsunuz?
• Bir form çalışmadığında bunu ne kadar sürede fark edersiniz?
• Yedek yoksa kaç günlük veri kaybını kabul edebilirsiniz?
• Teknik sorunda içeride müdahale edecek biri var mı?

Bakımın kapsamı büyüdükçe maliyet de yükselir. Bu normaldir. Ancak kapsam net değilse, düşük görünen fiyatın neleri dışarıda bıraktığını sormak gerekir. “Destek dahil” ifadesi yeterli değildir: Hangi destek, kaç değişiklik, ne kadar sürede? Maliyet kalemlerinin ayrıntısı WordPress bakım maliyeti ve güvenlik güncellemeleri yazısında.

Web Sitesi Bakımı Hakkında Sık Sorulan Sorular

Web sitesi teknik desteği neleri kapsar?

Teknik destek, bir şey bozulduğunda kimin, hangi kanaldan ve ne kadar sürede müdahale edeceğidir. Kapsam genellikle hata tespiti, güncelleme sonrası sorunlar, yedekten geri yükleme, güvenlik müdahalesi ve form ya da ödeme akışındaki arızaları içerir. Hangi işlerin dahil, hangilerinin kapsam dışı olduğu teklifte yazılı olmalıdır.

Web sitesi bakımını kendim yapabilir miyim?

Temel içerik güncellemelerini ve bazı eklenti güncellemelerini siz yönetebilirsiniz. Ancak yedekleme, güvenlik taraması, hata analizi ve güncelleme sonrası test teknik bilgi gerektirir. Siteniz sipariş, randevu veya talep alıyorsa kontrollü destek daha güvenlidir.

WordPress otomatik güncelleme açık olsa yeterli olmaz mı?

Hayır. Otomatik güncelleme bazı riskleri azaltır. WordPress 6.6’dan beri ölümcül bir PHP hatasında eklenti güncellemesini geri de alır. Ancak bu kontrol ana sayfadaki ölümcül hatayı arar; çalışmayan bir formu, bozulan bir ödeme adımını veya tasarım hatasını yakalamaz. Bunlar ancak test edildiğinde fark edilir.

Yedekleme ne sıklıkla yapılmalı?

WordPress’in kendi rehberi küçük siteler için haftalık, yoğun siteler için günlük yedek önerir. Her güncellemeden önce ayrıca yedek alınmalıdır. Yedek hem veri tabanını hem dosyaları içermeli, en az 3–5 güncel kopya farklı yerlerde saklanmalıdır.

Bakım hizmetinde içerik güncellemeleri de yer alır mı?

Bu, bakım anlaşmasının kapsamına bağlıdır. Teknik bakım ile içerik girişi aynı iş değildir. Teklifte dahil olan değişiklik türleri ve sınırları birlikte yazılmalıdır.

Sitem hacklendiyse yedekten geri dönmek yeterli mi?

Hayır. Google’ın temizlik rehberine göre önce geri döneceğiniz yedeğin saldırıdan önce alındığını doğrulayın. Yalnızca güncelleme değil temiz kurulum yapın; FTP, veri tabanı, sunucu ve yönetici şifrelerini değiştirin, kullanılmayan yazılımları kaldırın (web.dev). Site temizlendikten sonra Search Console’daki Güvenlik sorunları raporundan İnceleme İsteğinde Bulunun ile uyarının kaldırılmasını istersiniz; Google’a göre inceleme birkaç gün ile birkaç hafta sürebilir.

Saldırıda form veya müşteri kayıtlarındaki kişisel veriler başkalarının eline geçtiyse bu bir veri ihlalidir. KVKK’ya göre veri sorumlusu durumu gecikmeksizin ve en geç 72 saat içinde Kurul’a bildirir (KVKK).

Form çalışmıyorsa bunu nasıl fark ederim?

Form gönderimlerini düzenli olarak test etmek gerekir. Form e-postalarının ulaştığı adresler, spam klasörleri ve dönüşüm takibi de kontrol edilmelidir. Site açık görünürken formun çalışmaması, en pahalı sessiz arızalardan biridir. Formun kendisinin nasıl kurulacağı web sitesi form tasarımı yazısında.

Teslim Sonrası Destek, Sitenin Devam Eden İşidir

Web sitesini teslim etmek önemlidir. Ancak teslimden sonra bakım yapılmazsa teknik risk yalnızca ertelenir. Güncellemeler, yedekler, güvenlik kontrolleri, PHP ve sertifika takibi ve kritik akış testleri; siteyi satış ve iletişim kanalı olarak kullanmaya devam etmenin temelidir.

İyi bir bakım süreci gereksiz raporlar veya belirsiz vaatler sunmaz. Hangi kontrollerin yapıldığı, hangi risklerin bulunduğu ve sorun halinde ne yapılacağı açıkça belirtilir. Özellikle WordPress ve WooCommerce sitelerinde bu açıklık, sonradan çıkacak maliyetleri önler.