Technical SEO Checklist: Crawl, Render, Index, Canonical Và Core Web Vitals

Technical SEO checklist là hệ thống kiểm tra giúp xác định liệu công cụ tìm kiếm có thể khám phá, truy cập, kết xuất, hiểu và lập chỉ mục đúng các trang quan trọng trên website hay không. Một website có nội dung tốt vẫn có thể gặp khó khăn trong tìm kiếm nếu Googlebot bị chặn, liên kết không thể thu thập, nội dung chính phụ thuộc vào JavaScript, canonical phát tín hiệu không nhất quán hoặc trải nghiệm tải trang thiếu ổn định.

Technical SEO không trực tiếp bảo đảm thứ hạng cao. Vai trò của SEO kỹ thuật là loại bỏ các rào cản khiến nội dung không được xử lý đúng, đồng thời tạo nền tảng để SEO Onpage, Content, Internal Link và hoạt động xây dựng thẩm quyền phát huy hiệu quả.

Checklist dưới đây tập trung vào năm lớp quan trọng: crawl, render, index, canonical và Core Web Vitals. Đây cũng là trình tự nên áp dụng khi kiểm tra website: xác minh khả năng truy cập trước, sau đó mới đánh giá cách Google kết xuất, lập chỉ mục và lựa chọn URL.

Tóm tắt nhanh

• Crawl: Bảo đảm Googlebot có thể tìm thấy và truy cập các URL quan trọng qua liên kết nội bộ, sitemap và cấu trúc website.
• Render: Kiểm tra nội dung, liên kết và tín hiệu SEO có xuất hiện đầy đủ sau khi JavaScript được xử lý hay không.
• Index: Xác nhận các trang cần SEO không bị chặn lập chỉ mục và cung cấp nội dung đủ rõ ràng, khác biệt.
• Canonical: Đồng bộ redirect, canonical, sitemap và internal link về cùng một URL ưu tiên.
• Core Web Vitals: Theo dõi LCP, INP và CLS bằng dữ liệu người dùng thực, đồng thời dùng dữ liệu lab để chẩn đoán nguyên nhân.

Technical SEO checklist là gì?

Technical SEO checklist là danh sách các hạng mục kỹ thuật cần kiểm tra để đánh giá khả năng website được công cụ tìm kiếm thu thập, kết xuất và lập chỉ mục.

Google xử lý các website thông qua ba giai đoạn chính:

1. Crawling: Googlebot khám phá và yêu cầu nội dung từ URL.
2. Rendering và indexing: Google xử lý HTML, CSS, JavaScript, nội dung và các tín hiệu kỹ thuật để hiểu trang.
3. Serving: Google lựa chọn kết quả phù hợp để hiển thị cho từng truy vấn.

Với website sử dụng JavaScript, Google mô tả ba giai đoạn chính là crawl, render và index. Các trang trả về mã trạng thái 200 thường được đưa vào hàng đợi kết xuất, trừ khi có chỉ thị yêu cầu không lập chỉ mục. Thời gian chờ render có thể khác nhau tùy tài nguyên và điều kiện xử lý.

Không phải URL nào được crawl cũng được index. Tương tự, một URL đã được index không có nghĩa nó sẽ xuất hiện cho mọi truy vấn. Technical SEO chỉ bảo đảm rằng website cung cấp các điều kiện kỹ thuật phù hợp để công cụ tìm kiếm xử lý nội dung.

Technical SEO thường cần được kiểm tra khi:

• Website mới xây dựng hoặc vừa thay đổi nền tảng.
• Website thay đổi tên miền, URL hoặc cấu trúc thư mục.
• Nhiều trang quan trọng không được index.
• Google lựa chọn canonical khác URL mong muốn.
• Website sử dụng framework JavaScript hoặc nội dung tải động.
• Traffic organic giảm sau khi thay đổi giao diện hoặc hệ thống.
• Core Web Vitals suy giảm trên nhiều nhóm trang.
• Website tạo nhiều URL tham số, bộ lọc hoặc trang trùng lặp.

