Webflow или WordPress: 5 реальных кейсов из практики
Почему этот вопрос всплывает на каждом первом звонке
Почти каждый созвон по проекту в итоге сводится к одному и тому же вопросу: «Так что, Webflow или WordPress?» Клиенты спрашивают это так, будто просят меня определить победителя в боксёрском поединке. Я их понимаю — они прочитали десяток сравнительных статей, посмотрели пару видео на YouTube и теперь хотят чёткий ответ до подписания договора. Но после восьми лет работы на обеих платформах я могу честно сказать: правильный ответ почти никогда не звучит как «Webflow лучше» или «WordPress лучше». Правильный ответ — «лучше для чего конкретно, и кто будет трогать этот сайт после того, как я закончу проект?»
Выбор платформы — это на самом деле не дизайнерское решение. Это операционное решение, замаскированное под дизайнерское. Кто будет обновлять контент? С какой скоростью работает команда? Какой бюджет заложен на хостинг и плагины против ежемесячной подписки на Webflow? Есть ли уже маркетинговая команда с налаженным процессом, или это соло-основатель, который сам будет редактировать текст на главной странице в 11 вечера перед звонком с инвесторами?
Я перестал отвечать на этот вопрос абстрактно. Вместо этого я разбираю, что реально произошло на конкретных проектах — как удачные результаты, так и те случаи, где я ошибся с выбором и потом отрабатывал часы, чтобы это исправить. Ниже — пять сценариев прямо из моей практики за последние несколько лет. Имена и детали, по которым можно узнать клиентов, изменены, но ситуации, ограничения и ошибки — реальные. Если вы сейчас смотрите на этот же выбор, скорее всего, один из этих пяти сценариев покажется вам знакомым.
Сценарий 1: агентство, которому нужен готовый к запуску сайт за 12 дней
Небольшое брендинговое агентство наняло меня, чтобы переделать их собственный маркетинговый сайт. Они только что переопределили свою позицию после потери крупного клиента на постоянном обслуживании и хотели запустить новый сайт до конференции, на которой должны выступать трое их партнёров. Двенадцать рабочих дней от старта до запуска. Никакой сложности с управлением контентом — пять страниц, сетка кейсов, блог, который они планировали обновлять раз в месяц, и форма для связи.
Это учебниковый сценарий для Webflow, и я хочу объяснить именно почему, потому что причины важнее вывода.
Во-первых, полностью исчезает этап передачи дизайна в разработку. В проекте на WordPress, даже простом, всегда есть шаг перевода: я делаю дизайн в Figma, а потом я сам или разработчик пересобирает этот дизайн в тему, шаблоны и кастомные поля. Каждую анимацию, каждый hover-эффект, каждую нестандартную сетку нужно заново реализовать в PHP и CSS, и в этом переводе что-то обязательно теряется или упрощается — тайминг перехода, который отлично смотрелся в прототипе, в итоге становится «примерно похожим», потому что ни у кого нет времени возиться с 200 миллисекундами ease-in-out во вторник перед запуском.
С Webflow я проектировал и собирал сайт одновременно. Hover-эффекты, появление элементов при скролле в сетке кейсов, кастомный курсор в hero-блоке — всё это я делал прямо в Webflow Designer, тестировал в браузере в реальном времени, и никакой передачи между этапами не было вообще. Что видел на канвасе, то и уходило в продакшен. При таймлайне в 12 дней исключение целого раунда разработки и QA против статичного дизайн-файла — это разница между «успели» и «не успели».
Во-вторых, хостинг и инфраструктура вообще не были проблемой. Мне не нужно было думать о staging-сервере, SSL-сертификатах, бэкапах базы данных или о том, какой managed WordPress-хостинг обеспечит нормальный uptime при всплеске трафика от конференции. Я опубликовал сайт, подключил их существующий домен и вернулся к настоящей дизайнерской работе. При спринте на 12 дней каждый час, не потраченный на DevOps, — это час, потраченный на то, за что клиент реально платит.
В-третьих — и это то, что люди обычно недооценивают, — команда самого агентства собиралась дальше обновлять сайт своими силами, и никто из них не был разработчиком. Это были дизайнеры и стратеги, которые понимали визуальную иерархию и умели читать файл Figma, но не имели ни малейшего желания разбираться в панели WordPress, конструкторах страниц или устройстве кастомных полей. Editor-режим Webflow позволил мне передать сайт так, что нетехнический человек мог заменить картинку в кейсе, отредактировать заголовок или добавить карточку нового сотрудника без риска что-то сломать в макете. Я провёл 45-минутный обучающий звонок — и это была вся передача знаний.
Сайт запустился на 11-й день. Единственное, о чём я скажу честно: встроенная блог-CMS в Webflow вполне годится для пяти постов в месяц, но начинает казаться скудной, когда нужны серьёзные редакционные процессы — об этом больше в сценарии два. Для этого агентства это ограничение вообще не имело значения. Им нужны были скорость, визуальная точность и сайт, который клиент может редактировать сам, без обслуживания сервера. Webflow дал им всё три без единого компромисса.
Сценарий 2: издатель контента с тремя редакторами и ежедневным графиком публикаций
Этот сценарий — полная зеркальная противоположность, и именно этот проект окончательно вылечил меня от любого инстинкта «Webflow для всего», если он у меня и был.
Клиент вёл нишевой B2B-медиасайт — ежедневные статьи, еженедельная подборка для рассылки, собранная из размеченных тегами материалов, гостевые авторские аккаунты и редакционный календарь с тремя людьми, которые публиковались независимо друг от друга, часто по несколько раз в день. Они пришли ко мне с запросом на редизайн, и их изначальным инстинктом был Webflow, потому что они видели, какими чистыми выглядят сайты на Webflow, а их старый сайт на WordPress казался захламлённым и медленным. Проблема была не в WordPress. Проблема была в пяти годах накопленных плагинов и теме, которую уже никто не понимал.
Перед тем как окончательно выбрать платформу, я провёл короткий аудит, и несколько вещей стали очевидны сразу. Им нужны были ролевые права доступа — редакторы, которые могут публиковать, авторы, которые могут только отправлять материалы на проверку, и администратор, который одобряет всё перед публикацией. Им нужен был по-настоящему быстрый процесс ввода контента, потому что их редакторы писали статьи по 800–1200 слов ежедневно и нуждались в богатом форматировании, встроенных твитах, инлайн-изображениях и цитатах-выносках без борьбы с интерфейсом CMS. Им нужны были категории, теги и таксономия, способная поддерживать систему «похожих материалов» и внутренний поиск, который действительно понимает структуру их контента. И им нужно было, чтобы всё это стабильно работало, когда каталог вырастет за пределы нескольких тысяч статей.
CMS в Webflow действительно хороша для структурированного контента — кейсов, биографий команды, списков товаров, портфолио. Но она никогда не создавалась как инструмент для редакции. В ней нет встроенного процесса «автор → рецензия» с той степенью гранулярности, которая нужна была этой команде. Редактирование богатого текста в полях CMS Webflow — рабочее, но заметно более ограниченное, чем блочный редактор WordPress, когда речь идёт о ежедневном лонгриде. А при их объёме лимиты на количество элементов CMS и ограничения коллекций на тарифах Webflow вынудили бы их постоянно повышать тариф или строить обходную архитектуру — разбивать контент по нескольким коллекциям так, что логику «похожих материалов» стало бы адом поддерживать.
Поэтому я порекомендовал WordPress, но не тот запутанный вариант, который они унаследовали. Я пересобрал всё на чистой, современной блочной теме, урезал список плагинов с примерно 40 до одиннадцати, которые реально оправдывали своё существование, и правильно настроил редакционные роли, используя встроенную систему ролей пользователей WordPress, расширенную лёгким плагином для редакционного процесса. Сначала я, честно говоря, спроектировал реальную визуальную систему в Figma — и именно отсюда обычно и берётся ощущение, что «WordPress выглядит хуже». Большинство устаревших на вид сайтов на WordPress выглядят устаревшими не из-за WordPress; они выглядят так, потому что перед сборкой темы никто не занимался настоящим дизайном. Я собрал кастомную блочную тему с правильной типографикой, отступами и библиотекой компонентов в редакторе Gutenberg, чтобы у их авторов прямо в интерфейсе написания были фирменные, соответствующие дизайну блоки — цитаты-выноски, подписи авторов, призывы подписаться на рассылку — без необходимости привлекать разработчика каждый раз, когда им хотелось немного другой раскладки.
В итоге сайт загружался быстрее и выглядел чище, чем старый, стабильно работал на хостинге среднего уровня для managed WordPress и давал редакционной команде именно тот процесс публикации, который им был нужен. Их месячные расходы на хостинг оказались меньше, чем стоило бы одно место на тарифе Webflow CMS, и всё это масштабировалось за пределы десяти тысяч статей без того, чтобы мне пришлось снова трогать архитектуру. Это тот сценарий, где WordPress — не компромиссный выбор, а правильное инженерное решение, и Webflow был бы неправильным инструментом, каким бы красивым ни могли получиться маркетинговые страницы.
Сценарий 3: основатель интернет-магазина на самофинансировании с бюджетом $40 в месяц
Соло-основательница обратилась ко мне с желанием запустить небольшую линейку косметики для кожи прямого потребления (D2C) — около 15 товаров на старте, планы постепенно расширять каталог, работа на собственные сбережения без внешнего финансирования. Бюджет был главной темой всего разговора. Она уже потратила деньги на пробную версию Shopify и чувствовала, что комиссии за транзакции и стоимость приложений съедят её маржу ещё до продажи первой бутылочки.
Это сценарий, в котором я реально возразил и против Webflow, и против платформы, которую она изначально себе представляла, и здесь стоит пройтись по цифрам, потому что это применимо к очень многим начинающим основателям.
Тарифы Webflow для e-commerce выглядят аккуратно, и оформление заказа действительно приятное, но структура цен включает и ежемесячную плату за платформу, и комиссию за транзакции сверху, а более продвинутая обработка инвентаря и вариантов товара, которая ей была нужна — разные размеры, наборы, опции подписки в перспективе — толкала её на более высокий тариф, чем базовый план для e-commerce. Когда я посчитал реальные цифры относительно её прогнозируемого объёма заказов, e-commerce на Webflow обходился заметно дороже в месяц, чем она готова была потратить, не имея ещё доказанного спроса.
Вместо этого я собрал ей сайт на WordPress с WooCommerce, на скромном, но надёжном хостинге, используя лёгкую кастомную тему, а не раздутую готовую тему для WooCommerce (это важно — большинство жалоб на «медленный e-commerce на WordPress», которые я вижу, на самом деле связаны с темой на сорок неиспользуемых функций на общем хостинге, а не с WooCommerce как таковым). WooCommerce не добавляет никакой дополнительной комиссии за транзакции сверх обычной ставки платёжного процессора, а для товара с низкой маржой это имеет огромное значение. Варианты товара, простые надстройки для подписки и промокоды — всё это обрабатывалось бесплатными или действительно недорогими плагинами, а не блокировалось за повышением тарифа платформы.
Её общие месячные расходы — хостинг, домен, SSL, пара необходимых плагинов — вышли меньше $40 в месяц против реальной прогнозируемой стоимости, более чем в два раза выше на тарифе Webflow e-commerce, когда объём транзакций начал бы расти. Для основательницы, тестирующей продукт-маркет фит с тонкой маржой, эта разница не мелочь. Это разница между реинвестированием в товарные запасы и утечкой денег на софт до того, как продано достаточно, чтобы понять, работает ли бизнес вообще.
Хочу быть справедливым к Webflow здесь, потому что это не универсальное правило — для товара с более высокой маржой, для основателя, который ценит визуальную полировку выше стоимости за единицу, или для того, кто продаёт несколько дорогих позиций, а не растущий каталог SKU, e-commerce на Webflow может быть лучшим решением, особенно в связке с сервисом типа партнёра по фулфилменту, который чисто интегрируется. Урок этого проекта не «WordPress бьёт Webflow в e-commerce». Урок в том, что e-commerce — единственная категория, где нужно построить реальную модель затрат под свою конкретную маржу и объём до выбора платформы, потому что структуры цен расходятся способами, которые быстро накапливаются при масштабировании.
Сценарий 4: клиент, который клялся, что «сам будет всем управлять» после передачи проекта
Этот сценарий меня однажды обжёг, и с тех пор я встроил соответствующий вопрос в каждый первый звонок. Консалтинговая фирма среднего размера наняла меня для полного редизайна сайта. На старте проекта основатель был непреклонен: «Мы хотим сайт, которым можем управлять сами — без разработчика на подряде, без ежемесячных платежей агентству, наш офис-менеджер будет заниматься обновлениями». На основе этого брифа, и потому что сам сайт был довольно простым — страницы услуг, справочник команды, раздел ресурсов — я собрал его на Webflow. Чистые коллекции CMS для команды и ресурсов, доступ в режиме Editor для офис-менеджера, всё задокументировано.
Через три месяца после запуска мне позвонили. Офис-менеджер, которая должна была поддерживать сайт, уволилась. Её замена никогда не работала в Webflow, находила вид Designer пугающим даже несмотря на то, что я закрыл ей доступ только к режиму Editor, и что важнее — «компьютерный человек» фирмы, парень, который неформально «занимался компьютерными вопросами», вообще не знал Webflow. Он знал WordPress. В экосистеме почти каждого малого бизнеса есть такой человек: не профессиональный разработчик, а тот, кому звонят, когда что-то ломается, и существующие навыки именно этого человека тихо определяют, какая платформа реально будет поддерживаться долгосрочно.
Ничего не ломалось. Сайт работал нормально. Но фраза «управлять сами» на практике означала что-то другое, чем на первом звонке. На самом деле они имели в виду «управлять с помощью инструментов и людей, с которыми у нас уже есть отношения», а Webflow, при всей своей объективной простоте изучения для одного обученного пользователя, был чужой системой для всех в их существующей сети поддержки, кроме единственного человека, который к тому моменту уже уволился.
В итоге я взялся за платный проект полгода спустя — помочь им либо нормально обучить нового человека, либо рассмотреть пересборку на WordPress; мы выбрали грамотное переобучение, а не пересборку, поскольку сам сайт работал хорошо, но это стоило им денег и стресса, которые пятиминутный вопрос на исходном стартовом звонке позволил бы избежать.
Урок, который я из этого вынес и теперь задаю прямо на каждом первом звонке: «Кто конкретно будет заходить и вносить изменения через полгода, и что этот человек уже умеет?» Не «насколько ваша команда технически подготовлена» — это бесполезный вопрос, все отвечают «да». Я спрашиваю про их реальные существующие отношения с поддержкой. Есть ли у них ИТ-специалист, виртуальный ассистент, маркетинг-координатор, работавший с WordPress на предыдущем месте? Есть ли где-то в организации институциональные знания, которые должны повлиять на выбор платформы? Платформа поддерживаема ровно настолько, насколько поддерживаема доступными людьми, а пул таких людей значительно больше и более взаимозаменяем для WordPress просто из-за его доли рынка — маркетинг-координаторов, ассистентов и фрилансеров, знающих WordPress и доступных в короткие сроки, гораздо больше, чем знающих Webflow, хотя сам Webflow, пожалуй, проще выучить с нуля.
Это не означает, что WordPress выигрывает каждый разговор про «переживёт ли это моё участие». Это означает, что честный ответ требует вопросов о реальной человеческой инфраструктуре клиента, а не только о наборе функций платформы, и теперь я встраиваю этот вопрос в каждое предложение до того, как что-либо рекомендовать.
Сценарий 5: маркетинговая команда SaaS, постоянно проводящая эксперименты
SaaS-компания на раунде Series A наняла меня для редизайна маркетингового сайта — главная страница, страница тарифов, несколько лендингов для платных кампаний и раздел «решения по отраслям», который они хотели со временем расширять. Их маркетинговая команда состояла из трёх человек: руководителя отдела роста, который занимался платным трафиком, контент-маркетолога и дизайнера, который на время проекта отчитывался мне, а после моего уxода должен был владеть дизайном самостоятельно.
Определяющим ограничением здесь были не бюджет и не объём контента — а скорость и эксперименты. Руководитель отдела роста хотел запускать новые варианты лендингов еженедельно под разные рекламные кампании, тестировать варианты заголовков и hero-блоков и убивать неэффективные страницы за считанные дни. Это принципиально иной ритм, чем у агентства из сценария один или у издателя из сценария два.
Я выбрал Webflow, и решающим фактором была не столько CMS, сколько то, насколько быстро нетехнический человек может продублировать существующий лендинг, заменить hero-секцию, немного подправить макет под конкретную кампанию и опубликовать — всё это без единой строчки кода и без ожидания разработческого спринта. В WordPress, даже с современным блочным редактором и хорошей темой, создание настоящих дизайн-вариантов с такой скоростью обычно означает либо плагин-конструктор страниц, прикрученный к CMS (что возвращает многие проблемы раздутости и несогласованности из сценария два), либо реальное время разработчика для всего, что выходит за рамки замены текста и картинок.
Я построил компонентную систему в Webflow с использованием вложенных символов и переиспользуемых секций — варианты hero-блоков, компоненты таблицы тарифов, блоки отзывов — так, что руководитель отдела роста мог собирать новые лендинги почти как конструктор Lego в рамках заданных мной ограничений, а не начинать с чистого холста и не звать разработчика под каждый вариант. Встроенный в Webflow staging и история версий тоже сыграли здесь очень практическую роль: когда страница кампании не показывала результата и они хотели быстро откатиться на предыдущую версию, это делалось за пару кликов, а не запросом на восстановление из бэкапа хостинг-провайдеру.
Также упомяну то, что сработало не так гладко: их команда разработки в какой-то момент захотела вытаскивать структурированные данные по тарифам с маркетингового сайта в свою внутреннюю панель продукта через API, и CMS API Webflow, хоть и работоспособный, требовал больше кастомного связующего кода и постоянного обслуживания, чем headless-настройка WordPress с устоявшимся слоем REST или GraphQL. Этого не было достаточно, чтобы изменить решение о платформе — потребность в скорости маркетинга перевешивала всё остальное — но это тот тип затрат на интеграцию, который легко упустить в первоначальном разговоре о платформе, и о нём стоит поднимать вопрос заранее, если маркетинговому сайту в перспективе нужно будет «разговаривать» с внутренними инструментами.
Через девять месяцев после запуска команда роста выпустила более 60 вариантов лендингов без единого запроса к разработчикам. Это тот сценарий, для которого Webflow действительно был создан — не потому, что это «лучшая» платформа в абстрактном смысле, а потому, что быстрая итерация, полностью в руках дизайнера, была реальной задачей сайта, и инструмент подходил под эту задачу.
Фреймворк, которым я теперь реально пользуюсь, по порядку
Я не запускаю формальную оценочную матрицу с каждым клиентом, но после этих пяти проектов и десятков похожих на них я задаю себе одну и ту же последовательность вопросов, прежде чем рекомендовать платформу, и советую всем, кто стоит перед этим выбором, делать то же самое, а не отталкиваться от предпочтений к бренду или от того, что использовал конкурент.
- Кто будет трогать сайт после запуска, и что этот человек уже знает? Это вопрос, который я пропустил в сценарии четыре и теперь задаю первым, каждый раз. Не абстрактное «насколько технически подкована ваша команда», а конкретно, какой именно человек или роль будет заходить в систему каждый месяц и какой опыт с платформами уже существует в сети поддержки вашей организации — среди штата, действующих подрядчиков или агентских отношений.
- Какой реальный объём контента и сложность рабочего процесса? Несколько страниц, обновляемых время от времени, — это совершенно другая задача, чем ежедневный редакционный выпуск с несколькими авторами и цепочками согласований. Если нужны ролевые процессы публикации, большой объём контента или сложная таксономия, это само по себе сильно указывает на WordPress независимо от других факторов.
- Насколько важна скорость дизайнерских итераций, и кто ею владеет? Если дизайнеру или маркетологу нужно еженедельно выпускать новые варианты страниц без участия разработчика, а структура контента относительно простая, обычно выигрывает модель прямого управления в Webflow. Если дизайн меняется редко, а контент — постоянно, баланс смещается в другую сторону.
- Как выглядит реальная модель затрат при вашем фактическом объёме, а не при объёме на день запуска? Это особенно остро касается e-commerce, но справедливо везде — считайте затраты на горизонте шести и восемнадцати месяцев реалистичного использования, а не по самому дешёвому тарифу со страницы цен. Цены Webflow за место и уровень CMS и стоимость хостинга плюс плагины у WordPress масштабируются очень по-разному в зависимости от трафика, объёма контента и размера команды.
- Нужно ли сайту «разговаривать» с другими системами? Если есть реальная потребность в интеграции — панель продукта, вытягивающая данные о тарифах, CRM, синхронизирующая заявки со сложной логикой, кастомная авторизация, система членства с замысловатыми уровнями доступа — проверьте, что это реально требует на каждой платформе, прежде чем принимать решение. Иногда ответ всё равно склоняется к Webflow с грамотно спроектированным API-слоем; иногда решительно указывает на более зрелую экосистему плагинов и интеграций WordPress.
Ни в одном из этих пяти вопросов не заложен универсальный победитель, и именно поэтому я перестал давать клиентам мнение о платформе на первом звонке. Вместо этого я задаю им эти вопросы, и платформа обычно отвечает сама себе уже к второму разговору.
Что я категорически не советую — выбирать платформу по тому, как сайт из портфолио выглядит на скриншоте, или по тому, какую платформу использует конкурент, или по тому, на какой платформе вам самим просто веселее собирать сайты. Это реальные факторы, но они последние в списке того, что я взвешиваю, а не первые. Агентство из сценария один и издатель из сценария два оказались на противоположных платформах, и оба получили именно тот инструмент, который подходил их реальной рабочей ситуации. Именно этот результат стоит оптимизировать — не победу в абстрактном споре о том, какая платформа «лучше», а точное соответствие инструмента конкретным людям, рабочим процессам и траектории роста, которые стоят прямо перед вами.
