Çok Dilli Sitede Filtre URL'leri Nasıl Yönetilir?

Bir e-ticaret sitesini çok dilli yapıya taşıdığınızda filtre URL'leri beklenmedik bir yer kaplar. Renk, beden, kategori, fiyat aralığı, marka — her filtre kombinasyonu potansiyel olarak bir URL üretiyor; bu URL'lerin her biri de dil sayısıyla çarpılıyor. Sekiz dil ve elli filtre kombinasyonunuz varsa, yalnızca bu kesişimden dört yüz URL elde edersiniz. Gerçek katalog ölçeğinde bu sayı binlere ulaşıyor.

Ama asıl zorluk rakamlar değil — karar noktaları dizisi. Filtre parametrelerini yerelleştirmeli misiniz? Hangi filtre URL'leri dizine girmeli, hangisi canonical ile üst kategoriye bağlanmalı? Aynı filtre kombinasyonu farklı dil sürümlerinde mevcutsa hreflang eşleşmesi nasıl kurulur? Her karar bir sonrakini etkiliyor. Çok dilli yapı ise tek dilli sitede geçiştirilebilecek kestirmeleri ortadan kaldırıyor.

Bu kararlar sıradan bir "tara veya engelle" seçiminden daha katmanlı. Parametre yapısından sitemap yönetimine, pazar farklılıklarından JavaScript durum sınırlarına uzanan bir değerlendirme gerektiriyor. Aşağıdaki bölümler bu karar noktalarını sırayla ele alıyor.

Filtre parametre adları ve değerleri: evrensel mi, yerel mi?

Filtre URL'lerinde ilk karar, parametrelerin dilden bağımsız mı tutulacağı yoksa her dil sürümüne göre mi şekilleneceğidir. Bu karar teknik basitlik ile SEO değeri arasındaki bir trade-off içeriyor.

Parametre adları — color, size, brand — çoğu durumda evrensel bırakmak daha mantıklı. Parametrenin kendisi kullanıcıya doğrudan görünmez, teknik altyapıyı etkiler ve backend'de tek bir logic'le yönetilir. Almanca sürümünüzde farbe yerine color kullanmak gereksiz karmaşıklık yaratır. Google zaten parametre adından değil, sayfa içeriğinden anlam çıkarıyor.

Parametre değerleri farklı bir tablo sunuyor. /tr/gomlekler?renk=kirmizi ile /tr/gomlekler?color=red arasında arama davranışı açısından ciddi fark var. Eğer o filtre sayfasını dizine almayı planlıyorsanız ve "kırmızı gömlek" gibi yerel bir sorgu hedefliyorsanız, değerleri yerelleştirmek doğrudan SEO değeri taşıyor. Dizine almayacaksanız bu fark pratikte kaybolur — ama o kararı vermeden önce değerin var olup olmadığına bakmak gerekiyor.

Yol segmenti kullanan mimarilerde — /renk/kirmizi/ formatı — yerelleştirme hem zorunlu hem daha temiz hale geliyor. Sorgu parametresi mimarisinde ise dikkatli olmak gerekiyor: Türkçe, Arapça veya Kiril gibi karakter setleri URL encoding sorunları yaratabilir. Bu senaryo için parametre değerlerini ASCII slug formatına normalize etmek — kırmızı yerine kirmizi — hem crawl güvenilirliğini hem de hreflang doğruluğunu artırır. Normalizasyon yapılmazsa aynı filtreye karşılık gelen iki farklı URL biçimi canonical çatışması yaratabilir; özellikle dil değiştirici mekanizması parametreleri aktarıyorsa bu risk somutlaşıyor.

Hangi filtre URL'si kendi sayfasına layık?

Her filtre kombinasyonu bir URL hak etmiyor. Bu ayrımı yaparken tek kriter "Google bunu tarıyor mu" olmamalı — "bu URL'nin karşılamak istediği arama ihtiyacı gerçekten var mı?" sorusu daha sağlıklı bir başlangıç.

Renk ve beden filtreleri moda e-ticaretinde çoğunlukla arama değeri taşır. "Kırmızı elbise", "L beden mont" gibi sorgular gerçek hacme sahip ve bu hacim dil sürümüne göre değişir. Almanya'da "rote Kleider", Türkiye'de "kırmızı elbise", Hollanda'da "rode jurk" aranıyor — üçü de aynı filtreye denk gelen ama farklı dil sürümlerinde farklı URL'ler gerektiren sorgular. Uluslararası keyword araştırması yapmadan bu ayrımı güvenilir biçimde yapamıyorsunuz; çünkü bir pazarda değer taşıyan filtre kombinasyonu başka bir pazarda sıfır arama hacmiyle karşılaşabilir.

