Audit SEO: cách tôi audit website từng bước

Audit SEO là quyết định nên sửa gì trước trên website, có bằng chứng ở mỗi khuyến nghị và cách kiểm tra sau khi triển khai. Danh sách lỗi từ công cụ mới chỉ là nguyên liệu của audit. Audit kỹ thuật là phần của nó kiểm tra xem bot của công cụ tìm kiếm và của các trợ lý AI có tải và đọc được website không, và công cụ tìm kiếm có lập chỉ mục được không.

Tôi làm audit theo tám bước:

1. Tôi xác định mục tiêu và tình hình website trước khi chạy crawler, tức chương trình duyệt website giống như bot của công cụ tìm kiếm.
2. Tôi kiểm tra xem bot có nhận được website không.
3. Tôi thu thập dữ liệu từ nhiều nguồn và kiểm tra mỗi nguồn không nhìn thấy gì.
4. Tôi nghiên cứu từ khóa và kết quả Google trước khi đụng đến kỹ thuật.
5. Tôi rà soát website theo danh mục vấn đề kèm điều kiện ưu tiên.
6. Ở mỗi vấn đề tôi đưa ra bằng chứng.
7. Tôi xác định thứ tự, khối lượng công việc và các phương án.
8. Tôi đưa kết quả đi kiểm tra chéo, và sau khi triển khai tôi kiểm tra từng vấn đề.

Audit SEO là gì và audit kỹ thuật khác ở điểm nào?

Audit SEO cho biết website đang ở tình trạng nào và điều gì giới hạn khả năng hiển thị của nó, còn audit kỹ thuật kiểm tra xem công cụ tìm kiếm có tải, render và lập chỉ mục được website không. Trong audit đầy đủ tôi kiểm tra kỹ thuật, kiến trúc và nội dung các trang, từ khóa, link bên ngoài và đối thủ, và cuối cùng sắp xếp thứ tự hành động. Audit kỹ thuật là đủ khi câu hỏi mang tính kỹ thuật: traffic giảm sau khi triển khai, chuyển đổi website, các trang rơi khỏi chỉ mục.

Audit là đầu vào của chiến lược, chứ không phải chiến lược. Chiến lược nói bạn giành nhu cầu nào và bỏ qua điều gì, còn audit nói hiện nay điều gì cản trở việc đó. Trong bài về chiến lược SEO tôi mô tả cái này chuyển thành cái kia ra sao.

Làm thế nào để audit SEO từng bước?

Thứ tự các bước quan trọng, vì các bước trước quyết định xem con số ở các bước sau có đáng tin không. Ở hai chỗ tôi dừng quy trình lại để quyết định: sau bước đầu tiên tôi chốt phạm vi, còn sau kiểm tra chéo, trước khi gửi cho khách hàng, tôi xem lại các ưu tiên và luận điểm.

Bước 1. Mục tiêu và tình hình website, trước khi tôi chạy crawler

Câu hỏi đầu tiên là website đang mất traffic hay chưa xây dựng được traffic, vì toàn bộ audit phụ thuộc vào câu trả lời. Website chưa có khả năng hiển thị trước hết cần bản đồ từ khóa và các trang sẽ trả lời chúng. Website đã có khả năng hiển thị trước hết cần bảo vệ những gì đang giữ vị trí, trước khi ai đó bắt đầu sửa nó.

Trước khi bắt đầu tôi hỏi những điều mà công cụ nào cũng không cho thấy. Sản phẩm hay dịch vụ nào đang sinh lời, có kế hoạch đổi hệ thống quản trị nội dung hoặc làm lại website không, ai sẽ triển khai các khuyến nghị và họ có bao nhiêu thời gian. Các câu trả lời giúp tôi xác định phạm vi audit và danh sách những việc tôi không mô tả, vì sẽ không ai triển khai chúng.

