Kiểm tra sức khoẻ kỹ thuật website từ A đến Z

Phần lớn người làm website Việt Nam chỉ kiểm tra "sức khoẻ kỹ thuật" của trang khi có sự cố — traffic tụt, Google ngừng index, hoặc khách phàn nàn trang load chậm. Lúc đó vấn đề đã âm ỉ nhiều tuần, và việc sửa trở nên đắt đỏ và gấp gáp. Kiểm tra kỹ thuật đáng lẽ phải là một thói quen định kỳ, không phải một phản ứng khẩn cấp.

Bài viết này là một quy trình audit kỹ thuật website từ A đến Z — viết theo dạng hướng dẫn từng bước mà bạn có thể chạy lại mỗi quý. Nó không phải là danh sách dài vô tận cho chuyên gia; nó là vòng kiểm tra thực tế, có thứ tự hợp lý, bắt được những lỗi thật sự làm mất traffic, hoàn thành trong vài giờ tập trung. Mục tiêu là biến audit từ việc "khi nào nhớ ra thì làm" thành một quy trình lặp lại được, không bỏ sót.

Vì sao cần một checklist cố định

Có hai lý do khiến một checklist viết sẵn quan trọng hơn nhiều người nghĩ.

Thứ nhất, lỗi kỹ thuật SEO thường vô hình cho đến khi đã đắt giá. Một thẻ canonical sai, một thẻ noindex bị bỏ quên trên template sau khi redesign, một sitemap âm thầm ngừng cập nhật — không cái nào tự lên tiếng. Traffic không sụp đột ngột; nó bào mòn từ từ. Đến khi sự bào mòn lộ rõ trong báo cáo thì lỗi đã sống nhiều tuần. Một vòng audit định kỳ bắt được những lỗi này khi sửa còn rẻ.

Thứ hai, không có checklist cố định thì bạn audit thiếu nhất quán. Bạn sẽ kiểm tra những gì tình cờ nhớ ra hôm đó, và bỏ qua những thứ buồn tẻ nhưng thật sự quan trọng. Một checklist viết sẵn loại bỏ sự phụ thuộc vào trí nhớ: mỗi quý bạn chạy đúng các bước đó, theo đúng thứ tự đó. Checklist tồn tại không phải vì công việc khó, mà vì công việc dễ quên.

Nhịp độ hợp lý cho phần lớn website là mỗi quý — đủ thường xuyên để bắt lỗi sớm, đủ thưa để không thành việc vặt. Website rất lớn hoặc thay đổi liên tục có thể cần hàng tháng; website nhỏ và ổn định có thể hai lần một năm. Nhưng bốn lần một năm là mặc định nên giữ.

Bước một: khả năng thu thập và lập chỉ mục

Bắt đầu từ đây vì mọi thứ khác đều vô nghĩa nếu công cụ tìm kiếm không thể tiếp cận và index trang của bạn. Một trang được tối ưu hoàn hảo nhưng bị chặn thu thập hoặc bị gắn noindex thì đóng góp con số không.

Mở file robots.txt trước tiên và đọc từng dòng. Bạn tìm một thứ trên hết: một quy tắc Disallow đang chặn nhiều hơn mức cần thiết. Những lỗi robots.txt tai hại nhất thường không kỳ lạ — chúng là một dòng Disallow: / còn sót lại từ môi trường staging, hoặc một quy tắc thư mục vô tình bắt nhầm các trang quan trọng.

Tiếp theo, kiểm tra tình trạng index trong Google Search Console — báo cáo Pages. So sánh số trang được index với số trang bạn kỳ vọng được index. Một khoảng chênh lớn theo bất kỳ chiều nào đều là dấu hiệu. Index ít hơn nhiều so với kỳ vọng nghĩa là có trang đang bị loại trừ; đọc lý do loại trừ để biết vì sao. Index nhiều hơn nhiều so với kỳ vọng thường nghĩa là các trang mỏng, trùng lặp, hoặc trang tham số đã lọt vào chỉ mục.

