Pazaryeri İlan Sitemap'i: Bölme ve lastmod Rehberi

Büyük bir ilan kataloğunda sitemap, arama motoruna "bu URL'ler var" diyen bir listedir. Google'a göre (yeni sekmede açılır) tek bir sitemap dosyası en çok 50.000 URL içerebilir ve sıkıştırılmamış hâliyle 50 MB'ı aşamaz. Katalog bu sınırı geçince dosyaları bölüp bir sitemap index dosyasında toplamanız gerekir. Lastmod alanı ise yalnızca sayfadaki anlamlı bir değişiklikte güncellenmelidir. On binlerce ilanı olan bir pazaryerini yönetiyor ya da teknik SEO işini üstleniyorsanız doğru sitemap tasarımı, yeni ilanların keşfine yardım eden ama tek başına hiçbir şeyi garanti etmeyen bir altyapı katmanıdır. Örnekler tek bir ürün kategorisi üzerinden gider: ikinci el kitap.

Sitemap ilan keşfinde ne yapar, ne yapmaz

Sitemap bir keşif yardımcısıdır. Bir URL'nin dizine girmesini, belirli bir sırada taranmasını ya da sonuçlarda görünmesini sağlamaz. Google'ın e-ticaret site yapısı sayfası (yeni sekmede açılır) sıralamayı değil, ulaşılabilirliği öne çıkarır. Sayfadaki yönlendirme şöyledir: dizinlenmesini istediğiniz her ürüne bağlantı verilmesi şiddetle önerilir, tüm sayfalara bağlantı vermek mümkün değilse sitemap kullanılmalıdır. Besleme dosyaları da bir tarayıcının başka türlü bulamayacağı sayfaların bağlantılarını taşıyabilir.

Bu ifade sitemap'in yerini net biçimde tanımlar: ilk çözüm site içi bağlantı yapısıdır, sitemap ise bağlantıyla ulaşılması zor ilanlar için yedek yoldur. İkinci el kitap pazaryerinde çok sayıda ilan açılıp kapanırken kategori sayfalarından her ilana tıklayarak ulaşmak kolay olmayabilir. Eski ilanlar sayfalama derinliğinde kaybolur, yeni ilanlar henüz hiçbir listeye girmemiş olabilir. Sitemap bu boşluğu kapatmak için vardır.

Sitemap'in yapamadıkları da bellidir:

• Taranmayı veya dizinlenmeyi garanti etmez.
• Bağlantı yapısının yerini tutmaz. Google'a göre bir sayfaya site içinden ne kadar çok bağlantı varsa sitenin içindeki göreli önemi o kadar yüksektir.
• Bozuk ya da yönlendirilen URL'leri iyileştirmez. Listelediğiniz adresin kendisi çalışmıyorsa sitemap sorunu yalnızca daha görünür kılar.
• Site hiyerarşisini URL yapısından çıkarmaz. Google'ın e-ticaret sayfası, URL yapısına bakarak site yapısının anlaşılmadığını söyler.

Karar kuralı: bir ilan hem kategori sayfalarından hem de sitemap'ten ulaşılabilir olmalıdır. Yalnızca sitemap'ten ulaşılabilen ilan yetim sayılır ve bağlantı yapısında bir eksiğe işaret eder. Tarama kapasitesi tarafı için bakın: tarama bütçesi optimizasyonu.

Desteklenen biçimler ve temel kurallar

Google sitemap'in dört biçimde sunulabileceğini belirtir: XML sitemap, RSS 2.0, Atom 1.0 ve satır başına bir URL içeren metin dosyası. Tüm biçimlerde tek dosya sınırı aynıdır: 50 MB (sıkıştırılmamış) veya 50.000 URL. Pazaryeri için XML sitemap en geniş alanı sunar, çünkü lastmod gibi alanlar protokolün parçasıdır.

Tablo: Sitemap dosyası kuralları ve dayanakları

