Chuyển hướng 303 (See Other)

303 See Other là gì, cách mẫu Post/Redirect/Get hoạt động, vì sao nó đổi yêu cầu sang GET hoặc HEAD, điểm khác với 302 và 307, cùng phạm vi hướng dẫn SEO thực tế.

Xuất bản lần đầu: 2 thg 7, 2026 · Cập nhật lần cuối: 22 thg 8, 2026 · Advanced
Ngôn ngữ

303 See Other là chuyển hướng HTTP tạm thời yêu cầu client lấy một URL khác bằng GET hoặc HEAD, bất kể phương thức ban đầu. Đây là cơ chế của mẫu Post/Redirect/Get: POST được xử lý, máy chủ trả 303, rồi trình duyệt lấy trang kết quả bằng GET để thao tác làm mới không gửi lại biểu mẫu. Khác 307 luôn giữ phương thức và 302 từng mơ hồ, hành vi đổi phương thức của 303 là rõ ràng. Đây là mẫu ứng dụng web, không phải công cụ di chuyển URL. Google chỉ xếp 303 trong nhóm chuyển hướng 3xx tạm thời/tín hiệu yếu cùng 302 và 307; không có hướng dẫn riêng từ Google hay Bing.

Tóm tắt — 303 (HTTP “303 See Other”) là chuyển hướng tạm thời yêu cầu client truy xuất một tài nguyên khác bằng GET hoặc HEAD, bất kể phương thức của yêu cầu ban đầu. Đây là nền tảng của mẫu Post/Redirect/Get (PRG): POST303 → trang kết quả GET, nhờ đó thao tác làm mới tải lại trang thay vì gửi lại biểu mẫu. Nó khác 307, mã luôn giữ phương thức, và khác 302, mã có lịch sử xử lý phương thức không rõ ràng. 303 hiếm khi là chuyển hướng SEO giữa các trang; nó là cơ chế ứng dụng web, không phải công cụ di chuyển URL. Google chỉ ghi 303 trong nhóm 3xx “tạm thời” cùng 302 và 307, tức tín hiệu canonical hóa yếu, và không có hướng dẫn riêng; tôi cũng không tìm thấy hướng dẫn riêng từ Bing. Đừng tạo ra thẩm quyền không tồn tại: hãy nói thẳng rằng chủ đề này có rất ít hướng dẫn.

Bản chất của 303

303 là mã trạng thái HTTP được trả về trong header phản hồi, trước phần body, với header Location trỏ đến URL client cần lấy tiếp. Ngữ nghĩa của nó hẹp và cụ thể: phản hồi cho yêu cầu của bạn nằm ở nơi khác, và bạn nên truy xuất nó bằng GET hoặc HEAD. Evidence for this claim RFC 9110 defines 303 See Other as directing the client to retrieve another resource identified by Location using GET or HEAD. Scope: HTTP semantics for 303 responses. Confidence: high · Verified: IETF: RFC 9110 §15.4.4 — 303 See Other

Hành vi truy xuất bằng GET hoặc HEAD là toàn bộ lý do 303 tồn tại như một mã riêng và là trục phân biệt ba loại chuyển hướng mang tính tạm thời.

303 với 302 và 307: câu hỏi về phương thức

Từ góc độ SEO, cả ba đều là chuyển hướng “tạm thời” và được Google xếp vào nhóm tín hiệu yếu. Về kỹ thuật, chúng trả lời khác nhau cho câu hỏi: client dùng phương thức HTTP nào khi theo chuyển hướng?

Ý nghĩaPhương thức của yêu cầu sau chuyển hướng
302 FoundTạm thờiTrong lịch sử không rõ ràng — nhiều client đổi POST thành GET nhưng đặc tả không bảo đảm, nên hành vi khác nhau
303 See OtherXem tài nguyên khác (tạm thời)GET hoặc HEAD — phương thức ban đầu được chủ ý thay đổi
307 Temporary RedirectTạm thờiLuôn được giữ nguyên — POST vẫn là POST, PUT vẫn là PUT

