Kiểm tra Redirect
Check redirect cho mọi URL hoặc link rút gọn: mã trạng thái của từng bước (301, 302, 307, 308 hoặc meta refresh) và ý nghĩa của nó, trỏ đến đâu và mất bao lâu, theo dõi tới 20 bước như trình duyệt, kèm điểm Googlebot dừng lại và cả bốn phiên bản http/https và www.
Tên miền trần bắt đầu từ https://. Gõ http:// để kiểm tra cả bước chuyển từ HTTP sang HTTPS.
Công cụ kiểm tra redirect cho biết điều gì?
Công cụ kiểm tra redirect hỏi một URL như trình duyệt sẽ làm, rồi theo từng header Location nhận được, từng bước một, cho đến khi một trang phản hồi. Ở mỗi bước bạn thấy mã trạng thái, nó trỏ đến đâu, mất bao lâu và mạng nào đã phản hồi.
Công cụ này đo thời gian từng bước: DNS, kết nối, TLS và byte đầu tiên cho kết nối mới, chỉ byte đầu tiên khi bước đó dùng lại kết nối đang mở tới cùng host, như trình duyệt. Nó giữ cookie theo từng host như trình duyệt, đọc trang cuối để tìm meta refresh, thẻ canonical và noindex, và đánh dấu nơi Googlebot sẽ bỏ cuộc.
- 13301Vĩnh viễnPOST có thể thành GET4368 mili giâyhttp://google.com/
- 2302Tạm thờiPOST có thể thành GET537 mili giâyhttp://www.google.com/
- 3200CuốiOK393 mili giâyhttps://www.google.com/?gws_rd=ssl“Google”
- 1Tổng thời gian của mọi bước cộng lại, trước khi trang có thể bắt đầu.
- 2Ngân sách bước mỗi redirect một ô; giới hạn của Googlebot là 10, của trình duyệt là 20.
- 3Trang của từng bước biểu tượng mới nghĩa là link đã rời khỏi website.
- 4Trạng thái theo màu của loại, và ý nghĩa của nó bằng lời.
- 5Thời gian đi đâu DNS, kết nối, TLS và byte đầu tiên trên cùng một đồng hồ.
Làm sao để check 301 redirect?
Dán URL vào ô trên và chọn Kiểm tra redirect: công cụ hỏi URL đó, theo mọi redirect đến trang cuối và gọi tên trạng thái của từng bước. 301 hoặc 308 hiện màu xanh lá là vĩnh viễn; 302, 303 hoặc 307 hiện màu hổ phách là tạm thời. Tên miền trần bắt đầu từ https://; gõ http:// để kiểm tra luôn bước từ HTTP sang HTTPS.
Phần kết luận tóm tắt chuỗi bằng lời, cột xanh navy vẽ nó từng bước trên cùng một đồng hồ, và chế độ xem Chuỗi liệt kê yêu cầu của từng bước, dòng trạng thái, Location như được gửi và như đã phân giải (cho phép đường dẫn tương đối), cùng mọi header của nó.
Kiểm tra redirect URL: một link, mọi bước
Mọi URL hoặc link rút gọn, tới 20 bước, kèm mạng, phiên bản TLS và phiên bản HTTP của từng bước, và bốn lối vào http/https và www được kiểm tra bên cạnh.
Check redirect hàng loạt: tới 50 URL
Chuyển sang Hàng loạt và dán danh sách di chuyển, mỗi dòng một URL: một bảng gồm các bước, trạng thái cuối, URL cuối và kết luận, sẵn sàng tải về dạng CSV.
Thử redirect như Googlebot, iPhone hoặc Bingbot
Chọn user agent dưới ô nhập: một số website gửi crawler hoặc điện thoại đến nơi khác, và chuỗi cho thấy chính xác agent đó nhận được gì.
Kiểm tra trạng thái HTTP cho mọi bước
Mỗi mã trạng thái bằng lời, kèm ý nghĩa với trình duyệt và với Google. Tường chặn bot được gọi là bị chặn, không phải trang hỏng, và các lỗi 52x của Cloudflare được gọi là của Cloudflare.

