Diller

E-ticaret XML Sitemap'leri

Katalog ölçeğinde genel sitemap tavsiyeleri yetersiz kalır. E-ticaret sitemap'ini türe göre bölmeyi, 50 000 URL ve 50 MB sınırlarını bir sitemap diziniyle yönetmeyi, stokta olmayan veya satıştan kaldırılan ürün URL'leri için karar vermeyi, lastmod değerini katalog değişiklikleriyle uyumlu tutmayı ve sitemap'leri IndexNow ile birlikte kullanmayı öğrenin. Türe göre bölümleme tarama bütçesi için değil, izleme içindir.

İlk yayın tarihi: 3 Tem 2026 · Son güncelleme: 20 Ağu 2026 · Advanced
Diller
AIYazanAI v2
Bu sayfada 1 kanıt sinyali

Bir e-ticaret XML sitemap'i, mağazanın taranmasını istediği canonical URL'leri tek bir sitemap dizini altında içerik türüne göre (ürünler, kategoriler, markalar ve statik sayfalar) gruplar. Tasarımı belirleyen sınırlar dosya başına 50 000 URL veya 50 MB ve dizin başına 50 000 dosyadır. Bölümlendirme, Search Console ve Bing Webmaster Tools'ta izleme içindir; tarama bütçesi ya da sıralama kaldıracı değildir. Yalnızca canonical, indexable ve 200 durum kodu döndüren URL'leri ekleyin; lastmod değerini son önemli değişiklikle uyumlu tutun, priority ile changefreq değerlerini kullanmayın. Stokta olmayan ve satıştan kaldırılan ürünleri kalıcı, geçici ve belirsiz durumları kapsayan belgelenmiş bir karar ağacıyla yönetin; sitemap'ten kaldırmayı dahili bağlantı temizliğiyle eş zamanlı yapın. Üretimi otomatikleştirin ve hızlı fiyat ya da stok değişiklikleri için lastmod'u IndexNow ile birlikte kullanın.

TL;DR — Bir e-ticaret sitemap’ini türüne göre (ürünler / kategoriler / markalar / statik sayfalar) tek bir sitemap dizini altında bölümlere ayırın ve nedenini bilin: Bu, Search Console ve Bing Webmaster Tools için bir izleme aracıdır; bir tarama bütçesi veya sıralama kaldıracı değildir (Mueller). Tasarımınızı şu sınırlar çevresinde yapın: dosya başına 50 000 URL / 50 MB, dizin başına 50 000 dosya ve — kurumsal üst sınır açısından — GSC en fazla 500 sitemap kabul eder; Bing ise dizin modelinin milyarlarca URL’ye ölçeklendiğini belirtir. Yalnızca canonical, indexable ve 200 durum kodu döndüren URL’leri dahil edin; fasetleri, izleme parametrelerini, ince varyantları, yönlendirmeleri, 4xx’leri ve noindex’i hariç tutun. lastmod, her iki motorun da kullandığı tek özniteliktir — değeri son önemli değişikliği dürüstçe yansıtmalıdır; priority ve changefreq değerlerini yok sayın (Google ikisini de açıkça yok sayar). Dosyanın asla güncelliğini yitirmemesi için üretimi otomatikleştirin ve hızlı fiyat/stok değişiklikleri için lastmod’u IndexNow ile birlikte kullanın. Çoğu rehberin atladığı ayırt edici nokta şudur: stokta olmayan ve satıştan kaldırılan ürünler için kalıcı / geçici / bilinmiyor durumlarını kapsayan belgelenmiş bir karar ağacı gerekir; sitemap’ten kaldırma, dahili bağlantı temizliğiyle senkronize edilmelidir — toplu hata sayfaları kullanılmamalıdır.

Katalog ölçeğinde genel sitemap tavsiyesi neden yetersiz kalır

Her “sitemap nasıl oluşturulur” makalesi aynı noktaları ele alır: 50 000 URL sınırı, bir sitemap dizinine bölme, gereksiz URL’leri hariç tutma ve lastmod değerini doğru tutma. Bunların hepsi doğrudur; ancak bir e-ticaret mağazasının asıl zorlandığı yer bunlar değildir. Mağaza ölçeğindeki sorunlar operasyoneldir: her gün değişen bir katalog, binlerce stoğu tükenen ve satıştan kaldırılan SKU, birbirine çok benzeyen beden/renk varyantları ve sessizce çalışmayı bırakan otomasyon. Bu yazı, zaten bir sitemap’iniz olduğunu ve bunları ele almanız gerektiğini varsayar.

