Faceted Navigation Nedir? E-Ticaret Filtre URL’leri Nasıl Yönetilmeli?

Faceted navigation veya yönlü gezinme, kullanıcıların bir ürün veya içerik listesini marka, renk, ölçü, fiyat, stok durumu ve teknik özellikler gibi niteliklerle daraltmasını sağlayan filtreleme sistemidir.

Kullanıcı açısından bu sistem basit görünür:

Akülü Matkaplar
      ↓
Marka: Bosch
      ↓
Voltaj: 18 V
      ↓
Motor: Kömürsüz

Teknik açıdan ise her seçim yeni bir URL veya URL durumu oluşturabilir:

/akulu-matkaplar/?marka=bosch
/akulu-matkaplar/?voltaj=18v
/akulu-matkaplar/?marka=bosch&voltaj=18v
/akulu-matkaplar/?marka=bosch&voltaj=18v&motor=komursuz

İlk URL anlamlı bir ürün kümesini temsil edebilir. Sonraki kombinasyonlardan bazıları yalnız kullanıcı deneyimine hizmet edebilir, bazıları mevcut bir kategoriyle çakışabilir, bazılarıysa hiçbir sonuç üretmeyebilir.

Sorun filtrenin kendisi değildir. Sorun, kullanıcı arayüzündeki her seçimin arama motoru açısından ayrı bir sayfaya dönüşebilmesidir.

Filtre SEO’su bütün filtreleri indekslemek veya tamamını engellemek değildir. Her URL sınıfını search demand, ürün derinliği, sayfa değeri, crawl maliyeti ve sürdürülebilirlik üzerinden yönetmektir.

Bu nedenle faceted navigation kararı yalnız teknik SEO görevi değildir. Ürün taksonomisi, kategori ownership’i, internal linking, stok yönetimi ve kullanıcı deneyimi aynı karar sisteminin parçalarıdır.

Faceted navigation nedir?

Facet, bir ürün grubunu tanımlayan filtrelenebilir niteliktir. Marka, renk, beden, malzeme, kullanım alanı ve kapasite birer facet olabilir. Faceted navigation ise kullanıcının bu niteliklerden birini veya birkaçını seçerek listeyi daraltmasını sağlayan navigasyon modelidir.

Örneğin bir hırdavat kategorisinde şu facet’ler bulunabilir:

• marka,
• voltaj,
• akü kapasitesi,
• mandren ölçüsü,
• motor tipi,
• ürün tipi,
• stok durumu,
• fiyat aralığı.

Facet, kategori veya arama sonucu ile aynı şey değildir. Aralarındaki farkı sayfa görevi belirler.

Yapı	Temel görevi	Tipik örnek
Kategori	Kalıcı ve tanımlı bir ürün grubunun ticari owner’ı olmak	Akülü matkaplar
Facet	Mevcut ürün listesini bir niteliğe göre daraltmak	18 V, kömürsüz, Bosch
Sıralama	Aynı ürünleri farklı sırada göstermek	Fiyata göre artan
Site içi arama	Kullanıcının serbest sorgusuna sonuç üretmek	?q=duvar+delme
Pagination	Aynı listenin sonraki ürün grubuna erişmek	?page=2

Bu yapıların hepsi URL parametresi kullanabilir. Fakat aynı teknik formatta görünmeleri, aynı index ve crawl kararını almaları gerektiği anlamına gelmez.

Filtreler nasıl devasa bir URL alanı üretir?

Bir kategoride 12 marka, 8 voltaj değeri, 2 motor tipi, 4 mandren ölçüsü ve 3 stok durumu bulunduğunu düşünelim.

12 × 8 × 2 × 4 × 3 = 2.304 kombinasyon

Bu yalnızca her gruptan tek seçim yapıldığı en basit senaryodur. Birden fazla markanın aynı anda seçilebildiği, fiyat aralıklarının URL ürettiği, filtre sırasının değişebildiği ve sonuçların ayrıca sıralanabildiği bir sistemde olası URL sayısı çok daha hızlı büyür.

Aynı ürün listesi şu URL’lerin tamamından açılabiliyorsa sorun daha da genişler:

?marka=bosch&voltaj=18v
?voltaj=18v&marka=bosch
?marka=bosch&marka=bosch&voltaj=18v
?min_fiyat=5000&max_fiyat=1000
?marka=bosch&voltaj=18v&sort=price_asc
?marka=bosch&voltaj=18v&utm_source=email

Aynı parametrenin bir URL’de birden fazla kez bulunması her sistemde otomatik olarak hata değildir. Bazı filtre motorları tekrarlanan parametreleri geçerli bir “VEYA” seçimi olarak yorumlayabilir. Kontrol edilmesi gereken; aynı değerin gereksiz yere tekrarlanması, sistemin desteklemediği çoklu seçimler ve minimum değerin maksimum değerden büyük olması gibi mantıksal olarak geçersiz durumlardır.

Kullanıcı aynı veya çok benzer sonuçları görürken crawler bunları önce ayrı URL’ler olarak keşfedebilir.

Google, parametre tabanlı faceted navigation sistemlerinin çok büyük hatta pratikte sonsuz URL alanları oluşturabildiğini; bunun gereksiz crawling’e ve yeni, yararlı URL’lerin daha yavaş keşfedilmesine yol açabileceğini açıkça belirtiyor.^[1]

Bu problemin search pipeline içindeki yerini anlamak için crawling, indexing, retrieval ve ranking arasındaki ayrımı ayrıca inceleyebilirsiniz. Filtre yönetimi doğrudan sorgu anındaki ranking’den önce, URL discovery ve crawling katmanında başlar.

Her filtre problemi “crawl budget krizi” değildir

