Mục lục bài viết6 mục
- 1.Bối cảnh trước khi chuyển và lý do phải đổi
- 2.Việc cần làm trước khi dựng kiến trúc headless
- 3.Ràng buộc kỹ thuật đặt ra cho bản kiến trúc headless mới
- 4.Bản chạy thử và những gì phát hiện được trước khi lên chạy thật
- 5.Ngày chuyển đổi và bốn tuần theo dõi sau đó
- 6.Điều kiện để lặp lại được kết quả này
Phần lớn thiệt hại sau khi đổi nền tảng không đến từ bản thân công nghệ mới, mà đến từ những thứ nền tảng cũ vẫn âm thầm làm hộ. Bài này dựng lại toàn bộ quá trình chuyển sang kiến trúc headless của một website SaaS B2B khoảng 300 trang đang có traffic ổn định, gồm việc đã làm theo thứ tự, chỗ suýt sai, và điều kiện để lặp lại được kết quả.
Trường hợp dưới đây được dựng lại để minh họa cách xử lý, không phải hồ sơ của một khách hàng cụ thể. Các con số trong bài đóng vai trò ví dụ.
Bối cảnh trước khi chuyển và lý do phải đổi
Website trong tình huống này là trang marketing của một sản phẩm SaaS B2B, chạy trên một CMS truyền thống, khoảng 300 URL gồm trang tính năng, trang giải pháp theo ngành, tài liệu hướng dẫn và blog. Traffic tự nhiên đã ổn định qua nhiều quý, phần lớn đến từ nhóm bài hướng dẫn.
Lý do chuyển sang kiến trúc headless không phải vì SEO. Đội sản phẩm cần dùng chung nội dung cho cả website, ứng dụng trong sản phẩm và bản tin gửi khách hàng, trong khi CMS cũ chỉ xuất được ra HTML. Đây là bối cảnh đáng chú ý, vì khi động lực chuyển đổi không đến từ SEO thì SEO rất dễ bị đẩy xuống cuối danh sách ưu tiên.
Điểm xuất phát có một lợi thế quan trọng: website đã có traffic nền ổn định và có dữ liệu lịch sử đủ dài trong Search Console. Nhờ vậy mọi biến động sau khi chuyển đều so sánh được với một đường cơ sở rõ ràng. Một website mới chưa có dữ liệu nền sẽ không có cách nào phân biệt giữa sụt giảm do migrate và dao động tự nhiên.
Việc cần làm trước khi dựng kiến trúc headless
Đội thực hiện dành hai tuần cho phần chuẩn bị, trước khi kiến trúc headless được dựng lên. Ba việc trong giai đoạn này quyết định phần lớn kết quả.
Việc thứ nhất là xuất toàn bộ danh sách URL hiện có kèm dữ liệu hiệu suất 12 tháng từ Search Console, rồi xếp hạng theo số lần nhấp. Nhóm 40 URL đầu tiên chiếm phần lớn traffic, và danh sách này trở thành nhóm cần bảo vệ trước tiên trong mọi quyết định sau đó.
Việc thứ hai là chụp lại hiện trạng kỹ thuật của từng URL trong nhóm quan trọng: thẻ tiêu đề, thẻ mô tả, thẻ canonical, cấu trúc heading, danh sách liên kết nội bộ trỏ tới và trỏ đi. Bản chụp này về sau dùng để đối chiếu từng dòng sau khi lên bản mới.
Việc thứ ba là chốt sơ đồ đường dẫn của website mới. Quyết định quan trọng nhất được đưa ra ở đây là giữ nguyên toàn bộ đường dẫn cũ. Kiến trúc headless cho phép đặt lại URL theo ý muốn, và đó chính là cám dỗ khiến nhiều lần migrate hỏng. Đổi nền tảng và đổi cấu trúc URL cùng lúc khiến bạn mất khả năng xác định nguyên nhân khi có sự cố.
Ràng buộc kỹ thuật đặt ra cho bản kiến trúc headless mới
Yêu cầu kỹ thuật được viết thành một danh sách ngắn, mỗi dòng là một điều kiện nghiệm thu kiểm tra được, không phải mô tả chung chung.
Mọi trang trong nhóm nội dung phải dựng ở phía máy chủ, HTML trả về đã chứa nội dung chính. Mỗi trang xuất đúng một thẻ tiêu đề, một thẻ canonical trỏ về chính nó, và thẻ mô tả chỉ xuất hiện khi trường mô tả có dữ liệu. Toàn bộ điều hướng dùng liên kết thật, không dùng phần tử bấm để đổi trang. Sitemap sinh từ kho nội dung và tự chạy lại khi có bài mới xuất bản. Trang không tồn tại trả về đúng mã 404. Khối dữ liệu có cấu trúc sinh từ trường dữ liệu thật.
Ràng buộc gây tranh luận nhiều nhất là ràng buộc đầu tiên, vì dựng phía máy chủ phức tạp hơn dựng ở trình duyệt. Lập luận thuyết phục được đội phát triển không phải là lý thuyết về bot, mà là một con số cụ thể: 40 URL trong nhóm quan trọng đang mang phần lớn số khách đăng ký dùng thử đến từ tìm kiếm. Rủi ro tính bằng khách hàng, không tính bằng thứ hạng.
Bản chạy thử và những gì phát hiện được trước khi lên chạy thật
Bản kiến trúc headless được dựng song song trên một tên miền phụ chặn thu thập, chạy thử ba tuần. Đây là giai đoạn phát hiện phần lớn vấn đề, và ba vấn đề dưới đây đáng kể nhất.
Vấn đề thứ nhất là mất liên kết nội bộ. Trên bản cũ, mỗi bài hướng dẫn có một khối bài liên quan sinh tự động theo danh mục. Bản dựng bằng kiến trúc headless mới bỏ khối đó vì chưa ai yêu cầu. Kết quả là một nhóm bài chỉ còn đường vào duy nhất từ sitemap. Khối này được dựng lại trước khi lên chạy thật.
Vấn đề thứ hai là thẻ tiêu đề bị rút gọn. Khi nhập dữ liệu từ CMS cũ, trường tiêu đề hiển thị trên kết quả tìm kiếm và trường tiêu đề bài viết bị gộp làm một. Những trang từng có tiêu đề viết riêng cho tìm kiếm nay dùng chung tiêu đề nội dung. Việc này được sửa bằng cách bổ sung trường riêng và nhập lại cho nhóm 40 URL quan trọng.
Vấn đề thứ ba là trang phân trang của blog trả về mã thành công cho cả những số trang không tồn tại, ví dụ trang thứ 99. Ứng dụng dựng ra một trang rỗng thay vì báo lỗi. Đây là lỗi đặc trưng của ứng dụng dựng động và được sửa bằng cách trả về mã 404 khi số trang vượt quá số trang thật.
Ngày chuyển đổi và bốn tuần theo dõi sau đó
Ngày chuyển sang kiến trúc headless được đặt vào đầu tuần, không phải cuối tuần. Lý do rất thực tế: nếu có sự cố, cả đội có đủ ngày làm việc phía trước để xử lý thay vì phát hiện vào sáng thứ hai sau khi hỏng đã hai ngày.
Ngay trong ngày đầu, bốn việc được làm theo thứ tự: bỏ chặn thu thập trên bản mới, kiểm tra tệp robots.txt trên tên miền chính, gửi lại sitemap trong Search Console, và chạy công cụ Kiểm tra URL trực tiếp cho mười URL quan trọng nhất để xác nhận HTML đã render chứa đủ nội dung.
Trong bốn tuần sau đó, chỉ số được theo dõi hằng ngày không phải thứ hạng mà là ba con số: số URL được lập chỉ mục trong báo cáo Trang, số lỗi thu thập mới phát sinh, và số lần hiển thị của riêng nhóm 40 URL quan trọng. Thứ hạng dao động trong vài tuần đầu là chuyện bình thường sau mỗi lần đổi nền tảng, còn ba chỉ số trên phản ánh sức khỏe kỹ thuật rõ hơn nhiều.
Điều kiện để lặp lại được kết quả này
Cách chuyển sang kiến trúc headless ở trên không phải công thức áp dụng được cho mọi website. Có bốn điều kiện nền, thiếu điều kiện nào thì kết quả sẽ khác.
Điều kiện thứ nhất là giữ nguyên toàn bộ URL. Nếu buộc phải đổi đường dẫn, hãy tách thành hai lần triển khai cách nhau ít nhất một tháng, đổi nền tảng trước rồi mới đổi URL.
Điều kiện thứ hai là quy mô vừa phải, vì kiến trúc headless không tự làm cho việc đối chiếu dễ hơn. Với 300 trang, việc đối chiếu thủ công từng URL quan trọng còn khả thi. Với vài chục nghìn trang, cần công cụ crawl để so sánh tự động giữa bản cũ và bản mới.
Điều kiện thứ ba là có dữ liệu lịch sử đủ dài để biết đâu là bất thường. Website mới chạy vài tháng không có đường cơ sở để so.
Điều kiện thứ tư là đội phát triển chấp nhận các ràng buộc kỹ thuật ngay từ đầu, không coi chúng là việc bổ sung sau khi ra mắt. Khi kiến trúc headless đã dựng xong theo hướng dựng ở trình duyệt, việc chuyển sang dựng phía máy chủ tốn công gấp nhiều lần so với quyết định đúng từ đầu.
=== FAQ === Q: Có nên chuyển từng phần thay vì chuyển toàn bộ website một lần không? A: Chuyển từng phần theo nhóm mẫu trang là cách an toàn hơn khi website lớn, với điều kiện tầng định tuyến phía trước xử lý được việc một phần đường dẫn chạy trên hệ thống mới và phần còn lại vẫn ở hệ thống cũ. Q: Bao lâu sau khi chuyển thì coi là đã ổn định? A: Thường cần ít nhất bốn tới sáu tuần để số liệu lập chỉ mục và số lần hiển thị trở lại quanh mức trước đó, nên đừng vội kết luận thành công hay thất bại trong hai tuần đầu. Q: Nếu traffic giảm sau khi chuyển thì nên nhìn vào đâu trước? A: Nhìn vào báo cáo Trang để xem có nhóm URL nào rơi khỏi chỉ mục hàng loạt không, vì nguyên nhân kỹ thuật luôn để lại dấu vết ở đó rõ hơn là ở biến động thứ hạng của từng từ khóa.
Chuyển nền tảng thành công không phải nhờ chọn đúng công nghệ mà nhờ chuẩn bị đủ chi tiết trước khi bắt đầu và giữ nguyên những gì đang hoạt động tốt. Nếu website của bạn sắp chuyển sang kiến trúc headless, việc nên làm ngay là xuất danh sách URL kèm dữ liệu hiệu suất 12 tháng, vì danh sách này quyết định mọi ưu tiên phía sau và càng lấy sớm càng ít bị ảnh hưởng bởi các thay đổi đang diễn ra.
