Chat Sitelerinde Oda Bazlı Index Sitemap (Sitemap Index + Segmentasyon) Nasıl Kurulur? (Adım Adım)

Chat uygulamalarında dinamik URL üretimi, hızlı içerik değişimi ve çok sayıda benzer sayfa yüzünden klasik sitemap yaklaşımı çoğu zaman beklediğiniz gibi ölçeklenmez. Bu yüzden chat sitelerinde sitemap’i odalara göre parçalara ayırma (index sitemap) konusu, sadece “dosya bölmek” değil; keşif önceliği, canonical tutarlılığı ve üretim maliyeti birlikte ele alınarak planlanmalıdır.

Özellikle oda sayısı her gün binlerce yeni sayfa üretiyorsa, tek bir sitemap.xml yerine oda bazlı segmentasyon + sitemap index mimarisi kurmak arama motoru keşfini daha öngörülebilir hale getirir. Bu yazıda size adım adım; hangi URL’leri hangi child sitemap’e koymanız gerektiğini, segmentasyonun nasıl otomatikleştirileceğini ve Google tarafında nasıl doğrulayacağınızı anlatacağım.

Kapsam: sitemap limitleri, sitemap index nedir, neden oda segmentasyonu gerekir?

Sitemaps, arama motorlarına “hangi URL’leri keşfet ve ne zaman güncellediğim” sinyali verir. Ancak chat sitelerinde bu mekanizma limitler nedeniyle kolayca zorlanır. Standart pratik limitlerde her sitemap dosyası için URL sayısı yaklaşık ~50.000 civarında hedeflenir; dosya boyutu da (sıkıştırma/transport koşullarına göre) ayrı bir kısıt oluşturur.

Sitemap index ise birden fazla sitemap dosyasını tek bir ana dosyada listeler. Böylece URL’leri mantıklı parçalara bölersiniz; hem limitleri aşmazsınız hem de belirli grupların daha sık güncellenmesini (ör. yüksek trafikli oda segmentleri) daha temiz şekilde yönetebilirsiniz.

Oda segmentasyonu gereklidir; çünkü sohbet odaları hem çok sayıdadır hem de farklı hızlarda değişir. Örneğin “destek” odalarında lastmod daha sık güncellenirken “arşiv” odalarında değişim çok daha düşüktür. Segmentasyon hem crawl bütçenizi doğru kullanmanıza hem de sitemap üretim yükünü daha dengeli dağıtmanıza yardımcı olur.

Mevcut durum analizi: robots.txt ve sitemap.xml doğrulama, URL sayısı ve değişim

İlk adım olarak sistemin “doğru sinyal gönderiyor mu” kısmını ölçün. Önce robots.txt içinde sitemap index (veya sitemap.xml) referanslarının doğru çalıştığını doğrulayın. Ardından sitemap endpoint’inizi doğrudan çağırarak gerçek XML içeriğini kontrol edin (tarayıcı + curl benzeri yöntemlerle).

Sonra URL envanteri çıkarın: toplam oda sayısı, her oda için sitemap’e girecek URL türleri (oda ana sayfası, kategori sayfası, mesaj arşivi varsa ayrı), günlük artış ve ortalama değişim sıklığı.

Chat sitelerinde gizli çoğaltma riski yüksektir: parametreli varyantlar, hash/oturum temelli URL’ler ya da benzer içerik için çok sayıda türetilen varyantlar oluşabilir. Analizde özellikle şunu netleştirin: “Hangi URL tipleri gerçekten indekslenmeye değer, hangileri canonical ile tekleştirilmeli?”

URL sınıflandırma modeli: ‘oda URL’i, kategori/etiket URL’i, kullanıcı profili URL’i vb.’ ayrımı

Oda bazlı index sitemap tasarımı bir “router” mantığı ister: Bir URL geldiğinde hangi child sitemap’te yer alacağını belirleyen kurallarınız olmalı. Bu nedenle ilk iş, URL’leri sınıflandıran bir model üretmek olmalı.

Pratik bir sınıflandırma şunları kapsar:

• Oda URL’leri: Örn. /o/oda-adi-123 (indekslenmek isteyen ana hedefler)
• Kategori/etiket URL’leri: Oda listelerinin filtreli görünümleri (ör. /c/... veya /t/...)
• Kullanıcı profili URL’leri: Sohbet etkileşimi olan kullanıcı sayfaları (çoğu zaman oda sayfalarından daha yavaş değişir)
• Yardımcı/kurumsal sayfalar: kurallar, arşiv, hakkımızda gibi daha statik sayfalar

