Core Web Vitals และ Latency: หน้าเว็บที่เร็วขึ้นจะได้รับการอ้างอิงจาก AI มากขึ้นหรือไม่?

Core Web Vitals และ Latency: หน้าเว็บที่เร็วขึ้นจะได้รับการอ้างอิงจากระบบปัญญาประดิษฐ์มากขึ้นหรือไม่?

บทนำ

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

แต่ความแตกต่างที่สำคัญมักถูกมองข้ามไป:

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

ณ วันที่ 2 สิงหาคม 2026 Google ระบุว่าเวลาตอบสนองของเซิร์ฟเวอร์ที่เสถียรและค่า Latency ที่ต่ำลงสามารถเพิ่มความสามารถในการรวบรวมข้อมูลของเว็บไซต์ได้ Google ยังระบุอีกว่าคุณสมบัติการค้นหาด้วยปัญญาประดิษฐ์ของตนใช้ระบบการค้นหาและการจัดทำดัชนีพื้นฐานเดียวกับการค้นหาแบบดั้งเดิม และไม่จำเป็นต้องใช้มาร์กอัปปัญญาประดิษฐ์พิเศษหรือการปรับความเร็วให้เหมาะสม (developers.google.com)

บทความนี้เสนอแผนการทดสอบที่อิงหลักฐาน แทนที่จะอ้างว่าการทดลองได้ดำเนินการเสร็จสิ้นแล้ว ไม่มีการจัดหาเว็บไซต์ ชุดหน้าเว็บ บันทึกเซิร์ฟเวอร์ หรือชุดข้อมูลการอ้างอิง เป้าหมายคือการกำหนดการศึกษาที่ควบคุมได้ ซึ่งสามารถวัดได้ว่า:

1. ค่า time to first byte ที่ลดลงจะเพิ่มความถี่ในการรวบรวมข้อมูลหรือไม่
2. ค่า Largest Contentful Paint ที่ลดลงจะช่วยปรับปรุงการค้นพบหรือการจัดทำดัชนีหรือไม่
3. ค่า Cumulative Layout Shift ที่ลดลงจะส่งผลต่อการรวบรวมข้อมูลหรือการดึงข้อมูลด้วยปัญญาประดิษฐ์หรือไม่
4. การปรับปรุงประสิทธิภาพจะเพิ่มอัตราการอ้างอิงหน้าเว็บอย่างเห็นได้ชัดโดยระบบค้นหาด้วยปัญญาประดิษฐ์หรือไม่

คำตอบสั้นๆ

ค่า Time to first byte ที่ต่ำลงสามารถปรับปรุงการรวบรวมข้อมูลได้ภายใต้เงื่อนไขที่เหมาะสม

เอกสารเกี่ยวกับการรวบรวมข้อมูลปัจจุบันของ Google ระบุว่าขีดจำกัดความสามารถในการรวบรวมข้อมูลสามารถเพิ่มขึ้นได้เมื่อเว็บไซต์มีเวลาตอบสนองที่เสถียรหรือดีขึ้น รวมถึงค่า time to first byte ด้วย หากเวลาตอบสนองสูงขึ้น หรือหากเว็บไซต์ส่งคืนข้อผิดพลาดของเซิร์ฟเวอร์มากเกินไปหรือการตอบสนองที่จำกัดอัตรา Google อาจลดการรวบรวมข้อมูลลง (developers.google.com)

อย่างไรก็ตาม เวลาตอบสนองที่เร็วขึ้นไม่ได้รับประกันว่าจะมีการรวบรวมข้อมูลมากขึ้น ความต้องการในการรวบรวมข้อมูลยังขึ้นอยู่กับปัจจัยต่างๆ เช่น:

• เว็บไซต์มีการเปลี่ยนแปลงบ่อยเพียงใด
• เว็บไซต์และหน้าเว็บได้รับความนิยมเพียงใด
• เนื้อหามีประโยชน์และไม่ซ้ำใครหรือไม่
• มี URL ที่ซ้ำกันหรือมีค่าน้อยจำนวนเท่าใด
• URL ที่อัปเดตแล้วถูกรวมอยู่ใน Sitemap หรือไม่

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

ค่า Largest Contentful Paint ที่ต่ำลงอาจช่วยได้ทางอ้อม

Largest Contentful Paint วัดเมื่อเนื้อหาหลักที่มองเห็นได้ปรากฏขึ้นสำหรับผู้ใช้ Google ยังระบุอีกว่าทั้งเวลาตอบสนองของเซิร์ฟเวอร์และเวลาที่ต้องใช้ในการเรนเดอร์หน้าเว็บและทรัพยากรที่ฝังอยู่สามารถส่งผลต่อประสิทธิภาพในการรวบรวมข้อมูลได้ (developers.google.com)

ความสัมพันธ์ที่น่าจะเป็นคือทางอ้อม:

ค่า Latency ที่ต่ำลง → การส่งมอบทรัพยากรที่เร็วขึ้น → การเรนเดอร์หรือการดึงข้อมูลที่มีประสิทธิภาพมากขึ้น → การหมดเวลาในการรวบรวมข้อมูลหรือการดึงข้อมูลไม่สมบูรณ์น้อยลง

ผลกระทบควรจะแข็งแกร่งที่สุดเมื่อเนื้อหาที่สำคัญขึ้นอยู่กับ:

• JavaScript ที่ช้า
• รูปภาพขนาดใหญ่
• สไตล์ชีตที่บล็อกการเรนเดอร์
• การเรนเดอร์ฝั่งไคลเอ็นต์
• ทรัพยากรที่ฝังอยู่ที่มีขนาดใหญ่

คะแนน Largest Contentful Paint ที่รวดเร็วด้วยตัวเองไม่น่าจะเป็นสัญญาณโดยตรงของการอ้างอิงจากปัญญาประดิษฐ์

