Хостинг, сервер и кэширование: скрытый фундамент SEO

Про хостинг вспоминают в двух случаях: когда сайт лёг и когда счёт за продление пришёл. В остальное время это «то, за что платим 300 рублей в месяц». А между тем сервер — единственный элемент SEO, который работает круглосуточно и влияет вообще на всё: на скорость загрузки, на то, сколько страниц робот Яндекса успеет обойти за сутки, на поведение пользователей и на то, останется ли сайт в индексе после недельного даунтайма. За 20 лет практики я видел десятки проектов, где переезд с дешёвого шареда на нормальный VPS давал больше прироста, чем полгода работы с контентом. В этой статье — как инфраструктура превращается в позиции, что мерить, что кэшировать и какие требования выставлять хостеру, чтобы потом не разгребать.

Почему сервер — это SEO, а не «айтишная тема»

Поисковая система не видит ваш дизайн и не читает ваши намерения. Она видит HTTP-ответы: код статуса, заголовки, время до первого байта, объём переданных данных. Всё, что делает сервер, — это отдаёт ответы. И качество этих ответов формирует три пласта факторов одновременно.

• Пользовательский пласт. Медленный ответ = долгая загрузка = отказы. Отказы и глубина просмотра — это поведенческие факторы, которые Яндекс учитывает напрямую и весомо. Сервер, отвечающий за 900 мс вместо 120 мс, добавляет почти секунду к каждому переходу пользователя по сайту — умножьте на 5 просмотров за сессию.
• Краулинговый пласт. Робот выделяет вашему сайту конечный ресурс — время и количество запросов. Чем дольше отвечает сервер, тем меньше страниц он успеет забрать за тот же интервал.
• Пласт доступности. Если сервер отдаёт 5xx или таймаутит, страницы вылетают из индекса. Не «понижаются» — вылетают. Это самый быстрый способ потерять трафик, который я знаю.

Важный нюанс: инфраструктурные проблемы почти никогда не диагностируются как инфраструктурные. Клиент приходит с формулировкой «трафик просел, наверное, фильтр» или «конкуренты обогнали». А в логах — 40% ответов дольше 2 секунд в вечерний пик. Поэтому в любой SEO-аудит серверная часть должна входить первым блоком, до семантики и текстов.

TTFB: главная метрика, которую все мерят неправильно

TTFB (Time To First Byte) — время от отправки запроса до получения первого байта ответа. Это чистая характеристика связки «сеть + сервер + приложение», без влияния фронтенда, картинок и скриптов. Если TTFB плохой, всё остальное уже не спасёт: никакая оптимизация изображений не вернёт вам потерянную секунду ожидания.

Из чего он складывается:

1. DNS-резолвинг — 10–80 мс. Медленный DNS-провайдер добавляет десятки миллисекунд к каждому первому запросу.
2. TCP-соединение — зависит от физического расстояния до сервера. Москва → Москва: 5–15 мс. Москва → Германия: 40–60 мс. Москва → США: 130–180 мс.
3. TLS-хендшейк — ещё 1–2 round-trip. С TLS 1.3 — один, с TLS 1.2 — два. Разница ощутима.
4. Обработка на сервере — время работы PHP/Python, запросы к базе, рендеринг шаблона. Здесь и живут основные потери на CMS-сайтах.

Ориентиры, которыми я пользуюсь на практике:

• до 200 мс — хорошо, дальше оптимизировать TTFB смысла мало, займитесь фронтендом;
• 200–500 мс — терпимо, но есть что улучшать;
• 500–800 мс — проблема, вы теряете и в Core Web Vitals, и в краулинге;
• больше 800 мс — критично, чинить в первую очередь.

Типичная ошибка измерения: смотреть TTFB одним прогоном PageSpeed Insights и делать выводы. Так вы получаете один замер из одной точки в одну секунду времени. Правильно — смотреть распределение: медиану и 95-й перцентиль за неделю, отдельно по типам страниц (главная, категория, карточка, поиск по сайту) и отдельно по времени суток. Сайт, который в 4 утра отдаёт 150 мс, а в 20:00 — 1,8 секунды, формально «имеет TTFB 150 мс» по одному замеру. Реально он имеет проблему с ресурсами в пик.