Sitemap’lerin bir mağaza büyüdükçe daha fazla işe yaramasının nedeni basittir. Google şöyle diyor: “Generally, on large sites it’s more difficult to make sure that every page is linked by at least one other page on the site.” Sitemap, dahili olarak yeterince bağlantı almayan bir ürünün yine de keşfedilmesini sağlamanın yoludur. John Mueller XML sitemap’lerini “a minimal baseline for any serious website.” olarak nitelendirmiştir. Mueller’ın “minimal baseline” ifadesi, bir X/Twitter yanıtına ilişkin Search Engine Roundtable haberinde aktarılmıştır; bunu birincil kaynaktan doğrudan alınmış bir alıntı değil, aktarılmış bir ifade olarak değerlendirin.

Tasarımınızı belirleyen kesin sınırlar

Sitemap protokolü tek bir dosyaya sınır koyar ve bu sınırı aşmak için bir sitemap index sağlar:

  • Dosya başına: Google — “All formats limit a single sitemap to 50MB (uncompressed) or 50,000 URLs. If you have a larger file or more URLs, you must break your sitemap into multiple sitemaps.” Evidence for this claim Each Google sitemap file is limited to 50,000 URLs or 50 MB uncompressed. Scope: Protocol and Search Console submission limits are separate constraints. Confidence: high · Verified: Google: Large sitemaps
  • Sitemap dizini: “A sitemap index file may have up to 50,000 loc tags” — yani 50 000 alt sitemap’e kadar referans verebilir. “submit up to 500 sitemap index files for each site in your Search Console account.”
  • Bing’in belirttiği üst sınır yine de daha geniştir: dosya başına 50 000 URL ve dizin başına 50 000 alt dosya; ardından şu alıntı gelir: “a single sitemap index file can reference up to 2.5 billion URLs. At scale, multiple index files can support up to 2.5 trillion URLs across a domain, making this approach ideal for large, complex sites.”

Neredeyse her mağaza için pratik sonuç şudur: dosya başına 50 000 URL, türe göre bölümlendirme ve tek bir index. Milyarlarca/trilyonlarca URL rakamları yalnızca on milyonlarca SKU için mimari tasarlıyorsanız önemlidir — ancak protokolün darboğazınız olmayacağını gösterir.

Bölümlendirme stratejisi — ve asıl amacı

Kataloğu, tek bir index tarafından referanslanan mantıksal sitemap dosyalarına — ürünler, kategoriler/koleksiyonlar, markalar, statik/CMS sayfaları — bölün. Çoğu rehberin yanıldığı nokta şudur: sitemap’i türe göre bölmenin tarama bütçesini iyileştirdiğini veya daha fazla sayfanın dizine eklenmesini sağladığını ima ederler. Böyle değildir. Mueller bunun bir tarama kaldıracı değil, tanılama amaçlı bir tercih olduğunu açıkça belirtir:

  • “The size & number of sitemap files generally won’t affect the crawling, unless your server is so bogged down that even fetching a handful of sitemap files would slow it down…”
  • “I generally recommend splitting a sitemap file into logical parts of your site so that you can monitor those parts individually…” Her iki ifade de Search Engine Journal’ın bir Reddit AMA raporu üzerinden aktarılmıştır; önemli olan nokta sitemap’i izleme amacıyla bölmektir.

Ürün sitemap’ini kategori sitemap’inden ayrı tutmanın getirisi, GSC’nin Sitemaps raporunun ve Bing Webmaster Tools’un gönderilen/dizine eklenen oranını segment başına göstermesidir. “Ürün sayfaları” 40% dizine eklenmiş, “kategori sayfaları” 95% dizine eklenmiş göründüğünde, nereye bakacağınızı tam olarak bilirsiniz. Bölümlendirme sorunu görünür kılar; çözmez ve size tarama bütçesi kazandırmaz.

Sitemap’e neler dahil edilir — neler edilmez?

Google’ın kuralı bütün filtreyi oluşturur: “Include the URLs in your sitemap that you want to see in Google’s search results. Google generally shows the canonical URLs in its search results, which you can influence with sitemaps.” Buna göre sitemap’teki bir URL canonical, indexable olmalı ve 200 durum kodu döndürmelidir. Evidence for this claim Google recommends listing the canonical URLs that a site wants shown in Search. Scope: Sitemap inclusion is a canonicalization hint and does not override noindex or response status. Confidence: high · Verified: Google: Build and submit a sitemap

