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

Bir e-ticaret kategorisine üç filtre eklediğinizi düşünün:

• renk,
• beden,
• marka.

Kullanıcı açısından oldukça masum bir arayüzdür.

Teknik tarafta ise aynı sistem şunları üretmeye başlayabilir:

/erkek-ayakkabi/?renk=siyah /erkek-ayakkabi/?beden=42 /erkek-ayakkabi/?marka=nike /erkek-ayakkabi/?renk=siyah&beden=42 /erkek-ayakkabi/?renk=siyah&marka=nike /erkek-ayakkabi/?beden=42&marka=nike /erkek-ayakkabi/?renk=siyah&beden=42&marka=nike

Buna fiyat, stok durumu, malzeme, kullanım alanı, sıralama ve pagination eklendiğinde birkaç dropdown bir anda binlerce veya milyonlarca URL durumuna dönüşebilir.

Faceted navigation SEO’sunda asıl problem bu noktada başlar.

Problem önce duplicate content veya indexation problemi değildir. Önce URL space problemidir.

Google’ın faceted navigation dokümantasyonunda da temel risk iki başlıkta tanımlanır:

• gereksiz URL’lerin aşırı taranması,
• crawler kaynaklarının bu URL’lere harcanması nedeniyle yeni ve değerli URL’lerin daha yavaş keşfedilmesi.

Çünkü crawler bir facet URL’nin yararlı olup olmadığını çoğu zaman onu görmeden ve crawl etmeden kesin biçimde bilemez.

Bu nedenle faceted navigation problemini şu sırayla düşünmek daha doğru olur:

FACET ↓ URL GENERATION ↓ CRAWL SPACE ↓ DISCOVERY ↓ CRAWLING ↓ CANONICALIZATION ↓ INDEX ELIGIBILITY ↓ RANKING

Buradaki sıra önemlidir.

SEO ekipleri çoğu zaman doğrudan:

Bu URL indexlenmesin, canonical basalım.

noktasından başlar.

Asıl teknik soru ise iki katman yukarıdadır:

Bu URL neden var ve crawler bunu neden keşfedebiliyor?

Faceted navigation nedir?

Faceted navigation veya filtreli/yönlü gezinme, kullanıcının bir ürün veya içerik listesini belirli niteliklere göre daraltmasını sağlayan navigasyon sistemidir.

E-ticarette yaygın facet örnekleri:

• marka,
• renk,
• beden,
• voltaj,
• malzeme,
• motor tipi,
• kapasite,
• uyumluluk,
• stok durumu,
• fiyat aralığı.

Örneğin:

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

kullanıcı açısından yalnız ürün listesini daraltma işlemidir.

Fakat altyapı her seçimi URL’ye yazıyorsa:

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

crawler açısından yeni URL adayları oluşur.

Facet bu nedenle otomatik olarak kategori veya SEO landing page değildir.

Yapı	Ana görevi
Kategori	Kalıcı bir ürün grubunun page owner’ı olmak
Facet	Mevcut ürün kümesini belirli niteliğe göre daraltmak
Sıralama	Aynı ürünleri farklı sırada göstermek
Pagination	Listenin devamındaki ürünlere erişmek
Site içi arama	Kullanıcının serbest sorgusuna sonuç üretmek

Bunların hepsi query parameter kullanabilir.

Aynı teknik formatta görünmeleri aynı SEO politikasına sahip olmaları gerektiği anlamına gelmez.

Faceted navigation problemi neden önce crawl-space problemidir?

Bir kategoride:

• 12 marka,
• 8 teknik özellik,
• 5 renk,
• 4 ürün tipi,
• 3 stok durumu

olduğunu düşünelim.

Yalnızca basit tekli kombinasyon mantığında bile:

12 × 8 × 5 × 4 × 3 = 5.760 kombinasyon

oluşabilir.

Birden fazla marka veya teknik özellik aynı anda seçilebiliyorsa, parametre sıraları değişebiliyorsa ve filtrelere pagination ile sorting ekleniyorsa olası URL sayısı çok daha hızlı büyür.

Örneğin aynı sonuç kümesi şu farklı URL’lerden erişilebilir olabilir:

?marka=bosch&voltaj=18v ?voltaj=18v&marka=bosch ?marka=bosch&voltaj=18v&sort=price_asc ?marka=bosch&voltaj=18v&utm_source=email

Kullanıcı aynı veya çok benzer ürünleri görür.

Crawler ise bunları ayrı URL olarak keşfedebilir.

Google bu problemi özellikle overcrawling üzerinden açıklıyor: faceted navigation URL’leri crawler’a yeni URL’ler gibi görünebilir ve crawler bunların faydasız olduğunu anlamadan önce çok sayıda kombinasyona erişebilir.

Sonuç:

MORE FACET STATES ↓ MORE DISCOVERABLE URLS ↓ MORE CRAWL REQUESTS ↓ MORE SERVER / RENDERING COST ↓ LESS ATTENTION FOR USEFUL URLS ↓ SLOWER DISCOVERY

