Контроль работы хостинга

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

Почему хостинг напрямую влияет на позиции

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

• Скорость ответа определяет глубину обхода. При ответе 200 мс робот успевает забрать в разы больше страниц за тот же сеанс, чем при ответе 1,5 секунды.
• Ошибки 5xx останавливают обход. Получив серию ответов 500, 502 или 503, робот делает паузу и возвращается позже с уменьшенной нагрузкой.
• Длительная недоступность выбрасывает страницы из индекса. Если страница отдаёт ошибку несколько проверок подряд на протяжении нескольких дней, она исключается как недоступная.
• Время загрузки — фактор ранжирования. Он не решающий, но при прочих равных медленный сайт проигрывает быстрому, особенно в мобильной выдаче.
• Поведение пользователей. Задержка первого экрана сверх 3 секунд заметно повышает долю отказов, а отказы косвенно ухудшают оценку страницы.
• Hostland отзывы о хостинге

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

Какие показатели нужно контролировать

Показатель	Норма	Тревожно	Чем грозит
Uptime за месяц	от 99,9%	ниже 99,5%	Более 3,5 часов простоя в месяц, выпадение страниц
TTFB (время до первого байта)	до 200 мс	от 600 мс	Сокращение обхода, рост отказов
Полное время ответа	до 0,5 с	от 1,5 с	Просадка в мобильной выдаче
Доля ответов 5xx	0%	от 0,1% запросов	Пауза в обходе, потеря индексации
Загрузка CPU	до 50% лимита	от 80% лимита	Троттлинг, принудительная блокировка сайта
Использование памяти	до 60% лимита	от 85% лимита	Обрывы PHP-процессов, белый экран
Одновременные соединения	запас в 2 раза	упор в лимит	Ошибка 503 для части посетителей
Место на диске	запас от 25%	менее 10%	Падение базы, невозможность создать бэкап

Отдельно стоит отметить: uptime 99,5% звучит прилично, но это 3 часа 39 минут простоя в месяц. Если они выпадают на утро рабочего дня, потери в заявках вполне ощутимы. А 99% — это уже больше семи часов, то есть почти рабочий день без сайта.

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

Самый честный способ — curl. Он не рисует красивых графиков, зато показывает голые цифры без прослоек и кэшей браузера. Базовая команда:

• curl -o /dev/null -s -w "%{time_total}\n" https://site.ru/ — полное время запроса в секундах.
• curl -o /dev/null -s -w "%{time_starttransfer}\n" https://site.ru/ — тот самый TTFB, время до первого байта.
• curl -o /dev/null -s -w "%{time_connect} %{time_appconnect} %{time_starttransfer} %{time_total}\n" https://site.ru/ — разбивка по этапам: TCP, TLS, первый байт, конец.
• curl -o /dev/null -s -w "%{http_code}\n" https://site.ru/stranica/ — код ответа конкретной страницы.
• Hostland отзывы о хостинге

Разбивка по этапам полезнее одной суммарной цифры. Если time_connect мал, а time_starttransfer велик — проблема в генерации страницы на сервере: тяжёлые запросы к базе, медленный PHP, нехватка ресурсов. Если долгим оказывается time_appconnect — вопрос к TLS-настройкам и сертификату. Если тормозит уже сам time_connect — беда с сетью или с датацентром.

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

• for i in $(seq 1 20); do curl -o /dev/null -s -w "%{time_starttransfer}\n" https://site.ru/; sleep 3; done
• Hostland отзывы о хостинге

Смотреть надо не на среднее, а на худшие значения. Если восемнадцать замеров дали 0,2 с, а два — по 2,5 с, это не «в среднем нормально». Это значит, что каждый десятый посетитель и каждый десятый заход робота упирается в затык.

Внешний мониторинг доступности

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

Тип проверки	Что делает	Что ловит
Ping / TCP-порт	Проверяет отклик сервера или открытость порта	Полное падение машины, сетевые проблемы
HTTP-код	Запрашивает страницу и смотрит статус	Ошибки 5xx, редиректы, отдачу заглушки
Ключевое слово	Ищет заданный текст в теле ответа	«Белый экран», ошибку базы при коде 200
Срок сертификата	Читает дату окончания TLS	Внезапное истечение SSL и предупреждение браузера
Срок домена	Проверяет whois	Забытое продление регистрации
Замер времени ответа	Пишет историю TTFB	Постепенную деградацию сервера

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

Смежный материал по теме — «Заказчик просрочил оплату хостинга и позиции сайта рухнули».

Интервал проверки ставьте не реже пяти минут. При интервале в час падение на сорок минут вы просто не увидите. И обязательно включите уведомления на почту и в мессенджер: письмо ночью можно проспать, push-уведомление разбудит.