Crawl budget kavramı burada gereğinden fazla dramatize edilmemelidir. Google’ın ileri seviye crawl budget rehberi esas olarak milyonlarca URL’ye sahip veya on binlerce URL’si çok sık değişen siteleri hedefler.^[8]

Ancak daha küçük bir e-ticaret sitesinde bile kontrolsüz filtre URL’leri şu problemleri oluşturabilir:

• Search Console raporlarında gereksiz URL kümeleri,
• yanlış canonical seçimleri,
• aynı sorgu ailesini hedefleyen birden fazla landing page,
• boş ve anlamsız sonuç sayfaları,
• sunucu ve render kaynaklarının düşük değerli URL’lere harcanması,
• yeni kategori ve ürünlerin keşif yollarının bulanıklaşması.

Dolayısıyla amaç “crawl budget artırmak” değil, sitenin ürettiği URL alanını gerçek kullanıcı ve arama ihtiyaçlarıyla uyumlu hale getirmektir.

Filtre URL’si neden otomatik olarak landing page değildir?

Bir filtre kombinasyonunun teknik olarak URL üretmesi, organik aramada ayrı bir sayfa olması gerektiğini kanıtlamaz.

Örneğin aşağıdaki URL kullanılabilir bir filtre sonucu oluşturabilir:

/akulu-matkaplar/?marka=bosch&voltaj=18v&stok=1

Fakat bu URL için ayrıca şu soruların cevaplanması gerekir:

• “Bosch 18 V akülü matkap” bağımsız ve anlamlı bir arama ihtiyacı mı?
• Arama sonuçları bu ihtiyaca kategori, ürün veya başka bir sayfa türüyle mi cevap veriyor?
• Bu kombinasyonda yeterli ve sürdürülebilir ürün bulunuyor mu?
• Sayfa yalnız filtrelenmiş liste değil, ayrı bir seçim değeri üretebilir mi?
• Mevcut başka bir kategori aynı ihtiyacın owner’ı mı?
• Ürün veya stok yapısı değiştiğinde sayfa korunabilecek mi?

Bu sorular cevaplanmadan filtreyi indexable yapmak, ürün kataloğundaki her etiketi SEO landing page’ine çevirmek olur.

Query ile information need arasındaki ayrım burada doğrudan page ownership kararına dönüşür. Kullanıcının sorgusunda bir marka ve teknik özellik bulunması, mutlaka iki facet’in birleştiği ayrı bir sayfa istediği anlamına gelmez.

Filtre URL’leri hangi sınıflara ayrılmalı?

Pratik bir faceted navigation sistemi en az üç URL sınıfını birbirinden ayırmalıdır.

1. Organik owner olacak facet

Bağımsız search demand taşıyan, farklı kullanıcı ihtiyacını karşılayan, yeterli ürün derinliğine sahip ve uzun vadede korunabilecek seçilmiş filtre veya kategori sayfasıdır.

Örnek:

/akulu-matkaplar/komursuz/

Bu sayfa gerçekten “kömürsüz akülü matkap” ihtiyacının owner’ı olacaksa:

• taranabilir ve indexable olmalı,
• self-referencing canonical kullanmalı,
• XML sitemap’e dahil edilebilmeli,
• kategori ve ilgili rehberlerden iç bağlantı almalı,
• kendine ait başlık, kapsam ve seçim değeri sunmalı,
• boşalmayacak kadar sürdürülebilir bir ürün kümesine dayanmalıdır.

Burada temiz bir statik URL üretmek çoğu zaman yönetimi kolaylaştırır. Ancak parametreli URL de teknik olarak çalışabilir. Kritik nokta URL’nin görünümü değil, tek ve tutarlı owner olarak yönetilmesidir.

2. Yalnız kullanıcı deneyimi için çalışan facet

Kullanıcıya ürün listesini daraltma imkânı verir fakat bağımsız organik landing page değeri üretmez.

Örnekler:

• yalnız stoktakileri göster,
• 0–500 TL arası,
• aynı gün kargo,
• iki geçici kampanya etiketinin birleşimi,
• kullanıcıya yararlı fakat ayrı search demand taşımayan teknik seçimler.

Bu URL’lerin kullanıcı için çalışması gerekir. Fakat sitemap’e girmeleri, site genelinde güçlü iç bağlantı almaları veya ayrı SEO owner’ları gibi optimize edilmeleri gerekmez.

3. Crawl trap veya düşük değerli URL

Kullanıcıya ve arama sistemine anlamlı yeni bir sonuç sunmayan; tekrar, sıralama, tracking, boş kombinasyon veya hatalı parametrelerden oluşan URL’lerdir.

Örnekler:

?sort=price_asc
?sort=price_desc
?utm_source=newsletter
?marka=bosch&marka=bosch
?min_fiyat=5000&max_fiyat=1000
?page=9999

Bu sınıf yalnız index dışında tutulmamalı; mümkün olduğunda URL’nin üretilmesi ve tekrar tekrar keşfedilmesi de önlenmelidir.

Faceted navigation karar tablosu

Aşağıdaki tablo nihai teknik reçete değil, sınıflandırma başlangıcıdır. Özellikle UX filtreleri için yöntem; URL’nin halihazırda indekste olup olmadığına, crawler’ın sayfayı görmesi gerekip gerekmediğine ve sistemin URL üretim biçimine göre seçilmelidir.