Crawl, render, index và canonical không nên được kiểm tra riêng lẻ. Một thay đổi ở lớp này có thể ảnh hưởng trực tiếp đến lớp khác. Ví dụ, một URL bị chặn bằng robots.txt có thể khiến Google không đọc được thẻ noindex. Một canonical được khai báo đúng vẫn có thể bị bỏ qua nếu redirect, sitemap và internal link liên tục trỏ sang URL khác.

Kiểm tra khả năng crawl của website

Crawl là lớp đầu tiên trong Technical SEO. Nếu công cụ tìm kiếm không thể tìm hoặc truy cập URL, nội dung phía sau sẽ khó được kết xuất và lập chỉ mục đầy đủ.

Kiểm tra robots.txt

Tệp robots.txt hướng dẫn crawler những khu vực nào được phép hoặc không được phép yêu cầu.

Cần kiểm tra:

• Website có vô tình chặn toàn bộ crawler hay không.
• Thư mục chứa bài viết, sản phẩm hoặc trang dịch vụ có bị chặn không.
• JavaScript, CSS hoặc hình ảnh quan trọng có bị chặn không.
• Môi trường staging có bị mở crawl sau khi đưa website lên production không.
• URL bộ lọc hoặc tham số có tạo không gian crawl quá lớn không.
• Các quy tắc có áp dụng đúng user-agent không.

Không nên dùng robots.txt như phương pháp chính để ngăn URL xuất hiện trên Google. Một URL bị chặn crawl vẫn có thể được Google phát hiện qua liên kết từ nơi khác. Khi mục tiêu là không cho trang xuất hiện trong kết quả tìm kiếm, cần cân nhắc noindex, xác thực truy cập hoặc loại bỏ URL tùy trường hợp.

Cũng không nên vừa chặn URL trong robots.txt vừa kỳ vọng Google đọc được noindex trên chính URL đó. Nếu crawler không truy cập được trang, chỉ thị noindex có thể không được xử lý.

Kiểm tra liên kết crawlable

Google chủ yếu khám phá URL thông qua liên kết, sitemap và redirect. Liên kết nội bộ nên được triển khai bằng phần tử <a> có thuộc tính href trỏ đến một URL cụ thể.

Cần kiểm tra:

• Trang quan trọng có ít nhất một internal link trỏ đến.
• Không có orphan page cần SEO.
• Menu, breadcrumb và phân trang tạo URL truy cập được.
• Anchor text mô tả đúng nội dung trang đích.
• Internal link không trỏ qua redirect không cần thiết.
• Liên kết không chỉ tồn tại dưới dạng nút JavaScript.
• URL đích trả về mã trạng thái phù hợp.
• Nội dung phân trang có đường dẫn riêng và liên kết tuần tự.

Với nội dung lazy load, không nên yêu cầu người dùng phải cuộn hoặc nhấp thì nội dung mới xuất hiện. Google không thực hiện các thao tác tương tác như người dùng để kích hoạt nội dung. Nội dung quan trọng nên được tải khi xuất hiện trong viewport hoặc có URL phân trang độc lập.

Độ sâu nhấp chuột cũng cần được xem xét. Không có một con số cố định phù hợp cho mọi website, nhưng các trang kinh doanh quan trọng không nên bị chôn quá sâu trong kiến trúc hoặc chỉ có thể được tìm thấy qua công cụ tìm kiếm nội bộ.

Kiểm tra XML sitemap

XML sitemap giúp công cụ tìm kiếm khám phá các URL mà website muốn ưu tiên. Sitemap đặc biệt hữu ích với website lớn, website có nhiều nội dung mới hoặc cấu trúc liên kết nội bộ chưa hoàn thiện.

Một sitemap phù hợp nên:

• Chỉ chứa URL canonical cần xuất hiện trên Google.
• Không chứa URL redirect.
• Không chứa URL trả về 404, 410 hoặc 5xx.
• Không chứa URL bị noindex.
• Không chứa URL bị chặn crawl ngoài chủ đích.
• Sử dụng URL tuyệt đối.
• Dùng đúng giao thức HTTPS.
• Được cập nhật khi URL thay đổi.
• Được gửi và theo dõi trong Google Search Console.

