A 206 means the server sent only the chunk of a file you asked for — used for streaming video, resuming a download, or progressively loading a large file. It is normal and expected for media content. The fix-it list is empty unless your CDN or origin is…
HTTP 206 Partial Content is a success response (it's not an error) that tells the client "here is the slice of the file you asked for." It is triggered when the request includes a Range header like Range: bytes=0-1023, asking for a specific byte range instead of the whole resource. The server replies with 206, a Content-Range header describing the slice that was returned, and just that slice in the body. This is how YouTube, Netflix, Spotify, and modern browsers stream video and audio without downloading the entire file upfront.
No direct SEO impact. 206 is a success response for byte-range requests on media files — Googlebot doesn't make range requests when crawling HTML, so you'll never see 206 on indexable pages. If your video sitemap pages serve media that needs to be played by Googlebot Video, byte-range support is required (Google can't index a video the player can't seek through).
LemWatch reports the final status code on monitored URLs, so a healthy media endpoint will register as 200/206 depending on whether the check sent a Range header. We can also probe video endpoints with explicit Range requests to verify byte-range support is working — critical for sites that depend on video playback.
Range requests were introduced in HTTP/1.1 (RFC 2616, 1999) and refined in RFC 7233 (2014). They became essential when HTML5 video and audio shipped — every modern browser uses range requests to seek inside a media file without re-downloading it. They are also how tools like curl --continue-at and wget --continue resume interrupted downloads.
HTTP 206 Partial Content means the server returned only the slice of the resource that the client asked for via a Range header, not the whole thing. It is a success response, not an error.
Because the client (a browser, video player, or download manager) sent a Range header asking for a specific byte range of the file. This is how streaming video, audio scrubbing, and resumable downloads work — the file is fetched in slices, each slice returns 206.
No. 206 is in the 2xx success range. It means "here is the partial content you asked for" — the request succeeded.
Whenever the request includes a Range header that the server can honour. If the server ignores the Range and returns the entire file, it should use 200; if it returns just the requested bytes, it should use 206 with a Content-Range header.
Nginx supports byte-range responses by default. Apache needs mod_dir and a server config that doesn't strip the Accept-Ranges header. S3, Cloudflare R2, and most CDNs handle this automatically. The key signal: your origin must send Accept-Ranges: bytes in its responses, and not strip Range headers from requests.
Almost always because your server isn't returning 206 for range requests on the video file. Safari and iOS WebKit require byte-range support to play <video> — they'll refuse to play a video served via a single 200 response.
206 means "here is the byte range you asked for." 416 Range Not Satisfiable means "the byte range you asked for falls outside the size of the file." 416 is the error counterpart of 206.