Checklist kiểm tra website sau khi chuyển hosting: DNS, SSL, email, form và SEO

Sau khi chuyển hosting, việc website mở được trang chủ chưa đủ để kết luận migration đã hoàn tất. DNS có thể vẫn phân giải không đồng nhất, form gửi thành công nhưng email không tới, cron hoặc webhook vẫn gọi môi trường cũ, canonical có thể sai, hoặc production vô tình giữ noindex từ staging.

Tóm tắt: Nghiệm thu sau migration nên đi theo thứ tự DNS → HTTPS → dữ liệu và chức năng → form/email → SEO kỹ thuật → tracking → log/tài nguyên → backup và rollback. Chỉ hủy hosting cũ khi các hạng mục quan trọng đã PASS và không còn phụ thuộc cần quay lại.

Nếu bạn chưa thực hiện cutover, hãy bắt đầu từ quy trình chuyển website sang hosting mới. Bài này chỉ sở hữu giai đoạn VERIFY sau khi traffic đã bắt đầu đi vào hosting mới, nhằm tránh trùng search intent với bài hướng dẫn migration.

Migration “xong” nghĩa là gì?

Một migration chỉ nên được xem là đã qua nghiệm thu khi domain đang phân giải tới hạ tầng dự kiến, HTTPS hoạt động đúng, website và database đầy đủ, chức năng kinh doanh chạy bình thường, các chỉ thị SEO kỹ thuật không bị thay đổi ngoài kế hoạch, hệ thống đo lường vẫn nhận dữ liệu và có restore point mới của môi trường sau migration.

• DNS và hostname quan trọng trả về đúng đích.
• HTTP/HTTPS và phiên bản www hoặc non-www theo đúng thiết kế.
• File, media, database và dữ liệu phát sinh không bị thiếu.
• Đăng nhập, form, email, thanh toán, API, webhook hoạt động.
• Canonical, robots, noindex, sitemap và internal link đúng.
• Analytics, Tag Manager, Search Console và conversion tracking tiếp tục nhận dữ liệu.
• Log và resource usage không xuất hiện bất thường nghiêm trọng.
• Backup mới được tạo và phương án rollback vẫn còn khả dụng.

1. Kiểm tra DNS đang trỏ tới đâu

Sau cutover, hãy xác minh domain và các hostname quan trọng đang phân giải tới đích dự kiến. Không nên chỉ kiểm tra trên một máy vì resolver của thiết bị hoặc nhà mạng có thể còn cache record cũ.

Cloudflare khuyến nghị ở giai đoạn post-migration phải test các dịch vụ phụ thuộc DNS như website, email và API từ nhiều mạng nếu có thể, đồng thời theo dõi log để tìm lỗi liên quan DNS. Xem Phase 4: Post-migration and DNSSEC Re-activation của Cloudflare.

Nếu thay đổi DNS là phần rủi ro chính của dự án, xem thêm DNS Change Management: TTL, cutover, validation và rollback.

2. Kiểm tra HTTPS và certificate

Sau khi DNS đi đúng, kiểm tra HTTPS trên domain chính, phiên bản www/non-www và các subdomain quan trọng. Với CDN hoặc reverse proxy, cần hiểu certificate được kết thúc ở edge hay origin để tránh sửa sai lớp.

• Certificate hợp lệ cho đúng hostname.
• HTTP chuyển hướng sang HTTPS đúng một hướng.
• Không có redirect loop giữa CDN, proxy và origin.
• Không có mixed content nghiêm trọng.
• API, ảnh, CSS và JavaScript không còn gọi endpoint HTTP cũ.

3. Xác nhận traffic thật đang vào server mới

DNS đúng chưa chắc đồng nghĩa mọi request đã rời máy chủ cũ. CDN, cache hoặc resolver cũ có thể che khuất trạng thái thật. Hãy đối chiếu access log, PHP/web-server log hoặc dashboard của môi trường mới để xác nhận request thật đang tới server mới.

Nếu website mở được nhưng hosting mới gần như không ghi nhận request, cần điều tra trước khi tiếp tục nghiệm thu.

4. Kiểm tra file, media và database