Bu kuralların pazaryerindeki sonuçları somuttur. Mutlak URL kuralı, ilan adreslerinin göreli yol olarak değil, protokol ve alan adıyla yazılmasını gerektirir. Ve işareti, parametreli adreslerde kaçış ister. Ayrı bir alt alan adında yayımlanan ilanlar ana alan adındaki sitemap'e eklenemez, çünkü sitemaps.org protokolü (yeni sekmede açılır) URL'lerin sitemap ile aynı ana makinede bulunmasını ister.

Konum ve kapsam

Google, sitemap'i sitenizde herhangi bir yerde barındırabileceğinizi söyler. Search Console üzerinden göndermediğiniz bir sitemap yalnızca bulunduğu dizinin altındaki sayfaları etkiler. Kök dizindeki bir sitemap ise sitedeki tüm dosyaları etkileyebilir ve sayfa sitemap'lerin kökte yayımlanmasını önerir. Tek bir ilan kataloğu için kökte bir index dosyası ve ona bağlı dosyalar bu öneriye uyar.

50.000 URL ve 50 MB sınırı: dosyaları bölmek

Sınırlar iki ayrı eşiktir ve hangisinin önce aşılacağı katalogdan kataloga değişir. Her URL'nin uzun parametrelerle yazıldığı bir kataloğun dosyası 50 MB'a, kısa adresli bir kataloğun dosyası ise 50.000 URL sınırına önce ulaşabilir. Uygulama önerisi: bölme kararını yalnızca URL sayısına göre değil, üretilen dosyanın gerçek boyutuna göre de verin ve her iki eşiğin altında pay bırakın. Kataloga her gün yeni ilan eklendiği için sınırın tam kenarında çalışan bir dosya bir sonraki üretimde taşabilir.

Sitemaps.org, 50.000 URL ve 50 MB (52.428.800 bayt) sınırının her bir dosya için geçerli olduğunu yazar. Google sınırın sıkıştırılmamış boyut üzerinden okunduğunu açıkça belirtir; yani dosyayı sıkıştırmak sınırı büyütmez.

Bölme ölçütünü seçmek

Belgeler dosyaların nasıl bölüneceği konusunda bir ölçüt dayatmaz. Hangi ölçütle böleceğiniz tasarım kararıdır. Uygulama önerisi: ölçütü, sorun çıktığında hangi dosyaya bakacağınızı kolaylaştıracak şekilde seçin.

Tablo: Bölme ölçütleri ve karar notları

Karar kuralı: kategori büyüklükleri tek dosyaya sığıyorsa kategoriye göre bölün. Bir kategori sınırı aşıyorsa o kategoriyi ikinci bir ölçütle (örneğin yayın tarihi aralığı) kendi içinde bölün. Bölme ölçütünü sık değiştirmeyin, çünkü dosya adları ve içerikleri sürekli kayan bir yapıyı izlemek zordur.

Örnek senaryo: ikinci el kitap kataloğu

Örnek senaryo: ikinci el kitap ilanlarının satıldığı bir pazaryerinde edebiyat, ders kitabı, çocuk kitabı ve koleksiyon kitapları ayrı kategorilerdir. Ders kitabı kategorisi dönem başlarında yoğun ilan alır ve tek başına 50.000'i aşabilir. Bu durumda ders kitabı kategorisi iki ya da daha çok dosyaya bölünür, diğer kategoriler tek dosyada kalır. Her dosya kategori adını ve sıra numarasını taşır; "ders-kitabi-3" gibi bir ad doğrudan hangi ilan aralığını işaret ettiğini söyler.

Satılan ya da kaldırılan ilanlar için dosyalar yeniden üretilirken kullanılamayan ilan adreslerinin sitemap'ten çıkarılması gerekir. Çıkarılan adreslerin nasıl yanıt vermesi gerektiği (404, 410 veya yönlendirme) ayrı bir karardır. Sitemap hatalarının denetimi için bakın: XML sitemap denetimi ve hata çözümü.

