เครื่องมือตรวจสอบห่วงโซ่การเปลี่ยนเส้นทาง URL
ป้อน URL เพื่อติดตามห่วงโซ่การเปลี่ยนเส้นทางและวิเคราะห์รหัสสถานะ HTTP การเปลี่ยนเส้นทาง และเวลาโหลดรวมตลอดการเดินทาง
วิธีใช้ เครื่องมือตรวจสอบห่วงโซ่การเปลี่ยนเส้นทาง URL
- 1
ป้อน URL
พิมพ์หรือวาง URL แบบเต็มที่คุณต้องการตรวจ รวมถึง http:// หรือ https://
- 2
ตรวจการ redirect
คลิก "ตรวจ Redirect" เพื่อติดตาม URL และตามทุก hop ไปจนถึงปลายทางสุดท้าย
- 3
อ่าน redirect chain
ตรวจดูแต่ละขั้น รหัสสถานะ HTTP ของมัน (เช่น 301 หรือ 302) และเวลารวมตลอดทั้ง chain
- 4
ดำเนินการตามการประเมิน SEO
ใช้แผง "ผลกระทบ SEO" ซึ่งทำเครื่องหมาย hop ที่มากเกินไป chain ที่ช้า redirect ชั่วคราว และรหัสข้อผิดพลาด เพื่อแก้ปัญหา
ทำความเข้าใจการเปลี่ยนเส้นทางและเหตุผลที่ห่วงโซ่เป็นปัญหา
การเปลี่ยนเส้นทางคืออะไร และห่วงโซ่ก่อตัวขึ้นได้อย่างไร
การเปลี่ยนเส้นทาง (redirect) คือคำสั่งจากเซิร์ฟเวอร์ที่บอกเบราว์เซอร์ว่า URL ที่ร้องขอไปนั้นได้ย้ายไปอยู่ที่อื่นแล้ว เซิร์ฟเวอร์จะตอบกลับด้วยรหัสสถานะกลุ่ม 3xx พร้อมส่วนหัว Location ที่ระบุที่อยู่ใหม่ และเบราว์เซอร์จะร้องขอที่อยู่นั้นแทนโดยอัตโนมัติ ห่วงโซ่การเปลี่ยนเส้นทาง (redirect chain) จะก่อตัวขึ้นเมื่อปลายทางของการเปลี่ยนเส้นทางหนึ่งกลับเป็นการเปลี่ยนเส้นทางอีกต่อหนึ่ง กล่าวคือเบราว์เซอร์ขอ A แล้วถูกส่งไป B จากนั้น B ส่งต่อไป C และกว่าจะพบหน้าเพจจริงก็ที่ C นั่นเอง ทุกลูกศรในเส้นทางนี้คือการเดินทางไป-กลับเซิร์ฟเวอร์แยกกันคนละครั้ง
โดยทั่วไปห่วงโซ่มักสะสมขึ้นโดยไม่ตั้งใจเมื่อเวลาผ่านไป เว็บไซต์ย้ายจาก http ไป https ต่อมาเปลี่ยนจาก non-www ไป www แล้วจึงปรับโครงสร้างเส้นทาง URL และหากแต่ละการเปลี่ยนแปลงถูกซ้อนทับลงบนของเดิมโดยไม่รวบให้เป็นหนึ่งเดียว ลิงก์เก่าเพียงลิงก์เดียวก็อาจเด้งผ่านสามหรือสี่ hop ก่อนจะถึงปลายทาง เครื่องมือตรวจสอบนี้จะติดตามทุก hop และแสดงเส้นทางทั้งหมด คุณจึงเห็นได้ชัดเจนว่าห่วงโซ่ยืดยาวขึ้นเพียงใด
301 กับ 302: แบบถาวรและแบบชั่วคราว
รหัสการเปลี่ยนเส้นทางที่พบบ่อยที่สุดสองตัวนี้มีความหมายต่างกันมาก 301 คือการเปลี่ยนเส้นทางแบบถาวร มันบอกเบราว์เซอร์และเครื่องมือค้นหาว่าการย้ายครั้งนี้เป็นที่สิ้นสุด จึงควรอัปเดตบุ๊กมาร์ก ส่งต่อสัญญาณอันดับที่ URL เก่าสะสมไว้ไปยัง URL ใหม่ และจัดทำดัชนีให้กับปลายทาง ส่วน 302 คือการเปลี่ยนเส้นทางแบบชั่วคราว มันบอกว่า URL เดิมจะกลับมา เครื่องมือค้นหาจึงมักเก็บ URL เดิมไว้ในดัชนีและระมัดระวังในการถ่ายโอนสัญญาณอันดับ การใช้ 302 กับการย้ายที่จริง ๆ แล้วเป็นแบบถาวรคือความผิดพลาด SEO ที่พบเห็นได้บ่อย ซึ่งทำให้ค่าน้ำหนักลิงก์ (link equity) ค้างอยู่ที่ URL เก่า
หลักการง่าย ๆ คือ หากการเปลี่ยนแปลงเป็นแบบถาวร เช่น หน้าที่เลิกใช้แล้วหรือโดเมนที่ย้ายไป ให้ใช้ 301 หากเป็นแบบชั่วคราวจริง ๆ เช่น โปรโมชันตามฤดูกาล การทดสอบ A/B หรือหน้าแจ้งปิดปรับปรุง ให้ใช้ 302 เมื่อไม่แน่ใจเกี่ยวกับการเปลี่ยนเส้นทางที่จะอยู่ยาวนาน 301 เป็นตัวเลือกที่ถูกต้องแทบทุกครั้ง
307 และ 308: รหัสยุคใหม่ที่เข้มงวด
ต่อมา HTTP ได้เพิ่ม 307 และ 308 เข้ามาเพื่อขจัดความกำกวมแบบเดิม รหัส 301 และ 302 ดั้งเดิมถูกนำไปใช้กันอย่างแพร่หลายในแบบที่อาจเปลี่ยนคำขอ POST ให้กลายเป็น GET เมื่อมีการเปลี่ยนเส้นทาง ซึ่งมักสะดวกสำหรับการย้ายหน้าเพจ แต่ผิดสำหรับการส่งฟอร์มและ API 308 คือการเปลี่ยนเส้นทางแบบถาวรเช่นเดียวกับ 301 แต่รับประกันว่าเมท็อด HTTP และเนื้อหา (body) จะถูกรักษาไว้ ส่วน 307 คือคู่ขนานแบบชั่วคราวของ 302 ที่มีการรับประกันแบบเดียวกัน สำหรับการเปลี่ยนเส้นทางหน้าเพจทั่วไป ผลทาง SEO ในทางปฏิบัติของ 308 จะเหมือนกับ 301 และ 307 เหมือนกับ 302
คุณจะพบ 307 ส่วนใหญ่ในสองที่ ได้แก่ การเปลี่ยนเส้นทางที่เกิดจาก HSTS preloading เมื่อเบราว์เซอร์ยกระดับ http ไปเป็น https ภายในตัวเอง และในทราฟฟิก API ที่การรักษาเมท็อดของคำขอเป็นเรื่องสำคัญ สำหรับ URL ของเนื้อหา การยึดติดกับ 301 สำหรับการย้ายแบบถาวรยังคงเป็นตัวเลือกตามธรรมเนียมที่เข้าใจกันดี
เหตุใดห่วงโซ่และวงวนจึงเป็นอันตราย
ทุก hop ในห่วงโซ่คือวงจรคำขอ-การตอบกลับเต็มรอบหนึ่งครั้ง และความหน่วงนั้นก็สะสมพอกพูน โดยเฉพาะบนเครือข่ายมือถือที่มีเวลาไป-กลับสูง ซึ่งการเปลี่ยนเส้นทางเพิ่มแต่ละครั้งอาจเพิ่มเวลาหลายร้อยมิลลิวินาทีก่อนที่ผู้ใช้จะได้เห็นอะไรเลย ห่วงโซ่ยังสิ้นเปลือง crawl budget อีกด้วย เครื่องมือค้นหามีขีดจำกัดในการส่งคำขอต่อเว็บไซต์หนึ่ง ๆ และการใช้มันไปกับการตาม A ไป B ไป C ไป D หมายความว่าเหลือทรัพยากรน้อยลงสำหรับรวบรวมเนื้อหาจริง นอกจากนี้ยังมีหลักฐานว่าสัญญาณอันดับอาจกระจัดกระจายหายไปบ้างตลอดห่วงโซ่ที่ยาว แทนที่จะไหลไปยังหน้าสุดท้ายอย่างหมดจด
วงวนการเปลี่ยนเส้นทาง (redirect loop) คือกรณีที่ผิดปกติอย่างรุนแรง คือ A ชี้ไป B และ B ชี้กลับมาที่ A เบราว์เซอร์จึงวนซ้ำไปเรื่อย ๆ จนยอมแพ้และแสดงข้อผิดพลาดอย่าง ERR_TOO_MANY_REDIRECTS ทำให้เข้าถึงหน้าเพจไม่ได้เลย เครื่องมือตรวจสอบจะทำเครื่องหมายห่วงโซ่ที่ยาวเกินไป ห่วงโซ่ที่ช้า การเปลี่ยนเส้นทางชั่วคราวที่อาจไม่ได้ตั้งใจ และรหัสสถานะข้อผิดพลาดในเส้นทาง โหมดความล้มเหลวแต่ละแบบเหล่านี้จึงถูกเผยให้เห็นแทนที่จะถูกซ่อนไว้
ปรับห่วงโซ่ให้เหลือ hop เดียว
วิธีแก้ห่วงโซ่คือทำให้ทุกจุดเริ่มต้นเปลี่ยนเส้นทางไปยังปลายทางสุดท้ายโดยตรงในเพียง hop เดียว หาก A ไป B ไป C คุณก็ปรับกฎของ A ให้ไป C ตรง ๆ ตัดจุดแวะพัก B ออก บน Apache นั่นหมายถึงการแก้กฎการเปลี่ยนเส้นทางใน .htaccess หรือไฟล์ตั้งค่าเซิร์ฟเวอร์ของคุณเพื่อให้ต้นทางจับคู่กับเป้าหมายสุดท้าย ส่วนบน Nginx หมายถึงการอัปเดตไดเรกทิฟ rewrite หรือ return เป้าหมายคือไม่ให้ปลายทางของการเปลี่ยนเส้นทางใดเป็นการเปลี่ยนเส้นทางเสียเอง
ตรวจสอบการเปลี่ยนเส้นทางเป็นระยะ ๆ เพราะห่วงโซ่จะค่อย ๆ คืบกลับมาเมื่อเว็บไซต์พัฒนาไป หลังการย้ายระบบ การเปิดใช้ HTTPS หรือการปรับโครงสร้าง URL ใด ๆ ให้ติดตาม URL ทางเข้าที่สำคัญที่สุดของคุณอีกครั้ง และยืนยันว่าแต่ละ URL นำไปสู่หน้า canonical ด้วย 301 เพียงครั้งเดียว ให้ความสำคัญเป็นพิเศษกับ URL ที่ปรากฏในแบ็กลิงก์จากภายนอก เพราะ URL เหล่านั้นแบกค่าน้ำหนักลิงก์ไว้มากที่สุดและได้ประโยชน์มากที่สุดจากการเปลี่ยนเส้นทางตรง ๆ ที่หมดจด
การทำให้เป็นรูปแบบหลัก (Canonicalization): การเปลี่ยนเส้นทางที่ทุกเว็บไซต์ต้องมี
ปัญหาการเปลี่ยนเส้นทางส่วนใหญ่สืบย้อนกลับไปที่ canonicalization ซึ่งคือแนวปฏิบัติในการรวมทุกรูปแบบที่แตกต่างกันของ URL ให้เหลือเป็นรูปแบบหลัก (canonical) เพียงรูปแบบเดียว สี่มิติที่ว่าได้แก่ โปรโตคอล (http กับ https) โฮสต์ (www กับ non-www) เครื่องหมายทับท้าย (เส้นทางที่มีหรือไม่มีสแลชปิดท้าย) และตัวพิมพ์เล็กใหญ่ หากเว็บไซต์ของคุณเข้าถึงได้ในทุกการผสมผสานของสิ่งเหล่านี้ เครื่องมือค้นหาจะเห็นเป็นเนื้อหาซ้ำซ้อน และสัญญาณลิงก์ของคุณก็จะแตกกระจายไปตามรูปแบบต่าง ๆ วิธีแก้คือชุดของการเปลี่ยนเส้นทาง 301 ที่ยุบแต่ละรูปแบบให้รวมมาที่ URL ที่ต้องการเพียงตัวเดียว
รายละเอียดสำคัญคือการรวมสิ่งเหล่านี้ให้เป็น hop เดียวแทนที่จะเรียงต่อกันเป็นห่วงโซ่ การส่ง http://example.com ไป https://example.com แล้วไป https://www.example.com คือการเปลี่ยนเส้นทางสองครั้งทั้งที่ครั้งเดียวก็พอ ให้ตั้งค่ากฎเพื่อให้คำขอที่ไม่ใช่ canonical ใด ๆ ไม่ว่าจะผิดกี่มิติก็ตาม ไปถึง URL ที่เป็น canonical อย่างสมบูรณ์ในการเปลี่ยนเส้นทาง 301 เพียงครั้งเดียว นั่นคือผลลัพธ์ที่หมดจดที่สุดเท่าที่จะเป็นไปได้ และเป็นผลลัพธ์ที่เครื่องมือตรวจสอบติดป้ายว่าเป็นแนวปฏิบัติที่ดี
การเปลี่ยนเส้นทางแบบ Meta refresh และ JavaScript
ไม่ใช่ทุกการเปลี่ยนเส้นทางจะเกิดขึ้นที่ระดับ HTTP การเปลี่ยนเส้นทางแบบ meta refresh ใช้แท็ก HTML meta http-equiv="refresh" เพื่อส่งเบราว์เซอร์ไปที่อื่นหลังจากหน่วงเวลา ส่วนการเปลี่ยนเส้นทางแบบ JavaScript จะเปลี่ยน window.location จากสคริปต์ ทั้งสองแบบใช้งานได้สำหรับผู้ใช้ แต่ด้อยกว่าในแง่ SEO กล่าวคือ ช้ากว่า เครื่องมือค้นหาให้ความเชื่อถือน้อยกว่า 301 ฝั่งเซิร์ฟเวอร์ และ meta refresh ที่หน่วงเวลาอาจสะดุดหูสะดุดตาหรือถูกตีตราว่าเป็นประสบการณ์ที่ไม่ดีได้ ทั้งสองแบบยังจะไม่ปรากฏในการติดตามการเปลี่ยนเส้นทางระดับ HTTP เพราะการเปลี่ยนเส้นทางถูกตัดสินหลังจากเนื้อหาของหน้าเพจโหลดเสร็จแล้ว
เมื่อใดที่คุณควบคุมเซิร์ฟเวอร์ได้ ให้เลือกใช้ HTTP 301 จริง ๆ มากกว่า meta refresh หรือการเปลี่ยนเส้นทางแบบ JavaScript สงวนการเปลี่ยนเส้นทางฝั่งไคลเอ็นต์ไว้สำหรับกรณีที่คุณไม่สามารถตั้งค่าเซิร์ฟเวอร์ได้จริง ๆ เท่านั้น เนื่องจากเครื่องมือตรวจสอบนี้ติดตามการตอบกลับกลุ่ม 3xx ที่ออกโดยเซิร์ฟเวอร์ หน้าเพจที่ดูเหมือนจะเปลี่ยนเส้นทางในเบราว์เซอร์แต่กลับแสดงเป็น 200 โดยตรงที่นี่ ถือเป็นสัญญาณชัดเจนว่าการเปลี่ยนเส้นทางกำลังเกิดขึ้นที่ฝั่งไคลเอ็นต์ และควรย้ายไปไว้ที่เซิร์ฟเวอร์
คำถามที่พบบ่อย
ตัวตรวจ redirect chain แสดงอะไรให้ฉัน
ทำไม redirect chain จึงไม่ดีต่อ SEO
redirect 301 กับ 302 ต่างกันอย่างไร
ฉันต้องป้อน URL แบบเต็มพร้อม http หรือ https ไหม
เครื่องมือนี้ฟรีไหม และมันส่ง URL ไปยังเซิร์ฟเวอร์หรือไม่
เครื่องมือที่เกี่ยวข้อง
ทำงานต่อด้วยเครื่องมือที่มีประโยชน์เหล่านี้