Chuyển hướng 302 và 307

Tóm tắt — 302 và 307 đều là chuyển hướng tạm thời: chúng tạm đưa khách đến nơi khác nhưng vẫn giữ URL gốc làm địa chỉ chính. Google xử lý hai mã giống nhau nên không có khác biệt SEO đáng kể. Khác biệt thật là kỹ thuật: 307 phải giữ nguyên loại yêu cầu, nên gửi biểu mẫu vẫn là gửi biểu mẫu thay vì biến thành tải trang thông thường; 302 từng cho phép đổi phương thức. Dùng 302 cho chuyển hướng thường; dùng 307 khi chuyển biểu mẫu hoặc API gửi dữ liệu. Đừng mặc định rằng “dùng 307 mọi nơi” hoàn toàn không có đánh đổi.

302 và 307 thực sự có nghĩa gì

302 và 307 đều là chuyển hướng: bạn yêu cầu một URL rồi đến URL khác. Con số là mã trạng thái HTTP máy chủ trả về, mang thông điệp cho trình duyệt và công cụ tìm kiếm.

• 302 — “Found” (tạm thời). Mã chuyển hướng tạm thời gốc, nghĩa là “tạm đến đây nhưng địa chỉ cũ vẫn là địa chỉ chính — tôi sẽ quay lại”.
• 307 — “Temporary Redirect” (Chuyển hướng tạm thời). Cùng thông điệp — tạm thời, URL cũ vẫn được tính — nhưng thêm một lời hứa: trình duyệt phải lặp lại chính xác yêu cầu, gồm việc đó là GET (lấy trang) hay POST (gửi dữ liệu như biểu mẫu).

Vì vậy, chúng là anh em cùng nhóm. Cách nói hữu ích: 307 là 302 có thêm bảo đảm trình duyệt không âm thầm đổi lần gửi biểu mẫu thành yêu cầu tải trang thường.

Điều này có quan trọng với SEO không?

Không theo cách phần lớn chủ site lo lắng. Tài liệu Google ghi 307 “equivalent to 302” (bản dịch) «tương đương với 302» về cách crawler xử lý và theo chuyển hướng. Cả hai đều là tín hiệu tạm thời, nên mặc định Google không coi đích là canonical chỉ vì chuyển hướng. Tài liệu Google không nói hai mã truyền lượng giá trị liên kết giống hay khác nhau; điều được nói rõ là không mã nào trao tín hiệu của nguồn cho đích theo cách chuyển hướng vĩnh viễn làm. Nếu ai nói 307 “truyền ít giá trị hơn” 302, hãy yêu cầu nguồn; Google chưa công bố điều đó. Evidence for this claim Google treats 307 as equivalent to 302 for Search while noting that the two status codes are semantically different. Scope: Google Search redirect handling; HTTP clients still need the appropriate status code. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search

Vậy dùng từng mã khi nào?

• Dùng 302 thường cho chuyển hướng tạm thời hàng ngày: trang giảm giá theo mùa, thử nghiệm A/B, trang bảo trì hoặc trang chủ theo quốc gia.
• Dùng 307 khi thứ được chuyển đang gửi dữ liệu: biểu mẫu, lệnh gọi API, POST đăng nhập hoặc thanh toán. Khi đó, lời hứa giữ phương thức và dữ liệu của 307 thật sự quan trọng vì 302 có thể cho client cũ đổi POST thành GET và bỏ dữ liệu.

Một điều thường gây nhầm lẫn

Đôi khi DevTools của trình duyệt hiển thị 307 bạn chưa từng cấu hình. Thường đó không phải chuyển hướng máy chủ thật mà là trình duyệt tự nâng liên kết http:// thành https:// bằng tính năng bảo mật HSTS rồi hiển thị như 307. Máy chủ chưa từng gửi mã đó. Phần Nâng cao giải thích kỹ hơn.

Muốn hiểu lịch sử đặc tả, nguyên văn Google và Mueller, “307 ảo” do HSTS và các mặc định framework gây bất ngờ? Hãy chuyển sang thẻ Nâng cao.

Tóm tắt — 302 và 307 đều là chuyển hướng tạm thời và được Google xử lý giống nhau. Tài liệu nói 307 “equivalent to 302” (bản dịch) «tương đương với 302»; Mueller nói “for SEO, it doesn’t really matter” (bản dịch) «đối với SEO, điều đó không thực sự quan trọng» giữa các cặp tạm thời và vĩnh viễn. Không mã nào là tín hiệu đích nên thành canonical và Google chưa công bố tỷ lệ PageRank/link value giữa chúng. Khác biệt thật là giữ phương thức: khi tự động theo 307, client phải giữ cùng phương thức — POST vẫn là POST — còn 302 cho phép đổi POST thành GET. Byte body, thông tin xác thực và hành vi khác origin vẫn phụ thuộc client, nên phải xác minh. Dùng 307 khi mất phương thức sẽ phá API, biểu mẫu, webhook, thanh toán hoặc xác thực; nhưng chú ý phát lại không idempotent, vì thanh toán hay đặt hàng bị chuyển có thể gửi lại. 302 thường phù hợp với GET thông thường, gồm thử nghiệm A/B mà Google khuyên dùng. Hãy nhận biết “307 ảo” HSTS — nhãn giao diện Chrome, không phải bảo đảm giao thức — và khác biệt framework; Next.js hiện ghi 303 cho Server Actions và 307 ở ngữ cảnh khác, nên kiểm tra đúng phiên bản. Bing không có hướng dẫn riêng cho 302 với 307. Thứ tự tạm thời tôi ưu tiên là 307 / 302 / 303 trước meta/HTTP refresh, nhưng mặc định 307 không miễn phí: phải kiểm tra header cache, client cũ và bảo vệ idempotency.

