Hành trình xây một repo WordPress chuẩn và lý do tôi vẫn khuyên dùng nó cho bán hàng

Bài trước tôi có so sánh WordPress với Next.js + Sanity theo hướng kỹ thuật. Bài này tôi muốn nói theo hướng thực tế hơn, từ góc độ người đã làm nhiều dự án với cả hai stack, đặc biệt là với các khách hàng có nhu cầu bán hàng online.

Hành trình từ theme có sẵn đến codebase tự chuẩn hóa

Những năm đầu làm WordPress, tôi làm như hầu hết mọi người: mua theme trên ThemeForest, cài vào, chỉnh màu chỉnh chữ, xong giao cho khách. Nhanh, rẻ, trông cũng ổn. Nhưng vấn đề bắt đầu xuất hiện sau vài tháng. Khách muốn thêm tính năng thì không biết can thiệp vào đâu, theme update lên version mới thì vỡ layout, performance kém vì theme nhét vào đủ thứ không cần thiết.

Giai đoạn tiếp theo tôi thử các page builder. Elementor thì phổ biến, Bricks Builder thì được giới developer đánh giá cao hơn vì clean hơn, performance tốt hơn, nhưng phí khá cao so với mặt bằng chung. Vấn đề chung của cả hai hướng, tự xây từ đầu lẫn dùng builder, là đều tốn thời gian và phức tạp hơn mức cần thiết. Xây từ đầu thì linh hoạt nhưng mất công. Dùng builder thì nhanh nhưng tạo ra một mớ nested block và layer mà sau này chính khách hàng cũng không biết click vào đâu để chỉnh cái tiêu đề hay đổi một cái ảnh.

Điểm chuyển thực sự đến khi tôi quyết định tự build theme từ đầu thay vì dùng base theme hay framework có sẵn. Cái lợi là kiểm soát hoàn toàn, không có code thừa, không phụ thuộc vào update của bên thứ ba. WordPress hiện tại hỗ trợ FSE (Full Site Editing) và tôi có đưa hỗ trợ FSE vào theme, nhưng thực tế không dùng. Lý do là frontend và editor trong FSE hiển thị không khớp nhau, chỉnh trong editor trông một kiểu, ra ngoài trông kiểu khác, người dùng cứ phải đoán. Không đáng tin cậy để giao cho khách hàng tự quản lý.

Phần quan trọng không kém là cấu trúc plugin. Tôi có một mu-plugin core đặt trong thư mục mu-plugins của WordPress. Mu-plugin là loại plugin WordPress tự load bắt buộc, người dùng không thấy, không tắt được, không xóa nhầm được. Tất cả tính năng cốt lõi của site như custom post type, taxonomy, helper function, shortcode nội bộ đều đưa vào đây. Những tính năng custom thường xuyên xuất hiện ở nhiều dự án cũng đưa vào mu-plugin core này, vừa tái sử dụng được, vừa không lo bị người dùng đụng vào. Plugin bên ngoài chỉ cài những thứ thực sự cần và không tự làm được tốt hơn, chủ yếu là SEO, cache, security, và form.

Một website doanh nghiệp thực sự cần gì

Sau nhiều dự án thực tế, tôi rút ra một số thứ gần như bắt buộc với website doanh nghiệp. Load nhanh vì khách hàng không chờ. SEO tốt vì đây thường là kênh traffic chính. Dễ cập nhật nội dung vì không phải lúc nào cũng có developer ngồi cạnh. Bảo mật cơ bản để không bị hack tầm thường. Và dễ mở rộng khi nhu cầu thay đổi.

WordPress làm được tất cả những thứ đó nếu setup đúng. Vấn đề là phần lớn WordPress site bị setup sai ngay từ đầu, dùng quá nhiều plugin chồng chéo, không có quy trình update, không có backup định kỳ. Lỗi là ở người triển khai, không phải ở nền tảng.

WooCommerce và lý do nó vẫn là lựa chọn tốt nhất cho bán hàng tại Việt Nam

Khi khách hàng nói muốn bán hàng online, câu hỏi đầu tiên tôi hỏi là quy mô và ngân sách. Shopify đẹp, tiện, nhưng phí hàng tháng cộng phí giao dịch cộng chi phí app là một bài toán không hề nhỏ, đặc biệt với các doanh nghiệp vừa và nhỏ đang trong giai đoạn đầu.

WooCommerce thì miễn phí. Bạn trả tiền hosting, domain, và nếu cần tính năng đặc biệt thì mua thêm plugin. Nhưng core của nó đủ để chạy một shop bán hàng cơ bản mà không tốn thêm gì. Tích hợp cổng thanh toán Việt Nam như VNPay, MoMo, ZaloPay đều có plugin sẵn. Quản lý đơn hàng, kho, shipping đều trong một dashboard quen thuộc.

Và quan trọng hơn là WordPress có thể host trên shared hosting giá rẻ. Với Next.js + Sanity, bạn cần ít nhất một VPS hoặc trả phí cho Vercel khi traffic lên. Với khách hàng SME ở Việt Nam, cái này có nghĩa là chi phí vận hành thấp hơn đáng kể trong năm đầu.

Vậy Next.js + Sanity dùng khi nào

Tôi dùng Next.js + Sanity khi có developer duy trì, khi performance là ưu tiên hàng đầu, khi content structure phức tạp và cần linh hoạt, hoặc khi dự án cần tích hợp nhiều API bên ngoài. Cho website cá nhân như cái này cũng hợp vì tôi thích có control và không ngại setup.

Nhưng cho phần lớn dự án khách hàng doanh nghiệp vừa và nhỏ, đặc biệt là có nhu cầu bán hàng, WordPress vẫn là lựa chọn thực tế hơn. Không phải vì nó tốt hơn về mặt kỹ thuật, mà vì nó phù hợp hơn với ngữ cảnh: ngân sách, nhân lực, và khả năng tự vận hành của khách hàng.

Tư duy chọn stack không phải là cái nào xịn hơn. Là cái nào phù hợp hơn với bài toán cụ thể của bạn.