HTTPS: Chuyển Đổi Từ HTTP Và Những Lỗi Làm Mất Traffic

Chuyển từ HTTP sang HTTPS không phải thao tác bật một chứng chỉ rồi chờ Google tự hiểu. Đây là một đợt migration URL: toàn bộ tín hiệu, redirect, canonical, sitemap, liên kết nội bộ và dữ liệu đo lường phải đồng bộ với giao thức mới. Chỉ một vài lỗi như canonical vẫn trỏ HTTP hoặc quên thêm property HTTPS trong Google Search Console cũng đủ khiến traffic giảm trong nhiều ngày.

Bài này tập trung vào quy trình migration HTTP sang HTTPS và các điểm thường làm rớt traffic, thay vì đi dài về cơ chế mã hoá. Mục tiêu là chuyển đổi có kiểm soát, phát hiện lỗi nhanh và hạn chế tối đa thời gian Google phải xử lý lại URL.

HTTPS migration thực chất là thay đổi toàn bộ URL

Với công cụ tìm kiếm, http://example.com/page và https://example.com/page là hai URL khác nhau. Vì vậy, việc cài SSL thành công chưa đồng nghĩa website đã chuyển đổi xong. Bạn cần xác định URL HTTPS chính thức, sau đó dẫn Google và người dùng từ phiên bản cũ sang phiên bản mới bằng redirect 301.

Một migration chuẩn thường bao gồm các nhóm công việc sau:

• Cài và kiểm tra chứng chỉ SSL cho toàn bộ hostname cần dùng, gồm cả biến thể www nếu website có sử dụng.
• Chuyển redirect từ HTTP sang HTTPS bằng mã trạng thái 301, không dùng redirect tạm thời 302 cho migration vĩnh viễn.
• Cập nhật canonical, hreflang, sitemap XML, liên kết nội bộ, dữ liệu có cấu trúc và các URL trong template.
• Kiểm tra mixed content để tài nguyên như ảnh, CSS, JavaScript và iframe không còn gọi qua HTTP.
• Khai báo property HTTPS trong Google Search Console và cập nhật cấu hình đo lường, quảng cáo, CDN, cache hoặc hệ thống tracking.

Không nên triển khai HTTPS cùng lúc với một đợt redesign lớn, đổi tên miền, thay cấu trúc thư mục hoặc thay CMS nếu không bắt buộc. Khi nhiều biến động xảy ra cùng lúc, đội SEO rất khó phân biệt traffic giảm do giao thức, nội dung, technical SEO hay thay đổi layout.

Quy trình migration HTTP sang HTTPS theo từng bước

1. Lập bản đồ URL và sao lưu hiện trạng

Trước khi thay đổi, hãy crawl website HTTP và xuất danh sách URL đang trả về mã 200, 3xx, 4xx, 5xx, cùng các trường canonical, meta robots, hreflang và internal link. Nếu site lớn, có thể ưu tiên toàn bộ URL đã nhận organic click trong 16 tháng gần nhất và các URL đang có backlink, doanh thu hoặc chuyển đổi.

Lưu lại các chỉ số baseline theo ngày trong ít nhất 28 ngày gần nhất: organic sessions, clicks, impressions, CTR, số URL được lập chỉ mục, doanh thu SEO và tỷ lệ chuyển đổi. Con số 28 ngày là mốc vận hành để so sánh đủ nhiều ngày trong tuần; đây là ngưỡng theo dõi thực tế, không phải quy định bắt buộc của Google.

Đồng thời, kiểm tra website đang có những biến thể nào:

• http://example.com
• http://www.example.com
• https://example.com
• https://www.example.com

Chỉ một biến thể HTTPS nên là bản chính. Các biến thể còn lại cần redirect nhất quán về đúng hostname và giao thức đã chọn. Đừng mặc định rằng hệ thống hosting đã xử lý toàn bộ bốn trường hợp.

2. Cài chứng chỉ và kiểm tra môi trường staging

Chứng chỉ phải bao phủ các hostname thực tế, bao gồm subdomain quan trọng nếu chúng được crawl hoặc có traffic. Kiểm tra thời hạn chứng chỉ, chuỗi chứng thực, phiên bản TLS được máy chủ hỗ trợ và phản hồi khi truy cập bằng trình duyệt phổ biến. Sau khi cài, dùng công cụ crawl hoặc kiểm tra HTTP để xác nhận trang HTTPS trả về 200, không bị vòng lặp redirect.

Trên staging, kiểm tra tối thiểu các mẫu URL sau:

• Trang chủ, trang danh mục, bài viết, sản phẩm và trang có tham số.
• Trang đăng nhập, form, thanh toán hoặc khu vực cần cookie.
• Ảnh, file CSS, JavaScript, font, video, iframe và tài nguyên tải từ CDN.
• URL có slash cuối, không slash cuối, chữ hoa, ký tự đặc biệt và phiên bản có query string.

