Otel Web Sitesi Nasıl Olmalı? Rezervasyon Mimarisi, Teknik SEO ve Yapay Zekâ Görünürlüğü

Bir misafir otelinizi bir rezervasyon platformunda bulduktan sonra kendi sitenize geliyor. Üç gece için oda arıyor; fotoğraftaki odanın iki çocukla uygun olup olmadığını, otoparkın ücretini ve iptal koşulunu öğrenmek istiyor. Ana sayfa etkileyici olsa bile bu sorular yanıtlanmıyorsa telefon açıyor veya alışverişini başka kanalda tamamlıyor. Otel web sitesinin işi, güvenilir bilgiyle başlayan bu yolculuğu işletmenin gerçekten yerine getirebileceği bir rezervasyona bağlamaktır.

Bu rehber bağımsız otel, apart ve küçük konaklama gruplarının sahipleri ile teknik karar vericileri içindir. Örneğimiz, farklı oda tipleri ve bir PMS kullanan temsili bir işletmedir; müşteri vakası veya ölçülmüş başarı iddiası değildir. Temel karar şudur: siteniz rezervasyon talebi mi toplayacak, mevcut rezervasyon motoruna mı bağlanacak, yoksa özel işlem akışı mı yönetecek? Bu üç işi aynı bütçe ve teslim sözüyle değerlendirmeyin.

1. Profesyonel otel sitesi hangi işi çözmeli?

OTA, yani çevrim içi seyahat acentesi, keşif ve dağıtım sağlayabilir. Kendi siteniz ise oda farklarını anlatma, gruplardan talep toplama, işletme politikalarını açıklama ve tekrar gelen misafirle ilişki kurma alanınızdır. Bu kanallar birlikte çalışabilir. Her OTA rezervasyonunun aynı maliyetle doğrudan kanala taşınabileceğini varsaymak, yeni misafir bulmanın bedelini yok sayar.

• Butik otel: az sayıdaki oda tipinin farkını, gerçek fotoğrafları ve ulaşımı netleştirin; mevcut motor yeterliyse yeniden motor yazdırmayın.
• Apart: daireye özel envanter, minimum konaklama, kişi kapasitesi, mutfak ve temizlik koşullarını modelleyin. Her daire tekilse oda tipi havuzundan farklı stok kuralı gerekir.
• Çok tesisli işletme: tesis, oda, para birimi, yerel saat ve yetki sınırlarını ayırın. Bir otelin fiyatını başka tesisin sayfasında göstermeyin.

Önce mevcut işleyişi haritalayın: müsaitliği kim yönetiyor, iptali kim onaylıyor, gece satışa kapanma nerede işleniyor, telefon rezervasyonu ne zaman stoktan düşüyor? Tasarım kararı bu cevaplardan çıkar. Eksik iş kuralını güzel bir takvim bileşeni tamamlayamaz.

2. OTA ve doğrudan rezervasyon: gerçek maliyet nasıl karşılaştırılır?

Booking.com için herkese uygulanan tek bir komisyon oranı varsaymıyoruz. Kendi sözleşmeniz, tahsilat modeli ve faturanızdaki fiilî maliyeti alın; no-show, iade, indirim ve vergilerin hesabını aynı zeminde yapın. Aşağıdaki oranlar yalnız hesap yöntemini göstermek için seçilmiştir, platform tarifesi değildir.

Varsayımsal, aynı netleşmiş konaklama geliri: 12.000 TL
OTA etkin dağıtım maliyeti varsayımı: %15 -> 1.800 TL
Doğrudan ödeme varsayımı: %3 -> 360 TL
Rezervasyon motorunun işlem bedeli varsayımı: %1 -> 120 TL
Ek müşteri edinimi + destek varsayımı: 500 TL
Doğrudan değişken maliyet: 980 TL
Senaryo farkı: 1.800 - 980 = 820 TL / gerçekleşen rezervasyon
Aylık ek sabit işletim gideri 8.200 TL ise: 8.200 / 820 = 10 rezervasyon
Bu, yalnız sabit işletim giderini karşılar; ilk geliştirme yatırımını içermez.

