Cách di chuyển tên miền mà không làm tụt hạng tìm kiếm

Đổi tên miền là một trong số ít dự án SEO mà một lỗi kỹ thuật tưởng nhỏ có thể trở nên rất dễ thấy chỉ trong thời gian ngắn. Một chuyển hướng bị thiếu, một đường thu thập dữ liệu bị chặn, hoặc một canonical bị bỏ quên có thể biến một lần đổi thương hiệu đơn giản thành nhiều tuần biến động thứ hạng.

Một số dao động là bình thường. Công cụ tìm kiếm cần thời gian để thu thập các URL cũ, phát hiện chuyển hướng, xử lý tín hiệu và đưa tên miền mới ổn định trong chỉ mục. Mục tiêu không phải là tránh mọi lần sụt giảm. Mục tiêu là làm cho việc di chuyển trở nên nhàm chán: một URL cũ trỏ đến một URL mới tương đương, máy chủ phản hồi rõ ràng, và không có nội dung quan trọng nào biến mất.

Bắt đầu bằng một bản kiểm kê, không phải một quy tắc chuyển hướng

Lỗi di chuyển phổ biến nhất là xem đây như một tác vụ cấu hình máy chủ. Không phải vậy. Đây là một tác vụ kiến trúc thông tin, chỉ tình cờ kết thúc bằng cấu hình máy chủ.

Trước khi đụng đến DNS, hãy xây dựng danh sách các URL quan trọng:

• Các URL nhận lưu lượng truy cập tự nhiên
• Các URL có backlink bên ngoài
• Các URL tạo chuyển đổi, tạo lead hoặc hỗ trợ chiến dịch
• Các URL canonical hiện có trong XML sitemap của bạn
• PDF, hình ảnh và tệp tải xuống được liên kết từ bên ngoài
• Các URL cũ có giá trị cao có thể không xuất hiện trong điều hướng hiện tại

Với mỗi URL cũ, hãy gán một đích đến trên tên miền mới. Trong hầu hết trường hợp, đích đến đó nên là cùng một trang với cùng ý định. Nếu /pricing trở thành https://newdomain.com/pricing, việc đó rất đơn giản. Nếu ba trang sản phẩm cũ được gộp thành một hướng dẫn mới, hãy ghi lại quyết định đó một cách có chủ đích.

Tránh kiểu làm biếng: chuyển hướng mọi thứ về trang chủ mới. Cách này tiện, nhưng làm mất đi mức độ liên quan. Cả công cụ tìm kiếm lẫn người dùng đều kỳ vọng đích đến đáp ứng cùng một nhu cầu như URL ban đầu.

Giữ cấu trúc URL khi có thể

Di chuyển tên miền sẽ dễ hơn khi các đường dẫn vẫn ổn định. Chuyển từ oldsite.com/blog/example sang newsite.com/blog/example sạch sẽ hơn nhiều so với việc thay đổi tên miền, CMS, slug, cấu trúc thư mục và nội dung cùng một lúc.

Đôi khi một lần thiết kế lại hoặc di chuyển CMS khiến việc đổi URL là không thể tránh khỏi. Nếu vậy, hãy tách riêng các quyết định:

1. Điều gì thay đổi vì tên miền đang thay đổi?
2. Điều gì thay đổi vì cấu trúc website đang thay đổi?
3. Điều gì đang bị xóa, gộp hoặc viết lại?

Bạn đưa vào càng nhiều biến số, việc chẩn đoán vấn đề về sau càng khó. Nếu việc di chuyển quan trọng và website hiện tại đang hoạt động tốt, hãy cân nhắc chuyển tên miền trước và thiết kế lại sau.

Dùng chuyển hướng vĩnh viễn, một bước nhảy