Краулинговый бюджет: арифметика, а не магия

Про краулинговый бюджет любят говорить абстрактно. Давайте посчитаем. Допустим, робот Яндекса тратит на ваш сайт условные 30 минут активного обхода в сутки. При TTFB 200 мс и параллелизме он успевает забрать несколько десятков тысяч страниц. При TTFB 1,5 секунды — в 7–8 раз меньше.

Для сайта на 200 страниц это неважно: обойдёт всё в любом случае. А вот для интернет-магазина на 50 000 карточек с фильтрами — это разница между «новые товары в индексе за 3 дня» и «за месяц». Если вы занимаетесь SEO для интернет-магазина, скорость ответа сервера напрямую конвертируется в скорость индексации ассортимента, а значит — в деньги на сезонных позициях.

Есть и обратная сторона, о которой редко говорят: Яндекс сам снижает интенсивность обхода, если видит, что сервер не справляется. Робот отслеживает время ответа и рост ошибок и притормаживает, чтобы не «положить» сайт. То есть слабый сервер наказывает вас дважды: сначала медленным обходом физически, потом — сознательным снижением нагрузки со стороны робота. И восстанавливается этот темп не мгновенно.

Что съедает бюджет впустую при слабом сервере:

• бесконечные комбинации фильтров и сортировок, каждая из которых генерирует тяжёлый SQL-запрос;
• внутренний поиск, открытый для индексации, — самая ресурсоёмкая страница на любом сайте;
• цепочки редиректов: каждый 301 — это отдельный запрос к серверу;
• страницы пагинации с полным рендерингом каталога.

Это уже пересечение инфраструктуры и технических ошибок сайта: закрыли мусорные параметры в robots.txt — освободили ресурс сервера и бюджет робота одновременно.

Виды хостинга: когда чего достаточно

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

Виртуальный (shared) хостинг

Сотни сайтов на одной физической машине, общие CPU, память и диск. Стоит 200–600 рублей в месяц. Работает — до определённого момента.

Главная беда шареда — эффект шумного соседа. Ваш TTFB зависит не от вас, а от того, что делает сайт из соседнего аккаунта. Кто-то запустил парсер или получил DDoS — у вас скачок времени ответа. Вторая беда — жёсткие лимиты: количество процессов PHP, CPU-минуты, число одновременных соединений. Превысили — получаете 503 или принудительное замедление. Причём хостер об этом вас не уведомит, вы просто увидите провал в Яндекс.Метрике.

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

VPS / VDS

Изолированный виртуальный сервер с гарантированными ресурсами. 800–5000 рублей в месяц в зависимости от конфигурации. Для 90% коммерческих сайтов в России это правильный выбор.

Что даёт: гарантированные CPU и RAM, полный контроль над стеком (nginx, версия PHP, OPcache, Redis), возможность нормально настроить кэширование, свои логи, свой мониторинг. Что требует: администрирования. Либо свой человек, либо услуга managed VPS у хостера, либо подрядчик — например, в рамках технической поддержки и доработки сайта. Брошенный VPS без обновлений опаснее шареда: там хоть хостер патчит.

Практический ориентир по конфигурации для типового сайта на 1С-Битрикс или WordPress с трафиком до 5000 визитов в сутки: 4 vCPU, 8 ГБ RAM, NVMe-диск. Меньше 4 ГБ RAM для Битрикса — сразу мимо.

Выделенный сервер

Физическая машина целиком. От 8000–10000 рублей в месяц. Нужен, когда упёрлись в потолок VPS: крупный магазин с десятками тысяч SKU, тяжёлая база на несколько десятков гигабайт, высокая посещаемость, требования к предсказуемой производительности диска. Плюс — когда есть регуляторные требования к размещению данных.

