Yapay zeka sistemleri için bir llms.txt ve bir de llms-full.txt dosyası hazırladığımızda, ikincisini “tüm içeriği tek dosyada ver” mantığıyla kurduk. Dosya içerik kaynağından otomatik üretiliyordu; yeni bir yazı eklenince kendiliğinden büyüyordu. Bir gün siteyi FTP ile yüklerken tek bir dosyanın yaklaşık 15 MB olduğunu gördük. Ortada bir hata yoktu, ama bir tasarım sorunu vardı: GEO danışmanlığı sattığımız bir sitenin kendi yapay zeka dosyası, yapay zeka sistemlerinin işleyebileceği boyutta değildi.
Bu yazıda dosyanın neden şiştiğini, neyi tam metin bırakıp neyi özetlediğimizi ve sonucu rakamlarla anlatıyoruz. Baştan söyleyelim: bu dosyaların yapay zeka yanıtlarındaki görünürlüğü artırdığına dair kanıtımız yok. Konunun temelini llms.txt nedir yazımızda ve gerçekçi beklentileri aynı yazının “gerçekten işe yarıyor mu” bölümünde anlattık; burada yalnızca mühendislik tarafına, yani dosyayı makul boyutta tutmaya odaklanıyoruz.
Sorun: Tek Dosya, 15 MB
İlk sürümde llms-full.txt şunları tek dosyada, aralarına ayraç koyarak birleştiriyordu: kurumsal sayfaların tam metni, hizmet sayfalarının tam metni ve SSS’leri, şehir sayfalarının tam metni ve SSS’leri, ve her blog yazısının tam gövdesi. Sitedeki yazı sayısı yüzlerceydi; yeni yazılar eklendikçe dosya da büyüyordu.
İçerik kaynağındaki Markdown dosyalarının boyutuna bakınca dağılım netleşti:
| İçerik türü | Kaynak boyutu (yaklaşık) | Dosyadaki payı |
|---|---|---|
| Blog yazıları (tam gövde) | 14 MB | Dosyanın büyük çoğunluğu |
| Şehir sayfaları | 1,2 MB | Küçük ama tekrarlı (şablon) içerik |
| Hizmet sayfaları | 0,5 MB | Küçük, ama en önemli içerik |
| Kurumsal sayfalar (yasal metinler) | 0,01 MB | Çok küçük |
Yani sorun dosyanın “tam” olması değil, en önemsiz kısmının (yüzlerce blog gövdesinin) en önemli kısmını (hizmet ve kurumsal sayfalar) gömmesiydi. Kimin neye bakacağı belli değildi.
Dosya Büyük Olunca Ne Sorun Çıkar?
Bu noktada dürüst olmak gerekir: bir yapay zeka sisteminin llms-full.txt dosyasını nasıl işlediğine dair kamuya açık bir boyut sınırı bilmiyoruz. Bu dosya bir standart değil, bir öneri ve uygulama biçimi. Ancak boyutun neden sorun olabileceğine dair mantıklı gerekçeler var:
- Bağlam penceresi: Dil modelleri belirli bir miktar metni aynı anda işleyebilir. 15 MB’lık Türkçe metin, kabaca birkaç milyon token eder; bu miktar bugün yaygın olan modellerin bağlam pencerelerinin büyük bölümünün üzerindedir. Dosyanın tamamı okunsa bile işlenmez, kesilir ya da atlanır.
- İndirme ve işleme maliyeti: Büyük dosyayı çekmek ve ayrıştırmak, sistem ya da araç için zaman ve kaynak demektir. Zaman aşımına uğrayan bir istek, hiç gelmemiş bir istektir.
- Sinyal kaybı: Hizmet sayfaları yüzlerce blog gövdesinin arasında kaybolur. Bir dosyanın amacı, en önemli bilgiyi hızlı ulaşılır kılmaktır.
- Bakım zorluğu: Büyük bir dosyayı doğrulamak, bozuk bağlantıları yakalamak ve gözle kontrol etmek zorlaşır.
Küçültmenin hedefi sihirli bir sayıya ulaşmak değil, dosyanın amacına uygun, öngörülebilir bir boyutta kalmasıydı.
Neyi Tam Metin, Neyi Özet Bıraktık?
Kararı bir soruyla verdik: “Bir yapay zeka sistemi bu siteyi anlamak için tek bir dosyaya bakacak olsa neyi görmeli?” Cevap, iş modelimizi anlatan sayfalar oldu: hangi hizmetleri sunduğumuz, ne içerdikleri ve nasıl çalıştığımız. Blog yazılarının tam metni ise zaten kendi adreslerinde duruyor.
| İçerik | Önce | Sonra | Gerekçe |
|---|---|---|---|
| Kurumsal sayfalar | Tam metin | Tam metin | Çok küçük, yasal ve kurumsal metin |
| Hizmet sayfaları | Tam metin + SSS | Tam metin + SSS | Ne sattığımızı anlatan asıl içerik |
| Şehir sayfaları | Tam metin + SSS | Yalnızca başlık ve adres | Şablon içerik, tekrarlı |
| Blog yazıları | Tam gövde | Başlık, adres, tarih, açıklama, kısa özet, SSS soruları | Tam metin kendi adresinde |
Girişteki açıklama paragrafını da değiştirdik: dosyanın neyi tam, neyi özet içerdiğini ve neden kısa tutulduğunu açıkça yazıyor. Böylece dosyayı okuyan bir sistem ya da insan, eksik gibi görünen kısmın bilinçli bir karar olduğunu anlıyor.
Blog Özetleri Nasıl Üretildi?
Her blog yazısı için dosyaya şu alanlar yazılıyor: başlık, adres, güncelleme ya da yayın tarihi, açıklama (meta description), yazının ilk düz paragrafından üretilmiş kısa bir özet ve yazıdaki SSS sorularının listesi. Gerçek bir kayıt şöyle görünüyor (özet kısaltılmıştır):
### Google Yorumlarına Nasıl Cevap Verilir? Olumlu ve Olumsuz Yorum Cevap Şablonları
URL: https://www.softajans.com/blog/google-yorumlarina-nasil-cevap-verilir/
Tarih: 2026-10-04
Açıklama: Google yorumlarına nasıl cevap verilir? Olumlu, olumsuz ve haksız yorumlar için ...
Özet: Bir müşteri Google'da işletmeniz hakkında yorum yazdığında, yalnızca size değil, ...
Sık sorulan sorular: Google yorumlarına cevap vermek zorunlu mu? | Google yorumlarına ne kadar sürede ...Özeti üreten küçük işlev şunları yapıyor: gövdeyi paragraflara bölüyor, başlık, görsel, tablo ve liste satırlarını eliyor, ilk düz paragrafı alıyor, içindeki bağlantıları ve biçimlendirme işaretlerini temizliyor ve en fazla 450 karakterde, kelime ortasında kesmeden bitiriyor. SSS soruları ise sitenin zaten FAQ şeması için kullandığı aynı ayrıştırıcıdan geliyor; böylece iki yerde iki farklı kural olmuyor.
Sonuç: Rakamlarla Önce ve Sonra
Değişikliği yaptıktan sonra dosyayı yeniden ürettik ve boyutları ölçtük:
| Dosya | Önce | Sonra |
|---|---|---|
llms-full.txt | yaklaşık 15,2 MB | yaklaşık 1,06 MB |
llms-full.txt (gzip ile sıkıştırılmış) | ölçmedik | yaklaşık 264 KB |
llms.txt | yaklaşık 145 KB | yaklaşık 127 KB |
llms.txt için yaptığımız değişiklik daha küçüktü: şehir sayfalarını tek tek listelemek yerine “tüm şehirler” sayfasına tek bir bağlantı verdik. Böylece dosya kısaldı ve şablon içerik bağlantı dizininde yer kaplamaz hâle geldi.
Yeni yazılar eklendikçe llms-full.txt yine büyüyecek, ama artık her yazı için birkaç satır ekliyor; yazının tamamını değil. Bu, dosyanın büyüme hızını belirgin biçimde yavaşlatır. Yine de 1 MB’lık metin bile birçok modelin tek seferde alabileceği miktarın üzerinde olabilir; bu yüzden bu dosyayı bir “tek seferde okunacak belge” olarak değil, sitenin yapısını ve önemli içeriğini gösteren bir harita olarak tasarlıyoruz.
Kendi Sitenizde Nasıl Uygularsınız?
llms-full.txt hazırlıyorsanız şu adımları izleyin:
- Bir boyut bütçesi koyun. Örneğin “1-2 MB’ı geçmesin”. Bütçe yoksa dosya içerik arttıkça sessizce büyür.
- Önceliği belirleyin. Hizmet, fiyat, hakkımızda ve iletişim gibi sayfalar tam metin olsun; blog gibi çok sayıdaki içerik için başlık, adres ve özet yeterli.
- Şablon içeriği tekrarlamayın. Şehir ya da ürün sayfaları gibi yapısı aynı olan sayfaları tek bir bağlantıya indirin.
- Dosyayı otomatik üretin. Elle güncellenen dosya eskir. İçerik kaynağından üretirseniz yeni sayfa kendiliğinden girer.
- Girişte dosyanın neyi içerdiğini yazın. Eksik görünen kısmın nedenini açıklayın.
- Her yayında boyutu ölçün. Yayından sonra dosya boyutunu ve sıkıştırılmış boyutu kontrol edin; sıçrama varsa nedenini araştırın.
- Gizli sayfaları dışarıda tutun.
noindexya da parola korumalı sayfalar dosyada yer almamalı; ayrıca dosya robots.txt kurallarıyla çelişmemeli. Bunun için robots.txt nedir yazısına bakabilirsiniz. - Bağlantıları temiz tutun. Dosyadaki adreslerin yönlendirmesiz, doğrudan çalışması gerekir; yönlendirme sorunlarını yönlendirme zinciri nedir yazısında anlattık.
Beklentiyi Yönetmek
Dosyayı küçültmek bir optimizasyon, bir sonuç değil. Bunun yapay zeka yanıtlarında daha çok anılmamızı sağlayıp sağlamadığını bilmiyoruz ve bu yüzden böyle bir iddia da kurmuyoruz. Büyük arama ve yapay zeka sağlayıcılarının bu dosyaları kullanıp kullanmadığı belirsiz; bazılarının yetkilileri kullanmadıklarını söylemiştir ve durum değişebilir.
Bu yüzden llms-full.txt çalışmasını daha geniş bir resmin küçük parçası olarak görüyoruz. Yapay zeka yanıtlarında görünürlüğü asıl etkileyen unsurlar hâlâ bilinen temeller: taranabilir ve hızlı bir site, net cevaplar veren içerik, yapılandırılmış veri ve güvenilirlik. Bunu nasıl ölçtüğümüz için yapay zeka görünürlüğü nasıl ölçülür yazısına, konunun genel çerçevesi için GEO nedir yazısına bakabilirsiniz. Markanızın yapay zeka yanıtlarındaki durumunu birlikte incelemek isterseniz GEO danışmanlığı sayfamıza göz atın.
Sık Yapılan Hatalar
- “Her şeyi koyalım” demek: Dosya tam olduğu için değil, işe yaradığı için değerlidir.
- Bütçesiz üretmek: Boyut sınırı olmayan dosya fark edilmeden büyür; biz bunu yükleme sırasında fark ettik.
- Şablon sayfaları tekrarlamak: Aynı yapıdaki yüzlerce sayfa dosyayı şişirir, sinyal eklemez.
- Girişte açıklama yazmamak: Dosyanın neden kısa olduğunu belirtmezseniz eksik sanılır.
- Gizli ya da yönlendirilen adresleri listelemek: Sistemi boşuna yönlendirir.
- Dosyayı yayınlayıp bırakmak: Her yayında boyut ve bağlantı kontrolü yapılmalı.
Sık Sorulan Sorular
llms-full.txt zorunlu mu?
Hayır. Resmî bir standart değildir; bazı siteler llms.txt ile yetinir, bazıları yanında daha kapsamlı bir dosya yayınlar. Hazırlayacaksanız boyutunu ve içeriğini bilinçli seçin.
İdeal dosya boyutu nedir?
Herkes için geçerli bir sınır yok. Bizim için ölçüt, dosyanın bir harita gibi kullanılabilmesiydi; bunun için birkaç yüz KB ile 1-2 MB arasındaki bir boyutu makul gördük. Siteniz ve amacınıza göre kendi bütçenizi belirleyin.
Blog yazılarının tam metnini hiç koymamak doğru mu?
Bizim yaklaşımımızda tam metin kendi adresinde duruyor, dosyada ise özet ve SSS soruları var. Küçük bir sitede az sayıda yazı varsa tam metin koymak sorun olmayabilir. Karar, toplam boyuta bağlıdır.
Bu değişiklik yapay zeka yanıtlarında görünürlüğü artırdı mı?
Bilmiyoruz ve ölçemedik. Bu nedenle bir etki iddia etmiyoruz; yaptığımız şey dosyayı amacına uygun ve bakımı kolay hâle getirmekti.
llms.txt ile llms-full.txt arasındaki fark nedir?
llms.txt sitenin kısa bir tanımını ve önemli sayfalara giden bağlantıları içeren bir dizindir. llms-full.txt ise içeriğin kendisini (tam ya da özet) tek dosyada toplar. Biri “nereye bakmalı”, diğeri “ne yazıyor” sorusuna cevap verir.
Dosyayı otomatik üretmek için ne gerekir?
İçeriğiniz bir yapıda (Markdown dosyaları, bir CMS ya da veritabanı) duruyorsa, yayın sırasında bu içeriği okuyup dosyayı yazan küçük bir betik yeterlidir. Bizim sitemizde dosya, yayın sırasında içerik kaynağından üretilen bir sayfa olarak çalışıyor.
