Что такое веб-приложение и чем оно отличается от сайта

Веб-приложение — это программа, которая работает в браузере: её не нужно устанавливать, она открывается по ссылке, но, в отличие от обычного сайта, не просто показывает страницы, а выполняет действия с данными пользователя. Вы входите под своим логином, что-то создаёте, меняете, считаете — и результат сохраняется на сервере. Почта, онлайн-банк, личный кабинет покупателя, CRM, Яндекс Документы — всё это веб-приложения.

Разобраться в разнице важно не ради терминов. От ответа на вопрос «сайт или приложение» зависят стек, команда, бюджет, сроки и то, как проект будет продвигаться в поиске. Ниже — определение простыми словами, признаки, по которым веб-приложение отличается от сайта, устройство «под капотом» и сценарии, когда бизнесу нужно одно, а когда другое.

Что такое веб-приложение простыми словами

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

Технически веб-приложение — клиент-серверная программа. Интерфейс отрисовывается в браузере, а логика и данные живут на сервере. Поэтому одно и то же приложение одинаково работает на Windows, macOS, Android и iOS, обновляется у всех пользователей сразу и не требует публикации в магазинах приложений.

Чем веб-приложение отличается от сайта

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

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

Признаки веб-приложения

• Бизнес-логика. Система что-то вычисляет и принимает решения по правилам: стоимость с учётом скидок и регионов, доступность слотов, лимиты, маршруты согласования.
• Состояние. Действия пользователя меняют данные, и эти изменения сохраняются: черновик заявки, корзина, статус задачи, история операций.
• Личные данные пользователя. У каждого свой набор записей: заказы, документы, баланс, настройки.
• Авторизация и роли. Вход по логину, коду из СМС или через VK ID и Яндекс ID; разные права у клиента, менеджера, бухгалтера и администратора.
• Работа с данными. Поиск, фильтры, сортировки, выгрузки, отчёты, импорт из 1С и таблиц.
• Интерактив. Интерфейс реагирует без перезагрузки страницы: перетаскивание карточек, автосохранение, уведомления в реальном времени.

Если в вашем проекте есть три-четыре признака из шести, вы проектируете веб-приложение, даже если заказчик называет его «сайтом с личным кабинетом». От этого зависит оценка: такой проект считают по сценариям и логике, а не по количеству страниц.

Сайт, веб-приложение, мобильное приложение и PWA: сравнение

Рядом с веб-приложением часто стоят ещё два понятия — мобильное приложение и PWA. Вот как они соотносятся:

Подробнее о прогрессивных приложениях, их ограничениях на iOS и публикации в магазинах — в статье что такое PWA-приложение. Выбор между нативным приложением и мобильной версией разобран отдельно — здесь на нём не останавливаемся.

Примеры веб-приложений: от калькулятора до онлайн-банка

Веб-приложения окружают нас повсюду, просто их редко так называют:

• Личный кабинет клиента — заявки, договоры, счета, статусы, закрывающие документы в одном окне. Самый частый заказ от сервисных и B2B-компаний.
• CRM и внутренние системы — сделки, задачи, склад, учёт производства. Битрикс24 и amoCRM — готовые веб-приложения, которые компания арендует по подписке.
• Онлайн-банк — веб-версии банков, где вы видите счета, переводите деньги, скачиваете выписки. Классика жанра: жёсткая авторизация, роли, журнал операций.
• Яндекс Документы и Яндекс Почта — редактор текстов и таблиц с совместной работой в реальном времени и почтовый клиент, которые целиком работают в браузере.
• Сервис бронирования — запись в клинику, автосервис, салон: расписание специалистов, свободные слоты, подтверждение, напоминания.
• Калькулятор стоимости на сайте — маленькое веб-приложение внутри обычного сайта: расчёт по формулам, сохранение сметы, отправка в CRM.
• B2B-портал для дилеров — индивидуальные прайсы, остатки из 1С, заказы и отгрузки.

Отдельный класс — веб-сервисы по подписке (SaaS): это те же веб-приложения, только продаваемые многим компаниям сразу. О том, когда выгоднее арендовать такой сервис, а когда писать свой, — в статье что такое SaaS простыми словами.

Как устроено веб-приложение: фронтенд, бэкенд, API и база данных

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

1. Фронтенд — то, что видит пользователь в браузере: экраны, формы, таблицы, кнопки. Пишется на JavaScript и TypeScript с фреймворками React, Next.js или Vue.
2. Бэкенд — серверная часть с бизнес-логикой: проверяет права, считает, сохраняет, отправляет уведомления. Типичные технологии — Node.js, Python с Django, PHP с Laravel.
3. API — договорённость о том, как фронтенд и сторонние системы обмениваются данными с бэкендом. Через API подключаются 1С, ЮKassa, СДЭК, amoCRM и мобильное приложение.
4. База данных — где хранятся пользователи, заказы, документы. Для бизнес-приложений чаще всего выбирают PostgreSQL.

SPA и SSR: два способа отрисовать интерфейс

SPA (одностраничное приложение) загружает оболочку один раз, а дальше подгружает только данные: переходы мгновенные, интерфейс ощущается как программа на компьютере. Минус — пока JavaScript не выполнится, в HTML почти пусто. SSR (серверный рендеринг) отдаёт браузеру уже готовую страницу с содержимым, а интерактивность «оживает» поверх неё. Next.js умеет оба режима и статическую генерацию (SSG), поэтому его часто выбирают, когда у приложения есть публичная часть.

Какой стек выбирают под задачу

