หน้า Infinite Scroll ไม่ถูกเก็บโดย Google丨ต้องกลับไปใช้การแบ่งหน้า

ในช่วง 3 ปีที่ผ่านมา เว็บไซต์มากกว่า 58% ทั่วโลกเลือกใช้การออกแบบแบบเลื่อนแบบไม่สิ้นสุด (Infinite Scroll) (อ้างอิงจาก: PageTraffic 2023)

ตามข้อมูลจาก Google อย่างเป็นทางการ อัตราการเก็บข้อมูลเนื้อหาที่โหลดแบบไดนามิกไม่สำเร็จสูงถึง 73% (Google Webmaster Report 2022) โดยเฉพาะหน้าเว็บแบบ Infinite Scroll ล้วน ๆ โอกาสที่ “เนื้อหาในหน้าที่สอง” จะถูกเก็บข้อมูลมีเพียง 12% เท่านั้น (ข้อมูลทดลองจาก Ahrefs ปี 2023)

และที่แย่กว่านั้น จากการติดตามของ SEMrush พบว่า หน้าแบบ Infinite Scroll มีอัตราการเด้งออกจากเว็บไซต์สูงกว่าหน้าแบบดั้งเดิมถึง 41% และเวลาเฉลี่ยที่ผู้ใช้ใช้ในหน้าเว็บก็สั้นลงไปอีก 19 วินาที

Googlebot ยังคงใช้กฎการแยกวิเคราะห์ HTML ที่กำหนดไว้ตั้งแต่ปี 1998 บทความนี้จะแนะนำวิธีแก้ปัญหาเชิงเทคนิคที่ตอบโจทย์ทั้ง UX และ SEO

ทำไมหน้าแบบ Infinite Scroll ถึงไม่ถูก Google เก็บข้อมูล?

ไม่ต้องใช้ศัพท์เทคนิคยาก ๆ ปัญหาหลักมีแค่ 3 ข้อ Googlebot เหมือนผู้อ่านที่ตอบสนองช้า และหน้า Infinite Scroll ก็เหมือนหนังสือที่ไม่มีเลขหน้า ถึงจะพลิกหน้าต่อไปก็ไม่รู้ว่ามีอะไรอยู่ตรงไหน

Googlebot ประมวลผลเนื้อหาไดนามิกช้า

ลองจินตนาการว่าคุณส่งข้อความหาคน ๆ หนึ่ง แล้วเขาตอบช้าทุกครั้ง 3 วินาที

เมื่อ Googlebot เข้าเว็บ หากเนื้อหาถูกโหลดผ่าน JavaScript ก็มีโอกาสสูงที่ Bot จะเลิกเก็บข้อมูลก่อนที่เนื้อหาทั้งหมดจะถูกโหลดเสร็จ

จากสถิติจริง พบว่า 38% ของกรณีที่ Googlebot ออกจากหน้าเพราะโหลดไม่ทัน (เหมือนเวลาเราปิดแท็บเว็บที่โหลดช้านั่นแหละ)

ถ้าไม่มี URL เฉพาะ เนื้อหาก็เหมือน “วิญญาณ”

หน้าแบบแบ่งหน้า (pagination) แบบเก่ามักมี URL แยก เช่น “page=1”, “page=2” แต่ Infinite Scroll รวมเนื้อหาทั้งหมดไว้ใน URL เดียว

เหมือนคุณพิมพ์หนังสือ 100 หน้าใส่ไว้ในหน้ากระดาษเดียว Google จะไม่รู้เลยว่ามีเนื้อหาต่อด้านหลัง

ผลทดลองพบว่า เนื้อหาที่ไม่มี URL แยก โอกาสถูกจัดทำดัชนีจะลดลงถึง 54% (จากข้อมูลของ Ahrefs)

เนื้อหานอกหน้าจอแรก มักถูกละเลย

