เช็กลิสต์ Technical SEO: ตรวจอะไร ตรวจอย่างไร และแบบไหนถือว่าผ่าน

หน้าเว็บอาจดูสมบูรณ์แบบในเบราว์เซอร์ แต่ยังล่องหนสำหรับ Google ได้ แค่บรรทัดเดียวใน robots.txt แท็กที่หลงเหลือจากเว็บไซต์ staging หรือ redirect ที่วนลูป ก็พอแล้ว และไม่มีอะไรเลยที่เห็นได้ ตอนคุณคลิกไปมา เช็กลิสต์ Technical SEO นี้สร้างขึ้นมา เพื่อจับปัญหาเหล่านั้น

การเช็กแต่ละข้อ มาพร้อมเครื่องมือฟรีที่ใช้ทดสอบ และหน้าตาของการผ่าน โดยอ้างอิงจากเอกสารของ Google Search Central นี่คือชั้นเทคนิคของคู่มือเว็บไซต์ที่เป็นมิตรกับ SEO ของเรา

เช็กลิสต์ Technical SEO แบบสรุป

เครื่องมือฟรี 3 ตัว ทำงานส่วนใหญ่ให้: Google Search Console ที่ตั้งค่าเป็นพร็อพเพอร์ตี้แบบ Domain (ยืนยันผ่าน DNS) เพื่อให้ครอบคลุมทุกโดเมนย่อย ทั้ง http และ https ตัวที่สองคือ crawler บนเดสก์ท็อป อย่าง Screaming Frog SEO Spider ซึ่งเวอร์ชันฟรีเก็บข้อมูลได้สูงสุด 500 URL และตัวที่สามคือ เบราว์เซอร์ ของคุณ ที่มีฟีเจอร์ดูซอร์ส และเครื่องมือนักพัฒนา ชื่อรายงานถูกต้อง ณ เวลาที่เขียน (กันยายน 2026)

เสิร์ชเอนจินเก็บข้อมูลเว็บไซต์คุณได้ไหม?

robots.txt

ไฟล์ robots.txt ที่รูทของโดเมน บอก crawler ว่าห้ามดึง path ไหน บนเว็บไซต์ WordPress ทั่วไป ไฟล์ที่ดีจะสั้น:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://www.example.com/sitemap.xml

เวอร์ชันที่สร้างความเสียหายมากที่สุด คือ Disallow: / ใต้ User-agent: * ซึ่งหลงเหลือมาจาก staging และบล็อกทุกอย่าง และ robots.txt หยุดการเก็บข้อมูล ไม่ใช่การจัดทำดัชนี: URL ที่ถูกบล็อก ยังปรากฏในผลการค้นหาได้ โดยไม่มีคำอธิบาย

วิธีเช็ก เปิด yourdomain.com/robots.txt แล้วเปิดรายงาน robots.txt ในการตั้งค่าของ Search Console ซึ่งแสดงเวอร์ชันที่ Google ดึงไปล่าสุด และข้อผิดพลาดต่าง ๆ

แบบไหนถือว่าผ่าน บล็อกเฉพาะส่วนที่ไม่มีคุณค่าต่อการค้นหา เช่น หน้าผู้ดูแลระบบ และผลการค้นหาภายในเว็บไซต์ และไม่บล็อก CSS หรือ JavaScript ที่หน้าต้องใช้ในการเรนเดอร์ ไฟล์โหลดได้สม่ำเสมอ: Google ถือว่า robots.txt ที่ไม่มีอยู่ (404) คือ “ไม่มีข้อจำกัด” แต่ข้อผิดพลาดของเซิร์ฟเวอร์ อาจทำให้ Google หยุดเก็บข้อมูลทั้งเว็บไซต์ จนกว่าไฟล์จะโหลดได้อีกครั้ง

XML sitemap

sitemap ช่วยให้ Google ค้นพบหน้า แต่ไม่ได้บังคับให้อะไรเข้าไปในดัชนี

วิธีเช็ก ส่ง sitemap ในรายงาน Sitemaps ของ Search Console ยืนยันว่าสถานะเป็น Success แล้วใช้ crawler เก็บข้อมูล URL ในนั้นแบบเป็นรายการ

