E-Ticaret Siteleri İçin Dinamik URL ve Slug Üretim Algoritmaları

Bir e-ticaret sitesinde URL yapısı çoğu zaman ürün yayına alınana kadar fazla önemsenmez. Sonra ürün adları değişir, kategoriler taşınır, aynı isimli ürünler çoğalır, eski bağlantılar indekslenmeye devam eder ve küçük görünen slug kararları ciddi teknik SEO sorunlarına dönüşür. E-Ticaret Siteleri İçin Dinamik URL ve Slug Üretim Algoritmaları tam da bu noktada yalnızca metni küçük harfe çevirip boşlukları tire yapmakla sınırlı olmayan bir mühendislik problemi haline gelir. On yıllık yazılım ve teknik SEO deneyimimde en sık gördüğüm hata, URL'nin ürün başlığından türetilen geçici bir string gibi ele alınmasıdır. Bu rehberde e-ticaret sitelerinde SEO uyumlu dinamik URL ve slug nasıl oluşturulur, ürün ve kategori sayfaları için otomatik slug üretme algoritması nasıl tasarlanır ve URL yaşam döngüsü production ortamında nasıl güvenilir biçimde yönetilir sorularını adım adım ele alacağız.

E-Ticaret URL Mimarisi Nedir?

E-ticaret URL mimarisi, ürün, kategori, marka, varyant, filtre ve dil sayfalarının hangi public adreslerle temsil edildiğini belirleyen kurallar bütünüdür. Bu yapı routing ile sınırlı değildir çünkü veri tabanı kimliği, canonical, redirect, sitemap ve iç link üretimi aynı kurallara dayanmalıdır. URL yapısı zaman içinde değişen ürün isimlerinden etkilenmemeli veya kontrollü değişmelidir. Ayrıca aynı entity'nin birden fazla erişim yolu varsa hangi adresin canonical olduğu net biçimde tanımlanmalıdır. Sağlam URL mimarisi, SEO ile backend veri modelini aynı sözleşmede buluşturur.

URL'nin Temel Bileşenleri

Bir URL scheme, domain, path, query parameter ve fragment gibi parçalardan oluşur. E-ticaret uygulamasında SEO açısından en görünür bölüm çoğunlukla path ve query parameter yapısıdır. Buna rağmen HTTPS kullanımı, domain standardizasyonu ve canonical üretimi de aynı sistemin parçasıdır. Router bu bileşenleri doğru yorumlamalıdır. URL generator ise aynı kuralları bütün uygulama katmanlarında tekrar kullanılabilir biçimde üretmelidir.

Scheme

Scheme, adresin hangi protokolü kullandığını belirtir. Production e-ticaret sitelerinde HTTPS temel tercih olmalıdır. HTTP ve HTTPS sürümlerinin aynı içeriği ayrı URL olarak sunması canonical ve redirect sorunlarına neden olabilir. Central URL resolver absolute URL üretirken doğru scheme'i kullanmalıdır. CDN ve reverse proxy arkasında çalışan sistemlerde forwarded protocol bilgisinin güvenilir biçimde ele alınması gerekir.

Domain

Domain, sitenin public kimliğinin temel parçasıdır. www ve non-www sürümleri ayrı ayrı erişilebiliyorsa tek tercih edilen sürüme yönlendirme yapılmalıdır. Çok bölgeli yapılarda farklı domain veya subdomain stratejileri kullanılabilir. Canonical ve sitemap aynı domain politikasını izlemelidir. Yanlış domain üretimi özellikle staging ve production configuration karıştığında ciddi indeksleme problemleri doğurabilir.

Path

Path, ürün veya kategori gibi kaynağın URL içindeki yolunu temsil eder. Örneğin /urun/kirmizi-elbise yapısında /urun/ route namespace, kirmizi-elbise ise slug olabilir. Path mümkün olduğunca stabil ve kullanıcı tarafından anlaşılır tutulmalıdır. Entity kimliği yalnızca path metnine bağlanmamalıdır. Route template değişiklikleri migration ve redirect planıyla birlikte yapılmalıdır.

Query Parameter

Query parameter, URL sonundaki key=value çiftleriyle state taşır. Filtre, sıralama, pagination veya tracking amacıyla kullanılabilir. Her parameter'ın indexable olup olmadığı ayrıca belirlenmelidir. Aynı değerlerin farklı sıralarda bulunması duplicate URL üretebilir. Canonical serialization bu nedenle parameter yönetiminin önemli parçasıdır.

Fragment

Fragment, # işaretinden sonra gelen client-side bölümü ifade eder. Tarayıcı belirli sayfa bölümüne kaydırmak için kullanabilir. Genellikle server request'e gönderilmez. E-ticaret filtre durumunu fragment içinde saklamak modern SEO yapılarında çoğu zaman doğru çözüm değildir. Indexlenmesi gereken içerik server tarafından erişilebilir URL ile sunulmalıdır.

E-Ticarette URL Neden Bir Veri Modeli Problemidir?

Ürün adı değişebilir ama ürün entity'si aynı kalır. Kategori başka parent altına taşınabilir ama kategori kimliği korunur. Bu nedenle URL yalnızca string formatting problemi değildir. Entity ID, locale, current slug, previous slug ve redirect ilişkileri veri modelinde temsil edilmelidir. URL'nin kalıcı davranışı ancak bu ilişkiler veri tabanı seviyesinde açık biçimde modellendiğinde güvenilir hale gelir.

SEO, Routing ve Veri Tabanı İlişkisi

SEO ekibi canonical ve redirect kurallarını tanımlar. Router gelen path'i entity ile eşleştirir. Veri tabanı current ve historical slug bilgisini saklar. Sitemap ve iç link üreticileri aynı resolver üzerinden URL oluşturur. Bu katmanlar farklı kurallar kullanırsa canonical mismatch ve gereksiz redirect sorunları kaçınılmaz hale gelir.

Slug Nedir?

Slug, URL path içinde belirli bir entity'yi insan tarafından okunabilir biçimde temsil eden metinsel parçadır. Ürün adından üretilebilir ancak entity kimliğinin kendisi olmak zorunda değildir. İyi slug kısa, anlaşılır, tutarlı ve stabil olur. Slug değişiklikleri kontrollü biçimde yönetilmelidir. E-ticaret URL yapısında Türkçe karakter kategori ürün adı ve benzersiz slug yönetimi bu nedenle ayrı bir servis veya domain modülü olarak ele alınabilir.

URL Slug Ne Anlama Gelir?

Slug, çoğunlukla ürün veya kategori adının URL dostu dönüşümüdür. Örneğin “Kırmızı Elbise” başlığı kirmizi-elbise slug'ına dönüşebilir. Slug kullanıcıya içeriğin konusu hakkında fikir verir. Search engine açısından da URL'nin okunabilirliğini artırır. Buna rağmen ranking için anahtar kelime doldurmak amacıyla sürekli değiştirilmemelidir.

Slug ile Path Arasındaki Fark

Path URL içindeki tam yol bölümüdür. Slug ise path'in yalnızca bir segmenti olabilir. /urun/kirmizi-elbise adresinde path /urun/kirmizi-elbise, slug ise kirmizi-elbise olarak düşünülebilir. Kategorili yapılarda birden fazla slug segmenti aynı path içinde bulunabilir. Veri modelinde path ile slug'ı ayrı tutmak migration işlemlerini kolaylaştırabilir.

Slug ile Query Parameter Arasındaki Fark

Slug çoğunlukla entity'nin ana public adresinde bulunur. Query parameter ise filtre, sıralama veya geçici state taşır. /urun/kirmizi-elbise?color=siyah örneğinde kirmizi-elbise slug, color=siyah parameter'dır. Canonical politikasında bu iki bileşenin rolü farklıdır. Tracking parameter'ları slug sistemine dahil edilmemelidir.

Slug ile İçerik ID'si Arasındaki Fark

Slug kullanıcı dostu ve editoryal bir değerdir. İçerik ID'si ise entity'nin kalıcı teknik kimliğidir. Ürün adı ve slug değişse bile ID aynı kalmalıdır. Bu ayrım redirect, history ve locale yönetimini kolaylaştırır. Slug'ın primary key gibi kullanılmaması uzun vadeli URL stabilitesi açısından daha sağlıklıdır.

Dinamik URL Nedir?

Dinamik URL, uygulama tarafından veri tabanı, route parametresi veya query state üzerinden oluşturulan URL'dir. Dinamik olması URL'nin kötü veya indekslenemez olduğu anlamına gelmez. Modern e-ticaret sitelerinin büyük bölümü ürün URL'lerini dinamik olarak çözer. Asıl önemli nokta aynı içeriğin kontrolsüz sayıda farklı URL ile erişilebilir hale gelmemesidir. Stabil route ve canonical sistemi dinamik yapıyı SEO açısından güvenilir hale getirir.

Dinamik İçerik ile Dinamik URL Aynı Şey midir?

Dinamik içerik verinin request sırasında oluşturulmasını ifade eder. Dinamik URL ise URL'nin parametre veya entity state'e göre çözümlenmesini anlatır. Statik görünümlü /urun/kirmizi-elbise URL'si backend tarafından dinamik oluşturulabilir. Buna karşılık query parameter içeren adres de tamamen cache'lenmiş içerik gösterebilir. Bu nedenle URL görünümünden rendering modelini doğrudan çıkarmak doğru değildir.

Query Parameter Nedir?

Query parameter route'a ek seçenekler iletir. Filtre, pagination, sort ve tracking bu yöntemle taşınabilir. Parameter sırası normalize edilmezse aynı state birden fazla URL ile temsil edilebilir. Allowed parameter list tanımlamak gereksiz crawl alanını sınırlar. Canonical generator geçici parameter'ları çoğunlukla dışarıda bırakmalıdır.

Path Parameter Nedir?

Path parameter route'un dinamik segmentidir. /urun/{slug} yapısındaki slug buna örnektir. Router değeri alıp URL registry veya entity tablosunda arar. Path parameter insan dostu olabilir. Ancak tek başına persistent kimlik olarak kullanılmamalıdır.

Database ID İçeren URL

/urun/12345 gibi adresler teknik açıdan oldukça stabildir. Fakat kullanıcıya ürün hakkında az bilgi verir. ID ile slug birlikte kullanılabilir. Örneğin /urun/12345-kirmizi-elbise yapısı lookup ve okunabilirliği birleştirebilir. Bunun gerçekten gerekli olup olmadığı route tasarımına göre değerlendirilmelidir.

Dinamik URL'ler SEO İçin Kötü müdür?

Dinamik URL kullanmak tek başına SEO problemi değildir. Search engine'ler query parameter ve dinamik route içeren sayfaları tarayabilir. Sorun aynı içeriğe onlarca veya milyonlarca farklı URL üretilmesidir. Geçici session ve tracking parameter'ları crawl alanını gereksiz büyütebilir. Bu nedenle dinamik URL yönetiminde canonical, parameter policy ve indexability kuralları baştan tasarlanmalıdır.

Parametre Kullanmak Tek Başına Problem midir?

Hayır. Pagination veya anlamlı filtre state'i parameter ile temsil edilebilir. Sorun parameter'ın sınırsız veya tutarsız üretilmesidir. Aynı filter farklı sıralarla tekrar oluşmamalıdır. Indexlenmesi gereken ve gerekmeyen parameter'lar açıkça ayrılmalıdır.

Asıl Risk: Duplicate URL Üretimi

Aynı ürün farklı parameter veya kategori path'leri üzerinden erişilebiliyorsa duplicate URL oluşabilir. Search engine hangi adresin ana olduğunu anlamakta zorlanabilir. Tek canonical product URL belirlenmelidir. İç linkler ve sitemap yalnızca current canonical adresi kullanmalıdır. Duplicate yollar gerektiğinde redirect veya canonical ile yönetilmelidir.

Asıl Risk: Geçici Parametreler

UTM ve click ID gibi değerler içerik kimliğinin parçası değildir. Bu parameter'ların canonical URL'ye eklenmesi gereksiz duplicate oluşturur. Analytics amacıyla request'te kalabilirler. Canonical generator ise bunları temizlemelidir. Server log analizi bu parameter'ların crawl edildiğini gösterebilir.

Asıl Risk: Sonsuz URL Alanı

Filtrelerin kontrolsüz kombinasyonu milyonlarca URL üretebilir. Fiyat, renk, beden ve sort parameter'ları birbirleriyle birleşebilir. Search engine crawl budget gereksiz sayfalara harcanabilir. Facet engine indexable kombinasyonları sınırlamalıdır. Slug engine ile filtre URL politikası birbirinden ayrılmalıdır.

SEO Uyumlu E-Ticaret URL'sinin Temel Özellikleri

SEO uyumlu URL yalnızca kısa veya anahtar kelime içeren URL değildir. Stabil olması, aynı entity için tek canonical adres üretmesi ve route kurallarıyla tutarlı çalışması gerekir. Kullanıcı adresi gördüğünde sayfanın ne hakkında olduğunu anlayabilmelidir. Sistem değişiklikleri URL churn üretmemelidir. En güçlü URL yapıları editoryal değişiklikleri entity kimliğinden ayırır.

Açıklayıcı

Slug ürün veya kategori hakkında temel bağlam vermelidir. Rastgele karakter dizileri kullanıcı açısından anlam taşımaz. Aşırı uzun anahtar kelime zincirleri de okunabilirliği bozar. En önemli ürün adı ve model bilgisi yeterlidir. Açıklayıcı olmak, URL'yi reklam metnine çevirmek anlamına gelmez.

Stabil

URL mümkün olduğunca uzun süre aynı kalmalıdır. Ürün başlığındaki küçük editoryal değişiklik URL'yi otomatik değiştirmemelidir. Stabil adres backlink ve bookmark değerini korur. Analytics sürekliliği de iyileşir. Gerekli değişikliklerde 301 history tutulmalıdır.

Benzersiz

Bir namespace içindeki public URL tek entity'ye ait olmalıdır. Database unique constraint bu kuralı enforce etmelidir. Application-level check tek başına race condition'ı engelleyemez. Locale bazlı namespace gerekiyorsa uniqueness scope açık tanımlanmalıdır. Collision resolver deterministik davranmalıdır.

Tutarlı

Benzer entity türleri aynı route template'i kullanmalıdır. Bir ürün bazen /product/, bazen /urun/ altında rastgele görünmemelidir. Locale route farklılığı bilinçli olmalıdır. Parameter order ve separator kuralları da aynı şekilde standartlaştırılmalıdır. Tutarlılık hem kullanıcı hem crawler davranışını kolaylaştırır.

Kullanıcı Tarafından Okunabilir

Slug mümkün olduğunca anlamlı kelimelerden oluşmalıdır. Gereksiz teknik ID veya hash görünümü azaltılmalıdır. Deterministik kısa ID collision çözümü için gerektiğinde kullanılabilir. URL kopyalandığında kullanıcı içerik hakkında fikir sahibi olmalıdır. Okunabilirlik lokalizasyon politikasıyla birlikte düşünülmelidir.

Canonical Sistemiyle Uyumlu

Canonical URL generator current slug ve doğru route template'i kullanmalıdır. Sitemap aynı adresi yayınlamalıdır. Internal link helper da aynı resolver'dan değer almalıdır. Üç farklı kod path'i üç farklı URL üretmemelidir. Central URL resolver bu uyumu sağlamak için kritik bileşendir.

Slug Üretim Algoritması Nasıl Çalışmalıdır?

Sağlam slug generator input normalizasyonundan collision resolution'a kadar belirli aşamalardan geçmelidir. İşlem sırası önemlidir çünkü Unicode veya locale normalizasyonu collision kontrolünden sonra yapılırsa aynı görünen iki slug farklı kayıt olarak değerlendirilebilir. Algoritma deterministik olmalıdır. Aynı input ve policy aynı base slug'ı üretmelidir. E-Ticaret Siteleri İçin Dinamik URL ve Slug Üretim Algoritmaları bu pipeline mantığıyla test edilebilir hale gelir.

Aşama 1 — Input Alma

Input genellikle ürün veya kategori başlığıdır. Ancak marka, model veya public ID gibi ek alanlar collision resolver tarafından kullanılabilir. Input null veya boş olabilir. Böyle durumlarda fallback policy gerekir. Raw input loglanırken kişisel veri veya gereksiz içerik saklanmamalıdır.

Aşama 2 — Unicode Normalization

Görsel olarak aynı karakter farklı Unicode kod dizileriyle temsil edilebilir. Önce NFC veya seçilen başka standarda normalize edilmelidir. Böylece eşdeğer string'ler aynı base slug'a yaklaşır. Collision check bundan sonra yapılmalıdır. Test seti composed ve decomposed karakterleri içermelidir.

Aşama 3 — Case Normalization

Slug çoğu sistemde küçük harfe dönüştürülür. Türkçe için locale-aware dönüşüm önemlidir. Büyük I ve İ karakterleri genel lowercase fonksiyonlarında beklenmeyen sonuç verebilir. Dil policy açık olmalıdır. Aynı uygulamanın frontend ve backend katmanları aynı kuralı kullanmalıdır.

Aşama 4 — Transliteration veya Encoding

Unicode karakterleri doğrudan korumak veya ASCII'ye çevirmek mümkündür. İki yaklaşım da teknik olarak uygulanabilir. Seçim bir kez yapılmalı ve tutarlı kalmalıdır. Migration sırasında eski URL'ler korunmalıdır. Locale plugin yapısı bu dönüşümü merkezileştirir.

Aşama 5 — Tokenization

Input anlamlı token'lara ayrılır. Boşluk, punctuation ve bazı semboller sınır olarak kullanılabilir. Semantik semboller doğrudan silinmeden önce özel mapping ile ele alınabilir. Tokenization Unicode aware olmalıdır. Birden fazla boşluk aynı sonucu üretmelidir.

Aşama 6 — Symbol Handling

+, &, % ve trademark gibi semboller policy'ye göre dönüştürülür veya kaldırılır. Samsung Galaxy S25+ örneğinde plus anlamı korunabilir. H&M gibi markada & işareti anlamsal değer taşıyabilir. Kör silme collision riskini artırabilir. Mapping listesi testlerle güvence altına alınmalıdır.

Aşama 7 — Separator Normalization

Tokenlar genellikle tire ile birleştirilir. Birden fazla ardışık tire tek tireye indirilmelidir. Baştaki ve sondaki tire kaldırılmalıdır. Farklı whitespace türleri aynı separator sonucuna dönüşmelidir. Separator policy bütün locale'lerde aynı olmayabilir ama route contract içinde açık olmalıdır.

Aşama 8 — Length Control

Slug sınırsız büyümemelidir. Karakter veya byte limiti belirlenebilir. Kesme kelime sınırında yapılmalıdır. Model numarası ve collision suffix korunmalıdır. Çok kısa truncation duplicate riskini yükseltebilir.

Aşama 9 — Reserved Word Check

admin veya api gibi sistem route'ları entity slug'ı olmamalıdır. Reserved list route registry ile ortak tutulabilir. Locale bazlı rezerve kelimeler de bulunabilir. Çakışma varsa disambiguator eklenmelidir. Hard-coded farklı listeler zamanla tutarsızlık üretir.

Aşama 10 — Collision Check

Base slug URL registry içinde aranır. Aynı namespace ve locale kapsamında current veya tombstone kayıt kontrol edilir. Application check hızlı ön kontrol sağlar. Nihai güvence database unique constraint'tir. Çakışma deterministik policy ile çözülmelidir.

Aşama 11 — Slug Reservation

Slug müsait görünse bile paralel worker aynı değeri seçebilir. Bu nedenle reservation transaction içinde yapılmalıdır. Unique index çatışmayı son noktada engeller. Failure durumunda deterministic alternate slug denenir. Retry sayısı sınırlı olmalıdır.

Aşama 12 — Persistence

Slug entity ile ilişkilendirilerek kalıcı olarak kaydedilir. Locale, current status ve created timestamp saklanabilir. URL registry current path'i ayrıca tutabilir. İlk oluşturma redirect history üretmemelidir. Sonraki değişiklikler audit ve redirect zincirine kaydedilir.

Slug Algorithm İçin Örnek Input–Output'lar

Slug algoritmasını yalnız teorik kurallarla değil golden test örnekleriyle tanımlamak daha güvenlidir. Her edge case beklenen output ile repository içinde saklanabilir. Böylece algoritma güncellendiğinde beklenmeyen URL değişiklikleri kolayca görülür. Türkçe karakter, sembol ve marka örnekleri mutlaka test edilmelidir. Golden set migration öncesi regression testinin temelidir.

Standart Ürün Adı

Standart ürün adı yalnız harf, sayı ve boşluk içerdiğinde pipeline basit çalışır. Lowercase uygulanır. Boşluklar tireye dönüşür. Gereksiz karakter bulunmaz. Sonuç deterministik biçimde aynı kalır.

Input: Nike Air Max 90 Beyaz

Bu input marka, model, numara ve renk bilgisi içerir. Tokenization kelimeleri doğal biçimde ayırır. Sayı korunmalıdır. Kelime sırası değiştirilmemelidir. Base slug collision yoksa doğrudan kullanılabilir.

Output: nike-air-max-90-beyaz

Output küçük harf ve tire separator kullanır. Model numarası korunmuştur. Kullanıcı URL'yi okuyarak ürünü kolayca anlayabilir. Slug tekrar üretildiğinde aynı sonuç çıkmalıdır. Ürün başlığı daha sonra değişse bile immutability policy nedeniyle current slug otomatik değişmeyebilir.

Türkçe Karakter

Türkçe input için ASCII ve Unicode olmak üzere iki geçerli politika vardır. Önemli olan aynı site içinde karışık davranmamaktır. Transliteration tablosu açık olmalıdır. Locale-aware lowercase önce uygulanmalıdır. Regression test iki politikanın da beklenen sonucunu doğrulamalıdır.

Input: Şık Çocuk Gömleği

Bu örnek ş, ı, ç, ö ve ğ karakterlerini aynı input içinde barındırır. Türkçe locale normalizasyonu uygulanmalıdır. General lowercase sonucu ayrıca test edilmelidir. Unicode ve ASCII policy farklı output üretir. Entity identity bu farktan bağımsız kalmalıdır.

ASCII politika: sik-cocuk-gomlegi

ASCII policy Türkçe harfleri latin karşılıklarına dönüştürür. URL klavyede yazılması daha kolay hale gelebilir. Transliteration deterministic olmalıdır. Eski Unicode URL'lerden geçiş yapılıyorsa 301 mapping gerekir. Mevcut site yalnız SEO amacıyla toplu migration yapmamalıdır.

Unicode politika: şık-çocuk-gömleği

Unicode policy karakterleri okunabilir biçimde korur. Modern tarayıcılar bu URL'leri destekler. Teknik olarak encoding arka planda uygulanabilir. İnsan tarafından kopyalandığında karakterler anlaşılır kalır. Bütün resolver ve cache katmanları aynı normalization standardını kullanmalıdır.

Sembol İçeren Ürün

Ürün isimlerinde +, &, %, ™ ve başka semboller bulunabilir. Bunların her biri aynı biçimde silinmemelidir. Anlam taşıyan sembol kelimeye dönüştürülebilir. Görsel veya hukuki işaret niteliğindeki bazı semboller kaldırılabilir. Policy markaya göre özel exception üretmemelidir; genel ve test edilebilir olmalıdır.

Input: Samsung Galaxy S25+

Bu input sonundaki + işareti ürün modelinin önemli parçasıdır. Sembolü silmek S25 ile S25+ arasında collision yaratabilir. Bu nedenle plus kelimesine dönüştürmek anlamı korur. Model numarası da aynen korunur. Böyle bir dönüşüm golden test setinde yer almalıdır.

Output: samsung-galaxy-s25-plus

Output model ayrımını açık biçimde korur. Kullanıcı ürünün plus sürümünü anlar. Sembol URL-safe kelimeye çevrilmiştir. Collision riski azalır. Aynı kural başka + işaretli modellerde de tutarlı çalışmalıdır.

Türkçe Karakterler Slug'da Nasıl Yönetilmelidir?

Türkçe karakterleri URL'de kullanmak teknik olarak mümkündür. ASCII transliteration da geçerli bir tasarım seçimidir. Burada kritik konu “hangi yaklaşım SEO açısından sihirli biçimde daha iyi?” sorusundan çok, hangi politikanın stabil ve tutarlı uygulanabileceğidir. Mevcut site yıllardır çalışan Unicode URL'lere sahipse yalnız görünüm için toplu değişiklik yapmak gereksiz migration riski yaratabilir. Yeni sistemde ise locale ve kullanıcı deneyimine göre bilinçli bir politika seçilebilir.

Unicode URL Yaklaşımı

Unicode yaklaşımı ş, ğ veya ü gibi karakterleri slug içinde korur. Kullanıcı açısından dilin doğal görünümünü muhafaza eder. Browser URL'yi gerektiğinde percent-encoding ile aktarabilir. Backend normalization ve lookup aynı Unicode formunu kullanmalıdır. Search engine tarafında temel sorun karakterin kendisi değil tutarlılıktır.

ASCII Transliteration Yaklaşımı

ASCII yaklaşımı Türkçe karakterleri c, g, i, o, s ve u gibi karşılıklara dönüştürür. Copy-paste ve bazı üçüncü taraf sistemlerde daha öngörülebilir görünüm sağlayabilir. Transliteration map açık biçimde tanımlanmalıdır. İ harfi ve I harfi locale-aware dönüşümden sonra işlenmelidir. Aynı slug generator bütün import kaynaklarında kullanılmalıdır.

Hangisi Daha İyi?

Mutlak olarak her site için tek doğru yaklaşım yoktur. Mevcut URL geçmişi, kullanıcı kitlesi ve entegrasyon sistemi karar üzerinde etkilidir. Yeni URL tasarlanırken teknik operasyon kolaylığı da dikkate alınmalıdır. Seçilen policy daha sonra sık sık değiştirilmemelidir. Stabilite çoğu durumda küçük biçim tercihinden daha değerlidir.

Bir Politika Seçip Tutarlı Kalmak

Tutarlılık duplicate ve migration riskini azaltır. Bir ürün Unicode, diğer ürün ASCII kuralla oluşturulmamalıdır. Locale plugin versionlanabilir. Policy değişirse URL diff testi çalıştırılmalıdır. Mevcut URL'ler için redirect ve rollout planı hazırlanmalıdır.

Türkçe Slug Dönüşüm Tablosu Nasıl Tasarlanır?

ASCII policy seçildiğinde karakter dönüşümleri merkezi bir transliteration tablosunda tutulmalıdır. Uygulamanın farklı noktalarında ayrı replace zincirleri yazmak uzun vadede hataya yol açar. Dönüşüm Unicode normalization sonrasında uygulanmalıdır. Büyük ve küçük harf davranışı locale-aware lowercase ile birlikte düşünülmelidir. Test seti her mapping için hem tek karakter hem gerçek kelime örneği içermelidir.

ç → c

Ç ve ç karakterleri normalizasyon sonrası c biçimine dönüştürülebilir. Bu dönüşüm Türkçe transliteration için yaygındır. “çocuk” kelimesi “cocuk” olur. Aynı mapping category ve product slug'larında kullanılmalıdır. Different service'lerin farklı output üretmesi engellenmelidir.

ğ → g

Ğ ve ğ karakterleri g ile temsil edilebilir. “gömleği” örneği bu dönüşümü gösterebilir. Kelimenin telaffuzunu birebir yansıtmak amaç değildir. Hedef stabil ASCII mapping üretmektir. Mapping değişikliği URL churn yaratabileceği için versionlanmalıdır.

ı → i

Noktasız ı ASCII policy'de i karakterine dönüştürülebilir. Bu adım locale-aware lowercase sonrasında uygulanmalıdır. Büyük I'nin önce doğru biçimde ı olması gerekir. Aksi halde aynı Türkçe kelime farklı slug üretebilir. Unit test özellikle İstanbul benzeri kelimeleri kapsamalıdır.

