Dịch vụ SEO Migration: chuyển website mà không đánh mất khả năng được tìm thấy

Migration hiếm khi hỏng vì một quyết định lớn sai. Nó hỏng vì những chi tiết nhỏ bị bỏ sót: một thẻ noindex còn sót lại từ môi trường thử nghiệm, một quy tắc redirect viết rộng quá tay, một nhóm URL có backlink bị gom hết về trang chủ vì không ai tìm được trang tương đương, hoặc một file robots.txt của bản dựng mới đè lên file cũ ngay lúc chuyển DNS.

Trang này mô tả cách RED tổ chức một dự án SEO Migration: phân loại chính xác loại thay đổi trước khi lập checklist, dựng sổ mapping URL có ghi lý do và độ tin cậy cho từng dòng, kiểm tra tương đương giữa trang cũ và trang đích thay vì so chuỗi ký tự, đối chiếu parity của toàn bộ tín hiệu kỹ thuật, dựng cổng go/no-go cho ngày launch, rồi giám sát sau launch theo từng nhóm trang thay vì nhìn một đường tổng.

Một điều cần nói trước, vì nó quyết định cách đánh giá cả dự án. Tài liệu của Google về site move nói rõ rằng biến động tạm thời trong xếp hạng và lưu lượng là điều nên dự kiến trong quá trình Google xử lý việc chuyển đổi. RED không cam kết migration không tụt lưu lượng, không cam kết giữ nguyên thứ hạng của từng URL, và không đưa ra mốc thời gian Google sẽ xử lý xong. Cái kiểm soát được là chất lượng chuẩn bị, độ đầy đủ của mapping, tính nhất quán của tín hiệu và tốc độ phát hiện sự cố sau launch.

Xác định loại migration trước khi lập bất kỳ checklist nào

Câu hỏi đầu tiên không phải "cần làm gì" mà là "thực sự đang thay đổi cái gì".

Google có hai tài liệu riêng biệt cho hai tình huống khác nhau: một cho site move có thay đổi URL, một cho việc chuyển hosting mà URL giữ nguyên. Đây không phải chi tiết hình thức. Hai tình huống này có quy trình khác nhau, rủi ro khác nhau và cách xác minh khác nhau. Dùng checklist của loại này cho loại kia là nguyên nhân của cả hai kiểu sai lầm: hoặc làm thừa những việc không cần, hoặc bỏ sót những việc bắt buộc.

Thực tế các dự án thường không thuộc một loại thuần. Doanh nghiệp đổi tên miền, đồng thời đổi CMS, đồng thời tái cấu trúc URL, đồng thời chuyển sang hạ tầng mới — tất cả trong một lần phát hành. Đây là tình huống rủi ro cao nhất, không phải vì từng thay đổi khó, mà vì khi có sự cố sẽ không xác định được biến nào gây ra.

Bảng phân loại migration

Nguyên tắc giảm số biến thay đổi cùng lúc

Khi lịch kinh doanh cho phép, tách các thay đổi thành nhiều lần phát hành nối tiếp thay vì gộp một lần. Ví dụ trình tự thường dùng: chuyển hạ tầng trước với URL giữ nguyên, ổn định, rồi mới đổi CMS, ổn định tiếp, rồi mới tái cấu trúc URL. Mỗi giai đoạn có một đường cơ sở riêng, nên khi lưu lượng biến động sẽ biết biến nào liên quan.

Khi lịch kinh doanh không cho phép tách — trường hợp phổ biến với dự án thay thương hiệu hoặc sáp nhập — thì phải bù bằng độ sâu của khâu chuẩn bị: mapping đầy đủ hơn, kiểm thử trên môi trường thử nghiệm kỹ hơn, và một kế hoạch quay lui viết sẵn chứ không ứng biến trong ngày launch.

