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

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

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

Что реально меняется при переходе на свежий PHP

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

Практический эффект сильнее всего заметен на тяжёлых сайтах. Лендинг на голом шаблоне с тремя плагинами и так генерируется за сотню миллисекунд — ускорять там особо нечего. А вот магазин на WooCommerce с конструктором страниц, фильтрами, калькулятором доставки и тридцатью активными плагинами выполняет на каждый запрос огромный объём кода. Именно там перевод на актуальную ветку даёт заметное сокращение времени генерации — обычно в полтора-два раза, иногда сильнее, но точную цифру всегда показывает только замер на конкретном сайте.

Второй эффект — нагрузка. Меньше процессорного времени на запрос означает, что тот же тариф выдерживает больше одновременных посетителей. На виртуальном хостинге с лимитом CP это прямо переводится в отсутствие писем «вы превысили лимит нагрузки». На VPS — в возможность не переезжать на тариф дороже.

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

Что даёт обновление: таблица без обещаний

Что меняется	За счёт чего	Где эффект виден
Время генерации страницы	Быстрее выполняется тот же PHP-код	Тяжёлые темы, WooCommerce, конструкторы, много плагинов
Нагрузка на процессор	Меньше тактов на один запрос	Лимиты хостинга, пиковые часы, трафик с рассылок
Стоимость размещения	Тот же тариф держит больше запросов	Возможность не повышать тариф при росте трафика
Закрытые уязвимости	Актуальная ветка получает патчи	Общая защищённость, требования аудитов и банков-эквайеров
Совместимость с новым софтом	Свежие плагины требуют минимальную версию	Возможность обновлять WordPress и плагины дальше
Потребление памяти	Оптимизированы внутренние структуры	Импорт товаров, генерация фидов, тяжёлые крон-задачи
Поддержка со стороны разработчиков	Авторы плагинов тестируют на актуальных ветках	Быстрее решаются баги, меньше «у нас это не воспроизводится»

Как скорость сервера связана с позициями

Здесь нужно разделять две вещи, которые постоянно смешивают: время ответа сервера и скорость загрузки страницы у пользователя.

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

А теперь честная часть. Само по себе ускорение генерации страницы в топ не выводит. Скорость — это фактор ранжирования крайне малого веса и, по сути, тай-брейкер: при прочих равных быстрый сайт получит преимущество над медленным, но «прочих равных» в реальной выдаче почти не бывает. Страница, которая хуже отвечает на запрос, не поднимется над более релевантной только потому, что сервер стал отвечать за 200 мс вместо 600.

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

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

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

Причины почти всегда одни и те же, и все они не технические, а организационные.

• Старая тема. Куплена восемь лет назад, автор давно исчез с маркетплейса, обновлений нет. В её коде живут конструкции, которые новые ветки PHP уже не выполняют.
• Платные плагины без действующей лицензии. Лицензия истекла, продлевать никто не стал, обновления не приходят. Плагин работает — значит, не трогаем.
• Самописные вставки в functions.php. Фрагменты, натасканные с форумов за много лет разными подрядчиками. Никто не помнит, что делает каждый кусок, а половина из них написана в стиле, который давно устарел.
• Правки прямо в файлах темы и плагинов. Отдельная беда: обновить нельзя, потому что обновление затрёт правки, а что именно правили — не задокументировано.
• Страх владельца. Сайт приносит деньги, ничего не падает, а подрядчик предлагает «обновить PHP». Владелец слышит риск и не слышит выгоды. И, честно говоря, он прав ровно до тех пор, пока переезд не спланирован по-человечески.
• Хостер, который не заставляет. Пока провайдер не выключил старую ветку принудительно, повода шевелиться нет.

Итог предсказуем: однажды хостинг присылает письмо «через две недели ветка отключается», и переезд делается в панике за один вечер. Именно так и получаются уронённые магазины.

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

Прежде чем что-то менять, соберите исходные данные.

