Google วางแผนรองรับสัญญาณปฏิเสธการฝึก AI แบบใช้ร่วมกันใน robots.txt ในปี 2570

Google วางแผนรองรับสัญญาณปฏิเสธการฝึก AI แบบใช้ร่วมกันใน robots.txt ในปี 2570

geoOctober 31, 2026
By Antonio Fernandez

สรุปสั้น ๆ (TL;DR)

  • บล็อก Search Central ของ Google ระบุเมื่อ 30 ตุลาคม 2569 ว่า Google ตั้งเป้ารองรับ token การฝึกแบบใช้ร่วมกันของ AIPREF ในปี 2570 ส่วนเอกสาร crawler ระบุว่าเป็นต้นปี 2570
  • ตามแผนของ Google การปฏิเสธใน robots.txt ที่เขียนว่า User-Agent: __usage_ai-training โดยไม่มีกฎ Google-Extended จะถูกอ่านเหมือน disallow Google-Extended
  • ร่าง IETF ของ Kevin Kelley จาก Anthropic ลงวันที่ 30 ตุลาคม 2569 และหมดอายุ 3 พฤษภาคม 2570 ระบุว่ากลุ่ม User-Agent: * ไม่ตรงกับ token นี้
  • เอกสารของ Google ระบุว่า Google-Extended ไม่มีผลต่อการปรากฏหรืออันดับใน Google Search ส่วนบล็อกของ Google ระบุว่าเว็บไซต์ที่ allow ไว้อย่างเจาะจงมีสิทธิ์ได้ grounding ใน Gemini Apps

Google ประกาศเมื่อวันที่ 30 ตุลาคม 2569 ว่ามีแผนจะรองรับสัญญาณปฏิเสธการนำเนื้อหาไปฝึก AI แบบใช้ร่วมกันหลายบริษัท ซึ่งเขียนไว้ในไฟล์ robots.txt และเมื่อเว็บไซต์ใช้สัญญาณนี้เพื่อปฏิเสธการฝึก (โดยไม่ได้ระบุ Google-Extended แยกไว้) Google จะตีความเหมือนกับว่าเว็บไซต์นั้นได้ disallow Google-Extended ไว้แล้ว ประกาศนี้โพสต์โดย John Mueller ตำแหน่ง Google Search Advocate บน บล็อก Google Search Central ระบุเป้าหมายว่าเป็นปี 2570 และบอกว่า Google ตั้งใจจะรองรับการควบคุมนี้ "ร่วมกับผู้ให้บริการ AI รายอื่น"

สัญญาณนี้มาจากงานของคณะทำงาน AI Preferences (AIPREF) ใน Internet Engineering Task Force (IETF) รูปแบบคือ "policy token" ตัวใหม่ใน robots.txt ชื่อ __usage_ai-training ที่บริษัท AI ทุกรายที่เข้าร่วมสามารถอ่านได้ บทความนี้อธิบายว่า token นี้คืออะไร เขียนใน robots.txt อย่างไร Google บอกว่าจะจับคู่กับการควบคุมของตัวเองอย่างไร และประกาศนี้ไม่ได้พูดถึงเรื่องอะไรบ้าง

Google ประกาศอะไรเมื่อวันที่ 30 ตุลาคม 2569

