การตรวจสอบ SEO: ผมตรวจสอบเว็บไซต์ทีละขั้นตอนอย่างไร

SEO Audit คือการตัดสินใจว่าจะแก้อะไรบนเว็บไซต์ก่อน โดยมีหลักฐานกำกับทุกข้อเสนอแนะ และมีวิธีตรวจสอบหลังนำไปใช้ รายการข้อผิดพลาดจากเครื่องมือเป็นเพียงวัตถุดิบของการตรวจสอบ ส่วนการตรวจสอบทางเทคนิคคือส่วนที่ตรวจว่าบอตของเสิร์ชเอนจินและผู้ช่วย AI ดึงและอ่านหน้าเว็บได้หรือไม่ และเสิร์ชเอนจินจัดทำดัชนีได้หรือไม่

ผมตรวจสอบในแปดขั้นตอน:

1. กำหนดเป้าหมายและสถานการณ์ของเว็บไซต์ ก่อนเปิดครอว์เลอร์ (crawler) คือโปรแกรมที่เดินผ่านเว็บไซต์เหมือนบอตของเสิร์ชเอนจิน
2. ตรวจว่าบอตเข้าถึงหน้าเว็บได้จริงหรือไม่
3. รวบรวมข้อมูลจากหลายแหล่ง และตรวจว่าแต่ละแหล่งมองไม่เห็นอะไร
4. ศึกษาคำค้นหาและผลการค้นหาของ Google ก่อนลงมือกับเรื่องเทคนิค
5. ตรวจเว็บไซต์ตามแคตตาล็อกปัญหาที่มีเงื่อนไขกำหนดลำดับความสำคัญ
6. แสดงหลักฐานในทุกประเด็น
7. กำหนดลำดับ ปริมาณงาน และตัวเลือก
8. ส่งผลเข้าสู่การตรวจไขว้ และหลังนำไปใช้ ตรวจทุกประเด็น

SEO Audit คืออะไร และการตรวจสอบทางเทคนิคต่างกันอย่างไร?

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

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

จะทำ SEO Audit ทีละขั้นตอนอย่างไร?

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

ขั้นตอนที่ 1. เป้าหมายและสถานการณ์ของเว็บไซต์ ก่อนเปิดครอว์เลอร์

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

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

ขั้นตอนนี้ต้องทำเอง แม้ผู้เชี่ยวชาญหลายคนในวันนี้ส่งให้โมเดลภาษา โมเดลภาษาช่วยได้ แต่ไม่เข้าใจธุรกิจของลูกค้า และไม่ให้มุมมองที่สร้างสรรค์และเฉพาะตัวแบบที่ผู้เชี่ยวชาญ SEOที่มีประสบการณ์มี

ขั้นตอนที่ 2. บอตเข้าถึงหน้าเว็บได้จริงหรือไม่

ก่อนอ่านตัวเลขใดจากเครื่องมือ ผมตรวจว่าเซิร์ฟเวอร์ยอมให้บอตเข้าหรือไม่ เพราะบอตที่ถูกบล็อกให้ข้อมูลที่ดูเหมือนปัญหา SEO ในสัปดาห์หนึ่งของเดือนกรกฎาคม 2026 “ปัญหา SEO” สามข้อในสามเว็บไซต์ที่ต่างกันกลายเป็นการบล็อกบอต:

1. เว็บไซต์หนึ่ง “เสีย” ลิงก์กว่า 2,200 ลิงก์ เพราะหน้าที่ลิงก์มาอยู่หลังไฟร์วอลล์ที่ปฏิเสธบอตของเครื่องมือวิเคราะห์ลิงก์
2. ร้านค้าหนึ่งมีคะแนนสุขภาพเว็บไซต์ในเครื่องมือเป็น 0 กับข้อผิดพลาดเกือบ 42,000 รายการ เพราะแทนที่จะได้หน้าเว็บ บอตของเครื่องมือได้รับคำตอบของไฟร์วอลล์ Cloudflare
3. ในเว็บไซต์ที่สาม การบล็อกหยุดครอว์เลอร์ไว้ที่ URL แรก และสามสัปดาห์ไม่มีใครสังเกต