Giai đoạn này phải tự mình làm, dù ngày nay nhiều chuyên gia giao nó cho mô hình ngôn ngữ. Mô hình ngôn ngữ đôi khi hữu ích, nhưng không hiểu được hoạt động kinh doanh của khách hàng. Nó cũng không mang lại góc nhìn sáng tạo, độc đáo của một chuyên gia SEO có kinh nghiệm.

Bước 2. Bot có nhận được website không

Trước khi đọc bất kỳ con số nào từ công cụ, tôi kiểm tra xem máy chủ có cho bot vào không, vì bot bị chặn tạo ra dữ liệu trông như vấn đề SEO. Trong một tuần của tháng 7 năm 2026, ba “vấn đề SEO” ở ba website khác nhau hóa ra là việc chặn bot:

1. Một website “mất” hơn 2.200 link, vì các trang chứa chúng nằm sau tường lửa chặn bot của công cụ phân tích link.
2. Một cửa hàng có điểm sức khỏe website bằng 0 trong công cụ với gần 42 nghìn lỗi, vì thay vì các trang, bot của công cụ nhận phản hồi của tường lửa Cloudflare.
3. Ở website thứ ba, việc chặn giữ crawler lại ở địa chỉ đầu tiên và ba tuần không ai ghi nhận điều đó.

Tôi tải cùng một địa chỉ bằng trình duyệt thông thường và bằng bot của Google, Bing, OpenAI, Perplexity và Anthropic, rồi so sánh mã phản hồi và dung lượng trang. Khác biệt giữa trình duyệt và bot là điều đầu tiên cần làm rõ, trước khi tôi bắt đầu tính bất cứ gì. Phép kiểm tra như vậy gửi yêu cầu từ địa chỉ IP của tôi dưới tên bot, còn tường lửa nhận ra bot thật của Google và Bing dựa vào địa chỉ IP gửi yêu cầu. Vì vậy việc “Googlebot” bị chặn trong phép kiểm tra không chứng minh Googlebot thật bị chặn. Search Console, bảng điều khiển miễn phí của Google cho chủ website, cho thấy Googlebot thật nhìn website ra sao.

File robots.txt tôi đọc đến hết bằng parser, tức chương trình áp dụng quy tắc giống như bot, chứ không đọc bằng mắt. Bot của Google chỉ áp dụng một nhóm quy tắc, nhóm có tên bot khớp nhất, và bỏ qua phần còn lại. Quy tắc Disallow: không có đường dẫn không chặn gì cả (Google Search Central). Vào tháng 8 năm 2026, từ một đoạn robots.txt của một website, có vẻ như nó chặn Google. Parser cho thấy Googlebot có toàn quyền truy cập, còn bị chặn là bot của Bing và các trợ lý AI. Vì vậy chẩn đoán khác: vấn đề nằm ở Bing và bot AI, chứ không phải Google.

Không có file robots.txt thì không chặn Google, nhưng sau mỗi lần triển khai tôi kiểm tra xem file có biến mất không. Google coi lỗi 4xx ở robots.txt (trừ 429) như không có file, tức không có hạn chế (Google Search Central). Website của tôi vào tháng 8 năm 2026 trả về lỗi 404 ở robots.txt, trước khi tôi sửa.

Bước 3. Dữ liệu từ nhiều nguồn và điều mỗi nguồn không thấy

Mỗi con số từ crawler chỉ là giả thuyết cho đến khi nguồn thứ hai xác nhận. Tôi thu thập crawl có và không chạy JavaScript, cùng dữ liệu về tốc độ từ người dùng thật trong báo cáo CrUX. Thêm vào đó là hồ sơ link và kết quả Google cho các từ khóa quan trọng vào ngày đo. Trong bài về link building tôi mô tả cách kiểm tra hồ sơ link trước khi lập kế hoạch chiến dịch. Ở mỗi file tôi ghi lại nguồn, ngày và phạm vi, để sau một tháng vẫn tái tạo được từng con số.

