204 Không có nội dung

Tóm tắt — Phản hồi 204 No Content có nghĩa là “yêu cầu đã thành công và tôi cố ý trả về một trang rỗng”. Đây là mã thành công, không phải lỗi. Cách này hoàn toàn phù hợp khi ứng dụng lưu dữ liệu ở nền hoặc trình theo dõi phân tích gửi beacon, nhưng sai đối với trang web thật mà bạn muốn xuất hiện trên Google. Thân rỗng không cung cấp gì để Google lập chỉ mục, nên phản hồi 204 trên một trang bị xử lý tương tự soft 404.

Phản hồi 204 thực chất là gì

Mọi phản hồi từ máy chủ đều kèm mã trạng thái. Các mã 2xx biểu thị “thành công”. 200 OK — mã phù hợp cho trang — có nghĩa “đây là trang”, gồm cả thân phản hồi. 204 No Content cũng biểu thị thành công nhưng có một khác biệt: máy chủ nói “tôi đã làm điều bạn yêu cầu và cố ý không có gì để hiển thị”. Evidence for this claim RFC 9110 defines 204 No Content as a successful response with no additional content to send and says it is terminated by the header section because it cannot contain content. Scope: HTTP semantics for 204 responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.3.5 — 204 No Content

Từ khóa là cố ý. Phản hồi 204 không phải trang tải thất bại hay URL không tồn tại; đây là phản hồi được thiết kế để trống. Có thể hình dung máy chủ gật đầu “xong” mà không đưa lại nội dung nào.

Vì sao điều đó gây vấn đề cho trang web

Google lập chỉ mục nội dung của trang. Nếu URL trả về 204, sẽ không có nội dung để đọc vì thân phản hồi rỗng theo thiết kế. Tài liệu của Google nói rõ rằng hệ thống “wasn’t able to receive any content and therefore can’t process it.” (bản dịch) «không thể nhận nội dung nên không thể xử lý». Vì vậy, trang cần xếp hạng nhưng trả 204 không cung cấp gì cho Google và sẽ không được lập chỉ mục; trong thực tế, Search Console thường gắn nhãn tương tự soft 404 — một trang thành công về kỹ thuật nhưng không có nội dung đáng lập chỉ mục. Evidence for this claim Google says it treats a 204 response as though the URL returned a soft 404. Scope: Google Search indexing behavior for URLs returning HTTP 204. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search

Vì vậy, khi trang bạn muốn xếp hạng xuất hiện với mã 204 trong dữ liệu crawl hoặc Search Console, đó là lỗi cần sửa chứ không phải tình trạng nên bỏ qua.

Khi nào mã 204 hoàn toàn phù hợp

Hầu hết phản hồi 204 bạn gặp không phải là trang:

• Ứng dụng lưu dữ liệu ở nền. Bạn nhấn “lưu”, ứng dụng ghi dữ liệu mà không tải lại trang; máy chủ có thể trả về 204.
• Phân tích và theo dõi. Trình theo dõi gửi các yêu cầu beacon nhỏ để ghi nhận sự kiện. Không có trang cần trả về nên 204 là lựa chọn đúng.
• Giao diện ứng dụng (API). Khi một hệ thống yêu cầu hệ thống khác xóa dữ liệu, thường không có gì cần gửi lại; mã 204 có nghĩa “đã xong”.

Không trường hợp nào ở trên cần xuất hiện trên Google, nên mã 204 là câu trả lời đúng, không phải sai sót.

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

Không bao giờ trả về 204 cho URL mà bạn muốn người dùng tìm thấy trong kết quả tìm kiếm. Nếu trang đã biến mất vĩnh viễn, dùng 404 hoặc 410. Nếu trang đã chuyển, dùng chuyển hướng 301. Nếu trang đáng lẽ có nội dung, hãy sửa lớp đang phục vụ phản hồi rỗng. Muốn xem cách diễn đạt chính xác của Google, các trường hợp API và beacon, cùng cách chẩn đoán mã 204 ngoài ý muốn? Hãy chuyển sang thẻ Nâng cao.

