Как создать сайт, который понимают AI‑краулеры и LLM

AI‑краулеры и LLM‑индексирование: что это и зачем готовиться

Кто такие AI‑краулеры и чем они отличаются от поисковых ботов

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

Отсюда — другие приоритеты: понятная структура страницы, явные источники фактов, наличие лицензии/условий использования, а также отсутствие препятствий для чтения (сложный JS, скрытый текст, агрессивные антибот‑проверки).

Что подразумевают под «LLM‑индексированием»

LLM‑индексирование — это не «страница в индексе», а процесс извлечения фактов, сущностей (персоны, продукты, места, цены, даты) и связей между ними. Модель лучше «понимает» материал, когда:

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

Какие страницы чаще попадают в датасеты и ответы

Чаще всего это справочные статьи, документация, гайды, FAQ, страницы компании «О нас/Контакты», карточки товаров и услуг, прайс‑страницы, политики (доставка, возврат), а также пресс‑релизы и исследования — всё, где есть проверяемые и цитируемые факты.

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

Если контент закрыт paywall’ом, требует авторизации или запрещён лицензией, его могут не использовать. Важны и юридические ограничения: персональные данные, условия перепечатки, robots‑политики и технические блокировки.

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

Планирование: цели, сущности и карта контента

Прежде чем править robots.txt или добавлять Schema.org, стоит зафиксировать базовую «модель мира» вашего сайта. Для AI‑краулеров и LLM это особенно важно: они пытаются понять, о чём сайт, какие объекты в нём главные и где лежит подтверждающая информация.

1) Сформулируйте цель сайта в 1–2 предложениях

Запишите формулировку так, чтобы её одинаково легко понял человек и «машина». Пример:

«Мы продаём X для Y в Z, публикуем инструкции по выбору и поддержку клиентов».

Эта мини‑формула станет опорой для навигации, названий разделов, мета‑описаний и будущих страниц справки.

2) Соберите список ключевых сущностей

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

Проверьте, что для каждой сущности есть «домашняя» страница (или она будет создана) — иначе LLM увидит упоминания, но не найдёт источник.

3) Выберите опорные страницы и «скелет» карты контента

Достаточно начать с минимального набора:

• Главная (общее описание и ссылки на ключевые разделы)
• Категории/направления (где живут сущности верхнего уровня)
• Справка/FAQ (короткие ответы, которые удобно цитировать)
• Блог/статьи (глубина и доказательная база)
• Контакты и юридические страницы

Важно: каждая опорная страница должна быть достижима за 2–3 клика и иметь понятные связи «родитель → дочерняя».

4) Задайте измеримые критерии качества

На старте определите, чем будете мерить успех:

• доступность обхода (нет блокировок важных разделов)
• полнота индекса (сколько ключевых страниц обнаруживается)
• число технических ошибок (4xx/5xx, неверные редиректы)
• скорость (Core Web Vitals или хотя бы LCP/INP)

Эти критерии помогают не спорить «на ощущениях» и быстро проверять прогресс после каждого релиза.

Информационная архитектура и понятные URL

Информационная архитектура — это «каркас» сайта: как разделы связаны между собой и насколько предсказуемо пользователь (и AI‑краулер) может дойти до нужной страницы. Практичное правило — двигаться от общего к частному и не уходить глубже 2–3 уровней вложенности, чтобы страницы не терялись в навигации.

Иерархия без перегруза

Соберите разделы вокруг понятных сущностей: «Продукт → Возможности → Кейсы», «База знаний → Темы → Статьи», «Услуги → Направления → Детали». Если категория получается слишком широкой, делите её на подкатегории, но не создавайте «лестницы» из 5–6 уровней.

Читаемые и стабильные URL

URL должны быть постоянными, короткими и единообразными:

• один формат слэшей (например, всегда со слэшем на конце: /blog/ai-crawlers/)
• без лишних параметров вроде ?utm= в канонических адресах
• без дат, если они не несут смысла (лучше обновлять статью, не меняя URL)

