1. Dönüşüm odaklı otel ana sayfası (ilk ekran kurgusu)

Ana sayfa, kullanıcıyı “her şeyi göstermek” için değil; en hızlı şekilde rezervasyon aksiyonuna götürmek için vardır. Özellikle mobilde kullanıcı, iki şey görmek ister: (1) bu otel bana uygun mu, (2) fiyat/uygunluk yoluna nasıl girerim?
“Above the fold” bileşen stack’i (otel için pratik)
- Değer önerisi (konsept + destinasyon)
- Mini güven (puan/yorum sayısı veya kısa kanıt)
- Ana CTA (Tarih seç / Fiyat gör / Rezervasyona başla)
- Hızlı arama barı veya sticky bar tetikleyicisi
Voice: “Butonu nereye koymalıyım?”
- • Cevap: İlk ekranda, değer önerisinin hemen altında ve mobilde baş parmağın erişebileceği bölgede. Kullanıcı kaydırmadan “rezervasyon yoluna” girmeli.

Kampanya ve promosyon mesajı nereye konmalı?
Promosyon, CTA’yı desteklemeli; CTA’yı gölgelememeli. Örnek: “Erken rezervasyon fırsatı” mesajını CTA’nın üstünde tek satır olarak konumlandırmak, kararı hızlandırır; ancak 3 farklı kampanya alanı aynı anda gösterilirse karar süresi uzar.
Mini Check (H2-1)
- • İlk ekranda tek ana CTA var mı?
- • CTA, mobilde erişilebilir mi (tap alanı yeterli mi)?
- • Promosyon mesajı 1 satır ve net mi?
- • Güven sinyali (puan/yorum) karar anında görünüyor mu?
Ne yapmalıyım?
- • İlk ekrana “tek iş” verin: tarih seç → uygunluk.
- • CTA’yı görünür yapın: mobilde thumb-zone; desktop’ta hero altında.
- • Promosyonu CTA’yı güçlendiren tek mesajla sınırlayın.
- • Ana sayfada “rezervasyon” dışındaki linkleri ikinci plana itin (footer/alt bloklar).
3. Rezervasyon formunda kaç alan olmalı?
AEO kısa cevap (3–5 madde):
- •En kritik alanlar genelde Ad–Soyad, E-posta, Telefon ile sınırlı tutulabilir; diğer bilgiler “sonra” toplanır.
- •Her ek alan, mobilde tamamlama sürtünmesini artırır; “zorunlu alan” gerçekten zorunlu olmalıdır.
- •Hata mesajları otomatik değil, çözüm söyleyen formatta yazılmalıdır (örnek format).
- •Label, error state ve erişilebilirlik (a11y) standart olmalı; form sayfasına gereksiz script yüklenmemelidir.
- •Form–ödeme akışında güven (iptal özeti + güvenli ödeme) görünür olmalıdır.
CTA’lar nereye konmalı? (otelde pratik yerleşim)
- •Ana sayfa: hero altında (ilk ekran) + scroll sonrası sticky
- •Oda listesi: her oda kartında “fiyat gör / seç” aksiyonu + sayfa altı sticky
- •Oda detayı: galeri sonrası ilk karar bloğunda + sticky
- •Form/ödeme: özetin yanında, tek ana CTA
Formu nasıl kısaltırım? (progressive disclosure)
- •“Önce rezervasyonu tamamla” mantığı: sadece gerekli alanlar
- •Özel istekler, transfer, fatura bilgisi gibi alanları opsiyonel yap
- •Otomatik doldurma (autocomplete) ve doğru klavye türleri (email/phone) kullan
Önce/Sonra – alan sadeleştirme mantığı (tablo)
Aşağıdaki yaklaşım, pek çok konaklama & seyahat projesinde form tamamlama oranını destekleyen yönlü bir fayda olarak gözlemlenir: alan sadeleşince sürtünme azalır; güven öğeleri eklenince karar güçlenir (rakam vermeden yönlü ifade).
| Form bloğu | “Önce” (ağır) | “Sonra” (sade) | Not |
|---|---|---|---|
| Kimlik | Ad, Soyad, Ünvan, T.C. | Ad, Soyad | Ünvan/T.C. çoğu senaryoda şart değil |
| İletişim | E-posta, Telefon, Ülke, Şehir | E-posta, Telefon | Ülke/şehir opsiyonel |
| Ek bilgiler | Varış saati, transfer, notlar | Notlar (opsiyonel) | Diğerleri post-booking |
| Doğrulama | Uzun uuyarılar | Kısa, net hata mesajı | Çözüm odaklı format |
Mini Check (Form)
- • Zorunlu alan sayısı minimum mu?
- • Label’lar açık mı; placeholder’a güvenilmiyor mu?
- • Error state ve mesajlar çözüm söylüyor mu?
- • Form sayfasında gereksiz script/etiket şişmesi var mı?
Ne yapmalıyım?
- • Zorunlu alanları 3–4 çekirdek alana indirin; diğerlerini opsiyonel yapın.
- • Hata mesajlarını standartlaştırın: “ne yanlış + nasıl düzeltilir”.
- • CTA’yı tekleştirin: her ekranda tek ana CTA, tek ikincil yol.
- • Dönüşümü ölçmek için raporlama sayfanıza bağlayın: /raporlama/satis-donusum
4. Güven bileşenleri (review, badge, sosyal kanıt) nereye yerleştirilmeli?
Otel sitelerinde güven öğeleri “dekor” değildir; rezervasyon kararının yakıtıdır. Yorum/puan, rozetler, ödüller, “iptal özeti”, “güvenli ödeme” gibi sinyaller doğru yerde görünmezse, kullanıcı ödeme adımında vazgeçebilir.
Güven öğesi yerleşim haritası (karar anına göre)
- •Ana sayfa: kısa puan/yorum (tek satır)
- •Oda listesi: “ücretsiz iptal” gibi karar rozetleri + puan mini
- •Oda detayı: yorum özeti + iptal koşulu özeti + fotoğraf kalitesi
- •Ödeme öncesi: güvenli ödeme + iptal özetinin görünür olması
Sosyal kanıtın dozu (rozet spam’inden kaçın)
Çok rozet, güveni artırmak yerine “satış baskısı” hissi yaratabilir. Kural: 2–3 çekirdek güven sinyali seçin ve her dilde aynı netlikle kullanın.
Mini Check (Güven)
- • Güven sinyali “karar anında” görünüyor mu?
- • İptal özeti 1–2 satır net mi?
- • Ödeme öncesi güvenli ödeme mesajı görünür mü?
- • Rozet sayısı kontrolden çıkmış mı?
Ne yapmalıyım?
- • Güven öğelerini sayfa sayfa değil, akış akış yerleştirin (funnel mantığı).
- • “İptal + toplam fiyat + güvenli ödeme” üçlüsünü standartlaştırın.
- • Reklam trafiği geliyorsa (SEM), güven öğelerini landing’de erken gösterin: /sem/google-ads-yonetimi
6. Dönüşüm Odaklı Otel UI Checklist’i (v1.0) — İndir
Dönüşüm Odaklı Otel UI Checklist’ini İndir — UI/UX Bileşenleri (v1.0)
Bu checklist, otel web sitenizde dönüşümü etkileyen UI bileşenlerini (CTA, form, header, footer, güven öğeleri) hızlıca tarayıp en yüksek sürtünmeyi yaratan noktaları önceliklendirmenizi sağlar. Amaç, “her şeyi değiştirmek” değil; 14 günlük sprintle en hızlı kazanımı üretmektir. Çıktı, ekipler arası ortak dil kuracak şekilde düzenlenmiştir.
Kim Kullanır?
Otel pazarlama/satış ekibi + ajans + yazılım/UX ekibi.
Nasıl Kullanılır?
- Mobil ve desktop’ta ana akışı 1 kez tamamlayın (ana sayfa → oda → form → ödeme).
- Aşağıdaki checklist’i işaretleyin; “kırmızı” çıkan 3 maddeyi seçin.
- 14 günlük sprint planına göre uygulayın; raporlama panelinde değişimi takip edin.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ İlk ekranda tek ana CTA var (tarih seç / fiyat gör)
- ▢ ✅ Sticky rezervasyon CTA mobilde erişilebilir (tap alanı yeterli)
- ▢ ✅ Header menü sade (5–7 madde) ve rezervasyon yolu net
- ▢ ✅ Oda kartında karar bilgisi net: toplam fiyat + iptal özeti + 3 fark
- ▢ ✅ Form alanları minimum (zorunlu alanlar gerçekten zorunlu)
- ▢ ✅ Label + error state erişilebilir (a11y) ve mesajlar çözüm odaklı
- ▢ ✅ Ödeme öncesi güven + iptal özeti görünür
- ▢ ✅ Güven öğeleri rozet spam değil; 2–3 çekirdek sinyal
- ▢ ✅ Footer ikincil dönüşüm sunuyor (geri arama/teklif/iletişim)
- ▢ ✅ CTA ve form event’leri ölçümleniyor (raporlama)
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
7. Sonuç: Dönüşüm “bileşen disiplini” ile gelir
Otel web dönüşümü; CTA, form, header, güven öğeleri ve footer’ın tek bir hedefe (rezervasyon) hizalanmasıyla yükselir. Niyet var ama sürtünme yüksekse, özellikle reklam trafiğinde kayıp büyür; niyeti hız + netlik + güven ile yakalamak gerekir.
Bu rehberi bir “playbook” gibi kullanın: önce en yüksek drop-off alanını seçin, sonra tek bir bileşeni iyileştirin, sonra ölçümleyin. Ardından bir sonraki bileşene geçin.
Bir Sonraki Adım
CTA, form, güven öğeleri ve footer akışını birlikte değerlendirip direkt rezervasyon için uygulanabilir bir bileşen planı alın.
Sık Sorulan Sorular
Otel web sitemde CTA’lar nereye konmalı?▾
Rezervasyon formunda kaç alan olmalı?▾
Güven öğeleri (yorum, puan, rozet) nereye yerleştirilmeli?▾
Header dönüşümü nasıl etkiler?▾
Footer dönüşümü nasıl etkiler?▾
Sticky rezervasyon butonu her sayfada olmalı mı?▾
Formu kısaltırken nelere dikkat etmeliyim?▾
İlgili İçerikler





