WordPress hacklendi: SEO açısından temizlik ve Google'a dönüş

25/09/26

Hacklenen bir WordPress sitesi çoğu zaman ilk olarak Search Console'dan ya da site: aramasında görünen tuhaf sonuçlardan fark edilir. Ana sayfa normal görünür, yönetim paneli çalışır, ama Google'da sitenizin adıyla Japonca başlıklar, ilaç reklamları ya da hiç yazmadığınız binlerce sayfa listelenir.

Burada iki iş var: siteyi gerçekten temizlemek ve Google'ın temiz hâli görmesini sağlamak. İkincisi birincisi olmadan işe yaramaz. Yarım temizlenmiş bir site birkaç gün sonra aynı içeriği yeniden üretir ve inceleme talebi reddedilir.

Belirtiler

Aşağıdakilerden biri bile varsa siteyi hacklenmiş kabul edip incelemeye başlıyorum:

Japonca anahtar kelime hack'i. site:alanadiniz.com aramasında Japonca başlıklı, genellikle rastgele karakterli URL'ler.
İlaç (pharma) spam'i. İlaç, kumar ya da sahte ürün başlıkları; bazen mevcut sayfaların başlık ve açıklaması değiştirilmiş olarak.
Cloaking. Sayfa size normal görünür, ama Googlebot'a ya da Google'dan gelen ziyaretçiye farklı içerik veya yönlendirme gösterilir.
Bilinmeyen yönetici hesapları. Kullanıcılar listesinde tanımadığınız bir yönetici.
Spam dolu site haritası. Sitemap'te sizin oluşturmadığınız URL'ler ya da Search Console'a eklenmiş yabancı bir sitemap.
Search Console uyarısı. Güvenlik sorunları raporunda saldırıya uğramış içerik (Hacked content) türünde bir kayıt.

Cloaking'i elle görmek zordur, çünkü saldırgan içeriği sadece belirli kullanıcı ajanlarına ya da Google'dan gelen yönlendirmeye gösterir. Search Console'daki URL Denetimi (URL Inspection) aracında Canlı URL'yi test et (Test live URL) ile Google'ın gördüğü HTML'e bakmak en güvenilir yöntem.

Adım adım temizlik

1. Yedek alın

Temizliğe başlamadan önce dosyaların ve veritabanının tam bir kopyasını alın. Bu kopya hacklenmiş hâlidir, geri yüklemek için değil, delil ve karşılaştırma için. Neyin nerede değiştiğini sonradan görmek için ona ihtiyacınız olacak.

2. Siteyi bakım moduna alın

Temizlik sürerken ziyaretçilerin zararlı içerikle karşılaşmaması için bakım moduna alın. Bakım sayfası 503 durum kodu dönmeli; böylece Google bunun geçici olduğunu anlar. Bakımı kısa tutun, günlerce 503 dönen bir site sorun yaratır.

3. Tüm parolaları ve anahtarları değiştirin

Hosting paneli, FTP/SFTP, veritabanı kullanıcısı, tüm WordPress yöneticileri ve e-posta hesapları. Veritabanı parolasını değiştirdikten sonra wp-config.php içindeki DB_PASSWORD değerini güncelleyin. Salt anahtarlarını yenilemek tüm açık oturumları sonlandırır:

# WP-CLI ile salt anahtarlarını yenile ve yöneticileri listele
wp config shuffle-salts
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Tanımadığınız yöneticileri silin. Kayıt tarihi, saldırının ne zaman başladığına dair ipucu verir.

4. Çekirdeği, temaları ve eklentileri resmi kaynaktan yeniden kurun

Dosyaları tek tek düzeltmek yerine yeniden kurmak daha güvenli. WordPress çekirdeğini, temaları ve eklentileri resmi dizinden ya da geliştiricinin sitesinden indirin. WP-CLI dosyaların orijinaliyle aynı olup olmadığını kontrol edebilir:

# Çekirdek ve wordpress.org eklentilerinin dosyalarını orijinalleriyle karşılaştır
wp core verify-checksums
wp plugin verify-checksums --all

"Nulled" (lisansı kırılmış) tema ve eklentileri kaldırın. Bunlar hack'lerin en yaygın giriş kapılarından biri; içlerinde çoğu zaman hazır bir arka kapı gelir. Kullanmadığınız temaları ve eklentileri de silin, devre dışı bırakmak yetmez.

5. Arka kapıları arayın

Saldırgan genellikle geri dönebilmek için bir ya da birkaç arka kapı bırakır. wp-content içinde, özellikle de uploads klasöründe PHP dosyası aramak iyi bir başlangıç:

# uploads klasöründe PHP dosyası olmamalı
find wp-content/uploads -type f -name "*.php"