Dữ liệu từ Search Console tôi lấy qua API, tức giao diện để tải dữ liệu tự động, vì xuất từ bảng điều khiển cắt danh sách ở 1.000 dòng. API trả về tới 50 nghìn dòng mỗi ngày cho mỗi loại kết quả, ví dụ riêng cho kết quả của trang, hình ảnh và video (Google, Trợ giúp Search Console). Trong bài về công cụ AI trong SEO tôi cho thấy bản xuất bị cắt đã làm CTR của một website cao hơn thực tế như thế nào.

Crawler có thể đánh giá thấp quy mô website, nên số lượng trang và sản phẩm tôi kiểm tra ở nguồn thứ hai. Ở hai cửa hàng, crawler đi đến trang đầu của danh sách sản phẩm trong danh mục rồi không đi tiếp, dù các trang tiếp theo của danh sách vẫn hoạt động và không bị chặn. Ở một cửa hàng nó tìm thấy chưa đến một nửa số sản phẩm, ở cửa hàng kia chưa đến một phần ba. Nếu tôi đưa các con số này làm tình trạng của cửa hàng, audit sẽ mô tả những thiếu sót trong danh mục sản phẩm mà thực tế không có.

Những thay đổi đột ngột trong dữ liệu hằng ngày tôi mô tả trước khi gán cho chúng nguyên nhân. Tôi làm vậy với lượt nhấp, lượt hiển thị, vị trí, phiên và yêu cầu của bot Google. Tôi tìm những ngày mà trung vị của bảy ngày liên tiếp chênh ít nhất 25% so với trung vị của mười bốn ngày trước đó. Ở mỗi ngày như vậy tôi ghi lời giải thích: triển khai, cập nhật của Google, sự cố, thay đổi cách đo hoặc “chưa rõ nguyên nhân”. Mô tả các ngày chỉ cho ra giả thuyết, còn nguyên nhân tôi chỉ nêu sau khi kiểm tra các cách giải thích khác.

Bước 4. Từ khóa và kết quả Google trước kỹ thuật

Trước hết tôi tìm cơ hội, sau đó mới sửa lỗi. Một phần vấn đề kỹ thuật chỉ đánh giá được trong bối cảnh từ khóa: bộ lọc trong cửa hàng có nên được lập chỉ mục không, tag có xứng đáng có trang riêng không, hai trang có thật sự cạnh tranh cùng một thứ không. Trong danh mục, 32 loại vấn đề được đánh dấu là không đánh giá được nếu thiếu phân tích từ khóa và kết quả Google.

Thiếu trang cho một từ khóa quan trọng là một trong những vấn đề khá hay gặp trong các audit của tôi: 15 trên 63 audit, ở 14 trên 50 website. Crawler tự nó sẽ không báo cáo, vì nó chỉ tải các trang tồn tại. Chỉ thấy được khi tôi đối chiếu nhu cầu với danh sách địa chỉ và với việc các trang của đối thủ xuất hiện trong kết quả.

Bước 5. Rà soát theo danh mục có điều kiện ưu tiên

Cùng một lỗi có mức ưu tiên cao hay thấp tùy vào nơi nó xuất hiện. Link nội bộ đến địa chỉ có chuyển hướng trong template lặp lại trên hàng nghìn trang có mức ưu tiên cao. Cùng link đó trong nội dung của một bài có mức ưu tiên trung bình, còn trong các bài cũ trong kho lưu trữ thì thấp.

Mỗi loại vấn đề trong danh mục có quy tắc phát hiện, điều kiện báo cáo, bằng chứng bắt buộc, mức ưu tiên kèm điều kiện và cách kiểm tra sau khi triển khai. Trong 256 loại, 86 loại bắt đầu quy tắc ưu tiên bằng “cao”, nhưng hầu như luôn kèm điều kiện: khi từ khóa có nhu cầu, khi trang có traffic, khi lỗi nằm trong template.

Vì vậy điểm sức khỏe website từ công cụ không quyết định các ưu tiên. Công cụ đếm lỗi, chứ không đếm traffic phụ thuộc vào chúng. Khuyến nghị về các trang chưa rõ traffic sẽ không được ưu tiên cao cho đến khi tôi kiểm tra dữ liệu.

