ลิงก์แชร์รูปจากเว็บฝากรูปของคุณจะโผล่ในผลค้นหา Google ไหม? ทดสอบจริง noindex 7 เว็บฝากรูปฟรี

เพื่อนในกลุ่ม LINE ส่งลิงก์เว็บฝากรูปมาให้ดูสลิปโอนเงิน คุณกดเข้าไปดูแล้วก็ลืมเรื่องนี้ไปเลย — แต่ลิงก์นั้นอาจกำลังนอนอยู่ในดัชนีของ Google เงียบๆ รอให้ใครสักคนพิมพ์คำค้นที่ถูกต้องแล้วเจอมันเข้า นี่ไม่ใช่การคาดเดาลอยๆ ปลายเดือนกรกฎาคม 2026 วงการความปลอดภัยไซเบอร์ตื่นตัวกับข่าวหนึ่ง: แค่พิมพ์ site:claude.ai/share ใน Google ก็ขุดเจอบทสนทนา AI ของคนอื่นจำนวนมาก ข้างในมีทั้ง API key, private key คริปโต, เนื้อหาปรึกษากฎหมาย และเรซูเม่

สาเหตุไม่ใช่ถูกแฮก แต่เป็นการตั้งค่าที่ขัดแย้งกันเอง — หน้าแชร์เหล่านั้นถูกตั้งเป็น "ห้ามเก็บข้อมูล" ใน robots.txt พร้อมกับตั้ง X-Robots-Tag: none ไว้ด้วย ปัญหาคือเมื่อ Googlebot ถูก robots.txt กันไว้ที่หน้าประตูแล้ว มันก็เข้าไปในหน้านั้นไม่ได้ตั้งแต่แรก จึงอ่านแท็ก noindex ที่ควรจะมีผลไม่ได้เลย ผลลัพธ์คือหน้าเหล่านี้ถูกค้นพบผ่านลิงก์ภายนอกแล้วเข้าไปอยู่ในดัชนี โดยไม่มีกลไกใดหยุดมันได้ นี่เป็นเหตุการณ์แบบเดียวกันครั้งที่สี่ในรอบปี ต่อจาก ChatGPT (ประเมินว่า 70,000–100,000 บทสนทนา) และ Grok (หลายแสนบทสนทนา)

เรื่องนี้เกี่ยวอะไรกับเว็บฝากรูป? ไม่เกี่ยวโดยตรง — นั่นคือลิงก์แชร์บทสนทนา AI ไม่ใช่รูปภาพ แต่กลไกเหมือนกันเป๊ะ: ฟังก์ชันแชร์แบบไหนก็ตามที่ยึดหลัก "รู้ลิงก์ถึงจะเข้าได้ แต่ไม่ได้กันบอทให้ถูกต้อง" ล้วนเข้าข่ายความเสี่ยงแบบนี้ทั้งนั้น หน้าดูรูปของเว็บฝากรูปก็ทำงานแบบเดียวกัน คือ "รู้ URL แล้วดูได้เลย" ต้องพึ่งสามชั้น robots.txt, meta robots, X-Robots-Tag มากันไว้ ตั้งค่าผิดชั้นใดชั้นหนึ่ง รูปก็หลุดไปอยู่ในผลค้นหาได้เหมือนกัน รูปหลุดมักสังเกตยากกว่าบทสนทนาหลุด เพราะไม่มีใครคิดว่าภาพหน้าจอที่ส่งแบบสบายๆ จะถูกค้นเจอบน Google ได้

ผมเลยลงมือทดสอบจริงดู

สามชั้นกลไกที่ตัดสินว่ารูปจะถูกค้นเจอหรือไม่

ขอพูดเกณฑ์ให้ชัดก่อน ไม่งั้นตารางข้างล่างจะดูเหมือนเดามั่ว การที่ URL หนึ่งจะถูก Google จัดทำดัชนีหรือไม่ ขึ้นอยู่กับสามชั้น:

robots.txt ตัดสินว่าบอทเข้าเส้นทางนี้ได้หรือไม่; แท็ก <meta name="robots"> ในหน้า HTML ตัดสินว่าหลังเข้าไปแล้วควรจัดทำดัชนีหรือไม่; ส่วน header HTTP ที่ชื่อ X-Robots-Tag เป็นคำสั่งจัดทำดัชนีอีกชุดหนึ่งที่แยกอิสระ ผลเหมือนแท็ก meta แต่ไม่ต้องแก้ HTML ทั้งสามชั้นเป็นอิสระจากกัน แต่มักถูกเข้าใจผิดว่าเป็นเรื่องเดียวกัน — นี่คือรากของปัญหาในเหตุการณ์ Claude: robots.txt กันไว้ ส่วน X-Robots-Tag ตั้งถูกต้อง แต่ไม่มีบอทตัวไหนอ่านมันได้

จำหลักนี้ไว้ให้ดี: จะให้ noindex มีผล บอทต้อง "เข้าได้" ก่อน ถ้าคุณ disallow เส้นทางหนึ่งใน robots.txt พร้อมกับหวังว่าแท็ก noindex ในเส้นทางนั้นจะทำงาน มันคือการออกแบบที่ขัดแย้งในตัวเอง สุดท้ายมักไม่มีชั้นไหนทำงานเลย

วิธีทดสอบ: ทำอะไรไปบ้าง ไม่ได้ทำอะไรบ้าง

พูดตรงๆ การทดสอบแบบนี้กลัวที่สุดคือ "เขียนจากความจำ" เลยขอเปิดเผยวิธีการก่อน: เดือนกันยายน 2026 ผมใช้ User-Agent ของเบราว์เซอร์รัน curl -I กับหน้าดูรูปของแต่ละบริการเพื่อดึง header HTTP (ดู X-Robots-Tag) แล้วดึง HTML ทั้งหน้าเพื่อหา <meta name="robots"> และ curl ดึง robots.txt ของแต่ละบริการโดยตรง สำหรับบริการที่ render เนื้อหาด้วย JavaScript จน curl ดึงลิงก์จริงไม่ได้ (เช่น บล็อกแนะนำในหน้าแรกของ Imgur) ผมเปลี่ยนไปใช้เครื่องมือ automation เบราว์เซอร์โหลดหน้าจริงแล้วดึงลิงก์แทน

ส่วนว่าจะค้นเจอจริงไหม ผมรันการตรวจสอบผ่านการค้นหา Google แยกต่างหาก — แต่ต้องบอกข้อจำกัดตรงนี้อย่างตรงไปตรงมา: เครื่องมือค้นหาที่ผมใช้ถูกโดเมน imgur.com บล็อกการเข้าถึง (ไม่ใช่ Google บล็อก แต่บอทของเครื่องมือค้นหาถูกระบบป้องกันของ imgur บล็อก) ดังนั้นช่อง "ถูกค้นเจอแล้วหรือยัง" ของ Imgur ผมไม่สามารถตรวจสอบด้วยวิธีเดียวกันได้ ทำได้แค่ตัดสินจากการตั้งค่าทางเทคนิคว่า "ในทางทฤษฎีจัดทำดัชนีได้" และระบุไว้ในตารางอย่างตรงไปตรงมา นี่ไม่ใช่สิ่งที่ผมอยากปิดบัง แต่เป็นข้อจำกัดของเครื่องมือ พูดให้ชัดดีกว่าแกล้งทำเป็นว่าทดสอบแล้ว

ผลการทดสอบ

ตารางข้างล่างนี้ ทุกแถวคือ URL และการตอบกลับที่ผมดึงมาจริงในรอบนี้ ไม่ได้เขียนจากเอกสาร