ผมดึง URL เดียวกันในฐานะเบราว์เซอร์ธรรมดา และในฐานะบอตของ Google, Bing, OpenAI, Perplexity และ Anthropic แล้วเทียบรหัสตอบกลับและขนาดหน้า ความต่างระหว่างเบราว์เซอร์กับบอตเป็นสิ่งแรกที่ต้องอธิบายก่อนจะนับอะไร การทดสอบแบบนี้ส่งคำขอจาก IP ของผมโดยใช้ชื่อบอต และไฟร์วอลล์จำบอตจริงของ Google และ Bing ได้จาก IP ที่ส่งมา ดังนั้นการที่ “Googlebot” ถูกบล็อกในการทดสอบไม่ได้พิสูจน์ว่า Googlebot ตัวจริงถูกบล็อก Search Console แผงควบคุมฟรีของ Google สำหรับเจ้าของเว็บไซต์ แสดงว่า Googlebot ตัวจริงเห็นเว็บไซต์อย่างไร

ไฟล์ robots.txt ผมอ่านจนจบด้วยพาร์เซอร์ คือโปรแกรมที่ใช้กฎแบบเดียวกับบอต ไม่ใช่ด้วยตา บอตของ Google ใช้กลุ่มกฎเพียงกลุ่มเดียว คือกลุ่มที่ชื่อบอตตรงที่สุด และข้ามกลุ่มอื่น กฎ Disallow: ที่ไม่มีเส้นทางไม่บล็อกอะไร (Google Search Central) ในเดือนสิงหาคม 2026 จากส่วนของ robots.txt ของเว็บไซต์หนึ่ง ดูเหมือนว่าเว็บไซต์บล็อก Google พาร์เซอร์แสดงว่า Googlebot เข้าถึงได้เต็มที่ ส่วนบอตของ Bing และผู้ช่วย AI ถูกบล็อก การวินิจฉัยจึงต่างไป: ปัญหาอยู่ที่ Bing และบอต AI ไม่ใช่ Google

ไม่มีไฟล์ robots.txt ไม่ได้บล็อก Google แต่หลังการนำไปใช้ทุกครั้ง ผมตรวจว่าไฟล์ไม่หายไป Google ถือข้อผิดพลาด 4xx ของ robots.txt (ยกเว้น 429) เหมือนไม่มีไฟล์ คือไม่มีข้อจำกัด (Google Search Central) เว็บไซต์ของผมส่งข้อผิดพลาด 404 ที่ robots.txt ในเดือนสิงหาคม 2026 ก่อนที่ผมจะแก้

ขั้นตอนที่ 3. ข้อมูลจากหลายแหล่ง และสิ่งที่แต่ละแหล่งมองไม่เห็น

ตัวเลขจากครอว์เลอร์ทุกตัวเป็นสมมติฐาน จนกว่าแหล่งที่สองจะยืนยัน ผมเก็บข้อมูลครอว์ลทั้งแบบรันและไม่รัน JavaScript กับข้อมูลความเร็วจากผู้ใช้จริงในรายงาน CrUX เพิ่มโปรไฟล์ลิงก์และผลการค้นหาของ Google สำหรับคำค้นหาสำคัญในวันที่วัด ในบทความเรื่องlink building ผมอธิบายว่าตรวจโปรไฟล์ลิงก์อย่างไรก่อนวางแผนแคมเปญ ในทุกไฟล์ผมบันทึกแหล่งที่มา วันที่ และขอบเขต เพื่อให้หนึ่งเดือนต่อมายังสร้างตัวเลขทุกตัวขึ้นใหม่ได้

ข้อมูลจาก Search Console ผมดึงผ่าน API คือส่วนต่อประสานสำหรับดึงข้อมูลอัตโนมัติ เพราะการส่งออกจากแผงควบคุมตัดรายการไว้ที่ 1,000 แถว API ให้ได้ถึง 50,000 แถวต่อวันต่อประเภทผลลัพธ์แต่ละประเภท เช่นแยกผลของหน้าเว็บ รูปภาพ และวิดีโอ (Google, Search Console Help) ในบทความเรื่องเครื่องมือ AI ใน SEO ผมแสดงว่าการส่งออกที่ถูกตัดทำให้ CTR ของเว็บไซต์หนึ่งสูงเกินจริงอย่างไร

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

