Перейти к содержимому

Умирает ли WordPress?

Опубликовано 26 октября 2026 г. · Автор Сергей Прокопов

Вопрос, который я слышу всё чаще: умирает ли WordPress?

Долгое время WordPress был моим ответом по умолчанию, когда клиенту нужен был простой «сайт‑визитка»: несколько страниц о компании, услуги, контакты, по требованию — новости. Привычный путь: нажал пару кнопок в панели хостинга, запустил установщик, выбрал тему, поставил пару плагинов — и начинай писать. Неглючно, знакомо, быстро. Можно отдать доступ не‑техническому человеку, и он будет добавлять и править страницы без обучения. Именно за это WordPress и выбирали.

Но веб изменился. Изменились и компромиссы.

Сегодня, когда есть мощные AI‑ассистенты, а также платформы вроде Replit и AI‑конструкторы сайтов и приложений — Lovable, Bolt.new, v0 и Framer AI — люди спокойно уходят с WordPress на статические сайты. Не потому что WordPress перестал работать, а потому что старая сделка — удобство в обмен на живую серверную систему — больше не окупается для множества небольших корпоративных сайтов. Вот почему я так считаю и почему увёл наш собственный сайт с WordPress.

Бесконечный конвейер обновлений

Если вы когда‑либо сопровождали хотя бы один продакшен‑сайт на WordPress, вы знаете это чувство: обновления ядра, обновления темы, обновления десятка плагинов, о половине из которых уже и не вспомнить. Каждое обновление — маленький риск. Что‑то сломается? Два плагина начнут конфликтовать? Тема перетрёт нужную настройку?

Умножьте это на портфель клиентских сайтов — и конвейер превращается в заметную работу. Либо тратишь время на клики по кнопкам и тестирование, либо смиряешься, что часть компонентов устареет, и надеешься, что ничего страшного не случится. Когда занят фичами и поддержкой, «зайти ради профилактических обновлений» легко сползает в конец списка дел.

Широкая поверхность атаки

Обновления существуют, потому что существуют уязвимости — не только в ядре WordPress, но и в темах и плагинах. Каждый движущийся элемент динамического стека увеличивает поверхность атаки. Популярные цели постоянно сканируются ботами. Достаточно одного слабого звена, чтобы попасть внутрь. Можно усилить вход, ограничить плагины, поставить защитный плагин и файрвол. Всё равно достаточно одного пропущенного обновления, одного уязвимого плагина, одной ошибки.

Я не обвиняю никого. Команда WordPress и авторы плагинов делают большую работу. Но модель такова: динамический PHP‑код, база данных и множество расширений, которые крутятся на живом сервере постоянно. Это удобно — и это открыто миру.

Взлом, который меня отрезвил

Я держу проекты в порядке. Ради удобства у меня было несколько маленьких сайтов под одной учётной записью хостинга. Это не были ценные цели. Один сайт, самый неважный, какое‑то время не обновлялся. Этого хватило. Его скомпрометировали, и, поскольку всё лежало в одной учётке, вредоносный код разошёлся по всему дереву.

Самое неприятное? Наш собственный сайт получил инъекции спама — посты в духе «дарк‑веб‑маркет», с ссылками, которые не хочется видеть. Чистить это было неприятно: искать изменённые файлы, сравнивать бэкапы, вычищать мусор. Вывод получился простой: для базовых корпоративных сайтов динамическая платформа приносит больше проблем, чем пользы.

Выход — статический сайт

Современный статический сайт не имеет движущихся серверных частей. Никакого PHP‑рантайма, базы данных, ни экосистемы плагинов, исполняющейся на каждый запрос. Сайт заранее рендерится в чистые HTML, CSS и немного JavaScript там, где это оправдано. Хранится на edge‑CDN, и на этом всё. Патчить почти нечего, потому что почти нечему крутиться. Поверхность атаки схлопывается.

