Canonical Tag: คืออะไรและวิธีใช้งาน

เมื่อคุณเป็นเจ้าของหนึ่งหรือหลายเว็บไซต์ ไม่ว่าจะเน้นสินค้า บริการหรือส่วนต่างประเภท เป็นเรื่องปกติที่หลายหน้าบนแพลตฟอร์มจะคล้ายหรือเกือบเหมือนกันด้วยเหตุผลหลากหลาย สิ่งนี้พบบ่อยโดยเฉพาะใน ecommerce แต่เรายังตรวจพบในงานที่ปรึกษาของเราเกี่ยวกับแท็กบล็อกและคอนเทนต์ประเภทต่าง ๆ
ง่ายที่จะนึกภาพว่าเว็บไซต์ใดอาจประสบปัญหา duplicate content Google ลงโทษไซต์ที่มี duplicate content และไม่ต้องสงสัยว่าสิ่งนี้ส่งผลต่อการจัดอันดับในผลการค้นหา
แล้วเว็บไซต์สามารถมี duplicate content และ webmaster ไม่ต้องกังวลเรื่องการลงโทษได้อย่างไร
คำตอบอยู่ที่สิ่งที่รู้จักว่า canonical attribute หรือ canonical link ซึ่งเราจะกล่าวถึงโดยละเอียดในส่วนต่อไปนี้ ครอบคลุมคำนิยาม จุดประสงค์ ประโยชน์ วิธีใช้ เมื่อใดควรใช้และข้อเสียที่อาจเกิดขึ้นที่เกี่ยวข้องกับ canonical attribute เมื่อใช้เพื่อหลีกเลี่ยงบทลงโทษที่เป็นไปได้สำหรับ duplicate content
canonical link และ canonical attribute คืออะไร
โดยทั่วไป canonical link คือลิงก์ที่ ผ่านแท็กหรือ attribute ถูกอธิบายว่าเป็นลิงก์ "หลัก" หรือ "ต้นฉบับ" บนเว็บไซต์ ให้คุณชี้ URL ของหน้าที่มีคอนเทนต์คล้ายกันมายัง ขอบคุณสิ่งนี้ ลิงก์ถูกรับรู้เป็นเวอร์ชันที่ต้องการหรือลำดับความสำคัญโดย bot ของ Google หรืออัลกอริทึมการค้นหา
ด้วยวิธีนี้ คอนเทนต์ที่อาจถูกมองว่าซ้ำสามารถจัดการได้อย่างถูกต้องและค่อนข้างง่าย หากไม่ถูกอธิบายเป็น canonical อาจส่งผลต่อการจัดอันดับของแพลตฟอร์มและนำไปสู่บทลงโทษ สิ่งนี้สามารถเกิดขึ้นได้แม้ว่าคอนเทนต์ที่ซ้ำไม่ได้ถูกวางอย่างจงใจ แต่ปรากฏอย่างเป็นธรรมชาติและเป็น organic ผ่านการขายสินค้า ข้อเสนอบริการ ส่วนที่เกี่ยวข้องและอื่น ๆ
จากมุมมองทางเทคนิค canonical URL คือลิงก์ที่เขียนในโค้ด HTML ที่รวม canonical tag ให้ canonical attribute สิ่งนี้ทำให้เห็นเป็นที่อยู่หลักหรือต้นทางโดย bot ของ Google ตามที่กล่าวข้างต้น ป้องกันลิงก์ที่คล้ายกันไม่ให้ถือว่าซ้ำหรือ duplicated
ด้านล่างเป็นตัวอย่างที่แสดงวิธีที่เราประกาศ URL เป็น canonical หรือหลัก
<link rel="canonical" href="/en/">
ที่มาของ canonical link และประโยชน์ SEO
การใช้ canonical link เริ่มในปี 2009 เมื่อบริษัทค้นหาอินเทอร์เน็ตหลักสามแห่ง Google, Bing และ Yahoo ร่วมกันแนะนำ canonical attribute
ตามตรรกะ canonical link มีศักยภาพมากจากมุมมอง SEO เพราะช่วยให้เราหลีกเลี่ยงบทลงโทษที่กล่าวถึงข้างต้นและส่งสัญญาณ URL ที่สำคัญที่สุดของเรามายัง Google
ด้วยเหตุนี้เมื่อพูดถึง SEO ของไซต์และการใช้กลยุทธ์ที่เกี่ยวข้อง การรวม canonical link เป็นส่วนหนึ่งของแผนเสมอ โดยเฉพาะสำหรับไซต์ขนาดใหญ่ที่มี URL จำนวนมากที่อาจเหมือนกัน
วิธีทำให้ URL เป็น canonical
เมื่อคุณมีเว็บไซต์หรือกำลังในกระบวนการเพิ่มประสิทธิภาพหนึ่งและคุณพบว่า มี URL ที่คล้ายกันจำนวนมาก คุณควรเริ่มกระบวนการ canonicalization ประกอบด้วยการเลือก URL ใดดีที่สุดและให้ canonical attribute
บางครั้ง การเลือก URL ที่ดีที่สุดตรงไปตรงมา เพราะมีคอนเทนต์และโครงสร้างทางเทคนิคที่เหมาะสมที่สุด อย่างไรก็ตาม ในกรณีอื่นการเลือกอาจซับซ้อนกว่า โดยเฉพาะเมื่อหน้าคล้ายกันมากและยากที่จะแยกความแตกต่าง
ไม่ว่าในกรณีใด นี่คือคำแนะนำง่าย ดีกว่าเสมอที่จะเลือก canonical URL เมื่อคุณมีส่วนหรือหน้าที่คล้ายกัน มิฉะนั้น อาจมีผลที่ตามมาเชิงลบเกี่ยวกับการจัดอันดับและบทลงโทษที่สามารถส่งผลต่อ traffic อย่างถาวร
ในการทำให้ URL เป็น canonical ขั้นตอนแรกคือการเปรียบเทียบ URL ที่อาจคล้ายกัน สิ่งนี้พบบ่อยในไซต์ ecommerce ที่ผู้ใช้ไปถึงรายการสินค้าและบริการในวิธีที่แตกต่าง ซึ่งอาจส่งผลให้เกิด URL เช่นนี้
เนื่องจาก URL ทั้งสองมีค่าสำหรับไซต์หรือนำไปยังสินค้าหรือหน้าเดียวกัน สิ่งที่คุณต้องทำคือเลือกตัวใดในสองที่เกี่ยวข้องมากกว่า ดังนี้
-
เลือก URL ที่เกี่ยวข้องที่สุดตามผู้เข้าชม, traffic และ authority
-
เมื่อเลือกลิงก์แล้ว เพิ่ม canonical attribute จากหน้าที่ไม่ใช่ canonical ชี้ไปยังตัว canonical ควรเป็นแบบนี้
<link rel="canonical" href="https://example.com/wordpress/seo-plugin/">
สิ่งที่เราบรรลุด้วยสิ่งนี้คือบอก Google ว่า URL ใดเป็น canonicalized (ตัวที่เราปฏิบัติเป็นสำเนาของต้นฉบับ) และตัวใดเป็น canonical URL คือต้นฉบับ ลิงก์นี้วางบน URL "สำเนา" และชี้ไปยัง URL ต้นฉบับ
กล่าวอีกนัยหนึ่ง จะเป็นไปตาม scheme นี้

