Sitemap lastmod Nedir, Nasıl Doğru Kullanılır?

lastmod, sitemap'inizdeki her URL için "bu sayfayı en son ne zaman gerçekten değiştirdim" bilgisini veren alandır. Google bunu tarama önceliği için kullanır ama koşulsuz güvenmez: değerleriniz sürekli yanlış çıkarsa sinyali tamamen yok saymaya başlar.

Sitemap denetimi yaparken çoğu kişi URL sayısına, hreflang etiketlerine, XML geçerliliğine bakar. Bizim sitemap'imiz bu üç testin hepsinden geçiyordu: 108 URL, her birinde hreflang üçlüsü, geçerli XML.

Sonra lastmod değerlerine baktık:

<lastmod>2026-08-22T16:01:16.477Z</lastmod>
<lastmod>2026-08-22T16:01:16.477Z</lastmod>
<lastmod>2026-08-22T16:01:16.477Z</lastmod>

102 sayfa, hepsi aynı zaman damgası — ve o damga isteği attığımız an. Sitemap'i beş dakika sonra tekrar çektiğimizde hepsi beş dakika ilerlemişti.

Yani sitemap her sorulduğunda Google'a "bu 102 sayfanın hepsi az önce değişti" diyordu.

Neden bu bir sorun

lastmod, Google'a "bu sayfayı en son ne zaman gerçekten değiştirdim" bilgisini verir. Google bunu tarama önceliğini belirlemek için kullanır: değişmiş sayfalar önce, değişmemişler sonra.

Google bu alana koşulsuz güvenmez. Doğruluğunu kendi kayıtlarıyla karşılaştırır. Bir site sürekli "her şey az önce değişti" diyor ama Google taradığında içerik aynı çıkıyorsa, Google o siteden gelen lastmod sinyalini tamamen yok saymaya başlar.

Sonucu şudur: gerçekten önemli bir güncelleme yaptığınızda — fiyatları değiştirdiniz, bir ürün sayfasını baştan yazdınız — Google artık sizin lastmod'unuza bakmaz. O sayfayı ne zaman tekrar tarayacağına kendi başına karar verir ve bu haftalar sürebilir.

Google Search Central belgeleri bu konuda açık: lastmod yalnızca tutarlı ve doğru olduğunda kullanılır.

Sinyalin geri kazanılması da anında olmuyor. Google'ın güveni kaybetmesi hızlı, geri vermesi yavaş — çünkü geri vermek için birkaç tarama turu boyunca "söylediğin tarih ile bulduğum içerik uyuşuyor" gözlemi yapması gerekiyor. Yani bugün düzeltseniz bile etkisini haftalar sonra görürsünüz. Bu, işi ertelemek için değil, bugün başlamak için bir sebep.

Neyi "değişiklik" saymalı

Burada ince bir ayrım var ve çoğu site yanlış tarafa düşüyor.

lastmod, kayda değer içerik değişikliğini göstermelidir. Google'ın belgeleri "önemli olmayan değişiklikler" için tarihin güncellenmemesini söylüyor. Pratikte ayrım şöyle:

Değişiklik	lastmod güncellenmeli mi
Yazıya yeni bölüm eklendi	Evet
Fiyat tablosu değişti	Evet
Başlık ya da meta açıklama değişti	Evet
Yazım hatası düzeltildi	Hayır
Footer'daki telefon numarası değişti (tüm sayfalarda)	Hayır
Sayfadaki "ilgili yazılar" bloğu yenilendi	Hayır
Çerez bandının metni değişti	Hayır

Son üç madde önemli: bunlar tüm sayfaları aynı anda etkiler. Şablona dokunan her değişiklikte bütün sitenin lastmod'unu ilerletirseniz, en başta anlattığımız duruma geri dönersiniz — Google her taramada "her şey değişmiş ama hiçbir şey değişmemiş" görür.

Veritabanı kullanıyorsanız bu ayrım çoğu zaman kendiliğinden doğru çalışır: updatedAt, kaydın kendisi değiştiğinde ilerler, şablonu değiştirdiğinizde ilerlemez. Sorun statik sayfalarda başlar.

Doğru biçim: ISO 8601

lastmod W3C Datetime biçimini ister. Kabul edilen üç yazım var:

<lastmod>2026-08-22</lastmod>
<lastmod>2026-08-22T16:01:16+03:00</lastmod>
<lastmod>2026-08-22T13:01:16Z</lastmod>

Üçü de geçerli. Saat bilgisi vermek zorunda değilsiniz; günde birkaç kez içerik güncellemiyorsanız YYYY-MM-DD yeterli ve daha az yanlış yapılır.

Sık görülen üç biçim hatası:

Yerel tarih biçimi. 22.08.2026 ya da 08/22/2026 geçersizdir. XML doğrulayıcı bunu yakalar ama sitemap'i hiç doğrulamadıysanız fark etmezsiniz.

Saat dilimi eksik. 2026-08-22T16:01:16 — sonunda Z ya da +03:00 yoksa hangi saat dilimi olduğu belirsiz kalır. Next.js Date nesnesini otomatik olarak Z ile (UTC) yazdığı için bu sorunu genelde yaşamazsınız, ama elle XML üretiyorsanız yaşarsınız.

Gelecek tarih. İleri bir tarih yazmak "beni daha sık tara" demek değildir; sadece verinizin güvenilmez olduğunu gösterir. Zamanlanmış yayın kullanıyorsanız yayın tarihinin sunucu saatiyle tutarlı olduğundan emin olun.

Sebep: new Date() her istekte "şimdi" döner

Next.js'te app/sitemap.ts yazarken en doğal görünen şey budur:

const staticUrls = staticPages.map(({ path }) => ({
  url: `${baseUrl}${path}`,
  lastModified: new Date(),   // ← sorun burada
  changeFrequency: "monthly",
  priority: 0.8,
}));

new Date() çağrıldığı anın zamanını verir. Sitemap statik olarak üretiliyorsa bu build zamanı olur — kabul edilebilir, çünkü en azından iki build arasında sabit kalır. Ama route force-dynamic ise her istekte yeniden çalışır ve her seferinde "şimdi" döner.

Bizim sitemap'imizin başında tam olarak bu satır var:

export const dynamic = 'force-dynamic';

Blog yazılarını ve projeleri veritabanından çektiğimiz için sitemap'in dinamik olması gerekiyordu. Ama dinamik olması, içindeki new Date() çağrılarının da her istekte tazelenmesi demekti.

Buradaki asıl tuzak şu: sorun force-dynamic değil, new Date(). Sitemap'i statiğe çevirerek "çözerseniz" bu sefer yeni blog yazılarınız sitemap'e günlerce girmez. Doğru çözüm dinamik kalmak ve tarihi doğru yerden almaktır.

Doğrusu

İçeriği veritabanında duran sayfalar için gerçek tarihi kullanın:

const posts = await prisma.post.findMany({
  where: { published: true, isNoindex: false },
  select: { slug: true, updatedAt: true, language: true },
});

const postUrls = posts.map((post) => ({
  url: `${baseUrl}/${post.language}/blog/${post.slug}`,
  lastModified: post.updatedAt,   // gerçek değişiklik tarihi
  changeFrequency: "weekly" as const,
  priority: 0.75,
}));

where koşulundaki isNoindex: false gözden kaçmasın. noindex işaretli bir sayfayı sitemap'e koymak kendi kendine çelişen bir sinyaldir: "bunu indeksleme" derken "bunu indekslemek için taramanı istiyorum" diyorsunuz.

Statik sayfalar (hakkımızda, hizmetler, iletişim) için veritabanında tarih yoktur. Onlar için elle tutulan bir sabit kullanın:

/**
 * Statik sayfaların son değişiklik tarihi.
 * BU SAYFALARIN İÇERİĞİNİ DEĞİŞTİRDİĞİNİZDE BU TARİHİ DE GÜNCELLEYİN.
 */
const STATIK_SAYFA_TARIHI = new Date("2026-08-22T00:00:00.000Z");

Elle güncellemek ilkel görünebilir ama dürüst. Sayfayı gerçekten değiştirdiğinizde tarihi de değiştirirsiniz; değiştirmediğinizde Google boşuna taramaz.

Yorum satırını büyük harfle yazmamızın sebebi var: bu sabit, kodun içinde unutulmaya en müsait satırlardan biri. Altı ay sonra hizmetler sayfasını baştan yazan kişi (muhtemelen siz) bu dosyaya bakmayacak.

Dört seçeneğin karşılaştırması

Statik sayfaların tarihini nereden alacağınız bir tercih meselesi. Dördünü de denedik ya da değerlendirdik:

Yöntem	Doğruluk	Bakım	Üretimde çalışır mı
new Date()	Yanlış — her istekte değişir	Yok	Çalışır ama zararlı
Build zamanı (statik sitemap)	Kısmen — build başına doğru	Yok	Evet
Elle tutulan sabit	Doğru, siz güncellerseniz	Elle	Evet
Git commit tarihi	Çok hassas — yazım hatası bile sayar	Yok	Genelde hayır

Küçük ve orta ölçekli siteler için elle tutulan sabit yeterli ve daha öngörülebilir. Yüzlerce statik sayfası olan bir sitede ise sayfa başına tarih tutan küçük bir veri dosyası ({ "/hizmetler": "2026-08-22", ... }) daha iyi ölçekleniyor.

Alternatif: git geçmişinden okumak

Build sırasında dosyanın son commit tarihini alabilirsiniz:

git log -1 --format=%cI -- src/app/hakkimizda/page.tsx

Bu daha otomatik ama iki tuzağı var. Birincisi, bir yazım hatası düzeltmesi de "değişiklik" sayılır ve gereksiz tarama sinyali verir — yukarıdaki "neyi değişiklik saymalı" tablosunun tam tersini yapar. İkincisi, çoğu dağıtım ortamı .git klasörünü taşımaz.

Bizim dağıtımımızda da taşımıyor: sunucuya giden şey rsync ile kopyalanan derlenmiş çıktı, depo değil. Aynı sorun Vercel dışındaki çoğu kurulumda geçerlidir. Bu yöntemi kullanacaksanız tarihleri build sırasında okuyup bir JSON'a yazın, çalışma zamanında git çağırmayın.

Kendi sitenizde kontrol

Sitemap'i iki kez çekip karşılaştırın:

curl -s https://siteniz.com/sitemap.xml | grep -o '<lastmod>[^<]*' | head -3
sleep 10
curl -s https://siteniz.com/sitemap.xml | grep -o '<lastmod>[^<]*' | head -3

İki çıktı farklıysa sorun sizde de var.

Kaç farklı tarih olduğuna da bakın:

curl -s https://siteniz.com/sitemap.xml \
  | grep -o '<lastmod>[^<]*' | sed 's/<lastmod>//' | cut -c1-10 | sort | uniq -c

Düzelttikten sonra bizim çıktımız şöyle oldu:

   6 2026-08-17     ← blog yazıları, gerçek yazım tarihleri
 102 2026-08-22     ← statik sayfalar, elle konan sabit

Anlamlı bir dağılım. Öncesinde tek bir satır vardı ve o satır her sorguda değişiyordu.

Üçüncü bir kontrol daha yapın — lastmod diyen sayfa gerçekten değişmiş mi:

# Sitemap'in en yeni tarihli URL'sini bul
URL=$(curl -s https://siteniz.com/sitemap.xml \
      | tr '<' '\n' | grep -A0 '^loc>' | sed 's/^loc>//' | head -1)

# O sayfayı çekip Last-Modified başlığına bak
curl -sI "$URL" | grep -i "last-modified"

