404 mềm là gì?

API Scraping toàn cầu không cần scrap lấy các trang công khai đã được hiển thị cho quy trình dữ liệu cần so sánh trạng thái HTTP với nội dung hiển thị và phát hiện các 404 mềm.

404 mềm là sự không phù hợp giữa nội dung và trạng thái

404 mềm xảy ra khi một URL phản hồi như một trang thành công nhưng nội dung được hiển thị nói rằng tài nguyên bị thiếu, trống hoặc không có sẵn. Trường hợp quen thuộc nhất là trang “không tìm thấy” được định dạng trả về với HTTP 200 OK. Máy chủ tuyên bố thành công trong khi trang giao tiếp thất bại.

Các công cụ tìm kiếm sử dụng tín hiệu nội dung để phát hiện sự không phù hợp này vì việc lập chỉ mục một mẫu lỗi như một trang thực sẽ làm ô nhiễm kết quả. Google Search Console báo cáo các URL bị ảnh hưởng là 404 mềm và thường loại trừ chúng khỏi tìm kiếm. Nhãn được sản xuất bởi cách giải thích của bộ thu thập thông tin, không phải bởi một mã trạng thái HTTP riêng biệt.

Phát hiện 404 mềm cũng quan trọng bên ngoài SEO. Các đường ống dữ liệu có thể tiếp nhận một shell điều hướng, trang thách thức, tuyến đường được hiển thị trống hoặc kết quả tìm kiếm trống như nội dung hợp lệ nếu chúng chỉ kiểm tra cho 200. Việc thu hồi đáng tin cậy xác thực trạng thái, URL cuối cùng, tiêu đề, tín hiệu thân bài và cấu trúc trang mong đợi cùng nhau.

Định nghĩa trực tiếp của một 404 mềm

Một 404 mềm là một URL có phản hồi chỉ ra thành công hoặc chuyển hướng đến một trang dường như thành công trong khi nội dung hiển thị cư xử như một lỗi tài nguyên bị thiếu. Google Search Central mô tả trường hợp cổ điển là một trang nói rằng nó không tồn tại trong khi trả về 200.

Từ mềm có nghĩa là lỗi được suy luận từ nội dung thay vì được khai báo trong phản hồi HTTP. Không có mã giao thức “404 mềm”. Một trang bị thiếu thực sự thường nên trả về 404 Không tìm thấy, trong khi nội dung bị xóa có chủ ý mà không có sự thay thế có thể trả về 410 đã biến mất. Một sự thay thế có liên quan có thể sử dụng chuyển hướng vĩnh viễn.

Các hệ thống tìm kiếm nhận diện nội dung giống như lỗi như thế nào

Một bộ thu thập thông tin lấy URL, theo các chuyển hướng, ghi nhận trạng thái cuối cùng, hiển thị các tài nguyên quan trọng và đánh giá nội dung hiển thị. Một phản hồi 200 với một thông điệp trang bị thiếu nổi bật, không có nội dung chính, hoặc một mẫu gần giống với các trang lỗi đã biết có thể được phân loại là 404 mềm.

Kết xuất phía khách hàng làm cho quá trình khó khăn hơn. HTML ban đầu có thể là một shell ứng dụng hợp lệ, trong khi JavaScript sau đó hiển thị trạng thái tài nguyên bị thiếu. Nếu các tập lệnh gặp lỗi cho bộ thu thập thông tin, trang được hiển thị cũng có thể trống hoặc gần trống. Việc chẩn đoán do đó phải so sánh phản hồi thô, đầu ra đã render và các lỗi tải tài nguyên.

Chuyển hướng có thể tạo ra cùng một kết quả. Gửi mọi URL không xác định đến trang chính trả về một trang thành công, nhưng trang đó không thỏa mãn ý định ban đầu. Các hệ thống tìm kiếm có thể coi điểm đến như một sự thay thế giống như lỗi thay vì một sự thay thế có nghĩa.

Mô hình tạo ra 404 mềm

404 mềm thường đến từ các mặc định CMS, quy tắc chuyển hướng rộng, lỗi kết xuất, các tuyến đường tạo mỏng, hoặc xử lý lỗi chỉ thay đổi phần nội dung.

Kiểm toán Phản hồi và Trang đã được Render cùng nhau

Một cuộc kiểm toán 404 mềm phải tái tạo những gì trình thu thập nhận được, không chỉ những gì trình duyệt đã đăng nhập hiển thị sau khi tải tài nguồn đã được lưu.

1. Bắt đầu với URL đã báo cáo. Sử dụng Kiểm tra URL hoặc một lần thu tương đương đã được render để chụp URL cuối, trạng thái, ảnh chụp màn hình và HTML đã render.
2. So sánh nội dung thô và đã render. Xác định xem máy chủ có gửi một thân lỗi trực tiếp hay JavaScript biến một shell thành công thành một tình trạng thiếu.
3. Kiểm tra các tài nguyên quan trọng. Các script bị thiếu, gọi API bị chặn và lỗi máy chủ có thể xóa nội dung chính trong khi điều hướng vẫn được render.
4. Kiểm tra sự tương đồng của mẫu. So sánh tiêu đề, tiêu đề phụ, cụm từ thân và bố cục với mẫu 404 đã biết và trang chủ của trang web.
5. Phân loại trạng thái tài nguyên nhắm đến. Quyết định xem nội dung đã biến mất, đã chuyển đến một thay thế liên quan, hoặc vẫn tồn tại nhưng không thể render được.
6. Kiểm tra các nhóm URL. Mẫu sản phẩm, tìm kiếm, thẻ, địa phương và các tuyến đường phân lớp để tìm một quy tắc CMS hoặc định tuyến chia sẻ thay vì cố gắng sửa từng URL một.
7. Xác thực sau khi phát hành. Xác nhận trạng thái trực tiếp, nội dung đã render, liên kết nội bộ, thành viên sơ đồ trang web, và trạng thái Search Console sau khi trình thu thập thấy sự thay đổi.