โพสต์บน Search Central ค่อนข้างสั้น ประเด็นหลักตามที่ Google เขียนไว้มีดังนี้

  • Google มีแผนจะรองรับ "การควบคุมการฝึก AI แบบใช้ร่วมกันใน robots.txt" เพื่อให้เจ้าของเว็บไซต์แสดงความต้องการเรื่องการฝึก AI ต่อผู้ให้บริการ AI หลายรายได้ในขั้นตอนเดียว
  • การควบคุมนี้อิงจากงานของคณะทำงาน AIPREF ใน IETF
  • แทนที่จะต้องเขียนคำสั่งแยกสำหรับนักพัฒนา AI แต่ละราย เจ้าของเว็บไซต์จะใช้ "policy token" ตัวเดียวใน robots.txt เพื่อกำหนดความต้องการกว้าง ๆ กับผู้ให้บริการทุกรายที่เข้าร่วมได้
  • ถ้าเว็บไซต์ใช้ token นี้เพื่อปฏิเสธการฝึก และไม่ได้ระบุ Google-Extended ไว้อย่างชัดเจน Google "มีแผนจะตีความเหมือนกับว่าผู้เผยแพร่ได้ disallow Google-Extended"
  • การควบคุมเฉพาะของแต่ละบริษัทยังทำงานควบคู่ไปกับสัญญาณร่วมนี้ และ "เว็บไซต์ที่ allow Google-Extended ไว้อย่างเจาะจงมีสิทธิ์ปรากฏในคำตอบและได้รับคลิกผ่าน grounding ใน Gemini Apps"
  • Google เรียกสิ่งนี้ว่า "ข้อเสนอฉบับร่าง" ที่สะท้อนความเห็นจากผู้เผยแพร่ กลุ่มภาคประชาสังคม หน่วยงานกำกับดูแล และผู้มีส่วนได้ส่วนเสียอื่น และบอกว่าจะทำงานเรื่องการทำให้เป็นมาตรฐานต่อผ่านคณะทำงานของ IETF
  • Google ระบุว่าข้อเสนอนี้สอดคล้องกับ EU Code of Practice สำหรับผู้ให้บริการโมเดล AI อเนกประสงค์ (GPAI) ภายใต้ EU AI Act ซึ่งยอมรับ robots.txt เป็นวิธีหลักที่ผู้เผยแพร่เว็บใช้แสดงความต้องการแบบที่เครื่องอ่านได้

เรื่องเวลา บล็อกระบุว่า Google ตั้งเป้าจะรองรับการควบคุมนี้ในปี 2570 และจะแจ้งความคืบหน้าเป็นระยะ ส่วนหมายเหตุที่เพิ่มเข้ามาในเอกสาร crawler ของ Google ตรงหัวข้อ Google-Extended ระบุละเอียดกว่าเล็กน้อย คือ Google ตั้งใจจะรองรับสัญญาณ AIPREF ซึ่งเขียนเป็น "user-agent: __usage_ai-training" ในช่วงต้นปี 2570 ทั้งสองหน้าไม่ได้ระบุวันหรือเดือนที่แน่นอน

token __usage_ai-training คืออะไร

ไวยากรณ์ของ token นี้กำหนดไว้ใน Internet-Draft ของ IETF ชื่อ draft-kelley-aipref-training-preference-signal-00 ลงวันที่ 30 ตุลาคม 2569 เขียนโดย Kevin Kelley จาก Anthropic และโพสต์ของ Google ลิงก์ไปที่เอกสารนี้ เช่นเดียวกับ Internet-Draft ทุกฉบับ เอกสารนี้ยังเป็นงานที่อยู่ระหว่างดำเนินการ และฉบับนี้จะหมดอายุในวันที่ 3 พฤษภาคม 2570 หากไม่มีการปรับปรุงหรือแทนที่

แนวคิดหลักของร่างนี้คือ เจ้าของเว็บไซต์เขียนกลุ่มคำสั่ง robots.txt ตามปกติ แต่บรรทัด User-Agent ระบุ "วัตถุประสงค์การใช้งาน" แทนชื่อ crawler ร่างนี้ไม่ได้เพิ่มชื่อคำสั่งใหม่และไม่ได้เพิ่มไวยากรณ์ใหม่ รูปแบบ path กฎ longest-match และโครงสร้างกลุ่มของ RFC 9309 ซึ่งเป็นมาตรฐานของ robots.txt ยังคงเหมือนเดิมทั้งหมด ตัวอย่างในร่างมีสามบรรทัด

User-Agent: __usage_ai-training

Disallow: /

Allow: /press-kit/

ตามร่างนี้ ไฟล์ดังกล่าวแสดงความต้องการ "ไม่ให้" นำเนื้อหาไปฝึก AI สำหรับทุก path ยกเว้น path ที่อยู่ใต้ /press-kit/ ซึ่งแสดงความต้องการ "ให้" นำไปฝึกได้ ถ้าต้องการปฏิเสธทั้งเว็บไซต์ ก็ใช้เพียงสองบรรทัดแรก

