Sekitar bulan September 2025, banyak alat SEO dan skrip kustom tiba-tiba berhenti bekerja tanpa banyak kabar. Penyebabnya? Google tidak lagi secara konsisten menghormati parameter num=100 yang selama bertahun-tahun dipakai pengguna tingkat lanjut untuk menampilkan 100 hasil per halaman. Tidak ada pengumuman penghentian resmi — hanya pernyataan juru bicara ke Search Engine Land bahwa parameter tersebut "tidak didukung secara formal." Di periode yang kurang lebih sama, Google memperkenalkan lebih banyak mode udm di samping vertikal tbm yang sudah ada, mengumumkan bahwa domain kode negara akan bertahap dialihkan ke google.com, dan melaporkan AI Overviews telah menjangkau lebih dari 2,5 miliar pengguna bulanan.
Kalau selama ini Anda membangun URL pencarian, memantau peringkat, atau mengotomatiskan riset dengan parameter URL Google, ada kemungkinan beberapa alur kerja Anda diam-diam sudah turun kualitasnya. Di Thunderbit, kami meninjau dokumentasi Google saat ini, pengumuman perubahan terbaru, referensi hasil reverse engineering, dan pengecekan langsung di browser untuk membedakan kontrol yang stabil dari yang kontekstual. Hasilnya adalah referensi bertanggal yang sebaiknya diuji dulu sebelum dipakai untuk parameter URL Google Search yang relevan di 2026, termasuk pemetaan tbm/udm, rumus encoding uule untuk penargetan geo tingkat kota, serta konflik parameter yang bisa menghemat berjam-jam debugging.
Apa Itu Parameter URL Google Search?
Parameter URL Google Search adalah pasangan key=value yang muncul setelah tanda ? pada URL pencarian Google. Parameter ini mengatur banyak hal, mulai dari apa yang Anda cari, hasil negara mana yang Anda lihat, sampai apakah yang muncul gambar, berita, atau tautan biru klasik.
Struktur URL pencarian Google pada umumnya seperti ini:
https://www.google.com/search?q=best+crm+software&hl=en&gl=us&tbs=qdr:m
- Base URL:
https://www.google.com/search ?memulai query stringq=best+crm+softwareadalah kueri pencarian (spasi dikodekan sebagai+)&memisahkan setiap parameterhl=enmengatur bahasa antarmuka ke bahasa Inggrisgl=usmemberi tahu Google untuk menampilkan hasil seolah-olah Anda berada di AStbs=qdr:mmemfilter hasil dari satu bulan terakhir
Perbedaan yang penting: operator pencarian seperti site:, filetype:, dan intitle: masuk di dalam nilai q=. Itu bagian dari kueri Anda. Sementara parameter URL seperti gl, hl, dan tbs adalah kunci terpisah di URL yang mengatur cara Google memproses dan menampilkan hasil. Keduanya penting dan saling melengkapi — tapi fungsinya berbeda.
Google tidak pernah menerbitkan satu spesifikasi resmi yang benar-benar versi-bernomor untuk parameter ini. Sebagiannya berasal dari formulir Advanced Search, sebagiannya dari Custom Search API, dan sisanya dari hasil pengamatan terhadap URL milik Google sendiri. Artinya, artikel yang Anda baca ini didasarkan pada pengujian langsung dan perilaku yang terdokumentasi, bukan kontrak API resmi.
Kenapa Parameter URL Google Search Penting di 2026
Parameter URL bukan cuma urusan developer. Siapa pun yang bekerja di SEO, marketing, sales, operations, atau product dan perlu memahami apa yang Google tampilkan untuk kueri tertentu, di pasar tertentu, pada waktu tertentu — parameter ini adalah toolkit Anda.
Ringkasan cepat siapa yang diuntungkan dan bagaimana:
| Use Case | Siapa yang Diuntungkan | Parameter Kunci |
|---|---|---|
| Pelacakan peringkat SEO lintas negara | Tim SEO & Marketing | gl, hl, uule, pws |
| Pemantauan kompetitor berdasarkan tanggal | Tim Strategy & Ops | tbs, q dengan site: |
| Pemantauan iklan di pasar tertentu | Tim paid media | gl, hl, udm |
| Audit SEO lokal (tingkat kota) | Pemilik bisnis lokal | uule, gl |
| Riset konten / pelacakan tren | Tim konten | tbs (filter tanggal), lr |
| Mengalirkan data pencarian ke aplikasi AI/LLM | Tim Product & Data | Berbagai parameter + ekstraksi terstruktur |
Tiga perubahan besar membuat 2026 jauh berbeda:
num=100tidak lagi bisa diandalkan. Trik lama untuk hasil per halaman berhenti bekerja secara konsisten pada September 2025. Google tidak pernah secara formal menghentikannya; juru bicara menyebut parameter itu memang tidak pernah didukung secara formal.- Redirect ccTLD adalah proses migrasi, bukan perpindahan yang sudah selesai. Google mengumumkan pada April 2025 bahwa domain kode negara seperti google.co.uk, google.de, dan lainnya akan bertahap dialihkan ke google.com. Google belum menerbitkan pemberitahuan penyelesaian, jadi jangan menganggap semua locale sudah bertingkah sama.
- AI Overviews mengubah SERP. Google melaporkan AI Overviews telah menjangkau lebih dari 2,5 miliar pengguna bulanan dan 200+ negara serta wilayah. Mode
udmhasil reverse engineering bisa mengubah tampilan hasil pada konteks tertentu, tetapi bukan tombol pasti untuk memaksa AI Overview.
Kalau alur kerja Anda belum diperbarui mengikuti perubahan ini, besar kemungkinan hasil yang Anda terima sekarang sudah menurun kualitasnya atau menyesatkan tanpa Anda sadari.
Cheat Sheet Parameter URL Google Search (2026)
Sebelum masuk lebih dalam, tabel referensi cepat di bawah ini adalah daftar paling mutakhir yang berhasil saya susun. Simpan sebagai bookmark.
| Parameter | Fungsinya | Contoh Nilai | Status |
|---|---|---|---|
q | Kueri pencarian (mendukung operator di dalamnya) | q=best+crm+software | ✅ Aktif |
hl | Bahasa antarmuka | hl=en, hl=ja | ✅ Aktif |
gl | Konteks negara/pasar | gl=us, gl=jp | ✅ Aktif |
lr | Membatasi hasil ke bahasa konten tertentu | lr=lang_en | ✅ Aktif |
cr | Membatasi hasil ke negara hosting tertentu | cr=countryUS | ✅ Aktif |
start | Offset pagination | start=10 (halaman 2) | ✅ Aktif |
num | Jumlah hasil per halaman (dulu) | num=100 | ⚠️ Tidak didukung secara formal; tidak andal sejak Sept 2025 |
udm | Mode konten kontekstual | udm=14 (web klasik) | ⚠️ Hasil reverse-engineered; bergantung konteks |
tbm | Vertikal pencarian | tbm=isch (gambar) | ⚠️ Masih teramati; uji bersama udm |
tbs | Filter waktu, urutan, verbatim | tbs=qdr:w | ✅ Aktif |
safe | Kontrol SafeSearch | safe=active | ✅ Aktif |
filter | Penyaringan hasil duplikat | filter=0 | ✅ Aktif (teramati) |
nfpr | Menonaktifkan koreksi otomatis | nfpr=1 | ✅ Aktif (teramati) |
pws | Menonaktifkan personalisasi | pws=0 | ✅ Aktif |
uule | Penargetan geo tingkat kota/DMA | uule=w+CAIQICI... | ✅ Aktif (reverse-engineered) |
as_q, as_epq, as_eq, dll. | Field Advanced Search | Beragam | ✅ Aktif |
as_sitesearch | Membatasi ke domain tertentu (Advanced Search) | as_sitesearch=example.com | ✅ Aktif |
as_filetype | Membatasi ke tipe file tertentu (Advanced Search) | as_filetype=pdf | ✅ Aktif |
ie, oe | Encoding input/output | ie=UTF-8 | ✅ Aktif (jarang dibutuhkan) |
kgmid, si, ibp | Entity Knowledge Graph / tampilan fitur | Beragam | ⚠️ Kontekstual (bukan untuk penggunaan umum) |
ei, ved, sxsrf, sclient | Sesi/pelacakan/telemetri | Beragam | 🔒 Internal (abaikan) |
gbv | Tampilan HTML basic (dulu) | gbv=1 | ❌ Tidak andal di 2026 |
Hapus ei, ved, sxsrf, dan sclient dari URL apa pun yang Anda simpan atau bagikan. Itu adalah state sesi dan telemetri yang ditambahkan Google secara otomatis — tidak relevan untuk membangun URL pencarian.
Parameter Inti Google Search yang Masih Berfungsi
Saya sudah menguji masing-masing parameter ini secara langsung per pertengahan 2026. Inilah yang paling sering akan Anda pakai.
q — Kueri Pencarian Anda
Parameter q memuat istilah pencarian Anda. Spasi dikodekan sebagai + atau %20. Di sinilah operator pencarian yang didokumentasikan Google berada — operator ditaruh di dalam nilai q, bukan sebagai parameter URL terpisah.
Beberapa contoh:
- Frasa persis:
q=%22google+search+url+parameters%22 - Dibatasi ke situs tertentu:
q=site%3Aexample.com+pricing - Tipe file:
q=filetype%3Apdf+annual+report+2026 - Gabungan:
q=site%3Acompetitor.com+intitle%3Apricing+after%3A2026%2F01%2F01
Selalu URL-encode seluruh nilai kueri. Tanda kutip, titik dua, dan garis miring semuanya harus di-encode dengan benar agar URL tidak rusak.
hl — Bahasa Antarmuka
hl mengontrol bahasa antarmuka Google (tombol, label, judul "People also ask") dan memengaruhi hasil mana yang diprioritaskan Google. Parameter ini menggunakan kode ISO 639-1 seperti en, fr, de, ja, atau tag BCP 47 seperti en-gb atau pt-br.
hl tidak memaksa semua dokumen hasil ke bahasa itu. Ini hanya sinyal kuat, tetapi Google masih bisa menampilkan hasil dalam bahasa lain jika sangat relevan. Untuk pembatasan bahasa konten, gunakan lr.
gl — Negara / Geolokasi
gl mensimulasikan negara tempat Anda mencari, menggunakan kode ISO 3166-1 alpha-2 (us, gb, jp, de). Dengan ccTLD yang secara bertahap dialihkan ke google.com, gl kini menjadi cara utama untuk mendapatkan hasil khusus negara.
Kueri yang sama dengan nilai gl berbeda bisa menghasilkan hasil, featured snippet, dan local pack yang sama sekali berbeda. Misalnya, q=best+bank&gl=us dan q=best+bank&gl=jp akan menampilkan bank yang sangat berbeda.
Tips: selalu pasangkan gl dengan hl untuk hasil lokal yang lebih akurat. Menggunakan gl=jp dengan hl=en memberi Anda hasil pasar Jepang dalam antarmuka bahasa Inggris — berguna untuk audit SEO internasional.
lr dan cr — Pembatas Bahasa dan Pembatas Negara
Keduanya sering tertukar. Bedanya penting:
lr=lang_enmembatasi hasil ke halaman berbahasa Inggris (bahasa konten)cr=countryUSmembatasi hasil ke halaman yang di-host di Amerika Serikat (lokasi server / asosiasi negara)gl=usmensimulasikan pencarian dari Amerika Serikat (memengaruhi ranking, hasil lokal, iklan)
Baik lr maupun cr tersedia melalui formulir Advanced Search. Hati-hati saat menggabungkannya — lr=lang_en + cr=countryJP berarti "hanya halaman berbahasa Inggris yang di-host di Jepang," yang sangat sempit. Kita bahas lagi di bagian konflik.
start — Pagination
start=10 meminta hasil dimulai dari posisi 11 (halaman 2), start=20 untuk halaman 3, dan seterusnya. Karena num=100 tidak lagi bisa diandalkan, menaikkan start per 10 adalah default yang lebih aman — tetapi Google masih bisa menulis ulang atau membatasi pagination.
Trik lama num=100&start=0 untuk menarik 100 hasil penuh sudah tidak berfungsi. Kalau skrip Anda masih memuat num, hapus saja — parameter itu sekarang diabaikan diam-diam.
pws — Menonaktifkan Personalisasi
pws=0 meminta Google mematikan personalisasi berbasis akun. Ini penting untuk pelacakan peringkat SEO, di mana Anda ingin hasil yang tidak bias oleh histori pencarian Anda sendiri, hasil yang pernah diklik, atau preferensi akun.
Perlu dicatat: pws=0 mengurangi personalisasi tetapi tidak menghilangkan semua faktor kontekstual. Google menyatakan hasil masih bisa berbeda berdasarkan waktu, lokasi, bahasa, dan perangkat. Tidak ada SERP Google yang benar-benar "netral".
safe dan filter — SafeSearch dan Penyaringan Duplikat
safe=activemenyalakan SafeSearch;safe=offmematikannya. Perlu diingat bahwa pengaturan akun, kebijakan admin, konfigurasi jaringan, atau aturan regional dapat mengesampingkan parameter ini.filter=0menonaktifkan penyaringan hasil duplikat Google. Berguna ketika Anda ingin melihat semua hasil yang dimiliki Google, termasuk near-duplicate yang biasanya digabungkan.
nfpr — Menonaktifkan Koreksi Otomatis
nfpr=1 mencegah Google menulis ulang kueri Anda secara paksa saat dianggap ada salah eja. Ini berguna untuk melacak istilah merek dengan ejaan tidak umum, jargon teknis, atau kueri yang sengaja disalah-eja oleh kompetitor.
Perlu dicatat bahwa nfpr=1 hanya menekan penulisan ulang paksa. Untuk kontrol yang lebih luas — menonaktifkan ekspansi sinonim, perubahan ejaan, dan modifikasi otomatis lain — gunakan tbs=li:1 (mode verbatim), yang akan saya bahas di bagian tbs di bawah.
Migrasi tbm ke udm: Apa yang Berubah dan Apa yang Harus Dipakai Sekarang
Ini salah satu perubahan parameter terbesar dalam beberapa tahun terakhir — dan salah satu yang paling mudah dibesar-besarkan.
tbm sudah lama menjadi cara umum untuk berpindah antar vertikal pencarian Google — gambar, berita, video, belanja — selama lebih dari satu dekade. Google juga memperkenalkan sistem numerik udm dengan mode yang tumpang tindih dan tambahan. Karena Google tidak menerbitkan registri konsumen yang stabil, anggap ini sebagai pemetaan kontekstual, bukan pengganti yang bersih dan tuntas.
Tabel Pemetaan tbm ke udm Lengkap
Pemetaan di bawah ini menggabungkan perilaku UI yang teramati dan pengecekan langsung bertanggal 12 Agustus 2026. Beberapa nilai dihapus atau ditulis ulang pada request anonim, jadi setiap baris harus diuji di akun, region, dan client tempat ia akan dipakai:
| Parameter Lama | Nilai Lama | Parameter Baru | Nilai Baru | Status |
|---|---|---|---|---|
tbm=lcl | Places/Local | udm=1 | Places/Local | ⚠️ Kontekstual |
tbm=isch | Images | udm=2 | Images | ⚠️ Kontekstual |
tbm=vid | Videos | udm=7 | Videos | ⚠️ Kontekstual |
tbm=nws | News | udm=12 | News | ⚠️ Kontekstual |
| — | — | udm=14 | Web klasik (tanpa AI Overview) | 🆕 Baru, tidak ada padanan tbm |
| — | — | udm=18 | Forums | 🆕 Baru, tidak ada padanan tbm |
tbm=shop | Shopping | udm=28 | Shopping | ⚠️ Kontekstual |
tbm=bks | Books | udm=36 | Books | ⚠️ Kontekstual |
| — | — | udm=39 | Short videos | 🆕 Baru, tidak ada padanan tbm |
| — | — | udm=50 | Mode AI Overview | 🆕 Baru, tidak ada padanan tbm |
Google belum menerbitkan registri udm yang stabil — ini catatan penting. Nilai-nilai ini merupakan hasil reverse engineering dari pengamatan perilaku UI Google sendiri. Penerimaan URL bervariasi tergantung akun, region, client, cookie, dan cohort eksperimen. Dalam pengujian saya, beberapa nilai udm dihapus pada request HTTP anonim tetapi berfungsi baik di sesi browser interaktif. Jangan menganggap semua nilai bekerja universal.
Apa yang Dilakukan udm=14 (dan Kenapa SEOs Menyukainya)
udm=14 telah menjadi semacam favorit kultus di komunitas SEO. Android Central menggambarkannya sebagai cara meminta tampilan hasil web klasik tanpa AI Overviews. Dalam banyak sesi, ia menghasilkan SERP dengan tautan biru tradisional, tetapi itu bukan jaminan resmi atau universal.
Kenapa ini penting? Kalau Anda melakukan rank tracking atau audit SEO, AI Overviews bisa mendorong hasil organik turun ke bawah lipatan layar dan membuat posisi peringkat lebih sulit dinilai. udm=14 bisa memberi tampilan yang lebih bersih saat Google menghormatinya.
Meski begitu, udm=14 tidak dijamin bekerja di semua konteks. Pada pengecekan langsung tanggal 12 Agustus 2026, Google kadang menghapus atau menulis ulang nilai udm tergantung konteks request. Hasilnya bisa berbeda tergantung sesi, akun, region, client, dan cohort eksperimen.
udm=50 pernah teramati di konteks AI Mode/hasil AI, tetapi tidak boleh disebut sebagai cara pasti untuk memaksa AI Overview untuk kueri apa pun.
Apa yang Harus Dilakukan: Perbarui Alur Kerja dari tbm ke udm
Rekomendasi saya:
- Implementasi baru: Perlakukan
udmsebagai input eksperimental/kontekstual dan siapkan fallback. - Alur kerja yang sudah ada: Dukung dan uji baik
tbmmaupunudmbila relevan, jangan berasumsi migrasi sudah selesai. - Jangan pernah gabungkan keduanya: Saat
tbmdanudmsama-sama ada di satu URL, perilakunya tidak bisa diprediksi. Dalam pengujian saya, Google kadang menghapus keduanya dan mengembalikan kueri biasa. Detailnya ada di bagian konflik.
Sintaks tbs Lengkap: Rentang Tanggal Kustom, Urut Berdasarkan Tanggal, dan Verbatim
tbs adalah salah satu parameter paling kuat dalam toolkit URL Google Search, dan kebanyakan panduan hanya menyentuh permukaannya saja. Parameter ini menangani filter waktu, pengurutan tanggal, mode verbatim, dan lainnya — semua dalam satu nilai yang dipisahkan koma.
Filter Waktu Standar
| Nilai tbs | Arti | Contoh Potongan URL |
|---|---|---|---|
| qdr:h | Satu jam terakhir | &tbs=qdr:h |
| qdr:d | 24 jam terakhir | &tbs=qdr:d |
| qdr:w | Satu minggu terakhir | &tbs=qdr:w |
| qdr:m | Satu bulan terakhir | &tbs=qdr:m |
| qdr:y | Satu tahun terakhir | &tbs=qdr:y |
Ini adalah dasar yang biasanya dibahas kebanyakan panduan. Tapi tbs bisa melakukan lebih banyak.
Rentang Tanggal Kustom
Butuh hasil dari jendela waktu tertentu? Gunakan sintaks cdr:1,cd_min:MM/DD/YYYY,cd_max:MM/DD/YYYY:
&tbs=cdr:1,cd_min:01/01/2026,cd_max:06/01/2026
Ini memfilter hasil ke yang oleh Google dikaitkan dengan tanggal antara 1 Januari dan 1 Juni 2026. Sangat berguna untuk riset kompetitif — misalnya, "apa yang dipublikasikan kompetitor tentang pricing di Q1 2026?" Ingat untuk meng-encode seluruh nilai URL, karena tanda titik dua dan garis miring perlu encoding.
Catatan praktis: asosiasi tanggal Google tidak selalu akurat. Tanggal yang tampil di hasil pencarian adalah tebakan terbaik Google, belum tentu tanggal publikasi sebenarnya. Selalu verifikasi tanggal di halaman tujuan.
Urut Berdasarkan Tanggal dan Mode Verbatim
Di sinilah panduan ini membahas hal yang tidak disentuh artikel pesaing mana pun.
sbd:1 mengurutkan hasil berdasarkan tanggal (terbaru lebih dulu). Sendiri, ini berguna tapi tidak terlalu istimewa. Triknya adalah Anda bisa menggabungkannya dengan filter rentang waktu dalam satu nilai tbs:
&tbs=qdr:m,sbd:1
Ini memberi hasil dari satu bulan terakhir, diurutkan berdasarkan tanggal — terbaru lebih dulu. Ini cara tercepat untuk menemukan apa yang baru saja diterbitkan tentang suatu topik. Saya sangat sering memakai kombinasi ini saat memantau konten kompetitor.
li:1 mengaktifkan mode verbatim — padanan URL dari mengklik alat "Verbatim" di antarmuka pencarian Google. Mode verbatim menonaktifkan koreksi otomatis, ekspansi sinonim, perubahan ejaan, dan modifikasi kueri otomatis lainnya.
Perbedaan li:1 dan nfpr=1 terletak pada cakupan:
nfpr=1: Hanya menekan penulisan ulang ejaan/kueri yang dipaksa (misalnya menghentikan Google mengubah "teh" menjadi "the")tbs=li:1: Menonaktifkan semua modifikasi otomatis — ejaan, sinonim, istilah terkait, penyesuaian personalisasi
Anda bahkan bisa menumpuk beberapa nilai tbs. Contohnya, tbs=qdr:m,sbd:1,li:1 memberi Anda hasil satu bulan terakhir, diurutkan berdasarkan tanggal, dengan pencocokan verbatim. Dalam pengujian saya, kombinasi ini bekerja, meski saya tetap menyarankan untuk memverifikasi dengan kueri spesifik Anda karena sintaks tbs memang tidak didokumentasikan secara resmi.
Cara Membuat Kode uule untuk Geo-Targeting Tingkat Kota
Kalau gl adalah lensa zoom tingkat negara, uule adalah mikroskop tingkat kota. Untuk SEO lokal — memeriksa bagaimana bisnis Anda ranking di Denver vs. Dallas, atau apa yang dilihat pencari di distrik Shibuya Tokyo — gl saja tidak cukup presisi.
Tidak ada artikel peringkat teratas yang benar-benar menjelaskan cara membangun kode uule — mereka hanya menyebut parameternya ada lalu lanjut. Berikut penjelasan lengkapnya.
Kapan Pakai gl vs. uule vs. cr
| Parameter | Tingkat Presisi | Use Case Umum | Perlu Encoding? |
|---|---|---|---|
gl=us | Tingkat negara | Simulasi negara dengan cepat | Tidak |
cr=countryUS | Tingkat negara (restrict) | Memfilter berdasarkan negara hosting | Tidak |
uule=w+CAIQICI... | Tingkat kota/DMA | Cek peringkat SEO lokal | Ya |
Algoritma Encoding uule (Langkah demi Langkah)
Parameter uule menggunakan sinyal lokasi bernama yang di-encode. Cara pembuatannya hasil reverse engineering, bukan dokumentasi resmi Google, tetapi sudah banyak divalidasi oleh komunitas SEO.
Pendekatan yang lebih aman adalah meng-encode payload Protocol Buffers kecil, alih-alih mengandalkan shortcut yang sering disalin ulang (yang bisa gagal untuk karakter non-ASCII). Berikut prosesnya:
- Ambil nama lokasi Google yang kanonik. Google menerbitkan target geografis dengan nama kanonik melalui data geographic targeting Google Ads API. Contoh:
New York,New York,United States - Encode nama itu sebagai byte UTF-8.
- Bangun payload protobuf kecil dengan nama dan panjang byte-nya.
- Lakukan base64url-encode pada payload lalu tambahkan awalan
w+.
Berikut potongan Python yang melakukan ini:
import base64
def encode_varint(value: int) -> bytes:
out = bytearray()
while True:
byte = value & 0x7F
value >>= 7
if value:
out.append(byte | 0x80)
else:
out.append(byte)
return bytes(out)
def build_uule(canonical_name: str) -> str:
name = canonical_name.encode("utf-8")
payload = b"\x08\x02\x10\x20\x12" + encode_varint(len(name)) + name
encoded = base64.urlsafe_b64encode(payload).decode().rstrip("=")
return "w+" + encoded
# Contoh
print(build_uule("New York,New York,United States"))
# Output: w+CAIQICIeTmV3IFlvcmssTmV3IFlvcmssVW5pdGVkIFN0YXRlcw
Saat memasukkan ini ke URL, pastikan tanda + literal pada w+ sudah di-encode dengan benar menjadi %2B oleh library URL Anda. Kebanyakan implementasi URLSearchParams atau urllib.parse.urlencode akan menangani ini otomatis.
uule yang dibangun dengan benar tetap hanya satu sinyal lokasi. Ini tidak mengalahkan alamat IP, pengaturan akun, perangkat, atau cohort eksperimen. Pakai untuk pengecekan SEO lokal yang bersifat arah, bukan sebagai jaminan ranking yang benar-benar spesifik di tingkat kota.
Saat Parameter URL Google Search Diam-Diam Saling Bertabrakan
Kombinasi parameter bisa gagal tanpa peringatan: Google bisa mengabaikan salah satu input, menulis ulang URL, atau menampilkan permukaan hasil yang berbeda. Pemeriksaan konflik di bawah ini layak ditambahkan ke setiap workflow tautan pencarian.
Tidak ada artikel pesaing yang membahas interaksi antar parameter. Tapi kalau Anda membangun URL pencarian dengan banyak parameter — dan kemungkinan besar memang begitu — Anda perlu tahu kombinasi mana yang cocok dan mana yang saling bentrok.
gl + uule: Mana yang Menang?
Saat keduanya ada, uule memberi sinyal lokasi yang lebih spesifik daripada gl. Kalau Anda set gl=uk dan uule menunjuk Tokyo, yang Anda dapatkan adalah hasil yang dipengaruhi Tokyo, bukan hasil UK.
Rekomendasi: Kalau menggunakan uule, baiknya kosongkan gl atau set gl ke negara yang menaungi kota pada uule Anda. Jangan kirim sinyal yang saling bertentangan.
tbm + udm: Jangan Pakai Keduanya
Dalam pengujian saya, saat tbm dan udm sama-sama ada di URL yang sama, Google kadang menghapus keduanya dan mengembalikan kueri web biasa. Perilakunya tidak konsisten antar sesi dan akun.
Rekomendasi: Untuk implementasi baru, gunakan hanya udm. Kalau harus mendukung workflow lama, pakai salah satu saja — jangan pernah dua-duanya.
lr + cr: Penyaringan Ganda Bisa Menghasilkan Nol Hasil
Ini jebakan yang halus. lr=lang_en membatasi ke konten berbahasa Inggris. cr=countryJP membatasi ke halaman yang di-host di Jepang. Gabungkan keduanya dan Anda meminta "halaman berbahasa Inggris yang di-host di Jepang" — yang jumlahnya sangat kecil.
Rekomendasi: Pakai salah satu saja kecuali Anda memang sengaja membutuhkan irisan keduanya. Kalau digabung, bersiaplah mendapat hasil yang jauh lebih sedikit.
num + start: Pagination Rusak
Skrip lama yang memakai num=100&start=0 sekarang diam-diam hanya mengembalikan sekitar 10 hasil. Parameter num tidak lagi dihormati, tetapi tidak memunculkan error — hanya diabaikan.
Rekomendasi: Hapus num dari semua URL. Lakukan pagination dengan start bertahap 10 dan deduplikasi hasil antar halaman.
Referensi Konflik Cepat
| Kombinasi | Apa yang Terjadi | Rekomendasi |
|---|---|---|
gl + uule | uule memberi sinyal yang lebih spesifik | Samakan negara dan kota, atau hapus gl |
tbm + udm | Tidak terduga — keduanya bisa dihapus | Pakai hanya udm |
lr + cr | Penyempitan agresif, sering hampir nol hasil | Pakai salah satu saja |
num + start | num diabaikan, hanya ~10 hasil yang kembali | Hapus num, pagination dengan start |
nfpr=1 + tbs=li:1 | Kontrol terkait tapi tidak identik | Uji kueri spesifik Anda |
hl + lr | Bahasa antarmuka ≠ pembatas bahasa konten | Gunakan dengan sengaja; hl bukan filter konten |
Dari Parameter URL Google Search ke Ekstraksi Data Terstruktur
Sampai titik ini Anda sudah punya URL Google Search yang presisi — kueri tepat, negara tepat, rentang tanggal tepat, hasil web klasik. Langkah berikutnya adalah mengubah hasil itu menjadi data terstruktur.
Baik Anda membangun rank tracker, memantau kompetitor, atau memasukkan data pencarian ke workflow riset, melihat hasil yang benar baru separuh pekerjaan. Anda butuh judul, URL, snippet, posisi, dan tanggal dalam spreadsheet atau database.
Membuat URL Pencarian Google yang Ditargetkan (Menggabungkan Semuanya)
Contoh lengkap yang menggabungkan beberapa parameter:
https://www.google.com/search?q=site%3Acompetitor.com+intitle%3Apricing&hl=en&gl=us&tbs=qdr:m,sbd:1&udm=14&pws=0
Rinciannya:
q=site%3Acompetitor.com+intitle%3Apricing— halaman di competitor.com dengan kata "pricing" di judulhl=en— antarmuka bahasa Inggrisgl=us— konteks pasar AStbs=qdr:m,sbd:1— satu bulan terakhir, diurutkan berdasarkan tanggaludm=14— hasil web klasik (tanpa AI Overviews)pws=0— personalisasi dimatikan
Anda bisa membangunnya secara programatis dengan curl:
curl -L -G 'https://www.google.com/search' \
--data-urlencode 'q=site:competitor.com intitle:pricing' \
--data-urlencode 'hl=en' \
--data-urlencode 'gl=us' \
--data-urlencode 'tbs=qdr:m,sbd:1' \
--data-urlencode 'udm=14' \
--data-urlencode 'pws=0' \
-H 'User-Agent: Mozilla/5.0'
Atau dengan Python:
import requests
params = {
"q": "site:competitor.com intitle:pricing",
"hl": "en",
"gl": "us",
"tbs": "qdr:m,sbd:1",
"udm": "14",
"pws": "0",
}
response = requests.get(
"https://www.google.com/search",
params=params,
headers={"User-Agent": "Mozilla/5.0"},
timeout=20,
)
print(response.url)
Request HTTP anonim ke Google sering kali hanya mengembalikan shell JavaScript tanpa hasil yang dirender di server, atau peringatan traffic tidak biasa — dan justru di situlah ekstraksi berbasis browser punya keunggulan.
Mengekstrak Data SERP Tanpa Menulis Parser
Parsing HTML Google itu rapuh. Struktur DOM sering berubah, nama class di-obfuscate, dan apa yang Anda lihat di browser belum tentu sama dengan respons HTTP mentah.
Pendekatan yang lebih sederhana untuk non-developer: buka URL pencarian yang sudah Anda susun rapi di Chrome, lalu gunakan tool ekstraksi berbasis browser untuk menarik data terstruktur dari halaman yang terlihat. Di Thunderbit, kami membangun ekstensi Chrome untuk menangani alur kerja seperti ini — Anda bisa memakai AI Suggest Fields untuk mengenali kolom seperti judul hasil, URL tujuan, teks snippet, dan posisi yang terlihat, lalu mengekstraknya ke spreadsheet tanpa menulis parser.
Ini bukan satu-satunya jalan. Pendekatan berbasis kode juga bisa, terutama jika Anda perlu menangani ekstraksi skala besar atau berulang. Tapi untuk riset ad-hoc, audit, dan analisis kompetitor satu kali, ekstraksi berbasis browser menghindari kerentanan parsing HTML sepenuhnya.
Kapan Sebaiknya Pakai API Resmi
Catatan penggunaan yang bertanggung jawab — dan ini penting.
Ketentuan Layanan Google melarang akses otomatis yang melewati mekanisme perlindungan, dan Google Search Help secara eksplisit mengklasifikasikan search scraper dan software yang mengirim kueri otomatis untuk menentukan peringkat sebagai traffic otomatis. Menjalankan scraper Google skala produksi menempatkan Anda pada risiko blokir IP, CAPTCHA, dan potensi masalah hukum.
Untuk kebutuhan data pencarian skala produksi dan volume tinggi, jalur yang lebih baik adalah API resmi. Custom Search JSON API milik Google ditutup untuk pelanggan baru — pengguna yang sudah ada punya waktu sampai 1 Januari 2027 untuk migrasi, dengan 100 kueri gratis per hari dan $5 per 1.000 kueri setelah itu. Ke depan, Google merekomendasikan Vertex AI Search untuk pencarian pada situs yang terkontrol.
Untuk situs yang Anda miliki sendiri, Search Console's Search Analytics API adalah sumber pihak pertama untuk klik, impresi, CTR, dan posisi rata-rata — tanpa scraping.
Anggap pengetahuan parameter URL sebagai alat diagnosis dan riset: bagus untuk membuat tautan pencarian yang presisi, menjalankan audit manual, dan memahami bagaimana Google menampilkan hasil. Bukan pengganti API resmi dalam skala besar.
Operator Pencarian Google: Parameter di Dalam Kueri Anda
Operator pencarian berada di dalam parameter q=, tetapi tetap pasangan penting bagi parameter URL. Tabel di bawah mencakup yang saat ini didokumentasikan Google plus beberapa yang masih bekerja di praktik:
| Operator | Fungsinya | Contoh |
|---|---|---|
site: | Membatasi ke domain tertentu | q=site:example.com+SEO |
filetype: | Membatasi ke tipe file tertentu | q=filetype:pdf+annual+report |
intitle: | Kata harus muncul di judul | q=intitle:pricing+SaaS |
inurl: | Kata harus muncul di URL | q=inurl:blog+marketing |
- | Mengecualikan istilah | q=apple+-fruit |
"" | Pencocokan frasa persis | q=%22google+search+url+parameters%22 |
OR | Salah satu istilah | q=scraping+OR+crawling |
before: | Hasil sebelum tanggal tertentu | q=AI+before:2026-01-01 |
after: | Hasil setelah tanggal tertentu | q=AI+after:2025-06-01 |
related: | Situs serupa | q=related:hubspot.com |
Kekuatan sebenarnya muncul saat Anda menggabungkan operator di dalam q dengan parameter URL di luar q:
q=site:competitor.com+intitle:pricing+after:2026/01/01&tbs=sbd:1&gl=us&udm=14
Ini menemukan halaman di competitor.com dengan "pricing" di judul, diterbitkan setelah Januari 2026, diurutkan berdasarkan tanggal, dalam pasar AS, dengan hasil web klasik. Itu query competitive intelligence yang sangat presisi, seluruhnya dibangun dari parameter URL dan operator.
Google menyebut hasil site: tidak dijamin lengkap — jadi jangan menganggap kueri site: sebagai inventaris lengkap dari semua halaman yang terindeks.
Penggunaan yang Bertanggung Jawab: Ketentuan Layanan Google dan Batas Kecepatan
Konteks singkat tapi penting.
Ketentuan Layanan Google melarang akses abusif dan penghindaran mekanisme perlindungan. Google Search Help secara spesifik menyinggung search scraper dan software ranking otomatis sebagai contoh traffic otomatis. Melanggar ketentuan ini bisa berakibat blokir IP, CAPTCHA, pembatasan akun, dan bahkan tindakan hukum.
Pengetahuan parameter URL paling baik dipakai untuk: menyusun URL pencarian presisi secara manual, membuat tautan pencarian yang bisa dibookmark untuk tim, menjalankan audit skala kecil di browser, dan memahami cara kerja antarmuka pencarian Google. Untuk kerja otomatis skala produksi, gunakan API resmi Google — atau penyedia data pencarian pihak ketiga berlisensi seperti Brave Search API.
Di Thunderbit, ekstensi browser kami dibuat untuk ekstraksi pada halaman yang terlihat dan dipicu pengguna — bukan untuk kueri Google otomatis bervolume tinggi. Itu perbedaan penting.
Poin-Poin Penting: Toolkit Parameter URL Google Search 2026 Anda
Versi singkatnya:
- Gunakan
gl+hluntuk sinyal lokalisasi dan jangan hanya bergantung pada ccTLD selama migrasi redirect Google - Uji
udmdantbmjika relevan — keduanya bukan API konsumen yang stabil dan berversi udm=14bisa meminta hasil web klasik tanpa AI Overviews, tetapi Google bisa menghapus atau menulis ulangnya- Gunakan
uuleuntuk geo-targeting tingkat kota dengan rumus encoding protobuf di atas - Kuasi
tbsuntuk filter tanggal presisi (cdr:1,cd_min:...,cd_max:...), pengurutan berdasarkan tanggal (sbd:1), dan pencarian verbatim (li:1) - Waspadai konflik parameter:
glvs.uule,tbmvs.udm,lrvs.cr num=100tidak andal dan memang tidak pernah didukung secara formal — pakaistartper 10 sebagai default yang lebih aman- Untuk data SERP terstruktur, gunakan tool berbasis browser seperti Thunderbit untuk pekerjaan ad-hoc, atau API resmi untuk skala produksi
- Hormati Ketentuan Layanan Google — parameter URL adalah alat riset, bukan lisensi scraping
Google terus mengubah parameter tanpa pengumuman. Saya akan terus memperbarui referensi ini seiring perubahan — bookmark dan cek lagi nanti.
Pelajari Lebih Lanjut
- 9 API SEO Terbaik untuk 2026 (Dengan Data Biaya per Request Nyata)
- Cara Menguasai Search Engine Scraping: Panduan Lengkap
- 27 Tool Terbaik untuk Menganalisis dan Memantau Peringkat Website
- Cara Menggunakan Pagination Web Scraper untuk Ekstraksi yang Efisien
- Apa Itu Otomatisasi Pencarian? Manfaat, Tool, dan Strateginya
FAQ
Apa fungsi udm=14 dalam URL pencarian Google?
udm=14 dapat meminta tampilan hasil web klasik tanpa AI Overviews, itulah sebabnya parameter ini populer di kalangan praktisi SEO. Parameter ini hasil reverse engineering, bukan kontrak resmi Google yang terdokumentasi, dan Google bisa menghapus atau menulis ulangnya tergantung sesi, akun, region, client, dan cohort eksperimen.
Apakah parameter num masih bekerja di 2026?
Jangan mengandalkannya. Google berhenti secara konsisten menghormati num=100 pada September 2025, dan seorang juru bicara mengatakan parameter itu memang tidak pernah didukung secara formal. Gunakan start per 10 sebagai default pagination yang lebih aman, dan verifikasi jumlah hasil yang kembali karena Google masih bisa menulis ulang atau membatasi respons.
Bagaimana cara mensimulasikan pencarian Google dari kota tertentu?
Gunakan parameter uule dengan nama kota yang sudah di-encode. Bagian encoding di atas menyediakan algoritma berbasis protobuf dan contoh kode Python. Anda membutuhkan nama lokasi Google yang kanonik (tersedia dari Google Ads geographic targeting data), lalu Anda encode ke nilai uule seperti uule=w+CAIQICIeNew+York,New+York,United+States.
Apa perbedaan gl, lr, dan cr?
Ketiga parameter ini mengontrol aspek yang berbeda dari penargetan geografis dan bahasa. gl mensimulasikan lokasi pencarian di tingkat negara (memengaruhi ranking dan hasil lokal). lr membatasi hasil ke halaman yang ditulis dalam bahasa konten tertentu. cr membatasi hasil ke halaman yang di-host di negara tertentu. Parameter ini bisa digabung, tetapi kombinasi yang saling bertentangan (seperti lr=lang_en + cr=countryJP) akan sangat mempersempit hasil Anda.
Bisakah saya menggabungkan beberapa nilai tbs dalam satu URL?
Bisa — pisahkan dengan koma dalam satu parameter tbs. Misalnya, tbs=qdr:m,sbd:1 memfilter ke satu bulan terakhir dan mengurutkan berdasarkan tanggal (terbaru dulu). Anda juga bisa menambahkan li:1 untuk mode verbatim: tbs=qdr:m,sbd:1,li:1. Sintaks tbs tidak didokumentasikan secara resmi, jadi uji kombinasi spesifik Anda untuk memastikan bekerja seperti yang diharapkan.
