Привет, друзья. Сегодня хотелось бы обсудить очень заезженную, но всегда актуальную тему – это 301 Редирект (Permanent Redirect 301) – в seo-тусовке и без формальностей именно это подразумевается под словом «редирект» . Технически это является ответом сервера на обращение к нему, этот ответ имеет код 301, обозначающий, что адрес обращения был изменен навсегда (moved permanently). В результате всех этих хитрых махинаций мы должны получить какой-то новый конечный адрес.
Я считаю, что вам не нужны эти технические аспекты, а потому хочу поговорить о прикладных вещах – когда и в каких ситуациях лучше использовать редирект, каким образом и при помощи каких команд можно настроить правила переадресации и т.д . А так же рассмотрим инструменты и сервисы, при помощи которых можно проверить правильность редиректов.
Так как пост вышел очень большим, то я решил сделать оглавление для вашего удобства :
Когда НЕОБХОДИМО делать 301 редиректВ первую очередь редирект применяется, когда страница (группа страниц или целый раздел) сменила свой адрес — чаще всего это случается при изменении структуры сайта, переименовании основообразующей части url’а или смене принципа формирования адресов (проще говоря, ЧПУ). К сожалению, не все об этом задумываются, когда что-то меняют на сайте, и в итоге возникает куча дублей, что приводит к потере позиций или даже наложению санкций со стороны поисковых систем. По своей работе я очень часто сталкиваюсь с такими ситуациями, и это стоит много нервов, чтобы все исправить и нивелировать последствия. От себя могу порекомендовать перед любой работой по смене типа ЧПУ или переделке структуры составить план текущей структуры сайта, всех его разделов и примеров конечных страниц. Все это необходимо будет проверить после завершения работ, чтобы при переходе по старому адресу мы попадали на новый, а сервер отдавал редирект с кодом 301 (а не 302).
Следующий частый случай использования 301 редиректа – смена адреса сайта или склейка зеркал. Если вы решили поменять адрес сайта в связи с ребрендингом компании или зарегистрировали новый более красивый и короткий домен для указания его на печатной промо-продукции — очень важно, чтобы при обращении к адресу на старом домене пользователь попадал на ту же самую страницу (а не на главную страницу), но на новом домене. Что касается промо-сайтов, то обычно они состоят из одной-двух страниц, ссылки с которых ведут на основной сайт, или же при переходе на промо-сайт сразу происходит редирект на специальную страницу основного сайта. Еще иногда при создании сайта регистрируется сразу несколько доменов, например, из-за неоднозначного написания имени компании на латинице. Чтобы интуитивно набирая адрес, пользователь попал куда надо, и регистрируются несколько доменов – очень важно, чтобы со всех «вспомогательных» доменов происходил 301 редирект на один основной адрес. Ни в коем случае нельзя допустить, чтобы по всем адресам был доступен один и тот же сайт.
И еще о зеркалах – может случиться так, что ваш сайт будет доступен по адресам http://www.site.ru, http://site.ru и https://site.ru (последнее редко, но бывает) – это все классические ошибки, которые нельзя допускать, и в их решении как раз участвует 301 редирект. Так же как и в случае с разными адресами сайтов, необходимо определиться с главным зеркалом (с www или без www) и настроить редиректы на основное зеркало. Конечно, поисковики не глупые и в таких ситуациях часто сами справляются, а так же им можно помочь, сделав правильные настройки в панелях вебмастера и в robots.txt (для Яндекса, директива Host). Но seo – дело тонкое, и я бы не стал полагаться на удачу, а воспользовался проверенным способом!
Иногда случается очень неприятная ситуация, когда копия сайта оказывается доступной не только при вводе в адресной строке названия домена, но и IP-адрес сервера. Такая ситуация вряд ли может произойти на виртуальном хостинге, а вот если у вас выделенный сервер, то запросто. Это может являться причиной некорректной настройки сервера – решить проблему поможет отключение возможности доступа при обращении к ip-адресу, но лучше всего здесь выручит 301-редирект на уровне веб-вервера (apache или nginx). Пару месяцев назад у меня случилась как раз такая ситуация – у меня был выделенный сервер, на котором висела часть сайтов, но под один из сайтов я решил взять еще один отдельный сервер. Я перенес сайт, все работало как часы, и вот однажды натыкаюсь в выдаче Гугла на клон моего сайта – шок, паника – оказалось, что это ip адрес моего нового сервера и, разумеется, на нем живет мой сайт, а при обращении сервер отдает ответ 200 OK, и Google проиндексировал его полностью. На предыдущем сервере такой проблемы не было, там изначально был настроен 301-редирект с ip на домен, указанный в качестве основного для этого ip. Теперь я научен горьким опытом и всегда проверяю такие вещи – будьте в курсе и вы, не повторяйте ошибок. Проблему решили путем добавления в конфиги веб-сервера nginx 301 редиректа на основной домен, пример кода покажу в практической части поста ниже.
Ситуация подобная предыдущей – когда копия сайта находится и доступна через служебный тестовый домен , например, вида site.hosting.ru. Такие случаи в моей практике тоже встречаются, и, в отличие от предыдущего случая, это свойственно как раз для виртуального хостинга. Для чего такое существует? Например, у вас еще не куплен домен или вы переносите сайт с одного хостинга на другой, а NS сервера для домена не сменили, или еще не обновились записи DNS у провайдера. В таких ситуациях и делают тестовые адреса, где вы можете все настроить и установить, прежде чем перенаправлять адрес сайта на новый хостинг. И вот некоторые хостеры грешат тем, что не закрывают доступ к таким техническим адресам и при этом даже не запрещают их индексацию. Если и у вас случилась эта неприятная ситуация, то стоит попробовать прописать 301-редирект с технического адреса на основной в файле.htaccess.
Ну и, конечно же, 301 редирект очень любят применять правильные сеошники для борьбы с различными дублями страниц. Почему только правильные сеошники? Да потому, что неправильные хуй забили на сайт клиента и, что вполне вероятно, даже не заходя на сайт, стали закупать ссылки – увы, это не редкость. Ко мне периодически обращаются заказчики, которые хотят проверить добросовестность своих подрядчиков/сотрудников, отвечающих за оптимизацию и продвижение сайта, насколько качественно идет работа – – и пока еще ни разу не было такого, чтобы я не нашел на сайтах ошибок или недоработок. Так что, имейте в виду – я всегда рад вам помочь. Вернемся же к дублям – я считаю, что вместо того чтобы закрывать дубли от индексации, необходимо делать редирект на основной адрес, а это уже не так интересно. Разумеется, существует масса случаев, когда дубли вынужденные, и тогда без канонизации не обойтись, но если есть возможность сделать редирект, обязательно делайте его. Частые случаи дублей, которые необходимо проверять всегда: адреса со слешем на конце и без, адреса с параметрами и метками – как это решать, я расскажу ниже.
Когда МОЖНО делать 301 редиректВ этом разделе много не напишешь, но я постараюсь. Очень надеюсь, что после прочтения вы в комментариях добавите мне парочку идей.
Redirect 301 можно использовать в качестве ответа сервера вместо ошибки 404 Not Found – другими словами, пользователь, перейдя по неправильной ссылке или на несуществующую страницу, увидит не сообщение, мол, «Извините, такой страницы больше нет», а будет перемещен на другую существующую страницу. Это очень спорный момент среди специалистов, а потому я свое мнение никому не навязываю. Но я предпочитаю использовать именно редирект вместо 404 ошибки, и тут существует несколько вариантов развития событий… Смотрите, есть 2 категории 404 ошибок: первая – классическая, когда страницу действительно удалили, вторая – когда появление ошибки связано с кривыми внешними ссылками. В первом случае, наверное, не стоит делать редирект, а оставить 404 ошибку как она есть. А вот во втором случае стоит озаботиться редиректом на правильный url-адрес, если его можно восстановить из битой ссылки, или редиректом на главную страницу (или категорию).
Когда НЕ СЛЕДУЕТ делать 301 редиректНесколько слов о том, когда редирект может вам навредить, а потому его не стоит использовать в следующих ситуациях.
Самое главное, чтобы не наделать ошибок, не стоит связываться с редиректами, если вы на 100% не уверены в том, что вы делаете или в чем-то сомневаетесь. Примите это как дружеский совет:)
Перманентный редирект не стоит использовать для временных решений , это очевидно из его названия – для временного перемещения используйте 302 Moved Temporarily. При этом не произойдет склейки страниц и страницу с редиректом можно будет в любое время восстановить.
Если с вашим доменом случились проблемы, например, фильтры, бан и т.п., и вы решили сменить адрес сайта (домен), то не стоит делать 301 редирект со старого домена на новый — в результате вы «приклеите» к новому домену и все проблемы старого. То есть в итоге ничего и не изменится. Да, было какое-то время решение выхода из под гугло-фильтра Пингвин при помощи полного 301-редиректа со старого домена на новый. Действительно все позиции восстанавливались до уровня как до санкций, и это казалось панацеей от злого Пингвина, но при очередном апдейте алгоритма эта особенность была учтена и новый домен так же попадал под фильтр, в итоге ничего не улучшалось после смены домена. Если уж вы решили сменить домен, то можно попробовать перенести весь контент на новый домен, а на старом его удалить и повесить заглушку с сообщением о переезде, а еще лучше начать все «с нуля».
Существует очень много способов сделать 301-редирект: через htaccess, php, javascript, настройки сервера и т. д. – так вот не надо пытаться использовать сразу все методы одновременно , слишком велика вероятность «разногласий» между разными способами и можно, например, получить бесконечное циклическое перенаправление.
Когда вы работаете со сложной структурой сайта или перерабатываете большой портал, часто случаются множественные редиректы или длинные цепочки. Это значит что редирект происходит не в один шаг, а в два и более – это плохая ситуация и ее надо по возможности избегать. При переходе по такой ссылке поисковый робот, получив несколько перенаправлений подряд, может подумать, что его обманывают и прекратить следовать дальше и вообще перестать учитывать ссылки. Вот вам пример из моей практики, однажды мне на аудит попался сайт с такой неожиданной цепочкой:
http://site.ru/tax/term/30 ->
http://www.site.ru/tax/term/30 ->
http://www.site.ru/tax/term/30/ ->
http://www.site.hosting.ru/404.php ->
http://www.site.ru/404.php
А еще в итоге страница http://www.site.ru/404.php, которая должна отдавать 404 ошибку, отдает ответ 200 OK. Это даже мне взорвало мозг, а представьте, что подумал бы поисковый робот, попав в такую карусель! Мало того, что в цепочке поучаствовали три разных домена, так еще и страница ошибки говорит, что она не ошибка и ее надо индексировать.
По возможности стремитесь к отсутствию редиректов внутри сайта – если внешние ссылки на сайт исправить уже нельзя и редирект неизбежен, то внутренние ссылки надо стараться исправлять. Может быть это и не скажется на качестве индексации и ранжировании, но и нельзя быть уверенным наверняка, а потому лучше избегать таких спорных ситуаций. В отслеживании внутренних редиректов и вообще ошибок внутри сайта вам поможет замечательная .
Составляя привила редиректов в.htaccess исключайте реальные адреса директорий и файлов на сервере и следите за выборкой. Ситуация для сайта, попавшего мне однажды на аудит – в борьбе с дублями страниц категорий со слешем на конце и без, вебмастер перестарался немного и наоборот только усугубил проблему. Мало того, что под правила перезаписи попали и реальные файлы js-скриптов и css-стилей из-за чего они перестали корректно работать, так еще и некоторые страницы получили ненужный слеш на конце и появились дубли. Друзья, тщательно следите, чтобы составленные правила распространялись только на ту группу адресов, с которой вы работаете, и ограничивайте все остальные.
Для поиска проблемных страниц и их адресов, от которых необходимо избавиться, используйте возможности панелей вебмастера от Яндекс и Google. Для Яндекса Вебмастер: Выбираем сайт –> Индексирование сайта –> Исключенные страницы. Для Google Webmaster: Выбираем сайт –> Оптимизация –> Оптимизация HTML; А так же: Выбираем сайт –> Конфигурация –> Параметры URL.
Особенности индексации и переиндексации редиректов в Яндекс и Google. Когда вы будете бороться с дублями и проблемными адресами, разумеется, вы будете ждать удаления ошибок из панелей вебмастера, тут есть некоторые особенности. С Google все просто – настроили редиректы, изменения проиндексируются в течение 2 недель, за это же время начнут исчезать ошибки и из панели вебмастера, обычно через месяц все ошибки пропадают. С Яндексом же есть тонкость, и заключается в следующем – после простановки редиректов можно ждать пропадания ошибок из панели вечно, я ждал однажды полгода, пока не написал в поддержку, где мне сообщили, что помимо редиректа необходимо дополнительно закрыть проблемные страницы в robots.txt и только тогда они пропадут из панели вебмастера.
Permanent Redirect 301 через.htaccessТакой способ установки редиректов является самым популярным и простым. Хотя, признаться, далеко все не так просто, как кажется, так что я планирую написать отдельный пост про htaccess. Из плюсов данного способа можно отметить, что редирект срабатывает на уровне сервера и до запуска обработки любых скриптов сайта и не несет дополнительной нагрузки.
У вас на сервере (в корне, там где главный index.php) уже наверняка есть файл.htaccess. Если этот файл не видно:
- Проверьте настройки ftp-менеджера, он может скрывать системыне файлы, коим и является файл htaccess
- Зайдите в файловый менеджер через панель управления хостера и проверьте права для файла. Я имею ввиду не CHMOD, а группу и пользователя, например, там может стоять пользователь root, а вы подключаетесь через ftp используя доступ пользователя владельца домена.
- Банально файла может не быть:) Тогда его следует создать, но под windows иногда возникает проблема, т.к. по сути файл.htaccess видится системой как файл без имени и только с расширением. Предлагаю простой способ – создаем обычный txt-файл, добавляем в него строку «RewriteEngine On» (без кавычек), загружаем txt-файл на сервер, на сервере переименовываем файл в.htaccess
Большинство правок, связанных с редиректом следует писать в самом начале файла после строки «RewriteEngine On» , чтобы эти правила обрабатывались в первую очередь. Важно соблюдать последовательность действий, т.к. команды обрабатывается сервером построчно с самого начала и до первого вхождения. Иначе говоря, надо всегда начинать с частной и заканчивать более общей выборкой.
Давайте рассмотрим несколько самых распространенных и полезных примеров:
301 редирект для домена с www.site.ru на site.ru
RewriteCond %{HTTP_HOST} !^www\.(.*) RewriteRule ^(.*)$ http://www.%1/$1
Вышеописанные варианты редиректа отлично работают и не требуют никаких правок с вашей стороны — только вставить в.htaccess файл. Однако для 100% надежности я бы посоветовал вам другой вариант:
| RewriteCond %{HTTP_HOST} !^www.site.ru$ RewriteRule ^(.*)$ http://www.site.ru/$1 |
RewriteCond %{HTTP_HOST} !^www.site.ru$ RewriteRule ^(.*)$ http://www.site.ru/$1
| RewriteCond %{HTTP_HOST} !^site.ru$ RewriteRule ^(.*)$ http://site.ru/$1 |
RewriteCond %{HTTP_HOST} !^site.ru$ RewriteRule ^(.*)$ http://site.ru/$1
Первый для тех, у кого основной домен с www, второй – у кого без www. Соответственно в обоих примерах надо вместо «site» вписать название вашего домена.
Итак, чем же данные варианты лучше?
Очень просто, они проверяют не только отсутствие/наличие www в имени домена, но проверяют и имя домена на полное его соответствие.
Живой пример: Наверняка вы сталкивались с тем, что неожиданно сайт может проиндексироваться по служебному адресу на хостинге (такой адрес выдается, чтобы к сайту можно было обратиться до привязки вашего реального домена), какому-нибудь зеркалу или вообще ip-адресу! Так вот универсальные правила будут лишь верифицировать отсутствие/наличие www, при этом все равно, к какому домену обращается пользователь или поисковый робот.
Так вот воспользовавшись продвинутым вариантом, вы на 146% будете уверены, что ваш сайт будет доступен только и исключительно по указному лично вами доменному имени и с учетом www. Я пользуюсь только таким вариантом и вам рекомендую!
В свете массового перехода сайтов на защищенный протокол, необходимо знать, как сделать редирект с http на https. Кстати, если вы еще не выбрали SSL-сертификат, вам стоит прочитать мой пост про .
Ниже я предлагаю вам несколько вариантов 301 редиректа с протокола http на https, которые могут работать либо не работать в зависимости от конфигурации именно вашего сервера, но какое-то из правил вам точно подойдет:
| RewriteCond %{HTTPS} !=on RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 |
RewriteCond %{HTTPS} !=on RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1
| RewriteCond %{SERVER_PORT} !^443 $ RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} |
RewriteCond %{SERVER_PORT} !^443$ RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI}
| RewriteCond %{ENV:HTTPS} !on RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} |
RewriteCond %{ENV:HTTPS} !on RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI}
| RewriteCond %{HTTP:X-HTTPS} !1 RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 |
RewriteCond %{HTTP:X-HTTPS} !1 RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1
RewriteCond %{HTTPS} off RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI}
Редирект с протокола https на http (честно, не знаю, зачем вам может это понадобиться):
| RewriteCond %{HTTPS} =on RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1 |
RewriteCond %{HTTPS} =on RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1
Недавно я написал очень подробную инструкцию . Если вы планируете переезд с https на https, вы обязаны ее прочитать!
Внесу некоторую ясность в непонятную абракадабру:
- RewriteCond обозначаем условие, при совпадении с которым будет выполнено правило RewriteRule. С помощью регулярных выражений задаются шаблоны строк.
- Переменные сервера:
- %{REQUEST_URI} — часть урла без доменного имени и GET-параметров, например, для страницы, которую вы сейчас читаете: blog/post/4393 ,
- %{HTTP_HOST} — хост или доменное имя, например: сайт
- %{QUERY_STRING} — строка с набором GET параметров, то есть часть урла после знака вопроса (и до решётки якоря, если он есть).
- %{REQUEST_FILENAME} — полный путь в файловой системе сервера к файлу или скрипту соответствующим этому запросу..php , а вот в файловой системе сервера это страшная строка /var/www/сайт/data/www/сайт/index.php .
Бывает, делая редирект, вы получаете неожиданный результат, например, хотели в адресе http://site.ru/page-name?post=17434801_4060 убрать параметры post=17434801_4060 , указали соответствующие правила (о них ниже будет написано), а в итоге получили строку http://site.ru/usr/local/www/site.ru/www/page-name — от параметров избавились, но получили странный адрес. Это все потому, что вы не указали в начале файла после RewriteEngine On директиву RewriteBase /, которая устанавливает конкретный, базовый URL для преобразований в контексте каталога.
- Метасимволы используются для задания групп символов или «меток» в шаблоне:
- ^ — метка начала строки,
- $ — метка конца строки,
- ! – отрицание,
- \ — экранирующий слеш, позволяет считать следующий за ним метасимвол обычным символом,
- . – точка, обозначает любой символ, но только один,
- () – группировка.
- Модификаторы ставятся после обычных символов, метасимволов или их групп и расширяют возможности использования шаблонов:
- ? — символ повторяется 0 или 1 раз,
- * — Повторяется от 0 до 65536 раз,
- + — Повторяется от 1 до 65536 раз.
- Флаги определяют дополнительные опции для данного правила и перечисляются в квадратных скобках через запятую:
- NC — (nocase) отключает проверку регистра символов.
- R — (redirect) останавливает процесс преобразования и возвращает результат браузеру клиента как редирект на данную страницу (302, MOVED TEMPORARY). С данным флагом можно указать другой код результата, например R=301 возвратит редирект с кодом 301 (MOVED PERMANENTLY). Как вы понимаете, это то самое, что нам и надо.
- L — (last) останавливает процесс преобразования, и текущая ссылка считается окончательной.
Самый популярный случай — 301-редирект с index.php (html) на главную страницу. На 90% сайтов встречается проблема дублирования главной страницы по адресам http://site.ru и http://site.ru/index.php (или index.html, index.htm или любой другой вариант, не принципиально, а то и все сразу). Где-то это явно, когда, например, ссылка из логотипа ведет на site.ru, а ссылка в меню ведет на site.ru/index.php, где-то не явно, когда дубль находится при вводе адреса с index.php вручную. Важно просто решить проблему. И я предлагаю универсальный вариант, вот он:
| RewriteCond %{THE_REQUEST} ^{3 ,9 }\ /index\.(php|html|htm)\ HTTP/ RewriteRule ^(.*)index\.(php|html|htm)$ $1 |
RewriteCond %{THE_REQUEST} ^{3,9}\ /index\.(php|html|htm)\ HTTP/ RewriteRule ^(.*)index\.(php|html|htm)$ $1
Просто вставьте этот код без изменений после строки после строки «RewriteEngine On» и нет проблем!
Многие, кто начинает бороться с дублями на сайте, задаются вопросом, а откуда берутся такие вот ссылки , которые дублируют основную страницу http://site.ru/page-name.html&post=-1234567_8901 ? Откуда взялась приставка &post=-1234567_8901 – это «добро» берется из вконтакте, когда кто-то делится ссылкой на ваш сайт у себя на стене, в группе или паблике, то автоматически добавляется подобная строка, видимо, для отслеживания какой-то статистики.
Чтобы избавиться от этой ерунды раз и навсегда необходимо добавить в htaccess:
RewriteCond %{REQUEST_URI} ^(.*)\&sa= RewriteRule ^(.*)\&sa=(.*)$ $1
Как видите, никакой разницы между этим и предыдущим случаем нет, пусть у вас в url"е будет &post= или &sa= или что угодно — решение одинаковое, просто надо заменить очевидные части кода. Понятно же, правда?
Избавляемся от параметров или меток в адресе
Вопрос задавался и в комментариях и много раз на форуме, потому нельзя его обойти стороной. Что делать вот с такими дублями: http://site.ru/?abrakadabra или более реальный случай http://site.ru?utm_source=twitterfeed&utm_medium=twitter
Данный случай немного отличается от следующего пункта, где мы будем избавляться от параметров для php-скрипта, так как тут обычный адрес и параметры в скрипт мы не передаем. Вот решение:
RewriteCond %{QUERY_STRING} ^lang=ru$ RewriteRule ^(.*)\.php\?(.*)$ $1\.php
%{QUERY_STRING} — это строка с набором переменных для PHP, часть урла после знака вопроса (и до решётки якоря, если он есть).
Вызываем url — http://site.ru/index.php?lang=ru
RewriteCond %{QUERY_STRING} ^lang=ru
$
Запрашиваемый url попадает под это правило, других правил нет, поэтому будет выполнен RewriteRule строкой ниже.
RewriteRule ^(.*)
\.php\?(.*)
$ $1
\.php
Исходный url: http://site.ru/index
.php?lang=ru
Шаблон разборки url’а: ^(.*)
\.php\?(.*)
$
URL будет разобран по переменным: $1
= http://site.ru/index
, $2
= lang=ru
и собран обратно уже в виде http://site.ru/index
.php ($1
\.php)
А далее будет 301 редирект на новый url.
Пример правил при смене структуры сайта
| RewriteRule ^post/category/(.*)$ blog/category/$1 RewriteRule ^post/(.*)$ blog/post/$1 |
RewriteRule ^post/category/(.*)$ blog/category/$1 RewriteRule ^post/(.*)$ blog/post/$1
Вот такие строки мне пришлось добавить в htaccess файл, когда я сменил структуру своего блога.
Info/post/category/seo, что как-то ломало логику в структуре – ведь блог это только часть сайта, но почему-то посты принадлежат сайту, а не блогу, а категории принадлежат постам, что тоже совсем нелогично..info/blog/category/seo — теперь блог как отдельный раздел сайта, а посты принадлежат ему, и категории принадлежат блогу, а не постам.
Из этого же примера видно, что важно соблюдать последовательность правил. Если бы я поменял строки местами, то есть впереди бы шла строка RewriteRule ^post/(..info/blog/post/category/seo а не как надо на https://сайт/blog/category/seo.
И последний пример — разбор частой ошибки с адресом от корня сервера
Например, вы решили исправить такую проблему, когда страница категории доступна по двум адресам http://site.ru/razdel/podrazdel/index.php и http://site.ru/razdel/podrazdel/. Второй url является правильным и основным, а url с index.php на конце является полным дублем, от которого необходимо избавиться.
Для того чтобы сделать редирект с index.php на категорию вы прописываете правило:
RewriteEngine On RewriteBase /
301-редирект со страницы на страницу, на новый адрес
Самый простой случай, когда надо сделать редирект одной страницы на другой адрес. Если же вам надо сделать редирект для нескольких страниц, то придется писать несколько правил, но в этом случае лучше воспользоваться шаблонами, описанными выше. Есть несколько совершенно идентичных вариантов синтаксиса:
| Redirect 301 /page-name1.html http://site.ru/page-name2.html Redirect permanent /page-name1.html http://site.ru/page-name2.html RedirectPermanent /page-name1.html http://site.ru/page-name2.html |
Redirect 301 /page-name1.html http://site.ru/page-name2.html Redirect permanent /page-name1.html http://site.ru/page-name2.html RedirectPermanent /page-name1.html http://site.ru/page-name2.html
Выбирайте один из трех, а лично я предпочитаю первый вариант — он короче, проще и понятнее. Кстати, здесь site.ru может быть не обязательно тем же самым доменом, но любым другим.
На этом закончим с.htaccess и перейдем к PHP.
Permanent Redirect 301 с помощью PHPОбычно PHP редирект я использую, когда возникают трудности с.htaccess или оказывается так, что функция на php оказывается более логичной и понятной.
Сам синтаксис 301 редиректа на php выглядит следующим образом:
| header (); header ("Location: http://site.ru" ); die("Redirect" ); |
header("HTTP/1.1 301 Moved Permanently"); header("Location: http://site.ru"); die("Redirect");
Эти строки сообщают браузеру клиента, что с какой-то запрошенной страницы необходимо произвести перманентный редирект на адрес http://site.ru. При этом http://site.ru может являться не только адресом главной страницы текущего сайта, но может быть и любым другим сайтом. Если же что-то пошло не так и произошла ошибка, то в окне браузера мы увидим надпись «Redirect».
Функция, позволяющая убрать определенный кусок из url
| if (strpos($_SERVER["REQUEST_URI" ], "http://сайт" ) !== false) { $real_page_url = "http://сайт" .str_replace ("/http://сайт" , "" , $_SERVER["REQUEST_URI" ]); header ("HTTP/1.1 301 Moved Permanently" ); header ("Location: $real_page_url" ); die("Redirect" ); } |
if (strpos($_SERVER["REQUEST_URI"], "http://сайт") !== false) { $real_page_url = "http://сайт"..1 301 Moved Permanently"); header("Location: $real_page_url"); die("Redirect"); }
Однажды у меня возникла проблема, что в панели вебмастера вылезла куча 404 ошибок, адреса этих страниц были вида https://alaev..е. откуда-то в адресе появился дублирующий адрес сайта. И тогда я написал функцию, которая проверяет, есть ли в URI (заметьте, не URL, а URI) вхождение «http://сайт», и если присутствует, то вырезаем из адреса этот кусок и записываем результат в переменную $real_page_url, а потом делаем 301-редирект на верный адрес из переменной.
Функция, убирающая конечный слеш из url
| if (($_SERVER["REQUEST_URI" ], - 1 , 1 ) == "/" ) { $requested_url = rtrim($requested_url, "/" ); header ("HTTP/1.0 301 Moved Permanently" ); header ("Location: $requested_url" ); die("Redirect" ); } |
if (($_SERVER["REQUEST_URI"], - 1, 1) == "/") { $requested_url = rtrim($requested_url, "/");header("HTTP/1.0 301 Moved Permanently"); header("Location: $requested_url"); die("Redirect"); }
Вот такая вот простейшая функция, которая смотрит, есть ли в запрошенном адерсе страницы слеш на конце, и если он есть, то слеш обрезается и происходит 301-редирет на адрес без слеша.
Существует еще масса вариантов, позволяющих отдавать команду перенаправления на разных языках программирования, типа ASP, Ruby on Rail и т.д., но я с этими языками не знаком, потому не буду тут умничать и пудрить вам мозги. Еще возможны редиректы при помощи метатега meta refresh, а так же редиректы на javascript – но это участь нечистых на руку дорвейщиков, а поисковики эти редиректы не понимают, они получаю ответ от сервера 200 OK. Так что эти варианты мы не рассматриваем.
Permanent Redirect 301 для сервера nginxПомните я писал про зеркало моего сайта, доступного по ip? В итоге проблему решили редиректом, прописанным в конфигурационном файле сервера, обычно он расположен тут /etc/nginx/nginx.conf. Там прописали вот такие строки:
| server { listen 1.2.34.123:80 default; server_name _; rewrite ^/(.*)$ http://site.ru/$1 permanent; } |
server { listen 1.2.34.123:80 default; server_name _; rewrite ^/(.*)$ http://site.ru/$1 permanent; }
Здесь говорится о том, что если идет обращение в ip-адресу через 80-ый порт, то необходимо делать permanent redirect на site.ru.
Однако техподдержка не рекомендовала мне так поступать со словами: «Более корректно будет настроить HTTP-сервер таким образом, чтобы он просто закрывал соединение, если к нему обращаются по адресу, который не указан явным образом в конфигурации HTTP-сервера, это наиболее надёжный, простой, безопасный и наименее требовательный к ресурсам сервера вариант. Через некоторое время страницы, которые будут недоступны, скорее всего, будут выкинуты из индекса поисковых систем.»
Следующий совет был такой: «Когда потребуется просто закрывать соединение вместо перенаправления, то укажите вместо строки "rewrite ^/(.*)$ http://site.ru/$1 permanent;" такую строку "return 444;". Затем выполните: "invoke-rc.d nginx reload"».
Вдруг это кому поможет.
Примеры редиректов в самых распространенных случаях
Редирект для домена www.site.ru на site.ru
server { listen 80; server_name site.ru; rewrite ^ http://www.site.ru$request_uri? permanent; }
Редирект с адреса http://site.ru/index.php на http://site.ru/
| location = /index.php { if ($request_uri = /index.php) { rewrite ^ http://$host? permanent;#301 redirect } fastcgi_pass unix:/tmp/fastcgi.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } |
location = /index.php { if ($request_uri = /index.php) { rewrite ^ http://$host? permanent;#301 redirect } fastcgi_pass unix:/tmp/fastcgi.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; }
Вот как-то так. Я в настройках конфигов для nginx не силен, всегда обхожусь настройками апача, так что, если у вас появились какие-то вопросы по nginx, то я вряд ли смогу вам помочь...
Как проверить HTTP заголовки и статусы ответа сервераЯ хотел в этом разделе описать различные сервисы и плагины для проверки ответа сервера, но понимаю, что данный пост уже настолько большой по объему, что придется ограничиться просто ссылками на расширения для браузеров Chrome и Firefox.
Дополнение HttpFox для Firefox
HttpFox (вот ссылка на аддон) — это мой любимый инструмент отслеживания http-заголовков. HttpFox построчно показывает ход загрузки страницы, что позволяет отслеживать, например, цепочки редиректов и вообще порядок и скорость загрузки страницы. Если вы пользуетесь Мозиллой, то однозначно рекомендую.
Расширение HTTP Headers для Chrome
Сам я не пользуюсь расширением HTTP Headers (вот ссылка на него), но интернеты мне посоветовали обратить внимание именно на него. Если у вас есть варианты получше, пожалуйста, отпишитесь в комментариях.
На этом я завершаю свой ужасно длинный и нудный пост, друзья.
Спасибо, что дочитали его до конца, я надеюсь, он оказался для вас реально полезным.
Часто в веб разработке требуется делать переадресации с одной страницы (например, устаревшей) на другую. При этом переадресация может выполняться разными методами - как с потерей веса страницы, так и без нее. Но об этом подробнее.
Как известно, любая страница со временем индексируется и имеет свой вес в сети. Если страница становится не актуальной, ее конечно можно удалить, но пользователи, которые перешли по ней, попадут на не существующий раздел сайта и в итоге его покинут. Правильнее считается на такие страницы делать 301 редирект на актуальные разделы сайта. Во-первых пользователь не увидит ошибку и вес старой страницы полностью передастся новой.
Переадресацию страниц можно делать разными методами. Рассмотрим основные.
301 редирект через.htaccess
В корне вашего сайта есть файл (если его нет - создайте) под названием.htaccess. Откройте его на редактирование и используйте один из следующих способов.
Redirect permanent и Redirect 301 - легко делает 301 редирект с одной страницы на другую (или сайта). Первой идет старая ссылка сайта (заметьте - без домена), второй - ссылка на новую страницу (которая может быть этим же сайтом или вообще новым).
Примеры:
Redirect permanent /staraya-stranica.php http://newsait.ru/novaya-stranica.php
(здесь просто переадресуем с устаревшей страницы на новую)
Redirect 301 / http://newsait.ru/
(здесь / означает, что все начиная с главной страницы сайта и всех его подстраниц (поддиректорий) будет переадресовываться на новый домен; т.е. фактически переадресация с оного домена на другой.)
RewriteRule редирект - более сложный редирект, чем предыдущие варианты. Требует для правильной работы подключение модуля mod_rewrite на хостинге (обычно всегда включен). Часто этот метод используют для переадресации страниц с www на такие же без www и обратно. Рассмотрим их:
Редирект домена с www на не-www
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.(.*)
RewriteRule ^(.*)$ http://%1/$1
Редирект с не-www на домен с www
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.(.*)
RewriteRule ^(.*)$ http://www.%1/$1
301 редирект с домена на домен и исключением для ссылки /market/vm2_market.xml. Т.е. все запросы (кроме /market/vm2_market.xml), со старого домена на новый будут выполняться.
RewriteEngine on
301 Все запросы (кроме /market/vm2_market.xml и ссылки /texts (и всеми ее "подссылками")), со старого домена на новый будут выполняться. Также здесь работает правило переадресации определенной подссылки (RedirectMatch 301)
RewriteEngine on
RedirectMatch 301 ^/texts/data/msg/(.*)\.png$ http://olddomen.ru/texts/data/rimage/msg.php?id=$1
RewriteCond %{REQUEST_URI} !^/texts*
RewriteCond %{REQUEST_URI} !^/market/vm2_market.xml$
RewriteRule ^(.*)$ http://newdomen.ru/$1
RedirectMatch 301 - еще один хороший метод редиректа, он похож на Redirect 301, но имеет больший функционал. А именно, с его помощью можно делать редиректы на основе регулярных выражений.
Примеры:
RedirectMatch 301 ^/olddirectory/ http://сайт/newdirectory/
(Здесь переадресует всю директорию на новую)
RedirectMatch 301 ^(.*)$ http://сайт
(Переадресует все страницы со старого домена на новый с помощью 301 редиректа (вес также передается на новый сайт))
RedirectMatch 301 (.*)\..php
(Смена страниц с html расширения на php расширение)
RedirectMatch 301 /dirA/(.*)\..php
(Запускает перенаправление из директории dirA в директорию dirB только при обращении к PHP скриптам.
.php -> http://сайт/dirB/page.php - сработает
http://сайт/dirB/page.html - не сработает)
Синтаксис для регулярных выражений
. - Точка заменяет произвольный символ.
- обозначает перечень символов, совпадающих с буквами a, b, или с.
[^abc] - перечень символов, которые не входят в указанных диапазон. Совпадёт с любым символом, кроме a, b, или с.
* - означает, что предшествующий символ может повторяться (0 или более раз).
* - команда найдёт идущие подряд символы из заданного набора.
[^abc]* - с точностью до наоборот.
.* - заменяет абсолютно любой набор символов. ".*" - найдёт все подстроки между кавычками.
^ - начало строки (в том случае, если используется в начале выражения).
$ - обозначает конец строки.
\w - буква, цифра или подчёркивание _.
\d - заменяет любую цифру.
\D - заменяет любой символ, но не цифру.
- заменяет любую цифру.
- любая буква от a до z (весь латинский набор символов) в нижнем регистре.
- любая буква от A до Z в ВЕРХНЕМ регистре.
- любая буква от a до Z в любом регистре.
- то же самое.
Спецсимволы, используемые в правилах и их значения.
^ - спецсимвол начала строки;
$ - спецсимвол конца строки;
! - спецсимвол отрицания;
. - точка, заменяет любой символ, но только один;
() - группировка;
\ - «экранирующий» слеш, следующий символ после него считается обычным, а не спецсимволом.
Модификаторы используются после обычных, спецсимволов или их групп и позволяют расширить возможности шаблонов для срабатывания правил.
? - символ повторяется 0 или 1 раз.
+ - повторяется от 1 до 65536 раз.
* - повторяется от 0 до 65536 раз.
Флаги, задают доп. опции для используемого правила. Перечисляются в квадратных скобках через запятую, скажем или .
NC - флаг NoCase, отключающий проверку регистра символов при срабатывании правила.
R - флаг Redirect, производит процесс остановки изменения URL-адреса и возвращает результат. Чаще всего используется значение R=301, но возможны и другие для временных перенаправлений (302, MOVED TEMPORARY).
L - флаг Last, останавливает формирования URL-адреса и строка считается окончательной.
Редирект через php. Если у вас обычная php страница, которую надо переадресовать на новый адрес, то можно обойтись без.htaccess
Пример:
Редирект через javascript. Также переадресацию можно сделать и на обычном javascript (правда без передачи веса страницы).
Пример:
window.location="http://сайт/category/";
(обычная переадресация на страницу сайта)
alert("Сейчас вы будете переадресованы!"); window.location="http://сайт/category/";
(обычная переадресация на страницу сайта перед которой пользователю выводится сообщение)
Мы выпустили новую книгу «Контент-маркетинг в социальных сетях: Как засесть в голову подписчиков и влюбить их в свой бренд».
В этой статье мне хотелось не только дать вам готовый код, но и разложить всё по полочкам, чтобы вы могли ориентироваться и в технической составляющей кода, и в условиях, когда стоит или не стоит его применять.
301 Permanent Redirect / 301 редирект…
… это переадресация пользователя на другой адрес страницы или домена. Этот код ответа сервера означает, что страница и ресурс переехали навсегда и теперь доступны в другому адресу.
Есть мифы, связанные с : например, что при редиректе не передаётся PR страницы, но этот миф был развенчан одним из вебмастеров Google Джоном Мюллером в своем блоге . Или что вместо редиректа можно использовать 302 Temporary Redirect.
Существует целый класс 3хх редиректов. Наиболее часто используются коды 301 и 302 - они как двойняшки, которые вроде бы и похожи, но всё-таки различаются. А для поискового робота это два совершенно разных человека, и трактуются такие ответы сервера по-разному:
Как эти коды отразятся на выдаче:
- При 301 редиректе в поисковой выдаче начинает отображаться новый URL, но это может занять некоторое время. Google советует сохранять статус страницы в течение года.
- При в поиске сохраняется старый URL страницы, но через 6 месяцев использования 302 редиректа поисковая система начинает считать его за постоянный 301, т.к. временное перенаправление не зря названо «временным», а полгода - достаточно большой срок.
Из-за подобных ошибок вебмастеров и злоупотребления 302 редиректом в неэтичных целях SEO-специалисты очень не советуют использовать его на своём сайте, ведь даже за небольшое подозрение в черном SEO вы можете схлопотать серьезный штраф. Давайте лучше разберемся как можно настроить легальный 3 01 редирект в
Файл.htaccess - это файл конфигурации HTTP-сервера, наподобие Apache. С его помощью задается большое количество дополнительный параметров и разрешений веб-сервера, распространяет свои права только на каталог, в котором располагается, и его дочерние подкаталоги.
Самый простой пример редиректа: с сайта на сайтRedirect / www.example.com
www.example.com - сайт, на который мы перенаправляем запрос пользователя.
Чуть более сложный пример - если мы хотим сделать редирект со страниц нашего сайта на другой сайт. Или, например, сделать редирект на главную страницу.
Redirect /semantica сайт/
Redirect /semantica/blog сайт/blog
Redirect 301 /kernel сайт/
Что всё это значит:
1 строка - при обращении к странице www.example.com/semantica будет открываться сайт сайт/
2 строка - при обращении к http://www.example.com/semantica/blog будет открываться сайт/blog
3 строка - веб-сервер будет отдавать код 301 о постоянном переезде на новый URL
Теперь, когда вы примерно понимаете, как это работает, можно переходить на задачи посложнее.
Сложные редиректыДля сложных редиректов существует модуль mod_rewrite - это средство преобразования URL-адресов, использующее . Для редиректа используются три важные директивы: RewriteCond, RewriteRule и RewriteEngine.
RewriteEngine on | off
Положение on-off включает и выключает работу модуля.
2. RewriteCond - определяет условие какого-либо правила, при котором происходит преобразование. Сразу после директивы чаще всего идут переменные %{HTTP_HOST} и %{REQUEST_URI}, которые означают адрес сервера (например, example.ru) и ресурс, запрошенный в строке HTTP-запроса, соответственно.
3. RewriteRule - идёт после одного или нескольких RewriteCond. Это правило преобразования URI, которое применяется только при условии выполнения RewriteCond.
Синтаксис директивы RewriteRule выглядит следующим образом:
RewriteRule Шаблон Подстановка
Здесь стоит дать пояснение к используемым символам регулярного выражения, которое задает шаблоны строк:
Метасимволы используются для задания групп символов и меток в шаблоне:
- ^ - метка начала строки,
- $ - метка конца строки,
- \ - экранирующий слеш, позволяет считать следующий за ним метасимвол обычным символом,
- . - точка, обозначает любой символ, но только один,
- () - группировка.
- ! - отрицание,
Флаги определяют дополнительные опции для данного правила и перечисляются в квадратных скобках через запятую:
- NC - (nocase) отключает проверку регистра символов.
- R - (redirect) останавливает процесс преобразования и возвращает результат браузеру клиента как редирект на данную страницу (302, MOVED TEMPORARY). С данным флагом можно указать другой код результата, например R=301 возвратит редирект с кодом 301 (MOVED PERMANENTLY).
- L - (last) останавливает процесс преобразования, и текущая ссылка считается окончательной.
Теперь, зная эти правила, мы можем попытаться самостоятельно сделать редирект с помощью htaccess .
где site.ru - ваше доменное имя.
Если вы заметили, что к адресу основной страницы приклеивается что-то вроде &sa=123 456 или &crw=123 456 и подобное, просто замените буквенную часть в следующем коде
RewriteCond %{REQUEST_URI} ^(.*)\&sa= RewriteRule ^(.*)\&sa=(.*)$ $1
Пример: объясняем на пальцахКак с помощью 301 редиректа сделать так, чтобы по запросу site.ru/category/art1/zapis/ в строке адреса было site.ru/zapis/, то есть /category/art1 вырезалась бы из строки, но после вырезания строки показывалось содержимое site.ru/category/art1/zapis/?
RewriteCond %{ENV:REDIRECT_STATUS} ^$ RewriteRule ^category/art1/zapis/$ http://%{HTTP_HOST}/zapis/ RewriteRule ^zapis/$ /category/art1/zapis/ [L]
А теперь давайте подробнее разберем, что же тут написано и что вообще происходит.
Как известно mod_rewrit на apache постоянно просматривает список правил, пока URL можно хоть как-то изменить.
И не редко получаются бесконечные циклы.
Чтобы ограничить цикл выполнения правил одной итерацией, можно использовать конструкцию из первой строки. Она предает apache статус был ли выполнен редирект или нет и если да, то пропустить следующие правила. К слову, на nginx эта строка не нужна.
Вторая строка делает 301 редирект с www.site.ru/category/art1/zapis/ на www.site.ru/zapis/
Третья же строка говорит серверу, что если адрес вида www.site.ru/zapis/, то надо показывать то, что находится по адресу www.site.ru/category/art1/zapis/
Помните, что с великой силой редиректа приходит и великая ответственность, так что используйте полученный знания с умом.
В заключении хотелось бы по пунктам огласить условиях при которых стоит и не стоит использовать .htaccess переадресацию .
Когда редирект необходим
Редирект 301 - зачем он нужен? В процессе продвижения сайта может возникнуть ситуация, когда необходимо изменить url страницы. Причины тому могут быть разные: переезд на новый домен, склейка дублей страниц, или даже, не к ночи будут помянуты, санкции поисковых систем. Чтобы изменить url, используется перенаправление, правильно называющееся «301 Permanent Redirect».
Что такое 301 редирект?301 redirect действует на постоянной основе, передает со старой страницы на новую ссылочный вес, ТИЦ сайта и . Также, если сайт находится в каталоге Яндекс или DMOZ, страниц нового сайта в нем, разумеется, не будет. Помимо этого, используется 301 редирект на другой сайт, и перенаправление с одной версии сайта на другую. В частности так избавляются от проблем при индексации, возникающих из-за дублирования страниц сайта.
Избавление от дублей страниц также называют канонизацией.
Как настроить 301 редиректПри использовании некоторых CMS (систем управления контентом, или «движков» сайта) редирект можно настроить при помощи специальных плагинов. Однако более распространена практика настройки 301 редиректа посредством внесения изменений в файл.htaссess.
Несколько примеров использования 301 редиректа Cклеивания зеркал сайтаДля поисковой системы site.name и www.site.name – разные сайты. Один из них будет проиндексирован, второй же окажется дублем. Чтобы подобного не произошло, делают так называемое «склеивание» сайта. С сайта с «www» указывается перенаправление на сайт без «www». Это делается в файле.htaccess, с помощью следующей конструкции:
RewriteEngine On RewriteCond %{HTTP_HOST} ^www.vash-sait\.ru$ RewriteRule ^(.*)$ http://vash-sait.ru/$1
Если на начальном этапе этого не было сделано, и в индекс попала версия сайта с «www», стоит сделать обратное перенаправление.
RewriteEngine On RewriteCond %{HTTP_HOST} ^vash-sait\.ru$ RewriteRule ^(.*)$ http://www.vash-sait.ru/$1
Перенаправление на страницу с другим urlПри использовании ЧПУ ссылок иногда возникает ситуация, когда url необходимо изменить, но исходная страница уже находится в индексе. Чтобы не потерять позиции и вес при изменении ссылки, стоит установить перенаправление с исходной ссылки с на измененную.
RewriteEngine On RewriteRule ^(.*)url.html$ http://vash-sait.ru/new-url.html
Перенаправление на другой доменВ ситуации, когда необходимо сменить домен, это можно сделать без потерь позиций и веса. Для этого нужно установить 301 редирект со старого домена на новый.
RewriteEngine on RewriteCond %{HTTP_HOST} ^www\.staryy-sait\.ru$ RewriteRule ^(.*)$ http://novyy-sait.ru/$1 RewriteCond %{HTTP_HOST} ^staryy-sait\.ru$ RewriteRule ^(.*)$ http://novyy-sait.ru/$1
Редирект алиасов на основной домен сайтаЕсли для сайта используется несколько доменов (алиасов), зарегистрированных в разных доменных зонах, то во избежание дублирования контента, нужно установить 301 редирект на основной домен.
RewriteEngine On RewriteCond %{HTTP_HOST} ^vash-sait.com$ RewriteCond %{HTTP_HOST} ^www.vash-sait.com$ RewriteCond %{REQUEST_URI} !^/robots.* RewriteRule ^(.*)$ http://vash-sait.ru/$1
Убираем расширение с помощью 301 редиректаRewriteEngine on RewriteRule ^(([^/]+/)*[^.]+)$ /$1.html [L]
Перенаправление с index.php на главнуюВ некоторых случаях, главная страница сайта доступна по нескольким адресам одновременно. Это также негативно сказывается на продвижении, так как говорит о дублировании контента. Избавиться от этого можно, применив следующую конструкцию:
RewriteEngine On RewriteCond %{THE_REQUEST} ^{3,9}\ /index\.php\ HTTP/ RewriteRule ^index\.php$ http://vash-sait.ru/
Страницы, в url которых встречается слеш, и страницы, в которых этого символа нет, также могут быть признаны дублями. Следующим кодом устанавливается перенаправление со страниц без слэша на страницы со слэшем:
RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_URI} ^(.+)/$ RewriteRule ^(.+)/$ /$1
Редирект для url с параметрамиЕсли исходный адрес содержит какой-либо параметр (например, http://vash-sait.ru/articles.php?section=1. Параметр здесь "section=1"), то перенаправляющая конструкция будет иметь следующий вид:
RewriteEngine On RewriteCond %{QUERY_STRING} section=1 RewriteRule ^index.php http://vash-sait.ru/articles.php?
Про 301 редирект уже, наверное, сказано и пересказано множество раз в блогах, форумах и т.п. Но, как оказывается, не до всех эта информация вовремя доходит (тут я как бы намекаю на себя:). За более чем 3 года в сети я слышал про 301 редирект множество раз, иногда даже собирался его «попробовать», но давайте посмотрим фактам в лицо — так этого и не сделал. А зря! Все началось достаточно прозаически — у меня есть один сайт, который постоянно «колбасит» в плане индексации поисковиками. Вроде и ссылки там есть, и контент нормальный, а он все ни в какую не хочет стабильно работать. У меня уже почти закончились варианты подобного поведения, но тут я вспомнил про основы основ SEO и вообще продвижения — 301 редирект.
Беглый опрос в твиттере показал, что реально я чуть ли не один «забиваю» на этот важный момент. Большинство единогласно ответило, что в обязательном порядке устанавливает 301 редирект сразу при создании сайта. Более того, тут мне недавно попросили по разработке сайта добавить этот же самый 301 редирект для них, поскольку просьба пришла от продвигающей и конторы. Учитывая все эти моменты и «намеки судьбы» я понял 301 редиректу быть!
Зачем вообще нужен 301 редирект ? — спросите вы — есть несколько ситуаций в которых его можно применить:
Вообще 301 редирект нужен как для пользователей, так и для поисковых роботов — позволяет сориентировать тех и других, что есть новый сайт, домен, страница и без лишних вопросов переадресовывает их туда. Кроме того 301 редирект произведет склейку показателей сайтов и позволит не потерять позиции в поисковых системах.
Как сделать 301 редиректРешений для этой задачи есть множество, все зависит от того какими техническими средствами обладает ваш хостинг. Также в интернете есть много статей по 301 редиректу, которые можно почитать, я приведу лишь несколько, на мой взгляд, самых типичных ситуаций.
Простой редирект
Производится в файле.htaccess или httpd.conf для Apache. Самый простой вариант простого 301 редиректа для переадресации на новый домен выглядит следующим образом:
Redirect 301 /site1/page1.htm http://www.site2.com/page2.htm
Вот еще парочка примеров простого 301 редиректа:
Redirect permanent /test http://www.test.com/ Redirect permanent / http://enter.test.com/
Здесь при попадании пользователя или робота в директорию test он перенаправится на www.test.com, все остальные попадут на enter.test.com. Для этого 301 редиректа на хостинге должны быть включены модули mod_alias (для поддержки Redirect, RedirectPermanent и RedirectMatch).
301 редирект с помощью mod_rewrite в.htaccess
С модулем mod_rewrite вы сталкивались достаточно часто даже не подозревая этого. В частности речь идет про постоянные ссылки (permalinks) как полезный инструмент в seo оптимизации wordpress. Если в админке настроите эти самые ссылки и после этого зайдете в файл.htaccess, то обнаружите там целый ряд правил для переадресации через директиву RewriteRule. Кроме того нужно проверить чтобы была подключена опция FollowSymLinks.
Перенаправление домена с www на без-www
Options +FollowSymLinks RewriteEngine On RewriteCond %{HTTP_HOST} ^www.domain\.com$ RewriteRule ^(.*)$ http://domain.com/$1
Редирект запросов без-www на домен с www префиксом
Options +FollowSymLinks RewriteEngine On RewriteCond %{HTTP_HOST} !^www\.(.*) RewriteRule ^(.*)$ http://www.%1/$1
Вообще использование www в названии сайта само по себе устарело, но иногда до сих пор встречается. Если вы создаете новый сайт, то конечно сразу указываете везде без www, но если получили «готовый продукт», то нужно смотреть как домен отображается в выдаче Google и Яндекс — такой редитект и оставляете дабы ничего кардинально не менять.
301 редирект старого домена на новый:
RewriteEngine on RewriteBase / RewriteRule ^rewrite\.htm$ rewrite.html
Для замены всех.htm файлов.html файлами:
HTTP/1.1 301 Moved Permanently Location: http://www.newdomain.ru/newdir/newpage.htm
Для этого, например, в PHP используем:
Данный код лучше всего вставлять в начало PHP скрипта чтобы до него ничего не выводилось (echo или print). За пояснение спасибо автору этой статьи где также найдете информацию про установку редиректа на ASP, ColdFusion и т.п., просто с php самый популярный вариант.
Примечания по 301 редиректу
Напоследок пару моментов по 301 редиректу, которые нужно помнить и с которым я так или иначе столкнулся:
- Во-первых, последовательность правил редиректа учитывается. Так что если какое-то правило не выполняется, проверьте нет ли других редиректов и не мешают ли они.
- Во-вторых, помнить синтаксис и все особенности 301 редиректа достаточно сложно, поэтому иногда здорово помогает логика и перебор некоторых вариантов:) Хотя, конечно, лучше читать официальную документацию.
- В-третьих, после внедрения 301 редиректа обязательно проверьте правила на работоспособность, зайдите не только на главную, но и пройдитесь по разделам, страницам сайта дабы потом не было проблем с этим.
Если у вас есть что добавить по 301 редиректу — пишите:)
P.S. Постовой. В наше время каждый день появляется множество интересных интернет проектов. Хотите знать все про стартапы тогда читайте новый увлекательный блог StartupWay.
После аудита и оптимизации веб-проекта следует комплексная раскрутка сайтов в поисковых системах Google и Яндекс.