การเปลี่ยนแปลงกะทันหันในข้อมูลรายวัน ผมอธิบายก่อนจะกำหนดสาเหตุ ผมทำกับคลิก การแสดงผล อันดับ เซสชัน และคำขอของบอต Google ผมหาวันที่ค่ามัธยฐานเจ็ดวันติดกันต่างจากค่ามัธยฐานสิบสี่วันก่อนหน้าอย่างน้อย 25% ในทุกวันที่แบบนี้ ผมบันทึกคำอธิบาย: การนำไปใช้ การอัปเดตของ Google ความขัดข้อง การเปลี่ยนการวัด หรือ “ไม่ทราบสาเหตุ” การอธิบายวันที่ให้สมมติฐาน และผมระบุสาเหตุหลังตรวจคำอธิบายอื่นที่เป็นไปได้แล้วเท่านั้น

ขั้นตอนที่ 4. คำค้นหาและผลการค้นหาของ Google ก่อนเรื่องเทคนิค

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

การไม่มีหน้าสำหรับคำค้นหาสำคัญเป็นหนึ่งในปัญหาที่พบบ่อยในการตรวจสอบของผม: 15 จาก 63 การตรวจสอบ ใน 14 จาก 50 เว็บไซต์ ครอว์เลอร์ไม่รายงานเอง เพราะดึงเฉพาะหน้าที่มีอยู่ เห็นได้เมื่อผมเทียบความต้องการค้นหากับรายการ URL และกับหน้าของคู่แข่งที่ปรากฏในผลการค้นหา

ขั้นตอนที่ 5. ตรวจตามแคตตาล็อกที่มีเงื่อนไขกำหนดลำดับความสำคัญ

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

ปัญหาแต่ละประเภทในแคตตาล็อกมีกฎการตรวจพบ เงื่อนไขการรายงาน หลักฐานที่ต้องมี ลำดับความสำคัญพร้อมเงื่อนไข และวิธีตรวจสอบหลังนำไปใช้ จาก 256 ประเภท 86 ประเภทเริ่มกฎลำดับความสำคัญด้วย “สูง” แต่เกือบทุกครั้งมีเงื่อนไข: เมื่อคำค้นหามีความต้องการ เมื่อหน้ามีทราฟฟิก เมื่อข้อผิดพลาดอยู่ในเทมเพลต

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

ขั้นตอนที่ 6. หลักฐานในทุกประเด็น

ประเด็นที่ไม่มีหลักฐานอยู่ในการตรวจสอบเป็น “ต้องตรวจสอบ” ไม่ใช่ข้อเสนอแนะ หลักฐานคือภาพหน้าจอตำแหน่งในโค้ด หรือ HTML จากเซิร์ฟเวอร์เทียบกับเวอร์ชันหลังรัน JavaScript หรืออาจเป็นกราฟจาก Search Console หรือการวัดความเร็วที่ระบุชื่อองค์ประกอบที่ทำให้ช้า องค์ประกอบที่ทำให้การโหลดแย่ลงหรือทำให้เลย์เอาต์ขยับ ผมเรียกตามที่การวัดชี้ ไม่ใช่ตามที่เข้ากับสมมติฐานของผม

ผมอธิบายแต่ละประเด็นในสี่ส่วน ตั้งแต่ปัญหาจนถึงการตรวจสอบการแก้ไข ผมเขียนว่าปัญหาคืออะไร ทำไมจึงเสียหายและกระทบอะไร จะแก้ทีละขั้นอย่างไร และเราจะตรวจอย่างไรว่าการแก้ได้ผล โค้ดที่ต้องแก้ผมคัดลอกจากเว็บไซต์ตามตัวอักษร เพื่อให้โปรแกรมเมอร์เห็นตำแหน่งที่ต้องเปลี่ยนตรง ๆ

ตัวอย่างสั้น ๆ ของรายงานหนึ่งรายการเรื่องลิงก์ไปยังการรีไดเรกต์:

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

ขั้นตอนที่ 7. ลำดับ ปริมาณงาน และตัวเลือก

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

