Как читать access/error logs при падении трафика

Когда трафик сайта падает, владельцы часто сразу ищут проблему в SEO: апдейт Google, плохие ссылки, конкуренты, санкции, контент. Это может быть правдой, но есть слой, который многие пропускают, — серверные логи. Access log и error log показывают то, чего не видно в PageSpeed, Search Console, Яндекс Вебмастере и SEO-сервисах: кто реально заходил на сайт, какие URL запрашивал, какие статусы получал, были ли ошибки 500/502/503/504, блокировался ли Googlebot, не отдавал ли сервер noindex-страницы, редиректы, пустые ответы или старый кэш.

В 2026 году лог-анализ стал еще важнее. Поисковая выдача меняется быстрее, сайты чаще стоят за CDN/WAF, WordPress работает через кэш-плагины, а часть трафика уходит в AI-ответы, агрегаторы и zero-click. Но серверные логи остаются фактической записью запросов. Если поисковый робот пришел на страницу и получил 503, это будет видно в access log. Если PHP упал из-за памяти, это будет видно в error log. Если WAF начал отдавать 403 для Googlebot или ЯндексБота, это тоже можно найти в логах.

Главная ошибка — смотреть только график трафика. График показывает, что проблема есть. Логи помогают понять, была ли техническая причина.

Что такое access log и error log простыми словами

Access log — это журнал запросов к сайту. В нем видно, кто пришел, когда пришел, какой URL запросил, какой HTTP-статус получил, какой user-agent использовал, сколько байт получил и иногда сколько времени сервер обрабатывал запрос.

Error log — это журнал ошибок сервера и приложения. В нем видно, почему сайт отдавал 500, почему PHP завершился с ошибкой, почему Nginx не смог подключиться к PHP-FPM, почему Apache получил permission denied, почему закончилась память, почему не найден файл или почему upstream не ответил.

Access log отвечает на вопрос: “Что запрашивали и какой ответ получили?”. Error log отвечает на вопрос: “Почему сломалось?”. При падении трафика их нужно читать вместе. Один access log без error log часто показывает только симптом. Один error log без access log не показывает, какие страницы и роботы пострадали.

Где обычно лежат логи

Пути зависят от панели, веб-сервера и дистрибутива. На VPS чаще встречаются такие варианты:

/var/log/nginx/access.log
/var/log/nginx/error.log

/var/log/apache2/access.log
/var/log/apache2/error.log

/var/log/httpd/access_log
/var/log/httpd/error_log

/var/log/php*-fpm.log
/var/log/mysql/error.log
/var/log/mariadb/mariadb.log

Если используется панель управления, логи могут лежать в директориях конкретного домена. Например, в структурах панели часто есть отдельные access/error logs для каждого сайта. Если сайт находится за CDN, часть запросов может быть видна в логах CDN, а на origin-сервере будет меньше прямых обращений. Это важно учитывать: падение запросов в origin access log после включения CDN не всегда означает падение трафика. Но ошибки origin-сервера, блокировки, редиректы и проблемы с ботами всё равно нужно проверять.

Что смотреть первым при падении трафика

Не начинайте с чтения всех логов подряд. Сначала сузьте проблему.

Когда началось падение: дата и примерное время?
Падение резкое или постепенное?
Просел Google, Яндекс, Bing, direct, referral или весь трафик?
Просели все страницы или отдельный раздел?
Пострадала мобильная или desktop-версия?
Были ли перенос сайта, смена DNS, настройка CDN, WAF, кэша, редиректов, обновление WordPress, смена темы, переход на VPS?
Есть ли ошибки в Search Console / Яндекс Вебмастере?
Не было ли падения сервера, переполнения диска, проблем с SSL или базы данных?

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

Как читать строку access log

Типичная строка Nginx/Apache может выглядеть так:

66.249.66.1 - - [23/Jun/2026:10:15:42 +0000] "GET /blog/example-page/ HTTP/1.1" 200 18432 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

