วิธีแก้ error 404 ใน Google Search Console (2026)

แก้ 'Not found (404)' ใน Search Console: เมื่อไหร่ควรปล่อยผ่าน เมื่อไหร่ควรทำ 301 redirect และเมื่อไหร่ควรกู้หน้าเดิม พร้อมตารางตัดสินใจและขั้นตอน validate

คำถามที่พบบ่อย

error 404 ทำให้อันดับใน Google ตกไหม

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

หน้าที่ลบแล้วควรใช้ 404 หรือ 410

สำหรับ Google Search แทบไม่ต่างกัน เอกสารเรื่อง HTTP status code ของ Google ปฏิบัติต่อ error 4xx ทุกตัวยกเว้น 429 เหมือนกัน คือถือว่าเนื้อหาไม่มีอยู่ URL ที่เคยอยู่ในดัชนีจะถูกนำออก และความถี่ในการ crawl URL นั้นจะค่อยๆ ลดลง เลือกอันที่แพลตฟอร์มของคุณตั้งค่าได้ง่ายกว่าก็พอ

'Validate fix' สำหรับ error 404 ใช้เวลานานแค่ไหน

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

ทำไม URL ที่แก้แล้วยังโผล่ในรายงาน Not found (404)

Google จะพยายาม crawl URL ที่หายไปอยู่พักหนึ่ง จึงอาจยังค้างในรายการหลังจากที่คุณแก้แล้ว นอกจากนี้รายการตัวอย่างในรายงานจำกัดที่ 1,000 แถว และไม่รับประกันว่าจะแสดงครบทุก URL ให้แก้ที่ต้นเหตุ (ลิงก์เสีย หรือรายการใน sitemap) จากนั้นสั่ง validate แล้วรอผล

ควร redirect 404 ทุกหน้าไปหน้าแรกไหม

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

คำตอบสั้นๆ: ใน Search Console ให้เปิด Indexing > Pages (การจัดทำดัชนี > หน้า) คลิก Not found (404) แล้วแยกแต่ละ URL ออกเป็นสามกลุ่ม ถ้าหน้านั้นถูกลบโดยตั้งใจและไม่มีลิงก์ไหนชี้มา ให้ปล่อยผ่าน ถ้าหน้านั้นย้ายที่หรือมีหน้าที่ใกล้เคียงมาแทน ให้ทำ 301 redirect ไปหน้านั้น ถ้าหน้านั้นควรมีอยู่ ให้กู้คืนกลับมา จากนั้นแก้ลิงก์ภายในหรือรายการใน sitemap ที่ชี้ไปยัง URL เสีย แล้วกด Validate fix (ตรวจสอบการแก้ไข)

"error 404" ส่วนใหญ่ใน Search Console ไม่จำเป็นต้องแก้เลย ทักษะที่ต้องใช้จึงเป็นการคัดแยก ไม่ใช่การซ่อม

"Not found (404)" หมายถึงอะไรกันแน่

รายงาน Page indexing จะแสดง URL ที่ Google พยายาม crawl แต่จัดทำดัชนีไม่ได้ "Not found (404)" หมายความว่าเซิร์ฟเวอร์ตอบคำขอนั้นด้วยสถานะ 404 เท่านั้นเอง ไม่ได้บอกว่า URL นั้นสำคัญหรือไม่

คำแนะนำการแก้ปัญหาของ Google ชัดเจนว่า ให้แก้เฉพาะ 404 ที่คุณลิงก์ไปเองหรือระบุไว้ใน sitemap และถ้าหน้าไหนย้ายที่ ให้ตอบ redirect แบบ 3XX ไปยังหน้าใหม่ Google ยังระบุ "404 ของหน้าที่คุณลบไปแล้วและไม่มีหน้าทดแทน" เป็นหนึ่งในเหตุผลที่หน้าหนึ่งไม่ถูกจัดทำดัชนีได้อย่างถูกต้อง