Bước 6. Bằng chứng ở mỗi vấn đề

Vấn đề không có bằng chứng ở lại trong audit dưới dạng “cần kiểm tra”, chứ không phải khuyến nghị. Bằng chứng là ảnh chụp chỗ trong mã hoặc HTML từ máy chủ đặt cạnh phiên bản sau khi chạy JavaScript. Nó cũng có thể là biểu đồ từ Search Console hoặc phép đo tốc độ kèm tên phần tử làm chậm. Phần tử làm chậm quá trình tải hoặc làm dịch chuyển bố cục trang tôi gọi theo đúng như phép đo chỉ ra, chứ không theo cách phù hợp với giả thuyết của tôi.

Mỗi vấn đề tôi mô tả bốn phần, từ vấn đề đến việc kiểm tra sửa lỗi. Tôi viết vấn đề là gì, vì sao nó gây hại và ảnh hưởng đến cái gì, cách sửa từng bước và chúng ta sẽ kiểm tra thế nào rằng việc sửa có hiệu quả. Mã cần sửa tôi sao chép từ website nguyên văn, để lập trình viên thấy chính xác chỗ cần thay đổi.

Đây là một báo cáo ngắn về link dẫn đến chuyển hướng:

• Vấn đề: link trong menu dẫn đến địa chỉ không có dấu gạch chéo ở cuối, và địa chỉ đó chuyển hướng sang phiên bản có dấu gạch chéo.
• Vì sao gây hại: menu có trên mọi trang, nên mỗi lần nhấp và mỗi lần bot tải đều đi qua một chuyển hướng thừa. Trong báo cáo của công cụ, hàng nghìn link như vậy khiến việc tìm ra các lỗi quan trọng hơn trở nên khó khăn.
• Cách sửa: trong template menu thay các địa chỉ bằng địa chỉ đích, kèm đoạn mã trước và sau thay đổi.
• Kiểm tra: sau khi triển khai, crawl không còn cho thấy link đến địa chỉ có chuyển hướng trong template.

Bước 7. Thứ tự, khối lượng công việc và các phương án

Kết quả của audit là thứ tự, chứ không phải số lượng phát hiện. Ở đầu tài liệu là bảng tất cả các vấn đề kèm mức ưu tiên và khối lượng công việc. Khối lượng tôi mô tả theo bốn loại: vài giờ, một hai ngày, một tuần hoặc cả dự án. Đội ngũ có nguồn lực hạn chế nhận được phương án tối thiểu bên cạnh phương án đầy đủ, kèm mô tả rõ họ mất gì khi chọn con đường ngắn hơn.

Triển khai đi đúng theo audit. Nếu khi báo giá triển khai xuất hiện phương án rẻ hơn, khách hàng là người chọn và tôi ghi lại điều đó thẳng thắn, chứ không thay khuyến nghị mà họ không biết.

Bước 8. Kiểm tra chéo và kiểm tra sau triển khai

Trước khi audit đến tay khách hàng, một người không viết nó sẽ kiểm tra. Tôi làm hai vòng kiểm tra: vòng đầu trên toàn bộ tài liệu, vòng hai chỉ trên những gì thay đổi sau vòng đầu. Việc kiểm tra tính lại các con số từ đầu và tìm những luận điểm không thể bảo vệ bằng bằng chứng. Cuối cùng chính tôi kiểm tra các ưu tiên và luận điểm phụ thuộc vào tình huống của khách hàng.

Sau khi triển khai, tôi kiểm tra từng vấn đề trên website đang hoạt động và đánh dấu là triển khai đúng, triển khai một phần hoặc chưa triển khai. Việc kiểm tra này nằm trong giá của audit. Thiếu bước này thì audit dừng ở tài liệu, chứ không đến thay đổi trên website.

Tôi kiểm tra gì trong audit kỹ thuật?