В этой строке важно:

IP — кто сделал запрос;
дата и время — когда был запрос;
метод — GET, POST, HEAD;
URL — какая страница запрошена;
HTTP-статус — что ответил сервер;
размер ответа — сколько байт отдано;
referer — откуда пришел пользователь, если передан;
user-agent — браузер, бот или инструмент.

Если в формате логов есть request_time, upstream_response_time, host, scheme, cache_status или x-forwarded-for, анализ становится намного полезнее. На VPS стоит настроить расширенный формат access log заранее, а не после инцидента. Когда трафик уже упал, старых данных может не быть.

Какие HTTP-статусы важны для SEO

При падении трафика смотрите не только количество визитов, а распределение статусов.

200

Страница отдается успешно. Но 200 не всегда означает, что всё хорошо. Сервер может отдавать 200 для пустой страницы, страницы с ошибкой внутри HTML, страницы с noindex, страницы “товар не найден” или страницы с вредоносным редиректом через JavaScript. Поэтому 200 нужно проверять выборочно по содержимому.

301 и 302

Редиректы нормальны, если они настроены осознанно. Проблема начинается, когда после миграции появляются цепочки редиректов, циклы, редиректы всех старых страниц на главную, временный 302 вместо постоянного 301 или разные редиректы для мобильных и desktop-пользователей. В логах это видно как большое число 301/302 по важным URL.

304

Not Modified. Обычно нормальный статус для кэширования. Сам по себе не проблема.

403

Доступ запрещен. Опасно, если 403 получают Googlebot, ЯндексБот, пользователи из целевых стран, CSS/JS, изображения, sitemap.xml или важные страницы. Частая причина — WAF, firewall, антибот, неверные права файлов, защита по IP, country block или ошибка в .htaccess/Nginx rules.

404

Страница не найдена. Небольшое количество 404 нормально. Проблема — массовые 404 по URL, которые раньше приносили трафик, имеют внешние ссылки, есть в sitemap, участвуют во внутренней перелинковке или появились после смены структуры сайта.

410

Страница удалена навсегда. Нормально, если это осознанное удаление. Плохо, если 410 начал отдаваться случайно для живых страниц.

429

Too Many Requests. Очень важный статус. Если его получают поисковые роботы, CDN, API или реальные пользователи, сервер или WAF может слишком агрессивно ограничивать частоту запросов. После включения rate limit это частая причина падения обхода и индексации.

500

Внутренняя ошибка приложения. Для WordPress часто связана с PHP fatal error, конфликтом плагинов, нехваткой памяти, ошибкой темы, поврежденной базой или лимитами сервера.

502

Bad Gateway. Часто означает, что Nginx не получил нормальный ответ от PHP-FPM, Apache, Node.js или другого upstream. Может появляться при перегрузе, падении PHP-FPM, нехватке worker-процессов или ошибке backend-сервиса.

503

Service Unavailable. Для SEO опасен, если возникает часто или долго. Может быть из-за перегруза, maintenance mode, лимитов хостинга, отключенной базы, проблем с приложением или неправильной защиты.

504

Gateway Timeout. Сервер слишком долго ждал ответ от backend. Часто связано с тяжелыми запросами к базе, медленным PHP, внешними API, импортами, cron-задачами, WooCommerce, LMS, каталогами и слабым VPS/shared-хостингом.

Как быстро посмотреть проблемные статусы

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

Посмотреть последние строки access log:

tail -n 100 /var/log/nginx/access.log

Смотреть лог в реальном времени:

tail -f /var/log/nginx/access.log

Посчитать HTTP-статусы:

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

Найти ошибки 500/502/503/504:

awk '$9 ~ /^50/ {print}' /var/log/nginx/access.log | tail -n 100

Найти 403 и 429:

awk '$9 == 403 || $9 == 429 {print}' /var/log/nginx/access.log | tail -n 100

