DEV Community

Cover image for Katalog Produk Industri 5.000+ SKU: Menjinakkan Faceted Search Tanpa Merusak Crawl Budget
Mightyblue
Mightyblue

Posted on

Katalog Produk Industri 5.000+ SKU: Menjinakkan Faceted Search Tanpa Merusak Crawl Budget

Ada satu momen yang bikin saya berhenti sejenak waktu memeriksa Search Console sebuah katalog perkakas industri: halaman kategori utama baru di-crawl tiga minggu sekali, sementara URL ?brand=x&diameter=8&coating=tialn&sort=price_asc di-crawl tiga kali sehari. Produk baru butuh hampir sebulan untuk muncul di hasil pencarian. Bukan karena kontennya jelek — Googlebot cuma sibuk di tempat yang salah. Panduan faceted navigation dari Search Engine Land menyebut pola ini sebagai crawl trap klasik, dan itu persis yang terjadi ketika faceted search katalog produk industri dibiarkan tumbuh tanpa aturan.

Masalahnya bukan filter itu sendiri. Filter justru wajib ada.

Coba hitung sendiri. Katalog dengan 5.000 SKU, lima dimensi filter — merek, tipe perkakas, diameter, material benda kerja, coating — masing-masing punya 8 nilai. Kombinasinya menembus angka 32.000 URL sebelum sorting dan pagination ikut masuk hitungan. Semuanya HTML valid, semuanya bisa di-crawl, dan hampir semuanya nyaris identik. Riset empiris tentang data produk schema.org dari Web Data Commons menunjukkan hal yang senada di skala web: dari ratusan juta node produk yang diekstrak, hanya sekitar 10% yang lolos uji validitas semantik — sisanya duplikat, kosong, atau berantakan. Saya menulis ini karena pola yang sama terus saya temui di klien manufaktur dan distributor teknis: tim engineering sudah membangun sistem filter yang canggih, tapi tidak ada seorang pun yang memutuskan filter mana yang boleh masuk indeks.

Dan keputusan itu bukan tugas SEO. Itu tugas arsitektur.


TL;DR — Faceted search bukan bug yang perlu ditambal, tapi permukaan yang perlu digubernur. Tentukan filter mana yang punya permintaan pencarian nyata, biarkan yang itu saja crawlable, blokir sisanya di level link, bukan di level tag. Salah memilih antara robots.txt dan noindex justru membuat masalahnya lebih mahal, bukan lebih murah.


1. Anatomi Ledakan URL di Katalog Teknis

Sebelum bicara solusi, kita perlu jujur soal skalanya. Katalog perkakas industri punya karakter yang berbeda dari toko fashion: dimensinya numerik, presisinya penting, dan pembeli sering datang dengan spesifikasi yang sangat spesifik. Itu bagus untuk konversi, tapi mematikan untuk crawl budget kalau tiap kombinasi jadi URL sendiri.

Kenapa katalog B2B lebih rawan daripada e-commerce ritel

Toko sepatu punya filter ukuran dengan 12 nilai. Distributor end mill punya filter diameter dengan 40 nilai, ditambah jumlah flute, panjang potong, radius sudut, dan jenis coating.

Setiap dimensi mengalikan, bukan menambah.

Yang bikin repot: banyak nilai numerik itu punya bentuk penulisan berbeda. d=8, d=8.0, d=8mm bisa menghasilkan tiga URL untuk produk yang sama persis, kalau normalisasi parameter tidak diurus di layer routing.

Tiga sumber pemborosan yang paling sering terlewat

  • Parameter sorting. sort=price_asc, sort=newest, sort=name tidak menambah satu pun konten unik. Nol nilai pencarian, tapi mengalikan seluruh ruang URL yang ada.
  • Session ID dan parameter tracking. utm_*, ref=, sid= yang bocor ke internal link. Ini murni sampah crawl.
  • Kombinasi tiga filter atau lebih. Tidak ada yang mengetik "end mill 8mm empat flute coating TiAlN panjang 60mm merek X" di Google sebagai satu frasa. Ini wilayah pencarian internal, bukan wilayah organik.

Gejala di lapangan sebelum grafiknya terlihat

Gejala pertama biasanya bukan penurunan ranking. Melainkan indexasi yang melambat.

Anda rilis 200 SKU baru. Dua minggu berlalu. Baru 40 yang terindeks.

Kalau itu terjadi, hampir pasti Googlebot Anda sedang tersesat di ruang filter.


