Mục lục bài viết7 mục
- 1.Điều thay đổi khi tách phần quản trị khỏi phần hiển thị
- 2.Metadata trên headless CMS không còn tự sinh
- 3.Khác biệt thứ hai: URL do lập trình viên quyết định
- 4.Khác biệt thứ ba: nội dung phải chờ JavaScript mới hiện ra
- 5.Khác biệt thứ tư: sitemap và dữ liệu có cấu trúc phải tự dựng
- 6.Danh sách bàn giao headless CMS cho đội phát triển
- 7.Lỗi thường gặp trong ba tháng đầu sau khi chuyển
Chuyển sang headless CMS, đội phát triển vui vì code sạch, còn người làm nội dung mất luôn ô nhập tiêu đề và mô tả quen thuộc. Khác biệt thật sự không nằm ở giao diện quản trị mà nằm ở chỗ ai chịu trách nhiệm sinh ra các tín hiệu SEO. Bài này chỉ ra bốn khác biệt cốt lõi và việc cần làm với từng khác biệt.
Điều thay đổi khi tách phần quản trị khỏi phần hiển thị
Trên một CMS truyền thống, phần quản trị và phần hiển thị nằm chung một hệ thống. Bạn nhập tiêu đề, hệ thống tự dựng URL, tự chèn thẻ meta, tự sinh sitemap. Mọi tín hiệu SEO là sản phẩm phụ đi kèm miễn phí.
Kiến trúc headless CMS cắt đôi việc đó. Phần quản trị chỉ còn là kho dữ liệu trả về nội dung dạng thuần, không biết gì về HTML. Phần hiển thị là một ứng dụng riêng, tự quyết định dựng trang thế nào. Không có bên nào tự động chịu trách nhiệm cho thẻ tiêu đề, thẻ canonical hay sitemap nữa.
Đó là lý do một website headless CMS mới ra mắt thường thiếu những thứ cơ bản nhất, không phải vì nền tảng kém mà vì không ai được giao việc đó. Mọi thứ CMS truyền thống cho không, bây giờ đều là một hạng mục phải đưa vào kế hoạch phát triển.
Metadata trên headless CMS không còn tự sinh
Trên WordPress, plugin SEO đọc tiêu đề bài và tự dựng thẻ tiêu đề theo mẫu. Trên headless CMS, bạn phải tự tạo trường dữ liệu tương ứng trong mô hình nội dung và tự viết mã đọc trường đó rồi đưa vào phần đầu trang.
Việc cần làm là thiết kế sẵn một nhóm trường SEO trong mọi loại nội dung ngay từ khi dựng mô hình dữ liệu, gồm tối thiểu: tiêu đề hiển thị trên kết quả tìm kiếm, mô tả ngắn, đường dẫn tĩnh, ảnh đại diện dùng cho chia sẻ, và một công tắc cho phép đánh dấu không lập chỉ mục. Thêm sau khi đã có vài trăm bản ghi tốn công gấp nhiều lần.
Cần chú ý một cạm bẫy khi làm việc với headless CMS: nếu để trống trường mô tả thì phần hiển thị nên bỏ hẳn thẻ mô tả, chứ đừng lấy tạm đoạn đầu nội dung. Đoạn đầu thường là câu dẫn dắt, và một thẻ mô tả kém còn tệ hơn không có thẻ nào.
Khác biệt thứ hai: URL do lập trình viên quyết định
CMS truyền thống có một quy tắc đường dẫn tĩnh cấu hình một lần cho cả site. Trong kiến trúc headless CMS, đường dẫn được ghép trong mã của phần hiển thị, nên mỗi loại nội dung có thể theo một quy tắc khác nhau tùy người viết mã hôm đó.
Hệ quả hay gặp là cùng một nội dung xuất hiện ở nhiều URL: một bản dưới đường dẫn theo danh mục, một bản dưới đường dẫn phẳng, một bản có tham số theo dõi chiến dịch. Không có bên nào tự động sinh thẻ canonical để gộp chúng lại.
Việc cần làm là chốt sơ đồ đường dẫn trước khi viết dòng mã đầu tiên, ghi thành tài liệu, và bắt buộc mọi trang phải xuất một thẻ canonical trỏ về đúng URL chuẩn của nó. Thêm vào đó, cần một cơ chế chuyển hướng ở tầng máy chủ hoặc tầng phân phối nội dung, vì headless CMS không có sẵn bảng quản lý chuyển hướng như plugin trên WordPress.
Khác biệt thứ ba: nội dung phải chờ JavaScript mới hiện ra
Đây là khác biệt được nhắc nhiều nhất và cũng bị hiểu sai nhiều nhất. Vấn đề không phải là dùng JavaScript, mà là thời điểm nội dung có mặt trong tài liệu HTML mà máy chủ trả về.
Nếu phần hiển thị dựng trang hoàn toàn ở phía trình duyệt, HTML ban đầu gần như rỗng, chỉ có một thẻ chứa. Công cụ tìm kiếm phải xếp trang vào hàng đợi để render lần hai mới thấy nội dung. Việc đó vẫn xảy ra, nhưng chậm hơn và không có gì bảo đảm mọi trang đều được xử lý kịp.
Cách tránh là dựng nội dung ở phía máy chủ hoặc dựng sẵn thành tệp tĩnh lúc xuất bản. Hầu hết framework hiện đại dùng chung với headless CMS đều hỗ trợ sẵn cả hai chế độ này. Cách kiểm tra nhanh mà không cần công cụ: mở trang, xem mã nguồn trang gốc, tìm một câu đặc trưng trong bài. Tìm thấy nghĩa là nội dung có sẵn trong HTML, không tìm thấy nghĩa là đang phụ thuộc vào bước render thứ hai.
Khác biệt thứ tư: sitemap và dữ liệu có cấu trúc phải tự dựng
Sitemap trên CMS truyền thống cập nhật tự động mỗi lần bạn xuất bản. Với headless CMS, sitemap là một điểm cuối do bạn viết ra, đọc danh sách nội dung từ kho dữ liệu rồi sinh tệp XML.
Điểm dễ sai là sitemap được sinh lúc dựng trang chứ không phải lúc có yêu cầu. Nếu website dựng tĩnh và bạn xuất bản một bài mới mà chưa chạy lại quá trình dựng, bài đó không có trong sitemap dù đã hiện trên web. Cách xử lý là gắn quá trình dựng lại vào sự kiện xuất bản của headless CMS, hầu hết nền tảng đều hỗ trợ gửi tín hiệu này.
Dữ liệu có cấu trúc cũng vậy, không có plugin nào lo hộ. Bù lại, đây là điểm mạnh của kiến trúc này: vì bạn đã có dữ liệu ở dạng có cấu trúc sẵn trong kho, việc sinh khối JSON-LD chính xác dễ hơn nhiều so với việc bóc tách từ HTML. Chỉ cần đưa nó vào danh sách công việc thay vì để đến lúc phát hiện thiếu.
Danh sách bàn giao headless CMS cho đội phát triển
Phần dưới là bản yêu cầu dùng được ngay cho một website nội dung khoảng 200 bài chuyển sang headless CMS, viết ở mức đủ cụ thể để lập trình viên không phải hỏi lại.
Mỗi trang phải trả về HTML đã chứa nội dung chính khi xem mã nguồn gốc. Mỗi trang có đúng một thẻ tiêu đề, một thẻ mô tả nếu trường mô tả không rỗng, một thẻ canonical trỏ về URL chuẩn. Sơ đồ đường dẫn theo dạng thư mục chủ đề rồi tới đường dẫn tĩnh của bài, không có tham số trong URL chuẩn. Mọi URL cũ có bảng ánh xạ sang URL mới, xử lý bằng chuyển hướng vĩnh viễn ở tầng máy chủ. Sitemap sinh động từ kho dữ liệu, tự chạy lại khi có nội dung mới xuất bản. Trang không tồn tại trả về đúng mã 404, không trả về mã 200 kèm giao diện báo lỗi. Khối JSON-LD kiểu Article sinh từ trường dữ liệu thật, không viết cứng trong mã.
Dòng cuối cùng đáng nhấn mạnh vì đây là lỗi đặc trưng của ứng dụng dựng phía trình duyệt: khi không tìm thấy nội dung, ứng dụng vẫn trả về mã thành công rồi hiển thị thông báo lỗi bằng JavaScript. Với công cụ tìm kiếm, đó là một trang hợp lệ có nội dung mỏng, và nó sẽ được lập chỉ mục.
Lỗi thường gặp trong ba tháng đầu sau khi chuyển
Lỗi thứ nhất là bàn giao thiếu người chịu trách nhiệm. Người làm nội dung nghĩ đội phát triển đã lo, đội phát triển nghĩ đó là việc của người làm nội dung. Cách tránh là ghi rõ từng hạng mục thuộc về ai ngay trong tài liệu yêu cầu.
Lỗi thứ hai là kiểm thử trên môi trường thử nghiệm rồi quên rằng môi trường đó đang chặn thu thập. Sau khi đưa lên chạy thật, cấu hình chặn theo lên cùng. Kiểm tra tệp robots.txt và thẻ robots trên bản chạy thật ngay trong ngày đầu tiên là việc mất năm phút.
Lỗi thứ ba là bỏ qua tốc độ phản hồi của kho dữ liệu. Một website headless CMS dựng ở phía máy chủ phải gọi kho nội dung cho mỗi yêu cầu, và nếu kho phản hồi chậm thì thời gian tới byte đầu tiên tăng theo. Đo chỉ số này ngay sau khi chuyển, và cân nhắc chuyển sang dựng tĩnh cho các trang không cần cập nhật theo thời gian thực.
=== FAQ === Q: Website nhỏ vài chục trang có nên chuyển sang headless không? A: Thường không đáng, vì toàn bộ phần việc SEO mà CMS truyền thống làm sẵn sẽ trở thành chi phí phát triển, trong khi lợi ích về hiệu năng và linh hoạt chỉ rõ rệt ở quy mô lớn hoặc khi cần dùng chung nội dung cho nhiều kênh. Q: Dùng dịch vụ render riêng cho bot có phải giải pháp lâu dài không? A: Đó là giải pháp tình thế chấp nhận được khi chưa kịp đổi cách dựng trang, nhưng nó thêm một hệ thống phải bảo trì và một chỗ nữa có thể hỏng, nên vẫn nên hướng tới dựng phía máy chủ. Q: Làm sao biết Google đã thấy đủ nội dung sau khi chuyển? A: Dùng công cụ Kiểm tra URL trong Search Console ở chế độ kiểm tra trực tiếp cho vài trang đại diện mỗi loại, rồi đọc phần HTML đã render để đối chiếu với nội dung hiển thị.
Nắm được bốn khác biệt trên, bạn chuyển được cuộc thảo luận với đội phát triển từ chỗ tranh cãi chung chung sang một danh sách hạng mục cụ thể có thể ước lượng thời gian. Nên đưa danh sách này vào ngay giai đoạn thiết kế mô hình dữ liệu, vì thêm trường và sửa sơ đồ đường dẫn sau khi đã có nội dung thật luôn tốn công hơn nhiều lần.
