Топ-5 методов SEO-аудита: сканер, логи и проверка вручную

Сайт теряет органический трафик, а отчёт подрядчика снова состоит из сотен «ошибок» без объяснения, что исправлять первым? Для полноценного технического SEO-аудита нужны пять методов: сканирование сайта, анализ серверных логов, проверка индексации, ручная диагностика страниц и оценка скорости. Каждый отвечает на свой вопрос: какие URL существуют, куда приходит поисковый робот, что попадает в поиск, какой контент доступен и насколько удобно загружается страница.

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

О цифрах в статье: нормативные значения приведены по документации Google Search Central, web.dev и стандарту HTTP. Примеры расчётов специально обозначены как учебные: это не статистика клиентов, не результаты исследования и не обещание роста.

1. Сканирование сайта SEO-краулером — поиск технических ошибок и связей между URL

SEO-краулер обходит страницы по ссылкам и собирает техническую карту сайта. Это основной инструмент для поиска битых ссылок, цепочек перенаправлений, дублей метаданных, проблем с canonical и внутренней перелинковкой.

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

Инструменты технического SEO-аудита этого класса полезны при запуске сайта, миграции, изменении каталога и регулярной проверке крупных проектов. Для небольшого сайта услуг обычно достаточно полного обхода. Для магазина с фильтрами сначала нужно ограничить пространство URL, иначе сканер уйдёт в бесконечные комбинации параметров.

Что проверять в первую очередь:

• HTTP-статусы: успешные ответы, перенаправления, ошибки клиента и сервера.
• Внутренние ссылки: какие страницы получают ссылки, а какие доступны только через Sitemap или прямой адрес.
• Canonical: куда указывает предпочитаемый URL и доступен ли он.
• Управление индексацией: robots.txt, meta robots, X-Robots-Tag.
• Метаданные: отсутствующие и повторяющиеся title, description, заголовки H1.
• Глубину переходов: насколько далеко коммерческие страницы находятся от основных разделов.
• Содержимое HTML: присутствует ли основной текст без выполнения JavaScript.

По стандарту RFC 9110, опубликованному в 2022 году, код 200 означает успешное выполнение запроса, 404 — отсутствие найденного представления ресурса, а 503 — временную неспособность сервера обработать запрос. Однако для SEO одного статуса недостаточно: страница может возвращать 200 и при этом содержать сообщение «товар не найден». Это уже кандидат на проверку как soft 404.

Как измерить масштаб ошибок, а не просто их количество?

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

Формула:

Доля URL с ошибкой = количество проблемных URL / количество проверенных URL × 100%.

Учебный пример: сканер проверил 2 000 внутренних URL, из которых 80 вернули 404. Доля составляет 4%. Но этот показатель ещё не определяет приоритет: если все 80 адресов ведут из основного меню, задача срочная; если это старые страницы без внутренних ссылок, порядок работ будет другим.

Для цепочек перенаправлений удобно считать отдельный показатель:

Доля внутренних ссылок через редирект = ссылки на перенаправляемые URL / все проверенные внутренние ссылки × 100%.

Здесь единица измерения — ссылка, а не уникальная страница. Один устаревший URL может стоять в общем меню и создавать проблему на всём сайте.

Плюсы:

• Массовая проверка по единым правилам.
• Возможность повторить обход после исправлений.
• Поиск системных ошибок в шаблонах, а не только отдельных страниц.

Ограничения:

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

Практический вывод: сохраняйте настройки обхода вместе с отчётом. Сравнивать два сканирования с разными правилами обработки параметров, поддоменов и JavaScript некорректно.

2. Анализ серверных логов — проверка реального поведения поисковых роботов

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

В журнале доступа обычно есть время запроса, адрес ресурса, HTTP-статус, IP-адрес, User-Agent и объём ответа. Время обработки запроса тоже может присутствовать, но зависит от формата логирования.

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

Важная деталь: User-Agent сам по себе не подтверждает принадлежность запроса поисковой системе. По документации Google Search Central, роботов можно проверять через опубликованные диапазоны IP либо через обратное и прямое DNS-разрешение. Без верификации статистика может включать обращения других программ с похожим именем.

