Должен ли я использовать расширение файла или нет?

Я всегда задавался вопросом об этом и никогда не находил хорошего решения.

Но этот вопрос напомнил мне об этом.

Когда у меня есть URL на моем веб-сайте, он может быть отображен и доступен любым из следующих способов:

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

так далее...

Теперь я могу понять достоинства добавления ключевых слов в URL. Даже самое простое руководство по SEO будет упоминать именно это. ... но ради здравомыслия, ясности, удобства чтения, удобства использования и т. д., включая соответствие веб-требованиям ...

Является ли он предпочел иметь расширение файла или нет?

Действительно, в глубине души моя логика говорит мне: да, так и должно быть. Причина в том, что это восходит к прошлым временам, когда Интернет был в основном USENET, FIDONET, FTP и GOPHER.

Смотрите, если у URL нет имени файла , то он обычно считается каталогом . Именно здесь возник файл index.htm, поскольку по умолчанию в нем указывается каталог, если индексный файл не найден. Однако довольно скоро веб-программисты начали переопределять это и использовать index.htm, чтобы фактически обслуживать содержимое этого веб-каталога как страницу . Основным отличием было добавление языка разметки, и это было проанализировано в браузере. С этим языком разметки Content-Type:text/html;тег в заголовке ответа стал индикатором того, какой тип файла был для любого файла . Кажется, что HTML является единственным «типом файла», который не имеет последовательно именованных расширений, за исключением случаев, когда они сохраняются.

К сожалению, как только веб-страницы стали главными, это стало ошибкой безопасности, чтобы фактически отобразить содержимое каталога, поэтому все оставалось скрытым, при этом отображался только фактический контент URL.

Не говоря уже о кросс-платформенных войнах имен файлов. Для Windows требуется расширение из 3 или менее цифр, а у unix / mac может быть больше. Так должно быть .HTMили .HTMLили NONEи пусть платформа решит?

Так что, по сути, я думаю, что я пытаюсь понять, что выходит за рамки SEO и больше касается эстетики и соответствия веб-требованиям.

Используйте .extension, если существует более одного представления или если клиентское программное обеспечение абсолютно глупо и отказывается принимать только Content-Type (QuickTime, RealPlayer, Outlook и т. Д. Я смотрю на вас):

• http://www.somesite.com/subdirectory - это может быть ваша версия с автоматическим согласованием, в которой используются мета-теги Canonical для указания фактического представления

• http://www.somesite.com/subdirectory/ - всегда стоит поддерживать косые черты на любом URL, но использовать мета-теги Canonical (не перенаправлять, поскольку это является ненужным замедлением), чтобы указывать на правильный URL

• http://www.somesite.com/subdirectory/index.htmи http://www.somesite.com/subdirectory/some-relevant-keywords.htm- ограничение расширения в три символа не применяется к HTTP (только базовая FileSystem / OS), поэтому клиент может сохранить его как index.html или aa, если хочет, при этом все еще имея возможность доступа к нему

• http://www.somesite.com/subdirectory/index.html - если вы используете .atom, .xml или аналогичную версию, то имеет смысл также учитывать версию .html (и канонически ссылаться на нее через теги LINK на версии с автоматическим согласованием) - использовать заголовки HTTP Content-Location для указания к версии с автоматическим согласованием - помните, что вы также можете перейти на многоязычный (.en, .es и т. д.) или на несколько кодировок (.utf8, .utf16 и т. д.)

• http://www.somesite.com/subdirectory/index.phpи http://www.somesite.com/subdirectory/index.asp- если вы не обслуживаете исходный код, поддерживать их бессмысленно

• http://www.somesite.com/subdirectory/some-relevant-keywords - SEO - это постоянно меняющееся искусство, и если это работает для вас, тогда отлично

• 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- если есть бесконечное число способов манипулировать содержание , то это здорово - но обычно страницы заслуживают их собственный URL не строка запроса и их тип URL , которые следует избегать (попытаться получить кто - то компьютерно неграмотный типа один из те, в)

Я бы сказал , не включайте расширение файла, если программное обеспечение, которое вы используете, позволяет вам его опустить. Итак, из вашего списка примеров я бы предпочел:

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

Браузеры не заботятся о том, является ли что-то каталогом или нет на сайте, или это HTML-файл, ASP-файл или что-то еще - они просто делают HTTP-запрос и получают HTTP-ответ. Так что если расширение лишнее, отбросьте его.

Это также дает дополнительное преимущество, заключающееся в том, что ваши URL-адреса становятся более лаконичными (и их легче читать по телефону - «пример dot com slash products» звучит гораздо приятнее, чем «example dot com slash products dot htm l») и упрощает его. для переключения технологий в будущем (так как изменение URL не потребуется).

Классные URI не меняются . (Перейдите к разделу «Так что же мне делать? Разработка URI»)

Желательно ли иметь расширение файла или нет?

