Tham số URL tìm kiếm Google: Những gì còn hoạt động trong năm 2026

Vào khoảng tháng 9/2025, một loạt công cụ SEO và script tùy chỉnh bỗng âm thầm ngừng hoạt động. Lý do là gì? Google đã không còn hỗ trợ ổn định tham số num=100 — thứ mà người dùng nâng cao vẫn dựa vào suốt nhiều năm để lấy 100 kết quả mỗi trang. Không có bất kỳ thông báo ngừng hỗ trợ chính thức nào cả — chỉ có một phát ngôn viên nói với Search Engine Land rằng tham số này “không được hỗ trợ chính thức”. Cùng lúc đó, Google tung ra thêm nhiều chế độ udm bên cạnh các vertical tbm cũ, thông báo rằng các tên miền quốc gia sẽ dần chuyển hướng về google.com, và cho biết AI Overviews đã đạt hơn 2,5 tỷ người dùng mỗi tháng.

Nếu bạn đang dựng URL tìm kiếm, theo dõi thứ hạng hoặc tự động hóa nghiên cứu bằng các tham số URL của Google, rất có thể một số quy trình của bạn hiện đã bị ảnh hưởng âm thầm. Tại Thunderbit, chúng tôi đã rà soát tài liệu Google hiện tại, các thông báo thay đổi gần đây, những tham chiếu được phân tích ngược và các kiểm tra thực tế để tách bạch đâu là điều khiển ổn định và đâu là điều khiển mang tính ngữ cảnh. Kết quả là một tài liệu tham chiếu có mốc thời gian, bạn nên kiểm tra trước khi triển khai cho các tham số URL tìm kiếm Google quan trọng trong năm 2026, bao gồm ánh xạ tbm/udm, công thức mã hóa uule cho nhắm mục tiêu theo thành phố, và các xung đột tham số có thể giúp tiết kiệm hàng giờ gỡ lỗi.

Tham số URL tìm kiếm Google là gì?

Tham số URL tìm kiếm Google là các cặp key=value xuất hiện sau dấu ? trong một URL tìm kiếm Google. Chúng điều khiển đủ thứ: bạn đang tìm gì, thấy kết quả của quốc gia nào, hay nhận hình ảnh, tin tức hoặc các liên kết xanh kiểu truyền thống.

Một URL tìm kiếm Google điển hình được cấu trúc như sau:

https://www.google.com/search?q=best+crm+software&hl=en&gl=us&tbs=qdr:m

• URL gốc: https://www.google.com/search
• ? mở đầu chuỗi truy vấn
• q=best+crm+software là truy vấn tìm kiếm (khoảng trắng được mã hóa thành +)
• & phân tách từng tham số
• hl=en đặt ngôn ngữ giao diện là tiếng Anh
• gl=us cho Google hiểu như thể bạn đang tìm kiếm từ Mỹ
• tbs=qdr:m lọc kết quả trong tháng gần nhất

Một điểm cần phân biệt: các toán tử tìm kiếm như site:, filetype: và intitle: nằm bên trong giá trị q=. Chúng là một phần của truy vấn. Trong khi đó, các tham số URL như gl, hl và tbs là những key riêng trong URL, điều khiển cách Google xử lý và hiển thị kết quả. Cả hai đều quan trọng và phối hợp với nhau — nhưng chúng là hai thứ khác nhau.

Google chưa từng công bố một bộ đặc tả duy nhất, có phiên bản hóa cho các tham số này. Một số đến từ biểu mẫu Tìm kiếm nâng cao, một số đến từ Custom Search API, và một số được suy ra bằng cách quan sát các URL của chính Google. Vì vậy, bài viết bạn đang đọc dựa trên kiểm thử thực tế và hành vi đã được ghi nhận, chứ không phải một hợp đồng API chính thức.

Vì sao tham số URL tìm kiếm Google vẫn quan trọng trong năm 2026?

Các tham số URL không chỉ là chuyện của lập trình viên. Bất kỳ ai làm SEO, marketing, sales, vận hành hay product — nếu cần hiểu Google hiển thị gì cho một truy vấn cụ thể, ở một thị trường cụ thể, vào một thời điểm cụ thể — thì đây chính là bộ công cụ của bạn.

Tóm tắt nhanh các nhóm hưởng lợi và cách họ dùng:

Trường hợp sử dụng	Ai được lợi	Tham số chính
Theo dõi thứ hạng SEO đa quốc gia	Team SEO & Marketing	gl, hl, uule, pws
Theo dõi đối thủ theo ngày	Team Strategy & Ops	tbs, q với site:
Giám sát quảng cáo theo thị trường	Team Paid Media	gl, hl, udm
Audit SEO local (cấp thành phố)	Chủ doanh nghiệp địa phương	uule, gl
Nghiên cứu nội dung / theo dõi xu hướng	Team Content	tbs (lọc ngày), lr
Đưa dữ liệu tìm kiếm vào ứng dụng AI/LLM	Team Product & Data	Nhiều tham số + trích xuất có cấu trúc

Ba thay đổi lớn khiến năm 2026 khác hẳn:

1. num=100 không còn đáng tin cậy. Thủ thuật lấy nhiều kết quả mỗi trang cũ đã ngừng hoạt động ổn định vào tháng 9/2025. Google không chính thức ngừng hỗ trợ; người phát ngôn chỉ nói rằng nó chưa bao giờ được hỗ trợ chính thức.
2. Chuyển hướng ccTLD là một quá trình chuyển đổi, không phải đã hoàn tất. Google thông báo vào tháng 4/2025 rằng các tên miền theo mã quốc gia (google.co.uk, google.de, v.v.) sẽ dần chuyển hướng về google.com. Google chưa công bố mốc hoàn tất, vì vậy đừng cho rằng mọi locale đã giống hệt nhau.
3. AI Overviews đã làm thay đổi SERP. Google cho biết AI Overviews đã đạt hơn 2,5 tỷ người dùng mỗi tháng và hơn 200 quốc gia và vùng lãnh thổ. Các chế độ udm được reverse-engineer có thể thay đổi bề mặt kết quả trong một số ngữ cảnh, nhưng không phải là nút bật AI Overview chắc chắn.

Nếu quy trình của bạn chưa được cập nhật theo những thay đổi này, rất có thể bạn đang nhận kết quả suy giảm hoặc gây hiểu nhầm mà không hề hay biết.

Bảng tra cứu nhanh tham số URL tìm kiếm Google (2026)

Trước khi đi sâu hơn, bảng tham khảo nhanh dưới đây là danh sách cập nhật nhất mà tôi có thể tổng hợp. Hãy đánh dấu lại.

Tham số	Tác dụng	Giá trị ví dụ	Trạng thái
q	Truy vấn tìm kiếm (hỗ trợ toán tử bên trong)	q=best+crm+software	✅ Đang hoạt động
hl	Ngôn ngữ giao diện	hl=en, hl=ja	✅ Đang hoạt động
gl	Ngữ cảnh quốc gia/thị trường	gl=us, gl=jp	✅ Đang hoạt động
lr	Giới hạn kết quả theo ngôn ngữ nội dung	lr=lang_en	✅ Đang hoạt động
cr	Giới hạn kết quả theo quốc gia lưu trữ	cr=countryUS	✅ Đang hoạt động
start	Vị trí phân trang	start=10 (trang 2)	✅ Đang hoạt động
num	Số kết quả mỗi trang (trước đây)	num=100	⚠️ Không được hỗ trợ chính thức; không ổn định từ 9/2025
udm	Chế độ nội dung theo ngữ cảnh	udm=14 (web cổ điển)	⚠️ Reverse-engineered; thay đổi theo ngữ cảnh
tbm	Vertical tìm kiếm	tbm=isch (hình ảnh)	⚠️ Vẫn còn thấy; nên test cùng udm
tbs	Bộ lọc thời gian, sắp xếp, verbatim	tbs=qdr:w	✅ Đang hoạt động
safe	Điều khiển SafeSearch	safe=active	✅ Đang hoạt động
filter	Lọc kết quả trùng lặp	filter=0	✅ Đang hoạt động (quan sát được)
nfpr	Tắt tự động sửa truy vấn	nfpr=1	✅ Đang hoạt động (quan sát được)
pws	Tắt cá nhân hóa	pws=0	✅ Đang hoạt động
uule	Nhắm mục tiêu theo thành phố/DMA	uule=w+CAIQICI...	✅ Đang hoạt động (reverse-engineered)
as_q, as_epq, as_eq, v.v.	Các trường của biểu mẫu Tìm kiếm nâng cao	Nhiều giá trị	✅ Đang hoạt động
as_sitesearch	Giới hạn theo một tên miền (Advanced Search)	as_sitesearch=example.com	✅ Đang hoạt động
as_filetype	Giới hạn theo loại file (Advanced Search)	as_filetype=pdf	✅ Đang hoạt động
ie, oe	Mã hóa đầu vào/đầu ra	ie=UTF-8	✅ Đang hoạt động (hiếm khi cần)
kgmid, si, ibp	Thực thể Knowledge Graph / chế độ hiển thị tính năng	Nhiều giá trị	⚠️ Theo ngữ cảnh (không dùng chung)
ei, ved, sxsrf, sclient	Phiên/ theo dõi/ telemetry	Nhiều giá trị	🔒 Nội bộ (bỏ qua)
gbv	Chế độ HTML cơ bản (trước đây)	gbv=1	❌ Không đáng tin trong năm 2026

Hãy loại bỏ ei, ved, sxsrf và sclient khỏi mọi URL bạn lưu hoặc chia sẻ. Đây là trạng thái phiên và telemetry mà Google tự gắn vào — không liên quan gì đến việc dựng URL tìm kiếm.

Những tham số URL tìm kiếm Google cốt lõi vẫn còn hoạt động

Tôi đã kiểm thử từng tham số dưới đây trên môi trường thực vào giữa năm 2026. Đây là những tham số bạn sẽ dùng thường xuyên nhất.

q — Truy vấn tìm kiếm của bạn

Tham số q chứa các từ khóa tìm kiếm của bạn. Khoảng trắng được mã hóa bằng + hoặc %20. Đây là nơi các toán tử tìm kiếm được Google công bố xuất hiện — chúng nằm bên trong giá trị q, không phải là tham số URL riêng biệt.

Một vài ví dụ:

• Cụm từ chính xác: q=%22google+search+url+parameters%22
• Giới hạn theo site: q=site%3Aexample.com+pricing
• Loại file: q=filetype%3Apdf+annual+report+2026
• Kết hợp: q=site%3Acompetitor.com+intitle%3Apricing+after%3A2026%2F01%2F01

Luôn mã hóa URL cho toàn bộ giá trị truy vấn. Dấu ngoặc kép, dấu hai chấm và dấu gạch chéo đều cần được mã hóa đúng cách để tránh làm hỏng URL.

hl — Ngôn ngữ giao diện