การนำไปใช้ทำตามการตรวจสอบทุกประการ ถ้าตอนประเมินราคาการนำไปใช้มีตัวเลือกที่ถูกกว่า ลูกค้าเป็นผู้เลือกและผมบันทึกไว้ตรง ๆ ไม่แอบเปลี่ยนข้อเสนอแนะโดยที่เขาไม่รู้

ขั้นตอนที่ 8. การตรวจไขว้และการตรวจสอบหลังนำไปใช้

ก่อนรายงานการตรวจสอบถึงมือลูกค้า ต้องให้คนที่ไม่ได้เขียนตรวจทาน ผมทำสองรอบ: รอบแรกทั้งเอกสาร รอบที่สองเฉพาะส่วนที่เปลี่ยนหลังรอบแรก การตรวจคำนวณตัวเลขใหม่ตั้งแต่ต้น และหาข้อสรุปที่ปกป้องด้วยหลักฐานไม่ได้ ท้ายที่สุดผมตรวจเองเรื่องลำดับความสำคัญและข้อสรุปที่ขึ้นกับสถานการณ์ของลูกค้า

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

ผมตรวจอะไรในการตรวจสอบทางเทคนิค?

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

ปัญหาที่รายงานไม่บ่อยไม่จำเป็นต้องเกิดไม่บ่อย ความเร็วและ JavaScript มีรายงานน้อยในตารางนี้ แต่การตรวจสอบในคลังมีขอบเขตต่างกัน จำนวนรายงานที่ต่ำจึงไม่บอกว่าปัญหาเหล่านี้พบบ่อยแค่ไหนในเว็บไซต์

ผมตรวจการจัดทำดัชนีของเว็บไซต์อย่างไร?

ผมตรวจการจัดทำดัชนีบนสามรายการ: อะไรอยู่ในไซต์แมป อะไรที่ Google จัดทำดัชนีแล้ว และอะไรที่ครอว์เลอร์พบผ่านลิงก์ ความไม่ตรงกันระหว่างสามรายการนี้แสดงปัญหาได้ดีกว่าแต่ละรายการแยกกัน ไซต์แมปที่มี URL ซึ่งส่งการรีไดเรกต์ ข้อผิดพลาด หรือถูกกันออกจากดัชนี ถูกรายงานใน 20 จาก 63 การตรวจสอบ ใน 18 จาก 50 เว็บไซต์ สำหรับ URL เดี่ยว ผมใช้การตรวจสอบ URL ใน Search Console ซึ่งแสดงหน้าหลังรัน JavaScript ด้วย

Core Web Vitals มีผลต่ออันดับหรือไม่?

Core Web Vitals เป็นส่วนหนึ่งของระบบจัดอันดับของ Google แต่ไม่ชนะความเกี่ยวข้องของเนื้อหา Google เขียนตรง ๆ ว่าระบบจัดอันดับใช้ Core Web Vitals และเขียนด้วยว่าพยายามแสดงเนื้อหาที่เกี่ยวข้องที่สุดเสมอ แม้ประสบการณ์บนหน้าเว็บจะไม่ดี (Google Search Central) ในการตรวจสอบ ผมใช้ข้อมูลจากผู้ใช้จริงในรายงาน CrUX ไม่ใช่การทดสอบครั้งเดียวในเครื่องมือห้องปฏิบัติการ ในที่ที่ Google มีข้อมูลแบบนี้แยกตามประเภทหน้า ผมแสดงแยก ส่วนที่ข้อมูลขาด ผมอธิบายไว้ในการตรวจสอบ ตั้งแต่วันที่ 12 มีนาคม 2024 ตัววัดการตอบสนองของหน้าคือ INP ซึ่งแทนที่ FID (web.dev)

ข้อผิดพลาดอะไรที่ผมพบบ่อยที่สุดใน SEO Audit?