Раздел ошибок в панели вебмастера

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

Панель вебмастера показывает не то, что видите вы, а то, что видит робот. Это принципиально разные вещи: ваш браузер ходит через кэш и с вашего IP, робот — с чужих адресов и без кэша.

1. Откройте раздел «Диагностика сайта» — там висят фатальные и критичные ошибки, включая недоступность главной страницы.
2. Проверьте «Статистику обхода»: график загруженных страниц и распределение по кодам ответа. Всплеск 5xx виден там мгновенно.
3. Загляните в «Скорость сайта»: сервис хранит историю времени ответа, и по ней видно, когда именно началась деградация.
4. Посмотрите «Страницы в поиске» с фильтром по исключённым: статус «Ошибка HTTP» прямо указывает, что страницу выкинули из-за сервера.

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

Логи сервера — источник правды

Логи доступа и ошибок отвечают на вопрос «что именно произошло в 3:47 ночи». Панель хостинга обычно даёт к ним доступ через файловый менеджер или раздел «Журналы».

• grep " 500 " access.log | wc -l — сколько было пятисотых ответов.
• awk '{print $9}' access.log | sort | uniq -c | sort -rn — распределение по всем кодам ответа.
• awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20 — топ IP по числу запросов, ловит ботов и парсеры.
• tail -100 error.log — последние записи об ошибках PHP и веб-сервера.
• Hostland отзывы о хостинге

Частая находка в логах — не поломка сайта, а нагрузка от чужих ботов. Агрессивные парсеры и сканеры могут выбирать весь лимит одновременных соединений, из-за чего живые посетители и поисковый робот получают 503. Лечится это не переездом на мощный тариф, а блокировкой по user-agent или подсети.

Типичные проблемы виртуального хостинга

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

Проблема	Как проявляется	Как проверить
Шумные соседи	Сайт тормозит в случайные часы без роста своего трафика	Серия замеров TTFB круглосуточно, сравнение с посещаемостью
Лимит CPU	Страницы генерируются по 3-5 секунд в часы пик	График нагрузки в панели хостинга
Лимит процессов	Часть посетителей видит 503, часть заходит нормально	Счётчик одновременных подключений, логи с кодом 503
Отключение при нагрузке	Сайт полностью заблокирован хостером на несколько часов	Письмо от поддержки, заглушка вместо сайта
Общий IP в чёрных списках	Письма с сайта уходят в спам	Проверка IP по спам-базам
Устаревшая версия PHP	CMS работает медленнее и не получает обновлений	Панель управления, раздел выбора версии PHP
Медленный диск	Долгие запросы к базе при небольшом объёме данных	Сравнение времени генерации с эталонным сервером

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

Когда пора переезжать на VPS

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

Если нужны детали, смотрите «Виды хостинга».

1. Посещаемость стабильно превышает 1000-1500 визитов в сутки, и в часы пик время ответа растёт вдвое.
2. В панели регулярно видно упор в лимит CPU или числа процессов.
3. Хостер уже присылал предупреждения о превышении лимитов.
4. Сайт — интернет-магазин с большим каталогом: фильтры и поиск создают тяжёлые запросы к базе.
5. Нужны свои настройки: другая версия PHP, кэш в оперативной памяти, отдельные модули, свои cron-задачи с коротким интервалом.
6. TTFB не опускается ниже 600 мс даже при включённом кэшировании и оптимизированной базе.

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

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

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

Обещания на сайте хостера ничего не стоят. Проверять надо самому, и делается это до оплаты годового тарифа со скидкой.

• Возьмите тестовый период. Почти все дают от 7 до 30 дней бесплатно. Разверните копию сайта и погоняйте её.
• Замерьте TTFB в разное время суток. Утром, днём, вечером и ночью — минимум по десять замеров.
• Проверьте лимиты в договоре. Ищите пункты про процессорное время, число процессов, размер базы и количество inode. Именно они, а не «безлимитный трафик», определяют реальные возможности.
• Протестируйте поддержку. Напишите технический вопрос в нерабочее время и засеките, через сколько ответят и по существу ли.
• Уточните расположение датацентра. Для аудитории из России сервер должен стоять в России: и по скорости, и по требованиям к хранению персональных данных.
• Спросите про бэкапы. Как часто, сколько копий хранится, можно ли восстановить самому и платно ли это.
• Проверьте версии ПО. Актуальная версия PHP, доступ к настройкам кэширования, наличие HTTP/2.
• Hostland отзывы о хостинге

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

Что делать при падении сайта

Порядок действий важнее скорости. Хаотичные попытки «что-нибудь поменять» в момент аварии обычно удлиняют простой.