URL sınıfı	Search demand	Index hedefi	Crawl yaklaşımı	Canonical yaklaşımı	Sitemap
Seçilmiş organik facet	Bağımsız ve doğrulanmış	Index	Açık	Self-referencing	Evet
UX filtresi — deindex geçişi	Zayıf veya yok	Index dışı	noindex görülebilsin diye geçici olarak açık	Yalnız gerçekten duplicate/çok benzerse parent değerlendirilebilir	Hayır
UX filtresi — kalıcı crawl baskılama	Yok	Index hedeflenmez	URL üretimi ve internal link sınırlandırılır; gerekiyorsa robots.txt	Canonical crawl kontrolünün yerine kullanılmaz	Hayır
Sıralama ve tracking parametresi	Yok	Index dışı	Internal link ve parametre üretimi sınırlandırılır; gerekirse engellenir	Aynı içeriğin temiz URL’si	Hayır
Boş sonuç kombinasyonu	Yok	Index dışı	İstek oluşursa gerçek 404	Gerekmez	Hayır
Tekrarlı veya anlamsız parametre	Yok	Index dışı	Üretimi önlenir; uygun durumda 404 veya normalize edilir	Canonical tek başına çözüm değildir	Hayır
Pagination	Landing page talebi değil	Keşif zincirinin parçası	Taranabilir <a href> bağlantıları	Her sayfa self-referencing	Genellikle yalnız temel owner’lar

Hangi filtre indexable olabilir?

Bir facet’i organik owner’a dönüştürmeden önce altı karar kapısından geçirmek gerekir.

1. Bağımsız search demand var mı?

Arama hacmi tek başına yeterli değildir. Talebin varlığı farklı kaynaklardan doğrulanabilir:

• Search Console sorguları,
• anahtar kelime ve SERP verileri,
• site içi arama kayıtları,
• kategori ve filtre kullanım davranışı,
• müşteri soruları ve satış ekibi içgörüleri,
• ürün grubu talebinin mevsimselliği.

“Marka + ürün” veya “teknik özellik + ürün” kalıbının görülmesi aday üretir; otomatik owner üretmez.

2. İhtiyaç gerçekten farklı mı?

Ana kategori ile filtre sayfası aynı görevi yapıyorsa yeni URL mevcut owner’ı bölme riski taşır.

Örneğin “akülü matkaplar” geniş ürün inceleme ihtiyacını karşılar. “Kömürsüz akülü matkaplar” ise motor teknolojisini özellikle isteyen kullanıcıya farklı ürün seçimi ve açıklama sunabilir. Buna karşılık “stokta bulunan akülü matkaplar” çoğunlukla ayrı bir bilgi ihtiyacı değil, mevcut listenin geçici durumudur.

3. SERP ayrı bir sayfa türünü destekliyor mu?

Arama sonuçları yalnız rakiplerin ne yaptığına bakmak için değil, Google’ın sorgu için hangi sayfa rollerini uygun gördüğünü anlamak için incelenir.

• Sonuçlarda kategori sayfaları mı var?
• Ürün sayfaları mı ağırlıkta?
• Marka sayfaları mı gösteriliyor?
• Rehber veya karşılaştırma içeriği mi öne çıkıyor?
• Ana sorgu ile facet sorgusunun sonuç kümeleri ne kadar ayrışıyor?

SERP analizi kararı tek başına vermez; fakat yanlış sayfa türü üretme ihtimalini azaltır.

4. Ürün derinliği yeterli ve sürdürülebilir mi?

“En az 10 ürün varsa kategori açılır” gibi evrensel bir eşik yoktur. Üç yüksek değerli ve sürekli stoklanan ürün bazı nişlerde yeterli olabilirken, elli geçici veya birbirinin aynısı ürün anlamlı bir sayfa oluşturmayabilir.

Şunlara birlikte bakılmalıdır:

• aktif ürün sayısı,
• stok devamlılığı,
• ürün çeşitliliği,
• varyantların gerçek farklılığı,
• tedarik ve kategori yaşam döngüsü,
• kullanıcının karşılaştırma yapabileceği seçenek derinliği.

5. Sayfa filtrelenmiş liste dışında değer üretebilir mi?

Indexable facet’in mutlaka yüzlerce kelimelik kategori açıklamasına ihtiyacı yoktur. Ancak sayfanın kullanıcı görevini ana kategoriden daha iyi tamamlaması gerekir.

Bu değer şunlardan gelebilir:

• doğru alt sınıflandırma,
• ürün kartlarında ilgili teknik özelliklerin öne çıkarılması,
• facet’e özel seçim kriterleri,
• uyumluluk veya kullanım bilgisi,
• ilgili rehber ve karşılaştırmalar,
• kullanıcının karar vermesini kolaylaştıran kısa açıklamalar.

6. Mevcut owner ile çakışıyor mu?

Yeni sayfa açılmadan önce mevcut kategori, ürün, marka ve rehber URL’lerinin sorgu kapsamı kontrol edilmelidir.

Aynı ihtiyaca iki owner atanırsa sistem şu hale gelebilir:

Ana kategori
      ↘
       Aynı sorgu ailesi
      ↗
Filtre landing page'i

Bu durumda sorun yalnız “keyword cannibalization” etiketi değildir. Internal linking, canonical, sitemap ve içerik sinyalleri hangi URL’nin temsilci olduğunu açık biçimde gösteremez.

robots.txt, noindex, canonical ve nofollow arasındaki fark

Faceted navigation uygulamalarındaki en büyük hata, dört farklı aracı aynı görevi yapıyormuş gibi kullanmaktır.

