พารามิเตอร์ URL ของ Google Search: อะไรยังใช้ได้อยู่ในปี 2026

ช่วงราวเดือนกันยายน 2025 เครื่องมือ SEO และสคริปต์ที่เขียนขึ้นเองจำนวนไม่น้อยเริ่มใช้งานไม่ได้แบบเงียบ ๆ สาเหตุคืออะไร? Google หยุดรองรับพารามิเตอร์ num=100 อย่างสม่ำเสมอ ทำให้พวกสายใช้งานขั้นสูงที่เคยพึ่งพามันเพื่อดึงผลลัพธ์ 100 รายการต่อหน้าใช้ไม่ได้เหมือนเดิม หลายคนไม่เห็นประกาศเลิกใช้แบบเป็นทางการ มีเพียง โฆษกที่บอกกับ Search Engine Land ว่าพารามิเตอร์นี้ “ไม่เคยได้รับการรองรับอย่างเป็นทางการ” ในช่วงเวลาใกล้เคียงกัน Google ยังเปิดตัวโหมด udm เพิ่มเติมควบคู่กับ vertical แบบ tbm เดิม ประกาศว่าดอเมนเนมแบบรหัสประเทศจะค่อย ๆ redirect ไปที่ google.com และรายงานว่า AI Overviews เข้าถึงผู้ใช้รายเดือน มากกว่า 2.5 พันล้านคน

ถ้าคุณกำลังสร้าง URL สำหรับค้นหา ติดตามอันดับ หรือทำรีเสิร์ชอัตโนมัติด้วยพารามิเตอร์ของ Google อยู่ มีโอกาสสูงว่างานบางส่วนของคุณกำลังเสื่อมสภาพแบบไม่รู้ตัว ใน Thunderbit เราจึงตรวจสอบเอกสารล่าสุดของ Google, ประกาศการเปลี่ยนแปลงช่วงหลัง, แหล่งข้อมูลที่ reverse engineer มา และการทดสอบจริงแบบ spot check เพื่อแยกว่าตัวควบคุมไหนยังเสถียร ตัวไหนเป็นแค่ตามบริบท ผลลัพธ์คือคู่มืออ้างอิงแบบมีวันที่กำกับและควรทดสอบก่อนนำไปใช้จริง สำหรับพารามิเตอร์ URL ของ Google Search ที่สำคัญในปี 2026 รวมถึงการจับคู่ tbm/udm, สูตรการเข้ารหัส uule สำหรับ targeting ระดับเมือง และความขัดแย้งของพารามิเตอร์ที่ช่วยคุณประหยัดเวลาการแก้บั๊กได้หลายชั่วโมง

พารามิเตอร์ URL ของ Google Search คืออะไร?

พารามิเตอร์ URL ของ Google Search คือคู่ key=value ที่อยู่หลังเครื่องหมาย ? ใน URL ของการค้นหา Google พารามิเตอร์เหล่านี้ควบคุมแทบทุกอย่าง ตั้งแต่สิ่งที่คุณค้นหา ไปจนถึงประเทศของผลลัพธ์ที่เห็น รวมถึงว่าคุณจะได้รูปภาพ ข่าว หรือผลลัพธ์ลิงก์สีน้ำเงินแบบคลาสสิก

ตัวอย่าง URL การค้นหา Google ทั่วไปจะมีโครงสร้างประมาณนี้:

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

• Base URL: https://www.google.com/search
• ? เริ่มต้น query string
• q=best+crm+software คือคำค้นหา (เว้นวรรคเข้ารหัสเป็น +)
• & ใช้คั่นแต่ละพารามิเตอร์
• hl=en กำหนดภาษาอินเทอร์เฟซเป็นอังกฤษ
• gl=us บอก Google ให้แสดงผลเสมือนว่าคุณอยู่ในสหรัฐฯ
• tbs=qdr:m กรองผลลัพธ์ให้เหลือเฉพาะช่วงเดือนที่ผ่านมา

สิ่งหนึ่งที่ควรแยกให้ออกคือ search operators อย่าง site:, filetype: และ intitle: จะอยู่ ข้างใน ค่า q= พวกนี้เป็นส่วนหนึ่งของคำค้นหา ในขณะที่ URL parameters เช่น gl, hl และ tbs เป็นคีย์แยกต่างหากใน URL ที่ควบคุมวิธีที่ Google ประมวลผลและแสดงผลลัพธ์ ทั้งสองอย่างสำคัญและทำงานร่วมกัน แต่เป็นคนละหน้าที่กัน

Google ไม่เคยเผยสเปกฉบับเดียวที่เป็นทางการและมีเวอร์ชันกำกับสำหรับพารามิเตอร์เหล่านี้ บางส่วนมาจาก ฟอร์ม Advanced Search บางส่วนมาจาก Custom Search API และบางส่วนมาจากการ reverse engineer จากการสังเกต URL ของ Google เอง นั่นหมายความว่าบทความที่คุณกำลังอ่านอิงจากการทดสอบจริงและพฤติกรรมที่พบได้จริง ไม่ใช่สัญญา API แบบเป็นทางการ

ทำไมพารามิเตอร์ URL ของ Google Search ถึงสำคัญในปี 2026

พารามิเตอร์ URL ไม่ได้เป็นเรื่องของนักพัฒนาเท่านั้น ใครก็ตามในสาย SEO, การตลาด, ฝ่ายขาย, operations หรือ product ที่ต้องเข้าใจว่า Google แสดงผลอะไรสำหรับคำค้นใดคำค้นหนึ่ง ในตลาดใดตลาดหนึ่ง และในช่วงเวลาใดช่วงเวลาหนึ่ง — พารามิเตอร์เหล่านี้คือเครื่องมือของคุณ

สรุปสั้น ๆ ว่าใครได้ประโยชน์และอย่างไร:

Use Case	ใครได้ประโยชน์	พารามิเตอร์สำคัญ
ติดตามอันดับ SEO ข้ามประเทศ	ทีม SEO & Marketing	gl, hl, uule, pws
เฝ้าดูคู่แข่งตามช่วงเวลา	ทีม Strategy & Ops	tbs, q ร่วมกับ site:
ติดตามโฆษณาในตลาดเฉพาะ	ทีม Paid Media	gl, hl, udm
ตรวจสอบ Local SEO ระดับเมือง	เจ้าของธุรกิจท้องถิ่น	uule, gl
รีเสิร์ชคอนเทนต์ / ติดตามเทรนด์	ทีม Content	tbs (กรองตามวันที่), lr
ส่งข้อมูลการค้นหาเข้าแอป AI/LLM	ทีม Product & Data	หลายพารามิเตอร์ + การดึงข้อมูลแบบมีโครงสร้าง

การเปลี่ยนแปลงใหญ่ 3 เรื่องทำให้ปี 2026 ต่างออกไปอย่างเห็นได้ชัด:

1. num=100 ไม่น่าเชื่อถืออีกต่อไป เทคนิคดึงผลลัพธ์ 100 รายการต่อหน้าแบบเดิม เริ่มใช้ไม่ได้อย่างสม่ำเสมอตั้งแต่กันยายน 2025 Google ไม่ได้ประกาศเลิกใช้แบบเป็นทางการ แต่โฆษกกล่าวว่ามันไม่เคยได้รับการรองรับอย่างเป็นทางการ
2. การ redirect ของ ccTLD คือกระบวนการย้าย ไม่ใช่การสวิตช์จบแล้ว Google ประกาศในเดือนเมษายน 2025 ว่าโดเมนรหัสประเทศอย่าง google.co.uk, google.de เป็นต้น จะค่อย ๆ redirect ไป google.com Google ยังไม่ประกาศว่าเสร็จสมบูรณ์ ดังนั้นอย่าคิดว่าแต่ละ locale จะทำงานเหมือนกันหมดแล้ว
3. AI Overviews เปลี่ยนหน้าผลการค้นหาไปแล้ว Google รายงานว่า AI Overviews มีผู้ใช้รายเดือน มากกว่า 2.5 พันล้านคน และครอบคลุม มากกว่า 200 ประเทศและดินแดน. โหมด udm ที่ reverse engineer มาอาจเปลี่ยนหน้าผลลัพธ์ในบางบริบท แต่ไม่ได้หมายความว่าจะเป็นสวิตช์เปิด AI Overview ได้เสมอไป

ถ้ากระบวนการของคุณยังไม่อัปเดตตามการเปลี่ยนแปลงเหล่านี้ คุณอาจกำลังได้ผลลัพธ์ที่ด้อยคุณภาพหรือทำให้เข้าใจผิดโดยไม่รู้ตัว

Cheat Sheet พารามิเตอร์ URL ของ Google Search (2026)

ก่อนลงลึก ตารางอ้างอิงด้านล่างคือรายการที่อัปเดตที่สุดเท่าที่ฉันรวบรวมได้ในตอนนี้ บันทึกไว้เลย

พารามิเตอร์	ทำอะไร	ค่าตัวอย่าง	สถานะ
q	คำค้นหา (รองรับ operators ภายใน)	q=best+crm+software	✅ ยังใช้งานอยู่
hl	ภาษาอินเทอร์เฟซ	hl=en, hl=ja	✅ ยังใช้งานอยู่
gl	บริบทประเทศ/ตลาด	gl=us, gl=jp	✅ ยังใช้งานอยู่
lr	จำกัดผลลัพธ์ตามภาษาของเนื้อหา	lr=lang_en	✅ ยังใช้งานอยู่
cr	จำกัดผลลัพธ์ตามประเทศที่โฮสต์	cr=countryUS	✅ ยังใช้งานอยู่
start	เลื่อนหน้าผลลัพธ์	start=10 (หน้า 2)	✅ ยังใช้งานอยู่
num	จำนวนผลลัพธ์ต่อหน้า (เดิม)	num=100	⚠️ ไม่ได้รองรับอย่างเป็นทางการ; ไม่น่าเชื่อถือตั้งแต่ ก.ย. 2025
udm	โหมดเนื้อหาแบบ contextual	udm=14 (เว็บแบบคลาสสิก)	⚠️ reverse-engineered; แตกต่างตามบริบท
tbm	vertical ของการค้นหา	tbm=isch (รูปภาพ)	⚠️ ยังพบได้; ต้องทดสอบคู่กับ udm
tbs	ฟิลเตอร์เวลา, การเรียงลำดับ, verbatim	tbs=qdr:w	✅ ยังใช้งานอยู่
safe	ควบคุม SafeSearch	safe=active	✅ ยังใช้งานอยู่
filter	กรองผลลัพธ์ที่ซ้ำ	filter=0	✅ ยังใช้งานอยู่ (ตามที่พบ)
nfpr	ปิดการแก้คำอัตโนมัติ	nfpr=1	✅ ยังใช้งานอยู่ (ตามที่พบ)
pws	ปิดการปรับผลลัพธ์ตามบัญชี	pws=0	✅ ยังใช้งานอยู่
uule	geo-targeting ระดับเมือง/DMA	uule=w+CAIQICI...	✅ ยังใช้งานอยู่ (reverse-engineered)
as_q, as_epq, as_eq, ฯลฯ	ฟิลด์จากฟอร์ม Advanced Search	หลากหลาย	✅ ยังใช้งานอยู่
as_sitesearch	จำกัดที่โดเมนเดียว (Advanced Search)	as_sitesearch=example.com	✅ ยังใช้งานอยู่
as_filetype	จำกัดตามชนิดไฟล์ (Advanced Search)	as_filetype=pdf	✅ ยังใช้งานอยู่
ie, oe	encoding ขาเข้า/ขาออก	ie=UTF-8	✅ ยังใช้งานอยู่ (แทบไม่จำเป็นแล้ว)
kgmid, si, ibp	entity / feature view ของ Knowledge Graph	หลากหลาย	⚠️ ตามบริบท (ไม่เหมาะใช้ทั่วไป)
ei, ved, sxsrf, sclient	session / tracking / telemetry	หลากหลาย	🔒 ภายใน (ไม่ต้องสนใจ)
gbv	basic HTML view (เดิม)	gbv=1	❌ ไม่น่าเชื่อถือในปี 2026

ตัด ei, ved, sxsrf และ sclient ออกจากทุก URL ที่คุณบันทึกหรือแชร์ พวกนี้คือสถานะ session และ telemetry ที่ Google แนบมาให้อัตโนมัติ — ไม่เกี่ยวกับการสร้าง search URL

พารามิเตอร์ Google Search หลักที่ยังใช้ได้

ฉันทดสอบรายการด้านล่างแบบสด ณ กลางปี 2026 และเป็นตัวที่คุณจะหยิบใช้บ่อยที่สุด

q — คำค้นหาของคุณ

พารามิเตอร์ q คือที่เก็บคำค้นหา เว้นวรรคจะถูกเข้ารหัสเป็น + หรือ %20 ตรงนี้คือที่อยู่ของ search operators ที่ Google อธิบายไว้ — พวกมันต้องอยู่ ภายใน ค่า q ไม่ใช่เป็นพารามิเตอร์แยก

ตัวอย่าง:

• วลีตรงตัว: q=%22google+search+url+parameters%22
• จำกัดเฉพาะเว็บไซต์: q=site%3Aexample.com+pricing
• ชนิดไฟล์: q=filetype%3Apdf+annual+report+2026
• ผสมกัน: q=site%3Acompetitor.com+intitle%3Apricing+after%3A2026%2F01%2F01

ควร URL-encode ค่าของ query ทั้งหมดเสมอ เครื่องหมายคำพูด เครื่องหมาย colon และ slash ต้องเข้ารหัสให้ถูกต้อง ไม่อย่างนั้น URL อาจเสียได้