2. Keputusan Arsitektural: Filter Mana yang Layak Diindeks

Ini bagian yang paling sering dilewati tim teknis, padahal paling menentukan. Sebelum menyentuh satu baris robots.txt pun, harus ada daftar eksplisit: filter mana yang punya permintaan pencarian, dan filter mana yang murni alat navigasi internal. Tanpa daftar ini, semua konfigurasi teknis berikutnya cuma menebak.

Uji dua sumbu: permintaan pencarian dan niat komersial

Sebuah facet layak diindeks hanya kalau lolos dua-duanya.

"Tap M8 HSS" punya volume pencarian dan niat beli yang jelas — layak jadi halaman terindeks dengan konten pendukung sendiri. "Perkakas urut harga termurah" tidak punya keduanya.

Aturan praktisnya: kalau kombinasi filter itu tidak pernah Anda dengar keluar dari mulut pelanggan saat telepon, kemungkinan besar tidak ada yang mengetiknya di Google.

Matriks keputusan yang bisa langsung dipakai

Tipe URL Contoh Crawl Index Mekanisme
Kategori utama /end-mill/ Ya Ya Default, prioritas sitemap
Facet bernilai tinggi (1 dimensi) /end-mill/coating-tialn/ Ya Ya Path statis + konten unik
Facet 2 dimensi bernilai sedang ?d=8&flute=4 Ya Tidak canonical ke induk
Facet 3+ dimensi ?d=8&flute=4&coat=tialn&l=60 Tidak Disallow pola di robots.txt
Sorting ?sort=price_asc Tidak Disallow + hindari link crawlable
Tracking / session ?utm_source= Tidak Disallow + jangan pernah di-render sebagai <a href>

Perhatikan kolom terakhir baris ketiga dan keempat. Perbedaannya krusial, dan itu bahan bab berikutnya.

Ubah facet juara jadi halaman kelas satu

Kalau satu kombinasi filter ternyata mendatangkan trafik konsisten dan Anda punya cukup SKU di dalamnya, jangan biarkan ia hidup sebagai query string.

Naikkan statusnya. Beri URL berbasis path, judul sendiri, deskripsi teknis sendiri, dan tautan dari navigasi utama.

Facet yang naik kelas jadi subkategori adalah cara paling bersih mengubah crawl waste menjadi aset organik.


3. Robots.txt vs Noindex: Kesalahan yang Paling Mahal

Ini bagian yang paling sering salah kaprah, dan kesalahannya bukan sekadar kurang optimal — ia justru memperparah masalah yang ingin diselesaikan. Insting kebanyakan orang saat ingin menghentikan sebuah halaman muncul di pencarian adalah memasang noindex. Untuk faceted search berskala besar, insting itu keliru.

Perbedaannya ada di kapan sinyal itu bekerja

Disallow di robots.txt mencegah permintaan crawl terjadi sama sekali. Nol budget terpakai.

noindex hidup di dalam HTML halaman. Artinya Googlebot harus meng-crawl halaman itu dulu untuk membacanya. Budget terpakai penuh, lalu hasilnya dibuang.

Untuk satu-dua halaman, tidak masalah. Untuk 30.000 URL filter, Anda baru saja membakar seluruh crawl budget demi memberi tahu Google bahwa 30.000 halaman itu tidak penting.

Aturan keras: jangan pernah gabungkan keduanya di URL yang sama

Kalau sebuah URL diblokir di robots.txt, Googlebot tidak akan pernah mengambil HTML-nya. Artinya tag noindex di dalamnya tidak akan pernah terbaca.

Hasilnya adalah kondisi terburuk: halaman tidak di-crawl, tapi juga tidak bisa dihapus dari indeks lewat sinyal noindex. Ia mengambang.

Pembahasan mendalam soal perilaku tag ini ada di panduan Hamed Fatehi tentang canonical dan robots meta tag untuk developer — referensinya rapi dan langsung menyambung ke dokumentasi resmi.

Kontrol terkuat justru ada di level link

Semua diskusi di atas jadi jauh lebih ringan kalau URL bermasalahnya tidak pernah dibuat sebagai tautan yang bisa di-crawl sejak awal.

Render kontrol filter tingkat lanjut sebagai <button>, bukan <a href>. Terapkan perubahan state lewat history.pushState setelah interaksi pengguna, bukan lewat tautan HTML yang tercetak di DOM saat render pertama.

