Checklist technical SEO tôi chạy mỗi quý

Mỗi quý một lần, tôi ngồi xuống và chạy lại đúng cùng một danh sách trên các website mình phụ trách. Không phải vì quý nào cũng có sự cố lớn, mà vì technical SEO là loại hỏng hóc âm thầm: một file robots.txt bị nhân viên dev sửa nhầm trong lúc deploy, một loạt trang rơi khỏi chỉ mục sau khi đổi giao diện, một redirect tạm thời quên gỡ — không cái nào báo động đỏ, nhưng cộng lại chúng âm thầm ăn mòn lưu lượng trong nhiều tuần trước khi bạn kịp nhận ra.

Bài này là toàn bộ checklist technical SEO tôi thực sự chạy theo nhịp hằng quý, viết lại cho website Việt Nam. Mỗi mục tôi sẽ nói rõ ba thứ: kiểm bằng công cụ nào, ngưỡng thế nào thì coi là "ổn", và đến mức nào thì phải dừng mọi việc để xử lý. Cuối bài có một bảng checklist bạn có thể sao chép và dùng ngay cho lần rà soát quý tới của mình.

Checklist technical SEO hằng quý là một quy trình rà soát định kỳ 10 nhóm hạng mục kỹ thuật của website — chỉ mục, robots/sitemap, tốc độ và Core Web Vitals, di động, lỗi crawl, redirect/404, canonical, schema, HTTPS và liên kết nội bộ — để bắt sớm những lỗi âm thầm làm tụt thứ hạng trước khi chúng kịp ăn mòn lưu lượng. Mỗi quý chạy một lần là đủ với phần lớn site, kết hợp theo dõi cảnh báo tự động giữa các đợt.

Vì sao nên rà soát theo quý, không phải mỗi tuần hay mỗi năm

Trước khi đi vào từng mục, cần thống nhất nhịp độ. Rất nhiều người hoặc rà soát quá thường xuyên — tuần nào cũng mở công cụ ra xem, hoảng vì những dao động bình thường — hoặc quá hiếm, một năm mới ngó tới một lần và lúc đó đã có vài chục lỗi tích tụ thành một mớ hỗn độn không gỡ nổi.

Nhịp hằng quý là điểm cân bằng. Nó đủ dày để không có lỗi nào âm ỉ quá ba tháng — đủ ngắn để khi bạn phát hiện một loạt trang rơi khỏi chỉ mục, bạn còn nhớ được mình đã deploy gì trong giai đoạn đó. Nhưng nó cũng đủ thưa để bạn không lãng phí thời gian phản ứng với nhiễu. Phần lớn chỉ số technical SEO dao động ngày qua ngày một cách vô hại; chỉ khi nhìn theo quý bạn mới phân biệt được xu hướng thật với tiếng ồn.

Một lưu ý quan trọng: rà soát theo quý không có nghĩa là bạn "mù" trong ba tháng giữa hai đợt. Những lỗi nghiêm trọng nhất — robots.txt chặn nhầm cả site, chứng chỉ bảo mật hết hạn, trang chủ trả về 500 — phải được bắt bằng cảnh báo tự động ngay khi xảy ra, không chờ tới đợt rà soát. Checklist hằng quý là tầng rà soát sâu, có hệ thống; còn cảnh báo tự động là tầng phản xạ nhanh. Hai tầng này bổ sung cho nhau. Nếu bạn muốn hiểu cách dựng một lượt soi toàn diện làm điểm xuất phát, bài cách kiểm tra sức khỏe kỹ thuật website là nơi tốt để bắt đầu trước khi thiết lập nhịp định kỳ.

Mục 1 — Chỉ mục (index coverage): Google đang giữ đúng những trang nào

Đây là mục tôi luôn chạy đầu tiên, vì nó là thước đo trực tiếp nhất cho câu hỏi quan trọng nhất: những trang bạn muốn xuất hiện trên Google có thực sự nằm trong chỉ mục không, và có trang nào lọt vào mà lẽ ra không nên?

Kiểm bằng đâu: Google Search Console, báo cáo "Lập chỉ mục trang" (Pages / Indexing). Nó chia URL của bạn thành hai nhóm lớn — đã lập chỉ mục và chưa lập chỉ mục — và quan trọng hơn, nêu lý do cho từng nhóm chưa lập chỉ mục. Bạn cũng có thể dùng toán tử site:tenmiendua.vn trên Google để xem nhanh số trang đang được giữ, nhưng con số này chỉ là ước lượng thô, đừng coi là chính xác.

