LidFly — сайты, магазины, лендинги и отчёты

ИИ создаёт лендинги, магазины и отчёты из блоков или публикует готовую статическую сборку. Активный сайт стоит от 490 ₽ за 30 дней: один блок включает 1000 контентных страниц и 3 ГБ файлов; в кабинете есть управление сайтами, страницами, файлами, заявками, доменом, Метрикой, доступами и магазином.

Как это работает

Сайт и поддомен создаются в личном кабинете LidFly. В кабинете владелец управляет сайтом, файлами, заявками, магазином, доменом, Метрикой и доступами. После этого встроенный чат или внешний ИИ-клиент через рекомендуемый /mcp/v3 либо legacy endpoint /mcp/lidfly видит ваши сайты и управляет страницами, блоками, ассетами, формами и магазином. Внешнему ИИ также доступны пять личных support-инструментов: read-only подготовка очищенного отчёта, чтение истории и изображений, приватная одноразовая загрузка и подтверждаемая отправка сообщения. Черновик всегда показывается пользователю; без явного текстового согласия сообщение не отправляется.

Возможности

Управление сайтами в кабинете

Раздел LidFly в личном кабинете — это не только создание поддомена. Для каждого сайта есть отдельная страница управления с вкладками Обзор, Шаблон, Страницы, Заявки, Файлы, Фавикон, Магазин, Домен и Настройки; у шаблона knowledge-base дополнительно появляется вкладка Знания.

• Создание сайта: на главной странице «Сайты» сначала выбирается стартовый шаблон из галереи с поиском, тегами, cover-картинками и live preview. После выбора открывается отдельная страница создания, где нужны только имя и поддомен *.lidfly.ru. Для knowledge-base сайт намеренно остаётся пустым: администратор открывает «Знания», выбирает точный уже связанный проект Пространства и один раз активирует auto-apply. Дальше содержательную работу выполняет внешний MCP-клиент со skill $lidfly-knowledge-maintainer, а не встроенный чат. Лендинг или магазин по-прежнему собираются через обычные инструменты LidFly. Базовый блок активного сайта стоит 490 ₽ за 30 дней и включает 1000 контентных страниц и 3 ГБ всех файлов; рекламный MCP-пакет для этого не нужен.
• Предупреждения об оплате: если общего баланса владельца не хватит на ближайшее списание, разделы «Сайты» и «Оплата» показывают дату, актуальную стоимость и недостающую сумму. Владелец получает сервисное письмо внутри семидневного окна, отдельное письмо в последние 24 часа и письмо после фактической остановки. После пополнения остановленный сайт нужно возобновить вручную. Приглашённые пользователи не видят баланс и финансовые предупреждения.
• Смена и развитие шаблона: владелец или администратор управляемого сайта открывает вкладку «Шаблон», видит текущий профиль, каталог и fullscreen preview, выбирает другой шаблон или сбрасывает его. Содержательные блоки и index.json не заменяются: LidFly пересобирает только совместимые managed HTML-страницы и generated-страницы. knowledge-base — развиваемый платформенный шаблон: совместимые сайты автоматически получают новые возможности оболочки и поиска, сохраняя типы, разделы, записи, устав, тему, chrome и CSS. Страницы с отключённым наследованием остаются opt-out. Для static-сборки шаблон недоступен — меняется исходный проект и загружается новый dist.
• Жизненный цикл: владелец видит статус, оплату, лимиты и дату следующего списания, может явно продлить, отключить без новых списаний, возобновить или архивировать сайт без удаления данных. В опасной зоне доступно необратимое удаление страниц, файлов, заявок, аналитики и данных магазина, но LidFly блокирует его, если у витрины есть заказы, платежи или история продаж: такой сайт можно безопасно отключить.
• Страницы: список опубликованных страниц выбранного сайта, переход к созданию и крупным правкам через встроенный чат.
• Знания: только для knowledge-base. Здесь видны профиль и проект Пространства, public/private/total storage, загрузка текста, URL и приватного файла, readiness источников, citation visibility, deterministic lint, semantic findings, provenance, relations и immutable changeset history. Файл до 50 МиБ хранится вне публичного web root; сервер проверяет формат, но извлечение текста/OCR выполняет внешний ИИ. Кнопка копирует задачу для вашего ИИ. Валидный preview применяется автоматически одной generation без второго подтверждения публикации; повышение storage capacity требует отдельного согласия. Rollback создаёт новый inverse changeset через доступный modal.
• Файлы: загрузка изображений, видео (MP4/WebM), PDF, документов, таблиц, презентаций и текстовых файлов до 10 МБ; отдельная безопасная загрузка SVG-иконок до 64 КБ; полная публикация статического сайта из готового dist.zip или одного HTML.
• Управляемый backend: произвольный Python/Node backend в сайт не загружается; динамика идёт через управляемые endpoint'ы LidFly. Для счётчика слов доступен POST /lidfly/tools/word-counter/:subdomain/analyze.
• Заявки: таблица лидов, фильтр по сайту, пагинация, удаление и экспорт CSV.
• Магазин: подсказки для управления каталогом через ИИ, публикация магазина, YooKassa, товары, услуги, упаковка для расчёта доставки, заказы и модерация отзывов покупателей.
• Свой домен: сначала подключите домен к сайту, затем оставьте у регистратора только A-запись 5.188.119.183, без других A и AAAA. LidFly проверяет запись напрямую на всех авторитетных DNS-серверах и продолжает подключение маршрута и HTTPS автоматически. Кнопка «Проверить» остаётся отдельной диагностикой и не блокирует сохранение домена. CNAME и AAAA пока не поддерживаются. WWW подключается и отслеживается независимо.
• Настройки: Яндекс Метрика по номеру счётчика и бесплатная выдача доступа другому пользователю по email с уровнем «управление» или «администрирование».

Термины дизайна сайта

В LidFly готовые структуры сайта задаются только постоянными шаблонами сайта. Шаблон сайта — site-level дизайн-профиль, который сохраняется у сайта через design_template_id и управляет будущими страницами: темой, header/footer и blueprint. Тема оформления — отдельный визуальный пресет: цвета, шрифт и скругление. Сейчас доступны четырнадцать шаблонов сайта: knowledge-base для публичной базы знаний, restaurant для ресторана или кафе с меню и бронированием, blog-editorial для блога, store-tech для магазина электроники, store-autoparts для магазина автозапчастей, store-jewelry для магазина украшений, store-modular для магазина модульных зданий, store-industrial для производителя промышленного оборудования или инжиниринговой компании с отраслевым мегаменю, video-production для видеопродакшна, interior-atelier для премиум-портфолио, digital-studio для веб-студии, ai-agency для агентства ИИ-видимости, event-luxury для универсального премиального мероприятия и event-anniversary-gold для юбилея, дня рождения, годовщины или семейного торжества с крупной золотой датой. Детальные capabilities и правила публикации возвращает lidfly_list_site_design_templates.

ИИ не должен молча отходить от выбранного шаблона. Перед первой правкой существующего сайта он вызывает read-only lidfly_audit_site_design_template. Проверка показывает выбранный и применённый профиль, site-level theme overrides, локальные темы, шапки, подвалы и CSS, отключённое наследование, изменения стартовых блоков, отсутствие Commerce-данных, отключённые ключевые возможности и конфликты generated-маршрутов. Site-level тема является штатным механизмом и отражается как info, без отдельного guard. Аудит ничего не меняет. Если правка впервые нарушает контракт шаблона, платформа останавливает её до записи; повторить вызов с confirm_template_deviation=true можно только после явного согласия пользователя с указанным последствием.

Галерея шаблонов в кабинете использует тот же SiteDesignTemplate для создания и управления сайтом: карточки получают теги, описание и preview.cover из registry, а preview рендерится сервером из starter.home. При создании кнопка карточки и primary-кнопка preview ведут на #lidfly/create?template=<id>; если начать без шаблона, design_template_id не отправляется. У существующего сайта та же галерея доступна владельцу/администратору по #lidfly/<subdomain>/#template, где текущая карточка отмечена, а выбор или сброс запускает безопасную пересборку. Preview не публикует страницу, не пишет файлы в /sites, не создаёт товары и не оформляет заказы. Для store-tech, store-autoparts, store-jewelry, store-modular и store-industrial в preview показан локальный demo catalog; реальные товары появятся только после добавления каталога в созданном сайте.

Как правильно собирать шаблоны сайта

• Шаблон — не тема: тема задаёт только визуальные tokens, а шаблон задаёт site-level структуру: reusable header/footer, стартовую главную и правила будущих страниц.
• Общий chrome переиспользуется: новые шаблоны должны использовать site-header и site-footer, а не копировать отдельную шапку и подвал под каждый дизайн. Для продуктовых и магазинных шаблонов используйте site-footer с variant: "light", CTA, social links и wide-колонками.
• Главная — обычная страница: starter.home хранит только локальные content blocks. Унаследованные header/footer добавляются при рендере и не записываются обратно в index.json.
• Blueprint нужен редко: новый тип страницы добавляется только если будущие страницы требуют автоматических блоков или metadata. Магазинная главная собирается обычными блоками и не требует отдельного PageKind.
• Cover должен быть настоящим превью: карточка в галерее использует статический preview.cover из /images/lidfly/templates/. Это должна быть мини-страница шаблона, а не skeleton или абстрактная заглушка.
• Preview общий с созданием: fullscreen preview рендерится из того же starter.home, что используется при создании сайта, и не создаёт файлы, товары, заказы или лиды.

