Yedi dile çevrilmiş bir acente sitesinin tipik hikâyesi şudur: Türkçe tarafta iş görüyor, İngilizce tarafta zar zor, kalan beş dilde neredeyse hiç. Ekip önce içeriği suçlar, çeviriyi yeniler, birkaç yazı daha ekler. Rakam kımıldamaz. Çünkü sorun çoğu zaman yazdığınız metinde değil, o metnin arama motoruna kaç ayrı adresten, hangi durum koduyla ve hangi dil etiketiyle sunulduğundadır.
Bu yazı, yedi dilli bir seyahat yazılımı sitesinde uçtan uca yürüttüğümüz teknik denetimin bulgularını rehber hâline getiriyor. Rakamların hepsi o denetimden ya da kaynağı belirtilmiş dış çalışmalardan geliyor; hiçbiri tahmin değil. Denetim 1.088 canlı sayfayı, 1.469 sitemap adresini ve yedi dilin tamamını kapsadı ve ortaya çıkan tablo şuydu: sayfaların %85'inde kanonik adres etiketi hiç yoktu, site iki ayrı host üzerinden tümüyle kopyalanıyordu, altı dilde ilan edilen çeviriler aslında "sayfa bulunamadı" mesajı döndürüyordu.
Aşağıdaki bölümlerin her biri, hiçbir yazılım satın almasanız bile kendi sitenizde bir tarayıcı ve curl ile uygulayabileceğiniz bir kontrol, bir eşik ya da bir karar kuralı veriyor. Sıra da önemli: teknik temizlik yapılmadan içerik derinliği çalışmaz, içerik derinliği olmadan yapay zekâ görünürlüğü çalışmaz.
Denetim sırası: önce tek gerçek kaynak (kanonik adres, karşılıklı hreflang, dürüst durum kodu), sonra içerik, en son yapay zekâ görünürlüğü.
1. Önce sayın: aynı sayfaya kaç adresten ulaşılıyor?
Denetime içerikten başlamayın, adres sayımından başlayın. Bir sayfanın kaç farklı adresten açılabildiğini ölçmek on dakika sürer ve genellikle en büyük kaybı ilk turda ortaya çıkarır.
Ölçtüğümüz sitede iki temel arıza vardı. Birincisi: alan adının www'lu ve www'suz hâli ikisi de 200 dönüyordu, yani sitenin tamamı iki kez erişilebilir durumdaydı. İkincisi: eski ve yeni yol adları birlikte açık bırakıldığı için /tr/portfolio ile /tr/referanslar aynı içeriği veriyordu; bu tek kalıp yaklaşık 1.713 gölge adres üretiyordu.
Kendi sitenizde şu beş varyantı sırayla isteyin ve dönen durum kodunu yazın:
| Varyant | Örnek | Beklenen sonuç |
|---|---|---|
| www'suz host | ornek.com/tr/blog |
301 → www'lu hâl |
| www'lu host | www.ornek.com/tr/blog |
200 |
| Sonda eğik çizgi | www.ornek.com/tr/blog/ |
301 → çizgisiz hâl |
| İzleme parametresi | www.ornek.com/tr/blog?utm=x |
200 + kanonik etiket parametresiz |
| Eski yol adı | www.ornek.com/tr/yazilar |
301 → yeni yol |
Komut satırında tek satırla bakabilirsiniz:
curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" -I <adres>
Beşinden ikisi ve fazlası 200 dönüyorsa, arama motoru sizin bir sayfanız olduğunu değil, birbirinin kopyası birkaç sayfanız olduğunu görüyordur. Bu bir ceza meselesi değil; sinyalin bölünmesi meselesidir. Aynı içeriğe gelen bağlantılar, tıklamalar ve tarama bütçesi birden fazla adrese dağılır.
Beş varyantın hepsi 200 dönüyorsa sinyal beşe bölünür. Çözüm sırası: eski yollar 301 ile birleşir, kalanlar kendini gösteren canonical etiketiyle toplanır.
Karar kuralı
Bir sayfa için tam olarak bir kanonik biçim tanımlayın ve üç şeyi ona sabitleyin: host (www'lu ya da www'suz, ikisinden biri), sondaki eğik çizgi politikası (hep var ya da hiç yok) ve büyük/küçük harf. Bu üç karar yazıya dökülmediği sürece her yeni sayfa şablonu kendi varyantını üretir.
2. Canonical bir emir değil, sinyaldir
Denetimde en çarpıcı rakam buydu: 200 dönen 1.088 sayfanın 921'inde (%85) canonical etiketi hiç yoktu. Etiketi olan 167 sayfanın 60'ında ise etiket kendini göstermiyordu — sayfa www.ornek.com/tr adresinden servis ediliyor, canonical olarak https://ornek.com/tr/ yazıyordu. Yani host da eğik çizgi de uyuşmuyordu.
Bu noktada iki teknik gerçeği bilmek gerekiyor. Google'ın kendi dokümantasyonu rel="canonical" etiketini bir direktif değil, "belirtilen adresin kanonik olması gerektiğine dair güçlü bir sinyal" olarak tanımlar; nihai kararı arama motoru verir. Aynı dokümantasyon kanonikleştirme yöntemlerini güçten zayıfa sıralar: yönlendirme > canonical etiketi > sitemap'te yer alma. Sitemap açıkça "zayıf sinyal" olarak geçer.
Bunun pratik sonucu şu: canonical etiketi tek başına bir temizlik aracı değildir. Eski bir adresi kapatmak istiyorsanız yönlendirme kullanın; canonical'ı yalnızca yönlendirilemeyen varyantlar (parametreli hâller, filtre kombinasyonları) için bırakın.
İkinci gerçek: Google kanonik sayfanın kendi kendine referans veren bir canonical taşımasını öneriyor. Yani "canonical yalnızca kopya sayfalara yazılır" varsayımı yanlış; asıl sayfa da kendini göstermelidir.
Neden elle yazılan canonical kaçınılmaz olarak bozulur
Denetlediğimiz sitede canonical on ayrı sayfa şablonunda elle yazılmıştı: birinde eğik çizgiyle, birinde www'suz, birinde artık var olmayan bir yol parçasıyla. On dört şablonda ise hiç yoktu. Bu bir dikkatsizlik değil, yapısal bir sonuç: her yeni sayfa şablonu yazan kişi kuralı yeniden hatırlamak zorunda kalırsa, kural er ya da geç unutulur.
Uygulanabilir kural: canonical, hreflang ve og:url üçlüsü sayfa şablonlarında değil, tek bir ortak yerde üretilsin ve sayfa başına yalnızca bir kez basılsın. Bir sayfa kendi canonical'ını yazmaya kalkarsa yayın süreci bunu engellemeli. Denetim sonrası kurulan yapıda bu kural bir derleme kontrolüne bağlandı; "disiplinle" değil "yapıyla" garanti altına alındı.
3. hreflang: karşılığı olmayan dili ilan etmenin bedeli
Çok dilli sitelerin en pahalı hatası burada. Denetlediğimiz sitede bir Türkçe blog yazısı, İngilizce karşılığı olarak bir adres ilan ediyordu. O adres HTTP 200 dönüyordu — ama gövdesinde "Blog Post Not Found" yazıyordu. Aynı kalıp altı dilde tekrarlanıyordu. Yani site, arama motoruna kendi eliyle yüzlerce boş sayfa bildiriyordu.
Google'ın uluslararası sürümler dokümantasyonu bu konuda net: "Eğer X sayfası Y sayfasına bağlanıyorsa, Y sayfası da X'e geri bağlanmalıdır. hreflang kullanan tüm sayfalar için bu geçerli değilse, bu ek açıklamalar yok sayılabilir veya doğru yorumlanmayabilir." Aynı doküman daha kesin bir cümle de kuruyor: "İki sayfa birbirini göstermiyorsa, etiketler yok sayılır."
Buradan çıkan üç kural var:
| Durum | Doğru davranış | Yanlış davranış |
|---|---|---|
| Çeviri var, yayında | Karşılıklı hreflang yaz | Tek yönlü ilan |
| Çeviri yok | Hiç hreflang yazma | Aynı slug'ı o dile de yaz |
| Çeviri var, taslak | Yayına alana kadar yazma | "Nasılsa yakında" diye yaz |
Solda: tek yönlü ilan edilen dil, 200 dönen ama içeriği olmayan bir adrese işaret ediyor. Sağda: yalnızca gerçek çevirisi olan diller karşılıklı ilan ediliyor, Almanca satırı hiç yazılmıyor.
Google'ın saydığı diğer iki yaygın hata da dikkat ister: dil kodlarının ISO 639-1 dışına çıkması ve bölge kodu olarak EU, UK, UN gibi resmî olmayan değerlerin kullanılması. Bölge kodu ISO 3166-1 Alpha 2 olmalı ve tek başına bölge belirtmek geçerli değil — hreflang="TR" yazılmaz, hreflang="tr" ya da hreflang="tr-TR" yazılır.
x-default ise dil seçimi yapılamayan kullanıcılar için bir yedek adres tanımlar. Çok dilli bir acente sitesinde en mantıklı seçim, uluslararası satış yapılan dilin (çoğunlukla İngilizce) ana sayfasıdır ya da varsa dil seçim ekranıdır.
4. Soft 404: "bulunamadı" yazıp 200 dönmek
Soft 404, Google'ın tanımıyla, içeriğin bir hata mesajı ya da boş sayfa olduğu hâlde sunucunun 2xx başarı kodu döndürmesidir. Fark edilmesi en zor arızadır çünkü hiçbir izleme aracı alarm vermez: sayfa "çalışıyor" görünür, insanlar da o adrese zaten gitmez.
Denetlediğimiz sitede olmayan içerikler 200 + "bulunamadı" dönüyordu. Bunları dürüst 404'e çevirdiğimizde, daha önce tamamen gizli kalmış üç arıza aynı anda görünür oldu:
| Ortaya çıkan arıza | Etkilenen adres |
|---|---|
| Yüzde-kodlu yollar hiç çözülmüyordu | 23 |
| Sitemap'te karşılığı olmayan kategori sayfaları | 33 |
| Veritabanı slug'ları ürün tanımıyla uyuşmuyordu | 10 |
En dramatik sonuç şuydu: Arapça ürün sayfaları yayına girdiklerinden beri hiçbir gerçek istemci için çalışmamıştı. Ham UTF-8 ile istendiğinde 200 dönüyor, tarayıcının gerçekte gönderdiği yüzde-kodlu hâliyle 404 dönüyorlardı. Soft 404 olduğu için kimse fark etmemişti; ekip Arapça sayfaların "yayında" olduğunu sanıyordu.
Karar kuralı
Dürüst 404'e geçmekten korkmayın. Kısa vadede hata sayınız artacak — bu bir kötüleşme değil, ölçümün doğrulaşmasıdır. Kalıcı olarak geri gelmeyecek adresler için 410 daha da nettir; ama hangi adresin geri gelmeyeceği bir içerik kararıdır, önce onu verin.
5. Latin dışı alfabede URL: yüzde-kodlama tuzağı
Arapça, Rusça ve Türkçe karakter içeren yollar tarayıcı tarafından yüzde-kodlanarak gönderilir. Google'ın adres yapısı dokümantasyonu bunu açıkça önerir: "ASCII aralığı dışındaki karakterler yüzde kodlanmalıdır." Aynı doküman hedef kitlenin dilindeki kelimelerin (ve gerekirse harf çevirisinin) adreste kullanılmasını da destekler.
Sorun şu ki sunucu tarafı bu kodlamayı çözmüyorsa, o dilin tamamı sessizce ölür. Kendi kontrolünüz için aynı adresi iki biçimde isteyin:
- Ham hâli:
/ar/blog/<arapça-slug> - Yüzde-kodlu hâli:
/ar/blog/%D8%A8...
İkisi de aynı durum kodunu dönmüyorsa arızanız var demektir. Test edilecek dil sayısı azdır ama etkisi tüm bir pazardır.
Uygulanabilir politika: Latin dışı alfabeli diller için üç seçenekten birini bilinçli seçin ve yedi dilde tutarlı uygulayın — (a) hedef dilin kendi alfabesi (yüzde-kodlamanın çalıştığı doğrulanmışsa), (b) harf çevirisi (Rusça için budushcheye-... gibi), (c) İngilizce slug + dil soneki. Yanlış olan seçenek yok; yanlış olan, dilden dile farklı davranmak.
Ayrıca Google kelime ayracı olarak alt çizgi yerine tireyi öneriyor: "Adreslerinizde kelimeleri ayırmak için alt çizgi (_) yerine tire (-) kullanmanızı öneririz." Gerekçesi, alt çizginin programlamada birbirine bağlı kavramları göstermek için kullanılması.
6. Sitemap bir liste değil, bir taahhüttür
Sitemap'e koyduğunuz her adres için "bu gerçek, indekslenmeye değer bir sayfadır" demiş olursunuz. Denetlediğimiz sitede sitemap 1.469 adres ilan ediyordu; temizlik sonrası 1.386'ya indi. Ayıklananlar şunlardı:
- 28 adres HTML değil, ham veri (JSON) döndürüyordu — bir uygulama arayüzü ucu, sayfa gibi ilan edilmişti.
- 21 adres hiç render edilemiyordu.
- 33 adres karşılığı olmayan kategori sayfalarıydı; gövdeleri 21-25 kelimeydi ve hepsi aynı "yüklenemedi" şablonunu basıyordu.
Ayrıca 1.469 adresin tamamı yanlış host ile (www'suz) yayınlanıyordu; yani sitemap, sitenin kendi kanonik kararına ters bir liste ilan ediyordu.
İkinci sessiz hata lastmod alanındaydı: her istekte "bugün" değerini üretiyordu. Bu, alanı tamamen anlamsız kılar. lastmod, o içeriğin gerçek son güncelleme tarihinden beslenmelidir; aksi hâlde tarayıcı bu sinyali dikkate almayı bırakır.
Sitemap kontrol listesi
- Sitemap'teki host, sitenin kanonik host'uyla birebir aynı mı?
- Rastgele 10 adresi çekin — hepsi 200 ve
Content-Type: text/htmlmi? - Sondaki eğik çizgi politikası sitemap'te de uygulanmış mı?
lastmoddeğerleri birbirinden farklı mı, yoksa hepsi aynı gün mü?- Çevirisi olmayan diller sitemap'e hiç girmiyor mu?
noindexverilen sayfalar sitemap'ten çıkarılmış mı?
7. robots.txt'in sessiz hatası: grup kuralı
Bu, denetimde bulduğumuz en ucuz ama en pahalı hatalardan biriydi: dosyada bir Disallow satırı vardı, doğru yazılmıştı, ama yanlış gruba yazıldığı için Googlebot için tamamen etkisizdi.
Sebebi robots.txt'in RFC 9309 ile standartlaşmış grup mantığı. Standart şunu söylüyor: bir tarayıcı kendi ürün belirtecine (product token) uyan grubu bulur ve o grubun kurallarına uyar. Joker * grubu yalnızca eşleşen bir grup yoksa devreye girer. Yani:
Şöyle bir dosya düşünün:
| Grup | İçindeki kurallar |
|---|---|
User-agent: Googlebot |
Disallow: /ara |
User-agent: * |
Disallow: /ara ve Disallow: /sepet |
Bu dosyada Googlebot /sepet yolunu tarayabilir, çünkü kendi grubunda o satır yok ve joker grubuyla birleştirme yapılmaz. Kural basit: bir kuralın geçerli olmasını istiyorsanız, o kuralı her User-agent grubunda ayrıca tekrarlayın.
Kontrolü elle yapmak yerine, dosyanızı kopyalayıp Search Console'daki robots.txt raporunda hedef yolu test edin. Beklediğinizle sonucun uyuşmadığı ilk satır muhtemelen bu gruplama hatasıdır.
8. CDN önbelleği: bir ziyaretçinin dili herkese servis edilir
Denetimde ortaya çıkan en tuhaf davranış buydu. Kök adres, ziyaretçinin tarayıcı diline göre değişen bir 302 yönlendirmesi üretiyordu. Ara katman bu yanıtı Vary başlığı göndermeden bir saat boyunca önbellekte tutuyordu. Sonuç: o bir saat içinde siteye ilk giren kişinin dili, sonraki herkese servis ediliyordu. Almanca tarayıcıyla gelen bir kurumsal müşteri Türkçe siteye düşüyordu ve bunun neden olduğunu kimse anlayamıyordu.
Vary başlığının işlevi tam olarak budur: önbelleğe, saklanan yanıtın hangi istek başlıklarına bağlı olduğunu söyler. MDN'in tanımıyla, Vary başlığı içermek "yanıtların, Vary alanında listelenen başlıklara göre ayrı ayrı önbelleğe alınmasını sağlar." Başlık gönderilmezse önbellek, aynı adrese gelen tüm istekleri özdeş sayar ve dil, çerez ya da cihaz farkına bakmaksızın aynı yanıtı verir.
Yanıt dile göre değişiyor ama önbellek anahtarı yalnızca adres. İlk ziyaretçinin dili bir saat boyunca herkesin dili olur.
İki çözümden birini seçin:
A — Yanıtı ayırın. Dile göre değişen her yanıta Vary: Accept-Language ekleyin. Önbellek dil başına ayrı kayıt tutar. Maliyeti: önbellek isabet oranı düşer.
B — Yanıtı sabitleyin (tercih edilen). Kök adres dile bakmadan tek bir kalıcı yönlendirme yapsın (/ → 301 → /tr gibi), dil tercihi sayfa içinde çözülsün. Hem önbellek verimli kalır hem arama motoru tek bir davranış görür.
İkinci kural: ölçümü önbellek temizlemeden yapmayın
Bir CDN, HTML yanıtlarını yirmi dört saate kadar tutabilir. Yayına aldığınız düzeltmeyi hemen ölçerseniz eski hâli ölçmüş olursunuz ve "düzelmemiş" sonucuna varırsınız. Yayın sonrası doğrulama sırası şudur: yayınla → ilgili yolların önbelleğini temizle → ölç. Bu adım atlandığı için düzgün çalışan bir düzeltmenin geri alındığına birden fazla kez tanık olduk.
9. Yönlendirme zincirleri ve kanonik olmayan hedefler
Denetim öncesi kök adres şöyle davranıyordu: / → 302 → /tr/ → 308 → /tr. Üç durak. Her durak hem tarayıcı için ek gecikme hem de sinyal kaybıdır; ayrıca ilk adımın 302 (geçici) olması, hedefin kalıcı kanonik olduğunu değil olmadığını söyler. Tek adıma indirildi: / → 301 → /tr.
Daha sinsi olan bulgu ikinciydi. Sitede eski adresleri yeniye taşıyan bir yönlendirme tablosu vardı ve bu tablodaki 329 hedefin kendisi kanonik değildi — yani yönlendirme kuralları uygulandığında her biri ikinci bir yönlendirme daha üretecekti. Kanonikleştirme yayına alınmadan önce yakalandı; alınsaydı 329 yeni zincir doğacaktı.
Karar kuralı
Yönlendirme tablonuza yeni satır eklemeden önce hedefin kendisini kanonik forma karşı doğrulayın: doğru host, doğru eğik çizgi politikası, gerçekten 200 dönen bir sayfa. Bu doğrulama tabloyu değiştiren her işin zorunlu adımı olmalı; sonradan tek tek ayıklamak kat kat pahalıdır.
10. Kendi sitenizde kaybolan sayfalar
Bir sayfanın sitemap'te olması onun bulunabilir olduğu anlamına gelmez. Denetimde iki ayrı kayıp kalemi çıktı:
49 indekslenebilir orphan adres. Sitemap'te ilan edilen ama sitede tek bir bağlantı almayan sayfalar: bir yardım merkezi sayfası (7 dil), beş entegrasyon kategori sayfası (35 adres) ve listelerle kod arasında ayrışmış 7 adres. Bunların bir kısmı için adres üretecek fonksiyon yazılmış, hatta menü bileşenine dahil edilmiş, ama hiç çağrılmamıştı.
70 kırık iç bağlantı. Yardım sayfasındaki dört kategori kartı var olmayan bir yola gidiyordu (4 kart × 7 dil = 28 bağlantı). Hizmet detay sayfalarının üst kırılımı (breadcrumb), hiç yazılmamış bir hizmet dizin sayfasını gösteriyordu (2 konum × 3 hizmet × 7 dil = 42 bağlantı) — ve aynı kırık adres yapısal veriye de giriyordu.
Üçüncü bulgu daha ince: 33 blog yazısının 21'i tıklama derinliği 3'teydi ve tek erişim yolu noindex işaretli bir sayfalama adımıydı. Bağlantılar takip edilebilir olduğu için teknik olarak taranıyorlardı, ama yazılara giden gerçek, indekslenebilir bir iç bağlantı yoktu.
Ölçüm yöntemi
Sitemap adres listesini bir kenara, sitenizin iç bağlantı grafiğini (her sayfadaki <a href> toplamı) diğer kenara koyun ve farkı alın. Sitemap'te olup grafikte olmayanlar orphan'dır; grafikte olup 200 dönmeyenler kırık bağlantıdır. Bu iki kümeyi ayda bir üretmek, çoğu sitenin fark etmediği kaybı görünür kılar.
11. İnce içerik ve "çevrildi sanılan" sayfalar
Denetim sonrası ölçümde site ortalaması 472 kelime, 300 kelimenin altında 176 sayfa vardı. Ama asıl bulgu ham rakamın kendisi değil, onu okuma biçimiydi.
Birinci düzeltme: sayfa çerçevesini çıkarın. Sayfa metnini olduğu gibi saymak, üst menü ve alt bilgiyi de içeriğe dahil eder. Ölçtüğümüz sitede bu sabit çerçeve dil başına 117-233 kelime tutuyordu. Yani ham 300 kelime, gerçekte yaklaşık 120 kelimelik bir gövdeye karşılık geliyordu. Gerçek eşiği ham sayıya değil, çerçeve çıkarılmış gövdeye kurun.
İkinci düzeltme: dil morfolojisini normalize edin. Ham sayıya bakıldığında Almanca çeviriler eksik görünüyordu (medyan 393'e karşı İspanyolca 610). Oysa içerik birebir aynıydı; fark tamamen kelime yapısından geliyordu: Flugbuchungssoftware bir kelime, aynı ifade İspanyolcada beş kelime. Tamamen çevrilmiş sekiz sayfa üzerinden ölçtüğümüz katsayılar şöyleydi:
| Dil | Katsayı (en = 1,00) |
|---|---|
| Almanca | 0,827 |
| Azerbaycanca | 0,916 |
| Türkçe | 0,929 |
| Rusça | 0,939 |
| Arapça | 0,963 |
| İspanyolca | 1,165 |
Bu düzeltme yapıldığında Almanca ve İspanyolca'da çeviri açığı olmadığı, gerçek açığın Arapça'da (22 adres) ve İngilizce'de (16 adres) toplandığı ortaya çıktı.
Üçüncü bulgu: özet, çeviri değildir. Arapça sürümlerin birçoğu tam çeviri değil, İngilizce metnin kısaltılmış hâliydi — küme medyanının %38-48'i. Bunlar teknik olarak "çevrilmiş" sayılıyordu, pratikte hiçbir sorguda yarışamıyordu.
Dördüncü bulgu: 7 grup / 67 adres birebir aynı gövdeye sahipti. Çoğu, çevirisi yapılmadan açılmış dil versiyonlarıydı.
Karar kuralı
Bir dili "açmak" çeviri yapmadan yapılırsa, o dil kopya içerik üretir ve mevcut dillerin işine de yaramaz. Yeni dil yayına alma eşiği şu olmalı: o dilde gövde, kaynak dilin normalize kelime sayısının en az %85'i. Altındaysa yayına almayın; yayına almadığınız dil için hreflang de yazmayın (bkz. 3. bölüm).
12. Yapay zekâ araması: temizlikten sonra gelen iş
Buraya kadarki on bir maddeyi kapatmadan bu bölüme geçmeyin. Yapay zekâ araması ayrı bir kanal değil, aynı indeksin üstüne kurulmuş bir katman; alt katman bozuksa üst katman da bozuk çalışır.
Rakamlar şunu söylüyor. BrightEdge'in Şubat 2025 – Şubat 2026 arası takibine göre yapay zekâ özetleri izlenen sorguların yaklaşık %48'inde görünüyor (bir yıl önce ~%30 idi); sorguların yaklaşık yarısında hâlâ hiç özet çıkmıyor. Seer Interactive'in Şubat 2026 ölçümünde, özet çıkan sorgularda organik tıklama oranı %2,4, özet çıkmayanlarda %3,8. Pew Research'ün 900 kişilik ABD panelinde (Mart 2025, 68.879 arama) yapay zekâ özeti görülen ziyaretlerin %8'inde klasik bir sonuç linkine tıklanmış; özet görülmeyenlerde bu oran %15. Özetin içindeki bir linke tıklama oranı ise yalnızca %1.
Seyahat için asıl kritik rakam şu: BrightEdge verisine göre seyahat sorgularındaki yapay zekâ özeti alıntılarının yalnızca %17,7'si organik ilk 10 sonuçtan geliyor (bir yıl önce %5,7 idi). Yani alıntıların yaklaşık dörtte üçünden fazlası ilk sayfada olmayan kaynaklardan çekiliyor.
Üstte organik tıklama oranı karşılaştırması, altta seyahat sorgularında alıntı kaynaklarının dağılımı. Kaynaklar: Seer Interactive ve BrightEdge, Şubat 2026.
Bu iki rakam bir arada okunduğunda pratik sonuç şu: sıralamada birinci olmak alıntılanmayı garantilemiyor, alıntılanmak da ayrı bir iş. Ve alıntılanmanın ölçülebilir bir karşılığı var — Seer Interactive'in Nisan 2026 ölçümüne göre aynı sorguda alıntılanan markalar, alıntılanmayanlara kıyasla gösterim başına %120 daha fazla organik tıklama alıyor.
Peki ne yapmalı — ve ne yapmamalı
Önce yapmamalı olanı netleştirelim, çünkü bu alanda çok fazla gürültü var.
llms.txt bir çözüm değil. Ahrefs'in 137.000 alan adını kapsayan incelemesinde llms.txt dosyalarının %97'si Mayıs 2026'da hiç istek almadı; geçerli dosyası olan yaklaşık 38.000 alan adının yalnızca ~1.100'üne tek bir istek gelmişti ve o isteklerin %96'sı bot, çoğu da yapay zekâ aracı değil denetim/profil çıkarma araçlarıydı. Google tarafında da durum net: resmî yapay zekâ özellikleri dokümantasyonu "Bu özelliklerde görünmek için yeni makine tarafından okunabilir dosyalar, yapay zekâ metin dosyaları veya işaretleme oluşturmanıza gerek yok" diyor ve ekliyor: "Eklemeniz gereken özel bir schema.org yapısal verisi de yok."
Dosyayı üretmek zararsızdır, ama görünürlük stratejiniz onun üstüne kurulamaz. Gerçekten işe yarayan dört şey var:
- Her sayfada makine tarafından temiz alınabilecek bir cevap paragrafı. Başlığın hemen altında, 40-60 kelimelik, tanımlayıcı ve kendi başına anlamlı. "Bu yazıda ele alacağız" cümleleri alıntılanamaz; "Void, biletlemeden sonra biletin hiç kesilmemiş sayılmasıdır ve yalnızca tedarikçinin tanımladığı pencere içinde mümkündür" cümlesi alıntılanabilir.
- Doğrulanabilir rakam ve kaynak. Kurum adı + yıl içeren bir rakam, kaynaksız bir iddiadan hem insan hem makine için daha değerlidir. Kaynağını veremeyeceğiniz rakamı yazmayın; niteliksel anlatın.
- Standart yapısal veri, doğru kurulmuş. Özel bir şema aramayın;
Organization,BreadcrumbList,FAQPagegibi standart tipleri doğru ve tutarlı doldurun. Denetimde bulduğumuz iki tipik hata: kuruluş logosunun var olmayan bir dosyayı göstermesi (arama motoru logoyu çekemeyince yayıncı görselini tamamen düşürür) ve üst kırılım verisinin yanlış kategoriyi göstermesi. - Tekil içerik, gerçekten çevrilmiş. Yedi dilde aynı gövdeye sahip 67 adresin hiçbiri alıntılanabilir değildi.
Snippet kontrolleri de burada geçerli: Google, nosnippet, data-nosnippet ve noindex'in yapay zekâ özellikleri için de çalıştığını belirtiyor. Yani bir bölümün özetlerde kullanılmasını istemiyorsanız aracınız zaten var.
13. Yirmi maddelik teknik görünürlük kontrol listesi
Tarayıcı ve curl dışında araç gerektirmez. Her maddede beklenen sonuç yazılı.
| # | Kontrol | Beklenen sonuç |
|---|---|---|
| 1 | www'suz host istenir | 301 → www'lu hâl (ya da tersi, tutarlı) |
| 2 | Sondaki eğik çizgili hâl istenir | 301 → tek biçime |
| 3 | Kök adres istenir | Tek adımda 301, dile bakmadan |
| 4 | Rastgele 10 sayfada canonical sayılır | Her sayfada tam olarak 1 tane |
| 5 | Canonical değeri sayfanın kendi adresi mi | Evet, host ve eğik çizgi dahil |
| 6 | Ürün/blog sayfasında hreflang kümesi | Yalnız gerçek çevirisi olan diller |
| 7 | Her hreflang hedefi tek tek istenir | Hepsi 200 ve gerçek içerik |
| 8 | Her hedef geri işaret ediyor mu | Evet, karşılıklı |
| 9 | Dil kodları ISO 639-1 mi | Evet; bölge tek başına yazılmamış |
| 10 | Olmayan bir adres uydurulup istenir | 404 (200 + "bulunamadı" değil) |
| 11 | Latin dışı slug ham ve kodlu istenir | İki biçim de aynı kodu döner |
| 12 | Sitemap host'u kanonik host mu | Evet |
| 13 | Sitemap'ten 10 adres örneklenir | Hepsi 200 ve HTML |
| 14 | lastmod değerleri incelenir |
Birbirinden farklı, gerçek tarihler |
| 15 | robots.txt grupları okunur | Kural her grupta ayrıca yazılı |
| 16 | Dile göre değişen yanıtta Vary |
Var; ya da yanıt dile bağlı değil |
| 17 | Yönlendirme hedefleri örneklenir | Hepsi kanonik ve 200 |
| 18 | Sitemap − iç bağlantı grafiği farkı | Boş küme (orphan yok) |
| 19 | Menü ve kırılım bağlantıları taranır | Hiçbiri 404 dönmüyor |
| 20 | Yayın sonrası ölçüm sırası | Yayınla → önbellek temizle → ölç |
14. Denetim takvimi
Bu işi bir kereye mahsus bir proje olarak kurarsanız altı ay içinde geri gelir. Ölçtüğümüz sitede bozulmanın tek sebebi ihmal değildi; her yeni sayfa şablonu kendi varyantını ürettiği için sistem kendiliğinden sapıyordu.
| Sıklık | İş | Neden |
|---|---|---|
| Her yayında | 1-5, 10, 20. maddeler | Yeni şablon eski kuralı bilmez |
| Haftalık | 7, 8, 19. maddeler | Çeviri ve içerik ekleri kümeyi bozar |
| Aylık | 12-14, 18. maddeler | Sitemap ile gerçek yavaşça ayrışır |
| Üç aylık | 6, 9, 11, 15-17 | Altyapı ve yönlendirme tablosu değişir |
Kaynaklar
- Google Search Central — Yerelleştirilmiş sayfa sürümleri (hreflang)
- Google Search Central — Yinelenen URL'leri birleştirme (canonical)
- Google Search Central — HTTP durum kodları ve soft 404
- Google Search Central — URL yapısı en iyi uygulamaları
- Google Search Central — Yapay zekâ özellikleri ve siteniz
- IETF — RFC 9309: Robots Exclusion Protocol
- MDN Web Docs — Vary başlığı
- BrightEdge — AI Overviews at the One-Year Mark: Presence, Size, and What They're Citing (Şubat 2026)
- Seer Interactive verisi, ALM Corp aktarımı — Google AI Overviews and Organic CTR in 2026
- Seer Interactive verisi, Omnibound aktarımı — Google AI Overviews Statistics (Nisan 2026)
- Pew Research Center — Google users are less likely to click on links when an AI summary appears
- Ahrefs — We Analyzed 137K Sites: 97% of llms.txt Files Never Get Read (Haziran 2026)
Kaynağı belirtilmeyen tüm ölçümler (1.088 sayfa, 921 eksik canonical, 1.469 → 1.386 sitemap, 49 orphan, 70 kırık bağlantı, 329 kanonik olmayan yönlendirme hedefi, dil katsayıları) yedi dilli bir seyahat yazılımı sitesinde Temmuz 2026'da yürütülen kendi denetimimize aittir.
Sıkça Sorulan Sorular
Canonical etiketi tam olarak ne işe yarar?
Aynı ya da çok benzer içeriğe sahip birden fazla adres varsa, hangisinin "asıl" sayılması gerektiğini arama motoruna bildirir. Ancak bu bir emir değil, Google'ın kendi ifadesiyle güçlü bir sinyaldir; nihai kararı arama motoru verir. Kalıcı olarak kapatmak istediğiniz adresler için canonical yerine 301 yönlendirme kullanın — yönlendirme daha güçlü bir sinyaldir.
www'lu ve www'suz adresin ikisinin de açık olması neden sorun?
Çünkü teknik olarak bunlar iki farklı sitedir. İkisi de 200 dönüyorsa her sayfanız iki kez erişilebilir hâle gelir; gelen bağlantılar, tıklama verisi ve tarama bütçesi ikiye bölünür. Birini seçip diğerinden 301 ile yönlendirin, sitemap ve iç bağlantılar da seçtiğiniz hâli kullansın.
hreflang'i her dile aynı slug ile yazabilir miyim?
Yalnızca o slug gerçekten o dilde çalışıyorsa. Google hreflang'i karşılıklı olma şartına bağlar: iki sayfa birbirini göstermiyorsa etiketler yok sayılabilir. Çevirisi olmayan bir dil için hreflang yazmak, arama motoruna var olmayan bir sayfa ilan etmek demektir. Eksik hreflang, yanlış hreflang'den daha iyidir.
Soft 404 nedir, nasıl fark edilir?
İçeriğin bir hata mesajı olduğu hâlde sunucunun 200 başarı kodu döndürmesidir. Fark etmenin en hızlı yolu, sitenizde var olmayan bir adres uydurup istemek: dönen kod 404 değilse soft 404'ünüz var demektir. Search Console'un indeksleme raporu da bu sayfaları ayrı bir kategoride listeler.
Arapça veya Rusça karakterli adresler neden bazen 404 dönüyor?
Tarayıcı bu karakterleri yüzde-kodlayarak gönderir; sunucu bu kodlamayı çözmüyorsa adres bulunamaz. Ham hâli test edildiğinde çalıştığı için sorun uzun süre gizli kalabilir. Kontrol yöntemi, aynı adresi hem ham hem yüzde-kodlu biçimde istemek ve iki yanıtın aynı durum kodunu döndürdüğünü doğrulamaktır.
Yapay zekâ özetleri yayımlandığından beri organik trafiğim neden düştü?
Ölçümler yapısal bir fark gösteriyor: Seer Interactive'in Şubat 2026 verisinde özet çıkan sorgularda organik tıklama oranı %2,4, çıkmayanlarda %3,8. Pew Research'ün panelinde ise özet görülen aramalarda sonuç linkine tıklama oranı %8, görülmeyenlerde %15. Yani aynı sıralamada kalsanız bile özet çıkan sorgularda daha az tıklama alırsınız; hedef, o özet içinde alıntılanmak olmalıdır.
llms.txt dosyası oluşturmalı mıyım?
Zararı yok ama görünürlük planınızı buna dayandırmayın. Ahrefs'in 137.000 alan adı üzerindeki incelemesinde bu dosyaların %97'si Mayıs 2026'da hiç istek almadı. Google da resmî dokümantasyonunda yapay zekâ özelliklerinde görünmek için yeni makine okunabilir dosya, işaretleme veya özel yapısal veri gerekmediğini açıkça belirtiyor.
Denetimi hangi sıklıkla tekrarlamalıyım?
Bir kerelik proje olarak kurgularsanız birkaç ay içinde bozulur, çünkü her yeni sayfa şablonu kendi adres varyantını üretme eğilimindedir. Pratik bir düzen: adres ve canonical kontrollerini her yayında, hreflang ve iç bağlantı kontrollerini haftalık, sitemap ve orphan analizini aylık, altyapı kontrollerini üç ayda bir çalıştırmak.
Yarın sabah yapabileceğiniz beş şey
- Beş varyant testini çalıştırın. En çok trafik alan üç sayfanız için www'lu/www'suz, eğik çizgili/çizgisiz ve varsa eski yol hâlini isteyin; dönen kodları bir tabloya yazın. Birden fazla 200 varsa ilk işiniz belli.
- On sayfada canonical sayın. Sayfa kaynağında kaç
rel="canonical"var ve değeri sayfanın kendi adresi mi? Sıfır ya da birden fazla çıkan her sayfa bir bulgu. - Bir yazının tüm hreflang hedeflerini tek tek isteyin. Hepsi 200 mü, gövdeleri gerçek içerik mi, geri işaret ediyorlar mı? Karşılığı olmayan dil varsa o satırı kaldırın — bu, tek başına en hızlı kazanç.
- Var olmayan bir adres uydurup isteyin. 404 gelmiyorsa soft 404'ünüz var; bu bir düzeltmeyle görünmeyen birkaç arıza birden ortaya çıkar.
- Sitemap'ten on adres örnekleyin. Host doğru mu, hepsi 200 ve HTML mi,
lastmoddeğerleri gerçek mi? Sitemap gerçeği bildirmiyorsa geri kalan her ölçümünüz de yanlış temele oturur.