Sunucuya Sızma ve SEO Spam Saldırıları: Tespit, Temizlik ve Korunma Rehberi

1. SEO Spam Saldırısının Hedefi Nasıl Olunur?

Saldırganlar çoğu zaman web sitelerini tek tek manuel olarak seçmez. İnterneti tarayan otomatik botnet ağları; CMS sürümlerini, bilinen güvenlik açıklarını, yanlış yapılandırılmış sunucuları, açık yönetim panellerini ve yazılabilir dizinleri sürekli olarak kontrol eder.

Bu nedenle küçük veya orta ölçekli bir web sitesinin saldırıya uğramayacağını düşünmek doğru değildir. İnternete açık olan her web uygulaması otomatik saldırı taramalarının hedefi olabilir.

1.1. Alan adı otoritesi ve geçmişi

SEO spam operasyonlarında saldırganların amaçlarından biri, saldırıya uğrayan alan adının geçmişte oluşturduğu güven ve görünürlükten faydalanmaktır.

Yıllardır aktif olan, arama motorlarında içerikleri bulunan ve dış bağlantılar kazanmış bir alan adı, sıfırdan oluşturulan bir spam sitesine göre saldırgan açısından daha değerli görülebilir.

Bu nedenle saldırganlar sitenin mevcut içeriğini tamamen değiştirmek yerine, mevcut yapının içerisine çok sayıda spam sayfası eklemeye çalışabilir.

1.2. Güncel olmayan yazılımlar

Eski CMS sürümleri, eklentiler, temalar, PHP uygulamaları veya üçüncü taraf kütüphaneler güvenlik riski oluşturabilir.

• Güncellenmemiş CMS çekirdeği
• Eski veya terk edilmiş eklentiler
• Güvenlik açığı bulunan temalar
• Eski PHP uygulamaları
• Güncel olmayan sunucu yazılımları
• Gereksiz aktif servisler

Özellikle artık kullanılmayan ancak sunucuda bırakılmış eski uygulamalar saldırganların otomatik taramalarında keşfedilebilir.

1.3. Yanlış dosya ve dizin izinleri

Web sunucusunun çalıştığı kullanıcı hesabının, uygulamanın ihtiyaç duymadığı alanlara yazma yetkisine sahip olması saldırı sonrasında zararlı dosya bırakılmasını kolaylaştırabilir.

Özellikle gereğinden fazla geniş dosya izinleri, kötü yapılandırılmış uygulamalarla birlikte güvenlik riskini artırabilir.

Buradaki amaç yalnızca belirli bir izin değerini yasaklamak değildir. Asıl hedef, uygulamanın gerçekten ihtiyaç duyduğu minimum yazma yetkisinin verilmesidir.

1.4. Zayıf yönetici hesapları

Saldırılar her zaman bir yazılım açığı üzerinden gerçekleşmez. Tahmin edilebilir, tekrar kullanılan veya ele geçirilmiş parolalar da önemli saldırı vektörlerinden biridir.

• FTP hesapları
• SFTP hesapları
• SSH kullanıcıları
• Hosting panel hesapları
• CMS yönetici hesapları
• Veritabanı kullanıcıları
• API erişim anahtarları

2. Saldırganlar Sunucuya Nasıl Sızar?

Bir saldırının gerçek giriş noktasını belirlemek, temizlik işleminden daha önemlidir. Çünkü yalnızca görünen zararlı dosyaları silmek, saldırganın kullandığı açık kapatılmadığı sürece sistemin yeniden enfekte olmasını engellemez.

2.1. Keşif ve otomatik tarama

İlk aşamada saldırgan sistem hakkında bilgi toplamaya çalışır. Otomatik tarayıcılar; kullanılan CMS, açık servisler, uygulama yolları, yönetim panelleri ve bilinen güvenlik açıklarını araştırabilir.

2.2. İlk erişim

İlk erişim; uygulama açığı, çalınmış kullanıcı bilgileri, hatalı dosya yükleme mekanizması, yanlış yapılandırılmış servis veya başka bir güvenlik problemi üzerinden gerçekleşebilir.

2.3. Kalıcılık oluşturma

Saldırgan sisteme eriştikten sonra yalnızca tek bir dosya bırakmakla yetinmeyebilir. Daha sonra tekrar erişebilmek için farklı kalıcılık mekanizmaları kullanılabilir.

Bu nedenle aşağıdaki alanlar özellikle kontrol edilmelidir:

• Yeni oluşturulmuş PHP dosyaları
• Değiştirilmiş .htaccess dosyaları
• Şüpheli zamanlanmış görevler
• Yeni kullanıcı veya erişim anahtarları
• Geçici dizinlerdeki şüpheli dosyalar
• Web uygulaması yükleme dizinleri
• Değiştirilmiş yapılandırma dosyaları

2.4. SEO spam içeriğinin oluşturulması

Saldırının SEO boyutu bu aşamada ortaya çıkabilir. Saldırganlar sitenin gerçek içeriğiyle ilgisiz çok sayıda URL oluşturabilir.

• Yabancı dilde anlamsız sayfalar
• Sahte ürün sayfaları
• Sahte haber içerikleri
• Spam bağlantılar
• Doorway sayfaları
• Gizli yönlendirmeler
• Sahte AMP benzeri URL yapıları

3. SEO Spam Saldırısının Belirtileri Nelerdir?

Bir web sitesinin saldırıya uğradığını anlamak için yalnızca antivirüs sonucuna bakmak yeterli değildir. SEO ve sunucu tarafındaki belirtiler birlikte değerlendirilmelidir.

Google Search Console belirtileri

• Hiç oluşturulmamış URL'lerin keşfedilmesi
• Yabancı dillerde sayfaların görünmesi
• Alakasız arama sorgularında sitenin görünmesi
• Spam içerikli sayfaların indekslenmesi
• Beklenmeyen AMP URL'lerinin oluşması
• Beklenmeyen tarama artışları
• Güvenlik veya spam uyarıları

Sunucu tarafındaki belirtiler

• Beklenmeyen PHP dosyaları
• Son günlerde değiştirilmiş çok sayıda dosya
• Şüpheli POST istekleri
• Tanımsız zamanlanmış görevler
• Beklenmeyen CPU veya RAM kullanımı
• Şüpheli dış bağlantılar
• Değiştirilmiş .htaccess dosyaları
• Normal olmayan HTTP istekleri

4. Apache Logları ile Saldırı Tespiti

Web sunucusu logları, olay müdahalesinin en önemli kanıt kaynaklarından biridir. Apache kullanan sistemlerde erişim ve hata logları incelenerek saldırganın hangi URL'lere istek gönderdiği, hangi HTTP metodunu kullandığı ve olayın yaklaşık olarak ne zaman gerçekleştiği konusunda önemli bilgiler elde edilebilir.

Canlı erişim takibi

tail -f /usr/local/apache/domlogs/alanadiniz.com

Belirli istek türlerini filtrelemek için:

tail -f /usr/local/apache/domlogs/alanadiniz.com | grep --color=auto -E "POST|wp-login|xmlrpc|uploads"

Ancak tek başına POST isteği görülmesi saldırı olduğu anlamına gelmez. POST istekleri normal web uygulamalarında da kullanılır. Önemli olan isteğin hangi URL'ye, hangi IP'den, hangi zaman aralığında ve hangi User-Agent ile geldiğinin değerlendirilmesidir.

Şüpheli URL kalıplarının aranması

grep -n -i -E "spam|casino|crypto|amp|uploads" /usr/local/apache/domlogs/alanadiniz.com

Bu tür aramalar yalnızca başlangıç noktasıdır. Gerçek analizde sitenin normal URL yapısı bilinmeli ve olağandışı hareketler buna göre değerlendirilmelidir.

5. Dosya Sistemi Adli Taraması

Saldırının zaman aralığı biliniyorsa dosya değişiklik tarihleri önemli ipuçları sağlayabilir. Özellikle olaydan hemen önce veya sonra değiştirilen dosyalar incelenmelidir.

find /home/kullanici/public_html -type f \( -name "*.php" -o -name "*.js" -o -name ".htaccess" \) -mtime -3 2>/dev/null

Bu komut son üç gün içerisinde değiştirilen belirli dosya türlerini listeler.

Ancak yeni değiştirilmiş her dosya zararlı değildir. CMS güncellemeleri, cache sistemleri, eklentiler veya normal geliştirici çalışmaları da dosya zamanlarını değiştirebilir.

Dosyanın zaman ve sahiplik bilgilerinin incelenmesi

stat /home/kullanici/public_html/ornek.php

Ardından şüpheli dosyanın içeriği kontrollü şekilde incelenebilir:

sed -n '1,220p' /home/kullanici/public_html/ornek.php