Tóm tắt — 204 là mã thành công 2xx tuân thủ RFC 9110 §15.3.5 và có thân rỗng theo thiết kế. Thân phản hồi phải rỗng, không được có Content-Length kể cả 0, và trình duyệt có thể từ chối phản hồi mang nội dung. Đây không phải lỗi, không nói tài nguyên có tồn tại hay không và RFC không giới hạn mã này vào danh sách phương thức cố định. Tình huống hợp lệ gần như đều không phải document: DELETE/PUT trong REST API và beacon phân tích (sendBeacon(), Measurement Protocol của GA4), dù giới thực hành bất đồng về tần suất API nên dùng nó. Hệ quả SEO rất hẹp: bảng mã trạng thái của Google nói “Google wasn’t able to receive any content and therefore can’t process it” (bản dịch) «Google không thể nhận nội dung nên không thể xử lý». Trang cần xếp hạng sẽ không được lập chỉ mục từ phản hồi này; trong thực tế chúng thường bị gắn soft 404 trong Search Console, nhưng Google không bảo đảm nhãn cụ thể hay thời gian loại bỏ. Sửa mã 204 cấp trang ngoài ý muốn bằng cách khôi phục 200 có thân thực hoặc dùng 404/410/301 tùy mục đích.

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

RFC 9110 (HTTP Semantics) nêu rõ rằng 204 cho biết “the server has successfully fulfilled the request and that there is no additional content to send in the response payload body.” (bản dịch) «máy chủ đã hoàn thành yêu cầu thành công và không có nội dung bổ sung để gửi trong thân payload phản hồi». Đây là mã thành công, cùng nhóm 2xx với 200 OK, nhưng cố ý không có thân phản hồi. Evidence for this claim RFC 9110 defines 204 No Content as a successful response with no additional content to send and says it is terminated by the header section because it cannot contain content. Scope: HTTP semantics for 204 responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.3.5 — 204 No Content

Có ba chi tiết vận hành quan trọng. Thứ nhất, thân phản hồi thực sự phải rỗng: MDN nói phản hồi này “must not include any content or the Content-Length header (browsers may reject responses that include content).” (bản dịch) «không được chứa nội dung hoặc header Content-Length; trình duyệt có thể từ chối phản hồi chứa nội dung». Đây là quy định thật, không phải thông lệ lỏng lẻo — RFC 9110 §8.6 cấm hoàn toàn Content-Length trên 204, nên “chỉ gửi Content-Length: 0” cũng không tuân thủ; phản hồi kết thúc sau phần header. Thứ hai, các header như ETag hay Last-Modified mô tả biểu diễn được chọn sau khi hành động hoàn tất, không phải thân đã gửi. Thứ ba, ETag xuất hiện trên một số phản hồi 204 (ví dụ MDN dùng PUT cập nhật tại chỗ), nhưng RFC không bắt buộc mọi phản hồi loại này phải có. Theo mặc định, 204 có thể lưu đệm theo suy đoán trừ khi phương thức hoặc header cache-control nói khác.

Điểm cốt yếu là 204 không liên quan đến việc URL có tồn tại hay không. Endpoint API hoạt động bình thường có thể trả 204 vĩnh viễn. Điều đó khác với 404 (không tìm thấy) hoặc 410 (đã mất): hai mã kia nói về sự vắng mặt, còn 204 nói về yêu cầu thành công nhưng cố ý không mang payload.

Cách Google xử lý phản hồi 204

Toàn bộ câu chuyện SEO hẹp hơn những câu khái quát trên blog nhà cung cấp. Google lập chỉ mục nội dung; phản hồi 204 không có nội dung. Tài liệu mã trạng thái của Google nêu riêng một giới hạn cụ thể: quy tắc chung cho 2xx là “Google considers the content for processing,” (bản dịch) «Google xem xét nội dung để xử lý»; còn hàng dành cho 204 nói “Google wasn’t able to receive any content and therefore can’t process it.” (bản dịch) «Google không thể nhận nội dung nên không thể xử lý». Evidence for this claim Google says it treats a 204 response as though the URL returned a soft 404. Scope: Google Search indexing behavior for URLs returning HTTP 204. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search

