Tuyên bố cái chết của CMS là quá sớm: Tại sao WordPress vẫn là lựa chọn tối ưu trong kỷ nguyên AI?

Gần đây, cộng đồng công nghệ đã rầm rộ thảo luận về tương lai của hệ quản trị nội dung (CMS). Một cựu chiến binh WordPress với 20 năm kinh nghiệm từng tuyên bố trên LinkedIn rằng anh ta sẽ chuyển toàn bộ văn phòng của mình từ WordPress sang AI. Lý do là họ có thể sử dụng các công cụ như Claude Code để xây dựng website nhanh hơn bao giờ hết. Thậm chí, Joost de Valk - người sáng tạo Yoast SEO, một huyền thoại trong giới WordPress - cũng đã chuyển blog cá nhân sang Astro (một framework JavaScript đang hot) và gợi ý rằng không phải mọi trang web đều cần một CMS.

Đây là một luận điểm gây tranh cãi, nhưng liệu đã đến lúc "khai tử" CMS thực sự? Câu trả lời có lẽ không đơn giản như những gì tiếng hô hào của cơn sốt AI đang mô tả.

Không phải trang web nào cũng cần CMS, nhưng đây không phải là ý tưởng mới

Joost de Valk không sai khi nói rằng không phải trang web nào cũng cần CMS. Một trang đích (landing page), một danh mục đầu tư cá nhân hay một blog đơn giản về mặt kỹ thuật chưa bao giờ thực sự cần một hệ thống CMS "nặng nề" đi kèm cơ sở dữ liệu, runtime PHP và hệ sinh thái plugin. Tuy nhiên, việc sơn lại một lời khuyên cũ kỹ và tuyên bố rằng AI là câu trả lời cuối cùng chỉ là việc riding the coattails của cơn sốt AI.

Vấn đề nằm ở chỗ, ý tưởng cho rằng AI có thể di chuyển toàn bộ trang web của bạn khỏi nền tảng hiện tại (như WordPress hay Drupal) để chuyển sang một trang web do AI tạo ra là một cái nhìn thiển cận.

Sự tiến hóa của hệ quản trị nội dung

"Dependency hell": Cạm bẫy của JavaScript hiện đại

Chúng ta có vẻ đã quên đi sự thay đổi chóng mặt của cảnh quan JavaScript trong thập kỷ qua. Có bao nhiêu framework đã trỗi dậy và rồi lụi tàn? Việc chuyển sang một trang web JavaScript sử dụng framework "hot trend" nhất hiện nay có thể mang lại vẻ hiện đại, nhưng nó cũng kéo theo "địa ngục dependencies" (dependency hell).

Bạn sẽ phải đối mặt với hàng tá gói packages cần cập nhật, trong đó Package A phụ thuộc vào Package B, và Package B không thể cập nhật vì Package C... Khi đó, bạn sẽ gặp lỗ hổng bảo mật không thể giải quyết do xung đột phụ thuộc. AI hoặc Dependabot có thể giúp quản lý, nhưng chúng không làm biến mất những vấn đề cốt lõi này, chúng chỉ ẩn chúng dưới một lớp bảo mật "ảo" do chatbot tạo ra. Người dùng có thực sự muốn quản lý các dependencies NPM không? Một blog đã tìm thấy 22 gói lỗi thời bao gồm các thay đổi lớn gây vỡ chức năng chỉ sau một năm để im lặng.

Giao diện AI so với Dashboard: Ai tin tưởng được?

Một trong những luận điểm ủng hộ việc bỏ CMS là: thay vì đăng nhập vào bảng quản trị (admin panel) để đổi giờ mở cửa, bạn chỉ cần bảo AI làm việc đó qua Claude Desktop hay ChatGPT. Giao diện quản lý site của bạn giờ đây là một "trình thông dịch AI".

