Dinamik E-Ticaret Mimarisinde Hata Sayfası (404) Stratejileri

Bir e-ticaret sitesinde 404 sayfasına düşen ziyaretçi her zaman kaybedilmiş ziyaretçi değildir. Çoğu zaman kullanıcı birkaç saniye önce belirli bir ürünü arıyor, eski bir kampanya bağlantısına tıklıyor veya satın almaya yakın bir noktada ilerliyordur. Bu yüzden Dinamik E-Ticaret Mimarisinde Hata Sayfası (404) Stratejileri yalnızca hata mesajının tasarımını değil, HTTP durum kodlarını, ürün yaşam döngüsünü, yönlendirmeleri, site içi aramayı, öneri sistemlerini ve ölçüm altyapısını birlikte ele almalıdır. On yılı aşkın teknik SEO ve web mimarisi deneyiminde gördüğüm en yaygın sorun, ekiplerin 404'ü yalnızca geliştiricilerin çözmesi gereken teknik bir hata olarak değerlendirmesidir. Oysa doğru kurgu, organik trafik kaybını azaltabilir, kullanıcının satın alma niyetini koruyabilir ve silinen URL'lerin oluşturduğu teknik borcu kontrol altında tutabilir.

Bu rehberde dinamik e-ticaret sitelerinde 404 sayfası nasıl optimize edilir, e-ticaret sitelerinde silinen ürün sayfaları 404 mü 301 mi olmalı ve e-ticaret 404 hataları SEO ve organik trafiği nasıl etkiler gibi pratik soruları sistem tasarımı açısından ele alacağız. Dinamik URL yapısında 404 soft 404 ve yönlendirme stratejileri için tek bir kural olmadığını, kararın ürünün yaşam döngüsüne ve URL'nin gerçek karşılığına bağlı olduğunu göreceğiz. Ayrıca e-ticaret sitesi teknik SEO ve 404 hata optimizasyonu hizmeti arayan ekiplerin hangi teknik ölçütleri değerlendirmesi gerektiğini açıklayacağız. E-ticaret teknik SEO ve 404 optimizasyonu uzmanı yakınımda gibi yerel niyetli aramalarda dahi önemli olan yalnızca danışmanın konumu değil, HTTP, indeksleme, katalog yönetimi, veri takibi ve kullanıcı davranışını birlikte okuyabilmesidir. Amacımız 404 sayfasını bir çıkmaz olmaktan çıkarıp ölçülebilir bir kurtarma noktası hâline getirmektir.

E-Ticarette 404 Hatası Nedir?

404, istenen URL için sunucunun geçerli bir kaynak bulamadığını bildiren HTTP durum kodudur. Basit bir kurumsal sitede bu durum nadiren ortaya çıkabilir, ancak binlerce ürünün, kategorinin, varyantın ve kampanyanın bulunduğu e-ticaret sistemlerinde çok daha sık görülür. Buradaki kritik ayrım, kaynağın gerçekten bulunamamasıyla kullanıcı arayüzünün yalnızca “ürün bulunamadı” mesajı göstermesi arasındadır. Tarayıcıda görünen içerik ile sunucunun döndürdüğü HTTP yanıtı aynı şeyi söylemelidir. Aksi durumda arama motorları ve izleme sistemleri gerçek durumu yanlış yorumlayabilir.

HTTP 404 Not Found Ne Anlama Gelir?

HTTP 404 Not Found, sunucunun istenen kaynağı o URL üzerinde bulamadığını ifade eder. Bu kod, sayfanın daha önce var olup olmadığı konusunda tek başına bilgi vermez. Örneğin kullanıcı hiç oluşturulmamış bir ürün URL'sini yazdığında da 404 alabilir, geçen ay kaldırılmış bir ürüne ulaştığında da aynı kod dönebilir. Arama motorları için önemli olan, URL'nin geçerli içerik sunmadığının açık biçimde belirtilmesidir. Kullanıcı açısından ise 404 yanıtına rağmen sayfanın yönlendirici ve kullanışlı olması gerekir.

404 Bir Sunucu Arızası mıdır?

404 çoğu durumda sunucu arızası değildir. Sunucu isteği almış, işlemiş ve istenen kaynağı bulamadığını doğru şekilde bildirmiştir. Sunucu arızaları daha çok 500 serisi HTTP durum kodlarıyla ilişkilidir. Bu ayrım operasyon ekipleri açısından önemlidir çünkü her 404 için sistem alarmı üretmek gereksiz gürültü oluşturabilir. Buna karşılık normal seviyenin çok üzerinde gerçekleşen ani 404 artışı bir dağıtım, katalog senkronizasyonu veya yönlendirme problemi gösterebilir.

E-Ticaret Sitelerinde 404 Neden Daha Sık Görülür?

E-ticaret sitelerindeki URL sayısı sürekli değişir ve bunun doğal sonucu olarak bulunamayan kaynakların sayısı da artar. Ürünler satıştan kalkar, kampanyalar sona erer, kategori yapıları değişir ve kullanıcıların daha önce paylaştığı bağlantılar yaşamaya devam eder. Dış siteler yıllar önceki ürünlere bağlantı vermeye devam edebilir. Arama motorları eski URL'leri tekrar tarayabilir. Bu yüzden 404 yönetimi tek seferlik bir temizlik işi değil, katalog yaşam döngüsünün parçası olmalıdır.

Sürekli Değişen Ürün Kataloğu

Katalog büyüdükçe URL envanteri de büyür. Her yeni ürün yeni bir taranabilir adres oluşturabilir. Ürün güncellemeleri sırasında slug, kategori yolu veya varyant yapısı değişirse eski adresler sahipsiz kalabilir. Bu nedenle ürün kayıtlarıyla URL geçmişinin birlikte saklanması yararlıdır. Katalog değişikliklerinin SEO durumuna etkisi ürün yönetim sürecinin doğal parçası olmalıdır.

Silinen Ürünler

Bir ürünün veri tabanından silinmesi URL'nin nasıl davranması gerektiği sorusunu kendiliğinden çözmez. Ürün başka bir modelle değiştirilmiş olabilir. Sayfa değerli backlinklere sahip olabilir. Aynı ürün farklı bir URL'de yaşamaya devam ediyor olabilir. Bu nedenle silme işlemi öncesinde URL için 200, 301, 404 veya 410 kararının ayrıca verilmesi gerekir.

Kaldırılan Kategoriler

Kategori taksonomileri zaman içinde birleşebilir veya ayrılabilir. Eski kategori yeni bir kategoriyle bire bir eşleşiyorsa 301 mantıklı olabilir. Benzer fakat farklı bir kategoriye kör yönlendirme yapılması kullanıcı niyetini bozabilir. Hiç karşılığı bulunmayan kategori 404 veya bazı politikalarda 410 dönebilir. Karar, eski URL'nin anlamı ve yeni hedefin gerçekten aynı ihtiyacı karşılayıp karşılamadığı üzerinden verilmelidir.

Kampanya URL'leri

Kampanya sayfalarının ömrü çoğu ürün sayfasından daha kısadır. Sezonluk bir kampanya gelecek yıl tekrar kullanılacaksa URL'yi korumak avantaj sağlayabilir. Tamamen sona ermiş ve eşdeğeri olmayan bir kampanyada 404 veya 410 düşünülebilir. Yeni kampanya eski kampanyanın gerçek devamıysa 301 kullanılabilir. Her kampanya URL'sini ana sayfaya göndermek ise genellikle kullanıcı beklentisini karşılamaz.

Yanlış Yazılmış URL'ler

Kullanıcılar ürün adreslerini manuel yazarken hata yapabilir. Harf eksikliği, yanlış SKU veya eski slug gibi durumlar gerçek 404 üretebilir. Sistem yüksek güvenle doğru sayfayı bulabiliyorsa kullanıcıya öneri sunabilir. Otomatik yönlendirme ise yalnızca eşleşme gerçekten güçlü olduğunda kullanılmalıdır. Belirsiz durumda arama ve kategori seçenekleri daha güvenli bir kurtarma yöntemidir.

Eski Backlink'ler

Dış sitelerdeki eski bağlantılar yıllarca trafik göndermeye devam edebilir. Böyle URL'lerin hepsini 404 bırakmak değerli referral ve organik sinyallerin kaybolmasına yol açabilir. Bununla birlikte yalnızca backlink bulunduğu için ilgisiz bir sayfaya 301 yapılması doğru değildir. Önce eski içeriğin yeni sistemde gerçek karşılığı aranmalıdır. Karşılık varsa doğrudan ve mümkünse tek adımlı yönlendirme oluşturulmalıdır.

Dinamik E-Ticaret Mimarisinde 404 Neden Sıradan Bir Hata Sayfası Değildir?

Dinamik E-Ticaret Mimarisinde Hata Sayfası (404) Stratejileri kullanıcı niyetini merkezde tutmalıdır. Bir ziyaretçi eski bir ürün URL'sine ulaştığında genellikle bir ürün ailesine, markaya veya kategoriye dair belirgin bir beklenti taşır. Bu bağlamı tamamen yok sayan standart hata sayfası, kullanıcının yaptığı işi yeniden başlatmasına neden olur. Dinamik sistemlerde URL'nin kendisi bile eski SKU, ürün adı veya kategori hakkında değerli işaretler barındırabilir. Dolayısıyla 404 katmanı yalnızca “bulamadım” cevabı vermek yerine güvenli biçimde “ne aradığını tahmin edebiliyorum ve buradan devam edebilirsin” diyebilmelidir.

Kullanıcının Satın Alma Niyeti Hâlâ Vardır

404 sayfasına ulaşmak satın alma isteğinin sona erdiği anlamına gelmez. Ziyaretçi reklamdan, organik aramadan, favorilerinden veya daha önce paylaşılan bir bağlantıdan gelmiş olabilir. Kullanıcıya arama kutusu, benzer ürünler ve uygun kategori seçenekleri sunmak niyetin devam etmesini kolaylaştırır. Buradaki hedef kullanıcıyı mümkün olduğunca hızlı biçimde geçerli bir ticari sayfaya taşımaktır. Bu geçişin ölçülmesi, 404 stratejisinin gerçek değerini ortaya çıkarır.

Kaybolan URL Ürün Bağlamı Taşıyabilir

Eski bir URL çoğu zaman anlamsız bir metin değildir. Slug içinde ürün adı, model numarası, kategori veya marka bilgisi bulunabilir. Redirect registry, ürün arşivi veya eski SKU sözlüğüyle birleştirildiğinde bu veri güçlü bir kurtarma sinyali oluşturur. Sistem bu sinyalleri kullanarak doğrudan halefi ya da benzer seçenekleri belirleyebilir. Ancak tahmin düşük güven seviyesindeyse otomatik yönlendirme yerine kullanıcıya seçenek sunmak daha doğrudur.

404 Trafiğinin Ticari Değeri

Tüm 404 oturumları aynı değerde değildir. Rastgele bot taramasıyla eski bir ürün backlinkinden gelen gerçek ziyaretçi aynı öncelikte değerlendirilmemelidir. Trafik, geçmiş satış, backlink, arama gösterimi ve kullanıcı davranışı bir araya getirilerek ticari önem hesaplanabilir. Özellikle yüksek trafik alan eski ürün URL'leri hızlı aksiyon gerektirir. Böylece teknik ekip yüz binlerce 404 arasından gerçekten değer taşıyanları önce çözebilir.

Hata Sayfasını Recovery Surface Olarak Görmek

404 sayfasını yalnızca hata mesajı olarak değil, kurtarma yüzeyi olarak tasarlamak bakış açısını değiştirir. Sayfa kullanıcının hedefini yeniden keşfetmesine yardımcı olur. Arama, kategori, doğrudan halef ürün ve popüler ürün gibi seçenekler belirli bir sıra içinde sunulur. Bu seçeneklere yapılan tıklamalar analytics olayları olarak izlenir. Böylece tasarımın ne kadar işe yaradığı varsayımla değil veriyle ölçülebilir.

Teknik Hata ile Ticari Fırsatı Aynı Anda Yönetmek

Doğru bir 404 sayfası iki farklı ihtiyacı aynı anda karşılar. Arama motorlarına ve istemcilere gerçek HTTP 404 yanıtını verir. Kullanıcıya ise yararlı bir arayüz gösterir. Bu iki davranış birbirine zıt değildir. Tam tersine kaliteli e-ticaret mimarisinde teknik doğruluk ile ticari kurtarma birlikte çalışır.

404, Soft 404, 410 ve Redirect Arasındaki Fark

404 yönetiminin temeli doğru HTTP davranışını seçmektir. 404 bulunamayan kaynağı, 410 bilerek kaldırılan kaynağı, 301 kalıcı taşınmayı, 302 ve 307 ise geçici yönlendirmeyi ifade eder. Soft 404 gerçek bir HTTP kodu değildir, sayfanın kullanılabilir içerik sunmadığı hâlde 200 dönmesi veya alakasız şekilde yönlendirilmesi gibi durumları tanımlamak için kullanılır. E-ticaret sistemlerinde bu seçenekleri yalnızca teknik isimlerine göre değil, URL'nin yaşam döngüsüne göre seçmek gerekir. Yanlış seçim arama motoru taramasını, kullanıcı beklentisini ve ölçüm kalitesini etkileyebilir.

404 Not Found

404, kaynağın istenen adreste bulunmadığını belirtir. Hiç var olmamış URL'ler için doğal yanıttır. Kalıcı biçimde kaldırılmış ancak özel 410 politikası bulunmayan ürünler için de kullanılabilir. Kullanıcıya yine de markalı ve yardımcı bir sayfa sunulmalıdır. HTTP yanıtı doğru kalırken arayüz zengin olabilir.

410 Gone

410, kaynağın bilerek kaldırıldığı ve geri gelmesinin beklenmediği bilgisini daha açık ifade eder. Özellikle hukuki nedenle kaldırılmış içerik veya kalıcı olarak kapatılmış belirli sayfalar için kullanılabilir. Her silinen ürünü 410 yapma zorunluluğu yoktur. Kurumun tek ve tutarlı bir politika belirlemesi daha önemlidir. Kullanıcı deneyimi bakımından 410 sayfası da 404 gibi yararlı kurtarma yolları sunabilir.

301 Moved Permanently

301, kaynağın kalıcı olarak yeni bir adrese taşındığını belirtir. Aynı ürünün URL değişikliğinde güçlü bir seçimdir. Eski modelin doğrudan ve gerçek halefi varsa da kullanılabilir. Fakat ilişki zayıfsa 301 kullanıcıyı yanlış içeriğe götürür. Yönlendirme kararı benzerlik ve kullanıcı niyeti açısından doğrulanmalıdır.

302 / 307 Temporary Redirect

302 ve 307 geçici yönlendirme senaryolarında kullanılır. Ürünün geçici stok yokluğu tek başına PDP'yi başka yere yönlendirmek için yeterli değildir. Geçici bakım veya kısa süreli rota değişiklikleri bu kodlara daha uygun olabilir. Özellikle istek metodunun korunması gereken durumlarda 307 davranışı teknik açıdan önem taşır. E-ticaret ekipleri geçici yönlendirmelerin kalıcı hâle gelmediğini düzenli olarak kontrol etmelidir.

Soft 404

Soft 404, kullanıcıya içerik bulunamadığını hissettiren ancak teknik olarak başarılı yanıt döndüren veya anlamsız hedefe yönlendiren sayfalarda görülebilir. En bilinen örnek, “ürün bulunamadı” mesajı gösterirken HTTP 200 döndürmektir. Bir diğer örnek, artık mevcut olmayan her ürünü ana sayfaya göndermektir. Bu davranış tarama ve indeksleme sinyallerini bulanıklaştırabilir. Çözüm gerçek durum kodunu doğru üretmek ve yalnızca güçlü eşleşmelerde yönlendirme kullanmaktır.

HTTP 200 Dönen “Ürün Bulunamadı” Sayfasının Sorunu

Bir sayfa HTTP 200 döndürüyorsa istemciye başarılı bir kaynak sunulduğu mesajı verilmiş olur. İçerikte ise “ürün bulunamadı” yazıyorsa teknik sinyal ile kullanıcı arayüzü çelişir. Bu durum özellikle SPA ve headless yapılarda sık görülür. Arama motorları sayfanın değerini anlamakta zorlanabilir ve Search Console soft 404 işaretleri gösterebilir. Sunucu tarafında gerçek 404 yanıtı üretmek sorunun temel çözümüdür.

Doğru HTTP Durum Kodu Neden Önemlidir?

HTTP durum kodları arama motorlarının, tarayıcıların, API istemcilerinin ve izleme sistemlerinin ortak dilidir. Kullanıcı yalnızca ekrandaki mesajı görürken teknik sistemler yanıt koduna göre karar verir. Yanlış kod, başarılı ve başarısız isteklerin analytics verilerinde birbirine karışmasına neden olabilir. Aynı hata sitemap, canonical ve yönlendirme davranışlarıyla birleştiğinde indeks yönetimini daha da zorlaştırır. Bu yüzden durum kodu seçimi yalnızca backend ayrıntısı değil, SEO ve operasyon kararının parçasıdır.

Kullanıcı Deneyimi

Doğru status code kullanıcı arayüzünü doğrudan güzelleştirmez, ancak güvenilir uygulama davranışının temelini oluşturur. Frontend gerçek durumu bildiğinde doğru mesajı ve doğru kurtarma bileşenlerini gösterebilir. Hata izleme sistemi de kullanıcıların hangi rota üzerinde sorun yaşadığını ayırt edebilir. Bu bilgi UX ekibinin hangi senaryoya öncelik vereceğini belirlemesini kolaylaştırır. Sonuçta teknik doğruluk daha kontrollü kullanıcı deneyimine dönüşür.

Search Engine Crawling

Arama motoru botları URL'leri tararken HTTP yanıtlarını önemli sinyal olarak kullanır. Geçerli içerik 200, taşınan içerik 301 ve bulunamayan içerik 404 gibi tutarlı davranışlar tarama sürecini anlaşılır hâle getirir. Binlerce anlamsız URL'nin 200 dönmesi tarama kaynaklarının gereksiz kullanılmasına yol açabilir. Özellikle faceted navigation ile birleşen soft 404 yapıları büyük URL alanları oluşturabilir. Bu nedenle crawl yönetimi HTTP katmanından başlamalıdır.

Index Yönetimi

İndekslenebilir URL envanterinin gerçek katalogla uyumlu olması gerekir. Kaldırılmış sayfaların 200 dönmeye devam etmesi indeks kalitesini düşürebilir. 404 veya 410 sinyali artık bulunmayan sayfaların zamanla indeks dışına çıkmasına yardımcı olur. Kalıcı taşınmış içeriğin 301 ile yeni adrese aktarılması ise doğru hedefin güçlenmesini destekler. Sitemap ve internal link yapısı da bu davranışlarla aynı kararı yansıtmalıdır.

Canonical Sinyalleri

Canonical etiketi 404'ün yerine kullanılacak bir çözüm değildir. Geçerli bir sayfanın kopya veya alternatif URL'sini tercih edilen sürüme işaret etmek için kullanılır. Kaynak gerçekten yoksa önce HTTP davranışı belirlenmelidir. Bir 404 sayfasına başka bir ürünü canonical vermek sorunu çözmez. Canonical, yönlendirme ve status code farklı amaçlara sahip araçlardır.

Redirect Davranışı

Redirect kuralları HTTP durumuyla birlikte değerlendirilmelidir. Kaynak taşınmışsa 301 hem kullanıcıyı hem botu yeni hedefe götürür. Kaynak yoksa ve gerçek eşdeğer bulunmuyorsa yönlendirme üretmek zorunlu değildir. Gereksiz redirectler zaman içinde zincirlere ve alakasız hedeflere dönüşebilir. Bu nedenle her yönlendirme kayıt altında tutulmalı ve belirli aralıklarla gözden geçirilmelidir.

Monitoring ve Observability

Doğru durum kodları izleme sisteminin güvenilirliğini artırır. 404, 410, 301 ve 500 yanıtları ayrı ayrı izlenebilir. Route, referrer, user agent ve ürün bağlamı gibi alanlarla sorun kaynağı belirlenebilir. Ani 404 artışları deployment veya katalog senkronizasyonuyla karşılaştırılabilir. Böylece hata yönetimi reaktif kontrol yerine ölçülebilir operasyon sürecine dönüşür.

Soft 404 Nedir?

Soft 404, teknik olarak başarılı görünen ancak kullanıcıya gerçek ve yararlı içerik sunmayan URL davranışlarını tanımlamak için kullanılan bir kavramdır. Özellikle dinamik e-ticaret uygulamalarında API ürün bulamadığında frontend hata mesajı gösterir, fakat sunucu veya CDN hâlâ HTTP 200 döndürebilir. Benzer biçimde tüm kayıp ürünleri ana sayfaya göndermek de hedef ilişkisizse soft 404 değerlendirmesine yaklaşabilir. Dinamik URL yapısında 404 soft 404 ve yönlendirme stratejileri planlanırken sayfanın görünüşü kadar HTTP yanıtı kontrol edilmelidir. Testler hem tarayıcı arayüzünü hem response header bilgisini doğrulamalıdır.

Sayfa Bulunamadı Mesajı + HTTP 200

Bu senaryo en yaygın soft 404 örneklerinden biridir. Kullanıcı hata mesajı görür, ancak sunucu başarılı yanıt gönderir. Analytics sistemi sayfayı normal görüntüleme olarak kaydedebilir. Arama motoru da sayfanın gerçek durumunu anlamak için içerikten çıkarım yapmak zorunda kalır. Doğru çözüm, bulunamayan kaynak için HTTP 404 üretmektir.

Ana Sayfaya Otomatik Redirect

Kayıp her URL'yi ana sayfaya göndermek kullanıcı niyetini siler. Bir dizüstü bilgisayar modeli arayan ziyaretçi genel ana sayfaya ulaştığında neden yönlendirildiğini anlayamayabilir. Arama motorları da kaynak ile hedef arasındaki düşük ilişkiyi fark edebilir. Bu yaklaşım ölçüm açısından gerçek 404 miktarını gizler. Ana sayfa yalnızca kullanıcıya isteğe bağlı bir navigasyon seçeneği olarak sunulmalıdır.

Alakasız Ürüne Redirect

Yalnızca stokta olduğu için farklı bir ürüne otomatik 301 yapmak risklidir. Kullanıcı farklı özellik, fiyat veya kullanım amacı bekliyor olabilir. Redirect mantığı marka, kategori, ürün tipi, özellikler ve geçmiş davranış gibi sinyalleri değerlendirmelidir. Eşleşme zayıfsa alternatif ürün kartları göstermek daha güvenlidir. Kullanıcı böylece seçimi kendi yapabilir.

Boş İçerik Sayfaları

Şablonu çalışan ancak içerik alanları boş kalan ürün sayfaları da sorun yaratır. HTTP 200 dönen boş PDP gerçek ürün sayfası değildir. Bu durum katalog senkronizasyon hatalarından sonra görülebilir. Ürün kaydı bulunamadığında uygulama açık bir state üzerinden 404 kararına geçmelidir. Eksik veri geçici operasyon problemi ise ayrı incident mantığı uygulanabilir.

Boş Internal Search Results

Site içi aramada sıfır sonuç görmek otomatik olarak 404 anlamına gelmez. Arama sonuç sayfası kullanıcı sorgusuna geçerli cevap veriyor ve alternatif arama yolları sunuyorsa HTTP 200 mantıklı olabilir. Buradaki kritik nokta bu sayfaların indekslenebilir organik landing page olarak kullanılmamasıdır. Internal search URL politikası robots, noindex ve canonical stratejileriyle birlikte düşünülmelidir. “Sonuç yok” ile “kaynak yok” farklı kavramlardır.

Google Search Console'da Soft 404

Google Search Console soft 404 olarak değerlendirdiği URL'leri raporlayabilir. Bu rapor özellikle frontend'in 200 döndürdüğü hata sayfalarını fark etmek için değerlidir. Tek tek URL Inspection ile gerçek yanıt ve indeks durumu kontrol edilebilir. Tekrarlayan desen bulunursa route seviyesinde sistematik düzeltme yapılmalıdır. Düzeltme sonrası yalnızca birkaç URL'yi değil aynı şablonu kullanan tüm URL ailesini doğrulamak gerekir.

SPA ve Modern JavaScript Uygulamalarında Soft 404 Problemi

Tek sayfa uygulamalarında routing çoğunlukla tarayıcı tarafında gerçekleştiği için sunucu istenen bütün yollar için aynı HTML kabuğunu 200 yanıtıyla döndürebilir. JavaScript daha sonra API'ye gider ve ürünün bulunmadığını öğrendiğinde ekranda 404 bileşenini gösterir. Kullanıcı açısından her şey doğru görünürken HTTP seviyesinde hâlâ başarı yanıtı bulunur. Bu sorun özellikle client-side routing, cache katmanı ve headless commerce API'leri birlikte kullanıldığında sık görülür. Çözüm, mümkün olan yapılarda sunucu veya edge katmanının URL'nin gerçek durumunu bilmesini sağlamaktır.

Client-Side Routing

Client-side router ekranı değiştirebilir ancak ilk HTTP yanıtını geriye dönük değiştiremez. Bu nedenle doğrudan açılan ürün URL'lerinde sunucunun route durumunu bilmesi önemlidir. Uygulama yalnızca browser içinde 404 bileşeni gösteriyorsa botlar ve monitoring sistemi farklı sinyal alabilir. SSR veya edge doğrulaması bu açığı azaltabilir. Mimari karar kullanılan framework ve veri erişim modeline göre verilmelidir.

API'den Product Not Found Gelmesi

Commerce API ürün bulamadığında frontend bu state'i özel olarak ele almalıdır. API 404 döndürürken storefront 200 üretmeye devam ediyorsa katmanlar arasında anlam kaybı oluşur. SSR sürecinde API sonucunun sayfa response koduna aktarılması iyi bir yaklaşımdır. Client-side senaryoda ise server route manifest veya resolver servisi kullanabilir. Böylece backend gerçeği kullanıcıya gönderilen HTTP yanıtına yansır.

UI'nın 404 Gösterip Sunucunun 200 Döndürmesi

Bu problem görsel testlerle fark edilmeyebilir. QA yalnızca ekranda “ürün bulunamadı” mesajını görüp senaryoyu başarılı sayabilir. Test paketinde response status assertion bulunmadığında hata üretime taşınır. Bu yüzden regression testleri HTML içeriğinin yanında HTTP status'u da kontrol etmelidir. Özellikle kritik ürün, kategori ve geçersiz URL örnekleri otomatik teste eklenmelidir.

SSR ile Doğru Status Code

Server-side rendering, ürün verisini yanıt oluşturulmadan önce kontrol etme avantajı sağlar. Kaynak bulunamazsa sunucu 404 status ile markalı hata bileşenini döndürebilir. Ürün taşınmışsa aynı aşamada 301 üretilebilir. Böylece kullanıcı, bot ve analytics sistemi aynı gerçeği görür. SSR tek başına çözüm değildir, ancak doğru karar katmanını kurmayı kolaylaştırır.

Server-Side 404

Server-side 404 en güvenilir davranışlardan biridir. Router istenen kaynağın geçerli olmadığını yanıt oluşmadan belirler. Gerekirse 404 resolver eski URL kayıtlarını ve ürün lifecycle bilgisini kontrol eder. Uygun redirect bulunamazsa gerçek 404 döndürür. Frontend ise aynı yanıtta arama ve öneri bileşenlerini gösterebilir.

Error Route + Noindex Yaklaşımı

Noindex etiketi bazı hata benzeri sayfalarda yardımcı olabilir, ancak gerçek 404'ün alternatifi olarak görülmemelidir. Gerçek bulunamayan URL'nin 404 döndürmesi daha net bir sinyaldir. Error route yalnızca 200 dönüp noindex ekliyorsa sistem hâlâ yanlış durum kodu üretiyor olabilir. Noindex daha çok geçerli fakat arama sonuçlarında bulunması istenmeyen sayfalar için değerlendirilmelidir. HTTP, robots ve indexability kararları ayrı katmanlar olarak tasarlanmalıdır.

Next.js, React, Vue ve Headless Commerce Yapılarında 404

Modern e-ticaret storefront'larında 404 yönetimi framework isminden çok render modeline ve veri akışına bağlıdır. Next.js gibi SSR ve static generation seçenekleri sunan sistemlerde gerçek 404 üretmek görece kolaydır. React veya Vue tabanlı tamamen istemci taraflı yapılarda ise route durumunu sunucuya aktaran ek bir mekanizma gerekebilir. Headless commerce projelerinde ürün bilgisi başka servisten geldiği için storefront, commerce backend ve edge katmanının aynı lifecycle durumunu anlaması gerekir. İyi mimaride 404 kararı yalnızca görsel component seviyesinde bırakılmaz.

Server-Side Rendering

SSR sırasında ürün API'si çağrılır ve sonuç response oluşturulmadan değerlendirilir. Ürün aktifse 200, taşınmışsa 301, bulunamıyorsa 404 üretilebilir. Bu model botlar için açık ve tutarlı davranış sağlar. Cache anahtarlarının da status koduna uygun tasarlanması gerekir. Yanlış cache yapılandırması 404 yanıtının geçerli ürüne taşınmasına neden olmamalıdır.

Static Generation

Static generation büyük kataloglarda build ve güncelleme stratejisini önemli hâle getirir. Ürün kaldırıldığında eski statik dosyanın yaşamaya devam etmemesi gerekir. Incremental revalidation veya purge mekanizması lifecycle event ile tetiklenebilir. Kaldırılan URL için sonraki istekte doğru 404 veya redirect üretimi doğrulanmalıdır. Build sisteminin katalog gerçekliğinden kopması 200 dönen hayalet ürün sayfaları oluşturabilir.

Client-Side Rendering

CSR mimarisinde ilk response çoğu zaman generic HTML shell'dir. Ürün durumu JavaScript çalıştıktan sonra öğrenilir. Bu yapı gerçek HTTP 404 üretimini zorlaştırır. Edge middleware, server fallback veya URL registry gibi ek çözümler kullanılabilir. Kritik olan kullanıcı arayüzü ile network seviyesindeki yanıtın tutarlı olmasıdır.

Dynamic Route

Dinamik route yapıları ürün slug veya SKU bilgisine göre çok sayıda URL oluşturur. Route kalıbının eşleşmesi ürünün gerçekten var olduğu anlamına gelmez. Örneğin /urun/herhangi-bir-metin route'a uyabilir ancak katalogda karşılığı olmayabilir. Router bu durumda veri katmanından gelen state'i değerlendirmelidir. Catch-all route'un otomatik 200 üretmesi önlenmelidir.

Product API

Product API yalnızca null veri döndürmek yerine mümkünse ürün durumunu açık biçimde ifade etmelidir. ACTIVE, DISCONTINUED, REPLACED veya REMOVED gibi state'ler storefront kararını kolaylaştırır. Replaced ürün için successor SKU verisi de döndürülebilir. Böylece frontend tahmin yapmak zorunda kalmaz. SEO kararı katalog gerçeğine dayanır.

Commerce Backend

Commerce backend ürünün satış durumu ile URL durumunu ayrı alanlar olarak yönetebilmelidir. Stok sıfır olduğunda ürünü otomatik olarak “yok” saymak yanlış olabilir. Ürün stok dışı olsa bile PDP canlı kalabilir. Kalıcı kaldırma, replacement ve archive durumları farklı davranış gerektirir. Backend bu farkları resolver katmanına açıkça aktarmalıdır.

Edge Middleware

Edge middleware eski URL registry gibi hızlı okunan veriler için kullanılabilir. Kullanıcı origin'e gitmeden önce bilinen redirectler edge üzerinde uygulanabilir. Fakat her 404 isteğinde pahalı katalog sorgusu yapmak edge maliyetini artırabilir. Hafif lookup, cache ve güvenli fallback yaklaşımı kullanılmalıdır. Edge ile commerce backend arasında veri güncelliği için net senkronizasyon mekanizması gerekir.

Gerçek HTTP Status Code'un Korunması

Framework ne olursa olsun temel hedef gerçek durum kodunu korumaktır. Kullanıcı arayüzü ne kadar güzel olursa olsun bulunamayan ürün 200 dönüyorsa mimari eksiktir. Aynı şekilde kalıcı taşınmış ürün için kullanıcıya manuel link göstermek yerine uygun 301 daha verimli olabilir. Testler response status, Location header, canonical ve indexability alanlarını birlikte doğrulamalıdır. Bu yaklaşım framework değişse bile geçerliliğini korur.

E-Ticarette 404'ün Asıl Kaynağı: Ürün Yaşam Döngüsü

E-ticaret sitelerinde silinen ürün sayfaları 404 mü 301 mi olmalı sorusunun doğru cevabı, ürünün neden ve nasıl kaldırıldığı bilinmeden verilemez. “Stok yok”, “üretimden kalktı”, “yeni modelle değişti”, “URL değişti” ve “hukuki nedenle kaldırıldı” birbirinden farklı state'lerdir. Bunların hepsini veri tabanında silinmiş kayıt olarak göstermek SEO ve UX kararını yetersiz bırakır. Ürün lifecycle'ı açık biçimde modellenirse URL davranışı otomatik ve tutarlı hâle gelebilir. Böylece katalog operasyonu değiştiğinde SEO ekibinin tek tek URL peşinde koşmasına gerek kalmaz.

Active Product

Aktif ürün normal PDP davranışını sürdürür. HTTP 200 döner ve canonical kendi geçerli URL'sini gösterir. Ürün sitemap içinde yer alabilir. Internal linkler aktif ürüne yönelir. Structured data güncel fiyat ve availability bilgisiyle uyumlu olmalıdır.

Temporarily Out of Stock

Geçici stok yokluğu çoğu durumda ürünün ortadan kalktığı anlamına gelmez. PDP 200 ile canlı tutulabilir. Kullanıcıya stok durumu açıkça gösterilir ve satın alma butonu uygun şekilde yönetilir. Stok bildirimi veya benzer ürünler sunulabilir. Ürünün geri gelmesi bekleniyorsa URL'yi silmek gereksiz organik kayıp yaratabilir.

Seasonal Product

Sezonluk ürünler dönem dışında satışa kapalı olabilir ancak sonraki sezonda geri gelebilir. Bu ürünler için sayfayı korumak çoğu zaman anlamlıdır. İçerikte sezon bilgisi ve alternatifler gösterilebilir. Sitemap politikası ürünün indekslenme hedeflerine göre ayrıca belirlenir. Her sezon yeni URL üretmek yerine kalıcı ürün veya kategori adresi kullanmak SEO sürekliliğini artırabilir.

Discontinued Product

Üretimden kalkan ürünün geri gelmesi beklenmez. Ancak sayfanın backlink, organik trafik ve kullanıcı bilgi ihtiyacı devam edebilir. Doğrudan halef ürün bulunuyorsa ilişki doğrulanarak 301 düşünülebilir. Alternatif yoksa 404, 410 veya bilgi amaçlı arşiv PDP politikalarından biri seçilebilir. Kararın kurumsal ölçekte tutarlı olması gerekir.

Replaced Product

Replaced state eski ürünün yeni bir modelle değiştirildiğini açıkça belirtir. Halef ürün gerçek ve doğrudan karşılıksa 301 güçlü adaydır. Fiyat segmenti veya kullanım amacı ciddi biçimde değişmişse otomatik yönlendirme dikkatle değerlendirilmelidir. Eski ürün bilgisi kullanıcılar için değerliyse kısa arşiv içerik de düşünülebilir. Resolver servisi successor SKU bilgisini doğrudan lifecycle kaydından okuyabilir.

Merged Product

Bazen birden fazla ürün sayfası tek bir ana üründe birleştirilir. Eski SKU'ların hepsi yeni ana ürüne anlamlı biçimde karşılık geliyorsa 301 mapping oluşturulabilir. Canonical tek başına kullanıcıyı taşımadığı için gerçek URL migration durumunda yeterli değildir. Internal linkler doğrudan yeni hedefe güncellenmelidir. Zincir oluşmaması için eski kaynaklar tek adımda son hedefe yönlendirilmelidir.

Deleted Product

Deleted state çoğu zaman eksik bir modellemedir. Ürünün neden silindiği bilinmiyorsa doğru URL kararı verilemez. Sistem hard delete yerine arşivlenmiş lifecycle kaydı tutmalıdır. Böylece eski SKU, URL ve silme nedeni daha sonra resolver tarafından bulunabilir. En azından yüksek trafik alan kataloglarda ürün geçmişini tamamen kaybetmemek ciddi operasyon avantajı sağlar.

Legally Removed Product

Hukuki veya uyumluluk nedeni bulunan içerik ayrı state olarak işaretlenebilir. Bazı durumlarda ürün bilgisinin kullanıcıya gösterilmemesi gerekir. Redirect yapılması da uygun olmayabilir. 404 veya 410 politikası hukuk ve ürün ekipleriyle birlikte belirlenmelidir. Hata sayfası hassas kaldırma nedenlerini gereksiz biçimde açıklamamalıdır.

Ürün Durumu ile URL Durumu Aynı Şey Değildir

En önemli tasarım prensiplerinden biri ürün satış durumu ile URL durumunu birbirinden ayırmaktır. Ürün stokta olmayabilir fakat URL hâlâ geçerli olabilir. Ürün yeni modele geçmiş olabilir ve eski URL artık redirect gerektirebilir. Ürün verisi yanlışlıkla kaybolmuşsa gerçek karar 404 vermek değil, veri incident'ını düzeltmek olabilir. Bu ayrım ürün ekibi ile SEO ve engineering ekiplerinin aynı kavramları kullanmasını sağlar.

Stokta Olmayan Ürün Silinmeli mi?

Genellikle hayır. Geçici stok yokluğu ürünün kullanıcı ve arama motoru açısından değersiz olduğu anlamına gelmez. Ürün sayfası fiyat geçmişi, teknik özellik, yorumlar ve organik görünürlük taşıyabilir. 200 PDP üzerinde OutOfStock bilgisi sunmak çoğu senaryoda daha mantıklıdır. Stok geri geldiğinde URL yeniden oluşturmak yerine aynı adres üzerinde devam edilir.

Kalıcı Olarak Kaldırılan Ürün

Kalıcı kaldırmada önce gerçek alternatif aranmalıdır. Doğrudan halef veya bire bir karşılık bulunuyorsa 301 değerlendirilebilir. Alternatif yoksa 404 ya da kurumsal politikaya göre 410 kullanılabilir. Yüksek backlink değeri tek başına alakasız redirect için gerekçe değildir. Kullanıcı niyeti daima kararın parçası olmalıdır.

Yeni Modelle Değiştirilen Ürün

Yeni model eski ürünün gerçek devamıysa redirect kullanıcıya yarar sağlayabilir. Örneğin yalnızca model yılı yenilenmiş ve ürün aynı ihtiyacı karşılıyorsa eşleşme yüksektir. Buna rağmen özellikler ve fiyat aralığı ciddi değişmişse öneri göstermek daha uygun olabilir. Otomatik sistem confidence score ile karar verebilir. Yüksek değerli URL'lerde manuel review ek güven sağlar.

URL'si Değişen Aynı Ürün

Aynı ürün yalnızca yeni slug veya taksonomi nedeniyle adres değiştirdiyse 301 en açık çözümdür. Eski URL'den yeni URL'ye doğrudan tek adımlı yönlendirme yapılmalıdır. Sitemap yeni URL'yi içermeli, eskiyi çıkarmalıdır. Internal linkler de redirect üzerinden geçmek yerine yeni adrese güncellenmelidir. Canonical yeni URL'yi göstermelidir.

Ürün Verisi Kaybolan Hatalı Durum

Katalog senkronizasyon hatasında ürün geçici olarak API'den kaybolabilir. Sistemin bunu kalıcı silme olarak yorumlayıp binlerce 404 üretmesi büyük sorun yaratabilir. Lifecycle ve import state bilgisinin ayrı tutulması bu riski azaltır. Ani toplu ürün kaybı incident alarmı oluşturmalıdır. Gerekirse kısa süreli güvenli cache veya hata yönetimiyle gerçek katalog doğrulanana kadar kontrollü davranış uygulanabilir.

Ürün State Machine Nasıl Tasarlanmalı?

Ürün state machine, ticari durum ile teknik davranış arasındaki bağlantıyı kurar. ACTIVE, OUT_OF_STOCK, BACKORDER, DISCONTINUED, REPLACED, ARCHIVED ve REMOVED gibi state'ler herkes tarafından aynı anlamda kullanılmalıdır. Her state yalnızca admin panel etiketi olmamalı, HTTP status, sitemap, search index, recommendation ve analytics davranışlarını tetiklemelidir. Event-driven mimari bu geçişleri diğer sistemlere güvenilir şekilde yayabilir. Böyle bir model büyüyen kataloglarda manuel SEO müdahalesini ciddi ölçüde azaltır.

ACTIVE

ACTIVE ürün satışa ve görüntülenmeye açık temel state'tir. PDP 200 döner. Search index ve sitemap içinde yer alması beklenir. Recommendation motoru ürünü aday olarak kullanabilir. Internal link üretimi aktif URL'yi hedeflemelidir.

OUT_OF_STOCK

OUT_OF_STOCK geçici stok yokluğunu tanımlar. URL çoğu durumda 200 olarak yaşamaya devam eder. Satın alma CTA'sı devre dışı bırakılabilir veya stok bildirimi sunulabilir. Structured data availability alanı gerçek durumu yansıtmalıdır. Recommendation motoru bu ürünü alternatif listelerinde göstermemeyi tercih edebilir.

BACKORDER

BACKORDER ürünün ileri tarihli sipariş kabul ettiğini ifade eder. PDP canlıdır ve 200 döner. Kullanıcı teslim süresi konusunda açıkça bilgilendirilmelidir. Structured data ile sayfa içeriği birbiriyle uyumlu olmalıdır. Sipariş deneyimi stokta ürün gibi sunulmamalıdır.

DISCONTINUED

DISCONTINUED ürün artık üretilmiyor veya satılmıyordur. Sistemin successor ilişkisini kontrol etmesi gerekir. Doğrudan halef varsa 301 veya arşiv PDP üzerinde halef önerisi değerlendirilebilir. Halef yoksa 404 veya 410 politikası uygulanabilir. Karar, ürünün trafik ve içerik değerine göre farklılaşabilir.

REPLACED

REPLACED state eski üründen yenisine açık ilişki kurar. Successor SKU zorunlu alan olarak saklanabilir. Yüksek relevance varsa resolver otomatik 301 oluşturabilir. Düşük güven durumunda eski sayfa 404 ile alternatif önerebilir. Bu state redirect kararının tahmine değil katalog verisine dayanmasını sağlar.

ARCHIVED

ARCHIVED ürün satılmıyor ancak bilgi amaçlı sayfa yaşamaya devam ediyordur. HTTP 200 kullanılması mümkündür çünkü gerçek içerik hâlâ sunulmaktadır. Sayfada ürünün artık satışta olmadığı açıkça belirtilmelidir. Arşiv sayfalarının indekslenip indekslenmeyeceği ayrı SEO politikasına bağlıdır. Güncel alternatifler kullanıcıya sunulabilir.

REMOVED

REMOVED state ürünün artık içerik olarak sunulmayacağını belirtir. Redirect ilişkisi yoksa 404 veya 410 kullanılabilir. Search index, sitemap ve recommendation adaylarından çıkarılmalıdır. Internal linkler temizlenmelidir. Audit trail içinde kaldırma nedeni ve tarih saklanmalıdır.

Her State İçin HTTP ve UX Davranışı

State machine ancak teknik davranışla eşlendiğinde değer üretir. Her ürün durumu için HTTP kodu, PDP davranışı, sitemap görünürlüğü, search index state'i ve öneri uygunluğu belirlenmelidir. Bu kurallar kod içine dağınık if koşulları şeklinde gömülmemelidir. Merkezi policy veya resolver üzerinden yönetilmesi bakım kolaylığı sağlar. Değişikliklerin QA testlerine otomatik yansıması da mümkündür.

Temporarily Out of Stock Ürünlerde Ne Yapılmalı?

Geçici stok yokluğu e-ticarette yanlış 404 üretiminin en yaygın nedenlerinden biridir. Ürün geri gelecekse veya kullanıcı açısından bilgi değeri devam ediyorsa PDP'yi canlı tutmak genellikle daha sağlıklıdır. Sayfa HTTP 200 dönebilir, ancak stok durumu açıkça belirtilmelidir. Sepete ekle butonunun davranışı, stok bildirimi ve benzer ürün önerileri kullanıcıyı belirsizlikte bırakmamalıdır. Böylece organik landing page korunurken kullanıcıya gerçek ticari durum gösterilir.

PDP'yi Canlı Tutmak

Geçici stok yokluğunda PDP'nin kaldırılması gereksiz URL değişimi yaratır. Kullanıcı ürün özelliklerini ve yorumlarını görmeye devam edebilir. Search trafiği geçerli bilgi sayfasına ulaşır. Ürün geri geldiğinde aynı URL kullanılmaya devam eder. Bu süreklilik teknik ve kullanıcı deneyimi açısından faydalıdır.

HTTP 200

Sayfada gerçek ürün içeriği mevcutsa 200 mantıklıdır. Stok yokluğu kaynağın bulunamadığı anlamına gelmez. HTTP 404 yalnızca stok olmadığı için kullanılmamalıdır. Sayfa içeriği ürünün mevcut ticari durumunu doğru göstermelidir. Monitoring sistemi stok state'ini status code'dan ayrı izlemelidir.

Stok Durumunu Açıkça Göstermek

Kullanıcı ürünün neden satın alınamadığını hemen anlamalıdır. “Stokta yok” ifadesi gizlenmemelidir. Tahmini dönüş tarihi biliniyorsa gösterilebilir. Tarih bilinmiyorsa gerçek dışı beklenti oluşturulmamalıdır. Açıklık, kullanıcının alternatif ürün değerlendirmesini kolaylaştırır.

Sepete Ekle Butonunu Yönetmek

Stokta olmayan üründe aktif görünen ancak işlem yapmayan buton güven kaybı yaratır. Buton devre dışı bırakılabilir veya stok bildirimi aksiyonuna dönüştürülebilir. Backorder destekleniyorsa teslim tarihi açıkça anlatılmalıdır. Mobil ve masaüstü davranış aynı kuralları izlemelidir. Analytics olayları kullanıcıların hangi seçeneğe yöneldiğini ölçmelidir.

Stok Gelince Haber Ver

Stok bildirimi kullanıcı niyetini korumanın etkili yollarından biridir. E-posta veya hesap içi bildirim kullanılabilir. Kullanıcıdan yalnızca gereken bilgiyi istemek önemlidir. İzin ve gizlilik kuralları açık biçimde uygulanmalıdır. Bildirim dönüşleri ayrı conversion eventi olarak izlenebilir.

Benzer Ürünler

Benzer ürünler stokta olmayan PDP'de güçlü bir fallback oluşturur. Önerilerin gerçekten aynı ihtiyacı karşılaması gerekir. Stok durumu güncel olmayan ürünlerin önerilmesi kullanıcıyı ikinci kez çıkmaza sokar. Marka, kategori, özellik ve fiyat aralığı birlikte değerlendirilebilir. Kullanıcıya birkaç güçlü seçenek göstermek onlarca zayıf seçenekten daha yararlıdır.

Tahmini Stok Tarihi

Tahmini tarih yalnızca güvenilir veri mevcutsa gösterilmelidir. Tedarik sistemi sürekli değişen tarih gönderiyorsa kullanıcı beklentisi zarar görebilir. Tarih değişiklikleri frontend cache'e doğru yansıtılmalıdır. Belirsiz durumda “stok tarihi henüz net değil” gibi açık ifade kullanılabilir. Bu bilgi SEO kararından çok kullanıcı deneyimi ve conversion üzerinde etkilidir.

Product Structured Data Güncellemesi

Structured data sayfada görünen bilgiyle uyumlu olmalıdır. Ürün stok dışıysa availability alanı bunu yansıtmalıdır. Sayfada olmayan fiyat veya stok bilgisinin schema içinde farklı görünmesi önlenmelidir. Structured data HTTP durum kodunun yerine geçmez. Teknik SEO kontrolü HTML, schema ve commerce verisini birlikte doğrulamalıdır.

Kalıcı Olarak Kaldırılan Ürünlerde Ne Yapılmalı?

Kalıcı kaldırılan ürünlerde otomatik olarak 301 veya otomatik olarak 404 seçmek yerine önce URL'nin değerini ve yeni karşılığını incelemek gerekir. Organik trafik, backlink, referral trafik, satış geçmişi ve marka aramaları eski sayfanın önemini gösterebilir. Ardından kullanıcı niyetini gerçekten karşılayan yeni ürün veya kategori bulunup bulunmadığı kontrol edilir. Yakın ve güçlü karşılık varsa 301 kullanılabilir. Gerçek karşılık yoksa 404 veya 410 ile yardımcı alternatifler sunmak daha güvenlidir.

Önce Sayfanın Değerini Ölçmek

Her kaldırılmış ürün aynı öncelikte değildir. Bazı URL'ler hiç trafik almazken bazıları yıllardır backlink ve organik görünürlük biriktirmiş olabilir. Analytics, Search Console, server log ve backlink verileri birlikte kullanılabilir. Yüksek değerli sayfalar manuel review listesine alınabilir. Bu yaklaşım ekip kaynaklarının en çok etki yaratacak URL'lere ayrılmasını sağlar.

Organik Trafik

Geçmiş organik oturumlar sayfanın kullanıcı talebi taşıyıp taşımadığını gösterir. Son birkaç hafta yerine yeterli tarih aralığı değerlendirilmelidir. Sezonluk ürünlerde yıllık kıyas daha anlamlı olabilir. Trafik tek başına redirect gerekçesi değildir. Yine de URL'nin öncelik skorunda güçlü sinyal oluşturur.

Backlink

Backlinkler eski URL'nin dış web ekosistemindeki değerini gösterir. Kaliteli ve ilgili bağlantılar yeni karşılık varsa 301 kararını daha önemli hâle getirebilir. Ancak link değerini korumak adına alakasız sayfaya yönlendirme yapılmamalıdır. Gerekirse yüksek değerli birkaç dış kaynak için outreach yapılabilir. Amaç hem kullanıcıyı hem kaynak siteyi doğru hedefe taşımaktır.

Referral Trafik

Referral trafik eski bağlantıların hâlâ insanlar tarafından kullanıldığını gösterebilir. Forum, inceleme veya içerik sayfalarından gelen kullanıcılar yüksek satın alma niyeti taşıyabilir. Bu trafik 404 recovery davranışıyla birlikte izlenmelidir. Doğru alternatif sunulması conversion kaybını azaltabilir. Referral kaynağı ayrıca eski bağlantının güncellenmesi için outreach fırsatı yaratabilir.

Satış Geçmişi

Ürünün geçmiş satış hacmi, eski URL'ye gelen kullanıcıların ticari değerini anlamaya yardımcı olur. Çok satılan ürünlerin eski bağlantıları uzun süre dolaşımda kalabilir. Successor ürünle açık ilişki varsa redirect güçlü sonuç verebilir. İlişki yoksa eski ürün adıyla arama yapan kullanıcıya alternatif listesi gösterilebilir. Revenue geçmişi criticality score içinde kullanılabilir.

Marka Araması

Kullanıcılar eski model adını doğrudan aramaya devam edebilir. Bu durumda bilgi amaçlı arşiv sayfası veya yeni model açıklaması yararlı olabilir. Yalnızca ürün artık satılmıyor diye bütün bilgi izlerini silmek kullanıcı ihtiyacını yok sayabilir. Marka araması yüksekse içerik stratejisi ayrıca değerlendirilmelidir. Arşiv sayfası kullanılacaksa satışta olmadığı açıkça belirtilmelidir.

Gerçek Alternatif Ürün Var mı?

Redirect kararı öncelikle bu soruya bağlıdır. Yeni hedef eski ürünü gerçekten karşılıyor mu, yoksa yalnızca aynı kategori içinde mi bulunuyor? Aynı kullanım amacı, ürün tipi, marka ve özellik seti eşleşmeyi güçlendirir. Fiyat aralığı çok farklıysa kullanıcı beklentisi bozulabilir. Otomatik scoring ve gerektiğinde manuel review birlikte kullanılabilir.

Alternatif Yoksa 404 / 410

Gerçek karşılık yoksa 404 veya 410 dürüst ve teknik açıdan temiz çözümdür. Hata sayfasında site içi arama ve ilgili kategori sunulabilir. Böylece kullanıcı kontrolü korunur. Search engine gereksiz bir redirect takip etmek zorunda kalmaz. URL de zamanla geçerli indeks envanterinden çıkar.

Yakın Karşılık Varsa 301

Yakın karşılık kavramı açık kriterlerle tanımlanmalıdır. Aynı SKU'nun yeni URL'si en güçlü eşleşmedir. Doğrudan successor ürün de yüksek güvenli seçenek olabilir. Yalnızca aynı kategoride olmak ise çoğu zaman yeterli değildir. Relevance threshold altında kalan eşleşmeler öneri olarak sunulmalıdır.

Eski Ürün Bilgisini Arşivleme Seçeneği

Bazı ürünler teknik özellik veya kullanım kılavuzu nedeniyle bilgi değeri taşımaya devam eder. Böyle durumlarda arşiv PDP mantıklı olabilir. Sayfa 200 döner ancak ürünün artık satılmadığını açıkça söyler. Güncel halef veya alternatif ürünler içerikte gösterilebilir. Arşiv stratejisi özellikle uzun ömürlü teknik ürünlerde faydalı olabilir.

404 mü 410 mu?

404 ve 410 arasındaki fark pratikte çoğu ekip için politika düzeyinde ele alınmalıdır. 404 kaynağın bulunamadığını, 410 ise bilinçli olarak kaldırıldığını daha açık biçimde belirtir. Her katalog kaldırma işleminde bu ayrımı yönetmek operasyon yükü oluşturuyorsa tek bir tutarlı 404 politikası kullanılabilir. Buna karşılık hukuki kaldırma veya kesin sonlandırılmış belirli içerikler için 410 tercih edilebilir. Kullanıcı deneyimi bakımından her iki durumda da yararlı navigasyon seçenekleri sunmak gerekir.

Kaynak Hiç Yoksa 404

Hiç var olmamış rastgele URL için 404 doğal yanıttır. Sistem geçmiş kayıt araması yapıp eşleşme bulamazsa bu sonucu döndürebilir. Otomatik redirect üretmeye çalışmak gereksizdir. Hata sayfası yine de site araması sunabilir. Bot kaynaklı rastgele isteklerde pahalı recommendation çağrılarından kaçınılmalıdır.

Bilerek ve Kalıcı Olarak Kaldırılan İçerik

Bu durumda 410 değerlendirilebilir. Özellikle içeriğin geri gelmeyeceği kesin ve sistem tarafından biliniyorsa sinyal daha açıktır. E-ticaret kataloglarında 404 kullanmak da teknik olarak yaygın ve kabul edilebilir bir politikadır. Kritik olan yanlışlıkla 200 döndürmemektir. Ayrıca sitemap ve internal linklerin aynı state'i yansıtması gerekir.

Kullanıcı Açısından Fark

Kullanıcı çoğu zaman 404 ile 410 arasındaki HTTP farkını görmez. Her iki durumda da hedef içeriğe ulaşamamıştır. UX metni teknik kodu açıklamak yerine ne yapılabileceğine odaklanmalıdır. Arama, kategori ve uygun ürün alternatifleri öne çıkarılabilir. Kullanıcıyı kod numarasıyla baş başa bırakmak fayda sağlamaz.

SEO Açısından Fark

Her iki durum kodu da artık geçerli olmayan kaynakları ifade eder. 410 kaldırma niyetini daha açık iletir. Ancak SEO stratejisinin başarısı tek başına bu kod seçimine bağlı değildir. Internal link temizliği, sitemap güncelliği ve doğru redirect kullanımı daha geniş etki yaratır. Ekip 404 ve 410 politikasını tutarlı uygulamalıdır.

Kurumsal Olarak Tek Bir Politika Tanımlamak

Büyük kataloglarda istisnasız kurallar operasyonu kolaylaştırır. Örneğin hiç var olmayan ve karşılığı olmayan URL 404, hukuk nedeniyle kaldırılan URL 410 şeklinde politika kurulabilir. Ürün successor ilişkisinde 301 ayrı dal olarak ele alınır. Bu kurallar dokümante edilip otomatik testlere bağlanmalıdır. Böylece farklı ekipler aynı senaryoda farklı karar üretmez.

301 Redirect Ne Zaman Kullanılmalı?

301 redirect bir URL'nin kalıcı olarak yeni bir adrese taşındığını anlatır. E-ticarette en güçlü kullanım alanı aynı ürünün URL değişikliği veya gerçek successor ilişkisidir. Kullanıcı eski bağlantıya tıkladığında beklediği içeriğe çok yakın bir hedef görmelidir. Yönlendirme relevance üzerine kurulmadığında kullanıcı memnuniyeti düşer ve soft 404 benzeri değerlendirme riski oluşur. 301'i “SEO değerini kurtaran genel araç” olarak değil, gerçek kaynak eşleşmesini ifade eden teknik mekanizma olarak düşünmek daha sağlıklıdır.

Aynı Ürünün Yeni URL'si

Aynı ürün yalnızca slug veya route değişikliği nedeniyle taşınmışsa 301 kullanılmalıdır. Eski URL doğrudan yeni URL'ye yönlendirilir. Zincir oluşturulmamalıdır. Internal link ve sitemap yeni hedefe güncellenmelidir. Böylece migration süreci hem kullanıcı hem bot açısından anlaşılır kalır.

Yeni Nesil Ürün

Yeni nesil ürün eski modelin doğrudan devamıysa redirect değerlendirilebilir. Özellik seti ve kullanım amacı büyük ölçüde korunmalıdır. Fiyat veya kategori çok farklılaşmışsa öneri göstermek daha doğru olabilir. Otomatik model yüksek confidence aramalıdır. Ticari ekip successor ilişkisini katalog verisinde açıkça tanımlayabilir.

Bire Bir Alternatif

Bire bir alternatif aynı ihtiyacı çok yakın özelliklerle karşılayan üründür. Kullanıcı eski URL'den geldiğinde hedefi beklenmedik bulmamalıdır. Aynı ürün ailesi ve marka güçlü sinyaldir. Fiyat segmenti ve temel özellikler de kontrol edilmelidir. Yeterli eşleşme yoksa redirect yerine 404 üzerinde alternatif sunmak daha güvenlidir.

Birleştirilen Ürün Sayfaları

Birden çok eski sayfa tek ana PDP altında birleştirilebilir. Eski URL'ler yeni ana sayfaya 301 ile taşınabilir. Bu durumda eski variant veya SKU bilgisi yeni PDP üzerinde hâlâ anlamlı olmalıdır. Canonical ve internal linkler yeni yapıya göre güncellenir. Redirect registry birleşme nedenini kaydetmelidir.

Yeniden Yapılandırılan Kategoriler

Kategori taksonomisi değiştiğinde eski kategoriyle yeni kategori arasındaki anlam ilişkisi kontrol edilir. Gerçek bire bir karşılık varsa 301 uygundur. Eski kategori birkaç yeni kategoriye bölündüyse tek hedef seçmek kullanıcı niyetini bozabilir. Bu durumda 404 veya seçim sayfası değerlendirilebilir. Mapping kararları ürün kapsamı karşılaştırılarak yapılmalıdır.

Eski Kampanya İçeriğinin Kalıcı Karşılığı

Eski kampanya yeni ve kalıcı bir landing page ile gerçek devamlılık taşıyorsa 301 kullanılabilir. Yıllık kampanya aynı tema ve ürün kapsamıyla tekrarlanıyorsa evergreen URL daha iyi çözüm olabilir. Her yıl yeni adres oluşturmak redirect yükünü artırır. Kampanya bittiğinde URL davranışı daha kampanya başlamadan planlanmalıdır. Böylece son gün acele karar verilmez.

301 Redirect Ne Zaman Kullanılmamalı?

Her ölü URL'yi başka bir sayfaya göndermek teknik borcu gizler. İlgisiz ürün, genel kategori veya ana sayfa gibi hedefler kullanıcının aradığı bağlamı kaybettirebilir. Yönlendirme yalnızca gerçek taşınma veya yüksek relevance varsa kullanılmalıdır. Kullanıcı niyeti açık değilse 404 üzerinde arama ve alternatif önerileri daha güvenlidir. Bu yaklaşım uzun vadede redirect registry'nin de yönetilebilir kalmasını sağlar.

İlgisiz Ürün

Aynı mağazada bulunması iki ürünü redirect için yeterince ilişkili yapmaz. Kaldırılan kahve makinesini rastgele bir mutfak ürününe yönlendirmek kötü deneyim yaratır. Marka, kategori, kullanım amacı ve özelliklerin birlikte eşleşmesi gerekir. Eşleşme düşükse kullanıcıya seçenek sunulmalıdır. Otomatik sistemler bu sınırı confidence score ile uygulayabilir.

Sadece SEO Değeri Aktarmak İçin

Redirect kararının tek nedeni geçmiş backlink değeri olmamalıdır. Kullanıcı eski bağlantıya tıkladığında yeni sayfanın neden açıldığını anlayabilmelidir. Alakasız hedefe değer taşımaya çalışma uzun vadede kalite sinyallerini bozabilir. Daha doğru seçenek gerçek 404 ve gerekiyorsa backlink kaynağıyla iletişim kurmaktır. SEO kullanıcı niyetinden ayrı düşünülmemelidir.

Her Ürünü Ana Sayfaya Yönlendirmek

Bu politika uygulaması kolay görünür ancak bilgi kaybı yaratır. Eski SKU, kategori ve ürün niyeti tamamen silinir. Analytics gerçek 404 oranını da göremez. Kullanıcı aradığı ürün yerine genel vitrine döner. Ana sayfa otomatik redirect hedefi değil, 404 içindeki opsiyonel bağlantılardan biri olmalıdır.

Çok Genel Bir Kategoriye Kör Redirect

Eski ürün ile kategori arasında ilişki olsa bile kullanıcının beklediği ayrıntı düzeyi farklıdır. Belirli bir kamerayı arayan kişiyi “Elektronik” kategorisine göndermek fazla geneldir. Daha dar ve anlamlı kategori varsa değerlendirilebilir. Hiçbir güçlü hedef yoksa 404 üzerinde birkaç seçenek sunmak daha şeffaftır. Redirect relevance için minimum eşik tanımlanmalıdır.

Kullanıcı Niyetini Bozan Yönlendirme

Yönlendirme teknik olarak çalışsa bile kullanıcı hedefte hemen geri dönüyorsa karar başarısız olabilir. Redirect sonrası bounce, ürün etkileşimi ve conversion verileri izlenmelidir. Düşük performans gösteren mappingler review kuyruğuna alınabilir. Böylece redirect registry yaşayan bir sistem hâline gelir. Kullanıcı davranışı relevance modelinin kalibrasyonunda kullanılabilir.

Ana Sayfaya Toplu Redirect Neden Kötü Bir Stratejidir?

Toplu ana sayfa yönlendirmesi kolay bir çözüm gibi görünür çünkü 404 sayısı azalır. Fakat ölçülen 404 azalırken kullanıcı problemi ortadan kalkmaz, yalnızca görünmez hâle gelir. Eski ürün bağlamı kaybolur, Search Console ve analytics verileri yanlış yorumlanabilir ve alakasız yönlendirmeler soft 404 riskini artırabilir. Kullanıcı da istediği içeriği bulmak için aramaya baştan başlamak zorunda kalır. Büyük e-ticaret sistemlerinde doğru yaklaşım, yüksek güvenli eşleşmeleri yönlendirmek ve diğer durumlarda gerçek 404 recovery deneyimi sunmaktır.

Kullanıcı Beklentisini Bozar

Kullanıcı belirli bir ürün linkine tıkladığında belirli ürün bağlamı bekler. Ana sayfa bu beklentiyi karşılamaz. Kullanıcı hata olduğunu bile anlamayabilir. Bu belirsizlik hızlı çıkış oranını artırabilir. Açık 404 mesajı ve ilgili alternatifler daha anlaşılır deneyim sağlar.

Aranan Ürün Bağlamını Kaybettirir

Eski URL'nin slug veya SKU bilgisi değerli bağlam taşır. Ana sayfaya redirect bu bağlamı arayüzden siler. Resolver ise aynı bilgiyi kullanarak arama sorgusu veya ürün önerisi oluşturabilir. Kullanıcının birkaç tıklamayla doğru alternatife ulaşması mümkün olur. Bağlamı korumak smart 404 tasarımının temelidir.

Soft 404 Riski

Alakasız URL'lerin aynı genel sayfaya toplu yönlendirilmesi arama motoru açısından düşük kaliteli davranış olabilir. Kaynak ve hedef anlamlı biçimde eşleşmiyorsa redirect doğru taşınma sinyali vermez. Bu nedenle yalnızca 301 kodunun varlığı başarılı SEO davranışı anlamına gelmez. İçerik ilişkisi de doğrulanmalıdır. Düşük relevance durumunda gerçek 404 daha temizdir.

Conversion Kaybı

Ana sayfaya dönen kullanıcı yeniden kategori seçmek ve arama yapmak zorunda kalır. Her ek adım satın alma niyetini zayıflatabilir. Dinamik 404 ise eski ürün bağlamına göre doğrudan birkaç ilgili seçenek sunabilir. Recovery funnel ölçüldüğünde hangi yaklaşımın daha çok ürün görüntüleme ve sepete ekleme oluşturduğu görülebilir. Tasarım kararı veriye dayanmalıdır.

Debugging'i Zorlaştırır

Her kayıp URL 301 ile gizlendiğinde gerçek broken link kaynaklarını bulmak zorlaşır. Internal link hataları aylarca fark edilmeyebilir. Redirect logları ve source reason alanları olmadan neden yönlendirme yapıldığı bilinmez. Doğrudan ana sayfa redirecti deployment hatalarını bile maskeleyebilir. Monitoring sistemi gerçek kaynak state'ini saklamalıdır.

Redirect Relevance Nasıl Ölçülmeli?

Redirect relevance, eski URL ile hedef sayfanın kullanıcı açısından ne kadar yakın olduğunu ölçer. Aynı SKU ailesi, marka, kategori, ürün tipi, temel özellikler, fiyat aralığı ve search intent gibi sinyaller birlikte kullanılabilir. Tek bir alan üzerinden karar vermek hatalı sonuç üretir. Örneğin aynı marka içinde tamamen farklı ürün tipleri bulunabilir. Minimum relevance threshold belirlenerek yalnızca yüksek güvenli eşleşmeler otomatik yönlendirilmelidir.

Aynı SKU Ailesi

Aynı ürün ailesi güçlü eşleşme sinyalidir. Eski SKU yeni varyant veya successor SKU ile doğrudan ilişkilendirilmiş olabilir. Bu ilişki PIM içinde tutulabiliyorsa tahmin ihtiyacı azalır. Otomatik redirect için en güvenilir veri kaynaklarından biridir. Yine de ürünün gerçekten aktif olduğu kontrol edilmelidir.

Aynı Marka

Marka eşleşmesi faydalıdır ancak tek başına yeterli değildir. Büyük markalar onlarca farklı ürün kategorisi sunabilir. Marka sinyali kategori ve ürün tipiyle birlikte değerlendirilmelidir. Kullanıcı eski üründe markaya güçlü bağlılık gösterebilir. Alternatif listesinde aynı marka seçenekleri öne çıkarılabilir.

Aynı Kategori

Kategori eşleşmesi ürünlerin benzer kullanım alanına sahip olabileceğini gösterir. Ancak geniş kategori seviyeleri yanıltıcı olabilir. En alt taksonomi seviyesindeki eşleşme daha değerlidir. Taksonomi migration dönemlerinde eski ve yeni kategori kimlikleri eşleştirilmelidir. Kategori bilgisi text similarity ile birlikte kullanılabilir.

Aynı Ürün Tipi

Ürün tipi kategoriye göre daha doğrudan ihtiyaç sinyali verebilir. Örneğin “kablosuz kulaklık” ile “hoparlör” aynı üst kategoride bulunmasına rağmen farklı niyetlerdir. Redirect için ürün tipi eşleşmesi güçlü ağırlık alabilir. Recommendation sisteminde de benzer yaklaşım kullanılabilir. Verinin katalog boyunca tutarlı olması gerekir.

Benzer Özellikler

Teknik özellik benzerliği kullanıcı beklentisini anlamada değerlidir. Boyut, kapasite, renk, işlemci, malzeme veya kullanım amacı kategoriye göre değişen attribute'lar olabilir. Önemli özellikler ürün tipine göre ağırlıklandırılmalıdır. Bütün alanlara eşit puan vermek anlamsız sonuç yaratabilir. Feature similarity domain bilgisiyle tasarlanmalıdır.

Benzer Fiyat Segmenti

Fiyat kullanıcı niyeti hakkında yardımcı sinyal verir. Eski 500 TL ürünün yerine 10.000 TL ürün göndermek kullanım amacı aynı olsa bile kötü deneyim olabilir. Fiyat farkı belirli oranın üzerindeyse relevance puanı düşürülebilir. Kampanya fiyatı ve normal fiyat ayrımı dikkate alınmalıdır. Kişiselleştirilmiş fiyatlandırma varsa hesaplama daha dikkatli yapılmalıdır.

Kullanıcı Search Intent'i

Search intent eski ürün adının ötesindeki ihtiyacı anlamaya yardımcı olur. Referrer search query, site içi arama geçmişi veya kategori yolu ek bağlam sunabilir. Kullanıcı marka arıyorsa farklı marka alternatifi düşük puan alabilir. Kullanıcı genel ürün tipi arıyorsa seçenek alanı genişletilebilir. Gizlilik ve consent kuralları kullanıcı davranışı sinyallerinin kullanımında korunmalıdır.

Minimum Relevance Threshold

Otomatik redirect yalnızca belirli güven eşiğinin üzerinde çalışmalıdır. Orta güven düzeyinde 404 üzerinde önerilen hedef gösterilebilir. Düşük güven düzeyinde arama ve kategori recovery tercih edilir. Threshold sabit bir varsayım olarak bırakılmamalıdır. A/B test ve kullanıcı davranışı verileriyle zaman içinde ayarlanmalıdır.

Otomatik Redirect İçin Relevance Score Modeli

Relevance score modeli birden fazla sinyali tek bir karar puanında birleştirebilir. Brand match, category match, attribute similarity, price similarity, text similarity, kullanıcı davranışı ve kurumsal iş kuralları ağırlıklı biçimde değerlendirilebilir. Modelin amacı olabildiğince çok redirect üretmek değil, yanlış redirect oranını düşük tutmaktır. Yüksek confidence otomatik yönlendirme, orta confidence öneri ve düşük confidence genel recovery şeklinde üç katmanlı yaklaşım işe yarar. Kritik ve yüksek trafikli URL'lerde insan kontrolü eklenmesi de faydalıdır.

Brand Match

Brand match ikili veya ağırlıklı puan olarak kullanılabilir. Aynı marka yüksek katkı sağlayabilir. Ancak kullanıcı eski markanın artık üretilmeyen ürününü arıyorsa rakip olmayan alternatif kategoriler yine de kullanıcıya gösterilebilir. Otomatik redirect için marka uyuşmazlığı daha güçlü ceza alabilir. İş kuralı kategoriye göre değişebilir.

Category Match

Taxonomy mesafesi puanlama için kullanılabilir. Aynı leaf category yüksek puan, aynı üst kategori orta puan verebilir. Farklı ana kategorilerde otomatik redirect engellenebilir. Migration sırasında kategori kimlikleri değişiyorsa historical mapping gerekir. Aksi durumda aynı ürün yanlışlıkla farklı kategori gibi değerlendirilebilir.

Attribute Similarity

Attribute similarity ürün tipine özgü alanlara dayanmalıdır. Ayakkabıda beden ve kullanım türü, bilgisayarda işlemci ve RAM daha anlamlı olabilir. Eksik veri durumunda model puanı yanlış artırmamalıdır. Kritik alanlar için minimum eşleşme kuralı konabilir. Similarity kullanıcı testleriyle doğrulanmalıdır.

Price Similarity

Fiyat yakınlığı doğrusal veya logaritmik ölçülebilir. Çok ucuz ve çok pahalı ürünlerin farkı aynı mutlak değerle değerlendirilmemelidir. Para birimi ve kampanya fiyatları normalize edilmelidir. Kullanıcı segmentine göre farklı fiyat hassasiyeti olabilir. Ancak SEO yönlendirmesinde kişisel fiyat yerine genel katalog fiyatı daha güvenli sinyal olabilir.

Text Similarity

Ürün adı ve açıklama benzerliği özellikle legacy kayıtların eşleşmesinde faydalıdır. Token eşleşmesi, typo toleransı veya semantic representation kullanılabilir. Metin benzerliği tek başına yanıltıcı olabileceği için katalog sinyalleriyle birleştirilmelidir. Model isimleri benzer ancak farklı ürünleri ayırabilmelidir. SKU veya product family verisi varsa daha yüksek öncelik almalıdır.

Customer Behavior

Kullanıcıların eski URL'den sonra hangi ürünlere yöneldiği değerli geri bildirim sağlar. Çok sayıda kullanıcı aynı alternatifi seçiyorsa bu hedef relevance modeline sinyal olabilir. Tekil oturum davranışı gizlilik kurallarına uygun işlenmelidir. Anonim agregasyon çoğu analiz için yeterlidir. Davranış verisi yönlendirme kararının zamanla gelişmesine yardımcı olur.

Business Rules

İş kuralları scoring modelinin sınırlarını belirler. Satışa kapalı veya ülkede bulunmayan ürünler hedef olamaz. Belirli kategori geçişleri otomatik redirect dışında tutulabilir. Hukuki kısıtlar ve stok politikaları da kurallara eklenebilir. Böylece yüksek matematiksel benzerlik tek başına yanlış ticari karar oluşturmaz.

Score Yetersizse Redirect Etmemek

İyi sistem redirect üretmemeyi de geçerli karar olarak kabul eder. Confidence düşükken kullanıcıyı yanlış hedefe göndermek yerine 404 recovery sunmak daha güvenlidir. Arama kutusu eski ürün adıyla önceden doldurulabilir. Benzer kategori ve popüler ürünler gösterilebilir. Kullanıcı kontrolü korunur ve yanlış redirect verisi birikmez.

Redirect Registry Nedir?

Redirect registry, yönlendirmeleri rastgele server config satırları olmaktan çıkarıp yönetilebilir veri modeline dönüştürür. Her kayıt source URL, destination URL, redirect type, reason, created date, owner ve review date gibi alanlar içerir. Ürün lifecycle event bilgisi de yönlendirmenin neden oluştuğunu açıklayabilir. Bu yapı zincir, loop ve bozuk hedef kontrollerini otomatikleştirmeyi kolaylaştırır. Büyük kataloglarda redirect yönetiminin sürdürülebilir olması için merkezi registry ciddi avantaj sağlar.

Source URL

Source URL yönlendirmenin başladığı eski adrestir. Normalize edilmiş sürümü ayrıca saklanabilir. Protokol, slash ve büyük küçük harf politikası açık olmalıdır. Aynı source için birden fazla aktif hedef bulunmamalıdır. Conflict kontrolü registry yazımı sırasında yapılmalıdır.

Destination URL

Destination geçerli ve erişilebilir hedef olmalıdır. Hedef ürün daha sonra kaldırılırsa registry otomatik review gerektirebilir. Destination'ın başka redirect'e gitmesi chain oluşturur. Sistem mümkünse doğrudan final URL'yi saklamalıdır. Hedef health check scheduled audit ile kontrol edilebilir.

Redirect Type

301 ve geçici yönlendirmeler açıkça ayrılmalıdır. Migration veya kalıcı URL değişikliğinde 301 kullanılır. Geçici operasyon durumunda uygun 302 veya 307 tercih edilebilir. Redirect type'ın nedeni kayıtla uyumlu olmalıdır. Süresi dolan geçici kayıtlar otomatik review listesine alınmalıdır.

Reason

Reason alanı redirect'in neden oluşturulduğunu açıklar. URL_CHANGED, PRODUCT_REPLACED, CATEGORY_MERGED veya MIGRATION gibi kontrollü değerler kullanılabilir. Serbest metin yerine enum kullanmak analiz kolaylığı sağlar. İnsan notu için ek açıklama alanı tutulabilir. Böylece aylar sonra mapping'in amacı anlaşılır.

Created Date

Oluşturma tarihi redirect yaşını takip etmeyi sağlar. Çok eski mappingler zamanla anlamsız hâle gelebilir. Audit sistemi yaşa göre kontrol sıklığı belirleyebilir. Migration dönemlerindeki kayıtlar toplu olarak filtrelenebilir. Tarih verisi incident araştırmalarında da yardımcı olur.

Owner

Her yönlendirme veya kural ailesinin sahibi bulunmalıdır. Owner birey yerine ekip olabilir. Problem çıktığında kimin review yapacağı açık olur. SEO, commerce ve engineering sorumlulukları karıştırılmaz. Ownership olmadan registry zamanla sahipsiz veri deposuna dönüşebilir.

Expiry / Review Date

Kalıcı 301 için teknik expiry zorunlu olmayabilir ancak review date yine de yararlıdır. Geçici redirectlerde review tarihi daha önemlidir. Tarih geldiğinde sistem hedef durumunu ve relevance değerini yeniden kontrol edebilir. Gereksiz kayıtlar kaldırılabilir. Böylece registry sürekli büyüyen kontrolsüz listeye dönüşmez.

Product Lifecycle Event

Redirect kaydını oluşturan lifecycle event saklanabilir. Örneğin PRODUCT_REPLACED eventi eski SKU ve yeni SKU ilişkisini taşır. Registry'nin neden oluştuğu doğrudan katalog geçmişiyle bağlantılanır. Event ID audit trail için kullanılabilir. Bu yapı otomasyon ve hata ayıklamada güçlü izlenebilirlik sağlar.

Büyük E-Ticaret Sistemlerinde URL Lifecycle Service

Çok büyük kataloglarda URL davranışını farklı uygulamalara dağılmış kurallarla yönetmek zorlaşır. PIM, ERP, CMS, commerce engine, search index, redirect registry, CDN ve frontend aynı ürün durumunun farklı parçalarını bilir. URL lifecycle service bu sistemlerden gelen olayları ortak karara dönüştürebilir. Ürün kaldırıldığında yalnızca veri tabanı kaydı değişmez, sitemap, search index, redirect ve frontend state'i de güncellenir. Böylece URL yaşam döngüsü ürün yaşam döngüsünün resmi bir parçası olur.

PIM

PIM ürünün temel katalog kimliğini ve attribute'larını taşır. Successor ve family ilişkileri burada tutulabilir. Ürün state değişiklikleri event olarak yayınlanabilir. URL resolver bu veriyi relevance kararında kullanır. PIM tek başına HTTP üretmez, ancak karar için güçlü kaynak sağlar.

ERP

ERP stok ve ticari durum hakkında ek bilgi sağlayabilir. Geçici stok yokluğu ile kalıcı ürün sonlandırmasını ayırmak önemlidir. Tedarik veya satış state'i doğrudan URL silme anlamına gelmemelidir. Lifecycle service ERP sinyalini diğer kaynaklarla birleştirir. Böylece stok sıfır olduğu anda yanlış 404 üretilmez.

CMS

CMS kampanya ve editorial landing page yaşam döngüsünü yönetebilir. Kampanya sona erdiğinde URL'nin archive, redirect veya 404 state'ine geçmesi gerekir. CMS eventleri redirect registry ve sitemap servisine iletilebilir. İçerik editörü teknik HTTP ayrıntısını manuel yönetmek zorunda kalmaz. Policy doğru davranışı otomatik üretir.

Commerce Engine

Commerce engine ürünün satışa uygunluğunu ve checkout davranışını belirler. Frontend sadece ürün kaydı bulundu mu sorusuna bakmamalıdır. Saleable, backorder ve region availability gibi durumlar ayrı değerlendirilir. URL state farklı bir katmanda korunur. Bu ayrım headless sistemlerde özellikle önemlidir.

Search Index

Search index ürün keşfinin ana kaynaklarından biri olabilir. Kaldırılan ürünlerin index içinde kalması kullanıcıları 404'e gönderir. Lifecycle event search index cleanup işlemini tetiklemelidir. Yeni successor ürün de doğru zamanda indekslenmelidir. Search ve storefront state'i mümkün olduğunca yakın tutulmalıdır.

Redirect Registry

Registry eski URL ile yeni hedef arasındaki resmi mapping'i tutar. Lifecycle service bu kaydı otomatik oluşturabilir veya review kuyruğuna gönderebilir. Hedef relevance belirli eşiğin altındaysa kayıt oluşturulmaz. Edge ve origin aynı registry verisini kullanabilir. Böylece farklı katmanlarda çelişkili redirect davranışı oluşmaz.

CDN / Edge

CDN yüksek hacimli redirectleri origin'e gitmeden uygulayabilir. Ancak registry güncellemeleri edge cache'e hızlı ulaşmalıdır. Silinen veya değişen yönlendirmeler purge mekanizmasıyla temizlenmelidir. 404 sayfası da kısa süreli cache edilebilir. Bot trafiğinde edge katmanı backend yükünü önemli ölçüde azaltır.

Frontend

Frontend son kullanıcı deneyimini üretir. Resolver sonucuna göre 200 PDP, redirect veya dinamik 404 bileşeni gösterebilir. Recommendation servisinin başarısız olması temel hata sayfasını bozmamalıdır. Arama ve navigation güvenli fallback olarak her zaman hazır olmalıdır. Analytics recovery interaction olaylarını frontend üzerinden ölçebilir.

Event-Driven 404 ve Redirect Mimarisi

Event-driven yaklaşım ürün ve URL değişikliklerini birbirine bağlar. Product Discontinued, Product Replaced, Category Deleted, SKU Merge ve URL Changed gibi olaylar yayınlandığında ilgili sistemler kendi state'lerini günceller. Redirect mapping, search index ve sitemap işlemleri aynı lifecycle event üzerinden tetiklenebilir. Böylece manuel listelerin unutulması azalır. İyi tasarlanmış event modeli özellikle yüksek hacimli kataloglarda tutarlılık sağlar.

Product Discontinued Event

Bu event ürünün kalıcı satış sonunu bildirir. Successor bilgisi varsa payload içinde taşınabilir. Resolver relevance kontrolü yapıp redirect kararı verebilir. Search index ve recommendation state'i güncellenir. Audit sistemi event'in bütün tüketiciler tarafından işlendiğini takip edebilir.

Product Replaced Event

Replacement eventi eski ve yeni SKU ilişkisini açıklar. Bu bilgi yüksek confidence redirect için kullanılabilir. Yeni ürün aktif değilse yönlendirme hemen devreye alınmamalıdır. Event consumer hedef durumunu doğrular. Böylece kullanıcı henüz yayında olmayan sayfaya gönderilmez.

Category Deleted Event

Kategori silindiğinde içindeki ürünlerin yeni taksonomide nereye gittiği bilinmelidir. Tek yeni kategori varsa mapping oluşturulabilir. Birden çok hedef varsa otomatik 301 riskli olabilir. Internal link ve navigation yapısı da event sonrası güncellenmelidir. Sitemap eski kategoriyi çıkarmalıdır.

SKU Merge Event

SKU merge birden fazla eski kaydı tek üründe birleştirir. Eski URL'ler final ürüne yönlendirilebilir. Mapping direct olmalı ve zincir oluşturmamalıdır. Analytics eski SKU kaynaklarını gerektiğinde ayrı izleyebilir. Merge event'i audit trail'de saklanmalıdır.

URL Changed Event

Slug veya route değişikliği URL_CHANGED eventi üretebilir. Eski ve yeni URL event içinde taşınır. Registry doğrudan 301 kaydı oluşturabilir. Sitemap ve internal link generator yeni adresi kullanmaya başlar. Bu otomasyon manuel migration hatalarını azaltır.

Redirect Mapping Oluşturmak

Her event otomatik redirect üretmemelidir. Önce policy ve relevance kontrolü yapılır. Güven yüksekse mapping oluşturulur. Orta güven durumunda insan review kuyruğu kullanılabilir. Düşük güvenli kayıtlar dinamik 404 recovery'ye bırakılır.

Search Index'i Güncellemek

Kaldırılmış ürün search sonuçlarında kalmamalıdır. Event consumer eski document'i index'ten çıkarabilir. Replacement durumunda yeni ürün doğru attribute'larla eklenir. Senkronizasyon gecikmesi kullanıcıyı 404'e gönderebilir. Search index freshness dashboard üzerinden izlenmelidir.

Sitemap'i Güncellemek

Sitemap yalnızca geçerli ve indekslenebilir canonical URL'leri içermelidir. Kaldırılan veya redirect edilen URL event sonrası çıkarılmalıdır. Yeni URL gerekliyse sitemap'e eklenir. Büyük kataloglarda incremental sitemap generation kullanılabilir. Event işleme başarısız olursa reconciliation job eksikleri düzeltmelidir.

Ürün Silme İşlemi Bir Database Delete Olmamalıdır

Bir ürün satışı sona erdiğinde doğrudan hard delete yapmak geçmiş URL bilgilerini ve karar bağlamını yok eder. Bunun yerine product lifecycle event, SEO state, redirect state, search state, recommendation state, analytics state ve audit trail birlikte yönetilmelidir. Bu yaklaşım geliştiricinin daha fazla alan saklaması anlamına gelir, ancak operasyonel belirsizliği büyük ölçüde azaltır. Aylar sonra eski SKU'ya trafik geldiğinde sistem onun ne olduğunu hâlâ anlayabilir. Akıllı 404 ve redirect altyapısının temelinde geçmişi unutmayan veri modeli bulunur.

Product Lifecycle Event

Silme işlemi bir event olarak kaydedilmelidir. Event tarih, neden ve eski ürün kimliğini taşıyabilir. Successor varsa ilişki de eklenir. Diğer servisler bu event üzerinden kendi state'lerini günceller. Hard delete yalnızca güvenli arşiv politikası sonrasında değerlendirilebilir.

SEO State

SEO state ürünün index ve URL davranışını tanımlar. INDEXABLE, REDIRECTED, NOT_FOUND veya ARCHIVED gibi değerler kullanılabilir. Ticari state ile bire bir aynı olmak zorunda değildir. Böylece stokta olmayan ürün 200 ve indexable kalabilir. Policy engine ticari değişikliği SEO state'e dönüştürür.

Redirect State

Redirect state hedef ve gerekçe bilgisini taşır. NONE, PENDING_REVIEW veya ACTIVE gibi değerler kullanılabilir. Hedef kaldırılırsa state tekrar review durumuna geçebilir. Bu veri registry ile senkron tutulmalıdır. Redirect kararının yaşam döngüsü izlenebilir hâle gelir.

Search State

Search state ürünün site içi aramada görünmesini kontrol eder. Kaldırılmış ürün index'ten çıkarılabilir. Out of stock ürün ise arama politikasına göre görünmeye devam edebilir. Search state ile URL state birbirinden bağımsızdır. Bu ayrım zero-result ve broken click problemlerini azaltır.

Recommendation State

Recommendation motoru geçerli olmayan ürünleri öneri adayı olarak kullanmamalıdır. Stok, region ve lifecycle filtreleri uygulanmalıdır. Kaldırılmış ürün yalnızca historical similarity hesaplarında veri noktası olarak tutulabilir. Kullanıcıya gösterilecek sonuçlar güncel katalogdan seçilmelidir. Cache invalidation bu state değişikliklerinde önemlidir.

Analytics State

Eski ürünün geçmiş satış ve trafik verisi silinmemelidir. Bu veri redirect priority ve recovery analizi için değerlidir. Ürün aktif katalogdan çıkarılsa bile historical analytics kimliği korunabilir. Recovered revenue eski kaynak URL ile ilişkilendirilebilir. Böylece kaldırma kararının ticari etkisi ölçülebilir.

Audit Trail

Audit trail kim, ne zaman ve neden ürün state'ini değiştirdi sorularını cevaplar. Otomatik eventlerin de iz bırakması gerekir. Yanlış toplu silme durumunda kök neden araştırması hızlanır. Redirect ve sitemap değişiklikleri aynı event'e bağlanabilir. Büyük operasyonlarda bu izlenebilirlik ciddi zaman kazandırır.

Redirect Chain Nedir?

Redirect chain, bir URL'nin başka bir URL'ye, onun da üçüncü bir URL'ye yönlenmesiyle oluşur. E-ticaret ürünleri yıllar içinde birkaç kez model veya URL değiştirdiğinde zincirler doğal olarak büyüyebilir. Kullanıcı ve bot her adımda ek network isteği yapmak zorunda kalır. En iyi yaklaşım eski kaynakların doğrudan güncel final hedefe yönlendirilmesidir. Registry audit zincirleri düzenli bulup mappingleri düzleştirmelidir.

A → B → C

A adresi B'ye, B de C'ye yönleniyorsa iki hop bulunur. A'nın doğrudan C'ye güncellenmesi daha temizdir. B kendi kaynak trafiği için C'ye yönlenmeye devam edebilir. Registry final destination çözümlemesi yapabilir. Test sistemi maksimum redirect hop sayısını kontrol etmelidir.

Eski Ürünün Yeni Ürünle Tekrar Değişmesi

Ürün A daha önce B ile değiştirilmiş, sonra B de C ile değiştirilmiş olabilir. Sistem A kaydını olduğu gibi bırakırsa A → B → C zinciri oluşur. Lifecycle event geldiğinde A'nın final hedefi C olarak yeniden yazılabilir. Relevance tekrar doğrulanmalıdır. Çok eski ürün ile son hedef arasındaki anlam ilişkisi zayıflamışsa redirect yerine recovery tercih edilebilir.

Redirect Zincirlerinin Zamanla Büyümesi

Zincirler genellikle tek seferde değil yıllar içinde oluşur. Her migration yeni bir katman ekleyebilir. Registry olmadan bu bağlantıları görmek zorlaşır. Scheduled crawler ve graph analizi uzun zincirleri bulabilir. Operasyon ekibi belirli hop sayısının üzerini otomatik alert olarak tanımlayabilir.

Zinciri Doğrudan Son Hedefe Güncellemek

Chain flattening işlemi kaynak mapping'i final hedefe taşır. Önce hedefin 200 ve doğru ürün olduğunun doğrulanması gerekir. Mapping güncellendikten sonra regression test çalıştırılmalıdır. Analytics source URL bilgisini koruyabilir. Kullanıcı daha az network adımıyla hedefe ulaşır.

Redirect Loop Tespiti

Loop A'nın B'ye, B'nin tekrar A'ya yönlenmesi gibi sonsuz döngüdür. Kullanıcı sayfaya ulaşamaz. Registry kaydı oluşturulurken graph cycle kontrolü yapılabilir. Production monitoring fazla redirect sayısını incident olarak işaretleyebilir. Loop tespiti CI/CD testlerinin de parçası olmalıdır.

Redirect Mapping Nasıl Otomatik Temizlenir?

Redirect registry bir kez kurulduktan sonra kendi hâline bırakılmamalıdır. Scheduled audit kaynak ve hedef URL'leri kontrol ederek bozuk destination, chain, loop ve artık geçersiz ürün state'lerini bulabilir. Bazı durumlar otomatik düzeltilebilir, bazıları ise insan review gerektirir. Özellikle yüksek trafik alan redirectler manuel doğrulama kuyruğuna alınabilir. Bu bakım süreci yönlendirme katmanının yıllar içinde kontrolsüz büyümesini engeller.

Scheduled Audit

Audit günlük, haftalık veya trafik önemine göre farklı sıklıkta çalışabilir. Registry içindeki hedefler batch olarak kontrol edilir. Status code, final URL ve lifecycle state kaydedilir. Değişiklikler dashboard üzerinde gösterilir. Kritik bozulmalar anında alert üretebilir.

Broken Destination

Redirect hedefi daha sonra 404 olursa eski kaynak da kullanıcıyı çıkmaza taşır. Audit böyle destination'ları tespit etmelidir. Yeni successor varsa mapping güncellenebilir. Alternatif yoksa kaynak 404 recovery state'ine alınabilir. Bozuk hedeflerin zincirleme etkisi hızlı çözülmelidir.

Chain Detection

Registry graph olarak analiz edildiğinde çok adımlı yönlendirmeler kolayca bulunur. Kaynağın final destination'ı hesaplanır. Relevance hâlâ yeterliyse source doğrudan final hedefe güncellenir. Bu işlem otomatik olabilir ancak kritik URL'lerde review uygulanabilir. Güncelleme sonrası test zorunlu tutulmalıdır.

Loop Detection

Cycle detection algoritmaları registry kaydındaki döngüleri bulabilir. Yeni kayıt eklenmeden önce kontrol yapmak en güvenli yaklaşımdır. Production'da ortaya çıkan looplar yüksek öncelikli incident sayılmalıdır. Kullanıcı hiçbir içeriğe ulaşamaz ve bot kaynakları boşa harcar. Alert payload ilgili mapping zincirini açıkça göstermelidir.

Destination Product State

Hedef URL 200 dönse bile ürün artık satılmıyor olabilir. Bu nedenle yalnızca HTTP health check yeterli değildir. Lifecycle state ayrıca kontrol edilmelidir. REPLACED veya REMOVED hedefler registry review gerektirir. Böylece teknik olarak çalışan fakat ticari olarak yanlış redirectler tespit edilir.

Otomatik Düzeltme veya Alert

Güvenli durumlar otomatik düzeltilebilir. Örneğin A → B → C zincirinde C aktif ve relation güçlü ise A doğrudan C'ye alınabilir. Belirsiz durumlar alert ile owner ekibe gönderilmelidir. Otomasyonun sınırları policy ile açıkça tanımlanmalıdır. Her otomatik değişiklik audit trail'e yazılmalıdır.

Kategori Sayfalarında 404 Stratejisi

Kategori URL'leri ürün URL'lerinden farklı yaşam döngüsüne sahiptir. Bir kategori geçici olarak ürünsüz kalabilir, kalıcı kaldırılabilir, başka kategoriyle birleşebilir veya yeni taksonomide farklı bölümlere ayrılabilir. Bu yüzden “ürün yoksa kategori 404 olsun” kuralı çoğu sistem için fazla basittir. Kategori kullanıcıya hâlâ anlamlı içerik, alt kategori veya yakında gelecek ürünler sunuyorsa 200 kalabilir. Kalıcı kaldırmada ise gerçek yeni karşılık varsa 301, yoksa 404 veya noindex stratejileri değerlendirilmelidir.

Boş Kategori

Boş kategori her zaman bulunamayan kaynak değildir. Kategori tanımı ve kullanıcı değeri hâlâ mevcut olabilir. Kısa süre içinde ürün eklenecekse 200 korunabilir. Ancak sürekli boş ve indekslenebilir kategoriler kalite sorunu yaratabilir. Kategori lifecycle state'i ürün sayısından ayrı tutulmalıdır.

Geçici Olarak Ürünsüz Kategori

Sezon veya stok nedeniyle geçici boş kalan kategori canlı kalabilir. Kullanıcıya ürünlerin geçici olarak bulunmadığı açıklanabilir. Benzer kategoriler gösterilebilir. Search ve sitemap politikası kategori değerine göre belirlenir. Kategori sürekli trafik alıyorsa URL'yi silmek gereksiz kayıp yaratabilir.

Kalıcı Olarak Kaldırılmış Kategori

Kategori artık taksonomide yer almıyorsa yeni karşılık aranmalıdır. Bire bir yeni kategori varsa 301 uygundur. İçerik birkaç kategoriye bölündüyse tek redirect yanlış olabilir. Bu durumda 404 veya seçim deneyimi düşünülebilir. Internal navigation eski URL'yi tamamen bırakmalıdır.

Birleştirilmiş Kategori

İki eski kategori tek yeni kategoriye birleştiğinde 301 mantıklı olabilir. Yeni hedef eski ürün kapsamını yeterince karşılamalıdır. Redirect registry merge event'ini kaydetmelidir. Sitemap yeni kategoriyi göstermelidir. Eski internal linkler doğrudan yeni URL'ye güncellenmelidir.

Yeni Taxonomy

Taksonomi migration projeleri yüz binlerce kategori ve ürün URL'sini etkileyebilir. Eski ve yeni kategori ağaçları önceden eşleştirilmelidir. Ürün overlap oranı relevance için kullanılabilir. Otomatik mapping sonrası düşük güvenli kategoriler insan review'ına gönderilebilir. Migration sonrası crawler ile 404 ve redirect chain kontrolü yapılmalıdır.

301 / Noindex / 404 Kararı

301 gerçek yeni hedef bulunduğunda, 404 kaynak sona erdiğinde, noindex ise geçerli fakat arama sonuçlarında bulunması istenmeyen sayfalarda düşünülmelidir. Bu araçlar birbirinin yerine kullanılmamalıdır. Boş sayfaya sırf 404 olmasın diye 200 vermek çözüm değildir. Aynı şekilde canlı kategoriye gereksiz noindex eklemek organik fırsatı azaltabilir. Karar kategori state ve kullanıcı değerine dayanmalıdır.

Faceted Navigation ve Filtre URL'leri

Faceted navigation e-ticaret sitelerinde milyonlarca URL kombinasyonu üretebilir. Filtrelerin bazıları sıfır ürün getirir, bazıları aynı içeriğin farklı sıralamalarını oluşturur ve bazıları gerçek arama talebi taşıyan landing page niteliği kazanır. Bu alanlarda 404, noindex, canonical ve crawl yönetimi birlikte ele alınmalıdır. Her boş filtre kombinasyonunu indekslenebilir 200 sayfası olarak bırakmak tarama alanını büyütebilir. Gerçekten geçersiz kombinasyonların ise gerektiğinde 404 döndürmesi mümkündür.

Boş Filtre Kombinasyonları

Kullanıcı filtre uygulayıp sıfır sonuç elde ettiğinde bu her zaman 404 değildir. Geçerli filtre işlemi sonucu 200 ve “sonuç yok” deneyimi sunulabilir. Ancak botların sonsuz boş URL kombinasyonu taraması engellenmelidir. İndeksleme ve crawl politikası parametre sistemine göre tanımlanmalıdır. Geçersiz parametre değerleri ise farklı ele alınabilir.

Sonsuz URL Üretimi

Sıralama, renk, beden ve fiyat parametreleri kombinasyon patlaması yaratabilir. Arama motoru her kombinasyonu taramaya çalışırsa crawl bütçesi dağılabilir. Canonical, noindex ve URL generation kuralları dikkatle tasarlanmalıdır. Internal linkler yalnızca değerli facet URL'lerini keşfedilebilir yapmalıdır. Server log analizi botların hangi parametre desenlerinde zaman harcadığını gösterir.

Canonical

Canonical kopya veya çok benzer filtre sayfalarını ana kategoriye işaret etmek için kullanılabilir. Ancak bütün facet URL'lerini otomatik olarak aynı canonical'a bağlamak da yanlış olabilir. Organik talep taşıyan belirli filtre landing page'leri bağımsız değerlendirilebilir. Canonical yalnızca tercih sinyalidir, crawl kontrol aracının tamamı değildir. URL stratejisi filtre bazında sınıflandırılmalıdır.

Noindex

Noindex geçerli fakat indekslenmesi istenmeyen filtre sonuçlarında kullanılabilir. Sayfa kullanıcı için çalışmaya devam eder. Yine de internal link üretimi ve crawl yükü ayrıca düşünülmelidir. Noindex yüz milyonlarca URL üretimini tek başına çözmez. Filtre URL üretim sınırları da gerekir.

Crawl Yönetimi

Crawl yönetimi parametre üretimi, internal linking ve sitemap kontrolüyle birlikte yapılmalıdır. Botların anlamsız kombinasyonlara sınırsız ulaşması engellenebilir. Log analizi sorunlu patternleri ortaya çıkarır. Facet policy ürün kategorisine göre farklılaşabilir. Teknik SEO ekibi davranışı düzenli olarak yeniden değerlendirmelidir.

Gerçek 404 Gereken Senaryolar

Geçersiz route, tanınmayan filtre adı veya sistemde hiç bulunmayan kategori değeri gerçek 404 gerektirebilir. URL'nin yalnızca sıfır ürün döndürmesi ise tek başına yeterli değildir. Kullanıcı geçerli bir filtre kombinasyonu yaptıysa sonuçsuz sayfa 200 olabilir. Sistem valid request ile invalid resource ayrımını bilmelidir. Bu ayrım router ve filter schema seviyesinde modellenebilir.

Ürün Varyantlarında 404 Stratejisi

Varyant URL'leri ürün lifecycle kararını daha ayrıntılı hâle getirir. Renk veya beden gibi tek varyant kaldırıldığında parent ürün hâlâ aktif olabilir. Varyant ayrı URL taşıyorsa kaldırılan seçeneğin parent PDP'ye veya uygun varyanta nasıl bağlanacağı belirlenmelidir. Kullanıcı beklediği renk veya bedeni kaybetmemelidir. Canonical ve redirect kararları varyantın gerçekten bağımsız landing page olup olmadığına göre uygulanmalıdır.

Renk Varyantı

Belirli renk kalıcı olarak kaldırılmış olabilir. Parent ürün diğer renklerle aktifse kullanıcı parent PDP'ye yönlendirilebilir veya 200 PDP içinde renk kullanılamıyor mesajı gösterilebilir. Otomatik redirect hedefte farklı renk seçildiğini açıkça göstermelidir. Kullanıcı istemediği varyanta sessizce taşınmamalıdır. Analytics varyant recovery performansını izleyebilir.

Beden Varyantı

Beden stok yokluğu genellikle geçici inventory state'tir. Ürün PDP'sini kaldırmak gerekmez. Kullanıcı mevcut bedenleri görebilir ve stok bildirimi alabilir. URL sadece beden parametresi içeriyorsa geçersiz beden için parent ürüne güvenli fallback yapılabilir. Parametre state'i canonical stratejisiyle uyumlu olmalıdır.

Parent Product

Parent product tüm varyantları bir arada temsil edebilir. Bu durumda ana URL'nin yaşam döngüsü varyantlardan ayrı tutulmalıdır. Tek varyant kayboldu diye parent 404 olmamalıdır. Tüm satılabilir varyantlar kaldırıldığında yeni state değerlendirilir. Parent ve variant modellerinin HTTP kuralları açık tanımlanmalıdır.

Variant URL

Her varyantın bağımsız URL'si varsa SEO değeri ayrı oluşabilir. Canonical parent'a işaret edebilir veya varyant gerçekten bağımsız içerik taşıyorsa self canonical kullanılabilir. Varyant kaldırıldığında eski URL için parent veya successor eşleşmesi kontrol edilir. Her durumda kullanıcı beklediği seçenek hakkında bilgilendirilmelidir. Yanlış variant redirectleri conversion kaybı yaratabilir.

Kaldırılan Tek Varyant

Tek varyant kaybolduğunda ürün ailesi yaşamaya devam eder. Parent PDP genellikle en güvenli recovery noktasıdır. Ancak redirect yalnızca kullanıcıya kaldırılan varyant bilgisini kaybettirmeyecek şekilde tasarlanmalıdır. Frontend mesajla “bu seçenek artık mevcut değil” diyebilir. Benzer renk veya bedenler önerilebilir.

Kaldırılan Tüm Ürün

Tüm varyantlar kalıcı kaldırılmışsa parent ürün lifecycle kararı devreye girer. Successor varsa 301 değerlendirilebilir. Alternatif yoksa 404 veya 410 kullanılabilir. Eski varyant URL'leri de aynı final policy'ye göre normalize edilmelidir. Zincir oluşmaması için hepsi final hedefe bağlanmalıdır.

Canonical ve Redirect İlişkisi

Canonical kullanıcıyı yeni URL'ye taşımaz. Redirect gerçek URL taşınmasında kullanılır. Varyant duplicate içeriği canonical ile yönetilebilirken kaldırılmış varyant için redirect veya 404 gerekir. İki mekanizma birbirine karıştırılmamalıdır. Test sistemi ikisinin tutarlılığını kontrol etmelidir.

Kampanya ve Landing Page 404 Stratejisi

Kampanya sayfalarında sona erme tarihi daha içerik oluşturulurken planlanmalıdır. Kampanya bittiğinde URL'nin geleceği belirsiz bırakılırsa ekipler son gün ana sayfaya redirect gibi kolay çözümlere yönelebilir. Sezonluk kampanya tekrar kullanılacaksa evergreen URL korunabilir. Kalıcı devam sayfası varsa 301, hiçbir karşılık yoksa 404 veya 410 uygulanabilir. Arşiv seçeneği, kampanyanın bilgi değerine ve kullanıcı talebine göre düşünülmelidir.

Kampanya Bittiğinde Ne Olmalı?

Kampanya sonu state'i önceden tanımlanmalıdır. İndirim bitmişse aktif fiyat mesajları kaldırılmalıdır. Sayfa evergreen içeriğe dönüşebilir veya archive state'e geçebilir. Yeni karşılık varsa 301 kullanılabilir. Geçmiş kampanya URL'sinin yıllarca yanlış teklif göstermesi önlenmelidir.

Sezonluk Kampanya Tekrar Gelecek mi?

Black Friday veya dönemsel kampanyalar her yıl tekrar edebilir. Bu durumda kalıcı landing URL kullanmak birçok redirect ihtiyacını ortadan kaldırır. Kampanya dışında sayfa yaklaşan dönem veya genel içerik sunabilir. Tarihler ve teklifler güncel tutulmalıdır. Her yıl yeni tarihli URL oluşturmak yalnızca gerekli içerik farkı varsa tercih edilmelidir.

Evergreen Landing Page

Evergreen sayfa zaman bağımsız konu veya kampanya temasını taşır. Sezon değişse bile URL sabit kalır. İçerik dönemsel olarak güncellenebilir. Böylece backlink ve organik sinyaller tek adreste birikir. Campaign lifecycle daha kolay yönetilir.

Eski Kampanyayı Arşivlemek

Geçmiş kampanya basın, haber veya kullanıcı bilgisi açısından değer taşıyabilir. Arşiv sayfası 200 ile yaşayabilir. Kampanyanın sona erdiği açıkça belirtilmelidir. Eski CTA ve fiyatlar aktif görünmemelidir. Yeni kampanyaya isteğe bağlı bağlantı verilebilir.

Yeni Kampanyaya Redirect

Yeni kampanya eski kampanyanın gerçek devamıysa 301 düşünülebilir. Tema ve kullanıcı niyeti güçlü biçimde eşleşmelidir. Her eski promosyonu en yeni kampanyaya otomatik göndermek doğru değildir. Mapping tarih ve kampanya türüne göre doğrulanmalıdır. Redirect süresi campaign policy içinde belirlenebilir.

404 / 410

Hiçbir yeni karşılık bulunmayan kampanya kapatılabilir. 404 veya 410 sayfası kullanıcıya aktif kampanyalar ve ana kategoriler sunabilir. Eski URL sitemap'ten çıkarılmalıdır. Internal linklerin güncellenmesi gerekir. Böylece ölü kampanya sistem içinde dolaşmaya devam etmez.

Site İçi Arama Sonuçlarında 404

Search index ile ürün kataloğu senkron değilse kullanıcı arama sonucundan kaldırılmış PDP'ye tıklayabilir. Bu durum gerçek kullanıcı kaynaklı 404 oranını hızla yükseltir. 404 düzeltmek kadar search index lifecycle'ını düzeltmek de gerekir. Zero-result search ve gerçek kayıp ürün sayfası birbirinden ayrılmalıdır. Site içi arama sonuçları kullanıcıyı ölü URL'lere göndermemelidir.

Eski Ürünlerin Search Index'te Kalması

Ürün kaldırıldıktan sonra search index update gecikebilir. Kullanıcı hâlâ eski kartı görür. Tıklamada 404 oluşur. Lifecycle event index removal işlemini tetiklemelidir. Index freshness KPI olarak izlenebilir.

Search Index Sync Problemi

Senkronizasyon job'ı başarısız olduğunda katalog ve arama ayrışır. Hata yalnızca search ekibinin problemi değildir çünkü conversion ve 404 metriklerini etkiler. Reconciliation job aktif katalogla index'i düzenli karşılaştırabilir. Büyük fark oluştuğunda alert üretilebilir. Incident dashboard deployment ve import zamanlarını birlikte göstermelidir.

Zero-Result Search

Zero-result search geçerli kullanıcı sorgusuna sıfır sonuç dönmesidir. Bu normalde HTTP 404 gerektirmez. Kullanıcıya typo correction, kategori veya popüler ürün seçenekleri sunulabilir. Query analytics katalog boşluklarını anlamak için değerlidir. Sık sıfır sonuç alan aramalar merchandising ekibine sinyal olabilir.

Empty Search Page ile Soft 404 Farkı

Geçerli search route içinde sıfır sonuç gösterilmesi soft 404 değildir. Sorun bu sayfanın arama motoruna değerli landing page gibi sunulmasıyla ortaya çıkabilir. Internal search sayfaları çoğu projede indeks dışında tutulur. Gerçek ürün URL'si 200 dönüp boş içerik gösteriyorsa durum farklıdır. Route type karar için önemlidir.

Search Index Lifecycle

Search index lifecycle ürün state değişikliklerini takip etmelidir. ACTIVE eklenir, OUT_OF_STOCK policy'ye göre korunur, REMOVED çıkarılır. Replacement durumunda eski ve yeni ürün geçişi kontrollü yapılır. Index değişiklikleri event log ile izlenebilir. Search click 404 oranı kalite metriği olarak kullanılabilir.

404 Sayfasının Temel UX Bileşenleri

İyi custom 404 sayfası kullanıcıya ne olduğunu açıkça anlatır ve bir sonraki adımı bulmasını kolaylaştırır. Header, navigation, site içi arama, ilgili kategoriler, alternatif ürünler, ana sayfa ve destek seçenekleri marka deneyiminin devam etmesini sağlar. Fakat bütün bileşenleri aynı anda öne çıkarmak seçenek yükü yaratabilir. Primary CTA kullanıcının bağlamına göre belirlenmelidir. Mobil tasarımda özellikle ilk ekran içinde arama veya en güçlü recovery aksiyonu görünür olmalıdır.

Açık ve İnsan Odaklı Hata Mesajı

Mesaj kısa ve anlaşılır olmalıdır. Kullanıcıyı yanlış URL yazdığı için suçlamamak gerekir. “Aradığınız sayfa artık burada olmayabilir” gibi ifade daha nötrdür. Teknik detaylar gerekiyorsa destek bağlantısında verilebilir. Ana metin doğrudan recovery seçeneklerine geçmelidir.

Header ve Navigation

404 sayfasında ana navigasyonu tamamen kaldırmak kullanıcıyı sıkıştırır. Mevcut header korunabilir. Kategorilere geçiş kolay olmalıdır. Mobil menü de normal siteyle aynı davranmalıdır. Kullanıcı hata sayfasında olduğunu hissetse bile siteden kopmamalıdır.

Site İçi Arama

Arama kutusu özellikle ürün ağırlıklı sitelerde güçlü recovery aracıdır. Eski URL'den ürün adı çıkarılabiliyorsa sorgu önceden doldurulabilir. Kullanıcı isterse metni değiştirebilir. Autocomplete güncel katalogdan sonuç getirmelidir. Search interaction recovery event olarak ölçülebilir.

İlgili Kategoriler

URL'den kategori bağlamı çıkarılıyorsa ilgili kategori seçenekleri gösterilebilir. Kategori gerçekten aktif olmalıdır. Eski taxonomi path'i yeni kategori map'iyle çözümlenebilir. En fazla birkaç güçlü seçenek sunmak yeterlidir. Genel kategori listesi ikinci seviyede tutulabilir.

Alternatif Ürünler

Alternatif ürünler kullanıcının kayıp ürüne yakın olmalıdır. Stok, fiyat ve bölge uygunluğu kontrol edilmelidir. Recommendation motoru başarısız olursa sayfa bozulmamalıdır. Cached popular products güvenli fallback olabilir. Öneri tıklaması ayrı analytics eventi olarak izlenmelidir.

Ana Sayfa

Ana sayfa erişimi her zaman bulunabilir olmalıdır. Ancak tek recovery seçeneği hâline getirilmemelidir. Kullanıcı ana sayfaya dönmek isteyebilir. Logo normal home link davranışını sürdürebilir. Primary CTA daha bağlamsal seçeneklere ayrılabilir.

Yardım / Destek

Özellikle ödeme, sipariş veya hesap akışından gelen 404'lerde destek erişimi önemlidir. Kullanıcı satın alma sürecinde kritik noktada olabilir. Destek linki bağlama göre görünür hâle getirilebilir. Teknik bilgi sızdırmadan problem raporu oluşturulabilir. Sipariş bilgileri URL içinde açıkça taşınmamalıdır.

Hata Bildirme

Kullanıcı broken link bildirebiliyorsa gerçek sorunlar daha hızlı keşfedilebilir. Form mümkün olduğunca kısa olmalıdır. Mevcut URL otomatik eklenebilir. Kullanıcıdan teknik detay istenmemelidir. Bildirim internal incident veya ticket sistemine bağlanabilir.

“Üzgünüz, Sayfa Bulunamadı” Yeterli midir?

Tek başına hayır. Bu cümle yalnızca problemi söyler, çözüm önermez. Kullanıcı ne olduğunu, neden orada olabileceğini ve hangi adımlarla devam edebileceğini anlamalıdır. Ürün arayan kişi için site içi arama ve benzer ürünler, kategori arayan kişi için yeni kategori yolu daha kullanışlı olabilir. Dinamik recovery'nin amacı herkese aynı hata ekranını göstermek yerine eldeki bağlamı faydaya dönüştürmektir.

Kullanıcının Ne Olduğunu Anlaması

Hata metni sayfanın artık mevcut olmadığını veya URL'nin bulunamadığını açıkça söylemelidir. Teknik kod tek başına yeterli değildir. Kullanıcı yanlış bir işlem yaptığını düşünmemelidir. Mesaj kısa tutulabilir. Ardından doğrudan recovery seçenekleri gösterilmelidir.

Bir Sonraki Adımı Bilmesi

Kullanıcıya arama, kategori veya benzer ürün gibi somut yollar verilmelidir. Birinci seçenek en olası ihtiyaca göre öne çıkarılabilir. Çok sayıda eşit CTA karar yükünü artırır. Primary ve secondary aksiyonlar görsel olarak ayrılmalıdır. Mobil ekranda ilk aksiyon kolay erişilebilir olmalıdır.

Neden Orada Olduğunu Açıklamak

Detaylı teknik açıklama gerekmese de kısa bağlam faydalıdır. “Bu ürün artık satışta olmayabilir” gibi mesaj ürün URL'lerinde kullanılabilir. Kampanya sayfasında kampanyanın sona erdiği belirtilir. Generic URL'de genel 404 mesajı yeterlidir. Route type'a göre copy değiştirmek dinamik 404'ü daha anlaşılır yapar.

Kullanıcının Satın Alma Niyetini Korumak

Recovery bileşenleri satın alma yolculuğunu mümkün olduğunca kısa tutmalıdır. Doğrudan halef ürün varsa ilk sırada gösterilebilir. Ardından benzer ürünler ve kategori seçenekleri gelir. Search her zaman güvenli fallback olarak bulunabilir. Recovered product view ve add-to-cart metrikleri bu stratejinin başarısını gösterir.

Dinamik 404 Sayfası Nedir?

Dinamik 404 sayfası herkese aynı sabit içeriği göstermez. Requested URL, referrer, eski SKU, kategori path'i ve oturum bağlamı gibi güvenli sinyalleri kullanarak daha ilgili recovery seçenekleri oluşturur. Örneğin kaldırılmış bir telefon modeline gelen kullanıcıya doğrudan successor ve aynı ürün ailesindeki modeller gösterilebilir. Rastgele URL'ye gelen bot için ise pahalı recommendation çağrıları yapılmadan hafif static 404 döndürülebilir. Bu ayrım hem UX kalitesini hem sistem maliyetini iyileştirir.

Herkese Aynı İçeriği Göstermemek

Ürün URL'si, kategori URL'si ve rastgele path aynı kullanıcı niyetini taşımaz. Route classification ilk adım olabilir. Ürün route'unda eski SKU lookup yapılırken generic path'te yalnızca arama gösterilebilir. Referrer da bağlamı güçlendirebilir. Böylece gereksiz servis çağrıları azaltılır.

İstek URL'sini Analiz Etmek

Slug ve route segmentleri eski ürün hakkında bilgi içerebilir. URL parser bu alanları normalize edebilir. SKU pattern bulunursa archive lookup yapılabilir. Kategori segmenti yeni taxonomy ile eşleştirilebilir. Analiz güvenli ve hızlı olmalıdır.

Referrer Analizi

Referrer kullanıcının nereden geldiğini gösterebilir. Internal referrer broken link kaynağını bulmada değerlidir. Search engine referrer organik trafik önemini işaret edebilir. Dış site referral bağlantısı backlink recovery fırsatı yaratabilir. Referrer bulunmadığında sistem yine temel recovery sunmalıdır.

Eski SKU Bilgisi

Legacy SKU en güçlü tanımlayıcılardan biridir. Ürün arşivinde successor veya family ilişkisi bulunabilir. URL slug değişse bile SKU aynı kalabilir. Resolver bu bilgiyi redirect veya recommendation için kullanabilir. SKU bilgisi kullanıcıya gereksiz teknik detay olarak gösterilmek zorunda değildir.

Kullanıcı Bağlamı

Önceki sayfa, sepet kategorileri veya son arama güvenli biçimde kullanılabilir. Kullanıcı hesabı varsa tercihler daha ilgili öneriler sağlayabilir. Ancak kişiselleştirme consent ve gizlilik kurallarına bağlıdır. 404 sayfası gereksiz veri toplama noktası olmamalıdır. Anonymous kullanıcı için de güçlü generic recovery bulunmalıdır.

İlgili Ürün Önerileri

Öneriler eski ürün bağlamından üretilmelidir. Successor en yüksek önceliğe sahip olabilir. Ardından aynı aile, benzer ürün ve kategori seçenekleri gelir. Stok filtreleme son aşamada mutlaka uygulanmalıdır. Recommendation bulunamazsa arama ve navigation fallback olarak çalışmalıdır.

404 Sayfasından Kullanıcı Niyeti Nasıl Çıkarılır?

Kullanıcı niyetini anlamak için URL slug, SKU, kategori yolu, query parameter, referrer, previous page, site search query ve session behavior gibi sinyaller bir araya getirilebilir. Bu verilerin tamamının bulunması gerekmez. Resolver eldeki sinyal miktarına göre confidence score üretebilir. Yüksek confidence redirect, orta confidence suggested destination ve düşük confidence generic recovery modeli iyi bir başlangıçtır. Kullanıcı bağlamının işlenmesinde gizlilik ve veri minimizasyonu korunmalıdır.

URL Slug

Slug ürün adı ve özellikleri içerebilir. Normalize edilip eski katalog dictionary ile karşılaştırılabilir. Typo toleransı eklenebilir. Çok genel sluglar düşük confidence vermelidir. Exact eski kayıt bulunursa daha güçlü karar üretilebilir.

SKU

SKU doğrudan ürün kimliği sağlar. Legacy registry içinde successor araması yapılabilir. Fuzzy SKU eşleşmesi dikkatle kullanılmalıdır. Bir karakter farkı bambaşka ürünü gösterebilir. Exact match her zaman daha yüksek ağırlık almalıdır.

Category Path

Eski kategori path'i ürünün bağlamını daraltır. Taxonomy mapping ile yeni kategori bulunabilir. Ürün bulunamazsa kategori recovery seçeneği oluşturulabilir. Path birkaç kez migration geçirmişse historical mapping zinciri düzleştirilmelidir. Çok genel üst kategoriler düşük relevance sayılmalıdır.

Query Parameter

Varyant, kampanya veya eski tracking parametreleri ek sinyal taşıyabilir. Güvenli ve bilinen parametreler parse edilmelidir. Rastgele query string recommendation sistemini etkilememelidir. Tracking parametreleri URL matching öncesinde normalize edilebilir. Security açısından parametreler doğrudan HTML'e yazılmamalıdır.

Referrer

Referrer internal ise source page broken link olarak kaydedilebilir. Search engine referrer organik recovery bağlamı verir. Affiliate veya dış kaynak trafik ayrı segment olarak izlenebilir. Referrer her tarayıcıda bulunmayabilir. Sistem bulunmadığında davranışını değiştirmeden devam etmelidir.

Previous Page

Oturumdaki önceki sayfa kategori veya ürün ailesi hakkında bilgi verebilir. Kullanıcı aynı kategoride geziyorsa ilgili öneriler güçlenebilir. Session verisi kısa süreli ve amaçla sınırlı tutulmalıdır. Previous page tek başına otomatik redirect gerekçesi olmamalıdır. Daha çok recommendation sıralamasında kullanılabilir.

Site Search Query

Kullanıcı site içi aramadan geldiyse aradığı metin doğrudan intent sinyalidir. Search result yanlış URL'ye yönlendirmişse index drift de tespit edilir. Resolver aynı sorguyla güncel arama yapabilir. Eşleşme yoksa typo correction uygulanabilir. Search query 404 recovery analytics'iyle ilişkilendirilebilir.

Session Behavior

Oturumdaki kategori ziyaretleri ve ürün etkileşimleri öneri kalitesini artırabilir. Bunun için kullanıcı izni ve veri politikası dikkate alınmalıdır. Anonymous session üzerinde kısa süreli bağlam yeterli olabilir. Hassas profil çıkarımı yapılmamalıdır. Amaç yalnızca kullanıcının kayıp sayfadan devam etmesini kolaylaştırmaktır.

URL'den Ürün Bağlamı Kurtarma

Legacy URL'lerden bilgi kurtarmak için eski slug dictionary, product archive, SKU resolver, redirect registry, search index ve semantic search birlikte kullanılabilir. İlk tercih deterministik kaynaklar olmalıdır. Exact SKU veya registry kaydı bulunduğunda semantic tahmine gerek kalmaz. Deterministik sonuç çıkmazsa metin benzerliği ve semantic matching devreye girebilir. Bu sıralama hem doğruluk hem maliyet açısından daha güvenli çalışır.

Eski Slug Dictionary

Slug değişiklikleri geçmiş tablo içinde saklanabilir. Eski slug geldiğinde sistem ürün kimliğini bulabilir. Aynı slug farklı zamanlarda farklı ürünlere ait olmuşsa tarih ve katalog state'i önem kazanır. Dictionary düzenli normalize edilmelidir. Exact mapping yüksek confidence sağlar.

Product Archive

Archive eski ürünün başlık, kategori, marka ve özelliklerini korur. Resolver bu bilgiyi benzer ürün bulmak için kullanabilir. Kullanıcıya eski ürünün tamamını göstermek gerekmese bile recommendation kalitesi artar. Archive hard delete riskini azaltır. Veri saklama politikası yasal gereksinimlerle uyumlu olmalıdır.

SKU Resolver

SKU resolver eski kimliği güncel lifecycle kaydıyla eşleştirir. Successor varsa doğrudan sonuç dönebilir. Birden fazla successor durumunda confidence düşürülmelidir. Resolver cache kullanabilir. Invalid SKU istekleri backend'i gereksiz zorlamamalıdır.

Redirect Registry

Registry en hızlı ve kesin kaynaklardan biridir. Bilinen source URL bulunduğunda destination doğrudan alınabilir. Hedef state yine de kontrol edilmelidir. Registry cache edge üzerinde tutulabilir. Version veya event timestamp ile güncellik izlenebilir.

Search Index

Eski ürün başlığıyla güncel katalog içinde arama yapılabilir. Search index typo toleransı sağlayabilir. Ancak sonuç listesi otomatik redirect için tek başına yeterli değildir. En yüksek sonuç bile yanlış ürün olabilir. Relevance threshold ve business rule filtresi gerekir.

Semantic Search

Semantic search metinsel anlam benzerliğiyle alternatif bulabilir. Özellikle eski ürün adı tam eşleşmediğinde yararlıdır. Marka, kategori ve attribute filtreleri sonuçları daraltmalıdır. Model skoru doğrudan redirect kararı olarak kullanılmamalıdır. En güvenli kullanım alanı öneri sıralamasıdır.

Dinamik Ürün Öneri Zinciri

404 recovery için önerileri belirli öncelik zinciriyle üretmek kararları sadeleştirir. Exact successor en güçlü seçenek, aynı ürün ailesi ikinci, benzer ürün üçüncü ve kategori düzeyi sonraki fallback olabilir. Hiçbir güçlü sinyal yoksa popüler ürünler ve site içi arama devreye girer. Bu yapı kullanıcıya mümkün olan en ilgili seçeneği önce gösterir. Recommendation servisinin her adımda aktif stok ve bölge uygunluğunu kontrol etmesi gerekir.

Seviye 1 — Exact Successor

Ürün lifecycle kaydında doğrudan successor varsa en güçlü sonuç budur. Hedef aktif ve erişilebilir olmalıdır. Relevance çok yüksekse 301 bile değerlendirilebilir. Kullanıcıya 404 gösteriliyorsa successor ilk kart olarak öne çıkarılabilir. Event source audit için saklanmalıdır.

Seviye 2 — Aynı Ürün Ailesi

Exact successor yoksa aynı family içinde güncel ürünler aranabilir. Family bilgisi katalog verisinden gelmelidir. Kullanım amacı genellikle benzerdir. Fiyat ve stok filtreleri yine uygulanmalıdır. Kullanıcıya birkaç yakın seçenek sunulabilir.

Seviye 3 — Benzer Ürün

Attribute ve semantic similarity ile benzer ürünler bulunabilir. Bu aşamada otomatik redirect yerine öneri daha güvenlidir. Sonuçların aktif ve stokta olması gerekir. Kişiselleştirme varsa sıralama değişebilir. Relevance ticari marjdan önce gelmelidir.

Seviye 4 — Aynı Kategori

Ürün eşleşmesi zayıfsa aktif kategoriye geçiş sunulabilir. Kategori leaf seviyesinde olmalıdır. Çok genel kategori kullanıcıya yeterli yardım sağlamaz. Popular veya filtered category linki kullanılabilir. Kullanıcı kendi ürününü yeniden seçebilir.

Seviye 5 — Popüler Ürünler

Bağlam bulunamıyorsa popüler ürünler fallback olabilir. Bu ürünler güncel ve stokta olmalıdır. Site geneli yerine mümkünse tahmin edilen kategori içinden seçilir. Cached sonuçlar performance açısından avantaj sağlar. Popülerlik metrikleri belirli aralıklarla yenilenmelidir.

Seviye 6 — Site Search

Search kullanıcı kontrolünü geri verir. Eski slug içinden çıkarılan kelimeler sorgu olarak önceden doldurulabilir. Kullanıcı sorguyu düzenleyebilir. Autocomplete güncel ürünleri göstermelidir. Search her zaman güvenli fallback'tir.

Hiçbiri Yoksa Genel Navigasyon

Hiçbir ürün bağlamı bulunamazsa genel navigation kullanılabilir. Ana kategoriler ve home bağlantısı yeterlidir. Backend'in boş recommendation bulmak için tekrar tekrar çağrı yapması gerekmez. Hafif 404 şablonu hızlı yüklenmelidir. Bu durum özellikle bot ve rastgele URL trafiğinde sık görülür.

404 Ürün Öneri Motoru Nasıl Çalışabilir?

Ürün öneri motoru content-based recommendation, collaborative filtering, semantic search, vector search ve business rule katmanlarını birlikte kullanabilir. 404 senaryosunda ana amaç kullanıcının kayıp ürün niyetini yakalamaktır, bu nedenle içerik ve katalog benzerliği genellikle ilk sırada gelir. Collaborative davranış sinyalleri sıralamayı iyileştirebilir. Hybrid recommendation farklı sinyalleri tek listede birleştirir. Her durumda recommendation motoru 404 sayfasının çalışması için zorunlu dependency olmamalıdır.

Content-Based Recommendation

Content-based yöntem ürün attribute'larını karşılaştırır. Marka, kategori, özellik ve fiyat segmenti temel sinyallerdir. Eski ürün archive kaydı sayesinde artık aktif olmayan üründen feature çıkarılabilir. Sonuçlar aktif katalogla karşılaştırılır. Bu yöntem yeni veya az etkileşim almış ürünlerde de çalışabilir.

Collaborative Filtering

Collaborative filtering kullanıcı davranışındaki benzerlikleri değerlendirir. Eski ürünü inceleyen kullanıcıların hangi güncel ürünlere geçtiği öğrenilebilir. Yeterli tarihsel veri yoksa sonuç zayıflayabilir. 404 recovery için tek başına kullanılmamalıdır. Content-based sinyalle birleştirildiğinde daha dengeli sonuç verir.

Semantic Search

Semantic search ürün açıklamalarındaki anlam yakınlığını kullanabilir. Eski model adı yeni model adıyla kelime olarak benzemese bile kullanım amacı benzer olabilir. Kategori filtresi sonuç kalitesini artırır. Confidence düşükse öneri sayısı azaltılabilir. Semantic sonuçların yanlış redirect üretmesine izin verilmemelidir.

Vector Search

Ürün embedding'leri vector index içinde tutulabilir. Eski ürün embedding'i archive'den alınarak nearest-neighbor sorgusu yapılabilir. Filtreler stok ve market uygunluğunu kontrol eder. Re-ranking iş kurallarıyla sonuçları düzenler. Vector sorgusu timeout olduğunda static fallback çalışmalıdır.

Business Rules

İş kuralları recommendation sonuçlarını güvenli hâle getirir. Satışa kapalı, yasaklı veya stok dışı ürünler filtrelenebilir. Sponsorlu ürünler relevance koşulu sağlandıktan sonra sıralamada yer alabilir. Aynı ürün ailesi belirli boost alabilir. Kurallar ölçülebilir ve versiyonlanabilir olmalıdır.

Hybrid Recommendation

Hybrid sistem birden fazla yaklaşımı birleştirir. Content similarity temel adayları çıkarabilir, collaborative signal sıralamayı ayarlayabilir ve business rules son filtreyi uygulayabilir. Bu yapı tek modele bağımlılığı azaltır. Debug sırasında her sonucun neden önerildiği görülebilmelidir. Açıklanabilirlik yanlış sonuçları düzeltmeyi kolaylaştırır.

Semantic Search ile Akıllı 404

Semantic search eski ürün başlığı, açıklaması, marka, kategori ve attribute bilgilerini anlam temsiline dönüştürerek güncel katalogda benzer seçenekler bulabilir. Bu yöntem özellikle ürün isimleri değiştiğinde veya yeni model adı eski modele hiç benzemediğinde faydalıdır. Yine de semantic benzerlik ticari eşdeğerlik anlamına gelmez. Vector similarity sonuçları katalog filtreleri ve re-ranking kurallarıyla doğrulanmalıdır. En güvenli kullanım, otomatik 301'den çok akıllı ürün önerisidir.

Eski Ürün Başlığı

Başlık embedding için temel veri kaynağıdır. Model numarası ve ürün tipi önemli sinyaller taşır. Gereksiz kampanya ifadeleri normalize edilebilir. Dil farklılıkları varsa multilingual model değerlendirilebilir. Başlık tek başına yeterli olmadığında diğer alanlar eklenmelidir.

Ürün Açıklaması

Açıklama kullanım amacı ve özellikler hakkında zengin bilgi sağlar. Çok uzun pazarlama metinleri noise oluşturabilir. Önemli teknik alanlar ayrı feature olarak tutulabilir. Archive ürün açıklaması eski bağlamı korur. Kişisel veya hassas veri embedding içine eklenmemelidir.

Marka

Marka vector similarity yerine metadata filtresi olarak kullanılabilir. Aynı marka şartı bazı kategorilerde güçlü olabilir. Kullanıcı davranışı farklı marka geçişine açıksa boost seviyesi azaltılabilir. Redirect kararında marka uyuşmazlığı daha yüksek risk taşır. Recommendation'da ise kullanıcıya kontrollü alternatif sunulabilir.

Kategori

Kategori aday havuzunu daraltır. Farklı ana kategorilerin semantic olarak benzer metinler üretmesi yanlış sonuçlara yol açabilir. Leaf category filtresi kaliteyi artırır. Yeni taksonomiye migration varsa eski kategori map edilmelidir. Kategori bilinmiyorsa model düşük confidence ile çalışmalıdır.

Attribute Embedding

Teknik attribute'lar metne dönüştürülüp embedding içine eklenebilir. Ürün tipine göre önemli alanlara daha fazla ağırlık verilebilir. Structured attribute bilgisi ayrıca filter olarak da kullanılabilir. Eksik değerler yanlış eşleşme oluşturmamalıdır. Feature pipeline katalog schema değişikliklerine dayanıklı olmalıdır.

Vector Similarity

Vector similarity adayların anlam yakınlığını ölçer. Tek başına 0.9 skorunun ticari anlamı yoktur. Eşik gerçek kullanıcı verisiyle kalibre edilmelidir. Farklı kategori ve dil modellerinde skor dağılımı değişebilir. Bu yüzden global sabit threshold yerine segment bazlı model gerekebilir.

Re-Ranking

Re-ranking ilk aday listesini ticari ve kullanıcı bağlamına göre yeniden sıralar. Stok, fiyat, marka ve dönüşüm performansı kullanılabilir. Relevance daima temel koşul olmalıdır. Yüksek marjlı fakat alakasız ürün sırf ticari nedenle üste taşınmamalıdır. A/B test sıralama değişikliklerinin etkisini gösterebilir.

Recommendation Architecture

Recommendation architecture ürün kataloğu, veri pipeline'ı, search veya vector index, recommendation API, rule engine, 404 resolver ve frontend component katmanlarından oluşabilir. Her katmanın sorumluluğu açık tutulduğunda sistem daha kolay test edilir. Product data pipeline güncel state'i index'e taşır, rule engine geçersiz adayları filtreler ve resolver nihai recovery tipini belirler. Frontend yalnızca gelen kararın kullanıcı arayüzünü üretir. Böylece öneri mantığı farklı storefront'larda tekrar yazılmaz.

Product Catalog

Katalog en temel veri kaynağıdır. Ürün state, category, brand, attribute ve stock bilgileri güvenilir olmalıdır. Legacy ürün archive de katalogla bağlantılı tutulabilir. Kimlik değişiklikleri mapping ile yönetilir. Recommendation kalitesi kaynak verinin kalitesinden bağımsız düşünülemez.

Product Data Pipeline

Pipeline katalog değişikliklerini search ve vector index'e taşır. Event-driven veya batch model kullanılabilir. Freshness gecikmesi ölçülmelidir. Kaldırılan ürünlerin index'ten çıkarılması ekleme kadar önemlidir. Pipeline failure alarm üretmelidir.

Search / Vector Index

Index hızlı aday bulmayı sağlar. Metadata filtreleri stok ve kategori kısıtlarını uygular. Version bilgisi veri güncelliğini izlemeye yardımcı olur. Index tamamen kullanılamazsa 404 sayfası yine çalışmalıdır. Popular products cache güvenli fallback sunabilir.

Recommendation API

API requested URL veya resolved legacy product context alabilir. Sonuçta ürün kimlikleri, relevance score ve reason döndürülebilir. Response süresi kısa tutulmalıdır. Timeout sonrası kullanıcı boş ekran görmemelidir. API failure rate teknik KPI olarak izlenebilir.

Rule Engine

Rule engine otomatik kararların sınırını belirler. Ürün state, market, stock ve compliance kuralları burada uygulanabilir. Kurallar versiyonlanmalıdır. Her önerinin hangi rule nedeniyle elendiği debug edilebilir olmalıdır. Bu yapı geliştirici deploy'u olmadan bazı iş kurallarının değişmesini sağlayabilir.

404 Resolver

Resolver URL'nin önce redirect mi, gerçek 404 mü yoksa başka state mi olduğunu belirler. Recommendation yalnızca redirect kararı çıkmadığında devreye girebilir. Legacy registry ve lifecycle lookup ilk aşamada çalışır. Confidence score karar tipini belirler. Resolver latency ayrı izlenmelidir.

Frontend Component

Frontend resolver sonucunu kullanıcıya anlaşılır biçimde gösterir. Search, öneriler ve kategori fallback bileşenleri bağımsız çalışmalıdır. Recommendation API başarısızsa component static navigasyona geçer. Accessibility ve mobile davranış burada uygulanır. Recovery interaction eventleri frontend üzerinden gönderilir.

Recommendation API Başarısız Olursa Ne Olmalı?

Recommendation 404'ün kendisi için kritik dependency olmamalıdır. Kullanıcı zaten geçersiz bir URL'ye ulaşmışken ikinci sistem hatasıyla 500 görmek deneyimi daha da kötüleştirir. API timeout olduğunda circuit breaker devreye girebilir, cached popular products veya category fallback kullanılabilir. Bunlar da bulunamazsa static navigation ve arama kutusu yeterli güvenli temel sağlar. Böylece dinamik özellikler hata sayfasının dayanıklılığını azaltmaz.

Recommendation 404'ün Kendisi İçin Kritik Dependency Olmamalı

Resolver öneri servisi olmadan da HTTP 404 döndürebilmelidir. Frontend temel mesaj ve navigation ile render olmalıdır. Öneriler enhancement olarak eklenir. Bu yaklaşım failure domain'i daraltır. Kullanıcı en kötü durumda sade ama çalışan sayfa görür.

Timeout

Recommendation çağrısı için kısa timeout tanımlanmalıdır. Kullanıcı saniyelerce boş ekran beklememelidir. Timeout metric olarak kaydedilebilir. Servis sürekli gecikiyorsa circuit breaker açılır. Fallback anında devreye girer.

Circuit Breaker

Circuit breaker bozuk recommendation servisine sürekli istek gitmesini engeller. Belirli hata oranında çağrılar kısa devre yapılır. Sistem belirli süre sonra health probe ile yeniden deneyebilir. Bu mekanizma backend yükünü azaltır. 404 availability ana servisten bağımsız kalır.

Cached Popular Products

Popüler ürünler edge veya uygulama cache'inde tutulabilir. Recommendation servisi kapalıysa hızlı fallback sağlar. Liste düzenli yenilenmelidir. Stok değişiklikleri için makul invalidation uygulanmalıdır. Kullanıcıya artık satılmayan ürün gösterilmemelidir.

Category Fallback

URL'den kategori çıkarılabiliyorsa ilgili kategori linki gösterilebilir. Bu yöntem recommendation kadar kişisel değildir ama güvenlidir. Kategori state'i aktif olmalıdır. Eski taxonomy yeni kategoriye map edilebilir. Kullanıcı güncel ürünleri kendisi görebilir.

Static Navigation Fallback

En temel fallback her zaman çalışmalıdır. Ana kategoriler, site search ve home bağlantısı yeterlidir. Ek backend çağrısına ihtiyaç duymaz. CDN üzerinden kolayca cache edilebilir. Disaster durumunda dahi kullanıcı site içinde ilerleyebilir.

404 Sayfası Backend'i Gereksiz Yük Altına Sokmamalıdır

404 trafik hacminin önemli bölümü gerçek kullanıcı değil bot, scanner veya rastgele URL isteklerinden oluşabilir. Her 404'te vector search, recommendation ve kişiselleştirme çalıştırmak maliyeti gereksiz artırır. User agent, request frequency, session ve referrer sinyalleriyle hafif sınıflandırma yapılabilir. Bot veya düşük değerli istekler static 404 ile cevaplanabilir. Gerçek kullanıcı ve ürün bağlamı bulunan isteklerde daha zengin recovery katmanı devreye alınabilir.

Bot Trafiği

Botlar rastgele URL desenlerini yüksek hızda tarayabilir. Bu isteklerin çoğunda recommendation değeri yoktur. Bilinen search engine botları ayrı izlenmelidir. Şüpheli botlar rate limiting ile sınırlandırılabilir. User agent tek başına güvenilir kimlik doğrulama aracı değildir.

Random URL Scan

Security scanner veya otomatik scriptler admin path, dosya adı ve rastgele endpoint deneyebilir. Bu URL'ler ürün resolver'a gönderilmemelidir. Route classification erken aşamada yapılabilir. Generic 404 hızlı biçimde döndürülür. Hassas sistem bilgileri yanıtta gösterilmemelidir.

Recommendation Query Cost

Vector ve collaborative sorgular normal navigation linklerinden daha maliyetli olabilir. 404 request hacmi yüksekse toplam maliyet büyür. Yalnızca anlamlı ürün context bulunduğunda sorgu yapılmalıdır. Cache benzer legacy ürün isteklerinde tekrar kullanımı azaltır. Query cost dashboard'da izlenebilir.

Cache

Legacy URL resolution sonuçları cache edilebilir. Kalıcı redirectler uzun süre saklanabilir. Dinamik öneriler daha kısa TTL kullanabilir. Product state eventleri cache invalidation tetikleyebilir. Yanlış eski cache kullanıcıyı kaldırılmış hedefe göndermemelidir.

Rate Limiting

Aynı IP veya pattern'den gelen çok yüksek 404 isteği sınırlandırılabilir. Gerçek search engine crawler davranışı yanlışlıkla engellenmemelidir. WAF ve edge rate limit kuralları birlikte kullanılabilir. Rate limit yanıtı 404 yerine uygun güvenlik davranışına göre belirlenmelidir. Security ekibi false positive oranını izlemelidir.

Lightweight Fallback

Lightweight fallback minimum HTML, navigation ve search sunabilir. Recommendation ve kişiselleştirme çağrısı yapmaz. Bot veya servis arızasında kullanılır. Core Web Vitals açısından hızlıdır. Marka deneyimi yine korunabilir.

CDN / Edge Caching

404 template edge üzerinde cache edilebilir. Ancak kullanıcıya özel içerik varsa cache key dikkatle tasarlanmalıdır. Generic bot 404'leri yüksek TTL ile tutulabilir. Product-context 404'lerde kısa TTL veya resolver sonucu cache edilebilir. Edge invalidation lifecycle eventleriyle bağlanabilir.

Bot Kaynaklı 404 Trafiği ile Gerçek Kullanıcı Trafiğini Ayırmak

404 dashboard yalnızca toplam request sayısını gösterirse ekip yanlış önceliklere yönelebilir. User agent, IP veya ASN, request frequency, session, referrer ve doğrulanmış search engine bot sinyalleri birlikte kullanılarak trafik sınıflandırılabilir. Security scanner'lar da ayrı kategori olmalıdır. Amaç botları tamamen yok saymak değil, gerçek kullanıcı kaybı ile operasyon gürültüsünü ayırmaktır. Human 404 sessions metriği bu nedenle toplam 404 request sayısından daha anlamlı olabilir.

User Agent

User agent ilk sınıflandırma sinyalidir. Bilinen browser ve bot desenleri ayırt edilebilir. Ancak kolayca taklit edilebilir. Tek başına güvenlik kararı için yeterli değildir. Diğer network ve davranış sinyalleriyle birleştirilmelidir.

IP / ASN

IP ve ASN belirli bot ağlarını tanımaya yardımcı olabilir. Search engine bot doğrulaması reverse DNS gibi yöntemlerle yapılabilir. Kullanıcı gizliliği için IP saklama süresi ve maskeleme politikası belirlenmelidir. ASN seviyesi analiz çoğu zaman yeterlidir. Güvenlik ve analytics amaçları ayrılmalıdır.

Request Frequency

İnsan kullanıcının saniyede yüzlerce farklı URL denemesi beklenmez. Yüksek frekans otomasyon sinyalidir. Rate threshold route tipine göre değişebilir. Search crawler davranışı normal botlardan farklı ele alınmalıdır. Ani frequency artışı security incident işareti olabilir.

Session

Gerçek kullanıcı çoğu zaman normal sayfalardan oluşan oturum geçmişine sahiptir. Tek bir IP'den binlerce bağımsız 404 session bulunması şüpheli olabilir. Session cookie bulunmadığında sistem yine sınıflandırma yapabilmelidir. Consent dışı izleme kullanılmamalıdır. Aggregate ölçüm yeterlidir.

Referrer

Internal referrer gerçek kullanıcı broken link'ini güçlü biçimde gösterir. Search engine veya dış içerik referreri de yüksek değer taşır. Referrer olmayan istek otomatik bot sayılmamalıdır. Browser privacy ayarları bilgiyi kaldırabilir. Sinyal yalnızca toplam modele katkı sağlamalıdır.

Search Engine Bot

Googlebot gibi doğrulanmış botlar SEO açısından ayrı izlenmelidir. Hangi 404 URL'leri sık taradıkları internal link veya eski sitemap sorunlarını gösterebilir. Bu isteklerde recommendation çalıştırmak gerekmez. Hafif ve doğru HTTP response yeterlidir. Log analizi crawl davranışını anlamak için kullanılabilir.

Security Scanner

Scanner'lar admin panel, backup dosyaları veya bilinen açık path'lerini deneyebilir. Bu istekler normal commerce recovery sisteminden ayrılmalıdır. 404 yanıtı stack trace veya framework bilgisi sızdırmamalıdır. Rate limiting ve WAF devreye girebilir. Security dashboard bu trafiği ayrı segmentte göstermelidir.

404 Sayfasında Site İçi Arama

Site içi arama, 404 sayfasındaki en güvenilir recovery araçlarından biridir. Kullanıcı aradığı ürünü kendi kelimeleriyle yeniden ifade edebilir ve sistem güncel katalog içinde arama yapar. URL'den eski ürün adı çıkarılabiliyorsa arama alanı önceden doldurulabilir. Typo correction, autocomplete, popular queries ve zero-result recovery bu deneyimi daha da güçlendirir. Search kullanım oranı 404 UX KPI'larından biri olarak izlenebilir.

Search Bar'ı Görünür Tutmak

Arama alanı sayfanın altına gizlenmemelidir. Ürün ağırlıklı sitelerde primary veya secondary aksiyon olarak ilk ekran içinde yer alabilir. Placeholder açık olmalıdır. Mobil klavye ve focus davranışı test edilmelidir. Search submit analytics eventi üretmelidir.

URL'den Search Query Pre-Fill

Eski slug anlamlı kelimeler içeriyorsa search query oluşturulabilir. Gereksiz kategori veya tracking parçaları temizlenmelidir. Kullanıcı metni düzenleyebilmelidir. Otomatik sorgu çok düşük confidence taşıyorsa alan boş bırakılabilir. Pre-fill kullanıcıya başlangıç noktası sağlar.

Typo Correction

Yanlış yazılan ürün ve marka adları düzeltilebilir. Edit distance ve dictionary tabanlı modeller kullanılabilir. Güven düşükse sistem sessizce düzeltmek yerine “bunu mu demek istediniz?” önerebilir. SKU correction daha yüksek dikkat gerektirir. Düzeltme başarısı click-through ile ölçülebilir.

Autocomplete

Autocomplete kullanıcı yazarken güncel ürün ve kategori seçenekleri gösterir. Kaldırılmış ürünler autocomplete index'inde kalmamalıdır. Sonuçlar stok ve market durumuna göre filtrelenebilir. Mobilde sonuç listesi kolay dokunulabilir olmalıdır. Response süresi kısa tutulmalıdır.

Popular Queries

Kullanıcı ne arayacağını bilmiyorsa popüler sorgular yardımcı olabilir. Site geneli yerine kategori bağlamı varsa o alanın sorguları gösterilebilir. Hassas veya uygunsuz aramalar filtrelenmelidir. Query listesi düzenli güncellenir. Çok fazla seçenek ekranı doldurmamalıdır.

Zero-Result Recovery

404 sayfasından yapılan arama da sıfır sonuç dönebilir. Bu durumda typo suggestion, kategori ve popüler ürün fallback'i sunulmalıdır. Kullanıcı ikinci kez çıkmaza sokulmamalıdır. Zero-result event kaydedilerek katalog veya synonym eksikleri bulunabilir. Search recovery ayrı funnel olarak izlenebilir.

Typo Kaynaklı URL'lerde Akıllı Recovery

Yanlış yazılmış URL'ler özellikle kullanıcıların ürün adreslerini manuel paylaştığı veya eski sistemlerden kopyaladığı sitelerde sık görülür. Edit distance, slug matching, SKU fuzzy match ve spell correction doğru hedefi tahmin etmeye yardımcı olabilir. Ancak tahmin ile gerçek taşınma aynı şey değildir. Confidence yüksekse öneri veya bazı sınırlı senaryolarda redirect düşünülebilir. Güven düşükse kullanıcıya birkaç seçenek göstermek daha emniyetlidir.

Edit Distance

Edit distance iki metin arasındaki karakter farkını ölçer. Bir harf eksikliği veya fazlalığı kolayca bulunabilir. Kısa SKU'larda tek karakter farkı ciddi anlam değişikliği yaratabilir. Bu nedenle threshold metin uzunluğuna göre ayarlanmalıdır. Kategori ve marka sinyalleri sonucu doğrulamalıdır.

Slug Matching

Slug normalize edilerek güncel ve legacy slug tablosuyla karşılaştırılabilir. Tire, slash ve küçük büyük harf farkları kaldırılabilir. Exact normalized match güçlü sinyaldir. Fuzzy match düşük confidence ile ele alınmalıdır. Redirect öncesinde ürün state kontrolü yapılmalıdır.

SKU Fuzzy Match

SKU fuzzy matching dikkat gerektirir çünkü benzer kodlar farklı ürünleri temsil edebilir. Exact SKU bulunamazsa komşu edit-distance adayları çıkarılabilir. Ancak kullanıcıya seçenek göstermek çoğu zaman otomatik redirectten daha güvenlidir. Product family bilgisi ek doğrulama sağlayabilir. Yanlış SKU eşleşmesi stok ve fiyat beklentisini bozabilir.

Spell Correction

Ürün adı ve marka sözlüğü typo correction için kullanılabilir. Search altyapısı zaten bu özelliğe sahipse 404 resolver aynı servisi yeniden kullanabilir. Düzeltme sonucu confidence ile birlikte döndürülmelidir. Kullanıcıya önerilen kelime açıkça gösterilebilir. Otomatik ve görünmez düzeltme düşük confidence'da yapılmamalıdır.

Confidence Threshold

Threshold typo recovery'nin güvenlik çizgisidir. Çok düşük eşik yanlış ürünlere redirect üretir. Çok yüksek eşik ise yararlı recovery fırsatlarını kaçırır. Gerçek kullanıcı tıklamalarıyla kalibre edilebilir. Kategoriye göre farklı eşikler gerekebilir.

Güven Yüksekse Öner

High confidence sonucu ilk seçenek olarak göstermek iyi başlangıçtır. Kullanıcı kendi kararıyla hedefe gidebilir. Exact legacy mapping varsa otomatik redirect daha uygun olabilir. Tahmin tabanlı sonuçlarda öneri kullanıcı kontrolünü korur. Click-through metriği doğruluğu test eder.

Güven Düşükse Kullanıcıya Seçenek Sun

Düşük confidence durumda tek hedefe zorlamak doğru değildir. İki veya üç yakın seçenek gösterilebilir. Site search alanı açık kalmalıdır. Kullanıcı kendisi doğru ürünü seçebilir. Bu etkileşim daha sonra model eğitim sinyaline dönüşebilir.

Otomatik Redirect ile Akıllı Öneri Arasındaki Fark

Otomatik redirect kullanıcıya seçim hakkı vermeden yeni hedefe taşır. Akıllı öneri ise 404 sayfasında olası hedefleri gösterir ve kararı kullanıcıya bırakır. Bu nedenle yüksek confidence durumunda redirect, orta confidence durumunda suggestion ve düşük confidence durumunda generic recovery modeli mantıklıdır. İki yaklaşımı aynı şey gibi kullanmak yanlış redirect oranını artırabilir. En önemli tasarım ilkesi belirsizlik yükseldikçe kullanıcı kontrolünü artırmaktır.

Yüksek Güven — Redirect

Aynı ürünün yeni URL'si yüksek güvenli örnektir. Explicit successor relation da benzer güçte olabilir. Hedef aktif ve uygun olmalıdır. Redirect tek hop ile yapılmalıdır. Analytics source reason kaydını koruyabilir.

Orta Güven — 404 + Suggested Destination

Benzerlik güçlü fakat kesin değilse 404 üzerinde suggestion gösterilir. Kullanıcı hedefi inceleyip seçebilir. Arama seçeneği de korunur. Suggestion click rate modelin faydasını gösterir. Yanlış seçim oranı feedback olarak kullanılabilir.

Düşük Güven — Generic Recovery

URL'den güvenilir bağlam çıkarılamıyorsa sistem tahmin yapmaya zorlanmamalıdır. Search, ana kategoriler ve home bağlantısı yeterlidir. Popular products isteğe bağlı gösterilebilir. Backend hafif kalır. Bot istekleri çoğunlukla bu sınıfa düşebilir.

Kullanıcı Kontrolünü Korumak

Kullanıcı kendi niyetini sistemden daha iyi bilir. Belirsiz durumda açık seçenekler sunmak güvenlidir. Redirect sonrası geri butonuna basma oranı yüksekse confidence modeli fazla agresif olabilir. Recovery UX kullanıcının seçimini kolaylaştırmalıdır. Sistem yalnızca gerekli yerde otomatik davranmalıdır.

404 Sayfasında Kaç CTA Olmalı?

404 sayfasında çok sayıda CTA eklemek kullanıcının kaybolmasını çözmeyebilir, hatta karar yükünü artırabilir. Primary CTA en güçlü recovery aksiyonuna ayrılmalıdır. Ürün bağlamı varsa ilgili ürün, yoksa site search iyi adaydır. Kategori ve home gibi seçenekler secondary seviyede tutulabilir. Mobilde tek bir primary action daha belirgin olmalı ve diğer seçenekler aşağıda sade biçimde sunulmalıdır.

Primary CTA

Primary CTA kullanıcının en olası sonraki adımını temsil eder. Dinamik ürün 404'ünde successor ürün olabilir. Generic 404'te search daha iyi seçimdir. Metin kullanıcıya ne olacağını açıkça anlatmalıdır. CTA performansı ayrı ölçülmelidir.

Search

Search birçok senaryoda evrensel recovery aracıdır. Kullanıcı kendi niyetini yeniden ifade eder. URL context ile pre-fill yapılabilir. Mobil tasarımda input kolay erişilebilir olmalıdır. Search submit ve result click funnel içinde izlenmelidir.

Alternatif Ürün

Alternatif ürün ancak relevance yeterliyse gösterilmelidir. Bir veya birkaç güçlü seçenek yeterlidir. Stok ve fiyat güncel olmalıdır. Sponsorlu ürün kullanılıyorsa relevance koşulu korunmalıdır. Kullanıcı yanlış ticari öneriyle yanıltılmamalıdır.

Kategori

Kategori linki ürün bulunamadığında güvenli geri dönüş olabilir. Leaf category daha kullanışlıdır. Çok genel kategori kullanıcının yeniden uzun yol izlemesine neden olur. Kategori active state kontrol edilmelidir. Old taxonomy mapping gerektiğinde kullanılabilir.

Çok Fazla Seçenek Vermenin Riski

Onlarca ürün ve link kullanıcının kararını zorlaştırır. 404 sayfası yeni ana sayfaya dönüşmemelidir. En ilgili birkaç yol önceliklendirilmelidir. Daha geniş navigation zaten header içinde bulunabilir. A/B test CTA sayısının recovery rate üzerindeki etkisini gösterebilir.

Mobile UX

Mobil ekranda alan sınırlıdır. Primary CTA ve search ilk ekran içinde görünür olmalıdır. Ürün kartları yatay carousel olarak kullanılabilir ancak erişilebilirlik korunmalıdır. Touch target yeterli boyutta olmalıdır. Ağır görseller 404 sayfasının yüklenmesini geciktirmemelidir.

404 Sayfasında Hangi Ürünler Gösterilmeli?

Öneri listesi yalnızca ticari önceliğe göre oluşturulmamalıdır. En benzer ürün, bestseller, kişiselleştirilmiş ürün, stokta ürün ve yüksek marjlı ürün gibi sinyaller birlikte değerlendirilebilir. Relevance temel filtre olmalıdır. Sponsorlu veya yüksek marjlı seçenekler ancak kullanıcı niyetini karşıladığında sıralamaya girmelidir. Böylece 404 recovery kullanıcıyı satış baskısına değil doğru ürüne götürür.

En Benzer Ürün

En benzer ürün genellikle ilk öneri için güçlü adaydır. Marka, kategori, özellik ve fiyat yakınlığı değerlendirilir. Ürün stokta olmalıdır. Benzerlik skoru minimum threshold'u geçmelidir. Aksi durumda kategori fallback daha doğru olabilir.

Best Seller

Bestseller ürünler genel fallback olarak işe yarayabilir. Ancak kullanıcı çok spesifik ürün arıyorsa ilk sırada olmamalıdır. Kategori bağlamında bestseller seçmek daha anlamlıdır. Güncel satış trendleri kullanılabilir. Popularity relevance'ın yerine geçmemelidir.

Kişiselleştirilmiş Ürün

Geçmiş gezinme veya favoriler öneri sıralamasını etkileyebilir. Consent ve veri minimizasyonu korunmalıdır. Kullanıcının 404'e geldiği ürün bağlamı kişisel geçmişten daha yüksek ağırlık alabilir. Anonymous kullanıcı için de sistem çalışmalıdır. Kişiselleştirme enhancement olarak görülmelidir.

Stokta Olan Ürün

404 önerisinin kendisi de stokta değilse kullanıcı ikinci çıkmazı yaşar. Final candidate list real-time veya yeterince güncel inventory filtresinden geçmelidir. Cache stale ise ürün kartı yanlış olabilir. Stock state hızlı invalidation gerektirir. Market bazlı stok ayrımı da önemlidir.

Yüksek Marjlı Ürün

Marj ticari ranking sinyali olabilir. Ancak alakasız ürünü üste taşımamalıdır. Önce relevance threshold geçilmelidir. Benzer relevance içindeki adaylarda marj tie-breaker olarak kullanılabilir. Bu yaklaşım kullanıcı deneyimi ile ticari hedef arasında denge kurar.

Sponsorlu Ürün

Sponsorlu öneri gösterilecekse açık ve ilgili olmalıdır. Kayıp ürünle bağlantısız sponsorlu içerik 404 deneyimini kötüleştirir. Relevance filtresi sponsorlu sonuçlara da uygulanmalıdır. Kullanıcı hangi içeriğin sponsorlu olduğunu anlayabilmelidir. Analytics organik ve sponsorlu recovery'yi ayrı ölçmelidir.

Relevance ile Ticari Önceliği Dengelemek

En sağlıklı sıralama önce kullanıcı niyetini filtreler, sonra ticari önceliği uygular. Relevance minimum koşuldur. Aynı relevance seviyesindeki adaylarda stok, marj veya popularity kullanılabilir. Bu politika dokümante edilmelidir. A/B test gerçek conversion etkisini gösterebilir.

Stokta Olmayan Ürünü 404 Önerilerinde Göstermemek

404 sayfasında kullanıcı zaten bir kez geçersiz veya kaldırılmış ürüne ulaşmıştır. İkinci olarak önerilen ürünün de stokta olmaması deneyimi daha fazla zedeler. Bu nedenle real-time inventory, search index freshness, recommendation filtering ve cache invalidation birlikte çalışmalıdır. Overselling riski yüksek kataloglarda yalnızca search index stok bilgisine güvenmek yeterli olmayabilir. Final recommendation API mümkünse güncel availability doğrulaması yapmalıdır.

Real-Time Inventory

Gerçek zamanlı inventory en doğru stok sinyalini sağlar. Ancak her öneri için ayrı stok çağrısı latency yaratabilir. Batch availability endpoint kullanılabilir. Kısa süreli cache performans sağlayabilir. Stok kritik ürünlerde TTL daha düşük tutulabilir.

Search Index Freshness

Search index stok bilgisini birkaç dakika gecikmeli taşıyabilir. Yüksek hızlı satış dönemlerinde bu fark önem kazanır. Freshness metriği izlenmelidir. Recommendation finalinde commerce API doğrulaması yapılabilir. Çok eski index state kullanıcıya gösterilmemelidir.

Recommendation Filter

Candidate list inventory filter'dan geçmelidir. Out of stock ürünler policy'ye göre çıkarılır. Backorder ürünler açık etiketle gösterilebilir. Market veya mağaza bazlı stok dikkate alınmalıdır. Filtre sırası latency ve doğruluk için optimize edilmelidir.

Cache Invalidation

Öneri cache'i stok değiştiğinde eski sonuç tutabilir. Inventory event cache invalidation tetikleyebilir. Çok büyük katalogda selective invalidation kullanılır. TTL tek başına yeterli olmayabilir. Stale recommendation oranı monitoring metriği olabilir.

Overselling Risk

Stok sinyali geciktiğinde kullanıcı mevcut olmayan ürünü sepete eklemeye çalışabilir. 404 recovery bu riski artırmamalıdır. Sepete ekleme anında final inventory kontrolü zaten yapılmalıdır. Ürün kartındaki availability mümkün olduğunca güncel olmalıdır. Yoğun kampanyalarda daha kısa cache politikası uygulanabilir.

Fiyat ve Kampanya Bilgisinin Güncelliği

404 önerilerinde gösterilen fiyat ve kampanya bilgisinin güncel olması güven açısından önemlidir. Cached recommendation sonucu saatler önceki kampanyayı taşırsa kullanıcı hedef PDP'de farklı fiyat görebilir. Promotion expiry, current price, availability ve personalized pricing gibi alanlar farklı hızlarda değişebilir. Öneri cache'i ürün kimliği saklayıp fiyatı render sırasında güncel servisten almak gibi hibrit yaklaşım kullanabilir. Ticari bilgi ile gerçek PDP arasında tutarlılık korunmalıdır.

Cached Recommendation Riski

Cache performansı artırır fakat eski ticari veri riski taşır. Ürün kimliklerini uzun, fiyatı kısa TTL ile saklamak mümkün olabilir. Kampanya sonu event invalidation tetikleyebilir. Stale oranı izlenmelidir. Kullanıcı yanlış indirim mesajıyla yönlendirilmemelidir.

Promotion Expiry

Kampanya bitiş zamanı merkezi kaynaktan gelmelidir. Recommendation kartları kendi tarih mantığını üretmemelidir. Promotion event cache temizliği yapabilir. Saat dilimi farkları dikkatle yönetilmelidir. Geçmiş kampanya etiketi kullanıcı güvenini zedeler.

Current Price

Current price ürün PDP'siyle aynı kaynaktan beslenmelidir. Farklı sistemler fiyat hesaplıyorsa tutarsızlık çıkabilir. Currency ve vergi politikası market bazında uygulanmalıdır. Recommendation response fiyatın timestamp bilgisini taşıyabilir. Çok eski fiyat gösterilmemelidir.

Availability

Availability yalnızca stok adedi değildir. Region, seller veya fulfillment durumuna göre değişebilir. Kullanıcı bulunduğu markette satın alamadığı ürünü görmemelidir. Resolver market context'i recommendation API'ye iletebilir. Gizlilik gerektirmeyen genel region sinyalleri yeterli olabilir.

Personalized Pricing

Kişiselleştirilmiş fiyatlandırma varsa cache dikkatle tasarlanmalıdır. Kullanıcıya başka segmentin fiyatı gösterilmemelidir. Shared edge cache kişisel fiyat taşımamalıdır. 404 recovery için genel liste fiyatı göstermek daha güvenli olabilir. PDP'ye geçişte gerçek kişisel fiyat uygulanabilir.

404 Sayfasında Kişiselleştirme

Kişiselleştirme 404 recovery'yi daha ilgili hâle getirebilir ancak temel deneyimin önüne geçmemelidir. Anonymous user için URL ve kategori bağlamı yeterli başlangıçtır. Logged-in kullanıcıda previous browsing, cart context ve favorite categories gibi sinyaller ek sıralama katkısı sağlayabilir. Privacy ve consent kuralları hangi verinin kullanılabileceğini açıkça belirlemelidir. Kişiselleştirme devre dışı kaldığında da sayfanın güçlü biçimde çalışması gerekir.

Anonymous User

Anonim kullanıcı için URL, referrer ve session context kullanılabilir. Uzun dönem profil gerekmeyebilir. Kategori ve eski SKU bilgisi güçlü recovery sağlar. Cookie izni olmayan kullanıcıya kişisel tracking zorlanmamalıdır. Generic fallback her zaman bulunmalıdır.

Logged-In User

Hesaplı kullanıcı daha zengin tercih geçmişine sahip olabilir. Favori marka veya kategori sıralamayı etkileyebilir. Bu bilgi sadece izin verilen amaçlar için kullanılmalıdır. Kullanıcı profilini 404 ekranında açıkça ifşa etmek gerekmez. Recommendation mantığı sade kalmalıdır.

Previous Browsing

Son ziyaret edilen ürünler kullanıcı niyetini gösterebilir. Aynı kategori ağırlık kazanabilir. Ancak kayıp URL bağlamı daha doğrudan sinyal olduğu için önceliğini korumalıdır. Session kısa tutulabilir. Davranış verisi agregasyonla analiz edilebilir.

Cart Context

Sepetteki ürünler tamamlayıcı önerileri etkileyebilir. Fakat kullanıcının aradığı kayıp ürünün yerine tamamen farklı cross-sell göstermek doğru değildir. Önce replacement ihtiyacı çözülmelidir. Ardından ek ürün önerileri düşünülebilir. Cart verisi hassas hesap bilgileriyle karıştırılmamalıdır.

Favorite Categories

Favori kategoriler generic fallback sıralamasını iyileştirebilir. Kullanıcı doğrudan ürün bağlamı taşımıyorsa fayda sağlar. Kayıp ürün başka kategoriye aitse sistem onu bastırmamalıdır. Kişiselleştirme relevance üzerine ek katman olmalıdır. Kullanıcı ayarlarından devre dışı bırakılabilmelidir.

Privacy ve Consent

404 sayfası veri toplamak için özel ayrıcalığa sahip değildir. Normal consent politikaları burada da geçerlidir. Gerekli olmayan kişisel veri resolver'a gönderilmemelidir. Analytics mümkün olduğunca anonim veya pseudonymous olabilir. Kullanıcı deneyimi gizlilik pahasına iyileştirilmemelidir.

404 Sayfasında Conversion Recovery

404 optimizasyonunun ticari tarafı yalnızca sayfadan çıkış oranını azaltmak değildir. Product click, search, category click, add to cart, wishlist, back-in-stock subscription ve purchase gibi olaylar recovery funnel içinde ölçülebilir. Böylece 404 sayfasının gerçekten satış yolculuğunu kurtarıp kurtarmadığı anlaşılır. Tek başına düşük bounce rate başarı sayılmamalıdır. Kullanıcının geçerli ürün sayfasına ve mümkünse satın almaya ilerlemesi daha anlamlı sonuçtur.

Product Click

Önerilen ürüne tıklama ilk recovery sinyalidir. Hangi recommendation reason ile gösterildiği kaydedilebilir. Click-through relevance modelini değerlendirmeye yardımcı olur. Çok tıklanan ancak hızla terk edilen hedefler ayrıca incelenmelidir. Click tek başına nihai başarı değildir.

Search

Search submit kullanıcının recovery niyetini sürdürdüğünü gösterir. Sorgu sonucu ürün görüntülemesine dönüşürse daha güçlü başarıdır. Zero-result search ayrı takip edilmelidir. Pre-fill kullanımının etkisi test edilebilir. Search recovery conversion ile ilişkilendirilebilir.

Category Click

Kategori tıklaması kullanıcının daha geniş seçim yapmak istediğini gösterir. Çok genel kategori tıklamaları düşük conversion üretebilir. Leaf category önerileri daha iyi çalışabilir. Category click sonrası product view izlenmelidir. Böylece gerçek recovery oranı hesaplanabilir.

Add to Cart

404 sonrası sepete ekleme güçlü ticari recovery eventidir. Source 404 URL attribution içinde korunmalıdır. Kullanıcı birkaç sayfa gezdikten sonra sepete eklese bile session attribution uygulanabilir. Aynı kullanıcı birden fazla 404 görürse attribution kuralı tanımlanmalıdır. Revenue raporları bu veriyi kullanabilir.

Wishlist

Wishlist doğrudan satış olmasa da güçlü niyet göstergesidir. Özellikle pahalı ürünlerde karar süresi uzun olabilir. 404 recommendation sonucu wishlist eklenmesi değerli recovery sayılabilir. Sonraki satın alma isteğe bağlı olarak attribution'a bağlanabilir. Privacy sınırları korunmalıdır.

Back-in-Stock Subscription

Stok bildirimi geçici stok yokluğunda önemli conversion türüdür. Kullanıcı ürünün geri gelmesini beklemeye razıdır. Subscription success ayrı ölçülmelidir. Bildirim sonrası purchase daha uzun attribution penceresi gerektirebilir. Ürünün gerçekten geri gelme ihtimali bulunmalıdır.

Purchase

Purchase recovery funnel'ın en güçlü ticari sonucudur. Kullanıcının 404 oturumundan hangi yol üzerinden geldiği korunmalıdır. Direct successor ve search recovery farklı segmentlerde ölçülebilir. Gelir katkısı dashboard'da gösterilebilir. Böylece 404 yatırımı somut ticari değerle ilişkilendirilir.

404 Recovery Funnel

404 recovery funnel, hata sayfasını teknik log satırından kullanıcı yolculuğuna dönüştürür. 404 View ile başlayan süreç Recovery Interaction, Product View, Add to Cart, Checkout, Purchase ve Recovered Revenue aşamalarından oluşabilir. Her adımın dönüşüm oranı hesaplanır. Farklı recovery yöntemleri ayrı segmentlerde karşılaştırılır. Böylece hangi tasarım veya recommendation yaklaşımının gerçekten daha fazla gelir kurtardığı görülebilir.

404 View

Funnel başlangıcı gerçek kullanıcı tarafından görülen 404 sayfasıdır. Bot requestleri mümkünse ayrı tutulmalıdır. Route type ve source URL context kaydedilir. Aynı session içindeki tekrar görüntülemeler ayrıca analiz edilebilir. Page view teknik request sayısından farklı metriktir.

Recovery Interaction

Arama, ürün önerisi, kategori veya home tıklaması recovery interaction sayılabilir. Primary ve secondary aksiyonlar ayrı event taşır. Interaction rate sayfanın kullanıcıyı harekete geçirip geçirmediğini gösterir. Çok düşük oran mesaj veya CTA problemini işaret edebilir. A/B test ile farklı düzenler karşılaştırılabilir.

Product View

Recovery sonrası geçerli PDP'ye ulaşılması daha güçlü başarıdır. Hedefin doğrudan öneriden mi search'ten mi geldiği izlenir. Product view sonrası hemen geri dönüş yanlış eşleşme sinyali olabilir. Relevance modeline feedback sağlanabilir. User journey birkaç adımı kapsamalıdır.

Add to Cart

Sepete ekleme ticari niyetin güçlendiğini gösterir. 404 kaynak attribution kaybedilmemelidir. Event pipeline source recovery method bilgisini taşır. A/B testler add-to-cart oranıyla değerlendirilebilir. Yalnızca CTR üzerinden karar vermek yanıltıcı olabilir.

Checkout

Checkout aşaması alışveriş sürecinin ilerlediğini gösterir. 404 recovery'nin gerçek ticari etkisini anlamada önemlidir. Payment veya shipping sorunları ayrı funnel problemidir. Recovery attribution checkout boyunca korunabilir. Session timeout kuralları açık olmalıdır.

Purchase

Satın alma gerçekleştiğinde recovered order işaretlenebilir. Sipariş değerinin tamamını veya belirli attribution payını recovery gelirine yazmak için kural gerekir. Farklı kanal modelleri farklı sonuç verebilir. Tutarlı metodoloji kullanılmalıdır. Dashboard tanımı ekiplerle paylaşılmalıdır.

Recovered Revenue

Recovered revenue 404 deneyiminin ticari değerini anlatır. Bu metriği aşırı yorumlamamak gerekir çünkü kullanıcı başka yoldan da ürünü bulabilirdi. A/B test daha sağlam artış tahmini sağlayabilir. Yine de operasyon önceliği belirlemede güçlü göstergedir. High-value broken URL'ler bu sayede hızlı çözülebilir.

404 Sayfasında E-Posta Toplamak Mantıklı mı?

E-posta toplama kullanıcı niyetiyle uyumluysa anlamlı olabilir. Stokta olmayan ürün için “stok gelince haber ver” CTA'sı doğal bir gerekçe sunar. Benzer ürün bildirimi de belirli kategorilerde yararlı olabilir. Buna karşılık generic 404 sayfasında büyük newsletter pop-up göstermek kullanıcıyı daha fazla yorabilir. Recovery önce kullanıcının mevcut problemini çözmeli, veri toplama ikinci planda kalmalıdır.

Stok Bildirimi

Stok bildirimi ürün niyetine doğrudan bağlıdır. Kullanıcı e-posta vermesinin nedenini anlar. Ürün geri geldiğinde bildirim gönderilir. İzin süreci açık olmalıdır. Subscription conversion ayrı ölçülebilir.

Benzer Ürün Bildirimi

Kullanıcının aradığı ürün artık yoksa benzer ürün gelişmelerini takip etmek isteyebilir. Bu özellik kategoriye göre kullanılabilir. Kullanıcı hangi tür bildirime kaydolduğunu bilmelidir. Gereksiz sıklıkta mesaj gönderilmemelidir. Opt-out kolay olmalıdır.

Newsletter

Genel newsletter 404 recovery'nin ana amacı değildir. Kullanıcı zaten bir problem yaşamaktadır. Önce arama ve ürün alternatifleri gösterilmelidir. Newsletter daha düşük öncelikli alanda sunulabilir. Pop-up kullanmak çoğu durumda gereksiz baskı yaratır.

Kullanıcının Niyetine Uygun CTA

CTA içeriği route context'e göre değişebilir. Stok yoksa bildirim, ürün kaldırılmışsa alternatif, generic 404'te search daha anlamlıdır. Tek tip lead form herkese uygun değildir. Dinamik 404 bu farkı kullanabilir. Conversion oranı bağlama göre segmentlenmelidir.

Gereksiz Conversion Baskısından Kaçınmak

404 sayfası kullanıcıyı manipüle eden satış ekranına dönüşmemelidir. Çok fazla popup ve form recovery'yi zorlaştırır. Kullanıcı önce aradığı içeriğe yaklaşmak ister. Ticari CTA relevance'a bağlı olmalıdır. Güvenilir deneyim uzun vadede daha değerlidir.

SEO Açısından İyi Bir Custom 404 Nasıl Olmalı?

SEO açısından iyi custom 404 gerçek HTTP 404 status code döndürür, marka tasarımını korur, kullanışlı internal links ve search sunar, gerekiyorsa ilgili ürün önerileri gösterir ve indekslenmeye çalışmaz. Kayıp URL XML sitemap içinde tutulmamalıdır. Custom tasarımın güzel olması status code hatasını telafi etmez. Aynı şekilde doğru 404 kodu da kullanıcıya yalnızca boş ekran sunmak için gerekçe değildir. Teknik sinyal ve UX birlikte doğru tasarlanmalıdır.

Gerçek 404 Status Code

Response header 404 olmalıdır. Frontend yalnızca görsel hata göstermemelidir. SSR, edge veya server route bunu üretmelidir. Automated test response code'u doğrulamalıdır. Soft 404 riski böylece azalır.

Brand Tasarımı

404 sayfası sitenin geri kalanından kopuk görünmemelidir. Logo, renk sistemi ve navigation korunabilir. Aşırı görsel içerik performance'ı düşürmemelidir. Kullanıcı doğru sitede olduğunu anlamalıdır. Marka tonu kısa ve yardımcı olmalıdır.

Kullanışlı Internal Links

Internal links kullanıcıyı aktif kategorilere ve ürünlere götürmelidir. Ölü URL'ye yeni link üretmekten kaçınılmalıdır. Dinamik öneri linkleri düzenli health check'ten geçebilir. Navigation normal site yapısıyla uyumlu olmalıdır. Link sayısı gereksiz büyütülmemelidir.

Search

Search kullanıcının ürünü yeniden bulmasını sağlar. Query pre-fill recovery hızını artırabilir. Search sonuçlarının kendisi güncel olmalıdır. Zero-result durumunda ek fallback bulunmalıdır. Search box erişilebilir biçimde etiketlenmelidir.

Alakalı Öneriler

Ürün önerileri gerçekten ilgili olmalıdır. Stokta ürünler tercih edilir. Recommendation failure sayfayı etkilememelidir. Structured data gereksiz yere 404 template'e eklenmemelidir. Öneriler kullanıcı recovery'si içindir.

Indexlenmeye Çalışmaması

404 response arama motoruna sayfanın geçerli içerik olmadığını bildirir. Hata template'ini indexletmeye çalışmak gerekmez. Custom 404 için ayrı canonical manipülasyonu yapılmamalıdır. Internal search URL'leri de ayrıca policy ile yönetilmelidir. Search Console sonuçları periyodik kontrol edilmelidir.

Sitemap'te Bulunmaması

404 URL XML sitemap içinde yer almamalıdır. Sitemap geçerli canonical ve indexlenebilir URL envanterini yansıtmalıdır. Redirect edilmiş URL'ler de çıkarılmalıdır. Lifecycle event sitemap sync'i tetikleyebilir. Düzenli validation hata oranını düşük tutar.

404 URL'leri XML Sitemap'te Kalmalı mı?

Hayır. XML sitemap'in amacı arama motorlarına indekslenmesi hedeflenen geçerli URL'leri sunmaktır. 404, 410 veya redirect olmuş URL'lerin sitemap içinde kalması çelişkili sinyal oluşturur. Büyük kataloglarda bu temizlik manuel yapılmamalı, ürün lifecycle ve URL registry ile otomatik senkronize edilmelidir. Sitemap validation job her URL'yi sürekli tek tek taramak yerine katalog state'ini kaynak olarak kullanabilir. Periyodik crawl ile de doğrulama yapılmalıdır.

Sitemap'in Amacı

Sitemap geçerli sayfaların keşfini kolaylaştırır. Arşiv veya filtre sayfalarının dahil edilmesi SEO politikasına bağlıdır. Bulunamayan URL'ler bu listede olmamalıdır. Lastmod gibi alanlar gerçek değişiklikleri yansıtmalıdır. Çok büyük kataloglarda sitemap index yapısı kullanılabilir.

Kaldırılmış URL'leri Çıkarmak

REMOVED lifecycle event sitemap removal tetikleyebilir. İşlemin tamamlandığı event log ile izlenmelidir. Sitemap cache purge edilmelidir. Kaldırma birkaç gün gecikmemelidir. Reconciliation job unutulan URL'leri bulabilir.

Redirect Edilmiş URL'leri Çıkarmak

301 kaynak URL sitemap'te kalmamalıdır. Sitemap doğrudan destination URL'yi göstermelidir. Böylece bot gereksiz redirect hop yapmaz. Migration sonrası bu kontrol özellikle önemlidir. Sitemap crawler 3xx URL raporu üretebilir.

Yalnızca Canonical ve Indexlenebilir URL'ler

Genel kural self-canonical ve indexlenebilir URL'leri sitemap'te tutmaktır. Noindex sayfaların sitemap'e eklenmesi çelişkili olabilir. Canonical başka URL'ye işaret ediyorsa tercih edilen hedef sitemap'te yer almalıdır. Policy sayfa tipine göre değişebilir. Otomasyon merkezi metadata'dan beslenmelidir.

Sitemap Sync Automation

Sitemap generator katalog lifecycle eventlerini tüketebilir. Yeni ürün eklenir, kaldırılmış ürün çıkarılır. Redirect state değişiklikleri aynı sisteme ulaşır. Büyük kataloglarda incremental update yapılabilir. Başarısız joblar alert üretmelidir.

Internal Link'ler 404'e Gitmemeli

Bir kullanıcının site içindeki kendi navigasyonundan 404'e düşmesi çoğu durumda önlenebilir problemdir. Navigation, PLP, PDP recommendation, blog, campaign ve footer linkleri geçerli URL'leri hedeflemelidir. Internal broken links arama motoruna da gereksiz crawl yolu açar. Crawler, CI/CD link check, production crawl ve server log analizi birlikte kullanılabilir. Internal link kaynaklı 404'ler external backlink 404'lerinden daha yüksek operasyon önceliği alabilir çünkü sitenin doğrudan kontrolündedir.

Navigation

Ana menüde 404 link bulunması kritik UX hatasıdır. Navigation config deployment öncesi doğrulanmalıdır. Dynamic category linkleri active state kontrolü yapmalıdır. Cache değişiklikleri zamanında yansıtmalıdır. Header ve mobile menu birlikte test edilmelidir.

PLP

Product listing page kaldırılmış PDP'ye link vermemelidir. Search index drift veya catalog cache bunu oluşturabilir. Ürün kartı render öncesi active state kontrolü yapılabilir. Büyük katalogda her request için ek lookup yerine güncel index gerekir. Broken PLP link oranı izlenebilir.

PDP Recommendation

Recommendation widget eski ürüne link verirse kullanıcı geçerli PDP'den 404'e düşer. Candidate filtering lifecycle state'i kontrol etmelidir. Cache invalidation önemlidir. Recommendation API health check broken destination oranını ölçebilir. Bu hata 404 recovery'den önce kaynağında çözülmelidir.

Blog

Eski içeriklerde ürün linkleri yıllarca yaşayabilir. Content audit broken product links bulmalıdır. Yeni successor varsa link güncellenebilir. Alternatif yoksa içerik bağlamı korunarak link kaldırılabilir. Blog linkleri dış backlink kadar değerli internal sinyal oluşturabilir.

Campaign

Kampanya landing page'leri kısa sürede çok sayıda ürün linki üretir. Kampanya sonrasında ürünler değişebilir. Dynamic product component aktif katalogdan beslenmelidir. Static hard-coded linkler daha sık audit gerektirir. Kampanya yayınından önce link checker çalıştırılmalıdır.

Footer

Footer site genelinde tekrarlandığı için tek broken link binlerce sayfadan 404'e yol açabilir. Deployment öncesi kontrol edilmelidir. Footer config merkezi yönetilmelidir. Eski kampanya veya kategori linkleri burada unutulmamalıdır. Sitewide broken link yüksek öncelikli sorun sayılmalıdır.

Internal Link Audit

Crawler bütün internal link graph'ını tarayabilir. 4xx destination ve source sayfalar raporlanır. En çok internal link alan broken URL'ler önce düzeltilir. Redirect üzerinden giden internal linkler de direct target'a güncellenebilir. Audit düzenli çalıştırılmalıdır.

Broken Internal Link Otomatik Nasıl Tespit Edilir?

Broken internal link tespiti crawler, CI/CD link check, production crawl, server logs, Search Console ve alerting kombinasyonuyla yapılabilir. Tek bir araç tüm senaryoları yakalamaz. CI/CD yeni regressions'ı yayın öncesinde engellerken production logs gerçek kullanıcıların karşılaştığı durumları gösterir. Search Console bot perspektifini ekler. Bu sinyaller merkezi dashboard'a geldiğinde internal 404 kaynakları hızla bulunabilir.

Crawler

Crawler site içindeki linkleri düzenli tarar. Destination status code kaydedilir. 404'e giden source URL listelenir. Büyük sitelerde örnekleme veya önceliklendirme yapılabilir. JavaScript render gerekiyorsa uygun crawler modu seçilmelidir.

CI/CD Link Check

Build sırasında kritik URL ve statik linkler doğrulanabilir. Yeni component broken href içeriyorsa deployment durdurulabilir. Dynamic katalogun tamamını CI içinde taramak gerekmeyebilir. Contract test API state'ini doğrulayabilir. Kritik navigation linkleri mutlaka kapsanmalıdır.

Production Crawl

Production crawl gerçek ortamın routing ve CDN davranışını kontrol eder. Staging'de görünmeyen redirect veya cache sorunları bulunabilir. Crawl schedule trafiği etkilemeyecek şekilde ayarlanmalıdır. Sonuçlar önceki run ile karşılaştırılabilir. Yeni 404 artışı otomatik alert oluşturabilir.

Server Logs

Server log bütün gerçek 404 requestlerini gösterir. Referrer internal ise broken source doğrudan bulunabilir. Bot ve insan trafiği ayrıştırılabilir. Yüksek frekanslı path'ler öncelik alır. Log retention ve privacy politikası tanımlanmalıdır.

Search Console

Search Console arama motorunun gördüğü Not Found ve Soft 404 örneklerini sağlar. Bütün 404 trafiğini göstermeyebilir. Bu nedenle logun yerine değil, tamamlayıcısıdır. URL Inspection kritik örnekleri kontrol etmekte faydalıdır. Fix sonrası doğrulama yapılabilir.

Alerting

Alert yalnızca her 404 için çalışmamalıdır. Baseline üzerindeki spike, kritik route veya yüksek trafikli URL gibi koşullar kullanılabilir. Internal broken link artışı ayrı threshold taşıyabilir. Alert owner ve runbook bilgisi içermelidir. Gereksiz alarm gürültüsü azaltılmalıdır.

External Backlink 404'leri Nasıl Ele Alınmalı?

External backlink 404'leri sitenin doğrudan kontrol edemediği fakat değer taşıyabilecek trafik kaynaklarıdır. Önce backlink'in kalitesi, yönlendirdiği eski içerik ve kullanıcı niyeti değerlendirilmelidir. Gerçek yeni hedef varsa 301 kullanılabilir. Alternatif yoksa 404 bırakmak, alakasız sayfaya yönlendirmekten daha doğru olabilir. Çok değerli backlinklerde kaynak siteyle iletişime geçerek linkin güncellenmesini istemek uzun vadeli çözüm sağlar.

Backlink Değerini Ölçmek

Backlink sayısı tek başına yeterli değildir. Kaynak sayfanın konusu, trafik kalitesi ve kullanıcı ilgisi değerlendirilmelidir. Spam linkler redirect kararını etkilememelidir. Referral session verisi gerçek kullanım hakkında bilgi verir. Yüksek değerli bağlantılar priority score içinde öne çıkar.

İlgili Yeni Hedef Bulmak

Eski URL'nin ürün veya kategori bağlamı çıkarılır. Registry ve product archive kontrol edilir. Successor veya bire bir yeni kategori varsa hedef doğrulanır. Düşük relevance'da redirect yapılmaz. Kullanıcı niyeti backlink değeri kadar önemlidir.

301

Gerçek karşılık bulunduğunda 301 hem kullanıcı hem bot için doğru taşınma sinyali verir. Destination aktif olmalıdır. Redirect chain olmamalıdır. Registry reason olarak BACKLINK_RECOVERY değil gerçek lifecycle nedenini saklamalıdır. Çünkü backlink yalnızca öncelik sinyalidir, taşınma nedeni değildir.

Alternatif Yoksa 404

Alternatif yoksa 404 tamamen normaldir. Custom 404 kullanıcıya search ve kategori sunabilir. Backlink değeri yanlış hedef üretmek için gerekçe değildir. Kaynak URL monitoring listesinde tutulabilir. Trafik yüksekse özel recovery content düşünülebilir.

Kritik Backlink İçin Outreach

Çok değerli kaynaklarda linki doğrudan yeni URL'ye güncelletmek en temiz çözümdür. Outreach mesajı eski ve yeni URL'yi açıkça belirtmelidir. Kaynak sahibi değişiklik yapmak zorunda değildir. Redirect yine yedek olarak kalabilir. Güncelleme sonrası referral trafik kontrol edilebilir.

404 Monitoring Sistemi Nasıl Kurulur?

404 monitoring yalnızca URL ve sayı tutmakla sınırlı kalmamalıdır. Request URL, timestamp, HTTP status, referrer, user agent, session ID, ürün veya kategori context'i ve recovery action gibi alanlar olayın gerçek anlamını ortaya çıkarır. Veriler normalize edilerek aynı path varyasyonları birleştirilebilir. Bot noise ve human session ayrımı yapılabilir. Dashboard teknik, SEO ve ticari ekiplerin aynı veriyi farklı amaçlarla okuyabileceği şekilde tasarlanmalıdır.

Request URL

Ham URL debugging için saklanabilir. Hassas query parameter'lar loglanmadan önce temizlenmelidir. Normalize URL ayrıca tutulur. Çok uzun veya zararlı input güvenli biçimde işlenmelidir. URL log injection risklerine karşı sanitize edilmelidir.

Timestamp

Zaman bilgisi spike analizi için gereklidir. Deployment ve katalog import olaylarıyla korelasyon kurulabilir. Saat dilimi standardı belirlenmelidir. Backend loglarında UTC kullanmak yaygındır. Dashboard kullanıcıya yerel saat gösterebilir.

HTTP Status

404 dışında 410, 301 ve 500 de aynı sistemde izlenebilir. Response status gerçek network değerinden alınmalıdır. Frontend label'a güvenilmemelidir. Soft 404 ayrı detection sonucu olarak saklanabilir. Status trendleri route bazında analiz edilir.

Referrer

Referrer broken link kaynağını bulmayı kolaylaştırır. Internal referrer yüksek öncelik alabilir. External referral backlink fırsatı gösterebilir. Search engine referrer organik segment oluşturur. Eksik referrer normal kabul edilmelidir.

User Agent

User agent insan ve bot sınıflandırmasına katkı sağlar. Browser family mobil UX problemlerini gösterebilir. Bot signature listesi güncel tutulmalıdır. Hassas fingerprinting yapılmamalıdır. Aggregate analiz yeterlidir.

Session ID

Session ID recovery funnel kurmak için kullanışlıdır. Pseudonymous değer tercih edilmelidir. Retention politikası belirlenmelidir. Oturum boyunca 404 sonrası product view ve purchase ilişkilendirilebilir. Kullanıcı hesabı kimliği gerekmeyebilir.

Product / Category Context

Resolver eski SKU veya kategori bulduysa monitoring olayına eklenebilir. Böylece en çok hata alan ürün aileleri görülür. Katalog state drift daha kolay fark edilir. Context bulunmazsa null değer normaldir. Monitoring sistemi inference ile gerçek katalog verisini ayırmalıdır.

Recovery Action

Kullanıcının search, product suggestion, category veya home seçimi kaydedilebilir. Otomatik redirect de ayrı action'dır. Bu veri recovery rate hesaplamasını sağlar. Action sonrası conversion olayları bağlanabilir. Farklı 404 template varyantları karşılaştırılabilir.

404 Loglarında Hangi Alanlar Tutulmalı?

404 logları yalnızca URL listesinden daha zengin olmalıdır. URL, normalized URL, source, route type, old SKU, suggested SKU, redirect destination, response time ve conversion outcome gibi alanlar teknik hata ile ticari etkiyi aynı kayıtta ilişkilendirir. Ancak her alanın veri minimizasyonu açısından gerekli olması gerekir. Hassas kullanıcı bilgileri loglara taşınmamalıdır. Veri modeli debugging ve dashboard ihtiyaçlarını dengeli biçimde karşılamalıdır.

URL

Raw URL detaylı inceleme için gereklidir. Query string hassas veri içeriyorsa redaction uygulanmalıdır. Encoding normalize edilmeden önce ham değer gerektiğinde saklanabilir. Güvenlik loglarıyla analytics logları ayrılabilir. Storage süresi policy ile sınırlanmalıdır.

Normalized URL

Normalized URL aynı isteğin farklı yazım biçimlerini gruplayabilir. Tracking parametreleri kaldırılabilir. Trailing slash ve case politikası standartlaştırılır. Dashboard cardinality azalır. Ancak normalization gerçek farklı kaynakları yanlış birleştirmemelidir.

Source

Source internal, external, search, direct veya bot gibi sınıflara ayrılabilir. Referrer ve session sinyalleri kullanılabilir. Bu sınıflandırma priority modelini güçlendirir. Unknown source geçerli kategori olmalıdır. Tahmin confidence değeri saklanabilir.

Route Type

PRODUCT, CATEGORY, CAMPAIGN, SEARCH veya UNKNOWN gibi route türleri kullanılabilir. Route classification resolver davranışını belirler. Her tür için farklı 404 baseline bulunabilir. Dashboard segmentasyonu kolaylaşır. Deployment sorunları belirli route üzerinde hızlı fark edilir.

Old SKU

Legacy product çözümlenebiliyorsa old SKU saklanabilir. Bu alan product archive ile bağlantı kurar. Successor analizi kolaylaşır. Raw URL'den tahmin edilen SKU ile registry'den kesin bulunan SKU ayrı flag taşımalıdır. Yanlış inference raporlamayı bozmamalıdır.

Suggested SKU

Recommendation'ın ilk adayı suggested SKU olarak saklanabilir. Confidence ve reason da eklenebilir. Kullanıcı tıklamazsa bile model performansı analiz edilir. Birden fazla öneri ayrı child event olarak tutulabilir. Katalog silinen ürünleri suggestion olarak üretmemelidir.

Redirect Destination

301 veya 302 varsa destination loglanmalıdır. Final destination ile initial destination ayrı olabilir. Chain tespiti kolaylaşır. Redirect reason registry'den alınabilir. Bozuk hedefler hızlı filtrelenir.

Response Time

404 sayfası hızlı olmalıdır. Resolver ve recommendation latency ayrı ölçülebilir. Toplam response time bot ve human segmentlerinde karşılaştırılır. Ani artış backend sorununu gösterebilir. Performance KPI business impact ile birlikte izlenmelidir.

Conversion Outcome

Session içinde gerçekleşen recovery conversion sonradan event join ile eklenebilir. Product view, add-to-cart veya purchase gibi seviyeler tutulabilir. Log satırını sürekli güncellemek yerine event warehouse join yapılabilir. Attribution penceresi açık tanımlanmalıdır. Böylece teknik request verisi ticari sonuçla bağlanır.

404 Hataları Nasıl Kategorize Edilmeli?

404'leri User Typo, Internal Broken Link, External Broken Link, Deleted Product, Deleted Category, Search Index Drift, Deployment Regression ve Bot Noise gibi kategorilere ayırmak aksiyon planını kolaylaştırır. Her kategori farklı owner ve çözüm gerektirir. Internal broken link engineering veya content tarafında düzeltilirken deleted product lifecycle policy ile yönetilir. Bot noise çoğu zaman SEO remediation gerektirmez. Classification otomatik başlayıp yüksek değerli vakalarda insan doğrulamasıyla desteklenebilir.

User Typo

Typo kullanıcı hatası gibi görünse de iyi recovery deneyimi sunulabilir. Slug matching ve search correction işe yarar. Sistemin internal link üretimi doğruysa source genellikle direct olur. Otomatik redirect yalnızca yüksek confidence'da kullanılmalıdır. Typo trendleri popüler ürün adlarını gösterir.

Internal Broken Link

Internal broken link doğrudan sitenin kontrolündedir. Source URL biliniyorsa bağlantı mümkün olan en kısa sürede düzeltilmelidir. Redirect geçici güvenlik ağı olabilir. Asıl hedef linki doğrudan doğru URL'ye güncellemektir. Sitewide linkler kritik öncelik alır.

External Broken Link

Dış bağlantı kaynak siteden gelir. Gerçek yeni karşılık varsa 301 kullanılabilir. Alternatif yoksa 404 normaldir. Yüksek değerli kaynaklarda outreach düşünülebilir. External traffic recovery rate ayrı ölçülebilir.

Deleted Product

Deleted product lifecycle policy gerektirir. Successor ve archive bilgisi kontrol edilir. 301, 404, 410 veya archive 200 seçeneklerinden biri seçilir. Sitemap ve search index state'i senkronize edilmelidir. Delete reason audit trail içinde bulunmalıdır.

Deleted Category

Silinen kategori yeni taxonomy ile eşleştirilebilir. Bire bir hedef varsa 301 uygulanabilir. Birden fazla olası hedef varsa kullanıcıya seçim sunmak daha güvenlidir. Internal navigation temizlenmelidir. Category migration testleri çalıştırılmalıdır.

Search Index Drift

Search result aktif olmayan URL'ye gidiyorsa index drift vardır. Search ekibi ve catalog pipeline birlikte incelenmelidir. Index cleanup yapılır. Freshness metric kök nedeni takip eder. 404 yalnızca semptomdur.

Deployment Regression

Yeni release route'ları bozabilir. 404 spike deployment zamanıyla çakışır. Critical URL contract testleri bu riski azaltır. Rollback veya hotfix gerekebilir. Incident review eksik testi ortaya çıkarır.

Bot Noise

Bot noise yüksek request sayısı üretir ancak gerçek kullanıcı etkisi düşük olabilir. Security scan ve crawler trafiği ayrıştırılır. Pahalı recovery servisleri çağrılmaz. Rate limiting gerekirse uygulanır. Dashboard human metric'i bu gürültüden ayrı gösterir.

Kritik 404 ile Normal 404 Nasıl Ayrılır?

Trafik, revenue potential, backlink, internal link, search impression ve customer complaints gibi sinyaller criticality score oluşturabilir. Her 404'ü aynı aciliyetle çözmeye çalışmak büyük kataloglarda verimsizdir. Günlük bir bot isteğiyle binlerce organik gösterim alan eski ürün aynı önceliği taşımamalıdır. Criticality score engineering backlog sıralamasını kolaylaştırır. Ağırlıklar site iş modeline göre düzenli gözden geçirilmelidir.

Trafik

Yüksek request ve human session sayısı önceliği artırır. Bot requestleri ayrı filtrelenmelidir. Trend artışı da önemlidir. Dün ortaya çıkan hızlı büyüyen URL, eski düşük trafikli URL'den daha kritik olabilir. Sezon etkisi göz önüne alınmalıdır.

Revenue Potential

Eski URL geçmişte yüksek satış üretmiş olabilir. Aynı ürün ailesi yüksek ortalama sipariş değerine sahip olabilir. Recovery sonrası revenue attribution bu sinyali iyileştirir. Yüksek potansiyel daha hızlı review gerektirir. Ticari değer kullanıcı relevance ile birlikte ele alınmalıdır.

Backlink

Kaliteli backlink sayısı ve referral traffic önem taşır. Spam bağlantılar puanı artırmamalıdır. Link topic relevance kontrol edilebilir. Yüksek değerli broken backlink uygun redirect varsa hızlı aksiyon gerektirir. Alternatif yoksa outreach düşünülebilir.

Internal Link

Internal broken link doğrudan düzeltilebilir olduğu için yüksek ağırlık alabilir. Sitewide navigation kaynağı çok kritiktir. Tek eski blog linki daha düşük olabilir. Source count puana dahil edilir. Redirectin varlığı internal link güncelleme ihtiyacını ortadan kaldırmaz.

Search Impression

Search Console impression eski URL'nin arama sonuçlarında hâlâ görünür olduğunu gösterebilir. Click düşük olsa bile yüksek impression kullanıcı talebi olduğunu işaret eder. Query verisi yeni içerik veya successor stratejisine katkı sağlar. Index state kontrol edilmelidir. Uygun redirect varsa hızlı uygulanabilir.

Customer Complaints

Müşteri desteğine gelen tekrar eden şikâyetler gerçek kullanıcı problemini doğrular. URL veya ürün bilgisi ticket sisteminden 404 dashboard'a aktarılabilir. Kişisel veri anonimleştirilmelidir. Şikâyet hacmi priority score'u yükseltebilir. Support ve engineering ortak root cause çözümü yapabilir.

Criticality Score

Score farklı sinyalleri normalize ederek tek öncelik değeri üretir. Formül şeffaf olmalıdır. Takım hangi faktörün puanı artırdığını görebilmelidir. Yüksek score otomatik ticket oluşturabilir. Model düzenli olarak gerçek business impact ile kalibre edilmelidir.

404 Risk Skoru

404 risk skoru traffic weight, SEO value, commercial value, internal-link severity, frequency ve user impact gibi bileşenleri bir araya getirir. Amaç yüz binlerce URL arasında önce hangi problemlerin çözülmesi gerektiğini belirlemektir. Risk skoru tek başına redirect kararı vermez. Yalnızca operasyon önceliğini belirler. Yüksek riskli URL'nin yine de gerçek karşılığı yoksa doğru karar 404 olarak kalabilir.

Traffic Weight

Human session hacmi normalize edilerek puana eklenir. Bot trafik çıkarılır. Son dönem trendi ayrıca ağırlıklandırılabilir. Sezonluk ürünlerde geçen yıl aynı dönem karşılaştırması yapılabilir. Trafik hacmi çözüm aciliyetini gösterir.

SEO Value

Organic clicks, impressions ve backlink kalitesi SEO value oluşturabilir. Tek bir metriğe bağlı kalınmamalıdır. Query çeşitliliği eski sayfanın talep genişliğini gösterir. Index durumu da değerlendirilir. SEO value yüksek olduğunda mapping review öncelik kazanır.

Commercial Value

Geçmiş revenue ve ürün marjı ticari değeri gösterir. Recovered revenue verisi modelin gelecekteki tahminini iyileştirebilir. Yüksek değer tek başına alakasız redirect üretmez. Yalnızca problemi daha hızlı ele alma gerekçesidir. Commercial ve relevance modelleri ayrı tutulmalıdır.

Internal-Link Severity

Sitewide linkler yüksek severity taşır. Tek source düşük olabilir. Source sayfasının trafik değeri de dikkate alınabilir. Broken navigation link kritik kabul edilir. Severity otomatik crawler verisinden hesaplanabilir.

Frequency

Request frequency sürekli veya ani olabilir. Ani artış incident sinyali taşır. Uzun süre düşük frekans normal background noise olabilir. Bot classification uygulanmalıdır. Frequency zaman serisi baseline ile karşılaştırılmalıdır.

User Impact

Exit rate, support complaint ve failed purchase flow kullanıcı etkisini gösterir. Checkout veya account route 404'leri ürün sayfasından farklı öncelik taşır. Mobile kullanıcı etkisi ayrıca incelenebilir. User impact qualitative verilerle de desteklenebilir. Score bu bilgiyi normalize eder.

Priority

Final priority score backlog sırasını belirler. P0 deployment regression, P1 yüksek trafik broken route gibi seviyeler tanımlanabilir. Her seviyenin response süreci bulunmalıdır. Dashboard owner ekibi gösterir. Çözüm sonrası score kapanmalı veya düşmelidir.

Google Search Console ile 404 Yönetimi

Google Search Console e-ticaret 404 hataları SEO ve organik trafiği nasıl etkiler sorusunu anlamada önemli veri kaynaklarından biridir. Page Indexing içindeki Not Found ve Soft 404 raporları arama motorunun gördüğü örnekleri gösterir. URL Inspection belirli bir sayfanın durumunu kontrol etmeye yardımcı olur. Ancak Search Console bütün gerçek kullanıcı 404'lerini göstermez. Bu nedenle server log ve analytics ile birlikte kullanılmalıdır.

Page Indexing

Page Indexing raporu indekslenmeyen URL nedenlerini gösterir. Not Found normal kaldırılmış URL'lerde hata olmak zorunda değildir. Kritik olan hâlâ internal link veya sitemap tarafından desteklenip desteklenmediğidir. Büyük sayılara bakıp panik yapmak yerine URL örnekleri sınıflandırılmalıdır. Trend artışı deployment veya migration ile karşılaştırılabilir.

Not Found

Not Found listesi 404 dönen URL örneklerini içerir. Her URL'nin düzeltilmesi gerekmez. Hiç var olmamış veya doğru kaldırılmış URL normaldir. Internal link alan ve organik trafik taşıyan örnekler öncelik kazanır. Sitemap'te yer alan 404'ler hızlı çözülmelidir.

Soft 404

Soft 404 raporu 200 dönen boş sayfaları veya alakasız yönlendirmeleri fark etmeye yardımcı olabilir. Template pattern aranmalıdır. Aynı route binlerce URL'yi etkiliyorsa tek tek değil sistem düzeyinde çözüm gerekir. Response header manuel doğrulanmalıdır. Fix sonrası URL Inspection kullanılabilir.

URL Inspection

URL Inspection belirli adresin indeks ve crawl durumunu incelemeyi sağlar. Kritik mapping veya soft 404 düzeltmelerinde faydalıdır. Tek URL sonucu bütün siteyi temsil etmez. Route seviyesinde otomatik test yine gereklidir. Search Console doğrulaması production davranışını tamamlar.

Internal Link Kaynaklarını Bulmak

Search Console bazı keşif sinyalleri sağlayabilir ancak source link analizi için crawler ve server log daha doğrudan yöntemdir. 404 URL internal referrer alıyorsa kaynak sayfa bulunabilir. Link doğrudan güncellenmelidir. Redirect varsa bile broken internal link temizlenmelidir. Böylece bot yeni URL'yi doğrudan tarar.

Fix Sonrası Doğrulama

Düzeltme production'da status code ve destination açısından kontrol edilmelidir. Search Console validation süreci başlatılabilir. Sitemap ve internal links de gözden geçirilmelidir. Bir URL düzelirken aynı pattern altındaki diğerleri unutulmamalıdır. Regression test fix'i kalıcı hâle getirir.

Server Log Analizi Neden Gereklidir?

Server log, botların ve gerçek kullanıcıların sunucuya yaptığı istekleri doğrudan gösterir. Search Console'da görünmeyen URL'ler, yüksek frekanslı broken path'ler ve bot noise bu veride bulunabilir. Googlebot requests ile human requests ayrı segmentlenebilir. Log analizi özellikle migration ve deployment sonrası ilk saatlerde güçlü erken uyarı sağlar. E-ticaret sitesi teknik SEO ve 404 hata optimizasyonu hizmeti veren bir ekibin yalnızca Search Console ekranına bakması bu nedenle yeterli değildir.

Googlebot Requests

Googlebot hangi eski URL'leri hâlâ tarıyor görülebilir. Yüksek frekans internal link veya güçlü external backlink sinyali olabilir. Bot doğrulaması yapılmalıdır. Recommendation servisi bot için çalıştırılmamalıdır. Status code ve latency ayrıca izlenebilir.

Gerçek Kullanıcı Requests

Human request segmenti UX problemini doğrudan gösterir. Session ve referrer recovery analizi sağlar. Mobile browser oranı tasarım önceliğini etkileyebilir. Kişisel veri minimizasyonu uygulanmalıdır. Human 404 sessions ana dashboard metriği olabilir.

Search Console'da Görünmeyen URL'ler

Search Console örnekleme yapabilir ve bütün URL'leri göstermeyebilir. Server log gerçek request envanterini verir. Özellikle long-tail bot ve referral URL'leri burada ortaya çıkar. Log retention yeterli tarih aralığını kapsamalıdır. Çok büyük veri için aggregation pipeline kurulabilir.

Bot Noise

Rastgele path taramaları toplam 404 sayısını şişirir. User agent ve frequency ile sınıflandırma yapılabilir. Security scanner ayrı tutulmalıdır. Human metric bot noise'dan etkilenmemelidir. Ancak ani yeni bot patterni WAF için yine önemli olabilir.

High-Frequency Broken Paths

Aynı path'in çok sık 404 vermesi hızlı öncelik gerektirir. Pattern hatalı template linkinden kaynaklanabilir. Regex veya route aggregation kullanılarak path ailesi bulunabilir. Tek tek URL yerine ortak root cause çözülür. Deployment zamanıyla korelasyon yapılabilir.

404 Dashboard

İyi 404 dashboard toplam request sayısından daha fazlasını gösterir. Human 404 sessions, en çok trafik alan broken URL, internal broken link count, soft 404, redirect success, recovery rate ve recovered revenue gibi metrikler teknik ve ticari görünümü bir araya getirir. Bot trafiği ayrı katmanda izlenmelidir. Route ve source filtreleri incident analizi hızlandırır. Dashboard yalnızca rapor değil, aksiyon önceliği sağlayan operasyon aracıdır.

Toplam 404 Request

Toplam request genel hacmi gösterir. Tek başına kalite metriği değildir. Botlar sayıyı büyük ölçüde artırabilir. Baseline ve trend analizi yapılmalıdır. Ani artış incident alarmı oluşturabilir.

Human 404 Sessions

Gerçek kullanıcı oturumları ticari etkiyi daha iyi gösterir. Aynı session içindeki tekrar requestler normalize edilebilir. Source ve device segmentasyonu yapılabilir. Recovery action ile ilişkilendirilebilir. Bu metrik UX ekibi için daha anlamlıdır.

En Çok Trafik Alan Broken URL

Top broken URL listesi hızlı backlog oluşturur. Human traffic ve revenue potential birlikte gösterilebilir. Source reason kullanıcıya sunulabilir. Owner ataması dashboard'dan yapılabilir. Çözüm sonrası trend düşüşü doğrulanmalıdır.

Internal Broken Link Count

Internal broken links sitenin kontrolündeki hataları gösterir. Source sayfa sayısı ayrı metrik olabilir. Sitewide template sorunları hızla fark edilir. CI/CD ile production farkları karşılaştırılabilir. Hedef mümkün olduğunca düşük tutulmalıdır.

Soft 404

Soft 404 Search Console ve internal crawler kaynaklarından gelebilir. Route pattern bazında gruplanmalıdır. HTTP 200 + empty content kontrolleri eklenebilir. Trend deployment ile ilişkilendirilebilir. Fix sonrası validation gerekir.

Redirect Success

Redirect'in destination 200'e ulaşıp ulaşmadığı ölçülür. Chain ve loop hataları ayrı gösterilir. Hedef kaldırıldıysa success düşer. User behavior da teknik success'in yanında izlenebilir. Teknik olarak çalışan ama düşük engagement alan mappingler review gerektirir.

Recovery Rate

Recovery rate 404 oturumlarının kaçının geçerli navigation veya ürün etkileşimine geçtiğini ölçer. Tanım ekip tarafından açıkça belirlenmelidir. Search submit tek başına mı, product view mı başarı sayılacağı net olmalıdır. Teknik ve ticari recovery ayrı tutulabilir. A/B testlerde temel KPI olarak kullanılabilir.

Recovered Revenue

404 sonrası oluşan gelirin attribution modeliyle hesaplanmış değeridir. Kesin nedensellik iddiası taşımamalıdır. Test gruplarıyla incremental effect tahmini yapılabilir. Yine de önceliklendirme için güçlü göstergedir. Dashboard farklı recovery yöntemlerini karşılaştırabilir.

404 İçin Teknik KPI'lar

Teknik KPI seti 404 rate, soft 404 count, broken internal links, redirect chain count, redirect loop count, resolver latency ve recommendation availability gibi metrikleri kapsar. Bu metrikler kullanıcının göremediği ancak deneyimin güvenilirliğini belirleyen sistem sağlığını gösterir. Her KPI için baseline ve hedef aralık tanımlanabilir. Ani sapmalar alert üretebilir. Teknik metrikler UX ve ticari metriklerden ayrı fakat bağlantılı izlenmelidir.

404 Rate

404 rate toplam request veya human page view üzerinden hesaplanabilir. Hangi denominator kullanıldığı açık olmalıdır. Bot rate ayrı tutulmalıdır. Katalog büyüdükçe mutlak sayı artabilir. Oran ve trend birlikte okunmalıdır.

Soft 404 Count

Soft 404 düşük tutulmalıdır. Search Console verisi gecikmeli olabilir. Internal synthetic test daha hızlı sinyal sağlar. Route pattern bazında dağılım incelenir. Yeni frontend release sonrası artış regression gösterebilir.

Broken Internal Links

Internal broken link doğrudan kalite metriğidir. Sayı yanında source severity izlenmelidir. Sitewide template linki tek URL olsa bile yüksek etki taşır. CI/CD yeni broken link girişini engelleyebilir. Production crawl mevcut borcu takip eder.

Redirect Chain Count

Chain sayısı registry sağlığını gösterir. Maksimum hop ayrı metrik olabilir. Migration sonrası geçici artış görülebilir. Scheduled audit chain flattening yapabilir. Internal linkler final hedefe güncellenmelidir.

Redirect Loop Count

Loop ideal olarak sıfır olmalıdır. Yeni kayıt oluşturulurken prevention check yapılabilir. Production'da tespit edilen loop incident sayılmalıdır. Browser error ve log patternleri alarm üretebilir. Registry graph analizi düzenli çalıştırılmalıdır.

Resolver Latency

404 resolver kullanıcıyı bekletmemelidir. P50, P95 ve P99 latency izlenebilir. Legacy lookup ve recommendation süreleri ayrı ölçülmelidir. Bot isteklerinde lightweight path kullanılmalıdır. Yavaş servisler circuit breaker ile korunabilir.

Recommendation Availability

Recommendation API availability 404 page availability'den ayrı olmalıdır. Servis kapalıyken static fallback çalışır. Success rate ve timeout oranı ölçülür. Feature degrade olduğunda alert düşük severity taşıyabilir. Kullanıcı yine site içinde ilerleyebilmelidir.

404 İçin UX KPI'ları

UX KPI'ları bounce veya exit rate, search usage, suggested product CTR, category CTR, recovery rate ve time to recovery gibi göstergeleri kapsar. Tek bir metriği başarı olarak görmek yanıltıcıdır. Örneğin düşük exit rate kullanıcı sayfada uzun süre kaybolduğu için oluşabilir. Time to recovery ve product view oranı daha fazla bağlam sağlar. Mobil ve masaüstü segmentleri ayrı incelenmelidir.

Bounce / Exit Rate

Yüksek exit kullanıcıların devam yolu bulamadığını gösterebilir. Ancak bazı 404'ler zaten düşük niyetli bot veya dış trafik olabilir. Human session filtresi uygulanmalıdır. Source segmentasyonu önemlidir. A/B test değişikliklerin gerçek etkisini gösterebilir.

Search Usage

Search usage kullanıcının aktif recovery denediğini gösterir. Çok yüksek oran da önerilerin yetersiz olduğunu gösterebilir. Query success oranı birlikte izlenmelidir. Pre-filled search ile empty search karşılaştırılabilir. Zero-result oranı ayrı KPI'dır.

Suggested Product CTR

CTR önerilerin relevance seviyesini gösterir. Ancak click sonrası hızlı geri dönüş de ölçülmelidir. Yüksek CTR düşük conversion ile birleşirse hedefler yanlış olabilir. Position bias dikkate alınmalıdır. Recommendation reason bazında analiz yapılabilir.

Category CTR

Kategori linkleri broad recovery sağlar. Leaf category ve top category performansı karşılaştırılabilir. Çok düşük CTR kategori önerilerinin ilgisiz olduğunu gösterebilir. Mobile placement sonucu etkileyebilir. Category click sonrası product view izlenmelidir.

Recovery Rate

Recovery rate kullanıcıların geçerli site deneyimine geri dönme oranıdır. Başarı tanımı standardize edilmelidir. Product view güçlü teknik recovery sayılabilir. Add-to-cart daha ticari seviyedir. Farklı ekipler aynı isim altında farklı formül kullanmamalıdır.

Time to Recovery

Kullanıcının 404 view ile geçerli hedef arasındaki süresidir. Daha kısa süre genellikle daha iyi yönlendirme anlamına gelir. Ancak otomatik yanlış redirect yapay olarak süreyi düşürebilir. Hedef engagement ile birlikte değerlendirilmelidir. Mobile performance süreyi etkileyebilir.

404 İçin Ticari KPI'lar

Ticari KPI'lar recovered product views, recovered add-to-cart, recovered checkout, recovered orders, recovered revenue ve revenue per 404 session gibi ölçümleri kapsar. Bu metrikler 404 optimizasyonunun yalnızca SEO bakım işi olmadığını gösterir. Attribution yöntemi açık tanımlanmalıdır. Kullanıcı birkaç farklı sayfa gezdikten sonra satın alırsa recovery etkisi nasıl paylaştırılacak belirlenmelidir. A/B test daha güvenilir incremental revenue tahmini sağlayabilir.

Recovered Product Views

404 sonrası geçerli ürün görüntüleme ilk ticari adımdır. Recommendation, search ve category kaynakları ayrı etiketlenebilir. Hedef PDP 200 dönmelidir. Aynı ürünün tekrar görüntülenmesi deduplicate edilebilir. Bu metrik recovery relevance hakkında güçlü sinyal verir.

Recovered Add-to-Cart

Sepete ekleme kullanıcı niyetinin devam ettiğini gösterir. 404 source session ile ilişkilendirilir. Hangi öneri algoritmasının daha çok add-to-cart ürettiği görülebilir. Ürün fiyat segmentleri ayrı incelenebilir. Bot trafik bu metrikte zaten büyük ölçüde elenir.

Recovered Checkout

Checkout daha güçlü conversion aşamasıdır. 404 recovery'nin ticari değerini doğrular. Checkout abandonment farklı problem alanıdır. Source recovery method korunmalıdır. Channel attribution ile çakışma kuralları belirlenmelidir.

Recovered Orders

Sipariş sayısı doğrudan sonuç verir. Aynı session içinde birden fazla 404 varsa attribution kuralı gerekir. Sipariş iptalleri istenirse net sonuçta dikkate alınabilir. Experiment group bazında fark ölçülebilir. Bu metrik üst yönetime anlatması kolay KPI'dır.

Recovered Revenue

Gelir, sipariş değerlerini recovery attribution ile toplar. Tam revenue yerine incremental estimate kullanmak daha doğru olabilir. A/B control group farkı hesaplamayı güçlendirir. Seasonal etkiler kontrol edilmelidir. Yine de dashboard operasyon önceliği için önemli gösterge sunar.

Revenue per 404 Session

Revenue per 404 session farklı trafik hacimlerini normalize eder. Dynamic ve static 404 varyantları karşılaştırılabilir. Bot sessionlar denominator'a dahil edilmemelidir. Product category mix sonucu etkileyebilir. Segment bazlı kıyas daha sağlıklı olur.

404 Recovery Rate Nasıl Hesaplanır?

Recovery rate hesaplamadan önce recovery event tanımı belirlenmelidir. Başarılı navigation, product interaction ve conversion farklı seviyeler olabilir. Örneğin 404 sonrası herhangi bir 200 sayfaya geçiş teknik recovery, ürün görüntüleme nitelikli recovery ve satın alma ticari recovery olarak ayrılabilir. Bu ayrım farklı ekiplerin aynı metriği yanlış yorumlamasını önler. Formül human 404 sessions üzerinden kurulmalıdır.

Recovery Event Tanımı

Event açık ve tekrar üretilebilir olmalıdır. Search click, category click veya product suggestion click ayrı ham olaylardır. Bunların hangisinin recovery sayılacağı dokümante edilir. Aynı session içindeki tekrarlar deduplicate edilebilir. Event version değişiklikleri raporlarda izlenmelidir.

Başarılı Navigation

Kullanıcının 404 sonrası geçerli sayfaya ulaşması teknik recovery sayılabilir. Home tıklaması da bu kapsama girebilir. Fakat ticari değer seviyesi düşük olabilir. Route type sonucu sınıflandırır. Navigation success kullanıcıyı artık broken URL'den çıkarmıştır.

Product Interaction

PDP view, variant seçimi veya wishlist daha güçlü recovery sinyalidir. Kullanıcı yeniden ürün bağlamına girmiştir. Recommendation relevance burada test edilir. Search sonuç tıklaması da product interaction'a dönüşebilir. Funnel katmanları ayrı tutulmalıdır.

Conversion

Add-to-cart, checkout ve purchase ticari recovery seviyeleridir. Attribution window tanımlanmalıdır. Session-based model basit başlangıçtır. Uzun karar döngülü ürünlerde daha uzun pencere gerekebilir. Deney grupları nedenselliği değerlendirmeye yardımcı olur.

Teknik Recovery ve Ticari Recovery'yi Ayırmak

Kullanıcının ana sayfaya dönmesi teknik olarak recovery olabilir ama satış üretmeyebilir. Bu nedenle iki ayrı oran raporlanmalıdır. Teknik rate UX akışını, ticari rate business etkisini gösterir. İki metrik birlikte okunduğunda yanlış optimizasyon önlenir. Yalnızca page exit düşürmeye odaklanmak yeterli değildir.

A/B Test ile 404 Optimizasyonu

404 tasarımı varsayımlarla değil deneylerle geliştirilebilir. Static vs Dynamic, Search vs No Search, Bestseller vs Personalized, 3 ürün vs 6 ürün, copy ve CTA varyasyonları test edilebilir. Testin ana metriği yalnızca click değil recovery ve mümkünse ticari dönüşüm olmalıdır. Statistical significance yanında test süresi ve trafik kalitesi dikkate alınmalıdır. Bot trafiği experiment sample'a dahil edilmemelidir.

Static vs Dynamic

Static 404 kontrol grubu olabilir. Dynamic varyant URL context'e göre öneriler sunar. Recovery rate ve revenue per session karşılaştırılır. Latency etkisi de izlenir. Dynamic sayfa daha çok gelir sağlarken performansı ciddi bozuyorsa mimari optimizasyon gerekir.

Search vs No Search

Search box'ın gerçek etkisi ölçülebilir. Search olmayan varyant kategori ve ürün önerilerine dayanabilir. Kullanıcı segmentine göre sonuç değişebilir. Generic 404'te search daha değerli olabilir. Product-context 404'te successor suggestion daha güçlü olabilir.

Bestseller vs Personalized

Generic bestseller basit kontrol grubudur. Personalized recommendation daha ilgili sonuç verebilir. Privacy ve consent koşulları test tasarımında korunmalıdır. CTR yanında add-to-cart karşılaştırılmalıdır. Kişiselleştirme maliyeti de business sonucuna eklenmelidir.

3 Ürün vs 6 Ürün

Daha fazla seçenek her zaman daha iyi değildir. Üç güçlü ürün karar süresini kısaltabilir. Altı ürün farklı ihtiyaçları kapsayabilir. Mobil ve desktop sonuçları farklı olabilir. Test time to recovery ve conversion metriklerini birlikte izlemelidir.

Copy

Mesaj tonu kullanıcının devam davranışını etkileyebilir. Kısa açıklama, ürün bağlamlı açıklama ve generic mesaj test edilebilir. Kullanıcıyı suçlayan ifadelerden kaçınılmalıdır. Mizah marka tonuna bağlıdır. Copy testinde diğer tasarım değişkenleri mümkün olduğunca sabit tutulmalıdır.

CTA

Primary CTA metni ve konumu test edilebilir. “Ürünleri Gör”, “Benzer Ürünlere Bak” veya “Arama Yap” gibi aksiyonlar bağlama göre değişir. CTA'nın sonucu açık olmalıdır. Mobil touch target korunmalıdır. CTR yanında downstream conversion izlenmelidir.

Statistical Significance

Düşük trafik alan 404'lerde anlamlı test sonucu almak zor olabilir. Test erken durdurulmamalıdır. Bot ve anomaly dönemleri sample'dan ayrılabilir. Büyük kampanya günleri normal trafiği temsil etmeyebilir. İstatistiksel sonuç business effect size ile birlikte değerlendirilmelidir.

404 Sayfasında Performance

404 sayfası ana sayfadan daha ağır olmamalıdır. Kullanıcı zaten başarısız bir URL deneyimi yaşamıştır ve ikinci kez uzun yükleme beklememelidir. Recommendation API latency, image optimization, lazy loading, cache ve Core Web Vitals metrikleri izlenmelidir. Kritik HTML ve search hızlı gelmeli, ürün önerileri gerekirse progressive enhancement olarak sonradan eklenmelidir. Performance problemi recovery oranını doğrudan düşürebilir.

Hata Sayfası Ana Sayfadan Daha Ağır Olmamalı

404 template gereksiz carousel ve medya taşımamalıdır. Ana navigation ve recovery araçları önceliklidir. JS bundle mümkün olduğunca küçük tutulabilir. Shared site shell zaten cache'den gelebilir. Page weight ayrı ölçülmelidir.

Recommendation API Latency

Recommendation backend gecikmesi ilk render'ı bloklamamalıdır. Timeout kısa tutulabilir. Skeleton yerine static fallback göstermek daha hızlı olabilir. P95 latency izlenmelidir. Servis yavaşsa circuit breaker devreye girmelidir.

Image Optimization

Ürün kartı görselleri uygun boyutta servis edilmelidir. Modern formatlar ve responsive image kullanılabilir. Çok büyük hero görsel gereksizdir. Placeholder layout shift'i azaltabilir. Alt metin erişilebilirliği desteklemelidir.

Lazy Loading

İlk ekran dışında kalan ürün görselleri lazy load edilebilir. Search ve primary CTA geciktirilmemelidir. Lazy component failure temel sayfayı etkilememelidir. Mobil ağ koşulları test edilmelidir. Interaction sonrası gerekli içerik öncelikli yüklenebilir.

Cache

Static template uzun süre cache edilebilir. Resolver mapping cache ile hızlanır. Personalized içerik shared cache'e karışmamalıdır. Stok ve fiyat alanları daha kısa TTL kullanabilir. Cache hit ratio performance dashboard'da izlenebilir.

Core Web Vitals

404 sayfaları da gerçek kullanıcı deneyiminin parçasıdır. LCP, INP ve CLS metrikleri izlenebilir. Trafik düşükse field data sınırlı olabilir. Synthetic test destekleyebilir. Hata sayfasının düşük öncelikli olduğu varsayımı kullanıcı kaybını büyütebilir.

404 Sayfasında Accessibility

Erişilebilirlik hata sayfasında da normal ürün sayfaları kadar önemlidir. Doğru heading yapısı, klavye navigasyonu, screen reader mesajı, focus state, color contrast ve anlaşılır CTA metinleri kullanıcıların recovery araçlarına ulaşmasını sağlar. Hata mesajı yalnızca renk veya görsele bağlı olmamalıdır. Search alanı doğru label'a sahip olmalıdır. Dynamic recommendation sonradan yüklendiğinde screen reader kullanıcılarına gereksiz tekrar yaratmamalıdır.

Doğru Heading Yapısı

Sayfada mantıklı başlık hiyerarşisi kullanılmalıdır. H1 hata bağlamını anlatabilir. Ürün önerileri ve kategoriler alt başlıklarla ayrılabilir. Yalnızca görsel boyut için heading seçilmemelidir. Screen reader kullanıcıları yapıyı kolayca tarayabilmelidir.

Klavye Navigasyonu

Bütün link ve inputlar klavyeyle erişilebilir olmalıdır. Focus sırası görsel sırayla uyumlu olmalıdır. Carousel varsa klavye kontrolü sağlanmalıdır. Focus trap oluşmamalıdır. Search submit sadece mouse gerektirmemelidir.

Screen Reader Mesajı

Hata durumu kısa ve açık biçimde okunmalıdır. Teknik kod yerine kullanıcı anlamı öne çıkarılabilir. Dynamic recommendation yüklenmesi aria-live ile kontrollü duyurulabilir. Çok fazla değişiklik spam oluşturmamalıdır. Test gerçek screen reader ile yapılmalıdır.

Focus State

Focus görünür olmalıdır. Marka tasarımı focus outline'ı kaldırmamalıdır. Primary CTA ve search kolay fark edilmelidir. Keyboard-only test uygulanabilir. Kontrast erişilebilirlik kriterlerini karşılamalıdır.

Color Contrast

Hata mesajı ve CTA metinleri yeterli kontrasta sahip olmalıdır. Soluk gri metin okunabilirliği düşürebilir. Disabled add-to-cart gibi state'ler yalnızca renkle anlatılmamalıdır. Ürün kartı fiyat ve stok bilgisi de erişilebilir olmalıdır. Tasarım sistemi merkezi token kullanabilir.

Anlaşılır CTA Metinleri

“Tıkla” gibi bağlamsız metin yerine hedefi anlatan ifade kullanılmalıdır. Screen reader link listesinden anlam çıkarabilmelidir. CTA kısa olabilir. Product suggestion linki ürün adını taşıyabilir. Aynı metin farklı hedefler için tekrar kullanılmamalıdır.

Mobile E-Ticarette 404 UX

Mobil kullanıcıların 404 sayfasında daha az ekran alanı ve çoğu zaman daha yavaş bağlantı koşulları vardır. Search'ün görünürlüğü, touch target, ürün carousel'i, bottom navigation, mobile performance ve tek bir primary action bu nedenle daha önemli hâle gelir. Masaüstünde çalışan kalabalık düzen mobilde karar vermeyi zorlaştırabilir. İlk ekran kullanıcının ne olduğunu ve ne yapabileceğini açıkça göstermelidir. Dynamic içerik düşük kaliteli ağda da güvenli fallback ile çalışmalıdır.

Search'ün Görünürlüğü

Search alanı mobilde kolay bulunmalıdır. Sayfanın en altına gömülmemelidir. Klavye açıldığında layout bozulmamalıdır. Input tipi ve autocomplete ayarları uygun seçilmelidir. Pre-fill metni kolayca temizlenebilmelidir.

Touch Target

CTA ve ürün kartları yeterli dokunma alanına sahip olmalıdır. Linkler birbirine fazla yakın olmamalıdır. Carousel kontrolleri küçük ikonlara dönüşmemelidir. Thumb reach dikkate alınabilir. Accessibility testleri gerçek cihazda yapılmalıdır.

Ürün Carousel'i

Carousel yatay alanı verimli kullanabilir. Ancak kullanıcı ilk üründen fazlası olduğunu anlayabilmelidir. Swipe yanında erişilebilir kontrol sunulmalıdır. Çok fazla kart yüklemek performance'ı düşürür. İlk birkaç yüksek relevance ürünü göstermek yeterlidir.

Bottom Navigation

Site normalde bottom navigation kullanıyorsa 404 sayfasında da korunabilir. Kullanıcı home, search veya kategoriye hızlı döner. Hata sayfasına özel farklı navigation öğrenmek zorunda kalmaz. Safe area ve device viewport test edilmelidir. Primary CTA ile çakışmamalıdır.

Mobile Performance

Düşük bandwidth ve orta sınıf cihazlar test edilmelidir. Büyük recommendation bundle'ları gecikme yaratabilir. Static HTML önce gelmelidir. Görseller responsive olmalıdır. Third-party scriptler 404 sayfasında minimumda tutulabilir.

Tek Bir Primary Action

Mobilde ilk ekran için tek primary aksiyon karar vermeyi kolaylaştırır. Product successor varsa bu öne çıkarılabilir. Generic 404'te search iyi varsayılandır. Diğer seçenekler aşağıda secondary olarak kalır. A/B test gerçek davranışı doğrulamalıdır.

Çok Dilli E-Ticaret Sitelerinde 404

Çok dilli sitelerde locale detection, dil bazlı 404, hreflang, ülkeye göre ürün bulunabilirliği ve cross-market redirect riskleri ayrıca değerlendirilmelidir. Bir ürün Türkiye kataloğunda bulunurken başka ülkede kaldırılmış olabilir. Kullanıcıyı otomatik olarak başka ülke mağazasına göndermek fiyat, teslimat ve dil beklentisini bozabilir. 404 sayfası mevcut locale içinde recovery sunmalıdır. Cross-market alternatif ancak kullanıcının seçebileceği açık seçenek olarak gösterilebilir.

Locale Detection

Locale URL, cookie veya site seçimi üzerinden belirlenebilir. 404 template doğru dilde gösterilmelidir. Yanlış locale fallback kullanıcıyı daha fazla şaşırtır. URL'deki locale geçersizse ayrı routing policy uygulanabilir. Search önerileri aynı market kataloğundan gelmelidir.

Dil Bazlı 404

Hata mesajı seçili dilde olmalıdır. Translation fallback zinciri bulunabilir. Lokalize route dictionary eski URL'leri çözümleyebilir. Recommendation ürün isimleri doğru dilde gösterilmelidir. Dil eksikliği nedeniyle yanlış 200 shell üretilmemelidir.

Hreflang

404 sayfaları için hreflang yönetimi geçerli ürün sayfalarından farklı düşünülmelidir. Kaldırılmış URL başka dilde yaşıyorsa kullanıcıya seçenek sunulabilir. Ancak bulunamayan sayfayı sırf hreflang partneri var diye otomatik cross-market redirect etmek doğru olmayabilir. Market availability kontrol edilmelidir. Geçerli canonical ve hreflang kümeleri düzenli audit edilmelidir.

Ürün Bir Ülkede Var Diğerinde Yoksa

Region-specific catalog state ayrı tutulmalıdır. Bir markette REMOVED olan ürün başka markette ACTIVE olabilir. Kullanıcı teslimat alamayacağı markete sessizce gönderilmemelidir. “Bu ürün başka bölgede mevcut” gibi seçenek sunulabilir. Kullanıcı ülke değiştirmeyi kendisi seçmelidir.

Cross-Market Redirect Riskleri

Otomatik ülke redirectleri dil ve para birimi değişimine yol açabilir. Kullanıcı checkout sırasında teslimat kısıtıyla karşılaşabilir. SEO tarafında farklı locale URL'leri karışabilir. Cross-market geçiş açık kullanıcı aksiyonuna bırakılmalıdır. Geo sinyali yalnızca suggestion üretmek için kullanılabilir.

Multi-Store ve Marketplace Yapılarında 404

Marketplace yapılarında ürün ile satıcı teklifini birbirinden ayırmak gerekir. Seller listing kaldırılmış olabilir fakat global product hâlâ başka satıcılar tarafından sunuluyor olabilir. Store-specific catalog, seller product removal, marketplace listing expiry, global product ile merchant offer ayrımı, seller alternative ve marketplace alternative state'leri bu nedenle ayrı modellenmelidir. Tek bir satıcı kayboldu diye global ürün URL'sinin 404 olması gerekmez. Resolver hangi entity'nin URL üzerinde temsil edildiğini bilmelidir.

Store-Specific Catalog

Her store farklı ürün envanteri taşıyabilir. Global URL store context'e göre farklı availability gösterebilir. Ürün store'da yoksa başka store'a otomatik geçiş yapılmamalıdır. Yerel alternatifler gösterilebilir. URL state market veya store scope ile birlikte saklanmalıdır.

Seller Product Removal

Satıcı listing'i kaldırdığında marketplace ürün sayfası yaşamaya devam edebilir. Diğer satıcı teklifleri gösterilebilir. URL doğrudan seller listing'i temsil ediyorsa yeni seller alternatifi suggestion olarak sunulabilir. Otomatik 301 yalnızca entity anlamı korunuyorsa yapılmalıdır. Seller kimliği kullanıcı beklentisinin parçasıdır.

Marketplace Listing Expiry

Listing süresi dolduğunda inventory state güncellenmelidir. Search index eski listing'i göstermemelidir. Global product aktifse kullanıcı oraya geçebilir. Ayrı listing URL için 404 veya uygun redirect policy uygulanabilir. Expiry event bütün sistemlere yayılmalıdır.

Global Product vs Merchant Offer

Global product ürünün kendisini, merchant offer satıcının teklifini temsil eder. Bu ayrım HTTP davranışını değiştirir. Offer kaybolduğunda product yaşamaya devam edebilir. Structured data da güncel offer setini göstermelidir. Resolver entity type'a göre karar verir.

Seller Alternative

Aynı ürün başka satıcıda varsa kullanıcıya alternatif teklif gösterilebilir. Fiyat ve teslimat koşulları açıkça belirtilmelidir. Kullanıcı satıcı tercihine bağlıysa otomatik geçiş yapılmamalıdır. Marketplace güven sinyalleri korunmalıdır. Recommendation seller availability ile filtrelenir.

Marketplace Alternative

Ürün tamamen kaldırılmışsa benzer marketplace ürünleri önerilebilir. Global successor relation varsa önceliklidir. Category ve attribute similarity kullanılabilir. Sponsorlu ürün relevance koşulunu geçmelidir. Kullanıcının aradığı ürün bağlamı korunmalıdır.

Headless Commerce Mimarisinde 404

Headless commerce yapılarında storefront, commerce API, CMS, search engine, recommendation engine ve edge farklı sistemlerdir. 404 kararının yalnızca frontend component'e bırakılması bu nedenle risklidir. Commerce API ürün state'ini, CMS landing page state'ini ve redirect registry legacy URL ilişkisini bilir. 404 resolver bu bilgileri tek nihai kararda birleştirebilir. Hangi katmanın karar verdiği açık olduğunda soft 404 ve çelişkili redirect problemleri azalır.

Frontend Storefront

Storefront kullanıcı arayüzünü üretir. Kendi başına ürün lifecycle tahmini yapmamalıdır. Resolver response'unu kullanır. Recommendation başarısızsa fallback gösterir. HTTP response SSR veya edge ile doğru status'ta döner.

Commerce API

Commerce API ürün kimliği ve state'i için ana kaynaktır. Null yerine anlamlı lifecycle state döndürmesi yararlıdır. Successor ve archive ilişkileri API'de bulunabilir. Market availability ayrı alan olabilir. Resolver bu veriyi policy ile yorumlar.

CMS

CMS kampanya ve editorial route'ları yönetir. Bir route kaldırıldığında redirect veya expiry metadata taşıyabilir. Headless frontend bu state'i doğrudan bilmeyebilir. Resolver CMS lookup yapabilir. Büyük hacimde registry cache kullanmak performansı artırır.

Search Engine

Search engine recovery adayları bulabilir. Fakat lifecycle için source of truth değildir. Index stale olabilir. Sonuçlar commerce API ile doğrulanmalıdır. Search index removal eventleri düzenli reconcile edilmelidir. Search click 404 oranı kalite KPI'ıdır.

Recommendation Engine

Recommendation engine alternatif ürünleri sıralar. Resolver kararından sonra enhancement olarak çağrılabilir. Hedeflerin active ve saleable olması gerekir. Timeout sayfayı 500'e çevirmemelidir. Cache ve circuit breaker kullanılabilir.

Edge

Edge known redirectleri hızlı uygular. Generic 404'leri cache edebilir. Çok ağır catalog logic edge'e taşınmamalıdır. Registry snapshot veya KV storage kullanılabilir. Data freshness eventlerle korunmalıdır.

Hangi Katman 404 Kararını Vermeli?

Nihai HTTP kararını response üretmeden önce bilgiye erişebilen server veya edge katmanı vermelidir. Business lifecycle kararı merkezi policy veya resolver servisten gelmelidir. Frontend yalnızca UI state yönetmelidir. Bu ayrım test edilebilirliği artırır. Tek bir source of truth çelişkili davranışı azaltır.

404 Resolver Service Tasarımı

404 Resolver Service requested URL'yi alır, route classification yapar, legacy URL lookup çalıştırır, product lifecycle ve redirect registry kontrol eder, gerekirse recommendation lookup yapar ve final response decision üretir. Servisin amacı her isteği yapay olarak kurtarmak değildir. Bazen doğru karar 404'tür. Resolver bunu açık biçimde söylemeli ve frontend'e recovery context döndürmelidir. Nihai response 301, 200 PDP, 404 veya 410 gibi deterministik state'lerden biri olmalıdır.

Requested URL

Input normalize edilmeden önce güvenlik kontrolünden geçmelidir. Query parameter'lar whitelist mantığıyla parse edilebilir. URL length sınırı uygulanabilir. Raw ve normalized değer debugging için ayrı tutulur. Kullanıcı girdisi doğrudan response HTML'e yazılmamalıdır.

Route Classification

İstek product, category, campaign veya unknown route olarak sınıflandırılır. Route type lookup stratejisini belirler. Product route için SKU resolver çalışabilir. Unknown route generic 404'e hızlı geçebilir. Classification latency düşük olmalıdır.

Legacy URL Lookup

Redirect registry exact source match için ilk kaynak olabilir. Old slug dictionary de kontrol edilir. Exact match deterministik sonuç sağlar. Destination health ve state doğrulanır. Bulunamazsa lifecycle veya semantic adımlara geçilir.

Product Lifecycle Lookup

Eski SKU çözümlendiyse lifecycle state alınır. OUT_OF_STOCK, REPLACED veya REMOVED davranışı farklıdır. Successor relation varsa confidence yükselir. Region state ayrıca değerlendirilebilir. Lifecycle verisi cache edilebilir.

Redirect Lookup

Registry'de aktif mapping varsa final destination çözülür. Chain varsa mümkünse registry düzeltmesi yapılmalıdır. Runtime sonsuz loop'a karşı hop limiti uygular. Hedef erişilebilir değilse redirect kullanılmaz. Monitoring broken mapping eventi üretir.

Recommendation Lookup

Redirect bulunmadığında recommendation opsiyonel olarak çağrılır. URL context ve legacy product feature gönderilebilir. API timeout kısa tutulur. Sonuç relevance ve stock filtresinden geçer. Başarısızlık generic 404 fallback'e döner.

Final Response Decision

Resolver explicit response type döndürmelidir. REDIRECT_301, PRODUCT_200, NOT_FOUND_404 veya GONE_410 gibi değerler kullanılabilir. Recovery context ayrı payload olabilir. Frontend bu kararı değiştirmemelidir. Analytics reason code'u loglamalıdır.

404 Resolver Karar Ağacı

Karar ağacı ekiplerin aynı senaryoya aynı cevabı vermesini sağlar. Önce URL taşındı mı sorulur, ardından ürünün geçici stok durumu ve halef ilişkisi değerlendirilir. Güçlü yeni karşılık varsa 301, geçici stok yoksa 200 PDP ve karşılık yoksa 404 veya 410 ile dynamic recovery uygulanabilir. Bu akış kod, dokümantasyon ve test senaryosu olarak aynı kaynaktan üretilebilir. Böylece product, SEO ve engineering ekiplerinin kuralları ayrışmaz.

URL Taşındı mı?

Exact mapping varsa en net senaryodur. Aynı kaynak yeni URL'de bulunuyorsa redirect gerekir. Registry hedefi doğrular. Chain olmamalıdır. Mapping reason açıkça saklanmalıdır.

Evet → 301

Kalıcı taşınmada HTTP 301 kullanılır. Location final URL'yi göstermelidir. Sitemap eski URL'yi içermemelidir. Internal links yeni adrese güncellenmelidir. Redirect automated contract test ile doğrulanmalıdır.

Ürün Geçici Olarak Stokta Yok mu?

Stok state commerce backend'den alınır. Ürün geri gelecekse URL geçerlidir. PDP içeriği korunur. Kullanıcıya stok mesajı ve alternatifler gösterilebilir. Silme veya redirect yapılması gerekmez.

Evet → 200 PDP

Sayfa gerçek ürün bilgisi sunduğu için 200 döner. Structured data OutOfStock durumunu yansıtır. Sepete ekleme uygun biçimde devre dışı kalır. Back-in-stock CTA eklenebilir. Sitemap politikası ürünün indeksleme hedeflerine göre sürer.

Doğrudan Halef Ürün Var mı?

Lifecycle state successor relation taşıyabilir. Exact successor otomatik relevance skorunu yükseltir. Hedef active olmalıdır. Birden fazla successor varsa seçim zorlaşır. Kullanıcıya öneri sunmak daha güvenli olabilir.

Evet → Relevance Kontrolü

Successor etiketi tek başına kör redirect üretmemelidir. Marka, kategori, kullanım amacı ve ürün tipi doğrulanır. Hedef başka markette değilse kullanılabilir. Score threshold uygulanır. Yüksek değerli URL manual review'a alınabilir.

İlgili Karşılık Yeterince Güçlü mü?

Relevance model yüksek confidence üretiyorsa redirect güvenlidir. Model reason code sağlamalıdır. Exact SKU mapping en güçlü sinyaldir. Semantic similarity tek başına yeterli değildir. Business rule filtresi son kontrolü yapar.

Evet → 301

Yüksek güvenli kalıcı eşleşme 301 ile uygulanabilir. Hedef tek hop olmalıdır. Registry mapping oluşturur. Search index ve sitemap güncellenir. Kullanıcı doğrudan yeni ürüne ulaşır.

Karşılık Yok mu?

Gerçek hedef yoksa sistem redirect üretmeye zorlanmamalıdır. Kullanıcıya açık hata mesajı gösterilir. Search ve kategori fallback sunulur. Legacy context varsa benzer ürün önerileri gösterilebilir. HTTP sinyali gerçek state'i korur.

404 / 410 + Dynamic Recovery

Policy'ye göre 404 veya 410 döndürülür. Dynamic recovery kullanıcıya ürün veya arama seçenekleri sunar. Recommendation servisi başarısız olsa bile basic navigation çalışır. URL sitemap'ten çıkarılır. Recovery funnel analytics ile ölçülür.

404 Resolver İçin Confidence Threshold

Confidence threshold otomatik davranışın sınırını belirler. High Confidence Automatic Redirect, Medium Confidence Suggested Alternatives ve Low Confidence Search + Category Recovery şeklinde üç seviye pratik bir başlangıçtır. Eşikler yalnızca model skoruna bakılarak belirlenmemelidir. Yanlış redirect maliyeti, kullanıcı davranışı ve ürün kategorisi hesaba katılmalıdır. A/B test confidence modelini zaman içinde kalibre etmeye yardımcı olur.

High Confidence

Exact URL registry veya açık successor relation bu seviyeye girebilir. Hedefin active state'i doğrulanır. Similarity ve business rule çelişmemelidir. Yanlış redirect olasılığı çok düşük olmalıdır. High confidence mapping otomatik olabilir.

Automatic Redirect

Automatic redirect yalnızca güçlü kanıta dayanmalıdır. 301 kalıcı davranış için kullanılır. Source ve reason loglanır. Hedef değişirse registry audit devreye girer. Kullanıcı gereksiz ara sayfa görmez.

Medium Confidence

Benzer ürün veya olası successor ancak kesin olmayan durumda medium confidence kullanılabilir. Otomatik redirect yapılmaz. Kullanıcıya birkaç güçlü seçenek gösterilir. Search fallback korunur. Click behavior score kalibrasyonuna katkı sağlar.

Suggested Alternatives

Alternatif kartları ürün adı ve temel bilgiyle sunulur. Kullanıcı seçim yapar. Stokta olmayan seçenekler filtrelenir. Çok fazla ürün gösterilmez. Suggestion CTR ve downstream conversion izlenir.

Low Confidence

URL bağlamı zayıfsa düşük confidence verilir. Rastgele path ve bilinmeyen SKU buna örnektir. Pahalı recommendation çağrısı yapılmayabilir. Generic 404 template hızlı döner. Kullanıcı search ile kendi yolunu belirler.

Search + Category Recovery

Search en güvenli fallback'tir. Ana veya tahmini kategori seçenekleri eklenebilir. Kullanıcı kontrolü korunur. Home bağlantısı da bulunabilir. Bu yaklaşım yanlış otomasyon riskini azaltır.

Confidence Modelini A/B Test ile Kalibre Etmek

Threshold farklı varyantlarda test edilebilir. Redirect sonrası bounce ve conversion karşılaştırılır. Medium confidence suggestion click behavior gerçek eşleşme kalitesini gösterir. Kategori bazlı threshold gerekebilir. Model değişiklikleri versiyonlanmalıdır.

404 Stratejisinde Canonical Ne Zaman Kullanılır?

Canonical duplicate product URL, product variant ve filter URL gibi geçerli sayfalar arasında tercih edilen adresi göstermek için kullanılır. Canonical 404'ün alternatifi değildir ve taşınmış URL için redirectin yerini tutmaz. Kaynak artık bulunamıyorsa HTTP state önce belirlenmelidir. Redirect gerçek navigasyon değiştirirken canonical arama motoruna tercih sinyali verir. İki araç farklı problemi çözer.

Duplicate Product URL

Aynı ürün birden fazla geçerli URL'den erişilebiliyorsa canonical kullanılabilir. Internal linkler tercih edilen URL'yi kullanmalıdır. Duplicate URL'leri tamamen kaldırmak mümkünse routing sadeleştirilebilir. Canonical self-consistent olmalıdır. Sitemap yalnızca canonical URL'yi göstermelidir.

Product Variant

Variant sayfaları çok benzer içerik taşıyorsa parent canonical değerlendirilebilir. Ancak her variant bağımsız arama talebi taşıyorsa farklı strateji gerekir. Kaldırılmış variant canonical ile yönetilmez. Redirect veya 404 state'i gerekir. Kullanıcı davranışı canonical'dan etkilenmez.

Filter URL

Filtre URL'leri ana kategoriye canonical verilebilir. Fakat organik landing page olan facet'ler ayrı değerlendirilmelidir. Crawl ve noindex politikası canonical'dan bağımsızdır. Sonsuz parametre üretimini canonical tek başına çözmez. Internal linking tasarımı önemlidir.

Canonical 404'ün Alternatifi Değildir

404 döndürmesi gereken sayfaya geçerli ürün canonical eklemek kaynağı taşımış olmaz. Kullanıcı hâlâ hata yaşar. Arama motoru çelişkili sinyal alabilir. Kaynak yoksa 404 veya uygun redirect seçilmelidir. Canonical yalnızca geçerli içerik ilişkilerinde kullanılmalıdır.

Redirect ile Canonical'ı Karıştırmamak

Redirect tarayıcıyı yeni URL'ye taşır. Canonical tarayıcı davranışını değiştirmez. Kalıcı URL migration için 301 tercih edilir. Duplicate erişim yolu için canonical kullanılabilir. Teknik dokümantasyon bu ayrımı açıkça göstermelidir.

Structured Data ve Kaldırılan Ürünler

Structured data ürünün availability ve offer durumunu arama motorlarına açıklamaya yardımcı olur, ancak HTTP state'in yerine geçmez. OutOfStock veya BackOrder gibi değerler gerçek PDP üzerinde kullanılabilir. Discontinued state sayfa yaşamaya devam ediyorsa içerikle uyumlu biçimde temsil edilmelidir. Kaynak tamamen kaldırılmışsa 404 sayfasına eski Product schema bırakılmamalıdır. PDP içeriği ile structured data her zaman aynı gerçeği söylemelidir.

Product Availability

Availability ürünün satın alınabilirlik durumunu yansıtır. Frontend metniyle uyumlu olmalıdır. Cache farkları çelişkili bilgi üretebilir. Structured data pipeline commerce state'ten beslenmelidir. Manual hard-coded değerler kolayca eskir.

OutOfStock

Geçici stok yokluğunda PDP 200 kalabilir. Structured data OutOfStock gösterebilir. Kullanıcıya stok bildirimi sunulabilir. Ürün sitemap politikası devam edebilir. 404 vermek gerekmez.

BackOrder

Backorder ürün satın alınabilir ancak teslim süresi farklıdır. Sayfa 200 döner. Offer bilgisi gerçek checkout davranışıyla uyumlu olmalıdır. Kullanıcı teslim beklentisini anlamalıdır. Structured data yanlış stok var izlenimi vermemelidir.

Discontinued State

Üretimden kalkmış ürün arşiv PDP olarak tutuluyorsa içerikte bu durum açıkça belirtilir. Structured data stratejisi güncel arama motoru yönergelerine göre değerlendirilmelidir. Satışta olmayan ürüne aktif offer gösterilmemelidir. Sayfa 404 olmuşsa Product markup kaldırılmalıdır. HTTP ve schema farklı sorumluluklardır.

Schema ile HTTP Davranışını Karıştırmamak

Schema bir 200 sayfasını 404 yapmaz. 404 response da eski Product markup'la geçerli ürün hâline gelmez. Önce route state belirlenir. Ardından sayfada sunulan gerçek içeriğe uygun schema uygulanır. Automated test iki katmanı ayrı doğrulamalıdır.

PDP İçeriği ile Structured Data'nın Uyumlu Olması

Fiyat, stok ve ürün adı aynı kaynaktan beslenmelidir. Kullanıcının görmediği farklı fiyat schema içinde olmamalıdır. Kampanya bitişleri senkron güncellenmelidir. Validation yalnızca syntax kontrolüyle sınırlı kalmamalıdır. Business data consistency test edilmelidir.

E-Ticaret Platform Migrasyonlarında 404 Stratejisi

Platform migration, 404 riskinin en yüksek olduğu dönemlerden biridir. Eski URL inventory, yeni URL mapping, SKU mapping, category mapping, 301 planı ve unmatched URL listesi migration öncesinde hazırlanmalıdır. Yayına geçtikten sonra crawl ve server log analizi yapılmalıdır. Eski URL'lerin büyük bölümünü ana sayfaya yönlendirmek kolay ama yanlış yaklaşımdır. Mapping mümkün olduğunca kullanıcı niyeti ve gerçek içerik ilişkisine dayanmalıdır.

Eski URL Inventory

Eski sitemap, analytics, Search Console, backlink ve server log verileri birleştirilebilir. Böylece yalnızca crawl sırasında bulunan URL'lere bağlı kalınmaz. Trafik ve SEO değeri de inventory'e eklenir. Duplicate URL'ler normalize edilir. Migration mapping için tam kaynak listesi oluşur.

Yeni URL Mapping

Eski URL'ler yeni karşılıklarla eşleştirilir. Exact SKU mapping en güvenilir yöntemdir. Kategori ve content similarity düşük güvenli kayıtlar için kullanılabilir. Unmatched URL'ler ayrı tutulmalıdır. Her satırda mapping reason bulunmalıdır.

SKU Mapping

SKU değişmiyorsa ürün migration'ı kolaylaşır. Yeni sistem farklı SKU üretiyorsa legacy ID ilişkisi saklanmalıdır. Merge ve split durumları ayrı ele alınır. Mapping one-to-many olduğunda otomatik redirect risklidir. Kullanıcıya seçim sunmak gerekebilir.

Category Mapping

Eski ve yeni taxonomy karşılaştırılır. Product overlap oranı relevance göstergesi olabilir. Bire bir kategori 301 alabilir. Split kategori manual review gerektirir. Yeni kategori URL'leri internal linklerde doğrudan kullanılmalıdır.

301 Planı

Redirect matrix production öncesi hazırlanmalıdır. Chain oluşmayacak şekilde final target seçilir. Edge veya server kapasitesi test edilir. Kritik URL'ler synthetic test listesine eklenir. Migration günü mapping deploy sırası açık olmalıdır.

Unmatched URL'ler

Her eski URL'nin yeni karşılığı olmayabilir. Bu normaldir. Unmatched URL'ler trafik ve backlink değerine göre review edilir. Gerçek hedef yoksa 404 bırakılır. Alakasız toplu redirect yapılmaz.

Migration Sonrası Crawl

Yeni site hemen taranmalıdır. 4xx, 5xx, chain, loop, canonical ve sitemap sorunları kontrol edilir. Production log ilk saatlerde incelenir. Critical landing page listesi ayrıca test edilir. Sorunlar öncelik skoruna göre çözülür.

URL Migration Öncesi Hazırlık

Migration başarısı yayına geçiş gününde değil, haftalar önce yapılan envanter çalışmasıyla belirlenir. Analytics export, Search Console, backlink export, sitemap, server logs ve redirect matrix eski sistemin gerçek URL değerini anlamaya yardımcı olur. Yalnızca mevcut sitemap'e güvenmek önemli landing page'leri kaçırabilir. Historical log ve analytics uzun süredir sitemap'te olmayan fakat hâlâ trafik alan URL'leri gösterebilir. Hazırlık ne kadar iyi olursa migration sonrası 404 incident ihtimali o kadar azalır.

Analytics Export

Landing page trafik ve conversion verisi dışa aktarılmalıdır. En az bir sezonu kapsayan tarih aralığı faydalıdır. High-value URL'ler işaretlenir. URL normalization uygulanır. Data privacy gereği kişisel bilgi export edilmez.

Search Console

Organic clicks ve impressions önemli URL'leri gösterir. Query context mapping kararına yardımcı olabilir. Coverage sorunları da migration öncesi baseline sağlar. Export limitleri nedeniyle API gerekebilir. Veriler analytics ile birleştirilebilir.

Backlink Export

Dış bağlantı alan URL'ler inventory'e eklenir. Kaynak kalite ve relevance sinyalleri saklanabilir. Aynı URL birden fazla tool'da tekrar edebilir. Deduplication yapılmalıdır. High-value backlink URL'leri manual review alabilir.

Sitemap

Eski sitemap resmi indexable URL listesi sağlar. Ancak eksiksiz inventory değildir. Birden fazla sitemap dosyası birleştirilir. Status ve canonical state doğrulanabilir. Yeni sitemap planıyla karşılaştırılır.

Server Logs

Loglar gerçekten istek alan URL'leri gösterir. Googlebot ve user requests ayrı segmentlenebilir. Eski URL patternleri bulunur. Migration sonrası karşılaştırma için baseline oluşturulur. Sensitive query parametreleri temizlenmelidir.

Redirect Matrix

Matrix source, destination, reason ve confidence içerir. Unmatched kayıtlar açıkça işaretlenir. Chain prevention kontrolü yapılır. High-value düşük confidence satırlar review edilir. Matrix production config'e dönüştürülmeden önce test edilir.

Migration Sonrası 404 Monitoring

Migration sonrası ilk saatler, ilk 24 saat, ilk hafta ve ilk ay farklı izleme yoğunlukları gerektirir. İlk saatlerde kritik route ve 404 spike, sonraki günlerde crawl ve Search Console sinyalleri, ilk ayda organik trafik ve redirect chain kalitesi takip edilir. Kritik landing page kontrolleri otomatik synthetic testlerle yürütülebilir. Server log migration öncesi baseline ile karşılaştırılmalıdır. Sorunların bir ay sonra fark edilmesi yerine erken müdahale ciddi trafik kaybını önleyebilir.

İlk Saatler

Critical URLs otomatik test edilir. 404 ve 5xx rate dashboard'da yakından izlenir. Redirect service health kontrol edilir. CDN cache problemleri aranır. Büyük sapma varsa rollback planı devreye girebilir.

İlk 24 Saat

Human traffic daha fazla veri üretmeye başlar. Internal broken link ve search click 404 oranı incelenir. Top high-traffic broken URLs listelenir. Mapping hotfix yapılabilir. Analytics eventlerinin çalıştığı doğrulanır.

İlk Hafta

Search engine crawl patternleri belirginleşir. Search Console sinyalleri gelmeye başlar. Redirect chain ve sitemap sorunları temizlenir. Organic landing traffic karşılaştırılır. Low-confidence mappingler davranış verisiyle review edilir.

İlk Ay

Organik performans daha anlamlı kıyaslanabilir. Recovered traffic ve revenue raporlanır. Kalıcı 404 baseline yeni sistem için belirlenir. Redirect registry cleanup planı başlatılır. Post-migration review dokümante edilir.

Kritik Landing Page Kontrolü

Top organic ve revenue landing page'ler ayrı liste olarak tutulmalıdır. Her deployment sonrası status, canonical ve content kontrol edilebilir. Migration döneminde daha sık synthetic test çalıştırılır. Kritik sayfanın 404 olması anında alert üretmelidir. Bu liste business ekipleriyle ortak hazırlanabilir.

Redirect Chain Kontrolü

Migration mapping eski redirectleri yeni redirectlerle zincirleyebilir. Crawler final hop sayısını raporlamalıdır. Eski kayıtlar final target'a güncellenmelidir. Internal links redirect üzerinden geçmemelidir. Registry chain count düşürülmelidir.

Deployment Kaynaklı 404'ler

404'lerin tamamı katalog yaşam döngüsünden kaynaklanmaz. Route değişikliği, missing build artifact, CDN cache, frontend/backend version mismatch, feature flag ve blue-green deployment gibi teknik sorunlar geçerli sayfaların aniden 404 olmasına yol açabilir. Bu durum normal 404 değil incident'tır. Baseline üzerindeki ani artış release zamanıyla korele edilmelidir. Automated regression test ve alerting bu problemi kullanıcılar fark etmeden yakalayabilir.

Route Değişikliği

Developer route path'ini değiştirdiğinde eski URL unutulabilir. Redirect planı release'in parçası olmalıdır. Route contract test eski ve yeni adresleri doğrular. Internal links aynı deployment içinde güncellenir. Breaking URL change review gerektirmelidir.

Missing Build Artifact

Static generation bazı sayfaları build'e dahil etmeyebilir. Ürün API'de aktif olduğu hâlde storefront 404 verir. Build manifest katalogla karşılaştırılabilir. Incremental generation fallback tasarlanabilir. Artifact eksikliği deployment incident olarak izlenmelidir.

CDN Cache

CDN eski 404 yanıtını geçerli ürün açıldıktan sonra taşımaya devam edebilir. Negative caching TTL dikkatle ayarlanmalıdır. Product create event purge tetikleyebilir. Cache key locale ve market'i doğru ayırmalıdır. Debug sırasında origin ve edge response karşılaştırılmalıdır.

Frontend/Backend Version Mismatch

Frontend yeni route beklerken backend eski API şemasında olabilir. Blue-green veya staggered rollout sırasında geçici 404 oluşabilir. Backward-compatible contract tasarlanmalıdır. Version health metadata monitoring'e eklenebilir. Deployment sırası dokümante edilmelidir.

Feature Flag

Feature flag bazı kullanıcıları yeni route'a gönderebilir. Flag kapandığında eski linkler sahipsiz kalabilir. URL oluşturan feature'ların lifecycle planı olmalıdır. Experiment bittiğinde redirect veya route cleanup yapılmalıdır. Flag config değişikliği de audit log'a yazılmalıdır.

Blue-Green Deployment

İki environment farklı route veya catalog snapshot taşıyabilir. Load balancer kullanıcıyı birinde 200 diğerinde 404 ile karşılaştırabilir. Deployment health check kritik URL'leri test etmelidir. Cache ve session affinity davranışı incelenmelidir. Version drift kısa tutulmalıdır.

Release Öncesi 404 Regression Test

Release öncesi test seti critical URLs, product URLs, category URLs, campaign URLs, redirect URLs ve invalid URLs içermelidir. Her örnek için expected status assertion tanımlanır. Böylece geçerli sayfanın yanlışlıkla 404 olması veya geçersiz URL'nin 200 dönmesi deployment öncesinde bulunabilir. Testler yalnızca happy path değil, bilinçli hatalı URL'leri de kapsamalıdır. CI/CD pipeline başarısız contract durumunda release'i durdurabilir.

Critical URLs

Top landing ve checkout route'ları mutlaka test edilir. Status yanında temel içerik assertion yapılabilir. Locale varyantları kapsanabilir. Kritik URL listesi business önceliğine göre güncellenir. Test failure release blocker olabilir.

Product URLs

Active, out-of-stock, replaced ve removed örnekler seçilir. Her lifecycle state beklenen davranışı göstermelidir. Product API ve storefront response birlikte doğrulanabilir. Random sample katalog genişliğini kapsar. High-value SKU'lar sabit test setinde tutulur.

Category URLs

Active, empty, merged ve removed kategori örnekleri test edilir. 301 veya 404 expectation açık olmalıdır. Canonical kontrolü eklenebilir. Facet URL örnekleri de dahil edilir. Taxonomy deployment'larında coverage genişletilir.

Campaign URLs

Aktif ve expired kampanya route'ları farklı davranır. Expiry tarihi simulation ile test edilebilir. Evergreen landing page 200 kalmalıdır. Redirect olan kampanya hedefi doğrulanmalıdır. CMS publish state test ortamına yansıtılmalıdır.

Redirect URLs

Expected Location ve status assert edilir. Maksimum hop kontrol edilir. Hedef 200 olmalıdır. Loop test otomatik yapılır. Registry config değişikliği test setini güncelleyebilir.

Invalid URLs

Rastgele product slug, bilinmeyen category ve bozuk parameter örnekleri eklenir. Beklenen 404 gerçek HTTP response olarak doğrulanır. UI custom 404 içeriği gösterir. Soft 404 regression böyle bulunur. Security path'leri ayrı test paketinde ele alınabilir.

Expected Status Assertion

Her URL kontratında beklenen status bulunmalıdır. Test body text'e bakmakla yetinmez. Redirectlerde Location kontrol edilir. 404'te response body'nin temel navigation içerdiği doğrulanabilir. Contract version repository içinde saklanabilir.

Automated URL Contract Test

Automated URL Contract Test, input URL, expected status, expected redirect, maximum redirect hop, canonical, indexability ve CI/CD integration alanlarını birlikte doğrular. Bu yaklaşım SEO gereksinimlerini test edilebilir teknik kontrata dönüştürür. Bir route refactor edildiğinde hangi beklentinin bozulduğu hemen görülür. Test verisi lifecycle örneklerinden otomatik üretilebilir. Böylece SEO kontrolü deployment sonrası manuel liste olmaktan çıkar.

Input URL

Her test belirli URL ile başlar. Locale ve query varyantları eklenebilir. Test verisi production'a zarar vermeyen örneklerden seçilmelidir. Random generated invalid URL'ler de kullanılabilir. Input normalize edilmemelidir çünkü gerçek routing davranışı test edilir.

Expected Status

200, 301, 404 veya 410 expectation açıkça tanımlanır. Status mismatch test failure'dır. Lifecycle state değişirse test kaydı da event ile güncellenebilir. Manual exception dokümante edilir. Bu alan soft 404 tespitinde kritiktir.

Expected Redirect

Redirect varsa hedef URL beklenen değerle karşılaştırılır. Alakasız destination kabul edilmez. Query preservation policy test edilebilir. Final target ayrıca health check'ten geçer. Relative ve absolute URL davranışı standardize edilir.

Maximum Redirect Hop

Çoğu kaynak için bir hop hedeflenebilir. Test final destination'a kadar redirect takip eder. Sınır aşılırsa failure üretir. Loop otomatik olarak ortaya çıkar. Migration sonrası chain temizliği bu testle korunur.

Canonical

200 sayfaların canonical değeri kontrol edilebilir. Redirect veya 404 sayfalarında gereksiz canonical beklentisi oluşturulmamalıdır. Variant ve facet testleri özellikle önemlidir. Canonical final URL ile tutarlı olmalıdır. Sitemap expectation ayrıca bağlanabilir.

Indexability

Meta robots ve HTTP davranışı birlikte kontrol edilir. 200 indexable sayfa yanlışlıkla noindex olmamalıdır. Internal search sayfaları policy'ye göre noindex olabilir. 404 için status temel sinyaldir. Test indexability rule set ile doğrulanır.

CI/CD Integration

Contract test deployment pipeline'a bağlanır. Kritik failure release'i durdurabilir. Daha düşük severity uyarı oluşturabilir. Test ortamında gerçek redirect registry ve sample katalog bulunmalıdır. Production smoke test ek güven sağlar.

404 Spike Bir Incident Sinyali Olabilir mi?

Evet. Normal bir e-ticaret sitesinde her zaman belirli baseline 404 seviyesi bulunabilir, ancak ani artış deployment, catalog import, CDN veya routing problemine işaret edebilir. Tek başına mutlak sayı yerine baseline sapması izlenmelidir. Route ve user segment analizi kök nedeni hızla daraltır. Alert threshold geçmiş trafik davranışına göre dinamik ayarlanabilir.

Baseline 404

Her sitenin normal 404 seviyesi farklıdır. Bot trafiği baseline'ın büyük bölümünü oluşturabilir. Human baseline ayrıca tutulmalıdır. Gün ve saat sezonsallığı hesaba katılabilir. Yeni deployment sonrası karşılaştırma bu referansa göre yapılır.

Ani Artış

Kısa sürede birkaç kat artış incident sinyali olabilir. Route type dağılımı incelenir. Tek product family etkileniyorsa catalog import sorunu olabilir. Tüm site etkileniyorsa routing veya CDN araştırılır. Human impact severity belirler.

Deployment Correlation

Monitoring dashboard release marker göstermelidir. 404 spike release ile aynı dakikada başladıysa ilişki güçlüdür. Son commit ve route değişiklikleri incelenir. Rollback kararı business impact'e göre verilir. Incident sonrası regression test eklenir.

Catalog Import Correlation

Toplu ürün importu yanlışlıkla binlerce kaydı REMOVED yapabilir. 404 spike product route'unda görünür. Import job logu ve lifecycle event hacmi kontrol edilir. Gerekirse katalog rollback yapılır. Event consumer state'i yeniden senkronize edilir.

CDN / Routing Problemi

Edge config yanlış route'u origin'e göndermeyebilir. Region bazlı 404 artışı CDN sorununu gösterebilir. Origin direct test ile karşılaştırma yapılır. Cache purge ve config rollback değerlendirilebilir. Multi-region monitoring önemlidir.

Alert Threshold

Sabit eşik küçük ve büyük trafik dönemlerinde yanlış alarm üretebilir. Percentage change ve baseline deviation birlikte kullanılabilir. Human 404 ve critical route ayrı threshold taşımalıdır. Alert spam önlenmelidir. Her alarm runbook linki ve owner içermelidir.

404 Incident Playbook

404 incident playbook spike'ı doğrulama, etkilenen route'u belirleme, son deployment'ı kontrol etme, catalog sync'i inceleme, redirect service'i kontrol etme, rollback veya fix uygulama ve post-incident review adımlarını içerir. Bu sıra panik içinde rastgele değişiklik yapılmasını önler. Her adım için owner ve gerekli dashboard linkleri tanımlanmalıdır. Incident sırasında ilk hedef kullanıcı etkisini azaltmaktır. Kalıcı çözüm ve test ekleme daha sonra post-review aşamasında tamamlanır.

Spike'ı Doğrula

Önce alarmın gerçek olup olmadığı kontrol edilir. Bot scan geçici artış oluşturmuş olabilir. Human sessions ve route dağılımı incelenir. Birden fazla monitoring kaynağı karşılaştırılır. False positive ise threshold not edilir.

Etkilenen Route'u Belirle

Product, category, campaign veya bütün site segmenti ayrılır. Tek pattern varsa regex veya template bulunur. Region ve device farkları kontrol edilir. Source URL listesi çıkarılır. Bu bilgi root cause araştırmasını hızlandırır.

Son Deployment'ı Kontrol Et

Release marker ve change log incelenir. Routing, feature flag ve CDN config değişiklikleri öne alınır. Rollback yapılabilirliği değerlendirilir. Hızlı geri dönüş kullanıcı etkisini azaltabilir. Sonraki düzeltme staging'de contract test ile doğrulanır.

Catalog Sync'i Kontrol Et

Product state ve search index drift araştırılır. Import job başarısız mı veya yanlış silme eventi mi üretmiş bakılır. PIM ve commerce data karşılaştırılır. Gerekirse reconciliation çalıştırılır. Yanlış lifecycle eventleri audit log'dan bulunur.

Redirect Service'i Kontrol Et

Registry availability ve cache state doğrulanır. Mapping deploy edilmemiş olabilir. Loop veya broken destination artışı araştırılır. Service latency ve error rate incelenir. Fallback davranışının çalıştığı kontrol edilir.

Rollback / Fix

En hızlı güvenli çözüm uygulanır. Rollback daha düşük riskliyse tercih edilebilir. Hotfix kritik route'u geri getirebilir. Değişiklik monitoring altında yayınlanır. 404 rate baseline'a dönene kadar takip edilir.

Post-Incident Review

Kök neden ve kullanıcı etkisi dokümante edilir. Eksik test veya monitoring alanı belirlenir. Action item owner ve tarih alır. Aynı incident'in tekrarını önleyen regression test eklenir. Süreç suçlama değil sistem geliştirme odaklı yürütülmelidir.

Güvenlik Perspektifinden 404

404 sayfaları security scanner ve URL enumeration trafiğiyle sık karşılaşır. Admin path probing, random file requests ve bot scan davranışlarında sistem gereksiz teknik bilgi vermemelidir. Stack trace, framework version veya internal path gibi detaylar kullanıcıya gösterilmemelidir. Rate limiting ve WAF şüpheli trafiği sınırlandırabilir. Commerce recovery servisleri security scan isteklerinde devre dışı bırakılarak backend maliyeti azaltılabilir.

URL Enumeration

Saldırganlar farklı ID veya path deneyerek kaynak varlığını anlamaya çalışabilir. Response farklılıkları gereksiz bilgi sızdırmamalıdır. Authorization gerektiren kaynaklar ayrı policy izler. 404 ve 403 seçimi güvenlik modeline bağlıdır. Timing farkları da bazı durumlarda bilgi verebilir.

Bot Scan

Automated scanner binlerce bilinen açık path'ini deneyebilir. Generic lightweight 404 yeterlidir. Recommendation API çağrılmamalıdır. Rate limiting uygulanabilir. Security analytics pattern'i ayrı toplar.

Admin Path Probing

/admin veya backup dosyaları gibi pathler sık denenir. Gerçek admin yapısı response içinde açıklanmamalıdır. Authentication ve authorization katmanı doğru çalışmalıdır. Public 404 template kullanılabilir. WAF yüksek frekansı engelleyebilir.

Hassas Bilgi Sızdırmamak

Error response internal ID, stack veya query detaylarını göstermemelidir. User-facing mesaj generic olabilir. Debug detayları yalnızca güvenli loglarda tutulur. Production error handling development modundan farklıdır. Loglar da hassas veri açısından kontrol edilmelidir.

Stack Trace Göstermemek

Stack trace kullanıcı için yararlı değildir. Framework ve dosya yollarını açığa çıkarabilir. Production'da merkezi error handler devreye girmelidir. Trace observability sistemine güvenli biçimde gönderilebilir. 404 zaten exception olarak ele alınmak zorunda değildir.

Rate Limiting

Şüpheli request hacmi edge üzerinde sınırlandırılabilir. Gerçek user ve search bot false positive olmamalıdır. Threshold path sınıfına göre değişebilir. Security incident sırasında dinamik olarak sıkılaştırılabilir. Rate limit logları ayrı tutulmalıdır.

WAF

WAF bilinen saldırı patternlerini engelleyebilir. 404 monitoring ile WAF telemetry birbirine bağlanabilir. Random scan artışı commerce dashboard'ı kirletmemelidir. Rule update false positive açısından test edilmelidir. WAF 404 resolver'ın yerine geçmez.

404 ve 403 Karıştırılmamalıdır

404 kaynak yok anlamına gelirken 403 kaynak veya route mevcut olsa da erişim yetkisinin reddedildiğini ifade eder. Authentication ve authorization hatalarını ürün bulunamadı gibi göstermek bazı güvenlik modellerinde bilinçli tercih olabilir, ancak bu davranış açık policy gerektirir. Normal e-ticaret ürün URL'sinde kullanıcı yetkisiz diye 404 üretmek çoğu zaman gereksizdir. Private account veya admin kaynaklarında resource enumeration riski farklı değerlendirilir. HTTP semantiği güvenlik hedefleriyle birlikte tasarlanmalıdır.

Kaynak Yok

Kaynak gerçekten yoksa 404 doğru yanıttır. Resolver registry ve lifecycle lookup sonucunda bunu belirleyebilir. Kullanıcıya generic recovery gösterilir. Authorization kontrolüne gerek kalmayabilir. Security log random scan durumunu ayrıca işaretler.

Kaynak Var Ama Yetki Yok

Private kaynakta kullanıcı erişim hakkına sahip olmayabilir. 403 veya login flow uygun olabilir. Kaynağın varlığını gizlemek gereken güvenlik modelinde farklı davranış seçilebilir. Policy tutarlı olmalıdır. Public product URL ile private dashboard aynı kuralı paylaşmamalıdır.

Authentication

Kullanıcı giriş yapmamışsa 401 veya login redirect senaryoları olabilir. 404 kullanmak problemi gizleyebilir. Checkout ve account route'larında doğru authentication state önemlidir. Session expiry kullanıcıya anlaşılır biçimde anlatılmalıdır. Security ve UX birlikte tasarlanmalıdır.

Authorization

Giriş yapan kullanıcı belirli kaynağa yetkisiz olabilir. 403 semantik olarak daha açıktır. Resource existence gizlenecekse güvenlik ekibi farklı policy tanımlayabilir. API ve web davranışı tutarlı olmalıdır. Monitoring bu durumları 404 metriğine karıştırmamalıdır.

Güvenlik Nedeniyle Resource Enumeration'ı Sınırlamak

Private sistemlerde farklı hata yanıtları kaynak varlığını ele verebilir. Response body ve timing benzer tutulabilir. Public commerce katalogunda bu gereklilik daha sınırlıdır. Her route aynı security policy'yi izlememelidir. Threat model hangi davranışın gerekli olduğunu belirler.

404 Sayfası İçin İçerik Stratejisi

404 içeriği marka tonuna uygun, kısa, yardımcı ve kullanıcıyı suçlamayan bir yapıda olmalıdır. Teknik jargon yerine kullanıcının ne yapabileceği anlatılmalıdır. Ürün odaklı recovery, generic mizah veya dekoratif mesajdan daha değerlidir. Başlık, kısa açıklama ve birinci aksiyon ilk ekranda anlaşılmalıdır. İçerik testleri recovery rate ve kullanıcı geri bildirimiyle geliştirilebilir.

Marka Tonu

Mesaj sitenin genel iletişim biçimiyle uyumlu olmalıdır. Kurumsal marka sade, genç marka daha rahat konuşabilir. Ton işlevin önüne geçmemelidir. Kullanıcı önce ne olduğunu anlamalıdır. Marka kişiliği recovery mesajını desteklemelidir.

Kısa Mesaj

Hata açıklaması uzun teknik paragraf olmak zorunda değildir. Bir veya iki kısa cümle yeterli olabilir. Ardından search veya öneri sunulur. Kullanıcı detay isterse support alanına gidebilir. Mobilde kısa mesaj özellikle önemlidir.

Kullanıcıyı Suçlamamak

“Yanlış adres girdiniz” gibi kesin ifade kullanıcıyı gereksiz suçlar. URL dış siteden veya internal broken linkten gelmiş olabilir. Daha nötr dil kullanılmalıdır. Problem sisteme ait olabilir. Empatik mesaj kullanıcı güvenini korur.

Teknik Jargondan Kaçınmak

DNS, route manifest veya SKU lifecycle kullanıcıya açıklanmak zorunda değildir. “Aradığınız ürün artık mevcut değil” daha anlaşılırdır. Teknik detay monitoring ve debug loglarında kalır. Error code istenirse küçük bilgi olarak gösterilebilir. Ana CTA jargondan uzak olmalıdır.

Ne Yapabileceğini Söylemek

Kullanıcıya arama, kategori veya benzer ürün gibi açık seçenekler verilir. Bir sonraki adım görünür olmalıdır. Generic “geri dön” tek çözüm değildir. URL context varsa daha ilgili aksiyon gösterilebilir. CTA sonucu açıkça ifade etmelidir.

Ürün Odaklı Recovery

Ürün URL'sindeki 404 ürün bağlamını kullanmalıdır. Successor veya benzer ürün önerisi ilk sıraya alınabilir. Stokta ürünler tercih edilir. Search query eski ürün adıyla doldurulabilir. Kullanıcı satın alma yoluna daha kısa sürede döner.

Mizah 404 Sayfasında Ne Zaman Kullanılmalı?

Mizah ancak marka tonuna uygunsa ve kullanıcının problemini çözmeyi geciktirmiyorsa kullanılmalıdır. Kullanıcı ödeme veya hesap işlemi sırasında hata yaşadığında komik mesaj ters etki yaratabilir. Ürün keşfi sırasında hafif mizah daha kabul edilebilir olabilir. Her durumda fonksiyon tasarımdan önce gelmelidir. Kullanıcı arama ve navigation seçeneklerini mizahi görselin altında aramak zorunda kalmamalıdır.

Marka Tonuna Uygunluk

Mizah markanın normal dilinde varsa doğal görünebilir. Sadece 404 için farklı kişilik kullanmak kopukluk yaratır. Mesaj herkes tarafından anlaşılır olmalıdır. Yerel espri farklı dil pazarlarında çalışmayabilir. Çeviri ve localization test edilmelidir.

Kullanıcının Frustration Seviyesi

Checkout veya sipariş takip hatası yüksek stres yaratabilir. Bu noktada mizah sorunu küçümsüyor gibi algılanabilir. Product browsing hatası daha düşük risklidir. Route context copy seçimini etkileyebilir. Kullanıcı destek ihtiyacı hızlı karşılanmalıdır.

Kritik İşlemlerde Mizahın Riski

Ödeme sonrası confirmation URL kaybolduysa kullanıcı sipariş konusunda endişelenir. Espri yerine açık durum ve destek yolu gerekir. Teknik ekibe incident alarmı gidebilir. Private route'larda generic 404 yerine doğru işlem state'i gösterilmelidir. Kritik akışlarda güven önceliklidir.

Fonksiyonun Tasarımdan Önce Gelmesi

404 sayfasının görevi kullanıcıyı devam ettirmektir. Büyük animasyon veya oyun search alanını gölgelememelidir. Performance etkisi de düşünülmelidir. Recovery CTA ilk sırada kalmalıdır. Tasarım işlevi desteklediği sürece değerlidir.

AI Destekli Dinamik 404

Yapay zekâ tabanlı yöntemler query intent extraction, semantic product matching, personalized recommendations, dynamic copy ve anomaly detection gibi alanlarda 404 recovery sistemini destekleyebilir. Ancak kritik HTTP ve redirect kararları kontrolsüz bir modele bırakılmamalıdır. Human-controlled business rules ve confidence threshold birlikte kullanılmalıdır. Bu konuda içerik üretimi ve SEO standartlarına dair ek yaklaşım için https://www.diyarbakiryazilim.com.tr/posts/yapay-zeka-icerik-uretim-sureclerinde-seo-uyum-standartlari adresindeki yaklaşım da incelenebilir. Model kullanıcıya daha iyi öneri sağlayabilir, ancak HTTP semantiğinin sahibi deterministic policy olmalıdır.

Query Intent Extraction

Eski slug veya search query içinden ürün niyeti çıkarılabilir. Marka, kategori ve özellik entity'leri bulunabilir. Bu bilgiler recommendation query'yi daraltır. Confidence düşükse generic search kullanılır. Model sonucu doğrudan redirect olarak kabul edilmemelidir.

Semantic Product Matching

Semantic matching eski ürünle güncel katalog arasındaki anlam ilişkisini bulur. Product archive veri kaynağı olarak değerlidir. Kategori ve stock filtreleri sonuca uygulanır. Yüksek similarity her zaman successor anlamına gelmez. Kullanıcıya öneri sunmak en güvenli kullanım alanıdır.

Personalized Recommendations

Oturum veya hesap tercihleri ranking'e katkı sağlayabilir. Consent şartları korunmalıdır. Kayıp ürün bağlamı temel sinyal olarak kalmalıdır. Kişiselleştirme başarısız olursa generic recommendation çalışmalıdır. Model kullanıcı profilini gereksiz yere genişletmemelidir.

Dynamic Copy

Route type'a göre hata mesajı değiştirilebilir. Ürün, kategori ve kampanya için farklı açıklamalar sunulabilir. Tam serbest metin üretimi yerine kontrollü template kullanmak güvenlidir. Marka tonu ve hukuki metinler korunur. A/B test farklı mesajların etkisini ölçebilir.

Anomaly Detection

404 time series üzerinde olağandışı artışlar otomatik bulunabilir. Route, region ve source segmentleri modele girdi olabilir. Deployment marker'ları korelasyon sağlar. Anomaly alert insan tarafından incelenir. Model incident'ın nedenini kesin gerçek olarak ilan etmemelidir.

Human-Controlled Business Rules

Ürün state, market ve compliance kuralları insan tarafından tanımlanmalıdır. Model yalnızca öneri veya score üretebilir. Deterministic guardrail final sonucu sınırlar. Kritik URL manual review'a gönderilebilir. Böylece otomasyon ile kontrol dengelenir.

AI ile Otomatik Redirect Kararı Verilmeli mi?

Tamamen kontrolsüz biçimde verilmemelidir. Yanlış redirect riski, explainability, confidence threshold ve high-value URL'lerde insan review ihtiyacı dikkate alınmalıdır. Yapay zekâyı öneri motoru olarak kullanmak çoğu durumda daha güvenlidir. Exact URL change ve açık successor gibi kritik redirectler deterministik tutulmalıdır. Modelin görevi belirsiz eşleşmelerde seçenek üretmek ve analiste yardımcı olmak olabilir.

Yanlış Redirect Riski

Model semantic olarak benzer fakat ticari olarak farklı ürünü seçebilir. Kullanıcı yanlış fiyat veya özellik görür. Arama motoru kaynak ve hedef ilişkisinin zayıf olduğunu değerlendirebilir. Bu nedenle automatic threshold yüksek tutulmalıdır. Redirect sonrası davranış izlenmelidir.

Explainability

Sistem neden bu hedefi seçtiğini gösterebilmelidir. Brand match, category match veya successor relation gibi reason code'lar faydalıdır. Salt model skoru operasyon ekibine yeterli açıklama vermez. Debug ve review kolaylaşır. Explainability yanlış mapping düzeltme hızını artırır.

Confidence Threshold

Model score'u business rule ile kalibre edilmelidir. High, medium ve low confidence seviyeleri kullanılabilir. Kategoriye göre eşikler farklılaşabilir. User behavior feedback kalibrasyon sağlar. Eşik değişiklikleri versiyonlanmalıdır.

High-Value URL'lerde İnsan Review

Yüksek trafik veya backlink değeri taşıyan URL'ler manual review alabilir. Otomatik sistem aday hedef önerir. SEO veya commerce uzmanı mapping'i onaylar. Review sonucu modele feedback olabilir. Bu süreç kritik yanlış redirect riskini azaltır.

AI'ı Öneri Motoru Olarak Kullanmak

Recommendation kullanıcıya seçenek sunduğu için hata maliyeti daha düşüktür. Model birkaç yakın ürün sıralayabilir. Kullanıcı seçim yapar. Click ve conversion verisi kaliteyi ölçer. Low confidence'da search fallback korunur.

Kritik Redirect'leri Deterministik Tutmak

Aynı ürünün yeni URL'si registry ile kesin olarak bilinebilir. Bu durumda model kullanmak gereksizdir. Product Replaced event açık successor taşıyabilir. Deterministik mapping daha hızlı ve açıklanabilirdir. Model belirsiz kalan alanlara ayrılmalıdır.

Open Source ile Akıllı 404 Altyapısı

Açık kaynak search engine, vector search, recommendation libraries, URL matching ve observability bileşenleri smart 404 altyapısının büyük bölümünü oluşturabilir. Önemli olan araçları kurumsal iş kurallarıyla birleştirmektir. Tek bir kütüphane ürün lifecycle, redirect registry ve SEO policy problemini kendiliğinden çözmez. Architecture, data contract ve monitoring yine ekip tarafından tasarlanmalıdır. Açık kaynak bileşenler kontrollü servis sınırları içinde değerlendirildiğinde güçlü öğrenme ve geliştirme alanı yaratır.

Search Engine

Search engine typo ve keyword recovery sağlayabilir. Legacy ürün başlığıyla güncel katalog aranabilir. Index freshness önemli metriktir. Kaldırılmış ürünler sonuçlarda kalmamalıdır. Search servisi timeout olduğunda generic fallback çalışmalıdır.

Vector Search

Vector search semantic alternatifleri bulabilir. Product embedding'leri index içinde tutulur. Metadata filter stock ve category state'i uygular. Re-ranking iş kurallarıyla yapılır. Vector database redirect registry'nin yerine geçmez.

Recommendation Libraries

Recommendation frameworkleri candidate generation ve ranking için kullanılabilir. 404 context özel feature olarak eklenebilir. Historical click ve purchase sinyalleri değerlendirilebilir. Cold-start için content-based yöntem gerekir. Business rule katmanı sonuçları filtrelemelidir.

URL Matching

String similarity ve routing kütüphaneleri typo kaynaklı pathleri eşleştirebilir. Normalize edilmiş slug dictionary güçlü başlangıçtır. Exact mapping her zaman fuzzy sonuçtan önce gelir. Security input validation korunmalıdır. Match confidence loglanmalıdır.

Observability

Metrics, logs ve traces resolver sisteminin anlaşılmasını sağlar. Request ID servis çağrılarını birbirine bağlayabilir. P95 latency ve error rate izlenir. Privacy gereksiz kullanıcı bilgisinin loglanmasını önler. Dashboard incident response'u hızlandırır.

Açık Kaynak Bileşenleri Kurumsal İş Kurallarıyla Birleştirmek

Teknoloji seçimi policy'nin yerine geçmez. Ürün state, redirect threshold ve market kuralları şirket tarafından tanımlanmalıdır. Açık kaynak araç yalnızca bu kuralları uygulayan altyapı sağlar. Upgrade ve security bakım planı bulunmalıdır. Contributor ekibi dokümantasyon ve test standardı belirlemelidir.

Diyarbakır Yazılım Topluluğu İçin Örnek Smart-404 Projesi

Örnek bir topluluk projesi açık kaynak e-ticaret demo kataloğu, dynamic product routes, 404 resolver, semantic search, product recommendation, analytics dashboard ve contributor workflow bileşenlerinden oluşabilir. Böyle bir proje HTTP, backend, frontend, search, SEO ve analytics konularını tek uygulamada buluşturur. Katılımcılar farklı ekipler hâlinde gerçek production problemlerine benzer kararları deneyebilir. Mevcut proje yaklaşım ve örneklerini görmek için https://www.diyarbakiryazilim.com.tr/projects adresi incelenebilir. Projenin en değerli tarafı yalnızca güzel bir 404 ekranı değil, ürün state değişikliğinin bütün sistemlerde nasıl yönetildiğini öğretmesidir.

Açık Kaynak E-Ticaret Demo Kataloğu

Demo katalog farklı lifecycle state'leri içermelidir. Active, out-of-stock, replaced ve removed ürün örnekleri bulunabilir. Kategori ve varyant yapısı gerçekçi tutulur. Seed data migration senaryoları eklenebilir. Testler deterministik veri üzerinden çalışır.

Dynamic Product Routes

Ürün route'ları slug veya SKU ile oluşturulabilir. Invalid URL gerçek 404 döndürmelidir. Legacy URL mapping örnekleri eklenebilir. SSR ve CSR farkı uygulamalı gösterilebilir. Test suite status code'u doğrular.

404 Resolver

Resolver registry ve lifecycle lookup yapar. Exact successor varsa 301 kararı verebilir. Belirsiz durumda recommendation context döndürür. Generic path lightweight 404 kullanır. Decision reason analytics'e yazılır.

Semantic Search

Archive ürün verisi embedding'e dönüştürülebilir. Güncel katalog adayları vector similarity ile bulunur. Kategori filtresi uygulanır. Sonuçlar recommendation listesinde gösterilir. Redirect kararı semantic skora tek başına bırakılmaz.

Product Recommendation

Content-based baseline ile başlanabilir. Daha sonra collaborative signal eklenir. Stock filter zorunlu tutulur. Recommendation failure static category fallback kullanır. A/B test farklı sıralamaları karşılaştırabilir.

Analytics Dashboard

Dashboard 404 view, recovery click, product view ve recovered revenue gösterebilir. Bot trafik ayrı tutulur. Route type filtreleri eklenir. Spike alarmı örnek olarak uygulanabilir. Katılımcılar gerçek gözlem pratiği kazanır.

Contributor Workflow

Issue template, branch policy ve code review standardı tanımlanabilir. Backend, frontend ve SEO taskları ayrı etiketlenir. Pull request contract test çalıştırır. Dokümantasyon değişikliği kodla birlikte istenir. Yeni katılımcılar küçük issue'lardan başlayabilir.

Topluluk Tabanlı Geliştirme Modeli

Smart 404 gibi çok katmanlı proje backend, frontend, SEO, data veya search ve QA ekiplerinin birlikte çalışması için iyi bir örnektir. Her ekip kendi alanını geliştirirken ortak HTTP ve lifecycle kontratına uymalıdır. Open Source Code Review farklı bakış açılarını bir araya getirir. Ortak release süreci integration sorunlarını görünür hâle getirir. Topluluğun çalışma yaklaşımı hakkında daha fazla bilgi için https://www.diyarbakiryazilim.com.tr/about adresi kullanılabilir.

Backend Ekibi

Resolver API ve lifecycle state modelini geliştirir. Cache ve performance sorumluluğunu taşır. Redirect registry integration kurar. Unit ve integration test yazar. API contract frontend ile ortak belirlenir.

Frontend Ekibi

Dynamic 404 component ve recovery UX geliştirir. Accessibility ve mobile davranışı test eder. Recommendation failure fallback uygular. Analytics eventlerini üretir. HTTP kararını kendi başına değiştirmez.

SEO Ekibi

Status code, canonical, sitemap ve redirect policy tanımlar. Search Console ve crawl verilerini analiz eder. High-value URL review yapar. Migration test listesi hazırlar. Product ve engineering ile lifecycle kurallarını netleştirir.

Data / Search Ekibi

Search index ve recommendation pipeline'ını yönetir. Semantic matching ve relevance score geliştirir. Index freshness ölçer. Feature ve model performansını izler. Business rule katmanıyla ortak çalışır.

QA Ekibi

Lifecycle state senaryolarını uçtan uca test eder. Expected status assertion uygular. Mobile ve accessibility testleri yapar. Regression suite production problemlerinden öğrenir. Release blocker kurallarını ekiplerle belirler.

Open Source Code Review

Code review yalnızca syntax kontrolü değildir. HTTP semantiği, test coverage ve performance değerlendirilir. SEO etkisi route değişikliklerinde gözden geçirilir. Reviewer checklist kullanılabilir. Kararlar dokümantasyona yansıtılır.

Ortak Release

Release öncesi bütün servis contractları test edilir. Migration script ve registry update sırası belirlenir. Smoke test kritik URL'leri doğrular. Monitoring dashboard release marker alır. Sorun çıkarsa rollback planı uygulanır.

“En İyi Programlama Dili” 404 Mimarisi İçin Var mı?

Tek bir en iyi programlama dili yoktur. 404 mimarisinin başarısını frontend stack, backend stack, edge runtime, search veya recommendation stack ve ekibin mevcut operasyon kapasitesi belirler. JavaScript, TypeScript, Java, Go, PHP, Python veya farklı bir dil doğru HTTP davranışını uygulayabilir. Seçim trafik, ekip uzmanlığı, mevcut mimari ve bakım maliyetine göre yapılmalıdır. Dil değiştirmek yanlış lifecycle modelini kendiliğinden çözmez.

Tek Bir En İyi Programlama Dili Neden Yok?

HTTP ve routing prensipleri dilden bağımsızdır. Her ekosistemde mature web framework bulunabilir. Kritik fark ekibin sistemi güvenilir biçimde geliştirebilmesidir. Performance ihtiyaçları kategoriye göre değişir. Gereksiz teknoloji değişimi proje riskini artırabilir.

Frontend Stack

Frontend SSR ve CSR yetenekleri önemlidir. Framework gerçek status code üretimini kolaylaştırmalıdır. Accessibility ve performance araçları bulunmalıdır. Team familiarity bakım hızını etkiler. Headless API contract açık tutulmalıdır.

Backend Stack

Backend resolver latency ve availability ihtiyaçlarını karşılamalıdır. Registry ve catalog integration kolay olmalıdır. Async event consumer desteği yararlıdır. Observability ekosistemi güçlü olmalıdır. Dil seçimi mevcut platformla uyumlu olursa operasyon sadeleşir.

Edge Runtime

Edge bilinen redirect ve lightweight routing için kullanılabilir. Runtime'ın storage ve latency özellikleri önemlidir. Ağır recommendation logic edge'e taşınmak zorunda değildir. Registry snapshot hızlı lookup sağlayabilir. Security ve cache davranışı test edilmelidir.

Search / Recommendation Stack

Search engine çoğu backend dilden API ile erişilebilir. Vector database de benzer biçimde bağımsız servis olabilir. Recommendation modeli Python'da geliştirilip farklı backend'den çağrılabilir. Tek teknoloji içinde her şeyi yazmak gerekmez. Servis contractları dil sınırını gizler.

Dil Seçimini Trafik, Ekip ve Mevcut Mimarinin Belirlemesi

Yüksek trafik düşük latency ihtiyacı doğurabilir. Ancak ekip deneyimi ve bakım maliyeti aynı derecede önemlidir. Mevcut platform Java ise yalnızca 404 için farklı dil eklemek gereksiz olabilir. Küçük ekip sade architecture'tan fayda görür. Seçim benchmark ve operasyon verisiyle yapılmalıdır.

404 Mimarisi Geliştiren Yazılımcı Hangi Konuları Bilmeli?

404 mimarisi HTTP, routing, REST veya GraphQL, database, search, SEO, analytics, caching, observability ve testing konularını aynı problem üzerinde birleştirir. Bu nedenle e-ticaret sistem tasarımını öğrenmek isteyen geliştiriciler için güçlü uygulama alanıdır. Yalnızca bir hata component'i yazmak yerine URL lifecycle ve kullanıcı davranışı düşünülür. Backend ile frontend arasındaki state aktarımı anlaşılır. Production monitoring ve regression test süreçleri de öğrenme kapsamına girer.

HTTP

200, 301, 302, 307, 404, 410 ve 5xx kodları anlaşılmalıdır. Header ve cache davranışı önemlidir. Status ile body içeriğinin tutarlı olması gerekir. Browser redirect mekanizması bilinmelidir. HTTP bilgisi soft 404 problemini anlamanın temelidir.

Routing

Static ve dynamic route farkı bilinmelidir. Catch-all route dikkatle kullanılmalıdır. URL normalization ve parameter parsing önemlidir. SSR ve CSR routing farkı anlaşılmalıdır. Route contract test yazılabilmelidir.

REST / GraphQL

Commerce backend state'i API üzerinden taşınabilir. Null ve explicit lifecycle state farkı önemlidir. Error contract frontend kararını etkiler. GraphQL'de partial error durumları ayrıca düşünülür. API response semantic olarak açık olmalıdır.

Database

Hard delete ve soft delete farkı bilinmelidir. Legacy URL ve product archive ilişkileri modellenebilir. Redirect registry relational veya key-value sistemde tutulabilir. Indexing lookup latency'yi etkiler. Audit trail veri modelinin parçasıdır.

Search

Keyword search, typo correction ve faceted navigation konuları önemlidir. Index freshness kullanıcıyı 404'e taşıyabilir. Search query recovery aracı olarak kullanılır. Filter URL'lerinin crawl etkisi anlaşılmalıdır. Search relevance ile redirect relevance farklıdır.

SEO

Status code, canonical, sitemap ve internal linking temel konulardır. Soft 404 ve redirect chain davranışı bilinmelidir. Search Console ve server log birlikte okunmalıdır. SEO sadece meta tag düzenlemek değildir. URL lifecycle sistem tasarımının parçasıdır.

Analytics

404 view ve recovery eventleri izlenebilir. Funnel ve attribution kavramları öğrenilir. Bot traffic temizlenmelidir. A/B test sonucu okunabilmelidir. Data privacy analitiğin sınırını belirler.

Caching

CDN, application cache ve recommendation cache farklıdır. Negative caching 404 problemlerini uzatabilir. Invalidation lifecycle event'e bağlanabilir. Personalized veri shared cache'te tutulmamalıdır. TTL state hızına göre seçilmelidir.

Observability

Metrics, logs ve traces production davranışını gösterir. Request ID servisler arasında takip sağlar. Alert threshold baseline'a göre ayarlanır. Dashboard sadece teknik hata değil recovery metriklerini de taşıyabilir. Incident response observability olmadan yavaşlar.

Testing

Unit, integration, contract ve end-to-end test birlikte kullanılabilir. Expected status assertion kritiktir. Redirect chain ve loop test edilmelidir. Lifecycle state sample'ları test fixture olur. Production incident sonrası regression test eklenmelidir.

Yazılımcı Olmak İsteyenler İçin 404 Projesi Neden İyi Bir Eğitimdir?

404 projesi basit UI'dan sistem tasarımına geçiş için iyi bir köprü oluşturur. Backend–Frontend entegrasyonu, HTTP status code, SEO, recommendation, analytics ve production monitoring aynı küçük problem etrafında öğrenilebilir. Başlangıçta statik hata sayfası yapılır, sonra ürün lifecycle ve dynamic resolver eklenir. Daha ileri aşamada semantic recommendation ve dashboard geliştirilebilir. Böylece proje öğrencinin yalnızca framework syntax değil sistem davranışı öğrenmesini sağlar.

Basit UI'dan Sistem Tasarımına Geçiş

İlk adımda kullanıcıya mesaj ve linkler gösterilir. Sonra status code problemi fark edilir. Ardından product state ve redirect registry gelir. Recommendation ve analytics yeni katman ekler. Öğrenci küçük bir feature'ın büyüyen mimari etkisini görür.

Backend–Frontend Entegrasyonu

Frontend ürün bulunamadığında backend state'ine ihtiyaç duyar. API contract tasarlanır. Error ve success response ayrılır. SSR davranışı test edilir. Bu süreç gerçek proje entegrasyonuna benzer.

HTTP Status Code

Öğrenci 404'ün yalnızca ekrandaki sayı olmadığını öğrenir. Network tab üzerinden response kontrol edilir. 301 ve 200 farkı uygulamalı görülür. Soft 404 örneği kolayca oluşturulabilir. Automated assertion temel test pratiği kazandırır.

SEO

Sitemap ve internal link etkisi görülebilir. Canonical ile redirect arasındaki fark anlaşılır. Search Console benzeri crawl mantığı simüle edilebilir. Product lifecycle SEO kararına bağlanır. Teknik SEO soyut kavram olmaktan çıkar.

Recommendation

Önce basit kategori benzerliği yapılabilir. Sonra attribute ve semantic yöntem eklenir. Confidence threshold tasarlanır. Kullanıcı tıklamaları ölçülür. Model sonucunun otomatik karar olmadığını öğrenci görür.

Analytics

404 view ve click eventleri eklenir. Funnel dashboard yapılabilir. Bot traffic örneği ayrıştırılır. Recovery rate hesaplanır. Bu deneyim ürün analitiğini teknik özelliklerle bağlar.

Production Monitoring

Latency ve error rate izlenir. Simüle deployment sonrası 404 spike oluşturulabilir. Alert çalışır. Runbook uygulanır. Öğrenci production bakımının geliştirme kadar önemli olduğunu öğrenir.

İyi Bir E-Ticaret Yazılımcısı Bu Problemi Nasıl Ele Alır?

İyi bir e-ticaret yazılımcısı yalnızca hata sayfası tasarlamaz. Ürün lifecycle'ını, SEO etkisini, customer journey'yi, observability ihtiyacını, automation fırsatını ve sonucu nasıl ölçeceğini birlikte düşünür. Problem “hangi görseli koyalım?” sorusuyla başlamaz. Önce URL neden kayboldu, yeni karşılık var mı ve doğru HTTP sinyali ne olmalı soruları cevaplanır. Ardından recovery UX ve ticari ölçüm eklenir.

Sadece Hata Sayfası Tasarlamaz

UI problemin yalnızca görünen kısmıdır. Kaynak katalog, routing veya search index olabilir. Developer root cause'u bulmalıdır. UI yine de güvenli fallback sağlamalıdır. Sistemik çözüm ile kullanıcı deneyimi birlikte yürütülür.

Ürün Lifecycle'ını Anlar

Stok yokluğu ile ürün kaldırma arasındaki farkı bilir. Successor relation kullanır. Hard delete'in URL etkisini değerlendirir. Event-driven state sync tasarlayabilir. Böylece yanlış 404 üretimi azalır.

SEO Etkisini Düşünür

HTTP, sitemap, canonical ve internal link davranışlarını değerlendirir. Ana sayfaya toplu redirect gibi kolay çözümlerden kaçınır. Search Console ve log verisini kullanır. Migration planına URL mapping ekler. SEO requirement'ı test edilebilir kontrata çevirir.

Customer Journey'yi Düşünür

Kullanıcının neden o URL'ye geldiğini anlamaya çalışır. Search ve relevant product önerileri sunar. Mobile ve accessibility davranışını test eder. Recovery funnel ölçer. Teknik çözümün ticari deneyime nasıl yansıdığını görür.

Observability Kurar

Request, route, referrer ve latency loglanır. Human ve bot traffic ayrılır. Spike alert oluşturulur. Dashboard owner bilgisi taşır. Incident sırasında kök neden hızlı bulunur.

Automation Ekler

Lifecycle event redirect ve sitemap update tetikleyebilir. CI/CD status contract test çalıştırır. Scheduled registry audit chain bulur. Search index reconciliation otomatik yapılır. Manuel hata ihtiyacı azaltılır.

Sonucu Ölçer

Recovery rate ve conversion metrikleri izlenir. Yalnızca 404 sayısının azalması başarı değildir. Yanlış redirect gerçek 404'ü gizleyebilir. A/B test UX değişikliklerini doğrular. Recovered revenue business etkisini görünür yapar.

404 Stratejisi İçin Ekipler Arası Sorumluluk

404 stratejisi Product, E-Commerce, Engineering, SEO, UX, Data, DevOps ve Customer Support ekiplerinin ortak alanıdır. Tek bir ekip bütün kararları doğru veremez çünkü ürün kaldırma ticari, HTTP teknik, redirect SEO ve recovery UX kararları içerir. Sorumluluk sınırları net tanımlandığında iş birbirine atılmaz. Owner ve approval modeli özellikle yüksek değerli URL'lerde önemlidir. RACI matrisi bu koordinasyonu somutlaştırabilir.

Product

Ürün lifecycle tanımlarını sahiplenir. Successor relation gibi business metadata'nın doğru olmasını sağlar. Ürün kaldırma nedenini belirler. Policy değişikliklerinde diğer ekiplerle çalışır. Hard delete kararını tek başına uygulamaz.

E-Commerce

Satış ve katalog operasyonunu yönetir. Stok ve kampanya state'lerini takip eder. Replacement ürün doğruluğunu kontrol eder. Recovery önerilerinin ticari uygunluğunu değerlendirir. Revenue metriklerini izler.

Engineering

Resolver, routing ve redirect registry altyapısını geliştirir. Test ve monitoring kurar. Performance ve availability sorumluluğunu taşır. Lifecycle eventleri entegre eder. Incident fixlerini uygular.

SEO

Status, redirect, canonical ve sitemap policy belirler. Search Console ve crawl analizini yapar. Migration mapping review'a katılır. High-value broken URL'leri önceliklendirir. Organik performansı takip eder.

UX

Custom 404 arayüzünü ve CTA hiyerarşisini tasarlar. Mobile ve accessibility gereksinimlerini kapsar. Kullanıcı araştırması yapabilir. A/B test varyantlarını oluşturur. Copy tonunu içerik ekibiyle belirler.

Data

Recovery funnel ve dashboard geliştirir. Attribution tanımını netleştirir. Recommendation modeli varsa performansını ölçer. Bot classification analizi yapabilir. Experiment istatistiğini destekler.

DevOps

CDN, edge, deployment ve alerting altyapısını yönetir. Release marker monitoring'e ekler. Incident rollback mekanizmasını sağlar. Cache invalidation güvenilirliğini takip eder. WAF ve rate limit ekipleriyle koordinasyon kurar.

Customer Support

Kullanıcı şikâyetlerinden broken URL örnekleri toplar. Kritik customer journey problemlerini engineering'e aktarır. Hata mesajının anlaşılır olup olmadığı konusunda geri bildirim verir. Ticket trendleri risk score'a katkı sağlayabilir. Kişisel veriler analytics'e taşınmadan önce korunmalıdır.

404 RACI Matrisi

404 RACI matrisi ürün silme kararı, redirect kararı, SEO review, recommendation logic, UX, monitoring ve incident response görevlerinde kimin Responsible, Accountable, Consulted ve Informed olduğunu açıklar. Bu model özellikle büyük organizasyonlarda aynı işin farklı ekipler arasında kaybolmasını önler. Örneğin product ürünün kaldırıldığını belirlerken SEO redirect relevance review yapabilir ve engineering teknik uygulamayı gerçekleştirir. Incident response DevOps ve engineering liderliğinde yürürken e-commerce etkiyi değerlendirir. RACI düzenli olarak ekip yapısına göre güncellenmelidir.

Ürün Silme Kararı

Product ve commerce business kararını verir. SEO ve engineering etkileri konusunda consulted olabilir. Hard delete yerine lifecycle event uygulanır. Owner kararı audit trail'e yazar. URL davranışı ayrı policy ile belirlenir.

Redirect Kararı

Deterministik mapping automation tarafından üretilebilir. High-value belirsiz eşleşmeler SEO review alır. Product successor bilgisini sağlar. Engineering registry kaydını uygular. Decision reason loglanır.

SEO Review

SEO ekip status ve relevance politikasını denetler. Search performance verisiyle öncelik verir. Teknik implementation engineering sorumluluğundadır. Product business context sağlar. Review bütün URL'lerde manuel olmak zorunda değildir.

Recommendation Logic

Data veya search ekibi scoring modelini geliştirir. Product iş kurallarını sağlar. SEO automatic redirect sınırlarını kontrol eder. UX sunum şeklini tasarlar. Engineering API availability'yi sağlar.

UX

UX hata mesajı ve component hiyerarşisinden sorumludur. SEO ve product copy context sağlar. Engineering implementation yapar. Accessibility QA tarafından doğrulanır. A/B test data ekibiyle ölçülür.

Monitoring

Engineering ve DevOps teknik metrikleri kurar. Data recovery dashboard'u geliştirir. SEO Search Console sinyallerini ekler. Owner alert rule'ları tanımlar. Her alarmın runbook'u olmalıdır.

Incident Response

Engineering ve DevOps teknik müdahaleyi yürütür. Product ve commerce business impact verir. SEO trafik riskini değerlendirir. Support kullanıcı etkisini paylaşır. Post-review action items farklı ekiplere atanabilir.

404 Policy Nasıl Hazırlanmalı?

Kurumsal 404 policy ürün state'leri, HTTP status kuralları, redirect kuralları, relevance threshold, exception, monitoring, owner ve review periyodu alanlarını kapsamalıdır. Doküman yalnızca SEO ekibinin bildiği rehber olmamalı, kod ve testlerle bağlantılı olmalıdır. Policy değiştiğinde resolver rule version güncellenebilir. Exception'lar sınırsız serbest metin yerine açık onay süreciyle yönetilmelidir. Düzenli review yeni ürün ve platform ihtiyaçlarına uyumu korur.

Ürün State'leri

ACTIVE, OUT_OF_STOCK, REPLACED ve REMOVED gibi state'ler açık tanımlanır. Her state'in business anlamı yazılır. Geçiş koşulları belirtilir. Product ve engineering aynı isimleri kullanır. Belirsiz “deleted” state mümkün olduğunca azaltılır.

HTTP Status Kuralları

Her state için varsayılan HTTP davranışı belirlenir. Out-of-stock 200, true missing 404 gibi temel kurallar yazılır. Exception senaryoları ayrıca belirtilir. Framework implementation bu policy'yi uygular. Contract test aynı beklentileri kullanır.

Redirect Kuralları

Exact URL move ve successor ilişkisinde 301 koşulları tanımlanır. Ana sayfaya toplu redirect yasaklanabilir. Chain ve loop sınırları belirtilir. Temporary redirect kullanım alanları açıklanır. Registry owner sorumluluğu tanımlanır.

Relevance Threshold

Automatic redirect için minimum score tanımlanır. Medium confidence suggestion state'e gider. High-value URL review kuralı eklenebilir. Threshold model version ile ilişkilendirilir. A/B test sonuçları periyodik review'a girer.

Exception

Hukuki kaldırma veya özel kampanya gibi istisnalar olabilir. Exception'ın owner ve expiry tarihi bulunmalıdır. Kalıcı istisnalar da gerekçeli olmalıdır. Çok sayıda exception policy'nin yetersiz olduğunu gösterebilir. Audit düzenli yapılmalıdır.

Monitoring

404 rate, soft 404, chain ve recovery KPI'ları tanımlanır. Alert threshold yazılır. Dashboard source belirlenir. Bot filtering metodolojisi açıklanır. Monitoring policy implementation kadar önemlidir.

Owner

Policy'nin kurumsal sahibi bulunmalıdır. Teknik ve SEO owner farklı olabilir. Değişiklik onay süreci tanımlanır. Incident sırasında karar yetkisi açık olur. Ownership ekip değişikliklerinde güncellenir.

Review Periyodu

Policy üç veya altı ayda bir gözden geçirilebilir. Büyük migration sonrası özel review yapılabilir. KPI ve incident verisi değişiklik gerekçesi sağlar. Framework veya search engine değişiklikleri de değerlendirilir. Doküman yaşayan süreç olmalıdır.

Örnek E-Ticaret 404 Karar Matrisi

Karar matrisi sık karşılaşılan senaryoları hızlı ve tutarlı biçimde çözmeyi sağlar. URL yanlış yazılmışsa 404 + Search, aynı sayfa yeni URL'ye taşınmışsa 301, ürün geçici stok dışıysa 200 + Out-of-Stock UX uygulanabilir. Kalıcı kaldırılan ürünün halefi varsa relevance doğrulanarak 301, halefi yoksa 404 veya 410 + Alternatives tercih edilir. Kalıcı kaldırılmış boş kategori ise 404 veya gerçek yeni kategoriye 301 alabilir. Bu matris otomatik resolver kurallarının başlangıç noktası olabilir.

URL Yanlış Yazılmış

System exact registry match bulamaz. Typo resolver düşük veya orta confidence verebilir. Yanlış hedefe otomatik taşımak risklidir. Search güvenli fallback sunar. Hata gerçek 404 olarak kalır.

404 + Search

HTTP 404 döner. Search box görünür olur. URL'den anlamlı query çıkarılırsa pre-fill yapılabilir. Typo suggestion sunulabilir. Kullanıcı seçimi kontrol eder.

Aynı Sayfa Yeni URL'ye Taşınmış

Kaynak ve hedef ilişkisi kesindir. Registry exact mapping taşır. Kullanıcı aynı içeriğin yeni adresine gitmelidir. Search veya 404 göstermeye gerek yoktur. Internal links yeni URL'ye güncellenir.

301

Kalıcı redirect uygulanır. Destination final URL olmalıdır. Chain önlenir. Sitemap yalnızca yeni URL'yi içerir. Contract test mapping'i doğrular.

Ürün Geçici Stok Dışı

Ürün kaybolmamıştır. PDP bilgi değeri taşır. Kullanıcı stok durumunu görmelidir. Search engine geçerli ürün içeriğine ulaşır. URL silinmez.

200 + Out-of-Stock UX

HTTP 200 korunur. Availability OutOfStock gösterilir. Add-to-cart devre dışı olabilir. Back-in-stock ve benzer ürün seçenekleri sunulur. Structured data sayfayla uyumlu tutulur.

Ürün Kalıcı Kaldırılmış ve Halefi Var

Successor relation önemli sinyaldir. Yine de kullanıcı niyeti doğrulanır. Yeni ürün aynı işlevi karşılamalıdır. Hedef aktif olmalıdır. High-value URL'lerde review uygulanabilir.

Relevance Doğrulanır → 301

Score eşik üzerindeyse 301 oluşturulur. Registry reason PRODUCT_REPLACED olabilir. Eski URL sitemap'ten çıkarılır. Search index yeni ürünü gösterir. Redirect davranışı analytics ile izlenir.

Ürün Kalıcı Kaldırılmış ve Halefi Yok

Gerçek yeni hedef yoktur. Alakasız category veya homepage redirect yapılmamalıdır. Kullanıcıya arama ve benzer ürün önerileri sunulur. URL doğru bulunamayan state'e geçer. Backlink varsa outreach ayrıca değerlendirilebilir.

404 / 410 + Alternatives

Policy'ye göre 404 veya 410 döndürülür. Dynamic recommendation ürün bağlamını kullanır. Search fallback bulunur. Sitemap ve internal linkler temizlenir. Recovery rate ölçülür.

Boş Kategori Kalıcı Olarak Kaldırılmış

Yeni taxonomy karşılığı aranır. Bire bir hedef varsa redirect uygundur. Split durumda tek hedef risklidir. Kategori tamamen sona erdiyse 404 olabilir. Internal navigation güncellenmelidir.

404 veya Uygun Yeni Kategoriye 301

Karar relevance'a dayanır. Yeni kategori ürün kapsamını karşılıyorsa 301 uygulanır. Aksi durumda 404 kullanıcıya alternatif kategori seçenekleri sunar. Sitemap eski URL'yi çıkarır. Mapping test edilir.

Smart 404 Minimum Viable Architecture

Minimum viable smart 404 için Correct HTTP Response, Branded Template, Site Search, Category Suggestions, Popular Products ve Basic Analytics yeterli olabilir. Semantic recommendation veya kişiselleştirme ilk gün zorunlu değildir. Önce gerçek 404 status code ve kullanıcıya açık recovery yolu sağlanmalıdır. Ardından trafik ve recovery verisi toplanır. Bu yaklaşım düşük maliyetle hızlı değer üretir.

Correct HTTP Response

Temel koşul gerçek status code'dur. Missing resource 404 döner. Redirect gerekiyorsa 301 kullanılır. Frontend 200 shell hatası giderilir. Automated test bunu korur.

Branded Template

Marka header ve navigation korunur. Mesaj kısa ve anlaşılır olur. Responsive tasarım uygulanır. Gereksiz ağır medya kullanılmaz. Accessibility temel gereksinimleri karşılanır.

Site Search

Search görünür alanda bulunur. Query pre-fill opsiyoneldir. Search sonuçları güncel katalogdan gelir. Zero-result fallback bulunur. Search click analytics'e yazılır.

Category Suggestions

Top kategoriler veya route context'e göre ilgili kategori gösterilebilir. Broken category link olmamalıdır. Çok fazla seçenek sunulmaz. Mobile düzen sade tutulur. Category click ölçülür.

Popular Products

Cached popüler ürünler kolay recommendation fallback sağlar. Ürünler stokta olmalıdır. Site geneli veya kategori bazlı liste kullanılabilir. Güncelleme job'ı düzenli çalışır. Recommendation servisi gerektirmez.

Basic Analytics

404 view ve recovery click eventleri yeterli başlangıçtır. Botlar mümkün olduğunca ayrılır. Source URL ve route type kaydedilir. Dashboard top broken URLs gösterir. Daha sonra conversion attribution eklenebilir.

Smart 404 Seviye 2

İkinci seviyede Legacy URL Registry, Product Lifecycle Integration, Dynamic Alternatives, Broken Link Monitoring ve Search Console Integration eklenir. Sistem artık yalnızca kullanıcıyı kurtarmakla kalmaz, eski URL'nin neden kaybolduğunu da anlamaya başlar. Redirect kararları katalog lifecycle'a bağlanır. Internal broken links proaktif bulunur. SEO ve product ekipleri aynı URL geçmişi üzerinden çalışabilir.

Legacy URL Registry

Eski URL'ler ve yeni hedefler merkezi tutulur. Reason ve date alanları eklenir. Exact lookup hızlıdır. Chain audit yapılabilir. Edge integration mümkün olur.

Product Lifecycle Integration

Ürün state değişiklikleri resolver'a ulaşır. Out-of-stock ve removed ayrılır. Successor relation kullanılabilir. Search ve sitemap sync başlatılır. Manuel karar ihtiyacı azalır.

Dynamic Alternatives

Legacy product context'e göre benzer ürünler gösterilir. Marka ve kategori sinyalleri kullanılır. Stock filter uygulanır. Recommendation failure fallback'e düşer. CTR ve conversion ölçülür.

Broken Link Monitoring

Crawler ve server log internal 404 kaynaklarını bulur. Sitewide source'lar yüksek öncelik alır. CI/CD yeni broken link girişini azaltır. Alert spike durumunda çalışır. Owner ekip dashboard'da görünür.

Search Console Integration

Not Found ve Soft 404 raporları monitoring'e eklenebilir. URL Inspection manual review için kullanılır. Search impressions priority score'a katkı sağlar. Fix sonrası validation yapılır. Search Console server log'un tamamlayıcısıdır.

Smart 404 Seviye 3

Üçüncü seviyede Semantic Search, Personalization, Automated Redirect Scoring, Revenue Attribution, A/B Testing ve Anomaly Detection sisteme eklenir. Bu aşamada 404 yalnızca teknik bakım değil data-driven recovery platformuna dönüşür. Ancak gelişmiş özelliklerin temeli hâlâ doğru HTTP ve lifecycle state'tir. Semantic model yanlış temel veriyi düzeltemez. İleri otomasyon belirli confidence ve business rule sınırları içinde çalışmalıdır.

Semantic Search

Legacy ürün description ve attribute embedding'i kullanılır. Güncel katalogda benzer adaylar bulunur. Category ve market filtresi uygulanır. Sonuçlar recommendation olarak gösterilir. Auto redirect yalnızca semantic score'a dayanmaz.

Personalization

Consent varsa session veya account sinyalleri ranking'e eklenebilir. Anonymous fallback korunur. Kayıp URL context'i temel relevance sinyalidir. Shared cache kişisel veri taşımamalıdır. Experiment ile gerçek katkı ölçülür.

Automated Redirect Scoring

Brand, category, attribute ve price similarity puanı oluşturur. Business rules final guardrail sağlar. High confidence auto redirect olabilir. Medium confidence suggestion olur. Score version monitoring'e yazılır.

Revenue Attribution

404 session purchase'a kadar takip edilebilir. Attribution window tanımlanır. Recovery method ayrı dimension olur. Control group incremental impact değerlendirmeye yardımcı olur. Dashboard recovered revenue gösterir.

A/B Testing

Template ve recommendation varyantları test edilir. Bot trafik sample'dan çıkarılır. Recovery rate primary metric olabilir. Downstream conversion izlenir. Experiment sonucu confidence modelini kalibre eder.

Anomaly Detection

404 time series otomatik analiz edilir. Deployment ve catalog eventleri context sağlar. Model route-level spike bulabilir. Alert insan review gerektirir. False positive zamanla azaltılır.

404 Olgunluk Modeli

404 olgunluk modeli Seviye 0 Default Server 404, Seviye 1 Branded Static 404, Seviye 2 Search ve Navigation, Seviye 3 Dynamic Product Recovery, Seviye 4 Lifecycle-Driven Resolver ve Seviye 5 Personalized ve Data-Driven Recovery aşamalarından oluşabilir. Her şirketin doğrudan beşinci seviyeye çıkması gerekmez. Trafik, katalog büyüklüğü ve ekip kapasitesi yatırım seviyesini belirler. Önce temel HTTP doğruluğu çözülmelidir. Daha yüksek seviye yanlış temeli yalnızca daha pahalı hâle getirir.

Seviye 0 — Default Server 404

Sunucunun standart hata metni gösterilir. Navigation bulunmayabilir. Analytics yoktur. Teknik olarak status doğru olabilir. Kullanıcı recovery'si zayıftır.

Seviye 1 — Branded Static 404

Marka tasarımı ve temel linkler eklenir. Header korunur. Home ve kategori bağlantıları bulunur. HTTP 404 doğru kalır. Kullanıcı deneyimi ilk kez kontrol altına alınır.

Seviye 2 — Search ve Navigation

Site search ve aktif kategoriler eklenir. Kullanıcı kendi yolunu bulabilir. Basic analytics recovery click ölçer. Popular products eklenebilir. Dynamic product context henüz sınırlıdır.

Seviye 3 — Dynamic Product Recovery

URL'den product context çözülür. Relevant alternatives ve inventory filtering eklenir. Recovery funnel izlenir. Recommendation failure fallback ile yönetilir. Kullanıcı niyeti daha iyi korunur.

Seviye 4 — Lifecycle-Driven Resolver

PIM ve ERP eventleri URL kararını tetikler. Redirect registry merkezi hâle gelir. Sitemap ve search index otomatik senkronize olur. HTTP decision product state'e dayanır. Manuel operasyon azalır.

Seviye 5 — Personalized ve Data-Driven Recovery

Semantic matching ve personalization sıralamayı iyileştirir. Confidence-based redirect kullanılır. Experimentation sürekli çalışır. Revenue optimization ölçülür. Human-controlled business rules final sınırı korur.

Seviye 0 — Default 404

Default 404 en temel seviyedir ve çoğu server kurulumu bunu otomatik sağlar. Teknik hata metni vardır, recovery yoktur ve monitoring sınırlıdır. Bu durum küçük bir demo için yeterli olabilir ancak e-ticaret kullanıcı deneyimi için zayıftır. Kullanıcı geri düğmesine basmak dışında ne yapacağını bilmeyebilir. İlk iyileştirme branded template ve doğru navigation eklemektir.

Teknik Hata Metni

Server generic “Not Found” mesajı gösterir. Marka dili yoktur. Kullanıcı teknik kodla karşılaşabilir. HTTP status genellikle doğrudur. Bu teknik doğruluk korunarak UI geliştirilebilir.

Recovery Yok

Search ve category link bulunmaz. Kullanıcı browser back kullanır. Satın alma niyeti kolayca kaybolur. Recovery rate ölçülemez. Branded template ilk hızlı kazanımdır.

Monitoring Yok

404 yalnızca access log içinde kalabilir. Human ve bot ayrımı yapılmaz. Top broken URL bilinmez. Incident spike geç fark edilir. Basic dashboard ciddi görünürlük sağlar.

Seviye 1 — Branded 404

Branded 404 marka tasarımı, ana sayfa ve navigation bileşenlerini hata deneyimine taşır. Kullanıcı doğru sitede olduğunu anlar ve temel bölümlere dönebilir. HTTP status yine 404 olarak kalmalıdır. Bu seviye düşük geliştirme maliyetiyle kullanıcı deneyimini belirgin biçimde iyileştirir. Sonraki adım site search ve analytics eklemektir.

Marka Tasarımı

Renk ve typography normal siteyle uyumlu olur. Büyük dekoratif öğeler zorunlu değildir. Sayfa hızlı yüklenir. Kullanıcı marka güvenini kaybetmez. Accessibility korunur.

Ana Sayfa

Home link kolay erişilebilir olur. Logo da normal davranışını sürdürebilir. Ancak home tek CTA olmamalıdır. Kullanıcı belirli ürün arıyorsa daha iyi recovery yolu gerekir. Search sonraki aşamada eklenebilir.

Navigation

Ana kategori navigasyonu kullanıcının yeniden keşfe başlamasını sağlar. Broken link içermemelidir. Mobile menu normal siteyle aynı olmalıdır. Çok geniş mega menu performance'ı etkilememelidir. En önemli kategoriler yeterlidir.

Seviye 2 — Search-Enabled 404

Search-enabled 404 site search, categories, popular products ve analytics bileşenlerini ekler. Kullanıcı artık hata sayfasından kendi hedefini aktif biçimde yeniden bulabilir. Popular products generic fallback sağlar. Analytics hangi recovery aracının kullanıldığını gösterir. Bu seviye birçok orta ölçekli e-ticaret sitesi için yüksek fayda sağlayabilir.

Site Search

Search box görünür olur. Typo correction kullanılabilir. Query event kaydedilir. Search index güncel olmalıdır. Zero-result fallback sağlanır.

Categories

Ana veya bağlamsal kategoriler gösterilir. Linkler active state kontrolünden geçer. Mobile tasarım sade tutulur. Category click ölçülür. Kullanıcı katalog keşfine devam eder.

Popular Products

Cached bestseller listesi gösterilebilir. Stok filtrelenir. Görseller optimize edilir. Ürün sayısı sınırlı tutulur. Click sonrası conversion izlenebilir.

Analytics

404 view ve recovery click eventleri eklenir. Route type ve source kaydedilir. Bot trafiği ayrıştırılır. Dashboard temel KPI'ları gösterir. Sonraki seviye için data baseline oluşur.

Seviye 3 — Dynamic Commerce 404

Dynamic Commerce 404 Product Context, Relevant Alternatives, Inventory Filtering ve Recovery Funnel bileşenlerini ekler. Sistem artık eski URL'nin hangi ürünle ilişkili olduğunu anlamaya çalışır. Kullanıcıya generic bestseller yerine daha yakın seçenekler gösterilir. Inventory filter ikinci broken deneyimi önler. Recovery funnel önerilerin gerçek ticari etkisini ölçer.

Product Context

Legacy URL registry ve slug parser kullanılır. Old SKU çözümlenebilir. Category ve brand bilgisi çıkarılır. Confidence score hesaplanır. Context bulunmazsa generic fallback çalışır.

Relevant Alternatives

Same family ve similar product adayları çıkarılır. Relevance threshold uygulanır. Kullanıcıya birkaç güçlü seçenek gösterilir. Low confidence sonuçlar gizlenebilir. Search her zaman bulunur.

Inventory Filtering

Recommendation list stok kontrolünden geçer. Region-specific availability uygulanır. Cache invalidation inventory eventlerine bağlanır. Out-of-stock ürün ikinci çıkmaz yaratmaz. Backorder policy ayrı uygulanabilir.

Recovery Funnel

404 view'dan purchase'a kadar eventler bağlanır. Recovery method dimension olarak tutulur. Product view ve add-to-cart oranları izlenir. A/B test yapılabilir. Revenue attribution başlatılabilir.

Seviye 4 — Lifecycle-Driven Architecture

Lifecycle-driven architecture PIM/ERP Events, Redirect Registry, Automated HTTP Decision, Sitemap Sync ve Search Index Sync bileşenlerini birleştirir. Ürün state değiştiğinde URL davranışı otomatik güncellenir. Redirect kararları manuel spreadsheet üzerinden yürütülmek zorunda kalmaz. Search index ve sitemap aynı lifecycle event'i takip eder. Büyük kataloglarda bu seviye operasyon kalitesini ciddi biçimde artırır.

PIM/ERP Events

Ürün state değişiklikleri event olarak yayınlanır. Successor ve stock context payload'da bulunabilir. Consumer'lar kendi sistemini günceller. Event delivery monitoring yapılır. Reconciliation kayıp eventleri düzeltir.

Redirect Registry

Source ve destination merkezi tutulur. Reason, owner ve review date bulunur. Edge snapshot üretilebilir. Chain ve loop audit otomatik çalışır. Lifecycle event yeni mapping oluşturabilir.

Automated HTTP Decision

Resolver state machine'den karar üretir. Out-of-stock 200, exact move 301 ve no-match 404 gibi kurallar uygulanır. Exception policy bulunur. Reason code loglanır. Contract test davranışı korur.

Sitemap Sync

Removed URL otomatik çıkarılır. Yeni canonical URL eklenir. Redirect source sitemap'te kalmaz. Job failure alert üretir. Periodic crawl doğrulama sağlar.

Search Index Sync

Removed product search index'ten çıkarılır. Replacement ürün eklenir. Freshness lag ölçülür. Search click 404 oranı KPI olur. Reconciliation katalog ile index'i karşılaştırır.

Seviye 5 — Intelligent Recovery Platform

Intelligent Recovery Platform Semantic Matching, Personalization, Confidence-Based Redirect, Experimentation ve Revenue Optimization özelliklerini kullanır. Bu seviye yüksek trafik ve büyük kataloglarda anlamlı olabilir. Model tabanlı sistemler yine lifecycle ve business rule sınırları içinde çalışır. Her kararın açıklanabilir reason code'u bulunmalıdır. Amaç daha fazla otomasyon değil, doğru kullanıcıyı daha doğru hedefe daha hızlı ulaştırmaktır.

Semantic Matching

Legacy ürün embedding'i güncel katalogla karşılaştırılır. Kategori ve market filter uygulanır. Similarity score recommendation'a katkı sağlar. Exact mapping her zaman önceliklidir. Semantic sonuç doğrudan kesin gerçek kabul edilmez.

Personalization

Session preference ranking'i iyileştirebilir. Consent gereksinimleri korunur. Anonymous fallback eşdeğer kalitede çalışmalıdır. Product context temel sinyal olmalıdır. Personalization business outcome ile test edilir.

Confidence-Based Redirect

High confidence otomatik redirect alabilir. Medium confidence suggestion olur. Low confidence search fallback'e gider. Threshold kategori ve user behavior ile kalibre edilir. Critical mapping human review alabilir.

Experimentation

Copy, layout ve recommendation varyantları test edilir. Primary KPI recovery veya revenue olabilir. Bot sample'dan çıkarılır. Test yeterli süre çalıştırılır. Sonuçlar policy ve model değişikliğine aktarılır.

Revenue Optimization

Recovered revenue ve revenue per 404 session izlenir. Relevance ticari ranking'in temel sınırı olarak kalır. Margin yalnızca benzer adaylarda tie-breaker olabilir. Incremental effect kontrol gruplarıyla ölçülür. Kullanıcı deneyimi kısa vadeli gelir için bozulmamalıdır.

404 Sayfasında Sık Yapılan Hatalar

En yaygın hatalar HTTP 200 döndürmek, bütün 404'leri ana sayfaya redirect etmek, ilgisiz ürüne yönlendirmek, geçici stok yokluğunda PDP'yi silmek, search bar koymamak, stokta olmayan alternatifler göstermek, redirect chain oluşturmak, sitemap'te ölü URL tutmak ve 404 trafiğini ölçmemektir. Bu hataların çoğu tek tek küçük görünür. Büyük katalogda ise yüz binlerce URL'ye yayılarak ciddi SEO ve UX problemi oluşturabilir. Öncelik önce HTTP doğruluğu ve internal link temizliğine verilmelidir. Ardından recovery ve otomasyon geliştirilir.

HTTP 200 Döndürmek

UI 404 gösterse bile network 200 ise soft 404 riski oluşur. Analytics başarısız isteği başarılı sayabilir. SSR veya server routing düzeltilmelidir. Response assertion CI/CD'ye eklenebilir. Framework catch-all davranışı kontrol edilmelidir.

Bütün 404'leri Ana Sayfaya Redirect Etmek

Kullanıcı bağlamı kaybolur. Gerçek broken URL ölçümü gizlenir. Search engine alakasız hedef görür. Product relevance kullanılmaz. Ana sayfa yalnızca opsiyonel recovery linki olmalıdır.

İlgisiz Ürüne Redirect

Yanlış ürün kullanıcı güvenini azaltır. Relevance threshold olmadan automation risklidir. Same category tek başına yeterli değildir. Medium confidence suggestion olarak gösterilmelidir. Redirect sonrası engagement izlenmelidir.

Geçici Stok Yokluğunda PDP'yi Silmek

Ürün URL'si gereksiz kaybolur. Organic history kesilir. Kullanıcı product info'ya ulaşamaz. 200 OutOfStock PDP daha sağlıklı olabilir. Lifecycle state stoktan ayrılmalıdır.

Search Bar Koymamak

Kullanıcı doğru ürünü kendi kelimeleriyle bulamaz. Navigation tek seçenek olur. Generic 404'lerde search güçlü recovery aracıdır. Mobile görünürlüğü önemlidir. Search interaction ölçülebilir.

Stokta Olmayan Alternatifler Göstermek

Kullanıcı ikinci kez başarısız ürün deneyimi yaşar. Recommendation stock filter kullanmalıdır. Search index freshness yeterli değilse commerce API doğrulanabilir. Cache invalidation uygulanır. Backorder açık etiketlenmelidir.

Redirect Chain Oluşturmak

Her migration yeni hop ekler. User ve bot ek network isteği yapar. Registry chain audit çalıştırmalıdır. Source direct final target'a bağlanır. Internal link final URL'yi kullanır.

Sitemap'te Ölü URL Tutmak

Arama motoruna çelişkili sinyal gönderilir. Removed ve redirected URL'ler sitemap'ten çıkarılmalıdır. Lifecycle event sync işlemini otomatikleştirebilir. Periodic validation uygulanır. Sitemap yalnızca geçerli canonical URL'leri göstermelidir.

404 Trafiğini Ölçmemek

Ölçüm yoksa high-value broken URL bilinmez. Deployment spike geç fark edilir. Recovery UX'in etkisi görülemez. Server log ve analytics temel veri sağlar. Dashboard teknik ve ticari metrikleri birleştirir.

Teknik Anti-Pattern'ler

Catch-All Route + HTTP 200, frontend'de “Not Found” yazıp status'u değiştirmemek, database record yoksa direkt homepage redirect, sonsuz redirect, recommendation API çalışmazsa 500 vermek ve bot isteklerinde pahalı recommendation çağrısı teknik anti-pattern örnekleridir. Bunlar kısa vadede uygulamayı kolaylaştırıyor gibi görünür. Uzun vadede soft 404, performance ve debugging sorunları üretir. Resolver karar katmanı ve güvenli fallback bu problemleri azaltır. Regression testler hataların geri gelmesini engeller.

Catch-All Route + HTTP 200

Catch-all route her URL'yi frontend shell'e düşürebilir. Invalid path de 200 olur. Server gerçek route state'ini bilmelidir. Unknown route 404 üretmelidir. Framework config automated test ile doğrulanır.

Frontend'de “Not Found” Yazıp Status'u Değiştirmemek

Client-side component yalnızca görsel state'i değiştirir. Initial HTTP response 200 kalır. SSR veya edge çözümü gerekir. Network test zorunludur. QA sadece ekran görüntüsüne bakmamalıdır.

Database Record Yoksa Direkt Homepage Redirect

Kayıt bulunamaması yeni hedef bulunduğu anlamına gelmez. Legacy registry ve archive kontrolü yapılmalıdır. Hiç karşılık yoksa 404 daha doğrudur. Homepage redirect user intent'i kaybeder. Monitoring gerçek problemi gizleyebilir.

Sonsuz Redirect

Loop kullanıcıyı tamamen engeller. Registry create sırasında cycle detection yapılmalıdır. Runtime hop limit bulunmalıdır. Production alert yüksek severity taşımalıdır. Mapping graph düzenli audit edilmelidir.

Recommendation API Çalışmazsa 500 Vermek

Recommendation enhancement'tır. Servis failure temel 404 page'i bozmaz. Timeout ve circuit breaker uygulanır. Static fallback render edilir. 404 page availability ayrı tutulur.

Bot İsteklerinde Pahalı Recommendation Çağrısı

Botlar büyük request hacmi üretebilir. Her istekte vector search maliyeti gereksizdir. Bot classification ve route context erken yapılır. Lightweight 404 kullanılır. Search engine botuna doğru status yeterlidir.

SEO Anti-Pattern'leri

Redirect Everything, sitemap'te 404, Internal Links to 404, Redirect Chains, yanlış canonical, Soft 404 ve boş Category Pages e-ticaret teknik SEO'sunda sık görülen anti-patternlerdir. Bu sorunların ortak noktası URL state ile gerçek içerik state'inin ayrışmasıdır. Ekipler bir metriği düzeltmeye çalışırken başka sinyali bozabilir. Örneğin 404 sayısını sıfırlamak için her şeyi 301 yapmak kaliteyi artırmaz. Amaç URL'lerin gerçek durumunu doğru ve tutarlı biçimde ifade etmektir.

Redirect Everything

Her URL için hedef uydurmak yanlış stratejidir. Relevance düşükse 404 daha doğrudur. Redirect registry yalnızca gerçek mappingleri içermelidir. Search engine ve user intent aynı anda düşünülür. High confidence koşulu uygulanır.

Sitemap'te 404

Sitemap geçerli URL listesi olmalıdır. 404 URL'ler çıkarılmalıdır. Redirect source da tutulmamalıdır. Sync automation hatayı azaltır. Search Console sitemap raporları kontrol edilebilir.

Internal Links to 404

Internal broken links doğrudan düzeltilmelidir. Redirect varsa bile source link final URL'ye güncellenir. Crawler ve CI/CD kontrolü uygulanır. Sitewide template hataları önceliklidir. Search engine crawl yolu temizlenir.

Redirect Chains

Chains migration ve replacement geçmişinden doğar. Source final target'a güncellenmelidir. Hop count monitor edilir. Loop detection aynı graph üzerinde çalışır. Registry bakım periyodu tanımlanır.

Yanlış Canonical

404 sayfasına geçerli ürün canonical vermek çözüm değildir. Duplicate olmayan sayfaları zorla canonical'lamak da sorun yaratabilir. Canonical gerçek preferred URL ilişkisini ifade etmelidir. Redirect ve canonical rolleri ayrıdır. Automated audit tutarsızlıkları bulabilir.

Soft 404

200 dönen empty product page sık örnektir. Homepage redirect de ilişkisizse benzer problem oluşturabilir. Response status doğrulanmalıdır. Search Console sinyalleri izlenir. SSR veya server route çözümü uygulanır.

Boş Category Pages

Kalıcı biçimde boş ve indexlenebilir kategoriler kalite sorunu olabilir. Geçici boşluk farklı değerlendirilir. Category lifecycle state gerekir. Noindex, 404 veya 301 seçenekleri gerçek duruma göre seçilir. Her boş kategori aynı değildir.

UX Anti-Pattern'leri

Sadece “404” yazmak, navigation'ı kaldırmak, ana sayfaya tek CTA vermek, çok fazla CTA kullanmak, kullanıcı niyetini yok saymak ve mobile experience'ı unutmak 404 UX'inin yaygın hatalarıdır. Kullanıcı teknik hata kodunu çözmek zorunda değildir. Aradığı ürün veya kategoriye geri dönmek ister. Tasarım recovery'yi kolaylaştırmalı ve seçim sayısını kontrol altında tutmalıdır. Mobile ve accessibility testleri release kriterinin parçası olmalıdır.

Sadece “404” Yazmak

Kullanıcı 404 kodunun anlamını bilmeyebilir. Kısa açıklama eklenmelidir. Ne yapabileceği gösterilmelidir. Search veya navigation görünür olmalıdır. Teknik kod ikincil bilgi olarak kalabilir.

Navigation'ı Kaldırmak

Navigation kaldırıldığında kullanıcı çıkmaza sıkışır. Normal site header korunabilir. Kategori ve search kolay ulaşılır olur. Checkout gibi özel akışlarda farklı güvenli navigation gerekebilir. Context tasarımı belirler.

Ana Sayfaya Tek CTA

Home her kullanıcı için en iyi hedef değildir. Product 404'ünde alternative product daha ilgili olabilir. Search evrensel seçenek sunar. Home secondary link olarak kalabilir. Dynamic CTA recovery'yi hızlandırır.

Çok Fazla CTA

Çok seçenek karar yükünü artırır. Primary action belirlenmelidir. Birkaç secondary link yeterlidir. Header zaten genel navigation sağlar. A/B test optimum sayıyı gösterebilir.

Kullanıcı Niyetini Yok Saymak

Eski URL değerli context taşır. Generic bestseller listesi her durumda yeterli değildir. SKU ve category lookup yapılabilir. Referrer ek bağlam sağlar. Kullanıcının aradığı şeye yakın seçenekler önceliklenmelidir.

Mobile Experience'ı Unutmak

Desktop 404 tasarımı mobilde taşabilir. Search görünür kalmalıdır. Touch target yeterli olmalıdır. Carousel accessibility test edilmelidir. Performance düşük ağ koşulunda ölçülmelidir.

E-Ticaret İçin 404 Audit Nasıl Yapılır?

Kapsamlı 404 audit HTTP Status Audit, Internal Link Audit, Redirect Audit, Product Lifecycle Audit, Search Index Audit, Sitemap Audit, UX Audit ve Analytics Audit aşamalarını içerir. Yalnızca crawler ile 404 URL listesi çıkarmak yeterli değildir. Kaynakların neden kırıldığı, kullanıcıların nasıl geldiği ve recovery deneyiminin nasıl çalıştığı da değerlendirilmelidir. Audit sonunda her sorun owner ve priority ile backlog'a aktarılmalıdır. E-ticaret sitesi teknik SEO ve 404 hata optimizasyonu hizmeti değerlendirilirken bu geniş kapsam iyi bir kalite göstergesidir.

HTTP Status Audit

Geçerli ve invalid URL örnekleri test edilir. Soft 404 patternleri aranır. 301 ve 302 kullanımları kontrol edilir. 404 template status doğrulanır. Route bazında sonuçlar gruplanır.

Internal Link Audit

Crawler broken source ve destination listeler. Sitewide links öncelik alır. Redirect üzerinden giden internal links de güncellenir. Blog ve campaign içerikleri dahil edilir. Fix sonrası yeniden crawl yapılır.

Redirect Audit

Chain, loop ve broken destination bulunur. Relevance düşük mappingler manuel incelenir. Homepage bulk redirect patternleri aranır. Temporary redirectler review edilir. Registry kayıtları reason ve owner açısından kontrol edilir.

Product Lifecycle Audit

Out-of-stock ürünlerin yanlış 404 olup olmadığı incelenir. Removed ve replaced state'ler örneklenir. Successor mapping doğrulanır. Hard delete süreçleri değerlendirilir. Event sync coverage kontrol edilir.

Search Index Audit

Search result clickleri 404 üretmemelidir. Removed ürünlerin index'te kalıp kalmadığı kontrol edilir. Index freshness ölçülür. Zero-result query patternleri analiz edilir. Search lifecycle eventleri doğrulanır.

Sitemap Audit

4xx ve 3xx URL'ler sitemap'te aranır. Canonical ve indexability uyumu kontrol edilir. Lastmod kalitesi değerlendirilebilir. Sitemap generator source data incelenir. Sync automation failure logları kontrol edilir.

UX Audit

Search, navigation, CTA ve product alternatives test edilir. Mobile ve accessibility kontrolleri yapılır. Recommendation failure fallback denenir. Hata copy'si kullanıcıyı suçlamamalıdır. Time to recovery ölçülebilir.

Analytics Audit

404 page view eventinin gerçekten 404'leri ölçtüğü doğrulanır. Bot filtering incelenir. Recovery action eventleri test edilir. Conversion attribution tutarlılığı kontrol edilir. Dashboard formülleri dokümante edilmelidir.

İlk 30 Günlük 404 İyileştirme Planı

İlk 30 günde hedef 404 envanteri oluşturmak, soft 404 tespiti yapmak, internal broken links temizlemek, kritik redirectleri düzeltmek, basic custom 404 oluşturmak ve analytics events eklemektir. Bu aşamada gelişmiş recommendation motoruna ihtiyaç yoktur. Önce teknik temel ve görünürlük kurulmalıdır. High-value URL'ler hızlı aksiyon alır. Ay sonunda baseline metrikler hazır olur.

404 Envanteri

Server log, crawler ve Search Console verileri birleştirilir. URL'ler normalize edilir. Human ve bot segmenti ayrılır. Route type ve traffic eklenir. Priority listesi oluşturulur.

Soft 404 Tespiti

200 dönen not-found template patternleri aranır. Search Console örnekleri incelenir. SPA route'ları manuel test edilir. HTTP assertion otomasyona eklenir. En büyük pattern önce düzeltilir.

Internal Broken Links

Navigation ve high-traffic source'lar öncelik alır. Links final URL'ye güncellenir. Redirect üzerinden gitmekten kaçınılır. CI/CD checker kurulmaya başlanır. Fix sonrası crawl tekrarlanır.

Critical Redirect Fix

High-value legacy URL'lerin gerçek hedefi bulunur. Chain ve loop temizlenir. Homepage bulk redirect kaldırılır. Registry için temel data modeli oluşturulur. Mapping reason kaydedilir.

Basic Custom 404

Gerçek HTTP 404 ile branded template yayınlanır. Search ve navigation eklenir. Mobile ve accessibility temel testleri yapılır. Sayfa hızlı tutulur. Recommendation sonraki aşamaya bırakılabilir.

Analytics Events

404 view ve recovery click eventleri eklenir. Source URL ve route type kaydedilir. Bot filtering başlangıç seviyesi uygulanır. Dashboard top broken URLs gösterir. Baseline recovery rate hesaplanır.

31–60 Günlük Plan

31–60 gün arasında Product Lifecycle Rules, Redirect Registry, Category Rules, Dynamic Product Suggestions, Search Integration ve Dashboard geliştirilir. İlk ayda toplanan veri hangi URL tiplerinin en çok sorun ürettiğini gösterir. Bu bilgi automation önceliğini belirler. Ürün state ve URL state ayrımı resmi policy hâline getirilir. İkinci ayın sonunda 404 sistemi yalnızca tepki veren değil otomatik karar üreten yapıya yaklaşır.

Product Lifecycle Rules

State machine resmi hâle getirilir. Out-of-stock ve removed ayrılır. Successor metadata eklenir. HTTP mapping dokümante edilir. Contract test state örneklerini kapsar.

Redirect Registry

Source, destination, reason ve owner alanları oluşturulur. Existing redirects import edilir. Chain audit başlatılır. Edge integration planlanabilir. Review date policy tanımlanır.

Category Rules

Empty, removed ve merged category davranışı belirlenir. Taxonomy mapping saklanır. Facet policy eklenir. Sitemap state güncellenir. Category test seti oluşturulur.

Dynamic Product Suggestions

Legacy SKU ve category context kullanılır. Content-based recommendation başlangıç için yeterlidir. Stock filter uygulanır. Generic fallback korunur. CTR ve recovery ölçülür.

Search Integration

URL'den query pre-fill eklenir. Typo correction kullanılabilir. Zero-result fallback tasarlanır. Search index drift monitoring kurulur. Search click 404 rate izlenir.

Dashboard

Human 404 sessions ve recovery rate gösterilir. Internal broken links ve soft 404 eklenir. Route ve source filtreleri sağlanır. Owner ve priority listesi oluşturulur. Recovered revenue sonraki aşamaya hazırlanır.

61–90 Günlük Plan

61–90 gün arasında Semantic Recommendation Pilot, Confidence-Based Resolver, A/B Test, Revenue Attribution, Automated Regression Tests ve 404 Incident Alerts geliştirilebilir. Bu aşama ilk iki ayın temiz veri ve lifecycle temeline dayanmalıdır. Semantic sistem yanlış katalog state'i üzerine kurulursa sonuç güvenilir olmaz. Confidence modeli düşük riskli recommendation alanında test edilerek başlanabilir. Üçüncü ay sonunda teknik, UX ve ticari KPI'lar aynı platformda izlenebilir.

Semantic Recommendation Pilot

Sınırlı ürün kategorisi seçilir. Archive ve active katalog embedding oluşturulur. Offline relevance değerlendirilir. Production'da suggestion olarak test edilir. Automatic redirect kapalı tutulabilir.

Confidence-Based Resolver

Exact, high, medium ve low confidence seviyeleri tanımlanır. Business rule guardrail uygulanır. High confidence mapping küçük trafik grubunda denenebilir. Decision reason loglanır. Threshold davranış verisiyle kalibre edilir.

A/B Test

Static ve dynamic 404 karşılaştırılır. Recovery rate ve add-to-cart primary metric olabilir. Bot sample dışına alınır. Test yeterli trafik toplayana kadar sürer. Sonuçlar roadmap kararına dönüşür.

Revenue Attribution

404 session conversion eventleriyle bağlanır. Attribution window tanımlanır. Recovery method dimension eklenir. Revenue per session hesaplanır. Incremental effect için control group değerlendirilir.

Automated Regression Tests

URL contract suite CI/CD'ye bağlanır. Active, replaced ve invalid route örnekleri eklenir. Status, redirect, canonical ve hop count test edilir. Critical URL smoke test production'da çalışır. Incident sonrası yeni fixture eklenir.

404 Incident Alerts

Baseline ve anomaly threshold belirlenir. Human 404 spike yüksek priority taşır. Route ve release marker alert payload'a eklenir. Runbook hazır olur. False positive düzenli review edilir.

404 Audit Kontrol Listesi

404 audit kontrol listesinde Status Code Doğru mu, Soft 404 Var mı, Redirect İlgili mi, Redirect Chain Var mı, Sitemap Temiz mi, Internal Links Temiz mi, Kullanıcı Search Yapabiliyor mu, Alternatif Ürünler Stokta mı, Analytics Çalışıyor mu ve Mobile UX Uygun mu soruları bulunmalıdır. Bu liste düzenli teknik SEO bakımında kullanılabilir. Her maddenin test yöntemi belirlenirse kontrol kişiye bağlı olmaktan çıkar. Kritik sorunlar owner ve deadline ile takip edilmelidir. Audit sonucu yalnızca rapor değil uygulanabilir backlog üretmelidir.

Status Code Doğru mu?

Network response kontrol edilir. Invalid URL 404 mü bakılır. Out-of-stock PDP yanlışlıkla 404 olmamalıdır. Redirect doğru 3xx kullanmalıdır. Automated assertion eklenir.

Soft 404 Var mı?

200 dönen empty template aranır. Homepage redirect patternleri incelenir. Search Console verisi kontrol edilir. SPA route örnekleri test edilir. Root cause template seviyesinde çözülür.

Redirect İlgili mi?

Source ve target kullanıcı niyeti açısından karşılaştırılır. Same category tek başına yeterli sayılmaz. Successor relation aranır. Low relevance mapping kaldırılır. Medium confidence suggestion'a çevrilebilir.

Redirect Chain Var mı?

Final URL'ye kadar hop sayılır. Source direct target'a güncellenir. Loop ayrıca kontrol edilir. Internal links final URL'yi kullanır. Registry audit otomatik çalışabilir.

Sitemap Temiz mi?

4xx ve 3xx URL bulunmamalıdır. Canonical target listelenmelidir. Noindex policy doğrulanır. Lifecycle sync çalışır. Search Console sitemap raporu incelenebilir.

Internal Links Temiz mi?

Crawler source pages raporlar. Navigation ve footer yüksek öncelik alır. Blog ve campaign linkleri dahil edilir. Redirect üzerinden giden linkler direct güncellenir. CI/CD future regressions'ı önler.

Kullanıcı Search Yapabiliyor mu?

Search box görünür mü kontrol edilir. Mobile focus ve submit çalışır. Query pre-fill doğru mu test edilir. Zero-result fallback bulunur. Analytics search eventini yakalar.

Alternatif Ürünler Stokta mı?

Recommendation final inventory kontrolünden geçer. Cache freshness incelenir. Region availability doğrulanır. Out-of-stock adaylar filtrelenir. Product card ile PDP bilgisi uyumlu olur.

Analytics Çalışıyor mu?

404 view gerçek error response'ta tetiklenmelidir. Bot filtering uygulanır. Recovery eventleri duplicate olmamalıdır. Source URL güvenli biçimde kaydedilir. Conversion attribution test edilir.

Mobile UX Uygun mu?

İlk ekran mesaj ve primary CTA'yı göstermelidir. Search kolay kullanılmalıdır. Touch target yeterli olmalıdır. Carousel taşmamalıdır. Performance gerçek mobil cihazda test edilir.

Custom 404 Sayfası Kontrol Listesi

Custom 404 sayfası için Marka Tasarımı, Açık Mesaj, Search, Navigation, Alakalı Kategori, Alakalı Ürün, Home, Support, Performance ve Accessibility bileşenleri gözden geçirilmelidir. Her bileşen her kullanıcıya aynı ağırlıkta gösterilmek zorunda değildir. Product-context 404'te ürün önerisi öne çıkarken generic 404'te search daha güçlü primary action olabilir. Sayfa her durumda gerçek 404 status code döndürmelidir. Dynamic özellikler bozulduğunda sade fallback kullanılmalıdır.

Marka Tasarımı

Sayfa sitenin normal visual language'ini sürdürür. Kullanıcı başka domain'e geçtiğini düşünmez. Ağır dekorasyon kullanılmaz. Mobile tasarım korunur. Marka tonu yardımcı kalır.

Açık Mesaj

Ne olduğu kısa biçimde açıklanır. Kullanıcı suçlanmaz. Teknik jargon azaltılır. Ürün route'unda bağlamsal copy kullanılabilir. Sonraki adım hemen gösterilir.

Search

Arama görünürdür. Input label erişilebilirdir. Pre-fill yalnızca anlamlı context varsa yapılır. Autocomplete güncel katalogdan beslenir. Search eventleri ölçülür.

Navigation

Header veya temel kategoriler korunur. Broken link içermemelidir. Mobile menu çalışmalıdır. Çok geniş seçenek listesi kullanıcıyı yormamalıdır. Home erişimi her zaman bulunur.

Alakalı Kategori

Legacy path varsa yeni kategori çözümlenir. Yalnızca active category gösterilir. Çok genel kategori düşük priority alır. User intent korunur. Category click takip edilir.

Alakalı Ürün

Successor ve similar products sıralanır. Stock ve market filter uygulanır. Relevance threshold kullanılır. Çok fazla ürün gösterilmez. Recommendation failure fallback'e düşer.

Home

Home her zaman erişilebilir olabilir. Ancak otomatik redirect hedefi değildir. Logo doğal link sağlar. Secondary CTA olarak kullanılabilir. Kullanıcı isterse sıfırdan keşfe döner.

Support

Kritik akışlarda destek görünür olmalıdır. Contact veya yardım merkezi linki sunulabilir. Kullanıcıdan gereksiz teknik bilgi istenmez. Error context ticket'a otomatik eklenebilir. Hassas veri taşınmamalıdır.

Performance

Page hızlı yüklenmelidir. Recommendation initial render'ı bloklamaz. Image optimization uygulanır. Cache doğru kullanılır. Core Web Vitals izlenebilir.

Accessibility

Heading ve focus yapısı doğru olur. Screen reader mesajı anlaşılırdır. Contrast yeterlidir. Keyboard navigation çalışır. CTA metinleri açık olur.

Sık Sorulan Sorular

404 konusu basit bir status code gibi görünse de ürün lifecycle, SEO, routing ve kullanıcı deneyimi aynı noktada birleştiği için sık sık benzer sorular ortaya çıkar. Aşağıdaki cevaplar özellikle dinamik kataloglarla çalışan ekiplerin hızlı karar vermesine yardımcı olmak amacıyla hazırlanmıştır. Her senaryoda tek bir evrensel kural yerine kaynağın gerçek durumunu ve kullanıcı niyetini değerlendirmek gerekir. Büyük kataloglarda bu kararların policy ve resolver servisiyle otomatikleştirilmesi daha sağlıklıdır. Ayrıca sık sorulan sorular düzenli olarak gerçek Search Console ve support verileriyle güncellenebilir.

404 hatası nedir?

404, istenen URL üzerinde kaynak bulunamadığını ifade eden HTTP durum kodudur. Sunucunun çalışmadığı anlamına gelmez. Kullanıcıya custom hata sayfası gösterilebilir. Sayfa yine gerçek 404 status code döndürmelidir. Search ve navigation kullanıcıyı site içinde tutabilir.

404 hatası SEO'ya zarar verir mi?

Doğal ve doğru 404'ler tek başına SEO hatası değildir. Sorun internal linklerin 404'e gitmesi, sitemap'te ölü URL bulunması veya değerli taşınmış sayfaların yanlış yönetilmesidir. Soft 404 da teknik kaliteyi bozabilir. Katalogdan kaldırılmış ve karşılığı olmayan URL'nin 404 olması normaldir. Öncelik gerçek problemli patternleri bulmaktır.

Soft 404 nedir?

Sayfa bulunamadığını gösterdiği hâlde HTTP 200 dönmesi yaygın soft 404 örneğidir. Alakasız homepage redirectleri de benzer değerlendirmeye yol açabilir. Search Console bazı URL'leri soft 404 olarak raporlayabilir. Network response manuel doğrulanmalıdır. Gerçek missing resource 404 döndürmelidir.

404 ile 410 arasındaki fark nedir?

404 kaynak bulunamadığını söyler. 410 kaynağın bilerek ve kalıcı kaldırıldığını daha açık ifade eder. Her silinen ürün için 410 zorunlu değildir. Kurumsal policy tutarlı olmalıdır. UX açısından her iki sayfa da recovery seçenekleri sunabilir.

404 sayfası HTTP 200 döndürebilir mi?

Görsel olarak döndürebilir ama teknik olarak doğru yaklaşım değildir. Kullanıcı “bulunamadı” görürken istemci başarı sinyali alır. Bu soft 404 riskini artırır. SSR veya server route gerçek 404 üretmelidir. Automated status test bu problemi önler.

Silinen ürün 301 mi 404 mü olmalıdır?

Gerçek yeni karşılık varsa 301 kullanılabilir. Aynı ürünün yeni URL'si en açık örnektir. Doğrudan halef ürün de relevance doğrulanarak yönlendirilebilir. Karşılık yoksa 404 veya 410 daha doğrudur. Ana sayfaya toplu redirect önerilmez.

Stokta olmayan ürün sayfası silinmeli midir?

Geçici stok yokluğunda çoğu zaman hayır. PDP 200 ile canlı tutulabilir. Stok durumu açıkça gösterilir. Back-in-stock ve alternatif ürün seçenekleri sunulabilir. Ürün geri geldiğinde aynı URL kullanılmaya devam eder.

Kalıcı olarak üretimden kalkan ürün ne yapılmalıdır?

Önce successor olup olmadığı kontrol edilir. Gerçek yeni ürün varsa 301 düşünülebilir. Alternatif yoksa 404, 410 veya bilgi amaçlı archive PDP policy'lerinden biri seçilir. Backlink ve organik değer review önceliğini etkiler. Alakasız redirect yapılmamalıdır.

Tüm 404 sayfalarını ana sayfaya yönlendirmek doğru mudur?

Hayır. Kullanıcı niyetini kaybettirir. Gerçek 404 sayısını gizler. Alakasız redirect soft 404 riskini artırabilir. Yalnızca gerçek hedef varsa yönlendirme yapılmalıdır. Aksi durumda dynamic 404 recovery daha iyi seçenektir.

Ürün kategori sayfasına yönlendirilebilir mi?

Kategori gerçekten kullanıcının ihtiyacını karşılıyorsa değerlendirilebilir. Çok genel kategoriye otomatik redirect risklidir. Medium confidence durumda kategori linki öneri olarak gösterilebilir. Kullanıcı kendi seçimini yapar. Exact successor her zaman daha güçlü hedef olur.

Redirect chain SEO'yu etkiler mi?

Zincirler gereksiz crawl ve network adımı oluşturur. Eski kaynak mümkünse final hedefe doğrudan bağlanmalıdır. Chain count düzenli audit edilmelidir. Internal links final URL'yi kullanmalıdır. Looplar ise kritik teknik hatadır.

Boş kategori 404 vermeli midir?

Her boş kategori 404 olmamalıdır. Geçici ürünsüz kategori 200 kalabilir. Kalıcı kaldırılmış kategori için yeni karşılık varsa 301, yoksa 404 değerlendirilebilir. Noindex bazı geçerli fakat arama sonuçlarında istenmeyen sayfalarda kullanılabilir. Category lifecycle state ayrı modellenmelidir.

404 sayfasında ürün önerileri gösterilmeli midir?

Evet, ürün bağlamı güvenilir biçimde çıkarılabiliyorsa faydalıdır. Öneriler ilgili ve stokta olmalıdır. Recommendation servisi başarısızsa sayfa yine çalışmalıdır. Search ve navigation fallback olarak bulunmalıdır. CTR ve recovery rate ile performans ölçülebilir.

Dinamik 404 sayfası nedir?

Dinamik 404 URL, SKU, kategori veya session bağlamına göre farklı recovery içeriği gösterir. Herkese aynı generic ürün listesini sunmaz. Exact successor, similar products veya ilgili kategori çıkarabilir. HTTP yine gerçek 404 olabilir. Dynamic UI teknik status'u değiştirmek zorunda değildir.

404 sayfasında site içi arama bulunmalı mıdır?

Çoğu e-ticaret sitesi için evet. Search kullanıcının niyetini kendi kelimeleriyle yeniden ifade etmesini sağlar. URL'den query pre-fill yapılabilir. Typo correction faydalıdır. Zero-result recovery ayrıca tasarlanmalıdır.

Next.js uygulamasında gerçek 404 nasıl yönetilir?

Server-side veya framework'ün not-found mekanizması kullanılarak HTTP 404 üretimi sağlanmalıdır. Client-side component tek başına yeterli olmayabilir. Dynamic route product API state'ini response kararına aktarmalıdır. Redirect gerekiyorsa server seviyesinde yapılmalıdır. Test response status'u doğrulamalıdır.

SPA uygulamalarında soft 404 nasıl önlenir?

Server bütün route'lara kör 200 shell döndürmemelidir. SSR, edge middleware veya route resolver kullanılabilir. API product-not-found state'i HTTP response'a yansıtılmalıdır. Invalid route contract test edilmelidir. UI ve network aynı durumu söylemelidir.

404 hataları Google Search Console'da nasıl bulunur?

Page Indexing raporundaki Not Found ve Soft 404 bölümleri incelenebilir. URL Inspection kritik örnekleri doğrular. Search Console bütün requestleri göstermediği için server log da kullanılmalıdır. Internal link source için crawler yardımcı olur. Fix sonrası validation yapılabilir.

E-ticaret sitesinde 404 oranı nasıl ölçülür?

404 request sayısı toplam request'e bölünebilir. UX için human 404 sessions oranı daha anlamlı olabilir. Bot traffic ayrı tutulmalıdır. Route ve source segmentasyonu yapılmalıdır. Trend baseline ile karşılaştırılmalıdır.

AI ile 404 ürün önerileri yapılabilir mi?

Evet. Semantic search ve recommendation modelleri eski ürün bağlamından yeni seçenekler çıkarabilir. Stok ve business rule filtresi uygulanmalıdır. Model sonucu otomatik redirect için tek başına yeterli sayılmamalıdır. Suggestion kullanımı daha güvenlidir. Kullanıcı davranışı model kalibrasyonuna katkı sağlar.

Açık kaynak araçlarla akıllı 404 sistemi kurulabilir mi?

Evet. Search, vector database, observability ve recommendation için açık kaynak bileşenler kullanılabilir. Asıl ihtiyaç URL lifecycle ve business policy tasarımıdır. Tool seçimi bu kuralların yerini tutmaz. Küçük MVP search ve registry ile başlayabilir. Daha sonra semantic katman eklenebilir.

E-ticaret geliştirmek için en iyi programlama dili hangisidir?

Tek bir en iyi dil yoktur. Mevcut ekip, trafik, platform ve bakım gereksinimleri seçimde daha önemlidir. HTTP ve SEO prensipleri dil bağımsızdır. Backend ve frontend farklı teknolojiler kullanabilir. Sade ve sürdürülebilir architecture çoğu zaman trend dil seçiminden daha değerlidir.

Bir yazılımcı e-ticaret mimarisi öğrenmek için nereden başlamalıdır?

HTTP, routing ve database temelleri iyi başlangıçtır. Ardından ürün katalog modeli, search, cache ve analytics öğrenilebilir. Küçük bir demo mağazada lifecycle ve 404 resolver projesi uygulanabilir. Monitoring ve test eklemek production düşünme alışkanlığı kazandırır. Proje tabanlı öğrenme kavramları birbirine bağlamayı kolaylaştırır.

Dinamik e-ticaret sitelerinde 404 hata sayfaları nasıl yönetilmelidir?

Dinamik e-ticaret sitelerinde 404 hata sayfaları yalnızca dekoratif bir hata ekranı olarak yönetilmemelidir. Önce URL'nin gerçekten kayıp olup olmadığı, ürünün geçici stok dışı mı yoksa kalıcı kaldırılmış mı olduğu ve yeni bir karşılığı bulunup bulunmadığı belirlenmelidir. Gerçek kaynak yoksa HTTP 404 veya uygun durumda 410 döndürülürken kullanıcıya arama, ilgili kategori ve gerçekten yakın ürün seçenekleri sunulabilir. Product lifecycle, redirect registry, sitemap ve search index aynı state'i paylaşırsa yüz binlerce URL için manuel işlem ihtiyacı azalır. Dinamik E-Ticaret Mimarisinde Hata Sayfası (404) Stratejileri bu nedenle HTTP, UX, SEO ve katalog operasyonunun ortak politikası olarak ele alınmalıdır.

Silinen veya stoktan kaldırılan ürün sayfaları 404 mü yoksa 301 yönlendirmesi mi kullanmalıdır?

Geçici stok yokluğu ile kalıcı ürün kaldırma birbirinden ayrılmalıdır. Geçici stok dışı ürün çoğu durumda 200 PDP olarak yaşamaya devam etmeli, kullanıcıya stok durumu ve alternatifler gösterilmelidir. Kalıcı kaldırılan ürünün aynı URL'de yeni adresi veya gerçek successor ürünü varsa 301 kullanılabilir. Gerçek karşılık bulunmuyorsa 404 veya kurumsal politikaya göre 410 daha doğru olur. Yalnızca SEO değerini başka yere taşımak amacıyla ilgisiz ürün veya ana sayfaya redirect yapmak kullanıcı niyetini bozabilir.

E-Ticaret sitelerinde 404 ve soft 404 hataları SEO performansını nasıl etkiler?

Doğru 404'ler doğal web davranışıdır ve tek başına SEO problemi sayılmaz. Sorun, geçerli ve değerli URL'lerin yanlışlıkla 404 olması, internal linklerin bu adreslere gitmesi, ölü URL'lerin sitemap'te tutulması veya kullanıcıya hata mesajı gösterirken HTTP 200 dönülmesidir. Soft 404 arama motorlarının sayfanın gerçek durumunu yorumlamasını zorlaştırabilir. Yanlış redirectler de kaynak ile hedef arasındaki ilişki zayıfsa fayda yerine belirsizlik oluşturur. SEO performansı için doğru status code, temiz internal linking, güncel sitemap ve lifecycle tabanlı redirect yönetimi birlikte çalışmalıdır.

404 hata sayfalarında ürün önerileri, arama kutusu ve kategori bağlantıları kullanıcı deneyimini nasıl iyileştirir?

Bu bileşenler kullanıcının hata sonrasında yeniden yol bulmasını sağlar. Ürün önerileri kayıp ürünün gerçek bağlamına dayanıyorsa kullanıcı doğrudan yakın bir alternatife geçebilir. Arama kutusu kullanıcının niyetini kendi kelimeleriyle yeniden ifade etmesine izin verir ve özellikle bağlamın bilinmediği generic 404'lerde güvenli fallback sunar. Kategori bağlantıları ürün eşleşmesi bulunamadığında katalog keşfine devam etmeyi kolaylaştırır. En iyi sonuç, bu seçenekleri aynı önemde yığmak yerine kullanıcı niyetine göre bir primary aksiyon ve birkaç secondary recovery yolu sunmaktır.

E-Ticaret siteleri için 404 hata sayfası optimizasyonu ve SEO danışmanlığı yakınımda nerede bulabilirim?

E-ticaret teknik SEO ve 404 optimizasyonu uzmanı yakınımda araması yaparken yalnızca fiziksel konuma odaklanmak doğru uzmanı seçmek için yeterli değildir. HTTP status kodları, JavaScript rendering, ürün lifecycle, redirect mapping, sitemap, search index, server log ve conversion analytics konularını birlikte ele alabilen bir yaklaşım aranmalıdır. Diyarbakır Yazılım Topluluğu'nun proje ve teknik içerik yaklaşımını incelemek için https://www.diyarbakiryazilim.com.tr/about ve https://www.diyarbakiryazilim.com.tr/projects adreslerinden yararlanabilirsiniz. İyi bir çalışma yalnızca 404 tasarımını değiştirmekle kalmaz, problemin katalog ve routing kaynağını da ortaya çıkarır. Böylece SEO iyileştirmesi ölçülebilir recovery ve daha temiz teknik mimariyle desteklenir.

Sonuç — E-Ticarette 404 Bir Çıkmaz Sokak Değil, Kontrollü Recovery Noktası Olmalıdır

Dinamik E-Ticaret Mimarisinde Hata Sayfası (404) Stratejileri için en önemli fikir, 404'ü sıfırlamaya çalışmak değil doğru yerde doğru HTTP davranışını üretmektir. Gerçekten bulunmayan kaynak 404 veya uygun politikada 410 dönebilir, taşınmış kaynak 301 ile yeni yerine gidebilir ve geçici stok dışı ürün 200 PDP olarak yaşamaya devam edebilir. Bunun üzerine dinamik ürün önerileri, search, kategori fallback, monitoring ve recovery analytics eklenebilir. Büyük kataloglarda lifecycle-driven resolver, redirect registry ve event-driven senkronizasyon manuel teknik borcu azaltır. Sonuçta iyi 404 mimarisi kullanıcı niyetini, SEO sinyalini ve ticari ölçümü aynı karar modelinde buluşturur.

Önce Gerçek HTTP Sinyali Doğru Verilmelidir

Her şey doğru status code ile başlar. UI 404 gösterirken 200 döndürmekten kaçınılmalıdır. Redirect yalnızca gerçek hedef olduğunda kullanılmalıdır. Automated URL contract test bu davranışı korur. Framework değişse bile HTTP prensibi değişmez.

Ürün Yaşam Döngüsü URL Davranışını Otomatik Belirlemelidir

ACTIVE, OUT_OF_STOCK, REPLACED ve REMOVED state'leri URL davranışıyla eşlenmelidir. Ürün silme yalnızca database delete olmamalıdır. Lifecycle event sitemap, search index ve registry state'ini günceller. Böylece ekipler aynı kararı tekrar tekrar manuel vermez. Büyük kataloglarda bu otomasyon önemli operasyon avantajı sağlar.

Sadece Gerçekten İlgili Sayfalara Redirect Yapılmalıdır

Redirect relevance temel koşuldur. Aynı ürünün yeni URL'si yüksek güven taşır. Successor relation doğrulanabilir. Çok genel category veya homepage düşük relevance taşır. Eşleşme zayıfsa kullanıcıya öneri sunmak daha güvenlidir.

Kullanıcının Satın Alma Niyeti Dinamik Önerilerle Korunmalıdır

Kayıp URL ürün bağlamı taşımaya devam edebilir. Legacy SKU ve slug bilgisi güncel alternatifleri bulmak için kullanılabilir. Stokta ve gerçekten ilgili ürünler gösterilmelidir. Recommendation failure sayfayı bozmamalıdır. CTR, add-to-cart ve revenue recovery ile etki ölçülmelidir.

Search ve Navigation Her Zaman Güvenli Fallback Olmalıdır

Hiçbir resolver her URL'yi doğru anlayamaz. Confidence düşük olduğunda search ve navigation kullanıcıya kontrol sağlar. Generic 404 hızlı ve erişilebilir kalmalıdır. Mobile ekranda primary action görünür olmalıdır. Bu fallback recommendation servisinden bağımsız çalışmalıdır.

404 Trafiği Teknik Hata Değil Ölçülebilir Bir Recovery Funnel Olarak İzlenmelidir

404 View, Recovery Interaction, Product View, Add to Cart, Checkout ve Purchase olayları aynı funnel içinde izlenebilir. Bot trafik ayrı tutulmalıdır. Recovery rate teknik başarıyı, recovered revenue ticari sonucu gösterir. High-value broken URL'ler bu verilerle önceliklendirilir. 404 optimizasyonu böylece sezgi yerine ölçüme dayanır.

En Olgun Mimari SEO, UX, Envanter ve Recommendation Sistemlerini Tek 404 Stratejisinde Birleştirir

Olgun yapı HTTP durum kodunu, ürün lifecycle state'ini, redirect registry'yi, inventory verisini, search index'i ve recommendation katmanını tek karar akışında birleştirir. Kullanıcıya yalnızca doğru ve güncel seçenekler sunulur. Search engine gerçek URL state'ini açık biçimde görür. Engineering ekibi monitoring ve regression testlerle sistemi güvenilir tutar. 404 ve teknik SEO konusunda proje, topluluk çalışmaları ve yazılım geliştirme içeriklerini takip etmek için https://www.diyarbakiryazilim.com.tr adresini ziyaret edebilirsiniz.