Kết luậnURL kết thúc ở đâu, sau bao nhiêu bước, và mỗi bước là vĩnh viễn hay tạm thời, bằng lời.Ngân sách bướcMỗi redirect một ô theo màu của loại, so với 10 của Googlebot và 20 của trình duyệt.Trạng thái từng bướcMã như máy chủ gửi, và ý nghĩa của nó: vĩnh viễn hay tạm thời, và điều gì xảy ra với POST.Thời gian đi đâuDNS, kết nối, TLS và byte đầu tiên của từng bước, trên cùng một đồng hồ từ yêu cầu đầu tiên đến trang.301 và 302: nên dùng redirect nào?
Dùng 301 (hoặc 308) khi một trang đã chuyển vĩnh viễn, và 302 (hoặc 307) chỉ khi nó sẽ quay lại. Mã này cho trình duyệt và công cụ tìm kiếm biết nên giữ URL nào (RFC 9110 §15.4).
Với Google, 301 và 308 là tín hiệu cho thấy đích nên là URL chính tắc, tức URL hiển thị trong kết quả; 302, 303 và 307 thì không, nên kết quả vẫn giữ URL cũ (Google Search Central). 302 không bị bỏ qua: Google vẫn đi theo nó và coi nó là tín hiệu yếu để xử lý đích (tài liệu crawler của Google); đích vẫn có thể được lập chỉ mục nếu các tín hiệu chuẩn hoá khác trỏ đến nó. Bing chỉ yêu cầu dùng 302 cho thay đổi ngắn hơn hai ngày.
Trình duyệt cache 301 và 308 theo mặc định, nên một redirect vĩnh viễn mà bạn gỡ đi có thể vẫn kẹt trong trình duyệt của khách truy cập. 307 và 308 giữ nguyên phương thức yêu cầu; 301 và 302 có thể biến POST thành GET, còn 303 luôn làm vậy.
| Mã | Vĩnh viễn | Với POST | Trình duyệt cache | Tín hiệu Google | Dùng cho |
|---|---|---|---|---|---|
| 301Moved Permanently | vĩnh viễn | có thể thành GET | có | mạnh | trang đã chuyển vĩnh viễn |
| 308Permanent Redirect | vĩnh viễn | giữ nguyên | có | mạnh | form hoặc API đã chuyển vĩnh viễn |
| 302Found | tạm thời | có thể thành GET | không | yếu | việc chuyển ngắn hạn (Bing: dưới 2 ngày) |
| 303See Other | tạm thời | luôn là GET | không | yếu | trang hiện sau khi gửi form |
| 307Temporary Redirect | tạm thời | giữ nguyên | không | yếu | việc chuyển tạm thời phải giữ POST |
| meta 0meta refresh tức thì | vĩnh viễn | GET | — | mạnh | khi máy chủ không thể redirect |
| meta 5meta refresh có độ trễ | tạm thời | GET | — | yếu | tránh: khách thấy trang cũ trước |
Refresh.Kiểm tra chuỗi redirect: bao nhiêu bước là quá nhiều?
Hơn ba. Chuỗi là nhiều redirect liên tiếp, chẳng hạn từ http:// sang https://, rồi sang www, rồi sang đường dẫn mới. Google khuyên nên link thẳng đến URL cuối, hoặc giữ chuỗi từ 3 bước trở xuống và luôn dưới 5 (Google Search Central).
Googlebot theo tối đa 10 bước rồi bỏ cuộc, và Search Console báo "Redirect error" (tài liệu crawler của Google). Chrome và Firefox theo tới 20 bước trước khi hiện ERR_TOO_MANY_REDIRECTS. Mỗi bước là thêm một vòng đi về trước khi trang có thể bắt đầu, nên hãy cập nhật link nội bộ để trỏ thẳng đến URL cuối.
- Google khuyên: 3 trở xuống
- vẫn được theo, chậm hơn
- Googlebot không bao giờ thấy các bước này: Search Console hiện “Redirect error”
- quá 20:
ERR_TOO_MANY_REDIRECTS
Làm sao để sửa vòng lặp redirect?
Tìm hai quy tắc đang mâu thuẫn và làm cho chúng thống nhất về một URL cuối. Vòng lặp là chuỗi quay lại một URL đã hỏi; trình duyệt cứ đi vòng cho đến 20 redirect rồi hiện ERR_TOO_MANY_REDIRECTS.
Hầu hết vòng lặp đến từ một quy tắc thêm www gặp quy tắc khác bỏ nó đi, hoặc từ quy tắc HTTP và HTTPS xung đột nhau sau CDN: CDN nói chuyện với máy chủ qua http://, máy chủ redirect sang https://, và CDN lại hỏi qua http://. Trình duyệt nhớ redirect vĩnh viễn, nên hãy thử bản sửa trong cửa sổ ẩn danh.
Cách công cụ kiểm tra vòng lặp redirect phát hiện vòng lặp
Một URL bị hỏi lần thứ hai mà không có cookie mới nào kể từ đó là vòng lặp: lộ trình vẽ nó quay lại bước bị lặp và dừng ở đó, thay vì đi vòng tới 20. Website đặt cookie rồi redirect về chính nó sẽ nhận lại cookie, như trình duyệt, nên bước đăng nhập không bị nhầm là vòng lặp.
ERR_TOO_MANY_REDIRECTS · sau 20
Meta refresh và redirect JavaScript: Google có theo không?
Có, với điều kiện. Google coi meta refresh tức thì (content="0; URL=…") là redirect vĩnh viễn và loại có độ trễ là tạm thời, và header HTTP Refresh được tính như vậy (Google Search Central). Redirect JavaScript chỉ hoạt động nếu Google render trang, nên chỉ dùng như phương án cuối cùng.
Ngay cả meta refresh 0 giây cũng chỉ chạy sau khi trang tải xong hoàn toàn (HTML Standard), nên khách có thể thấy trang cũ trước. Công cụ này theo meta refresh và header Refresh như các bước riêng, kèm độ trễ. Nó tìm redirect JavaScript đơn giản trong trang và đưa ra nút Kiểm tra URL này, nhưng không bao giờ chạy script: "không tìm thấy" nghĩa là không có trong HTML, chứ không phải hoàn toàn không có.
HTTP/1.1 301 Moved Permanently Location: https://example.com/new
- Google: theo mã: 301 và 308 vĩnh viễn, còn lại tạm thời
- Công cụ này: theo từng bước
<meta http-equiv="refresh" content="0; URL=https://example.com/new">
- Google: 0 giây: vĩnh viễn; có độ trễ: tạm thời
- Công cụ này: được theo như một bước, kèm độ trễ
window.location.href = "https://example.com/new";
- Google: chỉ khi render được: phương án cuối
- Công cụ này: hiển thị với “Kiểm tra URL này”, không bao giờ chạy
http, https, www và không www có cùng về một URL không?
Nên như vậy. Mỗi website có bốn lối vào, và mỗi lối nên đến cùng một URL cuối, lý tưởng là sau một bước vĩnh viễn; khác đi sẽ chia link giữa các phiên bản của cùng một trang.
Một ngoại lệ vẫn chấp nhận được: http://www. có thể mất hai bước nếu trước tiên nó đi đến https://www. trên cùng host. hstspreload.org yêu cầu đúng thứ tự đó, và Mozilla HTTP Observatory trừ 5 điểm khi bước đầu tiên từ http:// đi sang host khác.
Cả bốn đều đến https://github.com/http://www.github.com mất hai bước: https:// trên cùng host trước, như HSTS preload yêu cầu
Mỗi lối vào được theo tới 10 bước bên cạnh chuỗi chính.
Tại sao một URL redirect khác nhau theo quốc gia?
Vì máy chủ chọn phiên bản quốc gia hoặc ngôn ngữ dựa trên địa chỉ IP của khách hoặc header Accept-Language rồi redirect đến đó, nên cùng một URL kết thúc ở những trang khác nhau với những khách khác nhau. www.mozilla.org làm vậy theo ngôn ngữ: một 302 tương đối đến /en-US/ với Vary: Accept-Language.
Google khuyên không nên: "Avoid automatically redirecting users from one language version of a site to a different language version", vì Googlebot thường crawl từ Mỹ và không gửi Accept-Language (Google Search Central). Hãy cho mỗi phiên bản URL riêng với link hreflang, và gợi ý phiên bản khác bằng một banner.
Từ 11 địa điểm trong kết quả chạy chuỗi từ các điểm thăm dò của Website Down Checker trên khắp thế giới, nên redirect theo quốc gia hiện ra như một kết thúc khác. Các điểm thăm dò đó theo tối đa 5 redirect với user agent riêng của chúng.
Ahttps://shop.example/10 nơi kết thúc ở đây
- bạnGần bạn nhất20041 mili giây
San JoseSJC200152 mili giây
AshburnIAD20096 mili giây
LondonLHR20022 mili giây
StockholmARN20031 mili giây
SingaporeSIN200168 mili giây
SydneySYD200290 mili giây
São PauloGRU200201 mili giây
Cape TownCPT200170 mili giây
MumbaiBOM200121 mili giây
Bhttps://shop.example/ja-jp/khác
OsakaKIX302200486 mili giây
Câu trả lời chỉ Osaka nhận được
HTTP/1.1 302 Found Location: /ja-jp/ Vary: CF-IPCountry
Ghi ngày 24 tháng 10, 2026: www.mozilla.org redirect theo ngôn ngữ
HTTP/1.1 302 Found location: /en-US/ Vary: Accept-Language
Googlebot chủ yếu crawl từ Mỹ và không gửi Accept-Language: nó chỉ thấy https://shop.example/.
Link này dẫn đến đâu? Mở rộng link rút gọn
Dán link rút gọn hoặc link theo dõi vào ô trên để xem nó kết thúc ở đâu trước khi mở: host của từng bước, URL cuối cùng với mọi tham số được thêm dọc đường, và mạng đang phản hồi. Nó hoạt động như công cụ theo dõi redirect cho link rút gọn, mã QR và link trong bản tin.
Máy chủ của chúng tôi mở link, không phải trình duyệt của bạn, nên đích đến không bao giờ thấy địa chỉ hay cookie của bạn. Mỗi host trên đường đi cũng được tra trong bộ lọc phần mềm độc hại và nội dung người lớn của Cloudflare: host nằm trong danh sách bị đánh dấu đỏ, không có link để mở, còn host sạch hiện "không nằm trong danh sách phần mềm độc hại hoặc nội dung người lớn của Cloudflare". Đó không phải lời hứa rằng website an toàn, nên hãy dùng công cụ kiểm tra redirect link này như một trong nhiều bước kiểm tra.
Link rút gọn
https://youtu.be/jNQXAC9IVRw
303 See Other · 260 mili giâyĐến trang
https://www.youtube.com/watch?v=jNQXAC9IVRw&feature=youtu.be
200 OK · 768 mili giây- AS15169Google · mạng đang phản hồi
- TLS 1.3cả hai bước đều được mã hóa
- máy chủ của chúng tôiđã mở nó, không phải trình duyệt của bạn
feature=youtu.be dọc đường: các tham số theo dõi xuất hiện trong URL cuối trước khi bạn bấm.Cách redirect 301 trong nginx, Apache hoặc Cloudflare?
Hãy redirect trên máy chủ và viết rõ 301: một dòng return trong nginx, một dòng Redirect trong .htaccess của Apache, một quy tắc trong web.config của IIS, một dòng trong file _redirects trên Cloudflare hoặc Netlify, một mục trong vercel.json, một lệnh gọi trong Express. Chọn nền tảng của bạn bên dưới và sao chép đoạn mã.
Chú ý các giá trị mặc định: không có mã, nginx, Apache, Express và _redirects của Cloudflare gửi 302 tạm thời, còn Vercel gửi 308, mà Google coi như 301. Sau khi triển khai, hãy kiểm tra URL cũ ở đây: nó phải trả về một 301, đi thẳng đến URL mới.
| Nền tảng | Viết là | Gửi |
|---|---|---|
| nginx | return URL; | 302 tạm thời |
| Apache | Redirect /old /new | 302 tạm thời |
| IIS | action type="Redirect" | 301 vĩnh viễn |
| Cloudflare | _redirects | 302 tạm thời |
| Vercel | vercel.json redirects | 308 vĩnh viễn |
| Netlify | _redirects | 301 vĩnh viễn |
| Express | res.redirect(path) | 302 tạm thời |
location = /old-page {
return 301 /new-page;
}Trong khối server { } của site, rồi reload nginx. `return URL;` trần, không có mã, gửi 302.
Cách kiểm tra redirect trong Chrome hoặc bằng curl
Trong Chrome, mở DevTools (F12), vào Mạng, tick Giữ nhật ký và tải URL: mỗi bước là một dòng với trạng thái của nó. Với curl, curl -sIL in phần đầu của từng phản hồi khi theo các redirect.
Cả hai chạy từ máy của bạn, với cookie của bạn và trí nhớ của trình duyệt về các website chỉ dùng HTTPS. Đó là lý do Chrome đôi khi hiện 307 Internal Redirect mà không máy chủ nào gửi: chính nó đã nâng yêu cầu lên HTTPS và nêu lý do trong Non-Authoritative-Reason (mã nguồn Chromium). Từ Chrome 115 nó còn thử HTTPS trước cho địa chỉ http:// được gõ, nên redirect HTTP của chính máy chủ có thể không bao giờ hiện ra.
$ curl -sIL http://google.com | grep -iE '^(HTTP|location)' HTTP/1.1 301 Moved Permanently Location: http://www.google.com/ HTTP/1.1 302 Found Location: https://www.google.com/?gws_rd=ssl HTTP/2 200
307 Internal Redirect không đến từ máy chủ: Chrome tạo ra nó vì đã biết website chỉ dùng HTTPS, và nói rõ điều đó trong Non-Authoritative-Reason: HSTS. Công cụ kiểm tra phía máy chủ chỉ hiển thị những gì máy chủ gửi.
Kiểm tra redirect: câu hỏi thường gặp
Redirect 302 có xấu cho SEO không?
Googlebot theo được bao nhiêu redirect?
Làm sao thử redirect như Googlebot hoặc trên iPhone?
Công cụ check 301 redirect này có miễn phí không, và có thể kiểm tra nhiều URL cùng lúc không?
Tại sao Chrome hiện 307 mà máy chủ không gửi?
Nên giữ redirect 301 trong bao lâu?
Link này dẫn đến đâu, và mở có an toàn không?
Tại sao tôi gặp ERR_TOO_MANY_REDIRECTS?
HTTP có nên redirect sang HTTPS bằng 301 không?
Redirect 301 có truyền link equity không?
Còn thiếu điều gì?Đề xuất tính năng hoặc công cụ mới
Công cụ website liên quan
Kiểm tra HTTP Header
Phân tích header phản hồi HTTP và chấm điểm header bảo mật
Phân Tích Liên Kết
Phân tích tất cả liên kết trên trang web với phát hiện dofollow/nofollow và kiểm tra trạng thái HTTP
Kiểm Tra Website Sập
Web sập với mọi người hay chỉ mình bạn? Kiểm tra bất kỳ website nào từ 11 địa điểm và từ kết nối của bạn, kèm ảnh chụp màn hình trực tiếp
Kiểm Tra Chứng Chỉ SSL
Xác minh tính hợp lệ chứng chỉ SSL và chi tiết bảo mật
Tra Cứu DNS
Mọi bản ghi DNS từ máy chủ của chính tên miền, cạnh bộ nhớ đệm của Google và Cloudflare
Kiểm tra Hosting
Tìm ra ai đang host bất kỳ website nào: nhà cung cấp hosting, CDN, CMS, email, nhà đăng ký và đơn vị cấp SSL
Tìm Tên Miền Phụ
Khám phá tất cả tên miền phụ của bất kỳ tên miền nào
Tra Cứu WHOIS
Tra cứu đăng ký tên miền, nhà đăng ký và chi tiết chủ sở hữu qua RDAP