Việc phân loại cũng quyết định phạm vi công việc và ngân sách. Chuyển hosting giữ nguyên URL là dự án đo bằng ngày; đổi tên miền kèm tái cấu trúc URL cho một website thương mại điện tử vài chục nghìn trang là dự án đo bằng tuần, với phần lớn thời gian nằm ở khâu mapping chứ không phải khâu deploy.

Mapping URL là xương sống của migration

Câu hỏi ở đây: mỗi URL cũ đi về URL mới nào, vì lý do gì, và mức độ tự tin của quyết định đó là bao nhiêu?

Google mô tả chuyển hướng vĩnh viễn là tín hiệu mạnh cho biết URL đích là URL nên xuất hiện trong kết quả tìm kiếm, và đây là cơ chế được dùng cho site move. Nhưng tài liệu cũng nêu giới hạn quan trọng: chuyển hướng nhiều URL không liên quan về một đích chung có thể bị coi như trang không tồn tại. Đây chính là lý do việc gom hàng loạt URL cũ về trang chủ — cách xử lý nhanh nhất và phổ biến nhất khi dự án gấp — thường phản tác dụng.

Cách làm của RED là dựng một sổ mapping trong đó mỗi dòng phải có lý do, không chỉ có URL nguồn và URL đích.

Sổ mapping URL

Thứ tự ưu tiên khi mapping

Với website vài chục nghìn URL, không thể mapping thủ công từng dòng. Thứ tự xử lý nên đi theo giá trị:

Nhóm thứ nhất là các URL có lưu lượng tự nhiên trong mười hai tháng gần nhất, xếp theo số phiên. Nhóm thứ hai là các URL có backlink từ tên miền bên ngoài — đây là nhóm dễ bị bỏ quên nhất vì chúng có thể không có lưu lượng nhưng vẫn mang tín hiệu. Nhóm thứ ba là các URL đang được index, lấy từ báo cáo trong Search Console. Nhóm thứ tư là phần còn lại, xử lý bằng quy tắc mẫu.

Ba nhóm đầu cần mapping có kiểm tra thủ công cho từng dòng hoặc từng cụm nhỏ. Nhóm cuối có thể xử lý bằng quy tắc chuyển đổi theo mẫu, nhưng phải kiểm mẫu ngẫu nhiên trước khi áp dụng — quy tắc mẫu viết sai sẽ sai đồng loạt trên hàng nghìn URL.

Ba lỗi mapping làm hỏng dự án

Gom về trang chủ. Khi không tìm được trang tương đương, phản xạ thường thấy là chuyển hướng về trang chủ. Với vài URL thì không sao; với hàng nghìn URL không liên quan thì đây đúng là kịch bản mà tài liệu Google cảnh báo, và kết quả là các URL đó được xử lý như trang không tồn tại chứ không phải như chuyển hướng hợp lệ.

Chuyển hướng nhiều bước. URL cũ trỏ sang URL trung gian, URL trung gian trỏ sang URL đích. Chuỗi này thường sinh ra khi website đã trải qua nhiều lần migration và mỗi lần đều thêm một lớp quy tắc mới lên trên lớp cũ. Cách xử lý là làm phẳng: mọi URL cũ trỏ thẳng một bước về đích cuối cùng.

Bỏ quên URL có tham số và URL biến thể. Bản kiểm kê URL lấy từ sitemap thường không chứa các URL có tham số theo dõi, URL lọc, hoặc URL biến thể sản phẩm — trong khi đó lại là nhóm có thể đang mang backlink hoặc đang được index. Bản kiểm kê phải hợp nhất từ nhiều nguồn: crawl toàn site, dữ liệu phân tích, báo cáo Search Console, và dữ liệu backlink.

Trang đích phải thực sự tương đương, không chỉ giống slug

Câu hỏi: hai URL có slug gần giống nhau thì có đủ căn cứ để chuyển hướng không?

