ข้อมูลที่มีโครงสร้างสำหรับการค้นหาด้วย AI อะไรที่ยังสำคัญอยู่

ข้อมูลที่มีโครงสร้างทำอะไรให้ผู้ช่วย AI จริง ๆ

ผู้ช่วย AI ทุกตัวที่ตอบคำถามอย่าง "หมอฟันที่ดีที่สุดใกล้ฉัน" หรือ "ซื้ออะไหล่ชิ้นนี้ได้ที่ไหน" จะส่งบ็อตเก็บข้อมูลออกไปก่อน ซึ่งก็คือโปรแกรมที่เข้าไปเยี่ยมหน้าเว็บและคัดลอกเนื้อหา เพื่อมาอ่านเว็บไซต์ของคุณ ถ้าไม่มีป้ายกำกับ บ็อตตัวนั้นจะเห็นแค่กำแพงตัวหนังสือและต้องอนุมานความหมายเอาเอง ว่า "555-0134" เป็นเบอร์โทรหรือรหัสสินค้ากันแน่ ข้อมูลที่มีโครงสร้างขจัดการเดานี้ด้วยการห่อข้อเท็จจริงไว้ในบล็อกโค้ดเล็ก ๆ ที่เรียกว่า JSON-LD ซึ่งนั่งอยู่เงียบ ๆ บนหน้าเว็บและบอกโดยพฤตินัยว่า นี่คือเบอร์โทร นี่คือราคา นี่คือเวลาเปิด

เอกสารของ OpenAI เองยืนยันว่าบ็อตของตนที่ชื่อ GPTBot ดึงหน้าเว็บที่เปิดให้สาธารณะเข้าถึงได้ ในแบบที่คล้ายกับเสิร์ชเอนจินดั้งเดิมมาก OpenAI และคำแนะนำเรื่องข้อมูลที่มีโครงสร้างของ Google ก็ระบุชัดว่าป้ายกำกับเหล่านี้ช่วยให้โปรแกรม "เข้าใจเนื้อหาของหน้าเว็บ" Google Search Central ไม่มีบริษัทใดในสองรายนี้บอกว่าตนเพิกเฉยต่อการติดป้ายนี้ ในทางปฏิบัติบล็อก JSON-LD ชุดเดียวกับที่คุณจะใส่เพื่อการค้นหาแบบเดิม จึงยังถูกอ่านโดยผู้ช่วยที่ลูกค้าของคุณกำลังย้ายไปใช้ ถ้าคุณไม่เคยใส่มันเลย ผู้ช่วยที่กำลังตอบคำถามเกี่ยวกับธุรกิจของคุณอยู่ในวันนี้ ก็กำลังทำงานจากการเดา ไม่ใช่จากข้อเท็จจริง

ชนิดข้อมูลสี่แบบที่คุ้มค่าเวลาของคุณ

schema.org ระบุชนิดของรายการไว้หลายร้อยแบบ ตั้งแต่ Recipe ไปจนถึง Movie และ Airport แต่ธุรกิจขนาดเล็กหรือขนาดกลางทั่วไปต้องใช้เพียงสี่แบบก็ครอบคลุมเกือบทุกข้อเท็จจริงที่ผู้ช่วยอาจยกไปอ้าง ใส่สี่อย่างนี้ แล้วไม่ต้องไปกังวลกับที่เหลือ

• Organization กำหนดให้ธุรกิจของคุณเป็นตัวตนเดียวที่มีชื่อ พร้อมโลโก้และลิงก์ไปยังโปรไฟล์โซเชียลอย่างเป็นทางการ เพื่อให้ผู้ช่วยรู้ได้ว่าบัญชี Instagram และเว็บไซต์เป็นของ "ร้านเบเกอรีโดโลเรส" เจ้าเดียวกัน
• LocalBusiness เป็นส่วนขยายของ Organization ที่สร้างมาสำหรับผู้ที่มีที่อยู่จริงหรือมีพื้นที่ให้บริการ มันบรรจุเวลาทำการ เบอร์โทร และย่านของคุณ ซึ่งเป็นรายละเอียดที่ผู้ช่วยต้องใช้เพื่อตอบว่า "ตอนนี้เขาเปิดอยู่ไหม"
• Product และ Offer ผูกราคาจริง สกุลเงิน และความพร้อมจำหน่ายเข้ากับสิ่งที่คุณขาย เพื่อให้ผู้ช่วยยกตัวเลขจริงของคุณไปใช้ แทนที่จะไปเฉลี่ยการเดาของคู่แข่งสองสามราย
• FAQPage คือชุดคู่คำถามและคำตอบในรูปแบบที่ผู้ช่วยชอบหยิบไปยกให้ผู้ใช้ฟังแบบคำต่อคำอยู่แล้ว