แบบไหนถือว่าผ่าน

• ทุก URL ส่งค่า 200 จัดทำดัชนีได้ และเป็นเวอร์ชัน canonical
• จำนวนใกล้เคียงกับหน้าที่คุณอยากให้ถูกค้นเจอ เว็บไซต์ 40 หน้า ที่มี URL ใน sitemap 900 รายการ น่าจะกำลังใส่หน้าคลังแท็ก หรือหน้าไฟล์แนบรูปภาพไว้ด้วย
• lastmod เปลี่ยนเฉพาะเมื่อเนื้อหาเปลี่ยน Google บอกว่าไม่สนใจ priority และ changefreq และใช้ lastmod เฉพาะเมื่อถูกต้องสม่ำเสมอ และตรวจสอบได้

ลิงก์ภายใน

Google ตามลิงก์ที่เขียนเป็น element <a> ที่มีที่อยู่ใน href “ลิงก์” ที่ทำงานผ่านตัวจัดการคลิกของ JavaScript เท่านั้น อาจไม่เคยถูกตามเลย

วิธีเช็ก เก็บข้อมูลเริ่มจากหน้าแรก แล้วเทียบผลกับ sitemap ของคุณ: URL ใน sitemap ที่การเก็บข้อมูลไปไม่ถึง คือหน้ากำพร้า (orphan pages)

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

หน้าของคุณจัดทำดัชนีได้ไหม?

กฎ noindex และ status code

กฎ noindex อยู่ในหน้าในรูป <meta name="robots" content="noindex"> หรืออยู่ใน HTTP header X-Robots-Tag ที่ไม่มีวันเห็นในซอร์สของหน้า อุบัติเหตุที่พบบ่อยคือ การตั้งค่าจาก staging ที่ติดมาตอนเปิดตัว ช่องติ๊กของ WordPress ที่ขอให้เครื่องมือค้นหาไม่ทำดัชนีเว็บไซต์ (Settings → Reading) ที่ยังติ๊กค้างไว้ หรือปลั๊กอิน SEO ที่ซ่อนเนื้อหาไปทั้งประเภท Google ต้องเก็บข้อมูลหน้าก่อน จึงจะเห็น noindex ดังนั้นอย่าบล็อกหน้านั้นใน robots.txt ไปพร้อมกัน

status code ต้องบอกความจริง: 200 สำหรับหน้าที่ใช้งานอยู่ 301 (หรือ 308) สำหรับการย้ายถาวร 404 หรือ 410 สำหรับหน้าที่ไม่มีแล้ว ระวัง soft 404 (หน้าที่บอกว่า “ไม่พบ” แต่ส่งค่า 200) และข้อผิดพลาดของเซิร์ฟเวอร์ที่เกิดซ้ำ ซึ่งทำให้ Google เก็บข้อมูลช้าลง

วิธีเช็ก URL Inspection ใน Search Console แสดงช่อง “Indexing allowed?” สำหรับ URL เดียว ส่วนคอลัมน์ indexability และ status code ใน crawler ครอบคลุมทั้งเว็บไซต์

แบบไหนถือว่าผ่าน หน้าที่ใช้งานอยู่ส่งค่า 200 และ noindex ปรากฏเฉพาะหน้าที่ไม่ควรอยู่ในการค้นหา เช่น หน้าขอบคุณ และหน้าล็อกอิน

รายงาน Page indexing

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

• มักไม่เป็นไร: “Page with redirect” (หน้าที่มีการเปลี่ยนเส้นทาง) หน้าสำรองที่มีแท็ก canonical ถูกต้อง “Not found (404)” สำหรับหน้าที่คุณลบออก และการยกเว้นด้วย noindex บนหน้าที่คุณตั้งใจซ่อน
• ควรตรวจสอบ: การบล็อกด้วย robots.txt บนหน้าที่คุณอยากให้ค้นเจอ หน้าซ้ำที่ Google เลือก canonical ต่างจากที่คุณระบุ “Soft 404” “Server error (5xx)” และ “Redirect error”
• ต้องใช้วิจารณญาณ: “Crawled – currently not indexed” (ดึงไปแล้วแต่ไม่จัดทำดัชนี โดยไม่บอกเหตุผล: ลองถามว่าหน้านี้เพิ่มอะไร ที่หน้าอื่นของคุณไม่มีไหม) และ “Discovered – currently not indexed” (รู้จักแล้ว แต่ยังไม่ได้เก็บข้อมูล)

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