ö → o

Ö ve ö karakterleri o ile dönüştürülebilir. “gömlek” kelimesi “gomlek” biçimine gelir. Bu mapping oldukça öngörülebilirdir. Yine de Unicode normalization öncesi farklı code point dizileri bulunabilir. Generator tek normalization pipeline kullanmalıdır.

ş → s

Ş ve ş karakterleri s ile eşlenebilir. “Şık” kelimesi “sik” biçimine dönüşür. Bu output Türkçe anlam açısından farklı okunabilse de ASCII transliteration davranışının doğal sonucudur. Site böyle bir görünümü istemiyorsa Unicode policy seçebilir. Karar tasarım aşamasında verilmelidir.

ü → u

Ü ve ü karakterleri u biçimine dönüşür. “ürün” kelimesi “urun” haline gelir. Route namespace olarak zaten /urun/ kullanılıyorsa bu davranışla uyumludur. Mapping locale plugin içinde tek yerde tutulmalıdır. Golden test bu dönüşümü korumalıdır.

İ → i

Büyük noktalı İ Türkçe lowercase ile i olur. Genel lowercase bazı ortamlarda birleşik Unicode sonuç üretebilir. Bu nedenle normalization ve locale sırası önemlidir. “İstanbul” beklenen biçimde “istanbul” olmalıdır. Property-based test farklı Unicode temsillerini kontrol edebilir.

Türkçe Locale-Aware Lowercase Neden Önemlidir?

String lowercase işlemi basit görünse de Türkçe I ve İ karakterleri nedeniyle uygulama hatalarına açıktır. JavaScript, Java, .NET veya Python ortamlarında locale davranışı aynı olmayabilir. Backend ve import worker farklı sonuç üretirse slug collision veya lookup problemi doğabilir. Bu nedenle locale parametresi slug generator'ın açık girdilerinden biri olmalıdır. Türkçe e-ticaret URL'lerinde bu detay production güvenilirliği açısından önemlidir.

I → ı Problemi

Türkçede büyük I küçük harfe çevrildiğinde ı olur. İngilizce locale mantığı ise bunu i olarak yorumlayabilir. Bu fark kelimenin transliteration sonucunu değiştirebilir. Önce Türkçe lowercase, sonra ASCII mapping uygulanmalıdır. Test ortamı server locale'ine bağımlı olmamalıdır.

İ → i Problemi

Noktalı büyük İ küçük harfte i olur. Bazı generic Unicode işlemleri i ve combining dot şeklinde sonuç üretebilir. Görsel olarak aynı olsa da byte dizisi farklılaşabilir. NFC normalization bu noktada önem kazanır. Database unique constraint normalized değeri kullanmalıdır.

Genel Lowercase Fonksiyonlarının Riski

Default lowercase çalıştığı runtime locale'e bağlı sonuç verebilir. Environment değişince slug output değişmemelidir. Bu nedenle explicit locale kullanılmalıdır. Build machine ve production server aynı sonucu üretmelidir. Determinism ancak environment bağımsız olduğunda gerçek anlam taşır.

Locale-Aware Normalization

Slug generator locale değerini açıkça almalıdır. Önce Unicode normalization yapılabilir. Ardından locale-aware case conversion uygulanır. Transliteration bundan sonra gelir. Bu sıra test dokümanında standartlaştırılmalıdır.

Unicode Normalization Nedir?

Unicode aynı görünen karakterlerin farklı kod dizileriyle temsil edilmesine izin verir. Bu özellik kullanıcı açısından görünmez olabilir ancak database karşılaştırması ve hashing sırasında önemlidir. Slug generator eşdeğer metinleri aynı normalize forma dönüştürmelidir. NFC yaygın seçimlerden biridir. Collision kontrolü mutlaka normalization tamamlandıktan sonra yapılmalıdır.

Görsel Olarak Aynı Farklı Unicode Dizileri

Bir karakter tek code point veya base karakter artı combining mark ile temsil edilebilir. Kullanıcı ekranda fark görmez. Backend ise iki farklı string görebilir. Bu durum duplicate URL üretimine neden olabilir. Normalization iki temsili ortak forma getirir.

NFC

NFC mümkün olduğunda birleşik karakter formunu kullanır. Web ve veri işleme sistemlerinde yaygın tercih edilir. Slug generator girişte NFC uygulayabilir. Database'e normalized output yazılır. Test setinde decomposed input kullanılarak aynı sonuç doğrulanmalıdır.

NFD

NFD karakterleri ayrıştırılmış forma dönüştürür. Bazı text processing işlerinde faydalıdır. Transliteration sırasında combining mark kaldırmak için kullanılabilir. Ancak public slug storage için hangi formun seçildiği açık olmalıdır. Karışık NFC ve NFD kayıt tutulmamalıdır.

Collision Kontrolünden Önce Normalizasyon

Collision check raw input üzerinde yapılmamalıdır. Önce case, Unicode ve separator normalizasyonu tamamlanmalıdır. Aksi halde görsel olarak aynı iki slug farklı kabul edilebilir. Database unique index final normalized value üzerinde çalışmalıdır. Bu sıra algorithm invariant olarak test edilmelidir.

Slug'da Özel Karakterler Nasıl Yönetilmelidir?

Özel karakter yönetimi yalnız regex ile her şeyi silmek şeklinde tasarlanmamalıdır. Bazı semboller ürün modelinin veya marka adının anlamlı parçasıdır. Bazıları ise URL açısından değer taşımayan dekoratif karakterlerdir. Policy sınıflandırması yapmak daha sağlıklıdır. Her karar deterministic olmalı ve test setinde örneklenmelidir.

Noktalama

Nokta, virgül, iki nokta ve benzeri punctuation çoğunlukla separator veya removal olarak ele alınabilir. Ondalık sayı gibi özel durumlar incelenmelidir. Birden fazla punctuation tek tire üretmemelidir. Baştaki ve sondaki boş segmentler temizlenmelidir. Output her zaman normalize edilmelidir.

Tırnak İşaretleri

Tek ve çift tırnaklar çoğu slug'da kaldırılabilir. Akıllı tırnak ve Unicode varyantları da aynı policy'ye girmelidir. Apostrophe bulunan marka veya ürün adında kelimeler birleştirilebilir veya ayrılabilir. Seçim golden test ile sabitlenmelidir. Farklı klavyeler aynı sonucu üretmelidir.

Slash

Slash URL path separator olduğu için slug içinde ham biçimde kullanılmamalıdır. Input içindeki slash iki token arasında separator olarak ele alınabilir. Percent-encoded slash router davranışını bozabilir. Security açısından path traversal benzeri edge case'ler test edilmelidir. Slug yalnız tek path segmenti olarak güvenli kalmalıdır.

Backslash

Backslash farklı server ve framework'lerde farklı yorumlanabilir. Input'ta separator veya removable character olarak ele alınmalıdır. Raw URL path içinde tutulması önerilmez. Normalizer bunu açık biçimde temizlemelidir. Security testleri encoded varyantları da kapsamalıdır.

Emoji

Emoji ürün başlığında bulunabilir ancak slug için çoğu durumda gerekli değildir. Tamamen emoji olan input boş slug üretebilir. Böyle durumda fallback identifier kullanılmalıdır. Emoji kaldırıldıktan sonra separator normalization tekrar yapılmalıdır. Property-based testing geniş emoji kombinasyonlarını test edebilir.

Ticari Marka Sembolleri

™ ve ® gibi işaretler genellikle ürün kimliğinin ayırt edici parçası değildir. Slug'dan kaldırılabilir. Kaldırma sonucu iki ürün aynı slug'a düşerse collision resolver devreye girer. Marka adının kendisi korunmalıdır. Golden set Nike Air Max™ 90 benzeri örnekler içerebilir.

Semantik Sembol Dönüşümü

Bazı semboller ürün adında anlam taşır. + işareti ürün modelinde farklı versiyonu gösterebilir. & işareti marka adının parçası olabilir. % işareti kampanya veya ürün niteliğinde önemli olabilir. Bu sembolleri doğrudan silmek yerine semantic mapping tanımlamak collision ve anlam kaybını azaltır.

+ → plus

Plus işareti özellikle elektronik ürün modellerinde önemlidir. S25+ ile S25 aynı ürün değildir. “plus” kelimesine dönüşüm ayrımı korur. Locale policy isterse Türkçe başka karşılık seçebilir. Ancak bir kez seçilen mapping değiştirilmemelidir.

& → and / ve

& işareti marka veya ürün isminde ilişki anlamı taşıyabilir. H&M benzeri adlarda tamamen kaldırmak “hm” slug'ını üretebilir. “and” veya “ve” mapping seçilebilir. Locale bazlı farklılaşma canonical stratejisini etkileyebilir. Marka namespace içinde policy açık olmalıdır.

% → yuzde / percent

Yüzde işareti ürün açıklayıcı isminde anlam taşıyabilir. %100 Pamuk Tişört örneğinde “yuzde-100-pamuk-tisort” üretilebilir. Alternatif olarak sembol kaldırılıp yalnız 100 korunabilir. Hangi yaklaşım seçilirse golden test ile sabitlenmelidir. Çok dilli slug'larda locale mapping kullanılabilir.

Sembolleri Körü Körüne Silmenin Riskleri

İki farklı ürün adı aynı slug'a dönüşebilir. Model varyant bilgisi kaybolabilir. Marka anlamı bozulabilir. Collision sayısı gereksiz artabilir. Semantic mapping bu nedenle slug quality'nin önemli parçasıdır.

Tire Kullanımı Nasıl Normalize Edilmelidir?

Tire URL slug'larında yaygın separator'dır. Ancak raw input'ta boşluk, underscore, farklı dash karakterleri ve birden fazla separator bulunabilir. Hepsi ortak politika altında normalize edilmelidir. Duplicate tire bırakılmamalıdır. Slug separator ile başlamamalı veya bitmemelidir.

Space → Hyphen

Boşluklar tireye dönüştürülebilir. Normal space dışında tab ve non-breaking space gibi whitespace türleri dikkate alınmalıdır. Birden fazla boşluk tek separator üretmelidir. Tokenization bu davranışı merkezi hale getirir. Regex yalnız ASCII space'e bağlı kalmamalıdır.

Multiple Hyphen → Single Hyphen

Ardışık tireler tek tireye indirilmelidir. Input içinde hazır tire bulunabilir. Symbol removal sonrası yeni boşluklar oluşabilir. Final normalization aşaması bütün duplicate separator'ları temizler. Bu invariant property-based test ile kolayca doğrulanabilir.

Leading Hyphen'i Kaldırmak

Slug tire ile başlamamalıdır. Başta punctuation veya boşluk olduğunda böyle sonuç oluşabilir. Trim separator işlemi final pipeline'da uygulanmalıdır. Empty result ayrıca kontrol edilmelidir. Leading separator route readability'yi bozar.

Trailing Hyphen'i Kaldırmak

Slug sonunda tire bırakılmamalıdır. Symbol removal bu durumu oluşturabilir. Final trim işlemi deterministic olmalıdır. Redirect ve canonical farklı trailing biçimler üretmemelidir. Router mümkünse alternatif biçimi current URL'ye yönlendirebilir.

Stop Words Slug'dan Kaldırılmalı mı?

Stop word kaldırma eski SEO pratiklerinde sık kullanılmış olsa da her durumda faydalı değildir. Ürün adı kısa ise küçük kelimeleri çıkarmak anlamı bozabilir. Marka veya model isminde stop word görünümü taşıyan gerçek kelimeler olabilir. Slug uzunluğu kontrolü için seçici yaklaşım düşünülebilir. En güvenli politika, gereksiz müdahale yerine ürün adının anlamını korumaktır.

Her Durumda Kaldırmak Doğru mu?

Hayır. “ve”, “ile” veya “için” gibi kelimeler bazı ürün adlarında anlamlı olabilir. Otomatik silme iki farklı başlığı aynı slug'a dönüştürebilir. Kullanıcı okunabilirliği de etkilenebilir. Stop word policy kullanılıyorsa locale bazlı ve test edilmiş olmalıdır.

Anlam Değiştiren Kelimeler

Küçük kelimeler bazen ürünün kullanım amacını belirler. “çocuk için güneş kremi” örneğinde bazı kelimeleri silmek anlamı azaltabilir. SEO kazanımı varsayılarak semantik kayıp yapılmamalıdır. Ürün başlığı zaten editoryal olarak optimize edilmelidir. Slug generator minimum müdahale yapmalıdır.

Marka ve Model İsimleri

Marka veya model içinde stop word'e benzeyen kelime bulunabilir. Bunları silmek doğru değildir. Brand dictionary ile exception yazmak yerine stop word removal'ı sınırlı kullanmak daha sağlıklıdır. Model identifier her zaman korunmalıdır. Golden set gerçek marka örneklerini kapsamalıdır.

Dil Bazlı Stop Word Listesi

Birden fazla dil destekleniyorsa tek stop word listesi kullanılamaz. Locale farklı dil kuralları gerektirir. Liste versionlanmalıdır. Policy değişikliği mevcut slug'ları otomatik değiştirmemelidir. Yeni entity'lerde yeni version kullanılabilir.

Slug Uzunluğu Nasıl Belirlenmelidir?

Slug uzunluğu için search engine tarafından zorunlu tek sihirli sayı yoktur. Ama çok uzun ürün başlıklarını tamamen URL'ye taşımak okunabilirliği düşürür. Uygulama pratik bir karakter veya byte sınırı koyabilir. Kesme kelime sınırında yapılmalıdır. Model ve disambiguator gibi önemli parçalar korunmalıdır.

Sabit Karakter Limiti

Örneğin 80 veya 100 karakter gibi uygulama limiti seçilebilir. Limit iş kuralıdır, evrensel SEO standardı değildir. UTF-8 byte ve character farkı dikkate alınmalıdır. Çok dilli sistemde karakter bazlı limit daha anlaşılır olabilir. DB column genişliği güvenli marj taşımalıdır.

Word Boundary'de Kesme

Slug kelimenin ortasından kesilmemelidir. Maximum length aşılınca son tam token seçilebilir. Separator ile bitiş temizlenir. Model numarası sona yakınsa korunması için priority uygulanabilir. Truncation deterministik olmalıdır.

Model Numarasını Korumak

Ürün model numarası benzer ürünleri ayırt eder. Uzunluk kontrolü sırasında rastgele atılmamalıdır. Priority token olarak işaretlenebilir. Elektronik ve otomotiv gibi kategorilerde özellikle önemlidir. Collision sayısını da azaltır.

Benzersizlik Sonekini Korumak

Collision resolver eklediği public ID veya kısa suffix'i truncation sonrasında kaybetmemelidir. Önce base slug için maksimum uzunluk hesaplanabilir. Son bölüm suffix için rezerve edilir. Böylece final path unique kalır. Database constraint son doğrulamayı yapar.

Slug ile Product ID Birbirinden Ayrılmalı mı?

Evet, çoğu sağlam e-ticaret mimarisinde product ID ile slug farklı sorumluluklara sahiptir. ID kalıcı teknik kimliktir. Slug ise public presentation ve SEO katmanıdır. Ürün adı değişse bile ID değişmez. Bu ayrım redirect history ve çok dilli slug üretimini çok daha kolay hale getirir.

Kalıcı Entity ID

Entity ID veritabanında ürünün değişmez kimliğidir. Integer, UUID veya public identifier olabilir. İsim değişikliğinden etkilenmez. Integration sistemleri ID üzerinden eşleşebilir. URL resolver slug'dan entity ID'ye ulaşır.

Kullanıcı Dostu Slug

Slug entity'nin kullanıcıya gösterilen adres adıdır. Okunabilir ve lokalize olabilir. Current ve previous version'ları bulunabilir. Identity değil presentation özelliğidir. Bu yüzden manuel değişiklik mümkün olabilir.

Ürün Adı Değiştiğinde ID'nin Değişmemesi

Product rename aynı entity üzerinde yapılan editoryal değişikliktir. Database ID sabit kalmalıdır. External feed mapping korunur. Analytics entity continuity devam eder. Slug policy ise ayrı karar verir.

URL'nin Gerçek Kimliği Ne Olmalıdır?

URL'nin arkasındaki entity kimliği mümkün olduğunca editoryal metinden bağımsız olmalıdır. Database primary key veya public ID bu amaçla kullanılabilir. SKU bazı sistemlerde değişebilir veya business anlamı taşıdığı için tek kalıcı kimlik olmayabilir. UUID dağıtık sistemlerde avantaj sunabilir. Slug'ın tek identity olması rename ve locale yönetimini gereksiz zorlaştırır.

Database Primary Key

Internal integer primary key hızlı ve basittir. Public URL'de görünmek zorunda değildir. Application lookup için kullanılabilir. Sharding veya multi-region yapıda generation stratejisi değerlendirilmelidir. Public API'de ayrı ID kullanılabilir.

UUID

UUID distributed creation için uygundur. Tahmin edilmesi zor public identity sağlayabilir. URL içine eklendiğinde uzunluk ve okunabilirlik maliyeti vardır. Kısa encoded sürüm düşünülebilir. Collision çözümünde tamamını kullanmak çoğu zaman gerekmez.

SKU

SKU business identifier olarak değerlidir. Ancak bazı işletmelerde değişebilir. Aynı ürün varyantları ayrı SKU taşıyabilir. Public URL identity olarak kullanmadan önce lifecycle kuralları incelenmelidir. Slug suffix için kısa ve stabil parçası kullanılabilir.

Public Product ID

Internal primary key'i dışarı açmadan stabil public ID oluşturulabilir. Kısa ve URL-safe format seçilebilir. Slug collision durumunda suffix olarak kullanılabilir. Marketplace feed ve API aynı ID'yi kullanabilir. Rotation yapılmamalıdır.

Slug Neden Tek Kimlik Olmamalıdır?

Slug insan tarafından değiştirilebilir. Lokalize edilebilir. Başka entity ile collision yaşayabilir. Silinen URL tombstone olarak tutulabilir. Bu özellikler slug'ı primary identity için uygun olmayan bir değer haline getirir.

Slug Benzersizliği Nasıl Sağlanır?

Benzersizlik yalnız uygulama kodunda SELECT yapıp sonra INSERT etmekle sağlanmamalıdır. İki paralel request aynı slug'ı boş görebilir. Database unique constraint nihai güvence olmalıdır. Transaction ve retry mekanizması concurrency altında doğru davranışı sağlar. Namespace ve locale uniqueness kapsamının parçası olmalıdır.

Unique Constraint

Database current path veya slug üzerinde unique constraint tutmalıdır. Locale ve entity type compound key içinde olabilir. Tombstone kayıtlar da gerektiğinde aynı namespace'i rezerve eder. Constraint uygulama bug'larına karşı son güvenlik çizgisidir. Migration öncesi mevcut duplicate kayıtlar temizlenmelidir.

Application-Level Check

Application önceden slug availability kontrol edebilir. Kullanıcıya daha iyi hata veya öneri sunar. Ancak tek başına yeterli değildir. Check ile insert arasında race oluşabilir. Bu yüzden database sonucu authoritative kabul edilmelidir.

Database-Level Check

Insert veya reservation anında unique index kontrol edilir. Conflict alınırsa alternate slug üretilir. Transaction rollback yapılabilir. Error handling conflict türünü diğer database hatalarından ayırmalıdır. Metric olarak collision sayısı tutulabilir.

Transaction

Slug reservation ve entity create işlemi aynı transaction içinde olabilir. Bir adım başarısızsa yarım kayıt kalmaz. Uzun transaction'lardan kaçınılmalıdır. Deterministic retry güvenli olmalıdır. Isolation level kullanım modeline göre seçilebilir.

Aynı İsimli Ürünlerde Slug Nasıl Oluşturulur?

Aynı ürün adı e-ticarette son derece normaldir. Farklı marka, satıcı veya model aynı title'ı taşıyabilir. Sıralı -2, -3 suffix kolaydır fakat import sırasına bağımlı olabilir. Marka, model veya stabil public ID daha anlamlı disambiguator sağlayabilir. Seçim deterministik ve değişmez olmalıdır.

Marka Eklemek

Ürün adı markayı içermiyorsa collision durumunda brand token eklenebilir. Böylece okunabilirlik korunur. Brand değişikliği nadir olsa da lifecycle policy düşünülmelidir. Aynı marka içinde yine collision olabilir. Son fallback stabil ID olmalıdır.

Model Eklemek

Model number ürünleri güçlü biçimde ayırır. Elektronik ürünlerde özellikle faydalıdır. Base title zaten model içermiyorsa suffix olarak eklenebilir. Model alanı değişken değilse stabil sonuç verir. Import kaynaklarındaki format normalize edilmelidir.

Kısa SKU Eklemek

SKU stabil ise kısa bir bölümü collision çözümünde kullanılabilir. Kullanıcı için teknik görünüm artabilir. SKU değişebiliyorsa URL churn riski vardır. Public görünürlük policy'si değerlendirilmelidir. Tam SKU yerine deterministic short form kullanılabilir.

Kısa Public ID Eklemek

Public ID en güvenilir fallback seçeneklerinden biridir. Entity lifecycle boyunca değişmez. Collision olasılığı çok düşüktür. URL biraz daha teknik görünür ama determinism sağlar. Kısa encode edilmiş değer tercih edilebilir.

Slug Collision Resolution Algorithm

Collision resolver açık ve tekrar edilebilir adımlara sahip olmalıdır. Base slug oluşturulur ve registry'de kontrol edilir. Boşsa atomic biçimde rezerve edilir. Doluysa stabil disambiguator eklenir. Sonuç tekrar unique constraint üzerinden doğrulanır.

Base Slug Oluştur

Normalizer başlık üzerinden base slug üretir. Locale ve transliteration policy uygulanır. Reserved word kontrolü yapılır. Length limit gözetilir. Bu aşama database state'inden bağımsızdır.

Registry'de Kontrol Et

URL registry aynı namespace ve locale içinde sorgulanır. Current, redirect source ve tombstone kayıtlar kontrol edilebilir. Lookup index üzerinden hızlı olmalıdır. Cache kullanılabilir ama authoritative sonuç database'dir. Soft-deleted kayıt policy'ye göre müsait sayılmamalıdır.

Boşsa Rezerve Et

Slug atomic insert veya reservation ile tutulur. Application “boş gördüm” sonucuna güvenmez. Unique index reservation'ı doğrular. Transaction entity kaydıyla ilişkilendirilebilir. Başarılı reservation final slug'ı belirler.

Doluysa Deterministic Disambiguator Ekle

Public ID veya stabil model bilgisi kullanılabilir. Suffix aynı entity için her environment'ta aynı olmalıdır. Import sırası sonucu değiştirmemelidir. Truncation suffix alanını korumalıdır. Yeni candidate yeniden normalize edilmemelidir.

Tekrar Kontrol Et

İkinci candidate yine constraint üzerinden denenir. Çok düşük olasılıklı collision için fallback bulunmalıdır. Infinite loop engellenmelidir. Retry count metric tutulabilir. Başarısızlık manual review queue'ya yönlendirilebilir.

-2, -3, -4 Sonekleri Kullanılmalı mı?

Sıralı numeric suffix kullanmak basit ve kullanıcı tarafından kolay anlaşılır. Ancak büyük import sistemlerinde entity'nin hangi suffix'i alacağı creation sırasına bağlı olabilir. Test, staging ve production farklı sonuç üretebilir. Eğer bu risk kabul ediliyorsa yöntem kullanılabilir. Daha yüksek determinism gerektiğinde stabil identifier suffix daha güvenlidir.

Avantajları

Uygulaması kolaydır. URL kısa kalır. Kullanıcı için okunabilir görünür. Küçük kataloglarda pratik olabilir. Database unique constraint ile güvenli hale getirilebilir.

Import Sırasına Bağımlılık

İlk gelen entity base slug'ı alır. İkinci entity -2 alır. Import sırası değişirse sonuç değişebilir. Environment'lar arasında URL mismatch oluşabilir. Büyük migration projelerinde bu ciddi problem yaratabilir.

Nondeterministic Sonuç Riski

Parallel worker scheduling sonucu suffix sırası değişebilir. Aynı dataset yeniden import edildiğinde farklı slug'lar oluşabilir. Idempotency zorlaşır. URL regression test daha çok değişiklik gösterir. Stabil public ID bu problemi azaltır.

Stabil Identifier Alternatifi

Collision durumunda kısa public ID eklenebilir. Aynı entity her zaman aynı suffix'i alır. Import sırasından bağımsızdır. Test edilebilirlik artar. URL biraz daha teknik görünse de yaşam döngüsü güvenilir hale gelir.

Deterministik Slug Nedir?

Deterministik slug aynı girdiler ve policy ile her zaman aynı sonucu üretir. Environment veya import sırası sonucu değiştirmemelidir. Bu özellik CI testleri ve bulk import açısından büyük avantaj sağlar. Deterministic base slug ile deterministic collision resolver birlikte düşünülmelidir. Sadece normalizer deterministik olup suffix random ise sistemin tamamı deterministik sayılmaz.

Aynı Entity → Aynı Slug

Entity verisi değişmedikçe slug sonucu aynı kalmalıdır. Idempotent import bunu kolaylaştırır. Random suffix kullanılmamalıdır. Public ID sabit kalmalıdır. Cache invalidation daha öngörülebilir hale gelir.

Environment Bağımsızlığı

Development ve production aynı input için aynı output üretmelidir. Server locale veya framework version davranışı kontrol edilmelidir. Transliteration map repository içinde versionlanmalıdır. Database collation farkları test edilmelidir. CI golden set bu garantiyi sağlar.

Import Sırası Bağımsızlığı

Aynı katalog farklı sıra ile işlendiğinde slug değişmemelidir. Numeric increment stratejisi bu özelliği bozabilir. Public ID based suffix güçlü alternatiftir. Bulk import parallel yapılabilir. Re-run sonucu redirect üretmemelidir.

Test Edilebilirlik

Deterministic algoritma snapshot ve unit test için idealdir. Input-output table saklanabilir. Version upgrade öncesi diff görülebilir. Bug kolay reproduce edilir. Production değişikliği release öncesi tahmin edilebilir.

Slug Oluştururken Race Condition Nasıl Önlenir?

Race condition, iki paralel işlem aynı slug'ı aynı anda seçtiğinde ortaya çıkar. Application-level existence check bu problemi çözmez. Database unique index zorunludur. Transaction ve conflict retry tasarımın parçası olmalıdır. High-volume import sistemlerinde bu davranış mutlaka load test edilmelidir.

Paralel Product Creation

İki worker aynı ürün adına sahip kayıt oluşturabilir. İkisi de availability check'te boş sonuç görebilir. Sonraki insert'lerden biri conflict almalıdır. Worker alternate deterministic slug üretir. Error business failure yerine expected concurrency event olarak yönetilebilir.

Unique Index

Unique index final path üzerinde yarışmayı çözer. Database tek owner kuralını enforce eder. Composite index locale ve namespace içerebilir. Redirect source'ları ayrı tablo kullanıyorsa ayrıca uniqueness gerekir. Index health monitoring yapılmalıdır.

Transaction

Reservation ve entity create transaction içinde koordine edilebilir. Conflict olduğunda rollback yapılır. Retry yeni deterministic candidate kullanır. Transaction gereğinden uzun tutulmamalıdır. Bulk worker database connection pool'u tüketmemelidir.

Retry

Retry yalnız unique conflict gibi beklenen durumda çalışmalıdır. Aynı candidate sonsuz tekrar edilmemelidir. Deterministic next candidate üretilmelidir. Retry count sınırlandırılmalıdır. Yüksek collision rate observability dashboard'da görünmelidir.

Reserved Slug Nedir?

Reserved slug uygulamanın sistem route'larıyla çakışmaması gereken kelimedir. /admin veya /api gibi adresler ürün slug'ı olarak kullanılırsa routing ambiguity oluşabilir. Reserved registry merkezi tutulmalıdır. Entity type ve locale bazında farklı listeler bulunabilir. Yeni sistem route'u eklenirken mevcut public URL'lerle conflict analizi yapılmalıdır.

