สรุปสั้น ๆ (TL;DR)
- Google ระบุบน LinkedIn ว่าได้เปลี่ยนวิธีดึงข้อมูล JSON-LD และตอนนี้ใช้การถอดรหัส HTML เพียงรอบเดียว เอนทิตีที่ถูกเอสเคปสองชั้นจึงไม่ถูกคลี่กลับอีกต่อไป
- Search Engine Roundtable รายงานเรื่องนี้เมื่อวันที่ 21 สิงหาคม 2569 โดยอ้างจากโพสต์ LinkedIn ของ Google ส่วน Gary Illyes ชี้ให้เจ้าของเว็บไปดู RFC 8259 หัวข้อ 7 เรื่องการเอสเคปที่ถูกต้อง
- Google ขอให้เจ้าของเว็บไซต์เปลี่ยนโค้ดไปใช้เอสเคปมาตรฐานของ JSON หรือ Unicode hexadecimal escapes ส่วนเอนทิตีที่เอสเคปชั้นเดียวยังทำงานได้ เพราะระบบยังถอดรหัสให้หนึ่งรอบ
- Google ไม่ได้ให้วันบังคับใช้ ไม่มีช่วงผ่อนผัน ไม่มีตัวเลขว่ากระทบกี่เว็บไซต์ และไม่ได้บอกว่า Search Console จะแจ้งเตือนคนที่โครงสร้างข้อมูลพังหรือไม่
- สิทธิ์การได้ rich results หมดลงได้โดยไม่มีข้อความแจ้งเตือนถึงเจ้าของเว็บไซต์ การเปิดซอร์สดิบไปตรวจตอนนี้จึงคุ้มกว่าการรอรายงาน
ตอนนี้ Googlebot ใช้การถอดรหัส HTML เพียงรอบเดียวในการดึงข้อมูล JSON-LD ออกจากหน้าเว็บ และโครงสร้างข้อมูลที่ต้องพึ่งการถอดรหัสรอบที่สองจะหยุดทำงาน Google ประกาศการเปลี่ยนแปลงนี้ผ่านโพสต์บน LinkedIn โดยเขียนว่า "To bring our parser up to JSON and other standards, we changed our JSON-LD extraction and are now only applying a single pass of HTML unescaping." Search Engine Roundtable รายงานเรื่องนี้เมื่อวันที่ 21 สิงหาคม 2569 โดยอ้างอิงจากโพสต์บน LinkedIn ฉบับดังกล่าว อ่านรายงานต้นทางได้ที่ Search Engine Roundtable ผลในทางปฏิบัติคือมาร์กอัปที่เคยถูกพาร์เซอร์ของ Google ซ่อมให้ จะถูกอ่านตามตัวอักษรจริง และความเสียหายจะเกิดขึ้นแบบเงียบ ๆ
Google อธิบายผลที่ตามมาไว้ในโพสต์เดียวกันว่า "Practically speaking, this means that double-escaped entities (like & or ✔) will no longer be unrolled. If you're using JSON-LD for structured data, be sure to update your code to standard JSON escapes or Unicode hexadecimal escapes (like \u0026)." ส่วน Gary Illyes จาก Google เสริมโดยชี้ไปที่ตัวมาตรฐานว่า "If you're wondering what *proper* escaping is in JSON, I have good news for you! It's very, very well defined in RFC 8259, specifically section 7."
Googlebot อ่านอะไร และทำไมการเอสเคปถึงสำคัญ
Google ใช้สคริปต์ชนิด application/ld+json ในการอ่านรายละเอียดของเอนทิตีบนหน้าเว็บ ทั้งราคาสินค้า ดาวรีวิว ส่วนผสมของสูตรอาหาร และคำถามที่พบบ่อย แล้วแปลงข้อมูลเหล่านั้นเป็นผลการค้นหาแบบ rich results บล็อกนี้คือเอกสาร JSON ที่วางอยู่ภายในเอกสาร HTML อีกที ซึ่งเป็นที่มาของการเอสเคปสองชั้น ตัวดึงข้อมูลต้องตัดสินใจก่อนว่าจะจัดการกับข้อความระหว่างแท็กสคริปต์เปิดกับปิดอย่างไร ก่อนจะส่งต่อให้ตัวพาร์ส JSON
ภายใต้พฤติกรรมเดิม ข้อความนั้นถูกถอดรหัส HTML มากกว่าหนึ่งรอบ ค่าที่ถูกเอสเคปไว้สองชั้นจึงถูกคลี่กลับมาเป็นตัวอักษรที่ผู้เขียนตั้งใจ ภายใต้พฤติกรรมใหม่ ระบบถอดรหัสหนึ่งรอบแล้วส่งผลลัพธ์ต่อไปตามที่ได้ ทุกอย่างที่รอดจากการถอดรหัสหนึ่งรอบยังทำงานเหมือนเดิม ส่วนทุกอย่างที่ต้องใช้สองรอบจะไปถึงตัวพาร์สพร้อมกับข้อความเอนทิตีที่กลายเป็นตัวอักษรจริง
ผลลัพธ์ที่ถูกเอสเคปสองชั้นมาจากไหน
ส่วนนี้เป็นคำอธิบายเชิงเทคนิค ไม่ใช่สิ่งที่ Google เขียนไว้ และเป็นส่วนที่ควรเอาไปตรวจกับระบบของตัวเอง การเอสเคปสองชั้นแทบไม่เคยเกิดจากการพิมพ์ด้วยมือ มันเกิดจากชั้นเทมเพลต
ลำดับที่พบบ่อยเป็นแบบนี้ ค่าตัวหนึ่ง สมมติว่าเป็นชื่อสินค้าที่มีเครื่องหมายแอมเปอร์แซนด์อยู่ ถูกแปลงเป็น JSON อย่างถูกต้อง จากนั้นสตริง JSON ถูกส่งต่อให้เทมเพลตที่ทำหน้าที่เขียนมันลงหน้าเว็บ เทมเพลตตัวนั้นเอสเคป HTML ให้กับทุกอย่างที่มันพิมพ์ออกมา เพราะนั่นคือสิ่งที่เอนจินเทมเพลตแบบ auto-escaping ถูกสร้างมาให้ทำ และมันไม่รู้ว่าบล็อกนี้เป็นเพย์โหลด JSON ไม่ใช่ข้อความบนหน้าเว็บ แอมเปอร์แซนด์จึงกลายเป็นเอนทิตี HTML และถ้าค่าตัวนั้นเคยถูกเอสเคป HTML มาแล้วหนึ่งรอบก่อนถูกแปลงเป็น JSON ซึ่งเกิดขึ้นเมื่อเนื้อหาถูกเก็บในฐานข้อมูลในรูปที่เอสเคปไว้แล้วหรือผ่านตัว sanitiser มาก่อน การเอสเคปรอบใหม่ก็จะไปทับของเดิม และเอนทิตีนั้นก็ถูกเอสเคปเป็นชั้นที่สอง
อีกเรื่องที่ควรรู้ เพราะมันอธิบายว่าทำไมรูปแบบนี้เปราะมาตั้งแต่ต้น เนื้อหาภายในอิลิเมนต์สคริปต์ของ HTML เป็นข้อความดิบ ตัวพาร์ส HTML ไม่ถอดรหัสการอ้างอิงตัวอักษรที่อยู่ข้างในเลย สำหรับเบราว์เซอร์ เอนทิตี HTML ที่เขียนอยู่ในบล็อก JSON-LD ก็คือชุดตัวอักษรตามตัวอักษรนั้นเท่านั้น การที่ Google ยังถอดรหัส HTML ให้หนึ่งรอบจึงผ่อนปรนกว่าการอ่านมาร์กอัปตามมาตรฐานเสียอีก การเปลี่ยนแปลงครั้งนี้แค่ลดความผ่อนปรนลง ไม่ได้ตัดทิ้งทั้งหมด
RFC 8259 หัวข้อ 7 ระบุอะไรไว้จริง ๆ
Illyes ชี้ไปที่ตัวมาตรฐานแทนที่จะชี้ไปที่เอกสารของ Google จึงควรบอกให้ชัดว่าหัวข้อ 7 ของ RFC 8259 ครอบคลุมอะไร ส่วนนี้เป็นเนื้อหาของมาตรฐาน ไม่ใช่กฎของ Google
หัวข้อ 7 นิยามสตริงใน JSON สตริงคือลำดับของจุดรหัส Unicode ที่ครอบด้วยเครื่องหมายอัญประกาศ จุดรหัสใดก็ตามวางอยู่ภายในอัญประกาศได้ตามปกติ ยกเว้นสามกลุ่ม คือเครื่องหมายอัญประกาศเอง เครื่องหมายทับกลับหลัง และตัวอักษรควบคุมตั้งแต่ U+0000 ถึง U+001F ทั้งสามกลุ่มนี้ต้องถูกเอสเคป
กลไกการเอสเคปมีสองรูปแบบ แบบแรกคือชุดตัวอักษรสองตัวที่ขึ้นต้นด้วยทับกลับหลัง ครอบคลุมอัญประกาศ ทับกลับหลัง ทับหน้า backspace form feed line feed carriage return และแท็บ แบบที่สองคือรูปหกตัวอักษร ได้แก่ ทับกลับหลัง ตามด้วยตัวอักษร u และเลขฐานสิบหกสี่หลักที่ระบุจุดรหัส ซึ่งคือสิ่งที่ Google เรียกว่า Unicode hexadecimal escapes ส่วนจุดรหัสที่อยู่เหนือ Basic Multilingual Plane เขียนเป็นคู่ของรูปหกตัวอักษรนี้ในรูปแบบ UTF-16 surrogate pair
สังเกตสิ่งที่ไม่อยู่ในรายการนั้น แอมเปอร์แซนด์ไม่ต้องเอสเคปใน JSON ตัวอักษรที่มีเครื่องหมายกำกับเสียง ตัวอักษรไทย และสัญลักษณ์สกุลเงินก็ไม่ต้องเช่นกัน สาเหตุที่ JSON-LD จำนวนมากบนเว็บเต็มไปด้วยเอนทิตี HTML จึงไม่ใช่เพราะ JSON เรียกร้องมัน แต่เพราะชั้น HTML เป็นคนใส่มันเข้าไป
สตริงเดียวกัน ก่อนและหลังการเปลี่ยนแปลง
ตารางด้านล่างไล่กฎการถอดรหัสรอบเดียวกับตัวอย่างสองตัวที่ Google ยกมา บวกกับรูปแบบที่ Google แนะนำ ตารางนี้เป็นผลที่ตามมาจากคำอธิบายของ Google ไม่ใช่ตารางที่ Google เผยแพร่เอง จึงควรอ่านที่กลไกมากกว่าที่ตัวอักษรแต่ละตัว
| สิ่งที่อยู่ในซอร์สดิบของหน้าเว็บ | ค่าที่ถูกดึงออกมาก่อนเปลี่ยน | ค่าที่ถูกดึงออกมาตอนนี้ |
|---|---|---|
| เอนทิตี HTML ชั้นเดียว เช่น & | & | & |
| เอนทิตีที่ถูกเอสเคปซ้ำอีกชั้น เช่น & | & | & |
| การอ้างอิงเชิงตัวเลขที่ถูกเอสเคปสองชั้น เช่น ✔ | ตัวอักษรเครื่องหมายถูก | ✔ |
| Unicode hexadecimal escape ของ JSON คือ \u0026 | & | & |
| แอมเปอร์แซนด์ดิบที่ไม่ได้เอสเคปเลย | & | & |
มันพังอย่างไร และทำไมไม่มีใครมาบอก
ความเสียหายมีสองรูปแบบ และมองเห็นได้ไม่เท่ากัน แบบที่เบากว่าคือ JSON ยังพาร์สผ่าน แต่ค่าที่ได้ผิด ชื่อสินค้าแสดงผลโดยมีข้อความเอนทิตีปนอยู่ข้างใน สตริงราคามีตัวอักษรที่ไม่ใช่ตัวเลขติดมา คำตอบในส่วนคำถามที่พบบ่อยมีเศษมาร์กอัปคาอยู่กลางประโยค มาร์กอัปยังถูกต้องตามรูปแบบ แต่ข้อมูลผิด หน้าเว็บยังมีโครงสร้างข้อมูลอยู่ ขณะที่สูญเสียความถูกต้องซึ่งเป็นเงื่อนไขของการได้ rich results
แบบที่หนักกว่าคือ JSON พาร์สไม่ผ่านเลย และทุกเอนทิตีที่อธิบายไว้ในบล็อกนั้นหายไปจากสายตาของ Google พร้อมกันทั้งหมด เทมเพลตตัวเดียวที่เขียนผลลัพธ์แบบเอสเคปลงในทุกหน้าสินค้า สามารถลากโครงสร้างข้อมูลของทั้งแคตตาล็อกหายไปด้วยได้
เหตุผลที่ควรไปตรวจแทนที่จะรอ คือความเสียหายทั้งสองแบบไม่ส่งสัญญาณบอก สิทธิ์การได้ rich results หมดลงได้โดยที่ไม่มีข้อความแจ้งเตือนไปถึงเจ้าของเว็บไซต์ ไม่มีข้อความใดในโพสต์ของ Google ที่บอกว่าจะมีการแจ้งเตือน และการเสียสิทธิ์ก็ไม่เหมือนกับการถูกลงโทษหรือได้รับคำเตือน อาการที่มองเห็นได้ ถ้ามี จะมาทีหลังในรูปของดาวรีวิวหรือรายละเอียดราคาที่หายไปเงียบ ๆ จากผลการค้นหา ซึ่งเป็นความเปลี่ยนแปลงชนิดที่มักถูกจับได้ในรายงานรายเดือนมากกว่าจะรู้ตัวในวันที่มันเกิด ใครที่ดูแลงาน SEO ในประเทศไทย ให้เว็บไซต์แคตตาล็อกจึงมีเหตุผลที่จะไปดูสัปดาห์นี้ ไม่ใช่ไตรมาสหน้า
ตรวจเว็บไซต์ของตัวเองอย่างไร
ขั้นตอนด้านล่างเป็นการอธิบายกระบวนการตรวจสอบ ไม่ใช่คำสั่งจาก Google และตั้งใจให้ขั้นแรกเป็นงานมือ
เริ่มจากการตอบกลับดิบที่ตัวรวบรวมข้อมูลได้รับ ดึงซอร์สของหน้าเว็บมาตรง ๆ แทนที่จะอ่านจากหน้าต่างตรวจสอบที่แสดงผลแล้ว เพราะเครื่องมือใดก็ตามที่ถอดรหัสเอนทิตีเพื่อเอามาแสดงผล จะซ่อนตัวอักษรที่คุณกำลังตามหาพอดี หาบล็อก JSON-LD ในข้อความดิบนั้น แล้วอ่านค่าสตริงในระดับไบต์ แทนที่จะอ่านตามที่มันแสดงผล
จากนั้นค้นในซอร์สดิบหาแพตเทิร์นที่บ่งบอกว่ามีการเอสเคปชั้นที่สอง คือชุดที่ขึ้นต้นด้วยเอนทิตีแอมเปอร์แซนด์แล้วตามด้วยข้อความเอนทิตีต่อทันที และการอ้างอิงเชิงตัวเลขใดก็ตามที่แอมเปอร์แซนด์นำหน้าของมันเป็นเอนทิตีเสียเอง แค่ grep ไฟล์ที่เซฟไว้ก็พอ ถ้าเจอแพตเทิร์นใดแพตเทิร์นหนึ่งอยู่ในบล็อก JSON-LD หน้านั้นได้รับผลกระทบแน่นอน
ทดสอบหน้าที่มีปัญหาหนึ่งหน้าด้วย Rich Results Test ของ Google และด้วย Schema Markup Validator แล้วแก้ แล้วทดสอบซ้ำ เครื่องมือทั้งสองอ่านจากมาร์กอัปไม่ใช่จากดัชนี จึงบอกได้ว่าบล็อกที่แก้แล้วพาร์สผ่านหรือไม่ โพสต์ของ Google ไม่ได้อธิบายว่าเครื่องมือทั้งสองจะรายงานอะไรกับปัญหาเฉพาะกรณีนี้ จึงควรเทียบผลก่อนกับหลัง แทนที่จะไปนั่งหาข้อความแจ้งเตือนข้อความใดข้อความหนึ่ง
สุดท้าย ให้มองว่านี่เป็นปัญหาระดับเทมเพลต ไม่ใช่ปัญหาระดับหน้า โครงสร้างข้อมูลของเว็บไซต์ส่วนใหญ่ถูกสร้างจากโค้ดเส้นทางเดียว การเจอหนึ่งหน้าที่มีผลลัพธ์เอสเคปสองชั้นจึงมักแปลว่าทุกหน้าที่ออกจากเทมเพลตนั้นเป็นเหมือนกันหมด แก้ที่จุดแปลงข้อมูลครั้งเดียว ตรงจุดที่สตริง JSON ถูกเขียนลงหน้าเว็บ แล้วสุ่มตรวจตัวอย่างของเทมเพลตแต่ละชนิด ทีมที่มีรอบ การตรวจสอบ SEO ที่ไล่เก็บทั้งเว็บอยู่แล้ว เพิ่มการตรวจแพตเทิร์นเดียวกันนี้ให้ครอบคลุมทุก URL ได้เลย แทนที่จะสุ่มดูไม่กี่หน้า
สิ่งที่ Google ไม่ได้พูด
โพสต์ต้นทางสั้นมาก และคำถามที่ควรถามหลายข้อยังไม่มีคำตอบ การไล่รายการออกมาให้ครบมีประโยชน์กว่าการเดา
- ไม่มีการระบุวันบังคับใช้หรือช่วงผ่อนผัน Google อธิบายการเปลี่ยนแปลงในรูปอดีต คือเป็นสิ่งที่ทำไปแล้ว และไม่ได้ให้กรอบเวลาสำหรับแก้มาร์กอัปก่อนมันจะมีผล
- ไม่มีการเผยแพร่ตัวเลขประมาณการว่ามีเว็บไซต์กี่แห่งได้รับผลกระทบ และไม่มีการระบุสัดส่วนของหน้าเว็บหรือชนิดของมาร์กอัป
- ไม่มีรายชื่อชนิดของ rich results ที่ได้รับผลกระทบนอกเหนือจากคำเตือนกว้าง ๆ Google เอ่ยถึงราคาสินค้า ดาวรีวิว ส่วนผสมของสูตรอาหาร และคำถามที่พบบ่อย ในฐานะประเภทของรายละเอียดที่ JSON-LD บรรจุไว้ แต่ไม่ได้บอกว่าอันไหนหยุดทำงานบนเว็บไซต์ใด
- ไม่มีการบอกว่า Search Console จะแจ้งเตือนคนที่โครงสร้างข้อมูลพังหรือไม่ และไม่มีข้อความใดในโพสต์ที่พูดถึงรายงานหรือการแจ้งเตือน
- ไม่มีการพูดถึงว่ามาร์กอัปที่เคยถูกดึงไปแล้วจะถูกประเมินใหม่เมื่อไร การแก้จะสะท้อนผลเร็วแค่ไหนจึงไม่มีคำตอบจากแหล่งข่าว
รายงานของ Search Engine Roundtable อ้างอิงจากโพสต์บน LinkedIn และชี้ให้ผู้อ่านไปดูการสนทนาที่นั่น รายงานไม่ได้ระบุว่ามีการอัปเดตเอกสาร Google Search Central แยกออกมาแต่อย่างใด
เรื่องนี้มีความหมายอย่างไรกับนักการตลาดไทย
หัวข้อนี้เป็นการวิเคราะห์ ไม่ใช่สิ่งที่แหล่งข่าวระบุ เว็บไซต์ภาษาไทยเจอปัญหานี้ในเวอร์ชันที่คมกว่าเว็บไซต์ภาษาอังกฤษ และเหตุผลอยู่ที่วิธีที่ข้อความไทยเดินทางผ่านระบบเผยแพร่เนื้อหา
ตัวอักษรไทยไม่ต้องเอสเคปใน JSON มันอยู่ใน Basic Multilingual Plane ในช่วง U+0E00 ถึง U+0E7F จึงใช้เป็น UTF-8 ดิบภายในสตริง JSON ได้เลย และถ้าอยากใช้เอสเคป รูปหกตัวอักษรของ Unicode hexadecimal escape หนึ่งชุดก็ครอบคลุมได้ทีละตัวโดยไม่ต้องใช้ surrogate pair ทั้งสองรูปแบบเป็นไปตามมาตรฐาน และรอดจากการเปลี่ยนแปลงครั้งนี้ทั้งคู่
สิ่งที่ไม่รอดคือข้อความไทยที่ถูกดันผ่านชั้นเอสเคปแบบเอนทิตี HTML ระบบจัดการเนื้อหาบางตัวแปลงตัวอักษรที่ไม่ใช่ ASCII เป็นการอ้างอิงเชิงตัวเลขตอนพิมพ์ออกมา ซึ่งเปลี่ยนชื่อสินค้าภาษาไทยให้กลายเป็นชุดเอนทิตีตัวเลขยาวเหยียด ภายใต้พฤติกรรมเดิมสิ่งนั้นยังถูกคลี่กลับได้ แต่ภายใต้การดึงข้อมูลรอบเดียว การอ้างอิงเชิงตัวเลขที่แอมเปอร์แซนด์ของมันเองถูกเอสเคปไว้จะค้างอยู่ตามตัวอักษร และชื่อสินค้าภาษาไทยในโครงสร้างข้อมูลก็จะกลายเป็นชุดตัวเลขกับเครื่องหมายอัฒภาค นี่คือแพตเทิร์นที่การเปลี่ยนแปลงครั้งนี้ลงโทษ และพบได้บ่อยกว่าในระบบที่ถูกสร้างมาเพื่อให้ปลอดภัยกับข้อความไทย มากกว่าในระบบที่ปล่อย UTF-8 ออกมาตรง ๆ
วิธีตรวจก็เหมือนที่อธิบายไว้ข้างต้น เพียงแต่รันกับ URL ภาษาไทยแทนภาษาอังกฤษ และควรรันกับทั้งสองภาษาของเว็บไซต์สองภาษา เพราะสองเวอร์ชันมักเดินผ่านเส้นทางเทมเพลตคนละเส้น สำหรับทีมที่กำลังดูว่าพื้นที่ตอบคำถามด้วย AI อ่านเว็บไซต์อย่างไร บล็อกเดียวกันนี้ทำงานสองหน้าที่ เพราะข้อมูลเอนทิตีที่สะอาดและพาร์สผ่านคือชั้นที่เครื่องอ่านได้ ซึ่ง การทำ GEO ต้องพึ่ง โครงสร้างข้อมูลที่พาร์สไม่ผ่านนั้นมองไม่เห็นสำหรับทุกสิ่งที่มาอ่านมัน ไม่ใช่แค่กับ Google Search
คำถามที่พบบ่อย
ถ้าโครงสร้างข้อมูลของเราใช้งานได้อยู่แล้ว ต้องแก้อะไรไหม
ต้องแก้ก็ต่อเมื่อมาร์กอัปมีเอนทิตีที่ถูกเอสเคปสองชั้นอยู่ ซึ่งต้องเปิดซอร์สดิบดูถึงจะรู้ มาร์กอัปที่ใช้ตัวอักษรดิบ ใช้เอสเคปมาตรฐานของ JSON หรือใช้ Unicode hexadecimal escapes จะไม่ได้รับผลกระทบ และโพสต์ของ Google อธิบายการเปลี่ยนแปลงนี้ว่าเป็นการปรับพาร์เซอร์ให้เข้ากับมาตรฐาน JSON มากกว่าจะเป็นการเพิ่มข้อกำหนดใหม่ เอนทิตีที่เอสเคปชั้นเดียวยังทำงานได้ เพราะระบบยังถอดรหัสให้หนึ่งรอบ
เรื่องนี้มีผลในประเทศไทยแล้วหรือยัง
แหล่งข่าวไม่ได้บอกไว้ Google อธิบายว่าเป็นการเปลี่ยนวิธีที่ Googlebot ดึงข้อมูล JSON-LD และไม่ได้พูดถึงการทยอยปล่อยตามภูมิภาค กำหนดเวลาแยกรายตลาด หรือพฤติกรรมที่ต่างกันตามภาษา การเปลี่ยนแปลงเรื่องการดึงข้อมูลลักษณะนี้ตามปกติเป็นคุณสมบัติของตัวรวบรวมข้อมูลมากกว่าจะขึ้นกับพื้นที่ แต่ไม่มีข้อความใดในโพสต์ยืนยันเรื่องนั้น จึงควรถือว่ายังไม่มีคำตอบ
จะรู้ได้อย่างไรว่าหน้าเว็บของเราได้รับผลกระทบ
อ่านซอร์สดิบของหน้าเว็บแทนหน้าต่างตรวจสอบที่แสดงผลแล้ว หาบล็อก JSON-LD แล้วมองหาเอนทิตีแอมเปอร์แซนด์ที่ตามด้วยข้อความเอนทิตีต่อทันที จากนั้นรัน URL ที่มีปัญหาหนึ่งหน้าผ่าน Rich Results Test ของ Google และผ่าน Schema Markup Validator ทั้งก่อนและหลังแก้ Google ไม่ได้บอกว่าเครื่องมือเหล่านั้นรายงานอะไรกับกรณีนี้โดยเฉพาะ จึงควรเทียบผลสองรอบ แทนที่จะตามหาข้อความแจ้งเตือนที่ระบุชื่อไว้
Google จะแจ้งเตือนไหมถ้า rich results หยุดทำงาน
แหล่งข่าวไม่ได้บอกไว้ และไม่มีข้อความใดในโพสต์ของ Google ที่พูดถึงการแจ้งเตือนผ่าน Search Console การเสียสิทธิ์ rich results ไม่ใช่การถูกดำเนินการด้วยมือและไม่ได้สร้างคำเตือนของตัวเองขึ้นมา ซึ่งเป็นเหตุผลที่การเข้าไปตรวจเองมีค่ามากกว่าการนั่งรอรายงานในกรณีนี้
การเอสเคปที่ถูกต้องใน JSON คืออะไร
Gary Illyes ชี้ไปที่ RFC 8259 หัวข้อ 7 ซึ่งนิยามสตริงของ JSON มาตรฐานกำหนดให้เอสเคปเฉพาะเครื่องหมายอัญประกาศ เครื่องหมายทับกลับหลัง และตัวอักษรควบคุมตั้งแต่ U+0000 ถึง U+001F โดยใช้ชุดสองตัวอักษรที่ขึ้นต้นด้วยทับกลับหลัง หรือใช้รูปหกตัวอักษรที่มีเลขฐานสิบหกสี่หลัก เอนทิตี HTML ไม่ได้เป็นส่วนหนึ่งของมาตรฐานนี้ ซึ่งเป็นเหตุผลที่ Google ขอให้เปลี่ยนไปใช้เอสเคปมาตรฐานของ JSON หรือ Unicode hexadecimal escapes แทน
ถ้ามาร์กอัปสินค้า รีวิว หรือคำถามที่พบบ่อยของคุณถูกสร้างจากเทมเพลตที่ไม่ได้เปิดดูมาตั้งแต่วันที่สร้างมัน เรื่องนี้เป็นสิ่งที่ตรวจได้ถูกและรู้ช้าแล้วแพง แค่เปิดซอร์สดิบของหน้าสินค้าหน้าเดียวก็พอจะบอกได้แล้วว่าที่เหลือทั้งแคตตาล็อกต้องแก้หรือไม่







