เวลาแชร์บทความ เรามักคาดหวังว่าปลายทางจะแสดงชื่อ คำโปรย และภาพปกให้คนตัดสินใจเปิดอ่านได้ แต่บางครั้งเปิดหน้าเว็บเองก็เห็นทุกอย่างครบ พอนำลิงก์ไปวางกลับมีแค่ URL หรือมีรูปเก่าที่เปลี่ยนไปแล้ว
สิ่งที่บริการสร้างตัวอย่างลิงก์อ่านอาจต่างจากสิ่งที่ browser ของเราแสดงหลังโหลดเสร็จ เพราะมันต้องขอ HTML เพื่อหาข้อมูลของหน้า แล้วค่อยไปขอรูปจาก URL ที่หน้านั้นระบุไว้ หากจุดใดเข้าถึงไม่ได้หรือได้ข้อมูลไม่ตรงกัน ก็เกิดอาการที่คนเปิดเองไม่เจอได้
การตรวจจึงควรเริ่มจากทางที่บริการนั้นเข้ามาอ่านครับ แยกว่ารับ HTML อะไร พบ metadata ชุดไหน และโหลดรูปได้หรือไม่ ก่อนจะสรุปว่าเป็นเพราะขนาดภาพหรือรอให้ cache เปลี่ยนอย่างเดียว
หน้าเว็บอาจแสดงภาพผ่าน component ของแอป ขณะที่ข้อมูลสำหรับตัวอย่างลิงก์ระบุอยู่ใน head ของ HTML อีกส่วนหนึ่ง การเปลี่ยนภาพบนหน้าจอจึงอาจยังไม่เปลี่ยน URL ที่ใช้ใน metadata หากระบบสร้างข้อมูลสองจุดจากคนละ field หรือมีค่าเริ่มต้นค้างอยู่
Open Graph ใช้ meta tags เพื่อระบุข้อมูลของวัตถุที่หน้าเป็นตัวแทน โดยกลุ่มพื้นฐานมีชื่อ ประเภท URL และภาพ ส่วนคำอธิบายกับรายละเอียดภาพเป็นข้อมูลเพิ่มเติมที่ช่วยบอกความหมายของหน้าและไฟล์ที่เกี่ยวข้องได้
ตัวอย่างด้านล่างเป็น HTML สมมติสำหรับหน้าบทความ ไม่ใช่ผลที่ตรวจพบจากเว็บใด โดย URL ต้องเปลี่ยนเป็นหน้ากับภาพที่เผยแพร่จริงก่อนนำไปใช้งาน
<meta property="og:title" content="จัดชื่อ topic เมื่อมีหลายอุปกรณ์" />
<meta property="og:type" content="article" />
<meta property="og:url" content="https://example.com/content/topic-plan" />
<meta property="og:description" content="เริ่มจากขอบเขตอุปกรณ์และข้อมูลที่ต้องส่ง ก่อนจัดชื่อให้ตามงานได้" />
<meta property="og:image" content="https://example.com/images/topic-plan-v2.jpg" />
<meta property="og:image:type" content="image/jpeg" />
<meta property="og:image:alt" content="แผนผัง topic แยกอุปกรณ์กับชนิดข้อความ" />
รายละเอียดอย่างความกว้างและความสูงควรตรงกับไฟล์จริง หากมีหลายรูปต้องดูความสัมพันธ์ของ tag ประกอบรูปด้วย และระวัง layout ส่วนกลางใส่ภาพเริ่มต้นมาซ้ำกับข้อมูลของบทความ ลำดับที่ผิดอาจทำให้บริการเลือกสิ่งที่เราไม่ได้ตั้งใจไว้
เริ่มจาก URL ที่แชร์จริงรวมทั้งรูปแบบ host และ path แล้วดูว่ามี redirect ไปที่ใดบ้าง ก่อนอ่าน metadata จาก response ปลายทาง หากระบบเปลี่ยนไปหน้าเข้าสู่ระบบ หน้าตรวจสอบการเข้าถึง หรือหน้าข้อผิดพลาด ก็ต้องจัดการสาเหตุนั้นก่อน เพราะบริการอาจไม่เคยได้รับหน้าบทความเลย
การเห็น metadata ใน DOM หลัง browser ทำงานเสร็จ ช่วยบอกสถานะหน้าที่เรากำลังดู แต่ยังไม่ยืนยันว่ามีข้อมูลเดียวกันอยู่ใน HTML ที่บริการ preview ได้รับ หากเว็บเติม tag ด้วย JavaScript ภายหลัง ต้องตรวจความสามารถของบริการเป้าหมาย ไม่สมมติว่าทุกเจ้ารันแอปได้เหมือน browser ของเรา
ควรตรวจทั้ง status และเนื้อหา เพราะบางระบบส่งหน้า error พร้อมสถานะ 200 ได้ ในทางกลับกันบางหน้า redirect หลายทอดก่อนถึงบทความจริง การไล่เส้นทางให้เห็นช่วยแยกปัญหา URL ออกจากปัญหา tag โดยไม่ต้องเดาจากหน้าตาการ์ดที่ปลายทางอย่างเดียว
ถ้าทางผู้ดูแลเห็นข้อมูลใหม่แต่ทางสาธารณะยังเก่า ให้ตรวจ cache ของ HTML และการสร้าง metadata ร่วมกับเนื้อหา บางระบบอาจอ่านข้อมูลคนละรอบจนชื่อเรื่องอัปเดตแล้วแต่ภาพใน head ยังเป็นฉบับก่อนหน้าอยู่
ภาพที่แสดงใน browser อาจเคยถูกโหลดไว้แล้ว หรือ browser ส่ง cookie ที่มีสิทธิ์อ่านไฟล์ไปให้ จึงควรขอ URL รูปตรงจากบริบทสาธารณะเพื่อตรวจว่าได้ไฟล์ภาพจริง ไม่ใช่หน้าเข้าสู่ระบบหรือข้อความปฏิเสธการเข้าถึงที่หน้าตาคล้าย response ปกติ
ต้องดูชนิดไฟล์ที่ตอบกลับกับข้อมูลไฟล์จริงด้วย การตั้งนามสกุลเป็น jpg ไม่ได้ทำให้เนื้อหาข้างในเป็น JPEG และการตอบ Content-Type เป็น text/html ก็อาจหมายถึงกำลังส่งหน้าอื่นมาแทนภาพ หากมีการแปลงรูปตาม header ของผู้เรียก ต้องตรวจว่าบริการเป้าหมายได้รับชนิดที่รองรับได้จริง
URL ที่มีลายเซ็นหมดอายุเร็วไม่เหมาะจะใช้เป็นตัวอ้างอิงสาธารณะระยะยาวโดยไม่คิดแผนต่อ เพราะบริการอาจกลับมาขอภายหลังจากที่ลิงก์นั้นใช้ไม่ได้แล้ว ส่วนไฟล์ที่ต้องป้องกันไว้ก็ไม่ควรถูกเปิดสาธารณะเพียงเพื่อให้ preview แสดง ต้องเลือกภาพอีกชุดที่ตั้งใจเผยแพร่ได้
ด้านขนาดและสัดส่วนควรดูข้อกำหนดของบริการที่ต้องการให้แสดง ไม่มีค่าชุดเดียวที่รับรองหน้าตาเหมือนกันทุกแพลตฟอร์ม และต่อให้ไฟล์ผ่านเกณฑ์พื้นฐาน แต่ข้อความสำคัญอยู่ชิดขอบมากก็อาจถูกตัดในรูปแบบการ์ดบางชนิดได้ จึงควรตรวจภาพที่ใช้จริงร่วมด้วย
ระหว่างการแก้มีทั้ง cache ของหน้าเว็บ cache ของไฟล์รูป และข้อมูล preview ที่บริการปลายทางเก็บไว้อีกชั้น การตรวจว่าหน้าบทความส่ง URL ใหม่แล้วจึงเป็นหลักฐานของฝั่งเว็บ แต่ยังไม่ยืนยันว่าปลายทางอ่านรอบใหม่เสร็จแล้ว
ถ้าใช้ URL รูปเดิมแต่เขียนไฟล์ใหม่ทับ ผู้เรียกที่มีสำเนาเดิมอาจยังแสดงภาพเก่าได้ การตั้ง URL ตามฉบับภาพช่วยแยกไฟล์ได้ชัดกว่า แต่ metadata ของหน้าเองก็ต้องเปลี่ยนไปชี้ URL ใหม่นั้น และต้องรอหรือใช้วิธีตรวจใหม่ที่บริการรองรับจริง
บางบริการมีเครื่องมือวินิจฉัยหรือวิธีขออ่านหน้าใหม่ ควรใช้ตามเอกสารของบริการนั้นและตรวจผลที่รายงาน ไม่สรุปจากการเติม query สุ่มลงลิงก์ว่าคือวิธีแก้ถาวร เพราะวิธีนั้นอาจสร้าง URL ของหน้าเพิ่มและไม่ได้จัดการต้นเหตุเรื่องฉบับข้อมูล
ถ้าแค่บางบริการไม่แสดง ก็ต้องแยกดูนโยบายการอ่าน ข้อจำกัดไฟล์ และผลตรวจของเจ้านั้น การที่แพลตฟอร์มหนึ่งแสดงครบเป็นข้อมูลเปรียบเทียบที่มีประโยชน์ แต่ไม่ใช่หลักฐานว่าทุกปลายทางควรอ่านได้เหมือนกันทันที
เริ่มบันทึก URL ที่แชร์ เวลาที่ตรวจ และบริการที่เห็นปัญหา จากนั้นเก็บ status กับ metadata ของหน้า และ status กับชนิดไฟล์รูป โดยระวังไม่เก็บข้อมูล session ส่วนตัวไปด้วย ข้อมูลชุดนี้ช่วยแยกอาการได้ว่าไม่ได้รับหน้า ไม่พบภาพ หรือพบแล้วแต่ยังแสดงฉบับเก่า
หลังแก้ควรตรวจหน้ารายละเอียดและ HTML สาธารณะอีกครั้ง รวมถึงภาพจาก URL ที่ metadata อ้างถึง หากต้องแสดงหลักฐานผล preview จริง ก็ค่อยเก็บภาพจากบริการนั้นโดยระบุเวลาให้ชัด ไม่ทำภาพการ์ดขึ้นเองแล้วใช้แทนผลที่ปลายทางแสดง
การเพิ่ม Open Graph เป็นการเตรียมข้อมูลให้บริการอ่าน ไม่ใช่คำสั่งบังคับหน้าตาการ์ดทุกที่ จึงควรรับรองเฉพาะสิ่งที่เว็บส่งออกกับผลที่ตรวจได้ และปล่อยพื้นที่ให้แต่ละแพลตฟอร์มมีวิธีแสดงตามระบบของตัวเอง
ภาพตัวอย่างลิงก์ต้องผ่านทั้งการอ่าน HTML การเลือก metadata และการโหลดไฟล์ภาพ การไล่ตามเส้นทางนี้ช่วยให้แก้ตรงจุดที่ขาดได้ เมื่อข้อมูลใน head สอดคล้องกับหน้าบทความและภาพเข้าถึงได้จริงแล้ว จึงค่อยตรวจการอ่านใหม่กับ cache ของบริการปลายทางต่อ โดยไม่เอาสิ่งที่ browser ของเราเห็นไปแทนทุกขั้นของการสร้าง preview