Sistem Route'ları

Framework ve uygulama tarafından kullanılan route'lar public entity namespace'inden korunmalıdır. Liste manuel dokümandan ibaret kalmamalıdır. Route registry üzerinden otomatik test üretilebilir. Deployment öncesi reserved collision kontrol edilir. Existing product path yeni sistem route'u nedeniyle bozulmamalıdır.

admin

admin yönetim paneli için yaygın route ismidir. Product slug olarak rezerve edilmemelidir. Admin panel farklı subdomain'de olsa bile future-proof yaklaşım değerlidir. Reserved list test edilmelidir. Case-insensitive normalization sonrasında da conflict kontrolü yapılmalıdır.

api

api backend endpoint namespace'i olarak sık kullanılır. Public ürün path'i ile karışmamalıdır. Versioned /api/v1 route'ları ayrıca dikkate alınmalıdır. Router precedence bug'ları production sorunu yaratabilir. Reserved registry yeni endpoint eklenirken güncellenmelidir.

cart

cart sepet route'u olarak kullanılabilir. Kategori veya ürün slug'ı olmamalıdır. Locale route kullanılıyorsa karşılıkları ayrıca düşünülmelidir. Public namespace farklıysa risk azalır. Yine de central registry en güvenli yaklaşımdır.

checkout

checkout satın alma akışının kritik route'udur. Entity slug ile collision yaşamamalıdır. Security ve conversion açısından yanlış routing kabul edilemez. Reserved path kesin constraint olarak tutulabilir. Import sırasında hata yerine alternate slug üretilmelidir.

login

login authentication route'u olarak yaygındır. Ürün veya marka slug'ı buna dönüşebilir. Reserved check alternate slug üretmelidir. Localization login path'ini değiştirebilir. Registry locale-aware olabilir.

account

account kullanıcı hesap alanını temsil edebilir. Public product namespace ile karıştırılmamalıdır. Router resolution sırası açık olmalıdır. Reserved path tombstone gibi kalıcı korunabilir. Test suite route shadowing durumunu kontrol etmelidir.

Reserved Slug Registry

Reserved kelimeler tek config veya data source içinde tutulmalıdır. Framework adapter bu listeden yararlanabilir. New route deployment sırasında registry update edilir. CI mevcut entity URL'leriyle conflict taraması yapabilir. Böylece runtime routing sürprizleri azalır.

Silinen Bir Ürünün Slug'ı Yeniden Kullanılmalı mı?

Silinen ürünün URL'si search index, backlink ve kullanıcı bookmark'larında yaşamaya devam edebilir. Aynı slug başka ürüne verilirse eski bağlantılar yeni ve ilgisiz içeriğe gider. Bu durum kullanıcı ve SEO açısından yanlış sinyal oluşturur. Bu nedenle public slug'ı belirli süre veya kalıcı olarak tombstone şeklinde rezerve etmek daha güvenlidir. Ürün lifecycle policy bu davranışı açıkça tanımlamalıdır.

Backlink Riski

Başka siteler eski ürün URL'sine link vermiş olabilir. Slug yeni ürüne verilirse backlink yanlış entity'ye aktarılır. 410 veya uygun alternatif redirect daha sağlıklıdır. Slug tombstone bunu engeller. Backlink değeri ürün değişikliği bahanesiyle rastgele taşınmamalıdır.

Eski Bookmark

Kullanıcı URL'yi kaydetmiş olabilir. Aylar sonra geri geldiğinde farklı ürün görmek güven kaybı yaratır. Eski bookmark 410 veya ilgili replacement ürün sayfasına kontrollü redirect alabilir. Decision business policy ile belirlenir. Reuse en riskli seçenektir.

Search Index

Search engine eski URL'yi bir süre indeksinde tutabilir. Yeni entity aynı path'i aldığında içerik kimliği karışır. Crawl history yeni ürüne aktarılabilir. Tombstone identity continuity'yi korur. Sitemap eski URL'yi yayınlamamalıdır.

Slug Tombstone

Tombstone silinen path'in artık yeni entity'ye atanamayacağını gösterir. Status field ile URL registry'de tutulabilir. 410 veya redirect davranışı bağlanabilir. Retention politikası belirlenebilir. Büyük kataloglarda storage maliyeti genellikle düşüktür.

Slug Tombstone Nedir?

Slug tombstone, artık aktif entity'ye ait olmayan fakat geçmişte public olarak kullanılmış URL'nin rezerve tutulmasıdır. Amaç path ownership geçmişini kaybetmemektir. Tombstone redirect veya 410 davranışı taşıyabilir. Yeni entity bu path'i alamaz. URL yaşam döngüsünü güvenilir hale getiren önemli bir veri modelidir.

Silinen URL'yi Rezerve Etmek

URL registry status deleted veya tombstone olabilir. Unique path constraint devam eder. Yeni create işlemi bu kaydı occupied kabul eder. Admin gerekirse özel migration ile override yapabilir. Normal uygulama akışı otomatik reuse yapmamalıdır.

410 Davranışı

İçerik kalıcı olarak kaldırıldı ve uygun replacement yoksa 410 kullanılabilir. Bu durum kaynağın artık mevcut olmadığını açıkça ifade eder. Kullanıcıya yardımcı alternatifler sayfada gösterilebilir. HTTP status gerçek 410 olmalıdır. Soft 404 davranışından kaçınılmalıdır.

Redirect Davranışı

Eski ürünün gerçek replacement veya birleşmiş yeni entity'si varsa redirect kullanılabilir. Target semantik olarak ilgili olmalıdır. Ana kategoriye toplu redirect her durumda doğru değildir. Redirect reason history'de saklanabilir. Chain oluşmaması için final target'a yönlendirilmelidir.

Yeniden Kullanımı Engellemek

Tombstone unique ownership kuralını sürdürür. Bulk import aynı title ile yeni ürün getirirse disambiguator eklenir. Eski path başka entity'ye verilmez. Bu davranış test edilmelidir. URL registry migration sırasında tombstone kayıtlarını korumalıdır.

Ürün Adı Değiştiğinde Slug Otomatik Değişmeli mi?

Çoğu durumda hayır. Ürün başlığı merchandising veya editoryal sebeplerle sık değişebilir. URL'nin her değişiklikte güncellenmesi gereksiz churn oluşturur. Slug varsayılan olarak immutable tutulabilir. Manuel veya bilinçli SEO değişikliği yapıldığında redirect history oluşturulmalıdır.

SEO Stabilitesi

Stabil URL backlink değerini korur. Search engine sürekli yeni adres keşfetmek zorunda kalmaz. Analytics trendleri aynı URL altında devam eder. Product rename URL migration'a dönüşmez. Bu nedenle isim ve URL lifecycle'ı ayrılmalıdır.

Editoryal Başlık ile URL Kimliğini Ayırmak

Başlık kullanıcıya gösterilen pazarlama metnidir. Slug ise public routing identifier'dır. Başlık güncellendiğinde slug'ın otomatik değişmemesi bu ayrımı korur. Admin panel iki alanı ayrı gösterebilir. Kullanıcı slug değişikliğinin redirect oluşturacağını görebilir.

Explicit Slug Update

Slug ancak bilinçli action ile değiştirilebilir. Yetkili kullanıcı nedeni seçebilir. Sistem preview URL ve redirect planını gösterebilir. Commit işleminde history kaydı oluşturulur. Audit değişikliği kimin yaptığını saklayabilir.

Slug Immutability Policy

Slug immutability, oluşturulan public URL'nin varsayılan olarak değişmemesi ilkesidir. Bu yaklaşım e-ticaret kataloglarında URL churn'ü ciddi biçimde azaltır. Ürün başlığı ve kategori ataması değişebilir. URL ancak açık bir kullanıcı veya migration işlemiyle değiştirilir. Her değişiklik otomatik redirect ve history üretir.

Ürün Başlığı Değişebilir

Merchandising ekipleri title'ı sık düzenleyebilir. Kampanya kelimesi eklenebilir veya çıkarılabilir. Ürün özellikleri güncellenebilir. Bunların hiçbiri otomatik URL değişikliği gerektirmez. Slug bağımsız alan olarak kalır.

Slug Varsayılan Olarak Sabit Kalır

Current slug create sırasında belirlenir. Normal product update event'i slug generator'ı çağırmaz. Böylece yanlışlıkla binlerce redirect oluşmaz. API contract bu davranışı açıkça belirtmelidir. Regression test URL snapshot ile doğrulanabilir.

Kullanıcı Manuel Değişiklik İsteyebilir

SEO veya editoryal gerekçeyle değişiklik gerekebilir. Admin kullanıcı explicit action seçer. Yeni slug collision ve reserved kontrolünden geçer. Preview gösterilebilir. Permission ile sınırlandırılabilir.

Değişiklik Redirect Oluşturur

Eski current path history'ye taşınır. Yeni path current olur. Eski path 301 ile doğrudan yeni current path'e gider. Sitemap yalnız yeni URL'yi içerir. Internal link resolver yeni adresi üretir.

Slug History Nasıl Tutulur?

Slug history URL'nin zaman içindeki değişimlerini kaydeder. Bu kayıt redirect üretimi ve audit için önemlidir. Sadece bir previous_slug kolonu uzun değişiklik zincirleri için yeterli değildir. Ayrı history tablosu daha esnek olur. Her eski path final target ile ilişkilendirilebilir.

Current Slug

Current slug entity'nin bugün kullanılan public slug'ıdır. URL registry içinde unique olmalıdır. Sitemap bu değeri kullanır. Internal link helper aynı current değeri alır. Admin panelde açıkça gösterilmelidir.

Previous Slug

Previous slug geçmişte kullanılan değerdir. Bir entity birden fazla previous slug taşıyabilir. Bu nedenle child history kayıtları tercih edilir. Her previous path redirect source olabilir. Reuse engellenmelidir.

Changed At

Değişiklik timestamp'i audit ve migration analizi sağlar. URL churn trendi bu veri üzerinden ölçülebilir. Deployment ile ilişki kurulabilir. Unexpected toplu değişiklik hızla fark edilir. Timezone standardı kullanılmalıdır.

Redirect Target

Eski path doğrudan current final path'e yönlenmelidir. Intermediate slug target olarak tutulmamalıdır. Slug yeniden değiştiğinde tüm geçmiş kaynaklar yeni target'a güncellenebilir. Böylece chain oluşmaz. Redirect graph flattening otomatik job olabilir.

Reason

Değişiklik nedeni rename, manual SEO, category migration veya bug fix gibi değerlerle saklanabilir. Observability için faydalıdır. Unexpected churn hangi nedenle oluştuğu görülür. Admin action audit edilebilir. Enum kullanımı raporlamayı kolaylaştırır.

Slug Değişikliğinde 301 Redirect Nasıl Oluşturulur?

Slug değişikliği eski public adresi geçersiz hale getirir. Eski URL semantik olarak aynı entity'nin yeni URL'sine kalıcı biçimde taşınıyorsa 301 uygun davranıştır. Redirect server veya edge seviyesinde uygulanabilir. History table authoritative mapping sağlamalıdır. Dinamik URL değişikliklerinde canonical 301 yönlendirme ve duplicate content yönetimi aynı resolver yaklaşımına bağlanmalıdır.

Eski URL

Eski URL redirect source olarak kayıt edilir. Başka entity tarafından sahiplenilemez. Sitemap'ten çıkarılır. Internal linklerde kullanılmaz. Search engine hit'leri loglarda izlenebilir.

Yeni URL

Yeni URL current canonical path olur. Unique constraint ile doğrulanır. Sitemap ve feed güncellenir. Canonical tag kendisini gösterir. Internal link helper yalnız bu adresi üretir.

Permanent Redirect

301 kalıcı adres değişikliğini ifade eder. Browser ve crawler yeni location'a yönelir. Route handler history registry üzerinden target bulabilir. Cache-Control policy trafik yapısına göre ayarlanabilir. Redirect response body gereksiz ağır olmamalıdır.

Search Engine Signal Transfer

301 eski URL'nin sinyallerinin yeni adrese aktarılmasına yardımcı olur. Bunun kusursuz ve anında olacağı varsayılmamalıdır. İç link ve sitemap da yeni URL'ye güncellenmelidir. Redirect chain azaltılmalıdır. Migration sonrası crawl ve indexing monitoring yapılmalıdır.

Redirect Chain Nasıl Önlenir?

Bir URL birkaç kez değiştiğinde A'dan B'ye, B'den C'ye zincir oluşabilir. Kullanıcı sonunda C'ye ulaşsa da gereksiz ekstra request oluşur. Search engine açısından da daha temiz mapping doğrudan A'dan C'ye gitmektir. History table final target'a güncellenmelidir. Redirect graph flattening deployment veya background maintenance sürecinde çalıştırılabilir.

A → B

İlk slug değişikliğinde eski A path'i B'ye yönlenir. Bu aşamada mapping doğrudur. History kaydı entity ile ilişkilidir. B current path olur. Later change durumunda kayıt güncellenmelidir.

B → C

İkinci slug değişikliğinde B eski olur ve C current olur. B doğrudan C'ye yönlenir. A'nın hâlâ B'ye gitmesi chain oluşturur. Resolver entity ID üzerinden final current path'i bulabilir. Bu tasarım chain'i doğal olarak azaltır.

A'yı Doğrudan C'ye Güncellemek

History record target path yerine entity ID tutarsa final URL runtime'da hesaplanabilir. Alternatif olarak materialized target update yapılabilir. Her iki yöntemde A doğrudan C'ye gider. Redirect hop sayısı bir olur. Test suite maximum hop kuralını kontrol edebilir.

Redirect Graph Flattening

Tüm redirect kaynakları final current target'a bağlanır. Cycle detection aynı süreçte yapılabilir. Batch job değişiklik sonrası çalıştırılabilir. Graph çok büyükse incremental update tercih edilebilir. URL quality dashboard chain count göstermelidir.

Redirect Loop Nasıl Önlenir?

Redirect loop iki veya daha fazla URL'nin birbirine sürekli yönlenmesi durumudur. Kullanıcı sayfaya ulaşamaz. History validation yeni mapping kaydedilmeden önce cycle kontrolü yapmalıdır. Entity current path hiçbir zaman historical source'a dönmemelidir. Deployment testleri redirect graph üzerinde otomatik cycle detection çalıştırabilir.

Cycle Detection

Redirect graph directed graph olarak değerlendirilebilir. DFS veya visited-set yaklaşımı loop tespit edebilir. Yeni edge eklenmeden önce target path zinciri takip edilir. Source'a geri dönüyorsa işlem reddedilir. Büyük registry için offline validation da çalıştırılabilir.

Slug History Validation

History kaydı aynı entity içinde mantıksal sıra taşımalıdır. Current path eski source listesinde bulunmamalıdır. Başka entity'ye yanlış mapping engellenmelidir. Foreign key ve application validation birlikte kullanılabilir. Admin manual değişiklikleri de aynı kurallardan geçmelidir.

Deployment Testleri

URL snapshot üzerinde tüm redirect'ler crawl edilebilir. Maximum redirect hop kontrol edilir. Loop bulunduğunda deployment durdurulabilir. HTTP status ve Location header doğrulanır. Production sonrası synthetic monitoring ek güvence sağlar.

Ürün URL'sinde Kategori Bulunmalı mı?

Ürün URL'sine kategori path'i eklemek kullanıcıya bağlam sağlar ancak kategori lifecycle'ını ürün URL'sine bağlar. Kategori değiştiğinde ürün URL'si de değişebilir. Kategoriden bağımsız /urun/{slug} yapısı daha stabil olur. Her iki yaklaşımın fayda ve maliyeti vardır. Büyük kataloglarda URL stabilitesi çoğu zaman daha önemli hale gelir.

Kategorili URL

Kategorili yapı ürünün taxonomy bağlamını URL'de gösterir. Breadcrumb ile uyumlu görünebilir. Ancak kategori move binlerce ürün URL'sini değiştirebilir. Bir ürün birden fazla kategorideyse canonical seçimi gerekir. Recursive category path bakım maliyetini yükseltir.

/ayakkabi/spor/nike-air-max

Bu URL kullanıcıya hiyerarşi hakkında bilgi verir. Ancak spor kategorisi başka parent'a taşınırsa adres değişebilir. Ürün başka kategoride de görünüyorsa alternatif path oluşabilir. Tek canonical belirlemek gerekir. Internal navigation path ile public product identity ayrılabilir.

Kategoriden Bağımsız URL

/urun/{slug} yapısı ürün kimliğini taxonomy'den ayırır. Category move URL'yi değiştirmez. Multi-category ürünlerde duplicate path riski azalır. Breadcrumb yine navigation context'ten üretilebilir. Büyük ve sık değişen kataloglarda bu yaklaşım yönetimi kolaylaştırır.

/urun/nike-air-max

Bu yapı kısa ve stabildir. Product namespace routing collision'ını azaltır. Kategori değişikliği URL'yi etkilemez. Sitemap ve feed aynı current path'i kullanır. Ürün slug'ı collision durumunda model veya public ID ile ayrıştırılabilir.

İki Yaklaşımın Trade-Off'ları

Kategorili URL bağlam sağlar ama lifecycle coupling yaratır. Kategorisiz URL daha stabildir ama taxonomy path görünmez. Breadcrumb ve schema ile kategori bağlamı yine sunulabilir. Migration maliyeti mevcut sitenin yapısına bağlıdır. Yeni sistemde ürün lifecycle sıklığı önemli karar kriteridir.

Ürün Kategori Değiştirirse URL Ne Olmalı?

Category-coupled route kullanılıyorsa kategori değişikliği product path'i de değiştirebilir. Bu durumda toplu 301 redirect gerekir. Binlerce ürün için bu işlem önemli migration maliyeti yaratır. Stable product route bu problemi ortadan kaldırır. Product manager ve SEO ekibi category move politikasını önceden tanımlamalıdır.

Category-Coupled URL

Ürün path'i parent category'den hesaplanır. Taxonomy değiştiğinde computed URL değişir. Bu model operasyonel olarak hassastır. Slug history tek başına yetmez çünkü parent path de değişmiştir. URL registry full path history tutmalıdır.

URL Değişikliği

Category move event'i etkilenen ürünleri hesaplar. Yeni path unique ve reserved kontrolünden geçer. Eski path history'ye taşınır. Sitemap ve internal link cache invalidate edilir. Search regression testi çalıştırılır.

301 Redirect

Eski product URL yeni current URL'ye 301 verir. Chain oluşturulmamalıdır. Mapping bulk job ile hazırlanabilir. CDN cache doğru invalidation almalıdır. Server log Googlebot eski URL hit'lerini gösterebilir.

Stable Product URL Alternatifi

Ürün /urun/{slug} altında tutulursa category move yalnız breadcrumb ve category listing'i etkiler. Product URL aynı kalır. Redirect ihtiyacı oluşmaz. Analytics continuity korunur. Bu yaklaşım büyük kataloglarda güçlü avantaj sağlar.

Aynı Ürün Birden Fazla Kategorideyse Ne Olmalı?

Bir ürün birden fazla navigation kategorisinde görünebilir. Bu durum aynı ürün için birden fazla canonical URL üretmeyi gerektirmez. Tek product URL seçilmelidir. Category listing'ler aynı adresi linklemelidir. Breadcrumb kullanıcının geldiği navigation context'e göre dinamik olabilir.

Tek Canonical Product URL

Entity ID tek current canonical path'e sahip olur. Category listeleri aynı URL resolver'ı çağırır. Sitemap tek adres yayınlar. Marketplace feed aynı canonical URL'yi kullanır. Duplicate product path oluşturulmaz.

Birden Fazla Navigation Path

Kullanıcı ürün sayfasına farklı kategorilerden gelebilir. Navigation path session veya referrer context ile korunabilir. Public product URL değişmez. Breadcrumb gerektiğinde source category bilgisi kullanabilir. Canonical yine tek kalır.

Breadcrumb

Breadcrumb taxonomy bağlamını gösterir. URL'nin kategori içermesi zorunlu değildir. Structured data içinde breadcrumb path sunulabilir. Multi-category durumda primary category veya navigation context seçilebilir. Business policy açık olmalıdır.

İç Linkleme

Tüm category cards current product URL'yi kullanmalıdır. Elle string birleştirilmemelidir. Locale-aware URL helper çağrılmalıdır. Eski slug internal linklerde bırakılmamalıdır. Redirect üzerinden iç link verme kısa vadede bile azaltılmalıdır.

Kategori Slug'ları Nasıl Üretilmelidir?

Kategori slug'ı ürün slug'ına benzer normalizasyon kullanabilir ancak hiyerarşi ve namespace davranışı farklıdır. Parent category path içinde yer alıyorsa collision kapsamı sibling seviyesinde olabilir. Flat /kategori/{slug} yapısında global category namespace gerekir. Category name değişimi otomatik slug değişikliği yapmak zorunda değildir. Taxonomy operasyonları redirect politikasına bağlanmalıdır.

Category Name

Base slug category name üzerinden üretilebilir. Locale-aware normalization uygulanır. Editoryal isim değişikliğinde slug policy ayrı çalışır. Category title ve slug bağımsız alan olabilir. Admin manual override desteklenebilir.

Parent Category

Recursive path kullanılıyorsa parent current path category URL'nin parçasıdır. Parent move child URL'leri etkileyebilir. Bu coupling açıkça kabul edilmelidir. Flat route alternatif olabilir. Parent ID yine entity ilişkisi olarak tutulmalıdır.

Namespace

/kategori/ prefix category slug'larını diğer entity türlerinden ayırır. Aynı slug product ve brand içinde tekrar kullanılabilir. Database uniqueness entity type ve locale bazında tanımlanabilir. Routing daha basit hale gelir. Reserved words yine category namespace için kontrol edilmelidir.

Collision

Aynı isimli category farklı parent'larda bulunabilir. Recursive path zaten doğal ayrım sağlayabilir. Flat namespace'de public ID veya parent token eklenebilir. Numeric increment determinism açısından değerlendirilmelidir. Unique constraint son kararı enforce eder.

Kategori Taşındığında Slug Nasıl Yönetilir?

Kategori move, yalnız taxonomy ilişkisi değil public URL değişikliği anlamına gelebilir. Parent path URL'ye dahilse category ve bütün child path'leri etkilenebilir. Bu nedenle taxonomy araçları URL impact preview göstermelidir. Binlerce redirect tek işlemde oluşabilir. Stable category route veya ID based path bazı sistemlerde bu riski azaltabilir.

Parent Değişikliği

Category parent ID değişir. Eğer URL recursive ise computed path de değişir. Impacted descendants hesaplanmalıdır. Move transaction doğrudan binlerce sync update yapmamalıdır. Background migration job kullanılabilir.

Path Değişikliği

Yeni parent current path üzerinden category path yeniden hesaplanır. Collision kontrol edilir. Old path history'ye alınır. Child paths policy'ye göre güncellenir. URL diff deployment öncesi üretilmelidir.

Redirect

Eski category path yeni current path'e 301 verir. Child old paths de final current target'a yönlenir. Chain flattening uygulanır. Sitemap yalnız yeni path'leri içerir. Server log move sonrası crawl davranışını izler.

Child URL Etkisi

Recursive modelde tek parent değişikliği binlerce child URL'yi değiştirebilir. Bu önemli SEO ve operasyon maliyetidir. Product URL category independent ise ürünler etkilenmez. Category descendants yine değişebilir. Taxonomy depth mimari kararını doğrudan etkiler.

Recursive Category URL'nin Riskleri

Recursive category URL hiyerarşiyi açık biçimde gösterir fakat taxonomy değişikliğini URL migration'a dönüştürür. Derin path okunabilirliği azaltabilir. Bir parent move büyük redirect listesi oluşturabilir. Bu durum özellikle merchandising yapısının sık değiştiği e-ticaret sitelerinde önemlidir. Stable category ID veya flat namespace alternatifleri değerlendirilmelidir.

Derin Path

Beş veya altı level category uzun URL üretir. Kullanıcı için okunabilirlik düşer. Router ve breadcrumb daha fazla segment işler. Slug collision farklı seviyelerde oluşabilir. Maximum public depth policy belirlenebilir.

Kategori Yeniden Yapılandırması

Taxonomy business ihtiyaçlarına göre sık değişebilir. Her değişim URL rewrite olmamalıdır. Recursive path bunu zorlaştırır. Stable route bu lifecycle bağımlılığını azaltır. Product manager URL impact'i move öncesi görmelidir.

Binlerce Redirect

Büyük kategori taşınması alt ağacı etkiler. Redirect registry hızla büyür. Sitemap ve feed cache güncellenmelidir. Deployment rollback daha zor olur. Migration batch ve monitoring gerektirir.

Stable Category ID Alternatifi

Public route içine stable category ID eklenebilir veya path flat tutulabilir. Slug presentation amacıyla kalır. Parent move URL'yi değiştirmeyebilir. Kullanıcı okunabilirliği korunabilir. Trade-off route tasarımına göre değerlendirilmelidir.

Marka Slug'ları Nasıl Yönetilir?

Marka URL'leri ayrı namespace altında tutulduğunda routing daha güvenli olur. Marka adlarında &, + ve noktalama gibi semboller sık görülebilir. Semantic mapping özellikle marka kimliğini bozmamak açısından önemlidir. Aynı isimli marka ihtimali düşük olsa da teknik olarak mümkün kabul edilmelidir. Brand slug lifecycle product slug'dan bağımsız yönetilebilir.

Brand Namespace

/marka/{slug} gibi route tür ayrımı sağlar. Product ve category aynı slug'ı kullanabilir. Registry entity_type ile uniqueness tanımlar. Canonical generator brand route template'i bilir. Multi-language durumda locale mapping uygulanabilir.

Marka Adındaki Semboller

Marka adlarında & veya nokta anlamlı olabilir. Generic symbol removal beklenmeyen sonuç verebilir. Brand normalizer aynı core engine üzerinde policy hook kullanabilir. Output kullanıcının markayı tanıyacağı kadar anlamlı kalmalıdır. Reserved path yine kontrol edilir.

H&M Örneği

H&M gibi isimde & işareti markanın bilinen parçasıdır. “hm” output kullanılabilir ancak başka entity ile collision olasılığı değerlendirilmeli. “h-and-m” veya locale-specific mapping alternatif olabilir. Seçim marka genelinde sabit tutulmalıdır. Migration sonradan kolay yapılmamalıdır.

Aynı İsimli Marka Collision'ı

Global katalogda aynı marka adıyla farklı kayıt oluşabilir. Master data önce deduplicate edilmelidir. Gerçekten farklı entity ise public ID disambiguator kullanılabilir. Sıralı suffix import sırasına bağımlı olabilir. Brand owner metadata faydalı olabilir.

Ürün, Marka ve Kategori Slug Namespace'leri Ayrılmalı mı?

Namespace ayrımı routing collision'larını büyük ölçüde azaltır. /urun/, /marka/ ve /kategori/ prefix'leri entity type'ı açık hale getirir. Aynı “apple” slug'ı farklı entity türlerinde kullanılabilir. URL registry uniqueness scope daha anlaşılır olur. Route resolution performansı da iyileşebilir.

/urun/

Product namespace ürün detail sayfalarını toplar. Router doğrudan product resolver kullanır. Slug collision yalnız product scope içinde kontrol edilebilir. Feed ve canonical aynı route template'i kullanır. Kategori değişikliği route'u etkilemez.

/marka/

Brand landing page ayrı namespace alır. Brand slug product ile çakışmaz. Search ve navigation linkleri resolver üzerinden üretilir. Localized route gerekirse /en/brand/ gibi değişebilir. Entity ID aynı kalır.

/kategori/

Category namespace taxonomy sayfalarını ayırır. Flat veya recursive yapı burada kurulabilir. Reserved route listesi daha kolay yönetilir. Filter facets category path sonrasında parameter ile eklenebilir. Sitemap category resolver'ı kullanır.