6. Web Shell ve Gizlenmiş PHP Kodları

Web shell, saldırganın daha sonra web üzerinden yetkisiz işlemler gerçekleştirmesine yardımcı olabilecek bir arka kapı mekanizmasıdır.

Zararlı kodlar her zaman açık ve anlaşılır şekilde yazılmaz. Kodun gerçek işlevini gizlemek amacıyla çeşitli kod gizleme yöntemleri kullanılabilir.

Örneğin aşağıdaki fonksiyonlar tek başına bir dosyanın zararlı olduğunu kanıtlamaz. Ancak beklenmeyen bir dosyada birden fazla şüpheli kod yapısıyla birlikte görülmeleri ayrıntılı inceleme gerektirebilir:

• eval benzeri dinamik kod çalıştırma yapıları
• base64_decode benzeri kod çözme fonksiyonları
• Sıkıştırılmış veya gizlenmiş PHP içerikleri
• Beklenmeyen uzak sunucu bağlantıları
• Uygulamanın normal mimarisiyle ilgisiz kod parçaları

Burada önemli olan tek bir fonksiyonu aramak değil, dosyanın uygulamanın normal kod yapısıyla uyumlu olup olmadığını değerlendirmektir.

7. Zamanlanmış Görevler ve Kalıcılık Kontrolü

Bir saldırganın sisteme tekrar erişmesini sağlayabilecek mekanizmalardan biri zamanlanmış görevlerdir. Bu nedenle temizlik sırasında yalnızca web dizinlerinin kontrol edilmesi yeterli değildir.

for user in $(cut -d: -f1 /etc/ passwd); do
  echo "===== $user ====="
  crontab -l -u "$user" 2>/dev/null
done

Yukarıdaki örnekteki sistem kullanıcı listesi bölümü, WAF filtrelerine takılmaması için metinsel açıklamada kısaltılmış olarak da gösterilebilir:

for user in $(cut -d: -f1 /etc/ [passwd]); do
  echo "===== $user ====="
  crontab -l -u "$user" 2>/dev/null
done

Ayrıca sistem genelindeki zamanlanmış görev dizinleri de incelenmelidir:

ls -la /etc/cron.d/
ls -la /etc/cron.daily/
ls -la /etc/cron.hourly/
ls -la /etc/cron.weekly/

Tanımadığınız her görev otomatik olarak zararlı kabul edilmemelidir. Önce görevin ne yaptığı, hangi kullanıcı tarafından oluşturulduğu ve sistemdeki hangi uygulamayla ilişkili olduğu araştırılmalıdır.

8. Geçici Dizinlerin Kontrolü

Geçici dizinler de olay incelemesinde gözden geçirilmelidir. Özellikle saldırı sonrasında oluşturulan ve sistemin normal çalışma düzeniyle açıklanamayan dosyalar araştırılmalıdır.

find /tmp -type f -mtime -3 -ls 2>/dev/null

find /dev/shm -type f -mtime -3 -ls 2>/dev/null

Bu dizinlerde görülen her dosya kötü amaçlı değildir. İşletim sistemi ve uygulamalar tarafından oluşturulan geçici dosyalar da bulunabilir. Bu nedenle silme işleminden önce dosyanın sahibi, zaman bilgileri ve içeriği kontrol edilmelidir.

9. Saldırı Sonrası Temizlik Nasıl Yapılmalı?

En sık yapılan hata, Google'da görünen spam URL'leri bulup doğrudan silmek ve olayı kapatılmış kabul etmektir. Bu yaklaşım çoğu zaman yeterli değildir.

Profesyonel temizlik üç temel soruya cevap vermelidir:

1. Saldırgan sisteme nasıl girdi?
2. Sistemde ne değiştirdi?
3. Tekrar girebilmesini sağlayan herhangi bir mekanizma kaldı mı?

9.1. Önce kanıtları koruyun

Mümkünse şüpheli dosyaları hemen silmeden önce dosya yolları, zaman damgaları, sahiplik bilgileri ve ilgili log kayıtları not edilmelidir.

Büyük ve kritik sistemlerde profesyonel adli bilişim yaklaşımının uygulanması daha güvenlidir.

9.2. Giriş noktasını kapatın

Kullanılmayan eklentiler kaldırılmalı, açık bulunan yazılımlar güncellenmeli ve zayıf parolalar değiştirilmelidir.

