Site içi arama ve otomatik tamamlama

Kısaca

Otomatik tamamlama, kullanıcı arama kutusuna yazarken kutunun altında sorgu ve ürün önerileri gösterir. İyi bir site içi aramada kutu sayfanın üstünde durur ve tipik bir sorguyu sığdıracak kadar geniştir. Öneri listesi kısadır, Türkçe karakter ve yazım hatasını tolere eder. Sonuç çıkmazsa ekran bir çıkış yolu sunar. Listenin tamamı klavyeyle de kullanılır.

Kısaca

Ne aradığını bilen ziyaretçi menüde dolaşmaz, aklındaki kelimeyi arama kutusuna yazar. Otomatik tamamlama bu kelimeyi daha yazılırken tamamlar ve ziyaretçiyi doğru sonuca kısa yoldan götürür.

Bu kalıp dört parçadan oluşuyor: kutunun yeri, öneri listesi, yazım hatalarına tolerans ve sonuç çıkmadığında gösterilen ekran. Dördünün de klavyeyle ve ekran okuyucuyla çalışması gerekiyor. Sırayla anlatıyorum; sayfanın ortasında kendiniz deneyebileceğiniz bir örnek de var.

Arama kutusu nerede ve ne kadar büyük olmalı

Ana sayfada arama bir bağlantı değil, yazılabilir bir kutu olmalı. Jakob Nielsen bunu 2001'de "Search: Visible and Simple" yazısında söyledi. Kendi sitesi useit.com'da bağlantıyı kutuya çevirince arama kullanımı yüzde 91 artmış.

Nielsen'e göre kutunun yeri sayfanın üstü, genelde sağ üst köşe. Sol tarafın da neredeyse aynı iyi çalıştığını ekliyor. Ziyaretçi kutuyu orada bekler. Başka yere koyarsanız önce kutuyu bulmak zorunda kalır.

Boyut için Nielsen kesin bir karakter sayısı vermiyor. Kutu tipik bir sorguyu sığdıracak kadar geniş olmalı. Kutu darsa uzun bir sorgunun başı sola kayar ve görünmez olur ve kutuyu kullanmak zorlaşır.

Mobilde asıl sorun, listenin açılacağı alan. Baymard, yapışkan başlıkların, canlı destek balonlarının ve uygulama reklamlarının öneri listesine yer bırakmadığını gösteriyor. Bir örnekte ekranda yalnızca 2 öneri, o da yarı kapalı görünüyordu; kullanıcı sorgunun tamamını kendisi yazdı. Mağaza tarafının geri kalanını e-ticaret UX rehberinde anlattım.

Öneriler: sorgu önerisi ve ürün önerisi

Baymard'ın 2022 ölçümüne göre e-ticaret sitelerinin yüzde 80'inde otomatik tamamlama var. 2014'teki ilk ölçümde bu oran yüzde 72'ydi. Ama her ayrıntıyı doğru yapan sitelerin oranı yalnızca yüzde 19.

İki tür öneri var. Sorgu önerisi kullanıcının yazdığını tamamlar: "kaz" yazana "kazak" önerir ve arama sonuç sayfasına götürür. Ürün önerisi doğrudan bir ürünü ya da kategoriyi gösterir ve tıklayınca o sayfayı açar.

Kate Moran, NN/g'deki yazısında zengin önerilerin, yani ürün ve kategori bağlantılarının ölçülü kullanılmasını istiyor. Mobilde ise yalnızca düz metin öneriler gösterilmeli. Kategoriyle sınırlı bir arama, örneğin "kazak, Kadın giyim içinde", sorgudan ayrı görünmeli. Baymard da aynı görüşte. İtalik yazı, farklı renk ya da girinti işe yarıyor; testlerde hiçbiri ötekilerden iyi çıkmamış.

Kaç öneri

Baymard'ın sınırı masaüstünde en fazla 10 öneri, mobilde 4 ile 8 arası. Testlerde fazla öneri seçim felcine yol açmış: kullanıcı önerileri ya görmezden gelmiş ya da okumaya çok zaman harcamış. Liste kendi boyunda açılmalı, içinde kaydırma çubuğu olmamalı.

Moran'ın kuralı daha basit: önerdiğiniz her sorgunun gerçekten iyi sonuçları olsun. Sıfır sonuç getiren bir öneri, kullanıcıyı kendi önerinizle çıkmaza sokar. NN/g'nin testinde öneriler 136 kez göründü ve kullanıcılar bunların 31'inde, yani yüzde 23'ünde bir öneri seçti.

