WordPress Spam Sayfaları Neden Oluşur ve Nasıl Temizlenir?

WordPress sitenizde yabancı ürün, bahis veya anlamsız anahtar kelimelerle açılmış URL’ler görüyorsanız bunu yalnızca kötü içerik olarak değerlendirmeyin. Spam sayfaları; ele geçirilmiş hesap, zayıf eklenti, temaya eklenmiş arka kapı veya dinamik URL üretimi nedeniyle oluşabilir. Amaç birkaç URL’yi gizlemek değil, kaynağı bulup yeniden üretimi durdurmaktır.

Search Console, sunucu logları, WordPress yazı/sayfa listeleri ve sitemap’i aynı tarih aralığında karşılaştırın. URL, başlık, ilk görülme zamanı, HTTP kodu ve bulunduğu kaynağı kaydedin. Canlı yanıtı kontrol etmeden toplu silme yapmayın; kanıtı kaybetmek bulaşma yolunu gizler.

Spamın türünü ayırın

Veritabanında gerçek post kaydı, sunucu/eklenti tarafından dinamik üretilen yol veya farklı kullanıcıya farklı içerik gösteren cloaking birbirinden farklıdır. Google’ın spam politikaları hacked sitelerde cloaking görülebileceğini belirtir. Tarayıcıda temiz görünmesi tek başına güvence değildir.

Post kaydı varsa yetki ve veritabanı değişikliklerini; dinamik yanıt varsa rewrite, tema, eklenti ve sunucu kurallarını; cloaking şüphesinde güvenli karşılaştırmalı testleri inceleyin.

Kök nedeni bulmadan temizlemeyin

Çekirdek, tema ve eklentileri yalnız güvenilir resmi kaynaklardan alın. WordPress hardening belgeleri güncel yazılım ve bağımsız, bütünlüğü kontrol edilmiş yedeklerin önemini vurgular. Yetkisiz yönetici hesabını silmek tek başına yeterli olmayabilir; erişim kayıtları, kalıcı kod ve cron görevleri de kontrol edilmelidir.

Üretimde rastgele kod çalıştırmak veya şüpheli dosyayı açmak yerine doğrulanmış yedek, staging kopyası ve olay kaydı hazırlayın. Üretim verisini silmeden önce bağımsız okunabilir bir kopya bulunmalıdır.

URL için doğru yanıtı seçin

Spam içerik kaldırıldı ve eşdeğer sayfa yoksa Google’ın tarama rehberindeki 404 veya 410 sinyali kullanılabilir. İçerik gerçekten taşındıysa ilgili yeni adrese 301 düşünülür. Her adresi ana sayfaya yönlendirmek kullanıcıyı yanıltabilir ve soft 404 üretebilir.

Robots.txt ile kalıcı kaldırma yapmayın; sitemap’ten çıkarın, canonical’ı zorla gerçek sayfaya yazmayın ve örnek URL’leri URL Inspection ile tekrar kontrol edin. Search Console’un eski sayıları gecikmeli güncellenebilir.

Kabul kontrolü

  1. Yeni spam URL üretimi durdu mu?
  2. Yetkisiz kullanıcı ve değişiklikler kanıtla incelendi mi?
  3. Örnek adresler beklenen 404/410 veya ilgili 301’i döndürüyor mu?
  4. Meşru sayfalar, formlar, canonical ve sitemap etkilenmedi mi?
  5. Yedek ve olay günlüğü saklandı mı?

Kapsam büyükse veya kişisel veri, ödeme ya da cloaking şüphesi varsa üretimde deneme-yanılma yapmayın; uzman incelemesi ve kontrollü restore planlayın.

Temizleme sırasını güvenli kurun

Önce kanıtı değiştirecek plansız bakım ve temizlik işlemlerini durdurun; gerekiyorsa aktif saldırıyı uzman desteğiyle kontrollü biçimde izole edin. Şüpheli kullanıcı, cron, eklenti ve dosya bulgularını bir tabloya yazın; aynı bulgunun farklı kopyalarını tek kayıt altında tutun. URL’nin Google’da görünmesiyle WordPress’te kayıtlı olması farklı sorulardır. Canlı yanıt, veritabanı kaydı ve kaynak log birlikte ele alınmalıdır.

Meşru URL ile spam URL’yi aynı temizleme komutunda karıştırmayın. Örneğin bir sorgu parametresi gerçek arama veya filtre işlevinin parçası olabilir. Kaldırma öncesi örnekleri, canonical’ı ve sitemap durumunu saklayın. Google sonuçlarının geç güncellenmesi, canlı sistemdeki bulgunun da durduğu anlamına gelmez.

Temizliğin sonunda yeniden tarama isteği vermek, teknik düzeltmenin yerine geçmez. Önce HTTP kodunu, kaynak HTML’yi, robots ve canonical’ı doğrulayın; sonra Search Console ile izleyin.

Örnek olay: URL var ama WordPress kaydı yok

Varsayımsal bir işletme, Search Console’da 200 yabancı URL görür. İlk 20 adresin canlı yanıtı 200’dür; WordPress yazı listesinde kayıt yoktur. Farklı kullanıcı ajanlarında HTML değişiyorsa bu, basit içerik silme değil dinamik üretim veya cloaking araştırmasıdır. Beklenen kanıt; URL örnekleri, iki kullanıcı ajanı yanıtı, access log satırları, aktif eklenti/tema sürümleri, cron listesi ve temizlik öncesi snapshot kimliğidir.

Adresler silindikten sonra yeniden oluşuyorsa sonraki adım yeni silme değil, onları üreten endpoint, cron, yetkili hesap veya dosya değişikliğini izole etmektir. URL artık 404/410 döndüğü halde Google sayısı bir süre yüksek kalıyorsa canlı sistemde yeniden silme yapmayın; sitemap, canonical ve yeniden tarama durumunu izleyin. Temizliğin ardından web sitesi virüs temizleme ve güvenlik hizmeti kapsamını ve post-incident kabulünü anlatan temizlik sonrası kontrol listesini birlikte değerlendirin.

İşletme yöneticisi için kapanış kaydı şu beş kanıtı birlikte taşımalıdır: temizleme öncesi snapshot, etkilenen URL listesi, kök neden bulgusu, temizlik sonrası canlı örnekler ve izleme sorumlusu. Bu kayıt yoksa aynı URL’lerin ne zaman ve neden kapandığını sonradan açıklamak zorlaşır.