İleri Seviye SEO: Bakım Rutini

İleri seviye SEO bakımı, tek tek anahtar kelimeleri izlemekten çok sistem davranışını yönetir. URL kümeleri, şablon sürümleri, tarama günlükleri, canonical seçimi, içerik eskimesi ve gerçek kullanıcı performansı aynı veri modeli içinde incelenmelidir. Amaç her düşüşte sayfayı değiştirmek değil; anomalinin kapsamını hızlı belirleyip en güçlü hipotezi kontrollü biçimde sınamaktır.

---

İleri bakım; URL, şablon, sürüm ve iş sonucunu aynı zaman çizelgesinde birleştirir.

Temel Rutinden Farkı​

Temel bakım erişim, dizinleme, içerik güncelliği ve performansı düzenli kontrol eder. İleri bakım ise yüzlerce veya binlerce URL içinde hangi grubun neden değiştiğini bulmaya odaklanır. Tek bir site ortalaması yerine sayfa türü, dizin, ülke, cihaz, sorgu niyeti ve yayın kohortu kullanılır.

• Kohort: Aynı şablon, yayın haftası, dizin veya içerik türündeki URL grubu
• Sürüm: Tema, render, canonical, iç link, CDN veya içerik değişikliğinin kimliği
• Durum: Dizinli, keşfedildi, tarandı, yönlendirildi, noindex veya canonical altında birleşti
• Sonuç: Gösterim, tıklama, doğru dönüşüm, gelir ve kullanıcı görevi
• Maliyet: Tarama, render, editör ve geliştirme zamanı

URL Envanteri ve Tek Doğruluk Kaynağı​

CMS, sitemap, Search Console, analitik ve log verisi aynı URL'leri farklı biçimde gösterebilir. Önce normalleştirme kuralları oluşturun: protokol, host, sondaki eğik çizgi, parametre ve büyük/küçük harf. Her URL için beklenen canonical, şablon, durum ve dizin kararı tek envanterde tutulmalıdır.

• CMS'de var ama sitemap'te olmayan canonical sayfalar
• Sitemap'te bulunup 3xx, 4xx, 5xx veya noindex dönen URL'ler
• Analitikte trafik alan fakat envanterde karşılığı olmayan eski yollar
• Logda taranan fakat iş değeri ve iç bağlantısı olmayan parametre kümeleri
• Google'ın seçtiği canonical ile bildirilen canonical'ın ayrıştığı örnekler

Envanter anlık rapor değil, değişikliklerle güncellenen operasyon kaydıdır. Her URL kararı için gerekçe ve tarih tutmak, altı ay sonra aynı tartışmayı tekrar yaşamayı önler.

Şablon Sağlığı ve Değişiklik Algılama​

Yüzlerce sayfadaki aynı bozukluk çoğu zaman tek şablon sürümünden çıkar. Her kritik şablon için referans HTML ve davranış kontrolleri oluşturun. Dağıtım sonrası title, canonical, robots, hreflang, structured data, ana içerik, iç bağlantı ve durum kodundaki farkları otomatik karşılaştırın.

• Yapısal sözleşme: Zorunlu etiket ve alanların varlığı
• Görünür içerik: Boş, tekrar eden veya yanlış veri bağlanan bölümler
• Render farkı: Ham HTML ile işlenmiş DOM arasındaki kritik içerik
• Link davranışı: Pagination, filtre, breadcrumb ve önerilen içerikler
• Durum kodu: Uygulama hata sayfasının yanlışlıkla 200 dönmemesi

Sürüm kuralı' Alıntı:

SEO anomalisi başladığında ilk soru “ne yazalım?” değil, “o tarihte hangi şablon veya veri sürümü değişti?” olmalıdır.

Genişletmek için tıkla ...

Search Console Kohort Analizi​

Search Console performans verisini sayfa türü ve iş amacıyla zenginleştirin. Sayfa URL'sinden kategori çıkarmak yerine envanterdeki şablon/dizin bilgisini kullanmak daha güvenlidir. Son 16 aya kadar veriyi karşılaştırmak mevsimselliği görmeye yardım eder; daha uzun saklama gerekiyorsa API veya toplu dışa aktarım planlayın.

• Tıklama, gösterim ve CTR farkını birlikte yorumlayın.
• Sorgu markalı/markasız, bilgi/işlem ve konu kümelerine ayrılabiliyorsa ayrı inceleyin.
• Yeni URL kohortlarını eski, benzer amaçlı kohortlarla karşılaştırın.
• Mutlak pozisyon yerine sorgu ve sayfa karışımının değişip değişmediğini kontrol edin.
• Düşüşü web, görsel, video veya haber arama türlerine göre ayırın.

