Влияет ли хостинг на продвижение сайта

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

Как хостинг связан с продвижением на самом деле

Прямого фактора «качество хостинга» в алгоритмах нет. Робот не знает ни названия провайдера, ни тарифа, ни того, сколько оперативной памяти выделено контейнеру. Он видит только три вещи: за сколько сервер отдал ответ, какой код ответа пришёл и удалось ли вообще установить соединение. Через эти три величины хостинг и попадает в продвижение.

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

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

Время ответа сервера: параметр, который важнее «скорости сайта»

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

В этот интервал укладывается вся работа хостинга: приём соединения, установка TLS, запуск обработчика PHP, обращения к базе данных, сборка HTML. Если сайт отдаёт первый байт за 150–250 миллисекунд, робот успевает за сеанс обойти много адресов. Если за полторы-две секунды — количество обойденных страниц падает кратно, и никакого «наказания» тут нет, просто арифметика: за отведённое на сайт время физически влезает меньше запросов.

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

Как замерить время ответа своими руками

Самый честный способ — консоль и curl, потому что он показывает чистое время сервера без влияния браузера и расширений. Команда выводит отдельно установку соединения, TLS-рукопожатие, время до первого байта и общее время:

curl -o /dev/null -s -w "connect: %{time_connect}\nssl: %{time_appconnect}\nttfb: %{time_starttransfer}\ntotal: %{time_total}\ncode: %{http_code}\n" https://example.ru/

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

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

Какие параметры хостинга и как проверять

Параметр	Как влияет на продвижение	Как проверить
Время ответа (TTFB)	Определяет, сколько страниц робот успевает обойти за визит; влияет на отказы живых пользователей	curl с выводом time_starttransfer, график в панели вебмастера, логи сервера
Аптайм	Простои превращаются в ошибки обхода, при длительном недоступе страницы выпадают из индекса	Внешний мониторинг с проверкой раз в минуту, статистика обхода, письма от панели вебмастера
Коды ответа	5xx на месте нормальной страницы откладывает её переобход, массовые 5xx снижают частоту визитов робота	Отчёт по кодам ответа в панели вебмастера, grep по логам, обход краулером
Версия PHP	Свежая версия быстрее генерирует страницу, значит короче время ответа	Панель управления хостингом, вывод phpinfo, заголовки ответа
Лимиты памяти и времени выполнения	Слишком низкие лимиты дают белые экраны и 500-е ошибки на тяжёлых страницах	phpinfo, логи ошибок PHP, поведение админки при массовых операциях
HTTP/2 или HTTP/3	Параллельная загрузка ресурсов, меньше задержек для пользователя	Вкладка «Сеть» в браузере, curl -I —http2
Сжатие ответа	Меньше объём HTML, быстрее передача, экономия трафика робота	Заголовок content-encoding в ответе сервера
Серверный кэш	Отдача готовой страницы без запуска PHP резко сокращает время ответа	Сравнить TTFB первого и повторного запроса, заголовки кэша
SSL-сертификат	Просроченный сертификат делает сайт недоступным для робота и браузеров	Дата в свойствах сертификата, автопродление в панели, внешний мониторинг
Автоматические бэкапы	Скорость восстановления после сбоя, а значит длительность простоя	Раздел резервных копий в панели, тестовое восстановление на поддомен

Аптайм и коды 5xx: что происходит, когда робот приходит на упавший сайт

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

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

Отдельно стоит код 503 с заголовком Retry-After. Это единственный корректный способ сказать роботу «сейчас техработы, зайди через час». Если сайт временно выключается на обновление, отдавать нужно именно 503, а не 200 с текстом «идут работы» и не 404. Двухсотый ответ со страницей-заглушкой хуже всего: робот честно проиндексирует заглушку вместо контента, и по всем адресам в поиске окажется одинаковый текст.

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

Как сбои выглядят в статистике обхода

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

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

За сколько времени сайт выпадает из индекса при простое

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

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

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

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

Расположение сервера и региональность: где миф, а где правда

Живучее заблуждение звучит так: «сервер в Германии — значит, в России сайт не будет ранжироваться». Реальность мягче. Физическое расположение дата-центра само по себе регион сайта не определяет. Для Яндекса регион задаётся присвоенным регионом в панели вебмастера, контактными данными и адресами на сайте, привязкой карточки организации, содержанием страниц и упоминаниями с региональной привязкой. Хостинг в этот список не входит.

Но у географии есть косвенное следствие — сетевая задержка. Каждый лишний прыжок между континентами добавляет к времени ответа десятки миллисекунд, а при плохой маршрутизации и больше. Для сайта, чьи посетители и робот находятся в России, сервер в европейском или американском дата-центре означает стабильно худший TTFB, чем у конкурента с сервером поблизости. То есть вредит не «неправильная страна», а лишние миллисекунды на пути пакетов.

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

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

