WordPress помер як автоматична відповідь, а не як програмне забезпечення.
Ця відмінність має значення. Якщо сказати «WordPress помер» як буквальне твердження про ринок, дані це спростовують. W3Techs повідомляє, що станом на червень 2026 року WordPress живить 59,2% вебсайтів із відомою CMS і 41,5% усіх вебсайтів. Це не можна назвати мертвим.
Але якщо ви створюєте вебсайти у 2026 році, старий рефлекс почав здаватися неправильним. Клієнту потрібен швидкий сайт, кастомний макет, чистий SEO, кілька інтеграцій та робочий процес редагування, який не потребує десяти плагінів. Раніше відповіддю був WordPress, тому що кастомний код був повільним і дорогим. ШІ змінив цей розрахунок.
EmDash від Cloudflare робить цей зсув важче ігнорувати. Cloudflare не каже, що WordPress не має цінності. Вони кажуть, що наступна CMS може бути написана на TypeScript, бути serverless, працювати на Astro, мати ізольовані плагіни та бути створеною для агентів ШІ з першого дня.
Я все ще поважаю WordPress. Я б все одно використав його у відповідному проєкті. Але я більше не вважаю, що він заслуговує бути варіантом за замовчуванням.
Чому WordPress помер як варіант за замовчуванням
WordPress переміг, тому що надав нетехнічним людям можливість публікувати контент. Це був справжній прорив. Ви могли встановити тему, додати конструктор сторінок, опублікувати дописи в блозі, додати форми, додати SEO-метадані та передати сайт клієнту.
Для багатьох бізнес-сайтів ця пропозиція старіла погано.
Простий сайт часто перетворюється на стек плагінів: конструктор сторінок, плагін кешування, SEO-плагін, плагін форм, плагін безпеки, плагін зображень, плагін cookie, плагін перенаправлень, плагін схеми, а іноді й плагін кастомних полів, щоб зробити конструктор сторінок менш болісним. Кожен елемент додає оновлення, налаштування, таблиці бази даних, ресурси та ще одну точку відмови.
Проблема не в ядрі WordPress. Проблема в операційній формі, яку багато проєктів на WordPress набувають через рік. Сайт стає невеликою бекенд-системою для сторінок, які можна було б випустити як чистий HTML, невелику CMS та кілька API-викликів.
Звіт Patchstack про безпеку WordPress за 2026 рік робить вартість обслуговування важче ігнорувати. У звіті зазначено, що у 2025 році в екосистемі WordPress було виявлено 11 334 нові вразливості, що на 42% більше, ніж у 2024 році. Також зазначено, що 91% нових вразливостей було знайдено в плагінах, 9% — у темах, і лише 6 вразливостей було повідомлено в ядрі WordPress, усі з низьким пріоритетом.
У цьому й суть. Сам WordPress не є лиходієм. Ризик живе на поверхні плагінів.
EmDash — найчистіший сигнал
Це та частина, яку мені слід було включити з самого початку. Cloudflare представила EmDash 1 квітня 2026 року як попередню версію v0.1.0 і описала її як духовного наступника WordPress.
Деталі узгоджуються з аргументом у цій статті. EmDash написана на TypeScript, працює на Astro, є відкритим вихідним кодом під ліцензією MIT і розроблена для serverless-хостингу. Вона також націлена на конкретний больовий пункт WordPress, який постійно повертається: плагіни.
У WordPress плагін працює в тому самому середовищі, що й сайт. Він може взаємодіяти з базою даних, файловою системою та середовищем виконання способами, які вимагають великої довіри. Модель Cloudflare EmDash штовхає плагіни в ізольовані Dynamic Workers і надає їм оголошені можливості через прив'язки (bindings). Плагін повинен запросити точні дозволи, які йому потрібні, наприклад, читання контенту або надсилання електронної пошти, перш ніж він зможе виконати цю роботу.
Це сучасна ідея CMS: менше неявної довіри, більше явних дозволів.
EmDash також важливий, тому що розглядає агентів ШІ як частину робочого процесу. Cloudflare каже, що кожен екземпляр EmDash може надавати віддалений сервер MCP, а також інструменти CLI та навички агентів. Це означає, що агент кодування може керувати контентом, схемами, медіа та роботою з міграцією через структуровані інструменти, замість того щоб скрапити адмін-панель або вгадувати, де живуть дані.
Я б не сказав клієнту сліпо мігрувати на EmDash сьогодні. Це попередня версія. Важлива частина — це напрямок: Cloudflare будує заміну WordPress навколо тих самих речей, які я тепер хочу від вебсайтів: ізольовані розширення, чиста фронтенд-архітектура, програмне керування та операції, зрозумілі для агентів.
ШІ змінив математику кастомних сайтів
Кілька років тому кастомний означав дорогий. Ви або платили розробнику за створення кожної сторінки та компонента, або використовували конструктор сторінок і приймали його вагу.
ШІ робить середній шлях практичним. Ви можете описати макет, згенерувати компоненти, уточнити відступи, написати текст, створити структурований контент, побудувати невеликий адмін-потік і підключити саме ті сервіси, які вам потрібні. Такі інструменти, як v0, Framer AI, Webflow AI, конструктори додатків типу Lovable та сучасні агенти кодування, зробили створення кастомних інтерфейсів швидшим.
Це не означає, що ШІ замінює смак, QA або інженерне судження. Це означає, що перший чернетковий варіант більше не забирає весь бюджет.
Саме тут WordPress втрачає свою позицію за замовчуванням. Якщо я можу отримати кастомну збірку на Next.js, Astro, EmDash або Webflow, яка точно відповідає бренду, швидко завантажується, постачається з чистою схемою та уникає важкого бекенду, компроміс з WordPress стає важче виправдати.
Конструктор сторінок дає вам ручки налаштування. Робочий процес коду за допомогою ШІ дає вам фактичну систему: компоненти, модель контенту, маршрути, метадані, обробку зображень, форми, аналітику та правила розгортання. Ви можете це перевірити. Ви можете це версіонувати. Ви можете це протестувати.
Це важливіше, ніж маркетплейс тем.
Бекенд повинен відповідати завданню
Сайту-візитці не потрібна адмін-панель на основі бази даних за замовчуванням. Лендінгу не потрібні PHP, MySQL, двадцять екранів налаштувань і шар кешування, щоб виглядати швидко.
Використовуйте бекенд, коли проєкт цього потребує:
Не додавайте бекенд лише тому, що темі потрібно десь зберігати блоки.
Сучасний легкий стек може бути меншим. Статичні сторінки, маршрути з серверним рендерингом, headless CMS, Supabase, потік контенту на основі Git, хостинг форм, Stripe, постачальник пошуку та невеликий API покривають великий відсоток вебсайтів. Ви отримуєте менше рухомих частин і кращий контроль над продуктивністю.
Це та сама причина, чому мене турбує чистий HTML і виважена робота над SEO. У моєму кейс-стаді щодо балу SEO в Lighthouse→ перемога прийшла завдяки дисциплінованій розмітці, схемі, швидкості, доступності та кешуванню. Конструктор сайтів може допомогти, але кінцевий результат все одно має бути читабельним для браузерів, пошукових систем та агентів ШІ.
ШІ робить точний дизайн менш дорогим
Найсильніший аргумент проти WordPress більше не лише швидкість. Це контроль над дизайном.
Більшість проєктів на WordPress починаються з теми, а потім бренд вигинають, щоб він під неї підійшов. Ви змінюєте шрифти, кольори, секції та відступи, але тема все одно залишає відбитки. Сайт виглядає як інструмент, який його створив.
ШІ перевертає цей робочий процес. Ви можете почати з бренду, пропозиції, аудиторії та фактичної моделі взаємодії. А потім згенерувати інтерфейс навколо цих обмежень.
Це кращий порядок.
Сайт консультанта може мати саме ту структуру доказів, яка йому потрібна. Сторінка SaaS може показувати щільну продуктову поверхню замість універсального героя. Сторінка музичного продукту може відчуватися як реальний студійний інструмент, а не як шаблон. Сторінка місцевого бізнесу може зробити бронювання, довіру, локацію та інформацію про послуги видимими без боротьби з припущеннями макету теми.
Результат все одно потребує перевірки. ШІ може генерувати поганий CSS, слабку доступність, роздутий JavaScript і нечіткий текст. Людина все одно повинна перевірити сторінку, протестувати мобільну версію, перевірити посилання, підтвердити метадані, запустити Lighthouse та підтримувати чесність написаного.
Але ШІ усуває виправдання, що кастомний означає повільний.
Коли WordPress все ще перемагає
Я б все одно обрав WordPress, коли робочий процес редагування є продуктом.
Якщо команда публікує багато дописів, використовує існуючі редакційні звички WordPress, залежить від WooCommerce, потребує конкретних зрілих плагінів або вже має роки SEO-історії в стабільному налаштуванні WordPress, перебудова заради моди є поганим ходом.
WordPress також добре працює для команд, яким потрібна знайома адмін-поверхня більше, ніж кастомний фронтенд. Є цінність в інструменті, який люди вже знають.
Помилка полягає у виборі WordPress до того, як запитати, що сайт повинен робити.
Для багатьох нових збірок сайту потрібні швидкість, структура, кастомний дизайн, контрольовані інтеграції та низьке обслуговування. WordPress може робити ці речі, але часто досягає їх через додаткові шари. Кастомні збірки за допомогою ШІ досягають їх більш прямо.
Моє практичне правило
Я б поставив три запитання перед вибором WordPress сьогодні.
По-перше, чи потрібен клієнту саме досвід адміністрування WordPress?
По-друге, чи вирішує плагін складну бізнес-проблему краще, ніж невелика кастомна інтеграція?
По-третє, чи буде сайт все ще легко обслуговувати через дванадцять місяців оновлень, маркетингових запитів, скриптів відстеження та змін контенту?
Якщо відповідь «так», WordPress може бути правильним вибором.
Якщо відповідь «ні», я б почав з легшої архітектури та використав ШІ для створення точного інтерфейсу. Це може означати статичний сайт, headless CMS, фронтенд на React або Astro, EmDash, Webflow, Framer або невеликий повностековий додаток. Стек повинен відповідати роботі, а не звичці.
Саме тут агенти ШІ стають корисними. Хороший агент може перевірити сайт, підтвердити посилання, перевірити метадані, протестувати збірку, оновити контент і залишити слід. Я писав про цей шар контролю у своїй статті про робочі процеси розробників MCP→. Та сама ідея застосовується до вебсайтів: інструменти повинні надавати чіткі дії, а не ховати все за екраном плагіна.
Вердикт
WordPress помер як автоматична відповідь. WordPress не помер як програмне забезпечення.
EmDash ще ранній, але він показує, куди рухається розмова про CMS: serverless за замовчуванням, дружній до TypeScript, рідний для фронтенду, безпечніші межі плагінів та робочі процеси з агентами ШІ замість ручної адмін-рутини.
Веб рухається до швидших фронтендів, менших бекендів, дизайну за допомогою ШІ та більш явного контролю над кінцевим результатом. WordPress все ще має своє місце, але він повинен заробляти це місце проєкт за проєктом.
Якщо вам потрібна видавнича машина, використовуйте її. Якщо вам потрібен кастомний вебсайт, який відчувається точним, швидко завантажується та уникає важкого бекенду, ШІ зробив кращий шлях легшим для проходження.