Найти запросы Googlebot:

grep -i "Googlebot" /var/log/nginx/access.log | tail -n 100

Найти запросы ЯндексБота:

grep -Ei "YandexBot|YandexImages|YandexMobileBot" /var/log/nginx/access.log | tail -n 100

Посмотреть, какие URL чаще всего дают 404:

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

Посмотреть, какие URL чаще всего дают 5xx:

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

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

Как понять, что Googlebot или ЯндексБот реально пострадал

Недостаточно увидеть строку с user-agent Googlebot. User-agent можно подделать. Для точной проверки Googlebot нужно верифицировать по reverse DNS и forward DNS, особенно если речь о блокировках, подозрительном трафике или спорных IP.

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

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

Если среди ответов много 403, 429, 500, 502, 503 или 504 — это красный сигнал. Дальше нужно смотреть конкретные URL:

grep -i "Googlebot" /var/log/nginx/access.log | awk '$9 != 200 {print $7, $9}' | sort | uniq -c | sort -nr | head -n 50

Если Googlebot получает ошибки только на мусорных URL, это не всегда критично. Если ошибки идут по страницам услуг, категориям, карточкам товаров, статьям, sitemap.xml, robots.txt или главным разделам — это может напрямую влиять на индексацию и трафик.

Что искать в error log

Error log нужно читать в те же даты и часы, когда в access log появились ошибки или когда началась просадка трафика.

Посмотреть последние ошибки Nginx:

tail -n 200 /var/log/nginx/error.log

Смотреть error log в реальном времени:

tail -f /var/log/nginx/error.log

Найти PHP fatal errors:

grep -Ei "fatal|PHP Fatal|Allowed memory size|segmentation|panic" /var/log/nginx/error.log | tail -n 100

Найти проблемы upstream/PHP-FPM:

grep -Ei "upstream|connect\\(\\) failed|timed out|recv\\(\\) failed|bad gateway" /var/log/nginx/error.log | tail -n 100

Типовые записи, на которые нужно обратить внимание:

connect() failed — Nginx не смог подключиться к PHP-FPM или upstream;
upstream timed out — backend слишком долго отвечал;
client intended to send too large body — лимит загрузки файла слишком мал;
permission denied — проблема с правами файлов или директорий;
Primary script unknown — неверный путь к PHP-скрипту или конфигурации;
Allowed memory size exhausted — PHP не хватает памяти;
too many open files — системные лимиты;
no space left on device — закончился диск или inode;
database connection error — проблема с MySQL/MariaDB или WordPress;
SSL_do_handshake failed — проблемы TLS/SSL или подозрительные подключения.

Если error log показывает ошибки в момент, когда поисковые роботы получали 5xx, причина просадки может быть технической. Если error log чистый, а трафик просел, проблема может быть в индексации, контенте, SERP, редиректах, robots/noindex, ссылках, апдейте поисковика или изменении спроса.

Частые сценарии падения трафика, которые видно в логах

1. После переноса сайта появились массовые 404

В логах видно, что старые URL запрашиваются, но сервер отвечает 404. Обычно это происходит после смены структуры ссылок, переезда с другой CMS, неправильного импорта WordPress, удаления категорий или отсутствия редиректов.

Что делать: собрать список старых URL с трафиком и внешними ссылками, настроить 301-редиректы на релевантные новые страницы, обновить sitemap и внутренние ссылки. Не редиректить всё на главную без смысла.

2. CDN или WAF начал блокировать роботов

В access log или логах CDN появляются 403/429 для Googlebot, ЯндексБота, Bingbot или других краулеров. Иногда это случается после включения антибота, country block, rate limit, challenge-страниц или aggressive security mode.

Что делать: проверить правила WAF, верифицировать поисковых роботов, не блокировать sitemap.xml, robots.txt, CSS, JS, изображения и важные URL. Не выдавать поисковикам CAPTCHA вместо страницы.