Выделенный IP или общий: когда стоит беспокоиться

На виртуальном хостинге один IP-адрес обслуживает десятки, а иногда и сотни сайтов. Отсюда родился страх «плохих соседей»: якобы если рядом окажется дорвей или спам-рассылка, тень падёт на всех.

Смежный материал по теме — «Влияет ли скорость сайта на продвижение».

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

А вот где общий адрес реально мешает: почтовые рассылки. Если сосед по IP занимается спамом, адрес попадает в почтовые чёрные списки, и письма с вашего сайта — уведомления о заказах, восстановление пароля, ответы клиентам — начинают уходить в спам или отбиваться. Это бьёт по бизнесу напрямую, хотя к позициям отношения не имеет. Лечится это не выделенным IP, а отправкой почты через внешний сервис рассылок с нормальной репутацией и настроенными SPF, DKIM и DMARC.

Ещё один сценарий: сосед с многократной нагрузкой съедает процессор общего сервера, и ваш сайт тормозит без всякой вины. Здесь выделенный IP тоже не поможет — нужен переезд на изолированные ресурсы.

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

Типы хостинга: что под какие задачи

Тип	Как устроен	Кому подходит	Слабые места
Виртуальный (shared)	Много сайтов на одном сервере, ресурсы делятся между всеми	Сайты-визитки, блоги, небольшие каталоги с невысокой посещаемостью	Соседи по серверу влияют на скорость, жёсткие лимиты процессорного времени, нельзя тонко настроить окружение
VPS	Изолированный виртуальный сервер с гарантированными ресурсами и полным доступом	Интернет-магазины, порталы, сайты с ощутимым трафиком и своей логикой	Нужен администратор или управляемый тариф, ресурсы всё же ограничены железом узла
Выделенный сервер	Физическая машина целиком в вашем распоряжении	Крупные магазины, высоконагруженные проекты, тяжёлые базы данных	Дорого, масштабирование требует времени, любое железное происшествие — ваш простой
Облако	Ресурсы выделяются динамически, мощность добавляется по нагрузке	Проекты с непредсказуемыми пиками: сезонность, реклама, распродажи	Счёт зависит от потребления, нужна грамотная настройка, иначе переплата

Универсального ответа «какой хостинг лучше для SEO» не существует, но есть простое правило: тип площадки должен соответствовать реальной нагрузке. Сайт-визитка на выделенном сервере не станет ранжироваться лучше — это просто сожжённый бюджет. Магазин на пять тысяч товаров на дешёвом шаред-тарифе будет упираться в лимиты, отдавать 5xx в часы пик и терять обход.

Признаки, что пора менять хостинг

Признак	Что происходит	Что делать
Время ответа стабильно выше секунды на лёгкой странице	Сервер не успевает генерировать HTML, обход падает	Сначала проверить сайт и кэш, если чисто — менять тариф или площадку
Регулярные 5xx в статистике обхода	Нехватка ресурсов или нестабильность узла	Запросить у поддержки логи по лимитам, при отсутствии внятного ответа переезжать
Скорость проседает в одни и те же часы	Пиковая нагрузка на общий сервер, часто из-за соседей	Переход на изолированные ресурсы: VPS или облако
Поддержка отвечает сутками или отписками	Любая авария растягивается на дни простоя	Менять на провайдера с круглосуточной технической поддержкой
Нет свежих версий PHP и нужных модулей	Сайт работает медленнее возможного, часть CMS-функций недоступна	Уточнить планы провайдера, при отказе обновляться — переезд
Бэкапы не делаются или не восстанавливаются	Один сбой может стоить всего сайта	Немедленно настроить свои копии, параллельно искать другую площадку
Цена продления кратно выше цены первого года	Бюджет растёт без роста качества	Сравнить рынок, переезжать заранее, а не в день окончания оплаты
Периодические блокировки сайта за «превышение нагрузки»	Сайт временно выключают, робот получает недоступность	Разбираться с причиной нагрузки, при повторении менять тип хостинга

Что должен уметь нормальный хостинг технически

Минимальный набор требований, который стоит проверить до оплаты, а не после переезда:

• Актуальные версии PHP с возможностью переключения. Каждая новая ветка заметно быстрее предыдущей на типовых CMS. Возможность переключить версию в панели за пару кликов — обязательна, потому что обновление CMS иногда требует и обновления языка.
• Достаточные лимиты. memory_limit, max_execution_time, upload_max_filesize, количество одновременных процессов. Низкие значения проявляются не сразу: сайт работает, а импорт товаров или генерация карты сайта падает с 500-й ошибкой.
• HTTP/2 или HTTP/3. Мультиплексирование запросов ощутимо ускоряет загрузку страниц с большим числом ресурсов.
• Сжатие на стороне сервера. gzip как минимум, brotli желательно. HTML сжимается в разы, и это бесплатное ускорение.
• Кэширование. Возможность включить кэш на уровне веб-сервера, использовать OPcache для PHP и подключить внешнее хранилище вроде Redis или Memcached для тяжёлых сайтов.
• SSL с автопродлением. Бесплатного сертификата достаточно для подавляющего большинства сайтов, но продление должно быть автоматическим — просроченный сертификат мгновенно превращает сайт в недоступный.
• Нормальный веб-сервер в связке. Раздача статики без запуска тяжёлого обработчика снимает с сервера значительную часть работы.
• Доступ к логам. Без логов доступа и ошибок диагностика превращается в гадание.
• Автоматические резервные копии с возможностью самостоятельного восстановления. Хранение хотя бы за неделю и кнопка отката без обращения в поддержку.

Как понять, что тормозит именно хостинг, а не сайт

Это ключевой вопрос, потому что переезд ради переезда часто ничего не меняет: медленный сайт остаётся медленным и на мощном сервере. Проверка делается по шагам.

1. Замерьте лёгкую страницу. Положите в корень простой файл, который ничего не делает — например, выводит одну строку через PHP. Если он отдаётся за 300–500 миллисекунд и больше, проблема в сервере: генерировать там нечего. Если за 40–80 миллисекунд — сервер в порядке, тормозит сам сайт.
2. Сравните с обычной страницей. Разница между пустым файлом и главной показывает, сколько времени тратит CMS со всеми плагинами и запросами.
3. Отключите расширения. На копии сайта поочерёдно выключайте плагины и модули, замеряя TTFB. Один-два «тяжеловеса» обычно дают львиную долю задержки: конструкторы страниц, фильтры каталога, счётчики просмотров, модули связанных товаров.
4. Посмотрите на базу. Медленные запросы находятся через профилировщик запросов или журнал медленных запросов в СУБД. Классика — запросы без индексов, выборки по всей таблице заказов, перебор метаданных на каждой странице.
5. Проверьте кэш. Если повторный запрос той же страницы отдаётся так же медленно, как первый, кэширование не работает вовсе, и вы каждый раз собираете страницу заново.
6. Сравните разные типы страниц. Если главная быстрая, а страница поиска или фильтра медленная, это архитектурная проблема, и хостинг тут ни при чём.

Если нужна помощь по теме — разработка сайта под ключ.

Практика показывает: чаще виноват сайт, а не сервер. Но встречается и обратное — когда пустой PHP-файл на дешёвом тарифе отвечает за секунду, потому что процессорное время урезано лимитами. Именно поэтому замер начинается с самой лёгкой страницы: он однозначно разделяет ответственность.

Нагрузка от плагинов и запросов к базе

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

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

Если нужны детали, смотрите «Влияет ли домен на продвижение сайта».

Как переехать на новый хостинг без потери позиций

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

Шаг	Что делаем	Как контролируем
1. Подготовка	Снимаем полную копию файлов и базы, фиксируем список текущих позиций и трафика	Копия открывается локально, дамп базы восстанавливается без ошибок
2. Развёртывание	Поднимаем сайт на новом сервере на техническом адресе или через файл hosts	Проверяем главную, каталог, карточку, корзину, формы, поиск, админку
3. Закрытие копии	Технический адрес закрываем от индексирования на уровне сервера	Запрос к техническому домену возвращает запрет для роботов
4. Проверка окружения	Версия PHP, модули, права на файлы, почта, планировщик, SSL	Тестовое письмо доходит, сертификат валиден, задачи выполняются
5. Заморозка контента	Прекращаем изменения на старом сайте, чтобы не потерять заказы и правки	Уведомление для контент-менеджеров и менеджеров заказов
6. Финальная синхронизация	Переносим свежие данные: заказы, комментарии, загруженные файлы	Сверка количества записей в ключевых таблицах
7. Смена DNS	Заранее уменьшаем TTL, затем меняем записи A и AAAA	Проверка резолвинга из разных сетей и через публичные DNS
8. Двойная работа	Старый сервер держим включённым ещё несколько дней	Часть посетителей ещё идёт на старый IP, сайт для них работает
9. Контроль кодов ответа	Обход краулером всех адресов из карты сайта	Ноль новых 404 и 5xx, редиректы ведут туда же, куда раньше
10. Карта сайта и переобход	Проверяем доступность sitemap.xml и robots.txt, отправляем ключевые адреса на переобход	Карта читается без ошибок, статистика обхода не проседает
11. Наблюдение	Две недели следим за временем ответа, ошибками и позициями	Графики в панели вебмастера и внешний мониторинг доступности

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

На что смотреть при выборе площадки

