Chuyển hướng 301, 302, gom www và HTTPS: làm một lần cho đúng

Mỗi trang chỉ nên có một địa chỉ chính thức, và mọi biến thể khác (http://, có hoặc không có www) phải chuyển hướng vĩnh viễn về địa chỉ đó bằng mã 301 (hoặc 308), trong đúng một bước. Chuyển hướng tạm thời 302 cho việc này không làm site sập, nhưng gửi cho Google tín hiệu yếu và mơ hồ: "địa chỉ cũ vẫn là địa chỉ chính, chỉ tạm thời gửi người dùng sang chỗ khác". Làm đúng một lần ở tầng máy chủ là xong việc trong nhiều năm; làm sai thì lỗi nằm im và rỉ dần tín hiệu xếp hạng mà không ai để ý.

Bốn mã chuyển hướng và ý nghĩa với Google

Mã	Loại	Google hiểu là	Dùng khi
301	Vĩnh viễn	Tín hiệu mạnh: địa chỉ đích là bản chính thức	Gom http về https, gom www, đổi URL bài, chuyển tên miền
308	Vĩnh viễn, giữ nguyên phương thức	Như 301	Như 301, khi cần giữ POST (API, biểu mẫu)
302 / 303	Tạm thời	Tín hiệu yếu: địa chỉ cũ vẫn là bản chính	Trang khuyến mãi tạm, chuyển theo vùng, đăng nhập
307	Tạm thời, giữ nguyên phương thức	Như 302	Ít dùng cho SEO

Google có nói rằng chuyển hướng tạm thời để lâu có thể dần được coi như vĩnh viễn. Đừng dựa vào điều đó: bạn không biết "lâu" là bao lâu, và trong khoảng thời gian đó Google có thể giữ URL cũ trong kết quả. Một điểm đáng chú ý khác: trình duyệt ghi nhớ chuyển hướng 301 rất dai. Nếu bạn thử nghiệm một 301 sai trên máy mình, trình duyệt sẽ tiếp tục chuyển hướng sai kể cả sau khi bạn đã sửa máy chủ. Kiểm chuyển hướng bằng curl hoặc cửa sổ ẩn danh, đừng tin vào trình duyệt quen dùng.

Chuyển hướng bằng thẻ meta refresh hay bằng JavaScript cũng được Google xử lý, nhưng JavaScript chỉ chạy sau bước dựng trang, chậm và kém chắc chắn hơn. Gom tên máy và giao thức luôn làm ở máy chủ.

Gom HTTPS và www: cấu hình mẫu

Chọn một dạng chính thức, ví dụ https://vidu.com (không www). Ba biến thể còn lại phải về thẳng đó:

• http://vidu.com/bai-a → https://vidu.com/bai-a
• http://www.vidu.com/bai-a → https://vidu.com/bai-a (một bước, không ghé qua https://www)
• https://www.vidu.com/bai-a → https://vidu.com/bai-a

Với nginx, cách gọn nhất là tách khối máy chủ riêng cho các biến thể:

server {
    listen 80;
    server_name vidu.com www.vidu.com;
    return 301 https://vidu.com$request_uri;
}
server {
    listen 443 ssl;
    server_name www.vidu.com;
    # chứng chỉ phải có cả www.vidu.com
    return 301 https://vidu.com$request_uri;
}
server {
    listen 443 ssl;
    server_name vidu.com;
    # nội dung site ở đây
}

Với Apache qua .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://vidu.com%{REQUEST_URI} [L,R=301]

Hai điều kiện gộp bằng [OR] giúp http://www về đích trong một bước. Viết thành hai luật tách rời là cách phổ biến tạo ra chuỗi hai bước. Nếu site nằm sau Cloudflare hoặc một bộ cân bằng tải, biến %{HTTPS} ở máy chủ gốc có thể luôn là off vì kết nối tới máy gốc là http, dẫn tới vòng lặp chuyển hướng; khi đó dựa vào tiêu đề X-Forwarded-Proto hoặc bật chuyển https ngay tại Cloudflare.

Sau khi chuyển hướng chạy ổn định ít nhất vài tuần, có thể thêm tiêu đề Strict-Transport-Security để trình duyệt tự dùng https. Cẩn thận với includeSubDomains và preload: một tên miền phụ nào đó chưa có chứng chỉ sẽ không mở được nữa, và gỡ khỏi danh sách nạp sẵn của trình duyệt mất nhiều tháng.

Lỗi hay gặp

Chuỗi chuyển hướng nhiều bước

Lỗi điển hình: http://www.vidu.com → https://www.vidu.com → https://vidu.com → https://vidu.com/. Googlebot theo được tới 10 bước nên trang vẫn được lập chỉ mục, nhưng mỗi bước là một lượt mạng thêm cho người dùng đầu tiên (trên di động là vài trăm mili giây), và chuỗi dài làm tăng khả năng một mắt xích bị gãy khi đổi cấu hình. Công cụ của SEO Gốc cảnh báo từ hai bước trở lên.

Cả www và không-www cùng trả 200

Hai địa chỉ phục vụ cùng nội dung là trùng lặp tên máy. Google thường tự chọn một bản và gom, đặc biệt nếu thẻ canonical trỏ đúng, nhưng liên kết ngoài trỏ vào bản kia bị chia tín hiệu, và báo cáo Search Console tách làm hai. SEO Gốc chấm nửa điểm nếu bản phụ có canonical trỏ về bản chính, không điểm nếu không có.

Chuyển hướng và canonical nói hai ý khác nhau

Máy chủ chuyển mọi thứ về https://vidu.com nhưng thẻ canonical trong mã nguồn lại ghi https://www.vidu.com (thường do cấu hình URL gốc của mã nguồn chưa sửa sau khi đổi). Google nhận hai tín hiệu ngược nhau và phải tự đoán. Sau mỗi lần đổi tên máy chính thức, kiểm cả bốn chỗ: chuyển hướng máy chủ, canonical, sitemap, liên kết nội bộ.

Chứng chỉ thiếu tên www

Chứng chỉ cấp cho vidu.com mà không có www.vidu.com: người gõ www thấy cảnh báo bảo mật trước khi kịp được chuyển hướng, vì trình duyệt kiểm chứng chỉ trước khi nhận phản hồi 301. Chuyển hướng không cứu được lỗi chứng chỉ. Khi cấp chứng chỉ, luôn gồm cả hai tên.

Đổi URL hàng loạt về trang chủ

Xoá một chuyên mục rồi chuyển mọi bài cũ về trang chủ: Google thường coi đó là "soft 404" (trang không tồn tại trá hình) và không chuyển tín hiệu của bài cũ sang đâu cả. Chuyển về trang có nội dung tương đương; không có thì để 404 hoặc 410 là trung thực hơn.

Gỡ chuyển hướng quá sớm khi đổi tên miền

Google khuyên giữ chuyển hướng khi chuyển site càng lâu càng tốt, tối thiểu một năm. Gỡ sau ba tháng là liên kết ngoài trỏ về tên cũ thành vô dụng, và người dùng còn lưu dấu trang cũ gặp lỗi.

Những việc không cần làm

• Không cần lo "301 làm mất sức mạnh liên kết": Google đã xác nhận các chuyển hướng 30x không làm hao PageRank. Lý do tránh chuỗi dài là tốc độ và độ bền, không phải hao hụt.
• Không cần đóng cổng 80. Đóng hẳn http thì người gõ địa chỉ không có https sẽ không vào được; mở cổng 80 chỉ để trả 301 là cách đúng.
• Không cần chuyển hướng giữa có và không có dấu gạch chéo cuối nếu canonical và liên kết nội bộ đã nhất quán, nhưng chọn một kiểu và giữ nguyên cho cả site thì gọn hơn.

Khi đổi cấu trúc URL: lập bảng ánh xạ trước

Đổi đường dẫn bài từ /2024/05/ten-bai.html sang /bai/ten-bai là lúc chuyển hướng dễ hỏng nhất. Trước khi đổi, xuất toàn bộ URL cũ từ sitemap, từ báo cáo Trang trong Search Console và từ nhật ký truy cập máy chủ (nhật ký bắt được cả URL cũ mà sitemap đã quên). Mỗi URL cũ ghi một URL mới tương ứng; quy luật đơn giản thì viết một luật rewrite, quy luật lộn xộn thì dùng bảng tra (map trong nginx). Sau khi chạy, lấy ngẫu nhiên vài chục URL cũ kiểm bằng curl, rồi theo dõi báo cáo "Không tìm thấy (404)" trong Search Console vài tuần đầu.

Danh sách kiểm sau mỗi lần đổi cấu hình

curl -sI http://vidu.com/        # 301, Location: https://vidu.com/
curl -sI http://www.vidu.com/    # 301 thẳng tới https://vidu.com/
curl -sI https://www.vidu.com/   # 301, chứng chỉ hợp lệ
curl -sI https://vidu.com/       # 200
curl -sIL -o /dev/null -w '%{num_redirects}\n' http://www.vidu.com/   # phải là 1

Kiểm thêm một URL bài sâu, không chỉ trang chủ: có cấu hình chỉ chuyển đúng trang chủ còn đường dẫn bài bị rơi về /. Khi xong, mở sitemap xem mọi URL đã đúng dạng chính thức (bài sitemap XML có danh sách kiểm riêng).

Kiểm bằng SEO Gốc

Chấm điểm site thử ba việc ở mục này: http:// có trả 301/308 sang https không (4 điểm), biến thể www hoặc không-www có gom về một tên máy không (3 điểm), và trang chủ có phải qua từ hai bước chuyển hướng trở lên không. Lỗi chứng chỉ ở trang chính bị xếp mức nặng vì người dùng không vào được. Trọng số đầy đủ ở thang chấm điểm. Chuyện chuyển hướng ảnh hưởng tốc độ tải trang đầu tiên thế nào, xem bài TTFB và Core Web Vitals; hướng dẫn chuyển site chính chủ ở Google Search Central.