Soft 404 là gì?

Trình duyệt Agent Scrapeless chạy các phiên duyệt web được quản lý có thể kiểm tra nội dung đã được render trên các trang web động.

Soft 404 là một trang hoạt động giống như một tài nguyên bị thiếu hoặc trống rỗng trong khi phản hồi HTTP của nó không truyền đạt đúng điều kiện đó, thường bằng cách trả về mã trạng thái thành công. Các hệ thống tìm kiếm cũng có thể phân loại một trang đã render là soft 404 khi nội dung chính của nó vắng mặt. Nhiệm vụ chẩn đoán là so sánh URL, phản hồi và ý nghĩa thực tế của trang.

Tại sao một Phản hồi Thành công Vẫn có Thể Đại diện cho một Trang Bị Thiếu

Soft 404 mô tả những gì trang truyền đạt cho người dùng và trình thu thập dữ liệu. Máy chủ có thể gửi phản hồi thành công trong khi nội dung cho biết bài viết được yêu cầu không khả dụng. Một ứng dụng phía khách có thể trả về cùng một khung cho mọi tuyến đường và sau đó hiển thị thông báo lỗi. Việc truyền tải đã hoàn tất, nhưng tài nguyên được yêu cầu đã không được cung cấp.

Chẩn đoán soft 404 của Google mô tả nội dung chính bị thiếu và trống như những tín hiệu liên quan đến phân loại này. Một báo cáo là bằng chứng về trang mà Google đã gặp, vì vậy hãy so sánh URL được báo cáo với phản hồi hiện tại và nội dung đã render của nó. Việc phân loại không phải là một mẫu văn bản phổ quát mà mọi trình thu thập dữ liệu đều áp dụng giống hệt nhau.

Đối với việc thu thập dữ liệu web, chỉ sử dụng “soft 404” như một hạng mục vận hành sau khi đã định nghĩa rõ ý nghĩa của nó. Một trình thu thập dữ liệu có thể phân loại một trang sản phẩm bị thiếu nhưng trả về mã trạng thái thành công là soft 404. Việc phân loại cục bộ đó tách biệt với quyết định lập chỉ mục của Google. Đặt tên hạng mục một cách rõ ràng giúp tránh việc một kiểm tra nội dung nội bộ bị trình bày như một phát hiện đã được xác nhận trong Search Console.

Một trao đổi mạng thành công trả lời câu hỏi liệu một biểu diễn đã đến hay chưa. Việc xác thực nội dung trả lời liệu đó có phải là biểu diễn mà bạn yêu cầu hay không. Kết hợp hai câu hỏi đó quá sớm khiến một bài viết bị thiếu trông giống như một bài viết thành công nhưng không có phần nội dung. Các hệ thống hạ nguồn sau đó sẽ mất đi sự phân biệt giữa việc nguồn vắng mặt và việc thu thập thất bại.

So sánh URL được yêu cầu với tài nguyên cuối cùng

URL cuối cùng là một phần của bằng chứng cho lỗi soft 404. Cú pháp URI và mô hình tham chiếu phân biệt các thành phần được sử dụng để nhận diện một tài nguyên. Một đường dẫn bị thiếu có thể trả về một mẫu lỗi tại URL ban đầu hoặc chuyển hướng đến một trang đích chung. Cả hai đều có thể gây nhầm lẫn cho một bộ thu thập chấp nhận bất kỳ phản hồi cuối cùng thành công nào mà không kiểm tra danh tính tài nguyên.

Kiểm tra toàn bộ lịch sử chuyển hướng trước khi quyết định trang cuối cùng có ý nghĩa gì. Việc chuyển tới tài nguyên thay thế thực sự của nó là hữu ích. Việc chuyển tới một trang chủ tổng quát cho bạn biết ít hơn nhiều về nội dung được yêu cầu. Ghi lại URL ban đầu và URL cuối cùng cùng với nhau, đặc biệt khi một pipeline sử dụng URL ban đầu làm định danh tài liệu của nó.

The Ngữ nghĩa mã trạng thái HTTP và chuyển hướng định nghĩa ý nghĩa phản hồi một cách độc lập với bộ phân tích (parser) của bạn. Trạng thái không tìm thấy có thể là hành vi đúng cho một trang đã bị xóa. Chuyển hướng vĩnh viễn có thể là hành vi đúng cho nội dung có một nội dung thay thế thực sự. Không trường hợp nào trong số đó nên được “sửa” bằng cách buộc mọi yêu cầu phải trả về một phản hồi thành công.

