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

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

При взломе порядок один: сначала изолируйте сайт, потом лечите. Ниже — календарь с минутами, из которого сложились эти 4 часа, и план на случай взлома.

Короткий ответ: сколько времени и что по частоте

Регламент держится на четырёх ритмах: ежедневном, еженедельном, ежемесячном и квартальном. Ежедневное делают автоматы, человек только читает оповещения. Основное время уходит на еженедельные обновления.

Таблица 1. Календарь работ на месяц (оценка для сайта на 10–20 плагинов без интернет-магазина, на 2026 год)

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

Колонка «Кто» делит работу на две роли. Владелец отвечает за то, что видно глазами клиента: формы, письма, пользователи. Администратор — за то, что требует доступа к хостингу.

Обновления: ядро, плагины и тема

Ядро

Минорные выпуски WordPress с исправлениями безопасности ставятся автоматически. Начиная с версии 5.6, новые установки обновляются автоматически и до мажорных версий, если на сервере не найден контроль версий — так описано в официальном руководстве по обновлению. Старые установки сохраняют прежнее поведение. Проверьте, что включено у вас: «Консоль → Обновления».

Плагины и тема

Основной риск сидит здесь, и это видно по цифрам. По отчёту Patchstack за 2025 год (опубликован 25.02.2026) в экосистеме WordPress нашли 11 334 новые уязвимости: 91 % — в плагинах, 9 % — в темах, в ядре всего 6, и все низкого приоритета. Там же: 46 % уязвимостей не получили патча к моменту публикации. Медиана до массовой эксплуатации самых атакуемых из них — 5 часов.

Из этих чисел следуют два правила. Меньше плагинов — меньше поверхность атаки. А для критических патчей недельный ритм слишком медленный: подпишитесь на оповещения базы уязвимостей Patchstack или аналогичной и ставьте такие исправления в тот же день.

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

Как читать changelog

Вкладка «Журнал изменений» есть у каждого плагина в каталоге wordpress.org. Смотрите на четыре сигнала:

1. Слова «security», «XSS», «CSRF», «SQL injection» — обновлять сразу, вне недельного цикла.
2. Смена первой цифры версии (2.9 → 3.0) — возможны несовместимости. Только через staging, с запасом времени на откат.
3. Новые требования к версии PHP или WordPress — сначала сверьте свои.
4. Последнее обновление больше года назад — плагин, похоже, заброшен. Ищите замену при квартальной ревизии.

Выбор самого набора плагинов разобран в статье какие плагины нужны сайту для США; здесь речь об уходе за ними.

Бэкапы: правило 3-2-1 и пробное восстановление

Правило 3-2-1 звучит так: три копии данных, на двух разных носителях, одна из них за пределами основной площадки. Для сайта это значит рабочий сервер, облачное хранилище (S3, Google Drive, Dropbox) и копия у вас на диске. Официальная инструкция WordPress по бэкапам советует держать 3–5 свежих копий в разных местах.

Бэкап только на том же хостинге защищает от ошибки в правке. От взлома аккаунта хостинга, блокировки или банкротства провайдера он не спасёт: копия пропадёт вместе с сайтом.

Копируйте две вещи — базу данных и папку wp-content с загрузками, темой и плагинами. Ядро можно скачать заново. Для сайта с ежедневными заявками хватает суточной копии, для магазина с заказами каждый час частоту поднимайте.

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

Защита: пользователи, вход, редактор файлов, PHP

Основа — официальное руководство по защите WordPress. Из него для малого сайта в регламент попадают четыре вещи.

Пользователи и роли

У каждого человека своя учётная запись, общих логинов нет. Администратор — только у тех, кто ставит плагины. Контент-менеджеру хватит роли «Редактор». Уволился сотрудник или закончился договор с фрилансером — запись удаляется в тот же день, в ежемесячной ревизии вы это проверяете.

Двухфакторный вход

