Поддержка сайтов
на WordPress
в Москве

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

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

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

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

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

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

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

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

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

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

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

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

Потому что настоящий носитель текста — не то, что выглядит телом страницы. Elementor, WPBakery, ACF-блоки держат контент в мете записи, а не в её тексте. Обычный перенос или поиск-замена по базе ломает такой сайт молча. Замена проходит по полю, которого на странице нет. Прежде чем что-то менять, мы находим фактический носитель и правим его.

По умолчанию задания в WordPress запускает посетитель: пришёл человек — выполнилась рассылка. На сайте с малой посещаемостью письма уходят с задержкой в часы. На нагруженном сам wp-cron становится причиной тормозов. Лечится переводом заданий на системный планировщик и отключением запуска по обращению.

Типовой вход — заброшенный плагин с известной уязвимостью и загрузка файла в каталог wp-content/uploads. Мы закрываем выполнение PHP в каталоге загрузок. Неиспользуемые плагины удаляем, а не «просто отключаем». И ведём реестр установленного с датой последнего обновления автора. Плагин, который автор не обновлял два года, — это не работающий плагин, это открытая дверь.

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

Разница не в цене за час, а в природе риска. WordPress — экосистема сторонних плагинов, и риск здесь внешний: автор выпустил обновление или, наоборот, забросил плагин; работа поддержки — это контроль зависимостей. 1С-Битрикс — монолит с собственным механизмом обновлений и лицензией, риск внутренний: правки в ядре или шаблоне от предыдущего подрядчика, из-за которых обновление уже нельзя накатить; работа начинается с того, чтобы эти правки развязать. Один и тот же тариф на двух таких сайтах расходуется по-разному. Мы говорим об этом до начала работ.

Отвечаем списком, потому что «посмотрим и скажем» — это не ответ. Мы сверяем файлы ядра с оригинальной сборкой той же версии и выписываем всё, что правили руками: такие правки исчезают при первом же обновлении вместе с функциональностью, которую держали. Смотрим права на wp-config.php и на каталог загрузок. Это две минуты и частая дыра. Проверяем, не включён ли WP_DEBUG на проде — вывод ошибок в браузер это и подсказка для взлома, и испорченная вёрстка. Сверяем версии PHP и MySQL с требованиями плагинов. Половина «необъяснимых» сбоев — это плагин, которому нужен PHP новее, чем стоит на хостинге. Составляем инвентарь плагинов и тем с датой последнего обновления автора и отмечаем заброшенные. Разбираем, что висит в cron и не дублируются ли задания. Выясняем, откуда уходят письма — через хостинг, SMTP или плагин, — потому что «письма не приходят» это чаще всего почта, а не форма. Проверяем копии: есть ли они, какого возраста, разворачивается ли из них сайт. Результат — два списка: что есть и что сломано или опасно, с оценкой в часах по каждому пункту.

Тариф 20 часов в месяц — это примерно так: 3–4 часа на обновления и проверку после них, 2–3 часа на мониторинг и разбор оповещений, 6–8 часов на задачи от вас — тексты, баннеры, правки блоков, новый раздел, — и остаток на инциденты и резерв. Инцидентов не было — неизрасходованное уходит в задачи, а не «сгорает молча». Отчёт по часам показываем. На 50 и 100 часах пропорция другая. Доля обновлений и проверок почти не растёт, растёт доля разработки: доработки, интеграции, оптимизация. Отсюда и цена часа на больших тарифах: 3 300 рублей на 50 часах и 3 100 на 100 против 3 500 на 20. Расход зависит и от того, на чём сайт: на WordPress с десятком плагинов больше уходит на контроль обновлений, на 1С-Битрикс с правками в ядре — на то, чтобы эти правки развязать и сделать обновления возможными.

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