Как работает шаблон сайта blog-editorial

Шаблон сайта выбирается при создании сайта в кабинете или через API. Выбор необязательный: если оставить «Без шаблона», сайт работает как раньше, а каждая страница полностью задаётся своим набором блоков. Если выбрать blog-editorial, LidFly сохраняет дизайн-профиль на уровне сайта и сразу публикует обычную главную страницу блога.

• Главная блога: создаётся как страница index с editorial-шапкой, masthead hero, рубриками, статической лентой blog-article-list и чистым CTA. Это не CMS-запись и не отдельный режим редактора — страницу можно дальше менять блоками как любую другую страницу LidFly.
• Наследование: новые JSON-страницы сайта по умолчанию получают тему, header и footer из шаблона при публикации или перерендере. Эти глобальные блоки не записываются повторно в index.json, поэтому локальная структура страницы остаётся чистой.
• Статьи: для статьи используется тип страницы blog_article. При рендере LidFly добавляет хлебные крошки, обложку, время чтения и шапку статьи, а содержательные блоки статьи остаются обычными локальными блоками.
• Отключение наследования: если нужна самостоятельная страница без общей темы, header и footer, MCP-инструменты принимают inherit_site_design=false.
• Смена шаблона: владелец или администратор может выбрать другой шаблон во вкладке «Шаблон» или через MCP. Управляемые HTML-страницы сразу перерендерятся с новым наследуемым оформлением, но их index.json, содержательные блоки и существующая главная не заменяются. При частичном пропуске операцию можно безопасно повторить с тем же шаблоном.

Статьи удобнее публиковать инструментом lidfly_publish_blog_article. По умолчанию он создаёт или обновляет страницу /articles/<slug>; heading_mode: "markdown-h3" превращает отдельные абзацы вида ### Заголовок во внутренние H3, а без параметра сохраняется прежний рендеринг абзацев. Для SEO-миграции 1:1 параметр url_path сохраняет точный legacy-маршрут, например /stati/<slug> или /blog/<slug>. При переданном url_path параметр slug можно не указывать; без url_path он обязателен. Занятый JSON-backed маршрут другого типа не перезаписывается: существующую страницу сначала нужно явно пометить через lidfly_classify_pages либо осознанно заменить через lidfly_update_page. Классификация сохраняет URL, исходные блоки и метаданные в index.json, но пересобирает публичный HTML с blueprint активного шаблона. На blog-editorial публикация дополнительно обновляет legacy editorial-ленту главной.

Как работает шаблон сайта restaurant

Шаблон ресторана или кафе без доставки: витрина и онлайн-бронирование столика. При выборе restaurant LidFly сохраняет тёмную тёплую тему и сразу публикует главную с фоновым видео, меню, галереей, картой и формой брони.

• Hero с видео: блок restaurant-hero-video показывает полноэкранное фоновое видео (autoplay, без звука, зацикленное) с постером; прозрачная шапка premium-header лежит поверх и становится матовой при прокрутке. Своё видео и постер владелец загружает через файлы сайта.
• Меню по категориям: блок restaurant-menu переключает категории по клику без перезагрузки. Категории (завтраки, салаты, основные, винная карта) можно добавлять и убирать; у винной карты фотографии отключаются. Все такие блоки сайта объединяются в единое меню со стабильными ID. Временно недоступное блюдо остаётся читаемым на странице и передаётся в фид с отдельным статусом.
• Бронирование: кнопка «Забронировать» открывает всплывающее окно с формой: имя, телефон со строгой проверкой формата, дата в календаре (не раньше чем через 24 часа), время и число гостей. Заявка приходит как обычный лид на почту, в Telegram и CRM.
• Яндекс.Карты: сначала lidfly_validate_yandex_business_menu показывает, какие блюда и фото войдут в меню и где исправить ошибки. После текстового подтверждения lidfly_set_yandex_business_menu_feed создаёт постоянный публичный YML URL и совместимый XLSX. URL один раз добавляют в Яндекс Бизнес, после чего LidFly автоматически пересобирает фид при изменении меню. Пользовательские файлы не перезаписываются; при закрытой индексации generated-файлы ожидаемо удалены. Старый lidfly_export_restaurant_menu сохранён для разовой CSV/YML-выгрузки.

Последние статьи на витрине или лендинге

На любую управляемую страницу можно добавить блок blog-article-list с пропсами { layout: "grid", source: "auto", heading: "Последние статьи", count: 4 }. Шаблон blog-editorial не нужен, а массив articles не передавайте: LidFly собирает его из всех страниц page_kind=blog_article независимо от URL только на время рендера и не записывает в index.json; главная index всегда исключена из источника. count принимает значения от 2 до 6; showImage, showDate и showDescription включают дополнительные поля. Плитки сортируются по createdAt страницы, поэтому повторная публикация того же slug не поднимает статью наверх; параметр date отвечает только за отображаемую дату. Если статей нет, секция не выводится, а write-инструмент сообщает, что auto-grid нашёл 0 статей и скрыт.

Доступ другому пользователю

Владелец или администратор сайта может назначить другого пользователя в настройках сайта после создания сайта: укажите email, выберите уровень доступа, и человек получит доступ только к этому сайту. Если пользователь уже зарегистрирован в LidFly, доступ выдаётся сразу; если нет — кабинет предложит отправить приглашение. Уровень «управление» даёт работу со страницами, заявками, файлами и магазином, а также подключение этого сайта к своему ИИ через OAuth в собственном аккаунте LidFly. Уровень «администрирование» дополнительно открывает смену шаблона, домен, Метрику, YooKassa и настройки доступа этого сайта. Ни один уровень не открывает команду аккаунта, баланс, API-ключи владельца и другие сайты аккаунта.

Что умеет ИИ-клиент через MCP

Подключённый ИИ работает не с абстрактным конструктором, а с конкретным сайтом из личного кабинета. Если известен URL, поддомен, site_id, свой домен или название, рекомендуемый MCP v3 flow начинается с прямого вызова get_provider_context({"provider":"lidfly","query":"airbarter.lidfly.ru"}). Единственное доступное совпадение возвращается как scope_type="site" с безопасным site_id, точным subdomain, public_url, уровнем доступа и готовым tool_args; для scope из Пространства там также есть workspace_project_id. В рабочий LidFly-инструмент копируется только tool_args. Если сайт заранее неизвестен или query не задан, используйте lidfly_list_sites; без query get_provider_context намеренно не перечисляет сайты. Перед записью ИИ отдельно читает актуальное состояние сайта и publication revision, а сам tool-call повторно проверяет доступ.

Права сайта. Владелец личного сайта и владелец выбранного проекта Пространства имеют уровень admin. Участник Пространства сохраняет точный уровень проекта: read разрешает только чтение, write — обычные изменения сайта, а admin — также домен, Метрику, YooKassa, шаблон и управление доступами. Права действуют только для сайтов, активно привязанных к указанному workspace_project_id; роли разных проектов не объединяются. Отдельный доступ к одному сайту сохраняет выданный уровень write или admin.

Отказ в доступе. MCP отвечает транспортным HTTP 200 с isError=true, а прикладной статус находится в structuredContent.error.http_status. Стабильные коды: site_scope_denied для чужого или неоднозначного scope, site_write_access_denied для попытки записи с уровнем read и admin_required для административной операции. В error.user_message находится безопасное сообщение для пользователя; такой штатный отказ не требует обращения в поддержку. REST API в тех же случаях возвращает реальный HTTP 403 и сохраняет строковое поле error.