В самом WordPress его нет, ставится плагином; варианты перечислены в разделе Two Step Authentication того же руководства. Включите его как минимум всем администраторам.

Редактор файлов в админке

Строка define( 'DISALLOW_FILE_EDIT', true ); в wp-config.php отключает правку кода тем и плагинов из браузера. Руководство честно предупреждает: загрузку вредоносных файлов это не остановит, но часть атак через украденный пароль администратора оборвёт.

Версия PHP

По графику php.net на 28.09.2026 поддерживаются ветки 8.2–8.5, причём у 8.2 исправления безопасности заканчиваются 31 декабря 2026 года. WordPress рекомендует PHP 8.3 или новее. Если хостинг показывает 8.2 или старше, запланируйте переход в ближайшие недели: сначала на staging, с проверкой всех плагинов.

Принципы, по которым строят защиту крупных проектов, разобраны в статье о том, как устроена безопасность WordPress на больших сайтах. Малому сайту из неё хватит логики, календарь выше закрывает практику.

Что делать при взломе: план из 10 шагов

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

1. Изолируйте сайт: включите режим обслуживания или закройте доступ ко всему, кроме своего IP. Поставьте рекламу на паузу, чтобы не вести клиентов на заражённые страницы.
2. Снимите копию заражённого состояния: файлы, базу и логи сервера — в отдельную папку. Она нужна для разбора причины, восстанавливать из неё нельзя.
3. Смените все пароли и соли: хостинг, SFTP, база данных, все администраторы WordPress, почта администратора. Новые ключи и соли для wp-config.php выдаёт генератор WordPress; после замены все открытые сессии, включая сессию взломщика, закроются.
4. Проверьте пользователей: удалите незнакомые учётные записи, особенно с ролью администратора.
5. Выберите путь — чистый бэкап или ручное лечение: если есть копия до даты взлома и вы её восстанавливали на пробу, разверните её и переходите к шагу 7. Если нет — лечите по шагам 6–8.
6. Поставьте ядро начисто: скачайте WordPress с wordpress.org и замените папки wp-admin и wp-includes целиком. Ядро не должно содержать ваших правок, так что потерять здесь нечего.
7. Проверьте плагины и тему по базе уязвимостей: найдите в базе Patchstack или аналогичной каждый установленный компонент с его версией. Уязвимый без патча удаляйте, остальные переустанавливайте из официального источника, иначе после чистки вас взломают той же дверью.
8. Ищите бэкдоры: файлы .php в папке uploads, незнакомые файлы в mu-plugins, правки в .htaccess и wp-config.php, чужие задачи в cron, скрипты в таблицах записей и опций базы.
9. Откройте отчёт «Проблемы безопасности» в Search Console: там видно, что именно Google нашёл и на каких адресах. Проверьте, что все примеры из отчёта чистые.
10. Запросите проверку: кнопка есть в том же отчёте. По справке Google проверка занимает от нескольких дней до нескольких недель. Пока она идёт, повторный запрос не отправляйте.

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

Когда регламент пора отдать

Признаки, что своими силами регламент не тянется:

• за последний квартал вы хотя бы раз пропустили недельные обновления;
• бэкап ни разу не разворачивали на пробу;
• staging нет, и обновления ставятся сразу на рабочий сайт;
• сайт принимает оплату, и час простоя обходится дороже часа работы разработчика;
• сайт уже взламывали, а причину так и не нашли.

Два совпадения из пяти — сигнал отдать календарь тому, у кого это работа. В пакетах поддержки под США в базу входят мониторинг аптайма, еженедельные обновления, ежедневный бэкап, сканирование на вредоносный код и ежемесячный отчёт о состоянии сайта; подробности — на странице про обслуживание сайта по регламенту. Если сайт собран на заброшенной теме и чинить его дороже, чем пересобрать, начните с раздела про сайт на WordPress для рынка США: цена там — смета после брифа.

Как обслуживание вписывается в весь запуск сайта под американский рынок — в материале руководство по сайту для бизнеса в США.