Chuyển từ WordPress sang website được xây dựng theo yêu cầu: Khi nào nên làm và cần chuẩn bị gì

Chuyển khi công việc thực sự đòi hỏi

Website được xây dựng theo yêu cầu có thể là khoản đầu tư hữu ích nếu website hiện tại liên tục cản trở việc doanh nghiệp cần làm. Có thể biên tập viên phải nhập cùng một thông tin ở nhiều nơi. Có thể yêu cầu liên hệ cần đến đúng nhóm theo các quy tắc ngày càng khó duy trì. Hoặc danh mục đang lớn lên đã vượt khỏi cách tổ chức trang hiện tại.

Trong những tình huống đó, bạn có thể thiết kế nội dung, màn hình biên tập và các kết nối theo công việc thực tế. Biên tập viên có thể nhập một sự kiện một lần và thấy ngày diễn ra được hiển thị nhất quán trên toàn website. Nhân viên có thể nhận yêu cầu kèm đúng thông tin khách hàng. Bạn cũng có thể thống nhất thay đổi nào quan trọng tiếp theo, thay vì ép mọi yêu cầu theo những plugin sẵn có.

Những cải thiện đó phải được thiết kế, xây dựng và kiểm thử. Chỉ thay WordPress không tự tạo ra chúng. Một hệ thống được xây dựng theo yêu cầu nhưng lập kế hoạch kém có thể khiến công cụ biên tập yếu hơn và hóa đơn bảo trì lớn hơn.

Hãy bắt đầu bằng cách mô tả vấn đề theo ngôn ngữ kinh doanh: mọi người khó làm việc gì, việc đó xảy ra bao lâu một lần, mất bao nhiêu thời gian hoặc khiến doanh nghiệp bỏ lỡ công việc nào, và kết quả đạt yêu cầu trông như thế nào. Sau đó so sánh các cách giải quyết. Chọn phương án ít gánh nặng nhất mà vẫn đáp ứng nhu cầu và có người duy trì được.

Bạn cần loại thay đổi nào?

“Website mới” có thể chỉ nhiều dự án rất khác nhau. Hãy xác định rõ mình mua gì trước khi so sánh giá.

Nếu nền tảng website vẫn phù hợp và vấn đề nằm ở cách vận hành, đổi nhà cung cấp có thể đã đủ. Hướng dẫn của chúng tôi về chuyển website sang nhà cung cấp khác mà không xây lại bàn riêng về quyết định này.

WordPress dạng headless là một lựa chọn thực tế: WordPress REST API cho phép ứng dụng riêng làm việc với nội dung trong phạm vi quyền truy cập. Điều đó không có nghĩa dữ liệu hay hành vi của mọi plugin đều có sẵn qua API. Giao diện mới vẫn có thể phụ thuộc vào cấu trúc nội dung và quy tắc plugin cũ. Hãy hỏi phương án này giải quyết gì, phần nào ở lại WordPress và ai duy trì kết nối.

Khi nào nên giữ WordPress

Nếu nhóm xuất bản thuận tiện, các chức năng cần thiết chạy tốt và thay đổi tương đối dễ, giữ lại WordPress có thể là lựa chọn hợp lý. Nhu cầu xuất bản thông thường chưa phải lý do để đặt hàng một hệ thống thay thế.

Ngay cả website khó dùng cũng có thể sửa được. Trang chậm có thể cần kiểm tra hình ảnh, máy chủ, xử lý cơ sở dữ liệu hoặc một tính năng cụ thể. Công cụ biên tập khó dùng có thể tốt hơn nhờ cấu trúc nội dung rõ ràng hoặc phát triển WordPress đúng cách. Hãy xem các vấn đề và hậu quả của chúng, thay vì lấy số lượng plugin làm kết luận.

Hãy so sánh cả những nền tảng tiêu chuẩn phù hợp. Nếu một nền tảng đã xử lý tốt nhu cầu đặt chỗ, bán hàng hoặc xuất bản, cấu hình và chuyển đổi cẩn thận có thể đòi hỏi ít công việc lâu dài hơn một hệ thống riêng.

Năng lực của doanh nghiệp cũng quan trọng. Cần có người quyết định hệ thống riêng phải làm gì, xác nhận nó làm được và chi trả cho việc chăm sóc. Có thể thuê bên ngoài phụ trách kỹ thuật, nhưng doanh nghiệp vẫn cần người ra quyết định và nghiệm thu. Nếu chưa có năng lực đó, một nền tảng hiện có dễ quản lý có thể phù hợp hơn.

