Переменные в адресе 301 редирект. Постоянная переадресация при изменении URL страниц. Перенаправление домена с www на без-www

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

Код статуса 301 означает, что запрашиваемая страница окончательно перемещена в новое местоположение.

На самом деле существует несколько редиректов. О том как сделать 301 редирект можно посмотреть на инфографике.

В каких случаях использовать редирект 301?

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

1. При смене домена. Вы переместили свой сайт в другой домен и хотите, чтобы казалось, будто перехода и вовсе не было.
2. Для передачи новому домену Page Rank и тИЦ.
3. Для сохранения поискового трафика.
4. Пользователи могут получить доступ к сайту, используя несколько различных URL-адресов. Например, попасть на страницу можно несколькими способами: //site.ru/sub , //sub.site.ru или //www.site.ru . Бывает удобно выбрать один из этих URL-адресов в качестве канонического (основного) и использовать переадресацию 301 для перенаправления на него трафика с других URL. Для настройки можно использовать «Инструменты для веб-мастеров».
5. При объединении двух сайтов требуется, чтобы все ссылки на устаревшие страницы указывали на страницы, действующие в данный момент.
6. При переносе страницы сайта в новое место.
7. Для склейки имени сайта с префиксом www и без него.

Статья по теме: Яндекс заменяет тИЦ на ИКС - новый показатель качества сайта

301-ая ошибка (301 Permament Redirect), возвращаемая при обращении к определенному адресу страницы, означает, что сайт был на постоянной основе перенесен на новый адрес, также указанный в HTTP заголовке. Как пользователи, зашедшие через браузер, так и поисковые боты будут перенаправляться по новому адресу, при этом, для поисковиков все свойства старого адреса (страницы) будут переданы новому URL . При 301 редиректе произойдет склейка старого и нового адресов: параметры вроде PageRank и тИЦ, а также вес страницы и ссылочный вес старого адреса будет передан новому URL .

Редирект с номером ошибки 301 (moved permanently) это наилучший способ сохранить рейтинг сайта в поисковых системах при переносе его на новый домен или смене системы управления контентом. Переадресацию можно выполнить несколькими способами, в зависимости от установленного программного обеспечения.

301 редирект в.htaccess

При использовании сервера Apache, переадресацию можно просто выполнить с помощью файла.htaccess , однако, при этом, не забыть включить модули mod_alias (для поддержки директив Redirect , RedirectPermanent и RedirectMatch) и/или mod_rewrite (для использования реврайта) в php.ini .

Для этого поместите в корне папке вашего сайта файл.htaccess.

Редирект с помощью директивы Redirect или RedirectPermanent модуля mod_alias

Redirect 301 /old-page.html //new-domain.ru/new-page.html

Redirect permanent /old-page.html //new-domain.ru/new-page.html

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

RedirectPermanent /old-url.html //new-site.ru/new-url.html

Редирект с помощью директивы RedirectMatch

Этот редирект подобен предыдущему, за исключением того, что можно задавать регулярное выражение для старых URL адресов. Допустим, при смене движка с PHP на ASP, можно старые адреса перенаправить следующим образом:

RedirectMatch /(.*).php$ /$1.aspx

Редирект с помощью директивы RewriteRule модуля mod_rewrite

Для использования директивы RewriteRule необходимо удостовериться, что в httpd.conf подключен модуль mod_rewrite , а также влючена опция FollowSymLinks . Использование реврайт модуля дает много возможностей для перенаправления страниц на новые адреса.

Статья

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

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

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

Что такое 301 редирект и когда его надо применять?

Чтобы СЕО продвижение вашего ресурса было максимально эффективным, нужно учитывать абсолютно все аспекты, которые могут повлиять на оптимизацию сайта. К их числу относится и рассматриваемый нами сегодня механизм. Что же такое редирект 301 (permanent redirect) и когда он применяется?

Технически это не что иное как HTTP ответа сервера, имеющий код 301, который информирует о том, что прежний изменен навсегда (moved permanently). На практике это выглядит так. При вводе старого адреса в поисковую строку браузер автоматически перенаправляет пользователя на новый урл, являющийся после настройки переадресации целевым объектом.

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

• старые урлы страниц изменены по одной из причин, которых может быть множество (о некоторых из них поговорим чуть ниже);
• нужно исключить появление дублированных страниц (с полностью идентичным содержанием) одного и того же сайта, которые открываются по разным URL-адресам. Сюда же можно отнести и полные дубли ресурсов. Например, те, которые имеют домены с WWW и без этого префикса, а также , являющиеся зеркалами основного вебсайта;
• осуществляется переезд на новый домен ( и );

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

