Sitemap lastmod yanlış kurulunca ne oluyor

Sitemap’teki lastmod etiketi yanlış kurulunca üç farklı biçimde bozulabilir: alan hiç üretilmez, tutarsız biçimde yanlış üretilir ya da her derlemede bugüne çekilerek kasıtlı olarak sahteleştirilir. Google bu üçüne aynı şekilde davranmıyor; eksik alanı nötr bir boşluk sayıyor, tutarsız veya sahte bir alanı ise sitenin tüm lastmod sütununa güven kaybettiren bir sinyal olarak okuyabiliyor. Bu ayrımı Google’ın 2025-2026’da verdiği üç açıklama netleştiriyor: lastmod yalnızca sayfanın gerçek değişimiyle tutarlı ve doğrulanabilir olduğunda kullanılıyor, her sayfaya bugünün tarihini yazmak genellikle bozuk bir sitemap kurulumunun işareti sayılıyor ve kronik olarak yanlış bir lastmod hiç lastmod kullanmamaktan muhtemelen daha kötü bir durum. Kendi sitemizde de bu hatanın en sık görülen biçimi, hiç üretmeme, Ağustos 2026’daki bir iç denetimde ortaya çıktı: technoradical.com’un o anki 14 sayfasının tamamında sitemap lastmod’u eksikti. Çözüm statik sayfalar için elle güncellenen tek bir doğruluk kaynağından, blog yazıları için ise frontmatter’dan otomatik okuyan ayrı bir mekanizmadan geçti ve hâlâ canlıda çalışıyor. Pratikte yanlış lastmod dört kalıptan biriyle ortaya çıkıyor: eklentinin üretmemesi, dosya değişim tarihinin (mtime) kaynak alınması, toplu yeniden üretim damgası veya içerik değişmeden yapılan bir CMS kaydı; kendi sitenizdeki kurulumu beş adımlık bir kontrolle test edip framework’ünüzün lastmod’u gerçekten mi ürettiğini yoksa ürettiği izlenimi mi verdiğini ayırt edebilirsiniz.

Google sitemap’teki lastmod’u ne zaman kullanır, ne zaman yok sayar

Google, sitemap’teki lastmod değerini yalnızca sayfanın gerçek değişimiyle tutarlı ve doğrulanabilir biçimde doğru olduğunda kullanıyor; aksi halde alanı yok sayıyor. Google Search Central’ın sitemap kurma rehberi bu koşulu doğrudan yazıyor: lastmod değeri, sayfanın son değişikliğiyle karşılaştırılarak tutarlı ve doğrulanabilir biçimde doğruysa kullanılıyor. Doğrulama Google’ın kendi taramasıyla yapılıyor; sitemap’teki tarihe kör güvenilmiyor, sayfanın gerçekten o tarihte değişip değişmediği karşılaştırılıyor.

Aynı rehber “önemli güncelleme” tanımını da veriyor ve bu tanım sektörde en sık atlanan noktalardan biri. Ana içeriğin, yapılandırılmış verinin veya sayfadaki bağlantıların değişmesi genellikle önemli sayılıyor; telif hakkı tarihinin değişmesi önemli sayılmıyor. Bir sayfanın altındaki telif yılını güncellemek ya da küçük bir stil dokunuşu yapmak, lastmod’u bugüne çekmek için yeterli bir gerekçe değil.

Bu koşulun beslediği mekanizma tarama talebidir (crawl demand). Google’ın tarama bütçesi rehberine göre tarama talebi üç faktörden oluşuyor: algılanan envanter, popülerlik ve tazelik. Lastmod, Google’ın bir sayfayı yeniden taramasına öncelik verme kararını besleyen tazelik faktörüne doğrudan girdi sağlıyor. Aynı rehberin tarama verimliliği için verdiği sekiz maddelik öneri listesinde de site haritalarını güncel tutmak ve lastmod etiketini kullanmak ayrı bir madde olarak yer alıyor.