3. WordPress начал отдавать 500 после обновления

В access log растет число 500, а в error log есть PHP Fatal error. Часто виноват конфликт плагина, темы, PHP-версии, кэша или нехватка памяти.

Что делать: включить maintenance только на короткое время, найти конкретный fatal error, отключить проблемный плагин, проверить совместимость PHP, восстановить сайт из backup, затем тестировать обновления на staging.

4. Сайт стал быстрым для людей, но нестабильным для ботов

Пользователь видит сайт через кэш/CDN, а Googlebot периодически получает 503/504 от origin. Внешне сайт “работает”, но робот ловит ошибки при обходе.

Что делать: смотреть логи origin-сервера и CDN, проверять Crawl Stats, уменьшать тяжелые cron-задачи, оптимизировать базу, настраивать PHP-FPM, Redis/object cache, переносить сайт на VPS с запасом ресурсов.

5. Закончился диск

В error log появляется no space left on device, сайт начинает отдавать ошибки, база не пишет данные, кэш не создается, сессии ломаются, WordPress ведет себя непредсказуемо.

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

6. Robots.txt или sitemap.xml стали недоступны

В access log видно 404/403/500 по /robots.txt или /sitemap.xml. Это может замедлить обход и ухудшить индексацию, особенно после миграции или настройки WAF.

Что делать: проверить доступность robots.txt и sitemap.xml для обычного пользователя и поисковых роботов, убрать блокировки, обновить sitemap в Search Console/Яндекс Вебмастере.

7. Страницы начали отдавать слишком медленно

Если в логах есть request_time или upstream_response_time, можно увидеть медленные URL. Часто это фильтры каталога, поиск, WooCommerce checkout, LMS, личный кабинет, импорт, API или тяжелые страницы с запросами к базе.

Пример поиска медленных запросов, если время ответа записано последним полем:

awk '$NF > 3 {print $7, $9, $NF}' /var/log/nginx/access.log | sort -k3 -nr | head -n 50

Команду нужно адаптировать под ваш формат логов. Но сама логика важна: ищите не только ошибки, а медленные страницы. Долгий TTFB и таймауты могут снижать качество обхода и ухудшать пользовательский опыт.

Как отличить SEO-проблему от серверной

Серверная проблема обычно оставляет следы в логах:

рост 5xx;
рост 403/429 для роботов;
массовые 404 после миграции;
долгие ответы сервера;
таймауты PHP-FPM или базы;
ошибки диска, памяти, прав файлов;
падение количества обходов роботами;
недоступность sitemap/robots;
частые рестарты сервисов.

SEO-проблема без серверной причины часто выглядит иначе:

логи чистые, 5xx нет;
роботы получают 200;
sitemap и robots доступны;
сервер отвечает быстро;
но падают позиции по конкретным запросам;
страницы индексируются, но хуже ранжируются;
конкуренты усилили контент;
изменился интент выдачи;
появились AI-ответы, агрегаторы, карты, видео или маркетплейсы;
сайт потерял ссылки или релевантность.

Если логи не показывают технических ошибок, не надо насильно искать проблему в сервере. Но если логи показывают 5xx, блокировки ботов, медленные URL или массовые 404, начинать нужно с инфраструктуры.

Как анализировать падение трафика после переезда на VPS

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

Проверьте:

все ли старые URL отдают 200 или корректный 301;
нет ли 404 по страницам, которые раньше приносили трафик;
не изменился ли canonical;
не появился ли noindex в шаблоне;
не закрыт ли сайт в robots.txt;
правильно ли работает https;
нет ли цепочек редиректов;
не отдается ли staging-версия;
не блокирует ли firewall поисковых роботов;
не отдает ли сервер разные версии для www/non-www или http/https;
не потерялись ли изображения, CSS, JS;
не сломались ли sitemap и внутренние ссылки.

