"Filtreleme var, faceted navigation yok" ayrımı, pratikte pek az ekip tarafından bilinçli biçimde yapılır. Bir sayfada birkaç filtre seçeneği sunmak ile gerçek anlamda faceted navigation kurmak arasında hem mimari hem de SEO açısından önemli farklar vardır. Bu farkın farkında olmadan kurulan sistemler kısa vadede çalışır görünür; ama ölçeklendikçe sorun üretmeye başlar.

Faceted navigation özünde şu fikre dayanır: bir içerik kümesini birbirinden bağımsız birden fazla nitelik boyutunda aynı anda daraltabilmek. Renk, beden ve fiyat aralığını aynı anda kullanan bir ziyaretçi üç farklı boyutu eş zamanlı uygular. Bu üç boyutun her kombinasyonu farklı bir sonuç kümesi üretir ve bu durum hem büyük bir kullanıcı deneyimi avantajıdır hem de dikkatli yönetilmezse ciddi bir teknik risk kaynağıdır.

Klasik kategori yapısında bir içerik tek bir konuma atanır. Faceted navigation ise bu mantığı tersine çevirir: bir ürün aynı anda "mavi", "45 numara", "150–300 TL arası" ve "su geçirmez" niteliklerine sahip olabilir; kullanıcı bu niteliklerin herhangi bir kombinasyonuyla o ürüne ulaşabilir. Bu esneklik, kategori hiyerarşisinin sağlayamadığı bir keşif derinliği sunar.

Filtreleme yapısının arayüz boyutu ayrı bir yazıda ele alındı; buradaki bakış açısı mimari ve kavramsal: hangi nitelikler facet olarak kurgulanmalı, URL yapısı nasıl yönetilmeli, SEO açısından ne gibi riskler var ve bu yapı ne zaman gerçekten gereklidir.

Faceted navigation, kategori ağacından farklı bir gezinme mantığı sunar

Kategori yapısında içerik tek bir konuma atanır. "Erkek > Üst Giyim > Sweatshirt" kategorisindeki bir ürün o konumdadır ve başka bir konumda değildir. Kullanıcı bu hiyerarşiyi izleyerek ilgili içeriğe ulaşır. Bu mantık, net ve sabit sınıflandırmaların mümkün olduğu içerik türlerinde güçlüdür.

Faceted navigation ise içeriği konuma değil niteliklere göre düzenler. Bir ürün beş farklı niteliğe sahipse — renk, beden, materyal, fiyat aralığı, marka — kullanıcı bu niteliklerin herhangi birini ya da birkaçını birden seçerek sonuçları daraltabilir. İçerik sabit bir konumda değildir; seçilen facet kombinasyonuna göre dinamik olarak filtrelenir.

Bu fark iki önemli sonuç doğurur. Birincisi, faceted navigation çok daha fazla içerik çeşitliliği barındıran ve bu çeşitliliğin kullanıcı için anlamlı olduğu sistemlerde değer üretir. On ürünlü küçük bir mağazada facet gereksizdir; binlerce ürünü olan ve bu ürünlerin onlarca niteliği bulunan bir mağazada ise neredeyse zorunludur. İkincisi, doğru yönetilmezse kategori yapısından çok daha karmaşık bir URL ve indeks sorunu üretir. Kategori ağacı ile düz liste arasındaki seçim mimari bir kararken, faceted navigation bu iki yapının üzerine oturan ayrı bir katmandır.

Faceted navigation'ı kategori yapısının yerini alan bir çözüm olarak görmek yanıltıcıdır. Çoğu sistemde bu iki yapı birlikte çalışır: kategoriler içeriği geniş gruplara ayırırken facetler o grup içinde niteliğe göre daraltma sağlar. Ama bu birliktelik tasarlanmış bir ayrım gerektirir; kendiliğinden oluşmaz.

Her nitelik facet olmaya uygun değildir

Faceted navigation tasarımında en sık yapılan hatalardan biri, bir içerik parçasının taşıdığı her niteliği otomatik olarak facet olarak sunmaktır. Teknik olarak mümkün olmak, mimari açıdan doğru olmak anlamına gelmez.