ที่ซ้ำบ่อยที่สุดคือข้อผิดพลาดเชิงระเบียบ คือแบบที่เครื่องมือตรวจพบง่าย: ลิงก์ไปยังการรีไดเรกต์และข้อผิดพลาด 404 ไซต์แมปที่มี URL ผิด และชื่อกับคำอธิบายหน้าที่ซ้ำกัน ลิงก์ภายในไปยัง URL ที่ถูกรีไดเรกต์ปรากฏใน 24 จาก 63 การตรวจสอบ ใน 20 จาก 50 เว็บไซต์ เครื่องมือตรวจพบได้ดี และต้นทุนการแก้ขึ้นกับเทมเพลตและระบบของเว็บไซต์

ปัญหาโครงสร้างที่รายงานน้อยกว่าอาจกระทบทราฟฟิกมากกว่าข้อผิดพลาดเชิงระเบียบ การไม่มีหน้าสำหรับคำค้นหาสำคัญถูกรายงานใน 15 จาก 63 การตรวจสอบ และบล็อกที่ไม่ลิงก์ไปหน้าบริการและหมวดหมู่ก็จำนวนเท่ากัน แคตตาล็อกให้หน้าที่ขาดลำดับความสำคัญสูงเมื่อคำค้นหามีความต้องการและคู่แข่งครองอันดับด้วยหน้าแยกกัน บล็อกที่ไม่มีลิงก์ได้ลำดับสูงเมื่อหน้าปลายทางมีทราฟฟิกหรือรายได้ และบล็อกมีความน่าเชื่อถือ เงื่อนไขเหล่านี้ผมตรวจกับข้อมูลก่อนกำหนดลำดับ

• 938ข้อค้นพบใน 63 การตรวจสอบใน 50 เว็บไซต์ ซึ่งผมสร้างแคตตาล็อก 256 ประเภทปัญหาคลังการตรวจสอบ 2020-2026 แคตตาล็อก ณ วันที่ 11 ตุลาคม 2026
• 38%ของการตรวจสอบมีลิงก์ภายในไปยัง URL ที่ถูกรีไดเรกต์ ซึ่งเป็นปัญหาที่รายงานบ่อยที่สุดในคลัง (24 จาก 63)แคตตาล็อก ณ วันที่ 11 ตุลาคม 2026
• 15 จาก 63การตรวจสอบที่ไม่มีหน้าสำหรับคำค้นหาสำคัญ ซึ่งครอว์เลอร์ไม่รายงานเองแคตตาล็อก ณ วันที่ 11 ตุลาคม 2026
• 14ประเภทคำแนะนำที่แคตตาล็อกทำเครื่องหมายว่าล้าสมัยในปัจจุบัน และอีก 30 ประเภทว่าเป็นแนวปฏิบัติที่เปลี่ยนไปแคตตาล็อก ณ วันที่ 11 ตุลาคม 2026

SEO Audit เปลี่ยนไปอย่างไรตั้งแต่ปี 2020?

ในการตรวจสอบปี 2023-2026 ข้อมูลที่มีโครงสร้างและการแบ่งหน้าปรากฏบ่อยกว่าในปี 2020-2022 ส่วนการรีไดเรกต์ URL แบบ canonical และการจัดทำดัชนีปรากฏน้อยลง ปัญหาข้อมูลที่มีโครงสร้างถูกรายงานใน 23 จาก 33 การตรวจสอบที่ใหม่กว่า เทียบกับ 16 จาก 30 ฉบับเก่า การรีไดเรกต์และรหัสตอบกลับ: 23 จาก 33 เทียบกับ 27 จาก 30 การบล็อกบอต AI ปรากฏเฉพาะในการตรวจสอบปี 2026 ปีของการตรวจสอบคือวันที่ของไฟล์ในคลัง จึงไม่ใช่ปีที่ทำงานเสมอไป

การลดลงไม่ได้พิสูจน์ว่าปัญหาการรีไดเรกต์หายไป องค์ประกอบของการตรวจสอบเปลี่ยน: ฉบับใหม่กว่าเกี่ยวกับข้อมูลที่มีโครงสร้าง เนื้อหา และการมองเห็นใน AI บ่อยขึ้น และวิธีทำงานก็เปลี่ยน จากกราฟนี้รู้ได้ว่าการตรวจสอบเกี่ยวกับอะไร ไม่ใช่ว่าเว็บไซต์ในโปแลนด์เปลี่ยนไปอย่างไร

