Битрикс редирект 301: Битрикс — Как настроить 301 редирект с HTTP на HTTPS-версию сайта

alexxlab

что это такое и как его правильно настроить

Редирект 301 — это один из SEO-инструментов, который используют для постоянного перенаправления трафика с несуществующих страниц сайта. Он сообщает поисковым роботам о том, что старой посадочной больше не существует, ее необходимо исключить из индекса, а пользователям показывать контент, размещенный по новому адресу. 

В этом материале вы узнаете, в каких случаях нужно использовать этот тип переадресации, а также как прописать 301 редирект в htaccess и с помощью плагинов, если ваш сайт сделан на конструкторе или популярной CMS.

Когда необходимо, можно и нельзя использовать 301-й редирект

Очень часто владельцы сайтов неправильно используют редиректы, что приводит к потере трафика, 404-м ошибкам и ухудшению SEO-показателей. Обычно путают 301-ю переадресацию с 302-й, руководствуясь принципом: «Наверное, они работают одинаково, раз отличаются одной цифрой». На самом деле разница есть и мы уже писали про отличия этих редиректов.

Редирект 301 необходимо использовать в следующих случаях:

  • Если адрес страницы изменился навсегда. Представим ситуацию: вы добавили в каталог новый раздел и переместили в него часть товаров. Чтобы у пользователей не появлялась 404-я ошибка, когда они будут переходить на страницы с товарами, вам нужно прописать редиректы. 
  • Если изменился адрес сайта. Допустим, вы решили поменять доменное имя, чтобы пользователям было легче написать URL по памяти в строке браузера. В этом случае тоже необходимо использовать 301-й редирект. Его нужно настроить таким образом, чтобы люди попадали на ту же самую страницу на новом домене, а не на главную сайта.
  • Если ваш сайт доступен по www, http и https. В такой ситуации следует указать главное зеркало в сервисах для вебмастеров и настроить на него редирект с других адресов. Так будет правильнее с точки зрения SEO. 

Иногда SEO-специалисты используют 301-й редирект для перенаправления трафика на страницы каталога со схожими товарами.

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

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

Если у вас возникла подобная ситуация, лучше оставьте страницу в индексе, а на самой посадочной объясните, что товар больше не поступит в продажу. И обязательно установите ссылки со схожими позициями в каталоге, чтобы удержать пользователей на сайте. Как вариант — сразу настройте переадресацию на категорию, чтобы потенциальные клиенты смогли выбрать аналогичный товар.

Теперь рассмотрим примеры, когда использовать 301-е перенаправление нельзя.  

Этот вид переадресации не подходит для временных решений, потому что навсегда исключает из индекса старый URL. Если вы хотите на какое-то время скрыть от пользователей некоторые страницы сайта, используйте 302-й редирект.

Еще одна ситуация, когда 301-й редирект может только навредить — это переадресация трафика с забаненного сайта на новый домен. В таком случае вы «приклеите» все проблемы старого сайта к новому. Лучше перенести весь контент на новый домен, а на старом сайте поставить заглушку с сообщением о переезде. Как вариант — начать продвижение в поиске с нуля.

Как

настроить 301 редирект в htaccess

Настроить 301-е перенаправление можно несколькими способами — через htaccess, php, javascript, с помощью плагинов и т. д. Покажем самый надежный и правильный способ, чтобы вы не столкнулись с проблемой бесконечных переадресаций из-за конфликтов в коде.

Перед тем как сделать редирект с http на https или с одной страницы на другую, перейдите в панель управления сайта и проверьте, есть ли в корневом каталоге файл . site.ru

RewriteRule (.*) http://www.site.ru/$1 [R=301,L]

Если вам нужно использовать сразу несколько перенаправлений, располагайте строки в файле .htaccess в порядке от частного к общему. Для примера: сначала указываем простую переадресацию с одной страницы на другую, а затем уже перенаправление с http на https. В противном случае поисковые роботы будут тратить больше времени на считывание фрагментов кода, что приведет к снижению скорости загрузки сайта.

Учтите, что результат принудительной переадресации может кэшироваться браузером. Другими словами: даже если вы все пропишете правильно, в браузере сработает старое правило. Рекомендуем после настройки переадресаций проверить старые URL с помощью сторонних сервисов — Redirect Checker или Web-Tool.

