คำอธิบาย JSON-LD สำหรับเว็บไซต์ส่วนตัว

 (hawksley.dev)
2 คะแนน โดย GN⁺ 8 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แม้แต่เว็บไซต์ส่วนตัวก็สามารถใส่ structured data ได้ เพื่อให้ครอว์เลอร์เข้าใจความสัมพันธ์ระหว่างหน้า บุคคล และบทความได้ดีขึ้น พร้อมช่วยปรับปรุงคุณภาพของลิงก์พรีวิวและการแสดงผลบนการค้นหา
  • การติดตั้งทำได้โดยกำหนด @context เป็น Schema.org ภายใน <script type="application/ld+json"> ที่อยู่ใน <head> แล้ววางโหนดอย่าง WebSite, Person, BlogPosting ไว้ใน @graph
  • หากใช้ @id เดียวกัน เว็บครอว์เลอร์สามารถรวมพร็อพเพอร์ตีของโหนดจากหลายหน้าเข้าด้วยกันได้ แต่สแครปเปอร์หรือ LLM ที่อ่านเพียงหน้าเดียวจะไม่รวมให้ ซึ่งเป็นความแตกต่างที่ต้องคำนึงถึง
  • ในหน้ารากควรมี WebSite, ProfilePage, Person เป็นพื้นฐาน ส่วนหน้าบล็อก โปรเจกต์ หรือหน้ารายการ สามารถเพิ่ม Blog, BlogPosting, SoftwareApplication, CollectionPage, BreadcrumbList ให้เหมาะกับลักษณะของหน้า
  • ฟิลด์อย่าง sameAs ของ Person, breadcrumb ของหน้า, และ image·license·วันที่ของบทความ ถูกนำไปใช้โดยตรงในการระบุตัวบุคคล เส้นทางในผลการค้นหา พรีวิวบทความ เงื่อนไขการใช้งาน และการประเมินความใหม่ของเนื้อหา

บทบาทและโครงสร้างพื้นฐานของ JSON-LD

  • JSON-LD ย่อมาจาก JSON Linked Data เป็นรูปแบบสำหรับเพิ่ม structured data ให้กับเว็บเพจ
  • ช่วยให้ครอว์เลอร์เข้าใจ โครงสร้างเชิงความหมาย ของเว็บไซต์ และอาจช่วยให้ได้ลิงก์พรีวิวที่สมบูรณ์ขึ้น รวมถึงมีส่วนช่วยปรับปรุงอันดับการค้นหา
  • เมื่อต้องการเพิ่มลงในหน้า ให้ใส่สคริปต์ในส่วน <head> ในรูปแบบต่อไปนี้
    • <script type="application/ld+json"> เป็นการประกาศ MIME type เป็น application/ld+json
    • เมื่อกำหนด type นี้แล้ว JavaScript engine ของเบราว์เซอร์จะไม่รันมัน
    • ครอว์เลอร์เฉพาะทางอย่าง Googlebot จะค้นหาองค์ประกอบนี้แล้วพาร์สเนื้อหาภายใน

@context, @graph, และ ID ของโหนด

  • @context ใช้ระบุ บริบท ที่ข้อมูล JSON-LD นี้ยึดตาม โดยเว็บครอว์เลอร์ใช้ Schema.org เป็นมาตรฐาน
  • Schema.org กำหนดคู่คีย์-ค่าที่ใช้ได้ใน JSON
  • เอกสาร JSON-LD สามารถมองเป็นกราฟมีทิศทางที่มีป้ายกำกับ และข้อมูลจะถูกเก็บไว้ใต้ @graph
  • ภายในกราฟมีได้หลายโหนด และโหนดเหล่านั้นเชื่อมต่อกันด้วยลิงก์ที่มีทิศทาง
  • แต่ละโหนดประกอบด้วยองค์ประกอบต่อไปนี้
    • @type: ระบุว่าโหนดคืออะไร เช่น WebSite, SoftwareApplication
    • @id: ตัวระบุของโหนด ซึ่งโดยทั่วไปมักเป็น URL ที่ต่อด้วยค่าแฮชเฉพาะท้ายสุด
    • พร็อพเพอร์ตี: คู่คีย์-ค่าที่แสดงคุณลักษณะของโหนด
  • เว็บครอว์เลอร์สามารถรวมพร็อพเพอร์ตีของโหนดที่ใช้ @id เดียวกันข้ามหลายหน้าได้
  • แต่สแครปเปอร์หรือ LLM ที่อ่านเพียงหน้าเดียวจะไม่รวมพร็อพเพอร์ตีเหล่านี้ ดังนั้นหากนำ JSON-LD ชุดเดียวกันไปใช้ซ้ำหลายหน้า ควรคำนึงถึงความต่างนี้
  • แนะนำให้ใช้ @id โดยต่อแฮชท้าย URL เพื่อระบุโหนดอย่างชัดเจน เช่น #website

