Коли я повинен використовувати в своїй URL-адресі косу рису?

283

Коли слід використовувати URL-адресу в нижній частині? Наприклад - Повинен чи мій URL виглядати /about-us/або як /about-us?

Я цілком знаю проблеми, пов'язані з SEO - дублювання вмісту та канонічну річ; Я намагаюся розібратися, яку саме я повинен використовувати в контексті правильного розміщення сторінок .

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

Чи є правильний спосіб знати, який використовувати?

— Денис
джерело

Похила коса риса, але, на мою думку, це в основному естетика. Дивитися і відчувати.

— Ерік Герліц

3

Те саме питання щодо веб-майстрів Pro: чи має значення це, якщо ваш шлях до URL-адреси закінчується кінцевою косою рисою чи ні?

— Стівен Остерміллер

4

Це питання ставиться як одна з переваг , і, таким чином, здавалося б, поза темою, як в першу чергу на основі думки . Однак, як показує моя відповідь , насправді поставити це питання як питання переваги є помилкою: це проблема XY, і основне "реальне" питання має точну технічну відповідь, і, отже, не ґрунтується насамперед на думці .

— Raedwald

Питання про те, які типи URL-адрес подобаються Google, не пов’язані з програмуванням (як згадується у тегах wiki ) та є поза темою для Stackoverflow.

— Квентін

Я вніс кілька змін до вашого питання, будь ласка, перевірте їх, коли у вас є можливість. Дякую :)

— Тим

131

На мою особисту думку, косою косою рискою є неправомірне використання.

Фактично, формат URL надходив з того самого формату файлів і папок UNIX, пізніше, в системах DOS і, нарешті, адаптований для Інтернету.

Типовою URL-адресою цієї книги в подібній операційній системі Unix буде шлях до файлу, такий як файл: ///home/username/RomeoAndJuliet.pdf, що ідентифікує електронну книгу, збережену у файлі на локальному жорсткому диску.

Джерело: Вікіпедія: Уніфікований ідентифікатор ресурсу

Ще одне хороше джерело для читання: Вікіпедія: схема URI

Відповідно до RFC 1738, який визначав URL-адреси в 1994 році, коли ресурси містять посилання на інші ресурси, вони можуть використовувати відносні посилання для визначення місця розташування другого ресурсу, як якщо б це було сказано, "там же, що і цей, за винятком наступного відносного шлях ». Він продовжував говорити , що такі відносні URL - адреса залежить від вихідного URL , що містить ієрархічну структуру , з якої базуються відносна посилання, і що в FTP, HTTP і файлові схеми URL є прикладами деяких , які можна вважати ієрархічними, з компоненти ієрархії, розділені знаком "/".

Джерело: Уніфікований локатор ресурсів Вікіпедії (URL)

Також:

Це питання ми часто чуємо. Вперед до відповідей! Історично для URL-адрес із косою косою рисою зазвичай вказується каталог, а для тих, хто не має косою косою рисою, позначають файл:

http://example.com/foo/ (з косою косою рисою, як правило, каталог)

http://example.com/foo (без кінцевої косої риски, як правило, файл)

Джерело: Центральний блог Google WebMaster - перерізати або не нарізати

Нарешті:

Похила кінець у кінці URL-адреси робить адресу "красивою".
URL-адреса без косою рисою в кінці та без розширення виглядає дещо "дивно".
Ви ніколи не будете називати файл CSS (наприклад) http://www.sample.com/stylesheet/ б ви?

Але я є прихильником передового досвіду в Інтернеті незалежно від середовища. Це може бути непростим і незрозумілим, як ви сказали про URL-адресу, яка не містить ext.

— Дементичний
джерело

1

Це дивно, ви не можете назвати файл "Стиль таблиць /" - і слэш або без косої риси - це зовсім інші ресурси на сервері, незалежно від того, як виглядає URL

— nico gawenda

10

@nicogawenda, .htaccess може робити всілякі магії;) ваш CSS може насправді бути файлом php!

— rmorse

4

Веб-сервери часто налаштовуються за замовчуванням для обслуговування index.html(або аналогічного файлу), коли доступ до каталогу /foo/є /foo/index.htmlбез зайвого безладу. Також у минулому браузери додавали /б доменне ім'я, але вони (Firefox, Chrome, Opera) з тих пір змінювались, щоб опустити цей /доступ під час доступу до домашньої сторінки.

— 0b10011

4

Я згоден з @bfrohs. Безумовно, що за замовчуванням сторінки для каталогів суперечать цьому принципу. Якщо ми хочемо застосувати 'trailing slash = directory', то, безумовно, всі URL-адреси, які вказують на каталог, повинні або повернути список каталогу, або 403 заборонену відповідь http.

— Марвін

11

Я не впевнений, чи точки 1 та 2 у розділі "Нарешті" все-таки точні. За роки, відколи це було написано, смаки змінювалися. Я детально цього не вивчав, але здається, що на новіших веб-сайтах частіше і «красивіше» опускати косу рису.

— швидкісний літак

172

Це не питання переваги. /baseі /base/мають різну семантику. У багатьох випадках різниця є несуттєвою. Але це важливо, коли є відносні URL-адреси.

childвідносно /base/є /base/child.
childвідносно /baseє (можливо, дивно) /child.

— Raedwald
джерело

5

Корисна стаття, яка в цьому глибоко заглиблюється

— Гефест

3

Так, я думаю, що це разом із SEO є найважливішим у цьому питанні.

— користувач2875289

Просто виникла ця проблема під час використання .Net's Uri.MakeRelativeUri. Результати відображають саме те, що ви сказали. Я вирішив цю проблему, додавши нижню косу рису до своєї бази Uri.

— julealgon

61

Мене завжди дивує широке використання прорізних косої риски в URL-адресах без каталогу (WordPress серед інших). Це дійсно не повинно бути або дебатом, тому що ставити косу рису після ресурсу семантично неправильно. Мережа була розроблена для доставки адресних ресурсів, а ці адреси - URL-адреси - були розроблені для імітації ієрархії файлової системи * nix-стилю. У цьому контексті:

Штрихи завжди позначають каталоги, а ніколи файли.
Файли можуть бути названі будь-якими (з розширеннями або без них), але не можуть містити або закінчуватися косою рисою.

Використовуючи ці вказівки, неправильно ставити косу рису після ресурсу без каталогу.

— Ярін
джерело

50

"косої риски після каталогів, а не після ресурсів": URL-адреси не посилаються на два типи речей, "ресурси" та "каталоги"; вони посилаються на один вид речі: ресурси. Підказка знаходиться в R URL.

— Raedwald

31

І все у файловій системі * nix - це файл, але каталоги все ще існують. Який твій погляд?

— Ярін

6

Незалежно від того, чи користується він файлом або каталогом всередині, користувач бачить лише веб-сторінку. І example.com/about насправді може читати з example.com/about/index.html .

— musiphil

1

