
Ba năm điều hành blog kỹ thuật của mình, tôi có 200 bài viết và một mớ hỗn độn về thẻ (tag). Các thẻ như "javascript", "js", "JS" và "node" đều xuất hiện ở thanh bên của tôi. Chẳng ai tìm được gì cả. Ngay cả tôi cũng vậy.
Tôi đã phải xây dựng lại mọi thứ từ đầu.
Đó là lúc tôi nhận ra rằng thẻ không chỉ là những nhãn vứt đi. Chúng là một hệ thống điều hướng. Nếu bạn làm sai, độc giả của bạn sẽ lạc lối. Nếu bạn làm đúng, họ sẽ tìm thấy chính xác những gì họ cần chỉ trong vài giây.
Live Google, Twitter/X & LinkedIn social card generator
Preview your website on Google, Twitter/X, and LinkedIn. Generates HTML meta tags and Next.js Metadata.
Hệ thống phân loại thẻ (tag taxonomy) là một hệ thống có cấu trúc, có chủ đích để phân loại nội dung của bạn. Nó khác với một danh sách thẻ phẳng vì các mối quan hệ giữa các thẻ được thiết kế rõ ràng.
Hầu hết các blogger bắt đầu bằng cách thêm thẻ khi họ viết bài. "Bài đăng này nói về React, vậy tôi sẽ thêm react." Bài đăng tiếp theo về React Hooks sẽ có "react-hooks." Vài tháng sau, tìm kiếm theo thẻ chẳng mang lại kết quả hữu ích nào.
Tôi đã làm điều này trong hai năm. Danh sách thẻ của tôi tăng lên 340 thẻ duy nhất. Nhiều thẻ là từ đồng nghĩa. Một số bị viết sai chính tả. Một thẻ chỉ đơn giản là "t."
Tại sao điều này lại quan trọng? Bởi vì các thẻ của bạn là các đường dẫn tìm kiếm. Nếu hệ thống phân loại của bạn bị hỏng, những đường dẫn đó sẽ không dẫn đến đâu cả.
Vấn đề chính khi thêm thẻ ngẫu nhiên trong quá trình viết là gì?
Tôi đã đặt ra một quy tắc thay đổi mọi thứ: không thẻ nào được thêm vào nếu chưa có vị trí trong hệ thống phân loại trước.
Trước khi bạn viết bài đăng đầu tiên, hãy phác thảo các danh mục của bạn. Chưa phải là thẻ - mà là danh mục. Các chủ đề chính của blog của bạn là gì?
Đối với một blog JavaScript, các chủ đề có thể là:
Tạo hệ thống phân loại của bạn trước khi tạo nội dung. Điều này ngược với cách hầu hết mọi người làm, nhưng đó là cách duy nhất để xây dựng một thứ gì đó nhất quán.
Khi bạn đã có các danh mục, bạn có thể định nghĩa các thẻ trong mỗi danh mục. Kiến thức cơ bản về ngôn ngữ có thể bao gồm "variables", "functions", "async", "types". Mỗi thẻ có một vị trí duy nhất. Không trùng lặp.
Đây là điều giúp hệ thống phân loại dễ quản lý: mỗi thẻ thuộc về chính xác một danh mục. Không thẻ nào xuất hiện trong hai nhóm.
Tôi biết điều này nghe có vẻ hạn chế. Bạn đang nghĩ "React có thể nằm trong cả Frameworks và Architecture." Nhưng nếu React nằm ở hai nơi, thì thực tế nó không nằm ở đâu cả. Sự mơ hồ làm xói mòn niềm tin vào hệ thống điều hướng của bạn.
Khi một thẻ thực sự bao trùm nhiều danh mục, đó là dấu hiệu cho thấy bạn cần một danh mục rộng hơn hoặc một nguyên tắc tổ chức khác.
Hệ thống phân loại của tôi có 8 danh mục và tổng cộng khoảng 60 thẻ. Hầu hết các danh mục có 5-8 thẻ. Danh sách đủ ngắn để ghi nhớ, điều đó có nghĩa là tôi gắn thẻ một cách nhất quán mà không cần suy nghĩ.
Viết ra mọi chủ đề chính mà blog của bạn đề cập. Nhắm đến 5-10 danh mục rộng.
Đối với mỗi danh mục, liệt kê các thẻ cụ thể thuộc về đó. Không thẻ nào xuất hiện hai lần.
Xem xét các bài đăng hiện tại của bạn và gắn thẻ lại chúng bằng hệ thống mới. Việc này tẻ nhạt nhưng cần thiết.
Quyết định cách bạn sẽ xử lý các thẻ mới trước khi chúng xuất hiện. Ai sẽ phê duyệt chúng? Bạn xem xét thường xuyên như thế nào?
Thẻ chỉ là một nửa vấn đề. Vệ sinh nội dung là nửa còn lại.
Tôi định nghĩa vệ sinh nội dung là việc giữ cho công việc đã xuất bản của bạn chính xác, cập nhật và nhất quán. Đối với một blog kỹ thuật, điều này quan trọng hơn hầu hết mọi người thừa nhận.
Tôi đã xuất bản một bài viết về một phương thức JavaScript vào năm 2023. Phương thức này lúc đó đang trong giai đoạn thử nghiệm. Đến năm 2024, nó đã trở thành tiêu chuẩn. Bài viết của tôi vẫn ghi "thử nghiệm" trong tiêu đề. Một độc giả đã để lại bình luận hỏi tại sao tôi lại đề cập đến một thứ đã lỗi thời như vậy.
Tôi đã không đụng đến bài viết đó trong 18 tháng.
Nội dung kỹ thuật có thời hạn sử dụng. Nếu không được bảo trì, blog của bạn sẽ trở thành một gánh nặng thay vì một nguồn tài nguyên.
Tôi thực hiện ba loại kiểm tra nội dung theo lịch trình.
Hàng tháng: Kiểm tra bề mặt. Tôi xem xét các bài đăng cũ hơn một năm và tự hỏi: cái này còn chính xác không? Có lỗi rõ ràng nào không? Tôi sửa những gì tôi tìm thấy nhưng không đọc sâu.
Hàng quý: Đánh giá chuyên sâu. Tôi đọc hoàn chỉnh các bài đăng từ quý trước. Các ví dụ có hoạt động không? Các liên kết còn hoạt động không? Các kết luận còn hợp lệ không?
Hàng năm: Đánh giá toàn bộ hệ thống phân loại. Tôi xem xét những thẻ nào đang được sử dụng, những thẻ nào không, và liệu các danh mục của tôi còn hợp lý không. Năm ngoái tôi đã loại bỏ 30% số thẻ của mình vì chúng có ít hơn 3 bài đăng. Việc hợp nhất này giúp điều hướng rõ ràng hơn.
Có tốn thời gian không? Có. Tôi dành khoảng 4 giờ mỗi tháng cho việc bảo trì. Nhưng tỷ lệ thoát trang của tôi đã giảm 40% sau khi tôi bắt đầu. Mọi người tìm thấy những gì họ cần và ở lại lâu hơn.
Sáu tháng trước, tôi tìm thấy một bài viết dài 1.200 từ mà không có một tiêu đề nào. Chỉ toàn là các đoạn văn bản kéo dài xuống trang. Tôi đã viết nó vào đêm khuya, chỉ tập trung vào nội dung kỹ thuật.
Bài viết xếp hạng tốt vì chủ đề hay. Nhưng độc giả không đọc hết. Heatmap cho thấy hầu hết mọi người thoát giữa chừng.
Tôi đã chia nó thành các phần với các tiêu đề mô tả, thêm mục lục và cắt bớt một số đoạn văn dài dòng của mình. Thời gian trên trang đã tăng gấp đôi.
Nội dung kỹ thuật không thay đổi. Vệ sinh đã thay đổi.
Tần suất kiểm tra tối thiểu đối với nội dung blog kỹ thuật là bao nhiêu?
Một điều nữa mà tôi mất quá nhiều thời gian để học: quy ước đặt tên nhất quán giúp ngăn chặn sự hỗn loạn.
Tôi sử dụng tên viết thường có dấu gạch nối. "unit-testing" chứ không phải "Unit Testing" hay "unit_testing." URL viết thường, vì vậy thẻ cũng nên như vậy. Dấu gạch nối dễ đọc. Dấu gạch dưới bị mất trong các liên kết.
Tôi cũng tuân thủ các danh từ số ít. "javascript" chứ không phải "javacripts." Số ít giữ cho danh sách nhất quán về mặt ngữ pháp, ngay cả khi thẻ đại diện cho nhiều bài đăng.
Trước khi bạn thêm một thẻ, hãy tự hỏi: tên này có khớp với mẫu hiện có của tôi không? Nếu không, hãy đổi tên hoặc không thêm nó.
Hai năm sau khi xây dựng lại hệ thống phân loại của mình, tôi vẫn đang sử dụng nó. Số lượng thẻ của tôi là 58 và đã ổn định trong 18 tháng. Tôi thuộc lòng mọi thẻ. Gắn thẻ cho một bài đăng mới chỉ mất 30 giây vì tôi chỉ cần chọn từ danh sách.
Mớ hỗn độn mà tôi thừa hưởng từ những ngày đầu đã buộc tôi phải xây dựng một thứ gì đó nghiêm ngặt. Tôi biết ơn vì điều đó, ngay cả khi lúc đó nó rất đau đớn.
Bắt đầu với hệ thống phân loại, không phải các thẻ. Kiểm tra thường xuyên. Giữ quy ước đặt tên nhất quán. Bản thân bạn trong tương lai - và độc giả của bạn - sẽ cảm ơn bạn.
Sẵn sàng kiểm tra blog của riêng bạn? Bắt đầu với một bảng tính đơn giản: một cột cho thẻ, một cột cho danh mục, một cột cho mô tả ngắn. Điền vào ngay hôm nay. Đó là nền tảng của mọi thứ khác.
Công việc là ở phía trước. Phần thưởng là nhiều năm nội dung sạch sẽ, dễ điều hướng mà độc giả thực sự tin tưởng.
Làm sạch log AI CLI, tạo biểu thức cron, giải mã JWT và tính quyền chmod offline.

Cách tôi sử dụng Google Search Console để tìm khoảng trống nội dung, khắc phục các vấn đề SEO kỹ thuật và quyết định viết gì tiếp theo, với các ví dụ cụ thể từ blog này.
Đọc tiếp
Tìm hiểu cách triển khai kiến trúc liên kết nội bộ và nhóm chủ đề có hệ thống đã giúp tăng gấp ba lần lưu lượng truy cập tìm kiếm tự nhiên trên hơn 200 hướng dẫn kỹ thuật chuyên sâu.
Đọc tiếp
Với SEO truyền thống đang suy yếu, bài đăng này trình bày cách cấu trúc tài liệu dành cho nhà phát triển và blog kỹ thuật để chúng được ưu tiên và trích dẫn bởi các công cụ tìm kiếm AI - bao gồm llms.txt, đánh dấu schema, ví dụ mã có cấu trúc và các mẫu viết đáng trích dẫn.
Đọc tiếp