Sitemap index dosyası

Google, isteğe bağlı olarak bir sitemap index dosyası oluşturabileceğinizi ve yalnızca bu tek dosyayı gönderebileceğinizi söyler. Sitemaps.org index dosyasının en çok 50.000 sitemap listeleyebileceğini belirtir. Dosya başına 50.000 URL ile birlikte düşünüldüğünde bu çok büyük bir kapasitedir. Yine de sınırın var olduğunu bilmek, otomatik üretim kodunda bir üst denetim koymak için yeterli gerekçedir.

Index dosyasının görevi dosyaları listelemektir. Uygulama önerisi: tek seviyeli bir yapı kurun, yani kökte bir index ve altında doğrudan URL içeren sitemap dosyaları.

Index içindeki her dosya kaydı için lastmod verirseniz, bu tarih dosyanın içindeki değişikliği yansıtmalıdır. Sitemaps.org'daki ilke, tarihin bağlantılı kaynağın en son değiştiği tarih olmasını, sitemap'in üretildiği tarih olmamasını ister.

lastmod yalnızca anlamlı değişiklikte güncellenir

Lastmod alanı sitemap'in en kolay yanlış kullanılan alanıdır, çünkü her üretimde güncel tarihi yazmak kolaydır. Google iki şeyi birlikte söyler: lastmod değeri tutarlı ve doğrulanabilir biçimde doğru olduğu sürece kullanılır, ve değer sayfadaki son anlamlı güncellemenin tarih ve saatini yansıtmalıdır. Sitemaps.org da tarihin sayfanın en son değiştiği tarih olması gerektiğini, sitemap'in üretildiği tarih olmadığını yazar.

Bu iki ifade pazaryerinde şu sonuca varır: sitemap üretim betiği her gece çalışıyor diye bütün ilanlara aynı tarihi yazarsanız lastmod doğrulanabilir tutarlılığını kaybeder. Google değerin kullanılması için tutarlı ve doğrulanabilir olmasını koşul koyar.

Anlamlı değişiklik nedir?

Uygulama önerisi: ikinci el kitap ilanı için şu ayrımı kullanın.

Tablo: lastmod güncelleme kararı

Teknik yazım

Sitemaps.org lastmod için W3C tarih-saat biçimini kullanır ve tarihin tek başına da yeterli olduğunu belirtir. Google ise tarih ve saati birlikte anar. Uygulama önerisi: ilan sistemi saat bilgisini zaten tutuyorsa saat dilimiyle birlikte tam zaman damgası yazın.

Uygulama önerisi: lastmod verisini ilanın veritabanı kaydındaki "içerik güncellendi" alanından türetin. "Kaydın herhangi bir sütunu değişti" zaman damgası, okunma sayacı gibi içerikle ilgisiz alanların da lastmod'u değiştirmesine yol açar. Bu nedenle içerik alanları (başlık, açıklama, fiyat, durum, fotoğraf) değiştiğinde güncellenen ayrı bir zaman damgası tutmak, hem sitemap'i hem de iç raporlamayı temiz bırakır.

Örnek senaryo: tarih kayması

Örnek senaryo: pazaryerinde gece 03.00'te çalışan bir betik, katalogdaki bütün ilanların güncelleme alanını "şimdi" yapıyor. Ertesi sabah sitemap'te çok sayıda ilanın lastmod değeri aynı günü gösteriyor, oysa ilanların çok küçük bir kısmı gerçekten değişmiş. Çözüm, betiğin yalnızca içerik alanı değişen kayıtlarda zaman damgasını güncellemesi ve sitemap üretiminin bu alana bakmasıdır. Betik düzeltildikten sonra eski sitemap dosyalarındaki yanlış tarihler bir sonraki üretimde kendiliğinden doğru değerlere döner.

priority ve changefreq alanları

