Otel, Restoran ve Kafeler İçin GEO: AI'da Görünmek

Bir misafirin telefonuna yazdığı cümle şuna benziyor artık: "3 yaşındaki çocukla, akşam 8'de hâlâ açık olan, kaldığımız otelden yürüme mesafesinde, glutensiz seçeneği olan bir yer önerir misin?" Bu bir arama sorgusu değil, içinde beş ayrı kısıt taşıyan bir talep. Eski alışkanlıkta arama kutusuna "Kadıköy restoran" yazılırdı; aradaki fark yalnızca uzunluk değil. Eski sorgu bir kategori adıydı, yenisi bir filtre kümesi.

Bu tür istekleri incelediğinizde tekrar eden üç özellik görünür. Birincisi bağlam: kullanıcı nerede olduğunu, kiminle olduğunu ve saatin kaç olduğunu cümlenin içine koyar. İkincisi kısıt: bir özelliğin bulunmasını şart koşar, tercih olarak değil eleme ölçütü olarak söyler. Üçüncüsü çokluk: bu kısıtlar tek tek değil, hepsi aynı anda karşılanmak üzere sıralanır. Anahtar kelime mantığıyla düşünülmüş bir sayfa bu üç özelliğin hiçbirine cevap vermez, çünkü sayfa bir konu etrafında yazılmıştır, koşullar etrafında değil.

Ağırlama işletmeleri açısından bu kaymanın pratik sonucu net: kullanıcı artık on bağlantılık bir liste görüp elemeyi kendisi yapmıyor. Elemeyi asistan yapıyor ve geriye iki üç isim kalıyor. O isimlerden biri olmak, sitenizin ne kadar iyi göründüğüyle değil, işletmenize dair kısıt bilgisinin makine tarafından okunabilir olup olmadığıyla ilgili bir mesele.

AI, bir mekânı önerirken hangi kısıtları eşleştirir

Çok kriterli bir istek, model tarafında tek parça halinde işlenmez. Ayrı ayrı doğrulanması gereken koşullara ayrışır ve her koşul kendi başına bir eleme adımıdır. Otel, restoran ve kafeler için bu koşullar pratikte altı başlıkta toplanıyor.

Konum ve mesafe. "Yürüme mesafesinde" ifadesi bir semt adına göre değil, kullanıcının bulunduğu referans noktasına göre çalışır. Sitesinde yalnızca ilçe adı geçen bir işletme, cadde, mahalle, yakın durak ve belirgin bir yer imine göre konumunu yazan işletmeyle aynı kefeye girmez.

Saat. Burada iki ayrı bilgi karışıyor: mekânın kapanış saati ile mutfağın son sipariş saati. "Akşam 8'de açık mı" sorusunun cevabı çoğu zaman ikincisine bağlı ama sitelerin çoğunda yalnızca birincisi yazıyor. Resmi tatil ve haftalık kapalı gün istisnaları da aynı şekilde eksik kalıyor.

Fiyat aralığı. Kişi başı ortalama, oda gecelik başlangıç fiyatı ya da en azından bir bant. Fiyatı hiç yazmayan sayfa, fiyat kısıtı içeren bir sorguda değerlendirme dışında kalır.

Diyet ve mutfak. Glutensiz, vegan, vejetaryen, laktozsuz, helal. Bu bilginin "bize sorun" düzeyinde kalması ile menüdeki hangi kalemin hangi diyete uygun olduğunun yazılması arasında büyük fark var.

Erişilebilirlik. Tekerlekli sandalye girişi, asansör, engelli tuvaleti, giriş katında masa bulunup bulunmadığı. Bu kısıt sorgularda gittikçe daha sık geçiyor ve karşılığı sitelerde en seyrek bulunan bilgi.

Çocuk ve evcil hayvan. Mama sandalyesi, çocuk menüsü, oyun alanı, evcil hayvan kabul politikası, bahçede kabul edilip edilmediği. Ailelerin ve hayvan sahiplerinin sorgularında bunlar tek başına belirleyici olabiliyor.

