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

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

Почему магазину сервер критичнее, чем сайту услуг

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

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

Дальше добавляются вещи, которых у сайта услуг нет в принципе:

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

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

Время ответа сервера и обход роботом

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

Практический смысл простой. Допустим, робот готов тратить на ваш сайт условные пять минут за визит. При времени ответа 150 мс он успеет забрать порядка двух тысяч документов. При времени ответа 1,5 секунды — в десять раз меньше. Каталог на сорок тысяч адресов в первом случае обходится за считаные дни, во втором растягивается на кварталы.

Среднее время ответа	Что происходит с обходом	Каталог 40 000 адресов
до 200 мс	робот идёт свободно, лимит упирается в его собственные квоты	полный цикл за дни
200–500 мс	обход стабильный, но новые разделы заходят заметно медленнее	недели
500 мс – 1,5 с	робот осторожничает, глубокие страницы посещаются редко	месяцы
больше 1,5 с	интенсивность падает, часть адресов не переобходится вовсе	каталог целиком не индексируется
таймауты и 5xx	робот резко снижает частоту, страницы вылетают из индекса	потеря уже набранного

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

Бюджет обхода: что это на практике

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

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

Куда чаще всего утекает обход:

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

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

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

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

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

Что с этим делают:

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

Отдельно стоит проверить, не считается ли количество товаров для каждого значения фильтра «на лету» при каждом открытии категории. Это классическая причина, когда категория с тремя тысячами товаров грузится восемь секунд, а карточка внутри неё — за полсекунды.

Тему разбирал отдельно: «Заказать продвижение интернет магазина».

Кэширование: три слоя и что они дают

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

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

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

Кэш запросов к базе. Часто повторяющиеся выборки сохраняются в памяти. Помогает на тяжёлых категориях и фильтрах, где один и тот же список запрашивается сотнями посетителей.

Главная ловушка кэша: корзина и чужие данные

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

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

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

Страница или блок	Кэшировать	Комментарий
Главная, категории, карточки товаров	Да, страничный кэш	основной объём трафика и обхода
Статьи блога, статические страницы	Да, с длинным сроком	меняются редко
Меню, дерево категорий, футер	Да, кэш объектов	одинаковы для всех
Блок корзины в шапке	Нет, только подгружать отдельно	индивидуален для каждого
Страница корзины и оформления заказа	Категорически нет	риск показать чужой заказ
Личный кабинет, история заказов	Категорически нет	персональные данные
Результаты поиска по сайту	Осторожно, коротким сроком	бесконечное число вариантов забьёт диск
Цены и остатки	Только с быстрым сбросом	сброс по событию синхронизации
Формы обратной связи с токеном	Нет	токен протухает, форма перестаёт отправляться

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

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

Тариф хостинга: когда виртуальный перестаёт тянуть

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

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

Признак	Что за ним стоит	Куда смотреть
Сайт «тормозит» в одни и те же часы	упор в лимиты или активность соседей	график нагрузки в панели хостинга
Ошибки 503 и 508 при росте трафика	кончились процессы или превышен лимит	логи ошибок веб-сервера
Админка работает заметно медленнее витрины	тяжёлые запросы к базе, кэш её не спасает	время ответа страниц админки
Импорт каталога падает на середине	лимит времени выполнения скрипта	max_execution_time, логи импорта
Письма и уведомления уходят с задержкой	очередь на общем сервере переполнена	лог почты
Резервная копия делается по несколько часов	дисковая подсистема перегружена	нагрузка на диск
Хостинг пишет о превышении нагрузки	тариф исчерпан, дальше блокировка	письма поддержки, счётчик CP

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

Отдельная деталь для продвижения: физическое расположение сервера. Если основная аудитория в России, а машина стоит за океаном, к времени ответа добавляются сетевые задержки на каждом обращении. На фоне общего медленного ответа эти сто-двести миллисекунд оказываются решающими.

Версия PHP и настройки окружения

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

Что нужно проверить в настройках:

Смежный материал по теме — «Продвижение интернет магазина в интернете».

• memory_limit — для магазина с импортом каталога 256 МБ считается минимумом, часто нужно больше;
• max_execution_time — короткое значение рвёт импорт и выгрузки на середине;
• число процессов PHP-FPM — определяет, сколько посетителей обслуживаются одновременно; при нехватке остальные ждут в очереди, и время ответа растёт лавинообразно;
• OPcache — кэш скомпилированного кода, должен быть включён и иметь достаточный объём памяти;
• лимиты загрузки файлов — важны для файлов выгрузки от поставщика;
• сжатие ответа — уменьшает объём HTML, который забирает робот.

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