Đó là ranh giới thật và cần nói chính xác điều nó bảo đảm hoặc không bảo đảm. Hướng dẫn chung về 2xx trên cùng trang nói nội dung trống hoặc giống lỗi có thể bị báo soft 404; nhưng riêng hàng 204 không bảo đảm mọi phản hồi đều nhận nhãn Search Console đó, và Google không công bố thời hạn loại bỏ. Điều chắc chắn là mã 204 trên URL nội dung không cung cấp gì cho quy trình lập chỉ mục, nên có thể suy luận hợp lý rằng URL không được lập chỉ mục từ phản hồi này. Không nên mở rộng thành tuyên bố “chắc chắn mất thứ hạng toàn site” hay “tự động thu hồi crawl budget”, vì Google không hứa như vậy. Trong thực tế, Search Console thường hiển thị các URL này dưới dạng soft 404; hãy coi nhãn và thời điểm cụ thể là hành vi quan sát được, không phải bảo đảm trong tài liệu.

Đây cũng là quan điểm tôi duy trì trong bài Mã trạng thái HTTP và tác động SEO trên blog Ahrefs. Trong phần Google xử lý phản hồi 2xx, tôi viết: “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ư lỗi mềm và không được lập chỉ mục». Tôi vẫn xem đây là cách hiểu thực tế; để xác định ranh giới chính thức chính xác, nên dùng cách diễn đạt hiện tại của Google rằng hệ thống không thể nhận hoặc xử lý nội dung.

Tài liệu nói soft 404 tiếp tục được crawl và gây lãng phí crawl budget, nhưng đó là hướng dẫn chung, không phải lời hứa riêng cho 204. Dùng 204 không tự động giải phóng hay chuyển tài nguyên crawl; Google lưu ý phân bổ tài nguyên còn phụ thuộc giới hạn phục vụ, chất lượng site và lượng nội dung, không chỉ mã trạng thái gây loại trừ. Kết luận an toàn là sửa phản hồi 204 ngoài ý muốn vì nó ngăn trang được lập chỉ mục, không phải vì bạn được bảo đảm nhận một khoản lợi crawl budget cụ thể. Evidence for this claim Using 204 does not automatically free crawl budget or redirect crawl resources; the official Google 204 guidance establishes only that no content can be processed. Scope: web crawling and indexing Confidence: high · Verified: 2026-07-16 How HTTP status codes affect Google's crawlers

So sánh 204 với các mã thường bị nhầm

Cạm bẫy là 204, phản hồi 200 rỗng, 404 và 410 đều có thể xuất hiện dưới nhãn “soft 404” trong GSC khi không có nội dung hữu ích, nhưng chúng thể hiện mục đích rất khác nhau với client tuân thủ đặc tả. 410 là tín hiệu có chủ đích rằng tài nguyên từng tồn tại và đã biến mất vĩnh viễn; 204 không được thiết kế cho ý nghĩa đó và không nên nằm trên URL trang.

Khi nào 204 hoàn toàn đúng, không phải lỗi

Hầu hết trường hợp 204 hợp lệ đều là phản hồi không phải document:

• REST API DELETE / PUT. Khi client xóa tài nguyên hoặc cập nhật tại chỗ và không có gì hữu ích cần trả về, 204 là cách trả lời điển hình — cũng là mẫu RFC 9110 khuyến nghị.
• Beacon phân tích và theo dõi. Đặc tả W3C Beacon quanh navigator.sendBeacon() kỳ vọng endpoint beacon trả 204. Endpoint Measurement Protocol của Google Analytics 4 trả 204 cho hit được chấp nhận. Cần lưu ý GA4 cũng trả 204 cho payload sai hoặc không hợp lệ; mã này chỉ xác nhận endpoint có thể truy cập và đã phản hồi đúng cấu trúc, không chứng minh hit được xử lý.
• Trải nghiệm “lưu mà không chuyển trang”. Yêu cầu PUT lưu trạng thái tại chỗ và giữ người dùng trên trang hiện tại; cách diễn đạt của MDN là với 204, “the client doesn’t need to navigate away from its current page.” (bản dịch) «client không cần rời trang hiện tại».