ค่า Cumulative Layout Shift ที่ต่ำลงอาจมีผลโดยตรงต่อการรวบรวมข้อมูลน้อยมาก

Cumulative Layout Shift วัดการเคลื่อนที่ที่ไม่คาดคิดของเนื้อหาที่มองเห็นได้ โดยหลักแล้วเป็นเมตริกประสบการณ์ผู้ใช้ สาเหตุทั่วไปได้แก่ รูปภาพที่ไม่มีขนาด โฆษณาที่แทรกเข้ามาแบบไดนามิก เนื้อหาที่ฝังอยู่ และเว็บฟอนต์ (web.dev)

โปรแกรมรวบรวมข้อมูลไม่ได้รับผลกระทบจากการเปลี่ยนแปลงเค้าโครงในลักษณะเดียวกับที่ผู้เยี่ยมชมที่เป็นมนุษย์ได้รับ ดังนั้นความสัมพันธ์โดยตรงระหว่างค่า Cumulative Layout Shift ที่ต่ำลงกับการรวบรวมข้อมูลที่มากขึ้นจึงไม่น่าเป็นไปได้

อาจมีความสัมพันธ์ทางอ้อมเมื่อการเปลี่ยนแปลงเค้าโครงสูงเกิดจาก:

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

ในกรณีเหล่านั้น ปัญหาที่แท้จริงไม่ใช่คะแนนการเปลี่ยนแปลงเค้าโครง แต่ปัญหาที่แท้จริงคือหน้าเว็บอาจประมวลผลได้ยาก หรืออาจแสดงเนื้อหาที่สำคัญช้าเกินไป

หน้าเว็บที่เร็วขึ้นไม่ได้รับการอ้างอิงบ่อยขึ้นโดยอัตโนมัติ

Google ระบุว่าหน้าเว็บที่ปรากฏในคุณสมบัติปัญญาประดิษฐ์จะต้องถูกจัดทำดัชนีและมีสิทธิ์ที่จะปรากฏในผลการค้นหาปกติพร้อมกับข้อความย่อก่อน Google ยังระบุอีกว่าไม่มีข้อกำหนดทางเทคนิคเพิ่มเติมหรือการเพิ่มประสิทธิภาพปัญญาประดิษฐ์พิเศษสำหรับภาพรวมปัญญาประดิษฐ์และโหมดปัญญาประดิษฐ์ของตน (developers.google.com)

OpenAI ก็ระบุในทำนองเดียวกันว่าการจัดอันดับการค้นหาของ ChatGPT ขึ้นอยู่กับปัจจัยหลายอย่าง และการอนุญาตให้โปรแกรมรวบรวมข้อมูลการค้นหา OAI-SearchBot เข้าถึงมีความสำคัญต่อการรวมข้อมูลเข้าสู่ระบบ ไม่ได้ระบุว่าค่า Core Web Vitals ที่ต่ำลงจะเพิ่มโอกาสในการอ้างอิงโดยตรง (help.openai.com)

สิ่งนี้ชี้ให้เห็นถึงโมเดลสี่ขั้นตอน:

1. การค้นพบ (Discovery) — ระบบเรียนรู้ว่ามี URL นี้อยู่หรือไม่?
2. การดึงและประมวลผล (Fetching and processing) — ระบบสามารถดึงและทำความเข้าใจหน้าเว็บได้หรือไม่?
3. การจัดทำดัชนีและการดึงข้อมูล (Indexing and retrieval) — หน้าเว็บนี้ถูกเลือกสำหรับคำค้นหาเฉพาะหรือไม่?
4. การเลือกการอ้างอิง (Citation selection) — หน้าเว็บนี้แสดงเป็นแหล่งข้อมูลที่มองเห็นได้ในคำตอบหรือไม่?

ความเร็วของหน้าเว็บอาจส่งผลต่อสองขั้นตอนแรก ไม่ได้ถูกกำหนดให้เป็นสาเหตุโดยตรงของขั้นตอนที่สี่

งานวิจัยล่าสุดยังแสดงให้เห็นว่าระบบปัญญาประดิษฐ์อาจอ่านหน้าเว็บที่เกี่ยวข้องหลายหน้า แต่อ้างอิงเพียงบางหน้าเท่านั้น กล่าวอีกนัยหนึ่งคือ การดึงข้อมูลและการอ้างอิงเป็นเหตุการณ์ที่แยกจากกัน (cambridge.org)

สิ่งที่ควรทดสอบคืออะไร?

การศึกษาควรทดสอบคำถามสองข้อที่แตกต่างกัน แทนที่จะพิจารณา "การมองเห็นด้วยปัญญาประดิษฐ์" เป็นเมตริกเดียว

คำถามที่ 1: ประสิทธิภาพส่งผลต่อการรวบรวมข้อมูลหรือไม่?

ผลลัพธ์หลัก:

• เวลาตั้งแต่เผยแพร่จนถึงคำขอโปรแกรมรวบรวมข้อมูลครั้งแรก
• จำนวนคำขอโปรแกรมรวบรวมข้อมูลต่อหน้าต่อวัน
• เวลาระหว่างการรวบรวมข้อมูลซ้ำที่สำเร็จ
• จำนวนหน้าเว็บที่ถูกรวบรวมข้อมูลต่อหน้าเว็บที่เผยแพร่ 1,000 หน้า
• เปอร์เซ็นต์ของการดึงข้อมูลที่สำเร็จ
• อัตราข้อผิดพลาดของเซิร์ฟเวอร์และการตอบสนองที่จำกัดอัตรา
• เวลาตั้งแต่เผยแพร่จนถึงการจัดทำดัชนี

คำถามที่ 2: ประสิทธิภาพส่งผลต่อการเลือกการอ้างอิงหรือไม่?

ผลลัพธ์หลัก:

• เปอร์เซ็นต์ของคำค้นหาที่ทดสอบที่สร้างการอ้างอิงที่มองเห็นได้
• อัตราการอ้างอิงต่อหน้าเว็บที่มีสิทธิ์
• ส่วนแบ่งการอ้างอิงภายในคำค้นหา
• เปอร์เซ็นต์ของหน้าเว็บที่ถูกดึงข้อมูลที่กลายเป็นการอ้างอิงที่มองเห็นได้
• ความคงอยู่ของการอ้างอิงเมื่อเวลาผ่านไป
• อัตราการอ้างอิงโดยระบบปัญญาประดิษฐ์

ผลลัพธ์เหล่านี้จะต้องแยกตามผู้ให้บริการ ภาพรวมปัญญาประดิษฐ์ของ Google, ผลการค้นหาของ ChatGPT, คำตอบของ Microsoft Copilot, คำตอบของ Perplexity และการตอบสนองการค้นหาของ Claude อาจใช้ดัชนี โปรแกรมรวบรวมข้อมูล ระบบการจัดอันดับ และกำหนดการรีเฟรชที่แตกต่างกัน

การออกแบบการทดลอง

1. สร้างชุดหน้าเว็บที่ควบคุมได้

ใช้ชุดหน้าเว็บที่มีขนาดใหญ่พอที่จะสร้างข้อมูลการรวบรวมข้อมูลและการอ้างอิงที่มีความหมาย

การออกแบบเริ่มต้นที่เป็นประโยชน์จะรวมถึง:

• 240 ถึง 800 หน้า
• อย่างน้อย 20 หน้าต่อเทมเพลตหน้าเว็บ
• หมวดหมู่เนื้อหาสามถึงห้าหมวดหมู่
• หน้าเว็บที่เป็นเนื้อหาคงที่และหน้าที่อัปเดตเป็นประจำ
• จำนวนหน้าเว็บที่เท่ากันในแต่ละกลุ่มทดลอง

แต่ละหน้าควรมี:

• โครงสร้าง HTML ที่คล้ายกัน
• ความยาวเนื้อหาที่คล้ายกัน
• ระบบเผยแพร่เดียวกัน
• รูปแบบการเชื่อมโยงภายในที่เหมือนกัน
• กฎ Canonical ที่เหมือนกัน
• การจัดการ Sitemap ที่เหมือนกัน
• สิทธิ์ robots.txt ที่เหมือนกัน
• หัวข้อที่ไม่ซ้ำกันและมีประโยชน์

อย่าสร้างหน้าเว็บจำนวนมากที่เนื้อหาเบาบางหรือเกือบซ้ำกันเพียงเพื่อการทดลอง คำแนะนำของ Google เตือนว่า URL ที่ซ้ำกันและมีค่าน้อยสามารถสิ้นเปลืองทรัพยากรในการรวบรวมข้อมูลและลดประสิทธิภาพของเว็บไซต์ได้ (developers.google.com)

การออกแบบแบบจับคู่มีประโยชน์ ตัวอย่างเช่น จับคู่หน้าเว็บที่มีลักษณะคล้ายกันในด้าน:

• ความยาวเนื้อหา
• ความต้องการหัวข้อ
• ความถี่ในการอัปเดต
• จำนวนลิงก์ภายใน
• จำนวนลิงก์ภายนอก
• การเข้าชมในอดีต
• ตำแหน่งการจัดอันดับการค้นหา

จากนั้นวางหน้าเว็บหนึ่งหน้าจากแต่ละคู่ในกลุ่มควบคุม และอีกหน้าหนึ่งในกลุ่มทดลอง

2. ใช้การออกแบบการทดลองแบบ Factorial

การปรับปรุงประสิทธิภาพหลักควรได้รับการทดสอบทั้งแบบอิสระและร่วมกัน

สิ่งนี้สร้างการทดลองที่ควบคุมได้สำหรับการเพิ่มประสิทธิภาพสามอย่างที่ร้องขอ:

• HTTP/3
• การแคชที่ Edge ของเครือข่ายจัดส่งเนื้อหา
• การบีบอัดรูปภาพ

การรักษาความเสถียรของเค้าโครงเป็นสิ่งจำเป็น เนื่องจากการเพิ่มประสิทธิภาพสามอย่างแรกไม่สามารถแยก Cumulative Layout Shift ได้อย่างน่าเชื่อถือ การบีบอัดรูปภาพอาจลด Largest Contentful Paint ได้โดยไม่เปลี่ยนแปลงความเสถียรของเค้าโครงเลย

ทำไม HTTP/3 จึงต้องการการวัดผลแยกต่างหาก

HTTP/3 ใช้โปรโตคอลการส่งข้อมูล QUIC และให้สตรีมที่เป็นอิสระ ซึ่งสามารถหลีกเลี่ยงปัญหาการบล็อกหัวแถวระดับการส่งข้อมูลที่พบใน HTTP/2 ผ่าน TCP ประโยชน์ของมันขึ้นอยู่กับว่าไคลเอ็นต์หรือโปรแกรมรวบรวมข้อมูลเจรจา HTTP/3 จริงหรือไม่ (rfc-editor.org)

ดังนั้น ให้บันทึกโปรโตคอลที่ตกลงกันไว้สำหรับทุกคำขอ:

• HTTP/1.1
• HTTP/2
• HTTP/3

อย่าคิดว่าการเปิดใช้งาน HTTP/3 หมายความว่าโปรแกรมรวบรวมข้อมูลทุกตัวจะใช้ หาก Googlebot, OAI-SearchBot หรือโปรแกรมรวบรวมข้อมูลอื่นยังคงใช้ HTTP/2, HTTP/3 ก็ไม่สามารถส่งผลกระทบต่อคำขอของโปรแกรมรวบรวมข้อมูลนั้นได้

ทำไมการแคชที่ Edge ควรได้รับการทดสอบอย่างรอบคอบ

เครือข่ายจัดส่งเนื้อหาสามารถลดเวลา Time to first byte ได้โดยการให้บริการเนื้อหาใกล้กับผู้ร้องขอ นอกจากนี้ยังสามารถลดจำนวนคำขอที่เข้าถึงเซิร์ฟเวอร์ต้นทางได้อีกด้วย (web.dev)

