niranar.com'da Arama Nasıl Çalışır? Konum, Tarih ve Filtre Mimarisi

Dört kişilik bir aile, Antalya'da özel havuzlu bir villa arıyor. Tatil tarihleri belli: 12–19 Temmuz. Bu aramayı anlamlı kılmak için sistemin aynı anda beş farklı soruyu yanıtlaması gerekiyor: Bu konum doğru mu? Bu tarihlerde müsait mi? Bu villa dört kişiyi barındırabilir mi? Havuzu var mı? Bütçeye uygun mu? Bu sorulardan herhangi birini yanlış yanıtlamak, alakasız bir sonuç sunmak demek. Hepsini birden doğru yanıtlamak ise gerçekten işe yarar bir arama deneyimi.

niranar.com, Türkiye'nin Akdeniz bölgesindeki tatil kiralama ilanlarını tek platformda toplayan bir pazar yeridir; 300.000'i aşkın aktif ilan barındırır. Bu yazı, platformun arama altyapısına — beş ayrı sorunu nasıl koordine ettiğine, PostgreSQL'i neden özelleştirilmiş bir arama motorunun yerine kullandığına ve harita entegrasyonunun aramaya nasıl mekânsal bir boyut kattığına — odaklanmaktadır. Platform hakkında genel bir giriş yapmak isteyenler niranar.com Ürün Tanıtımı yazısından başlayabilir; bu yazı arama mühendisliğinin derinliklerine inmektedir.

Arama Beş Ayrı Problemdir

Tatil kiralama aramayı basit bir kelime eşleştirmesi olarak düşünmek yanıltıcıdır. "Antalya'da havuzlu villa" yazmak yalnızca bir metin sorgusu değildir — konum çözümleme, uygunluk filtreleme, kapasite eşleştirme, öznitelik filtreleme ve fiyat segmentasyonu olmak üzere beş ayrı işlemin eş zamanlı koordinasyonudur.

Her işlem kendi kurallarına göre çalışır. Konum, metin değil coğrafyadır — "Antalya" aranırken sistemin Antalya şehir merkezini, Kemer'i, Lara'yı ve diğer alt bölgeleri anlamlandırması gerekir. Tarih aralığı ise statik bir veri değil, her mülk için ayrıca tutulan uygunluk takvimiyle karşılaştırılması gereken dinamik bir sorgudur. Misafir sayısı, yalnızca bir sayı değil — kapasite eşleştirme kriteri olarak her mülkün kişi kapasitesiyle ilişkilendirilmesi gereken bir kısıttır.

Bu beş işlemi birbirinden bağımsız çalıştırmak mümkündür; ama bunu doğru sırayla ve hızlı biçimde koordine etmek, kullanıcı deneyimini belirleyen şeydir. 300.000'i aşan ilan hacminde bu koordinasyonun saniyeler içinde tamamlanması gerekir — bir tatil araması kullanıcıya saniyeler içinde anlamlı, filtrelenmiş, uygunluk onaylı sonuçlar sunmak zorundadır.

Bu çerçeveden bakıldığında arama, bir özellik listesi değil, birbirini tamamlayan bileşenlerden oluşan bir sistem haline gelir. Her bileşen, diğerlerinin doğru çalışmasına bağımlıdır. Yanlış bir kapasite eşleştirmesi, tüm sorgunun değerini sıfıra indirir. Uygunsuz bir uygunluk kaydı, müsait olmayan mülkleri sonuçlara karıştırır. Sistemin gücü, tek bir bileşenin tasarımında değil, bileşenlerin koordinasyonunun kalitesinde yatar.

Konum ve Tarih: Aramanın Temeli

Her arama üç zorunlu girdiyle başlar: konum, tarih aralığı ve misafir sayısı. Bu üç girdi birlikte aramanın anlamlı bir başlangıç noktasını tanımlar; bu girdilerin herhangi biri eksik olduğunda sistemin iade edebileceği sonuç seti ya çok geniş ya da anlamsız hale gelir.

Konum Çözümleme

Kullanıcı "Bodrum" yazdığında sistem bunu coğrafi bir referans noktasına dönüştürür. Türkiye'nin Akdeniz ve Ege kıyısındaki en popüler tatil destinasyonları — Antalya, Bodrum, Fethiye, Alanya, Kuşadası, Sapanca — platforma dahildir. Bu destinasyonların her biri binlerce mülkü kapsar; konum çözümleme, kullanıcının girdiği şehir veya bölge adını ilgili mülk havuzuyla eşleştiren ilk filtre adımıdır.

