WordPress *

Вы опубликовали статью. Счётчик показывает пару тысяч просмотров. Но кто-нибудь её на самом деле прочитал? Обычная аналитика на этот вопрос не отвечает: человек, закрывший вкладку через три секунды, и человек, дочитавший до последней строки, для счётчика одинаковы — «1».

Хуже того, ответа не даёт и «средняя глубина прокрутки», которая есть почти в каждом сервисе веб-аналитики. О том, почему она врёт и как я решал обе задачи в бесплатном плагине AnGo Scroll Analytics для WordPress, — эта статья. Внутри: процентили вместо среднего, трекер на чистом JavaScript, отправка данных через sendBeacon, upsert с GREATEST() и принцип «клиент враждебен».

У нас небольшой сайт на WordPress в финансовой нише, SEO делаем своими руками. Позиции раньше снимал платный сервис, частотность я смотрел в браузерном Вордстате, по одной фразе. В октябре перевёл и то и другое на Search API Яндекс Облака. Получилась горстка PHP-скриптов, которые запускаются через wp eval-file на том же сервере, где живёт сайт.

Дальше будет схема, упрощённый код и грабли. Код обезличен: ни ключей, ни путей, ни идентификаторов облака. Поля API у Яндекса меняются, так что перед копированием сверьтесь с документацией.

Недавно на одном сайте пропали превью ссылок в Telegram. Разметка на месте, сайт открывается, ошибок нет, а в логах сервера за десять дней ни одного запроса от Telegram. Это самый неприятный вид поломки: сайт вроде бы работает, а что-то важное тихо сломано. Разбираем, как сделать бесплатный мониторинг WordPress-сайтов на Cloudflare Workers и во что упираешься в лимитах бесплатного тарифа.

Клиент написал: сайты лежат, похоже на DDoS. На сервере около 5 500 сайтов WordPress, nginx, PHP-FPM 8.4, MariaDB, 125 ГБ памяти, Debian 13. Я нашёл сканер, закрыл его в nginx, сайты поднялись. Через два дня клиент написал снова: всё падает каждые пять минут.

Причина оказалась не снаружи. Каждый новый воркер PHP-FPM с первого же запроса весил около 600 МБ, и OOM-killer по очереди убивал базу и nginx. Воркеры раздувал баг в OPcache, который срабатывает на каждом сбросе кеша под нагрузкой. Сбрасывал кеш Yoast SEO при обновлении. Причём не массовое обновление по всем сайтам, а догоняющее, на 467 сайтах, где плановое когда-то не прошло. Всё решил порядок двух команд.

WordPress хоронят не первый год. Сначала казалось, что его вытеснят конструкторы сайтов, затем современные JavaScript-фреймворки, headless-подход и облачные платформы. Теперь к этому списку добавились нейросети: они уже умеют не только писать отдельные фрагменты кода, но и работать с проектом целиком – запускать WP-CLI, подключать плагины, готовить тесты и помогать с деплоем.

Что это меняет для WordPress в 2026 году? Стоит ли новому разработчику изучать его с нуля, если ИИ-агенты и вайб-кодинг берут на себя всё больше рутины? Где WordPress по-прежнему удобен, а где логичнее выбрать Laravel? И насколько сегодня нужны Elementor, Gutenberg, ACF и WooCommerce, если часть задач уже можно поставить обычной фразой?

Я, Александр, автор телеграм-канала «Shulepov Code», поговорил с Александром Сокиркой – разработчиком, который пришел во фриланс еще школьником, начинал с баннера за пять долларов, затем работал с Joomla и WordPress, продавал шаблоны на маркетплейсах, сотрудничал с американскими студиями и сейчас активно экспериментирует с вайб-кодингом и ИИ-инструментами. У Александра также есть YouTube-канал: «Быть Программистом», где он публикует материалы о разработке и своем опыте.

В разговоре мы не ограничились WordPress. Обсудили Laravel, Copilot, Claude, Codex и Qwen, фриланс и зависимость от платформ, Elementor и Gutenberg, ACF и таксономии, Docker и CI/CD, WooCommerce и выгорание. Отдельно поговорили о том, что имеет смысл учить разработчику сегодня, где ИИ действительно экономит время, а где без понимания архитектуры и кода всё равно не обойтись.

Год назад мы с другом делали интернет‑магазин для его девушки. Она модель, и у неё была совместная линейка одежды с одним брендом. Нужны были каталог, лукбук, страница о ней и промо‑баннеры под каждую новую коллекцию. Каталог сделали на WooCommerce, а главную, лукбук и баннеры я сверстал в Elementor. Чтобы было быстрее, вставил вёрстку в HTML‑виджеты, подогнал стили, и всё выглядело ровно так, как задумывали. Передал доступы и забыл.

