Hacklink Nedir, Nasıl Tespit Edilir ve Temizlenir?

Sitenizde her şey “normal” görünürken, Google’da markanızın yanında alakasız başlıklar görmeye başladıysanız; ya da bir sabah organik trafik düşüşüyle uyanıp “Ne oldu şimdi?” diye ekrana bakakaldıysanız, büyük ihtimalle teknik SEO değil, güvenlik kaynaklı bir problemle karşı karşıyasınız. Google tarafında “hacked content”, “spam”, “gizli link” gibi sinyaller oluştuğunda, algoritma konuyu ciddiye alır: kullanıcı güvenliği ve arama kalitesi, sıralama hedefinizden daha önceliklidir. 

Ben bunu defalarca gördüm :/ Hacklink vakaları, çoğu zaman “SEO sorunu” gibi başlar ama aslında bir “olay müdahalesi” (incident response) disiplinini gerektirir. Yani sadece linki silip geçmek neredeyse hiçbir zaman yeterli olmaz; kök nedeni bulmadan temizlik kalıcı hâle gelmez. 

Aşağıda, hacklink’i sıfırdan tanımlayıp; tespit sürecini, temizleme adımlarını ve yeniden bulaşmayı önlemek için uygulanabilir güvenlik rutinini, danışman gibi samimi bir dille ama “gerçek hayatta işe yarayan” bir mantıkla anlatıyorum.

Hacklink Nedir?

Hacklink, en basit anlatımla: sitenize yetkisiz şekilde eklenmiş (ve çoğu zaman ziyaretçinin fark etmediği) dış bağlantılardır. Ama “link” dediğimiz şey yalnızca bir <a href> etiketi değildir; saldırganlar bazen linkleri görünmez yapar, bazen spam sayfalar üretir, bazen de arama motoruna farklı, kullanıcıya farklı içerik gösteren cloak (gizleme) tekniklerine başvurur. 

Google’ın spam politikalarında iki başlık özellikle önemli:

• Hacked content: Güvenlik açığı nedeniyle, izniniz olmadan eklenen içerik. 
• Hidden text and link abuse: Arama motorunu manipüle etmek için, insanın görmediği ama botun gördüğü şekilde gizlenen metin/link kullanımı (beyaz zemine beyaz yazı, CSS ile ekran dışına taşıma, opacity 0, font-size 0 gibi örneklerle). 

Türkiye’de “hacklink” kelimesi genellikle şu senaryoları kapsar:

• Footer’a, sidebar’a veya içerik bloklarına gizli/maskelemiş dış link enjekte edilmesi
• Sitenin içinde hiç bilmediğiniz dizinlerde otomatik üretilmiş spam sayfalar (özellikle alakasız ürün/anahtar kelime içerikleri)
• Arama sonuçlarında görünen ama site içinde dolaşırken fark edilmeyen cloaked sayfalar
• Bazen de kullanıcıyı arama motorundan gelince başka yere gönderen sneaky redirect türü yönlendirmeler 

Önemli ayrımı netleştireyim: “Hacklink” çoğu zaman sitenizden çıkan (outbound) spam linkler demektir. “Negatif SEO” diye konuşulan konu ise genelde başka sitelerden size gelen “kalitesiz link saldırısı” gibi tartışmalara kayar. Burada odak, sizin sitenizin ele geçirilip başka bir projeye link otoritesi taşıyan bir araca dönüştürülmesidir.

Hacklink Neden Tehlikeli?

Hacklink’i “birkaç link eklenmiş” diye hafife almak, pratikte üç farklı cephede bedel ödetir: SEO, marka güveni ve operasyonel risk.

Google tarafında iki rapor, işin ciddiyetini doğrudan gösterir:

• Google Search Console içindeki Security Issues report, sitenizde “hack” şüphesi veya ziyaretçiye zarar verebilecek davranışlar (phishing, malware, unwanted software vb.) tespit edildiğinde örnek URL’lerle uyarı üretir; bazı durumlarda arama sonuçlarında uyarı etiketi veya tarayıcıda ara sayfa (interstitial) görülebilir. 
• Aynı paneldeki Manual Actions report, insan incelemesiyle tespit edilen ihlallerin (spam girişimleri dahil) sayfa/sitede sıralamayı düşürmesine veya sonuçlardan çıkarılmasına neden olabilir; bazen kullanıcı tarafında görünür bir uyarı olmadan bile görünürlük kırılır. 