База данных: разрастание, мусор и медленные запросы

База магазина растёт быстрее, чем кажется. Через два года работы там оказывается в разы больше строк, чем товаров в каталоге, и большая часть этого объёма никак не участвует в работе витрины.

Что накапливается:

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

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

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

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

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

Что ломается	Как проявляется	Что помогает заранее
Процессы PHP	очередь, время ответа растёт до десятков секунд	увеличить лимит процессов, включить страничный кэш
Подключения к базе	ошибка соединения с базой, белый экран	поднять лимит подключений, кэш объектов
Оформление заказа	заказы не сохраняются, оплата не проходит	исключить из кэша, проверить таймауты платёжного модуля
Поиск по сайту	перестаёт отвечать, тянет за собой весь сервер	вынести в отдельный движок поиска
Диск	кончается место из-за логов и кэша	ротация логов, лимит на размер кэша
Внешние сервисы	чат, аналитика, виджеты подвисают и держат страницу	подгрузка асинхронно, отложенно

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

Синхронизация с 1С и поставщиками

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

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

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

Как настраивают правильно:

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

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

Как понять, что виноват сервер, а не сайт

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

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

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

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

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

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

Шаг пятый. Откройте логи веб-сервера. Там видно, кто именно создаёт нагрузку: настоящие поисковые роботы, парсеры конкурентов, боты-накрутчики или обычные посетители. Нередко половина всех обращений приходится на пару агрессивных сканеров, которых достаточно ограничить.

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

Параметры сервера и их влияние на магазин

Параметр	Как влияет на магазин	Как проверить
Время до первого байта	определяет число страниц, которые робот заберёт за визит	отчёт вебмастера, консоль браузера, замер утилитой в консоли
Тип диска	скорость чтения базы и файлов кэша	тариф хостинга, тест скорости диска
Число процессов PHP	сколько посетителей обслуживаются одновременно без очереди	настройки PHP-FPM, ошибки 503 в логах
Память на процесс	работоспособность импорта и тяжёлых страниц	memory_limit, ошибки «allowed memory exhausted»
Версия PHP	скорость выполнения кода в разы	панель хостинга
Лимит подключений к базе	устойчивость в пик, ошибки соединения	настройки СУБД, лог ошибок
Наличие OPcache	снимает повторную компиляцию кода на каждом запросе	информация о конфигурации PHP
Расположение сервера	сетевая задержка для российской аудитории	трассировка, данные хостинга
Поддержка HTTP/2	параллельная отдача ресурсов страницы	вкладка «Сеть» в браузере
Стабильность (аптайм)	падения роняют индексацию и продажи	внешний мониторинг доступности

Мониторинг: узнавать о проблеме раньше покупателей

Магазин без мониторинга живёт в режиме «узнаём о поломке из звонка клиента». Минимальный набор, который закрывает большую часть рисков:

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

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

Как переезжать на другой сервер без потери позиций

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

Этап	Действие	Чем грозит пропуск
Подготовка	полная копия файлов и базы, проверка её восстановления	нечем откатиться при провале
Подготовка	снять карту всех адресов и кодов ответа до переезда	не с чем сравнить результат
Развёртывание	поднять сайт на новом сервере, проверить по IP или тестовому домену	ошибки увидят посетители
Развёртывание	закрыть тестовую копию от индексации паролем	дубль всего магазина в индексе
Проверка	прогнать краулером весь каталог на новом сервере	битые карточки и потерянные разделы
Проверка	сверить работу корзины, оплаты, синхронизации, писем	заказы не доходят
Проверка	перенести сертификат, проверить редиректы на https и на основное зеркало	смешанный контент, потеря трафика
Переключение	заранее снизить время жизни DNS-записи	часть посетителей сутками на старом сервере
Переключение	перевести обмен с учётной системой на новый адрес	цены и остатки замирают
После	держать старый сервер включённым несколько суток	обрыв для тех, у кого DNS ещё старый
После	следить за 5xx, временем ответа и отчётом обхода две недели	проблему заметят поисковики раньше вас
После	отключить старую копию и убедиться, что она не отвечает	живой дубль магазина

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

Частые ошибки владельцев

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

Разобрать, что тормозит ваш магазин, помогу на SEO-консультации.

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

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

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

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

Как понять, что сайт кладут не посетители, а боты?
По логам веб-сервера: смотрите распределение обращений по адресам и по сетям. Если несколько подсетей дают тысячи запросов в час на страницы фильтров, это парсер или накрутка, и лечится ограничением, а не покупкой ресурсов.

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

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

1:30

Коротко

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