Через пару недель она пишет: «кажется, я сломала сайт». Выходила новая коллекция, она хотела поменять текст на баннере, открыла виджет, увидела там кучу div‑ов и аккуратно поправила пару строк. Заодно случайно стёрла один закрывающий тег. Половина главной съехала, подвал оказался посреди лукбука.

Винить её не за что. Elementor мы и выбрали для того, чтобы она меняла баннеры и тексты сама, мышкой, без нас. А я отдал ей конструктор, внутри которого лежит обычный HTML. Формально это Elementor, а по сути та же ручная вёрстка.

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

Но если ты создаёшь для себя или для общественного проекта, и если таких сайтов много, — появляется проблема: сайты будут тянуть деньги из кармана, так что рано или поздно — через год или десять — они «умрут».

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

Ещё один вариант — завести сайт на известной крупной платформе, например, на WordPress.com, где платформа выступает хостингом и даёт возможность прикрутить домен. И вот, как только перестаёшь платить, ты теряешь домен и возможность пользоваться всеми платными фишками, но сайт хотя бы останется на плаву на субдомене 12345.wordpress.com.

WordPress за более чем 20 лет своей истории прошел огромный путь от маленького блогового-движка до ультимативного решения в сфере разработки контентных сайтов.   Кодовая база WordPress огромна. Можно встретить спагетти-код написанный на PHP в 2003 году рядом с современным реактивным JavaScript, и это только в ядре. А если посмотреть код бесчисленных плагинов к этой CMS, то там найдется вообще все что угодно. WordPress одновременно про свободу и про обратную совместимость. Звучит круто, но задумка «делай как хочешь, обновления ничего не сломают», на деле превращается в «придумай жесткие рамки, чтобы обновления ничего не сломали».

Сначала я выбрал модель, которая отлично писала код. Подключил её к OpenCode и выяснил, что создавать файлы на диске она просто не умеет. Взял другую — та уверенно работала с файлами, но полностью поплыла на русском языке.

​В итоге победила модель, которую я поначалу оставил «для экспериментов»: слишком большая, на грани по квантованию и, казалось, сплошной компромисс.

​Ниже — о том, как я подбирал рабочую лошадку под WordPress и фронтенд на видеокарте с 16 ГБ памяти. Со скоростями, квантами и неожиданным экзаменом по русскому языку.

Реальный кейс снижения нагрузки WordPress/WooCommerce с помощью WAF

На WordPress/WooCommerce-сайте на shared-хостинге регулярно возникали серьёзные превышения нагрузки на веб-сервер и MySQL. Штатный антибот-фильтр хостинга проблему не решил. В этом кейсе я показываю, что изменилось после подключения внешнего WAF с индивидуальной фильтрацией трафика: какие запросы создавали лишнюю нагрузку, как отсеивались парсеры, сканеры и поведенческие боты и что происходило с поисковыми роботами.

По данным Beget, после замены фильтра суточная нагрузка сайта снизилась примерно в 45 раз, базы данных — примерно в 39 раз. При этом WordPress, WooCommerce, плагины, код и структура БД не изменялись. В статье — реальные графики, данные Яндекс Метрики, статистика WAF и разбор случаев, когда WAF, наоборот, не поможет решить проблему высокой нагрузки.

Начал я делать очередной сайт на Wordpress и решил упростить регистрацию пользователям. По этому пошел по схеме вход через другие сервисы. Как стало нынче модно‑сковородно использовать авторизацию через ВК. Ее то я и решил прикрутить. Делал уже это раньше но вот сегодня столкнулся с проблемой.

Клиентский сайт на WordPress уже чистили в июле, но одну закладку пропустили. Через месяц в админку зашёл скрипт, посмотрел настройки оплаты WooCommerce и удалил дефолтного пользователя admin. Вместе с ним в корзину улетели 59 страниц, а 192 объекта медиатеки удалились вместе с файлами: корзина для вложений по умолчанию отключена.

Разбираю хронику по логам, механику каскадного удаления через wp_delete_user() без переназначения автора и восстановление по частям, когда полный откат бэкапа запрещён. И две ошибки, которые я допустил уже в процессе ремонта: подстановка файла по совпадению имени и прямой SQL, после которого Yoast продолжал отдавать canonical на момент аварии.

Ставить WordPress руками — занятие на полтора часа: веб‑сервер, PHP с десятком расширений, база данных, конфиг Nginx, права на файлы, лимиты загрузки, сертификат. Я устал повторять этот ритуал и собрал скрипт, который делает всё сам и спрашивает только то, что действительно зависит от меня.

