Asansör arıza kayıtları AI yanıtlarında kaynak olarak gösterilir mi?

Kisaca: Kısa yanıt: Evet, gösterilebilir; ancak bu bir garanti değil, erişim ve yapı kalitesine bağlı bir olasılıktır. AI botları bir sayfayı kaynak olarak değerlendirirken içeriğin erişilebilirliğine, metnin makine tarafından okunabilir olmasına ve iddiaların somut veriyle desteklenmesine bakar. Asansör bakım firmalarının tuttuğu arıza ve müdahale kayıtları (tarih, arıza kodu, çözüm süresi) bu açıdan güçlü bir adaydır; çünkü özgün, tekrarlanabilir ve doğrulanabilir bilgi içerir. Ancak kayıtlar yalnızca görsel tablo veya indirilebilir dosya olarak sunulursa botlar bu veriyi okuyamaz. Robots ve llms.txt izinleri ise erişimin ön koşuludur: botların sayfaya girmesine izin verilmiyorsa içerik ne kadar iyi olursa olsun atıf üretilmez. Bu yazıda kayıtların yapısal veri ve erişilebilir metin olarak nasıl sunulacağını, izinlerin bu veri setini nasıl şekillendirdiğini ve etkinin nasıl ölçüleceğini adım adım ele alıyoruz. Sektörünüze özel bağlam için sektör rehberi sayfamıza göz atabilirsiniz.

Sorunun kısa yanıtı

Asansör arıza kayıtları, tek başına sayfada durduğunda AI yanıtlarında kaynak olarak gösterilmez. Gösterim için üç koşulun birlikte sağlanması gerekir: kaydın erişilebilir HTML metni olarak yayınlanması, tarih, arıza kodu ve çözüm süresi gibi alanların yapısal veriyle (schema.org) işaretlenmesi ve arama motoru ile AI botlarının bu sayfaya robots.txt ve llms.txt üzerinden erişebilmesi. Bu üçü tamamlandığında kayıtlar, modelin “asansör arıza kodları”, “müdahale süresi” veya “bakım firması deneyimi” gibi sorulara verdiği yanıtlarda atıf adayı haline gelir. Ancak atıf bir garanti değildir; modelin o an hangi kaynağı seçeceği dışarıdan kesin olarak öngörülemez.

Uygulamada en sık görülen eksik, kayıtların yalnızca PDF, Excel veya müşteri portalı arkasında tutulmasıdır. Bu durumda içerik botlar için görünmez kalır ve AI yanıtlarında hiçbir şekilde kaynak olarak yer almaz. Kayıtların herkese açık bir sayfada, arıza kodu, tarih, bina tipi ve ortalama çözüm süresi kolonlarıyla tablo halinde sunulması, hem okunabilirliği hem de alıntılanabilirliği artırır.

• Arıza kaydı sayfası HTML olarak yayınlanmalı, JavaScript ile sonradan yüklenen içerikten kaçınılmalı.
• Her kayıt için tarih, arıza kodu, müdahale süresi ve çözüm özeti ayrı alan olarak verilmeli.
• Tablo başlıkları ve birimler (dakika, saat) açıkça yazılmalı.
• robots.txt içinde ilgili dizin engellenmemeli; llms.txt dosyasında arıza kaydı sayfasının bağlantısı listelenmeli.
• Sayfada firma adı, hizmet bölgesi ve iletişim bilgisi görünür olmalı.

Kısaca: kayıtlar erişilebilir, yapılandırılmış ve izinli olduğunda AI yanıtlarında kaynak olarak gösterilme olasılığı artar. Sektörün genel görünürlük çerçevesi için asansör bakımı sektör rehberi sayfasına bakabilirsiniz.

Neden böyle oluyor

AI yanıt motorları, bir konuda cümle kurarken kaynaklarını çoğunlukla erişilebilir ve yapısal olarak çözümlenebilir sayfalardan seçer. Asansör bakımı özelinde bu durum, arıza kayıtlarının sayfada nasıl sunulduğuna doğrudan bağlıdır. Bir firmanın tuttuğu kayıtlar yalnızca PDF içinde, görsel tablo halinde veya giriş gerektiren panelde kalıyorsa, botlar bu veriyi okuyamaz; dolayısıyla yanıtta kaynak olarak gösterilmesi de beklenmez. Buna karşılık tarih, arıza kodu, müdahale süresi gibi alanlar HTML tablosu veya tanımlı liste olarak açık metin halinde yayımlandığında, modelin bu veriyi alıntılaması ve özetlemesi kolaylaşır.

