Chẩn Đoán Technical SEO: 10 Bước Theo Thứ Tự Của SQA-200™

Chẩn đoán Technical SEO gồm mười bước theo thứ tự nào?

Chẩn đoán Technical SEO gồm mười bước, đi từ lớp nền lên lớp trên: phiên bản tên miền, canonical, chuyển hướng, sitemap, lỗi index, mã trạng thái, trang đã render, nội dung ẩn, schema, rồi Core Web Vitals. Thứ tự này là cách làm của Danh Nolan. Lớp dưới sai thì sửa lớp trên không có tác dụng.

Mười bước trên nằm trong trụ Technical và Core Web Vitals của SQA-200™, trụ được 40 trên 200 điểm. Riêng bước 9 thuộc trụ Bảo chứng thực thể và Schema. Bản đặc tả SQA-200™ có 99 mục kiểm có trọng số, công bố trên Zenodo. Bảng chấm có trọng số và mẫu điền cho từng mục thuộc bản đầy đủ, ngoài phạm vi bài viết miễn phí.

Muốn biết trụ nào đang yếu trước khi đi từng bước, bạn làm chẩn đoán SQA-200™: công cụ tự chấm miễn phí, 15 câu theo sáu trụ cột, thang 200 điểm, ra danh sách chỗ nên sửa trước. Danh sách kiểm rộng hơn cho cả Technical, ý định tìm kiếm và chuyển đổi nằm ở checklist audit SEO website. Công cụ crawl để quét hàng loạt URL có ở Screaming Frog Mastery.

Đi đúng thứ tự từ lớp nền. Một lỗi ở bước 1 có thể làm sai kết quả của cả chín bước sau.

Bước 1: Website đã chạy một phiên bản HTTPS duy nhất chưa?

Website chạy một phiên bản duy nhất khi mọi biến thể http, https, có www và không www đều chuyển hướng vĩnh viễn về một địa chỉ HTTPS. Google gọi http và https là protocol variants, một dạng nội dung trùng lặp. Google ưu tiên bản HTTPS làm canonical, trừ khi chứng chỉ lỗi hoặc tín hiệu mâu thuẫn.

Bốn việc kiểm ở bước 1

1. Gõ đủ bốn biến thể: http://, https://, có www và không www. Ba biến thể phải chuyển hướng 301 hoặc 308 về biến thể còn lại, chỉ một biến thể trả 200.
2. Kiểm chứng chỉ SSL: chứng chỉ hết hạn hoặc sai tên miền là một trong các trường hợp Google không chọn bản HTTPS làm canonical.
3. Tìm tài nguyên http: script, CSS, iframe còn gọi qua http trên trang HTTPS là tài nguyên không an toàn. Google nêu đây là tín hiệu mâu thuẫn, trừ trường hợp chỉ có ảnh.
4. Đồng bộ link nội bộ: menu, footer, canonical và sitemap đều dùng đúng một biến thể, cùng giao thức, cùng www hay không www.

Trang How to specify a canonical URL của Google ghi: "Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals". Hai vấn đề được nêu tên là chứng chỉ SSL không hợp lệ và trang HTTPS chứa tài nguyên không an toàn.

Cách kiểm nhanh nhất là chạy lệnh curl với cờ hiện header cho từng biến thể, đọc mã trạng thái và dòng Location. Trong Search Console, bạn nên xác minh property dạng Domain để thấy số liệu của mọi biến thể trong một chỗ.

curl -sI http://example.com/
curl -sI http://www.example.com/
curl -sI https://www.example.com/
curl -sI https://example.com/

Bốn biến thể, một đích. Chỉ một địa chỉ trả 200, ba địa chỉ còn lại chuyển hướng thẳng về đó.

Bước 2: Canonical của mỗi trang đã tự trỏ về chính nó chưa?

Canonical tự trỏ là thẻ rel="canonical" đặt trên trang gốc và trỏ về chính URL của trang đó. Google khuyên đặt thẻ này trên chính trang canonical, dùng URL tuyệt đối. Thẻ canonical là gợi ý, Google vẫn có thể chọn URL khác, nên bước này kiểm cả canonical bạn khai lẫn canonical Google chọn.

Năm lỗi canonical hay gặp khi chẩn đoán

