Softonic

ตัวตรวจสอบการเปลี่ยนเส้นทาง

ขั้นตอน 1 / 3
ถัดไป

วาง URL แล้วตัวตรวจสอบจะติดตามสายการเปลี่ยนเส้นทาง HTTP ทีละช่วงต่อ โดยแสดงหนึ่งแถวต่อหนึ่งขั้น พร้อมรหัสสถานะ (301, 302, 303, 307 หรือ 308) ค่า Location ที่ชี้ไป และเซิร์ฟเวอร์กับประเภทเนื้อหาที่รายงานมา ระบบจะหยุดที่การตอบกลับแรกที่ไม่ใช่ 3xx หรือเมื่อถึงขีดจำกัดช่วงต่อที่คุณตั้งไว้ และจะทำเครื่องหมายว่าเป็นลูปหากมี URL ชี้กลับไปยังอันที่เคยเยี่ยมมาแล้ว งาน SEO ขึ้นอยู่กับการติดตามนี้: 302 ที่เงียบเพียงตัวเดียวในสายหลายช่วงต่ออาจทำให้ PageRank รั่วไหล และสายที่ยาวจะสิ้นเปลืองงบการรวบรวมข้อมูลที่ Google จะไม่คืนให้

วิธีติดตามสายการเปลี่ยนเส้นทาง

  1. 1

    ป้อน URL เริ่มต้น

    URL ใดก็ได้ ทั้ง HTTPS หรือ HTTP มีหรือไม่มี `www` ก็ได้ หากคุณละสคีมไว้ ตัวตรวจสอบจะเติมให้

  2. 2

    ตั้งขีดจำกัดช่วงต่อ

    เลือกว่าจะติดตามการเปลี่ยนเส้นทางกี่ครั้ง ตั้งแต่ 1 ถึง 20 ค่าเริ่มต้นจะหยุดสายที่พุ่งเกินหรือวนลูปตั้งแต่เนิ่นๆ

  3. 3

    เรียกใช้การตรวจสอบ

    แต่ละช่วงต่อจะถูกร้องขอตามลำดับและติดตามไปจนกว่าจะได้การตอบกลับที่ไม่ใช่ 3xx หรือถึงขีดจำกัด

  4. 4

    อ่านสายการเปลี่ยนเส้นทาง

    แต่ละแถวแสดงหมายเลขช่วงต่อ รหัสสถานะและประเภท (ถาวร ชั่วคราว OK ข้อผิดพลาดฝั่งไคลเอ็นต์ ข้อผิดพลาดฝั่งเซิร์ฟเวอร์ หรือลูป) URL และปลายทางที่มันเปลี่ยนเส้นทางไป

รหัสสถานะการเปลี่ยนเส้นทางและความหมาย

RFC 7231 และ RFC 7538 (สำหรับ 308) กำหนดความหมายไว้ ความแตกต่างระหว่างทั้งสองมีผลต่อ SEO การแคช และการที่เบราว์เซอร์จะส่ง POST ซ้ำหรือถอยกลับไปใช้ GET

รหัส ชื่อ ถาวร? รักษาเมท็อด? แคชได้โดยค่าเริ่มต้น?
301 Moved Permanently ใช่ ในอดีตไม่ ใช่
302 Found ไม่ ในอดีตไม่ เฉพาะเมื่อส่วนหัวอนุญาต
303 See Other ไม่ บังคับเป็น GET ไม่
307 Temporary Redirect ไม่ ใช่ เฉพาะเมื่อส่วนหัวอนุญาต
308 Permanent Redirect ใช่ ใช่ ใช่

สำหรับ SEO นั้น 301 และ 308 จะรวม PageRank ไปยังปลายทาง ส่วน 302 และ 307 ไม่รวม (Google ถือว่าเป็นแบบชั่วคราวและเก็บ URL ต้นทางไว้ในดัชนี)

สายการเปลี่ยนเส้นทางที่ดีควรเป็นอย่างไร

  • 1 ช่วงต่อถือว่าดี URL เก่าไปยัง URL ใหม่ด้วย 301 เพียงตัวเดียว ไม่สูญเสียค่าลิงก์
  • 2 ช่วงต่อพอรับได้ หากช่วงหนึ่งเป็นการยกระดับจาก HTTP เป็น HTTPS และอีกช่วงเป็นการปรับ www ให้เป็นมาตรฐาน
  • 3 ช่วงต่อขึ้นไปเป็นสัญญาณเตือน แต่ละช่วงต่อเพิ่มความหน่วง และ Google ระบุว่าสายที่ยาวมากอาจถูกละทิ้ง ควรรวมสายไว้ที่เซิร์ฟเวอร์เพื่อให้ผู้ใช้และบอตรวบรวมข้อมูลไปถึงปลายทางในขั้นเดียว

ตัวตรวจสอบนี้ติดตามอะไรและไม่ติดตามอะไร

ตัวตรวจสอบติดตามการเปลี่ยนเส้นทาง HTTP ฝั่งเซิร์ฟเวอร์ คือการตอบกลับใดก็ตามที่มีสถานะ 3xx และส่วนหัว Location มันไม่รันหน้าเว็บ ดังนั้นการเปลี่ยนเส้นทางอีกสองประเภทจึงไม่ถูกติดตาม:

  • Meta refresh แท็ก <meta http-equiv="refresh" content="0; url=..."> เป็นการเปลี่ยนเส้นทางระดับ HTML ที่เขียนอยู่ในเนื้อหน้า ไม่ใช่ส่วนหัว HTTP จึงปรากฏที่นี่เป็นการตอบกลับ 200 ตามปกติ
  • การเปลี่ยนเส้นทางด้วย JavaScript window.location = '...' ทำงานในเบราว์เซอร์หลังจากหน้าโหลดเสร็จ คำขอฝั่งเซิร์ฟเวอร์จึงไม่มีวันเห็นมัน