İkinci belirleyici unsur, erişim izinleridir. robots.txt dosyasında AI tarayıcılarına kapalı bir dizin altında tutulan arıza arşivi, içerik ne kadar iyi yapılandırılmış olursa olsun yanıt üretiminde kullanılmaz. llms.txt gibi dosyalarla hangi bölümlerin özetlenebilir olduğunu bildirmek, botların hangi veri setine yöneleceğini şekillendirir. Asansör bakımında sık görülen bir durum, arıza kodlarının üretici terminolojisiyle (örneğin kapı sensörü, tahrik kayışı, kat seviye hatası) yazılması ama sayfada bu terimlerin açıklamasının bulunmamasıdır. Bot, kodu görse de bağlamı kuramadığında alıntılama eğilimi düşer.

Üçüncü etken, verinin tazeliği ve tutarlılığıdır. Aynı arıza kodu için farklı sayfalarda çelişkili çözüm süreleri yer alıyorsa, model güvenilir kaynak olarak bu sayfayı tercih etmez. Aşağıdaki unsurlar, arıza kayıtlarının AI yanıtlarında kaynak olarak öne çıkmasını doğrudan etkiler:

• Kayıtların HTML tablosu olarak, her satırda tarih, arıza kodu ve çözüm süresi bulunacak şekilde yayımlanması
• Arıza kodlarının kısa açıklamalarla eşleştirilmesi ve terimlerin sayfa metninde geçmesi
• robots.txt ve llms.txt dosyalarında arıza arşivi dizinine açık izin verilmesi
• Sayfa başlığı ve alt başlıkların “asansör arıza kaydı”, “müdahale süresi” gibi arama niyetine uygun olması
• Verinin düzenli güncellenmesi ve eski kayıtların arşiv olarak ayrı tutulması

Bu unsurlar bir arada sağlandığında, botlar sayfayı yalnızca tanıtmakla kalmaz; belirli bir arıza kodu veya ortalama çözüm süresi sorulduğunda bu veri setine atıf yapma olasılığı artar. Sektörün genel görünürlük çerçevesi için sektör rehberi sayfasındaki yapı da bu yaklaşımı destekler.

Nasıl uygulanır

Asansör arıza kayıtlarını AI yanıtlarında kaynak olarak gösterme ihtimalini artırmanın ilk adımı, veriyi sayfada erişilebilir metin haline getirmektir. Bakım firmaları genellikle arıza kayıtlarını kendi yönetim yazılımında tutar; bu verilerin bir kısmı siteye hiç taşınmaz. Oysa AI botları, yalnızca erişebildiği ve okuyabildiği içeriği değerlendirebilir. Bu nedenle her kayıt için tarih, bina veya tesis tipi, arıza kodu, arıza tanımı, müdahale süresi ve uygulanan çözüm gibi alanların açık metin olarak yayınlanması gerekir. Kişisel veri ve müşteri adı paylaşılmadan, anonimleştirilmiş kayıtlar hem güvenli hem de kullanışlıdır.

Sayfa yapısında bu kayıtları tablo veya tanım listesi olarak sunmak, botların alanları ayırt etmesini kolaylaştırır. Aşağıdaki alanlar her kayıtta tutarlı biçimde yer almalıdır:

• Kayıt tarihi ve müdahale tarihi
• Arıza kodu ve kısa tanımı (örneğin kapı sensörü, kat hizası sapması)
• Çözüm süresi (saat veya gün)
• Uygulanan müdahale türü (ayar, parça değişimi, acil servis)
• Bakım periyodu bilgisi

Yapısal veri tarafında tablo içeriğini Schema.org üzerinden işaretlemek, sayfanın ne anlattığını makineye açıklar. Ancak yapısal veri tek başına yeterli değildir; robots.txt ve llms.txt dosyalarında bu kayıt sayfalarına erişim izni verilmelidir. Arıza kayıtları bir alt dizinde toplanıyorsa, ilgili dizinin taranmasına izin verilmeli, sayfaların giriş gerektirmemesi sağlanmalıdır. Giriş duvarı arkasındaki veri, botlar için görünmez kalır.

