Canonical tags ทำอะไรเมื่อคุณตั้งค่าผิด

canonical tag ไม่ใช่ยางลบสำหรับเนื้อหาซ้ำ

canonical tag บอกเครื่องมือค้นหาว่า URL ใดที่คุณต้องการให้เป็นเวอร์ชันหลัก เมื่อมีหลาย URL ที่มีเนื้อหาเหมือนกันหรือคล้ายกันอย่างมาก เวอร์ชัน HTML ที่พบได้ทั่วไปมีหน้าตาแบบนี้:

<link rel="canonical" href="https://example.com/preferred-page/">

ยังมีเวอร์ชัน HTTP header ด้วย ซึ่งส่วนใหญ่มีประโยชน์กับไฟล์ที่ไม่ใช่ HTML เช่น PDFs:

Link: <https://example.com/preferred-file.pdf>; rel="canonical"

ฟังดูเรียบง่ายพอสมควร ปัญหาเริ่มขึ้นเมื่อทีมต่าง ๆ ปฏิบัติกับ canonical tags เหมือนเป็นวิธีที่ปลอดภัยในการจัดการทุกอย่างที่ดูยุ่งยากให้เรียบร้อย: faceted navigation, พารามิเตอร์ติดตามผล, หน้าสำหรับพิมพ์, หน้าสินค้าที่เกือบซ้ำกัน, pagination, staging URLs และหน้าแคมเปญเก่า

Canonical tags ไม่ใช่ปุ่มลบ ไม่ใช่ redirect ไม่ใช่สิ่งทดแทนสถาปัตยกรรมสารสนเทศ และไม่ได้รับประกันว่าจะถูกทำตาม

เครื่องมือค้นหาใช้ canonicals เป็นสัญญาณบอกใบ้ที่ค่อนข้างแรง พวกมันเปรียบเทียบ canonical tag กับสัญญาณอื่น ๆ: redirects, ลิงก์ภายใน, URLs ใน sitemap, hreflang annotations, ความคล้ายกันของเนื้อหา, HTTP status codes และ URLs ที่ผู้ใช้กับ crawlers พบจริง หากสัญญาณเหล่านี้ขัดแย้งกัน เครื่องมือค้นหาอาจเพิกเฉยต่อ canonical ของคุณ หรือเลือก canonical URL อื่นไปเลย

นั่นคือเหตุผลที่การตั้งค่า canonicals ผิดจึงทำให้สับสนได้มาก markup ดูถูกต้องในเบราว์เซอร์ แต่หน้าที่ผิดกลับปรากฏในผลการค้นหา — หรือหน้าที่ถูกต้องหายไป

จะเกิดอะไรขึ้นเมื่อ canonical ชี้ไปยัง URL ที่ผิด

เมื่อเครื่องมือค้นหาเห็น URLs ที่ซ้ำกันหรือเกือบซ้ำกัน โดยทั่วไปจะจัดกลุ่มเป็นคลัสเตอร์และเลือก URL หนึ่งเป็น canonical canonical ที่ถูกเลือกคือเวอร์ชันที่มีแนวโน้มมากที่สุดที่จะถูกจัดทำดัชนีและแสดงในผลการค้นหา สัญญาณจากหน้าซ้ำอาจถูกรวมไปยัง URL ที่ถูกเลือกนั้น

หาก canonical tag ของคุณชี้ไปยังหน้าที่ผิด อาจเกิดได้หลายอย่าง

1. URL ที่ผิดถูกจัดทำดัชนี

สมมติว่าคุณมีสอง URL:

• /mens-running-shoes/
• /sale/mens-running-shoes/

หากหน้าลดราคาตั้ง canonical ไปยังหน้าหมวดหมู่หลัก นั่นอาจไม่เป็นปัญหาหากเนื้อหาเกือบเหมือนกันและ URL ลดราคาเป็นเพียงเวอร์ชันที่ถูกกรอง แต่ถ้าหน้าลดราคามีข้อความเฉพาะตัว สินค้าเฉพาะตัว และมีความต้องการค้นหาเป็นของตัวเอง canonical อาจกดหน้านั้นไว้