Với một lần di chuyển tên miền thực sự, hãy dùng chuyển hướng phía máy chủ 301 hoặc 308 từ các URL cũ đến URL mới tương đương. Chuyển hướng tạm thời dành cho các tình huống tạm thời. Chuyển hướng JavaScript, meta refresh và soft redirect là các tín hiệu yếu hơn và dễ hỏng hơn.

Mục tiêu chuyển hướng của bạn rất đơn giản:

• Mọi URL cũ quan trọng đều trả về một chuyển hướng vĩnh viễn.
• Mỗi chuyển hướng đi thẳng đến đích cuối cùng.
• HTTP chuyển hướng sang HTTPS một cách sạch sẽ.
• Các biến thể www và không www được xử lý nhất quán.
• Chuyển hướng không phụ thuộc vào hành vi query-string mong manh trừ khi cần thiết.

Một chuỗi chuyển hướng không tốt trông như sau:

http://oldsite.com/page → https://oldsite.com/page → https://www.oldsite.com/page → https://newsite.com/page → https://www.newsite.com/page

Chuỗi đó cuối cùng có thể đến đúng trang, nhưng chậm, khó thu thập dữ liệu hơn và dễ che giấu lỗi hơn. Hãy nhắm đến một bước nhảy từ mọi biến thể cũ đến URL mới cuối cùng.

Khi xác thực hành vi, hãy kiểm tra phản hồi HTTP thực tế thay vì tin vào những gì trình duyệt hiển thị. Hướng dẫn của chúng tôi về debug redirect và HTTP header trong production rất hữu ích ở đây vì trình duyệt quá lịch sự: chúng đi theo chuỗi và che đi những phần lộn xộn.

Chuẩn bị DNS và chứng chỉ trước khi ra mắt

DNS không trực tiếp chuyển thứ hạng, nhưng DNS cấu hình kém có thể khiến một lần di chuyển trông như bị hỏng. Hãy giảm giá trị TTL trước khung thời gian ra mắt để các thay đổi lan truyền dễ dự đoán hơn. Xác nhận rằng tên miền mới có bản ghi chính xác cho lưu lượng web, email và mọi subdomain cần thiết.

Bạn cũng cần chứng chỉ TLS hợp lệ cho cả hai tên miền. Điều này rất dễ bị bỏ sót. Tên miền cũ vẫn cần phục vụ chuyển hướng HTTPS sau khi di chuyển. Nếu chứng chỉ của nó hết hạn, người dùng và crawler có thể gặp cảnh báo trình duyệt trước khi họ đến được website mới.

Nếu việc chuyển đổi ảnh hưởng đến email, đừng xem đó là chuyện phụ. Thay đổi tên miền thường làm hỏng SPF, DKIM, DMARC, bản ghi MX, liên kết theo dõi và email giao dịch. Để ôn lại các bản ghi quan trọng, hãy xem hướng dẫn thân thiện với developer của chúng tôi về MX, SPF, DKIM và DMARC.

Kiểm tra canonical, liên kết nội bộ và sitemap

Sau khi ra mắt, tên miền mới nên hoạt động như thể nó luôn là nơi canonical của nội dung.

Điều đó có nghĩa là:

• Thẻ canonical trỏ đến các URL mới, không phải tên miền cũ.
• Liên kết nội bộ dùng tên miền mới hoặc đường dẫn root-relative.
• XML sitemap chỉ chứa các URL mới cuối cùng, có thể lập chỉ mục.
• Chú thích hreflang, nếu dùng, tham chiếu các URL mới.
• Open Graph, structured data và liên kết thay thế được cập nhật.
• Robots.txt không chặn các khu vực quan trọng.

Đừng xuất bản một sitemap đầy URL cũ rồi mong chuyển hướng dọn dẹp nó. Sitemap nên là danh sách các URL bạn muốn được lập chỉ mục. Sau một lần di chuyển, điều đó nghĩa là các URL cuối cùng trên tên miền mới.

