บทนำ
บางครั้งปัญหา SEO ไม่ได้เริ่มจากบทความไม่ดี หรือ เว็บไซต์โหลดช้า แต่อาจเริ่มจาก “ตัวอักษรไม่กี่ตัวในโค้ด” ที่ Google อ่านไม่เหมือนเดิมอีกต่อไป
เมื่อวันที่ 21 สิงหาคม 2569 Search Engine Roundtable รายงานว่า Google ปรับวิธีที่ Googlebot อ่าน และ ถอด HTML escape จาก JSON-LD โดยจะทำเพียงหนึ่งรอบ ทำให้ข้อมูลที่ถูก Escape ซ้อนและเคยอาศัยการแก้ไขอัตโนมัติจากระบบ อาจไม่ถูกตีความแบบเดิมอีกต่อไป
สำหรับธุรกิจไทย เรื่องนี้จึงไม่ใช่เพียงข่าวของทีม SEO แต่เป็นสัญญาณว่า เว็บไซต์ที่พึ่งพาโค้ดสำเร็จรูปโดยไม่เคยตรวจสอบ อาจมี “ปัญหาทางเทคนิค” ซ่อนอยู่โดยไม่รู้ตัว
ข้อเท็จจริง: Google เปลี่ยนตรงไหน
ประเด็นอยู่ที่ JSON-LD ซึ่งเป็นรูปแบบที่เว็บไซต์ใช้บอก Google ว่าเนื้อหาบนหน้านั้น คืออะไร เช่น ข้อมูลสินค้า รีวิว สูตรอาหาร หรือคำถามที่พบบ่อย
Search Engine Roundtable รายงานโดยอ้างข้อมูลจาก Google และ Gary Illyes ว่า Google ปรับกระบวนการดึง JSON-LD ให้สอดคล้องกับมาตรฐาน JSON มากขึ้น และเปลี่ยนเป็นการทำ HTML unescaping เพียงหนึ่งครั้ง แทนพฤติกรรมเดิมที่อาจช่วยจัดการกรณี Escape ซ้อนบางรูปแบบได้
Google ยังชี้ไปที่ RFC 8259 มาตรา 7 สำหรับหลักการ Escape ของข้อความใน JSON โดยมาตรฐานดังกล่าวกำหนดรูปแบบอักขระที่จำเป็นต้อง Escape และรูปแบบ Unicode Escape ที่สามารถใช้ได้ พูดให้ง่ายที่สุดคือ
เมื่อก่อนโค้ดบางแบบอาจใช้ได้ เพราะระบบช่วยตีความให้ แต่ตอนนี้เว็บไซต์ไม่ควรฝากความหวังไว้กับการแก้โค้ดให้จาก Google
และนี่คือจุดที่เจ้าของเว็บไซต์ควรสนใจ เพราะปัญหา ไม่ได้หมายความว่า Google จะ “ลงโทษเว็บไซต์” โดยอัตโนมัติ แต่หมายความว่า Structured Data ที่เขียนไม่ถูกต้องอาจทำงานไม่ตรงตามที่ผู้สร้างตั้งใจ ขณะที่ Google ระบุเองว่าการมี Structured Data เป็นเพียงการเพิ่มโอกาสให้เกิด Rich Results ไม่ใช่การรับประกันว่าจะได้แสดงผลรูปแบบพิเศษทุกครั้ง
Google แนะนำให้ตรวจ Structured Data ระหว่างการพัฒนาและหลังนำขึ้นเว็บไซต์ โดยใช้ Rich Results Test และติดตามสถานะหลัง Deploy ด้วยเครื่องมือของ Google
ผลกระทบต่อธุรกิจในประเทศไทย
ลองนึกภาพบริษัทไทยแห่งหนึ่งที่ทำเว็บไซต์มาหลายปี ใช้ WordPress มี Plugin SEO อยู่สองสามตัว และให้เอเจนซีช่วยติดตั้ง Schema ตั้งแต่วันแรก ทุกอย่างดูเรียบร้อย หน้าเว็บขึ้น Google ตามปกติ ไม่มีใครแตะโค้ด JSON-LD เพราะทุกคนคิดว่า “ปลั๊กอินจัดการให้หมดแล้ว”
ปัญหาคือ สิ่งที่ทำงานมานาน ไม่ได้แปลว่าสิ่งนั้นถูกต้องตามมาตรฐานเสมอไป
การเปลี่ยนแปลงของ Google ครั้งนี้จึงทำให้เรื่องที่เคยเป็นปัญหาของ Developer กลายเป็นปัญหาของฝ่ายธุรกิจด้วย เพราะ Structured Data เป็นส่วนหนึ่งของระบบที่ช่วยให้ Search Engine เข้าใจเนื้อหาของเว็บไซต์ และอาจเชื่อมโยงกับโอกาสในการแสดงผลแบบ Rich Result
สำหรับ SME ความเสี่ยง คือ การพึ่ง Plugin หรือ Freelancer โดยไม่มีขั้นตอนตรวจสอบ เมื่อเกิดปัญหาจะไม่รู้ว่าเป็นปัญหาที่ Content, SEO, Theme, Plugin หรือโค้ด Structured Data
สำหรับองค์กรขนาดใหญ่ ความเสี่ยงกลับซับซ้อนกว่า เพราะเว็บไซต์หนึ่งแห่งอาจมีหลายทีมสร้างหน้าเว็บ หลาย Template และหลายระบบสร้าง JSON-LD หาก Template กลางผิดเพียงจุดเดียว ปัญหาอาจกระจายไปหลายร้อยหรือ หลายพันหน้า
ที่สำคัญคือ ความเสียหายอาจมองไม่เห็นทันที หน้าเว็บยังเปิดได้
บทความยังอ่านได้ Google ยัง Crawl ได้ Search Ranking อาจยังไม่ได้ตกทันที แต่ Structured Data อาจไม่ได้ถูกตีความตามที่ธุรกิจคาดหวัง
นี่ทำให้ประเด็นนี้ควรถูกมองในฐานะ Technical Debt หรือ “หนี้ทางเทคนิค” มากกว่าเรื่อง SEO เล็กๆ เพราะองค์กรจำนวนมากมีโค้ดเก่าที่สร้างโดย Plugin, Theme, Developer รุ่นก่อน หรือ Vendor ภายนอก แต่ไม่มีเจ้าของที่รับผิดชอบตรวจสอบอย่างต่อเนื่อง
สำหรับบริษัทที่กำลังทำ AEO/GEO หรือ เตรียมเว็บไซต์ให้เหมาะกับการค้นหายุค AI เรื่องนี้ยิ่งสำคัญขึ้นอีก เพราะการทำให้เครื่องเข้าใจเนื้อหา ไม่ควรถูกมองเป็นเพียงขั้นตอนติด Schema แล้วจบ แต่ควรเป็นกระบวนการตรวจสอบคุณภาพของข้อมูลที่เว็บไซต์กำลังส่งออกไป
พูดง่ายๆ คือ เว็บไซต์ไม่ได้มีแค่ “สิ่งที่คนอ่านเห็น” แต่ยังมี “สิ่งที่เครื่องอ่าน” และสองส่วนนี้ต้องถูกต้องพร้อมกัน
ดังนั้น สิ่งที่ธุรกิจไทยควรถาม Vendor หรือทีม SEO ไม่ใช่เพียงว่า “เว็บเรามี Schema หรือยัง?” แต่ควรถามว่า
“Schema ที่เรามีอยู่ตอนนี้ยังถูกต้องจริงหรือแค่ยังไม่เคยมีใครตรวจ?”
สิ่งที่ควรทำต่อ
1. ตรวจหน้าสำคัญก่อน ไม่ต้องเริ่มทั้งเว็บไซต์
เลือกหน้าที่มีมูลค่าทางธุรกิจสูง เช่น หน้า Service, Product, บทความหลัก และ Landing Page แล้วนำไปตรวจด้วย Google Rich Results Test
2. ตรวจ JSON-LD ที่สร้างโดย Plugin และ Template กลาง
อย่าตรวจเฉพาะหน้าต้นทาง เพราะ Plugin หรือ Template เดียวกันอาจถูกนำไปใช้กับหลายร้อยหน้า หากต้นเหตุอยู่ที่ระบบสร้าง Schema ควรแก้ที่ต้นทาง
3. อย่าถามแค่ว่า “มี Error หรือไม่”
ควรถามต่อว่า JSON-LD ถูกสร้างตามมาตรฐาน JSON หรือไม่ โดยเฉพาะจุดที่เกี่ยวกับการ Escape ตัวอักษร เพราะมาตรฐาน RFC 8259 กำหนดวิธีการ Escape ของ JSON ไว้อย่างชัดเจน
4. ตรวจหลัง Deploy ไม่ใช่ตรวจครั้งเดียวแล้วจบ
Google แนะนำให้ตรวจ Structured Data ในช่วงพัฒนาและติดตามหลังนำขึ้นจริง เพราะปัญหาอาจเกิดจาก Template หรือระบบที่ใช้แสดงผลหลัง Deploy ได้
5. กำหนดเจ้าของ Structured Data ให้ชัด
เว็บไซต์องค์กรควรระบุว่าใครรับผิดชอบเรื่องนี้ระหว่าง SEO, Developer, Content หรือ Vendor ภายนอก เพราะเมื่อเกิดปัญหา “ทุกคนคิดว่าอีกทีมดูอยู่” คือจุดที่ทำให้ Technical Debt อยู่ได้นานที่สุด
มุมมองผู้เชี่ยวชาญ
“เรื่องนี้ผมมองว่าไม่ใช่ข่าว SEO เล็กๆ เลยครับ เพราะ มันกำลังบอกเราว่า Google จะไม่ช่วยแก้โค้ดที่เราเขียนผิดไปตลอด ถ้าองค์กรใช้ Plugin ทำ Schema ก็ไม่ได้แปลว่า เราจบหน้าที่แล้ว เราต้องตรวจด้วยว่าโค้ดที่ถูกสร้างออกมานั้นถูกจริงหรือเปล่า ผมชอบคิดง่ายๆ ว่า คนอ่านเว็บไซต์ต้องเข้าใจ และ เครื่องก็ต้องเข้าใจด้วย เพราะ ตอนนี้เราไม่ได้ทำเว็บเพื่อ Google อย่างเดียวแล้ว แต่กำลังทำเว็บเพื่อ Search และ AI ที่จะเข้ามาอ่านข้อมูลของเราด้วย ดังนั้น อย่ารอให้ Traffic หายก่อนค่อยตรวจครับ ตรวจตอนที่เว็บยังทำงานปกติ จะถูกกว่าและง่ายกว่ามาก”
— Phuwara Krobtaku —
LL.M. (IP & IT) | M.S. (IT) | Thai Barrister & Attorney-at-Law
แหล่งอ้างอิง
Search Engine Roundtable — รายงานการเปลี่ยนแปลงวิธีที่ Googlebot อ่าน JSON-LD และการทำ HTML unescaping หนึ่งรอบ
อ่านข่าวต้นฉบับจาก Search Engine Roundtable
Google Search Central — แนวทางเกี่ยวกับ Structured Data และการตรวจสอบด้วย Rich Results Test
Google Search Central — General Structured Data Guidelines — Structured Data ช่วยให้เกิด Rich Results ได้ แต่ไม่ได้รับประกันว่าจะแสดงผลทุกครั้ง และ Google แนะนำให้ตรวจด้วย Rich Results Test และ URL Inspection
RFC Editor — RFC 8259 — มาตรฐาน JSON และหลักการ Escape ในมาตรา 7