แต่ละหน้ามีเวอร์ชันเดียวไหม?

สำหรับเสิร์ชเอนจิน http://example.com/services, https://www.example.com/services/ และที่อยู่เดียวกันที่มี ?utm_source=newsletter อาจเป็นสามหน้าแยกกัน หน้าซ้ำแบ่งสัญญาณ เช่น ลิงก์ ออกเป็นหลายส่วน และปล่อยให้ Google เลือกเอง

HTTPS และ www

วิธีเช็ก พิมพ์ทุกรูปแบบของหน้าด้านในหน้าหนึ่ง ลงในแถบที่อยู่ (มีและไม่มี www เป็น http หรือ https มีหรือไม่มีเครื่องหมาย / ปิดท้าย) แล้วใช้ crawler เก็บข้อมูลรายการนั้น เพื่อดู status code และจำนวนทอด

แบบไหนถือว่าผ่าน ทุกรูปแบบไปถึงเวอร์ชันที่ต้องการเพียงเวอร์ชันเดียว ผ่าน 301 เพียงครั้งเดียว ลิงก์ภายใน แท็ก canonical และ sitemap ใช้เวอร์ชันนั้นทั้งหมด และคอนโซลของเบราว์เซอร์ ไม่มีคำเตือน mixed content

แท็ก canonical

แท็ก canonical ระบุ URL ที่ต้องการของหน้า Google ถือว่าเป็นคำใบ้ที่มีน้ำหนัก ไม่ใช่คำสั่ง ดังนั้นแต่ละหน้าที่จัดทำดัชนีได้ ควรชี้มาที่ตัวเอง และสัญญาณอื่นทั้งหมดควรสอดคล้องกัน ข้อผิดพลาดที่ต้องตามหา:

• บั๊กในเทมเพลต ที่ทำให้ canonical ทุกหน้าชี้ไปที่หน้าแรก
• canonical ที่ชี้ไปยัง URL ที่ redirect ส่งค่า 404 มี noindex หรือยังใช้โดเมน staging
• หน้าที่แบ่งเป็นหลายหน้า (pagination) ตั้ง canonical ไปที่หน้า 1 Google แนะนำให้แต่ละหน้าในชุด มี canonical ของตัวเอง
• หน้าแปลที่ตั้ง canonical ไปที่ภาษาหลัก แทนที่จะชี้มาที่ตัวเอง และลิงก์ถึงกันด้วย hreflang (ดูคู่มือ SEO หลายภาษา)

วิธีเช็ก URL Inspection แสดง canonical ที่ผู้ใช้ระบุ (User-declared canonical) และ canonical ที่ Google เลือก (Google-selected canonical) ในทุกหน้าสำคัญ ทั้งสองค่าควรตรงกัน

พารามิเตอร์ใน URL

แท็กติดตาม การเรียงลำดับ และตัวกรอง (?sort=price) สร้าง URL ใหม่สำหรับเนื้อหาเดิม Google ปลดเครื่องมือ URL Parameters ของ Search Console ออกในปี 2022 การแก้จึงอยู่ที่ตัวเว็บไซต์: เวอร์ชันที่มีพารามิเตอร์ ควรตั้ง canonical ไปที่ URL ที่สะอาด และลิงก์ภายในไม่ควรมีแท็กติดตามเลย เพราะยังทำให้ข้อมูลวิเคราะห์ของคุณสับสนด้วย

ใช้บนมือถือได้และเรนเดอร์ถูกต้องไหม?

Mobile-first indexing