• Canonical tương đối: khai /trang-a/ thay cho https://example.com/trang-a/. Google khuyên dùng đường dẫn tuyệt đối.
• Hai tín hiệu mâu thuẫn: sitemap khai một URL, thẻ canonical khai URL khác cho cùng một trang. Google ghi rõ không nên làm vậy.
• Dùng robots.txt để gom bản trùng: Google ghi không dùng robots.txt cho canonical, vì URL bị chặn vẫn có thể vào chỉ mục mà không có nội dung.
• Dùng noindex để chọn canonical: noindex chặn hẳn trang khỏi Search. Google khuyên dùng rel="canonical" cho việc này.
• Link nội bộ trỏ vào bản trùng: menu trỏ vào URL có tham số trong khi canonical là URL sạch. Google khuyên link nội bộ trỏ thẳng vào URL canonical.

Tài liệu consolidate duplicate URLs ghi: "Do include a rel="canonical" link on the canonical page itself (also known as a self-referential canonical)." Trang What is URL canonicalization nói thêm rằng khai canonical là "a hint, not a rule".

Cách kiểm: mở URL Inspection cho trang chủ lực, so dòng User-declared canonical với dòng Google-selected canonical. Hai dòng lệch nhau là việc của bước này. Google ghi dòng canonical do Google chọn chỉ có ở kết quả đã index, phần live test không đoán được. Các tình huống canonical phức tạp hơn có ở Canonicalization Strategy.

Khai canonical đúng là việc của bạn, chọn canonical là việc của Google. Chẩn đoán đúng là đọc cả hai dòng.

Bước 3: Chuỗi chuyển hướng làm website mất gì?

Chuỗi chuyển hướng làm người dùng chờ lâu hơn và có thể đứt giữa đường, nhưng không làm mất PageRank. Google ghi chuyển hướng 301 và các chuyển hướng vĩnh viễn khác không làm mất PageRank. Googlebot đi theo tối đa 10 bước, còn Google khuyên chuyển hướng thẳng tới đích, hoặc giữ dưới 5 bước.

Nhiều checklist SEO vẫn ghi mỗi bước chuyển hướng làm mất một phần sức mạnh link. Tài liệu Site moves with URL changes của Google ghi ngược lại: "301 and other permanent redirects don't cause a loss in PageRank." Lý do thật để rút gọn chuỗi nằm ở câu sau trong cùng tài liệu: "Chaining redirects adds latency for users, and not all user agents and browsers support long redirect chains."

Google khuyên giữ chuỗi "ideally no more than 3 and fewer than 5". Cách tôi làm khi chẩn đoán: mọi link nội bộ trỏ thẳng vào URL cuối, mọi URL cũ chuyển hướng một bước tới đích. Trang Redirects and Google Search cũng ghi chuyển hướng vĩnh viễn là tín hiệu để Google chọn URL đích làm canonical. Cách dựng bảng chuyển hướng không tạo chuỗi có ở Redirect Mapping 301/308.

Rút chuỗi chuyển hướng để người dùng tới nhanh hơn và bot nào cũng đi tới đích. PageRank không phải lý do.

Bước 4: XML sitemap cần bỏ những URL nào ra?

XML sitemap cần bỏ ra mọi URL bạn không muốn thấy trong kết quả tìm kiếm. Google ghi: đưa vào sitemap những URL bạn muốn thấy trong kết quả của Google. Vậy URL chuyển hướng, URL noindex, URL lỗi và URL không phải canonical đều không nên nằm trong sitemap.

Các loại URL cần bỏ khỏi XML sitemap

• URL chuyển hướng: sitemap nên chứa URL đích, không chứa URL cũ đang trả 301 hoặc 302.
• URL noindex: khai trong sitemap rồi lại chặn bằng noindex là hai tín hiệu ngược nhau.
• URL trả 404, 410 hoặc 5xx: URL không còn nội dung thì không có lý do để Google ghé lại qua sitemap.
• URL không phải canonical: bản có tham số lọc, sắp xếp, mã theo dõi, bản in. Google ghi sitemap là tín hiệu yếu giúp chọn canonical.
• URL bị chặn trong robots.txt: Google không thu thập được nên không đọc được nội dung để index.
• Biến thể giao thức và tên miền: URL http hoặc biến thể www không phải bản chính đã chọn ở bước 1.

Tài liệu Build and submit a sitemap ghi ba điều đáng kiểm. Thứ nhất, "Include the URLs in your sitemap that you want to see in Google's search results." Thứ hai, "Google ignores <priority> and <changefreq> values." Thứ ba, Google chỉ dùng <lastmod> khi giá trị đó đúng một cách nhất quán và kiểm được.

Vậy <lastmod> nên đổi khi nội dung chính, dữ liệu cấu trúc hoặc link trên trang đổi. Đổi năm bản quyền ở footer không tính. Mỗi tệp sitemap tối đa 50MB chưa nén hoặc 50.000 URL, dùng URL tuyệt đối. Cách tạo và khai báo sitemap có ở Sitemap là gì.

