Hướng dẫn về 200 OK

Tóm tắt — Phản hồi 200 OK có nghĩa là máy chủ đang nói: “đây là trang bạn yêu cầu, mọi thứ đều ổn”. Đây là mã thành công âm thầm mà bạn muốn thấy trên mọi trang cần xuất hiện trong Google. Tuy nhiên, riêng mã 200 không bảo đảm trang sẽ được lập chỉ mục — Google vẫn đánh giá nội dung có đáng được lập chỉ mục hay không. Một trang hỏng hoặc trống nhưng vẫn trả về 200 là lỗi cấu hình, không phải tín hiệu tốt.

200 OK có nghĩa là gì

Mỗi khi trình duyệt hoặc Googlebot yêu cầu máy chủ cung cấp một trang, máy chủ trả lời bằng mã trạng thái gồm ba chữ số trước khi gửi dữ liệu khác. 200 OK là trường hợp “mọi thứ đều ổn”: máy chủ đã tìm thấy tài nguyên được yêu cầu và trả nó về, thông thường kèm nội dung trang. Về kỹ thuật, đặc tả cho phép phản hồi 200 có thân rỗng trong một số trường hợp; nhưng với trang dành cho người đọc, bạn cần một thân phản hồi thực. Đây là mã ít được chú ý vì nó cho biết không có lỗi ở tầng HTTP. Evidence for this claim RFC 9110 defines 200 OK as indicating that the request succeeded; the response content depends on the request method. Scope: HTTP semantics for 200 responses; this does not guarantee search indexing. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.3.1 — 200 OK

Patrick Stox tóm tắt trong ba từ trong hướng dẫn về mã trạng thái HTTP của Ahrefs: “200 OK – All good. Everything is successful.” (bản dịch) «Mọi thứ đều ổn. Mọi thao tác đều thành công.»

Với những trang trên website mà bạn muốn người dùng tìm thấy qua công cụ tìm kiếm, 200 chính là mã cần trả về.

Vì sao mã 200 chưa nói lên toàn bộ câu chuyện

Đây là điểm nhiều trang giải thích “200 có nghĩa là gì” bỏ qua: mã 200 giúp trang được xem xét để lập chỉ mục, chứ không bảo đảm trang sẽ vào chỉ mục. Hai điều này rất khác nhau.

Hãy xem mã 200 như tấm vé đưa bạn qua cửa. Sau đó Google vẫn quyết định nội dung có đáng giữ lại hay không: chất lượng có cao không, có gần trùng với trang khác không, nội dung có mỏng hoặc trống không, hay có thẻ noindex yêu cầu Google đứng ngoài không? Bất kỳ yếu tố nào cũng có thể khiến một trang trả 200 hoàn toàn bình thường vẫn không được lập chỉ mục.

Vì vậy, nếu trang trả về 200 nhưng không xuất hiện trên Google, vấn đề thường không nằm ở mã trạng thái mà ở nội dung hoặc cách cấu hình.

Cạm bẫy: trả 200 cho trang thực chất là “không tìm thấy”

Sai sót khó nhận biết nhất là trang trả về 200 nhưng nội dung lại nói rằng tài nguyên không tồn tại. Ví dụ gồm trang sản phẩm hết hàng nhưng trống, bài viết đã xóa vẫn tải template rỗng, hoặc trang kết quả tìm kiếm không có mục nào. Máy chủ vui vẻ gửi 200 nhưng trên trang không có giá trị thực.

Google xem cả nội dung thay vì chỉ nhìn mã, nhận ra trang trống hoặc giống trang lỗi, rồi gắn nhãn soft 404 trong Search Console — xử lý tương tự một trang thực sự không tìm thấy. Bài soft-404-errors giải thích chi tiết; phiên bản ngắn là: nếu trang đã biến mất thật, hãy trả về 404 hoặc 410 thay vì 200.

Quy tắc duy nhất cần nhớ

Trang bạn muốn xuất hiện trong Google phải trả về 200 và có nội dung thực. Nếu trang đã biến mất, dùng 404 hoặc 410. Nếu trang đã chuyển, dùng chuyển hướng 301. Nếu trang trùng với trang khác, dùng thẻ canonical. Muốn xem nguyên văn hướng dẫn của Google, sự khác biệt giữa 200 và 204, cùng cách kiểm tra phản hồi Googlebot thực sự nhận? Hãy chuyển sang thẻ Nâng cao.