หน้านั้นอาจยังถูก crawl อยู่ ผู้ใช้อาจยังเข้าถึงได้ แต่เครื่องมือค้นหาอาจตัดสินใจไม่จัดทำดัชนีแยกต่างหาก เพราะคุณบอกพวกมันว่า URL อื่นคือเวอร์ชันที่ต้องการ

นี่คือความล้มเหลวของ canonical ที่พบบ่อยที่สุด: ไม่ใช่เหตุขัดข้องทางเทคนิคครั้งใหญ่ แต่เป็นการหายไปจากดัชนีอย่างเงียบ ๆ

2. สัญญาณการจัดอันดับถูกรวมไปผิดที่

Canonicals มักถูกใช้เพื่อรวมสัญญาณ เช่น ลิงก์และเวอร์ชันเนื้อหาที่ซ้ำกัน สิ่งนี้มีประโยชน์เมื่อหน้าที่ซ้ำนั้นเทียบเท่ากันจริง ๆ แต่มีความเสี่ยงเมื่อไม่ใช่

หากบทความบล็อกมี URLs สำหรับติดตามผล เช่น:

• /guide-to-canonical-tags/?utm_source=newsletter
• /guide-to-canonical-tags/?utm_source=linkedin

การ canonicalize ทั้งคู่ไปที่ /guide-to-canonical-tags/ เป็นเรื่องสมเหตุสมผล

แต่ถ้าเวอร์ชันภาษาสเปน เวอร์ชันสำหรับพิมพ์ที่มีเนื้อหาเพิ่มเติม หรือ variant ของสินค้าที่มี intent ต่างกัน ชี้ไปยัง canonical เดียวกัน คุณอาจกำลังรวมสัญญาณที่ควรแยกกันไว้ ผลลัพธ์อาจทำให้ความเกี่ยวข้องของทุกหน้าลดลง

Canonical tags ว่าด้วยความเทียบเท่า หากสองหน้าตอบเจตนาการค้นหาที่ต่างกัน ก็อาจไม่ควร canonicalize เข้าหากัน

3. เครื่องมือค้นหาเพิกเฉยต่อ tag

canonical ไม่ใช่คำสั่ง หากปลายทาง canonical redirect, ส่งคืน 404, ถูกบล็อก, มี noindex หรือมีเนื้อหาที่แตกต่างกันมาก เครื่องมือค้นหาอาจเพิกเฉยต่อมัน

ในแง่หนึ่ง นี่เป็นเรื่องดี: canonical ที่ไม่ดีไม่ได้ทำลายการจัดทำดัชนีเสมอไป แต่ก็หมายความว่าคุณไม่สามารถสรุปได้ว่า tag กำลังทำสิ่งที่คุณคิดอยู่ หน้าอาจประกาศ canonical อย่างหนึ่ง ขณะที่ Google เลือกอีกอย่างหนึ่ง

สิ่งนี้พบได้บ่อยเป็นพิเศษเมื่อ internal links, sitemaps และ canonicals ไม่สอดคล้องกัน หากลิงก์ภายในทุกลิงก์ชี้ไปที่ /product, sitemap ของคุณระบุ /product/ และ canonical ของคุณชี้ไปที่ https://www.example.com/product?ref=main คุณได้สร้างข้อโต้แย้งเล็ก ๆ ระหว่างสัญญาณของตัวเอง

เครื่องมือค้นหาเก่งในการคลี่คลายข้อโต้แย้งนั้น แต่ไม่ได้เก่งเสมอไปในการคลี่คลายตามแบบที่คุณตั้งใจ

4. การดีบักยากขึ้นโดยไม่จำเป็น

Canonicals ที่ไม่ดีมักไม่ล้มเหลวเสียงดัง แต่มักสร้างอาการที่ดูเหมือนปัญหา SEO แบบอื่น:

• “Discovered, currently not indexed” หรือภาวะค้างคาในการจัดทำดัชนีที่คล้ายกัน
• URL ที่ผิดติดอันดับสำหรับ query หนึ่ง
• Parameter URLs ปรากฏในรายงาน
• หน้าหมวดหมู่ไม่ปรากฏ แม้จะ crawl ได้
• หน้าระหว่างประเทศถูกรวมเข้ากับเวอร์ชันภาษาที่ผิด
• เทมเพลตใหม่เปิดตัวแล้วมีจำนวนหน้าที่ถูกจัดทำดัชนีน้อยกว่าที่คาด