Bot mengikuti tautan. Bot tidak menekan tombol.

Ini satu-satunya kontrol yang bersifat direktif, bukan sekadar petunjuk.


4. Implementasi Bertahap Tanpa Merusak yang Sudah Jalan

Godaan terbesar setelah paham teorinya adalah langsung memblokir semuanya dalam satu deploy. Jangan. Katalog yang sudah berjalan biasanya punya beberapa URL filter yang diam-diam mendatangkan trafik, dan memblokirnya sekaligus berarti membuang pendapatan yang sudah ada. Urutannya penting.

Panduan enam langkah

Buka checklist implementasi lengkap

Langkah 1 — Ambil data sebelum menyentuh apa pun.
Ekspor laporan Crawl Stats dari Search Console dan log server minimal 30 hari. Kelompokkan permintaan Googlebot berdasarkan pola URL. Anda butuh angka dasar untuk membuktikan perbaikan nanti.

Langkah 2 — Bangun taksonomi URL.
Klasifikasikan tiap pola ke salah satu baris di tabel bab 2. Simpan sebagai file konfigurasi di repo, bukan di spreadsheet seseorang. Ini dokumen hidup yang akan direview tiap kuartal.

Langkah 3 — Silangkan dengan data performa.
Gabungkan daftar pola tadi dengan laporan Performance. Pola filter mana yang benar-benar menghasilkan klik? Yang menghasilkan klik dipromosikan, bukan diblokir.

Langkah 4 — Perbaiki di level render dulu.
Sebelum menyentuh robots.txt, ubah kontrol filter tingkat lanjut dari anchor jadi button. Bersihkan parameter tracking dari internal link. Normalisasi urutan dan format parameter di routing. Banyak masalah selesai di sini saja.

Langkah 5 — Baru terapkan disallow, bertahap.
Mulai dari yang paling aman dan paling jelas: sorting dan session ID. Tunggu dua minggu. Pantau Crawl Stats. Kalau kurva crawl mulai bergeser ke halaman produk, lanjutkan ke kombinasi tiga dimensi.

Langkah 6 — Pasang pemantauan permanen.
Buat alert untuk lonjakan jumlah halaman terindeks dan untuk anomali di Crawl Stats. Ledakan URL biasanya datang lagi diam-diam setelah rilis fitur filter baru.

Tanda bahwa strategi Anda bekerja

Metrik yang harus Anda pantau bukan ranking, melainkan kecepatan.

Berapa hari dari publish SKU baru sampai terindeks? Kalau angka itu turun dari 21 hari ke 3 hari, strateginya berhasil — bahkan sebelum posisi ranking bergerak sedikit pun.


5. Studi Kasus: Katalog Perkakas Potong dan Metrologi

Prinsip di atas terdengar abstrak sampai ditempelkan ke katalog nyata dengan kendala nyata. Distributor perkakas presisi punya kombinasi masalah yang khas: SKU teknis dengan spesifikasi berlapis, harga yang sering tidak dipublikasikan, dan pembeli yang mencari lewat kode part maupun lewat spesifikasi deskriptif sekaligus.

Kendala khas distributor teknis

Katalog seperti milik PT Bless Berkarya Lestari — distributor cutting tools, sistem tool holding, dan alat ukur presisi di koridor industri Karawang — mencakup lini yang lebar: twist drill, tap, thread mill, end mill, perkakas PCD, holder, chuck, sampai thread gauge dari beberapa principal.

Tiap lini punya dimensi filter yang sama sekali berbeda. Filter untuk tap tidak relevan untuk gauge.

Artinya, aturan facet tidak bisa seragam sitewide. Harus per-kategori.

Pola yang saya rekomendasikan untuk kasus seperti ini

  • Filter merek dan tipe perkakas → path statis, terindeks, diberi konten teknis pendukung. Ini yang dicari orang: "tap Emuge", "end mill PCD".
  • Filter dimensi tunggal yang populer → terindeks selektif, hanya untuk nilai yang punya volume pencarian nyata dan cukup SKU di dalamnya.
  • Kombinasi dimensi teknis lanjutan → murni pencarian internal. Tidak crawlable, dirender via tombol.
  • Filter ketersediaan stok → tidak pernah diindeks. Kontennya berubah tiap hari; halaman kosong yang terindeks adalah kerugian bersih.