Không. Đây là lỗi hệ thống của cách mapping bằng so khớp chuỗi ký tự. Slug giống nhau chỉ nói lên rằng hai URL có cách đặt tên giống nhau, không nói lên rằng hai trang phục vụ cùng một nhu cầu. Trong dự án thực tế, việc chuyển hướng một trang bài viết chuyên sâu về một trang danh mục có tên gần giống là kiểu sai làm người dùng bấm vào từ kết quả tìm kiếm và không thấy thứ họ muốn — kèm rủi ro trang đích bị xử lý như trang không tồn tại vì nội dung không tương ứng.

Bài kiểm tra tương đương trang

Khi không có trang tương đương

Đây là tình huống cần quyết định thay vì né tránh. Có ba lựa chọn hợp lệ và mỗi lựa chọn có cái giá riêng.

Thứ nhất: tạo trang tương đương ở bản mới. Đắt nhất, nhưng đúng nhất khi URL cũ đang có lưu lượng hoặc backlink đáng kể. Với các URL nằm trong nhóm ưu tiên cao, chi phí tạo trang thường nhỏ hơn chi phí mất đi nhóm truy vấn mà trang đó đang phục vụ.

Thứ hai: chuyển hướng về trang gần nhất trong cùng nhánh nội dung — không phải trang chủ, mà là trang danh mục hoặc trang chủ đề cha. Chấp nhận được khi trang đích thực sự phục vụ cùng nhóm nhu cầu ở mức khái quát hơn.

Thứ ba: để trả 410. Đây là lựa chọn đúng khi nội dung đã ngừng vĩnh viễn và không có gì thay thế. Nó tạo tín hiệu dứt khoát và tránh sinh ra một lớp chuyển hướng vô nghĩa phải bảo trì về sau. Nhiều đội tránh phương án này vì cảm giác "mất trang", nhưng chuyển hướng gượng ép về một trang không liên quan không giữ được gì mà còn tạo thêm rủi ro.

Quyết định thuộc nhóm nào là quyết định chung giữa RED và phía kinh doanh. RED cung cấp dữ liệu — URL đang có lưu lượng bao nhiêu, có backlink từ đâu, phục vụ truy vấn nào — còn việc trang đó có đáng tạo lại hay không phụ thuộc vào định hướng sản phẩm của doanh nghiệp.

Giữ parity của toàn bộ tín hiệu, không chỉ redirect

Câu hỏi: ngoài chuyển hướng, những tín hiệu nào phải được chuyển sang bản mới ở trạng thái tương đương?

Đây là phần bị bỏ sót nhiều nhất. Đội dự án tập trung toàn bộ vào bảng redirect, launch xong mới phát hiện thẻ canonical ở bản mới vẫn trỏ về tên miền cũ, hoặc liên kết nội bộ trong nội dung vẫn dẫn tới URL cũ và đi qua một lớp chuyển hướng, hoặc dữ liệu có cấu trúc bị mất khi đổi CMS.

Google mô tả các tín hiệu canonical bao gồm chuyển hướng, thẻ rel=canonical và sitemap, và Google tự chọn URL đại diện dựa trên tập tín hiệu đó. Khi các tín hiệu này mâu thuẫn sau migration — redirect nói một đằng, canonical nói một nẻo, sitemap nói thứ ba — kết quả sẽ không dự đoán được.

Ma trận parity tín hiệu

Ảnh chụp trạng thái trước launch

Điều kiện tiên quyết cho toàn bộ ma trận trên là một bản crawl đầy đủ của website cũ, lưu lại trước ngày launch. Không có bản này thì sau launch không có gì để so sánh, và mọi tranh luận về "trước đây có hay không" đều thành phỏng đoán.

Bản crawl cũ cần lưu tối thiểu: danh sách URL, mã trạng thái, thẻ tiêu đề, thẻ mô tả, thẻ H1, canonical, thẻ robots, danh sách liên kết nội bộ, và các loại dữ liệu có cấu trúc. Kèm theo là bản xuất dữ liệu từ Search Console và công cụ phân tích cho ít nhất mười hai tháng gần nhất.

