Внутрихостовая директива: оптимизация и безопасность веб-сервера

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

В SEO я с 2005 года, и доля проблем, которые лечатся не текстами и не ссылками, а десятью строками в конфигурации хоста, за это время не уменьшилась. Ниже — где эти строки лежат в Apache, nginx и .htaccess, в каком порядке они применяются, какие из них влияют на индексацию и скорость, что закрывают ради безопасности и как проверить, что написанное вами вообще сработало.

Где лежат внутрихостовые директивы

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

В Apache блок сайта выглядит как <VirtualHost *:443> и содержит внутри себя ServerName, DocumentRoot, вложенные блоки <Directory> и <Location>. В nginx та же роль у блока server { ... } с директивами server_name, root и вложенными location. Логика одинаковая, синтаксис разный.

Отдельная история — файл .htaccess. Это способ задать директивы уровня директории, не имея доступа к основной конфигурации: файл кладётся в папку сайта и читается Apache при каждом запросе. Именно с ним чаще всего работает владелец сайта на обычном хостинге. У nginx аналога нет вовсе: там всё правится в конфигурации и требует перезапуска.

Где	Что задаёт	Когда применяется	Нужен доступ
Глобальная конфигурация	Общие правила для всех сайтов сервера	При старте сервера	Root или панель управления
Блок VirtualHost или server	Настройки одного сайта	При старте сервера	Root или панель управления
Блок Directory или location	Настройки одного раздела сайта	При старте сервера	Root или панель управления
Файл .htaccess	Правила для папки и вложенных папок	При каждом запросе	Достаточно FTP

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

Порядок применения: почему правило не срабатывает

Самая частая жалоба звучит так: «правило написал, а оно не работает». Почти всегда причина в порядке.

• Директивы более узкого уровня перекрывают широкие. Правило в .htaccess подпапки отменяет правило из корня, если оно про то же самое.
• Правила перезаписи адресов выполняются сверху вниз. Первое сработавшее правило с флагом остановки прекращает обработку остальных.
• Директива AllowOverride может запрещать .htaccess вовсе. Если в конфигурации хоста стоит AllowOverride None, ваш файл просто не читается.
• Nginx перед Apache отдаёт статику сам. В типичной связке картинки, стили и скрипты не доходят до Apache, и правила из .htaccess к ним не применяются вообще.
• Кэш браузера хранит старый редирект. Постоянный редирект браузер запоминает и продолжает выполнять даже после удаления правила.

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

Один сайт — один адрес

Классическая ситуация: сайт открывается по адресу с www и без, по протоколу http и https, а иногда ещё и по IP-адресу сервера или техническому домену хостинга. Для поиска это несколько копий одного сайта, между которыми размывается вес и путается индекс.

Лечится директивами уровня хоста. Порядок такой:

Подробнее об этом — в статье «Поисковая оптимизация интернет-сайтов».

1. Выбрать основной адрес — с www или без, разницы для продвижения нет, важна только неизменность.
2. Настроить постоянный редирект со всех остальных вариантов на основной, одним шагом, без промежуточных переходов.
3. Проверить, что редирект отдаёт код 301, а не 302 и не цепочку из двух-трёх переходов.
4. Закрыть доступ по IP и по техническому домену хостинга — либо редиректом, либо отдачей кода 444 в nginx.
5. Указать основной адрес в Яндекс.Вебмастере и убедиться, что канонические ссылки на страницах ведут на него же.

Про цепочки редиректов. Схема, при которой http без www ведёт на http с www, затем на https с www, а оттуда на https без www, работает для человека и вредит сайту: каждый переход теряет часть веса, увеличивает время до первого байта и создаёт риск обрыва. Правило простое — от любого входного адреса до конечного не более одного перехода.

Редиректы и правила перезаписи

Редирект — самая используемая внутрихостовая директива и самый частый источник аварий. Разница между кодами ответа принципиальна и путается постоянно.

Код	Смысл	Когда применять	Что делает поиск
301	Перемещено навсегда	Смена адреса, склейка зеркал, объединение страниц	Заменяет старый адрес новым, переносит накопленные сигналы
302	Временно перемещено	Технические работы, временная замена страницы	Оставляет в индексе старый адрес
307	Временно, с сохранением метода запроса	Формы и API	Так же, как 302
404	Не найдено	Страницы никогда не было или она удалена без замены	Постепенно убирает адрес из индекса
410	Удалено навсегда	Осознанно удалённые разделы	Убирает адрес быстрее, чем 404

