Перевожу сайт с WordPress на сервер с PHP 7.4

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

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

Зачем обновлять, если и так работает

Три причины, и все три измеримые.

Скорость. Восьмая ветка исполняет тот же код заметно быстрее седьмой. На типичном сайте на популярной CMS переход с 7.4 на 8.2–8.4 даёт сокращение времени генерации страницы примерно на 20–35% без единой правки в коде. Это не рекламная цифра, а то, что видно в логах сервера до и после. Для сайта, где страница генерировалась 700 миллисекунд, экономия — около двух сотен миллисекунд на каждом запросе.

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

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

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

Влияет ли это на позиции

Напрямую поисковик не смотрит, какая у вас версия PHP. Он смотрит на то, что из неё следует.

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

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

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

Какую версию выбирать в 2026 году

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

Версия	Состояние на 2026 год	Что делать
7.4 и старше	Мертва несколько лет, обновлений нет	Обновляться немедленно, это вопрос безопасности
8.0 – 8.1	Поддержка закончилась	Планировать переход в ближайший месяц
8.2	Только исправления безопасности, срок на исходе	Приемлемо как временная остановка, не как цель
8.3	Поддерживается, максимум совместимости с плагинами	Безопасный выбор по умолчанию
8.4	Поддерживается, самая долгая перспектива	Хороший выбор, если все компоненты совместимы
8.5	Свежая ветка	Не спешить: часть плагинов ещё не проверена

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

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

Что именно ломается

Полезно понимать не абстрактную «несовместимость», а конкретные типы поломок.

• Удалённые функции. Старый способ работы с базой данных, вырезанный ещё в седьмой ветке, до сих пор встречается в самописных вставках. Сайт падает сразу и полностью.
• Изменения в обработке типов и строк. Восьмая ветка строже: там, где раньше выдавалось предупреждение, теперь бросается ошибка. Это самая частая причина падения на старых плагинах.
• Устаревшие конструкции. Короткие открывающие теги, отключённые в конфигурации, превращают код в текст прямо на странице.
• Заброшенные плагины. Расширение не обновлялось пять лет — оно почти наверняка сломается. Хорошая новость: обычно это ровно то, от чего стоило избавиться.
• Тема оформления. Купленный когда-то шаблон с самописными функциями — вторая по частоте причина после плагинов.
• Внешние библиотеки. Старые платёжные и почтовые компоненты, вставленные разово и с тех пор забытые.

Что проверяем	Риск поломки	Как оценить заранее
Ядро CMS актуальной версии	Низкий	Требования к PHP в описании версии
Популярные плагины с обновлениями	Низкий	Дата последнего обновления и заявленная совместимость
Плагины без обновлений 2+ года	Высокий	Считать несовместимыми, искать замену
Купленная тема со своими функциями	Средний или высокий	Поддержка автора, наличие свежих версий
Самописные вставки и правки в шаблонах	Высокий	Только проверка на тестовой копии
Платёжные и почтовые интеграции	Средний	Документация сервиса, тестовый платёж
Задания по расписанию и выгрузки	Средний	Отдельный запуск после переключения

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

Порядок безопасного обновления

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

1. Полная резервная копия. Файлы и база, скачанные к себе, а не только «бэкап на хостинге». Проверьте, что архив открывается.
2. Инвентаризация. Выпишите текущую версию PHP, версию CMS, список плагинов с версиями и датами последнего обновления. Всё, что не обновлялось больше двух лет, — кандидат на удаление.
3. Обновите CMS, тему и плагины. До обновления PHP, а не после. Половина несовместимостей исчезает на этом шаге.
4. Сделайте тестовую копию. Поддомен или отдельная папка с копией базы. У большинства панелей управления хостингом это делается в пару кликов. Именно тут вы имеете право что-то сломать.
5. Переключите версию на копии. Включите вывод ошибок в лог, а не на экран, и пройдите по сайту.
6. Проверьте сценарии, а не страницы. Оформление заказа, отправка формы, оплата, вход в личный кабинет, загрузка файла, поиск по сайту, работа фильтров, письма-уведомления, административная панель.
7. Прочитайте лог ошибок. Даже если внешне всё работает. Предупреждения об устаревших конструкциях — предупреждение о том, что сломается на следующей версии.
8. Почините или замените проблемные компоненты. Заброшенный плагин чаще выгоднее заменить, чем чинить.
9. Переключите боевой сайт. В будний день утром, а не вечером пятницы и не в разгар сезона.
10. Час наблюдения. Пройдите те же сценарии, проверьте лог, посмотрите на количество ошибок сервера.

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

Если сайт лёг