hl — ภาษาอินเทอร์เฟซ

hl ควบคุมภาษาของหน้าอินเทอร์เฟซ Google เช่น ปุ่ม ฉลาก และหัวข้อ “People also ask” และมีผลต่อผลลัพธ์ที่ Google ให้ความสำคัญ ใช้รหัส ISO 639-1 เช่น en, fr, de, ja หรือ BCP 47 tags เช่น en-gb, pt-br

hl ไม่ได้บังคับให้เอกสารผลลัพธ์ทั้งหมดเป็นภาษานั้น มันเป็นสัญญาณที่แรง แต่ Google ยังอาจแสดงผลลัพธ์ภาษาอื่นถ้ามีความเกี่ยวข้องมากกว่า ถ้าต้องการจำกัดตามภาษาเนื้อหา ให้ใช้ lr แทน

gl — ประเทศ / ตำแหน่งทางภูมิศาสตร์

gl จำลองประเทศที่คุณกำลังค้นหาจาก โดยใช้รหัสประเทศ ISO 3166-1 alpha-2 (us, gb, jp, de) เมื่อ ccTLD ค่อย ๆ redirect ไป google.com gl จึงกลายเป็นวิธีหลักในการดึงผลลัพธ์เฉพาะประเทศ

คำค้นหาเดียวกันเมื่อเปลี่ยนค่า gl อาจให้ผลลัพธ์ Featured Snippet และ Local Pack ต่างกันมาก เช่น q=best+bank&gl=us กับ q=best+bank&gl=jp จะเห็นธนาคารคนละชุดกันชัดเจน

เคล็ดลับ: ควรจับคู่ gl กับ hl เสมอเพื่อให้ได้ผลลัพธ์ที่ localize ถูกต้อง gl=jp กับ hl=en จะได้ผลลัพธ์ในตลาดญี่ปุ่นแต่แสดงเป็นอินเทอร์เฟซอังกฤษ — มีประโยชน์มากสำหรับการตรวจ SEO ระหว่างประเทศ

lr และ cr — จำกัดตามภาษาและประเทศ

สองตัวนี้มักถูกสับสนกันอยู่บ่อย ๆ แต่ความต่างสำคัญมาก:

• lr=lang_en จำกัดผลลัพธ์ให้เป็นหน้าเว็บที่เขียนเป็นภาษาอังกฤษ (ภาษาของเนื้อหา)
• cr=countryUS จำกัดผลลัพธ์ให้เป็นหน้าที่โฮสต์อยู่ในสหรัฐฯ (ตำแหน่งเซิร์ฟเวอร์ / การเชื่อมโยงประเทศ)
• gl=us จำลองว่าคุณค้นหาจาก ภายใน สหรัฐฯ (มีผลต่อ ranking, local results, ads)

ทั้ง lr และ cr ใช้ได้จาก ฟอร์ม Advanced Search ของ Google ระวังเวลาเอามาผสมกัน — lr=lang_en + cr=countryJP หมายถึง “เฉพาะหน้าอังกฤษที่โฮสต์ในญี่ปุ่น” ซึ่งเป็นชุดผลลัพธ์ที่แคบมาก เดี๋ยวส่วน conflicts จะอธิบายเพิ่ม

start — การแบ่งหน้า

start=10 หมายถึงขอผลลัพธ์ตั้งแต่ตำแหน่งที่ 11 เป็นต้นไป (หน้า 2) start=20 คือหน้า 3 และต่อไปเรื่อย ๆ เพราะ num=100 ไม่น่าเชื่อถือแล้ว การเพิ่ม start ทีละ 10 จึงเป็นค่าเริ่มต้นที่ปลอดภัยกว่า — แต่ Google ก็ยังอาจ rewrite หรือจำกัด pagination ได้

เทคนิคเก่า num=100&start=0 เพื่อดึง 100 ผลลัพธ์ต่อหน้า ใช้ไม่ได้แล้ว ถ้าสคริปต์ของคุณยังใส่ num อยู่ ให้ลบออก มันถูกเมินแบบเงียบ ๆ

pws — ปิดการปรับผลลัพธ์ตามผู้ใช้

pws=0 คือการขอให้ Google ปิด personalization ที่อิงกับบัญชี ซึ่งสำคัญมากสำหรับการติดตามอันดับ SEO เพราะคุณต้องการผลลัพธ์ที่ไม่เพี้ยนจากประวัติการค้นหา การคลิก หรือค่าตั้งในบัญชีของคุณเอง

ข้อควรระวัง: pws=0 ลด personalization ได้ แต่ไม่ได้ลบปัจจัยเชิงบริบททั้งหมด Google ระบุว่า ผลลัพธ์ยังอาจเปลี่ยนตามเวลา ตำแหน่ง ภาษา และอุปกรณ์ จึงไม่มีสิ่งที่เรียกว่า Google SERP แบบ “กลางจริง ๆ”

safe และ filter — SafeSearch และการกรองผลซ้ำ

• safe=active เปิด SafeSearch; safe=off ปิด SafeSearch อย่างไรก็ตาม การตั้งค่าบัญชี นโยบายผู้ดูแลระบบ การตั้งค่าเครือข่าย หรือกฎหมายในบางภูมิภาคอาจ override ค่านี้ได้
• filter=0 ปิดการกรองผลลัพธ์ซ้ำของ Google เหมาะเวลาคุณอยากเห็นทุกผลลัพธ์ที่ Google มี รวมถึงหน้าใกล้เคียงกันที่ปกติมันจะรวมเข้าด้วยกัน

nfpr — ปิดการแก้คำอัตโนมัติ

nfpr=1 ทำให้ Google ไม่บังคับ rewrite คำค้นหาเมื่อมันคิดว่าคุณสะกดผิด เหมาะกับการติดตามคำแบรนด์ที่สะกดแปลก คำเทคนิค หรือคำที่ตั้งใจสะกดผิดซึ่งคู่แข่งกำลังใช้

สังเกตว่า nfpr=1 แค่ยับยั้งการ rewrite แบบบังคับเท่านั้น ถ้าอยากควบคุมกว้างกว่านั้น — เช่น ปิดการขยายคำพ้อง การเปลี่ยนการสะกด และการปรับอัตโนมัติอื่น ๆ — ให้ใช้ tbs=li:1 (verbatim mode) ซึ่งจะพูดถึงในส่วน tbs ด้านล่าง

การย้ายจาก tbm ไป udm: อะไรเปลี่ยน และตอนนี้ควรใช้แบบไหน

นี่คือหนึ่งในการเปลี่ยนแปลงพารามิเตอร์ที่ใหญ่ที่สุดในช่วงไม่กี่ปีที่ผ่านมา และก็เป็นหนึ่งในสิ่งที่คนตีความเกินจริงได้ง่ายที่สุด

