Грамотная настройка редиректов для SEO оптимизации

В этой статье я расскажу о том, как надо желательно настроить базовые правила обработки адресов на сайте и постараюсь подробно объяснить важного каждого из правил.

Хоть поисковики и не предъявляют строгих требований и правил к тому, как должны работать сайты и тем более нет правил о том, что нужно как-то грамотно настраивать редиректы на сайте. Однако, по опыту работы с SEO оптимизацией сайтов уже сформировался набор правил для работы с URL. Вообще как и все SEO рекомендации, данная статья строится по принципу “У сайтов в ТОПе обчыно сделано так, поэтому можно считать, что эти правила нужно соблюдать, чтобы были шансы пробитсья на верхушку “SEO Олимпа”.

Итак начнем по порядку разжевывать каждое правило

Статус редиректов 301

Все редиректы должны быть с 301 статусом. Использовать редиректы со статусом 302 не желательно, так поисковик не сможет правильно передать вес новой странице, а будет ожидать, что старая страница когда-то должна вновь появиться.

Отсутствие цепочек редиректов

На сайте желательно делать всего один редирект, и не должно быть цепочек редиректов, т.е. не должно происходить так, что сначала сработало правило обработки протокола, а потом еще второе правило обработки главного зеркала, а за ним может быть третье правило и т.д. Нет, так конечно можно делать, но в ТОПе сайты, у которых таких цепочек нет, а значит и нам нужно стремиться к тому, чтобы редирект был всего один.

В том числе нужно избежать цепочек редиректов, в результате которых пользователь попадает на страницу 404 ошибки. Т.е. если файла нет, то и редирект делать не стоит, нужно просто сразу выдать 404 ошибку в ответ на запрос пользователя. Однако есть один нюанс, не всегда мы работаем с файлам, часто происходит обарботка адреса и в результате половина адресов не является физическими путями к файлам или папкам, поэтому данный момент может быть и не настроен.

Редирект с HTTP на HTTPS протокол

Или наоборот, смотря у кого какие потребности и цели. В любом случае сайт должен работать по одному протоколу, и любые запросы к публичным страницам участвующим в SEO продвижении должны быть перенаправлены на нужный протокол, в случае, если в URL был указан не верный протокол.

Редирект WWW

Так повелось, что поддомен www по умолчанию равен основному домену, а это значит, что если сайт будет работать в двух вариациях, то для поисковой машины это два разных сайта с одинаковым контентом, так называемые зеркала сайта. Поэтому необходимо определиться какое зеркало есть главное и с не главного зеркала настроить редирект на главное зеркало. Проще говоря, если по умолчанию сайт работать без WWW, то нужен редирект “с www” на “без www”, или наоборот если главное зеркало с WWW.

Окончание URL

В большинстве случаев web-сервер может выдавать контент страницы со слешем или без слеша в конце адреса, и это будут дубли страниц, т.к. для поисковика любое отличие хотя бы в один символ в URL – это разные страницы. Поэтому нужно настроить так, чтобы все страницы работали в едином формате, т.е. если решили, что в конце адреса ставится слеш, то значит все страницы делаем со слешем на конце, и настраиваем редирект со страниц без слеша, на страницу со слешем в конце.

Слеш после расширения файла

Бывает, что настраивая правило из предыдущего пункта мы можем получить в ответ на запрос к файлу шрифта в папке “/fonts/font.ttf” сервер переадресует на адрес “/fonts/font.ttf/” где мы ловим 404 ошибку вместо нужного содержимого. Поэтому важно настраивать добавление / в конец адреса с учетом исключения расширений файлов. Проще говоря, для запроса “/catalog/phones” нужно добавить слеш в конец адреса, а для запроса “/catalog/phones.php” уже не нужно.
И самый перец данного пункта, что желательно настроить обратное правило, что если в URL есть слеш после расширения файла, то желательно сделать редирект на URL с отрезанным слешем. Пример: при запросе “/catalog/phones.php/” нужен редирект на адрес “/catalog/phones.php”.

Зеркало индексной страницы

Тут еще один фокус от веб сервера – страница например /catalog/ и /catalog/index.php выводят один и тот же контент, и для вебсервера это обращение к одному и томуже файлу, но для поисковика это дубли страниц, для которых нужно тоже настроить редирект. Часто настраивается редирект с “/index.php” на “/”. Страницы с расширениями .html, .htm и вообще любыми другими, которые отдаются в качестве индексной страницы раздела все требования те же самые.

Однако, есть один подводный камень, важно настроить редирект не со всех адресов заканчивающихся .php (.html и т.п.), а только с index.php файлов, иначе можно сломать какие-то важные скрипты, которые могут быть с адресами например /ajax.php и т.п.

Двойной слеш в URL