hl điều khiển ngôn ngữ giao diện của Google (nút bấm, nhãn, tiêu đề “People also ask”) và ảnh hưởng đến loại kết quả mà Google ưu tiên. Nó dùng mã ISO 639-1 như en, fr, de, ja, hoặc các thẻ BCP 47 như en-gb hay pt-br.

hl không ép tất cả tài liệu kết quả phải cùng ngôn ngữ đó. Đây là một tín hiệu mạnh, nhưng Google vẫn có thể hiển thị kết quả ở ngôn ngữ khác nếu chúng rất liên quan. Nếu muốn giới hạn theo ngôn ngữ nội dung, hãy dùng lr.

gl — Quốc gia / vị trí địa lý

gl mô phỏng quốc gia bạn đang tìm kiếm từ đó, dùng mã ISO 3166-1 alpha-2 (us, gb, jp, de). Khi ccTLD đang dần chuyển hướng về google.com, gl giờ là cách chính để lấy kết quả theo quốc gia.

Cùng một truy vấn nhưng khác gl có thể trả về hoàn toàn khác nhau về kết quả, featured snippet và local pack. Ví dụ, q=best+bank&gl=us và q=best+bank&gl=jp sẽ cho bạn thấy các ngân hàng rất khác nhau.

Mẹo hay: luôn ghép gl với hl để có kết quả bản địa hóa chính xác. Dùng gl=jp cùng hl=en sẽ cho bạn kết quả thị trường Nhật nhưng giao diện tiếng Anh — rất hữu ích cho audit SEO quốc tế.

lr và cr — Giới hạn theo ngôn ngữ và theo quốc gia

Hai tham số này thường bị nhầm lẫn. Điểm khác nhau rất quan trọng:

• lr=lang_en giới hạn kết quả ở các trang viết bằng tiếng Anh (ngôn ngữ nội dung)
• cr=countryUS giới hạn kết quả ở các trang được lưu trữ tại Hoa Kỳ (vị trí máy chủ / liên kết quốc gia)
• gl=us mô phỏng việc tìm kiếm từ Hoa Kỳ (ảnh hưởng thứ hạng, kết quả địa phương, quảng cáo)

Cả lr và cr đều có trong biểu mẫu Tìm kiếm nâng cao của Google. Hãy cẩn thận khi kết hợp chúng — lr=lang_en + cr=countryJP có nghĩa là “chỉ các trang tiếng Anh được lưu trữ tại Nhật Bản”, một tập cực kỳ hẹp. Sẽ nói thêm ở phần xung đột.

start — Phân trang

start=10 yêu cầu kết quả bắt đầu từ vị trí thứ 11 (trang 2), start=20 là trang 3, và cứ thế tiếp tục. Vì num=100 không còn đáng tin cậy, tăng start theo bước 10 là mặc định an toàn hơn — nhưng Google vẫn có thể viết lại hoặc giới hạn phân trang.

Thủ thuật cũ num=100&start=0 để kéo một trang đầy đủ 100 kết quả không còn hoạt động. Nếu script của bạn vẫn còn num, hãy xóa nó — Google đang bỏ qua nó một cách im lặng.

pws — Tắt cá nhân hóa

pws=0 yêu cầu Google tắt cá nhân hóa dựa trên tài khoản. Điều này rất cần thiết cho theo dõi thứ hạng SEO, khi bạn muốn kết quả không bị méo bởi lịch sử tìm kiếm, các kết quả đã nhấp trước đó hoặc tùy chọn tài khoản của bạn.

Lưu ý: pws=0 chỉ giảm cá nhân hóa chứ không loại bỏ hoàn toàn mọi yếu tố ngữ cảnh. Google nói rằng kết quả vẫn có thể khác nhau theo thời gian, vị trí, ngôn ngữ và thiết bị. Không tồn tại một SERP Google hoàn toàn “trung tính”.

safe và filter — SafeSearch và lọc trùng lặp

• safe=active bật SafeSearch; safe=off tắt nó. Lưu ý rằng cài đặt tài khoản, chính sách quản trị, cấu hình mạng hoặc luật khu vực có thể ghi đè tham số này.
• filter=0 tắt lọc kết quả trùng lặp của Google. Hữu ích khi bạn muốn thấy toàn bộ kết quả Google có, bao gồm cả các bản gần trùng lặp mà bình thường nó sẽ gộp lại.

nfpr — Tắt tự động sửa lỗi

nfpr=1 ngăn Google viết lại truy vấn của bạn một cách ép buộc khi nó nghĩ rằng bạn gõ sai chính tả. Điều này hữu ích để theo dõi các từ khóa thương hiệu có cách viết lạ, thuật ngữ kỹ thuật hoặc các truy vấn cố tình viết sai mà đối thủ đang nhắm đến.

Lưu ý rằng nfpr=1 chỉ ngăn việc viết lại bắt buộc. Để kiểm soát rộng hơn — tắt mở rộng đồng nghĩa, sửa chính tả và các thay đổi tự động khác — hãy dùng tbs=li:1 (chế độ verbatim), phần này tôi sẽ trình bày ngay bên dưới.

Chuyển từ tbm sang udm: Điều gì đã đổi và nên dùng gì bây giờ

Đây là một trong những thay đổi tham số lớn nhất trong vài năm gần đây — và cũng là một thay đổi rất dễ bị nói quá.

tbm từ lâu đã là cách phổ biến để chuyển giữa các vertical tìm kiếm của Google — hình ảnh, tin tức, video, mua sắm — suốt hơn một thập kỷ. Google cũng đã giới thiệu hệ thống số udm với các chế độ chồng lấp và bổ sung. Vì Google chưa công bố một registry ổn định cho người dùng phổ thông, hãy coi đây là ánh xạ theo ngữ cảnh chứ không phải một sự thay thế sạch sẽ và hoàn chỉnh.

