Phân tích tụt hạng SEO: chẩn đoán nguyên nhân trước, sửa sau

Khi lưu lượng tự nhiên giảm đột ngột, phản ứng thường gặp trong tổ chức là tìm ngay một lời giải thích. Và lời giải thích sẵn có nhất — luôn có sẵn, vì Google cập nhật thuật toán liên tục — là "chắc do thuật toán".

Đây là chẩn đoán tệ nhất có thể đưa ra ở giờ đầu tiên, vì nó dẫn tới hành động sai. Nếu tin rằng nguyên nhân là thuật toán, việc tiếp theo sẽ là viết lại nội dung hàng loạt, thêm tác giả, sửa cấu trúc bài — trong khi nguyên nhân thật có thể là một thẻ noindex sót lại từ lần phát hành ba ngày trước, hoặc một thay đổi trong cấu hình theo dõi khiến số liệu sai chứ lưu lượng không hề giảm.

Tài liệu chính thức của Google về việc gỡ rối khi lưu lượng tìm kiếm giảm liệt kê nhiều nhóm nguyên nhân khác nhau: thay đổi thuật toán, vấn đề kỹ thuật, vấn đề bảo mật, vi phạm chính sách spam, biến động mùa vụ, thay đổi trong nhu cầu tìm kiếm, và các vấn đề phát sinh sau khi chuyển website. Thuật toán chỉ là một trong số đó.

Trang này mô tả quy trình RED dùng để phân biệt các nhóm nguyên nhân này bằng bằng chứng: dựng dòng thời gian sự cố trước khi chạy bất kỳ công cụ audit nào, đọc hình dạng của cú giảm để biết cần điều tra ở đâu, loại trừ lỗi đo lường trước khi kết luận về SEO, lập bảng giả thuyết có bằng chứng ủng hộ và phản bác thay vì một danh sách kiểm tra, tách nhóm bị ảnh hưởng khỏi nhóm đối chứng, và chỉ chuyển sang khắc phục khi mức tin cậy đủ.

RED không cam kết xác định được một nguyên nhân duy nhất trong mọi trường hợp. Khi nhiều biến động chồng lên nhau — một lần phát hành, một đợt cập nhật thuật toán và một giai đoạn thấp điểm cùng xảy ra trong hai tuần — việc tách bạch đóng góp của từng yếu tố có thể không khả thi. Trong tình huống đó, kết luận trung thực là nêu rõ các giả thuyết còn lại cùng mức tin cậy, không phải chọn đại một nguyên nhân để có câu trả lời.

Dựng dòng thời gian sự cố trước khi chạy audit

Câu hỏi đầu tiên không phải "website có lỗi gì" mà là "biến động bắt đầu chính xác khi nào, và quanh mốc đó có chuyện gì xảy ra".

Chạy một công cụ audit ngay từ đầu là phản xạ sai vì nó luôn cho ra hàng trăm phát hiện, và trong số đó chắc chắn có vài phát hiện trông đủ nghiêm trọng để đổ lỗi. Nhưng phần lớn các phát hiện đó đã tồn tại từ trước khi lưu lượng giảm — chúng không giải thích được sự thay đổi. Cái cần tìm là thứ đã thay đổi, không phải thứ đang sai.

Dòng thời gian sự cố SEO

Điểm khó nhất trong bảng này là dòng đầu tiên. Xác định đúng ngày bắt đầu quan trọng hơn mọi thứ khác, vì lệch vài ngày sẽ dẫn tới việc gán nhầm nguyên nhân. Cần lưu ý dữ liệu gần đây trong Search Console có thể ở trạng thái sơ bộ và được cập nhật lại, nên vài ngày cuối cùng của khoảng dữ liệu không đáng tin để xác định mốc.

Trùng thời điểm không phải nhân quả

Đây là nguyên tắc phải giữ trong suốt quá trình điều tra. Một đợt cập nhật thuật toán được công bố trong cùng tuần với đợt giảm không chứng minh rằng cập nhật đó là nguyên nhân — đặc biệt khi trong tuần đó cũng có một lần phát hành website.

Cách RED làm việc: liệt kê tất cả các sự kiện trong cửa sổ thời gian quanh mốc bắt đầu, coi mỗi sự kiện là một giả thuyết cần kiểm chứng hoặc loại trừ, và không xếp hạng chúng theo mức độ dễ tin. Việc một nguyên nhân nghe hợp lý hơn không phải bằng chứng.

