10.000+ Ürünlü E-Ticaret Sitesinde SEO Nasıl Planlanır?

10.000 ürünlü bir e-ticaret sitesinde SEO problemi, 500 ürünlü mağazada yapılan işleri yirmiyle çarpmak değildir.

Katalog büyüdükçe site yalnız daha fazla ürün sayfasına sahip olmaz. Kategori ve alt kategoriler genişler, filtre kombinasyonları çoğalır, ürün varyantları yeni URL davranışları üretir, stok hareketleri hızlanır, pagination derinleşir, Merchant Center ve ürün verisi daha kritik hale gelir. Üstelik bütün bunlar CMS, ERP, feed sistemi, frontend ve developer ekibiyle aynı anda çalışır.

Bu noktadan sonra SEO’nun temel birimi tek URL olmaktan çıkar.

Asıl yönetmeniz gereken şey URL üreten sistemlerdir.

Bir product template hatası 20.000 ürünü, yanlış facet politikası yüz binlerce URL’yi, kötü kategori mimarisi ise sitenin bütün ticari talep dağılımını etkileyebilir.

Bu yüzden büyük katalog SEO’sunu:

Keyword → Sayfa → Optimize Et

şeklinde değil:

Demand → Architecture → URL Systems → Crawl / Index → Product Lifecycle → Internal Linking → Product Data → Measurement

şeklinde planlamak gerekir.

DigitalPlus’ın E-Ticaret SEO yaklaşımında kategori, ürün, teknik SEO ve organik gelir tarafını aynı sistemde ele almamızın nedeni bu. Büyük katalogda SEO, içerik ekibinin kendi başına yürütebileceği bir yayın operasyonu olmaktan çıkıp teknik ve ticari bir işletim modeline dönüşür.

10.000 Ürün Gerçekten Bir SEO Eşiği mi?

Hayır. 10.000 ürün Google’ın belirlediği sihirli bir sınır değildir.

Burada 10.000 sayısını pratik bir ölçek göstergesi olarak kullanıyoruz.

Bir site 8.000 ürünle çok karmaşık olabilirken başka bir site 30.000 ürünle oldukça temiz çalışabilir. Farkı yalnız SKU sayısı değil, ürünlerin kaç URL sistemi ürettiği belirler.

Örneğin 10.000 ürününüz olabilir ancak her ürün tek URL’de yaşar, kategori ağacı nettir, filtreler sınırlıdır ve katalog yavaş değişiyordur. Başka bir mağazada aynı 10.000 ürün; renk, beden, marka, fiyat, stok, sıralama ve kampanya parametreleriyle yüz binlerce erişilebilir URL kombinasyonu oluşturabilir.

İkinci site SEO açısından çok daha büyük bir sistemdir.

Bu nedenle başlangıç sorusu:

“Kaç ürünümüz var?”

değil:

“Bu ürün kataloğu kaç farklı indexlenebilir veya crawl edilebilir URL pattern’i üretiyor?”

olmalıdır.

İlk İş Keyword Research Değil, Katalog Haritası Çıkarmaktır

Büyük e-ticaret sitesinde SEO planlamasına doğrudan keyword listesiyle başlamak eksik kalır.

Önce mevcut katalog ve URL sisteminin nasıl çalıştığını görmek gerekir.

Site hangi sayfa tiplerine sahip?

Kategoriler ve alt kategoriler nasıl oluşuyor? Marka sayfaları var mı? Filtre kullanıldığında yeni URL çıkıyor mu? Ürün varyantları tek sayfada mı, ayrı URL’lerde mi? Site içi arama sonuçlarının URL’leri erişilebilir mi? Stoktan kalkan ürünler ne oluyor? Pagination nasıl çalışıyor?

Bu harita çıkarılmadan keyword araştırması yapmak, talebi hangi sisteme bağlayacağınızı bilmeden talep listesi toplamaktır.

Sağlıklı modelde önce URL tipleri ve mevcut owner’lar görünür hale gelir. Sonra arama talebi bu yapının üzerine yerleştirilir.

DigitalPlus’ın E-Ticaret Kategori Sayfası SEO Rehberi içinde kategori ağacını depo mantığından değil arama talebinden üretmemizin nedeni tam olarak budur.

Bir kullanıcının ayrı ürün kümesi görmek istediği sorgu varsa kategori veya alt kategori owner’ı gerekebilir. Aynı intent zaten mevcut bir URL tarafından karşılanıyorsa ikinci sayfayı açmak yalnız cannibalization ve crawl yükü üretir.