Konum, yalnızca bir metin eşleştirmesi değil — harita boyutunu da tetikleyen bir giriş parametresidir. Kullanıcı liste görünümünde arama yapsa bile, arka planda konum bilgisi mülklerin haritalanabilmesi için kullanılmaktadır. Konum ve harita katmanı birbirinden ayrı değil, birbirini tamamlayan iki veri noktasıdır: birincisi metin girişini işlerken, ikincisi coğrafi koordinatları görselleştirir.

Destinasyonların coğrafi çeşitliliği de bu çözümleme sürecinin kapsamını belirler. Antalya gibi geniş bir il, hem şehir merkezini hem Kemer'i hem Belek'i hem de Alanya gibi alt destinasyonları içerebilir. Bodrum ise yarımada üzerinde onlarca farklı koydan oluşur. Sistem, bu coğrafi derinliği bir bütün olarak yönetmek zorundadır.

Tarih Aralığı ve Uygunluk Takvimi

Giriş ve çıkış tarihleri, uygunluk hesabının temelini oluşturur. niranar.com, her mülk için özel olarak geliştirilen bir takvim uygulaması kullanır. Bu, üçüncü taraf bir takvim hizmeti değil — platformun kendi bünyesinde inşa edilmiş, her mülkün dolu ve müsait günlerini ayrı ayrı izleyen bir sistemdir.

Bu kararın pratik önemi büyük. Bir mülkün 12–19 Temmuz tarihleri arasında müsait olup olmadığını anlayabilmek için sistemin bu tarih aralığını o mülkün uygunluk kaydıyla karşılaştırması gerekir. Özel takvim, bu karşılaştırmanın mülk bazında ve güvenilir biçimde yapılmasını mümkün kılar.

Üçüncü taraf bir takvim hizmetine bağımlı olmamak, platforma önemli bir operasyonel özerklik sağlar. Dış bir hizmet kullanmak, o hizmetin API kısıtlarına, veri formatlarına ve servis sürekliliğine bağımlı olmak anlamına gelir. Özel geliştirme, bu bağımlılıkları ortadan kaldırır ve veri modelinin tamamen platform kontrolünde kalmasını sağlar.

Tarih girişinin arama sonuçları üzerindeki etkisi hem somut hem de kritiktir: seçilen tarihlerde dolu olan mülkler sonuçlara dahil edilmez. Kullanıcı yalnızca gerçekten rezerve edebileceği seçenekleri görür — bu, tatil aramasının en temel kalite göstergelerinden biridir.

Uygunluk ve Kapasite: Görünmez Filtreleme

Konum ve tarih girildikten sonra sistem iki ek kısıtı devreye alır: uygunluk ve kapasite. Bunlar kullanıcının ayrıca belirtmesine gerek kalmadan otomatik işleyen filtrelerdir.

Misafir sayısı girişi, kapasite eşleştirme kriterini aktif hale getirir. Dört kişilik bir grup için arama yapıldığında, yalnızca dört veya daha fazla kişiyi barındırabilen mülkler sonuçlara dahil edilir. İki kişilik bir stüdyo daire, dört kişilik bir arama sorgusunda görünmez. Sekiz kişilik bir grup için arama yapıldığında ise küçük kapasiteli mülkler otomatik olarak elenir. Bu eşleştirme, alakasız sonuçların baştan elenmesini sağlar.

Uygunluk ve kapasite filtrelemesinin değeri, kullanıcının ekranda görmediği şeyin değeriyle ölçülür: seçilen tarihlerde dolu olan ya da grup büyüklüğüne uygun olmayan mülkler zaten listede yer almaz. Kullanıcı, anlamlı bir seçenek havuzuyla karşılaşır.

Bu yaklaşımın doğrudan bir karşılaştırmalı değeri de var. Eğer platform kapasite filtresi uygulamazsa, kullanıcı sekiz kişilik bir tatil için iki kişilik pek çok daire görür ve bunları tek tek inceleyip elimine etmek zorunda kalır. Kapasite eşleştirmesi, bu gereksiz eğlenceyi ortadan kaldırır ve kullanıcının dikkatini gerçekten ilgili seçeneklere yönlendirir.