บริการ	ตัวอย่างหน้าดูรูป	ข้อจำกัดใน robots.txt	meta robots / X-Robots-Tag	สถานะการจัดทำดัชนี (ทดสอบ 2026-09)
ImgBB	ibb.co/xxx	robots.txt ว่างเปล่าทั้งหมด	ไม่มีการตั้งค่าใดๆ	ถูกจัดทำดัชนีแล้ว — ค้นด้วยคำทั่วไปเจอหน้ารูปจริงหลายรายการทันที
Postimages	postimg.cc/xxx	robots.txt ว่างเปล่าทั้งหมด	ไม่มีการตั้งค่าใดๆ	ถูกจัดทำดัชนีแล้ว — เจอหน้ารูปพร้อมชื่อไฟล์หลายรายการเช่นกัน
Flickr	flickr.com/photos/user/id	บอทที่ระบุชื่อ (รวม Googlebot) ได้รับอนุญาตให้เข้า /photos/	มีแค่ noarchive ไม่มี noindex	ถูกจัดทำดัชนีแล้ว — ค้นเจอหน้ารูปเฉพาะของผู้ใช้รายหนึ่งจริง
ลิงก์แชร์ Google Photos	photos.app.goo.gl/xxx	เส้นทาง /share/ ไม่ถูก robots.txt กันไว้อย่างชัดเจน	หน้า render ด้วย JS, curl ดึงเนื้อหามาตัดสินไม่ได้	ถูกจัดทำดัชนีแล้ว — ค้นหาเจอลิงก์แชร์ของคนอื่น บางลิงก์ยังเปิดได้
Imgur	imgur.com/gallery/xxx	ไม่ได้กันเส้นทาง /gallery/	ไม่มีการตั้งค่าใดๆ (ค่าเริ่มต้นให้จัดทำดัชนีได้)	ทางเทคนิคจัดทำดัชนีได้ แต่เพราะเครื่องมือค้นหาถูก imgur.com บล็อก จึงยืนยันโดยตรงไม่ได้ว่าถูกจัดทำดัชนีแล้วหรือยัง
Catbox	files.catbox.moe/xxx	กันบางเส้นทางจัดการระบบ และระบุชื่อกัน ClaudeBot / GPTBot อย่างชัดเจน	ไฟล์เป็นลิงก์ตรงแบบไบนารีล้วน ไม่มีหน้า HTML ให้ใส่แท็ก meta	โดยโครงสร้างไม่มี "หน้าดูที่จัดทำดัชนีได้" เลย — ไม่มีหน้า ก็ไม่มีเรื่อง meta robots
lpic.cc	lpic.cc/short-code	Allow: / (เปิดในระดับหน้าแรก)	ซอร์สโค้ดหน้าดูตั้งค่าชัดเจนว่า index: false, follow: true	noindex ชัดเจน — ออกแบบมาตั้งแต่แรกให้หน้าดูไม่เข้าดัชนี

พอเห็นแถว Google Photos บอกตรงๆ ว่าผมนิ่งไปแป๊บหนึ่ง

เจาะทีละบริการ: ปัญหาอยู่ที่ชั้นไหน

ImgBB กับ Postimages เป็นตัวอย่างสวนทางที่ชัดเจนที่สุดในการทดสอบครั้งนี้: robots.txt ตอบกลับว่างเปล่าโดยตรง หมายความว่าไม่มีข้อจำกัดเส้นทางใดๆ เลย หน้าเว็บก็ไม่มีแท็ก meta robots ใดๆ ไม่มีข้อจำกัดบวกไม่มีแท็ก เท่ากับ "เปิดเต็มที่" — นี่เป็นค่าเริ่มต้น ไม่ใช่ตัวเลือกที่ผู้ใช้ปิดได้ตอนอัปโหลด ตอนค้นหาผมแทบจะเจอทันที ผลลัพธ์หลายอันมีชื่อหน้าเป็นชื่อไฟล์ดิบที่กล้องมือถือสร้างขึ้น (แบบ IMG_ ตามด้วยชุดวันเวลา) ดูปุ๊บก็รู้ว่าเป็นรูปที่อัปโหลดตรงจากมือถือ

Flickr ซับซ้อนกว่า และเข้าใจผิดได้ง่ายกว่า robots.txt ของมันมีบอทที่ระบุชื่อเกือบสี่สิบตัว (รวม Googlebot) กลุ่มที่ระบุชื่อนี้กันเฉพาะบัญชีและหน้าฟังก์ชันบางอย่างเท่านั้น เส้นทาง /photos/ชื่อผู้ใช้/id-รูป ของผู้ใช้ทั่วไปไม่อยู่ในรายการที่ถูกกัน; ตัวหน้ามีแค่ noarchive (ไม่เก็บภาพจำลองหน้าเว็บ) ไม่มี noindex เลย นี่คือตัวอย่างจริง: หน้ารูปที่ผมค้นเจอในรอบทดสอบนี้คือโพสต์สอน "วิธีแชร์รูป Flickr" ของบัญชีทางการเสียเอง — ขนาดหน้าที่สอนวิธีแชร์เองก็ยังถูกค้นเจอ ฟังดูย้อนแย้งอยู่เหมือนกัน