1. Убедитесь, что проблема не у вас: откройте сайт с мобильного интернета или через внешний сервис проверки доступности.
2. Определите код ответа: curl -I https://site.ru/. Ответ 500 — ошибка приложения, 502 и 504 — проблема веб-сервера, отсутствие ответа — сервер лежит целиком.
3. Загляните в error.log — там чаще всего лежит прямая причина: исчерпана память, ошибка в PHP, недоступна база.
4. Проверьте место на диске и лимиты в панели. Переполненный диск даёт эффект, неотличимый от поломки CMS.
5. Вспомните, что менялось: обновление CMS, новый плагин, правка кода, импорт данных.
6. Напишите в поддержку с конкретикой: время начала, код ответа, выдержка из лога. Так ответят быстрее и по делу.
7. Если простой затягивается за час, поставьте на домен заглушку с кодом 503 и заголовком Retry-After — робот поймёт, что это временно, и не станет исключать страницы.

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

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

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

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

Что копировать	Частота	Где хранить	Глубина
База данных	Ежедневно	Внешнее облако или свой диск	не менее 14 копий
Файлы сайта	Еженедельно	Внешнее хранилище	не менее 4 копий
Загрузки и медиа	Еженедельно	Отдельно от кода	2-3 копии
Конфигурации сервера	После каждой правки	Локально или в репозитории	вся история

Дамп базы делается одной командой: mysqldump -u user -p baza | gzip > baza_$(date +%F).sql.gz. Файлы упаковываются архиватором. Дальше копия выгружается на сторонний ресурс — по расписанию через cron или синхронизацией.

Подробнее об этом — в статье «Всплывающее окно на весь экран: Яндекс за него понижает, а вы теряете людей».

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

Регулярный регламент проверок

Периодичность	Что проверять
Постоянно	Внешний мониторинг доступности с уведомлениями
Еженедельно	Замер TTFB, коды ответа в статистике обхода, диагностика в панели вебмастера
Ежемесячно	Отчёт по uptime, нагрузка на CPU и память, свободное место, объём базы
Ежеквартально	Тестовое восстановление из бэкапа, ревизия логов на предмет ботов
Ежегодно	Сроки домена и сертификата, пересмотр тарифа, сравнение с рынком

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

Что можно улучшить без смены хостинга

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

• Включите серверное кэширование. Отдача готовой HTML-страницы вместо генерации сокращает время ответа в разы.
• Обновите PHP. Переход на актуальную версию заметно ускоряет исполнение кода на большинстве CMS.
• Почистите базу. Ревизии, спам-комментарии, логи плагинов и мусорные записи в служебных таблицах — типичные источники разбухания.
• Добавьте индексы. Медленные запросы к большим таблицам чаще всего лечатся правильным индексом, а не мощным процессором.
• Уберите лишние плагины. Каждый подключённый модуль исполняется на каждом запросе.
• Заблокируйте паразитный трафик. Сканеры и парсеры съедают лимиты, ничего не давая взамен.
• Вынесите статику. Картинки и файлы отдавайте напрямую веб-сервером или через CDN, минуя интерпретатор.
• Hostland отзывы о хостинге

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

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

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

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

Хостер обещает uptime 99,9% — это гарантия?
Это обязательство, но проверять его всё равно надо самостоятельно, потому что считает его сам хостер и по своим правилам. Плановые работы часто выводятся за рамки расчёта, а короткие сбои могут просто не попасть в отчёт. Ведите собственную статистику через внешний мониторинг и сверяйте её с обещанным. При систематических расхождениях есть повод требовать компенсацию или менять провайдера.

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

Как понять, что тормозит именно хостинг, а не сайт?
Разделите замеры. Посмотрите time_starttransfer для обычной страницы и для маленького статического файла на том же домене. Если статика отдаётся за 50 мс, а страница — за 1,5 секунды, дело в генерации: код, база, плагины. Если медленно отдаётся даже картинка, проблема на уровне сервера или сети, и это уже вопрос к хостеру.

Коротко

• Целевые ориентиры: uptime от 99,9%, время ответа до 0,5 секунды, TTFB до 200 мс, нулевая доля ответов 5xx.
• Измеряйте сами: серия команд curl с параметрами time_starttransfer и time_total честнее любых обещаний хостера.
• Обязательный минимум мониторинга — внешняя проверка HTTP-кода и ключевого слова каждые 5 минут с уведомлениями.
• Признаки, что пора на VPS: упор в лимиты CPU и процессов, предупреждения от хостера, TTFB выше 600 мс при включённом кэше.
• Свой бэкап на внешнем хранилище с проверкой восстановления раз в квартал — единственная надёжная страховка.
• Hostland отзывы о хостинге

Как узнать, на каком хостинге стоит сайт, и почему это важно:

1:30

Проверить сайт по этим пунктам разом можно через бесплатный аудит — отчёт приходит на почту.