Итог, к которому мы придём: работающий сайт с настроенной админкой, ЧПУ‑ссылками, русской локализацией, при желании — с сертификатом Let’s Encrypt, phpMyAdmin и защитой от подбора паролей. Все доступы будут лежать в одном файле на сервере.

Сравнений WordPress и Tilda в интернете уже достаточно. Обычно они сводятся примерно к одному и тому же набору критериев: стоимость, простота освоения, скорость создания сайта, SEO, количество шаблонов и необходимость заниматься техническим обслуживанием.

В результате вывод тоже часто получается предсказуемым: Tilda проще и быстрее, а WordPress сложнее, зато гибче.

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

Она становится особенно заметной, когда сайт перестаёт быть набором из пяти-десяти страниц и на нём появляются повторяющиеся данные: услуги, проекты, сотрудники, объекты, товары, характеристики, отзывы. А затем эти данные начинают зависеть друг от друга.

Поэтому в этой статье я хочу сравнить WordPress и Tilda не столько по внешним возможностям, сколько по их внутренней логике:

Или, как один простой вопрос неожиданно превратился в микро-расследование.

Опуская неинтересную предысторию, нынешнее утро застало меня на сайте Context7 — MCP-сервера, обещающего всегда актуальную документацию для огромного количества фреймворков, языков и библиотек.

Прошло уже 10 лет с публикации моей предыдущей статьи на тему организации проекта на WordPress для удобной работы. Старый текст до сих пор кто-то добавляет в закладки и ставит звезды на Github, хотя многие вещи, актуальные на тот момент, устарели, а задачи поменялись. Если раньше я работал над большим количеством корпоративных сайтов, по принципу «сделал и забыл», то сейчас у меня в работе несколько долгоживущих новостных ресурсов с посещаемостью доходящей до миллиона хостов в сутки. Эти проекты требуют постоянного участия разработчика, и есть большая ответственность перед заказчиком за поломки.

Споры между Elementor и Bricks обычно сводятся к попытке определить победителя: что быстрее, удобнее, чище, функциональнее.

После нескольких лет работы с WordPress мне такой вопрос кажется не совсем правильным.

Я много работаю с Elementor PRO и не собираюсь от него отказываться. При этом для новых проектов всё чаще смотрю в сторону Bricks.

Причина не в том, что один билдер «хороший», а второй «плохой». Они по-разному вписываются в процесс разработки.

Для себя я сейчас разделяю их примерно так:

В прошлой статье я рассказывал, почему в какой-то момент пришлось делать собственный Анти Бот для WordPress: Cloudflare для части клиентов стал недоступен, а платные альтернативы вроде облачных WAF просят от 10 тысяч рублей в месяц за один сайт – и это при том, что задача у большинства клиентов скромная: отсеять спам-регистрации, спам в комментариях и мусор в формах обратной связи.

Статья неожиданно вызвала живое обсуждение, и часть комментариев была настолько по делу, что отвечать одной строкой в треде было бы нечестно. Так что это скорее не «часть 2» в смысле новой большой темы, а закрытие долгов перед читателями плюс рассказ о том, что успело измениться в плагине с мая.

Elementor позволяет собрать страницу буквально за несколько часов. Поставить контейнер, добавить заголовок, картинку, кнопку — и визуально всё работает.

Проблемы обычно начинаются позже.

Нужно поменять основной цвет сайта — оказывается, он вручную прописан в десятках виджетов.

Нужно увеличить отступы — на одной странице стоят padding, на другой margin, а на третьей вообще добавлен пустой контейнер.

Клиент поменял номер телефона — приходится искать его в шапке, подвале, странице контактов и нескольких всплывающих окнах.

А через полгода открываешь Elementor и видишь:

Container
Container
Container
Container
Image
Heading
Container…

И попробуй вспомни, что из этого что.

Поэтому для себя я использую определённые правила верстки на Elementor PRO. Они не являются официальным стандартом Elementor и не претендуют на единственно правильный способ разработки.

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

Разберём его по пунктам.

WordPress занимает около 65% рынка систем управления контентом (CMS) — и на него сейчас активно давит волна ИИ‑инструментов. Книга Ричарда Мэнсфилда «WordPress Power Toolkit» (оригинал в 2025 г., русское издание вышло в 2026 году) — это практическое руководство по тому, как объединить ИИ и работу в CMS. Автор показывает, что любой человек без опыта в программировании может создать полноценный сайт на WordPress: сгенерировать CSS, написать плагин, настроить SEO и управлять контентом — с помощью ChatGPT, Claude, Gemini и Midjourney. При этом, версии ИИ‑инструментов развиваются очень быстро, упомянутые в книге увы, уже устарели — и про эти изменения (апдейт) напишем ниже.