แก้ SEO ให้เห็นผลจริง: Canonical, Sitemap และเครื่องหมายทับท้าย URL

คำแนะนำ SEO ส่วนใหญ่กว้างเกินกว่าจะนำไปใช้ได้ทันที หรือเจาะจงกับแพลตฟอร์มมากจนใช้กับระบบอื่นไม่ได้ ระหว่างคำแนะนำอย่าง “เขียนเนื้อหาที่ดี” กับคู่มือเฉพาะอย่าง “เพิ่ม schema markup ให้ breadcrumb” ยังมีงานพื้นฐานด้าน SEO ในระดับโครงสร้างพื้นฐาน งานนี้กำหนดว่าเครื่องมือค้นหาจะจัดทำดัชนีและเข้าใจเว็บไซต์ได้อย่างน่าเชื่อถือหรือไม่ แต่ได้รับความสนใจน้อยกว่าที่ควร แม้ให้ผลสม่ำเสมอกว่ากลยุทธ์ด้านเนื้อหา

จากการตรวจสอบและแก้ไข SEO อย่างเป็นระบบสำหรับเว็บไซต์นี้กับเว็บไซต์ลูกค้าหลายแห่ง การแก้ที่ทำให้ความครอบคลุมของการจัดทำดัชนีและอันดับเปลี่ยนแปลงอย่างวัดผลได้ มักเป็นด้านเทคนิคมากกว่าเนื้อหา นี่ไม่ใช่ข้อสรุปสากล เว็บไซต์ที่มี SEO ทางเทคนิคดีอยู่แล้วมักติดข้อจำกัดจากช่องว่างเนื้อหา แต่เว็บไซต์ที่สะสมการเปลี่ยน URL การเปลี่ยนเส้นทาง และการย้ายเฟรมเวิร์กมาหลายปี มีหนี้ทางเทคนิคเป็นเพดานจำกัดผลที่การลงทุนในเนื้อหาจะทำได้

canonical URL ที่ไม่สอดคล้องกัน

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

รูปแบบที่พบบ่อยที่สุดในการตรวจสอบคือ canonical ที่อ้างอิงหน้าตัวเองกลับใช้รูปแบบ URL ไม่ตรงกับหน้าจริง หน้า https://example.com/products/widget/ ที่ชี้ canonical ไปยัง https://example.com/products/widget ซึ่งไม่มีเครื่องหมายทับท้าย กำลังส่งสัญญาณว่าฉบับที่ควรจัดทำดัชนีคือ URL ที่เมื่อเรียกแล้วเปลี่ยนเส้นทางกลับมาฉบับมีเครื่องหมายทับ เครื่องมือค้นหามักรับมือความไม่สอดคล้องนี้ได้ แต่ “มักรับมือได้” หมายถึงบางครั้งรวมสัญญาณถูกต้อง บางครั้งแบ่งงบการรวบรวมข้อมูลไปให้สองสัญญาณ

ความไม่สอดคล้องที่มีผลมากกว่าคือระหว่าง canonical URL กับ hreflang URL ในเว็บไซต์หลายภาษา หน้าเว็บที่ canonical ชี้ไปฉบับภาษาอังกฤษ แต่ hreflang ชี้ไปฉบับแต่ละภาษา ทำให้เครื่องมือค้นหาต้องประสานคำสั่งสองชุดที่บอกตัวตนของหน้าไม่ตรงกัน เอกสาร Google ระบุชัดว่า canonical กับ hreflang ต้องสอดคล้องกัน ในทางปฏิบัติ ค่ากำหนดที่ขัดกันทำให้พฤติกรรมจัดทำดัชนีคาดเดาไม่ได้ และวินิจฉัยยากหากไม่ตรวจสอบอย่างเป็นระบบ

วิธีแก้ไม่ซับซ้อน ต้องตรวจ canonical ที่อ้างอิงหน้าตัวเองของทุกหน้า และยืนยันว่าตรงกับ URL ที่ให้บริการจริงทุกด้าน ทั้งโปรโตคอล การมีหรือไม่มี www เครื่องหมายทับท้าย และการเข้ารหัส URL ความซับซ้อนอยู่ที่ขอบเขต สำหรับเว็บไซต์หลายร้อยหน้าหลายภาษา ต้องตรวจด้วยโปรแกรมแทนการตรวจด้วยมือ

การกรอง sitemap

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

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