Yöntem	Temel görevi	Yapmadığı şey
robots.txt	Crawler’ın belirli URL kalıplarına erişimini yönetmek	URL’nin arama sonuçlarında kesinlikle görünmemesini garanti etmez
noindex	Sayfayı arama sonuçlarının dışında tutmak	Crawling’i durdurmaz; kuralın görülmesi için sayfa taranabilmelidir
rel="canonical"	Duplicate veya çok benzer sayfa kümesinde tercih edilen temsilciyi bildirmek	URL üretimini veya crawling’i anında durdurmaz
rel="nofollow"	Belirli bağlantının takip edilmemesi yönünde sinyal vermek	URL’nin başka yollarla keşfedilmesini engellemez
404	İstenen URL’de gerçek bir karşılık bulunmadığını bildirmek	Geçerli fakat index dışı tutulmak istenen sayfanın yerine kullanılmaz

robots.txt ne zaman anlamlıdır?

Belirli parametre sınıflarının organik aramada hiçbir rolü yoksa ve bu URL’lerin crawling’i sistem kaynaklarını tüketiyorsa robots.txt ile erişim sınırlandırılabilir.

Ancak robots.txt bir index kaldırma mekanizması değildir. Google, başka sayfalardaki bağlantılardan keşfettiği engellenmiş bir URL’yi içeriğini taramadan URL olarak gösterebilir.^[2]

Bu nedenle halihazırda indekste bulunan URL’lere aynı anda noindex ekleyip robots.txt ile engel koymak çelişkili bir geçiş planıdır. Crawler sayfaya erişemezse noindex kuralını göremez.^[3]

noindex ne zaman anlamlıdır?

Kullanıcı için erişilebilir kalması gereken fakat arama sonuçlarında yer almaması istenen sayfalarda kullanılabilir.

Fakat binlerce filtre URL’sini noindex yapmak crawling problemini otomatik olarak çözmez. Google’ın bu kuralı görmesi için URL’leri taraması gerekir. Amaç büyük bir URL sınıfının hiç taranmamasıysa üretim ve keşif mekanizması ayrıca kontrol edilmelidir.

Canonical ne zaman anlamlıdır?

Canonical, aynı veya çok benzer ana içeriğin birden fazla URL’den açıldığı durumlarda tercih edilen temsilciyi belirtmek için kullanılır.

Örneğin ürün listesi değişmeden yalnız sıralama değişiyorsa temiz kategori URL’si canonical olarak gösterilebilir:

/akulu-matkaplar/?sort=price_asc
        ↓ canonical
/akulu-matkaplar/

Ancak ürün kümesi ve kullanıcı görevi gerçekten farklı olan bir sayfayı ana kategoriye canonical’lamak, sayfayı ayrı owner olarak konumlandırma iddiasıyla çelişir.

Google canonical’ı bir kural değil, güçlü bir sinyal olarak değerlendirir. Ayrıca faceted URL’lerde canonical kullanımının zamanla crawl hacmini azaltabilse de doğrudan crawl engelleme yöntemlerine göre uzun vadede daha az etkili olabileceğini belirtir.^[1]

noindex ile canonical aynı kararın iki eş anlamlı uygulaması değildir. Google, site içi canonical seçiminde noindex kullanmak yerine rel="canonical" işaretini önerir.^[4]

nofollow neden tek başına yeterli değildir?

Filtre bağlantılarına nofollow eklemek bazı keşif yollarını azaltabilir. Fakat aynı URL’ye giden bütün bağlantılarda uygulanması gerekir ve URL sitemap, dış bağlantı veya başka bir iç bağlantı üzerinden yine keşfedilebilir.

Bu nedenle nofollow, URL üretim kurallarının ve doğru HTTP/index sinyallerinin yerine geçmez.

Halihazırda indekslenmiş filtre URL’leri nasıl temizlenmeli?

Mevcut filtre URL’leri Google indeksine girdiyse doğrudan bütün parametreleri robots.txt ile engellemek doğru geçiş planı değildir. Googlebot engellenen sayfadaki noindex kuralını göremez.^[3]

Daha kontrollü sıra şöyledir:

1. URL sınıflarını ayırın: Organik owner olarak korunacak facet’leri whitelist’e alın; UX filtreleri, sıralamalar ve crawl trap’leri ayrı kümelere bölün.
2. Yeni keşif yollarını azaltın: Gereksiz parametre URL’lerini sitemap’ten çıkarın, internal linkleri temiz URL’lere yöneltin ve uygulamanın yeni anlamsız kombinasyon üretmesini durdurun.
3. İndeksten çıkması gereken URL’leri taranabilir bırakın: Sayfalarda noindex kullanın ve Googlebot’un bu kuralı okuyabilmesi için geçici olarak crawl erişimini açık tutun.
4. Deindex sürecini izleyin: Search Console örnekleri, URL Inspection ve gerekiyorsa sunucu logları üzerinden URL kümesinin indeksten çekildiğini doğrulayın.
5. Kalıcı crawl politikasını uygulayın: Deindex tamamlandıktan sonra organik değeri bulunmayan büyük parametre sınıflarının üretimini ve internal linking’ini sınırlandırın; sunucu yükü veya crawl alanı gerektiriyorsa uygun robots.txt kurallarını devreye alın.
6. Geçersiz URL’leri ayrı yönetin: Boş, tekrarlı veya mantıksal olarak imkânsız kombinasyonları canonical’a bırakmak yerine gerçek 404 veya uygulama seviyesinde normalizasyon ile çözün.

Bu bir “önce noindex, sonra her durumda robots.txt” reçetesi değildir. Son aşamadaki crawl engeli yalnız URL sınıfının organik değeri bulunmadığı ve crawling’in gerçekten sınırlandırılması gerektiği doğrulanırsa uygulanır.

Boş ve anlamsız filtre kombinasyonları nasıl yönetilmeli?

Sonuç üretmeyen kombinasyonların 200 OK durumuyla boş kategori şablonu döndürmesi doğru değildir.

Örnek:

/akulu-matkaplar/?min_fiyat=5000&max_fiyat=1000
/akulu-matkaplar/?marka=olmayan-marka
/akulu-matkaplar/?page=9999

Google, boş sonuç veren, tekrarlı filtre içeren, mantıksız kombinasyon oluşturan ve var olmayan pagination URL’lerinde gerçek 404 durum kodu döndürülmesini öneriyor. Ayrıca bu URL’lerin ortak bir hata sayfasına yönlendirilmemesi gerektiğini belirtiyor.^[1]

Buradaki ayrım şudur:

• Geçici olarak stokta ürün yok: Sayfanın uzun vadeli bir owner olup olmadığına göre korunabilir.
• Filtre kombinasyonunun katalogda hiçbir karşılığı yok: Gerçek 404 daha doğru olabilir.
• Parametre mantıksal olarak imkânsız: URL’nin hiç üretilmemesi, oluşursa 404 vermesi gerekir.
• Ürünler var fakat liste JavaScript hatasıyla boş görünüyor: Bu index kararı değil, render ve uygulama hatasıdır.

“Sonuç bulunamadı” mesajı gösterip HTTP tarafında 200 döndürmek, crawler’a sayfanın geçerli olduğu sinyalini vermeye devam eder.

Parametre sırası ve URL tutarlılığı neden önemlidir?

Aynı filtre seti farklı sıralarla yeni URL üretmemelidir.

?marka=bosch&voltaj=18v
?voltaj=18v&marka=bosch

İki URL aynı sonucu veriyorsa uygulama tek bir parametre sırası belirlemeli ve bütün iç bağlantılarda onu kullanmalıdır.

Google, standart parametre ayracı olarak & kullanılmasını; filtreler URL path’i içine yazılıyorsa mantıksal sıranın sabit tutulmasını ve tekrarlı filtrelerin engellenmesini öneriyor.^[1]

E-ticaret URL’lerinde ayrıca şu kurallar yararlıdır:

• Aynı içerik için tek URL biçimi üretin.
• Parametre adlarını açık key=value yapısında kullanın.
• Session ID, geçici zaman damgası ve kullanıcıya özel değerleri iç bağlantılara taşımayın.
• Indexable sayfalara verilen iç bağlantı, sitemap ve canonical URL’lerini aynı biçimde tutun.
• JavaScript ile oluşan navigasyonda gerçek <a href> bağlantılarını koruyun.

Google’ın e-ticaret URL rehberi, aynı sayfanın farklı URL biçimlerinden erişilebilir olmasının gereksiz crawling oluşturabileceğini; iç bağlantı, sitemap ve canonical işaretlerinde aynı URL’nin kullanılmasını öneriyor.^[5]

Facet ile ürün varyantı aynı şey midir?

Hayır. Her ikisi de renk, beden, kapasite veya teknik özellik gibi nitelikler kullanabildiği için birbirine karıştırılabilir; fakat temsil ettikleri nesne ve sayfa görevi farklıdır.

Yapı	Neyi değiştirir?	Örnek	Temel SEO sorusu
Kategori facet’i	Bir ürün listesindeki aday kümesini daraltır	Yalnız 18 V akülü matkapları göster	Bu filtre ayrı bir organik landing page olmalı mı?
Ürün varyantı	Belirli bir ürünün satın alınabilir sürümünü seçer	Telefonun 256 GB sürümü veya tişörtün M bedeni	Varyant ayrı URL, canonical, stok, fiyat ve ürün kimliğiyle nasıl temsil edilmeli?

Google ürün varyantları için tek sayfalı ve çok sayfalı modelleri ayrı ayrı tanımlar; ProductGroup, hasVariant, variesBy ve productGroupID gibi ilişkiler ürün verisi katmanının parçasıdır.^[9]

Dolayısıyla kategori filtresi için verilen index ve crawl kararı, ürün varyantı URL’sine mekanik olarak uygulanmamalıdır. Facet yönetimi listeleme mimarisini; varyant yönetimi ise ürün kimliği, offer, fiyat, stok ve structured data ilişkilerini kapsar.

Pagination ile faceted navigation birlikte nasıl çalışır?

Pagination, filtreyle aynı iş değildir. Filtre ürün kümesini değiştirir; pagination aynı kümenin sonraki bölümüne erişim sağlar.

Örnek:

/akulu-matkaplar/?page=2
/akulu-matkaplar/?marka=bosch&page=2

Google, paginated serideki her sayfanın benzersiz URL’ye ve self-referencing canonical’a sahip olmasını; bütün sayfaların ilk sayfaya canonical’lanmamasını öneriyor. Sayfalar arasında taranabilir <a href> bağlantıları bulunmalıdır.^[6]

Faceted navigation ile pagination birleştiğinde şu kontroller gerekir:

• Filtre uygulandığında toplam sayfa sayısı yeniden hesaplanmalı.
• Artık var olmayan ?page=n URL’leri gerçek 404 döndürmeli.
• Sıralama parametreleriyle pagination birleşip yeni duplicate seriler üretmemeli.
• Indexable facet’in paginated sayfalarından ürünlere ulaşılabilmeli.
• “Daha fazla yükle” veya sonsuz kaydırma, crawler’ın tıklamasına bağımlı tek keşif yolu olmamalı.

Google crawler’ları genellikle kullanıcı gibi butonlara tıklamaz. Bu nedenle load more ve infinite scroll kullanılan yapılarda ürün gruplarına ayrı URL’ler ve gerçek bağlantılar üzerinden erişim sağlanmalıdır.^[6]

Internal linking hangi filtre owner’larına verilmelidir?

Index kararı yalnız robots ve canonical etiketlerinden oluşmaz. Sitenin hangi URL’lere düzenli olarak bağlantı verdiği de mimari tercihi gösterir.