tbm เคยเป็นวิธีหลักในการสลับ vertical ของการค้นหาของ Google มานานกว่าทศวรรษ เช่น รูปภาพ ข่าว วิดีโอ ช็อปปิ้ง ขณะเดียวกัน Google ก็เริ่มมีระบบตัวเลข udm ที่มีโหมดซ้อนทับและโหมดเพิ่มเติมหลายแบบ เพราะ Google ไม่ได้เผย registry สำหรับผู้ใช้ทั่วไปอย่างเป็นทางการ จึงควรมองสิ่งนี้เป็นการจับคู่ตามบริบท ไม่ใช่การแทนที่ที่สมบูรณ์แบบและสิ้นสุดแล้ว

ตารางจับคู่ tbm-to-udm แบบครบถ้วน

การจับคู่ด้านล่างผสมระหว่างพฤติกรรม UI ที่สังเกตได้และการ spot check สด ณ วันที่ 12 สิงหาคม 2026 ค่าหลายตัวถูกตัดออกหรือเขียนใหม่ในการร้องขอแบบไม่ระบุตัวตน ดังนั้นทุกรายการควรทดสอบในบัญชี ภูมิภาค และไคลเอนต์ที่จะใช้งานจริง:

พารามิเตอร์เดิม	ค่าเดิม	พารามิเตอร์ใหม่	ค่าใหม่	สถานะ
tbm=lcl	Places/Local	udm=1	Places/Local	⚠️ ตามบริบท
tbm=isch	รูปภาพ	udm=2	รูปภาพ	⚠️ ตามบริบท
tbm=vid	วิดีโอ	udm=7	วิดีโอ	⚠️ ตามบริบท
tbm=nws	ข่าว	udm=12	ข่าว	⚠️ ตามบริบท
—	—	udm=14	เว็บแบบคลาสสิก (ไม่มี AI Overview)	🆕 ใหม่, ไม่มีคู่เทียบ tbm
—	—	udm=18	ฟอรัม	🆕 ใหม่, ไม่มีคู่เทียบ tbm
tbm=shop	ช็อปปิ้ง	udm=28	ช็อปปิ้ง	⚠️ ตามบริบท
tbm=bks	หนังสือ	udm=36	หนังสือ	⚠️ ตามบริบท
—	—	udm=39	วิดีโอสั้น	🆕 ใหม่, ไม่มีคู่เทียบ tbm
—	—	udm=50	โหมด AI Overview	🆕 ใหม่, ไม่มีคู่เทียบ tbm

Google ไม่ได้เผย registry ที่เสถียรสำหรับ udm — นี่คือข้อควรระวังสำคัญ ค่าพวกนี้ ได้มาจากการ reverse engineer จากการสังเกตพฤติกรรม UI ของ Google เอง การยอมรับ URL แตกต่างกันไปตามบัญชี ภูมิภาค ไคลเอนต์ คุกกี้ และกลุ่มทดลอง ในการทดสอบของฉัน ค่าบางตัวถูกตัดออกในการร้องขอ HTTP แบบ anonymous แต่กลับใช้งานได้ใน session เบราว์เซอร์แบบโต้ตอบ อย่าคิดว่าทุกค่าจะใช้ได้เหมือนกันทุกสถานการณ์

udm=14 ทำอะไร และทำไมสาย SEO ถึงชอบ

udm=14 กลายเป็นเหมือนตัวโปรดของชุมชน SEO Android Central อธิบายไว้ ว่าเป็นวิธีขอหน้าผลลัพธ์เว็บแบบคลาสสิกโดยไม่มี AI Overviews ในหลาย session มันให้ SERP แบบลิงก์สีน้ำเงินดั้งเดิม แต่ก็ไม่ใช่การรับประกันอย่างเป็นทางการหรือใช้ได้เสมอทุกครั้ง

ทำไมเรื่องนี้สำคัญ? ถ้าคุณกำลังติดตามอันดับหรือทำ SEO audit AI Overviews อาจดันผลลัพธ์ออร์แกนิกลงไปต่ำกว่า fold ทำให้ประเมินอันดับจริงได้ยากขึ้น udm=14 จะช่วยให้เห็นภาพที่สะอาดกว่าเมื่อ Google ยอมรับมัน

อย่างไรก็ตาม udm=14 ไม่ได้การันตีว่าใช้ได้ทุกบริบท ใน spot check วันที่ 12 สิงหาคม 2026 Google บางครั้งตัดค่าหรือ rewrite ค่า udm ขึ้นกับบริบทของ request ผลลัพธ์ที่คุณได้จะขึ้นกับ session, account, region, client และ experiment cohort

มีการสังเกต udm=50 ในบริบทของ AI Mode / AI-result แต่ไม่ควรอธิบายว่ามันเป็นวิธีบังคับให้คำค้นหาทั่วไปแสดง AI Overview ได้อย่างแน่นอน

ควรทำอย่างไร: อัปเดตเวิร์กโฟลว์จาก tbm ไป udm

คำแนะนำของฉัน:

• การทำงานใหม่: มอง udm เป็น input แบบทดลอง/ตามบริบท และต้องมี fallback เสมอ
• เวิร์กโฟลว์ที่มีอยู่: รองรับและทดสอบทั้ง tbm และ udm ในกรณีที่เกี่ยวข้อง แทนที่จะคิดว่าการย้ายเสร็จสมบูรณ์แล้ว
• อย่าใช้ทั้งคู่พร้อมกัน: เมื่อ tbm และ udm อยู่ใน URL เดียวกัน พฤติกรรมจะคาดเดาไม่ได้ ในการทดสอบของฉัน Google บางครั้งตัดทั้งสองตัวออกแล้วคืนค่าคำค้นหาธรรมดา ส่วน conflicts จะอธิบายเพิ่มด้านล่าง

ไวยากรณ์ tbs แบบเต็ม: กำหนดช่วงเวลาเอง, เรียงตามวันที่, และ verbatim

tbs เป็นหนึ่งในพารามิเตอร์ที่ทรงพลังที่สุดในชุดเครื่องมือ Google search URL แต่คู่มือส่วนใหญ่แทบพูดถึงแค่ผิวเผิน มันรองรับการกรองตามเวลา การเรียงตามวันที่ verbatim mode และอื่น ๆ ทั้งหมดอัดอยู่ในค่าเดียวที่คั่นด้วย comma

ฟิลเตอร์เวลามาตรฐาน

ค่า tbs	ความหมาย	ตัวอย่าง fragment ของ URL
qdr:h	ภายใน 1 ชั่วโมงที่ผ่านมา	&tbs=qdr:h
qdr:d	ภายใน 24 ชั่วโมงที่ผ่านมา	&tbs=qdr:d
qdr:w	ภายใน 1 สัปดาห์ที่ผ่านมา	&tbs=qdr:w
qdr:m	ภายใน 1 เดือนที่ผ่านมา	&tbs=qdr:m
qdr:y	ภายใน 1 ปีที่ผ่านมา	&tbs=qdr:y