ถ้ายังไม่ได้ตั้งค่าเครื่องมือนี้ เริ่มจากคู่มือ Search Consoleของเรา หรือขั้นตอนการยืนยันความเป็นเจ้าของเว็บไซต์ใน Google Search Console

ขั้นที่ 1: ส่งออกรายการ แล้วหาว่า 404 แต่ละตัวมาจากไหน

เปิด Search Console แล้วเลือกพร็อพเพอร์ตี้ของคุณ
ไปที่ Indexing > Pages
เลื่อนไปที่ตาราง "Why pages aren't indexed" (เหตุผลที่หน้าไม่ถูกจัดทำดัชนี) แล้วคลิก Not found (404)
ดู URL ตัวอย่าง ตารางนี้จำกัดที่ 1,000 แถวและไม่รับประกันว่าจะแสดงทุก URL ถ้าเว็บไซต์ใหญ่ให้ถือว่าเป็นแค่ตัวอย่าง
ส่งออกข้อมูลถ้าอยากทำงานใน spreadsheet
คลิก URL แล้วใช้ Inspect URL (ตรวจสอบ URL) เพื่อดูว่า Google ค้นพบ URL นี้ได้อย่างไร ข้อมูลหน้าที่อ้างอิงและ sitemap จะบอกว่าลิงก์นั้นเป็นของคุณหรือไม่

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

ขั้นที่ 2: ตัดสินใจ: ปล่อยผ่าน, redirect หรือกู้คืน

ใช้ตารางนี้กับทุกกลุ่ม URL ในรายงาน

สถานการณ์	ลักษณะที่พบ	สิ่งที่ควรทำ
ลบหน้าโดยตั้งใจ ไม่มีหน้าทดแทน ไม่มีลิงก์ภายใน	สินค้าเก่า อีเวนต์ที่หมดอายุ หน้าทดสอบ	ปล่อยผ่าน ปล่อยเป็น 404 (หรือ 410)
ลบหน้าแล้ว แต่มีหน้าที่ใกล้เคียงมาแทน	สินค้าที่เลิกขาย คู่มือฉบับใหม่กว่า	301 redirect ไปยังหน้าที่ใกล้เคียงที่สุด
URL เปลี่ยน (เปลี่ยน slug ย้ายโฟลเดอร์ ย้ายโดเมนหรือเปลี่ยนเป็น HTTPS)	เนื้อหาเดิมอยู่ที่ที่อยู่ใหม่	301 redirect จาก URL เก่าไป URL ใหม่ ภายในหนึ่งทอด
หน้านี้ควรมีอยู่ แต่ถูกลบหรือยกเลิกการเผยแพร่โดยไม่ตั้งใจ	หน้าบริการที่ยังใช้งานอยู่ บทความสำคัญ	กู้คืน ตรวจว่าตอบ 200 แล้วสั่ง validate
ลิงก์ในเมนู ส่วนท้ายเว็บ หรือเนื้อหาของคุณเองชี้ไปที่หน้านั้น	ลิงก์ภายในที่ชี้ไป URL เสีย	แก้ลิงก์ (หรือ redirect ถ้าหน้านั้นย้ายที่)
อยู่ใน XML sitemap ของคุณ	sitemap มี URL ที่ถูกลบไปแล้ว	ลบออกจาก sitemap แล้วค่อยตัดสินใจว่าจะ redirect หรือปล่อยผ่าน
URL ขยะจากสแปมหรือพารามิเตอร์แปลกๆ	สตริงสุ่ม รูปแบบที่สแครปเปอร์สร้าง	ปล่อยผ่าน ตรวจความปลอดภัยถ้าดูเหมือนถูกฝังเข้ามา (ดูด้านล่าง)

