Redirect Chain คืออะไร ทำไมทำให้ SEO เสียคะแนน แก้ยังไง

Redirect chain คืออะไร

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

ตัวอย่างที่เห็นได้บ่อยที่สุดคือหน้าบทความที่เคยเปลี่ยน URL สองครั้ง ครั้งแรก /article/seo-tip ถูกย้ายไป /blog/seo-tip ครั้งที่สองย้ายไป /blog/seo-tips-2026 ถ้าคนตั้ง redirect ครั้งที่สองเพิ่มกฎใหม่โดยไม่แตะกฎเดิม ผลคือ URL แรกสุดยังชี้ไปที่ URL กลางอยู่ แล้วค่อยเด้งต่อไปปลายทาง กลายเป็นเชน 2 hop โดยไม่มีใครตั้งใจ

สิ่งที่ทำให้เชนอันตรายกว่าที่ควรจะเป็นคือมันไม่แสดงอาการ ผู้ใช้กดลิงก์เก่าแล้วก็ยังไปถึงหน้าที่ถูกต้อง ทีมงานเปิดดูก็เห็นว่าใช้งานได้ ไม่มี error ไม่มีหน้า 404 ให้ตกใจ เชนจึงเป็นปัญหาที่ต้องออกไปตรวจถึงจะเจอ ไม่มีวันเด้งมาเตือนเราเอง ต่างจาก loop ที่ประกาศตัวชัดเจนทันทีที่เกิด

hop คืออะไร นับยังไง

hop คือหนึ่งจังหวะของการส่งต่อ นับจากจำนวนครั้งที่เซิร์ฟเวอร์ตอบกลับมาด้วยสถานะ 3xx พร้อม Location header ก่อนจะได้สถานะ 200 ที่เป็นหน้าจริง เส้นทาง A ไป D ตรงๆ คือ 1 hop ส่วน A ไป B ไป C ไป D คือ 3 hop

จุดที่คนนับพลาดบ่อยคือลืมนับ redirect พื้นฐานที่ระบบทำให้อัตโนมัติ เช่น การบังคับ HTTPS และการรวม www ถ้าเว็บทำสองอย่างนี้แยกกันคนละชั้น URL เก่าหนึ่งเส้นอาจกลายเป็น 3 hop ตั้งแต่ยังไม่ได้นับ redirect ที่เราตั้งเองด้วยซ้ำ

Redirect chain กับ redirect loop ต่างกันยังไง

ต่างกันที่ chain มีปลายทาง ส่วน loop ไม่มี เชนคือเส้นตรงที่ยาวเกินจำเป็นแต่สุดท้ายก็ถึงหน้าจริง ขณะที่ loop คือวงวนที่ย้อนกลับมาที่เดิม เช่น A ไป B แล้ว B ย้อนกลับไป A จนไม่มีทางออก

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

chain จึงเป็นปัญหาที่แย่กว่าในเชิงการค้นพบ ไม่ใช่ในเชิงความรุนแรง loop พังชัดจนต้องแก้ทันที ส่วน chain ปล่อยไว้ได้เป็นปีโดยไม่มีใครบ่น แล้วค่อยๆ กัดประสิทธิภาพทีละนิดตลอดเวลาที่ปล่อยไว้

ทำไม redirect chain ทำให้ SEO เสียคะแนน

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

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

• Link equity — ประเด็นที่ยังถกกันอยู่ ฝั่ง Google ระบุว่า 3xx redirect ไม่ทำให้ PageRank สูญไปแล้ว แต่ในทางปฏิบัติเชนยาวยังเสี่ยงที่สัญญาณจะไปไม่ถึงปลายทาง เพราะถ้าจุดกลางทางจุดใดพัง ถูกลบ หรือบอตตามไม่จบเส้น ลิงก์จากภายนอกที่ชี้มา URL เก่าก็ส่งแรงถึงหน้าจริงไม่ได้
• เปลือง crawl budget — Googlebot ต้องเสียรอบ crawl ไล่ตามทีละ hop แทนที่จะเอารอบนั้นไปเก็บหน้าใหม่ที่ยังไม่ถูก index ยิ่งเว็บใหญ่และมี URL เก่าเยอะยิ่งเห็นผลชัด
• เพิ่มเวลาโหลดและกระทบ Core Web Vitals — แต่ละ hop คือ round trip ใหม่ที่ต้องต่อเชื่อมและรอตอบกลับ ความหน่วงสะสมนี้กระทบค่า LCP โดยตรง
• ประสบการณ์ผู้ใช้แย่ลง โดยเฉพาะบนมือถือหรือเน็ตช้า ที่ความหน่วงต่อรอบสูงกว่าบนเดสก์ท็อปมาก
• เสี่ยงไปไม่ถึงปลายทาง ถ้าเชนยาวเกินขีดจำกัดที่บอตยอมตาม หน้านั้นอาจไม่ถูกเก็บเข้าดัชนีในรอบนั้นเลย