303 và 307 ra đời một phần để loại bỏ sự mơ hồ quanh 302. Muốn buộc phương thức chuyển thành GET sau khi gửi biểu mẫu, hãy dùng 303. Cần giữ phương thức ban đầu, chẳng hạn gửi lại POST đến endpoint mới, hãy dùng 307. 302 nằm ở khoảng giữa mang tính lịch sử và không xác định rõ hai hành vi đó.

Một khác biệt thực tế nữa: phản hồi 303 mặc định không thể cache, trong khi 301 có thể. Điều này hữu ích khi bạn không muốn trình duyệt hoặc CDN lưu nhầm đích chuyển hướng.

Mẫu Post/Redirect/Get, nói chính xác

PRG là trường hợp dùng chuẩn của 303 và là một mẫu thiết kế có chủ ý, đúng đắn, không phải trạng thái lỗi:

  1. Client gửi biểu mẫu bằng POST để tạo đơn hàng, đăng bình luận hoặc thực hiện thanh toán.
  2. Máy chủ xử lý tác dụng phụ rồi trả về 303 See Other với header Location trỏ đến URL kết quả có thể lấy bằng GET, như biên nhận, xác nhận hoặc chế độ xem tài nguyên đã cập nhật.
  3. Client theo chuyển hướng bằng GET hoặc HEAD. Lịch sử và nút làm mới của trình duyệt lúc này trỏ đến thao tác truy xuất an toàn, idempotent; tải lại chỉ lấy trang kết quả thay vì phát lại POST.

Lợi ích là thao tác làm mới thông thường không còn gửi lại biểu mẫu và không hiện hộp thoại “confirm form resubmission” (bản dịch) «xác nhận gửi lại biểu mẫu». Nhưng PRG chỉ ngăn đường phát lại cụ thể đó, không ngăn mọi lần ghi trùng và không bảo đảm xử lý đúng một lần. Thử lại, hết thời gian chờ, nhấp đúp và yêu cầu đồng thời vẫn có thể gửi POST hai lần. Vì vậy, đơn hàng, thanh toán hay bình luận vẫn cần kiểm soát ở tầng ứng dụng như khóa idempotency, ranh giới giao dịch và phát hiện yêu cầu trùng. Trong API REST, 303 cũng có thể xuất hiện sau PUT hoặc DELETE để đưa client đến biểu diễn của tài nguyên bị ảnh hưởng.

Google xử lý 303 thế nào

Phát hiện cốt lõi và trung thực là Google không có hướng dẫn SEO riêng cho 303. Mã này chỉ xuất hiện như một hàng trong bảng chuyển hướng “tạm thời”, cạnh 302 và 307. Cách Google mô tả cả nhóm rất chính xác: crawler theo chuyển hướng, nhưng hệ thống lập chỉ mục không dùng chính chuyển hướng làm tín hiệu rằng đích nên là canonical; các tín hiệu khác vẫn có thể khiến Google lập chỉ mục đích. Phạm vi đó hẹp hơn tín hiệu canonical hóa mạnh của 301 vĩnh viễn. Evidence for this claim Google groups HTTP 303 with temporary redirects, follows it, and does not use it as a signal that the destination should become canonical. Scope: Google Search canonicalization behavior for server-side temporary redirects. Confidence: high · Verified: Google: Redirects and Google Search

Bài viết không chính thức của John Mueller về các loại chuyển hướng còn nói rõ hơn. Sau khi trình bày 301, 302 và 307, ông chỉ lướt qua 303: “What about 303? 304.5? If you have strong feelings about one of the other kinds of redirects, feel free to use them.” (bản dịch) «Còn 303? 304.5? Nếu bạn đặc biệt muốn dùng một loại chuyển hướng khác, cứ dùng.» Ý thực tế nằm ở câu sau: “We’ll have to figure out which URL to index the content under, so if you have strong feelings about that too, make sure to follow up with other canonicalization signals.” (bản dịch) «Chúng tôi vẫn phải xác định URL nào dùng để lập chỉ mục nội dung; nếu bạn quan tâm mạnh đến điều đó, hãy bổ sung các tín hiệu canonical hóa khác.» Nói cách khác, nếu dùng 303 và quan tâm URL nào được lập chỉ mục, đừng dựa vào loại chuyển hướng; hãy củng cố bằng rel="canonical", liên kết nội bộ và sitemap.

