Đánh giá công cụ audit technical SEO bằng bài test

Muốn đánh giá độ chính xác của công cụ SEO khi audit technical SEO, không nên chỉ nhập một tên miền rồi đếm số cảnh báo. Cách đáng tin cậy hơn là tạo một website thử nghiệm có lỗi được cài đặt chủ động, xác định trước kết quả mong đợi và đối chiếu từng phát hiện của công cụ.

Bộ thử nghiệm nên bao phủ ít nhất sáu nhóm: mã trạng thái HTTP, canonical, robots, JavaScript, liên kết hỏng và nội dung trùng lặp. Ngoài khả năng phát hiện lỗi, doanh nghiệp còn cần kiểm tra độ chính xác, giới hạn crawl, bằng chứng kỹ thuật và chất lượng tệp xuất trước khi quyết định sử dụng.

Tiêu chí đánh giá công cụ audit technical SEO

Một công cụ audit website phù hợp cần trả lời được bốn câu hỏi:

1. Công cụ có phát hiện đúng lỗi đã cài đặt hay không?
2. Công cụ có tạo cảnh báo sai đối với trang bình thường hay không?
3. Công cụ có thu thập đủ website trong điều kiện thực tế hay không?
4. Báo cáo có đủ dữ liệu để SEO, lập trình viên và quản trị website cùng xử lý hay không?

Không nên đánh giá chỉ dựa trên tổng số lỗi. Một công cụ liệt kê nhiều cảnh báo chưa chắc chính xác hơn công cụ có ít cảnh báo nhưng cung cấp URL, bằng chứng và nguyên nhân rõ ràng. Khi lựa chọn giải pháp dài hạn, có thể kết hợp bộ thử nghiệm trong bài với các tiêu chí chọn phần mềm SEO web như phạm vi tính năng, khả năng tích hợp và mức độ phù hợp với quy trình nội bộ.

Bốn loại kết quả cần phân biệt

• Lỗi đúng: Website có lỗi và công cụ phát hiện chính xác.
• Lỗi giả: Website không có lỗi nhưng công cụ vẫn cảnh báo.
• Lỗi bị bỏ sót: Website có lỗi nhưng công cụ không phát hiện.
• Kết quả đúng âm: Trang không có lỗi và công cụ không cảnh báo.

Nếu cần lượng hóa kết quả, có thể dùng hai chỉ số:

• Độ chính xác cảnh báo: số lỗi đúng chia cho tổng số lỗi đúng và lỗi giả.
• Khả năng bao phủ: số lỗi đúng chia cho tổng số lỗi đúng và lỗi bị bỏ sót.

Không cần đặt một ngưỡng chung cho mọi website. Trang thương mại điện tử nhiều bộ lọc URL sẽ có yêu cầu khác với website giới thiệu doanh nghiệp chỉ có vài trăm trang.

Chuẩn bị website thử nghiệm và dữ liệu đối chứng

Nên chạy thử trên môi trường staging hoặc một khu vực kiểm thử tách biệt, không cài lỗi trực tiếp lên website đang phục vụ khách hàng. Một bộ dữ liệu khoảng 20–30 URL đã đủ để kiểm tra chức năng cốt lõi; quy mô lớn hơn chỉ cần thiết khi đánh giá giới hạn thu thập dữ liệu.

Trước khi crawl, hãy lập bảng đối chứng gồm các cột:

Trường	Nội dung cần ghi
Mã tình huống	Mã duy nhất như HTTP-01 hoặc CAN-02
URL thử nghiệm	Đường dẫn của trang được kiểm tra
Thiết lập	Lỗi hoặc trạng thái đã chủ động tạo
Kết quả mong đợi	Công cụ nên phát hiện điều gì
Kết quả thực tế	Dữ liệu công cụ trả về
Bằng chứng	Header HTTP, HTML nguồn, DOM sau render hoặc log máy chủ
Phân loại	Đúng, sai, bỏ sót hoặc chưa thể kết luận

Giữ cố định user-agent, phạm vi crawl, tốc độ truy cập, chế độ render JavaScript và trạng thái đăng nhập trong mỗi lượt thử. Nếu thay đổi nhiều điều kiện cùng lúc, rất khó xác định nguyên nhân chênh lệch.

Không dùng chính báo cáo của công cụ làm đáp án. Dữ liệu đối chứng cần được xác minh độc lập bằng phản hồi máy chủ, mã nguồn HTML, DOM đã render, tệp robots.txt và cấu hình website.

