Ко мне обычно приходят не с абстрактным «хотим на Laravel», а с конкретной болью: сайт на Tilda оброс скриптами настолько, что его боятся трогать, WooCommerce-магазин тормозит на пяти тысячах товаров, самописный PHP пятилетней давности некому поддерживать. Когда решаешь перенести сайт на Laravel, разработка обычно упирается не в сам фреймворк, а в детали - забытые интеграции, скрипты, о которых никто уже не помнит, и позиции в поиске, которые легко потерять за одну неаккуратную миграцию. Ниже чек-лист, по которому я закрываю такие проекты на практике - без потери функционала и трафика.
Когда перенос сайта на Laravel окупается, а когда нет
Laravel имеет смысл, когда сайту нужна собственная логика: личный кабинет с ролями, интеграция с 1С или ERP, API для мобильного приложения, нестандартный расчёт цен или статусов заказа. Если каталог растёт, а WooCommerce начинает тормозить на десятках тысяч товаров и конфликтующих между собой плагинах - это тоже повод переезжать. Отдельная причина - когда на сайте накопилось несколько разрозненных систем: интернет-магазин, личный кабинет, партнёрский раздел - и их пора собрать в одном бэкенде с общей базой.
Если сайт - лендинг без сложной логики, переезд не окупится. Сайт на Tilda стоит от 30 000 ₽ и решает задачу быстрее, а бэкенд на Laravel - это отдельная разработка от 100 000 ₽, и её смысл появляется там, где логики действительно много. На старте проекта я всегда прошу описать сценарии работы сайта, а не просто «хотим современный стек» - часто выясняется, что хватит доработки текущей платформы, и клиент экономит и время, и бюджет.
Аудит перед тем как перенести сайт на Laravel: что выписать в первую очередь
Перед тем как писать первую строчку кода, я собираю список всего, что должно продолжить работать после переезда. Без этого шага теряются именно те мелочи, из-за которых потом приходится оправдываться перед клиентом на живом проекте.
В аудит попадает:
- все страницы и маршруты, включая те, что не в главном меню - акции, лендинги под рекламу, страницы благодарности;
- формы и то, куда уходят данные - CRM, почта, Telegram, Google Таблицы (для персональных данных клиентов нужны сервисы с серверами в РФ - это требование 152-ФЗ, а не рекомендация);
- интеграции: эквайринг, СДЭК или другая служба доставки, SMS-шлюз, аналитика;
- кастомные скрипты - доработки на Tilda, самописные плагины WordPress, JS-виджеты;
- права доступа и роли пользователей;
- cron-задачи и фоновые обработчики;
- SEO: структура URL, метатеги, файл robots.txt, sitemap.
Для среднего сайта на 50-200 страниц аудит занимает 3-5 рабочих дней. Для крупного магазина с ERP-интеграцией - до двух недель, потому что часть логики приходится вытаскивать из головы прежнего разработчика по кусочкам.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Что чаще всего теряют при переезде на Laravel и как этого избежать
Самые частые потери при переносе - не в дизайне и не в текстах, а в интеграциях, которые работали «по умолчанию» и о которых никто не вспоминал, пока они не сломались.
Оплата и эквайринг (T‑Bank и аналоги)
При переносе WooCommerce-магазина с оплатой через T‑Bank я в первую очередь выношу логику вебхуков и статусов заказа отдельно от остального кода - в Laravel это обычно events и listeners с очередью на случай, если платёжка ответит с задержкой. На одном из проектов заказы терялись шесть часов просто потому, что старый вебхук продолжал стучаться в мёртвый адрес после переключения DNS. Теперь перед финальным переключением я всегда прогоняю тестовые платежи в песочнице на новом домене.
Доставка и СДЭК
СДЭК на старых сайтах обычно зашит в плагин или кусок кода, который никто не трогал с момента установки - расчёт тарифа, статусы, забор груза. При переносе я выношу это в отдельный сервис-класс с очередью и повторными попытками при обрыве API, чтобы одна ошибка на стороне службы доставки не роняла оформление заказа целиком.
Скрипты Tilda и кастомные доработки
Если сайт уезжает с Tilda, кастомные JS-обработчики - валидация форм, доработки зеро-блоков, интеграции с внешними сервисами - приходится переписывать под контроллеры и Blade или Vue-компоненты Laravel. Часть таких доработок у меня уже готова в виде библиотеки готовых скриптов - по ней удобно свериться, что из типовых вещей точно нужно перенести, а не изобретать заново.
Уведомления и боты
Если на старом сайте заказы падают в Telegram через бота на aiogram, переписывать его на PHP смысла нет. Бот остаётся отдельным сервисом, а Laravel просто дёргает его webhook или кладёт задачу в очередь, из которой бот забирает уведомления. То же самое с автоматизацией в n8n - если там уже настроены сценарии на дублирование заявок в CRM, их проще подключить к новому API, чем пересобирать логику внутри самого Laravel.
База данных и SEO: перенос без просадки трафика
Схему в Laravel я описываю миграциями с нуля, но данные переношу отдельной командой импорта, а не руками через phpMyAdmin. У старых записей - из WordPress, Tilda-экспорта или инфоблоков Битрикса - сохраняю исходный ID во внешнем поле, чтобы при расхождениях можно было сверяться с оригиналом.
php artisan make:command ImportLegacyCatalog
php artisan legacy:import --source=woocommerce --dry-runФлаг - dry-run я использую всегда: команда прогоняется, показывает, сколько записей будет создано или пропущено, и только после сверки с реальными числами запускается импорт в боевом режиме.
Для SEO - отдельная таблица соответствий старых и новых адресов, из которой middleware отдаёт 301. После переключения DNS проверяю всё краулером (хватает и бесплатной версии Screaming Frog), ищу ссылки, которые отдают 404 вместо редиректа, и донастраиваю их вручную. Просадка позиций почти всегда случается не из-за смены технологии, а из-за забытых страниц без редиректа - поисковик просто не находит контент там, где ждал его найти.
| Платформа-источник | Что чаще всего теряется при переносе | Критичность |
|---|---|---|
| Tilda | JS-скрипты, зеро-блоки, кастомные формы | Высокая |
| WooCommerce | Хуки оплаты, статусы заказов, купоны и скидки | Высокая |
| WordPress (кастом) | Плагины, шорткоды, кастомные поля ACF | Средняя |
| 1С-Битрикс | Инфоблоки, права доступа, событийная модель | Высокая |
Чек-лист тестирования перед запуском Laravel-версии
- стейджинг с копией продакшен-базы и реальными объёмами данных, а не тестовыми тремя товарами;
- тестовые платежи в песочнице эквайринга на новом домене;
- проверка всех форм и уведомлений - почта, SMS, Telegram, CRM;
- нагрузочная проверка очередей на реальном объёме задач;
- проверка 301-редиректов по полному списку старых адресов;
- актуальный robots.txt и пересобранный sitemap.xml;
- бэкап старой базы прямо перед переключением DNS;
- мониторинг ошибок первые 48 часов после запуска.
На переходный период я иногда подключаю n8n как страховку: сценарий дублирует новые заявки в старую систему и в Laravel одновременно несколько дней, пока не убедишься, что новый бэкенд ничего не роняет, - потом сценарий просто отключается.
Сроки и стоимость разработки при переносе на Laravel
Аудит занимает 3-5 дней для среднего сайта и до двух недель для крупного магазина с ERP. Сама разработка бэкенда на Laravel начинается от 100 000 ₽ - в эту сумму входит перенос основной логики и интеграций из аудита. Если помимо переноса нужна доработка конкретного модуля, например, отдельная интеграция с CRM или переработка расчёта доставки, она считается отдельно от базовой стоимости.
По срокам: лендинг или небольшой каталог с редиректами и базовыми интеграциями переезжает за 3-6 недель. Крупный магазин с ERP, несколькими способами оплаты и десятками тысяч товаров - от двух до четырёх месяцев, с поэтапным тестированием каждого блока перед переключением. После запуска обычно нужна техподдержка на первое время - от 15 000 ₽/мес, пока не отловлены хвосты, которые не проявились на стейджинге.
API и серверная часть под SPA
API / Бэкенд
от 100 000 ₽
Подробнее →Частые вопросы
Можно ли перенести сайт на Laravel без остановки продаж?
Да, если готовиться заранее. Я переключаю DNS в ночное окно с минимальным трафиком, оставляю старый сайт доступным в режиме только для чтения ещё двое суток и слежу за заказами вручную первые часы после переключения. Если что-то идёт не так, откат на старый домен занимает минуты, а не часы.
Что будет с позициями сайта в поиске после переезда?
При правильно настроенных 301-редиректах и сохранённых метатегах заметной просадки обычно нет - поисковик переиндексирует новые адреса за одну-две недели. Проблемы начинаются, когда часть старых URL забыли занести в таблицу редиректов - тогда трафик по этим страницам действительно теряется, и его приходится возвращать заново.
Нужно ли переписывать Telegram-бота или рассылки при переезде на Laravel?
Нет, если бот уже работает стабильно - например, написан на aiogram. Проще оставить его отдельным сервисом и подключить к новому бэкенду через webhook или очередь, чем переписывать логику бота на PHP ради унификации стека.
Сколько по времени занимает весь перенос сайта на Laravel?
Зависит от объёма: лендинг или небольшой каталог - 3-6 недель, крупный магазин с интеграциями и ERP - от двух до четырёх месяцев. Точный срок появляется только после аудита, потому что до него не видно всех скрытых интеграций и зависимостей между модулями.