Ngưỡng "ổn": số trang đã lập chỉ mục nên xấp xỉ số trang bạn thực sự muốn xếp hạng — không chênh lệch lớn theo cả hai hướng. Nếu bạn có 400 trang nội dung giá trị mà Google chỉ giữ 120, đó là vấn đề. Nếu bạn chỉ có 400 trang giá trị mà Google đang giữ 9.000, bạn đang bị "phình chỉ mục" (index bloat) — nhiều khả năng các trang lọc, trang tìm kiếm nội bộ, hay trang phân trang tự sinh đang ngốn ngân sách crawl.

Khi nào hành động: nếu số trang đã lập chỉ mục giảm đột ngột giữa hai quý, đó là cờ đỏ — đào ngay vào lý do "chưa lập chỉ mục" để xem có loạt trang nào bị gắn noindex nhầm, bị chặn, hay bị Google coi là trùng lặp. Nếu chỉ mục phình to bất thường, hãy xác định nhóm URL rác và chặn chúng (qua robots hoặc noindex) trước khi chúng làm loãng tín hiệu của site. Với mỗi mục trong báo cáo bạn không nhận ra, hãy mở vài URL mẫu để hiểu vì sao chúng tồn tại.

Một mẹo nhỏ với báo cáo này

Đừng chỉ nhìn tổng số. Hãy lọc theo từng lý do và xem URL mẫu của mỗi lý do. "Đã thu thập dữ liệu — hiện chưa được lập chỉ mục" thường nghĩa là chất lượng trang chưa đủ để Google muốn giữ; "Trùng lặp, không có canonical do người dùng chọn" nghĩa là bạn đang để Google tự đoán canonical — một dấu hiệu cần dọn. Mỗi lý do là một câu chuyện kỹ thuật khác nhau và đòi cách xử lý khác nhau.

Mục 2 — robots.txt và sitemap: hai file nhỏ quyết định cả site

robots.txt là file văn bản nhỏ xíu nằm ở gốc tên miền, nhưng nó có sức phá hoại không cân xứng với kích thước. Một dòng Disallow: / đặt nhầm có thể xóa sạch website của bạn khỏi kết quả tìm kiếm trong vài ngày. Tôi đã thấy điều này xảy ra nhiều lần, hầu như luôn là do một bản build từ môi trường thử nghiệm (staging) bị đẩy nhầm lên môi trường thật, mang theo file robots.txt chặn-toàn-bộ vốn dùng để giấu site thử nghiệm.

Kiểm bằng đâu: mở trực tiếp tenmiendua.vn/robots.txt trên trình duyệt và đọc bằng mắt — đừng tin trí nhớ. Đối chiếu với báo cáo robots trong Search Console để xem Google đang đọc file này thế nào và có dòng nào chặn nhầm khu vực quan trọng không. Với sitemap, vào báo cáo "Sơ đồ trang web" trong Search Console: kiểm tra sitemap đã được gửi, đang ở trạng thái "Thành công", và số URL Google đọc được khớp với số URL bạn kỳ vọng.

Ngưỡng "ổn": robots.txt chỉ chặn đúng những thứ nên chặn (khu vực quản trị, trang giỏ hàng, tham số lọc rác) và để mở toàn bộ nội dung công khai. Sitemap chỉ liệt kê URL chuẩn, trả về mã 200, không chứa URL bị noindex, không chứa redirect, không chứa trang 404. Số URL trong sitemap nên xấp xỉ số trang bạn muốn lập chỉ mục.

Khi nào hành động: bất kỳ dòng Disallow nào chặn nội dung công khai là việc khẩn cấp — sửa ngay trong ngày, đừng chờ hết đợt rà soát. Nếu sitemap chứa hàng loạt URL trả về lỗi hoặc redirect, hãy làm sạch nguồn sinh sitemap, vì sitemap bẩn làm Google mất niềm tin vào toàn bộ file. Đây là khu vực rất nhạy: chỉ một dòng sai có thể giết phần lớn lưu lượng tự nhiên, nên bài lỗi robots.txt giết traffic như thế nào đáng đọc kỹ nếu bạn từng để dev động vào file này mà không rà lại.