Lastmod’un hiç olmaması ile yanlış olması aynı riski mi taşır

Hayır. Google’a göre lastmod’un hiç olmaması nötr bir eksiklik; kronik olarak yanlış bir lastmod ise hiç lastmod kullanmamaktan daha kötü bir sinyal. Bu ayrımı Google’dan iki isim, iki ayrı açıklamayla doğruluyor.

Google’dan Gary Illyes, Temmuz 2026’da Bluesky’de bir geliştiricinin sorusuna yanıt verdi; soru şuydu: sitemap üretim kodundaki bir hata yüzünden lastmod tarihleri güvenilmez çıkıyorsa, hiç lastmod olmaması mı yoksa güvenilmez lastmod mu daha iyi. Illyes’e göre muhtemelen lastmod olmadan daha iyi durumda olunuyor, en azından birkaç bayt tasarruf ediliyor. Bu resmi bir dokümantasyon cümlesi değil, gayri resmi bir sosyal medya yanıtı; belirli bir site için garanti sayılmamalı ama Google’ın konuya yaklaşımını gösteriyor.

John Mueller de benzer bir gerekçeyi daha önce paylaşmıştı. Reddit’te bir tartışmada, sitemap’te her sayfaya bugünün tarihini yazan bir kurulumun genellikle bozuk bir sitemap üretici işareti sayıldığını, bunun hiçbir olumlu etkisi olmadığını ve gerçekten güncellenen sayfaları tespit etmeyi zorlaştırdığını yazdı. Bu açıklama da resmi bir Google dokümantasyon sayfası değil, gayri resmi bir forum yanıtı; “genellikle” ifadesiyle okunmalı, kesin bir kural gibi aktarılmamalı.

Ayrım şurada: eksik veri nötrdür, Google başka sinyallere (algılanan envanter, popülerlik) yöneliyor. Yanlış veri ise güven kaybettiriyor ve bu güvensizlik yalnızca hatalı URL’yle sınırlı kalmayabilir, sitenin lastmod sütununun tamamına yayılabilir.

Bir sitemap’te lastmod pratikte hangi dört kalıpla bozulur

Pratikte yanlış veya eksik lastmod dört kalıptan biriyle ortaya çıkıyor: eklenti hiç üretmiyor, dosya değişim tarihi kaynak alınıyor, toplu yeniden üretim aynı damgayı basıyor veya içerik değişmeden yapılan bir kayıt otomatik “güncellendi” yazıyor. Dört kalıp şöyle ayrışıyor.

Kalıp	Örnek	Neden yanıltıcı
Eklenti/framework hiç üretmiyor	Astro’nun @astrojs/sitemap eklentisi, elle tarih bağlanmazsa alanı boş bırakıyor	Google hiçbir sinyal alamıyor, alan tamamen eksik kalıyor
Dosya değişim tarihi (mtime) kaynak alınıyor	Küçük bir meta düzeltmesi dosyanın mtime’ını değiştiriyor	Google’ın “önemli güncelleme” tanımını karşılamıyor, yanlış sinyal üretiyor
Toplu build/regenerasyon aynı damgayı basıyor	webtures.com’da 1.243 URL’nin 627’si aynı ayın damgasını taşıyor	Damga içerik değişikliğini değil, site geneli yeniden üretimi yansıtıyor
CMS içerik değişmeden kaydediyor	Bir alanı dokunmadan kaydetmek otomatik “güncellendi” damgası basıyor	Editör hiçbir gövde metnini değiştirmediği halde sinyal üretiliyor

Birinci kalıp kendi sitemizin ilk hali. Astro’nun @astrojs/sitemap eklentisi sayfa içeriğinin değiştiğini kendiliğinden bilmiyor, bu yüzden ayrı bir tarih kaynağı bağlanmadığı sürece lastmod alanını hiç üretmiyor.

