Technical SEO กับ On-page SEO: ความแตกต่างและแนวปฏิบัติ

คำนิยามสั้น ๆ และกรอบความคิด

ก่อนลงรายละเอียดเชิงเทคนิค ให้ตั้งกรอบความเข้าใจง่าย ๆ: technical SEO เป็นงานที่ดูแลโครงสร้างพื้นฐานและการสื่อสารระหว่างเว็บไซต์กับเครื่องมือค้นหา ส่วน on-page SEO เป็นงานที่ปรับแต่งสัญญาณบนหน้าเพื่อให้ทั้งผู้ใช้และเครื่องมือค้นหาเข้าใจความเกี่ยวข้องของเนื้อหา ทั้งสองทำงานร่วมกัน — ปัญหาที่ฝังอยู่ในชั้นโครงสร้างจะจำกัดผลของงานปรับแต่งเนื้อหา และเนื้อหาที่ไม่ตอบโจทย์ผู้ใช้จะทำให้การแก้ไขโครงสร้างไม่คุ้มค่า

นิยาม: technical SEO vs on-page SEO

technical SEO

technical SEO โฟกัสที่การค้นพบ (crawling), การเก็บข้อมูลและแสดงผล (rendering), การตัดสินใจจัดทำดัชนี (indexing) และความสามารถของหน้าในการถูกนำมาใช้เป็นสัญญาณจัดอันดับ เช่น โครงสร้าง URL, แท็ก canonical, การจัดการการเปลี่ยนเส้นทาง, HTTP status, XML sitemaps, structured data, JavaScript rendering, และความเร็วหน้า (Core Web Vitals). Google uses the mobile version as its primary basis for crawling and indexing. Since July 2024, Google crawls sites for Search with Googlebot Smartphone by default.

on-page SEO

on-page SEO ครอบคลุมสัญญาณที่ปรากฏบนหน้า เช่น โครงสร้างหัวข้อ (H1–Hn), เมตาแท็ก (title, meta description), ความสอดคล้องกับ search intent (เนื้อหา ตอบคำถามของผู้ค้นหา), คุณภาพของเนื้อหา, anchor text, internal linking และ structured data ที่อธิบายความหมายของเนื้อหาเพื่อ rich results หรือ AI Overviews ใน SERP

กลไกพื้นฐานและความสัมพันธ์เชิงสาเหตุ

แยก 3 ขั้นตอนสำคัญเพื่อทำความเข้าใจบทบาทของแต่ละด้าน: Crawling → Indexing → Ranking. Technical SEO มักเป็นตัวกำหนดว่าเครื่องมือค้นหาจะพบและสามารถประมวลผลหน้าได้หรือไม่ (crawling, rendering, indexing) ขณะที่ on-page SEO ส่งสัญญาณความเกี่ยวข้องและประสบการณ์ผู้ใช้ที่ช่วยในขั้นตอนการจัดอันดับ. ตัวอย่างเช่น หากหน้าไม่สามารถเรนเดอร์ JavaScript ได้หรือถูกบล็อกโดย robots.txt หน้าอาจไม่ถูก index แม้เนื้อหาจะดี — นี่คือปัญหา technical ที่ต้องแก้ก่อนจะคาดหวังผลจากการปรับเนื้อหา

วิธีตรวจสอบเชิงปฏิบัติ — ขั้นตอนและคำสั่งที่ใช้ได้จริง

ตรวจสอบ crawlability และ status

สิ่งที่ต้องเช็ก: HTTP status, robots headers, X-Robots-Tag, และการตอบสนองของเซิร์ฟเวอร์. ตัวอย่างคำสั่ง curl ที่ใช้ได้:

• ตรวจเฉพาะ headers: curl -I https://example.com/page — คำสั่งนี้คืนเฉพาะ response headers เช่น HTTP/ status และ X-Robots-Tag

• ตรวจ HTML สำหรับ user-agent เฉพาะหรือการเรนเดอร์: curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/page — ใช้ -A เพื่อจำลอง user-agent; อย่าใช้ผลลัพธ์นี้เพื่อ justify การให้เนื้อหาต่างกับผู้ใช้จริง

ตรวจการเรนเดอร์และ JavaScript

ใช้ Chrome DevTools (Network, Elements) ในโหมด device emulation เพื่อดู DOM ที่ผู้ใช้เห็นจริง และใช้ Lighthouse เพื่อประเมินการเรนเดอร์และ Core Web Vitals (LCP, INP, CLS). หากต้องการเปรียบเทียบสิ่งที่เครื่องมือค้นหาเห็นกับสิ่งที่ผู้ใช้เห็น ให้ใช้ URL Inspection ใน Google Search Console สำหรับหน้าในโดเมนที่คุณเป็นเจ้าของ — เครื่องมือนี้แสดงรหัสสถานะ การฉายภาพของหน้า และข้อบันทึกการ indexation

ตรวจ indexation และสัญญาณสาธารณะ

สำหรับหน้าในโดเมนของคุณ: ใช้ URL Inspection ใน Google Search Console เป็นแหล่งข้อมูลที่เชื่อถือได้เกี่ยวกับสถานะการ indexation และปัญหาที่เครื่องมือค้นพบบนหน้า. สำหรับการตรวจหน้าของผู้เผยแพร่ภายนอก ให้ใช้เครื่องมือสาธารณะเช่นการค้นหาด้วย site: operator, การค้นหาด้วยข้อความเฉพาะ, หรือเครื่องมือสแกนภายนอก แต่จำไว้ว่า site: เป็นสัญญาณบ่งชี้ ไม่ใช่ผลลัพธ์ที่ยืนยันการ indexation อย่างเป็นทางการ