# Sık kullanılan gizleme kalıpları
grep -rnE "eval\s*\(\s*(base64_decode|gzinflate|gzuncompress|str_rot13)" --include=*.php .
grep -rlE "base64_decode|gzinflate|str_rot13|assert\s*\(" --include=*.php wp-content/

# Son 14 günde değişen PHP dosyaları
find . -type f -name "*.php" -mtime -14 -printf "%TY-%Tm-%Td %p\n" | sort

Bu kalıplar meşru eklentilerde de geçebilir; eşleşen her dosya zararlı değildir. Ama uploads içindeki PHP dosyaları, rastgele isimli dosyalar ve tek satırlık uzun kodlanmış içerik neredeyse her zaman şüphelidir.

6. .htaccess, wp-config ve cron

.htaccess dosyalarında (kök dizin dışındakiler dâhil) HTTP_USER_AGENT veya HTTP_REFERER koşuluna bağlı yönlendirmeler cloaking'in klasik izidir. wp-config.php dosyasının başında ya da sonunda eklenmiş include veya kodlanmış satırlara bakın.

Zamanlanmış görevleri de kontrol edin: hosting panelindeki cron işleri ve sunucuda crontab -l. WordPress'in kendi zamanlanmış olaylarını wp cron event list ile listeleyebilirsiniz; tanımadığınız bir kanca adı, silinen dosyaları yeniden oluşturan bir görev olabilir.

Saldırganın nereden girdiğini anlamak için erişim loglarına bakmak da faydalı. Loglardan belirli istekleri ayıklama yöntemini cPanel logları ile Googlebot analizi yazısında anlattım; aynı yaklaşım şüpheli POST isteklerini bulmak için de çalışır.

Spam URL'leri kaldırmak

Hack'in oluşturduğu sayfalar temizlikten sonra 404 ya da 410 dönmeli. Sayfalar veritabanında ya da dosya olarak üretildiyse, kaynağı silince zaten 404 dönerler. Bunu birkaç örnek URL ile kontrol edin; bazı hack'ler silinen sayfalar için 200 durum kodlu boş bir sayfa bırakır.

Spam URL'leri robots.txt ile engellemeyin. Engellenen URL'yi Google tarayamaz, 404 ya da 410 döndüğünü göremez ve dizinden düşmesi gecikir.

Google'ın yeniden tarayıp dizinden çıkarması zaman alır. Gerçekten acil durumlarda (örneğin marka adınızla aranınca müstehcen içerik çıkıyorsa) Search Console'daki Kaldırmalar (Removals) aracıyla URL'leri geçici olarak gizleyebilirsiniz. Bu araç, Google'ın belgelerine göre sonuçları yaklaşık altı ay gizler, sayfaları kalıcı olarak silmez. Kalıcı çözüm yine 404/410'dur.

Search Console tarafı

Kullanıcılar ve izinler (Users and permissions) bölümünde tanımadığınız sahip var mı bakın. Saldırganlar bazen kendi hesaplarını doğrular. Onları kaldırın ve sunucudaki yabancı doğrulama dosyalarını (google*.html) ya da meta etiketlerini silin.
Site haritaları (Sitemaps) raporunda yabancı sitemap varsa kaldırın, temiz sitemap'inizi yeniden gönderin.
Güvenlik sorunları (Security issues) raporunda kayıt varsa, temizlik bittikten sonra inceleme isteyin. Talepte ne yaptığınızı açıkça yazın. Bu raporun ayrıntılarını Search Console güvenlik sorunları yazısında ayrıca ele aldım.

Bakım modunu kapatmadan önce URL Denetimi ile birkaç sayfayı canlı test edin ve Google'ın gördüğü HTML'in temiz olduğundan emin olun.

Önleme kontrol listesi

WordPress çekirdeği, temalar ve eklentiler otomatik ya da haftalık güncelleniyor.
Nulled tema ve eklenti yok; kullanılmayanlar silindi.
Tüm yöneticilerde güçlü, benzersiz parola ve iki adımlı doğrulama var.
wp-config.php içinde define('DISALLOW_FILE_EDIT', true); tanımlı.
uploads klasöründe PHP çalıştırılması sunucu yapılandırmasıyla engellendi.
Dosya izinleri makul (dizinler 755, dosyalar 644, wp-config.php daha kısıtlı).
Günlük, siteden bağımsız bir yerde tutulan yedekler var ve geri yükleme denendi.
Güvenlik başlıkları kontrol edildi; güvenlik başlıkları aracı ile eksikleri görebilirsiniz.
Search Console e-posta bildirimleri açık ve doğru adrese gidiyor.
Ayda bir site: araması ve Kullanıcılar ve izinler listesi kontrol ediliyor.

Comments / questions

If you have a question about any topic or wish to contact me: Telegram or send an email to [email protected] Thanks!