ถ้าหน้าทดแทนไม่ได้ใกล้เคียงกันจริงๆ อย่าฝืนหาให้ได้ เอกสาร redirect ของ Google อธิบายว่า redirect คือวิธีส่งผู้ใช้และ Google ไปยังที่อยู่ใหม่ของหน้า ส่วนหน้าที่ไม่มีที่อยู่ใหม่ก็ไม่มีอะไรให้ชี้ไป

ขั้นที่ 3: ตั้งค่า redirect ให้ถูกต้อง

สำหรับการย้ายถาวร Google แนะนำให้ใช้ redirect ฝั่งเซิร์ฟเวอร์แบบถาวรทุกครั้งที่ทำได้ รหัสสถานะ 301 และ 308 ต่างหมายถึงหน้านั้นย้ายถาวร Google ระบุว่าให้ใช้ JavaScript redirect เฉพาะเมื่อทำ redirect ฝั่งเซิร์ฟเวอร์หรือ meta refresh ไม่ได้

หลักปฏิบัติ:

redirect ไปยัง URL เดียวที่ตรงที่สุด ไม่ใช่ผ่านหลายทอด
ชี้ไปยังหน้าที่ตอบ 200 ตามปกติ ไม่ใช่หน้าที่เป็น redirect หรือ error อีกที
อัปเดตลิงก์ภายในให้ชี้ไป URL ใหม่ด้วย จะได้ไม่ต้องพึ่ง redirect ตลอดไป
บน WordPress ใช้ปลั๊กอิน redirect หรือกฎ redirect ของโฮสต์ได้ ส่วนแพลตฟอร์มอื่นให้ใช้การตั้งค่า redirect หรือ rewrite ของเซิร์ฟเวอร์หรือ CMS

ตัวอย่างแผนผัง redirect ที่ส่งให้นักพัฒนาหรือวางในเครื่องมือ redirect ได้เลย:

`` /old-pricing -> /pricing /blog/2022/seo-tips -> /blog/seo-tips /services/web-design -> /services/website-design ``

ขั้นที่ 4: ทดสอบการแก้ไข แล้วสั่ง validate

ก่อนแจ้ง Google ให้ตรวจ URL ด้วยตัวเองก่อน

เปิด URL เก่าในเบราว์เซอร์ หรือรันการตรวจ header แล้วยืนยันว่าตอบ 301 และไปจบที่หน้าที่ตอบ 200
ใน Search Console วาง URL ในแถบด้านบนแล้วรัน Inspect URL จากนั้นใช้การทดสอบสด (live test) เพื่อดูว่า Google ได้อะไรกลับไป
ยืนยันว่า URL นั้นไม่อยู่ใน sitemap แล้ว และไม่มีหน้าภายในไหนลิงก์ไปหา

จากนั้นสั่ง validate:

เปิดปัญหา Not found (404) ในรายงาน Page indexing
คลิก Validate fix
ดูสถานะ อย่ากด Validate fix ซ้ำจนกว่าการตรวจสอบจะสำเร็จหรือล้มเหลว
ถ้าล้มเหลว ให้คลิก See details (ดูรายละเอียด) แก้ URL ที่เหลือ แล้วเริ่มใหม่

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

อีกข้อที่ควรรู้: Google จัดการ URL ที่ตอบ 404 แบบค่อยเป็นค่อยไป โดยระบุว่าระบบจัดทำดัชนีจะนำ URL ออกจากดัชนีถ้าเคยถูกจัดทำดัชนีมาก่อน หน้า 404 ที่เพิ่งพบใหม่จะไม่ถูกประมวลผล และความถี่ในการ crawl จะค่อยๆ ลดลง ดังนั้น URL ที่คุณปล่อยเป็น 404 ไว้จะจางหายไปเอง

ขั้นที่ 5: เช็กกรณีที่ "ดูเหมือน 404 แต่ไม่ใช่"

มีสองกรณีที่หน้าตาคล้ายกันแต่ต้องจัดการต่างออกไป:

Soft 404 หน้านั้นตอบสถานะ 200 แต่แสดงหน้าว่างหรือข้อความ error และ Search Console รายงานว่าเป็น soft 404 แก้โดยให้ตอบสถานะ 404 จริง หรือใส่เนื้อหาจริงลงในหน้านั้น
URL ที่ถูกแฮกหรือถูกฝังเข้ามา ถ้าจู่ๆ มี 404 ท่วมมาที่ชื่อไฟล์แปลกๆ หรือพาธที่เป็นสแปม อาจชี้ว่าเว็บไซต์ถูกเจาะ ถ้าตรงกับที่คุณเจอบน CMS ให้อ่านคู่มือแก้ไขของเราสำหรับ WordPress, Joomla หรือ Drupal แล้วตรวจรายงานอีกครั้ง

เช็กลิสต์คัดแยกที่คัดลอกไปใช้ได้

[ ] ส่งออก URL ที่เป็น Not found (404) จาก Indexing > Pages แล้ว
[ ] ระบุที่มาของแต่ละ URL: ลิงก์ของเรา, sitemap ของเรา, ลิงก์ภายนอก หรือไม่ทราบ
[ ] ปล่อยผ่านหน้าที่ลบแล้วโดยไม่มีหน้าทดแทนและไม่มีลิงก์ภายใน
[ ] เพิ่ม 301 redirect ให้หน้าที่ย้ายที่ ภายในหนึ่งทอด ไปยังหน้าที่ตอบ 200
[ ] กู้คืนหน้าที่ถูกลบโดยไม่ตั้งใจ
[ ] แก้ลิงก์ภายในที่ชี้ไป URL เสีย
[ ] ลบ URL เสียออกจาก XML sitemap
[ ] ตรวจตัวอย่างด้วย Inspect URL
[ ] กด Validate fix เพียงครั้งเดียว แล้วรอผล

ป้องกันไม่ให้เกิด 404 ชุดใหม่

404 ที่เกิดซ้ำๆ ส่วนใหญ่มาจากการสร้างเว็บใหม่ การเปลี่ยน slug และการลบโพสต์โดยไม่มีแผน redirect ก่อนย้ายเว็บทุกครั้ง ให้ทำรายการ URL เก่าและจับคู่กับที่อยู่ใหม่ของแต่ละหน้า ถ้าคุณกำลังจะสร้างเว็บไซต์เล็กๆ ใหม่อยู่แล้ว แพ็กเกจฟรีของ We.Inc ให้เผยแพร่ได้สูงสุดสามเว็บไซต์จากเทมเพลตสำเร็จรูป ส่วน AI builder ที่ร่างเว็บไซต์จากพรอมต์เริ่มที่แพ็กเกจ Starter ราคา $20 ต่อเดือน คุณสมัครได้ที่นี่ ไม่ว่าจะเลือกแบบไหน เก็บแผนผัง URL เก่า-ใหม่ไว้ด้วย เพราะนี่คือสิ่งที่ทำให้รายงานนี้สะอาดอยู่เสมอ

ถ้าอยากเข้าใจเครื่องมือนี้ในภาพรวมมากขึ้น ดู Google Search Console สำหรับมือใหม่

เริ่มต้นฟรี · ไม่ต้องใช้บัตรเครดิต

Umair Ali Sadaqat

ผู้ก่อตั้ง We.Inc

Umair เป็นผู้ก่อตั้ง We.Inc เขาเขียนเกี่ยวกับการสร้างเว็บไซต์ด้วย AI เอเจนซี และธุรกิจการบริหารเว็บสตูดิโอ

พร้อมสร้างสิ่งที่ยอดเยี่ยมแล้วหรือยัง

เข้าร่วมกับธุรกิจ 15,000+ รายที่ใช้ We.Inc เปิดตัว เติบโต และทำงานอัตโนมัติ ทั้งหมดจากแพลตฟอร์มเดียว

เริ่มต้นฟรี

ไม่ต้องใช้บัตรเครดิต · ติดต่อฝ่ายขาย