ความหมายของคำว่า "AI training" นำมาจากร่างคำศัพท์ของ AIPREF (draft-ietf-aipref-vocab-08) ซึ่งนิยาม AI training ว่า "การใช้ asset เพื่อปรับพารามิเตอร์ที่เรียนรู้แล้วของโมเดล generative AI" การฝึกโมเดลที่ใช้เฉพาะงานที่ไม่ใช่การสร้างเนื้อหาไม่นับรวม แม้โมเดลนั้นจะสามารถสร้างเนื้อหาได้ก็ตาม และโมเดลที่ใช้สำหรับการจัดหมวดหมู่ การจัดอันดับ หรือการให้คะแนน ไม่ถือเป็นโมเดล generative AI แม้จะเขียนเหตุผลประกอบผลลัพธ์ออกมาด้วยก็ตาม

การอ่าน robots.txt ตามร่างนี้ทำงานอย่างไร

ร่างของ Kelley กำหนดกฎหลายข้อที่ตัดสินว่าไฟล์หนึ่ง ๆ แสดงความต้องการอะไรจริง ๆ กฎเหล่านี้สำคัญกว่าพาดหัวข่าว เพราะเป็นตัวตัดสินว่า robots.txt ที่มีอยู่ตอนนี้แสดงความต้องการเรื่องการฝึก AI ไว้แล้วหรือยัง

  • การค้นหาใช้การจับคู่ path แบบ RFC 9309 ตามปกติ path ที่ถูก disallow หมายถึงความต้องการไม่ให้ฝึก AI ด้วย path นั้น ส่วน path ที่ allow หมายถึงความต้องการให้ฝึกได้
  • กลุ่ม wildcard ไม่นับ ร่างระบุว่า "User-Agent: *" ต้องไม่ถูกตีความว่าตรงกับ policy token ดังนั้นกฎกว้าง ๆ ที่เขียนไว้สำหรับ crawler ทุกตัวจึงไม่ได้บอกอะไรเกี่ยวกับการฝึก AI เลย
  • ถ้าไม่มีกลุ่มใดในไฟล์ระบุ __usage_ai-training ก็ถือว่ายังไม่ได้แสดงความต้องการใด ๆ อีเมลที่ Kelley ใช้ประกาศร่างนี้ในเมลลิงลิสต์ ai-control ของ IETF ระบุว่าข้อนี้เป็นจริงกับ robots.txt ทุกไฟล์ที่เผยแพร่อยู่ในปัจจุบัน
  • ผู้ใช้สัญญาณต้องจับคู่ token แบบตรงตัว โดยไม่สนตัวพิมพ์เล็กพิมพ์ใหญ่ เครื่องหมายขีดล่างสองตัวข้างหน้ามีไว้เพื่อลดโอกาสที่จะจับคู่ผิดโดยบังเอิญ
  • กลุ่มเดียวสามารถระบุ policy token ได้หลายตัว และใส่ policy token ปนกับชื่อ crawler ปกติในกลุ่มเดียวกันได้
  • ไฟล์ robots.txt ที่ใช้บังคับอยู่ในขณะที่ดึงเนื้อหามา คือไฟล์ที่กำหนดความต้องการของเนื้อหาชิ้นนั้น

เป็นความต้องการเรื่องการใช้งาน ไม่ใช่การควบคุมการ crawl

ร่างนี้แยกสองเรื่องออกจากกันชัดเจน กฎที่เขียนไว้สำหรับชื่อ crawler แต่ละตัวยังคงเป็นตัวตัดสินว่า crawler นั้นดึงหน้าเว็บได้หรือไม่ "เหมือนกับในกรณีที่ไม่มีเอกสารนี้" ส่วน token ใหม่บอกว่าเนื้อหาที่ดึงไปแล้วจะถูกนำไปใช้อย่างไร ร่างเขียนตรง ๆ ว่า token นี้ "ไม่ใช่คำสั่งสำหรับพฤติกรรมการ crawl" บริษัทที่ crawl เพื่อการฝึกเพียงอย่างเดียว อาจเลือกไม่ดึงหน้าที่แสดงความต้องการไม่ให้ฝึกไว้ได้ แต่ไม่มีอะไรบังคับให้ต้องทำ เว็บไซต์ที่ต้องการหยุดการดึงข้อมูลจริง ๆ ยังต้องบล็อก crawler ตามชื่อเหมือนเดิม