Bảng ánh xạ đầy đủ từ tbm sang udm

Các ánh xạ dưới đây kết hợp hành vi giao diện quan sát được và các kiểm tra thực tế ngày 12/08/2026. Một số giá trị đã bị loại bỏ hoặc viết lại trong các yêu cầu ẩn danh, vì vậy mọi dòng đều cần được test trong đúng tài khoản, khu vực và client nơi nó sẽ được sử dụng:

Tham số cũ	Giá trị cũ	Tham số mới	Giá trị mới	Trạng thái
tbm=lcl	Địa điểm/Local	udm=1	Địa điểm/Local	⚠️ Theo ngữ cảnh
tbm=isch	Hình ảnh	udm=2	Hình ảnh	⚠️ Theo ngữ cảnh
tbm=vid	Video	udm=7	Video	⚠️ Theo ngữ cảnh
tbm=nws	Tin tức	udm=12	Tin tức	⚠️ Theo ngữ cảnh
—	—	udm=14	Web cổ điển (không AI Overview)	🆕 Mới, không có đối chiếu tbm
—	—	udm=18	Diễn đàn	🆕 Mới, không có đối chiếu tbm
tbm=shop	Mua sắm	udm=28	Mua sắm	⚠️ Theo ngữ cảnh
tbm=bks	Sách	udm=36	Sách	⚠️ Theo ngữ cảnh
—	—	udm=39	Video ngắn	🆕 Mới, không có đối chiếu tbm
—	—	udm=50	Chế độ AI Overview	🆕 Mới, không có đối chiếu tbm

Google chưa công bố một registry udm ổn định — đây là lưu ý cực kỳ quan trọng. Các giá trị này được reverse-engineer từ hành vi giao diện của Google. Mức độ chấp nhận URL thay đổi theo tài khoản, khu vực, client, cookie và nhóm thử nghiệm. Trong các thử nghiệm của tôi, một số giá trị udm bị xóa trong các yêu cầu HTTP ẩn danh nhưng lại hoạt động bình thường trong phiên trình duyệt tương tác. Đừng mặc định rằng mọi giá trị đều hoạt động ở mọi nơi.

udm=14 làm gì (và vì sao SEO thích nó)

udm=14 đã trở thành một kiểu “mã được cộng đồng SEO yêu thích”. Android Central mô tả nó như một cách yêu cầu bề mặt kết quả web cổ điển mà không có AI Overviews. Trong nhiều phiên, nó tạo ra SERP kiểu liên kết xanh truyền thống, nhưng đây không phải là cam kết chính thức hay đảm bảo áp dụng cho mọi trường hợp.

Vì sao điều này quan trọng? Nếu bạn đang theo dõi thứ hạng hoặc audit SEO, AI Overviews có thể đẩy kết quả organic xuống dưới màn hình đầu tiên, khiến việc đánh giá vị trí khó hơn. udm=14 có thể cho bạn cái nhìn sạch hơn khi Google chấp nhận nó.

Tuy vậy, udm=14 không được đảm bảo hoạt động trong mọi ngữ cảnh. Trong các spot check thực tế ngày 12/08/2026, Google đôi khi xóa hoặc viết lại các giá trị udm tùy theo bối cảnh yêu cầu. Kết quả thực tế sẽ khác nhau theo phiên, tài khoản, khu vực, client và nhóm thử nghiệm.

udm=50 đã được quan sát trong bối cảnh AI Mode/AI-result, nhưng không nên mô tả nó là cách chắc chắn để ép một truy vấn bất kỳ hiển thị AI Overview.

Nên làm gì: Cập nhật quy trình từ tbm sang udm

Khuyến nghị của tôi:

• Triển khai mới: Hãy coi udm là đầu vào thử nghiệm/theo ngữ cảnh và thiết kế fallback.
• Quy trình hiện có: Hỗ trợ và test cả tbm lẫn udm ở những chỗ liên quan, thay vì giả định việc chuyển đổi đã hoàn tất.
• Không bao giờ dùng cả hai cùng lúc: Khi tbm và udm cùng xuất hiện trong một URL, hành vi sẽ khó đoán. Trong các thử nghiệm của tôi, Google đôi khi loại bỏ cả hai và trả về một truy vấn web thuần túy. Xem thêm ở phần xung đột.

Cú pháp tbs đầy đủ: khoảng ngày tùy chỉnh, sắp xếp theo ngày và verbatim

tbs là một trong những tham số mạnh nhất trong bộ công cụ URL tìm kiếm Google, nhưng hầu hết bài hướng dẫn chỉ mới chạm phần bề mặt. Nó xử lý lọc thời gian, sắp xếp theo ngày, chế độ verbatim, và nhiều thứ khác — tất cả gói trong một giá trị phân tách bằng dấu phẩy.

Bộ lọc thời gian tiêu chuẩn

Giá trị tbs	Ý nghĩa	Mẫu phần URL
qdr:h	Trong 1 giờ qua	&tbs=qdr:h
qdr:d	Trong 24 giờ qua	&tbs=qdr:d
qdr:w	Trong 1 tuần qua	&tbs=qdr:w
qdr:m	Trong 1 tháng qua	&tbs=qdr:m
qdr:y	Trong 1 năm qua	&tbs=qdr:y

Đây là những gì hầu hết hướng dẫn đều đề cập. Nhưng tbs có thể làm nhiều hơn thế.

Khoảng ngày tùy chỉnh

