Dois-je utiliser une extension de fichier ou non?

Je me suis toujours posé des questions à ce sujet 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 accessible 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 d'ajouter des mots clés dans l'URL. Même le guide SEO le plus basique le mentionnera. ... mais pour des raisons de clarté, de clarté, de facilité de lecture, de facilité d'utilisation, etc., y compris la conformité Web ...

Est-il préférable d'avoir une extension de fichier ou non?

Vraiment, au fond, ma logique me dit: oui, ça devrait. La raison en est que cela remonte aux jours du passé 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 là qu'index.htm est apparu, 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é à remplacer cela et à utiliser index.htm pour réellement servir le contenu de ce répertoire Web en tant que page . La principale différence est que le langage de balisage a été ajouté, et cela a été analysé dans le navigateur. Avec ce langage de balisage, la Content-Type:text/html;balise dans l'en-tête de réponse est devenue l'indicateur de quel type de fichier c'était pour n'importe quel fichier . HTML semble être le seul "type de fichier" qui n'a tout simplement pas d'extensions nommées de manière cohérente, sauf quand elles sont enregistrées.

Malheureusement, une fois que les pages Web sont devenues l'élément principal, il est devenu une erreur de sécurité d'afficher réellement le contenu du répertoire, donc tout est resté caché avec uniquement le contenu URL réel affiché.

Sans parler des guerres de dénomination de fichiers multiplateforme. Les fenêtres basées nécessitent une extension à 3 chiffres ou moins, et unix / mac peut en avoir plus. Alors, devrait-il être .HTMou .HTMLou NONEet laisser la plateforme décider?

Donc, en substance, je suppose que ce que j'essaie de comprendre est au - delà du référencement et traite davantage de l'esthétique et de la conformité Web.

Utilisez un .extension où il y a plus d'une représentation ou où le logiciel client est absolument stupide et refuse d'accepter le Content-Type seul (QuickTime, RealPlayer, Outlook, etc. je vous regarde):

• http://www.somesite.com/subdirectory - cela peut être votre version d'auto-négociation qui utilise des balises META canoniques pour pointer vers la représentation réelle

• http://www.somesite.com/subdirectory/ - il vaut toujours la peine de prendre en charge les barres obliques de fin sur n'importe quelle URL, mais en utilisant des balises METAL canoniques (pas de redirection car il s'agit d'un ralentissement inutile) pour pointer vers l'URL correcte

• http://www.somesite.com/subdirectory/index.htmet http://www.somesite.com/subdirectory/some-relevant-keywords.htm- la limite d'extension de trois caractères ne s'applique pas à HTTP (uniquement le FileSystem / OS sous-jacent) afin que le client puisse l'enregistrer sous index.html ou aa s'il le souhaite, tout en étant toujours en mesure d'y accéder

• http://www.somesite.com/subdirectory/index.html - si vous diffusez un .atom, un .xml ou une version similaire, il est logique d'honorer également la version .html (et de la lier de manière canonique via des balises LINK sur la version négociée automatiquement) - utilisez les en-têtes HTTP Content-Location pour pointer à la version de négociation automatique - rappelez-vous que vous pouvez également opter pour plusieurs langues (.en, .es, etc ...) ou multi-charset (.utf8, .utf16, etc ...)

• http://www.somesite.com/subdirectory/index.phpet http://www.somesite.com/subdirectory/index.asp- à moins que vous ne serviez le code source, cela n'a aucun sens

• http://www.somesite.com/subdirectory/some-relevant-keywords - Le référencement est un art en constante évolution et si cela fonctionne pour vous, alors super

• http://www.somesite.com/subdirectory/index.php?page=some-relevant-keywords, http://www.somesite.com/subdirectory/?page=some-relevant-keywordset http://www.somesite.com/subdirectory/?page=some-relevant-keywords&even=more-keywords- s'il existe un nombre infini de façons de manipuler le contenu, alors c'est génial - mais généralement les pages méritent leur propre URL et non une chaîne de requête et ce type d'URL doit être évité (essayez de mettre un ordinateur analphabète pour taper l'un des ceux en)

Je dirais de ne pas inclure l'extension de fichier si le logiciel que vous utilisez vous permet de l'omettre. Donc, à partir de votre liste d'exemples, ma préférence serait:

http://www.somesite.com/subdirectory/some-relevant-keywords

Les navigateurs ne se soucient pas de savoir si quelque chose est un répertoire ou non sur le site, ou s'il s'agit d'un fichier HTML, d'un fichier .asp ou autre - ils font simplement une demande HTTP et obtiennent une réponse HTTP. Donc, si l'extension est superflue, supprimez-la.