Yani risk yalnızca “trafik düşüşü” değildir; Google kullanıcıyı korumak için “site compromised” gibi sinyaller üretip tıklama oranınızı (CTR) da baltalayabilir. Google’ın güvenlik ekibi, arama sonuçlarında “This site may be compromised” benzeri etiketlerle kullanıcıyı uyarma yaklaşımını uzun süredir uyguluyor. 

SEO açısından en sık gördüğüm etkiler:

• Alakasız sorgularda görünme + alakasız sayfalara indeks (index bloat): Siteniz, sizin işinizle ilgisi olmayan kelimelerde görünür hâle gelir, kalite sinyali bozulur. Injected gibberish veya otomatik üretilmiş hack sayfalarında, ana amaç arama motorunu manipüle etmektir. 
• Sıralama kırılması: “Yeni içerik gireyim düzelir” yaklaşımı işlemez; güvenlik sorunu çözülmeden toparlanma gecikir. 
• Manuel işlem riski: “Hacked site” gibi başlıklar bazen “partial match” şeklinde bazı URL’leri etkiler, bazen daha geniş etki yaratır. Google, hack temizlendikten sonra kimi durumlarda manuel işlemi otomatik kaldırmayı test ettiğini bile paylaştı; yine de panelde uyarı varsa inceleme talebi mantıklıdır. 

Operasyonel tarafta ise daha sinsi bir risk var: Hacklink çoğu zaman “tek bir satır” değildir; saldırgan çoğu vakada kalıcılık için arka kapı (backdoor) bırakır. Siz linki silseniz bile, açık kapatılmadıysa aynı gün geri gelir. Incident response disiplininin “sürekli iyileştirme” tarafı tam da burada önem kazanır.

Hacklink Nasıl Tespit Edilir?

Tespit sürecini iki katmanlı düşünün: “hızlı teşhis” ve “kök neden analizi”. Hızlı teşhis, sorunu doğrular; kök neden analizi ise bir daha yaşanmaması için şarttır.

Hızlı teşhis için ilk üç ekran:

1. Search Console’da Security Issues raporu: Google bir değerlendirme yaptığında sitenizde hack veya zararlı davranış görürse bu raporda örnek URL’ler gösterir; listelenen URL’lerin “tam liste” olmadığını özellikle vurgular. Dolayısıyla “örnek URL temizledim” diyerek bırakmak doğru olmaz; problem kökten çözülmelidir. 
2. Search Console’da Manual Actions raporu: Manuel işlem raporu, insan değerlendirmesiyle tespit edilen ihlalleri listeler. Çoğu manuel işlem, sayfaların daha düşük sıralanmasına veya sonuçlardan çıkarılmasına neden olabilir. Temizlik sonrası aynı ekrandan “Request Review” süreci yönetilir. 
3. Google’da basit site: kontrolleri: Cloaked hack’lerde bile site:alanadiniz.com araması, Google’ın indekslediği anormal URL’leri yakalamada çok faydalıdır. Google’ın kendi hack temizleme rehberleri de bu yaklaşımı önerir. 

Burada pratik bir yöntem: site:alanadiniz.com aramasını yapıp ilk 2-3 sayfada URL yapısına bakın. Tanımadığınız klasörler, anlamlı olmayan dizin adları, sıra dışı parametreler, alakasız başlık/meta… Bunlar kırmızı bayraktır. Injected gibberish vakalarında “kelime yığını” gibi URL’ler zaten tipiktir. 

Ek sinyaller (çoğu kişi gözden kaçırıyor):

• Search Console’da siteye sizin bilmediğiniz bir kullanıcının/owner’ın eklenmesi: Özellikle Japanese keyword hack türlerinde saldırganın Search Console mülk sahipliğine kendini ekleyebildiği senaryolar raporlanıyor. Ayarlar kısmında kullanıcıları kontrol etmek şart. 
• Arama sonuçlarında görünen snippet’in “sizden çıkmamış gibi” durması: Alakasız ürün metinleri, başka dilde içerik, garip kategori adları. Bu tip hack’ler arama görünürlüğünü manipüle etmeyi hedefler. 
• Sitede normal gezinirken görünmeyen ama Google botuna gösterilen içerik: “Cloaking” dediğimiz senaryoda, kullanıcıya temiz sayfa, bota spam sayfa sunulur. 