Dolayısıyla faceted navigation teknik SEO’su yalnız:

Google hangisini indexledi?

sorusuyla başlamamalıdır.

Önce:

Googlebot hangi URL alanına maruz kalıyor?

sorusunu sormak gerekir.

Her faceted navigation problemi crawl budget problemi midir?

Hayır.

Küçük bir sitede 20 filtre URL’sinin crawl edilmesi büyük bir operasyonel kriz yaratmayabilir.

“Crawl budget” terimini gördüğümüz her parametreli URL’ye yapıştırmak problemi olduğundan büyük gösterebilir.

Ancak katalog büyüdükçe:

• ürün sayısı,
• kategori sayısı,
• facet sayısı,
• facet kombinasyonları,
• pagination,
• sorting,
• varyantlar

birbirini çarpmaya başladığında URL space gerçek bir crawler yönetimi problemine dönüşebilir.

Burada asıl hedef yalnız “crawl budget optimize etmek” değildir.

Hedef:

Crawler’ın keşfedebildiği URL uzayını sitenin gerçek search value üreten URL’lerine mümkün olduğunca yaklaştırmak.

Facet URL otomatik olarak kötü URL değildir

Faceted navigation SEO’sunda iki aşırı yaklaşım vardır:

Bütün filtreleri indexle.

ve:

Bütün filtreleri kapat.

İkisi de yanlıştır.

Bazı facet kombinasyonları gerçek bir kullanıcı ihtiyacını ve ayrı search demand’i temsil edebilir.

Örneğin:

/kadin-elbise/siyah/

gerçek bir ticari arama ihtiyacını karşılayabilir.

Ama:

/kadin-elbise/siyah/?stok=var&sort=fiyat_artan&page=3

aynı seviyede ayrı bir SEO landing page değildir.

Bu nedenle faceted navigation kararı şu soruya indirgenmemelidir:

Filtre URL’si indexlensin mi?

Daha doğru soru:

Bu filtrelenmiş ürün kümesi bağımsız bir kullanıcı ihtiyacının page owner’ı olmayı hak ediyor mu?

Bu karar, e-ticaret kategori mimarisinde kategori, alt kategori, facet ve no-URL ayrımını yaptığımız daha geniş search architecture kararının teknik devamıdır.

Facet ile SEO landing page arasındaki fark nedir?

Facet bir interface primitive olarak düşünülebilir.

Kullanıcının ürünleri daraltmasını sağlar.

SEO landing page ise arama talebinde ayrı bir kullanıcı ihtiyacını temsil eden document veya listing owner’dır.

FACET = UX SELECTION STATE SEO LANDING PAGE = SEARCH NEED OWNER

Bazen aynı şey olabilirler.

Örneğin:

Akülü Matkaplar ↓ Kömürsüz

seçimi hem UX filtresi hem de “kömürsüz akülü matkap” ihtiyacının organik owner’ı olabilir.

Ama:

Stokta Olanlar ↓ Fiyata Göre Artan ↓ 5000–7500 TL ↓ Sayfa 4

gibi durumlar kullanıcı arayüzünde faydalı olabilirken ayrı search document’ları olmayı hak etmeyebilir.

Hangi facet SEO landing page olabilir?

Bir facet’i indexable owner yapmadan önce yalnız keyword volume’a bakmak yeterli değildir.

Ben kararı şu kapılardan geçiririm:

FACET COMBINATION ↓ GERÇEK USER NEED? ↓ SEARCH DEMAND? ↓ DISTINCT PRODUCT SET? ↓ STABLE ATTRIBUTE? ↓ SUSTAINABLE INVENTORY? ↓ SEPARATE PAGE VALUE? ↓ EXISTING OWNER İLE ÇAKIŞIYOR MU? / \ HAYIR EVET | | SEO LP NO NEW OWNER

1. Gerçek kullanıcı ihtiyacı var mı?

Ürün verisinde bir attribute bulunması kullanıcının bu attribute üzerinden ürün aradığı anlamına gelmez.

Örneğin veri tabanında:

depo_raf_kodu = A14

alanı bulunabilir.

Bunun URL üretebilmesi ayrı bir SEO sayfası olması gerektiği anlamına gelmez.

2. Search demand var mı?

Talep şu kaynaklardan anlaşılabilir:

• Search Console,
• keyword verisi,
• SERP yapısı,
• site içi arama,
• filter usage,
• sales ve customer questions.

Fakat search volume tek başına owner üretmez.

3. Distinct product set oluşuyor mu?

Yeni facet sayfası ana kategoriden anlamlı biçimde farklı bir ürün kümesi göstermelidir.

Örneğin:

/akulu-matkaplar/ 300 ürün /akulu-matkaplar/komursuz/ 95 ürün

anlamlı bir refinement olabilir.