ลิงก์แชร์ Google Photos คือรายการที่ทำให้ผมกังวลที่สุดในการทดสอบครั้งนี้ ต้องเน้นย้ำว่า: ลิงก์แชร์มองผิวเผินเหมือนเป็นกลไกส่วนตัวแบบ "ให้ใครก็เห็นเฉพาะคนนั้น" แต่ผมใช้แค่คำค้นทั่วไป ไม่ต้องใช้คำสั่งพิเศษใดๆ ก็เจอลิงก์แชร์แบบสั้น photos.app.goo.gl ของคนอื่นในผลค้นหา (ด้วยเหตุผลด้านความเป็นส่วนตัว จึงไม่ขอระบุลิงก์จริงในที่นี้) บางลิงก์กดเข้าไปแล้วต้องล็อกอิน แสดงว่าสิทธิ์การแชร์ถูกเปลี่ยนหรือหมดอายุไปแล้ว บางลิงก์ยังเปิดได้ปกติ — หมายความว่าลิงก์ที่ "แชร์ส่วนตัวให้คนเฉพาะเจาะจง" เคยหรือยังคงถูกค้นพบผ่านการค้นหาสาธารณะได้ นี่คือความเสี่ยงรูปแบบเดียวกับกรณีบทสนทนา Claude หลุด: ตัวลิงก์เองไม่มีเจตนาเปิดเผยต่อสาธารณะ แต่รายละเอียดกฎของบอทต่างหากที่ตัดสินว่ามันจะถูกเครื่องมือค้นหา "เก็บไป" หรือไม่

Catbox กลับเป็นกรณีพิเศษ มันไม่มี "หน้าดู" แยกต่างหากเหมือนเจ้าอื่น — อัปโหลดเสร็จได้ URL ลิงก์ตรงไปยังไฟล์ทันที เปิดมาก็คือรูปเลย ไม่มีเปลือก HTML ใดๆ ให้ใส่แท็ก meta robots นี่ทำให้การตรวจสอบแบบ "meta robots" แบบดั้งเดิมใช้ไม่ได้เลยที่นี่ แต่ไม่ได้แปลว่ามันปลอดภัยกว่า ความเสี่ยงแค่ย้ายไปอยู่ที่อื่น: Google Images ยังอาจจัดทำดัชนี URL ไฟล์ตรงได้เช่นกัน เพียงแต่เกณฑ์การตัดสินต่างจากหน้า HTML ทั่วไป ส่วนนี้ผมไม่พบวิธีตรวจสอบที่น่าเชื่อถือ พูดตรงๆ คือตรวจไม่ได้ ผมไม่ขอมั่วตัวเลขขึ้นมาเอง

lpic.cc ผลิตภัณฑ์ของผมเองก็ทดสอบไปด้วย จะไปตรวจแต่คนอื่นอย่างเดียวไม่ได้ ดูซอร์สโค้ดจะเห็นว่า metadata ของหน้าดูตั้งไว้ชัดเจนว่า robots: { index: false, follow: true } — หมายความว่าแม้ short code ของคุณจะถูกคนอื่นแชร์ออกไปแล้วถูกบอทของเครื่องมือค้นหาเก็บได้ ตัวหน้าเว็บเองก็ยังบอก Google อย่างจริงจังว่า "อย่าจัดทำดัชนีฉัน" นี่เป็นพฤติกรรมที่กำหนดไว้ตั้งแต่ขั้นตอนออกแบบ ไม่ใช่สิ่งที่เพิ่งเสริมชั่วคราวเพื่อการทดสอบครั้งนี้ แต่พูดตรงๆ ว่า noindex ป้องกันได้แค่การถูกเก็บเข้าผลค้นหา ป้องกันไม่ได้เรื่อง "รู้ URL แล้วเปิดได้" ในตัวมันเอง — นี่คือเหตุผลที่ฟีเจอร์ป้องกันด้วยรหัสผ่านมีอยู่ ต้องใช้สองอย่างร่วมกันถึงจะครบ

นี่หมายถึงความเสี่ยงจริงอะไรสำหรับคุณ

