Kenapa Saya Lebih Sering Membuat Live Search Sendiri daripada Mengandalkan Search Bawaan WordPress

Hampir setiap website WordPress custom yang saya kerjakan memiliki kebutuhan yang berbeda. Ada yang berupa company profile, directory, knowledge base, hingga website internal perusahaan dengan ribuan data.

Namun, meskipun jenis project-nya berbeda-beda, saya mulai menyadari ada satu pola yang terus berulang.

Cepat atau lambat, client biasanya akan bertanya, “Search-nya bisa dibuat lebih pintar nggak?”

Menariknya, mereka tidak pernah bertanya bagaimana cara saya membangunnya. Mereka tidak peduli apakah saya menggunakan WP_Query, WordPress REST API, atau teknologi lainnya.

Yang mereka rasakan hanya satu hal.

Kalau data yang mereka cari tidak muncul, berarti fitur search dianggap belum bekerja dengan baik. Sejak saat itu, saya mulai melihat fitur search dari sudut pandang yang berbeda.

TL;DR

• Search bawaan WordPress masih sangat layak digunakan untuk website sederhana.
• Ketika website mulai menggunakan banyak Custom Post Type (CPT), saya lebih sering membangun Live Search sendiri.
• Bagi saya, tujuan utama bukan sekadar membuat pencarian lebih cepat, tetapi membantu pengguna menemukan informasi dengan lebih mudah.
• Contoh implementasi nyata bisa dicoba di demo https://cars.rizwanaritonang.com/ — klik ikon search di header, lalu ketik kata kunci seperti “Tesla” atau “Honda”.

Search Bawaan WordPress Sebenarnya Tidak Buruk

Kalau ada yang bertanya apakah saya selalu mengganti search bawaan WordPress, jawabannya tentu tidak.

Untuk website seperti blog, company profile, atau landing page, saya hampir selalu menggunakan fitur bawaan WordPress. Alasannya sederhana. Kontennya tidak terlalu banyak, struktur datanya juga relatif sederhana, dan pengguna biasanya hanya mencari artikel atau halaman tertentu.

Dalam kondisi seperti itu, saya tidak melihat alasan untuk menambahkan kompleksitas yang sebenarnya tidak dibutuhkan.

Menurut saya, salah satu kesalahan yang sering dilakukan developer adalah terlalu cepat menambahkan teknologi baru, padahal solusi bawaan sebenarnya sudah cukup.

Semuanya Berubah Ketika Project Mulai Menggunakan Custom Post Type

Perubahan mulai terasa ketika saya mengerjakan project yang tidak lagi hanya berisi Post dan Page.

Misalnya sebuah website memiliki struktur seperti ini:

• Portfolio
• Services
• Team
• Case Study
• FAQ
• Documentation

Atau, seperti pada project car marketplace yang saya bangun, data mobil disimpan di Custom Post Type car dengan taxonomy tersendiri untuk merek, tahun, lokasi, dan tipe bahan bakar.

Dari sisi developer, struktur tersebut terasa masuk akal karena setiap jenis konten memiliki tempatnya masing-masing. Namun dari sisi pengguna, semua itu hanyalah informasi yang mereka harapkan bisa ditemukan melalui satu kotak pencarian.

Mereka tidak pernah berpikir apakah data tersebut berasal dari Post, Custom Post Type, atau Custom Field. Yang mereka tahu hanyalah, jika informasi itu ada di website, seharusnya bisa ditemukan.

Dan di sinilah saya mulai memahami bahwa ekspektasi pengguna sering kali berbeda dengan cara kerja search bawaan WordPress.

Yang Sebenarnya Diinginkan Client Bukan “Search”

Selama mengerjakan berbagai project, saya hampir tidak pernah menerima permintaan seperti, “Tolong pakai WordPress REST API.” atau, “Search-nya harus menggunakan AJAX.”

Client tidak pernah berbicara tentang teknologi. Mereka justru menyampaikan hal-hal yang jauh lebih sederhana. Misalnya,