Если после переноса появились 502/504, значит серверная конфигурация не выдерживает сайт или настроена неправильно. Для WordPress часто нужно настраивать PHP-FPM, OPcache, Redis/object cache, лимиты памяти, Nginx rules, кэш и cron. Просто “перенести файлы на VPS” недостаточно.

Какие логи нужны для WordPress

Для WordPress одного Nginx/Apache access log мало. Нужно смотреть несколько уровней:

access log веб-сервера;
error log веб-сервера;
PHP-FPM log;
WordPress debug log, если он включен временно для диагностики;
MySQL/MariaDB error log;
slow query log базы данных, если проблема в медленных запросах;
логи кэш-плагина или object cache;
логи CDN/WAF, если сайт за прокси;
логи почты, если проблема связана с формами, заказами или регистрацией.

Включать debug log на production нужно осторожно. Нельзя показывать ошибки посетителям. Логи могут содержать пути, email, токены, параметры запросов и другую чувствительную информацию. После диагностики debug лучше отключить или ограничить доступ к логам.

Что часто советуют опытные администраторы и вебмастера

По опыту реальных разборов на форумах и в сообществах, самые полезные выводы простые:

не верьте только dashboard-панели, смотрите сырые логи;
не анализируйте только главную страницу, смотрите URL, которые потеряли трафик;
не включайте WAF/CDN/rate limit без проверки поисковых роботов;
не удаляйте старые URL без карты редиректов;
не храните backup только на том же сервере;
не держите логи всего один день, при SEO-проблемах нужен исторический период;
не делайте пять изменений одновременно;
не игнорируйте 429 и 503, даже если сайт “открывается у меня”;
не путайте падение обхода с падением позиций;
не используйте минимальный VPS для тяжелого WordPress, WooCommerce, LMS или каталога без запаса.

Самый частый неприятный вывод: проблема была не в “алгоритме Google”, а в простом техническом сбое — сервер отдавал ошибки роботам, WAF блокировал краулер, sitemap был закрыт, после миграции пропали редиректы или PHP-FPM падал под нагрузкой.

Что проверить перед обращением в поддержку

Чтобы поддержка быстрее помогла, не пишите просто “упал трафик”. Подготовьте конкретику.

домен;
дата и время начала просадки;
какой трафик упал: Google, Яндекс, весь, мобильный, отдельные страницы;
что менялось перед падением: перенос, DNS, CDN, кэш, тема, плагины, firewall;
примеры URL, которые потеряли трафик;
скриншоты из Search Console / Яндекс Вебмастера;
ошибки из access log и error log;
есть ли 403/429/5xx для поисковых роботов;
есть ли проблемы с sitemap.xml и robots.txt;
какой стек используется: WordPress, WooCommerce, Laravel, Bitrix, OpenCart, custom;
используется ли CDN/WAF;
где находится backup.

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

Когда пора переходить с shared-хостинга на VPS

Если сайт теряет трафик из-за технических ограничений shared-хостинга, постоянных 5xx, медленного TTFB, перегруза базы, нехватки CPU/RAM, невозможности настроить Redis, PHP-FPM, firewall и нормальный кэш, VPS становится не роскошью, а базовой инфраструктурой.

VPS особенно нужен, если:

сайт приносит заявки или продажи;
есть WooCommerce, LMS, каталог, личный кабинет или активная CMS;
нужно хранить логи и анализировать поведение роботов;
нужен контроль Nginx/Apache, PHP, MySQL/MariaDB;
нужен Redis/object cache;
нужна изоляция от соседей;
нужен внешний backup и мониторинг;
shared-хостинг ограничивает процессы или блокирует сайт при пиках.

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

Когда VPS не решит падение трафика

VPS не вернет позиции, если причина в слабом контенте, изменении интента, санкциях, плохих ссылках, потере внешних ссылок, некорректной SEO-структуре, дублях, неправильных canonical, noindex или падении спроса. Серверные логи помогают исключить техническую причину, но они не заменяют SEO-аудит.