Cả hai đều tạm thời — đó là điểm xuất phát

Trước hết, 302 và 307 nằm trong cùng nhóm. Google gom 302 (Found), 303 (See Other) và 307 (Temporary Redirect) thành “chuyển hướng tạm thời”, với cùng hành vi: “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (bản dịch) «Googlebot đi theo chuyển hướng nhưng quy trình lập chỉ mục không dùng nó làm tín hiệu đích nên là canonical.» Nói đơn giản, chuyển hướng tạm thời mặc định giữ URL nguồn làm canonical; nó không trao tín hiệu nguồn cho đích như 301/308 vĩnh viễn. Evidence for this claim Google Search does not use a 302, 303, or 307 temporary redirect itself as a signal that the target should be canonical, although other signals can still lead to target indexing or selection. Scope: temporary redirects Confidence: high · Verified: 2026-07-16 Redirects and Google Search

Đây chính là so sánh ở tầng thấp hơn của cặp vĩnh viễn: 301/308 là cặp vĩnh viễn, 302/307 là cặp tạm thời, và logic “mã lớn hơn giữ phương thức” giống hệt ở cả hai.

Khác biệt thật duy nhất: giữ phương thức và body

Khác biệt quan trọng trong một câu: khi client tự động theo 307, đặc tả HTTP hiện tại RFC 9110 yêu cầu giữ cùng phương thức; 302 cho phép client đổi POST thành GET. Đây là bảo đảm ở tầng đặc tả về phương thức, không phải bảo đảm mọi byte body, thông tin xác thực hay hành vi khác origin, vốn còn phụ thuộc client cụ thể. Hãy xác minh bằng yêu cầu thật thay vì giả định 307 luôn phát lại mọi thứ giống hệt.

Sự mơ hồ bắt nguồn từ lịch sử đặc tả. Thời HTTP/1.0, văn bản 302 nói client không nên đổi phương thức khi theo chuyển hướng, nhưng trình duyệt đầu tiên — Netscape rồi các trình duyệt khác — bỏ qua và âm thầm đổi phương thức không phải GET, nhất là POST, thành GET. Hành vi thiếu nhất quán nhưng phổ biến đó trở thành tiêu chuẩn thực tế. HTTP/1.1 (RFC 2616 năm 1999, sau gộp vào RFC 7231 và RFC 9110 hiện nay) tách thành hai mã rõ để chấm dứt nhầm lẫn:

• 303 (See Other) — lấy đích bằng GET hoặc HEAD, không đơn giản là “luôn GET” vì RFC 9110 cho phép cả hai phương thức an toàn. Đây là hành vi dành cho “POST rồi chuyển đến trang kết quả có thể tải lại an toàn”.
• 307 (Temporary Redirect) — phương thức được giữ nghiêm ngặt khi tự động theo; RFC 9110 không buộc mọi client phải theo chuyển hướng.

MDN tóm tắt thực tế: “The difference between 307 and 302 is that 307 guarantees that the client will not change the request method and body when the redirected request is made. With 302, older clients incorrectly changed the method to GET.” (bản dịch) «Khác biệt là 307 bảo đảm client không đổi phương thức và body khi chuyển hướng, còn client cũ từng đổi sai phương thức 302 thành GET.» Vì vậy 307 chủ yếu xóa sự mơ hồ, là phiên bản được đặc tả bảo đảm của điều 302 đúng ra phải làm. Trình duyệt hiện đại nhất quán hơn thời Netscape, nhưng 307 loại bỏ sự mơ hồ bằng đặc tả thay vì quy ước.

So sánh trực tiếp:

Hai lưu ý chính xác: ngoại lệ RFC cho 302 nêu POST, không phải mọi phương thức; đừng khái quát thành “302 always breaks PUT/DELETE” (bản dịch) «302 luôn phá PUT/DELETE» nếu chưa kiểm tra client. Ngoài ra, riêng mã trạng thái không làm 302 hay 307 mặc định có thể cache: RFC 9111 không liệt kê chúng trong nhóm có thể cache theo suy đoán. Việc cache vẫn phụ thuộc header Cache-Control/Expires, không phải mã đã chọn. Evidence for this claim Do not generalize the RFC's 302 POST-to-GET allowance into a claim that PUT, DELETE, or every non-GET method will change; client-specific evidence is required. Scope: 302, 303, and 307 responses Confidence: high · Verified: 2026-07-16 RFC 9110: HTTP Semantics