Dahil edin: canonical ürün sayfalarını (PDP’ler), sıralanmasını istediğiniz kategori/koleksiyon sayfalarını, marka sayfalarını ve indexable statik sayfaları.

Hariç tutun:

  • Faset / filtrelenmiş / sıralanmış URL’ler — ?sort=, ?color=, filtre birleşimleri. Bunlar faset stratejinize (engelleme veya canonical) aittir, sitemap’e değil. Joshua Hardwick’in Ahrefs sitemap rehberi bunun e-ticarete özgü biçimini vurgular: “worth checking for duplicate and near-duplicate pages on ecommerce sites as these often slip through the net.”
  • Oturum kimlikleri ve izleme parametreleri.
  • Yönlendirmeler (3xx) ve hatalar (4xx / 410) — yönlendirme URL’lerinden oluşan bir sitemap, Google’a göstermemesini söylediğiniz URL’lerin listesidir.
  • noindex sayfaları — gönderme + noindex çelişkisi yalnızca tarama kaynaklarını boşa harcar.
  • İnce, neredeyse yinelenen varyantlar. Benzersiz içeriği olmayan ayrı bir beden/renk URL’si ayrı bir sitemap girişi olmamalıdır — canonical ürün URL’sini listeleyin. Google’ın 2024 ürün varyantları yapılandırılmış verisi (ProductGroup / hasVariant / variesBy), bir dizi beden/renk seçeneğinin N adet neredeyse yinelenen sayfa yerine varyantları olan tek bir ürün olduğunu ifade etmenin modern yoludur; varyant ilişkisini sitemap’in değil bunun taşımasını sağlayın.

Ürün görselleri sahibi oldukları sayfanın girişinde yer alır; ayrı bir liste değildir. Görsel URL’lerinden oluşan bağımsız bir sitemap oluşturmayın — görsel sitemap uzantısını kullanarak canonical ürün URL’sinin kendi <url> girişine bir <image:image> bloğu ekleyin. Google: “Each <url> tag can contain up to 1,000 <image:image> tags” — bir PDP galerisi için fazlasıyla yeterlidir. Evidence for this claim Product images can be added to an existing product URL entry with the image sitemap extension instead of a separate image sitemap. Scope: Each <url> entry can carry up to 1,000 <image:image> tags, and the images still have to be crawlable (not blocked by robots.txt) and, if served from another domain, verified in Search Console. Confidence: high · Verified: Google: Image sitemaps Katalog ölçeğinde kolayca gözden kaçan iki taranabilirlik gereksinimi vardır: robots.txt içinde görsel yollarını engellemeyin ve ürün görselleri ayrı bir alan adından veya CDN’den sunuluyorsa, bu ana makineyi Search Console’da doğrulayın; aksi hâlde görseller alınmaz. Hangi varyantın görselinin girişe ekleneceği, URL’nin kendisiyle ilgili aynı canonical mimari kararını izler — görselleri, yukarıda zaten hariç tuttuğunuz her ince varyant URL’sine değil, canonical ürün girişine ekleyin.

Stokta olmayan ve satıştan kaldırılan ürünler için karar ağacı

Bir e-ticaret sitemap makalesinin gerçekten farklılaşabileceği yer burasıdır; çünkü neredeyse hiçbiri bu durumu yeterince incelikli biçimde ele almaz — ayrıca bir URL’nin sitemap’e ait olup olmadığını belirleyen tam da bu karardır. Ahrefs blogunda tam çerçeveyi (How Should You Handle Out-of-Stock Products? It Depends) yazdım; buna “it depends” denmesinin bir nedeni var. Kusursuz bir çözüm yoktur — amaç tek bir yanıtı ezberlemek değil, işletme hedeflerinizle uyumlu tutarlı kurallar oluşturmaktır.

Karar iki eksende verilir: ürün kalıcı olarak mı yoksa geçici olarak mı yok oldu ve sayfanın hâlâ değeri var mı (trafik, yorumlar, yararlı bilgiler)?

  • Geçici olarak stokta yok, geri döneceği kesin → Sayfayı yayında ve sitemap’te tutun. Yeniden stoklanma tahmini, bekleme listesi veya “bana haber ver” seçeneği sunun. Her stok değişiminde sayfayı sitemap’e ekleyip çıkarmayın — bu yalnızca gürültü yaratır.
  • Geçici olarak stokta yok, durum bilinmiyor → Sayfayı hemen sitemap’ten çekmek yerine arayüzde ve dahili bağlantılarda önceliğini düşürün (sıralamasını değiştirin, filtrelerde aşağı taşıyın). Erken kaldırma, Google’ın sayfayı terk edilmiş olarak değerlendirmesine ve geri kazanılması zor sıralamaların kaybedilmesine yol açabilir.
  • Kalıcı olarak kaldırıldı, iyi bir alternatif var → Bağlantı değerini korumak için benzer bir ürüne 301 yönlendirmesi yapın ve ürünü sitemap’ten kaldırın.
  • Kalıcı olarak kaldırıldı, alternatif yok ama sayfa hâlâ trafik getiriyor veya yararlı içerik barındırıyor (yorumlar, satın alma rehberi) → Yayında ve sitemap’te kalabilir.
  • Kalıcı olarak kaldırıldı, değeri yok → Silin ve 404/410 döndürün; ardından sitemap’ten kaldırın.