Điểm chặn tuyệt đối: không launch khi bản mới còn thẻ noindex diện rộng hoặc còn dòng chặn toàn site trong robots.txt. Đây không phải lỗi cần ưu tiên cao — đây là lỗi hoãn launch. Chi tiết về cơ chế crawl, render và index nằm trong phạm vi SEO kỹ thuật và được áp dụng nguyên vẹn trong dự án migration.

Ngày launch cần một cổng go/no-go, không phải một danh sách việc

Câu hỏi: lỗi nào đủ nghiêm trọng để hoãn phát hành, và ai có quyền quyết định?

Khác biệt giữa một checklist và một cổng kiểm soát nằm ở chỗ: checklist liệt kê việc cần làm, cổng kiểm soát định nghĩa điều kiện bắt buộc phải đạt mới được đi tiếp. Trong ngày launch, áp lực lịch trình luôn đẩy đội dự án về phía "cứ lên rồi sửa sau". Với một số loại lỗi, cách đó chấp nhận được. Với một số loại khác thì không, vì hậu quả kéo dài hơn nhiều so với thời gian tiết kiệm được.

Cổng kiểm soát ngày launch

Điều kiện quay lui

Kế hoạch quay lui phải được viết trước launch, không ứng biến trong lúc sự cố. Nội dung tối thiểu: điều kiện kích hoạt quay lui viết cụ thể bằng con số hoặc trạng thái quan sát được, người có quyền ra lệnh, các bước kỹ thuật, thời gian ước tính, và cách xử lý dữ liệu phát sinh giữa hai mốc.

Cần lưu ý rằng quay lui trong migration có thay đổi URL không phải thao tác miễn phí. Nếu Googlebot đã crawl bản mới và ghi nhận các chuyển hướng, việc đảo ngược sẽ tạo thêm một lớp thay đổi nữa. Vì vậy ngưỡng quay lui nên đặt ở mức sự cố nghiêm trọng thật sự — website không truy cập được, chức năng thanh toán hỏng, dữ liệu sai — chứ không phải ở mức "một số trang hiển thị chưa đúng".

Search Console và sitemap hỗ trợ khâu phát hiện sau khi chuyển

Câu hỏi: công cụ Change of Address dùng khi nào, và nộp sitemap mới có tác dụng gì?

Tài liệu site move của Google mô tả một quy trình gồm chuẩn bị và kiểm thử bản mới, lập bản đồ URL, thiết lập chuyển hướng vĩnh viễn, dùng công cụ thông báo thay đổi địa chỉ khi đổi tên miền, cập nhật sitemap, và theo dõi sau khi chuyển. Điểm cần giữ đúng kỳ vọng: đây là các thao tác giúp Google phát hiện và xử lý việc chuyển đổi nhanh hơn, không phải các thao tác bảo đảm giữ nguyên thứ hạng hay bảo đảm index ngay.

Danh sách việc trong Search Console

Một chi tiết hay bị làm sai: giữ sitemap của tên miền cũ hoạt động thêm một thời gian sau launch. Điều này giúp Google crawl lại các URL cũ và ghi nhận chuyển hướng nhanh hơn, thay vì phải chờ phát hiện tự nhiên. Nhưng sitemap cũ phải chứa đúng danh sách URL cũ đang có chuyển hướng — không phải một sitemap trộn lẫn.

Giám sát theo nhóm trang, không chỉ nhìn đường tổng

Câu hỏi: sau launch, nhóm trang nào đang mất số nhấp, số lần hiển thị hoặc mất trạng thái được index?

Đường tổng của toàn website che giấu nhiều thứ. Một website có thể giảm tổng số nhấp năm phần trăm sau migration, con số nghe như trong ngưỡng biến động bình thường — trong khi thực tế là một nhánh danh mục mất tám mươi phần trăm còn phần còn lại tăng nhẹ và bù vào. Nhìn đường tổng sẽ phát hiện vấn đề này muộn hàng tuần.

Vì vậy giám sát phải chia theo nhóm, và các nhóm phải được định nghĩa trước launch cùng với đường cơ sở của chúng.