Bu ayrım SEO açısından önemlidir; çünkü oda URL’leri genellikle en değerli ve en sık değişen grup olur. Kategori/etiket ve kullanıcı profili sayfaları için lastmod ve öncelik stratejisi doğal olarak farklılaşır.

Segmentasyon stratejileri: oda türü / harf aralığı / oda id aralığı / hash / zaman bazlı (ne zaman hangisi?)

Segmentasyon seçimi, URL üretim düzeniniz ve ölçek hızınıza göre şekillenmelidir. Çoğu senaryoda tek bir strateji yetmez; ancak ilk sürümde en deterministik olanı seçip sonra iyileştirmek genellikle en sağlam yoldur.

1) Oda türü bazlı segmentasyon: Oda türlerini (destek, genel sohbet, hobi vb.) ayrı child sitemap havuzlarına bölün. Trafik yoğun türler daha sık güncellenir; bu sayede lastmod sinyali daha anlamlı hale gelir.

2) Alfabetik aralık (A–H, I–P, Q–Z): Oda slug’ının baş harfini veya ilk N karakteri üzerinden aralıklar tanımlayın. Örn. “oda-adasi-123” A–H child sitemap’te yer alır.

3) Oda ID aralığı: Oda id’leri ardışık artıyorsa en stabil segmentasyon budur. Oda ID 1–100.000 arası bir child sitemap; 100.001–200.000 arası başka child sitemap üretin. Böylece oda kapanma/taşınma gibi durumlarda hataları azaltırsınız.

4) Hash’leme: odaId % K yöntemiyle eşit dağıtım hedeflenir. Fakat izlenebilirlik (hata ayıklama) azalır ve “hangi segment değişti” tespiti için ek metrik gerekir.

5) Zaman bazlı segmentasyon: “son 7 günde açılan odalar” gibi pencereler. Hızlı büyüme dönemlerinde discovery’yi artırabilir; ancak child sayısı aşırı artarsa index yönetimi zorlaşır. Bu yüzden pencere süresini ve toplam child limitini kontrol etmelisiniz.

Sitemap dosya boyutu ve URL limitleri: pratik limitler, dosya sayısı planlama

Child sitemap sayısını doğru hesaplamak, sistemin hem performansını hem de operasyonel maliyetini etkiler. Plan yaparken iki temel limit düşünün: URL sayısı limiti ve dosya boyutu limiti (sıkıştırma/transport etkileriyle birlikte pratikte 50MB bandı referans alınır).

Bir model kurun: Child sitemap başına hedef URL sayısı N olsun. Toplam oda URL sayınız T ise, child sayınız yaklaşık ceil(T / N) olur. Örneğin 1.200.000 oda URL’iniz varsa ve child başına 40.000 hedefliyorsanız 30 child sitemap görürsünüz. Kategori/etiket gibi ek URL tiplerini ayrıca koyuyorsanız bu sayı artar.

Segmentasyon kararınız aynı zamanda üretim maliyetine de etki eder. Oda id aralığı kullanıyorsanız “hangi aralık değişti”yi kolayca bulur ve incremental build mümkün hale gelir. Alfabetik aralıkta da slug tabanlı değişim tespit edilebilir; dolayısıyla güncelleme stratejiniz daha net olur.

Segmentasyon Türü	Avantaj	Dezavantaj / Risk	Uygun Olduğu Durum
Oda Türü Bazlı (support/general)	Lastmod üretimini anlamlandırır; crawl önceliği daha yönetilebilir	Çocuk sitemap sayısı hızla artabilir	Oda türleri farklı trafik ve değişim hızına sahipse
Oda ID Aralığı (1-100k / 100001-200k)	Deterministik ve incremental güncelleme için ideal	ID boşlukları varsa dağılım dengesizleşebilir	Oda id’leri ardışık ve güvenilir artıyorsa
Alfabetik Aralık (A–H, I–P, Q–Z)	İnsan okur log/iz sürüm kolaylığı	Slug dağılımı dengesiz olabilir; bazı segment şişer	Slug temelli URL üretimi varsa ve dağılım nispeten dengeliyse