Если вы все настроили верно, то при вводе старого адреса страницы сервис выдаст примерно такой ответ и покажет путь перенаправления:

Как

настроить переадресацию на конструкторах и CMS

Если сайт сделан на популярном конструкторе или CMS, то доступа к файлу htaccess у вас может не быть. Разработчики ограничивают эту возможность, чтобы неопытные пользователи ничего не сломали. В таких случаях принудительную переадресацию приходится настраивать через панель управления сайтом. Покажем, как это сделать правильно на примере Тильды, WordPress и Битрикс.

Tilda 

Для сайтов на Тильда все перенаправления можно настроить в разделе «Настройки сайта — SEO — Редиректы страниц (Code 301)». Тут всё просто: выбираете, какой именно редирект вам нужен, добавляете старые и новые URL, а затем сохраняете изменения.

Редирект с www на основной домен: настройки сайта на Тильда

Владельцам тарифа Free недоступен функционал SEO-модуля. Прописать параметры переадресации можно только на тарифах Personal и Business. Также на Тильда нельзя сделать перенаправление с одного доменного имени на другое — редиректы работают в рамках только одного домена и только с несуществующих страниц сайта. 

WordPress

Если сайт сделан на CMS WordPress, но вы боитесь менять что-то в файле htaccess, используйте плагины, чтобы сделать постоянную переадресацию.

Вот самые популярные решения для WP: 

  • Redirection. С помощью этого плагина можно легко прописать редиректы, а также собирать статистику переадресаций и отслеживать 404-е ошибки на сайте.
  • Safe Redirect Manager. Простой плагин, позволяющий использовать регулярные выражения. Понравится опытным пользователям, которым важно поддерживать высокую производительность сайта.
  • Quick Page/Post Redirect Plugin. Еще один плагин, с помощью которого можно легко прописать редиректы, а также добавить при необходимости атрибут nofollow. Единственный минус — нельзя использовать регулярные выражения. Параметры придется устанавливать вручную для каждого редиректа.

После настройки редиректов с помощью плагинов для WordPress рекомендуем периодически отслеживать данные в разделе «Ссылки — Внутренние ссылки» Яндекс.Вебмастера. Так, вы будете знать наверняка, что переадресации настроены правильно и на сайте нет битых ссылок, которые могут негативно повлиять на позиции в результатах выдачи.

Битрикс

Для сайтов, созданных на Битрикс24, тоже есть модули (плагины), которые позволяют настроить 301 редирект с одной страницы на другую или с поддомена на основной домен. Они бывают бесплатными и платными, отличаются набором возможностей. Все модули для настройки редиректов можно найти на этой странице «Каталога решений».

Учтите, что многие продукты из «Каталога решений» работают некорректно — они могут замедлять скорость загрузки сайта и даже подвешивать базу данных.

Отзывы о модуле для настройки 301 редиректа с домена на домен для сайтов Битрикс

Наши разработчики рекомендуют прописывать параметры переадресации в файле htaccess, а не делать это с помощью модулей Битрикс. 

Коротко о главном

  • Редирект 301 предназначен для постоянного перенаправления трафика с одного URL на другой, причем старая ссылка навсегда исключается из индекса.
  • Такой вид переадресации используют при смене структуры сайта, при переезде с http на https и переносе сайта с одного домена на другой.
  • Лучше всего настраивать 301-е перенаправление в файле .htaccess, добавляя в код соответствующие команды по принципу «от частного к общему (глобальному)».
  • На Тильде все переадресации прописываются в разделе SEO настроек сайта. На WordPress и Битрикс можно использовать плагины, но правильнее будет вносить изменения в файл .htaccess.
  • Редиректы после настройки нужно проверить с помощью сторонних сервисов — Redirect Checker или Web-Tool.

Поделись с друзьями:

301 редирект на 1С Битрикс или как понравится поисковикам?

Не секрет, что поисковые системы и оптимизаторы очень не любят дубли, дубли, это когда одна и таже информация на странице имеет разный путь, к примеру ваш сайт с www и без www, или в конце адреса вашего сайта есть \(слеш) или его нет.