Google belgesi bu iki alanı doğrudan ele alır: Google priority ve changefreq değerlerini yok sayar. Sitemaps.org'a göre priority için geçerli değerler 0.0 ile 1.0 arasındadır, bir sayfanın varsayılan önceliği 0.5'tir ve changefreq bir komut değil, ipucudur. Bu alanları doldurmak Google için bir fayda sağlamaz ve her kayıt için dosya boyutunu büyütür.

Karar kuralı: boyut sınırına yaklaşan bir katalogda bu iki alanı yazmayın. Her URL kaydı kısalır ve 50 MB sınırına daha geç ulaşırsınız.

Sitemap'e hangi ilan URL'leri girer

Google belgesi hangi URL'lerin listelenmesi gerektiğine dair ayrıntılı bir ölçüt listesi vermez. Elde olan ifade, listelenen URL'lerin tam nitelikli, mutlak adresler olması ve sitemaps.org kurallarına göre aynı protokol ve ana makinede bulunmasıdır.

Uygulama önerisi, kontrol listesi:

• Yalnızca dizinlenmesini istediğiniz ilanların kanonik adreslerini yazın. Aynı ilana parametreli ve parametresiz iki adres varsa yalnızca birini listeleyin.
• Satılmış ve yayından kalkmış ilanları, adresleri artık içerik göstermiyorsa çıkarın.
• Yönlendirilen adresleri değil, yönlendirmenin varış adresini yazın.
• Oturum ya da arama kimliği taşıyan adresleri listelemeyin.
• Filtre ve sıralama sayfalarını yalnızca bilinçli olarak dizinlenmesini istiyorsanız ekleyin.
• Giriş gerektiren ya da noindex ile işaretli sayfaları listelemeyin, çünkü sitemap'in bir URL'yi önerip sayfanın dizinden uzak durmasını istemesi çelişkili bir sinyal verir.

Amaç, sitemap'i "dizinlenmesini istediğim sayfalar" listesi olarak tutmaktır.

Gönderim, yayımlama ve izleme

Google üç gönderim yolunu sayar: Search Console'daki Sitemaps raporundan göndermek, Search Console API ile programatik olarak göndermek ve robots.txt dosyasına bir Sitemap satırı eklemek. Atom ya da RSS besleme kullanıyorsanız WebSub ile değişiklikleri arama motorlarına duyurabilirsiniz. Arayüzü Türkçe kullanıyorsanız menü ve rapor adları farklı görünebilir; İngilizce arayüzde rapor adı "Sitemaps" olarak geçer.

Index dosyasını gönderiyorsanız tek bir adres göndermeniz yeterlidir. Uygulama önerisi: robots.txt içine yalnızca index dosyasının adresini yazın. Böylece yeni sitemap dosyası eklendiğinde robots.txt'ye dokunmanız gerekmez.

Dosya bazında izleme

Bu yüzden raporda neyin görüneceğine dair bir vaat verilemez. Uygulama önerisi: bölme ölçütünü kategoriye bağladıysanız, bir dosyada sorun çıktığında hangi kategorinin etkilendiğini tek bakışta anlarsınız. Kendi tarafınızda da dosya başına URL sayısı, boyut, üretim zamanı ve son hata sayısını bir kayıt tablosuna yazın. Böylece Search Console'daki bir değişiklik kendi üretim kaydınızla karşılaştırılabilir.

Tablo: Üretim kayıt tablosu için alanlar

Görsel ve video sitemap uzantıları bu konunun dışındadır.

Üretim sürecinin düzeni

Sitemap'i elle değil, katalogdan otomatik üreten bir süreç kurmak pazaryeri için gereklidir. Sürecin dört kararı vardır.

Üretim sıklığı ve kaynağı