Mỗi sitemap được giới hạn ở 50.000 URL hoặc 50 MB khi chưa nén. Nếu vượt quá giới hạn này, website cần chia thành nhiều sitemap và có thể gom lại bằng sitemap index.

Sitemap không bảo đảm URL sẽ được index. Nó chỉ cung cấp thêm một tín hiệu để Google khám phá URL và nhận biết phiên bản mà website muốn ưu tiên.

Kiểm tra mã trạng thái HTTP

Các trang cần lập chỉ mục thường phải trả về mã trạng thái 200. URL đã chuyển vĩnh viễn nên redirect đến URL mới. Nội dung đã xóa và không có trang thay thế phù hợp thường nên trả về 404 hoặc 410.

Các lỗi cần ưu tiên:

• Trang quan trọng trả về 3xx.
• Redirect chain kéo dài.
• Redirect loop.
• Trang lỗi nhưng vẫn trả về 200.
• Lỗi máy chủ 5xx.
• URL HTTP và HTTPS cùng tồn tại.
• Googlebot bị chặn bởi firewall hoặc CDN.
• Máy chủ phản hồi không ổn định.
• Bot nhận nội dung khác biệt bất thường so với người dùng.

Đối với website lớn, log server có thể giúp xác định Googlebot đang truy cập khu vực nào, mức độ thường xuyên và liệu crawler có đang tiêu tốn tài nguyên vào URL bộ lọc, tham số hoặc trang không có giá trị hay không.

Kiểm tra rendering và JavaScript SEO

Rendering là quá trình trình duyệt hoặc hệ thống kết xuất xử lý HTML, CSS và JavaScript để tạo nội dung cuối cùng.

Đây là bước đặc biệt quan trọng với website sử dụng framework JavaScript như React, Vue, Angular hoặc Next.js, nhất là khi nội dung chính được tạo bằng client-side rendering.

Next.js không mặc định là một nền tảng client-side rendering. Framework này có thể được triển khai theo nhiều cách như server-side rendering, static generation, hydration hoặc client rendering. Vì vậy, rủi ro SEO phụ thuộc vào cách website được xây dựng, không chỉ phụ thuộc vào tên framework.

So sánh HTML ban đầu và HTML đã render

Khi kiểm tra một URL, cần phân biệt:

• HTML ban đầu: Nội dung máy chủ gửi về.
• Rendered HTML: Nội dung sau khi JavaScript được thực thi.
• Giao diện trình duyệt: Nội dung người dùng nhìn thấy.

Các thành phần SEO quan trọng nên xuất hiện trong HTML ban đầu hoặc rendered HTML:

• Nội dung chính.
• H1 và heading quan trọng.
• Internal link.
• Title.
• Meta description.
• Canonical.
• Robots meta.
• Structured data.
• Hình ảnh và alt text.
• Sản phẩm hoặc nội dung phân trang.

Google sử dụng Chromium để thực thi JavaScript và phân tích HTML đã render. Tuy nhiên, rendering cần tài nguyên và có thể không xảy ra ngay sau khi URL được crawl. Server-side rendering hoặc prerendering vẫn có thể giúp nội dung được cung cấp sớm hơn cho người dùng và crawler.

Nếu nội dung quan trọng không xuất hiện trong rendered HTML, Google có thể không xử lý được nội dung đó. Có thể kiểm tra bằng URL Inspection hoặc Rich Results Test khi phù hợp.

Kiểm tra tài nguyên JavaScript và CSS

Cần xác định:

• File JavaScript có trả về lỗi không.
• API cung cấp nội dung có bị chặn không.
• CSS hoặc JavaScript quan trọng có bị chặn trong robots.txt không.
• Nội dung có biến mất khi script tải chậm không.
• Internal link có xuất hiện trong rendered HTML không.
• Lazy loading có phụ thuộc vào click hoặc scroll không.
• Canonical có bị JavaScript thay đổi không.
• Robots meta có bị thay đổi sau khi render không.
• Structured data có được tạo đầy đủ không.
• Consent banner có ngăn nội dung chính tải hay không.

