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.

Được hỏi từ máy chủ của chúng tôi, dùng lại kết nối theo từng host như trình duyệt · tới 20 bước, như trình duyệt theo dõi · với tư cách Chrome, iPhone, Googlebot hoặc Bingbot · kết quả được giữ 2 phút rồi xóa

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.

Lộ trình, được đọchttp://google.com · ghi ngày 24 tháng 10, 2026
Lộ trình · google.comChrome
2 lần chuyển hướng1,30 giây tổng
vĩnh viễntạm thờitrong tranglỗi
DNSkết nốiTLSbyte đầu tiên
  1. 1
    301Vĩnh viễnPOST có thể thành GET368 mili giây
    http://google.com/
    Google AS15169HTTP/1.1 · không TLS
  2. 2
    302Tạm thờiPOST có thể thành GET537 mili giây
    http://www.google.com/
    Google AS15169HTTP/1.1 · không TLS
  3. 3
    200CuốiOK393 mili giây
    https://www.google.com/?gws_rd=ssl
    “Google”
    Google AS15169TLS 1.3 · HTTP/2
  1. Tổng thời gian của mọi bước cộng lại, trước khi trang có thể bắt đầu.
  2. Ngâ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.
  3. Trang của từng bước biểu tượng mới nghĩa là link đã rời khỏi website.
  4. Trạng thái theo màu của loại, và ý nghĩa của nó bằng lời.
  5. Thời gian đi đâu DNS, kết nối, TLS và byte đầu tiên trên cùng một đồng hồ.
Hai redirect trước khi tới trang: google.com gửi 301 sang www, rồi www gửi 302 sang HTTPS. Ghi từng bước ngày 24 tháng 10, 2026; thời gian lấy từ máy ghi.

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 quả kiểm tra redirect cho http://google.com: một 301 và một 302 sang HTTPS, mỗi bước được đo trên cùng một đồng hồKết quả kiểm tra redirect cho http://google.com: một 301 và một 302 sang HTTPS, mỗi bước được đo trên cùng một đồng hồ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.
Kết quả kiểm tra redirect của http://google.com: kết luận, ngân sách bước so với 10 của Googlebot và 20 của trình duyệt, và từng bước với trạng thái và thời gian. Chọn một số để xem từng phần cho biết gì.

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.

Các loại redirect và cách Google đọc chúngRFC 9110 · Google Search Central · Bing
MãVĩnh viễnVới POSTTrình duyệt cacheTín hiệu GoogleDùng cho
301Moved Permanentlyvĩnh viễncó thể thành GETcómạnhtrang đã chuyển vĩnh viễn
308Permanent Redirectvĩnh viễngiữ nguyêncómạnhform hoặc API đã chuyển vĩnh viễn
302Foundtạm thờicó thể thành GETkhôngyếuviệc chuyển ngắn hạn (Bing: dưới 2 ngày)
303See Othertạm thờiluôn là GETkhôngyếutrang hiện sau khi gửi form
307Temporary Redirecttạm thờigiữ nguyênkhôngyếuviệc chuyển tạm thời phải giữ POST
meta 0meta refresh tức thìvĩnh viễnGET—mạnhkhi máy chủ không thể redirect
meta 5meta refresh có độ trễtạm thờiGET—yếutránh: khách thấy trang cũ trước
308 được coi như 301 và 307 như 302. Các dòng meta refresh tính cả header HTTP 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.

Bao nhiêu bước là quá nhiều?Google · Chromium · Firefox
  • 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
http://google.com2 redirect, rồi đến trang301 · 368302 · 537trang · 3931,30 giây
https://www.google.com/link thẳng đến trangtrang · 393393 mili giây
Mỗi bước là một vòng đi về đầy đủ trước khi trang có thể bắt đầu: ở đây 905 mili giây redirect đứng trước một trang 393 mili giây, ghi từng bước ngày 24 tháng 10, 2026.

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.

