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

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

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

Когда у меня есть 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 и больше занимается эстетикой и соблюдением веб-сайтов.

25 голосов | спросил Talvi Watia 17 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 17 Sep 2010 12:28:09 +0400 2010, 12:28:09

7 ответов


18

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

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

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

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

  • http://www.somesite.com/subdirectory/index.html - если вы обслуживаете .atom, .xml или аналогичную версию, тогда имеет смысл также соблюдать .html (и канонически ссылайтесь на нее с помощью тегов LINK в версии с автосогласованием) - используйте заголовки HTTP Content-Location, чтобы указать на версию автосогласования, хотя помните, что вы также можете использовать многоязычные (.en, .es , etc ...) или multi-charset (.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 - это постоянно меняющееся искусство, и если это работает для вас, тогда большой

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

ответил Metalshark 17 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 17 Sep 2010 14:45:03 +0400 2010, 14:45:03
13

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

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

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

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

ответил Tim Fountain 17 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 17 Sep 2010 13:33:08 +0400 2010, 13:33:08
12

Прохладные URI не меняются . (Перейдите в раздел «Что мне делать? Проектирование URI»)

ответил John Conde 17 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 17 Sep 2010 16:00:40 +0400 2010, 16:00:40
7
  

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

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

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

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

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

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

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

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

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

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

ответил Jesper Mortensen 17 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 17 Sep 2010 17:39:05 +0400 2010, 17:39:05
2

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

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

Однако наличие или отсутствие расширения, а также того, что такое расширение, похоже, влияют на посещения поисковых систем.

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

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

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

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

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

ответил Walt Stoneburner 17 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 17 Sep 2010 21:51:25 +0400 2010, 21:51:25
2

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

  

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

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

ответил Virtuosi Media 17 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 17 Sep 2010 23:07:02 +0400 2010, 23:07:02
0

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

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

ответил DanMan 23 FebruaryEurope/MoscowbSat, 23 Feb 2013 23:48:56 +0400000000pmSat, 23 Feb 2013 23:48:56 +040013 2013, 23:48:56

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132