ร่างนี้ยังกำหนดว่าสัญญาณร่วมอยู่ร่วมกับการควบคุมเดิมของแต่ละบริษัทอย่างไร การแสดงความต้องการแบบเจาะจงควรมีลำดับความสำคัญเหนือแบบทั่วไป และบริษัทหนึ่งอาจประกาศว่าจะถือ token เฉพาะของตัวเองว่าเจาะจงกว่า token ร่วม นอกจากนี้ข้อตกลงส่วนตัวระหว่างคู่สัญญาสามารถแทนที่ความต้องการที่แสดงผ่านกลไกนี้ได้ แผนของ Google เป็นไปตามรูปแบบนี้ คือกฎ Google-Extended ที่ระบุไว้ชัดเจนจะมีผลเหนือกว่า และ token ร่วมจะเข้ามามีผลเฉพาะเมื่อไม่มีการระบุ Google-Extended

Google จะจับคู่ token นี้กับ Google-Extended อย่างไร

Google เปิดให้ใช้ Google-Extended เป็นตัวควบคุมการฝึก AI มาตั้งแต่ปี 2566 เอกสาร crawler ของ Google อธิบายว่าเป็น product token แบบแยกเดี่ยว ไม่มี user agent ของ HTTP แยกต่างหาก ใช้จัดการว่าเนื้อหาที่ Google crawl มา จะถูกนำไปฝึก Gemini รุ่นต่อ ๆ ไปที่ขับเคลื่อน Gemini Apps และ Vertex AI API for Gemini ได้หรือไม่ หน้าเดียวกันระบุว่า Google-Extended ยังควบคุม grounding ใน Gemini Apps และใน Grounding with Google Search บน Vertex AI ด้วย และ Google-Extended "ไม่มีผลต่อการปรากฏของเว็บไซต์ใน Google Search และไม่ได้ใช้เป็นสัญญาณจัดอันดับใน Google Search"

ตารางด้านล่างสรุปสถานะของ robots.txt ที่ประกาศและร่างของ IETF อธิบายไว้ พร้อมผลของแต่ละกรณี คอลัมน์ขวานำมาจากโพสต์และเอกสารของ Google

Google จะจับคู่ token นี้กับ Google-Extended อย่างไร
สิ่งที่อยู่ในไฟล์ robots.txtผลลัพธ์ ตาม Google และร่างของ IETF
ไม่มีกลุ่ม __usage_ai-training เลย (ทุกไฟล์ในปัจจุบัน ตามที่ผู้เขียนร่างระบุ)ไม่มีการแสดงความต้องการร่วม กฎ Google-Extended ถ้ามี ยังใช้ตามเดิม
disallow __usage_ai-training และไม่มีกฎ Google-ExtendedGoogle มีแผนจะถือว่าเหมือน disallow Google-Extended (ตั้งแต่ปี 2570)
disallow __usage_ai-training และ allow Google-Extended ไว้ชัดเจนการควบคุมเฉพาะบริษัทยังทำงาน Google ระบุว่าเว็บไซต์แบบนี้มีสิทธิ์ได้ grounding และคลิกใน Gemini Apps
มีเพียงกลุ่ม "User-Agent: *"ไม่ถูกอ่านเป็นความต้องการเรื่องการฝึก ร่างห้ามไม่ให้กลุ่ม wildcard ตรงกับ token
disallow หรือ allow Google-Extendedตามเอกสาร Google ไม่มีผลต่อการปรากฏใน Google Search และไม่ใช่สัญญาณจัดอันดับของ Search