Routing Collision'ı Önlemek

Namespace yoksa /apple adresinin marka mı ürün mü kategori mi olduğu belirsizleşebilir. Router precedence business rule'a bağlı hale gelir. Yeni entity türü eklemek daha zor olur. Namespace bu belirsizliği ortadan kaldırır. Kısa URL uğruna route ownership'i belirsiz bırakmak önerilmez.

Ürün Varyantlarında URL Nasıl Oluşturulur?

Varyant URL politikası search intent ve paylaşılabilir state ihtiyacına göre belirlenmelidir. Her renk ve beden kombinasyonuna ayrı indexable URL vermek çoğu katalogda URL patlamasına yol açar. Ana ürün canonical kalabilir. Varyant state query parameter veya internal ID ile temsil edilebilir. Gerçek arama talebi olan belirli varyantlar için ayrı indexable landing policy uygulanabilir.

Varyantsız Ana Ürün URL'si

Ana ürün tek canonical URL taşır. Renk ve beden UI state olarak seçilir. Search engine tek product page indeksler. Varyant stok bilgisi structured data ve page content'te gösterilebilir. URL lifecycle daha basit kalır.

Path Bazlı Varyant

/urun/tshirt/kirmizi gibi yapı varyantı path içinde gösterir. Paylaşılabilir state sağlar. Ancak her varyant için canonical policy gerekir. Color değişimi ayrı indexable page olmak zorunda değildir. Route registry variant identity'yi product ID ile ilişkilendirmelidir.

Query Parameter Bazlı Varyant

?color=kirmizi biçimi UI state için pratiktir. Canonical ana product URL'ye işaret edebilir. Parameter ordering normalize edilmelidir. Tracking ile varyant parameter'ları ayrılmalıdır. Shareable link ihtiyacını iyi karşılayabilir.

Varyant ID

Her variant kalıcı internal veya public ID taşımalıdır. Color label değişse bile variant identity korunur. URL state slug'dan bağımsız resolve edilebilir. Feed variant URL gerekiyorsa ID yardımcı olabilir. Canonical policy entity tipine göre belirlenmelidir.

Renk Varyantı İçin Örnek URL Yapıları

Renk varyantı farklı biçimlerde temsil edilebilir. Path yapısı daha okunabilir görünürken query parameter state mantığını açık şekilde taşır. İki model de teknik olarak çalışabilir. Önemli konu canonical ve indexability kararının sabit olmasıdır. Site aynı varyant için iki farklı indexable adres üretmemelidir.

/urun/tshirt/kirmizi

Path varyantı kullanıcıya renk seçimini açıkça gösterir. Router color segment'i variant resolver'a iletir. Kırmızı ayrı search demand taşıyorsa indexable yapılabilir. Aksi halde canonical ana product URL'ye dönebilir. Her color value normalized slug policy kullanmalıdır.

/urun/tshirt?color=kirmizi

Query parameter implementation daha az route değişikliği gerektirir. UI state kolay okunur. Canonical genellikle parameter'sız product URL olabilir. Parameter order başka seçeneklerle birleştiğinde normalize edilmelidir. Analytics tracking parameter'larıyla karıştırılmamalıdır.

Canonical Politikasını Belirlemek

Varyant sayfası gerçekten ayrı arama niyetini karşılıyorsa self-canonical düşünülebilir. Aksi halde ana ürün canonical olur. Policy category veya product type bazında değişebilir. Structured data canonical ile çelişmemelidir. Sitemap yalnız indexable variant URL'lerini içermelidir.

Beden Varyantı URL'ye Dahil Edilmeli mi?

Beden çoğu ürün için kullanıcı seçimidir fakat ayrı arama sayfası değildir. Her bedeni URL'ye dahil etmek kombinasyon sayısını büyütebilir. Ancak kullanıcı link paylaşımında seçili bedenin korunması istenebilir. Query parameter bu ihtiyacı karşılayabilir. Canonical yine ana ürün üzerinde kalabilir.

Search Intent

Kullanıcılar belirli beden için doğrudan arama yapıyor mu incelenmelidir. Çoğu durumda ürün tipi ve marka daha önemlidir. Search demand yoksa ayrı indexable URL gereksizdir. SEO kararı data ile verilmelidir. Facet analytics yardımcı olabilir.

Kullanıcı Paylaşımı

Seçili beden linkte taşınabilir. Kullanıcı arkadaşına aynı state'i gönderebilir. Query parameter bu iş için uygundur. Parameter canonical'dan hariç tutulabilir. Expired stok durumu linki yine ana ürüne açabilir.

Stok Durumu

Beden stoğu sık değişir. URL identity stok state'e bağlanmamalıdır. Out-of-stock variant için product page yaşamaya devam edebilir. Kullanıcıya alternatif beden gösterilir. Sitemap transient stok değişikliklerine göre sürekli değişmemelidir.

URL Kombinasyon Patlaması

Renk, beden, malzeme ve satıcı birlikte düşünüldüğünde kombinasyon sayısı hızla büyür. Her state ayrı URL olmamalıdır. Indexable facet listesi sınırlandırılmalıdır. Canonical aynı product identity etrafında kalmalıdır. Crawl alanı server log ile izlenmelidir.

Varyant Kombinasyon Patlaması Nasıl Önlenir?

Varyant kombinasyon patlaması, her seçenek birleşiminin ayrı URL olarak üretilmesinden kaynaklanır. Dört renk, on beden, üç malzeme ve beş satıcı yüzlerce kombinasyon yaratabilir. Bunların çoğu search intent taşımaz. UI state ile indexable URL kavramı ayrılmalıdır. Facet engine hangi kombinasyonların public ve indexable olduğunu yönetmelidir.

Color

Renk kullanıcı seçimidir. Bazı renkler güçlü arama talebi taşıyabilir. Bu durumda limited indexable route düşünülebilir. Diğer renkler parameter state olarak kalır. Policy ürün kategorisine göre belirlenebilir.

Size

Beden genellikle indexable dimension değildir. Query parameter veya client state yeterlidir. Stok değişimi URL üretmemelidir. Size values normalize edilmelidir. Analytics user preference'i takip edebilir.

Material

Malzeme bazı ürün kategorilerinde search intent taşır. “deri çanta” gibi sorgular ayrı landing mantığına uygun olabilir. Her material kombinasyonunu product variant URL yapmak yine gereksizdir. Category facet page daha doğru olabilir. Canonical policy use case'e göre seçilmelidir.

Seller

Marketplace yapısında seller aynı product entity'nin teklif sahibi olabilir. Her seller için ayrı product URL duplicate content yaratabilir. Offer state product page içinde gösterilebilir. Seller-specific listing ayrı route kullanabilir. Canonical product identity korunmalıdır.

Her State İçin Ayrı URL Üretmemek

UI state ve SEO landing page farklı kavramlardır. Shareable state query parameter ile tutulabilir. Indexable sayfa yalnız seçilmiş facet kombinasyonlarına açılır. Sitemap bu whitelist'i takip eder. Crawl budget daha kontrollü kullanılır.

Query Parameter'lar Nasıl Normalize Edilmelidir?

Query parameter normalization aynı state'in tek canonical serialization ile temsil edilmesini sağlar. Key order, value formatı ve duplicate key davranışı belirlenmelidir. Tracking parameter'ları business state'ten ayrılmalıdır. Unknown parameter'lar canonical'dan çıkarılabilir. E-ticaret URL sisteminde bu iş slug normalizer'dan ayrı bir parameter normalizer tarafından yönetilebilir.

key=value

Parameter clear key=value formatında serialize edilir. Key lowercase policy kullanabilir. Value URL encoding kurallarına göre normalize edilir. Empty value davranışı tanımlanmalıdır. Boolean parameter için standart representation seçilmelidir.

Deterministic Key Order

?color=red&size=m ile ?size=m&color=red aynı state'i temsil eder. Canonical serializer tek sıralama kullanmalıdır. Alfabetik veya business-defined order seçilebilir. Internal linkler aynı sırayı üretir. Duplicate crawl azalır.

Multiple Values

Bir filtre birden fazla değer taşıyabilir. color=red,blue veya tekrarlanan key formatı kullanılabilir. Tek policy seçilmelidir. Value order da normalize edilmelidir. Aynı set farklı URL üretmemelidir.

Duplicate Keys

Aynı key request'te birden fazla kez gelebilir. Parser davranışı framework'e göre değişebilir. Allowed schema bunu açıkça tanımlamalıdır. Gereksiz duplicate key canonical serialization'da temizlenmelidir. Security açısından parameter pollution test edilmelidir.

Parameter Ordering Algorithm

Parameter ordering canonicalization sürecinin basit ama önemli parçasıdır. Önce allowed parameter list uygulanır. Ardından key ve value normalization yapılır. Canonical sıra belirlenir. Sonuç tek serializer üzerinden bütün uygulamada kullanılmalıdır.

Allowed Parameter List

Bilinen filtre ve pagination key'leri whitelist edilir. Unknown tracking veya debug parameter'ları canonical state'e dahil edilmez. Route bazında allowed list farklı olabilir. Security validation aynı schema'dan yararlanabilir. Yeni parameter eklemek explicit change gerektirir.

Alfabetik veya Tanımlı Sıra

Alfabetik sıra implementation açısından kolaydır. Business-defined order kullanıcıya daha okunabilir olabilir. Hangisi seçilirse bütün resolver aynı kuralı kullanmalıdır. Order change URL churn yaratabileceği için versionlanmalıdır. Mevcut indexable parameter URL'lerinde migration etkisi incelenmelidir.

Value Normalization

Value case, whitespace ve encoding açısından normalize edilir. Color ID yerine slug veya stable code kullanılabilir. Numeric range formatı standartlaştırılır. Multiple values sort edilebilir. Invalid values request'ten çıkarılabilir veya 400 dönebilir.

Canonical Serialization

Normalize key-value set tek string'e çevrilir. Escaping standardı sabit olmalıdır. Empty parameter atılabilir. Tracking değerleri hariç tutulur. HTML canonical tag bu serializer sonucunu kullanır.

Geçici Parametreler Canonical URL'ye Dahil Edilmeli mi?

Çoğu tracking ve session parameter'ı canonical URL'nin parçası olmamalıdır. Bunlar içeriğin kimliğini değiştirmez. Canonical generator business state ile analytics state'i ayırmalıdır. Session ID'nin URL'ye eklenmesi özellikle duplicate crawl ve privacy açısından risklidir. Tracking parameter'ları request analytics için işlenebilir ama canonical serialization'dan çıkarılmalıdır.

UTM

UTM parameter'ları kampanya attribution için kullanılır. Sayfa içeriğini değiştirmez. Canonical URL'den çıkarılmalıdır. Internal linklerde UTM kullanılmamalıdır. Landing request analytics sistemi değerleri kaydedebilir.

Session ID

Session ID URL içinde taşınmaması gereken hassas ve duplicate üreten değerdir. Cookie veya güvenli session mekanizması tercih edilmelidir. Search engine session parameter'lı URL'leri crawl etmemelidir. Canonical temiz URL'yi göstermelidir. Server log accidental session URLs için izlenebilir.

Click ID

Click ID reklam platformu attribution amacıyla gelebilir. İçerik identity'si değildir. Canonical'dan çıkarılır. Stored analytics event'e bağlanabilir. Sitemap veya internal linkte asla üretilmemelidir.

Referral Parameter

Referral code business tracking için kullanılabilir. Kullanıcıya özel fiyat veya attribution davranışı varsa security ayrıca düşünülmelidir. Canonical genellikle referral olmadan üretilir. Shared link state ayrı değerlendirilebilir. Indexable URL sayısı artırılmamalıdır.

Canonical'dan Hariç Tutmak

Temporary parameter list merkezi policy'de tutulmalıdır. Canonical resolver yalnız content-defining parameter'ları serialize eder. Sitemap zaten parameter'sız URL yayınlar. Internal links clean form kullanır. Search regression testi tracking parameter'lı canonical üretimini yakalamalıdır.

Pagination URL'leri Slug Sisteminden Nasıl Ayrılır?

Pagination ürün veya kategori entity slug'ının parçası değildir. Liste sayfası state'idir. page parameter veya path segment ile temsil edilebilir. Her sayfanın indexability ve canonical politikası ayrıca belirlenmelidir. Slug engine yalnız base category path üretmeli, pagination serializer ayrı çalışmalıdır.

page Parameter

?page=2 basit ve anlaşılır yöntemdir. Numeric value validation yapılmalıdır. page=1 canonical base URL'ye normalize edilebilir. Negative ve çok büyük values ele alınmalıdır. Internal pagination links canonical serializer kullanmalıdır.

Her Sayfanın Benzersiz URL'si

Pagination sayfaları farklı ürün setleri gösterdiği için ayrı crawlable URL olabilir. Aynı page state farklı parameter order ile tekrar üretilmemelidir. Invalid page soft 404 olmamalıdır. Return behavior business rule'a göre belirlenir. Pagination links server-rendered olmalıdır.

Pagination Canonical

Canonical stratejisi kullanılan SEO yaklaşımına göre belirlenmelidir. Her pagination page kendisini canonical gösterebilir. İlk sayfaya toplu canonical vermek içerik discovery'yi etkileyebilir. Mevcut search engine rehberleri ve site yapısı birlikte değerlendirilmelidir. Policy central resolver içinde uygulanmalıdır.

Filtre URL'leri Nasıl Yönetilmelidir?

Faceted navigation e-ticaret sitelerinin en büyük URL ölçekleme sorunlarından biridir. Her filtre state'i indexable olmamalıdır. Search demand taşıyan belirli facet kombinasyonları ayrı landing page olabilir. Geri kalanları crawl ve index açısından sınırlandırmak gerekir. Slug engine ile facet engine sorumluluklarının ayrılması sistem tasarımını sadeleştirir.

Filter State

Seçili renk, beden, fiyat veya marka state'i URL'de temsil edilebilir. Shareable experience için faydalıdır. Bu state'in indexable olması ayrı karardır. Parameter order canonical olmalıdır. Invalid combinations temiz yönetilmelidir.

Search Demand

Arama hacmi olan facet kombinasyonları SEO landing adayı olabilir. “erkek siyah spor ayakkabı” gibi kombinasyonlar değerlendirilebilir. Her filtreyi indexlemek gereksizdir. Search data ve business margin birlikte kullanılabilir. Page content de yeterli kalite sunmalıdır.

Indexable Facet

Whitelist ile seçilebilir. Self-canonical URL kullanabilir. Sitemap'e eklenebilir. Unique title ve content üretilmelidir. Facet state stabil olmalıdır.

Non-Indexable Facet

Kullanıcı deneyimi için URL state'i bulunabilir. Canonical daha üst landing'e dönebilir. Sitemap'e eklenmez. Internal crawling kontrollü tutulabilir. Infinite combination engellenmelidir.

Slug Engine ile Facet Engine'i Ayırmak

Slug engine entity path üretir. Facet engine filter state serialize eder. İki modül bağımsız test edilir. Canonical resolver ikisini policy'ye göre birleştirir. Böylece product slug değişikliği filter logic'i etkilemez.

Canonical URL Generator Nasıl Tasarlanmalıdır?

Canonical generator uygulamanın farklı yerlerinde string birleştiren yardımcı fonksiyonlardan oluşmamalıdır. Entity ID üzerinden current slug ve locale bilgisi alınmalıdır. Route template uygulanır. Temporary parameter temizlenir. Son olarak doğru scheme ve domain ile absolute URL oluşturulur.

Entity ID Al

Canonical generation mümkünse entity ID ile başlar. Böylece incoming request path'ine güvenilmez. Eski slug ile ziyaret edilmiş olsa bile current URL bulunur. Redirect ve canonical aynı entity state'i kullanır. Identity slug'dan bağımsız kalır.

Current Slug Bul

URL registry locale ve entity ID üzerinden current slug döndürür. Historical slug kullanılmaz. Cache kullanılabilir. Registry miss production error olarak izlenebilir. Fallback generation kontrolsüz yapılmamalıdır.

Locale Belirle

Locale request veya entity context'ten alınır. Kullanıcı dili ile URL locale policy ayrılabilir. Hreflang mapping aynı locale registry'yi kullanır. Unsupported locale fallback açık tanımlanmalıdır. Route template locale'e göre seçilir.

Route Template Uygula

Product için /urun/{slug}, brand için /marka/{slug} gibi template kullanılır. Template config versionlanabilir. Entity-specific helper hard-coded string üretmemelidir. Category recursive ise parent path resolver çağrılır. Reserved namespace merkezidir.

Absolute URL Oluştur

Scheme ve domain environment config'ten gelir. Host header doğrudan güvenilmemelidir. Production canonical staging domain üretmemelidir. Multi-region domain mapping locale ile ilişkilendirilebilir. Output normalized absolute URL olur.

Canonical, Sitemap ve İç Linkler Aynı URL Kaynağını Kullanmalı mı?

Evet. Bu üç sistem farklı URL generator kullanırsa kaçınılmaz olarak tutarsızlık oluşur. Canonical bir adresi, sitemap başka adresi, internal link üçüncü adresi gösterebilir. Search engine açısından bu çelişkili sinyal yaratır. Central URL resolver bütün public URL üretiminin tek kaynağı olmalıdır. Testler bu üç output'un aynı current path'i kullandığını doğrulamalıdır.

Central URL Resolver

Resolver entity ve locale alır. Current path üretir. Route policy uygular. İhtiyaç halinde absolute veya relative URL döndürür. Uygulamanın başka yerleri slug formatting yapmaz.

Tek Kaynaktan URL Üretimi

Frontend, backend, sitemap job ve feed exporter aynı service veya shared library'yi kullanır. Headless yapıda HTTP URL service de kullanılabilir. Versioning control altında tutulur. Cache key entity ID ve locale içerebilir. Contract test cross-service consistency sağlar.

Tutarsızlıkların Önlenmesi

Canonical mismatch sayısı dashboard'da sıfıra yakın olmalıdır. URL diff test farklı producer çıktısını karşılaştırabilir. Staging crawler bütün page'leri tarayabilir. Redirect URL sitemap'te bulunmamalıdır. Old slug internal linkte kalmamalıdır.

Central URL Resolver Nedir?

Central URL resolver, uygulamadaki public URL kurallarını tek katmanda toplayan servistir. Product, category, brand ve canonical adreslerini üretir. Entity identity, locale, current slug ve route template bilgilerini birleştirir. Böylece UI veya feed kodu kendi URL mantığını yazmaz. Teknik SEO governance açısından en değerli modüllerden biridir.

getProductUrl()

Product ID ve locale alabilir. URL registry current slug'ı bulur. Product route template uygulanır. Optional absolute flag olabilir. Eski slug hiçbir zaman burada üretilmez.

getCategoryUrl()

Category ID üzerinden current path oluşturur. Recursive policy varsa parent chain kullanır. Locale translation dikkate alınır. Tombstone category error döndürebilir. Sitemap aynı fonksiyonu çağırır.

getBrandUrl()

Brand namespace ve locale kullanılır. Sembol normalization create sırasında yapılmıştır. Resolver stored current slug'ı döndürür. Brand rename otomatik yeni slug üretmez. Manual history davranışı ayrı service'tedir.

getCanonicalUrl()

Incoming request URL'sine göre değil entity identity'ye göre çalışmalıdır. Temporary parameter'ları temizler. Doğru domain ve scheme ekler. Locale mapping uygular. HTML head, API metadata ve SEO testleri aynı sonucu kullanabilir.

URL Database'de Saklanmalı mı, Hesaplanmalı mı?

URL tamamen hesaplanabilir, tamamen saklanabilir veya hibrit model kullanılabilir. Computed model basittir ancak source attribute değişince URL kendiliğinden değişebilir. Persisted model stabilite ve history açısından daha güçlüdür. Büyük e-ticaret sistemlerinde current slug ve history'nin saklanması çoğu zaman faydalıdır. Route template yine hesaplanabilir tutulabilir.

Computed URL

URL her request'te ürün adı ve kategori bilgisinden oluşturulur. Ek data storage ihtiyacı düşüktür. Ancak source field değişikliği URL'yi fark edilmeden değiştirir. Redirect history oluşturmak zordur. SEO stabilitesi için risklidir.

Persisted URL

Current slug veya current path database'de saklanır. Rename URL'yi otomatik etkilemez. History kolay tutulur. Migration audit edilebilir. Storage maliyeti düşüktür.

Hybrid Model

Slug persisted, route template computed olabilir. Product ID ve locale registry'de current slug taşır. Resolver prefix ve domain'i hesaplar. History old path veya old slug saklayabilir. Bu model esneklik ve stabiliteyi dengeler.

Computed URL Modelinin Avantajları

Computed URL küçük ve basit sistemlerde hızlı geliştirilebilir. Data duplication azalır. Tek route kuralı üzerinden output alınabilir. Rename sıklığı düşük ve SEO önemi sınırlı projelerde yeterli olabilir. Ancak e-ticarette ürün ve kategori lifecycle büyüdükçe riskleri daha görünür hale gelir.

Daha Az Veri Saklama

Ayrı slug table gerekmeyebilir. Product name üzerinden runtime hesap yapılır. Migration schema daha basittir. History ihtiyacı yoksa bakım kolaydır. Büyük katalogda compute maliyeti genellikle düşük olsa da stability riski daha önemlidir.

Tek Route Kuralı

Route template kodda bulunur. Her URL aynı formatla hesaplanır. Domain change kolay olabilir. Fakat category path ve locale translation eklenince logic büyür. Shared library kullanmak yine gerekir.

Basit Sistem

MVP için yeterli olabilir. Az ürün ve düşük SEO geçmişi vardır. Slug change maliyeti düşüktür. Sistem büyürse persisted modele migration planlanmalıdır. En baştan entity ID ayrımı yapmak geçişi kolaylaştırır.

Computed URL Modelinin Riskleri

Computed model kaynak alanların her değişikliğini URL değişikliği haline getirebilir. Bu durum özellikle kategori taşıma ve ürün rename işlemlerinde tehlikelidir. Redirect history yoksa eski URL 404 olur. Sitemap ve cache eski adresi tutabilir. Büyük e-ticaret sitelerinde kontrolsüz URL churn oluşturabilir.

Kategori Değişimi

Recursive category path anında değişebilir. Altındaki binlerce product URL etkilenebilir. Redirect map otomatik oluşmaz. Search index eski URL'leri taramaya devam eder. Bu nedenle category-coupled computed URL risklidir.

Ürün Adı Değişimi

Title güncellemesi slug'ı değiştirir. Marketing ekibi bunun SEO etkisini fark etmeyebilir. Eski linkler kırılır. Analytics URL bazında parçalanır. Persisted slug bu problemi önler.

Kontrolsüz URL Değişimi

Normalizer code update bile tüm URL'leri değiştirebilir. Transliteration mapping değişikliği geniş migration yaratabilir. Deployment öncesi URL diff gerekli olur. Computed modelde rollback daha zor olabilir. URL snapshot test kritik hale gelir.

Persisted URL Modelinin Avantajları

Persisted model URL yaşam döngüsünü açık biçimde yönetir. Current slug bir veri kaydı olarak tutulur. Geçmiş slug'lar redirect ve audit için saklanır. Rename veya taxonomy değişimi otomatik URL değişikliği üretmez. Kurumsal e-ticaret yapılarında bu stabilite önemli avantajdır.

Stabilite

Source title değişikliği current slug'ı etkilemez. URL yıllarca aynı kalabilir. Backlink ve bookmark korunur. Search engine daha az migration görür. Product lifecycle editoryal değişikliklerden ayrılır.

Slug History

Her değişiklik kayıt altındadır. Old path redirect source olur. Chain flattening yapılabilir. Audit ve troubleshooting kolaylaşır. Tombstone reuse'i engeller.

Redirect Yönetimi

History table 301 mapping üretir. Old URL doğrudan current target'a gider. Sitemap eski path'i kullanmaz. Internal links otomatik current path'e geçer. Redirect count dashboard'da izlenebilir.

Audit

Kimin, ne zaman ve neden slug değiştirdiği kaydedilebilir. Unexpected churn root cause bulunur. Migration release ile ilişkilendirilir. Product manager impact raporu görebilir. Governance güçlenir.

URL Registry Nasıl Tasarlanır?

URL registry public adres sahipliğini merkezi biçimde tutar. Entity type, entity ID, locale, current path ve status temel alanlardır. Bir public URL tek entity'ye ait olmalıdır. Historical ve tombstone path'ler de ownership kaydı olarak tutulabilir. Registry canonical, redirect ve resolver sisteminin ortak kaynağı olur.

Entity Type

Product, category veya brand gibi türü belirtir. Namespace ve route template seçimini etkiler. Enum veya stable code kullanılabilir. Yeni entity type eklemek migration gerektirebilir. Query index entity_type ile başlayabilir.

Entity ID

Kalıcı entity kimliğidir. URL değişse bile aynı kalır. Foreign key ile asıl tabloya bağlanabilir. Cross-service registry'de generic identifier kullanılabilir. Deleted entity status üzerinden yönetilir.

Locale

Aynı entity farklı dilde farklı slug taşıyabilir. Locale uniqueness scope'unda yer alır. Hreflang mapping bu alanı kullanır. Unsupported locale kayıt oluşturmaz. Region-specific locale gerekiyorsa dil-ülke kodu saklanabilir.

Current Path

Entity'nin güncel public path'idir. Unique constraint taşımalıdır. Absolute domain yerine relative path saklamak çoğu zaman daha esnektir. Domain resolver ayrıca çalışır. Path change history kaydı oluşturur.

Status

active, redirect, tombstone veya deleted gibi durumlar kullanılabilir. Resolver yalnız active current path'i üretir. Incoming route historical path bulursa redirect verir. Tombstone reuse'i engeller. Status transition state machine ile yönetilebilir.

Created At

URL kaydının oluşturulma zamanıdır. Audit ve churn analizi sağlar. Import batch ile ilişkilendirilebilir. Timestamp timezone standardı kullanmalıdır. Çok sık create event alert üretebilir.

URL History Tablosu Nasıl Tasarlanır?

History tablosu eski public path'lerin yeni current path ile ilişkisini tutar. Source ve target yalnız string değil entity relationship ile de modellenebilir. Changed timestamp ve redirect type kaydedilmelidir. Chain flattening için final target mantığı kullanılmalıdır. Eski URL hiçbir zaman silently kaybolmamalıdır.

Old Path

Geçmişte public olarak kullanılan tam relative path'tir. Unique source olmalıdır. Başka entity'ye atanamaz. Incoming request lookup bu alan üzerinden yapılır. Index performansı önemlidir.

New Path

Final current target path olabilir. Alternatif modelde entity ID saklanıp runtime çözülür. Materialized path performansı artırır. Slug tekrar değişince update gerekir. Chain testleri bunu doğrular.

Entity ID

History kaydının hangi entity'ye ait olduğunu gösterir. Current path değişse bile ilişki korunur. Cross-entity redirect yalnız explicit migration ile yapılmalıdır. Product merge senaryosu reason ile işaretlenebilir. Audit daha anlaşılır hale gelir.

Changed At

Değişiklik zamanı migration analizinde kullanılır. Deployment window ile karşılaştırılabilir. URL churn metric hesaplanabilir. User action timestamp'i ayrıca bulunabilir. Incident timeline kolaylaşır.

HTTP Redirect Type

301 kalıcı değişiklik için yaygın tercihtir. Bazı geçici use case'lerde 302 veya 307 gerekebilir. URL history çoğunlukla permanent değişiklikleri tutar. Redirect type business policy'ye göre sınırlanmalıdır. SEO migration'da yanlış status engellenmelidir.

URL Ownership Nedir?

URL ownership, bir public path'in hangi entity tarafından sahiplenildiğini tanımlar. Aynı path'in aynı anda iki entity'ye ait olması routing ve SEO açısından kabul edilemez. Redirect source'lar da geçmiş ownership taşır. Reserved path'ler sistem tarafından sahiplenilmiş kabul edilebilir. Ownership database constraint ile enforce edilmelidir.

