Нужен ли слэш в конце URL-адреса?
Завершающий слэш — это косая черта “/”, помещенная в конце URL-адреса, например: “домен.com/” или “домен.com/страница/”. Завершающий слэш обычно используется, чтобы различать папки, у которых есть завершающий слэш, от файлов, не имеющих завершающего слэша. Однако это рекомендация, а не требование.
Раньше после имени папки ставился завершающий слэш, а после имени файла — нет. Папка указывает на то, что есть и другие файлы. Также у вас обычно есть индексный файл (index.html, index.php и т. д.), из которого будет загружаться контент страницы. Таким образом, контент будет поступать, скажем, из “домен.com/страница/index.html”, но пользователи увидят только “домен.com/страница/”. В случае отдельных файлов у вас будет только имя файла без слэша в конце.
В большинстве систем URL-адреса не указывают на файлы. В них URL-адрес — это запись, хранящаяся в базе данных. А бессерверные системы вообще не размещают файлы на вашем сервере.
Различные структуры URL-адресов могут обрабатываться по-разному. Решите вы использовать завершающий слэш или нет — больше является вашим личным предпочтением. Давайте рассмотрим несколько распространенных сценариев.
домен.com
= домен.com/
Эти URL-адреса обрабатываются абсолютно одинаково, так что не имеет значения, какую версию вы используете.
домен.com/страница
≠ домен.com/страница/
Во всех остальных случаях, кроме употребления завершающего слэша сразу после корневого домена, URL-адрес с завершающим слэшем будет рассматриваться как отдельный URL-адрес.
В большинстве случаев, если вы добавляете завершающий слэш после файла, например .html, .php, .js, .css, .pdf, .jpg и т. д., файл не будет загружен. Это связано с тем, что большинство систем будут считать, что файл является папкой, а поскольку такого пути не существует, обычно возвращается страница 404.
Здесь ваше решение зависит от того, как работают ваши системы. Вот несколько распространенных сценариев, с которыми вы можете столкнуться.
Как я упоминал ранее, если ваш контент можно увидеть как на версии страницы с завершающим слэшем, так и на версии страницы без него, эти страницы можно рассматривать как отдельные URL-адреса. Здесь стоит беспокоиться о том, что одинаковый контент в разных версиях может привести к дублированию контента. В большинстве случаев это не должно быть проблемой, потому что канонический тег, скорее всего, будет указывать на предпочтительную версию. Даже, если такой тег отсутствует, Google обычно выбирает для вас предпочтительную версию, в которой они объединяют сигналы. При желании вы можете принудительно указать предпочитаемую версию URL-адреса.
Независимо от того, решите вы использовать завершающий слэш или нет, вам нужно убедиться, что различные сигналы каноникализации, такие как редиректы, карты сайта, внутренние ссылки, канонические теги и т. д. указывают на ту версию, которая должна индексироваться.
В некоторых случаях, когда у вас есть две системы, использующие одну и ту же структуру папок, или с определенным программным обеспечением для A/B‑тестирования, вы можете столкнуться с ситуацией, когда версии URL-адреса с завершающим слэшем и без него показывают совершенно разный контент. В таких случаях в идеале вам нужно выбрать одну версию для индексации и показа пользователям, а затем перенаправить на нее другую версию.
Вы можете столкнуться с проблемами при более сложной настройке с применением атрибута hreflang. Ссылки с атрибутом hreflang должны указывать на проиндексированную версию страниц. Если канонический тег указывает на версию страницы с завершающим слэшем и Google индексирует именно эту версию страницы, но атрибуты hreflang указывают на версию страницы без нее, то эти атрибуты hreflang могут не соблюдаться.
Этот процесс может отличаться в зависимости от вашей системы. Прежде чем вносить какие-либо изменения, лучше всего ознакомиться с соответствующей документацией.
Удаление слэша:
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)/$ /$1 [L,R=301]
ПРИМЕЧАНИЕ.
!-d ищет директорию и, если она существует, не удаляет слэш. Если вы не включите этот кусочек кода, вы можете поломать основные страницы директории.
Добавление слэша:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*[^/])$ /$1/ [L,R=301]
ПРИМЕЧАНИЕ.
!-f ищет файл и, если он существует, не добавляет слэш. Этот кусочек кода предотвращает поломку изображений, PDF-файлов, JS, CSS и т. д.
Вы можете выбрать, использовать ли завершающий слэш, воспользовавшись настраиваемой структурой URL-адресов в разделе “Настройки” (Settings) > “Постоянные ссылки” (Permalinks)
/%postname%/
такой формат добавит завершающий слэш к URL-адресам
/%postname%
такой формат удалит завершающий слэш из URL-адресов
Из-за своих маршрутизаторов эти системы могут немного отличаться от того, к чему вы привыкли. Вы можете либо настроить способ обработки URL-адресов в маршрутизаторе, либо, если вы не хотите тратить на это много времени, можете воспользоваться встроенными модулями для добавления или удаления завершающих слэшей, которые есть в большинстве этих систем.
При выборе, использовать завершающий слэш или нет, необходимо учитывать обработку для отчетов. Например, в Google Search Console вы можете настроить свойство префикса домена или URL-адреса. Если при настройке свойства префикса URL-адреса вы не добавите слэш в конце (например, “домен.com/папка”), Google все равно добавит его. В результате все посещения адреса “домен.com/папка” (без завершающего слэша) не будут регистрироваться, потому что адрес “домен.com/папка/” (с завершающим слэшем) имеет преимущество.
В Google Analytics (GA) такая же проблема возникает при попытке анализа контента по папкам, если на основных страницах не применяется завершающий слэш. Если у вас работают обе версии URL-адресов (с завершающим слэшем и без), то в GA можно указать обе версии.
Вы можете добавить фильтр, как показано ниже, чтобы принудительно использовать завершающий слэш в URL-адресах в ваших аналитических отчетах, если вы хотите консолидировать данные.
Для этого можете использовать следующее регулярное выражение. ^(/[a-z0–9/_-]*[^/])$
Внесение изменений всегда сопровождается определенным риском, поэтому, если ваши настройки не вызывают проблем, я бы не рекомендовал принудительно изменять структуру ваших URL-адресов. Технологии не стоят на месте, так что старое поведение завершающего слэша в URL-адресах не применимо к большинству современных веб-сайтов.
Поделиться записью