İndeksleme Durum Geçişleri​

Sadece mevcut dizin durumunu saymak, sorunun ne zaman başladığını göstermez. URL'lerin “dizinli → tarandı, dizinlenmedi” veya “canonical seçimi değişti” gibi durum geçişlerini sürüm ve içerik değişiklikleriyle ilişkilendirin.

Dizin riski = etkilenen değerli URL sayısı × durum süresi × iş etkisi

Her rapor sınıfı hata değildir. Redirect, noindex veya duplicate canonical kararı beklenen olabilir. Beklenen durum matrisi oluşturun; alarm yalnız gerçek karar ile gözlenen durum ayrıştığında çalışsın.

Tarama Günlükleriyle Doğrulama​

Sunucu logları botun gerçekten hangi URL'yi, ne zaman ve hangi durumla aldığını gösterir. User-Agent adına tek başına güvenmeyin; gerekli durumda Google'ın yayımladığı doğrulama yöntemlerini kullanın. Kişisel veri ve sırları loga taşımadan istek zamanı, yol, durum, yanıt boyutu ve süre gibi alanları saklayın.

• Değerli yeni URL'ler ne kadar sürede tekrar taranıyor?
• Bot zamanı parametre, filtre ve hata URL'lerinde mi harcanıyor?
• 5xx, timeout veya anormal küçük yanıtlar hangi şablonda yoğunlaşıyor?
• Redirect zinciri veya döngüsü tarama tekrarını artırıyor mu?
• Sitemap güncellemesi ile tarama davranışı arasında ilişki var mı?

Tarama bütçesi küçük sitelerde genellikle öncelikli sorun değildir. Log analizi, gerçek sorun kanıtı varsa kullanılmalı; sırf ileri seviye göründüğü için gereksiz optimizasyon yapılmamalıdır.

Canonical Drift Denetimi​

Canonical drift, bildirilen veya seçilen ana URL'nin zamanla beklenmedik biçimde değişmesidir. Filtre sayfaları, syndication, ürün varyantları, protokol/host farkları ve içerik benzerliği bunu tetikleyebilir.

• Redirect, rel=canonical, sitemap ve iç link aynı hedefi destekliyor mu?
• Canonical hedefi 200 dönüyor ve indexlenebilir mi?
• Kaynak ile hedef gerçekten aynı kullanıcı görevini karşılıyor mu?
• Şablon bütün sayfaları kategori veya ana sayfaya bağlamış olabilir mi?
• Uluslararası sayfalarda canonical ve hreflang karşılıklı tutarlı mı?

Canonical sorunu için yalnız etiketi değiştirmek yeterli olmayabilir. İç bağlantı, içerik farkı, yönlendirme ve sitemap sinyallerini beraber düzeltin.

İçerik Eskimesi ve Birleştirme Modeli​

İçerik bakımını yaşa göre otomatikleştirmeyin. Tarihsel haber, evergreen rehber ve fiyat/mevzuat sayfasının eskime davranışı farklıdır. Her içerik türü için doğrulama süresi ve kaynak sahibi tanımlayın.

• Koru: Hâlâ doğru, benzersiz ve kullanıcı görevini karşılıyor
• Güncelle: Talep var fakat bilgi, örnek veya kaynak eskimiş
• Birleştir: Aynı niyeti bölen zayıf sayfalar daha güçlü tek kaynakta toplanabilir
• Yönlendir: Gerçek eşdeğer hedef mevcut ve eski URL artık gerekli değil
• Kaldır: İş değeri, talep ve geçerli karşılığı yok; uygun 404/410 davranışı kullanılır

Kararı yalnız trafikle vermeyin. Destek, uyumluluk, marka ve dönüşüm değeri düşük trafikle de önemli olabilir.

İç Bağlantı Akışı​

İç bağlantı analizinde yalnız adet değil, bağlam ve yön önemlidir. Hub/cluster, breadcrumb, navigasyon ve önerilen içerik bağlantılarını ayrı sınıflandırın. Yeni sayfaya bütün site footer'ından link vermek ile ilgili üç güçlü içerikten bağ vermek aynı değildir.

Önemli sayfaların tıklama derinliği, yetim sayfalar, kırık hedefler ve aynı anchor'ın farklı amaçlara dağılması izlenebilir. Otomatik öneri sistemi varsa konu dışı bağlantı paketi üretmediğini örneklerle kontrol edin.

Core Web Vitals Regresyon Bütçesi​

