คู่มือผู้ใช้ฉบับสมบูรณ์และการใช้งานจริง
RedirectChecker.Site ไม่ใช่เพียงเครื่องมืออ่านส่วนหัว HTTP ทั่วไป แต่เป็นเครื่องมือวินิจฉัยเครือข่ายขั้นสูงที่สร้างขึ้นสำหรับผู้เชี่ยวชาญ SEO ผู้ดูแลระบบ และนักพัฒนาเว็บ การเข้าใจวิธีใช้ฟีเจอร์ต่าง ๆ อย่างถูกต้องช่วยให้คุณแก้ปัญหาการกำหนดเส้นทางที่ซับซ้อน ซึ่งส่งผลกระทบอย่างมากต่ออันดับในเครื่องมือค้นหาและประสบการณ์ผู้ใช้
1. วิธีใช้เครื่องมือตรวจสอบ: คำแนะนำทีละขั้นตอน
ป้อน URL สาธารณะให้ครบถ้วน รวมโปรโตคอลด้วย (ตัวอย่างเช่น https://example.com/old-page) เลือกตัวอย่าง User-Agent และหากจำเป็น ให้เลือกโปรไฟล์ส่วนหัว Client Hints เครื่องมือตรวจสอบจะส่งคำขอจากฝั่งเซิร์ฟเวอร์โดยใช้ส่วนหัวที่เลือก โดยไม่ได้จำลองเบราว์เซอร์เต็มรูปแบบ คุกกี้ JavaScript หรืออัตลักษณ์เครือข่ายของโปรแกรมรวบรวมข้อมูล
2. การตีความผลลัพธ์และตัวอย่างผังการเปลี่ยนเส้นทาง
คลิก ตรวจสอบ URL เพื่อดูการตอบกลับ HTTP แต่ละรายการในห่วงโซ่การเปลี่ยนเส้นทาง รหัสสถานะ เวลาคำขอที่วัดได้ และ URL Location ถัดไปเมื่อมี การตรวจสอบแต่ละครั้งติดตามการเปลี่ยนเส้นทางได้สูงสุดห้าครั้ง หากห่วงโซ่ยาวกว่านั้น การตอบกลับของ URL ถัดไปจะไม่รวมอยู่ในการตรวจสอบครั้งนั้น
3. กรณีใช้งานจริง: ตรวจหาการลดระดับ SSL
การเปลี่ยนเส้นทางอาจลดระดับ URL จาก HTTPS เป็น HTTP เครื่องมือตรวจสอบจะแจ้งเตือนเมื่อพบ URL HTTPS ที่การตอบกลับชี้ไปยัง Location แบบ HTTP ตรวจสอบปลายทางและกำหนดเส้นทาง HTTPS ที่ต้องการก่อนนำผลไปใช้
พื้นฐานทางเทคนิค: รหัสสถานะ HTTP และวิศวกรรมเครือข่าย
รหัสสถานะ HTTP อธิบายผลลัพธ์ของคำขอ ส่วนการตอบกลับ 3xx จะนำไคลเอนต์ไปยัง URL อื่น การเปลี่ยนเส้นทางแบบถาวรอาจช่วยให้เครื่องมือค้นหารวม URL เข้าด้วยกัน แต่ไม่ได้รับประกันอันดับหรือผลการจัดทำดัชนีแบบใดแบบหนึ่ง ใช้รหัสสถานะที่สอดคล้องกับความถาวรที่ต้องการ และตรวจสอบห่วงโซ่ทั้งหมดกับการตอบกลับสุดท้าย
ความแตกต่างระหว่าง 301, 302, 307 และ 308
- 301 ย้ายถาวร: ใช้เมื่อทรัพยากรถูกย้ายอย่างถาวร เครื่องมือค้นหาถือว่าการเปลี่ยนเส้นทางถาวรเป็นสัญญาณที่หนักแน่นให้ใช้ปลายทาง แต่ไม่มีการเปลี่ยนเส้นทางใดรับประกันอันดับหรือผลการจัดทำดัชนีเฉพาะเจาะจง
- 302 พบ (ชั่วคราว): แจ้งให้ไคลเอนต์ไปยัง URL อื่นชั่วคราว โดยสื่อว่า URL เดิมจะกลับมา โดยทั่วไปเครื่องมือค้นหาจะไม่ส่งต่อค่าลิงก์ถาวรผ่าน 302
- 307 เปลี่ยนเส้นทางชั่วคราว: เทียบเท่าสมัยใหม่ของ 302 ใน HTTP/1.1 จุดสำคัญคือ 307 รับประกันว่าวิธี HTTP (GET หรือ POST) จะไม่เปลี่ยนเมื่อทำตามการเปลี่ยนเส้นทาง
- 308 เปลี่ยนเส้นทางถาวร: รุ่นถาวรของ 307 สำหรับ SEO ทำงานคล้าย 301 แต่ห้ามเบราว์เซอร์เปลี่ยนคำขอ POST เป็น GET อย่างเคร่งครัด
ความเข้ากันได้ของเบราว์เซอร์กับรหัสสถานะการตอบกลับ HTTP
รหัสสถานะ HTTP เป็นสัญญาณของโปรโตคอลที่จัดการโดยระบบเครือข่ายของเบราว์เซอร์ ไม่ใช่ฟีเจอร์เบราว์เซอร์แยกต่างหาก Chrome, Edge, Firefox, Safari, Opera, Android WebView และ iPhone WebView รุ่นใหม่ประมวลผลกลุ่มสถานะมาตรฐานได้ทั้งหมด แต่สิ่งที่ผู้ใช้เห็นเมื่อเกิดข้อผิดพลาดอาจต่างกันตามเบราว์เซอร์และพร็อกซีที่คั่นกลาง
| กลุ่มการตอบกลับ HTTP | Chrome / Edge | Firefox | Safari | Opera | Android / iPhone WebView | รายละเอียดความเข้ากันได้ในการใช้งานจริง |
|---|
| ข้อมูล 1xx | รองรับ | รองรับ | รองรับ | รองรับ | รองรับในชั้นเครือข่าย | 100 และ 101 ใช้งานทั่วไปแล้ว 102 เป็นกรณีเฉพาะ/เลิกใช้ ส่วนพฤติกรรม 103 Early Hints อาจแตกต่างตามรุ่น เซิร์ฟเวอร์ และระบบตัวกลาง |
| ความสำเร็จ 2xx | รองรับ | รองรับ | รองรับ | รองรับ | รองรับ | ใช้ความหมายของโปรโตคอลร่วมกัน โดยยังคงใช้กฎเกี่ยวกับเนื้อหาตอบกลับ เช่น 204/205 ไม่มีเนื้อหา |
| การเปลี่ยนเส้นทาง 3xx | รองรับ | รองรับ | รองรับ | รองรับ | รองรับ | ไคลเอนต์ทำตาม Location ภายใต้กฎเกี่ยวกับวิธี แคช ความปลอดภัย และการนำทาง 307/308 คงวิธีเดิมไว้ ส่วน 301/302 อาจเปลี่ยน POST เป็น GET |
| ข้อผิดพลาดไคลเอนต์ 4xx | รองรับ | รองรับ | รองรับ | รองรับ | รองรับ | เข้าใจกลุ่มการตอบกลับได้ แต่การแสดงเนื้อหาจากเซิร์ฟเวอร์หรือหน้าข้อผิดพลาดของเบราว์เซอร์อาจแตกต่างกัน |
| ข้อผิดพลาดเซิร์ฟเวอร์ 5xx | รองรับ | รองรับ | รองรับ | รองรับ | รองรับ | หน้าแสดงผลของพร็อกซี พฤติกรรมการลองใหม่ และการแสดงข้อมูลวินิจฉัยอาจต่างกัน แม้รหัสสถานะจะเหมือนกัน |
| รหัสที่ไม่รู้จักในกลุ่มที่รู้จัก | การจัดการตามกลุ่ม | การจัดการตามกลุ่ม | การจัดการตามกลุ่ม | การจัดการตามกลุ่ม | การจัดการตามกลุ่ม | ไคลเอนต์ใช้ตัวเลขหลักแรกเพื่ออนุมานกลุ่มโดยรวมได้ การใช้วิธีสำรองนี้ไม่ได้ทำให้รหัสกำหนดเองมีความหมายสากล |
ตารางนี้อธิบายความเข้ากันได้ของโปรโตคอล ไม่ได้หมายความว่าการแสดงผลเหมือนกัน หรือเบราว์เซอร์ทุกเวอร์ชันจะแสดงการตอบกลับระหว่างทางในรูปแบบเดียวกัน
การละเมิดเรื่อง Cloaking และ Dynamic Rendering
Cloaking คือการแสดงเนื้อหาหรือปลายทางที่แตกต่างกันอย่างมีนัยสำคัญระหว่างเครื่องมือค้นหากับผู้ใช้ทั่วไป คุณสามารถเปรียบเทียบการตอบกลับของส่วนหัว User-Agent และ Client Hints ที่เลือกได้บนระบบที่คุณได้รับอนุญาตให้ทดสอบ โปรไฟล์ส่วนหัวเหล่านี้ไม่ได้ยืนยันตัวตนของโปรแกรมรวบรวมข้อมูลหรือระบุว่าเว็บไซต์ปฏิบัติตามนโยบายของ Google หรือไม่
คำถามที่พบบ่อย (FAQ ด้านเทคนิค)
ฉันจะตรวจสอบแท็ก canonical หลังการเปลี่ยนเส้นทางได้อย่างไร
เครื่องมือนี้ติดตามรหัสสถานะ HTTP และส่วนหัว Location แต่ไม่ได้ดาวน์โหลดหรือแยกวิเคราะห์ HTML ของหน้าปลายทาง จึงตรวจสอบ rel=canonical ไม่ได้ เปิด URL สุดท้ายและตรวจสอบว่าลิงก์ canonical ชี้ไปยังหน้าที่ต้องการและจัดทำดัชนีได้ คุณใช้ URL Inspection ใน Search Console เพื่อตรวจสอบการเลือก canonical ของ Google ได้
Google Search Central: การกำหนด canonical · Google Search Central: ระบุ URL canonical
เครื่องมือนี้ตรวจจับการเปลี่ยนเส้นทางที่ใช้ JavaScript ได้หรือไม่
ไม่ได้ เครื่องมือนี้ติดตามการตอบกลับ HTTP 3xx ที่มีส่วนหัว Location โดยไม่เรียกใช้ JavaScript หรือตรวจสอบเนื้อหาการตอบกลับเพื่อหาแท็ก meta-refresh; การตรวจสอบดังกล่าวต้องใช้เบราว์เซอร์
Google Search Central: การเปลี่ยนเส้นทางและ Google Search
Client Hints คืออะไร และเครื่องมือนี้ใช้ข้อมูลเหล่านี้อย่างไร
Client Hints คือส่วนหัวคำขอ HTTP เช่น Sec-CH-UA-Mobile และ Sec-CH-UA-Platform โปรไฟล์ที่เลือกจะเพิ่มส่วนหัวเหล่านั้นในคำขอฝั่งเซิร์ฟเวอร์ของเครื่องมือ เพื่อให้คุณเปรียบเทียบการตอบสนองของเซิร์ฟเวอร์ การทดสอบนี้ตรวจสอบส่วนหัว ไม่ใช่การจำลองเบราว์เซอร์เต็มรูปแบบหรือหลักฐานว่าคำขอมาจากเบราว์เซอร์หรือโปรแกรมรวบรวมข้อมูลใด
MDN: HTTP Client Hints
ฉันสามารถทำ 301 Redirect ต่อกันในห่วงโซ่ได้กี่ครั้ง
Google ระบุว่า Googlebot ติดตามการเปลี่ยนเส้นทางได้สูงสุด 10 ช่วง และแนะนำให้ใช้เส้นทางตรงเมื่อทำได้ หากหลีกเลี่ยงห่วงโซ่ไม่ได้ ให้ทำให้สั้น—ควรไม่เกินสามช่วงและต่ำกว่าห้าช่วง แต่ละช่วงเพิ่มคำขอ และไคลเอนต์อื่นอาจมีขีดจำกัดต่ำกว่า เลือกรหัสถาวร (301/308) หรือชั่วคราว (302/307) ให้ตรงกับการย้ายที่ตั้งใจ
คำแนะนำจาก Google Search Central.
RFC 9110: ความหมายของ HTTP, การเปลี่ยนเส้นทาง
รหัสสถานะ HTTP ใดบ่งบอกการย้ายถาวรหรือชั่วคราว
301 และ 308 หมายถึงทรัพยากรถูกย้ายถาวร ส่วน 302 และ 307 หมายถึงการเปลี่ยนเส้นทางชั่วคราว เลือกรหัสตามว่าคาดว่า URL เดิมจะกลับมาใช้หรือไม่ และให้ปลายทางเกี่ยวข้องกับคำขอต้นฉบับ
RFC 9110: ความหมายของ HTTP, การเปลี่ยนเส้นทาง
เมื่อใดควรใช้ 307 หรือ 308 แทน 301 หรือ 302
307 และ 308 คงวิธีของคำขอไว้เมื่อเปลี่ยนเส้นทาง สำหรับ 301 และ 302 ไคลเอนต์บางตัวอาจเปลี่ยนคำขอ POST เป็น GET ใช้ 307 สำหรับการย้ายชั่วคราว หรือ 308 สำหรับการย้ายถาวร เมื่อการคงวิธีและเนื้อหาคำขอเป็นสิ่งสำคัญ และตรวจสอบพฤติกรรมกับไคลเอนต์ที่บริการของคุณรองรับ
RFC 9110: ความหมายของ HTTP, 307 และ 308
เหตุใดเครื่องมือตรวจสอบจึงได้รับ 403 หรือ 429 ทั้งที่เปิดหน้าเว็บในเบราว์เซอร์ได้
เครื่องมือนี้ส่งคำขอจากฝั่งเซิร์ฟเวอร์ ซึ่งอาจแตกต่างจากเบราว์เซอร์ของคุณในด้านตำแหน่งเครือข่าย คุกกี้ การยืนยันตัวตน และส่วนหัว ไฟร์วอลล์ CDN การจำกัดอัตรา หรือกฎบอตอาจบล็อกหรือจำกัดคำขอ ตรวจสอบบันทึกเซิร์ฟเวอร์และกฎการเข้าถึง อย่าถือว่า 403 หรือ 429 จากการทดสอบครั้งเดียวเป็นหลักฐานว่าผู้เข้าชมทุกคนถูกบล็อก
RFC 9110: 403 Forbidden · RFC 6585: 429 Too Many Requests
โปรไฟล์ Googlebot และโปรแกรมรวบรวมข้อมูลค้นหาเป็นบอตที่ได้รับการยืนยันหรือไม่
ไม่ โปรไฟล์จะเปลี่ยนเฉพาะข้อความในส่วนหัว User-Agent เท่านั้น ไม่ได้ส่งคำขอจากเครือข่ายของ Google หรือโปรแกรมรวบรวมข้อมูลอื่น และไม่สามารถพิสูจน์ว่าผู้ร้องขอเป็นบอตจริง ตรวจสอบตัวตนของบอตโดยใช้กระบวนการยืนยัน IP หรือ DNS ที่ผู้ให้บริการเผยแพร่
Google Search Central: ยืนยัน Googlebot และโปรแกรมรวบรวมข้อมูลอื่นของ Google
เหตุใดโปรไฟล์ User-Agent ต่างกันจึงได้ห่วงโซ่การเปลี่ยนเส้นทางต่างกัน
เซิร์ฟเวอร์ CDN และกฎแอปพลิเคชันอาจเลือกปลายทางหรือรหัสสถานะต่างกันตามส่วนหัวคำขอ สัญญาณอุปกรณ์ ภูมิศาสตร์ การยืนยันตัวตน หรือสถานะเซสชัน เปรียบเทียบผลติดตามเหล่านี้ในฐานะตัวอย่างวินิจฉัย ซึ่งอาจไม่ตรงกับคำขอของผู้ใช้หรือบอตจริงทุกกรณี
RFC 9110: ส่วนหัว Vary และการตอบกลับตามการเจรจา
พารามิเตอร์คำค้นจะคงอยู่หรือไม่เมื่อเปลี่ยนเส้นทาง URL
ส่วนหัว Location ในการตอบกลับเปลี่ยนเส้นทางจะกำหนด URL ถัดไป เซิร์ฟเวอร์อาจคง ลบ หรือเขียนพารามิเตอร์คำค้นใหม่ เครื่องมือนี้ทำตามค่า Location ที่ได้รับ โปรดเปรียบเทียบ URL ที่แสดงแต่ละรายการเพื่อดูสิ่งที่เซิร์ฟเวอร์ส่งกลับจริง
RFC 9110: ส่วนหัวการตอบกลับ Location
เครื่องมือนี้ติดตามการเปลี่ยนเส้นทางได้กี่ครั้งต่อการตรวจสอบหนึ่งครั้ง
เครื่องมือตรวจสอบปัจจุบันติดตามการเปลี่ยนเส้นทางได้สูงสุดห้าครั้ง หากการตอบกลับหลังช่วงที่ห้าชี้ไปยัง URL อื่น การตรวจสอบอาจแสดงที่อยู่ถัดไปโดยไม่ได้ดึงข้อมูล เปิดที่อยู่นั้นเพื่อตรวจสอบใหม่ หรือทำห่วงโซ่ให้สั้นลงเพื่อตรวจดูการตอบกลับสุดท้าย
ตัวเลือก Client Hints มีผลต่อการตรวจสอบอย่างไร
ตัวเลือกนี้เพิ่มส่วนหัวคำขอ Sec-CH-* ที่เลือก เช่น ธงอุปกรณ์มือถือหรือค่าแพลตฟอร์ม ควบคู่กับข้อความ User-Agent ที่เลือกไว้ นี่เป็นตัวอย่างส่วนหัวที่กำหนดค่าได้ ไม่ใช่การจำลองพฤติกรรมเครือข่ายเต็มรูปแบบของเบราว์เซอร์ และเซิร์ฟเวอร์อาจไม่สนใจส่วนหัวเหล่านี้
MDN: HTTP Client Hints
ควรคงการเปลี่ยนเส้นทางหลังย้าย URL ไว้นานเท่าใด
คงการเปลี่ยนเส้นทางไว้นานที่สุดเท่าที่ทำได้ Google แนะนำให้คงไว้อย่างน้อยหนึ่งปีหลังย้ายเว็บไซต์ เพื่อให้เครื่องมือค้นหาประมวลผลการเปลี่ยนแปลง ผู้เข้าชมอาจยังใช้บุ๊กมาร์กและลิงก์เดิมต่อไปแม้พ้นช่วงนั้นแล้ว
Google Search Central: การย้ายเว็บไซต์และการเปลี่ยนเส้นทาง
หลังย้าย URL ควรอัปเดตอะไรบ้างนอกเหนือจากการเปลี่ยนเส้นทาง
อัปเดตลิงก์ภายใน URL canonical ของหน้าปลายทาง คำกำกับ hreflang หากใช้ และแผนผังเว็บไซต์ XML ให้ชี้ไปยัง URL ใหม่ ใช้หน้าทดแทนที่เกี่ยวข้อง จากนั้นตรวจสอบว่าการเปลี่ยนเส้นทางนำไปยังปลายทางโดยตรงและสม่ำเสมอ
Google Search Central: การย้ายเว็บไซต์และการเปลี่ยนเส้นทาง