820 TL, oda gelirinden elde edilen kâr değildir; iki kanalın varsayımsal dağıtım gideri farkıdır. İlk yatırım, yıllık bakım, iade kayıpları ve finansman ayrıca değerlendirilir. Reklamla edinilen rezervasyonun maliyeti 500 TL’den yüksekse avantaj azalır veya kaybolur. Mevcut OTA müşterisinin kanalı değişmesiyle gerçekten yeni talep oluşmasını da ayrı ölçün.

3. Doğrudan rezervasyon sistemi nasıl çalışır?

Public room pages / CMS       Guest selects dates and occupants
          |                                  |
          |                           Booking engine / server
          |                                  |
          |                     Authoritative inventory + rate plan
          |                                  |
          |                           Expiring quote / hold
          |                                  |
          |                         Hosted payment provider
          |                                  |
          |                     Verified result + durable booking
          |                                  |
          +---- no private data ----> PMS / channel manager
                                     |           |
                                OTA updates   Reconciliation

Tarih ve kişi seçimi, satılabilir oda tipi ile fiyat planını sorgular. Fiyat planı; kahvaltı, esneklik, minimum gece, girişe kapalı gün ve çocuk yaşları gibi kuralları taşır. Sonuçta gecelik dağılımı, para birimi, toplam, vergi/ek ücret bilgisi, iptal koşulu sürümü ve geçerlilik süresi olan bir teklif oluşur. Tarayıcıdan gelen toplam tutar ödeme emri olarak kabul edilmez; sunucu doğrular.

İletişim formu, WhatsApp bağlantısı veya “rezervasyon talebi alındı” e-postası kesin oda onayı değildir. Envanteri bağlayamıyorsanız ekranda talep/teyit ayrımını açık yazın. Entegrasyon yapılabiliyorsa mevcut PMS veya rezervasyon motorunun belgelenmiş hold ve onay sözleşmesini kullanın. API erişimi, sağlayıcı izni ve test ortamı proje başlamadan doğrulanmalıdır.

Ödeme sağlayıcısındaki dönüş URL’si başarı kanıtı sayılmaz. Sunucu, imzalı bildirimi ve sağlayıcı durumunu doğrular; tutar, para birimi ve rezervasyon eşleşmesini kontrol eder. Aynı bildirim tekrar geldiğinde ikinci rezervasyon oluşmaz. Kart verisini kendi formunuzda toplamak yerine uygun barındırılmış ödeme akışı tercih edin; entegrasyonun güvenlik yükümlülükleri sağlayıcı ve işletmeyle ayrıca netleştirilir.

4. Son oda iki kanalda satılırsa: envanter ve hata mimarisi

PMS tesis operasyonunu, channel manager dağıtım kanallarını, booking engine misafirin satın alma akışını yönetir; bir ürün birden fazla rol üstlenebilir. Hangi sistemin satılabilir envantere son kararı verdiğini yazılı belirleyin. CMS oda açıklamasının kaynağı olabilir; müsaitlik otoritesi olmamalıdır. Booking.com rezervasyon belgeleri, yeni, değişen ve iptal edilen rezervasyonların teslimini ve envanter kopyalarının güncellenmesini ayrı operasyonlar olarak ele alır.

Property(id, timezone, default_currency)
RoomType(id, property_id, code, max_occupancy)
RoomTypeTranslation(room_type_id, locale, slug, description)
RatePlan(id, room_type_id, meal_plan, cancellation_policy_version)
NightInventory(property_id, room_type_id, stay_date, allocation, held, sold)
Quote(id, rate_plan_id, arrival, departure, occupants, currency,
      nightly_amounts, taxes, total, expires_at, policy_version)
Booking(id, property_id, quote_id, status, external_pms_id)
BookingRequest(property_id, idempotency_key, request_hash, booking_id)
PaymentAttempt(id, booking_id, provider_reference, state)
Outbox(event_id, booking_id, event_type, payload)