นี่คือเหตุผลที่การดีบัก canonical ควรรวม raw HTML, rendered HTML, HTTP headers, redirects และรายการใน sitemap หากคุณกำลังตรวจสอบ redirect chains หรือ headers ที่ไม่ตรงกันอยู่แล้ว นิสัยเดียวกันนี้ใช้ได้เช่นกัน; workflow การตรวจสอบ HTTP ในทางปฏิบัติอย่างใน คู่มือของเราในการดีบัก redirects และ HTTP headers บน production มักจะจับความขัดแย้งของ canonical ได้เร็วกว่าการจ้องดูช่องใน CMS

ความผิดพลาดเกี่ยวกับ canonical ที่เสียหายแพงที่สุด

Canonicalize ทุกอย่างไปยัง homepage

เรื่องนี้ยังเกิดขึ้นอยู่ ฟิลด์ในเทมเพลตถูกปล่อยว่าง plugin fallback ไปยัง root ของเว็บไซต์ แล้วทันใดนั้นหลายร้อยหน้าก็ประกาศให้ homepage เป็น canonical

เครื่องมือค้นหาอาจเพิกเฉยต่อสิ่งนี้ เพราะเนื้อหาแตกต่างกันอย่างชัดเจน แต่หากสัญญาณยุ่งเหยิงมากพอ บางหน้าอาจถูกตัดออกหรือถูกจัดกลุ่มผิด อย่างน้อยที่สุด คุณก็กำลังส่งสัญญาณบอกใบ้ที่ไร้ประโยชน์และขัดแย้งกันในทุกหน้า

homepage แทบไม่เคยเป็น canonical สำหรับหน้าภายใน

Canonicalize หน้าที่แบ่งหน้าไปยังหน้าหนึ่ง

เป็นเวลานานที่บางเว็บไซต์ canonicalize /category/page/2/, /page/3/ และอื่น ๆ กลับไปยังหน้าหนึ่ง เจตนาคือเพื่อหลีกเลี่ยงหน้าหมวดหมู่ที่ซ้ำกัน

ปัญหาคือหน้าที่แบ่งหน้าไม่ใช่หน้าซ้ำ พวกมันมีรายการที่แตกต่างกันและช่วยให้ crawlers ค้นพบเนื้อหาที่ลึกลงไป การ canonicalize ทั้งหมดไปยังหน้าหนึ่งอาจลดโอกาสที่เครื่องมือค้นหาจะประมวลผลหน้าถัด ๆ ไปอย่างครบถ้วน

โดยทั่วไป หน้าที่แบ่งหน้าควรมี self-referencing canonicals เว้นแต่จะมีเหตุผลเฉพาะในการรวมเข้าด้วยกัน

Canonicalize หน้าที่ถูกกรองโดยไม่ตรวจสอบ search intent

Faceted navigation สร้างทางเลือกที่ยาก URL ที่ถูกกรองบางรายการเป็นขยะ:

• ?sort=price_ascending
• ?view=grid
• ?sessionid=123

บางรายการอาจเป็น landing pages ที่มีคุณค่า:

• /sofas/blue/
• /laptops/16gb-ram/
• /hotels/paris/pet-friendly/

กฎ canonical แบบครอบคลุมทั้งหมดมักลบหน้าค้นหาที่มีประโยชน์ไปพร้อมกับ noise ของพารามิเตอร์ที่ไร้ประโยชน์ ก่อน canonicalize หน้าที่ถูกกรอง ให้ถามว่าหน้านั้นมีเนื้อหาที่เสถียร ลิงก์ภายใน ความต้องการค้นหา และความต้องการของผู้ใช้ที่ชัดเจนแตกต่างออกไปหรือไม่

หากคำตอบคือใช่ หน้านั้นอาจสมควรให้ indexable พร้อม self-referencing canonical

ชี้ canonicals ไปยัง URLs ที่ redirect หรือถูกบล็อก

ปลายทาง canonical ควรสะอาด indexable และส่งคืน 200 OK อย่าชี้ canonicals ไปยัง URLs ที่ redirect, ส่งคืน errors, ต้องใช้ cookies, ถูกบล็อกด้วย robots.txt หรือมี noindex

