Cấu trúc nội dung và taxonomy: danh mục, thẻ, pillar–cluster

Hãy chọn loại nội dung theo vai trò của trang: pages cho nội dung tĩnh, posts cho bài có ngày và tác giả, products cho trang sản phẩm/dịch vụ, landings cho trang chiến dịch dạng block. Phân loại bằng taxonomies (chuyên mục, thẻ), điều hướng bằng menus. Quyết định đúng ngay từ đầu giúp URL, breadcrumb và JSON-LD nhất quán.

Tóm tắt nhanh

• 4 loại nội dung chính: pages, posts, products, landings; mỗi loại có phiên bản (tối đa 30/tài liệu) và thùng rác.
• Taxonomy có 4 type: category, product-category, tag, custom; hỗ trợ cây cha/con.
• Slug duy nhất theo site (trừ tài liệu trong thùng rác); đổi slug tạo redirect 301.
• Menu là cây kéo thả, 5 vị trí, độ sâu tối đa 10 cấp ở REST.
• FAQ, shortcode, tác giả là collection riêng, dùng lại được nhiều nơi.

1. Chọn loại nội dung

Nguyên tắc chọn nhanh:

1. Có ngày đăng, tác giả và nằm trong dòng thời gian? → posts.
2. Là trang tồn tại lâu, ít đổi? → pages.
3. Có giá hoặc là thứ bạn bán? → products (lưu ý đây là trang giới thiệu sản phẩm, không có giỏ hàng; xem website bán hàng).
4. Có mục tiêu chuyển đổi, ghép từ hero, bảng giá, CTA, FAQ? → landings.

Landing hỗ trợ các block hero, content, imageGallery, testimonials, cta, faq, stats, pricingTable, blogFeed, offerCards, embed, divider. Trạng thái của landing có thêm archived (không công khai). Chi tiết mô hình: nội dung và cấu trúc.

2. Thiết kế taxonomy

taxonomies có bốn type:

Một (type, slug) là duy nhất trong site, nên category và tag có thể trùng slug. Quy tắc thực hành:

• Cây nông: 1–2 cấp. Cây sâu làm breadcrumb dài và loãng sức mạnh liên kết.
• Mỗi bài thuộc 1 chuyên mục chính (breadcrumb lấy chuyên mục tìm thấy đầu tiên khớp Sites.breadcrumbs.primaryTaxonomyPost), thêm tag vừa phải.
• Viết nội dung cho trang chuyên mục: taxonomy có contentMd riêng và SEO riêng; CMS đánh dấu nội dung dưới THIN_CONTENT_THRESHOLD = 500 từ là mỏng.
• Dùng trường tùy chọn tier/cluster trên bài viết để ghi cụm chủ đề cho đội biên tập (CMS không tự render hay dùng cho gợi ý liên kết).

Taxonomy không có trạng thái/thùng rác nhưng có lịch sử phiên bản (30).

3. Quy ước slug và URL

Slug tự sinh từ tiêu đề (bỏ dấu, đ → d, mọi ký tự khác [a-z0-9] thành -), không đa ngôn ngữ và duy nhất theo site giữa các tài liệu chưa vào thùng rác. Một vài điều cần biết:

• Tài liệu trong thùng rác giữ slug. Khôi phục vào slug đã bị chiếm sẽ báo lỗi song ngữ (makeGuardRestoreSlugConflict).
• Đường dẫn công khai trong breadcrumb, JSON-LD và redirect đến từ slug-url-prefix-map.ts: sản phẩm ở /product/{slug}, product-category ở /product-category/…, còn lại ở gốc.
• Nếu frontend của bạn định tuyến khác (ví dụ /blog/{slug}), hãy sửa bảng này và hàm publicPathFor trong src/lib/frontend-public-path.ts để liên kết “xem trên site” và bộ chọn liên kết @ đúng.

4. Menu dạng cây

menus là một tài liệu cho mỗi location mỗi site: PRIMARY, SECONDARY_MENU, MOBILE_MENU, FOOTER_MENU, LOGGEDIN_ACCOUNT_MENU. Biên tập bằng trình kéo thả MenuTreeField. REST không trả tree mà trả items đã chiếu theo ngôn ngữ, mỗi mục có label, url, order, parentId, children; độ sâu tối đa 10 cấp.

curl -s 'https://cms.example.com/api/menus?where[tenant][equals]=1&where[location][equals]=PRIMARY&locale=vi&limit=1'

Thực hành: menu chính ≤ 7 mục cấp 1; đặt trang trụ cột ở cấp 1, bài con ở cấp 2; footer chứa trang pháp lý. Menu và FAQ gửi revalidate theo cả site khi đổi.

5. FAQ, tác giả và shortcode

• FAQ: một tài liệu = một nhóm (group) gồm các cặp question/answer (Markdown, đa ngôn ngữ, có phiên bản và thùng rác). Gắn vào bài/trang/sản phẩm qua faqs để sinh FAQPage. Chỉ cặp đủ cả hai vế mới được xuất.
• Tác giả (authors): bút danh công khai với bio, avatar, sameAs[]; email không bao giờ trả về qua API. Đây là nền cho trang tác giả và tín hiệu E-E-A-T.
• Shortcode: đoạn Markdown dùng lại (chính sách, bảng giá, lời kêu gọi). Cú pháp [sc name="chinh-sach-doi-tra" /]; tên chỉ gồm [a-z0-9-], duy nhất theo site, lồng tối đa 3 cấp. Trong editor, gõ / rồi snippet để chèn. Lưu hay xóa shortcode sẽ revalidate frontend của site.

6. Nội dung Markdown

Thân bài viết lưu ở contentMd (nguồn thật) và REST trả HTML đã làm sạch ở khóa content. Các thẻ ngoài danh sách cho phép (script, style, iframe, thuộc tính style, on*) bị loại. Quy tắc nhớ: chuỗi rỗng '' nghĩa là “không có nội dung”, null mới là “chưa lưu từ khi chuyển sang Markdown”. Xem trình soạn thảo Markdown.

7. Vòng đời nội dung

Lưu ý: tài liệu hẹn giờ xuất hiện ở request đầu tiên sau mốc giờ, nhưng cache frontend chỉ được làm mới khi có lưu, không theo đồng hồ — hãy lên kế hoạch revalidate (xem hiệu năng và cache).

Ví dụ cấu trúc pillar–cluster

Mô hình pillar–cluster dùng một trang trụ cột cho mỗi chủ đề lớn và nhiều bài con liên kết qua lại. Trong KDIGI CMS:

Các trường tier và cluster chỉ là siêu dữ liệu cho đội biên tập và frontend; CMS không tự dựng liên kết hay trang cụm từ chúng. Tránh nội dung trùng lặp: mỗi truy vấn chính chỉ có một trang đích, và chuyên mục không nên lặp lại nguyên văn bài viết.

Checklist cấu trúc

• [ ] Mỗi loại nội dung có mục đích rõ, không dùng posts cho trang tĩnh.
• [ ] Chuyên mục ≤ 2 cấp, mỗi chuyên mục có mô tả dài và SEO riêng.
• [ ] Slug ngắn, ổn định; đã quy ước tiền tố URL ở frontend.
• [ ] Menu chính khớp với cụm chủ đề, không trang mồ côi.
• [ ] FAQ và shortcode được đặt tên có hệ thống.

Cấu hình các thành phần này trên bản demo, hoặc đọc về quy trình biên tập để giao việc cho đội.