Cần kết quả từ một khung thời gian cụ thể? Hãy dùng cú pháp 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

Cú pháp này lọc kết quả mà Google gán cho các mốc thời gian từ ngày 1/1/2026 đến 1/6/2026. Nó cực kỳ hữu ích cho nghiên cứu đối thủ — ví dụ: “đối thủ đã đăng gì về giá trong Q1/2026?” Chỉ cần nhớ mã hóa URL cho toàn bộ giá trị, vì dấu hai chấm và dấu gạch chéo cần được mã hóa.

Một lưu ý thực tế: việc gán ngày của Google không phải lúc nào cũng chính xác. Ngày hiển thị trong kết quả tìm kiếm là phỏng đoán tốt nhất của Google, chứ không nhất thiết là ngày xuất bản thật. Luôn kiểm tra lại ngày trên trang đích.

Sắp xếp theo ngày và chế độ Verbatim

Đây là phần mà hướng dẫn này đi xa hơn những bài khác.

sbd:1 sắp xếp kết quả theo ngày (mới nhất trước). Bản thân nó đã hữu ích, nhưng chưa thật sự nổi bật. Mẹo ở đây là bạn có thể kết hợp nó với bộ lọc khoảng thời gian trong cùng một giá trị tbs:

&tbs=qdr:m,sbd:1

Cách này cho bạn kết quả trong tháng gần nhất, được sắp theo ngày — mới nhất lên trước. Đây là cách nhanh nhất để tìm nội dung vừa mới được đăng về một chủ đề. Tôi dùng tổ hợp này liên tục khi theo dõi nội dung của đối thủ.

li:1 bật chế độ verbatim — tương đương ở dạng URL của việc nhấp vào công cụ “Verbatim” trong giao diện tìm kiếm của Google. Verbatim mode tắt tự động sửa lỗi, mở rộng đồng nghĩa, thay đổi chính tả và các chỉnh sửa tự động khác đối với truy vấn.

Sự khác nhau giữa li:1 và nfpr=1 nằm ở phạm vi:

• nfpr=1: Chỉ ngăn việc viết lại truy vấn/chính tả bắt buộc (ví dụ: ngăn Google đổi “teh” thành “the”)
• tbs=li:1: Tắt mọi chỉnh sửa tự động — chính tả, đồng nghĩa, thuật ngữ liên quan, điều chỉnh cá nhân hóa

Bạn thậm chí có thể xếp nhiều giá trị tbs cùng lúc. Ví dụ, tbs=qdr:m,sbd:1,li:1 cho bạn kết quả trong tháng gần nhất, sắp theo ngày, với khớp verbatim. Trong các thử nghiệm của tôi, tổ hợp này hoạt động, nhưng tôi khuyên bạn nên kiểm tra lại với truy vấn cụ thể của mình vì cú pháp tbs là không được tài liệu hóa.

Cách tạo mã uule cho nhắm mục tiêu theo thành phố

Nếu gl là kính zoom cấp quốc gia, thì uule là kính hiển vi cấp thành phố. Với SEO local — kiểm tra doanh nghiệp của bạn xếp hạng ở Denver so với Dallas, hoặc người tìm kiếm ở quận Shibuya của Tokyo thấy gì — thì gl thôi là chưa đủ chính xác.

Chưa có bài viết top nào thực sự giải thích cách xây dựng mã uule — họ chỉ nhắc rằng tham số này tồn tại rồi dừng ở đó. Phần phân tích đầy đủ nằm dưới đây.

Khi nào dùng gl vs. uule vs. cr

Tham số	Mức độ chi tiết	Trường hợp sử dụng điển hình	Có cần mã hóa không?
gl=us	Cấp quốc gia	Mô phỏng nhanh theo quốc gia	Không
cr=countryUS	Cấp quốc gia (giới hạn)	Lọc theo quốc gia lưu trữ	Không
uule=w+CAIQICI...	Cấp thành phố/DMA	Kiểm tra thứ hạng SEO local	Có

Thuật toán mã hóa uule (từng bước)

Tham số uule dùng một tín hiệu vị trí được mã hóa. Cách tạo ra nó được reverse-engineer, không được Google tài liệu hóa chính thức, nhưng đã được cộng đồng SEO kiểm chứng rộng rãi.

Cách an toàn hơn là mã hóa một payload nhỏ theo Protocol Buffers thay vì dùng mẹo sao chép thường thấy (cách đó có thể lỗi với ký tự không phải ASCII). Quy trình như sau:

1. Lấy tên vị trí chuẩn của Google. Google công bố các mục tiêu địa lý với tên chuẩn thông qua dữ liệu định vị địa lý của Google Ads API. Ví dụ: New York,New York,United States
2. Mã hóa tên này thành byte UTF-8.
3. Tạo một payload protobuf nhỏ gồm tên và độ dài byte của nó.
4. Base64url-encode payload và thêm tiền tố w+.

Dưới đây là một đoạn Python thực hiện việc này:

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

#Example
print(build_uule("New York,New York,United States"))
#Output: w+CAIQICIeTmV3IFlvcmssTmV3IFlvcmssVW5pdGVkIFN0YXRlcw

Khi đưa vào URL, hãy đảm bảo dấu + trong w+ được thư viện URL của bạn mã hóa đúng thành %2B. Phần lớn triển khai URLSearchParams hoặc urllib.parse.urlencode sẽ tự xử lý việc này.

Một uule được tạo đúng chỉ là một trong các tín hiệu vị trí. Nó không ghi đè IP, cài đặt tài khoản, thiết bị hay nhóm thử nghiệm. Hãy dùng nó cho các kiểm tra định hướng SEO local, không phải như một cam kết xếp hạng chính xác cấp thành phố.

