Как сделать редирект на мобильную версию сайта

Настраиваем редиректы для SEO

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

При настройке 301 редиректов помните о двух правилах:

1. Избегайте нескольких последовательных перенаправлений — они увеличивают нагрузку на сервер и снижают скорость работы сайта.
2. Располагайте редиректы от частных к глобальным. Например, сначала переадресация с одной страницы на другую, затем общий редирект на страницы со слешем. Это правило работает не в 100% случаев, поэтому с размещением директив нужно экспериментировать.

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

Это потребуется в следующих случаях:

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

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

• — адрес страницы от корня, без протокола и домена. Например, .
• — полный адрес страницы перенаправления, включая протокол и домен. Например, .

2. Избавляемся от дублей

Каждая страница сайта должна быть доступна только по одному адресу. Для этого должны быть настроены:

• редирект на страницы со слешем в конце URL или наоборот;
• главное зеркало — основной адрес сайта в поиске.

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

Переадресация на слеш или наоборот

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

Код 301 редиректа на страницы без слеша:

3. Настраиваем главное зеркало

Для начала нужно определиться, какой адрес будет являться основным для поиска. SSL-сертификат давно уже мастхэв. Просто установите его и добавьте правило в .htaccess. Не забудьте также прописать его в robots.txt.

Редирект на HTTPS

Определять, с «www» или без будет главное зеркало, можно несколькими способами:

• добавить сайт в Яндекс.Вебмастер в двух вариантах, в консоли отобразится информация, какой URL поисковик считает главным зеркалом;
• проанализировать выдачу и посмотреть, каких страниц сайта больше в индексе;
• для нового ресурса не имеет значения, с «www» или без будет адрес, выбор за вами.

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

Редирект с без www на www

4. Перенаправляем с одного домена на другой

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

Воспользуйтесь одним из вариантов кода:

или

Не забудьте поменять в коде «mysite1» и «mysite2» на старый и новый домен соответственно.

Частные случаи

Двойное перенаправление

Двойное перенаправление — перенаправление А, установленное для перехода на перенаправление Б. Возникает, в случае если страница, на которую по задумке автора должно переводить перенаправление А, оказалась переименована. Иногда создаётся умышленно в целях вандализма (т. н. дятлинга).

Для поиска двойных перенаправлений необходимо использовать одноимённую служебную страницу. Их можно исправлять вручную или с помощью скрипта RedirectManagement.

Разорванное перенаправление

Разорванное перенаправление — перенаправление, ведущее на несуществующую (как правило, удалённую) страницу.

Отмечается на одноимённой служебной странице. Исправляется путём удаления вручную или с помощью скрипта RedirectManagement.

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

Взаимное перенаправление

Взаимное перенаправление — перенаправление А, ведущее на перенаправление Б, который возвращает читателя к перенаправлению А.

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

Рекурсивное перенаправление

Рекурси́вное перенаправление, или реку́рсия, — перенаправление, перенаправляющее само на себя.

Иногда создаётся участниками как шутка или для вандализма, практического применения не имеет.

Мягкое перенаправление

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

См. ]

Эта информация расположена в ]

Читайте ]

и т. п.

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

Иногда к мягким перенаправлениям относят также обособленные ссылки внутри содержательной статьи — например, в графе «Возможно, вы имели в виду» в преамбуле.

Несколько примеров совмещения 2-х редиректов в один

Для избежания последовательных редиректов можно использовать совмещенные варианты.

301 редирект с www на без www и со слешем в конце URL

Комбинируем и

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

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

RewriteCond %{REQUEST_URI} !\?
RewriteCond %{REQUEST_URI} !\&
RewriteCond %{REQUEST_URI} !\=
RewriteCond %{REQUEST_URI} !\.
RewriteCond %{REQUEST_URI} !\/$
RewriteCond %{HTTP_HOST} ^(.*)$
RewriteRule ^(.*)$ http://%1/$1/ 

301 редирект с без www на с www и со слешем в конце URL

Комбинируем и

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

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

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

301 редирект с без www на с www и без слеша в конце URL

Комбинируем и

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

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

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

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

301 редирект с www на без www и без слеша в конце URL

Комбинируем и

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

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

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