Какие коэффициенты считать по логам сайта?

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

Доля ошибок сервера:

Запросы с ответами 5xx / все подтверждённые запросы робота × 100%.

Учебный пример: из 10 000 запросов подтверждённого робота 150 получили ответы 5xx. Доля — 1,5%. Это не «допустимая норма»: дальше нужно выяснить, были ли ошибки распределены равномерно или произошли в короткий период недоступности.

Доля обхода технических URL:

Запросы к выбранной группе технических URL / все запросы робота × 100%.

Если в учебной выборке из 10 000 запросов 3 000 пришлись на сортировки и параметры, получаем 30%. Но называть весь этот объём потерянным бюджетом обхода преждевременно: часть параметрических страниц может быть нужна поиску. Сначала классифицируйте адреса.

Коэффициент охвата целевых страниц:

Число уникальных целевых URL, посещённых роботом / общее число целевых URL.

Например, робот посетил 1 600 из 2 000 согласованных коммерческих страниц. Коэффициент — 0,8, или 80% за выбранный период. Это показатель обхода, не индексации: посещение страницы ещё не означает её включение в поиск.

За какой период собирать логи?

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

Для первой рабочей проверки можно взять 14–30 дней как стартовый диапазон, а затем расширить его, если важные страницы обходятся редко. Это рекомендация по организации анализа, а не норматив поисковой системы.

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

Плюсы:

• Видно реальное распределение запросов роботов.
• Можно находить обход устаревших URL и технических параметров.
• Доступна временная последовательность событий.

Ограничения:

• Логи не показывают решение поисковой системы об индексации.
• Часть запросов может обслуживаться CDN и не попадать в журнал сервера приложения.
• Ротация журналов способна удалить нужный период.
• IP-адреса и другие данные требуют аккуратной обработки и ограничения доступа.

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

3. Проверка индексации в панели вебмастера — сопоставление желаемого и фактического состояния

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

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

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

Сопоставляйте три набора:

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

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

Как посчитать покрытие индекса без ложной точности?

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

Формула:

Покрытие индекса = проиндексированные целевые URL / все целевые URL × 100%.

Учебный пример: из 500 целевых страниц подтверждено включение 420. Покрытие — 84%, разрыв — 80 страниц. Следующий шаг — распределить эти 80 адресов по причинам: запрет индексации, дубль, выбран другой canonical, ошибка ответа, отсутствие достаточного содержимого или другой статус.

Цифра 100% не является обязательной целью для всего сайта. Корзина, личный кабинет, внутренний поиск и многие служебные адреса обычно не должны участвовать в органическом поиске.

По документации Google Search Central, разрешение обхода и разрешение индексации — разные вещи. Блокировка в robots.txt не гарантирует исключение URL из поиска. Если робот не может открыть страницу, он не сможет прочитать размещённый на ней noindex.

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

Плюсы: доступ к статусам, которые невозможно надёжно восстановить по одному сканированию.

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

4. Ручная проверка HTML и JavaScript — диагностика того, что автоматизация пропускает

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

Для работы используют браузерные инструменты разработчика: просмотр исходного кода, DOM после выполнения JavaScript, вкладку Network и консоль ошибок.

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

Что проверить вручную на коммерческой странице?

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

• Исходный HTML и DOM: есть ли название товара, описание, цена и ссылки до и после выполнения JavaScript.
• Ссылки: ведут ли они на реальные URL через обычный элемент `a` с атрибутом `href`.
• Canonical и robots: не меняются ли они неожиданно после загрузки скриптов.
• Сетевые запросы: загружаются ли данные каталога, нет ли ошибок API.
• Мобильное отображение: доступен ли основной контент на узком экране.
• Структурированные данные: соответствуют ли они видимому содержимому страницы.
• Формы и кнопки: проходит ли реальный сценарий обращения.

Google Search Central рекомендует делать ссылки доступными для обхода через стандартную HTML-разметку. Кнопка с обработчиком JavaScript и без адреса — не равноценная замена обычной ссылке для обнаружения страниц.