Büyük Katalog SEO’sunun Merkezi: Query Ownership

10.000+ ürünlü mağazada her arama sorgusunu bir ürüne göndermek doğru değildir.

Bazı query’ler kategori intent’i taşır. Bazıları marka sayfasına aittir. Bazıları belirli ürün veya model aramasıdır. Bazı filtre kombinasyonları gerçek organik talebi temsil ederken büyük bölümü yalnız kullanıcı deneyiminin parçasıdır.

Bu yüzden büyük katalogda URL üretmeden önce:

Query → Intent → Owner Type → Owner URL

kararı verilmelidir.

Örneğin:

“18V akülü matkap”

ürün listesi görmek isteyen bir kategori intent’i olabilir.

“Bosch GSB 18V-50”

ise doğrudan ürün/model intent’ine daha yakındır.

“Bosch matkap” sorgusu ise sitenin marka ve kategori mimarisine bağlı olarak ayrı bir marka-kategori owner’ı gerektirebilir.

Bu sahiplik sistemi kurulmadan facet, ürün varyantı veya internal linking konusunda verilecek teknik kararlar da havada kalır.

Çünkü önce hangi URL’lerin gerçekten organik görev taşıması gerektiğini bilmeniz gerekir.

Kategori Mimarisini Bir Defa Kurup Bırakmayın

Büyük kataloglarda kategori mimarisi genellikle zaman içinde bozulur.

Yeni ürün grupları eklenir, merchandising ekipleri yeni menüler açar, kampanyalar kalıcı hale gelir, bazı kategoriler anlamını kaybeder ve aynı talep farklı sayfalara dağılmaya başlar.

Bu nedenle kategori mimarisini yalnız site kurulurken yapılan bir SEO çalışması olarak görmemek gerekir.

Periyodik olarak hangi kategorilerin gerçek talep taşıdığı, hangi URL’lerin birbirleriyle yarıştığı ve hangi yeni ürün kümelerinin ayrı owner hak ettiği kontrol edilmelidir.

Burada amaç kategori sayısını mümkün olduğunca artırmak değildir.

Asıl amaç her güçlü ticari talebin bir tane net sahibi olmasıdır.

Büyük e-ticaret sitesinin kategori katmanını ayrı bir teknik uygulama gibi değil, ticari search architecture olarak değerlendirin. Detaylı kategori optimizasyonunu yeniden burada anlatmıyoruz; bunun için kategori sayfası SEO rehberi kullanılabilir.

Crawl Budget’ı Her Şeyin Başlangıcı Sanmayın

Büyük site dendiğinde ilk reflekslerden biri “crawl budget problemi vardır” demektir.

Bu her zaman doğru değildir.

Önce Google’ın gerçekten değerli URL’leri keşfetmekte veya yeniden taramakta zorlanıp zorlanmadığını görmek gerekir.

Search Console’da ciddi miktarda keşfedilmiş ancak indekslenmemiş URL bulunması, yeni ürünlerin geç keşfedilmesi veya server loglarında Googlebot’un büyük bölümünün düşük değerli URL pattern’lerinde dolaşması gerçek sinyal olabilir.

Ancak site büyük diye robots.txt dosyasına onlarca kural eklemek başlı başına strateji değildir.

Büyük katalog operasyonunda doğru sıra:

Önce URL envanterini anla → Sonra crawl davranışını ölç → Ardından gerçekten gereksiz alanları azalt.

Bu yüzden crawl budget ve log analizi ayrı bir uzmanlık alanıdır. Teknik yöntemi tekrar burada uzatmak yerine, gerçekten bu problem doğrulandığında E-Ticaret Crawl Budget ve Log Analizi rehberindeki segmentasyon modeline geçmek daha doğru olur.

Önemli olan her büyük sitenin log analizi yapması değil, gerektiğinde log verisini kullanabilecek bir işletim modeline sahip olmasıdır.

Facet Yönetimini Ayrı Bir SEO Projesi Değil, Katalog Politikasının Parçası Yapın

10.000+ ürünlü bir mağazada filtre sistemi kaçınılmaz olabilir.

Kullanıcı yüzlerce ürünü marka, beden, renk, kapasite, kullanım alanı veya teknik özelliğe göre daraltmak ister.

Buradaki SEO sorusu filtrelerin var olup olmaması değildir.

Soru, hangi filtre durumlarının gerçek organik landing page görevi taşıdığıdır.