RewriteCond %{REQUEST_URI} !\?
RewriteCond %{REQUEST_URI} !\&
RewriteCond %{REQUEST_URI} !\=
RewriteCond %{REQUEST_URI} !\.
RewriteCond %{REQUEST_URI} \/$
RewriteCond %{HTTP_HOST} ^(.*)$
RewriteRule ^(.*)\/$ http://%1/$1 

Использование уязвимости

Фишинг

Предположим, что целью является example.com. Он имеет страницу восстановления пароля по адресу example.com/forgot-password. Вы вводите адрес электронной почты и нажимаете кнопку «Forgot Password», и вам будет отправлено письмо со ссылкой для сброса пароля, и эта ссылка может выглядеть следующим образом

Если мы вмешаемся в параметр redirect и изменим его на

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

Сцепление с SSRF

Если вы ничего не знаете о SSRF, вы можете поискать об этом в Google. В любом случае, допустим, у нас есть цель — example.com, и вы обнаружили ошибку SSRF на https://example.com/?get-image=https://images.example.com/cat.jpg. По сути, мы хотим заставить сервер сделать запрос от нашего имени. Мы можем изменить значение параметра get-image, и сервер сделает запрос к этой конечной точке. Но в этом случае он ограничивает запросы своим собственным (под) доменом (ами), например images.example.com. Это означает, что вы можете сделать запрос на * .example.com (Любой поддомен) в качестве сервера и не можете получить доступ ни к чему вне этой области. Допустим, вы также обнаружили ошибку Open Redirect на https://test.example.com/redirect_url=https://www.example.com/, теперь вы можете связать их вместе, чтобы заставить SSRF работать для любого домена, например

Сначала мы используем уязвимость Open Redirect, изменяя параметр redirect_url

Затем мы можем использовать это с SSRF, добавив открытый URL-адрес Open Redirect сверху в качестве параметра get-image.

Теперь это заставит сервер сделать запрос на один из его собственных поддоменов (test.example.com), а затем он будет перенаправлен на attacker.com, чтобы сработала ошибка SSRF.

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

Чего не стоит делать с редиректами?

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

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

2. Перенаправление на несуществующие страницы. Необходимо, чтобы страница, на которую происходит редирект, существовала и отображалась с кодом 200 (нет ошибок).

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

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

5. Часто менять редиректы. Это как в жизни, если вас постоянно переадресуют разным людям, то закрадывается некое подозрение. Поэтому, старайтесь тщательно продумывать структуру ваших url адресов.

6. Если тексты страниц сильно отличаются. Представьте себе, что вы пытаетесь открыть страницу с мемами о котятах, а вас переадресует на страницу о физике. Вряд ли бы вы отнеслись к такой ситуации позитивно. Аналогично, поисковики воспринимают подобные редиректы. Конечно, существуют нюансы, например, код 302 на страницу «сайт чинится». Однако, не стоит подобным злоупотреблять.

Теперь, вы знаете что такое редирект, а так же некоторые важные особенности.

• Нативная реклама
• Nofollow, Noindex: что это такое и как использовать

Зачем нужен .htaccess и где его искать

Файл нужен для более гибкой настройки сервера под задачи оптимизатора. Задавать правила в .htaccess не стоит, если у вас есть доступ к главному конфигурационному файлу сервера .httpd.conf или apache.conf (название зависит от настроек операционной системы). Изменения в нем вступают в силу быстрее, запросы не перегружают сервер. Однако очень часто такого доступа нет, например, в случае с виртуальным хостингом. Тогда приходится прописывать нужные настройки через .htaccess.

Возможности .htaccess для оптимизации сайта:

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

Где искать и как редактировать

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

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

Некоторые CMS дают возможность редактировать файл через административную панель. В Битриксе его легко можно найти в разделе Контент — Файлы и папки:

В WordPress редактировать .htaccess можно с помощью модулей плагинов Yoast SEO и All in One SEO Pack.

Если файл .htaccess отсутствует, создайте его в текстовом редакторе и разместите в корневой папке сайта или в нужном каталоге (потребуется доступ к хостингу или по ftp).

Оптимизируем работу сайта

Скорость загрузки сайта — один из факторов ранжирования в поисковых системах. Увеличить ее можно в том числе с помощью директив в .htaccess.