โหนดที่ใช้อธิบายเว็บไซต์และหน้าเว็บ

  • WebSite

    • WebSite เก็บ เมทาดาทา ของเว็บไซต์ และช่วยให้ครอว์เลอร์ตัดสินใจได้ว่าจะนำเว็บไซต์ไปแสดงอย่างไร
    • ในหน้ารากสามารถใส่เวอร์ชันแบบละเอียดที่มีพร็อพเพอร์ตีอย่าง url, name, alternateName, description, inLanguage, publisher, image
    • ไม่จำเป็นต้องใส่โหนด WebSite แบบเต็มในทุกหน้า
    • หน้ารากของโดเมนควรเขียนแบบละเอียด ส่วนหน้าอื่นใช้เวอร์ชันย่อที่มีเพียง @type, @id, url, name ก็เพียงพอ
    • เวอร์ชันย่อช่วยให้ครอว์เลอร์ที่อ่านเพียงหน้าเดียวมีบริบทพอที่จะระบุชื่อเว็บไซต์ได้ถูกต้อง

  • WebPage

    • WebPage หมายถึงหน้าปัจจุบันเอง หรือก็คือ หน้า HTML ทางกายภาพ
    • ควรแยกจากประเภทคอนเทนต์อย่าง BlogPosting โดย WebPage ชี้ไปที่หน้าที่บรรจุคอนเทนต์นั้น
    • ตัวอย่างพร็อพเพอร์ตี ได้แก่ url, isPartOf, name, inLanguage, breadcrumb
    • ProfilePage, CollectionPage เป็นชนิดย่อยที่เฉพาะเจาะจงกว่าของ WebPage
    • ชนิดย่อยที่พบไม่บ่อยกว่านี้สามารถดูได้ใน คำจำกัดความ WebPage ของ Schema.org

การระบุตัวบุคคลและหน้าโปรไฟล์

  • Person

    • แนะนำให้ใส่โหนด Person ไว้ในทุกหน้าของเว็บไซต์ส่วนตัว
    • Person ใช้แสดงว่าเจ้าของเว็บไซต์คือใคร และถูกใช้เป็นส่วนหนึ่งของตัวชี้วัดคุณภาพคอนเทนต์ของ Google
    • ครอว์เลอร์ของ LLM ก็ใช้ข้อมูล Person มากขึ้นเรื่อย ๆ เพื่อพิจารณาว่าควรอ้างถึงใครในคำตอบ
    • ต่างจาก WebSite, Person เป็นบริบทสำคัญมากพอที่จะใส่ไว้ในทุกหน้า
    • พร็อพเพอร์ตีที่สำคัญมีดังนี้
      • url: ชี้ไปที่หน้ารากเพื่อยึดโหนดนี้ไว้
      • name, givenName, familyName: แสดงชื่อให้ชัดเจน
      • image: ถ้าเป็นไปได้ควรใช้รูปเจ้าตัวหรือโลโก้ที่เกี่ยวข้องเพื่อเชื่อมภาพทางการ
      • sameAs: ช่วยบอกครอว์เลอร์เกี่ยวกับโปรไฟล์อื่น ๆ เพื่อช่วยระบุตัวบุคคล
    • sameAs มีประโยชน์มากเป็นพิเศษในการ แยกคนชื่อซ้ำ และใช้สร้างการแสดงผลแบบ knowledge graph ข้ามหลายหน้า
    • พร็อพเพอร์ตีอื่นของ Person มีประโยชน์ในการเพิ่มรายละเอียด แต่ไม่ใช่สิ่งจำเป็น และตัดทอนลงได้โดยมีผลกระทบน้อย

  • ProfilePage

    • ProfilePage ใช้แทนหน้าภายในเว็บไซต์ที่เกี่ยวกับบุคคลใดบุคคลหนึ่ง
    • หากหน้าแรกใช้แนะนำตัวเองก็สามารถใช้กับหน้าแรกได้ แต่ถ้ามีหน้า about แยกต่างหากก็อาจเหมาะกว่าที่จะใส่ไว้ตรงนั้น
    • สิ่งสำคัญคือเชื่อมกับโหนด WebSite ที่กว้างกว่าด้วย isPartOf
    • mainEntity ใช้บอกครอว์เลอร์ว่าหน้านี้เกี่ยวกับใคร
    • dateCreated, dateModified มีประโยชน์ในฐานะ สัญญาณความใหม่ สำหรับครอว์เลอร์ แต่ถ้าเว็บไซต์ให้ข้อมูลนี้ได้ไม่สะดวกก็ไม่ต้องกังวลมาก