Bảng giám sát theo nhóm sau migration

Nhóm cuối cùng là thứ giữ cho chẩn đoán không bị lệch. Không phải mọi biến động sau launch đều do migration. Thị trường có mùa vụ, đối thủ có thay đổi, Google có cập nhật thuật toán, và bản thân tài liệu của Google cũng nói biến động tạm thời là điều nên dự kiến trong quá trình xử lý site move. Nếu nhóm đối chứng — các trang không đổi URL, không nằm trong phạm vi migration — cũng giảm cùng thời điểm với biên độ tương tự, thì nguyên nhân nhiều khả năng không nằm ở bảng chuyển hướng. Khi cần đi sâu vào việc phân tách nguyên nhân giữa migration, thuật toán và cạnh tranh, nội dung đó thuộc phạm vi phân tích tụt hạng.

Về khung thời gian: RED không đưa ra con số ngày hay tuần cho việc Google xử lý xong một site move, vì con số đó phụ thuộc quy mô website, tần suất crawl và nhiều yếu tố không quan sát được từ phía website. Cái theo dõi được là tiến độ crawl lại các URL cũ và tốc độ URL mới xuất hiện trong báo cáo.

Chuyển hướng và hạ tầng cũ cần một kế hoạch ngừng

Câu hỏi: bao giờ có thể tắt máy chủ cũ và gỡ các quy tắc chuyển hướng?

Google khuyến nghị giữ chuyển hướng càng lâu càng tốt, thường là ít nhất một năm, để bảo đảm Google chuyển hết tín hiệu sang URL mới. Đây là mốc tham chiếu, không phải hạn kết thúc tự động. Sau một năm vẫn phải kiểm tra nhu cầu thực tế trước khi gỡ.

Việc gỡ chuyển hướng sớm là dạng sai lầm có độ trễ: nó không gây hậu quả ngay, nên đội vận hành thường không liên hệ được sự cố về sau với quyết định tắt máy chủ cũ từ vài tháng trước.

Sổ theo dõi việc ngừng chuyển hướng

Điểm đáng nhấn ở dòng áp chót. URL cũ không chỉ tồn tại trên web. Chúng nằm trong chữ ký email, tài liệu in, mã QR trên bao bì, quảng cáo đã chạy, bài đăng của đối tác. Tắt chuyển hướng làm gãy tất cả những đường dẫn đó cùng lúc, và phần lớn không được đo bằng công cụ phân tích. Trước khi gỡ, cần một vòng rà soát với đội marketing và đội bán hàng.

Một thực hành nên giữ: ngay cả khi đã gỡ phần lớn quy tắc, giữ lại chuyển hướng cho nhóm URL có backlink mạnh và nhóm URL từng có lưu lượng cao. Chi phí duy trì một bảng chuyển hướng vài trăm dòng là không đáng kể so với việc mất các đường dẫn đó.

Ranh giới với dự án thiết kế lại website

Migration và redesign hay bị gộp làm một, nhưng phạm vi khác nhau. Redesign xử lý thay đổi giao diện, template và điều hướng — có thể không đổi URL nào. Migration xử lý cơ chế chuyển URL, tên miền hoặc nền tảng. Khi doanh nghiệp làm cả hai cùng lúc, cần hai bộ kiểm soát chồng lên nhau; phần liên quan đến giữ hiệu quả tìm kiếm trong dự án thiết kế lại được xử lý tại SEO khi redesign.

Về phân chia trách nhiệm trong dự án migration: RED làm phần kiểm kê URL, mapping, kiểm tra tương đương, ma trận parity tín hiệu, tiêu chí cổng launch và giám sát sau launch. Phần triển khai quy tắc chuyển hướng trên máy chủ, deploy và xử lý DNS do đội phát triển hoặc đối tác hạ tầng của doanh nghiệp thực hiện — [CẦN RED XÁC NHẬN] phạm vi thực thi kỹ thuật mà RED nhận trực tiếp trong hợp đồng.