เนื้อหาที่ต้องยืนยันตัวตนควรใส่ใจเป็นพิเศษ หน้าหลังการเข้าสู่ระบบ เช่น แดชบอร์ดบัญชี ประวัติคำสั่งซื้อ และขั้นตอนชำระเงิน ไม่ควรอยู่ใน sitemap ไม่ว่าจะมีแท็ก noindex อย่างชัดเจนหรือไม่ sitemap ที่ส่งให้ Google Search Console และมี URL ที่ต้องเข้าสู่ระบบจะสร้างรายงาน “Page with redirect” หรือ “Crawled — currently not indexed” ซึ่งเป็นข้อมูลรบกวนในการตรวจสอบและบดบังสถานะของหน้าที่ควรจัดทำดัชนี

sitemap ที่กรองและแยกไฟล์ตามประเภทเนื้อหา เช่น สินค้า บทความ และหน้าแนะนำบริการ มีประโยชน์เพิ่มคือวิเคราะห์ใน Google Search Console ได้ละเอียดว่าประเภทใดจัดทำดัชนีได้มีประสิทธิภาพ sitemap สินค้าที่มี 200 URL กับ sitemap บทความที่มี 80 URL ช่วยติดตามอัตราจัดทำดัชนีแยกประเภท และระบุรูปแบบที่อาจมองไม่เห็นหากรวมในไฟล์เดียว

กำหนดเครื่องหมายทับท้าย URL ให้สอดคล้องกัน

คำถามเรื่องเครื่องหมายทับท้าย URL เก่าแก่กว่าอายุงานของนักพัฒนาเว็บส่วนใหญ่ในปัจจุบัน และไม่ได้ง่ายขึ้น เซิร์ฟเวอร์กับเฟรมเวิร์กส่วนใหญ่ให้บริการได้ทั้ง /page และ /page/ และมักเปลี่ยนเส้นทางจากรูปแบบหนึ่งไปอีกแบบ แต่เปลี่ยนจากแบบไหน และใช้รหัสสถานะใด มักไม่สอดคล้องกันทั่วเว็บไซต์ที่ผ่านการย้าย CMS หรือเปลี่ยนเฟรมเวิร์กหลายครั้ง

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

การทำให้เป็นรูปแบบเดียวต้องสอดคล้องกันสามชั้น ได้แก่ การเปลี่ยนเส้นทางระดับเซิร์ฟเวอร์ด้วย 301 จากรูปแบบรองไปยังรูปแบบ canonical แท็ก canonical ที่อ้างอิงหน้าตัวเองโดยใช้รูปแบบเดียวกัน และลิงก์ภายในทั่วเว็บไซต์ที่ใช้รูปแบบ canonical เว็บไซต์มักทำเพียงหนึ่งหรือสองชั้น จึงลดแต่ไม่ขจัดสัญญาณซ้ำ

การเลือกรูปแบบหลักว่าจะมีเครื่องหมายทับท้ายหรือไม่สำคัญน้อยกว่าความสม่ำเสมอ ทั้งสองแบบใช้ได้ รูปแบบที่เข้ากับการสร้างเว็บไซต์แบบสแตติกได้ดีที่สุด ซึ่งมี /page/index.html เป็นโครงสร้างผลลัพธ์ตามธรรมชาติ คือแบบมีเครื่องหมายทับท้าย ซึ่งเป็นรูปแบบที่ได้จากค่าเริ่มต้นของรูปแบบเอาต์พุต build.format: 'directory' ใน Astro ส่วน Next.js จะเปลี่ยนเส้นทางไปยังรูปแบบที่ไม่มีเครื่องหมายทับท้ายโดยค่าเริ่มต้น ส่วนแนวทางที่ตรงกับโครงสร้างไดเรกทอรีแบบไม่มีเครื่องหมายทับใช้แบบไม่มีเป็นค่าเริ่มต้น เลือกแบบใดก็ได้ ปัญหาอยู่ที่ความไม่สอดคล้อง

วินิจฉัยการจัดทำดัชนีด้วย Google Search Console

รายงาน Coverage ซึ่งปัจจุบันคือ Page Indexing ของ Google Search Console เป็นช่องทางรับผลตอบกลับที่ตรงที่สุดสำหรับวินิจฉัย SEO ระดับเว็บไซต์ หมวดที่แสดง เช่น “Crawled — currently not indexed”, “Discovered — currently not indexed”, “Duplicate without user-selected canonical” และ “Alternate page with proper canonical tag” ต่างสัมพันธ์กับสถานการณ์ทางเทคนิคเฉพาะที่ต้องแก้ต่างกัน

