Redirect 301 vs 302 trong .htaccess | Freelancer VN chuyển domain/hosting【2026】

Freelancer Việt Nam nhận việc chuyển domain, đổi hosting (Hostinger, Vietnix, AZDigi, AWS Lightsail…), hoặc ép HTTPS sau khi gắn SSL gần như luôn đụng redirect. Khách hỏi “sao Google vẫn index bản cũ?” — nửa số lần là vì dùng 302 thay 301, hoặc redirect vòng giữa www / không www / http.

Bài này tập trung quyết định đúng mã, viết rule an toàn trên Apache, và khi nào bỏ .htaccess để dùng panel / Cloudflare.

Bài viết này giúp bạn

• Phân biệt 301 vs 302 theo ngữ cảnh migrate (không chỉ định nghĩa sách)
• Viết redirect trang, www↔apex, ép HTTPS
• Tránh loop, 500, và cache trình duyệt giả “đã ổn”
• Chọn Apache .htaccess vs host panel vs Cloudflare
• Checklist trước khi bàn giao khách

301 vs 302: quyết định trước khi viết file

Sai phổ biến ở freelancer VN

1. Dùng 302 vì sợ “không quay lại được” — Redirect không xóa nội dung server; đổi lại rule là được. Migrate xong mà để 302 = SEO chậm vài tuần đến vài tháng.
2. 301 từng trang nhưng để http://www và https://apex song song — Google vẫn thấy hai canonical. Redirect phải gom về một URL chuẩn.
3. Copy rule từ blog nước ngoài có khoảng trắng sai trong %{HTTP_HOST} → site 500 ngay sau upload.

Quy tắc nhớ: Nếu sau 30 ngày URL cũ không còn phục vụ traffic chính → 301. Chỉ 302 khi bạn chắc sẽ trả URL cũ về trạng thái cũ.

Apache .htaccess: mẫu thực tế

.htaccess đặt ở thư mục gốc site (thường public_html / www). Backup file cũ trước khi sửa — một dấu cách sai có thể 500 toàn site.

1) Redirect một path

Redirect 301 /landing-cu.html https://example.com/dich-vu/

Hoặc với mod_rewrite (linh hoạt hơn khi có điều kiện):

RewriteEngine On
RewriteRule ^blog/bai-cu/?$ https://example.com/blog/bai-moi/ [R=301,L]

2) Ép HTTPS (http → https)

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

3) Apex → www (hoặc ngược lại)

# example.com → www.example.com
RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

# www → apex
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

Thứ tự quan trọng: Thường gom host (www/apex) và scheme (https) thành một chuỗi để tránh A→B→C nhiều hop. Mỗi hop thêm latency và dễ confuse crawler.

4) Domain cũ → domain mới

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?old-brand\.vn$ [NC]
RewriteRule ^(.*)$ https://new-brand.vn/$1 [R=301,L]

Đặt rule này trên hosting còn giữ domain cũ (DNS vẫn trỏ về đó). Domain mới chỉ cần nhận traffic — không redirect ngược lại.

Sinh rule nhanh (tránh gõ tay sai)

Khi chỉ cần một cặp from → to với mã 301/302, tạo .htaccess trên Kawa sinh khối RewriteEngine + RewriteCond + RewriteRule trong trình duyệt — không upload cấu hình lên server lạ. Dán vào file sau khi đã backup.

Generator phù hợp redirect từng pattern; rule phức tạp (nhiều điều kiện, exclude admin WordPress, proxy) nên viết tay hoặc dùng panel chuyên dụng.

Apache vs panel hosting vs Cloudflare

Freelancer VN thường không “chỉ có Apache thuần”. Chọn lớp redirect đúng để tránh hai nơi cùng redirect (loop hoặc double hop).

Khi nào ưu tiên Cloudflare / panel

• Khách đã dùng Cloudflare DNS + proxy: Redirect Rules / Bulk Redirects dễ audit hơn .htaccess trên shared host.
• Hosting Nginx (một số VPS “tối ưu tốc độ”): đừng dán .htaccess — file bị bỏ qua, bạn tưởng đã redirect.
• WordPress + plugin redirect: ổn cho marketing, nhưng migrate domain nên có rule ở web server/CDN để không phụ thuộc PHP khi site lỗi.

Case study 1: Freelancer chuyển .com → .vn

Tình huống: Landing agency trên oldstudio.com, khách mua oldstudio.vn, hosting Apache + Cloudflare.

Làm đúng:

1. DNS domain mới trỏ hosting mới, SSL Let’s Encrypt xanh.
2. Trên Cloudflare (domain cũ): Bulk Redirect https://oldstudio.com/* → https://oldstudio.vn/$1 với 301.
3. Search Console: thêm property domain mới, giữ property cũ để theo dõi 404.
4. Cập nhật sitemap, canonical, và link trong email chữ ký / Facebook page.

Làm sai (thật): Rule 302 “tạm vài tuần”. Sau 6 tuần Google vẫn ưu tiên .com trong vài từ khóa brand — khách nghĩ “SEO chết vì đổi domain”. Đổi sang 301 + đợi crawl lại thì ổn định.

Case study 2: Ép HTTPS nhưng quên www

Site có cả http://example.vn, https://example.vn, https://www.example.vn. Chỉ ép HTTPS trên apex → www vẫn HTTP hoặc không redirect.

Checklist tối thiểu:

1. curl -I http://example.vn → 301 → https://… (canonical)
2. curl -I http://www.example.vn → cùng canonical
3. curl -I https://www.example.vn → cùng canonical (nếu chọn apex)
4. Không còn chuỗi 301→302→301

Dùng cửa sổ ẩn danh hoặc curl — Chrome cache 301 rất lâu, dễ báo cáo sai cho khách.

Lỗi thường gặp và cách xử lý

Checklist bàn giao khách (copy vào PR / email)

1. Canonical URL chốt: https:// + www hoặc apex
2. Mọi redirect migrate là 301 (trừ bảo trì có ngày kết thúc)
3. curl -I 5–10 URL mẫu (trang chủ, 2 blog, 1 landing, 1 URL đã đổi slug)
4. Không double redirect CF + .htaccess cùng logic
5. Sitemap + canonical trong HTML trỏ domain mới
6. Backup .htaccess / export Cloudflare rules

FAQ ngắn (thực địa)

WordPress có cần .htaccess không? Có permalink thì WP ghi block riêng — chèn redirect phía trên block # BEGIN WordPress, hoặc dùng Redirect ở CDN để khỏi đụng file WP ghi đè.

301 có mất backlink không? Không “xóa” backlink; 301 giúp chuyển phần lớn tín hiệu. Vẫn nên xin cập nhật link quan trọng (báo chí, đối tác) sang URL mới khi có thể.

Bao lâu Google nhận? Thường vài ngày đến vài tuần tùy crawl. Search Console → Page indexing giúp theo dõi URL cũ còn “Found” không.

Công cụ liên quan

• Tạo .htaccess (301/302) — sinh rule Rewrite trong trình duyệt
• Kiểm tra DNS / CNAME — xác nhận domain đã trỏ đúng trước khi kết luận redirect lỗi
• Kiểm tra SSL — HTTPS xanh trước khi ép redirect

Migrate domain/hosting không cần “phép thuật SEO”. Cần một canonical, 301 đúng chỗ, và kiểm tra bằng header thay vì cảm giác trình duyệt.