После правильной настройки redirect 301 на страничку с новым URL со старого документа будет направлен весь накопленный им траст, включая ссылочный вес, передаваемый обратными ссылками, а также трафик посетителей, некоторая часть которого вполне может включать уже приобретенных вами клиентов или постоянных подписчиков.

Но обращаю ваше внимание на следующее. Редиректы (особенно, в массовом количестве) не всегда благо, потому не следует бездумно их использовать. Конечно, поисковики нормально учитывают permanent redirect (и передача всех характеристик со старого URL на новый тому порукой).

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

Постоянная переадресация при изменении URL страниц

В ходе развития проекта могут возникать ситуации, когда необходимо реорганизовать его структуру. Скажем, перенести некоторые статьи в другие разделы (если, конечно, они выводятся через рубрики, например), заменить постоянные ссылки на либо просто добавить в состав URL ключевые слова, которые были упущены ранее. Во всех этих случаях можно применить permanent redirect, но сначала оцените состояние своего ресурса.

Если сайт совсем молодой (2-3 месяца) и вы не успели еще толком провести внешнюю оптимизацию (получить достаточную ссылочную массу извне) тех страниц, URL которых желаете изменить, а также ежели трафик на них небольшой вкупе с полным отсутствием комментариев к статьям, то, возможно, лучше просто удалить такие вебстраницы.

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

А вот ежели ваш сайт уже набрал определенный траст у поисковиков, известность у пользователей и содержит несколько сотен страниц, то без редиректа 301 при изменении URL здесь не обойтись. Иначе, если вы решили все-таки удалить странички со старыми урлами, потери в виде посещаемости и веса уже будут серьезными.

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

Необходимость применения 301 редиректа возрастает многократно , если вы планируете перейти на новую CMS () либо поменять все разделы ресурса, иначе говоря, изменить в массовом порядке все урлы единовременно.

Дубли страниц (зеркала) сайта со слешем и без на конце, а также с index.php

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

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

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

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

Возникновение подобных дублей с окончанием index.php и/или index.html, index.htm (в зависимости от настроек сервера), а также со слешем на конце и без него, связано со структурой урлов, по которым осуществляется переход на ту или иную папку на сервере. Если URL оканчивается слешем «/» , то это команда для серверного обработчика отобразить именно содержание директории (папки), которая включает находящиеся в ней файлы:

Http://site.ru/folder/

А вот ежели слеш отсутствует , то происходит обращение к файлу:

Http://site.ru/folder

В этом случае веб-сервер будет искать именно файлик с названием «folder». Поскольку на серверах в основном используются Unix-подобные операционные системы (чаще Linux), в которых расширение для файлов, идущее после его наименования и точки, не является обязательным (этим они отличаются от Windows), то это вполне логично.

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

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

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

Http://site.ru/

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

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

Http://site.ru/index.php

Кстати, это же справедливо и для других вебстраниц, например, категорий (рубрик):

Http://site.ru/category/index.php

А это уже дубли, которые нужно во что бы то ни стало ликвидировать посредством того самого перманентного редиректа в.htaccess. Решение этой задачи не только в отношении урлов с окончанием index.php, но и других вариантов, обязательно предоставлю в последней части статьи.

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

Причем, это касается всех вебстраниц, включая те же категории:

Http://site.ru/category http://site.ru/category/

или статьи (записи):

Http://site.ru/category/entry http://site.ru/category/entry/

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

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

Многие вебмастера, например, предпочитают адреса страничек с расширением.html на конце, которые имеют завершающий вид, привычный для пользователей, у подавляющего большинства которых установлена ОС Виндовс (где наличие расширения является обязательным).

Но это лишь красивый вид, не более того (я, кстати, не разделяю этих восторгов). Как было отмечено выше, все варианты урлов, включая адреса, оканчивающиеся слешем и без оного, совершенно равнозначны с практической точки зрения.

Желательно сыграть на опережение и не ждать, пока Яндекс или Гугл сами определят основное зеркало. Ведь вы не будете знать, какому именно поисковики выказали предпочтение. А такая ситуация может сильно замедлить раскрутку веб-ресурса.

Ведь ПС исключат из индекса страницы неосновного зеркала (совершенно нерентабельно забивать БД кучей бесполезного контента), на которые, возможно, были направлены ваши усилия по продвижению. Это чревато потерями позиций в выдаче, а, следовательно, трафика и траста. Жуть.

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

Проверка наличия постоянного редиректа для каждого из дублей сайта

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

//goldbusinessnet..com/optimizatsiya-i-raskrutka-saita/index.php

И проследить, что произойдет дальше. У меня на блоге, например, первый вариант является основным, поэтому именно на него происходит перенаправление при вводе второго и третьего урла. Иначе говоря, данные зеркала уже склеены. Если же при вводе всех трех адресов открывается одна и та же страничка, но состав URL остается каждый раз неизменным (то есть, переадресации нет), то проблема имеет место быть.