Bütün facet kombinasyonlarını indexlemek URL alanını kontrolsüz büyütebilir. Bütün filtreleri arama motorlarından kapatmak ise gerçek talep taşıyan değerli kategori varyasyonlarını ortadan kaldırabilir.

Bu nedenle işletme seviyesinde bir facet policy gerekir.

Hangi attribute’lar yalnız UX filtresidir? Hangi kombinasyonlar gerçek query demand taşır? SEO owner olan facet’ler hangi URL formatını kullanır? Sitemap, canonical ve internal linking bu seçimi nasıl destekler?

Bu karar bir defa developer’a verilip unutulmamalıdır. Katalog ve arama talebi değiştikçe politika da gözden geçirilmelidir.

Facet URL’lerinin teknik yönetimini detaylı olarak Faceted Navigation SEO Rehberi içinde ele alıyoruz. Büyük katalog operating modelinde bu rehberin görevi belirli teknik kararları çözmek; ana planın görevi ise facet sisteminin ne zaman ve neden devreye girdiğini belirlemektir.

Ürün Varyantlarını Katalog Seviyesinde Bir Entity Kararı Olarak Yönetin

10.000 ürününüz olduğunu düşünürken aslında 40.000 SKU’nuz olabilir.

Renk, beden, kapasite, paket miktarı veya teknik model seçenekleri arttıkça ürün sayısı ile kullanıcıya ve arama motoruna sunulan URL sayısı birbirinden ayrılır.

Burada her varyant için ayrı URL açmak da bütün varyantları tek URL altında eritmek de genel kural değildir.

Karar product family, search demand ve ürün verisi modeline göre verilmelidir.

Önemli olan kullanıcı, URL, SKU, GTIN, fiyat, stok durumu ve structured data’nın aynı ürünü tarif etmesidir.

Bu konu büyük katalogda ayrıca operasyonel hale gelir çünkü varyant davranışı yalnız SEO ekibinin kontrolünde değildir. ERP, feed sistemi, frontend ve Merchant Center aynı product identity’yi farklı biçimlerde işleyebilir.

Varyant sisteminin teknik uygulamasını E-Ticaret Ürün Varyantları SEO içeriğinde ayrıntılı olarak ele alıyoruz. Büyük katalog planında ise ana görev, varyant politikasını bütün katalog için tutarlı hale getirmektir.

Ürün Sayfasını Tek Tek Optimize Etmeye Çalışmayın

10.000 ürünlü sitede “bu ay 100 ürün sayfasını optimize edelim” modeli kısa sürede ölçek problemi yaratır.

Bu yaklaşım bazı yüksek değerli ürünlerde kullanılabilir, fakat ana sistem template seviyesinde kurulmalıdır.

Ürün adı, breadcrumb, product data, fiyat, availability, görseller, structured data, internal linking ve stok davranışlarının büyük bölümü ortak product template tarafından yönetilir.

Dolayısıyla önce ürün template’inin sağlıklı çalışması gerekir.

Ardından yüksek talep veya yüksek marj taşıyan ürünlerde manuel iyileştirmeler yapılabilir.

Bu sıra tersine çevrilirse ekip sürekli ürün URL’lerini tek tek düzeltirken altyapı yeni sorunlar üretmeye devam eder.

Product template’in hangi alanları taşıması gerektiğini ve ürün sayfalarının kategori mimarisiyle nasıl ilişkilendiğini E-Ticaret Ürün Sayfası SEO rehberinde daha ayrıntılı ele alıyoruz.

Stok ve Ürün Yaşam Döngüsü İçin Baştan Politika Belirleyin

Büyük katalogda önemli SEO problemlerinden biri ürünlerin sürekli değişmesidir.

Yeni ürün gelir. Ürün geçici olarak tükenir. Aynı modelin yenisi çıkar. Bazı ürünler kalıcı olarak kaldırılır. Tedarikçi değişir. Ürün adı veya SKU güncellenir.

Bunların her biri için editörün o gün vereceği manuel karar sürdürülebilir değildir.

İşletmenin bir product lifecycle policy’si olmalıdır.

Geçici stok yokluğunda URL’nin ne olacağı, kalıcı kaldırılan üründe hangi koşulda 404/410 veya yönlendirme kullanılacağı, eşdeğer yeni model varsa ilişkinin nasıl kurulacağı ve ürünün kategori ağından ne zaman çıkarılacağı tanımlanmalıdır.

Bu kararların Merchant feed ve structured data tarafındaki availability bilgileriyle de çelişmemesi gerekir.

