Content-Type

L'équipe Citead, mis à jour le

En bref. Content-Type déclare le format et le traitement prévu d’un contenu HTTP, tandis que le document transmis fournit le texte que le destinataire peut lire.

Définition : Content-Type est un champ d’en-tête HTTP qui indique le type de média (media type) du contenu associé. Un type de média décrit le format des données et le traitement attendu de la part du destinataire, par exemple l’interprétation d’un document comme du HTML.

Points clés

  • La RFC 9110, HTTP Semantics recommande à l’émetteur d’inclure Content-Type lorsqu’il envoie un contenu dont il connaît le type de média.
  • Au 17 octobre 2026, la documentation de Google sur les types de fichiers indique que Google détermine le type d’un fichier à partir de l’en-tête Content-Type, avec un recours possible à l’extension ou à un autre analyseur lorsque l’en-tête est absent ou incorrect.
  • Les recommandations de Google sur le SEO JavaScript distinguent les réponses HTML contenant tout le contenu de la page des coquilles d’application (application shells), dont le HTML initial ne contient pas le contenu réel de la page et nécessite l’exécution de JavaScript pour le rendre accessible.

Comment s’écrit un type de média ?

La syntaxe des types de médias définie par la RFC 9110 comprend un type, une barre oblique, un sous-type et des paramètres facultatifs. Dans text/html, text est le type et html le sous-type. Un point-virgule introduit un paramètre ; charset indique l’encodage des caractères utilisé pour le texte.

Cet en-tête associe le type de média HTML à l’encodage des caractères UTF-8, conformément aux exemples de la RFC :

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

Les noms de types et de sous-types sont insensibles à la casse. La RFC traite également les noms d’encodages de caractères sans tenir compte de la casse : UTF-8 et utf-8 désignent donc le même encodage.

Qu’est-ce qui rend un document transmis lisible ?

La documentation de Google sur les types de fichiers acceptés inclut le HTML et le texte brut parmi les formats textuels acceptés. Elle inclut également le PDF parmi les formats encodés qui nécessitent un analyseur spécifique pour en extraire le texte lisible par une personne. L’en-tête aide à déterminer le traitement adapté au document.

Pour les pages HTML, le contenu transmis comprend aussi le texte effectivement accessible au destinataire. Les recommandations de Google sur JavaScript expliquent que les pages avec rendu côté serveur peuvent contenir l’intégralité du contenu dans la réponse HTTP. Une coquille d’application peut initialement ne pas contenir le contenu réel de la page et nécessiter l’exécution de scripts. Les mêmes recommandations préconisent de préparer le HTML rendu sur le serveur, car certains robots ne peuvent pas exécuter JavaScript. Pour un site web qui fournit du contenu aux moteurs de réponse, il est donc utile de vérifier conjointement le corps de la réponse et le format déclaré.

Que faut-il examiner lors d’un contrôle de la transmission ?

La section de la RFC 9110 consacrée à Content-Type indique qu’une configuration incorrecte du serveur peut être à l’origine d’un type de média erroné. Un contrôle de la transmission compare donc l’en-tête renvoyé au format réel du document. La RFC définit Content-Type comme un champ à valeur unique et avertit que la répétition de ce champ peut entraîner des problèmes d’interopérabilité et de sécurité.

La compression dispose d’un champ distinct, Content-Encoding, qui décrit les transformations appliquées au contenu. La même RFC donne Content-Encoding: gzip comme exemple. Après décompression, les données conservent le type de média déclaré par Content-Type. Vérifier séparément le type de média, l’encodage des caractères et la compression aide à localiser une incohérence dans la transmission.

Termes associés

Questions fréquentes

Puis-je me fier à l’extension d’un nom de fichier ?

La documentation de Google sur les types de fichiers indique que Content-Type sert de base à la détermination du type de fichier. Une extension peut servir de solution de repli lorsque l’en-tête est absent ou incorrect ; examiner l’en-tête renvoyé reste donc utile, même pour une URL se terminant par .html.

Que se passe-t-il si j’omets Content-Type ?

La RFC 9110 autorise le destinataire à supposer que le type de média est application/octet-stream ou à examiner les données pour en déterminer le type. Fournir l’en-tête correct donne au destinataire une déclaration explicite du format prévu.

Sources

  1. IETF, « RFC 9110: HTTP Semantics », juin 2022
  2. Google Search Central, « File types indexable by Google », mis à jour le 3 février 2026
  3. Google Search Central, « Understand the JavaScript SEO basics », mis à jour le 4 mars 2026

Vérifiez comment une page se lit pour les moteurs de réponse. Ouvrir l’analyseur de score GEO

Testez une page et voyez quoi corriger en premier

L'analyse prend en général moins de 10 secondes et ne demande pas de compte.

400 000+ pages notées dans le benchmark public