Sau đó dùng một công cụ thu thập để quét cả site, tìm cụ thể những thẻ noindex lạc. Thảm hoạ kinh điển: một lần redesign hoặc migration gắn noindex lên template để chạy staging, site lên live, và thẻ đó không bao giờ được gỡ. Cả mảng nội dung âm thầm rơi khỏi chỉ mục.

Bước hai: sitemap XML

Sitemap nhỏ, dễ kiểm tra, và thường xuyên sai — nên đây là vài phút có lợi suất cao.

Mở sitemap và xác nhận ba điều. Một, nó chứa các URL nên được index — những trang thật, chuẩn canonical, có giá trị. Hai, nó không chứa các URL không nên có: trang noindex, URL đã redirect, trang 404, phiên bản không phải canonical. Một sitemap đầy URL rác gửi tín hiệu lẫn lộn. Ba, xác nhận nó thật sự đang cập nhật — các trang mới xuất bản có xuất hiện trong đó không. Một sitemap âm thầm ngừng tự tạo lại sau khi thay đổi CMS là một lỗi phổ biến và lặng lẽ.

Cuối cùng, kiểm tra trong Search Console rằng sitemap đã được gửi và được đọc không có lỗi.

Bước ba: thẻ canonical và trùng lặp

Đây là bước phát hiện những lỗi tinh vi và tai hại nhất, nên hãy làm chậm lại.

Thẻ canonical cho công cụ tìm kiếm biết phiên bản nào của một trang là phiên bản chính khi có nhiều URL tương tự tồn tại. Khi canonical đúng, chúng gom tín hiệu về đúng trang. Khi sai, chúng phá hoại website. Quét site và rà soát các thẻ canonical, tìm những mẫu lỗi cụ thể.

Trang canonical về URL sai — từng có những mảng site mà mọi trang đều canonical về trang chủ vì một lỗi template, thực chất bảo Google bỏ qua tất cả chúng. Trang không có canonical nào trong khi có trùng lặp. Thẻ canonical trỏ về một URL đã redirect hoặc 404. Và các URL tham số hoặc bộ lọc (sắp xếp, tracking, điều hướng phân lớp) không được canonical về phiên bản sạch, để site phải cạnh tranh với hàng chục bản sao của chính nó.

Cũng xem xét vấn đề liên quan chặt chẽ là nội dung trùng và gần trùng: nhiều URL phục vụ nội dung về cơ bản giống nhau, thường do tham số URL, sự không nhất quán http/https hay www/non-www, hoặc biến thể dấu gạch chéo cuối. Mỗi cụm trùng lặp là một nơi sức mạnh của site bị chia nhỏ thay vì tập trung.

Bước bốn: redirect và link gãy

Link gãy và redirect lộn xộn lãng phí công thu thập, làm rò rỉ giá trị liên kết, và tạo trải nghiệm tệ. Chúng tích tụ tự nhiên khi site lớn lên, và đó chính là lý do một vòng audit định kỳ là công cụ đúng để quản lý chúng.

Quét site và lấy ra mọi link nội bộ gãy — link nội bộ trỏ tới trang 404. Mỗi cái là một lỗ rò nhỏ: nó đưa người dùng và bộ thu thập tới ngõ cụt, và lãng phí giá trị liên kết mà link nội bộ đó lẽ ra phải truyền. Sửa bằng cách cập nhật link tới URL đúng hoặc gỡ bỏ.

Sau đó xem xét redirect. Tìm các chuỗi redirect — URL A redirect tới B redirect tới C — và rút gọn để URL gốc trỏ thẳng tới đích cuối. Tìm các vòng lặp redirect, vốn là lỗi hoàn toàn. Kiểm tra rằng các URL cũ quan trọng redirect tới trang thật sự liên quan, không phải lười biếng đẩy hết về trang chủ — Google thường coi đó là soft 404. Cũng xác nhận redirect dùng đúng loại: một lần chuyển vĩnh viễn phải là 301, không phải 302.