Điểm chung là không URL nào trong các trường hợp trên cần được lập chỉ mục, nên 204 là kết quả đúng và được kỳ vọng. Vấn đề chỉ xuất hiện khi 204 nằm trên URL document đáng lẽ phải xếp hạng.

Một sắc thái liên quan: RFC 9110 không giới hạn 204 vào DELETE/PUT/beacon; đó chỉ là các mẫu phổ biến. Định nghĩa của đặc tả trung lập với phương thức; điều quan trọng là hợp đồng của phương thức và việc trả một biểu diễn có hữu ích hay không. Yêu cầu GET trả 204 vẫn hợp lệ ở tầng giao thức. Với trang cần lập chỉ mục, câu hỏi thật không phải “204 trên GET có được phép không” mà là “URL này có cần đưa một biểu diễn cho Google để được tìm thấy không”; câu trả lời luôn là có. Quy tắc SEO phụ thuộc URL có phải document hay không, không phụ thuộc phương thức HTTP.

Ngay cả giới thiết kế API cũng không nhất trí rằng “204 luôn đúng cho phản hồi API”. Bài của Postman xem 204 là lựa chọn mặc định khi hành động không có gì để trả; Brandur Leach lập luận ngược lại rằng phản hồi thành công rỗng có thể gây bất tiện cho client đang chờ biểu diễn mới như trạng thái cập nhật, ID được tạo hoặc trường được tính. Đây là đánh đổi về trải nghiệm lập trình, không phải tính đúng của HTTP — 204 vẫn tuân thủ đặc tả theo cả hai cách — và tách biệt với câu hỏi SEO. Một lỗi hay gặp trong bài viết API là gửi Content-Length: 0 trên 204 “cho an toàn”. Đừng làm vậy: RFC 9110 §8.6 cấm hoàn toàn Content-Length trong phản hồi 204, kể cả khi giá trị bằng 0.

Chẩn đoán và sửa mã 204 cấp trang ngoài ý muốn

Nếu crawler như Screaming Frog hoặc Ahrefs Site Audit, hay nhật ký của bạn, cho thấy mã 204 trên trang đáng lẽ có nội dung:

1. Xác minh điều Googlebot thực sự nhận. Dùng URL Inspection trong Search Console để xem trạng thái và nội dung được kết xuất mà Google nhận, không chỉ phản hồi trình duyệt. CDN, edge worker, WAF hoặc tuyến ứng dụng có thể trả 204 cho bot hay trong điều kiện cụ thể dù phía bạn trông bình thường — tương tự mẫu “trình duyệt của tôi vẫn ổn” khi xuất hiện 403 ngoài ý muốn.
2. Sau đó sửa theo mục đích:
   • Trang phải tồn tại và có nội dung → tìm logic máy chủ/CDN/ứng dụng phát ra 204 và khôi phục 200 cùng thân phản hồi thật.
   • Trang đã mất và không có nội dung thay thế → trả về 404 hoặc 410.
   • Trang đã chuyển → dùng 301 đến URL mới.
3. Giám sát. Theo dõi mục soft 404 trong báo cáo Lập chỉ mục trang của GSC, xem mã crawl trong nhật ký và cấu hình crawler cảnh báo 204 để một lỗi template không âm thầm loại cả khu vực khỏi chỉ mục.

Mô hình cần nhớ là 204 không “xấu”. Đây là công cụ chính xác, phù hợp với endpoint API và beacon nhưng sai với document. Lỗi chỉ xuất hiện khi dùng không đúng chỗ. Các mã liên quan như 403, 404, 410 và soft 404 đều có vị trí riêng; vị trí của 204 nằm ngoài trang nội dung.

Tóm tắt bằng AI

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

