DDoS, боты и парсеры: базовая защита сайта без убийства SEO

Защита сайта от DDoS, ботов и парсеров часто ломает SEO сильнее, чем сама атака. Владелец включает агрессивный firewall, антибот, country block, JavaScript challenge, rate limit или “режим под атакой”, сайт визуально открывается, но Googlebot и ЯндексБот начинают получать 403, 429, 503, капчу, пустой HTML или старую кэшированную версию. Через несколько дней падает обход, потом индексация, потом позиции и трафик.

Проблема не в самой защите. Проблема в грубой защите без понимания разницы между плохими ботами, полезными поисковыми роботами, мониторингом, рекламными системами, API-клиентами и реальными пользователями. В 2026 году сайт почти всегда посещают не только люди: поисковые роботы, AI-краулеры, парсеры цен, сканеры уязвимостей, спам-боты, uptime-мониторинг, платежные webhook, CDN, браузерные prefetch-запросы и боты рекламных сетей. Если резать всё подряд, можно остановить атаку и одновременно убить нормальную видимость сайта в поиске.

Правильная защита строится слоями: сервер с запасом, кэш, CDN/WAF при необходимости, rate limiting по конкретным зонам, проверка логов, аккуратные правила для поисковых роботов, защита форм и админки, мониторинг 403/429/5xx и быстрый откат опасных правил. Цель — не “заблокировать всех ботов”, а отделить вредный трафик от нужного.

Чем отличаются DDoS, боты и парсеры

Эти слова часто смешивают, но для защиты важно разделять сценарии.

DDoS — это атака на доступность. Цель — перегрузить канал, сервер, базу, PHP, backend, форму, поиск, checkout, API или конкретный URL. DDoS может быть большим по трафику, а может быть “низким”, но бить в тяжелую точку сайта: поиск, фильтры каталога, корзину, wp-login.php, xmlrpc.php, REST API, импорт или страницу с медленным SQL-запросом.

Боты — это автоматизированные клиенты. Они бывают полезными и вредными. Googlebot, ЯндексБот, Bingbot и другие поисковые краулеры нужны для индексации. Uptime-боты нужны для мониторинга. Плохие боты подбирают пароли, спамят формы, сканируют уязвимости, создают фейковые аккаунты, нагружают checkout или ищут открытые файлы.

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

Если сайт тормозит, сначала нужно понять, какой тип трафика создает проблему. Нельзя лечить DDoS, парсинг и спам в формах одним правилом “заблокировать всех подозрительных”.

Почему защита может убить SEO

Поисковая система должна иметь возможность получить HTML, CSS, JS, изображения, sitemap.xml, robots.txt и правильные HTTP-ответы. Если защита мешает краулеру, SEO начинает страдать.

Типовые ошибки:

Googlebot или ЯндексБот получает 403 из-за WAF;
поисковым роботам отдается JavaScript challenge или CAPTCHA;
rate limit выдает 429 на sitemap.xml, категории, статьи или карточки товаров;
country block режет дата-центры поисковых систем;
robots.txt или sitemap.xml закрыты firewall-правилом;
CSS/JS заблокированы, и робот видит поломанную страницу;
CDN отдает роботам старый кэш после удаления noindex;
WAF принимает поискового робота за scraper из-за высокой частоты обхода;
администратор блокирует весь ASN облачного провайдера, где есть полезные боты;
включается “under attack” режим на весь сайт без исключений для нужных путей.

В форумах вебмастеров часто встречается один и тот же сценарий: сайт был под атакой, включили жесткую защиту, атака ушла, но через неделю просел трафик. Потом в логах находят 403/429 для Googlebot, ошибки обхода sitemap или массовые 503 на важных страницах. Это не проблема поисковика. Это неправильная фильтрация.

Базовый принцип: защищать не весь сайт одинаково

Не все URL одинаково важны и не все URL одинаково опасны. Главная, статьи, категории, карточки товаров и страницы услуг должны быть доступны поисковикам и пользователям. А вот формы входа, поиск, корзина, checkout, API, xmlrpc.php, wp-login.php, админка и тяжелые фильтры требуют более жесткой защиты.