Định nghĩa của tôi trên Ahrefs phù hợp với điểm giữ phương thức: “A 307 redirect is the same as a 302 redirect, except it retains the HTTP method (POST, GET) of the original request when performing the redirect.” (bản dịch) «307 giống 302, ngoại trừ giữ phương thức HTTP (POST, GET) của yêu cầu gốc khi chuyển hướng.» Evidence for this claim RFC 9110 defines both 302 and 307 as temporary redirects; 307 forbids changing the request method, while 302 permits POST-to-GET rewriting for historical reasons. Scope: HTTP semantics for 302 and 307 responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §§15.4.3, 15.4.8

Google có xử lý 302 và 307 khác nhau cho SEO không?

Không. Google nói rõ bất thường về điều này. Đây là chủ đề đã ngã ngũ, ít tranh cãi, giống 301 với 308.

Trong tài liệu mã trạng thái HTTP, dòng 302 nói crawler theo chuyển hướng và dùng nó làm tín hiệu yếu rằng đích nên được xử lý; dòng 307 ghi nguyên văn “Equivalent to 302.” (bản dịch) «Tương đương với 302.» Google thêm lưu ý cho cả cặp 302/307 và 301/308: “While Google treats these status codes the same way, keep in mind that they’re semantically different. Use the status code that’s appropriate for the redirect so other clients (for example, e-readers, other search engines) may benefit from it.” (bản dịch) «Dù Google xử lý các mã giống nhau, chúng khác về ngữ nghĩa; hãy dùng mã phù hợp để client khác hưởng lợi.»

Đó là câu trả lời ở tầng xử lý crawler. Googlebot lấy và theo hai mã giống nhau, chỉ yêu cầu chọn mã đúng ngữ nghĩa để client ngoài Google hoạt động tốt. Evidence for this claim Google treats 307 as equivalent to 302 for Search while noting that the two status codes are semantically different. Scope: Google Search redirect handling; HTTP clients still need the appropriate status code. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search

Một sắc thái cần tách rõ: tương đương trong xử lý crawler là tuyên bố khác với kết quả lập chỉ mục. Tài liệu Chuyển hướng và Google Tìm kiếm gom 302, 303 và 307 vào “chuyển hướng tạm thời” và nói quy trình lập chỉ mục không dùng chuyển hướng làm tín hiệu đích nên là canonical. Đây là bảo đảm hữu ích nhưng không hứa URL nguồn giữ thứ hạng hay đích không bao giờ được lập chỉ mục nhờ tín hiệu khác. Hãy coi “302 và 307 được xử lý giống nhau” và “không mã nào là tín hiệu canonical cho đích” là hai phát biểu đúng riêng biệt, không phải tuyên bố chúng truyền PageRank/link value bằng nhau — tài liệu Google không nói theo hướng nào.

John Mueller diễn đạt tương tự trong tập “Bàn về chuyển hướng” của Search Off the Record. Martin Splitt hỏi vì sao cần 307/308 bên cạnh 301/302. Mueller nói: “I had to look this up recently. And usually, with a 301 and 302, what is forwarded are GET requests.” (bản dịch) «Tôi vừa phải tra cứu; với 301 và 302, thường yêu cầu GET được chuyển tiếp.» Sau đó: “And with 307, 308, it also forwards POST requests.” (bản dịch) «Với 307 và 308, yêu cầu POST cũng được chuyển tiếp.» Câu kết cho SEO: “I think for SEO, it doesn’t really matter. It’s more like, I don’t know… Does it work for APIs or not? And usually, APIs are not something that you need to have indexed directly in Search.” (bản dịch) «Đối với SEO, điều đó không thực sự quan trọng; câu hỏi là có hoạt động với API không, mà API thường không cần được lập chỉ mục trực tiếp.»

Cách diễn đạt cho thấy toàn bộ lý do chọn 307 thay 302 là câu hỏi chức năng — “API có hoạt động không?” — không phải thứ hạng. Không có nguồn sơ cấp đáng tin nào nói một mã có lợi thế SEO.

Bing có xử lý 302 và 307 khác nhau không?

Thành thật: Bing chưa nói. Hướng dẫn công khai năm 2011 và 2020 chỉ nói khác biệt vĩnh viễn/tạm thời của 301 với 302, không nhắc tên 307 hay 308. Không giống chủ đề 301/308 nơi Fabrice Canel phát biểu trực tiếp, tôi không tìm thấy phát biểu riêng nào của Bing về 302 với 307.

Vì vậy, không nên giả định tương đương: không có phát biểu Bing phân biệt cụ thể 302 và 307. Có hành vi Bing được ghi nhận cho chuyển hướng tạm thời nói chung: nếu Bingbot thấy cùng 302 đủ nhiều lần, nó bắt đầu xử lý như 301 và hợp nhất về phía trước. Nhưng Bing chưa xác nhận hành vi này áp dụng cho 307 lặp lại. Đây là khoảng trống tài liệu thật, không phải sự thật về 307.

Khi 307 là lựa chọn đúng về kỹ thuật

Bất kỳ chuyển hướng nào mà mất phương thức hoặc body gốc sẽ phá chức năng:

• API và endpoint webhook — yêu cầu POST/PUT/DELETE phải đến URL mới với phương thức và payload nguyên vẹn.
• Gửi biểu mẫu (luồng POST) — Mueller nói “if you have a— I’d almost say like a broken setup, that you have a form on one domain and the results are forwarded to a different one, then you would use the 307, 308.” (bản dịch) «nếu có biểu mẫu ở một miền và kết quả được chuyển sang miền khác, bạn sẽ dùng 307 hoặc 308».
• Luồng POST thanh toán, đặt hàng và đăng nhập/xác thực — nơi bỏ body làm giao dịch thất bại âm thầm.

Một lưu ý an toàn: bảo đảm giữ phương thức của 307 có hai mặt. Nếu yêu cầu gốc không idempotent — thu tiền, gửi đơn hàng hoặc tác dụng phụ khác — tự động theo 307 sẽ phát lại chính yêu cầu đó tại URL mới. Thường đây là điều mong muốn, nhưng client thử lại hoặc chuỗi chuyển hướng có thể gửi yêu cầu nhiều lần. Hãy đặt biện pháp idempotency như khóa idempotency hoặc kiểm tra gửi trùng tại endpoint nhận, thay vì giả định chuyển hướng tự làm việc phát lại an toàn.

Một lý do lớn khiến lập trình viên gặp 307 mà không chọn là framework và nền tảng edge mặc định dùng mã giữ phương thức cho yêu cầu không phải GET. Next.js là ví dụ có tài liệu rõ: hàm redirect() trả 303 khi gọi từ Server Action và 307 trong ngữ cảnh hỗ trợ khác theo API hiện tại. Hãy kiểm tra tài liệu đúng phiên bản, không khái quát sang nền tảng khác. Framework, CDN và load balancer thay đổi theo sản phẩm/phiên bản; xác minh mã thật thay vì giả định. 307 hoặc 303 bất ngờ thường là nền tảng chủ động nhận biết phương thức, không nhất thiết cấu hình sai, nhưng phải xác nhận trên hệ thống cụ thể.

Khi 302 là mặc định thực dụng

Chuyển hướng tạm thời tiêu chuẩn trên yêu cầu GET thường không có phương thức cần giữ, nên bảo đảm 307 không đem thêm lợi ích:

• Chuyển hướng địa lý/ngôn ngữ, với lưu ý không chặn hoàn toàn nội dung theo vùng.
• Thử nghiệm A/B và split test — hướng dẫn thử nghiệm website của Google nói rõ dùng 302, không dùng 301, vì chuyển hướng tạm thời.
• Chế độ bảo trì hoặc “sắp quay lại” — chỉ khi có tài nguyên thật để đưa khách đến. Nếu toàn site không khả dụng, Google khuyên 503 thay vì chuyển hướng. Nếu thứ được chuyển là yêu cầu không phải GET như thanh toán/API, 307 sẽ phát lại tại URL mới và không tự an toàn nếu có tác dụng phụ; đừng dùng theo thói quen.
• Chuyển hướng mobile↔desktop (m-dot) — ví dụ của Mueller nơi 302 đúng: “a 302 redirect would be the right one because next time someone goes there, you don’t really know if they want to go to the mobile version or the desktop version.” (bản dịch) «302 là lựa chọn đúng vì lần sau không biết người dùng muốn bản mobile hay desktop». Đích phụ thuộc khách, không phải lần chuyển vĩnh viễn.

“307 ảo” do HSTS — mã máy chủ chưa từng gửi

Phần này riêng biệt với việc chọn mã chuyển hướng; trộn hai chuyện gây nhầm khi gỡ lỗi chuỗi.

Nếu site gửi header HSTS (Strict-Transport-Security) qua HTTPS, trình duyệt ghi nhớ và lần sau khi truy cập http:// sẽ tự đổi thành https:// trước khi yêu cầu chạm mạng. Chrome hiện hiển thị nâng cấp nội bộ đó trong DevTools như 307, nhưng máy chủ không phát mã. Nhãn, số byte và cách hiển thị header phụ thuộc phiên bản Chrome, không phải yêu cầu của HTTP/HSTS. Mueller viết: “After seeing the HTTPS URL with the HSTS header (for example, with any redirect from the HTTP version), Chrome will act like it’s seeing a 307 redirect the next time you try to access the HTTP page.” (bản dịch) «Sau khi thấy URL HTTPS có HSTS, Chrome hành động như gặp 307 khi lần sau truy cập trang HTTP.» Và phần quan trọng: “Your server’s not returning a 307, Chrome is just showing it to you as such to explain that it’s doing the redirect for you.” (bản dịch) «Máy chủ không trả 307; Chrome chỉ hiển thị như vậy để giải thích nó đang chuyển hướng giúp bạn.»

Tôi cũng ghi điều này trong bài mã trạng thái: có nghĩa riêng “307 HSTS Policy” — ép client dùng HTTPS — khác với “307 Temporary Redirect”. Sắc thái SEO: “When web servers require clients to only use HTTPS connections (HSTS policy), Google won’t see the 307 because it’s cached in the browser.” (bản dịch) «Khi máy chủ yêu cầu chỉ dùng HTTPS qua HSTS, Google không thấy 307 vì nó được cache trong trình duyệt.» Vì vậy, nếu Network hiển thị 307 chưa cấu hình, hãy kiểm tra HSTS tự nâng HTTP→HTTPS trước khi săn quy tắc sai.