Büyük katalog SEO’sunda en pahalı hatalar çoğu zaman tek tek yapılan kötü optimizasyonlardan değil, yanlış otomasyon kurallarından çıkar.

Pagination ve Infinite Scroll’u Ürün Keşfinin Parçası Olarak Düşünün

Binlerce ürünün bulunduğu kategorilerde bütün ürünleri ilk response içinde göstermek gerçekçi değildir.

Pagination, “Daha Fazla Yükle”, infinite scroll veya hibrit model kullanılabilir.

Burada operating model açısından temel soru basittir:

Kullanıcı hiçbir özel etkileşim yapmadan crawler bütün ürün gruplarına ulaşabiliyor mu?

Bir kategori ilk 24 ürünü gerçek bağlantılarla gösteriyor ancak geri kalan bin ürün yalnız JavaScript butonuna basıldığında geliyor ve kalıcı URL karşılıkları bulunmuyorsa katalog discovery tarafında problem oluşabilir.

Bu konuyu her category audit’inde sıfırdan çözmeye çalışmak yerine site genelinde standart bir pagination modeli belirlemek gerekir.

Detaylı teknik modeli E-Ticarette Sayfalama, Daha Fazla Yükle ve Sonsuz Kaydırma rehberinde ele alıyoruz.

Büyük katalog operasyonunda önemli olan, bu kararın bütün listing template’lerinde tutarlı uygulanması ve yeni frontend geliştirmelerinde bozulmamasıdır.

Site İçi Arama Verisini Yeni Kategori Fırsatları İçin Kullanın

10.000+ ürünlü sitelerde kullanıcılar navigasyondan çok site içi aramayı kullanmaya başlayabilir.

Bu veri yalnız UX ekibi için değil SEO için de değerlidir.

Kullanıcılar tekrar tekrar sitenizde var olmayan ürün kümelerini arıyorsa mevcut kategori mimarisinde demand gap bulunabilir.

Örneğin kullanıcılar sürekli “18V fırçasız darbeli matkap” arıyor ancak sitede bu ihtiyacı karşılayan kalıcı bir kategori veya facet owner bulunmuyorsa yeni landing page fırsatı olabilir.

Burada yapılmaması gereken şey bütün `/arama?q=` URL’lerini indeksletmektir.

Daha sağlıklı süreç:

Site Search Data → Demand Pattern → SERP Validation → Existing Owner Check → New Category / Facet Decision

şeklindedir.

Site-search URL’lerinin teknik yönetimi ve search loglarından kategori fırsatı çıkarma modelini E-Ticaret Site İçi Arama SEO rehberinde ayrıntılı olarak ele alıyoruz.

Internal Linking’i Otomasyon ve Template Seviyesinde Planlayın

10.000 ürünlü mağazada internal linking operasyonunu “bu hafta 50 link ekleyelim” şeklinde yönetemezsiniz.

Manuel contextual linkler yine değerlidir ancak katalog içindeki ana bağlantı sistemi template’lerden doğmalıdır.

Ana navigasyon, kategori-alt kategori ilişkileri, breadcrumb, marka bağlantıları, ürün kartları, related products ve supporting content sisteminin her biri farklı görev taşır.

Google e-ticaret yapısını sayfalar arasındaki bağlantı ilişkilerinden anlamaya çalıştığı için önemli ürün ve kategorilerin gerçek navigasyon ağında bulunması gerekir.

Bu yüzden XML sitemap tek başına ürün keşif sistemi değildir.

Bir ürün sitemap’te olabilir fakat kategori ağından hiçbir bağlantı almıyorsa site içindeki bağlamı ve göreli önemi zayıf kalabilir.

Büyük katalog operating modelinde internal linking için şu soru düzenli sorulmalıdır:

Ticari olarak en önemli ürün ve kategoriler site architecture içinde gerçekten daha güçlü mü?

Yoksa 5 TL’lik aksesuar ile yüksek değerli ana kategori aynı derinlik ve bağlantı sistemine mi sahip?

JavaScript ve Frontend Kararlarını SEO Backlog’undan Ayırmayın

Büyük e-ticaret sitesi çoğu zaman sürekli geliştirilir.

Yeni filtre component’i gelir. Product card değişir. React veya başka frontend katmanı güncellenir. Infinite scroll eklenir. Varyant seçici yeniden yazılır.

SEO ekibi yalnız yayınlandıktan sonra siteyi crawl ediyorsa sürekli geriden gelir.

Daha sağlıklı model SEO’nun geliştirme sürecine acceptance criteria ile dahil olmasıdır.