Sitemap index mimarisi: index dosya formatı, child sitemap adlandırma kuralı

Index sitemap’in görevi; child sitemap URL’lerini listelerken XML standartlarını bozmadan erişilebilir linkler sağlamaktır. Index dosyası da genellikle <sitemapindex> formatındadır ve her child için <sitemap> + <loc> + <lastmod> alanları kullanılır.

Adlandırma kuralı operasyonel hayatta büyük fark yaratır. İyi bir kural, “child sitemap’i nereden üretmişim, hangi segment?” sorularını logdan hızlıca görmenize yardım eder. Örneğin:

• sitemap-rooms-type-support-01.xml
• sitemap-rooms-alpha-A-H-02.xml
• sitemap-rooms-id-000001-100000.xml

Index dosyasını barındıracağınız endpoint stabil olmalı: 403/404 üretmemeli, HTTPS ile her zaman erişilebilir olmalı ve cache stratejisi doğru konfigüre edilmiş bir konumda tutulmalıdır.

Örnek XML şablonları: sitemap-index.xml + oda child sitemap örnekleri

Aşağıdaki örnekler bir “şema şablonu” gibi düşünülmelidir. Kendi domain’iniz, dizininiz ve konumlarınıza göre güncelleyin.

1) sitemap-index.xml (örnek)

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemaps/rooms/sitemap-rooms-alpha-A-H-01.xml</loc>
    <lastmod>2026-04-14</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemaps/rooms/sitemap-rooms-alpha-I-P-01.xml</loc>
    <lastmod>2026-04-13</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemaps/rooms/sitemap-rooms-id-000001-100000.xml</loc>
    <lastmod>2026-04-14</lastmod>
  </sitemap>
</sitemapindex>

2) child sitemap (oda A–H örneği)

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/o/oda-adasi-123</loc>
    <lastmod>2026-04-14</lastmod>
  </url>
  <url>
    <loc>https://example.com/o/oda-aksu-987</loc>
    <lastmod>2026-04-12</lastmod>
  </url>
</urlset>

Oda URL formatını varsayalım: 3 farklı child sitemap segmentasyonu (A–H, I–P, Q–Z veya id aralığı)

Varsayalım ki oda URL formatınız şu şekilde: /o/oda-adi-123. Şimdi üç segmentasyon kurgusu ile aynı mantığı kurabilirsiniz.

Segmentasyon A: Alfabetik aralık Slug ilk harfine göre:

• A–H: sitemap-rooms-alpha-A-H-XX.xml
• I–P: sitemap-rooms-alpha-I-P-XX.xml
• Q–Z: sitemap-rooms-alpha-Q-Z-XX.xml

Segmentasyon B: Oda ID aralığı ID 1–100.000: sitemap-rooms-id-000001-100000.xml ID 100.001–200.000: sitemap-rooms-id-100001-200000.xml

Segmentasyon C: Oda türü bazlı Örneğin “support” ve “general” türlerini ayırın:

• sitemap-rooms-type-support-01.xml
• sitemap-rooms-type-general-01.xml

Burada önemli olan şey şu: child sitemap üretim kuralınız deterministik olmalı. Böylece aynı oda her zaman aynı segmentte kalır, canonical/lastmod doğruluğu korunur.

Örnek: sitemap index’te 20+ child sitemap satırının gösterimi (tam örnek XML parçaları)