Bộ tình huống kiểm tra phần mềm audit SEO

1. Mã trạng thái HTTP và chuyển hướng

Tạo các đường dẫn trả về những trạng thái phổ biến sau:

Tình huống	Kết quả mong đợi
Trang trả về 200	Được ghi nhận là truy cập thành công
Chuyển hướng 301	Hiển thị URL nguồn, URL đích và mã 301
Chuyển hướng 302	Không bị gộp nhầm với chuyển hướng vĩnh viễn
Chuỗi gồm nhiều bước chuyển hướng	Liệt kê đủ từng chặng và độ dài chuỗi
Vòng lặp chuyển hướng	Cảnh báo vòng lặp, không tiếp tục crawl vô hạn
URL trả về 404	Ghi nhận đúng URL lỗi và các trang đang liên kết đến URL đó
URL trả về 410	Phân biệt với 404 nếu công cụ hỗ trợ
Trang lỗi hiển thị nội dung nhưng trả về 200	Nhận diện nguy cơ soft 404 hoặc cung cấp dữ liệu để kiểm tra
Phản hồi 500 hoặc 503	Ghi nhận lỗi máy chủ và thời điểm crawl
Trang yêu cầu đăng nhập trả về 401 hoặc 403	Không kết luận nhầm là URL không tồn tại

Với website có cả HTTP và HTTPS, cần kiểm tra từng biến thể giao thức, tên miền có hoặc không có www, đường dẫn có hoặc không có dấu gạch chéo cuối. Quy trình kiểm tra chuyển hướng HTTP sang HTTPS giúp xác nhận công cụ có nhìn thấy đầy đủ chuỗi chuyển hướng hay chỉ báo URL cuối.

Một lỗi thường gặp khi kiểm tra là chỉ nhìn nội dung hiển thị trong trình duyệt. Trang có thể hiện thông báo không tồn tại nhưng vẫn trả về 200, hoặc chuyển hướng bằng JavaScript thay vì header HTTP. Báo cáo tốt phải thể hiện mã phản hồi thực tế và loại chuyển hướng.

2. Canonical

Bộ test canonical nên có các trường hợp:

• Trang có canonical tự tham chiếu hợp lệ.
• Trang A đặt canonical sang trang B.
• Canonical trỏ đến URL 404 hoặc URL bị chuyển hướng.
• Canonical trỏ đến trang bị noindex.
• Canonical dùng HTTP trong khi trang đang chạy HTTPS.
• Canonical tương đối và canonical tuyệt đối.
• Một trang có nhiều thẻ canonical trong HTML.
• Canonical trong HTML khác với canonical trong HTTP header.
• Nội dung gần giống nhau nhưng mỗi URL lại tự canonical.

Công cụ nên hiển thị URL nguồn, canonical được khai báo, trạng thái HTTP của URL đích và khả năng truy cập URL đích. Tuy nhiên, không nên coi mọi canonical chéo là lỗi. Canonical là tín hiệu hợp nhất URL; tính đúng sai còn phụ thuộc quan hệ nội dung và chủ đích của website.

Một cảnh báo canonical chỉ có giá trị khi đi kèm ngữ cảnh. Ví dụ, canonical trỏ đến URL chuyển hướng là cấu hình nên xem xét, còn canonical tự tham chiếu trên trang độc lập thường không phải vấn đề.

3. Robots và khả năng index

Cần tách riêng ba khái niệm: cho phép thu thập dữ liệu, cho phép index và cho phép hiển thị đoạn trích. Chúng không đồng nghĩa.

Hãy tạo các trường hợp sau:

• URL được cho phép trong robots.txt và có index, follow.
• URL bị chặn bằng Disallow trong robots.txt.
• URL được crawl nhưng có meta robots noindex.
• URL có X-Robots-Tag: noindex trong HTTP header.
• Trang chứa đồng thời chỉ thị mâu thuẫn.
• Liên kết có thuộc tính nofollow.
• Trang dùng nosnippet hoặc giới hạn đoạn trích.
• Tài nguyên JavaScript hoặc CSS cần thiết bị robots.txt chặn.

Công cụ phải phân biệt URL bị chặn crawl với URL đã được crawl và phát hiện noindex. Nếu robots.txt ngăn truy cập, trình thu thập dữ liệu thường không thể đọc meta robots nằm trong HTML; vì vậy không nên yêu cầu công cụ báo một chỉ thị mà nó không thể quan sát.