Uygulama önerisi: tam yeniden üretim yerine yalnızca ilanı değişen kategorinin dosyalarını yeniden üretin. Her gece çok sayıda dosyayı baştan yazmak, hiçbir ilanı değişmemiş kategoriler için de yeni tarih riskini doğurur. İçeriği değişmemiş dosyayı aynen bırakmak üretim süresini kısaltır ve tutarlı bir lastmod geçmişi bırakır.

Atomik yayımlama

Dosyalar yazılırken yarım dosya yayımlanmamalıdır. Uygulama önerisi: dosyayı geçici bir adla yazın, URL sayısını ve boyutu denetleyin, doğrulama geçerse son adıyla yeniden adlandırın. Üretim sırasında hata çıkarsa eski sağlam dosya yayında kalır.

Sıkıştırma

Sıkıştırma kullansanız bile sınır hesabını açılmış boyut üzerinden yapın.

Başarısızlık durumunda davranış

Üretim sırasında veritabanı hatası olursa boş bir sitemap yayımlamayın. Boş ya da çok küçük bir dosya, kataloğun tamamının sitemap'ten çıkmış gibi görünmesine yol açar. Uygulama önerisi: yeni dosyadaki URL sayısı önceki üretimin belirli bir oranının altına düşerse yayımlamayı durdurun ve uyarı üretin. Oranı ekibin gerçek katalog dalgalanmasına göre belirleyin.

Dosya adlandırma ve index düzeni

Dosya adı, sorun çıktığında ilk okuduğunuz bilgidir. Uygulama önerisi: kategori kısa adı, sıra numarası ve sabit bir önek taşıyan adlar kullanın. Örneğin ikinci el kitap kataloğunda edebiyat için bir dosya, ders kitabı için üç dosya, çocuk kitabı için bir dosya ve koleksiyon kitapları için bir dosya bulunabilir. Index dosyası bu beş kaydı listeler ve robots.txt yalnızca index adresini bildirir.

Adlandırma kararında üç ilkeyi birlikte tutun:

• Ad, içerik değiştiğinde değişmesin. Tarih içeren dosya adları her üretimde yeni bir adres doğurur ve Search Console gönderimini bozar.
• Ad, URL güvenli karakterlerden oluşsun. Boşluk ve Türkçe karakterler ayrıca kaçış gerektirir.
• Ad, kendi kayıt tablonuzdaki satırla bire bir eşleşsin.

Dosyalar index'te listelenirken her dosyanın adresi de mutlak olmalı ve aynı ana makinede bulunmalıdır. Sitemaps.org konum kuralı index dosyası için de geçerlidir: index'in bulunduğu yer, listeleyebileceği dosyaları sınırlar. Kökte bir index, kök altında dosyalar, bu kuralın en sade uygulamasıdır.

Bu düzen kurulduktan sonra bir yeni kategori açıldığında yapılacak işler de netleşir: yeni kategori için bir dosya adı ayrılır, üretim sorgusuna kategori eklenir, index'e yeni kayıt girer ve kayıt tablosunda yeni bir satır belirir. Dört adımlık bu iş akışını bir kontrol listesine bağlamak, yeni kategorilerin sitemap dışında kalmasını önler.

Katalog büyürken eşik yönetimi

Sınırlar bir kez kurulup unutulacak değerler değildir. İlan sayısı arttıkça bir kategori dosyasının eşiğe yaklaşması, bölme planını yeniden gözden geçirmeyi gerektirir. Uygulama önerisi: üretim süreci her dosyada iki oran hesaplasın: URL sayısının 50.000'e oranı ve boyutun 50 MB'a oranı. Oranlardan biri belirlediğiniz uyarı çizgisine ulaştığında dosya otomatik olarak ikiye bölünsün ya da ekibe bildirim gitsin.

Uyarı çizgisini seçerken ilan akışının hızını hesaba katın. Günde binlerce ilan alan bir kategori ile haftada birkaç yüz ilan alan kategori aynı çizgiyi taşımaz. Hızlı büyüyen kategoride çizgiyi düşük tutun, yavaş kategoride yüksek tutun. Belgeler bu konuda bir değer önermez; çizgi tamamen sizin akış verinize bağlıdır.