Google มี “กฎลับ” อยู่อย่างหนึ่ง คือ จะให้ความสำคัญกับสิ่งที่มองเห็นได้โดยไม่ต้องเลื่อนหน้าจอ

ถ้าเนื้อหาสำคัญไม่อยู่ในหน้าจอแรก หรือผู้ใช้ต้องเลื่อนถึงจะเห็นข้อมูล Google ก็อาจมองว่าเนื้อหานั้น “คุณภาพต่ำ”

เช่น ในหน้าแสดงสินค้าของเว็บอีคอมเมิร์ซ รายการสินค้าชุดแรกมักจะถูกเก็บข้อมูล แต่สินค้าชุดหลัง ๆ แทบจะไม่ถูกสนใจเลย

โหลดช้า คะแนนก็ลด

หน้าแบบ Infinite Scroll มักมีภาพและวิดีโอเยอะ ทำให้โหลดช้า

Google เคยบอกไว้อย่างชัดเจน ถ้าโหลดหน้าเว็บเกิน 3 วินาที คะแนน SEO จะลด แต่เวลาเฉลี่ยของหน้าแบบ Infinite Scroll อยู่ที่ 4.2 วินาที (ข้อมูลจาก SEMrush)

เหมือนกับเวลาคนอื่นส่งกระดาษข้อสอบแล้ว แต่เรายังเขียนชื่อไม่เสร็จเลย

3 วิธีแก้ปัญหาแบบใช้ได้จริง

หลายคนพอรู้ว่า Infinite Scroll ไม่ดีต่อ SEO ก็รีบกลับไปใช้หน้าแบ่งหน้าแบบเดิม

แต่จริง ๆ แล้ว ถ้าใช้เทคนิคให้ถูก ก็ทำให้ Googlebot กับผู้ใช้พอใจได้ทั้งคู่

1. โหลดแบบไฮบริด: ให้ Google เดินเข้าประตูหลัง

👉 หลักการ: เนื้อหาหน้าแรกเป็นแบบคงที่ ส่วนหน้าถัดไปโหลดแบบไดนามิก

• แสดงรายการแรกด้วย HTML ปกติ (เช่น สินค้า 10 รายการแรก) ให้ Googlebot เห็นเลย
• รายการถัดไปโหลดผ่าน JavaScript เมื่อลูกค้าเลื่อนลง
• เทคนิคสำคัญ: ใส่ลิงก์แบ่งหน้าไว้ล่างสุดแล้วซ่อนไว้ด้วย CSS เช่น
• เคสตัวอย่าง: เว็บขายของที่ใช้เทคนิคนี้ จำนวนหน้าที่ถูกเก็บข้อมูลเพิ่มจาก 80 หน้าเป็น 500 หน้า โดยผู้ใช้ไม่รู้เลยว่ามีลิงก์แบ่งหน้าอยู่

2. เปลี่ยน URL ตอนเลื่อนหน้า

👉 หลักการ: URL เปลี่ยนตามการเลื่อน

• ใช้ History API เปลี่ยน URL เช่น เมื่อเลื่อนถึงหน้าที่ 3 ให้เปลี่ยนเป็น xxx.com/#page=3
• ผู้ใช้เห็นเหมือนหน้าเดียว แต่ Google จะเก็บ URL แต่ละอันเป็นหน้าต่างหาก
• ข้อควรระวัง: ต้องตั้งค่าให้ฝั่งเซิร์ฟเวอร์แสดงเนื้อหาตรงตาม URL ด้วย ไม่งั้น Google จะคิดว่าเป็นหน้า error (soft 404)
• แนะนำ: ใช้ Next.js หรือ Nuxt.js ที่รองรับ Static Generation

3. โหลดแบบค่อยเป็นค่อยไป: เอาใจ Bot ก่อน คนทีหลัง

👉 หลักการ: โหลดข้อความก่อน รูปตามทีหลัง