Một website hoạt động bình thường trên trình duyệt của quản trị viên chưa chắc cung cấp cùng một phiên bản cho Googlebot. Cookie, đăng nhập, vị trí địa lý, CDN, firewall hoặc hệ thống chống bot có thể làm crawler nhận nội dung khác.

Lựa chọn phương pháp rendering

Các phương pháp thường gặp gồm:

• Server-side rendering: Máy chủ trả về HTML đã có nội dung.
• Static rendering: HTML được tạo sẵn trong quá trình build.
• Hydration: HTML có nội dung được gửi trước, JavaScript bổ sung tương tác sau.
• Client-side rendering: JavaScript phía trình duyệt tạo phần lớn nội dung.
• Dynamic rendering: Bot và người dùng nhận các phiên bản kết xuất khác nhau.

Google xem dynamic rendering là giải pháp tạm thời, không phải hướng xử lý dài hạn. Khi có thể, nên ưu tiên server-side rendering, static rendering hoặc hydration.

Không phải website client-side rendering nào cũng gặp vấn đề SEO. Việc lựa chọn kiến trúc cần dựa trên nội dung, nguồn lực phát triển, mức độ tương tác và khả năng kiểm soát quá trình kết xuất.

Kiểm tra điều kiện index

Một URL có thể crawl được nhưng vẫn không được lập chỉ mục. Indexing phụ thuộc vào cả tín hiệu kỹ thuật lẫn nội dung mà Google nhận được.

Kiểm tra robots meta và X-Robots-Tag

Hai phương pháp phổ biến để kiểm soát lập chỉ mục là:

• Thẻ meta robots.
• Header X-Robots-Tag.

X-Robots-Tag hữu ích với tài nguyên không phải HTML, chẳng hạn PDF.

Cần kiểm tra:

• Trang dịch vụ, danh mục hoặc bài viết quan trọng có bị noindex không.
• Template có tự động thêm noindex cho toàn bộ nhóm trang không.
• CDN hoặc máy chủ có chèn X-Robots-Tag không.
• Môi trường staging có bị index không.
• Trang tìm kiếm nội bộ, giỏ hàng hoặc tài khoản có được kiểm soát đúng không.
• URL bị noindex có xuất hiện trong sitemap không.
• URL bị chặn crawl có đồng thời chứa noindex không.

Kiểm tra chất lượng và tính khác biệt của URL

Google có thể không chọn index một URL khi:

• Nội dung quá mỏng.
• Nội dung trùng hoặc gần giống URL khác.
• Trang không có mục đích tìm kiếm rõ ràng.
• Nội dung chính không xuất hiện trong rendered HTML.
• Trang chỉ chứa danh sách rỗng hoặc bộ lọc.
• Canonical trỏ sang URL khác.
• Internal link quá yếu.
• Trang bị xem là soft 404.
• Nội dung khác biệt chỉ nằm ở vài từ hoặc thông số nhỏ.

Không nên xem việc gửi sitemap hoặc yêu cầu lập chỉ mục là bằng chứng URL chắc chắn sẽ được index. Những thao tác này chỉ giúp Google phát hiện hoặc đánh giá lại URL.

Kiểm tra bằng Google Search Console

URL Inspection có thể hỗ trợ đối chiếu:

• Google đã biết URL hay chưa.
• URL có được phép crawl không.
• Trạng thái index.
• Canonical do website khai báo.
• Canonical do Google lựa chọn.
• Lần crawl gần nhất.
• HTML đã render.
• Tài nguyên bị lỗi khi tải.
• Structured data hoặc enhancement được Google nhận diện khi loại nội dung đó được hỗ trợ và có dữ liệu tương ứng.

Với các trang quan trọng, cần kiểm tra xem Google-selected canonical có khớp với URL mà website muốn ưu tiên hay không.