คำแนะนำ SEO อะไรที่ล้าสมัยในปัจจุบัน?

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

แหล่งที่มาของตาราง: Google เรื่องการแบ่งหน้า, Google เรื่องข้อผิดพลาดห้าข้อกับ rel=canonical, Google เรื่องผลลัพธ์ FAQ และ HowTo, Matt Cutts เรื่อง nofollow และการแบ่งพลังของลิงก์, John Mueller เรื่องการรีไดเรกต์ไปหน้าแรก จาก Search Engine Roundtable, Google เรื่อง robots.txt, Google เรื่องกฎที่ไม่รองรับใน robots.txt, Google เรื่องไซต์แมป, Google เรื่องฟิลด์ lastmod, changefreq และ priority, web.dev เรื่อง INP, Google เรื่องช่องค้นหาในผลลัพธ์

ด้วยเหตุนี้ ทุกคำแนะนำในแคตตาล็อกของผมจึงมีช่องสถานะความเป็นปัจจุบันพร้อมเหตุผล ปัจจุบันแคตตาล็อกทำเครื่องหมาย 14 ประเภทคำแนะนำว่าล้าสมัย และ 30 ประเภทว่าเป็นแนวปฏิบัติที่เปลี่ยนไป คำแนะนำที่ถูกต้องเมื่อไม่กี่ปีก่อนจะไม่เข้าสู่การตรวจสอบเพียงเพราะเคยได้ผล

จะตรวจการเข้าถึงของบอต AI ในการตรวจสอบได้อย่างไร?

ผมตรวจการเข้าถึงของบอต AI ในขั้นตอนเดียวกับการเข้าถึงของ Googlebot เพราะการตั้งค่าไฟร์วอลล์หรือ CDN เดียวกันบล็อกได้ทั้งสอง CDN คือเครือข่ายเซิร์ฟเวอร์ตัวกลาง เช่น Cloudflare ในเดือนกันยายน 2026 ผมตรวจ 12 โดเมนของลูกค้าที่ทำงานอยู่หลัง Cloudflare จากไฟล์ robots.txt เพียงอย่างเดียวพบว่า:

• 3 โดเมนบล็อกบอตชุดเดียวกันเจ็ดตัวที่เก็บข้อมูลสำหรับเทรนโมเดล ด้วยรายชื่อที่เหมือนกัน รายชื่อที่เหมือนกันบ่งว่ามีแหล่งร่วม เช่นการตั้งค่าสำเร็จรูปในแผงควบคุม Cloudflare จากภายนอกมองไม่เห็นการตั้งค่านี้ จึงต้องยืนยันในแผงควบคุมเอง
• 1 โดเมนบล็อกบอตที่ดึงหน้าเว็บเพื่อตอบใน ChatGPT, Perplexity และ Claude ไม่ได้ทำตรง ๆ แต่ใช้กฎทั่วไปสำหรับบอตทั้งหมดที่ไม่ได้ระบุชื่อ โดเมนเดียวกันยังแสดงหน้าป้องกันให้ GPTBot โดยไม่มีแท็ก noindex ที่กันหน้าออกจากดัชนี ถ้าบอตจัดทำดัชนีได้หน้านั้น หน้าบล็อกอาจเข้าไปอยู่ในดัชนีแทนเนื้อหา
• 8 โดเมนไม่มีการบล็อกใน robots.txt

คุณตัดสินใจแยกกันได้ว่าจะให้บอตที่ดึงหน้าเว็บเพื่อตอบและบอตที่เก็บข้อมูลสำหรับเทรนเข้าถึงเว็บไซต์หรือไม่ ในบทความเรื่องAI SEO และ GEO ผมอธิบายวิธีแยกสองแบบ ตั้งแต่วันที่ 31 สิงหาคม 2026 ยังมีการตั้งค่าแยกใน Search Console ที่กันเว็บไซต์ออกจาก AI Overview, AI Mode และฟีเจอร์ Generative AI ใน Discover ตามที่ Google ระบุ ไม่กระทบผลการค้นหาส่วนที่เหลือ (Search Console Help) ผมตรวจการตั้งค่าแบบนี้ในการตรวจสอบเหมือน robots.txt เพราะอาจมีคนเปิดโดยที่ผู้รับผิดชอบ SEO ไม่ทราบ ส่วนว่าหลังเปิดการเข้าถึงแล้วแบรนด์ปรากฏในคำตอบหรือไม่ เป็นการวัดอีกอย่าง ซึ่งผมอธิบายไว้ในบทความเรื่องการมองเห็นของแบรนด์ใน AI