İkinci kalıp mtime’a güvenmenin doğal sonucu. Google’ın “önemli güncelleme” tanımı, ana içerik, yapılandırılmış veri veya link değişikliği önemli, telif tarihi değişikliği değil, tam bu noktada devreye giriyor; mtime bu ayrımı yapamıyor, dosyaya her dokunuşu “önemli” sayıyor.

Üçüncü ve dördüncü kalıp rakip sitemap taramasında doğrudan görüldü. webtures.com’da taranan 1.243 URL’nin 627’si, yaklaşık yarısı, aynı ayın lastmod damgasını taşıyordu; bu oran, damganın gerçek içerik değişikliğinden değil site geneli bir teknik yeniden üretimden geldiğini gösteriyor. Aynı taramada zeo.org ise alanı tamamen boş bırakıyordu, yani birinci kalıba düşen ayrı bir örnekti.

Kendi sitemizde bunu nasıl çözdük: tek doğruluk kaynağından üç hedefe

Kendi sitemizde bu dört kalıptan ilkini, eklentinin hiç üretmemesini, yaşadık; çözümü tek bir elle güncellenen doğruluk kaynağından üç ayrı yere besleyerek kurduk.

7 Ağustos 2026 tarihli bir iç denetim, technoradical.com’un o anki 14 sayfasının tamamında üç sinyalin de eksik olduğunu ortaya çıkardı: görünür “son güncelleme” tarihi yoktu, WebPage.dateModified yoktu, sitemap lastmod yoktu. Kök neden, eklentinin sayfa değişikliğini kendiliğinden bilmemesiydi: Astro’nun @astrojs/sitemap eklentisi bu bilgiyi ayrı bir kaynaktan almadığı sürece lastmod alanını hiç üretmiyordu.

Çözüm aynı gün kuruldu ve hâlâ canlıda çalışıyor. Statik sayfalar için guncelleme.mjs dosyası elle güncellenen tek doğruluk kaynağı oldu; bu dosya üç yere birden besleniyor: sayfada görünen “son güncelleme” satırına, WebPage.dateModified şemasına ve astro.config.mjs içindeki özel bir serialize() fonksiyonu üzerinden sitemap lastmod’una.

// astro.config.mjs - sitemap lastmod, tek dogruluk kaynagindan besleniyor
serialize(item) {
  const yol = new URL(item.url).pathname;
  const tarih = GUNCELLEME[yol] ?? BLOG_TARIHLERI[yol];
  if (tarih) item.lastmod = new Date(`${tarih}T00:00:00Z`).toISOString();
  return item;
}

Dosyanın mtime’ı kasıtlı olarak kullanılmıyor. guncelleme.mjs içindeki yorum bunu gerekçelendiriyor: dosya değişim tarihi her dokunuşta değişiyor, otomatik “bugün” tarihi ise güncellik konusunda yanıltıcı bir iddia üretiyor; bu yüzden tarih, içeriği değiştiren kişi tarafından elle güncelleniyor.

Blog yazıları için ayrı bir mekanizma kuruldu, çünkü günde bir yazı üreten bir üretim hattında kimse elle tarih girmeyecekti. astro.config.mjs içindeki blogTarihleri() fonksiyonu her yazının kendi başlık bloğundaki guncelleme alanını, yoksa tarih alanını, okuyup sitemap’e otomatik yazıyor. Taslak olarak işaretlenmiş yazılar zaten derlemeye girmediği için sitemap’te de yer almıyor.

Bu iki mekanizmanın üzerine bir denetim kontrolü eklendi: seo-kontrol.mjs, her derlemede sitemap’te <lastmod> etiketinin varlığını otomatik denetliyor ve etiket yoksa uyarı veriyor. Bu kayıt tek bir siteye ve tek bir olaya dayanıyor, daha geniş bir örneklem iddiası taşımıyor; ölçülen tek şey kurulumun var olduğu ve nasıl çalıştığı, Google tarafında ölçülebilir bir tarama sıklığı etkisi iddia edilmiyor.