Các trạng thái như Crawled – currently not indexed hoặc Discovered – currently not indexed không nên được xử lý chỉ bằng cách yêu cầu index lại. Cần phân tích sâu theo nguyên nhân như crawl demand, nội dung, rendering, internal link, canonical và mức độ trùng lặp. Phần này nên được triển khai trong một bài troubleshooting riêng để tránh mở rộng quá mức phạm vi của Technical SEO checklist.

Kiểm tra canonical và URL trùng lặp

Canonicalization là quá trình Google lựa chọn URL đại diện trong một nhóm trang trùng hoặc gần giống nhau.

URL mà website khai báo chỉ là tín hiệu ưu tiên. Google có thể lựa chọn URL khác nếu hệ thống phát hiện nhiều tín hiệu xung đột.

Kiểm tra self-referencing canonical

Các trang chính nên có canonical trỏ về chính URL của mình, đặc biệt với:

• Bài viết.
• Trang dịch vụ.
• Trang sản phẩm.
• Trang danh mục.
• Landing page.
• Trang ngôn ngữ riêng biệt.

Cần kiểm tra sự nhất quán giữa:

• HTTP và HTTPS.
• Có www và không có www.
• Có và không có dấu gạch cuối.
• URL viết hoa và viết thường.
• URL có tham số và URL sạch.

Đồng bộ tín hiệu canonical

Theo tài liệu Google:

• Redirect là tín hiệu mạnh.
• rel="canonical" là tín hiệu mạnh.
• URL có trong sitemap là tín hiệu yếu hơn.

Các tín hiệu có thể được kết hợp để tăng khả năng Google lựa chọn URL mà website muốn ưu tiên.

URL ưu tiên nên được sử dụng nhất quán trong:

• Redirect.
• Canonical.
• Sitemap.
• Internal link.
• Hreflang.
• Navigation.
• Breadcrumb.

Cần tránh:

• Canonical trỏ đến URL redirect.
• Canonical trỏ đến 404.
• Canonical trỏ đến URL noindex.
• Canonical khác URL trong sitemap.
• Internal link trỏ đến phiên bản không canonical.
• HTTP canonical sang HTTPS nhưng redirect ngược về HTTP.
• Canonical toàn bộ trang phân trang về trang đầu tiên dù nội dung khác nhau.
• Các trang ngôn ngữ canonical sai phiên bản.
• JavaScript tạo canonical không nhất quán.
• Nhiều trang khác nhau cùng canonical về một URL không tương đương.

Không nên dùng robots.txt, Removal Tool hoặc noindex để thay thế canonicalization cho các URL trùng lặp trong cùng website.

Xác định nguồn tạo URL trùng lặp

URL trùng lặp thường xuất hiện từ:

• HTTP và HTTPS.
• Có www và không có www.
• Dấu gạch cuối URL.
• Tham số UTM.
• Bộ lọc sản phẩm.
• Chức năng sắp xếp.
• Trang in.
• Session ID.
• Trang tag và category.
• Trang tìm kiếm nội bộ.
• Nhiều đường dẫn cùng hiển thị một sản phẩm.

Không phải mọi URL trùng lặp đều là vi phạm hoặc lỗi nghiêm trọng. Mục tiêu của canonical là giúp công cụ tìm kiếm hiểu URL đại diện và hạn chế tín hiệu bị phân tán giữa nhiều phiên bản.

Kiểm tra Core Web Vitals

Core Web Vitals là nhóm chỉ số phản ánh trải nghiệm tải trang, khả năng phản hồi và độ ổn định bố cục trong điều kiện sử dụng thực tế.

Ba chỉ số hiện tại gồm:

Chỉ số	Ý nghĩa	Ngưỡng tốt
LCP	Thời gian hiển thị phần tử nội dung lớn nhất	Không quá 2,5 giây
INP	Độ trễ phản hồi sau tương tác	Không quá 200 mili giây
CLS	Mức dịch chuyển bố cục ngoài dự kiến	Không quá 0,1

Việc đánh giá nên dựa trên phân vị thứ 75 của lượt tải trang, được phân tách giữa thiết bị di động và máy tính. Một trang hoặc nhóm URL được đánh giá đạt khi cả ba chỉ số đều nằm trong ngưỡng tốt.