Không chỉ mở homepage. Hãy lấy mẫu nhiều page type: bài viết, trang dịch vụ, category, ảnh cũ, file tải xuống, tìm kiếm, tài khoản người dùng, sản phẩm và dữ liệu động nếu website có.

Điểm cần chú ý nhất là dữ liệu phát sinh giữa bản backup đầu tiên và thời điểm cutover. Với website có đơn hàng, lead, booking, comment hoặc tài khoản mới, phải xác minh dữ liệu đó đã được đồng bộ đầy đủ.

5. Kiểm tra đăng nhập, admin và tác vụ nền

• Đăng nhập, logout và reset password.
• Upload media và lưu bài viết.
• AJAX, REST API và quyền user.
• WP-Cron hoặc cron hệ thống.
• Queue, scheduled job và tác vụ nền.

Nếu frontend nhanh nhưng admin chậm, nguyên nhân có thể nằm ở PHP, database, plugin, cron hoặc API bên thứ ba. Khi đó hãy dùng quy trình chẩn đoán lỗi hosting để xác định KEEP, OPTIMIZE, UPGRADE hay MIGRATE thay vì vội nâng gói.

6. Test form và email từ đầu đến cuối

Một form hiện thông báo “gửi thành công” chưa chứng minh lead đã tới nơi. Hãy kiểm tra toàn bộ chuỗi:

User submit → website xử lý → SMTP/mail service → mailbox nhận → CRM/automation nếu có.

• Form liên hệ và báo giá.
• Newsletter hoặc đăng ký tài khoản.
• Form đặt lịch, tuyển dụng hoặc upload.
• Email transactional, reset password, order notification.
• MX, SPF, DKIM, DMARC và SMTP nếu DNS hoặc nhà cung cấp mail có liên quan tới migration.

7. Kiểm tra checkout, webhook và API quan trọng

Website thương mại cần test các luồng tạo doanh thu trước khi gọi migration là thành công: giỏ hàng, checkout, payment callback, webhook, CRM, ERP, vận chuyển, SMS, SSO và API bên thứ ba.

Một số dịch vụ whitelist IP. Khi origin IP thay đổi nhưng hệ thống bên thứ ba vẫn chỉ cho phép IP cũ, lỗi thường chỉ xuất hiện lúc giao dịch thật.

8. Kiểm tra URL và redirect

Nếu dự án chỉ đổi hosting, URL public thông thường không nên đổi. Crawl một tập URL quan trọng để tìm 404 mới, 5xx, redirect loop, chain hoặc rule redirect ngoài kế hoạch.

Nếu migration đồng thời đổi domain hoặc URL, đó là một scope riêng. Google khuyến nghị kiểm tra URL mapping, redirect, canonical và internal link trong quy trình site move. Xem Site Moves and Migrations của Google Search Central.

9. Kiểm tra canonical, robots và noindex

Đây là nhóm lỗi SEO có thể không nhìn thấy trên giao diện. Kiểm tra homepage và các page type quan trọng để chắc canonical trỏ về preferred URL thực tế, không về staging, IP hoặc domain cũ ngoài kế hoạch.

• robots.txt không chặn nhầm vùng cần crawl.
• Meta robots hoặc X-Robots-Tag không còn noindex từ staging.
• Canonical phản ánh URL preferred.
• Không dùng robots.txt như công cụ thay thế noindex.

Google cũng nhắc phải gỡ các rule noindex hoặc block tạm đã dùng trong môi trường chuẩn bị khi site bắt đầu phục vụ thật.

10. Kiểm tra sitemap và internal link

Sitemap nên trả 200 và chỉ chứa preferred canonical indexable URLs phù hợp. Nếu chỉ đổi hosting và URL giữ nguyên, sitemap không cần đổi URL chỉ vì server thay đổi.

• Không còn URL staging hoặc IP.
• Không đưa URL redirect hoặc noindex vào sitemap một cách không chủ đích.
• Internal link không trỏ staging, IP hoặc HTTP cũ.
• Nếu URL có thay đổi, link nội bộ nên trỏ trực tiếp URL mới thay vì phụ thuộc redirect.

11. Kiểm tra Analytics, Tag Manager và Search Console

