Phân tích thay đổi liên kết khi di chuyển trang web

Xây dựng bản đồ chuyển hướng trước khi ra mắt

Bản đồ chuyển hướng là phần của việc di chuyển mà mọi người thường đánh giá thấp. Điểm đến rất quan trọng. Trước khi phân tích dữ liệu liên kết sau khi di chuyển, các URL cũ cần có điểm đến rõ ràng, vì đó là các địa chỉ mà các liên kết hiện tại đang trỏ tới.

Chuyển hướng từng trang một tốt hơn là chuyển hướng hàng loạt về trang chủ

Việc gửi hàng trăm URL cũ không liên quan về trang chủ cung cấp rất ít thông tin cho công cụ tìm kiếm và người dùng. Sự liên quan là tiêu chí kiểm tra. Hãy ánh xạ từng URL cũ có giá trị cao đến trang mới gần nhất tương ứng, và chuyển các URL còn lại đến một danh mục vẫn phù hợp với chủ đề của chúng.

Xuất các URL cũ kèm theo mã trạng thái của chúng trước tiên. Giữ tệp đó an toàn. Tệp đó chính là danh sách kiểm tra, và nó cho biết những trang nào đã tạo ra các liên kết.

Nếu một trang không có bản tương đương gần, hãy ghi rõ trong bản đồ và chuyển nó đến danh mục gần nhất, kèm theo ghi chú. Các ô trống ẩn đi các quyết định. Một ô trống trong bảng là một quyết định chưa được đưa ra.

Giản lược các chuỗi chuyển hướng trước khi ra mắt

Một chuyển hướng phải đi qua hai quy tắc trước khi đến trang mới sẽ làm tăng độ trễ và rủi ro. Các chuỗi chuyển hướng dễ hình thành khi một lần di chuyển thứ hai nằm chồng lên lần đầu tiên, vì vậy hãy xem xét lại bản đồ trước mỗi lần chuyển đổi thay vì giả định rằng nó vẫn sạch sẽ. Mỗi bước nhảy phụ đều có chi phí. Hãy yêu cầu truy cập từng URL cũ một lần sau khi chuyển đổi và xác nhận rằng nó trả về kết quả với chỉ một bước nhảy.

Sửa sớm. Sửa các chuỗi trong chính bản đồ chuyển hướng, không phải sửa từng cái một sau khi ra mắt, để danh sách luôn ngắn gọn.

Giữ lại các đường dẫn vẫn hoạt động

Thay đổi cấu trúc URL trong quá trình thiết kế lại là nguồn gốc của sự mất mát có thể tránh được. Mọi thay đổi về đường dẫn đều là thay đổi đối với mọi liên kết trỏ tới nó, và những liên kết đó nằm ngoài tầm kiểm soát của bạn. Hãy giữ những gì đang hoạt động. Nếu một đường dẫn vẫn hoạt động, hãy giữ nguyên nó và chỉ thay đổi những gì bắt buộc phải thay đổi do việc di chuyển.

Ít chuyển hướng hơn, ít lỗi hơn. Mọi đường dẫn bạn giữ lại là một liên kết không bao giờ cần chuyển hướng.

Một đường dẫn được giữ nguyên có nghĩa là các hàng anchor text cũ vẫn trỏ đến một nơi hữu ích, giảm bớt công việc phải xây dựng lại trong bảng tính. Ít công việc xây dựng lại hơn về sau.

Những gì sẽ xảy ra sau khi di chuyển

Các chuyển hướng thực hiện phần việc nặng nề, và một chuyển hướng 301 từ URL cũ sang URL mới cho phép các liên kết cũ tiếp tục hoạt động. Việc duy trì một chuyển hướng cho mỗi URL cũ, không có chuỗi chuyển hướng ở giữa, là cách đơn giản nhất để giữ nguyên giá trị của từng liên kết. Các chuỗi chuyển hướng gồm ba hoặc bốn bước làm chậm trình thu thập chỉ mục và nên được giản lược.

Anchor text không thay đổi khi URL di chuyển, vì văn bản này nằm trên trang liên kết. Điều thay đổi là số lượng điểm đến: bảng các trang hàng đầu của bạn sẽ hiển thị tên miền cũ giảm dần và tên miền mới tăng dần qua vài lần cập nhật hàng tháng. Các điểm đến thay đổi chậm.