นี่คือพื้นฐานที่คู่มือส่วนใหญ่พูดถึง แต่ tbs ทำได้มากกว่านั้น

ช่วงวันที่แบบกำหนดเอง

ต้องการผลลัพธ์จากช่วงเวลาที่เฉพาะเจาะจงใช่ไหม? ใช้ไวยากรณ์ 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

วิธีนี้จะกรองผลลัพธ์ให้เหลือเฉพาะหน้าที่ Google เชื่อมโยงกับวันที่ระหว่าง 1 มกราคม ถึง 1 มิถุนายน 2026 มีประโยชน์มากสำหรับการรีเสิร์ชคู่แข่ง เช่น “คู่แข่งเผยแพร่เรื่องราคาอะไรบ้างในไตรมาส 1 ปี 2026?” อย่าลืม URL-encode ค่าเต็ม เพราะ colon และ slash ต้องเข้ารหัสให้ถูกต้อง

ข้อสังเกตเชิงปฏิบัติ: การจับคู่วันที่ของ Google ไม่ได้แม่นเสมอไป วันที่ที่เห็นในผลการค้นหาเป็นแค่การคาดเดาที่ดีที่สุดของ Google ไม่จำเป็นต้องเป็นวันที่เผยแพร่จริงเสมอไป ควรตรวจสอบวันที่บนหน้าเป้าหมายทุกครั้ง

เรียงตามวันที่และ Verbatim Mode

ตรงนี้คือส่วนที่คู่มือนี้ลงลึกกว่าเนื้อหาคู่แข่งเกือบทั้งหมด

sbd:1 ใช้เรียงผลลัพธ์ตามวันที่ (ใหม่สุดก่อน) เองอย่างเดียวก็มีประโยชน์ แต่สิ่งที่ดีคือคุณสามารถ รวมมันกับฟิลเตอร์ช่วงเวลา ในค่า tbs เดียวกันได้:

&tbs=qdr:m,sbd:1

แบบนี้จะได้ผลลัพธ์ในเดือนที่ผ่านมา เรียงตามวันที่จากใหม่สุดก่อน เป็นวิธีที่เร็วที่สุดในการหาของที่เพิ่งเผยแพร่ในหัวข้อใดหัวข้อหนึ่ง ฉันใช้การจับคู่นี้ตลอดเวลาตอนเฝ้าดูคอนเทนต์ของคู่แข่ง

li:1 เปิด verbatim mode — เทียบได้กับการกดเครื่องมือ “Verbatim” ของ Google ในหน้า search interface โหมดนี้จะปิด auto-correction, การขยายคำพ้อง, การเปลี่ยนการสะกด และการปรับคำค้นหาอัตโนมัติอื่น ๆ

ความต่างระหว่าง li:1 กับ nfpr=1 อยู่ที่ขอบเขต:

• nfpr=1: ยับยั้งเฉพาะการบังคับ rewrite คำสะกด/คำค้นหา เช่น หยุด Google จากการเปลี่ยน “teh” เป็น “the”
• tbs=li:1: ปิดการปรับอัตโนมัติทั้งหมด — การสะกด คำพ้อง คำที่เกี่ยวข้อง และการปรับตาม personalization

คุณยังสามารถซ้อนค่า tbs หลายตัวได้ เช่น tbs=qdr:m,sbd:1,li:1 จะให้ผลลัพธ์ในเดือนที่ผ่านมา เรียงตามวันที่ และจับคู่แบบ verbatim ในการทดสอบของฉัน ชุดนี้ใช้ได้ แต่แนะนำให้ตรวจสอบกับคำค้นหาเฉพาะของคุณ เพราะ tbs เป็นไวยากรณ์ที่ไม่ได้มีเอกสารทางการรองรับ

วิธีสร้าง uule code สำหรับ geo-targeting ระดับเมือง

ถ้า gl คือเลนส์ซูมระดับประเทศ uule ก็คือกล้องจุลทรรศน์ระดับเมือง สำหรับ local SEO — เช่น เช็กว่าธุรกิจของคุณติดอันดับใน Denver เทียบกับ Dallas อย่างไร หรือคนค้นหาในย่าน Shibuya ของโตเกียวเห็นอะไร — gl อย่างเดียวไม่ละเอียดพอ

บทความอันดับต้น ๆ แทบไม่มีใครอธิบายวิธี สร้าง uule code จริง ๆ พวกเขาแค่บอกว่ามีพารามิเตอร์นี้แล้วก็จบ ส่วนที่เหลือมีดังนี้

เมื่อไรควรใช้ gl เทียบกับ uule และ cr

พารามิเตอร์	ความละเอียด	กรณีใช้งานทั่วไป	ต้องเข้ารหัสไหม?
gl=us	ระดับประเทศ	จำลองประเทศแบบเร็ว ๆ	ไม่ต้อง
cr=countryUS	ระดับประเทศ (แบบจำกัด)	กรองตามประเทศที่โฮสต์	ไม่ต้อง
uule=w+CAIQICI...	ระดับเมือง/DMA	ตรวจอันดับ Local SEO	ต้อง

อัลกอริทึมการเข้ารหัส uule (ทีละขั้น)

พารามิเตอร์ uule ใช้สัญญาณชื่อสถานที่ที่ถูกเข้ารหัส การสร้างค่าถูก reverse-engineered ไม่ได้มีเอกสารทางการจาก Google แต่ชุมชน SEO ตรวจสอบและใช้งานกันอย่างแพร่หลาย

วิธีที่ปลอดภัยกว่าคือเข้ารหัส payload แบบ Protocol Buffers ขนาดเล็ก แทนที่จะใช้สูตรลัดที่คัดลอกกันมาบ่อย ๆ (ซึ่งอาจพังกับอักขระนอก ASCII) ขั้นตอนมีดังนี้:

1. เอาชื่อสถานที่แบบ canonical ของ Google Google เผยเป้าหมายทางภูมิศาสตร์พร้อมชื่อ canonical ผ่าน Google Ads API geographic targeting data ตัวอย่าง: New York,New York,United States
2. เข้ารหัสชื่อเป็น UTF-8 bytes
3. สร้าง protobuf payload ขนาดเล็ก ที่มีชื่อและความยาวของ byte
4. Base64url-encode payload แล้วเติม w+ นำหน้า

นี่คือตัวอย่าง Python ที่ทำได้:

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

เวลานำไปใส่ใน URL ต้องแน่ใจว่า + ที่อยู่ใน w+ ถูกเข้ารหัสเป็น %2B โดยไลบรารี URL ของคุณ ส่วนใหญ่ URLSearchParams หรือ urllib.parse.urlencode จัดการให้อัตโนมัติ