Пример: вместо /article?id=123&ref=promo используйте /blog/llm-indeksirovanie/.

Хлебные крошки и сквозная навигация

Добавьте «хлебные крошки» (например: Главная → База знаний → AI‑краулеры). Они помогают понять контекст страницы и распределяют внутренний «вес» между разделами.

В шапке и футере держите сквозные ссылки на ключевые узлы: /blog/, /pricing, /docs/.

Внутренняя перелинковка как подсказки

Внутри материалов делайте ссылки не «для SEO», а как маршруты:

• «Похожие материалы» (по теме)
• «Следующий шаг» (после чтения)
• ссылки на определения терминов (глоссарий или якорь на странице)

Так AI‑краулеру проще собрать цельную картину сайта, а пользователю — не теряться после первого прочтения.

Контент, который легко извлекается и цитируется

AI‑краулеры и LLM чаще всего «видят» страницу как набор блоков текста. Чем яснее границы смысловых фрагментов и чем точнее формулировки, тем выше шанс, что модель корректно извлечёт факт и сослётся на вас.

Пишите как для справочника, а не как для рекламы

Делайте короткие абзацы (1–3 предложения) и начинайте с определения: что это, для кого, когда применять.

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

Хороший приём — «TL;DR» в 2–3 строках сразу после заголовка раздела: он часто попадает в ответы моделей как готовая выдержка.

Давайте факты в извлекаемых формах

LLM удобнее брать данные из структур:

• шаги (нумерованный список), если это инструкция;
• таблица, если нужно сравнение;
• мини‑FAQ, если есть повторяющиеся вопросы.

Пример таблицы (её легко «скопировать» в ответ):

Контекст и ограничения — рядом с утверждением

Если вы пишете «работает за 5 минут», уточните условия: «при стабильном интернете, для файла до 20 МБ». Если указываете цену, добавляйте «актуально на 2025‑12‑26» или ссылку на /pricing.

Мини‑шаблон абзаца, который легко цитируется

Определение: …

Когда использовать: …

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

Источник/дата: …

Такой формат снижает вероятность неправильной интерпретации и повышает качество цитирования.

Семантический HTML и доступность как основа понимания

LLM‑краулеры и обычные поисковые боты «читают» страницу не глазами, а по структуре DOM. Чем яснее смысл разметки, тем проще извлечь факты, заголовки, определения и связи — а значит, выше шанс, что контент будет корректно процитирован.

Заголовки: один H1 и понятная иерархия

На странице держите ровно один H1 — это главный ответ «о чём страница». Дальше стройте смысловую лестницу: H2 для крупных блоков, H3 для подпунктов.

Заголовки должны быть описательными, а не декоративными («Подробнее», «Информация»), чтобы бот понимал, что именно раскрывается.

Семантические теги вместо «дивов ради дивов»

Используйте теги по назначению: header, nav, main, article, section, footer. Это помогает отделить навигацию от основного текста и корректно интерпретировать фрагменты.

Например, основной материал — внутри main, самостоятельная публикация — article, а тематические части — section с заголовком.

Изображения: alt и подписи по смыслу

alt должен описывать суть изображения (что на нём и зачем оно в тексте), без переспама ключевыми словами. Если картинка несёт информацию (график, схема) — добавьте подпись (figcaption) или краткое пояснение рядом.

Доступность = меньше двусмысленностей

Доступная разметка улучшает извлечение контента: корректные label у полей формы, логичный порядок фокуса, заметные состояния :focus, достаточный контраст. Это делает интерфейс понятнее людям — и уменьшает «шум» для ботов, которые анализируют структуру и назначение элементов.

Структурированные данные (Schema.org) без ошибок

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

Когда применять Schema.org

Используйте разметку там, где у страницы есть чёткая сущность:

• Article/BlogPosting — статьи, новости, гайды.
• Product — товары и тарифы.
• Organization/LocalBusiness — о компании, контакты.
• FAQPage — разделы «Вопрос–ответ» (только если вопросы и ответы реально видимы на странице).
• BreadcrumbList — хлебные крошки для структуры и навигации.