Trong audit kỹ thuật tôi đi qua hơn chục lĩnh vực, và các vấn đề thường được báo cáo nhất nằm ở chuyển hướng, kiến trúc website và nội dung. Cột cuối cho biết có bao nhiêu trong số 63 audit lưu trữ ghi nhận ít nhất một vấn đề thuộc lĩnh vực đó. Cột “Tôi kiểm tra gì” đưa ra ví dụ, chứ không phải toàn bộ phạm vi lĩnh vực. Bảng cho thấy một số lĩnh vực chọn lọc, còn danh mục chia vấn đề thành 22 lĩnh vực.

Vấn đề hiếm khi được báo cáo không nhất thiết hiếm khi xảy ra. Tốc độ và JavaScript có ít báo cáo trong bảng này, nhưng các audit trong kho có phạm vi khác nhau. Vì vậy số báo cáo thấp không cho biết các vấn đề đó xuất hiện trên website thường xuyên đến đâu.

Làm thế nào để kiểm tra việc lập chỉ mục của website?

Việc lập chỉ mục tôi kiểm tra trên ba danh sách: cái gì có trong sitemap, cái gì Google đã lập chỉ mục và cái gì crawler tìm thấy qua link. Sự chênh lệch giữa ba danh sách này cho thấy vấn đề tốt hơn từng danh sách riêng. Sitemap có các địa chỉ trả về chuyển hướng, lỗi hoặc bị loại khỏi chỉ mục được báo cáo trong 20 trên 63 audit, ở 18 trên 50 website. Với từng địa chỉ riêng lẻ tôi dùng công cụ kiểm tra URL trong Search Console, công cụ này cũng cho thấy trang sau khi chạy JavaScript.

Core Web Vitals có ảnh hưởng đến vị trí không?

Core Web Vitals là một phần của các hệ thống xếp hạng của Google, nhưng không thắng được mức độ phù hợp của nội dung. Google viết thẳng rằng các hệ thống xếp hạng sử dụng Core Web Vitals. Họ cũng viết rằng luôn cố hiển thị nội dung phù hợp nhất, ngay cả khi trải nghiệm trên trang kém (Google Search Central). Trong audit tôi dùng dữ liệu từ người dùng thật trong báo cáo CrUX, chứ không dùng một phép thử trong công cụ phòng thí nghiệm. Nơi nào Google có dữ liệu như vậy cho từng loại trang, tôi nêu riêng. Chỗ thiếu dữ liệu tôi mô tả trong audit. Từ ngày 12 tháng 3 năm 2024, thước đo độ phản hồi của trang là INP, thay thế FID (web.dev).

Tôi hay tìm thấy những lỗi nào trong các audit SEO?

Các lỗi lặp lại nhiều nhất là lỗi kỹ thuật cơ bản, tức loại mà công cụ dễ phát hiện: link đến chuyển hướng và đến lỗi 404, sitemap có địa chỉ sai, và tiêu đề cùng mô tả trang bị trùng. Link nội bộ đến địa chỉ có chuyển hướng xuất hiện trong 24 trên 63 audit, ở 20 trên 50 website. Công cụ phát hiện chúng tốt, còn chi phí sửa phụ thuộc vào template và hệ thống của website.

Các vấn đề cấu trúc ít được báo cáo hơn có thể ảnh hưởng đến traffic nhiều hơn các lỗi kỹ thuật cơ bản. Việc thiếu trang cho các từ khóa quan trọng được báo cáo trong 15 trên 63 audit, và cũng từng ấy audit ghi nhận blog không có link đến các trang giới thiệu sản phẩm, dịch vụ và các trang danh mục. Danh mục cho trang còn thiếu mức ưu tiên cao khi từ khóa có nhu cầu và đối thủ giữ vị trí bằng các trang riêng. Blog không có link được ưu tiên cao khi các trang đích có traffic hoặc doanh thu và blog có uy tín. Những điều kiện này tôi kiểm tra trên dữ liệu trước khi gán mức ưu tiên.