UNIQUE(property_id, idempotency_key)
UNIQUE(property_id, room_type_id, stay_date)
Money: integer minor units + explicit currency; never binary float.
Stay interval: [arrival, departure), in the property's local calendar.

Üç gecelik konaklama üç ayrı gece için yeterli kapasite gerektirir. Giriş tarihi dahildir, çıkış günü gece sayısına dahil değildir. Geceyi otelin yerel takviminde tutun; mesaj ve ödeme olaylarının zamanını ayrıca UTC ile kaydedin. Erken giriş, yatak kapasitesi ve yetişkin/çocuk fiyatlaması tek bir “kişi sayısı” alanına sıkıştırılmamalıdır.

# Architectural pseudocode; not a ready-to-run PMS adapter.
# Valid only for inventory this ledger is authorized to allocate.
with db.transaction():
    request = admit_idempotent_request(property_id, key, request_hash)
    if request.already_exists:
        return same_result_or_conflict(request, request_hash)
    nights = lock_nights_in_date_order(room_type, arrival, departure)
    if len(nights) != expected_nights or any(n.free < quantity for n in nights):
        raise Unavailable()  # rollback the entire stay
    hold = create_hold(nights, quantity, expires_at, quote_id)
    write_outbox("hold.created", hold.id)
# No payment/network request inside the inventory transaction.
# Expiry and payment finalization must lock the SAME hold and check state.
# A late successful payment cannot confirm an expired/reallocated hold.
# Reconcile uncertain outcomes; refund/review when inventory is unavailable.

Bu yerel kilit yalnız bu defterin yönettiği envanteri korur. OTA ve resepsiyon başka bir otoritede satış yapıyorsa web veritabanındaki kilit tüm kanallarda çifte satışı engellemez. Sağlayıcının atomik rezervasyon API’sini, açık kanal tahsisini veya teyit bekleyen talep modelini seçin. Gecikmeli senkronizasyonda sıfır overbooking garantisi vermeyin.

Dayanıklı kayıtla dış sisteme bildirim arasında outbox kullanmak, yeniden denemeleri takip etmek ve periyodik mutabakat yapmak gerekir. Mutabakat; web, PMS, ödeme ve kanal rezervasyon kimliklerini karşılaştırır. Operatör hangi kayıtların belirsiz kaldığını görebilmelidir. Genel uygulama ayrıntıları için API ve sistem entegrasyonu rehberine bakabilirsiniz.

5. Oda, dil ve lokasyon sayfaları nasıl modellenir?

Kalıcı bir oda kimliğini çevrilmiş metin ve slug’dan ayırın. “Standart çift kişilik” oda iki dilde aynı oda tipine bağlanır; fiyat planı ve fiziksel kapasite çevrilmez, açıklama ve politika metni yerelleştirilir. Her dilin yayın/onay durumu ayrı olmalıdır. Eksik İngilizce sayfayı Türkçe metinle doldurup İngilizce gibi işaretlemeyin.

Oda detayında gerçek fotoğraf, metrekare, yatak düzeni, kişi kapasitesi, manzara, erişilebilirlik ayrıntısı ve dahil/ücretli hizmet ayrımı bulunmalı. “Engelli dostu” demek yerine ölçülmüş kapı açıklığı veya basamaksız giriş gibi teyit edilmiş özellikleri verin. Apartlarda görselin kategoriye mi belirli daireye mi ait olduğunu açıklayın.

Lokasyon sayfası otelin gerçekten bulunduğu yere hizmet etmelidir. Havalimanından ulaşım, park girişi ve yakındaki somut noktalar yararlıdır; hizmet vermediğiniz onlarca ilçeye aynı metinle açılan sayfalar bilgi sağlamaz. Yolculuk süresini trafik koşulundan bağımsız garanti etmeyin. Yerelleştirme; yalnız cümle çevirisi değil, tarih, para birimi ve misafirin bilgi ihtiyacıdır.

6. Otel web sitesinde teknik SEO kontrolü