uule ที่สร้างถูกต้องก็ยังเป็นเพียงสัญญาณตำแหน่งหนึ่งเท่านั้น มันไม่ได้ override IP address การตั้งค่าบัญชี อุปกรณ์ หรือ experiment cohort ใช้มันเพื่อเช็ก local SEO แบบบอกแนวโน้ม ไม่ใช่การรับประกันอันดับแบบเจาะจงระดับเมือง

เมื่อพารามิเตอร์ Google Search ขัดแย้งกันแบบเงียบ ๆ

การผสมพารามิเตอร์อาจล้มเหลวแบบเงียบ ๆ: Google อาจเมินค่า input ตัวหนึ่ง rewrite URL หรือส่งผลลัพธ์คนละ surface กัน การตรวจความขัดแย้งด้านล่างคุ้มค่าที่จะใส่ในทุก workflow ที่สร้างลิงก์ค้นหา

แทบไม่มีบทความคู่แข่งไหนพูดถึงการทำงานร่วมกันของพารามิเตอร์เลย แต่ถ้าคุณกำลังสร้าง URL ที่มีหลายพารามิเตอร์ — และคุณน่าจะกำลังทำอยู่ — คุณต้องรู้ว่าคู่ไหนใช้ร่วมกันได้ดี และคู่ไหนตีกัน

gl + uule: ตัวไหนชนะ?

เมื่อมีทั้งสองตัว uule จะให้สัญญาณตำแหน่งที่เฉพาะเจาะจงกว่า gl ถ้าคุณตั้ง gl=uk แต่ uule ชี้ไปที่โตเกียว คุณจะได้ผลลัพธ์ที่ได้รับอิทธิพลจากโตเกียว ไม่ใช่ผลลัพธ์ของสหราชอาณาจักร

คำแนะนำ: ถ้าใช้ uule ให้ตัด gl ออกไปเลย หรืออย่างน้อยตั้ง gl ให้เป็นประเทศที่ครอบคลุมเมืองใน uule อย่าส่งสัญญาณขัดกัน

tbm + udm: อย่าใช้พร้อมกัน

จากการทดสอบของฉัน เมื่อ tbm และ udm อยู่ใน URL เดียวกัน Google บางครั้งจะตัดทั้งคู่ทิ้งและคืนค่าเป็นการค้นหาเว็บธรรมดา พฤติกรรมนี้ไม่คงที่ระหว่าง session และบัญชี

คำแนะนำ: ใช้ udm อย่างเดียวสำหรับงานใหม่ ถ้าจำเป็นต้องรองรับ workflow เก่า ให้เลือกใช้เพียงตัวเดียว — ห้ามใช้ทั้งคู่พร้อมกัน

lr + cr: กรองซ้อนกันมากไปอาจได้ศูนย์ผลลัพธ์

นี่คือกับดักที่ละเอียดอ่อน lr=lang_en จำกัดเฉพาะเนื้อหาภาษาอังกฤษ cr=countryJP จำกัดเฉพาะหน้าที่โฮสต์ในญี่ปุ่น เมื่อนำมารวมกัน คุณกำลังขอผลลัพธ์แบบ “หน้าอังกฤษที่โฮสต์ในญี่ปุ่น” ซึ่งเป็นสัดส่วนที่เล็กมากของเว็บ

คำแนะนำ: ใช้อย่างใดอย่างหนึ่ง เว้นแต่คุณต้องการจุดตัดร่วมของทั้งสองจริง ๆ ถ้าจะใช้คู่กัน ให้คาดหวังว่าจำนวนผลลัพธ์จะน้อยลงมาก

num + start: pagination ที่พัง

สคริปต์เก่าที่ใช้ num=100&start=0 ตอนนี้มักจะได้ผลลัพธ์แค่ราว ๆ 10 รายการแบบเงียบ ๆ พารามิเตอร์ num ไม่ได้รับการยอมรับแล้ว แต่ก็ไม่ได้ error — แค่ถูกเมิน

คำแนะนำ: ลบ num ออกจากทุก URL ใช้ start เพิ่มทีละ 10 และตัดผลลัพธ์ที่ซ้ำกันระหว่างหน้า

Quick Conflict Reference

การจับคู่	เกิดอะไรขึ้น	คำแนะนำ
gl + uule	uule ให้สัญญาณที่เฉพาะเจาะจงกว่า	ทำประเทศและเมืองให้สอดคล้องกัน หรือเอา gl ออก
tbm + udm	เดาไม่ได้ — ทั้งคู่ถูกตัดทิ้งได้	ใช้แค่ udm
lr + cr	จำกัดแคบมาก มักเกือบไม่มีผลลัพธ์	ใช้อย่างใดอย่างหนึ่ง
num + start	num ถูกเมิน เหลือผลลัพธ์ประมาณ 10 รายการ	ลบ num ออก ใช้ start แบ่งหน้า
nfpr=1 + tbs=li:1	ควบคุมเกี่ยวข้องกันแต่ไม่เหมือนกัน	ทดสอบกับคำค้นหาจริงของคุณ
hl + lr	ภาษาอินเทอร์เฟซ ≠ การจำกัดภาษาของเนื้อหา	ใช้อย่างตั้งใจ; hl ไม่ใช่ตัวกรองเนื้อหา

จากพารามิเตอร์ URL ของ Google Search ไปสู่การดึงข้อมูลแบบมีโครงสร้าง

ตอนนี้คุณมี Google search URL ที่แม่นยำแล้ว — คำค้นถูกต้อง ประเทศถูกต้อง ช่วงเวลาถูกต้อง และเป็น classic web results ขั้นต่อไปคือการดึงข้อมูลแบบมีโครงสร้างจากผลลัพธ์

ไม่ว่าคุณจะสร้าง rank tracker, เฝ้าดูคู่แข่ง หรือส่งข้อมูลการค้นหาเข้า workflow ของงานรีเสิร์ช การเห็นผลลัพธ์ที่ถูกต้องเป็นแค่ครึ่งทาง คุณยังต้องมี title, URL, snippet, position และวันที่ในสเปรดชีตหรือฐานข้อมูล

สร้าง Google Search URL แบบเจาะจงเป้าหมาย (รวมทุกอย่างเข้าด้วยกัน)

ตัวอย่างแบบครบชุดที่ผสมหลายพารามิเตอร์:

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

แยกออกมาได้ดังนี้:

• q=site%3Acompetitor.com+intitle%3Apricing — หน้าบน competitor.com ที่มีคำว่า “pricing” อยู่ใน title
• hl=en — อินเทอร์เฟซภาษาอังกฤษ
• gl=us — บริบทตลาดสหรัฐฯ
• tbs=qdr:m,sbd:1 — ช่วงเดือนที่ผ่านมา เรียงตามวันที่
• udm=14 — ผลลัพธ์เว็บแบบคลาสสิก (ไม่มี AI Overviews)
• pws=0 — ปิด personalization

คุณสามารถสร้างแบบโปรแกรมได้ด้วย 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'

หรือด้วย 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)