Phân biệt field data và lab data

Field data được thu thập từ người dùng thực, với nhiều loại thiết bị, kết nối mạng, vị trí và hành vi khác nhau.

Lab data được đo trong môi trường kiểm thử có điều kiện thiết bị và mạng được xác định trước. Lighthouse thường được sử dụng để tạo dữ liệu này.

Việc một trang hoặc nhóm URL được đánh giá đạt Core Web Vitals nên dựa chủ yếu trên field data ở phân vị thứ 75. Điểm Lighthouse hoặc lab data phù hợp để chẩn đoán nguyên nhân và kiểm thử trước khi triển khai, nhưng không thay thế dữ liệu trải nghiệm thực tế của người dùng.

Khi có cả field data và lab data, field data nên được ưu tiên để xác định mức độ ảnh hưởng thực tế. Lab data vẫn hữu ích để tái tạo lỗi, thử nghiệm giải pháp và phát hiện vấn đề trên thiết bị hoặc kết nối chậm.

Không nên chạy PageSpeed Insights một lần rồi kết luận toàn bộ website nhanh hoặc chậm. Cần:

• Kiểm tra cả mobile và desktop.
• Phân tích theo từng template.
• So sánh trang chủ, bài viết, dịch vụ, danh mục và sản phẩm.
• Theo dõi trước và sau khi triển khai.
• Xác định phần tử cụ thể gây LCP, INP hoặc CLS.
• Xem xét dữ liệu trong một khoảng thời gian đủ dài.

Cách cải thiện LCP

LCP thường bị ảnh hưởng bởi:

• Thời gian phản hồi máy chủ cao.
• Hình ảnh hero quá lớn.
• Hình ảnh không được nén.
• CSS chặn hiển thị.
• Font tải chậm.
• Nội dung chính được tạo muộn bằng JavaScript.
• Hình ảnh LCP bị lazy load.
• CDN hoặc cache chưa được cấu hình phù hợp.

Quy trình kiểm tra nên gồm:

1. Xác định phần tử LCP.
2. Kiểm tra thời gian phản hồi ban đầu.
3. Xác định khi nào trình duyệt phát hiện tài nguyên.
4. Kiểm tra thời gian tải tài nguyên.
5. Đánh giá độ trễ trước khi phần tử được hiển thị.

Không nên lazy load hình ảnh hoặc nội dung có khả năng xuất hiện ngay trong viewport ban đầu.

Cách cải thiện INP

INP có thể bị ảnh hưởng bởi:

• JavaScript thực thi quá lâu.
• Main thread bị chặn.
• Event handler xử lý quá nhiều tác vụ.
• Third-party script.
• DOM quá lớn.
• Component render lại không cần thiết.
• Tác vụ đồng bộ kéo dài.

Các hướng xử lý có thể gồm:

• Chia nhỏ long task.
• Trì hoãn script không quan trọng.
• Giảm lượng JavaScript phía client.
• Tối ưu event handler.
• Hạn chế third-party script.
• Giảm phạm vi cập nhật DOM.
• Phản hồi giao diện sớm trước khi hoàn tất tác vụ nặng.

Cách cải thiện CLS

CLS thường xuất hiện khi:

• Hình ảnh không khai báo kích thước.
• Banner hoặc quảng cáo được chèn sau khi tải.
• Font thay đổi kích thước chữ.
• Nội dung mới xuất hiện phía trên vùng đang đọc.
• Animation làm thay đổi layout.
• Cookie banner đẩy toàn bộ nội dung.

Cần dành sẵn không gian cho:

• Hình ảnh.
• Video.
• Quảng cáo.
• Nội dung nhúng.
• Banner.
• Thành phần tải động.

Với font, cần kiểm tra preload, fallback font và cách chuyển đổi giữa các font để hạn chế thay đổi bố cục.

Core Web Vitals không phải hạng mục tối ưu một lần. Plugin, script tracking, quảng cáo, thay đổi giao diện hoặc nội dung mới đều có thể làm các chỉ số thay đổi.