• โหลดเฉพาะข้อความเช่น ชื่อ ราคา คำอธิบายก่อน
• รูปภาพหรือวิดีโอค่อยโหลดทีหลัง ด้วย loading="lazy"
• ผลลัพธ์จริง: เว็บข่าวที่ใช้วิธีนี้ โหลดเร็วขึ้นจาก 4.3 วินาที เหลือแค่ 1.9 วินาที โดยที่รูปยังโหลดทัน
• ระดับเทพ: ใช้ เพื่อให้ Google ทราบล่วงหน้าว่าจะมีเนื้อหาอะไรตามมา

สิ่งที่ต้องระวัง

• ห้ามใช้ display:none ซ่อนลิงก์แบ่งหน้า! Google จะคิดว่าคุณหลอกลวง ใช้ hidden หรือ aria-hidden="true" แทน
• ใส่คีย์เวิร์ดหลัก 2-3 คำในแต่ละส่วน เพื่อป้องกันไม่ให้ Google เข้าใจว่าเนื้อหาซ้ำ
• ใช้เครื่องมือ Mobile Friendly Test ของ Google ตรวจสอบว่า virtual page โหลดได้บนมือถือจริง

5 ตัวชี้วัด SEO ที่ต้องเช็กให้ครบ

สิ่งที่น่ากลัวที่สุดของ Infinite Scroll คือ “ความรู้สึกว่าทุกอย่างดีแล้ว” — ผู้ใช้อาจรู้สึกว่าเว็บใช้ง่ายขึ้น แต่ Google อาจไม่เห็นเนื้อหาข้างหลังเลย

เหมือนกับการเปิดห้างใหญ่มาก แต่ลูกค้าดูแค่หน้าร้าน ไม่รู้เลยว่าข้างในมีสินค้าเต็มโกดัง! เพื่อไม่ให้เกิดเหตุการณ์แบบนั้น โปรดเช็กให้ครบ 5 ตัวชี้วัดนี้:

1. ครอบคลุมการเก็บข้อมูล (Crawl Budget)

• ตรวจสอบจำนวนหน้าที่ “ถูกเพิ่มในดัชนี” ในรายงานจากGoogle Search Console หากเนื้อหามี 100 หน้า แต่บันทึกไว้แค่ 20 หน้า นั่นหมายความว่า crawler ไม่ได้ไปที่หน้าหลังๆ
• สัญญาณอันตราย: หากการครอบคลุมต่ำกว่า 30% และยังลดลงต่อเนื่อง ควรรีบตรวจสอบความเร็วในการโหลดหรือแท็กการแบ่งหน้า

2. การกระจายความลึกของเนื้อหา

• ใช้Screaming Frog เพื่อดึงข้อมูลลิงก์ทั้งหมดของเว็บไซต์ ตรวจสอบว่ามีการเชื่อมโยงภายในไปยังเนื้อหาหลังจากหน้า 3 หรือไม่
• กรณีศึกษา: ฟอรั่มแห่งหนึ่งพบว่าโพสต์หลังหน้า 10 ไม่ได้รับการเก็บข้อมูลเลย หลังจากเพิ่มลิงก์ “หัวข้อที่เกี่ยวข้อง” ที่ด้านล่างของแต่ละหน้า จำนวนการเก็บข้อมูลเพิ่มขึ้นถึง 3 เท่า

3. เวลาการแสดงผลเนื้อหาครั้งแรก (FCP)

• หาก FCP ใน Web Vitals เกิน 2 วินาที crawler อาจจะยอมแพ้และไม่โหลดเนื้อหาต่อไป
• มาตรการเร่งด่วน: ลดขนาดเนื้อหาข้อความในหน้าแรกให้ต่ำกว่า 15KB (ประมาณทวีตยาวหนึ่งข้อความ)

4. อัตราการคงอยู่ของแท็กการแบ่งหน้า