Tài liệu Google cũng lưu ý rằng dù xử lý các mã này giống nhau, bạn nên “keep in mind that they’re semantically different. Use the status code that’s appropriate for the redirect.” (bản dịch) «nhớ rằng chúng khác nhau về ngữ nghĩa; hãy dùng mã trạng thái phù hợp với chuyển hướng». Việc SEO không phân biệt không cho phép dùng 303 cho một lần chuyển vĩnh viễn; chọn mã đúng với ý định để các client khác hành xử chính xác.

Bing xử lý 303 thế nào

Tôi không tìm thấy hướng dẫn công khai riêng của Bing về cách xử lý 303 ngoài các tham chiếu chung đến mã trạng thái HTTP trong trợ giúp Bing Webmaster Tools. Không có phát biểu đã xác minh từ Fabrice Canel hay đại diện Microsoft khác dành riêng cho 303. Vì vậy, hoàn toàn có thể nói “chúng ta không có tài liệu”; đừng lấp khoảng trống bằng giả định rằng Bing làm giống Google. Thiếu tài liệu không chứng minh hành vi giống nhau; nếu cần câu trả lời dứt khoát cho riêng Bing, đó vẫn là câu hỏi mở.

303 có quan trọng với SEO không? Hiếm khi

Kết luận thẳng thắn của tôi, nhất quán với nội dung đã công bố, là 303 không phải công cụ di chuyển trang. Trong bài 11 loại chuyển hướng và tác động SEO, tôi viết: “A 303 redirect forwards the user to a resource similar to the one requested and is a temporary form of redirect. It’s typically used for things like preventing form resubmissions when a user hits the ‘back’ button in their browser. You won’t typically see 303 redirects used for SEO purposes, but if you do then it will be treated just like a 302/307.” (bản dịch) «Chuyển hướng 303 đưa người dùng đến tài nguyên tương tự tài nguyên được yêu cầu và là dạng chuyển hướng tạm thời. Nó thường ngăn gửi lại biểu mẫu khi người dùng bấm nút quay lại. Bạn thường không thấy 303 được dùng cho SEO; nếu có, nó sẽ được xử lý giống 302/307.»

Tôi cũng cần nêu một điểm chưa thống nhất trong nội dung cũ. Trong bài Mã trạng thái HTTP và tác động SEO, tôi từng mô tả cách xử lý 303 là “undefined… They may be treated as 301 or 302, depending on how they function.” (bản dịch) «chưa xác định… chúng có thể được xử lý như 301 hoặc 302 tùy cách hoạt động». Cách diễn đạt chính xác hơn hiện nay là tài liệu Google xếp 303 vào nhóm tạm thời/tín hiệu yếu cùng 302 và 307. Cảm giác “chưa xác định” trong thực tế đến từ việc 303 quá hiếm nên Google không cần làm rõ trường hợp biên, chứ không phải vì tồn tại một hành vi mạnh bí mật. Hãy lấy mặc định đã được ghi nhận làm chuẩn và coi bất ngờ là hệ quả của độ hiếm.

303 chỉ có thể đáng chú ý trên site có nhiều luồng biểu mẫu, thanh toán hoặc ứng dụng dựa trên API, nơi mã này xuất hiện trong báo cáo crawl. Ngay cả khi đó, câu trả lời thường là “đang hoạt động đúng, hãy để nguyên”. Nếu chủ ý chuyển URL, đừng dùng 303; dùng 301 cho vĩnh viễn, 302 cho tạm thời, hoặc 308/307 nếu cần giữ phương thức.

So sánh 303 với 201, 202 và 204 sau thao tác ghi