Tóm tắt — 200 OK là mã thành công tiêu chuẩn thuộc nhóm 2xx (RFC 9110 §15.3.1): máy chủ đã hoàn thành yêu cầu và, với GET/HEAD, thân phản hồi biểu diễn tài nguyên. Theo mặc định, phản hồi có thể được lưu đệm theo suy đoán. Với SEO, mã này cần thiết nhưng chưa đủ: tài liệu của Google nói hệ thống “may index the content, but that’s not guaranteed,” (bản dịch) «có thể lập chỉ mục nội dung, nhưng điều đó không được bảo đảm»; chất lượng, trùng lặp, nội dung mỏng và noindex vẫn quyết định kết quả. Lỗi điển hình là soft 404: mã 200 bao quanh nội dung lỗi hoặc trống, khiến Google phát hiện ở tầng nội dung và báo soft 404 bất kể mã. Hãy phân biệt 200 (dự kiến có thân phản hồi), 204 (thân rỗng, bị xử lý như soft 404 trên trang) và 304 (tín hiệu bộ nhớ đệm, không phải quyết định lập chỉ mục). Đồng thời phải xác minh điều Googlebot nhận được, vì cloaking, chặn bot, quy tắc địa lý hoặc cấu hình CDN/WAF có thể trả mã khác với trình duyệt.

Ý nghĩa của 200 trong đặc tả

RFC 9110 (HTTP Semantics) là tài liệu có thẩm quyền hiện hành, và §15.3.1 nói rõ: “The 200 (OK) status code indicates that the request has succeeded.” (bản dịch) «Mã trạng thái này cho biết yêu cầu đã thành công.» Nội dung thân phản hồi phụ thuộc vào phương thức yêu cầu. Với GET và HEAD — hai phương thức quan trọng cho trang — nội dung biểu diễn tài nguyên đích. RFC cũng nêu ngoại lệ: ngoài phản hồi cho CONNECT, mã 200 được kỳ vọng có nội dung trừ khi khung thông điệp báo rõ độ dài bằng 0. Vì vậy, “200 luôn có thân phản hồi” chỉ là cách nói tắt, không phải quy tắc tuyệt đối. Trong thực tế, trang cần được lập chỉ mục phải có thân phản hồi thực. Theo mặc định, 200 còn “có thể lưu đệm theo suy đoán” trừ khi chỉ thị cache-control quy định khác; đó là lý do các header xác thực như ETag và Last-Modified quan trọng với trang được crawl lại thường xuyên. Evidence for this claim RFC 9110 defines 200 OK as indicating that the request succeeded; the response content depends on the request method. Scope: HTTP semantics for 200 responses; this does not guarantee search indexing. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.3.1 — 200 OK

Về kỹ thuật, mã 200 không chỉ dành cho trang. RFC mô tả ý nghĩa của “thành công” theo từng phương thức:

Với phương thức khác GET, bạn thường không thấy mã 200. MDN lưu ý rằng yêu cầu PUT hoặc DELETE thành công “often do not result in a 200 OK response,” (bản dịch) «thường không tạo ra phản hồi 200 OK»; 201 Created hoặc 204 No Content phổ biến hơn. Điều này không liên quan trực tiếp đến SEO của URL trang. Điểm cần nhớ là tài liệu muốn được lập chỉ mục nên trả 200 cùng thân phản hồi thực.

Cần thiết nhưng chưa đủ để lập chỉ mục

Đây là điểm quan trọng nhất và cũng là chỗ nhiều trang thuật ngữ giải thích sai khi nói “200 nghĩa là trang được lập chỉ mục”. Tài liệu của Google nói: “passes on whatever it received to the next processing step… For Google Search, the next system is the indexing pipeline. The indexing systems may index the content, but that’s not guaranteed.” (bản dịch) «Google chuyển mọi thứ đã nhận sang bước xử lý tiếp theo; với Google Search, đó là quy trình lập chỉ mục. Hệ thống có thể lập chỉ mục nội dung, nhưng điều đó không được bảo đảm.» Evidence for this claim Google passes a 2xx response to its indexing pipeline, which may index the content but does not guarantee that it will do so; error-like content can be classified as a soft 404. Scope: Google Search handling of 2xx page responses and soft 404s. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search

Vì vậy, mã 200 là cam kết về phản hồi HTTP, không phải lời hứa về số phận của trang trong Search. Sau mã 200, Google đánh giá độc lập:

• Chất lượng — trang mỏng, ít giá trị hoặc được tạo tự động có thể không được lập chỉ mục.
• Trùng lặp — trang gần trùng với URL mạnh hơn có thể được hợp nhất vào URL đó thay vì tự được lập chỉ mục; thẻ canonical giúp kiểm soát việc này.
• Chỉ thị — noindex trong thẻ meta hoặc header X-Robots-Tag loại trang khỏi chỉ mục ngay cả khi phản hồi 200 hoàn hảo.

Hướng dẫn của Patrick trên Ahrefs cũng phân biệt ở cấp nhóm mã: “Most 2xxs will allow pages to be indexed. However, 204s will be treated as soft 404s and won’t be indexed.” (bản dịch) «Hầu hết phản hồi thành công cho phép trang được lập chỉ mục; phản hồi không có nội dung sẽ bị xử lý như trang lỗi mềm và không được lập chỉ mục.» Mã 200 chỉ giúp trang đủ điều kiện, không biến trang thành đã lập chỉ mục.

Cạm bẫy soft 404

Ví dụ rõ nhất cho việc “200 chưa nói lên toàn bộ câu chuyện” là soft 404. Tài liệu về mã trạng thái của Google mô tả cơ chế: “If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error.” (bản dịch) «Nếu nội dung gợi ra lỗi đối với Google Search, chẳng hạn trang trống hoặc thông báo lỗi, Search Console sẽ hiển thị lỗi mềm.» Điều này cho thấy việc phân loại dựa trên nội dung được kết xuất, không chỉ mã HTTP. Quy trình lập chỉ mục nhìn qua mã 200; nếu trang giống “không tìm thấy”, trang sẽ được xếp và báo cáo như lỗi thật.

Các trường hợp cần kiểm tra nhanh gồm sản phẩm đã ngừng bán nhưng chỉ tải template trống, bài viết đã xóa vẫn trả về khung trang 200, hoặc danh mục đã lọc hay kết quả tìm kiếm không có mục nào và chỉ hiện thông báo “không có gì ở đây”. Tất cả đều trả mã đúng về kỹ thuật nhưng lại nói với người dùng và Google rằng không có nội dung đáng xem.

Website này có bài soft-404-errors riêng về cơ chế phát hiện và cách sửa. Điều cần rút ra ở đây là: trả về 200 cho trang thực sự đã biến mất chính là tiền đề tạo soft 404. Cách sửa là để mã phản ánh đúng thực tế.

Cạm bẫy liên quan: truyền tải thành công không đồng nghĩa ứng dụng thành công

Một điểm cần lưu ý trong API và giám sát là tầng HTTP và tầng ứng dụng có thể bất đồng. Endpoint API có thể trả 200 nhưng thân JSON chứa đối tượng lỗi; trang có thể trả 200 trong khi dependency phía sau thất bại và chỉ kết xuất một khối hỏng. Dòng trạng thái chỉ nói dữ liệu đã được chuyển ở tầng giao thức; payload có đúng hay không là câu hỏi riêng. Các nhóm có thể chọn báo lỗi API bằng mã khác 200 hoặc bọc payload lỗi trong 200 — đó là hợp đồng ứng dụng, không phải quy tắc HTTP. Với SEO, phiên bản cấp trang chính là soft 404: đừng chỉ tin dòng trạng thái, hãy kiểm tra thân phản hồi.

200, 204 và 304 — đừng đánh đồng

Ba mã thường bị nhầm lẫn, nhưng chỉ một mã mang nghĩa “đây là trang bạn yêu cầu”:

204 là mã thành công thật, nhưng thân rỗng khiến crawler không có gì để lập chỉ mục; vì vậy, trên URL trang nó rơi vào nhóm soft 404 (được giải thích ở bài riêng). 304 thuộc nhóm khác và trả lời yêu cầu có điều kiện (If-None-Match / If-Modified-Since) bằng cách yêu cầu client dùng bản đã lưu. Nó không có thân phản hồi và không nói gì về việc lập chỉ mục; đây là cơ chế tối ưu hiệu quả crawl, không phải phiên bản khác của 200.

Xác minh điều Googlebot thực sự thấy

Một khoảng trống nhiều bài khác bỏ qua là những bên gửi yêu cầu khác nhau có thể nhận mã khác nhau cho cùng URL. Trình duyệt có thể thấy 200 trong khi Googlebot nhận phản hồi khác — đôi khi do cloaking cố ý, vốn vi phạm chính sách spam của Google, nhưng thường do quy tắc WAF/chặn bot, nhắm mục tiêu theo IP địa lý, logic CDN ở edge hoặc thử nghiệm A/B xử lý bot sai.