Son olarak kayıt sayfalarını sektör rehberi gibi ilgili içeriklerle bağlantılandırmak, botların bağlamı anlamasına yardımcı olur. Her arıza kaydı sayfasında kısa bir özet paragraf bulunması, tablo verisinin metin olarak da okunabilmesini sağlar.

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 sabit bir soru seti tanımlayın. Bakım firması olarak hedeflediğiniz aramaları yazılı hale getirin: “asansör kapı arızası neden olur”, “asansör kuyu dibi su alması müdahale süresi”, “asansör 5 yıllık periyodik kontrol arıza kodları” gibi. Her soruyu ayda bir kez aynı gün ve aynı tarayıcı oturumundan, birden fazla AI asistanında çalıştırın. Yanıtın kaynak listesinde alan adınızın görünüp görünmediğini, görünüyorsa hangi sayfanın (arıza kodu sayfası, müdahale süresi tablosu, sektör rehberi) atıf aldığını kaydedin. Bu kayıt, hangi veri setinin gerçekten alıntılandığını gösterir.

Ölçümü üç katmanda tutmanız faydalı olur:

• Erişim katmanı: Sunucu günlüklerinde GPTBot, ClaudeBot, PerplexityBot gibi kullanıcı ajanlarının arıza kaydı sayfalarınıza yaptığı istek sayısı ve durum kodları. 200 dönen istekler, robots.txt ve llms.txt izinlerinin doğru yapılandırıldığını gösterir.
• İçerik katmanı: Yapısal veri doğrulama araçlarıyla arıza kodu, tarih ve çözüm süresi alanlarının hatasız işaretlendiğinin kontrolü. Hatalı şema, atıf ihtimalini düşürür.
• Atıf katmanı: Soru setindeki her sorgu için kaynak gösterilme oranı. Örneğin 20 sorunun 6’sında alan adınızın geçmesi, başlangıç seviyesi olarak not edilir.

Son olarak, atıf alan sayfalardaki arıza kayıtlarının güncelliğini kontrol edin. Eski tarihli ve çözüm süresi belirtilmemiş kayıtlar alıntılanmıyorsa, veri setini tarih, arıza kodu ve müdahale süresi sütunlarıyla yeniden düzenleyin ve ölçümü bir sonraki ay aynı soru setiyle tekrarlayın. Karşılaştırma ancak aynı sorular ve aynı dönem aralığıyla anlamlı olur.

Sık yapılan hatalar

Asansör bakım firmalarının arıza kayıtlarını yayınlarken en sık düştüğü hata, veriyi yalnızca görsel bir tablo veya taranmış PDF içine gömmektir. AI botları bu tür içerikten tarih, arıza kodu ve çözüm süresi gibi alanları güvenilir biçimde ayıklayamaz; sayfa kaynak olarak değerlendirilse bile atıf yapılmaz. Kayıtların HTML tablosu olarak, her satırda ayrı hücreler halinde ve erişilebilir metinle sunulması gerekir.

İkinci yaygın hata, robots.txt ve llms.txt dosyalarının birbirinden habersiz yönetilmesidir. Arıza arşivi sayfaları robots.txt içinde Disallow ile kapatılırken llms.txt dosyasında bu bölümün adresinin verilmesi çelişki yaratır; botlar izin durumunu net okuyamadığında arşivi tamamen atlar. Ayrıca tüm siteyi kapsayan genel bir User-agent: * kuralı, arıza kayıtlarının bulunduğu alt dizini de istemeden kapatabilir.

Yapısal veri tarafında sık görülen hatalar şunlardır:

• Arıza kaydı için Dataset veya Table işaretlemesi yapmadan yalnızca Article şeması kullanmak; tarih ve çözüm süresi alanlarının makine tarafından okunmasını engeller.
• Arıza kodlarını serbest metin içinde (“kapı sensörü arızası, yaklaşık 2 saat”) bırakıp ayrı alanlara ayırmamak; botlar bu ifadeyi sayısal veri olarak eşleştiremez.
• Kayıtları yalnızca giriş gerektiren panel arkasında tutup herkese açık bir özet sayfası yayınlamamak; erişilemeyen veri atıf için değerlendirilmez.
• Bakım periyodu, müdahale süresi ve arıza kodu sözlüğünü sayfada tanımlamadan kullanmak; bağlam eksikliği nedeniyle yanlış eşleştirme riski doğar.

Son olarak, arşiv sayfalarında tarih biçiminin tutarsız olması (bir yerde 12.03.2024, başka yerde 2024-03-12) ve sayfa başlığında bölge veya bina tipi belirtilmemesi, AI yanıtlarında kaynağın ilgisiz bulunmasına yol açar. Sektör rehberi için asansör bakımı sektör rehberi bölümündeki yapı örnekleri bu hataların önüne geçmek için kullanılabilir.

Asansör bakımı sektörü için kontrol listesi

