От сайта к бизнес-платформе: как меняются конструкторы в 2026 году

Еще несколько лет назад от конструктора сайтов требовался вполне понятный набор вещей. Шаблоны, визуальный редактор, формы, домен, интернет-магазин, базовая аналитика. Собрал страницы, подключил оплату, опубликовал – и задача решена.

В 2026 году это описание подходит все хуже.

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

Получается примерно такая эволюция:

сайт > магазин > CRM > автоматизация > серверная логика > AI

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

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

Сначала – о том, что происходит в Рунете.

Один из самых показательных примеров этого года – Яндекс KIT. В июле платформа получила открытый API. Через него продавец может связать магазин с внешними системами, обмениваться данными и строить собственные сценарии автоматизации. Сам по себе API в 2026 году никого не удивляет. Гораздо интереснее стало через месяц.

21 августа Яндекс объявил о новом сценарии: продавцы без собственного интернет-магазина могут подключиться к продажам через Поиск и Алису AI. Пользователь находит товар, выбирает предложение и оформляет заказ через универсальный чекаут Яндекса. Ассортимент, цены, оплату и доставку продавец настраивает через сервисы Яндекса и KIT. Пока функция работает в бета-режиме.

Раньше стандартный путь выглядел примерно так:

Поиск > сайт магазина > карточка товара > корзина > оплата

Теперь появляется еще один вариант:

Поиск / Алиса > товар > оформление заказа > доставка

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

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

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

Поэтому KIT постепенно становится интереснее рассматривать не как еще один конструктор интернет-магазинов, а как слой торговой инфраструктуры Яндекса.

У uCoz движение идет в другую сторону. Платформа исторически была большой модульной CMS: магазин, каталог, форум, блог, пользователи, шаблоны и десятки других функций жили внутри одной системы. В 2026 году к этой архитектуре начали добавлять программируемый слой.

В начале лета появился доступ для AI-агентов через MCP и набор специализированных навыков. Затем расширился API. К августу через него можно было работать уже не только с материалами сайта, но и с разделами, настройками ряда модулей, правами групп пользователей, шаблонами, тарифами, подписками и платежами. Это хорошо видно в августовском обновлении uAPI и MCP.

Но самый интересный релиз был позже. В июле uCoz вывел из закрытого тестирования Server Scripts. Рядом с сайтом теперь можно запускать собственный код на PHP 8, Node.js и Python, создавать базы MySQL, использовать Cron и FTP. Через эту среду можно делать API-сервисы, ботов, фоновые задачи, интеграции, обработку данных и отдельные веб-приложения. Серверное приложение при этом может обмениваться данными с сайтом через uAPI.

Для обычного конструктора это довольно существенная смена границ.

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

Здесь модель становится другой:

готовая CMS + собственный код + API + AI

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

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

AI-инструменты заметно упростили создание простых сайтов, поэтому конкурировать только удобством сборки страницы становится все сложнее. Платформам приходится давать пользователю больше возможностей уже после создания сайта. uCoz как раз идет по этому пути.

У Tilda почти противоположная стратегия. Здесь никто не пытается превратить платформу в универсальную серверную среду. Вместо этого Tilda постепенно расширяет то, что происходит вокруг обычного сайта.

Летом появились CMS Потоки 2.0. Теперь можно задавать собственную структуру записей, шаблоны и поля и на этой базе собирать большие однотипные разделы: услуги, вакансии, мероприятия, каталоги, медиа и другие проекты.

Одновременно Tilda CRM получила более полноценную работу с заказами интернет-магазина: изменение состава и статуса заказа, управление оплатой, данные покупателя. Затем появился отдельный раздел с задачами, сроками, ответственными, приоритетами, чек-листами и канбан-доской. Задачу можно привязать к конкретной заявке из CRM.

Получается вполне понятная цепочка:

страница > сайт > CMS > магазин > CRM > задачи

И в этой последовательности хорошо виден продуктовый расчет. Малому бизнесу неудобно собирать систему из нескольких разных сервисов. Сайт в одном месте, заявки в другом, CRM в третьем, задачи в четвертом, товары еще где-то.

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

AI у Tilda пока вписывается в ту же модель. Vibe Block позволяет создавать и дорабатывать блоки с помощью запроса, прикладывать PDF, TXT, CSS и видео как дополнительный контекст. Но AI остается инструментом внутри привычного процесса работы с сайтом, а не самостоятельным управляющим всей системой.

Поэтому Tilda сейчас интереснее не как пример «AI-конструктора», а как пример расширения конструктора вокруг повседневных задач бизнеса.

Если Tilda идет от сайта к CRM и задачам, то Битрикс24 давно находится на другом конце этого маршрута.

У него уже есть CRM, сделки, задачи, коммуникации, документы и автоматизация. Сайты для Битрикс24 – лишь один из компонентов большой системы. Теперь к этому набору добавляется еще один слой.

В августе компания представила «Коворк/Код». Его позиционируют не как очередного помощника, который расскажет, что делать, а как AI-исполнителя. Пользователь ставит задачу, а агент может работать с данными, проверять сделки, собирать отчет, делать дашборд или создавать приложение.