บทวิเคราะห์ ไม่ใช่คำกล่าวของ Google: เมื่ออ่านโพสต์และหน้าเอกสาร crawler ประกอบกัน การปฏิเสธผ่าน token ร่วมโดยไม่มีบรรทัด Google-Extended มีผลกว้างกว่าที่คำว่า "การฝึก" ฟังดู เพราะ Google-Extended ครอบคลุมทั้งการฝึกและ grounding ของ Gemini เว็บไซต์ที่ปฏิเสธผ่าน token ร่วมเพียงอย่างเดียว ตามการจับคู่ที่ Google ประกาศไว้ ก็จะออกจาก grounding ใน Gemini Apps ไปด้วย นี่อาจเป็นเหตุผลที่โพสต์ระบุชัดว่าเว็บไซต์ที่ allow Google-Extended ไว้อย่างชัดเจนยังมีสิทธิ์ได้ grounding และคลิกในส่วนนั้น

สิ่งที่ประกาศนี้ไม่ได้บอก

มีหลายคำถามที่เจ้าของเว็บไซต์น่าจะถาม แต่โพสต์บน Search Central ไม่ได้ตอบ แต่ละข้อด้านล่างคือช่องว่างในแหล่งข่าว ไม่ใช่การบอกใบ้ถึงแผนของ Google

  • ไม่มีการพูดถึง AI Overviews และ AI Mode โพสต์พูดถึงเพียงการฝึกและ grounding ใน Gemini Apps เอกสาร Google-Extended ระบุว่า token นี้ไม่มีผลต่อการปรากฏใน Google Search แต่ทั้งสองหน้าไม่ได้กล่าวถึง AI Overviews หรือ AI Mode โดยตรง
  • โพสต์ไม่ได้บอกว่า Google จะอ่านการ allow แบบชัดเจนบน token ร่วม หรือการผสม Allow กับ Disallow ในระดับ path อย่างไร นอกเหนือจากกรณีปฏิเสธทั่วไป
  • ไม่มีวันเปิดใช้ที่แน่นอน มีเพียง "ปี 2570" ในบล็อก และ "ต้นปี 2570" ในเอกสาร
  • ไม่มีข้อมูลเรื่องการรายงานผล เช่น Search Console จะแสดงหรือไม่ว่า Google ตรวจพบความต้องการแบบใด
  • โพสต์ไม่ได้ระบุชื่อ "ผู้ให้บริการ AI รายอื่น" ที่คาดว่าจะรองรับการควบคุมนี้

ใครอีกบ้างที่สนับสนุนสัญญาณร่วมนี้

มีอีกสองบริษัทที่เคลื่อนไหวต่อสาธารณะในวันที่ 30 ตุลาคม 2569 Microsoft Bing ประกาศในวันเดียวกันว่าจะนำความต้องการเรื่องการฝึก AI แบบใช้ร่วมกันมาใช้ และเพิ่มการควบคุม grounding ระดับหน้าเว็บของตัวเองแยกต่างหาก ซึ่ง RA สรุปไว้ในบทความคู่กันเรื่องการควบคุม AI grounding ของ Bing ส่วนในอีเมลที่ประกาศร่าง Kelley เขียนว่า Anthropic "ได้เริ่มพัฒนาการรองรับร่างนี้แล้ว"

ส่วนกิตติกรรมประกาศในร่างขอบคุณผู้เข้าร่วมคณะทำงานที่สังกัด Google, Microsoft, OpenAI, Meta, Cloudflare, Common Crawl, BBC, Financial Times, News Corp และอื่น ๆ ร่างระบุว่าสังกัดเหล่านี้ใส่ไว้ "เพื่อการระบุตัวตนเท่านั้น เพราะผู้เข้าร่วม IETF มีส่วนร่วมในฐานะบุคคล" รายชื่อนี้จึงบอกว่าใครเข้าร่วมการหารือ ไม่ได้บอกว่าบริษัทใดให้คำมั่นว่าจะปฏิบัติตาม token นี้

เจ้าของเว็บไซต์ควรตรวจอะไรใน robots.txt

