Response content type
The response content type is the value returned in the HTTP Content-Type header. It tells browsers and search engines what kind of resource the URL is serving, such as an HTML page, a PDF, JSON, or an image.
This is a useful check because a page can still return a normal status code while serving the wrong kind of content. If the content type changes unexpectedly, it may signal a broken response, misconfiguration, or a page that is no longer being delivered in the format search engines expect.
What it is
The Content-Type header describes the media type of the server response.
A typical page response might return:
text/html; charset=UTF-8
That means the URL is serving an HTML document using UTF-8 character encoding.
SEOlerts stores the exact header value and alerts you if it changes. This helps detect when a page that should behave like a normal HTML page starts returning something different.
Why it matters
Search engines and browsers use the content type to understand how to process a URL.
For most standard web pages, the expected type is HTML. If the response changes to something else, such as application/json, text/plain, or a file type, the page may no longer be treated as a normal indexable document. Even where the URL still loads, the way it is parsed and interpreted can change significantly.
This matters because the content type helps define what the URL actually is. A page that stops being served as HTML may no longer behave as a page in the normal SEO sense.
What can go wrong if unchecked
If the content type changes unexpectedly, the URL may stop delivering the kind of response users and search engines expect.
Common problems include:
- an HTML page returning JSON or plain text
- an error page being served with an incorrect type
- a CMS or server misconfiguration changing header output
- application endpoints replacing page responses
- cached or proxy-level issues serving the wrong resource type
- file downloads or API responses appearing where a page should be
This is useful for catching broken non-HTML responses because the page may still return 200, making the issue less obvious in basic uptime checks.
The reverse can matter too. A non-HTML asset unexpectedly switching to text/html can also signal a delivery or routing problem.
Why monitoring it matters
Monitoring the response content type helps you detect changes in how a URL is being served, not just whether it is reachable.
This is especially useful after deployments, server changes, caching changes, CDN updates, CMS edits, routing changes, or application rewrites. These are common moments when a page can accidentally start returning the wrong media type.
Because the full header value is stored, you can also catch smaller but still meaningful changes, such as altered encoding declarations.
What an alert may mean
An alert means the HTTP Content-Type header has changed from the previously stored value.
In practice, that could mean:
- the page is no longer being served as HTML
- application routing has changed
- a server, CDN, or cache layer is returning a different response
- a file or API response is being served at the page URL
- encoding settings have changed
- a broken or fallback response is being delivered instead of the intended page
The alert does not automatically mean the page is unusable, but it does mean the nature of the response has changed and should be checked.
What to check next
Start by requesting the URL directly and inspecting the current Content-Type header.
Then review:
- whether the page should still be serving
text/html - whether the response body matches the declared content type
- whether recent deployments, routing changes, or cache updates explain the change
- whether the issue affects one URL or a wider section of the site
- whether the page still renders properly in a browser and for crawlers
If the page is returning a non-HTML type unexpectedly, check server configuration, application routes, CDN rules, and any recent infrastructure changes. Also review the HTTP status code, because content type problems often appear alongside other response issues.
Key takeaway
The response content type shows what kind of resource a URL is actually serving through the HTTP Content-Type header. Monitoring it helps you catch broken non-HTML responses, header misconfigurations, and delivery issues that may not show up in simpler checks. An alert means the format of the response has changed, and that change should be reviewed to confirm the URL is still serving the intended content.