Một vòng lặp redirectví dụ giả lập

ERR_TOO_MANY_REDIRECTS · sau 20

Một quy tắc hostChọn tên miền không www hoặc có www và để mọi quy tắc đều gửi về đó, kể cả trang đăng nhập.
Quy tắc đọc cookieQuy tắc redirect cho đến khi cookie được đặt sẽ lặp với mọi client bỏ cookie, kể cả crawler.
Xóa 301 đã cacheTrình duyệt nhớ redirect vĩnh viễn: hãy thử trong cửa sổ ẩn danh sau khi sửa.

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ó.

Ba cách để redirectcách Google và công cụ này xử lý từng loại
Redirect máy chủdòng trạng thái
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
Refresh bằng metatrong HTML của trang
<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ễ
JavaScriptmột script đổi địa chỉ
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
Thứ tự trong trình duyệt: redirect HTTP trước, rồi JavaScript chạy khi trang đang tải, rồi meta refresh sau khi trang tải xong.

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.

Bốn lối vàogithub.com · ghi ngày 24 tháng 10, 2026

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

http://github.com301200sau 1 bước
http://www.github.com301301200sau 2 bước
https://github.com200chính canonical
https://www.github.com301200sau 1 bước
https://github.com/200 OK

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.

Một URL từ 11 địa điểmshop.example
Ví dụ giả lập

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/.

Mỗi nơi hỏi bằng DNS và địa chỉ của riêng nó. Các điểm thăm dò theo tối đa 5 redirect với user agent riêng của chúng.

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.

Mỗi nền tảng gửi gì khi không có mãtài liệu của từng nền tảng · 24 tháng 10, 2026
Nền tảngViết làGửi
nginxreturn URL;302 tạm thời
ApacheRedirect /old /new302 tạm thời
IISaction type="Redirect"301 vĩnh viễn
Cloudflare_redirects302 tạm thời
Vercelvercel.json redirects308 vĩnh viễn
Netlify_redirects301 vĩnh viễn
Expressres.redirect(path)302 tạm thời
Bốn trong bảy nền tảng quay về 302 tạm thời: luôn viết mã mà bạn muốn.
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.

Tự kiểm tra redirectcurl · Chrome DevTools
$ 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
Mạng☑ Giữ nhật ký
TênTrạng tháiLoại
www.google.com307Internal
?gws_rd=ssl200document

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?

Không hẳn. 302 cho Google biết việc chuyển là tạm thời, nên nó có thể vẫn hiển thị URL cũ, dù vẫn xử lý đích. Nếu việc chuyển là vĩnh viễn, hãy đổi sang 301 hoặc 308 để Google coi URL mới là URL cần lập chỉ mục và trình duyệt có thể cache redirect. Bing cũng chỉ yêu cầu dùng 302 cho thay đổi ngắn hơn hai ngày.

Googlebot theo được bao nhiêu redirect?

Tối đa 10 bước cho mỗi URL. Sau đó nó dừng và Search Console báo lỗi redirect cho trang. Lời khuyên của chính Google là giữ chuỗi từ 3 bước trở xuống và luôn dưới 5, và link thẳng đến URL cuối bất cứ khi nào có thể. Trình duyệt đi xa hơn: Chrome và Firefox theo tới 20 redirect trước khi bỏ cuộc.

Làm sao thử redirect như Googlebot hoặc trên iPhone?

Chọn Googlebot, iPhone, Bingbot hoặc Chrome ở hàng Với tư cách dưới ô URL, rồi kiểm tra URL. Công cụ gửi chuỗi user agent của agent đó ở mọi bước, nên website redirect crawler hoặc điện thoại đến nơi khác sẽ hiện ra trong chuỗi. Nó không thể dùng địa chỉ IP của Google, nên website kiểm tra địa chỉ thay vì user agent vẫn có thể trả lời khác.

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?