Bu altı başlığın hepsi aynı anda karşılanmak zorunda değil. Ama her biri hakkında bir cevabın bulunabilir olması gerekiyor; çünkü modelin yaptığı şey işletmeleri sıralamak değil, koşulları eşleştirmek.

Kısıt bilgisi sitenizde yoksa AI sizi eleyemez de seçemez de

Buradaki asimetri fark edilmeden geçiliyor. Bir insan ziyaretçi sitenize girip glutensiz seçenek göremezse telefon eder, boşluğu kendi kapatır. Bir dil modeli o telefonu etmez. Elinde kanıt olmayan bir iddiayı — "burada glutensiz menü var" — üretmesi, en temel doğruluk kısıtına aykırıdır. Dolayısıyla bilgi yoksa model olumlu cevap vermez.

Sonuç şu: eksik bilgi, olumsuz bilgiyle aynı kapıya çıkar. Evcil hayvan kabul ediyor olabilirsiniz; sayfanızda yazmadığı sürece "evcil hayvanla girilebilen kafe" sorgusunun cevabında yoksunuz. Bunun tersi de doğru ve aslında iyi haber: rakiplerinizin çoğu da bu bilgiyi yazmıyor. Kısıtları açıkça yazan işletme, sektörün genel eksikliği sayesinde belirgin bir avantaj elde ediyor.

Yerel arama alışkanlıklarıyla bu yeni davranış arasındaki farkı ayrıntılı görmek isterseniz yerel SEO ile GEO arasındaki farkı ele aldığımız yazı iyi bir başlangıç. Kısaca: yerel SEO sizi bir listeye sokmayı hedefler, GEO ise doğrudan cevabın içinde geçmeyi.

Menü, oda ve olanak bilgisini makine okunabilir yapmak

Ağırlama sektöründe bilgiyi görünmez kılan üç yaygın kalıp var.

Birincisi PDF menü. Tasarımcıdan geldiği haliyle sayfaya iliştirilen PDF, insan için okunabilir ama site içeriğinin bir parçası olarak işlenmesi güvenilir değil. İkincisi görsel içine gömülü metin: menü fotoğrafı, oda özelliklerini anlatan bir afiş görseli, fiyat listesi ekran görüntüsü. Üçüncüsü yalnızca tıklamayla açılan içerik: rezervasyon motorunun içindeki oda açıklamaları, JavaScript ile yüklenen sekmeler. Üçünün ortak sonucu aynı — bilgi sitede vardır, sayfanın metninde yoktur.

Otellerde bu kalıbın en pahalı hali oda tiplerinde görülür. Oda adları sayfada listelenir ama metrekare, yatak düzeni, manzara, balkon, küvet veya duş, ek yatak imkânı gibi ayrıntılar rezervasyon motorunun içinde kalır. "İki çocuklu aile için uygun oda" sorgusunda değerlendirmeyi mümkün kılan bilgi tam olarak budur.

Çözümün ilk adımı sıkıcı ama etkili: menüyü, oda tiplerini ve olanak listesini düz HTML metni olarak sayfaya yazmak. Görsel ve PDF kalabilir; metin karşılığı da bulunsun.

İkinci adım yapılandırılmış veri. Restoranlar için Restaurant, oteller için Hotel veya BedAndBreakfast tipi üzerinden servesCuisine, priceRange, hasMenu ile bağlanan Menu / MenuSection / MenuItem, kalem bazında suitableForDiet, olanaklar için amenityFeature, çalışma saatleri için openingHoursSpecification, ayrıca acceptsReservations, petsAllowed, otellerde checkinTime ve checkoutTime. Bu alanlar sayfadaki görünür metnin yerine geçmez, onu doğrular. Şemanın hangi sinyalleri güçlendirdiğine schema işaretlemesi ve E-E-A-T yazımızda daha ayrıntılı bakmıştık.

Rezervasyon platformları sizi temsil ederken

Çoğu otel ve restoran için internetteki görünürlüğün büyük kısmı üçüncü taraf platformlardan geliyor: rezervasyon siteleri, harita kayıtları, yemek uygulamaları, sosyal medya profilleri. Bir asistan cevabını hazırlarken bu kaynakların hepsine aynı anda bakabiliyor ve aralarındaki çelişkiyi görüyor.

