GSC Manuel İşlemler ve Güvenlik

Manuel işlem, arama motoru kalite ekibinin bir web sitesini insan denetçi aracılığıyla inceleyip belirlenen kural ihlali nedeniyle doğrudan yaptırım uygulamasıdır. 2026 itibarıyla SpamBrain destekli otomatik tespit kapasitesinin artmasıyla birlikte manuel işlem sayısı azalmış ancak uygulanan yaptırımların şiddeti ve kapsamı genişlemiştir. Bu durum, manuel işlem ve güvenlik panelinin düzenli takibini teknik SEO hijyeninin vazgeçilmez bir bileşeni haline getirdi.

Manuel İşlem ile Algoritmik Ceza Arasındaki Temel Fark

Manuel işlem, bir insan denetçinin siteyi inceleyip bilinçli olarak uyguladığı yaptırımdır. Search Console'da bildirim olarak görünür ve düzeltme sonrası yeniden inceleme talebi gerektiren resmi bir süreçtir. Algoritmik ceza ise arama motoru algoritmasının otomatik olarak uyguladığı sıralama düşüşüdür. Bildirim gelmez ve düzeltme sonrası kaldırılması algoritmik güncellemeye bağlıdır.

Bu ayrım operasyonel açıdan kritiktir. Manuel işlemde ne yapılması gerektiği açıkça bildirilir, düzeltme adımları nettir ve süreç takip edilebilir. Algoritmik cezada ise sorunun kaynağı tahmin edilmek zorundadır ve düzeltmenin etkisi belirsiz bir süre sonra gözlemlenir. Search Console'da Güvenlik ve Manuel İşlemler > Manuel İşlemler sayfasının boş olması, sitenin manuel yaptırım almadığını doğrular. Ancak boş sayfa algoritmik sorun olmadığı anlamına gelmez.

Manuel İşlem Türleri ve Etki Kapsamları

Manuel işlemler site genelini veya belirli sayfaları hedefleyebilir. Site geneli işlemler tüm URL'lerin sıralamasını etkilerken sayfa bazlı işlemler yalnızca belirtilen URL'leri etkiler. Her işlem türü farklı bir kural ihlaliyle ilişkilidir.

Temel manuel işlem kategorileri:

• Doğal olmayan gelen bağlantılar sitenin backlink profilinde manipülatif bağlantılar tespit edildiğinde uygulanır ve en yaygın manuel işlem türüdür.
• Doğal olmayan giden bağlantılar siteden dışarıya yönlendirilen satılmış veya manipülatif bağlantılar tespit edildiğinde tetiklenir.
• İnce içerik orijinal değeri düşük, otomatik üretilmiş veya kopyalanmış içerik barındıran sayfalarda uygulanır.
• Kullanıcı tarafından oluşturulan spam yorum, forum veya profil alanlarındaki spam içerik nedeniyle verilir.
• Gizli metin veya gizli bağlantı CSS veya JavaScript ile kullanıcıdan gizlenen ancak tarayıcıya gösterilen içerik tespit edildiğinde uygulanır.
• Cloaking ve hatalı yönlendirmeler arama motoru tarayıcısına ve kullanıcıya farklı içerik sunulduğunda devreye girer.

Doğal Olmayan Gelen Bağlantılar İşleminin Çözüm Süreci

Bu işlem, sitenin backlink profilinde satın alınmış, değiştirilmiş veya manipülatif bağlantılar tespit edildiğinde uygulanır. Çözüm süreci üç aşamalıdır: zararlı bağlantıların tespiti, kaldırma veya reddetme ve yeniden inceleme talebi gönderimi.

İlk aşamada backlink profilinin tamamı dışa aktarılır ve her bağlantı manuel olarak değerlendirilir. Spam siteleri, PBN ağları ve aşırı optimize edilmiş anchor text taşıyan bağlantılar işaretlenir. İkinci aşamada işaretlenen bağlantıların kaynak sitelerine kaldırma talebi gönderilir. Yanıt alınamayan domainler disavow dosyasına eklenir. Üçüncü aşamada yapılan tüm düzeltmeler belgelenir ve yeniden inceleme talebiyle birlikte sunulur.