Những quan niệm sai phổ biến

• “307 không truyền cùng giá trị SEO như 302.” Không có bằng chứng. Tài liệu Google nói 307 “Equivalent to 302” về cách xử lý và không mã nào là tín hiệu canonical cho đích. Nhưng Google không công bố công thức PageRank/link value cho hai mã, nên đừng khẳng định lượng truyền bằng hoặc khác chính xác; phát biểu đúng là Google xử lý chúng giống nhau.
• “302 an toàn hoặc được khuyên dùng hơn vì công cụ tìm kiếm hiểu rõ hơn.” Nói quá. Cách Google xử lý 307 cũng được ghi rõ như 302. 307 còn có bảo đảm chức năng giữ phương thức/body.
• “307 trong Network nghĩa máy chủ cấu hình sai.” Thường sai; với HSTS, đó có thể là nâng cấp HTTP→HTTPS nội bộ của Chrome.
• “302 luôn đổi POST thành GET nên không bao giờ dùng cho biểu mẫu.” Nói quá với trình duyệt hiện đại. POST→GET là vấn đề có thật ở client cũ và lý do 307 là lựa chọn được bảo đảm; 302 mơ hồ, không phải luôn hỏng.
• “Đổi mọi chuyển hướng tạm thời sang 307 để tăng thứ hạng.” Sai và tạo biến động; chỉ chọn 307 khi thật sự cần giữ phương thức/body hoặc muốn future-proof.
• “303 và 307 gần như giống nhau.” Không; 303 chủ động chuyển sang GET/HEAD cho mẫu POST rồi đến trang kết quả, đối lập với bảo đảm giữ phương thức của 307.

Khuyến nghị của tôi

Với chuyển hướng tạm thời, thứ tự triển khai tôi ưu tiên là 307 / 302 / 303, cao hơn meta refresh (0) và HTTP refresh (0). Tôi xếp 307 trên 302 không phải vì SEO mà vì mã giữ phương thức giúp bạn ít phải nhớ đổi sau này: GET thường hoạt động tốt với 307, và khi chuyển biểu mẫu/API thì đã được bảo vệ. Đây là lý do về tính đầy đủ, không phải không có chi phí: chính sách mặc định 307 vẫn cần kiểm soát cache, hỗ trợ client cũ và bảo vệ idempotency ở đích không phải GET. Mueller cũng nói “if you always use them, then you’re always safe.” (bản dịch) «nếu luôn dùng chúng thì luôn an toàn». Dù vậy, 302 thường hoàn toàn ổn, và với m-dot thì 302 đúng hơn về kỹ thuật.

Vị trí của chủ đề này

302 và 307 là hai mã chuyển hướng tạm thời 3xx, mỗi mã có bài chuyên sâu riêng bên cạnh cặp vĩnh viễn 301/308, mã luôn chuyển GET là 303 và các bài so sánh liên quan: 301 với 308 có cùng logic giữ phương thức ở tầng vĩnh viễn; 301 với 302 so sánh vĩnh viễn và tạm thời. Cũng cần chú ý chuỗi và vòng lặp chuyển hướng. Để xem toàn bộ phản hồi máy chủ, hãy đọc trung tâm Mã trạng thái HTTP; loại chuyển hướng là một tín hiệu trong bài canonical hóa.

Tóm tắt bằng AI

Phiên bản cô đọng của phần Nâng cao:

• Cả hai là chuyển hướng tạm thời. 302 và 307 mặc định giữ URL nguồn làm canonical; không mã nào trao tín hiệu nguồn cho đích như 301/308 vĩnh viễn.
• Google xử lý chúng giống nhau. Tài liệu nói 307 “equivalent to 302” (bản dịch) «tương đương với 302»; Mueller nói “for SEO, it doesn’t really matter.” (bản dịch) «đối với SEO, điều đó không quan trọng». Đây là tuyên bố về xử lý crawler, không phải công thức PageRank/link value. Google chưa công bố công thức cho hai mã, nên đừng khẳng định lượng truyền chính xác bằng hoặc khác nhau; cũng đừng cho rằng “xử lý giống nhau” bảo đảm nguồn luôn xếp hạng hoặc đích không thể được lập chỉ mục nhờ tín hiệu khác.
• Khác biệt thật duy nhất là giữ phương thức. Khi tự động theo 307, client phải giữ cùng phương thức — POST vẫn là POST; 302 cho phép đổi POST thành GET. 307 được thêm trong HTTP/1.1 để xóa sự mơ hồ, nhưng byte body, thông tin xác thực và hành vi khác origin vẫn tùy client; ngoại lệ RFC nêu riêng POST, không phải mọi phương thức không phải GET.
• Dùng 307 cho API, biểu mẫu, webhook, thanh toán hoặc xác thực POST; chú ý phát lại không idempotent và thêm bảo vệ. Dùng 302 cho GET thường: địa lý/ngôn ngữ, thử nghiệm A/B theo khuyến nghị Google và mobile↔desktop theo ví dụ Mueller. Với bảo trì, nếu không có tài nguyên thật để chuyển đến thì gián đoạn toàn site thường nên trả 503.
• Mặc định framework tùy phiên bản/ngữ cảnh. Next.js ghi 303 cho Server Actions và 307 ở ngữ cảnh khác; kiểm tra phiên bản thay vì giả định framework/CDN khác giống nhau.
• “307 ảo” HSTS: 307 trong Network thường là Chrome tự nâng HTTP→HTTPS, không phải phản hồi máy chủ; nhãn “307” là lựa chọn giao diện theo phiên bản Chrome, không phải yêu cầu đặc tả. Mueller: “Your server’s not returning a 307, Chrome is just showing it to you as such.” (bản dịch) «Máy chủ không trả 307; Chrome chỉ hiển thị như vậy.»
• Bing: không có hướng dẫn riêng 302 với 307; đừng giả định tương đương hoặc rằng hành vi “302 lặp lại → xử lý như 301” cũng áp dụng 307.
• Không mã nào mặc định có thể cache chỉ nhờ trạng thái theo RFC 9111; cache phụ thuộc header Cache-Control/Expires.
• Thứ tự Patrick ưu tiên: 307 / 302 / 303 trước meta/HTTP refresh, nhưng mặc định 307 mọi nơi không miễn phí; kiểm tra cache, client cũ và idempotency.