ทำไมเวลาโหลดถึงบวกเพิ่มเยอะกว่าที่คิด

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

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

Redirect chain ยาวกี่ hop ถึงเรียกว่ามีปัญหา

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

ฝั่ง Google เคยมีคำแนะนำจาก John Mueller ว่าควรให้เชนสั้นกว่า 5 hop และในทางปฏิบัติ Googlebot จะตามได้ราว 5 hop ต่อหนึ่งรอบ crawl ถ้ายังไม่ถึงปลายทางมันจะพักไว้แล้วค่อยกลับมาลองใหม่ในรอบถัดไป ซึ่งแปลว่าหน้าปลายทางของคุณต้องรอนานขึ้นกว่าจะถูกเก็บ

ส่วนขีดจำกัดสูงสุดในทางเทคนิคอยู่ที่ราว 10 hop เกินจากนั้น Search Console จะรายงานเป็น Redirect error และหน้านั้นจะไม่ถูก index เลย จุดนี้ไม่ใช่การเสียคะแนนแล้วแต่เป็นการหายไปจากผลค้นหา

• 1 hop — เป้าหมายที่ควรตั้งไว้ ทุก URL เก่าถึงปลายทางในจังหวะเดียว
• 2 ถึง 3 hop — ยังรับได้ในช่วงเปลี่ยนผ่าน แต่ควรมีแผนตัดให้เหลือเส้นเดียว
• ใกล้ 5 hop — เริ่มเสี่ยงที่บอตจะไม่จบเส้นทางในรอบเดียว การเก็บดัชนีช้าลง
• เกิน 10 hop — Search Console ขึ้น Redirect error หน้าไม่ถูก index ถือเป็นปัญหาระดับต้องแก้ทันที

Redirect chain เกิดจากอะไรได้บ้าง

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

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

• ย้ายโดเมนหรือเปลี่ยน URL หลายรอบ แล้วไม่อัปเดต redirect ชุดเก่าให้ชี้ปลายทางล่าสุด
• ซ้อนกันของ redirect พื้นฐานสำหรับรวมร่าง URL คือ HTTP ไป HTTPS ต่อด้วย www ไป non-www ต่อด้วย trailing slash ถ้าไม่รวมเป็นกฎเดียวจะได้เชนฟรีทันที 3 hop
• ปลั๊กอิน WordPress หลายตัวตั้งกฎทับกันเป็นชั้นๆ โดยแต่ละตัวไม่รู้ว่าอีกตัวทำอะไรไว้
• CMS เปลี่ยน slug บทความหลายครั้งแล้วสร้าง redirect ใหม่เพิ่มทุกครั้งแทนที่จะแก้ของเดิมให้ชี้ตรง
• ตั้งกฎระดับ CDN หรือ edge ทับกฎที่มีอยู่แล้วในชั้นแอปพลิเคชัน โดยไม่ได้ตรวจว่าซ้อนกันหรือไม่

ทำไมงานย้ายโดเมนถึงสร้างเชนได้ง่ายเป็นพิเศษ

เพราะการย้ายโดเมนคือการเพิ่ม redirect หนึ่งชั้นให้กับ URL ทุกเส้นที่มีอยู่พร้อมกัน ถ้าเว็บเดิมมี redirect ค้างอยู่ 1 จังหวะ หลังย้ายจะกลายเป็น 2 hop ทั้งเว็บโดยอัตโนมัติ และถ้าเว็บเดิมมี 2 hop ก็จะกลายเป็น 3 hop ทันที

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

จะรู้ได้ยังไงว่าเว็บมี redirect chain

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

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

Screaming Frog SEO Spider