Buna karşın fiyat aralığı filtreleri, sıralama filtreleri ("fiyata göre: ucuzdan pahalıya") ve stok durumu filtreleri neredeyse hiç organik değer taşımaz. Bu URL'lerin dizine girmesi crawl bütçesini tüketir, kalite sinyalini seyreltir. Noindex koyun ya da canonical ile kategori sayfasına bağlayın. Global bir "hepsini dizine al" ya da "hepsini engelle" politikası ise genellikle yanlış çalışıyor; çünkü bir filtre kombinasyonunun Türkçe sürümde karşılığı olmayabilir, aynı kombinasyon Almancada güçlü bir kümede yer alabilir. Kararın dil sürümü bazında verilmesi bu yüzden şart.

URL durumu ile JavaScript durumu: sınır nerede çizilir?

Modern e-ticaret front-end'lerinde bazı filtreler URL'yi değiştiriyor, bazıları yalnızca sayfanın görünümünü güncelliyor. Bu ayrım SEO açısından kritik bir sınır çiziyor.

URL'ye yazılan filtreler taranabilir ve potansiyel olarak dizine alınabilir. JavaScript durumunda kalan filtreler ise Googlebot için görünmez — ya da gecikmeli ve tutarsız görünür. Eğer dizine almak istediğiniz bir filtre kombinasyonunu history.pushState kullanmadan JS state'te saklıyorsanız, bu filtrenin URL'si hiçbir zaman var olmaz. Taranacak bir şey yoktur.

Çok dilli yapıda bu sorun ek bir boyut kazanıyor: dil geçiş mekanizması. Kullanıcı /de/hemden?farbe=rot sayfasındayken İngilizce sürüme geçtiğinde ne oluyor? Eğer dil değiştirici yalnızca ana kategori sayfasına yönlendiriyorsa (/en/shirts), filtre bilgisi kayboluyor. Bu hem kullanıcı deneyimi hem de hreflang tutarlılığı açısından sorun yaratıyor — hreflang'ın doğru çalışması için eşleştirdiği sayfaların gerçekten erişilebilir olması gerekiyor.

Sağlam kurulum şu ayrımı benimseyenler için çalışıyor: dizine alınacak filtreler URL'de; alınmayacaklar JS state'te. Dil değiştirici ise URL'deki filtre parametrelerini hedef dil sürümünün karşılığına çevirerek aktarmalı. Bu, özellikle parametre değerleri yerelleştirilmişse ek bir eşleme katmanı gerektiriyor — farbe=rot'tan color=red'e dönüşüm gibi. Karmaşıklık artar ama doğru yapıldığında hem kullanıcı akışı hem crawl tutarlılığı kazanılıyor.

Dil sürümleri arası filtre eşleştirmesi ve hreflang

Filtre URL'lerinde hreflang kurulumu standart sayfa kurulumundan ayrılıyor; çünkü her dil sürümünde aynı filtre kombinasyonu olmayabilir. Hreflang'ın temel mantığı gereği, yalnızca gerçekten mevcut olan ve eşdeğer içerik sunan sayfalar birbirine işaret etmeli.

Türkçe sürümde "kırmızı bluz" filtresi var ve stokta ürün mevcut. Almanca sürümde bu renk-ürün kombinasyonu yok. Bu durumda Türkçe filtre URL'sine Almanca hreflang eklemek yanlış — Google eşdeğer olmayan bir sayfaya yönlendirilmiş olur. Hreflang yalnızca her iki sürümde de o filtre kombinasyonu gerçekten var olduğunda kurulmalı. Stok değişimleri nedeniyle bu eşleşme zaman içinde bozulabilir; büyük kataloglarda filtre hreflang setlerinin dinamik olarak üretilmesi ve düzenli doğrulanması şart oluyor.

Noindex kararı verilen filtre sayfaları için hreflang'ı tamamen kaldırın. Noindex + hreflang kombinasyonu karışık sinyal üretiyor: Google sayfayı dizine almıyor ama başka dil sürümlerinden bu sayfaya referans var. Canonical'ı üst kategori sayfasına çeken filtre URL'leri de aynı şekilde hreflang içermemeli. Canonical, noindex ve hreflang üçünün tutarlı çalışması için bu kararların birbirine bağlı verilmesi gerekiyor — bunlardan birini düzenleyip diğerini unutmak, yüzlerce URL setinde sinyal kirliliği yaratıyor. Daha geniş mimari bağlam için çok dilli faceted navigation sorunlarına bakabilirsiniz.

Pazar bazlı filtre mantığı: her dil sürümü aynı filtrelere sahip olmak zorunda değil