Правильная модель:

публичные SEO-страницы — максимально доступны, кэшируемы и стабильны;
админка — закрыта по IP, VPN, 2FA или дополнительной авторизации;
формы — защищены от спама и частых POST-запросов;
поиск и фильтры — ограничены по частоте, потому что могут грузить базу;
API — защищен ключами, лимитами и логированием;
медиа — отдаются через кэш/CDN при необходимости;
sitemap.xml и robots.txt — всегда доступны нормальным краулерам;
checkout и личный кабинет — защищены аккуратно, без кэширования персональных данных.

Если одно правило применяется ко всему сайту, оно почти наверняка будет слишком мягким для опасных зон и слишком жестким для SEO-страниц.

Что проверить до включения защиты

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

Какие URL получают больше всего запросов?
Какие IP или подсети создают нагрузку?
Какие user-agent встречаются чаще всего?
Есть ли много POST-запросов?
Есть ли атака на wp-login.php, xmlrpc.php, /search, /api, /cart, /checkout?
Какие статусы растут: 403, 404, 429, 500, 502, 503, 504?
Есть ли всплеск запросов к sitemap.xml или конкретным категориям?
Получают ли Googlebot и ЯндексБот нормальные 200?
Не упирается ли сервер в CPU, RAM, диск, PHP-FPM или базу?
Работает ли кэш для публичных страниц?

Начинайте с access/error logs. Если логов нет или они хранятся слишком мало, вы не контролируете ситуацию. На VPS нужно хранить логи достаточно долго, чтобы сравнить нормальный день, день атаки и период после включения защиты.

Как отличить полезного поискового робота от подделки

Нельзя доверять только user-agent. Любой плохой бот может написать в user-agent “Googlebot”. Для первичной фильтрации user-agent полезен, но для whitelist важных роботов нужна проверка подлинности.

Для Googlebot и ЯндексБота используется проверка через reverse DNS и forward DNS. Логика простая: сначала проверяется, что IP действительно резолвится в домен поисковой системы, затем этот домен обратно резолвится в тот же IP. Если этого не делать, вы можете разрешить вредного бота, который просто притворился поисковым.

Практический вывод: не добавляйте в исключения всех, кто назвался Googlebot. Добавляйте только проверенных роботов или используйте надежные механизмы CDN/WAF, которые умеют отличать verified bots.

Какие HTTP-статусы опасны для SEO при защите

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

403 Forbidden

Опасен, если его получают поисковые роботы, пользователи из целевых стран, CSS/JS, изображения, sitemap.xml или robots.txt. 403 говорит: “доступ запрещен”. Если так отвечает важная страница, поисковик может снизить обход и убрать URL из нормальной выдачи.

429 Too Many Requests

Нормален для защиты от агрессивных запросов, но опасен для краулеров, если лимиты слишком жесткие. Поисковые роботы могут запрашивать много страниц, особенно после обновления sitemap или миграции. Если они получают 429 на нормальных URL, индексация может замедлиться.

503 Service Unavailable

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

500/502/504

Эти статусы часто показывают, что проблема глубже: PHP-FPM падает, база тормозит, backend не отвечает, серверу не хватает ресурсов или тяжелые URL пробивают кэш. DDoS-защита на уровне firewall не исправит плохую архитектуру приложения.

После любой защиты проверяйте в логах: Googlebot, ЯндексБот, Bingbot, sitemap.xml, robots.txt, главная, категории, статьи, услуги, карточки товаров и страницы, которые приносят трафик.

Базовая защита WordPress без вреда для SEO

WordPress чаще всего страдает от атак на wp-login.php, xmlrpc.php, REST API, формы комментариев, поиск, уязвимые плагины, загрузку файлов и старые темы. Но блокировать весь сайт из-за атаки на login — плохая практика.

Минимальные меры:

закрыть wp-login.php по IP, VPN или дополнительной авторизации, если это возможно;
отключить или ограничить xmlrpc.php, если он не нужен;
включить 2FA для администраторов;
ограничить частоту POST-запросов к формам;
защитить комментарии и формы от спама;
обновить WordPress, темы и плагины;
удалить nulled-темы и старые неиспользуемые плагины;
запретить выполнение PHP в uploads;
настроить page cache для публичных страниц;
не кэшировать корзину, checkout, личный кабинет и персональные страницы;
следить за 403/429/5xx в логах после включения правил.

Для WordPress нельзя включать все security-настройки одновременно и не проверять результат. После каждого изменения нужно открыть сайт как обычный пользователь, проверить мобильную версию, формы, поиск, sitemap, robots, страницы услуг, статьи, checkout и логи поисковых роботов.

Rate limiting: где он нужен, а где опасен

Rate limiting — один из самых полезных инструментов против ботов, но его легко настроить неправильно. Нельзя ставить один жесткий лимит на весь сайт. У поискового робота, реального пользователя, бота атаки, API-клиента и сканера разные паттерны.

Где rate limit обычно нужен:

страницы входа;
формы регистрации;
формы комментариев;
поиск по сайту;
фильтры каталога;
REST API;
дорогие POST-запросы;
страницы восстановления пароля;
checkout при подозрительной активности;
URL, которые создают тяжелые SQL-запросы.

Где rate limit нужно применять осторожно:

sitemap.xml;
robots.txt;
статические CSS/JS;
изображения;
категории и статьи;
страницы, которые активно обходят поисковые роботы;
страницы с высоким рекламным трафиком;
API платежей и webhook.

Если после rate limiting в логах растет 429 для поисковых роботов, правило нужно смягчать или делать исключения. 429 — нормальный инструмент, но не для важных краулеров и не для страниц, которые должны индексироваться.

CDN и WAF: когда помогают, а когда мешают

CDN помогает отдавать статику, снижать нагрузку на origin-сервер, фильтровать часть плохого трафика и переживать всплески. WAF помогает блокировать типовые атаки, SQL injection, XSS, подозрительные запросы, вредные user-agent и аномальную активность. Но CDN/WAF нужно настраивать, а не просто включать “максимальную защиту”.

Что проверить после подключения CDN/WAF:

Googlebot и ЯндексБот получают 200 на важных страницах;
sitemap.xml и robots.txt доступны;
CSS, JS и изображения не блокируются;
нет CAPTCHA для поисковых роботов;
нет 403/429 на SEO-страницах;
canonical, hreflang и robots meta не отдаются из старого кэша;
origin IP не открыт для обхода CDN, если это важно;
реальный IP пользователя корректно передается в логи;
правила не ломают checkout, API, формы и личный кабинет;
можно быстро отключить или смягчить правило, если оно ударит по SEO.

Режимы вроде “Under Attack” могут быть полезны во время L7-атаки, но плохо подходят как постоянная настройка для всего сайта. Если каждый посетитель и бот получает challenge, поисковое сканирование может пострадать. Такие режимы нужно включать точечно и временно.

Как защищаться от парсеров без блокировки поисковиков

Парсеры сложнее обычных ботов. Они могут имитировать браузер, менять IP, использовать residential proxies, подставлять популярные user-agent и обходить простые блокировки. Поэтому защита от парсинга должна быть прагматичной: не пытаться полностью запретить копирование всего, а снижать ущерб и защищать самые дорогие зоны.

Что работает лучше грубой блокировки:

ограничение частоты запросов к дорогим страницам;
кэширование публичных страниц, чтобы парсер не бил по базе;
отдельные лимиты для поиска, фильтров и API;
логирование аномальных паттернов;
блокировка конкретных IP/ASN только после проверки;
защита изображений и медиа через hotlink protection, если это уместно;
водяные знаки или технические метки для контента, если важно доказать копирование;
закрытие служебных API, которые не должны быть публичными;
ограничение экспорта больших списков;
невыдача полной базы через один endpoint.