การยืนยันที่เครื่องอ่านได้ช่วยเรื่องการระบุตัวตนอย่างไร

ลองนึกถึงโดโลเรส เจ้าของร้านเบเกอรีในออสติน เธอมีโปรไฟล์ธุรกิจบน Google หน้าบน Yelp บัญชี Instagram และเว็บไซต์ รวมเป็นการถูกเอ่ยถึงในชื่อ "ร้านเบเกอรีโดโลเรส" สี่แห่งที่กระจายอยู่บนอินเทอร์เน็ต ก่อนที่ผู้ช่วยจะแนะนำเธอได้อย่างมั่นใจ มันต้องแก้โจทย์การระบุตัวตนให้ได้ก่อน คือตัดสินว่าการเอ่ยถึงทั้งสี่แห่งหมายถึงธุรกิจจริงเดียวกัน หรือมีอันหนึ่งเป็นร้านเบเกอรีโดโลเรสอีกร้านในอีกเมืองหนึ่ง

ข้อมูลที่มีโครงสร้างให้ทางลัดแก่ผู้ช่วย คุณสมบัติของ schema.org ที่ชื่อ sameAs ช่วยให้โดโลเรสใส่ URL ของ Instagram, Facebook และ Yelp ของเธอไว้ในมาร์กอัป Organization บนเว็บไซต์ของเธอเองได้โดยตรง เท่ากับเป็นคำยืนยันที่เครื่องอ่านได้ ในคำพูดของเธอเอง ว่าบัญชีเหล่านี้เป็นของเธอ schema.org นั่นเป็นสัญญาณที่หนักแน่นกว่าการที่ผู้ช่วยอนุมานความตรงกันเอาเองจากชื่อและที่อยู่ที่คล้ายกันตามแหล่งข้อมูลซึ่งมันไม่ได้เชื่อถือเต็มร้อย เพราะนี่คือโดโลเรสเองที่รับรองความเชื่อมโยงนั้น ในรูปแบบที่ไม่มีอะไรอ่านผิดได้

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

ตัวอย่าง JSON-LD ที่คัดลอกไปปรับใช้ได้ในสัปดาห์นี้

คุณไม่จำเป็นต้องมีนักพัฒนามาเขียนสิ่งนี้ตั้งแต่ต้น คุณแค่ต้องกรอกแม่แบบให้ครบ บล็อก JSON-LD สำหรับธุรกิจท้องถิ่นจะอยู่ในแท็ก script เพียงแท็กเดียว กำกับชนิดไว้ว่า application/ld+json และเริ่มด้วยบรรทัดที่ประกาศคำศัพท์ของมันว่าเป็นบริบทของ schema.org ภายในนั้นตั้งชนิดเป็น LocalBusiness ตามด้วยช่อง name ที่ใส่ชื่อธุรกิจของคุณแบบตรงตัว และช่อง image ที่ชี้ไปยังโลโก้ของคุณ

ถัดมาคือที่อยู่ ซึ่งเขียนเป็นออบเจ็กต์ซ้อนของตัวเองชนิด PostalAddress แล้วแตกออกเป็น streetAddress, addressLocality (เมืองของคุณ), addressRegion (รัฐหรือจังหวัดของคุณ) และ postalCode รวมเป็นสี่ช่องที่มีป้ายกำกับแยกกัน แทนที่จะเป็นข้อความบรรทัดเดียว เพราะแบบนี้ต่างหากที่ทำให้ผู้ช่วยตอบได้ว่า "ที่นี่อยู่ใกล้ฉันไหม" โดยไม่อ่านรหัสไปรษณีย์เป็นเลขห้อง จากนั้นเป็นช่อง telephone และช่อง priceRange (ง่าย ๆ แค่ "$" สำหรับราคาระดับกลางก็พอ) ส่วนช่อง openingHoursSpecification จะระบุวันและเวลาของคุณในรูปแบบที่มีโครงสร้างแทนการเขียนเป็นประโยค เพื่อไม่ให้ "ปิดวันอาทิตย์" ถูกอ่านเป็น "ปิดวันจันทร์" สุดท้ายช่อง sameAs เก็บชุด URL ไว้ ทั้ง Instagram ของคุณ หน้า Facebook ของคุณ รายการบน Yelp ของคุณ และโปรไฟล์อื่นใดที่เป็นของคุณอย่างไม่ต้องสงสัย

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