โปรเจกต์และการแสดงเส้นทาง

  • SoftwareApplication

    • หากหน้าเว็บใช้แนะนำซอฟต์แวร์ ก็ควรใส่เมทาดาทาของซอฟต์แวร์นั้นด้วยโหนด SoftwareApplication
    • หากต้องการแบบเฉพาะเจาะจงกว่า สามารถใช้ MobileApplication, WebApplication, VideoGame ได้
    • พร็อพเพอร์ตี url ควรชี้ไปยังตำแหน่งที่โปรเจกต์ถูกเผยแพร่
    • ตัวอย่างเช่นหน้าเผยแพร่อย่าง crates.io
    • sameAs ใช้กับหน้าอื่นที่เชื่อมกับโปรเจกต์ เช่นที่เก็บซอร์สโค้ด
    • ค่าที่ใช้ได้ของ applicationCategory ดูได้จาก คำจำกัดความ SoftwareApplication ของ Google
    • แม้จะเป็นโปรเจกต์ FOSS ก็ควรใส่ offers และตั้งราคาเป็น 0

  • BreadcrumbList

    • BreadcrumbList มีประโยชน์อย่างกว้างขวางกับทุกหน้าที่ยกเว้นหน้าราก
    • มันแสดง เส้นทางการจัดหมวดหมู่ ของหน้า และไม่จำเป็นต้องตรงกับเส้นทาง URL จริงเสมอไป
    • สามารถใช้ควบคุมวิธีที่เสิร์ชเอนจินแสดงเส้นทางของหน้าหนึ่ง ๆ ได้
    • หากเส้นทางของเว็บไซต์สั้นอยู่แล้ว ประโยชน์ของโหนดนี้ก็มีไม่มากและอาจละได้
    • แต่สำหรับเว็บไซต์ที่มีเส้นทางยาว BreadcrumbList มีประโยชน์ในการทำให้เส้นทางในผลค้นหาสั้นลง

หน้ารายการ บล็อก และหน้าบทความ

  • CollectionPage

    • CollectionPage เป็นชนิดย่อยของ WebPage ที่ใช้หลัก ๆ กับหน้าที่รวบรวมรายการ
    • ตัวอย่างเช่นหน้า /elsewhere/ ที่รวมโปรไฟล์อื่น ๆ หรือหน้า /blog/ ที่เป็นรายการบทความบล็อก
    • สามารถใช้ about เพื่อเชื่อมกับโหนด Person ที่เกี่ยวข้อง
    • breadcrumb ต้องเชื่อมกับ BreadcrumbList ที่ถูกต้องของหน้าปัจจุบันเสมอ

  • Blog

    • ควรเพิ่มโหนด Blog ในหน้า index หรือหน้าแรกของบล็อก
    • มันทำหน้าที่เป็น โหนดกลาง ระหว่าง WebSite กับ BlogPosting แต่ละชิ้น
    • dateModified มีประโยชน์ในฐานะสัญญาณความใหม่ แต่หากให้ข้อมูลนี้ได้ไม่ง่ายก็ละไว้ได้
    • license ช่วยให้ครอว์เลอร์ทราบว่าสามารถใช้บทความภายใต้เงื่อนไขใด
    • ในเว็บไซต์ส่วนตัวสามารถตั้ง publisher เป็น Person แทน Organization ได้
    • เอกสารของ Google ต่างจากในอดีตตรงที่ตอนนี้ยอมรับ Person เป็นค่าที่ใช้ได้ และอาจแม่นยำกว่าสำหรับเว็บไซต์ส่วนตัว

  • BlogPosting

    • BlogPosting ควรใส่ในทุกบทความบล็อกที่เผยแพร่แล้ว
    • มันให้ข้อมูลเพิ่มเติมเพื่อให้ครอว์เลอร์นำเสนอบทความได้แม่นยำขึ้น
    • สามารถใช้เพื่อช่วยจัดวางตำแหน่งในผลค้นหาได้แม่นยำขึ้น และแสดงรายละเอียดที่สมบูรณ์ยิ่งขึ้น
    • ในเว็บไซต์ส่วนตัว author และ publisher จะชี้ไปยังโหนด Person เดียวกันก็ได้
    • พร็อพเพอร์ตี image ควรตรงกับ ภาพ OG ที่ใช้ในลิงก์พรีวิวของบทความอยู่แล้ว
    • license สามารถใช้เพื่อระบุเงื่อนไขการใช้งานของบทความ