Đối với những người không kỹ thuật, bảng điều khiển WordPress hay Drupal cung cấp sức mạnh xuất bản và chỉnh sửa trực quan một cách rõ ràng. Họ nhấn Lưu và nhìn thấy kết quả. Nhưng khi bạn gửi lệnh qua chatbot, bạn đang đặt niềm tin vào việc AI sẽ thực hiện chính xác hành động bạn yêu cầu. Đó là việc giao chìa khóa lâu đài cho một người máy và hy vọng không có gì kỳ lạ xảy ra. Các mô hình ngôn ngữ lớn (LLM) nổi tiếng với việc tạo ra những kết quả "không lường trước được", và bạn vẫn cần phải xác minh xem AI đã làm đúng hay không. Về bản chất, bạn chỉ đang chuyển sự phức tạp sang một phần khác của hệ thống.

Sự phụ thuộc vào nhà cung cấp (Vendor Lock-in)

Cái giá phải trả cho những giải pháp "di cư khỏi WordPress bằng AI" rẻ tiền chính là sự phụ thuộc vào nhà cung cấp. Khi website của bạn là một sản phẩm tùy chỉnh, được tạo bởi AI dựa trên một framework cụ thể, ai sẽ bảo trì nó khi bạn cần cập nhật? Bạn sẽ phải gọi lại agency đã xây dựng nó. Ngược lại, với WordPress, bạn có thể thuê bất kỳ lập trình viên nào trên thế giới để sửa chữa.

Builder.ai từng sụp đổ và khách hàng đã mất quyền truy cập vào mọi thứ. Đó là cực đoan, nhưng là minh chứng cho rủi ro khi website của bạn phụ thuộc vào kiến thức và công cụ của một nhà cung cấp duy nhất.

Trải nghiệm thực tế: Giữ lại CMS, tân trang giao diện

Tôi đã dành một tháng qua để xây dựng lại phiên bản Next.js của trang web cá nhân (headless) mà không mất chức năng nào. Kết luận tôi rút ra không phải là "cần loại bỏ các phần CMS", mà là "tuyệt đối giữ lại CMS".

Tôi bắt đầu blog từ thời còn gọi là web log, viết tay HTML và FTP lên server. Trang web này đã phát triển qua sBlog và sau đó là WordPress. Tôi giữ lại mọi bài viết, kể cả những bài HTML tay, di chuyển hết chúng qua. Có 24 năm nội dung trên trang web này. Thay vì thổi bay mọi thứ để xây lại từ đầu, tôi muốn bảo tồn kiến trúc và dữ liệu lịch sử đó. AI không làm cho CMS trở nên lỗi thời; nó làm cho trang web mạnh mẽ hơn khi xây dựng trên nền tảng các nguyên bản gốc của WordPress như REST API, Abilities API và các khả năng adapter MCP đang được tích hợp.

Lập trình viên làm việc với AI và CMS

Kết luận: CMS chưa chết, nó đang tiến hóa

Ngày 1/4 vừa qua, Cloudflare đã giới thiệu EmDash, một "kế thừa tâm linh của WordPress" được viết bằng TypeScript và Astro. Thay vì xây dựng một trình tạo trang tĩnh (static site generator) không dành cho con người, họ đã xây dựng một thứ được kiến tạo để AI có thể tiêu thụ và vận hành, nhưng vẫn có giao diện dành cho con người. Thay vì nói "bỏ CMS đi", họ nói "hãy di chuyển CMS của bạn sang cái mới, tốt hơn". Thậm chí chính Joost de Valk cũng đã quay lại sử dụng một CMS mới sau hai tuần.

Chúng ta vẫn đang có cuộc tranh luận giống như 20 năm qua: hãy dùng đúng công cụ cho đúng việc. Các yếu tố xác định "công cụ đúng" phụ thuộc vào năng lực của team, tính dễ bảo trì và lịch sử dự án.

Tôi không nói rằng bạn không nên di chuyển khỏi WordPress nếu bạn muốn. Nhưng cỏ ở bên kia hàng rào không nhất thiết xanh hơn. Chi phí con người luôn là điểm yếu, dù đó là quản lý plugin WordPress hay chấp nhận thay đổi code từ AI agent. Vì vậy, tôi tuyên bố "bịa đặt" ý kiến cho rằng CMS - và đặc biệt là WordPress - đã chết.