ส่วนนี้เป็นบทวิเคราะห์ของ RA จากแหล่งข้อมูลข้างต้น ตอนนี้ยังไม่จำเป็นต้องเปลี่ยนอะไร เพราะ Google วางแผนรองรับในปี 2570 แต่การตรวจใช้เวลาไม่นาน

  • ตรวจว่าเว็บไซต์มีกฎ Google-Extended อยู่แล้วหรือไม่ ถ้ามี กฎนั้นยังทำงานต่อ และตามลำดับความสำคัญที่ Google ประกาศ กฎนี้จะมีผลเหนือ token ร่วมสำหรับ Google
  • ตัดสินใจเรื่องการฝึก AI และเรื่อง grounding ของ Gemini แยกกัน ถ้าเป้าหมายคือปฏิเสธการฝึกกับผู้ให้บริการทุกราย แต่ยังอยากถูกอ้างอิงใน Gemini Apps ไฟล์ต้องมีทั้งกลุ่ม Disallow ของ __usage_ai-training และ Allow สำหรับ Google-Extended แบบชัดเจน
  • อย่าพึ่งกฎ "User-Agent: *" ตามร่างนี้ กฎเหล่านั้นไม่ได้บอกอะไรเกี่ยวกับการฝึก ไม่ว่าจะเข้มงวดแค่ไหน
  • แยกการบล็อก crawl ออกจากความต้องการเรื่องการใช้งาน การบล็อก Googlebot เพื่อหยุดการฝึกจะทำให้หน้าเว็บหายจาก Search ไปด้วย token ร่วมถูกออกแบบมาเพื่อให้ไม่ต้องทำแบบนั้น
  • ตรวจขนาดไฟล์ ร่างระบุว่า robots.txt มีข้อจำกัดด้านขนาดตาม RFC 9309 และ token นี้ถูกออกแบบมาเพื่อไม่ต้องเขียนกฎเดิมซ้ำ การเพิ่มกลุ่มสั้น ๆ หนึ่งกลุ่มจึงน่าจะเพียงพอ
  • จำสถานะของเรื่องนี้ไว้ โพสต์ของ Google เองเรียกว่าข้อเสนอฉบับร่าง Internet-Draft ยังอยู่ระหว่างดำเนินการ และผู้เขียนร่างระบุในอีเมลประกาศว่าการตีความของ Anthropic อาจเปลี่ยนไปเมื่อมาตรฐานพัฒนาขึ้น

แบรนด์ที่ติดตามว่าหน้าเว็บของตัวเองถูกอ้างอิงในคำตอบของ AI หรือไม่ สามารถรวมเรื่องนี้เข้าไปในการตรวจรอบเดียวกันได้ บริการ Generative Engine Optimization (GEO) ของ RA ถือว่าการควบคุม crawler และการใช้งานเนื้อหาเป็นส่วนหนึ่งของการมองเห็นบน AI

ความหมายสำหรับนักการตลาดไทย

แหล่งข่าวไม่ได้พูดถึงประเทศไทย กลไกนี้ใช้ได้ทั่วโลกเพราะอยู่ใน robots.txt ของแต่ละเว็บไซต์ จึงมีผลกับเว็บไซต์ .co.th หรือ .th เหมือนกับเว็บไซต์ที่อื่น สำหรับสำนักข่าว ร้านค้าออนไลน์ และเว็บไซต์แบรนด์ในไทยที่อยากปรากฏในคำตอบของ Gemini ประเด็นที่ต้องระวังคือความสัมพันธ์กับ Google-Extended การปฏิเสธการฝึกแบบกว้าง ๆ โดยไม่มีบรรทัด Allow สำหรับ Google-Extended ตามการจับคู่ที่ Google ประกาศไว้ จะครอบคลุม grounding ของ Gemini ไปด้วย ทีมที่ทำ AI SEO ควรบันทึกการตัดสินใจนี้ไว้ในประวัติการแก้ไข robots.txt ตั้งแต่ตอนนี้ เพื่อไม่ให้การแก้ไขในอนาคตลบล้างไปโดยไม่มีใครสังเกต

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