Плохая идея — закрыть весь сайт за авторизацию или JavaScript challenge только из-за парсеров. Да, парсеру станет сложнее. Но поисковикам, пользователям, рекламным системам и AI-ассистентам тоже. Для SEO-проекта это часто слишком дорогая цена.

Как защитить сайт от L7 DDoS

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

Базовая защита:

кэшировать публичные страницы;
выносить статику на CDN;
ограничивать тяжелые POST-запросы;
закрывать админку по IP/VPN;
ограничивать поиск и фильтры;
настраивать PHP-FPM, OPcache, Redis/object cache;
оптимизировать базу данных;
отключать ненужные endpoints;
включать WAF-правила по конкретным атакам;
мониторить 5xx, CPU, RAM, диск, network, slow queries и PHP-FPM;
иметь план быстрого переключения на усиленную защиту.

Если атака большая по каналу или пакетам, одних Nginx-правил на VPS недостаточно. Нужна защита выше уровня сервера: провайдерская DDoS-фильтрация, CDN, специализированная защита или перенос на инфраструктуру, которая выдерживает такой тип атаки. VPS не должен быть единственным барьером против объемной DDoS-атаки.

Как не сломать индексацию при country block

Блокировка стран иногда выглядит привлекательной: “мы работаем только с одной страной, остальное запретим”. Но поисковые роботы, CDN, мониторинг, рекламные сервисы и пользователи могут приходить из разных регионов и дата-центров. Грубый country block может случайно закрыть поисковое сканирование или важные сервисы.

Если country block нужен, проверьте:

из каких регионов реально приходят поисковые роботы;
не блокируются ли Googlebot, ЯндексБот и Bingbot;
доступны ли sitemap.xml и robots.txt;
не блокируются ли платежные webhook;
не блокируются ли CDN, мониторинг и API;
не теряются ли пользователи из целевых стран из-за VPN/роуминга;
какие статусы получают заблокированные пользователи и роботы.

Для SEO-сайта country block нужно применять осторожно. Часто лучше защищать конкретные опасные URL и паттерны, чем закрывать половину интернета на уровне страны.

Как читать логи после включения защиты

После включения защиты нужно проверять не только “атака ушла”, но и “SEO не пострадало”.

Минимальный набор проверок:

статусы для Googlebot;
статусы для ЯндексБота;
статусы для Bingbot;
доступность sitemap.xml;
доступность robots.txt;
рост 403;
рост 429;
рост 5xx;
ошибки WAF/CDN;
медленные URL;
нагрузка на PHP-FPM и базу;
проверка важных страниц из разных регионов и user-agent.

Примеры быстрых проверок на VPS:

grep -i "Googlebot" /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c | sort -nr

grep -Ei "YandexBot|YandexMobileBot" /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c | sort -nr

awk '$9 == 403 || $9 == 429 {print $7, $9, $12}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 50

awk '$9 ~ /^50/ {print $7, $9}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 50

Важно: команды зависят от формата логов. В вашем access log HTTP-статус может быть не в поле $9. Сначала откройте несколько строк и проверьте формат.

Что нельзя делать при атаке

В панике часто принимают решения, которые потом дорого чинить.

Не закрывайте весь сайт за CAPTCHA без проверки SEO-последствий.
Не блокируйте всех ботов по user-agent.
Не блокируйте Googlebot/ЯндексБот только потому, что они делают много запросов.
Не включайте жесткий rate limit на весь сайт.
Не закрывайте robots.txt и sitemap.xml.
Не отдавайте 403 на публичные SEO-страницы.
Не блокируйте целые страны без проверки краулеров и платежных сервисов.
Не держите “Under Attack” режим постоянно без необходимости.
Не чистите логи сразу после инцидента.
Не меняйте одновременно CDN, WAF, кэш, DNS и сервер без плана отката.

Самая опасная ошибка — считать, что если сайт открылся у владельца, значит всё хорошо. SEO может страдать в тот момент, когда у владельца всё открывается: робот получает 403, мобильная версия получает challenge, sitemap закрыт, а пользователи из другого региона видят 503.