เครื่องมือหลักสำหรับงานนี้ สแกนเว็บทั้งเว็บแล้วเข้าไปที่เมนู Reports แล้วเลือก Redirects ต่อด้วย Redirect Chains จะได้รายงานที่แสดงทุกเส้นทางพร้อมจำนวน hop และ URL ปลายทางสุดท้ายในไฟล์เดียว

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

Google Search Console

เปิดรายงานในหมวด Pages หรือ Indexing แล้วดูหัวข้อ Page with redirect เพื่อดูว่า Google เจอ URL ที่เป็น redirect อยู่เท่าไร และถ้ามีเส้นที่ยาวเกินขีดจำกัดจะเห็นเป็น Redirect error แยกออกมาให้

ข้อจำกัดคือรายงานนี้บอกว่ามีปัญหาแต่ไม่ได้วาดเส้นทางทั้งเชนให้ดู จึงเหมาะใช้เป็นสัญญาณเตือนและใช้ยืนยันว่า Google มองเห็นอะไร ไม่ใช่ใช้แทนการสแกน วิธีอ่านรายงานอื่นๆ ในเครื่องมือนี้อยู่ใน คู่มือใช้ Google Search Console

curl ไล่ header ทีละ hop

วิธีที่แม่นที่สุดสำหรับตรวจทีละเส้น ใช้คำสั่ง curl -IL ตามด้วย URL ที่ต้องการเช็ค แฟล็ก I คือขอเฉพาะ header และ L คือให้ตามทุก redirect จนสุดทาง ผลที่ได้จะพิมพ์ออกมาเป็นชุดๆ ให้เห็นทั้งสถานะและค่า Location ของแต่ละจังหวะ

วิธีอ่านผลคือนับจำนวนบล็อกที่ขึ้นต้นด้วยสถานะ 3xx ก่อนจะเจอ 200 นั่นคือจำนวน hop จริง ถ้าเห็นมากกว่าหนึ่งบล็อกแปลว่ามีเชน ให้ใช้คำสั่งนี้ยืนยันทุกครั้งหลังแก้ อย่าเชื่อแค่ว่าเปิดหน้าในเบราว์เซอร์แล้วเข้าได้ ถ้าผลลัพธ์ดูแปลกๆ เช่น บาง server ตอบ HEAD ต่างจาก GET หรือไม่รองรับ HEAD เลย ให้ลองใช้ curl -sIL -X GET ทวนอีกรอบ

เครื่องมือ redirect checker ออนไลน์

เว็บอย่าง httpstatus.io หรือ redirect-checker.org ใช้เช็คเส้นทางทีละ URL ได้โดยไม่ต้องติดตั้งอะไร วางลิงก์แล้วกดดูก็เห็นทุก hop พร้อมสถานะ เหมาะกับการเช็คเร็วๆ หรือส่งผลให้คนที่ไม่ได้ใช้ terminal ดู

ข้อควรระวังคืออย่าเอา URL ภายในที่เป็นระบบหลังบ้านหรือลิงก์ที่มี token ไปวางในเครื่องมือสาธารณะ ถ้าเป็นเส้นทางที่มีข้อมูลอ่อนไหวให้ใช้ curl จากเครื่องตัวเองแทน

แก้ redirect chain ยังไงให้จบจริง

หลักการมีข้อเดียวคือแก้ที่ต้นทางทุกเส้นให้ชี้ไปปลายทางสุดท้ายโดยตรง ไม่ใช่เพิ่มกฎใหม่เข้าไปอีกชั้น ถ้าเดิมเป็น A ไป B ไป C ไป D ให้แก้กฎของ A ให้ชี้ D และแก้กฎของ B ให้ชี้ D ด้วย เพราะ B กับ C อาจยังมีลิงก์จากภายนอกชี้อยู่

จุดที่หลายคนทำพลาดคือแก้แค่ต้นทางแรกแล้วปล่อยกฎกลางทางไว้ ผลคือคนที่เข้าผ่าน A ได้เส้นทางสั้นแล้ว แต่คนที่เข้าผ่าน B ยังเจอเชนเหมือนเดิม ให้คิดว่าทุก URL ในเชนคือต้นทางของตัวเอง ไม่ใช่แค่จุดผ่าน

หลังแก้แล้วต้องเก็บงานปลายทางด้วย ไม่ใช่จบที่การแก้กฎ เพราะสิ่งที่ทำให้เชนกลับมาคือลิงก์ภายในเว็บกับ sitemap ที่ยังชี้ URL เก่าอยู่