• 938phát hiện trong 63 audit ở 50 website, từ đó tôi xây dựng danh mục 256 loại vấn đềKho audit 2020-2026, danh mục ngày 11/10/2026
• 38%số audit có link nội bộ đến địa chỉ có chuyển hướng, vấn đề được báo cáo nhiều nhất trong kho (24 trên 63)Danh mục ngày 11/10/2026
• 15 trên 63số audit thiếu trang cho các từ khóa quan trọng, điều mà crawler tự nó không báo cáoDanh mục ngày 11/10/2026
• 14loại khuyến nghị mà danh mục hiện đánh dấu là lỗi thời, và 30 loại tiếp theo là thực hành đã thay đổiDanh mục ngày 11/10/2026

Các audit SEO đã thay đổi thế nào kể từ năm 2020?

Trong các audit 2023-2026, dữ liệu có cấu trúc và phân trang xuất hiện thường xuyên hơn so với 2020-2022, còn chuyển hướng, địa chỉ canonical và lập chỉ mục thì ít hơn. Vấn đề với dữ liệu có cấu trúc được báo cáo trong 23 trên 33 audit mới hơn so với 16 trên 30 audit cũ hơn. Chuyển hướng và mã phản hồi: 23 trên 33 so với 27 trên 30. Việc chặn bot AI chỉ xuất hiện trong các audit từ năm 2026. Năm của audit là ngày của file trong kho, nên không phải lúc nào cũng là năm thực hiện công việc.

Mức giảm không chứng minh rằng vấn đề chuyển hướng đã biến mất. Thành phần của các audit đã thay đổi: các audit mới hơn thường nói về dữ liệu có cấu trúc, nội dung và khả năng hiển thị trong AI, và cách làm việc cũng đã thay đổi. Biểu đồ cho thấy các audit đã làm gì, chứ không phải các website ở Ba Lan đã thay đổi ra sao.

Những khuyến nghị SEO nào ngày nay đã lỗi thời?

Một số khuyến nghị vẫn xuất hiện trong audit và hướng dẫn, dù ngày nay không nên triển khai. Một phần trong số đó từng hiệu quả vài năm trước, một phần Google đã khuyên không dùng hoặc bỏ qua từ lâu. Trong bảng, ở mỗi thực hành tôi nêu lý do và việc nên làm thay thế.

Nguồn cho bảng: Google về phân trang, Google về năm lỗi với rel=canonical, Google về kết quả FAQ và HowTo, Matt Cutts về nofollow và phân bổ sức mạnh link, John Mueller về chuyển hướng về trang chủ, theo Search Engine Roundtable, Google về robots.txt, Google về các quy tắc không được hỗ trợ trong robots.txt, Google về sitemap, Google về các trường lastmod, changefreq và priority, web.dev về INP, Google về ô tìm kiếm trong kết quả.

Vì vậy mỗi khuyến nghị trong danh mục của tôi có trường về tính cập nhật kèm lý do. Danh mục hiện đánh dấu 14 loại khuyến nghị là lỗi thời và 30 loại là thực hành đã thay đổi. Khuyến nghị đúng vài năm trước sẽ không vào audit chỉ vì ngày xưa nó hiệu quả.

Làm thế nào để kiểm tra quyền truy cập của bot AI trong audit?

Quyền truy cập của bot AI tôi kiểm tra trong cùng bước với quyền truy cập của Googlebot, vì cùng một thiết lập tường lửa hoặc CDN có thể chặn chúng. CDN là mạng máy chủ trung gian, ví dụ Cloudflare. Vào tháng 9 năm 2026 tôi kiểm tra 12 tên miền của khách hàng chạy sau Cloudflare. Chỉ riêng file robots.txt cho thấy:

• 3 tên miền chặn cùng một bộ bảy bot thu thập dữ liệu để huấn luyện mô hình, với danh sách tên giống hệt nhau. Danh sách giống hệt gợi ý một nguồn chung, ví dụ thiết lập có sẵn trong bảng điều khiển Cloudflare. Từ bên ngoài không thấy thiết lập này, nên cần xác nhận ngay trong bảng điều khiển.
• 1 tên miền chặn các bot tải trang để trả lời trong ChatGPT, Perplexity và Claude. Nó không làm vậy trực tiếp, mà bằng quy tắc chung cho mọi bot không được nêu tên. Cũng tên miền đó hiển thị cho GPTBot trang bảo vệ không có thẻ noindex, tức thẻ loại trang khỏi chỉ mục. Nếu bot lập chỉ mục nhận trang như vậy, vào chỉ mục có thể là trang chặn thay vì nội dung.
• 8 tên miền không có chặn nào trong robots.txt.

Bạn quyết định riêng về quyền truy cập của bot tải trang để trả lời và bot thu thập dữ liệu để huấn luyện. Trong bài về AI SEO tôi mô tả cách phân biệt chúng. Từ ngày 31 tháng 8 năm 2026 còn có một thiết lập riêng trong Search Console loại website khỏi AI Overview, Chế độ AI và các tính năng tạo sinh trong Discover. Theo Google nó không ảnh hưởng đến phần còn lại của kết quả tìm kiếm (Trợ giúp Search Console). Thiết lập như vậy tôi kiểm tra trong audit giống như robots.txt, vì ai đó có thể đã bật nó mà người phụ trách SEO không biết. Còn việc sau khi mở quyền truy cập thương hiệu có xuất hiện trong câu trả lời không là một phép đo riêng, mà tôi mô tả trong bài về khả năng hiển thị thương hiệu trong AI.

Phép kiểm tra từ một địa chỉ IP chỉ cho thấy một phần tình hình, và bản thân nó có thể gây báo động giả. Trong cùng đợt rà soát, một loạt yêu cầu đã báo cáo việc chặn do vượt giới hạn ở hai tên miền. Việc chặn đó do chính các yêu cầu trước đó của tôi gây ra. Lần kiểm tra vài phút sau, với một mã định danh bot và các yêu cầu đơn lẻ, cho năm và bảy phản hồi đúng liên tiếp. Nếu không có lần kiểm tra đó, hai khách hàng đã nhận thông tin về việc chặn không hề có. Chỉ log máy chủ mới cho thấy ChatGPT có thật sự tải trang không. Trong bài về file llms.txt tôi cho thấy log website của tôi thể hiện gì.

Mã 200 không có nghĩa là bot đã nhận được nội dung. Ở một khách hàng có ứng dụng JavaScript, Googlebot và Bingbot nhận HTML hoàn chỉnh từ dịch vụ prerender, còn bot của các trợ lý AI nhận trang trống. Dịch vụ nhận ra bot theo tên và không có bot AI trong danh sách. Phép kiểm tra của tôi cho kết quả “ổn”, vì nó đo mã phản hồi chứ không đo nội dung. Từ đó tôi so sánh nội dung bot nhận được với nội dung sau khi chạy JavaScript trong trình duyệt.

Audit SEO miễn phí có đủ không?

Công cụ miễn phí sẽ cho danh sách lỗi, nhưng từ báo cáo đó không biết lỗi nào làm bạn mất traffic. Với cụm “audyt seo” (audit SEO) trên Google Ba Lan, 7 trong 9 kết quả tự nhiên ở trang đầu là công cụ hoặc lời mời audit miễn phí (kết quả ngày 17 tháng 10 năm 2026). Báo cáo như vậy đếm lỗi theo quy tắc của công cụ, chứ không theo việc bao nhiêu traffic và doanh thu phụ thuộc vào chúng. Cũng cần kiểm tra xem kết quả có đến từ việc chặn bot không, như trường hợp cửa hàng có điểm sức khỏe bằng 0.