• İndekslenmesi amaçlanan oda/tesis sayfaları gerçek 200 yanıtı, okunabilir ana içerik, tek açıklayıcı H1 ve özgün title/açıklama üretmeli; kaldırılan URL uygun 404/410 veya gerçek karşılığına yönlendirme almalı.
• Her dil sürümünde uygun kendi canonical URL’sini kullanın; karşılıklı hreflang bağlantılarını ve sitemap’teki URL’leri eşleştirin. İngilizceyi topluca Türkçeye canonical vermeyin.
• Tarih, kişi, promosyon ve sıralama parametreleri için tarama politikası belirleyin; her arama sonucunu yeni SEO sayfasına çevirmeyin. Rezervasyon, ödeme ve kişisel teyit ekranları public indeks ve ortak cache dışında kalmalı.
• Oda açıklamalarını sunucuda okunabilir HTML ile sunun. Fotoğraflara boyut tanımlayın, uygun biçim/boyut üretin; ana görseli geciktirmeyin, gereksiz galeri ve sohbet JavaScript’ini sınırlayın.

Canonical bir tercih sinyalidir; farklı içerikleri otomatik olarak birleştiren kesin emir değildir. Canonical kılavuzu ve dil sürümleri belgesi bu iki mekanizmayı ayrı açıklar. Robots ile engellenmiş sayfadaki noindex etiketi okunamayabilir; önce erişim ve indeksleme hedefini ayırın.

Mobil gerçek kullanıcı deneyiminde Core Web Vitals için iyi eşikler LCP ≤ 2,5 saniye, INP ≤ 200 ms, CLS ≤ 0,1’dir; 75. yüzdelikte değerlendirilir. Laboratuvar raporu alan verisinin yerine geçmez. Otelde oda galerisi kadar takvim, kişi seçici ve harici rezervasyon motoruna geçişi de test edin. Hız iyileşmesinden doğrudan belirli gelir artışı türetmeyin.

7. Hotel ve HotelRoom yapılandırılmış verisi

Hotel tesisi, HotelRoom oda bilgisini tanımlar. Kararlı @id değerleriyle ilişki kurun. Aşağıdaki alan adı, tesis ve oda tamamen örnektir; oda tipi sayfasının basit modelini gösterir. Gerçek projede tekil oda ile satılan oda kategorisinin ayrımını veri sözleşmesine yazın.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Hotel",
      "@id": "https://hotel.example/#hotel",
      "name": "Example Courtyard Hotel",
      "url": "https://hotel.example/en/",
      "address": {
        "@type": "PostalAddress",
        "addressLocality": "Ankara",
        "addressCountry": "TR"
      },
      "containsPlace": {
        "@id": "https://hotel.example/#standard-double"
      }
    },
    {
      "@type": "HotelRoom",
      "@id": "https://hotel.example/#standard-double",
      "name": "Example standard double room",
      "url": "https://hotel.example/en/rooms/standard-double",
      "containedInPlace": {
        "@id": "https://hotel.example/#hotel"
      },
      "occupancy": {
        "@type": "QuantitativeValue",
        "maxValue": 2,
        "unitCode": "C62"
      },
      "bed": "1 double bed",
      "floorSize": {
        "@type": "QuantitativeValue",
        "value": 24,
        "unitCode": "MTK"
      }
    }
  ]
}

Bu kod öğretici örnektir; TankDev sayfasının çalıştırılan JSON-LD’sine sahte otel olarak eklenmez. Gerçek otelde işaretlenen kapasite, ölçü ve adres görünür içerikle eşleşmelidir. Tesisin yıldız sınıfı ile misafir puanını karıştırmayın; doğrulanmamış yorum, aggregateRating veya sahte sameAs üretmeyin. Offer kullanılıyorsa tarih, fiyat planı, para birimi, fiyat geçerliliği ve koşulları gerçekten sunulan teklifle uyumlu olmalıdır; değişken gecelik fiyatı kalıcı bir ürün fiyatı gibi sabitlemeyin.

Schema.org sözlüğüne uygun olmak, Google’da belirli bir otel görünümü veya Hotel Ads entegrasyonu kazanmakla aynı şey değildir. Google yapılandırılmış veri ilkeleri uygunluk ile gösterim garantisini ayırır. Kod örneğini Schema Markup Validator’da; desteklenen Google özelliklerini Rich Results Test’te ayrıca kontrol edin.

8. SEO ve GEO: otel markası için doğrulanabilir sinyaller

SEO; sayfanın keşfi, teknik uygunluğu ve arama niyetini karşılamasıyla ilgilenir. GEO ise üretken arama yanıtlarında bilgi veya kaynağın nasıl temsil edildiğini inceleyen çalışma alanıdır. GEO araştırması kontrollü bir değerlendirme çerçevesi sunar; bulgularını oteliniz için sabit etki oranı veya platform sıralama kuralı gibi kullanmak doğru değildir. İndekste yer alma, marka anılması, kaynak bağlantısı ve tavsiye birbirinden farklı sonuçlardır.

Google’ın AI özellikleri belgesi, temel SEO’nun geçerli olduğunu ve özel AI dosyası ya da ayrı schema gerekmediğini belirtir. Bu Google kapsamındaki açıklama, bütün asistanların aynı kaynak seçimini yaptığı anlamına gelmez. Bir dosya ekleyerek ChatGPT veya Gemini tavsiyesi garanti edilemez.

• Otelin adı, adresi, telefonu ve resmî alan adını site ve işletme profillerinde tutarlı tutun; yanlış veya kapanmış kayıtları düzeltin.
• Gerçek oda özelliklerini, erişilebilirlik bilgisini, konumu ve değişiklik tarihini kaynak sahibi editörle yayınlayın. Kopya “en iyi otel” paragrafları yerine misafirin somut sorularını yanıtlayın.
• Aynı isimli farklı otelleri karıştırmayacak tesis kimliği kurun; sameAs yalnız o işletmeye ait doğrulanmış profilleri bağlasın.
• TankDev için de şirketin kimliği, açıklanmış hizmet kapsamı, teknik rehberler ve incelenebilir çalışmalar önemlidir. Bu yazı, TankDev’in yayımlanmamış otel müşterileri veya otel gelir artışı bulunduğu iddiasını taşımaz.

TankDev’in kendi sitesindeki SEO/GEO uygulama vakası, erişim, kimlik ve gözlemlenen kaynak gösterimlerini belgeliyor; otel sektöründe elde edilmiş sonuç olarak sunulmamalı. Genel mekanizmaları tekrar etmek yerine ayrıntılar için Google görünürlüğü ve ChatGPT görünürlüğü rehberlerimize bağlantı veriyoruz.

9. Hazır tema mı, özel yazılım mı?

WordPress veya hazır tema kendiliğinden yavaş değildir; özel Next.js kodu da kendiliğinden hızlı ya da güvenli değildir. WordPress performans belgeleri barındırma, yazılım ve cache etkilerini açıklar. Mevcut motor ihtiyacı karşılıyorsa özel bir otel sitesi onun üzerinde çalışabilir. Motoru sıfırdan yazmak; tarih/kapasite, ödeme, iptal ve operasyon desteği yükünü de üstlenmektir.

10. Essential ve Advanced otel işletmesine ne sağlar?

8 Kasım 2026’da kontrol ettiğimiz paket sayfasına göre Essential 50.000 TL, Advanced 150.000 TL başlangıç bedelindedir. Kapsam ve bedel, ihtiyacın değerlendirilmesiyle teklif üzerinde netleşir. Aşağıdaki eşleştirme otel projesi için karar desteğidir; henüz yapılmamış entegrasyonu pakete dahilmiş gibi sunmaz.

Essential; önce doğru bilgi veren ve rezervasyon yoluna net geçiş sağlayan bir siteye ihtiyacı olan işletme için başlangıç olabilir. Advanced; işletme kimliği, dış profil tutarlılığı ve kaynak gösterimi gözlemlerini ayrıca ele almak isteyen işletmeye yöneliktir. İki pakette de oda sayfası adedi, dil sayısı, çeviri sorumlusu, motor lisansı ve entegrasyon geliştirmesi teklifte açıkça yazılmalıdır. Advanced, PMS geliştirme paketi veya rezervasyon artışı garantisi değildir.