Google, site hiyerarşisini yalnız URL klasörlerinden çıkarmadığını; sayfalar arasındaki bağlantıları ve bir sayfanın site içinde aldığı linkleri de değerlendirdiğini belirtiyor.^[7]

Bu nedenle organik owner olacak seçilmiş facet’ler:

• ilgili parent kategoriden,
• uygun kardeş veya alt kategorilerden,
• ürün seçim rehberlerinden,
• teknik karşılaştırma içeriklerinden,
• gerektiğinde breadcrumb ve navigasyon bileşenlerinden

anlamlı bağlantılar almalıdır.

Yalnız UX için çalışan binlerce filtre kombinasyonuna site genelinde taranabilir bağlantı vermek ise URL alanını genişletebilir.

Doğru model şöyledir:

ANA KATEGORİ
     │
     ├── Seçilmiş alt kategori
     │        └── Ürünler
     │
     ├── Organik facet owner
     │        └── İlgili ürün kümesi
     │
     └── UX filtreleri
              └── Kullanıcı listesini daraltır

Her filtreyi linklemek de hiçbir filtreyi linklememek de doğru varsayılan değildir. Internal linking, organik owner kararının uygulamadaki karşılığı olmalıdır.

Faceted navigation nasıl denetlenir?

Filtre sistemini yalnız Screaming Frog benzeri bir crawler ile taramak yeterli değildir. Crawler sitenin bağlantı grafiğini simüle eder; Search Console Google’ın raporladığı durumları, sunucu logları ise botların gerçekte hangi URL’leri istediğini gösterir.

1. URL ve parametre envanterini çıkarın

Önce hangi parametre ailelerinin bulunduğunu belirleyin:

• filtre,
• sıralama,
• pagination,
• site içi arama,
• tracking,
• session veya kullanıcı durumu,
• ürün varyantı.

Parametreleri yalnız isimleriyle değil, oluşturdukları sayfa davranışıyla sınıflandırın.

2. URL örneklerini teknik sinyalleriyle birlikte kaydedin

Alan	Kontrol
HTTP durumu	200, 3xx, 404, 5xx
Robots erişimi	Crawl açık mı, engelli mi?
Robots meta	Index veya noindex?
Canonical	Self mi, parent mı, başka URL mi?
İç bağlantı	Kaç sayfadan ve hangi bağlamda link alıyor?
Ürün kümesi	Kaç ürün var, ana kategoriden ne kadar farklı?
Search demand	Bağımsız sorgu ve SERP ayrışması var mı?
Bakım durumu	Sayfa stok ve katalog değişimlerinde korunabilir mi?

3. URL çoğalmasını ölçün

Her kategori için yalnız mevcut filtre URL sayısını değil, sistemin teorik olarak kaç URL üretebildiğini anlamaya çalışın.

• Parametre sırası değişebiliyor mu?
• Aynı facet birden fazla kez eklenebiliyor mu?
• Sıfır sonuçlu kombinasyonlara link oluşuyor mu?
• Tracking parametreleri iç bağlantılarda kalıyor mu?
• Pagination üst sınırı olmayan URL’ler döndürüyor mu?
• Kullanıcı seçimi temizlendiğinde parametre URL’de kalıyor mu?

4. Search Console verisini inceleyin

Google, teknik sorunların incelenmesinde Crawl Stats ve Page Indexing raporlarının birlikte kontrol edilmesini önerir.^[10] Page Indexing raporunda özellikle şu kümeler filtre URL’leriyle ilişkilendirilebilir:

• Discovered – currently not indexed,
• Crawled – currently not indexed,
• Duplicate without user-selected canonical,
• Alternate page with proper canonical,
• Excluded by noindex,
• Soft 404,
• Blocked by robots.txt.

Bu etiketlerin hiçbiri tek başına çözüm söylemez. Önce örnek URL’lerin hangi parametre sınıfına ait olduğu belirlenmelidir.

5. Sunucu loglarıyla gerçek bot davranışını kontrol edin

Log analizi şu sorulara cevap verebilir:

• Googlebot en fazla hangi parametre kalıplarını tarıyor?
• Organik owner URL’leriyle düşük değerli filtre URL’leri hangi sıklıkta ziyaret ediliyor?
• Yeni ürün ve kategoriler ne kadar sürede taranıyor?
• Boş sonuç ve redirect URL’leri tekrar tekrar isteniyor mu?
• Filtre URL’leri sunucu yanıt süresini etkiliyor mu?

Log verisi yoksa Crawl Stats ve URL Inspection örnekleri başlangıç sağlayabilir; fakat bunlar tam URL düzeyinde sunucu kaydının yerini tutmaz.

6. Organik performansı URL sınıfına göre ayırın

Filtre URL’lerinin gösterim ve tıklama alması tek başına başarılı olduklarını göstermez.

Şunlara bakılmalıdır:

• Hangi sorgu kümelerinde görünüyorlar?
• Ana kategoriyle aynı sorguları mı paylaşıyorlar?
• Doğru landing page olarak mı gösteriliyorlar?
• Ürün keşfine ve gelire katkı sağlıyorlar mı?
• Stok değiştiğinde performans sürekli kayboluyor mu?

E-ticaret SEO sisteminin tamamında olduğu gibi burada da görünürlük, crawling, index ve ticari sonuçlar ayrı katmanlar olarak ölçülmelidir.

Hırdavat kategorisi üzerinden örnek karar

Anonimleştirilmiş ve rakamları örnek amaçlı sadeleştirilmiş bir hırdavat kataloğu düşünelim.

Ana kategori:

/akulu-matkaplar/

