Модернизация старого PHP-сайта: пошаговый план

Почему старый PHP-сайт становится проблемой

Пока сайт «просто работает», кажется, что трогать его не нужно. Однако технический долг растёт незаметно. Версии PHP, на которых он написан, давно сняты с поддержки: для них больше не выпускают исправления безопасности. Любая найденная уязвимость остаётся открытой навсегда, а взломанный сайт может попасть под фильтры Яндекса и Google и получить пометку об опасности в выдаче.

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

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

Что вы получаете в результате

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

Начинаем с аудита, а не с кода

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

Параллельно собирается SEO-срез: список всех индексируемых URL, данные о посещаемости из Яндекс Метрики и Google Analytics, позиции по ключевым запросам, статус индексации в Яндекс Вебмастере и Google Search Console. Этот «слепок» потом служит точкой сравнения: по нему вы поймёте, не просели ли показатели после запуска.

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

Как выглядит результат

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

Рефакторинг, переписывание или переезд на CMS

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

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

Переписывание на фреймворке (например, Laravel или Symfony) оправдано, когда старый код нельзя ни тестировать, ни расширять, а сайт содержит сложную логику: личные кабинеты, интеграции с CRM, расчёты. Это дороже и дольше, но результат живёт годами.

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

Как сохранить SEO при обновлении

Для бизнеса главный страх — потерять поисковый трафик. Он оправдан: при смене структуры сайт может «просесть» на месяцы. Но этого можно избежать, если относиться к SEO как к полноценной части проекта, а не к задаче «потом».

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

Второе — перенести всё, что влияет на ранжирование: заголовки title и описания, заголовки H1–H3, тексты, атрибуты alt у изображений, канонические адреса, микроразметку schema.org. Третье — обновить sitemap.xml и проверить robots.txt: на стадии разработки сайт нередко закрывают от индексации, и после запуска директиву забывают убрать.

После релиза добавьте обновлённую карту сайта в Яндекс Вебмастер и Google Search Console, следите за отчётами об ошибках индексации и за динамикой в Яндекс Метрике и Google Analytics. Скорость загрузки и стабильность верстки (Core Web Vitals) тоже учитываются поисковиками, а чёткая структура страниц и разметка помогают нейропоисковикам — Яндекс Нейро, Алисе, Perplexity и ChatGPT — находить в тексте прямые ответы и ссылаться на вас.

Тестирование и запуск

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

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

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

После запуска: наблюдение и поддержка

Релиз — не финал. В первые две-четыре недели следите за журналами ошибок сервера, отчётами Яндекс Вебмастера и Google Search Console, а также за посещаемостью и конверсиями в Метрике и Analytics. Небольшие колебания позиций после технических изменений — нормальное явление, а вот резкое падение трафика требует срочной проверки редиректов, индексации и скорости.

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