Một bất ngờ phổ biến là xóa nền tảng cũ quá sớm. Đừng làm vậy. Các nhà cung cấp như Squarespace, Wix và tương tự thường lưu trữ các quy tắc chuyển hướng, vì vậy việc hủy gói dịch vụ có thể xóa chúng, và các liên kết sau đó sẽ trỏ đến một điểm chết cho đến khi bạn xây dựng lại các quy tắc đó ở nơi khác.

Hreflang và thẻ canonical cũng cần được xem xét. Sự không khớp là phổ biến. Ví dụ, sau khi di chuyển từ CRA sang Next.js, các trang web thường kết thúc với các thẻ canonical không khớp với bộ hreflang của chúng, và các liên kết bị chia cắt giữa hai phiên bản của một trang.

Nếu các con số không khớp sau khi di chuyển, hãy kiểm tra bảng khắc phục sự cố trước khi giả định rằng các liên kết đã bị mất. Chỉ một lần cập nhật hàng tháng đã có thể giải thích nhiều khoảng trống. Các khoảng trống thường là do thời gian.

Hãy dự kiến lần so sánh sạch đầu tiên vào khoảng hai lần cập nhật hàng tháng sau khi ra mắt, và ghi lại ngày của mỗi lần cập nhật trong bảng tính của bạn để một tháng dữ liệu phẳng không bị nhầm lẫn là bị kẹt. Hãy kiên nhẫn. Ahrefs hoặc Semrush có thể lấp đầy khoảng trống này bằng các lần thu thập chỉ mục mới hơn nếu bạn cần đọc tạm thời.

Theo dõi những gì di chuyển mà không có thông báo ra mắt

Ngày ra mắt có một danh sách kiểm tra, nhưng nhiều vấn đề xuất hiện sau đó một cách âm thầm. Chúng xuất hiện trong các hàng dữ liệu và trong chỉ mục, lâu sau khi nhóm đã chuyển sang công việc khác. Chúng rất dễ bị bỏ qua.

Noindex đi kèm với bản dựng staging

Một bản sao staging được giữ ngoài công cụ tìm kiếm có thể mang theo các cài đặt của nó vào trang web chính. Hãy kiểm tra các thẻ meta robots và bất kỳ tiêu đề noindex nào trong lần thu thập chỉ mục đầu tiên, và lấy mẫu các trang từ mỗi danh mục thay vì chỉ trang chủ. Lấy mẫu mọi danh mục.

Các mẫu (templates) thường bị lỗi trước tiên. Nếu một toàn bộ danh mục bị mất khỏi chỉ mục sau khi ra mắt, hãy xem xét mẫu của nó trước khi xem xét nội dung của nó.

Ảnh chụp màn hình cũng rất hữu ích. Hãy giữ một bản sao của cài đặt robots từ bản dựng staging. Khi một thứ gì đó bị mất khỏi chỉ mục, việc so sánh hai bộ cài đặt chỉ mất vài phút thay vì cả buổi chiều.

Các liên kết fragment (neo) bị thu thập chỉ mục

Các liên kết nhảy (jump links) như neo mục lục có thể xuất hiện dưới dạng các URL riêng biệt trong kết quả tìm kiếm. Công cụ tìm kiếm thường gộp các liên kết này vào trang chính, nhưng khi chúng không được gộp, cùng một nội dung có thể xuất hiện dưới nhiều địa chỉ khác nhau. Chúng phân tán các tín hiệu khỏi trang chính, và chúng có thể trông giống như các trang trùng lặp trong báo cáo khả năng hiển thị. Các URL chứa hash nhân lên một cách âm thầm.

Một phiên bản, một địa chỉ. Một thẻ canonical trỏ đến một địa chỉ trong khi sitemap liệt kê một địa chỉ khác sẽ gửi đi các tín hiệu hỗn loạn, và báo cáo sẽ hiển thị sự không khớp. Hãy đặt một phiên bản canonical cho mỗi trang và xác nhận rằng sitemap liệt kê cùng phiên bản đó.

Kiểm tra báo cáo khả năng hiển thị sau khi ra mắt để tìm các URL có chứa hash, vì đó là những URL nhân lên một cách âm thầm. Hashes là thủ phạm.

Một tên miền phụ trở thành tên miền chính

Việc di chuyển trang web từ tên miền phụ staging sang tên miền chính mang theo các bản sao trùng lặp, vì cả hai phiên bản đều có thể vẫn truy cập được trong một thời gian. Hãy quyết định xem tên miền nào là canonical trước khi ra mắt. Chọn tên miền sớm.

