Как обновить PHP для WordPress без поломок

PHP — язык, на котором работает WordPress. Его версию выбирает не админка WordPress, а сервер у хостинга. Поэтому обновление PHP — не галочка ради зелёного статуса: вы меняете среду, в которой запускаются ядро, тема и плагины.

WordPress сейчас рекомендует PHP 8.3 или новее. Старые версии могут ещё запускать сайт, но уже не являются безопасной долгосрочной опорой. У PHP есть понятный жизненный цикл: после активной поддержки остаётся ограниченный период security support, а затем ветка достигает конца поддержки. Но правило «поставить самую свежую версию прямо на проде» всё равно плохое. Устаревший плагин или самописный код могут не пережить переход.

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

Сначала выясните, что у вас сейчас

В WordPress откройте Инструменты → Здоровье сайта → Информация. В блоке «Сервер» будет версия PHP. Там же видны сведения о WordPress, активной теме, плагинах, базе и конфигурации. Экран «Здоровье сайта» только диагностирует: он не обновляет PHP сам.

На вкладке «Статус» WordPress может отдельно показать предупреждение об устаревшем PHP. Это полезный сигнал, но не команда нажать первую попавшуюся кнопку в панели хостинга. Сначала ответьте на три вопроса:

1. Есть ли у вас полный бэкап файлов и базы?
2. Кто отвечает за тему и критичные плагины: вы, подрядчик или разработчик?
3. Есть ли тестовая копия сайта, где можно повторить переключение без посетителей и заявок?

Если на один из вопросов ответ «нет», сначала закройте этот риск. Обновление PHP занимает немного времени; восстановление сайта после непродуманного переключения — обычно гораздо дольше.

Какую версию PHP ставить

Официальная рекомендация WordPress на момент обновления этой статьи — PHP 8.3 или выше. На странице PHP.net опубликован календарь поддержки веток: к августу 2026 года поддерживаются 8.2, 8.3, 8.4 и 8.5, но WordPress использует 8.3+ как современный базовый ориентир.

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

• доступна на вашем хостинге;
• не ниже PHP 8.3;
• проверена на тестовой копии вместе с вашей темой и активными плагинами;
• имеет актуальную поддержку по календарю PHP.

Если сайт важен для продаж, не перепрыгивайте через несколько крупных версий одним движением на боевом контуре. Сначала повторите маршрут на staging-копии. Для сайта без staging хотя бы подготовьте бэкап и возможность быстро вернуть прежнюю версию через панель или поддержку хостинга.

Сделайте бэкап, который можно вернуть

Бэкап — это не сообщение «резервная копия создана». Это сохранённые файлы сайта и база данных, понятное место хранения и возможность восстановить копию. WordPress прямо рекомендует сделать backup до изменения PHP: если что-то пойдёт не так, понадобится вернуть и сайт, и прежнюю серверную версию.

Перед началом зафиксируйте:

• текущую версию PHP;
• дату и время бэкапа;
• способ восстановления и доступ к нему;
• список критичных страниц и действий: главная, каталог, корзина, форма заявки, личный кабинет, отправка письма;
• контакт поддержки хостинга.

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

Подготовьте WordPress, тему и плагины

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

Проверяйте именно функции, на которых держится бизнес:

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

Не обновляйте всё «пакетом» прямо перед переключением, если нет нормального отката. Иначе при ошибке будет непонятно, виновата новая PHP-версия, обновлённый плагин или тема. Если нужен отдельный план на случай 500-й, держите под рукой разбор ошибки 500 в WordPress.

Проверьте совместимость на тестовой копии

Тестовая копия (staging) — это дубликат сайта, закрытый от индексации и от реальных пользователей. Она даёт возможность сменить PHP без риска для заявок, заказов и репутации. Если хостинг умеет создавать staging-копию, используйте её. Если нет — попросите поддержку создать копию или подготовьте отдельное окружение с теми же версиями PHP, базы, темы и плагинов.

На тестовой копии:

1. Убедитесь, что копия действительно использует ту же базу и набор файлов, но не отправляет реальные письма и не принимает оплату.
2. Переключите PHP на выбранную версию в панели хостинга.
3. Очистите серверный и плагинный кеш, если они есть.
4. Пройдите чек-лист из предыдущего раздела и посмотрите логи ошибок хостинга.
5. Откройте «Здоровье сайта» и сохраните сведения о сервере до и после изменения.

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

Переключите PHP на рабочем сайте

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

После переключения не уходите сразу. Сначала:

1. Откройте сайт в приватном окне и проверьте главную и ключевые страницы.
2. Выполните одну тестовую заявку или другой главный пользовательский сценарий.
3. Войдите в админку, создайте черновик и загрузите тестовый файл.
4. Посмотрите «Инструменты → Здоровье сайта»: нет ли новых критических замечаний.
5. Проверьте журнал ошибок в панели хостинга в ближайшие часы.

Если используете кеш или CDN, очистите кеш только после того, как увидели рабочий сайт на новой версии. Иначе можно надолго раздать посетителям старую ошибочную страницу и запутать диагностику.

Что делать, если сайт сломался

Типичные симптомы после неудачной смены PHP: белый экран, HTTP 500, сообщение о критической ошибке, неработающая форма или часть админки. Не пытайтесь одновременно обновлять плагины, править wp-config.php и менять десяток настроек. Сначала остановите влияние новой переменной.

1. Верните прежнюю версию PHP через панель хостинга. Если доступа нет — обратитесь в поддержку и назовите версию, записанную до работ.
2. Проверьте, вернулась ли работа сайта. Если нет, восстанавливайте проверенный backup.
3. На тестовой копии включите логи хостинга и по одному ищите несовместимые тему или плагин.
4. Обратитесь к разработчику расширения с версией PHP, текстом ошибки и шагами воспроизведения. Не отправляйте ему пароли или бэкап с персональными данными.

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

Короткий чек-лист

• Узнал текущую PHP-версию в «Здоровье сайта».
• Сделал и проверил полный бэкап файлов и базы.
• Обновил WordPress, тему и плагины; проверил сайт.
• Выбрал PHP 8.3+ с учётом поддержки хостинга и теста совместимости.
• Повторил переключение на staging-копии.
• На проде выбрал короткое окно и сохранил путь отката.
• После смены проверил публичные страницы, формы, админку и «Здоровье сайта».
• Отслеживаю ошибки хостинга после работ.

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