Всё для сайтов

По выдержкам из RFC 1738 объяснены причины, согласно которым написание URL с оконечным слешем или без такого считается в обоих случаях правильным.

Полезные сведения

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

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

Споры по этому вопросу - как правильно писать 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> - строка запроса. <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 килорублей проскакивают, и так как ребята аутсорсят их партнёрам сеошникам, тут можно навести мосты партнёрства и получать хороший приработок.

Обсуждение
«Сергей, Dics-Net, Донецк | 6 мар 20:44
Ну хоть один показал доказательства. Сколько я блин нерва попортил, переделывая все ссылки чтобы закрывались слешем. Мой сеошник сказал надо так.
Ответить
«Анатолий, MTS Ukraine PrJSC, Киев | 6 мар 22:36
Чтож это у вас сеошник специалист такой, если ссылки правили вы. Этим как раз должен был заниматься он.
Ответить
«Андрей, ByFly BelTelecom, Минск | 25 апр 19:14
То что надо! Спасибо!!! Решил проблему!!!
Ответить
«Polina, FarLine.Net ISP, Симферополь | 2 июн 12:08
Спасибо, очень полезная статья!
Ответить
«Юрий, North-West Telecom, Великий Новгород | 17 сен 12:16
Согласен со всем!
У меня все ссылки отправляются в основной файл index.php на сервере который находиться соответственно в корне сайта, а он уже обрабатывает вложенность урл и формирует контент согласно вложенности. По сути то таких файлов и папок вовсе нет на сервере.

И таки да, проблема не в урл а в формировании контента. Если по адресу "mysite.ru/bla-bla-bla/" формируется такой же контент как и по адресу "mysite.ru/bla-bla-bla" могут быть проблемы и все же лучше от них подстраховаться выбрав какой то один из вариантов подправив файл htaccess.

По поводу склейки данных урл, специально сегодня прочитав вашу статью, думаю дай гляну в гугл веб мастер. И таки опять да... он все склеил. НО БУКВАЛЬНО ПОЛ ГОДА НАЗАД БЫЛИ ДУБЛИ! Так что разговор об этом имеет место быть.
Ответить
«Макс, UkrtelNet-ADSL, Киев | 11 янв 11:00
Спасибо. Всё понятно написано. Остался вопрос. Нужно ли продублировать заголовки редиректов в head страницы или достаточно htacces? Чтобы склейка прошла быстрее.
Ответить
«Matroskin, Legion-InterNet, Стаханов | 17 янв 16:17
Поисковый бот смотрит серверные заголовки. Head это из другой сказки. Поэтому только htaccess.
Ответить
«Евгений, LiS Cable TV ISP, Белгород-Днестровский | 12 фев 08:36
Вот это объяснение - со ссылкой на правила. А не пустые разглагольствования, как у многих. Спасибо.
Ответить
«Томсон Юрий, JSC Digital Network, Москва | 22 авг 14:04
Хорошая статья! Я тоже много раз задумывался, как правильно со слешем или без него. Решил для себя, что буду "закрывать" урлы чертой. Так, как мне кажется - эстетически лучше, поскольку люди, так или иначе, обращают на это внимание, пусть и не все.
Ответить
«Стас, Kyivstar-NET-15, Харьков | 6 сен 15:10
Все-таки склоняюсь к слешу в конце, это закрывает вопрос со ссылками без слеша.

Например ttt редиректим ttt/ - теперь и то и другое показывает на одну страницу, так сделано например в диджанго.
Ответить
«Щеклина Е, Ru-MOS-Smile, Москва | 2 окт 21:39
По-моему представлению, учитывать стоит не просто завершение урла прямым или обратным слешем, но и принять во внимание длину слов между сегментами урла, не короче и не длиннее какого-нибудь эталонного сегмента. А также учесть глубину урла, не более скольких-то сегментов. Все данные следует получить экспериментально, так как связаны с существующей урловой картой сайта.