การทดสอบจาก IP เดียวแสดงเพียงส่วนหนึ่งของสถานการณ์ และเองก็ให้สัญญาณเตือนผิดได้ ในการตรวจครั้งเดียวกัน ชุดคำขอรายงานการบล็อกหลังเกินขีดจำกัดใน 2 โดเมน การบล็อกนั้นเกิดจากคำขอก่อนหน้าของผมเอง การตรวจอีกครั้งหลังไม่กี่นาที ด้วยตัวระบุบอตเดียวและคำขอเดี่ยว ได้คำตอบที่ถูกต้องห้าและเจ็ดครั้งติดกัน ถ้าไม่มีการตรวจนั้น ลูกค้าสองรายจะได้ข้อมูลเรื่องการบล็อกที่ไม่เคยมี มีแต่ล็อกของเซิร์ฟเวอร์ที่แสดงว่า ChatGPT ดึงหน้าเว็บจริงหรือไม่ ในบทความเรื่องไฟล์ llms.txt ผมแสดงสิ่งที่เห็นในล็อกของเว็บไซต์ผม

รหัส 200 ไม่ได้แปลว่าบอตได้เนื้อหา ลูกค้ารายหนึ่งที่ใช้แอปแบบ JavaScript Googlebot และ Bingbot ได้ HTML สำเร็จรูปจากบริการเรนเดอร์ล่วงหน้า แต่บอตของผู้ช่วย AI ได้หน้าว่าง บริการจำบอตจากชื่อและไม่มีบอต AI ในรายการ การทดสอบของผมให้ผล “ปกติ” เพราะวัดรหัสตอบกลับ ไม่ได้วัดเนื้อหา ตั้งแต่นั้น ผมเทียบเนื้อหาที่บอตได้กับเนื้อหาหลังรัน JavaScript ในเบราว์เซอร์

SEO Audit ฟรีพอไหม?

เครื่องมือฟรีแสดงรายการข้อผิดพลาด แต่จากรายงานอย่างเดียวไม่รู้ว่าข้อไหนทำให้คุณเสียทราฟฟิก สำหรับคำค้นหา “audyt seo” (การตรวจสอบ SEO ในภาษาโปแลนด์) 7 จาก 9 ผลลัพธ์แบบออร์แกนิกในหน้าแรกของ Google เป็นเครื่องมือหรือข้อเสนอการตรวจสอบฟรี (ผลวันที่ 17 ตุลาคม 2026) รายงานแบบนั้นนับข้อผิดพลาดตามกฎของเครื่องมือ ไม่ใช่ตามจำนวนทราฟฟิกและรายได้ที่ขึ้นกับข้อผิดพลาดนั้น ต้องตรวจด้วยว่าผลไม่ได้มาจากการบล็อกบอต เหมือนกรณีของร้านค้าที่มีคะแนนสุขภาพเว็บไซต์ 0

คุณทำได้มากโดยไม่เสียเงิน ถ้ารู้ว่าต้องดูที่ไหน Search Console แสดงข้อมูลของ Google เรื่องการจัดทำดัชนี Core Web Vitals และหน้าหลังรัน JavaScript Screaming Frog เวอร์ชันฟรีเดินได้ถึง 500 URL ในหนึ่งครอว์ล (Screaming Frog) ซึ่งพอสำหรับเว็บไซต์บริษัทขนาดเล็ก การตรวจสอบกับที่ปรึกษาสมเหตุสมผลเมื่อข้อผิดพลาดมีราคาสูง (การย้ายเว็บไซต์ ทราฟฟิกตก ร้านค้าขนาดใหญ่) หรือเมื่อคุณไม่มีเวลาเรียบเรียงและประเมินข้อมูล

ChatGPT ทำ SEO Audit ให้ได้ไหม?

