Технический SEO-аудит сервера помогает понять, почему сайт плохо индексируется, медленно открывается или теряет страницы из поиска. Для малого бизнеса в Беларуси достаточно начать с десяти проверок: доступность сайта, ответы сервера, HTTPS, скорость, индексация, robots.txt, карта сайта, дубли, мобильная версия и резервное копирование. В статье разберём, что проверить владельцу VPS самостоятельно и какие задачи лучше передать администратору.
Зачем проверять сервер вместе с сайтом?
SEO зависит не только от заголовков и текстов. Поисковый робот должен получить корректный ответ от сервера, скачать страницу без задержек и понять, какую версию URL считать основной. Если VPS перегружен, сайт периодически отдаёт ошибку или сервер закрывает доступ к файлам, поисковая система не сможет нормально обработать даже хорошо подготовленный материал.
Технический SEO-чек-лист на 2026 год обычно включает управление обходом, серверные ответы, скорость, Core Web Vitals и разметку Schema.org. В одном из опубликованных чек-листов технического SEO эти направления собраны в десять функциональных групп и более шестидесяти отдельных проверок (Cropas). Для небольшого сайта такой объём можно разделить на регулярный контроль и разовый аудит.
Какие десять проверок нужно выполнить на VPS?
- Доступность сайта. Откройте главную страницу, несколько внутренних страниц и страницу ошибки. Проверьте сайт через мобильный интернет и обычное подключение. Если ресурс недоступен, сначала ищите причину в VPS, веб-сервере, DNS или сроке действия домена.
- Коды ответа. Рабочие страницы должны отдавать ответ 200. Перемещённые страницы направляют на новый адрес постоянным редиректом 301. Несуществующие страницы получают 404 или 410, а не копию главной страницы. Ошибки 5xx требуют проверки нагрузки, журналов и состояния приложений.
- HTTPS и сертификат. Проверьте, что сайт открывается по защищённому протоколу, сертификат не просрочен, а обращения к HTTP переходят на единственную HTTPS-версию. Отдельно проверьте изображения, стили и скрипты: смешанное содержимое часто появляется после переноса сайта.
- Скорость ответа сервера. Измерьте время до первого байта в часы обычной нагрузки. Причиной задержки бывает медленная база данных, отсутствие кеширования, нехватка оперативной памяти или большое число фоновых процессов. На VPS полезно смотреть загрузку CPU, RAM, диска и сетевого канала.
- Стабильность ресурсов. Убедитесь, что сервер не уходит в swap при обычных запросах и не заполняет диск логами или резервными копиями. Если заканчивается место, веб-сервер и база данных начинают работать непредсказуемо. Для диагностики сохраните графики нагрузки хотя бы за несколько рабочих дней.
- Файл robots.txt. Проверьте, что правила не закрывают весь сайт или важные разделы. В файле можно указать адрес карты сайта, но сам robots.txt не заменяет настройку индексации страниц.
- XML-карта сайта. В sitemap.xml должны попадать канонические, доступные для робота страницы с ответом 200. Не добавляйте туда адреса фильтров, корзины, личного кабинета и страницы с переадресацией. После изменений проверьте дату обновления и корректность XML.
- Дубли URL. Один материал может открываться с разными параметрами, со слешем и без него, через HTTP и HTTPS или с разными вариантами регистра. Выберите основную версию, настройте редиректы и укажите canonical там, где редирект не подходит.
- Мобильная загрузка. Проверьте страницу на телефоне: меню, формы, изображения, шрифты и таблицы. Большой файл изображения или блокирующий скрипт часто замедляет мобильную версию сильнее, чем десктопную.
- Логи и мониторинг. Просмотрите журналы веб-сервера и приложения. Они покажут частые 404, ошибки PHP, обращения роботов и пики нагрузки. Для постоянного контроля полезно настроить мониторинг VPS, чтобы узнавать о недоступности сайта до обращения посетителей.
Как отличить проблему сайта от проблемы VPS?
Начните с простого разделения. Если сервер не отвечает ни на главную страницу, ни на статический файл, проверяйте сеть, веб-сервер, DNS и firewall. Если статический файл открывается, а каталог или карточка товара загружается медленно, ищите причину в CMS, базе данных, PHP и подключаемых модулях.
Логи помогают увидеть момент сбоя. В журнале веб-сервера ищут коды 499, 502, 503 и 504, а в журнале приложения — ошибки выполнения и нехватку памяти. После исправления одну и ту же страницу стоит проверить несколько раз: единичный успешный ответ ещё не доказывает стабильность.
Для CMS с большим каталогом отдельное внимание уделите базе данных и кешу. Не запускайте тяжёлую оптимизацию в часы, когда сайт принимает заказы. Сначала создайте резервную копию, затем проверьте изменения на копии или в отдельном окружении.
Как проверить индексацию после исправлений?
Составьте список важных URL: главная страница, разделы, карточки товаров или услуг, контакты и документы, которые действительно должны находиться через поиск. Для каждого адреса зафиксируйте код ответа, canonical, наличие в sitemap.xml и запрет в robots.txt. Такая таблица быстро показывает конфликтующие настройки.
| Проверка | Что должно быть | Что делать при ошибке |
|---|---|---|
| Основной URL | Одна версия адреса | Настроить 301 или canonical |
| Ответ страницы | 200 для доступного материала | Проверить веб-сервер и приложение |
| robots.txt | Важные разделы открыты | Убрать лишние запреты |
| sitemap.xml | Только нужные URL | Удалить дубли и ошибки |
| Мобильная версия | Страница читается и загружается | Сжать ресурсы и проверить шаблон |
После изменения редиректов проверьте цепочки. Запрос к старому адресу должен приводить к конечной странице без нескольких последовательных переадресаций. Подробный разбор этой задачи есть в материале как настроить 301-редиректы на VPS и сохранить позиции сайта.
Если сайт использует структурированные данные, проверьте разметку Schema.org на страницах, где она действительно описывает содержимое. Удаляйте поля, которым нет подтверждения на самой странице. Некорректная разметка не ускоряет индексацию и может создавать противоречия для поискового робота.
Какие типичные ошибки мешают техническому SEO?
- Все неизвестные адреса перенаправляют на главную страницу, поэтому ошибка 404 превращается в скрытый дубль.
- В robots.txt закрывают раздел, который случайно содержит важные страницы.
- В sitemap.xml оставляют старые URL после смены структуры каталога.
- Редиректы настроены цепочкой: HTTP ведёт на www, затем на HTTPS, затем на новый путь.
- Резервные копии хранят на том же диске VPS, поэтому отказ диска уничтожает и сайт, и копии.
- После обновления CMS не проверяют PHP-ошибки, кеш и потребление памяти.
Как организовать регулярную проверку?
Разовый аудит показывает состояние сайта в конкретный день, но серверная проблема может появиться после обновления CMS, установки модуля или изменения конфигурации. Для небольшого бизнеса достаточно назначить ответственного и хранить короткий журнал: дата проверки, доступность, ошибки 5xx, свободное место, нагрузка и результат проверки важных URL.
Еженедельно проверяйте доступность, свободное место и резервное копирование. После каждого изменения DNS, сертификата, структуры URL или серверного ПО повторяйте проверки HTTPS, редиректов, robots.txt и sitemap.xml. Для автоматизации развёртывания и одинаковых настроек на нескольких VPS можно изучить настройку Ansible для управления VPS.
3 шага, которые можно сделать на этой неделе:
- Соберите список из десяти важных страниц и запишите для них коды ответа, canonical и наличие в карте сайта.
- Проверьте журналы VPS, свободное место, нагрузку CPU и RAM, а также работу резервных копий.
- Исправьте одну найденную проблему, после чего повторите проверку с компьютера и телефона.
Если после этих действий остаются ошибки 5xx, нестабильная скорость или непонятные редиректы, причина обычно требует одновременной проверки веб-сервера, CMS и базы данных. В таком случае техническое SEO-аудирование логично проводить вместе с оптимизацией VPS и настройкой безопасного хостинга, чтобы исправления не ограничивались одной страницей.