Bước năm: hiệu năng và Core Web Vitals

Tốc độ là một yếu tố xếp hạng thật sự, và ngoài xếp hạng nó còn định hình cảm giác của site. Đừng đuổi theo điểm số hoàn hảo; hãy tìm những vấn đề thật.

Kiểm tra báo cáo Core Web Vitals trong Search Console, vốn dùng dữ liệu người dùng thật — thước đo trung thực nhất về cách site thật sự hoạt động. Ghi lại bao nhiêu URL rơi vào nhóm "cần cải thiện" hoặc "kém", và ở chỉ số nào. Rồi chạy vài trang tiêu biểu — trang chủ, một landing page quan trọng, một bài blog điển hình — qua một công cụ lab như PageSpeed Insights để thấy các cơ hội cụ thể: ảnh quá khổ, tài nguyên chặn hiển thị, dịch chuyển bố cục do phần tử load mà không giữ chỗ.

Đừng cố sửa mọi thứ. Xác định hai hoặc ba vấn đề ảnh hưởng nhiều trang nhất hoặc các trang quan trọng nhất, và đó là phần việc hiệu năng của quý. Cải thiện đều đặn, có ưu tiên, thắng một đợt tối ưu hối hả chạm vào mọi thứ mà không hoàn tất gì.

Bước sáu: dữ liệu có cấu trúc

Nếu site dùng dữ liệu có cấu trúc (structured data) — và phần lớn nên dùng — thì nó cần được kiểm tra, vì structured data bị xuống cấp theo thời gian. Schema.org thay đổi, Google thay đổi loại nào được hiển thị kết quả nhiều định dạng, và việc thay đổi trang có thể làm hỏng markup từng hợp lệ ở quý trước.

Kiểm tra dữ liệu có cấu trúc trên các template trang chính bằng công cụ Rich Results Test của Google. Xác nhận markup vẫn hợp lệ, vẫn đủ điều kiện cho kết quả nhiều định dạng, và — quy tắc quan trọng nhất — vẫn mô tả chính xác nội dung thật sự hiển thị trên trang. Nếu một template đã đổi và markup giờ tham chiếu nội dung không còn ở đó nữa, đánh dấu lại. Dữ liệu có cấu trúc lệch khỏi trang của nó còn tệ hơn không có dữ liệu có cấu trúc.

Bước bảy: mobile và HTTPS

Bước cuối kiểm hai hạng mục nền tảng thường vẫn ổn nhưng tai hại khi không ổn, nên đáng kiểm tra một cách có chủ ý.

Mobile: Google index phiên bản di động của site, nên hãy mở các trang quan trọng ở khung nhìn mobile và xác nhận toàn bộ nội dung có mặt, bố cục dùng được, và không có gì quan trọng bị ẩn hay hỏng trên màn hình nhỏ. Những site mà phiên bản mobile âm thầm hiển thị ít nội dung hơn desktop đang đưa cho Google một trang không đầy đủ để index.

HTTPS: xác nhận chứng chỉ bảo mật còn hiệu lực và không sắp hết hạn, cả site load qua HTTPS, các phiên bản HTTP redirect đúng sang HTTPS, và không có nội dung hỗn hợp — trang bảo mật load tài nguyên không bảo mật. Một chứng chỉ hết hạn là sự cố khẩn cấp thật sự, và một vòng audit theo lịch sẽ bắt được hạn sắp tới trước khi nó thành sự cố.

Xử lý kết quả audit thế nào

Một vòng audit tạo ra danh sách mà không ai hành động chỉ là hình thức. Khi hoàn tất bảy bước, bạn có một danh sách lỗi, và hãy làm hai việc với nó.

Thứ nhất, phân loại theo mức ảnh hưởng, không theo độ dễ. Một thẻ noindex trên template quan trọng, một lỗi canonical toàn site, một chứng chỉ sắp hết hạn — những thứ này lên đầu bất kể các mục khác có thể tick nhanh đến đâu. Cám dỗ luôn là dọn các việc dễ trước; hãy cưỡng lại, vì những lỗi đắt giá mới là lý do vòng audit tồn tại.

