Schema โรงแรม คืออะไร — และทำไมเว็บที่ “หน้าตาดี” อย่างเดียวถึงยังไม่พอให้ AI เข้าใจ
Schema และ structured data ช่วยให้ Google และ AI เข้าใจข้อมูลโรงแรมถูกต้อง บทความนี้บอก schema ที่โรงแรมควรมี Hotel, FAQPage, Review พร้อมเหตุผล
โดย BoydWee
คำตอบสั้นๆ: Schema (structured data) คือ code ที่ฝังในหน้าเว็บเพื่อบอกเครื่อง — ทั้ง Google และ AI อย่าง ChatGPT, Gemini, Perplexity — ว่าข้อมูลแต่ละชิ้นคืออะไร เช่น “นี่คือชื่อโรงแรม” “นี่คือราคาเริ่มต้น” “นี่คือคำถาม-คำตอบ” โรงแรมควรมีอย่างน้อย 5 ตัว: Hotel (หรือ LodgingBusiness), FAQPage, Review/AggregateRating, BreadcrumbList และ LocalBusiness ฝังเป็น JSON-LD รูปแบบที่ Google แนะนำ Schema ไม่ดันอันดับโดยตรง แต่ลดโอกาสที่เครื่องจะเข้าใจข้อมูลคุณผิด และเพิ่มโอกาสถูกหยิบไปแสดงเป็นคำตอบ
ลองนึกภาพว่าหน้าเว็บโรงแรมคุณคือกระดาษแผ่นหนึ่งที่เขียนทุกอย่างไว้ครบ — ชื่อ ที่อยู่ ราคา รีวิว มนุษย์อ่านแล้วเข้าใจทันที เพราะเราเห็น context เห็น layout เห็นว่าตัวเลข “1,800” ตรงนั้นคือราคาห้อง ไม่ใช่เลขที่อยู่
แต่เครื่องไม่ได้ “เห็น” แบบเรา มันอ่านโครงสร้าง ถ้าไม่มีอะไรบอกชัดๆ ว่าชิ้นไหนคืออะไร มันต้องเดา และการเดาคือจุดที่ข้อมูลเพี้ยน — ราคาผิด ที่อยู่สลับ คำถามแขกไม่ถูกจับเป็น Q&A นั่นคือปัญหาที่ schema เกิดมาเพื่อแก้
Schema กับ structured data ต่างกันไหม — และ JSON-LD คืออะไร
สามคำนี้มักใช้ปนกัน เคลียร์ให้ชัดตรงนี้ เพราะ AI ชอบหยิบนิยามสั้นๆ ไปอ้าง:
- Structured data คือแนวคิดกว้างๆ — การจัดข้อมูลให้มีโครงสร้างที่เครื่องอ่านได้
- Schema.org คือ “พจนานุกรม” มาตรฐานที่ Google, Microsoft, Yahoo และ Yandex ร่วมกันสร้าง กำหนดว่าจะเรียกที่พักว่า
Hotelเรียกราคาว่าpriceRangeเรียกรีวิวว่าReview - JSON-LD คือ “รูปแบบการเขียน” schema ลงในหน้า เป็น block code ที่วางในส่วน
<head>ของหน้า — Google แนะนำรูปแบบนี้เป็นหลัก เพราะแยกออกจากเนื้อหาที่คนเห็น แก้ง่าย ไม่กระทบหน้าตาเว็บ
พูดง่ายๆ: structured data คือเป้าหมาย, schema.org คือคำศัพท์, JSON-LD คือวิธีพิมพ์ ทั้งหมดนี้คืองานเบื้องหลังเดียวกันกับที่ทำให้ AEO ของโรงแรม ทำงานได้
5 schema ที่โรงแรมควรมี (เรียงตามผลกระทบจริง)
ผมจะซื่อสัตย์ตั้งแต่ต้น — schema ไม่ใช่เวทมนตร์ที่ดันคุณขึ้นอันดับ 1 ข้ามคืน หน้าที่ของมันคือทำให้ข้อมูลจริงของคุณ “เครื่องอ่านแล้วไม่เข้าใจผิด” นี่คือชุดที่เกี่ยวกับโรงแรมโดยตรง:
1. Hotel (หรือ LodgingBusiness)
นี่คือตัวหลัก บอกเครื่องว่า entity นี้คือ “ที่พัก” ใน schema.org Hotel เป็น subtype ของ LodgingBusiness (ซึ่งเป็น subtype ของ LocalBusiness อีกที) ระบุได้: name, address, geo (พิกัด lat/long), priceRange, telephone, starRating, amenityFeature, checkinTime, checkoutTime ยิ่งกรอกครบ เครื่องยิ่งมี context ตอบคำถามแขกได้ตรง
2. FAQPage
ห่อชุดคำถาม-คำตอบบนหน้าให้เครื่องอ่านเป็น Q&A ชัดเจน แต่ละคู่ใช้ Question + acceptedAnswer (ชนิด Answer) นี่คือ schema ที่จับคู่กับ generative search ตรงที่สุด เพราะ AI หยิบโครงสร้างคำถาม-คำตอบไปตอบผู้ใช้ได้เลย ข้อควรรู้: เนื้อหาใน schema ต้องตรงกับที่แสดงบนหน้าจริง ห้ามใส่ Q&A ที่คนมองไม่เห็น — ผิดแนวทางของ Google
3. Review + AggregateRating
Review คือรีวิวเดี่ยว (มีผู้เขียน คะแนน เนื้อหา) ส่วน AggregateRating คือคะแนนรวม (เช่น 4.6 จาก 128 รีวิว) สองตัวนี้สร้างสัญญาณความน่าเชื่อถือให้เครื่อง ข้อควรระวังตามกฎ Google: ต้องเป็นรีวิวจริงที่แขกเขียนถึงโรงแรมคุณ และต้องแสดงบนหน้าด้วย — ห้ามแต่งคะแนนหรือใส่ rating ที่ไม่มีรีวิวรองรับ นั่นทั้งผิดกฎและทำลายความเชื่อใจระยะยาว
4. BreadcrumbList
บอกเครื่องว่าหน้านี้อยู่ตรงไหนในโครงสร้างเว็บ เช่น หน้าแรก › ห้องพัก › Deluxe Suite ช่วยให้เครื่องเข้าใจลำดับชั้นและความสัมพันธ์ระหว่างหน้า และมักทำให้ผลการค้นหาแสดง path สวยขึ้น
5. LocalBusiness
สำหรับข้อมูล NAP — Name, Address, Phone — รวมถึงเวลาเปิด-ปิด พิกัด และพื้นที่ให้บริการ ถ้าใช้ Hotel ครบถ้วนแล้ว ข้อมูลส่วนนี้ซ้อนอยู่ในนั้น แต่ความสอดคล้องของ NAP ข้ามทุกที่ (เว็บคุณ, Google Business Profile, แพลตฟอร์มท่องเที่ยว) คือสิ่งที่เครื่องใช้ยืนยันว่า “โรงแรมนี้มีจริง”
ทำไม schema ช่วยทั้ง Google และ AI
เหตุผลที่ schema คุ้มค่าลงแรง มีสามชั้น:
ชั้นที่ 1 — Rich result บน Google. เมื่อข้อมูลมีโครงสร้างชัด Google อาจแสดงผลแบบพิเศษ เช่น ดาวรีวิว, FAQ ที่กางได้, breadcrumb path สิ่งเหล่านี้ทำให้ผลของคุณเด่นขึ้นในหน้าค้นหา และมักได้คลิกมากกว่าผลธรรมดา
ชั้นที่ 2 — ลดการเข้าใจผิด. AI อย่าง ChatGPT, Gemini, Perplexity อ่านความหมายจากหน้าเว็บ ถ้ามี schema กำกับ มันมั่นใจขึ้นว่าตัวเลขไหนคือราคา ข้อความไหนคือนโยบาย โอกาสที่มันจะพูดถึงคุณ “ผิด” ก็ลดลง
ชั้นที่ 3 — หยิบไปตอบง่ายขึ้น. เนื้อหาที่มีโครงสร้าง — โดยเฉพาะ FAQPage — แมปกับคำถามผู้ใช้ตรงๆ เมื่อแขกถาม AI ว่า “โรงแรมนี้รับสัตว์เลี้ยงไหม” หน้าที่ห่อคำตอบนั้นด้วย schema ก็มีโอกาสถูกหยิบไปใช้มากกว่า
ข้อควรเข้าใจที่ตรงไปตรงมา: schema เป็น “สัญญาณสนับสนุน” ไม่ใช่ปุ่มลัด Google ระบุชัดว่า structured data ช่วยเรื่องการ “เข้าใจ” และการแสดงผลแบบ rich result แต่ไม่ใช่ ranking factor ตรงๆ ที่ดันอันดับ ของจริงคือ — มันทำให้เนื้อหาดีที่คุณมีอยู่แล้ว ถูกอ่านและนำเสนอได้เต็มศักยภาพ
ใส่ schema ยังไง และเช็คว่าถูกต้องที่ไหน
ข่าวดีคือโรงแรมไม่ต้องเขียน code เองทั้งหมด เส้นทางที่ทำได้จริง:
- ถ้าใช้ระบบจัดการเว็บยอดนิยม มักมีปลั๊กอินหรือฟีเจอร์ใส่ structured data ให้ บางตัวสร้าง JSON-LD อัตโนมัติจากข้อมูลที่คุณกรอก
- ถ้าทำเว็บเอง เขียน JSON-LD วางใน
<head>ของแต่ละหน้า — หน้าโรงแรมใส่ Hotel, หน้า FAQ ใส่ FAQPage และอื่นๆ ตามเนื้อหาจริงของหน้านั้น - เลือก type ให้ตรงเนื้อหา อย่าใส่ FAQPage ในหน้าที่ไม่มี FAQ จริง อย่าใส่ Review ที่ไม่มีรีวิวแสดง — ความตรงระหว่าง schema กับสิ่งที่คนเห็น คือกฎเหล็ก
เมื่อใส่แล้ว ต้องตรวจ สองเครื่องมือฟรีจาก Google และ schema.org:
- Google Rich Results Test — บอกว่าหน้าคุณมีสิทธิ์แสดง rich result แบบไหนบ้าง และเตือน error
- Schema Markup Validator (จาก schema.org) — ตรวจความถูกต้องเชิงโครงสร้างของ JSON-LD
อย่าข้ามขั้นตรวจสอบ schema ที่เขียนผิด syntax หรือใส่ field ไม่ถูก type เครื่องอาจ “ไม่อ่าน” ทั้ง block แทนที่จะช่วย กลับกลายเป็นเสียเปล่า ดูนิยามคำว่า structured data, schema, JSON-LD แบบสั้นได้ที่ glossary
ตัวอย่างประกอบ
(ตัวอย่างสมมติเพื่ออธิบายหลักการ ไม่ใช่เคสจริง)
โรงแรมบูทีค 30 ห้องในเชียงใหม่ มีเว็บสวย ข้อมูลครบ แต่เวลาแขกถาม Perplexity ว่า “ที่พักในเมืองเก่าเชียงใหม่ที่มีที่จอดรถ” กลับไม่เคยโผล่ พอตรวจดูพบว่าหน้าเว็บไม่มี schema เลย เครื่องเลยต้องเดาทุกอย่าง
ทีมงานเริ่มจากใส่ Hotel schema ที่หน้าหลัก (กรอก address, geo, priceRange, amenityFeature รวมถึงระบุว่ามีที่จอดรถ) ทำหน้า FAQ จากคำถามจริงของแขก 10 ข้อแล้วห่อด้วย FAQPage และใส่ AggregateRating ที่ดึงจากรีวิวจริงบนหน้า จากนั้นรัน Rich Results Test จนไม่มี error
ผลไม่ได้มาทันที (ตัวอย่างประกอบ) — เดือนแรกแทบไม่ขยับ แต่พอเครื่องเริ่ม crawl ซ้ำและข้อมูลเริ่มสอดคล้องกันทุกที่ ชื่อก็เริ่มโผล่ในบางคำถาม นี่คือจังหวะจริงของงานนี้ — ไม่ใช่สวิตช์เปิด-ปิด แต่เป็นการวางฐานให้เครื่องเข้าใจคุณถูกต้อง แล้วค่อยสะสมผล
