Teknik SEO denetimi çoğu ekipte iki iş gününü yiyen manuel bir iştir: tarama çıktısını aç, kırk sütunu filtrele, Search Console ile karşılaştır, log dosyasına bak, bulguları tabloya geçir. Markention olarak bu akışı üç saate indirdik. Yöntemin sırrı modele daha uzun bir prompt yazmak değil; veriyi doğru biçimde hazırlamak, denetimi üç aşamaya bölmek ve her bulguyu üç yoldan biriyle doğrulamak.
Rehber 1.000 ile 250.000 URL arasındaki siteler için yazıldı; daha büyük siteler için örnekleme kuralları bölümü geçerli. Yöntem araca bağlı değil: Screaming Frog yerine Sitebulb, Claude yerine başka bir model kullanabilirsiniz. Değişmeyen şey veri sözlüğü ve doğrulama disiplinidir.
Yapay zekâ teknik denetimde neyi hızlandırıyor
Model sizin yerinize karar vermiyor; korelasyon kurma işini üstleniyor. Bir teknik denetimde zamanın büyük kısmı tek bir soruya gidiyor: bu tarama bulgusu gerçekten trafik kaybettiriyor mu? Bunu yanıtlamak için tarama satırını, o URL kalıbının Search Console gösterimini ve Googlebot’un o kalıbı ne sıklıkta çağırdığını yan yana koymak gerekir. Üç dosyayı aynı anda okuyabilen bir model bu eşleştirmeyi saniyeler içinde yapar; sizin işiniz sonucu yorumlamak olur.
- Hızlanan: kalıp çıkarma, veri birleştirme, bulgu metnini yazma, öncelik sıralaması.
- Hızlanmayan: iş öncelikleri, gelir modeli, kaynak planlama, teknik uygulanabilirlik kararı.
- Devredilmemesi gereken: canonical, robots ve yönlendirme değişikliklerinin son onayı.
Denetim öncesi hazırlık: üç veri kaynağı
Denetimin kalitesi, modele verdiğiniz verinin kalitesiyle sınırlıdır. Üç kaynağı birleştiriyor ve her birini CSV olarak yüklüyoruz. Bu adımı atlayıp ham HTML veya ekran görüntüsü verdiğimiz denemelerde yanlış pozitif oranı belirgin biçimde arttı.
1. Tarama çıktısı
Screaming Frog’da “Internal → All” sekmesini yalnızca HTML satırlarıyla dışa aktarıyoruz. Kırk sütunun on ikisini tutuyoruz: adres, durum kodu, indexlenebilirlik, canonical, title, H1, kelime sayısı, iç bağlantı sayısı, tarama derinliği, yanıt süresi, meta robots ve hreflang. JavaScript render açık, beş eş zamanlı istek, bir saniye gecikme. Sitemap’teki URL’ler tarama listesine dahil edilir; yalnızca bağlantıyla ulaşılamayanlar orphan olarak işaretlenir.
2. Search Console dışa aktarımı
Sayfa bazlı 16 aylık tıklama ve gösterim verisiyle Sayfalar raporundaki dizine eklenmeme nedenlerini birleştiriyoruz. Böylece model, taramada gördüğü bir sorunun trafik etkisini tahmin edebiliyor. Performans raporunu cihaz kırılımı olmadan, indexleme raporunu ise “Taranıyor – şu anda dizine eklenmemiş” ve “Yinelenen, Google farklı canonical seçti” listeleriyle alıyoruz.
3. Sunucu log örneklemi
Yedi günlük erişim logundan yalnızca doğrulanmış Googlebot satırlarını süzüyoruz. Amaç tam bir log analizi değil; hangi URL kalıplarının hiç çağrılmadığını görmek. Cloudflare kullanan sitelerde origin log yerine Logpush çıktısı da iş görür.
# Googlebot satirlarini suz, kalip bazinda say
grep -i "googlebot" access.log \
| awk '{print $7}' \
| sed -E 's#/[0-9]+/#/:id/#g' \
| sort | uniq -c | sort -rn \
> googlebot-kalip-dagilimi.txt
# En cok cagrilan 20 kalibi gor
head -20 googlebot-kalip-dagilimi.txt| Kaynak | Tutulan sütunlar | Hangi soruyu yanıtlar | Örnekleme |
|---|---|---|---|
| Tarama çıktısı | adres, durum kodu, indexlenebilirlik, canonical, title, H1 | Sayfa teknik olarak taranabilir ve dizinlenebilir mi | Tam tarama, 250K URL’ye kadar |
| Search Console – Performans | sayfa, tıklama, gösterim, ortalama pozisyon | Bu URL kalıbı gerçekten trafik üretiyor mu | 16 ay, sayfa bazlı |
| Search Console – İndexleme | URL, dizine eklenmeme nedeni | Google neden dışarıda bırakıyor | Tüm liste |
| Sunucu logu | tarih, URL, user-agent, durum kodu | Googlebot bu kalıbı ne sıklıkta çağırıyor | 7 gün, yalnızca bot satırları |
Üç aşamalı prompt mimarisi
Tek uzun prompt yerine üç aşamalı bir akış kullanıyoruz. Sebebi basit: modelin bir aşamada ürettiği çıktı, bir sonraki aşamanın girdisi oluyor ve her aşamanın çıktı formatı önceden belirlendiği için sapma şansı kalmıyor. Aşamalar arasında çıktıyı elle gözden geçirmek toplam süreyi uzatmıyor, aksine üçüncü aşamada düzeltme ihtiyacını ortadan kaldırıyor.
Aşama 1 – Veri sözlüğü
Modele önce sütunların ne anlama geldiğini tek paragrafta anlatıyoruz. Bu adım atlandığında model “Indexability” sütununu kendi varsayımıyla yorumluyor ve canonical’ı olan sayfaları hatalı biçimde sorunlu sayıyor.
# Asama 1 - veri sozlugu
Rol: Teknik SEO denetcisi
Girdi: tarama.csv, gsc-sayfalar.csv, log-ornek.csv
Gorev: Her dosyanin sutunlarini tek tek listele ve ne olctugunu yaz.
Kural: Emin olmadigin sutun icin "belirsiz" yaz, tahmin etme.
Cikti: | dosya | sutun | anlam | ornek deger |Aşama 2 – Bulgu çıkarımı
İkinci aşamada model yalnızca bulguları çıkarır, önceliklendirme yapmaz. Her bulgunun bir kanıt satırına dayanması şart; kanıtı olmayan bulgu rapora girmez.
# Asama 2 - bulgu cikarimi
Rol: Teknik SEO denetcisi
Gorev: Her bulgu icin -> url_kalibi | sorun | kanit(satir no) | etki(1-5) | cozum
Kural 1: Kaniti olmayan bulgu yazma.
Kural 2: "Muhtemelen", "olabilir" gibi ifadeler kullanma; veriye isaret et.
Kural 3: Ayni kokten gelen bulgulari tek satirda birlestir.
Cikti: CSV, baslik satiri dahilAşama 3 – Önceliklendirme
Üçüncü aşamada ikinci aşamanın çıktısını olduğu gibi veriyoruz ve sıralamayı yalnızca Search Console gösterim verisine göre ağırlıklandırmasını istiyoruz. Böylece “teknik olarak ilginç ama trafiksiz” bulgular listenin sonuna düşüyor.
Örnek bulgular ve önceliklendirme
Aşağıdaki tablo, 1.240 URL’lik bir e-ticaret sitesinde çıkan ilk beş bulgunun özetidir. Etki sütunu Search Console gösterimine, efor sütunu geliştirici tahminine dayanıyor. Öncelik, etkinin efora bölünmesiyle hesaplanıyor.
| URL kalıbı | Sorun | Etkilenen URL | Etki | Efor | Çözüm |
|---|---|---|---|---|---|
| /kategori/?renk=* | Facet URL’leri indexleniyor, canonical yok | 312 | 5 | 2 | Canonical + noindex, iç bağlantıları kaldır |
| /urun/* | Title ile H1 birebir aynı, marka eki yok | 604 | 3 | 1 | Title şablonunu güncelle |
| /blog/page/* | Sayfalama derinliği 6+ | 41 | 3 | 3 | Kategori sayfalarından doğrudan bağlantı |
| /tr/ ↔ /en/ | Hreflang karşılıklı değil | 88 | 4 | 2 | x-default ekle, karşılıklı etiketle |
| /kampanya/2024-* | Süresi geçmiş sayfalar 200 dönüyor | 27 | 2 | 1 | 410 veya güncel kampanyaya 301 |
Tabloyu okurken dikkat edilecek nokta: en çok URL’yi etkileyen bulgu her zaman ilk sırada değildir. Title tekrarı 604 URL’yi etkiliyor ama gösterim kaybı facet sorununa kıyasla düşük. Öncelik matrisi bu tuzağı kapatıyor.
Büyük sitelerde örnekleme kuralları
250 bin URL’nin üzerindeki sitelerde tam tarama hem zaman hem de bağlam açısından verimsizdir. Bu ölçekte denetimi URL kalıbı bazına indiriyoruz. Önce tarama çıktısındaki adresleri normalize ediyor, sayısal kimlikleri ve sorgu değerlerini değişkene çeviriyoruz; ardından her kalıptan sabit sayıda örnek alıyoruz. Amaç istatistiksel temsil değil, şablon kapsaması: her benzersiz şablonun en az bir kez denetlenmesi.
- Her kalıptan en az 50, en fazla 300 URL alın; kalıp sayısı arttıkça alt sınıra yaklaşın.
- Gösterimi sıfır olan kalıplardan en az 20 URL ekleyin – index sorunları genellikle orada saklıdır.
- Sayfalama kalıplarında ilk sayfa, orta sayfa ve son sayfa üçlüsünü mutlaka örnekleme dahil edin.
- Toplam satır sayısını 10 binin altında tutun; üzerine çıkıldığında model bağlam kaybetmeye başlıyor.
import pandas as pd, re
df = pd.read_csv("tarama.csv")
def kalip(u):
u = re.sub(r"/\d+", "/:id", u)
u = re.sub(r"=[^&]+", "=:v", u)
return u
df["kalip"] = df["Address"].map(kalip)
ornek = (
df.groupby("kalip", group_keys=False)
.apply(lambda g: g.head(min(300, max(50, len(g) // 20))))
)
ornek.to_csv("tarama-ornek.csv", index=False)
print(ornek["kalip"].nunique(), "kalip,", len(ornek), "satir")Sık yapılan beş hata
Bu akışı ekiplerimize aktarırken tekrar eden hataları not ettik. Beşi de sonucu doğrudan bozuyor.
- Veri sözlüğünü atlamak. Sütun adları araca özgüdür; model tahmin etmek zorunda kalırsa yanlış pozitif üretir. Bu tek adım, yanlış pozitiflerin büyük kısmını kapatıyor.
- Ekran görüntüsü yüklemek. Görselden okunan tablo satır kaymalarına açıktır. CSV varken görsel kullanmayın.
- Tek promptta her şeyi istemek. Bulgu çıkarımı ile önceliklendirme aynı istekte yapıldığında model, önceliği yüksek göstermek için bulguyu abartıyor.
- Trafiği hesaba katmamak. Gösterim verisi olmadan yapılan sıralama, teknik ilginçliğe göre sıralamadır; iş etkisine göre değil.
- Doğrulamayı atlamak. Raporlanan ama doğrulanmamış bir bulgu, geliştirici ekibin güvenini bir defada tüketir.
Altıncı bir madde eklemek gerekirse: denetimi tek seferlik bir proje gibi görmek. Şablon değişiklikleri, yeni kategori açılışları ve tema güncellemeleri aynı sorunları geri getirir. Bu akışı çeyrekte bir tekrarlayan bir rutine bağlamak, tek seferlik derin bir denetimden daha fazla kazanç sağlıyor.
Raporu geliştirici ekibine teslim etme biçimi
Teknik denetimlerin uygulanmama sebebi genellikle bulgunun yanlış olması değil, teslim biçiminin geliştiricinin iş akışına uymamasıdır. PDF rapor kimsenin backlog’una girmez. Bulguları doğrudan ticket’a dönüşebilecek biçimde teslim ediyoruz: her satır bir iş kalemi, her iş kaleminde etkilenen URL listesi, beklenen davranış ve kabul kriteri var.
Kabul kriteri yazmak fazladan beş dakika alır ama tartışmayı bitirir. “Facet URL’leri indexlenmesin” cümlesi yoruma açıktır; “/kategori/?renk=* adresleri <meta name=robots content=noindex,follow> döndürmeli ve kategori sayfasındaki filtre bağlantıları rel=nofollow almalı” cümlesi test edilebilir. Aynı disiplini yönlendirme kararlarında da uyguluyoruz: hedef URL, durum kodu ve beklenen zincir uzunluğu ticket’ta yazılı olmalı.
- Başlık: kalıp adı + sorun, tek satır.
- Kanıt: tarama satır numarası veya URL Inspection ekran çıktısı.
- Beklenen davranış: hangi başlık, etiket veya durum kodu döneceği.
- Kabul kriteri: nasıl test edileceği; tercihen tek komutluk bir doğrulama.
- Geri alma: değişiklik beklenmedik sonuç verirse nasıl geri alınacağı.
Son adım, yayına aldıktan sonra aynı kalıbı yeniden taramak. Denetimi kapatan şey rapor değil, düzeltmenin canlıda doğrulanmasıdır. Bizde bu kontrol, uygulamadan 48 saat sonra otomatik çalışan kısa bir tarama işiyle yapılıyor; fark varsa ticket yeniden açılıyor.
Bulguları doğrulama: modelin uydurmasını nasıl engelliyoruz
Modelin çıkardığı her bulguyu üç yoldan biriyle doğruluyoruz. Üçünden biri tutmuyorsa bulgu rapora girmez. Son denetimde 47 bulgunun 44’ü doğrulandı; üç yanlış pozitifin tamamı eksik sütun açıklamasından kaynaklanıyordu.
- Canlı test: Search Console → URL Inspection ile canlı tarama; canonical ve indexlenebilirlik ekranda görülür.
- Yeniden üretim: Aynı URL kalıbı için ikinci bir tarama; bulgu tekrar çıkıyor mu?
- Log kanıtı: Log örnekleminde ilgili Googlebot isteğini bulma.
Doğrulamayı elle yapmak istemiyorsanız URL Inspection API’si üzerinden toplu kontrol yazmak on dakikalık iş. Günlük kota 2.000 sorgu; örneklem yapmanız yeterli.
import json, requests
ENDPOINT = "https://searchconsole.googleapis.com/v1/urlInspection/index:inspect"
def inspect(url, site, token):
body = {"inspectionUrl": url, "siteUrl": site, "languageCode": "tr"}
r = requests.post(
ENDPOINT,
headers={"Authorization": "Bearer " + token},
json=body, timeout=30,
)
r.raise_for_status()
d = r.json()["inspectionResult"]["indexStatusResult"]
return {
"url": url,
"verdict": d.get("verdict"),
"coverage": d.get("coverageState"),
"canonical": d.get("googleCanonical"),
}
# Ornek: bulgu listesinden 50 URL orneklemi
for u in ornek_urls[:50]:
print(json.dumps(inspect(u, SITE, TOKEN), ensure_ascii=False))
30 günlük uygulama planı
Denetim raporu tek başına değer üretmez; uygulanan kısmı üretir. Bulguları dört haftaya yayıyoruz ve her haftanın sonunda ölçüm alıyoruz.
- 1. hafta – Index kontrolü: canonical, robots ve noindex düzeltmeleri. Riski en yüksek, etkisi en hızlı grup. Değişiklikler staging’de doğrulanır.
- 2. hafta – Bilgi mimarisi: iç bağlantı, sayfalama derinliği, orphan sayfalar. Kategori sayfalarından derin sayfalara doğrudan bağlantı açılır.
- 3. hafta – İçerik sinyalleri: title ve meta description şablonları, H1 tekrarları, thin content birleştirmeleri.
- 4. hafta – Performans ve schema: Core Web Vitals, görsel boyutları, Product ve FAQPage yapısal verisi.
Sıralama tesadüfi değil. Index katmanı düzelmeden içerik iyileştirmesi yapmak, Google’ın zaten dizine almadığı sayfalara emek harcamak demektir. Aynı mantıkla performans işleri en sona bırakılır: teknik olarak görünmeyen bir sayfanın hızlanması ölçülebilir bir kazanç üretmez.
Ölçüm ve raporlama
Denetimin işe yarayıp yaramadığını dört metrikle takip ediyoruz. Hepsi Search Console’dan ücretsiz alınabilir; ek araç gerekmez.
- Dizine eklenen sayfa sayısı: hedef, gerçek sayfa sayısına yakınsamak. Şişkin index kadar eksik index de sorundur.
- Tarama istekleri / gün: gereksiz kalıplar kapandıkça isteklerin değerli URL’lere kayması beklenir.
- Ortalama yanıt süresi: tarama istatistiklerinde 600 ms üzeri değerler crawl bütçesini kısar.
- Gösterim / tıklama: kalıp bazında, düzeltme tarihinden 28 gün sonra karşılaştırmalı.
Raporu paydaşa sunarken bulgu sayısını değil, etkilenen gösterim hacmini öne çıkarın. “47 teknik bulgu” cümlesi karar aldırmaz; “312 facet URL’si crawl bütçesinin %19’unu tüketiyor” cümlesi aldırır.
Sık sorulan sorular
Yapay zekâ teknik SEO denetçisinin yerini alır mı?
Hayır. Model veri birleştirme ve kalıp çıkarma işini hızlandırıyor, karar katmanını değil. Canonical, robots ve yönlendirme kararlarının sonucu doğrudan trafiktir; bu kararlar insanda kalmalı. Denetçinin işi rapor yazmaktan öncelik belirlemeye kayıyor.
Modele yüklediğim veri eğitimde kullanılıyor mu?
Ticari ve API planlarında müşteri verisi model eğitiminde kullanılmaz; yine de kişisel veriyi anonimleştirip yükleyin. Log satırlarındaki IP ve kullanıcı bilgilerini yüklemeden önce maskelemek iyi bir alışkanlıktır. Sözleşmeli müşterilerde bu adımı KVKK süreçlerinize yazılı olarak ekleyin.
Kaç URL’ye kadar tek seferde analiz yapılabilir?
10–15 bin satırlık CSV’ler sorunsuz işleniyor. Daha büyük sitelerde şablon bazında örnekleme yapın: her URL kalıbından 200–300 satır, toplamda 10 bin satırı geçmeyen bir set. Kalıp çeşitliliği satır sayısından daha önemlidir.
JavaScript ile üretilen içerik denetime dahil oluyor mu?
Yalnızca taramayı JavaScript render açık yaptıysanız. Render edilmiş DOM yüklenmediğinde model istemci tarafında eklenen schema, hreflang ve canonical etiketlerini göremez ve bunları eksik olarak raporlar. Bu, en sık karşılaştığımız yanlış pozitif kaynağıdır.
Hangi tarama aracı daha uygun: Screaming Frog mu, Sitebulb mu?
İkisi de çalışır. Önemli olan sütun adlarını sabit tutmak ve veri sözlüğünü ilk mesajda vermek; araç değiştiğinde yalnızca sözlüğü güncellemeniz yeterli olur. Sitebulb’ın hazır öncelik puanları işinizi kolaylaştırabilir, ancak kendi etki/efor matrisinizi kurmak daha isabetli sonuç verir.
Sonuç
Yapay zekâ destekli teknik denetim, iki günlük bir işi üç saate indiriyor; ancak bu kazanç prompt kalitesinden değil, veri hazırlığı ve doğrulama disiplininden geliyor. Üç veri kaynağını doğru sütunlarla hazırlayın, denetimi üç aşamaya bölün, her bulguyu üç yoldan biriyle doğrulayın ve raporu 30 günlük uygulama planına bağlayın. Sonuçları kalıp bazında ölçün; teknik SEO’da kazanç, tek tek sayfalarda değil kalıplarda birikir.
Yapay Zeka SEO