Но есть и более продвинутые способы проверки склейки доменов и наличия редиректа. К таковым относится, например, возможность спросить у самих поисковых систем, ради которых вебмастера и проводят подобную оптимизацию. Например, чтобы проверить, присутствует ли переадресация от урлов с index.php на URL без этого окончания, для Яндекса необходимо ввести в поисковую строку вот такой запрос:

Url:сайт | url:сайт/index.php

После нажатия кнопки «Найти» вы получите ответ. Если присутствует один результат (как на скриншоте ниже), то все «ОК». Иначе говоря, редирект осуществлен:

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

Но самым надежным методом проверки является, на мой взгляд, получение ответа сервера. В этом случае вы получите код статуса HTTP, по которому сможете оценить корректность установленной переадресации или ее полное отсутствие. Воспользуемся для этого специальным сервисом Яндекса , введя тестируемый урл и нажав кнопку «Проверить»:

В итоге узнаем, что для URL с окончанием index.php основной робот Яндекса получил ответ «301 Moved Permanently», что и требовалось доказать. Таким же способом можно проверить перманентный редирект для любой группы страничек вашего сайта. Кстати, и поиск Google также можно задействовать (об этом в статье про домены с WWW и без также упомянуто).

Как сделать 301 редирект через htaccess

Итак, на основании предоставленной в этом мануале информации вы решили, что необходим перманентный редирект для решения той или иной задачи. С большой долей вероятности можно утверждать, что ваш сайт находится на сервере, управляемом ПО Apache (на всякий случай уточните у своего хостинг провайдера, так или это).

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

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

Доступ к этому файлу можно легко получить по , задействовав соответствующий софт в виде того же Файлзилла. Ну а вносить изменения в него желательно не в простом редакторе, а в "золотом", то бишь в , где есть возможность осуществить откат на несколько шагов назад:

Если вдруг на сервере, где хостится ваш сайт, этого файлика не оказалось, его можно создать самому. Сделать это можно прямо на сервере через ту же программу NotePad++, которая также поддерживает возможность подсоединения по FTP-протоколу.

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

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

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

Теперь посмотрим, как настроить 301 редирект через.htaccess для каждого конкретного случая. Для этого нам понадобится воспользоваться услугами модуля mod_rewrite , который и предназначен для преобразования URL на серверах Apache.

По умолчанию обычно от отключен. Чтобы включить этот модуль, требуется прописать в файл.htaccess «RewriteEngine on» :

RewriteEngine on

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

Options +FollowSymLinks RewriteEngine on RewriteBase /

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

Вторая, как я уже сказал, включает сам модуль mod_rewrite. Ну а третья (RewriteBase / ) позволяет обрезать полный путь от корня сервера до корневой директории сайта с тем, чтобы последующие директивы были применены именно к URL-адресам сайта. Если этого не сделать, могут возникнуть проблемы.

Простой знак слеша «/» здесь обозначает относительный путь для главной страницы (или до корневой папки) и используется при формировании . Если вы пожелаете прописать сразу несколько директив по 301-му редиректу, выше означенные строчки повторять перед каждым правилом не нужно.

Теперь приступаем к практике и начнем с самого легкого. Если по какой-то причине вам необходимо выборочно изменить урлы отдельных страниц, то указываем простое перенаправление на новый адрес :

Redirect 301 /page-name1/ http://site.ru/page-name2/