Vì vậy, “trình duyệt của tôi thấy 200” không chứng minh “Google thấy 200”. Chẩn đoán đúng là kiểm tra phản hồi mà chính Googlebot nhận:

• URL Inspection trong GSC — chạy Live Test để xem trạng thái và nội dung được kết xuất mà Google tìm nạp, thay vì phản hồi máy của bạn nhận.
• Nhật ký máy chủ / CDN — bằng chứng gốc về mã mà từng user agent thực sự nhận.

Lệnh curl -I trong terminal rất hữu ích, nhưng đó chỉ là một bên gửi yêu cầu khác và có thể đi qua quy tắc edge khác Googlebot. Hãy coi kết quả là một điểm dữ liệu, không phải kết luận cuối cùng.

Cách kiểm tra và giám sát phản hồi 200

• Browser DevTools — mở thẻ Network, tải lại trang, chọn yêu cầu document và đọc cột Status.
• Dòng lệnh — dùng curl -I https://example.com/page để xem header của một yêu cầu; dùng curl -IL để đi theo chuỗi chuyển hướng.
• Google Search Console — URL Inspection báo trạng thái đã crawl và cung cấp Live Test.
• Bing Webmaster Tools — URL Inspection giúp xác nhận phản hồi Bingbot nhận. Bing không xuất bản tài liệu riêng về tác động của mã trạng thái đến lập chỉ mục như Google, nên không nên tự suy diễn chính sách.
• Crawler — Screaming Frog và Ahrefs Site Audit tổng hợp mã trạng thái trên toàn website; Ahrefs SEO Toolbar miễn phí hiển thị mã của trang hiện tại.

Trạng thái “khỏe mạnh” nghĩa là các URL canonical quan trọng luôn trả về 200 cùng nội dung thực, còn trang đáng lẽ đã mất hoặc đã chuyển thì trả 404/410 hoặc 301 thay vì mã 200 gây hiểu lầm.

Quyết định trong một câu

Hãy để mã phản ánh đúng thực tế. Muốn có trong chỉ mục → 200 với nội dung thực chất. Đã biến mất vĩnh viễn → 404 hoặc 410 (xem 404-not-found). Đã chuyển địa chỉ → 301. Trùng lặp với URL khác → đặt thẻ canonical trỏ đến phiên bản ưu tiên thay vì cố dùng mã khác 200. Mã 200 là đèn xanh cho những trang thực sự xứng đáng — không hơn, không kém.

Tóm tắt bằng AI

Bản tóm lược của phần Nâng cao:

• 200 OK là mã thành công tiêu chuẩn thuộc nhóm 2xx (RFC 9110 §15.3.1): máy chủ đã hoàn thành yêu cầu và, với GET/HEAD, thân phản hồi biểu diễn tài nguyên. Theo mặc định, phản hồi này có thể được lưu vào bộ nhớ đệm theo suy đoán. RFC xem việc có thân phản hồi là điều được kỳ vọng, không phải tuyệt đối — phản hồi 200 dài 0 byte vẫn hợp lệ về kỹ thuật, dù một trang cần được lập chỉ mục phải có nội dung thực.
• Cần thiết nhưng chưa đủ để lập chỉ mục. Tài liệu của Google nói hệ thống lập chỉ mục “may index the content, but that’s not guaranteed.” (bản dịch) «có thể lập chỉ mục nội dung, nhưng điều đó không được bảo đảm». Chất lượng, trùng lặp, nội dung mỏng và noindex vẫn được đánh giá sau mã 200. Nhiều trang giải thích sai khi đồng nhất “200” với “đã lập chỉ mục”.
• Cạm bẫy soft 404: phản hồi 200 bao quanh nội dung lỗi hoặc trống sẽ bị phát hiện ở tầng nội dung và được báo là soft 404 trong Search Console. Google nói: “if the content suggests an error… Search Console will show a soft 404 error.” (bản dịch) «nếu nội dung cho thấy có lỗi… Search Console sẽ hiển thị lỗi soft 404». Một trang thực sự đã biến mất nhưng vẫn trả 200 tạo ra chính tình huống này. Xem bài soft-404-errors.
• Một cạm bẫy tương tự: tầng HTTP và tầng ứng dụng có thể bất đồng — mã 200 có thể bao quanh payload lỗi API hoặc một khối backend bị hỏng âm thầm. Dòng trạng thái chỉ xác nhận truyền tải thành công, không xác nhận payload đúng.
• 200 so với 204 và 304: 200 = thành công với thân phản hồi thực (đủ điều kiện lập chỉ mục); 204 = thành công nhưng thân rỗng, bị xử lý như soft 404 trên URL trang (xem 204-no-content); 304 = tín hiệu bộ nhớ đệm trả lời yêu cầu có điều kiện, không phải quyết định lập chỉ mục.
• Xác minh điều Googlebot nhận được. Cùng một URL có thể trả mã khác nhau do cloaking, chặn bot, quy tắc địa lý hoặc cấu hình CDN/WAF. “Trình duyệt thấy 200” không đồng nghĩa “Google thấy 200”. Hãy kiểm tra bằng Live Test trong URL Inspection của GSC hoặc nhật ký máy chủ, không chỉ bằng trình duyệt hay curl.
• Để mã phản ánh đúng thực tế: cần giữ → 200 với nội dung thực; đã mất → 404/410; đã chuyển → 301; trùng lặp → thẻ canonical. Theo cách Patrick tóm tắt, mã này cho biết mọi thứ đều ổn và yêu cầu đã thành công — khi trang thực sự xứng đáng tồn tại.