• แก้ทุก redirect ในเชนให้ชี้ปลายทางสุดท้ายเส้นเดียว ทั้งต้นทางแรกและทุกจุดกลางทาง
• รวมกฎ canonical พื้นฐานคือ HTTPS, www และ trailing slash ให้จบใน กฎเดียวที่ระดับเซิร์ฟเวอร์หรือ edge ไม่ใช่แยกเป็นสามชั้น
• อัปเดตลิงก์ภายในเว็บ เมนู และ sitemap ให้ชี้ URL ปลายทางโดยตรง ลิงก์ภายในไม่ควรวิ่งผ่าน redirect เลยสักเส้น
• ตรวจว่ากฎใหม่ไม่ได้ต่อท้ายกฎเก่าที่ยังไม่ถูกลบ โดยเฉพาะตอนย้ายโดเมนหรือรื้อโครงสร้าง URL
• เคลียร์ redirect rule เก่าที่ไม่มีใครเรียกแล้วเป็นระยะ เพื่อไม่ให้ชุดกฎบวมจนไล่ตรวจไม่ไหว
• ยิง curl -IL ยืนยันทีละเส้นหลังแก้ แล้วสแกนซ้ำทั้งเว็บอีกรอบเพื่อดูว่าไม่มีเส้นไหนตกหล่น

ป้องกันไม่ให้เชนกลับมาอีก

การแก้ครั้งเดียวไม่พอ เพราะเชนเกิดจากกระบวนการทำงาน ไม่ใช่จากบั๊ก ตราบใดที่ยังมีคนเปลี่ยน URL แล้วเพิ่มกฎใหม่โดยไม่ดูของเก่า เชนก็จะกลับมาเสมอ

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

อีกเรื่องที่ช่วยได้มากคือเก็บกฎ redirect ไว้ในที่เดียวที่ตรวจสอบได้ ถ้ากฎกระจายอยู่ทั้งในปลั๊กอิน ในไฟล์เซิร์ฟเวอร์ และที่ชั้น CDN จะไม่มีใครเห็นภาพรวมและเชนจะงอกโดยไม่มีใครรู้

• กำหนดเป็นกติกาว่าเวลาเปลี่ยน URL ต้องแก้กฎเดิมให้ชี้ปลายทางใหม่ ไม่ใช่เพิ่มกฎใหม่ต่อท้าย
• audit redirect อย่างน้อยปีละครั้ง และบังคับตรวจหลังงานย้ายโดเมนหรือรื้อ URL ทุกครั้ง
• รวมแหล่งเก็บกฎให้อยู่ที่เดียวเท่าที่ทำได้ เพื่อให้เห็นภาพรวมและรีวิวได้
• ก่อนปล่อยงานที่แตะ URL ให้สแกนหา chain ในรอบทดสอบ ไม่ใช่รอเจอบน production

สรุปและก้าวต่อไป

redirect chain คือหนี้ทางเทคนิคที่สะสมเงียบๆ ทุกครั้งที่เว็บเปลี่ยน URL มันไม่ทำให้อะไรพัง จึงไม่มีใครแก้ จนกระทั่งเว็บมีเชนหลายร้อยเส้นและลิงก์เก่าที่ชี้เข้ามาเสี่ยงส่งแรงไปไม่ถึงปลายทางมากขึ้นเรื่อยๆ

สิ่งที่ต้องจำมีสามข้อ คือเป้าหมายอยู่ที่ 1 hop ไม่ควรเกิน 3 hop และเกินราว 10 hop คือหน้าหายจากดัชนี วิธีแก้มีทางเดียวคือแก้ต้นทางทุกเส้นให้ชี้ปลายทางสุดท้ายโดยตรง ส่วนวิธีป้องกันคือทำให้การตรวจเป็นงานประจำ ไม่ใช่งานที่ทำตอนสงสัย

ถ้าเว็บของคุณผ่านการย้ายมาหลายรอบจนไล่เองไม่ไหว ทีม SEONo1 รับตรวจสุขภาพเว็บเชิงเทคนิค เพื่อสแกนหาเชนทั้งหมดพร้อมระบุว่าแต่ละเส้นควรชี้ไปไหน ให้ทีมพัฒนาเอาไปแก้ต่อได้เป็นข้อๆ