Khi một URL không xuất hiện trên Google, báo cáo audit chỉ là một nguồn chẩn đoán. Quy trình kiểm tra nguyên nhân website không được index còn cần xem khả năng truy cập, canonical, chất lượng nội dung và trạng thái được Google ghi nhận.

4. Nội dung và liên kết tạo bằng JavaScript

Để kiểm tra khả năng render, hãy thiết lập hai phiên bản của cùng một trang:

• HTML ban đầu gần như trống, nội dung chính được chèn bằng JavaScript.
• Nội dung và liên kết đã có sẵn trong HTML máy chủ trả về.

Sau đó thêm các tình huống:

• Liên kết chỉ xuất hiện sau khi người dùng bấm nút.
• Nội dung được tải sau một khoảng chờ.
• JavaScript gọi API để lấy dữ liệu.
• Script bị lỗi nên nội dung không được render.
• Thẻ canonical hoặc meta robots bị JavaScript thay đổi.
• Liên kết được tạo bằng sự kiện thay vì phần tử a có href.

Ghi nhận riêng kết quả crawl HTML thô và kết quả sau render. Một technical SEO audit tool có hỗ trợ JavaScript nên cho biết chế độ nào đã được sử dụng, thời gian chờ render và tài nguyên nào tải thất bại.

Không phải liên kết xuất hiện trên màn hình đều có thể được trình thu thập dữ liệu khám phá như một liên kết HTML thông thường. Vì vậy, bằng chứng cần bao gồm cả mã nguồn ban đầu và DOM sau khi render.

5. Liên kết hỏng

Bộ thử nghiệm liên kết hỏng nên bao gồm:

• Liên kết nội bộ đến URL 404.
• Liên kết nội bộ đến URL 500.
• Liên kết qua chuỗi chuyển hướng.
• Liên kết từ nhiều trang nguồn đến cùng một URL hỏng.
• Liên kết ngoài không phản hồi.
• Liên kết chỉ xuất hiện sau khi render JavaScript.
• Liên kết chứa ký tự đặc biệt hoặc tham số truy vấn.
• Liên kết đến fragment không tồn tại trên cùng trang.

Báo cáo hữu ích phải cho biết cả URL đích bị lỗi và URL nguồn chứa liên kết. Nếu chỉ xuất một danh sách URL 404 mà không chỉ ra trang nào đang liên kết đến chúng, nhóm nội dung và lập trình viên sẽ mất thêm thời gian truy vết.

Đối với liên kết ngoài, lỗi timeout trong một lần crawl chưa đủ để kết luận URL đã hỏng. Nên thử lại ở thời điểm khác và phân biệt timeout, lỗi DNS, chặn bot, 403 và 404.

6. Nội dung trùng lặp

Tạo các cặp hoặc nhóm trang có mức độ giống nhau khác nhau:

• Hai URL có nội dung giống hoàn toàn.
• Hai URL chỉ khác tiêu đề.
• Hai trang sản phẩm chỉ khác tên hoặc mã sản phẩm.
• URL có tham số sắp xếp hoặc theo dõi nhưng nội dung không đổi.
• Phiên bản có và không có dấu gạch chéo cuối.
• Hai trang khu vực như /dich-vu/ha-noi và /dich-vu/tp-ho-chi-minh chỉ thay tên địa danh nhưng phần còn lại gần như giống nhau.
• Nội dung giống nhau nhưng canonical đã hợp nhất về một URL chính.

Cần kiểm tra công cụ đang so sánh yếu tố nào: tiêu đề, meta description, văn bản chính, toàn bộ HTML hay một dấu vân tay nội dung. Nếu công cụ không công bố phương pháp, hãy dùng các cặp trang có mức giống nhau tăng dần để quan sát ngưỡng cảnh báo.

Không phải mọi nội dung trùng lặp đều cần xóa. Trang in, URL tham số hoặc biến thể kỹ thuật có thể được xử lý bằng canonical, chuyển hướng hoặc kiểm soát điều hướng. Ngược lại, các trang địa phương chỉ thay tên Hà Nội và TP.HCM nhưng không cung cấp thông tin riêng có thể cần biên tập lại thay vì chỉ sửa canonical.

Cách ghi nhận lỗi đúng, lỗi giả và lỗi bị bỏ sót

Mỗi cảnh báo cần được xác minh theo ba lớp:

1. Phản hồi máy chủ: Kiểm tra mã trạng thái, header, số lần chuyển hướng và thời gian phản hồi.
2. HTML ban đầu: Kiểm tra canonical, meta robots, liên kết và nội dung do máy chủ trả về.
3. DOM sau render: Kiểm tra những thay đổi do JavaScript tạo ra.

