Otel Web Sitesi Rezervasyon Almıyor mu?

Kısa cevap: Otel web siteniz ziyaretçi alıyor ama rezervasyon almıyorsa kayıp çoğu zaman trafikte değil, rezervasyon akışındadır. Önce GA4’teki dönüşüm hunisiyle misafiri hangi adımda kaybettiğinizi bulun. Ardından sırayla bakın: GA4 rezervasyon motorunu görüyor mu, telefonda ödeme tamamlanıyor mu, sayfa hızlı açılıyor mu, toplam fiyat ödemeden önce görünüyor mu ve misafirin doğrudan rezervasyon yapması için bir nedeni var mı.

Mobilde zor kullanılan, fiyatı geç gösteren veya doğrudan rezervasyon için net bir neden sunmayan bir site, misafiri yeniden OTA’ya gönderebilir. Ama hangisinin sizde olduğunu tahmin etmek yerine ölçmek gerekir. Bu yazı, sorunu düzeltmeden önce yerini bulmak için yedi test sunar. Kaynaklar Ekim 2026’da kontrol edildi.

Varsayımsal bir örnek: Siteniz ayda 1.000 ziyaretçi alıyor ve 12 doğrudan rezervasyon üretiyor. Bu, %1,2 dönüşüm oranı demektir. Aynı trafikte oran örnek olarak %2’ye çıksa ayda 8 rezervasyon daha gelir. Daha fazla reklam, SEO veya sosyal medya bütçesi ayırmadan önce mevcut trafiğin nerede kaybolduğunu bulmak bu yüzden daha ucuzdur.

Öne Çıkanlar

• Rezervasyon kaybını bulmanın ilk adımı GA4’teki dönüşüm hunisi keşfidir: hangi adımda kaç kişinin ayrıldığını gösterir.
• Rezervasyon motoru başka bir alan adındaysa GA4 ayarı yapılmadan huni kopuk görünür ve ödeme sayfası yeni bir trafik kaynağı gibi sayılabilir.
• GA4 rakamları yalnızca çerezlere onay veren ziyaretçileri gösterebilir; rezervasyon motorunun kendi raporuyla karşılaştırın.
• Türkiye, Apple Pay’in ve Google Pay’in çevrimiçi ödeme ülkeleri listesinde yer almıyor. Telefonda asıl test edilecek şey kart formu, taksit ve 3D Secure adımıdır.
• Vergiler dahil toplam fiyat ödeme adımından önce görünmelidir.
• En büyük kaybı önce düzeltip 30 gün ölçmek, aynı anda her şeyi değiştirmekten daha sağlıklı sonuç verir.

Otel web sitesi neden rezervasyon almıyor?

Bir misafir Google’da veya bir OTA’da sizi gördükten sonra sitenize geldiğinde çoğu zaman OTA’ya dönmeye yatkındır. Hesap bilgileri oradadır, ödeme sürecini tanır ve fiyat karşılaştırmaya alışmıştır.

Bu alışkanlığı bozan şey güzel bir ana sayfa değil, sürtünmesiz bir akış ve doğrudan rezervasyon için açık bir nedendir. Hangisinin eksik olduğunu görmek için tasarımı değiştirmeden önce verinize bakın. Aşağıdaki yedi test, en sık kayıp noktalarını sırayla kontrol eder.

Kaybı nasıl düzelteceğinizi, yani akış ve tasarım tarafını, otel web sitesi dönüşüm oranı yazımızda ayrıca anlattık. Bu yazı, kaybın nerede olduğunu bulmakla ilgilidir.

Rezervasyon kaybı hangi adımda oluyor?

1. GA4 dönüşüm hunisiyle kayıp adımını bulun

Rezervasyon almayan bir sitede ilk soru “ne kadar ziyaretçi var” değil, “ziyaretçi hangi adımda ayrılıyor” olmalıdır. Bunu GA4’teki dönüşüm hunisi keşfi gösterir.

Huniyi kurmak için GA4’te Keşfet bölümüne girin ve Yeni bir keşif başlatın altında Dönüşüm hunisi keşfi şablonunu seçin (Google Analytics Yardım). Adımları kendi akışınıza göre tanımlayın. Örneğin:

1. Ana sayfa veya oda sayfası görüntülendi
2. Tarih seçildi veya rezervasyon motoru açıldı
3. Oda seçildi
4. Ödeme adımı açıldı
5. Rezervasyon onayı görüntülendi

Hangi adımda en büyük düşüş varsa ilk işiniz odur. Kapalı huni yalnızca ilk adımdan başlayanları sayar; Açık dönüşüm hunisi oluştur seçeneği, herhangi bir adımdan giren misafiri de gösterir. Geçen süreyi göster ile adımlar arasında ne kadar beklendiğini, Sonraki işlem ile her adımdan sonra misafirlerin en sık ne yaptığını görebilirsiniz.

Rezervasyon onayını ayrıca önemli etkinlik olarak işaretleyin. GA4’te Yönetici > Veri görüntüleme > Etkinlikler bölümünde ilgili etkinliğin yanındaki yıldız simgesiyle yapılır; bunun için mülkte en az Düzenleyici rolü gerekir (Google Analytics Yardım). Onay etkinliği yoksa huni, rezervasyonun tamamlandığını hiç göremez.

2. GA4 rezervasyon motorunu görüyor mu?

Rezervasyon motoru çoğu otelde ayrı bir alan adında veya alt alan adında çalışır. GA4 bu geçişi doğru takip etmiyorsa huni ödeme adımında kopuk görünür ve rezervasyon hiç gerçekleşmemiş gibi okunur.

İki ayarı kontrol edin:

• Alanlar arası ölçüm: Hem sitenizde hem rezervasyon motorunda aynı “G-” kimlikli Google etiketi çalışmalıdır. Ardından Yönetici > Veri toplama ve değiştirme > Veri akışları > Web > [akışınız] > Etiket ayarlarını yapılandırın > Ayarlar > Alanlarınızı yapılandırın yolundan iki alan adını ekleyin (Google Analytics Yardım). Doğru kurulduğunda bağlantılara _gl parametresi eklenir ve Analytics iki alan adındaki ziyareti tek kullanıcı ve tek oturum olarak tanımlar.
• İstenmeyen yönlendirmeler: 3D Secure veya ödeme kuruluşunun sayfasından sitenize dönen misafir, yeni bir trafik kaynağından gelmiş gibi sayılabilir. Bu durumda rezervasyon, onu getiren kanala değil ödeme sayfasına yazılır. Aynı Etiket ayarlarını yapılandırın > Ayarlar bölümünde Tümünü göster > İstenmeyen yönlendirmeleri listeleyin adımından ödeme alan adlarını ekleyin. Google bu listeye örnek olarak üçüncü taraf ödeme işleyicilerini verir (Google Analytics Yardım).

Rezervasyon motoru sayfasındaki “hemen çıkma oranı”na tek başına güvenmeyin. GA4’te hemen çıkma, etkileşim sağlanmayan oturumların oranıdır; etkileşim sağlanan oturum da 10 saniyeden uzun süren, önemli etkinlik içeren veya en az iki sayfa görüntülenen oturumdur. Bu metrik çoğu raporda varsayılan olarak görünmez ve raporu özelleştirmeniz gerekir (Google Analytics Yardım). Motor ayrı bir alan adındaysa ve ayar yapılmamışsa bu oran zaten yanıltıcıdır. Huni daha net bir cevap verir.

3. Rakamlar çerez onayına göre eksik mi?

KVKK’nın Çerez Uygulamaları Hakkında Rehberi, analitik çerezleri açık rıza şartından ancak sınırlı koşullarda ayrı tutar: yalnızca anonim istatistik, siteler arası takip yok ve verinin üçüncü taraflara aktarılmaması gibi. GA4 gibi verinin sağlayıcıya gittiği araçlarda temkinli yaklaşım, etiketi onaydan sonra çalıştırmaktır.

Bu yüzden GA4’teki huni, sitenize gelen herkesi değil, çerezlere onay veren ziyaretçileri gösterebilir. Hunide az rezervasyon görmeniz, rezervasyonun az olduğu anlamına gelmeyebilir. Aynı dönem için rezervasyon motorunun kendi raporundaki rezervasyon sayısıyla GA4’teki onay etkinliğini karşılaştırın. Fark büyükse önce ölçümü düzeltin, sonra akışı.

Telefonda ödeme gerçekten tamamlanıyor mu?

4. Mobil rezervasyonu gerçek telefonda test edin

Misafirlerinizin ne kadarının telefondan geldiğini tahmin etmeyin; GA4’teki cihaz kategorisi boyutu bunu gösterir. Huniyi cihaz kategorisine göre ayırın. Mobildeki düşüş masaüstünden belirgin biçimde büyükse sorun içerikte değil, telefondaki akıştadır.

Ardından kendi telefonunuzla gerçek bir test rezervasyonu yapın. Masaüstü tarayıcısındaki küçültülmüş mobil görünümü kullanmayın. Tarihi seçtiğiniz andan onay e-postasını aldığınız ana kadar şunları not edin:

• Takvimde doğru güne tek dokunuşla basabiliyor musunuz?
• Metni yakınlaştırmadan okuyabiliyor musunuz?
• Formda rezervasyon için gerçekten gerekmeyen alan var mı?
• Kart formu telefonda düzgün açılıyor mu, taksit seçenekleri görünüyor mu?
• 3D Secure doğrulama ekranı açılıyor mu ve onaydan sonra misafir rezervasyon onayına dönüyor mu?
• Onay e-postası hemen geliyor mu?

Türkiye’de ödeme tarafında beklenti yönetimi önemlidir. Türkiye, Apple Pay’in desteklenen ülkeler listesinde yer almıyor; Google Pay’in çevrimiçi ödeme yapılabilen ülkeler listesinde de Türkiye yok. Bu yüzden telefondaki asıl test, Apple Pay düğmesi değil, sanal POS veya lisanslı bir ödeme kuruluşu üzerinden çalışan kart formu, taksit ve 3D Secure adımıdır. Bir rezervasyon sisteminde ödeme altyapısına neye bakılacağını otel rezervasyon sistemi sayfamızda anlattık.

Formu kısa tutmanın bir dayanağı da KVKK’dır: kişisel veriler, 6698 sayılı Kanun md. 4’e göre işlendikleri amaçla bağlantılı, sınırlı ve ölçülü olmalıdır. Rezervasyon için gereken bilgi genelde tarih, oda, misafir adı, iletişim bilgisi ve ödemedir. Bunun dışındaki her alanı sorgulayın.

Telefondaki arayüz sorunlarını nasıl düzelteceğinizi mobil optimizasyon yazımızda, motorda nelere bakılacağını rezervasyon motoru kontrol listemizde anlattık.

Site, misafir odaları görmeden önce mi kaybediyor?

5. Hızı Lighthouse ve Search Console ile ölçün

Misafir sitenizi yavaş bulursa oda fotoğraflarını veya rezervasyon avantajlarınızı görme fırsatı bile olmayabilir. Hızı iki yerden ölçün.

PageSpeed Insights (Lighthouse): Sitenizin adresini test edin ve mobil puana bakın. Lighthouse puanları şöyle gruplar: 0–49 Yetersiz, 50–89 İyileştirme gerekli, 90–100 İyi (Chrome for Developers). Puan testten teste dalgalanabilir; tek bir ölçüme göre karar vermeyin.

Search Console Core Web Vitals raporu: Bu rapor laboratuvar testini değil, gerçek kullanıcı verisini gösterir ve sayfalarınızı Yavaş, İyileştirme gerektiriyor ve Hızlı olarak gruplar (Search Console Yardım). Google’ın iyi kabul ettiği eşikler şunlardır: LCP 2,5 saniye içinde, INP 200 milisaniyeden kısa, CLS 0,1’den az (Google Search Central). Raporda bu değerler, son 28 gündeki sayfa isteklerinin %75’ine göre hesaplanır. Siteniz yeniyse veya trafiği azsa raporda “Veri yok” görebilirsiniz.

Otel sitelerinde sık görülen hız sorunları şunlardır:

• Sıkıştırılmadan yüklenmiş büyük ana görseller
• Her sayfada çalışan fazla sayıda eklenti
• Yetersiz sunucu kaynağı
• Kullanılmayan kod, yazı tipi ve görsel yükleri
• Rezervasyon motorunun sayfaya ağır biçimde eklenmesi

Page builder ile kurulmuş ve her sayfada gereksiz kod yükleyen bir siteyi yalnızca görselleri sıkıştırarak tam anlamıyla hızlandıramazsınız. Sorun bazen fotoğraf dosyasında değil, sitenin nasıl kurulduğundadır.

Fiyat ve güven, kararın verildiği yerde mi?

6. Toplam fiyat ödemeden önce görünüyor mu?

Kendi sitenizde tarih seçin ve vergiler dahil toplam tutarı ilk kez hangi adımda gördüğünüze bakın. Tutar yalnızca ödeme onayında görünüyorsa misafir rezervasyonu tamamlamak yerine yeniden fiyat karşılaştırmasına dönebilir.

Bu yalnızca bir dönüşüm konusu değildir. Mesafeli Sözleşmeler Yönetmeliği md. 5, sözleşme kurulmadan önce tüketiciye “tüm vergiler dahil toplam fiyatı” bildirmeyi ön bilgilendirmenin parçası sayar. Aynı Yönetmelik md. 15, belirli bir tarihte yapılması gereken konaklama sözleşmelerini cayma hakkının dışında tutar. Yani iptal koşulunu otel kendisi belirler ve misafir bunu ödeme öncesinde açıkça görmelidir.

Google’da otel fiyatlarınız görünüyorsa bir kontrol daha var. Hotel Center’ın fiyat doğruluğu politikasına göre sitenizdeki toplam fiyat belirgin biçimde görünmeli ve Google’da gösterilen toplamla aynı olmalıdır; vergiler ve ücretler de misafirden ek bir işlem beklemeden açıklanmalıdır. Fiyat doğruluğu puanı düşük kalırsa Google reklamlarınızı ve ücretsiz rezervasyon bağlantılarınızı devre dışı bırakabilir.

Kontrol listesi:

• Zorunlu ücretler oda fiyatına dahil mi, yoksa sonradan mı ekleniyor?
• Kahvaltı ve dahil hizmetler oda fiyatının yanında yazıyor mu?
• Vergiler dahil toplam, ödeme adımından önce görünüyor mu?
• İptal koşulu ödeme öncesinde açık mı?
• Seçilen tarihler için geçerli olmayan “…’den başlayan” fiyatlar öne çıkıyor mu?

Misafir fiyatı geç gördüğünde yalnızca tutarı değerlendirmez. Otelin neyi sakladığını da düşünmeye başlar.

7. Doğrudan rezervasyon için bir neden var mı ve görünüyor mu?

Akış sorunsuzsa ve fiyat açıksa son soru şudur: misafir neden OTA yerine sizden rezervasyon yapsın? Ana sayfada ve rezervasyon düğmesinin yakınında bunun cevabı görünmüyorsa misafirin alıştığı yere dönmesi için bir engel kalmaz.

Üç hızlı kontrol yapın:

• Doğrudan rezervasyon nedeni: İlk ekranda, rezervasyon düğmesine yakın bir yerde somut bir avantaj var mı? Fiyat eşitliği sözleşmenizi bozmadan neler sunabileceğinizi doğrudan rezervasyon teşvikleri yazımızda anlattık.
• Oda fotoğrafları: Her oda tipinde oda, banyo ve manzara görünüyor mu? Otelinizi hiç görmemiş biri, kalacağı odayı fotoğraflardan anlayabilir mi? Ayrıntılar doğru fotoğraflar yazımızda.
• Yorumlar: Google puanınız ve misafir yorumlarınız yalnızca ayrı bir “Yorumlar” sayfasında mı, yoksa ana sayfada ve oda sayfasında da mı? Hangi güven sinyallerinin nerede durması gerektiğini güven unsurları yazımızda anlattık.

Nereden başlamalısınız?

Her otelde bu yedi sorunun tamamı bulunmaz. En hızlı yol, en büyük kayıp noktasını bulup önce onu düzeltmektir.

İlk kontrol listeniz şöyle olabilir:

1. GA4’te dönüşüm hunisi keşfi kurun. Rezervasyon onayını önemli etkinlik olarak işaretleyin ve en büyük düşüşün hangi adımda olduğuna bakın.
2. Ölçümün doğru olduğundan emin olun. Alanlar arası ölçümü ve istenmeyen yönlendirmeleri kontrol edin; GA4’teki rezervasyon sayısını motorun kendi raporuyla karşılaştırın.
3. Huniyi cihaz kategorisine göre ayırın ve telefondan 3D Secure dahil gerçek bir test rezervasyonu yapın.
4. Mobil PageSpeed puanına ve Core Web Vitals raporuna bakın. Mobil puan 50’nin altındaysa (Yetersiz) hız ilk işleriniz arasında olmalıdır.
5. Vergiler dahil toplam fiyatın ve iptal koşulunun ödeme adımından önce göründüğünü kontrol edin.
6. Doğrudan rezervasyon nedenini, oda fotoğraflarını ve yorumların yerini gözden geçirin.