Для того чтобы исправить такие недочеты, достаточно прибегнуть к редиректам. (.*)$ <a href=»http://%{HTTP_HOST}/$1″ rel=»nofollow»>http://%{HTTP_HOST}/$1</a> [R=301,L]

Надеюсь помог с данным функционалом.

 

 

 

Автор СтаниславОпубликовано Рубрики BitrixМетки bitrix https редиректы, Редирект с http на https

nginx — цикл перенаправления промежуточного программного обеспечения Docker Predender.io 301

Я пытаюсь настроить prerender.io для своей платформы реагирования на AWS ECS вместе с балансировщиком нагрузки, но я продолжаю получать 301 цикл перенаправления при посещении основного домена.

Согласно официальной документации и исходному коду github, я соответствующим образом настроил балансировщик нагрузки AWS в правилах прослушивателя балансировщика нагрузки:

Для HTTPS: 443, , если хост — www2.example.com Переслать в ecs_website_container

Для HTTPS:443, , если хостом является example. com ИЛИ www.example.com Перенаправить на ecs_prerender_io_container

Для HTTP:80, перенаправить весь трафик на https://#{host}:443/# {path}?#{query}

Когда я проверяю журналы Docker для предварительного рендеринга, каждый раз, когда я посещаю основной домен example.com, я вижу некоторую активность в журналах, например:

 [13/Aug/2022:18:32 :57 +0000] "GET / HTTP/1.1" 301 134 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, например Gecko) Chrome/104.0.0.0 Safari/537.36" "12.34 0,56,789"

Итак, это ошибка перенаправления 301. Дело не в переадресации на www2.example.com.

Исходный код точно такой же, как и в официальном репозитории github, только явно изменены переменные. Если я захожу напрямую на www2.example.com, сайт работает нормально, поэтому проблема должна быть где-то в конфигурации промежуточного программного обеспечения.

Я отследил редиректы и они такие (с 1 на 2, с 2 на 3 и т. д.):

 1. http://example.com
2. https://example.com:443/
3. https://www.example.com:443/
4. https://www.example.com:443/
5. https://www.example.com:443/
... бесконечная петля ...

Для ясности вот используемая конфигурация nginx default.conf.template:

 map $http_user_agent $prerender_ua {
    по умолчанию 0;
    "~* Пререндеринг" 0;
    "~*гуглбот" 1;
    "~*yahoo!\ чавкать" 1;
    "~*бинбот" 1;
    "~*яндекс" 1;
    "~*байдуспайдер" 1;
    "~*facebookexternalhit" 1;
    "~*твиттербот" 1;
    "~*Роджербот" 1;
    "~*linkedinbot" 1;
    "~* встроить" 1;
    "~*quora\ссылка\ превью" 1;
    "~*showyoubot" 1;
    "~*безмозглый" 1;
    "~*pinterest\/0\." 1;
    "~*developers.google.com\/\+\/web\/snippet" 1;
    "~*слэкбот" 1;
    "~*vkshare" 1;
    "~*w3c_validator" 1;
    "~*реддитбот" 1;
    "~*яблочный бот" 1;
    "~*ватсап" 1;
    "~*флипборд" 1;
    "~*тумблер" 1;
    "~*bitlybot" 1;
    "~*skypeuripreview" 1;
    "~*наззел" 1;
    "~*дискордбот" 1;
    "~*google\ страница\ скорость" 1;
    "~*qwantify" 1;
    "~*pinterestbot" 1;
    "~*bitrix\ссылка\превью" 1;
    "~*xing-contenttabreceiver" 1;
    "~*хром-маяк" 1;
    "~*телеграммбот" 1;
}
карта $args $prerender_args {
    по умолчанию $prerender_ua;
    "~(^|&)_escaped_fragment_=" 1;
}
карта $http_x_prerender $x_prerender {
    по умолчанию $prerender_args;
    «1» 0;
}
карта $uri $prerender {
    по умолчанию $x_prerender;
    "~*\. (js|css|xml|less|png|jpg|jpeg|gif|pdf|doc|txt|ico|rss|zip|mp3|rar|exe|wmv|doc|avi|ppt|mpg| mpeg|tif|wav|mov|psd|ai|xls|mp4|m4a|swf|dat|dmg|iso|flv|m4v|torrent|ttf|woff|svg|eot)" 0;
}
сервер {
    слушать 80;
    слушать [::]:80;
    имя_сервера ${PRIMARY_DOMAIN};
    расположение / {
        если ($ prerender = 1) {
            переписать (.*) /prerenderio последним;
        }
        proxy_set_header Хост $SERVER_NAME;
        proxy_set_header Соединение "";
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_hide_header Кэш-Контроль;
        add_header Cache-Control "public, max-age=31536000";
        #resolve с использованием DNS-сервера Google для принудительного разрешения DNS и предотвращения кэширования IP-адресов
        резольвер 8.8.8.8 8.8.4.4;
        # установка бэкенда в качестве переменной принудительно разрешает DNS, поскольку nginx кэширует IP-адреса и плохо работает с балансировкой нагрузки
        установить $backend "${SECONDARY_DOMAIN}";
        переписать . * $uri break;
        proxy_pass http://$backend;
    }
    расположение / пререндерио {
        если ($ prerender = 0) {
            вернуть 404;
        }
        proxy_set_header X-Prerender-Token ${PRERENDER_API_KEY};
        proxy_hide_header Кэш-Контроль;
        add_header Cache-Control "private, max-age=600, must-revalidate";
        #resolve с использованием DNS-сервера Google для принудительного разрешения DNS и предотвращения кэширования IP-адресов
        резольвер 8.8.8.8 8.8.4.4;
        установить $prerenderio_host "${PRERENDER_HOST}";
        proxy_pass http://$prerenderio_host;
        переписать .* /https://${PRIMARY_DOMAIN}$request_uri break;
    }
}