เมื่อใดที่ควรใช้ canonical URL
เมื่อคุณมี เว็บไซต์ที่มีหลายหน้าหรือส่วนเช่นสินค้า บริการและข้อมูลและโพสต์อื่น มีโอกาสมากที่บางหน้าและ URL จะคล้ายกันมาก ซึ่งทำให้การใช้ canonical URL แนะนำอย่างยิ่ง
อย่างไรก็ตาม ในกรณีเหล่านั้นคุณยังสามารถใช้ redirect 301 จริง แทน canonical tag สิ่งนี้ มีประโยชน์โดยเฉพาะเมื่อ redirect จะถาวร และมีการย้ายไซต์ ที่กล่าวมา ในกรณีปัญหาทางเทคนิคหรือบทลงโทษ การตั้ง canonical tag เป็นตัวเลือกถัดไปที่แนะนำที่สุดเสมอ
แม้ เป็นไปได้ที่จะใช้ canonical tag บน URL ในไซต์ต่าง ๆ เช่นคอนเทนต์ที่ถูกเผยแพร่ใหม่โดยไม่มีการแก้ไขบนแพลตฟอร์มอื่น ด้วยการอนุญาตที่เหมาะสม โดยชี้ไปยังต้นฉบับเสมอเพื่อหลีกเลี่ยงบทลงโทษ
หมายเหตุสำคัญเกี่ยวกับ rel=canonical
เพียงเพราะเราเก็บสิ่งนี้ไว้ในตอนท้ายไม่ได้ทำให้สำคัญน้อยลง เราต้องชัดเจนว่า canonical attribute เป็น SUGGESTION ต่อ Google ไม่ใช่ directive หมายความว่า Google อาจเพิกเฉยหากสัญญาณที่เราส่งบนส่วนที่เหลือของไซต์ขัดแย้งกับวิธีที่เรากำหนด
กล่าวอีกนัยหนึ่ง หากเราตั้ง canonical จาก URL A ไปยัง URL B แต่ภายในลิงก์ทั้งหมดชี้ไปยัง A และลิงก์ภายนอกก็ชี้ไปยัง A Google อาจเพิกเฉย canonical นั้นและปฏิบัติ A เป็นตัวที่ดี B จะเป็นสำเนาของ A และอาจอยู่ภายใต้บทลงโทษ
ในการค้นหา URL ใดที่ Google ปฏิบัติเป็นต้นฉบับและตัวใดเป็น canonical เราต้องไปที่ Search Console เพิ่ม URL ลงใน inspector และทบทวนข้อมูลที่ให้โดย Google Search Console
และที่นั่นเราได้รับข้อมูลต่อไปนี้

ข้อผิดพลาดที่พบบ่อยกับ canonical URL
มีปัญหาและข้อผิดพลาดที่ทำบ่อยหลายรายการที่เกี่ยวข้องกับ canonical URL ซึ่งกลายเป็นเรื่องปกติและแสดงโดยเฉพาะเมื่อเครื่องมือนี้ถูกใช้ในทางที่ผิด ตัวอย่าง
-
คุณไม่ควร canonicalize archive ที่แบ่งหน้าไปยังหน้า 1 เช่นเดียวกัน canonical tag ของหน้าควรชี้ไปยังหน้าเดียวกัน ตัวอย่าง จากหน้า 2 ไปยังหน้า 2 มิฉะนั้นเสิร์ชเอนจินอาจมีปัญหาในการจัดทำดัชนี archive ของหน้าที่ลึกกว่า
-
คุณต้องทำให้ canonical URL พิเศษและเป็นเอกลักษณ์ แม้ว่านั่นหมายถึงการเปลี่ยน protocol จาก HTTP เป็น HTTPS
-
คุณต้องอ้างอิง canonical tag บน URL ที่ต้องการ โดยไม่ใช้ตัวแปรและในแบบโดยตรง
-
เมื่อหน้ามี canonical URL ที่เกี่ยวข้องหลายตัว อาจตรงกันข้ามและคาดเดาไม่ได้ อย่าลืมว่า Google ต้องเข้าใจเว็บไซต์ของเราอย่างรวดเร็วและชัดเจน ดังนั้นเรามาทำให้ง่าย
-
ข้อผิดพลาด สำคัญอีกอย่างอาจมาจาก การใช้ canonical attribute ในส่วน body แทนที่จะเป็น /head หรือ header Google แนะนำในการสื่อสารทางการให้ใช้ attribute ใน head ให้เร็วที่สุดเพื่อหลีกเลี่ยงปัญหาเมื่อ parse คอนเทนต์ทั้งหมด เนื่องจากอาจไม่ถูกตรวจพบ
-
ใช้ noindex และ rel=canonical ร่วมกัน John Mueller กล่าวถึงสิ่งนี้โดยเฉพาะในหนึ่งในหลาย hangout อธิบายว่าทั้งสองสัญญาณขัดแย้งกันและจะทำให้ Google สับสน ซึ่งจะใช้ canonical attribute เหนือ noindex ดังนั้นเราไม่ควรใช้ร่วมกันเลย
-
ชี้ canonical attribute ไปยังหน้า 404 หรือหน้า 30x มาคิดสักครู่ หากเราเพิ่ม attribute ไปยัง URL A ชี้ไปยัง B ซึ่งคืน error หรือทำ redirect เราไม่ได้ส่งสัญญาณผิดไปยัง Google หรือ เรากำลังบอกว่า URL "ต้นฉบับ" คือหน้า error หรือ redirect ไม่สมเหตุสมผล
การใช้ canonical attribute ขั้นสูง
canonical attribute สามารถมีฟังก์ชันอื่นและการใช้ขั้นสูง เช่น
- HTTP header canonical link header ประเภทนี้สามารถมีประโยชน์มากเมื่อพูดถึงการ canonicalize เอกสาร PDF เพราะไม่ใช่ HTML เราต้องเลือกตัวเลือกนี้หากเราต้องการ canonicalize จะเป็นแบบนี้
Link: <http://www.example.com/downloads/seoguide.pdf>; rel="canonical"
-
ใช้ canonical บนหน้าที่ไม่คล้ายกันมาก จริง ๆ แล้วเป็นไปได้ที่จะใช้ canonical tag บนหน้าที่ไม่เหมือนกันจริง ๆ แม้ค่อนข้างต่างกัน ในขณะที่อาจช่วย authority โดยรวมของไซต์ ไม่แนะนำเพราะ Google สามารถตรวจพบการใช้ canonical ในทางที่ผิด ลงโทษไซต์และเพิกเฉย canonical URL จริง
-
ใช้ canonical attribute ร่วมกับ Hreflang คุณสามารถใช้กลยุทธ์ที่เกี่ยวข้องกับ Hreflang ในเวลาเดียวกับ canonical tag ด้วยผลลัพธ์ที่ดีหากใช้อย่างเหมาะสม อย่างไรก็ตาม คุณต้องชัดเจนมากว่าเมื่อใช้ Hreflang การใช้ภาษาของ canonical ต้องสมบูรณ์แบบ ชี้ไปยังตัวเองเสมอเพื่อหลีกเลี่ยงปัญหาที่คาดเดาไม่ได้หรือความขัดแย้งที่อาจทำร้ายมากกว่าดีต่อทั้งสองกลยุทธ์
คุณยังมีคำถามเกี่ยวกับแท็ก SEO ที่น่าสนใจนี้หรือไม่ เรายินดีช่วย
โดย: David Kaufmann

ในช่วง 10+ ปีที่ผ่านมา ผมหมกมุ่นกับ SEO อย่างสมบูรณ์ — และพูดตรง ๆ ก็ไม่อยากให้เป็นแบบอื่น
อาชีพของผมก้าวขึ้นไปอีกระดับเมื่อทำงานเป็นผู้เชี่ยวชาญ SEO อาวุโสที่ Chess.com — หนึ่งใน 100 เว็บไซต์ที่มีผู้เข้าชมมากที่สุดในอินเทอร์เน็ต การทำงานในระดับนี้สอนสิ่งที่ไม่มีหลักสูตรหรือประกาศนียบัตรใดสอนได้
จากประสบการณ์นี้ ผมก่อตั้ง SEO Alive — เอเจนซีสำหรับแบรนด์ที่จริงจังกับการเติบโตแบบออร์แกนิก และเพราะหาเครื่องมือที่จัดการทั้งโลกคลาสสิกและยุค AI ได้ดีไม่ได้ ผมจึงสร้าง SEOcrawl ขึ้น หากคุณกำลังมองหาพาร์ตเนอร์ SEO มากประสบการณ์ที่รักสาขานี้ — ยินดีพูดคุยครับ!
ค้นพบเนื้อหาเพิ่มเติมของผู้เขียนคนนี้

