Google'da Sitem Japonca Çıkıyor: WordPress SEO Spam Enfeksiyonu Temizleme

Sabah bir müşteriniz arıyor: "Firmanızın adını Google'da arattım, çıkan sonuçların yarısı Japonca. Ucuz çanta satan sayfalar." Siz hemen siteyi açıyorsunuz — her şey yerli yerinde. Ana sayfa normal, ürünler normal, yönetim paneli normal. Tarayıcıda hiçbir tuhaflık yok. Ama Google'da site:ornek.com yazdığınızda ekranı katakana ve kanji dolu yüzlerce URL kaplıyor: /jp/brand-copy-42/, /cheap/bag-3921/ gibi sizin hiç oluşturmadığınız adresler.

Bu tablo, güvenlik dünyasında Japanese keyword hack ya da Japonca anahtar kelime enjeksiyonu olarak bilinen saldırının klasik görüntüsüdür. Sitenizin ziyaretçilere bozuk görünmemesi bir tesadüf değil, saldırının tasarımının parçasıdır: kod, isteği kimin yaptığına bakar ve arama motoru botuna bambaşka bir sayfa, size ise gerçek sayfayı gösterir. Buna cloaking (kılık değiştirme) denir ve tam da bu yüzden enfeksiyon aylarca fark edilmeden yaşayabilir.

Bu rehberde saldırının mekaniğini, kapsamını Search Console üzerinden nasıl ölçeceğinizi, cloaking'i kendi terminalinizde nasıl doğrulayacağınızı, arka kapıları nasıl avlayacağınızı ve temizlik bittikten sonra arama sonuçlarını nasıl toparlayacağınızı sırayla anlatacağım. En kritik noktayı baştan söyleyeyim: bulduğunuz Japonca dosyaları silmek çoğu zaman işe yaramaz, çünkü onları yazan mekanizma yerinde durur ve birkaç saat içinde her şeyi geri getirir.

Sitem Normal Görünüyor, Google Neden Japonca Gösteriyor?#