Для большого сайта не нужно вручную открывать каждый URL. Начните с представителей шаблонов: категория, карточка, статья, фильтр, пагинация, страница услуги. Затем проверьте исключения, найденные краулером и панелью вебмастера.

Коэффициент согласованности ссылок можно использовать как внутреннюю диагностическую метрику:

Число значимых ссылок в исходном HTML / число значимых ссылок после рендеринга.

Если в учебном примере в исходном HTML есть 12 ссылок, а после рендеринга — 20, коэффициент равен 0,6. Это не официальный фактор ранжирования и не норматив. Показатель лишь помогает увидеть, насколько обнаружение ссылок зависит от JavaScript.

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

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

5. Проверка Core Web Vitals — оценка загрузки и отзывчивости страниц

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

По документации web.dev хорошие значения основных метрик:

• LCP — не более 2,5 секунды: время отображения крупнейшего значимого элемента в области просмотра.
• INP — не более 200 миллисекунд: показатель отзывчивости страницы при взаимодействиях.
• CLS — не более 0,1: показатель неожиданных сдвигов макета.

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

Это не означает рост трафика на 75% и не означает, что каждый посетитель увидит одинаковую скорость. Процентиль описывает распределение измерений, а не коммерческий эффект.

Чем полевые данные отличаются от лабораторного теста?

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

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

По документации Chrome UX Report, агрегированные данные обычно используют скользящее окно 28 дней. Поэтому после исправления показатель не обязан обновиться мгновенно: в окне ещё остаются измерения предыдущего периода.

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

Как сравнить результат до и после исправлений?

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

Формула относительного изменения:

Снижение времени = (значение до − значение после) / значение до × 100%.

Учебный пример: лабораторный LCP уменьшился с 4 до 3 секунд. Снижение — 25%. Но 3 секунды всё ещё выше границы хорошего LCP, а лабораторный результат не доказывает аналогичное улучшение у всех пользователей.

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

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

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

Сочетание методов для технического аудита сайта

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

Сравнение по задачам:

По каким признакам выбирать глубину аудита?

Глубину проверки определяют устройство сайта, доступные данные и риск для бизнеса. До начала работ согласуйте следующие условия.

• ✅ Целевые страницы. Выделите категории, услуги и карточки, которые должны привлекать спрос. Без этого проценты индексации будут малоинформативны.
• ✅ Техническая архитектура. Уточните роль JavaScript, наличие CDN, фильтров, поддоменов и нескольких версий сайта.
• ✅ Доступы и сохранность данных. Проверьте панель вебмастера, журнал запросов, аналитику и возможность выгрузки URL.
• ✅ Воспроизводимость. В отчёте должны быть период, настройки сканера, формула метрики и примеры адресов.
• ✅ Приоритет по ущербу. Недоступная посадочная и повторяющийся description — не задачи одной срочности.
• ✅ Приёмка исправлений. Каждая задача должна содержать ожидаемый результат и способ повторной проверки.
• ✅ Связь с обращениями. Если задача бизнеса — продажи, заранее проверьте, где фиксируются заявки и как определяется их источник.

Какой набор методов подходит вашему сценарию?

Начинайте с метода, который проверяет основную гипотезу, затем подтверждайте её независимыми данными. Это быстрее, чем запускать все инструменты без вопроса к ним.

• Сценарий: после миграции исчезли посадочные краулер и проверка индексации, затем логи для оценки обхода новых и старых URL.
• Сценарий: большой каталог с фильтрами анализ логов сайта и сканирование с контролем параметров; ручная проверка полезности выбранных фильтров.
• Сценарий: сайт построен на JavaScript сравнение исходного HTML и DOM, обход с рендерингом, индивидуальная проверка важных URL.
• Сценарий: страницы индексируются, но неудобны на мобильном Core Web Vitals и ручной пользовательский сценарий.
• Сценарий: небольшой сайт услуг без выраженного сбоя краулер, проверка индексации и ручная диагностика основных посадочных; логи — при подозрении на проблемы обхода.