Tài liệu chính thức

Các nguồn sơ cấp giải thích mã 200 và cách Google xử lý mã này.

Đặc tả HTTP và tài liệu trình duyệt

• RFC 9110 §15.3.1 — 200 OK — định nghĩa có thẩm quyền: yêu cầu thành công, ngữ nghĩa thân phản hồi theo từng phương thức và khả năng lưu đệm theo suy đoán.
• MDN — 200 OK — cách giải thích dễ hiểu, khả năng lưu đệm mặc định và sắc thái của PUT/DELETE (thường dùng 201/204 thay thế).

Google Search Central

• Ảnh hưởng của mã trạng thái HTTP cùng lỗi mạng và DNS đến Google Search — cách xử lý phản hồi 2xx, trong đó khả năng lập chỉ mục không được bảo đảm, và tham chiếu đến soft 404.
• Lỗi soft 404 — Báo cáo lập chỉ mục trang — định nghĩa của Google về trường hợp trả 200 nhưng thực chất là lỗi, cùng lý do không nên trả mã thành công cho trang đã biến mất.
• Cloaking — lý do một URL có thể phục vụ mã hoặc nội dung khác nhau cho người dùng và Googlebot, cũng như vì sao đây là vi phạm khi nhằm thao túng thứ hạng.

Bing / Microsoft

• Bing Webmaster Tools — URL Inspection — cách phía Bing xác minh phản hồi HTTP mà Bingbot nhận cho một URL. (Bing không xuất bản tài liệu riêng tương đương về tác động của mã trạng thái đến lập chỉ mục.)

Trích dẫn từ nguồn

Các phát biểu được ghi nhận công khai. Mỗi liên kết sâu dẫn đến đoạn được trích trên trang nguồn.

Đặc tả HTTP

• “The 200 (OK) status code indicates that the request has succeeded.” (bản dịch) «Mã trạng thái 200 (OK) cho biết yêu cầu đã thành công.» — RFC 9110, HTTP Semantics, §15.3.1. Đọc mục này

MDN Web Docs

• “The HTTP 200 OK success status response code indicates that a request has succeeded. A 200 OK response is cacheable by default.” (bản dịch) «Mã phản hồi thành công HTTP 200 OK cho biết một yêu cầu đã thành công. Theo mặc định, phản hồi 200 OK có thể được lưu vào bộ nhớ đệm.» Đi đến trích dẫn

Google Search Central — cách xử lý 2xx / 200

• “Google passes on whatever it received to the next processing step (which is product specific). For Google Search, the next system is the indexing pipeline. The indexing systems may index the content, but that’s not guaranteed.” (bản dịch) «Google chuyển mọi thứ đã nhận sang bước xử lý tiếp theo (tùy từng sản phẩm). Với Google Search, hệ thống tiếp theo là quy trình lập chỉ mục. Hệ thống lập chỉ mục có thể lập chỉ mục nội dung, nhưng điều đó không được bảo đảm.» — tài liệu về mã trạng thái HTTP của Google, mục 200. Tài liệu về mã trạng thái của Google

