Google ซีรีส์ Non-Canonical Cabinet: คีย์เวิร์ดใน URL เป็นสัญญาณที่เล็กมาก

Google Search Central เผยแพร่ตอนแรกของซีรีส์วิดีโอใหม่บน YouTube ชื่อ "The Non-Canonical Cabinet" เมื่อวันที่ 14 ต.ค. 2569 ในตอนที่ชื่อ "What can you actually put in a URL?" Gary Illyes และ Cherry Prommawin ซึ่งเป็น Search Developer Advocate ของ Google อธิบายว่าชื่อโดเมนและพาธของ URL ใส่อะไรได้บ้าง และ Illyes เรียกคีย์เวิร์ดใน URL ว่าเป็น "สัญญาณที่เล็กมากอย่างเหลือเชื่อ" (an incredibly small signal) ที่มีผลเฉพาะตอนที่ Google ไม่มีข้อมูลอื่นให้ใช้เลย คำแนะนำส่วนใหญ่เป็นแนวทางเดิมที่ Google พูดมาหลายปีแล้ว สิ่งที่ใหม่คือรูปแบบรายการ และการที่คำตอบเหล่านี้ถูกบันทึกไว้ในที่เดียวแบบเป็นทางการ ตามที่ Search Engine Journal รายงานในวันเดียวกัน

ซีรีส์ Non-Canonical Cabinet คืออะไร

Search Engine Journal รายงานว่า Google Search Central ประกาศซีรีส์ Non-Canonical Cabinet ด้วยวิดีโอตัวอย่างเมื่อวันที่ 6 ต.ค. 2569 โดยตัวอย่างอธิบายว่าเป็นรายการแนวซิทคอมที่สร้างจากคำถามเฉพาะเจาะจงของเจ้าของเว็บไซต์และคนในวงการ SEO คำอธิบายของตอนแรกระบุขอบเขตไว้ว่า เป็นคำถามที่ "ไม่เหมาะจะอยู่ในหน้า FAQ มาตรฐาน แต่ยังมีประโยชน์ต่อ Search และฟีเจอร์ generative AI"

Search Engine Journal ชี้ว่า Illyes เคยเป็นพิธีกรซีรีส์ "How Search Works" ของ Search Central ในปี 2567 ซึ่งมี 5 ตอน และไล่เรียงตั้งแต่การ crawl การ index ไปจนถึงการแสดงผล ซีรีส์ใหม่นี้กลับด้านกัน คือเริ่มจากคำถามแปลก ๆ ที่เจ้าของเว็บถามจริง แล้วค่อยย้อนไปหากฎทางเทคนิคที่อยู่เบื้องหลัง Google เปิดให้ผู้ชมส่งคำถามแบบ edge case ของตัวเองไว้ในช่องคอมเมนต์ใต้วิดีโอแต่ละตอน หัวข้อของรายการจึงมาจากผู้ชมส่วนหนึ่ง

วิดีโอตัวอย่างกับตอนแรกออกห่างกัน 8 วัน Search Engine Journal รายงานว่าตอนถัดไปจะพูดถึง robots.txt และคำอธิบายวิดีโอทั้งสองไม่ได้ระบุตารางการปล่อยตอนใหม่

ชื่อโดเมนกับพาธ URL ใช้กฎคนละชุด

ตอนวันที่ 14 ต.ค. 2569 แยกสองส่วนของที่อยู่เว็บที่คนมักเหมารวมกันออกจากกัน ส่วนแรกคือชื่อโดเมน (โฮสต์ เช่น example.com) ส่วนที่สองคือพาธ (ทุกอย่างหลังเครื่องหมายทับตัวแรก) กฎของแต่ละส่วนมาจากหน่วยงานต่างกัน และฝั่งโดเมนเข้มงวดกว่ามาก

ชื่อโดเมน: ตัวอักษร ตัวเลข และขีดกลาง

Prommawin กล่าวในรายการว่า Google ทำตามมาตรฐานทางเทคนิคของ Internet Engineering Task Force (IETF) สำหรับชื่อโดเมน Search Engine Journal ระบุว่ามาตรฐานนั้นคือ RFC 1035 และ RFC 1123 ซึ่งอนุญาตให้ชื่อโดเมนมีตัวอักษร ตัวเลข และขีดกลาง ส่วน ICANN เป็นผู้กำหนดนโยบายในระดับนี้ด้วย

โดเมนภาษาท้องถิ่น (IDN) และ Punycode