การร้องขอแบบ HTTP จาก anonymous ไปยัง Google มักคืนเป็น JavaScript shell ที่ไม่มีผลลัพธ์เรนเดอร์ฝั่งเซิร์ฟเวอร์ หรือมีการเตือน unusual traffic — ซึ่งนี่เองคือจุดที่การดึงข้อมูลผ่านเบราว์เซอร์ได้เปรียบ

ดึงข้อมูล SERP โดยไม่ต้องเขียน parser

การ parse HTML ของ Google เป็นงานที่เปราะบาง โครงสร้าง DOM เปลี่ยนบ่อย class names ถูกทำให้คลุมเครือ และสิ่งที่คุณเห็นในเบราว์เซอร์ก็ไม่ตรงกับ raw HTTP response เสมอไป

วิธีที่ง่ายกว่าสำหรับคนไม่ใช่นักพัฒนา: เปิด URL ที่คุณสร้างไว้อย่างดีใน Chrome แล้วใช้เครื่องมือดึงข้อมูลบนเบราว์เซอร์เพื่อดึงข้อมูลแบบมีโครงสร้างจากหน้าที่มองเห็นอยู่ ที่ Thunderbit เราสร้าง Chrome extension มาเพื่อรองรับ workflow แบบนี้โดยเฉพาะ — คุณสามารถใช้ AI Suggest Fields เพื่อระบุคอลัมน์อย่าง title ของผลลัพธ์, URL ปลายทาง, ข้อความ snippet และตำแหน่งที่มองเห็น แล้วดึงออกมาเป็นสเปรดชีตได้โดยไม่ต้องเขียน parser

นี่ไม่ใช่ทางเดียวที่ทำได้ แนวทางที่ใช้โค้ดก็ใช้ได้เช่นกัน โดยเฉพาะถ้าคุณต้องดึงข้อมูลจำนวนมากหรือทำซ้ำบ่อย ๆ แต่สำหรับงานรีเสิร์ชเฉพาะกิจ งานตรวจสอบ และ competitive analysis แบบครั้งคราว การดึงข้อมูลผ่านเบราว์เซอร์ช่วยหลีกเลี่ยงความเปราะบางของการ parse HTML ไปได้เลย

เมื่อไรควรใช้ API อย่างเป็นทางการแทน

ประเด็นเรื่องการใช้งานอย่างรับผิดชอบ — และสำคัญมาก

ข้อกำหนดในการให้บริการของ Google ห้ามการเข้าถึงอัตโนมัติที่หลีกเลี่ยงมาตรการป้องกัน และ Google Search Help ก็จัดประเภท search scraper และซอฟต์แวร์ที่ส่งคำค้นหาอัตโนมัติเพื่อตรวจอันดับว่าเป็น automated traffic อย่างชัดเจน การรัน Google scraper ระดับ production ทำให้คุณเสี่ยงต่อ IP block, CAPTCHA และปัญหาทางกฎหมายได้

สำหรับความต้องการข้อมูลการค้นหาขนาดใหญ่ระดับ production ทางเลือกที่ดีกว่าคือ API อย่างเป็นทางการ Google’s Custom Search JSON API กำลัง ปิดรับลูกค้าใหม่ — ผู้ใช้เดิมมีเวลาย้ายจนถึง 1 มกราคม 2027 พร้อมโควต้าฟรี 100 คำขอต่อวัน และคิด $5 ต่อ 1,000 คำขอหลังจากนั้น Google แนะนำ Vertex AI Search สำหรับการค้นหาในไซต์ที่ควบคุมได้ในอนาคต

สำหรับเว็บไซต์ที่คุณเป็นเจ้าของ Search Console’s Search Analytics API คือแหล่งข้อมูล first-party สำหรับ clicks, impressions, CTR และ average position — ไม่ต้อง scrape เลย

มองความรู้เรื่องพารามิเตอร์ URL เป็นเครื่องมือสำหรับการวิเคราะห์และรีเสิร์ช: เหมาะมากสำหรับสร้างลิงก์ค้นหาที่แม่นยำ ทำ manual audit และทำความเข้าใจว่า Google แสดงอะไร แต่ไม่ใช่ตัวแทนของ official API ในระดับสเกลใหญ่

Google Search Operators: ตัวดำเนินการที่อยู่ในคำค้นของคุณ

Search operators อยู่ภายในพารามิเตอร์ q= แต่ก็เป็นคู่หูสำคัญของ URL parameters ตารางด้านล่างครอบคลุมตัวที่ Google มีเอกสารอธิบายอยู่ตอนนี้ รวมถึงบางตัวที่ยังใช้งานได้จริง:

Operator	ทำอะไร	ตัวอย่าง
site:	จำกัดเฉพาะโดเมน	q=site:example.com+SEO
filetype:	จำกัดเฉพาะชนิดไฟล์	q=filetype:pdf+annual+report
intitle:	คำต้องอยู่ใน title	q=intitle:pricing+SaaS
inurl:	คำต้องอยู่ใน URL	q=inurl:blog+marketing
-	ตัดคำออก	q=apple+-fruit
""	จับวลีตรงตัว	q=%22google+search+url+parameters%22
OR	อย่างใดอย่างหนึ่ง	q=scraping+OR+crawling
before:	ผลลัพธ์ก่อนวันที่กำหนด	q=AI+before:2026-01-01
after:	ผลลัพธ์หลังวันที่กำหนด	q=AI+after:2025-06-01
related:	เว็บไซต์ที่คล้ายกัน	q=related:hubspot.com

พลังจริงเกิดจากการผสม operators ภายใน q เข้ากับพารามิเตอร์ URL ที่อยู่นอกมัน:

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

อันนี้จะหาหน้าที่อยู่บน competitor.com ที่มีคำว่า “pricing” ใน title เผยแพร่หลังมกราคม 2026 เรียงตามวันที่ ในตลาดสหรัฐฯ และเป็น classic web results ทั้งหมดนี้คือคำค้นเชิง competitive intelligence ที่แม่นมากซึ่งสร้างได้จาก URL parameters และ operators ล้วน ๆ

Google ระบุว่า ผลลัพธ์จาก site: ไม่ได้การันตีว่าครบทั้งหมด — อย่ามอง query แบบ site: ว่าเป็น inventory ครบถ้วนของทุกหน้าที่ถูก index แล้ว

การใช้อย่างรับผิดชอบ: ข้อกำหนดของ Google และ Rate Limits

ขออธิบายสั้น ๆ แต่สำคัญ

ข้อกำหนดในการให้บริการของ Google ห้ามการเข้าถึงแบบละเมิดและการหลีกเลี่ยงมาตรการป้องกัน Google Search Help ระบุชัดว่า search scraper และซอฟต์แวร์ตรวจอันดับอัตโนมัติเป็นตัวอย่างของ automated traffic การละเมิดอาจนำไปสู่ IP block, CAPTCHA, การจำกัดบัญชี และอาจมีผลทางกฎหมาย