Khi nào một cảnh báo có thể là lỗi giả?

• Công cụ báo 404 nhưng URL thực tế trả về 403 vì tường lửa chặn bot.
• Công cụ báo thiếu nội dung vì không chờ JavaScript render xong.
• Công cụ báo canonical không hợp lệ do chỉ crawl URL nguồn mà chưa kiểm tra URL đích.
• Công cụ báo trang mồ côi dù trang được liên kết từ sitemap hoặc khu vực yêu cầu đăng nhập.
• Công cụ báo nội dung trùng lặp vì tính cả menu, chân trang và các thành phần dùng chung.
• Công cụ báo chuyển hướng quá dài vì tính cả bước chuyển giao thức do cấu hình môi trường thử nghiệm.

Khi nào chưa thể kết luận?

Đánh dấu “chưa thể kết luận” thay vì ép thành đúng hoặc sai nếu gặp timeout, máy chủ phản hồi không ổn định, bot bị chặn, dữ liệu yêu cầu đăng nhập hoặc nội dung thay đổi theo vị trí, cookie và thiết bị.

Google Search Console có thể hỗ trợ xác minh một số URL quan trọng, nhưng không thay thế trình crawl toàn website. Ngược lại, phần mềm crawl cũng không cung cấp đầy đủ dữ liệu mà Google ghi nhận. Việc đối chiếu phần mềm SEO với Google Search Console giúp tránh kết luận dựa trên một nguồn duy nhất.

Kiểm tra giới hạn thu thập dữ liệu

Giới hạn công bố trong gói dịch vụ chưa chắc là giới hạn thực tế của một phiên crawl. Hãy kiểm tra theo từng cấp quy mô, chẳng hạn 100 URL, 1.000 URL rồi tăng dần trong môi trường do doanh nghiệp kiểm soát. Đây là kích thước thử nghiệm gợi ý, không phải chuẩn bắt buộc.

Ở mỗi cấp, ghi nhận:

• Số URL được phát hiện.
• Số URL đã crawl thành công.
• Số URL bị bỏ qua và lý do.
• Số lần yêu cầu lại.
• Thời gian hoàn thành.
• Mức sử dụng CPU, bộ nhớ hoặc quota nếu có thể quan sát.
• Số trang được render JavaScript.
• Tốc độ gửi yêu cầu và khả năng tự điều chỉnh khi máy chủ phản hồi 429 hoặc 503.
• Quy tắc xử lý tham số, phân trang và lịch crawl.

Đồng thời thử các cấu trúc có thể tạo không gian URL rất lớn, như bộ lọc nhiều lớp, lịch vô hạn hoặc tham số kết hợp. Công cụ phải cho phép giới hạn phạm vi, loại trừ mẫu URL và dừng crawl khi phát hiện vòng lặp. Không nên gây tải lớn lên website thật chỉ để tìm giới hạn công cụ.

Nếu số URL báo cáo thấp hơn dự kiến, cần xác định nguyên nhân trước khi kết luận công cụ bị giới hạn. URL có thể không được khám phá do thiếu liên kết nội bộ, bị chặn bởi robots.txt, nằm ngoài phạm vi tên miền hoặc chỉ xuất hiện sau tương tác JavaScript.

Đánh giá khả năng xuất báo cáo

Bản xuất CSV, bảng tính hoặc API cần giữ đủ dữ liệu để người nhận có thể xác minh lỗi mà không phải mở lại từng URL trong giao diện.

Các trường nên có gồm:

• Mã lỗi ổn định.
• Mô tả ngắn và mức độ ưu tiên.
• URL nguồn và URL đích.
• Mã trạng thái HTTP.
• Canonical khai báo và trạng thái URL canonical.
• Chỉ thị robots phát hiện được.
• Nguồn phát hiện: HTML, header, sitemap hay JavaScript.
• Thời gian crawl.
• Chế độ render.
• Bằng chứng hoặc giá trị thực tế gây ra cảnh báo.

Hãy thử mở tệp bằng phần mềm bảng tính, kiểm tra mã hóa UTF-8, dấu tiếng Việt, URL dài, ký tự đặc biệt và cách xuống dòng. Tiếp theo, lọc theo loại lỗi, sắp xếp theo mức độ ưu tiên và đối chiếu số dòng với giao diện.