В этом случае для представления старого урла страницы применяется относительный путь (/page1-name1/), а нового — абсолютный (начинается с «http://»), поскольку постраничный редирект можно осуществлять и на другой сайт. Здесь следует обратить внимание на то, что между двумя адресами оставляется пробел.

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

Redirect 301 /category1/page-name1/ http://sait.ru/category2/page-name2/

Ежели надо сделать постоянное перенаправление для всех страниц ресурса сразу, например, при смене окончания адреса с расширением.php на завершение с.html, то уже используется директива RedirectMatch , позволяющая использовать регулярные выражения:

RedirectMatch 301 (.*)\.php$ http://site.ru$1.html

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

Как настроить permanent redirect для доменов с WWW и без, я . Но все-таки повторю эту информацию для полноты картины. Итак, для того, чтобы сделать постоянную переадресацию с URL, содержащего в адресе WWW, на урл без этого префикса , нужно добавить следующее правило в файл.htaccess:

RewriteCond %{HTTP_HOST} ^www\.(.*) RewriteRule ^(.*)$ http://%1/$1

И наоборот, при желании оставить в урлах страниц рудиментарный отросток в виде трех W, надо оформить перенаправление с адресов без WWW на URL с WWW посредством директивы:

RewriteCond %{HTTP_HOST} ^(.*)$ RewriteCond %{HTTP_HOST} !^www\. RewriteRule ^(.*)$ http://www.%1/$1

RewriteCond определяет условие, при котором будет выполняться правило RewriteRule (то есть сам редирект). Кстати, детальный разбор применения основных директив mod_rewrite , при желании можете ознакомиться.

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

RewriteCond %{HTTP_HOST} ^www\.site\.ru$ RewriteRule ^(.*)$ http://site.ru/$1

А обратный redirect (с без WWW на с WWW) вот так:

RewriteCond %{HTTP_HOST} ^site\.ru$ RewriteRule ^(.*)$ http://www.site.ru/$1

Чем же конкретно второй метод лучше первого? Дело в том, что в нем проверяется не только отсутствие или наличие трех W в адресе, но и сам домен подвергается проверке на полное соответствие. Только не забудьте вместо «site» и «.ru» вставить свое имя домена и доменную зону.

Попробуем склеить зеркала, плодящие дубли страниц с index.php (расширения могут быть другими, скажем, .htm или.html). Итак, 301 редирект с урлов, содержащих index.php, на адреса страниц ресурса без этого окончания :

RewriteCond %{THE_REQUEST} ^.*/index.php RewriteRule ^(.*)index.php$ http://%{HTTP_HOST}/$1

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

RewriteCond %{REQUEST_URI} !\? RewriteCond %{REQUEST_URI} !\& RewriteCond %{REQUEST_URI} !\= RewriteCond %{REQUEST_URI} !\. RewriteCond %{REQUEST_URI} !\/$ RewriteRule ^(.*[^\/])$ /$1/

А вот как выглядит обратная переадресация, то есть, с URL-ов со слешем на адреса без слеша :

RewriteCond %{REQUEST_URI} !\? RewriteCond %{REQUEST_URI} !\& RewriteCond %{REQUEST_URI} !\= RewriteCond %{REQUEST_URI} !\. RewriteCond %{REQUEST_URI} ![^\/]$ RewriteRule ^(.*)\/$ /$1

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

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

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

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

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

В завершение предлагаю еще один видеоролик, который по качеству не только не уступает первому, но и в каком-то смысле дополняет его:

1. Термины и определения В настоящем соглашении об обработке персональных данных (далее - Соглашение) нижеприведенные термины имеют следующие определения: Оператор - ИП Днепровский Олег Александрович. Акцепт Соглашения - полное и безоговорочное принятие всех условий Соглашения путем отправки и обработки персональных данных. Персональные данные - информация, внесенная Пользователем (субъектом персональных данных) на сайте и прямо или косвенно относящаяся к данному Пользователю. Пользователь - любое физическое или юридическое лицо, успешно прошедшее процедуру заполнение полей ввода на сайте. Заполнение полей ввода - процедура отправки Пользователем имени, фамилии, номера телефона, персонального адреса электронной почты (далее - Персональные данные) в базу зарегистрированных пользователей сайта, производимая с целью идентификации Пользователя. В результате заполнения полей ввода персональные данные отправляются в базу данных Оператора. Заполнение полей ввода осуществляется добровольно. сайт - сайт, размещенный в сети Интернет и состоящий из одной страницы. 2. Общие положения 2.1. Настоящее Соглашение составлено на основании требований Федерального закона от 27.07.2006 г. No 152-ФЗ «О персональных данных» и положений Статьи 13.11 о «Нарушении законодательства Российской Федерации в области персональных данных» Кодекса об административных правонарушениях Российской Федерации и действует в отношении всех персональных данных, которые Оператор может получить о Пользователе во время использования им Сайта. 2.2. Заполнение полей ввода Пользователем на Сайте означает безоговорочное согласие Пользователем со всеми условиями настоящего Соглашения (Акцепт Соглашения). В случае несогласия с этими условиями Пользователь не осуществляет Заполнение полей ввода на Сайте. 2.3. Согласие Пользователя на предоставление персональных данных Оператору и их обработку Оператором действует до момента прекращения деятельности Оператора либо до момента отзыва согласия Пользователем. Акцептовав настоящее Соглашение, и пройдя процедуру Регистрации, а также осуществляя последующий доступ к Сайту, Пользователь подтверждает, что он, действуя своей волей и в своем интересе, передает свои персональные данные для обработки Оператору и согласен на их обработку. Пользователь уведомлен, что обработка его персональных данных будет осуществляться Оператором на основании Федерального закона от 27.07.2006 г. No 152-ФЗ «О персональных данных». 3. Перечень персональных данных и иной информации о пользователе, подлежащих передаче Оператору 3.1. При использовании Сайта Оператора Пользователем представляются следующие персональные данные: 3.1.1. Достоверная персональная информация, которую Пользователь предоставляет о себе самостоятельно при Заполнении полей ввода и/или в процессе использования сервисов Сайта, включая, фамилию, имя, отчество, номер телефона (домашний или мобильный), персональный адрес электронной почты. 3.1.2. Данные, которые автоматически передаются сервисам Сайта в процессе их использования с помощью установленного на устройстве Пользователя программного обеспечения, в том числе IP-адрес, информация из Cookies, информация о браузере Пользователя (или иной программе, с помощью которой осуществляется доступ к сервисам). 3.2. Оператор не проверяет достоверность персональных данных, предоставляемых Пользователем. При этом Оператор исходит из того, что Пользователь предоставляет достоверную и достаточную персональную информацию по вопросам, предлагаемым в Полях ввода. 4. Цели, правила сбора и использования персональных данных 4.1. Оператор осуществляет обработку персональных данных, которые необходимы для предоставления сервисов и оказания услуг Пользователю. 4.2. Персональные данные Пользователя используются Оператором в следующих целях: 4.2.1. Идентификация Пользователя; 4.2.2. Предоставление Пользователю персонализированных сервисов и услуг (а также, информирование о новых акциях и услугах компании, путём рассылки писем); 4.2.3. Поддерживания связи с Пользователем в случае необходимости, в том числе направление уведомлений, запросов и информации, связанных с использованием сервисов, оказанием услуг, а также обработка запросов и заявок от Пользователя; 4.3. В ходе обработки персональных данных будут совершены следующие действия: сбор, запись, систематизация, накопление, хранение, уточнение (обновление, изменение), извлечение, использование, блокирование, удаление, уничтожение. 4.4. Пользователь не возражает, что указанные им сведения в определенных случаях могут предоставляться уполномоченным государственным органам РФ в соответствии с действующим законодательством РФ. 4.5. Персональные данные Пользователя хранятся и обрабатываются Оператором в порядке, предусмотренном настоящим Соглашением, в течение всего срока осуществления деятельности Оператором. 4.6. Обработка персональных данных осуществляется Оператором путем ведения баз данных, автоматизированным, механическим, ручным способами. 4.7. Сайт использует файлы Cookies и другие технологии, чтобы отслеживать использование сервисов Сайта. Эти данные необходимы для оптимизации технической работы Сайта и повышения качества предоставления услуг. На Сайтее автоматически записываются сведения (включая URL, IP-адрес, тип браузера, язык, дату и время запроса) о каждом посетителе Сайта. Пользователь вправе отказаться от предоставления персональных данных при посещении Сайта или отключить файлы Cookies, но в этом случае не все функции Сайта могут работать правильно. 4.8. Предусмотренные настоящим Соглашением условия конфиденциальности распространяются на всю информацию, которую Оператор может получить о Пользователе во время пребывания последнего на Сайте и использования Сайта. 4.9. Не является конфиденциальной информация, публично раскрытая в ходе исполнения настоящего Соглашения, а также информация, которая может быть получена сторонами или третьими лицами из источников, к которым имеется свободный доступ любым лицам. 4.10. Оператор принимает все необходимые меры для защиты конфиденциальности персональных данных Пользователя от несанкционированного доступа, изменения, раскрытия или уничтожения, в том числе: обеспечивает постоянную внутреннюю проверку процессов сбора, хранения и обработки данных и обеспечения безопасности; обеспечивает физическую безопасность данных, предотвращая неправомерный доступ к техническим системам, обеспечивающим работу Сайта, в которых Оператор хранит персональные данные; предоставляет доступ к персональным данным только тем сотрудникам Оператора или уполномоченным лицам, которым эта информация необходима для выполнения обязанностей, непосредственно связанных с оказанием услуг Пользователю, а также эксплуатации, разработки и улучшения Сайта. 4.11. В отношении персональных данных Пользователя сохраняется их конфиденциальность, кроме случаев добровольного предоставления Пользователем информации о себе для общего доступа неограниченному кругу лиц. 4.12. Передача Оператором персональных данных Пользователя правомерна при реорганизации Оператора и передачи прав правопреемнику Оператора, при этом к правопреемнику переходят все обязательства по соблюдению условий настоящего Соглашения применительно к полученной им персональной информации. 4.13. Настоящее Положение применимо только к Сайту Оператора. Компания не контролирует и не несет ответственность за сайты (сервисы) третьих лиц, на которые пользователь может перейти по ссылкам, доступным на Сайте Оператора, в том числе в результатах поиска. На таких Сайтах (сервисах) у пользователя может собираться или запрашиваться иная персональная информация, а также могут совершаться иные действия 5. Права пользователя как субъекта персональных данных, изменение и удаление пользователем персональных данных 5.1. Пользователь вправе: 5.1.2. Требовать от Оператора уточнения его персональных данных, их блокирования или уничтожения в случае, если персональные данные являются неполными, устаревшими, неточными, незаконно полученными или не являются необходимыми для заявленной цели обработки, а также принимать предусмотренные законом меры по защите своих прав. 5.1.3. Получать информацию, касающуюся обработки его персональных данных, в том числе содержащей: 5.1.3.1. подтверждение факта обработки персональных данных Оператором; 5.1.3.2. цели и применяемые оператором способы обработки персональных данных; 5.1.3.3. наименование и место нахождения Оператора; 5.1.3.4. обрабатываемые персональные данные, относящиеся к соответствующему субъекту персональных данных, источник их получения, если иной порядок представления таких данных не предусмотрен федеральным законом; 5.1.3.5. сроки обработки персональных данных, в том числе сроки их хранения; 5.1.3.6. иные сведения, предусмотренные действующим законодательство м РФ. 5.2. Отзыв согласия на обработку персональных данных может быть осуществлен Пользователем путем направления Оператору соответствующего письменного (распечатанного на материальном носителе и подписанного Пользователем) уведомления. 6. Обязанности Оператора. Доступ к персональным данным 6.1. Оператор обязуется обеспечивать недопущение несанкционированного и не целевого доступа к персональным данным Пользователей Сайта Оператора. При этом санкционированным и целевым доступом к персональным данным Пользователей Сайта будет считаться доступ к ним всех заинтересованных лиц, реализуемый в рамках целей деятельности и тематике Сайта Оператора. Вместе с тем Оператор не несет ответственности за возможное не целевое использование персональных данных Пользователей, произошедшее вследствие: технических неполадок в программном обеспечении и в технических средствах и сетях, находящихся вне контроля Оператора; в связи с намеренным или ненамеренным использованием Сайтов Оператора не по их прямому назначению третьими лицами; 6.2 Оператор принимает необходимые и достаточные организационные и технические меры для защиты персональной информации пользователя от неправомерного или случайного доступа, уничтожения, изменения, блокирования, копирования, распространения, а также от иных неправомерных действий с ней третьих лиц. 7. Изменение Положения о политике конфиденциальности. Применимое законодательство 7.1. Оператор имеет право вносить изменения в настоящее Положение без какого-либо специального уведомления Пользователей. При внесении изменений в актуальной редакции указывается дата последнего обновления. Новая редакция Положения вступает в силу с момента ее размещения, если иное не предусмотрено новой редакцией Положения. 7.2. К настоящему Положению и отношениям между Пользователем и Оператором, возникающим в связи с применением Положения, подлежит применению право Российской Федерации. Принимаю Не принимаю

Код ответа 301 (Moved Permanently) означает, что запрошенный документ теперь доступен по новому адресу на постоянной основе. Редирект 301 может понадобиться в нескольких случаях: переезд на новый домен, изменение адреса страницы или . Цели этих мероприятий вполне прозрачны:

• Перенос старых показателей на новую страницу или домен.
• Устранение битых ссылок, как внешних, так и внутренних.
• Устранение дублей страниц.

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

Настройка 301 редиректа со страницы на страницу

Довольно часто возникает ситуация, когда страница сайта была удалена или вынуждена сменить свой URL. При обращении к её старому адресу, пользователь, само собой, увидит страницу 404 ошибки (не найдено).

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

Также его можно использовать для борьбы с дублями страниц. В общем нужно писать книгу на тему «99 способов использование Redirect 301». Вот его синтаксис:

Redirect 301 /old-page.html http://new-domain.ru/new-page.html

Ну или так, результат будет один и тот же:

Redirect permanent /old-page.html http://new-domain.ru/new-page.html

Поясняю: /old-page.html - относительный адрес старой страницы. Он может быть вложенным: /old-category/old-page.html, ну или таким: /old-category/old-page/ - тут никаких ограничений нет. Тоже самое относится к http://new-domain.ru/new-page.html (новой странице), с той лишь разницей, что путь тут абсолютный (не обязательно, чтобы это был новый домен - может быть просто новый внутренний адрес страницы).

Настройка 301 редиректа при переносе сайта на новый домен

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

Options +FollowSymLinks
RewriteEngine on

RewriteEngine off

RewriteCond %{HTTP_HOST} ^old-domain\.ru
RewriteRule ^(.*)$ http://new-domain.ru/$1
RewriteCond %{HTTP_HOST} ^www.oldsite\.ru
RewriteRule ^(.*)$ http://old-domain.ru/$1

В данном примере мы установили редирект всех страниц старого домена на страницы нового (при условии, что их относительные адреса совпадают). При этом мы оставили без редиректа на старом домене файл robots.txt, чтобы процесс переноса был более полноценным. В него мы прописываем:

User-agent: *
Disallow:
Host: newsite.ru
Sitemap: http://newsite.ru/sitemap.xml

Ну и ждём пару месяцев, пока переезд домена не будет зачтен, а все характеристики - переданы.

Склейка зеркал сайта: 301 редирект c www на без www и наоборот

Существует несколько вариантов обращения к сайту - с www и без www (например, сайт и www.сайт). Пользователю все равно, как именно вводить URL, так как он в любом случае попадет на одну и ту же страницу. Иначе дело обстоит с поисковыми системами. Они расценивают www.site.ru и site.ru, как два совершенно разных домена (что тянется из глубин истории всемирной сети, когда это действительно было так).

Эти дубли мешают индексации сайта и продвижению в целом, так как, во-первых, это банальные дубли страниц (уж извиняюсь за повторение) и, во-вторых, входящие ссылки будут также укладываться в разные корзины. Тоже самое касается и дублей главной страницы: site.ru, site.ru/index.html, site.ru/index.php и т.д. По этой причине еще на этапе создания сайта желательно позаботиться об этом вопросе и одну из версий сайта (например, c www) переадресовать на другую (например, без www). Если момент был упущен, то тут нет ничего страшного.

Рассмотрим процесс склейки зеркал с помощью 301 редиректа поэтапно.

1. Определяем основной домен, выбранный для индексации поисковыми системами.

Основное зеркало можно легко определить по результатам поисковой выдачи Яндекс и . Вводим название домена и смотрим, какой адрес отобразится: www.site.ru или site.ru. Если же сайт еще не проиндексирован, то выбираем его по своему усмотрению. Если в Google и Yandex основные домены разные, то лучше оставьте Яндексовский.

2. Прописываем 301 редирект в.htaccess.

Находим в корне FTP сайта файл.htaccess, скачиваем и открываем в блокноте, а затем вносим в него необходимые изменения. Первый вариант - 301 редирект домена без www на с www:

Options +FollowSymLinks
RewriteEngine On

RewriteEngine off

RewriteCond %{HTTP_HOST} ^site.ru$
RewriteRule (.*) http://www.site.ru/$1

Обратная ситуация - с www на без www:

Options +FollowSymLinks
RewriteEngine On

RewriteEngine off

RewriteCond %{HTTP_HOST} ^www.site.ru$
RewriteRule (.*) http://site.ru/$1

После завершения редактирования, сохраняем файл и загружаем его в корневую папку FTP с перезаписью.

Опционально можно сразу же позаботиться о дублях главной страницы вида index.php и index.html, добавим ниже следующий код:

RewriteRule ^index\.html$ http://www.site.ru/

RewriteRule ^index\.php$ http://www.site.ru/

Ну и, опять же, если у вас site.ru:

RewriteCond %{THE_REQUEST} ^{3,9}\ /index\.html\ HTTP/
RewriteRule ^index\.html$ http://site.ru/
RewriteCond %{THE_REQUEST} ^{3,9}\ /index\.php\ HTTP/
RewriteRule ^index\.php$ http://site.ru/

3. Настройка robots.txt

Увидели знакомую директиву, оставляющей robots.txt нетронутым? Все верно, вносим изменение в robots.txt:

Host: основное-зеркало.ru

4. Проверяем работу сайта.

Вводим тот адрес, который с которого мы проставляли редирект, например www.site.ru или site.ru/index.html и если при заходе на него происходит переход на site.ru, то всё настроено правильно.

5. Настройка Yandex и Google вебмастер.

Дополнительно применяем соответствующие настройки в личных . В случае с Yandex:

Ну и для Google:

На этом вроде всё. Удачи вам и если появятся вопросы, то пишите в комментариях.

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

Что такое 301 редирект и зачем он нужен?

301 редирект призван помочь вебмастерам переадресовать пользователей с одного URL, который изначально был в адресной строке браузера, на совершенно иной. С точки зрения поисковой оптимизации, 301 Moved Permanently - это постоянный редирект, который помогает переместить до 99% ссылочного веса на новый URL, а старый «пометить» в качестве устаревшего. То есть благодаря этому удастся сохранить позиции в поисковых системах, а если просто изменить адрес URL, не делаля редирект, то для Яндекса и Гугла это будет новой страницей, которая будет ранжироваться без связки с предыдущей историей.

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

• при совершении склейки доменов;
• для переезда сайта на новый адрес, например, в случае снижения трафика вследствие попадания вашего ресурса под фильтры поисковиков. 301 редирект не позволит тем, кто добавил ваш сайт в закладки, потерять его из виду;
• чтобы увеличить показатели тИЦ, PR, трафик из ПС на основном сайте. В этом случае понадобится приобрести домен, который обладает неплохими показателями и настроить редирект на тот ресурс, который нуждается в улучшении данных параметров;
• при смене адреса конкретной страницы для сохранения высоких позиций в ПС (например, это может быть актуально при переезде сайта из одной CMS в другую);
• и др.

Как сделать 301 редирект?

Вариантов решения задачи по настройке 301 редиректа есть несколько. Каким из них воспользоваться - зависит от технических возможностей хостинга . Но у современных хостеров подобных проблем обычно не возникает, а если и появляются, то решается быстро через тех поддрежку. Вот парочка основных ситуаций простого редиректа, с которыми вы можете столкнуться. Для этого понадобиться создать файл с именем.htaccess (если его нет), а затем внести в него нужный код редиректа. Если создать его просто на рабочем столе не получается, то попробуйте сделать это через программу Total Commander, либо FileZilla просто переименовав любой ненужный документ.

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

Redirect 301 / http://site.ru

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

Redirect 301 /старая-страница.html http://новый-домен.ru/новая-страница.html

RedirectPermanent /старая-страница. html http://новый-домен.ru/новая-страница.html

Как склеить домен с www с вариантом без?

В данный момент применение www в названии сайтов считается устаревшим. Однако, такой вариант встречается нередко. Если это не покупка готового сайта , то при создании нового ресурса лучше указывать везде без www. При склеивании доменов объединяются все их самые важные параметры, такие как тИЦ, PR и посещалка. К тому же это поможет оптимизировать ресурс, и избежать ситуации, когда ПС отражение сайта с www принимают за «самозванца» с «ворованным» контентом.

Код для склеивания домена с использованием www на домен без www выглядит так:

RewriteEngine on RewriteCond %{HTTP_HOST} ^www.site.ru$ RewriteRule ^(.*)$ http://site.ru/$1

При этом значение RewriteEngine on/off является специализированной директивой, служащей для подключения либо прекращения доступа к коду самого файла. А доступ происходит посредством модуля mod_rewrite. RewriteCond - директива, используемая для формирования условий по правилам преобразования. А RewriteRule - предписание, отвечающее за производимые преобразования, в конкретной ситуации - редирект 301.

301 редирект при переезде на HTTPS

Современный тренд - перенос сайтов на защищенный протокол HTTPS. При этом настройка переадресации со страниц с HTTP на HTTPS является ключевым этапом. Делается это следующим образом в файле .htaccess.

RewriteCond %{SERVER_PORT} !^443$ RewriteRule ^(.*)$ https://site.ru/$1

Примечания и ошибки

С чем можно столкнуться, и о каких деталях не стоит забывать при настройке 301 редиректа:

• строгий учет последовательности правил редиректа - это первое, о чем следует помнить. Поэтому в случае не выполнения определенного правила, стоит перепроверить - нет ли иных редиректов, противоречащих ему;
• 301 редирект имеет множество особенностей и непростой синтаксис, все это сложно постоянно держать в голове, - так что официальные мануалы вам в помощь. Кроме них, помочь может логика и последовательный перебор нескольких вариантов;
• проверка работоспособности сайта и всех внедренных правил редиректа - это обязательное условие благополучного завершения его настройки. Не поленитесь зайти в разделы и страницы ресурса, не только на главную страницу, дабы исключить любые проблемы в дальнейшем. При допущении ошибок в синтаксисе инструкций вполне может перестать работать и весь сайт.

Также существует несколько ситуаций, когда использование 301 редиректа будет ошибочным. Так, лучше не применять многоходовый редирект, если его внедрение займет слишком продолжительное время. Или, например, при наличии контента, который дублируется, и по ряду причин нужно сохранить обе страницы для пользователей. Если страница и ее содержимое не релевантны, то от редиректа тоже стоит отказаться. Ошибкой будет настройка редиректа на некорректно работающую страницу (страница должна быть с 200 или 404 ответом сервера). И, наконец, неверным будет редирект файла robots.txt .

Другие виды редиректов

Опытные вебмастеры помимо самого популярного 301 редиректа используют и некоторые другие: от 300-го по 307-й. К примеру, 302 и 307 - это временный редирект, 305 - доступ исключительно посредством прокси и т. д. Также довольно востребованным типом редиректов можно назвать Meta Refresh. Он выполняется не на уровне сервера, а на уровне страницы. Однако, такой редирект эксперты рекомендуют применять как можно реже. Это обосновано тем, что к ним зачастую прибегают дорвейщики и спамеры. К тому же применение этого редиректа практически не дает возможности для передачи ссылочного веса.