Kritik bir operasyonel nokta şudur: kaldırma, tek bir sitemap düzenlemesi değil, koordineli bir temizliktir. O makalede bunu şöyle ifade ettim: “when redirecting a page, many systems will automatically remove internal links from categories, facets, sitemaps, and internal search pages” — bu nedenle URL’yi sitemap’ten çekin ve ona işaret eden dahili bağlantıları (kategori modülleri, ilgili ürün widget’ları, dahili arama) aynı iş akışında temizleyin. Sitemap’ten çıkarılmış ama hâlâ yirmi kategori sayfasından bağlantı alan geçersiz bir URL gerçekten temizlenmiş sayılmaz.

Google’ın kendi yönergelerinin karşı çıktığı bir şey de şudur: satıştan kaldırılan her ürünü refleks olarak toplu 404’e çevirmeyin. Google, toplu 404’ler yerine URL’yi alternatiflerle yayında tutmayı veya ilgili bir kategoriye yönlendirmeyi tercih eder ve çok sayıda soft 404 oluşturulmaması konusunda uyarır. Yeni 404’e dönüştürülmüş ürün sayfalarından oluşan bir duvar, tam olarak bu uyarıyı tetikleyen örüntüdür.

Güncelleme sıklığı, lastmod ve otomasyon

Üretimi otomatikleştirin. Bu, her gün değişen bir katalog için pazarlık konusu olamaz. Kurumsal siteler için temel tavsiyem şudur: “Add sitemaps. I would make sure this is automated. If you are asked to manually create them, you can do it, but just know that if it’s manual these will rarely be kept up-to-date.” Bing arızanın tam biçimini şöyle belgelemiştir — “Too often, Bing discovers stalled sitemaps which have the same URLs listed for months – sometimes years” — ve sitemap’in “should ideally be automatically generated at least once a day.” olmasını önerir.

lastmod, önemli olan tek özniteliktir. Google ve Bing ikisi de bunu etkin biçimde kullanır; diğerlerini hiçbiri kullanmaz. Değerini dürüst tutun:

  • Google: “Google uses the <lastmod> value if it’s consistently and verifiably (for example by comparing to the last modification of the page) accurate.” Ayrıca değer “reflect the date and time of the last significant update to the page… an update to the main content, the structured data, or links on the page is generally considered significant, however an update to the copyright date is not.”
  • Bing, karşı örnek konusunda nettir: “Do not set the <lastmod> value set to the time you generate the sitemap. <lastmod> should be the date of the last modification of the content.” Zaman bileşeni içeren ISO 8601 kullanın.

Burada işaretlenmeye değer gerçek bir gri alan var: fiyat değişikliği veya stok durumu değişimi “önemli” bir güncelleme midir? Google’ın tanımına göre (ana içerik / yapılandırılmış veri / bağlantılar), salt bir fiyat değişikliği tartışmalı biçimde değildir — ancak Product yapılandırılmış verinizi (availability, price) değiştiriyorsa, bu önemli değişikliğe daha yakındır. Dürüst değerlendirmem şu: bu konuda kurnazlık yapmaya çalışmayın. Her önemsiz değişimde lastmod değerini güncellemeyin (bu yalnızca gürültü ekler) ve zamana duyarlı bir fiyat düşüşünü hızlıca yaymak için yalnızca lastmod’a güvenmeyin.