โดเมนที่เขียนด้วยอักษรที่ไม่ใช่ละติน เช่น ภาษาจีนหรืออาหรับ เรียกว่า internationalized domain name หรือ IDN ทั้งสองคนอธิบายว่าโดเมนแบบนี้จะถูกแปลงเป็น Punycode ซึ่งเป็นสตริง ASCII ที่ขึ้นต้นด้วย "xn--" เบราว์เซอร์มักแสดง IDN เป็นอักษรต้นฉบับ แต่ชื่อจริงที่ระบบ DNS ใช้คือรูป xn-- รายการหัวข้อที่ Search Engine Roundtable สรุปไว้มีหัวข้อ "ทำไม xn-- ถึงไม่ใช่การพิมพ์ผิด" ด้วย ซึ่งตรงกับความสับสนที่หลายคนเจอเวลาเห็นรูปแบบนี้ในรายงานหรือ log

Illyes ยังเตือนจุดอ่อนที่รู้กันของ IDN คืออักษรบางชุดมีตัวที่หน้าตาแทบเหมือนตัวอักษรในอีกชุดหนึ่ง Search Engine Journal ยกตัวอย่างอักษรซีริลลิกตัวหนึ่งที่หน้าตาใกล้เคียงกับตัว "p" ในภาษาอังกฤษมาก ตัวอักษรหน้าตาคล้ายกันแบบนี้ทำให้ทั้งคนและเบราว์เซอร์สับสนได้

ใส่อีโมจิในชื่อโดเมนไม่ได้

Illyes กล่าวว่ามาตรฐานอินเทอร์เน็ตปัจจุบันสำหรับโดเมนไม่อนุญาตให้มีอีโมจิในชื่อโดเมน Search Engine Journal อ้างมติคณะกรรมการ ICANN ปี 2560 ที่ระบุว่าอีโมจิ "ไม่ได้รับอนุญาตตามมาตรฐานทางเทคนิคปัจจุบันของ IDN" มติเดียวกันยังบอกว่าโดเมนระดับบนสุดรหัสประเทศ (ccTLD) บางแห่งยังให้จดอีโมจิในระดับที่สองได้ ส่วน Search Engine Roundtable สรุปตอนนี้แบบตรง ๆ ว่าโดเมนที่เป็นอีโมจิไก่กับไฟ "มีไม่ได้"

พาธ URL: ใส่อีโมจิและอักษรที่ไม่ใช่ละตินได้

พาธยืดหยุ่นกว่ามาก Illyes บอกว่า Googlebot จะ crawl พาธที่มีอีโมจิ และ "ระบบของเราจะประมวลผลมันจริง ๆ" เบราว์เซอร์จะทำ percent-encoding ตัวอักษรเหล่านี้ก่อนส่งคำขอ อีโมจิไก่ที่ใช้ในรายการจึงกลายเป็น %F0%9F%90%94 ในพาธ Illyes เสริมว่าไม่ใช่ทุกเบราว์เซอร์หรือแอปโซเชียลมีเดียจะแสดงอีโมจิกลับมาให้เห็น บางแอปแสดงเป็น "ตัวอักษรยุ่งเหยิงยาวเหยียด" แทน

ทั้งหมดนี้ไม่ขัดกับเอกสารของ Google หน้า "URL structure best practices for Google Search" ระบุว่า Google Search รองรับ URL ตามนิยามของ IETF STD 66 แนะนำให้ทำ percent-encoding กับตัวอักษรนอกช่วง ASCII เวลาใส่ลิงก์ และใช้พาธที่เป็นอีโมจิเป็นหนึ่งในตัวอย่างของเอกสารอยู่แล้ว

คีย์เวิร์ดใน URL: "สัญญาณที่เล็กมากอย่างเหลือเชื่อ"

ประโยคที่ทีม SEO น่าจะหยิบไปอ้างมากที่สุดคือเรื่องคีย์เวิร์ด Illyes เรียกคีย์เวิร์ดใน URL ว่า "สัญญาณที่เล็กมากอย่างเหลือเชื่อ" และบอกว่า "มันมีผลจริง ๆ ก็ต่อเมื่อเราไม่มีข้อมูลอื่นให้ใช้เลย" ตัวอย่างของเขาคือเว็บไซต์ที่เพิ่งเกิดได้ไม่กี่วินาทีและยังไม่มีเนื้อหา เมื่อ Google เห็นเนื้อหาแล้ว เขาบอกว่าคีย์เวิร์ดในโดเมนและ URL "แทบไม่มีความหมายอะไรเลย"

