HTTP 208 Already Reported
HTTP 208 Already Reported is defined by RFC 5842, an extension to WebDAV for bindings. It is used inside a 207 Multi-Status response to tell the client that a resource's members were already enumerated in a previous part of the response, so they are not listed again. It prevents infinite or repeated enumeration when bindings create multiple paths to the same collection.
What this means
208 Already Reported is part of RFC 5842, Binding Extensions to WebDAV. WebDAV bindings let the same resource appear under multiple paths. When a Depth-recursive operation such as PROPFIND enumerates a collection reachable through more than one binding, the server could otherwise report the same internal members repeatedly.
To avoid that, after listing a collection's members once, the server uses 208 for subsequent appearances of the same collection inside the same 207 multistatus response. It says: this was already reported above.
Why crawlers should never see it standalone
208 is only meaningful inside a 207 Multi-Status body — it is not a valid standalone response to a GET. A search or AI crawler fetching an HTML page will not encounter it under normal conditions.
If tooling reports a bare 208 for a content URL, treat it as a misconfiguration or a non-conformant server, because the code has no defined meaning outside WebDAV multistatus enumeration.
- RFC 5842 WebDAV binding extension
- Appears only inside a 207 multistatus body
- Prevents duplicate enumeration when bindings alias a collection
How it appears in analytics and logs
A 208 Already Reported never appears as a top-level response to a normal GET; it lives inside a 207 multistatus body. It indicates the server avoided re-listing a collection it had already detailed, which only happens with WebDAV bindings.
Diagnostic use case
Recognise 208 only as an internal status inside a WebDAV 207 body, signalling a resource already reported to avoid duplicate enumeration.
What WebmasterID can help detect
WebmasterID records crawler fetch statuses; a 208 is so specific to WebDAV bindings that its appearance flags an unusual server feature rather than normal content delivery.
Common mistakes
- Expecting 208 as a standalone GET response — it only lives inside a 207 body.
- Confusing 208 with a redirect or caching status; it is enumeration de-duplication.
- Enabling WebDAV bindings on paths that should serve plain content.
Privacy and accuracy notes
A 208 describes WebDAV enumeration behaviour, not visitors. WebmasterID records crawler fetch statuses without attaching them to any person.
Related pages
- HTTP 207 Multi-Status
HTTP 207 Multi-Status comes from RFC 4918 (WebDAV). Instead of one status for the whole request, the server returns a 207 with an XML multistatus body that reports a separate status for each affected resource. It is used when a single request touches multiple resources that can succeed or fail independently. It is a WebDAV/API response, not something search crawlers expect on content pages.
- Infinite redirect loops
An infinite redirect loop occurs when URL A redirects to B which redirects back to A (directly or through a cycle), so the request never reaches a final response. Browsers and crawlers stop after a few hops and report an error. Loops make pages completely unreachable, blocking both users and indexing.
- HTTP status code cheat sheet for crawlers
This cheat sheet maps the five HTTP status classes to what they mean for crawlers and indexing. It is a quick reference for reading server logs and Search Console crawl data: which codes index normally, which redirect, which signal client errors, and which are server failures crawlers will retry. The aim is to interpret status codes through a crawl-and-index lens rather than a generic one.
- Website observability
Surface unusual WebDAV status codes returned to crawlers, server-side.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.