Важно: не размечайте «для красоты» всё подряд. Если сущность спорная — лучше не добавлять тип, чем добавить неправильный.

JSON-LD: куда вставлять и как валидировать

Предпочтительный формат — JSON-LD. Его удобно поддерживать, и он меньше конфликтует с версткой.

• Вставляйте блок <script type="application/ld+json">…</script> в <head> или в конце <body>.
• Разметка должна соответствовать текущей странице, а не «общей информации о сайте».
• Валидируйте через Schema Markup Validator и тест расширенных результатов (если актуально для вашего типа).

Критичные поля и типичные ошибки

Минимальный набор полей, которые стоит заполнять аккуратно: name, description, url, datePublished/dateModified, author, sameAs.

• sameAs добавляйте только на реальные, официальные страницы бренда/организации.
• Следите, чтобы url совпадал с каноническим адресом страницы.
• Не создавайте конфликтов: один основной тип на страницу (например, Article), а дополнительные — только по смыслу (например, BreadcrumbList). Избегайте дубликатов одинакового типа, описывающих одно и то же.

Управление обходом: robots.txt, meta robots и заголовки

Правильное управление обходом помогает AI‑краулерам и классическим ботам не тратить бюджет сканирования на «мусор», быстрее находить важное и не индексировать то, что не должно появляться в поиске.

robots.txt: базовые правила и sitemap

robots.txt — это подсказка, какие разделы сканировать не стоит. Обычно закрывают служебные области: админку, внутренний поиск, корзину/личный кабинет, параметры фильтров, временные каталоги.

User-agent: *
Disallow: /admin/
Disallow: /search/
Disallow: /cart/
Disallow: /account/

Sitemap: /sitemap.xml

Важно: не «перекрывайте кислород» контенту, который хотите видеть в выдаче. Если вы запретите обход ключевых страниц, бот может так и не увидеть их содержание.

Meta robots и X‑Robots‑Tag: точечный контроль

Для отдельных страниц используйте meta robots:

<meta name="robots" content="noindex,follow">

Для файлов (PDF, изображения) и ответов сервера удобнее заголовок X‑Robots‑Tag:

X-Robots-Tag: noindex

Так вы управляете индексированием независимо от HTML и можете закрывать, например, прайс‑листы «для скачивания», оставляя доступной саму страницу.

Раздельные окружения: staging/dev не должны утекать

Тестовые окружения лучше закрывать не только robots.txt, а авторизацией или IP‑ограничением. Иначе возможны утечки дублей в индекс. На проде при этом не используйте глобальный noindex и не копируйте защитные правила «как есть».

Осторожно с блокировками: запрет обхода ≠ запрет использования

robots.txt и директивы индексирования управляют тем, что бот может получить и сохранить в индексе. Они не являются универсальным юридическим запретом на использование данных в обучении или ответах моделей — это разные уровни контроля.

Поэтому для чувствительного контента полагайтесь на реальные ограничения доступа (логин, paywall, токены, запрет публичной раздачи), а не только на директивы для ботов.

Sitemap, RSS и llms.txt: ускоряем обнаружение контента

Поисковые боты и AI‑краулеры находят страницы по ссылкам, но «пакетные» подсказки сильно ускоряют обнаружение нового и обновлённого контента. Начните с базового набора: sitemap.xml для всех важных URL и RSS/Atom для ленты публикаций. llms.txt можно добавить как экспериментальный ориентир, но без завышенных ожиданий.

sitemap.xml: что включать и как обновлять

В sitemap.xml добавляйте только канонические, индексируемые URL (те, что вы готовы показывать в выдаче и в цитатах). Не включайте страницы с noindex, результаты поиска по сайту, служебные параметры, дубликаты и черновики.