В RFC нет ничего, чтобы предписывать наличие расширений файлов, и нет ничего, что требовало бы от вас их исключать. Это выбор, который вы делаете.

Соответствующие HTTP URI не нуждаются ни в каких расширениях файлов. Существует богатый набор заголовков HTTP (особенно MIME-типа) для обработки всего, для чего в противном случае используются расширения файлов.

При этом большинство современных браузеров фактически используют комбинацию типа MIME, расширения и двоичного «отпечатка пальца» первых байтов для определения типа контента. Иногда это может давать неожиданные результаты , и поэтому важно, чтобы мы, веб-мастера, установили правильные заголовки (и, возможно, отключили анализ типа контента, если мы на 101% уверены, что наши заголовки верны).

Существует одна ситуация, когда расширения файлов полезны: если конечный пользователь сохраняет контент с вашего сайта на свой локальный компьютер для дальнейшего использования. Теоретически «умный» браузер должен гарантировать, что сохраненный контент работает для локального типа компьютера; но на практике вы можете помочь всем, предоставляя контент с помощью стандартных расширений, таких как .jpg, .mp4, .css и т. д. По моему опыту, все браузеры правильно обрабатывают тип HTML. Вам не нужно самостоятельно добавлять расширение .htm / .html в HTML, браузер будет правильно обрабатывать этот конкретный тип контента.

Безопасность: Кто-то может поспорить, что безопасность скрывает скрытую платформу, которую вы используете (.php / .asp и т.д.). Это правда. На практике, я думаю, что любой хороший хакер узнает об этом сразу, поэтому я не думаю, что сокрытие этих расширений для обеспечения безопасности стоит потраченных усилий.

Особое внимание: если вы планируете использовать CDN в будущем, и ваш CDN имеет тип «push» (контент загружается в CDN заранее через fx через SFTP), то вы можете сохранить расширения файлов. Большинство сторонних систем обращаются к расширениям файлов, чтобы определить, к какому типу MIME относится контент.

Мой личный выбор стал:

• Когда мой веб-приложение динамически генерирует HTML, я не добавляю поддельное расширение .html для имитации структуры каталогов и файлов, которой на самом деле нет. Я нормализую URL-адреса и стандартизирую формат URL-адреса, используемый по причинам SEO. Лично я предпочитаю использовать косую черту на последнем листе URL-адреса, т.е. http://example.org/first/second/, но это дело вкуса.

• Когда мы на самом деле говорим о реальных файлах, которые загружаются на жесткий диск, то я сохраняю «нормальное» расширение файла для этого типа. Так что .css / .js / .exe / .mp4 и т. Д. Используются для такого рода контента.

Я провел небольшие неформальные эксперименты, и то, что я обнаружил, удивило меня, но в этом есть смысл.

С точки зрения доставки контента пользователю, а также соскоба с экрана, Тип контента управляет днем.

Тем не менее, наличие или отсутствие расширения, а также то, что это расширение, похоже, влияет на посещения поисковой системы.

Когда я вообще пропустил какое-либо расширение, у меня было относительно мало обращений - как если бы URL был местоположением или динамическим контентом и поэтому не стоил слишком много индексировать.

Когда я изменил те же ссылки, чтобы использовать расширение .xml, поскольку страницы были действительно сгенерированы XSLT (на стороне сервера), индексирование фактически упало еще больше - возможно, потому, что он думал, что это были просто данные или результат какого-то программного запроса ,

Когда я изменил те же ссылки, чтобы использовать .html, поисковые системы взбесились с сайта.

На данный момент мой сайт обрабатывает все три прозрачно, но когда он предоставляет ссылку, по которой можно кликнуть, я возвращаю .html версию URL.

Я хотел бы думать, что поисковые системы были немного умнее или менее предвзятыми, но это то, что я наблюдал, случалось с моими страницами.

Нет, вы не должны использовать расширение файла для обычных типов страниц, если вам это абсолютно не нужно по технической причине. Как это улучшает пользовательский опыт? Это больше, чтобы напечатать, но это не говорит им ничего полезного. Что они смогут сделать, зная, что ваш сайт PHP, ASP и т. Д.? URL проще, понятнее, удобнее в использовании и более запоминающимся без расширения файла.

Смотрите, если у URL нет имени файла, то он обычно считается каталогом.

Я не думаю, что я согласен. Как правило, URL является каталогом, только если он имеет косую черту. Без косой черты он считается файлом.

Вам следует только добавить расширение файла, если содержимое URI на самом деле является файлом. Но даже тогда вы можете оставить его, если есть только одно его представление (JPG, PDF, ...).

Если существует несколько представлений, HTTP-способ будет заключаться в согласовании формата через Acceptзаголовок. Но если вы хотите, чтобы ваши пользователи имели право голоса, вы, вероятно, захотите иметь расширение, чтобы они могли выбирать, какое представление они хотят (JPG, PNG, ...), запрашивая тот или иной URI.