@DavidRR: Ти маєш рацію. І браузер потрібен редирект , оскільки дозвіл імен повинно статися з внутрішньої directory( в іншому випадку, image.pngв http://hostname/directoryвказуватиме http://hostname/image.png). Я просто говорив, що різниця між файлом і каталогом може бути не дуже важливою з точки зору користувача.

— musiphil

2

Я згоден з вашим результатом, але я не впевнений, що ми повинні розробляти нашу URL-систему для емуляції файлових систем у стилі * nix. Це, можливо, спочатку слугувало цілі, але тепер набагато менше.

— швидкісний літак

27

Це насправді не питання естетики, а справді технічна різниця. Думка про нього в каталозі абсолютно правильна і в значній мірі пояснює все. Давайте розробимо:

Ви знову в кам'яному віці або обслуговуєте лише статичні сторінки

У вас на веб-сервері встановлена фіксована структура каталогів і лише статичні файли, такі як зображення, html і так далі - жодних скриптів на стороні сервера чи будь-чого іншого.

Браузер запитує /index.htm, він існує і доставляється клієнту. Пізніше у вас є багато - скажімо, - переглянуті фільми DVD та HTML-сторінка для кожного з них у /dvd/каталозі. Зараз хтось просить, /dvd/adams_apples.htmі його доставляють, бо він є.

В якийсь день хтось просто запитує /dvd/- що це каталог, і сервер намагається зрозуміти, що доставити. Крім того , обмеження доступу і так далі є дві можливості: показати користувачеві вміст каталогу (я впевнений , ви вже бачили це де - то) або показати файл за умовчанням (в Apache це: DirectoryIndex: sets the file that Apache will serve if a directory is requested.)

Поки що добре, це очікуваний випадок. Це вже показує різницю в керованості, тому давайте вступимо в нього:

О 5:34 ви помилилися при завантаженні файлів

(Що, до речі, цілком зрозуміло.) Отже, ви зробили щось зовсім не так і замість того, щоб /dvd/the_big_lebowski.htmви завантажили цей файл як dvd(без розширення) в /.

Хтось /dvd/зробив закладки у вашому списку каталогів (звичайно, ви не хотіли створювати та постійно оновлювати цей чудовий index.htm) і відвідуєте ваш веб-сайт. Вміст каталогу доставляється - все добре.

Хтось чув про ваш список і набирає текст /dvd. А тепер він накручений. Замість вашого каталогу DVD у списку сервер знаходить файл з таким ім'ям і доставляє ваш файл Big Lebowski.

Отже, ви видаляєте цей файл і повідомте хлопцеві перезавантажити сторінку. Ваш сервер шукає /dvdфайл, але його немає. Тоді більшість серверів помітять, що існує каталог з таким ім'ям, і скажуть клієнту, що те, що він шукав, є десь в іншому місці. Відповідь, швидше за все, буде такою:

Status Code:301 Moved Permanently з Location: http://[...]/dvd/

Отже, повністю ігноруючи те, що ви думаєте про каталоги чи файли, сервер може лише обробляти такі речі і - якщо не сказано інакше - вирішує для вас значення "перерізати чи ні".

Нарешті, отримавши цю відповідь, клієнт завантажується /dvd/і все в порядку.

Це добре? Немає.

"Просто чудово" недостатньо добре для вас

У вас є динамічна сторінка, де все передається /index.phpта обробляється. До цього все працювало досить добре, але вся ця справа починає повільніше, і ти розслідуєш.

Незабаром ви помітите, що /dvd/listробить саме те саме: Перенаправлення на /dvd/list/який потім внутрішньо перекладається на index.php?controller=dvd&action=list. Ще один запит - але ще гірше! customer/loginпереадресації, до customer/login/яких у свою чергу переспрямовується до HTTPS URL-адреси customer/login/. У вас з’являється безліч непотрібних переспрямувань HTTP (= додаткові запити), які роблять роботу користувачів більш повільною.

Швидше за все, тут також є індекс каталогів за замовчуванням: index.php?controller=dvdбез actionпросто внутрішніх завантажень index.php?controller=dvd&action=list.

Підсумок:

Якщо це закінчується, /він ніколи не може бути файлом. Відгадування сервера немає.
Нахил або коса коса риса - це зовсім різні значення. Існує технічна / ресурсна різниця між "косою рисою чи без косої риси", і ви повинні знати про це та використовувати її відповідно. Просто тому, що сервер, швидше за все, завантажує /dvd/index.htm- або завантажує правильний матеріал сценарію - коли ви говорите /dvd: це робиться, але не тому, що ви зробили правильний запит. Що було б /dvd/.
Пропускання косої риски, навіть якщо ви дійсно маєте на увазі, що нарізана версія дає додатковий штраф за запит HTTP. Це завжди погано (думайте про затримку мобільних пристроїв) і має більшу вагу, ніж "гарненька URL-адреса" - тим більше, що сканери не такі німі, як вірять SEO або хочуть, щоб ви вірили;)

— nico gawenda
джерело

2

Отже, підсумовуючи, ви всі для додавання косої риски в кінці? :)

— Денис

2

Я все використовую, коли ви це маєте на увазі;) Наприклад, якщо говорити про контролери та дії, це було б так: контролери повинні закінчуватися косою рисою. Коли ви посилаєтесь на файл або дію, пропустіть косу

— рису

Тримайся, чому б ти пропустив косу рису на дію? Згідно з вашим прикладом, чи не це призведе до додаткового перенаправленого запиту? Я маю на увазі, імовірно, ваш сервер досить розумний, щоб розпізнати дії контролера і фактично не буде перенаправляти на пошук файлів чи каталогів у такому випадку, але все одно це суперечить вашому прикладу, чи не так?

— Адам Гудвін

7

Я не розумію вашого прикладу. Яка файлова система дозволяє директорії та іншому регулярному файлу з тим же ім'ям ( dvd)?

— musiphil

19