Chat sitelerinde segmentasyon gerçekçi şekilde 20+ child sitemap’e ulaşabilir. Aşağıda 21 child sitemap satırı içeren örnek bir parçayı göreceksiniz (tamamı index dosyasının içinde yer alır):

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap><loc>https://example.com/sitemaps/rooms/sitemap-rooms-type-support-01.xml</loc><lastmod>2026-04-14</lastmod></sitemap>
  <sitemap><loc>https://example.com/sitemaps/rooms/sitemap-rooms-type-support-02.xml</loc><lastmod>2026-04-14</lastmod></sitemap>
  <sitemap><loc>https://example.com/sitemaps/rooms/sitemap-rooms-type-support-03.xml</loc><lastmod>2026-04-13</lastmod></sitemap>

  <sitemap><loc>https://example.com/sitemaps/rooms/sitemap-rooms-type-general-01.xml</loc><lastmod>2026-04-13</lastmod></sitemap>
  <sitemap><loc>https://example.com/sitemaps/rooms/sitemap-rooms-type-general-02.xml</loc><lastmod>2026-04-12</lastmod></sitemap>
  <sitemap><loc>https://example.com/sitemaps/rooms/sitemap-rooms-type-general-03.xml</loc><lastmod>2026-04-12</lastmod></sitemap>
  <sitemap><loc>https://example.com/sitemaps/rooms/sitemap-rooms-type-general-04.xml</loc><lastmod>2026-04-11</lastmod></sitemap>

  <sitemap><loc>https://example.com/sitemaps/rooms/sitemap-rooms-alpha-A-H-01.xml</loc><lastmod>2026-04-14</lastmod></sitemap>
  <sitemap><loc>https://example.com/sitemaps/rooms/sitemap-rooms-alpha-A-H-02.xml</loc><lastmod>2026-04-13</lastmod></sitemap>
  <sitemap><loc>https://example.com/sitemaps/rooms/sitemap-rooms-alpha-A-H-03.xml</loc><lastmod>2026-04-11</lastmod></sitemap>

  <sitemap><loc>https://example.com/sitemaps/rooms/sitemap-rooms-alpha-I-P-01.xml</loc><lastmod>2026-04-14</lastmod></sitemap>
  <sitemap><loc>https://example.com/sitemaps/rooms/sitemap-rooms-alpha-I-P-02.xml</loc><lastmod>2026-04-13</lastmod></sitemap>

  <sitemap><loc>https://example.com/sitemaps/rooms/sitemap-rooms-alpha-Q-Z-01.xml</loc><lastmod>2026-04-14</lastmod></sitemap>
  <sitemap><loc>https://example.com/sitemaps/rooms/sitemap-rooms-alpha-Q-Z-02.xml</loc><lastmod>2026-04-13</lastmod></sitemap>

  <sitemap><loc>https://example.com/sitemaps/rooms/sitemap-rooms-id-000001-100000.xml</loc><lastmod>2026-04-14</lastmod></sitemap>
  <sitemap><loc>https://example.com/sitemaps/rooms/sitemap-rooms-id-100001-200000.xml</loc><lastmod>2026-04-14</lastmod></sitemap>
  <sitemap><loc>https://example.com/sitemaps/rooms/sitemap-rooms-id-200001-300000.xml</loc><lastmod>2026-04-13</lastmod></sitemap>

  <sitemap><loc>https://example.com/sitemaps/rooms/sitemap-rooms-time-last7d-01.xml</loc><lastmod>2026-04-14</lastmod></sitemap>
  <sitemap><loc>https://example.com/sitemaps/rooms/sitemap-rooms-time-last7d-02.xml</loc><lastmod>2026-04-14</lastmod></sitemap>

  <sitemap><loc>https://example.com/sitemaps/rooms/sitemap-rooms-time-last30d-01.xml</loc><lastmod>2026-04-10</lastmod></sitemap>

  <sitemap><loc>https://example.com/sitemaps/rooms/sitemap-rooms-archived-01.xml</loc><lastmod>2026-04-02</lastmod></sitemap>
  <sitemap><loc>https://example.com/sitemaps/rooms/sitemap-rooms-archived-02.xml</loc><lastmod>2026-04-02</lastmod></sitemap>
</sitemapindex>

Dinamik ortam kurgusu: yeni oda oluşturulunca sitemap nasıl güncellenir? (batch vs incremental)

Yeni oda saniyeler içinde oluşabilir. Bu yüzden sitemap güncellemesini ya periyodik batch ile ya da segment bazlı incremental yaklaşımla yaparsınız. Burada iki alternatifi yan yana koyuyorum.

Yaklaşım 1: Batch job (periyodik yeniden üretim) Örn. her 15 dakikada bir ya da günde bir kez: tüm child sitemap’leri veya seçili bir havuzu yeniden üretin. Bu yöntem kolaydır; ancak son oda keşfi gecikebilir.

Yaklaşım 2: Incremental (artımlı ekleme) Oda eklendiğinde ilgili child sitemap’i bulun (ör. oda slug baş harfi A–H ise alpha-A-H segmentindeki dosya). Sadece bu segmentteki değişen URL’leri ekleyin ve/veya child sitemap’i yeniden yazın. Bu, lastmod doğruluğunu ve güncel keşfi iyileştirir; fakat uygulama karmaşıklığı artar.