Поле lastmod обновляйте только при реальном изменении содержания — это помогает краулерам приоритизировать обход. Частоту пересборки карты обычно привязывают к публикации/обновлению контента (например, по событию деплоя или по расписанию раз в сутки для новостных проектов).

Технические лимиты: до 50 000 URL в одном файле sitemap и до ~50 MB (в несжатом виде). Если страниц больше — разбивайте на несколько файлов и используйте sitemap‑index.

Отдельные карты: изображения, видео, новости

Если у вас медиа‑контент, отдельные sitemaps для изображений/видео могут улучшить обнаружение вложенных ресурсов. Для новостных проектов пригодна news‑sitemap, где особенно важны свежесть и корректные даты.

RSS/Atom для публикаций

RSS/Atom — простой канал «что нового». Он особенно полезен для блога, базы знаний и релиз‑нотов: краулер получает список последних материалов без глубокого обхода.

llms.txt: подсказка, а не гарантия

llms.txt — экспериментальная практика. В него кладут краткое описание сайта и ссылки на ключевые разделы: /docs, /blog, /pricing, страницу «О проекте», политику использования контента.

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

Рендеринг и JavaScript: чтобы контент был виден без ожиданий

AI‑краулеры и многие системы извлечения фактов любят «простой» веб: когда ключевой текст, заголовки и ссылки уже присутствуют в исходном HTML. Если сайт отдаёт пустую оболочку и наполняется только после выполнения JavaScript, вы рискуете тем, что страница будет проиндексирована частично или с задержкой.

Почему SPA часто проигрывают

У типичного SPA (client-side rendering) есть четыре частые проблемы:

• Пустой HTML на старте: в ответе сервера почти нет контента, только <div id="app">.
• Задержки JS: краулер может не дождаться загрузки и выполнения скриптов.
• Скрытый контент: важные блоки появляются только после клика, скролла или выполнения сложной логики.
• Хрупкость: любая ошибка в JS превращает страницу в «белый экран».

SSR, SSG и пререндер: что выбрать

• SSR (Server-Side Rendering) — когда контент зависит от пользователя, часто обновляется или важна быстрая первая отрисовка. Сервер отдаёт готовый HTML на каждый запрос.
• SSG (Static Site Generation) — когда контент в основном статичный (статьи, справка). Генерация HTML происходит на этапе сборки.
• Пререндер — компромисс для SPA: для важных маршрутов заранее генерируется HTML‑снимок.

Главное правило: то, что вы хотите, чтобы цитировали и находили, должно быть доступно без выполнения JS.

Если вы собираете продукт или контент‑раздел «с нуля», полезно сразу выбирать стек и процесс, где SSR/SSG и технические файлы (sitemap, robots, каноникалы) ставятся «по умолчанию». Например, на TakProsto.AI можно в формате чата спроектировать структуру сайта, быстро собрать веб‑часть на React и бэкенд на Go с PostgreSQL, а затем выгрузить исходники, настроить деплой и домен — так проще избежать типичных SPA‑ловушек ещё до первого релиза.

Как быстро проверить результат

1. Откройте страницу и сравните «Просмотр исходного кода» (view-source) с тем, что видите в браузере. Если в исходнике нет текста — это сигнал.
2. Проверьте ответ сервера через curl и убедитесь, что внутри есть заголовок, основной абзац и ссылки:

curl -s https://example.com/page | sed -n '1,120p'

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

Уберите «ловушки» для обхода

Бесконечная прокрутка, фильтры и бесконечные параметры URL легко создают миллионы «вариантов» страниц.

Сделайте так, чтобы:

• у ленты были пагинация и отдельные URL для страниц;
• фильтры имели ограниченный набор индексируемых комбинаций;
• параметры не порождали бесконечные циклы (например, сортировки и трекинг‑метки не должны создавать новые «уникальные» страницы).

Производительность и техническая надёжность для индексации

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

Скорость загрузки и стабильность

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

• Оптимизируйте изображения (правильные размеры, WebP/AVIF, lazy‑load там, где уместно).
• Не «раздувайте» шрифты: ограничьте начертания, используйте font-display: swap.
• Включите кеширование на уровне CDN и сервера (ETag/Last-Modified, Cache-Control для статических ресурсов).