Google เก็บข้อมูลและจัดทำดัชนี ด้วย crawler สำหรับสมาร์ตโฟน ดังนั้นเวอร์ชันมือถือของแต่ละหน้า คือสิ่งที่นับ เว็บไซต์แบบ responsive ส่ง HTML เดียวกันให้ทุกหน้าจอ ความเสี่ยงอยู่ที่เทมเพลตมือถือแยก และดีไซน์ที่ตัดส่วน หัวข้อ หรือข้อมูลแบบมีโครงสร้างออกบนจอเล็ก Googlebot ไม่คลิก ไม่แตะ และไม่ปัด ดังนั้นเนื้อหาที่โหลดหลังการโต้ตอบเท่านั้น อาจถูกมองข้าม ส่วนข้อความที่อยู่ใน HTML แล้ว แต่ซ่อนอยู่ในแท็บหรือ accordion ไม่เป็นปัญหา

วิธีเช็ก Google ปลด Mobile-Friendly Test ไปในเดือนธันวาคม 2023 ให้ใช้ Lighthouse ในเครื่องมือนักพัฒนาของ Chrome มือถือของคุณเองบนเน็ตมือถือ และการทดสอบสดของ URL Inspection ซึ่งถ่ายภาพหน้าจอของหน้า ตามที่ Googlebot เรนเดอร์

แบบไหนถือว่าผ่าน ไม่มีอะไรที่คุณอยากให้ติดอันดับ ที่มีอยู่แค่บนเดสก์ท็อป

การเรนเดอร์ JavaScript

Google เรนเดอร์หน้าด้วย Chrome เวอร์ชันล่าสุด แม้ไม่ได้ทำทันทีหลังเก็บข้อมูลเสมอไป และไม่ใช่ทุก crawler ที่รัน JavaScript หน้าที่ส่งมาเป็น HTML ครบถ้วน อย่างหน้า WordPress มาตรฐาน หลีกเลี่ยงความเสี่ยงส่วนใหญ่ได้

วิธีเช็ก

1. เปิด View source ไม่ใช่ Inspect ถ้าหัวข้อ ข้อความ และลิงก์เมนูของคุณอยู่ในนั้น ความเสี่ยงด้านการเรนเดอร์ก็ต่ำ
2. ถ้าไม่อยู่ ให้รันการทดสอบสดใน URL Inspection แล้วเปิด View tested page: แท็บ HTML แสดงสิ่งที่ Google เรนเดอร์ และ “More info” แสดงไฟล์ที่ Google โหลดไม่ได้
3. ถ้าไม่มีสิทธิ์เข้า Search Console เครื่องมือ Rich Results Test ของ Google แสดง HTML ที่เรนเดอร์แล้ว สำหรับ URL สาธารณะใดก็ได้

แบบไหนถือว่าผ่าน HTML ที่เรนเดอร์แล้ว มีข้อความครบ มีลิงก์ <a href> จริง และมีชื่อหน้า canonical และแท็ก robots ที่ถูกต้อง และแต่ละหน้ามี URL ของตัวเอง ไม่ใช่ fragment แบบ #

ความเร็วและ Core Web Vitals

ความเร็วควรเป็นโปรเจกต์ของตัวเอง แต่ควรรู้เกณฑ์: Google ให้หน้าอยู่ในระดับดี เมื่อ LCP ไม่เกิน 2.5 วินาที INP ไม่เกิน 200 มิลลิวินาที และ CLS ไม่เกิน 0.1 ที่เปอร์เซ็นไทล์ที่ 75 ของการเข้าชมจริง บทความอธิบาย Core Web Vitals อธิบายค่าวัดแต่ละตัว และบทความด้านประสิทธิภาพ ลงลึกกว่านั้น

redirect และ 404 อยู่ในการควบคุมไหม?

redirect ต่อกันหลายทอดและวนลูป

redirect chain คือ A redirect ไป B แล้ว B redirect ไป C chain ค่อย ๆ สะสมขึ้นโดยไม่มีใครสังเกต จากการย้ายไป HTTPS การปรับโครงสร้าง และการเปลี่ยนชื่อหน้า และแต่ละทอด ทำให้ผู้เข้าชมช้าลง Googlebot ตามได้สูงสุด 10 ทอด แต่ Google แนะนำให้ redirect ตรงไปที่หน้าปลายทางเลย