• 204 No Content là mã thành công 2xx (RFC 9110 §15.3.5) trả về thân rỗng theo thiết kế. Đây không phải lỗi và không nói URL có tồn tại hay không. RFC không giới hạn mã này vào danh sách phương thức cố định; DELETE/PUT và beacon là mẫu phổ biến chứ không phải yêu cầu, còn 204 trên GET vẫn hợp lệ về giao thức.
• Thân phản hồi phải rỗng, không có ngoại lệ. Theo MDN, phản hồi không được chứa nội dung hoặc header Content-Length; RFC 9110 §8.6 cấm hoàn toàn header này nên cả Content-Length: 0 cũng không tuân thủ. Header đi kèm mô tả biểu diễn được chọn sau hành động, không phải thân đã truyền. Theo mặc định, 204 có thể lưu đệm theo suy đoán, nhưng không phải phản hồi nào cũng được bảo đảm có ETag.
• Hệ quả SEO có giới hạn chính xác: tài liệu của Google nói “Google wasn’t able to receive any content and therefore can’t process it.” (bản dịch) «Google không thể nhận nội dung nên không thể xử lý». Có thể suy luận hợp lý rằng trang cần xếp hạng sẽ không được lập chỉ mục từ phản hồi này, nhưng Google không bảo đảm mọi URL nhận nhãn soft 404 cụ thể hay thời hạn loại bỏ; dùng 204 cũng không tự động thu hồi crawl budget hoặc chứng minh tác động thứ hạng. Theo cách Patrick mô tả trong bài của mình, phản hồi không có nội dung bị xử lý như lỗi mềm và không được lập chỉ mục; đó là mẫu thực tế, còn cách diễn đạt chính thức hẹp hơn.
• Tình huống hợp lệ chủ yếu không phải document: DELETE/PUT của REST API và beacon phân tích (sendBeacon(), GA4 Measurement Protocol). GA4 trả 204 ngay cả với hit sai, nên phản hồi beacon không chứng minh hit được xử lý. Giới thực hành cũng bất đồng: Postman ưu tiên 204 cho hành động không có gì để trả, còn Brandur Leach cho rằng thành công rỗng có thể gây bất tiện cho client cần biểu diễn; đây là tranh luận về trải nghiệm API, không phải tính đúng của HTTP.
• 204 không bao giờ phù hợp với trang cần xếp hạng. Đã mất và không có thay thế → 404/410; đã chuyển → 301; đáng lẽ có nội dung → sửa máy chủ/CDN phát 204 và khôi phục 200 thật. Xác minh phản hồi Googlebot bằng URL Inspection.

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

Các nguồn sơ cấp giải thích mã 204 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.5 — 204 No Content — định nghĩa có thẩm quyền: thành công, không có thân payload hay trailer, có thể lưu đệm theo suy đoán và các header mô tả biểu diễn được chọn sau hành động.
• RFC 9110 §8.6 — Content-Length — quy tắc cấm hoàn toàn Content-Length trong phản hồi 204, không chỉ khi giá trị khác 0.
• MDN — 204 No Content — cách giải thích dễ hiểu, ràng buộc thân rỗng / Content-Length, khả năng lưu đệm, ví dụ ETag cụ thể và trường hợp “lưu mà không rời trang”.

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 — bảng mã trạng thái gọi tên riêng 204 và định nghĩa soft 404 của Google.

Beacon và phân tích — các trường hợp 204 hợp lệ

• W3C — Beacon — đặc tả navigator.sendBeacon() kỳ vọng endpoint beacon trả 204.
• Google Analytics 4 — Tài liệu Measurement Protocol — endpoint thu thập của GA4, trong đó có phản hồi 204 cho hit được chấp nhận.

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 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional content to send in the response payload body.” (bản dịch) «Mã trạng thái này cho biết máy chủ đã hoàn thành yêu cầu thành công và không có nội dung bổ sung để gửi trong thân payload phản hồi.» — RFC 9110, HTTP Semantics, §15.3.5. Đọc mục này

MDN Web Docs

• “The HTTP 204 No Content successful response status code indicates that a request has succeeded, but the client doesn’t need to navigate away from its current page. A 204 response is cacheable by default, and an ETag header is included in such cases.” (bản dịch) «Mã phản hồi thành công này cho biết yêu cầu đã thành công nhưng client không cần rời trang hiện tại. Theo mặc định phản hồi có thể được lưu đệm và trong những trường hợp đó có header ETag.» Đi đến trích dẫn

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

• “Google wasn’t able to receive any content and therefore can’t process it.” (bản dịch) «Google không thể nhận nội dung nên không thể xử lý.» — tài liệu về mã trạng thái HTTP của Google, hàng 204 trong bảng 2xx (đối chiếu quy tắc chung rằng Google xem xét nội dung để xử lý). Tài liệu mã trạng thái của Google