Định nghĩa lỗi mềm trong Hướng dẫn 404 mềm của Google Search, ngữ nghĩa 404 trong tham chiếu 404 của MDN, và tham chiếu trạng thái rộng hơn trong Ngữ nghĩa HTTP thiết lập lý do tại sao cả giao thức và nội dung cần được kiểm tra.

Chọn Sửa Chữa Phù Hợp Với Trạng Thái Tài Nguyên

Việc sửa chữa phụ thuộc vào việc nội dung đã biến mất, đã chuyển, hay vẫn được cho là tồn tại.

• Trả về 404 hoặc 410 khi không có thay thế nào tồn tại. Giữ trang lỗi tùy chỉnh hữu ích, nhưng gửi trạng thái trung thực.
• Sử dụng 301 cho một thay thế vĩnh viễn liên quan. Lập bản đồ các URL cũ một cách riêng lẻ thay vì gửi tất cả các lối đi thiếu đến trang chủ.
• Khôi phục nội dung có thực cho các trang hợp lệ. Sửa chữa các tài nguyên bị chặn, tải dữ liệu, mẫu và kết xuất máy chủ để nội dung chính có mặt.
• Kiểm soát các trang được tạo ra trống. Ngăn chặn sự kết hợp tìm kiếm và phân lớp không giới hạn trở thành danh mục URL có thể lập chỉ mục và được liên kết nội bộ.

Xây dựng Phòng Ngừa Soft-404 Vào Các Mẫu

Xử lý trạng thái đúng là thuộc về các thành phần chia sẻ định tuyến và kết xuất để mọi loại nội dung hoạt động nhất quán.

Làm cho việc xử lý bản ghi thiếu thiết lập trạng thái trước khi kết xuất mẫu lỗi tùy chỉnh. Trong các ứng dụng kết xuất từ máy chủ, điều này thuộc về phản hồi định tuyến hoặc khung. Trong các hệ thống kết xuất từ khách hàng, cung cấp phản hồi từ máy chủ hoặc edge có thể đại diện cho sự vắng mặt trước khi shell ứng dụng trả về thành công.

Tạo kiểm tra tự động cho các URL thiếu đại diện. Xác nhận trạng thái cuối cùng, tiêu đề, mục tiêu chính thức, sự hiện diện của nội dung chính và sự vắng mặt của metadata thành công có thể lập chỉ mục. Bao gồm địa phương, phân trang, sản phẩm, hồ sơ và các tuyến đường truy vấn vì lỗi mềm thường ẩn trong các mẫu thứ cấp.

Giữ cho sơ đồ trang web và liên kết nội bộ được sạch sẽ. Một sơ đồ trang web đầy các URL đã bị xóa sẽ mời gọi việc thu thập lại, trong khi các liên kết nội bộ đến các chuyển hướng tổng quát báo hiệu rằng biểu đồ chính thức của trang web đã cũ. Sửa chữa các tham chiếu nguồn, không chỉ phản hồi đích.

Soft 404 và Real 404 và Redirect

Kết quả chính xác phụ thuộc vào việc tài nguyên có tồn tại hay không và liệu một thay thế tương đương có sẵn hay không.

Phát hiện Soft 404 trong Dòng dữ liệu

Cái API Thu thập Dữ liệu Đa Năng Không Tàn có thể trả về nội dung trang công khai đã được hiển thị, cho phép một quy trình thu thập đánh giá những gì người dùng thực sự thấy. Cái nhìn đã được hiển thị này nên được kiểm tra cùng với trạng thái và URL cuối cùng, không được coi là bằng chứng của một trang mục tiêu thành công.

Sử dụng kỳ vọng cụ thể cho máy chủ như tiêu đề sản phẩm yêu cầu, nội dung bài viết, số lượng kết quả hoặc trường lược đồ ổn định. Thêm các tín hiệu chung cho các cụm từ trang thiếu, các chứa chính trống, các bài kiểm tra giữa, các lối đi đăng nhập, và các mẫu lỗi gần giống nhau. Lưu trữ bằng chứng phân loại để các trường hợp dương tính giả có thể được xem xét lại.

Giữ các trang lỗi mềm ra khỏi chỉ mục tìm kiếm, tập hợp dữ liệu truy vấn và tập dữ liệu phân tích. Một dòng dữ liệu sạch sẽ báo cáo sự vắng mặt một cách rõ ràng thay vì nhúng phần điều hướng và một thông điệp “không tìm thấy” như thể nó là nội dung nguồn.

Khớp Trạng thái với những gì Trang thực sự Nói

Một soft 404 không phải là một phản hồi giao thức đặc biệt. Nó là một chẩn đoán của bot thu thập rằng dữ liệu vận chuyển thành công mâu thuẫn với nội dung bị thiếu, trống, hoặc giống lỗi được hiển thị.

Trả về 404 hoặc 410 cho nội dung không có thay thế, sử dụng một chuyển hướng vĩnh viễn trực tiếp cho một động thái tương đương, và sửa chữa cách hiển thị khi trang nên tồn tại. Sau đó, xác minh cả trạng thái và nội dung chính có thể thấy trong toàn bộ gia đình URL bị ảnh hưởng.