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

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

  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 [ "?