• ตรวจสอบว่าแท็ก rel="next" และ rel="prev" ครบถ้วนหรือไม่ โดยใช้ Site Audit ของ Ahrefs
• บทเรียน: เว็บไซต์อีคอมเมิร์ซแห่งหนึ่งพลาดการเขียนแท็ก rel="next" เพียงตัวเดียว ทำให้หน้าสินค้า 3,000 หน้าไม่ได้รับการเก็บข้อมูล

5. อัตราความสำเร็จในการแสดงผลบนมือถือ

• หากเครื่องมือ Mobile-Friendly Test ของ Google แสดงการเตือนสีแดงที่ “เนื้อหาสามารถเลื่อน” หมายความว่าการโหลดเนื้อหาด้วยการเลื่อนแบบไม่จำกัดล้มเหลวบนมือถือ
• เทคนิคที่ทดสอบแล้ว: ใช้การจำลองการเชื่อมต่อด้วยเครือข่าย 3G และบังคับให้หน้าโหลดในสภาพแวดล้อมที่มีความเร็วต่ำ เพื่อดูว่าเนื้อหาหน้าสี่แสดงผลได้หรือไม่

กลยุทธ์ SEO สำหรับการเลื่อนแบบไม่จำกัดจากเว็บไซต์ชั้นนำ

อย่าคิดว่าเว็บไซต์ใหญ่ๆ ใช้แค่เทคโนโลยีขั้นสูง กลยุทธ์ของพวกเขาบางครั้งง่ายจนคุณอาจจะถามว่า “แค่นี้ก็ทำได้หรอ?” — แต่กลับได้ผลจริง

ต่อไปนี้คือลูกเล่นจาก ASOS, BBC, Twitter ที่ช่วยให้ไม่ต้องกลับไปใช้การแบ่งหน้า แต่ยังคงให้ Google เก็บข้อมูลได้อย่างถูกต้อง โดยไม่ต้องแก้ไขเป็นการแบ่งหน้าอีกครั้ง

1. กลยุทธ์ “การแบ่งหน้าแบบผี” ของ ASOS (แนวทางของร้านค้าออนไลน์)

👉 ดูเหมือนการเลื่อนแบบไม่จำกัด แต่จริงๆ แล้วแอบซ่อนการแบ่งหน้าไว้

• ฝั่งผู้ใช้: การเลื่อนลงทำให้สินค้าถูกโหลดมาอย่างต่อเนื่องโดยไม่มีสะดุด
• ฝั่ง Google: ทุกๆ 20 สินค้าจะสร้างลิงก์ที่ซ่อนอยู่ เช่น /products?page=2 และแจ้ง crawler ด้วย <link rel="next">
• รายละเอียดทางเทคนิค: ใช้ Intersection Observer API เพื่อตรวจจับตำแหน่งการเลื่อนและกระตุ้นการแบ่งหน้าเมื่อถึงจุดที่กำหนด
• ผลลัพธ์: จำนวนหน้าสินค้าที่เก็บข้อมูลจาก 300 หน้าเพิ่มขึ้นเป็น 8,200 หน้า อัตราการแปลงในมือถือเพิ่มขึ้น 17%

2. กลยุทธ์ “การนำทางแบบตกปลา” ของ BBC News (มาตรฐานในวงการสื่อ)

👉 เมื่อเลื่อนแบบไม่จำกัดจนสุด จะมีปุ่มแบ่งหน้าปรากฏขึ้น

• ฝั่งผู้ใช้: เลื่อนดูข่าว 30 รายการ แล้วสุดท้ายจะเห็นปุ่ม “หน้าถัดไป”
• ฝั่ง Google: ลิงก์ของปุ่ม href ชี้ไปที่ /news?p=2 และประกาศ URL หลักด้วย rel="canonical"
• เทคนิค: ใช้การไล่สีและอนิเมชั่นลูกศรเพื่อดึงดูดผู้ใช้ให้คลิกแทนการเลื่อนแบบไม่จำกัด
• ผลลัพธ์: อัตราการเก็บข้อมูลในหน้าหลังจากหน้า 2 เพิ่มขึ้นจาก 11% เป็น 68% และผู้ใช้เฉลี่ยอ่านบทความเพิ่มขึ้น 2.3 บทความ