Kendi sitenizde lastmod’un doğru kurulup kurulmadığını nasıl test edersiniz

Kendi sitenizdeki lastmod kurulumunu beş adımlık bir kontrolle test edebilirsiniz; ilk ikisi doğruluğu, sonraki ikisi tutarlılığı, son adım kaynağı ortaya çıkarır.

1. Sitemap’i açıp birkaç lastmod değerini örnekleyin. sitemap.xml dosyasını, veya bir sitemap index’iniz varsa alt sitemap’lerden birini, tarayıcıda açıp rastgele birkaç URL’nin lastmod değerine bakın.
2. Örneklenen URL’lerin gerçek içeriğini kontrol edin. Sayfanın gövde metni, yapılandırılmış verisi veya bağlantıları o tarihte gerçekten değişti mi diye sorun; yalnızca telif tarihi veya küçük bir stil değişikliği o tarihi açıklıyorsa kurulumunuz güvenilir değildir.
3. Aynı gün veya ay damgasını taşıyan URL oranını sayın. webtures.com örneğinde olduğu gibi URL’lerin yaklaşık yarısı aynı damgayı taşıyorsa bu, toplu regenerasyondan gelen bir işaret olabilir, gerçek içerik değişikliğini yansıtmayabilir.
4. Hiç lastmod alanı olmayan URL var mı kontrol edin. Bu nötr ama iyileştirilebilir bir eksikliktir; Illyes’in yanıtı hatırlanırsa bunu gidermek doğru kurulan bir lastmod’dan iyi değildir ama bozuk bir lastmod’dan daha güvenlidir.
5. Framework veya CMS’inizin lastmod kaynağını belirleyin. Kaynak dosya mtime’ı mı, bir içerik alanı mı, yoksa elle girilen bir tarih mi, öğrenin; ilk ikisi güvenilmez olma riski taşırken üçüncüsü, editoryal karar, en doğrulanabilir olanıdır.

Bu beş adımı elle tekrar tekrar yapmak yerine otomatik bir ilk tarama da mümkün. Robots.txt, site haritası, yönlendirme zinciri, kanonik etiket ve H1 yapısını tek taramada kontrol eden site haritası bildirimini de otuz saniyede tarayan site denetimi bu beş adımın çoğunu insan müdahalesi olmadan yapıyor.

Lastmod’u sahte güncellik sinyali gibi kullanmanın riski

Sitemap üretimini her derlemede tüm URL’lerin lastmod’unu bugüne çekecek şekilde kurmak riskli bir teknik. Risk: orta. Google bunu tespit edip sitenin tüm lastmod sütununu görmezden almaya başlayabilir; bu, gerçekten güncellenen sayfaların sinyalini de kaybetme riski taşır.

Gerekçe iki güncel açıklamaya dayanıyor. Mueller’a göre bu genellikle bozuk bir sitemap üretici kurulumunun işareti sayılıyor ve gerçek güncellemeleri tespit etmeyi zorlaştırıyor. Illyes’e göre de kronik olarak yanlış bir lastmod, hiç lastmod kullanmamaktan muhtemelen daha kötü bir durum. İkisi birlikte okununca risk büyüyor: sahte güncellik yalnızca boşa gitmiyor, gerçekten güncellenen sayfaların sinyalini de siliyor.

Bu risk raporlama tarafında da bir tuzak taşıyor. Bir ajansın sitemap’i her gün yeniden imzalamasını ölçülebilir bir iyileştirme gibi sunması, ölçülebilir bir iyileştirme gibi sunulan aktivitelerin genel bir örneği; sitemap’i her gün yeniden imzalamanın kendisi bir aktivite değil, gerçek etkisi sıfır, hatta Google’ın güven kaybı riskiyle negatif olabilir.

Lastmod doğru kurulunca ne değişir, ne değişmez

Doğru kurulan lastmod yalnızca tarama talebinin tazelik bileşenine katkı sağlıyor; bir sıralama faktörü değil ve yeniden tarama zamanlaması garanti etmiyor.