Маркетинговые обещания про «99,9% аптайма» пишут все, поэтому оценивать провайдера приходится по другим признакам.

• Отзывы про аварии, а не про цену. Ищите не общие оценки, а описания конкретных сбоев: как долго лежало, как быстро отвечала поддержка, компенсировали ли простой. Провайдер без единого упоминания аварий за годы работы либо очень мал, либо отзывы подчищены.
• Скорость и компетентность поддержки. Напишите в поддержку до покупки с техническим вопросом — например, про лимиты процессорного времени на тарифе. По ответу видно и скорость реакции, и уровень специалистов.
• Прозрачность лимитов. Нормальный провайдер называет конкретные цифры по процессорному времени, числу процессов и соединениям с базой. Формулировка «неограниченно» означает, что ограничения есть, но вам их не покажут до момента блокировки.
• Резервные копии. Глубина хранения, частота, возможность восстановить самостоятельно, отдельное хранилище от основного сервера.
• Тестовый период. Возможность развернуть сайт и померить время ответа до оплаты года.
• Цена продления. Первый год часто продают с большой скидкой, а второй стоит втрое дороже. Считайте стоимость на два-три года вперёд.
• Панель управления. Понятная панель с доступом к логам, версиям PHP, базам, планировщику и SSL экономит десятки часов за год.
• Возможность роста внутри провайдера. Переход с виртуального тарифа на VPS без смены компании — большое удобство, когда сайт вырастет.

Мониторинг: чтобы узнавать о падениях раньше поиска

Даже идеальный хостинг иногда падает. Разница между «потеряли час трафика» и «потеряли позиции» в том, насколько быстро вы узнали о проблеме. Минимальный набор: внешний сервис мониторинга, который проверяет главную и одну внутреннюю страницу раз в минуту и присылает уведомление в мессенджер; отслеживание срока действия SSL-сертификата и домена; регулярный просмотр статистики обхода в панели вебмастера хотя бы раз в неделю.

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

Частые заблуждения про хостинг и поиск

• «Дорогой хостинг поднимет позиции». Не поднимет. Он уберёт помеху, если она была. Если время ответа и так нормальное, переплата ничего не даст.
• «Нужен сервер строго в моём городе». Регион сайта задаётся не сервером. Достаточно, чтобы дата-центр был в той же стране и с хорошей связностью.
• «Соседи по IP испортят репутацию». Для ранжирования — практически нет. Для почтовых рассылок — вполне возможно.
• «Переезд обязательно роняет позиции». Аккуратный переезд без смены домена и адресов проходит незаметно.
• «Главное — оценка в сервисе проверки скорости». Балл в тестере оценивает фронтенд. Для обхода важнее время ответа сервера, которое в такой оценке почти не отражается.

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

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

Какое время ответа считать нормальным?
Ориентир для обычного сайта на CMS — отдача первого байта в пределах пары-тройки сотен миллисекунд на закэшированной странице. Значения ближе к секунде — повод разбираться, стабильно больше секунды — повод действовать. Важнее абсолютной цифры стабильность: ровный график лучше, чем среднее хорошее значение с регулярными выбросами.

Сайт упал на несколько часов, что делать?
Ничего экстренного. Убедитесь, что сервер восстановлен и отдаёт код 200, проверьте статистику обхода на предмет ошибок, при необходимости отправьте ключевые страницы на переобход. Короткий простой не приводит к потере позиций. Если падение планируется заранее, настройте ответ 503 с заголовком Retry-After вместо заглушки с кодом 200.

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

Как понять, что 5xx-ошибки в панели вебмастера — вина хостинга?
Сопоставьте время ошибок с логами сервера и с графиком нагрузки. Если ошибки совпадают с пиками посещаемости или с запуском фоновых задач, дело в нехватке ресурсов или в тяжёлых скриптах. Если они возникают равномерно и без нагрузки, это сбои на стороне площадки, и стоит запросить объяснения у поддержки. Если 5xx приходятся только на один раздел, виноват код сайта, а не хостинг.

О роли хостинга и настроек сервера в продвижении:

2:36

Коротко

• Хостинг не ранжируется напрямую, но управляет тремя вещами, которые видит робот: временем ответа, кодами ответа и доступностью.
• Для обхода важнее время до первого байта, чем общая скорость отрисовки страницы; мерить его надо через curl, панель вебмастера и логи.
• Регулярные 5xx снижают интенсивность обхода, а простой длиной в неделю и больше уже выбивает страницы из индекса.
• Регион сайта задаётся не географией дата-центра, а настройками и содержанием; расположение сервера влияет только на сетевые задержки.
• Перед переездом проверьте, что тормозит именно сервер, а не плагины и запросы к базе, а сам переезд проводите по чек-листу с контролем кодов ответа.

Проверить, что именно тормозит ваш сайт, можно на SEO-консультации.