ตรวจคุณภาพ on-page

เช็ครายการต่อไปนี้เป็นประจำ: title tag ที่ชัดเจน ดึงดูดความสนใจ และไม่ยาวเกินไป; H1 ที่สอดคล้องกับ title; meta description ที่สรุป intent; ความครบถ้วนของเนื้อหา เทียบกับคำถามที่ผู้ใช้มี; การใช้งาน structured data ด้วย Rich Results Test และ Schema Markup Validator (schema.org) เพื่อตรวจว่ายังไม่เกิดข้อผิดพลาดของไวยากรณ์หรือประเภทที่ไม่สนับสนุน

ตัวอย่างโค้ดลิงก์บนหน้า (syntax ตัวอย่างให้ชัด):

• ลิงก์ปกติ: ตัวอย่าง • ลิงก์สำหรับเนื้อหาที่ได้รับค่าตอบแทน: ตัวอย่าง • ลิงก์จาก user-generated content: ตัวอย่าง • ลิงก์ที่ต้องการเป็น hint เพื่อไม่ให้เครื่องมือค้นหาใช้: ตัวอย่าง

รายการตรวจสอบเร็วก่อนเปลี่ยนแปลงใหญ่ (pre-deployment checklist)

ยืนยันว่า URL สำคัญไม่ถูกบล็อกโดย robots.txt หรือ X-Robots-Tag

ตรวจ canonical tags ว่าไม่ส่งไปยังหน้าไม่เกี่ยวข้อง

ยืนยันการตอบสนอง HTTP ถูกต้อง (200/301/404 ตามกรณี) โดยใช้ curl -I

ทดสอบการเรนเดอร์ที่ผู้ใช้จะเห็นด้วย Chrome DevTools และ Lighthouse

ตรวจ meta tags และโครงสร้าง H1–Hn เพื่อความสอดคล้องกับ search intent

ข้อผิดพลาดที่พบบ่อยและวิธีแก้

ด้าน technical:

JavaScript สำคัญ ๆ ถูกโหลดแบบ lazy หรือบล็อกการเรนเดอร์ ทำให้เนื้อหาสำคัญไม่อยู่ใน initial DOM — แก้โดยให้เนื้อหาหลักอยู่ใน HTML หรือใช้ server-side rendering / hybrid rendering

การตั้งค่า canonical ผิด ส่งผลให้หน้าที่ควร index ถูกมองข้าม — ตรวจความสอดคล้องและใช้ URL แบบเป็นมาตรฐาน

ด้าน on-page:

เนื้อหาไม่ตอบ intent ของผู้ค้นหา — แก้โดยทำ research เรื่อง intent และปรับโครงสร้างหน้าให้ตอบคำถามหลักก่อน

title/description ซ้ำหรือไม่สื่อความหมาย — ตรวจและเขียนใหม่โดยยึด UX และ CTR เป็นแนวทาง

การจัดลำดับความสำคัญระหว่าง technical และ on-page

การตัดสินใจว่าจะเริ่มจาก technical หรือ on-page ขึ้นกับปัญหาที่ตรวจพบเป็นหลัก: หากหน้าไม่ถูกค้นพบหรือไม่ index ให้เริ่มจาก technical fixes ก่อน เพราะการปรับเนื้อหาจะไม่มีผลหากหน้าไม่ถูกเก็บในดัชนี; หากหน้า index อยู่แต่มี CTR หรือการมีส่วนร่วมต่ำ ให้เริ่มจาก on-page เพื่อปรับคุณภาพเนื้อหาและสัญญาณที่สำคัญต่อผู้ใช้ การผสานงานแบบ iteration โดยทีมเทคนิคและคอนเทนต์พร้อมทดสอบ A/B เป็นวิธีปฏิบัติที่มีประสิทธิภาพ

หากต้องการอ่านแนวทางการจัดการ technical tasks อย่างละเอียด ให้ดูคู่มือที่เกี่ยวข้อง:

ตัวอย่างการวินิจฉัยปัญหาแบบสั้น ๆ

ตัวอย่าง A — หน้าเพจที่เนื้อหาดีแต่ไม่ปรากฏในผลการค้นหา: เริ่มจากตรวจ robots.txt, X-Robots-Tag, และ canonical; ใช้ curl -I ตรวจ status; หาก headers ถูกต้อง ให้ใช้ URL Inspection เพื่อตรวจเหตุผลการไม่ถูก index; หากมีปัญหาเรื่องการเรนเดอร์ JavaScript ให้ทดสอบด้วย Chrome DevTools แล้วพิจารณา server-side rendering หรือ prerendering สำหรับเนื้อหาสำคัญ

ตัวอย่าง B — หน้า index อยู่ แต่ CTR ต่ำ: ตรวจ title/meta description, ดู SERP intent และพิจารณาเพิ่ม structured data ที่เกี่ยวข้องเพื่อช่วยให้หน้าปรากฏเป็น rich result หรือให้อ่านง่ายขึ้นใน AI Overviews; ทดสอบข้อความ CTA และความชัดเจนของ H1 เพื่อปรับ CTR

FAQ