Hình dạng của cú giảm cho biết nơi cần điều tra

Câu hỏi: số nhấp, số lần hiển thị và vị trí thay đổi theo mẫu hình nào?

Đây là bước rút ngắn thời gian điều tra nhiều nhất, và cũng là bước bị bỏ nhiều nhất vì hầu hết mọi người chỉ nhìn một đường tổng lưu lượng. Ba chỉ số này thay đổi theo các tổ hợp khác nhau, và mỗi tổ hợp chỉ về một nhóm nguyên nhân khác nhau.

Tài liệu của Google khuyến nghị tập trung vào xu hướng của số nhấp và số lần hiển thị hơn là chỉ nhìn vị trí trung bình. Lý do nằm chính ở đây: vị trí trung bình đơn lẻ không phân biệt được các tình huống hoàn toàn khác nhau.

Bảng phân loại hình dạng cú giảm

Trường hợp đầu tiên trong bảng đáng được nói riêng vì nó hay bị chẩn đoán sai nhất. Khi số lần hiển thị giữ nguyên mà số nhấp giảm, website không hề mất thứ hạng — nó vẫn xuất hiện đúng như trước. Vấn đề nằm ở chỗ khác: có thể Google viết lại thẻ tiêu đề hiển thị, có thể một tính năng hiển thị mới xuất hiện phía trên đẩy kết quả xuống dưới màn hình đầu, có thể một đối thủ mới có đoạn mô tả hấp dẫn hơn. Viết lại nội dung trang trong tình huống này là hành động không chạm vào nguyên nhân.

Nguyên tắc kỹ thuật khi đọc dữ liệu: giữ nguyên một cách gộp trong suốt quá trình so sánh. Search Console gộp dữ liệu theo cấp thuộc tính và cấp trang cho ra số lần hiển thị, số nhấp và vị trí khác nhau. So sánh số của tháng này lấy từ cách gộp này với số tháng trước lấy từ cách gộp kia sẽ tạo ra biến động hoàn toàn giả.

Kiểm tra chất lượng dữ liệu trước khi kết luận về SEO

Câu hỏi: lưu lượng thật sự giảm, hay chỉ số liệu bị sai?

Đây là bước phải làm trước mọi bước khác, vì nếu bỏ qua thì toàn bộ công sức điều tra sau đó có thể dành cho một vấn đề không tồn tại. Trong thực tế, một tỷ lệ không nhỏ các sự cố "mất lưu lượng" hóa ra là sự cố đo lường.

Cổng kiểm tra chất lượng dữ liệu

Cách kiểm tra nhanh nhất: đối chiếu chéo giữa hai nguồn độc lập. Nếu số nhấp trong Search Console giữ nguyên trong khi số phiên trong công cụ phân tích giảm mạnh, gần như chắc chắn vấn đề nằm ở khâu đo lường trên website chứ không phải ở khả năng xuất hiện trên kết quả tìm kiếm. Nếu cả hai cùng giảm, vấn đề là thật.

Nguyên tắc: không sửa SEO để chữa một lỗi đo lường. Nghe hiển nhiên nhưng chuyện này xảy ra thường xuyên, và hậu quả là tổ chức tiêu tốn nhiều tuần công sức cho một vấn đề không tồn tại, đồng thời tạo ra các thay đổi trên website mà về sau lại thành nguồn gốc của sự cố thật. Việc thiết lập hệ dữ liệu có định nghĩa rõ ràng để tránh loại nhầm lẫn này thuộc phạm vi báo cáo SEO.

Lập bảng giả thuyết thay vì chạy danh sách kiểm tra

Câu hỏi: mỗi nguyên nhân khả dĩ có bằng chứng nào ủng hộ và bằng chứng nào phản bác?

Danh sách kiểm tra dẫn tới việc thu thập thông tin theo chiều rộng mà không có hướng. Bảng giả thuyết dẫn tới việc thu thập thông tin có chủ đích: mỗi giả thuyết đưa ra một dự đoán cụ thể, và việc điều tra là kiểm tra xem dự đoán đó có đúng không.