หาก URL เปลี่ยนเส้นทางผ่านวิธีใดวิธีหนึ่งเหล่านี้เท่านั้น ให้ใช้เครื่องมือที่ใช้เบราว์เซอร์แบบไม่มีส่วนติดต่อ (headless) เพื่อดูปลายทางสุดท้าย

การแก้จุดบกพร่องของสายที่เสีย

สายที่เสียส่วนใหญ่มาจากหนึ่งในสามสาเหตุ: ลูปการเปลี่ยนเส้นทาง (ช่วงต่อชี้กลับไปยัง URL ที่เคยเยี่ยมมาแล้ว) www ที่หายไปแล้วเปลี่ยนเส้นทางอีก หรือความไม่สอดคล้องของเครื่องหมายทับท้าย ที่ทำให้ /page และ /page/ เด้งไปมาระหว่างกัน ตัวตรวจสอบจะหยุดและทำเครื่องหมายว่าเป็นลูปเมื่อ URL ซ้ำ

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

ไม่ มันติดตามการเปลี่ยนเส้นทาง HTTP ฝั่งเซิร์ฟเวอร์ (สถานะ 3xx พร้อมส่วนหัว Location) การเปลี่ยนเส้นทางแบบ meta refresh และ JavaScript ทำงานภายในหน้าเว็บหลังจากโหลดเสร็จ คำขอฝั่งเซิร์ฟเวอร์จึงไม่เห็นมัน สำหรับกรณีเหล่านั้นให้ใช้เครื่องมือที่ใช้เบราว์เซอร์แบบไม่มีส่วนติดต่อ (headless)

คุณติดตามได้ตั้งแต่ 1 ถึง 20 ช่วงต่อ โดยค่าเริ่มต้นคือ 10 ตัวตรวจสอบจะหยุดที่ขีดจำกัดของคุณ หรือเมื่อ URL ชี้กลับไปยังอันที่เคยเยี่ยมมาแล้ว ลูปการเปลี่ยนเส้นทางจึงไม่สามารถทำงานไปได้ตลอด

ได้เฉพาะเมื่อมันแปลงชื่อได้จากอินเทอร์เน็ตสาธารณะ URL ที่อยู่หลัง VPN ใช้การยืนยันตัวตนพื้นฐานแบบ HTTP หรืออยู่บน localhost (และที่อยู่ส่วนตัวอื่นๆ) ตัวตรวจสอบเข้าถึงไม่ได้

สำหรับแต่ละช่วงต่อ: หมายเลข รหัสสถานะ HTTP และประเภท (ถาวร ชั่วคราว OK ข้อผิดพลาดฝั่งไคลเอ็นต์ ข้อผิดพลาดฝั่งเซิร์ฟเวอร์ หรือลูป) URL ที่ร้องขอ ค่า Location ที่มันเปลี่ยนเส้นทางไป และเซิร์ฟเวอร์กับประเภทเนื้อหาที่รายงานในการตอบกลับ

ไม่ แต่ละคำขอจะทำและส่งผลลัพธ์กลับไปยังคุณโดยตรง URL ที่คุณวางจะไม่ถูกบันทึกไว้

เครื่องมือที่เกี่ยวข้อง

ตัวสร้างลิงก์ UTM

สร้าง URL ติดตามแคมเปญด้วยพารามิเตอร์ UTM source, medium, campaign, term และ content ลิงก์สะอาดที่เข้ารหัส URL แล้ว พร้อมใช้สำหรับโฆษณาและจดหมายข่าว

ตัววิเคราะห์ UTM

วาง URL แคมเปญแล้วอ่านแท็ก UTM มาตรฐานทั้งห้าตัว (source, medium, campaign, term และ content) พร้อมค่าที่ถอดรหัสแล้วในแต่ละตัว วิธีที่รวดเร็วในการตรวจสอบลิงก์ติดตามก่อนส่ง

ตัวอย่าง SERP

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

เครื่องมือวิเคราะห์ส่วนหัวความปลอดภัย

วางส่วนหัวการตอบกลับ HTTP ของคุณ แล้วรับคำแนะนำแบบจัดลำดับความสำคัญเกี่ยวกับส่วนหัวความปลอดภัยที่สำคัญ: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, Referrer-Policy และอื่น ๆ

เครื่องสร้าง Sitemap

วางรายการ URL ของคุณแล้วสร้าง XML sitemap ที่ถูกต้องพร้อม changefreq, priority และ lastmod ตามต้องการ พร้อมบันทึกและส่งไปยัง Search Console

เครื่องตรวจสอบความสามารถในการจัดทำดัชนี (Indexability Checker)

ตรวจสอบว่า URL นั้นสามารถถูกดักจับโดยระบบดัชนีได้หรือไม่ โดยพิจารณาจากไฟล์ robots.txt, meta robots, X-Robots-Tag, สัญญาณ canonical และสถานะ HTTP

เครื่องมือนี้มีให้บริการในภาษาอื่น