แปลรายละเอียดทางเทคนิคข้างบนเป็นภาษาบ้านๆ: ถ้าคุณอัปโหลดรูปที่มีข้อมูลส่วนตัว ใบเสร็จ ภาพหน้าจอแชท บัตรประชาชน ไปยัง ImgBB หรือ Postimages ซึ่งเป็นเว็บที่เปิดดัชนีทั้งหมดโดยค่าเริ่มต้น ในทางทฤษฎีใครก็ตามสามารถค้นเจอมันได้แค่ด้วยคำค้นหรือข้อความบางส่วนในรูป — ไม่ต้องได้ลิงก์ที่คุณแชร์เลย แค่เครื่องมือค้นหาเคยเก็บไปแล้ว มันก็รออยู่ตรงนั้น สิ่งนี้ไม่ต่างอะไรกับการที่คุณเปิดไฟล์เป็น "สาธารณะ" แล้วอัปโหลดขึ้นเว็บของตัวเองโดยตรง

หลายคนมองข้ามสถานการณ์ที่แอบแฝงยิ่งกว่า: เวลาโพสต์ในกลุ่ม Facebook หรือเว็บบอร์ดอย่าง Pantip แล้วแนบลิงก์เว็บฝากรูปเข้าไป มักไม่ได้คิดตั้งใจว่า "รูปนี้จะถูกค้นเจอไหม" แต่ถ้ารูปมีชื่อ ที่อยู่ เลขบัตรประชาชนบางส่วนของคุณ (พบบ่อยในภาพหน้าจอเอกสารยื่นภาษี ขอคืนสินค้า หรือทำธุรกรรม) พอถูกเครื่องมือค้นหาเก็บไปแล้ว ข้อมูลเหล่านี้จะอยู่บนอินเทอร์เน็ตแทบถาวรจนกว่าคุณจะพบเองแล้วขอถอดออก — ทั้งที่คนส่วนใหญ่ไม่รู้ด้วยซ้ำว่าต้องไปแจ้งที่ไหน

ในแง่กฎหมาย พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) ของไทย กำหนดให้การประมวลผลข้อมูลส่วนบุคคลต้องได้รับความยินยอมจากเจ้าของข้อมูล แต่กฎหมายนี้ผูกพันผู้ควบคุมข้อมูลในไทย ส่วนเว็บฝากรูปต่างประเทศที่ทำให้รูปของคุณหลุดไปอยู่ในเครื่องมือค้นหา เป็นเรื่องการตั้งค่าทางเทคนิคของตัวบริการเอง ไม่ใช่สิ่งที่ PDPA จะป้องกันไว้ล่วงหน้าได้

วิธีปกป้องลิงก์แชร์ของคุณ

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

• ลองค้นหาด้วยตัวเองก่อน ก่อนและหลังอัปโหลด เอาชื่อไฟล์หรือข้อความในรูปไปค้นบน Google สักครั้ง ดูว่ามีร่องรอยถูกจัดทำดัชนีหรือไม่
• เนื้อหาที่ละเอียดอ่อนควรเลี่ยงเว็บฝากรูปที่เปิดดัชนีทั้งหมดโดยค่าเริ่มต้น เปลี่ยนไปใช้บริการที่ระบุ noindex ชัดเจนหรือรองรับการป้องกันด้วยรหัสผ่าน
• ตั้งวันหมดอายุให้ลิงก์แชร์อย่างจริงจัง อย่าพึ่งสมมติฐานที่ว่า "ยังไงก็ไม่มีใครรู้ URL" — เหตุการณ์ Claude พิสูจน์แล้วว่าบอทไม่จำเป็นต้องรู้ URL เอง แค่มีลิงก์ภายนอกใดๆ ชี้ไปที่นั่นก็พอ

ถ้าคุณกำลังหาเว็บฝากรูปที่มีทั้ง "ลิงก์แชร์ไม่เข้าดัชนีโดยค่าเริ่มต้น" และ "ป้องกันด้วยรหัสผ่าน" มาในตัว lpic.cc ออกแบบหน้าดูให้เป็น noindex อยู่แล้ว บวกกับฟีเจอร์ป้องกันด้วยรหัสผ่าน เท่ากับได้สองชั้นป้องกันข้างต้นมาในทีเดียว แต่ก็ต้องพูดถึงข้อจำกัดให้ชัด: แผนฟรีมีเดียหมดอายุใน 30 วันหลังอัปโหลดโดยค่าเริ่มต้น (ฟอร์มอัปโหลดเปิด "ต่ออายุอัตโนมัติเมื่อมีการดู" ไว้เป็นค่าเริ่มต้น) หมดอายุแล้วจะถูกลบ และบริการนี้พึ่งพารายได้จากโฆษณาในการดำเนินงาน — สิ่งเหล่านี้ควรรู้ล่วงหน้า ไม่ใช่มาพบทีหลังหลังอัปโหลดเสร็จแล้ว