Cũng hãy để ý các mâu thuẫn canonical. Một trang chuyển hướng từ cũ sang mới nhưng có canonical trỏ ngược về tên miền cũ sẽ gửi tín hiệu lẫn lộn. Công cụ tìm kiếm thường có thể xử lý một số điểm không nhất quán, nhưng bạn không nên bắt họ làm vậy.

Đừng thay đổi mọi thứ vào ngày ra mắt

Một lần di chuyển tự nó đã là một sự kiện đủ lớn. Nếu có thể, hãy tránh kết hợp nó với việc cắt giảm nội dung lớn, viết lại template, thay đổi điều hướng, thay đổi cách render JavaScript hoặc một hồ sơ hiệu năng mới.

Đây không phải mê tín. Đây là kỷ luật debug. Nếu thứ hạng giảm sau khi ra mắt, bạn cần biết nguyên nhân là ánh xạ chuyển hướng, quyền truy cập thu thập dữ liệu, nội dung đã thay đổi, render chậm hơn, thiếu structured data hay điều gì khác.

Hãy giữ lần ra mắt ban đầu gần với website cũ nhất có thể trong thực tế. Khi tên miền mới đã ổn định, hãy thực hiện các thay đổi biên tập và thiết kế lớn hơn theo từng đợt nhỏ.

Cho công cụ tìm kiếm biết điều gì đã thay đổi

Trong Google Search Console, hãy xác minh cả tên miền cũ và mới. Sau đó dùng công cụ Change of Address khi việc chuyển đổi là thay đổi ở cấp tên miền và nội dung đang chuyển sang một tên miền mới. Gửi sitemap mới sau khi ra mắt.

Việc này không thay thế chuyển hướng. Nó hỗ trợ chuyển hướng. Công cụ tìm kiếm vẫn cần các chuyển hướng bền vững, có thể thu thập dữ liệu để hiểu ánh xạ ở cấp URL.

Với Bing và các công cụ tìm kiếm khác, hãy dùng công cụ webmaster của họ nếu có. Đồng thời cập nhật những nơi bạn kiểm soát: hồ sơ mạng xã hội, danh bạ doanh nghiệp, đích đến quảng cáo, chữ ký email, tài liệu, liên kết đối tác và tham chiếu canonical trong nội dung được phân phối lại.

Không phải mọi liên kết bên ngoài đều sẽ được cập nhật, và điều đó không sao. Nhưng những liên kết quan trọng nhất thì nên được cập nhật. Nếu một đối tác lớn, marketplace ứng dụng, cổng tài liệu hoặc trang báo chí liên kết đến tên miền cũ, hãy yêu cầu cập nhật.

Giám sát đúng thứ sau khi ra mắt

Vài ngày đầu sau khi di chuyển nên là thời gian giám sát chủ động, không phải ăn mừng.

Hãy kiểm tra:

• Log máy chủ cho hoạt động thu thập dữ liệu trên tên miền cũ và mới
• 404 và lỗi 5xx ngoài dự kiến
• Chuỗi và vòng lặp chuyển hướng
• Trạng thái lập chỉ mục trong Search Console
• Việc phát hiện và xử lý sitemap
• Trang đích từ tìm kiếm tự nhiên và mẫu truy vấn
• Luồng chuyển đổi phụ thuộc vào URL cũ
• Bộ lọc analytics và loại trừ referral

Hãy kỳ vọng nhiễu trong báo cáo. Một số công cụ analytics xem tên miền mới như một property mới nếu không được cấu hình đúng. Một số dashboard so sánh lưu lượng tên miền cũ với lưu lượng tên miền mới và khiến lần di chuyển trông tệ hơn thực tế.

Khả năng hiển thị tìm kiếm có thể dao động trong vài tuần. Điều bạn không muốn là một mẫu trong đó các URL cũ có giá trị cao được thu thập lặp đi lặp lại nhưng không được chuyển hướng đúng, hoặc các trang mới được phát hiện nhưng bị đánh dấu là bản trùng lặp của tên miền cũ.