Bir Public URL Tek Entity'ye Aittir

Unique path rule temel invariant'tır. Locale veya host namespace'e göre scope değişebilir. Current ve historical paths birlikte değerlendirilmelidir. Reverse lookup hangi entity'nin sahibi olduğunu döndürür. Ambiguous route oluşturulmamalıdır.

Duplicate Owner Tespit Etmek

Migration sırasında duplicate path taraması yapılmalıdır. Case normalization ve Unicode equivalence dikkate alınmalıdır. Database query raw string karşılaştırmasından fazlasını gerektirebilir. Normalize path materialized column kullanılabilir. Conflict manual veya deterministic rule ile çözülür.

Reserved Path

Sistem route'ları entity tarafından sahiplenilemez. Registry bunları virtual owner olarak işaretleyebilir. New route eklenirken conflict check yapılır. Existing product path varsa migration planı gerekir. Production router precedence ile problem gizlenmemelidir.

Çok Dilli E-Ticaret Sitelerinde Slug Nasıl Üretilir?

Çok dilli yapılarda aynı product ID farklı locale'lerde farklı slug taşıyabilir. URL identity entity ID üzerinden korunur. Localized route template dil bazında değişebilir. Slug çevirisi editoryal veya otomatik olabilir. Hreflang ve canonical aynı URL registry üzerinden üretilmelidir.

Locale Bazlı Slug

Her locale için ayrı current slug kaydı tutulabilir. Türkçe ve İngilizce başlıklar farklı normalize edilir. Transliteration policy locale'e göre değişebilir. Fallback locale behavior açık olmalıdır. Eksik çeviri otomatik yanlış URL üretmemelidir.

Aynı Product ID, Farklı Slug

Entity tek product ID'dir. /tr/ ve /en/ adresleri presentation varyantıdır. Analytics entity bazında birleştirilebilir. Hreflang bu ilişkiyi kullanır. Product rename bir locale'de diğerini otomatik etkilemez.

Localized Route

/tr/urun/ ve /en/product/ gibi route template değişebilir. Router locale prefix'i çözer. URL resolver language-specific template kullanır. Hard-coded stringler frontend içinde tutulmamalıdır. Sitemap locale bazlı listeler oluşturabilir.

Türkçe ve İngilizce Slug Örneği

Aynı ürün için farklı dillere göre doğal slug kullanmak kullanıcı deneyimini iyileştirir. Entity ID aynı kaldığı için iki URL'nin hangi ürüne ait olduğu sistem açısından nettir. Her locale self-canonical URL kullanabilir. Hreflang alternatif dilleri birbirine bağlar. Çok dilli sitemap mimarisinde bu ilişki merkezi registry'den üretilmelidir.

/tr/urun/kirmizi-elbise

Türkçe locale route'u ve Türkçe slug kullanır. ASCII policy örneğinde kirmizi-elbise üretilmiştir. Türkçe canonical bu adresi gösterir. Hreflang tr alternatifi olur. Product ID URL'nin arkasında sabittir.

/en/product/red-dress

İngilizce route ve slug kullanır. Product translation “Red Dress” üzerinden oluşturulmuştur. İngilizce canonical kendisini gösterir. Türkçe alternatifi hreflang ile bağlanır. Locale mapping tek entity kaydında tutulur.

Aynı Entity ID

İki URL de aynı product ID'yi resolve eder. Stock ve price temel entity'den gelir. Locale yalnız presentation ve content'i değiştirir. Product merge veya delete iki locale'i birlikte etkiler. URL history locale bazında ayrı tutulabilir.

Çeviri Değiştiğinde Slug Değişmeli mi?

Çeviri metni değişebilir fakat slug'ın otomatik değişmesi gerekli değildir. URL stabilitesi burada da önemlidir. Lokal SEO için gerçekten anlamlı bir iyileştirme gerekiyorsa explicit change yapılabilir. Eski localized URL 301 ile yeni adrese gider. Hreflang mapping aynı transaction içinde güncellenmelidir.

URL Stabilitesi

Translation edit URL change tetiklememelidir. Content team rahatça başlık düzenleyebilir. Search index history korunur. Locale-specific backlinks kaybolmaz. Slug bağımsız alan olarak kalır.

Lokal SEO

Yanlış veya alakasız çeviri slug düzeltilebilir. Değişikliğin gerçek kullanıcı ve arama faydası değerlendirilmelidir. Her küçük wording farkı migration gerekçesi değildir. Search query data kullanılabilir. 301 zorunlu süreç olarak uygulanır.

Editoryal Override

Slug çeviriden otomatik oluşturulduktan sonra editör manual override yapabilir. Override flag saklanabilir. Sonraki translation update slug'ı değiştirmez. Admin preview old-new mapping gösterir. Permission yönetimi uygulanmalıdır.

Redirect

Eski locale path yeni locale path'e 301 verir. Cross-language redirect yapılmamalıdır. Hreflang yeni current URL'yi göstermelidir. Sitemap old URL'yi kaldırır. Internal links cache invalidate edilir.

Hreflang URL'leri Nereden Üretilmelidir?

Hreflang URL'leri sayfa template'inde manuel string birleştirmeyle üretilmemelidir. URL registry aynı entity'nin locale alternatiflerini bilir. Locale mapping üzerinden current path'ler alınır. Her sayfa kendisini ve alternatifleri tutarlı biçimde referanslamalıdır. Canonical ile hreflang URL'leri çelişmemelidir.

URL Registry

Entity ID üzerinden tüm active locale URL'leri bulunur. Tombstone veya redirect path dışarıda bırakılır. Current paths absolute URL'ye çevrilir. Missing locale hreflang listesine eklenmez. Cache entity version ile invalidate edilebilir.

Locale Mapping

tr, en veya region-specific kodlar product localization ile eşleştirilir. Route template locale'e göre seçilir. Hreflang code standardı doğru format kullanmalıdır. Default x-default policy ayrıca belirlenebilir. Mapping tek config'te tutulmalıdır.

Self Reference

Her localized page kendi locale URL'sini hreflang setine dahil edebilir. Alternatif sayfalar karşılıklı reference vermelidir. Redirect URL kullanılmamalıdır. Canonical current path ile aynı olmalıdır. SEO testleri reciprocity kontrolü yapabilir.

Canonical Uyumu

Türkçe page canonical olarak Türkçe current URL'yi göstermelidir. Hreflang İngilizce alternatifi ayrı URL olarak listeler. Bir locale başka locale'i canonical yaparsa sinyaller karışabilir. Policy central SEO service'te tutulmalıdır. Sitemap language mapping de aynı source'u kullanmalıdır.

Çok Bölgeli E-Ticaret URL'leri

Dil ile ülke aynı kavram değildir. /tr-tr/, /en-gb/ veya /de-de/ gibi locale kodları bölgesel fiyat, stok veya mevzuat farklarını temsil edebilir. Aynı dil farklı ülkelerde farklı catalog veya currency gösterebilir. URL registry locale key'i bu ayrımı desteklemelidir. Çok bölgeli sitemap ve hreflang yapısı aynı model üzerine kurulmalıdır.

/tr-tr/

Türkiye Türkçesi için kullanılabilir. Currency TRY ve local content bağlanabilir. Entity aynı global product olabilir. Region availability ayrı business rule'dur. Slug Türkçe locale policy kullanır.

/en-gb/

İngilizce ve Birleşik Krallık bölgesini temsil edebilir. Product translation ve fiyat farklı olabilir. Route template yine localized olabilir. Hreflang en-gb olarak üretilir. Global en fallback ayrı policy'ye bağlanabilir.

/de-de/

Almanya Almancası için locale kullanılır. Slug German title üzerinden üretilebilir. German character policy ayrı plugin kullanabilir. Product ID global kalabilir. Regional compliance page content'i etkileyebilir.

Dil ile Ülke Ayrımı

tr yalnız dil, tr-TR dil ve ülke kombinasyonudur. Global işletmede bu ayrım fiyat ve availability için önemlidir. URL architecture baştan doğru locale granularity seçmelidir. Sonradan prefix değişikliği büyük migration yaratabilir. Hreflang ve analytics aynı locale taxonomy'yi kullanmalıdır.

Slug Generator İçin Örnek Veri Modeli

Slug sistemi entity, localized slug ve redirect kayıtlarından oluşabilir. Entity kalıcı kimliği taşır. Slug tablosu locale ve current flag ile presentation bilgisini tutar. Redirect tablosu historical path'leri final target'a bağlar. Bu model küçük başlayıp URL registry yapısına büyüyebilir.

Entity

Entity product, category veya brand gibi public kaynakların ortak abstraction'ıdır. ID kalıcıdır. Type routing policy'yi belirler. Slug değişikliği entity identity'yi etkilemez. Soft delete status ayrıca tutulabilir.

id

Kalıcı primary veya public identifier'dır. Slug'dan bağımsızdır. Redirect history aynı ID'ye bağlı kalır. Multi-language kayıtlar aynı ID'yi paylaşır. Integration mapping için kullanılabilir.

type

product, category veya brand gibi sınıfı gösterir. URL namespace seçimini etkiler. Constraint ve route resolver bu alanı kullanabilir. Yeni type eklemek schema değil enum update gerektirebilir. Type değişimi normal lifecycle'da yapılmamalıdır.

Slug

Slug tablosu entity'nin locale bazlı public adını tutar. Bir entity birden fazla historical slug'a sahip olabilir. is_current active olanı gösterir. Unique constraint locale ve namespace ile birlikte uygulanır. Created timestamp audit sağlar.

locale

Slug'ın hangi dil veya bölgeye ait olduğunu belirtir. Translation update yalnız ilgili locale'i etkiler. Hreflang bu alan üzerinden eşleşir. Locale string standardı sabit olmalıdır. Case normalize edilmelidir.

value

Normalized slug değeridir. Path prefix içermez. Unique constraint entity type ve locale scope'unda olabilir. Length limit database ve application'da uyumlu olmalıdır. Raw title ayrıca saklanabilir.

is_current

Current slug'ı historical kayıtlardan ayırır. Bir entity-locale için yalnız bir true kayıt bulunmalıdır. Partial unique index uygulanabilir. Change transaction eskiyi false, yeniyi true yapar. Redirect history ayrıca oluşturulur.

Redirect

Redirect table eski public path'i yeni current path'e bağlar. Source unique olmalıdır. Target current canonical path veya entity ID olabilir. HTTP status ve reason metadata eklenebilir. Chain flattening bu tablo üzerinden yapılır.

source

Eski relative path'tir. Incoming request buradan lookup edilir. Unique index taşır. Tombstone source başka entity'ye verilmez. Locale path içinde açık olabilir.

target

Final current relative path'tir. Chain oluşturmamak için doğrudan current olmalıdır. Alternatif olarak target entity ID saklanabilir. Resolver absolute URL üretir. Target existence deployment testinde doğrulanır.

Bulk Product Import Sırasında Slug Nasıl Üretilir?

Bulk import URL sisteminin gerçek dayanıklılığını test eder. PIM veya ERP'den gelen yüz binlerce ürün aynı anda normalize edilmelidir. Product ID mapping olmadan yalnız title üzerinden işlem yapmak duplicate entity yaratabilir. Collision detection batch seviyesinde ve database seviyesinde yapılmalıdır. Transactional persist ile yarım kayıt bırakılmamalıdır.

PIM / ERP Verisini Almak

External feed schema validate edilir. Product ID veya SKU mapping çıkarılır. Name ve locale alanları temizlenir. Null ve malformed kayıtlar reject queue'ya alınabilir. Slug generation raw feed içinde yapılmamalıdır.

Product ID Mapping

External ID mevcut internal entity ile eşleştirilir. Existing entity varsa current slug korunur. New entity ise slug generation çalışır. Mapping table idempotency sağlar. Merge ve split senaryoları explicit workflow gerektirir.

Batch Normalization

Product title'lar aynı core normalizer ile işlenir. Parallel worker olsa bile algorithm version aynıdır. Locale explicit geçilir. Golden tests deployment öncesi çalışır. Batch output geçici staging table'a yazılabilir.

Collision Detection

Batch içinde duplicate base slug'lar önceden görülebilir. Deterministic suffix planlanabilir. Database existing registry ayrıca kontrol edilir. Race için unique constraint devam eder. Collision count metric raporlanır.

Transactional Persist

Entity ve slug kayıtları güvenli transaction ile yazılır. Büyük batch tek dev transaction olmamalıdır. Chunked commit kullanılabilir. Failure retry queue'ya gider. Partial duplicate oluşmamalıdır.

100.000 Ürün İçin Slug Üretimi Nasıl Ölçeklenir?

Yüz bin ürün için string normalization CPU açısından genellikle zor değildir. Asıl konu database lookup, unique reservation ve idempotency'dir. Batch processing ve paralel worker throughput'u artırabilir. Unique constraint concurrency güvenliği sağlar. Metric'ler throughput, collision ve retry oranını göstermelidir.

Batch Processing

Kayıtlar belirli chunk'lara ayrılır. Memory kullanımı kontrol altında kalır. Database round-trip toplu yapılabilir. Transaction süresi yönetilebilir. Failed batch tekrar çalıştırılabilir.

Parallel Workers

Worker sayısı CPU ve database kapasitesine göre belirlenir. Aynı entity iki worker'a verilmemelidir. Collision unique index ile güvenli kalır. Çok fazla worker lock contention oluşturabilir. Throughput benchmark yapılmalıdır.

Unique Constraint

Parallel generation'ın son doğrulamasıdır. Application cache'e güvenilmez. Conflict error expected branch olarak ele alınır. Composite uniqueness doğru scope'ta tanımlanır. Index performansı izlenir.

Retry Queue

Transient DB error veya collision retry queue'ya alınabilir. Retry reason kayıt edilir. Infinite retry engellenir. Poison record manual review'a gider. Queue depth monitoring yapılır.

Performance Metrics

Generated slug per second ölçülebilir. Collision rate katalog kalitesi hakkında bilgi verir. Retry latency ve DB conflict oranı izlenir. Batch duration release planına girdi olur. Memory ve connection pool kullanımı takip edilir.

Aynı Import İkinci Kez Çalışırsa Ne Olmalı?

İkinci import idempotent davranmalıdır. Existing product yeniden oluşturulmamalıdır. Current slug aynı kalmalıdır. Product title değişmiş olsa bile immutability policy nedeniyle gereksiz redirect oluşmamalıdır. Import sonucu mümkün olduğunca ilk başarılı çalışmayla aynı entity state'ini korumalıdır.

Idempotency

Aynı external record bir kez etkili olmalıdır. External ID idempotency key görevi görebilir. Repeat import duplicate product üretmez. Update değişen business field'ları uygular. URL lifecycle ayrı policy izler.

Existing Entity Detection

Product mapping table üzerinden bulunur. Title eşleşmesine güvenilmez. Existing ID bulunduğunda create branch çalışmaz. Soft-deleted entity handling business rule'a göre yapılır. Duplicate external IDs reject edilir.

Current Slug Reuse

Existing entity'nin stored current slug'ı korunur. Normalizer yeniden çalıştırılsa bile output farklı olsa URL otomatik değişmez. Manual migration ayrı işlem gerektirir. Böylece algorithm version update import sırasında churn yaratmaz. URL snapshot stabil kalır.

Gereksiz Redirect Oluşturmamak

Product rename redirect trigger olmamalıdır. Only explicit slug change history üretir. Repeat import no-op URL state bırakır. Redirect creation count anormal yükselirse alert oluşabilir. Idempotency testi CI içinde bulunmalıdır.

PIM ve ERP ile URL Sistemi Nasıl Entegre Edilir?

PIM ve ERP sistemleri ürün adları, kategoriler ve kimlik bilgileri sağlayabilir. Ancak external source'un her title update'i URL değişikliği yapmamalıdır. URL ownership e-ticaret platformunda veya merkezi URL service'te kalmalıdır. External product ID mapping stable integration sağlar. Slug update policy explicit field veya workflow üzerinden yönetilmelidir.

External Product ID

Source sistem kimliğini taşır. Internal entity ile mapping kurulur. Aynı ürün farklı source'lardan geliyorsa master data çözümü gerekir. ID değişikliği entity recreate anlamına gelmemelidir. Mapping audit edilmelidir.

Name Update

PIM başlığı güncelleyebilir. Product display title değişir. Slug varsayılan olarak sabit kalır. Explicit slug request yoksa URL history oluşmaz. UI current slug'ı ayrı gösterir.

Category Update

Taxonomy association değişebilir. Stable product URL kullanılıyorsa product path etkilenmez. Category-coupled model impact hesabı yapar. Bulk redirect gerekebilir. Import pipeline bunu sessizce yapmamalıdır.

Slug Update Policy

PIM özel slug alanı gönderebilir. Bunun authoritative olup olmadığı açıkça tanımlanmalıdır. Manual override korunabilir. Change 301 history üretir. Permission ve audit uygulanmalıdır.

Marketplace Feed URL'leri Nasıl Üretilmelidir?

Marketplace veya partner feed'leri mümkün olduğunca canonical product URL kullanmalıdır. Feed içinde eski veya redirect alan URL yayınlamak gereksiz hop oluşturur. Locale doğru seçilmelidir. Tracking parameter gerekiyorsa canonical identity yine temiz kalmalıdır. Feed exporter central URL resolver çağırmalıdır.

Canonical Product URL

Current product URL feed'e yazılır. Redirect source kullanılmaz. Product ID resolver'a verilir. Locale marketplace hedefiyle uyumlu seçilir. Absolute domain production config'ten gelir.

Stable URL

Feed URL sürekli değişmemelidir. Product title update feed address'i değiştirmemelidir. Partner cache ve ranking sinyalleri korunur. Manual slug change feed refresh gerektirir. Version history support süresince 301 çalışır.

Locale

Marketplace ülkesine uygun locale URL seçilir. en-gb veya tr-tr gibi mapping olabilir. Product availability region policy ile kontrol edilir. Unsupported locale fallback yapılmamalıdır. Hreflang ve feed aynı registry kaynağını kullanır.

Tracking Parameters

Partner attribution için parameter eklenebilir. Bu parameter product canonical identity'sinin parçası değildir. Feed URL track edilebilir halde olabilir. Landing page canonical temiz current URL'yi gösterir. Parameter order standardize edilir.

Google Merchant Feed ile Site URL'si Tutarlı Olmalı mı?

Merchant feed URL'sinin kullanıcıyı doğrudan mevcut ve ilgili ürün sayfasına götürmesi gerekir. Redirect üzerinden sürekli dolaştırmak gereksizdir. Variant teklif gönderiliyorsa ilgili variant state temsil edilebilir. Canonical policy site içinde tutarlı kalmalıdır. Feed generator current URL resolver kullanmalıdır.

Canonical Product URL

Base product teklifinde current canonical URL kullanılabilir. Slug history source yayınlanmaz. Locale ve domain doğru olmalıdır. Availability page content ile eşleşmelidir. Feed validation otomatik yapılabilir.

Variant URL

Variant-specific feed item gerekiyorsa selected variant parameter veya stable variant URL kullanılabilir. Sayfa ilgili varyantı varsayılan seçmelidir. Canonical business policy'ye göre ana ürün olabilir. Feed ve landing data tutarlı olmalıdır. Variant ID stable kalmalıdır.

Redirectlerden Kaçınmak

Feed eski URL taşımamalıdır. Slug change sonrası export cache invalidate edilir. 301 backup olarak kalır ama primary feed current path'i kullanır. Redirect hop latency ve diagnostic sorun yaratır. Automated feed crawler current status kontrol edebilir.

Slug Değişikliğinde Cache Nasıl Yönetilir?

Slug change yalnız database değişikliği değildir. CDN, application, sitemap, feed ve search index cache'leri eski URL'yi tutabilir. Invalidation event publish edilmelidir. Consumer servisler current path'i yeniden üretir. Cache invalidation başarısızlığı canonical mismatch oluşturabilir.

CDN Cache

Eski URL cache'te 200 response tutmamalıdır. Purge veya versioned routing yapılabilir. Yeni path ilk request'te origin'den gelir. Redirect response cache edilebilir. Purge API failure monitoring gerekir.

Application Cache

Entity ID to URL cache invalidated edilir. Current slug update event publish edilebilir. TTL tek başına uzun süre mismatch bırakabilir. Distributed cache key locale içerir. Stale cache request eski URL üretmemelidir.

Sitemap Cache

Sitemap generator new current URL'yi yayınlamalıdır. Eski URL hızla çıkarılmalıdır. Large sitemap chunk rebuild gerekebilir. Incremental update kullanılabilir. Lastmod slug değişikliğine göre güncellenebilir.

Feed Cache

Marketplace ve merchant feed cached URL tutabilir. Slug change sonrası ilgili product records invalidate edilmelidir. Bulk change full feed regeneration gerektirebilir. Partner delivery timestamp izlenir. Redirect backup devam eder.

Search Index

Site içi search document current URL saklıyorsa update edilmelidir. Alternatif olarak result rendering resolver çağırabilir. Stored URL stale risk taşır. Product ID saklamak daha güvenlidir. Reindex event slug change'e bağlanabilir.

Headless Commerce Sistemlerinde URL Üretimi

Headless commerce yapısında frontend router, commerce backend ve CMS ayrı sistemlerde olabilir. URL mantığını yalnız frontend'e bırakmak tutarsızlık yaratabilir. Merkezi registry veya canonical service bu katmanları ortak sözleşmede buluşturur. CMS title değişikliği URL lifecycle'ını otomatik değiştirmemelidir. API response current URL metadata taşıyabilir.

Frontend Router

Incoming path'i parse eder. Product lookup için backend resolver çağrılabilir. Current slug ile request slug karşılaştırılır. Eski slug ise server-side redirect üretilir. Canonical metadata aynı resolver'dan gelir.

Commerce Backend

Entity identity ve catalog lifecycle burada yönetilir. Slug create ve update policy uygulanabilir. URL registry ayrı servis olsa bile backend events yayınlar. External PIM mapping burada bulunabilir. Product delete tombstone tetikler.

CMS

Editorial title ve SEO content yönetir. Slug manual override yetkisi sınırlı olabilir. CMS preview current URL'yi resolver'dan alır. Title update URL'yi otomatik değiştirmez. Locale translation ayrı field'larda tutulur.

URL Registry

Tüm entity current ve historical paths saklanır. Multiple frontend aynı source'u kullanır. Unique ownership merkezi enforce edilir. Redirect lookup hızlı index üzerinden yapılır. API veya shared DB erişim modeli seçilebilir.

Canonical Service

Absolute URL üretimini standardize eder. Domain, locale ve route policy uygular. Frontend head metadata bu servisten gelir. Sitemap ve feed aynı endpoint'i kullanabilir. High availability önemli hale gelir.

Next.js E-Ticaret Sisteminde Slug Mimarisi

Next.js dynamic route yapısı slug tabanlı product URL'leri kolayca destekler. Ancak framework route'u yalnız URL yaşam döngüsünün giriş noktasıdır. Product lookup ID ve URL registry ile ilişkilendirilmelidir. Eski slug server-side redirect üretmelidir. Canonical metadata central resolver üzerinden oluşturulmalıdır.

Dynamic Route

[slug] benzeri segment incoming value'yu alır. Locale prefix route yapısına eklenebilir. Route handler raw slug'a güvenmez. Normalize lookup veya registry query yapılır. Unknown path 404 veya tombstone davranışı üretir.

Product Lookup

Current veya historical path registry'den bulunur. Current ise product ID alınır. Historical ise redirect target hesaplanır. Direct product table slug lookup history support etmeyebilir. Registry abstraction daha esnek olur.

Slug Validation

Request slug current slug ile karşılaştırılır. Case veya trailing separator varyantı varsa canonical redirect yapılabilir. Unknown encoded form security açısından validate edilir. Reserved route dynamic handler'a düşmemelidir. 404 ve 410 ayrımı policy'ye bağlıdır.

Redirect Eski Slug

History match varsa permanent redirect döndürülür. Target central resolver'dan gelir. Chain olmamalıdır. Server component veya edge layer kullanılabilir. SEO regression test response status'u doğrular.

Canonical

Metadata generation current entity URL'sini kullanır. Incoming old slug canonical üretip 200 dönmemelidir; ideal olarak redirect eder. Query tracking parameter temizlenir. Locale alternates registry'den alınır. Staging domain engellenmelidir.

Laravel E-Ticaret Sisteminde Slug Mimarisi

Laravel route model binding slug lookup için kullanılabilir ancak historical URL desteği ayrıca tasarlanmalıdır. Slug service normalization ve uniqueness logic'ini merkezi tutmalıdır. Database unique constraint zorunludur. Redirect history ayrı model olabilir. Product title observer'ın otomatik slug değiştirmesi genellikle engellenmelidir.

Route Model Binding

Route binding current slug üzerinden product bulabilir. Historical slug için custom resolver gerekebilir. Product not found durumunda redirect registry kontrol edilir. Locale scope query'ye dahil edilmelidir. Binding yalnız raw title transform yapmamalıdır.

Slug Service

Normalizer, collision resolver ve reservation işlemleri service içinde toplanır. Controller bu logic'i tekrar etmez. Locale policy dependency olarak verilebilir. Unit test service'i doğrudan test eder. Algorithm version dokümante edilebilir.

Unique Constraint

Migration ile database uniqueness tanımlanır. Compound index locale ve namespace içerebilir. Duplicate existing records deploy öncesi temizlenir. Conflict exception özel handling alır. Transaction retry uygulanabilir.

Redirect History

Old path ayrı table'da tutulur. Middleware request path'i kontrol edebilir. Target current entity URL resolver'dan alınır. HTTP 301 response üretilir. Chain flattening scheduled command olabilir.

Django E-Ticaret Sisteminde Slug Mimarisi

Django SlugField temel validation sağlayabilir ancak kurumsal URL lifecycle için tek başına yeterli değildir. Entity ID ve slug ayrılmalıdır. Unique constraint locale scope ile tanımlanabilir. get_absolute_url central resolver mantığına bağlanabilir. Rename sırasında save method içinde otomatik slug yenilemek stabiliteyi bozabilir.

SlugField

SlugField URL-safe text saklamak için kullanılabilir. Unicode davranışı configuration'a göre değerlendirilebilir. Custom validator reserved words kontrol edebilir. Normalization create service'te yapılmalıdır. Field tek başına collision resolution çözmez.

Model ID

Product primary key slug'dan bağımsızdır. URL change ID'yi etkilemez. Foreign key ilişkileri stabil kalır. API serialized product ID kullanabilir. Slug history aynı product'a bağlanır.

Unique Constraint

Meta constraints locale ve slug üzerinde tanımlanabilir. Partial current slug constraint uygulanabilir. Database authoritative olur. IntegrityError retry branch'ini tetikler. Test parallel create senaryosu içermelidir.

get_absolute_url

Model current URL üretmek için resolver çağırabilir. Route name hard-coded olabilir ama slug formatting burada yapılmamalıdır. Locale context gerektiğinde açık parametre kullanılır. Sitemap aynı URL helper'ı kullanabilir. Historical path üretmez.

Node.js / TypeScript Slug Service

TypeScript ile slug service core normalizer, resolver, repository ve redirect service olarak modüler tasarlanabilir. Pure normalization function kolay test edilir. Repository database uniqueness ve transaction işlemlerini yönetir. Resolver yalnız current URL üretir. Redirect service historical ownership'i kontrol eder.

Normalizer

Pure function input, locale ve policy alır. Unicode ve case normalization uygular. Symbol ve separator davranışı deterministic olur. Database erişimi yapmaz. Golden test set bu modülü kapsar.

Resolver

Entity ID ve locale üzerinden current path üretir. Repository current slug sağlar. Route template config'ten alınır. Absolute URL gerektiğinde domain service kullanır. Sitemap ve API aynı resolver'a bağlanır.

Repository