• “If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error.” (bản dịch) «Nếu nội dung gợi ra lỗi đối với Google Search, chẳng hạn trang trống hoặc thông báo lỗi, Search Console sẽ hiển thị lỗi soft 404.» — cùng tài liệu, phần tham chiếu về soft 404. Tài liệu về mã trạng thái của Google

Patrick Stox — Ahrefs

• “200 OK – All good. Everything is successful.” (bản dịch) «200 OK – Mọi thứ đều ổn. Mọi thao tác đều thành công.» — từ hướng dẫn về mã trạng thái HTTP của tôi trên blog Ahrefs. Đi đến trích dẫn

• “Most 2xxs will allow pages to be indexed. However, 204s will be treated as soft 404s and won’t be indexed.” (bản dịch) «Hầu hết phản hồi 2xx cho phép trang được lập chỉ mục. Tuy nhiên, phản hồi không có nội dung sẽ bị xử lý như soft 404 và không được lập chỉ mục.» — từ cùng hướng dẫn, về cách Google xử lý nhóm 2xx. Đi đến trích dẫn

200 OK — bảng tham khảo nhanh

Thông tin cơ bản

So sánh 200 với các mã thường bị nhầm lẫn

URL này nên trả về mã nào?

• Muốn có trong chỉ mục → 200 với nội dung thực và có giá trị.
• Đã biến mất vĩnh viễn → 404 hoặc 410 (xem 404-not-found).
• Đã chuyển sang URL mới → 301.
• Trùng lặp với URL khác → giữ mã 200 và thêm thẻ canonical trỏ đến phiên bản ưu tiên.
• Cố ý để trống (API/beacon) → 204 (xem 204-no-content) — không dùng cho trang.

Thông tin nhanh

• Mã 200 chỉ mở đường cho việc lập chỉ mục; Google vẫn quyết định riêng dựa trên chất lượng, trùng lặp, nội dung mỏng và noindex.
• Mã 200 trên một trang thực tế đã biến mất hoặc trống là soft 404 trong cách nhìn của Google.
• Những bên gửi yêu cầu khác nhau có thể nhận mã khác nhau cho cùng URL — hãy xác minh điều Googlebot nhận bằng URL Inspection của GSC hoặc nhật ký máy chủ, không chỉ bằng trình duyệt hay curl.
• Kiểm tra mã bằng thẻ Network trong DevTools, curl -I / curl -IL, URL Inspection của GSC/Bing, Screaming Frog hoặc Ahrefs Site Audit/Toolbar.

Những hiểu lầm phổ biến về 200 OK

“Mã trạng thái 200 nghĩa là trang đã được lập chỉ mục.” Sai. Mã 200 chỉ xác nhận máy chủ trả nội dung thành công; việc có đưa URL vào chỉ mục hay không được quyết định ở bước sau. Tài liệu của Google nói hệ thống “may index the content, but that’s not guaranteed.” (bản dịch) «có thể lập chỉ mục nội dung, nhưng điều đó không được bảo đảm». Google còn xem xét chất lượng, mức độ trùng lặp, độ mỏng của nội dung và chỉ thị noindex.

“Nếu Search Console báo soft 404 thì máy chủ của tôi bị lỗi.” Không nhất thiết. Soft 404 không phải mã máy chủ gửi; đó là nhãn Google áp dụng khi mã 200 không khớp với nội dung trông giống trang lỗi hoặc trang trống. Máy chủ đang làm đúng cấu hình là gửi 200; vấn đề nằm ở nội dung, không phải header.

“200 lúc nào cũng tốt.” Không phải vậy. Mã 200 trên URL đáng lẽ phải trả 404 — như sản phẩm đã xóa, tin đăng hết hạn hoặc trang kết quả tìm kiếm trống — là tín hiệu xấu. Nó dễ dẫn đến xử lý soft 404 và lãng phí tài nguyên crawl cho URL không còn giá trị.

“Trình duyệt của tôi thấy 200 nên Google chắc chắn cũng thấy 200.” Không được bảo đảm. Quy tắc chặn bot, cloaking, định vị theo IP và cấu hình CDN/WAF có thể phục vụ cho Googlebot một phản hồi khác với trình duyệt người dùng. Hãy xác minh bằng URL Inspection hoặc nhật ký máy chủ.

“200 và 204 về cơ bản giống nhau vì đều là thành công.” Cả hai đều thuộc nhóm 2xx, nhưng 204 có thân phản hồi rỗng theo thiết kế. Điều đó phù hợp với API và beacon nhưng không phù hợp với trang cần lập chỉ mục — mã 204 trên URL trang bị xử lý như soft 404 (xem 204-no-content).