Чем меньше «лишней работы» у браузера и сервера, тем стабильнее краулер получает страницу без повторных попыток.

Чистая стратегия 4xx/5xx

Ошибки неизбежны, но они должны быть управляемыми:

• Возвращайте корректные коды: 404 для удалённого, 410 для окончательно исчезнувшего, 503 для временных проблем.
• Делайте страницы ошибок полезными: краткое объяснение, поиск, ссылки на ключевые разделы.
• Не отдавайте 200 с текстом «страница не найдена» — это засоряет индекс и ломает цитирование.

Безопасность и доверие

HTTPS — базовый минимум. Если используете HSTS, настраивайте аккуратно (с учётом поддоменов). Добавьте защиту от внедрений: CSP, безопасные заголовки, актуальные зависимости.

Устойчивость к пикам

AI‑краулеры могут приходить «волнами». Помогают CDN, серверный кеш и ограничения на тяжёлые запросы (rate limit, защита от дорогостоящих фильтров/поиска).

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

Дубликаты, каноникал и мультиязычность

Поисковые и AI‑краулеры хуже «понимают» сайт, когда один и тот же контент доступен по множеству адресов. Для LLM‑индексирования это особенно болезненно: модель может вытянуть не ту версию, смешать языки или процитировать страницу с параметрами.

Canonical: когда нужен и как не сломать индексацию

rel="canonical" ставят, когда есть несколько URL с одинаковым (или почти одинаковым) содержимым, но вы хотите, чтобы индексировалась одна «главная» версия.

Главные правила:

• Каноникал должен указывать на 200 OK страницу, не на редирект и не на 404.
• Каноникал должен быть самореференсным на основной версии (страница канонизирует сама себя).
• Не канонизируйте разные по смыслу страницы друг на друга — это ломает аналитику и снижает шанс, что нужная версия попадёт в индекс.

Параметры URL: UTM, сортировки, фильтры

Параметры часто создают дубликаты: ?utm_source=…, ?sort=price, фильтры каталога.

Практика:

• Маркетинговые UTM обычно не должны создавать отдельные индексируемые URL: используйте каноникал на «чистый» адрес.
• Для фильтров решите заранее: если фильтр создаёт ценную посадочную — делайте её отдельной страницей; если нет — закрывайте от индексации и/или канонизируйте.
• Нормализуйте URL (единый порядок параметров, без пустых значений), чтобы не плодить адреса.

Пагинация и категории: связность без «тонких» страниц

Для категорий важно, чтобы страницы пагинации были связаны ссылками «назад/вперёд», а не генерировались только скриптами.

У «тонких» страниц (минимум товаров/текста) лучше снижать шанс индексирования: объединяйте, улучшайте контент или аккуратно канонизируйте на первую страницу категории — но только если страницы действительно почти одинаковые.

Мультиязычность: hreflang и единая структура

Если есть переводы, используйте hreflang между версиями и держите понятную симметричную структуру URL (например, /ru/... и /en/...). Переключатель языка должен вести на соответствующую страницу, а не на главную.

Это помогает краулерам и LLM не смешивать языки при извлечении и цитировании.

Логи, мониторинг и диагностика AI‑краулеров

Если вы хотите, чтобы AI‑краулеры и LLM‑индексирование работали предсказуемо, логов и базового мониторинга достаточно, чтобы быстро понять: «бот не видит контент» или «сайт сам себе мешает».

Логи сервера: что смотреть в первую очередь

Начните с access‑логов (и, если есть, CDN/WAF‑логов). Полезная минимальная выборка:

• частота обхода: запросы к ключевым разделам, всплески и «провалы»;
• коды ответов: доля 200/304 против 404/410/429/5xx;
• проблемные URL: цепочки редиректов, бесконечные параметры, «тонкие» страницы;
• время ответа: p95/p99 для HTML (не только для API).

