Redirect 301 vs 302: Khác Nhau Thế Nào Và Khi Nào Dùng?

Redirect 301 và 302 khác nhau thế nào?

Redirect 301 cho biết tài nguyên đã chuyển vĩnh viễn sang URL mới. Redirect 302 cho biết việc chuyển hướng là tạm thời và URL gốc có thể quay lại. Với SEO, dùng 301 khi URL mới là đích lâu dài; dùng 302 khi bạn thực sự muốn Google tiếp tục xem URL gốc là đại diện.

Đây cũng là cách Google phân loại redirect vĩnh viễn và tạm thời. Trình duyệt đều có thể đưa người dùng tới trang đích, nên chọn sai status code thường không lộ ra bằng mắt. Hệ thống tìm kiếm vẫn phải quyết định URL nào nên giữ trong index.

Trước khi đi vào chi tiết, nếu bạn chưa nắm phần nền, xem thêm technical SEO là gì.

Chọn nhanh:

Đổi slug vĩnh viễn, gộp bài, chuyển domain, HTTP sang HTTPS: dùng 301 hoặc 308.
Trang bảo trì ngắn hạn, chiến dịch tạm, A/B test có kiểm soát: dùng 302 hoặc 307.
Request phải giữ nguyên method và body: ưu tiên 307 nếu tạm thời, 308 nếu vĩnh viễn.
Không có trang thay thế tương đương: trả 404 hoặc 410, đừng redirect về trang chủ.

Bảng so sánh 301, 302, 307 và 308

Code	Tính chất	Phương thức request	Tình huống
301	Vĩnh viễn	Có thể bị đổi trong thực tế client	Di chuyển URL marketing thông thường
302	Tạm thời	Có thể bị đổi	Chiến dịch hoặc thay đổi ngắn hạn
307	Tạm thời	Giữ nguyên	API hoặc form cần bảo toàn method
308	Vĩnh viễn	Giữ nguyên	Di chuyển vĩnh viễn cần bảo toàn method

Điểm khác biệt về method không phải mẹo SEO. Theo HTTP Semantics RFC 9110, 307 và 308 yêu cầu client không đổi method khi tự động redirect. Điều này đặc biệt quan trọng với request POST, form thanh toán và API.

Google xử lý redirect như thế nào?

Google xem redirect vĩnh viễn là tín hiệu mạnh cho URL đích canonical. Redirect tạm thời là tín hiệu yếu hơn cho việc giữ URL gốc. Nếu 302 tồn tại lâu, Google có thể suy luận việc di chuyển thực tế là vĩnh viễn. Không nên dựa vào suy luận này thay cho status code đúng.

Redirect là một tín hiệu canonicalization, không phải máy chuyển “toàn bộ sức mạnh” ngay lập tức. Google cần crawl URL cũ và mới, xử lý tín hiệu và cập nhật index. Trang đích phải có nội dung tương đương hợp lý.

6 tình huống và loại redirect nên dùng

1. Đổi slug bài viết

Dùng 301 từ slug cũ tới slug mới. Cập nhật internal link, canonical, sitemap và hreflang nếu có. Không để internal link tiếp tục đi qua redirect.

2. Gộp hai bài trùng intent

Chọn URL có nội dung và tín hiệu tốt hơn, hợp nhất phần hữu ích và 301 URL còn lại. Đọc Search Console trước khi xóa để không mất query có giá trị.

3. Chiến dịch tạm thời

Nếu URL gốc sẽ quay lại sau chiến dịch, 302 phù hợp. Đặt ngày kết thúc và owner. Redirect tạm không có ngày review rất dễ trở thành sai lầm vĩnh viễn.

4. A/B test

Giữ thời gian thử nghiệm hợp lý, dùng redirect tạm và canonical nhất quán theo hướng dẫn testing. Đừng cloaking nội dung khác bản chất cho Googlebot.

5. Chuyển HTTP sang HTTPS

Dùng redirect vĩnh viễn, một hop, trên toàn bộ URL tương ứng. Cập nhật canonical, sitemap, internal link và tài nguyên để không còn mixed content.

6. Xóa trang không có thay thế

Trả 404 hoặc 410. Redirect hàng loạt về trang chủ có thể bị xem như soft 404 và làm người dùng bối rối.