ทดสอบสถานะแคชอย่างน้อยสามสถานะ:

1. Cold cache — Edge ต้องติดต่อต้นทาง
2. Warm cache — Edge ให้บริการหน้าเว็บโดยไม่ต้องติดต่อต้นทาง
3. Revalidated cache — Edge หรือโปรแกรมรวบรวมข้อมูลใช้ค่า ETag หรือ Last-Modified และได้รับการตอบกลับ 304 Not Modified

Google แนะนำเป็นพิเศษให้ใช้การแคช HTTP ที่มีประสิทธิภาพ และสนับสนุนการใช้การตอบสนอง 304 Not Modified เพื่อลดการประมวลผลและแบนด์วิดท์ที่ไม่จำเป็น (developers.google.com)

อย่าอนุญาตให้แคชให้บริการเนื้อหาที่เก่าหรือไม่ถูกต้องแก่โปรแกรมรวบรวมข้อมูล บันทึก:

• แคช hit หรือ miss
• อายุแคช
• ตำแหน่ง Edge
• เวลาตอบสนองของต้นทาง
• เวอร์ชันเนื้อหา
• รหัสสถานะ
• ส่วนหัวการตรวจสอบ

ทำไมการบีบอัดรูปภาพควรเชื่อมโยงกับ Largest Contentful Paint

โดยทั่วไป WebP และ AVIF ให้การบีบอัดที่ดีกว่ารูปแบบรูปภาพเก่า รูปภาพที่มีขนาดเล็กลงสามารถลดเวลาในการถ่ายโอนและอาจปรับปรุง Largest Contentful Paint ได้เมื่อรูปภาพเป็นองค์ประกอบ Largest Contentful Paint (web.dev)

การทดสอบควรใช้:

• ขนาดรูปภาพเดียวกัน
• เป้าหมายคุณภาพของภาพเดียวกัน
• รูปภาพ srcset ที่ตอบสนอง
• รูปแบบที่ทันสมัยพร้อมการสำรองข้อมูลที่เหมาะสม
• ค่า width และ height ที่ระบุชัดเจน
• ไม่มีการโหลดแบบ Lazy Loading สำหรับรูปภาพ Largest Contentful Paint
• URL รูปภาพที่มองเห็นได้ใน HTML เริ่มต้น

การบีบอัดรูปภาพเพียงอย่างเดียวอาจไม่ปรับปรุง Largest Contentful Paint หากความล่าช้าที่แท้จริงมาจาก JavaScript หรือการค้นพบทรัพยากรล่าช้า คำแนะนำด้านประสิทธิภาพของ Google ระบุว่าการลดเวลาดาวน์โหลดรูปภาพสามารถย้ายความล่าช้าไปยังส่วนอื่นของหน้าเว็บได้ หากองค์ประกอบ Largest Contentful Paint ถูกเปิดเผยล่าช้า (web.dev)

3. ดำเนินการทดสอบนานพอ

การทดสอบสั้นๆ อาจพลาดผลกระทบของการจัดกำหนดการรวบรวมข้อมูลและการรีเฟรชดัชนี

การออกแบบที่เป็นประโยชน์คือ:

• การวัดค่าพื้นฐานสองสัปดาห์
• การวัดผลการทดลองหกถึงสิบสองสัปดาห์
• ช่วงการกลับข้างหรือครอสโอเวอร์ ครั้งสุดท้าย ถ้าเป็นไปได้

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

ข้อมูลภาคสนามของ Core Web Vitals ควรได้รับการประเมินในช่วงเวลาที่เหมาะสม Chrome User Experience Report ใช้การรวบรวมข้อมูลแบบเลื่อน 28 วัน ดังนั้นจึงไม่ได้ออกแบบมาเพื่อแสดงการเปลี่ยนแปลงทันทีหลังการปรับใช้ (developer.chrome.com)

4. วัดประชากรโปรแกรมรวบรวมข้อมูลทั้งหมด

อย่าปฏิบัติต่อการเข้าชมอัตโนมัติทั้งหมดเป็นกลุ่มเดียวกัน

อย่างน้อยที่สุด ให้แยก:

โปรแกรมรวบรวมข้อมูลการค้นหา

• Googlebot
• Bingbot

โปรแกรมรวบรวมข้อมูลการค้นหาด้วยปัญญาประดิษฐ์

• OAI-SearchBot
• PerplexityBot
• Claude-SearchBot

โปรแกรมดึงข้อมูลที่ผู้ใช้ร้องขอ

• Perplexity-User
• Claude-User
• โปรแกรมดึงข้อมูลผู้ใช้ ChatGPT ที่สามารถระบุได้

โปรแกรมรวบรวมข้อมูลการฝึกอบรม

• GPTBot
• ClaudeBot
• การควบคุม Google-Extended

โปรแกรมรวบรวมข้อมูลการฝึกอบรมไม่ควรถูกใช้เป็นตัวแทนของการอ้างอิงจากการค้นหาด้วยปัญญาประดิษฐ์ Anthropic, OpenAI และ Google แยกความแตกต่างระหว่างโปรแกรมรวบรวมข้อมูลที่ใช้สำหรับการฝึกอบรม การค้นหา หรือการดึงข้อมูลที่ผู้ใช้ร้องขอ Google ยังระบุด้วยว่า Google-Extended ไม่มีผลต่อการรวมหรือการจัดอันดับในการค้นหาของ Google (help.openai.com)

Perplexity ก็แยกความแตกต่างระหว่าง PerplexityBot ซึ่งรองรับการจัดทำดัชนีการค้นหา และ Perplexity-User ซึ่งอาจดึงหน้าเว็บเพื่อตอบสนองคำขอของผู้ใช้ (docs.perplexity.ai)

