Conference manager ошибка 301

Здравствуйте, уважаемые друзья и гости блога! Сегодня пойдет речь о такой странной вещи на сайте, как ошибка 301 Moved Permanently (переехал навсегда) или по другому редирект 301.

Думаю. что все с таким сталкивались, а некоторые даже использовали данную “ошибку 301” на своих сайтах. Но не все знают для чего эта ошибка 301 или иначе редирект 301 нужна на сайте? Для чего он, 301 редирект, используется?!

Вот сейчас мы с вами и займемся разбором этого вопроса во всех его подробностях и нюансах …

Как Вы уже наверное догадались по переводу слов “moved permanently” – это дословно, что сайт или отдельная его страница “переехал навсегда” по адресу на который Вас перекинул ваш браузер. Тут надеюсь все понятно и ясно без лишних пояснений!

Но возникает вопрос. Для чего это сделано вебмастером этого сайта? Почему он поставил редирект 301 и у нас с вами выскакивает иногда 301 ошибка? А все просто! Ошибка 301 появляется, когда сервер перебрасывает нас с уже не работающего сайта на страницу сделанную специально для перенаправления пользователя на рабочий сайт, но просто с некоторой задержкой или вообще на этой странице нужно самостоятельно перейти по ссылке. Вот это в двух словах об ошибке 301.

Теперь самый важный момент, зачем же все таки нужен редирект 301 на сайте …

Редирект 301 и для чего он нужен?

Есть несколько причин у вебмастера, чтобы использовать редирект 301. Вот они:

• Причина первая: Склейка домена с www и без www. При этом все seo показатели сайта и его ссылочный вес будут совмещены и не будут отличаться друг от друга.
• Причина вторая: Если вдруг пришлось сменить домен для сайта. Тогда применяется редирект 301 и он как раз перенаправляет посетителя сайта и поисковые роботы на рабочий домен сайта. Это также позволит вам сохранить все seo показатели вашего переехавшего сайта, как тИЦ, PR, так и своих посетителей.
• Причина третья: Использование редиректа 301 при переносе отдельной страницы сайта на другой ресурс. Бывают и такие случаи, когда это нужно сделать.
• Причина четвертая: Например у Вас есть сайт, где высокий тИЦ и PR и много посетителей. И еще есть другой сайт, который нужно немного пропиарить и прибавить к нему посещения. Тогда Вы просто на просто перенаправляете при помощи того же редирект 301, с одной страницы высоко посещаемого сайта на страницу более низко посещаемого сайта и тем самым выигрываете, добавив ему веса ссылочной массы и соответственно посещений.

Вот основные причины для использования редирект 301 или ошибка 301 Moved Permanently.

Теперь давайте узнаем, как правильно использовать редирект 301 на своем сайте и как настроить его через файл htaccess …

301 редирект и файл htaccess – как правильно настроить?

Как я вам уже говорил выше – 301 редирект это переадресация посетителя и поискового робота на сайт или отдельно взятую страницу сайта на URL адрес отличный от первоначально запрошенного в браузере.

Для чего это нужно мы с вами также уже разобрали. Но как же это сделать правильно на нашем сайте используя файл htaccess? Сейчас я вам все подробно объясню и приведу примеры внесения изменений в файл htaccess для вашего сайта!

• Перенаправление домена с www на без-www

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.(.*) [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]

или вот более понятный синтаксис:

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.domain.com$ [NC]
RewriteRule ^(.*)$ http://domain.com/$1 [R=301,L]

•  301 редирект запросов без-www на домен с www префиксом

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^domain.com$ [NC]
RewriteRule ^(.*)$ http://www.domain.com/$1 [R=301,L]

Альтернативный вариант:

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www.(.*) [NC]
RewriteRule ^(.*)$ http://www.%1/$1 [R=301,L]

•  301 редирект старого домена на новый в фале htaccess

Options +FollowSymLinks
RewriteEngine on
RewriteRule (.*) http://www.newdomain.com/$1 [R=301,L]

•  Если вам нужно, чтобы вместо rewrite.htm загружался файл rewrite.html, добавьте в файл htaccess вот это:

RewriteEngine   on
RewriteBase     /
RewriteRule     ^rewrite.htm$  rewrite.html [R=permanent]

•  Чтобы заменить все .htm файлы на .html внесите в файл htaccess:

RewriteEngine  on
RewriteBase     /
RewriteRule     ^(.*).htm$  $1.html [R=permanent]

•  Варианты, когда не нужно использовать 301 редирект на вашем сайте:
• Если реализация 301 редиректа невозможна или она займет неоправданно много времени.
• Если контент вашего сайта дублируется на двух или нескольких страницах, но эти страницы должны быть доступны в поиске пользователю ввиду некоторых отличий (на пример, выбор какого-то товара).
• Если одна страница имеет несколько URL адресов (сортировка каталога товаров по различным категориям или критериям).
• Для кросс-доменов. Это, когда контент сайта на двух URL адресах дублируется, но он должен быть доступен на каждом из двух или нескольких доменах.

Этот материал посвящен выходу 301-ой статьи на моем блоге!

Может вам интересно узнать, что такое ошибка 503 и как ее устранить?

