Redirect 301 là gì và khi nào cần dùng

Đội ngũ KDIGIĐăng 03/11/202612 phút đọc

Redirect 301 là mã trạng thái HTTP cho biết một URL đã chuyển vĩnh viễn sang URL khác. Trình duyệt và Googlebot tự động đi theo đến địa chỉ mới, và Google dùng 301 như tín hiệu rằng URL đích nên là bản chính (canonical) hiển thị trong kết quả tìm kiếm. Dùng khi đổi slug, đổi domain, gộp trang hoặc chuẩn hoá www/https.

Tóm tắt nhanh

301 (và 308) là chuyển hướng vĩnh viễn; 302, 303, 307 là tạm thời. Google hiển thị URL đích với redirect vĩnh viễn, còn với redirect tạm thời thì giữ URL nguồn trong kết quả.

Dùng 301 khi đổi slug, đổi cấu trúc URL, đổi domain, gộp nội dung trùng lặp, chuẩn hoá http → https và www ↔ non-www.

Cách tốt nhất là redirect phía server (Nginx, Apache, middleware); redirect bằng JavaScript chỉ là phương án cuối cùng.

Trỏ thẳng về URL đích cuối, tránh chuỗi A → B → C và vòng lặp.

Trang bị xoá thật sự: trả 404/410, đừng dồn hàng loạt về trang chủ (soft-404).

KDIGI CMS tự tạo redirect 301 khi bạn đổi slug trong admin, và lưu quy tắc trong collection redirects để frontend áp dụng.

Redirect 301 là gì

Khi trình duyệt yêu cầu https://example.com/cu, server có thể trả về phản hồi 301 Moved Permanently kèm header Location: https://example.com/moi. Trình duyệt tự gửi yêu cầu thứ hai đến URL mới; người dùng gần như không nhận ra. Với công cụ tìm kiếm, phản hồi này nói: "Trang này đã chuyển vĩnh viễn, hãy cập nhật chỉ mục sang địa chỉ mới."

HTTP/1.1 301 Moved Permanently
Location: https://example.com/moi

Google mô tả mục đích của redirect trong tài liệu của mình: chuyển site sang domain mới, chọn một URL chính (canonical) khi một trang truy cập được bằng nhiều URL, gộp hai website, hoặc đưa người dùng sang trang mới khi bạn xoá một trang.

301, 302, 307 và 308 khác nhau thế nào

Mã	Tên	Loại	Google xử lý
301	Moved Permanently	Vĩnh viễn	Dùng làm tín hiệu URL đích là canonical; kết quả tìm kiếm hiển thị URL đích
308	Permanent Redirect	Vĩnh viễn	Như 301; giữ nguyên phương thức HTTP (POST vẫn là POST)
302	Found	Tạm thời	Không dùng làm tín hiệu canonical; thường giữ URL nguồn
303	See Other	Tạm thời	Như 302
307	Temporary Redirect	Tạm thời	Như 302; giữ nguyên phương thức HTTP

Theo tài liệu "Redirects and Google Search", với redirect tạm thời, Googlebot vẫn đi theo nhưng quy trình lập chỉ mục không coi đích là canonical; trang đích vẫn có thể được lập chỉ mục nếu có tín hiệu canonical khác. Quy tắc chọn: chắc chắn không quay lại → vĩnh viễn (301/308); nếu chỉ muốn tạm đưa người dùng sang trang khác (ví dụ trang đang bảo trì) và giữ URL gốc trong kết quả → tạm thời (302/307).

Khi nào cần dùng redirect 301

Đổi slug hoặc cấu trúc URL. Ví dụ /2024/05/ten-bai/ → /ten-bai. Không có redirect, backlink và thứ hạng của URL cũ mất.
Chuyển domain hoặc chuyển CMS. Mỗi URL cũ phải 301 đến URL tương đương trên domain mới; xem bài chuyển WordPress sang headless CMS không mất SEO.
Chuẩn hoá phiên bản URL. http → https, www ↔ non-www, có/không dấu / cuối, chữ hoa/thường.
Gộp nội dung trùng lặp hoặc yếu. Hai bài cùng chủ đề gộp thành một, bài cũ 301 sang bài mới.
Thay trang đã xoá bằng trang thay thế thực sự tương đương (không phải trang chủ).
Sửa URL sai đã bị người khác link (ví dụ lỗi chính tả trong slug đã phát hành).