Mục 3 — Tốc độ và Core Web Vitals: trải nghiệm Google thực sự đo

Core Web Vitals là bộ ba chỉ số Google dùng để đo trải nghiệm tải trang của người dùng thật: LCP (thời gian phần tử nội dung lớn nhất hiện ra), INP (độ phản hồi khi người dùng tương tác — đã thay thế FID từ 2024), và CLS (mức độ giao diện bị xê dịch ngoài ý muốn). Đây không phải lý thuyết suông; với web Việt, nơi rất nhiều người vào bằng điện thoại tầm trung và mạng 4G chập chờn, ba chỉ số này phản ánh khá sát việc người dùng có ở lại hay thoát ngay.

Kiểm bằng đâu: báo cáo "Các chỉ số quan trọng về trang web" (Core Web Vitals) trong Search Console cho bạn dữ liệu hiện trường — tức là số đo từ người dùng thật, chia theo di động và máy tính. Đây là nguồn đáng tin nhất vì nó là trải nghiệm thực. Để soi một trang cụ thể, dùng PageSpeed Insights: nó vừa cho dữ liệu hiện trường vừa cho dữ liệu phòng thí nghiệm cùng danh sách đề xuất sửa. Lighthouse trong trình duyệt cũng hữu ích khi muốn thử nhanh.

Ngưỡng "ổn": theo mốc của Google, LCP nên dưới 2,5 giây, INP nên dưới 200 mili-giây, và CLS nên dưới 0,1. Quan trọng là phải đạt ở nhóm di động, không chỉ máy tính — vì phần lớn người Việt truy cập bằng điện thoại, và di động thường là nhóm tệ hơn. Trong báo cáo Search Console, mục tiêu là đưa càng nhiều URL về nhóm "Tốt" càng tốt.

Khi nào hành động: nếu một nhóm URL lớn rơi vào "Kém" ở di động, đó là ưu tiên cao. Thủ phạm phổ biến ở web Việt: ảnh chưa nén và chưa đặt kích thước (gây CLS), quá nhiều mã JavaScript của bên thứ ba — chat, pixel quảng cáo, công cụ phân tích — chặn luồng hiển thị (gây INP và LCP xấu), và font web tải chậm. Đừng đuổi theo điểm số 100 tuyệt đối; hãy đưa các chỉ số qua ngưỡng "Tốt" rồi dừng, vì cố vắt thêm vài điểm cuối thường tốn công gấp nhiều lần lợi ích.

Mục 4 — Thân thiện di động: mặc định, không phải tùy chọn

Google lập chỉ mục theo bản di động trước (mobile-first indexing) đã nhiều năm — nghĩa là phiên bản di động của site mới là phiên bản Google "nhìn thấy" và dùng để xếp hạng. Nếu bản di động của bạn thiếu nội dung so với bản máy tính, hoặc khó dùng, bạn đang tự bắn vào chân mình.

Kiểm bằng đâu: mở vài trang chính trên điện thoại thật và dùng thử như một người dùng bình thường — đây là phép thử không gì thay thế được. Bổ sung bằng chế độ giả lập thiết bị trong công cụ dành cho nhà phát triển của trình duyệt (DevTools) để xem nhanh nhiều kích thước màn hình. Kiểm tra cả việc bản di động có đầy đủ nội dung và liên kết như bản máy tính không.

Ngưỡng "ổn": chữ đọc được mà không cần phóng to, các nút và liên kết đủ lớn để bấm bằng ngón tay không bị bấm nhầm, không có nội dung nào tràn ngang phải kéo qua lại, và bản di động chứa đúng những nội dung quan trọng như bản máy tính. Pop-up che toàn màn hình ngay khi vào trang là điều cần tránh — Google không thích, và người dùng cũng vậy.

Khi nào hành động: nếu bản di động thiếu hẳn một khối nội dung mà bản máy tính có (thường do thiết kế "ẩn trên mobile"), hãy sửa ngay, vì Google có thể đang không thấy phần nội dung đó. Nếu các phần tử bấm quá nhỏ hoặc quá sát nhau, chỉnh lại khoảng cách. Đây là mục dễ bỏ sót vì người làm marketing hay ngồi máy tính cả ngày và quên rằng đa số người dùng của họ thì không.

Mục 5 — Lỗi crawl: những cánh cửa Google gõ mà không ai mở