Помогу с продвижением: SEO-продвижение от Анатолия Кузнецова — вывожу сайты в топ Яндекса белыми методами.

Отдельно про массовые редиректы при переезде. Правило «всё старое на главную» — самая дорогая ошибка при смене структуры сайта: поиск трактует такой редирект как отсутствие соответствия и обнуляет накопленное. Каждый старый адрес должен вести на страницу с тем же смыслом, а если такой нет — отдавать 404 или 410. Список соответствий готовится заранее, а не в ночь переезда.

Если интересно направление с сайтами — базу даю в своём курсе:

8:14

Ещё один частый сценарий — переезд сайта на другой сервер. Файлы копируют, базу переносят, домен переключают, а конфигурацию хоста собирают заново с нуля, и все накопленные за годы правила остаются на старой машине. Внешне сайт работает, поэтому проблему замечают через две-три недели по падению трафика: перестали действовать редиректы со старых адресов, вернулись доступные копии с www, отвалились правила блокировки. Перед переездом нужно выгрузить действующую конфигурацию и .htaccess целиком и переносить их как часть сайта, наравне с файлами и базой.

Кэширование и сжатие на уровне хоста

Две директивы, дающие ощутимый прирост скорости без единой правки в коде сайта.

Сжатие. Сервер отдаёт HTML, CSS, JS и шрифты в сжатом виде — gzip или более экономный brotli. Объём передаваемых данных падает в три-четыре раза. Картинки и видео сжимать повторно не нужно: они уже сжаты своими форматами, и попытка даёт только нагрузку на процессор.

Тему разбирал отдельно: «Оптимизация сайта под мобильные устройства».

Заголовки кэширования. Директивы Cache-Control и Expires сообщают браузеру, сколько хранить файл локально. Разумные сроки различаются по типам файлов.

Тип файла	Срок хранения	Замечание
Картинки, шрифты	от 30 дней до года	Меняются редко
CSS и JS	от 7 до 30 дней	Обязательна версия в имени файла или в параметре
HTML страниц	от нескольких минут до часа	Долгий срок мешает видеть правки
Личный кабинет, корзина	не кэшировать	Иначе посетители видят чужие данные

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

Обработка ошибок — вопрос не только удобства

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

• Своя страница 404. С поиском по сайту, ссылками на основные разделы и понятным объяснением. Пустая страница сервера отправляет посетителя обратно в выдачу.
• Правильный код ответа. Красивая страница «ничего не найдено», отдающая код 200, — это «мягкая» ошибка: поиск считает адрес рабочей страницей и держит его в индексе. Проверяется только инструментом, глазами не видно.
• Страница 403. Появляется при блокировке доступа и не должна выглядеть как поломка сайта.
• Страница 5xx. При аварии сервер должен отдавать именно 503 с указанием повторить позже, а не 200 с текстом об ошибке: 503 сообщает роботу подождать и не выбрасывать страницы из индекса.
• Логирование. Отдельные логи по хосту позволяют увидеть всплеск 404 и 5xx до того, как о нём сообщит Вебмастер.

Безопасность: что закрывают на уровне хоста

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

• Служебные файлы. Резервные копии, дампы базы, файлы конфигурации, каталог .git. Оставленный в корне архив сайта — самый частый способ, которым сливают базы.
• Листинг директорий. Директива Options -Indexes закрывает просмотр содержимого папок без индексного файла.
• Выполнение скриптов в папке загрузок. Если через форму загрузили файл с расширением скрипта, он не должен исполняться.
• Скрытие версии сервера. ServerTokens Prod и server_tokens off убирают точную версию из заголовков ответа.
• Заголовки безопасности. X-Content-Type-Options, X-Frame-Options, Referrer-Policy, а на сайтах с оплатой — Strict-Transport-Security.
• Ограничение доступа к админке по IP. Работает, если у вас фиксированный адрес; иначе однажды заблокируете себя.

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

Блокировка ботов и ограничение нагрузки