Chuỗi redirect, vòng lặp và 302 đặt nhầm chỗ hiếm khi lộ ra khi duyệt bằng mắt; đây là nhóm lỗi mà dịch vụ SEO audit rà bằng crawl toàn site và log status code.

Ví dụ cài redirect

Nginx

location = /duong-dan-cu {
  return 301 https://example.com/duong-dan-moi;
}

Apache

Redirect 301 /duong-dan-cu https://example.com/duong-dan-moi

WordPress

Có thể dùng plugin redirect, cấu hình máy chủ hoặc CDN. Với website lớn, quản lý redirect bằng code và version control dễ review, test và rollback hơn. Không cài nhiều plugin cùng xử lý redirect.

Kiểm tra response thật

curl -I https://example.com/duong-dan-cu
curl -IL https://example.com/duong-dan-cu

Lệnh đầu cho biết status và Location ở hop đầu. Lệnh thứ hai đi theo toàn bộ chuỗi để bạn phát hiện redirect chain. Hãy kiểm tra cả URL cũ lẫn trang đích, vì trình duyệt chỉ hiện URL cuối và có thể che mất một hop sai.

Checklist kiểm tra redirect sau khi deploy

URL cũ trả đúng 301/302/307/308, không phải 200 kèm JavaScript redirect.
Header Location trỏ tới URL tuyệt đối đúng.
Chỉ một hop, không chain hoặc loop.
Trang đích trả 200, indexable và self-canonical.
Sitemap chỉ chứa URL đích.
Internal link, hreflang và structured data dùng URL mới.
Không redirect tới trang không tương đương.
Theo dõi 404, index và traffic sau thay đổi.

Một lần đổi cấu trúc URL thường kéo theo sitemap, internal link và canonical phải sửa cùng lúc. Bài toán đó thuộc về kế hoạch SEO tổng thể chứ không dừng ở việc khai báo vài dòng 301.

Redirect ảnh hưởng GEO ra sao?

AI Search không cần một loại redirect riêng. Vấn đề là URL nguồn phải ổn định, có thể index và không tạo tín hiệu canonical mâu thuẫn. Redirect chain và URL thay đổi liên tục làm việc thu thập, hợp nhất tín hiệu và trích dẫn kém ổn định.

Sau khi di chuyển một bài có khả năng được trích dẫn, hãy cập nhật internal link, canonical, Article schema và sitemap. Để nối các tín hiệu này thành một hệ thống, xem Parent Pillar SEO Technical là gì, hướng dẫn tối ưu URL SEO bền vững, cách giữ sitemap chỉ chứa URL canonical và bài GEO là gì.

Cách lập redirect mapping cho migration

Bắt đầu bằng danh sách URL từ sitemap, crawl, Search Console, analytics, backlink export và log. Mỗi URL cũ được gán một trong các hành động: giữ nguyên, 301 tới trang tương đương, gộp nội dung, hoặc trả 404/410. Không dùng công thức thay chuỗi đơn giản nếu kiến trúc mới thay đổi ý nghĩa.

Ưu tiên URL có click, impression, backlink, lead và trang chuyển đổi. Review mapping bằng content owner, không chỉ developer. Hai URL có slug giống nhau chưa chắc cùng intent. Redirect sai tới trang không tương đương có thể tạo soft 404.

Trước một đợt migration lớn, bản đồ redirect nên được người thứ hai soi lại; brief SEO miễn phí là cách nhanh nhất để chúng tôi nhận danh sách URL cũ và nói trước điều đáng lo.

Meta refresh và JavaScript redirect có nên dùng không?

Redirect phía server là lựa chọn ưu tiên vì user agent nhận status và Location ngay. Meta refresh và JavaScript redirect có thể được Google xử lý, nhưng chậm hơn, phụ thuộc vào render và tạo trải nghiệm kém. Chỉ dùng khi không thể cấu hình server.

Nếu buộc dùng client-side, giữ delay bằng 0, cung cấp link HTML tới trang đích và kiểm tra rendering. Không hiển thị một trang có nội dung khác trong vài giây rồi chuyển, vì người dùng có thể bắt đầu đọc hoặc thao tác.

Tại sao redirect chain vẫn cần sửa?

Mỗi hop thêm request, độ trễ và điểm có thể lỗi. Chuỗi A → B → C → D thường xuất hiện sau nhiều lần đổi slug. Giữ redirect A để bảo toàn backlink cũ, nhưng cập nhật đích A trực tiếp tới D và sửa internal link trỏ thẳng D.