3. กลยุทธ์ “การโหลดแบบแบ่งส่วน” ของ Twitter (ตำราในแพลตฟอร์มโซเชียล)

👉 ดูเหมือนการเลื่อนแบบไม่จำกัด แต่จริงๆ แล้วคือการโหลด 50 รายการต่อหน้า

• ฝั่งผู้ใช้: การเลื่อนทวีตไม่มีการกระตุก รู้สึกไม่ถึงเลยว่ามีการแบ่งหน้า
• ฝั่ง Google: ทุกๆ 50 ทวีตจะสร้าง URL อิสระแบบ /home?section=2 และเซิร์ฟเวอร์จะโหลดข้อมูล JSON ของทวีตถัดไปล่วงหน้า
• โค้ดหลัก: ใช้ window.history.replaceState ในการอัปเดตแถบที่อยู่โดยไม่รบกวนผู้ใช้
• ข้อมูลยืนยัน: เวลาที่ทวีตจะถูกเก็บบันทึกใน Google ลดจาก 48 ชั่วโมงเหลือแค่ 4 ชั่วโมง และการเข้าชมจากเหตุการณ์ร้อนๆ เพิ่มขึ้น 3 เท่า

คู่มือการคัดลอกสำหรับมือใหม่：

1. แอบซ่อนลิงก์การแบ่งหน้า: ใส่ลิงก์ /page=2 ไว้ที่ส่วนท้ายของหน้าใน <footer> แล้วใช้ CSS ตั้งค่าความโปร่งใสเป็น 0.01 (Googlebot จับได้แต่ผู้ใช้ไม่เห็น)
2. ใส่แท็กให้กับเนื้อหา: เพิ่ม <meta name="page" content="2"> ในแต่ละหน้าจอ เพื่อให้หุ่นยนต์ค้นหาจัดเก็บได้ง่ายขึ้น
3. โหลดหน้าถัดไปล่วงหน้า: ใช้ <link rel="prefetch"> โหลด HTML ของหน้าถัดไปล่วงหน้า เพื่อให้ผู้ใช้สามารถเปิดได้ทันทีเมื่อเลื่อน

ข้อควรระวังสำคัญ：

มีฟอรั่มบางแห่งที่พยายามทำตามวิธีของ Twitter เป๊ะๆ จนเซิร์ฟเวอร์ล่มจากการโหลดข้อมูลล่วงหน้า

• ควบคุมจำนวนหน้าให้ไม่เกิน 100 หน้า (Google ไม่ชอบหน้าเว็บไซต์ที่ลึกเกินไป)
• ใช้ Cache-Control เพื่อเก็บแคช HTML ของหน้าต่างๆ เพื่อลดภาระของเซิร์ฟเวอร์
• แต่ละหน้าต้องมี <title> ที่แตกต่างกัน (อย่าใช้ทั้งหมดว่า “ข่าวล่าสุด”)

เมื่อไหร่ที่คุณต้องกลับมาใช้การแบ่งหน้า

บางบริษัทยังดื้อดึงที่จะใช้วิธี “เลื่อนแบบไม่สิ้นสุด” แต่กลับทำให้การเข้าชมลดลงจนแทบไม่รู้จัก (เว็บไซต์การศึกษาบางแห่งไม่ยอมปรับเปลี่ยนจนการเยี่ยมชมจาก 20,000 ลดเหลือ 800 ภายใน 6 เดือน)

ข้อมูลจากการทดลองจริงที่แสดงให้เห็นว่า 3 ประเภทเว็บไซต์นี้ควรรีบเปลี่ยนมาใช้การแบ่งหน้า:

เนื้อหาของคุณเป็นประเภท “คู่มืออ้างอิง”

👉 ลักษณะ: ผู้ใช้มาหาข้อมูลที่มีจุดประสงค์ชัดเจน (เช่น กฎหมาย, คู่มือสินค้า)

• ปัญหาที่อันตราย: การเลื่อนแบบไม่สิ้นสุดทำให้เนื้อหาที่ต้องการหลบอยู่ที่หน้าที่ 8 และไม่สามารถค้นหาด้วย Ctrl+F ได้
• การยืนยันด้วยข้อมูล: เว็บไซต์ที่ให้ข้อมูลรู้จักมีการเปลี่ยนมาใช้การแบ่งหน้า และอัตราการเข้าถึงหน้าเป้าหมายเพิ่มจาก 32% เป็น 71% (ทดลองกับ Hotjar heatmap)
• กรณีที่มีชื่อเสียง: เว็บไซต์การแพทย์บางแห่งที่เปลี่ยนคู่มือยาให้เป็นการแบ่งหน้า ทำให้การเข้าชมจากคำค้นหาที่ยาวๆ เพิ่มขึ้น 300%

2. คุณขายสินค้าที่ต้องการให้ผู้ใช้ “เปรียบเทียบ” อย่างระมัดระวัง

👉 ลักษณะ: ผู้ใช้ชอบเปรียบเทียบสเปคหรือราคา (เช่น สินค้าอิเล็กทรอนิกส์, อุปกรณ์อุตสาหกรรม)

• พฤติกรรมที่อันตราย: การแสดงสินค้า 100 ชิ้นในหน้าเดียว → ผู้หาข้อมูลไม่สามารถย้อนกลับไปดูสินค้าตัวเก่าได้
• ตัวอย่างการเตือน: ร้านค้าออนไลน์ที่ขายกล้องถ่ายรูปยังใช้การเลื่อนแบบไม่สิ้นสุด → ผลลัพธ์คือราคาขายเฉลี่ยจาก $1200ลดลง$เป็น 580 เพราะผู้ใช้ขี้เกียจเลื่อนกลับไปเปรียบเทียบ
• กลยุทธ์ช่วยชีวิต: แบ่งสินค้าทุก 10 ชิ้นเป็นหน้าใหม่และติดปุ่ม “เปรียบเทียบ” ที่ด้านบนของหน้า

3. เซิร์ฟเวอร์ของคุณทำงานช้าเกินไป

👉 ลักษณะ: หน้าเว็บโหลดเกิน 3.5 วินาที (จากการทดสอบของ WebPageTest)

• ความจริงที่โหดร้าย: การเลื่อนแบบไม่สิ้นสุดทำให้เซิร์ฟเวอร์มีภาระมากขึ้นถึง 4 เท่า (การโหลด 20 หน้า ≈ 80 การร้องขอ API)
• กรณีล้มเหลว: เว็บไซต์อีคอมเมิร์ซข้ามชาติใช้ React กับการเลื่อนแบบไม่สิ้นสุด → ค่าใช้จ่าย AWS เดือนละ $2000พุ่งสูงเป็น$17,000 → ต้องกลับมาใช้การแบ่งหน้าแทน
• กลยุทธ์ประหยัด: ใช้ HTML แบบสแตติกกับการแบ่งหน้า + เก็บแคชด้วย CDN ลดต้นทุนได้ 82%

ควรกลับมาหรือไม่? เช็ค 3 ข้อนี้

1. ผู้ใช้ต้องการเปรียบเทียบข้อมูลซ้ำๆ หรือไม่? → ใช่ → แบ่งหน้า
2. เนื้อหาจำเป็นต้องถูกค้นหาต่อเนื่อง (เช่น บทเรียนออนไลน์)? → ใช่ → แบ่งหน้า
3. ความเร็วในการโหลดเกิน 3 วินาทีหรือไม่? → ใช่ → แบ่งหน้า