Önce etkisi en yüksek sorunu düzeltin. Ardından sonucu 30 gün boyunca ölçün. Her şeyi aynı anda değiştirmek, hangi iyileştirmenin işe yaradığını görmeyi zorlaştırır. Hangi kanalın gerçekten rezervasyon getirdiğini görmek için otel analitiği yazımıza da bakabilirsiniz.

Sık sorulan sorular

Otel web sitem neden rezervasyon almıyor?

Trafik varsa kayıp çoğu zaman rezervasyon akışındadır: telefonda tamamlanamayan ödeme, geç görünen toplam fiyat, yavaş açılan sayfalar veya doğrudan rezervasyon için görünür bir nedenin olmaması. Hangisinin sizde olduğunu GA4’teki dönüşüm hunisi keşfiyle, misafirin hangi adımda ayrıldığına bakarak bulursunuz.

GA4’te rezervasyon hunisi nasıl kurulur?

Keşfet bölümünde Yeni bir keşif başlatın altından Dönüşüm hunisi keşfi şablonunu seçin ve adımları akışınıza göre tanımlayın: oda sayfası, rezervasyon motoru, oda seçimi, ödeme ve onay. Rezervasyon onayını ayrıca Yönetici > Veri görüntüleme > Etkinlikler bölümünden yıldız simgesiyle önemli etkinlik olarak işaretleyin.

Rezervasyon motoru başka alan adındaysa GA4 ne yapar?

Ayar yapılmazsa GA4, motora geçen misafiri yeni bir ziyaret gibi sayabilir ve huni ödeme adımında kopuk görünür. Her iki tarafta aynı “G-” kimlikli etiketi kullanın, Alanlarınızı yapılandırın bölümünden iki alan adını ekleyin ve 3D Secure veya ödeme sayfalarını İstenmeyen yönlendirmeleri listeleyin bölümüne yazın.

Türkiye’de Apple Pay ile otel ödemesi alınır mı?

Türkiye, Apple Pay’in desteklenen ülkeler listesinde ve Google Pay’in çevrimiçi ödeme ülkeleri listesinde yer almıyor. Türkiye’deki otel sitelerinde ödeme genelde sanal POS veya lisanslı bir ödeme kuruluşu üzerinden kartla, taksit seçeneği ve 3D Secure doğrulamasıyla alınır. Telefonda test edilmesi gereken akış budur.

PageSpeed puanı kaç olmalı?

Lighthouse’a göre 90–100 İyi, 50–89 İyileştirme gerekli, 0–49 Yetersiz kabul edilir. Puan testten teste dalgalanabildiği için tek ölçüme göre karar vermeyin; gerçek kullanıcı verisi için Search Console’daki Core Web Vitals raporuna da bakın.

Otel web siteniz trafiği rezervasyona çevirmelidir

Doğrudan rezervasyon sorunu çoğu zaman daha fazla trafik satın alarak çözülmez. Önce mevcut misafirin nerede ayrıldığını ölçmek gerekir.

Doğru kurulmuş bir huni, eksiksiz ölçüm, telefonda tamamlanan ödeme, hızlı sayfalar, ödemeden önce görünen toplam fiyat ve doğrudan rezervasyon için görünür bir neden birlikte çalışır. Her biri, misafirin OTA’ya dönmesi için bir nedeni ortadan kaldırır.

Otel web siteniz odalarınızı dolduracak trafiği zaten alıyor olabilir. Asıl soru, trafik sitenize geldikten sonra ne olduğudur.

İlgili Yazılar

• Otel Web Sitesi Dönüşüm Oranı: 7 UX Dersi
• Otel Rezervasyon Motoru Kontrol Listesi
• Otel Web Sitesi Tasarımı: Mobil Optimizasyon Neden Önemli
• Otel Web Sitesi Güven Unsurları: 7 Rezervasyon Sinyali
• Otel KPI’ları ve Doğrudan Rezervasyon