Enjekte edilen kod genellikle tek bir karar verir: bu isteği yapan kim? Karar üç veriye bakar — HTTP_USER_AGENT başlığı (Googlebot mu, Chrome mu), HTTP_REFERER başlığı (ziyaretçi Google'dan mı geldi) ve bazen ziyaretçinin IP adresi. Mantık kabaca şudur:

• İstek Googlebot'tan geliyorsa: spam içerik, spam başlık, spam iç linkler döndürülür. Google bu sayfayı indeksler.
• Ziyaretçi Google sonuçlarına tıklayıp geldiyse: sahte alışveriş sayfasına yönlendirilir.
• İstek doğrudan adres çubuğundan geliyorsa (yani siz): gerçek sayfa döndürülür.

Üçüncü madde, sitenizi kendi tarayıcınızdan kontrol ettiğinizde neden hiçbir şey göremediğinizin cevabıdır. Aynı mantık, sitenizi düzenli tarayan bir eklentinin de neden sessiz kaldığını açıklar: eklenti dosyaları kontrol eder ama sayfayı Googlebot kimliğiyle istemez.

Saldırganın amacı sitenizi bozmak değil, sitenizin biriktirdiği alan adı itibarını kiralamaktır. Ne kadar uzun süre fark edilmezseniz, sahte sayfalar o kadar uzun süre sıralanır. Bu yüzden saldırı olabildiğince sessizdir: yönetim panelinize dokunulmaz, tasarımınız bozulmaz, hatta sitenin hızı bile belirgin şekilde düşmez.

İkinci bir katman daha vardır ve genellikle atlanır: saldırgan çoğu zaman Search Console'a kendini mülk sahibi olarak ekler. Bunu ya sunucu köküne bıraktığı bir google1a2b3c4d.html doğrulama dosyasıyla ya da erişebildiği bir DNS TXT kaydıyla yapar. Sahiplik alındıktan sonra sahte site haritalarını doğrudan Google'a bildirebilir, indeksleme isteği gönderebilir ve sizin temizlik hamlelerinizi canlı izleyebilir. Dosyaları temizleyip bu sahipliği bırakan bir sitede saldırı birkaç hafta sonra geri gelir.

Enfeksiyonun Kapsamını Search Console'da Ölçün#

Temizliğe dosya silerek değil, ölçerek başlayın. Search Console'a hiç bağlanmadıysanız önce Search Console kurulumunu tamamlayın; doğrulama sırasında zaten mevcut sahipleri de göreceksiniz ki bu tek başına değerli bir bilgidir.

Bakılacak dört ekran şudur:

1. Güvenlik ve Manuel İşlemler → Güvenlik Sorunları. Google enfeksiyonu tespit ettiyse burada "Hacklenmiş: İçerik enjeksiyonu" veya "Hacklenmiş: URL enjeksiyonu" uyarısı görürsünüz. Bu ekran temizlik sonunda yeniden değerlendirme talebini göndereceğiniz yerdir; şimdiden not edin.
2. Dizine ekleme → Sayfalar. "Dizine eklendi" sayısı sitenizin gerçek sayfa sayısının kat kat üstündeyse enjekte edilen URL hacmi hakkında ilk fikri buradan alırsınız. Listeyi dışa aktarın; temizlik sonrası hangi adreslerin düştüğünü karşılaştırmak için işinize yarayacak.
3. Performans raporu. Sorgu listesini açın ve Japonca karakter içeren sorguları filtreleyin. Hangi kelimelerde göründüğünüz, saldırganın hedeflediği pazarı ve enjekte edilen sayfa kalıbını gösterir.
4. Site Haritaları. Sizin göndermediğiniz sitemap-1.xml, wp-sitemap-jp.xml, sitemap_index_1.xml gibi girdiler varsa saldırgan burada iz bırakmış demektir. Bu girdileri hemen silmeyin — önce hangi URL'leri içerdiklerini indirin.

site:ornek.com aramasını da tamamlayıcı bir kaynak olarak kullanın, ama tek dayanağınız yapmayın: bu arama indeksin yalnızca bir kısmını gösterir ve sayfalama derinliği sınırlıdır. Search Console'un "Sayfalar" raporu daha eksiksizdir.

Cloaking'i Kendi Terminalinizde Doğrulama#

Enfeksiyonu kendi gözünüzle görmek, hangi dosyanın suçlu olduğunu bulmayı da kolaylaştırır. Aynı isteği farklı kimliklerle tekrarlayın:

# 1) Normal ziyaretçi kimliğiyle
curl -s -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" https://ornek.com/ | grep -i "<title>"

# 2) Googlebot kimliğiyle
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
     https://ornek.com/ | grep -i "<title>"

# 3) Googlebot + Google referrer (yönlendirme katmanını tetikler)
curl -s -o /dev/null -w "%{http_code} -> %{redirect_url}\n" \
     -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
     -H "Referer: https://www.google.com/search?q=test" \
     https://ornek.com/

Çıktıları şu tabloyla yorumlayın:

İkinci satır bu saldırının imzasıdır. Üçüncü komut 301/302 ve yabancı bir redirect_url veriyorsa yönlendirme katmanı da aktiftir; o hedef alan adı, aynı ağdaki başka enfekte siteleri bulmakta işinize yarar.

Aynı doğrulamayı Search Console'un URL Denetimi aracından da yapabilirsiniz: bir spam URL'yi girin, "Yayındaki URL'yi test et" deyin ve "Taranan sayfayı görüntüle → HTML" sekmesini açın. Bu, Google'ın gerçekten aldığı yanıttır; tarayıcınızın gördüğüyle arasındaki fark saldırının kendisidir.

Küçük bir uyarı: bazı varyantlar isteği IP aralığına göre de süzer. Sunucunun kendi IP'sinden yapılan istek temiz sayfa döndürürken dışarıdan yapılan istek spam döndürebilir. Testi iki noktadan da tekrarlayın.

Sahte Site Haritası ve Enjekte Edilen Sayfaları Bulma#

Saldırganın binlerce sayfayı bir gecede Google'a tanıtma yöntemi genelde sahte bir site haritasıdır. Bu haritalar iki biçimde karşınıza çıkar: kök dizine bırakılmış statik bir .xml dosyası ya da isteğe göre üretilen dinamik bir PHP çıktısı. İkincisi daha sinsidir, çünkü dosya sisteminde sitemap adında hiçbir şey bulamazsınız.

# Kök dizindeki şüpheli xml/html dosyaları (son 90 gün)
find . -maxdepth 1 -type f \( -name "*.xml" -o -name "*.html" \) -mtime -90 -ls

# Google doğrulama dosyaları — sizin eklemediğiniz varsa saldırgan mülk sahibi olmuş
ls -la google*.html

# Sahte haritanın içindeki URL kalıbını çıkarın
curl -s https://ornek.com/sitemap-1.xml | grep -o "<loc>[^<]*</loc>" | head -30

Dinamik üretim şüphesi varsa .htaccess dosyasını satır satır okuyun. Enjekte edilen kural genellikle şuna benzer bir yeniden yazma içerir ve WordPress'in kendi bloğunun üstüne yerleştirilir:

RewriteEngine On
RewriteRule ^sitemap-([0-9]+)\.xml$ /wp-content/uploads/2024/cache.php?s=$1 [L]
RewriteCond %{HTTP_USER_AGENT} (googlebot|bingbot) [NC]
RewriteRule ^jp/(.*)$ /wp-content/uploads/2024/cache.php?p=$1 [L]

Böyle bir kural görürseniz hedefteki dosya arka kapılarınızdan biridir. Kuralı silmeden önce dosyanın yolunu not edin.

Elde ettiğiniz URL kalıbı (/jp/, /cheap/, /brand/ gibi ortak bir önek) temizliğin son aşamasında 410 döndüreceğiniz yolları belirleyeceği için önemlidir. Kalıpları bir metin dosyasına yazın.

Arka Kapı Avı: Dosya Sisteminde Ne Aranır?#

Bu aşamada siteyi bakım moduna alın ve hiçbir şeyi silmeden tam bir yedek alın; yedek hem delil hem de yanlış silme durumunda geri dönüş noktasıdır. Ayrıntılı yedek ve kurtarma akışını hacklenmiş site kurtarma yazısında bulabilirsiniz.

Ardından üç eksende arama yapın.

1. Değişiklik zamanına göre#

Saldırının başlangıç tarihini Search Console'daki ilk Japonca gösterimden yaklaşık olarak biliyorsunuz. O tarihten sonra değişen PHP dosyalarını listeleyin:

find . -name "*.php" -newermt "2026-06-01" -printf "%TY-%Tm-%Td %TH:%TM  %p\n" | sort

2. İmzaya göre#

Gizlenmiş kod belli fonksiyonlara mecburdur:

grep -rIl --include="*.php" -E "eval\(|base64_decode\(|gzinflate\(|str_rot13\(" . | head -50
grep -rIl --include="*.php" -iE "googlebot|HTTP_REFERER|HTTP_USER_AGENT" wp-content/ | head -50

Bulduğunuz her sonuç zararlı değildir — bazı eklentiler HTTP_USER_AGENT okur. Ayırt edici işaret, dosyanın tek satırda yüzlerce karakterlik anlamsız bir dize içermesi ve bulunduğu eklentinin klasör mantığına uymamasıdır.

3. Olmaması gereken yerde PHP#

uploads klasöründe çalıştırılabilir kod bulunmamalıdır:

find wp-content/uploads -type f -name "*.ph*" -ls
find . -type f -name ".*.php" -ls           # noktayla başlayan gizli dosyalar
find . -type f -name "*.php" -perm -o+w -ls # herkese yazılabilir php dosyaları

Çekirdek ve eklenti dosyalarının değiştirilip değiştirilmediğini tahminle değil, sağlama toplamıyla anlayın. WP-CLI kuruluysa:

wp core verify-checksums
wp plugin verify-checksums --all

verify-checksums yalnızca WordPress.org deposundan gelen eklentileri doğrulayabilir; ücretli eklentiler için satıcının orijinal ZIP dosyasıyla karşılaştırma yapmanız gerekir. En temiz yol çekirdeği ve tüm eklenti/temaları resmî kaynaktan yeniden kurmak, yalnızca wp-content/uploads içeriğini ve wp-config.php dosyasını elle denetleyerek taşımaktır.

Dosya izinleri bu tür saldırıların hem nedeni hem sonucu olabilir; temizlik sonrası WordPress dosya izinlerini standart değerlere çekin.

Sildiğim Dosya Neden Geri Geliyor? Veritabanı ve Zamanlanmış Görevler#

Bir dosyayı sildiniz, sekiz saat sonra aynı isimle geri geldi. Bu, temizliğin en can sıkıcı anıdır ve tek bir anlama gelir: yazan mekanizma hâlâ ayakta. Üç yerde olabilir.

WordPress zamanlanmış görevleri. Enjekte edilen bir cron olayı, her tetiklendiğinde dosyayı yeniden yazar:

wp cron event list --fields=hook,next_run_relative,recurrence

Tanımadığınız bir kanca adı (çekirdeğe benzetilmiş wp_cache_check, _core_update_hook gibi isimler tipiktir) görürseniz onu kaydeden kodu bulun, sonra olayı silin:

wp cron event delete supheli_hook_adi

Sunucu crontab'ı. Panel dışı bir cron satırı uzak sunucudan kod indiriyor olabilir:

crontab -l
ls -la /etc/cron.d/ /var/spool/cron/crontabs/ 2>/dev/null

Veritabanı kayıtları. İçerik enjeksiyonunun kalıcı yarısı burada durur: enjekte edilmiş yazılar, wp_options içine yazılmış otomatik yüklenen (autoload) bir seçenek, mu-plugins klasörüne bırakılmış bir yükleyici. WP-CLI ile aramak en hızlısıdır:

# Veritabanının tamamında Japonca bir hece arayın
wp db search "の" --all-tables

# Otomatik yüklenen en büyük seçenekler — enjekte edilen kod genelde buradadır
wp db query "SELECT option_name, LENGTH(option_value) AS boyut FROM wp_options WHERE autoload='yes' ORDER BY boyut DESC LIMIT 15;"

# Son eklenen içerikler
wp post list --post_type=any --fields=ID,post_title,post_status,post_date --orderby=date --order=DESC --posts_per_page=30

Enjekte edilen yazıları silmeden önce URL listesini kaydedin; birazdan bu adreslere 410 döndüreceksiniz. Genel malware temizliğinin dosya tarafını WordPress malware temizleme yazısında ayrıntılı bulabilirsiniz.

Kalıcılık noktalarını tek tabloda özetlersek:

Bu altı noktadan biri açıkta kalırsa temizlik kalıcı olmaz; sıralamayı atlamadan uygulayın.

Yönetici Hesaplarını ve Search Console Sahipliklerini Denetleyin#

Saldırganın kalıcılık kurmak için kullandığı ikinci yol meşru bir yönetici hesabıdır. Bazı varyantlar bu hesabı kullanıcı listesinde gizler; bu yüzden panele değil veritabanına bakın:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp db query "SELECT u.ID, u.user_login, u.user_email, u.user_registered FROM wp_users u INNER JOIN wp_usermeta m ON u.ID = m.user_id WHERE m.meta_key = 'wp_capabilities' AND m.meta_value LIKE '%administrator%';"

İki sorgunun sonucu birbirini tutmuyorsa panelde gizlenen bir hesap var demektir. Tanımadığınız hesapları silin, tanıdıklarının parolasını yenileyin ve tüm oturumları düşürün:

wp user session destroy --all --all-users

Ardından wp-config.php içindeki güvenlik anahtarlarını yenileyin — bu işlem çalınmış oturum çerezlerini geçersiz kılar. Anahtarların ne işe yaradığını WordPress güvenlik anahtarları yazısında, dosyanın diğer sertleştirme ayarlarını wp-config güvenliği yazısında bulabilirsiniz.

Sonra Search Console tarafına dönün: Ayarlar → Kullanıcılar ve izinler ekranını açın. Tanımadığınız her mülk sahibini kaldırın, ardından ona ait doğrulama yöntemini de yok edin — kök dizindeki google*.html dosyasını silin veya DNS'teki ilgili TXT kaydını kaldırın. Doğrulama yöntemi ayakta kaldığı sürece kaldırdığınız sahip kendini yeniden ekleyebilir. Aynı denetimi Bing Webmaster Tools ve Yandex Webmaster için de yapın; ikisi de aynı yöntemle ele geçirilebiliyor.

Son olarak hosting paneli, FTP/SFTP, veritabanı kullanıcısı ve varsa Git deposu erişim bilgilerini değiştirin. Aynı hesapta barınan diğer siteleri de kontrol edin: paylaşımlı barındırmada çapraz bulaşma yaygındır ve temizlenmemiş tek bir site tüm hesabı yeniden enfekte eder.

İndeksi Toparlama: 410, Site Haritası ve Yeniden Değerlendirme Talebi#

Site temizlendikten sonra arama sonuçları kendiliğinden düzelmez; Google'a o adreslerin kalıcı olarak yok olduğunu söylemeniz gerekir. Doğru yanıt kodu 404 değil 410 Gone'dur: 410 "bu kaynak kalıcı olarak kaldırıldı" anlamına gelir ve indeksten düşürme sürecini hızlandırır.

Apache tarafında, tespit ettiğiniz URL kalıbı için:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^(jp|cheap|brand)/ - [G,L]
</IfModule>

Nginx tarafında:

location ~ ^/(jp|cheap|brand)/ {
    return 410;
}

Sonra doğrulayın:

curl -s -o /dev/null -w "%{http_code}\n" https://ornek.com/jp/brand-copy-42/
# beklenen çıktı: 410

Bu URL'leri robots.txt ile engellemeyin. Engellenen bir adresi Google tarayamaz, dolayısıyla 410 yanıtını hiç göremez ve URL indekste asılı kalır. Silinmesini istediğiniz sayfa taranabilir olmalıdır.

Kalan işler sırayla:

1. Search Console → Site Haritaları ekranından saldırganın gönderdiği haritaları kaldırın, kendi doğru haritanızı yeniden gönderin.
2. Çok görünür birkaç spam URL için Kaldırmalar aracını kullanın. Bu araç kalıcı silme değil, yaklaşık altı aylık geçici gizlemedir; asıl işi 410 yapar, kaldırma aracı yalnızca vitrini hızlı temizler.
3. Ana sayfanızı ve birkaç önemli sayfayı URL Denetimi ile yeniden dizine ekletin.
4. Güvenlik Sorunları ekranından yeniden değerlendirme talebi gönderin. Açıklamada üç şeyi net yazın: enfeksiyonun nasıl girdiğine dair tespitiniz, temizlik için attığınız adımlar (çekirdek yeniden kurulumu, arka kapıların kaldırılması, parola ve anahtar yenileme) ve tekrarını önlemek için aldığınız kalıcı önlemler. Yüzeysel bir metin, talebin reddedilme sebebidir.

Değerlendirme genelde birkaç gün sürer. Bu süre içinde 410 döndürdüğünüz sayfa sayısı arttıkça "Sayfalar" raporundaki dizine eklenmiş sayısının düştüğünü göreceksiniz; bu, temizliğin işe yaradığının en somut göstergesidir.

Temizlik Sonrası: Aynı Kapıdan Bir Daha Girilmesin#

Enfeksiyonun giriş noktası neredeyse her zaman üçünden biridir: güncellenmemiş bir eklenti, zayıf veya başka serviste de kullanılmış bir yönetici parolası, ya da aynı sunucudaki bakımsız ikinci bir site. Temizlik biter bitmez çekirdeği ve tüm eklentileri güncelleyin, kullanılmayan eklenti ve temaları devre dışı bırakmakla yetinmeyin, silin — pasif bir eklentinin dosyaları hâlâ web üzerinden çağrılabilir.

Sonrasında uploads klasöründe PHP çalıştırmayı sunucu seviyesinde kapatın, yönetici hesaplarına iki adımlı doğrulama ekleyin, dosya değişikliklerini izleyen bir bütünlük kontrolü kurun ve Search Console e-posta bildirimlerini açık tutun. Bu saldırının en pahalı tarafı temizliği değil, fark edilmeden geçen aylardır; erken uyarı zincirini kurmak tek seferlik bir iştir.

Sıkça Sorulan Sorular#

Sitem tarayıcıda normal görünüyorsa gerçekten hacklenmiş olabilir mi?#

Evet, hatta bu tür saldırıların ayırt edici özelliği budur. Enjekte edilen kod isteğin user-agent ve referrer başlıklarına bakar; arama motoru botuna spam sayfayı, size gerçek sayfayı döndürür. Tarayıcınızdan yaptığınız kontrol bu yüzden hiçbir şey göstermez. Doğru test, Googlebot kimliğiyle istek atmak veya Search Console'un URL Denetimi aracında "taranan sayfayı görüntüle" seçeneğiyle Google'ın aldığı HTML'i okumaktır.

Japonca sayfaları sildim ama birkaç saat sonra geri geldi, neden?#

Çünkü dosyaları yazan mekanizma hâlâ çalışıyor. Üç yerde olabilir: WordPress'in kendi zamanlanmış görevlerine eklenmiş bir olay, sunucu crontab'ına yazılmış bir satır, ya da veritabanında duran ve her sayfa yüklenişinde çalışan bir kod parçası. Yalnızca dosya silmek belirtiyi temizler, sebebi değil. Önce yazıcı mekanizmayı bulup kapatın, dosyaları ondan sonra silin.

Enfekte URL'lere 404 mü yoksa 410 mu döndürmeliyim?#

410 tercih edilir. 404 "şu an bulunamadı", 410 ise "kalıcı olarak kaldırıldı" anlamına gelir ve arama motorlarının o adresi indeksten düşürme sürecini hızlandırır. Her iki durumda da adresleri robots.txt ile engellememeye dikkat edin; engellenen bir URL taranamayacağı için yanıt kodunuz hiç görülmez ve sayfa indekste kalmaya devam eder.

Search Console'da tanımadığım bir mülk sahibi var, sadece silsem yeter mi?#

Yetmez. Sahiplik bir doğrulama yöntemine dayanır: kök dizindeki bir HTML dosyası, bir DNS TXT kaydı veya bir meta etiket. Sahibi kaldırıp doğrulama yöntemini yerinde bırakırsanız aynı kişi kendini birkaç tıklamayla yeniden ekleyebilir. Önce kullanıcıyı kaldırın, hemen ardından ilgili doğrulama dosyasını silin veya DNS kaydını kaldırın, sonra listeyi yeniden kontrol edin.

Yeniden değerlendirme talebim ne kadar sürede sonuçlanır, reddedilirse ne yapmalıyım?#

Genellikle birkaç gün içinde yanıt gelir. Reddedilirse bu, Google'ın hâlâ enfekte içerik gördüğü anlamına gelir — çoğunlukla gözden kaçmış bir arka kapı veya alt dizindeki ikinci bir WordPress kurulumu vardır. Ret bildirimindeki örnek URL'leri Googlebot kimliğiyle tek tek test edin, kalan enjeksiyonu temizleyin ve talebi tekrarlayın. Aynı metni yeniden göndermek yerine yeni bulgularınızı ekleyin.

Aynı hosting hesabındaki diğer sitelerimi de kontrol etmeli miyim?#

Kesinlikle. Paylaşımlı barındırmada tüm siteler aynı sistem kullanıcısı altında çalıştığı için bir sitedeki arka kapı komşu dizinlere yazabilir. Tek bir siteyi temizleyip diğerlerini atlarsanız enfeksiyon birkaç gün içinde geri döner. Hesaptaki her kurulumu ayrı ayrı tarayın, kullanılmayan eski kurulumları tamamen silin ve mümkünse siteleri farklı sistem kullanıcılarına ayırın.