Bir niteliğin facet olarak sunulmasının anlamlı olabilmesi için birkaç koşulun sağlanması gerekir. Her şeyden önce o nitelik, içerik kümesinin önemli bir bölümünde tutarlı biçimde var olmalıdır. Eğer "malzeme" niteliği ürünlerin yalnızca yüzde onunda doldurulmuşsa bu niteliğe dayalı bir facet kullanıcıya anlamsız bir filtreleme sunar. İkinci olarak, o niteliğe göre arama yapacak yeterli sayıda kullanıcı olmalıdır. "Üretim ülkesi" bilgisi veri olarak mevcut olsa bile bu bilgi için filtreleme yapan ziyaretçi sayısı çok azsa bu niteliği öne çıkarmak arayüzü karmaşıklaştırır.

Üçüncü ve çoğu zaman gözden kaçan koşul şudur: niteliğin değerleri arasında kullanıcının anlamlı seçim yapabileceği kadar çeşitlilik olmalıdır. Yalnızca iki değer alabilen bir nitelik — örneğin "indirimli / tam fiyat" — facet yerine basit bir filtre düğmesi olarak daha iyi temsil edilebilir. Öte yandan onlarca değer alabilen ve bu değerlerin önemli bir kısmında içerik bulunan nitelikler facet mantığına en uygun adaylardır.

Nitelik seçimi aynı zamanda veri kalitesine bağlıdır. Facet olarak sunulacak bir niteliğin tüm içerik kümesinde standart ve tutarlı biçimde etiketlenmiş olması gerekir. "Mavi", "lacivert", "gece mavisi" ve "indigo" gibi değerler birleştirilmemişse renk faceti karmaşık bir liste üretir ve kullanıcıya gerçek bir daraltma sağlamaz. Bu nedenle facet kararı yalnızca bir UI tasarım kararı değildir; veri standardizasyonu süreciyle birlikte yürütülmesi gereken yapısal bir karardır.

Facet kombinasyonları URL mimarisini doğrudan şekillendirir

Faceted navigation'ın en karmaşık boyutu URL yönetimidir. Kullanıcı bir facet seçtiğinde sistemin bir URL üretmesi gerekir. Bu URL ya kalıcı ve anlamlı bir adres olur ya da geçici ve oturuma özgü bir sorgu dizisi olur. Bu tercih hem kullanıcı deneyimini hem de arama motoru taramasını derinden etkiler.

Sorgu parametresi yaklaşımında URL şu biçimi alır: `/urunler?renk=mavi&beden=M&fiyat=100-300`. Bu yaklaşım teknik olarak basittir; yeni bir facet eklendiğinde parametre listesine eklenir. Ama bu URL'ler genellikle bookmark'a uygun değildir ve arama motorlarının bunları nasıl değerlendireceği her zaman öngörülebilir değildir.

Yol tabanlı URL yaklaşımında ise belirli kombinasyonlara kendine özgü temiz adresler verilir. Bu URL'ler daha okunabilirdir ama kombinasyonel patlama riski taşır. Üç niteliğin her birinde on değer varsa teorik olarak bin farklı kombinasyon URL'i oluşabilir. Bu URL'lerin büyük bölümü az içerik barındırır ve tümü arama motorlarına açık bırakılırsa ince arşiv sorunu ciddi boyutlara ulaşır. Her iki yaklaşımın melez versiyonları yaygındır: en önemli kombinasyonlar temiz URL alırken geri kalanlar parametre kullanır. Ama neyin "önemli" sayıldığını belirlemek ve bu kararı sürdürmek tutarlı bir editoryal disiplin gerektirir. URL yapısı kararları başlangıçta verildikten sonra değiştirmesi maliyetli kararların başında gelir ve faceted navigation bu zorluğu katlar.

Boş sonuç sorunu facet tasarımının en kritik kırılma noktasıdır