Cách ưu tiên lỗi Technical SEO theo P0/P1/P2

Technical SEO checklist giúp phát hiện lỗi, nhưng không phải lỗi nào cũng cần xử lý cùng mức độ ưu tiên.

Để thống nhất với quy trình SEO Audit, có thể sử dụng ba cấp:

P0: Vấn đề nghiêm trọng

P0 là các vấn đề có thể khiến toàn bộ website hoặc nhóm trang quan trọng không thể được truy cập, crawl hoặc index.

Ví dụ:

• Website production bị chặn toàn bộ.
• Trang quan trọng đồng loạt bị noindex.
• Lỗi máy chủ diện rộng.
• Redirect loop trên toàn bộ template.
• Canonical sai hàng loạt về một URL không liên quan.
• Nội dung chính không xuất hiện sau rendering.

P1: Vấn đề ảnh hưởng đáng kể

P1 là lỗi ảnh hưởng đến trang kinh doanh quan trọng, template chính hoặc số lượng lớn URL nhưng chưa làm website mất hoàn toàn khả năng xuất hiện.

Ví dụ:

• Sitemap chứa nhiều URL lỗi.
• Internal link trỏ sai phiên bản canonical.
• Core Web Vitals kém trên template dịch vụ.
• Bộ lọc tạo hàng nghìn URL crawlable.
• Một nhóm trang quan trọng bị orphan.
• JavaScript làm mất liên kết hoặc structured data.

P2: Hạng mục tối ưu hoặc cải thiện dài hạn

P2 là các vấn đề cục bộ hoặc hạng mục cải thiện chưa gây rủi ro nghiêm trọng ngay lập tức.

Ví dụ:

• Một số redirect chain ngắn.
• Hình ảnh chưa tối ưu hoàn toàn.
• CLS xuất hiện trên một thành phần ít dùng.
• Sitemap có một số URL không cần thiết.
• Click depth chưa tối ưu ở nhóm trang phụ.

Cùng một lỗi có thể được xếp mức khác nhau tùy số lượng URL, giá trị kinh doanh và mức độ ảnh hưởng thực tế. Phần đánh giá toàn diện về Technical, Content, Authority và Conversion nên được xử lý trong quy trình SEO Audit riêng; bài này chỉ tập trung vào cách kiểm tra và hiểu các lỗi kỹ thuật.

Technical SEO checklist tổng hợp

Crawl

• Website không bị chặn toàn bộ trong robots.txt.
• JavaScript, CSS và hình ảnh quan trọng có thể truy cập.
• Trang quan trọng có internal link crawlable.
• Không có orphan page cần SEO.
• Menu, breadcrumb và phân trang dùng URL truy cập được.
• Không có redirect loop.
• Redirect chain được hạn chế.
• URL cần index trả về 200.
• URL đã xóa trả về trạng thái phù hợp.
• Sitemap chỉ chứa URL canonical có giá trị.
• URL tham số và bộ lọc được kiểm soát.
• Máy chủ không trả lỗi 5xx bất thường.

Render

• Nội dung chính xuất hiện trong rendered HTML.
• H1, title, canonical và robots meta được render đúng.
• Internal link xuất hiện sau rendering.
• JavaScript không tạo lỗi ảnh hưởng nội dung.
• API cung cấp nội dung không bị chặn.
• Lazy loading không phụ thuộc vào click hoặc scroll.
• Structured data xuất hiện đầy đủ khi phù hợp.
• Googlebot không nhận phiên bản rỗng hoặc khác biệt bất thường.
• Dynamic rendering không được sử dụng như giải pháp dài hạn.

Index

• Trang cần SEO không chứa noindex.
• Trang không cần xuất hiện được kiểm soát đúng cách.
• Không dùng đồng thời robots block và noindex sai mục đích.
• Nội dung đủ khác biệt với URL khác.
• Không có soft 404 diện rộng.
• Trang quan trọng được khai báo trong sitemap.
• Google-selected canonical khớp với URL ưu tiên trên các trang quan trọng.
• Trang index có mục đích tìm kiếm rõ ràng.
• Môi trường staging không xuất hiện trên Google.