Kök Neden Analizi: Hacklink Sitenize Nereden Giriyor?

Kök neden analizi, teknik olarak iki temel yere bakar: dosya sistemi ve veri tabanı.

• Dosya tarafı: .htaccess, tema dosyaları, header/footer şablonları, beklenmedik PHP dosyaları, cron benzeri çalışan script’ler, “masum görünümlü” ama şifrelenmiş/obfuscate edilmiş kod blokları. web.dev’in “cloaked keywords and links hack” rehberinde, saldırganların .htaccess üzerinden rewrite kurallarıyla cloaked sayfalar üretebildiği detaylı anlatılır. 
• Veri tabanı tarafı: İçerik tablolarına gizli link enjekte edilmesi, widget/ayar alanlarına base64 benzeri camuflajlı kod, admin kullanıcılarının çoğalması.

Saldırı vektörü tarafında en çok karşılaşılan nedenler, web uygulaması güvenliği literatürüyle de uyumlu: zayıf şifreler, güncellenmemiş eklentiler/temalar, yetki yükseltme, enjeksiyon açıkları. Örneğin SQL injection, saldırganın veri tabanını okumasına/değiştirmesine kadar gidebilen bir risk sınıfıdır. 

Benim gözlemim: Hacklink vakalarının önemli bir kısmı, “tek bir açık” değil, birkaç küçük ihmalin birleşimiyle büyüyor. Admin panel şifresi zayıf + güncelleme gecikmiş + dosya izinleri gevşek… Sonuç: sitenin otoritesi bir başkasının link kaynağına dönüşüyor.

Hacklink nasıl temizlenir?

Temizlik tarafını “SEO checklist” gibi değil, “olay müdahalesi” gibi ele almak gerekir. NIST, modern olay müdahalesini siber risk yönetiminin parçası olarak yorumlar; yalnızca müdahale değil, hazırlık ve iyileştirme döngüsünü de vurgular. 

Benim uyguladığım yaklaşım, pratikte beş fazda ilerler:

İzolasyon ve hasar kontrolü

Öncelik, saldırganın sisteme erişimini kesmek ve yayılımı durdurmaktır. Google’ın hacklenmiş siteler için önerdiği klasik yaklaşım, mümkünse siteyi geçici olarak offline almak; değilse 503 döndürerek taramayı (crawl) geçici olarak frenlemektir. Hosting tarafı desteği de özellikle paylaşılmış sunucularda kritik olabilir. 

Bu aşamada pratik adımlar:

• Tüm admin hesaplarının şifrelerini değiştirin (panel, FTP/SFTP, DB, e-posta).
• Bilinmeyen kullanıcıları kaldırın (özellikle Search Console kullanıcı/izin listesi dahil). 
• Mümkünse saldırı anındaki logları korumaya alın (sonradan kök neden bulmayı kolaylaştırır). 

Temiz bir referans noktası oluşturma

web.dev rehberleri temizlikten önce, sitenin tam yedeğini “offline” almayı özellikle önerir. Çünkü temizlik sırasında bir dosyayı yanlışlıkla silmek, siteyi daha da bozabilir; ayrıca karşılaştırma yapmanız gerekir. 

Burada kritik detay: “Yedek aldım, bitti” değil. Yedek, saldırgan kodu da içeriyor olabilir. Yedek, geri dönmek için değil; karşılaştırmak ve kanıt tutmak için de lazımdır.

Temizlik: Hacklink Hangi Katmana Yerleşmiş?

Hacklink’in yerleştiği yer, temizlik yöntemini belirler. En yaygın üç senaryo:

• Şablon/tema içine enjekte edilmiş linkler: header.php/footer.php veya benzeri şablonlarda, görünmeyecek şekilde CSS ile gizlenmiş link blokları.
• .htaccess ve yönlendirme zincirleri: Cloaked hack’lerde .htaccess üzerinden botlara özel sayfa üretimi veya yönlendirmeler görülebilir. web.dev rehberinde .htaccess içindeki şüpheli rewrite kuralları ve referans verilen PHP dosyaları üzerinden ilerleme mantığı anlatılır. 
• Otomatik üretilmiş spam sayfalar: Injected gibberish veya Japanese keyword hack gibi vakalarda, rastgele dizinlerde çok sayıda spam sayfa üretimi görülebilir. Google’ın NoHacked serisi, injected gibberish hack’te “siteye eklenmiş gibi görünen” spam sayfaların tipik olduğunu belirtir. 

Temizlikte iki yaklaşım var:

• Son iyi yedekten geri dönmek (en hızlı, genellikle en temiz)
• Manuel temizlemek (daha uzun, ama bazı sistemlerde mecburi)

Google’ın Security Issues raporu da temizlik için ya son iyi yedekle değiştirmeyi ya da spam içeriği kendiniz kaldırmayı bir seçenek olarak anlatır. 

Benim bakış açım şu: Eğer elinizde “gerçekten temiz” bir yedek varsa ve yedeğin alındığı günle saldırının başladığı gün arasında net bir çizgi çekebiliyorsanız, geri dönüş çoğu zaman daha sağlıklıdır. Ama “yedekler zaten şüpheli” veya “iş kritik ve geri dönüş büyük veri kaybı yaratır” diyorsanız, manuel temizlik kaçınılmazdır.

Kök nedeni kapatma: aynı delikten tekrar girmesin.

Burada en çok unutulan konu, “vulnerable yüzey”in kapanmasıdır. Google’ın injected gibberish fix yazısında da vurgulanan fikir net: Zararlı dosyayı kaldırdıktan sonra, siteyi ele geçirmeye izin veren açığı bulup kapatmak gerekir; aksi hâlde yeniden hacklenme riski yükselir. 

Kök neden kapamada en sık aksiyonlar:

• Uygulama/tema/eklenti güncellemeleri
• Gereksiz bileşenlerin kaldırılması
• Kullanıcı yetkilerinin daraltılması
• Dosya izinlerinin sıkılaştırılması
• Güvenli uzaktan yönetim (SFTP/SSH, 2FA, IP kısıtlama) 

Özellikle sunucu tarafında, NIST’in web sunucusu güvenliği kılavuzunda “uzaktan yönetim” için net öneriler var: güçlü kimlik doğrulama, hangi hostların bağlanabileceğini kısıtlama, şifreli protokoller kullanma (SSH/HTTPS), en az ayrıcalık (least privilege), internetten doğrudan yönetimi kısıtlama gibi. 

Ayrıca genel sunucu güvenliğinde “least privilege” ve “defense in depth” (katmanlı savunma) yaklaşımı; hem fonksiyonları minimumda tutmayı hem de bir katman bozulduğunda diğerinin sistemi korumasını önerir. 

Google Tarafı: Temizlik Bitti, Peki Görünürlük ne Olacak?

Temizliğin “SEO’ya yansıması” için arama motoru tarafında da adım gerekir:

• Security Issues raporunda listelenen tüm sorunları, tüm örnek URL’lerle sınırlı kalmadan site genelinde giderin; Google yalnızca “bazı sayfaları” düzeltmenin kısmi geri dönüş garantisi olmadığını belirtir. 
• Her şey temizlendikten sonra Search Console üzerinden ilgili raporda Request Review gönderin. Google, iyi bir inceleme talebinin problemi net anlattığını, yapılan adımları özetlediğini ve sonucu belgelediğini söyler. 
• Eğer spam URL’ler indeks olduysa, Google’ın URL kaldırma yaklaşımı “gizleme” (temporary hide) şeklinde çalışır; kalıcı temizlik için kaynağı kaldırmak ve doğru durum kodlarıyla yönetmek gerekir. 

Google’ın “Request a review” rehberi, sitenin tehlikeli olarak işaretini kaldırmak için inceleme talebinin şart olduğunu açıkça yazar. 

Pro Tip: Temizliğin bittiğine “siteyi tarayıcıda gezdim, sorun yok” diye karar vermeyin. Cloaking vakalarında ziyaretçiye temiz, bota kirli içerik gösterilebilir. Bu yüzden URL Inspection benzeri kontrollerde “rendered” çıktılara bakmak, farklı cihaz/oturumlarla örnek URL’leri test etmek ve Search Console tarafındaki örnek listeyle yetinmemek çok iş kurtarır.

Hacklink’ten Nasıl Korunursunuz?

Hacklink temizliği başarıldığında asıl hedef “normalleşmek” değil; “daha zor hedef olmak” olmalı. NIST’in yaklaşımında olay müdahalesi, iyileştirme ve risk yönetimiyle birlikte düşünülür; alınan derslerin hızlıca süreçlere yansıtılması özellikle vurgulanır. 