Bạn làm được nhiều việc miễn phí nếu biết nhìn vào đâu. Search Console cho thấy dữ liệu của Google về lập chỉ mục, Core Web Vitals và trang sau khi chạy JavaScript. Bản miễn phí của Screaming Frog duyệt tới 500 địa chỉ trong một lần crawl (Screaming Frog), đủ cho một website công ty nhỏ. Audit cùng chuyên gia tư vấn có ý nghĩa khi lỗi tốn kém (chuyển đổi website, traffic giảm, cửa hàng lớn) hoặc khi bạn không có thời gian tổng hợp và đánh giá dữ liệu.

ChatGPT có làm được audit SEO không?

ChatGPT hay bất kỳ mô hình AI nào khác không tự làm được audit đầy đủ, vì nó không nhìn thấy website như bot của công cụ tìm kiếm. Thường nó thấy website qua một công cụ tải trang và chuyển thành văn bản. Mô hình đọc dữ liệu bạn đưa và đề xuất cần kiểm tra gì. Tuy vậy công cụ tải trang có thể làm mất một phần website: vào tháng 9 năm 2026 tôi kiểm tra và thấy công cụ tải trang trong Claude Code cắt bỏ dữ liệu có cấu trúc khi chuyển trang thành văn bản. Mô hình trả lời rằng không có thông tin, dù nó nằm trong thẻ trên cùng trang. Audit làm theo cách đó sẽ báo cáo thiếu dữ liệu có cấu trúc mà thực tế không thiếu. Trong quy trình của tôi, AI là công cụ, chủ yếu để tổng hợp dữ liệu từ crawl, Search Console và các nguồn khác. Phạm vi, đánh giá và ưu tiên tôi tự xác định.

Audit SEO tốn bao nhiêu?

Audit tôi tính như tư vấn: 70 EUR mỗi giờ làm việc (chưa gồm thuế), với giới hạn trên về số giờ được thống nhất trước khi bắt đầu. Số giờ phụ thuộc vào những gì cần kiểm tra:

• audit chẩn đoán, tức một hoặc hai vấn đề cụ thể (traffic giảm, chuyển đổi website, lập chỉ mục), thường là 10-16 giờ, tức 700-1.120 EUR (chưa gồm thuế);
• audit đầy đủ kèm thứ tự hành động thường là 32-50 giờ, tức 2.240-3.500 EUR (chưa gồm thuế);
• website nhỏ đến 500 địa chỉ gần giới hạn dưới, còn cửa hàng có hàng nghìn địa chỉ và bộ lọc gần giới hạn trên;
• các phiên bản ngôn ngữ thường thêm 3-5 giờ, còn khủng hoảng đang diễn ra cần chẩn đoán thì thêm 4-8 giờ.

Trong giá có phân tích, báo cáo kèm khuyến nghị, buổi họp để thảo luận nó và kiểm tra sau khi triển khai. Việc triển khai do đội ngũ của bạn làm, hoặc tôi báo giá riêng.

Không có quyền truy cập Search Console, bảng điều khiển CDN và hosting thì tôi không kiểm tra đầy đủ phần kỹ thuật được, và tôi nói điều đó trước khi báo giá. Khi đó tôi nêu rõ những gì tôi không xác minh được nếu thiếu các quyền này và thu hẹp phạm vi tương ứng. Trong bài về tư vấn SEO tôi mô tả khi nào thay cho audit chỉ cần một buổi trao đổi về một quyết định.

Câu hỏi thường gặp về audit SEO

Nên bắt đầu từ đâu?

Hãy bắt đầu từ một câu hỏi: website đang mất traffic hay chưa xây dựng được traffic. Từ câu trả lời mà biết trước hết bạn bảo vệ các trang đang có vị trí hay tìm các từ khóa còn thiếu trang. Sau đó làm ba phép kiểm tra miễn phí từ câu trả lời về việc tự audit: robots.txt, báo cáo lập chỉ mục trong Search Console và crawl bằng bản miễn phí của Screaming Frog. Nếu kết quả làm bạn bất ngờ hoặc bạn không biết nên sửa gì trước, đó là chủ đề phù hợp để tư vấn.