In short. Content-Type declares the format and intended processing of HTTP content, while the delivered document supplies the text a recipient can read.

Definition: Content-Type is an HTTP header field that identifies the media type of the associated content. A media type describes the data format and how a recipient is intended to process it, such as interpreting a document as HTML.

Key facts

RFC 9110, HTTP Semantics recommends that a sender include Content-Type when sending content whose media type it knows.
As of 17 October 2026, Google's file type documentation says Google determines a file's type from the Content-Type header, with possible fallback to the extension or another parser when the header is missing or incorrect.
Google's JavaScript SEO guidance distinguishes HTML responses containing all page content from application shells, whose initial HTML lacks the actual page content and requires JavaScript execution to expose it.

How is a media type written?

RFC 9110's media type syntax consists of a type, a slash, a subtype and optional parameters. In text/html, text is the type and html is the subtype. A semicolon introduces a parameter; charset identifies the character encoding used for text.

This header combines the HTML media type with the UTF-8 character encoding, matching the RFC's examples:

Content-Type: text/html;charset=utf-8

Type and subtype names are case-insensitive. The RFC also treats the charset names case-insensitively, so UTF-8 and utf-8 identify the same encoding.

What makes a delivered document readable?

Google's supported file types documentation lists HTML and plain text among supported text-based formats. It also lists PDF among encoded formats whose human-readable text requires a specific parser. The header helps identify which processing is appropriate for the document.

For HTML pages, delivery also includes the actual text available to the recipient. Google's JavaScript guidance explains that server-side rendered pages can contain all content in the HTTP response. An application shell can initially lack the actual page content and require script execution. The same guidance recommends preparing rendered HTML on the server because some bots cannot run JavaScript. For a website serving answer engines, this makes the response body and the declared format useful checks alongside one another.

What should a delivery check examine?

RFC 9110's Content-Type section identifies incorrect server configuration as a reason for wrong media types. A delivery review therefore compares the returned header with the actual document format. The RFC defines Content-Type as a single-value field and warns that repeated fields can cause interoperability and security problems.

Compression has a separate field, Content-Encoding, which describes transformations applied to the content. The same RFC gives Content-Encoding: gzip as an example. After decompression, the data still has the media type declared by Content-Type. Checking the media type, character encoding and compression separately helps locate a delivery mismatch.

FAQ

Can I rely on a filename extension?

Google's file type documentation identifies Content-Type as its basis for determining the file type. An extension can serve as a fallback when the header is missing or incorrect, so inspecting the returned header remains useful even for a URL ending in .html.

What happens if I omit Content-Type?

RFC 9110 permits the recipient to assume the media type application/octet-stream or examine the data to determine its type. Supplying the correct header gives the recipient an explicit declaration of the intended format.

Sources

Check how a page reads to answer engines. Open the GEO score analyzer