ความรู้เรื่องพารามิเตอร์ URL ควรใช้เพื่อ: สร้าง URL ค้นหาที่แม่นยำด้วยตนเอง, ทำลิงก์ค้นหาที่บันทึกไว้แชร์ให้ทีม, ทำ audit ขนาดเล็กในเบราว์เซอร์, และทำความเข้าใจว่า interface การค้นหาของ Google ทำงานอย่างไร สำหรับงานอัตโนมัติระดับ production ควรใช้ official API ของ Google หรือผู้ให้บริการข้อมูลการค้นหาบุคคลที่สามที่มีสิทธิ์ใช้งานอย่างถูกต้อง เช่น Brave Search API

ที่ Thunderbit, browser extension ของเราสร้างมาเพื่อการดึงข้อมูลจากหน้าที่ผู้ใช้เปิดดูอยู่จริง ๆ ไม่ใช่การยิงคำค้นหาอัตโนมัติไปยัง Google ปริมาณสูง นี่เป็นความแตกต่างที่สำคัญ

Key Takeaways: ชุดเครื่องมือพารามิเตอร์ URL ของ Google Search สำหรับปี 2026

สรุปสั้น ๆ:

• ใช้ gl + hl สำหรับสัญญาณ localization และอย่าพึ่ง ccTLD อย่างเดียวระหว่างที่ Google กำลังย้ายโดเมน
• ทดสอบทั้ง udm และ tbm เมื่อเกี่ยวข้อง — ทั้งคู่ไม่ใช่ API ผู้ใช้แบบเสถียรที่มีเวอร์ชันรองรับอย่างเป็นทางการ
• udm=14 อาจขอ classic web results โดยไม่มี AI Overviews แต่ Google อาจตัดหรือ rewrite ค่านี้ได้
• ใช้ uule สำหรับ geo-targeting ระดับเมือง ด้วยสูตรการเข้ารหัส protobuf ด้านบน
• เรียนรู้ tbs ให้แม่น สำหรับการกรองวันที่ (cdr:1,cd_min:...,cd_max:...), การเรียงตามวันที่ (sbd:1), และ verbatim search (li:1)
• ระวังความขัดแย้งของพารามิเตอร์: gl vs. uule, tbm vs. udm, lr vs. cr
• num=100 ไม่น่าเชื่อถือและไม่เคยได้รับการรองรับอย่างเป็นทางการ — ใช้ start ทีละ 10 เป็นค่าเริ่มต้นที่ปลอดภัยกว่า
• สำหรับข้อมูล SERP แบบมีโครงสร้าง ใช้เครื่องมือบนเบราว์เซอร์อย่าง Thunderbit สำหรับงานเฉพาะกิจ หรือใช้ official API สำหรับงานระดับ production
• เคารพข้อกำหนดของ Google — พารามิเตอร์ URL เป็นเครื่องมือวิจัย ไม่ใช่ใบอนุญาตให้ scrape

Google ยังคงเปลี่ยนพารามิเตอร์โดยไม่ประกาศล่วงหน้า ฉันจะอัปเดต reference นี้ต่อไปเมื่อมีการเปลี่ยนแปลง — เก็บไว้เป็นบุ๊กมาร์กแล้วกลับมาเช็กเรื่อย ๆ

เรียนรู้เพิ่มเติม

• 9 Best SEO APIs for 2026 (With Real Cost-per-Request Data)
• How to Master Search Engine Scraping: A Complete Guide
• Top 27 Tools to Analyze and Monitor Website Rankings
• How to Use Web Scraper Pagination for Efficient Extraction
• What Is Search Automation? Benefits, Tools, and Strategies

คำถามที่พบบ่อย

udm=14 ทำอะไรใน URL การค้นหาของ Google?

udm=14 สามารถขอหน้าผลลัพธ์เว็บแบบคลาสสิกที่ไม่มี AI Overviews ได้ จึงเป็นที่นิยมในหมู่ผู้ทำ SEO มันเป็นค่าที่ reverse-engineered ไม่ใช่สัญญาอย่างเป็นทางการจาก Google และ Google อาจตัดหรือ rewrite ได้ขึ้นกับ session, account, region, client และ experiment cohort

พารามิเตอร์ num ยังใช้ได้อยู่ไหมในปี 2026?

อย่าอิงมันเป็นหลัก Google หยุดยอมรับ num=100 อย่างสม่ำเสมอ ตั้งแต่กันยายน 2025 และโฆษกก็ระบุว่าพารามิเตอร์นี้ไม่เคยได้รับการรองรับอย่างเป็นทางการ ควรใช้ start ทีละ 10 เป็นค่าแบ่งหน้าที่ปลอดภัยกว่า และตรวจสอบจำนวนผลลัพธ์ที่ได้จริง เพราะ Google ยังอาจ rewrite หรือจำกัดคำตอบได้

จะจำลองการค้นหา Google จากเมืองหนึ่งโดยเฉพาะได้อย่างไร?

ใช้พารามิเตอร์ uule ร่วมกับชื่อเมืองที่เข้ารหัส ส่วนการเข้ารหัสด้านบนมีทั้งอัลกอริทึมแบบ protobuf และตัวอย่างโค้ด Python คุณจะต้องใช้ชื่อสถานที่ canonical ของ Google ซึ่งหาได้จาก Google Ads geographic targeting data แล้วเข้ารหัสเป็นค่า uule เช่น uule=w+CAIQICIeNew+York,New+York,United+States

gl, lr และ cr ต่างกันอย่างไร?

ทั้งสามตัวนี้ควบคุมคนละมิติของการกำหนดเป้าหมายด้านภูมิศาสตร์และภาษา gl จำลองตำแหน่งค้นหาในระดับประเทศ (มีผลต่อ ranking และ local results) lr จำกัดผลลัพธ์ตามภาษาของเนื้อหา cr จำกัดผลลัพธ์ตามประเทศที่โฮสต์อยู่ สามารถใช้ร่วมกันได้ แต่ถ้าจับคู่ขัดกัน เช่น lr=lang_en + cr=countryJP ผลลัพธ์จะถูกบีบให้แคบลงมาก

ใช้ค่า tbs หลายตัวใน URL เดียวได้ไหม?

ได้ — ให้คั่นด้วย comma ภายในพารามิเตอร์ tbs เดียว เช่น tbs=qdr:m,sbd:1 จะกรองเฉพาะเดือนที่ผ่านมาและเรียงตามวันที่ (ใหม่สุดก่อน) คุณยังเพิ่ม li:1 เพื่อ verbatim mode ได้ด้วย: tbs=qdr:m,sbd:1,li:1 อย่างไรก็ตาม syntax ของ tbs ไม่ได้มีเอกสารทางการ จึงควรทดสอบชุดค่าที่คุณใช้จริงเพื่อยืนยันว่าทำงานตามต้องการ