ตรวจสอบตัวตนของโปรแกรมรวบรวมข้อมูลโดยใช้ช่วง IP ที่เผยแพร่หรือ Reverse DNS ในกรณีที่ผู้ให้บริการสนับสนุน สตริง User-agent สามารถถูกคัดลอกโดยโปรแกรมรวบรวมข้อมูลที่ไม่เกี่ยวข้อง Google เตือนโดยเฉพาะว่าสตริง User-agent ของ Googlebot สามารถถูกปลอมแปลงได้ (developers.google.com)

เมตริกที่จะรวบรวม

เมตริกประสิทธิภาพ

รวบรวมข้อมูลทั้งจากการทดสอบในห้องปฏิบัติการและข้อมูลจากผู้ใช้จริง:

• Time to first byte
• First Contentful Paint
• Largest Contentful Paint
• Cumulative Layout Shift
• Interaction to Next Paint
• น้ำหนักหน้าเว็บทั้งหมด
• ขนาด HTML เริ่มต้น
• ขนาดการถ่ายโอนรูปภาพ
• จำนวนคำขอ
• เวลาที่ใช้ในการประมวลผลของเซิร์ฟเวอร์
• เวลาที่ใช้รอทรัพยากร Largest Contentful Paint
• โปรโตคอล HTTP
• สถานะแคช

Google แนะนำค่าเป้าหมายโดยประมาณสำหรับ Time to first byte ที่ 800 มิลลิวินาทีหรือน้อยกว่า แต่ Time to first byte ไม่ใช่ Core Web Vital ด้วยตัวเอง (web.dev)

เกณฑ์ "ดี" ของ Core Web Vitals ในปัจจุบันที่ 75th percentile คือ:

• Largest Contentful Paint: 2.5 วินาทีหรือน้อยกว่า
• Cumulative Layout Shift: 0.1 หรือน้อยกว่า
• Interaction to Next Paint: 200 มิลลิวินาทีหรือน้อยกว่า (web.dev)

เมตริกการรวบรวมข้อมูล

สำหรับทุกคำขอโปรแกรมรวบรวมข้อมูลที่ได้รับการยืนยัน ให้บันทึก:

text timestamp url user_agent verified_bot source_ip http_protocol status_code response_time time_to_first_byte bytes_sent cache_status edge_location etag last_modified referrer

คำนวณ:

text crawl_requests_per_url_day successful_fetch_rate 5xx_rate 429_rate median_recrawl_interval p75_recrawl_interval publication_to_first_fetch publication_to_first_index

เมตริกการอ้างอิงด้วยปัญญาประดิษฐ์

ใช้ชุดคำค้นหาที่กำหนดไว้สำหรับแต่ละแพลตฟอร์ม ชุดคำค้นหาควรรวมถึง:

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

สำหรับแต่ละคำค้นหา ให้บันทึก:

text engine model or experience timestamp location device query pages shown as sources page citation order whether the tested page was cited whether the tested page was retrieved but not cited answer text hash

ทำซ้ำคำค้นหาเนื่องจากคำตอบของปัญญาประดิษฐ์อาจแตกต่างกัน ใช้กำหนดการที่แน่นอน เช่น สามครั้งต่อสัปดาห์ และบันทึกการเปลี่ยนแปลงในเอนจินหรือโมเดล

Microsoft Bing Webmaster Tools มีรายงานประสิทธิภาพปัญญาประดิษฐ์ (Artificial Intelligence Performance) ที่แสดงหน้าเว็บที่ถูกอ้างอิง, คำค้นหาที่เป็นพื้นฐาน, และแนวโน้มการอ้างอิงในประสบการณ์ปัญญาประดิษฐ์ของ Microsoft ที่รองรับ Microsoft เตือนว่าข้อมูลนี้เป็นการรวบรวม สุ่มตัวอย่าง และเป็นเพียงการสังเกต ไม่สามารถพิสูจน์ได้ว่าการเปลี่ยนแปลงหน้าเว็บเฉพาะใดทำให้เกิดการเปลี่ยนแปลงการอ้างอิง (bing.com)

Google ยังเริ่มเปิดตัวรายงานประสิทธิภาพปัญญาประดิษฐ์เชิงสร้างสรรค์ (generative artificial intelligence performance reports) โดยเฉพาะใน Search Console ในเดือนมิถุนายน 2026 รายงานเหล่านี้ในตอนแรกมีให้สำหรับเว็บไซต์บางส่วนเท่านั้น ดังนั้นการเข้าถึงอาจแตกต่างกันไป (developers.google.com)

การวิเคราะห์ทางสถิติ

ความถี่ในการรวบรวมข้อมูล

ใช้โมเดลนับแบบ Mixed-effects เช่น โมเดล Negative binomial:

text crawl_count ~ treatment + time_to_first_byte + page_age + update_frequency + sitemap_status + internal_links + server_errors + (1 | page) + (1 | crawler)

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

การค้นพบและการจัดทำดัชนี

ใช้การวิเคราะห์การรอดชีวิตสำหรับ:

• เวลาตั้งแต่เผยแพร่จนถึงการดึงข้อมูลครั้งแรก
• เวลาตั้งแต่เผยแพร่จนถึงการจัดทำดัชนีครั้งแรก
• เวลาตั้งแต่การอัปเดตจนถึงการรวบรวมข้อมูลซ้ำ

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

การเลือกการอ้างอิงด้วยปัญญาประดิษฐ์

ใช้โมเดล Logistic แบบลำดับชั้น:

text citation_present ~ treatment + time_to_first_byte + largest_contentful_paint + cumulative_layout_shift + indexed_status + search_visibility + content_freshness + page_authority + (1 | query) + (1 | engine) + (1 | page)

รันสองโมเดลแยกกัน:

1. โมเดลการดึงข้อมูล (Retrieval model) — หน้าเว็บถูกดึงข้อมูลหรือแสดงเป็นตัวเลือกหรือไม่?
2. โมเดลการอ้างอิง (Citation model) — หากถูกดึงข้อมูล หน้าเว็บนั้นถูกอ้างอิงอย่างชัดเจนหรือไม่?

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

ข้อค้นพบที่คาดการณ์

สิ่งเหล่านี้คือสมมติฐานในการทำงาน ไม่ใช่ผลการทดลองที่อ้างสิทธิ์

สมมติฐานที่ 1: Time to first byte จะมีผลต่อการรวบรวมข้อมูลที่ชัดเจนที่สุด

คาดการณ์ความสัมพันธ์เชิงบวกระหว่างค่า time to first byte ที่ต่ำลงกับความสามารถในการรวบรวมข้อมูลเมื่อ:

• เว็บไซต์มีหน้าเว็บจำนวนมาก
• หน้าเว็บมีการเปลี่ยนแปลงบ่อยครั้ง
• เซิร์ฟเวอร์ต้นทางช้าหรือโอเวอร์โหลด
• เว็บไซต์ส่งคืนการตอบสนอง 5xx หรือ 429
• โปรแกรมรวบรวมข้อมูลใช้เวลามากในการรอการตอบสนอง

คาดการณ์ว่าจะมีผลกระทบที่วัดได้น้อยต่อเว็บไซต์ขนาดเล็กที่มีความต้องการในการรวบรวมข้อมูลต่ำ

สมมติฐานที่ 2: Largest Contentful Paint จะมีความสำคัญผ่านการเรนเดอร์และการส่งมอบทรัพยากร

คาดการณ์ว่าค่า Largest Contentful Paint ที่ต่ำลงจะช่วยได้เมื่อ:

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

คาดการณ์ความสัมพันธ์ที่อ่อนแอเมื่อข้อความสำคัญของหน้าเว็บมีอยู่ใน HTML เริ่มต้นแล้ว

สมมติฐานที่ 3: Cumulative Layout Shift จะมีผลกระทบโดยตรงน้อยมาก

คาดการณ์ว่าจะไม่มีความสัมพันธ์โดยตรงที่มีความหมายระหว่าง Cumulative Layout Shift กับความถี่ในการรวบรวมข้อมูลหรืออัตราการอ้างอิง หลังจากควบคุมโครงสร้างหน้าเว็บและพฤติกรรมของ JavaScript แล้ว

หาก Cumulative Layout Shift ดูเหมือนจะคาดการณ์การอ้างอิงได้ ให้ตรวจสอบว่ามันทำหน้าที่เป็นตัวแทนของสิ่งใด:

• การเรนเดอร์ฝั่งไคลเอ็นต์
• การแทรกเนื้อหาล่าช้า
• โฆษณาที่ไม่เสถียร
• ข้อความที่ซ่อนอยู่หรือล่าช้า
• HTML ที่มีโครงสร้างไม่ดี

สมมติฐานที่ 4: ความเร็วเพียงอย่างเดียวจะไม่สร้างการอ้างอิงจากปัญญาประดิษฐ์มากขึ้น

ปัจจัยที่คาดการณ์การเลือกการอ้างอิงที่แข็งแกร่งที่สุดมีแนวโน้มที่จะยังคงเป็น:

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

คำแนะนำของ Google เน้นย้ำเนื้อหาที่มีประโยชน์ น่าเชื่อถือ และเน้นผู้คนเป็นอันดับแรก และระบุว่าคุณสมบัติการค้นหาด้วยปัญญาประดิษฐ์นั้นมีพื้นฐานมาจากระบบการค้นหาและการจัดทำดัชนีที่มีอยู่เดิม (developers.google.com)

งบประมาณประสิทธิภาพที่ปรับแต่งสำหรับการดึงข้อมูลด้วยปัญญาประดิษฐ์

ต่อไปนี้เป็นงบประมาณการดำเนินงานที่เสนอ นี่คือ ไม่ใช่สูตรการจัดอันดับปัญญาประดิษฐ์ที่เผยแพร่แล้ว

เอกสารปัจจุบันของ Google ระบุว่า Googlebot ดึงข้อมูล 2 เมกะไบต์แรกของไฟล์ที่รองรับ และดึงสคริปต์ภายนอกและสไตล์ชีตแยกต่างหาก นอกจากนี้ยังแนะนำให้วางเมตาดาต้าที่สำคัญและข้อมูลที่มีโครงสร้างไว้ในช่วงต้นของ HTML (developers.google.com)

ข้อแนะนำในการนำไปใช้

HTTP/3

ใช้ HTTP/3 เมื่อได้รับการสนับสนุนจากผู้ให้บริการโฮสติ้งและเครือข่ายจัดส่งเนื้อหา

วัด:

• อัตราการเจรจา HTTP/3
• อัตราการกลับไปใช้ HTTP/2
• เวลาในการตั้งค่าการเชื่อมต่อ
• Time to first byte
• ประสิทธิภาพตามภูมิภาคทางภูมิศาสตร์
• ประสิทธิภาพตามโปรแกรมรวบรวมข้อมูล

อย่าปฏิบัติต่อ HTTP/3 ว่าเป็นการเพิ่มประสิทธิภาพการค้นหาหรือปัญญาประดิษฐ์ที่รับประกันได้ เป็นการปรับปรุงการส่งข้อมูลที่อาจช่วยได้เฉพาะไคลเอนต์ที่ใช้งานเท่านั้น

การแคชที่ Edge ของเครือข่ายจัดส่งเนื้อหา

สำหรับหน้าเว็บสาธารณะที่ไม่ใช่แบบส่วนบุคคล:

• กำหนดกฎ Cache-Control ที่ชัดเจน
• ใช้การแคชที่มีอายุยาวนานสำหรับสินทรัพย์คงที่ที่มีเวอร์ชัน
• ใช้การแคชที่สั้นแต่มีประโยชน์สำหรับ HTML ที่อัปเดตบ่อยครั้ง
• หลีกเลี่ยงการแยกส่วนแคชจากพารามิเตอร์การสอบถามที่ไม่จำเป็น
• เก็บรักษา URL Canonical ไว้
• รองรับ ETag และ Last-Modified
• ทดสอบสถานะแคชแบบ Cold, Warm และ Revalidated
• ยืนยันว่าคำขอของโปรแกรมรวบรวมข้อมูลได้รับเนื้อหาสำคัญเดียวกับคำขอของมนุษย์

เครือข่ายจัดส่งเนื้อหาควรกำจัด Latency โดยไม่สร้างหน้าเว็บเวอร์ชันที่ล้าสมัย ไม่สอดคล้องกัน หรือเฉพาะสำหรับบอท

การบีบอัดรูปภาพ

สำหรับรูปภาพ:

• ใช้ AVIF หรือ WebP เมื่อคุณภาพของภาพเป็นที่ยอมรับ
• จัดเตรียมขนาดรูปภาพที่ตอบสนอง
• อย่าแสดงรูปภาพขนาดเดสก์ท็อปบนหน้าจอมือถือขนาดเล็ก
• อย่าโหลดรูปภาพ Largest Contentful Paint แบบ Lazy Loading
• ระบุขนาดรูปภาพ
• วางรูปภาพ Largest Contentful Paint ใน HTML เริ่มต้น
• ใช้ fetchpriority="high" เมื่อเหมาะสมเท่านั้น
• เก็บคำอธิบายที่สำคัญไว้ในข้อความแทนที่จะฝังไว้ในรูปภาพเท่านั้น

การบีบอัดรูปภาพมีค่ามากที่สุดเมื่อรูปภาพเป็นองค์ประกอบ Largest Contentful Paint จะไม่สามารถแก้ไขหน้าเว็บที่มีความล่าช้าหลักมาจาก การเรนเดอร์ของเซิร์ฟเวอร์หรือการดำเนินการ JavaScript (web.dev)

ความเสถียรของเค้าโครง

เพื่อลด Cumulative Layout Shift:

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

การเปลี่ยนแปลงเหล่านี้ช่วยปรับปรุงประสบการณ์ผู้ใช้แม้ว่าจะไม่มีผลกระทบที่วัดได้ต่อการรวบรวมข้อมูลหรือการอ้างอิง (web.dev)

เครื่องมือและการตรวจสอบ

เครื่องมือประสิทธิภาพ

ใช้:

• Chrome User Experience Report สำหรับ Core Web Vitals จากผู้ใช้จริง
• API ของ Chrome User Experience Report สำหรับการรวบรวมข้อมูลภาคสนามแบบอัตโนมัติ
• PageSpeed Insights สำหรับการตรวจสอบในห้องปฏิบัติการและข้อมูลภาคสนาม
• Lighthouse สำหรับการทดสอบในห้องปฏิบัติการที่ทำซ้ำได้
• Lighthouse Continuous Integration สำหรับงบประมาณประสิทธิภาพ Pull Request
• WebPageTest สำหรับการทดสอบหลายตำแหน่ง สถานะแคช และการเปรียบเทียบโปรโตคอล
• Chrome DevTools สำหรับการแก้ไขจุดบกพร่องของ Largest Contentful Paint และ Layout Shift
• ไลบรารี JavaScript web-vitals สำหรับการตรวจสอบผู้ใช้จริง

API ของ Chrome User Experience Report ให้ข้อมูลภาคสนามรวมระดับหน้าและระดับต้นทาง รวมถึง Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint และ Time to first byte ในการทดลอง (developer.chrome.com)

Lighthouse Continuous Integration สามารถทำการตรวจสอบประสิทธิภาพในการเปลี่ยนแปลงโค้ดทุกครั้ง และทำให้การสร้างล้มเหลวเมื่อเกินงบประมาณที่กำหนด (github.com)

การตรวจสอบโปรแกรมรวบรวมข้อมูล

ใช้บันทึกเซิร์ฟเวอร์ บันทึก Edge และชุดการตรวจสอบสังเคราะห์ขนาดเล็ก

ตัวอย่างการตรวจสอบ:

bash curl --http3 -sS -o /dev/null -D - \ -w 'status=%{http_code}
http_version=%{http_version}
namelookup=%{time_namelookup}
connect=%{time_connect}
starttransfer=%{time_starttransfer}
total=%{time_total}
size=%{size_download}
' \ -A 'Mozilla/5.0 (compatible; OAI-SearchBot/1.0)' \ https://example.com/page

รันการทดสอบเดียวกันด้วย:

• Googlebot
• Bingbot
• OAI-SearchBot
• PerplexityBot
• Claude-SearchBot
• User-agent ของเบราว์เซอร์ปกติ

การทดสอบควรตรวจสอบ:

• รหัสสถานะ
• สิทธิ์ Robots
• ส่วนหัวการตอบสนอง
• เนื้อหา HTML
• เวอร์ชัน HTTP
• สถานะแคช
• เวลาตอบสนอง
• มีข้อความสำคัญอยู่โดยไม่มี JavaScript หรือไม่

การตรวจสอบการค้นหาและการจัดทำดัชนี

ใช้:

• สถิติการรวบรวมข้อมูลของ Google Search Console
• รายงานการจัดทำดัชนีหน้าเว็บของ Google Search Console
• การตรวจสอบ URL ของ Google Search Console
• ข้อมูล Sitemap ของ Google Search Console
• รายงานปัญญาประดิษฐ์เชิงสร้างสรรค์ของ Google Search Console เมื่อพร้อมใช้งาน
• คำขอการรวบรวมข้อมูลและหน้าเว็บที่จัดทำดัชนีของ Bing Webmaster Tools
• ประสิทธิภาพปัญญาประดิษฐ์ของ Bing Webmaster Tools
• การตรวจสอบ Sitemap และ lastmod รายวัน