Пытался связаться со службой поддержки, но ответа нет.

301 злоупотребление сценарием перенаправления — с какой целью?

Background

Несколько лет назад мы написали сценарий перенаправления 301, который наши клиенты могли использовать для установки файлов cookie первой стороны перед перенаправлением на их сайт (который, в свою очередь, содержал наш iframe, который к тому моменту мог создавать/ читать основные файлы cookie).

Что-то вроде http://www.ourdomain.com/redirect?return=http://clientdomain.com/clientpage

Который установит основной файл cookie, а затем выдаст 301 для возвращаемого параметра.

Issue

Мы заметили резкое увеличение числа явно вредоносных запросов к этой странице со странными параметрами назначения. Например:

  1. /redirect?return=http://bfvev.freetzi.com
  2. /redirect?return=http://www.youtube.com/watch?v=l456e7O9ZGY
  3. /redirect?return=http://www.cognoschina.net/home/link.php?url=http://www.tklife.com.cn/home/link.php?url=http://www. .kamyarshah.com/Маркетинг/
  4. /redirect?return=http://www.m-bo.ru/bitrix/rk.php?goto=http://Abolished-your-mythology.tumblr.com/post/77355569234/shiv-shankaran-nair -деловой-архитектор
  5. /redirect?return=http://www.superdoctors.com/redirect?r=http://www.tklife.com.cn/home/link. php?url=http://www.kamyarshah.com /Маркетинг/
  6. /redirect?return=http://www.slider.com/r.php?url=http://www.tklife.com.cn/home/link.php?url=http://www.kamyarshah .com/Маркетинг/
  7. /redirect?return=http://ufacity.info/bitrix/redirect.php?event1=&event2=&event3=&goto=http://www.tklife.com.cn/home/link.php?url=http ://www.kamyarshah.com/Marketing/
  8. /redirect?return=http://www.x666xx.ru/redir.php%3Fhttp%3A//gesundheitstest.org/%3Fs%3Dzurueckbegleitendes
  9. /redirect?return=http://www.dloutstanding.com/home/link.php?url=https://www.youtube.com/watch?v=E3xd_YTntRw
  10. /redirect?return=http://www.thehighguy.ca/groups/does-a-link-developing-instrument-work-751305441/

Многие из них представляют собой простые перенаправления на другие домены (#1, #2, #10).

Многие отправляют 301-е на другие сайты, которые, похоже, тоже будут выдавать 301-е — кто-то связывает 301-е (№3, №4, №5, №6, №7, №8, №9).

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *