WordPress temizliği tamamlandıktan sonra sitenin açılması olayın bittiği anlamına gelmez. Ön yüzde temiz görünen site; veritabanında kalmış kullanıcıyı, zamanlanmış zararlı görevi, değiştirilmiş sunucu kuralını veya çalışmayan formu göstermeyebilir. Yeniden yayın, kanıtlanabilir bir kabul süreci olmalıdır.
Bu içerik ilk müdahale rehberinin yerine geçmez; temizlikten sonra neyi doğrulayacağınızı anlatır.
Temiz kaynağı sabitleyin
Hangi yedek veya temiz kurulumun esas alındığını, hangi dosya ve veritabanı tablolarının değiştirildiğini yazın. Çekirdek, tema, eklenti, uploads, mu-plugins, yapılandırma ve veritabanı kapsamda mı? Temizlik sırasında çıkarılan dosyaların olay öncesi kopyasını saklayın; bu kopya üretime dönmek için değil, kök nedeni anlamak içindir.
Dosya ve veritabanını ayrı doğrulayın
Çekirdek bütünlüğü, özel eklentiler, yönetici hesapları, cron görevleri, options ve spam URL kayıtlarını ayrı inceleyin. Tarama aracının bulgu üretmemesi, sistemde hiçbir tehdit kalmadığını kanıtlamaz. Şüpheli bulguyu üretimde rastgele silmek yerine staging veya uzman incelemesiyle değerlendirin.
Erişimleri yenileyin
- WordPress, hosting, SFTP/SSH, veritabanı, DNS ve e-posta erişimlerini listeleyin.
- Gereksiz kullanıcıları sahiplik kontrolüyle kaldırın; ortak parola kullanmayın.
- Uygulama parolaları, API anahtarları ve üçüncü taraf bağlantılarını yenileyin.
- Mümkün olan katmanlarda çok adımlı doğrulama kullanın.
SEO ve iş akışını kabul edin
Meşru sayfaları mobil ve masaüstünde test edin. Form, telefon, WhatsApp, ödeme, e-posta, login, canonical, robots ve sitemap çıktısını kontrol edin. Spam URL kaldırıldıysa eşdeğer içerik yokken 404/410; gerçek taşınma varsa uygun 301 düşünün. Google’ın tarama rehberi her URL’yi ana sayfaya yönlendirmenin doğru olmadığını gösterir.
Yayına dönüş kapısı
- Temiz dosya ve veritabanı kaynağı kayıtlı.
- Erişimler yenilenmiş.
- Örnek URL, form ve dönüşüm akışları test edilmiş.
- HTTP, canonical, robots, sitemap ve güvenlik uyarıları kontrol edilmiş.
- Rollback ve bağımsız okunabilir yedek doğrulanmış.
İlk haftalarda izle
Yeni dosya, yönetici oturumu, spam URL, beklenmeyen yönlendirme, 404 artışı ve kaynak kullanımını takip edin. Monitoring belgeleri uptime yanında performans ve yavaş logların da izlenmesini önerir.
İzleme dönemini kayıt altına alın
İlk gün ve ilk hafta için ayrı kontrol sıklığı belirleyin. Dosya değişikliği, yeni yönetici, dışa giden istek, cron, beklenmedik 5xx ve spam URL sinyallerini aynı zaman çizelgesinde tutun. Yeniden bulaşma şüphesinde hangi olayın önce geldiğini görmek, temizliği yeniden planlamaktan daha değerlidir.
Ödeme veya kişisel veri etkilendiyse yalnız teknik testle yetinmeyin. İlgili ekiplerin olay bildirimi, kullanıcı iletişimi ve hukuki değerlendirme ihtiyacını ayrıca kontrol edin. Temizliğin kanıtı olmayan yerde “tamamen güvenli” ifadesi kullanmayın; bilinen bulguların kapandığını ve kalan belirsizliği yazın.
Restore testinde e-posta, medya, cron ve üçüncü taraf entegrasyonlarını da deneyin. Staging kabulü üretim DNS, SSL veya API kimliklerinin çalıştığını otomatik kanıtlamaz.
Örnek kabul testi ve başarısızlık yolu
Varsayımsal bir hizmet sitesinde temiz snapshot staging’e geri yüklenir. Kabul için ana sayfa, iki kritik hizmet URL’si, yönetici girişi, form başarı/hata durumu, e-posta bildirimi, medya, sitemap ve 404 örneği test edilir. Her testin URL’si, zamanı, beklenen sonucu ve gerçek sonucu kaydedilir; yalnız ekran görüntüsü değil HTTP yanıtı ve log kanıtı da tutulur.
Form gönderiliyor fakat bildirim gelmiyorsa siteyi hemen açmak yerine SMTP/üçüncü taraf kimlik bilgilerini ve logları ayırın. Yeni yönetici veya dosya oluşuyorsa snapshot’a dönmek yerine önce zaman damgası, oturum ve erişim kanıtını saklayın. 404/410 beklenen gibi çalışıyor fakat eski arama sonucu duruyorsa Search Console gecikmesini olay devam ediyor diye yorumlamayın. İlk hafta günlük, sonraki haftalarda seyrekleştirilen dosya/URL/uptime izleme planı oluşturun.
Yayına dönüşten sonra izleme eşiği belirleyin: yeni yönetici hesabı, beklenmeyen PHP dosyası, spam URL, yönlendirme veya kritik form hatası görüldüğünde kim durdurma kararı verecek? Eşik ve iletişim kişisi yazılı değilse dashboard tek başına olay müdahalesi sağlamaz.
Test ortamını yalnız alan adıyla değil dış etkileriyle de üretimden ayırın: arama motoru erişimini sınırlandırın, müşteri e-postaları ve webhook gönderimlerini test alıcılarına yönlendirin, ödeme entegrasyonunu deneme modunda kullanın. Geri yüklenen kişisel veriye erişimi kısıtlayın. Test sırasında gerçek müşterilere bildirim veya mükerrer işlem gitmediğini doğrulayın.