Khi nào KHÔNG nên dùng 301

Tình huống	Làm gì thay thế
Trang đã xoá, không có trang tương đương	Trả 404 hoặc 410; đừng redirect hàng loạt về trang chủ
Chỉ chuyển tạm (bảo trì, chiến dịch ngắn hạn)	Dùng 302/307
Muốn hai URL cùng tồn tại nhưng chỉ lập chỉ mục một	Dùng thẻ canonical, không redirect
URL sai chỉ trong nội bộ site	Sửa liên kết nội bộ thay vì dựa vào redirect
Bộ lọc/tham số theo dõi	Xử lý bằng canonical và cấu hình tham số, không redirect

Playbook migration của KDIGI CMS nói rõ: nội dung bị xoá nên để draft (trả 404) thay vì redirect về trang chủ, vì soft-404 gây hại SEO.

Redirect 301 ảnh hưởng SEO thế nào

Tín hiệu canonical: với redirect vĩnh viễn, Google coi URL đích là canonical và hiển thị nó trong kết quả.
Backlink: liên kết tới URL cũ vẫn dẫn người dùng và crawler đến đích; vì vậy cần giữ redirect đủ lâu.
Tên thay thế (alternate names): Google ghi nhận cả URL nguồn lẫn đích. URL cũ có thể thỉnh thoảng vẫn hiện trong kết quả khi truy vấn gợi ý người dùng quen URL cũ hơn; Google nói đây là bình thường và sẽ mờ dần.
Tốc độ: mỗi lần redirect thêm một vòng yêu cầu. Chuỗi dài làm chậm trang và lãng phí ngân sách crawl.
Không phải phép màu: redirect không "cứu" được nội dung kém; trang đích nên thực sự tương đương về nội dung.

Google khuyên dùng redirect phía server khi có thể. Thứ tự ưu tiên trong tài liệu của họ: server-side (301/308) → meta refresh tức thì (Google coi là vĩnh viễn) → JavaScript location (chỉ khi không còn cách nào, vì Google có thể không thấy nếu render lỗi) → "crypto redirect" (chỉ một liên kết giải thích, không nên dựa vào).

Cách cấu hình redirect 301

Nginx

# Một URL
location = /cu {
    return 301 https://example.com/moi;
}