Nếu staging bị chặn bởi mật khẩu hoặc noindex, hãy chắc chắn cấu hình này không được đẩy nhầm lên production. Một lỗi triển khai noindex trên template chung có thể khiến hàng nghìn URL mất khả năng xuất hiện trên kết quả tìm kiếm.

3. Triển khai redirect 301 từ HTTP sang HTTPS

Redirect nên đưa từng URL HTTP đến URL HTTPS tương ứng, giữ nguyên path và tham số cần thiết. Ví dụ, http://example.com/dich-vu nên chuyển thẳng đến https://example.com/dich-vu, không vòng qua trang chủ hoặc một URL trung gian.

Nguyên tắc cần kiểm tra:

• HTTP trả về 301, không phải chuỗi nhiều bước như 301 > 302 > 200.
• URL HTTPS cuối cùng trả về 200 nếu là trang hợp lệ.
• Không redirect URL cũ về trang chủ chỉ vì chưa tạo mapping.
• Không để HTTP và HTTPS cùng trả về nội dung 200 mà không có tín hiệu canonical rõ ràng.
• Giữ nguyên các tham số quan trọng khi chúng phục vụ tracking hoặc lọc sản phẩm; loại bỏ tham số thừa bằng quy tắc có kiểm soát.

Ngưỡng vận hành nên đặt là một URL cũ chỉ qua tối đa một lần redirect trước khi đến URL đích. Một chain hai hoặc ba bước không phải lúc nào cũng làm mất toàn bộ tín hiệu, nhưng làm tăng độ trễ, khó crawl và dễ phát sinh lỗi khi nhiều lớp CDN, CMS và máy chủ cùng tham gia.

Bốn lỗi HTTPS thường làm rớt traffic

Mixed content: trang HTTPS nhưng tài nguyên vẫn gọi HTTP

Mixed content xảy ra khi HTML đã dùng HTTPS nhưng vẫn tải một phần tài nguyên bằng HTTP, chẳng hạn http://cdn.example.com/style.css hoặc ảnh nhúng từ URL HTTP. Với tài nguyên chủ động như JavaScript, CSS, font hoặc iframe, trình duyệt có thể chặn tải. Kết quả là giao diện vỡ, menu không hoạt động, nội dung chính không render đầy đủ hoặc bot không đọc được trang như mong muốn.

Cách xử lý không phải chỉ thay chuỗi trong một vài bài viết. Hãy rà soát database, template, file CSS, JavaScript, plugin, widget bên thứ ba và URL trong trường srcset. Với URL nội bộ, dùng HTTPS tuyệt đối. Với tài nguyên bên ngoài chưa hỗ trợ HTTPS, cần thay nhà cung cấp hoặc loại bỏ; không nên tiếp tục nhúng HTTP chỉ để giữ một hình ảnh phụ.

Kiểm tra tỷ lệ lỗi sau triển khai bằng log trình duyệt, crawl tài nguyên và báo cáo của hệ thống giám sát. Mục tiêu thực tế là 0 URL tài nguyên quan trọng bị gọi qua HTTP trong template và các trang có traffic cao.

Canonical vẫn trỏ về HTTP

Đây là lỗi phổ biến nhất khi đội phát triển chỉ bật redirect ở máy chủ nhưng quên cập nhật SEO plugin hoặc template. Trang đang mở tại HTTPS nhưng thẻ canonical lại là:

<link rel="canonical" href="http://example.com/bai-viet" />

Trong trường hợp này, Google nhận tín hiệu mâu thuẫn: URL HTTPS đang được truy cập, nhưng canonical đề xuất URL HTTP. Redirect có thể giúp Google hiểu ý định, nhưng không nên dựa vào việc Google tự sửa mọi tín hiệu. Canonical tự tham chiếu trên URL HTTPS nên trỏ đến chính URL HTTPS chuẩn, tuyệt đối không trỏ ngược về HTTP.

Hãy kiểm tra cả canonical do CMS sinh ra, canonical trong header HTTP, canonical ở trang phân trang, sản phẩm biến thể và URL có tham số. Sau khi sửa, crawl lại một nhóm URL đại diện rồi kiểm tra bằng công cụ kiểm tra URL trong Google Search Console.

Redirect chain và redirect loop

Chain thường xuất hiện khi website đã có quy tắc đổi hostname, thêm slash hoặc bỏ slash, rồi mới thêm HTTPS. Ví dụ: HTTP non-www chuyển sang HTTP www, sau đó sang HTTPS www, rồi tiếp tục chuyển vì slash. Người dùng vẫn có thể đến trang cuối, nhưng bot phải đi qua nhiều phản hồi.

Loop nghiêm trọng hơn: HTTP chuyển sang HTTPS, nhưng proxy hoặc CDN đọc sai header khiến HTTPS lại bị chuyển ngược về HTTP. Khi đó trang không tải được và cả người dùng lẫn bot đều thất bại.

