สรุปสั้น ๆ (TL;DR)
- John Mueller ตอบรายงานเรื่องเว็บที่ถูกถอดออกจากดัชนีและถูกแทนที่ด้วยโดเมนคาสิโนที่ไม่เกี่ยวข้องเป็น canonical รายงานโดย Search Engine Journal เมื่อวันที่ 18 กันยายน 2569
- สาเหตุที่น่าจะเป็นไม่ใช่การยึด canonical แต่คือเว็บส่ง error shell ฝั่งไคลเอนต์ทั่วไปให้ Googlebot ซึ่งจากนั้นถือว่าทุก URL ที่แสดง error เดียวกันเป็นหน้าซ้ำ
- Mueller บอกว่าผลลัพธ์ canonical ที่เจาะจงไม่สำคัญ เพราะทุกเวอร์ชันจบที่หน้าไม่แสดงสำหรับเนื้อหาปกติ วิธีแก้คือ error ที่อยู่เบื้องหลัง ไม่ใช่ canonical
- คำแนะนำของเขา คือใช้การตรวจ URL แบบสดใน Search Console จับ error ก่อนเปิดตัวด้วยการทดสอบอัตโนมัติ และมอนิเตอร์หน้าสำคัญตามตารางเพื่อจับการเรนเดอร์ที่พังแต่เนิ่น ๆ
- cross-domain canonical จริงต้องมีแท็กบนโดเมนของคุณเอง ถ้ามันอยู่ที่นั่นและคุณไม่ได้ใส่ ให้ถือเป็นการถูกแฮ็ก ถ้าไม่มี ก็ไม่ใช่การถอดออกจากดัชนีจาก canonical
John Mueller จาก Google ตอบรายงานเรื่องเว็บไซต์ที่ดูเหมือนถูกถอดออกจากดัชนีและถูกแทนที่ในการค้นหาด้วยโดเมนที่ไม่เกี่ยวข้อง และประเด็นที่มีประโยชน์คือแทบไม่เคยเป็นการยึด canonical มันมักเป็นเว็บที่เผลอส่งหน้า error ให้ Googlebot ซึ่งจากนั้นถูกถือว่าเป็นหน้าซ้ำกับทุกเว็บอื่นที่แสดง error ทั่วไปเดียวกัน Search Engine Journal รายงานบทสนทนานี้เมื่อวันที่ 18 กันยายน 2569
ความตื่นตระหนกในกรณีเหล่านี้เข้าใจได้ เจ้าของเว็บเห็นหน้าของตัวเองหายไปและมีโดเมนแปลก ๆ ในกรณีนี้คือเว็บคาสิโน ถูกแสดงเป็นเวอร์ชัน canonical ของเนื้อหาของตัวเอง แต่กลไกที่คนสันนิษฐาน คือมีคนอื่นตั้ง canonical เว็บของเขาไปยังคาสิโน ไม่ใช่วิธีที่ canonical ทำงาน สาเหตุจริงธรรมดากว่าและแก้ได้ง่ายกว่า
cross-domain canonical คืออะไร
cross-domain canonical คือ meta tag ที่บอกเสิร์ชเอนจินว่าเนื้อหาบนเว็บหนึ่งเหมือนกับเนื้อหาบนอีกเว็บหนึ่ง เป็นเวอร์ชันข้ามเว็บของ canonical tag ธรรมดาที่จัดการ URL ซ้ำภายในเว็บเดียว Google ถือทั้งคู่เป็นคำใบ้ที่หนักแน่น ไม่ใช่ข้อบังคับ มันจึงเพิกเฉยได้และเพิกเฉยจริง
การใช้งานที่ถูกต้องของมันแคบลงจนแทบไม่เหลือ มันเคยเป็นวิธีบอกการย้ายเว็บเมื่อการทำ 301 redirect เป็นไปไม่ได้จริง ซึ่งหายากแล้วในตอนนี้ และเป็นวิธีชี้ไปยังเวอร์ชันต้นฉบับของเนื้อหาที่ถูกนำไปเผยแพร่ต่อ สำหรับการเผยแพร่ต่อ แนวทางของ Google เปลี่ยนไปแนะนำ meta noindex บนสำเนาแทน โดยใช้ robots meta tag เช่น noindex สำหรับ Googlebot-News หรือสำหรับ Googlebot ทั่วไป เพราะ canonical เป็นเพียงคำใบ้ ขณะที่ redirect และ noindex เป็นคำสั่งที่ Google ต้องเชื่อฟัง จึงแทบไม่มีเหตุผลที่จะใช้ cross-domain canonical ในวันนี้
สิ่งที่เกิดขึ้นจริงในกรณีที่รายงาน
เจ้าของเว็บอธิบายการถูกถอดออกจากดัชนีที่เพิ่มขึ้น โดย Google เห็นหน้าเว็บพนันคาสิโนเป็นเวอร์ชัน canonical ของหน้าเกี่ยวกับบริษัทและซัพพลายเออร์ของเขา ทั้งที่ไม่มีความคล้ายในเนื้อหา เจ้าของเว็บอีกรายที่เจอเรื่องเดียวกันให้คำอธิบายที่น่าจะเป็น และมันไม่เกี่ยวกับ canonical ที่มุ่งร้าย
เว็บของเขาเคยส่ง error ของ JavaScript ฝั่งไคลเอนต์เป็นครั้งคราว คือข้อความทั่วไป "Application error: a client-side exception has occurred" ระหว่างการล่มชั่วคราวเมื่อแอปโหลดไม่สำเร็จ เมื่อค้น URL canonical ของบุคคลที่สามใน Google มันแสดงว่าถูกทำดัชนีด้วยข้อความ error เดียวกันนั้นเป็นชื่อเรื่อง ทฤษฎีคือ Googlebot ครอว์ล error หรือการตอบสนองสำรองแทนเนื้อหาจริง แล้วถือว่า URL ที่ไม่เกี่ยวข้องหลายอันซึ่งแสดง error shell เดียวกันเป็นหน้าซ้ำของกันและกัน นั่นคือสิ่งที่ทำให้เกิดการเลือก cross-domain canonical และการถอดออกจากดัชนี และมันแก้ตัวเองเมื่อหน้าเว็บส่งเนื้อหาจริงอีกครั้ง
สิ่งที่ Mueller บอกให้ทำ
Mueller เห็นด้วยว่าคำอธิบายเรื่อง error shell ฟังขึ้น และแนะนำให้ใช้การตรวจ URL แบบสดใน Search Console เพื่อดูว่า Google เรนเดอร์หน้าเว็บอย่างไรจริง ๆ ประเด็นที่สองของเขาตรงกว่าและมีประโยชน์กว่า คือสุดท้ายแล้ว เขาบอกว่าผลลัพธ์ canonical ที่เจาะจงไม่สำคัญ เพราะทุกเวอร์ชันของมันจบเหมือนกัน
| ผลลัพธ์ที่ Mueller อธิบาย | ผลที่ได้ |
|---|---|
| หน้าของคุณเป็น canonical แต่ถูกทำดัชนีด้วยข้อความ error ของเซิร์ฟเวอร์ | หน้าของคุณไม่แสดงในการค้นหาสำหรับเนื้อหาปกติ |
| หน้าของคุณถูกถือเป็น soft 404 ซึ่ง Mueller บอกว่าเป็นสิ่งที่ควรเกิด | หน้าของคุณไม่แสดงในการค้นหาสำหรับเนื้อหาปกติ |
| หน้าอื่นถูกถือเป็น canonical | หน้าของคุณไม่แสดงในการค้นหาสำหรับเนื้อหาปกติ |
ประเด็นของตารางคือการไล่ตามว่า Google เลือก canonical ตัวไหนเป็นสิ่งที่เบี่ยงเบนความสนใจ ไม่ว่าป้ายจะเป็นอะไร ปัญหาที่อยู่ข้างใต้เหมือนกัน คือ Googlebot เห็น error แทนเนื้อหาของคุณ และวิธีแก้ก็เหมือนกัน
วิธีแก้จริงไม่เกี่ยวกับ canonical เลย
วิธีแก้ที่ Mueller แนะนำคือจับ error ให้ได้ก่อนเว็บขึ้นจริง ไม่ใช่สู้กับ canonical หลังเกิดเหตุ เขาอธิบายว่ารันการทดสอบอัตโนมัติก่อนดันเว็บขึ้นจริง และเพิ่มการทดสอบใหม่ทุกครั้งที่มีอะไรผิดพลาด เพื่อให้ความล้มเหลวที่รู้อยู่แล้วไม่เกิดซ้ำแบบเงียบ ๆ สำหรับเว็บที่ขึ้นจริงแล้ว สิ่งเทียบเท่าคือการมอนิเตอร์ คือดึงหน้าที่สำคัญที่สุดของคุณตามตาราง รายชั่วโมงหรือทำนองนั้น และตรวจหาปัญหา เพื่อให้การเรนเดอร์ที่พังถูกจับและแก้ก่อนกลายเป็นปัญหาถาวรที่เสิร์ชเอนจินเก็บไป
เรื่องนี้เปลี่ยนกรอบทั้งหมด อันตรายไม่ใช่การโจมตี canonical แต่คือเว็บของคุณเองส่ง error shell ให้ Googlebot เป็นครั้งคราว ส่วนใหญ่บนหน้าที่ใช้ JavaScript หนักซึ่งเรนเดอร์ไม่สำเร็จ ระหว่างการดีพลอย หรือตอนล่ม ถ้า Googlebot เห็นแต่เนื้อหาจริงเสมอ ปัญหา error shell ซ้ำจะเกิดไม่ได้ และอาการ cross-domain canonical ที่ดูแปลกก็ไม่มีทางปรากฏ
เมื่อไรที่เป็น cross-domain canonical จริง และเมื่อไรที่เป็นความบังเอิญ
มีกรณีแคบ ๆ ที่ cross-domain canonical เป็นสาเหตุจริง คือเพื่อให้สัญญาณถ่ายโอน โดเมนของคุณเองต้องมี cross-domain canonical ชี้ไปยังเว็บอื่น ถ้าแท็กนั้นอยู่บนหน้าของคุณและคุณไม่ได้ใส่ นั่นชี้ไปที่การถูกแฮ็ก และการตอบสนองคือการสืบสวนความปลอดภัย ไม่ใช่เรื่อง SEO ถ้าแท็กนั้นไม่อยู่บนหน้าของคุณ สิ่งที่คุณเห็นก็ไม่ใช่การถอดออกจากดัชนีจาก cross-domain canonical ไม่ว่ามันจะดูเหมือนแค่ไหน
นี่คือจุดที่รายงานของ SEJ ตั้งประเด็นที่กว้างกว่าและควรจำ SEO มักติดป้ายความบังเอิญว่าเป็นสาเหตุ เว็บเสียอันดับ มีคนสังเกตเห็นหลายหน้าในหัวข้อคล้ายกันแล้วโทษ keyword cannibalisation หรือเจอแบ็กลิงก์คุณภาพต่ำแล้วโทษมัน ทั้งที่สาเหตุจริงเป็นอะไรที่ไม่เกี่ยวกัน เช่น error shell ที่ถูกส่งอยู่หนึ่งสัปดาห์ สองสิ่งที่เกิดใกล้เวลากันไม่ใช่หลักฐานว่าอย่างหนึ่งทำให้เกิดอีกอย่าง ให้วินิจฉัยจากสิ่งที่ Google เรนเดอร์จริง ผ่านการตรวจ URL แบบสดและล็อกของคุณ ก่อนคว้าคำอธิบายที่ดราม่า
เรื่องนี้มีความหมายอย่างไรกับนักการตลาดไทย
เรื่องนี้กระทบหนักที่สุดกับเว็บแบบที่พบบ่อยในไทย คือเว็บที่ใช้ JavaScript หนัก หน้าเว็บแบบ single-page application และเว็บบนโฮสติ้งแบบแชร์หรือราคาถูกที่บางครั้งหมดเวลาตอบสนอง นั่นคือการตั้งค่าที่มีโอกาสมากที่สุดที่จะส่ง error shell ฝั่งไคลเอนต์ให้ Googlebot ระหว่างการดีพลอยหรือตอนทราฟฟิกพุ่ง ซึ่งเป็นตัวกระตุ้นจริงเบื้องหลังอาการที่ดูน่ากลัวในที่นี้
คำแนะนำที่ใช้ได้จริงสำหรับเว็บไทยไม่หวือหวาแต่เชื่อถือได้ ยืนยันว่า Googlebot เรนเดอร์อะไรจริงโดยใช้การตรวจ URL ใน Search Console แทนการเชื่อสิ่งที่คุณเห็นในเบราว์เซอร์ เพราะหน้าที่โหลดปกติสำหรับผู้เข้าชมยังส่ง error ให้ Googlebot ได้ระหว่างการเรนเดอร์ที่ล้มเหลว ติดตั้งการมอนิเตอร์ uptime และการเรนเดอร์พื้นฐานบนหน้าที่สำคัญที่สุด เพื่อให้การล่มที่แสดง error shell ถูกจับในไม่กี่ชั่วโมง ไม่ใช่พบในอีกหลายสัปดาห์ต่อมาเป็นการถอดออกจากดัชนี และถ้าหน้าหลุดออกไปจริง ให้ตรวจเนื้อหาที่เรนเดอร์ก่อนจะสันนิษฐานว่า canonical บทลงโทษ หรือคู่แข่งเป็นคนทำ นี่คือสุขอนามัยเชิงเทคนิคหลัก และมันอยู่ใน การตรวจสอบ SEO เป็นระยะ ควบคู่กับงาน SEO ที่เหลือ ไม่ใช่การตอบสนองฉุกเฉินหลังทราฟฟิกหายไปแล้ว
คำถามที่พบบ่อย
เว็บอื่นตั้ง canonical เว็บของฉันไปเป็นของเขาแล้วถอดฉันออกจากดัชนีได้ไหม
ไม่ได้ เพื่อให้ cross-domain canonical ถ่ายโอนสัญญาณ แท็กต้องอยู่บนโดเมนของคุณเองที่ชี้ไปยังเว็บอื่น ถ้าแท็กนั้นอยู่บนหน้าของคุณและคุณไม่ได้ใส่ ให้ถือว่าอาจเป็นการถูกแฮ็ก ถ้ามันไม่อยู่บนหน้าของคุณ สิ่งที่คุณเห็นก็ไม่ใช่การถอดออกจากดัชนีจาก cross-domain canonical แม้จะดูเหมือน
ทำไมเว็บที่ไม่เกี่ยวข้องปรากฏเป็น canonical ของฉัน
สาเหตุที่น่าจะเป็นคือเว็บของคุณส่ง error shell ฝั่งไคลเอนต์ทั่วไปให้ Googlebot ระหว่างการล่ม และ Google ถือว่าทุก URL ที่ไม่เกี่ยวข้องซึ่งแสดง error เดียวกันเป็นหน้าซ้ำของกันและกัน นั่นทำให้เกิดการเลือก canonical ที่แปลก และมักแก้ตัวเองเมื่อหน้าเว็บส่งเนื้อหาจริงอีกครั้ง
Mueller แนะนำอะไร
ใช้การตรวจ URL แบบสดใน Search Console เพื่อดูว่า Google เรนเดอร์หน้าเว็บอย่างไร และแก้ error ที่อยู่เบื้องหลังแทนการแก้ canonical เขาแนะนำให้จับ error ก่อนเปิดตัวด้วยการทดสอบอัตโนมัติ และมอนิเตอร์หน้าสำคัญตามตารางสำหรับเว็บที่ขึ้นจริงแล้ว เพื่อให้การเรนเดอร์ที่พังถูกจับก่อนที่เสิร์ชเอนจินจะทำดัชนี
ยังควรใช้ cross-domain canonical ไหม
แทบไม่ canonical เป็นเพียงคำใบ้ ขณะที่ 301 redirect และ meta noindex เป็นคำสั่งที่ Google ต้องเชื่อฟัง สำหรับการย้ายเว็บให้ใช้ 301 และสำหรับเนื้อหาที่เผยแพร่ต่อ Google แนะนำ meta noindex บนสำเนาแทน cross-domain canonical
แยกสาเหตุจริงจากความบังเอิญได้อย่างไร
วินิจฉัยจากสิ่งที่ Google เรนเดอร์จริง โดยใช้การตรวจ URL แบบสดและล็อกเซิร์ฟเวอร์ของคุณ ก่อนโทษ canonical การกินกันของคีย์เวิร์ด หรือแบ็กลิงก์ สองสิ่งที่เกิดพร้อมกันไม่ได้พิสูจน์ว่าอย่างหนึ่งทำให้เกิดอีกอย่าง และคำอธิบายที่ดราม่ามักเป็นการวินิจฉัยผิดของปัญหาการเรนเดอร์หรือ uptime ธรรมดา
สรุป
เว็บที่หายไปและโดเมนคาสิโนที่ปรากฏเป็น canonical ของมันดูน่าตกใจและแทบทุกครั้งมีต้นตอที่ไม่ร้ายแรง คือ Googlebot ครอว์ล error shell แล้วเหมารวม error เดียวกันเข้าด้วยกัน คำแนะนำของ Mueller คือเลิกไล่ตาม canonical เพราะทุกเวอร์ชันของผลลัพธ์หมายความเหมือนกัน และไปแก้ที่สาเหตุแทน คือจับ error ก่อนเปิดตัวด้วยการทดสอบ และมอนิเตอร์หน้าสำคัญเพื่อให้การเรนเดอร์ที่พังไม่กลายเป็นการถอดออกจากดัชนี สำหรับเว็บไทยบนการตั้งค่าที่ใช้ JavaScript หนักหรือราคาถูก การมอนิเตอร์นั้นคือบทเรียนทั้งหมด คือทำให้แน่ใจว่า Googlebot เห็นแต่เนื้อหาจริงของคุณเสมอ