Tài liệu chính thức

Tài liệu và đặc tả nguồn sơ cấp.

Google

• Mã trạng thái HTTP, lỗi mạng/DNS và Google Tìm kiếm — dòng “tín hiệu yếu” của 302, dòng 307 “Equivalent to 302” và lưu ý “khác ngữ nghĩa — dùng đúng mã”.
• Chuyển hướng và Google Tìm kiếm — gom 302, 303 và 307 thành chuyển hướng tạm thời và giải thích ảnh hưởng canonical hóa.
• Search Off the Record, tập 51 — “Bàn về chuyển hướng” (John Mueller và Martin Splitt) — thảo luận chính thức về lý do 307/308 tồn tại và khi nào quan trọng.
• John Mueller — Hướng dẫn 301, 302, 307 và các chuyển hướng khác — hành vi lập chỉ mục 302, nơi URL nguồn “R” thường được lập chỉ mục và chuyển hướng không được cache.
• John Mueller — 307s — giải thích “307 ảo” HSTS.

Bing / Microsoft

• Quản lý chuyển hướng — 301, 302 và canonical (10/2011) — cách Bing phân loại 301 cho vĩnh viễn, 302 cho tạm thời; không nhắc 307.
• Di chuyển website với Bing (12/2020) — hướng dẫn di chuyển chung, cũng không có phát biểu riêng về 307.

Đặc tả

• MDN — 307 Temporary Redirect — định nghĩa giữ phương thức/body và lưu ý lịch sử client cũ đổi phương thức thành GET.
• RFC 9110 — HTTP Semantics — §15.4.8 “307 Temporary Redirect” và §15.4.3 “302 Found”, văn bản đặc tả hiện tại cho hai mã.

Trích dẫn từ nguồn

Các phát biểu chính thức của Google cùng đặc tả. Khi trang hỗ trợ, liên kết sâu đưa đến đoạn được trích.

Tài liệu Google — 307 tương đương 302

• “Equivalent to 302.” (bản dịch) «Tương đương với 302.» (dòng 307) — Google Search Central. Đi đến trích dẫn
• “While Google treats these status codes the same way, keep in mind that they’re semantically different. Use the status code that’s appropriate for the redirect so other clients (for example, e-readers, other search engines) may benefit from it.” (bản dịch) «Dù Google xử lý các mã giống nhau, chúng khác về ngữ nghĩa; hãy dùng mã phù hợp để client khác hưởng lợi.» Đi đến trích dẫn
• “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (bản dịch) «Googlebot đi theo chuyển hướng nhưng quy trình lập chỉ mục không dùng nó làm tín hiệu đích nên là canonical.» (chuyển hướng tạm thời gồm 302/303/307) Đi đến trích dẫn

John Mueller của Google (tập 51 “Bàn về chuyển hướng” của Search Off the Record; PDF transcript chính thức, dẫn theo đoạn vì không có trang HTML với anchor tương ứng)

• “I had to look this up recently. And usually, with a 301 and 302, what is forwarded are GET requests.” (bản dịch) «Với 301/302, thường yêu cầu GET được chuyển tiếp.»
• “And with 307, 308, it also forwards POST requests.” (bản dịch) «Với 307/308, yêu cầu POST cũng được chuyển tiếp.»
• “If you have some kind of an API that uses POST requests, or if you have a— I’d almost say like a broken setup, that you have a form on one domain and the results are forwarded to a different one, then you would use the 307, 308.” (bản dịch) «Nếu API dùng POST hoặc biểu mẫu ở một miền chuyển kết quả sang miền khác, bạn sẽ dùng 307 hoặc 308.»
• “I guess from a completeness point of view, if you always use them, then you’re always safe. But that’s the difference there. I think for SEO, it doesn’t really matter. It’s more like, I don’t know… Does it work for APIs or not? And usually, APIs are not something that you need to have indexed directly in Search.” (bản dịch) «Về tính đầy đủ, luôn dùng mã giữ phương thức thì an toàn; với SEO điều đó không quan trọng, câu hỏi là API có hoạt động không và API thường không cần lập chỉ mục.»
• “And for that kind of redirect [mobile/desktop], from a technical point of view, a 302 redirect would be the right one because next time someone goes there, you don’t really know if they want to go to the mobile version or the desktop version.” (bản dịch) «Với mobile/desktop, 302 đúng vì lần sau không biết người dùng muốn phiên bản nào.» PDF transcript

