สรุปสั้น ๆ (TL;DR)
- Search Engine Journal รายงานเมื่อวันที่ 2 กันยายน 2569 ว่าผู้ใช้ Bluesky ถาม John Mueller เรื่องการเติม ?v= unix timestamp ใหม่ทุกวันให้ URL ของ sitemap ลูกใน sitemap index
- Mueller ตอบว่าการมี URL ที่สะอาดและคงที่เป็นเรื่องสำคัญ และชี้ผู้ถามไปที่หน้า Cool URIs don't change ของ Tim Berners-Lee
- เขาไม่ได้บอกว่าเทคนิคนี้เปลี่ยนความถี่ในการเก็บข้อมูลหรือไม่ และรายงานไม่มีคำพูดของเขาเรื่องค่า lastmod หรือเรื่องว่าอัตราการเก็บข้อมูลขึ้นกับอะไร
- คำอธิบายเรื่อง lastmod ในบทความมาจาก Search Engine Journal พร้อมความเห็นของผู้เขียน Roger Montti ที่วิจารณ์วิธีลัดของอินฟลูเอนเซอร์สาย SEO
เมื่อวันที่ 2 กันยายน 2569 Search Engine Journal รายงานว่า John Mueller จาก Google ระบุว่าการทำ cache busting ใน sitemap เป็น "ความคิดที่ไม่ดี" โดยเทคนิคนี้คือการใส่พารามิเตอร์เวอร์ชันใหม่ให้กับ URL ของ sitemap ลูกที่อยู่ใน sitemap index ทุกวัน เพื่อให้เสิร์ชเอนจินดึงไฟล์ใหม่ ข้อคัดค้านของ Mueller เป็นเรื่องความคงที่ของ URL ไม่ใช่เรื่องการเก็บข้อมูล เขาบอกว่าวิธีนี้เป็นการส่งสัญญาณว่า canonical URL ของเนื้อหาชิ้นหนึ่งควรเปลี่ยนไปเรื่อย ๆ ซึ่งไม่ดีทั้งกับเสิร์ชเอนจินและกับระบบวัดผลของเว็บเอง
เทคนิคที่ว่านี้คืออะไร
cache busting เป็นวิธีการฝั่งหน้าเว็บที่ใช้กันมานานและถูกต้องตามหลักการ ตามที่ Search Engine Journal อธิบายไว้ในบทความวันที่ 2 กันยายน 2569 เจ้าของเว็บจะเติมเครื่องหมายคำถามและพารามิเตอร์ต่อท้ายชื่อไฟล์ CSS, JavaScript หรือไฟล์รูปภาพ เพื่อให้เบราว์เซอร์ของผู้เข้าชมดาวน์โหลดไฟล์เวอร์ชันใหม่ล่าสุด แทนที่จะหยิบไฟล์เก่าที่ค้างอยู่ในแคชมาใช้ การเปลี่ยนพารามิเตอร์ก็คือการเปลี่ยน URL และ URL ที่เปลี่ยนไปจะบังคับให้เกิดการดาวน์โหลดใหม่ ขณะที่ไฟล์อื่นยังถูกแคชไว้ได้ตามปกติ เว็บจึงโหลดเร็วและผู้เข้าชมยังได้ไฟล์เวอร์ชันปัจจุบัน
เวอร์ชันสาย SEO ที่ Search Engine Journal รายงาน คือการย้ายเทคนิคนี้ไปใช้ในที่ที่มันไม่ได้ถูกออกแบบมาให้ใช้ ผู้ใช้ Bluesky ที่ใช้ชื่อ @seoharbour ถาม Mueller เรื่องการเติม ?v= ตามด้วย unix timestamp ต่อท้าย URL ของ sitemap ที่อยู่ใน sitemap index เมื่อถูกขอให้อธิบายเพิ่ม @seoharbour บอกว่าเขาเห็นพฤติกรรมนี้บนเว็บขนาดใหญ่ที่มีโครงสร้างตายตัว โดย URL ของ sitemap ลูกที่อยู่ใน index จะได้ ?v=timestamp ชุดใหม่ทุกวัน และเดาว่าเจตนาคือการบังคับให้เกิดการดึงไฟล์ใหม่ด้วยการยื่น URL ใหม่ให้ทุกวัน คำถามของเขาคือวิธีนี้สร้างความเสียหายหรือไม่ เพราะสิ่งที่เปลี่ยนคือตัว URL ไม่ใช่ค่า lastmod
Mueller พูดอะไรจริง ๆ และไม่ได้พูดอะไร
คำตอบแรกของ Mueller ตามที่ Search Engine Journal อ้างอิงไว้ เป็นคำถามกลับมากกว่าคำตัดสิน เขาเขียนว่า "ทำไมถึงจะใช้ cache-busting ในไฟล์ sitemap ล่ะ บางทีผมอาจจะเข้าใจเป้าหมายของคุณผิดก็ได้ อธิบายเพิ่มได้เลย" หลังจากได้คำอธิบาย เขาจึงให้คำตอบ
ประโยคเต็มที่ Search Engine Journal รายงานไว้คือ "ผมคิดว่านั่นเป็นความคิดที่ไม่ดี เพราะคุณกำลังส่งสัญญาณว่า canonical URL ของเนื้อหาชิ้นหนึ่งควรเปลี่ยนไปเรื่อย ๆ นั่นไม่ดีกับเสิร์ชเอนจิน และไม่ดีกับการเก็บข้อมูลวัดผลของคุณเอง การมี URL ที่สะอาดและคงที่เป็นเรื่องสำคัญ" จากนั้นเขาชี้ไปที่หน้า "Cool URIs don't change" ของ Tim Berners-Lee
ควรระบุขอบเขตของคำตอบนี้ให้ชัด เพราะขอบเขตคือจุดที่ข่าวลักษณะนี้มักถูกเล่าเกินจริง Mueller ไม่ได้บอกว่าเทคนิคนี้ทำให้ Google ดึงไฟล์ sitemap บ่อยขึ้นหรือไม่ เขาไม่ได้บอกว่ามันไม่ได้ผล เขาไม่ได้พูดถึงค่า lastmod ไม่ได้พูดถึงความถี่ในการเก็บข้อมูล ไม่ได้พูดถึง crawl budget และไม่ได้พูดว่าอะไรเป็นตัวกำหนดว่า Googlebot จะเข้ามาบ่อยแค่ไหน บทความของ Search Engine Journal ไม่มีคำพูดของ Mueller ในประเด็นเหล่านั้นเลย ข้อคัดค้านเดียวที่เขายกขึ้นมาคือเรื่องการส่งสัญญาณว่า URL ไม่คงที่ และผลที่ตามมาต่อเสิร์ชเอนจินกับการวัดผลของเจ้าของเว็บ
ส่วนคำอธิบายเรื่องแท็ก lastmod ในบทความนั้นมาจากกองบรรณาธิการ ไม่ได้มาจาก Mueller Search Engine Journal อธิบายว่า lastmod คือองค์ประกอบที่บอกวันที่ล่าสุดที่ไฟล์ถูกแก้ไข ซึ่งบอกครอว์เลอร์ได้ว่าไฟล์เปลี่ยนไปหรือไม่ และทำให้ครอว์เลอร์ทุ่มเวลาไปกับหน้าที่เปลี่ยนแปลงจริง นั่นคือมุมมองของสำนักข่าวว่าทำไม sitemap ที่คงที่พร้อมวันที่ถูกต้องจึงเป็นกลไกที่ถูกออกแบบมา บทความยังระบุด้วยว่าผู้ตั้งคำถามเคยเห็นความเห็นเรื่องค่า lastmod ที่ถูกต้องในบล็อกนักพัฒนาของ Google และกำลังถามว่าหลักการเดียวกันใช้ได้หรือไม่
สรุปบทสนทนาที่ถูกรายงานไว้ในตารางเดียว
ข้อมูลในตารางด้านล่างจำกัดอยู่เฉพาะสิ่งที่ Search Engine Journal รายงานเมื่อวันที่ 2 กันยายน 2569 รวมถึงจุดที่แหล่งข่าวไม่ได้พูดถึง
| ประเด็น | สิ่งที่ Search Engine Journal รายงาน |
|---|---|
| ตัวเทคนิค | เติม ?v= ตามด้วย unix timestamp ต่อท้าย URL ของ sitemap ลูกใน sitemap index และเปลี่ยนใหม่ทุกวันเพื่อบังคับให้ดึงไฟล์ซ้ำ |
| ใครเป็นคนเล่า | ผู้ใช้ Bluesky ชื่อ @seoharbour ซึ่งบอกว่าเห็นวิธีนี้บนเว็บขนาดใหญ่ที่มีโครงสร้างตายตัว |
| คำตอบแรกของ Mueller | ถามกลับว่าทำไมถึงจะใช้ cache busting ในไฟล์ sitemap และชวนให้อธิบายเป้าหมายเพิ่ม |
| คำตัดสินของ Mueller | "ความคิดที่ไม่ดี" เพราะเป็นการส่งสัญญาณว่า canonical URL ของเนื้อหาชิ้นหนึ่งควรเปลี่ยนไปเรื่อย ๆ ซึ่งไม่ดีกับเสิร์ชเอนจินและกับการวัดผลของเว็บ |
| สิ่งที่รายงานไม่ได้ครอบคลุม | ไม่มีคำพูดของ Mueller ว่าเทคนิคนี้เปลี่ยนความถี่ในการเก็บข้อมูลหรือไม่ ไม่มีเรื่องค่า lastmod และไม่มีเรื่องว่าอัตราการเก็บข้อมูลขึ้นกับอะไร |
ทำไมข้อคัดค้านนี้จึงเป็นเรื่องตัวตนของ URL ไม่ใช่เรื่องการเก็บข้อมูล
ส่วนนี้เป็นการวิเคราะห์ เหตุผลที่คำตอบของ Mueller ไปลงที่ canonical แทนที่จะลงที่อัตราการเก็บข้อมูล ก็เพราะ URL ทำหน้าที่เป็นตัวระบุตัวตนก่อนจะเป็นที่อยู่ เมื่อไฟล์ sitemap เดียวกันถูกเสิร์ฟที่ sitemap-1.xml?v=1756771200 ในวันนี้ และ sitemap-1.xml?v=1756857600 ในวันพรุ่งนี้ ครอว์เลอร์กำลังถูกบอกว่านี่คือเอกสารสองชิ้น ไม่ใช่เอกสารชิ้นเดียวที่ถูกดึงสองครั้ง คูณด้วยรอบรายวันและจำนวน sitemap ลูกทั้งหมดของเว็บขนาดใหญ่ ครอว์เลอร์ก็จะถูกแนะนำให้รู้จักกับชุด URL ที่โตขึ้นไม่สิ้นสุด ทั้งที่ทุกอันชี้ไปยังเนื้อหาเดียวกัน
ครึ่งหลังของข้อคัดค้านคือส่วนที่เจ้าของเว็บมักมองข้าม เขาบอกว่ามันไม่ดีกับการเก็บข้อมูลวัดผลของเว็บเอง และข้อนี้ตรวจสอบได้ทันที การวิเคราะห์ log การรายงานสถิติการเก็บข้อมูล และแดชบอร์ดภายในใดก็ตามที่จัดกลุ่มคำขอตาม URL จะกระจายประวัติของ sitemap ไฟล์เดียวออกเป็นแถวใหม่ทุกวัน เว็บจึงเสียความสามารถในการตอบคำถามพื้นฐานว่า sitemap นี้ถูกดึงบ่อยแค่ไหน และอัตรานั้นเปลี่ยนไปหรือเปล่า
ยังมีประเด็นที่ตรงไปตรงมากว่านั้น พารามิเตอร์ที่เปลี่ยนทุกวันรับประกันได้แค่ว่าจะเกิด URL ใหม่ แต่ไม่ได้รับประกันว่าครอว์เลอร์จะมอง URL ใหม่นั้นว่าเร่งด่วน และยิ่งไม่ได้รับประกันว่าสิ่งที่อยู่ใน sitemap จะถูกจัดทำดัชนี การดึงไฟล์ sitemap กับการจัดทำดัชนีหน้าเว็บที่อยู่ในไฟล์นั้นเป็นคนละเหตุการณ์ และการทำให้เหตุการณ์แรกเกิดถี่ขึ้นก็ไม่ได้ทำให้เหตุการณ์ที่สองเกิดตามมา
อะไรมีผลต่อการเก็บข้อมูลจริง ในเชิงวิเคราะห์
ไม่มีข้อความในส่วนนี้ที่อ้างว่ามาจาก Mueller เพราะรายงานของ Search Engine Journal ไม่ได้บันทึกว่าเขาพูดเรื่องเหล่านี้ สิ่งที่ตามมาคือแนวปฏิบัติมาตรฐานในการวินิจฉัยปัญหาการเก็บข้อมูล
- เวลาตอบสนองของเซิร์ฟเวอร์ เว็บที่ตอบช้าจะถูกดึงข้อมูลอย่างระมัดระวังมากขึ้น และนี่เป็นหนึ่งในไม่กี่ปัจจัยที่เจ้าของเว็บควบคุมได้โดยตรง รายงาน crawl stats ใน Search Console แสดงเวลาตอบสนองเฉลี่ยคู่กับจำนวนคำขอ ทำให้เห็นความสัมพันธ์นี้ได้ชัด
- เนื้อหาเปลี่ยนจริงหรือไม่ sitemap ที่อ้างว่าหน้าเว็บถูกแก้ไขทุกวันทั้งที่เนื้อหาเหมือนเดิม จะฝึกให้ครอว์เลอร์เลิกเชื่อไฟล์นั้น ค่า lastmod ที่ถูกต้องมีค่ามากกว่าค่าที่เปลี่ยนบ่อย
- อัตราความผิดพลาด สัดส่วนการตอบกลับ 5xx การหมดเวลาเชื่อมต่อ หรือ soft 404 ที่เพิ่มขึ้น มักทำให้การเก็บข้อมูลลดลงก่อนที่ใครจะสังเกตเห็นผลกระทบต่ออันดับเสียอีก
- ความคงที่ของ URL และความซ้ำซ้อน พารามิเตอร์ที่สร้างที่อยู่เพิ่มให้เนื้อหาเดิม ทำให้การเก็บข้อมูลถูกใช้ไปกับเอกสารที่เว็บไม่ได้ต้องการให้ถูกค้นพบ ซึ่งเป็นรูปแบบเดียวกับที่เทคนิค cache busting สร้างขึ้นมาโดยตั้งใจ
- หน้าเหล่านั้นคุ้มค่าที่จะถูกดึงหรือไม่ หน้าที่เนื้อหาบาง ใกล้เคียงกับหน้าอื่น หรือไม่มีลิงก์ภายในชี้ถึง จะถูกเก็บข้อมูลน้อยลงเรื่อย ๆ และไม่มีสัญญาณจาก sitemap ใดกลับทิศทางนั้นได้
ลำดับความสำคัญนี้มีผลกับคนที่กำลังไล่แก้ปัญหาการเก็บข้อมูล ไวยากรณ์ของ sitemap คือที่สุดท้ายที่ควรไปดู ไม่ใช่ที่แรก และการทำตรวจสอบทางเทคนิคที่วัดเวลาตอบสนองและอัตราความผิดพลาด จะอธิบายรูปแบบการเก็บข้อมูลได้บ่อยกว่าการไปปรับ sitemap มาก
ส่วนที่เป็นความเห็นของผู้เขียนบทความ
บทความของ Search Engine Journal ไม่ได้หยุดอยู่แค่การรายงานบทสนทนา ผู้เขียนคือ Roger Montti เพิ่มส่วนที่โต้แย้งว่าเทคนิคแบบนี้เกิดขึ้นเมื่ออินฟลูเอนเซอร์สาย SEO ที่ไม่ได้รู้จริงเรื่อง SEO คิดวิธีลัดที่ฟังดูดีบนกระดาษ แต่ฟังดูไร้สาระสำหรับคนทำ SEO ที่เข้าใจว่าภาษามาร์กอัปอย่าง XML และ HTML ทำงานอย่างไร เขาชี้ว่า XML ย่อมาจาก Extensible Markup Language และมีกฎที่เจ้าของเว็บทำตามเพื่อสื่อสารกับครอว์เลอร์ได้โดยไม่ต้องใช้วิธีลัด
ความเห็นส่วนนั้นเป็นของสำนักข่าว ไม่ใช่ของ Google และการแยกให้ออกเป็นเรื่องสำคัญ เพราะทั้งสองส่วนมักถูกยกไปอ้างพร้อมกัน จุดยืนของ Google ในข่าวนี้มีความยาวเพียงประโยคเดียว คือการทำ cache busting กับ sitemap เป็นความคิดที่ไม่ดี เพราะเป็นการส่งสัญญาณว่า canonical URL ไม่คงที่
สิ่งที่รายงานไม่ได้พูดถึง
บทความไม่ได้ให้หลักฐานเรื่องผลลัพธ์เลย ไม่ได้บอกว่าเว็บขนาดใหญ่ที่ @seoharbour เล่าถึงนั้นเสียอันดับ ได้อันดับเพิ่ม ถูกเก็บข้อมูลมากขึ้น หรือถูกเก็บข้อมูลน้อยลง ผู้ตั้งคำถามไม่ได้ระบุชื่อเว็บ และ Mueller ก็ไม่ได้เข้าไปตรวจสอบ ไม่มีข้อมูลเปรียบเทียบก่อนและหลังปรากฏอยู่ในรายงานฉบับนี้
นอกจากนี้ยังไม่มีข้อความว่า Google ลงโทษวิธีการนี้ ไม่มีกรอบเวลา ไม่มีการเปลี่ยนแปลงผลิตภัณฑ์ และไม่มีการอัปเดตเอกสารใด ๆ Mueller เพียงตอบคำถามบนโซเชียลมีเดีย ไม่ได้ประกาศอะไรทั้งสิ้น ใครที่เล่าข่าวนี้ว่า Google ยืนยันแล้วว่า cache busting ใน sitemap ทำลายการเก็บข้อมูล ก็กำลังเติมข้อความที่ไม่มีอยู่ในแหล่งข่าว
เรื่องนี้มีความหมายอย่างไรกับนักการตลาดไทย
เว็บไทยขนาดใหญ่มีเหตุผลเชิงโครงสร้างที่ต้องสนใจเรื่องนี้ เว็บประกาศอสังหาริมทรัพย์ เว็บหางาน แคตตาล็อกอีคอมเมิร์ซ และเว็บประกาศซื้อขาย ล้วนมี sitemap index ที่ซ้อนหลายชั้น ซึ่งเป็นจุดที่เทคนิคแบบนี้มักถูกนำไปใช้โดยนักพัฒนาที่อ่านเรื่อง cache busting มาจากบริบทงานฝั่งหน้าเว็บ แล้วนำไปใช้ผิดที่ การตรวจสอบใช้เวลาไม่ถึงนาที เปิด sitemap index ดู URL ของ sitemap ลูก แล้วดูว่ามีพารามิเตอร์ที่เปลี่ยนค่าอยู่หรือไม่
เว็บสองภาษามีเหตุผลข้อที่สอง เมื่อหน้าเวอร์ชันไทยกับอังกฤษถูกผูกเข้าด้วยกันผ่านการประกาศ canonical และ hreflang สิ่งใดก็ตามที่ทำให้ canonical URL ดูไม่คงที่ ย่อมเพิ่มสัญญาณรบกวนในจุดที่เป็นต้นเหตุของปัญหาการจัดทำดัชนีบนเว็บไทย-อังกฤษอยู่แล้ว ทีมที่ดูแลงาน SEO ทั้งเวอร์ชันไทยและอังกฤษของเว็บเดียวกันควรยืนยันว่าทุก URL ใน sitemap คือ URL เดียวกับที่ประกาศเป็น canonical บนหน้านั้น โดยไม่มีพารามิเตอร์ห้อยท้าย
ยังมีประเด็นกว้างกว่านั้นเรื่องการจัดลำดับความสำคัญ URL ที่คงที่คือสิ่งที่เครื่องมือตอบคำถามด้วย AI ใช้อ้างอิงด้วยเช่นกัน และการอ้างอิงที่ชี้ไปยังที่อยู่ซึ่งเปลี่ยนทุกวันก็คือการอ้างอิงที่พังในวันถัดไป เว็บที่ลงทุนกับการมองเห็นในคำตอบของ AI จึงมีเหตุผลเดียวกับครอว์เลอร์ที่ต้องการให้เอกสารหนึ่งชิ้นมีที่อยู่ถาวรหนึ่งที่อยู่
คำถามที่พบบ่อย (FAQ) เรื่อง cache busting ใน sitemap กับการเก็บข้อมูล
การเติมพารามิเตอร์ timestamp ใน URL ของ sitemap ทำให้ Google เข้ามาเก็บข้อมูลทุกวันจริงไหม
รายงานของ Search Engine Journal วันที่ 2 กันยายน 2569 ไม่ได้ตอบคำถามนี้ เพราะ John Mueller ไม่ได้พูดถึงความถี่ในการเก็บข้อมูลในคำตอบของเขาเลย เขาบอกเพียงว่าวิธีนี้เป็นความคิดที่ไม่ดี เพราะส่งสัญญาณว่า canonical URL ของเนื้อหาชิ้นหนึ่งควรเปลี่ยนไปเรื่อย ๆ และไม่ได้ประเมินว่ามันเปลี่ยนความถี่ในการดึงไฟล์หรือไม่
Mueller คัดค้านตรงจุดไหนกันแน่
เขาคัดค้านสัญญาณเรื่องตัวตนของ URL โดยเขียนว่า "ผมคิดว่านั่นเป็นความคิดที่ไม่ดี เพราะคุณกำลังส่งสัญญาณว่า canonical URL ของเนื้อหาชิ้นหนึ่งควรเปลี่ยนไปเรื่อย ๆ นั่นไม่ดีกับเสิร์ชเอนจิน และไม่ดีกับการเก็บข้อมูลวัดผลของคุณเอง การมี URL ที่สะอาดและคงที่เป็นเรื่องสำคัญ" แล้วชี้ไปที่หน้า "Cool URIs don't change" ของ Tim Berners-Lee
แล้ว cache busting เป็นวิธีที่ผิดหรือเปล่า
ไม่ผิด Search Engine Journal อธิบายว่ามันเป็นเทคนิคที่ถูกต้องสำหรับไฟล์ CSS, JavaScript และรูปภาพ ซึ่งการเปลี่ยนพารามิเตอร์ทำให้เบราว์เซอร์ดาวน์โหลดไฟล์เวอร์ชันล่าสุดแทนไฟล์เก่าในแคช ปัญหาที่บทความรายงานคือการนำมันไปใช้กับ URL ของ sitemap ซึ่งควรเป็นที่อยู่ที่คงที่
แท็ก lastmod ทำหน้าที่อะไร
Search Engine Journal อธิบายว่า lastmod คือองค์ประกอบที่บอกวันที่ล่าสุดที่ไฟล์ถูกแก้ไข ซึ่งบอกครอว์เลอร์ว่าไฟล์เปลี่ยนไปหรือไม่ และทำให้ครอว์เลอร์โฟกัสไปที่หน้าที่เปลี่ยนแปลงจริง คำอธิบายนี้มาจากสำนักข่าว ส่วน Mueller ไม่ได้พูดถึงค่า lastmod ในบทสนทนาที่บทความรายงานไว้
ถ้าการเก็บข้อมูลช้า ควรวินิจฉัยจากอะไรแทน
เริ่มจาก crawl stats ใน Search Console เวลาตอบสนองของเซิร์ฟเวอร์ อัตราความผิดพลาด และคำถามว่าหน้าเหล่านั้นเปลี่ยนเนื้อหาจริงหรือไม่ ซึ่งแหล่งข่าวไม่ได้พูดถึงแต่ทั้งหมดวัดได้จากตัวเว็บเอง การไปปรับ URL ของ sitemap ไม่ได้แก้ข้อใดในนี้ และยังทำให้ติดตามประวัติการดึงไฟล์ sitemap เดียวกันในระยะยาวไม่ได้อีกด้วย
ก้าวต่อไป
สิ่งที่ทำได้จริงจากรายงานวันที่ 2 กันยายน 2569 ใช้เวลาไม่กี่นาที เปิด sitemap index ยืนยันว่า URL ของ sitemap ลูกทุกอันคงที่และไม่มีพารามิเตอร์ห้อยท้าย ยืนยันว่า URL ที่อยู่ข้างในตรงกับ canonical URL บนหน้าเว็บจริง และตรวจว่าค่า lastmod สะท้อนการเปลี่ยนแปลงจริง ไม่ใช่ผลจากสคริปต์ที่รันทุกคืน ถ้าการเก็บข้อมูลยังดูช้าหลังจากนั้น หลักฐานอยู่ใน crawl stats และ log ของเซิร์ฟเวอร์ ไม่ได้อยู่ในไฟล์ sitemap อ่านรายงานฉบับเต็มได้ที่ Search Engine Journal