Örneğin yeni listing component’inde:

ürün bağlantıları gerçek <a href> olarak üretilecek mi? Canonical server-side doğru gelecek mi? Product data initial HTML’de mevcut mu? URL doğrudan açıldığında aynı state’i gösterebiliyor mu?

Bu kriterler geliştirme öncesinde ticket’a girebilir.

Google da e-ticaret site yapısında ürünlerin gerçek crawlable bağlantılar üzerinden ulaşılabilir olmasını öneriyor. Merchant listing dokümantasyonunda hızlı değişen price ve availability gibi product data’nın yalnız JavaScript ile üretilmesinin crawling güvenilirliğini etkileyebileceğine ayrıca dikkat çekiliyor.

Bu nedenle büyük katalog SEO’sunda Teknik SEO yalnız dönemsel audit değildir; product ve development süreçlerine bağlanan sürekli kalite katmanıdır.

Product Data, Structured Data ve Merchant Feed’i Aynı Sistem Olarak Görün

10.000 ürünlü mağazada ürün verisinin farklı kanallarda birbirinden kopması kolaydır.

Web sayfası bir fiyat gösterir, structured data eski fiyatı taşır, Merchant feed farklı availability gönderir ve kullanıcı başka varyantı seçmiştir.

Bunların her birini ayrı ekip yönetiyorsa hata ihtimali büyür.

Büyük katalogda product data için tek bir source-of-truth yaklaşımı mümkün olduğunca tercih edilmelidir.

Ürün adı, SKU, GTIN, fiyat, availability, variant ilişkisi ve canonical URL’nin site, structured data ve feed arasında tutarlı olması gerekir.

Google da e-ticaret sitelerinin hem sayfa üzerindeki structured data hem Merchant Center feed’i üzerinden ürün bilgisi paylaşabileceğini ve bu kanalların ürün anlayışını desteklediğini belirtiyor.

Bu nedenle Merchant Center yalnız performans pazarlaması ekibinin kutusu değildir.

Organik ürün görünürlüğü ve teknik product SEO açısından da katalog işletim modelinin parçasıdır.

SEO Planını Bütün 10.000 Ürüne Eşit Dağıtmayın

Büyük katalog yönetiminde bütün URL’lere aynı miktarda zaman harcamak pratik değildir ve ticari olarak da mantıklı değildir.

Önceliklendirme gerekir.

Yüksek talep, yüksek marj, stratejik marka veya güçlü conversion potansiyeli taşıyan kategori ve ürün kümeleri daha fazla attention alabilir.

Diğer tarafta indekslenmesi gereken bütün ürünlerin temel teknik kalite standardını karşılaması gerekir.

Bu nedenle iki katmanlı model kullanmak daha sağlıklıdır:

Sitewide Quality Floor + Priority Growth Layer

İlk katmanda bütün katalog için doğru template, canonical, product data, crawlability ve lifecycle kuralları uygulanır.

İkinci katmanda en yüksek ticari fırsat taşıyan kategori ve ürünler keyword research, içerik, internal links ve conversion açısından daha yoğun geliştirilir.

Bu yaklaşım sayesinde ekip 10.000 ürüne tek tek SEO yapmaya çalışmaz ama katalogun geri kalanını da teknik olarak kaderine terk etmez.

Öncelikleri URL Sayısıyla Değil Business Impact ile Belirleyin

Büyük mağazada crawler size binlerce hata gösterebilir.

En fazla URL’yi etkileyen problem her zaman en önemli problem değildir.

Örneğin 50.000 düşük değerli parametre URL’sindeki minor metadata problemi, sitenin en çok gelir üreten 20 kategori sayfasındaki canonical hatasından daha düşük öncelikli olabilir.

Bu yüzden backlog:

Severity + URL Scale + Commercial Impact + Evidence + Implementation Effort

üzerinden değerlendirilmelidir.

DigitalPlus’ın SEO Audit yaklaşımında P0, P1, P2 ve P3 ayrımı kullanmamızın nedeni bu. Büyük katalogda yapılabilecek SEO işi sonsuzdur; kritik yetenek yapılmaması gereken işleri de ayıklayabilmektir.

10.000+ Ürünlü E-Ticaret Sitesinde SEO Ekibi Nasıl Çalışmalı?

Büyük katalog SEO’su tek bir SEO uzmanının CMS içinde değişiklik yaptığı modelle uzun süre ölçeklenmez.

En azından SEO, development, product/merchandising, content ve analytics rollerinin birbiriyle konuşması gerekir.

