Bir sitenin sunucu logunda /_next/static/immutable/chunks/turbopack-02sl120el9-1r.js biçiminde URL'ler görmek rahatsız edici. Bunlar HTML üretmiyor, sayıları yüksek, ve ilk refleks onları kapatmak oluyor. Refleksin arkasındaki kaygı gerçek, hedefi yanlış.
Aşağıdaki bölümler önce /_next/ altında ne olduğunu, sonra engelin hangi mekanizmayı bozduğunu, sonra da kaybın hangi raporda ne zaman göründüğünü veriyor. Son iki bölüm, Next.js robots.txt dosyasına o satırı zaten yazmış olan okuyucu için.
/_next/ altında tek bir şey yok
Disallow: /_next/ tek satır, ama üç ayrı davranışı birden kapatıyor. Üçünün engelleme cevabı aynı değil, dolayısıyla tek satırla verilen karar üçünden en az ikisi için yanlış.
_next/static: build çıktısı ve dosya adındaki parmak izi
Burası derlenmiş JavaScript, CSS ve font dosyalarının durduğu yer. Next.js dokümantasyonuna göre framework bu dosyalara Cache-Control: public, max-age=31536000, immutable başlığını yazıyor ve başlık geçersiz kılınamıyor. Dosya adlarının içinde SHA hash'i var, içerik değiştiğinde ad da değişiyor.
Adın içindeki hash, dosyayı kalıcı olarak cache'lenebilir yapan şey. Bir yıllık max-age ise bunun yalnızca beyanı. Ayrım ilerideki bölümlerde önem kazanacak, çünkü Googlebot tarafında yalnızca birincisi işliyor.
_next/image: çalışma anında üretilen görsel
next/image optimizasyonu build sırasında değil, istek anında çalışıyor. Next.js dokümanının ifadesi açık: görseller çalışma anında optimize ediliyor, derleme sırasında değil. Yani sayfadaki görsel etiketi bir dosyaya değil, parametreli bir uç noktaya işaret ediyor.
Sonucu şu: /_next/ altındaki her şeyi kapatan bir kural, görsel yolunu da kapatıyor. Google'ın robots.txt dokümanı engellenen bir sayfaya gömülü görsellerin, videoların ve PDF dosyalarının da tarama dışında kaldığını yazıyor. Görsel aramadan trafik alan bir sitede bu, HTML tarafında hiç görünmeyen ikinci bir kayıp.
_next/data: gezinti sırasındaki veri isteği
Pages Router kullanan projelerde next/link ile yapılan gezinti sunucuya ayrı bir istek gönderiyor ve getServerSideProps orada çalışıyor. İlk yüklemede veri zaten HTML'in içinde. Ayrı istek yalnızca istemci tarafı geçişlerde doğuyor.
Googlebot sayfaları birbirine tıklayarak dolaşmaz, her URL'i ilk yükleme gibi ister. Bu yüzden gezinti veri yolunu engellemek Google'ın gördüğü içeriği doğrudan bozmuyor ve üç yol arasında en düşük riskli olanı. Yolun adı Next.js dokümantasyonunda yazılı değil. Kendi build'inizde tarayıcı ağ sekmesinden doğrulayın, varsayarak kapatmayın.
Engellemeden önce kendi projenizi tanıyın
Yukarıdaki üç yol framework'e ait. Sayfalarınızın hangisine yaslandığı ise projenize ait bir bilgi; aynı Disallow satırı iki Next.js sitesinde farklı büyüklükte kayıp üretir.
Belirleyici olan, sayfadaki metnin nereden geldiği. Server Component, statik üretim, istek anında render ve cache'ten servis edilen yenilenebilir üretim, içeriği sunucunun ilk yanıtına koyuyor. İstemci tarafı render koymuyor: ilk yanıt boş bir kabuk ve onu /_next/static/ altındaki JavaScript dolduruyor. Sayfanın görünürlüğünü robots.txt'e bağımlı kılan tek durum sonuncusu.
Kontrol ucuz ve Search Console gerektirmiyor. Tarayıcıda view-source ile kaynağa bakın, metni arayın. Metin kaynaktaysa o chunk Google'ın ihtiyaç duyduğu içeriği taşımıyor. Metin yoksa chunk sayfanın kendisi ve engel sayfayı boşaltıyor.
Gereksiz yazılmış bir 'use client' direktifi, robots.txt'e yazılacak hiçbir satırın telafi edemeyeceği bir kayıp. Disallow kuralını, sayfalarınızın hangisinin ikinci durumda olduğunu bildikten sonra yazın.
Engellenen dosyayı Googlebot render etmez
Google'ın JavaScript dokümanı süreci üç faza ayırıyor: crawling, rendering ve indexing. Yaygın varsayım, robots.txt'in yalnızca birinci fazı kontrol ettiği. Doküman aksini yazıyor: "Google Search won't render JavaScript from blocked files or on blocked pages."
Cümlenin iki yarısı iki ayrı senaryo. Engellenen sayfa render edilmiyor, beklenen sonuç. Engellenen dosya da render edilmiyor, ve gözden kaçan sonuç bu. Sayfanın kendisi taranabilir olsa bile, çalışması için gereken JavaScript engelliyse o JavaScript çalışmıyor.
Taranmış ama içi boş sayfa
Aynı doküman indeksleme koşulunu da veriyor: içerik render edilmiş HTML'de görünmüyorsa Google onu indeksleyemiyor. Render girdisi eksik olduğunda çıktı da eksik oluyor.
Ortaya çıkan tablo, taranmak ile indekslenmek arasındaki farkın teknik sebeplerinden biri. Sunucu logunda her şey normal görünüyor: Googlebot geldi, 200 aldı, gitti. Google tarafında elde kalan şey ise gövdesi doldurulamamış bir sayfa.
Kaybedilen ikinci şey: linkler
Googlebot yanıtı href özniteliklerindeki URL'ler için ayrıştırıyor ve bulduklarını crawl queue'ya ekliyor. Navigasyon veya listeleme linkleri yalnızca render sonrası DOM'a giriyorsa, render olmadığında keşif de olmuyor.
Internal linkler hem keşif yolu hem öncelik sinyali. Bir kategori sayfasının altındaki ürün linkleri render'a bağlıysa, engel o ürünleri pratikte orphan hâline getiriyor.
Engellediğin bot muhtemelen Googlebot değil
Yayınlanmış Next.js SEO rehberlerinde dolaşan robots.ts şablonu genelde tek bir şekle sahip. Bir * grubu, içinde /_next/ dahil uzun bir disallow listesi, ve altında Googlebot için ayrı bir grup.
User-agent: *
Disallow: /_next/
Disallow: /api/
User-agent: Googlebot
Disallow: /admin/
Disallow: /api/Dosyayı yazan kişi /_next/ yolunu herkese kapattığını sanıyor. Google'ın spesifikasyonu başka bir şey söylüyor: "Only one group is valid for a particular crawler. … Other groups are ignored." Devamı ayrımı kapatıyor: user-agent'a özel gruplar ile * grubu birleştirilmiyor.
Googlebot yalnızca kendi grubunu okuyor ve o grupta /_next/ yok. Yani dosyanın Googlebot üzerindeki etkisi sıfır. Engel Bingbot'a, Applebot'a ve robots.txt'e uyan her AI crawler'ına uygulanıyor.
İlk bakışta iyi haber gibi duruyor, Google zarar görmüyor. Asıl mesele hatanın bu yüzden hiç fark edilmemesi. Search Console temiz, URL Inspection'da engelli kaynak görünmüyor, Page indexing hareketsiz. Baktığın tek araç sana sorun olmadığını söylüyor.
Kayıp bakmadığın yerde birikiyor. Bing'in indeksinde sayfaların içi boşalıyor, ve ChatGPT ile Perplexity gibi ürünlere kaynak veren crawler'lar sayfayı render edemiyor. Grupların dosyadaki sırası da seni kurtarmıyor; doküman sıranın önemsiz olduğunu ayrıca yazıyor.
Kontrol yöntemi bu yüzden tek satır aramaktan farklı. Dosyada /_next/ geçiyor mu diye değil, hangi user-agent grubunda geçiyor diye bakılır. Googlebot için ayrı bir grup açıldığı anda, * altına yazılan hiçbir satır Googlebot'u ilgilendirmiyor.
Trafik kaybı hangi raporda görünür
Engelin bedeli anında ve tek bir yerde görünmüyor. Nereye bakılacağını bilmek, kaybı aylarca "sebebi belirsiz düşüş" olarak taşımakla haftalar içinde teşhis etmek arasındaki fark.
Page indexing: iki satır, iki ayrı anlam
Search Console'un Page indexing raporunda iki satır bu senaryoda hareket ediyor ve sık karıştırılıyorlar.
"Indexed, though blocked by robots.txt" engellenen URL'in kendisi için. Google dokümanı bunu bir uyarı olarak tanımlıyor: sayfa taranmadan, ona link veren sayfalardan gelen bilgiyle indekslenmiş. Aynı doküman devamını da yazıyor, arama sonucunda görünen snippet muhtemelen çok sınırlı kalıyor.
"Crawled – currently not indexed" ise engellenen kaynağa bağımlı sayfalar için beklenen davranış. Google'ın tanımı kısa: sayfa tarandı ama indekslenmedi, ileride indekslenebilir de indekslenmeyebilir de. Doküman bu satır için sebep listesi vermiyor.
Render girdisi kesilmiş bir sayfanın bu kovaya düşmesi mekanik olarak tutarlı. Bağı Google kurmuyor, Beaked'in çıkarımı, ve öyle okunmalı.
URL Inspection: kaybın gözle görüldüğü tek yer
Search Console'da bir URL incelenip View crawled page > More info açıldığında yüklenen kaynakların listesi, JavaScript konsol çıktısı ve render edilmiş DOM geliyor. Canlı testte aynı panel View tested page > More info altında.
İki panel iki ayrı soruyu cevaplıyor. İndeksteki sürüm "Google şu an ne biliyor" sorusunu, canlı test "şimdi çekse ne görürdü" sorusunu. Düzeltmeden sonra bakılacak yer ikincisi, çünkü indeksteki sürüm düzeltmeyi henüz görmemiş oluyor.
Bir kaynağın yanında engel kaydı varsa sorun robots.txt tarafında. Kaynak listede hiç yoksa sebep engel olmayabilir. Google'ın kendi dokümanı, Web Rendering Service'in temel sayfa içeriğine katkısı olmayan kaynakları çekmeyebileceğini söylüyor.
Core Web Vitals bu kayıptan etkilenmez
Sık tekrarlanan bir iddia ve yanlış. Search Console'un Core Web Vitals raporu gerçek kullanıcı verisine dayanıyor. Doküman veriyi "real world usage data" diye adlandırıyor ve üç metriğin gerçek kullanıcı ölçümü olduğunu yazıyor.
Ziyaretçinin tarayıcısı robots.txt okumaz. Engellenen JavaScript kullanıcıya normal servis edilir, Largest Contentful Paint (LCP) ve Interaction to Next Paint (INP) değerleri değişmez.
Geriye tek bir dolaylı bağ kalıyor ve dar: rapora yalnızca indekslenmiş URL'ler giriyor. Sayfa indeksten düşerse rapordan da düşer. Bozulan şey performans değil, sayfanın raporda temsil edilmesi.
Asıl crawl budget kaybı JavaScript'te değil
Next.js crawl budget tartışmasının çoğu yanlış yerde yürüyor. /_next/static/ altındaki dosyalar ucuz, ve ucuz olmalarının sebebi cache başlığı değil.
Google'ın dokümanı davranışı yazıyor: Googlebot ağ isteğini azaltmak için agresif cache uyguluyor, ve Web Rendering Service cache başlıklarını yok sayabiliyor. Bir yıllık immutable başlığına dayanan gerekçe bu yüzden eksik.
Doğru gerekçe dosya adı. Google aynı dokümanda içerik parmak izi kullanılmasını öneriyor, Next.js de tam olarak bunu yapıyor. Ad sabit kaldığı sürece dosya aynı dosya, yeniden çekilmesi için sebep yok.
Pahalı olan taraf başka. Sonlu içerikten sonsuz URL üreten şeyler, yani filtre kombinasyonları, sıralama parametreleri, takvim şablonları ve sayfalama zincirleri. ?sort= ile ?page= çarpımı bir kategori sayfasını binlerce URL'e çeviriyor ve bu URL'lerin hepsi taranabilir HTML döndürüyor. Bir robots.txt disallow satırı yazılacaksa değeri buradadır, JavaScript chunk'larında değil.
Satırı yazarken robots.txt'in neyi anladığına dikkat etmek gerekiyor. Path matching'de yalnızca iki wildcard destekleniyor, * ve $. Sık kopyalanan Disallow: /*?page=[2-9]* gibi bir kural düzenli ifade sanılıyor; Google onu düz metin olarak eşleştiriyor ve hiçbir sayfayı engellemiyor.
İkinci tuzak canonical tarafında. Parametreli URL'leri hem canonical ile ana sürüme bağlamak hem robots.txt ile engellemek iki aracı birbirine karşı çalıştırıyor. Google bunu açıkça yazıyor: robots.txt canonicalization amacıyla kullanılmamalı, çünkü engellenen URL'ler içeriksiz olarak indekslenmeye devam edebiliyor.
Ayrım, crawl budget yönetiminin merkezindeki soruya bağlanıyor: hedef toplam taramayı büyütmek değil, aynı taramayı doğru sayfalara yöneltmek. Next.js SEO tarafında yapılan engelleme hatalarının çoğu, bu soruyu hiç sormadan doğrudan bir satır yazmaktan doğuyor.
Next.js robots.txt nasıl yazılmalı
Doğru desen "engelleme" değil, engelle ve istisna aç. Desenin kaynağı bir yorum da değil. Google'ın robots.txt spesifikasyon dokümanının açılış örneği aynen bunu yapıyor. Örnekte .css ve .js klasörü tüm crawler'lara kapalı, Googlebot'a açık, ve gerekçe yorum satırında yazılı: Google'ın bu dosyalara render için ihtiyacı var.
Rule precedence: uzun yol kazanır, sıra değil
Yaygın varsayım, robots.txt'in yukarıdan aşağı okunduğu ve son eşleşen satırın kazandığı. Google öyle çalışmıyor. Doküman kuralı yazıyor: çakışan kurallarda en spesifik olan seçiliyor ve spesifiklik ölçüsü kural yolunun karakter uzunluğu. Eşit uzunlukta çakışma varsa en az kısıtlayıcı kural kazanıyor.
Pratikteki karşılığı, istisnanın satır sırasına bağlı olmaması:
User-agent: *
Disallow: /api/
Disallow: /_next/data/
Allow: /_next/static/
Allow: /_next/image
Sitemap: https://example.com/sitemap.xml/_next/static/ yolu /_next/ yolundan uzun olduğu için Allow kazanıyor. Aynı dosyaya Disallow: /_next/ de eklenebilir, sonuç değişmez.
app/robots.ts ve cache tuzağı
Next.js robots.txt dosyasını app dizininin kökünden veriyor. İki yol var: app/robots.txt düz metni ya da app/robots.ts içinde MetadataRoute.Robots döndüren bir fonksiyon. İkincisinin bir davranış notu var. Dokümanın kendi ifadesiyle robots.js varsayılan olarak cache'lenen özel bir route handler.
Buna Google'ın kendi cache'i ekleniyor. Spesifikasyon, robots.txt içeriğinin 24 saate kadar cache'lendiğini yazıyor. İki cache üst üste bindiğinde "düzelttim ama değişmedi" gözlemi doğuyor. Değişikliğin görünmesi hem yeni bir deploy hem Google tarafındaki tazelenme gerektiriyor.
Engel zaten konulduysa
Geri alma sırası önemli, çünkü yanlış sırada bakan kişi düzeltmenin işe yaramadığı sonucuna varıyor.
Önce Allow istisnasını ekleyin ve deploy edin. Sonra canlı robots.txt dosyasını tarayıcıdan açıp satırın gerçekten yayında olduğunu doğrulayın, çünkü üretilen dosya cache'lenmiş olabilir. Ardından URL Inspection'da canlı testi çalıştırın, indeksteki sürümü değil. Yüklenen kaynaklar listesinde engel kaydı kalmadıysa düzeltme Google tarafında geçerli.
İkinci kontrol sayfanın kaynağında. Tarayıcıda view-source ile açıp içeriğin HTML'de mi durduğuna yoksa yalnızca JavaScript ile mi geldiğine bakın. Sunucu tarafında render edilen (server-side rendering, SSR) veya statik üretilen (static site generation, SSG) içerik HTML'de zaten hazır olduğu için engelden daha az etkileniyor. Etkilenme derecesi, projenin ne kadarının istemci tarafında çalıştığına bağlı.
Buradan sonrası bekleme. Engellenen URL'ler crawl queue'da uzun süre kalıyor ve engel kaldırıldığında yeniden taranıyorlar, ama takvim sizin kontrolünüzde değil. Search Console'daki yeniden indeksleme talebi tek tek URL için işe yarar, site geneli için beklemek gerekiyor.
Bu sürede Page indexing raporundaki iki satırın hareketini takip edin. Toparlanma önce "Crawled – currently not indexed" sayısının düşmesiyle, sonra Crawl Stats raporundaki istek dağılımının normalleşmesiyle görünüyor.
Sıkça Sorulan Sorular
Next.js'te /_next/ engellenmeli mi?
Hayır. /_next/static/ ve /_next/image yolları render ve görsel arama için gerekli. Engelleme kararı verilecekse yol yol verilmeli. /api/ ve /_next/data/ kapatılabilir, build çıktısı ve görsel uç noktası kapatılamaz.
Disallow: /_next/ yazarsam ne olur?
Googlebot o dosyalara istek yapmayı bırakıyor ve Google engellenen dosyalardaki JavaScript'i çalıştırmıyor. İstemci tarafında render edilen içerik ve yalnızca render sonrası doğan internal linkler Google'a görünmez oluyor. Sunucu tarafında render edilen içerik HTML'de hazır olduğu için daha az etkileniyor.
/api/ robots.txt'te engellenmeli mi?
Genellikle evet. API uç noktaları HTML üretmiyor ve indekslenmeleri için sebep yok. Tek istisna, bir uç noktanın sayfa render'ına girdi veriyor olması. O durumda engel /_next/static/ engeliyle aynı sonucu doğuruyor.
robots.txt'te Googlebot için ayrı grup açmalı mıyım?
Açacaksan o grubun eksiksiz olması gerekiyor. Googlebot yalnızca kendisine en spesifik uyan tek grubu uyguluyor ve * grubunu tamamen yok sayıyor; ikisi birleştirilmiyor. Ayrı grup açıp * altındaki kuralların da geçerli olduğunu varsaymak, robots.txt'te en sık yapılan sessiz hata.
Next.js robots.txt değişikliği Google'da ne zaman görünür?
Google robots.txt içeriğini 24 saate kadar cache'liyor. app/robots.ts ile üretilen dosya ayrıca build tarafında cache'lendiği için, değişikliğin görünmesi önce yeni bir deploy sonra Google tarafındaki tazelenme gerektiriyor. Canlı dosyayı tarayıcıdan açıp doğrulamak, iki cache'ten hangisinin beklettiğini ayırmanın en hızlı yolu.
Kaynaklar ve Referanslar
- Google Search Central, "Understand the JavaScript SEO basics" (erişim 9 Eylül 2026)
- Google Search Central, "How Google interprets the robots.txt specification" (erişim 9 Eylül 2026)
- Google Search Central, "Introduction to robots.txt" (erişim 9 Eylül 2026)
- Google Search Central, "Fix Search-related JavaScript problems" (erişim 9 Eylül 2026)
- Google Search Console Yardım, "URL Inspection tool" (erişim 9 Eylül 2026)
- Google Search Console Yardım, "Page indexing report" (erişim 9 Eylül 2026)
- Google Search Console Yardım, "Core Web Vitals report" (erişim 9 Eylül 2026)
- Next.js dokümantasyonu, "How to self-host your Next.js application" (erişim 9 Eylül 2026)
- Next.js dokümantasyonu, "Metadata Files: robots.txt" (erişim 9 Eylül 2026)
- Next.js dokümantasyonu, "getServerSideProps" (erişim 9 Eylül 2026)