Barry Schwartz จาก Search Engine Roundtable เสริมว่า Illyes ตั้งใจพูดด้วยว่า Google ตรวจจับการสแปมใน URL ได้ รายการหัวข้อที่ Search Engine Roundtable สรุปไว้ยังแซวว่า URL อย่าง "best-grilled-chicken-cheap-delicious-amaze-amaze-amaze" จะทำให้หน้าเว็บติดอันดับหนึ่งตลอดไปหรือเปล่า และ Search Engine Journal รายงานว่าช่วงสรุปท้ายรายการบอกผู้ชมให้เลิกพยายามปั่นผลการค้นหาด้วยการยัดคีย์เวิร์ดลงใน URL

นี่ไม่ใช่แนวทางใหม่

Search Engine Roundtable เขียนชัดว่าหัวข้อทั้งหมดนี้ "เป็นเรื่องที่เราเคยรายงานไปแล้ว" โพสต์วันที่ 14 ต.ค. 2569 ของเว็บนี้ลิงก์ไปยังบทความเก่ากว่าสิบชิ้นเรื่อง URL ในฐานะสัญญาณการจัดอันดับ เช่นหัวข้อ "Google: Keywords In URLs A Very Small Ranking Factor" และ "Google Really Wants You To Avoid Changing URLs Just For SEO Reasons" ส่วน Search Engine Journal อ้างว่า John Mueller ของ Google เคยเรียกคีย์เวิร์ดใน URL ว่าเป็น "ปัจจัยการจัดอันดับที่เล็กมาก" ในปี 2559 และ "ปัจจัยที่เบามาก ๆ" ในปี 2564 ถ้อยคำของ Illyes ในปี 2569 คมกว่าทั้งสองครั้ง แต่ทิศทางเหมือนเดิมมาราวสิบปี

สรุปแบบตรงไปตรงมาคือ ตอนนี้ไม่ได้เปลี่ยนวิธีที่ Google ปฏิบัติต่อ URL แต่ให้คลิปจากต้นทางที่ใหม่และชัดเจน ให้ SEO และนักพัฒนาใช้อ้างอิงเวลามีคนขอให้ทำ slug ที่อัดคีย์เวิร์ด หรือขอเปลี่ยน URL ทั้งเว็บ "เพื่อ SEO"

ใช้ขีดกลาง ไม่ใช่ขีดล่าง

เรื่องตัวคั่นคำ Illyes บอกว่า Google มองคำที่เชื่อมด้วยขีดล่าง (underscore) ในพาธ URL ว่าเป็น "คำยาวคำเดียว" เขาเสริมว่าบางครั้งก็ไม่เป็นไร เพราะ Google อาจยังแยกคำออกมาใช้ได้ แต่ Google แนะนำขีดกลาง (hyphen) เพราะเป็นตัวคั่นที่ใช้กันทั่วไปบนเว็บ

เอกสาร URL structure ของ Google พูดเรื่องเดียวกันและอธิบายเหตุผลไว้ เอกสารแนะนำให้ใช้ขีดกลางแทนขีดล่าง เพราะช่วยให้ผู้ใช้และเสิร์ชเอนจินแยกแนวคิดใน URL ได้ดีกว่า และไม่แนะนำขีดล่าง "ด้วยเหตุผลทางประวัติศาสตร์" เพราะขีดล่างมักใช้กับสิ่งที่ควรอยู่ติดกันเป็นหนึ่งเดียว เช่นชื่อฟังก์ชันอย่าง format_date ในภาษาโปรแกรม เอกสารยังจัดการเขียนคำติดกันโดยไม่มีตัวคั่น (ตัวอย่างคือ "greendress") ไว้ในกลุ่มที่ไม่แนะนำ

คลังบทความเรื่องนี้ของ Search Engine Roundtable ย้อนไปถึงยุคที่ Matt Cutts พูดเรื่องขีดล่าง จนถึงหัวข้อที่ใหม่กว่าอย่าง "Google: Hyphens Still Recommended Over Underscores In URLs For SEO" ตอนนี้ปิดประเด็นด้วยเสียงของ Google ในปัจจุบัน

เทียบคำพูดในรายการกับเอกสารของ Google