SEO ekibi her şeyi kendisi yapmak zorunda değildir.

Ancak her kararın owner’ı belli olmalıdır.

Örneğin facet policy SEO ve product tarafından belirlenebilir, teknik uygulamayı developer yapabilir ve SEO staging/canlı QA’yı üstlenebilir.

Kategori mimarisini SEO çıkarabilir ancak merchandising gerçek ürün ilişkilerini doğrulayabilir.

Product data problemi ERP veya feed ekibine ait olabilir.

Sağlıklı operasyon:

Issue → Owner → Deliverable → Acceptance Criteria → Implementation → QA → Measurement

şeklinde ilerler.

“Developer’a söyledik” completed task değildir.

Büyük kataloglarda SEO kararının production’da gerçekten beklenen davranışı üretip üretmediği kontrol edilmelidir.

SEO Backlog’unu Aylık Değil Sprint Mantığıyla Yönetin

10.000+ ürünlü site için “bu ay 10 blog + 20 backlink” gibi sabit paketler operasyonun doğasına uymaz.

Bir hafta critical indexation problemi çıkabilir. Sonraki sprint kategori mimarisi çalışması gerekir. Bir başka dönemde product structured data veya Merchant feed tutarsızlıkları öne çıkabilir.

Bu nedenle aylık hedef korunabilir ancak uygulama daha kısa sprintlere bölünmelidir.

Örneğin bir aylık hedef:

“Ana ticari kategori ağında indexation ve ownership problemlerini azaltmak.”

olabilir.

İlk sprint URL ve query mapping, ikinci sprint technical implementation, üçüncü sprint internal linking ve template değişiklikleri, dördüncü sprint QA ve measurement içerebilir.

Böylece SEO planı yapılacak işler listesi olmaktan çıkar, kapanış kriteri bulunan bir operasyon sistemine dönüşür.

İlk 30 Günde Ne Yapılmalı?

İlk ayın hedefi katalogdaki her şeyi optimize etmek olmamalıdır.

Önce sistemin haritasını çıkarmak gerekir.

URL ve template envanteri, ana commercial query sahipleri, Search Console landing page performansı, indexation örnekleri, XML sitemap segmentleri ve ana teknik pattern’ler birlikte incelenebilir.

Bu aşamanın sonunda ekip şu sorulara cevap verebilmelidir:

Site hangi URL tiplerini üretiyor? Hangi sayfalar para kazanıyor? Google hangi URL gruplarında zaman harcıyor? Hangi ana kategori veya ürün kümeleri organik talebi sahipleniyor? Nerede duplicate ownership veya gereksiz URL üretimi var?

İlk ayın çıktısı 200 maddelik hata dosyası değil, birkaç net problem kümesi olmalıdır.

Örneğin:

P0: Ana kategori indexation problemi

P0: Facet URL explosion

P1: Product template structured data tutarsızlığı

P1: Önemli ürünlerin pagination nedeniyle derin kalması

gibi.

Problemin genişliği henüz belli değilse SEO Audit tam olarak bu başlangıç teşhisi için kullanılabilir.

30-60 Gün Arasında Sistem Seviyesinde Uygulamaya Geçin

İlk teşhisten sonra bütün bulguları aynı anda geliştirme ekibine göndermek yerine en yüksek etki taşıyan sistemlere müdahale edilmelidir.

Örneğin facet sistemi katalog genelinde gereksiz URL üretiyorsa bunu çözmek yüzlerce ayrı URL task’ından daha değerlidir.

Product template bütün varyantlarda yanlış structured data oluşturuyorsa template seviyesinde düzeltme yapılmalıdır.

Önemli kategoriler yanlış owner’larla yarışıyorsa query-to-URL mapping üzerinden mimari yeniden düzenlenebilir.

Bu aşamada her task için acceptance criteria oluşturmak özellikle önemlidir.

“Facet SEO düzeltilecek” yerine hangi URL pattern’inin nasıl davranacağı yazılmalıdır.

Büyük sistemlerde belirsiz teknik task, belirsiz sonuç üretir. Bunu insanlığın kaç Jira board’u doldurduktan sonra öğreneceği henüz belli değil.

60-90 Gün Arasında Growth Katmanına Geçin

Kritik teknik ve mimari blocker’lar azaldığında daha klasik growth çalışmalarının değeri yükselir.

Yeni kategori fırsatları, high-opportunity ürün kümeleri, internal linking geliştirmeleri, ürün ve kategori içerikleri, supporting content ve conversion iyileştirmeleri burada daha anlamlı hale gelir.

