Раньше после имени папки ставился завершающий слэш, а после имени файла — нет. Папка указывает на то, что есть и другие файлы. Также у вас обычно есть индексный файл (index.html, index.php и т. д.), из которого будет загружаться контент страницы. Таким образом, контент будет поступать, скажем, из “домен.com/страница/index.html”, но пользователи увидят только “домен.com/страница/”. В случае отдельных файлов у вас будет только имя файла без слэша в конце.
В большинстве систем URL-адреса не указывают на файлы. В них URL-адрес — это запись, хранящаяся в базе данных. А бессерверные системы вообще не размещают файлы на вашем сервере.
Различные структуры URL-адресов могут обрабатываться по-разному. Решите вы использовать завершающий слэш или нет — больше является вашим личным предпочтением. Давайте рассмотрим несколько распространенных сценариев.
Завершающий слэш после имени домена не имеет значения
домен.com = домен.com/
Эти URL-адреса обрабатываются абсолютно одинаково, так что не имеет значения, какую версию вы используете.
Завершающий слэш имеет значение при обработке других типов URL-адресов
домен.com/страница ≠ домен.com/страница/
Во всех остальных случаях, кроме употребления завершающего слэша сразу после корневого домена, URL-адрес с завершающим слэшем будет рассматриваться как отдельный URL-адрес.
Завершающий слэш не должен следовать после файла
В большинстве случаев, если вы добавляете завершающий слэш после файла, например .html, .php, .js, .css, .pdf, .jpg и т. д., файл не будет загружен. Это связано с тем, что большинство систем будут считать, что файл является папкой, а поскольку такого пути не существует, обычно возвращается страница 404.
Теперь давайте посмотрим, как это влияет на SEO.
Завершающий слэш и SEO
Здесь ваше решение зависит от того, как работают ваши системы. Вот несколько распространенных сценариев, с которыми вы можете столкнуться.
По URL-адресам с завершающим слэшем и без него отображается один и тот же контент.
Как я упоминал ранее, если ваш контент можно увидеть как на версии страницы с завершающим слэшем, так и на версии страницы без него, эти страницы можно рассматривать как отдельные URL-адреса. Здесь стоит беспокоиться о том, что одинаковый контент в разных версиях может привести к дублированию контента. В большинстве случаев это не должно быть проблемой, потому что канонический тег, скорее всего, будет указывать на предпочтительную версию. Даже, если такой тег отсутствует, Google обычно выбирает для вас предпочтительную версию, в которой они объединяют сигналы. При желании вы можете принудительно указать предпочитаемую версию URL-адреса.
Независимо от того, решите вы использовать завершающий слэш или нет, вам нужно убедиться, что различные сигналы каноникализации, такие как редиректы, карты сайта, внутренние ссылки, канонические теги и т. д. указывают на ту версию, которая должна индексироваться.
По URL-адресам с завершающим слэшем и без него отображается разный контент.
В некоторых случаях, когда у вас есть две системы, использующие одну и ту же структуру папок, или с определенным программным обеспечением для A/B‑тестирования, вы можете столкнуться с ситуацией, когда версии URL-адреса с завершающим слэшем и без него показывают совершенно разный контент. В таких случаях в идеале вам нужно выбрать одну версию для индексации и показа пользователям, а затем перенаправить на нее другую версию.
Атрибут Hreflang
Вы можете столкнуться с проблемами при более сложной настройке с применением атрибута hreflang. Ссылки с атрибутом hreflang должны указывать на проиндексированную версию страниц. Если канонический тег указывает на версию страницы с завершающим слэшем и Google индексирует именно эту версию страницы, но атрибуты hreflang указывают на версию страницы без нее, то эти атрибуты hreflang могут не соблюдаться.
Добавление или удаление завершающего слэша
Этот процесс может отличаться в зависимости от вашей системы. Прежде чем вносить какие-либо изменения, лучше всего ознакомиться с соответствующей документацией.
.htaccess
Удаление слэша:
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)/$ /$1 [L,R=301]
Добавление слэша:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*[^/])$ /$1/ [L,R=301]
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-адресах не применимо к большинству современных веб-сайтов.
Перевела Олеся Коробка, владелец Fajela.com