Faceted navigation'ın en sık karşılaşılan ve en kötü kullanıcı deneyimi üreten sorunu, kombinasyon seçimlerinin boş bir sonuç listesine götürmesidir. Kullanıcı birden fazla facet seçer, sistem geçerli içerik bulamaz ve ziyaretçi "sonuç bulunamadı" ekranıyla karşılaşır.

Bu sorunun oluşmasının iki temel nedeni vardır. Birincisi, içerik kümesinde gerçekten o kombinasyona uyan içerik yoktur. İkincisi, sistem kullanıcıya bu kombinasyonun boş sonuç üreteceğini önceden göstermemiştir. İyi tasarlanmış faceted navigation sistemleri seçilebilecek değerleri içerik durumuna göre dinamik olarak günceller: mevcut seçimlerle birleştiğinde sıfır sonuç üretecek facet değerleri ya devre dışı bırakılır ya da içerik sayısı gösterilerek ziyaretçi uyarılır.

Bu dinamik güncelleme teknik açıdan maliyetlidir. Her facet seçimi değiştiğinde sistemin geçerli değerleri yeniden hesaplaması gerekir. Büyük içerik kümelerinde bu hesaplama yavaşlayabilir; ön bellekleme ve indeks stratejileri bu yükü azaltır ama facet sayısı ve içerik hacmi arttıkça maliyet de büyür.

Boş sonucu önceden önlemenin pratik yolu, facet değerlerinin içerik dağılımını sürekli izlemektir. Belirli bir değer çok az sayıda içerikle eşleşiyorsa diğer facetlerle birleştirilmesi kolayca boş sonuca götürebilir. Bu tür değerleri gruplandırmak ya da "diğer" kategorisine taşımak, boş sonuç üretme sıklığını düşürür. Filtreleme yapısı kurulurken seçim kombinasyonları baştan ele alınmazsa bu sorun sonradan çözmesi çok daha güç bir yapısal borç hâline gelir.

SEO açısından facet URL'leri özel bir yönetim gerektirir

Faceted navigation dikkatli yönetilmediğinde SEO açısından ciddi sorunlara yol açabilir. Temel risk şudur: yüzlerce ya da binlerce facet kombinasyonu, içerik olarak birbirinden yalnızca küçük farklarla ayrılan URL'ler üretir. Arama motorları bu URL'lerin çoğunu ince içerikli ya da yinelenen sayfa olarak değerlendirebilir.

Bu riski yönetmenin birkaç pratik yolu vardır. Robots.txt ya da meta robots etiketi aracılığıyla facet URL'lerinin taranmasını ve indekslenmesini kısıtlamak yaygın bir yaklaşımdır. Tüm facet kombinasyonlarını taramaktan kaçınan botlar, sitenin asıl içerik sayfalarına daha fazla kaynak ayırır. Ama bu kısıtlamayı çok katı uygulamak, gerçekten değerli olabilecek bazı kombinasyon sayfalarının da devre dışı kalmasına yol açar.

Canonical etiket kullanımı bu dengeyi kurmada yardımcı olur. Belirli facet kombinasyonlarına ait sayfalar, ilgili üst kategori sayfasına ya da en yakın temiz URL'e işaret eden bir canonical etiketi taşıyabilir. Bu sayede içeriğin erişilebilirliği korunurken arama motoruna indeksleme sinyali verilmez. Hangi kombinasyonların değerli sayfa sayılacağına karar vermek için arama verisi yol göstericidir: belirli facet kombinasyonlarına karşılık gelen organik sorgular varsa o kombinasyonlar için tam indeksleme anlamlıdır. Site haritası planlamasında hangi sayfaların dahil edileceği kararı, faceted navigation sitelerinde özellikle stratejik önem taşır: tüm kombinasyonları değil, yalnızca yeterli içerik yoğunluğu olan kombinasyonları dahil etmek gerekir.

Facet altyapısı kurulmadan önce veri modeli hazır olmalıdır

