web-dev-qa-db-fra.com

Est-ce que ça va faire mal à SEO de supprimer l'extension '.html' des pages statiques pour qu'elles soient servies en tant que 'text / x-generic'?

Si nous voulons aller avec un site web statique, nous générons des fichiers HTML statiques de pages avec des noms comme contacts.html et nous pouvons ajouter à notre fichier .htaccess les lignes telles que

RewriteEngine On
RewriteRule ^(([^/]+/)*[^.]+)$ /$1.html [L]

Donc, si nous suivons par le lien /contacts, nous obtenons le contenu du fichier public_html/contacts.html dans le navigateur.

Mais que se passe-t-il si vous voulez enregistrer des fichiers statiques sans l’extension .html, c’est-à-dire simplement avec le nom contacts? En d'autres termes, avec le type text/x-generic. Dans ce cas, nous n’avons pas besoin de la règle .htaccess, mais existe-t-il des inconvénients de l’approche du référencement naturel ou/et d’un autre camp?

ps. Je veux dire si j'utilise un hébergement partagé et que je n'ai pas accès à nginx

Ce n'est pas une copie de la question Dois-je utiliser une extension de fichier ou non? car je ne demande pas d'utiliser l'extension .html dans la barre d'adresse du navigateur ou pas.

seohtmlwebserverhttp-headersstatic-content
5
stckvrw

Ce n’est pas tant un problème de référencement que de savoir si votre site fonctionnerait du tout. Si cela ne fonctionne pas dans le navigateur, cela va certainement nuire à votre référencement.

Vos pages HTML doivent toujours renvoyer le type mime text/html pour pouvoir être interprétées en tant que HTML par le navigateur. c'est à dire. Vous devez en quelque sorte envoyer un en-tête de réponse HTTP Content-Type: text/html.

En règle générale, Apache utilise l'extension de fichier pour déterminer le type mime (à l'aide de la directive AddType], à partir duquel il génère l'en-tête de réponse Content-Type HTTP. S'il n'y a pas d'extension de fichier, le système retournera les valeurs par défaut définies par votre serveur pour les types de fichiers inconnus. (Gardez à l'esprit que ce "défaut" pourrait être rien du tout, c'est-à-dire non Content-Type.)

En d'autres termes, avec le type text/x-generic.

Si le serveur envoie un text/x-genericContent-Type, le navigateur va probablement voir la réponse en texte brut et l'afficher sous la forme en texte brut . c'est à dire. les utilisateurs voient la source HTML brute.

De plus, même si votre serveur peut être configuré pour envoyer une réponse text/x-generic par défaut, ce n’est en aucun cas une norme. De nombreux serveurs utiliseront par défaut application/octet-stream, ce qui déclenchera probablement le navigateur pour télécharger le fichier. c'est à dire. L'utilisateur peut voir une boîte de dialogue "Enregistrer sous ...".

La valeur par défaut sur Apache 2.4 n’est pas du tout Content-Type. Il reste donc au navigateur à interpréter la réponse et à décider par lui-même. Cependant, cela pourrait naturellement entraîner des réponses différentes de la part des différents navigateurs, car je ne crois pas qu’il existe un "standard" dans ce cas.

Nous n'avons pas besoin de la règle .htaccess dans un tel cas

Mais vous avez besoin de quelque chose pour "réparer" l'en-tête Content-Type.

Solution de contournement (enfin, genre de ...)

Dans les commentaires, il est mentionné la possibilité de définir le type mime par défaut dans .htaccess. Cependant, ceci n'est disponible que sur Apache 2.2 via la directive DefaultType. Par exemple, ce qui suit renvoie un en-tête Content-Type: text/html pour les ressources pour lesquelles le type mime ne peut pas être déduit.

DefaultType text/html

Cependant, DefaultType ne fonctionne pas sur Apache 2.4. Il est uniquement disponible pour la compatibilité ascendante (c.-à-d. Qu'il ne casse pas le serveur - mais ne fait rien en réalité).

Sur Apache 2.4, il est recommandé d'utiliser AddType - en d'autres termes, la recommandation consiste à baser le type mime sur l'extension de fichier sous-jacente. , par exemple. .html. Donc, en supprimant l'extension du fichier, vous vous opposez à la recommandation d'Apache.

Alternativement, vous pouvez utiliser ForceType - mais ceci force le type mime sur toutes les ressources (selon l'endroit où vous avez placé la directive) - donc cela doit être réglé sous condition. Mais sur quoi fondez-vous cette condition? Vous pourriez peut-être vérifier que le nom de fichier ne contient pas de point (ou ne contient qu'un ensemble limité de caractères autorisés), c'est-à-dire. il ne ressemble pas à il a une extension de fichier:

<FilesMatch "^[^.]+$">
ForceType text/html
</FilesMatch>

Cependant, il pourrait éventuellement y avoir d'autres problèmes:

  • Comment sont les en-têtes de cache de votre serveur? Cela pourrait être basé sur l'extension de fichier, bien qu'il soit préférable de le définir en fonction du type mime.

  • Si vous voulez ouvrir ces fichiers dans un éditeur ... comment votre éditeur traite-t-il les fichiers sans extension?

Résumé:

Tu pourrais faire ça, mais pas moi. Réécrivez l'URL à la place.

Référence:

  • DefaultType sur Apache 2.2 et Apache 2.4
  • ForceType sur Apache 2.4
  • Archive de listes de diffusion décrivant DefaultType (raisons de supprimer Apache 2.4) et ForceType ainsi que d'autres méthodes possibles (non fonctionnelles) pour définir l'en-tête Content-Type à l'aide de la directive Header (Bien que ce ne soit pas trivial en raison de la nature de l'en-tête Content-Type). ( De côté: Notez qu'il n'a été possible de définir que l'en-tête Content-Type - avec la directive Header - depuis Apache 2.2.12):
    https://lists.gt.net/Apache/users/443558
  • Répondez sur SO qui indique une méthode évidente pour définir l'en-tête Content-Type à l'aide de la directive Header et d'expressions pour définir conditionnellement l'en-tête Content-Type uniquement s'il n'est pas déjà défini (référence ci-dessus):
    https://stackoverflow.com/a/37529835/369434
6
MrWhite