“200 và 304 có phải cùng một ý tưởng không?” Không. 304 Not Modified là cơ chế bộ nhớ đệm trả lời yêu cầu có điều kiện (If-None-Match / If-Modified-Since), yêu cầu client dùng bản đã lưu. Nó không có thân phản hồi và không phải quyết định lập chỉ mục — hoàn toàn khác với 200.

Vì sao trang 200 OK vẫn thất bại

Search Console gọi URL là soft 404

Triệu chứng: URL trả về 200, nhưng báo cáo Lập chỉ mục trang ghi nhận soft 404.

Nguyên nhân có thể: Thân phản hồi trống, hỏng hoặc giống trang lỗi. Các trường hợp thường gặp gồm sản phẩm đã ngừng bán nhưng không còn thông tin hữu ích, bài viết đã xóa nằm trong một template vẫn đầy đủ, hoặc trang tìm kiếm không có kết quả.

Cách sửa: Làm cho phản hồi khớp với thực tế. Khôi phục nội dung thực chất nếu trang vẫn cần tồn tại; trả về 404 hoặc 410 nếu trang đã mất; hoặc dùng 301 nếu trang đã chuyển. Chạy lại Live Test trong URL Inspection và xác nhận phản hồi khớp với nội dung được kết xuất.

Trình duyệt nhận 200 nhưng Googlebot không nhận

Triệu chứng: DevTools hoặc curl hiển thị 200, trong khi Google không thể tìm nạp hoặc lập chỉ mục URL.

Nguyên nhân có thể: CDN, WAF, quy tắc địa lý, quy tắc bot hoặc thử nghiệm phục vụ phản hồi khác cho Googlebot. Yêu cầu của bạn không chứng minh phản hồi Google nhận được.

Cách sửa: So sánh yêu cầu bình thường với yêu cầu dùng user agent Googlebot, rồi kiểm tra URL Inspection và nhật ký máy chủ/CDN. Sửa quy tắc ở edge và xác nhận Live Test nhận 200 với cùng nội dung thực chất mà người dùng nhận.

Trang trả 200 nhưng vẫn không được lập chỉ mục

Triệu chứng: Mã trạng thái bình thường nhưng URL vẫn bị loại khỏi chỉ mục.

Nguyên nhân có thể: 200 chỉ khiến nội dung đủ điều kiện được xử lý. noindex, xung đột trùng lặp/canonical hoặc nội dung ít giá trị vẫn có thể khiến trang không được lập chỉ mục.

Cách sửa: Đừng tiếp tục thay đổi mã trạng thái. Hãy kiểm tra chỉ thị lập chỉ mục, canonical do Google chọn và nội dung thực tế. Phản hồi HTTP thành công không phải phán quyết lập chỉ mục.

Những phản hồi 200 kể sai câu chuyện

Đây là các ví dụ đơn giản hóa. Dòng trạng thái thành công về kỹ thuật, nhưng thân phản hồi mới quyết định thành công đó có phản ánh đúng thực tế hay không.

Trang sản phẩm rỗng: mã 200 gây hiểu lầm

HTTP/1.1 200 OK
Content-Type: text/html

<h1>Product unavailable</h1>
<p>There is nothing here.</p>

Nếu sản phẩm đã biến mất vĩnh viễn và không có sản phẩm thay thế, hãy trả về 404 hoặc 410. Nếu vẫn còn một trang sản phẩm hữu ích — có thông số, lựa chọn thay thế, hỗ trợ hoặc thông tin tồn kho — thì 200 vẫn phù hợp vì trang có mục đích thực.

Bài viết đã xóa có nội dung thay thế: dùng chuyển hướng

HTTP/1.1 301 Moved Permanently
Location: https://example.com/current-guide

Một trang template trả 200 nhưng chỉ nói “bài viết đã bị xóa” khiến người dùng mắc kẹt và dễ bị phân loại soft 404. Nội dung thay thế phù hợp nên là đích của chuyển hướng 301 phía máy chủ.

Tìm kiếm nội bộ không có kết quả: hữu ích hay trống rỗng

Mã 200 có thể phản ánh đúng thực tế nếu trang giúp người dùng điều chỉnh truy vấn, duyệt danh mục hoặc tìm lựa chọn thay thế. Một trang mỏng chỉ có “0 kết quả” trông như lỗi dù mã báo thành công. Khác biệt nằm ở mức hữu ích của thân phản hồi, không phải con số 200.