Çelişki üç yerde ortaya çıkıyor. Ad, adres, telefon yazımının kaynaktan kaynağa değişmesi — şube adının bir yerde "Kafe X Moda", başka yerde "X Coffee" olması, adres formatının tutmaması, telefonun eski numarada kalması. Çalışma saatleri, özellikle kış-yaz farkı olan işletmelerde. Fiyat, platformda gösterilen tutarla kendi sitenizdeki tutarın uyuşmaması.

Özellikle saatlerde şu tabloya sık rastlanır: harita kaydında yaz saatleri duruyordur, rezervasyon platformunda kışın kısalttığınız saat görünüyordur, kendi sitenizde ise iki yıl önce yazılmış üçüncü bir saat vardır. Üçü de teknik olarak bir zamanlar doğruydu; bugün üçü birden doğru olamaz.

Çelişki bulunduğunda model iki şeyden birini yapar: ya bilgiyi hiç kullanmaz ya da daha güncel gördüğü kaynağı tercih eder. İkisi de sizin lehinize değil, çünkü ikisinde de kontrol sizde olmaz. Bu yüzden kendi siteniz birincil kaynak olarak konumlanmalı ve platformlar ona göre hizalanmalı — tersi değil.

Pratik yöntem basit: çeyrekte bir kez, işletme adının geçtiği tüm kayıtları tek bir tabloda toplayın; ad yazımı, adres, telefon, saatler ve kapalı günler sütunlarını yan yana koyup farklıları düzeltin. Bu denetim, altyapı tarafındaki diğer temel işlerle birlikte KOBİ web sitesi için GEO uyumlu altyapı rehberinde anlattığımız düzenin bir parçası.

Sezon, kampanya ve geçici değişiklikler

Ağırlama sektörü mevsimlik çalışır. Kış menüsü, yaz terası, bayram programı, tadilat nedeniyle kapalı iki hafta, düğün sezonunda değişen rezervasyon koşulları. Bu bilgiler sitede yayımlanır ama sonrasında güncellenmediği için zamanla yanlış bilgi kaynağına dönüşür.

İki ayrı şey birbirine karışıyor burada: içeriğin güncelliği ve içeriğin geçerlilik aralığı. Sayfanın en son ne zaman değiştiğini bildiren dateModified alanı birinciyi çözer. İkincisi için geçici saat değişikliklerini specialOpeningHoursSpecification ile, tarihli kampanyaları ise sayfada açıkça yazılmış başlangıç ve bitiş tarihiyle belirtmek gerekir. "Yaz kampanyası" başlıklı, hangi yaza ait olduğu yazmayan bir sayfa hem kullanıcıyı hem modeli yanıltır.

Süresi dolan kampanya sayfalarını silmek yerine üzerine "bu kampanya sona erdi" notu düşmek daha sağlıklı; hem bağlantılar kırılmaz hem de geçerlilik açıkça bildirilmiş olur. Fiyat ve kontenjan gibi hızlı değişen alanlarda ise kural şu: sayfada yazılı olan tutar, rezervasyon adımında karşılaşılan tutarla aynı olsun. Aradaki fark, kullanıcıda güven kaybı yaratmanın ötesinde, kaynak olarak sitenizin güvenilirliğini de aşağı çeker.

Küçük işletme için gerçekçi bir başlangıç sırası

Tek kişilik bir ekiple çalışan bir kafe için yukarıdakilerin tamamı fazla gelebilir. Sıralama şöyle kurulursa ilk iki adım bile ölçülebilir fark yaratır.

1. Tek bir "olanaklar" sayfası yazın. Düz metin, madde madde: diyet seçenekleri, erişilebilirlik, çocuk ve evcil hayvan politikası, otopark, wifi, dış mekân. Yarım saatlik iş.

2. Menüyü ve oda tiplerini HTML metnine taşıyın. PDF ve görsel dursun, altına metin karşılığını ekleyin.