Bölünmüş dosyanın kimliği kararlı kalmalı

Bir kategori ikiye bölündüğünde birinci dosyanın adı değişmemeli, yeni ilanlar ikinci dosyaya akmalıdır. Aksi hâlde her bölmede bütün dosyaların içeriği kayar ve izleme geçmişi anlamsızlaşır. Uygulama önerisi: yeni ilanları yalnızca en yeni dosyaya yazan, eski dosyalara yalnızca güncelleme ve çıkarma işlemi uygulayan bir kural kullanın.

Örnek senaryo: dönem başı yoğunluğu

Örnek senaryo: ders kitabı kategorisi eylül ve şubat aylarında hızla büyüyor. Üretim süreci, kategorinin ikinci dosyası eşik çizgisine ulaştığında üçüncü dosyayı açıyor ve index dosyasına ekliyor. Dönem bittiğinde satılan kitapların adresleri eski dosyalardan çıkıyor, dosyalar küçülüyor. Küçülen dosyaların birleştirilmesi zorunlu değildir; kararlı dosya adları, izleme geçmişi açısından birleştirmeden daha değerlidir.

Sorun çıktığında teşhis sırası

Yeni ilanların geç keşfedildiğini düşündüğünüzde sitemap'e bakmak mantıklı bir ilk adımdır, ancak sorun sitemap dışında da olabilir. Sıralı bir teşhis, gereksiz değişikliklerden kaçınmanızı sağlar.

Tablo: Belirti ve ilk kontrol

Karar kuralı: önce kendi üretim kaydınıza, sonra sitemap dosyasının kendisine, en son Search Console'daki rapora bakın. Kendi kaydınızda sorun görünmüyorsa ve dosya doğruysa, sorunu bağlantı yapısında ya da tarama kapasitesinde aramanız gerekir.

Roller ve sorumluluklar

Sitemap üretimi tek bir ekibin işi gibi görünse de karar noktaları farklı kişilere dağılır. Net bir sorumluluk tablosu, lastmod ve çıkarma kuralı gibi kararların sahipsiz kalmasını önler.

Tablo: Sitemap sorumluluk dağılımı

İkinci el kitap örneğinde ürün sahibi, "satıldı" ve "rezerve" durumlarının listeden çıkarılıp çıkarılmayacağına karar verir. Rezerve ilan kısa süre sonra yeniden satışa dönebiliyorsa listede tutmak ya da çıkarmak iş kuralıdır. Belgelerde bu durum için ifade yok, karar ürün davranışınıza bağlıdır.

Yayından önce kontrol listesi

Kontrol listesi: Sitemap yayın öncesi denetimi

• Her dosyada URL sayısı 50.000'in, sıkıştırılmamış boyut 50 MB'ın altında mı?
• Dosyalar UTF-8 olarak kaydedildi mi ve özel karakterler kaçışlı mı?
• Tüm URL'ler mutlak, aynı protokol ve aynı ana makinede mi?
• Index dosyası kökte mi ve bölünmüş dosyaların hepsini listeliyor mu?
• Lastmod değerleri ilanın içerik değişikliğinden mi türüyor, üretim zamanından değil mi?
• Priority ve changefreq yazılmadı mı ya da yazılacaksa bilerek mi?
• Satılmış, silinmiş, yönlendirilen ve noindex adresler listeden çıkarıldı mı?
• Index dosyası Search Console'a gönderildi ve robots.txt'ye Sitemap satırı eklendi mi?
• Üretim hatasında eski dosya yayında kalıyor mu?
• Dosya başına URL sayısı ve üretim zamanı kayda alınıyor mu?

Dikkat edilecek hatalar

Her üretimde tüm tarihleri yenilemek

