Dịch vụ SEO Audit — phạm vi, bằng chứng, thứ tự ưu tiên và điều kiện đóng lỗi
SEO Audit không phải danh sách hàng trăm lỗi từ crawler. Đây là cách chốt phạm vi, gắn mức tin cậy theo dữ liệu, chấm ưu tiên và xác minh trước khi đóng từng lỗi.
Một công cụ thu thập dữ liệu chạy qua website 5.000 trang sẽ trả về vài nghìn cảnh báo. Xuất ra PDF, đóng bìa, gửi khách hàng — đó là thứ vẫn được bán dưới tên "SEO Audit" ở khá nhiều nơi.
Vấn đề: bản báo cáo đó không cho biết nên làm gì trước, không cho biết ai phải làm, và phần lớn các cảnh báo trong đó không ảnh hưởng gì tới kết quả kinh doanh. Nó cũng không phân biệt được điều gì là kết luận chắc chắn với điều gì chỉ là suy đoán vì thiếu dữ liệu.
Chất lượng của một bản audit không đo bằng số lỗi tìm được. Nó đo bằng việc doanh nghiệp ra được quyết định gì sau khi đọc.
Trang này mô tả cách RED làm audit: chốt phạm vi trước khi thu thập, ghi rõ dữ liệu nào có và dữ liệu nào không, mỗi phát hiện phải tái hiện được, chấm thứ tự ưu tiên kèm giả định, gắn chủ sở hữu cho từng hạng mục, và chỉ đóng lỗi khi đã xác minh trên môi trường thật.
Phần triển khai sửa chữa ở lớp kỹ thuật thuộc Technical SEO, phần chỉnh sửa trên trang thuộc SEO Onpage.
Audit phải có bản điều lệ phạm vi trước khi thu thập dữ liệu
Chạy công cụ thu thập trước, hỏi phạm vi sau là cách làm ra một báo cáo lẫn lộn: có phần thừa, có phần thiếu, và không ai biết phần nào đã được kiểm tra.
Bản điều lệ phạm vi
| Hạng mục | Cần chốt gì | Vì sao |
|---|---|---|
| Tên miền và tên miền phụ | Những tên miền nào thuộc phạm vi, những tên miền nào không | Nhiều doanh nghiệp có blog hoặc cửa hàng trên tên miền phụ riêng, dễ bị bỏ sót |
| Thị trường và ngôn ngữ | Website có nhiều phiên bản ngôn ngữ hoặc khu vực không | Vấn đề của phiên bản đa ngôn ngữ khác hẳn website một ngôn ngữ |
| Nhóm trang | Những loại trang nào được kiểm tra: dịch vụ, danh mục, sản phẩm, bài viết, trang chức năng | Cho biết mẫu kiểm tra bao phủ tới đâu |
| Khoảng dữ liệu | Xem dữ liệu từ ngày nào tới ngày nào | Ảnh hưởng tới việc phát hiện xu hướng và tính mùa vụ |
| Thay đổi kinh doanh trong kỳ | Đổi giao diện, đổi nền tảng, ra mắt sản phẩm mới, chiến dịch lớn | Là bối cảnh để đọc dữ liệu; thiếu nó dễ quy sai nguyên nhân |
| Hệ thống nằm ngoài phạm vi | Ứng dụng di động, hệ thống đặt lịch riêng, tên miền phụ của bên thứ ba | Ghi rõ để không ai hiểu nhầm rằng đã kiểm tra |
| Mục tiêu của audit | Đánh giá tổng quát, chuẩn bị chuyển đổi, hay điều tra một vấn đề cụ thể | Quyết định độ sâu ở từng phần |
Nguyên tắc: nếu phạm vi bị giới hạn — vì thời gian, vì ngân sách, vì không có quyền truy cập — thì phải ghi rõ trong báo cáo, không gọi kết quả là "toàn diện".
Một bản audit trung thực nói rõ nó đã kiểm tra gì và chưa kiểm tra gì. Đây là điểm phân biệt cơ bản với những bản báo cáo tự động ngụ ý đã bao phủ mọi thứ.
Với các dự án chuẩn bị chuyển đổi website hoặc đổi nền tảng, phạm vi audit khác hẳn và cần chốt riêng: trọng tâm nằm ở việc bảo toàn những gì đang có, không phải tìm cơ hội mới.
Quyền truy cập dữ liệu quyết định mức độ tin cậy của kết luận
Đây là điểm ít bản audit nào nói ra: không có dữ liệu thì phần lớn kết luận chỉ là giả thuyết.
Một người bên ngoài chỉ nhìn website mà không có dữ liệu nội bộ có thể phát hiện các vấn đề quan sát được, nhưng không thể biết trang nào đang mang lại giá trị, truy vấn nào đang dẫn người dùng tới, hay tài nguyên thu thập đang bị tiêu vào đâu.
Ma trận dữ liệu và mức độ tin cậy
| Nguồn dữ liệu | Cho biết gì | Nếu không có thì mất gì | Kết luận nào trở thành giả thuyết |
|---|---|---|---|
| Search Console | Truy vấn thật, trạng thái index, lỗi thu thập, thông báo hành động thủ công và bảo mật | Mất toàn bộ dữ liệu tìm kiếm thật của website | Gần như mọi kết luận về hiệu quả và nguyên nhân |
| Công cụ phân tích | Hành vi người dùng, đường dẫn tới hành động có giá trị | Không biết trang nào tạo ra giá trị | Kết luận về ưu tiên theo giá trị kinh doanh |
| Công cụ thu thập dữ liệu | Cấu trúc website, lỗi kỹ thuật quan sát được | Không có bản đồ website | Mọi kết luận về cấu trúc và phạm vi |
| Nhật ký máy chủ | Hệ thống thực sự truy cập những URL nào, tần suất ra sao | Không biết tài nguyên thu thập bị tiêu vào đâu | Kết luận về hiệu quả thu thập trên website lớn |
| Hệ thống quản trị nội dung | Cách nội dung được tạo ra, mẫu giao diện sinh ra gì | Không biết lỗi nằm ở mẫu hay ở từng trang | Khuyến nghị sửa ở cấp mẫu |
| Dữ liệu liên kết từ công cụ bên thứ ba | Ước lượng về hồ sơ liên kết | Chỉ còn dữ liệu liên kết trong Search Console | Kết luận so sánh với đối thủ |
| Dữ liệu kinh doanh | Giá trị thật của từng nhóm khách hàng | Không xếp được thứ tự theo giá trị | Toàn bộ phần ưu tiên theo doanh thu |
Cách RED xử lý: mỗi phát hiện được gắn mức độ tin cậy dựa trên dữ liệu đang có. Một kết luận rút ra từ Search Console được ghi là chắc chắn. Một kết luận rút ra từ quan sát bên ngoài được ghi là giả thuyết cần xác minh.
Cần phân biệt rõ hai loại dữ liệu: dữ liệu của chính website — Search Console, công cụ phân tích, nhật ký máy chủ — và ước lượng của công cụ bên thứ ba. Loại thứ hai hữu ích để so sánh và khoanh vùng, nhưng không phải dữ liệu thật của website và không nên trình bày như vậy.
Mỗi phát hiện phải tái hiện được
Dòng "trang bị lỗi SEO" trong một bảng báo cáo không dùng được. Người nhận phải biết trang nào, lỗi gì, kiểm tra bằng cách nào, và vì sao nó quan trọng.
Phiếu bằng chứng cho một phát hiện
| Trường thông tin | Nội dung bắt buộc | Vì sao |
|---|---|---|
| Mô tả vấn đề | Nêu ngắn gọn vấn đề là gì | Để đọc lướt vẫn hiểu |
| Các URL bị ảnh hưởng | Danh sách cụ thể, hoặc mẫu đại diện kèm tổng số ước tính | Không có URL thì không sửa được |
| Quy mô mẫu | Kiểm tra bao nhiêu trang, phát hiện trên bao nhiêu | Phân biệt lỗi hệ thống với lỗi cá biệt |
| Hành vi quan sát được | Điều gì đang xảy ra trên thực tế | Là bằng chứng |
| Hành vi mong đợi | Điều gì lẽ ra phải xảy ra | Là tiêu chí để nghiệm thu sau khi sửa |
| Cách tái hiện | Các bước cụ thể để người khác kiểm chứng | Ngăn tranh cãi và cho phép đội phát triển tự kiểm tra |
| Bằng chứng đính kèm | Ảnh chụp màn hình, đoạn mã nguồn, dữ liệu xuất từ công cụ | Để báo cáo có thể kiểm chứng |
| Giả thuyết về tác động | Vấn đề này ảnh hưởng tới điều gì và mức độ chắc chắn tới đâu | Là căn cứ xếp ưu tiên, và phải ghi rõ là giả thuyết |
| Nguồn phát hiện | Từ công cụ thu thập, từ Search Console, từ kiểm tra thủ công | Cho biết mức độ tin cậy |
Trường quan trọng nhất là cách tái hiện. Nếu đội phát triển không tự kiểm chứng được, mọi phát hiện đều trở thành cuộc tranh luận giữa hai bên.
Trường về tác động phải viết trung thực. "Vấn đề này có thể đang ảnh hưởng tới khả năng index của nhóm trang X" là một giả thuyết có căn cứ. "Sửa việc này sẽ tăng 30% traffic" là một con số không có cơ sở.
Cần nói rõ một giới hạn: điểm số sức khỏe website và số lượng lỗi do các công cụ đưa ra là chỉ số nội bộ của chính công cụ đó. Chúng không phải chỉ số của Google và không phản ánh mức độ nghiêm trọng đối với kinh doanh. Một website có "500 lỗi" theo công cụ có thể đang hoạt động tốt hơn một website có "50 lỗi".
Mức độ nghiêm trọng không lấy trực tiếp từ công cụ
Công cụ gán nhãn nghiêm trọng theo quy tắc chung cho mọi website. Chúng không biết trang nào tạo ra doanh thu, không biết đội phát triển có bao nhiêu người, và không biết doanh nghiệp đang ưu tiên gì.
Ma trận chấm ưu tiên
| Tiêu chí | Cách chấm | Nguồn thông tin | Lưu ý |
|---|---|---|---|
| Mức tác động | Nếu sửa, điều gì cải thiện và ở mức nào | Dữ liệu website, hiểu biết về cách hệ thống hoạt động | Là ước lượng, không phải dự báo |
| Phạm vi ảnh hưởng | Bao nhiêu trang bị ảnh hưởng, chúng có quan trọng không | Dữ liệu thu thập, dữ liệu hiệu suất | Lỗi nhỏ trên nhiều trang quan trọng thường đáng xử lý trước |
| Mức độ tin cậy | Bằng chứng cho kết luận này mạnh tới đâu | Nguồn dữ liệu đang có | Phát hiện dựa trên suy đoán phải chấm thấp |
| Công sức | Cần bao nhiêu ngày công, loại nguồn lực nào | Phải hỏi đội thực thi | Không tự ước lượng thay đội phát triển |
| Rủi ro hồi quy | Sửa việc này có thể làm hỏng gì | Kinh nghiệm với nền tảng, phạm vi thay đổi | Thay đổi ở cấp mẫu luôn rủi ro cao hơn |
| Phụ thuộc | Có phải chờ hạng mục khác không | Sơ đồ phụ thuộc giữa các phát hiện | Hạng mục bị chặn không xếp đầu dù điểm cao |
Cách dùng: chấm từng phát hiện theo sáu tiêu chí, xếp thứ tự theo tương quan giữa tác động và công sức, rồi điều chỉnh theo phụ thuộc và rủi ro.
Hai nguyên tắc.
Ghi rõ giả định đằng sau mỗi điểm số. Một điểm số không có lý do đi kèm thì không tranh luận được, và khi giả định sai thì cả thứ tự ưu tiên sai theo mà không ai phát hiện.
Không tạo cảm giác chính xác giả tạo. Điểm số là công cụ hỗ trợ xếp thứ tự, không phải phép đo. Trình bày "hạng mục này 8,4 điểm" gợi ý một độ chính xác không có thật; "nhóm ưu tiên cao" trung thực hơn.
Audit phải chỉ rõ ai xử lý và phụ thuộc vào đâu
Một danh sách khuyến nghị không có tên người phụ trách là một danh sách sẽ nằm yên. Phần lớn hạng mục trong audit không do đội SEO thực hiện.
Bản đồ trách nhiệm xử lý
| Loại phát hiện | Ai xử lý chính | Ai cần phối hợp | Phụ thuộc điển hình | Tiêu chí nghiệm thu |
|---|---|---|---|---|
| Lỗi ở mã nguồn, cấu hình máy chủ | Đội phát triển | Đội SEO mô tả yêu cầu | Hàng đợi phát triển, lịch phát hành | Kiểm tra trên môi trường thật, hành vi khớp mô tả mong đợi |
| Cấu trúc URL, điều hướng | Đội phát triển | Đội SEO đề xuất, doanh nghiệp duyệt | Ảnh hưởng nhiều hệ thống | Cấu trúc mới hoạt động, chuyển hướng đầy đủ |
| Nội dung thiếu, sai hoặc trùng lặp | Đội nội dung | Chuyên gia lĩnh vực, đội SEO | Lịch sản xuất, thời hạn phê duyệt | Nội dung đã đăng và đáp ứng tiêu chí đã nêu |
| Thẻ tiêu đề, mô tả, cấu trúc heading | Đội SEO hoặc đội nội dung | Đội phát triển nếu nằm ở mẫu | Quyền chỉnh sửa trong hệ thống quản trị | Kiểm tra mã nguồn đầu ra |
| Dữ liệu sản phẩm, tồn kho | Bộ phận vận hành hoặc thương mại điện tử | Đội phát triển | Nguồn dữ liệu gốc | Dữ liệu khớp giữa các hệ thống |
| Nội dung pháp lý, phát ngôn thương hiệu | Bộ phận pháp chế hoặc thương hiệu | Đội nội dung | Quy trình phê duyệt nội bộ | Được duyệt bằng văn bản |
| Hạ tầng, hiệu năng máy chủ | Bộ phận hạ tầng hoặc nhà cung cấp dịch vụ | Đội phát triển | Hợp đồng với nhà cung cấp | Đo lại sau khi thay đổi |
Mỗi hạng mục cần một tiêu chí nghiệm thu cụ thể. "Sửa lỗi index" là mô tả mơ hồ. "Các URL trong danh sách trả về trạng thái bình thường, không bị chặn thu thập, và xuất hiện trong báo cáo index sau khi được thu thập lại" là tiêu chí kiểm chứng được.
Phần phụ thuộc cần được nêu rõ ngay trong báo cáo. Nếu ba hạng mục ưu tiên cao đều phụ thuộc vào cùng một đợt phát hành của đội phát triển, doanh nghiệp cần biết điều đó để lên kế hoạch, thay vì phát hiện sau hai tháng.
Đối thủ là bối cảnh, không phải mệnh lệnh sao chép
Phần so sánh với đối thủ trong nhiều bản audit dừng ở việc liệt kê: đối thủ có bao nhiêu trang, bao nhiêu liên kết, viết những chủ đề gì. Kết luận ngầm là làm giống họ.
Bảng bối cảnh đối thủ
| Chiều so sánh | Dùng để làm gì | Không dùng để làm gì |
|---|---|---|
| Độ phủ nhu cầu tìm kiếm | Phát hiện nhóm nhu cầu doanh nghiệp chưa phục vụ | Kết luận phải phủ mọi nhóm đối thủ đang phủ |
| Kiến trúc website | Hiểu cách họ tổ chức thông tin, đối chiếu với cách của mình | Sao chép cấu trúc mà không xét mô hình kinh doanh |
| Nội dung | Xem họ trả lời câu hỏi nào và ở mức độ nào | Viết lại nội dung của họ |
| Hồ sơ liên kết | Phát hiện các nguồn trong ngành mình chưa tiếp cận | Coi số lượng liên kết của họ là mục tiêu |
| Thành phần hiển thị họ đang chiếm | Biết dạng nội dung nào đang được ưu tiên trong lĩnh vực | Kết luận phải làm mọi dạng |
Nguyên tắc: việc đối thủ đang làm không đồng nghĩa việc đó hiệu quả. Nhiều website xếp trên nhờ những yếu tố không nhìn thấy được từ bên ngoài — thương hiệu mạnh, lịch sử lâu, quan hệ ngành — chứ không nhờ những gì họ đang làm trên trang.
Phần phân tích chuyên sâu về tập cạnh tranh thuộc phân tích đối thủ. Trong phạm vi audit, đối thủ được dùng để đặt bối cảnh cho các phát hiện, không phải để tạo ra một danh sách việc phải làm.
Audit và triển khai phải tách sản phẩm bàn giao
Đây là chỗ gây tranh chấp nhiều nhất trong hợp đồng, và nó hoàn toàn tránh được bằng cách viết rõ từ đầu.
Ranh giới giữa audit và triển khai
| Giai đoạn | Sản phẩm bàn giao | Thuộc phạm vi audit không |
|---|---|---|
| Phát hiện | Danh sách phát hiện kèm bằng chứng, mức tin cậy và thứ tự ưu tiên | Có |
| Khuyến nghị | Mô tả hướng xử lý cho từng phát hiện | Có |
| Đặc tả kỹ thuật | Mô tả chi tiết đủ để đội phát triển thực hiện | Tùy thỏa thuận — cần ghi rõ |
| Triển khai | Thực hiện thay đổi trên website | Không, trừ khi có hợp đồng riêng |
| Kiểm tra sau triển khai | Xác minh thay đổi đã có hiệu lực và không gây hồi quy | Tùy thỏa thuận — cần ghi rõ |
| Theo dõi dài hạn | Giám sát và báo cáo định kỳ | Không, thuộc chương trình vận hành |
Hai hàng ở giữa là nguồn gốc của phần lớn hiểu lầm. Doanh nghiệp thường mặc định rằng audit bao gồm cả đặc tả kỹ thuật chi tiết và kiểm tra sau khi sửa. Đơn vị dịch vụ thường mặc định ngược lại. Cả hai phía chỉ phát hiện sự khác biệt khi đã muộn.
Cách xử lý đơn giản: đánh dấu rõ từng hàng trong bảng này khi ký hợp đồng.
RED không ngầm hứa sửa lỗi miễn phí ngoài phạm vi. Nếu phát hiện một vấn đề nghiêm trọng nằm ngoài phạm vi đã thỏa thuận, RED nêu rõ trong báo cáo và đề xuất phạm vi bổ sung, thay vì im lặng hoặc làm rồi tính tiền sau.
Một phát hiện chỉ được đóng khi đã xác minh
"Đội phát triển báo đã sửa" không phải căn cứ để đóng một hạng mục. Rất nhiều thay đổi được triển khai nhưng không có hiệu lực như dự kiến — vì bộ nhớ đệm, vì cấu hình môi trường khác nhau, vì một thay đổi khác ghi đè lên.
Sổ theo dõi đóng lỗi
| Trạng thái | Điều kiện để chuyển sang trạng thái này | Bằng chứng |
|---|---|---|
| Đã báo cáo | Phát hiện được ghi vào báo cáo với đầy đủ bằng chứng | Phiếu bằng chứng |
| Đã tiếp nhận | Có người nhận trách nhiệm xử lý | Xác nhận từ chủ sở hữu |
| Đã triển khai | Thay đổi đã được phát hành lên môi trường thật | Xác nhận từ đội phát triển kèm ngày |
| Đã xác minh hiển thị | Kiểm tra mã nguồn đầu ra trên môi trường thật cho thấy thay đổi có hiệu lực | Ảnh chụp hoặc đoạn mã nguồn |
| Đã thu thập lại | Hệ thống đã thu thập lại các URL bị ảnh hưởng | Kiểm tra URL trong Search Console |
| Đã quan sát trong dữ liệu | Chỉ số liên quan phản ánh thay đổi | Báo cáo tương ứng trong Search Console |
| Đã kiểm tra hồi quy | Xác nhận thay đổi không làm hỏng thứ khác | Đối chiếu dữ liệu thu thập trước và sau |
| Đóng | Đạt các điều kiện trên, hoặc có quyết định chấp nhận rủi ro còn lại | Ghi rõ trạng thái đóng và lý do |
Hàng cuối cần lưu ý: không phải phát hiện nào cũng được sửa. Một số hạng mục không sửa được trên nền tảng hiện tại, một số không đáng chi phí. Trong những trường hợp đó, cách đóng đúng là ghi nhận rủi ro còn lại và ai đã quyết định chấp nhận nó — không phải xóa hạng mục khỏi danh sách.
Sổ này cũng là tài liệu bàn giao. Khi hợp đồng kết thúc, doanh nghiệp giữ lại danh sách những gì đã xử lý, những gì còn tồn, và lý do của từng quyết định.
Câu hỏi thường gặp
SEO Audit gồm những gì?
Phạm vi được chốt trước bằng bản điều lệ, thường bao gồm: khả năng thu thập và index, cấu trúc website và URL, các yếu tố trên trang, chất lượng và độ phủ nội dung, hồ sơ liên kết, và bối cảnh cạnh tranh. Sản phẩm bàn giao là danh sách phát hiện kèm bằng chứng tái hiện được, mức độ tin cậy, thứ tự ưu tiên, chủ sở hữu và tiêu chí nghiệm thu — không phải một danh sách cảnh báo xuất từ công cụ.
Audit khác Technical SEO thế nào?
Audit là chẩn đoán trên nhiều lớp: kỹ thuật, nội dung, cấu trúc, liên kết. Technical SEO là chương trình triển khai chuyên sâu ở lớp kỹ thuật. Audit thường tạo ra danh sách công việc cho Technical SEO, nhưng bản thân nó không phải công việc sửa chữa.
Có cần cấp quyền Search Console và công cụ phân tích không?
Có. Không có Search Console thì mất toàn bộ dữ liệu tìm kiếm thật của website, và phần lớn kết luận về nguyên nhân trở thành giả thuyết. Không có công cụ phân tích thì không biết trang nào đang tạo ra giá trị, nên không xếp được thứ tự ưu tiên theo giá trị kinh doanh. Audit vẫn làm được khi thiếu, nhưng mức độ tin cậy giảm và điều đó phải được ghi rõ.
Audit có sửa lỗi luôn không?
Không mặc định. Audit kết thúc ở danh sách phát hiện và khuyến nghị. Việc viết đặc tả kỹ thuật chi tiết, triển khai và kiểm tra sau triển khai là các giai đoạn riêng, cần thỏa thuận rõ trong hợp đồng. Đây là nguồn gốc của phần lớn hiểu lầm giữa hai bên, và nó tránh được bằng cách đánh dấu rõ từng giai đoạn khi ký.
Tìm được bao nhiêu lỗi thì gọi là audit tốt?
Số lượng không phải thước đo. Điểm số sức khỏe và số lỗi do công cụ đưa ra là chỉ số nội bộ của chính công cụ đó, không phải chỉ số của Google, và không phản ánh mức độ nghiêm trọng với kinh doanh. Một bản audit tốt được đo bằng việc doanh nghiệp ra được quyết định gì sau khi đọc: làm gì trước, ai làm, và làm xong thì kiểm tra thế nào.
Ưu tiên các phát hiện dựa vào gì?
Sáu tiêu chí: mức tác động nếu sửa, phạm vi ảnh hưởng, mức độ tin cậy của kết luận, công sức cần bỏ ra, rủi ro làm hỏng thứ khác, và các phụ thuộc. Điểm số là công cụ hỗ trợ xếp thứ tự, không phải phép đo chính xác — và mọi giả định đằng sau nó phải được ghi lại để tranh luận được.
Bước tiếp theo
Để RED đánh giá phạm vi cho một dự án audit, gửi năm thứ:
Địa chỉ website, các tên miền phụ đang dùng, và quy mô ước tính (số trang, số nhóm trang).
Mục tiêu của audit: đánh giá tổng quát, chuẩn bị chuyển đổi, hay điều tra một vấn đề cụ thể.
Quyền truy cập ở mức đọc vào Search Console và công cụ phân tích.
Nền tảng đang dùng và mức độ can thiệp được vào mã nguồn.
Nhật ký thay đổi lớn trong 6–12 tháng gần nhất, nếu có.
RED sẽ chốt bản điều lệ phạm vi, ghi rõ dữ liệu nào có và dữ liệu nào thiếu cùng ảnh hưởng của nó tới độ tin cậy, và phản hồi bằng đề xuất phạm vi kèm sản phẩm bàn giao cụ thể.
Hotline: 0845 009 977
Email: tuvan@red.com.vn