Tìm hiểu website thực sự làm những gì

Số trang là điểm khởi đầu. Phạm vi chuyển đổi còn phụ thuộc vào nội dung, quan hệ và công việc đằng sau các trang.

Hãy rà soát website cùng những người sử dụng và vận hành nó. Bao gồm cả phần khách truy cập không nhìn thấy:

• Nội dung: trang, bài viết và các loại nội dung khác; chuyên mục và thẻ; tác giả và ngày xuất bản; bản dịch và quan hệ giữa chúng.
• Tệp: ảnh gốc và các tệp khác, chú thích, văn bản thay thế, tệp đính kèm và nơi mỗi tệp được sử dụng.
• Tìm kiếm thông tin: menu, tìm kiếm, bộ lọc, mẫu URL, chuyển hướng hiện có, tiêu đề và mô tả SEO, cùng quy tắc về trang nào công cụ tìm kiếm nên lập chỉ mục.
• Việc khách truy cập làm: biểu mẫu, xác nhận, gửi email, đăng nhập, truy cập tài khoản và quyền.
• Công việc kết nối: hệ thống khách hàng hoặc kế toán, công cụ gửi thư, phân tích, nhập xuất dữ liệu, tác vụ định kỳ và việc chạy nền khác.

Với mỗi mục, hãy quyết định giữ, thay hay ngừng dùng. Ghi lại ai có quyền quyết định và cách xác nhận kết quả hoạt động. Một plugin bỏ quên có thể xóa; plugin khác có thể âm thầm gửi yêu cầu liên hệ mà đội bán hàng đang dựa vào.

Nếu bạn bán sản phẩm, hội viên hoặc chỗ đặt trước, hãy xác định phạm vi riêng cho phần đó. Sản phẩm, đơn hàng, quyền truy cập của khách, gia hạn, tình trạng còn chỗ và các nhà cung cấp kết nối đều cần quyết định rõ. Chuyển nội dung không giải quyết cách duy trì gói thuê bao đang hoạt động hoặc lịch đặt sẵn. Phải điều tra hệ thống và nhà cung cấp thực tế trước khi ai đó hứa có thể chuyển dữ liệu.

Thiết kế công cụ biên tập kỹ như các trang công khai

Rời WordPress không có nghĩa mất hệ thống quản trị. Hãy nêu rõ hệ thống mới phải cho nhóm làm gì. Xây dựng riêng không tự động gồm mọi tính năng mà biên tập viên quen dùng.

Quyết định mỗi loại nội dung gồm những gì. Sự kiện có thể có ngày, địa điểm, liên kết đặt chỗ và bài liên quan. Tách mỗi phần thành trường riêng giúp tái sử dụng và kiểm tra dễ hơn. Đồng thời cần thống nhất cách xử lý ngoại lệ: sự kiện kéo dài nhiều ngày, chưa rõ địa điểm hoặc liên kết đặt chỗ được thêm sau.

Sau đó thống nhất ai được tạo, duyệt và xuất bản nội dung. Bao gồm bản nháp, lịch xuất bản, xem trước, lịch sử sửa đổi, quản lý tệp, menu, tìm kiếm và chỉnh chuyển hướng khi nhóm cần. Quyết định biên tập viên sửa lỗi thế nào và có thể hoàn tác hay không.

Trước khi nghiệm thu công cụ biên tập, hãy nhờ người dùng thực tế làm những việc đại diện. Cho một người chuẩn bị bài, thêm ảnh và văn bản thay thế, xem trước trên điện thoại, lên lịch đăng, sửa lỗi và tìm một mục cũ. Quan sát nơi họ cần trợ giúp. Thấy nhóm của bạn hoàn thành việc bình thường hữu ích hơn một buổi trình diễn đẹp mắt.

Phần nào chuyển được, phần nào phải xây lại?

WordPress có công cụ xuất dữ liệu. Định dạng xuất WXR chứa nội dung đã được mô tả như bài viết, trang, loại nội dung tùy chỉnh, bình luận, trường, chuyên mục và thẻ. Đây có thể là dữ liệu nguồn giá trị, nhưng không phải bản sao website có thể chạy ngay.

Nhóm chuyển đổi cần xem bản cài đặt của bạn thực sự lưu gì: cơ sở dữ liệu, tệp tải lên, bản xuất, phản hồi API và bản ghi riêng của plugin. Giữ bản gốc an toàn trước khi biến đổi bất cứ thứ gì. Xác định mỗi trường bắt buộc nằm ở đâu và các bản ghi liên hệ với nhau thế nào.

