Чи варто використовувати розширення файлу чи ні?

Я завжди цікавився цим і ніколи не знайшов хорошого рішення.

Але це питання мені нагадало.

Якщо у мене на веб-сайті є 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 та більше займається естетикою та дотриманням веб-сторінок.

Використовуйте розширення .exe там, де є декілька представництв або де клієнтське програмне забезпечення є абсолютно дурним і відмовляється приймати тип вмісту самостійно (QuickTime, RealPlayer, Outlook тощо. Я дивлюся на вас):

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

• http://www.somesite.com/subdirectory/ - завжди слід підтримувати прорізні риски на будь-якій URL-адресі, але використовуючи теги Canonical META (не переспрямовувати, оскільки це зайве уповільнення), щоб вказати на правильну 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 (і Canonically посилатися на неї за допомогою тегів LINK на автоматично узгодженій версії) - використовуйте заголовки вмісту-розташування HTTP, щоб вказувати до версії для автоматичних переговорів - пам’ятайте, що ви також можете перейти на багатомовних (.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 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 тощо використовується для таких типів вмісту.

Я зробив невеликі неформальні експерименти, і те, що я виявив, мене здивувало, але має певний сенс.

З урахуванням того, що вміст доставляється користувачеві з точки зору, а також екранізація екрана, Content-Type визначає день.

Однак присутність або відсутність розширення, а також те, що таке розширення, схоже, коливаються відвідуваннями пошукової системи.

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

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

Коли я змінив ті самі посилання, що й використовувати .html, пошукові системи зачарували над сайтом.

Наразі мій сайт обробляє всі три прозоро, але коли він надає посилання, яке можна натискати, я повертаю .html версію URL-адреси.

Мені б хотілося подумати, що пошукові системи були трохи розумнішими або трохи менш упередженими, але це те, що я спостерігав, що трапляється зі своїми сторінками.

Ні, ви не повинні використовувати розширення файлу для звичайних типів сторінок, якщо це абсолютно не знадобиться з технічної причини. Як це покращує роботу користувачів? Це більше набирати, але це не говорить їм нічого корисного. Що вони зможуть зробити, знаючи, що ваш сайт - PHP, ASP тощо? URL-адреса простіша, чистіша, зручніша у користуванні та запам'ятовується без розширення файлу.

Дивіться, якщо URL-адреса не має імені файлу, то вона зазвичай вважається каталогом.

Я не думаю, що я згоден. Як правило, URL-адреса - це каталог лише у тому випадку, коли він має проділ. Без кінцевої косої риски це вважається файлом.

Ви повинні додати розширення файлу лише у тому випадку, якщо вміст за URI - це фактично файл. Але навіть тоді ви можете скинути його, якщо є лише одне його представлення (JPG, PDF, ...).

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