• Страницы и блоки: создаёт страницы, читает текущую структуру, добавляет, обновляет и удаляет отдельные блоки без пересборки всего сайта.
• Шаблоны сайта: видит доступные постоянные шаблоны через lidfly_list_site_design_templates, а владелец или администратор меняет профиль через write-инструмент lidfly_set_site_design_template. Для существующего сайта рекомендуемый порядок: lidfly_list_sites → lidfly_audit_site_design_template → нужная правка → повторный аудит. Пустой design_template_id сбрасывает шаблон; безопасная пересборка по умолчанию включена. Статьи на любом управляемом сайте публикуются через lidfly_publish_blog_article; blog-editorial дополнительно оформляет их blueprint-блоками. Локальную тему, header/footer, CSS или inherit_site_design=false ИИ применяет только как осознанное отклонение и передаёт confirm_template_deviation=true лишь после явного согласия пользователя.
• Структура сайта: видит все опубликованные страницы поддомена, их slug, URL и title. Slug у LidFly может быть вложенным page path: главная — index, обычная страница — about, вложенная страница — catalog/conveyor/privodnye-barabany для URL /catalog/conveyor/privodnye-barabany или uslugi/mercedes/w164_ml для URL /uslugi/mercedes/w164_ml. Каждый сегмент: 1-160 символов, латиница, цифры, дефис или подчёркивание в любой позиции, в том числе в начале и конце; общая длина slug/path — до 255 символов.
• Техническое SEO: проверяет indexing_enabled, robots.txt, страницы с noindex и sitemap.xml через lidfly_get_site_indexing. По явному решению о запуске lidfly_update_site_indexing атомарно открывает индексацию и публикует sitemap либо закрывает сайт от краулеров.
• Файлы сайта: загружает изображения, PDF, документы, таблицы и презентации по URL, а SVG-иконки для общей шапки/подвала — отдельным безопасным инструментом lidfly_upload_site_icon. Смотрит список файлов, удаляет неиспользуемые и применяет канонические пути /assets/.... Старые пути assets/... платформа нормализует автоматически.
• Отдельная HTML-страница: lidfly_create_html_page, lidfly_replace_html_page и lidfly_delete_html_page работают с зарегистрированным маршрутом на static- и managed-сайтах. Inline HTML или route-scoped ZIP заменяет только свой bundle; остальные HTML и assets остаются побайтово неизменными. Такая страница не получает blocks, theme, header/footer или index.json.
• Готовый static-сайт: полный root публикуется только через lidfly_preview_static_site_deploy → проверку diff и candidate_digest → lidfly_deploy_static_site. Зарегистрированные HTML-bundles сохраняются автоматически, а коллизия их маршрутов блокирует preview.
• Backend-сценарии: не загружает произвольный серверный код, а подключает платформенные endpoint'ы. Пример для приложений внутри сайта: POST https://lidfly.ru/lidfly/tools/word-counter/<subdomain>/analyze с JSON {"text":"..."}.
• Формы, лиды и статистика: ставит формы, получает заявки с UTM, смотрит просмотры, уникальных посетителей и конверсию, включает Яндекс Метрику по номеру счётчика.
• Магазин и заказы: публикует каталог, управляет коллекциями, вариантами товаров, SKU, остатками, YooKassa продавца, заказами и статусами доставки. Каталог по умолчанию ставит товары в наличии первыми; у блока product-grid проп inStockOnly=true скрывает товары под заказ и без остатка, а showInStockToggle=true показывает посетителю переключатель «Только в наличии».
• AI-медиа: готовит промпты для изображений, генерирует их только после подтверждения, смотрит недавние картинки, запрашивает загрузку файлов, транскрибирует аудио и получает расшифровки.

Блоки

Семантика страницы задаётся типизированным page_kind: service добавляет отдельный Service с provider и areaServed из SEO Entity Profile, а collection/blog_home создают CollectionPage и дедуплицированный ItemList из поддерживаемых видимых листингов. В media-spotlight заголовок карточки по умолчанию остаётся h3; для video hero можно задать ровно один headingLevel:"h1". Визуальный класс не меняется, а конфликт с другим H1 блокирует публикацию.

111 блоков в 7 категориях. ИИ узнаёт список доступных блоков и их пропсы через lidfly_list_blocks. Для точного production-портфолио доступны logo-service-rail с двухстрочной навигацией услуг, responsive-лимитами логотипов до 420×220 px и индивидуальными maxWidth/maxHeight, overlap-services-showcase с вариантами staggered-overlap/compact-collage, явными строками heading.lines, bounded desktopStyle/mobileStyle и ограниченной геометрией отдельных элементов, messenger-lead-band со штатной лид-формой и мессенджерами, editorial-about-stats для единой композиции about/play/метрик, stacked-pricing-groups для последовательных групп цен без табов, а также diagnostic-cards и diagnostic-split для диагностических секций с карточками, статистикой, CTA и фото. Для мероприятий доступны hero, countdown, история, программа, места, RSVP/questionnaire, рассадка, вишлист, музыка, галерея, объявления, контакты и quick actions; для магазинов — отдельный commerce-header, editorial hero/коллекции/подписка, store-delivery-estimator, store-product-quiz, catalog-node-grid, catalog-brand-rail и platform-owned catalog-facet-links.

diagnostic-split принимает прежние image/imageAlt или массив images из 1–10 объектов { image, imageAlt? }. Непустой валидный images имеет приоритет, а первый кадр при записи зеркалируется в legacy-поля для безопасного rollback; images: [] возвращает блок к одиночному image. imageDisplayDurationMs задаёт время полностью видимого кадра (по умолчанию 5000 мс, диапазон 1000–30000), fadeDurationMs — длительность crossfade (по умолчанию 800 мс, диапазон 100–5000). Один кадр остаётся статичным. Автосмена запускается только для нескольких загруженных кадров, пропускает ошибки, приостанавливается вне viewport и на скрытой вкладке и полностью отключается при prefers-reduced-motion.

Для российского телефона в formFields блока messenger-lead-band доступна отдельная настройка phoneMask: {"country":"RU","prefix":"+7","format":"+7 (###) ###-##-##","ignoreLeading":["7","8"],"submitFormat":"E.164"}. Она удерживает префикс +7, одинаково форматирует клавиатурный ввод, вставку и автозаполнение и сохраняет в заявке номер вида +79991234567. Без phoneMask существующие формы работают как раньше; ошибочный контракт отклоняется до публикации.

У messenger-lead-band есть отдельный bounded desktopStyle для точного reusable-воспроизведения CTA без custom CSS: отступы и сетка, колонка и типографика заголовка, мессенджеры, описание, ширина и высота поля/кнопки, рамки, радиусы и дисклеймер. Числа нормализуются до сохранения и повторно ограничиваются renderer. Desktop-настройки не меняют mobileStyle, штатную форму и телефонную маску.

Обычная managed-страница с page_kind=default принимает до 60 сохранённых блоков; страницы blog_home, blog_article, project и event_home — до 20. Inherited header/footer и blueprint-блоки в лимит не входят. Превышение отклоняется до записи с кодом page_block_limit_exceeded и полями page_kind, actual_blocks, max_blocks. Лимит итогового HTML остаётся 512 КиБ. Commerce slots отдельно сохраняют лимит 20 effective blocks.

video-embed принимает только безопасные HTTPS-формы YouTube, VK Video и Rutube embed. YouTube сохраняется через youtube-nocookie.com; текущие и ранее поддержанные VK page/playlist URL — через vk.com/video_ext.php с oid, id и валидным необязательным непустым hash; пустой hash и параметр hd не переносятся. Неизвестный host, credentials, custom port или невалидный непустой hash возвращает unsupported_video_embed с block_index и block_type до изменения страницы. В text-content можно явно задать headingMode: "markdown-h3": тогда отдельный непустой абзац ### Заголовок станет экранированным H3. Без этого поля старый текст рендерится без изменений; якорь задаётся через обычный id блока.

Для product-grid доступны независимые настройки наличия: inStockOnly задаёт начальный или фиксированный режим «только в наличии», а showInStockToggle управляет видимостью переключателя для посетителя. Если оба пропа выключены, каталог показывает все товары, сохраняя порядок «в наличии — сначала».

yandex-maps-embed безопасно встраивает карту и живые отзывы: передайте ID или ссылку карточки организации в orgId, а для своей карты — iframe из «Поделиться» либо код Конструктора в mapEmbedUrl. Сторонний JavaScript из кода Конструктора на страницу не добавляется.

yandex-rating-badge добавляет компактный официальный рейтинг Яндекс Бизнеса 150×50, как на Airbarter: на страницу — обычным блоком с orgId, в premium-header, commerce-header, site-header или gallery-header — элементом {"kind":"yandex-rating","orgId":"..."} массива topStrip.items, а в site-footer или gallery-footer — полем yandexRatingOrgId. Принимается только цифровой ID или официальная HTTPS-ссылка карточки организации; iframe собирается платформой.

Промежуточный корневой пункт хлебных крошек витрины настраивается через breadcrumbs.catalogRoot. По умолчанию это Каталог → /catalog/. Режим link принимает label до 80 символов и безопасный внутренний managed path url, например /uslugi/; hidden убирает только этот пункт. Product, плоский каталог и taxonomy используют один массив для visual SSR и BreadcrumbList. Taxonomy добавляет root только при совпадении или реальном URL-родстве, поэтому независимый маршрут /audi/ не получает искусственный /catalog/.

Внешний вид каталога задаётся через catalog.cardVariant (standard или borderless editorial), catalog.imageRatio (square или portrait) и catalog.hoverImage. Для товарной страницы productPage.layout = gallery-sticky включает большую галерею и закреплённую колонку покупки, а productPage.mobileStickyBuy = true — нижнюю мобильную панель с ценой и кнопкой. Эти настройки наследуются generated catalog/taxonomy/product routes и не меняют данные товаров.