Облако

Yandex Cloud, VK Cloud, Selectel. Платите за потребление, масштабируетесь по нагрузке. Логика простая: облако имеет смысл при неравномерной нагрузке. Если у вас сезонный трафик — цветы к 8 марта, шины к ноябрю, подарки к декабрю — вы платите за пиковую мощность только в пик, а не круглый год. При ровной нагрузке облако выйдет дороже эквивалентного выделенного сервера в полтора-два раза.

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

География сервера: что важно и что миф

Здесь много путаницы, разложу по полочкам.

Миф: «Сервер должен быть в России, иначе Яндекс не будет ранжировать сайт по России». Нет. Региональная привязка определяется через Яндекс.Вебмастер, домен, контактные данные с адресом и телефоном, разметку организации, присутствие в Яндекс Бизнесе. IP сервера — сигнал слабый и вспомогательный.

Правда: география сервера критична через физику. Скорость света конечна, каждый километр — это миллисекунды. Сервер в Нидерландах добавляет к TTFB для московского пользователя 40–70 мс на сетевую задержку, а для пользователя из Новосибирска — все 100+. Умножьте на количество round-trip'ов при установке соединения и TLS — набегает четверть секунды до того, как сервер вообще начал думать.

Практическая рекомендация: размещайте сервер там, где живёт ваша аудитория. Работаете по Москве и ЦФО — берите московский или питерский дата-центр. Продвигаетесь в нескольких регионах — московский ДЦ плюс CDN для статики закрывают почти всё; тонкости региональной выдачи разбирали в материале про мультирегиональное SEO. Есть заграничная аудитория — CDN или отдельные точки присутствия.

Второй практический момент: санкционные и блокировочные риски. За последние годы российские сайты на зарубежных хостингах не раз попадали под внезапные блокировки аккаунтов, отказы в приёме оплаты и попадание IP-подсетей под ограничения РКН. Сайт, недоступный из России по сетевым причинам, для Яндекса просто недоступный сайт — и он выпадет из индекса ровно так же, как при аппаратном сбое. Это не про SEO-факторы, это про операционный риск, который бьёт по SEO сильнее любого фактора.

Кэширование: четыре уровня и логика выбора

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

Уровень 1. Кэш CMS (кэш приложения)

Внутри самой CMS: закэшированные результаты запросов к БД, скомпилированные шаблоны, готовые фрагменты HTML. В Битриксе это «Автокэширование» и композитный сайт, в WordPress — плагины типа LiteSpeed Cache или W3 Total Cache, в MODX — кэш ресурсов и сниппетов.

Что даёт: снимает нагрузку с базы. На типовом магазине 70–80% времени генерации страницы — это SQL-запросы. Закэшировали меню, блоки каталога, фильтры — TTFB упал вдвое без единой строчки нового кода.

Главная ошибка: кэш без продуманной инвалидации. Классика — изменили цену товара, а на сайте она старая ещё сутки, потому что кэш живёт 86400 секунд. В Яндекс.Маркете одна цена, на сайте другая — жалобы покупателей и проблемы с фидом. Инвалидация должна быть по событию (изменился товар → сбросился его кэш и кэш связанных категорий), а не по таймеру.

Уровень 2. Кэш сервера (nginx / reverse proxy)

Nginx отдаёт готовый HTML, вообще не запуская PHP. Это самый мощный уровень: время ответа падает до 10–30 мс, потому что запрос до приложения не доходит.

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

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

Уровень 3. Кэш браузера

Заголовки Cache-Control и ETag говорят браузеру: «этот файл не менялся, возьми из локального кэша». Влияет на повторные визиты и на переходы между страницами внутри сайта.

Рабочая схема:

• статика с хешем в имени файла (style.a3f9c1.css) — Cache-Control: public, max-age=31536000, immutable, то есть год;
• изображения — от 30 дней до года;
• HTML-документы — no-cache или короткий max-age с обязательной ревалидацией;
• ответы API и персональные данные — private, no-store.