Khi các tham số URL tìm kiếm Google âm thầm xung đột

Các tổ hợp tham số có thể thất bại một cách lặng lẽ: Google có thể bỏ qua một input, viết lại URL, hoặc trả về một bề mặt khác. Những kiểm tra xung đột dưới đây rất đáng để thêm vào mọi workflow tạo link tìm kiếm.

Không có bài viết cạnh tranh nào đề cập đầy đủ đến tương tác giữa các tham số. Nhưng nếu bạn đang xây dựng URL tìm kiếm với nhiều tham số — mà gần như chắc chắn là có — thì bạn cần biết tổ hợp nào hòa hợp và tổ hợp nào xung đột.

gl + uule: Cái nào thắng?

Khi cả hai cùng xuất hiện, uule cung cấp tín hiệu vị trí cụ thể hơn gl. Nếu bạn đặt gl=uk và uule trỏ tới Tokyo, bạn sẽ nhận kết quả bị ảnh hưởng bởi Tokyo, chứ không phải kết quả UK.

Khuyến nghị: Nếu dùng uule, hãy либо bỏ hẳn gl hoặc đặt gl theo quốc gia chứa thành phố trong uule. Đừng gửi tín hiệu mâu thuẫn.

tbm + udm: Đừng dùng cả hai

Trong thử nghiệm của tôi, khi cả tbm và udm cùng xuất hiện trong một URL, Google đôi khi xóa cả hai và trả về một truy vấn web thuần túy. Hành vi này không nhất quán giữa các phiên và tài khoản.

Khuyến nghị: Chỉ dùng udm cho các triển khai mới. Nếu buộc phải hỗ trợ quy trình cũ, hãy dùng một trong hai — không bao giờ cả hai.

lr + cr: Lọc kép có thể trả về 0 kết quả

Đây là một cái bẫy tinh vi. lr=lang_en giới hạn ở nội dung tiếng Anh. cr=countryJP giới hạn ở các trang được lưu trữ tại Nhật Bản. Kết hợp lại, bạn đang yêu cầu “các trang tiếng Anh được lưu trữ tại Nhật Bản” — một tập con rất nhỏ của web.

Khuyến nghị: Chỉ dùng một trong hai trừ khi bạn thực sự cần phần giao nhau. Nếu vẫn kết hợp, hãy chuẩn bị tinh thần số lượng kết quả sẽ giảm mạnh.

num + start: Phân trang bị hỏng

Các script cũ dùng num=100&start=0 giờ chỉ âm thầm trả về khoảng 10 kết quả. Tham số num không còn được chấp nhận, nhưng nó cũng không báo lỗi — chỉ bị bỏ qua.

Khuyến nghị: Xóa num khỏi mọi URL. Phân trang bằng start với bước nhảy 10 và khử trùng lặp kết quả giữa các trang.

Bảng tham chiếu xung đột nhanh

Tổ hợp	Điều gì xảy ra	Khuyến nghị
gl + uule	uule cung cấp tín hiệu cụ thể hơn	Đồng bộ quốc gia và thành phố, hoặc bỏ gl
tbm + udm	Không đoán trước được — có thể bị xóa cả hai	Chỉ dùng udm
lr + cr	Thu hẹp mạnh, thường gần như 0 kết quả	Chỉ dùng một trong hai
num + start	num bị bỏ qua, chỉ trả về khoảng 10 kết quả	Bỏ num, phân trang bằng start
nfpr=1 + tbs=li:1	Có liên quan nhưng không giống hệt nhau	Test theo truy vấn cụ thể
hl + lr	Ngôn ngữ giao diện ≠ giới hạn ngôn ngữ nội dung	Dùng có chủ đích; hl không phải bộ lọc nội dung

Từ tham số URL tìm kiếm Google đến trích xuất dữ liệu có cấu trúc

Đến đây bạn đã có một URL tìm kiếm Google chính xác — đúng truy vấn, đúng quốc gia, đúng khoảng thời gian, và kết quả web cổ điển. Bước tiếp theo là lấy dữ liệu có cấu trúc từ các kết quả đó.

Dù bạn đang xây dựng công cụ theo dõi thứ hạng, giám sát đối thủ hay đưa dữ liệu tìm kiếm vào một workflow nghiên cứu, việc nhìn thấy đúng kết quả chỉ mới là một nửa công việc. Bạn cần tiêu đề, URL, đoạn trích, vị trí và ngày tháng trong bảng tính hoặc cơ sở dữ liệu.

Xây dựng một URL tìm kiếm Google có mục tiêu rõ ràng (kết hợp tất cả)

Ví dụ hoàn chỉnh kết hợp nhiều tham số:

https://www.google.com/search?q=site%3Acompetitor.com+intitle%3Apricing&hl=en&gl=us&tbs=qdr:m,sbd:1&udm=14&pws=0

Giải nghĩa từng phần:

• q=site%3Acompetitor.com+intitle%3Apricing — các trang trên competitor.com có chữ “pricing” trong tiêu đề
• hl=en — giao diện tiếng Anh
• gl=us — ngữ cảnh thị trường Mỹ
• tbs=qdr:m,sbd:1 — trong tháng gần nhất, sắp theo ngày
• udm=14 — kết quả web cổ điển (không AI Overviews)
• pws=0 — tắt cá nhân hóa

Bạn có thể tạo nó theo chương trình bằng 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'

Hoặc bằng 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)