Site-level блоки generated-страниц настраиваются через catalogNodePage.slots (beforeCatalog, afterChildren, afterProducts, afterCatalog) и productPage.slots (beforeProduct, afterProduct). Общий allow-list из 24 типов: text-content, faq-accordion, cta-banner, feature-split, gallery-grid, table-data, video-embed, yandex-maps-embed, yandex-rating-badge, features-grid, steps-horizontal, testimonials-cards, team-grid, logo-cloud, logo-cloud-cases, comparison-table, progress-bars, store-trust, media-bento, case-study, agency-statements, agency-services, agency-segments, pricing-3col. Изображения принимают managed-путь /assets/* или абсолютный HTTP(S) URL, а ссылочные props — только внутренний путь /... или якорь #.... Taxonomy node может полностью заменить inherited slot или передать []; reset возвращает только этот node к site defaults. Product slots одинаковы для всех товаров и не имеют per-product override. Перед записью используйте lidfly_preview_storefront_blocks: он ничего не меняет, проверяет базовые и региональные HTML-кандидаты, лимиты 20 блоков / 256 КиБ JSON / 512 КиБ HTML и возвращает paginated route diagnostics.

Для generated товарных маршрутов также сохраняется legacy-compatible site-level настройка productPage.externalReviews в lidfly_update_storefront_design. Виджет по умолчанию выключен; при включении принимает только provider = yandex_maps, ID или HTTPS-ссылку карточки организации в orgId, необязательный orgTitle и высоту 500–900 px. Платформа сохраняет цифровой ID, строит безопасный canonical iframe и показывает его один раз внутри существующей секции отзывов. Generic yandex-maps-embed не заменяет и не дедуплицирует этот механизм.

Пустой url_path товара публикуется по адресу /product/<slug>/. Явный custom path сохраняется для миграции 1:1. Canonical, sitemap, ссылки каталога, Schema.org и товарные фиды используют один конечный URL с завершающим /; активный custom domain применяется только после подтверждения. Старые marker-owned generated-маршруты /p/* удаляются следующей публикацией без автоматического redirect, а пользовательские страницы без маркера сохраняются.

Managed-страницы получают единый platform JSON-LD graph: WebSite/WebPage, расширенный Article, безопасный VideoObject, Service или Event, а для магазина — Product либо совместимый с Яндексом и Google ProductGroup + Product с реальными variant Product/Offer. Generated-каталоги дополнительно размечают видимые SSR-карточки одним OfferCatalog. Фактическая организация и конкретный тип локального бизнеса задаются через lidfly_get_site_seo_profile → lidfly_update_site_seo_profile; условия доставки и возврата публикуются только на странице с видимым блоком условий store-trust. Валидные опубликованные товарные отзывы могут войти в Product; внешние отзывы организации никогда не копируются в JSON-LD. Разметка даёт техническую пригодность, но не гарантирует позиции, звёзды или расширенный результат.

ИИ-клиент меняет типизированные источники данных, а не generated JSON-LD, HTML, RSS, sitemap или feed-файлы. Профиль организации управляет Organization/LocalBusiness; поля страницы title, description и og_image — Open Graph и Twitter Cards; props блока video-embed — VideoObject; lidfly_publish_blog_article — Article и RSS; PostgreSQL Commerce вместе с lidfly_publish_store — Product/ProductGroup/OfferCatalog и товарные фиды. В MCP v3 соблюдайте search_tools → get_tool_schema → call_tool/call_write_tool, точный subdomain, read → write → reread и CAS-поля из последнего чтения. Регистрация готового YML URL в Яндекс Вебмастере остаётся отдельной подтверждаемой операцией с точным host_id.

На managed-страницах canonical, полный Open Graph, Twitter Cards и Schema.org используют один активный публичный origin. Для статей публикуются ISO-даты, автор, изображение и теги; для видео — безопасный embed, preview, дата и длительность при их наличии. При открытой индексации и наличии статей сайт создаёт marker-owned /rss.xml; пустой feed не публикуется, региональные копии используют собственный host, а конфликт с пользовательским /rss.xml возвращается как warning. lidfly_publish_store создаёт /yandex-market.yml и /google-merchant.xml из PostgreSQL Commerce: только активные физические товары, по одному item на вариант, без выдуманных GTIN/MPN. В YML дата формируется в UTC по RFC 3339, а внешние offer id и group_id стабильно приводятся к допустимому Яндексом формату длиной до 20 символов без изменения внутренних ID, SKU, маршрутов и исходного ?variant=. Вариант без доступного HTTPS-изображения исключается, поскольку picture обязателен для Яндекс Товаров; итоговые included_variants и excluded_variants считаются после всех проверок. Варианты price_mode=on_request штатно исключаются и отдельно считаются в on_request_excluded_variants без warning missing_price. Feed warnings, включая коллизию внешнего ID, не блокируют HTML-публикацию. Если crawler_indexing_blocked=true, отсутствие sitemap, RSS и generated feed-файлов является ожидаемым; marker-owned файлы удаляются, пользовательские файлы на тех же путях не перезаписываются.

Цена по запросу. У варианта есть единый контракт: price_mode=fixed требует price_rub, а price_mode=on_request не принимает числовую цену и может содержать price_request_text (по умолчанию «Цена по запросу»). Он одинаков для создания одного товара, batch create/update и файлового импорта. Режим доступен только при checkout_mode=manager_request. Во всех шаблонах карточка, товарная страница, корзина, заявка, кабинет и CRM показывают текст вместо 0 ₽; Schema.org не публикует для такого варианта Offer, а смешанная заявка не получает ложный числовой итог. Нулевые legacy-цены автоматически не переводятся в этот режим.

Состав generated storefront routes настраивается отдельно от шаблона сайта через read-before-write flow lidfly_get_storefront_routes → lidfly_update_storefront_routes. Можно независимо управлять ключами catalog, account, favorites, compare и business; platform default для каждого — true. catalog=false отключает только generated /catalog/: страницы /catalog/<collection>/, товары, taxonomy, /checkout/, /order/, корзина и заказы продолжают работать. Sparse-настройка хранится на уровне сайта, переживает смену шаблона и применяется при каждой Commerce-публикации: marker-owned HTML удаляется без удаления index.json, точный root исключается из sitemap, а платформенные ссылки и поиск не ведут на отключённый маршрут. reset для выбранного ключа и reset_all возвращают platform defaults.

Read-tool разделяет artifact_status и route_occupancy. Если на отключаемом slug остаётся пользовательский config или custom HTML, write-tool сохраняет его и возвращает машинный warning_details с безопасным next_safe_call; автоматического удаления пользовательской страницы нет. lidfly_get_page, lidfly_list_pages и кабинет дополнительно разделяют desired_owner, artifact_owner, artifact_kind и conflicts[], не меняя legacy route_kind/source. В managed-режиме pages_count считает все HTML-маршруты, включая generated product/catalog/taxonomy/checkout/customer pages. Полный projected count проверяется до первой записи артефакта, а после успешной Commerce-публикации pages_count и storage_bytes один раз сохраняются по проверенному фактическому инвентарю.

При persistent Commerce claim обычные create/update/block tools остаются заблокированы. После диагностики lidfly_delete_page может явно удалить только пользовательский index.json и ordinary/custom HTML; matching generated HTML с точным marker всегда сохраняется. Marker mismatch, orphan generated artifact и несколько persistent owners блокируют удаление без записи. Успешный ответ перечисляет deleted_artifacts, preserved_generated_html, publish_required и исполнимый next_safe_call с новой publication revision. Taxonomy/facet cleanup ведёт в lidfly_preview_catalog_publish, остальные Commerce routes — в lidfly_publish_store; для настраиваемых root/customer routes можно сначала отключить generated route через lidfly_get_storefront_routes → lidfly_update_storefront_routes и сохранить пользовательскую страницу.

Для вложенных Commerce-каталогов используется persistent taxonomy brand → model → condition → part_category. Collections остаются отдельными плоскими группами товаров и не заменяют дерево маршрутов. Один товар может входить в несколько узлов, но primary node только один: он задаёт полные breadcrumbs и ссылку «Назад к модели», не меняя canonical и сохранённый url_path товара. Root /catalog/ показывает общую иерархию всех публикуемых активных узлов перед товарной сеткой; это часть общего renderer/publisher и одинаково работает во всех магазинных шаблонах. Каждая сетка сериализует в SSR и OfferCatalog не более первых 24 карточек. Generated taxonomy/facet routes передают серверный scope ID вместо длинного массива productIds; пользовательский taxonomy-блок без проверенного scope по-прежнему fail-closed и не показывает чужие товары.

GET /api/storefront/:subdomain/catalog по умолчанию возвращает 24 товара, максимум 100, lightweight detail_level=summary и непрозрачный next_cursor, привязанный к точному scope. Поддерживаются scope по product/variant IDs, taxonomy-узлу с descendants, facet и collection. Runtime делает один scoped-запрос и по кнопке «Показать ещё» — ровно один cursor-запрос; он больше не загружает весь каталог или taxonomy fan-out при открытии страницы. Полный DTO товара запрашивается лениво только при открытии quick-view. Taxonomy nodes/memberships остаются отдельным диагностическим API с лимитом 500.

Перед резервированием новой publication_revision lidfly_publish_store под общей блокировкой выполняет read-only exact-HTML preflight плоского каталога, taxonomy и facets, включая лимит 512 КиБ. Детерминированная ошибка размера, структуры или маршрута поэтому не расходует ревизию и не оставляет пустой /catalog/. Диагностика ответа ограничена 100 элементами на массив; details_truncated/details_total явно показывают усечение, а details_read_tool ведёт к полному read-only preview.

Для импорта больших каталогов используйте приватный flow lidfly_request_products_import_upload → curl -T → lidfly_import_products(dry_run=true) → реальный import → lidfly_publish_store. Один JSON/JSONL может занимать до 50 МиБ и содержать до 5 000 товаров; JSON принимает только плоский top-level array, JSONL — один объект на непустую строку. Одноразовый URL действует 5 минут, приватный файл — 1 час, публичного GET нет. Dry-run исполняет ту же транзакционную логику с rollback; реальный import меняет только PostgreSQL desired state и не увеличивает publication revision. Отчёт содержит counts, первые 50 ошибок и errors_truncated.

Повторяемые add-ons можно хранить в site-level preset-ах через lidfly_manage_addon_presets и назначать товару упорядоченным addon_presets[]. Management read различает локальные addons, ссылки addon_presets и итоговые effective_addons; storefront по-прежнему получает итог в существующем поле addons. Preset-ы раскрываются по порядку, duplicate code между ними отклоняется, локальный add-on с тем же code заменяет preset item на его позиции, максимум итогового набора — 100. Секция productPage.sections[].id = addons серверно рендерит группы, radio/checkbox, количество и разбивку цены; браузер прогрессивно добавляет пересчёт. Выбор сохраняется отдельной строкой корзины для каждой комплектации и доезжает до заказа и уведомления. Preview, quote и заказ используют один server-authoritative resolver.

Generated taxonomy-страницы управляют порядком через storefront.catalogNodePage.sectionOrder: auto (по умолчанию), products-first или children-first. В режиме auto прямые публикуемые товары показываются перед подразделами, а узел без прямых товаров сначала показывает подразделы. Плотность обычной сетки задаёт catalogNodePage.childNodeGrid: fallback desktopColumns и правила byChildKind для однородных brand, model, condition или part_category. Допустимы только 2–6 колонок; mixed-набор использует fallback. Responsive policy: 1 колонка до 560 px, 2 до 900 px, максимум 3 до 1199 px и настроенное значение от 1200 px; 5–6 включают компактный SSR-профиль. tree, одиночный cross-link и товарный .lf-product-grid не меняются. Site-level reset_paths удаляет отдельный leaf и восстанавливает inheritance. На странице остаётся ровно один H1. Единственный дочерний condition выводится компактной ссылкой «Не нашли что искали?», остальные дочерние узлы — обычной сеткой.

Per-node presentation наследуется по цепочке platform → template → site → node и хранится отдельно от generated HTML. Через lidfly_get_catalog_node_page и lidfly_update_catalog_node_page можно задать безопасные H2-подписи и все двадцать три allow-listed типа блоков в slots beforeCatalog, afterChildren, afterProducts, afterCatalog. Массив node является полной заменой inherited slot; [] скрывает его, reset снова наследует site default. Системные H1, breadcrumbs, товары, дочерние узлы, SEO intro, cart и chrome не входят в override. После write обязателен flow lidfly_preview_catalog_publish → lidfly_publish_store; обычные page tools generated route не заменяют.

Маршруты товаров, коллекций и taxonomy проверяются под общей блокировкой магазина. Активный taxonomy-узел блокирует свой путь, а архивный сохраняет прежние ID, key, parent и route для истории, но освобождает route для товара или активной коллекции. Правило намеренно асимметрично: строка товара резервирует непустой url_path независимо от статуса, поэтому soft-delete/archive товара не освобождает route для create/restore taxonomy-узла. Чтобы вернуть узел, сначала прочитайте дерево с include_archived=true, затем вызовите lidfly_manage_catalog_node с action=restore и прежним key или ID. Для дочернего node родитель уже должен быть active; если route успел занять товар или коллекция, restore безопасно отклоняется. Restore не восстанавливает детей и memberships, не публикует сайт и всегда ведёт к preflight через lidfly_preview_catalog_publish. При следующей обычной или degraded-пересборке устаревший marker-protected taxonomy-артефакт удаляется до записи товарной страницы, а пользовательская страница без системного маркера сохраняется. Если одна из дополнительных страниц большого публичного каталога временно недоступна, витрина сохраняет SSR-карточки и продолжает использовать уже загруженные товары и фильтры.

Hero (главный экран)

Контент

Данные и диаграммы

Конверсия и подвал

Темы

15 готовых цветовых тем. ИИ автоматически подбирает тему по тематике бизнеса. Можно переопределить отдельные цвета через theme.

Пример кастомизации: theme_preset: "wellness" + theme: { accentColor: "#8B5CF6" } — берёт всё от wellness, но заменяет акцентный цвет на фиолетовый.

Если фон темы не белый, задавайте вместе с ним cardColor — цвет карточек и панелей поверх фона. Например theme: { backgroundColor: "#F5F5F7", cardColor: "#FFFFFF" } даёт серое полотно и белые карточки товара; без cardColor карточки заливаются цветом фона и сливаются с ним.

Подключение

1. Создайте сайт в личном кабинете

Откройте раздел LidFly и создайте сайт. Например, поддомен my-shop станет my-shop.lidfly.ru. Сайт создаётся и оплачивается в личном кабинете: от 490 ₽ за 30 дней за блок из 1000 контентных страниц и 3 ГБ; после этого можно собрать лендинг, магазин или оставить адрес пустым до первой публикации. Внешний ИИ управляет уже созданным сайтом через MCP.

2. Настройте ИИ-клиент

3. Попросите ИИ собрать или изменить страницу

Создай лендинг для стоматологической клиники "Улыбка".
Услуги: лечение, протезирование, имплантация, отбеливание.
Форма записи на приём. Телефон: +7 (999) 123-45-67.

ИИ сначала проверит доступные сайты, выберет созданный поддомен, затем подберёт тему оформления, блоки и опубликует страницу. Так же можно попросить изменить отдельный блок, добавить форму, загрузить изображение или подготовить магазин.

Примеры использования

Событийные шаблоны

event-luxury — универсальный премиальный шаблон для свадьбы, корпоратива или конференции. event-anniversary-gold — более яркий вариант с большой золотой датой для юбилея, взрослого дня рождения, годовщины, семейного банкета, выпускного или встречи выпускников. Оба используют один событийный runtime: публичные тексты, программа и оформление остаются в статической странице, а персональные приглашения и изменяемый RSVP хранятся отдельно в PostgreSQL и загружаются только после открытия страницы.

• Персональная ссылка: токен передаётся во fragment #invite=…, удаляется из адресной строки до запроса и обменивается на HttpOnly-сессию; открытый токен в базе не хранится.
• RSVP: один ответ на человека, пару или семью можно изменить до дедлайна; revision и idempotency защищают от дублей и перезаписи с другого устройства.
• Приватность: закрытое событие получает noindex, nofollow. Имена, контакты и ответы не встраиваются в HTML, index.json или preview. Sensitive-ответы требуют отдельного согласия, шифруются и очищаются через 30 дней после окончания.
• Рассадка: организатор назначает только подтвердивших участие гостей; вместимость стола и уникальность нумерованного места проверяются транзакционно. Гость видит рассадку только своей группы и только после заданной даты.
• Вишлист: последний экземпляр подарка резервируется атомарно, резерв можно снять. В surprise mode организатор видит количество резервов, но не личность дарителя.
• Программа и календарь: несколько мест, ссылки на Яндекс Карты, 2ГИС и Google Maps, лёгкая lazy-карта, ICS в timezone события и live-объявления без повторной публикации.
• Кабинет: вкладка «Событие» доступна только владельцу или site admin любого шаблона с capability event_publishing; разделы управляют настройками, гостями, RSVP, вопросами, рассадкой, вишлистом, программой, объявлениями, медиа и статистикой. CSV защищён от formula injection.
• Уведомления и retention: email работает в режимах immediate, daily digest или disabled через transactional outbox. Sensitive-ответы, истёкшие токены и сессии очищаются кластерно-безопасной задачей через 30 дней после события.

MCP-инструменты

189 инструментов для полного цикла: от управления страницами, route-owned HTML-bundles, индексацией, Agent/GEO readiness, favicon, verification meta tags, шаблонами, SEO Entity Profile, self-updating knowledge changesets, storefront-дизайном и generated customer routes до приватного импорта 5 000 товаров, site-level add-on preset-ов, persistent-редактирования taxonomy Commerce-каталога, событий Lumière, регионального магазина, отзывов, checkout, вариантов товаров, заказов, Метрики, сквозных нативных видео- и messenger-виджетов, уведомлений о заявках, интеграций Bitrix24 и MANGO OFFICE, immutable assets с явной атомарной заменой, preview-only полной публикации, экспорта меню ресторана в Яндекс.Бизнес, блоговых статей, проектов, AI-изображений, транскрибации аудио и личной поддержки.

Self-updating knowledge-base. Эти инструменты доступны только внешнему MCP-клиенту и намеренно отсутствуют во встроенном чате. Workspace-часть создаёт/читает/архивирует immutable sources через workspace_request_knowledge_source_upload, workspace_finalize_knowledge_source, workspace_list_knowledge_sources, workspace_get_knowledge_source, workspace_request_knowledge_source_download и workspace_archive_knowledge_source. Upload/download URLs — короткоживущие одноразовые private capabilities, поэтому обе операции их выдачи помечены как write; pending-файлы ограничены суммарной квотой. Архивация освобождает storage usage и удаляет оригинал. URL-source сервер не скачивает. Содержательная часть работает через восемь LidFly tools ниже и один exact workspace_project_id.

Custom CSS. Каскад фиксирован: токены темы сайта → платформенный CSS блоков → CSS сайта → CSS страницы; страница переопределяет сайт при равной специфичности. Действующий CSS обоих уровней вместе с размерами и sha256 читается одним вызовом lidfly_get_css. Одну страницу правит lidfly_update_page_css — блоки в операции не участвуют, поэтому правка стиля не может потерять секцию; сквозные правила сайта — lidfly_update_site_css, он пересобирает все управляемые страницы, товарные и региональные артефакты. Пустая строка очищает уровень. Лимит — 64 КиБ на уровень, последовательность </style запрещена. Страница с inherit_site_design=false не наследует CSS сайта. Неудачная запись не двигает publication_revision, а повтор того же CSS страницы не стоит ревизии.

Нативный видеовиджет. lidfly_get_floating_video_widget читает сквозную site-level настройку и проверяет managed assets; lidfly_update_floating_video_widget безопасно пересобирает все managed-маршруты. После lidfly_upload_file нужно повторить get и передать в update свежие expected_updated_at/expected_publication_revision: upload меняет CAS сайта. В HTML изначально нет запроса к ролику: один <video preload="none"> публикуется без src/source, а managed MP4/WebM назначается тому же элементу после порога прокрутки. Маленький режим muted+loop; реальный click перезапускает тот же файл со звуком. close_persistence=session скрывает виджет до конца вкладки, page — только до следующей загрузки страницы. Встроенная Метрика получает цели video_widget_show, video_widget_open, video_widget_close и video_widget_complete; сторонние SDK и произвольный JavaScript не нужны.

Нативный виджет связи. lidfly_get_floating_messenger_widget читает site-level конфигурацию, нормализованные URL, custom SVG diagnostics и оба CAS guard; lidfly_update_floating_messenger_widget настраивает до шести упорядоченных каналов и строго пересобирает все managed-маршруты. Один канал становится прямой SSR-ссылкой, два–шесть — доступным <details> со списком, который работает и без JavaScript. Поддерживаются Telegram, WhatsApp, MAX, Viber, VK, Instagram, Facebook и явный публичный HTTPS URL; известный тип проверяется по официальному hostname. Общую и отдельные иконки сначала загружают через lidfly_upload_site_icon, после upload обязательно повторяют get. Виджет только открывает ссылку: боты, переписка и передача диалога в CRM остаются внешней интеграцией клиента, токены мессенджеров LidFly не получает.

Точки привязки для CSS. Каждая секция опубликованной страницы несёт data-lf-block, data-lf-block-index и data-lf-block-id при заданном якорном id; ключевые внутренние элементы — объявленные блоком data-lf-part из общего словаря (section, inner, heading, subheading, text, media, list, item, card, card-title, card-text, actions, cta, form, field, submit, caption, badge, price, header, brand, navigation, search). Состав ролей каждого блока возвращает lidfly_list_blocks. Это контракт: имена не меняются без версии контракта. Генерируемые скоуп-классы вида ossk4dv8j-* и селекторы по подстрокам классов контрактом не являются.

В premium-header, site-header и gallery-header верхняя полоса задаётся единым topStrip.items (до 16 элементов) и сохраняет точный порядок text/social/phone/email/work-hours/delivery/yandex-rating в SSR DOM. align: start, center или space-between. Наличие topStrip подавляет inherited legacy-поля, а {"items":[]} явно скрывает полосу. Региональные контакты используют source:"region" и необязательный fallback. mobileActions без значения включает platform defaults, пустой массив отключает быстрые действия, а явный массив выводится без перестановки и дублей. Предупреждения мобильной конфигурации возвращаются отдельно в responsive_diagnostics.

Все четыре shared header поддерживают полный responsiveLayout для независимой desktop/mobile-композиции без копирования данных. Desktop-зоны: utility, brandAfter, navigationAfter, actions; mobile-зоны: utilityStart, utilityEnd, actions. Роли info, socials, phone, email и yandex-rating берут данные только из topStrip.items. Порядок массивов — порядок SSR DOM, пропущенная роль скрыта, повтор в одном breakpoint отклоняется. На mobile прокручивается только utilityStart, а закреплённая utilityEnd сохраняет рейтинг 150×50. responsiveLayout нельзя смешивать с mobileActions/hideTopStripOnMobile в одном set; reset responsiveLayout возвращает сохранённое legacy-поведение.

На desktop общий fit-runtime измеряет реальные brand/navigation/actions-зоны с их padding и gap и включает compact только при переполнении или пересечении более 1 px; возврат в полную строку требует 10 px запаса. Mobile breakpoint остаётся собственным для каждого семейства: 900 px у premium-header/site-header, 1100 px у commerce-header и 820 px у gallery-header. В compact отдельное SSR-меню сохраняет навигацию, utility links, контакты, соцсети и другие скрытые роли независимо от мобильного burger-меню; остающиеся inline-действия не дублируются.

Поле contentWidth принимает только default или wide. Отсутствующее значение сохраняет прежние ограничения конкретного header, а wide opt-in расширяет ограниченные строки до 1480 px. Произвольные пиксели не принимаются; reset contentWidth возвращает семейный default. Диагностика desktop_compact_fallback_moves_content статически перечисляет роли, которые могут перейти в compact-меню, но не утверждает collapse на конкретной ширине. desktop_compact_content_unavailable предупреждает об отсутствии fallback и для поддерживаемых комбинаций не появляется. Ранее опубликованный managed HTML получает новый runtime при следующем publish/rebuild, без массовой пересборки.

commerce-header — отдельная магазинная шапка с тем же ordered top strip. desktopLayout задаёт один или два ряда вверху страницы, а collapseOnScroll:true после прокрутки полностью скрывает ряд навигационных ссылок и оставляет в плавающей полупрозрачной строке только бренд и действия; верхняя информационная полоса также скрывается. Порог настраивается через scrollThreshold.

В мобильном burger panel premium-header и commerce-header выбор региона имеет стабильную высоту 48 px: MapPin 20 px, название с ellipsis и ChevronDown 18 px. Кнопка открывает существующий dialog выбора региона; icon-only quick action остаётся без chevron.

Для premium-header и commerce-header поле logoSize принимает compact, regular или large. Точную высоту задают desktopPresentation.logoHeight (20–160 px), desktopPresentation.logoHeightScrolled (20–120 px), mobilePresentation.logoHeight (20–96 px) и mobilePresentation.logoHeightScrolled (20–72 px). Явное число выигрывает только в своём состоянии, отсутствующее поле берётся из preset, а семейный default — regular. Без logoImage настройки не меняют декоративную марку или текстовый бренд.

{
  "logoSize": "large",
  "desktopPresentation": { "logoHeight": 80, "logoHeightScrolled": 48 },
  "mobilePresentation": { "logoHeight": 62, "logoHeightScrolled": 48 }
}

Изображение сохраняет пропорции (width:auto, object-fit:contain) и ограничивается доступной шириной brand-контейнера. У commerce-header explicit mobile-значения действуют на всём breakpoint до 1100 px; без них старая геометрия не меняется. set shallow-merges top-level props, поэтому при изменении premium-header.mobilePresentation передавайте полный текущий объект из свежего lidfly_get_site_chrome, включая burger/drawer-поля.

premium-header.ctaStyle поддерживает отдельные desktop/mobile варианты. borderPlacement:"inside" рисует contrast-рамку внутрь кнопки и сохраняет её внешний размер. Через mobilePresentation настраиваются высота логотипа, размер burger trigger, ширина/интервал линий burger и плотность drawer: font-size, line-height, gap и padding. Все числовые значения ограничены безопасными диапазонами renderer.

У любого блока страницы есть общее поле visibility рядом с type, props и id: {"mobile":false} скрывает блок до 767 px, tablet:false — на 768–1023 px, desktop:false — от 1024 px. Поле сохраняется в managed JSON и не удаляет блок на других ширинах. В секциях шаблона video-production мобильная типографика и интервалы задаются bounded-полем mobileStyle; overlap-services-showcase дополнительно принимает bounded desktopStyle, items[].desktopStyle, явные heading.lines и variant="compact-collage", а messenger-lead-band — отдельный bounded desktopStyle для CTA и формы. Значения нормализуются до записи, а compact-композиция на mobile всегда становится одной колонкой без горизонтального overflow. project-grid и team-grid принимают mobileLayout:{"mode":"carousel","cardWidth":94,"gap":12} для нативной mobile scroll-snap карусели без autoplay. team-grid также принимает desktopLayout.mode="carousel": visible cards, gap, step, loop, optional autoplay, startIndex, доступные Lucide-стрелки и клавиши ←/→. Все реальные members остаются в SSR, а loop-копии создаются только в браузере как inert/aria-hidden. headingParts оформляет muted/accent/text части внутри одного h2, а bounded desktopStyle управляет контейнером, интервалами, изображениями, порядком текста, типографикой, цветами и стрелками. Явный imageHeight имеет приоритет над imageAspectRatio. Без новых desktop-полей сохраняется прежняя статическая сетка. В project-grid variant="video" элемент с videoUrl YouTube, VK Video или Rutube открывает адаптивное модальное видео после клика, а элемент только с url остаётся обычной ссылкой; iframe заранее не загружается. logo-service-rail.serviceColumnsMobile принимает до 5.

Для site-footer поле logoSize принимает compact, regular или large: максимальная высота логотипа равна 28, 34 или 48 px. Изображение сохраняет натуральные пропорции, ограничено шириной 260 px на desktop и доступной шириной контейнера на mobile.

Для соцсетей в общей шапке или подвале соблюдайте read-before-write: lidfly_get_site_chrome → при необходимости lidfly_upload_site_icon → lidfly_update_site_chrome. Переданный socials заменяется целиком. Встроенная иконка задаётся как {"kind":"builtin","name":"vk"}, пользовательская — только возвращённым managed path: {"kind":"asset","src":"/assets/brand.svg","colorMode":"monochrome"}. Если icon опущен, площадка определяется по type, затем по точному hostname; raw SVG, data URI и внешний icon URL не принимаются.

Подтверждение прав на сайт

Владелец или администратор может хранить несколько кодов подтверждения на уровне сайта. Для managed-публикации LidFly добавляет нормализованные теги во все генерируемые страницы. Для static-публикации меняется только управляемый marker-блок в корневом index.html; пользовательские теги вне блока сохраняются, а HTML verification files не создаются.

REST: GET /api/lidfly/sites/:subdomain/verifications, POST /api/lidfly/sites/:subdomain/verifications и DELETE /api/lidfly/sites/:subdomain/verifications/:verificationId. Все записи требуют актуальную expected_publication_revision. Для проверки точного тега используйте ?check_publication=true; результат показывает только публикацию, после чего подтверждение нужно завершить в выбранном сервисе.

Для Яндекс Вебмастера безопасный MCP-flow: webmaster_get_verification → lidfly_set_site_verification → lidfly_get_site_verifications(check_publication=true) → отдельное подтверждение пользователя → webmaster_start_verification(method="META_TAG"). Google Domain property нельзя подтвердить meta tag: используйте DNS. Meta tag подходит для URL-prefix property.

Готовые статические сайты

LidFly публикует готовый статический сайт целиком. Многофайловую сборку загрузите как dist.zip; один самодостаточный полный HTML станет корневым index.html. Активные site-level verification meta tags повторно накладываются на новую сборку до активации и расчёта квоты. В MCP lidfly_request_upload_archive возвращает отдельные команды для Windows (curl.exe) и macOS/Linux (curl), после чего приватный архив передаётся в lidfly_deploy_static_site как archive_token. Обе команды задают Content-Type: application/zip, но серверный binary upload не зависит от наличия или значения заголовка; также поддерживаются публичный zip_url и прямой html. JavaScript может обращаться к внешним API и managed endpoints LidFly.

Полная публикация и маршруты

• ZIP должен содержать корневой index.html. Если он находится внутри единственной папки dist/ или out/, LidFly снимает этот верхний уровень.
• Одиночный HTML должен быть полным UTF-8 документом с <!doctype html> или <html>, иметь размер до 512 КБ и публикуется только по /. Для внешних CSS, JS и изображений используйте абсолютные URL либо ZIP со всеми файлами.
• index.html открывается по /, catalog/index.html — по /catalog, плоский файл cases/example.html — по /cases/example.html.
• Все доступные HTML-URL, кроме технического fallback 404.html, отображаются во вкладке «Страницы» и в lidfly_list_pages.
• Операция всегда заменяет сайт целиком и переводит его в static-режим. Загрузить HTML как отдельную страницу в существующий managed-сайт нельзя; для такой страницы используйте управляемые блоки и page tools.
• Static-страницы доступны только для просмотра. Чтобы изменить файл, исправьте исходный проект и опубликуйте новый ZIP или полный HTML; блоковый редактор и page/template writes к static-артефакту не применяются.
• Новая публикация полностью заменяет текущую сборку. Stale expected_publication_revision возвращает 409; кабинет перечитывает состояние, но не отправляет файл повторно автоматически.
• ZIP по умолчанию — до 100 МБ, распакованная сборка — до 500 МБ и 10 000 файлов в пределах лимитов сайта. Dotfiles, .env, .git, node_modules, symlink, зашифрованные и многотомные архивы не публикуются.

Заявки через POST /api/leads

Для формы используйте относительный URL /api/leads. Сайт определяется только по текущему Host, поэтому один и тот же код работает на *.lidfly.ru и на активном пользовательском домене. Значения site_id, siteId и subdomain из payload не выбирают сайт.

Endpoint принимает JSON и application/x-www-form-urlencoded. Рекомендуемые поля: name, phone, email, message; любые дополнительные поля сохраняются в заявке. Служебные поля атрибуции: _page, _utm_source, _utm_medium, _utm_campaign, _utm_content, _utm_term, _metrika_client_id, _gclid, _yclid.

Метаданные формы передаются в зарезервированных полях _lidfly_form_id и _lidfly_form_name. Если форма действительно получила явное согласие пользователя, передайте _lidfly_consent_accepted=true и версию показанного текста в _lidfly_consent_version; время принятия устанавливает сервер. Эти поля сохраняются отдельно и не дублируются среди пользовательских полей заявки. Не передавайте true только на основании текста под кнопкой без отдельного действия пользователя.

<form id="lead-form">
  <input name="name" required>
  <input name="phone">
  <button type="submit">Отправить</button>
</form>
<p id="lead-status" role="status"></p>

const form = document.querySelector("#lead-form");
const status = document.querySelector("#lead-status");

form.addEventListener("submit", async (event) => {
  event.preventDefault();

  const payload = Object.fromEntries(new FormData(form));
  payload._page = location.pathname + location.search;
  payload._lidfly_form_id = "/#lead-form";
  payload._lidfly_form_name = "Заявка с главной";

  const response = await fetch("/api/leads", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "Accept": "application/json"
    },
    body: JSON.stringify(payload)
  });

  if (!response.ok) {
    const error = await response.json().catch(() => ({}));
    status.textContent = error.error || `Ошибка HTTP ${response.status}`;
    throw new Error(error.error || `HTTP ${response.status}`);
  }

  status.textContent = "Спасибо! Заявка отправлена.";
  form.reset();
});

JSON/fetch-запрос получает 200 {"ok":true}. Обычная HTML-форма после успеха получает безопасный 303 на тот же сайт. OPTIONS возвращает 204. Ошибки: 404 — сайт не найден, 409 — публикация приостановлена, 429 — лимит сайта и IP, 500 — заявка не сохранена.

name каждого input становится названием поля заявки. Владелец сайта отвечает за текст и получение согласия на обработку персональных данных. Экспорт Tilda продолжит отправлять формы в Tilda, пока URL в исходном пользовательском JavaScript не заменён на /api/leads. LidFly не перехватывает формы и не переписывает пользовательский ZIP или HTML автоматически.

Quota, список страниц и ограничения backend

Базовый тарифный блок стоит 490 ₽ за 30 дней и включает 1000 контентных страниц и 3 ГБ файлов. При превышении любого лимита мощность расширяется автоматически и пропорционально: 2 блока — 980 ₽, 2000 страниц и 6 ГБ; 3 блока — 1470 ₽, 3000 страниц и 9 ГБ. Дополнительного списания внутри уже оплаченного периода нет: новая цена применяется при следующем продлении. Write-инструменты страниц, файлов, фавикона, публикации магазина и статического деплоя предупреждают о возможности расширения, а при фактическом переходе на новый блок сообщают capacity_units и следующую регулярную цену прямо в результате записи.

Для managed-сайта quota_pages_count и billable_pages_count считают только контентные страницы. Автоматически созданные карточки товаров, каталог, страницы таксономии, checkout, заказа и кабинета покупателя не расходуют эту квоту, но видны в total_routes_count и generated-счётчиках. Для static-публикации quota считает все HTML-файлы архива, включая 404.html и технические артефакты; total_routes_count показывает публичный inventory без fallback 404.html.

Загруженный ZIP или HTML не запускает Node.js, Python, SSR, базы данных, Next.js API routes или server actions. Серверная динамика доступна только через managed endpoints платформы; актуальный машинный контракт возвращает lidfly_list_managed_endpoints. Legacy POST /lidfly/form/:subdomain остаётся для старых managed-страниц, но новый код должен использовать относительный /api/leads.

У сайта всегда один источник контента: managed для страниц и блоков LidFly, static для неизменяемого артефакта полной публикации из ZIP или HTML, либо аварийный unknown, в котором запись блокируется. Текущие publication_mode и publication_revision возвращаются в DTO сайта и read-инструментах.

Для изменения общей шапки/подвала и storefront-настроек передавайте expected_updated_at и expected_publication_revision из одного read-ответа. Если revision совпала, но timestamp устарел, LidFly возвращает site_updated_at_conflict без изменения файлов и не резервирует новую revision. Перечитайте настройки и сформируйте новую правку; stale write автоматически не повторяется.

Управляемые backend-функции

Сайты LidFly остаются статическими, но могут вызывать серверные функции платформы через fetch. Это даёт интерактивные инструменты без отдельного хостинга, Docker, Python или Node.js на стороне клиента.

ИИ-клиентам доступен read-only инструмент lidfly_list_managed_endpoints: он возвращает актуальные URL, payload, лимиты и CORS. Для Commerce он описывает региональный поиск /api/storefront/:subdomain/search, список/выбор города, одноразовый вход по email, профиль, заказы, адреса, избранное и сравнение. Отдельно остаётся пример анализа текста: POST https://lidfly.ru/lidfly/tools/word-counter/<subdomain>/analyze.

Эта же схема подходит для более полезных сценариев:

• калькулятор стоимости;
• квиз с сохранением заявки;
• генератор КП;
• проверка текста или SEO;
• загрузка файла и анализ;
• подбор товара;
• бронирование;
• поиск по каталогу;
• AI-форма: посетитель пишет запрос, LidFly backend обрабатывает его и возвращает ответ на страницу.

Если для сайта нужна новая backend-функция, напишите в поддержку LidFly и опишите, какие поля отправляет страница и какой результат нужно вернуть. Типовые безопасные функции обычно добавляем в течение дня; сложные интеграции, платежи, внешние API и сценарии с персональными данными сначала отдельно согласуем по безопасности и объёму.

Домены, доступы и роли

Сайт сразу работает на поддомене *.lidfly.ru. Если нужен свой адрес, владелец подключает домен в кабинете: создаёт A-запись на 5.188.119.183, проверяет DNS и сохраняет домен в настройках сайта.

После создания сайта владелец или администратор может выдать бесплатный доступ по email. Если адрес уже зарегистрирован в LidFly, доступ включается сразу; если нет, кабинет предложит отправить приглашение. Это доступ только к одному сайту. «Управление» разрешает страницы, файлы, заявки, магазин, чат и MCP-инструменты выбранного сайта. Для внешнего ИИ используйте URL конкретного сайта https://lidfly.ru/mcp/lidfly/site/<поддомен> и OAuth-вход по email; API-ключ владельца не нужен. «Администрирование» дополнительно разрешает смену шаблона, домен, Метрику, YooKassa и настройки доступа этого сайта. Баланс, команда аккаунта, API-ключи владельца и другие сайты не открываются.

Формы и заявки

Формы можно поставить через cta-banner с showForm: true, lead-magnet или modal-form. Данные формы сохраняются в базу с UTM-метками, страницей, источником, yclid и clientID Метрики, если она включена.

Email-уведомления всегда включены: по умолчанию они идут владельцу сайта. Владелец или администратор может безопасно сменить адрес через lidfly_get_lead_notifications → lidfly_set_lead_notification_email → lidfly_confirm_lead_notification_email, вернуть адрес владельца через lidfly_reset_lead_notification_email и проверить доставку через lidfly_test_lead_notification_email. Получатель является настройкой сайта и никогда не берётся из публичной формы.

• На managed-странице: renderer подключает относительный POST /api/leads, валидацию, отправку без перезагрузки и сообщение об успехе
• На static-сайте: добавьте POST /api/leads в исходный JavaScript и опубликуйте новый ZIP или полный HTML; LidFly не изменяет исходник автоматически
• В ИИ: lidfly_get_leads показывает последние заявки с датой, данными формы и подписанными полями UTM/yclid
• В личном кабинете: вкладка «Заявки» показывает таблицу, фильтры, пагинацию, удаление и экспорт CSV
• На своём домене: публичный приём заявок определяет сайт по Host, поэтому формы работают и на *.lidfly.ru, и на подключённом домене

Доставка в Bitrix24

ИИ клиента сначала читает lidfly_get_site_integrations и lidfly_get_bitrix24_integration. Структурированные capability_details различают available, disabled, conditional и unsupported и являются источником истины. Webhook вводится только в авторизованном кабинете LidFly: не отправляйте webhook, секрет или токен в чат.

Текст согласия и URL политики для управляемых форм, Bitrix24 и Commerce разрешаются общей managed-политикой. Изменение через ИИ выполняется только парой lidfly_preview_bitrix24_privacy_policy → lidfly_apply_bitrix24_privacy_policy: apply проверяет хеш конфигурации и обе ревизии, поэтому параллельная перенастройка CRM или новая публикация блокирует устаревшую запись. Commerce может наследовать URL сайта или использовать свой HTTPS URL; публичный checkout и приём заявки проверяют именно эффективное значение и fail closed при недоступной managed-странице политики.

CRM-настройки наследуются как default → scenario → exact form; Commerce использует default → system_event:commerce.manager_request. SOURCE_ID и ответственный из существующих настроек являются default для всех новых CRM-заявок без override. Managed-шаблоны содержат только семантические ключи callback, general_request и product_request, без Bitrix ID.

Каждое изменение создаёт immutable profile version. Новая заявка фиксирует effective profile и revisions при приёме. Поэтому обычный retry не меняет payload после перенастройки CRM; переход failed delivery на текущий профиль выполняется отдельным подтверждаемым rebind-and-retry с сохранением исходной попытки в аудите. lidfly_preview_crm_delivery_plan использует ту же projection-функцию, что worker.

Для стандартных managed-форм совместимые инструменты общего и индивидуального mapping сохранены. Одинаковая форма общего шаблона показывается один раз; конфликт разных definitions под одним form_key блокирует exact binding. Mapping preview/apply, delivery-plan preview и назначение exact form profile проверяют один и тот же полный form_ref v2. При изменении версии публикации или любой координаты операция отвечает 409 и требует заново вызвать lidfly_list_lead_forms; запись автоматически не повторяется. Custom HTML и static-публикации без стабильного ключа используют default profile.

Поля utm_source, utm_medium, utm_campaign, utm_content и utm_term передаются в штатные поля Bitrix24 автоматически и не требуют ручного сопоставления. Их нельзя переопределить mapping, но любой UTM-источник можно дополнительно сопоставить с отдельным пользовательским полем CRM. Системное поле opened LidFly не сохраняет и не отправляет: доступность лида задаётся настройками Bitrix24.

Классификация использует только стабильные API ID, а не локализованные подписи. Неизвестное обязательное поле остаётся строгой пользовательской целью: отсутствие mapping блокирует сохранение с required_mapping_missing, а неподдерживаемый тип — с required_field_unsupported. Кабинет, REST API и инструменты ИИ используют одну проверку.

ИИ-клиент получает исполняемый next_safe_call_detail с точным инструментом и аргументами. Ошибки интеграций содержат безопасные code, retryable, retry_after_seconds и при внутреннем сбое support_id; stack, webhook и provider payload пользователю не возвращаются.

Владелец или администратор может отдельно включить создание Лидов из обычных форм, создание Лидов из Commerce-заявок менеджеру и передачу пути клиента. Все три возможности выключены по умолчанию на уровне сайта. Заявка менеджеру остаётся неквалифицированным обращением: LidFly создаёт только Лид и не создаёт Контакт, Компанию, Сделку или товарные позиции Bitrix24.

Managed-публикация атомарно создаёт revision-bound CRM manifest v2 со всеми формами, сценариями, полями, routes, stored-block provenance, fingerprints и checksum. Поэтому поле на поздней странице доступно без сканирования сотен файлов. Старая managed-публикация без актуального manifest и static/custom сайт честно возвращают complete=false; republish или безопасный manifest backfill создаёт актуальный derived artifact без перерендера HTML.

Managed runtime защищает обычные формы от сетевых дублей: UUID одной попытки сохраняется после timeout/5xx, а сервер атомарно создаёт один lead и outbox. Повтор тех же данных возвращает исходную заявку; тот же UUID с другим payload получает 409 idempotency_conflict. Старый custom runtime без UUID продолжает работать без этой гарантии.

Для заявки менеджеру Лид получает серверно сформированную корзину, контакты, комментарий, URL страницы, UTM, gclid, yclid, ClientID Метрики и снимки согласий. Создавать пользовательские поля Bitrix24 не требуется: источник и ID заказа передаются через стандартную пару originatorId=LIDFLY и originId=order:<ID заказа>. Необязательные UF-поля можно настроить только для дополнительного дублирования этих значений. Повтор checkout с тем же ключом идемпотентности не создаёт вторую CRM-задачу.

Путь клиента доставляется отдельно после создания Лида. Безопасный режим по умолчанию — «после отдельного согласия»: единый runtime работает на всех заново опубликованных управляемых страницах, показывает посетителю один site-wide запрос, хранит принятое или отклонённое решение для следующих страниц и повторно спрашивает при смене версии текста согласия. После принятия tracker загружается сразу на текущей странице; обычные формы и Commerce используют то же решение. Режим «сразу после загрузки» требует явного административного подтверждения правового основания. Заблокированный tracker не мешает отправить форму или оформить заявку: статус Лида и статус пути клиента отображаются независимо. Старые управляемые страницы нужно один раз перепубликовать; статические ZIP/HTML LidFly автоматически не переписывает.

Аналитика

Каждая страница, созданная через LidFly-блоки, автоматически отправляет данные о просмотре: страница, реферер и UTM-параметры. Статистика доступна в кабинете и через lidfly_get_stats.

• Просмотры — общее количество загрузок страницы
• Уникальные посетители — дедупликация по IP + User-Agent
• Заявки — количество отправленных форм
• Конверсия — заявки / уники × 100%
• Яндекс Метрика — счётчик по номеру и цели lidfly_lead_submit, lidfly_order_created, lidfly_purchase_paid; Webvisor и ecommerce остаются в стандартной конфигурации

На управляемых страницах очередь ym и команда init создаются сразу, но внешний https://mc.yandex.ru/metrika/tag.js не входит в начальную загрузку. LidFly загружает его один раз при первом касании, нажатии клавиши, прокрутке, отправке формы или начале checkout, а если взаимодействия нет — через 4 секунды после события window.load. Получение Client ID и отправка цели также запускают загрузку, но форма, заказ, оплата и переход не ждут ответа Яндекса.

Оптимизация применяется автоматически при публикации и не требует отдельной настройки. Она относится только к страницам, которыми управляет renderer LidFly: загруженный владельцем статический HTML или ZIP платформа не переписывает. Для короткого визита, завершившегося до взаимодействия и до fallback-таймера, Метрика может не успеть загрузиться — это осознанный компромисс ради чистого начального waterfall.

Спросите ИИ: «Покажи статистику моих лендингов за последнюю неделю» — он вызовет lidfly_get_stats с days: 7.