Наш вывод: для планового аудита начните с краулера и проверки индексации. При большом количестве URL или непонятном поведении робота добавьте логи. Для JavaScript-сайта ручной рендеринг обязателен, а проблемы загрузки подтверждайте отдельными измерениями, не общей оценкой сканера.

Как превратить отчёт в план внедрения и расчёт окупаемости?

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

Порядок работ удобно строить по зависимостям:

• Сначала устранить недоступность, ошибочные запреты и массовые сбои ответов.
• Затем исправить обнаружение страниц, перенаправления и canonical.
• После этого проверить рендеринг, содержимое и производительность.
• В конце повторить измерения и сопоставить результаты с исходной базой.

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

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

Для расчёта окупаемости используйте финансовый результат, а не только трафик:

ROI = (дополнительная маржинальная прибыль − затраты на аудит и исправления) / затраты × 100%.

В затраты включают не только отчёт, но и разработку, управление задачами, тестирование. Дополнительную прибыль сравнивают с базовым периодом, учитывая сезонность, рекламу и изменения ассортимента. Без этого формула выглядит убедительно, но не доказывает вклад SEO.

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

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

Как связать технический аудит с видимостью в AI-поиске?

Технический аудит проверяет доступность и корректность сайта, а GEO-аудит — присутствие и описание бренда в ответах AI-поисковиков. Хорошее техническое состояние полезно, но не гарантирует упоминаний или цитирования.

Если вы готовите чеклист запуска GEO-кампании бренда, включите проверку доступности посадочных, однозначное описание компании, согласованность фактов и исходный замер видимости. Результаты SEO-краулера и логов используйте как техническую основу, а не как измерение доли голоса бренда.

Запросы «цена аудита видимости в AI-поисковиках», «цена тарифа SaaS GEO-платформы» и «цена услуги по оптимизации контента под LLM» относятся к разным предметам покупки. В первом случае сравнивают состав исследования, во втором — возможности регулярного мониторинга, в третьем — объём редакционной работы. Объединять их в одну «стоимость SEO-аудита» некорректно.

То же относится к разработке GEO-стратегии, подготовке контента для AI-поисковиков и мониторингу бренда в нескольких нейросетях: бюджет зависит от числа брендов, рынков, запросов и периодичности проверки. Конкретную стоимость имеет смысл обсуждать только вместе с составом работ.

Вопросы и ответы по теме

Для практического аудита полезнее уточнять не название инструмента, а какие данные он проверяет и чем подтверждается вывод.

Сканер нашёл сотни ошибок. Нужно исправлять все сразу?

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

Если робот посещает страницу, почему её нет в поиске?

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

Можно ли провести технический SEO-аудит без доступа к серверным логам?

Да, но выводы о реальном обходе будут ограничены. Краулер, панель вебмастера и ручная диагностика позволяют проверить значительную часть задач. Утверждать, как робот распределяет запросы между группами URL, без логов или сопоставимых данных нельзя.

Сколько займёт внедрение исправлений после аудита?

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

У нас хороший результат теста скорости. Можно больше ничего не проверять?

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

Как запросить кейс в нашей нише, чтобы он помог оценить подрядчика?

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

Как понять, что проблема в сайте, а не в обработке заявок?

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

Молвун — это SEO-агентство или SaaS-платформа?

Молвун — SaaS-платформа для мониторинга и аналитики видимости бренда в нейросетях. Это не агентство внедрения CRM и не замена всем инструментам технического SEO-аудита. Платформа помогает отслеживать упоминания, тональность и долю голоса бренда в AI-поиске.

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

Если техническую диагностику вы хотите дополнить оценкой присутствия бренда в AI-поиске, изучите [возможности платформы GEO-аналитики], разделы «Продукт», «Как работает», «Кейсы» и «Цены». Сначала определите базовый уровень видимости — затем планируйте изменения и оценивайте их результат.

Про данные. Диапазоны в тексте — ориентиры по открытым источникам и отзывам, а не прайс конкретной компании. Автор обзора — Молвун, платформа анализа видимости брендов в ИИ-ответах. Перед решением сверьте условия с поставщиком.