Đối với một trang web thuộc sở hữu, hãy chọn phản hồi dựa trên trạng thái tài nguyên. Nếu nội dung vẫn tồn tại, hãy cung cấp nội dung hữu ích và sửa đường dẫn tải của nó. Nếu nó đã được chuyển đi, hãy hướng người dùng đến nội dung thay thế tương ứng. Nếu nó đã biến mất mà không có nội dung thay thế tương đương, hãy thông báo về sự vắng mặt đó. Một trang lỗi thân thiện vẫn có thể sử dụng phản hồi không tìm thấy (not-found) thích hợp.

Khung ứng dụng trống và thiếu nội dung chính

Một trang đã được render có thể khác với phản hồi HTML ban đầu. Các ứng dụng hiện đại có thể tải nội dung chính của chúng từ một yêu cầu dữ liệu diễn ra sau đó. Nếu yêu cầu đó thất bại, trình duyệt có thể hiển thị phần điều hướng, thương hiệu và chân trang trong khi bài viết hoặc sản phẩm không bao giờ xuất hiện. Một phép kiểm tra độ dài phần thân có thể chấp nhận phần khung xung quanh và bỏ sót tài nguyên bị thiếu.

So sánh đánh dấu ban đầu với tài liệu đã được render. Xác định thành phần lẽ ra phải chứa nội dung được yêu cầu và phần phụ thuộc dữ liệu cung cấp nội dung đó. Kiểm tra lỗi tải script, phản hồi API thất bại và trạng thái lỗi của ứng dụng. Việc so sánh này đặc biệt hữu ích khi một URL hoạt động với trình duyệt đã đăng nhập nhưng một phiên sạch lại chỉ thấy một trang gần như trống.

Một kiểm tra nội dung tốt đòi hỏi danh tính cụ thể theo từng tài nguyên. Đối với một bài viết, hãy so sánh phần tiêu đề dự kiến và vùng văn bản chính của nó. Đối với một sản phẩm, hãy so sánh mã định danh sản phẩm và phần chi tiết sản phẩm. Việc kiểm tra nên tránh cách diễn đạt dễ vỡ khi có thể, nhưng cần đủ mức độ cụ thể để phân biệt đối tượng với một mẫu chung chung.

Không nên cho rằng mọi trang ngắn đều là soft 404. Một trang tiện ích nhỏ có thể đã đầy đủ, và một trang kết quả tìm kiếm trống có thể đúng khi thông báo rằng truy vấn không trả về kết quả nào. Ngược lại, một trang lỗi dài có thể chứa hàng trăm từ điều hướng và liên kết gợi ý. Vai trò của trang và nội dung được mong đợi quan trọng hơn một ngưỡng số lượng từ mang tính phổ quát.

Soft 404, Hard 404, Hợp lệ rỗng, và Lỗi truy cập

Một lỗi 404 mềm thuộc về một sơ đồ phân loại giữ nguyên các kết quả lân cận. Quyết định hữu ích là liệu tài nguyên bị thiếu, không thể truy cập, không đầy đủ, hay có mặt nhưng với kết quả rỗng.

Một kết quả tìm kiếm trống hợp lệ có giao diện tìm kiếm như mong đợi, ngữ cảnh truy vấn được yêu cầu và trạng thái không có kết quả rõ ràng. Một trang sản phẩm bị thiếu thì không có bản biểu diễn sản phẩm tương ứng. Một thử thách truy cập có nghĩa là bộ thu thập không tiếp cận được tài nguyên, nên không được coi là bằng chứng cho thấy sản phẩm đã bị gỡ bỏ.

Nếu nguồn trả về phản hồi bảo trì hoặc lỗi dịch vụ, hãy giữ nguyên hạng mục phản hồi đó. Gắn nhãn lại mọi trang không khả dụng thành “không tìm thấy” có thể khiến hệ thống giám sát xóa bản ghi quá sớm. Khi bằng chứng vẫn mơ hồ, hãy giữ trạng thái cần xem xét với phản hồi thô và điều kiện thu thập.

Xây dựng Quy tắc Chấp nhận Nội dung cho Bộ Thu thập

Các quy tắc chấp nhận nội dung cần xác minh cả việc truyền tải hoàn tất và danh tính nguồn. Bắt đầu với phản hồi cuối cùng và URL, sau đó xác nhận vùng nội dung mong đợi tồn tại. Kiểm tra xem trang có chứa trạng thái lỗi rõ ràng liên quan đến tài nguyên hay không. Sử dụng các tín hiệu này cùng nhau thay vì để một cụm từ quyết định hoàn toàn.