303 không phải lựa chọn duy nhất sau yêu cầu thay đổi trạng thái và không nên dùng chỉ vì thói quen. Trong API, khác với luồng biểu mẫu trình duyệt, ba mã 2xx thường phù hợp hơn:

  • 201 Created — yêu cầu đã tạo đồng bộ một hay nhiều tài nguyên; phản hồi nên xác định tài nguyên chính bằng Location nếu có, nếu không thì bằng chính URI đích. Dùng khi việc tạo đã xong và muốn client nhận tài nguyên mới trực tiếp, không cần thêm vòng GET.
  • 202 Accepted — yêu cầu đã được chấp nhận nhưng xử lý chưa hoàn tất, chẳng hạn công việc xếp hàng hoặc tác vụ bất đồng bộ. Phản hồi không đưa ra cam kết về kết quả sau cùng; hãy mô tả trạng thái hiện tại và tốt nhất là chỉ client đến trình theo dõi có thể thăm dò.
  • 204 No Content — thao tác thành công và không còn gì cần gửi: không body, không cần chuyển hướng; phản hồi kết thúc ở phần header.

303 phù hợp với một dạng khác: client cần truy xuất tài nguyên kết quả được xác định riêng sau thao tác ghi, thường là mẫu PRG trong trình duyệt. Nó không thay thế 201 cho tạo đồng bộ, 202 cho chấp nhận bất đồng bộ hay 204 cho thành công không có nội dung; mỗi mã truyền đạt một kết quả riêng mà chuyển hướng không thể hiện.

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

  • “303 nghĩa là trang đã chuyển hoặc bị hỏng.” Không. Đây là phản hồi có chủ ý làm đổi phương thức, thường sau POST/PUT/DELETE, không phải tín hiệu nội dung đã dời hay lỗi.
  • “303 truyền giá trị SEO như 301.” Không. Theo tài liệu Google, nó nằm trong nhóm tạm thời/tín hiệu yếu cùng 302 và 307.
  • “SEO nên dùng 303 như chuyển hướng chung.” Mã này được thiết kế cho mẫu biểu mẫu/API hẹp, không phải di chuyển URL thông thường.
  • “Google có quy tắc chi tiết riêng cho 303.” Không. Chỉ có một lần nêu theo nhóm và lời nhận xét ngắn của Mueller.
  • “303 và 302 giống hệt nhau về kỹ thuật.” Chúng có thể được xử lý tương đương trong tìm kiếm, nhưng 303 đổi yêu cầu tiếp theo sang GET hoặc HEAD, còn cách 302 xử lý phương thức từng không nhất quán; chính vì thế 303 và 307 được tạo ra.

Vị trí của 303 trong họ mã trạng thái

303 thuộc nhóm chuyển hướng tạm thời. Họ hàng gần nhất là 302, mã tạm thời linh hoạt thường được xếp cùng nhóm, và 307, đối cực giữ phương thức: 307 giữ phương thức còn 303 chuyển sang GET hoặc HEAD. Nó khác 301, chuyển hướng vĩnh viễn dùng để hợp nhất tín hiệu xếp hạng và thực hiện việc di chuyển URL mà 303 không được thiết kế cho. Xem cụm mã trạng thái HTTP để hiểu đầy đủ họ 301/308 vĩnh viễn, 302/303/307 tạm thời, 404/410 đã mất và lỗi 5xx.

Xác minh luồng 303 an toàn

Trước khi tin một 303 ngoài thực tế, hãy kiểm tra mà không tự động theo một cách mù quáng: xem giá trị Location có tuyệt đối, tương đối và phân giải được hay không; tìm vòng lặp hoặc chuỗi thừa; xác nhận yêu cầu tiếp theo thật sự dùng GET hoặc HEAD; rồi kiểm tra trạng thái và nội dung phản hồi cuối. Với luồng biểu mẫu hoặc API, xem cả nhật ký ứng dụng để chắc chắn thao tác ghi ban đầu không bị phát lại.

Đừng khái quát hành vi của một client thành quy tắc phổ quát. Hành vi tự theo chuyển hướng của trình duyệt, thư viện HTTP và framework thay đổi theo sản phẩm, phiên bản và cấu hình. Báo cáo về một client/phiên bản không phải bằng chứng cho tất cả. Công cụ kiểm tra URL có thể xác nhận chuyển hướng và hình dạng đích, nhưng không thể xác minh idempotency, cách xử lý thông tin xác thực hay an ninh khác origin; các điểm đó cần kiểm thử luồng gửi thật.

Try it live

This is a real endpoint on this site — not a simulation. Hit it from the button, open it in a new tab, or curl -i it from your terminal, and the server answers with the actual status code this article is about.

Open in new tab ↗

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.