Что делать, если сайт уже просел после защиты

Если после включения защиты упали позиции или трафик, не отключайте всё вслепую. Сначала найдите, какое правило ударило по индексации.

Проверьте Search Console и Яндекс Вебмастер.
Посмотрите crawl errors и статистику обхода.
Проверьте access log по Googlebot/ЯндексБоту за даты падения.
Найдите 403, 429, 503 и 5xx по важным URL.
Проверьте, доступен ли sitemap.xml.
Проверьте robots.txt.
Проверьте, не получил ли сайт noindex через кэш или заголовки.
Проверьте CDN/WAF events.
Проверьте, не блокируется ли CSS/JS.
Сравните HTML для обычного пользователя и поискового робота.

Если виноват WAF, смягчите правило. Если виноват rate limit, разделите лимиты по URL. Если виноват country block, сделайте исключения. Если виноват перегруз сервера, усиливайте инфраструктуру, кэш и базу. Если атака продолжается, включайте защиту точечно и временно, а не ломайте весь сайт.

Когда нужен VPS, Power VPS или dedicated

Защита от ботов зависит не только от правил, но и от ресурсов. Если сайт еле работает в нормальном режиме, небольшой всплеск ботов положит его без всякого DDoS. Shared-хостинг часто ограничивает CPU, процессы, PHP, базу и логи. На VPS больше контроля: можно настраивать Nginx, PHP-FPM, Redis, firewall, access logs, rate limits, fail2ban, backup и мониторинг.

VPS подходит, если:

сайт на WordPress, OpenCart, Bitrix, Laravel или другой CMS требует контроля сервера;
нужны логи и диагностика;
нужно настроить firewall и rate limiting;
нужен Redis/object cache;
сайт страдает от ботов, но атака не объемная по каналу;
нужна изоляция от соседей shared-хостинга.

Power VPS или dedicated стоит рассматривать, если:

много динамических страниц;
есть WooCommerce, LMS, каталог, личные кабинеты или API;
атаки бьют в базу, поиск или фильтры;
нужен запас CPU/RAM/NVMe;
сайт получает большие пики трафика;
нужно разделить backend, базу, кэш и статику;
простои напрямую влияют на деньги.

Для обычного сайта можно начать с VPS от Xhost24. Для тяжелых проектов, WooCommerce, LMS, каталогов, медиа-сайтов и высокой динамической нагрузки лучше смотреть Power VPS или заранее обсуждать dedicated-конфигурацию через тикет.

Когда защита на VPS не поможет

VPS не заменяет полноценную DDoS-защиту от большой сетевой атаки. Если атака забивает канал до сервера, правила Nginx уже не спасут: плохой трафик должен фильтроваться выше. Также VPS не исправит плохое приложение, если каждая страница делает тяжелые SQL-запросы, поиск не ограничен, кэш не работает, а WordPress забит уязвимыми плагинами.

VPS также не решает юридические и abuse-риски. Если с сайта идет malware, phishing, spam, вредоносные редиректы или атаки на другие ресурсы, провайдер будет реагировать на жалобы. Защита от ботов не должна превращаться в попытку скрыть запрещенную активность.

Практический план базовой защиты

Для большинства сайтов рабочий план выглядит так:

Включить нормальный access/error logging.
Настроить мониторинг доступности, 5xx, диска, CPU, RAM и SSL.
Обновить CMS, темы, плагины и серверные пакеты.
Настроить кэш публичных страниц.
Закрыть админку по IP/VPN или усилить 2FA.
Ограничить wp-login.php, xmlrpc.php, формы, поиск, фильтры и API.
Проверить, что sitemap.xml и robots.txt доступны.
Проверить, что Googlebot и ЯндексБот не получают 403/429/5xx.
Подключить CDN/WAF при необходимости, но не включать максимальную защиту вслепую.
Разделить лимиты по типам URL.
Настроить backup вне сервера.
После каждого изменения проверять логи и важные страницы.

