Какой PHP нужен WordPress в 2026 году и что даёт переход на 8.3

Какой PHP нужен WordPress в 2026 году, владельцы сайтов обычно выясняют после письма от хостинга о принудительном отключении старой версии. До этого момента переключатель в панели никого не интересует, хотя стоит на нём чаще всего цифра из позапрошлой эпохи: сайты, собранные пять-семь лет назад, до сих пор работают на 7.4, которая перестала получать даже исправления безопасности в конце 2022 года.

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

Какие версии PHP поддерживаются сейчас

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

Версия	Статус на 2026 год	Что это значит для сайта
5.6 и ниже	Мертва много лет	Несовместима с современным ядром, уязвимости не закрываются
7.0–7.3	Мертвы	Работает, но без исправлений безопасности; часть плагинов уже не ставится
7.4	Мертва с конца 2022	Самая распространённая «старая» версия на хостингах, обновлять в первую очередь
8.0	Мертва с конца 2023	Переходный вариант, задерживаться на нём смысла нет
8.1	Поддержка безопасности завершена	Рабочий минимум для старых сайтов, но уже не цель
8.2	Только исправления безопасности	Приемлемо, если 8.3 не заводится
8.3	Актуальна	Оптимальный выбор: поддержка есть, совместимость проверена массово
8.4 и новее	Свежая	Годится, если все плагины заявили поддержку; на боевом сайте — после проверки

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

Что реально меняется в скорости

Здесь много преувеличений, поэтому по механике. Основной прирост между семёркой и восьмёркой дала не одна оптимизация, а несколько изменений в устройстве интерпретатора.

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

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

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

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

Отсюда вывод, который часто игнорируют: если сайт тормозит, обновление PHP — не первое, что надо делать. Сначала проверяются кэширование, время ответа базы, вес изображений и число плагинов. Какие серверные параметры влияют на скорость сильнее версии интерпретатора, разобрано в материале 9 серверных проверок, которые влияют на ранжирование сильнее, чем перелинковка, а куда уходит время до первого байта — в разборе Хостинг быстрый, а сайт тормозит: куда исчезает секунда до первого байта.

Зачем тогда обновляться

Скорость — не главная причина. Главных три.

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

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

Стоимость отката. Разрыв между 7.4 и 8.3 больше, чем между 8.1 и 8.3. Чем дольше вы стоите на месте, тем дороже прыжок: за один раз придётся чинить и синтаксические изменения, и убранные функции, и поведение, изменившееся между версиями.

Как проверить совместимость до переключения

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

Шаг 1. Инструмент состояния сайта. В админке WordPress есть раздел с диагностикой. Он показывает текущую версию PHP, наличие нужных расширений и предупреждения об устаревших компонентах. Это первое, что надо открыть.

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

Шаг 3. Сканер совместимости. Есть плагины, которые проходят по коду темы и плагинов и ищут конструкции, несовместимые с целевой версией. Инструмент неидеальный: он даёт ложные срабатывания на динамических вызовах и не видит проблем, возникающих только в момент выполнения. Считайте его подсказкой, а не гарантией.

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

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

Что проверяем	Как	Признак проблемы
Текущая версия и расширения	Раздел состояния сайта в админке	Предупреждения об устаревших компонентах
Заброшенные плагины	Дата последнего обновления в списке	Обновления нет два года и более
Код темы и плагинов	Плагин-сканер совместимости	Ошибки уровня fatal в отчёте
Реальная работа	Копия сайта с новой версией PHP	Белый экран, пропавшие блоки, ошибки в логе
Формы и оплата	Ручной проход сценария на копии	Форма отправляется, но письмо не приходит
Скорость до и после	Замер времени до первого байта на копии	Время выросло — ищите отключившийся кэш

Порядок обновления

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

