Zincir ve Grup Oteller İçin Bilgi Mimarisi ve UX: Multi-Property Web Tasarımı

Information Architecture (IA), içerik ve sayfaların kullanıcı zihnindeki “harita”sıdır: nerede ne var, nasıl bulunur, hangi yoldan rezervasyona gidilir? Zincir otelde IA iki şeye hizmet eder:

1. Keşif: destinasyon ve marka algısı (awareness)
2. Seçim: doğru oteli ve doğru paketi hızlı seçmek (consideration)

IA’nın otel zinciri için 3 temel çıktısı

• •Net hiyerarşi (marka→destinasyon→otel)
• •Net navigasyon ve breadcrumb (kullanıcı nerede?)
• •Net listeleme/filtreleme (doğru oteli buldur)

☑ Mini Check (IA)

• •Kullanıcı “şu anda nerede”yi 2 saniyede anlıyor mu?
• •Destinasyon sayfaları mantıklı listeleniyor mu?
• •Otel seçim adımı rezervasyon akışında net mi?
• •Aynı otelin farklı adları/URL’leri karışıklık yaratıyor mu?

Zincir yapılarda en kritik stratejik karar: tek bir marka sitesi mi, yoksa her otel için ayrı site mi? Pratikte çoğu grup, “marka ana domain + otel alt sayfaları” yaklaşımına gider; çünkü hem marka hikâyesini hem de satış odaklı otel sayfalarını tek sistemde yönetmek daha sürdürülebilir olur.

Marka sitesinin rolü (hub)

• •Destinasyon seçtirir (Antalya, Bodrum, Side…)
• •Segment anlatır (resort/city)
• •Markanın değer önerisini taşır
• •Zincirdeki otellere yönlendirir

Otel sayfasının rolü (child / conversion)

• •Oda tipleri, konsept, galeri
• •Fiyat/iptal netliği
• •Rezervasyon akışı (conversion)

Ne zaman ayrı site mantıklı?

Bazı oteller “farklı marka” gibi davranıyorsa (tam ayrı segment), ayrı site tartışılabilir. Ama çoğu durumda parçalı yapı; SEO, ölçüm ve yönetim maliyetini artırır.

☑ Mini Check (Rol)

• •Marka sayfası “satış”a değil “seçim”e hizmet ediyor mu?
• •Otel sayfası rezervasyon için yeterince detaylı mı?
• •Kullanıcı marka sayfasında kaybolmadan otel seçebiliyor mu?
• •Ölçümde (GA4) marka→otel geçişi izleniyor mu?

AEO kontrol listesi (5–7 madde)

1. Hiyerarşiyi net kurun: Marka → Destinasyon → Otel → Rezervasyon.
2. Destinasyon listeleme sayfaları oluşturun (Antalya/Bodrum/Side) ve filtre/arama ekleyin.
3. Segment filtreleri ekleyin: resort/city, aile/çift, spa, aquapark gibi.
4. Her otelin tek bir “kanonik” otel sayfası olsun; içerik ve URL tutarlı kalsın.
5. Breadcrumb ve sayfa başlıkları “kullanıcı nerede?” sorusunu cevaplasın.
6. Otel seçimini tek rezervasyon funnel’ına entegre edin (önce otel, sonra oda/paket).
7. Yerel SEO ve URL yapısını destekleyin (destinasyon sayfaları + GBP yönlendirmeleri).

☑ Mini Check

• •Destinasyon sayfaları var mı?
• •Otel kanonik URL’leri net mi?
• •Breadcrumb çalışıyor mu?
• •Otel seçimi akışın neresinde?

Multi-property’de asıl iş “liste” sayfasında olur. Kullanıcı Antalya’ya gelir, sonra “Belek mi Side mı?” diye bakar, sonra aquapark veya spa gibi ihtiyacını filtreler. Filtreleme, kullanıcıya seçenek sunmak için değil; seçenekleri azaltıp doğruyu buldurmak için vardır.

Lokasyon bazlı listeler (GEO)

Örnek yapı:

• •Antalya otelleri (resort/city ayrımı)
• •Bodrum otelleri (butik/beach)
• •Side otelleri (aile odaklı)

Segment filtreleri (otel özel)

• •Resort / City
• •Aile / Çift / Business
• •Aquapark / Spa / Beach bar
• •Çocuk dostu / Erişilebilir oda (varsa)

Harita + liste birlikte (en iyi pratik)

• •Liste hızlı tarama sağlar
• •Harita konum kararını hızlandırır

Birlikte kullanıldığında, kullanıcı “yakınlık” ve “özellik” kararını aynı ekranda verir.

☑ Mini Check (Filtre)

• •Filtre sayısı karar yorgunluğu yaratıyor mu?
• •Varsayılan filtreler segmenti doğru yansıtıyor mu?
• •Harita/listede aynı otel aynı şekilde temsil ediliyor mu?
• •Mobilde filtre aç/kapat deneyimi hızlı mı?

Tek funnel’da birden fazla oteli yönetmenin kilidi, “otel seçimi” adımını net bir karar ekranına çevirmektir. Otel seçim ekranı belirsiz olursa kullanıcı yanlış oteli seçer veya geri döner.

Otel seçimi adımı nerede olmalı?

İki yaygın yaklaşım:

1. Önce otel seç, sonra tarih/oda: destinasyon araması güçlü ise
2. Önce tarih seç, sonra uygun oteller: kullanıcı tarih odaklı ise (availability-first)

Grup otellerde genelde “tarih seç → uygun oteller → otel seç → oda seç” akışı daha verimlidir; çünkü müsaitlik kararı otel seçiminde belirleyicidir.

Otel liste kartı (selection UI) için zorunlu alanlar

• •Otel adı + lokasyon (Belek/Side)
• •Segment etiketi (resort/city)
• •Kısa değer önerisi (1 satır)
• •Puan/yorum (social proof)
• •“Fiyat gör / uygunluk” CTA

☑ Mini Check (Funnel)

• •Otel seçimi ekranında karar bilgisi var mı?
• •Kullanıcı yanlış otele gitmiyor mu? (geri dönüş çok mu?)
• •Uygunluk (availability) filtreleri var mı?
• •CTA’lar tek hedefe bağlı mı?

Multi-property’de tutarlılık, hem güven hem hızdır. Her otel sayfası “tamamen farklı UI” olursa kullanıcı her defasında yeniden öğrenir. Bu yüzden pattern seti şarttır:

• •Destinasyon listeleme pattern’i
• •Otel kart pattern’i
• •Otel detay pattern’i
• •Tek funnel pattern’i (availability-first)

Bu bölüm kısa tutulmalı; amaç teknik ekibe yön vermek:

• •URL yapısı: marka → destinasyon → otel hiyerarşisini yansıtmalı
• •Çok dilli ise hreflang ve doğru canonical kurgusu yapılmalı
• •Breadcrumb şeması (schema) ve sayfa başlıkları tutarlı olmalı
• •Listeleme sayfalarında pagination veya “load more” performansı bozmayacak şekilde kurgulanmalı (özellikle mobilde)

İç link: Yerel SEO bağlamı için https://dgtlface.com/tr/seo/yerel-seo

☑ Mini Check (Teknik)

• •URL hiyerarşisi anlaşılır mı?
• •Breadcrumb kullanıcıya konumu gösteriyor mu?
• •Listeleme performansı iyi mi (load more/pagination)?
• •Çok dilli yapı varsa hreflang doğru mu?