• Hasilnya langsung muncul saat mengetik.
• Tidak perlu pindah halaman.
• Semua data bisa dicari.
• Lebih nyaman dipakai di mobile.

Awalnya saya menganggap itu hanya permintaan kecil. Tetapi semakin sering saya mengerjakan project serupa, saya mulai sadar bahwa mereka sebenarnya tidak sedang meminta fitur search. Mereka sedang meminta pengalaman mencari informasi yang terasa lebih cepat dan lebih nyaman. Dan menurut saya, dua hal itu sangat berbeda.

Kenapa Saya Lebih Memilih Membangun Live Search

Di beberapa project terakhir, saya lebih sering membangun Live Search menggunakan WordPress REST API. Bukan karena fitur search bawaan WordPress buruk. Justru karena saya ingin memiliki kontrol yang lebih besar terhadap pengalaman pengguna.

Dengan REST API, saya bisa menentukan sendiri:

• jenis konten apa saja yang ikut dicari,
• informasi apa yang ditampilkan,
• urutan hasil pencarian,
• kapan request dikirim,
• hingga bagaimana tampilan dropdown hasil pencarian.

Saya tidak lagi terikat dengan perilaku default WordPress. Semuanya bisa disesuaikan dengan kebutuhan project.

Studi Kasus: Live Search di Car Marketplace

Salah satu implementasi yang paling saya sukai adalah fitur Live Search pada website https://cars.rizwanaritonang.com/.

Website ini dibangun sebagai katalog mobil dengan Custom Post Type car, lengkap dengan filter sidebar untuk merek, harga, tahun, dan lokasi. Namun di samping filter tersebut, saya juga menambahkan ikon search di header. Ketika diklik, muncul overlay pencarian — pengguna bisa langsung mengetik tanpa pindah halaman.

Di balik layar, saya mendaftarkan custom REST API endpoint (/wp-json/rzwn/v1/live-search) yang mencari di tiga sumber sekaligus:

1. Custom Post Type car — termasuk taxonomy seperti merek, tahun, lokasi, dan tipe bahan bakar
2. Post — artikel blog
3. Page — halaman statis

Hasil pencarian dikelompokkan berdasarkan jenis konten (Cars, Articles, Pages), menampilkan thumbnail, judul, ringkasan singkat, dan harga untuk mobil. Request dikirim dengan debounce 300 ms setelah pengguna berhenti mengetik, sehingga tidak membebani server.

Coba sendiri: buka https://cars.rizwanaritonang.com/, klik ikon search di pojok kanan header, lalu ketik “Tesla” atau “Honda”. Hasilnya langsung muncul di overlay tanpa reload halaman.

Perbandingan Pendekatan

Search Bawaan

1. Reload halaman
2. Hasil muncul setelah submit
3. Kustomisasi terbatas
4. Cocok untuk website sederhana

Live Search

1. Hasil muncul tanpa reload
2. Hasil muncul saat pengguna mengetik
3. Sangat fleksibel
4. Cocok untuk website custom dengan banyak data

Yang Saya Sukai dari Pendekatan Ini

Salah satu keuntungan terbesar adalah saya bisa membangun pengalaman pencarian yang terasa lebih modern. Misalnya, pada demo Car Listing, ketika pengguna mengetik beberapa karakter, hasil langsung muncul dengan:

• Thumbnail mobil atau artikel
• Judul
• Jenis konten (dikelompokkan: Cars, Articles, Pages)
• Ringkasan singkat
• Harga (untuk mobil) atau tanggal publikasi (untuk artikel)
• Link menuju halaman detail

Hal-hal seperti ini memang terlihat sederhana. Tetapi dari pengalaman saya, perubahan kecil seperti ini cukup berpengaruh terhadap kenyamanan pengguna ketika menjelajahi website. Terutama pada website yang memiliki ratusan bahkan ribuan konten.

Tidak Semua Website Membutuhkan Live Search