14. Сжимаем компоненты сайта при помощи mod_gzip или mod_deflate

Сжатие файлов, с одной стороны, увеличивает скорость загрузки сайта, но с другой — больше нагружает сервер. В .htaccess можно включить сжатие при помощи двух модулей — mod_zip и mod_deflate. Они практически идентичны по качеству сжатия.

Синтаксис модуля Gzip более гибкий и он умеет работать с масками:

В mod_deflate вы перечисляете типы файлов, которые нужно сжать:

15. Усиливаем кэширование

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

В примере срок жизни кэша ограничен одной неделей («1 week»), вы можете указать свой срок в месяцах (month), годах (year), часах (hours) и т.д.

Другой вариант кода:

Для кэширования доступны следующие типы файлов:

• image/x-icon;
• image/jpeg;
• image/png;
• image/gif;
• application/x-shockwave-flash;
• text/css;
• text/javascript;
• application/javascript;
• application/x-javascript;
• text/html;
• application/xhtml+xml.

Все стандартные редиректы в nginx

Рассмотрю типовой пример, когда у нас одновременно присутствуют следующие редиректы:

1. С http на https.
2. С www на без www для обоих протоколов.
3. Без слеша на конце на урл со слешем.

Наша цель будет реализовать все преобразования url в одном месте и выдать клиенту только один 301-й редирект.

server {
    listen 443 ssl http2;
    server_name site.ru;
    root /web/sites/site.ru/www/;
    index index.php index.html index.htm;
    access_log /web/sites/site.ru/log/access.log main;
    error_log /web/sites/site.ru/log/error.log;

    ssl_certificate		/etc/letsencrypt/live/site.ru/fullchain.pem;
    ssl_certificate_key		/etc/letsencrypt/live/site.ru/privkey.pem;

    location / {
	rewrite ^(*)$ $1/ permanent;
	try_files $uri/ /index.php?$args;
	}

    location ~* ^.+.(js|css|png|jpg|jpeg|gif|webp|ico|woff|txt)$ {
	access_log off;
	expires max;
	}

    location ~* ^/(\.ht|xmlrpc\.php)$ {
	return 404;
	}

    location ~ \.php$ {
	try_files  $uri =404;
	fastcgi_pass   unix:/var/run/php-fpm/php7-fpm.sock;
	fastcgi_index index.php;
	fastcgi_param DOCUMENT_ROOT /web/sites/site.ru/www/;
	fastcgi_param SCRIPT_FILENAME /web/sites/site.ru/www$fastcgi_script_name;
	fastcgi_param PATH_TRANSLATED /web/sites/site.ru/www$fastcgi_script_name;
	include fastcgi_params;
	fastcgi_param QUERY_STRING $query_string;
	fastcgi_param REQUEST_METHOD $request_method;
	fastcgi_param CONTENT_TYPE $content_type;
	fastcgi_param CONTENT_LENGTH $content_length;
	fastcgi_param HTTPS on;
	fastcgi_intercept_errors on;
	}

    location = /favicon.ico {
	log_not_found off;
	access_log off;
	}

    location = /robots.txt {
	allow all;
	log_not_found off;
	access_log off;
	}
}

server {
    listen 443 ssl http2;
    server_name www.site.ru;

    location ~* ^.+.(js|css|png|jpg|jpeg|gif|webp|ico|woff|txt)$ {
	return 301 https://site.ru$request_uri;
    }
    
    location / {
	rewrite ^/(.*)/$ /$1;
	return 301 https://site.ru$uri/;
    }
}

server {
    listen 80;
    server_name site.ru www.site.ru;

    location ~* ^.+.(js|css|png|jpg|jpeg|gif|webp|ico|woff|txt)$ {
	return 301 https://site.ru$request_uri;
    }
    
    location / {
	rewrite ^/(.*)/$ /$1;
	return 301 https://site.ru$uri/;
    }
}

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

Синтаксис .htaccess

Синтаксис файла простой: каждая директива (команда) начинается с новой строки, после знака # можно добавлять комментарии, которые не будут учитываться сервером. Изменения на сайте вступают в силу сразу, перезагрузка сервера не требуется.

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

Основные спецсимволы:

• ^ — начало строки;
• $ — конец строки;
• . — любой символ;
• * — любое количество любых символов;
• ? — один определенный символ;
• — последовательность символов, например, от 0 до 9;
• | — символ «или», выбирается или одна группа, или другая;
• () — иcпользуется для выбора групп символов.

Основные переменные:

• %{HTTP_USER_AGENT} — поле User-Agent, которое передает браузер пользователя;
• %{REMOTE_ADDR} — IP адрес пользователя;
• %{REQUEST_URI} — запрашиваемый URI;
• %{QUERY_STRING} — параметры запроса после знака ?.

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

Что такое редирект простыми словами

Редирект (англ. «Redirect») — это автоматическое перенаправление пользователей с одной страницы сайта на другую, причём как в пределах одного проекта, так и на внешние. Для поисковых систем редирект применяется для склейки адресов страниц.

У каждого редиректа есть свой номер, который отвечает за его функцию. Выделяют следующие виды:

• 300 редирект — множественный выбор;
• 301 редирект — перемещен навсегда;
• 302 редирект — документ найден;
• 303 редирект — смотри другое;
• 304 редирект — документ не изменился;
• 305 редирект — используй прокси;
• 306 редирект — не используется;
• 307 редирект — временный редирект;

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

Существует несколько способов сделать редирект. У каждого есть свои плюсы и минусы. Ниже мы рассмотрим каждый из них в отдельности с примерами.

Переадресация на https через htaccess

Если ваш сайт уже проиндексирован то перед настройкой редиректа вам нужно произвести склейку зеркал, а потом уже настраивать редирект. Это поможет минимизировать потери трафика и позиций . О том как это сделать написано тут.

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

Как пользоваться Notepad++ и настроить для него FTP-подключение я рассказывала в одной из прошлых статей, с которой вы можете ознакомиться по этой ссылке:

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

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

Понятие и назначение безопасного режима

В Windows 7 присутствуют диагностические режимы запуска операционной системы для решения тех или иных проблем. Один из них – безопасный или Safe mode (ещё называется режимом устранения сбоев) предназначен для выявления и устранения неполадок в Win 7, работе драйверов и аппаратных компонентов компьютера. В безопасном режиме запускается минимально возможный перечень процессов, служб и драйверов, необходимых для обеспечения работы операционной системы и основных аппаратных компонентов. Благодаря функционированию с ограниченными возможностями быстрее выявляются проблемы, ведь прикладное программное обеспечение не активно.

HTML Redirect: Useful Tips

• If you don’t define a new URL address for the redirect, HTML page will simply reload itself after the time specified. It can be useful when you need to refresh dynamic content.
• We’d advise you to avoid delays shorter than 3 seconds, as that makes it virtually impossible for the user to click the Back button on their browser.
• Be careful not to overuse HTML meta redirects: if your website has a ton of them, the search engines may think it contains spam and remove it from their index.
• You can also create redirects with PHP, JavaScript, Ruby on Rails, and Python Flask, as well as in the Apache, Nginx, and Lighttpd web servers.

Обеспечиваем безопасность сайта

Файл .htaccess предоставляет большие возможности для защиты сайта от вредоносных скриптов, кражи контента, DOS-атак. Также можно защитить доступ к определенным файлам и разделам.

5. Запрещаем загрузку картинок с вашего сайта

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

Осадите воришек при помощи этого кода:

Заменяете «mysite.com» на адрес вашего сайта и создаете изображение с любым сообщением о том, что красть чужие картинки нехорошо, по адресу . Это изображение и будет показано на стороннем ресурсе.

6. Запрещаем доступ

Целым группам нежелательных гостей с определенных IP-адресов, подсетей, а также вредоносным ботам можно запретить доступ на ваш ресурс при помощи следующих директив в .htaccess.

Для нежелательных User Agents (ботов)

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

Частный случай такого запрета — запрет для поисковых роботов. Если вас почему-то не устраивает правило в robots.txt, можно запретить доступ, например, роботу Google при помощи таких директив:

Для подсети

Вписываем маску сети в строку после «deny from».

Спамные IP-адреса можно вычислить в логах сервера или с помощью сервисов статистики. В административной панели WordPress отображаются IP-адреса комментаторов:

К определенному файлу

Вписываем название файла вместо «myfile.html» в примере. Пользователю будет показана ошибка 403 — «доступ запрещен».

