Technical SEO audit là quá trình kiểm tra các yếu tố kỹ thuật của website (khả năng crawl, index, cấu trúc URL, tốc độ, di động, bảo mật, dữ liệu có cấu trúc) để tìm lỗi cản trở công cụ tìm kiếm và bot AI truy cập, hiểu và xếp hạng nội dung. Bài này là checklist technical SEO audit theo thứ tự ưu tiên, kèm ngưỡng số liệu từ tài liệu chính thức của Google, công cụ cần dùng, cách phân loại mức độ lỗi và bảng quy trình một buổi audit thực tế.
Mục lục
- Technical SEO audit là gì và khi nào cần làm?
- Chuẩn bị trước khi audit
- 1. Crawlability và indexability
- 2. Cấu trúc website và URL
- 3. Tốc độ và Core Web Vitals
- 4. Thân thiện với di động
- 5. Dữ liệu có cấu trúc và tín hiệu on-page
- 6. Bot AI và khả năng được trích dẫn
- Công cụ audit
- Quy trình audit từng bước
- Lỗi phổ biến và cách ưu tiên sửa
- Khi nào nên và không nên tự audit?
- Câu hỏi thường gặp
- Nguồn tham khảo
Technical SEO audit là gì và khi nào cần làm?
Trước khi đầu tư vào nội dung, backlink hay AEO, nền móng kỹ thuật phải vững. Technical SEO audit là bước đầu tiên của hầu hết chiến lược SEO nghiêm túc: nếu Google không crawl hoặc index được trang, nội dung tốt đến đâu cũng không có cơ hội xếp hạng.
| Thời điểm | Lý do cần audit |
|---|---|
| Website mới ra mắt hoặc vừa thiết kế lại | Bắt lỗi trước khi Google index bản lỗi |
| Sau khi chuyển domain, đổi cấu trúc URL, đổi CMS | Redirect sai là nguyên nhân tụt thứ hạng phổ biến nhất |
| Traffic tự nhiên giảm đột ngột | Loại trừ nguyên nhân kỹ thuật trước khi nghi thuật toán |
| Định kỳ | Website nhỏ – vừa: khoảng mỗi quý; website lớn: crawl tự động hằng tháng |
| Trước khi làm chiến dịch nội dung lớn | Tránh đổ công vào trang không được index |
Chuẩn bị trước khi audit
- Quyền truy cập: Google Search Console (quyền chủ sở hữu hoặc đầy đủ), Google Analytics, quyền xem file robots.txt và cấu hình CMS. Nếu có, xin thêm quyền xem log máy chủ.
- Danh sách trang quan trọng: trang dịch vụ, trang sản phẩm, bài viết kéo traffic. Đây là nhóm cần đúng 100% trước khi sửa phần còn lại.
- Dữ liệu nền: lưu traffic tự nhiên, số trang được index, điểm Core Web Vitals hiện tại để so sánh sau khi sửa.
- Môi trường: xác định website dùng CMS nào (WordPress, Haravan, code riêng) vì cách sửa mỗi loại khác nhau.
1. Crawlability và indexability
Đây là nhóm quan trọng nhất: bot phải vào được trang và trang phải được phép vào chỉ mục.
| Hạng mục | Cần kiểm tra | Cách kiểm tra |
|---|---|---|
| robots.txt | Không chặn thư mục hoặc tài nguyên quan trọng (CSS, JS, trang dịch vụ) | Mở /robots.txt, dùng báo cáo robots.txt trong Search Console |
| noindex | Trang cần xếp hạng không có thẻ noindex (cả meta robots và header X-Robots-Tag) | Công cụ Kiểm tra URL, crawl bằng Screaming Frog |
| XML Sitemap | Chỉ chứa URL chuẩn, trả mã 200, đã gửi lên Search Console | Báo cáo Sitemap trong Search Console |
| Canonical | Mỗi trang trỏ canonical đúng, không trỏ sang trang lỗi | Crawl, lọc cột Canonical |
| Mã trạng thái | Trang quan trọng trả 200; không có 5xx; số 404 và chuỗi redirect được xử lý | Crawl toàn site, báo cáo Lập chỉ mục trang |
| Crawl budget | Không để bot mất công ở URL tham số, trang lọc, trang tìm kiếm nội bộ | Phân tích log hoặc báo cáo Thống kê thu thập dữ liệu |
Lưu ý quan trọng: theo tài liệu của Google, robots.txt chỉ quản lý việc thu thập dữ liệu, không phải cách ẩn trang khỏi kết quả tìm kiếm. Một URL bị chặn bằng robots.txt vẫn có thể xuất hiện nếu có trang khác trỏ đến. Muốn loại trang khỏi chỉ mục, hãy dùng noindex hoặc xóa/khóa truy cập, và đừng chặn đồng thời trong robots.txt vì bot sẽ không đọc được thẻ noindex.
Báo cáo “Lập chỉ mục trang” trong Search Console (trước đây gọi là Coverage) cho biết vì sao một trang chưa được index: “Đã phát hiện – hiện chưa được lập chỉ mục”, “Đã thu thập dữ liệu – hiện chưa được lập chỉ mục”, “Trang trùng lặp”, “Được chọn canonical khác”… Mỗi lý do có cách xử lý khác nhau, nên đọc nhóm lỗi trước khi sửa từng URL.
Xem thêm hướng dẫn riêng về robots.txt và sitemap XML.
2. Cấu trúc website và URL
- URL ngắn, rõ nghĩa, không chứa mã phiên (session ID) hoặc quá nhiều tham số.
- Breadcrumb đầy đủ và nhất quán với cấu trúc danh mục.
- Trang quan trọng nằm trong khoảng 3 lần nhấp từ trang chủ.
- Liên kết nội bộ hợp lý, anchor text mô tả; xem internal linking.
- Không có trang mồ côi (orphan page): trang tồn tại nhưng không có liên kết nội bộ nào trỏ tới.
- Một phiên bản duy nhất của domain: http/https, có/không www, có/không dấu gạch chéo cuối đều chuyển hướng 301 về một dạng.
Cách tìm trang mồ côi: so danh sách URL trong sitemap với danh sách URL crawl được từ trang chủ; URL có trong sitemap nhưng bot không tìm thấy qua liên kết nội bộ là ứng viên. Với site lớn, kết hợp dữ liệu Search Console và log máy chủ.
3. Tốc độ và Core Web Vitals
Google công bố ba chỉ số Core Web Vitals, đo ở phân vị thứ 75 của lượt tải trang, tách riêng di động và máy tính. Ngưỡng “tốt” theo tài liệu web.dev:
| Chỉ số | Đo cái gì | Ngưỡng tốt |
|---|---|---|
| LCP (Largest Contentful Paint) | Tốc độ hiển thị nội dung lớn nhất | Trong 2,5 giây |
| INP (Interaction to Next Paint) | Độ phản hồi khi người dùng tương tác | 200 mili giây trở xuống |
| CLS (Cumulative Layout Shift) | Độ ổn định bố cục | 0,1 trở xuống |
TTFB (thời gian đến byte đầu tiên) không phải Core Web Vitals, nhưng nếu quá chậm sẽ kéo LCP xuống. Theo web.dev, TTFB 0,8 giây trở xuống được coi là tốt, từ 0,8 đến 1,8 giây cần cải thiện, trên 1,8 giây là kém; đây chỉ là mốc tham khảo.
| Vấn đề | Nguyên nhân hay gặp | Cách xử lý |
|---|---|---|
| LCP cao | Ảnh hero quá nặng, máy chủ chậm, CSS/JS chặn hiển thị | Nén ảnh (WebP/AVIF), ưu tiên tải ảnh chính, dùng CDN và cache, hoãn JS không cần thiết |
| INP cao | JavaScript chạy lâu, plugin nặng, script bên thứ ba | Giảm script, chia nhỏ tác vụ dài, bỏ plugin không dùng |
| CLS cao | Ảnh/quảng cáo/iframe không khai báo kích thước, font tải muộn | Đặt width/height, giữ chỗ cho quảng cáo, tối ưu font |
| TTFB chậm | Hosting yếu, thiếu cache, truy vấn CSDL nặng | Nâng cấp hosting, bật cache trang và OPcache, tối ưu truy vấn |
Hãy ưu tiên dữ liệu thực tế từ người dùng (báo cáo Core Web Vitals trong Search Console, hoặc dữ liệu thực địa trong PageSpeed Insights) hơn điểm số thử nghiệm trong phòng lab. Chi tiết xem thêm bài Core Web Vitals.
4. Thân thiện với di động
Google dùng chỉ mục ưu tiên thiết bị di động, nghĩa là bản di động của trang là bản chính để lập chỉ mục. Kiểm tra:
- Nội dung, liên kết, dữ liệu có cấu trúc và thẻ meta ở bản di động giống bản máy tính.
- Giao diện responsive, thẻ viewport đúng.
- Vùng chạm đủ lớn, khoảng cách giữa các nút hợp lý (mốc thường dùng khoảng 48px).
- Không có popup che toàn bộ nội dung ngay khi vào trang.
- Thử trên điện thoại thật và dùng chế độ giả lập trong Chrome DevTools.
Lưu ý: công cụ “Mobile-Friendly Test” độc lập của Google đã ngừng, nên đừng đưa nó vào checklist nữa. Hãy dùng Lighthouse trong Chrome DevTools, PageSpeed Insights và kiểm tra trực tiếp trên thiết bị.
5. Dữ liệu có cấu trúc và tín hiệu on-page
| Hạng mục | Cần kiểm tra |
|---|---|
| Schema (JSON-LD) | Dùng loại phù hợp (Organization, Article, Product, BreadcrumbList…), hợp lệ trong Rich Results Test, khớp nội dung hiển thị |
| Thẻ title và meta description | Duy nhất cho mỗi trang, mô tả đúng nội dung |
| Thẻ H1 | Một H1 rõ nghĩa mỗi trang, heading phân cấp hợp lý |
| Văn bản thay thế của ảnh (alt) | Mô tả ngắn, đúng nội dung ảnh |
| HTTPS | Toàn site dùng HTTPS, không còn mixed content, chứng chỉ còn hạn |
| Hreflang (nếu nhiều ngôn ngữ) | Cặp liên kết hai chiều, mã ngôn ngữ đúng |
Schema không phải nút bật xếp hạng. Google nói dữ liệu có cấu trúc giúp họ hiểu nội dung và có thể đủ điều kiện hiển thị kết quả nâng cao; đánh dấu thông tin không có thật trên trang có thể bị xử lý thủ công. Xem thêm schema markup và SEO onpage.
6. Bot AI và khả năng được trích dẫn
Các công cụ AI tìm kiếm cũng cần truy cập nội dung của bạn. Trong audit, hãy kiểm tra:
- robots.txt có chặn bot của các nhà cung cấp AI hay không (mỗi nhà cung cấp có tên user-agent riêng, ví dụ GPTBot của OpenAI; hãy đọc tài liệu chính thức của từng bên). Chặn bot huấn luyện nhưng cho phép bot tìm kiếm là lựa chọn có chủ đích, không phải mặc định.
- Nội dung quan trọng có nằm trong HTML gốc hay chỉ xuất hiện sau khi JavaScript chạy. Nhiều crawler không chạy JavaScript đầy đủ.
- Câu trả lời trực tiếp ở đầu trang, tiêu đề dạng câu hỏi, bảng và danh sách rõ ràng giúp trích dẫn dễ hơn.
- Thông tin tác giả, ngày cập nhật, nguồn tham khảo (tín hiệu E-E-A-T).
- Tệp llms.txt là đề xuất cộng đồng, chưa phải tiêu chuẩn được các nền tảng cam kết hỗ trợ; xem llms.txt nếu muốn thử, nhưng đừng coi nó là điều kiện bắt buộc.
Công cụ audit
| Công cụ | Dùng để | Chi phí |
|---|---|---|
| Google Search Console | Lập chỉ mục trang, Core Web Vitals, sitemap, lỗi thu thập, hành động thủ công | Miễn phí |
| Screaming Frog SEO Spider | Crawl toàn site, tìm liên kết hỏng, chuỗi redirect, trùng lặp, thiếu canonical | Có bản miễn phí giới hạn số URL, bản trả phí theo năm |
| Semrush Site Audit | Quét theo lịch, theo dõi lỗi theo thời gian | Trả phí theo tháng, tùy gói |
| Ahrefs Site Audit | Crawl, điểm sức khỏe, ưu tiên lỗi | Trả phí theo tháng, tùy gói |
| PageSpeed Insights / Lighthouse | Core Web Vitals, gợi ý tăng tốc | Miễn phí |
| Rich Results Test | Kiểm tra dữ liệu có cấu trúc | Miễn phí |
| GTmetrix | Biểu đồ waterfall, phân tích tải tài nguyên | Có bản miễn phí, bản trả phí theo tháng |
Quy trình audit từng bước
- Crawl toàn site bằng Screaming Frog: xuất toàn bộ URL, mã trạng thái, title, meta, canonical, độ sâu.
- Đối chiếu Search Console: báo cáo Lập chỉ mục trang, sitemap, hành động thủ công, vấn đề bảo mật.
- Audit Core Web Vitals: trang chủ và 5-10 trang đích quan trọng, tách di động và máy tính.
- Kiểm tra di động bằng Lighthouse và thiết bị thật.
- Kiểm tra dữ liệu có cấu trúc bằng Rich Results Test cho mọi loại schema đang dùng.
- Kiểm tra trùng lặp: canonical, tham số URL, trang phân trang, phiên bản http/https, www.
- Kiểm tra bảo mật: SSL, chuyển hướng HTTPS, mixed content.
- Kiểm tra liên kết ngoài và backlink bất thường bằng Ahrefs hoặc Semrush. Chỉ xử lý khi có dấu hiệu rõ ràng (ví dụ hành động thủ công trong Search Console hoặc đợt liên kết spam bất thường).
- Phân tích log (nếu có quyền): xem Googlebot thực sự crawl gì, bao nhiêu lần, có tốn công vào URL vô ích không.
- Phân loại và lập kế hoạch sửa: gắn mức Nghiêm trọng, Cao, Trung bình, Thấp; ghi người chịu trách nhiệm và hạn.
Lỗi phổ biến và cách ưu tiên sửa
| Lỗi | Mức độ | Cách sửa |
|---|---|---|
| Trang quan trọng bị noindex hoặc bị chặn robots.txt | Nghiêm trọng | Bỏ noindex, mở chặn, gửi lại URL để Google xử lý |
| Trang quan trọng trả 404/5xx | Nghiêm trọng | Khôi phục trang hoặc chuyển hướng 301 sang trang liên quan nhất |
| Chuỗi redirect, redirect về trang chủ hàng loạt | Cao | Chuyển hướng thẳng tới URL đích; tránh dồn mọi URL cũ về trang chủ |
| Thiếu hoặc sai canonical, nội dung trùng | Cao | Khai báo canonical đúng, gộp nội dung trùng |
| Title/meta trùng lặp trên nhiều trang | Trung bình – Cao | Viết title, meta duy nhất cho từng trang |
| LCP, INP hoặc CLS ngoài ngưỡng | Cao | Tối ưu ảnh, giảm JS, đặt kích thước phần tử |
| Liên kết nội bộ hỏng | Trung bình | Sửa URL hoặc cập nhật liên kết |
| Thiếu alt ảnh, thiếu H1 | Thấp – Trung bình | Bổ sung mô tả, chuẩn hóa heading |
| Mixed content, chứng chỉ sắp hết hạn | Cao | Đổi toàn bộ tài nguyên sang HTTPS, gia hạn chứng chỉ |
Nguyên tắc ưu tiên: sửa trước những lỗi khiến trang quan trọng không được index, sau đó là lỗi ảnh hưởng nhiều trang cùng lúc (template), rồi mới đến lỗi lẻ từng trang. Một lỗi ở template có thể ảnh hưởng hàng trăm URL, nên sửa một lần hiệu quả hơn nhiều so với sửa tay từng trang.
Sai lầm thường gặp khi audit
- Chạy công cụ rồi gửi cả báo cáo 500 cảnh báo mà không phân loại, khiến đội phát triển không biết bắt đầu từ đâu.
- Sửa lỗi nhỏ (thiếu alt) trước khi sửa lỗi lớn (trang không được index).
- Chặn trang trong robots.txt để “xóa khỏi Google” rồi ngạc nhiên vì URL vẫn hiện.
- Không đo lại sau khi sửa, nên không biết thay đổi có hiệu quả không.
- Theo điểm số của một công cụ duy nhất thay vì dữ liệu thực từ Search Console.
- Tin hoàn toàn vào “điểm sức khỏe” của công cụ; điểm đó không phải chỉ số xếp hạng của Google.
Khi nào nên và không nên tự audit?
| Tình huống | Tự làm | Nên nhờ chuyên gia |
|---|---|---|
| Website nhỏ dưới vài trăm trang, dùng WordPress phổ biến | Phù hợp: dùng Search Console, PageSpeed Insights và bản miễn phí Screaming Frog | Chưa bắt buộc |
| Website thương mại điện tử nhiều bộ lọc, nhiều biến thể | Chỉ làm phần cơ bản | Nên, vì crawl budget và canonical phức tạp |
| Vừa chuyển domain hoặc thiết kế lại | Không nên làm một mình | Nên, cần kế hoạch redirect và giám sát sau chuyển |
| Traffic giảm mạnh, chưa rõ nguyên nhân | Kiểm tra sơ bộ | Nên, cần phân tích nhiều nguồn dữ liệu |
| Website dùng nhiều JavaScript (React, Vue) render phía trình duyệt | Khó | Nên, cần kiểm tra render và chỉ mục |
Vidco Group có thể hỗ trợ: nếu bạn muốn một báo cáo audit đã phân loại mức ưu tiên và danh sách việc cụ thể cho đội phát triển, xem dịch vụ SEO audit của chúng tôi. Nếu đang làm website mới, tham khảo thiết kế website chuẩn SEO, hoặc dịch vụ SEO tổng thể.
Câu hỏi thường gặp
Cần audit technical SEO bao lâu một lần?
Với website nhỏ – vừa (dưới khoảng 1.000 trang), nên audit đầy đủ khoảng mỗi quý. Website lớn nên crawl tự động hằng tháng. Luôn audit sau khi chuyển domain, thiết kế lại hoặc cập nhật lớn CMS, và xem Search Console hằng tuần để bắt lỗi nghiêm trọng.
Technical SEO quan trọng hơn Content SEO không?
Cả hai cần thiết và bổ trợ nhau. Technical SEO là điều kiện cần: nếu kỹ thuật sai, nội dung tốt cũng không được index đúng. Content là điều kiện đủ: kỹ thuật ổn nhưng nội dung kém vẫn khó xếp hạng. Nên sửa lỗi kỹ thuật nghiêm trọng trước, rồi tập trung nội dung.
Bot AI có bị ảnh hưởng bởi lỗi kỹ thuật không?
Có. Crawler của các công cụ AI cũng cần truy cập được nội dung của bạn. Chặn trong robots.txt, trang tải chậm hoặc nội dung chỉ xuất hiện sau JavaScript đều có thể khiến nội dung khó được đọc và trích dẫn. Mỗi nhà cung cấp có cách xử lý riêng, hãy xem tài liệu chính thức của họ.
Technical SEO audit gồm những gì?
Gồm sáu nhóm: crawl và index, cấu trúc website, tốc độ và Core Web Vitals, di động, dữ liệu có cấu trúc cùng tín hiệu on-page, và khả năng truy cập của bot AI. Mỗi nhóm kiểm tra bằng Search Console và công cụ crawl rồi phân loại mức độ ưu tiên.
Technical SEO audit miễn phí được không?
Được với website nhỏ: Google Search Console, PageSpeed Insights, Rich Results Test và bản miễn phí của Screaming Frog (giới hạn số URL) đủ cho phần lớn lỗi cơ bản. Công cụ trả phí hữu ích khi site lớn hoặc cần theo dõi theo thời gian.
Mất bao lâu để audit một website?
Phụ thuộc quy mô và độ phức tạp. Website nhỏ có thể xong trong một đến hai ngày làm việc; website lớn hoặc thương mại điện tử có thể lâu hơn, đặc biệt nếu cần phân tích log. Thời gian sửa lỗi thường dài hơn thời gian audit.
Sửa xong lỗi kỹ thuật bao lâu thì thấy kết quả?
Không có mốc cố định. Google cần thu thập lại và xử lý lại các trang. Với lỗi nghiêm trọng như noindex nhầm, trang có thể quay lại nhanh hơn sau khi được thu thập lại; cải thiện Core Web Vitals thường hiển thị chậm vì dữ liệu thực địa được tổng hợp theo thời gian. Hãy theo dõi bằng Search Console thay vì chờ một con số.
Lỗi nào nên sửa trước tiên?
Những lỗi khiến trang quan trọng không vào được chỉ mục: noindex nhầm, chặn robots.txt, 404 hoặc 5xx, redirect sai. Sau đó là lỗi lan trên cả template, rồi mới đến lỗi nhỏ từng trang.
Kết luận và bước tiếp theo
Technical SEO audit không phải việc làm một lần: hãy chạy audit đầy đủ mỗi quý và theo dõi Search Console hằng tuần. Trong tuần này, bạn có thể bắt đầu bằng ba việc: kiểm tra báo cáo Lập chỉ mục trang, đo Core Web Vitals của 5-10 trang quan trọng, và crawl toàn site để lọc 404, redirect và canonical. Ghi lại số liệu trước và sau khi sửa để biết điều gì thật sự có tác dụng.
Nguồn tham khảo
- Google Search Central: Giới thiệu về robots.txt
- Google Search Central: Chặn lập chỉ mục bằng noindex
- web.dev: Core Web Vitals và ngưỡng chỉ số
- web.dev: Time to First Byte (TTFB)
- Google Search Central: Giới thiệu về dữ liệu có cấu trúc
- OpenAI: Tài liệu về các bot của OpenAI
Cập nhật: tháng 10/2026.