URL registry persistence işlemlerini soyutlar. Unique reservation transaction içinde yapılır. Historical lookup destekler. Database-specific query code burada kalır. Unit ve integration test ayrılır.

Redirect Service

Old path'ten target entity veya path bulur. Chain flattening uygular. Redirect type döndürür. Tombstone durumunda 410 behavior seçebilir. Metrics redirect frequency kaydeder.

Slug Üretimi İçin En İyi Programlama Dili Hangisidir?

Slug üretmek için tek en iyi programlama dili yoktur. Algoritmanın deterministik, Unicode-aware ve test edilmiş olması dilden daha önemlidir. Kullanılan e-ticaret stack'i dil seçimini belirler. Frontend ve backend farklı diller kullanıyorsa aynı slug algoritmasını iki yerde kopyalamak yerine merkezi service daha güvenlidir. Büyük sistemlerde database constraint ve URL contract programlama dilinden daha kritik rol oynar.

Tek Bir En İyi Dil Var mı?

Hayır. String işleme hemen her modern dilde yapılabilir. Önemli olan locale API'lerinin doğru kullanılmasıdır. Test ve database integration güçlü olmalıdır. Ekip mevcut stack'te bakım yapabilmelidir.

JavaScript / TypeScript

Web ve Node.js sistemlerinde doğal seçimdir. Unicode string API'leri yeterlidir. TypeScript policy ve result tiplerini açık tutar. Shared package frontend ve backend'de kullanılabilir. Ancak URL ownership database tarafında korunmalıdır.

Node.js

API ve batch worker geliştirmek için kullanılabilir. Async database işlemleri bulk import'a uygundur. Worker concurrency sınırlandırılmalıdır. Central slug service kolay kurulabilir. Property-based testing library'leri kullanılabilir.

Next.js

Frontend routing ve server rendering aynı projede bulunabilir. URL resolver server tarafında kullanılabilir. Dynamic route hızlı geliştirilir. Canonical metadata central policy'den gelir. Product title'ı component içinde slug'a çevirmekten kaçınılmalıdır.

PHP

Birçok e-ticaret ve CMS altyapısında PHP yaygındır. Unicode extension ve locale handling doğru kullanılmalıdır. Slug service framework'ten bağımsız tasarlanabilir. Database transaction ve unique constraint kolay uygulanır. Batch import queue ile ölçeklenebilir.

Laravel

Service container slug normalizer'ı yönetebilir. Eloquent events bilinçli kullanılmalıdır. Queue bulk import için uygundur. Migration unique constraint tanımlar. Redirect middleware URL history ile entegre olabilir.

E-ticaret CMS'leri

Mevcut CMS kendi slug ve rewrite mekanizmasına sahip olabilir. Custom logic core sistemi bypass etmemelidir. Plugin veya extension point kullanılmalıdır. Upgrade sonrası regression test yapılmalıdır. Canonical ve sitemap modülleri aynı URL source'a bağlanmalıdır.

Python

Python Django ve batch processing için uygundur. Unicode işleme güçlüdür. Data import script'leri kolay yazılır. Deterministic normalizer pure function olarak tasarlanabilir. Production route logic ayrı service ile paylaşılmalıdır.

Django

Model ve route yapısı slug alanlarını kolay destekler. SlugField temel sağlar. History ve tombstone custom model ister. Transaction.atomic reservation için kullanılabilir. get_absolute_url central resolver'a bağlanabilir.

Batch processing

PIM export büyük dataset Python ile işlenebilir. Chunked processing memory kullanımını kontrol eder. Parallel worker database limitine göre ayarlanır. Golden test aynı normalizer package üzerinde çalışır. Idempotent import zorunludur.

Java / .NET

Enterprise commerce platformlarında yaygın olabilir. Strong typing büyük domain modelinde avantaj sağlar. Locale ve Unicode API'leri güçlüdür. Transaction ve distributed service mimarisi uygulanabilir. URL service ayrı mikroservis olarak çalıştırılabilir.

Enterprise commerce

Büyük katalog ve çoklu bölge desteği sık görülür. PIM ve ERP integration karmaşık olabilir. URL registry merkezi service haline gelebilir. Event-driven cache invalidation kullanılır. Governance ve rollout süreçleri daha formal olabilir.

Slug Generator Unit Testleri Nasıl Yazılır?

Slug generator deterministic olduğu için unit test açısından ideal bir bileşendir. Normal ürün, Türkçe karakter, emoji, boşluk ve reserved word örnekleri test edilmelidir. Sadece birkaç happy path yeterli değildir. Empty input ve collision integration testleri ayrıca bulunmalıdır. Her bug fix golden test setine yeni örnek eklemelidir.

Normal Ürün Adı

Basit ASCII title beklenen slug'a dönüşmelidir. Lowercase doğrulanır. Separator davranışı kontrol edilir. Model number korunur. Aynı çağrı her seferinde aynı output verir.

Türkçe Karakter

Ş, İ, ı, ç, ğ, ö ve ü test edilmelidir. Locale-aware lowercase doğrulanır. ASCII ve Unicode policy ayrı test edilir. NFC ve NFD input aynı sonuç vermelidir. Environment locale sonucu değiştirmemelidir.

Emoji

Emoji aradaki kelimeleri bozmadan kaldırılmalıdır. Tam emoji input fallback üretmelidir. Multiple emoji duplicate tire oluşturmamalıdır. Variation selector edge case test edilebilir. Output boş olmamalıdır.

Çoklu Boşluk

Birden fazla space tek tireye dönüşmelidir. Tab ve newline da whitespace kabul edilebilir. Leading ve trailing space temizlenmelidir. Non-breaking space test edilmelidir. Output deterministic kalır.

Çoklu Tire

Input içindeki --- tek tire olmalıdır. Symbol removal sonrası oluşan duplicate separator temizlenmelidir. Leading ve trailing tire kalmamalıdır. Unicode dash varyantları policy'ye göre normalize edilebilir. Invariant testleri bunu kontrol eder.

Empty Input

Boş string empty slug üretmemelidir. Fallback public ID kullanılabilir. Validation error da tercih edilebilir. Policy entity type'a göre tanımlanmalıdır. Production'da “/urun/” gibi invalid route oluşmamalıdır.

Reserved Word

Input “admin” ise final slug doğrudan admin olmamalıdır. Disambiguator eklenebilir. Reserved registry mock ile test edilebilir. Locale-specific reserved word ayrıca denenebilir. Database reservation yapılmadan önce guard çalışmalıdır.

Golden Slug Test Seti

Golden set, input ve beklenen output çiftlerini version control altında tutar. Algoritma değişikliğinin URL etkisini hızlı biçimde gösterir. Gerçek katalog edge case'leri zamanla sete eklenmelidir. Locale policy değişiklikleri explicit snapshot update gerektirir. Bu yöntem beklenmeyen migration riskini önemli ölçüde azaltır.

Şık Çocuk Gömleği

Türkçe karakterlerin büyük bölümünü aynı anda test eder. ASCII policy sik-cocuk-gomlegi gibi sonuç verebilir. Unicode policy farklı output üretir. Locale lowercasing doğrulanır. NFC/NFD varyantları eklenebilir.

İstanbul T-Shirt

Büyük İ karakteri için kritik testtir. Hyphen ve mixed language content içerir. ASCII output istanbul-t-shirt olabilir. Generic lowercase regression yakalanır. Separator normalization kontrol edilir.

Samsung Galaxy S25+

Plus sembolünün semantic mapping'ini test eder. Model number korunur. Beklenen output samsung-galaxy-s25-plus olabilir. S25 ile collision oluşmaması doğrulanır. Length truncation suffix'i kaybetmemelidir.

H&M Elbise

Ampersand mapping policy'yi test eder. h-and-m-elbise veya seçilen başka standard beklenebilir. Blind removal değişik output üretir. Brand-specific değil generic semantic mapping tercih edilir. Golden result sabit kalmalıdır.

%100 Pamuk Tişört

Yüzde sembolü ve Türkçe karakterleri birlikte test eder. “yuzde-100-pamuk-tisort” örnek policy olabilir. Leading symbol kaldırma problemi görülür. Number preservation doğrulanır. Locale mapping test edilir.

Nike Air Max™ 90

Trademark symbol removal test edilir. Beklenen slug nike-air-max-90 olabilir. Removal duplicate separator oluşturmamalıdır. Number korunur. Brand ve model kelimeleri aynı sırada kalır.

Slug Algorithm Invariant'ları

Invariant, belirli input ne olursa olsun her output için geçerli olması gereken kurallardır. Property-based testing bu kuralları binlerce rastgele string üzerinde doğrulayabilir. Slug boş olmamalı, separator ile başlamamalı ve duplicate separator içermemelidir. Namespace uniqueness database ile garanti edilir. Bu kurallar algoritmanın davranışını örnek testlerden daha geniş ölçekte güvence altına alır.

Aynı Input Aynı Base Slug'ı Üretir

Determinism temel invariant'tır. Random değer normalizer içinde kullanılmaz. Environment locale sonucu değiştirmez. Policy version aynıysa output aynı kalır. Snapshot test bunu doğrular.

Slug Boş Olmaz

Emoji veya sembol-only input boş sonuç verebilir. Fallback ID veya validation error devreye girer. Empty path production'da publish edilmez. Reserved route ile karışmaz. Property test random punctuation üretir.

Separator ile Başlamaz

Leading separator final trim'de temizlenir. Input başındaki boşluk veya punctuation bunu bozmamalıdır. Unicode dash de ele alınabilir. Regex invariant kolay kontrol edilir. Route double slash oluşmaz.

Separator ile Bitmez

Trailing cleanup her output'ta çalışır. Symbol removal sonrası kalan tire kaldırılır. Length truncation da yeni trailing separator bırakmamalıdır. Property test random uzun string kullanabilir. URL quality artar.

Duplicate Separator İçermez

Ardışık tire tek tireye normalize edilir. Multiple spaces ve punctuation aynı sonucu verir. Truncation sonucu double separator oluşmamalıdır. Regex ile kolay assertion yapılabilir. Human readability korunur.

Namespace İçinde Unique'dir

Bu invariant pure normalizer değil persistence layer tarafından garanti edilir. Database unique constraint kullanılır. Collision resolver alternate candidate üretir. Parallel create testi yapılır. Tombstone kayıtlar occupancy sayılır.

Property-Based Testing Nasıl Kullanılır?

Property-based testing tek tek örnekler yerine geniş input alanı üzerinde invariant'ları test eder. Unicode ve özel karakter problemi için özellikle değerlidir. Rastgele uzun string ve collision kombinasyonları üretilebilir. Failing input otomatik küçültülerek reproduce edilebilir hale gelir. Slug engine gibi string algoritmalarında yüksek hata yakalama gücü sunar.

Rastgele Unicode Input

Farklı script ve combining mark üretilir. Normalizer crash etmemelidir. Output valid UTF-8 veya ASCII policy'ye uymalıdır. Invariant'lar her örnekte geçerli kalır. Unicode normalization bug'ları bulunabilir.

Çok Uzun Input

Binlerce karakterlik title üretilebilir. Slug length limit aşılmamalıdır. Word boundary behavior test edilir. Memory ve CPU olağan dışı artmamalıdır. Suffix preservation doğrulanır.

Özel Karakter Kombinasyonları

Slash, emoji, ampersand ve whitespace karışımları test edilir. Output route-safe olmalıdır. Duplicate separator oluşmamalıdır. Empty result fallback çalışmalıdır. Security edge case'leri yakalanabilir.

Collision Fuzzing

Farklı input'ların aynı base slug'a düşmesi simüle edilir. Resolver unique final output üretmelidir. Parallel transaction testine bağlanabilir. Retry limit aşılmamalıdır. Deterministic suffix davranışı doğrulanır.

URL Regression Testing Nedir?

URL regression testing deployment öncesi ve sonrası aynı entity setinin public URL'lerini karşılaştırır. Slug algorithm, route template veya locale library değişikliği beklenmeyen binlerce URL farkı yaratabilir. Snapshot diff bu sorunu production'a çıkmadan gösterir. Intentional change whitelist edilebilir. Redirect mapping olmayan değişiklik deployment'ı durdurabilir.

Yeni Deployment Öncesi URL Snapshot

Production-like dataset üzerinden entity ID ve current URL listesi alınır. Locale ayrı sütun olur. Snapshot artifact olarak saklanır. Redirect sources ayrıca export edilebilir. Test deterministic olmalıdır.

Deployment Sonrası URL Snapshot

Yeni code aynı dataset üzerinde çalıştırılır. Current URL listesi tekrar üretilir. Environment config aynı domain yerine relative path karşılaştırabilir. New algorithm effect görünür olur. Diff pipeline tarafından hesaplanır.

Beklenmeyen URL Değişikliklerini Bulmak

Changed URL listesi intention file ile karşılaştırılır. Product title update nedeniyle oluşan fark regression sayılır. Explicit migration approved olabilir. Redirect mapping var mı kontrol edilir. Threshold aşılırsa release engellenebilir.

URL Diff Testi

URL diff yalnız değişen path'leri değil eklenen ve kaldırılan adresleri de gösterir. Her değişen URL için redirect varlığı kontrol edilebilir. Yeni URL reserved veya collision durumuna bakılır. Kaldırılan URL tombstone veya redirect policy'ye uymalıdır. Bu test büyük migration projelerinde vazgeçilmezdir.

Yeni URL

New entity veya approved migration sonucu olabilir. Collision kontrol edilmelidir. Sitemap eligibility belirlenir. Canonical self-reference doğrulanır. Unexpected new URL churn işareti olabilir.

Kaldırılan URL

Entity deleted veya URL migrated olabilir. 404 yerine 410 veya redirect policy değerlendirilir. Sitemap'ten çıkarılmalıdır. Internal links kalmamalıdır. Backlink etkisi incelenebilir.

Değişen URL

Old ve new path entity ID ile eşleştirilir. Change reason bulunmalıdır. Slug update approved değilse regression olabilir. Cache invalidation planı gerekir. Analytics annotation yapılabilir.

Redirect Mevcut mu?

Old path için 301 mapping doğrulanır. Target direkt current URL olmalıdır. Loop ve chain olmamalıdır. HTTP test gerçek response'u kontrol eder. Missing redirect release blocker olabilir.

SEO Regression Testlerinde Neler Kontrol Edilmelidir?

URL regression yalnız path string karşılaştırması değildir. HTTP status, canonical, sitemap, internal link ve redirect behavior birlikte test edilmelidir. Bir URL doğru görünse bile canonical eski adrese işaret edebilir. Sitemap redirect source yayınlayabilir. Otomatik crawler bu tutarsızlıkları release öncesi yakalayabilir.

HTTP Status

Current URL 200 dönmelidir. Historical URL 301 almalıdır. Deleted URL policy'ye göre 404 veya 410 olabilir. Redirect source 200 dönmemelidir. Server error oranı ayrıca izlenir.

Canonical

Current page canonical current absolute URL'yi göstermelidir. Tracking parameter canonical'dan çıkarılmalıdır. Redirect page canonical content render etmemelidir. Locale canonical doğru host kullanmalıdır. Canonical mismatch dashboard'a düşmelidir.

Sitemap

Sitemap yalnız current ve indexable URLs içermelidir. Redirect sources çıkarılmalıdır. 404 URL olmamalıdır. Locale mapping doğru olmalıdır. Sitemap cache release sonrası yenilenmelidir.

Internal Links

Rendered HTML current URL'leri linklemelidir. Redirect üzerinden navigation yapılmamalıdır. Locale-aware link doğru route kullanmalıdır. Hard-coded old slug tespit edilebilir. Crawler internal redirect count hesaplayabilir.

Redirect

Old URL tek hop'ta current URL'ye gitmelidir. Status 301 olmalıdır. Location doğru scheme ve host kullanmalıdır. Loop bulunmamalıdır. Query tracking preservation policy gerekiyorsa test edilmelidir.

Slug Generator Observability

Slug sistemi production'da sessiz çalışan utility olarak bırakılmamalıdır. Generated count, collision, reserved hit ve change sayısı operasyonel sinyal sağlar. Ani collision artışı source data kalitesi problemine işaret edebilir. Slug update count artışı yanlış import policy'sini gösterebilir. Redirect creation trendi URL churn'ü erken fark etmeyi sağlar.

Generated Slug Count

Yeni oluşturulan slug sayısı günlük izlenebilir. Product import hacmiyle uyumlu olmalıdır. Ani artış duplicate entity creation gösterebilir. Entity type ve locale bazında segmentlenebilir. Dashboard baseline oluşturur.

Collision Count

Base slug collision oranı ölçülür. Yüksek oran title kalitesini veya truncation limitini gösterebilir. Deterministic resolver success rate izlenir. Database conflict ve pre-check collision ayrılabilir. Anormal trend alert üretir.

Reserved Slug Hit

Kaç input reserved word'e çarptı izlenir. New route deployment sonrası artış görülebilir. Import source değişikliği sinyal olabilir. Alternate slug generation başarı oranı tutulur. Manual review gerektiren kayıtlar listelenebilir.

Slug Update Count

Explicit slug değişikliği sayısı haftalık takip edilir. Normal product rename bu metriği artırmamalıdır. Bulk spike migration dışında şüphelidir. Change reason breakdown önemlidir. Product manager dashboard'a eklenebilir.

Redirect Creation Count

Slug değişikliği kadar redirect oluşturulmalıdır. Fark varsa history bug olabilir. Category move büyük spike yaratabilir. Expected migration window annotation yapılır. Redirect table growth kapasite planına dahil edilir.

URL Quality Dashboard

URL quality dashboard teknik SEO ve developer ekiplerinin ortak görünümüdür. Toplam public URL, duplicate path, redirect chain ve canonical mismatch gibi göstergeler burada takip edilir. Slug collision ve churn trendleri de eklenebilir. Dashboard yalnız Search Console verisine bağlı kalmamalıdır. Registry, crawler ve server log kaynakları birlikte kullanılmalıdır.

Toplam Public URL

Current indexable ve non-indexable URL sayıları ayrılabilir. Catalog büyümesiyle oran karşılaştırılır. Facet URL patlaması hızlıca görünür. Locale bazında dağılım incelenir. Sitemap count ile fark analiz edilir.

Duplicate Path

Registry unique constraint sayesinde idealde sıfır olmalıdır. Migration staging'de duplicate bulunabilir. Case-insensitive eşdeğer paths ayrıca taranır. Unicode normalized duplicate kontrol edilir. Any duplicate release blocker olabilir.

Redirect Chain

İki veya daha fazla hop alan URL sayısı ölçülür. Hedef sıfıra yakın olmalıdır. Chain source'ları flattening job'a gönderilir. External backlink yoğun path'ler önceliklendirilebilir. Trend deployment sonrası izlenir.

Redirect Loop

Loop sayısı her zaman sıfır olmalıdır. Synthetic crawler otomatik tespit eder. Registry graph validation ek güvence sağlar. Loop kullanıcı deneyimini tamamen bozar. Alert yüksek öncelikli olmalıdır.

Canonical Mismatch

Router URL, HTML canonical, sitemap ve resolver output karşılaştırılır. Fark varsa entity ID üzerinden root cause bulunur. Cache stale olabilir. Manual template hard-code problemi olabilir. Metric release kalite kapısı olarak kullanılabilir.

Slug Collision

Collision event sayısı katalog trendiyle izlenir. Çözülmemiş collision sıfır olmalıdır. Numeric suffix kullanım oranı ayrıca görülebilir. High collision belirli product category'de kümelenebilir. Model data quality iyileştirmesi yapılabilir.

URL Değişim Oranı Nasıl Ölçülür?

URL değişim oranı belirli dönemde current path'i değişen entity'lerin toplam entity sayısına oranıyla ölçülebilir. Normal bir e-ticaret sitesinde bu oran migration dönemleri dışında düşük olmalıdır. Product rename ve category move gibi nedenler ayrı izlenmelidir. Beklenmeyen churn SEO ve analytics kalitesini düşürür. Slug immutability bu metriği kontrol altında tutar.

Haftalık Slug Change

Haftalık toplam değişiklik sayısı baseline oluşturur. Migration olmayan haftalarda ani artış alert üretir. Locale bazında segmentlenebilir. Change reason breakdown yapılır. Team owner bulunur.

Product Rename

Product rename count ile slug change count karşılaştırılır. İdeal immutability modelinde doğrudan korelasyon olmamalıdır. Rename slug change tetikliyorsa bug olabilir. Import policy incelenir. Historical trend düzeltme sonrası takip edilir.

Category Move

Recursive URL modelinde move URL değişimi üretir. Kaç descendant etkilendiği ölçülmelidir. Move öncesi impact preview sağlanabilir. Large change approval gerektirebilir. Stable route alternatifinin değeri sayısal görülebilir.

Beklenmeyen URL Churn

Approved migration dışındaki değişiklikler churn olarak işaretlenebilir. Algorithm version veya locale library update root cause olabilir. URL diff change source'u gösterir. Churn threshold release blocker olabilir. Production incident olarak izlenebilir.

URL Churn Nedir?

URL churn, aynı içeriğin zaman içinde gereksiz yere sürekli yeni public URL almasıdır. Ürün başlığına bağlı computed slug sistemlerinde sık görülür. Churn search history, backlinks ve analytics continuity üzerinde olumsuz etki yaratabilir. Redirect registry hızla büyür. Slug immutability ve explicit change policy bu problemi büyük ölçüde önler.

Aynı İçeriğin Sürekli Yeni URL Alması

Product title her edit'te yeni slug üretebilir. Campaign kelimesi eklenip çıkarıldıkça path değişir. Entity aynı olmasına rağmen public identity dalgalanır. Bu behavior quality bug olarak kabul edilmelidir. URL lifecycle entity state'ten ayrılmalıdır.

SEO ve Analytics Etkisi

Search engine yeni URL'yi tekrar keşfetmek zorunda kalır. Redirect dependency artar. URL bazlı analytics raporları parçalanır. Shared links sürekli redirect alır. Technical debt büyür.

Slug Immutability ile Önlemek

Current slug stored olarak tutulur. Title update URL'yi etkilemez. Manual change açık action gerektirir. History otomatik oluşur. Churn metriği düşer.

Canonical Mismatch Nasıl Tespit Edilir?

Canonical mismatch farklı sistem bileşenlerinin aynı entity için farklı URL üretmesidir. Router current page'i açar fakat HTML canonical eski slug'ı gösterebilir. Sitemap başka route kullanabilir. Feed ve internal links ayrıca farklılaşabilir. Entity ID üzerinden bütün URL producer çıktıları karşılaştırılarak sorun otomatik tespit edilebilir.

Router URL

Gerçek request'in açıldığı current path'tir. Historical path 200 yerine redirect vermelidir. Router registry ownership kontrol eder. Request normalize variation varsa current path'e yönlenir. Baseline URL olarak kullanılabilir.

HTML Canonical

Page source içindeki absolute canonical URL'dir. Router current path ile eşleşmelidir. Tracking parameter dahil olmamalıdır. Locale doğru olmalıdır. Crawler canonical mismatch raporu oluşturabilir.

Sitemap URL

Sitemap entity için current URL yayınlar. Redirect veya tombstone içermez. HTML canonical ile aynı normalized URL olmalıdır. Domain ve scheme farkı da mismatch sayılır. Batch validation yapılabilir.

Internal Link URL

Navigation ve product card linkleri resolver'dan gelmelidir. Old slug internal redirect yaratır. Static template hard-code tespit edilmelidir. Crawler link target entity ID ile karşılaştırabilir. Internal redirect ratio quality metric olabilir.

Feed URL

Merchant ve marketplace feed current product URL kullanmalıdır. Feed cache eski slug tutabilir. Daily validator HTTP status kontrol edebilir. Redirect bulunan feed entry güncellenmelidir. Locale business target ile eşleşmelidir.

Sitemap URL'leri Nasıl Üretilmelidir?

Sitemap URL'leri URL registry'nin current ve indexable kayıtlarından üretilmelidir. Raw product title üzerinden yeniden slug hesaplanmamalıdır. Redirect ve tombstone paths hariç tutulmalıdır. Locale sitemap yapısı current mapping'i kullanmalıdır. Çok dilli sitemap mimarisi için https://www.diyarbakiryazilim.com.tr/posts/yapisal-coklu-dil-destekli-multi-language-site-haritasi-mimarisi adresindeki çalışma tamamlayıcı bir teknik çerçeve sunar.

URL Registry

Sitemap job registry query yapar. Entity active ve indexable olmalıdır. Current path alınır. Absolute host locale config'ten eklenir. Aynı resolver page canonical için de kullanılmalıdır.

Yalnız Current URL

Previous slug sitemap'e eklenmez. Redirect source search engine'e yeni discovery sinyali vermemelidir. Current path tek kayıttır. Duplicate URL dedupe edilmelidir. Snapshot test bunu doğrular.

Yalnız Indexable Entity

Noindex veya unavailable entity sitemap'te bulunmamalıdır. Facet whitelist ayrı data source olabilir. Product state business rule ile değerlendirilir. Temporary out-of-stock policy dikkatle seçilmelidir. Sitemap listing ile page robots çelişmemelidir.

Redirect URL'leri Hariç Tutmak

301 veren URL sitemap'te yayınlanmamalıdır. Crawler validation response status kontrol edebilir. History table records ayrı tutulur. Bulk migration sonrası sitemap regenerate edilir. Search engine current URLs'a daha net yönlendirilir.

Internal Linkler Nasıl Üretilmelidir?

Internal link sistemi current URL kullanımının en önemli kaynaklarından biridir. Template içinde product name'den slug hesaplamak ciddi hata kaynağıdır. Entity ID central URL helper'a verilmelidir. Locale context açık biçimde geçmelidir. Slug değiştiğinde bütün yeni render'lar otomatik current URL'yi kullanmalıdır.

Elle String Birleştirmemek

"/urun/" + slug gibi kod yüzlerce yerde kopyalanmamalıdır. Route template değişikliği büyük refactor gerektirir. Locale prefix unutulabilir. Old slug cache'te kalabilir. Helper veya resolver zorunlu hale getirilmelidir.

URL Helper Kullanmak

getProductUrl(entityId, locale) gibi helper kullanılabilir. Unit test merkezi logic'i kapsar. Frontend API current URL field alabilir. Helper fallback raw title generate etmemelidir. Missing registry kaydı error olarak izlenmelidir.

Current Slug Kullanmak

Historical slug internal linkte kullanılmaz. Resolver current record seçer. Redirect hop azaltılır. Search engine internal graph doğru URL'yi görür. Cache invalidation current change event ile çalışır.

Locale-Aware Link

Türkçe sayfadan Türkçe current URL'ye link verilmelidir. Cross-locale link intentional language switch dışında kullanılmamalıdır. Locale registry doğru slug sağlar. Hreflang ve internal navigation aynı mapping'i kullanır. Missing translation fallback policy uygulanır.

Slug Değiştiğinde Eski İç Linkler Nasıl Güncellenir?

301 redirect kısa vadede eski linkleri çalışır halde tutar. Ancak internal linklerin kalıcı olarak redirect üzerinden gitmesi doğru değildir. Kaynak content ve navigation linkleri current URL'ye güncellenmelidir. Central resolver kullanan dinamik linkler zaten otomatik düzelir. CMS içinde saklanan hard-coded links için link migration job gerekebilir.

Redirect Kısa Vadeli Güvence

Eski link kullanıcıyı kaybetmez. Search engine final target'a ulaşır. Deployment sırasında broken link önlenir. Ancak redirect kalıcı internal linking stratejisi değildir. Monitoring internal redirect hit sayısını izler.

Kaynak Linkleri Güncellemek

CMS rich text içindeki old path'ler taranabilir. Entity ID stored link modeli daha iyi alternatiftir. Navigation config current resolver kullanmalıdır. Sitemap zaten otomatik güncellenir. Partner-owned linkler 301 üzerinden yaşamaya devam edebilir.

Redirect Üzerinden İç Link Vermemek