Cách trình bày này cũng giải quyết vấn đề giao tiếp với ban lãnh đạo. Thay vì trả lời "chưa biết nguyên nhân", có thể trình bày trạng thái điều tra: đang có bốn giả thuyết, hai đã bị loại trừ bằng bằng chứng nào, hai còn lại cần kiểm tra gì.

Bảng giả thuyết nguyên nhân

Mỗi giả thuyết cần được gán một mức tin cậy dựa trên chất lượng bằng chứng, không dựa trên mức độ hợp lý về mặt trực giác. Bằng chứng mạnh nhất là bằng chứng phân lập: khi chỉ nhóm bị ảnh hưởng bởi một yếu tố giảm còn các nhóm khác giữ nguyên, giả thuyết về yếu tố đó mạnh lên đáng kể.

Về báo cáo tác vụ thủ công: đây là thứ cần kiểm tra sớm vì nó cho câu trả lời dứt khoát. Hình phạt thủ công được đưa ra khi người đánh giá của Google xác định website vi phạm chính sách chống spam, và nó có báo cáo riêng trong Search Console. Nếu báo cáo trống thì loại trừ được nhóm nguyên nhân này ngay, không cần suy đoán thêm.

Điều RED không làm: không chẩn đoán dựa trên một cảnh báo từ công cụ audit bên thứ ba. Các công cụ này cảnh báo theo quy tắc chung của công cụ, và một cảnh báo có thể đã tồn tại nhiều tháng trước khi lưu lượng giảm — nó không giải thích được sự thay đổi.

Tách nhóm bị ảnh hưởng khỏi nhóm đối chứng

Câu hỏi: nhóm trang nào giảm, và nhóm trang tương tự nào không giảm?

Đây là kỹ thuật mạnh nhất trong toàn bộ quy trình. Điều cần tìm không phải là "cái gì sai" mà là "điểm chung giữa những thứ bị ảnh hưởng, mà những thứ không bị ảnh hưởng không có".

Nếu toàn bộ trang danh mục giảm trong khi toàn bộ bài viết giữ nguyên, điểm chung là template danh mục — và việc điều tra thu hẹp lại đáng kể. Nếu các trang bị ảnh hưởng nằm rải rác không theo template nào nhưng đều thuộc một nhóm chủ đề, hướng điều tra khác hẳn.

Ma trận nhóm bị ảnh hưởng và nhóm đối chứng

Nguyên tắc quan trọng: không suy ra kết luận cho toàn website từ vài URL. Việc kiểm tra năm trang thấy đều giảm rồi kết luận "toàn site bị ảnh hưởng" là sai phương pháp — năm trang đó có thể cùng thuộc một nhóm mà người kiểm tra vô tình chọn.

Việc phân nhóm phải làm trước khi nhìn dữ liệu, dựa trên cấu trúc thật của website, rồi mới áp dữ liệu vào. Làm ngược lại — nhìn dữ liệu rồi vẽ nhóm quanh các trang giảm — sẽ luôn tìm được một "mẫu hình", kể cả khi không có.

Nhóm đối chứng là thứ giữ cho kết luận không bị lệch. Nếu các trang không liên quan gì tới thay đổi đang nghi ngờ cũng giảm với biên độ tương tự trong cùng khoảng thời gian, thì thay đổi đó không phải nguyên nhân.

Nhu cầu giảm bên ngoài website phải được nhận diện

Câu hỏi: nếu cả thị trường đang tìm kiếm ít hơn thì sao?

Đây là nhóm nguyên nhân mà không hành động SEO nào giải quyết được, và việc nhận diện nó sớm tiết kiệm được rất nhiều nguồn lực bị tiêu vào những việc không có tác dụng.

Tài liệu của Google về gỡ rối khi lưu lượng giảm nêu biến động mùa vụ và thay đổi trong nhu cầu tìm kiếm là các nhóm nguyên nhân riêng. Công cụ Google Trends có chức năng so sánh mức độ quan tâm theo thời gian và theo khu vực, dùng được để kiểm tra giả thuyết này — với lưu ý rằng nó đo mức quan tâm tương đối, không đo lưu lượng của một website cụ thể.

Kiểm tra dịch chuyển nhu cầu