การติดตั้งขั้นต่ำและเกณฑ์การนำไปใช้

  • JSON-LD ที่จำเป็นสำหรับเว็บไซต์ส่วนตัวสามารถเลือกจัดองค์ประกอบได้ตามลักษณะของแต่ละหน้า
  • แม้จะเป็นเว็บไซต์สแตติกที่ไม่มีขั้นตอน build ก็ยังได้ประโยชน์จากการเพิ่มโหนดขั้นต่ำต่อไปนี้ในหน้าราก
    • WebSite
    • ProfilePage
    • Person
  • หากมีบล็อก ก็สามารถเพิ่ม Blog และ BlogPosting ได้ และสำหรับหน้ารายการบทความหรือหน้ารวมโปรไฟล์ภายนอกสามารถใช้ CollectionPage ได้
  • สำหรับหน้าแนะนำโปรเจกต์สามารถพิจารณา SoftwareApplication และสำหรับหน้าที่ไม่ใช่หน้ารากสามารถพิจารณา BreadcrumbList ได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 8 시간 전
ความเห็นจาก Hacker News

  • ถ้าจะเปรียบเทียบ มันให้ความรู้สึกเหมือน ไปรบในสงครามครั้งเก่าอีกครั้ง
    ในมุมของเว็บไซต์ WWW ของฉัน ตอนนี้ Google แทนที่จะส่งคนไปยังบทความจริงของฉัน กลับแสดง สรุปที่สร้างโดย LLM แบบยาวและปนข้อผิดพลาดไว้ด้านบน
    การได้ชื่อแสดงผลสวย ๆ แทน ‘breadcrumb’ หรือโดเมน ไม่ได้แก้ปัญหาความจริงที่ว่า Google ลดความสำคัญของสิ่งเหล่านี้ลงอยู่ดี ไม่ว่าจะแต่งมันให้ดูดีหรือไม่ก็ตาม
    มันเหมือนทุ่มแรงมากเกินไปกับสิ่งที่คนที่เข้ามายังเว็บไซต์จริงจะไม่มีวันเห็น และคนที่ใช้ Google ก็หาแทบไม่เจอเพราะถูกกดลงไปอยู่ใต้เวอร์ชันที่ถูกทำให้เป็น LLM ของตัว Google เอง

    • ถ้าคุณอยากได้โลกที่ข้อมูลแบบนี้มีความหมายจริง ก็ต้อง หว่านเมล็ดก่อน
      ต่อให้ Google ไม่ใช้ ถ้าทั้งอินเทอร์เน็ตนำเมทาดาทาแบบนี้ไปใช้กันอย่างแพร่หลาย ก็จะกลายเป็นพื้นดินที่ดีให้คู่แข่งที่ไม่ต้องพึ่งการสแครปด้วย LLM สร้างทางเลือกขึ้นมาได้
      ถ้ายอมสยบต่อ Google ก็มีแต่จะยิ่งเสริมอำนาจครอบงำ เพิ่มกำแพงการเข้าสู่ตลาดของคู่แข่ง และบีบให้พวกเขาต้องใช้เทคโนโลยีแบบเดียวกันด้วย
    • จริงมาก บริษัทเราตอนนี้ก็ขึ้นใน Google Search แบบนี้แล้ว:
      $STATE บริษัทไอทีที่เชี่ยวชาญการสร้างเวิร์กโฟลว์ AI เชิงปฏิบัติและโซลูชันการจัดการข้อมูลสำหรับธุรกิจในแถบมิดเวสต์ ดำเนินงานด้วยโมเดลสัญญาราคาคงที่ที่คล่องตัว และมุ่งเน้นการส่งมอบผลลัพธ์ที่เป็นรูปธรรมโดยหลีกเลี่ยงความเทอะทะแบบองค์กรขนาดใหญ่
      ไม่ยักรู้มาก่อนว่าเดี๋ยวนี้พวกเราให้บริการ เวิร์กโฟลว์ AI เชิงปฏิบัติ แล้ว
      แล้วยังเอาชื่อคู่แข่งที่คล้ายกันแต่คนละเจ้ามาปนกันอีก แถมตั้งฉันเป็นผู้บริหารด้วย อย่างน้อยข้อดีคือคู่แข่งซ่อนข้อมูลติดต่อไว้หลังฟอร์ม “จองคำปรึกษา” เลยกลายเป็นว่าแสดงแต่ข้อมูลติดต่อของเรา
    • ตอนนี้ฉันไม่อนุญาตให้ Google ครอลและทำดัชนี เว็บไซต์ของฉันแล้ว
    • ตอนนี้ Google ก็ถูกรวมอยู่ในกลุ่มที่ “ถ้าบอตเข้ามาในเว็บ จะได้รับ 10GB zipbomb” แล้ว
      ตอนนี้มันไม่ได้เพิ่มคุณค่าอะไร มีแต่สร้างปัญหาเพิ่ม
    • ใช่เลย หลายปีมานี้ฉันใส่ แท็กและแอตทริบิวต์ microdata เต็มเว็บไซต์ หวังว่าจะช่วยดึงทราฟฟิกมา
      สุดท้ายก็มีแต่ช่วยฝึก AI ของ Google เพื่อให้คนไม่ต้องออกจาก Google เท่านั้นเอง

  • ถ้ามองแบบใช้งานจริง ผมแนะนำให้อ่านเอกสารของ Google สำหรับเว็บไซต์เรื่อง JSON-LD
    https://developers.google.com/search/docs/appearance/structu...
    คุณจะเห็นด้วยว่าข้อมูลจำนวนมากเกี่ยวข้องกับเว็บไซต์บางประเภทเท่านั้น Rotten Tomatoes สามารถเผยแพร่คะแนนนักวิจารณ์หนังด้วย JSON-LD ได้ แต่ถึงผมจะเขียนรีวิวหนังก็ไม่ได้เกี่ยวอะไรกับผมมากนัก
    JSON-LD ใช้งานง่าย และเครื่องมือค้นหาก็ใช้มันจริง จึงถือว่าโอเค แม้มันจะทำให้ข้อมูลในหน้าเว็บซ้ำกันได้ แต่ผมมองว่าความฝันที่จะใส่คำอธิบายประกอบอย่างสมบูรณ์แบบจนข้อมูลปรากฏในเอกสารเพียงครั้งเดียวอย่างแม่นยำนั้น เป็นอุดมคติพอ ๆ กับวัวทรงกลมและเชือกไร้มวล
    การทำเว็บเพจต้องใช้แรงคน และผลลัพธ์สุดท้ายจะมีข้อมูลซ้ำอยู่บ้างก็ไม่เป็นไร

    • ต่อให้ไม่ใช่เว็บไซต์ใหญ่ ก็ใช้ JSON-LD กับรีวิวหนังได้
      ในเว็บไซต์ของฉัน ฉันใช้กับรีวิวหนังสือ เกม และภาพยนตร์ และดูเหมือนเครื่องมือค้นหาส่วนใหญ่จะแสดงข้อมูลอย่างคะแนนดาวด้วย
    • 403. That’s an error.
      ขึ้นว่าฝั่งไคลเอนต์ไม่มีสิทธิ์เข้าถึง URL /search/docs/appearance/structured-data/intro-structured-data บนเซิร์ฟเวอร์นี้
    • แต่การทำข้อมูลซ้ำจะเพิ่ม การใช้น้ำ นะ /s

  • สำหรับพรีวิวลิงก์แบบสมบูรณ์ OpenGraph ได้รับการรองรับบ่อยกว่า JSON-LD มาก
    ถ้าจุดประสงค์คือทำ SEO ประเภทของ JSON-LD ที่เสิร์ชเอนจินรองรับนั้นเฉพาะเจาะจงและมีข้อจำกัดมาก ทางที่ดีกว่าคือดูเอกสารของเสิร์ชเอนจินเป้าหมายโดยตรง เช่น Google[1] หรือ Bing[2] แล้วทำตามนั้นเลย นอกเหนือจากนั้นแทบจะเป็นการเสียเวลา
    นอกเหนือจากกรณีของเสิร์ชเอนจินแล้ว ถ้าไม่มีจุดประสงค์เฉพาะ JSON-LD ก็มักไม่มีประโยชน์อะไรนัก ถ้ามีความต้องการที่ชัดเจนว่าต้องใช้ JSON-LD ก็ใส่ข้อมูลที่มีประโยชน์กับกรณีนั้นไป แต่ถ้าใส่ข้อมูลอื่น ๆ นอกเหนือจากนั้นก็แทบไม่ต่างจากการตะโกนใส่ความว่างเปล่า
    IndieWeb[3] ใช้ข้อมูลแบบมีโครงสร้างเหมือนกัน แต่เห็นว่า JSON-LD ขัดกับหลัก DRY จึงใช้ Microformats[4] แทน
    0: https://ogp.me
    1: https://developers.google.com/search/docs/appearance/structu...
    2: https://www.bing.com/webmasters/help/marking-up-your-site-wi...
    3: https://indieweb.org/
    4: https://microformats.org/

  • สิ่งที่อยากให้ทุกเว็บไซต์ทำจริง ๆ คือข้อมูลแบบมีโครงสร้างที่ใช้ คำศัพท์ของ Schema.org
    JSON-LD เป็นหนึ่งในวิธีทำแบบนั้น และยังมี RDFa กับ Microdata ด้วย
    ตอนเริ่มเรียนรู้ ผมอ้างอิงบทความนี้และคิดว่าน่าแนะนำ: https://neilpatel.com/blog/get-started-using-schema/
    จะดูได้ว่าจะเพิ่มข้อมูลอะไรบ้างด้วยเครื่องมือนี้: https://technicalseo.com/tools/schema-markup-generator/
    ดูรายการทั้งหมดได้ที่เว็บ schema.org: https://schema.org/docs/schemas.html

  • เมื่อหลายปีก่อน ผมเพิ่งรู้ว่า ฟีเจอร์อีเมลแบบหวือหวา อย่างการแทรกตั๋วเครื่องบินหรือการแสดงข้อมูลติดตามพัสดุ ล้วนทำด้วย JSON-LD ภายในอีเมล
    แต่เท่าที่ผมรู้ มีแค่ Gmail ที่รองรับ
    ข้อมูลเพิ่มเติม: https://www.emailonacid.com/blog/article/email-development/s...

    • Outlook และ iCloud ก็รองรับ บางฟีเจอร์ อย่างตั๋วหรือการจองเช่นกัน

  • สงสัยว่าคุณสมบัติเหล่านี้ช่วยเรื่อง การแสดงผลบนการค้นหา ได้จริงไหม หรือแค่ช่วยให้เสิร์ชเอนจินกักผู้ใช้อยู่บนหน้าผลการค้นหาได้ง่ายขึ้น

    • หลังเพิ่ม JSON-LD แล้ว Google ก็เริ่มแสดง ลิงก์ย่อย ที่เข้าไปยังส่วนต่าง ๆ ในเว็บไซต์ของผม อันนั้นก็โอเคอยู่
    • ถ้าเป็นเว็บไซต์ธุรกิจ JSON-LD อาจใช้ส่งข้อมูลให้แพลตฟอร์มแผนที่ได้
      เช่น ที่อยู่ เวลาทำการ เบอร์โทร เมนู เป็นต้น

  • ทั้งที่มี semantic HTML อยู่แล้ว แต่แปลกดีที่เรายังต้องมาใส่ความหมายของเว็บไซต์ซ้ำอีกครั้งด้วย JSON แปลก ๆ แบบกำหนดเองในแท็ก script ที่เบราว์เซอร์ไม่ประมวลผล

    • ผมเคยใช้ JSON-LD บนเว็บไซต์ตัวเอง และมองว่ามันตอบโจทย์คนละอย่างกับ semantic HTML
      semantic HTML ใช้กำหนดสิ่งที่เบราว์เซอร์ประมวลผล เช่น ชื่อเรื่องและหัวข้อ ส่วนข้อมูล JSON-LD คือ metadata อย่างวันที่สร้าง วันที่แก้ไข แท็ก ผู้เขียน
      สิ่งเหล่านี้จะแสดงใน HTML ด้วย microdata ก็ได้ แต่ JSON-LD ง่ายกว่า ผมเลยเลิกใช้ microdata
      ผมเติม JSON-LD จากข้อมูลชุดเดียวกับที่ใช้สร้างเว็บไซต์ และยังใช้ metadata นี้ทำหน้าดัชนีอย่างรายการโพสต์บล็อกปี 2024 หรือบทความทั้งหมดเกี่ยวกับหัวข้อ X ด้วย ผู้ใช้หลักของ JSON-LD คือเสิร์ชเอนจิน
      ถ้าอยากหงุดหงิดมากขึ้น ก็ลองนึกดูว่ายังต้องใส่ metadata ของ OpenGraph ลงในหน้าเดียวกันอีกด้วย เท่ากับว่ามี metadata คนละรูปแบบสองชุดอยู่ในหน้าเดียวกัน
    • มี Microdata ด้วย และถ้าผมจำไม่ผิด มันรองรับคำศัพท์เดียวกับ JSON-LD schema.org เป็นแหล่งข้อมูลที่ดี
      แต่ JSON-LD กลายเป็นค่าเริ่มต้นมาพักใหญ่แล้ว คล้ายกับที่เราส่วนใหญ่เลิกใช้ REST แล้วหันไปใช้ RPC ผมก็ไม่แน่ใจว่าตัว parser สำคัญ ๆ ทุกวันนี้ยังรองรับ microdata ครบหรือเปล่า และโดยเฉพาะเวลาทำเว็บให้ลูกค้าอย่างเว็บอีคอมเมิร์ซที่อยากได้การแสดงผลบน Google ผมก็ใช้ LD เป็นค่าเริ่มต้นมาตลอด
      และเมื่อเทียบกับ semantic HTML ก็มีประเด็นที่ควรสังเกต semantic HTML ช่วยนิยามโครงสร้างของมาร์กอัป แต่ไม่ได้สื่อถึง บริบทของโลกจริง ระดับว่า “นี่คือสินค้าที่กำลังขาย” หรือ “นี่คือตารางเวลาเดินรถไฟ”
    • ผมคิดว่าคุณอาจยังเข้าใจบทความไม่ครบ
      คุณใช้ออนโทโลยีอย่าง Schema.org/FOAF/WikiData ภายใน HTML ได้ โดยไม่ต้องใช้ JSON-LD และแท็ก script
    • ในโลกอุดมคติ ผมคิดว่าเซิร์ฟเวอร์กับเบราว์เซอร์ควรทำ content negotiation กันได้ โดยให้เบราว์เซอร์ร้องขอเฉพาะ JSON-LD จากเว็บไซต์ก่อน แล้วใช้รูปแบบตัวเรนเดอร์ภายในของตัวเอง
    • semantic HTML ไม่ได้ครอบคลุมขอบเขตเดียวกับ microformats อื่น ๆ ที่ JSON-LD จัดการ
      แค่จากตัวอย่างในบทความ ก็ต้องถามแล้วว่าองค์ประกอบเชิงความหมายสำหรับคน รายการ breadcrumb ซอฟต์แวร์แอปพลิเคชัน บล็อก และโพสต์บล็อก คืออะไร
      semantic HTML มีไว้เพื่อช่วยให้คนที่ใช้ screen reader นำทางผ่านองค์ประกอบทั่วไปอย่าง “navigation” หรือ “article” ได้

  • นี่มันก็แค่ OpenGraph ที่เขียนเป็น JSON ไม่ใช่เหรอ? ข้อดีคืออะไร?

  • หลังปี 2024 ทราฟฟิกของ หน้า content-based marketing ของเราลดลงไปราว 85%
    สิ่งที่ผมไม่เข้าใจคือ เมื่อหน้าผลการค้นหาแบบ zero-click เพิ่มขึ้น Google เองก็น่าจะโดนกระทบหนักเหมือนกันไม่ใช่หรือ
    รายได้โฆษณาบนหน้าผลการค้นหาที่อิงจากการคลิกก็น่าจะลดลงรุนแรงในระดับใกล้เคียงกัน แต่ผมหาตัวเลขสาธารณะที่ใช้หักล้างหรือยืนยันสมมติฐานนี้ไม่ได้

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