Patrick Stox — Ahrefs

• “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. Tuy nhiên, phản hồi không có nội dung sẽ bị xử lý như lỗi mềm và không được lập chỉ mục.» — từ hướng dẫn Mã trạng thái HTTP và tác động SEO của tôi. Đi đến trích dẫn

Matt G. Southern — Search Engine Journal

• “The exception is a 204 status code, which means the page was successfully accessed but no content was found. Google may show a soft 404 in Search Console for pages serving a 204 code.” (bản dịch) «Ngoại lệ là mã trạng thái không có nội dung: trang đã được truy cập thành công nhưng không tìm thấy nội dung. Google có thể hiển thị soft 404 trong Search Console cho các trang phục vụ mã này.» Đi đến trích dẫn

Phản hồi 204 hợp lệ và phản hồi ngoài ý muốn

Các trường hợp cụ thể cho thấy 204 phù hợp ở đâu và trở thành lỗi ở đâu.

Đúng: REST API DELETE

Client xóa một tài nguyên; không có gì cần trả về.

DELETE /api/items/42 HTTP/1.1
Host: example.com

HTTP/1.1 204 No Content

Không có thân phản hồi và không có Content-Length. Đây là cách trả lời điển hình, và endpoint này không bao giờ nên là URL bạn mong xuất hiện trong kết quả tìm kiếm.

Đúng: beacon phân tích (sendBeacon)

// Fires a fire-and-forget beacon on page unload
navigator.sendBeacon('/collect', payload);
// Endpoint responds:  HTTP/1.1 204 No Content

Endpoint không có trang cần phục vụ nên 204 hoàn toàn chính xác. Điều tương tự áp dụng cho endpoint Measurement Protocol của GA4; chỉ cần nhớ GA4 trả 204 ngay cả với hit sai, vì vậy mã này xác nhận endpoint đã phản hồi chứ không xác nhận hit được xử lý.

Sai: trang nội dung trả về 204

GET /blog/my-article/ HTTP/1.1
Host: example.com

HTTP/1.1 204 No Content        ← bug: a real page must return 200 + body

Google nhận thân rỗng, xử lý URL tương tự soft 404 và không lập chỉ mục. Cách sửa phụ thuộc mục đích:

• Đáng lẽ tồn tại với nội dung → khôi phục 200 OK cùng thân phản hồi thực; sửa tuyến máy chủ/CDN/ứng dụng đang phát 204.
• Đã mất và không có thay thế → 404 hoặc 410.
• Đã chuyển → 301 đến URL mới.

Quy tắc kinh nghiệm: nếu người dùng cần truy cập URL và đọc nội dung, URL phải trả về 200 cùng thân phản hồi. Chỉ dùng 204 cho endpoint máy-với-máy như API và beacon, nơi thực sự không có gì cần hiển thị.

Chẩn đoán phản hồi 204 ngoài ý muốn

Trang trống và bảng Network hiển thị 204

Triệu chứng: URL document đáng lẽ kết xuất nội dung lại trả về 204 No Content.

Nguyên nhân có thể: Định tuyến ứng dụng, quy tắc CDN, edge worker hoặc trình xử lý lỗi đang phát phản hồi thành công kiểu API trên tuyến trang.

Cách sửa: Theo dõi yêu cầu qua lớp sở hữu phản hồi. Nếu trang phải tồn tại, khôi phục 200 cùng thân thực. Xác nhận bằng yêu cầu header mới và tải lại trình duyệt khi đã tắt bộ nhớ đệm.

Search Console báo soft 404 cho URL 204

Triệu chứng: URL bị loại dưới nhãn soft 404 dù 204 là mã thành công.

Nguyên nhân có thể: Việc phân loại dựa trên nội dung bị thiếu, không dựa vào việc mã bắt đầu bằng 2. Theo định nghĩa, phản hồi 204 không có thân.

Cách sửa: Chọn phản hồi theo mục đích: 200 có nội dung cho trang thật, 301 cho trang đã chuyển, hoặc 404/410 cho trang đã mất. Chạy lại URL Inspection sau khi triển khai.