Değişen taraf net: crawl demand’ın tazelik bileşenine katkı ve Google’ın tarama verimliliği için verdiği sekiz maddelik listede yer alan bir hijyen pratiği.

Değişmeyen taraf da net: lastmod bir sıralama faktörü değil; hangi tarihte, hangi sıklıkta yeniden taranacağına dair bir garanti sağlamıyor.

İki ayrı sinyal burada sık karışıyor. Sitemap’te bulunmak, hangi URL’nin asıl (canonical) sayılacağı kararında yalnızca zayıf bir sinyal; Google’ın kendi duplike URL birleştirme rehberi 301 yönlendirmeyi ve rel=canonical etiketini güçlü sinyal sayarken sitemap’te listelenmeyi yalnızca zayıf bir sinyal olarak tanımlıyor. Lastmod ise tamamen ayrı bir sinyal: biri hangi URL’nin asıl sayılacağını, diğeri o URL’nin ne zaman yeniden taranacağını etkiliyor. Bu ayrımın en çok karıştığı yer, kanonik etiketin sessizce yanlış kurulması durumu; kanonik sinyali bozuk bir sayfada lastmod’u düzeltmek, canonicalization sorununu çözmüyor.

Lastmod’u düzeltmek hangi sitelerde öncelik olmamalı

Günde birkaç sayfası olan, nadiren güncellenen küçük bir sitede lastmod hassasiyeti öncelik taşımayabilir; önce eksikliğin giderilmesi, sonra tutarsızlığın düzeltilmesi, en son ince ayar gelir.

Bu öncelik sırasının gerekçesi keyfi değil, ayrı bir karara bağlı. Sitenin küçük mü büyük mü sayıldığını, tarama bütçesi gerçekten sorun olan sayfa sayısı eşiklerini belirleyen ayrı bir eşik kararı çiziyor. O eşiklerin altında kalan bir site için tarama önceliği zaten küçük bir kazanç taşıyor; lastmod ince ayarı da aynı kategoriye giriyor.

Yine de sıralama net: önce lastmod’un hiç olmaması, nötr ama iyileştirilebilir, giderilir; sonra tutarsızlık, Illyes’in işaret ettiği orta risk, giderilir; en son ince ayar, düşük getiri, yapılır.

Kendi sitemizin örneği bu küçüklüğü somutlaştırıyor: 49 URL’lik, günde bir yazı ekleyen bir sitede bile bu düzeltme bir günde kurulabilecek büyüklükte bir mühendislik işiydi, büyük bir proje değildi.

Sitemap lastmod’ta hangi tarih formatı kullanılmalı?

Sitemap protokolü lastmod için W3C Datetime biçimini istiyor; saat kısmı opsiyonel, yalın YYYY-MM-DD biçimi kabul ediliyor. Sitemaps.org’un resmi protokol sayfası iki örnek biçim gösteriyor: yalın tarih (2005-01-01) ve tam zaman damgalı ISO 8601 (2004-12-23T18:00:15+00:00). Google’ın kendi sitemap belgesi ayrı bir format şartı koymuyor, örneklerinde yalın tarih biçimini kullanıyor.

Framework’ler sitemap lastmod’unu otomatik üretir mi?

Çoğu sitemap eklentisi içerik değişikliğini kendiliğinden bilmiyor, bu yüzden lastmod’u varsayılan olarak hiç üretmiyor. Kendi sitemizin ilk hali tam olarak buydu: Astro’nun @astrojs/sitemap eklentisi ayrı bir tarih kaynağı bağlanmadığı sürece bu alanı boş bırakıyordu. Bu framework’e özgü bir kusur değil; içerik yönetim katmanı neyin anlamlı biçimde değiştiğini bilemiyor, geliştiricinin bunu ayrı bir kaynaktan, frontmatter alanı veya elle yazılan bir harita, söylemesi gerekiyor.