Redirect error ใน Google Search Console: สาเหตุและวิธีแก้
คุณเปิดรายงาน Page indexing ใน Search Console แล้วพบ URL อยู่ในรายการ "Redirect error" ต่างจากสถานะส่วนใหญ่ในรายงานนี้ สถานะนี้คือปัญหาจริงที่ต้องแก้
สรุปสั้นๆ คือ Google พยายามตามการเปลี่ยนเส้นทาง (redirect) ของ URL คุณ แต่ไปไม่ถึงหน้าที่ใช้งานได้ ตราบใดที่ยังไม่แก้ URL นั้นจะไม่ถูกจัดทำดัชนี และเนื้อหาที่คุณตั้งใจส่งผู้ใช้ไปหาก็จะไม่ถูกจัดทำดัชนีผ่านเส้นทางนั้นด้วย
ข่าวดีคือ redirect error มักวินิจฉัยได้เร็วเมื่อรู้ว่าต้องดูอะไร คู่มือนี้อธิบายความหมายของสถานะนี้ สาเหตุที่ Google ระบุไว้ วิธีไล่ตรวจแต่ละสาเหตุ และวิธีแก้ไขพร้อมตรวจสอบผล
Redirect error ใน Search Console หมายความว่าอะไร
Redirect error เป็นหนึ่งในเหตุผลในตาราง "Why pages aren't indexed" ของรายงาน Page indexing ใน Google Search Console สถานะนี้แสดงเมื่อ Googlebot ตามการเปลี่ยนเส้นทางจาก URL ของคุณ แต่ไปไม่ถึงปลายทางที่ครอลได้ ทั้ง URL ต้นทางและปลายทางจึงไม่ถูกจัดทำดัชนีผ่านเส้นทางนั้น
สถานะนี้สับสนได้ง่ายกับ "Page with redirect" จึงขอแยกให้ชัด สถานะ Page with redirect เป็นเรื่องปกติ หมายความว่าการเปลี่ยนเส้นทาง ทำงานได้ URL ไม่ถูกจัดทำดัชนีเพราะชี้ไปที่อื่น และ Google ประเมินหน้าปลายทางแยกต่างหาก ส่วน Redirect error หมายความว่าการเปลี่ยนเส้นทาง ล้มเหลว
คุณจะพบสถานะนี้ที่ Indexing › Pages คลิกแถว "Redirect error" เพื่อดู URL ที่ได้รับผลกระทบ และใช้ Export เพื่อดาวน์โหลดรายการทั้งหมด
สาเหตุที่พบบ่อยของ Redirect error
เอกสารของรายงาน Page indexing ของ Google ระบุสถานการณ์ที่ทำให้เกิดสถานะนี้ไว้สี่แบบ และในการทำงานจริงยังพบอีกสองแบบบ่อยๆ
1. Redirect chain ที่ยาวเกินไป
ทุก URL ที่เปลี่ยนเส้นทางไปยัง URL อื่นจะเพิ่ม hop หนึ่งครั้ง ตามเอกสารเรื่องการครอลของ Google ครอว์เลอร์ของ Google ตามการเปลี่ยนเส้นทางได้สูงสุด 10 hop เกินกว่านั้น Googlebot จะเลิกตาม และ Search Console จะรายงาน redirect error โดยทั่วไป chain จะยาวขึ้นเรื่อยๆ ตามเวลา เช่น มีกฎ HTTP ไป HTTPS แล้วเพิ่มกฎ www ตามด้วยกฎเครื่องหมายทับท้าย URL และมีการย้ายเว็บไซต์ซ้อนทับลงไปอีก
2. Redirect loop
URL A เปลี่ยนเส้นทางไปยัง URL B และ URL B เปลี่ยนเส้นทางกลับมาที่ URL A (หรือไปยัง URL ใดก็ตามที่วนกลับมาที่ A) chain จึงไม่มีวันจบ และไม่มีวันไปถึงหน้าใด loop มักเกิดจากกฎสองข้อที่ขัดแย้งกัน เช่น กฎหนึ่งบังคับให้มีเครื่องหมายทับท้าย URL แต่อีกกฎลบออก
3. URL ของการเปลี่ยนเส้นทางยาวเกินความยาวสูงสุด
หากกฎการเปลี่ยนเส้นทางเติมบางอย่างต่อท้าย URL ไปเรื่อยๆ เช่น พารามิเตอร์หรือส่วนของ path ในทุก hop ที่อยู่จะยาวขึ้นจนเกินความยาว URL สูงสุด และ chain ก็ล้มเหลว
4. URL ที่ผิดรูปแบบหรือว่างเปล่าใน chain
การพิมพ์ผิด เช่น htp:// แทน http://, path แบบสัมพัทธ์ที่ชี้ไปผิดที่ หรือ header Location ที่ว่างเปล่า จะทำให้การเปลี่ยนเส้นทางขาดที่ hop นั้น
5. ปลายทางที่ Google ครอลไม่ได้
หาก URL สุดท้ายถูกบล็อกโดย robots.txt Googlebot จะดึงข้อมูลหน้านั้นไม่ได้ ตรวจสอบว่าปลายทางของการเปลี่ยนเส้นทางทุกรายการครอลได้ ไม่ใช่แค่มีอยู่จริง
6. กฎการเปลี่ยนเส้นทางที่ขัดแย้งกันในหลายที่
การเปลี่ยนเส้นทางที่ตั้งไว้ใน CMS, ปลั๊กอิน, เว็บเซิร์ฟเวอร์ และ CDN อาจซ้อนกันหรือขัดแย้งกัน กฎที่เพิ่มในชั้นหนึ่งอาจส่ง URL กลับไปหากฎในอีกชั้นหนึ่ง และนี่คือที่มาของ chain และ loop ส่วนใหญ่
วิธีวินิจฉัย Redirect error
เริ่มจาก URL ที่ Search Console แจ้งไว้ แล้วไล่ดูว่าเกิดอะไรขึ้นเมื่อมีการร้องขอแต่ละ URL
ใช้ URL Inspection
วาง URL ที่ได้รับผลกระทบลงในแถบตรวจสอบด้านบนของ Search Console ส่วน Page indexing จะแสดงว่า Google ครอลครั้งล่าสุดเมื่อไหร่ และดึงข้อมูลหน้าสำเร็จหรือไม่ คลิก Test live URL เพื่อตรวจพฤติกรรมปัจจุบัน เพราะรายงานอาจอัปเดตช้ากว่าการแก้ไขของคุณ
ไล่ตรวจเส้นทางการเปลี่ยนเส้นทางทั้งหมด
ร้องขอ URL แล้วตามทุก hop จากเทอร์มินัลทำได้ดังนี้
curl -sIL https://example.com/old-page | grep -iE "^(HTTP|location)"
ผลลัพธ์จะแสดงรหัสสถานะและ header Location แต่ละรายการตามลำดับ สิ่งที่ต้องมองหาคือมีมากกว่าหนึ่ง hop หรือไม่, มี URL ที่ปรากฏซ้ำสองครั้ง (loop) หรือไม่, มี Location ที่ผิดรูปแบบหรือไม่ หรือ response สุดท้ายไม่ใช่ 200 หรือไม่
หากไม่อยากใช้เทอร์มินัล การตรวจ SEO ฟรีในหน้า Crawler ของ SEOcrawl AI จะนับจำนวน hop ของการเปลี่ยนเส้นทางของ URL ใดก็ได้ และเครื่องมือ fetch_url ของเซิร์ฟเวอร์ MCP ของ SEOcrawl AI จะส่งคืน URL สุดท้าย รหัสสถานะ และ redirect chain ทั้งหมดให้คุณใน Claude, ChatGPT หรือ Cursor ได้โดยตรง
ตรวจรหัส response สุดท้าย
ยืนยันว่า URL สุดท้ายในเส้นทางตอบกลับด้วย 200 ไม่ใช่ 3xx อีกตัว, 4xx หรือ 5xx หาก chain จบลงที่ข้อผิดพลาด ปัญหาอยู่ที่ปลายทาง ดูคู่มือของเราเรื่อง Not found (404) และ Blocked due to other 4xx issue
วิธีแก้ตามแต่ละสาเหตุ
แนวคิดในการแก้แทบจะเหมือนกันเสมอ คือ ส่ง URL ต้นทางไปยังปลายทางสุดท้ายใน hop เดียวที่สะอาด
- Chain ยาวเกินไป: ชี้ URL แรกไปยัง URL สุดท้ายที่ตอบกลับ 200 โดยตรง และลบ hop ที่อยู่ตรงกลางออก หาก URL เก่าหลายตัวป้อนเข้าสู่ chain เดียวกัน ให้อัปเดตทุกตัว
- Redirect loop: หากฎสองข้อที่ชี้หากัน แล้วลบหรือแก้ข้อใดข้อหนึ่ง เพื่อให้เส้นทางจบที่หน้าจริง
- URL ยาวเกินไป: แก้กฎที่คอยเติมต่อท้าย URL แล้วยืนยันว่าหน้าปลายทางโหลดได้
- ปลายทางผิดหรือว่าง: แก้คำที่พิมพ์ผิดหรือค่า
Locationที่ว่างเปล่า และใช้ URL แบบสัมบูรณ์ - ปลายทางถูกบล็อกโดย robots.txt: อนุญาตให้ครอลปลายทาง หรือเปลี่ยนเส้นทางไปยัง URL ที่ไม่ถูกบล็อก
- กฎขัดแย้งกัน: รวมการเปลี่ยนเส้นทางไว้ในที่เดียว เพื่อไม่ให้ CMS, เซิร์ฟเวอร์ และ CDN เขียนทับกัน
จากนั้น อัปเดตลิงก์ภายใน ให้ชี้ไปยัง URL สุดท้ายแทน URL ที่มีการเปลี่ยนเส้นทาง และใส่เฉพาะ URL สุดท้ายใน XML sitemap Crawler ตรวจพบทั้งสองกรณีทั่วทั้งเว็บไซต์ ทั้งลิงก์ภายในที่ตอบกลับ 3xx และ sitemap ที่มี URL ที่เปลี่ยนเส้นทาง หากต้องการตรวจ sitemap แยกต่างหาก ให้ใช้เครื่องมือตรวจสอบ sitemap ฟรี ซึ่งตรวจรหัสสถานะและ redirect chain ของทุก URL ที่อยู่ใน sitemap
แนวทางปฏิบัติที่ดีในการเปลี่ยนเส้นทาง
นิสัยไม่กี่อย่างช่วยป้องกัน redirect error ส่วนใหญ่ได้ตั้งแต่ก่อนเกิด
- ใช้รหัสสถานะที่ถูกต้อง การเปลี่ยนเส้นทาง 301 (หรือ 308) เป็นสัญญาณที่ชัดเจนว่าควรจัดทำดัชนีหน้าปลายทาง ใช้สำหรับการย้ายถาวร การเปลี่ยนเส้นทาง 302 (หรือ 307) เป็นสัญญาณที่อ่อนซึ่งคง URL เดิมไว้ในผลการค้นหา ใช้เฉพาะเมื่อเป็นการย้ายชั่วคราว
- เลือกใช้การเปลี่ยนเส้นทางฝั่งเซิร์ฟเวอร์เป็นหลัก Google ตาม meta refresh แบบทันทีและการเปลี่ยนเส้นทางด้วย JavaScript ได้เช่นกัน แต่แนะนำให้ใช้ JavaScript เฉพาะเมื่อใช้การเปลี่ยนเส้นทางฝั่งเซิร์ฟเวอร์หรือ meta refresh ไม่ได้
- รักษา chain ให้สั้น hop เดียวคือดีที่สุด ทุก hop ที่เพิ่มขึ้นทำให้ผู้ใช้รอนานขึ้น ใช้ crawl budget และเพิ่มจุดที่อาจล้มเหลว
- เปลี่ยนเส้นทางไปยัง URL ที่ตอบกลับ 200 เสมอ ห้ามไปยังการเปลี่ยนเส้นทางอีกทอด
- อัปเดตลิงก์ภายในและ sitemap ให้เป็น URL สุดท้าย เพื่อให้ Google และผู้เข้าชมข้ามการเปลี่ยนเส้นทางไปได้เลย
- ตรวจซ้ำหลังการย้ายเว็บไซต์ทุกครั้ง หรือหลังเปลี่ยนกฎใน CMS, เซิร์ฟเวอร์ หรือ CDN เพราะเป็นช่วงที่ chain และ loop ใหม่มักเกิดขึ้น
วิธีตรวจสอบการแก้ไข
เมื่อการเปลี่ยนเส้นทางไปถึงหน้า 200 ได้ใน hop เดียวแล้ว:
- ใช้ URL Inspection กับ URL ที่ได้รับผลกระทบ แล้วคลิก Test live URL เพื่อยืนยันว่าตอนนี้ Google ไปถึงปลายทางได้แล้ว
- คลิก Request indexing สำหรับ URL ที่สำคัญที่สุดของคุณ
- ในรายงาน Page indexing ให้เปิดปัญหา Redirect error แล้วคลิก Validate fix เพื่อให้ Google ครอล URL ที่ได้รับผลกระทบทั้งหมดใหม่
- ติดตามสถานะการตรวจสอบ อาจใช้เวลาหลายวันหรือสองสามสัปดาห์ URL จะหลุดออกจากปัญหานี้เมื่อได้รับการครอลใหม่
รู้ทัน Redirect error ก่อนใคร
Redirect error แทบไม่เคยส่งสัญญาณเตือน มันแค่ปรากฏในรายงาน Page indexing และในเว็บไซต์ขนาดใหญ่อาจถูกมองข้ามไปจนกระทั่งทราฟฟิกตก การเปิด Search Console ตรวจทุก property ด้วยมือเป็นงานที่ช้าและถูกข้ามได้ง่าย
มุมมอง Indexation ของ SEOcrawl AI จัดกลุ่ม URL ของคุณตามสถานะ coverage ใน Search Console คุณจึงเห็นว่า URL ใดอยู่ในสถานะข้อผิดพลาด และติดตามได้ว่าจำนวนเปลี่ยนไปอย่างไรเมื่อเวลาผ่านไป คุณติดแท็ก URL ที่ได้รับผลกระทบได้ตามกฎ ด้วยตนเอง หรือผ่านเซิร์ฟเวอร์ MCP แล้วจัดการไล่ไปจนกว่าแต่ละ URL จะได้รับการแก้ไข หากคุณทำงานกับผู้ช่วย AI การตรวจ Google Search Console จะตรวจ index coverage ของคุณจากพรอมต์เดียว และสร้างงานสำหรับการแก้ไขแต่ละรายการ
คำถามที่พบบ่อย
อะไรทำให้เกิด Redirect error ใน Google Search Console
Google ระบุสาเหตุไว้สี่อย่าง ได้แก่ redirect chain ที่ยาวเกินไป, redirect loop, URL ของการเปลี่ยนเส้นทางที่ยาวจนเกินความยาว URL สูงสุดในที่สุด และ URL ที่ผิดรูปแบบหรือว่างเปล่าใน chain ไม่ว่ากรณีใด Googlebot ก็ไปไม่ถึงหน้าปลายทางที่ใช้งานได้
แก้ Redirect error อย่างไร
ส่ง URL ต้นทางไปยังปลายทางสุดท้าย ใน hop เดียว ลบการเปลี่ยนเส้นทางที่อยู่ตรงกลาง ตัด loop ทิ้ง และตรวจให้แน่ใจว่า URL สุดท้ายตอบกลับด้วยสถานะ 200 อัปเดตลิงก์ภายในให้ชี้ไปที่ปลายทาง จากนั้นใช้ URL Inspection และคลิก Validate fix ในรายงาน Page indexing
Redirect chain และ redirect loop คืออะไร
Redirect chain คือการเปลี่ยนเส้นทางหลายครั้งต่อกัน เช่น URL A ไป B แล้ว B ไป C ไปเรื่อยๆ ก่อนจะถึงหน้าสุดท้าย ส่วน redirect loop คือ chain ที่ไม่มีวันจบ เพราะ URL ชี้วนกลับหากันเอง ทั้งสองแบบอาจทำให้ Google ไปไม่ถึงหน้าที่จะจัดทำดัชนี
301 กับ 302 ควรใช้แบบไหน
ใช้ 301 (หรือ 308) สำหรับการย้ายถาวร Google ถือว่าเป็นสัญญาณที่ชัดเจนให้จัดทำดัชนีหน้าปลายทาง ใช้ 302 (หรือ 307) เฉพาะการย้ายชั่วคราว เมื่อคุณต้องการให้ URL เดิมยังอยู่ในผลการค้นหา
"Page with redirect" เหมือนกับ Redirect error หรือไม่
ไม่เหมือน "Page with redirect" หมายความว่าการเปลี่ยนเส้นทางทำงานได้ URL นั้นไม่ถูกจัดทำดัชนีเพราะชี้ไปยังหน้าอื่น ส่วน Redirect error หมายความว่า Google พยายามตามการเปลี่ยนเส้นทางแต่ไปไม่ถึงหน้าที่ใช้งานได้
Redirect error จะหายไปภายในกี่วัน
หลังจากคลิก Validate fix แล้ว Google จะครอล URL ที่ได้รับผลกระทบใหม่ในช่วงหลายวันถัดไป บางครั้งนานถึงสองสัปดาห์ สถานะจะอัปเดตเมื่อแต่ละ URL ได้รับการประมวลผล คุณจึงไม่ต้องขอจัดทำดัชนีทีละ URL ด้วยตนเอง
โดย: David Kaufmann
ในช่วง 10+ ปีที่ผ่านมา ผมหมกมุ่นกับ SEO อย่างสมบูรณ์ — และพูดตรง ๆ ก็ไม่อยากให้เป็นแบบอื่น
อาชีพของผมก้าวขึ้นไปอีกระดับเมื่อทำงานเป็นผู้เชี่ยวชาญ SEO อาวุโสที่ Chess.com — หนึ่งใน 100 เว็บไซต์ที่มีผู้เข้าชมมากที่สุดในอินเทอร์เน็ต การทำงานในระดับนี้สอนสิ่งที่ไม่มีหลักสูตรหรือประกาศนียบัตรใดสอนได้
จากประสบการณ์นี้ ผมก่อตั้ง SEO Alive — เอเจนซีสำหรับแบรนด์ที่จริงจังกับการเติบโตแบบออร์แกนิก และเพราะหาเครื่องมือที่จัดการทั้งโลกคลาสสิกและยุค AI ได้ดีไม่ได้ ผมจึงสร้าง SEOcrawl AI ขึ้น หากคุณกำลังมองหาพาร์ตเนอร์ SEO มากประสบการณ์ที่รักสาขานี้ — ยินดีพูดคุยครับ!
ค้นพบเนื้อหาเพิ่มเติมของผู้เขียนคนนี้