Canonical

• Trang chính có self-referencing canonical.
• Canonical dùng URL tuyệt đối.
• Canonical trỏ đến URL trả về 200.
• Canonical không trỏ đến URL noindex.
• Redirect, sitemap và internal link cùng trỏ về URL ưu tiên.
• HTTP chuyển hướng nhất quán sang HTTPS.
• Phiên bản có và không có www được chuẩn hóa.
• Dấu gạch cuối URL được xử lý nhất quán.
• URL tham số không tạo tín hiệu canonical xung đột.
• Hreflang trỏ đến URL canonical đúng ngôn ngữ.

Core Web Vitals

• Theo dõi LCP, INP và CLS.
• Kiểm tra cả mobile và desktop.
• Ưu tiên field data khi có.
• Dùng lab data để chẩn đoán.
• Xác định phần tử gây LCP.
• Kiểm tra long task và third-party script gây INP.
• Khai báo kích thước ảnh và nội dung nhúng.
• Phân tích theo từng template.
• Theo dõi lại sau khi thay đổi giao diện hoặc script.

Những lỗi cần tránh khi triển khai Technical SEO

Chặn robots.txt rồi thêm noindex

Nếu crawler không được phép truy cập trang, crawler có thể không đọc được noindex. Cần xác định rõ mục tiêu là ngăn crawl hay ngăn index trước khi chọn phương án.

Đưa toàn bộ URL vào sitemap

Sitemap không nên là danh sách tất cả URL mà CMS có thể tạo. Chỉ nên đưa các URL canonical mà website thực sự muốn xuất hiện trong kết quả tìm kiếm.

Canonical mọi trang về trang chủ

Canonical chỉ phù hợp khi các URL trùng hoặc gần tương đương. Canonical hàng loạt các trang khác nhau về trang chủ có thể bị Google bỏ qua và làm sai cấu trúc index.

Chỉ kiểm tra giao diện trên trình duyệt

Người dùng nhìn thấy nội dung không có nghĩa Google nhận được đúng nội dung đó. Website sử dụng JavaScript cần được kiểm tra bằng rendered HTML và URL Inspection.

Chỉ tối ưu điểm Lighthouse

Điểm Lighthouse hữu ích cho chẩn đoán nhưng không thay thế field data. Cần ưu tiên trải nghiệm thực tế của người dùng và phân tích nguyên nhân theo từng template.

Sửa từng URL thay vì sửa nguyên nhân gốc

Khi hàng trăm URL gặp cùng một vấn đề, nguyên nhân thường nằm ở template, CMS, plugin hoặc logic routing. Sửa từng URL có thể không giải quyết được lỗi tái diễn.

Xem Technical SEO là việc làm một lần

Website liên tục thay đổi. Plugin, tracking, tính năng lọc, nội dung mới và cập nhật giao diện đều có thể phát sinh lỗi crawl, render hoặc hiệu suất.

Bước tiếp theo để áp dụng Technical SEO checklist

Hãy bắt đầu với nhóm URL có giá trị kinh doanh cao thay vì cố gắng sửa toàn bộ website cùng lúc. Trước tiên, xác định trang nào cần index, sau đó kiểm tra khả năng crawl, rendered HTML, canonical và Core Web Vitals theo từng template.

Nếu website có nhiều URL, sử dụng JavaScript phức tạp hoặc xuất hiện lỗi index diện rộng, nên thực hiện Technical SEO Audit có phân loại P0/P1/P2. Báo cáo cần chỉ rõ:

• URL hoặc template bị ảnh hưởng.
• Nguyên nhân gốc.
• Mức độ ưu tiên.
• Bộ phận phụ trách.
• Cách kiểm tra lại sau triển khai.

Mục tiêu của Technical SEO không phải tạo ra một website “không có bất kỳ cảnh báo nào”, mà là bảo đảm các trang quan trọng có thể được công cụ tìm kiếm truy cập, hiểu và xử lý đúng, đồng thời mang lại trải nghiệm ổn định cho người dùng.