Редирект 301 bitrix: Настройка 301-редиректа в Битрикс — корректировка файла htaccess | Дропшиппинг

Содержание

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

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

Для того чтобы исправить такие недочеты, достаточно прибегнуть к редиректам. Создаются они как правило в файле .htaccess, который находится в корне вашего сайта.

Итак:

301 редирект c www на без www. Правим htaccess (желательно править через ftp, т.к. если вы создадите ошибку, через админку Bitrix зайти не получится)

Данные строки можно указать в самом начале файла со строкой

RewriteEngine On

В начале, либо в секции

<IfModule mod_rewrite.

(.*)$ <a href=»http://%{HTTP_HOST}/$1″ rel=»nofollow»>http://%{HTTP_HOST}/$1</a> [R=301,L]

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

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

Настройка 301-редиректа в BitrixVM

Используя дефолтную установку «1C-Битрикс: Виртуальная машина», вебмастеры часто обнаруживают на управляемом сайте следующие проблемы:

1. Детальные элементы инфоблоков (например новости или статьи) индексируются поисковыми системами (ПС) по 2 адресам:

site.ru/news/novost/

www.site.ru/news/novost/

2. Вместо доменного имени, в поисковом запросе выводится IP-адрес сервера, вида:

123.111.222.3/news/novost/

Причем, поисковый запрос с IP-адресом может в выдаче оказаться выше, чем запрос с доменным именем сайта.

Естественно, такое представление в поисковиках вредит SEO-продвижению сайта и вводит в заблуждение посетителей, т..к переходя по IP-ссылкам — в браузере также отображается IP-адрес, а не доменное имя.

Для того, чтобы поисковые системы индексировали Битрикс-сайт корректно — без дублей, необходимо в BitrixVM настроить так называемый 301-редирект. Т.е. поисковикам требуется сообщить, что проиндексированные элементы перемещены по новому адресу на постояной основе.

Как настроить 301-редирект в «1C-Битрикс: Виртуальная машина»

1. Для переадресации посетилей и ПС с адресов вида:

www.site.ru

на

site.ru

необходимо открыть root-пользователем файл:

/etc/nginx/bx/site_enabled/s1.conf

и добавить в него следующий код:

#Redirect from WWW to WITHOUT WWW
server {
listen 80;
server_name www. /(.*)$ http://site.ru/$1 permanent; }

(где переменная $host — IP-адрес сервера сайта).

сохранить и перезагрузить весь сервер, либо только Apache и Nginx с помощью команд:

service httpd restart
service nginx restart

И, таким образом, все переходы из ПС по ссылкам: www.site.ru или 123.111.222.3/news/novost/, будут перенаправляться сервером на адреса: site.ru или site.ru/news/novost/.

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

Читайте также:

Установка/настройка «1C-Битрикс: Виртуальная машина 4.2-4.3»
Как восстановить root-пароль на BitrixVM
Открытие портов в CentOS

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\. |&)_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;
    }
}

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

Битрикс24 за прокси — Pocket Admin

2020-06-10

2020-04-23 от Admin

Ввод данных
Конфигурация front-end сервера с nginx
Конфигурация back-end сервера/битрикса

Ввод данных

Возникла необходимость разместить коробочную версию Битрикс24 за прокси сервером на nginx. И так что у нас есть:

192.168.88.20 — ip сервера с nginx, для которого есть А-запись с доменным именем bx24.corp . Сервер прослушивает стандартные порты 80 и 443 .
192.168.88.24 — ip бокса версии битрикс24, который доступен на порту 80 .

Внешний сервер конфигурации с nginx

Создать отдельный файл для конфигурации /etc/nginx/conf.d/bx.conf :

 server {
    слушать 80;
    имя_сервера bx24.corp;
    вернуть 301 https://bx24.corp$request_uri;
}
сервер {
слушать 443 ssl;
        имя_сервера bx24.corp;
        SSL включен;
        ssl_certificate /etc/pki/tls/certs/bx.crt;
        ssl_certificate_key /etc/pki/tls/private/bx.key;
        ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;
        ssl_prefer_server_ciphers включен;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
место расположения / {
прокси_пароль http://192.168.88.24:80;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
}

В первом блоке server делаем редирект с http на https : принимаем запросы на 80 порт на bx24.

corp и перенаправляем на 443 порт.

Во втором блоке server указываем настройки для bx24.corp: 443 . Здесь нужно указать сертификат и закрытый ключ для доменного имени: ssl_certificate и ssl_certificate_key .

В location в proxy_pass указан back-end сервер, в нашем случае это bitrix. Параметр proxy_set_header необходим для передачи реальных IP-адресов посетителей.

Для применения новых настроек говорим nginx перечитать конфигурационные файлы:

 service nginx reload

Конфигурация back-end сервера/битрикса за прокси

Открыть конфигурационный файл nginx для битрикса. По умолчанию это /etc/nginx/bx/site_avaliable/s1.conf :

 # Веб-сайт по умолчанию
 сервер {
 слушать 80 default_server;
 имя сервера _;
 server_name_in_redirect выключен;
журнал_доступа /var/log/nginx/access.