Разработка сайта на WordPress: где платформа сильна, а где начинаются проблемы

Кому платформа подходит, а кому нет

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

Подходит хорошо. Сайт услуг на 10–40 страниц. Корпоративный сайт с новостями и разделом о компании. Блог или медиапроект — здесь платформа исторически сильнее всех. Небольшой магазин до нескольких сотен позиций с простым ассортиментом. Посадочные страницы под рекламу, когда их нужно быстро создавать и менять.

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

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

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

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'lead_submit',
  form_id: 'audit',
  page_path: location.pathname
});

Разбор сборки: сайт услуг на 14 страниц

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

2. Тема — не готовый шаблон из каталога. Взяли лёгкую основу и сверстали под структуру. Причина: универсальные темы из маркетплейсов тянут за собой конструктор, слайдеры, десяток шрифтов и набор функций «на все случаи», из которых используется пятая часть. Разница в скорости получается кратной.

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

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

5. Формы — одна связка, а не пять разных. Все формы на сайте работают через один механизм и складывают заявки в базу, дублируя на почту. Пять разных плагинов форм — типичное наследие сайтов, которые дорабатывали годами, и типичный источник «заявка не пришла».

Итог по срокам: примерно три недели, из которых неделя — структура и согласование, полторы — вёрстка и сборка, остальное — наполнение и проверки.

Плагины: минимальный набор и почему их не должно быть тридцать

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

Что действительно нужно почти всегда:

Практическое правило перед установкой очередного расширения: спросить, какую задачу оно решает и нельзя ли решить её десятью строками в теме. В половине случаев можно.

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

Конструктор страниц: удобство сейчас против скорости потом

Визуальные конструкторы — самая спорная часть экосистемы. Разберём честно обе стороны.

За. Редактор без разработчика собирает новую посадочную страницу за час. Для компании, которая часто запускает рекламные кампании под разные услуги, это реальная экономия — не нужно ждать очереди у подрядчика.

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

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

Отдельно предупреждение: уход с конструктора потом — это переделка вёрстки всех страниц, которые на нём собраны. Решение принимается фактически навсегда, поэтому обсуждать его лучше в начале проекта, а не когда страниц уже сорок.

Почему сайт медленный: пять причин по убыванию частоты

Жалоба «платформа тормозит» почти всегда раскладывается на конкретные причины. Порядок проверки от самого частого:

1. Изображения в исходном размере. Редактор загружает фотографию с телефона на 4 МБ, платформа показывает её в блоке шириной 400 пикселей, но отдаёт целиком. Самая частая причина, и самая простая: настройка размеров при загрузке плюс пересжатие в современный формат.

2. Слишком много расширений. Каждое добавляет свои файлы стилей и скриптов на все страницы. Диагностика простая: посмотреть, сколько отдельных файлов запрашивает страница. Если их за сотню — искать нужно здесь.

3. Отсутствие кеширования. Без него платформа собирает страницу заново при каждом обращении, обращаясь к базе десятки раз. Включение кеша часто даёт кратное ускорение за полчаса работы.

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

5. Тяжёлая тема. Универсальные темы с сотней настроек несут соответствующий объём кода. Лечится либо заменой, либо отключением неиспользуемых модулей темы, если она это позволяет.

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

Безопасность: почему взламывают и что делать

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

Что даёт основную защиту:

Регулярные обновления. Платформа, тема, все расширения. Раз в месяц, с предварительной копией. Это скучно и потому не делается — а именно это и есть главная мера.

Удаление неиспользуемого. Отключённый, но не удалённый плагин остаётся файлами на сервере и остаётся уязвимым. Отключение не равно удалению.

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

Резервные копии вне сервера. Копия, лежащая на том же хостинге, при серьёзной проблеме исчезает вместе с сайтом.

Что делать, если сайт уже взломан. Порядок такой: закрыть сайт от посетителей, снять копию текущего состояния для разбора, восстановиться из чистой копии до даты заражения, обновить всё, сменить все пароли и ключи, проверить учётные записи на посторонние. И только потом открывать. Попытка «почистить и оставить как есть» обычно заканчивается повторным заражением через неделю: закладка остаётся.

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

Когда пора уходить с платформы

Признаки того, что вы упёрлись в потолок и дальнейшие вложения в текущее решение не окупятся:

Каталог перестал справляться. Страницы фильтров генерируются медленно, кеширование конфликтует с актуальностью остатков, а любая доработка требует всё больше времени.

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

Каждая доработка ломает две другие. Признак накопившегося технического долга: сайт собран из расширений, которые конфликтуют, и любое изменение требует проверки всего.

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

И признак обратного — уходить не нужно: «нам сказали, что это несерьёзная платформа». Это не аргумент. Сайт услуг или блог на ней работает прекрасно и переезд не даст ничего, кроме расходов и просадки трафика на время переноса.

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