Google จะเริ่มรองรับ token __usage_ai-training เมื่อไร

Google ระบุว่าปี 2570 แต่ไม่ได้ระบุวันที่แน่นอน โพสต์บล็อก Search Central เมื่อ 30 ตุลาคม 2569 บอกว่า Google ตั้งเป้าจะรองรับในปี 2570 (ค.ศ. 2027) และหัวข้อ Google-Extended ในเอกสาร crawler ของ Google ระบุว่าเป็นช่วงต้นปี 2570

การปฏิเสธผ่าน token ร่วมจะทำให้เว็บไซต์หายจาก Google Search หรือไม่

เอกสารของ Google ระบุว่า Google-Extended ซึ่งเป็นสิ่งที่การปฏิเสธผ่าน token ร่วมจะถูกจับคู่ด้วย ไม่มีผลต่อการปรากฏใน Google Search และไม่ใช่สัญญาณจัดอันดับ ตัวประกาศเองไม่ได้กล่าวถึง AI Overviews หรือ AI Mode จึงไม่ได้บอกอะไรเกี่ยวกับสองส่วนนี้

บล็อกการฝึก AI แต่ยังได้รับการอ้างอิงใน Gemini ได้หรือไม่

ได้ ตามที่ Google ระบุ หากเว็บไซต์ allow Google-Extended ไว้อย่างชัดเจน โพสต์บอกว่าการควบคุมเฉพาะบริษัทยังคงทำงาน และเว็บไซต์ที่ allow Google-Extended ไว้อย่างเจาะจงมีสิทธิ์ปรากฏในคำตอบและได้รับคลิกผ่าน grounding ใน Gemini Apps

การ disallow ใน "User-Agent: *" นับเป็นการปฏิเสธการฝึกแล้วหรือยัง

ไม่นับ ร่างของ IETF ระบุว่ากลุ่ม wildcard ต้องไม่ถูกตีความว่าตรงกับ policy token และไฟล์ที่ไม่มีกลุ่ม __usage_ai-training ถือว่าไม่ได้แสดงความต้องการใด ๆ เลย

ตอนนี้ต้องเปลี่ยนอะไรหรือไม่

ตามแหล่งข่าว ยังไม่ต้อง Google วางแผนรองรับในปี 2570 และร่างยังอยู่ระหว่างดำเนินการ เว็บไซต์ที่ใช้ Google-Extended อยู่แล้วยังคงควบคุมได้ตามเดิม token ร่วมจะมีผลกับ Google เฉพาะเมื่อไม่ได้ระบุ Google-Extended

token ร่วมนี้ให้เจ้าของเว็บไซต์มีบรรทัดเดียวที่บริษัท AI หลายรายอาจอ่านได้ ขณะที่แต่ละบริษัทยังมีการควบคุมของตัวเอง หากต้องการให้ช่วยตรวจว่า robots.txt กฎของ crawler และการถูกอ้างอิงบน AI ของเว็บไซต์เข้ากันอย่างไรก่อนการเปิดใช้ในปี 2570 ทีม GEO ของ RA พร้อมช่วยตรวจร่วมกับคุณ

Antonio Fernandez

Antonio Fernandez

ผู้ก่อตั้งและ CEO ของ Relevant Audience ผู้นำด้านการตลาดดิจิทัลในเอเชียตะวันออกเฉียงใต้ ด้วยประสบการณ์กว่า 15 ปีในการพัฒนากลยุทธ์การตลาดดิจิทัล เขาได้นำพาทีมงานในการสร้างผลลัพธ์ที่ยอดเยี่ยมให้กับลูกค้าผ่านโซลูชันดิจิทัลที่มุ่งเน้นประสิทธิภาพ

แชร์ไปยัง:
คัดลอกลิงก์:

อ่านบทความของเราเป็นประจำใช่ไหม เพิ่ม Relevant Audience เป็นแหล่งข้อมูลที่คุณเลือก เพื่อให้บทความของเราปรากฏในผลการค้นหา Google ของคุณมากขึ้น