На этом пока все. Всем удачи и благополучия!

При работе с веб-ресурсами возникают ситуации, когда происходит удаление, перенос или изменение url-адреса отдельных страниц или сайта целиком. При этом требуется сохранить индексацию в поисковых системах и перенаправить пользовательский трафик на новый адрес. Для решения этой задачи используется функция под названием 301 Redirect. Это один из инструментов SEO, который позволяет не только избежать ошибок при открытии отдельных страниц, но и добиться корректной работы ресурса. Правильные настройки редиректа дают дополнительную возможность получить синергетический эффект в поисковой оптимизации и увеличить количество органического трафика на релевантные страницы. Рассмотрим более подробно, как происходит настройка редиректа 301.

Что такое переадресация 301

Permanent Redirect 301 применяется с целью организации постоянной переадресации с неактуального доменного адреса или url отдельной страницы на рабочую версию. Редирект может понадобиться в связи с глобальным переносом сайта на другой домен, техническими изменениями в написании адреса, удалением страниц, необходимостью внутренней и внешней перелинковки. Один из вариантов использования перманентной переадресации – редирект с нескольких доменных имен, созданных в разных зонах, на один актуальный адрес. Грамотное использование редиректа позволяет перемещать контент без потерь в поисковой индексации, сохранить и даже увеличить прежний вес и позицию в выдаче.

Настроить код состояния HTTP 301 можно разными способами:

• с помощью HTML и PHP;

• через панель управления или плагины соответствующей CMS;

• при помощи специальных скриптов (программ);

• на уровне хостинг-провайдера;

• внесением соответствующих записей в файлы .htaccess для сервера Apache или web.config для IIS.

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

Альтернативные методы переадресации

• Редирект 302. Применяется в случае временной переадресации с одного url на другой. При его использовании поисковая система индексирует все доступные версии сайта или страницы. Объединения ссылочного веса и внутренних метрик на приоритетном ресурсе не происходит. 
• 307 Temporary Redirect рекомендуется применять в исключительных случаях. Например, при техническом обслуживании сайта, когда он недоступен некоторое время. 
• Обновления Meta Refresh выполняют переадресацию не на уровне сервера, а непосредственно на сайте. Пользователь сталкивается с временной задержкой (обычно около пяти секунд), после чего для перехода на нужную страницу должен принудительно запустить определенную команду. Этот метод часто приводит к падению посетительского интереса и проседанию поисковых индексов.
• Редирект rel=«canonical». Позволяет сохранить доступ посетителям ресурса к контенту дублирующихся страниц. При этом для поисковиков наличие команды canonical на одной из страниц говорит о том, что только она подлежит индексации в поиске.

В большинстве случаев постоянная переадресация является более правильным решением, чем временная. На практике это объясняется просто. Предположим, сайт сменил доменную зону, а затем еще и обзавелся защищенным протоколом https. При настройке временной переадресации в индексе Яндекса и Google по одним и тем же запросам появились три версии сайта с пропорциональным проседанием позиций в выдаче. После настройки редиректа 301 на приоритетный url произошло склеивание дублей, робот вернул сайт в топ выдачи. 

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

В каких случаях используется постоянный редирект 301

1. Смена доменного имени, перенос сайта. Необходимо произвести тотальную настройку переадресации со старого адреса на новый, чтобы все без исключения запросы к old_site.ru перенаправлялись на new_site.ru.

2. Изменение написания url определенных страниц в целях SEO-продвижения, смены CMS или по иным причинам. Требуется настроить редирект с site.ru/1hdkr5 на site.ru/page_adress.

3. Перенос разделов на субдомены. Необходимо сменить адрес www.site.ru/example на example.site.ru.

4. Для аккумуляции трафика с адресов, купленных в разных доменных зонах, на один приоритетный ресурс. 

5. Исключение дублирующихся страниц из индекса. 

6. Склейка зеркал сайта – вариантов сайта с идентичным контентом, но разным написанием адресов: site.ru, www.site.ru, https://site1.ru и т.д. В этом случае выбирается один приоритетный домен и на него настраивается редирект со всех остальных зеркал.

7. Удаление ранее существовавшей страницы. В этом случае пользователи обычно видят ошибку 404. Большое количество таких сообщений негативно воспринимается как пользователями, так и поисковиками.

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

Создание постоянной переадресации 301 через настройки и плагины CMS

В большинстве популярных конструкторов сайтов и CMS (OpenCart, Joomla!, Битрикс, Wix, Тильда) предусмотрена настройка редиректов с помощью встроенных инструментов. Если сайт создан с помощью WordPress, для настройки переадресации можно воспользоваться следующими плагинами:

• Redirection — самый популярный плагин для настройки редиректов. Кроме основной функции обладает следующими возможностями: сбором статистики переадресаций, отслеживанием ошибок 404, поддержкой регулярных выражений.

• Safe Redirect Manager — простой плагин, который также поддерживает регулярные выражения, практически не влияет на производительность сайта.

• Quick Page/Post Redirect Plugin — еще один удобный инструмент оптимизации. Один из недостатков — отсутствие поддержки регулярных выражений. К ссылкам можно добавлять атрибут «nofollow».