Meskipun saya cukup sering membangun Live Search, bukan berarti saya menggunakannya di semua project. Kalau website hanya berisi beberapa halaman dan beberapa artikel blog, saya tetap memilih menggunakan search bawaan WordPress.

Lebih sederhana. Lebih mudah dirawat. Dan sudah lebih dari cukup.

Menurut saya, memilih teknologi bukan tentang menggunakan solusi yang paling canggih. Tetapi tentang menggunakan solusi yang paling masuk akal untuk kebutuhan project.

Kapan Saya Mulai Mempertimbangkan Live Search?

Biasanya saya mulai mempertimbangkannya ketika project memiliki salah satu kondisi berikut.

• Menggunakan banyak Custom Post Type.
• Memiliki ratusan hingga ribuan konten.
• Search menjadi fitur utama website.
• Pengguna lebih sering mencari data daripada menelusuri menu.
• Website berfungsi sebagai katalog, directory, atau knowledge base.

Kalau beberapa kondisi tersebut sudah mulai muncul, saya hampir selalu memasukkan Live Search ke dalam perencanaan sejak awal. Bukan karena lebih keren, tetapi karena pengalaman pengguna akan jauh lebih baik.

Apa yang Saya Pelajari

Kalau ada satu hal yang saya pelajari dari berbagai project WordPress, mungkin ini. Search bukan sekadar kotak kecil di bagian header. Search adalah salah satu cara utama pengguna berinteraksi dengan seluruh isi website. Semakin kompleks struktur data yang kita bangun, semakin penting pula pengalaman pencariannya. Karena itu, ketika mulai merancang website custom, saya tidak hanya memikirkan bagaimana data akan disimpan.

Saya juga memikirkan bagaimana pengguna akan menemukannya kembali. Menurut saya, dua hal tersebut sama pentingnya.

Frequently Asked Questions

Apakah semua website WordPress membutuhkan Live Search?

Tidak. Untuk blog, company profile, atau website sederhana, search bawaan biasanya sudah cukup.

Apakah Live Search harus menggunakan plugin?

Tidak selalu. Pada studi kasus Car Listing, saya membangunnya langsung di custom theme menggunakan WordPress REST API dan modul JavaScript — tanpa plugin pencarian tambahan.

Apakah ada demo yang bisa dicoba?

Ya. Anda bisa mencoba langsung di https://cars.rizwanaritonang.com/. Klik ikon search di header, ketik kata kunci, dan lihat hasilnya muncul secara real-time.

Apakah Live Search lebih cepat?

Dari sisi pengalaman pengguna, iya. Hasil pencarian dapat muncul saat pengguna mengetik tanpa perlu me-reload halaman.

Kapan waktu yang tepat untuk mulai membangun Live Search?

Saya biasanya mulai mempertimbangkannya ketika website memiliki banyak Custom Post Type atau ketika fitur pencarian menjadi salah satu fitur utama website.

Penutup

Dulu saya menganggap fitur search hanyalah pelengkap. Selama pengguna masih bisa menemukan informasi, saya merasa itu sudah cukup.

Namun setelah mengerjakan semakin banyak website WordPress custom, pandangan saya berubah. Saya mulai melihat bahwa kualitas fitur search sangat memengaruhi bagaimana pengguna berinteraksi dengan sebuah website.

Karena itulah saya tidak lagi langsung mengandalkan search bawaan setiap kali memulai project baru. Saya akan melihat dulu bagaimana struktur datanya, bagaimana pengguna akan mencari informasi, dan seberapa penting peran pencarian dalam website tersebut.

Kalau jawabannya adalah “search akan sering digunakan”, saya hampir selalu memilih membangun Live Search sendiri. Bukan karena teknologinya lebih menarik, tetapi karena saya ingin pengalaman yang diberikan kepada pengguna terasa lebih cepat, lebih relevan, dan lebih sesuai dengan kebutuhan website yang sedang saya bangun.