• Главная
    • /
  • Блог
    • /
  • УРЛ зі слешем або без - чому правильно саме так?

УРЛ зі слешем або без - чому правильно саме так?

  1. Загальний синтаксис URL
  2. ієрархічні схеми
  3. Загальний синтаксис мережевий схеми
  4. ієрархія
  5. Http
  6. формальна запис
  7. висновок
  8. До відома
  9. Що ще почитати по темі SEO

Спори з цього питання - як правильно писати URL, з слешем на кінці або без? - були і будуть. Аргументація зустрічається різноманітна, і часто суперечлива. А розплату за неправильний запис універсального локатора ресурсу (URL) уявляють двох видів. З боку пошукових систем - це нібито штрафні санкції за дублі сторінок. З точки зору продуктивності - нібито зайвий редирект на сторінку вірною записи, автоматично генерується сервером.

Однак, розбираючи технічні специфікації стандартів Інтернету, зокрема документ " RFC 1738 - Uniform Resource Locators (URL) ", доводиться визнати, що обидва варіанти запису адреси веб-ресурсу формально правильні, і санкція за використання того чи іншого варіанту - не більше ніж бзік пошукової системи або байки псевдо-SEO-шників.

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

Завантажувати вас багатосторінковим перекладом згаданого RFC не стану, так як, по-перше, метою питання були слеші на кінці URL, і по-друге, публікація адресована простим користувачам движків, в тому числі і Impera CMS , Яким вся деталізація не цікава, вони чекають коротких роз'яснень і доказів по суті. Відповідно, я буду цитувати витяги з цього документа в якості доказової бази і пояснювати. Кому і це не цікаво, може відразу дивитися висновок в кінці статті.

Загальний синтаксис URL

Насамперед приверну увагу до витягу з параграфа 2. General URL Syntax (Загальний синтаксис URL). У кожному разі буду приводити фрагмент тексту мовою оригіналу і слідом переклад на російську мову.

