Hızlı Cevap
Sayfa gruplarıyla şablon sorunu bulma yöntemi şudur: Search Console’da benzer URL’leri klasör, slug ve parametre desenlerine göre regex ile segmentleyin; her grupta CTR, gösterim, ortalama konum ve indeks sinyallerini kıyaslayın; düşen grupları sonra Crawl Stats ve GA4 ile doğrulayıp önceliklendirin.
Önemli Noktalar
- Önce URL envanterini çıkarın, sonra kalıcı page-group taksonomisi kurun.
- Regex filtresi kadar false positive ve false negative kontrolü önemlidir.
- CTR düşüşünü tek başına değil, konum ve gösterimle birlikte okuyun.
- Büyük sitelerde karar kalitesi, GSC verisini GA4 ve crawl ile doğrulamaya bağlıdır.
Sayfa grupları oluşturarak Search Console verisiyle şablon bazlı sorunlar nasıl bulunur?
Search Console verisini tek tek URL satırlarında okumak, özellikle büyük sitelerde sizi yavaşlatır. Daha verimli yaklaşım, benzer amaç taşıyan sayfaları aynı page group içinde toplamaktır. Kategori, ürün, blog, kampanya ve filtreli URL gibi şablonları ayrı grupladığınızda; problem artık tek sayfa değil, aynı üretim mantığıyla oluşturulmuş bir sayfa ailesi olarak görünür. Bu da başlık şablonu, iç linkleme, indeksleme, crawl bütçesi veya template tarafındaki ortak hataları daha hızlı yakalamanızı sağlar.
Bu yöntemde ana sinyaller nettir: CTR düşüşü, ortalama konum kaybı, gösterim kırılması, indeks kapsamı farkı ve tarama davranışındaki sapma. Google’ın Performance Report yardım dokümanı, analiz omurgasının hâlâ tıklama, gösterim, CTR ve ortalama konum metriklerine dayandığını açıkça belirtir (Google Search Console Help). Yani şablon bazlı analiz, yeni bir teori değil; mevcut veriyi daha doğru gruplama biçimidir.
En kritik nokta, sürdürülebilir bir taksonomi kurmaktır. Sadece klasöre bakarsanız parametreli sayfaları kaçırabilirsiniz; sadece slug mantığına bakarsanız farklı klasörlerdeki aynı şablonu bölebilirsiniz. Bu yüzden klasör, slug, parametre ve arama görünümü boyutlarını birlikte düşünmek gerekir. Özellikle e-ticaret, ilan, marketplace ve büyük içerik sitelerinde bu yaklaşım, tek tek URL denetiminden daha olgun ve daha hızlı bir analiz metodolojisi sunar.
Adım Adım: Search Console’da page group kurup şablon sorunu bulma
Aşağıdaki akış, küçük ekiplerin de büyük sitelerin de aynı mantıkla uygulayabileceği pratik bir çerçevedir. Amaç, veriyi daha fazla toplamak değil; karar verebileceğiniz gruplara dönüştürmektir.
- URL envanterini çıkar ve şablonları etiketle: Önce kategoriler, ürün detayları, blog içerikleri, kampanyalar ve filtreli URL’ler için envanter oluşturun. Her URL’ye bir sayfa tipi etiketi atayın. Bu ilk sınıflandırma ne kadar temizse, sonraki regex kuralları o kadar güvenilir olur.
- Regex kurallarını yaz ve örneklerle doğrula: Her page group için ayrı filtre tanımlayın. Regex kuralları yazıldıktan sonra en az 20-30 örnek URL üzerinde manuel kontrol yapın. Yanlış eşleşen sayfaları ve hiç yakalanmayan sayfaları not etmek, daha sonra yanlış karar vermenizi engeller.
- GSC segmentlerini ve tarih karşılaştırmasını kur: Page filtresi kurulduktan sonra cihaz, ülke ve gerekirse search appearance kırılımlarını ikinci katman olarak ekleyin. Aynı grubu son 28 gün, önceki 28 gün, son 3 ay ve önceki 3 ay gibi karşılaştırmalarla izleyin. Deploy sonrası etki ölçümü için karşılaştırma modu özellikle faydalıdır.
- KPI eşiklerine göre sorunlu grupları ayıkla: Her grup için CTR, ortalama konum, gösterim ve indeks durumunu yan yana okuyun. En sert düşüş gösteren grupları önceleyin. Böylece ekip, onlarca tekil URL yerine gerçekten şablon seviyesinde etkisi olan işlere odaklanır.
- Crawl, analytics ve operasyon araçlarıyla doğrula: Son aşamada bulguyu tek kaynağa bırakmayın. Crawl Stats, GA4 ve operasyon raporlarıyla teyit edin. Böylece görünen düşüşün talep kaynaklı mı, indeks kaynaklı mı, yoksa teknik yayın problemi mi olduğunu daha net ayırabilirsiniz.
Bu çerçeve, veri dağınıklığını azaltır ve toplantılarda “hangi sayfa bozuldu?” sorusunu “hangi şablon bozuldu?” sorusuna çevirir. Operasyon hızını artıran asıl fark burada oluşur.
Regex, klasör ve URL pattern ile doğru page group nasıl kurulur?
İlk adım, URL envanterini sadece export etmek değil, etiketlenebilir hale getirmektir. Örneğin `/kategori/`, `/urun/`, `/blog/` gibi klasörler varsa başlangıç kolaydır; ama çoğu sitede kampanya sayfaları, arama sonuçları, filtreli kombinasyonlar ve parametreli URL’ler işi karıştırır. Bu nedenle önce hangi sayfa tiplerinin SEO açısından ayrı izlenmesi gerektiğini tanımlayın. İçerik kümeleri kurarken destekleyici sorgu varyasyonlarını görmek için bir anahtar kelime aracı ile slug desenlerini karşılaştırmak da faydalı olur.
Regex, Search Console tarafında page ve query filtrelerini daha esnek yönetmenizi sağlar. Google, 7 Nisan 2021 tarihli duyurusunda Performance Report için regex filtreleri ve geliştirilmiş karşılaştırma modunu resmi olarak sundu (Google Search Central Blog). Pratikte şu mantık iş görür:
- Kategori sayfaları: klasör tabanlı desenler
- Ürün sayfaları: detay slug kalıpları ve ürün ID yapıları
- Blog içerikleri: tarihli veya konu klasörlü içerik yapıları
- Filtreli URL’ler: parametre, facet veya sort desenleri
Burada en sık hata, yalnızca regex yazıp işi bitti sanmaktır. Oysa false positive ve false negative kontrolü zorunludur. Regex’iniz blog etiket sayfalarını yanlışlıkla içerik gibi yakalayabilir ya da kanonik ürün sayfalarının bir kısmını dışarıda bırakabilir. Benzer şekilde, query groups ile page groups aynı şey değildir. Google, 27 Ekim 2025’te Search Console Insights içinde query groups özelliğini duyurdu ve bunun benzer sorguları kümelendiğini açıkladı (Google Search Central Blog). Page groups URL şablonunu izler; query groups ise aynı şablonun içinde markalı ve non-brand sorgu davranışını ikinci katman olarak anlamanızı sağlar.
| Kriter | Search Console arayüzü | API/Export | SEOYEN |
|---|---|---|---|
| Regex segment kurma | Hızlı filtreleme ve anlık kontrol için uygundur | Daha esnek ama teknik kurulum ve bakım ister | Bulguyu ekip içi operasyon akışına bağlamayı kolaylaştırır |
| Haftalık/aylık trend okuma | Yeni granüler görünümle trend okumak kolaydır | Kendi raporunuzu kurmanız gerekir | Trendleri diğer SEO sinyalleriyle birlikte izlemeyi hızlandırır |
| Büyük site ölçeğinde veri işleme | Arayüz limiti nedeniyle zorlaşabilir | Toplu analiz için en uygun katmandır | Teknik içgörüyü daha okunur raporlara dönüştürür |
| Crawl ve indeks sinyallerini birleştirme | Parçalı görünürlük sunar | Birleştirme mümkündür ama emek ister | Site sağlığı ve performansı aynı akışta yorumlamaya yardımcı olur |
| Türkçe ekip içi raporlama | Ham veri odaklıdır | Veri uzmanlığı gerektirir | Türkçe arayüzle karar paylaşımını kolaylaştırır |
| AI görünürlük takibi | Mülke göre ayrı raporları takip edebilirsiniz | Özel veri modeli kurmanız gerekir | AI görünürlüğünü operasyonel SEO takibiyle yan yana getirir |
Şablon bazlı sorunları CTR, konum ve gösterim farklarıyla nasıl okursunuz?
Page group kurulduktan sonra asıl değer, metrikleri birlikte okumakta çıkar. CTR düşüşü tek başına başlık veya snippet sorunu anlamına gelmez; bazen ortalama konum aynı kalır ama SERP görünümü değişir, bazen de konum kaybı CTR’ı aşağı iter. Bu yüzden her grup için şu dört soruyu aynı tabloda izleyin: Gösterim düştü mü, tıklama düştü mü, ortalama konum bozuldu mu, CTR bu değişime paralel mi? Performance Report’un temel metrik yapısı bu okuma için zaten yeterlidir (Google Search Console Help).
Karşılaştırma tarafında haftalık ve aylık görünüm, 2026’da ekiplerin elini belirgin biçimde güçlendiriyor. Google, 10 Aralık 2025’te Performance Report’a weekly ve monthly views eklediğini duyurdu; bu görünüm, günlük dalgalanmayı yumuşatıp gerçek trendi okumayı kolaylaştırıyor (Google Search Central Blog). Özellikle deploy öncesi-sonrası analizde ve hafta sonu etkisinin güçlü olduğu sektörlerde bu görünüm çok işinize yarar. Aynı page group’u cihaz ve ülke kırılımıyla açtığınızda, masaüstünde sabit kalan ama mobilde bozulan veya yalnızca belirli pazarlarda gerileyen şablonları çok daha net görürsünüz.
Search, Discover ve News görünürlüğünü de aynı sepette yorumlamayın. Aynı URL şablonu web sonuçlarında iyi giderken Discover tarafında zayıf olabilir. Eğer mülkünüzde ayrı AI görünürlüğü raporları erişime açıldıysa, onu da bağımsız bir katman gibi okumak gerekir; aksi halde web araması verisiyle karışır ve teşhis bulanıklaşır. Bu noktada Search Console verisini farklı görünürlük katmanlarıyla birlikte izlemek için AI görünürlük analizi gibi tamamlayıcı bir panel operasyonel avantaj sağlar.
Index kapsamı, Crawl Stats ve GA4 ile bulgular nasıl doğrulanır?
Bir page group’ta gösterim veya tıklama düşüşü gördüğünüzde ilk refleks “sıralama düştü” olmamalı. Önce bunun talep kaybı mı, indeks sorunu mu, yoksa crawl sapması mı olduğunu ayırın. Kategori şablonunda ortalama konum aynıyken gösterim kırılıyorsa sorgu talebine ya da kapsama bakın; ürün şablonunda sayfa sayısı artmasına rağmen görünürlük artmıyorsa kanonikleşme veya dizine ekleme sorununu araştırın. Crawl Stats ve kapsam raporları burada performans grafiğinin arkasındaki teknik nedeni doğrulamak için gereklidir.
GA4 ile çapraz okuma ikinci güvenlik katmanıdır. Google’ın Search Console ve Analytics dokümanı, iki aracı birlikte kullanmanın sitenin Google’da nasıl bulunduğunu ve sitede nasıl kullanıldığını daha kapsamlı gösterdiğini açıkça söyler (Google Search Central Documentation). Aynı doküman; tıklamalarla oturumların birebir eşleşmeyeceğini, kanonik URL farklarının ve zaman diliminin sapma yaratabileceğini de vurgular. Bu yüzden landing page trafiği düşmeyen ama GSC tıklaması gerileyen gruplarda veri farkını paniğe çevirmeden yorumlamak gerekir.
Büyük sitelerde arayüz bazen yetmez. Google, 9 Nisan 2025’te Search Analytics API için saatlik veri desteğini duyurdu ve son 10 güne kadar saatlik kırılım alınabildiğini açıkladı (Google Search Central Blog). Bu, özellikle ani deploy etkisini, toplu indeksleme sorunlarını veya yeni yayınlanan içeriklerin ilk performansını okumada değerli. Yine de unutmayın: Search Console’da bazı query ve page satırları gizlilik veya depolama sınırları nedeniyle eksik görünebilir. Bu yüzden tek export dosyasıyla kesin hüküm vermek yerine, trendi farklı veri kaynaklarıyla teyit etmek daha güvenlidir.
90 günlük örnek: kategori, ürün, blog ve filtreli URL gruplarında ne bulduk?
Buradaki örnek, saha gerçekliğine uygun ama anonimleştirilmiş bir 90 günlük akıştır. Dört ana grup vardı: 1.240 kategori URL’si, 18.600 ürün URL’si, 340 blog içeriği ve 8.900 filtreli URL. İlk bakışta en sert kırılma ürün grubunda görünüyordu; fakat grup bazlı okumada asıl sorun filtreli URL setindeydi. Gösterimler sert artıyor, tıklamalar aynı hızda gelmiyor ve ortalama konum dalgalanıyordu. Bu kombinasyon, yeni talep kazanımından çok şablon dağınıklığına işaret etti.
Son 90 günde kategori grubunda CTR 0,8 puan geriledi ama ortalama konum neredeyse sabit kaldı; bu bize başlık ve snippet tarafını öncelememiz gerektiğini gösterdi. Ürün grubunda gösterim düşüşü sınırlıydı, ancak indekslenen URL sayısında dengesizlik vardı; burada kanonik sinyaller ve varyasyon URL’leri öne çıktı. Blog grubunda ise daha az URL olmasına rağmen tıklama kaybı trafik etkisi açısından düşüktü. Filtreli URL grubunda yanlış eşleşen parametre desenlerini temizlediğimizde, ilk raporda sorunlu görünen satırların yaklaşık beşte biri analizin dışına çıktı; karar kalitesini asıl artıran nokta buydu.
Bu tip örneklerde en sık gördüğümüz hata, her düşüşü aynı önemde ele almak. Oysa öncelik sırası genelde şöyledir:
- İndeks ve kanonik sorunu üreten şablonlar
- Yüksek gösterimli ama düşen CTR’lı şablonlar
- Cihaz veya ülke bazında bozulmuş kritik gruplar
- Trafik etkisi sınırlı içerik kümeleri
Pratikte ekip toplantısına tek tek URL listesiyle değil, “hangi şablon ne kadar trafik riski taşıyor” özetiyle girmek çok daha işlevseldir. Deneyim tarafında en net gözlem şu: regex temizliği yapılmadan alınan kararlar, çoğu zaman teknik ekibi yanlış işe yönlendirir.
Bulguları SEOYEN ile nasıl önceliklendirip ekibe aktarırsınız?
Search Console bulgusu tek başına teşhis değil, operasyon başlangıcıdır. Sağlıklı akış; page group içgörüsünü teknik risk, görünürlük ve görev yönetimiyle birleştirmektir. Bu noktada site sağlığı kontrolleri ile aynı şablondaki teknik sinyalleri, sıralama takibi panosu ile sorgu tarafındaki hareketi ve Search Console verisini aynı operasyon çerçevesinde bir araya getirmek ekip içi iletişimi hızlandırır.
Ahrefs, SEMrush, SEOptimer, Moz ve SE Ranking kendi alanlarında güçlü araçlardır; özellikle geniş veri katmanları ve uluslararası kullanım senaryoları için sık değerlendirilirler. SEOYEN’in farkı, bu analizi Türkçe arayüz, TL bazlı fiyatlandırma ve yerel Türkçe destek ile daha erişilebilir bir operasyon akışına çevirmesidir. Yani mesele yalnızca veri görmek değil; veriyi Türkiye’deki ekiplerin daha hızlı anlayıp aksiyona dönüştürmesidir. Plan seçimini değerlendirmeniz gerekirse güncel paket detayları üzerinden bakmak daha doğru olur.
Yöneticilere gidecek özet raporun kısa ama karar odaklı olması gerekir. En iyi çalışan format genelde üç parçalıdır: sorunlu page group, olası kök neden, beklenen trafik etkisi. Böylece içerik, teknik SEO ve ürün ekipleri aynı tablo üzerinden konuşur. SEOYEN’in tek platform yaklaşımı da tam burada değer üretir: Search Console bulgusunu ayrı Excel dosyalarında dağıtmak yerine, tek akışta izlemek ve düzenli kontrol alışkanlığına bağlamak daha kolay hale gelir.
Kaynaklar
- Leistungsbericht (Google-Suchergebnisse): Übersicht und grundlegende Einrichtung
- Besseres Filtern und Vergleichen von Daten in Leistungsberichten
- Search Console- und Google Analytics-Daten für die Suchmaschinenoptimierung (SEO) verwenden
- Introducing Query groups in Search Console Insights
- The Search Analytics API now supports hourly data
- Introducing weekly and monthly views in Search Console
Sıkça Sorulan Sorular
Search Console’da regex filtresi, page veya query alanında gelişmiş eşleşme kurmak için kullanılır. Önce raporda ilgili filtreyi açın, ardından özel ifade seçeneğiyle klasör, slug veya parametre deseninizi yazın. Ama asıl önemli kısım yazmak değil, doğrulamaktır. Regex’inizin yanlış eşleştirdiği URL’leri ve yakalayamadığı URL’leri örnek listeyle kontrol etmelisiniz. Özellikle kategori, ürün ve filtreli sayfalarda benzer URL yapıları yüzünden false positive ve false negative sık görülür. En sağlıklı yaklaşım, regex’i küçük örnek setlerle test edip sonra tüm gruba uygulamaktır.
İlk adım URL envanteri çıkarmaktır. Sonra sayfaları kategori, ürün, blog, kampanya, filtreli URL ve parametreli sayfalar gibi işlevsel gruplara ayırırsınız. Eğer klasör yapısı temizse bu iş kolaylaşır. değilse slug kuralları ve parametre desenleriyle ikinci katman kurmanız gerekir. Amaç sadece benzer URL’leri bir araya getirmek değil, aynı üretim mantığıyla oluşmuş sayfaları birlikte izlemektir. Böylece tek bir sayfadaki anormallik yerine, bütün şablonda tekrar eden başlık, indeks, crawl veya CTR problemlerini daha hızlı bulabilirsiniz.
Önce benzer URL’leri aynı page group içinde toplarsınız. Ardından her grupta tıklama, gösterim, CTR ve ortalama konumu tarih karşılaştırmasıyla incelersiniz. Sapma gösteren gruplar bulunduğunda bunları indeks kapsamı, Crawl Stats ve GA4 landing page verisiyle doğrulamak gerekir. Bu akış sayesinde düşüşün talep mi, sıralama mı, kanonikleşme mi, yoksa tarama sorunu mu olduğunu ayırabilirsiniz. En önemli fark, URL bazlı değil şablon bazlı düşünmektir. bu yaklaşım büyük sitelerde analiz hızını ve karar kalitesini ciddi biçimde artırır.
Aynı page group’u tarih karşılaştırmasıyla açın ve CTR değişimini tek başına değil, ortalama konum ve gösterimle birlikte okuyun. Konum sabitken CTR düşüyorsa başlık, snippet veya SERP görünümü etkilenmiş olabilir. Konum da düşüyorsa sorun daha çok sıralama veya iç rekabet tarafındadır. Cihaz ve ülke kırılımı eklemek de önemlidir. bazen sadece mobilde veya belirli pazarlarda düşüş olur. Haftalık ve aylık görünüm, günlük gürültüyü azalttığı için gerçek trendi daha net gösterir. Bu yüzden CTR analizi kısa dönem grafiğe bakıp karar vermekle sınırlı kalmamalıdır.
En sağlam yöntem, klasör yapısı, slug kuralları ve URL parametrelerini birlikte kullanmaktır. Kategori sayfaları çoğu zaman belirli klasör desenleriyle ayrılırken ürün sayfalarında detay slug’ları veya ürün ID yapıları öne çıkar. Blog içeriklerinde ise içerik klasörü, tarih yapısı ya da yazar etiketi gibi farklı sinyaller olabilir. Bu kuralları regex filtreleriyle Search Console’a taşıyabilirsiniz. Ancak gruplar oluşturulduktan sonra örnek URL listesiyle temizlik yapmak gerekir. Çünkü benzer URL yapıları yanlış eşleşmeye çok açıktır ve bu hata şablon bazlı analizin kalitesini doğrudan düşürür.
Page groups, URL şablonlarını yani hangi sayfa tipinin nasıl performans verdiğini izler. Query groups ise benzer niyet taşıyan sorguları kümeler ve kullanıcıların aynı konuyu hangi farklı aramalarla ifade ettiğini görmenizi sağlar. Kısacası biri sayfa mimarisini, diğeri sorgu niyetini anlamaya yarar. İkisini birlikte kullandığınızda, örneğin ürün sayfalarının genel performansını izlerken aynı grubun içindeki markalı ve non-brand sorgu davranışını ikinci katman olarak okuyabilirsiniz. Bu da özellikle CTR yorumunda ve içerik önceliklendirmesinde daha doğru karar vermenizi sağlar.
Crawl Stats, sorunlu görünen bir page group’un gerçekten tarama problemi yaşayıp yaşamadığını anlamak için kullanılır. Örneğin filtreli URL’lerde gösterim düşüşü görüyorsanız, aynı dönemde tarama hacmi artmış mı, yanıt kodları bozulmuş mu, gecikme yükselmiş mi diye bakarsınız. Böylece performans düşüşünün teknik köküne yaklaşabilirsiniz. Crawl verisini tek başına yorumlamak doğru değildir. en iyi kullanım, Search Console performans bulgusu ve indeks kapsamı sinyaliyle birlikte okumaktır. Özellikle büyük sitelerde tarama davranışını şablon bazlı düşünmek, gereksiz URL üretimini ve crawl sapmalarını daha görünür hale getirir.