Trường hợp thứ năm hay bị bỏ sót. Nếu kỳ trước có một đỉnh bất thường do một sự kiện — một chiến dịch lớn, một tin tức liên quan, một đợt khuyến mại — thì việc so sánh kỳ này với kỳ đó sẽ luôn cho ra "giảm", trong khi thực tế là kỳ này đang ở mức bình thường. Cách xử lý là so sánh với một kỳ bình thường, hoặc với cùng kỳ năm trước.

Ranh giới cần giữ: khi nguyên nhân là nhu cầu thị trường giảm, RED nói rõ điều đó thay vì đề xuất một gói công việc để "khắc phục". Không có hành động SEO nào tạo ra nhu cầu tìm kiếm không tồn tại. Việc cần bàn khi đó là câu hỏi chiến lược — có nên chuyển đầu tư sang nhóm chủ đề khác, sang thị trường khác, hay sang kênh khác — chứ không phải câu hỏi kỹ thuật.

Chỉ chuyển sang khắc phục khi mức tin cậy đủ

Câu hỏi: khi nào dừng điều tra và bắt đầu sửa, và giao cho ai?

Cám dỗ lớn nhất trong một sự cố là hành động sớm để chứng tỏ đang làm gì đó. Áp lực từ ban lãnh đạo đẩy về phía này, và kết quả thường là một loạt thay đổi diện rộng được thực hiện trước khi biết nguyên nhân — làm mất luôn khả năng chẩn đoán, vì sau đó không còn phân biệt được biến động nào do nguyên nhân gốc và biến động nào do chính các thay đổi vừa làm.

Cổng quyết định chuyển sang khắc phục

Sau khi vượt cổng, việc tiếp theo là chuyển sang đúng chuyên môn. Nếu nguyên nhân là kỹ thuật hoặc lập chỉ mục, phần xử lý thuộc SEO kỹ thuật. Nếu nguyên nhân liên quan tới việc chuyển website hoặc đổi URL, xử lý theo quy trình của SEO Migration. Nếu bằng chứng đủ mạnh cho thấy giảm gắn với một đợt cập nhật thuật toán lõi, hướng xử lý thuộc khôi phục Core Update. Nếu cần đánh giá tổng thể trạng thái website trước khi quyết định, SEO Audit là bước phù hợp.

Nguyên tắc không thỏa hiệp: không thực hiện thay đổi diện rộng trước khi có bằng chứng về nguyên nhân. Viết lại toàn bộ nội dung, thay đổi cấu trúc URL, hoặc gỡ bỏ hàng loạt liên kết khi chưa biết nguyên nhân là các hành động không đảo ngược được và có thể tạo ra sự cố mới chồng lên sự cố cũ.

Tổng kết sự cố để lần sau phát hiện sớm hơn

Câu hỏi: sau khi sự cố kết thúc, cần lưu lại gì?

Một sự cố được xử lý mà không có tổng kết sẽ lặp lại, và lần sau vẫn mất đúng chừng ấy thời gian để chẩn đoán.

Bản tổng kết sự cố

Hai nguyên tắc.

Ghi lại mức độ không chắc chắn một cách trung thực. Nếu bằng chứng còn hỗn hợp và không xác định được một nguyên nhân duy nhất, bản tổng kết phải nói vậy. Viết một kết luận dứt khoát không có cơ sở sẽ khiến lần sau tổ chức tìm sai hướng, vì họ tin rằng đã biết nguyên nhân.

Chuyển bài học thành cơ chế, không thành lời nhắc. "Lần sau nhớ kiểm tra thẻ robots trước khi deploy" là lời nhắc và sẽ bị quên. Thêm bước kiểm tra thẻ robots vào cổng kiểm soát phát hành là cơ chế và sẽ tồn tại. Độ trễ phát hiện thường là hạng mục cải thiện có giá trị nhất: nếu mất ba tuần mới phát hiện, việc thiết lập cảnh báo tự động khi một nhóm trang giảm quá ngưỡng sẽ rút ngắn đáng kể thời gian phản ứng cho mọi sự cố sau này.

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

Tụt lưu lượng có phải lúc nào cũng do Google cập nhật thuật toán không?