Для пересборки я выбрал Astro. Это генератор, который по умолчанию старается не отправлять лишний JavaScript в браузер. Он быстрый по дизайну и приятный в работе. Я также использовал AI‑ассистента — в моём случае, Cursor — как напарника‑программиста. Взял старый сайт на WordPress, описал, как хочу его модернизировать, и пошёл итерациями. Ассистент генерировал компоненты, переносил тексты, предлагал структуру и переписывал тему в чистый, читаемый код. Я проверял каждое изменение и сохранял полный контроль. Это ощущалось как магия без потери владения кодовой базой.

Из Git — сразу в Cloudflare

Финальный шаг — публикация. Я поместил новый проект на Astro в репозиторий GitHub и подключил его к Cloudflare. Каждый пуш собирает сайт и публикует его на глобальный edge. Для каждой ветки появляется превью‑URL, так что можно проверить изменения с командой до слияния. Прод — это всего лишь защищённая ветка. Раздача статических файлов на границе — как раз то, в чём силён Cloudflare: быстро, надёжно и скучно в хорошем смысле.

Никаких кронов, никаких «обновить ради обновления», никакого страха, что заброшенный плагин тихо откроет дверь. Хочу что‑то поменять — меняю код, коммичу и пушу. Дальше Cloudflare делает свою работу. Хочу добавить страницу — добавляю файл. Хочу перевести сайт — добавляю локализованный маршрут. Хочу опубликовать такую статью — пишу Markdown, а генератор берёт на себя шаблоны, метаданные и карту сайта.

«Но мне нужно легко править страницы»

Это была главная причина выбора WordPress. Хотелось добавлять и редактировать страницы без разработчика. Сегодня это возможно без тяжёлой CMS. Есть Git‑базированные интерфейсы поверх репозитория, где не‑технические пользователи редактируют контент через формы. Есть headless‑варианты, если они действительно нужны. А AI‑ассистенты способны черновить текст по вашим заметкам и складывать его куда надо. Для небольшого маркетингового сайта статической связки достаточно — и она оставляет управление у вас.

Наш чек‑лист после миграции

  • Чистая кодовая база, которую мы понимаем от и до.
  • Быстрый сайт, который почти не шлёт JavaScript по умолчанию.
  • Автодеплой из GitHub в Cloudflare.
  • Никаких баз данных, PHP и плагинов, которые надо патчить.
  • Контент в Markdown — статьи легко писать и ревьюить.
  • Мизерная «поверхность атаки»: атаковать просто нечего.

Именно этого я и хотел — как разработчик и как владелец бизнеса.

Общая тенденция

Речь не о том, чтобы ругать WordPress. Он построил огромную часть веба и отлично тянет сложные, контентно‑тяжёлые проекты. Но выбор по умолчанию для простых корпоративных страниц меняется. С AI, который помогает строить, с генераторами вроде Astro, которые компилируют сайт в статический HTML, и с edge‑хостингом от таких провайдеров, как Cloudflare, вы получаете более чистый результат с меньшей болью.

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

Что мы сделали по шагам

  1. Проаудировали старый сайт и выгрузили тексты и изображения, которые нам всё ещё нравились.
  2. Попросили Cursor помочь со скелетом проекта на Astro и переписать структуру темы.
  3. Зафиксировали результат в чистом репозитории GitHub.
  4. Подключили репозиторий к Cloudflare и настроили превью‑сборки на каждую ветку.
  5. Перенесли формы и мелкие интерактивные части на простые и надёжные решения.
  6. Написали этот пост в Markdown с локализованными маршрутами для русского, английского и эстонского.

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

Куда двигаться дальше?

Если вы держите небольшой сайт на WordPress и он постоянно требует внимания — обновления, заплатки, изредка тревожные сюрпризы — подумайте о статике. Попробуйте Astro. При желании подключите AI‑ассистента. Положите репозиторий в GitHub и позвольте Cloudflare публиковать сайт глобально при каждом пуше. Вы по‑прежнему сможете легко добавлять и править страницы — и, вероятно, будете спать спокойнее.

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