İyi hibrit strateji: Trafiği yüksek segmentleri daha sık incremental güncelle, geri kalan segmentleri günlük batch ile yenileyin. Böylece hem maliyet hem discovery dengelenir.

Önbellekleme/CDN ve performans: sitemap üretim yükü, crawl bütçesi

Sitemap dosyalarını üretirken veritabanı sorguları ağırsa sistem çökmez ama performans dalgalanabilir. Bu yüzden üretim pipeline’ında “sadece değişen aralıkları” yeniden sorgulamak kritik olur. Oda id aralığı segmentasyonu kullandıysanız incremental ile bunu yapmak daha kolaydır.

CDN ve cache konusunda dikkatli olun: Sitemap index dosyası cache’de kalırsa yeni child sitemap URL’leri hızlı şekilde yayılmayabilir. Öte yandan cache’siz bırakmak origin’e gereksiz yük bindirebilir. Bu denge için index ve child dosyalarına ayrı cache TTL kuralı ve kontrollü invalidation uygulayın.

Bir diğer önemli konu crawl bütçesidir. Yanlış canonical veya parametreli URL’leri sitemap’e koyarsanız Google “değerli keşif” yerine “varyant keşfi” yapmaya yönelebilir. Bu yüzden sitemap’e girecek URL’leri mümkün olduğunca temiz tutun.

robots.txt ile eşleşme: locate/Allow-Disallow uyumu, wildcard riskleri

robots.txt, sitemap URL’lerini “gizlemek” için değil; taramayı yönlendirmek için kullanılır. Sitemap’e koyduğunuz URL’ler robots.txt ile engellenmişse Google erişemeyebilir. Bu durumda Search Console’da “tarama engellendi” veya “okundu ama işlenmedi” gibi durumlar görünür.