Стек подбирают под задачу, а не под привычки команды. Публичная часть, которой важен поиск, — Next.js. Логика вокруг данных и машинного обучения — Python и Django. Большинство кабинетов и сервисов — React и Node.js. Если у компании уже есть PHP-разработчики и проект на Laravel или Yii, разумно продолжать на нём.

SEO и веб-приложения: как индексируются SPA

Это главный источник разочарований. Кабинет за логином поисковик не видит и видеть не должен — индексируется только публичная часть: главная, описание сервиса, тарифы, справка, каталог. Но если и эта часть сделана как чистая SPA, робот получает почти пустой HTML.

Google обычно дорендеривает такие страницы, хотя и с задержкой. Яндекс тоже умеет выполнять JavaScript, но с индексацией SPA в нём возможны проблемы: страница может попасть в индекс без текста или с неверным заголовком. Надёжное решение — отдавать публичные страницы через SSR или SSG, а SPA-режим оставить для кабинета.

Безопасность и 152-ФЗ: что меняется, когда вы храните данные клиентов

Как только в приложении появляются учётные записи, телефоны, адреса и история заказов, компания становится оператором персональных данных со всеми обязанностями по 152-ФЗ. Для сайта-визитки это одна форма заявки, для веб-приложения — целая база, поэтому требования серьёзнее.

• Локализация. По ч. 5 ст. 18 152-ФЗ запись, хранение и обработка персональных данных граждан РФ должны вестись в базах на территории России, а с 1 июля 2025 года использовать для этого зарубежные базы прямо запрещено. Сервер с базой приложения — в российском дата-центре.
• Уведомление Роскомнадзора об обработке персональных данных и опубликованная политика обработки.
• Согласие на обработку — с 1 сентября 2025 года оформляется отдельно от других документов (156-ФЗ), а не строчкой в оферте.
• Штрафы. За нарушение локализации для юрлица — от 1 до 6 млн ₽, за повторное — от 6 до 18 млн ₽ (ч. 8 и 9 ст. 13.11 КоАП). С 30 мая 2025 года (420-ФЗ) действуют отдельные штрафы за утечки, а за повторную утечку — оборотные.

Технический минимум безопасности для веб-приложения: проверка прав на сервере для каждого запроса (а не только скрытие кнопок в интерфейсе), защита от SQL-инъекций и XSS, хранение паролей в виде хешей, журнал действий пользователей, резервные копии и отдельные окружения для разработки и боевого сервера.

Когда бизнесу нужен сайт, а когда веб-приложение

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

Хватит сайта

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

Нужно веб-приложение

• Клиенты регулярно спрашивают статус заказа, просят документы и копии счетов — это работа для личного кабинета.
• Дилерам нужны персональные прайсы, остатки и заказы из 1С в режиме онлайн.
• Сотрудники ведут процесс в Excel и мессенджерах, данные теряются и дублируются.
• Вы продаёте доступ к сервису, а не услугу — это продукт, то есть приложение по определению.

Если нужна именно программная логика — роли, расчёты, статусы, интеграции, — ищите подрядчика с опытом разработки веб-приложений, а не только сайтов на шаблонах: оценка, команда и процесс там устроены иначе. Для контентного проекта, наоборот, лучше подойдёт обычная разработка сайта на CMS.

По деньгам ориентир — от 900 000 ₽ за веб-приложение. По срокам: MVP и простой личный кабинет — от 1,5 месяцев, сервис средней сложности — 2–5 месяцев, нагруженная система — от 6 месяцев. Цифры зависят от числа ролей, сценариев и интеграций. Подробная раскладка по типам проектов — в статье о стоимости разработки веб-сервиса.

Типичные ошибки при выборе между сайтом и веб-приложением

1. Писать CRM с нуля, когда хватит Битрикс24 или amoCRM. Если процесс продаж стандартный, коробка с настройкой и интеграциями закроет задачу быстрее и дешевле. Своя система оправдана, когда воронка нестандартная, упираетесь в лимиты или данные должны храниться строго на своём сервере — подробнее об этом на странице разработки CRM на заказ.
2. SPA для контентного сайта. Выглядит современно, а в итоге — проблемы с индексацией, долгая первая загрузка и дорогая доработка.
3. Оценивать приложение по количеству страниц. Десять экранов кабинета с ролями и интеграцией с 1С стоят дороже, чем сайт на сто страниц. Считать нужно сценарии и правила.
4. Строить всё сразу. Первый релиз должен закрывать один-два ключевых сценария, остальное — после обратной связи пользователей.
5. Отложить безопасность и 152-ФЗ на потом. Переносить базу в российский дата-центр и переписывать проверку прав после запуска дороже, чем заложить это в архитектуру.
6. Не договориться о коде. Исходный код, доступы к серверу и базе должны принадлежать заказчику — иначе любая доработка зависит от одного подрядчика.

Чек-лист: нужно ли вам веб-приложение

Отметьте пункты, которые про ваш проект. Три и больше — вы проектируете веб-приложение, и оценивать его нужно соответственно.

• Пользователи входят под своим логином и видят только свои данные.
• Есть хотя бы две роли с разными правами: клиент и менеджер, дилер и администратор.
• Система что-то считает по правилам: цены, скидки, сроки, остатки.
• У объектов есть статусы, которые меняются по ходу процесса.
• Нужен обмен данными с 1С, оплатой, доставкой или CRM.
• Пользователи возвращаются регулярно, а не заходят один раз за информацией.
• Вы храните персональные данные клиентов и готовы выполнять требования 152-ФЗ.
• Готовая коробка или SaaS не ложится на ваш процесс без серьёзных костылей.

Итог

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