Самая частая ошибка — не версионировать статику. Тогда либо ставят короткий max-age (и кэш бесполезен), либо длинный (и пользователи неделю видят старый CSS после релиза).

Уровень 4. CDN

Сеть узлов, раздающих контент с точки, ближней к пользователю. Для России имеет смысл CDN с реальным присутствием в российских регионах — Yandex Cloud CDN, Selectel, CDNvideo, G-Core.

Что отдавать через CDN: картинки, CSS, JS, шрифты, видео. Что не отдавать бездумно: HTML коммерческих страниц. Если CDN закэширует HTML и отдаст его посетителю из другого региона, вы рискуете показать неправильный город, неправильные цены и неправильный телефон — и это ударит по коммерческим факторам ранжирования и по конверсии одновременно.

Что кэшировать нельзя

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

• Страницы с персональными данными — личный кабинет, история заказов, корзина, оформление заказа. Никогда, ни на каком уровне.
• Формы с CSRF-токенами. Закэшировали страницу с формой — токен протух — форма не отправляется. Пользователь жмёт «Отправить», ничего не происходит, он уходит. Вы теряете лиды и не понимаете почему. Проверяйте отправку формы после каждой настройки кэша.
• Динамические остатки и цены — если они меняются чаще, чем раз в час, кэшируйте их отдельным AJAX-запросом, а не в составе HTML.
• Ответы с ошибками. Если 500-я ошибка попала в кэш nginx на 10 минут, вы получаете 10 минут гарантированного даунтайма после того, как проблема уже устранена.
• Персонализированные блоки — «вы недавно смотрели», «рекомендуем вам». Только через отдельные запросы поверх закэшированного скелета.

Сжатие, HTTP/2, HTTP/3 и OPcache

Gzip и Brotli. Сжатие текстовых ответов — HTML, CSS, JS, JSON, SVG. Gzip даёт 60–75% экономии, Brotli на уровне 4–5 — на 15–20% лучше при сопоставимой нагрузке на CPU. Статику сжимайте заранее (brotli_static on), динамику — на лету на среднем уровне. Не сжимайте то, что уже сжато: JPEG, PNG, WebP, видео, архивы — только зря греете процессор. Проверить включено ли: посмотрите заголовок Content-Encoding в ответе.

HTTP/2. Мультиплексирование: все ресурсы грузятся в одном соединении параллельно, без очереди. Плюс сжатие заголовков. Включается одной строкой в конфиге nginx при наличии HTTPS. Побочный эффект, который многие упускают: после перехода на HTTP/2 старые «оптимизации» вроде склейки всех JS в один файл и доменного шардинга становятся вредными. Раньше объединяли, чтобы уменьшить число запросов, теперь мелкие файлы кэшируются гранулярно и грузятся параллельно.

HTTP/3 (QUIC). Поверх UDP, без head-of-line blocking, соединение устанавливается за 0-RTT при повторных визитах. Реальный выигрыш — на мобильных сетях с потерями пакетов, где TCP тормозит на ретрансмиссиях. Если у вас 60–70% мобильного трафика, HTTP/3 даёт ощутимый эффект — это прямое дополнение к мобильной оптимизации сайта. Включается в свежих nginx или через CDN.

OPcache. Для любого PHP-сайта — обязательно. Без него PHP при каждом запросе заново парсит и компилирует все подключаемые файлы. С OPcache байт-код лежит в памяти. Прирост на CMS с сотнями файлов — двукратный и больше. Настройки, которые я ставлю: opcache.memory_consumption=256, opcache.max_accelerated_files=100000 (Битриксу нужно много), opcache.validate_timestamps=0 на проде со сбросом кэша при деплое. Проверьте прямо сейчас: если в phpinfo OPcache не включён — вы теряете половину производительности бесплатно.

И ещё: используйте актуальную версию PHP. Переход с 7.4 на 8.3 — это 20–30% производительности без единой правки кода. Это, наверное, самая дешёвая оптимизация из существующих.