Sitemap là danh sách trang bạn muốn Google xếp hạng. URL nào bạn không muốn thấy trên Google thì không có chỗ trong đó.

Bước 5: Đọc lỗi index trong Search Console thế nào?

Đọc lỗi index bằng báo cáo Page indexing: mở nhóm Not indexed, xem lý do của từng nhóm, rồi kiểm xem trang chủ lực có nằm trong đó không. Hai lý do hay gặp nhất là Crawled - currently not indexed và Discovered - currently not indexed. Google định nghĩa hai lý do này khác nhau.

Trang Page indexing report ghi về Discovered - currently not indexed: "Typically, Google wanted to crawl the URL but this was expected to overload the site", nên Google dời lịch thu thập. Với Crawled - currently not indexed, Google ghi trang "may or may not be indexed in the future", và không cần gửi lại URL để thu thập.

Google cũng ghi: "Don't expect every URL on your site to be indexed." Vậy bước này không nhằm đưa mọi URL vào chỉ mục. Việc của bạn là chắc trang chủ lực được index. Cách đọc các báo cáo khác trong công cụ có ở Google Search Console, còn bảy lỗi index và crawl thường gặp có ở Audit Index/Crawl.

Không phải URL nào cũng cần được index. Trang chủ lực nằm trong nhóm Not indexed mới là lỗi cần sửa ngay.

Bước 6: Khi nào trả 404, khi nào trả 410 hay 5xx?

Trả 404 hoặc 410 khi trang không còn và không có trang thay thế, trả 5xx chỉ khi máy chủ thật sự lỗi. Với Google, 404 và 410 được xử lý như nhau: mọi mã 4xx trừ 429 đều báo nội dung không tồn tại, URL rơi khỏi chỉ mục và tần suất thu thập giảm dần.

Lời khuyên hay gặp là dùng 410 để Googlebot không quay lại. Tài liệu How HTTP status codes affect Google's crawlers ghi: "All 4xx errors, except 429, are treated the same", và "The crawling frequency gradually decreases." Không có mã nào khiến Googlebot dừng hẳn ngay. Bạn vẫn có thể dùng 410 vì nó đúng nghĩa hơn với trình duyệt và công cụ khác.

Lỗi 5xx đáng sợ hơn. Google ghi URL đã index được giữ lại một thời gian, nhưng URL trả lỗi máy chủ kéo dài sẽ bị gỡ khỏi chỉ mục. Trang còn giá trị mà trả 404 thì nên chuyển hướng 301 về trang tương đương gần nhất. Cách phân loại broken link, soft 404 và chuỗi chuyển hướng có ở phân loại broken link.

404 hay 410 đều được, miễn là trang đã bỏ thật. Lỗi 5xx lặp lại mới là thứ làm mất trang khỏi chỉ mục.

Bước 7: Google có thấy đủ nội dung sau khi render không?

Google thấy đủ nội dung khi HTML đã render chứa toàn bộ nội dung chính của trang. Google xử lý trang JavaScript qua ba giai đoạn crawl, render, index, và dùng HTML đã render để lập chỉ mục. Cách kiểm là chạy Test live URL trong URL Inspection rồi mở View tested page.

Ba chỗ cần xem trong View tested page

1. HTML: tìm đoạn mở đầu, tiêu đề và đoạn trả lời chính. Không có trong HTML đã render thì Google không index được.
2. Screenshot: ảnh chụp trang Google-InspectionTool thấy. Google ghi ảnh này chỉ có ở live test.
3. More info: tài nguyên không tải được, thông báo lỗi JavaScript trong console. Script hoặc CSS bị chặn làm trang render thiếu.

Trang JavaScript SEO basics ghi: "If the content isn't visible in the rendered HTML, Google won't be able to index it." Google cũng khuyên render phía máy chủ hoặc dựng sẵn trang, vì "not all bots can run JavaScript." Vậy nội dung chính nên có sẵn trong HTML máy chủ trả về.

Một giới hạn cần biết: Google ghi live test "only confirms if Google-InspectionTool can access your page for indexing". Live test đạt không có nghĩa trang chắc chắn được index. Hướng dẫn dùng công cụ ở URL Inspection tool. Cách Google đọc HTML so với JavaScript có ở Indexing và Rendering, cách xử lý site nặng JavaScript có ở JavaScript SEO và Rendering.

Đừng đọc mã nguồn rồi kết luận. Đọc HTML mà Google đã render, đó mới là thứ được đem đi index.

Bước 8: Nội dung trong accordion có được Google đọc không?