Arıza ve müdahale kayıtlarınızın AI yanıtlarında kaynak olarak değerlendirilmesi için önce veri setinin sayfada gerçekten görünür ve erişilebilir olması gerekir. Kayıtları yalnızca müşteri panelinde veya PDF içinde tutmak, botların bu içeriği okuyup atıf yapmasını engeller. Aşağıdaki liste, yayın öncesi kontrol için pratik bir çerçeve sunar.

• Her arıza kaydı için ayrı ve sabit bir URL oluşturun; örneğin /ariza-kayitlari/2024-11-kapi-sensoru gibi okunabilir bir yol kullanın.
• Kayıt sayfasında tarih, bina veya tesis tipi, arıza kodu, belirti, müdahale adımı ve çözüm süresini metin olarak yazın; tablo görseli yerine HTML tablo tercih edin.
• Arıza kodlarını kendi bakım yönetim sisteminizdeki kodlarla birebir eşleştirin; AI yanıtlarında kodun anlamı sorulduğunda sayfada açık tanım bulunsun.
• Sayfa başlığı ve açıklamasında “asansör arıza kaydı”, “müdahale süresi” gibi arama niyetine uygun ifadeler kullanın; süslemeli başlıklardan kaçının.
• Yapısal veri için Schema.org üzerinde teknik doküman veya rapor benzeri bir tip seçin; sayfadaki görünür metinle işaretlemeyi tutarlı tutun.
• robots.txt dosyasında arıza kayıtları dizinine AI tarayıcıları için erişim izni verin; yalnızca müşteriye özel, kişisel veri içeren kayıtları hariç tutun.
• llms.txt dosyasında arıza kayıtları dizininin kapsamını ve güncelleme sıklığını kısa biçimde belirtin.
• Kayıt sayfalarında müşteri adı, telefon ve adres gibi kişisel verileri maskeleyin; yalnızca bina tipi ve şehir düzeyinde bilgi verin.
• Çözüm süresini saat veya gün cinsinden sayısal olarak yazın; “kısa sürede” gibi ölçüsüz ifadeler kullanmayın.
• Sayfa sonunda kaydın hangi döneme ait olduğunu ve son güncelleme tarihini belirtin.

Bu adımlar, bakım firmasının sektör rehberi sayfasındaki genel çerçeveyle birlikte uygulandığında, arıza kayıtlarının hem arama hem de AI yanıtlarında kaynak olarak görünme olasılığını artırır. Yine de hiçbir yöntem belirli bir sıralama veya atıf garantisi vermez; sonuçlar tarayıcı davranışına ve içeriğin özgünlüğüne göre değişir.

Sik sorulan sorular

Arıza kayıtlarını yayınlamak müşteri verisi açısından riskli mi?

Bina adresi, iletişim bilgisi ve kişi adı gibi tanımlayıcı alanlar çıkarıldığında kayıtlar anonimleşir. Yayınlanacak veri setinde yalnızca tarih, arıza kodu, müdahale türü ve çözüm süresi gibi teknik alanlar tutulmalıdır. Bu ayrım yapılmadan yayın yapılmamalıdır.

llms.txt dosyası tek başına atıf sağlar mı?

Hayır. llms.txt bir izin ve yönlendirme dosyasıdır, içeriğin kendisi değildir. Botların sayfaya erişebilmesi ve metni okuyabilmesi gerekir. Dosya yalnızca erişim tercihini bildirir, atıf kararını içerik kalitesi belirler.

Yapısal veri olmadan da kayıtlar kaynak gösterilir mi?

Gösterilebilir, ancak yapısal veri botların alanları daha net ayırt etmesine yardımcı olur. Tablo verisinin sayfa metninde de açıklanması okunabilirliği artırır. İkisinin birlikte sunulması en sağlıklı yaklaşımdır.

Etkiyi ne kadar sürede ölçebiliriz?

AI yanıtlarındaki atıflar kısa vadede dalgalanır, bu nedenle tek seferlik kontrol yeterli değildir. Aylık tekrarlanan sorgu seti ve yönlendirme trafiği takibi daha güvenilir sonuç verir. Ölçümü sabit bir sorgu listesiyle düzenli yapmak gerekir.

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.

Bu konunun ayrıntıları Uzun dönem filo kiralama sözleşmeleri AI yanıtlarınd yazısında adım adım anlatılıyor.

Bu konunun ayrıntıları Havalimanı şube sayfaları AI harita yanıtlarında nas yazısında adım adım anlatılıyor.

Bu konunun ayrıntıları Gıda ambalajı uygunluk beyanları AI atıf sinyali taş yazısında adım adım anlatılıyor.

Bu konunun ayrıntıları Ambalaj numune ve teklif sayfaları AI yanıtlarında k yazısında adım adım anlatılıyor.