API ของ Search Console สามารถดึงข้อมูลประสิทธิภาพตามหน้าเว็บ, คำค้นหา, วันที่, อุปกรณ์ และลักษณะการค้นหาได้ โดยอยู่ภายใต้ข้อจำกัดข้อมูลของมัน (developers.google.com)

การตรวจสอบการอ้างอิง

สร้างแผงการอ้างอิงที่มีคำค้นหาที่เสถียร 50 ถึง 200 รายการต่อหัวข้อ รันแผงนี้ตามกำหนดเวลาที่แน่นอนและบันทึก:

• แพลตฟอร์มค้นหาหรือไม่
• แหล่งที่มาใดปรากฏขึ้น
• URL ที่ทดสอบถูกอ้างอิงหรือไม่
• ลำดับการอ้างอิง
• วันที่และเวลาของคำตอบ
• หน้าเว็บมีการเปลี่ยนแปลงหรือไม่
• โมเดลหรือประสบการณ์การค้นหามีการเปลี่ยนแปลงหรือไม่

อย่าเปรียบเทียบจำนวนการอ้างอิงจากระบบที่แตกต่างกันราวกับว่าเท่ากัน Microsoft ระบุว่ากิจกรรมการอ้างอิงไม่ใช่คะแนนการจัดอันดับ, คะแนนอำนาจ, การวัดปริมาณการเข้าชม หรือคะแนนคุณภาพ (bing.com)

กฎการแจ้งเตือน

สร้างการแจ้งเตือนสำหรับ:

• Time to first byte เพิ่มขึ้นเกิน 25 เปอร์เซ็นต์
• Largest Contentful Paint ขยับเกิน 2.5 วินาทีที่ 75th percentile
• Cumulative Layout Shift ขยับเกิน 0.1
• การเพิ่มขึ้นอย่างต่อเนื่องของการตอบสนอง 5xx หรือ 429
• อัตราความสำเร็จของโปรแกรมรวบรวมข้อมูลลดลง
• การเปลี่ยนแปลง robots.txt
• ข้อผิดพลาด Sitemap
• จำนวนหน้าเว็บที่จัดทำดัชนีลดลงอย่างกะทันหัน
• การอ้างอิงด้วยปัญญาประดิษฐ์ลดลงอย่างกะทันหันในหลายแพลตฟอร์ม
• การเปลี่ยนแปลงปริมาณการอ้างอิงที่ส่งผลกระทบต่อแพลตฟอร์มเดียว

การลดลงของการอ้างอิงที่ส่งผลกระทบต่อแพลตฟอร์มเดียวอาจเกิดจากการเปลี่ยนแปลงโมเดล, ดัชนี, คำค้นหา หรือผลิตภัณฑ์ แทนที่จะเป็นปัญหาด้านประสิทธิภาพของหน้าเว็บ Microsoft เตือนอย่างชัดเจนว่าแนวโน้มการอ้างอิงเป็นเพียงการสังเกตการณ์และสามารถเปลี่ยนแปลงได้เนื่องจากการอัปเดตเนื้อหา, ความต้องการของผู้ใช้ และการเปลี่ยนแปลงระบบหรือโมเดล (bing.com)

บทสรุปสุดท้าย

ข้อสรุปที่สามารถโต้แย้งได้น้อยที่สุดคือ:

หน้าเว็บที่เร็วขึ้นสามารถปรับปรุงประสิทธิภาพในการรวบรวมข้อมูลได้ โดยเฉพาะอย่างยิ่งเมื่อ Latency ของเซิร์ฟเวอร์, ขนาดทรัพยากร, ข้อผิดพลาด หรือความล่าช้าในการเรนเดอร์เป็นปัจจัยจำกัด แต่ปัจจุบันยังไม่มีหลักฐานที่แข็งแกร่งว่าค่า Core Web Vitals ที่ต่ำลงโดยตรงทำให้ระบบปัญญาประดิษฐ์เลือกหน้าเว็บเป็นแหล่งอ้างอิง

ห่วงโซ่สาเหตุที่คาดการณ์ไว้คือ:

text Lower latency → better server capacity → fewer failed or delayed fetches → faster discovery and processing → improved chance of being indexed and retrieved → possible increase in citations

ขั้นตอนสุดท้ายยังคงไม่แน่นอน เนื่องจาก การเลือกการอ้างอิงขึ้นอยู่กับความเกี่ยวข้อง, คุณภาพ, ความสดใหม่, อำนาจและความน่าเชื่อถือ, เจตนาของคำค้นหา, อันดับการดึงข้อมูล และพฤติกรรมของระบบปัญญาประดิษฐ์แต่ละระบบ

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

1. ทำให้เนื้อหาสำคัญพร้อมใช้งานใน HTML เริ่มต้น
2. รักษา Time to first byte ให้เสถียร
3. ใช้การแคชที่ Edge สำหรับเนื้อหาสาธารณะ
4. บีบอัดและจัดลำดับความสำคัญของรูปภาพที่สำคัญ
5. ป้องกันการเปลี่ยนแปลงเค้าโครง
6. ส่งคืนรหัสสถานะที่น่าเชื่อถือ
7. อัปเดต Sitemap และลิงก์ภายในให้เป็นปัจจุบันอยู่เสมอ
8. อนุญาตให้โปรแกรมรวบรวมข้อมูลการค้นหาที่ถูกต้องเข้าถึง
9. วัดการรวบรวมข้อมูล, การจัดทำดัชนี, การดึงข้อมูล และการอ้างอิงเป็นขั้นตอนแยกกัน

แนวทางดังกล่าวจะสร้างเว็บไซต์ที่เร็วขึ้นสำหรับผู้คน, เว็บไซต์ที่ดีขึ้นสำหรับโปรแกรมรวบรวมข้อมูลการค้นหา และเป็นรากฐานที่สามารถทดสอบได้สำหรับการทำความเข้าใจการมองเห็นด้วยปัญญาประดิษฐ์