นี่เป็นหนึ่งในการตรวจสอบที่ทำให้เป็นอัตโนมัติได้ง่ายที่สุด Crawl เว็บไซต์ของคุณและ flag ปลายทาง canonical ที่ไม่ส่งคืน response 200 ที่สะอาด

ผสม canonical กับ noindex ราวกับว่ามีความหมายเดียวกัน

rel="canonical" และ noindex แก้ปัญหาคนละแบบ

ใช้ canonical เมื่อมีหน้าซ้ำและคุณต้องการรวมสัญญาณไปยัง URL ที่ต้องการ ใช้ noindex เมื่อคุณไม่ต้องการให้หน้าถูกจัดทำดัชนีเลย

การใช้ทั้งสองร่วมกันส่งข้อความที่กระอักกระอ่วน: “อย่าจัดทำดัชนีหน้านี้ แต่ก็ใช้มันเป็นสัญญาณหน้าซ้ำสำหรับอีกหน้าหนึ่งด้วย” เครื่องมือค้นหามักหาทางจัดการได้ แต่ไม่ใช่คำสั่งที่สะอาด หากหน้าเป็นหน้าซ้ำ ให้ canonicalize หากไม่ควรปรากฏในการค้นหาและไม่มีความสัมพันธ์แบบหน้าซ้ำที่มีประโยชน์ ให้พิจารณา noindex

การ audit canonical ในทางปฏิบัติ

คุณไม่จำเป็นต้องมีแพลตฟอร์ม SEO ขนาดใหญ่เพื่อค้นหาปัญหา canonical จำนวนมาก เริ่มจากการ crawl, ตัวอย่าง URL ไม่กี่รายการ และ spreadsheet

สำหรับเทมเพลตสำคัญแต่ละแบบ ให้ตรวจสอบ:

1. หน้านี้มี canonical tag เพียงหนึ่งรายการพอดีหรือไม่? canonical tags หลายรายการสร้างความคลุมเครือ
2. canonical เป็น absolute หรือไม่? ใช้ URL เต็ม รวม protocol และ hostname
3. ปลายทาง canonical ส่งคืน 200 OK หรือไม่? หลีกเลี่ยงปลายทางที่ redirect, ถูกบล็อก หรือเกิด error
4. ปลายทาง canonical indexable หรือไม่? ไม่มี noindex, ไม่มี robots block, ไม่มีข้อกำหนด authentication
5. เนื้อหาเทียบเท่ากันจริงหรือไม่? คล้ายกันไม่ได้แปลว่าเทียบเท่าเสมอไป
6. ลิงก์ภายในสอดคล้องกันหรือไม่? ลิงก์ไปยังรูปแบบ canonical URL เมื่อทำได้
7. sitemap สอดคล้องกันหรือไม่? โดยทั่วไป sitemaps ควรระบุ canonical, indexable URLs
8. hreflang tags สอดคล้องกันหรือไม่? หน้าระหว่างประเทศต้องมีความสัมพันธ์ canonical และ hreflang ที่สอดคล้องกัน
9. rendered HTML ตรงกับ raw HTML หรือไม่? JavaScript สามารถเปลี่ยนหรือ inject tags ได้
10. เครื่องมือค้นหาเลือก canonical ใด? Inspection tools สามารถเปิดเผยได้เมื่อ canonical ที่คุณประกาศแตกต่างจาก canonical ที่ถูกเลือก

นี่เป็นจุดที่ Lighthouse ช่วยได้เช่นกัน แต่เฉพาะภายในข้อจำกัดของมัน มันสามารถ flag ปัญหาบางอย่างเกี่ยวกับ crawlability และ document ได้ แต่ไม่เข้าใจเจตนาเชิงพาณิชย์หรือกลยุทธ์ canonical ของคุณ ให้ถือว่าเป็น input หนึ่ง ไม่ใช่คำตัดสิน หากคุณต้องการวิธีที่นิ่งกว่าในการแยกสิ่งที่มีประโยชน์ออกจาก noise ให้ดูวิธีอ่านรายงาน Lighthouse โดยไม่ตื่นตระหนก