1. Текущая версия PHP. Смотрите в панели хостинга или в админке WordPress: «Инструменты», далее «Здоровье сайта», вкладка «Информация», раздел «Сервер».
2. Версия WordPress и дата последнего обновления ядра.
3. Полный список активных плагинов с версиями и датами последнего обновления автора.
4. Тема и её версия, наличие дочерней темы, наличие правок в файлах родительской.
5. Содержимое functions.php дочерней темы и любых плагинов-сниппетов.
6. Какие ветки PHP вообще предлагает ваш хостинг и до какого срока живёт текущая.

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

Тему разбирал отдельно: «AMP страницы WordPress | Перевожу сайт на AMP и Турбо».

Бэкап: файлы и база, отдельно и проверенно

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

Что важно проверить в самой копии: она разворачивается. Архив, который не открывается, и дамп базы, оборвавшийся на середине из-за таймаута, обнаруживаются ровно в тот момент, когда они нужны. Разверните копию на тестовом поддомене — это и есть проверка бэкапа, и одновременно первый шаг основной работы.

Тестовая копия на поддомене

Порядок такой. Создаёте поддомен вида test.вашсайт.ru, разворачиваете туда файлы и базу, правите адреса сайта, закрываете копию от индексации.

Помогу с продвижением: поисковое продвижение сайта — вывожу сайты в топ Яндекса белыми методами.

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

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

Проверка совместимости: что умеют плагины и чего не умеют

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

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

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

Обновляем ядро, тему и плагины — до переключения версии

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

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

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

Включите лог ошибок, иначе вы работаете вслепую

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

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

Смежный материал по теме — «Какие плагины на WordPress помогут оптимизировать сайт».

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

Прогон ключевых сценариев

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

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

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

Чек-лист перед переключением боевого сайта

Пункт	Как проверить	Что должно быть
Бэкап файлов и базы	Развернуть копию на поддомене	Копия открывается и работает
Копия закрыта от индексации	Открыть поддомен из инкогнито	Запрос логина и пароля
Сканер совместимости пройден	Отчёт плагина проверки	Критичных находок нет либо они устранены
Ядро, тема, плагины обновлены	Раздел обновлений в админке	Пусто или осознанно отложено
Заброшенные плагины разобраны	Список с датами обновлений	Каждый либо заменён, либо удалён, либо принят как риск
Лог ошибок включён	debug.log и журнал хостинга	Файлы пишутся и читаются
Сценарии прогнаны	Формы, корзина, кабинет, оплата	Все проходят, в логе чисто
Замер времени ответа сделан	Одна и та же страница до переезда	Цифра записана для сравнения
Окно работ выбрано	Отчёт по посещаемости по часам	Время минимального трафика, не пятница вечером
Есть план отката	Как вернуть старую версию и файлы	Понятная последовательность на бумаге

Типичные поломки и что они означают

Симптом	Что произошло	Где искать и что делать
Белый экран	Фатальная ошибка, вывод скрыт	Журнал ошибок хостинга или debug.log, там имя файла и строка
Фатальная ошибка в плагине	Плагин вызывает то, чего в новой ветке нет	Отключить плагин через переименование папки, искать обновление или замену
Deprecated в логе	Функция ещё работает, но объявлена устаревшей	Не срочно, но чинить: в следующей ветке она исчезнет
Деление на ноль	Раньше давало предупреждение, теперь исключение	Найти расчёт (часто скидка, рейтинг, пагинация), добавить проверку делителя
Обращение к несуществующему свойству	Объект пришёл без ожидаемого поля	Строка из лога, проверить источник данных и добавить проверку на существование
Ошибка «слишком мало аргументов»	Функция вызвана не полностью	Обычно старый хук или устаревший вызов в functions.php
Слетела вёрстка	Ошибка в теме прервала вывод стилей или разметки	Смотреть исходный код страницы: вывод обрывается на месте ошибки
Админка открывается, сайт нет	Ломается тема, а не ядро	Временно включить стандартную тему и убедиться
Не уходят письма	Плагин отправки несовместим или сменились настройки	Лог плагина рассылки, тестовое письмо, проверка SMTP
Работает, но медленно	Не подключён кэш кода или упал кэш плагина	Проверить наличие OPcache и настройки кэширующего плагина