Disavow dosyası Search Console'un disavow aracına yüklenir:

    
# PBN ağı bağlantıları
domain:spam-site-1.com
domain:spam-site-2.com
domain:spam-site-3.com

# Satın alınmış link tespit edilen siteler
domain:paid-link-network.com
https://ornek.com/spam-sayfa       
    

Dosya formatı UTF-8 kodlamalı düz metin olmalıdır. Her satır bir domain veya URL direktifi içerir. Yorum satırları # ile başlar ve açıklama amacıyla kullanılır.

Doğal Olmayan Giden Bağlantılar İşleminin Çözümü

Bu işlem, siteden dışarıya satılan veya manipülatif amaçla yerleştirilen bağlantılar tespit edildiğinde uygulanır. Çözüm, zararlı giden bağlantıların kaldırılması veya rel="nofollow" ya da rel="sponsored" özniteliğiyle işaretlenmesidir.

Site genelinde giden bağlantı denetimi yapılmalıdır. Özellikle sponsorlu içerikler, misafir yazılar ve reklam alanlarındaki bağlantılar kontrol edilir. Ücretli yerleşim karşılığı oluşturulan bağlantıların tamamı rel="sponsored" özniteliğiyle işaretlenmelidir. Bu işaretleme yapılmadan yeniden inceleme talebi gönderilirse talep reddedilir.

    
<!-- Düzeltme öncesi (ihlal) -->
<a href="https://reklam-veren.com">Ürün İncelemesi</a>

<!-- Düzeltme sonrası (uyumlu) -->
<a href="https://reklam-veren.com" rel="sponsored">Ürün İncelemesi</a>      
    

Tüm sponsorlu ve ücretli bağlantıların tespit edilmesi için site genelinde tarama yapılmalıdır. Screaming Frog veya benzeri araçlarla tüm outbound linkler dışa aktarılır ve her birinin rel özniteliği kontrol edilir.

İnce İçerik İşleminin Kapsamı ve Düzeltme Stratejisi

İnce içerik (thin content) işlemi, orijinal değeri düşük sayfalarda uygulanır. Otomatik üretilmiş içerik, affiliate sitelerindeki sığ ürün açıklamaları, başka sitelerden kopyalanmış metin ve doorway sayfaları bu kategoriye girer.

Düzeltme stratejisi içerik kalitesinin toptan yükseltilmesini gerektirir. İnce içerikli sayfalar üç gruba ayrılır: güncellenecek sayfalar, birleştirilecek sayfalar ve kaldırılacak sayfalar. Trafiği ve backlink'i olan sayfalar güncellenerek derinleştirilir. Benzer konuları kapsayan birden fazla sığ sayfa tek bir kapsamlı sayfada birleştirilir ve eski URL'ler 301 ile yönlendirilir. Hiçbir değer taşımayan sayfalar tamamen kaldırılır ve 410 (Gone) durum koduyla işaretlenir.

Gizli Metin ve Gizli Bağlantı İşleminin Teknik Tespiti

Gizli metin, kullanıcıya görünmeyen ancak arama motoru tarayıcısına gösterilen içeriktir. Arka plan rengiyle aynı renkte metin, sıfır font boyutu, ekran dışına konumlandırma (text-indent: -9999px) ve display: none ile gizlenen anahtar kelime blokları bu ihlale girer.