Self-referencing canonicals มักเป็นค่าเริ่มต้นที่ดี

หน้าสำคัญทุกหน้าที่ indexable โดยทั่วไปควรประกาศตัวเองเป็น canonical ไม่ใช่เพราะเครื่องมือค้นหาไม่สามารถคิดเองได้หากไม่มี tag แต่เพราะ self-referencing canonicals ลดความคลุมเครือเมื่อพารามิเตอร์, tracking links, URLs ที่ถูกคัดลอก และความแปลกของ CMS สร้างเส้นทางอื่นไปยังเนื้อหาเดียวกัน

สำหรับหน้าสินค้าที่สะอาด แบบนี้มักถูกต้อง:

<link rel="canonical" href="https://example.com/products/linen-shirt/">

สำหรับ tracking URL โดยทั่วไป canonical ควรชี้กลับไปยังเวอร์ชันที่สะอาด:

<link rel="canonical" href="https://example.com/products/linen-shirt/">

สำหรับ product variant ที่แตกต่างกันจริง ๆ คำตอบขึ้นอยู่กับสถานการณ์ หากเสื้อสีแดง เสื้อสีน้ำเงิน และเสื้อสีดำมีคำอธิบายเดียวกันและเปลี่ยนเฉพาะสี หน้า canonical ของสินค้าหน้าเดียวอาจเพียงพอ หากแต่ละ variant มี demand, reviews, images, stock และ internal links แยกกัน หน้า indexable แยกกันอาจสมเหตุสมผล

ไม่มีกฎ canonical สากลสำหรับ variants มีเพียงคำถามเดียว: หน้าเหล่านี้แทนกันได้สำหรับผู้ค้นหาหรือไม่

Canonical tags ควรตรงกับนโยบาย URL จริงของเว็บไซต์คุณ

บั๊ก canonical ส่วนใหญ่เป็นอาการของปัญหานโยบาย URL ที่ลึกกว่า เว็บไซต์ยังไม่ได้ตัดสินใจว่า trailing slashes มีความสำคัญหรือไม่, URLs ตัวพิมพ์ใหญ่ควร resolve หรือไม่, อนุญาตพารามิเตอร์หรือไม่, HTTP redirect ไป HTTPS หรือไม่ หรือ www เป็น canonical หรือไม่

เลือกเวอร์ชันที่สะอาดหนึ่งเวอร์ชันของแต่ละ URL แล้วทำให้ทั้งระบบสอดคล้องกัน:

• Redirect เวอร์ชัน URL ที่ไม่ต้องการไปยังเวอร์ชันที่ต้องการ
• ลิงก์ภายในไปยังเวอร์ชันที่ต้องการ
• ใส่เวอร์ชันที่ต้องการใน XML sitemaps
• ใช้ self-referencing canonicals บนหน้าที่ต้องการ
• Canonicalize เฉพาะหน้าซ้ำจริงไปยัง URL ที่ต้องการ

เมื่อสัญญาณทั้งหมดชี้ไปในทิศทางเดียวกัน canonical tags จะกลายเป็นเรื่องน่าเบื่อ นั่นคือเป้าหมาย

สรุป

Canonical tags ทรงพลังเพราะมีอิทธิพลต่อการจัดทำดัชนีและการรวมสัญญาณ และอันตรายด้วยเหตุผลเดียวกัน

canonical ที่ผิดไม่ได้ลบหน้าออกจากการค้นหาเสมอไป เครื่องมือค้นหาอาจเพิกเฉยต่อมัน แต่การพึ่งพาเครื่องมือค้นหาให้ช่วยกู้สัญญาณที่ไม่ดีไม่ใช่กลยุทธ์ วิธีที่ปลอดภัยกว่าคือสงวน canonicalization ไว้สำหรับหน้าซ้ำจริง รักษาปลายทางให้สะอาดและ indexable และทำให้ลิงก์ภายใน, redirects, sitemaps และ canonicals ของคุณเล่าเรื่องเดียวกัน

Canonicals ไม่ใช่ที่สำหรับซ่อนสถาปัตยกรรมที่ยุ่งเหยิง แต่เป็นที่สำหรับยืนยันว่ามันถูกจัดระเบียบเรียบร้อยแล้ว