Hãy test bằng nhiều lớp: trình duyệt, lệnh HTTP header, crawler và máy chủ ở môi trường production. Ghi nhận status code, URL đích, thời gian phản hồi và header Location. Các URL quan trọng nên hoàn tất trong một bước redirect và URL đích nên phản hồi trong khoảng dưới 2 giây ở điều kiện máy chủ bình thường. Đây là ngưỡng vận hành để phát hiện bất thường, không phải tiêu chuẩn xếp hạng cố định.

Quên đổi property trong Google Search Console

HTTPS là property riêng trong Google Search Console. Dữ liệu của http://example.com không tự biến thành dữ liệu đầy đủ cho https://example.com ngay lập tức. Nếu chỉ theo dõi property HTTP, bạn có thể tưởng rằng website mất click trong khi dữ liệu mới đang phân bổ ở property HTTPS, hoặc ngược lại.

Trước khi bật redirect, hãy xác minh cả các property cần thiết: HTTPS non-www, HTTPS www nếu có, cùng domain property nếu hệ thống sử dụng. Sau khi triển khai, gửi sitemap HTTPS, kiểm tra URL đại diện và theo dõi các báo cáo Page indexing, HTTPS, Manual actions và Performance. Không cần xoá property HTTP; dữ liệu lịch sử ở đó vẫn hữu ích để đối chiếu.

Bảng checklist migration HTTP sang HTTPS

Theo dõi traffic sau khi chuyển đổi

Đừng đánh giá migration chỉ bằng một ngày traffic. Google cần thời gian crawl lại, xử lý redirect và thay thế URL trong chỉ mục. Trong 24 giờ đầu, ưu tiên kiểm tra tính khả dụng: tỷ lệ 5xx, redirect loop, lỗi tài nguyên, form, thanh toán và dữ liệu tracking.

Ở mốc 3 và 7 ngày, so sánh theo cùng thứ trong tuần thay vì chỉ so sánh hôm qua với hôm nay. Theo dõi riêng nhóm URL HTTPS mới, nhóm URL HTTP cũ, brand traffic, non-brand traffic và các landing page tạo doanh thu. Nếu click giảm trên 20% trong 3 ngày liên tiếp so với baseline đã điều chỉnh theo mùa vụ, cần bắt đầu điều tra ngay; đây là ngưỡng cảnh báo vận hành, không phải kết luận rằng migration chắc chắn thất bại.

Đến ngày 14 và 28, kiểm tra:

• Sitemap chỉ còn URL HTTPS trả về 200.
• Canonical, hreflang và internal link không còn trỏ HTTP.
• URL HTTPS quan trọng đã được Google chọn làm canonical.
• Không phát sinh tăng bất thường của 404, 5xx hoặc soft 404.
• Organic traffic, doanh thu và tỷ lệ chuyển đổi đã ổn định so với baseline.

Nếu traffic giảm, không vội rollback về HTTP. Rollback có thể tạo thêm vòng đời URL và tín hiệu mâu thuẫn. Hãy xác định nhóm URL mất click, kiểm tra log crawl, redirect, canonical và khả năng render trước. Chỉ cân nhắc thay đổi lớn khi có bằng chứng rõ ràng rằng lỗi nằm ở bản triển khai HTTPS, đồng thời phải ghi lại thời điểm và phạm vi thay đổi để tránh biến việc xử lý thành một lần migration thứ hai.

Khi nào không nên chuyển sang HTTPS ngay?

Không nên triển khai vào thời điểm website đang chạy chiến dịch lớn, mùa cao điểm hoặc trước ngày phát hành sản phẩm quan trọng nếu đội kỹ thuật không có ít nhất một khung giám sát liên tục 4–8 giờ. Cũng nên trì hoãn khi chưa có quyền chỉnh redirect máy chủ, chưa truy cập được Search Console, không thể cập nhật canonical hoặc không có bản sao lưu cấu hình hiện tại.

Với website nhỏ, chi phí trực tiếp của chứng chỉ có thể bằng 0 nếu dùng chứng chỉ miễn phí phù hợp; nhưng chi phí kiểm thử, chỉnh CMS, CDN, tracking và nhân sự vẫn cần dự toán. Một kế hoạch thực tế nên dành 1–2 ngày cho audit và staging, 1 ngày triển khai có giám sát, sau đó tối thiểu 28 ngày theo dõi. Migration thành công không phải là biểu tượng ổ khoá trên trình duyệt, mà là hệ thống URL HTTPS nhất quán, tín hiệu SEO không mâu thuẫn và traffic được kiểm chứng qua dữ liệu.

Đọc thêm

• Audit website — triển khai trọn gói, có cam kết đo lường bằng số.
• Dịch vụ seo tổng thể — xem phạm vi công việc và mức đầu tư.
• Công Cụ Nghiên Cứu Keyword: So Sánh Bản Miễn Phí
• Internal Link: Cách Phân Bổ Sức Mạnh Trang Trong Website