Lỗi crawl là khi Google cố truy cập một URL trên site của bạn nhưng gặp trục trặc — máy chủ trả về lỗi, trang quá lâu không phản hồi, hoặc bị chuyển hướng lòng vòng. Một vài lỗi rải rác là bình thường với mọi site; nhưng một cụm lỗi tập trung thường báo hiệu một vấn đề có hệ thống.

Kiểm bằng đâu: báo cáo "Số liệu thống kê về thu thập dữ liệu" (Crawl stats) trong phần Cài đặt của Search Console cho bạn thấy Google đang gặp những mã phản hồi nào khi crawl. Mục "Lập chỉ mục trang" cũng liệt kê các URL gặp lỗi máy chủ (5xx) hay không tìm thấy (404). Công cụ "Kiểm tra URL" cho phép soi từng URL cụ thể để xem Google nhìn thấy gì.

Ngưỡng "ổn": tỷ lệ lỗi máy chủ (mã 5xx) nên gần như bằng không — đó là dấu hiệu hạ tầng của bạn ổn định. Lỗi 404 ở mức thấp và chủ yếu là các URL cũ không còn quan trọng thì chấp nhận được; điều bạn không muốn là 404 trên những trang vẫn còn liên kết trỏ tới hoặc vẫn có người tìm. Thời gian phản hồi trung bình nên ổn định, không tăng vọt.

Khi nào hành động: nếu thấy một cụm lỗi 5xx, đó là việc cho đội kỹ thuật ngay lập tức — máy chủ đang quá tải hoặc có lỗi ứng dụng, và mỗi lần Google gặp 5xx là một lần nó mất niềm tin vào độ ổn định của site. Nếu 404 tăng đột biến sau một lần đổi cấu trúc URL, nghĩa là bạn quên gắn redirect — xử lý ở mục tiếp theo. Nếu thời gian phản hồi leo dần qua các quý, đó là tín hiệu sớm cho thấy hạ tầng cần nâng cấp trước khi nó thành nút thắt thật sự.

Mục 6 — Redirect và 404: dọn dẹp đường đi sau mỗi lần thay đổi

Redirect (chuyển hướng) và lỗi 404 là cặp đôi luôn sinh ra mỗi khi website thay đổi — đổi slug bài viết, gộp hai trang, bỏ một mục sản phẩm, đổi cấu trúc danh mục. Quản lý chúng cho gọn là một trong những việc dễ bị lười nhất và cũng âm thầm gây hại nhất.

Kiểm bằng đâu: một công cụ crawl toàn site (loại quét toàn bộ liên kết nội bộ và trả về mã trạng thái cho từng URL) là cách tốt nhất để có bức tranh đầy đủ — nó chỉ ra mọi liên kết nội bộ đang trỏ tới trang 404 hoặc đi qua chuỗi redirect. Trong Search Console, mục lỗi 404 và mục "Trang có chuyển hướng" cũng cho dữ liệu hữu ích. Để kiểm một URL cụ thể, công cụ kiểm tra HTTP header hoặc tiện ích trình duyệt theo dõi chuỗi chuyển hướng đều dùng được.

Ngưỡng "ổn": redirect nên là chuyển hướng vĩnh viễn (mã 301) khi nội dung đã dời chỗ hẳn, và mỗi redirect chỉ nên có một bước — không có chuỗi A trỏ B trỏ C trỏ D. Không có liên kết nội bộ nào được trỏ tới một URL redirect; hãy cập nhật liên kết để trỏ thẳng tới đích cuối. Trang 404 phải có giao diện thân thiện, giữ điều hướng của site, và gợi ý đường về các trang chính.

Khi nào hành động: nếu phát hiện chuỗi redirect nhiều bước, rút gọn xuống một bước — mỗi bước thừa làm chậm tải và làm loãng tín hiệu truyền qua. Nếu có liên kết nội bộ trỏ tới trang đã chết, sửa chính liên kết đó thay vì chỉ dựa vào redirect đỡ. Một sai lầm phổ biến cần loại bỏ: dùng redirect tạm thời (mã 302) cho những thay đổi thực ra là vĩnh viễn — điều này khiến Google do dự không chuyển uy tín sang URL mới.

Mục 7 — Canonical: chỉ cho Google bản nào là bản chính