Общее правило чтения ошибки: в тексте всегда есть три части — тип ошибки, описание и адрес файла со строкой. Адрес файла сразу говорит, чей это код: путь с wp-content/plugins/имя — плагин, wp-content/themes/имя — тема, wp-includes — ядро. Ошибка в ядре при актуальном WordPress почти всегда означает, что настоящую проблему вызвал плагин, а ядро просто оказалось последним в цепочке.

Переключение боевого сайта

Когда копия отработала все сценарии чисто, переключение боевого — это несколько минут. Порядок такой.

1. Свежий бэкап боевого сайта прямо перед работами.
2. Выбрать время минимального трафика. Ночь буднего дня, не вечер пятницы: если что-то поедет, чинить это в выходные придётся вам же.
3. Обновить на боевом ядро, тему и плагины до тех же версий, что на копии. Это делается до смены версии PHP.
4. Переключить версию PHP в панели хостинга.
5. Сбросить весь кэш: плагин кэширования, кэш объектов, кэш сервера, кэш CDN.
6. Пройти ключевые сценарии заново, уже на боевом.

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

Что проверить сразу после переключения

Что проверяем	Чем	Норма
Коды ответа ключевых страниц	curl -sI или онлайн-проверка	200 на страницах, 404 на несуществующих, 301 на склейках
robots.txt	Открыть в браузере	Тот же файл, что был, без запрета на весь сайт
Карта сайта	Открыть sitemap.xml	Отдаётся, содержит актуальные адреса и даты
Формы	Отправить тестовую заявку	Отправляется, приходит письмо, есть запись в базе
Письма	Восстановление пароля, письмо о заказе	Доходят, не падают в спам
Оплата	Тестовый или мелкий реальный платёж	Возврат на сайт, смена статуса заказа
Лог ошибок	debug.log и журнал хостинга	Пусто или только известные безобидные записи
Кэш	Заголовки ответа, повторный запрос	Кэш собирается, страницы отдаются из него
Скорость	Замер времени ответа	Не хуже, чем было до переезда
Поиск и фильтры	Ручной прогон	Выдают результаты, пагинация работает
Изображения и превью	Загрузить картинку в админке	Загружается, генерируются все размеры
Крон-задачи	Список запланированных задач	Выполняются, не копятся просроченные

Первые сутки после переезда держите лог открытым и проверяйте его несколько раз. Часть проблем проявляется только тогда, когда до кода добирается редкий сценарий — например, оформление заказа с конкретным способом доставки.

Как убедиться, что стало быстрее

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

Если нужна помощь по теме — создание сайтов.

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

Второе: измеряйте время ответа сервера, а не общее время загрузки в браузере. Общее время зависит от картинок, скриптов и канала пользователя — на него переезд почти не влияет. Время до первого байта показывает работу PHP напрямую. Проще всего снимать его консольной утилитой, которая выводит тайминги запроса, или в панели инструментов разработчика в браузере — колонка Waiting.

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

Если нужны детали, смотрите «Как продвигать сайт на WordPress».

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

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

Когда переезд не поможет, потому что тормозит не PHP

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

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

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

Чистка базы и кэширование как продолжение работы

Переезд на новую версию PHP логично продолжить двумя вещами, которые дают эффект того же порядка.

Чистка базы. Убираются ревизии записей (их можно ограничить количеством в настройках), удалённые записи из корзины, спамные комментарии, просроченные транзиенты, осиротевшие метаданные от давно удалённых плагинов. После чистки таблицы стоит оптимизировать. Делать это нужно с бэкапом и без фанатизма: плагины-чистильщики с настройкой «удалить всё» умеют выносить нужные данные вместе с мусором.

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

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

Проверить, что именно тормозит ваш сайт, можно на SEO-консультации.

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

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

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

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

Позиции просядут во время переезда?
Если сайт не был недоступен и адреса не менялись — нет, менять там нечего. Проблемы возникают, когда переезд задел что-то ещё: слетел robots.txt, страницы начали отдавать пятисотые коды, пропала карта сайта, тестовая копия попала в индекс. Именно поэтому список проверок после переключения начинается с кодов ответа и robots.

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

Как узнать, на каком хостинге стоит сайт, и почему это важно:

1:30

Коротко

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