Her internal redirect ekstra request oluşturur. Crawler graph eski URL'yi görür. User latency artabilir. Link validator 3xx target'ları raporlamalıdır. Release kalite metriği internal redirect oranı olabilir.

Search Console ile URL Sistemi Nasıl İzlenir?

Search Console URL mimarisinin search engine tarafından nasıl görüldüğünü anlamaya yardımcı olur. Duplicate, canonical ve crawled not indexed örnekleri URL policy hakkında sinyal verir. Ancak tek veri kaynağı olarak kullanılmamalıdır. Server log ve internal registry ile birlikte yorumlanmalıdır. URL pattern bazlı segmentasyon root cause bulmayı kolaylaştırır.

Duplicate URL

Duplicate reports facet veya parameter problemine işaret edebilir. Same product multiple paths kontrol edilir. Canonical selected ile declared farkı incelenir. Internal links duplicate path'e gidiyor olabilir. Resolver policy gözden geçirilir.

Redirect

Search engine hangi old URL'leri hâlâ crawl ediyor görülebilir. Migration sonrası beklenen davranış olabilir. Çok uzun süre yüksek hit internal veya external link kalıntısını gösterebilir. Redirect chain ayrıca kontrol edilir. Sitemap old URL içermemelidir.

Canonical

Declared canonical ile selected canonical farkları analiz edilir. Mismatch aynı content'in farklı URL'lerinden kaynaklanabilir. Hreflang veya sitemap sinyalleri çelişebilir. Page source test edilir. Central resolver consistency doğrulanır.

Crawled Not Indexed

Filter ve thin variant URLs bu grupta yoğunlaşabilir. Indexable facet policy gözden geçirilmelidir. Duplicate product paths olabilir. Content quality ayrı faktördür. URL pattern segmentasyonu problemi daraltır.

URL Pattern Analizi

/urun/, /kategori/ ve parameter patterns ayrı incelenir. Unexpected query keys bulunabilir. Old migration prefix'leri crawl edilmeye devam ediyor olabilir. Search Console export log data ile karşılaştırılabilir. Pattern based alert kurulabilir.

Server Log ile Slug Problemleri Nasıl Tespit Edilir?

Server log gerçek crawler ve kullanıcı request'lerini gösterir. Eski slug hit'leri redirect dependency'yi ortaya çıkarır. 404 pattern yeni broken URL üretimini gösterebilir. Parameter crawl sonsuz URL alanını işaret edebilir. Log analizi Search Console'dan daha ayrıntılı teknik sinyal sağlayabilir.

Googlebot Eski URL Hits

Historical paths hit sayısı ölçülür. Migration sonrası zamanla azalması beklenir. Sürekli yüksekse external links veya stale sitemap araştırılır. Redirect status doğru olmalıdır. Chain varsa hızla düzeltilmelidir.

404 Slug Hits

404 path'ler normalize edilerek gruplandırılır. Typo, deleted product ve broken internal link ayrılır. High-frequency path için redirect gerekebilir. Tombstone policy uygulanabilir. Bot-generated random URL'ler ayrı sınıflandırılır.

Redirect Frequency

Toplam 301 oranı izlenir. Internal users gereksiz redirect alıyorsa link source bulunur. Migration traffic expected olabilir. Long-tail old URLs zamanla düşük seviyede kalabilir. CDN logs de dahil edilebilir.

Parameter Crawl

Unknown query keys crawler tarafından keşfedilebilir. Sort ve filter kombinasyonları patlayabilir. Canonical ve robots strategy gözden geçirilir. Internal link generator temiz URL kullanmalıdır. Parameter whitelist log analiziyle güncellenebilir.

URL Migration Projesi Nasıl Yapılır?

URL migration, yalnız yeni slug algoritmasını deploy etmek değildir. Önce mevcut URL envanteri çıkarılmalıdır. Old-to-new mapping hazırlanmalı ve redirect map test edilmelidir. Sitemap, internal links ve canonical aynı anda güncellenmelidir. Deployment sonrası server log ve indexing monitoring devam etmelidir.

Mevcut URL Envanteri

Product, category, brand ve facet URLs listelenir. HTTP status ve canonical kaydedilir. Backlink önemli URLs ayrıca işaretlenebilir. Duplicate paths bulunur. Current traffic baseline oluşturulur.

Yeni URL Algoritması

Normalizer ve route policy versionlanır. Golden test set çalışır. Existing entities için new candidate URLs üretilir. Collision ve reserved conflicts çözülür. Unexpected churn sayısı raporlanır.

Old → New Mapping

Entity ID üzerinden eski ve yeni path eşleştirilir. Silinen entity ayrı tutulur. Mapping duplicate target kontrolünden geçer. Locale ayrımı korunur. Manual review high-value pages için yapılabilir.

Redirect Map

Her old path final new path'e bağlanır. Chain ve loop validation yapılır. HTTP 301 kullanılır. CDN veya app routing formatına export edilir. Rollback backup saklanır.

Sitemap

Yeni current URLs ile regenerate edilir. Old URLs çıkarılır. Locale mappings doğrulanır. Indexable policy aynı kalmalıdır. Deployment ile aynı zaman penceresinde publish edilir.

Deployment

Feature flag kullanılabilir. Canary route subset test edilir. Redirect and canonical synthetic crawler ile doğrulanır. Cache invalidation yapılır. Monitoring dashboard active tutulur.

Monitoring

404, redirect hit ve indexing trendleri izlenir. Canonical mismatch alarmı kullanılır. High-value old URLs ayrıca kontrol edilir. Internal redirect count düşmelidir. Gerekirse rollback veya mapping düzeltmesi yapılır.

URL Algoritması Değiştirildiğinde Bütün URL'ler Yeniden Yazılmalı mı?

Çoğu durumda hayır. Daha güzel bir slug algoritması mevcut milyonlarca URL'yi değiştirmek için tek başına yeterli gerekçe değildir. Migration SEO ve operasyon riski taşır. Yeni algoritma yalnız yeni ürünlerde kullanılabilir. Legacy URL'ler stabil bırakılabilir veya kademeli migration yapılabilir.

SEO Kazancı ile Migration Riskini Karşılaştırmak

Mevcut URL'ler çalışıyor ve indekslenmiş olabilir. Küçük okunabilirlik iyileştirmesi büyük redirect projesini hak etmeyebilir. Backlink ve traffic riskleri ölçülmelidir. Technical debt gerçekten iş sonucu etkiliyor mu değerlendirilmelidir. Karar data ile verilmelidir.

Yeni Ürünlerde Yeni Algoritma

Algorithm version create timestamp sonrası uygulanabilir. Existing slug'lar korunur. URL registry her iki formatı destekler. New golden tests yeni policy'yi doğrular. Zamanla catalog doğal biçimde yeni standarda geçebilir.

Legacy URL'leri Korumak

Eski URL'ler current olarak kalabilir. Resolver format bağımsız entity ID ile çalışır. Canonical legacy current path'i gösterir. Sadece görünüm için migration yapılmaz. Security veya duplicate problemi varsa ayrı değerlendirme yapılır.

Kademeli Migration

High-value küçük subset seçilebilir. Redirect ve ranking trendi izlenir. Problem yoksa sonraki batch'e geçilir. Feature flag rollback sağlar. Bulk one-shot risk azaltılır.

Slug Migration İçin Rollback Planı

Migration başarısız olduğunda eski route yapısına dönebilmek gerekir. Previous route map ve redirect backup saklanmalıdır. Sitemap eski snapshot üzerinden yeniden yayınlanabilir. Feature flag yeni resolver'ı kapatabilir. Rollback planı deployment öncesi gerçek staging testinde denenmelidir.

Previous Route Map

Eski entity ID to URL mapping saklanır. Rollback sırasında current registry restore edilebilir. Database snapshot tek seçenek olmamalıdır. Mapping version tag taşımalıdır. Locale bazında korunmalıdır.

Redirect Backup

Migration öncesi redirect table export edilir. Yeni mapping ayrı version olarak tutulabilir. Rollback eski source-target ilişkisini geri yükler. Chain corruption engellenir. Backup restore testi yapılmalıdır.

Sitemap Backup

Eski sitemap snapshot saklanır. Rollback sonrası hızlı publish edilebilir. Host ve locale yapısı korunur. CDN cache purge edilir. Sitemap index version ile ilişkilendirilebilir.

Feature Flag

New URL resolver belirli trafik veya entity subset'ine açılabilir. Problemde anında old behavior'a dönülebilir. Data migration reversible değilse flag tek başına yetmez. Registry versioning ile birlikte kullanılmalıdır. Observability flag state'i loglamalıdır.

Open Source Slug Generator Nasıl Tasarlanabilir?

Açık kaynak slug generator yalnız replace fonksiyonundan ibaret olmamalıdır. Core normalizer saf ve bağımsız tutulabilir. Locale plugin'leri dil kurallarını ekler. Collision resolver interface uygulamanın database modelinden bağımsız kalır. Reserved word provider ve geniş test suite projenin gerçek kullanım değerini artırır.

Core Normalizer

Unicode, case, symbol ve separator logic'ini içerir. Database dependency taşımaz. Policy object üzerinden davranış alır. Deterministic output verir. Property-based tests bu modülü yoğun test eder.

Locale Plugins

Türkçe, Almanca veya başka dil kuralları plugin olarak eklenebilir. Transliteration map locale'e özeldir. Core package language-specific if zinciri içermez. Plugin versionlanır. Community yeni locale desteği sağlayabilir.

Collision Resolver Interface

Normalizer yalnız base slug üretir. Resolver availability ve disambiguator logic'ini soyutlar. PostgreSQL veya başka database adapter uygulanabilir. Deterministic strategy interface ile değiştirilebilir. Unit test fake registry kullanabilir.

Reserved Word Provider

Framework ve uygulama route'ları provider üzerinden gelir. Static list veya dynamic registry kullanılabilir. Locale-specific reserved values desteklenebilir. Test easily mock edilir. New framework adapter kendi defaults'unu sağlayabilir.

Test Suite

Golden, unit, property ve concurrency testleri bulunmalıdır. Türkçe Unicode edge case'leri ayrı fixture olabilir. Security input'ları test edilir. Benchmark performance regression gösterir. Contribution acceptance test zorunlu olabilir.

Open Source ve İş Birliği URL Kalitesini Nasıl Artırabilir?

Açık source yaklaşımı transliteration ve edge case kurallarının birçok geliştirici tarafından incelenmesini sağlar. Farklı framework'ler için adapter üretilebilir. Community code review Unicode ve routing hatalarını erken bulabilir. Açık test setleri behavior değişikliğini görünür hale getirir. URL kalitesi ortak deneyimle daha hızlı gelişebilir.

Ortak Transliteration Rules

Dil kullanıcıları gerçek kelime örnekleri sağlayabilir. Mapping hataları issue olarak raporlanabilir. Version change semver ile yönetilebilir. Backward compatibility dokümante edilir. Locale maintainers belirlenebilir.

Edge Case Testleri

Gerçek kataloglardan anonim edge case'ler eklenebilir. Unicode combining marks çeşitlenir. Emoji ve symbol örnekleri büyür. Regression coverage artar. Bug tekrar ortaya çıkmaz.

Framework Adapter'ları

Next.js, Laravel veya Django integration paketleri geliştirilebilir. Core behavior aynı kalır. Framework-specific routing ayrı katmanda tutulur. Community bakım paylaşır. Version compatibility matrix hazırlanır.

Community Code Review

Pull request farklı geliştiriciler tarafından incelenir. Security ve internationalization sorunları daha görünür olur. Tests discussion'ın merkezi olur. Breaking change kolayca fark edilir. Documentation quality de gelişir.

Diyarbakır Yazılım Topluluğu Gibi Yapılarda Örnek Slug Projesi

URL ve slug motoru, yazılım toplulukları için güzel bir açık kaynak çalışma konusudur çünkü string algoritmaları, database, concurrency, HTTP ve SEO aynı projede buluşur. TypeScript tabanlı core engine ile başlanabilir. Türkçe locale plugin ve PostgreSQL collision resolver eklenebilir. Redirect registry gerçek production kavramlarını öğretir. Benzer proje çalışmalarına https://www.diyarbakiryazilim.com.tr/projects adresinden ulaşabilirsiniz.

TypeScript Slug Engine

Pure normalizer TypeScript ile geliştirilebilir. Policy interfaces açık tanımlanır. Golden tests repository'de tutulur. npm package olarak yayınlanabilir. CLI input-output denemeleri sağlayabilir.

Turkish Locale Plugin

Türkçe lowercase ve transliteration kuralları plugin'e taşınır. NFC normalization uygulanır. Şık Çocuk Gömleği gibi fixtures bulunur. Unicode ve ASCII policy ayrı desteklenebilir. Community gerçek kelime örnekleri ekleyebilir.

PostgreSQL Collision Resolver

Unique index ile atomic reservation yapılır. Transaction conflict retry test edilir. Public ID suffix strategy uygulanabilir. Concurrent worker integration testi yazılır. Tombstone records occupancy olarak tutulur.

Redirect Registry

Old ve current path ilişkisi saklanır. 301 lookup endpoint yazılabilir. Chain flattening command eklenebilir. Cycle detection graph testleri yapılır. Audit metadata tutulur.

SEO Validator

Canonical, sitemap ve current URL karşılaştırılır. Redirect source sitemap'te mi kontrol edilir. Internal link crawler eklenebilir. URL churn raporu üretilebilir. CLI CI pipeline içinde çalışabilir.

Open Source Documentation

Architecture decision records tutulabilir. Locale policy açıklanır. Migration examples verilir. Contribution guide edge case eklemeyi öğretir. Proje yalnız kod değil öğrenme kaynağı haline gelir.

Yazılımcı Olmak İsteyenler Bu Projeden Ne Öğrenebilir?

Slug projesi küçük görünse de temel yazılım mühendisliği konularının çoğunu içerir. String processing ve Unicode doğrudan pratiğe dönüşür. HTTP redirect ve routing web altyapısını öğretir. Database constraints ve concurrency production güvenilirliği konusunda deneyim kazandırır. SEO gereksinimleri teknik tasarım kararlarının iş etkisini anlamayı sağlar.

String Algorithms

Tokenization ve normalization uygulanır. Regex sınırları görülür. Deterministic dönüşüm tasarlanır. Performance büyük input üzerinde ölçülür. Pure function test yaklaşımı öğrenilir.

Unicode

NFC ve NFD farkı pratikte görülür. Locale-aware lowercase kullanılır. Combining mark problemi anlaşılır. Encoding ve byte-length test edilir. Internationalization becerisi gelişir.

HTTP

200, 301, 404 ve 410 davranışları öğrenilir. Location header test edilir. Cache ve redirect ilişkisi görülür. Canonical HTTP status'tan ayrılır. Server log analizi yapılır.

Routing

Dynamic route ve namespace kavramları uygulanır. Reserved path problemi çözülür. Historical path lookup eklenir. Locale routing denenir. Route precedence test edilir.

Database Constraints

Unique index gerçek race condition'ı çözer. Transaction kullanılır. Composite key tasarlanır. Tombstone storage modellenir. Migration script yazılır.

Concurrency

Parallel create simulation yapılır. Race condition reproduce edilir. Retry strategy yazılır. Idempotency uygulanır. Load test sonuçları yorumlanır.

SEO

Canonical ve duplicate URL ilişkisi öğrenilir. Sitemap current URLs'dan üretilir. Redirect migration tasarlanır. Faceted navigation riski görülür. Search crawler behavior anlaşılır.

Testing

Unit, golden ve property-based testler uygulanır. URL snapshot regression yazılır. HTTP crawler test eklenir. CI quality gate oluşturulur. Test-driven design somut hale gelir.

İyi Bir E-Ticaret Geliştiricisi URL Sisteminde Neleri Bilmelidir?

E-ticaret geliştiricisinin URL'yi yalnız router konusu olarak görmemesi gerekir. URL standardı, HTTP redirect ve canonicalization temel web bilgisi olmalıdır. Database transaction ve Unicode slug güvenilirliğini doğrudan etkiler. Search engine crawling davranışı teknik kararların SEO sonucunu anlamayı sağlar. Bu birleşik bilgi URL hatalarının production'a çıkmasını önemli ölçüde azaltır.

URL Standardı

Path, query ve encoding kavramları anlaşılmalıdır. Reserved character davranışı bilinmelidir. Absolute ve relative URL farkı önemlidir. Normalization sonucu browser behavior test edilmelidir. URL parsing elle string split ile yapılmamalıdır.

HTTP Redirect

301 ve temporary redirect farkı bilinmelidir. Location header doğru target göstermelidir. Chain ve loop sorunları anlaşılmalıdır. Cache behavior test edilmelidir. Migration tasarımının parçası olmalıdır.

Canonicalization

Aynı content'in preferred URL'si belirlenir. Tracking parameters temizlenir. Canonical redirect yerine geçmez. Sitemap ve internal links ile uyumlu olmalıdır. Locale alternates doğru ilişkilendirilmelidir.

Database Transaction

Slug reservation race condition yaratabilir. Transaction ve unique index kullanımı bilinmelidir. Retry idempotent olmalıdır. Bulk import connection management gerektirir. Constraint violation doğru yorumlanmalıdır.

Unicode

Türkçe case conversion temel örnektir. NFC ve NFD farkı anlaşılmalıdır. Emoji ve combining mark test edilmelidir. Database collation davranışı incelenmelidir. Runtime locale'e güvenilmemelidir.

Search Engine Crawling

Duplicate URL ve parameter crawl riskleri bilinmelidir. Sitemap yalnız current URLs sunmalıdır. Internal link graph önemlidir. Server log crawler behavior gösterebilir. Search Console teknik sinyal sağlar.

Product Manager URL Sisteminde Neden Yer Almalıdır?

URL mimarisi yalnız developer veya SEO ekibinin kararı değildir. Product manager merchandising ve kategori lifecycle'ını bilir. Kategori yeniden düzenlemelerinin URL üzerindeki etkisini değerlendirebilir. Localization ve variant davranışı kullanıcı deneyimi kararıdır. Bu nedenle URL contract ürün gereksinimi olarak dokümante edilmelidir.

URL Bir Kullanıcı Deneyimi Kararıdır

Kullanıcı URL'yi paylaşabilir ve bookmark yapabilir. Okunabilirlik güven hissini etkiler. Selected variant state linkte korunabilir. Çok uzun veya sürekli değişen URL deneyimi bozar. Product requirement bu davranışları tanımlamalıdır.

Merchandising Değişiklikleri

Ürün title ve category sık değişebilir. Bu operasyonların URL değiştirmemesi için policy gerekir. Product manager edit flow'u bilir. Manual slug change approval belirlenebilir. Impact preview kullanıcıya gösterilebilir.

Kategori Yaşam Döngüsü

Taxonomy seasonal veya campaign nedeniyle değişebilir. Recursive URL bu değişiklikleri migration'a dönüştürebilir. Product manager frequency bilgisini architecture kararına taşır. Stable route seçimi buna göre yapılabilir. Redirect cost planlanır.

Lokalizasyon

Her dilde slug çevirisi gerekli olabilir. Translation team workflow ürün gereksinimidir. Missing locale behavior belirlenmelidir. Hreflang ve region routing kullanıcıya doğru deneyim sunmalıdır. Product manager locale rollout planını yönetebilir.

SEO ve Developer Ekibi Arasında URL Contract Nasıl Oluşturulur?

URL contract hangi entity'nin hangi route'u kullandığını, slug policy'yi, canonical ve redirect davranışını açıkça tanımlar. Böylece SEO talebi production code içinde yorumlanmaya bırakılmaz. Developer ekip test edilebilir teknik kurallar elde eder. Product manager değişikliğin kullanıcı etkisini görür. Contract version control altında tutulabilir.

Entity Type

Product, category, brand ve facet ayrılır. Her type farklı lifecycle taşıyabilir. Namespace ve indexability buna göre belirlenir. URL ownership scope yazılır. New entity type contract change gerektirir.

URL Template

/urun/{slug} gibi açık route formatı belirtilir. Locale prefix ve domain policy eklenir. Category recursive olup olmadığı yazılır. Variant representation tanımlanır. Template string koddan bağımsız dokümante edilir.

Slug Policy

ASCII veya Unicode seçimi belirtilir. Locale lowercasing ve symbol mapping açıklanır. Length ve reserved word rule eklenir. Collision strategy tanımlanır. Slug immutability kararı yazılır.

Canonical Policy

Product main URL ve variant canonical davranışı belirtilir. Tracking parameter removal listesi yazılır. Pagination ve facets ayrı policy alır. Locale canonical self-reference tanımlanır. Sitemap ile aynı resolver zorunlu tutulur.

Redirect Policy

Slug change 301 oluşturur. Deleted content 410 veya replacement redirect davranışı tanımlanır. Chain maximum bir hop olmalıdır. Tombstone reuse yasak olabilir. Migration testing zorunlu hale getirilir.

Parameter Policy

Allowed filter keys belirtilir. Tracking keys canonical'dan çıkarılır. Ordering algorithm yazılır. Multi-value serialization standardı tanımlanır. Indexable facets whitelist ile yönetilir.

Örnek Product URL Contract

Product URL contract küçük ve net kurallarla başlayabilir. Route /urun/{slug} olabilir. Entity identity Product ID'dir. Slug persistent tutulur. Product rename otomatik URL değişikliği yapmaz ve manual slug update 301 redirect üretir.

Route

Product detail pages tek route namespace altında bulunur. Route locale prefix ile genişleyebilir. Product resolver central registry kullanır. Historical path redirect service'e gider. Reserved namespace product slug'ından ayrıdır.

/urun/{slug}

Slug current stored değerdir. Runtime title'dan hesaplanmaz. Router slug'dan product ID bulur. Eski slug match olursa 301 verir. Canonical aynı current path'i gösterir.

Identity

URL identity editoryal slug değil kalıcı entity identifier'dır. API ve database ilişkileri aynı ID'yi kullanır. Multi-language URL'ler aynı identity'ye bağlanır. Product merge explicit migration gerektirir. Delete tombstone yaratabilir.

Product ID

Product ID slug değişse bile sabit kalır. Feed ve internal systems bunu kullanabilir. URL resolver input olarak ID alır. Primary veya public ID olabilir. URL içine yazılması zorunlu değildir.

Slug

Slug kullanıcı dostu public presentation değeridir. Normalization create sırasında uygulanır. Collision resolver unique hale getirir. Locale bazında farklı olabilir. History tutulur.

Persistent

Current slug database'de saklanır. Product title update tekrar generation yapmaz. Algorithm version change existing slug'ı etkilemez. Snapshot stability korunur. Manual change explicit action'dır.

Rename

Product display name değişebilir. URL identity aynı kalır. Search title ve heading update edilir. Slug yalnız kullanıcı isterse değişir. Analytics continuity korunur.

Otomatik slug değişmez

Rename event slug service'i çağırmaz. Import repeat URL yaratmaz. PIM title update güvenlidir. URL churn düşer. Unit test bu contract'ı doğrular.

Manual Slug Change

Yetkili kullanıcı new slug talep eder. Normalization ve collision check yapılır. Old current history'ye taşınır. Cache invalidate edilir. Sitemap update edilir.

301 oluşturur

Eski product path permanent redirect verir. Target doğrudan yeni current URL'dir. Chain flattening uygulanır. Internal links yeni URL'yi kullanır. Old path tombstone ownership korur.

Örnek Category URL Contract

Category URL contract parent policy'yi açıkça tanımlamalıdır. Flat veya recursive route seçimi migration davranışını değiştirir. Slug persistent tutulabilir. Move işlemi URL değiştiriyorsa redirect zorunlu olmalıdır. Child URL etkisi önceden hesaplanmalıdır.

Route

/kategori/{slug} flat yapı için kullanılabilir. Recursive route seçilirse parent segments eklenir. Locale route farklılaşabilir. Resolver current category ID üzerinden üretir. Sitemap aynı source'u kullanır.

Parent Policy

Parent category URL'nin parçası mı açıkça belirtilir. Flat model move etkisini azaltır. Recursive model hierarchy görünümünü artırır. Product URLs parent'tan bağımsız olabilir. Business taxonomy change frequency karar kriteridir.

Slug Policy

Category name create sırasında normalize edilir. Rename otomatik slug change yapmaz. Collision scope namespace'e göre belirlenir. Reserved word kontrol edilir. Locale-specific current records tutulabilir.

Move Policy

Flat route'ta parent move URL'yi değiştirmeyebilir. Recursive route'ta new path hesaplanır. Descendant impact raporu oluşturulur. Approval threshold belirlenebilir. Batch migration event üretir.

Redirect Policy

Old category paths new current path'e 301 verir. Descendant old paths flatten edilir. Redirect loops test edilir. Sitemap new URLs kullanır. Monitoring migration sonrası devam eder.

İlk 30 Günlük URL Mimari Projesi

Mevcut e-ticaret sitesinde URL mimarisini iyileştirmek aşamalı yapılmalıdır. İlk günlerde envanter çıkarılır. Sonraki aşamada slug standardı ve data model belirlenir. Implementation küçük subset üzerinde test edilir. Son hafta pilot, sitemap ve monitoring ile production davranışı doğrulanır.

Gün 1–5 — URL Envanteri

Current URL patterns toplanır. Product, category, brand ve filter adresleri ayrılır. Redirect ve canonical davranışı ölçülür. Search Console ve server log örnekleri incelenir. Duplicate ve churn başlangıç metriği oluşturulur.

Product

Tüm current product paths entity ID ile eşleştirilir. Duplicate ve redirects bulunur. Title-slug relationship incelenir. Variant URLs ayrıca işaretlenir. High traffic örnekler priority olur.

Category

Category depth ve parent coupling incelenir. Move history varsa URL etkisi ölçülür. Recursive paths listelenir. Facets base category'den ayrılır. Category canonical behavior kontrol edilir.

Brand

Brand namespace ve symbol handling değerlendirilir. Duplicate names bulunur. Brand landing indexability kontrol edilir. Locale behavior incelenir. Existing redirects kaydedilir.

Filter

Parameter combinations analiz edilir. Indexable facets belirlenir. Infinite patterns server logdan bulunur. Tracking parameters ayrılır. Canonical serialization farkları raporlanır.

Gün 6–10 — Slug Standardı

Normalization policy dokümante edilir. Unicode veya ASCII seçimi yapılır. Locale ve collision davranışı tanımlanır. Reserved words merkezi listeye alınır. Golden test set oluşturulur.

Unicode

NFC standardı belirlenir. Unicode vs ASCII policy seçilir. Existing URLs migration dışında korunabilir. Encoding behavior test edilir. Database collation gözden geçirilir.

locale

Türkçe lowercase rule belirlenir. Multi-language plugin interface tasarlanır. Locale input explicit olur. Region variants desteklenir. Tests environment independent çalışır.

collision

Deterministic disambiguator seçilir. Numeric suffix trade-off değerlendirilir. Database unique constraint planlanır. Bulk import test cases hazırlanır. Tombstone occupancy tanımlanır.

reserved words

System routes inventory çıkarılır. Registry source belirlenir. Admin ve API paths korunur. Locale reserved values eklenir. CI collision scanner hazırlanır.

Gün 11–15 — Data Model

URL registry ve slug history tabloları tasarlanır. Redirect ownership belirlenir. Entity ID bağlantıları kurulur. Index ve constraint planı hazırlanır. Migration script dry-run yapılır.

URL registry

Entity type, ID, locale ve current path saklanır. Unique index tanımlanır. Status enum belirlenir. Current lookup performansı test edilir. Existing URL import edilir.

slug history

Old slugs veya paths ayrı kayıt tutulur. Changed timestamp ve reason eklenir. Current relation korunur. Reuse engellenir. Audit query hazırlanır.

redirect

Source ve final target modeli seçilir. HTTP type belirlenir. Chain flattening yaklaşımı tasarlanır. Cycle validation eklenir. Tombstone behavior ayrılır.