Этого достаточно для базовой защиты от большинства простых ботов, спама, парсеров и небольших L7-нагрузок. Для серьезных DDoS-атак нужна отдельная схема защиты и согласование с провайдером.

Как Xhost24 может помочь

Xhost24 может помочь, если сайту нужна изоляция на VPS, контроль логов, настройка firewall, rate limiting, кэша, PHP-FPM, Redis, backup и мониторинг без грубой блокировки поисковых роботов. Для обычных сайтов можно смотреть VPS-тарифы. Для тяжелых CMS, WooCommerce, LMS, каталогов, API и проектов с высокой нагрузкой лучше оценить Power VPS.

Если сайт уже страдает от ботов, DDoS или парсеров, в тикете лучше сразу указать: домен, тип CMS, симптомы, время атаки, примеры access/error logs, есть ли CDN/WAF, какие URL нагружаются, какие статусы получают Googlebot/ЯндексБот, есть ли 403/429/5xx, какой трафик считается нормальным и какие страницы нельзя блокировать из-за SEO.

Если нет своего администратора, можно заранее обсудить услуги администрирования: перенос на VPS, hardening, настройку Nginx/Apache, firewall, PHP-FPM, Redis, backup, мониторинг и базовые правила против ботов. Правильная цель — защитить сайт так, чтобы он оставался доступным для пользователей и поисковых систем.

Смотреть VPS для сайта или открыть тикет для настройки защиты. Для быстрых вопросов по серверу, IP, переносу и условиям можно написать в Telegram: @xhost24.

FAQ: DDoS, боты, парсеры и SEO

Можно ли полностью заблокировать всех ботов?

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

Почему после включения защиты упал трафик из Google?

Частая причина — Googlebot начал получать 403, 429, 503, CAPTCHA, JavaScript challenge или пустой HTML. Нужно проверить access logs, CDN/WAF events, sitemap.xml, robots.txt и статусы важных страниц.

Можно ли показывать CAPTCHA поисковым роботам?

Нет, это плохая практика. Поисковый робот должен получать нормальный HTML страницы, а не challenge. Если CAPTCHA включена для всего сайта, индексация может пострадать.

Что лучше против парсеров: robots.txt или firewall?

Robots.txt работает только для добросовестных роботов. Вредные парсеры могут его игнорировать. Firewall, WAF и rate limiting нужны для принудительной защиты, но их нужно настраивать осторожно, чтобы не блокировать поисковые системы.

Опасен ли статус 429 для SEO?

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

Нужно ли блокировать страны, откуда идет атака?

Иногда это помогает, но грубый country block может заблокировать поисковых роботов, CDN, мониторинг, платежные webhook и реальных пользователей. Лучше сначала смотреть логи и блокировать конкретные паттерны.

Поможет ли CDN от DDoS?

CDN помогает против части L7-атак, снижает нагрузку на origin и фильтрует часть плохого трафика. Но он не решает все типы DDoS и может навредить SEO при неправильных WAF-правилах. После подключения CDN нужно проверить логи и статусы для поисковых роботов.

Как защитить WordPress от ботов?

Обновить CMS, темы и плагины, закрыть wp-login.php, ограничить xmlrpc.php, включить 2FA, защитить формы, настроить кэш, firewall, rate limits, мониторинг логов и внешний backup. Не нужно закрывать весь сайт за CAPTCHA из-за атаки на админку.

Когда нужен VPS для защиты от ботов?

VPS нужен, когда shared-хостинг не дает контроля над логами, firewall, PHP-FPM, Redis, кэшем, лимитами и мониторингом. Для серьезных атак по каналу может потребоваться не только VPS, но и внешняя DDoS-фильтрация.

Что отправить в поддержку при атаке?

Домен, время атаки, тип CMS, примеры логов, список нагружаемых URL, статусы 403/429/5xx, наличие CDN/WAF, данные по Googlebot/ЯндексБоту, текущие правила защиты и описание, какие страницы критичны для SEO и не должны блокироваться.

База знаний

Категории

Категории