เมื่อพบ “Crawled — currently not indexed” จำนวนมาก มักเป็นหนึ่งในสามกรณี ได้แก่ ปัญหาคุณภาพเนื้อหาในหน้าบางประเภท สัญญาณโครงสร้างที่บ่งชี้ว่าเนื้อหาคุณค่าต่ำ เช่น หน้าเนื้อหาน้อย เนื้อหาตามเทมเพลตมาก หรือหน้าที่มีความหมายต่างจากหน้าอื่นน้อย หรือข้อจำกัดงบการรวบรวมข้อมูลที่ทำให้ Google ชะลอจัดทำดัชนีแม้ดึงหน้าแล้ว วิธีแก้ต่างกันมากตามสาเหตุ

“Duplicate without user-selected canonical” แทบจะเป็นสัญญาณว่าการกำหนดเครื่องหมายทับท้ายหรือค่ากำหนด canonical มีช่องโหว่เสมอ เมื่อ Google พบเนื้อหาเดียวกันที่สอง URL และไม่มีฉบับใดชี้ canonical ไปยังอีกฉบับ จะเลือกฉบับหนึ่งเองโดยอาศัยสัญญาณของตน ซึ่งอาจไม่ใช่รูปแบบที่คุณต้องการ หมวดรายงานนี้เป็นตัวบ่งชี้ที่เชื่อถือได้ของปัญหาความไม่สอดคล้องข้างต้น

การใช้ Search Console เพื่อติดตาม SEO ต่อเนื่องที่นำไปดำเนินการได้มากที่สุดไม่ใช่รายงานอันดับ ซึ่งมีความแปรปรวนจากการปรับเฉพาะบุคคล ตำแหน่ง และบริบทคำค้นมากเกินไปสำหรับใช้งานระดับ URL รายงานการจัดทำดัชนีที่เทียบกับข้อมูลการส่ง sitemap ให้สัญญาณตรงว่าโครงสร้างพื้นฐานทางเทคนิคกำลังช่วยหรือจำกัดการมองเห็นเว็บไซต์

สิ่งที่ทำให้เห็นผลจริง

ข้อมูลก่อนและหลังการแก้ไข วัดในช่วง 60-90 วัน ซึ่งจากประสบการณ์ของเราเป็นระยะเวลาที่ Google ใช้ประมวลผลและสะท้อนการเปลี่ยนแปลงโครงสร้าง แสดงรูปแบบสม่ำเสมอ การทำ canonical และเครื่องหมายทับท้ายให้สอดคล้องกันให้ผลชัดที่สุดในการลดคำเตือน GSC เรื่องหน้าซ้ำ พร้อมประสิทธิภาพการรวบรวมข้อมูลที่ดีขึ้น การกรอง sitemap สัมพันธ์กับความครอบคลุมการจัดทำดัชนีหน้าสำคัญที่ดีขึ้น ซึ่งอาจเป็นเพราะความสนใจในการรวบรวมข้อมูลเปลี่ยนจากข้อมูลรบกวนไปยังสัญญาณที่มีคุณค่า

ข้อจำกัดที่ต้องยอมรับตรง ๆ คือแยกผลของการแก้แต่ละอย่างได้ยาก งาน SEO เกิดบนเว็บไซต์ที่มีอายุเพิ่มขึ้น เพิ่มเนื้อหาใหม่ และถูก Google รวบรวมข้อมูลตามกำหนดของ Google ไม่ใช่ของเรา ความสัมพันธ์ระหว่างการแก้เทคนิคกับอันดับที่ดีขึ้นจึงมีปัจจัยร่วมเหล่านี้ปะปนอยู่เสมอในระดับหนึ่ง

สิ่งที่ข้อมูลสนับสนุนชัดคือเว็บไซต์ที่ยังมีหนี้ SEO ทางเทคนิค เช่น สัญญาณซ้ำต่อเนื่อง sitemap ที่รวมมากเกินไป และ canonical ไม่สอดคล้องกัน ทำผลงานต่ำกว่าศักยภาพไม่ว่าเนื้อหาดีเพียงใด การแก้พื้นฐานไม่รับประกันอันดับดีขึ้น แต่ขจัดเพดานที่ทำให้การลงทุนด้านอื่นได้ผลไม่เต็มที่