วิธีเช็ก รายงาน redirect ใน crawler แสดงรายการ chain และลูป ส่วนที่ Google ยอมแพ้ จะปรากฏในรายงาน Page indexing เป็น “Redirect error”

แบบไหนถือว่าผ่าน ทุก redirect ไปถึงหน้าปลายทางในทอดเดียว และลิงก์ภายในชี้ตรงไปที่ URL ปลายทาง สำหรับการรีดีไซน์และการเปลี่ยนโดเมน เช็กลิสต์ SEO สำหรับการย้ายเว็บไซต์ อธิบายการวางแผน redirect

หน้าที่ถูกลบและลิงก์เสีย

redirect หน้าที่ถูกลบไปยังหน้าที่ใกล้เคียงที่สุด หรือปล่อยให้ส่งค่า 404 หรือ 410 ถ้าไม่มีหน้าที่ใกล้เคียง การส่งทุก URL ที่หายไปไปที่หน้าแรก ดูเรียบร้อย แต่ทำให้ผู้เข้าชมสับสน และ Google บอกว่าอาจถือ redirect เหล่านั้นเป็น soft 404

วิธีเช็ก กรองผลการเก็บข้อมูล หาการตอบกลับแบบ 4xx แล้วดูว่าหน้าไหนลิงก์ไปหา

แบบไหนถือว่าผ่าน ไม่มีลิงก์ภายในไปยังหน้าที่หายไป และมีหน้า 404 แบบกำหนดเองที่มีประโยชน์ ซึ่งส่ง status 404 จริง

แก้อะไรก่อน

1. ตัวบล็อก: แก้วันนี้ noindex ทั้งเว็บไซต์ หรือ Disallow: / ข้อผิดพลาดของเซิร์ฟเวอร์กับ robots.txt ข้อผิดพลาดของใบรับรอง HTTPS หน้าสำคัญที่ส่งค่าข้อผิดพลาด และเนื้อหาหลักที่หายไปจาก HTML ที่เรนเดอร์แล้ว
2. จุดรั่ว: แก้ภายในเดือนนี้ เวอร์ชันซ้ำที่ไม่ redirect canonical ที่ Google ไม่ทำตาม redirect chain หน้าบริการที่ไม่มีลิงก์ถึง soft 404 และเนื้อหาที่หายไปบนมือถือ
3. สุขอนามัย: แก้เป็นส่วนหนึ่งของการดูแลประจำ sitemap ที่รก ลิงก์ไปหน้าที่ลบแล้ว หน้าซ้ำจากพารามิเตอร์ Core Web Vitals ที่อยู่ในระดับ “ต้องปรับปรุง” และคำเตือนของข้อมูลแบบมีโครงสร้าง (Schema markup สำหรับเว็บไซต์ธุรกิจ แสดงประเภทที่ควรเพิ่ม)

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

ทำอะไรต่อ

เริ่มจากตัวบล็อก: เปิด robots.txt ของคุณ ตรวจหน้าแรกและหน้าบริการหลักด้วย URL Inspection และอ่านทุกเหตุผลในรายงาน Page indexing

กำลังวางแผนเว็บไซต์ใหม่ หรือรีดีไซน์? เช็กลิสต์นี้ส่วนใหญ่ควรผ่านตั้งแต่วันเปิดตัว และการทำไว้ตั้งแต่แรก ถูกกว่าการมาแก้ทีหลังมาก: เอาการบล็อกการค้นหาออก sitemap ที่สะอาด canonical ที่ชี้มาที่ตัวเอง เนื้อหาครบบนมือถือและใน HTML และ URL เก่าที่ redirect ในทอดเดียว บทความการออกแบบเว็บไซต์รวม SEO ไหม? อธิบายว่างานสร้างเว็บไซต์จบตรงไหน เช็กลิสต์ก่อนเปิดตัวเว็บไซต์ เรียงลำดับการเช็กก่อนขึ้นระบบ โปรเจกต์ออกแบบและพัฒนาเว็บไซต์ ของเรารวมโครงสร้างหน้าที่สะอาด XML sitemap และการตั้งค่า Search Console และทุกงานรีดีไซน์เว็บไซต์ จะ redirect URL เก่าทุกรายการ

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