Alan verisindeki LCP, INP ve CLS'yi şablon ve sürüm bazında izleyin. Ortalama yerine 75. yüzdelik ve iyi/iyileştirilmeli/kötü dağılımını kullanın. Yeni üçüncü taraf veya tasarım bileşeni için kabul edilen regresyon bütçesi belirleyin.

• Değişiklikten önce ve sonra aynı şablon/cihaz kohortu
• Trafik ve mevsim farkı nedeniyle oluşan örneklem değişimi
• Laboratuvar izinde LCP kaynağı ve uzun görevler
• İşlev, erişilebilirlik ve dönüşümde yan etki
• Geri alma veya aşamalı yayın eşiği

Anomali Tespitinde Gürültü Kontrolü​

Günlük veride hafta günü, tatil, kampanya ve raporlama gecikmesi gürültü üretir. Basit eşiklerle başlayın; karmaşık model yalnız veri hacmi ve operasyon kapasitesi uygunsa kullanılmalıdır.


Alarmın ardından otomatik içerik veya yönlendirme değişikliği yapmayın. Sistem, inceleme kuyruğu ve bağlam üretmeli; yayın kararı insan denetimi ve geri alma planıyla verilmelidir.

Aylık İleri Bakım Gündemi​

• URL envanteri ve durum geçişlerinin özeti
• En büyük pozitif/negatif sayfa ve sorgu kohortları
• Şablon regresyonları ve son sürüm etkileri
• Canonical, sitemap, robots ve iç link ayrışmaları
• İçerik güncelleme/birleştirme/kaldırma kararları
• Core Web Vitals ve üçüncü taraf maliyeti
• Tamamlanan hipotezlerin sonucu ve yeni teknik borç

Olay Müdahale Runbook'u​

1. Ölçüm ve veri gecikmesini doğrulayın.
2. Başlangıç zamanını yayın, altyapı ve arama sistemi olaylarıyla eşleştirin.
3. Etkilenen URL/sorgu/cihaz/ülke kohortunu sınırlandırın.
4. Durum kodu, render, robots, canonical, güvenlik ve log kanıtını toplayın.
5. En güçlü hipotez için temsilî URL seti seçin.
6. Geri alınabilir düzeltmeyi küçük kapsamda yayımlayın.
7. Doğru öncü ve gecikmeli sinyalleri yeterli süre izleyin.
8. Kök nedeni, alınan kararı ve önleyici kontrolü kaydedin.

Sık Sorulan Sorular​

Her site log analizi yapmalı mı?
Hayır. Büyük veya karmaşık sitelerde, tarama/durum sorunu kanıtlandığında değerlidir. Küçük sitede önce erişim, sitemap, iç link ve Search Console sorunları çözülmelidir.

İleri bakım için hangi veri ambarı gerekir?
Araçtan önce veri sözlüğü gerekir. URL, tarih, şablon, sürüm ve metrik alanları tutarlıysa küçük bir veri tabanı da başlayabilir.

Anomali alarmı neden çok çalışıyor?
Hacim alt sınırı, hafta günü, mevsimsellik, veri gecikmesi veya kohort karışımı hesaba katılmıyor olabilir.

Canonical drift nasıl erken yakalanır?
Temsilî URL'lerin bildirilen/seçilen canonical farkını ve şablon çıktısını sürüm sonrası karşılaştırarak.

Birleştirilen içerikte eski URL ne olmalı?
Gerçek eşdeğer yeni kaynak varsa doğrudan 301 düşünülebilir. Eşdeğer yoksa alakasız sayfaya yönlendirme yapılmamalıdır.

İleri bakımın başarısı nedir?
Daha çok rapor değil; daha kısa teşhis süresi, daha az tekrarlanan regresyon ve değerli URL'lerde daha kararlı sonuçtur.

İç Bağlantılar​

• Temel SEO bakım rutini
• SEO raporlama ve performans izleme
• Teknik SEO teşhis rehberi
• Sık yapılan SEO hataları

Dış Kaynaklar​

• Google Search Central — Trafik düşüşlerini teşhis
• Google Search Central — Search Console ve Analytics birlikte kullanım
• Google Search Central — Canonical yöntemleri
• Google Search Central — Büyük sitelerde tarama yönetimi
• web.dev — Core Web Vitals

Özetle​

URL envanteri, şablon sürümü, durum geçişi, log ve iş sonucunu aynı kohort modelinde birleştirin; alarmı otomatik değişiklik değil kanıtlı inceleme başlatmak için kullanın. Bakım sürecinizde en uzun süren teşhis adımını paylaşın; runbook'u o darboğaza göre geliştirelim.

---