Cela a également l'avantage supplémentaire de rendre vos URL plus concises (et plus faciles à lire sur le téléphone - "exemple de produits slash dot com" est beaucoup plus agréable que "exemples de produits slash dot com dot htm l"), et de le rendre plus facile pour changer de technologie à l'avenir (car aucun changement d'URL ne serait nécessaire).

Les URI cool ne changent pas . (Allez à la section intitulée "Alors, que dois-je faire? Conception d'URI")

Est-il préférable d'avoir une extension de fichier ou non?

Il n'y a rien dans les RFC pour exiger des extensions de fichier, ni rien vous obligeant à les laisser de côté. C'est un choix que vous faites.

Les URI HTTP conformes n'ont besoin d'extensions de fichier pour rien. Il existe un riche ensemble d'en-têtes HTTP (en particulier le type MIME) pour gérer tout ce pour quoi les extensions de fichier sont utilisées par ailleurs.

Cela dit, la plupart des navigateurs s'appuient actuellement sur une combinaison de type MIME, d'extension et d '«empreinte digitale» 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, les webmasters, définissions les bons en-têtes (et désactiviez éventuellement le reniflement du type de contenu si nous sommes sûrs à 101% que nos en-têtes sont corrects).

Il existe une situation 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 proposant du contenu avec des extensions standard comme .jpg, .mp4, .css etc. D'après 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 traitera correctement ce type de contenu spécifique.

Sécurité: on pourrait soutenir qu'il y a un avantage de sécurité à cacher la plate-forme que vous utilisez (.php / .asp, etc.). C'est vrai. Dans la pratique, je pense que tout bon pirate découvrira cela immédiatement, donc je ne pense pas que cacher ces extensions pour la sécurité en vaut 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 téléchargé sur le CDN via SFTP), vous souhaiterez peut-être conserver les extensions de fichier. La plupart des systèmes tiers examinent les extensions de fichier pour découvrir avec quel type MIME servir le contenu.

Mon choix personnel est devenu:

• Lorsque le HTML est généré dynamiquement par ma webapp, je n'ajoute pas une extension "fausse" .html pour imiter un répertoire et une structure de fichiers qui ne sont pas réellement là. Je normalise les URL et je standardise le format d'URL utilisé pour des raisons de référencement. Personnellement, je préfère avoir une barre oblique sur la dernière feuille de l'URL, c'est http://example.org/first/second/-à- dire , mais c'est une question de goût.

• Lorsque nous parlons en fait de fichiers réels qui sont téléchargés sur un disque dur quelque part, je conserve l'extension de fichier «normale» pour le type. Donc .css / .js / .exe / .mp4 etc. sont utilisés pour ces types de contenu.

J'ai fait une petite expérimentation informelle, et ce que j'ai découvert m'a surpris mais a du sens.

Du point de vue du contenu livré à l'utilisateur, ainsi que du grattage de l'écran, le type de contenu gouverne la journée.

Cependant, la présence ou l'absence d'une extension, ainsi que ce que cette extension est, semble influencer les visites des moteurs de recherche.

Lorsque j'ai omis une extension, j'ai reçu relativement peu de hits - comme si l'URL était un emplacement ou un contenu dynamique et ne valait donc pas vraiment la peine d'être indexée.

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 en fait chuté davantage - peut-être parce qu'elle pensait qu'il s'agissait simplement de données ou du résultat d'une demande de programmation .

Lorsque j'ai changé les mêmes liens pour utiliser .html, les moteurs de recherche se sont déchaînés avec le site.

Pour le moment, mon site gère les trois de manière transparente, 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 un peu moins biaisés, mais c'est ce que j'ai observé avec mes pages.

Non, vous ne devez pas utiliser une extension de fichier pour les types de page normaux, sauf si vous en avez absolument besoin pour une raison technique. Comment améliore-t-il l'expérience utilisateur? C'est plus à taper, mais cela ne leur dit rien d'utile. Que pourront-ils faire en sachant que votre site est 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, 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 n'est un répertoire que lorsqu'elle comporte une barre oblique de fin. Sans barre oblique de fin, 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 alors, vous pouvez le supprimer s'il n'y a qu'une seule représentation (JPG, PDF, ...).

S'il y a plusieurs représentations, la voie HTTP consisterait à négocier le format via l'en- Accepttête. Mais si vous voulez que vos utilisateurs aient leur mot à dire, vous voudrez probablement avoir une extension afin qu'ils puissent choisir la représentation qu'ils souhaitent (JPG, PNG, ...) en demandant l'un ou l'autre URI.