Sitemap üretiminde tüm ilanlara şimdiki zamanı yazmak, lastmod alanının tutarlı ve doğrulanabilir olma koşuluna aykırıdır. Sitemaps.org da tarihin üretim anı olmaması gerektiğini söyler.

Sınırda sessizce kesilen dosya

Dosya sınırı aşıldığında üretimi sessizce kesen bir betik, son ilanları sitemap'e almadan dosyayı kapatabilir. Bölme mantığını, sınır aşılınca bir sonraki dosyaya geçecek biçimde yazın ve kesilen dosya için uyarı verin.

Sitemap'i bağlantı yapısının yerine koymak

Kategori sayfalarından ulaşılamayan ilanlar sitemap'te bulunsa bile Google'ın sitenin yapısını anlamasına yardımcı olmaz. Google'ın e-ticaret yapısı sayfası, ürünlerin kategori gezintisinden ulaşılabilir olmasını vurgular.

Farklı ana makineden URL

Mağaza alt alanında yayımlanan ilanların ana alan adı sitemap'ine konması sitemaps.org konum kuralına aykırıdır. Her ana makine için o ana makinede yayımlanan sitemap kullanılmalıdır.

Kaçış karakterlerini atlamak

Parametreli adreslerde ve işareti kaçışsız bırakılırsa XML ayrıştırılamaz. Dosyayı metin birleştirerek değil, XML yazan bir kütüphaneyle üretin.

Sık Sorulan Sorular

Bir sitemap dosyasına en çok kaç URL konabilir?

Google ve sitemaps.org tek dosya için en çok 50.000 URL ve sıkıştırılmamış 50 MB sınırını verir. Sınırlar değişebilir, uygulamadan önce Google'ın güncel sayfasına bakın.

Sitemap index dosyası zorunlu mu?

Google index dosyasını isteğe bağlı olarak tanımlar. Katalog tek dosyaya sığıyorsa gerekmez. Birden fazla dosyaya bölündüğünde tek bir adres göndermeyi mümkün kılar.

lastmod alanına her gün bugünün tarihini yazabilir miyim?

Hayır. Google değerin sayfadaki son anlamlı güncellemeyi yansıtmasını ve tutarlı ve doğrulanabilir olmasını ister. Sitemaps.org tarihin sitemap'in üretildiği tarih olmaması gerektiğini söyler.

priority ve changefreq yazmalı mıyım?

Google bu iki alanı yok sayar. Google bu alanları yok sayar; başka arama motorları için kendi belgelerini kontrol edin. Dosya boyutunu küçük tutmak istiyorsanız yazmayın.

Sitemap bir ilanın dizine girmesini garanti eder mi?

Belgelerde böyle bir vaat yok. Google ilanlara site içinden bağlantı verilmesini önerir ve bağlantı vermenin mümkün olmadığı sayfalar için sitemap kullanılmasını söyler.

Satılan ilanları sitemap'ten çıkarmak gerekir mi?

Uygulama önerisi: içerik göstermeyen adresleri listeden çıkarın, yalnızca çalışan kanonik adresleri tutun.

Sonuç

Pazaryeri sitemap'i üç kararın toplamıdır: dosyaların 50.000 URL ve 50 MB sınırının altında kalacak şekilde bölünmesi, bölünen dosyaların tek bir index dosyasında toplanması ve lastmod değerinin yalnızca sayfadaki anlamlı değişiklikte güncellenmesi. Priority ve changefreq alanlarını Google yok saydığı için ilk üretimde bırakabilirsiniz. Üretim hatasında eski dosyayı koruyan, kategoriye göre bölünmüş ve kendi kayıt tablonuzla izlenen bir yapı, yeni ilanların keşfini destekleyen sağlam bir temel olur.

Sitemap keşfi kolaylaştırır ama ilan kartlarının, kategori yapısının ve reklam görünürlüğünün yerini almaz. İlanlarınızın daha geniş bir kitleye ulaşması için reklam alanlarını inceleyin.