Если упростить развитие подобных инструментов, получается:

генерировать > советовать > выполнять

И именно последний этап сейчас интереснее всего.

Когда AI пишет текст для страницы, цена ошибки невелика: человек перечитал и исправил.

Когда AI получает доступ к CRM, заказам, отчетам или автоматизации, вопрос становится совсем другим: что именно ему разрешено делать от имени бизнеса?

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

Tilda движется так: сайт > CRM > задачи

Битрикс24 так: CRM > сайты > AI-исполнители

Где между ними должна проходить граница категории через несколько лет, уже не так очевидно.

Западные платформы существуют сейчас в другой рыночной реальности, поэтому дальше речь не о том, чем заменить Tilda или uCoz. Интересны сами продуктовые решения.

Wix много лет был почти синонимом классического конструктора: открыл редактор, собрал страницы, подключил магазин или бронирование. Летом компания сделала несколько шагов, которые заметно меняют эту модель.

Wix Harmony появился внутри Microsoft 365 Copilot: сайт можно создать из диалога и там же получить доступ к части бизнес-функций. Похожая интеграция в августе появилась с Gemini.

Еще интереснее Wix Headless. Внешний AI-инструмент вроде Claude Code или Codex может заниматься интерфейсом, а Wix предоставляет готовую бизнес-часть: CMS, интернет-магазин, платежи, бронирования, CRM, аналитику, хостинг и безопасность.

Логика довольно прозрачная:

редактор сайта > бизнес-инфраструктура для разных интерфейсов

А в августе Wix пошел еще дальше и запустил Symphony – отдельную систему AI-агентов для малого бизнеса, уже не привязанную к редактору сайта. То есть компания сама постепенно выходит за рамки категории, на которой выросла.

Shopify двигается в похожем направлении, но вокруг торговли. В июне компания открыла инфраструктуру для торговли через AI-агентов всем разработчикам. Catalog API дает доступ к структурированному каталогу товаров, а Universal Commerce Protocol описывает путь от поиска товара до оформления покупки.

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

Это не российский сценарий и не альтернатива Яндекс KIT. Но продуктовый принцип похож: торговая инфраструктура начинает отделяться от конкретной витрины.

Framer показывает другую сторону процесса. В июне вышел Framer 3.0 с Agents. AI работает непосредственно внутри редактора: может создавать страницы и компоненты, менять адаптивность, писать код, подключаться к CMS и работать с аналитикой сайта. Одновременно появился механизм веток, чтобы экспериментировать отдельно от основной версии проекта.

Это уже заметно отличается от привычного «сгенерируй мне текст для первого экрана». AI становится вторым оператором редактора.

Webflow интересен следующим этапом этой истории. В MCP 2.0 AI-агенты получили возможность менять элементы, компоненты, стили и переменные без открытого редактора, работать с аналитикой и другими сущностями проекта.

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

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

Как только AI получает право что-то менять сам, ему нужно получить ответы вопросы:

что ему разрешено > что он уже сделал > как это отменить

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

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

Российским сервисам приходится учитывать местные платежи, доставку, CRM, требования к данным, доступные каналы продвижения и крупные локальные экосистемы.

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

На практике из всего этого я бы сделал несколько выводов.

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

Имеет смысл заранее смотреть, что находится вокруг редактора:

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

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

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

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

Это контролируемый канал, собственный контент, поисковый трафик, бренд и возможность не зависеть полностью от правил одной площадки.

Скорее меняется его роль. Раньше сайт пытались сделать местом, куда обязательно должен прийти каждый клиент. Теперь он может быть одним из нескольких интерфейсов бизнеса.

Для владельца небольшого бизнеса слово API долгое время означало примерно «что-то техническое, что понадобится программисту».

С AI ситуация меняется. Чем больше действий платформы доступны программно, тем больше из них потенциально сможет использовать агент или автоматизация.

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

Пока AI пишет заголовки, легко смотреть только на качество результата. Когда он начинает менять сайт, работать с заказами или CRM, критерии другие.

Нужно понимать:

То есть полезность AI растет вместе с количеством доступных ему действий. И примерно с той же скоростью растет цена ошибки.

Похоже, сама категория «конструктор сайтов» постепенно становится слишком узкой. С ней все сильнее пересекаются CMS, CRM, платформы электронной торговли, хостинги, AI-инструменты и крупные экосистемы. А традиционные конструкторы в ответ добавляют бизнес-функции, API, автоматизацию и собственную серверную логику.

В итоге все чаще пересекаются вещи, которые раньше продавались как отдельные продукты:

сайт > CMS > магазин > CRM > автоматизация > AI

Поэтому при выборе платформы вопрос постепенно меняется.

Раньше было достаточно спросить: «Где мне проще сделать сайт?» Теперь полезнее добавить второй вопрос: «Какую часть моего бизнеса эта платформа сможет обслуживать через два-три года?» И, судя по обновлениям текущего года, именно за ответ на этот вопрос конструкторы начинают конкурировать все активнее.