Các yêu cầu HTTP ẩn danh tới Google thường trả về shell JavaScript không có kết quả render từ server, hoặc cảnh báo lưu lượng bất thường — chính ở đây, trích xuất dựa trên trình duyệt có lợi thế.

Trích xuất dữ liệu SERP mà không cần viết parser

Phân tích HTML của Google là công việc khá mong manh. Cấu trúc DOM thay đổi thường xuyên, class name bị làm rối, và những gì bạn thấy trong trình duyệt không phải lúc nào cũng giống phản hồi HTTP thô.

Một cách đơn giản hơn cho người không phải lập trình viên: mở URL tìm kiếm bạn đã xây dựng cẩn thận trong Chrome, rồi dùng công cụ trích xuất dựa trên trình duyệt để lấy dữ liệu có cấu trúc từ trang hiển thị. Tại Thunderbit, chúng tôi xây dựng Chrome extension để xử lý chính kiểu workflow này — bạn có thể dùng AI Suggest Fields để xác định các cột như tiêu đề kết quả, URL đích, đoạn mô tả và vị trí hiển thị, rồi trích xuất vào bảng tính mà không cần viết parser.

Đây không phải con đường duy nhất. Cách dùng code cũng hiệu quả, đặc biệt nếu bạn cần trích xuất quy mô lớn hoặc lặp đi lặp lại. Nhưng với nghiên cứu ngẫu hứng, audit và phân tích đối thủ một lần, trích xuất dựa trên trình duyệt giúp tránh hoàn toàn sự mong manh của việc parse HTML.

Khi nào nên dùng API chính thức thay vì vậy

Thông điệp về sử dụng có trách nhiệm — và điều này rất quan trọng.

Điều khoản dịch vụ của Google cấm truy cập tự động nhằm vượt qua các biện pháp bảo vệ, và Google Search Help nêu rõ search scraper và phần mềm gửi truy vấn tự động để xác định thứ hạng là lưu lượng tự động. Vận hành một Google scraper ở quy mô sản xuất sẽ khiến bạn đối mặt với chặn IP, CAPTCHA, và rủi ro pháp lý tiềm ẩn.

Với nhu cầu dữ liệu tìm kiếm quy mô lớn, hướng tốt hơn là API chính thức. Google Custom Search JSON API đang đóng cho khách hàng mới — người dùng hiện tại có thời hạn đến ngày 1/1/2027 để chuyển đổi, với 100 truy vấn miễn phí mỗi ngày và sau đó là $5 cho mỗi 1.000 truy vấn. Google hiện khuyến nghị Vertex AI Search cho nhu cầu tìm kiếm trong site được kiểm soát.

Với các site do bạn sở hữu, Search Console Search Analytics API là nguồn dữ liệu gốc cho lượt nhấp, impression, CTR và vị trí trung bình — không cần scraping.

Hãy xem kiến thức về tham số URL như một công cụ chẩn đoán và nghiên cứu: tuyệt vời để tạo link tìm kiếm chính xác, chạy audit thủ công và hiểu Google hiển thị gì. Không phải là giải pháp thay thế API chính thức ở quy mô lớn.

Toán tử tìm kiếm Google: Những thứ nằm bên trong truy vấn của bạn

Các toán tử tìm kiếm nằm trong tham số q=, nhưng chúng là bạn đồng hành không thể thiếu của các tham số URL. Bảng dưới đây bao gồm các toán tử Google hiện đang tài liệu hóa cùng vài toán tử vẫn hoạt động trong thực tế:

Toán tử	Tác dụng	Ví dụ
site:	Giới hạn trong một tên miền	q=site:example.com+SEO
filetype:	Giới hạn theo loại file	q=filetype:pdf+annual+report
intitle:	Từ phải xuất hiện trong tiêu đề	q=intitle:pricing+SaaS
inurl:	Từ phải xuất hiện trong URL	q=inurl:blog+marketing
-	Loại trừ một thuật ngữ	q=apple+-fruit
""	Khớp cụm từ chính xác	q=%22google+search+url+parameters%22
OR	Một trong hai thuật ngữ	q=scraping+OR+crawling
before:	Kết quả trước một ngày	q=AI+before:2026-01-01
after:	Kết quả sau một ngày	q=AI+after:2025-06-01
related:	Các site tương tự	q=related:hubspot.com

Sức mạnh thực sự đến từ việc kết hợp toán tử bên trong q với các tham số URL bên ngoài nó:

q=site:competitor.com+intitle:pricing+after:2026/01/01&tbs=sbd:1&gl=us&udm=14

Điều này tìm các trang trên competitor.com có “pricing” trong tiêu đề, được xuất bản sau tháng 1/2026, sắp theo ngày, trong thị trường Mỹ, và hiển thị kết quả web cổ điển. Đây là một truy vấn tình báo cạnh tranh rất chính xác, được tạo hoàn toàn từ tham số URL và toán tử.

Google cho biết kết quả site: không được đảm bảo đầy đủ — đừng coi truy vấn site: như một danh mục đầy đủ tất cả các trang đã được index.

Sử dụng có trách nhiệm: Điều khoản dịch vụ của Google và giới hạn tốc độ

Tóm gọn nhưng rất quan trọng.

Điều khoản dịch vụ của Google cấm truy cập lạm dụng và né tránh cơ chế bảo vệ. Google Search Help nêu rõ search scraper và phần mềm tự động hóa xếp hạng là ví dụ của lưu lượng tự động. Vi phạm các điều khoản này có thể dẫn đến chặn IP, CAPTCHA, giới hạn tài khoản và thậm chí là hành động pháp lý.