คำถามที่พบบ่อย

Q1: ตั้งค่า noindex แล้วรูปจะไม่ถูกค้นเจอเด็ดขาดไหม? ไม่ถึงขั้นเด็ดขาด noindex เป็นการ "ขอร้อง" ให้บอทอย่าจัดทำดัชนี ส่วนใหญ่ Google จะทำตาม แต่มีเงื่อนไขว่าบอทต้องอ่านแท็กนี้ได้จริง — ถ้า robots.txt กันเส้นทางนั้นไว้ด้วย บอทก็เข้าไม่ได้ตั้งแต่แรก จึงไม่เห็น noindex เลย นี่คือสาเหตุตรงของเหตุการณ์ Claude

Q2: เว็บฝากรูปแบบ Catbox ที่ลิงก์ตรงไปไฟล์เลย รูปจะถูกค้นเจอไหม? ตัดสินด้วย meta robots ไม่ได้ เพราะไม่มีหน้า HTML ในทางทฤษฎี Google Images อาจจัดทำดัชนี URL ไฟล์ตรงได้ แต่วิธีตรวจสอบต่างจากหน้าเว็บทั่วไป การทดสอบครั้งนี้ยังไม่พบวิธีตรวจสอบที่เชื่อถือได้ จึงไม่ขอฟันธงในสิ่งที่ยังไม่ได้พิสูจน์

Q3: อัปโหลดรูปไปที่ ImgBB แล้วพบว่าถูกค้นเจอ ลบออกจากดัชนีได้ไหม? ลบรูปต้นฉบับก่อนให้ URL ใช้ไม่ได้ แล้วส่งคำขอผ่านเครื่องมือ "นำ URL ออก" ใน Google Search Console จะเร็วกว่ารอให้บอทมาเก็บซ้ำตามธรรมชาติมาก

Q4: บทความนี้ทดสอบผลลัพธ์ของเดือนกันยายน 2026 ถ้าแพลตฟอร์มเปลี่ยนการตั้งค่าในอนาคตล่ะ? robots.txt และแท็ก meta เปลี่ยนได้ตลอดเวลา การตั้งค่าแบบนี้ไม่มีการรับประกันถาวรอยู่แล้ว วิธีที่แนะนำไม่ใช่ท่องจำตารางนี้ แต่ลงมือใช้ curl -I หรือเครื่องมือนักพัฒนาของเบราว์เซอร์ตรวจสอบเองอีกครั้ง — วิธีการอยู่ทนกว่าข้อสรุป

Q5: ทำไม Flickr อนุญาต Googlebot แต่กันบอทส่วนใหญ่อื่นๆ? เป็นทางเลือกที่ตั้งใจ — อนุญาตให้เครื่องมือค้นหาหลักจัดทำดัชนีเพื่อรักษาปริมาณผู้เข้าชมและการมองเห็น ในขณะเดียวกันก็กันบอทบุคคลที่สามที่ไม่ระบุชื่อเพื่อลดความเสี่ยงเนื้อหาถูกนำไปใช้ในทางที่ผิด สองเรื่องนี้เป็นการชั่งน้ำหนักคนละแบบ ไม่ใช่เรื่องเดียวกัน

แหล่งอ้างอิง

• รายงานเหตุการณ์ลิงก์แชร์บทสนทนา Claude ถูก Google จัดทำดัชนี (2026-07-29)
• robots.txt ของ Imgur, ImgBB (ibb.co), Postimages (postimg.cc), Flickr, Google Photos (photos.google.com), Catbox (catbox.moe) — เข้าถึงโดยตรงเดือนกันยายน 2026
• header HTTP และซอร์สโค้ด HTML ของหน้าดูแต่ละบริการข้างต้น — ทดสอบจริงด้วย curl และเครื่องมือ automation เบราว์เซอร์เดือนกันยายน 2026
• ซอร์สโค้ด metadata หน้าดูของ lpic.cc (app/(public)/[locale]/[code]/page.tsx)