Câu hỏi thường gặp

Migration có chắc chắn không tụt lưu lượng không?

Không có bảo đảm nào như vậy. Tài liệu của Google về site move nêu rõ nên dự kiến biến động tạm thời về xếp hạng và lưu lượng trong khi Google xử lý việc chuyển đổi. Chuẩn bị tốt làm giảm mức độ và thời gian biến động, không loại bỏ nó. Bất kỳ bên nào cam kết migration không tụt lưu lượng đều đang hứa điều họ không kiểm soát được.

Chuyển hướng 301 có làm mất PageRank không?

Theo tài liệu của Google, chuyển hướng vĩnh viễn là tín hiệu mạnh cho biết URL đích nên là URL xuất hiện trong kết quả tìm kiếm, và đây là cơ chế được dùng cho site move. Vấn đề không nằm ở bản thân việc chuyển hướng mà ở chất lượng mapping: chuyển hướng nhiều URL không liên quan về một đích chung có thể bị xử lý như trang không tồn tại.

Có nên chuyển hướng toàn bộ URL cũ về trang chủ không?

Không. Đây chính là kiểu chuyển hướng mà tài liệu Google cảnh báo là có thể bị coi như trang không tồn tại. Với các URL không có trang tương đương, ba lựa chọn hợp lệ là: tạo trang tương đương ở bản mới, chuyển hướng về trang gần nhất trong cùng nhánh nội dung, hoặc trả 410 nếu nội dung đã ngừng vĩnh viễn.

Cần giữ chuyển hướng trong bao lâu?

Google khuyến nghị giữ chuyển hướng càng lâu càng tốt, thường ít nhất một năm. Sau mốc đó vẫn nên kiểm tra trước khi gỡ: còn liên kết ngoài trỏ vào URL cũ không, Googlebot còn gọi URL cũ không, còn lưu lượng người dùng không, và URL cũ có nằm trong tài liệu ngoài web không.

Đổi hosting có giống đổi tên miền không?

Không, và Google có tài liệu riêng cho hai trường hợp. Chuyển hosting mà URL giữ nguyên có quy trình riêng, tập trung vào chuẩn bị, chuyển DNS, theo dõi và tắt hạ tầng cũ. Site move có thay đổi URL cần thêm mapping, chuyển hướng và các bước thông báo trong Search Console. Dùng nhầm quy trình dẫn đến vừa làm thừa vừa bỏ sót.

Sau launch cần theo dõi những gì?

Tối thiểu: trạng thái chuyển hướng của nhóm URL ưu tiên cao, mã trạng thái trên các template chính, canonical mà Google chọn cho URL mới, báo cáo trang trong Search Console, và các chỉ số hiệu quả chia theo nhóm — trang đích hàng đầu, thư mục, quốc gia, nhóm truy vấn, và một nhóm đối chứng không nằm trong phạm vi migration để phân biệt biến động do migration với biến động do nguyên nhân khác.

Gửi kế hoạch migration để RED đánh giá phạm vi

Nếu doanh nghiệp đang chuẩn bị đổi tên miền, đổi nền tảng, tái cấu trúc URL hoặc chuyển hạ tầng, hãy gửi cho RED:

• Tên miền hiện tại và tên miền hoặc cấu trúc dự kiến
• Loại thay đổi và lịch phát hành dự kiến
• Quyền truy cập Search Console và công cụ phân tích, nếu chia sẻ được
• Bản kiểm kê URL hiện có, nếu đã lập
• Nền tảng cũ và nền tảng mới, cùng thông tin về đội phát triển phụ trách

RED sẽ phân loại loại migration, xác định phạm vi công việc mapping và kiểm soát cần thiết, rồi phản hồi bằng bản mô tả phạm vi phù hợp với quy mô website và lịch phát hành. RED không cam kết migration không tụt lưu lượng, không cam kết giữ nguyên thứ hạng và không đưa ra mốc thời gian Google xử lý xong việc chuyển đổi.