Örneğin Search Console’da pozisyon 6-15 arasında bulunan ancak yüksek ticari değer taşıyan kategori kümeleri ayrı growth backlog’una alınabilir.

Site içi arama verisinden yeni kategori opportunity’leri çıkarılabilir.

Supporting içeriklerden önemli category owner’lara contextual internal links güçlendirilebilir.

Buradaki temel kural:

Teknik borç tamamen bitene kadar growth yapma

değildir.

Büyük sitede teknik çalışma ile growth paralel yürüyebilir.

Ancak growth backlog’unun kritik technical blocker’ların önüne geçmesine izin verilmemelidir.

Measurement’ı Toplam Organik Trafikten Kurtarın

10.000 ürünlü sitede toplam organic sessions özellikle yanıltıcı olabilir.

Blog trafiği büyürken kategori geliri düşebilir. Marka aramaları artarken non-brand discovery aynı kalabilir. Binlerce düşük değerli ürün daha fazla impression üretirken ana ticari kategoriler kaybediyor olabilir.

Bu nedenle raporlama segmentli olmalıdır.

En azından kategori, ürün ve informational content performansı ayrı okunmalıdır.

Daha ileri yapıda kategori aileleri, ürün markaları veya ticari öncelik grupları ayrıca izlenebilir.

Search Console tarafında impression, click, CTR ve query coverage; analytics tarafında product view, add-to-cart, checkout ve revenue birlikte değerlendirilebilir.

DigitalPlus’ın E-Ticaret Sitem Google’da Görünüyor Ama Satış Getirmiyor rehberinde de bu ayrımı özellikle ele alıyoruz. Search visibility ile revenue arasındaki zincirin hangi noktada kırıldığı bulunmadan daha fazla trafik tek başına çözüm değildir.

Büyük Katalogda Hangi KPI’lar Daha Anlamlı?

Her proje farklı olsa da tek bir KPI kullanmak yerine teknik, search ve ticari katmanları birlikte takip etmek daha sağlıklıdır.

Katman	Örnek ölçüm
Crawl / Index	Önemli URL gruplarının crawl ve index durumu
Architecture	Doğru query’nin doğru owner URL ile eşleşmesi
Search	Non-brand impression, click, query coverage
Commercial Pages	Kategori ve ürün landing performansı
E-Commerce	Product view, add-to-cart, checkout
Business	Organic revenue ve margin odaklı sonuçlar

Böylece teknik ekip “index coverage iyileşti”, SEO ekibi “click arttı” ve yönetim “satış değişmedi” diye üç ayrı gerçeklik yaşamaz.

Aynı funnel üzerinde konuşulur.

Yeni İçerik Üretmeden Önce Mevcut Kataloğu Kullanın

Büyük e-ticaret sitelerinde içerik fırsatı genellikle vardır, ancak sürekli yeni blog üretmek otomatik öncelik değildir.

Zaten on binlerce ürün ve yüzlerce kategori içeren bir sitede ilk soru:

Mevcut ticari envanter Search’te doğru şekilde çalışıyor mu?

olmalıdır.

Örneğin kategori title’ları zayıf olabilir. Search intent doğru sayfaya eşleşmiyor olabilir. Ürün açıklamaları tamamen tedarikçi feed’inden geliyor olabilir. Supporting içerik güçlü fakat hiçbir ticari sayfaya bağlanmıyor olabilir.

Yeni production kararı bundan sonra verilmelidir.

Bu nedenle büyük katalogda içerik operasyonunun sırası:

Existing Owners → Existing Opportunities → Missing Commercial Pages → Supporting Content

şeklinde kurulabilir.

Büyük E-Ticaret SEO Neden Daha Fazla Kaynak İster?

Çünkü iş hacmi yalnız URL sayısıyla artmaz.

Daha fazla ekip, entegrasyon ve sistem kararının birbirine bağlanması gerekir.

Keyword research kategori mimarisini etkiler. Kategori mimarisi frontend navigation’ı etkiler. Facet policy developer işine dönüşür. Product lifecycle ERP ve feed sistemine dokunur. Structured data ürün verisine bağlıdır. Measurement analytics ekibini gerektirir.

Bu nedenle büyük katalog SEO’sunun maliyeti çoğu zaman “daha fazla içerik yazıldığı” için değil, daha fazla sistemin koordine edilmesi gerektiği için büyür.

Bu maliyet yapısını ayrı olarak E-Ticaret SEO Neden Normal Bir Kurumsal Siteden Daha Pahalıdır? içeriğinde ele alıyoruz.