Gün 16–20 — Implementation

Generator, resolver ve canonical service geliştirilir. Framework route integration yapılır. Import pipeline yeni service'i kullanır. Cache invalidation event eklenir. Feature flag pilot için hazırlanır.

generator

Pure normalizer uygulanır. Locale plugin bağlanır. Collision reservation repository eklenir. Reserved check çalışır. Unit ve property tests geçer.

resolver

Product ve category helpers geliştirilir. Entity ID current path'e çevrilir. Locale route uygulanır. Absolute URL config güvenli hale getirilir. API contract yayınlanır.

canonical

Request parameters normalize edilir. Temporary keys çıkarılır. HTML metadata central service kullanır. Sitemap aynı output'u tüketir. Hreflang locale mapping bağlanır.

Gün 21–25 — Testing

Unit, property ve regression testleri çalıştırılır. URL snapshot karşılaştırılır. Redirect crawler hazırlanır. Collision concurrency test edilir. SEO canonical mismatch taraması yapılır.

unit

Golden slug örnekleri doğrulanır. Reserved and empty input test edilir. Locale conversions kontrol edilir. Length truncation sınanır. Symbol mapping fixtures kullanılır.

property-based

Random Unicode data üretilir. Invariant'lar test edilir. Long input ve emoji fuzzing yapılır. Collision generator denenir. Crash oluşturan input regression fixture olur.

regression

Before ve after URL snapshot karşılaştırılır. Unexpected changes engellenir. Approved migration mapping doğrulanır. Canonical ve sitemap diff edilir. Internal links crawl edilir.

Gün 26–30 — Pilot ve Monitoring

Product subset üzerinde yeni sistem açılır. Sitemap ve resolver birlikte gözlemlenir. Search Console ve server log takibi başlar. Collision ve redirect metrics dashboard'a eklenir. Başarı sonrası kapsam kademeli artırılır.

product subset

Farklı category ve locale örnekleri seçilir. High traffic olmayan fakat temsil edici ürünler kullanılabilir. Create, rename ve manual slug change test edilir. Rollback denenir. Feedback kaydedilir.

sitemap

Pilot URLs current resolver'dan üretilir. Redirect sources dışarıda tutulur. HTTP status validator çalışır. Locale mapping doğrulanır. Cache refresh ölçülür.

Search Console

Indexing ve canonical signals takip edilir. Duplicate reports baseline ile karşılaştırılır. Old URLs redirect behavior izlenir. Unexpected crawl patterns araştırılır. URL inspection örnekleri alınır.

URL ve Slug Maturity Model

URL sistemleri basit title-to-slug yaklaşımından merkezi governance modeline kadar farklı olgunluk seviyelerine sahip olabilir. Amaç her projeyi en üst seviyeye zorlamak değildir. Katalog büyüklüğü, değişim sıklığı ve SEO önemi ihtiyaç seviyesini belirler. Olgunluk modeli teknik borcu görünür hale getirir. Ekip bir sonraki gelişim adımını daha net planlayabilir.

Seviye 1 — Başlığı Doğrudan URL Yapmak

Slug runtime title'dan hesaplanır. History ve collision policy sınırlıdır. Küçük prototip için çalışabilir. Rename URL change üretir. Büyük katalogda hızla sorun çıkarır.

Seviye 2 — Basic Slug Normalization

Lowercase, transliteration ve tire normalization vardır. URL daha okunabilir hale gelir. Collision basit suffix ile çözülür. History hâlâ zayıf olabilir. Locale testleri eklenmeye başlanır.

Seviye 3 — Collision ve Redirect Yönetimi

Database uniqueness uygulanır. Slug history tutulur. Manual change 301 üretir. Tombstone policy bulunabilir. URL churn kontrol altına girer.

Seviye 4 — Merkezi URL Registry

Product, category ve brand ownership merkezi hale gelir. Canonical ve resolver tek source kullanır. Multi-language mapping desteklenir. Sitemap registry'den üretilir. URL auditing kolaylaşır.

Seviye 5 — Automated SEO Testing

URL snapshot ve diff CI'da çalışır. Canonical mismatch release öncesi yakalanır. Redirect loops test edilir. Sitemap ve internal link validator bulunur. URL quality dashboard aktif hale gelir.

Seviye 6 — Global URL Governance

Multi-region ve locale policy merkezi yönetilir. Product manager, SEO ve developer ortak contract kullanır. Migration impact otomatik hesaplanır. URL churn SLO izlenir. Feed, sitemap, app ve web aynı registry modelini paylaşır.

En Sık Yapılan Slug Algoritması Hataları

Slug sistemlerinde görülen hataların önemli bölümü başlangıçta küçük kolaylıklar uğruna yaşam döngüsünün göz ardı edilmesinden kaynaklanır. Product name'i identity sanmak bunun başında gelir. Database constraint olmadan collision kontrolü concurrency altında kırılır. Slug history tutulmadığında migration sonrası 404 sayısı artar. Canonical ve sitemap'in ayrı kod kullanması da tutarsız sinyaller üretir.

Product Name'i Kalıcı ID Sanmak

Product name değişebilir. Localization farklı title üretir. Aynı isimli iki ürün olabilir. Bu nedenle primary identity olamaz. Stable entity ID kullanılmalıdır.

Her İsim Değişikliğinde URL'yi Değiştirmek

Merchandising edit URL migration'a dönüşür. Redirect table hızla büyür. Backlinks sürekli hop alır. Analytics continuity bozulur. Slug immutability daha sağlıklıdır.

Slug Collision'ı Yalnız Uygulama Kodunda Kontrol Etmek

SELECT before INSERT race condition'a açıktır. Parallel worker aynı slug'ı seçebilir. Database unique constraint gerekir. Conflict retry tasarlanmalıdır. Application pre-check yalnız UX için kullanılmalıdır.

Race Condition'ı Görmezden Gelmek

Küçük trafikte hata görünmeyebilir. Bulk import altında duplicate oluşur. Database exception beklenmeyen 500'e dönüşebilir. Concurrency integration test yazılmalıdır. Reservation atomic olmalıdır.

Silinen Slug'ı Hemen Yeniden Kullanmak

Eski backlinks yeni ürüne gider. Bookmark kullanıcıyı yanlış içeriğe taşır. Search index identity karışır. Tombstone reuse'i engeller. Replacement varsa explicit redirect yapılır.

Eski Slug History Tutmamak

Manual change sonrası old URL 404 olur. Redirect map üretilemez. Analytics migration izi kaybolur. Audit yoktur. History table düşük maliyetle bu problemi çözer.

Redirect Chain Oluşturmak

Her change previous target'a bağlanırsa A-B-C zinciri oluşur. Resolver final current path'i hedeflemelidir. Graph flattening uygulanır. Maximum hop test edilir. Internal links current URL kullanır.

Türkçe Locale Kurallarını Görmezden Gelmek

I ve İ dönüşümü yanlış olabilir. Environment'lar farklı slug üretir. Unicode normalization eksik kalır. Collision veya 404 oluşabilir. Türkçe locale plugin ve tests şarttır.

Bütün Dinamik URL'leri Kötü Kabul Etmek

Dinamik route modern e-ticaretin doğal parçasıdır. Sorun dynamic olması değil uncontrolled duplication'dır. Parameter policy ve canonical doğru olmalıdır. Clean-looking URL bile duplicate üretebilir. SEO değerlendirmesi davranış üzerinden yapılmalıdır.

Query Parameter Sırasını Kontrol Etmemek

Aynı filter state birden fazla URL üretir. Canonical inconsistent olur. Internal links farklı serialization kullanabilir. Deterministic parameter order gerekir. Multi-value order da normalize edilmelidir.

Canonical ve Sitemap'i Farklı Kodla Üretmek

İki code path zamanla farklılaşır. Biri old slug kullanabilir. Locale prefix unutulabilir. Search signal çelişir. Central URL resolver kullanılmalıdır.

Başarılı Bir Slug Engine'in 12 Temel İlkesi

Başarılı slug engine yalnız temiz text üretmez. Entity identity, determinism, locale, collision ve URL history birlikte düşünülür. Database constraint concurrency güvenliği sağlar. Canonical, sitemap ve internal links aynı resolver'a bağlanır. URL churn düzenli ölçülerek sistem davranışı production'da izlenir.

1. Slug Entity ID Değildir

Slug değişebilir ve lokalize olabilir. Entity ID kalıcıdır. Routing slug'dan ID'ye çözüm yapar. History aynı ID'ye bağlanır. Bu ayrım sistemin temelidir.

2. Algoritma Deterministik Olmalıdır

Aynı input aynı base slug'ı üretmelidir. Randomness kullanılmamalıdır. Environment locale sonucu değiştirmemelidir. Collision suffix stabil olmalıdır. Test edilebilirlik böyle sağlanır.

3. Unicode Politikası Açık Olmalıdır

ASCII veya Unicode seçimi dokümante edilmelidir. NFC normalization uygulanmalıdır. Locale-specific case davranışı bilinmelidir. Existing URLs policy change ile otomatik rewrite edilmemelidir. Golden tests standardı korur.

4. Collision Stratejisi Tanımlı Olmalıdır

Numeric suffix veya stable public ID policy seçilmelidir. Database uniqueness zorunludur. Race condition düşünülmelidir. Retry behavior açık olmalıdır. Tombstone occupancy hesaba katılmalıdır.

5. Slug Varsayılan Olarak Stabil Kalmalıdır

Product rename automatic change yapmamalıdır. Category move etkisi route policy'ye göre sınırlanmalıdır. Manual update explicit action olmalıdır. URL churn düşük tutulur. Analytics continuity korunur.

6. Eski Slug'lar Kaydedilmelidir

History redirect için gereklidir. Old path reuse edilmemelidir. Audit ve migration analysis sağlar. Multiple previous values tutulabilir. Final current target her zaman bulunmalıdır.

7. Değişiklikler 301 Üretmelidir

Aynı entity'nin kalıcı URL değişimi 301 ile yönetilir. Old URL 404 bırakılmaz. Target current path olmalıdır. Chain önlenmelidir. Sitemap new URL'yi kullanır.

8. Reserved Path'ler Korunmalıdır

System routes public entity slug olamaz. Registry merkezi tutulur. New route deployment conflict taraması yapar. Alternate slug üretilir. Router shadowing önlenir.

9. Database Unique Constraint Kullanılmalıdır

Application check yeterli değildir. Unique index concurrent writes altında authoritative olur. Locale ve namespace scope doğru seçilmelidir. Retry expected conflict'i yönetir. Constraint migration test edilir.

10. Canonical, Sitemap ve İç Linkler Aynı Resolver'ı Kullanmalıdır

Tek URL source consistency sağlar. Manual string concatenation engellenir. Locale current slug ortak kaynaktan gelir. Feed de aynı resolver'ı kullanabilir. Canonical mismatch azalır.

11. URL Algoritması Otomatik Test Edilmelidir

Unit ve golden tests minimum gereksinimdir. Property-based Unicode edge case bulur. Regression URL snapshot deploy öncesi çalışır. HTTP crawler canonical ve redirect test eder. Breaking change görünür hale gelir.

12. URL Churn Düzenli Ölçülmelidir

Weekly slug change metric tutulur. Expected migration ayrı işaretlenir. Rename-driven churn bug olarak görülür. Category move impact ölçülür. Dashboard product ve SEO ekiplerine görünür olur.

Sonuç — Slug Generator'dan URL Yaşam Döngüsü Sistemine

E-Ticaret Siteleri İçin Dinamik URL ve Slug Üretim Algoritmaları yalnız ürün adını küçük harfe çevirip boşlukları tireye dönüştüren bir fonksiyon olarak tasarlanmamalıdır. Sağlam sistem; entity kimliği, locale, Unicode, collision, concurrency, history, redirect, canonical ve sitemap davranışlarını tek URL sözleşmesinde toplar. Özellikle büyük kataloglarda URL'nin yıllarca stabil kalması, yeni slug üretmekten daha değerlidir. E-ticaret dinamik URL slug ve teknik SEO optimizasyon hizmeti planlanırken uygulama kodu ile SEO gereksinimlerinin aynı veri modeline bağlanması gerekir. E-ticaret URL yapısı ve teknik SEO danışmanlığı yakınımda şeklinde çözüm arıyorsanız Diyarbakır Yazılım Topluluğu çalışmalarını https://www.diyarbakiryazilim.com.tr/about adresinden inceleyebilirsiniz.

Amaç Yalnız Temiz URL Üretmek Değildir

Temiz slug başlangıç noktasıdır. Asıl amaç URL ownership ve lifecycle yönetimidir. Redirect ve history olmadan slug system eksik kalır. Canonical ve sitemap aynı state'i kullanmalıdır. Production observability davranışı sürekli doğrulamalıdır.

URL'nin Yıllarca Stabil Kalması Sağlanmalıdır

Stability search ve kullanıcı açısından değerlidir. Product rename URL change olmamalıdır. Migration yalnız gerçek ihtiyaçla yapılmalıdır. Backlinks korunur. URL churn ölçülür.

Entity Kimliği ile Slug Ayrılmalıdır

ID kalıcıdır. Slug presentation değeridir. Locale slug'ları aynı entity'yi paylaşabilir. History ve redirect kolaylaşır. Integration sistemleri daha güvenilir hale gelir.

Collision ve Concurrency Algoritmanın Parçası Olmalıdır

Unique constraint son güvenceyi sağlar. Deterministic disambiguator tercih edilir. Parallel create test edilmelidir. Retry kontrollü yapılır. Collision metrics production'da izlenir.

Ürün, Kategori ve Varyantlar İçin Ayrı URL Politikaları Tanımlanmalıdır

Product URL stabil olabilir. Category taxonomy lifecycle farklıdır. Variant state her zaman indexable değildir. Facet engine slug engine'den ayrılır. Her entity type için contract yazılmalıdır.

Canonical, Redirect, Sitemap ve İç Linkler Aynı URL Modelini Kullanmalıdır

Central resolver tek current path üretir. Historical paths yalnız redirect service'te kullanılır. Sitemap yalnız indexable current URLs yayınlar. Internal links redirect üzerinden gitmez. Bu yaklaşım teknik SEO sinyallerini tutarlı hale getirir.

Sıkça Sorulan Sorular

URL slug nedir?

URL slug, bir web adresinin içerik veya entity'yi açıklayan okunabilir bölümüdür. Product veya category adından üretilebilir. Slug kalıcı teknik ID olmak zorunda değildir. Locale bazında değişebilir. Sağlam sistem current ve historical slug bilgilerini ayrı yönetir.

E-ticaret sitesinde slug nasıl oluşturulur?

Input Unicode normalization'dan geçirilir. Locale-aware lowercase uygulanır. Semboller ve separator'lar normalize edilir. Reserved ve collision kontrolü yapılır. Final slug database unique constraint ile güvenli biçimde saklanır.

Dinamik URL nedir?

Dinamik URL backend veya application state üzerinden çözümlenen adrestir. Query parameter veya path parameter içerebilir. Dinamik olması SEO sorunu değildir. Asıl risk duplicate ve sonsuz URL üretimidir. Canonical ve parameter policy bunu yönetir.

Dinamik URL'ler SEO için kötü müdür?

Hayır. Search engine dinamik URL'leri tarayabilir. Sorun aynı içeriğin çok fazla farklı URL ile sunulmasıdır. Geçici parameter ve kontrolsüz facets risklidir. Stabil canonical ve internal links kullanıldığında dinamik yapı güvenli olabilir.

SEO uyumlu ürün URL'si nasıl olmalıdır?

Açıklayıcı ve kullanıcı tarafından okunabilir olmalıdır. Mümkün olduğunca stabil kalmalıdır. Tek canonical identity üretmelidir. Gereksiz parameter içermemelidir. Product title değişikliklerine otomatik bağlı olmaması güçlü avantaj sağlar.

Türkçe karakterler URL'de kullanılabilir mi?

Evet, Unicode URL teknik olarak kullanılabilir. ASCII transliteration da mümkündür. Önemli olan tek policy seçip tutarlı kalmaktır. Unicode normalization uygulanmalıdır. Existing URLs yalnız karakter görünümü nedeniyle toplu değiştirilmemelidir.

Türkçe karakterleri slug'dan kaldırmak zorunlu mudur?

Hayır. Ş, ğ, ç, ö, ü ve ı karakterleri kullanılabilir. ASCII tercih edilirse transliteration yapılabilir. Search açısından asıl önemli konu stabil ve tutarlı URL'dir. Migration riski policy seçiminden daha önemli olabilir.

Slug oluşturma algoritması nasıl çalışır?

Input normalize edilir. Locale ve case dönüşümü uygulanır. Symbol ve separator temizlenir. Length ve reserved check yapılır. Collision resolver unique final slug üretir.

Aynı isimli iki ürün için slug nasıl oluşturulur?

İlk olarak marka veya model gibi anlamlı ayrım kullanılabilir. Gerekirse kısa public ID eklenebilir. Deterministic suffix tercih edilir. Numeric -2 yöntemi küçük sistemlerde kullanılabilir. Database uniqueness her durumda zorunludur.

Slug benzersizliği nasıl sağlanır?

Application availability check yapabilir. Ancak database unique constraint nihai kontrol olmalıdır. Transaction içinde reservation yapılır. Conflict durumunda alternate deterministic slug üretilir. Parallel create test edilmelidir.

Slug ile ürün ID'si arasındaki fark nedir?

Product ID kalıcı teknik kimliktir. Slug kullanıcı dostu URL parçasıdır. Slug değişebilir veya lokalize olabilir. ID değişmemelidir. Resolver slug'ı entity ID ile ilişkilendirir.

Ürün adı değiştiğinde URL değişmeli mi?

Genellikle otomatik değişmemelidir. Product title editoryal alan olarak değişebilir. Slug persistent tutulur. Manual slug change gerektiğinde explicit action yapılır. Eski URL 301 ile korunur.

Slug değiştiğinde 301 redirect gerekli midir?

Aynı entity'nin kalıcı URL değişikliğinde 301 güçlü varsayımdır. Eski backlink ve bookmark yeni adrese ulaşır. Redirect doğrudan current target'a gitmelidir. Sitemap old URL'yi kaldırmalıdır. Internal links yeni URL'yi kullanmalıdır.

Silinen bir ürünün slug'ı başka üründe kullanılabilir mi?

Teknik olarak mümkün olsa da çoğu durumda önerilmez. Eski backlinks yeni ve ilgisiz ürüne gidebilir. Search index identity karışabilir. Tombstone slug'ı rezerve tutabilir. Replacement varsa explicit redirect kullanılabilir.

Ürün URL'sinde kategori bulunmalı mı?

Zorunlu değildir. Kategorili URL bağlam sağlar fakat category move product URL'yi değiştirebilir. /urun/{slug} gibi flat product route daha stabil olabilir. Breadcrumb taxonomy bilgisini yine gösterebilir. Katalog değişim sıklığı karar üzerinde önemlidir.

Aynı ürün birden fazla kategorideyse URL nasıl olmalıdır?

Tek canonical product URL tercih edilmelidir. Farklı category listing'leri aynı current adresi linkler. Breadcrumb navigation context gösterebilir. Birden fazla indexable product path duplicate riskini artırır. Sitemap yalnız canonical adresi yayınlar.

Ürün varyantları için ayrı URL oluşturulmalı mı?

Her varyant için ayrı indexable URL gerekli değildir. Search intent ve paylaşılabilir state değerlendirilmelidir. Query parameter selected variant'ı taşıyabilir. Canonical ana product URL olabilir. Yalnız değerli varyant landing'leri indexlenebilir.

Renk ve beden query parameter olarak kullanılabilir mi?

Evet. color ve size gibi parameter'lar UI state'i taşıyabilir. Parameter ordering normalize edilmelidir. Canonical çoğu durumda ana product URL olabilir. Search demand varsa belirli variant URL'leri ayrı değerlendirilebilir. Tracking keys ile karıştırılmamalıdır.

Query parameter sırası SEO için nasıl yönetilmelidir?

Tek deterministic serialization kullanılmalıdır. Allowed keys belirlenir. Key order alfabetik veya tanımlı sıra olabilir. Multi-value listeler de normalize edilir. Aynı state farklı URL üretmemelidir.

Canonical URL slug sistemine nasıl bağlanmalıdır?

Canonical generator entity ID üzerinden current slug'ı bulmalıdır. Incoming old URL'ye güvenmemelidir. Locale ve route template uygulanır. Tracking parameter temizlenir. Absolute current URL üretilir.

Sitemap URL'leri nasıl oluşturulmalıdır?

URL registry'deki current ve indexable entities kullanılmalıdır. Slug raw title'dan yeniden hesaplanmamalıdır. Redirect ve tombstone paths dışarıda bırakılır. Locale mapping aynı source'tan gelir. HTTP validator sitemap'i düzenli test eder.

Çok dilli sitelerde slug nasıl çevrilmelidir?

Her locale için ayrı current slug tutulabilir. Aynı product ID korunur. Localized route template uygulanabilir. Translation change slug'ı otomatik değiştirmek zorunda değildir. Hreflang registry üzerinden oluşturulmalıdır.

E-ticaret URL'lerinde UUID kullanılmalı mı?

UUID kalıcı identity için güçlü seçenektir. URL içinde görünmesi zorunlu değildir. Collision suffix için kısa encoded parçası kullanılabilir. Okunabilirlik ile determinism dengelenmelidir. Internal ID'den ayrı public UUID tercih edilebilir.

SKU slug'a eklenmeli mi?

SKU stabil ve anlamlıysa collision çözümünde kullanılabilir. Her URL'ye zorunlu eklenmesi gerekmez. SKU lifecycle önceden incelenmelidir. Değişebilen SKU URL churn yaratabilir. Public ID daha stabil fallback olabilir.

Slug collision nasıl çözülür?

Base slug registry'de kontrol edilir. Boşsa atomic reserve edilir. Doluysa deterministic disambiguator eklenir. Database unique constraint final doğrulamayı yapar. Parallel conflict retry edilir.

Slug generator hangi programlama diliyle yazılmalıdır?

Tek doğru dil yoktur. TypeScript, PHP, Python, Java ve C# kullanılabilir. Önemli olan Unicode ve locale davranışının doğru olmasıdır. Database constraints ve testing daha kritik unsurlardır. Mevcut teknoloji yığınıyla uyum tercih edilmelidir.

URL algoritmaları nasıl test edilir?

Unit ve golden testler temel örnekleri doğrular. Property-based testing Unicode edge case'leri bulur. URL snapshot regression beklenmeyen change'i gösterir. HTTP crawler canonical ve redirect kontrol eder. Concurrency test collision güvenliğini doğrular.

URL migration sırasında sıralama kaybı nasıl azaltılır?

Old-to-new mapping eksiksiz hazırlanmalıdır. 301 redirect doğrudan current target'a gitmelidir. Sitemap ve internal links aynı anda güncellenmelidir. Migration kademeli yapılabilir. Search Console ve server log monitoring devam etmelidir.

Open source slug generator geliştirilebilir mi?

Evet. Core normalizer, locale plugins ve collision resolver interface ayrılabilir. Golden ve property test suite eklenebilir. Framework adapter'ları community tarafından geliştirilebilir. Türkçe locale desteği güçlü proje konusu olabilir. Documentation ve backward compatibility önemlidir.

Yazılımcılar teknik SEO için URL mimarisini neden öğrenmelidir?

URL mimarisi routing ve database kararlarının doğrudan search görünürlüğüne etkisini gösterir. Redirect ve canonical temel web davranışlarıdır. Unicode ve concurrency production güvenilirliği gerektirir. Sitemap ve internal link consistency uygulama tasarımına bağlıdır. Teknik SEO böylece yalnız içerik değil sistem mühendisliği konusu haline gelir.

E-Ticaret Dinamik URL ve Slug Yönetimi Hakkında Ek Sorular

E-ticaret sitelerinde dinamik URL ve SEO uyumlu slug üretim algoritmaları nasıl oluşturulur?

E-ticaret sitelerinde SEO uyumlu dinamik URL ve slug nasıl oluşturulur sorusunun cevabı, title metnini dönüştürmekten daha geniştir. Önce Unicode ve locale normalizasyonu yapılmalı, ardından sembol ve separator politikası uygulanmalıdır. Collision database unique constraint ve deterministic resolver ile çözülmelidir. Slug entity ID'den ayrılmalı ve current değer persistent tutulmalıdır. E-Ticaret Siteleri İçin Dinamik URL ve Slug Üretim Algoritmaları ancak redirect, canonical ve URL history ile birlikte tasarlandığında production seviyesinde güvenilir hale gelir.

Ürün ve kategori slug’larında anahtar kelime, ürün adı ve kategori bilgileri nasıl kullanılmalıdır?

Ürün ve kategori sayfaları için otomatik slug üretme algoritması öncelikle gerçek entity adını korumalıdır. Anahtar kelime eklemek amacıyla gereksiz tekrar üretmek yerine kullanıcıya anlamlı ve kısa adres sağlamak daha sağlıklıdır. Product URL category-independent ise taxonomy değişikliklerinden etkilenmez. Kategori slug'ı ise category name üzerinden persistent olarak oluşturulabilir. Editoryal başlık değişikliklerinin URL'yi otomatik değiştirmemesi uzun vadeli stabilite sağlar.

Dinamik URL’lerde Türkçe karakterler, özel karakterler, boşluklar ve yinelenen slug’lar nasıl yönetilmelidir?

Türkçe karakterlerde Unicode veya ASCII transliteration politikası seçilebilir. Locale-aware lowercase özellikle I ve İ karakterleri için uygulanmalıdır. Özel semboller anlam taşıyorsa semantic mapping kullanılmalı, whitespace ve birden fazla tire normalize edilmelidir. Duplicate base slug bulunduğunda stabil public ID veya başka deterministic disambiguator eklenebilir. Database unique constraint race condition altında benzersizliği garanti etmelidir.

Ürün adı veya kategorisi değiştiğinde eski slug için 301 yönlendirme ve canonical URL yönetimi nasıl yapılmalıdır?

Product rename varsayılan olarak current slug'ı değiştirmemelidir. Explicit slug değişikliği yapıldığında eski path history'ye alınmalı ve yeni current path'e 301 ile yönlendirilmelidir. Redirect chain oluşmaması için bütün geçmiş path'ler final current URL'ye gitmelidir. Canonical, sitemap ve internal links yalnız yeni current URL'yi kullanmalıdır. Dinamik URL değişikliklerinde canonical 301 yönlendirme ve duplicate content yönetimi merkezi URL resolver üzerinden yürütüldüğünde tutarsızlık riski ciddi biçimde azalır.

E-ticaret siteleri için dinamik URL ve slug optimizasyonu konusunda yakınımda teknik SEO danışmanlığı nerede bulabilirim?

E-ticaret URL yapısı ve teknik SEO danışmanlığı yakınımda şeklinde araştırma yaparken yalnız slug formatına değil URL registry, redirect history, canonical, sitemap, çoklu dil ve regression testing konularına birlikte yaklaşan hizmetleri değerlendirmek faydalıdır. E-ticaret dinamik URL slug ve teknik SEO optimizasyon hizmeti mevcut URL envanteri ve server log analiziyle başlamalıdır. Diyarbakır Yazılım Topluluğu’nun proje çalışmalarını https://www.diyarbakiryazilim.com.tr/projects adresinden inceleyebilirsiniz. Topluluk ve çalışma yaklaşımı hakkında https://www.diyarbakiryazilim.com.tr/about adresinde ek bilgi bulunmaktadır. URL mimarisi üzerine teknik çalışma planlamak için https://www.diyarbakiryazilim.com.tr adresi üzerinden Diyarbakır Yazılım Topluluğu ile iletişime geçebilirsiniz.

İçerik, yüklediğiniz brief’teki hedef anahtar kelime, başlık yapısı, uzun kuyruklu sorgular, bağlantılar ve SSS gereksinimleri temel alınarak hazırlanmıştır.