บทความหนึ่งเรื่องอาจถูกส่งต่อด้วยลิงก์หลายหน้าตา ทั้ง URL ปกติ ลิงก์ที่ติดค่าบอกแหล่งที่มา หรือเส้นทางเก่าที่เคยใช้ ถ้าเปิดแล้วได้เนื้อหาเหมือนกัน คนอ่านอาจไม่รู้สึกต่าง แต่ระบบดูแลเว็บยังต้องรู้ว่าตั้งใจใช้ URL ใดเป็นตัวแทน
ความสัมพันธ์นี้เกี่ยวทั้งลิงก์ที่สร้างในเว็บ sitemap และ metadata ของหน้าครับ หากแต่ละจุดส่งคนละ URL เราก็ทำให้ความตั้งใจของเว็บอ่านยากขึ้น ทั้งสำหรับระบบค้นหาและคนที่ต้องตรวจปัญหาภายหลัง
Canonical เข้ามาช่วยบอกหน้าที่อยากใช้เป็นตัวแทนของเนื้อหาซ้ำหรือใกล้เคียง แต่ก่อนใส่ควรแยกก่อนว่า URL เหล่านั้นแสดงสิ่งเดียวกันจริงหรือเปล่า
ลิงก์อย่าง /content/mqtt-basics?utm_source=newsletter อาจเปิดบทความเดียวกับ URL ที่ไม่มี query โดยค่าที่เพิ่มใช้ติดตามแหล่งที่มา ในกรณีนี้เราสามารถมีนโยบายเลือก URL สะอาดเป็นหน้าหลักของบทนั้นได้
แต่ query ที่เลือกสินค้า ภาษา หรือชุดผลลัพธ์อาจทำให้เนื้อหาต่างกันจริง การลบ query ทุกตัวออกจาก canonical แบบเหมารวมจึงเสี่ยงทำให้หน้าที่มีความหมายต่างกันถูกบอกเป็นหน้าเดียวกัน ต้องรู้หน้าที่ของ parameter ก่อนสร้างกติกา
เริ่มจากทำรายการรูปแบบ URL ที่ระบบสร้างได้ แล้วจดว่าค่าใดมีผลต่อเนื้อหา ค่าใดใช้เพียงติดตาม และค่าใดเป็นเส้นทางที่ต้องเลิกใช้ การจำแนกนี้ช่วยให้เลือก canonical กับ redirect ได้ตรงงานมากกว่าตัดทุกอย่างหลังเครื่องหมายคำถามโดยอัตโนมัติ
สำหรับเว็บที่ใช้ข้อมูลใน query เพื่อปรับหน้าตาเฉพาะชั่วคราว ก็ควรถามต่อว่าความต่างนั้นควรถูกพบเป็นหน้าอิสระหรือไม่ นโยบายควรเกิดจากหน้าที่ของหน้า ไม่ใช่เพียงเพราะระบบ routing เปิด URL นั้นได้
สำหรับหน้า HTML สามารถใช้ link element ใน head เพื่อระบุ URL ที่ต้องการ เช่นตัวอย่างสมมติของบทความที่เปิดได้หลายลิงก์:
<link rel="canonical" href="https://example.com/content/mqtt-basics">
ใช้ URL แบบเต็มที่ตั้งใจให้เป็นปลายทาง และตรวจหน้าเป้าหมายด้วยว่ามีเนื้อหาที่ตรงกัน เปิดอ่านได้ และไม่ได้ชี้ต่อไปอีกหน้าหนึ่งโดยไม่จำเป็น การมี tag รูปแบบถูกแต่ชี้ผิดบทก็ยังเป็นข้อมูลผิดอยู่
หน้าหลักเองก็ควรมี canonical ที่สอดคล้องกับ URL หลักของมัน ส่วนรายการใน sitemap และลิงก์ภายในก็ควรใช้ทางเดียวกัน เพื่อไม่ให้จุดหนึ่งบอก URL สะอาดแต่อีกจุดสร้างลิงก์ติดค่าติดตามซ้ำให้ทั้งเว็บ
หากมีการตั้งผ่านทั้ง HTML กับ HTTP header ต้องระวังความขัดกันจากหลายแหล่ง การเลือกจุดรับผิดชอบที่ชัดช่วยดูแลง่ายกว่าเติมซ้ำทุกชั้นโดยไม่มีตัวตรวจว่าให้ค่าเดียวกันหรือไม่
คนที่เปิดลิงก์พร้อม query อาจยังอยู่ที่ URL นั้นหลังโหลด เพราะ canonical เป็นข้อมูลอธิบายความสัมพันธ์ให้ระบบที่อ่าน ไม่ใช่คำสั่งนำทางของเบราว์เซอร์ การคง URL ที่ใช้ติดตามบางแบบจึงสามารถเป็นการตัดสินใจแยกจากหน้าหลักที่ต้องการในผลค้นหาได้
ถ้าย้าย slug ถาวรและไม่ต้องการให้ URL เก่าเป็นทางเปิดเนื้อหาอีก ก็ควรพิจารณา redirect ที่เหมาะกับการย้ายด้วย เพื่อให้คนที่มีลิงก์เก่าถูกพาไปปลายทาง ไม่ใช้ canonical อย่างเดียวแล้วคาดว่าที่อยู่ในเบราว์เซอร์จะเปลี่ยนตาม
แต่การ redirect ควรรักษาข้อมูลที่ยังมีหน้าที่ตามนโยบาย เช่น ค่าติดตามที่ต้องใช้หรือปลายทางเฉพาะ ไม่ลบทุก parameter โดยไม่ตรวจว่าจะทำให้คนอ่านได้เนื้อหาหรือสถานะต่างจากที่กดมาหรือไม่
สำหรับหน้าที่ต้องเปิดหลายแบบต่อเพราะมีหน้าที่ด้าน UX ก็สามารถคงเส้นทางเหล่านั้นไว้และบอกความสัมพันธ์อย่างตั้งใจ ไม่จำเป็นต้องทำให้ทุก URL หายไปเพียงเพื่อให้รายการดูเรียบ หากยังมีเหตุผลใช้งานที่แยกไว้ชัด
บทความสองเรื่องที่อยู่ในหมวดเดียวกันอาจตอบคนละคำถาม เช่น MQTT retained message กับ Last Will แม้พูดถึงอุปกรณ์เดียวกัน ก็ไม่ได้หมายความว่าเป็น duplicate ที่ควรชี้ canonical ไปหน้าหมวดหรือบทใดบทหนึ่งทั้งหมด
ควรดูเนื้อหาหลักและหน้าที่ของ URL ว่าเป็นตัวแทนกันได้จริงหรือไม่ ถ้าหน้าหนึ่งมีรายละเอียดที่อีกหน้าไม่มี การเลือกชี้รวมอาจไม่ตรงกับสิ่งที่คนค้นต้องการ และไม่ได้ทำให้ความสัมพันธ์เนื้อหาชัดขึ้นตามที่หวัง
หน้าหลายภาษาก็ต้องดูต่างออกไป โดยทั่วไปควรรักษาหน้าหลักตามภาษาของเนื้อหาและอธิบายความสัมพันธ์ของคู่ภาษาให้เหมาะสม ไม่ชี้ทุกคำแปลกลับหน้าไทยเพียงเพราะเป็นเรื่องเดียวกัน
การเปลี่ยน canonical จึงควรถูกมองเป็นการเปลี่ยนข้อมูลของหน้า ไม่ใช่ช่องสำหรับเลือกหน้าไหนก็ได้ที่อยากดัน ก่อนปรับเป็นชุดควรทดสอบรูปแบบ URL หลักและกรณีพิเศษให้ครบตามสิ่งที่เว็บสร้างจริง
หลังแก้ metadata ให้ดู HTML สาธารณะว่า canonical ตรงกับที่ตั้งใจ ไม่มีค่าจาก template เก่าหรือถูก JavaScript เปลี่ยนไปอีกทาง หากมี cache ต้องตรวจฉบับที่คนภายนอกได้รับ ไม่จบที่ค่าหลังบ้าน
จากนั้นใช้ข้อมูลฉบับที่ index ใน URL Inspection ดูว่า Google เลือก canonical อะไรตามขอบเขตที่รายงานได้ การทดสอบ live ช่วยดูหน้าปัจจุบัน แต่ไม่ทำนายผลเลือก canonical ที่ระบบจะใช้ในอนาคตแทนเรา
ถ้าผลเลือกต่างจากที่ระบุ ให้ย้อนดูความตรงกันของเนื้อหา redirect sitemap และลิงก์ รวมถึงวันที่ระบบอ่านครั้งล่าสุด เพราะสิ่งที่เราระบุเป็นสัญญาณ ไม่ใช่คำรับรองว่าจะถูกเลือกเสมอในทันที
เก็บตัวอย่าง URL ที่เป็นปัญหากับการเปลี่ยนที่ทำไว้ จะช่วยให้รอบถัดไปไม่ย้อนแก้จากข้อมูลคนละฉบับ และเมื่อเพิ่มช่องทางแชร์ใหม่ก็สามารถใช้กติกาเดิมตรวจได้ว่าค่าติดตามยังไม่สร้างความหมายของหน้าให้เปลี่ยนโดยไม่ตั้งใจ
การจัดบทความที่มีหลาย URL ควรเริ่มจากรู้ว่าแต่ละส่วนของลิงก์เปลี่ยนเนื้อหาหรือเพียงบอกที่มา แล้วเลือก canonical ให้ตรงกับหน้าที่เป็นตัวแทนจริง เมื่อ metadata ลิงก์ภายใน sitemap และการย้ายเส้นทางสอดคล้องกัน เราจะสื่อความสัมพันธ์ได้ชัดขึ้น และตรวจผลเลือกของระบบค้นหาได้โดยไม่คาดว่า tag หนึ่งตัวจะบังคับทุกอย่างแทนข้อมูลส่วนอื่นครับ