Правильная логика такая: сначала проверить, не мешает ли сервер поисковикам и пользователям. Если access/error logs чистые, сайт стабилен, роботы получают 200, sitemap доступен, 5xx нет, скорость нормальная — дальше нужно смотреть контент, выдачу, конкурентов, ссылки и спрос.

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

Xhost24 может помочь, если падение трафика связано с инфраструктурой: перегруженный shared-хостинг, ошибки 5xx, медленный TTFB, блокировки роботов, неправильная настройка VPS, проблемы с кэшем, PHP-FPM, базой, диском, backup или мониторингом. На VPS можно хранить и анализировать access/error logs, настраивать расширенный формат логов, контролировать ресурсы и быстрее находить технические причины просадки.

Если нужен не просто сервер, а перенос, настройка, hardening, firewall, PHP-FPM, Redis, Nginx/Apache, backup и мониторинг, стоит заранее обсудить услуги администрирования. Это особенно важно для WordPress, WooCommerce, LMS, каталогов и сайтов, где падение трафика сразу влияет на продажи.

Правильный запрос в поддержку: “У сайта упал трафик. Нужно проверить access/error logs, статусы для Googlebot/ЯндексБота, 5xx, 403/429, sitemap, robots.txt, TTFB, PHP-FPM, базу, кэш и понять, есть ли серверная причина. При необходимости нужен перенос на VPS и настройка мониторинга”. Такой запрос быстрее приводит к рабочей диагностике, чем общая фраза “SEO просело”.

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

FAQ: access log, error log и падение трафика

Могут ли серверные логи показать причину падения трафика?

Да, если причина техническая: 5xx, блокировки роботов, массовые 404, неправильные редиректы, таймауты, медленные ответы, недоступный sitemap, ошибки PHP, проблемы базы или WAF/CDN. Если логи чистые, причину нужно искать в SEO, контенте, ссылках, выдаче или спросе.

Что важнее смотреть: access log или error log?

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

Какие статусы самые опасные для SEO?

Наиболее опасны частые 500, 502, 503, 504, 403 и 429 на важных страницах или для поисковых роботов. Массовые 404 по старым трафиковым URL тоже могут привести к потере видимости после миграции или изменения структуры сайта.

Почему Googlebot получает 403, если сайт открывается у меня?

Причина может быть в WAF, CDN, firewall, rate limit, country block, антибот-защите, правилах .htaccess/Nginx или неправильной идентификации робота. Нужно смотреть логи и проверять, какие статусы получает именно поисковый бот.

Что значит 429 для поискового робота?

429 означает Too Many Requests. Если его получает Googlebot или ЯндексБот, сервер или защита ограничивает частоту обхода. Это может снизить активность краулинга и замедлить обновление индекса.

Почему после переноса сайта выросли 404?

Обычно это происходит из-за изменения структуры URL, отсутствия 301-редиректов, неправильного импорта CMS, удаления категорий или ошибок в rewrite rules. Нужно собрать список старых URL и настроить релевантные редиректы.

Нужно ли хранить логи долго?

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

Можно ли читать логи на shared-хостинге?

Иногда да, если хостинг дает доступ к access/error logs. Но на shared-хостинге часто меньше контроля: нельзя настроить расширенный формат логов, глубоко анализировать PHP-FPM, базу, firewall и ресурсы. На VPS возможностей диагностики больше.

Поможет ли VPS, если трафик упал?

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

Что отправить в поддержку для диагностики?

Укажите домен, дату просадки, примеры URL, источник трафика, что менялось перед падением, ошибки из Search Console/Яндекс Вебмастера, наличие CDN/WAF, примеры строк access/error log и информацию о CMS. Это сильно ускоряет диагностику.

Base de connaissances

Catégories

Catégories