• Simple 301 Redirects. Данный модуль обладает одним недостатком – url для переадресации необходимо прописывать вручную.

Настроить Permanent Redirect 301 в Вордпресс можно и через редактирование файла .htaccess в разделе управления хостингом. Чтобы подключиться к нему, потребуется использовать FTP-клиент. Сама кодировка производится по общим правилам настройки переадресации в .htaccess.

Чтобы настроить 301 редирект в CMS OpenCart в файле .htaccess необходимо прописать:

RewriteCond %{QUERY_STRING} ^_route_=адрес_старой_страницы.html$

RewriteRule ^(.*)$ http://ваш_домен.ru/новой_страницы/? [R=301,L]

Для Битрикс кодировка будет выглядеть следующим образом:

RewriteEngine On

RewriteCond %{HTTP_HOST} ^www.sng-it.ru$ [NC]

RewriteRule ^(.*)$ http://sng-it.ru/$1 [R=301,L]

В Joomla настройки переадресации производятся через панель администратора в разделе «Компоненты» => «Перенаправление». Здесь можно не только установить правила редиректа, но и отслеживать страницы с битыми ссылками и перенаправлять их на корректные адреса.

С конструкторами сайтов все не так однозначно. Например, один из наиболее популярных CMS-конструкторов WIX не предоставляет возможности создания файла .htaccess.

Но настроить редирект 301 довольно просто в базовом редакторе.

Настройка 301 редирект в .htaccess

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

Для настройки 301 редиректа в файле .htaccess чаще всего применяют одну из трех директив: Redirect, RedirectMatch или RewriteRule. Директивы относятся только к папке, где размещен .htaccess, а оттуда распространяются на дочерние папки.

Найти файл можно через панель управления хостинга либо использовать FTP-клиент. При любом варианте нужно включить отображение скрытых файлов.

Предварительная подготовка

• Для создания 301 редиректа перейдите в панель управления вашего сайта.

• Проверьте наличие .htaccess файла в корневом каталоге сайта (public_html, если используете WordPress). Если файл отсутствует, создайте его.

• Рекомендуем все условия редирект записывать в блоке IfModule, дабы избежать ошибок при выполнении файла htaccess.

<IfModule mod_rewrite.c>
</IfModule>

• Перед тем как начать прописывать правила перенаправления, необходимо включить механизм преобразований (RewriteEngine) при помощи команды RewriteEngine On.

• Хостинги применяют по умолчанию 302 или любой другой 3xx редирект. В связи с этим в правилах используются флаги. Рекомендуем дописывать в своих правилах [R=301,L].

Разберем наиболее распространенные варианты создания 301 редиректа через .htaccess.

Склейка зеркал сайта (www / без www)

Сайты http://name.site и http://www.name.site для поисковых систем являются разными. А по факту это разные адреса одного сайта.

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

Если изначально в индекс поисковой системы попала версия «с www», в файл .htaccess добавляется редирект на «без www»:

RewriteCond %{HTTP_HOST} ^www.name.site$ [NC]

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

Если произошла обратная ситуация и необходима переадресация с без «www» на «www», то в файл прописывается:

RewriteCond %{HTTP_HOST} ^v name.site$ [NC]

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

Редирект с http на https для всего сайта

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

RewriteCond %{SERVER_PORT} !^443$

RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

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

RewriteCond %{HTTPS} =on

RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [QSA,L]

RewriteCond %{HTTPS} off

RewriteCond %{HTTP:X-Forwarded-Proto} !https

RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Если редирект не работает и в этом случае, попробуйте такой вариант:

RewriteEngine On

RewriteCond %{SERVER_PORT} !^443$

RewriteCond %{REQUEST_URI} =/page.php

RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R,L]

В результате пройдет перенаправление на https всех пользователей и поисковых систем.

Постранично

Бывают случаи, когда необходимо создать редирект на https всех страниц, кроме одной. В этом случае используют постраничный редирект:

RewriteEngine On

RewriteCond %{HTTPS} =off

RewriteCond %{REQUEST_URI} !^/page.php

RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [QSA,L]

Для одной страницы

Для редиректа с http на https одной страницы (например page.php), в файл добавьте следующую конструкцию:

RewriteEngine On

RewriteCond %{HTTPS} =off

RewriteCond %{REQUEST_URI} =/page.php

RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [QSA,L]

Редирект сайта с https на http

Если необходимо сделать 301 редирект всего сайта с https на http, в файл прописывается следующее:

RewriteCond %{SERVER_PORT} ^443$ [OR]

RewriteCond %{HTTP} =on

RewriteRule ^(.*)$ https://name.site/$1 [R=301,L]

Изменение домена

В том случае. если необходимо перейти на другой домен, при этом сохранив SEO-позиции, в файл .htaccess прописывают следующее:

RewriteCond %{HTTP_HOST} ^www.old_name.ru$ [NC]

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

RewriteCond %{HTTP_HOST} ^old_name.ru$ [NC]

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

Редирект на страницу с другим url (без параметров)

Иногда возникает ситуация, когда необходимо изменить url страницы, то есть перенести данные с одной страницы на другую страницу, при этом не потеряв вес страниц. В этом случае в файл .htaccess прописывают следующее:

RewriteRule ^(.*)old_page.html$ http://vash-sait.ru/new_page.html [R=301,L]

Редирект для url (с параметрами)

Если адрес содержит параметр (например, http://name.site/articles.php?section=1, где параметром является «section=1» ), то прописывают следующую конструкцию:

RewriteCond %{QUERY_STRING} section=1

RewriteRule ^index.php http://name.site/articles.php? [R=301,L]

Редирект с index.php на главную страницу

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

RewriteCond %{THE_REQUEST} ^[A-Z]{3,9} /index.php HTTP/

RewriteRule ^index.php$ http://name.site/ [R=301,L]

Редирект со страниц со слешем на без слеша (для всего сайта)

Для избегания дублей в файле .htaccess используют следующую конструкцию:

RewriteCond %{REQUEST_URI} !?

RewriteCond %{REQUEST_URI} !&

RewriteCond %{REQUEST_URI} !=

RewriteCond %{REQUEST_URI} !.

RewriteCond %{REQUEST_URI} ![^/]$

RewriteRule ^(.*)/$ /$1 [R=301,L]

Или более короткий вариант:

RewriteCond %{REQUEST_FILENAME} !-d

RewriteCond %{REQUEST_URI} ^(.+)/$

RewriteRule ^(.+)/$ /$1 [R=301,L]

Редирект со страниц без слеша на слеш (для всего сайта)

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

RewriteCond %{REQUEST_URI} !?

RewriteCond %{REQUEST_URI} !&

RewriteCond %{REQUEST_URI} !=

RewriteCond %{REQUEST_URI} !.

RewriteCond %{REQUEST_URI} !/$

RewriteRule ^(.*[^/])$ /$1/ [R=301,L]

301 редирект с 404 Not Found

Код 404 Not Found (страница не найдена) присваивается удаленной или несуществующей странице на сайте. Создание постоянного перенаправления с таких страниц актуально для контентных сайтов и крупных интернет-магазинов, где страницы часто удаляются по естественным причинам. Тогда возникает потребность перенаправить посетителей на одну из главных страниц сайта, чтобы они не уходили с ресурса при виде ошибки.

301 редирект для страниц 404 Not Found сделать совсем не сложно. Например, этот код перенаправит со всех 404-страниц на главную:

ErrorDocument 404 http://www.site.com/301.html

Однако делать такие редиректы в массовом порядке не рекомендуется, так как это может испортить SEO-статистику всего ресурса.

Финальный вид файла .htaccess

Пример файла htaccess, после добавления в него редиректов:

Options -Indexes

ErrorDocument 404 /404.php

php_flag register_globals off

php_value pcre.recursion_limit 1000

#Условия 301 редиректа


<IfModule mod_rewrite.c>

RewriteEngine On

# склейка зеркал


RewriteCond %{HTTP_HOST} ^my_site.ru

RewriteRule ^(.*)$ https://my_site.ru/$1 [R=301,L]

RewriteCond %{HTTP_HOST} ^my_site.ru

RewriteRule ^(.*)$ https://my_site.ru/$1 [R=301,L]

RewriteCond %{HTTP_HOST} ^www.my_site.ru

RewriteRule ^(.*)$ https://my_site.ru/$1 [R=301,L]

RewriteCond %{HTTP_HOST} ^www.my_site.ru$ [NC]

RewriteRule ^(.*)$ https://my_site.ru/$1 [R=301,L]

RewriteCond %{HTTP_HOST} ^www.my_site.ru

RewriteRule ^(.*)$ https://my_site.ru/$1 [R=301,L]

# без слеша


RewriteCond %{REQUEST_FILENAME} !-d

RewriteCond %{REQUEST_URI} ^(.+)/$

RewriteRule ^(.+)/$ /$1 [R=301,L]

</IfModule>

php_value default_charset utf-8

AddType 'text/html; charset=utf-8' .html .htm .shtml

Синтаксис для регулярных выражений в .htaccess

Важно учитывать, что настройка редиректа путем редактирования файла .htaccess  доступна исключительно для веб-серверов Apache.

Другие способы создания переадресации 301

Через PHP

Данный вариант подойдет тем, кто хорошо разбирается в web-программировании и PHP. Необходимо открыть файл index.php в корне CMS-движка и прописать там:

if($_SERVER['REQUEST_URI'] == "/index.php") {

 header("Location: /",TRUE,301);

 exit();

}

(в первой строке укажите старый url, а во второй — новый)

Второй способ — перенаправление при помощи отправки заголовков (скрипта):

<?php

  header("HTTP/1.1 301 Moved Permanently");

  header("Location: http://www.newdomain.ru/newdir/newpage.htm");

  exit();

?>

ASP-редирект

<%@ Language=VBScript %>

<%

Response.Status="301 Moved Permanently"

Response.AddHeader "Location", "http://www.new-url.com"

response.end

%>

ASP.NET редирект

Найдите в корне своего сайта файл web.config и вставьте в секцию синтаксис:

<script runat="server">

  private void Page_Load(object sender, System.EventArgs e)

  {

    Response.Status = "301 Moved Permanently";

    Response.AddHeader("Location","http://www.new-url.com");

  }

</script>

ColdFusion редирект

<.cfheader statuscode="301″ statustext="Moved permanently">

<.cfheader name="Location" value="http://www.new-url.com">

JSP (Java) редирект

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

<script type="text/javascript" src="redirect.js"></script>

<script type="text/javascript">

  location="https://yandex.ru";

</script>

CGI-скрипт на PERL

$q = new CGI;

print $q->redirect("http://www.new-url.com/");

Ruby on Rails

def old_action

headers["Status"] = "301 Moved Permanently"

redirect_to "http://www.new-url.com/"

end

Редирект в Nginx

if ($host = 'www.domain.com' ) {

  rewrite ^(.*)$ http://domain.com$1 permanent;

}

HTML-редирект

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

<meta http-equiv="refresh" content="5;https://livepage.pro">

Если поставить значение 0 вместо 5, то переадресация на https://livepage.pro произойдет моментально.

Однако для больших сайтов HTML-перенаправление делать сложно и затратно по времени, поэтому лучше отдать предпочтение другому варианту.

Редирект 301 в панелях управления сервера

Большинство панелей управления сервера предоставляют возможность настройки переадресации с кодом 301. Рассмотрим варианты решения этой задачи на примере двух популярных ПУ для VDS.

Cpanel

Нужно перейти в блок «Домены» => «Перенаправления». В появившемся окне выполнить следующее:

• В строке «Тип» выбрать «Постоянный 301».

• В строке «https://www» из выпадающего списка выбрать домен сайта (например, example.ru).

• В строке «Перенаправляет на» указать для домена адрес http://example.ru.

• В блоке «Перенаправление www» поставить галочку напротив «Перенаправлять только с www».

• Сохранить изменения кликом на «Добавить».

ISPmanager

В этой панели можно вручную править файлы nginx.config или .htaccess, но есть и встроенный механизм переадресации. Например, для настройки редиректа на https/http нужно снять галочку с соответствующего пункта в разделе «WWW-домены».

Автоматическое создание переадресации

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

• Seomagnifier — 301 для www;

• 301 Redirect Code Generator Tool — для доменов и страниц;

• Generate .htaccess— для страниц, разделов сайтов, доменов.

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

Самый простой способ проверки переадресации – ручное тестирование. Для этого необходимо вставить в адресную строку браузера url сайта или страницы, с которой настроено перенаправление. Если при открытии будет доступен ресурс, на который настроен редирект, то переадресация выполняется правильно.

Для автоматической проверки можно воспользоваться специальными сервисами:

• Redirect Checker, bertal.ru или Header Checker Tool для тестирования отдельных страниц;

• программой Screaming Frog Seo Spider, способной просканировать весь сайт.

Существует ряд ошибок, которые следует избегать при настройке редирект 301:

• использование перенаправлений между страницами сайта без изменения их url в ссылках;

• установка временной переадресации вместо постоянной;

• неправильный выбор типа редиректа;

• перенаправление файла robots.txt;

• непонимание разницы между rel=canonical и кодом 301;

• редирект на нерелевантный контент;

• переадресация, которая не приводит к 200-й странице.

Стоит отметить проблему создания цепочки ссылок, которая может привести к появлению циклического редиректа — ошибки с кодом «ERR_TOO_MANY_REDIRECTS». Наиболее распространенные причины возникновения такого бага – неправильная настройка в процессе создания переадресации, вирусная атака, слишком длинная цепочка редиректов. Не рекомендуется настраивать редирект, содержащий более пяти адресов. Оптимальной является прямая переадресация со старого на новый url.

Заключение

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

Инструментов для настройки корректной работы Permanent Redirect 301 существует достаточно много. Наиболее удобный и правильный – внесение записей в файл .htaccess. Недостаток этого метода в том, что он доступен только для веб-серверов Apache. При использовании IIS придется настраивать web.config. Для создания сложных правил переадресации более всего подходит PHP, но в этом случае без помощи программиста не обойтись. Еще одним вариантом настройки 301 редиректа может быть обращение к хостинг-провайдеру с целью подключения услуги web-форвардинга.

The following code runs on an Adafruit ESP32 Feather that connects to the internet via my ASUS RT-N66U router. The ESP32 is «remote» and is accessible only via wifi.

It posts to ThingSpeak every 10 minutes and works fine for a day, sometimes a few days, but then it stops posting and returns error -301 («failed to connect») with every attempt. It only starts posting again after a hard reboot.

I suspected heap fragmentation, but free heap is constant at 247k (after an initial quick decline from 250k) and max allocatable heap is constant at 114k from the start.

ESP32 hasn’t lost wifi connectivity, since I can access the ESP32 via the router (and run the «server.on» commands).

I also have an ESP8266 posting to ThingSpeak every five minutes and it has been online for months, so the problem probably isn’t with the router or ISP.

I’m running the latest ThingSpeak library, ESP library and core (but not developmental version), and Arduino IDE.

Would appreciate suggestions on things to try or monitor.

Подскажите где ошибка, на сервер приходит такой запрос:
http://homeserver.com/database/client/number/7573

Сервер должен переделать его на такой:
http://homeserver.com/database/client?number=7573

и отдать PHP скрипту (т.е. создать GET параметр из строки запроса)

В браузере все работает как надо, (временно для проверки сделал чтоб скрипт Выводил Get параметры в браузер)

А из приложения для Android (собственно для него и надо сделать) на такой запрос приходит ответ

<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>

Вот строка конфигурации NGINX

rewrite /database/client/(w+)/(d{4})   /database/client?$1=$2 break;

Обычные посетители сайта обращают внимание в первую очередь на качественный контент, а поисковые краулеры – на ответы сервера.

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

Немного теории

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

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

Сперва определимся с терминами.

• Клиент – компьютер, смартфон или другое мобильное устройство, которое имеет подключение к интернету.
• Сервер – определенный компьютер, который хранит все данные сайта (включая страницы и системные файлы). Именно на сервере «живет» сайт.

Выделяют пять классов ответов. Идентифицировать класс можно по первой цифре.

• 5** – техническая ошибка на стороне сервера. Точная причина указывается сразу после кода. Иногда пятисотая говорит о внутренних сбоях, реже – о превышении статической нагрузки на сервер.
• 4** – сбой на стороне юзера.
• 3** – обнаружен редирект на другой адрес (не ошибка).
• 2** – запрос обработан успешно (не ошибка).
• 1** – служебный класс кодов, который чаще всего относится к информационным сообщениям (не ошибка).

Логика кодов, таким образом, весьма проста:

Что значат коды состояния HTTP

Причины / решения / пояснения ошибок, я буду давать только для самых часто встречающихся кодов. Для всех остальных – только краткое описание.

Двухсотые – успешные запросы

200 – успешный запрос данных. Код не является ошибкой.

201 – завершена успешная транзакция. Код говорит о том, что сформирован новый ресурс (или документ).

202 – запрос принят, но еще не завершен. Необходимо дождаться окончания обработки.

203 – данные получены не из первоисточника (возвращаемые данные идут не от исходного сервера, а от какого-то другого) и могут быть устаревшими.

204 – запрос был обработан правильно, но отсутствует содержимое. Есть заголовок ответа, но содержимое для него отсутствует. Обновлять и актуализировать содержимое не нужно.

205 – клиенту необходимо осуществить сброс содержимого. Саму страницу обновлять не требуется.

206 – ошибка частичного содержимого. Если клиент хочет выполнить загрузку данных в несколько потоков, а сервер выполняет только часть GET-запроса, будет возникать 206-ая ошибка.

GET-запрос предназначен для получения данных, в то время как POST-запрос нужен для отправки данных.

Код также может быть отправлен с сервера, когда клиент запросил диапазон (например, условно: «Дайте мне первые 2 МБ видеоданных»). Происходит возврат только частичного контента, соответствующего Range-заголовку (данный заголовок дает понять серверу, какую именно часть страницы от него требуют, и какую ему нужно вернуть).

Если страница отдает этот код, следует обратить внимание на выполнение кэширования и на исходящий запрос.

207 – выполнено несколько операций. Найти их можно в XML, в строке MultiStatus.

226 – обработан IM-заголовок. Содержимое будет возвращено для получения информации об ответе вместе с ранее обозначенными параметрами.

Трехсотые – запросы на редирект

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

301 – документ был навсегда перемещен на новый URL. Так должны отвечать все веб-страницы, которые удалены или являются зеркалами, дублями. Со временем все указанные страницы будут склеены с целевой веб-страницей (присоединены к ней) автоматически. Если возникает такая ошибка, нужно настроить 301-ое перенаправление с устаревшего URL на актуальный (если речь идет о веб-странице, которая уже ранжировалась, но ее URL изменился). В таком случае все позитивные метрики, включая вес URL, будут сохранены.

302 – документ был временно перемещен на новый URL. Это абсолютно корректный ответ сервера, который актуален для веб-страниц с распродажами или сезонными акциями, распространяющимися на какой-либо товар. Код указывает, что данный URI будет учитываться клиентом в последующих запросах. Другими словами, страница была найдена, но перенесена. Такие документы из индекса не удаляются. Если адрес был изменен навсегда, вместо 302-го, лучше использовать 303-ий или 307-ой ответ.

303 – нужно направить пользователя на иной URL. 303-ый код можно получить исключительно GET-запросом. В идеале, этот код нужно отдавать, когда требуется редиректнуть посетителя на близкорелевантую, но не идентичную странице.

304 – документ не модифицировался. Этот код не является стандартным редиректом. Он помогает краулерам определять страницы, которые не изменились с последнего визита.

Если на вашем сайте немного страниц (до 1 000), использовать код 304 нет смысла. Если вас напрягает этот редирект, то в заголовке нужно поправить параметр Last-Modified (последняя дата изменения) – он не должен быть старше, чем заголовок If-Modified-Since (если изменялся спустя заданное количество времени).

305 – доступ к этому документу возможен исключительно через прокси.

307 – документ был временно перемещен на иной URL. Идеальный вариант, если требуется временно редиректнуть посетителя, но оставить техническую возможность отправки POST-запросов.

Четырехсотые – сбои на стороне клиента

400 – ошибка синтаксиса. Сервер не может идентифицировать запрос, так как была допущена опечатка в синтаксисе. Проверьте корректность отправляемого запроса.

401 – отсутствует аутентификация. Код отдается, когда для доступа требуется пароль или регистрация.

403 – отсутствует доступ к документу. Возникает, когда пользователь хочет открыть системные файлы (robots, htaccess). Либо вы сделали опечатку при вводе URL и пытаетесь воспользоваться веб-страницей, которая не предназначена для обычного пользователя, либо вам нужно: пройти авторизацию для доступа к системным файлам.

404 – отсутствует соответствующий ресурс по введенному URL. Разберитесь, по каким причинам была удалена / перемещена страница. Возможно, вы допустили ошибку и удалили ее случайно. Если так – просто восстановите ее.

Задумайтесь над созданием красивой, кастомизированной 404-ой. Например, такой:

405 – некорректный метод (указывается в запросной строке клиента) для выбранного документа. Метод запроса определяет точное действие, которое должно быть выполнено для указанного ресурса.

406 – некорректный / неподдерживаемый краулером формат запроса. Код отдается, когда сервер не способен возвратить ответ, релевантный листу допустимых значений. Самый распространенный случай – поисковый робот не поддерживает кодировку документа или его язык. Убедитесь, что в теле сообщения содержится лист доступных ресурсов. Подробное описание ошибка на сайте веб-разработчиков Mozilla.

407 – отсутствует регистрация прокси или авторизация файервола.

408 – таймаут запроса. Соединение разорвано, так как полный запрос не был передан. Другими словами, запрос занял слишком много времени, а сервер не готов был ждать. На каждом сайте существует свое время таймаута. Проверьте наличие интернета и просто обновите страницу. Подробное объяснение этой ошибки на сайте веб-разработчиков Mozilla.

409 – несовместимость двух запросов. Запрос невозможно выполнить при текущем состоянии сервера. Самый распространенный случай – операции c PUT-запросом. Например, когда нужно скачать файл, возраст которого превышает возраст уже существующего, расположенного на сервере.

410 – ресурс более не существует по указанному URL. Если страница удаляется целенаправленно, лучше делать так, чтобы она отдавала именно 410-ый. Краулер обойдет такую страницу, получит этот код и больше никогда на нее не вернется, так как поймет, что она удалена навсегда. Если речь о веб-странице, которая была удалена временно, гораздо эффективнее использовать 404-ый ответ. Если страница удалена намерено и навсегда, но в SERP имела хорошие места и приносила трафик, лучше сделать редирект на максимально релевантную существующую страницу.

411 – сервер сам отклоняет отправляемый запрос, так как не находит значение Content-Length. Этот ответ характерен как для обычных POST-запросов, так и для PUT-запросов (подразумевают замену существующих представлений документа на данные, которые содержатся в самом запросе).

412 –не были до конца выполнены условные поля HTTP-заголовка, например, If-Match. 412-ый код появляется в случаях, когда доступ к целевому документу отклоняется. Нужно проверить соблюдение и корректность HTTP-заголовков выполняемого запроса.

413 – у каждого сервера есть свой собственный максимальный размер запроса, определяемый не самим HTTP-протоколом (у него ограничения по длине запроса просто напросто отсутствуют), а ограничениями со стороны браузеров. Браузеры поддерживают запросы от 2 до 8 килобайт. Вышеуказанный код отдается, когда сервер не понимает запрос из-за слишком большого размера.

414 – возникает, когда отправляется чрезвычайно длинный URL. Запросы, содержащие излишне длинные URL, не могут правильно интерпретироваться сервером. Самые частые случаи появления этого ответа – попытка передать удлиненные параметры (излишне большое количество данных через GET- запрос).

415 – некорректный медиаформат. Текущий тип данных не может быть интерпретирован сервером.

416 – некорректное значение Range (диапазон). Ответ возникает в случаях, когда в самом HTTP-заголовке прописывается некорректный байтовый диапазон. 416-ый отдается в случаях, когда сервер не может взаимодействовать с запрашиваемыми диапазонами. Причина – отсутствие диапазона в необходимом документе или опечатка в синтаксисе.Сервер просто не имеет возможности работать с запрашиваемыми диапазонами. Проверьте синтаксис значения Range – он должен обязательно соблюдаться. Скорее всего, документ просто не имеет запрашиваемых диапазонов. Обновите страницу.

417 – указанное значение Expect не может быть удовлетворено (речь о заголовке запроса). Прокси некорректно идентифицировал содержимое поля «Expect: 100-Continue». Устранить эту ошибку самостоятельно не удастся. Если вы используете прокси Squid, обратитесь в поддержку. Вам нужно активировать ignore_expect_100. Другой вариант ­ разрешите BS_PingHost обращаться к интернет-сети без участия прокси.

422 – существует определенная логическая ошибка. Какая именно, данный код не указывает. Копайте в сторону ошибок в семантике документа.

423 – используемый ресурс был заблокирован для выбранного HTTP—метода. Перезагрузите роутер и компьютер. Используйте только статистический IP.

424 – зависимый ресурс был блокирован по соображением безопасности. Данный код отдается, если в запросе присутствуют признаки несанкционированного доступа к файлам CMS.

426 – некорректные значения полей Upgrade и Conection. Этот ответ возникает, когда серверу требуется обновление до SSL-протокола, но клиент не имеет его поддержки.

429 – слишком много запросов. Ошибка отдается, когда один пользователь проявляет чрезмерно большую активность за короткий временной интервал. Проверьте плагины используемой CMS. В идеале, отключите их все и включайте по очереди, пока не доберетесь до источника проблемы.

451 – доступ к серверу заблокирован по решению судебных органов. Можно плодить бесконечные дубли или вообще создать новый домен, но рано или поздно страницу с идентичным содержимым все равно заблокируют. Временное решение – разместить проблемное содержимое на другом домене. Провайдеры могут подстраховаться и блокировать не только отдельные страницы, но и сайты целиком. Не нарушать закон – единственное, что можно посоветовать в этом случае.

Пятисотые – серверные сбои

500 – серверу не удается полностью обработать запрос. Такой код отдается, когда существует непредвиденное условие, мешающее выполнению запроса. Чаще всего внутренняя ошибка сервера может появляться при серверных сбоях. Проверяйте, корректно ли указаны директивы в системных файлах (особенно htaccess), нет ли ошибки прав доступа к файлам. Обратите внимание на ошибки внутри скриптов и их медленную работу.

Проверяйте конфликты плагинов и дополнений. Нередко 500-ая возникает, когда в настройках административной панели хостинга указана одна версия PHP, а на самом сайте используется другая. Последнее также создает высокую статическую нагрузку на хостинг. Если вам было бы узнать о пятисотой подробнее, пишите в комментариях, и я напишу развернутый материал на эту тему.

501 – не выполнено. Этот код отдается, когда сам сервер не может идентифицировать метод запроса. Сами вы эту ошибку не исправите. Устранить ее может только сервер.

502 – шлюзовый сбой. Возникает при получении некорректного ответа от сервера, находящегося по иерархии выше. Актуально исключительно для прокси и шлюзовых конфигураций.

503 – данный ответ возникает в случаях, когда существуют технические неполадки, не позволяющие интерпретировать введенный запрос. Скорее всего, ваш сервер просто на обслуживании или сильно перегружен. Уменьшите число перманентных запросов к базам данных. Убедитесь, что на сервере нет профилактических или других работ, ограничивающих его пропускную способность. Не используйте VPN.

504 – отсутствует ответ. Этот код отдается в одной ситуации – если сервер не может получит ответ за необходимый период времени. Отклика нет и возникает таймаут. Как и 501-ый ответ, 504-ый исправить самостоятельно не получится. Здесь дело в прокси, часто – в веб-сервере. Первым делом просто обновите веб-страницу. Если не помогло, нужно почистить DNS-кэш. Для этого используем сочетание горячих клавиш Windows+R и вводим команду cmd (Control+пробел). В открывшемся окне указываем команду ipconfig / flushdns и подтверждаем ее нажатием Enter.

Также полезно посмотреть, как страница ведет себя различных мобильных устройствах и в разных браузерах. Проверьте дебаг. Если сайт на WP, то проверить дебан проще всего. Достаточно добавить этот код в wp-config.php:

Теперь все сбои будут фиксировать в файле debug.log (находится в папке wp-сontents). Если вы используете другую CMS, найдите к ней мануал и посмотрите, как активировать в ней журнал ошибок.

Также 504-ая отдает, когда на сайте существуют проблемы, связанные с задействованием CDN или кастомизированных серверов DNS. Отключите CDN на своем сайте.

Иногда 504-ый код пропадает, если просто подождать несколько часов. Часто 504-ая появляется на сайтах, которые используют CloudFlare.

505 – отсутствует поддержка текущей версии HTTP-протокола.

507 – не хватает места на жестком диске для выполнения запроса.

510 – не найдено расширение, желающее задействовать клиент.

Массово проверяем ответ веб-страницы

Самый простой способ проверить ответ веб-страницы – воспользоваться готовыми сервисами. Наиболее популярны:

• mainspy;
• 2ip;
• cy-pr;
• wwhois;
• 4seo.

Возьмем для примера mainspy. Тут проверить код ответа проще всего:

Таким образом, для проверки кода просто открываем страницу и вводим необходимые URL. Кликаем «Проверить». Будет выведен отчет. Напротив каждого проверяемого URL будет отображаться код ответа сервера:

Кроме перечисленных сервисов есть также замечательный плагин для Google Chrome – HTTP Header Spy. Он позволяет проверять код ответа сервера как одной, так и нескольких страниц сразу:

Послесловие

Коды ответа HTTP – это универсальный язык, который понимают не только краулеры Google / «Яндекса», но и люди. 5 классов кодов позволят с первого взгляда определить, где именно существует ошибка при выполнении HTTP запроса и куда копать для ее устранения.

Если ваш код ответа не указан в этом мануале, значит речь идет о кастомизированном сервере. Чтобы правильно истолковать ответ такого сервера и перевести его на человеческий язык, придется обратится к его разработчику.