# Sitemap lastmod Nedir, Nasıl Doğru Kullanılır? > 108 URL, geçerli XML, tam hreflang — sitemap'imiz her testten geçiyordu. Sonra lastmod değerlerine baktık: hepsi isteği attığımız anın zaman damgasıydı. - Kanonik URL: https://algoritmaajans.com/tr/blog/sitemap-lastmod-nedir-nasil-kullanilir - Dil: tr - Kategori: Teknoloji - Yayın: 2026-08-27 - Güncelleme: 2026-08-29 - Yayıncı: Algoritma Ajans --- **`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: ``` 2026-08-22T16:01:16.477Z 2026-08-22T16:01:16.477Z 2026-08-22T16:01:16.477Z ``` 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: ```xml 2026-08-22 2026-08-22T16:01:16+03:00 2026-08-22T13:01:16Z ``` Üçü 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: ```ts 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: ```ts 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. ![Üst üste yığılmış sayfaların her birine basılmış aynı tarih damgası — sitemap'te her URL için aynı lastmod değerinin yazılması](/images/blog/sitemap-lastmod-inline-1.jpg) ## Doğrusu İçeriği veritabanında duran sayfalar için gerçek tarihi kullanın: ```ts 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: ```ts /** * 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: ```bash 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: ```bash curl -s https://siteniz.com/sitemap.xml | grep -o '[^<]*' | head -3 sleep 10 curl -s https://siteniz.com/sitemap.xml | grep -o '[^<]*' | head -3 ``` İki çıktı farklıysa sorun sizde de var. Kaç farklı tarih olduğuna da bakın: ```bash curl -s https://siteniz.com/sitemap.xml \ | grep -o '[^<]*' | sed 's///' | 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: ```bash # 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: ```xml https://siteniz.com/sitemap/blog.xml 2026-08-22 https://siteniz.com/sitemap/urunler.xml 2026-08-20 ``` 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](/tr/blog/yapisal-veri-hatasi-ayni-sayfada-iki-sema), 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](/tr/blog/cdn-onbellegi-nasil-temizlenir) 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](/tr/blog/chatgpt-sitenizi-neden-okumuyor-kontrol-listesi) üçü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. ```bash 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](/tr/blog/yapay-zeka-aramalarinda-gorunurluk-geo-rehberi-2026) 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](/tr/blog/web-sitesi-fiyatlari-neye-gore-degisir) ayırdık; mevcut sitenizde bu denetimi bizim yapmamızı isterseniz [hizmetler sayfasında](/tr/hizmetler) kapsamı bulabilirsiniz.