John Mueller, Google (johnmu.com — “307 ảo” HSTS)

• “After seeing the HTTPS URL with the HSTS header (for example, with any redirect from the HTTP version), Chrome will act like it’s seeing a 307 redirect the next time you try to access the HTTP page.” (bản dịch) «Sau khi thấy URL HTTPS có HSTS, lần sau Chrome hành động như gặp 307 khi truy cập trang HTTP.»
• “Your server’s not returning a 307, Chrome is just showing it to you as such to explain that it’s doing the redirect for you.” (bản dịch) «Máy chủ không trả 307; Chrome chỉ hiển thị như vậy để giải thích nó đang chuyển hướng giúp bạn.» Đọc bài viết

MDN — khác biệt giữ phương thức

• “The difference between 307 and 302 is that 307 guarantees that the client will not change the request method and body when the redirected request is made. With 302, older clients incorrectly changed the method to GET.” (bản dịch) «307 bảo đảm client không đổi phương thức và body; với 302, client cũ từng đổi sai phương thức thành GET.» Đi đến trích dẫn

Nên dùng chuyển hướng tạm thời nào: 302 hay 307?

Vì cả hai đều tạm thời và tương đương với SEO, toàn bộ quyết định nằm ở một câu hỏi: yêu cầu có mang phương thức hoặc body phải giữ không?

Lưu ý cho nhánh “chưa chắc”: Google xử lý 307 giống 302 và mã này hoạt động tốt với GET thường, nên mặc định dùng không sai; nhưng cũng không tự miễn phí. Xác nhận header cache, kiểm tra client cũ có xử lý 307 ổn định không, và nếu yêu cầu có tác dụng phụ — lệnh gọi API không phải GET — đừng cho tự động phát lại mà không có bảo vệ idempotency.

Những lỗi cần tránh với chuyển hướng tạm thời

Chọn 302 vì cho rằng 307 truyền ít giá trị hơn

Google ghi 307 tương đương 302 cho tìm kiếm. Hãy chọn theo hành vi yêu cầu, không phải thứ hạng.

Cho rằng 302 luôn an toàn hơn vì lâu đời

Client cũ làm cách xử lý phương thức 302 trở nên mơ hồ. Nếu body POST, PUT, DELETE, webhook hoặc API phải tồn tại, dùng 307 để có bảo đảm rõ.

Coi mọi 307 trong DevTools là quy tắc máy chủ

Chrome có thể hiển thị nâng cấp HSTS nội bộ như 307 dù máy chủ chưa từng trả mã đó. Hãy tái hiện bằng công cụ phía máy chủ hoặc curl trước khi sửa cấu hình.

Khẳng định mọi 302 đổi POST thành GET

Hành vi lịch sử được phép và mơ hồ, không được bảo đảm ở mọi client hiện đại. Dùng 307 khi cần chắc chắn; đừng mô tả mọi triển khai 302 là hỏng.

Thay mọi 302 bằng 307 để tăng SEO

Không có lợi ích thứ hạng. Chỉ đổi khi giữ phương thức/body cải thiện tính đúng đắn hoặc mặc định an toàn hơn của framework phù hợp.

Nhầm 303 với 307

Chúng đối lập về phương thức: 303 cố ý đổi yêu cầu theo sau thành GET; 307 giữ phương thức và body gốc.

Chẩn đoán 307 bất ngờ hoặc luồng 302 hỏng

DevTools hiển thị Internal Redirect / 307 không giải thích được

Triệu chứng: Điều hướng http:// xuất hiện như 307 trong Chrome nhưng không có quy tắc chuyển hướng.

Nguyên nhân có thể: HSTS nâng cấp yêu cầu trong trình duyệt trước khi đến máy chủ.

Cách sửa: Kiểm tra initiator và header rồi gửi yêu cầu không tự theo chuyển hướng trực tiếp đến URL HTTP bằng công cụ phía máy chủ, không dùng trình duyệt vì cả cửa sổ Incognito mới vẫn có thể áp dụng HSTS preload. curl cũng không mặc định trung lập vì có thể có kho HSTS riêng; ghi rõ cách gọi. Nếu phản hồi máy chủ thô khác DevTools, đừng “sửa” 307 ảo; audit riêng chuyển hướng HTTP→HTTPS thật. Phát lại yêu cầu không phải GET trong phép kiểm soát riêng; HEAD tự theo không chứng minh hành vi POST/body.

POST mất body sau chuyển hướng tạm thời

Triệu chứng: Biểu mẫu, webhook, đăng nhập hoặc API đến đích dưới dạng GET hoặc không có payload.

Nguyên nhân có thể: Nguồn dùng 302, cho phép client đổi phương thức, hoặc trung gian viết lại phản hồi.