Hızlı değişiklikler için lastmod’u IndexNow ile birlikte kullanın. Bing, ikisini birbirinin alternatifi değil, tamamlayıcısı olarak çerçeveler: “While real-time URL submission protocols such as IndexNow help notify search engines of immediate content changes, sitemaps remain a foundational signal for ensuring comprehensive URL coverage across your site.” Özellikle yapay zekâ destekli yüzeyler için: “The lastmod field in your sitemap remains a key signal, helping Bing prioritize URLs for recrawling and reindexing, or skip them entirely if the content hasn’t changed since the last crawl.” Sonuç olarak: sitemap kapsam ve günlük güncellik sağlar; IndexNow (Bing/Yandex/diğerleri — Google değil) bir sonraki yeniden tarama döngüsünü beklemeden tekil fiyat/stok değişikliklerini iletmek içindir.

priority ve changefreq değerlerini yok sayın

Bunların bakımına mühendislik zamanı ayırmayın. Google açıkça şunu belirtir: “Google ignores <priority> and <changefreq> values.” Gary Illyes’in öncelik alanını “essentially a bag of noise.” olarak nitelendirdiği aktarılmıştır. Illyes’in bu ifadesi Search Engine Roundtable’ın SMX Advanced 2017 haberinden aktarılmıştır; birincil kaynaktan doğrudan alınmış değildir. Google’ın dokümanları artık her iki alanın da yok sayıldığını belirttiği için temel nokta yine geçerlidir. Platformunuz bunlara otomatik olarak hangi değeri verirse versin zararsızdır; yalnızca bunları hesaplayacak bir mantık kurmayın.

İzleme ve tanılama

Bölümlendirmenin amacı buydu:

  • GSC Sitemaps raporu — segment başına gönderilen/dizine eklenen oranı. Kategori sitemap’inizden çok daha kötü olan ürün sitemap’i oranı, sizi doğrudan ürün sayfası sorununa yönlendirir (ince içerik, engellenmiş varyantlar, canonical sorunları).
  • Bing Webmaster Tools — Bing tarafında aynı segment düzeyi görünümü ve ayrıca IndexNow gönderim durumu.
  • GSC Page Indexing raporu — facet/parametre URL’lerinin şişen hariç tutulan kümelerini izleyin; bu, facet stratejinizin keşfe sızdığını gösterir.
  • Site taraması / denetimi (Ahrefs Site Audit, Screaming Frog) — hâlâ stokta yok mesajı gösteren ürünleri, artık hiçbir yerden bağlantı almayan öksüz ürünleri ve yönlendirme veya kaldırma sonrasında geride kalan bozuk dahili bağlantıları yakalayın.

Kurumsal ölçekli mimari — örnek bir yapı

Milyonlarca SKU içeren bir katalog için hiyerarşiyi, dosyaları sonradan eklemek yerine gerçek hacminize ve gönderim sınırlarına göre planlayın:

/sitemap-index.xml            ← the one index you submit to GSC + BWT
  ├── /sitemaps/products-1.xml      (URLs 1–50,000)
  ├── /sitemaps/products-2.xml      (50,001–100,000)
  ├── … products-N.xml              (chunk every 50,000 canonical PDPs)
  ├── /sitemaps/categories.xml      (all category / collection pages)
  ├── /sitemaps/brands.xml          (all brand pages)
  └── /sitemaps/static.xml          (homepage, guides, policy pages)

5 milyon üründe bu, yaklaşık 100 ürün sitemap dosyası ve birkaç başka dosya demektir — dizin başına 50 000 dosya sınırı ve GSC’nin 500 sitemap kabulü içinde rahatça kalır. Her nasılsa tek bir dizin sınırını (50 000 × 50 000 = 2,5 milyar URL) aşarsanız, birden çok dizin dosyasına bölün ve her birini gönderin. Amaç parçaların boyutunu baştan belirlemektir; böylece günlük yeniden üretim yalnızca her dosyanın içeriğini yeniden yazar ve bir tahmini aştığınız için ağacı yeniden tasarlamanız gerekmez.

Bu konu nereye oturuyor?

E-ticaret sitemap’leri, listeledikleri sayfalarla büyük ölçüde örtüşür. Sitemap’e neyin ait olduğu, kategori sayfası ve facet’li gezinme stratejiniz (hangi filtrelenmiş URL’lerin canonical ve indexable olduğu) tarafından belirlenir. Bir ürünün stoğu tükendiğinde URL’ye ne olacağı, stokta olmayan ve satıştan kaldırılan ürün kararının konusudur. Sitemap, tarayıcıların bir mağazayı keşfetmesinin çeşitli yollarından yalnızca biridir — dahili bağlantıların, IndexNow’un ve (Google Shopping için) bir Merchant Center product feed’inin yanında yer alır. Sitemap bunların hiçbirinin yerini tutmaz; hiçbir şeyin arada kaybolmamasını sağlayan kapsam güvencesidir.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.