Разработка сайта на 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. Формы — одна связка, а не пять разных. Все формы на сайте работают через один механизм и складывают заявки в базу, дублируя на почту. Пять разных плагинов форм — типичное наследие сайтов, которые дорабатывали годами, и типичный источник «заявка не пришла».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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