Ánh xạ nghĩa là quyết định mỗi giá trị cũ nằm ở đâu trong hệ thống mới. Tác giả vẫn phải gắn với đúng bài. Chuyên mục có thể trở thành chủ đề. Liên kết tới bài liên quan phải trỏ tới bản mới của bài đó. Giá trị thiếu và bản trùng lặp cần cách xử lý đã thống nhất, không được âm thầm bỏ qua.

Ảnh cần được chuyển và kiểm tra riêng. Xác nhận tệp có ở vị trí mới, vẫn gắn với nội dung đúng và tải ở kích thước phù hợp. Cập nhật URL của ảnh nhúng và tệp tải xuống khi cần. Thấy ảnh trên trang đã chuyển chưa đủ nếu ảnh vẫn được phục vụ từ website cũ dự định đóng.

Cũng phải xem bố cục nội dung. WordPress giải thích rằng khối có thể lưu mã đánh dấu và thuộc tính, còn khối động có thể chỉ lưu chỗ giữ vị trí cho phần hiển thị được tạo sau. Vì vậy bài được sao chép có thể chứa chỉ dẫn mà hệ thống mới không hiểu. Các trình dựng trang có cấu trúc riêng và cần kiểm tra riêng.

Giải pháp có thể là chuyển nội dung sang thành phần được hỗ trợ, xây lại một số bố cục hoặc đơn giản hóa trang cũ với sự đồng ý của nhóm biên tập. Sao chép HTML đang hiển thị đôi khi giữ được vẻ ngoài, nhưng không chứng minh biên tập viên có thể cập nhật đúng sau này. Hãy thống nhất cả kết quả công khai lẫn cách biên tập.

Ví dụ về một nhà xuất bản nhỏ

Hãy tưởng tượng nhà xuất bản chuyển website WordPress. Đây là ví dụ giả định, không phải kết quả của khách hàng. Bài thử có tác giả, ảnh chính, hai bài liên quan và biểu mẫu hỏi về quảng cáo.

Tiêu đề và nội dung bài đã nhập đúng. Sau đó nhóm kiểm tra tác giả và ngày xuất bản còn nguyên, bài liên quan dẫn tới đúng trang, và ảnh đã chuyển cùng chú thích và văn bản thay thế. Biên tập viên mở bài, sửa phần đầu và xem trước. Như vậy họ thử cả nội dung lẫn cách biên tập.

Biểu mẫu là một phần việc riêng. Phần thay thế phải thu thập thông tin đã thống nhất, lưu hoặc gửi đúng nơi và báo xác nhận hữu ích cho khách. Có người gửi thử rồi kiểm tra nơi nhận thực tế. Việc biểu mẫu xuất hiện trên trang cũ không có nghĩa hành vi của nó đi theo bài viết.

Lúc này nhà xuất bản đã có bằng chứng cho bốn việc: bài viết, ảnh, một tác vụ biên tập và yêu cầu của khách truy cập. Lặp lại cách thử với các cấu trúc khác nhau sẽ tạo căn cứ xác định phạm vi tốt hơn lời nói “có thể nhập bài viết”.

Giữ URL hữu ích và chủ động lập kế hoạch thay đổi

Khi thay hệ thống nội dung, nhiều khi bạn vẫn có thể giữ tên miền và đường dẫn trang cũ. Hãy yêu cầu rõ nếu những địa chỉ đó còn hữu ích. Đổi CMS không bắt buộc đổi tên miền hay mẫu URL.

Khi địa chỉ phải thay, hãy ánh xạ địa chỉ cũ tới trang mới phù hợp và kiểm tra chuyển hướng. Đừng chuyển mọi trang cũ về trang chủ. Bài đã ngừng, chủ đề được gộp và sản phẩm đã chuyển cần quyết định theo thứ khách truy cập đang tìm.

Hướng dẫn của Google về chuyển website khi URL thay đổi đề cập ánh xạ URL, chuyển hướng vĩnh viễn và kiểm tra địa chỉ chuẩn, liên kết nội bộ, hình ảnh, tham chiếu ngôn ngữ và sơ đồ website. Địa chỉ chuẩn cho công cụ tìm kiếm biết bạn ưu tiên phiên bản trang nào; hãy đảm bảo nó chỉ tới trang thay thế đang hoạt động, không phải website thử hay địa chỉ cũ.