Có, miễn phí và không cần tài khoản. Chuyển sang Hàng loạt và dán tới 50 URL, mỗi dòng một URL: mỗi URL được theo tới 20 bước với user agent bạn chọn, và bảng hiển thị các bước, trạng thái cuối, URL cuối và kết luận. Tải về dạng CSV để kiểm tra việc di chuyển website. Kiểm tra đơn lẻ giới hạn 20 lần mỗi phút cho mỗi người dùng để giữ dịch vụ công bằng.

Tại sao Chrome hiện 307 mà máy chủ không gửi?

Chrome tạo "307 Internal Redirect" khi đã biết website chỉ dùng HTTPS, từ HSTS hoặc bản ghi DNS HTTPS, và nâng yêu cầu lên trước khi gửi bất cứ thứ gì. Header Non-Authoritative-Reason của phản hồi cho biết lý do. Công cụ kiểm tra phía máy chủ như thế này không bao giờ thấy bước đó, nên hiển thị các redirect do chính máy chủ gửi, đúng thứ mà các trình duyệt khác và crawler nhận được.

Nên giữ redirect 301 trong bao lâu?

Ít nhất một năm, và lâu hơn nếu có thể. Hướng dẫn chuyển website của Google nói hãy giữ redirect càng lâu càng tốt, thường ít nhất một năm, và vì khách truy cập hãy cân nhắc giữ vô thời hạn, vì link cũ, dấu trang và email vẫn đưa mọi người về URL cũ. Trỏ mỗi URL cũ đến trang mới gần nhất; redirect tất cả về trang chủ có thể bị coi là soft 404.

Link này dẫn đến đâu, và mở có an toàn không?

Hãy dán link vào đây trước khi bấm: máy chủ của chúng tôi theo nó, nên đích đến không bao giờ thấy địa chỉ của bạn. Bạn nhận được mọi bước, URL cuối cùng với các tham số theo dõi, và liệu có host nào trên đườ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. Kết quả sạch không phải là đảm bảo: hãy tự đánh giá tên miền cuối trước khi nhập bất cứ thứ gì ở đó.

Tại sao tôi gặp ERR_TOO_MANY_REDIRECTS?

Trình duyệt của bạn đã theo 20 redirect mà không đến được trang nào, hầu như luôn do vòng lặp: hai quy tắc đẩy một URL qua lại, như một quy tắc thêm www và một quy tắc bỏ nó, hoặc CDN hỏi qua http:// trong khi máy chủ khăng khăng dùng https://. Hãy kiểm tra URL ở đây để thấy bước bị lặp, sửa quy tắc, rồi xóa cookie của website hoặc dùng cửa sổ ẩn danh.

HTTP có nên redirect sang HTTPS bằng 301 không?

Có. 301 hoặc 308 vĩnh viễn từ http:// sang https:// là điều RFC 6797 khuyến nghị cho website dùng HSTS, và bước đầu tiên trên cùng host là điều hstspreload.org và bài kiểm tra redirect của Mozilla Observatory tìm kiếm. 302 vẫn hoạt động với khách nhưng cho công cụ tìm kiếm biết việc chuyển là tạm thời. Chỉ 301 thì chưa khiến trình duyệt thử HTTPS trước lần sau: đó là việc của header Strict-Transport-Security.

Redirect 301 có truyền link equity không?

Google không công bố con số, nhưng theo tài liệu của họ, 301 hoặc 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ả, còn 302, 303 hoặc 307 thì không. Vì vậy redirect vĩnh viễn là cách chuyển vị thế của một trang sang URL mới; redirect tạm thời vẫn khiến đích được xử lý (tín hiệu yếu, theo tài liệu crawler của Google), và đích có thể được lập chỉ mục nếu các tín hiệu chuẩn hoá khác trỏ đến nó.

Còn thiếu điều gì?Đề xuất tính năng hoặc công cụ mới