Kuncinya: tim yang mengelola faceted search katalog produk industri harus bicara dengan tim sales. Merekalah yang tahu frasa apa yang benar-benar dipakai pelanggan saat mencari perkakas.

Jangan lupa halaman kosong

Filter yang menghasilkan nol produk adalah jebakan yang sering luput.

Kembalikan status yang benar, jangan render 200 dengan halaman kosong. Dan pastikan halaman semacam itu tidak pernah masuk sitemap.


6. Pertanyaan yang Sering Muncul

Bagian ini merangkum pertanyaan yang paling sering datang setiap kali saya membahas topik ini dengan tim engineering, terutama dari developer yang baru pertama kali memegang katalog berskala besar.

Apakah rel="nofollow" cukup untuk menghentikan crawl facet?

Tidak sepenuhnya. nofollow bersifat petunjuk, bukan perintah, dan hanya bekerja kalau setiap tautan internal ke URL itu memakainya. Satu tautan terlewat, atau satu tautan eksternal dari luar, dan URL itu tetap ditemukan. Untuk facet, kombinasikan dengan pendekatan level render.

Bagaimana kalau situs saya cuma punya 300 SKU?

Untuk katalog kecil, crawl budget jarang jadi kendala nyata. Fokuslah dulu ke kualitas konten produk dan kecepatan halaman. Tapi taksonomi URL tetap layak dibuat sejak awal — jauh lebih murah menyiapkan aturannya di 300 SKU daripada merapikannya di 5.000.

Apakah filtering berbasis AJAX tanpa mengubah URL adalah solusi terbaik?

Secara teknis ia paling bersih untuk crawl budget, karena tidak ada URL baru yang terbentuk sama sekali. Tapi ada harganya: pengguna kehilangan kemampuan berbagi hasil filter, tombol back jadi tidak intuitif, dan aksesibilitas perlu perhatian ekstra. Pendekatan hibrida — pushState untuk state yang berguna, tanpa tautan crawlable — biasanya kompromi yang lebih sehat.

Berapa lama sampai perubahan ini terlihat hasilnya?

Pergeseran pola crawl biasanya mulai terlihat di Crawl Stats dalam dua sampai empat minggu. Dampak ke kecepatan indexasi menyusul setelahnya. Perubahan posisi ranking adalah efek paling akhir, bukan yang pertama — jangan menilai keberhasilan dari sana.

Apakah facet yang diblokir kehilangan link equity-nya?

Kalau Anda memakai canonical ke halaman induk, sinyalnya dikonsolidasikan ke induk. Kalau Anda memblokir lewat robots.txt, tidak ada sinyal yang mengalir sama sekali dari URL itu. Karena itu urutannya penting: canonical untuk facet bernilai sedang, disallow untuk yang benar-benar tanpa nilai.


Yang Tersisa Setelah Semua Konfigurasi Selesai

Menutup pembahasan panjang ini, ada satu hal yang perlu diletakkan di atas semua detail teknis tadi: crawl budget bukan masalah yang selesai sekali deploy. Ia adalah sistem yang perlu diatur terus-menerus, karena tiap fitur filter baru, tiap kategori baru, tiap integrasi PIM baru berpotensi membuka ruang URL yang belum pernah Anda petakan.

"The best way to get information from Google is to give information to Google in the way it wants it."

Kalimat itu datang dari Rand Fishkin, pendiri Moz dan salah satu figur paling berpengaruh dalam pembentukan disiplin SEO modern sebagai praktik yang berbasis data, bukan tebakan. Relevansinya dengan topik ini langsung: Google tidak menghukum katalog karena punya banyak filter. Google hanya menghabiskan sumber dayanya sesuai apa yang kita sodorkan lewat tautan dan struktur. Kalau yang kita sodorkan adalah 30.000 kombinasi filter, itulah yang akan ia telusuri. Kalau yang kita sodorkan adalah 800 halaman produk dan 40 kategori bermakna, itu pula yang ia prioritaskan.

Jadi pertanyaannya bukan bagaimana caranya menyembunyikan filter dari Google.

Pertanyaannya: struktur apa yang sebenarnya ingin Anda tunjukkan?

Mulai dari daftar taksonomi URL. Itu satu jam kerja yang mengubah bagaimana seluruh katalog Anda ditemukan.


Punya pengalaman menangani ledakan URL di katalog besar? Ceritakan pendekatan Anda di kolom komentar — terutama kalau Anda menemukan pola yang berbeda di sektor lain.

Top comments (0)