Thẻ canonical là cách bạn nói với Google: "trong số các URL có nội dung giống hoặc gần giống nhau, đây mới là bản chính, hãy lập chỉ mục và dồn uy tín về bản này". Nó đặc biệt quan trọng với những site sinh ra nhiều biến thể URL cho cùng một nội dung — trang thương mại điện tử với tham số lọc, trang có cả phiên bản có và không có gạch chéo cuối, trang phân trang.

Kiểm bằng đâu: công cụ "Kiểm tra URL" trong Search Console cho biết canonical bạn khai báo là gì và canonical Google thực sự chọn là gì — khi hai cái này lệch nhau là có chuyện đáng xem. Một công cụ crawl toàn site sẽ liệt kê thẻ canonical của mọi trang, giúp bạn phát hiện các trang trỏ canonical sai chỗ hoặc thiếu hẳn.

Ngưỡng "ổn": mỗi trang có một thẻ canonical rõ ràng, hợp lý — thường là tự trỏ tới chính nó với URL chuẩn (đúng giao thức HTTPS, đúng cách dùng www hay không, đúng quy ước gạch chéo cuối). Các biến thể của một trang đều trỏ canonical về cùng một bản chính. Canonical Google chọn trùng với canonical bạn khai báo.

Khi nào hành động: nếu Google liên tục chọn canonical khác với bản bạn muốn, đó là tín hiệu các tín hiệu của bạn đang mâu thuẫn — liên kết nội bộ, sitemap và thẻ canonical phải nhất quán cùng trỏ về một bản. Nếu một loạt trang quan trọng đang trỏ canonical về một trang khác (vô tình tự loại mình khỏi chỉ mục), sửa ngay. Đây là mục tinh tế: lỗi canonical không gây sập rõ ràng, nó chỉ âm thầm khiến những trang bạn muốn xếp hạng tự nhường chỗ cho bản khác.

Mục 8 — Dữ liệu có cấu trúc (schema): giúp Google hiểu nội dung là gì

Schema (dữ liệu có cấu trúc) là đoạn mã ẩn bạn thêm vào trang để mô tả rõ ràng nội dung của nó cho Google — đây là một bài viết, đây là một câu hỏi thường gặp, đây là một sản phẩm với giá này. Khai báo đúng schema giúp trang có cơ hội hiển thị dưới dạng kết quả nổi bật (rich result) — ngôi sao đánh giá, mục câu hỏi gấp gọn, thông tin sản phẩm — vốn thu hút nhiều lượt nhấp hơn.

Kiểm bằng đâu: công cụ Kiểm tra kết quả nhiều định dạng (Rich Results Test) của Google cho biết một trang có schema hợp lệ không và đủ điều kiện cho dạng kết quả nổi bật nào. Trình xác thực Schema.org giúp bắt lỗi cú pháp. Trong Search Console, mục "Cải tiến" (Enhancements) báo cáo các loại schema Google đã nhận diện cùng lỗi nếu có.

Ngưỡng "ổn": schema trên các loại trang chính (bài viết, sản phẩm, trang câu hỏi thường gặp, doanh nghiệp địa phương nếu áp dụng) phải hợp lệ, không lỗi, và quan trọng nhất là phản ánh đúng nội dung thật trên trang — không khai một đằng hiển thị một nẻo. Báo cáo "Cải tiến" trong Search Console không nên có lỗi tồn đọng.

Khi nào hành động: nếu Search Console báo lỗi schema trên một loại trang, sửa ở mẫu (template) để vá toàn bộ cùng lúc. Tuyệt đối tránh khai schema không khớp nội dung hiển thị — ví dụ gắn đánh giá sao mà trang không thực sự có đánh giá; đây là kiểu vi phạm Google phạt thẳng tay. Với web Việt, schema doanh nghiệp địa phương (địa chỉ, giờ mở cửa, số điện thoại) thường bị bỏ quên dù rất đáng làm cho các site có cửa hàng thật.

Mục 9 — HTTPS và bảo mật: nền móng tin cậy

HTTPS — kết nối có mã hóa, hiển thị bằng ổ khóa trên thanh địa chỉ — từ lâu đã là điều kiện cơ bản, không còn là điểm cộng. Một site không HTTPS, hoặc có chứng chỉ bảo mật trục trặc, sẽ bị trình duyệt cảnh báo "không an toàn" khiến người dùng quay đầu, và Google cũng coi đó là tín hiệu tiêu cực.

