Что означает слэш в адресе сайта
По выдержкам из RFC 1738 объяснены причины, согласно которым написание URL с оконечным слешем или без такого считается в обоих случаях правильным.
С позиции лаконичности, более правильным представляется вариант без слеша на конце вне зависимости от того, адресует ли ваша ссылка «файл» на сервере или «папку», косвенное доказательство чему будет продемонстрировано ниже. Но и нет ни одного утверждения в документе, что иной вариант неверный или ссылается совсем на другой ресурс.
Загружать вас многостраничным переводом упомянутого RFC не стану, так как, во-первых, целью вопроса были слеши на конце URL, и во-вторых, публикация адресована простым пользователям движков, в том числе и Impera CMS, которым вся детализация не интересна, они ждут кратких разъяснений и доказательств по существу. Соответственно, я буду цитировать выдержки из сего документа в качестве доказательной базы и пояснять. Кому и это не интересно, может сразу смотреть вывод в конце статьи.
Общий синтаксис URL
Первым делом привлеку внимание к выдержке из параграфа 2. General URL Syntax (общий синтаксис URL). В каждом случае буду приводить фрагмент текста на языке оригинала и следом перевод на русский язык.
Заметка Вообще в отношении http-ссылок в принципе неверно говорить, что например
Мы просто привыкли так говорить, потому что удобно ассоциировать ссылки с файлами на сайте. В действительности все эти ссылки указывают на некие ресурсы, никоим образом не обозначая тип ресурса. Что же скрывается за каждым ресурсом, то есть какой именно реальный файл или папка и какой тип контента будет отдан по такой ссылке, то уже определено конфигурацией сервера.
Важно уяснить, что в ссылках нет такого понятия как «файл», «папка», «подпапка», «текст», «картинка», «html», «скрипт», «таблица стилей» и так далее. Никакой слеш на конце или его отсутствие не значит ровным счётом ничего до тех пор, пока ссылка не пройдёт трансформацию внутри сервера, и уже он сам решит, куда же на самом деле указывает ссылка и какой контент какого типа скрывается за ней. Только это решение относится к внутренней архитектуре сервера.
Иерархические схемы
Далее выдержка из параграфа 2.3 Hierarchical schemes and relative links (иерархические схемы и относительные ссылки).
То есть утверждается, что в отдельных схемах адресов содержимое локатора ресурса не воспрещено подразумевать иерархическим, причём пока не оговаривалось, что иерархия эквивалентна какой-либо форме, скажем файловой.
Общий синтаксис сетевой схемы
Далее выдержка из параграфа 3.1. Common Internet Scheme Syntax (общий синтаксис сетевой схемы).
И так и так правильно. Просто первый слеш после имени хоста предназначен для отделения имени пути от имени хоста. Тот же параграф документа сообщает об этом так:
Ни словом не обязали вас ставить этот замыкающий символ или не ставить, когда url-path равен пустой строке (как сказали бы многие из нас, когда URL ссылается в корень сайта). Никто не имеет права применить к вам штрафные санкции «за два дубля главной страницы», ибо согласно спецификации, в обоих случаях вы ссылаете URL на один и тот же ресурс.
Продолжим ещё одной выдержкой из того же параграфа.
Это лишнее подтверждение, что у каждой схемы локатора своё понятие «иерархии» и способ её интерпретации.
Иерархия
Далее выдержка из параграфа 3.2.4 Hierarchy (иерархия).
Далее выдержка из параграфа 3.3. HTTP.
Формальная запись
И наконец выдержка из параграфа 5. BNF for specific URL schemes (формальная запись для конкретных схем URL).
Здесь в квадратных скобках указаны опциональные части. Звёздочка перед скобкой обозначает 0 или более повторов такого фрагмента, как указан в скобках. Вертикальную черту следует понимать как ИЛИ.
Вывод
Просторечным языком смысловое наполнение двух ссылок можно пояснить так:
Несмотря на оконечный слеш во второй ссылке, она всё же адресует во второй уровень иерархии, а не в третий, потому что ссылка явно не назвала имя третьего уровня.
Из всего сказанного выше следует, что аналогично тому, как ссылки
адресуют посетителя в корень сайта, так и например ссылки
Особо подчеркну, что это внутренние знания сервера, обусловленные его конфигурацией, а также установленным на сайте движком. Внешний сервис, скажем тот же поисковик, домыслов делать не может и понятия не имеет, отличаются ли и чем ссылки со слешем и без, если только сервер сайта специально не настроили так, чтобы по таким ссылкам выдавать разный контент.
К сведению
Гуглу (опять же по сведениям, не подтверждённым экспериментом) эти редиректы не важны, так как он будто бы умеет склеивать такие адреса правильно и без редиректов.
Помните Есть немало людей, считающих себя SEO-специалистами. Но не каждый из них таким является. Более того, темой SEO часто спекулируют без должных знаний и оснований, просто в расчёте на то, что и вы неосведомлены в этой области, поэтому легко поверите в любую «лапшу». Когда вам говорят, что какая-то ваша страница «вылетела из индекса», воспользуйтесь очень хорошей рекомендацией Яндекса: Узнавать об ошибках индексирования, если таковые возникают, можно в сервисе Яндекс.Вебмастер. В этом сервисе всегда можно увидеть список ваших страниц, находящихся в поиске и список страниц, по какой-то причине исключённых из поиска. Похожий сервис есть и у Гугла. Доверяйте этим знаниям, а не мнению псевдо-специалистов, которые где-то что-то краем уха слышали, и на том основании рекомендуют вам делать так, как им кажется единственно правильным.
Что ещё почитать по теме SEO
Вот Очень интересная публикация Малоизвестные факты SEO, вышедшая в апреле 2017 года. Там представлено большое исследование со множеством скриншотов, которое начиналось с целью проверить справедливость нескольких популярных суждений в области поискового продвижения и на понятных примерах донести результаты до обычного владельца сайта. То же исследование попутно демонстрирует молодому читателю ряд очевидных, обыденных, и скорее даже неприметных, но всё же удивительных особенностей органической выдачи в поисках Google и Yandex.
Вот Хотя следующая ссылка почти не касается SEO, всё же станет привлекательной для seo-мастеров, находящихся сейчас в поиске дополнительных заказов. Под ссылкой размещено коммерческое предложение, ребята нашли любопытный способ использования сайта. Частному бизнесу предлагают создание рекламного щита онлайн на основе какой-то специальной темы, под управлением которой сайт, а точнее его первый экран выглядит словно бы баннерная растяжка на билбордах наружной рекламы. На смартфоне повернул экран, растяжка стала вертикальной и занимает всю площадь экрана, повернул назад, стала горизонтальной и снова на весь экран. А под первым экраном есть текстовый придаток, куда пользователи обычно не скролят, но поисковик хорошо видит этот текст. Так вот самые шустрые буратины регионального бизнеса покупают себе эти недорогие онлайн билборды в качестве выгодной альтернативы контекстной рекламе и контекстно-медийной сети Яндекса и Гугла. А чтобы по-максимуму тусоваться в местном поисковом индексе, на продвижение своего щита готовы стегнуть денег сразу на кучу seo-текстов, что пахнет некислой суммой. Судя по слухам, заказы на 30 килорублей проскакивают, и так как ребята аутсорсят их партнёрам сеошникам, тут можно навести мосты партнёрства и получать хороший приработок.
Слэш в конце ссылки, или Как одна косая 900 страниц сайта подвела
Для одурманивания верного семьянина Семёна Горбункова из «Бриллиантовой руки» было достаточно одной таблэтки. А для того, чтобы испортить результаты нескольких лет работы с сайтом, оказалось достаточно одного символа. И символ этот – слэш (/). Вообще проблема наличия или отсутствия слэш в конце ссылки (URL) сама по себе – небольшая проблема. Большая проблема – когда страничка открывается по ссылке со слэшем и по ссылке без него. Огромная проблема – когда структура ссылок резко меняется на всем сайте.
Влияние «миграции» слэша в конце ссылки
Печальный и свежий пример из моей практики. Увлекшись технической оптимизацией одного из контентных проектов и опьяненный первыми положительными результатами, я стал реже заглядывать в Метрику. Оправдать себя могу лишь огромной работой по переписыванию сниппетов, которая близится к завершению и скоро (очень надеюсь) принесет свои плоды.
Так или иначе, трафик после первоначального подъема стал проседать. Причем, зараза, уверенно и сильно. За пару недель снизился процентов на 30 % по Яндексу (вместе с доходом, разумеется). И вспомнил я свою любимую, но нелюбимую многими статистику (а я настаиваю на солидарности с Новосельцевым: без нее не жизнь, а каторга какая-то!). И не сразу, но все-таки зарулил в отчеты содержания по заголовкам страниц.
Видите, как втыкаются в землю разноцветные линии на графике: зеленая, коричневая, фиолетовая, голубая. Это падает посещаемость самых популярных страниц. «Зеленая» генерировала около 100 посетителей в день. «Фиолетовая» – от 150 до 200. «Голубая» в некоторые дни приводила на сайт более 200 человек. А теперь они вчетвером приводят ноль. То есть примерно минус 500 человек ежедневно по сравнению с ситуацией двухнедельной давности.
И это я еще вовремя спохватился! Потому что характер причины падения трафика таков, что он, этот трафик, в скором времени попросту должен быть исчезнуть. И дело вовсе не в бане от поисковых систем (странички продолжают успешно индексироваться, черным SEO я не занимаюсь). И не в проблемах с сервером (он в данной ситуации выступает свидетелем). Дело всего в одном символе – слэше.
Почему может пропасть слэш в конце ссылки
Распутываем клубок дальше. Слэш исчез. При очередном посещении сайта поисковый паук обнаруживал новую страничку. Вспоминал, что была такая же, но со слэшем. И старую из своей памяти удалял, чтобы не получилось дублей.
По факту странички как были на сайте, так и остались. И в поисковом индексе как были, так и остались. Но вот весь ссылочный вес по понятным причинам исчез. Ведь для поисковика ссылка со слешем и без него – это разные ссылки. И по его разумению одна может вести на более релевантную поисковому запросу страницу, чем вторая. Результат «обновления памяти» поисковика – на вышеупомянутом графике.
Проблему со ссылками (после ее обнаружения) я поправил за полторы минуты. Жаль, что теперь придется ждать 2-4 недели, пока все вернется на круги своя. А с другой стороны, если сайт не убит, значит, он стал сильнее! Ну и вашим проектам не хворать) Поделитесь этой историей с теми, кому она может быть полезна!
Все об URL: понятие, структура, виды и рекомендации по созданию
Английская аббревиатура URL расшифровывается как Uniform Resource Locator, что в переводе на русский означает «унифицированный указатель ресурса». Впервые URL стал применяться в 1990 году. Слава его изобретения принадлежит создателю Всемирной паутины — Тиму Бернерсу-Ли.
Что такое URL
Изначально УРЛ применялся для обозначения размещения файлов в Интернете, но в настоящее время используется для указания расположения почти всех веб-ресурсов. URL может обозначать путь как к веб-сайту, так и к какому-то определенному документу или изображению. Чтобы перейти к нужному сайту или файлу, пользователю нужно написать в адресной строке браузера соответствующий УРЛ. Например, URL https://timeweb.com/ru/community открывает стартовую страницу сайта хостингового сообщества «Timeweb Community».
Определить URL-адрес веб-страницы просто — он показан в адресной строке браузера. Оттуда его можно скопировать, кликнув по адресной строке правой кнопкой мыши (при этом адрес выделяется) и в контекстном меню выбрав команду «Копировать».
Чтобы скопировать адрес отдельного изображения на странице, нужно кликнуть правой кнопкой мыши по картинке и выбрать пункт «Копировать адрес изображения» или «Копировать URL картинки» (в разных браузерах название команды может отличаться).
Для копирования адреса документа в контекстном меню ведущей к нему ссылки следует выбрать команду «Копировать адрес ссылки».
Во всех случаях URL окажется в буфера обмена, откуда его можно вставить в адресную строку браузера, переслать в сообщении либо вставить в текстовый документ.
Структура URL адреса
URL-адрес, который мы видим в адресной строке браузера, состоит из нескольких частей:
В начале адреса (1) всегда указан протокол (в некоторых браузерах по умолчанию он может быть скрыт и становится виден при щелчке по адресной строке). Если мы просматриваем веб-страницу, это будет протокол передачи данных «http» или его форма «https» с поддержкой шифрования для установки безопасного соединения. Однако URL может начинаться с других обозначений, например:
После протокола (2) следует доменное имя сайта (хост) или в редких случаях его IP-адрес. Также в некоторых случаях URL-адрес может содержать номер порта, например, его можно увидеть в сетевых приложениях (выглядит это так: //example.com:8080).
Затем указывается путь к странице (3), состоящий из каталогов и подкаталогов, который, в свою очередь, включает в себя ее название.
URL также может включать параметры, которые указываются после знака «?» и разделяются символом «&». Пример адреса страницы с результатами поиска по слову «url» в поисковой системе Google:
Конечный компонент URL, который пользователь может увидеть в документах большого объема, состоящих из нескольких разделов, — это якорь, которому предшествует знак решетки «#». Часть адреса после этого знака ссылается на определенный абзац внутри страницы сайта. Пример: если на странице Википедии со статьей «URL» перейти по ссылке «Структура URL» в блоке «Содержание», унифицированный указатель ресурса в адресной строке браузера примет такой вид:
Виды URL
URL-адреса веб-страниц бывают статические и динамические.
С точки зрения SEO предпочтительнее статические ссылки, так как динамические URL имеют ряд недостатков:
Форматы URL
Транслитерация
Для обозначения названий статей обычно используют транслитерацию. Такие адреса легко читаются и понятны для восприятия пользователей.
По такому адресу сразу можно судить, какое содержимое вы увидите на странице. Поисковые системы легко распознают в подобных адресах ключевые слова, что также оказывает положительное влияние на SEO. Если в URL используется транслитерация, становится четко видна структура сайта и, чтобы попасть в нужный раздел, пользователь просто может стереть в адресной строке часть адреса.
Латиница
Латинские URL представляют собой адреса, переведенные на английский язык. Например, вместо «/novosti/» в адресе будет значиться «/news/».
Такой формат УРЛ часто используется для обозначения веб-страниц категорий и рубрик. Этот вариант считается универсальным, так как легко воспринимается пользователями и без труда обрабатывается поисковыми роботами.
Кириллические URL
Такой формат URL чаще всего применяют в кириллических доменах или когда часть адреса не очень длинная.
К их преимуществам относятся:
Однако кириллические URL имеют существенный недостаток: при копировании такого адреса и вставки его в сообщение для отправки кому-либо или вставки в текстовый редактор, вы получите непонятный набор знаков, наподобие:
Это объясняется тем, что запись URL-адресов возможна только определенными символами из разрешенного набора, а символы кириллицы в него не входят. Поэтому адрес, в котором используется кириллица, шифруется, хотя при этом ссылка все равно будет работать.
К минусам кириллических УРЛов можно отнести и трудность для восприятия зарубежными пользователями, привыкшими к латинским символам, а также сложности при чтении адресов этого формата поисковыми роботами (такие URL приходится переводить в понятный для робота вид).
Человекопонятные URL
Поисковые системы рекомендуют создавать дружественные адреса веб-страниц, по которым и пользователи, и поисковые роботы смогут судить, какая информация на этой странице находится. Например, по URL-адресу вида: www.yoursite.net/viewpage.php?page_id=23 понять это невозможно, а адрес www.yoursite.net/contact/ сразу дает представление о содержании страницы. Такие УРЛы называют человекопонятными (ЧПУ).
Кроме того, что они позволяют понять содержание веб-страницы еще до перехода по ссылке, подобные адреса имеют и другие преимущества:
При формировании ЧПУ на своем сайте следует придерживаться определенных правил:
Рекомендации по созданию URL
Соблюдайте указанные выше рекомендации, формируйте человекопонятные URL, чтобы при прочих равных условиях получить преимущество над другими сайтами.
Нужно ли ставить слэш в конце URL-адреса?
Поделиться этой статьей
Раньше после имени папки ставился завершающий слэш, а после имени файла — нет. Папка указывает на то, что есть и другие файлы. Также у вас обычно есть индексный файл (index.html, index.php и т. д.), из которого будет загружаться контент страницы. Таким образом, контент будет поступать, скажем, из “домен.com/страница/index.html”, но пользователи увидят только “домен.com/страница/”. В случае отдельных файлов у вас будет только имя файла без слэша в конце.
В большинстве систем URL-адреса не указывают на файлы. В них URL-адрес — это запись, хранящаяся в базе данных. А бессерверные системы вообще не размещают файлы на вашем сервере.
Различные структуры URL-адресов могут обрабатываться по-разному. Решите вы использовать завершающий слэш или нет — больше является вашим личным предпочтением. Давайте рассмотрим несколько распространенных сценариев.
Завершающий слэш после имени домена не имеет значения
Эти URL-адреса обрабатываются абсолютно одинаково, так что не имеет значения, какую версию вы используете.
Завершающий слэш имеет значение при обработке других типов URL-адресов
Во всех остальных случаях, кроме употребления завершающего слэша сразу после корневого домена, URL-адрес с завершающим слэшем будет рассматриваться как отдельный URL-адрес.
Завершающий слэш не должен следовать после файла
Теперь давайте посмотрим, как это влияет на SEO.
Завершающий слэш и SEO
Здесь ваше решение зависит от того, как работают ваши системы. Вот несколько распространенных сценариев, с которыми вы можете столкнуться.
По URL-адресам с завершающим слэшем и без него отображается один и тот же контент.
Как я упоминал ранее, если ваш контент можно увидеть как на версии страницы с завершающим слэшем, так и на версии страницы без него, эти страницы можно рассматривать как отдельные URL-адреса. Здесь стоит беспокоиться о том, что одинаковый контент в разных версиях может привести к дублированию контента. В большинстве случаев это не должно быть проблемой, потому что канонический тег, скорее всего, будет указывать на предпочтительную версию. Даже, если такой тег отсутствует, Google обычно выбирает для вас предпочтительную версию, в которой они объединяют сигналы. При желании вы можете принудительно указать предпочитаемую версию URL-адреса.
Независимо от того, решите вы использовать завершающий слэш или нет, вам нужно убедиться, что различные сигналы каноникализации, такие как редиректы, карты сайта, внутренние ссылки, канонические теги и т. д. указывают на ту версию, которая должна индексироваться.
По URL-адресам с завершающим слэшем и без него отображается разный контент.
В некоторых случаях, когда у вас есть две системы, использующие одну и ту же структуру папок, или с определенным программным обеспечением для A/B‑тестирования, вы можете столкнуться с ситуацией, когда версии URL-адреса с завершающим слэшем и без него показывают совершенно разный контент. В таких случаях в идеале вам нужно выбрать одну версию для индексации и показа пользователям, а затем перенаправить на нее другую версию.
Атрибут Hreflang
Вы можете столкнуться с проблемами при более сложной настройке с применением атрибута hreflang. Ссылки с атрибутом hreflang должны указывать на проиндексированную версию страниц. Если канонический тег указывает на версию страницы с завершающим слэшем и Google индексирует именно эту версию страницы, но атрибуты hreflang указывают на версию страницы без нее, то эти атрибуты hreflang могут не соблюдаться.
Добавление или удаление завершающего слэша
Этот процесс может отличаться в зависимости от вашей системы. Прежде чем вносить какие-либо изменения, лучше всего ознакомиться с соответствующей документацией.
.htaccess
Удаление слэша:
Добавление слэша:
WordPress
Вы можете выбрать, использовать ли завершающий слэш, воспользовавшись настраиваемой структурой URL-адресов в разделе “Настройки” (Settings) > “Постоянные ссылки” (Permalinks)
/%postname%/ такой формат добавит завершающий слэш к URL-адресам
/%postname% такой формат удалит завершающий слэш из URL-адресов
Фреймворки JavaScript
Из-за своих маршрутизаторов эти системы могут немного отличаться от того, к чему вы привыкли. Вы можете либо настроить способ обработки URL-адресов в маршрутизаторе, либо, если вы не хотите тратить на это много времени, можете воспользоваться встроенными модулями для добавления или удаления завершающих слэшей, которые есть в большинстве этих систем.
Влияние завершающего слэша на отчеты
При выборе, использовать завершающий слэш или нет, необходимо учитывать обработку для отчетов. Например, в Google Search Console вы можете настроить свойство префикса домена или URL-адреса. Если при настройке свойства префикса URL-адреса вы не добавите слэш в конце (например, “домен.com/папка”), Google все равно добавит его. В результате все посещения адреса “домен.com/папка” (без завершающего слэша) не будут регистрироваться, потому что адрес “домен.com/папка/” (с завершающим слэшем) имеет преимущество.
В Google Analytics (GA) такая же проблема возникает при попытке анализа контента по папкам, если на основных страницах не применяется завершающий слэш. Если у вас работают обе версии URL-адресов (с завершающим слэшем и без), то в GA можно указать обе версии.
Вы можете добавить фильтр, как показано ниже, чтобы принудительно использовать завершающий слэш в URL-адресах в ваших аналитических отчетах, если вы хотите консолидировать данные.
Для этого можете использовать следующее регулярное выражение. ^(/[a-z0–9/_-]*[^/])$
Заключение
Внесение изменений всегда сопровождается определенным риском, поэтому, если ваши настройки не вызывают проблем, я бы не рекомендовал принудительно изменять структуру ваших URL-адресов. Технологии не стоят на месте, так что старое поведение завершающего слэша в URL-адресах не применимо к большинству современных веб-сайтов.
Слеш в ссылках — не просто так
Позабавила меня статья в Википедии. По их мнению, слеш — это такая «наклонная палочка», а слэш — это и музыкант, и жанр фанфиков. Как так получилось — не понять, все это одно слово на английском — slash.
Ладно, не о том речь. Поговорим об использовании этой «косой черты» в URL ссылок. Когда-то давно, когда весь веб был статическим (голый HTML), на слеш (/) заканчивались адреса папок, а URL документа заканчивались расширением (.html, например).
Сейчас все изменилось — балом правят динамически генерируемые страницы, CMS, clean URLs и прочее — сайт может состоять из одного файла и кучи записей в базе данных. Концепция «контейнер — документ» ушла в прошлое, а вместе с ней и принятая схема адресации — по обыкновению, CMS одинаково охотно отдают страницу по обоим адресам. В частности, этим грешит MODx, если не принять меры.
По всем нормам и правилам — это 2 разных адреса (URL), 2 разных документа, поисковые системы проиндексируют оба варианта, если найдут на них ссылки. Проблема первая — дублированный контент. С этим злом нектороые CMS борятся при помощи редиректов, принимая одну из схем за основную, либо эмулируя старый подход «каталог/файл», а самые строгие вообще выдают ошибку 404 — документ не найден.
Редиректы, кстати, бывают разные: если 301 редирект передает ссылочный вес (хоть и с потерями), то 302 — нет, он еще бесполезнее, чем ссылка с nofollow. В общем, «новые компьютерные технологии» добавили удобства разработчикам и, отчасти, пользователям, но несколько затруднили жизнь оптимизаторам.
Что может случиться, если не уделять внимание слешам в адресах
Все это касается как внутренних ссылок сайта, так и ссылок извне (покупных, заказных или полностью бесплатных), так что проверяйте свои обратные ссылки, особенно покупные, а то можно «зевнуть» неплохую сумму совершенно впустую.