Redirect loop là lỗi P0 vì người dùng và bot không truy cập được. Test cả biến thể protocol, host, slash, chữ hoa và query. Quy tắc www/non-www kết hợp với app redirect rất dễ tạo vòng lặp khi proxy header bị đọc sai.

Theo dõi 30 ngày sau migration

Ngày 0: crawl URL cũ, URL mới, redirect, canonical, sitemap và hreflang.
Ngày 1–3: theo dõi 5xx, 404, loop, log Googlebot và trang chuyển đổi.
Tuần 1: xem Indexing, canonical Google chọn, click/impression và backlink quan trọng.
Tuần 2: crawl lại internal redirect, orphan, sitemap và chain.
Ngày 30: so query, landing page, lead và index coverage với baseline.

Không xóa redirect cũ sau vài tuần chỉ vì Google đã index URL mới. Backlink, bookmark và tài liệu cũ có thể tồn tại nhiều năm. Trong hướng dẫn site move có thay đổi URL, Google khuyến nghị giữ redirect ít nhất một năm và lâu hơn nếu có thể.

Đọc thêm: kiểm tra mobile friendly · cách thêm FAQ schema vào website đúng chuẩn google

Bộ test redirect tối thiểu

Test từng mapping ưu tiên và mẫu theo pattern.
Không có hai URL cũ trỏ nhầm vào một trang chung không liên quan.
Status vĩnh viễn/tạm thời đúng mục đích.
Header Location không tạo URL không hợp lệ.
Không có chain, loop hoặc mixed protocol.
Trang đích có content parity, 200, self-canonical và indexable.
Analytics và event tracking không ghi sai landing page.

Chọn redirect theo tình huống thực tế

Đổi slug bài viết đã public

Nếu URL mới thay thế lâu dài và giữ cùng nội dung, dùng 301 từ slug cũ sang slug mới. Sau đó sửa internal link, canonical, sitemap và mọi hreflang liên quan. Đừng để website tự tạo chuỗi qua nhiều lần đổi slug.

Landing page chiến dịch tạm thời

Nếu chuyển người dùng sang phiên bản thử nghiệm trong một khoảng ngắn và URL cũ sẽ quay lại, 302 hoặc 307 phù hợp hơn. Ghi ngày kết thúc để rule tạm thời không tồn tại vô hạn.

Sản phẩm hết hàng

Nếu chỉ tạm hết, giữ trang và thông báo thời gian dự kiến. Nếu ngừng vĩnh viễn, chỉ redirect khi có sản phẩm thay thế tương đương. Chuyển mọi sản phẩm hết hàng về trang danh mục hoặc trang chủ thường làm người dùng hụt hẫng và có thể bị xem là soft 404.

Chuyển HTTP sang HTTPS hoặc www sang non-www

Dùng redirect vĩnh viễn theo một hop duy nhất. Kiểm tra proxy và CDN để tránh vòng lặp, rồi bảo đảm canonical, sitemap và internal link đều dùng host đích.

Câu hỏi thường gặp

301 có làm mất thứ hạng không?

Redirect đúng tới trang tương đương giúp hợp nhất tín hiệu, nhưng Google cần thời gian crawl và xử lý. Biến động có thể xảy ra trong migration. Rủi ro lớn đến từ mapping sai, chain, trang đích kém và tín hiệu mâu thuẫn.

302 có truyền tín hiệu SEO không?

Google có thể xử lý redirect tạm và thậm chí suy luận redirect lâu ngày là vĩnh viễn. Tuy nhiên, nếu di chuyển là vĩnh viễn, hãy dùng 301/308 thay vì chờ Google suy luận.

Có nên redirect mọi 404 về trang chủ?

Không. Chỉ redirect khi có trang thay thế thực sự tương đương. Nếu không có, giữ 404/410 và cung cấp trang lỗi hữu ích cho người dùng.

Kết luận

Quy tắc cốt lõi của redirect 301 vs 302 rất ngắn: vĩnh viễn dùng 301, tạm thời dùng 302. Phần khó là mapping URL, giữ trang đích tương đương và cập nhật tất cả tín hiệu liên quan. Hãy kiểm tra response thực tế thay vì chỉ nhìn trình duyệt chuyển trang.