JavaScript SEO: ให้หน้า JS ติดดัชนี

การจัดทำดัชนีเกิดขึ้นในสองรอบ

Googlebot ดึงข้อมูล HTML ดิบของคุณก่อนและสามารถจัดทำดัชนีเนื้อหาใด ๆ ที่มีอยู่แล้วในการตอบสนองเริ่มต้นนั้นได้เกือบทันที สิ่งใดที่ปรากฏหลัง JavaScript รันเท่านั้นจะถูกเข้าคิวสำหรับรอบที่สอง — การเรนเดอร์ — ซึ่งใช้ทรัพยากรแยกต่างหากและอาจล่าช้ากว่าการ crawl เริ่มต้นตั้งแต่ไม่กี่วินาทีไปจนถึงนานกว่านั้นมากบนเว็บไซต์ที่มีข้อจำกัดด้าน crawl หากเนื้อหาหรือลิงก์ภายในของคุณมีอยู่หลังรอบที่สองเท่านั้น คุณกำลังพึ่งพาเส้นทางที่ช้ากว่าและไม่แน่นอนกว่าในการถูกจัดทำดัชนีเลย

สิ่งที่ทำให้การจัดทำดัชนีเสียหายจริง ๆ

• เนื้อหาหลักหรือลิงก์ภายในที่เรนเดอร์หลังการดึงข้อมูลฝั่งไคลเอนต์เท่านั้น โดยไม่มีอะไรที่มีความหมายใน HTML เริ่มต้น
• เนื้อหาที่ถูกล็อกไว้หลังการกระทำของผู้ใช้ — การคลิก การเลื่อน การชี้เมาส์ — ที่ Googlebot ไม่มีเหตุผลที่จะทำ
• ไฟล์ JS หรือ CSS ที่ถูกบล็อกใน robots.txt ที่หน้าเว็บต้องการเพื่อเรนเดอร์อย่างถูกต้อง ดูrobots.txt เทียบกับ noindexว่าการบล็อกอาจส่งผลย้อนกลับได้อย่างไร
• การกำหนดเส้นทางฝั่งไคลเอนต์ที่ไม่เคยเปลี่ยนสถานะ HTTP จริง — เส้นทางที่เสียหายอาจแสดงว่างเปล่าหรือแสดงข้อความไม่พบในขณะที่ยังคงส่งกลับ 200 ซึ่งปรากฏเป็นsoft 404
• ข้อผิดพลาดในการ hydration หรือการเรนเดอร์ที่เกิดขึ้นเฉพาะในสภาพแวดล้อมเบราว์เซอร์แบบ headless และไม่มีใครสังเกตเห็นในการทดสอบด้วยตนเองตามปกติ

วิธีตรวจสอบสิ่งที่ Google เห็นจริง ๆ

เครื่องมือตรวจสอบ URL ของ Search Console มีมุมมอง "Tested page" ที่แสดง HTML ที่เรนเดอร์แล้วและภาพหน้าจอหลังจากตัวเรนเดอร์ของ Google ทำงาน — ไม่ใช่แค่การตอบสนองดิบ เปรียบเทียบกับ HTML ต้นทางของคุณ: หากเนื้อหาหรือลิงก์สำคัญหายไปจากการตอบสนองดิบแต่มีอยู่หลังการเรนเดอร์ แสดงว่าคุณกำลังพึ่งพาคิวการเรนเดอร์ทั้งหมดแทนที่จะเป็นการ crawl เริ่มต้นที่รวดเร็ว

สิ่งที่ช่วยได้จริง

• เรนเดอร์ฝั่งเซิร์ฟเวอร์ (หรือสร้างแบบ static) เนื้อหาและลิงก์นำทางที่สำคัญต่อ SEO แทนที่จะดึงข้อมูลฝั่งไคลเอนต์หลังโหลด
• ใช้อีลิเมนต์ <a href> จริงสำหรับลิงก์ภายใน ไม่ใช่ตัวจัดการคลิกบนอีลิเมนต์ที่ไม่ใช่ anchor — Googlebot ติดตาม href ไม่ใช่การผูก event ของ JavaScript ตามอำเภอใจ
• อย่าบล็อกชุด JS/CSS ที่หน้าเว็บต้องพึ่งพาในการเรนเดอร์ — Google ต้องดึงข้อมูลเหล่านั้นเพื่อเรนเดอร์หน้าเว็บได้เลย
• เมื่อหน้าเว็บได้รับการแก้ไขแล้ว อย่าเพียงแค่รอรอบการเรนเดอร์ถัดไป — ขอจัดทำดัชนีใหม่โดยตรง หรือส่ง URL ผ่าน IndexNow เพื่อให้เวอร์ชันที่แก้ไขแล้วถูกรับไปตามกำหนดการของคุณแทนคิวของตัวเรนเดอร์

ข้อควรทราบเฉพาะแต่ละเฟรมเวิร์ก

• แอป React ฝั่งไคลเอนต์: single-page app แบบพื้นฐานจะส่งโครง HTML ที่แทบว่างเปล่า สำหรับหน้าที่ต้องการติดอันดับ ให้ใช้เฟรมเวิร์กที่รองรับการเรนเดอร์ฝั่งเซิร์ฟเวอร์หรือการสร้างแบบ static
• Next.js และ Nuxt: การเรนเดอร์ฝั่งเซิร์ฟเวอร์และการสร้างแบบ static จะใส่เนื้อหาไว้ใน HTML เริ่มต้นเป็นค่าเริ่มต้น ระวังเนื้อหาสำคัญที่โหลดเฉพาะใน effect ฝั่งไคลเอนต์
• Angular และ Vue: ใช้การเรนเดอร์ฝั่งเซิร์ฟเวอร์ของ Angular หรือใช้ Nuxt สำหรับ Vue เพื่อให้หน้าเว็บส่งมาพร้อมเนื้อหาใน HTML อยู่แล้ว
• Infinite scroll: ใช้คู่กับ URL แบบแบ่งหน้าที่โหลดได้ด้วยตัวเอง เพื่อให้ crawler เข้าถึงรายการที่อยู่เลยหน้าจอแรกไปได้

การทดสอบด่วนที่คุณทำได้วันนี้

เปิดหน้าเว็บ เลือก View Page Source (ไม่ใช่ Inspect) แล้วค้นหาประโยคจากเนื้อหาหลักและ URL ของลิงก์ภายในสองสามรายการ หากไม่พบในซอร์สโค้ด แสดงว่าสิ่งเหล่านั้นพึ่งพา JavaScript จากนั้นรันการตรวจสอบความสามารถในการจัดทำดัชนีฟรีเพื่อยืนยันว่าหน้าเว็บส่งกลับรหัส 200 ไม่ได้ตั้งค่าเป็น noindex และมี canonical ที่ถูกต้อง