Kiểm bằng đâu: nhìn thanh địa chỉ trình duyệt khi vào site — phải có ổ khóa và bắt đầu bằng https. Để kiểm sâu chứng chỉ (còn hạn bao lâu, cấu hình đúng chưa), dùng một công cụ kiểm tra SSL trực tuyến. Một công cụ crawl toàn site giúp phát hiện "nội dung lẫn lộn" (mixed content) — tức trang HTTPS nhưng còn nhúng ảnh, mã hay tài nguyên qua HTTP, làm hỏng ổ khóa.

Ngưỡng "ổn": toàn bộ site chạy HTTPS, mọi URL HTTP đều redirect 301 sang bản HTTPS tương ứng, chứng chỉ còn hạn thoải mái (không sắp hết trong vài tuần tới), và không có nội dung lẫn lộn. Chỉ tồn tại một phiên bản chuẩn của site — không để cả http và https, cả có-www và không-www cùng truy cập được mà không chuyển hướng về một bản.

Khi nào hành động: chứng chỉ sắp hết hạn là việc khẩn — chứng chỉ hết hạn làm cả site hiện cảnh báo đỏ và lưu lượng rơi tự do, nên đây phải nằm trong nhóm cảnh báo tự động chứ không chờ đợt rà soát quý. Nếu phát hiện nội dung lẫn lộn, sửa các đường dẫn còn HTTP. Nếu cả nhiều phiên bản site cùng truy cập được, thiết lập redirect để gom về một bản chuẩn duy nhất — nếu không bạn đang chia nhỏ uy tín của chính mình ra nhiều bản trùng.

Mục 10 — Liên kết nội bộ và trang mồ côi: bản đồ Google đi theo

Liên kết nội bộ là cách Google đi từ trang này sang trang khác trong site của bạn, và cũng là cách uy tín lan tỏa giữa các trang. Một trang không có liên kết nội bộ nào trỏ tới — gọi là trang "mồ côi" (orphan page) — gần như vô hình với Google, dù nó vẫn tồn tại và vẫn nằm trong sitemap.

Kiểm bằng đâu: một công cụ crawl toàn site là cách duy nhất nhìn ra toàn cảnh kiến trúc liên kết — nó cho biết mỗi trang nhận bao nhiêu liên kết nội bộ, ở độ sâu nào tính từ trang chủ, và trang nào không có liên kết nào trỏ tới. Đối chiếu danh sách URL trong sitemap với danh sách URL công cụ crawl tìm thấy qua liên kết: những URL có trong sitemap mà crawl không gặp chính là trang mồ côi.

Ngưỡng "ổn": mọi trang quan trọng đều nằm trong vòng ba đến bốn lần nhấp từ trang chủ — càng sâu càng khó được crawl và xếp hạng. Các trang trụ cột, mang lại doanh thu hoặc lưu lượng lớn, nên nhận nhiều liên kết nội bộ. Không có trang giá trị nào bị mồ côi. Văn bản neo (anchor text) của liên kết nội bộ nên mô tả đúng trang đích, không phải những cụm chung chung vô nghĩa.

Khi nào hành động: nếu phát hiện trang mồ côi có giá trị, thêm liên kết nội bộ trỏ tới chúng từ các trang liên quan — đây thường là cách nhanh và rẻ nhất để hồi sinh một trang đang chìm. Nếu các trang quan trọng nằm quá sâu, nâng chúng lên bằng cách liên kết từ những trang gần trang chủ hơn. Đây là mục có sức bật cao: chỉ cần sửa lại một phần kiến trúc liên kết nội bộ, nhiều trang vốn ngủ yên có thể bắt đầu lên hạng mà không cần thêm một chữ nội dung nào.

Bảng checklist hằng quý — sao chép và dùng ngay

Dưới đây là toàn bộ mười mục gói gọn thành một bảng để bạn chạy theo. Mỗi lần rà soát, đi từ trên xuống, ghi lại trạng thái và việc cần làm cho từng mục.

