Как переписать сайт на Laravel: план миграции без потерь

Когда переписывание оправдано, а когда нет

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

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

Если же сайт — простая визитка на 5–10 страниц, которая отлично работает, переписывание на фреймворк, скорее всего, лишнее. Laravel раскрывается там, где есть бизнес-логика: личные кабинеты, каталоги, заказы, интеграции с CRM и платёжными системами, API для мобильного приложения.

Что проект получает от Laravel

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

Отдельная ценность — экосистема и предсказуемость. Консольная утилита Artisan генерирует шаблоны кода, миграции хранят историю изменений структуры БД в репозитории, а шаблонизатор Blade отделяет вёрстку от логики. Актуальные версии фреймворка требуют современный PHP (8.2 и выше), а значит, вы автоматически уходите от устаревшей среды выполнения.

SEO при переносе: что нельзя потерять

Самый частый страх при смене технологии — «слетят позиции». Он оправдан, если миграцию делают без SEO-плана. Для поисковых систем сайт — это набор адресов с контентом, ссылками и историей. Яндекс и Google не интересует, на чём написан бэкенд. Их интересует, что по старым URL по-прежнему отдаётся тот же полезный контент с кодом ответа 200.

Поэтому до начала разработки нужно выгрузить полную карту существующих адресов: из sitemap.xml, из аналитики (Яндекс Метрика и Google Analytics), из отчётов Яндекс Вебмастера и Google Search Console, а также краулером. Для каждого URL фиксируются title, description, заголовок H1, canonical и код ответа. Эта таблица станет эталоном, с которым вы будете сверять новый сайт.

Если часть адресов неизбежно меняется, для них настраивается постоянный редирект 301 на новый аналог. Laravel позволяет делать это на уровне маршрутов или middleware, а при большом количестве правил — через конфигурацию веб-сервера. Отдельно переносятся robots.txt (включая директиву Clean-param, которую понимает Яндекс), sitemap.xml, микроразметка и счётчики аналитики.

Как перенести данные и не сломать пользователей

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

Особое внимание стоит уделить пользователям. Если на старом сайте пароли хранились в слабых хэшах вроде MD5, Laravel не обязан их принимать навсегда. Распространённое решение: при первом входе проверить пароль по старой схеме, а затем сохранить его в современном формате. Пользователям не придётся ничего сбрасывать, а безопасность вырастет.

Медиафайлы лучше переносить вместе с исходной структурой путей или сразу настраивать редиректы со старых адресов изображений и документов. Иначе внешние ссылки, а также картинки в поиске по картинкам Яндекса и Google начнут отдавать ошибку 404.

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

Новую версию сайта нужно показывать только тем, кто её проверяет. Тестовый стенд закрывают базовой авторизацией, а не только директивой в robots.txt: так он гарантированно не попадёт в индекс Яндекса и Google. Это важная деталь, потому что случайно проиндексированный staging создаёт дубли контента и путаницу в выдаче.

На стенде проверяют три слоя. Первый — функциональность: автотесты на Pest или PHPUnit покрывают регистрацию, оформление заказа, формы обратной связи и права доступа. Второй — SEO: краулер обходит новый сайт и сравнивает коды ответа, мета-данные и внутренние ссылки с эталонной таблицей. Третий — производительность: замеряют время ответа, число запросов к базе (помогает отладчик вроде Laravel Debugbar или Telescope) и поведение под нагрузкой.

Где чаще всего ошибаются

Технически перенос на Laravel — это решаемая задача. Большинство проблем возникает не в коде, а в организации процесса: не учли SEO, не описали требования, пытались одновременно переписать и «улучшить» всё подряд. Разберём типичные ловушки и способы их обойти.