1. Полная копия. Файлы и база данных, выгруженные и скачанные к себе, а не «снимок в панели хостинга». Проверьте, что копия действительно скачалась и открывается.
2. Обновить плагины и тему на текущей версии PHP. Свежие версии почти всегда уже совместимы с новой версией интерпретатора. Обновляться сразу и по коду, и по окружению — верный способ не понять причину поломки.
3. Обновить ядро WordPress. Тоже на старой версии PHP.
4. Удалить лишнее. Неактивные плагины и неиспользуемые темы удаляются, а не отключаются: они всё равно остаются на диске и остаются точкой входа для взлома.
5. Переключить PHP на копии сайта и пройти сценарии.
6. Переключить на боевом сайте в момент минимального трафика — обычно раннее утро буднего дня.
7. Проверить сразу после переключения: главная, три-четыре внутренние страницы, форма, админка, журнал ошибок.
8. Сбросить кэш — плагина кэширования, серверный, если он есть, и объектный. Без сброса вы будете смотреть на старые страницы и не увидите ни поломок, ни улучшений.

Отдельно про версии-ступеньки: прыгать с 7.4 сразу на 8.3 можно, если тестовая копия прошла проверку. Если она валится, есть смысл идти лесенкой — сначала 8.1, убедиться, что всё живо, потом 8.2 и 8.3. Так проще локализовать плагин-виновника.

Что делать при белом экране

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

Порядок разбора:

• Откатите версию назад. Сначала сайт работает, потом ищем причину.
• Включите вывод ошибок в лог. В wp-config.php ставится режим отладки с записью в файл и без вывода на экран — посетители ничего не увидят, а вы получите точное сообщение с именем файла и номером строки.
• Прочитайте лог. В нём указан конкретный файл: путь вида /wp-content/plugins/nazvanie/ прямо называет виновника.
• Отключите виновника через файловую систему. Если админка недоступна, плагин отключается переименованием его папки по FTP или в файловом менеджере — WordPress перестанет его загружать.
• Найдите замену. Заброшенный плагин чинить бессмысленно: ищите живой аналог или реализуйте нужную функцию в теме.

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

Почему хостинги держат старые версии

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

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

Ещё один момент — режим работы PHP. На современных площадках это обычно FPM, на старых встречается модуль Apache. Разница влияет на потребление памяти и на скорость под нагрузкой сильнее, чем номер версии. Если в панели есть выбор, берите FPM.

Когда обновление не решит проблему

Смена версии PHP — не универсальное лекарство, и вот случаи, где она не поможет.

Сайт тормозит из-за базы. Разросшаяся таблица настроек с автозагрузкой, тысячи ревизий записей, мусор от удалённых плагинов, отсутствие индексов. Интерпретатор тут ни при чём — время уходит на ожидание ответа базы.

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

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

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

Сайт не растёт по другим причинам. Версия PHP не является фактором ранжирования. Она влияет на скорость, скорость влияет на поведение людей и на объём обхода, и уже через эту цепочку — на результат. Прямой связи «обновил PHP — вырос в выдаче» не существует, и рассчитывать на неё не стоит.

Чеклист перед переключением

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

Если сайту много лет, а трогать его страшно, разумнее не переключать вслепую, а сначала посмотреть, что вообще внутри: какие плагины живы, что с базой, где узкое место по скорости. Такой разбор с последующей аккуратной правкой — это техническая доработка сайта; работы веду лично, без передачи проекта менеджерам. Если задача шире и нужен результат в поиске, а не только обновление окружения, смотрите, как устроено SEO-сопровождение сайта.

Частые вопросы

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

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

Нужно ли предупреждать поисковые системы? Нет, это внутреннее изменение окружения. Никаких уведомлений, переобходов и заявок не требуется.

Сколько памяти выделять? Для обычного сайта хватает 256 мегабайт на процесс, для магазина с большим каталогом — 512. Лимит задаётся в конфигурации PHP или в wp-config.php; ошибка об исчерпании памяти прямо указывает на этот параметр.

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

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

Коротко

• Живые версии на 2026 год — 8.2 и выше, целевая для WordPress — 8.3; 7.4 и 8.0 не получают даже исправлений безопасности.
• Главный аргумент за обновление — безопасность и совместимость с плагинами, а не скорость.
• Прирост скорости даёт не JIT, а общие оптимизации интерпретатора; на сайте с рабочим кэшем разница может быть незаметна.
• Проверка совместимости делается на копии сайта — сканер кода даёт подсказку, но не гарантию.
• Порядок: копия, обновление плагинов и ядра на старой версии, удаление лишнего, переключение на копии, потом на боевом, сброс кэша.
• Белый экран лечится откатом версии за минуту, а виновник находится в журнале ошибок по имени файла.