Một báo cáo tốt cũng cần hỗ trợ so sánh các lần crawl. Sau khi sửa một số lỗi trong website thử nghiệm, chạy lại và kiểm tra xem công cụ có phân biệt được lỗi mới, lỗi còn tồn tại và lỗi đã khắc phục hay không.

Bảng chấm điểm và checklist audit website

Có thể dùng thang điểm 100 sau đây làm khung tham khảo:

Nhóm tiêu chí	Điểm gợi ý
Độ chính xác và tỷ lệ lỗi giả	40
Độ phủ sáu nhóm tình huống	20
Khả năng crawl và kiểm soát phạm vi	15
Chất lượng báo cáo và xuất dữ liệu	15
Khả năng sử dụng trong quy trình nội bộ	10

Không nên dùng tổng điểm để che lấp lỗi nghiêm trọng. Công cụ đạt điểm cao nhưng thường xuyên đọc sai mã trạng thái, bỏ sót noindex hoặc không chỉ ra URL nguồn của liên kết hỏng vẫn có thể không phù hợp.

Checklist trước khi quyết định sử dụng

• [ ] Đã thử trên website kiểm soát được cấu hình.
• [ ] Đã có bảng kết quả mong đợi trước khi crawl.
• [ ] Đã kiểm tra 200, 301, 302, 404, 410 và lỗi máy chủ.
• [ ] Đã thử chuỗi và vòng lặp chuyển hướng.
• [ ] Đã kiểm tra canonical tự tham chiếu, canonical chéo và canonical lỗi.
• [ ] Đã phân biệt robots.txt, meta robots và X-Robots-Tag.
• [ ] Đã thử HTML thô và nội dung render bằng JavaScript.
• [ ] Đã kiểm tra liên kết hỏng nội bộ lẫn liên kết ngoài.
• [ ] Đã thử nội dung trùng hoàn toàn và gần trùng lặp.
• [ ] Đã ghi nhận lỗi đúng, lỗi giả và lỗi bị bỏ sót.
• [ ] Đã kiểm tra giới hạn URL và khả năng kiểm soát tốc độ crawl.
• [ ] Đã xuất báo cáo và đối chiếu dữ liệu với giao diện.
• [ ] Đã kiểm tra khả năng so sánh hai lần crawl.
• [ ] Đã xác định ai chịu trách nhiệm xử lý từng nhóm lỗi.

Bộ tiêu chí này có thể dùng làm tài liệu nghiệm thu khi doanh nghiệp triển khai giải pháp audit technical SEO của Hà Sơn Tech. Quyết định cuối cùng nên dựa trên dữ liệu thử nghiệm của chính website, thay vì số lượng cảnh báo hoặc mô tả tính năng chung.

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

Công cụ audit website có thay thế Google Search Console không?

Không. Công cụ audit chủ động crawl website để phát hiện vấn đề kỹ thuật, trong khi Google Search Console cung cấp một phần dữ liệu về cách Google truy cập, index và hiển thị website. Hai nguồn có mục đích khác nhau và nên được đối chiếu.

Mọi cảnh báo canonical đều là lỗi cần sửa ngay không?

Không. Canonical chéo có thể là cấu hình có chủ đích để hợp nhất các URL giống nhau. Chỉ nên kết luận sau khi kiểm tra nội dung, trạng thái HTTP, khả năng index và URL canonical đích.

Vì sao công cụ không phát hiện meta noindex trên URL bị robots.txt chặn?

Khi URL bị chặn thu thập dữ liệu, công cụ có thể không tải được HTML nên không nhìn thấy meta robots bên trong trang. Đây có thể là giới hạn quan sát hợp lý, không nhất thiết là lỗi của phần mềm.

Website không dùng nhiều JavaScript có cần kiểm tra render không?

Vẫn nên thử ít nhất một lần để xác nhận nội dung chính, liên kết, canonical và robots không bị script thay đổi. Nếu toàn bộ thông tin quan trọng đã có trong HTML máy chủ trả về, có thể ưu tiên crawl không render để tiết kiệm tài nguyên.

Bản dùng thử có đủ để kiểm tra phần mềm audit SEO không?

Có thể đủ nếu bản dùng thử cho phép crawl toàn bộ bộ dữ liệu đối chứng và xuất báo cáo cần thiết. Nếu bị giới hạn URL hoặc tính năng render, kết quả chỉ phản ánh phần chức năng đã được truy cập; cần ghi rõ giới hạn thay vì suy rộng cho toàn bộ sản phẩm.