Wildcards konusunda özellikle dikkat edin. Disallow: /o/* gibi bir kural yanlışlıkla oda endpoint’inizi kapsarsa tüm child sitemap içeriğiniz fiilen etkisiz kalır. Aynı şekilde Allow ve Disallow öncelik kurallarını da test edin.

Özetle: Index sitemap tasarımı robots.txt kural setinizle uyumlu olmalı; aksi halde keşif zinciri kırılır.

Canonical/parametre uyumu: aynı oda için parametre varyantlarında canonical politikası

Chat dinamik URL yapısında aynı oda, farklı oturum/hash/cihaz parametreleriyle yeniden üretilebilir. Eğer sitemap’te bu varyantları çoğaltırsanız indeks kalitesi düşer. Yapmanız gereken: Her oda için tek bir kanonik URL belirlemek ve sitemap’te yalnızca o URL’i listelemek.

Canonical politikası tipik olarak “oda ID aynıysa canonical aynı olmalı” prensibine dayanır. Kullanıcıya özel parametreleri (ör. ziyaretçi session) canonical içine dahil etmeyin; canonical tekil kalsın.

Bu konu doğrudan canonical otomatik üretim hatalarıyla da ilişkilidir. Otomatik canonical üretiminde hash/oturum parametrelerinin yanlış işlendiğinden şüpheleniyorsanız şu rehber pratik olabilir: Chat Sitelerinde Canonical Otomatik Üretim Hataları: Hash ve Oturum Parametrelerini Doğru Ele Alma.

Özel durumlar: kapatılan/taşınan odalar, 404/410, remove vs keep

Bir oda kapanırsa iki şeyi birlikte yönetmelisiniz: (1) HTTP durum kodu davranışı ve (2) sitemap içeriğinin temizliği. Sadece birini yapmak eksik kalır.

Taşınma/yeniden adlandırma varsa: eski URL için 301/308 redirect uygulayın ve yeni canonical URL’yi sitemap’te tutun. Önemli olan, kullanıcıyı ve botu doğru hedefe yönlendiren tek bir kalıcı akış oluşturmak.

Kalıcı kapanma varsa: mümkünse 410 (Gone) ile kalıcı sinyali güçlendirin. Alternatif olarak 404 kullanabilirsiniz; ancak 410 genellikle “artık geri gelmeyecek” mesajını daha net iletir.

Örnek senaryo (410 ile yönetim) Oda: /o/oda-eskisi-123 kalıcı kapandı. - Uygulama 410 döndürür. - child sitemap segmentinden ilgili URL kaldırılır (veya bir sonraki üretimde kaldırılır). Bu sayede arama motoru hem taramaya devam etmeyi azaltır hem de eski URL’nin geri dönüş sinyalini almaz.

Google Search Console kontrol adımları: URL’leri gönderme, test etme, hatalar

Kurulumdan sonra doğrulama “tek seferlik” değildir. Search Console’da sitemap index’inizi veya child sitemap’leri gönderin ve raporlardaki işlenme durumlarını takip edin. Özellikle “okundu ama şu nedenle işlenmedi” türü hatalar kritik.

Ardından URL Inspection ile örnek bir oda URL’sini inceleyin: Google canonical’ı doğru görüyor mu, sayfa erişilebilir mi, robot kuralları/redirect zinciri temiz mi? Bu adımlar segmentasyon hatasını daha erken yakalamanıza yardım eder.

Ek olarak, site içi linklemeyi de hesaba katın. Oda sayfaları için kategori/etiket sayfalarına ve ilgili oda gruplarına doğru iç bağlantı kurmak keşif yolunu güçlendirir. Bu hiyerarşi için: oda–kategori–etiket iç linkleme hiyerarşisi rehberi yol gösterir.

Yaygın hatalar

Oda bazlı index sitemap kurulumlarında en sık karşılaşılan sorunlar şunlardır. Bu hatalar genellikle “sitemap var ama işe yaramıyor” hissi yaratır.

• Parametreli varyantları sitemap’e koymak: Oturum/hash/query ile aynı odanın farklı URL’leri çoğalır; indeks karışır.
• Child sitemap ile robots.txt çelişkisi: Index doğru görünür ama Google tarayamaz; Search Console’da işlenmedi hataları ortaya çıkar.
• lastmod’u anlamsız güncellemek: Her üretimde aynı değeri basmak veya her mesajda lastmod basmak güvenilirliği düşürür.
• Yanlış segmentasyon eşlemesi: Bir oda zaman içinde farklı child sitemap’lere düşmeye başlarsa izlenebilirlik ve canonical uyumu bozulur.
• Kapalı odaları yalnızca sitemap’ten kaldırmak: HTTP sinyaliyle desteklenmezse botlar eski URL’ye tekrar düşebilir.

Nasıl kontrol edilir? Adım adım doğrulama kontrol listesi

Yayın öncesi ve sonrası doğrulama için şu kontrol listesi oldukça işe yarar. En az 3 adımı mutlaka uygulayın:

1. Index sitemap erişilebilirlik testi: Index sitemap URL’inizi açın; 200 dönüyor mu? XML parse hatası var mı? CDN kaynaklı 403/404 var mı?
2. Child sitemap parse testi: Birkaç child sitemap URL’sini rastgele seçip URL sayısını kontrol edin. Limit aşımı veya eksik URL üretimi var mı?
3. robots.txt uyum testi: Bir oda URL’sini hedef alıp taramaya izin veriliyor mu doğrulayın. Wildcard kural etkilerini kontrol edin.
4. Canonical doğrulama: Aynı oda için parametreli varyantları deneyin; canonical tek URL’e mi indirgeniyor?
5. Log/alert kurulumu: XML üretim hataları, 404/410 oranları ve sitemap gönderim durumları için metrik/alert tanımlayın.

Sitemap güncelleme sıklığı (lastmod) nasıl belirlenmeli?

Chat odalarında içerik akışı çok değişken; lastmod’u “her mesaj” seviyesinde güncellemek çoğu zaman gereksiz gürültü oluşturur. Bunun yerine lastmod’u “arama niyeti açısından anlamlı değişimler” için kullanın.

Pratikte iki yaklaşım öne çıkar: (1) olay tabanlı lastmod: oda açıldı, oda kapanmış oldu, odanın ana sayfası (başlık/slug/kalıcı içeriği) değişti gibi olaylarda güncelleyin. (2) pencere tabanlı lastmod: trafiği yüksek segmentlerde ör. günde birkaç kez; düşük segmentlerde günde 1 veya 2 gibi.

Böylece Search Console’da lastmod sinyali daha güvenilir kalır ve gereksiz crawl israfı azalır.

Sürümleme ve izleme planı: loglama, hata metrikleri, düzenli sağlık kontrolü

Index sitemap mimarisini canlıya aldıktan sonra “bir daha düşünmeyiz” demeyin. Segmentasyon şeması zamanla değişir (oda türleri eklenir, eşleştirme kuralı iyileştirilir, URL canonical politikası güncellenir). Bu nedenle sitemap üretim pipeline’ını versiyonlayın.

İzleme için şunları loglayın: sitemap üretim süresi, child başına URL sayısı, XML validation sonuçları, son üretim tarihi, 404/410 dağılımları, Search Console’da sitemap error yüzdeleri ve “işlenmedi” sebepleri.

Düzenli sağlık kontrolü olarak haftada bir (veya kritik büyüme döneminde daha sık) şu adımları uygulayın: index sitemap’i çağırın, birkaç child parse edin, rastgele bir oda URL’sinin canonical’ini ve robots uyumunu kontrol edin, ardından GSC raporlarındaki değişimleri karşılaştırın.

SSS

Index sitemap kaç child sitemap içermelidir, pratik bir limit var mı? Mutlak bir sayıdan çok “yönetilebilirlik + parse edilebilirlik + child başına URL limitleri” önem kazanır. Oda sayınız hızla artıyorsa 20–100 aralığında child sitemap görmek yaygın bir durumdur. Kritik olan, child başına URL sayısının limitleri aşmaması ve segmentasyonun dengesiz şişme üretmemesidir.

Oda sayısı hızla artıyorsa segmentasyonu nasıl otomatikleştirmeliyim? Oda id aralığı veya hash mod tabanlı segmentasyon otomasyona uygundur. Ek olarak “URL sayısı eşiği” kuralı koyun: child sitemap 40.000 URL bandına yaklaşınca yeni alt segment açın. Böylece limit aşımı riski düşer.

Sitemap’te hangi URL’leri dışarıda bırakmalıyım (parametreli, kullanıcıya özel, spam odalar)? Kullanıcıya özel sayfalar, kişiselleştirilen parametreleri olan varyantlar, düşük değerli/spam odalar sitemap dışında tutulmalıdır. Ayrıca aynı oda için canonical tek URL olmalı; canonical olmayan varyantları sitemap’e eklemekten kaçının.

Sitemap güncelleme sıklığı (lastmod) nasıl belirlenmeli? lastmod’u her içerik değişimine değil, arama niyeti/ana sayfa doğruluğu açısından anlamlı değişimlere bağlayın. Trafiği yüksek segmentlerde daha sık, düşük segmentlerde daha seyrek güncelleyin.

Bir oda silindiğinde sitemap’ten kaldırmak mı yoksa 410/404 ile yönetmek mi daha doğru? En doğru yaklaşım ikisini birlikte uygulamaktır: HTTP tarafında doğru kalıcı sinyali verin (tercihen 410), ardından sonraki sitemap üretiminde child sitemap’ten çıkarın. Böylece hem tarama hem keşif davranışı uyumlu olur.

Sitemap index dosyası nerede barındırılmalı ve erişilebilirlik (cache, 403 vb.) nasıl yönetilmeli? Index dosyası HTTPS ile erişilen, 200 döndüren ve yanlış cache yüzünden 403/404 üretmeyen stabil bir endpoint’te olmalıdır. CDN kullanıyorsanız index sitemap için kısa/kontrollü TTL ve invalidation planı kurun. En azından yayın sonrası erişilebilirlik testini otomasyona alın.

Son kontrol listesi: aksiyon planınız

Planlama aşamasında “çalışır görünüyor” demek yetmez. Aşağıdaki kriterleri sağladığınızdan emin olun:

• Index sitemap ve child sitemap’ler 200 ile erişiliyor, XML parse hatası yok.
• Child sitemap’lerde URL limitleri aşılmıyor ve segmentasyon dengeli.
• robots.txt kural setiniz child sitemap URL’lerini engellemiyor.
• Her oda için canonical tek URL ve sitemap’te yalnızca kanonik URL var.
• Kapanan odalar için HTTP sinyali (410/404) var ve sitemap temizliği düzenli yapılıyor.
• Search Console’da sitemap gönderimleri tamam ve hatalar izleniyor.

İsterseniz bir sonraki adım olarak size özel bir “sitemap planlama şablonu + kontrol listesi” çıkarabilirim ya da teknik inceleme (audit) talep edebilirsiniz. Özellikle Search Console raporlarını (indexing ve tarama engelleri) segmentasyon kararlarınızla birlikte değerlendiririz.