อะไรที่ข้ามไปได้

ไม่ใช่ทุกชนิดของ schema.org ที่คุ้มค่าเวลาคุณ และการไล่ทำให้ครบทุกอย่างก็เปลืองแรงที่ควรเอาไปลงกับสี่แบบข้างต้นมากกว่า

• มาร์กอัป BreadcrumbList ซึ่งอธิบายโครงสร้างโฟลเดอร์ของเว็บไซต์คุณ (หน้าแรก > เมนู > เค้ก) ช่วยให้ผลการค้นหาแบบดั้งเดิมแสดงเส้นทางนำทางได้ก็จริง แต่ไม่ได้บอกอะไรผู้ช่วยเลยเกี่ยวกับข้อเท็จจริงของธุรกิจคุณ ให้ข้ามไป เว้นแต่คุณมีมันติดมาจากงานเก่าอยู่แล้ว
• AggregateRating ที่ไม่มีรีวิวจริงรองรับ แนวทางเรื่องข้อมูลที่มีโครงสร้างของ Google ห้ามมาร์กอัปที่บิดเบือนคะแนนซึ่งคุณไม่ได้มีจริงไว้อย่างชัดเจน Google Search Central และการที่ผู้ช่วยไปพูดซ้ำคะแนนที่ปั่นขึ้นมาโดยคุณพิสูจน์ไม่ได้ ก็เป็นความเสี่ยงด้านชื่อเสียง ไม่ใช่ชัยชนะ
• มาร์กอัปที่ซ้อนกันลึกหรือทำซ้ำในทุกหน้า ตัวตนแบบ Organization ของคุณต้องประกาศให้ชัดเพียงครั้งเดียวก็พอ ซึ่งปกติคือบนหน้าแรก การไปทำซ้ำอย่างไม่สอดคล้องกันในหลายสิบหน้าจะสร้างเวอร์ชันที่ขัดกันเองให้ผู้ช่วยต้องมานั่งปะติดปะต่อ ซึ่งแย่กว่าการประกาศครั้งเดียวให้ถูกต้อง
• ชนิดข้อมูลของ schema.org ที่เพิ่งเกิดใหม่และแทบไม่มีใครรองรับ ตัวคำศัพท์เองก็ระบุชนิดไว้หลายร้อยแบบที่สร้างมาเพื่อการใช้งานแคบ ๆ อย่างสูตรอาหารหรือสนามบิน schema.org ถ้าชนิดใดไม่ได้อยู่ในไม่กี่แบบที่มีเอกสารระบุว่าเสิร์ชเอนจินและผู้ช่วยใช้จริง ป้ายกำกับนั้นก็ไม่ได้ทำอะไรให้คุณในวันนี้

วิธีตรวจว่าข้อมูลที่มีโครงสร้างของคุณทำงานจริง

การใส่โค้ดเป็นแค่ครึ่งหนึ่งของงาน ส่วนอีกครึ่งคือการยืนยันว่ามันอ่านได้ เครื่องมือ Rich Results Test ที่ Google ให้ใช้ฟรีเปิดให้คุณวาง URL ของหน้าเว็บหรือตัวโค้ดเองลงไป แล้วดูได้เลยว่ามันตรวจพบชนิดใดบ้างและช่องใดขาดหายไป Google การรันมันทุกครั้งหลังแก้ไขจะจับข้อผิดพลาดจากการพิมพ์ได้ เพราะจุลภาคที่หายไปตัวเดียวทำให้ทั้งบล็อกพังเงียบ ๆ ได้ และจับได้ก่อนที่มันจะทำให้คุณเสียอะไรไป

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

FAQ