1. Chỉ mục: Search Console → Lập chỉ mục trang. Ổn khi số trang đã lập chỉ mục xấp xỉ số trang giá trị. Hành động khi giảm đột ngột hoặc phình bất thường.
2. robots.txt và sitemap: đọc mắt file robots, kiểm sitemap trong Search Console. Ổn khi không chặn nhầm nội dung công khai, sitemap toàn URL 200 chuẩn. Hành động ngay nếu có Disallow chặn nội dung.
3. Tốc độ và Core Web Vitals: báo cáo Core Web Vitals + PageSpeed Insights. Ổn khi LCP dưới 2,5 giây, INP dưới 200 mili-giây, CLS dưới 0,1 ở di động. Hành động khi cụm URL rơi "Kém" trên di động.
4. Thân thiện di động: dùng thử trên điện thoại thật. Ổn khi nội dung đầy đủ, chữ đọc được, nút bấm vừa tay. Hành động khi bản di động thiếu nội dung hoặc khó dùng.
5. Lỗi crawl: Search Console → Số liệu thu thập dữ liệu. Ổn khi lỗi 5xx gần bằng không, 404 thấp và không quan trọng. Hành động khi có cụm 5xx hoặc 404 tăng vọt.
6. Redirect và 404: crawl toàn site. Ổn khi redirect là 301 một bước, không liên kết nội bộ trỏ tới trang chết. Hành động khi có chuỗi redirect hoặc liên kết gãy.
7. Canonical: Kiểm tra URL + crawl toàn site. Ổn khi mỗi trang có canonical hợp lý và Google chọn đúng bản đó. Hành động khi Google chọn khác hoặc trang tự loại mình.
8. Schema: Rich Results Test + Search Console → Cải tiến. Ổn khi schema hợp lệ và khớp nội dung thật. Hành động khi có lỗi hoặc khai sai lệch nội dung.
9. HTTPS và bảo mật: thanh địa chỉ + kiểm tra SSL. Ổn khi toàn site HTTPS, chứng chỉ còn hạn, không nội dung lẫn lộn. Hành động khi chứng chỉ sắp hết hạn hoặc còn HTTP.
10. Liên kết nội bộ và trang mồ côi: crawl toàn site, đối chiếu sitemap. Ổn khi trang quan trọng trong vòng ba đến bốn lần nhấp, không trang giá trị nào mồ côi. Hành động khi tìm thấy trang mồ côi hoặc trang quan trọng quá sâu.

Mẹo cuối: mỗi quý hãy lưu lại kết quả rà soát thành một bản ghi đơn giản — ngày chạy, mục nào ổn, mục nào phải sửa, đã sửa gì. So sánh giữa các quý quan trọng hơn bản thân một lần chạy, vì xu hướng mới là thứ tiết lộ liệu sức khỏe kỹ thuật của site đang đi lên hay đi xuống. Nếu bạn muốn một cách chấm điểm tổng hợp để theo dõi xu hướng đó qua thời gian, cách tiếp cận trong bài chấm điểm sức khỏe kỹ thuật trên thang 100 là một khung gọn để quy mười mục này về một con số dễ so sánh giữa các đợt.

Biến checklist thành thói quen, không phải sự kiện

Điều quan trọng nhất về một checklist technical SEO hằng quý không phải là sự hoàn hảo của từng mục, mà là sự đều đặn của cả quy trình. Một site được rà soát ở mức "tạm ổn" mỗi quý, đều như vắt chanh, sẽ luôn khỏe hơn một site được rà soát "hoàn hảo" một lần rồi bỏ bê hai năm. Lỗi kỹ thuật không sinh ra cùng lúc — chúng tích tụ dần theo mỗi lần deploy, mỗi lần đổi giao diện, mỗi lần ai đó "sửa nhanh một chút". Nhịp định kỳ là thứ duy nhất bắt kịp chúng.

Mười mục trên đây nhìn thì nhiều, nhưng phần lớn chỉ là đọc báo cáo và đối chiếu ngưỡng — công việc lặp lại, có quy trình rõ ràng, và đó chính là loại việc dễ rơi rớt nhất vì nó nhàm. Đây cũng là loại việc một AI agent làm SEO như Orova được sinh ra để gánh: chạy đều các phép kiểm theo lịch, đối chiếu với ngưỡng, và chỉ gọi bạn vào cuộc khi có thứ thực sự cần phán đoán của con người — chứ không bắt bạn nhớ tự mở mười báo cáo mỗi quý. Hãy giữ checklist này, chạy nó đúng nhịp, và để phần lặp lại cho thứ không bao giờ quên hay chán.