Di chuyển trang web là một trong những khía cạnh đầy thách thức nhất của SEO.
Cho dù bạn có bao nhiêu kinh nghiệm về SEO kỹ thuật, kế hoạch của bạn chi tiết đến đâu hay danh sách kiểm tra của bạn có kỹ lưỡng đến đâu thì vẫn có thể phát sinh các vấn đề bất ngờ.
Đó là lý do tại sao việc theo dõi sau khi di chuyển cũng quan trọng như chính quá trình di chuyển – đặc biệt là trong tháng đầu tiên khi các vấn đề tiềm ẩn có nhiều khả năng xuất hiện nhất.
Bài viết này giải quyết một số lỗi sau khi ra mắt đáng ngạc nhiên nhất mà tôi từng gặp phải, cùng với các mẹo thực tế về cách xác định và giải quyết chúng trước khi chúng gây ra thiệt hại nghiêm trọng.
Vấn đề này khiến tôi phát điên. Đây là cơn ác mộng đối với thử nghiệm SEO vì nó làm sai lệch mọi công cụ và báo cáo mà chúng ta dựa vào.
Khi bạn không thể tin tưởng dữ liệu, bạn không thể biết được lỗi thực sự là gì hoặc nó ảnh hưởng đến hiệu suất như thế nào.
Trong giai đoạn sau khi di chuyển để cập nhật thư viện JavaScript, chúng tôi nhận thấy lỗi 404 ngẫu nhiên trong các công cụ SEO và Google Search Console.
Phần kỳ lạ là gì?
Các trang bị ảnh hưởng không nhất quán và mỗi lần chúng tôi kiểm tra thủ công, chúng đều tải tốt với trạng thái 200.
Kết quả là, tất cả các báo cáo khác đều không đáng tin cậy, khiến việc phân tích đúng cách gần như không thể.
Những lỗi 404 ngẫu nhiên này thường bắt nguồn từ các sự cố về phía máy chủ như giới hạn tốc độ, trong đó máy chủ từ chối quyền truy cập của bot sau quá nhiều yêu cầu.
Các nguyên nhân tiềm ẩn khác bao gồm:
Và đây là bài học lớn nhất mà tôi học được: Nếu không có quyền truy cập vào nhật ký máy chủ, bạn sẽ phải chiến đấu một cách mù quáng.
Đảm bảo nhóm SEO của bạn có quyền truy cập vào các công cụ nhật ký máy chủ cần thiết và ít nhất là hiểu được những điều cơ bản về cách chúng hoạt động.
Theo dõi nhật ký hoạt động của bot có thể giúp bạn chứng minh sự cố với các nhà phát triển. Nếu không có chúng, bạn có nguy cơ bị mắc kẹt trong những cuộc tranh luận bất tận về độ chính xác của các công cụ SEO.
Tìm hiểu sâu hơn: Danh sách kiểm tra di chuyển trang web: 11 bước để thành công
Thoạt nhìn, lỗi này trông giống như lỗi 404 ngẫu nhiên, nhưng nguyên nhân thường hoàn toàn khác và cũng khó chẩn đoán như vậy.
Ngay cả các công cụ SEO như Lumar và Screaming Frog cũng có thể vô tình kích hoạt lỗi 500 này trong khi thu thập dữ liệu.
Nhiều năm trước, một trong những trang web tôi làm việc có một quy tắc nghiêm ngặt: không thu thập dữ liệu vào cuối tuần và không vượt quá ba URL mỗi giây.
Mỗi khi chúng tôi tăng giới hạn thu thập dữ liệu, máy chủ cơ sở dữ liệu sẽ gặp sự cố, làm chậm toàn bộ trang web - hoặc tệ hơn là làm sập trang web.
Những lỗi này thường là kết quả của các truy vấn cơ sở dữ liệu phức tạp làm quá tải máy chủ hoặc cấu hình không đúng cách bộ nhớ đệm.
Nếu không có bộ nhớ đệm phù hợp, mỗi yêu cầu sẽ được xử lý riêng lẻ, làm tăng thêm căng thẳng và dẫn đến thời gian tải chậm hoặc sự cố không liên tục.
Và một lần nữa, giải pháp bắt đầu bằng quyền truy cập nhật ký máy chủ. Nếu không có nó, bạn chỉ có thể đoán mò.
Đây là một trong những khoảnh khắc khiến tôi cảm thấy mình giống như Sherlock Holmes kỹ thuật số.
Việc di chuyển đã hoàn tất trước khi tôi gia nhập công ty và tôi lần đầu tiên nhận thấy sự cố trong quá trình kiểm tra kỹ thuật ban đầu.
Manh mối đầu tiên?
Một sự sụt giảm bí ẩn về thứ hạng và lưu lượng truy cập ngay sau khi di chuyển.
Cũng có một bản cập nhật của Google vào cùng thời điểm đó, vì vậy tôi không thể liên kết ngay sự suy giảm này với quá trình di chuyển.
Để làm mọi thứ phức tạp hơn nữa, đây không phải là quá trình di chuyển hoàn toàn, chỉ là cải tiến thiết kế.
Nhìn bề ngoài, mọi thứ có vẻ ổn. Các trang được tải đúng cách và các kiểu và JavaScript hoạt động hoàn hảo đối với người dùng.
Tuy nhiên, trong công cụ kiểm tra của Google Search Console, các trang giống nhau thường bị hỏng và không có kiểu.
Vấn đề này không nhất quán, khiến việc sao chép trước nhóm phát triển gần như không thể.
Là một thành viên mới trong nhóm vẫn đang xây dựng lòng tin, việc thuyết phục họ rằng có một vấn đề sâu xa hơn không phải là điều dễ dàng.
Nhìn lại, lỗi của tôi là không kiểm tra bảng điều khiển trình duyệt sớm hơn.
Ba tháng sau, một thông báo bảng điều khiển trình duyệt duy nhất cuối cùng đã tiết lộ nguyên nhân gốc rễ: một tập lệnh đang tải không theo thứ tự.
Do lưu trữ đệm, đôi khi Googlebot thấy trang web đúng và đôi khi thì không, giải thích cho hành vi thất thường này.
Đó là lời nhắc nhở khó khăn rằng các chi tiết kỹ thuật nhỏ - như trình tự tải tài nguyên - và việc bỏ qua một bước chẩn đoán rõ ràng có thể ảnh hưởng đáng kể đến hiệu suất SEO.
Lời khuyên chính của tôi: Kiểm tra trang web của bạn trên các trình duyệt khác nhau và xem xét kỹ lưỡng các thông báo lỗi và cảnh báo trong bảng điều khiển.
Nếu bạn không quen với thuật ngữ dành cho nhà phát triển, hãy tham khảo ý kiến của chuyên gia độc lập hoặc thậm chí là nhiều công cụ AI để được giải thích.
Trong khi điều tra những lỗi 404 ngẫu nhiên gây khó chịu đó, tôi tình cờ gặp phải một vấn đề khác.
Trong khi xem xét báo cáo của Google Search Console về các trang được phát hiện nhưng không được lập chỉ mục, tôi nhận thấy một mô hình bất thường - một số URL không tồn tại xuất hiện trong một số phần nhất định, được đánh dấu là nội dung trùng lặp.
Thay vì trả về lỗi 404 như mong đợi, các URL này được giải quyết như các trang bình thường với mã trạng thái 200.
Loại lỗi này gây ra hai rủi ro chính:
Đừng chần chừ để tình cờ phát hiện ra nó. Hãy đảm bảo:
Quản lý thẻ hreflang trên một trang web đa ngôn ngữ là một thách thức và ngay cả những lỗi nhỏ cũng có thể gây ra sự cố lớn.
Trên một trang web mà tôi đã làm việc, chúng tôi thường tạo các trang bằng tiếng Anh trước rồi mới bản địa hóa chúng.
Tuy nhiên, trong một số trường hợp, chỉ có phiên bản bản địa tồn tại và hreflang
Thẻ hreflang không chính xác gây nhầm lẫn cho các công cụ tìm kiếm, vì chúng dựa vào chúng để xác định phiên bản ngôn ngữ hoặc khu vực chính xác của một trang.
Khi các thẻ này sai, các công cụ tìm kiếm có thể gặp khó khăn khi hiểu cấu trúc của trang web hoặc bỏ qua hoàn toàn việc triển khai hreflang.
Thông thường, chúng tôi sẽ phát hiện ra điều này trong các lần kiểm tra di chuyển của mình.
Nhưng tại thời điểm đó, chúng tôi đang phải vật lộn để khắc phục lỗi 404 ngẫu nhiên.
Chúng tôi cũng đã mắc lỗi khi không kiểm tra thủ công các trang đã bản địa hóa trên các mẫu khác nhau.
Để ngăn chặn điều này trong các lần di chuyển trong tương lai:
Nội dung do JavaScript điều khiển mà người dùng có thể thấy nhưng bot tìm kiếm thì không là một sự cố phổ biến và thường bị bỏ qua.
Điều này thường xảy ra khi các tiện ích hoặc phần nội dung dựa vào JavaScript để hiển thị, nhưng các tập lệnh không thể thu thập đầy đủ hoặc không được bot công cụ tìm kiếm thực thi đúng cách.
(Google cung cấp một nguồn tài nguyên tuyệt vời để giúp bạn hiểu Kiến thức cơ bản về JavaScript.)
Nếu bạn không chắc chắn về cách thức hoạt động của một tiện ích, hãy sử dụng bài kiểm tra đơn giản này:
Để phát hiện ra vấn đề này, hãy chạy cả trình thu thập thông tin hỗ trợ JavaScript và trình thu thập thông tin HTML thuần túy, sau đó so sánh kết quả.
Một bài kiểm tra thủ công nhanh cũng có thể hữu ích.
Vì quá trình di chuyển trang web thường không có nhiều thời gian để thử nghiệm, hãy ưu tiên chạy hai lần thu thập thông tin này sau khi di chuyển để xác định và khắc phục mọi sự cố kết xuất.
Tìm hiểu sâu hơn: Hướng dẫn chẩn đoán các sự cố SEO JavaScript phổ biến
Mất dữ liệu theo dõi có thể là vấn đề khó phát hiện nhưng tốn kém sau khi di chuyển.
Trong một trường hợp thực tế, mọi thứ ban đầu có vẻ ổn. Dữ liệu phân tích đang được truyền và lượt truy cập đang được ghi lại.
Tuy nhiên, sau một vài ngày, rõ ràng là người dùng truy cập thông qua quảng cáo trả phí đã mất các tham số theo dõi khi họ điều hướng trang web.
Điều này có nghĩa là các lượt xem trang tiếp theo trong cùng một phiên không còn được quy cho chiến dịch trả phí ban đầu, làm gián đoạn các nỗ lực tiếp thị lại.
Nguyên nhân là gì?
Xử lý không đúng các tham số URL trong quá trình di chuyển.
Việc di chuyển trang web đòi hỏi phải có sự giám sát giữa các nhóm, không chỉ từ nhóm SEO.
Mặc dù sự cố này không ảnh hưởng trực tiếp đến thứ hạng SEO, nhưng nó vẫn gây ra hậu quả lớn.
Trước khi bắt đầu di chuyển, hãy kiểm tra lại kế hoạch của bạn để đảm bảo tất cả các nhóm có liên quan đều tham gia.
Kiểm tra di chuyển phải vượt ra ngoài SEO, kết hợp các nhóm phân tích, phát triển và tiếp thị để bảo vệ các tham số theo dõi và ghi nhận người dùng.
Mỗi nhóm phải có báo cáo trước khi di chuyển để so sánh sau khi ra mắt.
Mặc dù việc lập kế hoạch có thể không nằm trong trách nhiệm trực tiếp của SEO, nhưng việc xác định các khoảng trống trong kế hoạch dự án và nêu lên các mối quan ngại là điều cần thiết.
Tìm hiểu sâu hơn: 12 cạm bẫy SEO cần tránh trong quá trình di chuyển nền tảng trang web
Trường hợp này là một ví dụ hoàn hảo về lý do tại sao việc có dữ liệu trước khi di chuyển là rất quan trọng.
Mọi thứ dường như hoàn hảo trong quá trình thử nghiệm.
Trang web hoạt động như mong đợi khi dàn dựng và thậm chí trong quá trình sản xuất với DNS nội bộ được chuyển đổi.
Nhưng ngay khi DNS bên ngoài được kích hoạt, một phần ba số bài đăng trên blog đã biến mất.
Phần còn lại của trang web vẫn nguyên vẹn, khiến vấn đề dễ bị bỏ qua.
Với tất cả các nhóm tập trung vào việc kiểm tra theo dõi, biểu mẫu, chuyển hướng, thẻ hreflang và chuẩn, không ai ban đầu nhận thấy các trang bị mất.
Thật trớ trêu, không phải công cụ SEO hoặc kiểm tra nhà phát triển đã phát hiện ra vấn đề, mà là một người quản lý khu vực.
Vài ngày trước khi di chuyển, cô ấy đã cập nhật một hình ảnh blog và muốn xác minh rằng thay đổi đã được chuyển.
Không chỉ hình ảnh bị mất mà toàn bộ bài đăng trên blog cũng biến mất.
Tôi thừa nhận rằng tôi không thể giải thích chính xác nguyên nhân gây ra điều này theo góc độ kỹ thuật.
Nhưng điều cần rút ra là: luôn tiến hành kiểm tra đầy đủ trước khi bắt đầu di chuyển.
Sử dụng chế độ so sánh của trình thu thập thông tin có thể nhanh chóng làm nổi bật những điểm khác biệt như thế này trước khi chúng trở thành vấn đề lớn.
Không phải mọi vấn đề đều ảnh hưởng đến SEO, nhưng điều đó không có nghĩa là chúng sẽ không gây ra vấn đề.
Trong quá trình cập nhật phần phụ trợ, chúng tôi gặp phải một thách thức bất ngờ: Lumar và Screaming Frog đã làm quá tải bảng quản trị CMS.
Mỗi lần bắt đầu thu thập thông tin, lượng yêu cầu tăng đột biến khiến biên tập viên gần như không thể cập nhật nội dung hoặc thực hiện thay đổi.
Điều quan trọng cần nhớ là bạn không công cụ duy nhất sử dụng các công cụ này.
Các trình thu thập thông tin thường được sử dụng để phân tích đối thủ cạnh tranh, nghĩa là trang web và CMS của bạn phải hoạt động bình thường ngay cả khi chịu áp lực thu thập thông tin lớn.
Trong một số tổ chức, nhóm SEO không có quyền truy cập trực tiếp vào CMS hoặc quản lý các bản cập nhật nội dung.
Nếu đúng như vậy, hãy đảm bảo nhóm nội dung thực hiện quy trình làm việc thông thường của họ với các phần thử nghiệm sau khi di chuyển.
Phối hợp điều này với các trình thu thập thông tin SEO giúp đánh giá mức độ phục hồi thực sự của hệ thống của bạn.
Di chuyển, cải tiến, thiết kế lại, cập nhật trang web. Dù bạn gọi chúng là gì thì chúng luôn phức tạp.
Một trong những sai lầm lớn nhất mà bạn có thể mắc phải là đánh giá thấp những thách thức liên quan.
Bất kỳ thay đổi nào cũng có nguy cơ xảy ra sai sót.
Một số lỗi, như chuyển hướng bị hỏng hoặc thiếu trang, có thể nhận thấy ngay lập tức.
Những lỗi khác, như lỗi theo dõi hoặc sự cố hiển thị JavaScript, có thể mất thời gian để phát hiện.
Đó là lý do tại sao việc giám sát sau khi di chuyển cũng quan trọng như chính quá trình di chuyển.
Cách tốt nhất để giảm thiểu những rủi ro này là:
Tìm hiểu sâu hơn: Cách tăng tốc quá trình di chuyển trang web bằng ánh xạ chuyển hướng hỗ trợ AI
Cho dù bạn có bao nhiêu kinh nghiệm về SEO kỹ thuật, kế hoạch của bạn chi tiết đến đâu hay danh sách kiểm tra của bạn có kỹ lưỡng đến đâu thì vẫn có thể phát sinh các vấn đề bất ngờ.
Đó là lý do tại sao việc theo dõi sau khi di chuyển cũng quan trọng như chính quá trình di chuyển – đặc biệt là trong tháng đầu tiên khi các vấn đề tiềm ẩn có nhiều khả năng xuất hiện nhất.
Bài viết này giải quyết một số lỗi sau khi ra mắt đáng ngạc nhiên nhất mà tôi từng gặp phải, cùng với các mẹo thực tế về cách xác định và giải quyết chúng trước khi chúng gây ra thiệt hại nghiêm trọng.
Trang 404 ngẫu nhiên
Vấn đề này khiến tôi phát điên. Đây là cơn ác mộng đối với thử nghiệm SEO vì nó làm sai lệch mọi công cụ và báo cáo mà chúng ta dựa vào.
Khi bạn không thể tin tưởng dữ liệu, bạn không thể biết được lỗi thực sự là gì hoặc nó ảnh hưởng đến hiệu suất như thế nào.
Trong giai đoạn sau khi di chuyển để cập nhật thư viện JavaScript, chúng tôi nhận thấy lỗi 404 ngẫu nhiên trong các công cụ SEO và Google Search Console.
Phần kỳ lạ là gì?
Các trang bị ảnh hưởng không nhất quán và mỗi lần chúng tôi kiểm tra thủ công, chúng đều tải tốt với trạng thái 200.
Kết quả là, tất cả các báo cáo khác đều không đáng tin cậy, khiến việc phân tích đúng cách gần như không thể.
Những lỗi 404 ngẫu nhiên này thường bắt nguồn từ các sự cố về phía máy chủ như giới hạn tốc độ, trong đó máy chủ từ chối quyền truy cập của bot sau quá nhiều yêu cầu.
Các nguyên nhân tiềm ẩn khác bao gồm:
- Bộ nhớ đệm được định cấu hình sai.
- Độ phân giải DNS không nhất quán.
- Tải lỗi cân bằng thỉnh thoảng định tuyến yêu cầu đến một máy chủ không khả dụng.
Và đây là bài học lớn nhất mà tôi học được: Nếu không có quyền truy cập vào nhật ký máy chủ, bạn sẽ phải chiến đấu một cách mù quáng.
Đảm bảo nhóm SEO của bạn có quyền truy cập vào các công cụ nhật ký máy chủ cần thiết và ít nhất là hiểu được những điều cơ bản về cách chúng hoạt động.
Theo dõi nhật ký hoạt động của bot có thể giúp bạn chứng minh sự cố với các nhà phát triển. Nếu không có chúng, bạn có nguy cơ bị mắc kẹt trong những cuộc tranh luận bất tận về độ chính xác của các công cụ SEO.
Tìm hiểu sâu hơn: Danh sách kiểm tra di chuyển trang web: 11 bước để thành công
500 trang ngẫu nhiên
Thoạt nhìn, lỗi này trông giống như lỗi 404 ngẫu nhiên, nhưng nguyên nhân thường hoàn toàn khác và cũng khó chẩn đoán như vậy.
Ngay cả các công cụ SEO như Lumar và Screaming Frog cũng có thể vô tình kích hoạt lỗi 500 này trong khi thu thập dữ liệu.
Nhiều năm trước, một trong những trang web tôi làm việc có một quy tắc nghiêm ngặt: không thu thập dữ liệu vào cuối tuần và không vượt quá ba URL mỗi giây.
Mỗi khi chúng tôi tăng giới hạn thu thập dữ liệu, máy chủ cơ sở dữ liệu sẽ gặp sự cố, làm chậm toàn bộ trang web - hoặc tệ hơn là làm sập trang web.
Những lỗi này thường là kết quả của các truy vấn cơ sở dữ liệu phức tạp làm quá tải máy chủ hoặc cấu hình không đúng cách bộ nhớ đệm.
Nếu không có bộ nhớ đệm phù hợp, mỗi yêu cầu sẽ được xử lý riêng lẻ, làm tăng thêm căng thẳng và dẫn đến thời gian tải chậm hoặc sự cố không liên tục.
Và một lần nữa, giải pháp bắt đầu bằng quyền truy cập nhật ký máy chủ. Nếu không có nó, bạn chỉ có thể đoán mò.
Tải tài nguyên không chính xác
Đây là một trong những khoảnh khắc khiến tôi cảm thấy mình giống như Sherlock Holmes kỹ thuật số.
Việc di chuyển đã hoàn tất trước khi tôi gia nhập công ty và tôi lần đầu tiên nhận thấy sự cố trong quá trình kiểm tra kỹ thuật ban đầu.
Manh mối đầu tiên?
Một sự sụt giảm bí ẩn về thứ hạng và lưu lượng truy cập ngay sau khi di chuyển.
Cũng có một bản cập nhật của Google vào cùng thời điểm đó, vì vậy tôi không thể liên kết ngay sự suy giảm này với quá trình di chuyển.
Để làm mọi thứ phức tạp hơn nữa, đây không phải là quá trình di chuyển hoàn toàn, chỉ là cải tiến thiết kế.
Nhìn bề ngoài, mọi thứ có vẻ ổn. Các trang được tải đúng cách và các kiểu và JavaScript hoạt động hoàn hảo đối với người dùng.
Tuy nhiên, trong công cụ kiểm tra của Google Search Console, các trang giống nhau thường bị hỏng và không có kiểu.
Vấn đề này không nhất quán, khiến việc sao chép trước nhóm phát triển gần như không thể.
Là một thành viên mới trong nhóm vẫn đang xây dựng lòng tin, việc thuyết phục họ rằng có một vấn đề sâu xa hơn không phải là điều dễ dàng.
Nhìn lại, lỗi của tôi là không kiểm tra bảng điều khiển trình duyệt sớm hơn.
Ba tháng sau, một thông báo bảng điều khiển trình duyệt duy nhất cuối cùng đã tiết lộ nguyên nhân gốc rễ: một tập lệnh đang tải không theo thứ tự.
Do lưu trữ đệm, đôi khi Googlebot thấy trang web đúng và đôi khi thì không, giải thích cho hành vi thất thường này.
Đó là lời nhắc nhở khó khăn rằng các chi tiết kỹ thuật nhỏ - như trình tự tải tài nguyên - và việc bỏ qua một bước chẩn đoán rõ ràng có thể ảnh hưởng đáng kể đến hiệu suất SEO.
Lời khuyên chính của tôi: Kiểm tra trang web của bạn trên các trình duyệt khác nhau và xem xét kỹ lưỡng các thông báo lỗi và cảnh báo trong bảng điều khiển.
Nếu bạn không quen với thuật ngữ dành cho nhà phát triển, hãy tham khảo ý kiến của chuyên gia độc lập hoặc thậm chí là nhiều công cụ AI để được giải thích.
URL không tồn tại
Trong khi điều tra những lỗi 404 ngẫu nhiên gây khó chịu đó, tôi tình cờ gặp phải một vấn đề khác.
Trong khi xem xét báo cáo của Google Search Console về các trang được phát hiện nhưng không được lập chỉ mục, tôi nhận thấy một mô hình bất thường - một số URL không tồn tại xuất hiện trong một số phần nhất định, được đánh dấu là nội dung trùng lặp.
Thay vì trả về lỗi 404 như mong đợi, các URL này được giải quyết như các trang bình thường với mã trạng thái 200.
Loại lỗi này gây ra hai rủi ro chính:
- Theo quan điểm SEO, các công cụ tìm kiếm coi các URL này là hợp lệ, có khả năng lập chỉ mục các trang không liên quan hoặc trùng lặp, lãng phí ngân sách thu thập thông tin và gây hại cho thứ hạng.
- Theo quan điểm bảo mật, nó tạo ra lỗ hổng - những kẻ tấn công độc hại có thể tạo ra hàng nghìn URL ngẫu nhiên, làm quá tải máy chủ.
Đừng chần chừ để tình cờ phát hiện ra nó. Hãy đảm bảo:
- Kiểm tra thường xuyên xem các phần của trang web của bạn có cho phép giải quyết các URL không tồn tại với trạng thái 200 hay không.
- Lập danh sách các phần chính và kiểm tra chúng hàng tháng bằng trình thu thập thông tin của bạn. Ngay cả những thay đổi nhỏ ở phần phụ trợ – không chỉ là di chuyển toàn bộ – cũng có thể gây ra sự cố này.
- Ưu tiên các trang được tạo theo chương trình hoặc động vì chúng là thủ phạm phổ biến nhất.
Thẻ hreflang hoặc thẻ chuẩn cho các URL không tồn tại
Quản lý thẻ hreflang trên một trang web đa ngôn ngữ là một thách thức và ngay cả những lỗi nhỏ cũng có thể gây ra sự cố lớn.
Trên một trang web mà tôi đã làm việc, chúng tôi thường tạo các trang bằng tiếng Anh trước rồi mới bản địa hóa chúng.
Tuy nhiên, trong một số trường hợp, chỉ có phiên bản bản địa tồn tại và hreflang
x-default đã vô tình được đặt thành một trang tiếng Anh không tồn tại.Thẻ hreflang không chính xác gây nhầm lẫn cho các công cụ tìm kiếm, vì chúng dựa vào chúng để xác định phiên bản ngôn ngữ hoặc khu vực chính xác của một trang.
Khi các thẻ này sai, các công cụ tìm kiếm có thể gặp khó khăn khi hiểu cấu trúc của trang web hoặc bỏ qua hoàn toàn việc triển khai hreflang.
Thông thường, chúng tôi sẽ phát hiện ra điều này trong các lần kiểm tra di chuyển của mình.
Nhưng tại thời điểm đó, chúng tôi đang phải vật lộn để khắc phục lỗi 404 ngẫu nhiên.
Chúng tôi cũng đã mắc lỗi khi không kiểm tra thủ công các trang đã bản địa hóa trên các mẫu khác nhau.
Để ngăn chặn điều này trong các lần di chuyển trong tương lai:
- Lên danh sách chi tiết các lần kiểm tra cụ thể cho từng trang web. Danh sách kiểm tra di chuyển chung là điểm khởi đầu tốt, nhưng chúng cần được tùy chỉnh cho trang web và CMS.
- Kiểm tra thủ công các trang đã bản địa hóa trên các mẫu khác nhau để đảm bảo triển khai hreflang và thẻ chính tắc chính xác.
Lỗi hiển thị JavaScript
Nội dung do JavaScript điều khiển mà người dùng có thể thấy nhưng bot tìm kiếm thì không là một sự cố phổ biến và thường bị bỏ qua.
Điều này thường xảy ra khi các tiện ích hoặc phần nội dung dựa vào JavaScript để hiển thị, nhưng các tập lệnh không thể thu thập đầy đủ hoặc không được bot công cụ tìm kiếm thực thi đúng cách.
(Google cung cấp một nguồn tài nguyên tuyệt vời để giúp bạn hiểu Kiến thức cơ bản về JavaScript.)
Nếu bạn không chắc chắn về cách thức hoạt động của một tiện ích, hãy sử dụng bài kiểm tra đơn giản này:
- Nó có hiển thị toàn bộ nội dung ngay lập tức hay có yêu cầu tương tác của người dùng không?
Để phát hiện ra vấn đề này, hãy chạy cả trình thu thập thông tin hỗ trợ JavaScript và trình thu thập thông tin HTML thuần túy, sau đó so sánh kết quả.
Một bài kiểm tra thủ công nhanh cũng có thể hữu ích.
- Tìm kiếm một câu hoặc phần tử cụ thể từ tiện ích trong nguồn HTML đã kết xuất của bạn.
- Nếu thiếu, có thể bot tìm kiếm cũng thiếu.
Vì quá trình di chuyển trang web thường không có nhiều thời gian để thử nghiệm, hãy ưu tiên chạy hai lần thu thập thông tin này sau khi di chuyển để xác định và khắc phục mọi sự cố kết xuất.
Tìm hiểu sâu hơn: Hướng dẫn chẩn đoán các sự cố SEO JavaScript phổ biến
Mất dữ liệu theo dõi
Mất dữ liệu theo dõi có thể là vấn đề khó phát hiện nhưng tốn kém sau khi di chuyển.
Trong một trường hợp thực tế, mọi thứ ban đầu có vẻ ổn. Dữ liệu phân tích đang được truyền và lượt truy cập đang được ghi lại.
Tuy nhiên, sau một vài ngày, rõ ràng là người dùng truy cập thông qua quảng cáo trả phí đã mất các tham số theo dõi khi họ điều hướng trang web.
Điều này có nghĩa là các lượt xem trang tiếp theo trong cùng một phiên không còn được quy cho chiến dịch trả phí ban đầu, làm gián đoạn các nỗ lực tiếp thị lại.
Nguyên nhân là gì?
Xử lý không đúng các tham số URL trong quá trình di chuyển.
Việc di chuyển trang web đòi hỏi phải có sự giám sát giữa các nhóm, không chỉ từ nhóm SEO.
Mặc dù sự cố này không ảnh hưởng trực tiếp đến thứ hạng SEO, nhưng nó vẫn gây ra hậu quả lớn.
Trước khi bắt đầu di chuyển, hãy kiểm tra lại kế hoạch của bạn để đảm bảo tất cả các nhóm có liên quan đều tham gia.
Kiểm tra di chuyển phải vượt ra ngoài SEO, kết hợp các nhóm phân tích, phát triển và tiếp thị để bảo vệ các tham số theo dõi và ghi nhận người dùng.
Mỗi nhóm phải có báo cáo trước khi di chuyển để so sánh sau khi ra mắt.
Mặc dù việc lập kế hoạch có thể không nằm trong trách nhiệm trực tiếp của SEO, nhưng việc xác định các khoảng trống trong kế hoạch dự án và nêu lên các mối quan ngại là điều cần thiết.
Tìm hiểu sâu hơn: 12 cạm bẫy SEO cần tránh trong quá trình di chuyển nền tảng trang web
Các trang biến mất
Trường hợp này là một ví dụ hoàn hảo về lý do tại sao việc có dữ liệu trước khi di chuyển là rất quan trọng.
Mọi thứ dường như hoàn hảo trong quá trình thử nghiệm.
Trang web hoạt động như mong đợi khi dàn dựng và thậm chí trong quá trình sản xuất với DNS nội bộ được chuyển đổi.
Nhưng ngay khi DNS bên ngoài được kích hoạt, một phần ba số bài đăng trên blog đã biến mất.
Phần còn lại của trang web vẫn nguyên vẹn, khiến vấn đề dễ bị bỏ qua.
Với tất cả các nhóm tập trung vào việc kiểm tra theo dõi, biểu mẫu, chuyển hướng, thẻ hreflang và chuẩn, không ai ban đầu nhận thấy các trang bị mất.
Thật trớ trêu, không phải công cụ SEO hoặc kiểm tra nhà phát triển đã phát hiện ra vấn đề, mà là một người quản lý khu vực.
Vài ngày trước khi di chuyển, cô ấy đã cập nhật một hình ảnh blog và muốn xác minh rằng thay đổi đã được chuyển.
Không chỉ hình ảnh bị mất mà toàn bộ bài đăng trên blog cũng biến mất.
Tôi thừa nhận rằng tôi không thể giải thích chính xác nguyên nhân gây ra điều này theo góc độ kỹ thuật.
Nhưng điều cần rút ra là: luôn tiến hành kiểm tra đầy đủ trước khi bắt đầu di chuyển.
Sử dụng chế độ so sánh của trình thu thập thông tin có thể nhanh chóng làm nổi bật những điểm khác biệt như thế này trước khi chúng trở thành vấn đề lớn.
Ảnh hưởng đến cài đặt quản trị
Không phải mọi vấn đề đều ảnh hưởng đến SEO, nhưng điều đó không có nghĩa là chúng sẽ không gây ra vấn đề.
Trong quá trình cập nhật phần phụ trợ, chúng tôi gặp phải một thách thức bất ngờ: Lumar và Screaming Frog đã làm quá tải bảng quản trị CMS.
Mỗi lần bắt đầu thu thập thông tin, lượng yêu cầu tăng đột biến khiến biên tập viên gần như không thể cập nhật nội dung hoặc thực hiện thay đổi.
Điều quan trọng cần nhớ là bạn không công cụ duy nhất sử dụng các công cụ này.
Các trình thu thập thông tin thường được sử dụng để phân tích đối thủ cạnh tranh, nghĩa là trang web và CMS của bạn phải hoạt động bình thường ngay cả khi chịu áp lực thu thập thông tin lớn.
Trong một số tổ chức, nhóm SEO không có quyền truy cập trực tiếp vào CMS hoặc quản lý các bản cập nhật nội dung.
Nếu đúng như vậy, hãy đảm bảo nhóm nội dung thực hiện quy trình làm việc thông thường của họ với các phần thử nghiệm sau khi di chuyển.
Phối hợp điều này với các trình thu thập thông tin SEO giúp đánh giá mức độ phục hồi thực sự của hệ thống của bạn.
Sai lầm lớn nhất: Đánh giá thấp việc giám sát sau khi di chuyển
Di chuyển, cải tiến, thiết kế lại, cập nhật trang web. Dù bạn gọi chúng là gì thì chúng luôn phức tạp.
Một trong những sai lầm lớn nhất mà bạn có thể mắc phải là đánh giá thấp những thách thức liên quan.
Bất kỳ thay đổi nào cũng có nguy cơ xảy ra sai sót.
Một số lỗi, như chuyển hướng bị hỏng hoặc thiếu trang, có thể nhận thấy ngay lập tức.
Những lỗi khác, như lỗi theo dõi hoặc sự cố hiển thị JavaScript, có thể mất thời gian để phát hiện.
Đó là lý do tại sao việc giám sát sau khi di chuyển cũng quan trọng như chính quá trình di chuyển.
Cách tốt nhất để giảm thiểu những rủi ro này là:
- Tạo một kế hoạch dự án chi tiết bao gồm tất cả các vấn đề tiềm ẩn.
- Ghi lại mọi thứ.
- Chạy kiểm tra trước và sau khi di chuyển.
- Hợp tác giữa các nhóm.
Tìm hiểu sâu hơn: Cách tăng tốc quá trình di chuyển trang web bằng ánh xạ chuyển hướng hỗ trợ AI
