Entity-Based SEO เทคนิคจัด Topic Cluster แทนการดัน Keyword ทีละคำ

ทีมการตลาดของโรงงานผลิตบรรจุภัณฑ์แห่งหนึ่งทำตามคู่มือ SEO เป๊ะ ๆ คือหาคำค้นมาสองร้อยคำ แล้วเขียนหนึ่งหน้าต่อหนึ่งคำ ผลคือเว็บมีหน้าชื่อ “กล่องกระดาษลูกฟูกราคาถูก” “กล่องลูกฟูกสั่งทำ” “โรงงานกล่องลูกฟูก” และ “กล่องลูกฟูก 3 ชั้น ราคา” ซึ่งเนื้อหาข้างในเกือบเหมือนกันทั้งสี่หน้า ต่างกันแค่คำในหัวเรื่องกับสองสามประโยคที่สลับที่กัน นี่คือจุดที่คนเริ่มหันมาสนใจ Entity Based SEO กันมากขึ้น

วิธีนี้เคยได้ผลในยุคที่ระบบค้นหาจับคู่ตัวอักษร แต่ตอนนี้ระบบเข้าใจว่าสี่คำนั้นหมายถึงเรื่องเดียวกัน และเมื่อคำตอบถูกสรุปโดย AI ก่อนแสดงลิงก์ การมีสี่หน้าที่ตอบครึ่ง ๆ กลาง ๆ ยิ่งเสียเปรียบหน้าเดียวที่ตอบครบ Entity Based SEO คือการกลับด้านวิธีคิด จากการไล่ดันคำทีละคำ มาเป็นการทำให้เว็บดูรู้จริงเรื่องสิ่งหนึ่งอย่างครบถ้วน บทความนี้จะลงรายละเอียดว่าหา entity อย่างไร จัด topic cluster อย่างไร และเขียนแต่ละหน้าให้ไม่ทับกันอย่างไร ถ้าอยากเห็นภาพรวมของการจัดโครงหน้าเว็บทั้งระบบ อ่านคู่กับ โครงสร้างเนื้อหาสำหรับ AIO

Entity Based SEO คืออะไร และต่างจากการทำคีย์เวิร์ดทีละคำอย่างไร

คำว่า entity ในที่นี้ไม่ใช่ศัพท์ลึกลับ ให้คิดง่าย ๆ ว่าถ้าอธิบายสิ่งนั้นให้คนที่ไม่รู้จักฟังได้ในประโยคเดียวว่ามันคืออะไร ทำอะไรได้ และต่างจากของใกล้เคียงตรงไหน สิ่งนั้นก็เป็น entity แล้ว เช่น กล่องลูกฟูกสามชั้น เป็น entity ส่วนคำว่า กล่องลูกฟูกราคาถูก ไม่ใช่ เพราะมันคือคำค้นที่บอกความต้องการของคนหา ไม่ใช่ชื่อของสิ่งใดสิ่งหนึ่ง

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

หา entity หลักของธุรกิจให้เจอก่อน

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

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

จัด Topic Cluster รอบ entity ทีละตัว

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

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

เขียนหน้า pillar กับหน้าลูกให้ต่างกันจริง

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

ตัวอย่างสมมติของ entity ชื่อ ล้างแอร์แบบถอดล้าง หน้า pillar จะตอบว่าคืออะไร ต่างจากล้างแบบไม่ถอดอย่างไร ควรทำถี่แค่ไหน และมีประเด็นอะไรบ้างที่คนมักถาม ส่วนหน้าลูกจะแยกเป็น ราคาล้างแอร์แบบถอดล้างคิดอย่างไร ขั้นตอนทำงานกี่ชั่วโมงและเจ้าของบ้านต้องเตรียมอะไร อาการแบบไหนที่ล้างแล้วไม่หาย และเลือกช่างอย่างไรไม่ให้เจอการเปลี่ยนอะไหล่เกินจำเป็น สี่หน้านี้ไม่ทับกันเพราะแต่ละหน้าตอบคนละคำถาม

ทำให้ระบบ AI เห็นว่าเว็บคุณรู้จัก entity นี้จริง

• เขียนนิยามไว้ในย่อหน้าต้นของหน้า pillar เป็นประโยคเต็มที่ยกไปใช้ได้ทั้งก้อน ไม่ใช่ซ่อนอยู่กลางหน้า
• ใส่คุณสมบัติเป็นตารางที่มีหน่วยกำกับชัด เช่น มิลลิเมตร กิโลกรัม ปี หรือบาทต่อหน่วย เพราะตัวเลขที่มีหน่วยถูกดึงไปอ้างได้ตรงกว่าคำบรรยาย
• ระบุความสัมพันธ์อย่างตรงไปตรงมา เช่น ใช้แทนกันได้ในกรณีใด และใช้แทนกันไม่ได้ในกรณีใด แทนการเขียนว่าแต่ละแบบมีข้อดีต่างกัน
• บอกข้อจำกัดของสิ่งนั้นตามจริง เว็บที่กล้าบอกว่าเมื่อไรไม่ควรใช้สินค้าของตัวเองมักได้ความเชื่อถือกลับมามากกว่าที่เสียไป
• ใช้ชื่อเรียกให้คงที่ทั้งเว็บ ถ้าเรียกว่าแบบถอดล้างก็ใช้คำนี้ทุกที่ อย่าสลับไปมาระหว่างคำเรียกสามสี่แบบในหน้าต่าง ๆ
• ใส่ structured data ให้ตรงกับประเภทของหน้า เช่น หน้าคำถามใช้ FAQPage และหน้าขั้นตอนใช้ HowTo วิธีเลือกใส่ดูที่ เทคนิคอัปเดต Structured Data