То есть 2 страницы взять, сократить в одной урл и смотреть, куда перескочит в поиске по сравнению с нетронутой страницей. Только на основании такого измерения можно судить, что правильно что нет для конкретного поисковика.
Ответить
«Алексей, Uz-iPlus-Net, Ташкент | 3 окт 12:22
Спасибо за полезную информацию, здесь все по делу, и логически вполне правильно
Ответить
«Арман, Orbita-Plus-Net, Алматы, Казахстан | 4 янв 08:06
Я SEO-специалист и понимаю что за сыр-бор вокруг этих слэшей. И вот и итог, одним словом определитесь со структурой и иерархией вашего веб-ресурса изначально (на стадии разработки) в будущем это сэкономит вам много времени. Спс автору, очень познавательная статья.
Ответить
«Михаил, Bras DHCP-pool 2, Москва | 26 янв 23:51
Дмитрий спасибо! Уважаю Ваш писательский труд по просвещению дремучих в seo как я. Вы рассказываете легко, по важным моментам ссылаетесь на официальные источники, что в разы повышает доверие к Вашим словам.

Я нашел похожие факты на сайте законотворца seo, им считаю сайты Яндекс и Google. Факты подтверждающие Ваше мнение о логичности ссылки без слеша в конце чем с ним. Во как сделаны ссылки в карте сайта Яндекс блога yandex.ru/blog/sitemap.xml. Все без слеша в конце:
https://yandex.ru/blog/sitemap/narod-karta
https://yandex.ru/blog/sitemap/apidisk
https://yandex.ru/blog/sitemap/x-plain
https://yandex.ru/blog/sitemap/rasp
https://yandex.ru/blog/sitemap/yatechnologies
https://yandex.ru/blog/sitemap/ymapsapi
...

Как сделаны ссылки в карте сайта Google Developers developers.google.com/sitemap.xml. То же без слеша в конце:
https://developers.google.com/sitemap/+
https://developers.google.com/sitemap/+/domains
https://developers.google.com/sitemap/+/hangouts
https://developers.google.com/sitemap/+/mobile
https://developers.google.com/sitemap/+/mobile/android
https://developers.google.com/sitemap/+/mobile/ios
https://developers.google.com/sitemap/+/web
https://developers.google.com/sitemap/sm
https://developers.google.com/sitemap/abusive-experience-report
https://developers.google.com/sitemap/actions
...

По моему, если бы ссылки были нелогичными, творцы поисковых правил так бы не сделали в своих картах сайта.
Ответить
«Sim0xa, Volia-KH route, Харьков | 27 янв 13:07
Да используйте урлы какие у вас уже получились. Миша. Есть слеш в конце, ну пусть. Нет, тоже не страшно. Автор о том и говорил, обе формы урла правильные. В пример вам ссылка на сайт гугля, где карта имеет урлы с завершающим слешем. www.google.com/sitemap.xml А вобще думаю, автор написал этот обзор как инструкцию для защиты от сео школоты, клевавшей мозг менеджерам что надо переделать урлы страниц на слеш закрытые. Но это давняя история, такие школьники вымерли, так что тема урла неактуальна в сео.
Ответить
«Михаил, Bras DHCP-pool 2, Москва | 29 янв 10:20
Легко обозвать школотой. Подтвердите ссылкой кто клевал мозг. Я обойду того человека, а может обращусь к фирме.
Ответить
«Дмитрий, Almtrx-Net, Алчевск | 30 янв 15:50
Михаил, часть фактов циркулирует лишь внутри сеошной кухни, на них иначе не сослаться, кроме скриншота. Может быть Sim0xa видел где-то информацию в открытом доступе, пусть сообщит. Если же вас устроит подтверждение с помощью скриншота, я показываю страницу из недавнего аудита одной фирмы, которая входит в десятку известных seo-компаний Украины. Говорю это к тому, что обращение в фирму не гарантирует, что вам попадутся специалисты.

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

Скажем, у нас была страница с адресом hello/world/, допустим нам нравился этот URL. Но предположим, мы по какой-то дикой случайности наставили везде по интернету массу противоречивых дублирующихся ссылок: и слешевых, и безслешевых, и с многократным слешем, и с вариацией заглавных букв, и с кучей левых GET-параметров. Так вот если мы не прописали редиректы всех этих бестолковых и немыслимых случаев, то поисковик оставит в индексе один дубль с URL-ом на своё усмотрение:

hello/world/
hello/world
hello/WOrld
Hello/World?левый=параметр
///hello/WORLD
hello///WORLD////
... и так далее сколько хотите дублей, однако только один останется в индексе

Любой мало-мальски подготовленный seo-специалист эту тонкость знает. Но не в каждой seo-фирме работают специалисты. Поэтому иногда встречается вот такое:
Ответить
«Яна, Akado-Stolitsa, Москва | 31 янв 11:44
Профессиональное сообщество маркетологов, веб и seo мастеров, в которое входит и агентство интернет-маркетинга Netpeak, чей аудит Вы взялись подвергать сомнению, считает 301 редиректы важным элементом поискового продвижения. Вы значит отвергаете, что проверено многолетним опытом агентства?
Ответить
«Анни Пипа, Kuban-GSM, Краснодар | 18 мар 00:31
Разве Дмитрий отвергал редиректы? Он о том, что не все понимают, как непрописаный 301 действует на индекс.
Ответить
«Мазалёв Игорь, Ru-Avangard-DSL, Вологда | 6 мар 23:35
Проржал над пунктом "главная страница доступна при добавлении многократных /".
Ну разводят так разводят.
Ответить
«Анни Пипа, Kuban-GSM, Краснодар | 18 мар 00:20
Теперь молчим о прямом и обратном слэше. А то делки увеличат свой аудит на два.
Ответить
«SantosRhype, Group Tower Telecom, Волжский | 29 мар 19:25
Друзья, если вы решили накинуться на агентство Netpeak и диктовать как пишут seo аудит сайта, то приучитесь к мысли, что основной отдачей в таком деле будет черное seo по всем вашим вебресурсам.

Как зарвавшиеся не смыслящие в seo юнцы, вы гоните на сеошников, которые уже будет 10 лет в обед как владеют любыми методами продвижения в совершенстве. И не только белыми методами.

А то сначала спам полезет из щелей вашего сайта. Потом пойдут в ход санкции покруче. Это безошибочный метод получить пессимизацию сайта на ровном месте, как подарок оскорбившихся мастеров продвижения.
Ответить
«ъъъъъ, Rostelecom Nets, Москва | 31 мар 14:22
Ты скатился до страшилок. Тут слеш обсуждают, вали в свое агентсво.
Ответить
«Дмитрий, Almtrx-Net, Алчевск | 1 апр 14:02
Давайте не реагировать на подобные заявления. Имел бы SantosRhype достойные знания в SEO, не писал бы ахинею. Возможно, это работавший когда-то в фирме наёмный мальчик, которого выставили за дверь, отчего он кидается теперь на всех. Или просто начинающий фрилансер, движимый солидарностью от ложного чувства причастности к большому SEO. Там на фрилансе многим мнится нимб крутого чувака после впервые установленного своими руками стандартного SEO-модуля.
Ответить
«Юрий, ER-Telecom, Санкт-Петербург | 16 май 23:22
Добрый день. А я вот бадаюсь второй день - пытаюсь через Redirect301 склеить урлы, убрав слеш. С www сразу легко получилось. А редирект на "без слеша" ну никак никакой код не принимает. Но когда вставляю код, который должен убирать слеш, комментарии на сайте исчезают, но слеш не убирается. Вот такое вот СЕО. А Sape пишет, что обязательно должен быть редирект. Не знаю, что делать.
Ответить
«Junior, Lanet Network Ltd, Киев | 6 июн 19:59
Спасибо за статью!
1. На сайте мне не хватает информации о дате добавления самой статьи.
2. Также не хватает вывода "год" у каждого комментария к статье.
P.S. Небольшое расследование показало что изображение (скрин письма Платона) было создано: Wed, 04 Mar 2015 01:36:23 GMT.
Ответить

Другие обсуждения »

Теги: схемы url, url, url schemes

Хотите чтобы мы рассказали ещё о чём-то - предлагайте тему.

Предложить

Следите за нашими публикациями в социальных сетях и новостных каналах.