Faceted navigation, doğru çalışması için tutarlı ve standartlaştırılmış bir veri modelini zorunlu kılar. Bu gereklilik çoğu zaman göz ardı edilir ve sistemin görsel olarak çalışır görünmesine rağmen kullanıcı için gerçek bir değer üretmemesine yol açar.

Bir facet'in kullanışlı olabilmesi için o facet'in temsil ettiği nitelik, içerik kümesinin büyük bölümünde doğru, tutarlı ve standart biçimde etiketlenmiş olmalıdır. "Renk" niteliği için "mavi", "lacivert", "gece mavisi" ve "koyu mavi" gibi birbirine yakın ama farklı değerlerin kullanılması renk facet'ini işlevsiz kılar: kullanıcı "mavi" seçtiğinde "lacivert" etiketli içerikler sonuçta görünmez.

Bu sorun teknik değil, operasyonel bir sorundur. İçerik üretim sürecinde nitelik değerlerini standartlaştıran bir kural ve kontrol mekanizması olmadan faceted navigation, veritabanıyla çelişen bir arayüze dönüşür. Büyük içerik kümelerinde geriye dönük standardizasyon son derece maliyetlidir; bu nedenle facet planlaması içerik üretim süreciyle eş zamanlı değil, ondan önce yapılmalıdır.

Facet sayısı da veri modeli kapsamını belirler. Her yeni facet, o niteliğin mevcut içeriğin tamamına uygulanmasını gerektirir. Binlerce içerik barındıran bir sistemde sonradan eklenen bir facet, geriye dönük etiketleme yüküyle birlikte gelir. Facet sayısını ve kapsamını önceden planlamak bu yükü öngörülebilir tutar ve sistemin zamanla hangi yönde büyüyeceğine dair net bir çerçeve çizer.

Faceted navigation e-ticaret dışında da anlam taşır

Faceted navigation denildiğinde akla ilk gelen örnek e-ticaret siteleridir. Kıyafet, elektronik, mobilya — çok nitelikli ürün katalogları bu yapı için doğal bir zemin sunar. Ama bu yaklaşım yalnızca e-ticaret için değildir.

İş ilanı siteleri, faceted navigation'ın güçlü biçimde çalıştığı başka bir alan sunar. Şehir, pozisyon türü, çalışma modeli, deneyim seviyesi ve sektör — bu niteliklerin herhangi bir kombinasyonunu uygulayabilen bir sistem, hiyerarşik bir kategori yapısının sağlayamayacağı arama esnekliği sunar. Benzer mantık emlak siteleri, akademik makale veritabanları, tarif siteleri ve otel rezervasyon platformları için de geçerlidir.

Bir sitede faceted navigation'ın anlamlı olup olmadığını belirleyen şey, içerik türü değil içeriğin yapısıdır. Üç koşul bir arada bulunduğunda bu yapı değer üretir: içerik kümesi yeterince büyüktür, her içerik birden fazla bağımsız niteliğe sahiptir ve kullanıcılar bu niteliklerin farklı kombinasyonlarına göre arama yapma eğilimindedir. E-ticaret site mimarisinde faceted navigation vazgeçilmez bir bileşen olarak öne çıksa da bu yapıyı yalnızca e-ticaretle özdeşleştirmek, farklı içerik türlerine uygulanabilecek güçlü bir mimari aracı gereksiz yere daraltmak anlamına gelir.

Faceted navigation, çok nitelikli içerik kümelerini yönetmenin en esnek yollarından birini sunar. Ama bu esneklik, kategori yapısından çok daha karmaşık mimari kararları beraberinde getirir. URL yönetimi, veri standardizasyonu, boş sonuç önleme ve SEO dengesi — bunların her biri başlangıçta ele alınması gereken yapısal sorulardır.

"Filtrelerimiz var, faceted navigation kuruldu" demek için bu kararların verilmiş olması gerekir. Filtreleme arayüzü sunmak ile faceted navigation mimarisi kurmak, görünürde benzer ama özünde farklı iki işlemdir. Bu farkı bilmek, sistemin kısa vadede çalışır görünürken uzun vadede ürettiği teknik borçtan korunmanın başlangıç noktasıdır.