Thiết kế quy tắc dựa trên một vài trang đại diện: một mục tiêu hoạt động, một đường dẫn cố ý bị thiếu, và một trường hợp trống hợp lệ nếu trang web hỗ trợ. Đây là các trường hợp so sánh, không phải dữ liệu huấn luyện để cho rằng mọi lỗi trong tương lai đều giống hệt nhau. Mẫu trang và bản địa hóa có thể thay đổi, vì vậy hãy ghi lại các đặc trưng mà quy tắc của bạn phụ thuộc vào.

Khi văn bản thay đổi theo ngôn ngữ, hãy sử dụng danh tính tài nguyên ổn định và bằng chứng cấu trúc khi khả thi. Cụm từ “not found” tiếng Anh là bộ phân loại kém nếu dùng một mình cho một trang web đa ngôn ngữ. Cùng một cụm từ cũng có thể xuất hiện trong một bài viết thảo luận về lỗi. Hãy xác nhận vị trí xuất hiện của văn bản và liệu tài nguyên dự định có hiện diện hay không.

Môi trường Scrapeless Agent Browser rendering environment hữu ích khi HTML ban đầu không đủ để kiểm tra một trang động. Phiên trình duyệt cung cấp bằng chứng đã render; quy trình của bạn vẫn phải quyết định liệu bằng chứng đó có đại diện cho tài nguyên được yêu cầu hay không. Kết xuất được quản lý không thể khôi phục nội dung mà nhà xuất bản đã gỡ bỏ.

Chẩn đoán Một Trang Sở Hữu Mà Không Thay Đổi Ý Nghĩa Của Nó

Sửa một nghi ngờ soft 404 bắt đầu từ tài nguyên dự định. Xác nhận bản ghi CMS có tồn tại và tuyến công khai có nên hiển thị nó hay không. Một bản ghi nháp ở backend không phải là bằng chứng cho thấy một bài viết công khai tồn tại. Kiểm tra trạng thái xuất bản và ánh xạ tuyến trước khi điều tra bộ hiển thị.

Đối với một tài nguyên lẽ ra phải công khai, hãy kiểm tra cùng lúc phản hồi dữ liệu và thành phần trang. Bản ghi cơ sở dữ liệu bị thiếu, khóa tuyến sai hoặc việc lấy nội dung thất bại đều có thể để lại một vỏ trang không có nội dung dự định. Cung cấp cho ứng dụng một phản hồi trạng thái thiếu đúng chuẩn khi khả thi và làm cho nội dung hiện có truy cập được thông qua đường hiển thị bình thường.

Đối với chẩn đoán Search Console, hãy kiểm tra trang được chụp và trang hiện tại đã render bằng các công cụ kiểm tra sẵn có. Một lượt truy cập thành công hiện tại không cho thấy trình thu thập trước đó đã gặp gì. Ghi lại thời điểm quan sát và ngữ cảnh triển khai trong cuộc điều tra nội bộ, sau đó đánh giá trang công khai đã được sửa khi báo cáo được cập nhật.

Đối với việc thu thập của bên thứ ba, hãy giữ lại URL nguồn gốc và lý do một lần chụp bị từ chối. Quy trình proxy connectivity testing workflow cung cấp ngữ cảnh để tách việc kiểm tra phân phối mạng khỏi việc chấp nhận nội dung. Scrapeless Agent Browser có thể cung cấp lớp kết xuất; current Scrapeless plans giúp bạn lập ngân sách cho nó mà không giả định rằng mọi URL đều cần trình duyệt.

Xem Ý Nghĩa Tài Nguyên Là Một Phần Của Thành Công

Một soft 404 được giải quyết khi phản hồi và trạng thái tài nguyên hiển thị đồng nhất. Nội dung hiện có phải tải như tài nguyên đúng; nội dung đã chuyển phải dẫn đến bản thay thế thực sự; nội dung đã gỡ bỏ phải thông báo là vắng mặt. Tăng độ dài trang hoặc ẩn văn bản lỗi không chứng minh rằng tài nguyên tồn tại.

Đối với một bộ thu thập, kết quả bền vững là một phân loại phân biệt nội dung được chấp nhận, kết quả trống hợp lệ, tài nguyên bị thiếu và lần chụp chưa giải quyết. Giữ lại bằng chứng cho mỗi quyết định để các thay đổi từ nguồn không âm thầm trở thành mất dữ liệu.