• CMS güncellemesi
• Eklenti güncellemeleri
• PHP uygulaması güncellemeleri
• Hosting panel güvenliği
• SSH güvenliği
• FTP hesaplarının kontrolü
• Veritabanı kullanıcılarının kontrolü

9.3. Şüpheli dosyaları temizleyin

Zararlı olduğu doğrulanan dosyalar karantinaya alınmalı veya güvenilir bir yedekten temiz sürümleriyle değiştirilmelidir.

Özellikle CMS çekirdek dosyalarında tek tek satır silmek yerine, mümkün olduğunda resmi ve doğrulanmış temiz sürümle değiştirmek daha güvenilir bir yöntemdir.

9.4. Erişim bilgilerini yenileyin

Bir sistem ele geçirilmişse yalnızca tek bir panel parolasını değiştirmek yeterli olmayabilir. Olayın kapsamına göre ilgili tüm kimlik bilgileri yenilenmelidir.

• Hosting panel parolası
• CMS yönetici hesapları
• FTP/SFTP hesapları
• SSH erişimleri
• Veritabanı parolaları
• API anahtarları
• SMTP hesapları

10. Google'da Oluşan Hayalet URL'ler Nasıl Temizlenir?

Sunucudaki spam dosyalarını silmek ile Google'ın indeksindeki spam URL'lerini temizlemek aynı işlem değildir.

Öncelikle URL'nin gerçekten sunucuda mevcut olup olmadığı belirlenmelidir.

URL hâlâ mevcutsa

Öncelikle kaynağın kaldırılması gerekir. Spam URL'nin arkasında gerçek bir dosya, veritabanı kaydı, dinamik route veya yönlendirme mekanizması varsa bunlar temizlenmelidir.

URL artık mevcut değilse

Sunucu doğru şekilde 404 Not Found veya uygun durumda içeriğin kalıcı olarak kaldırıldığını belirten başka bir HTTP yanıtı döndürmelidir.

Google Search Console içerisindeki Kaldırmalar (Removals) aracı, arama sonuçlarında görünen istenmeyen URL'lerin geçici olarak gizlenmesine yardımcı olabilir. Ancak bu araç saldırının teknik kaynağını temizlemez.

Unutmayın: Search Console'dan bir URL'yi kaldırmak, sunucudaki zararlı kodu veya saldırganın erişim mekanizmasını ortadan kaldırmaz.

11. 404, 410 ve Yönlendirme Arasındaki Fark

Temizlik sonrasında bütün bilinmeyen URL'leri ana sayfaya yönlendirmek doğru yaklaşım değildir.

Gerçekten kaldırılmış ve karşılığı olmayan spam URL'lerin uygun HTTP durum koduyla sonlandırılması genellikle daha doğru bir yaklaşım oluşturur.

• 404: İstenen kaynak bulunamadı.
• 410: Kaynağın kalıcı olarak kaldırıldığı belirtilir.
• 301: Gerçekten başka bir karşılığı bulunan içerik için kalıcı yönlendirme.

SEO amacıyla yüzlerce spam URL'yi alakasız şekilde ana sayfaya yönlendirmek yerine, URL'nin gerçek durumuna uygun HTTP yanıtı verilmelidir.

12. Cloaking ve Doorway Pages Nedir?

Cloaking

Cloaking, aynı URL'nin farklı kullanıcı veya sistemlere farklı içerikler göstermesi yaklaşımıdır. Kötüye kullanıldığında arama motoru botlarına farklı, gerçek ziyaretçilere farklı içerik gösterilerek arama sonuçlarının manipüle edilmesi amaçlanabilir.

Doorway Pages

Doorway pages, belirli arama sorgularından trafik almak amacıyla oluşturulan ve çoğu zaman kullanıcıya gerçek anlamda değer sunmayan çok sayıdaki benzer sayfadır.

Bir saldırganın web sitesine binlerce otomatik spam sayfası eklemesi, bu tür tekniklerin kötüye kullanımına örnek olabilir.

13. Web Sunucusu ve PHP-FPM Mimarisi Kontrol Edilmeli

Saldırı sonrası yalnızca dosyaları incelemek yeterli olmayabilir. Web sunucusu mimarisinde yapılan değişiklikler de kontrol edilmelidir.

Özellikle Apache, Nginx ve PHP-FPM birlikte kullanılıyorsa aşağıdaki zincirin doğru çalıştığından emin olunmalıdır:

Internet
   |
Nginx / Proxy
   |
Apache
   |