Коли ви зробите свій URL /about-us/(з лідируючим слешем), це легко почати з одним файлом , index.htmlа пізніше розширити його і додати додаткові файли (наприклад our-CEO-john-doe.jpg) , або навіть побудувати ієрархію під нею (наприклад /about-us/company/, /about-us/products/і т.д.) по мірі необхідності, без зміна опублікованої URL-адреси . Це дає велику гнучкість.

— мусіфіл
джерело

9

Вибачте, що не зрозумів. якщо я починаю з /about-usабо /about-us/мені ще потрібно змінити опубліковану URL-адресу в обох випадках, якщо я розширював каталог. новий файл буде /about-us/new-file.htmlв обох випадках !! чого я тут пропускаю?

— Бухгалтер з

2

@Accountant Я думаю, що ОП може думати, що якщо ви публікуєте "/ about-us" без останньої косої риски, згодом ви не зможете додавати субресурси, використовуючи відносні шляхи. Якщо у вас немає останньої косої риски, браузер вважатиме, що посилання на "ceo.jpg" на сторінці about буде жити в корені вашого домену та запитає example.com/ceo.jpg. З косою рисою браузер запитає example.com/about-us/ceo.jpg, і ви можете статично маршрутизувати ціле дерево папок для вашого веб-сайту під час розширення.

— світанок

1

FYI - Я не вірю, що будь-що з перерахованого вище є правдою. Чому не може бути /about-usі /about-us/company? Що стосується обслуговування файлів, і Apache, і IIS можуть впоратися з цим просто чудово, тому я не згоден.

— sean2078

1

@ sean2078 Так, але якщо від /about-usвас хочеться посилання /about-us/company, вам доведеться використовувати href="https://stackoverflow.com/about-us/company"або href="./company"(не впевнений у цьому). Якщо ви перебуваєте на /about-us/, хоча, це просто: href="company".

— Adowrath

11

Інші відповіді тут здаються на користь пропускання останньої косої риски. Є один випадок, коли косою косою рискою допоможе оптимізація пошукових систем (SEO). Саме тому у вашому документі є те, що, схоже, є розширенням файлу, яке не є .html. Це стає проблемою для сайтів, які рейтингові веб-сайти. Вони можуть вибрати між цими двома URL-адресами:

http://mysite.example.com/rated.example.com
http://mysite.example.com/rated.example.com/

У такому випадку я вибрав би ту, що є косою косою рисою . Це тому, що .comрозширення є розширенням для виконавчих командних файлів Windows. Пошукові системи та вірусні перевірки часто не люблять URL-адреси, які, можливо, містять зловмисне програмне забезпечення, розповсюджене за допомогою таких механізмів. Начертання косої риси, здається, пом’якшує будь-які проблеми, дозволяючи цій сторінці займати рейтинг у пошукових системах та отримувати вірусні перевірки.

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

— Стівен Остерміллер
джерело

Жодна реальна пошукова система не така дурна. Ця відповідь є чистою спекуляцією.

— Навін

1

Я фактично бачив цю проблему в Google. Це було кілька років тому, тож я не впевнений, чи так би було й сьогодні.

— Стівен Остерміллер

Так, це гарний момент даних. Хоча ми досі не знаємо, чи це було викликано чимось іншим.

— Навін

10

Хто каже, що ім'я файлу потребує розширення ?? погляньте на * nix-машину колись ...
Я згоден з вашим другом, ніякої зворотної косої риски.

— Аарон Гейдж
джерело

3

З точки зору SEO, вибір того, включати чи ні додати кінцеву косу риску в кінці URL-адреси, не має значення. У ці дні звичайно бачити приклади обох в Інтернеті. Веб-сайт жодним чином не буде покараний, і цей вибір не вплине на рейтинг пошукової системи вашого веб-сайту чи інші SEO-міркування.

Просто виберіть потрібну конвенцію про іменування URL-адрес та додайте до <head>розділу кожної веб-сторінки канонічний метатег .

Пошукові системи можуть вважати одну веб-сторінку двома окремими повторюваними URL-адресами, коли вони стикаються з нею і без косої риски, тобто example.com/about-us/і example.com/about-us.

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

Канонічний тег виглядає наступним чином : <link rel="canonical" href="https://example.com/about-us" />. Використання канонічного метатега гарантує, що пошукові системи підраховують кожну вашу URL-адресу один раз, незалежно від того, включають інші веб-сайти проміжну косу рису, коли вони посилаються на ваш сайт.

— бунт
джерело