Một tên miền, ở mọi nơi. Khi một tên miền thay đổi ở một nơi nhưng không ở nơi khác, phiên bản cũ hơn có thể tiếp tục thu thập liên kết trong nhiều tháng mà không ai nhận ra. Sau đó, hãy giữ sitemap, các thẻ canonical và bất kỳ bộ hreflang nào trỏ về một tên miền đó.

Các liên kết do-follow dường như biến mất

Sau khi thiết kế lại, các hàng do-follow trong công cụ có thể giảm mạnh, và phỏng đoán đầu tiên là các liên kết đã bị mất. Hãy so sánh các trang hàng đầu cũ với các trang mới trước khi chấp nhận phỏng đoán đó, sau đó kiểm tra xem mỗi địa chỉ cũ hiện có chuyển hướng đúng cách hay không. Kiểm tra trước khi hoảng sợ.

Sửa cái đó trước tiên. Một liên kết vẫn tồn tại trên trang liên kết nhưng trỏ đến một địa chỉ chết là trường hợp cần sửa đầu tiên.

Đặt ngày sớm. Hãy giao cho nhóm một ngày cố định để so sánh, để không ai chạy lại việc trích xuất dữ liệu mỗi ngày và đọc nhiễu như là tin tức.

Làm việc với nhà phát triển trong quá trình di chuyển

Hầu hết công việc chuyển hướng thuộc về nhà phát triển, và việc giám sát thuộc về người đọc bảng tính. Viết sự phân chia công việc dưới dạng một bảng ngắn, với một tên trong mỗi ô, thường là đủ để ngăn hai người từ giả định cùng một nhiệm vụ. Hãy phân chia các vai trò này trên giấy trước khi ra mắt, để không ai giả định rằng người kia đang giám sát. Các vai trò cần có tên cụ thể.

Cung cấp cho nhà phát triển một bản đồ, không phải một danh sách nhiệm vụ

Một danh sách nhiệm vụ cho nhà phát triển biết phải làm gì, trong khi một bản đồ cho biết địa chỉ cũ nào đi đâu. Hãy gửi bảng ánh xạ từng trang một kèm theo các mã trạng thái và lý do cho mỗi hàng, để các trường hợp biên được đưa ra quyết định thay vì phỏng đoán. Quyết định tốt hơn phỏng đoán.

Kế hoạch kiểm tra đến trước. Hãy yêu cầu một kế hoạch kiểm tra ngắn bắt đầu bằng các địa chỉ cũ từ tệp trang hàng đầu.

Xác định ai sẽ đọc tệp hàng tháng

Lần so sánh sạch đầu tiên đến vào khoảng hai lần cập nhật sau khi ra mắt, và tệp đó sẽ cần một người đọc. Lần đọc đầu tiên sau khi ra mắt thường nhiều nhiễu, và một người đọc hiểu điều đó sẽ tránh phản ứng với một tháng bất thường đơn lẻ. Hãy chỉ định người đó, ngày họ mở tệp, và bảng tính nơi kết quả được ghi lại. Ai đó phải chịu trách nhiệm về nó.

Ngày tháng giải quyết vấn đề. Việc ghi ngày cập nhật bên cạnh mỗi tệp biến mối lo ngại về một chỉ mục bị kẹt thành một sự thật đơn giản về lịch trình. Một tháng dữ liệu phẳng dễ bị đọc nhầm là bị kẹt trừ khi ai đó ghi lại ngày cập nhật.

Hãy yêu cầu người đó ghi một dòng cho mỗi lần cập nhật, ngay cả khi không có gì thay đổi, để tệp duy trì một hồ sơ liên tục. Một dòng mỗi lần.

Kế hoạch hoàn tác (rollback) trước khi ra mắt

Nếu tên miền mới làm hỏng một đường dẫn quan trọng, nhóm cần một cách quay lại đã được kiểm tra trước. Hãy ghi các bước lại, bao gồm ai có thể bật/tắt công tắc và cách các chuyển hướng hoạt động trong khi nó được hoàn tác. Hãy diễn tập nó trước khi ra mắt.

Hãy ghi lại kế hoạch hoàn tác. Một kế hoạch hoàn tác chỉ tồn tại trong đầu một người thì không phải là một kế hoạch.