Kiến thức về tham số URL nên được dùng cho: tự xây URL tìm kiếm chính xác bằng tay, tạo link tìm kiếm có thể lưu và chia sẻ cho team, audit quy mô nhỏ trong trình duyệt, và hiểu cách giao diện tìm kiếm của Google hoạt động. Với công việc tự động ở quy mô sản xuất, hãy dùng API chính thức của Google — hoặc nhà cung cấp dữ liệu tìm kiếm bên thứ ba có cấp phép như Brave Search API.

Tại Thunderbit, browser extension của chúng tôi được xây dựng cho việc trích xuất trên trang hiển thị do người dùng khởi tạo — không phải cho việc gửi truy vấn Google tự động ở khối lượng lớn. Đây là một khác biệt rất quan trọng.

Điểm chính cần nhớ: Bộ công cụ tham số URL tìm kiếm Google 2026 của bạn

Bản tóm tắt ngắn gọn:

• Dùng gl + hl cho tín hiệu bản địa hóa và đừng chỉ dựa vào ccTLD trong giai đoạn Google chuyển hướng
• Test cả udm và tbm ở những chỗ liên quan — không tham số nào là API người dùng ổn định, có phiên bản
• udm=14 có thể yêu cầu kết quả web cổ điển không có AI Overviews, nhưng Google có thể xóa hoặc viết lại nó
• Dùng uule cho nhắm mục tiêu cấp thành phố với công thức mã hóa protobuf ở trên
• Làm chủ tbs cho lọc ngày chính xác (cdr:1,cd_min:...,cd_max:...), sắp theo ngày (sbd:1) và tìm verbatim (li:1)
• Cẩn thận với xung đột tham số: gl với uule, tbm với udm, lr với cr
• num=100 không ổn định và chưa bao giờ được hỗ trợ chính thức — dùng start theo bước 10 là lựa chọn an toàn hơn
• Để có dữ liệu SERP có cấu trúc, dùng công cụ dựa trên trình duyệt như Thunderbit cho nhu cầu ngẫu hứng, hoặc API chính thức cho quy mô sản xuất
• Tôn trọng Điều khoản dịch vụ của Google — tham số URL là công cụ nghiên cứu, không phải giấy phép scraping

Google vẫn tiếp tục thay đổi tham số mà không thông báo. Tôi sẽ cập nhật tài liệu tham chiếu này khi mọi thứ thay đổi — hãy bookmark lại và quay lại xem.

Tìm hiểu thêm

• 9 API SEO tốt nhất cho năm 2026 (kèm dữ liệu chi phí thực trên mỗi request)
• Cách làm chủ search engine scraping: Hướng dẫn toàn diện
• Top 27 công cụ để phân tích và theo dõi thứ hạng website
• Cách dùng phân trang trong Web Scraper để trích xuất hiệu quả
• Tự động hóa tìm kiếm là gì? Lợi ích, công cụ và chiến lược

Câu hỏi thường gặp

udm=14 làm gì trong một URL tìm kiếm Google?

udm=14 có thể yêu cầu bề mặt kết quả web cổ điển mà không có AI Overviews, vì vậy nó rất được giới SEO ưa chuộng. Đây là thứ được reverse-engineer, không phải một cam kết chính thức được Google tài liệu hóa, và Google có thể xóa hoặc viết lại nó tùy theo phiên, tài khoản, khu vực, client và nhóm thử nghiệm.

Tham số num còn hoạt động trong năm 2026 không?

Đừng phụ thuộc vào nó. Google đã ngừng chấp nhận ổn định num=100 từ tháng 9/2025, và một phát ngôn viên nói tham số này chưa bao giờ được hỗ trợ chính thức. Hãy dùng start theo bước 10 như mặc định phân trang an toàn hơn, và kiểm tra số lượng kết quả trả về vì Google vẫn có thể viết lại hoặc giới hạn phản hồi.

Làm sao mô phỏng tìm kiếm Google từ một thành phố cụ thể?

Dùng tham số uule với tên thành phố đã được mã hóa. Phần mã hóa ở trên cung cấp thuật toán dựa trên protobuf và một ví dụ Python. Bạn sẽ cần tên địa điểm chuẩn của Google (có trong dữ liệu nhắm mục tiêu địa lý của Google Ads), rồi mã hóa nó thành giá trị uule như uule=w+CAIQICIeNew+York,New+York,United+States.

Khác nhau giữa gl, lr và cr là gì?

Ba tham số này điều khiển các khía cạnh khác nhau của nhắm mục tiêu theo địa lý và ngôn ngữ. gl mô phỏng vị trí tìm kiếm ở cấp quốc gia (ảnh hưởng đến thứ hạng và kết quả địa phương). lr giới hạn kết quả ở các trang được viết bằng một ngôn ngữ nội dung cụ thể. cr giới hạn kết quả ở các trang được lưu trữ tại một quốc gia cụ thể. Chúng có thể kết hợp, nhưng các tổ hợp mâu thuẫn (như lr=lang_en + cr=countryJP) sẽ làm kết quả bị thu hẹp đáng kể.

Tôi có thể kết hợp nhiều giá trị tbs trong một URL không?

Có — hãy phân tách chúng bằng dấu phẩy trong cùng một tham số tbs. Ví dụ, tbs=qdr:m,sbd:1 lọc trong tháng gần nhất và sắp theo ngày (mới nhất trước). Bạn cũng có thể thêm li:1 để bật verbatim mode: tbs=qdr:m,sbd:1,li:1. Cú pháp tbs không được tài liệu hóa, vì vậy hãy test các tổ hợp cụ thể để chắc rằng chúng hoạt động như mong đợi.