Trình duyệt và crawler thấy trạng thái khác nhau

Triệu chứng: Trang trông bình thường trong trình duyệt nhưng crawler hoặc nhật ký ghi nhận 204.

Nguyên nhân có thể: Logic theo bot, phương thức, vị trí địa lý, cache, WAF hoặc edge đang thay đổi phản hồi.

Cách sửa: So sánh GET với HEAD, yêu cầu bình thường với user agent Googlebot và yêu cầu chính xác trong nhật ký máy chủ/CDN. Sửa quy tắc có điều kiện rồi xác minh cả hai đường dẫn trả cùng phản hồi dự kiến.

Phân loại một tập URL 204 theo mục đích

Dán bản xuất dữ liệu crawl hoặc nhật ký gồm URL, phương thức yêu cầu, loại nội dung, referrer hoặc loại tuyến và mã phản hồi.

Classify each HTTP 204 row I provide as:
- likely legitimate API response,
- likely legitimate beacon/background request,
- accidental document/page response, or
- insufficient evidence.

For every row, cite the supplied evidence, explain why 204 does or does not fit, and give
the next verification step. For accidental page responses, recommend exactly one intended
outcome: 200 with content, 301 to a relevant replacement, or 404/410 if gone.

Do not infer that a 204 analytics response means the event was processed. Do not invent
route behavior, redirect targets, or page content. Return a table followed by a prioritized
manual-check queue.

PASTE ROWS HERE

Tìm phản hồi 204 ngoài ý muốn

Kiểm tra một URL và phương thức yêu cầu

curl -sS -D - -o /dev/null https://example.com/page
curl -sS -X HEAD -D - -o /dev/null https://example.com/page

Yêu cầu document không nên trả 204 nếu URL cần kết xuất nội dung. Hãy thử cả GET và HEAD vì trình xử lý sai theo phương thức có thể trả kết quả khác nhau.

So sánh phản hồi mặc định 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"

Nếu chỉ một đường dẫn trả 204 với 0 byte tải xuống, nguyên nhân có thể nằm ở logic có điều kiện của máy chủ, CDN hoặc WAF. Dùng nhật ký thật và URL Inspection để xác nhận điều Google thực sự nhận.

Báo cáo phản hồi 204 từ danh sách URL

while IFS= read -r url; do
  code=$(curl -sS -o /dev/null -w "%{http_code}" "$url")
  if [ "$code" = "204" ]; then printf '%s\t%s\n' "$code" "$url"; fi
done < urls.txt

Chạy đoạn mã này trên macOS, Linux hoặc WSL với mỗi URL trên một dòng trong urls.txt. Đánh giá từng kết quả theo mục đích của tuyến; phản hồi 204 từ API và beacon không phải lỗi.

Công cụ phân biệt phản hồi 204 hợp lệ và ngoài ý muốn

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 — kiểm tra tối đa 500 URL, lọc kết quả theo 204 và xuất tập bị ảnh hưởng. Dùng bối cảnh tuyến và nội dung để tách endpoint API/beacon hợp lệ khỏi URL trang đáng lẽ phải trả nội dung.

Xác nhận nguyên nhân

• URL Inspection trong Google Search Console — chạy Live Test cho URL trang để xem Google có thể tìm nạp gì sau khi đổi phản hồi.
• Nhật ký máy chủ/CDN — xác định 204 có thay đổi theo phương thức, user agent, tuyến hoặc vị trí edge hay không.
• Bảng Network của Browser DevTools — phân biệt yêu cầu document với lệnh gọi API và beacon ở nền; 204 trên beacon có thể đúng nhưng 204 trên document thì không.
• Crawler toàn site — lập danh sách URL document trả 204 và giữ phép kiểm tra trong các đợt audit định kỳ để lỗi template không ảnh hưởng cả khu vực.

Tự kiểm tra: 204 No Content

Năm câu hỏi nhanh về ý nghĩa của mã 204 và khi nào nên dùng. Chọn đáp án cho từng câu rồi kiểm tra kết quả.

Nhật ký thay đổi