Ama yeni URL 300 ürünün 295’ini tekrar gösteriyorsa ayrı page role daha dikkatli sorgulanmalıdır.

4. Attribute stabil mi?

Şunlar daha stabil olabilir:

• marka,
• ürün tipi,
• renk,
• malzeme,
• voltaj,
• teknik standart.

Şunlar daha geçici olabilir:

• stokta,
• bugün indirimde,
• aynı gün kargo,
• son 3 ürün,
• kampanya etiketi.

Geçici operational state üzerine kalıcı organic architecture kurmak kırılgan olabilir.

5. Ürün seti sürdürülebilir mi?

Bugün 30 ürün gösteren filtre gelecek ay sıfıra düşüyorsa kalıcı landing page üretmek risklidir.

Sabit “minimum 10 ürün” gibi evrensel eşik de yoktur.

Ürün derinliği sektör, fiyat, katalog yapısı ve kullanıcı göreviyle birlikte değerlendirilmelidir.

6. Sayfa bağımsız değer üretebilir mi?

Indexable facet yalnız filtrelenmiş ürün grid’i olmak zorunda değildir.

Ancak ana kategoriden farklı kullanıcı görevini gerçekten desteklemelidir.

Örneğin:

• ilgili selection criteria,
• teknik attribute açıklaması,
• ürün kartlarında ilgili özelliklerin öne çıkarılması,
• uyumluluk bilgisi,
• ilgili seçim rehberleri

sayfanın farklı görevini güçlendirebilir.

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

Zaten:

/komursuz-akulu-matkaplar/

şeklinde kategori owner varsa:

/akulu-matkaplar/?motor=komursuz

ikinci bir owner yaratmamalıdır.

Burada sorun yalnız “cannibalization” kelimesi değildir.

Asıl problem aynı information need için iki farklı URL’nin site mimarisi tarafından aday gösterilmesidir.

Bu page ownership mantığını SEO stratejisinde kullanıcı ihtiyacı → page role → URL ownership ilişkisi içinde daha geniş biçimde ele alıyorum.

Canonical faceted navigation crawl problemini çözer mi?

Hayır.

Bu faceted navigation SEO’sundaki en kritik ayrımlardan biridir.

Şöyle bir yapı düşünelim:

/category/?color=red&size=m rel="canonical" ↓ /category/

Canonical etiketi Google’a hangi URL’yi temsilci olarak tercih ettiğimizi bildiren güçlü canonicalization sinyallerinden biridir.

Ancak canonical:

Bu URL hiç var olmasın.

veya:

Bu URL hiç crawl edilmesin.

demez.

Google faceted navigation dokümantasyonunda canonical kullanımının non-canonical varyasyonların crawl hacmini zaman içinde azaltabileceğini, fakat crawl kontrolü için robots.txt veya URL üretim yaklaşımı kadar etkili olmadığını belirtiyor.

Yani:

DISCOVERY ↓ CRAWL ↓ CANONICAL PROCESSING ↓ INDEXING

zincirinde canonical daha aşağıdaki bir problemi etkiler.

URL’nin üretilmesini veya keşfedilmesini otomatik olarak engellemez.

Canonicalization’ın ne olduğunu ve Google’ın canonical URL seçerken hangi sinyalleri kullandığını Canonical Nedir? yazısında ayrı olarak ele alıyorum.

Canonical ile crawl control arasındaki fark

Mekanizma	Ana görevi
rel=”canonical”	Tercih edilen temsilci URL için canonicalization sinyali vermek
robots.txt	Crawler’ın belirli URL pattern’lerini crawl etmesini engellemek
noindex	Crawl edilebilen URL’nin Search indexinde görünmemesini istemek
URL generation rule	Gereksiz URL state’in baştan üretilmesini engellemek
Internal linking	Crawler’ın hangi URL’leri kolayca keşfettiğini şekillendirmek
404	İstenen state’in gerçekten mevcut olmadığını belirtmek

Bu araçlardan biri diğerinin yerine geçmez.

Örneğin:

robots.txt + noindex

kombinasyonunu düşünmeden kullanmak da sorun yaratabilir.

Crawler robots.txt nedeniyle sayfayı fetch edemiyorsa sayfanın içindeki noindex directive’ini göremeyebilir.

Bu nedenle faceted navigation politikası “birkaç SEO etiketi basalım” yaklaşımıyla değil, URL sınıfları üzerinden tasarlanmalıdır.

robots.txt faceted navigation için kullanılmalı mı?

Eğer belirli facet URL’lerinin Google tarafından Search’te görünmesini istemiyor ve crawling için de bir değer görmüyorsanız robots.txt güçlü crawl-control seçeneklerinden biridir.

Google’ın kendi örneğinde:

User-agent: Googlebot Disallow: /*?*products= Disallow: /*?*color= Disallow: /*?*size=

gibi parametre aileleri engellenebilir.

Ancak robots.txt politikası siteye özgü olmalıdır.

Örneğin bütün:

?brand=

URL’lerini block etmek mantıklı olmayabilir; eğer bazı brand × category facet’leri gerçekten organik owner olacaksa bunların taranabilir olması gerekir.

Dolayısıyla:

PARAMETER EXISTS ≠ BLOCK PARAMETER

Daha doğru model:

URL CLASS ↓ SEO ROLE ↓ CRAWL POLICY

URL fragment kullanmak çözüm olabilir mi?

Google Search URL fragment’lerini genel olarak crawling ve indexing için ayrı URL state’leri olarak kullanmaz.

Bu nedenle UX filtrelerinin:

/category/#color=red

gibi fragment tabanlı çalışması bazı yapılarda crawler’a yeni faceted URL alanı açmadan kullanıcı state’i üretmenin yollarından biri olabilir.

Ancak bu bir e-ticaret sitesine otomatik olarak uygulanacak evrensel reçete değildir.

Frontend mimarisi, paylaşılabilir URL gereksinimi, analytics, state management ve organik owner olacak facet’lerin ihtiyaçları birlikte değerlendirilmelidir.

nofollow faceted navigation crawling’ini çözer mi?

Tek başına güvenilir ana politika olarak düşünmem.

Google faceted navigation dokümanı, filter URL’lerine giden linklerde rel="nofollow" kullanımının yardımcı olabileceğini; ancak etkili olabilmesi için aynı URL’ye giden bütün bağlantıların tutarlı biçimde nofollow olması gerektiğini belirtiyor.

Bu pratikte özellikle büyük sitelerde zor olabilir.

URL başka bir:

• kategori,
• navigation component,
• XML dışı feed,
• harici site

üzerinden tekrar keşfedilebilir.

Dolayısıyla nofollow’u URL-generation probleminin ana çözümü olarak konumlandırmak doğru değildir.

noindex faceted navigation için yeterli midir?

Noindex indexation problemini hedefler.

Crawl-space problemini değil.

Bir filtre URL’sinin:

<meta name="robots" content="noindex">

taşıması Google’ın bu directive’i görebilmesi için URL’yi crawl etmesini gerektirir.

Büyük hacimli faceted URL alanında:

crawl ↓ discover noindex ↓ don't index

döngüsü hâlâ server ve crawl kaynağı tüketebilir.

Bu nedenle:

Bütün filtrelere noindex koyduk, faceted navigation çözüldü.

yaklaşımı eksiktir.

Geçersiz ve zero-result facet kombinasyonları nasıl davranmalı?

Faceted navigation sisteminde URL space’in sınırlarını belirleyen en önemli mühendislik kararlarından biri budur.

Şöyle bir URL düşünelim:

/elbise/?renk=mor&beden=XXXXXXL&malzeme=metal

Sistemde bu kombinasyonu karşılayan hiçbir ürün bulunmuyorsa URL’nin sonsuza kadar:

200 OK 0 ürün bulundu

olarak yaşaması şart değildir.

Google, sonuç üretmeyen facet kombinasyonlarının doğru HTTP 404 status code ile cevap vermesini öneriyor.

Aynı mantık:

• duplicate filters,
• mantıksız kombinasyonlar,
• geçersiz parameter state’leri,
• var olmayan pagination URL’leri

için de geçerlidir.

Örneğin:

/category?page=999999

gerçek bir state değilse:

HTTP 404

vermesi URL space’in gerçek sınırını crawler’a daha açık biçimde gösterir.

Buradaki temel sistem prensibi:

VALID STATE → 200 INVALID STATE → 404

olmalıdır.

Şunun yerine:

EVERY POSSIBLE STRING → 200

değil.

Zero-result sayfalar neden ortak 404 sayfasına redirect edilmemeli?

Google, sonuç üretmeyen facet URL’sini ortak bir “not found” URL’sine redirect etmek yerine hatayı karşılaşılan URL üzerinde gerçek 404 response ile sunmayı öneriyor.

Örneğin:

/akulu-matkaplar/?voltaj=999v ↓ HTTP 404

şeklindeki davranış:

/akulu-matkaplar/?voltaj=999v ↓ 302 /not-found/

gibi ortak redirect zincirinden daha açık bir state modelidir.

Filter parametre sırası neden önemli?

Aynı state farklı parameter order ile üretilebiliyorsa gereksiz URL varyasyonları oluşabilir:

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

İki URL aynı ürün kümesini gösteriyorsa uygulama bunları mümkün olduğunca tek normalize edilmiş URL formatına indirmelidir.

Path tabanlı filtrelerde de aynı mantık geçerlidir:

/products/bosch/18v/ vs. /products/18v/bosch/

Google’ın güncel dokümanı path içine encode edilen filtrelerde logical order’ın tutarlı tutulmasını ve duplicate filters oluşmamasını özellikle öneriyor.

Burada amaç estetik URL değildir.

Amaç:

Aynı state’in mümkün olduğunca tek URL temsiline sahip olmasıdır.

Sıralama URL’leri nasıl ele alınmalı?

Sorting çoğunlukla yeni ürün kümesi oluşturmaz.

Aynı ürünleri farklı sıraya dizer:

?sort=price_asc ?sort=price_desc ?sort=popular ?sort=newest

Bu nedenle sorting state’leri genellikle bağımsız organic owner değildir.

Burada ayrı search landing page üretmek yerine:

• gereksiz crawl keşfini azaltmak,
• canonical politikasını tutarlı tutmak,
• sitemap’e almamak,
• internal link graph’ta owner gibi güçlendirmemek

daha anlamlı olabilir.

Stok filtresi ayrı SEO landing page olmalı mı?

Çoğu durumda:

?stok=var

kullanıcı deneyimi state’idir.

Çünkü stok sürekli değişir.

Bugün ürün kümesinde 100 ürün olabilir, yarın 7 ürün kalabilir.

Bu nedenle “stokta olan siyah kadın elbiseleri” şeklinde arama görüyor olsak bile bunun gerçekten kalıcı page owner gerektirip gerektirmediğini ayrıca değerlendirmek gerekir.

Search query içinde kelime bulunması otomatik olarak ayrı URL requirement yaratmaz.

Faceted navigation ile kategori mimarisi aynı problem değildir

İki alan birbirine bağlıdır ama rolleri farklıdır.

CATEGORY ARCHITECTURE = Hangi ürün kümesi hangi page role tarafından temsil edilmeli? FACETED NAVIGATION = Kullanıcı ürün kümesini hangi boyutlarda daraltabilmeli ve oluşan URL state'leri nasıl yönetilmeli?

Örneğin:

Elektrikli El Aletleri ↓ Matkaplar ↓ Akülü Matkaplar

kalıcı taxonomy olabilir.

Bunun içinde:

Marka Voltaj Motor tipi Mandren Fiyat Stok

facet olarak çalışabilir.

Facet’lerden bazılarının search demand nedeniyle organic owner’a yükselmesi mümkündür.

Ama filtre motorundaki bütün değerlerin kategori ağacına çevrilmesi gerekmez.

Bu ayrımı e-ticaret kategori mimarisinde product taxonomy ile search architecture arasındaki fark üzerinden daha ayrıntılı ele alıyorum.

Faceted navigation daha geniş e-ticaret SEO sisteminde nereye oturur?

E-ticaret SEO’yu yalnız category title ve product description optimizasyonu olarak görürsek faceted navigation kolayca “parameter problemi” gibi görünür.

Aslında daha geniş sistem şudur:

E-COMMERCE PLATFORM ↓ URL GENERATION RULES ↓ SITE ARCHITECTURE ↓ INTERNAL LINKING ↓ DISCOVERY ↓ CRAWLING ↓ RENDERING ↓ CANONICALIZATION ↓ INDEXATION ↓ RETRIEVAL / RANKING

Faceted navigation özellikle ilk beş katmanı etkiler.

Bu nedenle e-ticaret SEO’yu URL temsilinden crawling ve arama yüzeylerine kadar bir sistem olarak ele aldığım ana rehberde filtre URL’lerini tek başına ayrı bir SEO taktiği olarak konumlandırmıyorum.

Technical SEO neden URL üretiminden başlamalı?

Faceted navigation bize daha geniş bir teknik SEO prensibi gösterir.

Şu sorunların tamamı benzer bir temel soruya sahiptir:

• facets,
• pagination,
• sorting,
• internal search,
• tracking parameters,
• session parameters,
• product variants,
• duplicate category paths.

Hepsinde önce şu sorular sorulmalıdır:

Bu URL nasıl oluşuyor? ↓ Kaç farklı state üretebilir? ↓ Crawler bunu nasıl keşfediyor? ↓ Crawler'ın bunu görmesi gerekiyor mu? ↓ Bu state ayrı index adayı mı? ↓ Canonical owner hangisi?

Bu nedenle teknik SEO audit’inde doğrudan:

Canonical doğru mu?

sorusuna atlamak bazen semptom seviyesinde çalışmak olur.

Daha erken soru:

Bu canonical’a neden ihtiyaç duyduk? Aynı state neden birden fazla URL’den üretilebiliyor?

olmalıdır.

Faceted navigation için URL sınıfları nasıl oluşturulmalı?

Ben pratikte en az dört sınıf kullanırım.

URL sınıfı	Örnek	SEO rolü
Organic facet owner	/akulu-matkaplar/komursuz/	Indexable landing page
UX-only facet	?stok=var	Kullanıcı filtresi
Sorting / presentation state	?sort=price_asc	Yeni owner değil
Invalid / crawl-trap state	?page=999999	Üretilmemeli veya gerçek 404

Buna göre teknik politika değişir.

URL tipi	Crawl	Index	Canonical	Sitemap
Organic owner	Evet	Evet	Self-referencing	Evet
UX-only facet	İhtiyaca göre kontrol	Genellikle hayır	Tek başına çözüm değil	Hayır
Sorting state	Genellikle azaltılmalı	Hayır	Ana listing owner’a	Hayır
Invalid state	Keşfi azaltılmalı	Hayır	Gerekmez	Hayır

Buradaki tablo mutlak reçete değildir.

Site altyapısı, mevcut index durumu ve kullanıcı gereksinimleri ayrıca değerlendirilmelidir.

Organik facet owner nasıl uygulanmalı?

Bir facet gerçekten ayrı organic owner olacaksa onu yarım ağızla indexable bırakmak yeterli değildir.

Örneğin:

/akulu-matkaplar/komursuz/

sayfası gerçekten “kömürsüz akülü matkaplar” ihtiyacının owner’ı ise:

• 200 status vermeli,
• crawl edilebilir olmalı,
• self-referencing canonical kullanmalı,
• XML sitemap’e girebilmeli,
• ilgili kategori ve içeriklerden internal link almalı,
• query intent’e uygun ürün seti göstermeli,
• ana kategoriyle page role ayrımı net olmalı.

URL’nin temiz path mi parametre mi olduğu ikinci seviyedeki karardır.

Asıl mesele URL’nin tek ve tutarlı owner olarak yönetilmesidir.

Internal linking faceted navigation’ı nasıl etkiler?

URL’nin üretilmesi tek başına crawler’ın onu bulacağı anlamına gelmeyebilir.

Asıl önemli katmanlardan biri discovery’dir.

Örneğin her kategori sayfasında yüzlerce facet seçeneği crawlable <a href> bağlantısı olarak sunuluyorsa crawler bütün kombinasyonlara güçlü keşif yolları elde eder.

Bu yüzden:

URL GENERATION + INTERNAL LINKING = DISCOVERABLE URL SPACE

şeklinde düşünmek faydalıdır.

Organic owner facet’lerin kontrollü internal link alması mantıklıdır.

Her UX filtresinin site genelinde bağımsız landing page gibi linklenmesi ise crawler’ın URL alanını genişletebilir.

Internal linking’in crawler discovery ve architecture açısından rolünü SEO stratejisinin mimari uygulama katmanında ayrıca ele alıyorum.

Faceted navigation nasıl audit edilir?

Filtre audit’i yalnız Screaming Frog crawl’ı değildir.

En az dört farklı veri katmanı birlikte kullanılmalıdır:

APPLICATION URL üretim kuralları + CRAWLER Site içi keşfedilebilir URL'ler + GOOGLE DATA Search Console + SERVER DATA Log files

1. Parametre envanterini çıkarın

Önce URL’lerde hangi state ailelerinin bulunduğunu belirleyin:

• filter,
• sorting,
• pagination,
• tracking,
• site search,
• session,
• product variant.

Parametreleri yalnız adına göre değil, davranışına göre sınıflandırın.

2. URL üretim kurallarını anlayın

Şunları test edin:

• parametre sırası değişebiliyor mu?
• aynı filtre birden fazla kez eklenebiliyor mu?
• aynı ürün kümesi farklı URL’lerden açılıyor mu?
• geçersiz değerler 200 üretiyor mu?
• boş kombinasyonlar sonsuza kadar açılabiliyor mu?
• pagination’ın üst sınırı var mı?

3. Crawlable link graph’ı inceleyin

Hangi facet URL’leri gerçek HTML linkleriyle keşfedilebiliyor?

Özellikle kategori templates üzerinde:

• filter links,
• pagination,
• sort links,
• related category modules

kontrol edilmelidir.

4. Search Console’da URL pattern’lerini inceleyin

Şunları araştırın:

• parametreli URL’ler impression üretiyor mu?
• Google beklenmeyen facet URL’lerini canonical seçiyor mu?
• duplicate veya crawled-not-indexed pattern’leri var mı?
• hangi facet query’leri gerçek demand gösteriyor?

5. Server loglarını inceleyin

Büyük kataloglarda en önemli veri kaynaklarından biridir.

Loglar şunu gösterir:

Googlebot gerçekte hangi URL’leri istiyor?

Örneğin crawl request’lerinin büyük bölümü:

?sort= ?stock= ?page= ?brand= ?price=

kombinasyonlarında yoğunlaşıyorsa crawler allocation problemi doğrudan görülebilir.

6. Search demand ile crawl maliyetini birlikte değerlendirin

Facet URL decision matrix şöyle kurulabilir:

Search Value	Crawl Cost	Muhtemel karar
Yüksek	Makul	Organic owner
Düşük	Yüksek	Güçlü crawl control
Düşük	Düşük	UX-only / düşük öncelik
Yüksek	Yüksek	Seçilmiş owner URL’leri whitelist et

Whitelist yaklaşımı neden faydalıdır?

Büyük e-ticaret kataloglarında varsayılan politikayı:

Her facet crawlable ve indexable, sonra sorunlu olanları tek tek kapatırız.

şeklinde kurmak risklidir.

Çünkü olası URL alanı çok büyük olabilir.

Bunun yerine bazı sistemlerde daha kontrollü model:

DEFAULT UX-ONLY ↓ VALIDATED SEARCH DEMAND + STABLE PRODUCT SET + CLEAR PAGE ROLE ↓ PROMOTE TO ORGANIC OWNER

olabilir.

Yani SEO landing page’ler facet motorunun doğal yan ürünü değil, bilinçli olarak onaylanan URL sınıfı olur.

Bu yaklaşım özellikle binlerce ürün ve onlarca attribute içeren kataloglarda daha güvenli olabilir.

11 bin ürünlü kataloglarda neden daha kritik hale gelir?

Yaklaşık 11 bin ürünlü anonim bir hırdavat e-ticaret projesinde ürün sayısının kendisi tek başına zorlayıcı değildi.

Asıl problem ürün evreninin:

• ürün tipi,
• marka,
• ölçü,
• teknik özellik,
• kullanım alanı

üzerinden çok sayıda farklı sınıflandırma ihtimali oluşturmasıydı.

Örneğin:

M8 civata ↓ Commercial product set M8 civata ölçüleri ↓ Technical information need

aynı ürün ailesine ait olsa da farklı page role gerektirebilir.

Buna bir de:

paslanmaz boy paket miktarı standart marka

facet’leri eklendiğinde ürün kataloğu kolayca çok büyük URL alanına dönüşebilir.

Bu nedenle gerçek projede kategori ownership’i ve URL üretim kuralları birlikte düşünülmelidir.

Bu yaklaşımın daha geniş uygulamasını 11 bin ürünlü anonim e-ticaret SEO vaka analizinde görebilirsiniz.

Faceted navigation’da sık yapılan hatalar

Problemi yalnız duplicate content sanmak

Duplicate content sonuçlardan biridir.

Asıl problem daha önce URL generation ve discovery katmanında başlamış olabilir.

Canonical’ı crawl-control etiketi sanmak

Canonical canonicalization sinyalidir. URL’nin hiç crawl edilmeyeceğini garanti etmez.

Her facet’i indexable yapmak

UX filtresi ile organic owner aynı şey değildir.

Bütün facet’leri bloklamak

Gerçek search demand taşıyan değerli landing page’leri de kaybedebilirsiniz.

Her search volume için URL üretmek

Search volume ayrı page role için tek başına yeterli değildir.

Sorting URL’lerini landing page gibi bırakmak

Aynı ürün kümesinin sırasını değiştirmek çoğu zaman yeni information need oluşturmaz.

Zero-result URL’leri 200 yaşatmak

Geçersiz state’lerin sınırsız URL üretmesine neden olabilir.

Pagination sınırını kontrol etmemek

?page=999999 gibi var olmayan URL’lerin 200 üretmesi URL space’i gereksiz genişletir.

Parameter order’ı normalize etmemek

Aynı state birden fazla URL’den erişilebilir hale gelir.

Facet kararını yalnız SEO ekibine bırakmak

Karar aslında:

• product taxonomy,
• development,
• UX,
• SEO,
• merchandising,
• inventory

katmanlarını birlikte etkiler.

Faceted navigation için pratik karar modeli

Ben faceted navigation politikasını şu sırayla kurarım:

1. INVENTORY Hangi facet'ler ve state'ler var? ↓ 2. URL GENERATION Hangi seçimler yeni URL oluşturuyor? ↓ 3. DISCOVERY Crawler bu URL'leri nasıl buluyor? ↓ 4. SEARCH VALUE Hangi kombinasyon gerçek demand taşıyor? ↓ 5. PAGE OWNERSHIP Hangi kombinasyon ayrı owner olmalı? ↓ 6. URL CLASSIFICATION Organic / UX / Sort / Invalid ↓ 7. CRAWL POLICY Crawler hangilerini görmeli? ↓ 8. INDEX POLICY Hangileri Search adayı? ↓ 9. CANONICALIZATION Temsilci URL hangisi? ↓ 10. MONITORING GSC + Crawl + Logs

Bu sırada özellikle:

CRAWL POLICY ↓ INDEX POLICY

ayrımını korumak gerekir.

Çünkü crawl ve index aynı problem değildir.

E-commerce Technical SEO için daha büyük model

Faceted navigation’dan çıkarılabilecek daha geniş ders şudur:

E-COMMERCE PLATFORM ↓ URL GENERATION RULES ↓ INTERNAL LINKING / DISCOVERY ↓ CRAWLER BEHAVIOR ↓ CRAWL ALLOCATION ↓ CANONICALIZATION ↓ INDEXATION ↓ RANKING

Çoğu teknik SEO kontrolü zincirin alt tarafında başlar:

Canonical ne?

Indexlenmiş mi?

Ranking alıyor mu?

Fakat büyük sitelerde daha güçlü soru çoğu zaman şudur:

Bu URL neden var?

Ardından:

Crawler bunu neden bulabiliyor?

Bu iki sorunun cevabı doğru değilse canonical ve noindex ile aşağıdan temizlik yapmaya devam edersiniz.

Sonuç: Faceted navigation SEO’su URL üretim sistemini yönetmektir

Faceted navigation problemi yalnız duplicate URL temizleme işi değildir.

Asıl problem filtre motorunun kullanıcı için yararlı state’ler üretirken crawler’a kontrolsüz bir URL uzayı açabilmesidir.

Bu nedenle doğru zihinsel model:

FACET ↓ URL GENERATION ↓ CRAWL SPACE ↓ DISCOVERY COST ↓ CRAWLING ↓ CANONICALIZATION ↓ INDEX ELIGIBILITY

şeklindedir.

Bazı facet’ler gerçek search demand ve ayrı page role taşıdığı için organic landing page olabilir.

Bazıları yalnız kullanıcı deneyimine hizmet eder.

Bazılarıysa sorting, tracking, zero-result veya mantıksız kombinasyonlar nedeniyle crawler için gereksiz URL alanı oluşturur.

Bu yüzden doğru çözüm:

Bütün filtreleri indexle.

veya:

Bütün filtreleri engelle.

değildir.

Doğru çözüm:

Her URL sınıfının search value, crawl maliyeti ve page role’una göre ayrı teknik politika belirlemektir.

Faceted navigation’ın daha geniş e-ticaret sistemi içindeki yerini e-ticaret SEO rehberinde; facet ile kategori arasındaki ownership kararını ise e-ticaret kategori mimarisi yazısında derinleştiriyorum.

Sık Sorulan Sorular

Faceted navigation nedir?

Faceted navigation, kullanıcıların ürün veya içerik listelerini marka, renk, beden, fiyat veya teknik özellik gibi niteliklere göre daraltmasını sağlayan filtreleme sistemidir.

Faceted navigation SEO için neden problem olabilir?

Filtre kombinasyonları çok büyük sayıda ayrı URL üretebilir. Bu URL’ler crawler tarafından keşfedilip tarandığında gereksiz crawl maliyeti ve yeni değerli URL’lerin daha yavaş keşfedilmesi gibi sorunlar oluşabilir.

Bütün filtre URL’leri noindex yapılmalı mı?

Hayır. Bazı filtre kombinasyonları bağımsız search demand, farklı ürün kümesi ve açık page role taşıdığı için organik landing page olabilir. Karar URL sınıfına göre verilmelidir.

Canonical filtre URL’lerinin crawl edilmesini engeller mi?

Hayır. rel=”canonical” canonicalization sinyalidir. Google non-canonical URL’leri zaman içinde daha az crawl edebilir, ancak canonical URL’nin keşfedilmesini veya crawl edilmesini doğrudan engelleyen bir crawl-control mekanizması değildir.

robots.txt faceted navigation için kullanılabilir mi?

Evet. Google, Search’te görünmesi gerekmeyen faceted navigation URL’lerinin crawling’ini azaltmak için robots.txt kullanımını önerilen seçeneklerden biri olarak gösterir. Ancak organik owner olacak facet’lerin yanlışlıkla block edilmemesi gerekir.

Sonuç üretmeyen filtre URL’leri ne yapmalı?

Google, sonuç üretmeyen, duplicate filtre içeren, mantıksız kombinasyon oluşturan veya gerçekte var olmayan pagination URL’lerinin uygun HTTP 404 response vermesini önerir.

Fiyata göre sıralama URL’leri indexlenmeli mi?

Genellikle ayrı organic owner olmaları gerekmez. Sıralama çoğunlukla ürün kümesini değil yalnız ürünlerin gösterim sırasını değiştirir.

Bir facet’in SEO landing page olup olmayacağı nasıl belirlenir?

Search demand, user need, ürün kümesinin farklılığı, attribute’un stabilitesi, stok sürdürülebilirliği, ayrı sayfa değeri ve mevcut owner’larla çakışma birlikte değerlendirilmelidir.

Faceted navigation ile kategori mimarisi aynı şey midir?

Hayır. Kategori mimarisi hangi ürün kümelerinin hangi page role tarafından temsil edileceğini belirler. Faceted navigation ise kullanıcının bu kümeleri nasıl daraltacağını ve oluşan URL state’lerinin crawl/index politikasını yönetir.

Kaynaklar ve teknik referanslar

1. Google Crawling Infrastructure — Managing crawling of faceted navigation URLs
2. Google Search Central — How to specify a canonical URL
3. Google Search Central — What is canonicalization?
4. Google Search Central — URL Structure Best Practices