Тут тоже самое, веб-сервер можно пропускать такие запросы и выдавать правильный контент, однако, это дубль страниц для поисковика, поэтому нужно убрать из URL повторы /.

Заглавные буквы в URL

Тут чуть интереснее, ведь файлы могут быть и с заглавными буквами, но обычно для публичных страниц, участвующих в SEO продвижении, желательно не использовать заглавные буквы, и запросы с заглавными буквами нужно перенаправлять на адреса в нижнем регистре.

Пробелы в URL

Так же как и заглавные буквы, это может быть просто ошибка при вводе адреса пользователем. По умолчанию пользователь увидит страницу 404 ошибки, но можно же и перенаправить человека на правильную страницу, поэтому желательно это правило тоже добавить.

Пустые ключи в адресной строке

Тоже интересный момент, тут все то же как и раньше, адрес поменялся, поисковик воспринимает эту страницу как новую, но по факту контент тот же, т.к. ключ был пустым, а значит и логика заложенная в скриптах вероятнее всего не отработала, и контент сайта не изменился. Например мы добавили ключ sort=asc для того, чтобы сделать сортировку выдачи в восходящем порядке, и sort=desc для сортировки в нисходящем порядке, а теперь представим, что в URL попал ключ sort= без значения. Обычно в этом случае сортировка будет применена на значение по умолчанию, и она может быть либо asc, либо desc, и в этом случае робот снова ловит дубли страницы. Да, кто-то вообще закрывает от индексации страницы с параметрами, но в некоторых случаях страницы с параметрами индексируются и иногда прилетают странные запросы с пустыми ключами, поэтому правило исправления URL от пустых ключей тоже не помешает.

Знаки “?” и “&” без ключей и убли “?” и “&” в URL

Опять дубли страниц для поискового робота, поэтому просто корректируем URL, заменяем повторяющиеся знаки “?” и “&” одинарные и убираем знаки после которых нет параметров. Например из адреса /?foo=bar& нужно убрать последний символ &, т.к. после него нет второго параметра. Или из URL /catalog/? нужно убрать знак ? т.к. после него нет ключей.

Первая страница пагинации

Первая страница пагинации должна всегда быть без ключей, поэтому если у нас в URL для пагинации используется ключ PAGE, и его значение вдруг оказалось равно 1, например “/catalog/?PAGE=1”, то нужно полность удалить ключ PAGE и URL и сделать редирект на корректную страницу. Иначе вновь ловим дубли страниц.

Особенности для CMS Битрикс, и может быть еще других CMS тоже

В любом движке сайта используются системные папки с ядром движка и другие служебные папки. Так например в движке Битрикс есть папки bitrix, upload и local, в которых обычно не кладут публичные страницы, но к этим папкам могут производиться AJAX запросы, которые веб сервер тоже может прогонять через правил редиректов, и иногда это играет злую шутку, что может отвалиться какой-нибудь функционал, например отправка формы, или добавление товара в корзину. Поэтому для запросов к файлам из системных папок нужно настроить исключение, чтобы все вышеупомянутые правила редиректов не применялись к этим запросам.

Короткие ссылки

Еще одно исключение на сайте под управлением CMS Битрикс нужно сделать для коротких ссылок, создаваемых средствами Битрикса. Эти ссылки обычно просто набор букв после корневого /. Однако в правилах формирования коротких ссылок битрикса указано, что все ссылки создаются одного вида: /~aaaaaa, где “aaaaaa” – случайный набор букв, а постоянная часть, это “~” после корневого слеша. Поэтому шаблону можно добавить правило-исключение, чтобы к подобным адресам не применялись правила редиректов. Если этого не сделать, то вероятнее всего будет добавлен / в конце адреса и короткая ссылка будет выдавать 404 ошибку, вместо задуманного редиректа на нужную страницу.

Итог

Вот он весь набор неглавных, но важных для SEO продвижения правил работы с адресами страниц.
Конкретные фрагменты кода, которые помогли бы это все реализовать я не буду пытаться предложить, т.к. каждый хостинг имеет свою архитектуру и настройки могут просто напросто не подойти и сломать текущую работу.

Сам собой напрашиваестя вопрос: “Что же делать? Как все это настроить на моем сайте?”. Как вариант можно обратиться за помощью к хостниг-провайдеру, и попросить сделтаь настройку по пунктам из этой статьи. Однако может быть так, что лучше обратиться к разработчикам, кто ведет и поддерживает проект Вашего сайта.
В своих проектах я использую собственный модуль “SEO помощник” для Битрикса, который учитывает все вышеперечисленные правила и в дополнение имеет возможность задать список статичных редиректов, а также список правил с применением регулярных выражений. Модуль позволяет сделтаь все необходимые настройки за пару минут, просто выставив флажки на тех правилах, которые нужны в конеретном проекте.

Установить модуль “SEO помощник” можно из маркетплейса Битрикса по ссылке