Sunucunuz Last-Modified başlığı üretiyorsa (Next.js dinamik sayfalarda genelde üretmez) iki değerin birbirine yakın olması beklenir. Uyuşmuyorsa hangisinin doğru olduğunu bulun; ikisi de yanlışsa Google zaten ikisini de dikkate almayı bırakır.

Search Console tarafında ne görürsünüz

Sitemap raporunda her sitemap için bir "son okunma" tarihi vardır. Bu, Google'ın dosyayı en son ne zaman indirdiğini gösterir — sayfalarınızı ne zaman taradığını değil. İkisi karıştırılıyor.

lastmod düzeltmesinin etkisini görmek için bakılacak yer sitemap raporu değil, Sayfalar raporundaki tarama tarihleri ve tek tek URL denetimi ekranındaki "Son tarama" satırı. Bir sayfayı güncelledikten sonra o satırdaki tarihin ne kadar sürede ilerlediğine bakın; düzeltme işe yaradıysa bu süre kısalır.

Sabırlı olun: birkaç yüz sayfalık bir sitede fark birkaç hafta içinde görünür, daha büyüklerinde daha geç.

changefreq ve priority ne oldu

Bu iki alanı da sitemap'inizde göreceksiniz — bizimkinde de var. Dürüst cevap şu: Google bunları kullanmadığını açıkça söyledi.

O halde neden duruyorlar? Çünkü zararsızlar ve Google dışındaki bazı araçlar (site içi tarayıcılar, bazı arama motorları) okuyor. Ama şunu bilerek durun: priority: 1.0 yazmak sayfanızı öne çıkarmaz, changefreq: daily yazmak Google'ı her gün getirmez. Tarama sıklığını belirleyen şey sitenizin genel otoritesi, sayfanın önemi ve lastmod sinyalinin güvenilirliğidir.

Yani bu üç alandan yalnızca biri gerçekten iş görüyor ve o da doğru doldurulduğunda.

Büyük siteler: sitemap dosyasının sınırları

Tek bir sitemap dosyası en fazla 50.000 URL ve 50 MB (sıkıştırılmamış) içerebilir. Bunu aşarsanız sitemap index kullanmanız gerekir:

<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://siteniz.com/sitemap/blog.xml</loc>
    <lastmod>2026-08-22</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://siteniz.com/sitemap/urunler.xml</loc>
    <lastmod>2026-08-20</lastmod>
  </sitemap>
</sitemapindex>

Dikkat: index dosyasındaki lastmod, o alt sitemap içindeki en yeni lastmod değeri olmalıdır. Buraya da "şimdi" yazarsanız aynı güven sorununu bir üst katmanda tekrarlarsınız.

Next.js tarafında bu bölme işi generateSitemaps ile yapılıyor; API'nin bu sürümdeki tam imzası için node_modules/next/dist/docs/ altındaki generate-sitemaps belgesine bakın — sürüm arası değişebiliyor.

Sık yapılan beş hata

1. noindex sayfaları sitemap'te bırakmak. Çelişkili sinyal. Sorguya isNoindex: false koşulunu ekleyin.

2. Yönlendirilen URL'leri sitemap'te bırakmak. Slug değiştirdiğinizde eski adres 301 verir ama sitemap'te durmaya devam eder. Sitemap yalnızca 200 dönen kanonik adresleri içermeli.

3. Sitemap'te olan URL'nin canonical'ının başka sayfayı göstermesi. Bu da çelişki. Aynı sayfada iki şema olması gibi, Google iki sinyal çeliştiğinde ikisini birden yok sayabiliyor.

4. Sitemap'i CDN'in bir yıl önbelleklemesine izin vermek. Bu bizim başımıza geldi: sitemap güncelleniyordu ama dışarıdan bakınca eski hali görünüyordu. Sebebini ve çözümünü CDN önbelleği yazısında ayrıntılı anlattık.

