Asansör arıza kayıtlarının AI yanıtlarında kaynak olarak gösterilmesi, kayıtların erişilebilir ve makine tarafından okunabilir biçimde yayımlanmasına bağlı bir olasılık demektir. ChatGPT, Gemini, Perplexity ve Google AI gibi sistemler bir sayfayı değerlendirirken önce içeriğe erişir, ardından metni ayrıştırıp soruyla ilgili somut veri arar. Tarih, arıza kodu ve çözüm süresi gibi alanların düz metin olarak sunulması ve uygun yapısal veriyle işaretlenmesi bu süreci kolaylaştırır; ancak robots.txt veya llms.txt izinleri belirleyici olmaya devam eder.
Sorunun kısa yanıtı
Kısa yanıt: Evet, ancak koşullu olarak. Asansör bakım firmalarının tuttuğu arıza ve müdahale kayıtları, sayfada erişilebilir metin ve yapısal veri olarak sunulduğunda AI Yanıtlarında kaynak gösterilme olasılığı artar. Kayıtlar yalnızca görsel, PDF içinde gömülü tablo veya giriş gerektiren panel arkasında kalırsa botlar bu veriye erişemez ve atıf üretemez. Yani belirleyici olan kaydın varlığı değil, botun okuyabildiği biçimde yayımlanmış olmasıdır.
AI botları bir sayfayı kaynak göstermek için önce erişir, sonra metni ayrıştırır ve soruyla ilgili somut veri bulup bulmadığını değerlendirir. Tarih, arıza kodu, müdahale süresi gibi alanların düz metin olarak okunabilmesi ve tablo yapısının işaretlenmesi bu değerlendirmeyi kolaylaştırır. Buna karşılık robots.txt veya llms.txt dosyasında bu dizinlere izin verilmemesi, veri seti zengin olsa bile atıf yolunu kapatır.
Asansör bakımı özelinde atıf tercihini etkileyen başlıca unsurlar şunlardır:
- Arıza kaydının tarih, arıza kodu, bina tipi ve çözüm süresi alanlarıyla ayrı ayrı metin olarak yazılması.
- Tablonun Schema.org yapısal verisiyle (örneğin Dataset veya tablo satırlarını tanımlayan işaretlemelerle) desteklenmesi.
- robots.txt içinde ilgili dizinin taranmasına izin verilmesi, llms.txt dosyasında bu veri setinin açıkça listelenmesi.
- Kayıtların sayfa içinde HTML tablo olarak yer alması; yalnızca indirilebilir dosya olarak bırakılmaması.
Bu koşullar sağlandığında firma, “belirli bir arıza kodunda ortalama müdahale süresi nedir” gibi sorularda kaynak olarak gösterilebilir. Ancak atıf garantisi yoktur; botlar kaynak seçimini kendi değerlendirme ölçütlerine göre yapar. Sektörün genel görünürlük çerçevesi için sektör rehberi sayfasına bakabilirsiniz.
Neden böyle oluyor
AI yanıt motorları, bir konuda cümle kurarken en kolay doğrulanabilen ve en net sınırları olan metni tercih eder. Asansör bakım firmalarının arıza kayıtları bu açıdan güçlü bir adaydır: tarih, arıza kodu, müdahale süresi ve çözüm gibi alanlar sayısal ve tekrar eden yapıdadır. Ancak bu kayıtlar sayfada serbest paragraf içinde dağınık duruyorsa, botlar hangi bilginin hangi arızaya ait olduğunu güvenilir biçimde ayıramaz. Kayıt tablo halinde, başlıkları sabit ve metin olarak erişilebilir olduğunda ise alıntılanma olasılığı artar.
Burada belirleyici olan iki teknik katman var. Birincisi yapısal veri: arıza kaydını Service veya Event benzeri şemalarla işaretlemek, botun alanları (tarih, konum, arıza türü, çözüm süresi) ayrı ayrı okumasını sağlar. İkincisi erişim izinleri: robots.txt ve llms.txt dosyalarında bu veri setine izin verilmemesi, içerik ne kadar iyi olursa olsun botun sayfayı taramaması veya alıntılamaması sonucunu doğurur. İzin verilen ama JavaScript ile sonradan yüklenen tablolar ise çoğu tarayıcı botu için görünmez kalır.
Sektöre özgü bir engel de verinin müşteriye ait olmasıdır. Bina adresi, kapıcı telefonu veya sözleşme bedeli gibi alanlar kişisel ve ticari veri sayılır; bunların sayfada açık metin olarak yayınlanması hem gizlilik hem de rekabet açısından risk taşır. Bu nedenle firmalar genellikle kayıtları ya hiç yayınlamaz ya da yalnızca özet istatistik verir. Oysa anonimleştirilmiş arıza kodu, müdahale süresi ve tekrar sıklığı gibi alanlar hem botlar hem de potansiyel müşteriler için değerlidir.
- Arıza kodu ve çözüm süresi tablo halinde, sabit başlıklarla sunulmalı.
- Kayıtlar HTML içinde statik metin olarak yer almalı, JavaScript ile yüklenmemeli.
- robots.txt ve llms.txt dosyalarında ilgili dizine açık izin tanımlanmalı.
- Müşteri kimliği ve adres bilgisi anonimleştirilerek yayınlanmalı.
Nasıl uygulanır
Asansör bakım firmasının arıza kayıtlarını AI botlarının okuyabileceği biçimde sunması üç adımda ilerler: veriyi seçmek, sayfada yapısal ve erişilebilir hale getirmek, ardından tarayıcı izinlerini bu veri setine göre ayarlamak. İlk adımda her kayıt için tarih, bina tipi (konut, ofis, hastane), asansör markası ve modeli, arıza kodu, belirti, yapılan müdahale ve çözüm süresi alanlarını standartlaştırın. Müşteri adı, adres ve telefon gibi kişisel verileri bu setten çıkarın; kayıtları bina kimliği yerine anonim bir referans numarasıyla yayınlayın.
İkinci adımda her arıza kaydını ayrı bir URL üzerinde erişilebilir metin olarak yayınlayın ve sayfaya JSON-LD ekleyin. Kayıt sayfasında Article veya TechArticle şeması kullanın; arıza kodunu, müdahale tarihini ve çözüm süresini about, datePublished ve metin içinde açıkça belirtin. Tablo halinde özet veriyorsanız Dataset şemasıyla veri setinin kapsamını, güncelleme sıklığını ve lisansını tanımlayın. Aşağıdaki alanlar sayfada hem görünür metin hem de yapısal veri olarak yer almalıdır:
- Arıza kodu ve kısa tanımı (örneğin kapı sensörü hatası, kat hizalama sapması)
- Müdahale tarihi ve varsa tekrar eden arıza bilgisi
- Çözüm süresi (saat cinsinden) ve kullanılan yedek parça sınıfı
- Bakım periyodu ve sözleşme tipi (tam kapsam, kısmi kapsam)
Üçüncü adımda robots.txt dosyasında arıza kayıt dizinine AI tarayıcıları için açık izin verin; GPTBot, ClaudeBot, PerplexityBot ve Google-Extended gibi kullanıcı aracılarını ayrı satırlarda tanımlayın. llms.txt dosyasında arıza kayıtları arşivinin giriş URL’sini, veri setinin kapsamını ve güncelleme tarihini kısa maddelerle belirtin. Sayfa içi bağlantılarla arıza kayıtlarını sektör rehberi ve bakım hizmeti sayfalarına bağlayın; böylece botlar kayıtları firmanın uzmanlık bağlamıyla birlikte değerlendirebilir.
Erişim izinleri: robots.txt ve llms.txt
Asansör arıza kayıtlarının AI yanıtlarında kaynak olarak görünmesi, önce botların bu sayfalara erişebilmesine bağlıdır. Bakım firmalarının arıza ve müdahale kayıtlarını yayınladığı sayfalar çoğu zaman yönetim paneli arkasında ya da giriş gerektiren bir alanda tutulur; bu durumda arama motoru botları da AI tarayıcıları da içeriği okuyamaz. Kayıtların herkese açık bir arşiv sayfasında, tarih, arıza kodu ve çözüm süresi alanlarıyla birlikte düz metin olarak yer alması gerekir. Robots.txt dosyasında bu arşiv yolunun Disallow ile kapatılmamış olması, sayfanın indekslenebilir kalmasını sağlar. Sık görülen bir hata, test veya staging ortamındaki kuralın canlı siteye taşınması ve arıza arşivinin yanlışlıkla taranmaya kapatılmasıdır.
llms.txt dosyası ise AI botlarına sitenin hangi bölümlerinin güvenilir kaynak olarak kullanılabileceğini bildiren bir yol haritası işlevi görür. Asansör bakımı sitesinde bu dosyaya arıza arşivi, bakım periyodu açıklamaları ve müdahale süresi tanımlarının yer aldığı sayfaların adresleri eklenmelidir. Böylece model, hangi veri setinin güncel ve yapılandırılmış olduğunu daha kolay ayırt eder.
Erişim izinleri belirlenirken şu noktalar kontrol edilmelidir:
- Arıza arşivi sayfası robots.txt içinde taranabilir durumda mı, yalnızca yönetim paneli yolları kapalı mı?
- llms.txt dosyası site kökünde erişilebilir mi ve arşiv sayfasının tam adresini içeriyor mu?
- Kayıt sayfaları giriş duvarı arkasında değil, herkese açık HTML olarak mı sunuluyor?
- Sayfa içeriği JavaScript ile sonradan yükleniyorsa, botların görebildiği sunucu tarafı metin mevcut mu?
- Arıza kodu ve çözüm süresi alanları tablo veya yapısal veri içinde açıkça etiketlenmiş mi?
Bu izinler, kayıtların AI yanıtlarında kaynak gösterilmesini tek başına sağlamaz; ancak erişim engeli varsa diğer tüm çalışmalar sonuçsuz kalır. Sektörün genel yaklaşımı için sektör rehberi sayfasına bakabilirsiniz.
Nasıl ölçülür
Asansör arıza kayıtlarının AI yanıtlarında kaynak olarak görünüp görünmediğini ölçmek için önce bir başlangıç (baseline) seti oluşturun. Bakım sözleşmesi kapsamındaki bina tiplerine göre (konut, ofis, hastane, AVM) 10-15 tipik soru belirleyin: “asansör kat arasında kalırsa ne yapılır”, “kapı sensörü arızası nasıl anlaşılır”, “asansör kurtarma süresi ne olmalı” gibi. Bu soruları ayda bir aynı gün ve aynı tarayıcı oturumunda ChatGPT, Gemini, Perplexity ve Copilot üzerinde sorun; yanıtta sitenizin adı, arıza kodu sayfası veya müdahale süresi tablosu geçiyor mu kaydedin.
Ölçümü üç katmanda tutun: atıf varlığı, atıf türü ve trafik yansıması. Atıf varlığında yanıtın kaynak listesinde alan adınızın görünmesini; atıf türünde ise yanıtın genel bilgi mi yoksa sizin yayımladığınız arıza kodu ve çözüm süresi verisine dayalı mı olduğunu işaretleyin. Trafik tarafında sunucu günlüklerinde GPTBot, ClaudeBot, PerplexityBot ve Google-Extended user-agent’larının arıza kaydı sayfalarına yaptığı istekleri haftalık sayın. Bu botların sayfayı çekip çekmediği, robots.txt ve llms.txt izinlerinin doğru çalıştığının da göstergesidir.
| Metrik | Ölçüm yöntemi | Hedef eğilim |
|---|---|---|
| Kaynakta görünme oranı | Aylık soru setinde alan adının geçtiği yanıt sayısı / toplam soru | Dönem içinde artış |
| Veriye dayalı atıf | Yanıtta arıza kodu veya çözüm süresi tablosuna atıf | Artış |
| Bot erişimi | Sunucu günlüğünde AI bot istekleri (arıza sayfaları) | İzinli botlarda düzenli erişim |
| Yapısal veri geçerliliği | Schema.org doğrulama aracı hataları | Sıfır kritik hata |
Son olarak, arıza kaydı sayfalarında yaptığınız her değişikliği (yeni arıza kodu, tablo güncellemesi, llms.txt düzenlemesi) tarihli bir değişiklik günlüğüne yazın. Ölçüm sonuçlarını bu günlükle eşleştirmeden yorumlamayın; aksi halde atıf artışının içerik güncellemesinden mi yoksa bot erişim izninden mi kaynaklandığı ayırt edilemez. Sektöre özel ölçüm çerçevesi için sektör rehberi sayfasındaki tanımları esas alın.
Sık yapılan hatalar
Asansör bakım firmalarının arıza kayıtlarını yayına hazırlarken en sık düştüğü hata, veriyi yalnızca görsel bir tabloya veya PDF dosyasına gömmektir. AI botları bir sayfayı tararken metin katmanı olmayan PDF içeriğini ve JavaScript ile sonradan yüklenen tablo satırlarını güvenilir biçimde okuyamaz. Aynı kayıtların HTML tablosu, açıklama metni ve yapısal veri olarak da sunulmaması, sayfanın kaynak olarak değerlendirilme ihtimalini düşürür.
Sık görülen bir diğer hata, arıza kodlarının yalnızca firma içi kısaltmalarla verilmesidir. “K-17” gibi bir kod, sayfada “kapı kilit kontağı arızası” gibi açık bir karşılıkla eşleştirilmediğinde botlar bu ifadeyi sektörel bir bilgi olarak yorumlayamaz. Benzer şekilde çözüm süresinin “hızlı giderildi” gibi öznel ifadelerle geçiştirilmesi, ölçülebilir veri beklentisini karşılamaz.
Teknik tarafta yapılan hatalar şunlardır:
- robots.txt dosyasında tüm botları engelleyen genel bir kural bırakıp arıza kaydı sayfalarının da erişim dışında kalması.
- llms.txt dosyasını hiç oluşturmamak veya oluşturup arıza kaydı dizinini listeye eklememek.
- Yapısal veride tarih alanlarını ISO 8601 dışında, “12.03.24” gibi belirsiz biçimde vermek.
- Aynı arıza kaydını hem /ariza/ hem /bakim-raporu/ altında yayınlayıp kopya içerik oluşturmak.
- Sayfa başlığında ve H1 etiketinde arıza türünü değil yalnızca firma adını kullanmak.
Son olarak, kayıtların müşteri adı, bina adresi veya tesisat numarası gibi kimlik belirtici bilgilerle birlikte yayınlanması hem gizlilik hem de veri kalitesi açısından sorun yaratır. AI yanıtlarında kaynak gösterilmek istenen bir veri seti, kişisel veriden arındırılmış, tutarlı ve makine tarafından okunabilir olmalıdır. Sektöre özel yayın çerçevesi için sektör rehberi sayfasındaki önerilere bakabilirsiniz.
Sektör için kontrol listesi
Asansör bakım firmalarının arıza kayıtlarını AI yanıtlarında kaynak olarak gösterebilmesi için önce bu verinin botlar tarafından okunabilir olması gerekir. Aşağıdaki liste, bakım firmalarının kendi sitelerinde uygulayabileceği somut adımları içerir. Kontrol listesini sektör rehberi ile birlikte kullanmanız, hem içerik hem teknik tarafta tutarlılık sağlar.
- Arıza kayıtlarını sayfada erişilebilir metin olarak yayınlayın; görsel içine gömülü tablo veya yalnızca PDF içindeki veri botlar tarafından güvenilir biçimde okunmaz.
- Her kayıt için tarih, arıza kodu, müdahale süresi ve çözüm açıklamasını ayrı alanlar halinde verin; serbest metin yerine yapılandırılmış başlıklar kullanın.
- Sayfaya JSON-LD ile yapısal veri ekleyin; arıza kaydını uygun şemayla (örneğin teknik servis kaydı niteliğinde) tanımlayın ve sayfadaki görünür metinle birebir eşleştirin.
- robots.txt dosyasında AI botları için erişim iznini açıkça belirtin; hangi dizinlerin taranabileceğini ve hangilerinin kapalı olduğunu netleştirin.
- llms.txt dosyası ekleyerek arıza kayıtları sayfasının konumunu, güncelleme sıklığını ve veri kapsamını kısa biçimde tanımlayın.
- Kayıt sayfalarında son güncelleme tarihini görünür biçimde belirtin; botların güncellik değerlendirmesi için bu bilgi kritik.
- Arıza kodu sözlüğü oluşturun; kodların ne anlama geldiğini ayrı bir sayfada açıklayın ve kayıt sayfalarından bu sözlüğe bağlantı verin.
- Müşteri ve bina bilgilerini anonimleştirin; kişisel veri içeren kayıtların yayınlanması hem mevzuat hem güven açısından risk oluşturur.
Ölçüm tarafında, arıza kayıtları sayfasına gelen bot isteklerini sunucu günlüklerinde ayrı takip edin. Hangi AI botlarının hangi kayıt sayfalarını çektiğini ve yapısal veriyi talep edip etmediğini düzenli olarak kontrol edin. Sayfa bazında taranma sıklığı ile güncelleme sıklığı arasındaki ilişkiyi izlemek, hangi kayıtların kaynak olarak öne çıktığını anlamanıza yardımcı olur.
Son olarak, arıza kayıtlarını yalnızca pazarlama metni olarak değil, tekrar eden ve karşılaştırılabilir bir veri seti olarak sunun. Aynı arıza kodunun farklı binalardaki müdahale sürelerini tablo halinde göstermek, AI yanıtlarında alıntılanma olasılığını artıran somut bir adımdır.
Sık sorulan sorular
Arıza kayıtlarını yayınlamak müşteri gizliliği açısından risk oluşturur mu?
Kayıtlar yayınlanırken bina adresi, iletişim bilgisi ve kişisel veri çıkarılmalıdır. Arıza kodu, tarih ve çözüm süresi gibi teknik alanlar anonimleştirilerek sunulabilir. Yayın öncesi veri minimizasyonu ve hukuki kontrol yapılması önerilir.
Yapısal veri eklemek tek başına AI atıfını sağlar mı?
Hayır, tek başına yeterli değildir. Yapısal veri, içeriğin makine tarafından anlaşılmasını kolaylaştırır; ancak erişilebilir metin, güncellik ve konu bütünlüğü de gerekir. Bu unsurlar birlikte değerlendirilmelidir.
llms.txt dosyası zorunlu mu?
Zorunlu değildir ve standart bir yapı değildir. Yine de botlara hangi içeriğin izinli olduğunu açıklamak için ek bir sinyal olarak kullanılabilir. Tek başına erişim kararı vermez, robots.txt ile birlikte düşünülmelidir.
Atıf etkisini hangi göstergelerle izleyebilirim?
AI yanıtlarında marka ve sayfa bağlantısının görünme sıklığı, yönlendirme trafiği ve arama konsolu verileri birlikte izlenebilir. Düzenli aralıklarla karşılaştırma yapmak, değişimin yönünü görmeyi kolaylaştırır.
Bu konunun ayrintilari sektor rehberi sayfasinda adim adim anlatiliyor.
Pixenon SEO, GEO/AEO, AI gorunurluk ve programatik SEO hizmetlerini tek catida yurutur. Sitenizin mevcut durumunu gormek icin ucretsiz analiz talep edebilirsiniz.
İlgili kaynak: dijital ölçüm ve analitik çözümleri.