Öznitelik Filtreleri: Havuz, Plaj, Tür, Fiyat

Konum, tarih ve kapasite aramanın zorunlu parametrelerini oluşturur. Öznitelik filtreleri ise kullanıcının tercihlerini devreye sokan isteğe bağlı kısıtlardır. Bu filtreler, temel parametreler uygulandıktan sonra kalan sonuçları daha da daraltmak için kullanılır.

Mülk Türü

Kullanıcı villa veya daire arasında seçim yapabilir. Bu iki kategori birbirinden temelden farklı bir tatil deneyimini temsil eder. Villa, genellikle özel bahçeli, havuzlu, müstakil bir mülktür — büyük aile grupları ve özel deneyim arayanlar için tercih edilen seçenek. Daire, bir rezidans kompleksinde veya şehir merkezinde yer alan tatil amaçlı kiralık bir birimdir — çiftler ve küçük gruplar için daha erişilebilir bir fiyat noktası sunar.

Mülk türü filtresi, bu iki deneyim setini baştan birbirinden ayırır. Bir kullanıcı villa bakıyorsa daireleri görmesi zaman kaybıdır; tersi de geçerlidir. Bu ayrımın arama sonuçlarına erkenden uygulanması, hem listenin anlamlılığını artırır hem de kullanıcının odaklanmasını kolaylaştırır.

Havuzlu

"Havuzlu" filtresi, yalnızca özel ya da ortak havuza sahip mülkleri getirir. Yazın Türkiye'ye gelen tatilciler için havuz, birincil karar kriterlerinden birini oluşturur. Özellikle aile grupları ve sıcak aylarda tatil yapanlar için havuz bir tercih değil çoğu zaman zorunluluktur.

Bu filtrenin etkin biçimde çalışması, havuz bilgisinin her ilan için güvenilir biçimde tutulmasını gerektirir. 300.000'i aşkın ilan içinde havuz bilgisinin doğruluğunu korumak, veri kalitesi açısından kritik bir alan anlamına gelir. Bir kullanıcı "Havuzlu" filtresiyle arama yapıp havuzu olmayan bir mülkle karşılaşırsa, filtrenin değeri sıfıra iner.

Denize Yakın

"Denize Yakın" filtresi, plaj erişimine sahip veya kıyıya yakın mülkleri öne çıkarır. Özellikle kıyı tatillerinde konum kalitesi, mülk kalitesiyle eşit ağırlık taşır. Bir kullanıcı Fethiye'de denize yürüyüş mesafesinde bir villa arayabilir; ya da Kuşadası'nda plaj erişimi olan bir daire tercih edebilir. Bu filtre olmadan mülkleri tek tek inceleyip konumu manuel olarak değerlendirmek zorunlu hale gelir.

Denize yakınlık kriteri, harita görünümüyle de doğrudan ilişkilidir. Kullanıcı hem "Denize Yakın" filtresini uygulayabilir hem de harita üzerinde kıyı şeridine yakın mülkleri görsel olarak inceleyebilir. İki yaklaşım birbirini tamamlar.

Fiyat Dilimi

niranar.com, tüm ilanları EUR cinsinden fiyatlandırır. Fiyat dilimi filtresi, yaklaşık 50 EUR ve altındaki uygun fiyatlı segmentten premium segmente kadar uzanan bir bant sunar. EUR cinsinden sabit fiyat dilimleri, farklı bütçe dilimlerindeki kullanıcıların hedef aralığı hızlıca belirlemesini sağlar — kur hesabı veya fiyat çevirimi gerekmez.

EUR fiyatlandırması, filtrenin uluslararası kullanıcılar için doğrudan karşılaştırılabilir olmasını sağlar. Türkiye'ye tatile gelen Avrupalı bir misafir, 50 EUR'nun günlük ne anlama geldiğini sezgisel olarak bilir — bu, İspanya'da, Yunanistan'da ya da Hırvatistan'da ödeyeceği miktarla doğrudan kıyaslanabilir bir rakamdır.

Harita Entegrasyonu: Mekânsal Boyut

niranar.com, liste görünümünün yanı sıra Leaflet ile desteklenen bir harita görünümü sunar. Leaflet, açık kaynaklı bir JavaScript haritalama kütüphanesidir — Google Maps değil.

Bu seçim rastlantısal değil, bilinçli bir mühendislik kararıdır. Google Maps API, kullanım başına maliyet içeren bir hizmettir. Her harita yüklemesi, her yer araması ve her konum sorgusu ücrete tabidir. Henüz gelir elde etmeyen bir beta ürününde, bu maliyet yapısı yönetilmesi gereken bir finansal risk haline gelir. Leaflet, açık kaynak olduğu ve kendi barındırılan harita verileriyle çalıştığı için API maliyeti oluşturmaz. Beta aşaması için bu, harita özelliğini ürüne dahil ederken sürdürülebilir maliyet yapısını korumak anlamına gelir.

Kullanıcı deneyimi açısından harita görünümü, liste görünümünün çözemediği temel bir soruyu çözer: "Bu mülk tam olarak nerede?" Tatil kararlarında konum, mülk özelliklerinden çok daha önce gelen bir kriter olabilir.

Bodrum gibi çok farklı mikro bölgelere sahip bir destinasyonda, bir mülkün "Bodrum'da" olduğunu bilmek yeterli değildir. Yalıkavak'ta mı, Gümbet'te mi, Türkbükü koyuna yakın mı? Bu soruların yanıtı tatil deneyimini köklü biçimde değiştirebilir: Türkbükü sakin bir koy deneyimi sunarken Gümbet eğlence mekânlarına yakın hareketli bir ortam demektir. Harita bu soruyu görsel olarak yanıtlar. Kullanıcı, farklı sorgular yazıp denemeden tercih ettiği kıyı şeridini harita üzerinde belirleyebilir.

Harita ile liste görünümü birbirini tamamlar. Bir kullanıcı form bazlı arama ile başlayıp haritaya geçebilir; ya da harita üzerinde bölge seçerek aramayı başlatabilir. Her iki giriş noktası da aynı 300.000+ ilan havuzunu paylaşır ve aynı filtre parametrelerini destekler. Kullanıcı bu iki görünüm arasında serbestçe geçiş yapabilir.

PostgreSQL Arama Motorunun Yerine

niranar.com, arama altyapısı olarak Supabase PostgreSQL sorgularını kullanır. Elasticsearch veya Algolia gibi özelleştirilmiş arama motorları kullanılmamaktadır.

Bu tercih, kısıtlı bir bütçenin sonucu değil — beta aşaması için bilinçli bir mimari karardır. Özelleştirilmiş bir arama motoru, yönetilmesi ve izlenmesi gereken ayrı bir servis demektir: ayrı bir indeksleme süreci, ayrı bir altyapı, ayrı bir maliyet kalemi ve ayrı bir operasyonel sorumluluk alanı. Her ek servis, sistemin toplam karmaşıklığını artırır.

PostgreSQL, doğru sorgu stratejisiyle tatil kiralama aramasının gerektirdiği konum, tarih, kapasite ve öznitelik filtrelerini yönetmek için yeterince güçlüdür. Tatil kiralama aramalarının büyük çoğunluğu yapısal sorgulardır: "şu tarihlerde müsait, şu kapasitede, şu özelliklere sahip, şu konumda mülkler." Bu tür yapısal sorgular PostgreSQL'in güçlü olduğu alandır. Elasticsearch'ün üstün olduğu alan olan tam metin araması — belirsiz, kelime benzerliğine dayalı metin eşleştirmesi — tatil kiralama aramasının merkezinde değildir.

Supabase bu kararı daha da erişilebilir kılar. Supabase, veritabanı, API katmanı ve sunucusuz fonksiyonları tek bir hizmet altında sunar. Tek bir geliştirici, birden fazla sistemi koordine etmek yerine tek bir bütünleşik altyapıyla çalışabilir. Servis sayısını azaltmak, karmaşıklığı azaltmak anlamına gelir — bu da solo geliştirici ortamında sürdürülebilirliği doğrudan artırır.

300.000'i aşan ilan hacminde PostgreSQL ile yürütülen arama, hem yeterli performansı hem de operasyonel sadeliği bir arada sunuyor. Ölçek büyüdükçe ve kullanım kalıpları netleştikçe arama gereksinimleri de değişebilir; ancak beta aşamasının doğru mühendislik kararı, var olan ihtiyacı fazladan karmaşıklık olmadan karşılayan çözümü seçmektir.

Yapısal Veri: Arama Motorlarına Görünürlük

niranar.com, standart sayfa markup'ının ötesinde iki ayrı yapısal veri şeması uygular: schema.org WebSite ve schema.org SearchAction. Bu iki şema doğrudan sayfa başlığına yerleştirilmiştir.

SearchAction şeması, Google'ın sitelinks arama kutusunu etkinleştiren teknik bir uyumluluk adımıdır. Bu özellik etkin olduğunda, bir kullanıcı Google'da "niranar.com" aradığında arama sonuçlarında doğrudan site içi arama kutusu görünebilir. Kullanıcı, niranar.com'a gitmeden önce bile platform içinde arama yapabilir hale gelir.

Bu, kullanıcı deneyimi için değil, arama motoru görünürlüğü için alınmış bir karardır. Tatil kiralama araması büyük ölçüde Google üzerinden gerçekleşir — potansiyel misafirler genellikle bir arama motoru sorgusundan platforma ulaşır. Google arama sonuçlarında sitelinks arama kutusu, bu ulaşım yolunu daha doğrudan hale getirir ve potansiyel kullanıcının platforma girmeden önce arama başlatabilmesine olanak tanır.

WebSite şeması ise sitenin kimliğini ve yapısını arama motorlarına tanıtır — arama kutusunun yanı sıra genel site görünürlüğünü ve indekslemeyi de destekler.

Bu yapısal veri uygulaması, SEO'nun geliştirme sürecine dahil edilmiş bir tasarım kararı olduğunu gösterir — ürün teslim edildikten sonra eklenen bir aksesuar değil. Arama motorlarına görünürlük, mimariye başından beri kazınmış bir gereksinim olarak ele alınmıştır. Tatil kiralama platformlarında organik arama trafiği birincil büyüme kanallarından biridir; bu gerçek, yapısal veri uygulamasının neden erken bir yatırım olduğunu açıklar.

Bu Neler Gösteriyor?

niranar.com'un arama mimarisi, koordineli bir çok-parametre arama sisteminin nasıl inşa edildiğini gösterir. Konum, tarih, kapasite, öznitelik ve fiyat — bu beş boyut tek bir sorguda birleştirilmiş; ardından harita entegrasyonu mekânsal bir boyut eklemiş, yapısal veri ise arama motoru görünürlüğü için zemin hazırlamıştır.

Her karar bağlamla birlikte okunduğunda daha anlamlı hale gelir. PostgreSQL'i özelleştirilmiş bir arama motorunun yerine kullanmak, büyük bir ödün değil — beta aşamasına uygun, operasyonel karmaşıklığı kontrol eden, tek geliştirici tarafından sürdürülebilir bir seçimdir. Leaflet'i Google Maps'in yerine kullanmak, harita özelliğinden vazgeçmeden maliyet yapısını yönetilebilir tutmaktır. Özel takvim uygulaması, uygunluk hesabının üçüncü taraf bağımlılığı olmadan güvenilir biçimde çalışmasını sağlar.

Bu tür mühendislik kararları — kapsamı, maliyeti ve karmaşıklığı aynı anda düşünerek tasarlanmış — pazar yeri arama sistemleri inşa etme konusundaki pratiği gösterir. Benzer bir çok-parametre arama, uygunluk filtreleme, harita entegrasyonu ve yapısal veri gerektiren bir proje düşünüyorsanız, niranar.com bu problemlerin gerçek dünyada çözülmüş halini görmek için somut bir referans noktasıdır.

Sonuç

niranar.com'un araması, beş problemi koordine eden bir sistemdir. Konum ve tarih temeli atarken özel takvim uygunluk hesabını güvenilir kılar. Kapasite eşleştirmesi alakasız sonuçları baştan eler. Öznitelik filtreleri kullanıcının gerçek tercihlerini devreye sokar. Leaflet haritası mekânsal boyutu görselleştirir ve konum kararını bilinçlendirirken maliyeti yönetilebilir tutar. PostgreSQL bu koordinasyonun tamamını ek servis karmaşıklığı olmadan yönetir. Yapısal veri ise bu deneyimi arama motorlarının da anlayabileceği bir biçimde sunar.

Bu arama altyapısının dayandığı teknik mimariye genel bakış için niranar.com'un Teknik Mimarisine göz atabilirsiniz. Platformun ürün kararları ve beta strateji açısından nasıl şekillendiğini merak edenler için bu seri kapsamındaki diğer yazılar da ilgili bağlamı sunmaktadır.