Çok dilli SEO'nun sıkça atlanılan boyutlarından biri: farklı pazarlar farklı filtre setleri gerektirebilir. Bu yalnızca teknik bir tercih değil, çoğunlukla operasyonel bir gerçek.

Avrupa pazarlarında beden standardı farklıdır. Almanya'daki "38 beden" ile İngiltere'deki "10 beden" aynı ürünü anlatır ama farklı filtre değerleri ve URL yapıları gerektirir. Bunun ötesinde, bir ülkede satışta olan ürün grubu başka ülkede hiç bulunmayabilir. Yasal düzenlemeler belirli kategorileri kısıtlayabilir. Mevsimsel farklılıklar filtre ağırlığını değiştirebilir — İskandinav pazarında kış ürünü filtreleri yaz ürünü filtrelerine oranla çok daha kritik; arama davranışı bunu yansıtıyor.

SEO açısından bu, her dil sürümünün bağımsız bir filtre mimarisi olabileceği anlamına geliyor. Merkezi bir filtre yapısı kurarken "tüm dillerde aynı filtreler" varsayımıyla yola çıkmak ileriki aşamada hem teknik borç hem SEO hatası üretiyor. Bir filtre İspanya pazarında anlam taşısa bile Türkiye sürümünde karşılığı yoksa, o filtre URL'sini Türkçe sürümde oluşturmak ve yönetmeye çalışmak boşa efor tüketiyor. Bu karar hreflang eşleştirmesini de doğrudan etkiliyor: o dil sürümünde filtre yoksa hreflang çifti de olmamalı.

Sitemap kararı: filtre URL'lerinde ne dahil edilir, nasıl güncellenir?

Filtre URL'lerinin sitemap yönetimi, standart sayfa sitemapından farklı düşünülmeli. Temel netleştirme: sitemap'e dahil edeceğiniz filtre URL'leri, daha önce verdiğiniz "neyi dizine al" kararıyla tam örtüşmeli. Sitemap'te olmayan bir sayfa Google tarafından hiç bulunamaz değil — ama sitemap'teki her URL crawl kaynağı tüketiyor ve bir beklenti yaratıyor. Noindex kararı verilen filtreyi sitemap'e eklemek, bu iki sinyali birbirine zıt hale getiriyor.

Pratikte işe yarayan yaklaşım: değeri kanıtlanmış filtre URL'leri sitemapa eklenir; değeri belirsiz ya da düşük olanlar dışarıda bırakılır. Zamanla dizinleme ve sıralama verisi incelenerek liste güncellenir. Bunu statik bir karar gibi değil, döngüsel bir süreç olarak kurmak gerekiyor. Özellikle büyük kataloglarda ürün eklenip çıktıkça filtre URL'lerinin içerik değeri değişiyor.

Uluslararası sitemap kurulumunda filtre URL'lerini ayrı dosyalara çıkarmak yönetimi kolaylaştırıyor. sitemap-filters-de.xml, sitemap-filters-tr.xml gibi dil bazlı dosyalar hem güncellemeyi hem de Google Search Console'da dil bazlı analizi kolaylaştırır. Bir ürün kalktığında ya da bir filtre kombinasyonu artık stokta yoksa ilgili URL'yi sitemap'ten çıkarmak ve canonical'ı üst kategori sayfasına çekmek, crawl bütçesinin boşa harcanmasını önlüyor.

changefreq ve priority değerleri filtre sayfaları için muhafazakâr tutulmalı. monthly ve 0.5 çoğu durumda yeterli.

Filtre URL yönetimi tek seferlik bir kurulum değil. Katalog genişledikçe, yeni pazarlara girildiğinde ya da platform değiştiğinde filtre mimarisi de tekrar değerlendirilmesi gereken bir katmana dönüşüyor. İç linkleme stratejisi içinde kategori sayfalarından yalnızca değeri kanıtlanmış filtre URL'lerine bağlantı vermek, bu sayfaların otoritesini de destekliyor — aksi hâlde crawl kaynağı boşa giden yüzlerce URL'ye dağılıyor.

Parametre yerelleştirmesinden hreflang eşleştirmesine, sitemap güncellemesinden pazar bazlı filtre mantığına kadar uzanan bu karar zincirinin en sağlıklı işlediği nokta: her kararın bir diğeriyle tutarlı olduğu yapılar. Canonical sayfaya işaret ederken hreflang başka bir URL'ye referans veriyorsa, noindex koyarken sitemap'ten kaldırmayı unutulmuşsa, ya da dil değiştirici filtre bilgisini aktaramıyorsa — bunların her biri ayrı ayrı küçük görünüyor, ama toplamda ciddi dizinleme sorununa dönüşüyor. Kararlara bütünlük içinde bakılması bu yüzden önemli.