ChatGPT และโมเดล AI อื่นทำการตรวจสอบเต็มรูปแบบเองไม่ได้ เพราะมองไม่เห็นเว็บไซต์แบบที่บอตของเสิร์ชเอนจินเห็น ปกติมันเห็นผ่านเครื่องมือที่ดึงหน้าแล้วแปลงเป็นข้อความ โมเดลอ่านข้อมูลที่คุณให้และเสนอสิ่งที่ควรตรวจ แต่เครื่องมือดึงข้อมูลทำให้ส่วนหนึ่งของหน้าหายได้: ในเดือนกันยายน 2026 ผมตรวจพบว่าเครื่องมือดึงหน้าเว็บใน Claude Code ตัดข้อมูลที่มีโครงสร้างออกเมื่อแปลงหน้าเป็นข้อความ โมเดลตอบว่าไม่มีข้อมูลนั้น ทั้งที่อยู่ในมาร์กอัปของหน้าเดียวกัน การตรวจสอบแบบนี้จะรายงานว่าไม่มีข้อมูลที่มีโครงสร้างซึ่งความจริงไม่ได้ขาด ในกระบวนการของผม AI เป็นเครื่องมือ โดยหลักเพื่อรวบรวมข้อมูลจากครอว์ล Search Console และแหล่งอื่น ขอบเขต การประเมิน และลำดับความสำคัญ ผมกำหนดเอง

SEO Audit ราคาเท่าไร?

ผมคิดค่าตรวจสอบเหมือนการปรึกษา: 70 EUR ต่อชั่วโมงไม่รวมภาษี โดยกำหนดเพดานชั่วโมงก่อนเริ่ม จำนวนชั่วโมงขึ้นกับสิ่งที่ต้องตรวจ:

• การตรวจสอบเชิงวินิจฉัย คือปัญหาที่เจาะจงหนึ่งหรือสองข้อ (ทราฟฟิกตก การย้ายเว็บไซต์ การจัดทำดัชนี) ปกติ 10-16 ชั่วโมง คือ 700-1,120 EUR ไม่รวมภาษี;
• การตรวจสอบเต็มพร้อมลำดับการลงมือ ปกติ 32-50 ชั่วโมง คือ 2,240-3,500 EUR ไม่รวมภาษี;
• เว็บไซต์เล็กไม่เกิน 500 URL ใกล้ขอบล่าง และร้านค้าที่มีหลายพัน URL และตัวกรองใกล้ขอบบน;
• เวอร์ชันภาษาเพิ่มปกติ 3-5 ชั่วโมง และวิกฤตที่กำลังเกิดซึ่งต้องวินิจฉัยเพิ่ม 4-8 ชั่วโมง

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

ถ้าไม่มีสิทธิ์เข้าถึง Search Console แผงควบคุม CDN และโฮสติ้ง ผมตรวจส่วนเทคนิคได้ไม่เต็มที่ และบอกก่อนประเมินราคา ผมจะระบุสิ่งที่ตรวจไม่ได้หากไม่มีสิทธิ์เหล่านั้น และลดขอบเขตตามนั้น ในบทความเรื่องการปรึกษา SEO ผมอธิบายว่าเมื่อไรการพูดคุยเรื่องการตัดสินใจเดียวพอแทนการตรวจสอบ

คำถามที่พบบ่อยเกี่ยวกับ SEO Audit

ควรเริ่มจากตรงไหน?

เริ่มจากคำถามเดียว: เว็บไซต์กำลังเสียทราฟฟิก หรือยังไม่ได้สร้างทราฟฟิก คำตอบกำหนดว่าคุณจะปกป้องหน้าที่มีอันดับก่อน หรือหาคำค้นหาที่ยังขาดหน้า จากนั้นทำการตรวจฟรีสามอย่างจากคำตอบเรื่องการตรวจสอบเอง: robots.txt รายงานการจัดทำดัชนีใน Search Console และครอว์ลด้วย Screaming Frog เวอร์ชันฟรี ถ้าผลทำให้คุณแปลกใจ หรือไม่รู้ว่าควรแก้อะไรก่อน นั่นคือหัวข้อที่ดีสำหรับการปรึกษา