Cũng không nên bỏ qua hiệu năng. Nếu tên miền mới ra mắt với template nặng hơn, caching bị hỏng hoặc asset chưa tối ưu, người dùng có thể cảm nhận việc di chuyển như một sự chậm lại. Nếu bạn dùng Lighthouse như một phần trong các bước kiểm tra, hãy đọc nó với ưu tiên rõ ràng; bài viết của chúng tôi về cách đọc báo cáo Lighthouse mà không hoảng loạn giải thích cách tách vấn đề có ý nghĩa khỏi nhiễu.

Giữ tên miền cũ trong thời gian dài

Đừng để tên miền cũ hết hạn sau khi việc di chuyển “hoạt động.” Hãy tiếp tục đăng ký, giữ chứng chỉ hợp lệ và duy trì chuyển hướng càng lâu càng tốt. Trên thực tế, điều đó thường có nghĩa là nhiều năm.

Liên kết cũ vẫn tồn tại trong bài blog, bookmark, tài liệu, PDF, email và bài đăng mạng xã hội. Chuyển hướng là cây cầu giữa dấu chân lịch sử đó và tên miền mới. Tắt chúng quá sớm sẽ làm đứt đường đi của người dùng và lãng phí các tín hiệu đã tích lũy.

Cũng hãy giữ một bản sao của bản đồ chuyển hướng và ghi chú ra mắt. Sáu tháng sau, khi ai đó hỏi vì sao một URL legacy hoạt động theo một cách nhất định, bạn sẽ vui vì đã ghi lại nó.

<!-- tool-cta:start -->

💡 Hãy thử cách này: Sau khi chuyển đổi, hãy truy vết các URL cũ của bạn qua Redirect Checker để xác nhận rằng từng URL đều phân giải qua một bước nhảy 301 duy nhất đến đúng trang mới.

<!-- tool-cta:end -->

Một checklist di chuyển hợp lý

Trước khi ra mắt:

• Xác minh cả hai tên miền trong Search Console.
• Crawl website hiện tại và xuất các URL quan trọng.
• Xây dựng bản đồ chuyển hướng một-một.
• Giảm DNS TTL.
• Chuẩn bị chứng chỉ TLS cho tên miền cũ và mới.
• Cập nhật canonical, liên kết nội bộ, hreflang, structured data và sitemap.
• Kiểm thử chuyển hướng trong staging hoặc một môi trường được kiểm soát.

Vào ngày ra mắt:

• Triển khai chuyển hướng.
• Xác nhận hành vi HTTP sang HTTPS.
• Kiểm thử các mẫu URL quan trọng từ mọi loại template.
• Gửi sitemap mới.
• Dùng công cụ Change of Address khi phù hợp.
• Theo dõi lỗi máy chủ, vòng lặp chuyển hướng và tài nguyên bị chặn.

Sau khi ra mắt:

• Giám sát lỗi thu thập dữ liệu và báo cáo lập chỉ mục.
• Cập nhật các liên kết bên ngoài quan trọng khi có thể.
• So sánh lưu lượng theo ý định trang đích, không chỉ theo tổng số ở cấp tên miền.
• Duy trì chuyển hướng vô thời hạn.
• Hoãn các thử nghiệm thiết kế lại hoặc nội dung không liên quan cho đến khi việc di chuyển ổn định.

Di chuyển tên miền không phải là không có rủi ro, nhưng có thể quản lý được. Thứ hạng thường bị ảnh hưởng khi việc di chuyển gửi tín hiệu không rõ ràng: thiếu chuyển hướng, nội dung đã thay đổi, canonical mâu thuẫn, crawler bị chặn hoặc tên miền cũ bị bỏ quên. Hãy cung cấp cho công cụ tìm kiếm và người dùng một bản đồ rõ ràng, và việc chuyển đổi sẽ ít kịch tính hơn nhiều.