Chuyển website: giữ đường đọc với redirect và kiểm URL
Lập inventory URL, mapping redirect, kiểm canonical, nội dung, ảnh và sitemap; theo dõi sau migration và chuẩn bị đường rollback.

Cập nhật: · Minh họa được tạo bằng AI
Chuyển website sang nền tảng hoặc giao diện mới có thể làm mất đường dẫn mà khách và công cụ tìm kiếm đang dùng. Một bản mới đẹp nhưng các bài cũ 404, ảnh lỗi hoặc canonical vẫn ở domain thử chưa phải migration hoàn chỉnh. Mục tiêu là giữ nội dung cần thiết và đưa mỗi URL cũ tới nơi phù hợp.
Không có cách hứa migration sẽ không bao giờ làm biến động tìm kiếm. Bạn có thể giảm lỗi có thể tránh bằng inventory, mapping, kiểm tra và theo dõi. Bài này trình bày quy trình cho doanh nghiệp nhỏ; các website lớn cần phạm vi lấy mẫu và hạ tầng riêng.
1. Giữ inventory trước khi thay gì
Thu URL từ sitemap, link nội bộ, dữ liệu search và catalog đang có. Ghi loại trang, trạng thái, title, canonical, nội dung chính và ảnh quan trọng. Phân biệt trang cần giữ, cần hợp nhất và đã hết nhiệm vụ. Đừng chỉ lấy các link trong menu vì nhiều bài hoặc sản phẩm không có ở đó.
Đánh dấu trang có traffic hoặc backlink khi có dữ liệu thật. Nếu chưa có quyền xem, ghi giới hạn thay vì bịa ưu tiên theo lượt truy cập. Google về site moves cung cấp khung tham khảo cho thay URL. Inventory là cơ sở để biết bản mới đã phục vụ đủ đường đi cũ chưa.
2. Mapping redirect theo nội dung tương đương
Với mỗi URL đổi, chọn một đích trả lời gần nhất với nhiệm vụ cũ. Không đưa mọi link mất về trang chủ. Nếu sản phẩm không còn và không có thay thế tương đương, xem chính sách nội dung và trạng thái phù hợp thay vì tạo redirect vô nghĩa. Tách quyết định nghỉ trang khỏi quyết định đổi địa chỉ.
Dùng redirect permanent khi thực sự chuyển lâu dài, kiểm status và tránh chain cũ → trung gian → mới. Google về redirect giúp tra cách hệ thống diễn giải. Một plugin đã lưu quy tắc chưa chứng minh quy tắc hoạt động trên host production.
3. Chuẩn bị nội dung và asset của bản mới
Chuyển tiêu đề, nội dung, ảnh, alt, ngày và link đúng theo từng record. Giữ slug nếu không có lý do thay. Khi sửa nội dung, ghi rõ thay đổi thực thay vì đổi tất cả ngày published thành ngày migration. Với song ngữ, kiểm cả hai bản và đường alternate.
Ảnh cần sống ở nơi website mới truy cập được, không chỉ trên máy của người triển khai hoặc domain preview được bảo vệ. Thử thumbnail, hero, ảnh trong bài và ảnh social. Đối chiếu mỗi template với nguồn cũ để tìm phần mất như bảng, checklist hoặc liên kết nguồn.
4. Kiểm SEO kỹ thuật trước khi gắn domain
Kiểm 200 cho URL cần giữ, canonical đúng domain, robots/noindex, sitemap, metadata và structured data. Môi trường preview thường cần hạn chế index; bản production phải dùng chỉ dẫn theo mục đích thật. Đừng bỏ bảo vệ preview trước khi nội dung sẵn sàng, cũng đừng mang noindex thử nghiệm lên live.
Chạy kiểm một mẫu mỗi template và tất cả URL mapping nếu quy mô cho phép. Kiểm link trong bài không còn trỏ preview. Checklist technical SEO giúp nối các tín hiệu. Một build thành công chỉ chứng minh mã có thể xây, không chứng minh redirect hay domain đúng.
5. Phát hành có mốc và cách quay lại
Ghi commit hoặc phiên bản, thời điểm, domain và người xác nhận. Giữ bản snapshot dữ liệu cần thiết cùng bảng mapping. Chọn đường rollback tương ứng loại thay đổi: code, cấu hình domain hay dữ liệu. Đừng giả định rollback code tự khôi phục nội dung đã xóa trên một hệ thống khác.
Sau phát hành, kiểm domain public, trang cũ, trang mới và request ảnh. Không chỉ nhìn trạng thái ‘READY’ của deployment. Với form hoặc thanh toán, dùng phép kiểm phù hợp tránh tạo tác vụ thật ngoài phạm vi. Ghi cả những phần chưa xác nhận như nhận email hoặc webhook.
6. Theo dõi sau migration theo trang và nhóm lỗi
Xem index, canonical và lỗi trong Search Console khi có quyền; so traffic theo khoảng ngày tương đương và ghi các thay đổi khác xảy ra cùng lúc. Tập trung lỗi có thể hành động như redirect sai, 404 ngoài dự kiến, ảnh không truy cập được và metadata lệch.
Khi thấy giảm click, không tự đổi tiếp mọi URL. Kiểm nhóm trang bị ảnh hưởng và giả thuyết cụ thể. Để hệ thống có cơ hội xử lý tín hiệu mới trong khi sửa lỗi rõ ràng. Báo cáo migration nên tách triển khai đã thành công, URL đã kiểm và kết quả tìm kiếm còn cần theo dõi. Đó là ba loại bằng chứng khác nhau.
Câu hỏi thường gặp
Đổi giao diện có cần đổi slug không?
Thường không. Nếu nhiệm vụ và nội dung vẫn giữ, bảo toàn URL giúp giảm công việc migration. Chỉ đổi khi có lý do kiến trúc rõ và mapping tương ứng, không đổi để giao diện mới trông như một website hoàn toàn khác.
Nguồn tham khảo và đọc tiếp
Bạn cần áp dụng vào website hiện tại? Xem dịch vụ website hoặc trao đổi với Dean Vu để xác định phạm vi dựa trên website và dữ liệu thực tế.