Не лишним будет ограничить доступ к самому файлу .htaccess из соображений безопасности, а также рекомендуем после настройки всех правил поставить на файл права доступа 444.

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

Для пользователей, пришедших с определенного сайта

Вы можете заблокировать посетителей с нежелательных ресурсов (например, со взрослым или шокирующим контентом).

7. Защищаем доступ к определенному файлу или папке

Для начала создайте файл .htpasswd, пропишите в нем логины и пароли в формате user:password и разместите в корне сайта. В целях безопасности пароли лучше зашифровать. Это можно сделать при помощи специальных сервисов генерации записей, например, такого. Следующим шагом добавьте директории или файлы в .htaccess:

Защита паролем папки

Вместо «/pub/home/.htpasswd» укажите путь до файла .htpasswd от корня сервера. Рекомендуем проверить доступ после установки кода.

8. Запрещаем выполнение вредоносных скриптов

Следующая группа директив защищает сайт от так называемых «скриптовых инъекций» — инструмента хакерских атак:

Все попытки причинить вред вашему ресурсу будут перенаправлены на страницу ошибки 403 «доступ запрещен».

9. Защищаем сайт от DOS-атак

Один из способов защиты — ограничить максимально допустимый размер запроса (ограничение отсутствует по умолчанию).

Для этого прописываем в .htaccess размер загружаемых файлов в байтах:

В примере указан размер 10 Мбайт. Если вы хотите запретить загрузку файлов, пропишите число меньше 1 Мбайт (1048576 байт).

Также можно изучить возможности директив LimitRequestFields, LimitRequestFieldSize и LimitRequestLine в официальной документации.

Что такое RivaTuner Statistics Server? Как установить, настроить и пользоваться программой?

Видеоматериал

Создание и изменение перенаправления[править | править код]

Кнопка «Параметры страницы» в выпадающем меню.

Меню параметров страницы.

Чтобы создать перенаправление, создайте новую страницу (см. создание новых страниц) или измените существующую.

Когда вы будете в окне создания страницы (или окне редактирования, если правите существующую), вставьте следующий код в поле ввода текста:

#перенаправление [[названиестраницы]]

где названиестраницы является названием целевой страницы.

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

1. Откройте визуальный редактор.
2. Нажмите на кнопку «Параметры страницы», расположенную в выпадающем меню «Настройки страницы».
3. (при превращении страницы в перенаправление) Включите опцию «Перенаправить эту страницу на» и введите название целевой страницы.
4. (при изменении существующего перенаправления) Измените название целевой страницы на желаемое название.

Примечание: если вы не знаете как просмотреть перенаправление, читайте раздел «» ниже.

Межпространственные перенаправления

В общем случае, перенаправления между разными пространствами имён нежелательны. Их необходимость, если она неочевидна, рекомендуется обосновывать на странице перенаправления, дописав текст объяснения в конец страницы; в противном случае они могут быть удалены. Это объяснение не будет отображено при работе перенаправления, однако люди, открывшие страницу с целью разобраться в причинах её создания или для её удаления, заметят и прочтут его. Следующие случаи являются консенсусными исключениями:

1. Допустимы шорткаты из пространств имён «Википедия» и «Обсуждение Википедии» на страницы других пространств, если они являются общеузнаваемыми или имеют большое число ссылок (в частности, из описаний правок). Примеры: ВП:ЗАЯ, ВП:WPCHECK.
2. Допустимы перенаправления, необходимые для работы расширений MediaWiki или сторонних инструментов, а также перенаправления с имён, распространённых в большинстве других языковых проектов. Хорошим примером являлся WP:AWB до того момента, как «WP» не стал алиасом для «Википедия».
3. Перенаправления со страниц участников на их страницы обсуждения являются распространённой консенсусной практикой.
4. Допустимы перенаправления со страниц обсуждения модулей на страницы обсуждения шаблонов, если модуль написан для работы единственного шаблона, а также со страниц обсуждения MediaWiki на страницы обсуждения соответствующих документаций.
5. В силу размытости понятий, допустимы перенаправления между пространствами имён «Википедия» и «Справка».
6. Подстраницы активных участников могут являться межпространственными перенаправлениями, если это необходимо для облегчения навигации.