Bir bayi ağında müşteri şöyle soruyor: “Antalya’da yetkili bayi nerede?” Bu soruyu ChatGPT’ye, Gemini’ye ya da Google’ın yapay zekâ özetine yazıyor ve cevabın altındaki bağlantıya tıklıyor. Sorun şu: bağlantı merkez sitenin ana sayfası mı çıkıyor, yoksa Antalya’daki bayinin kendi sitesi mi?
Bu yazı, o bağlantının doğru yere gidebilmesi için bayi ağına özgü ne yapmak gerektiğini anlatıyor. Genel yapay zekâ görünürlüğünü, yani dizin, tarayıcı izni ve alıntılanabilir cümleyi yapay zekâ aramalarında görünmek yazısında anlattık; llms.txt’nin ne olduğunu da llms.txt nedir yazısında. Burada onları tekrarlamayacağım. Konumuz tek bir ayrım: merkezle bayinin aynı markayı değil, farklı işletmeleri anlattığı.
Bayi ağında yapay zekâ kimi gösterir?
Yapay zekâ şehir sorusuna cevap verecekse önce bayinin kim olduğunu ve nerede olduğunu bilmek zorundadır. Bunu bilmiyorsa markanın genel sayfasını koyar ve bayiyi atlar. Ben bayi ağlarında en sık gördüğüm eksiği şöyle özetlerim: merkez sitesi markayı iyi anlatıyor, ama hiçbir bayi kendi adresini makineye açıkça söylemiyor.
Burada iki işletme var ve ikisi de ayrı işaretlenmeli. Merkez, markanın kurumsal kimliğidir. Bayi ise adresi, telefonu ve çalışma saatleri olan yerel bir işletmedir. Model bu ikisini karıştırırsa bayinin adresini markanın genel merkeziyle eşleştirir ya da bayiyi hiç çıkarmaz.
Merkez sitede marka ve kurum bilgisi nasıl işaretlenir?
Merkez sitede işaretlenmesi gereken şey markanın kendisidir: kim olduğu, hangi hizmetleri verdiği, hangi sayfanın hangi soruyu cevapladığı. XPEL Türkiye merkez sitesinde Organization, Brand, WebSite ve FAQPage düğümleri ile hizmet ve teklif kayıtları bu amaçla kullanılıyor. Bunların hiçbiri tek bir bayinin adresini taşımıyor.
Burada sık yapılan bir hata var. Bayi kartlarını merkezin Organization kaydının içine gömmek, tek sayfadan ağın tamamını anlatmak gibi gelir. Ben bunu önermem. Bayi ayrı bir işletmedir ve kendi kaydıyla anlatılmalıdır. Merkez sayfası bayi dizinine bağlantı verir, dizin her bayiye kendi sayfasına giden bir yol açar, bayi sayfası da kendi adresini söyler. Zincirin her halkası kendi işini yapar.
Bayi sitesinde adresli kayıt neden ayrı olmalı?
Bayi sitesinin şeması, o bayinin fiziksel varlığını anlatmalı: adres, çalışma saatleri, telefon. XPEL Türkiye’nin bayi sitelerinde bu, adres ve çalışma saatli bir AutomotiveBusiness kaydı olarak yazılıyor; sayfadaki SSS bölümü de aynı işletmeyi anlatıyor. Solar Gard ağında her bayi sitesi kendi şehrine göre yerelleştiriliyor ve bayi sitelerine merkeze ait iletişim bilgisi sızmıyor.
Aşağıdaki tablo iki sitenin ne anlattığını ayırıyor:
| Sayfa | Şema türü | Anlattığı | Taşımadığı |
|---|---|---|---|
| Merkez site | Organization, Brand, WebSite | Markanın kim olduğu, hizmetler, bayi dizini | Tek bir bayinin adresi |
| Bayi sitesi | AutomotiveBusiness (adresli) | Bayinin adresi, saatleri, hizmet kapsamı | Merkezin telefonu ve WhatsApp hattı |
Bayi sitesindeki SSS bölümü de bu işin parçası. Orada bayiye gerçekten sorulan soruları yazın: çalışma saati, hangi hizmetler, hangi araçlar için çalışılıyor, randevu nasıl alınıyor. Bu cevaplar bayinin kendi sayfasından geldiği için merkezin genel bir cümlesinden daha güçlü bir kaynak olur.
Şemaya sayfada görünmeyen bir bilgi de yazılmamalı. Sayfada yoksa şemada da olmamalı; aksi halde model iki kaynağın çeliştiğini görür ve bayiye güvenmez.
llms.txt ağda ne işe yarar?
llms.txt, bir dil modeline siteyi özetleyen kısa bir giriş dosyasıdır. Bayi ağında bu dosya, o sitenin hangi işletme olduğunu ve merkeze nasıl bağlandığını söylemeli. XPEL’in üç sitesinin üçünde de llms.txt var; bayi sitelerindeki dosya kendi bayisini anlatıyor.
Ben her bayiye uzun bir llms.txt yazılmasını önermem. Bayinin adı, adresi, hizmet kapsamı ve merkeze bağlantısı yeter. Ürün kataloğu ya da tam metin merkezde kalsın. Dosyanın bir sıralama sinyali olmadığını da unutmamak gerekiyor; Google, AI özetleri için böyle bir dosya gerektirmediğini kendi dokümanında yazıyor. Ağda llms.txt’nin işi, bir modelin bayiyi yanlış bir ilçeyle karıştırmasını önlemek. Bu da dosyadaki özet cümlenin ne kadar net yazıldığına bağlı.
Tek kod tabanında bu işi kim yürütür?
Ağ büyüdükçe bu işaretlemeyi elle sürdürmek en çok unutulan işe dönüşür. Bayi eklenir, adresi değişir, telefonu yenilenir; şema ve llms.txt bir yerde eski kalır. Bu yüzden şemanın, llms.txt’nin ve site haritasının aynı yapılandırma dosyasından üretilmesi gerekiyor.
Solar Gard ağında yeni bir bayi yapılandırma dosyasıyla eklenip yayına alınıyor ve ortak katmandaki bir düzeltme sekiz siteye birlikte gidiyor. XPEL’de ise her site kendi Cloudflare Pages projesinde yayında; yani aynı düzeltme üç siteye ayrı ayrı gönderiliyor. Bence bu işte en kolay aksayan yer yayın adımıdır. Yayına almayı unutulan bir bayi, en güzel şemaya sahip olsa da ağın dışında kalır.
Bayi ağdan ayrıldığında da aynı disiplin geçerli. Sitesini bir gecede kapatmak, o adrese yapılmış bağlantıları ve modelin hafızasındaki eski adresi kırar. Solar Gard’da eski adresler için 301 yönlendirme haritası otomatik çıkarılıyor; ayrılan bir bayinin adresi de merkez dizinine yönlenirse, ziyaretçi ve model aynı yere gider. Bu, yapılandırma dosyasının neden tek kaynak olması gerektiğinin bir başka nedeni.
Yanlış bayi eşleşmesi nasıl görülür?
Görünürlüğü ölçmenin en basit yolu, şehir sorusunu kendiniz sormaktır. Ayda bir, her önemli şehir için “[şehir] yetkili [marka] bayisi nerede?” sorusunu ChatGPT, Gemini ve Copilot’a sorun. Cevapta hangi adresin çıktığına bakın. Komşu ilçedeki bayinin adresi karıştırılmış mı, bayi yanlış ilde mi gösterilmiş, yoksa hiç çıkmamış mı, bir deftere yazın.
Yanlış eşleşmenin iki tipik kaynağı var. Birincisi, iki bayinin adresinin aynı sayfada ya da aynı dizin satırında geçmesi. İkincisi, llms.txt’teki özet cümlenin belirsiz olması. Örneğin “Türkiye genelinde hizmet veriyoruz” yazan bir özet, modelin bayiyi hangi şehirle eşleştireceğini söylemez. Bayi adı ve şehir aynı cümlede olmalı.
Bu kontrolün sonucunu bir sonraki düzeltmeye çevirmek gerekiyor. Yanlış cevap bir bayi sayfasında kötü bir cümleden geliyorsa o cümleyi düzeltirsiniz; merkezin dizininden geliyorsa dizindeki etiketi düzeltirsiniz. Her ay aynı soruyu sorup aynı hatayı görüyorsanız, sorun çoğu zaman sayfada değil, veri dosyasındadır.
Bayi kaydı için kontrol listesi
Bir bayi sitesini yapay zekâ görünürlüğü açısından tamam saymadan önce bu sorulara evet diyebilmelisiniz:
- Bayinin adı, adresi ve telefonu sayfada ve şemada aynı mı?
- Çalışma saatleri şemada yazıyor ve sayfada da görünüyor mu?
- Bayi sitesinde merkezin telefonu ya da WhatsApp hattı yok mu?
- robots.txt, OAI-SearchBot ve Google-Extended’ı engellemiyor mu?
- llms.txt’teki bayi bilgisi bu hafta güncel mi?
- Merkezdeki bayi dizini, bu bayinin sayfasına bağlanıyor mu?
Son madde en çok atlanan. Dizin bir bayiyi listeliyor ama sayfası ona bağlı değilse model iki ayrı işletme görür.
Bayi kanalındaki tıklama kimin?
Ağda ölçümün en çok yanlış okunduğu yer, bir tıklamanın kime ait olduğudur. XPEL merkez sitede telefon ve WhatsApp tıklamalarını ayrı bir olay olarak ölçüyor. Dizinden başka bir bayinin kanalına yapılan tıklama ise merkezin dönüşümü sayılmıyor. Bu ayrım baştan kurulmazsa bayilerin ürettiği talep ya merkezin başarısı gibi görünür ya da hiç görünmez.
Yapay zekâ kaynaklı ziyaretler için de aynı dikkat gerekiyor. ChatGPT ya da Copilot’tan gelen ziyaretçi, yönlendiren kaynak olarak analitikte görünür. Bing Webmaster Tools’taki AI Performance raporu da Copilot alıntılarını gösterir. Hangi bayi sayfasının alıntılandığını bu raporlardan okumak, merkez ile bayi arasında hangi cümlenin işe yaradığını görmenin en hızlı yolu.
Başlamak için küçük bir iş yeter: merkez sitede telefon tıklamasının hangi sayfadan geldiğini, bayi sitesinde ise kendi tıklamasının ayrı bir olay olarak ölçüldüğünü bu hafta kontrol edin.
Bu yazıdaki bilgiler XPEL Türkiye ve Solar Gard Türkiye referans sayfalarımızdan alındı.