# Chuẩn hoá www → non-www
server {
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

Apache (.htaccess)

# Một URL
Redirect permanent "/cu" "https://example.com/moi"

# Chuẩn hoá http → https
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Next.js

// next.config.ts
export default {
  async redirects() {
    return [
      { source: '/cu', destination: '/moi', permanent: true }, // 308
    ]
  },
}

Lưu ý: permanent: true trong Next.js trả về mã 308, tương đương 301 về mặt tín hiệu vĩnh viễn với Google. Với nhiều quy tắc động đến từ CMS, thường dùng middleware đọc danh sách redirect (xem bên dưới).

WordPress

Dùng plugin (Rank Math Redirections, Yoast Premium Redirect manager, Redirection) hoặc sửa .htaccess. Hãy nhớ plugin chỉ chạy khi WordPress còn sống; khi chuyển sang CMS khác, bạn phải xuất quy tắc ra.

Redirect trong KDIGI CMS

KDIGI CMS lưu quy tắc trong collection redirects, mỗi quy tắc thuộc một site:

Trường	Ý nghĩa
`from`	Đường dẫn nguồn, tự chuẩn hoá để bắt đầu bằng `/`
`to`	Đường dẫn đích nội bộ; URL ngoài bị từ chối khi lưu
`statusCode`	`'301'` hoặc `'302'` (chuỗi)
`isEnabled`	Bật/tắt quy tắc

Quy tắc kiểm tra khi lưu: from và to không được trùng nhau, và chuỗi redirect chỉ bị cảnh báo chứ không bị chặn. Hành vi tự động:

Đổi slug trong admin → hook autoRedirectOnSlugChange tạo một dòng redirects (301, bật) từ đường dẫn công khai cũ sang đường dẫn mới: /{slug}/ cho bài viết, trang, landing; /product/{slug}/ cho sản phẩm. Nếu đã có redirect từ đường dẫn đó thì bỏ qua, và việc lưu không bao giờ bị chặn vì lỗi redirect.
Cùng lần lưu đó, CMS xếp một job revalidate cho slug cũ để cache của trang cũ được làm mới.
Script đổi slug ngoài admin (Local API không có người dùng đăng nhập) có thể không tạo redirect; bạn phải tự tạo.

Frontend lấy danh sách qua REST:

curl -s 'https://cms.example.com/api/redirects?where[tenant][equals]=1&where[isEnabled][equals]=true&limit=1000&depth=0'

Vì CMS chỉ lưu quy tắc, frontend phải áp dụng chúng, thường ở middleware, và giới hạn số hop. Ví dụ ý tưởng cho Next.js middleware:

// middleware.ts (rút gọn)
import { NextResponse } from 'next/server'

export async function middleware(req) {
  const map = await getRedirectMap() // cache danh sách /api/redirects
  const hit = map.get(req.nextUrl.pathname)
  if (hit) {
    return NextResponse.redirect(new URL(hit.to, req.url), Number(hit.statusCode))
  }
}

Khi di chuyển từ WordPress, pipeline import sinh 301 từ permalink cũ ở phase redirects và cho phép thêm quy tắc thủ công trong staged/redirects/*.json. Trang lưu trữ taxonomy, trang tác giả, phân trang, feed, ?p=123 và đính kèm không tự sinh, bạn phải liệt kê và thêm. Xem chuyển từ WordPress, nội dung và cấu trúc và Headless API.

Lỗi redirect thường gặp

Lỗi	Hậu quả	Cách sửa
Chuỗi redirect (A → B → C)	Chậm, tốn crawl, tín hiệu yếu	Cập nhật quy tắc để A → C trực tiếp
Vòng lặp (A → B → A)	Trình duyệt báo lỗi, trang không truy cập được	Rà bảng quy tắc, kiểm thử bằng `curl -IL`
Dồn hàng loạt về trang chủ	Bị coi là soft-404	404/410 cho nội dung đã xoá
Dùng 302 thay 301 cho thay đổi vĩnh viễn	URL cũ còn trong kết quả	Dùng 301/308
Redirect bằng JavaScript	Google có thể không thấy khi render lỗi	Chuyển sang redirect server-side
Quên chuẩn hoá `https`/`www`	Nhiều URL cho cùng một trang	Một redirect chuẩn hoá duy nhất
Gỡ redirect quá sớm	Mất backlink, người dùng gặp 404	Giữ càng lâu càng tốt
Canonical mâu thuẫn với redirect	Tín hiệu trái chiều	Canonical của đích trỏ về chính nó

Cách kiểm tra redirect

# Xem chuỗi redirect và mã trạng thái
curl -sIL https://example.com/cu | grep -iE '^(HTTP|location)'

# Chỉ lấy mã cuối và URL cuối
curl -s -o /dev/null -w '%{http_code} %{url_effective}\n' -L https://example.com/cu

Kết quả mong đợi: một dòng 301 rồi 200 ở URL đích. Nếu thấy hai dòng 301 trở lên, bạn đang có chuỗi redirect. Với số lượng lớn, xuất danh sách URL cũ từ sitemap và chạy hàng loạt (vòng lặp while read), so với bảng ánh xạ. Sau đó dùng Search Console (Pages, URL Inspection) để xác nhận Google nhìn thấy đúng đích.

Quy trình redirect an toàn khi đổi URL

Lập bảng URL cũ → URL mới trước khi đổi bất cứ thứ gì.
Mỗi URL một trong ba kết cục: giữ nguyên, 301 sang trang tương đương, hoặc 404/410 có chủ ý.
Đảm bảo đích của mọi redirect trả 200 (không phải đích cũng là redirect).
Cập nhật liên kết nội bộ, sitemap, canonical về URL mới.
Kiểm thử toàn bộ bảng bằng curl trước khi lên production.
Giữ redirect lâu dài và theo dõi báo cáo Pages trong Search Console.

Thêm một lưu ý cho website đang tối ưu hiển thị trong AI: URL ổn định và có redirect đúng giúp các hệ thống thu thập (kể cả các crawler AI) không gặp trang chết; xem llms.txt là gì và cách tối ưu website cho AI. Về dữ liệu có cấu trúc gắn với URL chính, xem Schema markup và JSON-LD là gì.

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

Redirect 301 là gì?

Redirect 301 là mã phản hồi HTTP "Moved Permanently", báo rằng một URL đã chuyển vĩnh viễn sang URL khác. Trình duyệt tự đi theo đến địa chỉ mới, còn Google dùng nó như tín hiệu rằng URL đích nên là bản chính trong kết quả tìm kiếm. Dùng khi đổi slug, đổi domain, gộp trang hoặc chuẩn hoá https và www.

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

301 là chuyển hướng vĩnh viễn: Google coi URL đích là canonical và hiển thị nó trong kết quả. 302 là tạm thời: Google vẫn đi theo nhưng không dùng làm tín hiệu canonical và thường giữ URL nguồn. Chọn 301 khi chắc chắn không quay lại, 302 khi chỉ tạm đưa người dùng sang trang khác như lúc bảo trì.

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

Redirect 301 đặt đúng là cách Google khuyên dùng để chuyển URL mà vẫn giữ tín hiệu. Thứ hạng thường giảm do các lỗi đi kèm: thiếu redirect cho một số URL, chuỗi redirect dài, đích không tương đương nội dung, hoặc gỡ redirect quá sớm. Dao động ngắn hạn sau khi đổi URL vẫn có thể xảy ra.

Có nên redirect trang đã xoá về trang chủ không?

Không nên. Redirect hàng loạt về trang chủ khi nội dung đã xoá thường bị coi là soft-404 và không giúp người dùng. Nếu có trang tương đương thật sự thì 301 sang trang đó; nếu không thì trả 404 hoặc 410. Playbook của KDIGI CMS cũng khuyên để bài ở trạng thái nháp, trả 404, thay vì redirect về trang chủ.

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

Càng lâu càng tốt. Backlink và dấu trang cũ có thể trỏ đến URL cũ nhiều năm, và gỡ redirect sớm khiến người dùng gặp 404 và mất tín hiệu. Với di chuyển site, hãy đối chiếu mốc thời gian trong tài liệu site move của Google và chỉ gỡ khi lượt truy cập vào URL cũ gần như bằng không.

Làm sao tạo redirect 301 trong KDIGI CMS?

Có hai cách. Đổi slug của bài viết, trang, landing hoặc sản phẩm trong admin: CMS tự tạo redirect 301 từ đường dẫn cũ sang mới. Hoặc thêm thủ công trong collection redirects với from, to (đường dẫn nội bộ), statusCode 301 và isEnabled. Frontend của bạn đọc danh sách qua REST và áp dụng ở middleware.

Nguồn

Google Search Central, Redirects and Google Search
Google Search Central, Site move with URL changes
IETF, RFC 9110: HTTP Semantics, mục 15.4 Redirection 3xx
Next.js, Redirects trong next.config.js
KDIGI CMS, tài liệu SEO, REST API và migration playbook tại github.com/kdigivn/kdigi-cms-open (docs/seo.md, docs/rest-api.md, docs/wordpress-migration/playbook.md)