11. Başarıyı hangi verilerle ölçmelisiniz?

Oda görüntüleme → tarih arama → uygun teklif → ödeme başlangıcı → kalıcı rezervasyon → gerçekleşen konaklama zincirini kurun. Motor başka alan adındaysa izinli ve belgelenmiş çapraz alan adı ölçümünü planlayın. Başarı sayfasını yenilemek ikinci satış sayılmamalı; booking_id ile tekrarları ayırın. İptal ve iade sonrası netleşen sonuçları PMS ve finans kayıtlarıyla uzlaştırın.

AI gözleminde iki ayrı sorgu paneli kullanın: “Ankara’da aileye uygun apart” otelin bulunmasını; “otel rezervasyon sistemi geliştiren yazılım şirketi” TankDev’in hizmet alakasını sınar. Platform, model/arama modu, dil, ülke, tarih, yanıt, kaynak URL ve sayfa sürümünü kaydedin. Tek başarılı cevap kalıcı görünürlük kanıtı değildir. Referral eksikliği de marka hiç anılmadı demek değildir.

Ticari tarafta nitelikli talebi ayrıca tanımlayın: tesis türü/oda sayısı, mevcut PMS, dil ve entegrasyon ihtiyacı, bütçe ve hedef tarih belli mi? Forma kimlik belgesi veya kart bilgisi istemeyin. Misafir, çalışan ve ticari talep verilerini yetki, saklama ve loglama açısından ayırın. Ölçümde kişisel veriyi URL’ye veya AI sorgusuna taşımayın.

12. Teklif ve teslim için kabul listesi

• Envanter: son oda için eşzamanlı iki talep, gece aralığında bir günün dolu olması, resepsiyon/OTA satışı ve minimum gece kuralları sınandı mı?
• Ödeme: çift webhook, zaman aşımı, geç ödeme, kısmi iade ve iptal tekrarında beklenen sonuç yazıldı mı?
• İçerik: iki dilde oda/politika eşleşmesi, kendi canonical, karşılıklı hreflang ve iç bağlantılar doğrulandı mı?
• Mobil deneyim: 360 px ekranda takvim ve misafir seçimi, klavye erişimi, hata mesajı, oda görseli ve ödeme geçişi kontrol edildi mi?
• Operasyon: belirsiz işlemler ekranı, mutabakat, uyarılar, geri yükleme, kaynak kod ve sağlayıcı hesaplarının devri tanımlı mı?

Otel web sitesi projesine başlarken mevcut motor/PMS adını, tesis ve oda tipi sayısını, dilleri, iptal kurallarını ve iki örnek rezervasyon senaryosunu hazırlayın. TankDev ile web paketlerini karşılaştırabilir veya tesisinizin ihtiyacını paylaşabilirsiniz. Önce hangi akışın hazır ürünle karşılanacağını, hangisinin özel geliştirme gerektirdiğini belirlemek teklifin doğruluğunu artırır.

Kaynaklar ve kapsam notu

Kaynaklar 8 Kasım 2026’da kontrol edildi. Yukarıdaki mimari ve maliyet örnekleri TankDev’in açıklayıcı tasarım önerileridir; gerçek müşteri performansı değildir. Paket bilgisi mevcut hizmet sayfasından alınmıştır. Kaynaklar ürün kuralları ve teknik tanımlar içindir; sektör geneline ait uydurma dönüşüm/komisyon istatistiği kullanılmamıştır.

• Booking.com: reservation delivery and inventory
• Google: canonical URLs
• Google: localized page versions
• Schema.org: Hotel
• Schema.org: HotelRoom
• Google: structured data policies
• Google: AI features and your website
• GEO research: Aggarwal et al.
• Google: Web Vitals
• WordPress: performance optimization
• Google: Search documentation updates