Không. Tài liệu chính thức của Google về gỡ rối khi lưu lượng tìm kiếm giảm liệt kê nhiều nhóm nguyên nhân: thay đổi thuật toán, vấn đề kỹ thuật, vấn đề bảo mật, vi phạm chính sách spam, biến động mùa vụ, thay đổi nhu cầu tìm kiếm, và các vấn đề sau khi chuyển website. Việc gán mặc định cho thuật toán dẫn tới hành động sai vì nó bỏ qua các nguyên nhân dễ kiểm chứng và dễ sửa hơn nhiều.

Số nhấp giảm nhưng số lần hiển thị không giảm nghĩa là gì?

Nghĩa là website vẫn xuất hiện trên kết quả tìm kiếm với tần suất như trước, nhưng ít người bấm hơn. Các nguyên nhân cần kiểm tra: giao diện trang kết quả thay đổi, thẻ tiêu đề hiển thị bị viết lại, một tính năng hiển thị mới chiếm chỗ phía trên, hoặc đối thủ mới xuất hiện với đoạn mô tả thu hút hơn. Đây không phải tình huống mất thứ hạng, nên viết lại nội dung trang thường không chạm vào nguyên nhân.

Có kiểm tra yếu tố mùa vụ không?

Có, và đây là một trong những bước đầu tiên. Cách kiểm tra là so sánh cùng kỳ nhiều năm trước và đối chiếu với dữ liệu xu hướng tìm kiếm để xem mức quan tâm của cả thị trường có giảm không. Nếu nguyên nhân là mùa vụ hoặc nhu cầu thị trường giảm, RED nói rõ điều đó thay vì đề xuất một gói công việc khắc phục — vì không có hành động SEO nào tạo ra nhu cầu tìm kiếm không tồn tại.

Hình phạt thủ công khác vấn đề thuật toán thế nào?

Hình phạt thủ công được áp dụng khi người đánh giá của Google xác định website vi phạm chính sách chống spam, và nó xuất hiện trong một báo cáo riêng trong Search Console. Vấn đề thuật toán không có thông báo nào. Vì vậy việc kiểm tra báo cáo tác vụ thủ công là bước cho câu trả lời dứt khoát và nên làm sớm: báo cáo trống thì loại trừ được ngay nhóm nguyên nhân này.

Phân tích tụt hạng khác SEO Audit ở điểm nào?

Audit đánh giá trạng thái tổng thể của website — những gì đang sai, ở mọi hạng mục. Phân tích tụt hạng là điều tra sự cố: tìm ra cái gì đã thay đổi và khi nào. Một website có thể có hàng trăm phát hiện trong bản audit mà không có phát hiện nào giải thích được cú giảm, vì chúng đã tồn tại từ trước. Audit là công cụ đánh giá; phân tích tụt hạng là công cụ chẩn đoán.

Khi nào chuyển sang dịch vụ khôi phục sau Core Update?

Khi bằng chứng đủ mạnh cho thấy cú giảm gắn với một đợt cập nhật thuật toán lõi: thời điểm bắt đầu trùng khớp với giai đoạn triển khai được công bố, phân bố ảnh hưởng theo nhóm nội dung chứ không theo template kỹ thuật, và các giả thuyết khác đã được loại trừ bằng bằng chứng. Nếu chưa đạt mức đó, việc chuyển sang khôi phục là chuyển sang sai hướng.

Gửi dữ liệu để RED bắt đầu chẩn đoán

Nếu website đang mất lưu lượng tự nhiên và chưa xác định được nguyên nhân, hãy gửi cho RED:

• Quyền truy cập Search Console và công cụ phân tích, nếu chia sẻ được
• Thời điểm phát hiện biến động và những gì đã quan sát được
• Nhật ký phát hành website trong ba tháng gần nhất, nếu có
• Các thay đổi đã thực hiện trên website, nội dung hoặc cấu hình đo lường gần đây
• Bối cảnh kinh doanh: mùa vụ của ngành, thay đổi về sản phẩm hoặc chính sách

RED sẽ dựng dòng thời gian sự cố, phân loại hình dạng cú giảm và phản hồi bằng bảng giả thuyết kèm mức tin cậy cùng các bước kiểm tra tiếp theo. RED không cam kết xác định được một nguyên nhân duy nhất khi nhiều biến động chồng lên nhau, không cam kết mốc thời gian phục hồi và không đề xuất thay đổi diện rộng trước khi có bằng chứng về nguyên nhân.