Liste sade ve dokunulabilir olsun

Baymard masaüstünde görsel gürültüyü azaltmayı öneriyor. Fazla boşluk, ayırıcı çizgiler, sırayla değişen satır renkleri ve ek içerik asıl önerileri gölgede bırakıyor. Trend aramalar buna örnek. Liste açıkken sayfanın arka planını karartmak da reklam ve kayan görsellerin dikkat dağıtmasını azaltıyor.

Mobilde Baymard yazının ve dokunma hedefinin yeterince büyük olmasını, satırlar arasında da boşluk kalmasını istiyor. Küçük yazı ve sık satır yanlış dokunmaya yol açıyor. Tamamı büyük harf yerine kelimelerin baş harfi büyük yazılmalı. Dokunma hedefinin ölçüsünü dokunma alanı kalıbında anlattım.

Hangi kısım kalın olmalı

Burada iki kaynak farklı şey söylüyor. Baymard, kullanıcının yazdığı kısmı değil, tamamlanan kısmı vurgulamayı öneriyor. Moran ise iki durumu ayırıyor. Öneriler yazılanın sonuna ekleme yapıyorsa eklenen kısmı vurgulayın. Yazılan kelime önerinin ortasında da geçiyorsa yazılan kısmı vurgulayın.

Aşağıdaki örnekte "kazak" kelimesi "Balıkçı yaka kazak" gibi ürünlerin ortasında da geçiyor. Bu yüzden Moran'ın ikinci kuralını uyguladım ve eşleşen kısmı kalın yazdım. Böylece kelimenin ürün adının neresinde geçtiği ilk bakışta görülüyor.

Yazım hatası ve Türkçe karakter toleransı

Türkçe bir mağazada yazım hatasından önce klavyeyi düşünün. Kullanıcı "şal" yerine "sal", "gömlek" yerine "gomlek" yazar. Arama bunları aynı kelime saymıyorsa ürün stokta olsa da "sonuç yok" der.

Büyük küçük harf de tuzak. JavaScript'te büyük "İ" harfini İngilizce kurala göre küçültürseniz sonuç düz "i" olmaz, üstünde fazladan bir nokta kalır. MDN belgesi bunu "İstanbul" örneğiyle gösteriyor; Türkçe yerel ayarla küçültünce düz "istanbul" elde ediliyor. Aynı tuzak "I" harfinde ters yönde çalışır: Türkçede küçüğü "ı" olur.

Örnekte bu yüzden iki adım var. Önce harfleri Türkçe kurala göre küçültüyorum, sonra ı, ş, ğ, ü, ö ve ç harflerini düz karşılıklarına çeviriyorum. Sorgu ve ürün adı aynı biçime gelince ikisini karşılaştırıyorum. "islak" yazan "Islak mendil" ürününü bulur.

Gerçek yazım hataları için daha fazlası gerekir. Baymard'a göre ürün adını kulaktan duyan ve nasıl yazıldığını bilmeyen kullanıcılar var. Bu yüzden sesli yazım hatalarını tolere etmek şart. Aynı ürünün farklı ve yerel adlarını da tanımak gerekiyor. Baymard'a göre sitelerin yüzde 56'sı kullanıcıların arama ihtiyacını yeterince karşılamıyor.

Canlı örnek: erişilebilir otomatik tamamlama

Aşağıdaki kutu, bu sayfa için yazdığım kurgusal bir mağaza kataloğunda arıyor. İlk satır her zaman yazdığınız kelimenin aramasıdır, italik yazılır ve kaç ürün olduğunu söyler. Altındaki satırlar ürün önerileridir, sağlarında kategori yazar.

Erişilebilir otomatik tamamlama

Örnek: arama kutusuna “kaz” yazınca açılan liste

  • Kazak, örgü, kremKadın giyim
  • Balıkçı yaka kazakErkek giyim
  • Çocuk kazağıÇocuk
  • Kaşmir kazakErkek giyim
  • Yün kazakKadın giyim

JavaScript kapalı olduğu için örnek sabit. Açıkken kutuya kendiniz yazabilirsiniz.

Kurgusal bir giyim mağazasının arama kutusu. “kazak”, “sal” ya da “gomlek” yazın: Türkçe karakter ve büyük küçük harf farkı tolere edilir. Ok tuşlarıyla gezin, Enter ile seçin, Esc ile kapatın. “kazk” gibi hatalı bir kelime sonuç yok ekranını gösterir.

Ok tuşuyla bir ürüne geldiğinizde ürün adı kutuya kopyalanır. Baymard bunu öneriyor, çünkü kullanıcı önerilen sorguya ayrıntı ekleyip öyle arayabilir. Esc'e basınca kutuya sizin yazdığınız geri gelir.

Sonuç yok ekranı

Baymard'a göre sitelerin neredeyse yarısı, sonuçsuz bir aramadan sonra kullanıcıya etkili bir çıkış yolu sunmuyor. Kötü kurulmuş bir sonuç yok ekranı, ziyaretçinin siteyi bırakmasını kolaylaştırır. Sonuç yok ekranı da bir boş durumdur ve aynı ilkelerle kurulur.

Kathryn Whitenton'ın NN/g için yazdığı üç ilke kısa: sonuç olmadığını açıkça söyleyin, ilerlemek için başlangıç noktaları verin, kullanıcıyla dalga geçmeyin. Baymard bir uyarı ekliyor: yalnızca arama ipuçları yazmak yetmez, kullanıcılar ipuçlarını nadiren okuyor.

Baymard'ın önerdiği çıkış yolları şunlar:

  • Sorguyla ilgili daha geniş kategoriler, tercihen filtrelenmiş bir ürün listesine bağlı.
  • Sorgunun sadeleştirilmiş halleri ve her biri için ilk 3 ile 5 ürünün önizlemesi. Yalnızca bir alternatif sonuç veriyorsa onu bir notla otomatik uygulamak.
  • Kullanıcının gezinme geçmişine dayalı öneriler.
  • Satış telefonu, canlı destek ve yardım bağlantıları.
  • Çok satan ürünler ve popüler kategoriler.

Örnekte "kazk" yazınca "Şunu mu demek istediniz?" altında "kazak" çıkıyor, yanında da popüler aramalar var. Sonuç yok ekranı bazen yazımdan değil, açık kalmış bir filtreden çıkar. Filtreler açıkken sıfır sonuç gösteren listeyi filtre ve sıralama kalıbında ayrıca anlattım.

Klavyeyle gezme

Öneri listesi fareyle çalışıp klavyeyle çalışmıyorsa yarım kalır. W3C'nin WAI-ARIA Yazarlık Pratikleri Kılavuzu (APG), metin kutusu ve açılır listeden oluşan bileşen için şu tuşları tanımlar:

Aşağı ok
Kutudayken odağı listeye taşır. Listedeyken bir sonraki öneriye geçer. Son öneride kutuya döner ya da hiçbir şey yapmaz.
Yukarı ok
Bir önceki öneriye geçer.
Enter
Seçili öneriyi kabul eder ve listeyi kapatır. Seçili öneri yoksa yazılanı arar.
Escape
Açık listeyi kapatır, odak arama kutusuna döner. Liste kapalıyken kutuyu temizleyebilir; bu isteğe bağlıdır.
Alt + aşağı ok
Liste kapalıysa odağı taşımadan açar. İsteğe bağlıdır.

Baymard da masaüstünde ok tuşlarıyla gezmeyi, Enter ile seçmeyi ve listenin sondan başa dönmesini öneriyor. Fareyle üzerine gelinen öneriye arka plan rengi verilmesini istiyor. Örnekte aynı rengi klavyeyle seçilen satıra da verdim. Satırın solunda ayrıca koyu bir çizgi var, çünkü yalnızca renge dayanan bir işareti herkes ayırt edemez.

Esc ile ilgili bir ayrıntı: APG'ye göre Esc açık listeyi kapatır. Liste zaten kapalıyken kutuyu temizlemek isteğe bağlıdır. Örnekte ikisini de yaptım, böylece kullanıcı yazdığını tek tuşla kaybetmiyor.

Erişilebilir combobox

APG bu bileşene combobox der: ilişkili bir açılır penceresi olan bir giriş alanı. Pencere bir liste, ızgara, ağaç ya da diyalog olabilir. Arama önerilerinde neredeyse her zaman liste kullanılır.

APG dört otomatik tamamlama türü sayar. Örnekteki tür "elle seçimli liste": öneriler yazılana göre süzülür, ama kullanıcı bir öneri seçmezse değer yazdığı metin olarak kalır. Bence arama için en güvenli tür bu, çünkü Enter her zaman kullanıcının yazdığını arar.

Ekran okuyucunun bileşeni doğru duyurması için gerekenler:

  • Arama kutusunda role="combobox" ve aria-autocomplete="list".
  • Liste kapalıyken aria-expanded="false", açıkken "true". aria-controls listeyi gösterir.
  • Odak kutuda kalır. Seçili öneri aria-activedescendant ile bildirilir ve o öneride aria-selected="true" olur.
  • Liste role="listbox", her satır role="option" taşır.

Kendi eklemem şu: kaç öneri çıktığını bir durum mesajıyla duyurun. Örnekte "4 ürün eşleşti" cümlesi aria-live alanında. Kullanıcı her harfte duyuru duymasın diye, yazmayı bırakmasından kısa süre sonra güncelleniyor. Durum mesajlarının WCAG tarafını WCAG rehberinde anlattım.

Benim notum

Audit'lerde arama kutusunu hep aynı testle açarım: ürün listesinden bir ürün adı alır, Türkçe karakterleri düz harfle yazarım. "cocuk" yazıp sonuç alamadığım mağaza sayısı az değil. Düzeltmesi küçük, ama satışa doğrudan dokunuyor.

İkinci testim sonuç yok ekranı. Bilerek hatalı bir kelime yazarım ve ekranın bana ne önerdiğine bakarım. Boş bir sayfa ve "0 sonuç" yazısı görüyorsam, ziyaretçinin de orada çıktığını varsayarım.

Son olarak fareyi bırakıp aşağı oka basarım. Liste tepki vermiyorsa ya da Enter sayfayı alakasız bir yere götürüyorsa bunu yüksek öncelikli bulgu olarak yazarım. Bu kontrolleri kendi sitenizde yapmak için UX audit kontrol listesini kullanabilirsiniz.

Sık sorulanlar

Otomatik tamamlamada kaç öneri gösterilmeli?

Baymard masaüstünde en fazla 10, mobilde 4 ile 8 arası öneriyor. Testlerinde fazla öneri kullanıcıyı ya önerileri görmezden gelmeye ya da onları uzun uzun okumaya itmiş. Listede kaydırma çubuğu olmamalı.

Arama kutusu sayfada nereye konmalı?

Jakob Nielsen sayfanın üstünü, genelde sağ üst köşeyi öneriyor ve solun da neredeyse aynı iyi çalıştığını söylüyor. Ana sayfada arama bir bağlantı değil, yazılabilir bir kutu olmalı.

Türkçe karakterleri yazmayan kullanıcı ürünü nasıl bulur?

Aramada hem sorgu hem ürün adı aynı biçime getirilir: önce Türkçe kurala göre küçültülür, sonra ı, ş, ğ, ü, ö ve ç düz harflere çevrilir. Böylece "gomlek" yazan kişi "Gömlek" ürününü görür.

Erişilebilir bir otomatik tamamlama için ne gerekir?

W3C'nin combobox kalıbını izleyin. Kutuda role="combobox", listenin açık mı kapalı mı olduğunu söyleyen aria-expanded ve seçili öneriyi bildiren aria-activedescendant olmalı. Ok tuşları, Enter ve Escape de çalışmalı.

Kaynaklar (8)
  1. W3C WAI, ARIA Authoring Practices Guide (APG): Combobox Pattern. erişim 2026-11-03
  2. Edward Scott, Baymard Institute, 9 UX Best Practice Design Patterns for Autocomplete Suggestions. 2022
  3. Kate Moran, Nielsen Norman Group, Site Search Suggestions. 2018
  4. Jakob Nielsen, Nielsen Norman Group, Search: Visible and Simple. 2001
  5. Edward Scott, Baymard Institute, Ecommerce Search Query Types UX Best Practices. 2024, güncelleme 2026
  6. Sonia Sousa, Baymard Institute, Search UX: 5 Proven Strategies for Improving "No Results" Pages. 2019, güncelleme 2025
  7. Kathryn Whitenton, Nielsen Norman Group, 3 Guidelines for Search Engine "No Results" Pages. 2014
  8. MDN Web Docs, String.prototype.toLocaleLowerCase(). erişim 2026-11-03