Có, nếu nội dung đã nằm sẵn trong HTML khi trang tải. Google cho phép đưa nội dung vào accordion hoặc tab trên di động để tiết kiệm chỗ, miễn nội dung tương đương bản máy tính. Điều Google không làm là bấm để tải thêm: nội dung chỉ tải sau khi người dùng bấm, vuốt hay gõ thì Google không thấy.

Trang Mobile-first indexing best practices ghi: "Instead of removing content, consider moving content into accordions or tabs to save space." Cùng trang đó ghi: "Google won't load content that requires user interactions (for example, swiping, clicking, or typing) to load."

Cách kiểm ở bước này dùng lại View tested page của bước 7: tìm một câu nằm trong accordion đang đóng. Có trong HTML đã render là đạt. Lời đồn Google bỏ qua nội dung trong accordion không có trong tài liệu nào của Google. Tôi vẫn đặt đoạn trả lời chính ngoài accordion để người đọc thấy ngay.

Accordion không làm mất nội dung. Nội dung chỉ tải khi bấm mới làm mất.

Bước 9: Schema JSON-LD cần kiểm những gì khi chẩn đoán?

Schema JSON-LD cần kiểm ba điều: cú pháp hợp lệ, đủ thuộc tính bắt buộc của loại kết quả, và nội dung trong markup có thật trên trang. Google khuyên dùng JSON-LD và ghi rõ không được đánh dấu nội dung người đọc không thấy. Markup đúng vẫn không chắc được hiện kết quả nhiều định dạng.

Bốn điểm kiểm schema

• Cú pháp và thuộc tính: chạy Rich Results Test cho trang mẫu của từng loại trang, sửa mọi lỗi và cảnh báo về thuộc tính bắt buộc.
• Khớp chữ hiển thị: tên, giá, đánh giá, câu hỏi trong JSON-LD phải có trên trang. Google ghi markup mô tả người biểu diễn thì thân trang phải mô tả đúng người đó.
• Đúng loại cho đúng trang: trang dịch vụ dùng Service, bài viết dùng Article, không gắn Product cho trang không bán sản phẩm.
• Theo dõi báo cáo Enhancements: Search Console báo lỗi schema theo nhóm trang sau khi Google thu thập lại.

Trang General structured data guidelines ghi: "Don't mark up content that is not visible to readers of the page." Vi phạm có thể dẫn tới tác vụ thủ công. Google ghi khi đó trang mất điều kiện hiện kết quả nhiều định dạng, và việc đó "doesn't affect how the page ranks in Google web search."

Trang Introduction to structured data ghi Google khuyên dùng JSON-LD. Cách cài JSON-LD cho từng loại trang có ở Schema Markup. Trong SQA-200™, schema nằm ở trụ Bảo chứng thực thể, vì nó giúp máy nhận đúng doanh nghiệp và người đứng sau website.

Schema chỉ có ích khi nó nói đúng điều trang đang nói. Markup đẹp cho nội dung không có trên trang là rủi ro.

Bước 10: Core Web Vitals đạt ngưỡng nào là tốt?

Core Web Vitals đạt mức tốt khi LCP trong vòng 2,5 giây, INP từ 200 mili giây trở xuống và CLS từ 0,1 trở xuống, đo ở phân vị 75 của lượt tải trang. Ngưỡng này lấy từ web.dev. Trang đạt khi cả ba chỉ số cùng đạt, tách riêng cho di động và máy tính.

Trang Web Vitals ghi ngưỡng nên đo ở "the 75th percentile of page loads, segmented across mobile and desktop devices." Về thứ hạng, trang Understanding page experience của Google ghi "Core Web Vitals are used by our ranking systems", và cũng ghi không có một tín hiệu trải nghiệm trang duy nhất.

Tôi đặt Core Web Vitals ở bước cuối vì một lý do: tốc độ chỉ giúp được trang đã vào chỉ mục đúng URL. Định nghĩa ba chỉ số có ở Core Web Vitals là gì. Mười kỹ thuật cải thiện theo dữ liệu người dùng thật có ở bài tối ưu Core Web Vitals.

Đo Core Web Vitals bằng dữ liệu người dùng thật ở phân vị 75. Điểm Lighthouse một lần chạy không thay được số liệu đó.

Người làm chẩn đoán Technical SEO hay hỏi gì?

Người làm chẩn đoán Technical SEO hay hỏi bốn câu: bao lâu nên chẩn đoán một lần, công cụ miễn phí có đủ không, có cần sửa hết mọi cảnh báo không, và chẩn đoán xong thì sửa gì trước. Câu trả lời ngắn cho từng câu nằm ngay bên dưới, kèm căn cứ.