Thứ hai, ghi lại kết quả với đủ ngữ cảnh để vài tuần sau vẫn hành động được, và giữ lại danh sách của quý trước. So sánh quý này với quý trước cho thấy site có thật sự khoẻ lên không, hay cùng những lỗi đó cứ tái xuất hiện — điều thường nghĩa là vấn đề ở quy trình, không phải lỗi một lần.

Sai lầm thường gặp khi audit kỹ thuật

Có vài sai lầm khiến vòng audit kém hiệu quả, và đáng nêu tên để tránh.

Sai lầm thứ nhất là chỉ audit khi có sự cố. Như đã nói, lúc đó lỗi đã đắt. Audit phải theo lịch, không theo cảm xúc hoảng loạn.

Sai lầm thứ hai là đuổi theo điểm số của công cụ thay vì lỗi thật. Một công cụ có thể hạ điểm site vì hàng trăm thẻ meta description thiếu — một vấn đề nhỏ — trong khi bỏ lỡ một template noindex. Đừng để con số tổng quát thay thế việc đọc từng lỗi và đánh giá mức nghiêm trọng thật của nó.

Sai lầm thứ ba là audit rồi không sửa. Một danh sách lỗi không được xử lý chỉ làm bạn yên tâm giả tạo rằng "đã audit rồi". Vòng audit chỉ có giá trị khi nối liền với hành động sửa, được ưu tiên theo mức ảnh hưởng.

Sai lầm thứ tư là quên audit phiên bản mobile như một thứ riêng. Vì Google index mobile trước, kiểm tra desktop là chưa đủ — nội dung và markup trên mobile mới là thứ Google thật sự nhìn thấy.

Orova hỗ trợ ở đâu

Bạn có thể chạy vòng audit này hoàn toàn bằng tay, và với một site nhỏ thì cứ làm vậy. Nhưng audit kỹ thuật có hai đặc tính khiến nó âm thầm mệt mỏi ở quy mô lớn: nó lặp đi lặp lại, và nó phụ thuộc vào việc bạn nhớ làm. Các đợt quét dài để phát hiện lỗi canonical và link gãy thì tẻ nhạt để rà soát. Vòng audit có giá trị chính vì nó buồn tẻ — và buồn tẻ là đúng thứ bị bỏ qua khi một quý bận rộn.

Đây là phần việc mà một AI agent SEO thật sự cải thiện được. Orova có thể chạy những bước này liên tục thay vì bốn lần một năm — quét site, kiểm tra tình trạng index và canonical, phát hiện link gãy và chuỗi redirect, theo dõi Core Web Vitals, kiểm tra dữ liệu có cấu trúc — và đánh dấu những gì đã thay đổi cùng những gì cần chú ý, để lỗi lộ ra trong vài ngày thay vì chờ đến kỳ audit tiếp theo. Phán đoán trong checklist này vẫn quan trọng: quyết định lỗi nào nghiêm trọng, phân loại theo mức ảnh hưởng, nhận ra khi nào một mẫu lỗi báo hiệu vấn đề quy trình. Nhưng việc theo dõi miệt mài và dễ quên thì đúng là việc một agent nên gánh. Để hiểu thêm nền tảng này, xem bài mô hình cụm chủ đề.

Bạn không cần đợi traffic tụt mới bắt đầu audit. Đặt một lời nhắc lặp lại trên lịch, chạy bảy bước này theo thứ tự, phân loại kết quả theo mức ảnh hưởng, và giữ lại danh sách. Vòng audit đầu tiên sẽ tìm ra nhiều hơn bạn nghĩ. Mỗi vòng audit sau đó giữ một lỗi nhỏ khỏi trở thành lỗi đắt giá — và đó chính là toàn bộ ý nghĩa của nó.