Аптайм и падения: как реагирует поисковик

Яндекс не бросается удалять страницы при первой ошибке. Логика примерно такая:

1. Короткий сбой (минуты). Робот получил 5xx или таймаут, отложил и вернулся позже. Последствий нет.
2. Сбой в часы. Робот снижает частоту обхода. Страницы в индексе, но обновления не подхватываются.
3. Сутки и больше. Начинается выпадение страниц из индекса, сначала низкочастотных и глубоко вложенных. В Вебмастере появляются уведомления.
4. Несколько дней. Массовое выпадение. Позиции обнуляются.

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

Ключевые правила поведения при сбоях:

• Технические работы — только через 503 с заголовком Retry-After. Это говорит роботу: «временно, вернись через N секунд». Отдавать в это время 200 с текстом «идут работы» — верный способ получить дубли и потерять страницы. Отдавать 404 — катастрофа.
• Не редиректьте всё на заглушку. Массовый 302 на одну страницу — робот решит, что сайт схлопнулся в один документ.
• Мониторинг обязателен. Внешняя проверка каждую минуту (UptimeRobot, Яндекс.Вебмастер, Zabbix) с алертом в мессенджер. Узнавать о падении от клиента через два дня — непрофессионально.
• Проверяйте не только код 200. Сайт может отдавать 200 и при этом показывать белый экран из-за ошибки PHP или пустой каталог из-за отвалившейся базы. Мониторьте наличие ключевого элемента в HTML.

Реалистичная планка: 99,9% аптайма — это 43 минуты недоступности в месяц. 99,5% — уже 3,6 часа, и это плохо. Если хостер обещает 99,9% в SLA, но по факту вы видите еженедельные пятиминутные провалы, SLA — просто текст на сайте.

Как продиагностировать свой сервер: пошагово

Порядок действий, который я применяю на старте любого проекта.

1. Замерьте TTFB руками. В консоли: curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer}\n" https://вашсайт.ru/. Прогоните 10 раз на разных типах страниц. Так вы сразу увидите, где теряется время — в сети или в приложении.
2. Проверьте под нагрузкой. Инструменты вроде ab или wrk: 50 одновременных соединений, минута. Если TTFB вырастает с 200 мс до 3 секунд — у вас нет запаса, и ближайший всплеск трафика положит сайт.
3. Посмотрите логи в пик. В логе nginx включите $request_time и $upstream_response_time. Разница между ними покажет, кто виноват: nginx или PHP. Отсортируйте по времени — увидите 20 самых тяжёлых URL. Обычно это фильтры и поиск.
4. Проверьте заголовки. curl -I: есть ли Content-Encoding: br или gzip, есть ли адекватный Cache-Control, отдаётся ли HTTP/2.
5. Загляните в Вебмастер. Раздел «Диагностика» → «Скорость сайта» и статистика обхода. Это данные реального робота Яндекса, а не синтетика. Рост доли ответов дольше секунды — красный флаг.
6. Проверьте OPcache и версию PHP. Секунда работы, потенциально двукратный выигрыш.
7. Посмотрите на соседей (для шареда). ping и трассировка в разное время суток. Скачки задержки в вечерний пик при неизменном вашем трафике = соседи едят ресурс.

Результат диагностики должен быть не «сервер медленный», а конкретика: «медиана TTFB на карточках 340 мс, 95-й перцентиль 2,1 с, деградация с 19:00, upstream_response_time — 90% времени ответа, значит проблема в PHP и БД, а не в сети». С таким выводом уже можно идти к разработчикам или хостеру. Это тот же принцип, что и во внутренней оптимизации сайта: сначала измерение, потом гипотеза, потом правка.

Какие требования выставить хостеру

Чек-лист, по которому стоит выбирать и проверять провайдера:

• Дата-центр в России (для российской аудитории), уровень Tier III и выше, желательно несколько ДЦ у провайдера.
• SLA не ниже 99,9% с прописанной компенсацией. Компенсация — маркер того, что провайдер верит в свои цифры.
• NVMe-диски. Не SATA SSD, не «SSD-кэширование поверх HDD». Для базы данных дисковая латентность решает.
• Гарантированные, а не «до», ресурсы CPU и RAM. Формулировка «до 4 ядер» означает «когда сосед не занят».
• Свежий PHP (8.2+) с возможностью переключать версии и управлять php.ini.
• Доступ к логам nginx и PHP-FPM. Если хостер не даёт логи — вы слепы. Это дисквалифицирующий пункт.
• Автоматические бэкапы с retention не менее 7–14 дней и — главное — проверенным восстановлением. Бэкап, который ни разу не разворачивали, — это не бэкап, а надежда.
• Базовая защита от DDoS на уровне L3/L4 в тарифе, возможность подключить L7.
• Техподдержка с реальным ответом за 15–30 минут и инженерами, а не операторами со скриптами. Проверяется до покупки: напишите в поддержку осмысленный технический вопрос и засеките время и качество ответа.
• Прозрачные лимиты по процессам, соединениям и CPU-минутам — в цифрах, а не в духе «безлимитно».

И отдельно про переезд: перед сменой хостинга снизьте TTL DNS-записей до 300 секунд минимум за сутки. Иначе часть пользователей и роботов сутки-двое будут ходить на старый сервер. Старый сервер держите работающим неделю после переезда. И проверьте, что новый корректно отдаёт 301 с www на без-www (или наоборот) и с http на https — на переездах эти правила теряются чаще всего.

Частые ошибки, которые я вижу постоянно

• «У нас хороший хостинг, там всё включено». Проверьте curl'ом. В половине случаев ни Brotli, ни HTTP/2, ни OPcache не включены.
• Оптимизировали картинки, не тронув TTFB. Сэкономили 200 мс на фронтенде при секунде задержки на бэкенде. Начинать надо с ответа сервера.
• Кэш включили, инвалидацию — нет. Через месяц кто-то замечает, что новости на главной трёхнедельной давности.
• Один сервер под сайт, базу, почту, бэкапы и 1С-обмен. Ночной обмен начинается — сайт ложится. Разносите тяжёлые фоновые задачи по времени или по машинам.
• Нет мониторинга. Сайт лежал в субботу восемь часов, узнали в понедельник.
• Экономия 500 рублей в месяц на хостинге при бюджете 100 000 на продвижение. Самая иррациональная экономия в отрасли — она обесценивает всё остальное. Из этой же категории — история про то, почему дешёвое SEO опасно: экономия на фундаменте всегда всплывает позже и дороже.
• Смена хостинга «на удачу» без замеров до и после. Переехали, стало хуже, доказать нечем.

Вывод

Хостинг и сервер — это не строчка расходов, а фундамент, на котором стоит вся остальная SEO-работа. Можно собрать безупречное семантическое ядро, написать отличные тексты и построить ссылочную массу — и всё это будет работать вполсилы, если сервер отвечает секунду и падает раз в неделю. Хорошая новость в том, что инфраструктура — самая управляемая часть SEO: здесь нет «а вдруг алгоритм передумает», есть измеримые метрики, понятные причины и предсказуемый результат. Замерьте TTFB, включите OPcache и Brotli, настройте кэш с честной инвалидацией, поставьте мониторинг — и вы уже опередите большинство конкурентов в своей нише.

Сложность в том, что серверная оптимизация требует связки компетенций: нужно одновременно понимать, как думает робот Яндекса, как устроено кэширование в конкретной CMS и где у вашего приложения узкое место. Мы в SEO ПРОГРЕСС начинаем работу именно с технического фундамента — и часто первый заметный рост позиций даёт не контент, а приведённый в порядок сервер. Посмотрите наши кейсы, чтобы увидеть, как это выглядит в цифрах на реальных проектах, или свяжитесь с нами — проведём диагностику вашей инфраструктуры и скажем, что чинить в первую очередь, а что подождёт.