Benim önerdiğim korunma çerçevesi üç katman:

➥ Teknik sertleştirme (hardening)

NIST’in genel sunucu güvenliği yaklaşımı, bilinen açıkları yamalamayı ve her kullanıcıya yalnızca gerekli fonksiyonları sunmayı (least privilege) temel ilke olarak ele alır. 

Web sunucusu tarafında da iki kritik alanı özellikle öne çıkarıyorum:

• Uzaktan yönetimi disipline etmek: NIST 800-44; güçlü kimlik doğrulama, IP ile kısıtlama, şifreli protokoller, en az ayrıcalık gibi pratik adımları önerir. 
• Dinamik içerik alanlarını ayırmak: Yazılabilir klasörde script çalıştırmayacak şekilde ayrıştırmak, yazma+çalıştırma izinlerini aynı klasörde tutmamak gibi prensipler, saldırı yüzeyini ciddi küçültür. 

➥ Operasyonel rutin

Hacklink’i yakalamanın en hızlı yolu, “sinyal” toplayan basit bir rutin kurmak:

• Haftalık site: kontrolleri (marka adı + alakasız kelimelerle)
• Search Console’da Security Issues + Manual Actions ekranlarına düzenli bakış
• Sunucu loglarında son günlerde oluşan sıra dışı istekler / yeni dosya hareketleri
• Yeni kullanıcı/izin kontrolü (Search Console dahil) 

NIST’in web sunucusu güvenliği dokümanı, zafiyet taraması ve testlerinin düzenli yapılmasının, yamaların güncel tutulmasının önemini ayrıca vurgular. 

➥ İçerik yönetişimi (content governance)

Hacklink’in zararı yalnızca “link” değildir; sitenin güvenilirlik algısı aşınır. Bu yüzden içerik tarafında da:

• Admin panel erişimlerinin kimde olduğu,
• Editoryal süreç (kim yayınlar, kim kontrol eder),
• Güvenlik güncellemelerinin kimin sorumluluğunda olduğu
  gibi netlikler, E-E-A-T algısı için dolaylı ama etkili katkı verir. 

Pro Tip: Sitede “gizli link” avına çıkarken yalnızca HTML aramayın. Hacklink bazen widget ayarlarına, bazen header injection alanlarına, bazen de .htaccess üzerinden üretilen sanal sayfalara saklanır. O yüzden temizlikte “dosya + veri tabanı + sunucu yapılandırması” üçlüsünü birlikte ele aldığınızda, tekrar bulaşma ihtimali dramatik düşer.

Sonuç

Hacklink konusu, klasik SEO başlıklarından farklı olarak “güvenlik” ile “arama görünürlüğü”nü aynı potada eritiyor. Google’ın yaklaşımı da tam burada netleşiyor: Ziyaretçiye zarar verme ihtimali olan veya izinsiz eklenmiş içerikler, arama kalitesini düşürdüğü için sonuçlarda baskılanabilir; kimi durumlarda güvenlik uyarıları görünür hâle gelebilir.

Son bir not: Hacklink temizliği sonrası “hemen eski sıralamaya döner miyim?” sorusu çok geliyor.

Burada tek bir sihirli süre yok; fakat Search Console raporlarında sorunların giderildiğini doğrulamak, inceleme talebini doğru anlatımla göndermek ve siteyi tekrar güvenli bir çizgiye çekmek, toparlanma sürecini hızlandıran en makul yoldur.

---

Kaynak Notları

Bu içerikte dayandığım yabancı kaynakların ana başlıkları aşağıdadır:

İncelediğim güvenlik standartları ve rehberleri:

• NIST – Incident Response Recommendations (SP 800-61r3) 
• NIST – Guidelines on Securing Public Web Servers (SP 800-44 v2) 
• NIST – Guide to General Server Security (SP 800-123) 
• OWASP – SQL Injection açıklaması (risk örneği)

Google / Search ekosistemi:

• Google Search Central – Spam Policies (Hacked content, Hidden text & link abuse) 
• Search Console Help – Security Issues report 
• Search Console Help – Manual Actions report 
• Google Search Blog / NoHacked serisi – Injected gibberish & common hack cases 
• Google Security Blog – hacked site uyarıları yaklaşımı 
• web.dev – Fix the Japanese keyword hack, Fix the cloaked keywords and links hack, Request a review