5. Çok dilli sitede aynı içeriği iki dil altında listelemek. Bizde 18 yazı için 36 URL üretiliyordu; yarısı yanlış dilde içerik sunuyordu. Çözüm, içerik URL'lerini yalnızca kendi dilinde üretmek ve hreflang alternate'ini sadece gerçek çeviri varsa yayınlamak. Bu, ChatGPT sitenizi neden okumuyor listesindeki üçüncü maddeyle aynı sorunun sitemap tarafındaki yüzü.

Yayın öncesi kontrol listesi

• Sitemap'i on saniye arayla iki kez çektim, lastmod değerleri değişmiyor
• Tarihler ISO 8601 biçiminde ve saat dilimi belirtilmiş
• Hiçbir tarih gelecekte değil
• Veritabanı içerikleri gerçek updatedAt değerini kullanıyor
• Statik sayfaların tarihi elle tutulan bir sabitten geliyor
• noindex ve yönlendirilen URL'ler sitemap'te yok
• Her URL'nin canonical'ı kendini gösteriyor
• Sitemap CDN'de uzun süre önbelleklenmiyor
• Search Console sitemap raporunda hata yok

Sitemap'i Google'a nasıl bildirirsiniz

Üç yol var ve üçü de aynı işi yapmıyor.

robots.txt içinde bildirmek. En temel yöntem, tek satır:

Sitemap: https://siteniz.com/sitemap.xml

Bu satır bütün tarayıcılar için geçerli — sadece Google değil, Bing de, yapay zeka botları da robots.txt okur. Sitemap'inizin adresini burada bildirmemek, dosyayı hazırlayıp kimseye söylememek demek.

Search Console'a göndermek. Sitemap raporundan bir kez eklersiniz, Google düzenli olarak tekrar okur. Faydası dosyanın kendisi değil, raporu: kaç URL okundu, kaçında hata var, en son ne zaman okundu.

IndexNow ile anlık bildirim. Bing, Yandex ve bazı diğer motorlar bu protokolü destekliyor: bir sayfayı güncellediğinizde tek bir HTTP isteğiyle "şu URL değişti" diyorsunuz.

curl -s "https://api.indexnow.org/indexnow?url=https://siteniz.com/blog/yazi&key=ANAHTARINIZ"

Google IndexNow'ı desteklemiyor; oradaki karşılığı sitemap ve lastmod. Yani lastmod'u doğru tutmak, Google tarafında elinizdeki tek hızlandırma aracı.

Üçünü birden yapmak mantıklı ama sıralama şu: önce lastmod doğru olsun, sonra bildirim. Yanlış tarihli bir sitemap'i daha sık bildirmek yalnızca yanlış bilgiyi daha hızlı yaymaktır.

Bunu düzeltmek sıralamanızı yükseltir mi

Hayır — en azından doğrudan değil. lastmod bir sıralama faktörü değil, tarama bütçesi sinyalidir.

Faydası şurada: bir sayfayı gerçekten iyileştirdiğinizde Google onu daha çabuk yeniden tarar, dolayısıyla iyileştirmenin etkisi daha erken görünür. Yüzlerce sayfalı sitelerde bu fark haftalara denk gelir.

Aynı mantık yapay zeka motorları için de geçerli. GPTBot ya da PerplexityBot sitenize uğradığında hangi sayfaların tazelendiğini lastmod'dan okuyor olabilir; keşif katmanının nasıl kurulduğunu GEO rehberinde anlattık.

Küçük bir ayar, ama yanlış olduğunda sessizce yanlış çalışır. Sitemap'iniz teknik olarak kusursuz görünürken Google'a güvenilmez bir sinyal veriyor olabilir.

Bu tür ayarların tek tek küçük, toplamda belirleyici olması teknik SEO'nun doğasında var. Bir sitenin maliyetini konuşurken bu kalemlerin nereye düştüğünü web sitesi fiyatları yazısında ayırdık; mevcut sitenizde bu denetimi bizim yapmamızı isterseniz hizmetler sayfasında kapsamı bulabilirsiniz.