Спокойно, почти всё чинится в пределах десяти минут. Разбор по симптомам.

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

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

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

Где это переключается и кто это делает

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

О чём стоит знать заранее:

• Версия для сайта и версия для командной строки различаются. Задания по расписанию могут исполняться на другой версии, чем сам сайт. Проверьте отдельно, иначе выгрузки и рассылки тихо сломаются.
• Набор расширений отличается между версиями. После переключения убедитесь, что включены нужные модули для работы с изображениями, шифрованием, архивами.
• Настройки лимитов сбрасываются. Объём памяти, максимальный размер загружаемого файла, время исполнения скрипта — проверьте, что значения соответствуют прежним.
• Кеш байт-кода. На новой версии он может оказаться выключенным, и сайт станет медленнее, чем был. Это первое, что нужно проверить, если после обновления вместо ускорения получилось замедление.
• Кеш сайта. После переключения его надо сбросить, иначе вы будете смотреть на старые сохранённые страницы и делать неверные выводы.

Сколько это стоит, если делать не самому: простое переключение с проверкой у администратора хостинга или подрядчика — 3 000–15 000 ₽. Обновление с исправлением несовместимого кода — 15 000–70 000 ₽ в зависимости от объёма самописных частей. Полноценная тестовая копия у большинства хостеров входит в тариф. Отдельно замечу: если сайту больше семи лет и он весь состоит из индивидуальных доработок, честная оценка иногда звучит как «дешевле сделать новый сайт», и её стоит выслушать без эмоций.

Частые ошибки

• Обновляться сразу на боевом сайте. Экономия получаса против нескольких часов простоя в худшем случае.
• Не иметь копии базы. Файлы обычно восстановить можно, базу — нет.
• Проверять только главную страницу. Ломается то, что сложнее: заказы, оплата, письма, фильтры.
• Обновлять PHP до обновления CMS и плагинов. Порядок имеет значение.
• Переключаться в пятницу вечером или в пик сезона. Классика, за которую платят выходными.
• Игнорировать предупреждения в логе. Сегодня предупреждение, на следующей версии — фатальная ошибка.
• Перепрыгивать через несколько версий раз в пять лет. Чем реже обновляетесь, тем тяжелее каждый переход.
• Оставлять заброшенные плагины ради одной функции. Одна кнопка не стоит дыры в безопасности.
• Забывать про задания по расписанию. Ломаются молча, обнаруживаются через месяц.

Чеклист

1. Посмотреть текущую версию PHP в панели хостинга.
2. Сделать копию файлов и базы, скачать к себе, проверить архив.
3. Обновить CMS, тему, плагины. Удалить неиспользуемое.
4. Создать тестовую копию на поддомене.
5. Переключить версию на копии, включить запись ошибок в лог.
6. Пройти все бизнес-сценарии, а не только просмотр страниц.
7. Прочитать лог целиком, исправить или заменить проблемные компоненты.
8. Переключить боевой сайт утром рабочего дня.
9. Сбросить кеш сайта, проверить кеш байт-кода и лимиты.
10. Проверить версию для заданий по расписанию.
11. Наблюдать за логом и скоростью в течение суток.
12. Записать в календарь проверку версии через год.

Обновление окружения и ускорение сайта входят в техническую доработку. Замерить скорость и найти узкие места поможет бесплатный аудит.

Коротко

• Обновление PHP даёт 20–35% ускорения генерации страниц без правок в коде и закрывает известные уязвимости старых версий.
• Поисковик не смотрит на версию, но смотрит на время ответа сервера и поведение людей — эффект приходит через них.
• Безопасный выбор в 2026 году — 8.3, при контролируемом коде 8.4. Самая свежая ветка на боевом сайте первые полгода не нужна.
• Сначала обновляем CMS, тему и плагины, потом PHP. Обратный порядок ломает сайты.
• Ломаются не CMS, а заброшенные плагины, старые темы и самописные вставки.
• Проверять надо сценарии — заказ, оплату, письма, фильтры, — а не главную страницу.
• Переключение версии обратимо: при поломке первым делом вернуть старую, разбираться потом на копии.
• Лог ошибок указывает конкретный файл и строку. Без лога диагностика превращается в гадание.
• После переключения проверьте кеш байт-кода, лимиты памяти, набор расширений и версию для заданий по расписанию.
• Обновляйтесь на одну ступень раз в год-полтора: редкие большие прыжки — главный источник поломок.
• Работа стоит 3 000–15 000 ₽ при простом переключении и до 70 000 ₽, если в проекте много индивидуального кода.

Если нужно SEO-продвижение сайтов — помогу вывести сайт в топ Яндекса и удержать позиции.