สิ่งที่หลายทีมมองข้ามคือความสม่ำเสมอของข้อมูลระหว่างหน้า ถ้าหน้า pillar บอกว่าอายุการใช้งานเฉลี่ยห้าถึงเจ็ดปี แต่หน้าลูกเขียนว่าสิบปี ความขัดแย้งนี้ทำให้ทั้งคนอ่านและระบบที่ดึงข้อมูลไปสรุปเลือกไม่ถูกว่าจะเชื่อตัวเลขไหน ทางแก้ที่ใช้แรงน้อยที่สุดคือเก็บตัวเลขสำคัญของแต่ละ entity ไว้ในไฟล์กลางหนึ่งไฟล์ แล้วให้คนเขียนทุกคนอ้างอิงจากไฟล์นั้นที่เดียว เวลาตัวเลขเปลี่ยนจะได้รู้ว่าต้องไปแก้หน้าไหนบ้าง

ย้ายจากโครงเดิมมาเป็นคลัสเตอร์โดยไม่พังของที่มีอยู่

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

1. 1เลือก entity หนึ่งตัว แล้วรวบรวม URL ทุกหน้าที่พูดถึงเรื่องนั้นอยู่แล้วมาไว้ในตารางเดียว
2. 2ทำเครื่องหมายว่าหน้าไหนมีลิงก์จากเว็บอื่นเข้ามาหรือมียอดเข้าชมจากการค้นหาอยู่ หน้าเหล่านี้ห้ามลบและควรถูกเลือกเป็นหน้าหลักถ้าเนื้อหาไม่แย่เกินไป
3. 3เลือกหนึ่งหน้าเป็น pillar แล้วเขียนใหม่ให้ครอบคลุมทุกหัวข้อในระดับสรุป โดยเก็บ URL เดิมไว้ถ้าเป็นไปได้
4. 4หน้าที่ซ้ำกับ pillar ให้ยุบแล้วทำ redirect มาที่ pillar ส่วนหน้าที่เนื้อหาต่างพอจะยืนเองได้ให้ปรับเป็นหน้าลูกโดยตัดส่วนที่ทับกับ pillar ออก
5. 5ใส่ลิงก์สองทางให้ครบทุกหน้าในคลัสเตอร์ แล้วบันทึกวันที่เปลี่ยนไว้ เพื่อใช้เทียบข้อมูลก่อนหลัง
6. 6รออย่างน้อยสองถึงสามเดือนก่อนตัดสินผล เพราะการเปลี่ยนโครงสร้างต้องใช้เวลาให้ระบบเก็บข้อมูลหน้าใหม่และปรับการจัดกลุ่มเอง

สิ่งที่ไม่ควรทำเวลาทำ Entity Based SEO

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

• ยัดชื่อ entity ซ้ำทุกย่อหน้าเพราะคิดว่ายิ่งพูดถึงบ่อยยิ่งดี ผลคืออ่านแล้วสะดุดและไม่ได้ช่วยให้ระบบเข้าใจมากขึ้น
• ทำคลัสเตอร์พร้อมกันสิบเรื่องด้วยทีมสองคน สุดท้ายได้ pillar สิบหน้าที่ไม่มีหน้าลูกสักหน้า ซึ่งแย่กว่าตอนเริ่ม
• เขียนหน้าลูกโดยเริ่มจากทำสำเนา pillar แล้วขยายหัวข้อเดียว ทำให้ครึ่งหน้าแรกของทุกหน้าลูกเหมือนกันหมด
• เลือก entity จากปริมาณการค้นหาอย่างเดียวโดยไม่ดูว่าธุรกิจขายของนั้นจริงหรือไม่ ได้ทราฟฟิกที่ไม่กลายเป็นลูกค้า
• ใส่ structured data ที่ไม่ตรงกับเนื้อหาบนหน้า เช่น ประกาศว่าเป็นหน้าขั้นตอนทั้งที่ในหน้าไม่มีขั้นตอน ซึ่งเสี่ยงถูกมองว่าจงใจให้ข้อมูลผิด
• ลบหน้าเก่าที่มีลิงก์จากเว็บอื่นเข้ามาเพราะเห็นว่าซ้ำ โดยไม่ทำ redirect ทำให้เสียสิ่งที่สะสมมาหลายปีในวันเดียว