Devrais-je utiliser une extension de fichier ou non?
Je me suis toujours posé la question et je n'ai jamais trouvé de bonne solution.
Mais cette question me l'a rappelé.
Lorsque j'ai une URL sur mon site Web, elle peut être affichée et utilisée de l'une des manières suivantes:
http://www.somesite.com/subdirectory
http://www.somesite.com/subdirectory/
http://www.somesite.com/subdirectory/index.htm
http://www.somesite.com/subdirectory/index.html
http://www.somesite.com/subdirectory/index.php
http://www.somesite.com/subdirectory/index.asp
http://www.somesite.com/subdirectory/some-relevant-keywords
http://www.somesite.com/subdirectory/some-relevant-keywords.htm
http://www.somesite.com/subdirectory/index.php?page=some-relevant-keywords
http://www.somesite.com/subdirectory/?page=some-relevant-keywords
http://www.somesite.com/subdirectory/?page=some-relevant-keywords&even=more-keywords
etc...
Maintenant, je peux comprendre les avantages de l’ajout de mots-clés dans l’URL. Même le guide de référencement le plus élémentaire mentionnera exactement cela. ... mais par souci de cohérence, de clarté, de facilité de lecture, d'utilisation, etc. , y compris la conformité Web ...
Est-il préférable d'avoir une extension de fichier ou non?
Vraiment, au fond de ma logique, il me dit que oui. La raison en est que cela remonte à l'époque où Internet était principalement USENET, FIDONET, FTP et Gopher.
Voir, si une URL n'a pas de nom de fichier , elle est normalement considérée comme un répertoire . C'est ici qu'index.htm a été créé, car il répertorie par défaut le répertoire si aucun fichier d'index n'est trouvé. Cependant, assez tôt, les programmeurs Web ont commencé à contourner cela et à utiliser index.htm pour servir le contenu de ce répertoire Web sous forme de page . La principale différence, c’est que le langage de balisage a été ajouté et analysé dans le navigateur. Avec ce langage de balisage, la balise Content-Type:text/html; de l'en-tête de la réponse devenait l'indicateur du type de fichier pour n'importe quel fichier . HTML semble être le seul "type de fichier" pour lequel les extensions ne portent pas de nom cohérent, à l'exception du moment où elles sont enregistrées.
Malheureusement, une fois que les pages Web sont devenues l'essentiel, l'affichage du contenu du répertoire est devenu une erreur de sécurité. Ainsi, tout est resté masqué, seul le contenu réel de l'URL étant affiché.
Sans oublier les guerres de nommage de fichiers sur plusieurs plates-formes. Les fenêtres basées sur Windows nécessitent une extension de 3 chiffres ou moins, et unix/mac peut en avoir davantage. Donc, faut-il que ce soit .HTM ou .HTML ou NONE et laisser la plate-forme décider?
Donc, en gros, je suppose que ce que je cherche à comprendre, c’est au-delà du référencement et que je traite davantage de l’esthétique et de la conformité Web.
Utilisez une extension où il y a plus d'une représentation ou où le logiciel client est complètement stupide et refuse d'accepter le type de contenu seul (QuickTime, RealPlayer, Outlook, etc. Je vous regarde):
http://www.somesite.com/subdirectory- il peut s'agir de votre version de négociation automatique qui utilise des balises META Canonical pour pointer sur la représentation réellehttp://www.somesite.com/subdirectory/- il est toujours utile de prendre en charge les barres obliques de fin, mais d'utiliser les balises META de Canonical (pas de redirections car il s'agit d'un ralentissement inutile) pour pointer sur la bonne URL.http://www.somesite.com/subdirectory/index.htmethttp://www.somesite.com/subdirectory/some-relevant-keywords.htm- la limite d'extension de trois caractères ne s'applique pas à HTTP (uniquement le système de fichiers/système d'exploitation sous-jacent). Le client peut donc enregistrer ce fichier sous le nom index.html ou aa s'il le souhaite, tout en restant. pouvoir y accéderhttp://www.somesite.com/subdirectory/index.html- si vous utilisez un fichier .atom, un fichier .xml ou une version similaire, il est également judicieux d'honorer la version .html (et de la lier de manière Canonique via des balises LINK sur la version négociée automatiquement) - utilisez le contenu HTTP. -En-têtes de localisation pour pointer sur la version de négociation automatique - n'oubliez pas que vous pouvez également utiliser plusieurs langues (.en, .es, etc ...) ou plusieurs jeux de caractères (.utf8, .utf16, etc ...)http://www.somesite.com/subdirectory/index.phpethttp://www.somesite.com/subdirectory/index.asp- à moins que vous ne fournissiez le code source, cela n'a aucun sens de prendre en chargehttp://www.somesite.com/subdirectory/some-relevant-keywords- Le référencement est un art en constante évolution et si cela fonctionne pour vous alors superhttp://www.somesite.com/subdirectory/index.php?page=some-relevant-keywords,http://www.somesite.com/subdirectory/?page=some-relevant-keywordsethttp://www.somesite.com/subdirectory/?page=some-relevant-keywords&even=more-keywords- s'il existe un nombre infini de façons de manipuler le contenu, c'est génial - mais les pages méritent généralement leur propre URL, et non une chaîne de requête, et ce type de contenu. Les URL doivent être évitées (essayez de demander à une personne analphabète de taper l'une de celles-ci)
Je dirais que ne pas inclure l'extension de fichier si le logiciel que vous utilisez vous permet de l'omettre. Donc, de votre liste d'exemples, ma préférence serait:
http://www.somesite.com/subdirectory/some-relevant-keywords
Les navigateurs ne s'inquiètent pas de savoir si quelque chose est un répertoire sur le site ou s'il s'agit d'un fichier HTML, d'un fichier .asp ou autre - ils font simplement une requête HTTP et obtiennent une réponse HTTP. Donc, si l'extension est superflue, laissez-la tomber.
Cela présente également l’avantage de rendre vos URL plus concises (et plus faciles à lire au téléphone - "exemple de produits slash point com" est beaucoup plus esthétique que "exemple de produit slash point com dot html") et facilite changer de technologie à l’avenir (aucun changement d’URL n’est requis).
Les URI sympas ne changent pas . (Allez à la section intitulée "Alors, que dois-je faire? Conception des URI")
Est-il préférable d'avoir une extension de fichier ou pas?
Il n'y a rien dans les RFC qui oblige à avoir des extensions de fichiers, ni rien ne vous oblige à les laisser de côté. C'est un choix que vous faites.
Les URI HTTP conformes ne nécessitent aucune extension de fichier. Il existe un riche ensemble d’en-têtes HTTP (en particulier le type MIME) permettant de gérer tout ce pour quoi les extensions de fichier sont utilisées.
Cela dit, la plupart des navigateurs utilisent aujourd'hui une combinaison du type MIME, de l'extension et de "l'empreinte" binaire des premiers octets pour déterminer le type de contenu. Cela peut parfois donner des résultats surprenants , et il est donc important que nous, webmasters, sélectionnions les bons en-têtes (et éventuellement désactivez le reniflement du type de conten si nous sommes sûrs à 101% que nos en-têtes sont corrects) .
Il existe un cas où les extensions de fichier sont utiles: Si l'utilisateur final enregistre le contenu de votre site sur son ordinateur local pour une utilisation ultérieure. Théoriquement, un navigateur 'intelligent' devrait garantir que le contenu enregistré fonctionne pour le type d'ordinateur local; mais dans la pratique, vous pouvez aider tout le monde en fournissant du contenu avec des extensions standard telles que .jpg, .mp4, .css etc. Selon mon expérience, tous les navigateurs gèrent correctement le type HTML. Vous n'avez pas besoin d'ajouter vous-même une extension .htm/.html sur HTML, le navigateur gérera correctement ce type de contenu spécifique.
Sécurité: On pourrait dire qu'il est avantageux de cacher la plate-forme que vous utilisez (.php/.asp, etc.). C'est vrai. En pratique, je pense que tout bon pirate informatique le découvrira immédiatement. Je ne pense donc pas que cacher ces extensions uniquement pour la sécurité vaille la peine.
Considération particulière: Si vous prévoyez d'utiliser un CDN à l'avenir, et que votre CDN est du type "Push" (le contenu est préalablement chargé sur le CDN. fx via SFTP), vous voudrez peut-être conserver les extensions de fichier. La plupart des systèmes tiers examinent les extensions de fichier pour déterminer le type MIME avec lequel diffuser le contenu.
Mon choix personnel est devenu:
Lorsque HTML est généré dynamiquement par mon application Web, je n’ajoute pas une extension .html "fictive" pour imiter un répertoire et une structure de fichiers qui n’y figurent pas réellement. Je normalise les URL et le format d’URL utilisé pour des raisons de référencement. Personnellement, je préfère avoir une barre oblique à la fin de la dernière page de l'URL, c'est-à-dire
http://example.org/first/second/, mais c'est une question de goût.Quand nous parlons en fait de fichiers réels qui sont téléchargés sur un disque dur quelque part, je garde l’extension de fichier "normale" pour le type. Donc, .css/.js/.exe/.mp4, etc. sont utilisés pour ce type de contenu.
J'ai fait quelques expériences informelles et ce que j'ai découvert m'a surpris mais n'a pas de sens.
Du point de vue du contenu remis à l'utilisateur, ainsi que de la suppression d'écran, le type de contenu gouverne le jour.
Cependant, la présence ou l'absence d'une extension, ainsi que la nature de cette extension, semblent influencer les visites des moteurs de recherche.
Lorsque j'ai omis une extension, j'ai eu relativement peu de résultats - comme si l'URL était un emplacement ou un contenu dynamique et qu'il ne valait donc pas la peine d'indexer.
Lorsque j'ai changé les mêmes liens pour utiliser une extension .xml, parce que les pages ont été générées par XSLT (côté serveur), l'indexation a été abandonnée davantage - peut-être parce qu'il pensait qu'il ne s'agissait que de données ou du résultat d'une requête de programmation .
Lorsque j'ai modifié les mêmes liens pour qu'ils utilisent le format .html, les moteurs de recherche se sont déchaînés avec le site.
Pour le moment, mon site gère les trois en toute transparence, mais lorsqu'il fournit un lien cliquable, je renvoie la version .html de l'URL.
J'aimerais penser que les moteurs de recherche étaient un peu plus intelligents ou moins biaisés, mais c'est ce que j'ai observé se produire avec mes pages.
Non, vous ne devriez pas utiliser une extension de fichier pour les types de page normaux, sauf si vous en avez absolument besoin pour des raisons techniques. Comment cela améliore-t-il l'expérience utilisateur? C'est plus facile à taper, mais cela ne leur dit rien d'utile. Que pourront-ils faire en sachant que votre site est en PHP, ASP, etc.? Une URL est plus simple, plus propre, plus utilisable et plus mémorable sans extension de fichier.
Voir, si une URL n'a pas de nom de fichier, alors elle est normalement considérée comme un répertoire.
Je ne pense pas être d'accord. En règle générale, une URL est un répertoire uniquement lorsqu'elle comporte une barre oblique de fin. Sans une barre oblique finale, il est considéré comme un fichier.
Vous ne devez ajouter une extension de fichier que si le contenu derrière l'URI est en fait un fichier. Mais même dans ce cas, vous pouvez le laisser tomber s'il n'y a qu'une représentation (JPG, PDF, ...).
S'il y a plusieurs représentations, la méthode HTTP consisterait à négocier le format via l'en-tête Accept. Mais si vous voulez que vos utilisateurs aient leur mot à dire, vous voudrez probablement avoir une extension pour pouvoir choisir la représentation de leur choix (JPG, PNG, ...) en demandant l'un ou l'autre URI.