Đừng chỉ nhìn source code để thấy tag. Hãy tạo test event thực tế và xác nhận hệ thống nhận dữ liệu.

• Google Analytics và Google Tag Manager.
• Conversion, Ads tracking, Meta Pixel hoặc call tracking nếu có.
• Search Console property vẫn verified.
• Sitemap và URL Inspection của một số URL quan trọng hoạt động bình thường.
• Theo dõi 5xx, crawl và page indexing sau cutover.

Nếu domain và URL không đổi thì thay hosting không đồng nghĩa phải khai báo một URL move mới trong Search Console. Trọng tâm là crawl, HTTP response, indexability và khả năng phục vụ của hạ tầng mới.

12. So sánh hiệu suất và tài nguyên trước/sau migration

Không đánh giá hosting mới bằng một lần mở trang. Hãy so baseline trước và sau theo các điểm thực sự liên quan tới workload: response time, CPU, RAM, I/O, process, query, cache hit, 4xx/5xx và uptime.

Nếu cần đọc đúng CPU, RAM, I/O, IOPS hoặc entry process trước khi kết luận thiếu tài nguyên, xem hướng dẫn đọc thông số hosting.

13. Theo dõi log và monitoring sau cutover

Một số lỗi chỉ xuất hiện khi traffic thật quay lại. Theo dõi web-server log, PHP log, application log, database errors, 404/5xx, cron, queue, mail và WAF. Nếu cần xây baseline và alert lâu dài, xem Website Monitoring là gì?.

14. Tạo backup mới của môi trường sau migration

Backup dùng để di chuyển không nên là restore point vận hành duy nhất. Sau khi môi trường mới ổn định, hãy tạo backup mới, lưu ngoài cùng hosting nếu phù hợp, kiểm tra database export và xác nhận quy trình restore.

15. Khi nào được hủy hosting cũ?

Không có một số giờ cố định áp dụng cho mọi website. Chỉ cân nhắc decommission khi DNS đã ổn định, traffic thật chạy ở môi trường mới, form/email và chức năng kinh doanh đã test, dữ liệu đầy đủ, không còn integration trỏ server cũ, monitoring hoạt động và rollback không còn cần thiết theo change plan.

Cloudflare cũng khuyến nghị chỉ decommission hạ tầng DNS cũ sau giai đoạn ổn định và khi đã chắc chắn các resolver/dịch vụ không còn phụ thuộc môi trường cũ.

Checklist nghiệm thu nhanh sau khi chuyển hosting

Nếu phát hiện lỗi sau migration thì xử lý thế nào?

Không sửa đồng thời nhiều lớp. Ghi URL/chức năng lỗi, thời điểm, HTTP status, log liên quan, DNS/IP đang trả về và thay đổi gần nhất. Sau đó phân loại lỗi vào DNS/SSL, application, tài nguyên hoặc dữ liệu rồi mới quyết định sửa tiếp hay rollback.

Nếu lỗi diện rộng, mất dữ liệu hoặc website không phục vụ chức năng kinh doanh quan trọng, ưu tiên bảo toàn log và đánh giá rollback. Nếu cần đội kỹ thuật rà hạ tầng hoặc hỗ trợ migration, xem dịch vụ hosting tại TP.HCM; nếu lỗi nằm ở ứng dụng, dùng đúng owner dịch vụ sửa lỗi website thay vì quy mọi lỗi cho hosting.

Kết luận

Migration chỉ thực sự hoàn thành khi môi trường mới được nghiệm thu. Thứ tự an toàn là DNS → HTTPS → dữ liệu → chức năng → form/email → SEO kỹ thuật → tracking → log/tài nguyên → backup → decommission.

Ba nguyên tắc quan trọng nhất là không hủy hosting cũ quá sớm, không kết luận website ổn chỉ vì homepage mở được và không thay đổi thêm nhiều thành phần trong lúc đang xác minh. Nếu migration chưa bắt đầu, quay lại quy trình chuyển website sang hosting mới; nếu đã cutover và đang có lỗi, dùng bài chẩn đoán lỗi hosting để xác định bước tiếp theo.

Đoàn Trình Dục

Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.