Rà soát tiêu đề, mô tả, quy tắc lập chỉ mục, đường dẫn ngôn ngữ và liên kết trong toàn bộ nội dung. Kiểm tra hạn chế của môi trường thử khi ra mắt: website thử cần tiếp tục riêng tư khi cần, còn các trang dự định công khai phải truy cập được và được phép lập chỉ mục.

Công cụ Change of Address của Google dành cho việc chuyển tên miền hoặc tên miền phụ. Chỉ thay WordPress trên cùng địa chỉ thì bản thân việc đó không đòi hỏi công cụ này.

Thứ hạng tìm kiếm có thể dao động sau thay đổi lớn. Hãy thống nhất điều cần theo dõi, ai điều tra trang bị mất hoặc biến động truy cập bất thường và cách sửa. Không thể lấy kế hoạch chuyển đổi làm lời hứa rằng thứ hạng sẽ không giảm hoặc lưu lượng truy cập sẽ tự tăng.

Thống nhất những gì phải chạy tốt trước khi ra mắt

Viết tiêu chí nghiệm thu theo những việc website phải làm. So sánh nội dung, hình ảnh, liên kết, rồi thử hành vi thực tế. Biểu mẫu phải chuyển tin đúng chỗ. Tìm kiếm phải ra những mục tiêu biểu. Người có quyền phải đăng nhập được, người không có quyền phải bị từ chối. Biên tập viên phải hoàn thành các tác vụ đã thống nhất.

Nếu phạm vi gồm mua hàng, đặt chỗ hoặc tích hợp, hãy thử cả các luồng đó và ngoại lệ quan trọng. Màn hình báo thành công chỉ là một phần kết quả nếu hệ thống kết nối vẫn cần nhận bản ghi.

Dùng môi trường thử được bảo vệ cho công việc này. Hạn chế truy cập thông tin riêng tư và ngăn thử nghiệm gửi tin thật cho khách hoặc kích hoạt thao tác ngoài ý muốn trên hệ thống đang chạy. Thống nhất dữ liệu nào được dùng và cách xử lý các bản sao thử nghiệm.

Lập kế hoạch cho thay đổi diễn ra khi website mới đang chuẩn bị. Bạn có thể tạm ngừng xuất bản để chuyển những sửa đổi cuối, hoặc chuyển lần cuối các bản ghi phát sinh từ lần nhập đầu. Nêu rõ ở từng giai đoạn hệ thống nào giữ bản ghi có thẩm quyền. Nếu không, biên tập viên có thể sửa bài ở một nơi trong khi khách gửi yêu cầu ở nơi khác.

Hướng dẫn của chúng tôi về chạy song song hệ thống cũ và mới khi thay thế đi sâu hơn vào trách nhiệm và quyết định trong quá trình chuyển đổi.

Hãy thống nhất phương án quay lại thực tế. Hướng dẫn sao lưu của WordPress phân biệt cơ sở dữ liệu và tệp cần cho khôi phục. Có bản sao mới là điểm đầu; nhóm vẫn cần chứng cứ rằng dịch vụ cần thiết khôi phục được. Bài của chúng tôi về bản sao lưu website cần khôi phục được những gì nêu điều cần kiểm tra.

Quay lại trở nên phức tạp hơn khi website mới đã nhận yêu cầu, đơn hàng hay sửa đổi, hoặc đã gửi chỉ dẫn tới dịch vụ khác. Cần đối chiếu các bản ghi và hành động đó. Không thể mặc nhiên coi việc phục hồi cơ sở dữ liệu hôm qua sẽ giữ nguyên hoạt động kinh doanh hôm nay. Hãy đặt điều kiện quay lại và người phụ trách trước khi ra mắt.

Điều gì quyết định chi phí và thời gian?

Số lượng nội dung quan trọng, nhưng sự đa dạng cũng vậy. Hàng nghìn bài cùng một cấu trúc có thể dễ dự đoán hơn một tập trang ít hơn nhưng mỗi trang được dựng riêng với hành vi đặc biệt.

Để so sánh các báo giá, hãy yêu cầu giải thích những giả định đằng sau công việc:

• Sẽ điều tra và chuyển những cấu trúc nội dung, khối riêng, bản ghi plugin nào?
• Bao gồm những tích hợp, tài khoản, giao dịch và ngôn ngữ nào?
• Dự kiến thay đổi thiết kế và dọn dẹp nội dung đến mức nào?
• Cần những tính năng biên tập, quyền và đào tạo nào?
• Gồm những kiểm thử, hỗ trợ ra mắt, kế hoạch duy trì hoạt động liên tục và công việc tiếp theo nào?