URLs are used to `locate 'resources, by providing an abstract identification of the resource location. URLи використовуються для 'знаходження' ресурсів, надаючи абстрактне позначення місця розташування ресурсу.

Тобто сам URL - це чиста абстракція. Що він може здатися нам зовні схожим на ім'я файлу або папки, зовсім не означає фізичну вказівку на саме такий-то файл, а не який-небудь інший в файловому просторі сервера. Нижче в документі про це буде заявлено прямо.

Замітка Взагалі щодо http-посилань в принципі невірно говорити, що наприклад

  • http://domain.com/path/subpath/filename.txt - нібито вказує на файл
  • http://domain.com/path/subpath/ - нібито вказує на папку
  • http://domain.com/path - нібито невірно вказує на папку

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

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

ієрархічні схеми

Далі витяг з параграфа 2.3 Hierarchical schemes and relative links (Ієрархічні схеми і відносні посилання).

Some URL schemes (such as the ftp, http, and file schemes) contain names that can be considered hierarchical; the components of the hierarchy are separated by "/". Деякі схеми URL (такі як ftp, http і file) містять імена, які можна вважати ієрархічними; елементи ієрархії розділені символом "/".

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

Загальний синтаксис мережевий схеми

Далі витяг з параграфа 3.1. Common Internet Scheme Syntax (Загальний синтаксис мережевий схеми).

// <user>: <password> @ <host>: <port> / <url-path> Some or all of the parts "<user>: <password> @", ": <password>", ": < port> ", and" / <url-path> "may be excluded. Деякі або всі частини "<user>: <password> @", ": <password>", ": <port>" і "/ <url-path>" можна виключати.

Замітка Це, до речі, відповідь на питання, похідний від розглянутого нами. Нерідко і з такого питання сперечаються: як правильно давати посилання на домен (хост) - без слеша в кінці або зі слешем?

Як правильно http://domain.com/ або http://domain.com?

І так і так правильно. Просто перший слеш після імені хоста призначений для відділення імені шляху від імені хоста. Той же параграф документа повідомляє про це так:

url-path The rest of the locator consists of data specific to the scheme, and is known as the "url-path". It supplies the details of how the specified resource can be accessed. Note that the "/" between the host (or port) and the url-path is NOT part of the url-path. Інша частина локатора складається з даних, характерних для схеми, і відома як "url-path" (шлях URL). Вона повідомляє подробиці, як можна отримати доступ до зазначеного ресурсу. Зверніть увагу, що символ "/" між хостом (або портом) та шляхом URL - це не частина url-path.

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

Продовжимо ще однієї витягом з того ж параграфа.

The url-path syntax depends on the scheme being used, as does the manner in which it is interpreted. Синтаксис url-path залежить від використовуваної схеми, як і спосіб, яким він інтерпретується.

Це зайве підтвердження, що у кожної схеми локатора своє поняття "ієрархії" і спосіб її інтерпретації.

ієрархія

Далі витяг з параграфа 3.2.4 Hierarchy (Ієрархія).

For some file systems, the "/" used to denote the hierarchical structure of the URL corresponds to the delimiter used to construct a file name hierarchy, and thus, the filename will look similar to the URL path. This does NOT mean that the URL is a Unix filename. Символ "/" використаний для позначення ієрархічної структури URL відповідно разделителю, використовуваному в конструюванні ієрархії файлових імен, і таким чином в деяких файлових системах ім'я файлу виглядає подібним шляху URL. Але це не означає, що URL - це Unix-подібне ім'я файлу.

Незважаючи на те, що цей параграф відноситься до схеми ftp, проте його затвердження распространіми і на інші схеми (http, gopher, prospero і так далі). Лише в схемі file символ слеша логічно позначає те ж, що і в іменах файлів, наприклад file: //server_or_device/path/subpath/filename.txt.

Http

Далі витяг з параграфа 3.3. HTTP .

An HTTP URL takes the form: http: // <host>: <port> / <path>? <Searchpart> where <host> and <port> are as described in Section 3.1. If: <port> is omitted, the port defaults to 80. No user name or password is allowed. <Path> is an HTTP selector, and <searchpart> is a query string. The <path> is optional, as is the <searchpart> and its preceding "?". If neither <path> nor <searchpart> is present, the "/" may also be omitted. Within the <path> and <searchpart> components, "/", ";", "?" are reserved. The "/" character may be used within HTTP to designate a hierarchical structure. URL схеми http приймає форму: http: // <host>: <port> / <path>? <Searchpart> де <host> і <port> такі ж як описані в параграфі 3.1. Якщо: <port> опущений, порт за замовчуванням вважається рівним 80. Ім'я користувача або пароль неприпустимі. <Path> - це селектор HTTP, і <searchpart> - рядок запиту. &lt;Path> є опціональним, як і <searchpart> разом з попереднім йому символом "?". Якщо ні <path>, ні <searchpart> не присутні, символ "/" може також бути опущений. В елементах <path> і <searchpart> символи "/", ";", "?" є зарезервованими. Символ "/" може використовуватися в HTTP, щоб визначати ієрархічну структуру.

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

формальна запис

І нарешті витяг з параграфа 5. BNF for specific URL schemes (Формальна запис для конкретних схем URL).

Тут в квадратних дужках вказані опціональні частини. Зірочка перед дужкою позначає 0 або більше повторів такого фрагмента, як вказано в дужках. Вертикальну риску слід розуміти як АБО.

hostport = host [ ":" port] ... ... httpurl = "http: //" hostport [ "/" hpath [ "?" search]] hpath = hsegment * [ "/" hsegment] hsegment = * [uchar | ";" | ":" | "@" | "&" | "="] Search = * [uchar | ";" | ":" | "@" | "&" | "="] ... ... lowalpha = "a" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" hialpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" alpha = lowalpha | hialpha digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" safe = "$" | "-" | "_" | "." | "+" Extra = "!" | "*" | " '" | "(" | ")" | "," Hex = digit | "A" | "B" | "C" | "D" | "E" | "F" | "A" | "B" | "C" | "D" | "E" | "F" escape = "%" hex hex unreserved = alpha | digit | safe | extra uchar = unreserved | escape

Зверніть увагу, як точно за правилами формується елемент hpath - шлях посилання. Елементи hsegment шляху - сегменти - поділяються слешем. Немов натякаючи на важливу ідею, що слеш ділить шлях на ієрархічні частини і завжди знаходиться всередині. В принципі не виключається, що останній елемент hsegment може бути символом нового рядка (це випливає з його визначення), і тоді на кінці URL мимоволі з'являється закриває слеш.

висновок

Розподіл шляху на сегменти за допомогою символу слеша має на увазі наявність непустих імен цих сегментів. Відповідно, посилання зі слешем на кінці бачиться нелогічною (хоча і не заборонена) в тому сенсі, що вона начебто вказує на якийсь останній сегмент шляху, але при тому ніяк не називає цей сегмент. Точно так як нелогічна (але теж не заборонена) посилання http://domain.com/level1////levelX, що не називає проміжні сегменти шляху, якщо шлях розглядати не як набір параметрів, а як ієрархічну структуру.

Просторічним мовою змістове наповнення двох посилань можна пояснити так:

  • http://domain.com/level1/level2 - адресує в дефолтну початкову точку другого рівня ієрархії
  • http://domain.com/level1/level2/ - адресує в невизначену точку всередині другого рівня ієрархії, тобто як би на сервер покладають завдання, що "ми звертаємося до другого рівня ієрархії, а ти сам визнач, яку точку вважаєш в цьому рівні дефолтной початкової ".

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

З усього сказаного вище випливає, що аналогічно тому, як посилання

  • http://domain.com
  • http://domain.com/

адресують відвідувача в корінь сайту, так і наприклад посилання

  • http://domain.com/level1/level2
  • http://domain.com/level1/level2/

адресують відвідувача до другого рівня ієрархії ресурсу. А то що якийсь сервер може інтерпретувати слеш на кінці по-своєму і почати внутрішньо редирект на дефолтну початкову точку рівня - скажімо на файл index.html, це вже окреме питання конкретної конфігурації. Точно так як і в реалізації системи людино-зрозумілих URL всі записи редиректів за допомогою серверного модуля mod_rewrite визначають своє (властиве конкретному движку) поняття ієрархічної будови URL, в якому елементи шляху можуть прирівнюватися до параметрів запиту і зовсім не мати спільного з файлової структурою сайту ( класичний приклад: http://domain.com/ru/path, елемент ru - це параметр поточного мови, а не папка на сайті).

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

До відома

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

Ось приклад реалізації такого редиректу за допомогою кореневого файлу .htaccess:

# Якщо вхідний url закінчується слеш (їм, ами), # задаємо 301-й редирект на сторінку без слеша RewriteCond% {REQUEST_URI} ^ /. + / $ RewriteRule ^ (. *?) / + $ Http: //% {HTTP_HOST } / $ 1 [R = 301, L, QSA]

Гуглу (знову ж за відомостями , Що не підтвердженим експериментом) ці редіректи не важливі, так як він нібито вміє склеювати такі адреси правильно і без редиректів.

Пам'ятайте Є чимало людей, які вважають себе SEO-фахівцями. Але не кожен з них таким є. Більш того, темою SEO часто спекулюють без належних знань і підстав, просто в розрахунку на те, що і ви необізнані в цій області, тому легко повірите в будь-яку "локшину". Коли вам говорять, що якась ваша сторінка "вилетіла з індексу", скористайтеся дуже гарною рекомендацією Яндекса: Дізнаватися про помилки індексування , Якщо такі виникають, можна в сервісі Яндекс.Вебмастер. У цьому сервісі завжди можна побачити список ваших сторінок, знаходяться в пошуку і список сторінок, з якоїсь причини виключених з пошуку . Схожий сервіс є і у Гугла. Довіряйте цим знанням, а не думку псевдо-фахівців, які десь щось краєм вуха чули, і на тій підставі рекомендують вам робити так, як їм здається єдино правильним.

Що ще почитати по темі SEO

Ось Дуже цікава публікація Маловідомі факти SEO , Що вийшла в квітні 2017 року. Там представлено велике дослідження з безліччю скріншотів, яке починалося з метою перевірити справедливість декількох популярних суджень в області пошукового просування і на зрозумілих прикладах донести результати до звичайного власника сайту. Те ж дослідження попутно демонструє молодому читачеві ряд очевидних, звичайних, і швидше навіть непримітних, але все ж дивовижних особливостей органічної видачі в пошуках Google і Yandex.

Ось Хоча наступна посилання майже не стосується SEO, все ж стане привабливою для seo-майстрів, які перебувають зараз в пошуку додаткових замовлень. Під посиланням розміщено комерційну пропозицію, хлопці знайшли цікавий спосіб використання сайту. Приватному бізнесу пропонують створення рекламного щита онлайн на основі якоїсь спеціальної теми, під управлінням якої сайт, а точніше його перший екран виглядає немов би банерна розтяжка на білбордах зовнішньої реклами. На смартфоні повернув екран, розтяжка стала вертикальної і займає всю площу екрана, повернув назад, стала горизонтальною і знову на весь екран. А під першим екраном є текстовий придаток, куди користувачі зазвичай не Скрол, але пошуковик добре бачить цей текст. Так ось найспритніші буратіни регіонального бізнесу купують собі ці недорогі онлайн білборди як вигідної альтернативи контекстній рекламі і Медійній мережі Яндекса і Гугла. А щоб по-максимуму тусуватися в місцевому пошуковому індексі, на просування свого щита готові стьобнути грошей відразу на купу seo-текстів, що пахне некислим сумою. Судячи з чуток, замовлення на 30 кілорублей проскакують, і так як хлопці Аутсорс їх партнерам сеошників, тут можна навести мости партнерства і отримувати хороший приробіток.

Нерідко і з такого питання сперечаються: як правильно давати посилання на домен (хост) - без слеша в кінці або зі слешем?
Com?
An HTTP URL takes the form: http: // <host>: <port> / <path>?
The <path> is optional, as is the <searchpart> and its preceding "?
Within the <path> and <searchpart> components, "/", ";", "?
URL схеми http приймає форму: http: // <host>: <port> / <path>?
Lt;Path> є опціональним, як і <searchpart> разом з попереднім йому символом "?
В елементах <path> і <searchpart> символи "/", ";", "?
Httpurl = "http: //" hostport [ "/" hpath [ "?