ตารางด้านล่างวางประเด็นหลักจากตอนวันที่ 14 ต.ค. 2569 ตามที่ Search Engine Journal และ Search Engine Roundtable รายงาน เทียบกับสิ่งที่เอกสาร URL structure ของ Google เขียนไว้อยู่แล้ว

สิ่งที่ Google ไม่ได้พูด

มีบางเรื่องที่ไม่มีในแหล่งข่าว และควรพูดให้ชัด ตามที่มีการรายงาน รายการไม่ได้ให้ตัวเลขว่าคีย์เวิร์ดใน URL มีน้ำหนักเท่าไร นอกจากบอกว่าเล็กมาก ไม่ได้บอกว่า Google ลงโทษ URL ที่ใช้ขีดล่าง (Illyes บอกว่าบางครั้งก็ไม่เป็นไร) และไม่ได้บอกให้เจ้าของเว็บเปลี่ยน URL เดิม Search Engine Journal สรุปในเชิงปฏิบัติว่าเว็บที่ทำตามเอกสาร URL structure อยู่แล้วไม่ต้องแก้อะไร

แหล่งข่าวทั้งหมดไม่ได้พูดถึงภาษาหรือตลาดใดเป็นการเฉพาะ รวมถึงภาษาไทย เนื้อหาเรื่อง URL ภาษาไทยด้านล่างจึงเป็นบทวิเคราะห์จากวิธีที่มาตรฐานทำงาน ไม่ใช่สิ่งที่ Google พูดในรายการ

ความหมายสำหรับนักการตลาดไทย

ส่วนนี้เป็นบทวิเคราะห์ ภาษาไทยเป็นอักษรที่ไม่ใช่ละติน ทั้งสองครึ่งของตอนนี้จึงใช้กับเว็บไทยได้โดยตรง

slug ภาษาไทยถูกทำ percent-encoding

คำภาษาไทยในพาธ URL จะถูกส่งเป็นไบต์ UTF-8 แล้วทำ percent-encoding แบบเดียวกับตัวอย่างอีโมจิ อักษรไทยหนึ่งตัวใช้ 3 ไบต์ใน UTF-8 คำว่า ไทย ซึ่งมี 3 ตัวอักษรจึงกลายเป็น %E0%B9%84%E0%B8%97%E0%B8%A2 ตอนส่งจริง นี่คือเหตุผลที่ slug ภาษาไทยที่คัดลอกไปวางในแอปแชตหรือสเปรดชีตบางครั้งกลายเป็นสตริง %E0 ยาวเหยียด ซึ่งเป็นปัญหาการแสดงผลแบบเดียวกับที่ Illyes พูดถึงเรื่องอีโมจิ เอกสารของ Google แนะนำให้ทำ percent-encoding กับตัวอักษรที่ไม่ใช่ ASCII ใน href และแนะนำให้ใช้คำในภาษาของกลุ่มเป้าหมายใน URL โดยยกภาษาญี่ปุ่นเป็นตัวอย่างหนึ่ง สำหรับเว็บที่กลุ่มเป้าหมายค้นหาเป็นภาษาไทย แนวทางนี้ชี้ว่า slug ภาษาไทยที่อ่านเข้าใจได้เป็นตัวเลือกที่ใช้ได้

โดเมนภาษาไทยใช้ Punycode

โดเมนระดับบนสุดภาษาไทย .ไทย เป็น IDN เบื้องหลังจึงเป็น Punycode ว่า xn--o3cw4h ชื่อโดเมนระดับที่สองที่เป็นอักษรไทยก็เช่นกัน คำเตือนเรื่องตัวอักษรหน้าตาคล้ายกันที่ Illyes พูดถึง ส่วนใหญ่เกี่ยวกับการผสมอักษรต่างชุดกัน ควรคิดถึงเรื่องนี้ก่อนซื้อโดเมนภาษาไทยไว้ป้องกันแบรนด์หรือใช้ทำแคมเปญ

slug ไทยหรือ slug อังกฤษ