PHP-FPM
   |
PHP Application
   |
Database

Yapılandırma değişikliklerinden sonra ortaya çıkan 404, 403, 500 veya PHP-FPM bağlantı hatalarının saldırıyla doğrudan ilişkili olduğu varsayılmamalıdır. Önce problemin hangi katmanda oluştuğu belirlenmelidir.

14. Malware ve Güvenlik Taraması

Sunucuda mevcut güvenlik yazılımlarından yararlanılabilir. Örneğin Imunify360 veya benzeri güvenlik çözümleri sistem genelinde malware taraması gerçekleştirebilir.

Ancak otomatik tarama sonucunun temiz çıkması da tek başına sistemin kesinlikle güvenli olduğunu kanıtlamaz. Yeni veya özel olarak hazırlanmış zararlı kodlar otomatik sistemler tarafından her zaman tanınmayabilir.

Bu nedenle otomatik güvenlik taraması ile manuel log ve dosya analizi birlikte kullanılmalıdır.

15. Sunucuda Yapılması Gereken Temel Güvenlik Kontrol Listesi

• ☐ CMS güncel mi?
• ☐ Kullanılmayan eklentiler kaldırıldı mı?
• ☐ Tema ve üçüncü taraf kütüphaneler güncel mi?
• ☐ PHP sürümü desteklenen bir sürüm mü?
• ☐ Dosya izinleri kontrol edildi mi?
• ☐ FTP/SFTP hesapları incelendi mi?
• ☐ SSH kullanıcıları ve erişim anahtarları kontrol edildi mi?
• ☐ Zamanlanmış görevler incelendi mi?
• ☐ Geçici dizinler kontrol edildi mi?
• ☐ Apache access ve error logları incelendi mi?
• ☐ Şüpheli PHP dosyaları kontrol edildi mi?
• ☐ .htaccess dosyaları karşılaştırıldı mı?
• ☐ Veritabanında beklenmeyen kullanıcı veya içerik var mı?
• ☐ Yönetici parolaları yenilendi mi?
• ☐ API anahtarları yenilendi mi?
• ☐ Güvenlik taraması gerçekleştirildi mi?
• ☐ Google Search Console kontrol edildi mi?
• ☐ Spam URL'lerin HTTP durum kodları kontrol edildi mi?
• ☐ Sitemap yeniden kontrol edildi mi?
• ☐ Yeniden enfeksiyona karşı izleme kuruldu mu?

16. Saldırı Sonrası Google Search Console Kontrolü

Teknik temizlik tamamlandıktan sonra SEO tarafındaki hasar ayrıca değerlendirilmelidir.

Kontrol edilmesi gereken başlıca alanlar:

• Sayfalar ve indeksleme raporları
• URL Denetleme
• Site Haritaları
• Kaldırmalar
• Güvenlik sorunları
• Manuel işlemler
• Performans raporu
• Tarama istatistikleri

Özellikle saldırı sonrasında organik trafik düşüşü yaşanıyorsa yalnızca sıralama değişimini değil; indekslenen sayfa sayısını, tarama davranışını, spam URL'leri, manuel işlemleri ve güvenlik uyarılarını birlikte değerlendirmek gerekir.

17. Saldırıdan Sonra SEO Neden Geçici Olarak Bozulabilir?

Bir site saldırıya uğradığında arama motorları kısa süre içerisinde çok sayıda yeni, kalitesiz veya alakasız URL keşfedebilir. Aynı dönemde gerçek sayfaların taranma oranı, indekslenme durumu veya kullanıcı sinyalleri de etkilenebilir.

Temizlik yapıldıktan sonra sıralamaların anında eski konumuna dönmemesi mümkündür.

Arama motorlarının siteyi yeniden taraması, değişiklikleri değerlendirmesi ve spam sinyallerinin ortadan kalktığını görmesi zaman alabilir.

Bu nedenle saldırı sonrası SEO iyileşmesi genellikle tek gecede gerçekleşen bir işlem değil, izlenmesi gereken bir toparlanma sürecidir.

18. Saldırıların Tekrarını Önlemek İçin Ne Yapılmalı?

Güncelleme politikası oluşturun

CMS, eklenti, tema, PHP ve sunucu yazılımları düzenli olarak güncellenmelidir. Kullanılmayan yazılımlar pasif bırakılmak yerine mümkünse tamamen kaldırılmalıdır.

Minimum yetki prensibini uygulayın