Buradaki önemli nokta bütçe değil çalışma modeli: büyük katalog SEO’suna küçük site paketi uygulanırsa ekip birkaç URL’de iyileştirme yaparken ana sistem aynı hataları üretmeye devam eder.

10.000+ Ürünlü Site İçin SEO Operating Model Nasıl Görünmeli?

Bütün sistemi tek çerçevede toplarsak büyük katalog SEO’sunun altı ana yönetim katmanı vardır.

1. Demand & Ownership

Hangi ticari talebin hangi kategori, marka veya ürün URL’si tarafından sahiplenileceği belirlenir.

2. URL & Crawl Governance

Hangi URL pattern’lerinin üretilmesi, crawl edilmesi ve indexlenmesi gerektiği kontrol edilir.

3. Catalog & Product Lifecycle

Ürün, varyant, stok, discontinued product ve pagination davranışları için sitewide politikalar oluşturulur.

4. Product Data

Sayfa, structured data, feed ve ERP tarafındaki product identity mümkün olduğunca tutarlı hale getirilir.

5. Implementation & QA

SEO kararları developer ve content task’larına çevrilir, staging ve production sonrasında doğrulanır.

6. Measurement & Growth

Search visibility, category/product performance ve revenue verileri yeni sprint önceliklerini üretir.

Bu katmanların herhangi biri sürekli diğerlerini bozuyorsa SEO operasyonu kalıcı olarak verimli hale gelmez.

En Sık Yapılan Hata: Her Problemi Tek Tek URL Üzerinden Çözmek

Büyük katalog sitelerinde ekipler bazen aylar boyunca binlerce URL’yi manuel düzeltmeye çalışır.

Oysa aynı sorun tek bir template, routing kuralı veya data mapping hatasından doğuyor olabilir.

Örneğin 15.000 ürünün canonical etiketi yanlışsa 15.000 ayrı task yoktur.

Bir product template problemi vardır.

30.000 sort URL’si indexleniyorsa 30.000 içerik problemi yoktur.

Bir URL governance problemi vardır.

8.000 ürün kategori navigation’ından bulunamıyorsa 8.000 internal link task’i yoktur.

Bir site architecture problemi vardır.

Büyük e-ticaret SEO’sunda ölçeklenebilirlik tam olarak burada başlar:

URL’leri değil, URL üreten kuralları optimize edin.

Sonuç: 10.000+ Ürünlü E-Ticaret Sitesinde SEO Nasıl Planlanmalı?

Büyük katalog SEO’su çok sayıda ürüne tek tek optimizasyon yapmak değildir.

Önce sitenin demand ve ownership modeli kurulmalıdır. Hangi query’nin kategoriye, hangi query’nin ürüne, hangi filtre durumunun gerçek landing page’e ait olduğu belirlenmelidir.

Ardından crawl ve indexation davranışı gerçek verilerle kontrol edilir. Facet, varyant, pagination ve site içi arama gibi sistemlerin her biri için sitewide politika oluşturulur. Product data, structured data ve feed aynı ürün kimliğini desteklemelidir.

Technical ve content kararları developer backlog’una net acceptance criteria ile girmeli, uygulama sonrasında QA yapılmalıdır.

Son olarak performans yalnız toplam organik trafik üzerinden değil kategori, ürün, non-brand visibility ve revenue katmanlarında ölçülmelidir.

Yani büyük katalog operating modelinin özeti:

Demand → Ownership → Architecture → Crawl / Index → Catalog Rules → Product Data → Implementation → QA → Measurement → Growth

şeklindedir.

Facet, varyant veya crawl budget gibi konular bu modelin ayrı ayrı amaçları değildir. Bunlar katalog büyüdükçe yönetilmesi gereken alt sistemlerdir.

Bu nedenle 10.000+ ürünlü mağazada doğru başlangıç “hangi SEO taktiklerini uygulayalım?” sorusu değil:

“Bu kataloğun organik arama işletim modelini nasıl kuracağız?”

sorusudur.

Kategori ve ürün mimarisi, faceted navigation, crawl/indexation, internal linking ve organik gelir tarafını tek operasyon içinde yönetmek gerekiyorsa E-Ticaret SEO hizmeti bu sistemin commercial owner’ıdır. Problemin önce geniş biçimde teşhis edilmesi gerekiyorsa SEO Audit, doğrulanmış teknik darboğazlar için ise Teknik SEO çalışmasıyla başlanabilir.