Sistemde şu filtreler bulunuyor:

• marka: Bosch, Makita, Dewalt, Einhell,
• voltaj: 12 V, 18 V, 20 V, 36 V,
• motor: kömürlü, kömürsüz,
• stok: stokta, tükendi,
• sıralama: fiyat artan, fiyat azalan, yeni ürün.

Aday 1: Kömürsüz akülü matkaplar

Ayrı search demand bulunuyor, kullanıcı motor teknolojisine göre seçim yapıyor, yeterli ürün derinliği var ve ürün kümesi sürdürülebilir.

Karar: Ayrı organik owner değerlendirilebilir.

/akulu-matkaplar/komursuz/

Sayfa self-canonical olur, ilgili kategori ve rehberlerden iç bağlantı alır, sitemap’e girer.

Aday 2: Bosch 18 V kömürsüz akülü matkaplar

Sorgu üretilebilse de ürün sayısı sık değişiyor ve ana marka/facet sayfalarıyla ciddi biçimde örtüşüyor.

Karar: Önce demand, SERP ayrışması ve ürün sürekliliği doğrulanır. Kanıt yetersizse yalnız UX filtresi olarak tutulur.

Aday 3: Stokta bulunan ürünler

Stok durumu kullanıcı için önemlidir fakat geçici bir katalog özelliğidir. Ayrı, kalıcı bir arama ihtiyacının owner’ı değildir.

Karar: UX filtresi. Organik landing page olarak desteklenmez.

Aday 4: Fiyata göre artan

Ürün kümesi değişmez, yalnız sıralama değişir.

Karar: Ayrı indexable sayfa değildir. Temiz kategori URL’si canonical olur; sıralama URL’lerinin iç bağlantılarla sınırsız çoğalması önlenir.

Aday 5: Sonuç üretmeyen kombinasyon

?min_fiyat=5000&max_fiyat=1000&motor=komursuz

Karar: Arayüz mümkünse bu kombinasyonu seçtirmez. URL istenirse gerçek 404 döner.

Bu örnekte SEO kararı filtre adından değil, facet’in temsil ettiği kullanıcı ihtiyacından ve katalog gerçekliğinden çıkıyor.

Kategori ownership’i, ürün kataloğu ve internal linking ilişkilerinin gerçek bir projedeki daha geniş uygulamasını 11 bin ürünlü anonim hırdavat e-ticaret SEO vaka analizinde inceleyebilirsiniz.

Faceted navigation karar ağacı

FİLTRE VEYA FİLTRE KOMBİNASYONU
                 ↓
       BAĞIMSIZ SEARCH DEMAND VAR MI?
          ├── HAYIR → UX / CRAWL SINIFI
          └── EVET
                 ↓
       AYRI KULLANICI İHTİYACI VAR MI?
          ├── HAYIR → MEVCUT OWNER İÇİNDE TUT
          └── EVET
                 ↓
       SERP AYRI LANDING PAGE DESTEKLİYOR MU?
          ├── HAYIR → SAYFA TÜRÜNÜ YENİDEN DEĞERLENDİR
          └── EVET
                 ↓
       ÜRÜN DERİNLİĞİ VE SÜREKLİLİK YETERLİ Mİ?
          ├── HAYIR → UX FİLTRESİ OLARAK TUT
          └── EVET
                 ↓
       AYRI SAYFA DEĞERİ ÜRETİLEBİLİR Mİ?
          ├── HAYIR → YENİ OWNER AÇMA
          └── EVET
                 ↓
       MEVCUT URL İLE ÇAKIŞIYOR MU?
          ├── EVET → BİRLEŞTİR / OWNER'I NETLEŞTİR
          └── HAYIR → ORGANİK FACET OWNER

Filtre motoru için SEO politika katmanı nasıl kurulabilir?

Kararların yalnız audit dokümanında kalması yeterli değildir. Büyük kataloglarda filtre motorunun hangi URL’yi üreteceğini, linkleyeceğini, indekslenebilir yapacağını veya reddedeceğini belirleyen bir politika katmanı gerekir.

Bu politika kod tabanında, CMS alanlarında veya ayrı bir kural tablosunda tutulabilir. Önemli olan kararın her URL isteğinde tutarlı biçimde uygulanmasıdır.

Politika alanı	Açıkladığı karar	Örnek değer
facet_name	Kuralın uygulandığı ürün niteliği	motor_tipi
seo_mode	URL’nin organik owner, UX filtresi veya crawl trap sınıfı	indexable_owner
allowed_values	Organik landing page üretmesine izin verilen değerler	komursuz
max_selected_values	Aynı facet içinde kabul edilen seçim derinliği	1
canonical_rule	Self, temiz kategori veya başka temsilci URL kararı	self
robots_rule	Index veya noindex davranışı	index
crawl_policy	Crawler erişiminin açık, sınırlı veya engelli olup olmayacağı	allowed
empty_result_status	Ürün bulunmayan kombinasyonun HTTP cevabı	404
internal_link	Sitenin bu URL’ye taranabilir bağlantı verip vermeyeceği	allowed
sitemap	URL’nin XML sitemap’e dahil edilip edilmeyeceği	included

Organik owner olacak bir facet’in kavramsal politikası şöyle görünebilir:

motor_tipi:
  seo_mode: indexable_owner
  allowed_values: [komursuz]
  max_selected_values: 1
  canonical_rule: self
  robots_rule: index
  crawl_policy: allowed
  empty_result_status: 404
  internal_link: allowed
  sitemap: included

Yalnız kullanıcı deneyimine hizmet eden fiyat filtresi ise farklı davranır:

fiyat:
  seo_mode: ux_only
  canonical_rule: none
  robots_rule: noindex_during_deindex_transition
  crawl_policy: evaluate_after_deindex
  internal_link: restricted
  sitemap: excluded

Bu örnek belirli bir yazılım diline ait hazır konfigürasyon değildir. Ama SEO kararını geliştiricinin uygulayabileceği açık sistem kurallarına çevirir.

Whitelist neden daha güvenli bir başlangıçtır?

Filtre motorunun bütün kombinasyonları varsayılan olarak indexable üretip sonradan binlerce istisnayı engellemesi yerine, organik değeri doğrulanmış sınırlı kombinasyonları whitelist’e almak daha yönetilebilir olabilir.

Varsayılan filtre davranışı: UX only
             ↓
Demand + SERP + ürün sürekliliği doğrulandı mı?
             ↓
Evet → Indexable owner whitelist

Böylece yeni bir marka, renk veya teknik özellik kataloğa eklendiğinde kendiliğinden yeni bir SEO landing page oluşmaz. Önce page ownership kararı verilir, ardından politika tablosu güncellenir.

Uygulama sırası nasıl olmalı?

1. URL envanterini çıkarın: Filtre, sıralama, pagination, arama ve tracking parametrelerini ayırın.
2. Mevcut indeks durumunu ölçün: Hangi parametre URL’lerinin Google tarafından keşfedildiğini ve gösterildiğini belirleyin.
3. Search demand adaylarını çıkarın: Organik owner olabilecek facet’leri ayrı listeleyin.
4. Ürün ve stok sürekliliğini kontrol edin: Kısa ömürlü kombinasyonları eleyin.
5. Üç URL sınıfını atayın: Organik owner, UX filtresi veya crawl trap.
6. Teknik sinyali amaca göre seçin: Index, crawl, canonical ve HTTP durumunu ayrı kararlar olarak belirleyin.
7. URL üretimini sınırlandırın: Tekrarlı parametreleri, anlamsız sıraları ve boş kombinasyonları uygulama seviyesinde önleyin.
8. Internal linking’i düzenleyin: Seçilmiş owner’lara link verin; düşük değerli URL’lerin keşif yollarını azaltın.
9. Pagination ve JavaScript davranışını test edin: Ürünlerin gerçek bağlantılarla bulunabildiğini doğrulayın.
10. Değişikliği aşamalı yayınlayın: Özellikle büyük URL kümelerinde indeks kaldırma ve crawl engelini aynı anda uygulamadan önce geçiş planı kurun.
11. GSC ve loglarla izleyin: Googlebot isteklerinin ve canonical seçimlerinin beklenen URL sınıflarına kayıp kaymadığını kontrol edin.

Yaygın faceted navigation SEO hataları

• Her filtre kombinasyonunu indexable yapmak.
• Bütün filtreleri hiçbir demand analizi yapmadan engellemek.
• Canonical etiketini crawl engeli sanmak.
• robots.txt ile engellenen sayfadaki noindex kuralının okunmasını beklemek.
• Bütün paginated sayfaları ilk sayfaya canonical’lamak.
• Boş sonuç sayfalarında 200 OK döndürmek.
• Sonuçsuz bütün URL’leri ana kategoriye yönlendirmek.
• Aynı filtre setini farklı parametre sıralarıyla üretmek.
• Tracking ve session parametrelerini iç bağlantılara taşımak.
• Organik owner yapılan facet’e iç bağlantı vermemek.
• Yalnız arama hacmine bakıp ürün sürekliliğini yok saymak.
• Ürün sayısı için bütün sektörlere aynı sabit eşiği uygulamak.
• Filtre sistemini yalnız crawler çıktısıyla denetleyip GSC ve log verisini dışarıda bırakmak.

Faceted navigation nasıl yönetilmeli?

Faceted navigation için tek bir evrensel teknik etiket yoktur. Çünkü aynı filtre sistemi içinde farklı görevler taşıyan URL’ler bulunur.

Doğru model şudur:

Bağımsız kullanıcı ihtiyacı ve sürdürülebilir ürün değeri taşıyan seçilmiş facet’ler organik owner yapılır; yalnız kullanıcı deneyimine hizmet eden filtreler index sisteminin dışında tutulur; boş, tekrarlı ve anlamsız kombinasyonların ise mümkün olduğunca üretilmesi ve taranması önlenir.

Bu yaklaşım, “hepsini indexle” ile “hepsini kapat” arasında orta yol bulmak değildir. Her URL sınıfına kendi görevine uygun teknik ve mimari karar vermektir.

Teknik SEO, site mimarisi ve içeriği birlikte planlamak gerektiği gibi, faceted navigation da yalnız robots veya canonical düzenlemesi olarak ele alınamaz. Ürün taksonomisi değiştiğinde facet adayları değişir; stok yapısı değiştiğinde sayfa değeri değişir; internal linking değiştiğinde crawler’ın keşif yolları değişir.

İyi çalışan filtre sistemi, kullanıcıya kataloğu daraltma özgürlüğü verirken arama motoruna sınırsız ve kontrolsüz bir URL alanı bırakmaz.

Kaynaklar ve teknik referanslar

1. Google Crawling Infrastructure — Managing crawling of faceted navigation URLs
2. Google Search Central — Introduction to robots.txt
3. Google Search Central — Block Search indexing with noindex
4. Google Search Central — How to specify a canonical URL
5. Google Search Central — Designing a URL structure for ecommerce websites
6. Google Search Central — Pagination and incremental page loading
7. Google Search Central — Help Google understand your ecommerce site structure
8. Google Crawling Infrastructure — Optimize your crawl budget
9. Google Search Central — Product variant structured data
10. Google Search Central — Debugging drops in Google Search traffic