Phân loại các phản hồi 200 đáng ngờ

Dán bản xuất dữ liệu crawl gồm URL, trạng thái, tiêu đề, canonical, khả năng lập chỉ mục và một mẫu ngắn từ thân trang. Prompt này tách thành công HTTP khỏi vấn đề nội dung và lập chỉ mục.

You are auditing URLs that return HTTP 200. Review the pasted rows without assuming that
"200" means "indexed" or "healthy."

For each URL:
1. Classify it as a substantive page, likely soft 404, redirect-needed page, genuinely gone
   page, duplicate/canonical case, or needs manual review.
2. Cite the exact evidence from the supplied title, body sample, canonical, and directives.
3. Recommend one response: keep 200, restore content, 301 to a relevant replacement,
   return 404/410, or fix canonical/noindex signals.
4. Flag any conclusion that cannot be made from the supplied data.

Do not invent page content, redirect targets, or indexing status. End with a prioritized
manual-check list.

PASTE CRAWL ROWS HERE

Kiểm tra phản hồi thay vì tin vào trang

Kiểm tra một phản hồi bằng curl

Chạy các lệnh sau trên macOS, Linux hoặc WSL. Lệnh đầu đọc header phản hồi; lệnh thứ hai tải cả thân phản hồi để bạn xác minh rằng 200 chứa nội dung thực.

curl -sI https://example.com/page
curl -sS -D - https://example.com/page -o page.html

Tìm dòng trạng thái 200, rồi mở page.html. Chỉ nhìn header sẽ không phát hiện được soft 404.

So sánh yêu cầu bình thường với user agent Googlebot

url="https://example.com/page"
curl -sS -o /dev/null -w "default: %{http_code} %{size_download} bytes\n" "$url"
curl -sS -A "Googlebot" -o /dev/null -w "Googlebot UA: %{http_code} %{size_download} bytes\n" "$url"

Sự khác biệt là lý do để kiểm tra quy tắc và nhật ký CDN/WAF, không phải bằng chứng Googlebot thật sự nhận phản hồi của yêu cầu giả lập. Hãy xác nhận lần tìm nạp thực trong URL Inspection.

Kiểm tra danh sách để tìm phản hồi khác 200

Đặt mỗi URL trên một dòng trong urls.txt:

while IFS= read -r url; do
  curl -sS -o /dev/null -w "%{http_code}\t%{url_effective}\n" "$url"
done < urls.txt

Đoạn mã này tìm các trường hợp mã trạng thái không khớp rõ ràng. Nó không thể đánh giá thân phản hồi 200 có nội dung thực chất hay không, vì vậy hãy kiểm tra tiếp các template đáng ngờ và báo cáo soft 404.

Công cụ xác minh phản hồi 200

Công cụ miễn phí của Patrick

• Công cụ kiểm tra mã trạng thái HTTP hàng loạt — dán tối đa 500 URL để thu thập mã trạng thái, đích cuối, chuỗi chuyển hướng và độ trễ trong một bản xuất. Dùng công cụ để tìm URL thực tế không trả về 200; sau đó kiểm tra riêng thân trang và Search Console để tìm lỗi mềm, vì công cụ kiểm tra trạng thái không thể đánh giá chất lượng nội dung hoặc tình trạng lập chỉ mục.

Bằng chứng từ công cụ tìm kiếm và máy chủ

• URL Inspection trong Google Search Console — so sánh kết quả đã lập chỉ mục với lần tìm nạp trực tiếp và xem nội dung được kết xuất mà Google có thể truy xuất.
• URL Inspection trong Bing Webmaster Tools — kiểm tra phản hồi mà Bingbot báo cáo đã nhận.
• Nhật ký máy chủ và CDN — xác nhận mã trạng thái mà các yêu cầu crawler thật sự nhận; nhật ký là bằng chứng mạnh hơn việc đổi chuỗi user agent trong curl.
• Bảng Network của Browser DevTools — xác minh yêu cầu tài liệu, header phản hồi và thân phản hồi cho phiên trình duyệt hiện tại.

Tự kiểm tra: 200 OK

Năm câu hỏi nhanh về ý nghĩa của mã 200 đối với SEO. Chọn đáp án cho từng câu rồi kiểm tra kết quả.

Nhật ký thay đổi