3. Saatler için tek doğru kaynak belirleyin. Site üzerindeki saat bilgisi tek yerde tutulsun, istisnalar da orada yazsın; ardından openingHoursSpecification ekleyin.

4. Platform denetimini yapın. Ad, adres, telefon ve saatleri tüm kayıtlarda eşitleyin.

5. Rezervasyon yolunu netleştirin. Kaç kişiye kadar rezervasyon alındığı, ne kadar önce iptal edilebildiği, telefon dışında bir kanal olup olmadığı sayfada yazılı olsun. Rezervasyon ve iptal akışını otomatikleştirmeyi düşünüyorsanız randevu ve iptal süreçlerine dair yazımız işletme tarafındaki karşılığını anlatıyor.

6. Ölçün. Kendi kısıt sorgularınızı — "çocukla gidilebilecek, glutensiz seçeneği olan, bu semtte" — birkaç farklı asistana sorup çıkan cevapları tarihiyle kaydedin. Değişimi görmenin başka güvenilir yolu yok; tahmin yerine kayıt tutun.

Bu adımların işletmenizde nasıl karşılık bulacağını konuşmak isterseniz sunduğumuz çözümlere göz atabilirsiniz.

Sıkça Sorulan Sorular

Restoranım için ayrı bir web sitesi şart mı, sosyal medya hesabı yetmez mi?

Sosyal medya hesabı görünürlük sağlar ama yapılandırılmış bilgi taşımaz: menü kalemleri, diyet uygunlukları, çalışma saati istisnaları ve erişilebilirlik bilgisi gönderi metinlerine dağılır. Yapay zeka asistanları bir öneri üretirken doğrulanabilir ve kalıcı bir kaynak arar. Sade, tek sayfalık ama bu bilgileri metin olarak içeren bir site, sürekli akan bir sosyal medya profilinden daha güvenilir bir referans oluşturur.

Menümü PDF olarak yayınlıyorum, bu neden sorun?

PDF, insan gözü için okunabilir olsa da sayfa içeriğinin doğal bir parçası olarak işlenmesi güvenilir değildir; içindeki kalem adları, fiyatlar ve diyet notları çoğu zaman değerlendirme dışında kalır. En sağlıklı yol PDF'i kaldırmak değil, aynı bilgiyi sayfada HTML metni olarak da yayınlamak. Böylece hem baskı kalitesindeki menü hem makine okunabilir karşılığı aynı anda bulunur.

Rezervasyon sitesindeki bilgilerimle kendi sitemdekiler farklıysa ne olur?

Bir asistan çelişkili bilgi gördüğünde ya o bilgiyi hiç kullanmaz ya da daha güncel saydığı kaynağı tercih eder. İki durumda da kontrol sizde olmaz ve yanlış saat veya fiyatla anılabilirsiniz. Bu yüzden kendi siteniz birincil kaynak kabul edilmeli, platform kayıtları düzenli aralıklarla ona göre hizalanmalıdır. Ad yazımı, adres formatı ve telefon numarası dahil.

Schema.org işaretlemesi eklersem sayfada metin yazmama gerek kalır mı?

Kalır. Yapılandırılmış veri, sayfadaki görünür içeriğin yerine geçmez; onu tanımlar ve doğrular. Sayfada karşılığı olmayan bir schema alanı en iyi ihtimalle yok sayılır, tutarsız olduğunda ise güven sinyalini zayıflatır. Doğru sıralama önce bilgiyi okunur metin olarak yazmak, sonra aynı bilgiyi schema ile etiketlemektir.

Sezonluk menü ve kampanyaları sitede nasıl tutmalıyım?

Her tarihli içeriğe geçerlilik aralığını açıkça yazın: hangi tarihte başladığı, ne zaman biteceği. Süresi dolan kampanya sayfasını silmek yerine üzerine sona erdiğini belirten bir not ekleyin, böylece bağlantılar kırılmaz ve bilgi yanlış yönlendirmez. Geçici saat değişiklikleri için ayrı bir schema alanı bulunur; normal çalışma saatlerini bozmadan istisnayı bildirmeye yarar.