Her kullanıcı, uygulama ve servis yalnızca ihtiyaç duyduğu yetkiye sahip olmalıdır. Gereksiz yazma ve yönetici yetkileri kaldırılmalıdır.

Logları merkezi olarak saklayın

Saldırganların logları değiştirmesi veya silmesi ihtimaline karşı kritik sistemlerde logların ayrı bir noktaya aktarılması olay incelemesini kolaylaştırabilir.

Yedekleri bağımsız tutun

Yedekleme sistemi sunucuyla aynı güvenlik sınırları içerisindeyse saldırı sırasında yedeklerin de zarar görmesi mümkündür.

Bu nedenle düzenli, test edilmiş ve mümkün olduğunca bağımsız yedekler kritik öneme sahiptir.

Dosya değişikliklerini izleyin

Özellikle kritik web sitelerinde dosya değişikliklerini izleyen sistemler sayesinde beklenmeyen PHP, JavaScript veya yapılandırma değişiklikleri daha erken fark edilebilir.

19. Saldırı Tespitinde En Sık Yapılan Hatalar

1. Sadece spam URL'leri silmek: Giriş noktası kapatılmadığı için saldırgan tekrar erişebilir.
2. Search Console'dan URL kaldırmayı temizlik sanmak: Bu işlem sunucudaki zararlı kodu temizlemez.
3. Her yabancı dosyayı rastgele silmek: Meşru uygulama dosyaları da yanlışlıkla silinebilir.
4. Sadece antivirüse güvenmek: Manuel adli analiz ve log incelemesi atlanmamalıdır.
5. Logları incelemeden sistemi yeniden kurmak: Giriş noktasının anlaşılmasını zorlaştırabilir.
6. Yedekleri kontrol etmeden geri yüklemek: Yedekte de zararlı dosyalar bulunabilir.
7. Erişim bilgilerini değiştirmemek: Çalınmış kimlik bilgileri saldırganın yeniden erişmesine neden olabilir.

20. Profesyonel Olay Müdahalesi İçin Örnek Akış

1. Anomaliyi doğrula.
2. Saldırı zaman aralığını belirle.
3. Access ve error loglarını koru.
4. Şüpheli dosyaları tespit et.
5. Dosya zaman damgalarını karşılaştır.
6. Zamanlanmış görevleri ve kalıcılık mekanizmalarını kontrol et.
7. Kullanıcı ve erişim bilgilerini kontrol et.
8. Giriş noktasını kapat.
9. Zararlı dosyaları temizle.
10. Temiz ve güvenilir dosyaları yeniden yükle.
11. Erişim bilgilerini ve anahtarları yenile.
12. Sunucuyu yeniden tara.
13. Spam URL'lerin HTTP durum kodlarını kontrol et.
14. Google Search Console'u kontrol et.
15. Temizlik sonrasında sistemi izlemeye devam et.

21. Sonuç: Saldırıdan Sonra Asıl Hedef Güveni Yeniden İnşa Etmektir

Bir web sitesinde yabancı dilde spam sayfalar, sahte AMP URL'leri veya daha önce oluşturulmamış binlerce adres görmek ciddi bir güvenlik alarmıdır. Fakat paniğe kapılarak rastgele dosya silmek yerine sistematik bir olay müdahalesi uygulanmalıdır.

En önemli nokta, SEO problemini güvenlik probleminden ayrı düşünmemektir. Spam URL'ler çoğu zaman problemin kendisi değil, sistemde gerçekleşen bir güvenlik ihlalinin arama motorlarında görünen sonucudur.

Bu nedenle başarılı bir kurtarma süreci yalnızca Google'daki URL'leri temizlemekten oluşmaz. Saldırının giriş noktası bulunmalı, kalıcılık mekanizmaları kontrol edilmeli, zararlı dosyalar temizlenmeli, erişim bilgileri yenilenmeli, sistem güncellenmeli ve sonrasında Google Search Console ile organik görünürlük yakından izlenmelidir.

Kısacası güvenli bir web sitesi için yaklaşım şu olmalıdır:

Tespit et → Kanıtı koru → Giriş noktasını kapat → Temizle → Doğrula → İzle.

Bu yaklaşım yalnızca SEO spam saldırılarında değil; web shell, malware, yetkisiz dosya değişiklikleri, hesap ele geçirme ve diğer birçok web güvenliği olayında uygulanabilecek temel bir olay müdahalesi çerçevesidir.