Если нужна помощь по теме — мой курс по SEO.

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

1. Запрет по подсетям. Точечно и эффективно, если атака идёт с ограниченного диапазона адресов. Списки собираются по логам сервера, а не по данным аналитики.
2. Ограничение частоты запросов. В nginx это limit_req, задающий предел числа обращений с одного адреса в секунду. Работает против переборов и агрессивных парсеров.
3. Фильтрация по строке User-Agent. Полезна против ленивых парсеров и бесполезна против тех, кто представляется браузером.

Два предупреждения. Первое: никогда не блокируйте по признакам, под которые попадают роботы поисковых систем. Проверяйте принадлежность робота обратным запросом по IP, а не по названию в User-Agent — им прикрываются в первую очередь. Второе: правила блокировки в .htaccess и в конфигурации хоста регулярно теряются при обновлении панели управления или переносе сайта. Держите их в отдельном файле, ведите копию вне сервера и проверяйте раз в месяц, что блокировка действует.

Смежный материал по теме — «Внутренняя SEO оптимизация сайта».

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

Как проверить, что директива работает

Настройка считается сделанной не после сохранения файла, а после проверки ответа сервера.

• Код ответа и заголовки. Смотреть инструментом проверки ответа сервера в Яндекс.Вебмастере или консольной командой запроса заголовков. Браузер показывает конечную страницу и скрывает цепочку.
• Цепочка редиректов. Проверять от всех четырёх вариантов адреса: http и https, с www и без.
• Сжатие. В заголовках ответа должен быть Content-Encoding с указанием метода.
• Кэширование. Проверять заголовок Cache-Control отдельно для картинки, стиля и HTML — они настраиваются по-разному.
• Ошибки. Открыть заведомо несуществующий адрес и убедиться, что код именно 404, а не 200.
• Проверка синтаксиса до применения. И Apache, и nginx умеют проверять конфигурацию без перезапуска — ошибка в одной строке иначе роняет все сайты сервера.

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

Частые вопросы

Чем .htaccess отличается от настроек виртуального хоста? Уровнем и скоростью. Файл действует на папку и читается при каждом запросе, конфигурация хоста действует на весь сайт и читается при старте сервера. Возможности почти совпадают, но часть директив в .htaccess недоступна.

Почему правила из .htaccess не работают на nginx? Nginx этот файл не читает вовсе и никогда не читал. В связке nginx с Apache файл работает только для тех запросов, которые доходят до Apache, — то есть обычно не для статики.

С www или без — что лучше для продвижения? Разницы нет. Значение имеет только то, что вариант выбран один и все остальные ведут на него одним постоянным редиректом.

Можно ли закрыть сайт от лишних роботов через robots.txt? Файл robots — рекомендация, и её соблюдают только добросовестные роботы. Паразитный трафик режется на уровне сервера, а не рекомендацией.

Сколько хранить логи? Достаточно двух-трёх месяцев с ротацией. Этого хватает, чтобы разобрать всплеск нагрузки или найти дату начала атаки, и логи не съедают диск.

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

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

Коротко

• Внутрихостовые директивы задают поведение конкретного сайта: адрес, редиректы, кэш, ошибки, запреты; в Apache это блок VirtualHost, в nginx — блок server.
• Файл .htaccess даёт те же возможности без доступа к серверу, но читается при каждом запросе и не работает в nginx.
• Правило «не срабатывает» почти всегда объясняется порядком применения, запретом AllowOverride, отдачей статики мимо Apache или закэшированным старым редиректом.
• Один сайт должен открываться по одному адресу, а любой другой вариант — вести на него ровно одним переходом с кодом 301.
• Сжатие и заголовки кэширования дают прирост скорости без правок в коде; персональные страницы из кэша исключают явно.
• Страница 404 обязана отдавать код 404, а не 200: «мягкие» ошибки держат несуществующие адреса в индексе.
• Блокировки и запреты держат на уровне хоста, проверяют раз в месяц и никогда не применяют к проверенным роботам поисковых систем.

Если сайт открывается по нескольким адресам, отдаёт странные коды ответа или медленно откликается, а причина не находится, приходите на SEO-консультацию: проверим ответы сервера и цепочки редиректов вместе и составим список правок для вашего хостинга.