Tespit için Chrome DevTools kullanılarak sayfadaki tüm öğelerin görünürlüğü kontrol edilir. Komut satırında hızlı tarama:

    
// DevTools konsolunda çalıştırın
document.querySelectorAll('*').forEach(el => {
  const style = getComputedStyle(el);
  const isHidden = style.display === 'none' || 
                   style.visibility === 'hidden' || 
                   style.opacity === '0' ||
                   parseInt(style.fontSize) === 0 ||
                   (style.color === style.backgroundColor && el.textContent.trim().length > 0);
  
  if (isHidden && el.textContent.trim().length > 20) {
    console.warn('Gizli içerik tespit edildi:', el.tagName, el.className);
    el.style.outline = '3px solid red';
  }
});
    

Bu betik, gizlenmiş ve 20 karakterden uzun metin içeren tüm öğeleri tespit eder. Erişilebilirlik amaçlı gizlenen öğeler (screen reader metinleri) bu tespitte false positive üretebilir. aria-label ve visually-hidden sınıfı kullanan öğeler erişilebilirlik amacıyla gizlenir ve ihlal oluşturmaz. Ayrım, gizlemenin amacına göre yapılır.

Cloaking ve Hatalı Yönlendirme İşleminin Analizi

Cloaking, arama motoru tarayıcısına ve kullanıcıya farklı içerik sunulmasıdır. User-agent tabanlı cloaking, IP tabanlı cloaking ve JavaScript tabanlı cloaking olmak üzere üç ana yöntemle gerçekleştirilir. Her üç yöntem de kalite kurallarının ciddi ihlalidir.

Kasıtlı olmayan cloaking durumları da mevcuttur. JavaScript ile render edilen içerik Googlebot tarafından farklı görüntülendiğinde teknik cloaking oluşabilir. Bu durumun tespiti için URL Denetim aracındaki "Canlı URL'yi test et" özelliği kullanılır. Render edilmiş HTML ile sayfa kaynağı karşılaştırılır. Kritik içeriğin yalnızca JavaScript ile yüklendiği ve sunucu tarafında render edilmediği sayfalar, kasıtsız cloaking riski taşır. SSR veya prerendering uygulaması bu riski ortadan kaldırır ve tarayıcı ile kullanıcının aynı içeriği görmesini garanti eder.

Yeniden İnceleme Talebi Hazırlama Protokolü

Yeniden inceleme talebi, manuel işlemin kaldırılması için resmi başvuru sürecidir. Talebin kalitesi, inceleme sonucunu doğrudan etkiler. Yetersiz veya genel ifadeler içeren talepler reddedilir. Detaylı, kanıt destekli ve samimi bir talep hazırlanmalıdır.

Etkili bir yeniden inceleme talebi şu bileşenleri içermelidir: sorunun kabul edilmesi (genel veya belirsiz ifadeler kullanmadan), yapılan düzeltmelerin spesifik olarak listelenmesi, kanıt dökümanları (kaldırma talep e-postaları, disavow dosyası, düzeltme öncesi/sonrası ekran görüntüleri) ve gelecekte ihlallerin tekrarlanmaması için alınan önlemler.

Talep metni örneği yapısı:

    
1. Sorunun kabulü: "Sitemize yönlendirilen [X] adet doğal olmayan 
   bağlantı tespit ettik."

2. Yapılan düzeltmeler:
   - [Y] domain sahibine kaldırma talebi gönderildi
   - [Z] domaine yanıt alınamadı, disavow dosyasına eklendi
   - Disavow dosyası [tarih] tarihinde yüklendi

3. Kanıtlar:
   - Kaldırma talebi e-posta kayıtları ektedir
   - Disavow dosyası [X] domain içermektedir

4. Önleme planı: Aylık backlink denetimi takvimi oluşturuldu,
   yeni bağlantı ortaklıkları SEO ekibi onayından geçecektir.
    

Yeniden İnceleme Sürecinin Zaman Çizelgesi

Yeniden inceleme talebi gönderildikten sonra ortalama 2 ila 4 hafta içinde yanıt alınır. Yoğun dönemlerde bu süre 6 haftaya kadar uzayabilir. Yanıt üç şekilde olabilir: işlem kaldırıldı, kısmi kaldırma veya talep reddedildi.

İşlem kaldırıldığında sıralama iyileşmesi anında başlamaz. Dizin güncellemesinin tamamlanması ve sayfaların yeniden değerlendirilmesi 4 ila 12 hafta sürer. Bu süreçte sabırlı olmak ve ek teknik iyileştirmeler yapmak gerekir. Talep reddedildiğinde ret gerekçesi incelenmeli, eksik kalan düzeltmeler tamamlanmalı ve yeni bir talep gönderilmelidir. Aynı talebi değişiklik yapmadan tekrar göndermek sonucu değiştirmez.

Güvenlik Sorunları Raporunun Kapsamı

Search Console'un Güvenlik ve Manuel İşlemler > Güvenlik Sorunları raporu, sitede tespit edilen güvenlik tehditlerini listeler. Malware (zararlı yazılım), phishing (kimlik avı), unwanted software (istenmeyen yazılım) ve social engineering (sosyal mühendislik) kategorilerinde tehditler raporlanır.

Güvenlik sorunu tespit edildiğinde arama motoru, kullanıcıları uyarmak için arama sonuçlarında "Bu site güvenli olmayabilir" mesajı gösterir. Chrome tarayıcısı ise kırmızı uyarı ekranıyla sitenin tehlikeli olduğunu bildirir. Bu uyarılar organik trafiği yüzde 90'a kadar düşürebilir çünkü kullanıcılar uyarıya rağmen siteyi ziyaret etmez. Dolayısıyla güvenlik sorunlarının çözümü, tüm SEO çalışmalarından daha acil öncelik taşır.

Hack Edilmiş Site Tespiti ve Kurtarma Süreci

Site hack'lenmesi en yaygın güvenlik sorunudur. Hack türleri: içerik enjeksiyonu (spam sayfa veya bağlantı eklenmesi), yönlendirme hack'i (kullanıcıların zararlı sitelere yönlendirilmesi) ve malware dağıtımı (ziyaretçilere zararlı yazılım indirilmesi) olarak sınıflandırılır.

Kurtarma süreci şöyle işler: önce saldırı vektörü belirlenir. Güncel olmayan CMS, eklenti veya tema açıkları en sık saldırı noktalarıdır. Ardından enfekte dosyalar tespit edilir. Sunucu log dosyalarında şüpheli erişim kalıpları aranır:

    
# Son 7 günde değiştirilen PHP dosyalarını listele
find /var/www/html -name "*.php" -mtime -7 -type f

# Şüpheli kod kalıplarını tara
grep -rl "eval(base64_decode" /var/www/html/
grep -rl "exec(\$_" /var/www/html/
grep -rl "shell_exec" /var/www/html/
    

Bu komutlar, son 7 günde değiştirilen PHP dosyalarını ve yaygın hack imzalarını (eval, base64_decode, shell_exec) barındıran dosyaları tespit eder. Tespit edilen dosyalar temizlenir veya yedeğe geri dönülür. CMS, eklentiler ve temalar en güncel sürüme güncellenir. Tüm şifreler (FTP, veritabanı, CMS admin) değiştirilir.

Malware Tespiti ve Temizleme Protokolü

Malware, sitenin koduna enjekte edilen zararlı JavaScript veya PHP parçacıklarıdır. Bu kod, ziyaretçilerin bilgisayarlarına zararlı yazılım indirmeye çalışır veya kullanıcıyı phishing sitelerine yönlendirir. Tespit için hem sunucu tarafı hem de istemci tarafı tarama yapılmalıdır.

Sunucu tarafında ClamAV ile dosya sistemi taraması:

    
# ClamAV ile site dizinini tara
clamscan -ri /var/www/html/ > malware-rapor.txt

# Sonuçları incele
grep "FOUND" malware-rapor.txt
    

İstemci tarafında ise sitenin JavaScript çıktısı incelenir. Chrome DevTools'ta Network sekmesinde bilinmeyen domainlere yapılan istekler kontrol edilir. Zararlı script'ler genellikle dinamik olarak oluşturulur ve doğrudan kaynak kodunda görünmez. document.write, eval ve createElement('script') kalıplarını barındıran şüpheli kod blokları tespit edilmelidir.

Phishing İçerik Tespiti ve Kaldırma

Phishing sayfaları, meşru sitelerin giriş sayfalarını taklit ederek kullanıcı kimlik bilgilerini çalmayı hedefler. Hack sonucu siteye eklenen phishing sayfaları genellikle gizli dizinlerde barındırılır ve site sahibi farkında olmaz.

Tespit için Search Console güvenlik raporunun yanı sıra site genelinde bilinmeyen dizinler ve dosyalar taranmalıdır:

    
# Son 30 günde oluşturulan HTML ve PHP dosyalarını listele
find /var/www/html -name "*.html" -o -name "*.php" | \
  xargs ls -lt | head -50

# Bilinen CMS dosyaları dışında kalan dosyaları tespit et
diff <(find /var/www/html -type f | sort) \
     <(cat cms-dosya-listesi.txt | sort) | grep "^<"
    

İkinci komut, CMS'in orijinal dosya listesiyle mevcut dosyaları karşılaştırır ve eklenen bilinmeyen dosyaları ortaya çıkarır. Tespit edilen phishing sayfaları derhal silinir, erişim yolu kapatılır ve güvenlik açığı giderilir.

HTTPS Güvenlik Yapılandırmasının Denetimi

SSL/TLS sertifikası yalnızca şifreleme sağlamaz, arama motoru güven sinyali olarak da işlev görür. Sertifika süresi dolduğunda veya yapılandırma hatası oluştuğunda, tarayıcı güvenlik uyarısı gösterir ve organik trafik çöker.

SSL yapılandırma denetimi için:

    
# Sertifika bitiş tarihini kontrol et
echo | openssl s_client -connect site.com:443 2>/dev/null | \
  openssl x509 -noout -dates

# SSL yapılandırma puanını kontrol et
curl -s "https://api.ssllabs.com/api/v3/analyze?host=site.com&publish=off" | \
  python3 -c "import sys,json; d=json.load(sys.stdin); \
  print(f'Grade: {d[\"endpoints\"][0][\"grade\"]}')"
    

İlk komut sertifikanın bitiş tarihini gösterir. Sertifika süresinin dolmasına 30 günden az kaldığında yenileme işlemi başlatılmalıdır. İkinci komut SSL Labs API'si ile SSL yapılandırma puanını kontrol eder. A+ puanı hedeflenmelidir. Mixed content (HTTPS sayfada HTTP kaynak yükleme) hataları da güvenlik uyarısı tetikler ve Content Security Policy header'ı ile engellenmelidir.

Usta Notu: Kriz Anının Belirleyiciliği

Kriz anında doğru hareket eden ile panik yapan arasındaki fark tam burada belirir: manuel işlem veya güvenlik sorunu bildirimi alan site sahiplerinin büyük çoğunluğu panikle aceleci kararlar verir. Disavow dosyasına tüm backlink'leri toptan ekler, yüzlerce sayfayı siler veya siteyi komple kapatır. Doğru yaklaşım cerrahi hassasiyetle hareket etmektir. Sahadaki tecrübemiz gösteriyor ki manuel işlem kurtarma sürecinde en kritik adım ilk 48 saattir. Bu sürede yapılacak ilk hamle düzeltme değil, belgelemedir. Mevcut durumun eksiksiz bir fotoğrafını çekin: tüm backlink verisini dışa aktarın, etkilenen sayfaların listesini oluşturun ve sunucu loglarını yedekleyin. Bu belgeleme, yeniden inceleme talebinde sunulacak kanıtların temelini oluşturur ve panik kararlarının önüne geçer.

Content Security Policy ve XSS Koruması

Content Security Policy (CSP) header'ı, sitede hangi kaynaklardan script, stil ve medya yüklenebileceğini kısıtlar. XSS (Cross-Site Scripting) saldırılarını engelleyen en etkili savunma katmanıdır. Enjekte edilen zararlı script'ler CSP politikasıyla eşleşmediğinde tarayıcı tarafından bloklanır.

Nginx yapılandırmasında CSP header'ı ekleme:

    
add_header Content-Security-Policy "
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com https://www.google-analytics.com;
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  connect-src 'self' https://www.google-analytics.com;
  frame-src 'self' https://www.youtube.com;
" always;
    

Bu politika, yalnızca belirtilen kaynaklardan script yüklenmesine izin verir. Bilinmeyen bir kaynaktan enjekte edilen zararlı script otomatik olarak engellenir. CSP yapılandırması başlangıçta "Report-Only" modunda çalıştırılmalı ve engellenecek kaynaklar doğrulandıktan sonra zorunlu moda geçirilmelidir.

Güvenlik Header'larının Kapsamlı Yapılandırması

CSP'nin yanı sıra ek güvenlik header'ları da yapılandırılmalıdır. Her header farklı bir saldırı vektörünü engeller:

    
# Clickjacking koruması
add_header X-Frame-Options "SAMEORIGIN" always;

# MIME type sniffing koruması
add_header X-Content-Type-Options "nosniff" always;

# XSS filtresi
add_header X-XSS-Protection "1; mode=block" always;

# HTTPS zorunluluğu
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

# Referrer bilgisi kontrolü
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

# İzin politikası
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
    

HSTS header'ı, tarayıcıya sitenin yalnızca HTTPS üzerinden erişilmesi gerektiğini bildirir. max-age=31536000 değeri bir yıllık süreyi kapsar. Bu header'ların tamamının yapılandırılması, sitenin güvenlik duruşunu kapsamlı şekilde güçlendirir ve güvenlik sorunları raporunda uyarı oluşma ihtimalini azaltır.

WordPress Güvenlik Sertleştirme Adımları

WordPress, küresel web sitelerinin yüzde 40'ından fazlasında kullanıldığı için en çok hedef alınan CMS'dir. Temel güvenlik sertleştirme adımları hack riskini önemli ölçüde azaltır.

wp-config.php dosyasında güvenlik anahtarlarının güncellenmesi, dosya düzenlemenin kapatılması ve veritabanı prefix'inin değiştirilmesi temel adımlardır:

    
// Dosya düzenlemeyi kapat
define('DISALLOW_FILE_EDIT', true);

// Otomatik güncellemeyi etkinleştir
define('WP_AUTO_UPDATE_CORE', true);

// Debug modunu kapat
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);
    

Ek olarak .htaccess dosyasında wp-config.php erişimi engellenmelidir:

    
<Files wp-config.php>
Order Allow,Deny
Deny from All
</Files>
    

Kullanılmayan eklenti ve temalar silinmelidir. Devre dışı bırakılmış eklentiler bile güvenlik açığı barındırabilir çünkü dosyaları sunucuda kalmaya devam eder. İki faktörlü kimlik doğrulama (2FA) admin girişleri için etkinleştirilmelidir.

Otomatik Güvenlik Tarama Pipeline'ı

Manuel güvenlik kontrolü ölçeklenebilir değildir. Otomatik tarama pipeline'ı kurmak, güvenlik tehditlerini erken tespit etmeyi sağlar:

    
import requests
import hashlib
import json
from datetime import datetime

def guvenlik_tarasi(site_url):
    sonuclar = []
    
    # SSL sertifika kontrolü
    try:
        r = requests.get(site_url, timeout=10)
        if not r.url.startswith('https'):
            sonuclar.append('KRITIK: HTTPS yonlendirmesi yok')
    except requests.exceptions.SSLError:
        sonuclar.append('KRITIK: SSL sertifika hatasi')
    
    # Guvenlik header kontrolu
    headers_kontrol = {
        'Strict-Transport-Security': 'HSTS eksik',
        'X-Content-Type-Options': 'MIME sniffing korumasi eksik',
        'X-Frame-Options': 'Clickjacking korumasi eksik',
        'Content-Security-Policy': 'CSP eksik'
    }
    
    r = requests.get(site_url, timeout=10)
    for header, mesaj in headers_kontrol.items():
        if header not in r.headers:
            sonuclar.append(f'UYARI: {mesaj}')
    
    # robots.txt erisim kontrolu
    robots = requests.get(f'{site_url}/robots.txt', timeout=10)
    if robots.status_code != 200:
        sonuclar.append('BILGI: robots.txt erisilemedi')
    
    return sonuclar

rapor = guvenlik_tarasi('https://site.com')
for madde in rapor:
    print(f'[{datetime.now().strftime("%Y-%m-%d")}] {madde}')
    

Bu script, SSL durumu, güvenlik header'ları ve temel erişim kontrollerini otomatik olarak denetler. Cron job ile günlük çalıştırıldığında, yapılandırma değişikliklerinden kaynaklanan güvenlik açıkları anında tespit edilir.

Safe Browsing API ile Proaktif Tehdit İzleme

Safe Browsing API, sitenin zararlı içerik listelerinde olup olmadığını programatik olarak sorgulamaya olanak tanır. Bu API, Search Console güvenlik raporundan önce tehdit tespiti yapabilir:

    
import requests

def safe_browsing_kontrol(api_key, url):
    endpoint = 'https://safebrowsing.googleapis.com/v4/threatMatches:find'
    
    payload = {
        'client': {'clientId': 'seo-monitor', 'clientVersion': '1.0'},
        'threatInfo': {
            'threatTypes': ['MALWARE', 'SOCIAL_ENGINEERING', 
                          'UNWANTED_SOFTWARE', 'POTENTIALLY_HARMFUL_APPLICATION'],
            'platformTypes': ['ANY_PLATFORM'],
            'threatEntryTypes': ['URL'],
            'threatEntries': [{'url': url}]
        }
    }
    
    r = requests.post(f'{endpoint}?key={api_key}', json=payload)
    matches = r.json().get('matches', [])
    
    if matches:
        for match in matches:
            print(f"TEHDIT: {match['threatType']} - {match['threat']['url']}")
    else:
        print(f"TEMIZ: {url}")

safe_browsing_kontrol('API_KEY', 'https://site.com')
    

Bu kontrol, günlük otomatik çalıştırıldığında sitenin zararlı listelerine eklenip eklenmediği proaktif olarak izlenir. Search Console bildirimi gelmeden önce müdahale etmek, kullanıcı güvenini ve organik trafiği korur. LinkedIn üzerindeki web güvenliği topluluklarında paylaşılan verilere göre, proaktif izleme uygulayan siteler güvenlik olaylarının ortalama müdahale süresini 72 saatten 4 saate düşürmektedir.

Güvenlik Olayı Sonrası SEO Kurtarma Stratejisi

Güvenlik sorunu çözüldükten sonra organik performansın tam olarak toparlanması 4 ila 16 hafta sürer. Bu süreçte teknik SEO altyapısının sağlam olması kurtarma hızını doğrudan etkiler.

Kurtarma stratejisi: önce Search Console'da "Güvenlik sorunlarını düzelttim" bildirimi yapılır. Ardından URL Denetim aracıyla kritik sayfaların yeniden taranması talep edilir. Sitemap dosyası güncellenip yeniden gönderilir. Bu adımlar, arama motorunun siteyi yeniden değerlendirmesini hızlandırır. Kurtarma sürecinde yeni içerik yayımlamaya devam etmek, sitenin aktif ve bakımlı olduğunu gösteren ek bir güven sinyali üretir.