Практика: заведите отдельный отчёт по URL, которые должны индексироваться (страницы продуктов, статьи), и по «техническим» (поиск, фильтры, пагинация) — так вы быстрее увидите, куда уходит crawl budget.

Идентификация ботов: аккуратно с блокировками

User‑Agent — полезный индикатор, но его легко подменить. Если вы сверяете IP/ASN, делайте это точечно и не стройте жёсткие блоки «по странам/провайдерам»: вы рискуете отрезать легитимных краулеров, превью‑ботов и сервисы проверки.

Лучше стратегия: rate limit на аномальные пики + разрешение доступа к важному контенту без JS‑зависимостей.

Мониторинг изменений: что должно тревожить

Отслеживайте тренды после релизов:

• рост 404/410 (особенно на внутренние ссылки);
• увеличение 5xx и 429 (краулеры начнут реже заходить);
• просадка скорости генерации HTML;
• ошибки разметки Schema.org и падение доли валидных страниц.

Мини‑тест‑набор перед релизом

Перед выкладкой прогоняйте короткий чек:

• доступны ли /sitemap.xml и при необходимости RSS;
• корректны ли правила в /robots.txt и meta robots;
• нет ли цепочек 3xx на канонических URL;
• валидируется ли структурированная разметка.

Это дешевле, чем потом «лечить» потерю обнаружения контента и цитируемости.

Чек‑лист запуска и шаблон страницы для LLM‑дружелюбного сайта

Пошаговый чек‑лист перед релизом

1. Структура и навигация: одна тема — одна страница; хлебные крошки; понятные категории; внутренние ссылки на ключевые материалы (например, /blog/llm-indexing, /pricing).

2. Контент: в начале — краткое резюме (3–6 предложений); дальше — разделы с подзаголовками; определения терминов; таблицы/списки там, где они реально упрощают чтение.

3. Разметка и метаданные: один h1 на страницу; логичная иерархия h2/h3; title и meta description уникальны; Open Graph/Twitter Cards при необходимости.

4. Файлы обнаружения: актуальные /sitemap.xml, /robots.txt, RSS/Atom (если есть публикации) и /llms.txt с ссылками на лучшие страницы и правилами использования.

5. Рендеринг: основной текст и заголовки доступны без ожидания JS (SSR/SSG или корректный prerender); важные ссылки видимы в HTML.

6. Процесс: зафиксированы критерии качества и мини‑тест‑набор перед релизом; есть план отката. (Кстати, похожий подход удобно поддерживать и на платформах с «снапшотами» и rollback — это снижает риск «сломать индексацию» одним деплоем.)

Шаблон «идеальной» страницы (минимум)

<!doctype html>
<html lang="ru">
<head>
  <meta charset="utf-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1" />
  <title>Точная тема страницы — бренд</title>
  <meta name="description" content="1–2 предложения: что даёт страница и кому." />
  <link rel="canonical" href="https://example.com/guides/page" />
  <script type="application/ld+json">{}</script>
</head>
<body>
  <header>…</header>
  <main>
    <article>
      <h1>Ясный заголовок</h1>
      <p><strong>Краткое резюме:</strong> …</p>
      <h2>Ключевой раздел</h2>
      <p>…</p>
    </article>
  </main>
  <footer>…</footer>
</body>
</html>

Типичные ошибки, которые ломают извлечение

Часто «случайно» закрывают CSS/JS в robots.txt и тем самым ломают рендеринг; прячут основной текст за скриптами/табы без серверного HTML; ставят неверный canonical (на главную, на другой язык, на страницу с параметрами).

Как уложить статью примерно в 3000 слов без повтора

Держите один главный вопрос на материал и делите объём на блоки: 200–300 слов ввод/резюме, 6–8 разделов по 300–400 слов, 200–300 слов вывод + чек‑лист.

В каждом разделе: тезис → пример → короткий вывод. Если мысль не даёт нового решения читателю — выносите в примечание или удаляйте.