JavaScript SEO คืออะไร ทำไมเว็บ React หรือ Next.js ต้องระวังเป็นพิเศษ
อธิบาย JavaScript SEO ทำไมเว็บที่ render ด้วย JavaScript ฝั่ง client เสี่ยงไม่ถูก index ความต่างของ CSR กับ SSR และวิธีตรวจว่า Googlebot เห็นเนื้อหาจริงไหม
ทีม NOAH · เผยแพร่ 2 กันยายน 2569 · อัปเดต 2 กันยายน 2569 · อ่าน 14 นาที
สรุปสั้น
- ✓JavaScript SEO คือการทำให้เว็บที่ใช้ JavaScript สร้างเนื้อหา ยังคงถูก Googlebot เห็นและ index ได้ครบเหมือนเว็บ HTML ปกติ
- ✓ปัญหาหลักเกิดกับเว็บที่ใช้ Client-side Rendering (CSR) ล้วน เพราะ HTML ตั้งต้นที่ Googlebot เห็นแทบว่างเปล่า
- ✓Server-side Rendering (SSR) และ Static Site Generation ช่วยให้เนื้อหาพร้อมอยู่ใน HTML ตั้งแต่แรก ลดความเสี่ยงเรื่อง index
- ✓เฟรมเวิร์กอย่าง Next.js รองรับ SSR ในตัว แต่ทีมยังต้องตั้งค่าถูกต้อง ไม่ใช่ใช้ default แล้วปลอดภัยเสมอ
- ✓วิธีตรวจที่แม่นที่สุดคือดู HTML ที่ Googlebot เห็นจริงผ่านเครื่องมือของ Google ไม่ใช่ดูแค่หน้าจอเบราว์เซอร์ของตัวเอง
ทีมพัฒนาเว็บด้วย React บ่อยครั้งเจอเหตุการณ์แปลก ๆ คือหน้าเว็บดูปกติทุกอย่างเวลาเปิดดูเอง แต่พอเช็กใน Search Console กลับพบว่า Google เห็นหน้าเปล่า ไม่มีข้อความ ไม่มีลิงก์ นี่คือปัญหาคลาสสิกของ JavaScript SEO ที่ทีมพัฒนาส่วนใหญ่ไม่รู้ว่ามีอยู่จนกว่าจะเจอเอง
ปัญหานี้ไม่ได้แปลว่าห้ามใช้ JavaScript หรือห้ามใช้ React แต่แปลว่าต้องเข้าใจว่าเบราว์เซอร์กับ Googlebot ไม่ได้เห็นหน้าเว็บแบบเดียวกันเสมอไป ถ้าไม่จัดการให้ถูก เนื้อหาที่คนเห็นเต็มหน้าจออาจไม่มีอยู่จริงสำหรับ Google เลย หัวข้อนี้เป็นส่วนหนึ่งของงานTechnical SEO ที่ทีมพัฒนาและทีม SEO ต้องคุยกันตั้งแต่เริ่มออกแบบเว็บ
JavaScript SEO คืออะไร
JavaScript SEO คืออะไร
JavaScript SEO คือแนวทางการทำให้เว็บไซต์ที่ใช้ JavaScript สร้างหรือแสดงเนื้อหา ยังคงถูก Googlebot เข้าถึง render และ index เนื้อหาได้ครบถ้วนเหมือนเว็บ HTML ทั่วไป Googlebot สามารถประมวลผล JavaScript ได้ แต่ต้องใช้ทรัพยากรและเวลามากกว่าการอ่าน HTML ตรง ๆ หากหน้าเว็บพึ่งพา JavaScript มากเกินไปโดยไม่มีทางเลือกสำรอง เนื้อหาบางส่วนอาจไม่ถูกเก็บเข้าดัชนี
Googlebot ทำงานเป็นสองขั้นตอนคร่าว ๆ คือดึง HTML ก่อน แล้วค่อยส่งไปประมวลผล JavaScript ในภายหลังผ่านกระบวนการที่เรียกว่า rendering ช่วงเวลาระหว่างสองขั้นตอนนี้อาจห่างกันหลายวันสำหรับเว็บที่ Google ไม่ได้ให้ความสำคัญสูง ทำให้หน้าที่เนื้อหาสำคัญโผล่มาหลัง JavaScript ทำงาน มีความเสี่ยงถูก index ช้ากว่าที่ควร
ตัวอย่าง: หน้าสินค้าที่ Googlebot เห็นเป็นหน้าว่าง
สมมติร้านขายเฟอร์นิเจอร์ออนไลน์สร้างเว็บด้วย React แบบ CSR ล้วน หน้าสินค้าทุกหน้าดึงชื่อสินค้า ราคา และรูปภาพผ่าน useEffect หลังหน้าโหลดเสร็จ เมื่อเจ้าของร้านเปิดเว็บดูเองในเบราว์เซอร์ ทุกอย่างแสดงผลปกติ แต่พอตรวจผ่าน URL Inspection ใน Search Console กลับพบว่า HTML ที่ Googlebot ดึงมามีแค่โครง div เปล่า ไม่มีชื่อสินค้าหรือราคาเลย เพราะ Googlebot บันทึกภาพหน้าจอในจังหวะที่ JavaScript ยังโหลดข้อมูลไม่เสร็จ ผลคือหน้าสินค้าหลายร้อยหน้าไม่ถูก index ทั้งที่หน้าเว็บดูสมบูรณ์ทุกอย่างเวลาดูด้วยตา
Client-side Rendering กับ Server-side Rendering ต่างกันอย่างไร
Client-side Rendering (CSR) คือรูปแบบที่ server ส่ง HTML เปล่าเกือบทั้งหมดมาให้ก่อน แล้วให้เบราว์เซอร์ดาวน์โหลดไฟล์ JavaScript มารันเองเพื่อสร้างเนื้อหาทั้งหมดบนฝั่งผู้ใช้ วิธีนี้เป็นค่าเริ่มต้นของแอป React ที่สร้างด้วย Create React App และเป็นรูปแบบที่เสี่ยงต่อ SEO มากที่สุด เพราะถ้า Googlebot render JavaScript ไม่สำเร็จหรือหยุดกลางทาง เนื้อหาจะไม่ถูกเห็นเลย
Server-side Rendering (SSR) คือรูปแบบที่ server สร้าง HTML ที่มีเนื้อหาครบถ้วนส่งมาให้ตั้งแต่ต้น แล้ว JavaScript ค่อยเข้ามาทำให้หน้าเว็บโต้ตอบได้ (hydration) ในภายหลัง วิธีนี้ทำให้ทั้งผู้ใช้และ Googlebot เห็นเนื้อหาทันทีโดยไม่ต้องรอ JavaScript ทำงานก่อน ลดความเสี่ยงเรื่อง index ได้มาก
| รูปแบบ | HTML ตั้งต้นมีเนื้อหาไหม | ความเสี่ยงต่อ SEO |
|---|---|---|
| Client-side Rendering (CSR) | ไม่มี ต้องรอ JavaScript ทำงานก่อน | สูง หากไม่มีทางเลือกสำรอง |
| Server-side Rendering (SSR) | มีครบตั้งแต่ request แรก | ต่ำ |
| Static Site Generation (SSG) | มีครบ สร้างไว้ล่วงหน้าเป็นไฟล์ HTML | ต่ำมาก |
| Hybrid (SSR/SSG บางหน้า + CSR บางส่วน) | ขึ้นกับการตั้งค่าของแต่ละหน้า | ปานกลาง ต้องตรวจทีละหน้า |
React, Next.js และ JavaScript SEO
React เองเป็นเพียงไลบรารีสำหรับสร้าง UI ไม่ได้กำหนดว่าต้อง render ฝั่งไหน ปัญหา SEO ส่วนใหญ่ที่ถูกเรียกว่า “React SEO” จริง ๆ แล้วมาจากการตั้งค่าโปรเจกต์เป็น CSR ล้วนโดยไม่รู้ตัว ไม่ใช่ตัว React เอง
Next.js ถูกสร้างขึ้นมาเพื่อแก้ปัญหานี้โดยตรง รองรับทั้ง SSR, SSG และ Incremental Static Regeneration ในตัว ทำให้นักพัฒนาสามารถเลือกได้ว่าหน้าไหนควร render ฝั่ง server หน้าไหนควร generate เป็นไฟล์ static ไว้ล่วงหน้า แต่การใช้ Next.js ไม่ได้แปลว่า SEO ปลอดภัยอัตโนมัติ ทีมยังต้องตรวจว่าแต่ละหน้าถูกตั้งค่า rendering ที่เหมาะสมจริง โดยเฉพาะหน้าที่ดึงข้อมูลแบบ client-side fetch หลังโหลดหน้าเสร็จแล้ว
หน้าที่ควรระวังเป็นพิเศษ
หน้าที่เนื้อหาหลักมาจากการเรียก API หลังหน้าโหลดเสร็จ (เช่น useEffect แล้วค่อย fetch) มีความเสี่ยงสูงว่า Googlebot จะเห็นหน้าว่างในรอบ crawl แรก ควรย้าย logic การดึงข้อมูลไปทำที่ฝั่ง server ก่อนส่ง HTML ออกไป
ตัวอย่าง: ย้ายหน้าบล็อกจาก client fetch มาเป็น SSG
สมมติทีมพัฒนาเว็บบริษัทหนึ่งสร้างหน้าบล็อกด้วย Next.js แต่ยังดึงเนื้อหาบทความผ่าน fetch ใน useEffect เหมือนตอนใช้ React ธรรมดา ทำให้หน้าบล็อกยังเป็น CSR ทั้งที่ใช้เฟรมเวิร์กที่รองรับ SSG อยู่แล้ว เมื่อทีมเปลี่ยนมาดึงข้อมูลบทความผ่านฟังก์ชันที่ทำงานฝั่ง build time แทน หน้า HTML ที่ส่งออกไปมีเนื้อหาบทความครบตั้งแต่ request แรก ผลคือรอบ crawl ถัดมา Googlebot เริ่มเก็บหน้าบทความใหม่เข้าดัชนีเร็วขึ้นอย่างเห็นได้ชัด เพราะไม่ต้องรอขั้นตอน render เพิ่มเติมอีกต่อไป
วิธีตรวจว่า Googlebot เห็นเนื้อหาจริงไหม
- 1ใช้ URL Inspection ใน Google Search Console แล้วดู “Screenshot” และ “HTML ที่ดึงมา” เพื่อดูสิ่งที่ Google เห็นจริง ไม่ใช่สิ่งที่เห็นในเบราว์เซอร์
- 2เปรียบเทียบ HTML ตั้งต้น (view-source) กับ HTML หลัง render (inspect element) ถ้าเนื้อหาสำคัญมีเฉพาะในฝั่งหลัง แปลว่าพึ่งพา JavaScript หนักเกินไป
- 3ตรวจว่าลิงก์ภายในเว็บเป็นแท็ก a href จริง ไม่ใช่ onClick หรือ div ที่ทำหน้าที่คล้ายลิงก์ เพราะ Googlebot ตามลิงก์จาก href เท่านั้น
- 4ตรวจว่า title, meta description และ structured data ถูกใส่ตั้งแต่ HTML ตั้งต้น ไม่ใช่ถูกเพิ่มเข้าไปทีหลังด้วย JavaScript
- 5ใช้เครื่องมือ crawl ที่รองรับการ render JavaScript เพื่อเทียบ HTML ก่อนและหลัง render ทั้งเว็บในคราวเดียว แทนการตรวจทีละหน้าด้วยมือ
วิธีตรวจสุขภาพ JavaScript SEO ทั้งเว็บทีละขั้นตอน
ขั้นตอนตรวจสุขภาพ JavaScript SEO
- 1
ไล่ URL Inspection ทีละหมวดหมู่หน้า
เลือกหน้าตัวแทนจากแต่ละหมวด เช่นหน้าแรก หน้าสินค้า หน้าบทความ อย่างละสองสามหน้า แล้วตรวจ HTML ที่ดึงมาทีละหมวด
- 2
บันทึกรายชื่อหน้าที่เนื้อหาหายไปในรอบ render
ทำรายการหน้าที่พบว่า HTML ตั้งต้นไม่มีเนื้อหาสำคัญ เพื่อจัดลำดับความสำคัญในการแก้
- 3
ตรวจสอบว่าไฟล์ JavaScript และ CSS ไม่ถูกบล็อกใน robots.txt
ถ้าไฟล์ที่จำเป็นต่อการ render ถูกบล็อก Googlebot จะ render หน้าไม่สมบูรณ์แม้เว็บจะตั้งค่า SSR ไว้แล้ว
- 4
ทดสอบซ้ำหลังแก้ไขทุกครั้งผ่าน URL Inspection
ยืนยันว่า HTML ที่ดึงมาใหม่มีเนื้อหาครบก่อนจะถือว่าหน้านั้นแก้เสร็จ
เช็กลิสต์ก่อนปล่อยหน้าเว็บใหม่ที่ใช้ JavaScript
- หน้าที่ต้องติดอันดับใช้ SSR หรือ SSG ไม่ใช่ CSR ล้วน
- เนื้อหาหลัก title และ meta description อยู่ใน HTML ตั้งต้น ไม่ต้องรอ JavaScript ทำงานก่อน
- ลิงก์ภายในทั้งหมดเป็นแท็ก a href ที่ Googlebot ตามได้
- ไฟล์ JavaScript และ CSS ที่จำเป็นต่อการ render ไม่ถูกบล็อกใน robots.txt
ข้อผิดพลาดที่เจอบ่อย
- ปล่อยให้เว็บใหม่เป็น CSR ล้วนตั้งแต่เริ่มโปรเจกต์โดยไม่ได้ประเมินผลกระทบต่อ SEO ก่อน
- บล็อกไฟล์ JavaScript หรือ CSS ใน robots.txt โดยไม่ตั้งใจ ทำให้ Googlebot render หน้าไม่สมบูรณ์
- ใส่ลิงก์ภายในด้วย JavaScript event แทนแท็ก a ทำให้ Googlebot ค้นพบหน้าใหม่ได้ช้าลง
- เข้าใจว่าเห็นเนื้อหาในเบราว์เซอร์ตัวเองแล้วเท่ากับ Google เห็นเหมือนกัน ทั้งที่ยังไม่เคยตรวจผ่าน URL Inspection จริง
- ใช้ Next.js แต่ยังดึงข้อมูลเนื้อหาหลักผ่าน client-side fetch เหมือนแอป React ทั่วไป ทำให้เสียประโยชน์ของ SSR/SSG ที่เฟรมเวิร์กมีให้
การ render ล่าช้าเชื่อมกับความเร็วเว็บด้วย
เว็บที่พึ่งพา JavaScript หนักมักมีปัญหา Core Web Vitals ตามมาด้วย โดยเฉพาะ LCP ที่ช้าเพราะต้องรอ JavaScript ทำงานก่อนเนื้อหาหลักจะปรากฏ อ่านเพิ่มที่ LCP คือ
คำถามที่พบบ่อย
เว็บที่ใช้ React ทั้งหมดจะติดอันดับได้ไหม+
ได้ ถ้าตั้งค่า render ให้ถูกต้อง เช่นใช้ Next.js แบบ SSR หรือ SSG แทน CSR ล้วน หลายเว็บใหญ่ที่ใช้ React เป็นฐานก็ติดอันดับดีเพราะจัดการเรื่อง rendering ให้ Googlebot เห็นเนื้อหาตั้งแต่ HTML แรกแล้ว
Googlebot render JavaScript ได้จริงหรือไม่+
ได้ Googlebot ใช้เครื่องมือ render ที่อิงจาก Chromium รุ่นล่าสุด แต่การ render ต้องใช้ทรัพยากรมากกว่าการอ่าน HTML ตรง ๆ และอาจเกิดขึ้นช้ากว่าขั้นตอนแรกที่ดึง HTML หลายวัน จึงไม่ควรพึ่งพา JavaScript เพียงอย่างเดียวสำหรับเนื้อหาสำคัญ
SSR กับ SSG ต่างกันอย่างไรในมุม SEO+
SSR สร้าง HTML ใหม่ทุกครั้งที่มี request เข้ามา เหมาะกับหน้าที่ข้อมูลเปลี่ยนบ่อย ส่วน SSG สร้าง HTML ไว้ล่วงหน้าเป็นไฟล์ static เหมาะกับหน้าที่เนื้อหาไม่เปลี่ยนบ่อย ทั้งสองแบบให้ผลดีต่อ SEO ใกล้เคียงกันเพราะ Googlebot เห็นเนื้อหาครบตั้งแต่ HTML แรก
จำเป็นต้องเปลี่ยนจาก CSR เป็น SSR ทั้งเว็บไหม+
ไม่จำเป็นเสมอไป หน้าที่ไม่ต้องการติดอันดับ เช่นหน้าหลังบ้านหรือหน้าที่ต้องล็อกอินก่อนเข้า สามารถเป็น CSR ต่อไปได้ ควรเน้นแก้เฉพาะหน้าที่ต้องพึ่งการค้นหาแบบ organic เช่นหน้าสินค้าหรือหน้าบทความ
ใช้เครื่องมืออะไรตรวจ JavaScript SEO ได้บ้าง+
เครื่องมือหลักที่ควรใช้คือ URL Inspection ใน Google Search Console เพราะเป็นข้อมูลจาก Googlebot จริง นอกจากนี้เครื่องมือ crawl แบบ desktop บางตัวก็รองรับการ render JavaScript ระหว่าง crawl ทำให้เห็นความต่างระหว่าง HTML ตั้งต้นกับ HTML หลัง render ได้
ถ้าไม่มีทีมพัฒนาที่เชี่ยวชาญเรื่อง SSR ควรทำอย่างไร+
เริ่มจากตรวจสอบว่าหน้าที่สำคัญที่สุดต่อธุรกิจ เช่นหน้าแรกและหน้าสินค้าหลัก มีปัญหานี้หรือไม่ก่อน แล้วปรึกษาผู้พัฒนาที่มีประสบการณ์ Next.js หรือเฟรมเวิร์กที่รองรับ SSR โดยตรง แทนที่จะพยายามแก้ทั้งเว็บพร้อมกันโดยไม่มีความชำนาญ
สรุป
JavaScript SEO ไม่ใช่เรื่องห้ามใช้เทคโนโลยีใหม่ แต่คือความเข้าใจว่า Googlebot ต้องทำงานหนักขึ้นเมื่อเจอเว็บที่พึ่งพา JavaScript มาก ทางที่ปลอดภัยที่สุดคือเลือก SSR หรือ SSG สำหรับหน้าที่ต้องพึ่งการค้นหา แล้วตรวจสอบผ่าน URL Inspection เสมอ ไม่ใช่เชื่อแค่สิ่งที่เห็นในเบราว์เซอร์ของตัวเอง
เตรียมเนื้อหาให้พร้อมก่อนขึ้นเว็บ
ไม่ว่าเว็บจะ render แบบไหน เนื้อหาที่มีโครงสร้างชัดเจนและตอบคำถามผู้อ่านตรงประเด็นยังเป็นพื้นฐานที่ขาดไม่ได้ NOAH ช่วยวางแผนและเขียนเนื้อหา SEO ให้พร้อมก่อนนำไปติดตั้งบนเว็บของคุณ
เริ่มต้นใช้งาน