Cách sửa: Dùng 307 cho lần chuyển tạm thời rồi phát lại yêu cầu thử nghiệm an toàn; xác nhận trong log đích rằng phương thức, content type và body đến nguyên vẹn.

Nền tảng phát 307 dù bạn chọn chuyển hướng chung

Triệu chứng: Framework hoặc nền tảng edge trả 307 thay vì 302 dự kiến.

Nguyên nhân có thể: Nền tảng chọn mã tạm thời giữ phương thức, thường cho yêu cầu không phải GET.

Cách sửa: Xác minh lần chuyển thật sự tạm thời và giữ yêu cầu là đúng. Nếu đúng, giữ mã vì Google xử lý giống nhau. Chỉ đổi khi ngữ nghĩa ứng dụng hoặc tương thích client yêu cầu phản hồi khác.

So sánh nhanh 302 và 307

Quy tắc kinh nghiệm: trang GET tạm thời thông thường → mã nào cũng được; yêu cầu tạm thời không phải GET phải đến nguyên vẹn → 307.

Công cụ xác định chuyển hướng thực sự nhận được

Công cụ miễn phí của Patrick

• Bulk HTTP Status Code Checker — gửi yêu cầu phía máy chủ cho tối đa 500 URL và xem mã cùng chuỗi thật. Đặc biệt hữu ích để tách phản hồi máy chủ khỏi hiển thị 307 nội bộ chỉ do HSTS của Chrome.

Kiểm tra hành vi yêu cầu

• Redirect Checker — theo một nguồn qua từng hop và xác nhận máy chủ bắt đầu bằng 302 hay 307.
• Bảng Network trong DevTools — xem initiator và Chrome có gắn nhãn internal redirect không; không coi riêng điều đó là bằng chứng phản hồi máy chủ.
• curl cùng log ứng dụng — gửi POST an toàn đến staging và xác nhận đích nhận cùng phương thức/body. Nếu cấu hình kho HSTS cho curl bằng --hsts, phải tính đến khi diễn giải. Công cụ chỉ xem trạng thái không chứng minh payload đến.

Tự kiểm tra: 302 và 307

Năm câu hỏi về hai chuyển hướng tạm thời và khác biệt thật giữa chúng. Chọn đáp án rồi kiểm tra kết quả.

Tài nguyên đáng đọc

Bài viết liên quan của tôi

• 11 loại chuyển hướng và tác động SEO (Ahrefs, cùng Joshua Hardwick) — tổng quan mọi loại chuyển hướng, nơi tôi nêu thứ tự tạm thời 307 / 302 / 303 > meta refresh 0 / HTTP refresh 0 và kết luận: “For SEO, it’s the same, but if you have data being sent through forms that redirect, then you don’t want to be swapping between GET and POST.” (bản dịch) «Với SEO chúng giống nhau, nhưng nếu biểu mẫu gửi dữ liệu qua chuyển hướng thì không nên đổi giữa GET và POST.»
• Mã trạng thái HTTP và tác động SEO — tham chiếu mọi mã, gồm hai nghĩa của 307 (Temporary Redirect và HSTS Policy 307) cùng lưu ý HSTS: “Google won’t see the 307 because it’s cached in the browser.” (bản dịch) «Google không thấy 307 vì nó được cache trong trình duyệt.»
• Hướng dẫn nhập môn Technical SEO — vị trí của chuyển hướng trong bức tranh lớn.

Bài nói của tôi

• Patrick Stox trên SlideShare và Speaker Deck — các bài nói technical SEO có đề cập chuyển hướng và canonical hóa. Lưu ý thường trực: “Đây là cách tôi hiểu hệ thống; nội dung không thể đầy đủ hoặc chính xác 100%.”

Nguồn chính thức

• Google — Mã trạng thái HTTP, lỗi mạng và DNS — dòng “Equivalent to 302” và lưu ý khác ngữ nghĩa.
• Google — Chuyển hướng và Google Tìm kiếm — gom 302/303/307 thành tạm thời.
• Search Off the Record — “Bàn về chuyển hướng” — thảo luận Mueller/Splitt làm nguồn cho trích dẫn trên.

Nguồn trong ngành

• John Mueller — 307s — giải thích rõ nhất về “307 ảo” HSTS mà trình duyệt hiển thị nhưng máy chủ không gửi.
• MDN — 307 Temporary Redirect — định nghĩa giữ phương thức/body và lưu ý client cũ.
• Hướng dẫn chuyển hướng cho SEO (Search Engine Land, Helen Pollitt) — tổng quan chắc chắn.
• URL Redirects For SEO: A Technical Guide — tổng quan kỹ thuật khác.
• Quan niệm cần sửa: trang “302 vs 307” của Conductor khuyên dùng 302 thay 307 vì “302 is the safer SEO choice” (bản dịch) «302 là lựa chọn SEO an toàn hơn» và vì công cụ tìm kiếm xử lý 302 rõ ràng. Điều này mâu thuẫn tài liệu Google ghi 307 “Equivalent to 302”; cách xử lý 307 cũng được ghi rõ. Yếu tố quyết định thật chỉ là có cần giữ phương thức/body không.
• r/TechSEO — cộng đồng gỡ lỗi chuyển hướng và canonical hóa.

Nhật ký thay đổi