Hãy dành thời gian cho nhóm của bạn nữa. Mọi người phải cấp quyền truy cập, trả lời câu hỏi, quyết định ngừng dùng gì, dọn nội dung, thử công cụ biên tập và nghiệm thu. Nếu người ra quyết định vắng mặt, công việc có thể phải chờ dù phần phát triển đã sẵn sàng.

Yêu cầu nhà cung cấp tách việc đã rõ khỏi việc cần điều tra. Thử chuyển một trang khó hoặc tính năng phụ thuộc plugin có thể làm rõ những điều chưa chắc chắn dễ gây tốn kém trước khi cam kết cả dự án. Giá cố định dựa trên bản xuất chưa được xem xét có thể che giấu giả định rất khác nhau giữa các nhà cung cấp.

So sánh cả chi phí vận hành từng phương án lẫn chi phí xây dựng. Tính máy chủ, giấy phép, dịch vụ ngoài, cập nhật bản vá, sao lưu, giám sát, hỗ trợ và thay đổi về sau. Giữ WordPress có chi phí, phần mềm riêng cũng vậy. Điều nên so sánh là mỗi đường hướng mang lại gì trong thời gian bạn định dùng và trách nhiệm của mỗi bên có rõ không.

Ai chăm sóc hệ thống riêng?

Hãy thống nhất khi chọn giải pháp. Website xây dựng riêng vẫn phụ thuộc vào framework, thư viện, dịch vụ lưu trữ và các dịch vụ kết nối. Những phần đó cần được chăm sóc. Bảo mật là công việc liên tục: hướng dẫn bảo mật của WordPress nói về giảm rủi ro và chia sẻ trách nhiệm; đổi nền tảng không làm biến mất nhu cầu phân công trách nhiệm ấy.

Đưa việc cập nhật bản vá, sao lưu, giám sát và hỗ trợ sự cố vào thỏa thuận. Nêu ai nhận cảnh báo, ai có thể xử lý, cách báo vấn đề khẩn cấp và phạm vi hỗ trợ thực tế. Bố trí cả quy trình cải tiến thường xuyên, không chỉ sửa lỗi.

Làm rõ quyền truy cập và bàn giao: tài khoản lưu trữ và triển khai, thông tin đăng nhập, xuất dữ liệu, tài liệu, giấy phép và quyền vào kho mã hoặc mã nguồn khi áp dụng. Chỉ được vào mã nguồn không có nghĩa bản quyền đã chuyển hay nhà cung cấp khác có thể vận hành hệ thống. Bàn giao hữu ích còn giải thích cách triển khai, khôi phục và làm việc với các phần phụ thuộc.

Hai chuyên gia Google là Acacio Cruz và Ashish Bhambhani mô tả tài liệu, đào tạo và chuyển trách nhiệm vận hành trong bài viết về mức độ sẵn sàng của dịch vụ. Doanh nghiệp nhỏ không cần cơ cấu đội ngũ của Google để áp dụng ý chính: người nhận trách nhiệm phải có kiến thức và quyền truy cập để làm việc.

LINK-V cung cấp website và hệ thống riêng, chuyển đổi, tích hợp, thiết kế và bảo trì liên tục. Việc xây dựng, quyền, bàn giao và chăm sóc tiếp theo cần được thống nhất cho dự án của bạn. Bạn có thể tìm hiểu phát triển theo yêu cầu hoặc các dịch vụ riêng lẻ theo công việc cần làm.

Chuẩn bị gì cho buổi trao đổi đầu tiên

Bạn không cần mang đến một bản đặc tả kỹ thuật. Hãy chuẩn bị đủ thông tin để vấn đề trở nên rõ ràng:

• Website hiện tại và người nắm quyền quản trị, lưu trữ, tên miền và các dịch vụ kết nối.
• Khó khăn lặp lại, một ví dụ cụ thể và điều bạn muốn mọi người làm được thay vào đó.
• Nội dung, chức năng và địa chỉ hữu ích phải giữ, cùng phần muốn ngừng dùng.
• Biên tập viên và người dùng khác cần tham gia thử bản thay thế.
• Dịch vụ kết nối, ngày giao dịch hoặc xuất bản quan trọng và mức gián đoạn doanh nghiệp chịu được.
• Câu hỏi về chi phí, quyền, truy cập, hỗ trợ và thay đổi trong tương lai.

Điều đó giúp buổi trao đổi tiếp theo có mục đích thực tế: xác định liệu cải thiện website hiện tại đã đủ, tìm những điều chưa biết và thống nhất phải chứng minh gì trước khi đặt hàng bản thay thế.