ทีมในกรุงเทพฯ มักถกกันว่าหน้าเว็บภาษาไทยควรใช้ slug ภาษาไทยหรือภาษาอังกฤษ ถ้ายึดตามคำพูดของ Illyes เอง ค่าทางคีย์เวิร์ดของทั้งสองทางแทบเป็นศูนย์เมื่อ Google เห็นเนื้อหาของหน้าแล้ว การตัดสินใจจึงควรดูจากเรื่องที่ใช้งานจริง เช่น ลิงก์ดูเป็นอย่างไรเวลาแชร์ ระบบ CMS และเครื่องมือวิเคราะห์จัดการพาธที่ถูก encode ได้เรียบร้อยไหม และความสม่ำเสมอกับส่วนอื่นของเว็บ การเปลี่ยน URL เดิมเพียงเพื่อใส่คีย์เวิร์ดมีความเสี่ยงเรื่อง redirect โดยแทบไม่ได้อะไรกลับมา ซึ่งตรงกับคำแนะนำเก่าของ Google ที่ Search Engine Roundtable ลิงก์ไว้

ถ้าอยากให้มีคนตรวจโครงสร้าง URL การ encode หรือ redirect ก่อนย้ายเว็บ การตรวจ SEO ทางเทคนิค คือจุดที่ควรเริ่ม ส่วน บริการ SEO ในประเทศไทย ครอบคลุมเนื้อหาและลิงก์ซึ่งเป็นสิ่งที่ขยับอันดับได้จริง เว็บที่กำลังสร้างใหม่สามารถวางกฎเรื่องขีดกลางและการ encode ไว้ตั้งแต่ต้นผ่านงาน ออกแบบเว็บไซต์

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

คีย์เวิร์ดใน URL ช่วยให้ติดอันดับ Google ไหม

แทบไม่ช่วย Gary Illyes เรียกมันว่า "สัญญาณที่เล็กมากอย่างเหลือเชื่อ" เมื่อวันที่ 14 ต.ค. 2569 และบอกว่ามีผลเฉพาะตอนที่ Google ไม่มีข้อมูลอื่น เช่นเว็บที่เพิ่งเปิดและยังไม่มีเนื้อหา เมื่อ Google เห็นเนื้อหาแล้ว คีย์เวิร์ดใน URL และโดเมน "แทบไม่มีความหมายอะไรเลย"

ควรใช้ขีดกลางหรือขีดล่างใน URL

ใช้ขีดกลาง Illyes บอกว่า Google มองคำที่เชื่อมด้วยขีดล่างเป็น "คำยาวคำเดียว" และเอกสาร URL structure ของ Google แนะนำขีดกลางมากกว่าขีดล่างสำหรับการคั่นคำ

ใส่อีโมจิในชื่อโดเมนได้ไหม

ไม่ได้ตามมาตรฐานปัจจุบัน Illyes บอกว่ามาตรฐานโดเมนไม่อนุญาตอีโมจิ และมติคณะกรรมการ ICANN ปี 2560 ระบุว่าอีโมจิไม่ได้รับอนุญาตสำหรับ IDN แม้ ccTLD บางแห่งยังให้จดในระดับที่สองได้ ส่วนอีโมจิในพาธ URL ใช้ได้และจะถูกทำ percent-encoding

URL ภาษาไทยใช้กับ Google ได้ไหม

ใช้ได้ตามหลักการในเอกสารของ Google แม้เอกสารจะไม่ได้พูดถึงภาษาไทยโดยตรง Google แนะนำให้ใช้คำในภาษาของกลุ่มเป้าหมายใน URL และทำ percent-encoding กับตัวอักษรที่ไม่ใช่ ASCII ซึ่งเป็นวิธีที่ slug ภาษาไทยทำงานอยู่แล้ว ส่วนโดเมนภาษาไทยอย่าง .ไทย จะถูกแปลงเป็น Punycode ตามที่รายการอธิบายไว้สำหรับ IDN ทุกตัว

ต้องเปลี่ยน URL เดิมหลังจากตอนนี้ไหม

ไม่ต้อง Search Engine Journal ระบุว่าเว็บที่ทำตามเอกสาร URL structure ของ Google อยู่แล้วไม่ต้องแก้อะไร และรายการไม่ได้ขอให้เจ้าของเว็บเปลี่ยน URL

Non-Canonical Cabinet น่าติดตามต่อในตอน robots.txt และในช่องคอมเมนต์ ซึ่ง Google ใช้รวบรวม edge case ที่จะตอบในตอนต่อ ๆ ไป สำหรับเว็บไทย ข้อสรุปจากตอนแรกตรงไปตรงมา คือทำ URL ให้อ่านเข้าใจได้ คั่นคำด้วยขีดกลาง ปล่อยให้เบราว์เซอร์จัดการเรื่อง encode และทุ่มแรงด้าน SEO ไปที่เนื้อหาของหน้าเอง