Bao lâu nên chẩn đoán Technical SEO một lần?

Tôi chẩn đoán đủ mười bước khi nhận một website mới, sau mỗi lần đổi giao diện, đổi URL hay chuyển máy chủ, và định kỳ mỗi quý. Giữa các lần đó, tôi xem hai báo cáo trong Search Console mỗi tuần: Page indexing cho thấy trang nào rơi khỏi chỉ mục, Core Web Vitals cho thấy nhóm URL nào chuyển sang Poor.

Công cụ miễn phí có đủ để chẩn đoán không?

Đủ cho website vừa và nhỏ. Search Console cho báo cáo Page indexing, URL Inspection, Core Web Vitals. PageSpeed Insights và Rich Results Test của Google miễn phí. Lệnh curl kiểm được mã trạng thái và chuyển hướng. Công cụ crawl trả phí chỉ cần khi website có hàng nghìn URL và bạn cần quét hàng loạt.

Có cần sửa hết mọi cảnh báo trong Search Console không?

Không. Google ghi không nên kỳ vọng mọi URL đều được index, và URL bị chặn bằng robots.txt có thể là chặn có chủ ý. Tôi sửa theo thứ tự: trang chủ lực bị loại khỏi chỉ mục trước, lỗi máy chủ lặp lại sau, rồi mới tới cảnh báo trên trang phụ.

Chẩn đoán xong nên sửa bước nào trước?

Sửa theo đúng thứ tự mười bước, từ bước 1 lên. Một lỗi phiên bản tên miền hay canonical làm Google index sai URL, khi đó tối ưu tốc độ hay schema cho URL kia không có tác dụng. Nếu chỉ có thời gian cho một việc, bạn kiểm trang chủ lực có được index đúng URL không.

Nguồn chính thức nào dùng để chẩn đoán Technical SEO?

Mọi câu trích về Google ở đây lấy từ tài liệu của chính Google: Google Search Central, tài liệu Crawling infrastructure, Search Console Help và web.dev. Tôi đọc lại toàn bộ ngày 03/10/2026. Google cập nhật các trang này thường xuyên, có trang đã đổi URL, nên đọc lại trước mỗi lần chẩn đoán lớn.

Mười bốn tài liệu gốc cho mười bước chẩn đoán

• Bước 1: What is URL canonicalization
• Bước 1 và 2: How to specify a canonical URL with rel="canonical" and other methods
• Bước 3: Site moves with URL changes
• Bước 3: Redirects and Google Search
• Bước 3 và 6: How HTTP status codes affect Google's crawlers
• Bước 4: Build and submit a sitemap
• Bước 5: Page indexing report
• Bước 7: URL Inspection tool
• Bước 7: Understand the JavaScript SEO basics
• Bước 8: Mobile-first indexing best practices
• Bước 9: General structured data guidelines
• Bước 9: Introduction to structured data markup
• Bước 10: Web Vitals
• Bước 10: Understanding page experience in Google Search results

Một câu khẳng định về Google không có trang gốc đi kèm thì chưa nên dùng để ra quyết định sửa website.

Học chẩn đoán Technical SEO trên website thật ở đâu?

Bạn học chẩn đoán Technical SEO ở Khóa Học SEO Cơ Bản nếu mới bắt đầu, hoặc Mentor SEO 1 kèm 1 nếu muốn làm ngay trên website đang chạy. Nếu cần người soi website trước khi quyết định học, Phân tích SEO và GEO là bước đầu, phí được trừ đủ khi đăng ký Mentor sau đó.

Mentor SEO 1 kèm 1 cho đầu ra 01 trang chủ lực và 10 bài hỗ trợ. Sau khóa có 30 ngày rà bài, 3 buổi xem dữ liệu và 6 tháng hỏi đáp. Đăng ký Mentor sau khi làm Phân tích SEO và GEO thì 5.000.000đ phí phân tích được trừ đủ vào học phí.

Muốn học sâu cả hệ phương pháp, có Khóa học SEO Master: 18.000.000đ, 24 buổi trong 2 tháng, offline ở Quận 7, lớp dưới 5 học viên. Chẩn đoán Technical SEO là phần nền của trụ TOP-Ready: giúp website được Google thu thập, lập chỉ mục và xếp hạng đúng trang, bậc đầu trên Bản đồ DLN.

Chọn được hướng rồi thì Đăng ký học SEO để giữ lịch. Muốn hỏi trước, bạn nhắn Zalo cá nhân của Danh Nolan qua số 03 9999 5885.

Tự chấm miễn phí trước, rồi chọn học theo đúng chỗ website đang nghẽn.