Перенесення PHP-проекту на React/Next.js: стратегії та кейси

Коли PHP-моноліт гальмує: міграція на React/Next.js

Ваш сайт на Laravel почав гальмувати: INP під 300 мс, а на додавання нової сторінки йде тиждень. Ми стикалися з такими проектами десятки разів. Міграція на React/Next.js — не зміна фреймворку, а перегляд архітектури. Next.js з React Server Components (RSC) генерує сторінки в 2-3 рази швидше, ніж чистий PHP-рендеринг, і знижує TTFB вдвічі. Міграція окупається за 6-12 місяців за рахунок зниження витрат на хостинг та розробку. Нижче — реальні стратегії, які ми застосовували на 50+ проектах. Ми гарантуємо збереження SEO-позицій при переїзді. Отримайте консультацію — оцінимо ваш проект за 1 день.

Які проблеми вирішує міграція?

Продуктивність. PHP генерує HTML на сервері кожен запит, що дає високий TTFB. Next.js з RSC віддає статику, а динаміку — потоком. CLS зникає завдяки серверному рендерингу.

Складність підтримки. Шаблони Blade змішують логіку та представлення. React з TypeScript та строгою типізацією знижує кількість багів на 30% за нашими вимірами.

SEO-проблеми. Клієнтські SPA погано індексуються. Next.js вирішує це SSR та ISR. Наприклад, в інтернет-магазину з 5000 товарів ми підняли трафік на 20% після міграції.

Як вибрати стратегію міграції?

Є три підходи, і вибір залежить від розміру проекту та допустимого даунтайму.

Strangler Fig — наш фаворит. Налаштовуємо Nginx так, щоб нові маршрути йшли на Next.js, старі — на PHP. Це виключає простої.

server {
    server_name mysite.com;

    # Нові маршрути → Next.js
    location /blog/ {
        proxy_pass http://nextjs:3000;
    }
    location /about {
        proxy_pass http://nextjs:3000;
    }

    # Старі маршрути → Laravel
    location / {
        proxy_pass http://laravel:8000;
    }
}

Як підготувати проект до міграції

1. Проведіть аудит коду: виявіть точки інтеграції, performance-пляшки, N+1 запити.
2. Визначте стратегію: Strangler Fig для великих проектів, Big Bang — для маленьких.
3. Налаштуйте інфраструктуру: Docker, CI/CD, розділіть оточення.
4. Реалізуйте поетапно: кожен маршрут тестуйте окремо.
5. Виконайте A/B-тестування та деплой.

Перенесення бізнес-логіки: Laravel → Zod + Prisma

Одна з частих помилок — копіювати валідацію «як є». В Laravel вона будується через $request->validate, в React — через Zod. Ми переписуємо з урахуванням типів TypeScript.

// До (Laravel)
// $request->validate([
//   'email' => 'required|email|unique:users',
//   'name'  => 'required|min:2|max:255',
// ]);

// Після (Zod + React Hook Form)
const schema = z.object({
  email: z.string().email('Некорректний email'),
  name:  z.string().min(2).max(255),
});

Запити до БД теж змінюються. Eloquent-запит з N+1 замінюємо на Prisma з включеннями.

// До (Eloquent в Laravel)
// User::where('active', true)->with('posts')->paginate(10);

// Після (Prisma в Next.js API Route)
const users = await prisma.user.findMany({
  where:   { active: true },
  include: { posts: true },
  take:    10,
  skip:    (page - 1) * 10,
});

Шаблони: Blade → React-компоненти

Шаблон Blade з циклом перетворюється на компонент ProductCard. Це покращує підтримуваність.

const ProductCard = ({ product }: { product: Product }) => (
  <div className="product-card">
    <img src={product.imageUrl} alt={product.name} />
    <h3>{product.name}</h3>
    <span>{product.price.toLocaleString('ru-RU')} руб.</span>
    <Link href={`/products/${product.slug}`}>Детальніше</Link>
  </div>
);

Аутентифікація: PHP sessions → NextAuth

PHP-сесії через Cookie замінюємо на JWT-токени NextAuth. Для Laravel API використовуємо Sanctum.

// Next.js: аутентифікація через Laravel Sanctum
import NextAuth from 'next-auth';
import Credentials from 'next-auth/providers/credentials';

export const { auth, handlers } = NextAuth({
  providers: [
    Credentials({
      async authorize(credentials) {
        const res = await fetch(`${process.env.LARAVEL_URL}/api/auth/login`, {
          method: 'POST',
          body: JSON.stringify(credentials),
          headers: { 'Content-Type': 'application/json' },
        });
        if (!res.ok) return null;
        return res.json();
      },
    }),
  ],
});

Що входить в роботу

Ми передаємо повний комплект:

• Документація архітектури та API
• Доступи до репозиторію, CI/CD, хостингу
• Навчання команди роботі з Next.js
• Підтримка 1 місяць після деплою
• Гарантія збереження SEO (100% редиректів, жодних 404)

Терміни та вартість

Вартість розраховується індивідуально після аудиту. Орієнтовні терміни:

Приклад з практики

Інтернет-магазин на CodeIgniter (2000 товарів) мігрували за патерном Strangler Fig. Спочатку переписали каталог, потім кошик, потім особистий кабінет. Підсумок: LCP знизився з 4,2 с до 1,1 с, трафік виріс на 25%. Весь процес зайняв 4 місяці.

Чому варто довірити міграцію нам?

Більше 8 років досвіду в міграціях на React/Next.js. Сертифіковані інженери (React, Next.js, AWS). 50+ успішних проектів. Ми гарантуємо, що ваш сайт не втратить позиції в пошуку. Звертайтеся, щоб отримати детальний аудит вашого PHP-проекту та розрахунок вартості.

Замовте консультацію — проаналізуємо ваш проект та запропонуємо оптимальний план міграції.

Редизайн та міграція сайту: зміна CMS, збереження SEO

Клієнт прийшов через 6 тижнів після самостійного редизайну: «Ми переїхали з WordPress на Tilda, трафік впав на 70%». Відкриваю Google Search Console — 847 сторінок віддають 404, URL-структура повністю змінилася, жодного 301-редиректу. Яндекс ще не переіндексував новий сайт, позиції впали. Відновлення зайняло 4 місяці та призвело до значних фінансових втрат. Наш досвід — понад 7 років та 80+ успішних міграцій. Клієнти, які замовляють професійну міграцію, відновлюють трафік у 3 рази швидше, ніж ті, хто виконує її самостійно.

Чому міграції ламають SEO?

Пошуковики проіндексували конкретні URL. Якщо /catalog/shoes/nike-air-max-270 перетворився на /products/nike-air-max-270 без 301-редиректу — весь посилальний вага сторінки, весь трафік, всі позиції йдуть у нікуди. Google каже, що 301 передає ~99% PageRank, але на практиці позиції відновлюються за 2–8 тижнів, а не миттєво.

Найчастіше SEO ламають не зі злого наміру, а тому що розробник не думає про URL-структуру як про публічний API. Ось типові поломки:

Як відновити трафік після невдалої міграції?

Якщо трафік впав — дійте негайно:

1. Краул нового сайту на 404 та порівняння з передміграційним списком URL.
2. Створення редиректів для всіх втрачених сторінок з трафіком >0.
3. Перевірка структурованих даних та мета-тегів на тестовій вибірці.
4. Щоденний моніторинг Coverage в Search Console та позицій за топ-50 запитами.
5. Якщо через 2 тижні трафік не відновлюється — глибокий аудит редиректів (транзитивність, ланцюжки, цикли).

У нашій практиці такий випадок: великий інтернет-магазин втратив 50% трафіку при переїзді з Бітрікса на React + Strapi. За три дні відновили 95% редиректів, через 3 тижні трафік повернувся на 90% від початкового.

Як підготувати сайт до міграції: що не можна пропустити?

До початку розробки нового сайту потрібно:

1. Повний краул поточного сайту через Screaming Frog або Sitebulb. Отримати список всіх індексованих URL з трафіком з Google Search Console.
2. Вивантажити всі сторінки з органічним трафіком >0 за останні 6 місяців — це пріоритет для редиректів.
3. Зафіксувати всі зовнішні посилання (backlinks) на конкретні сторінки — Ahrefs, Semrush.
4. Сфотографувати поточні позиції за ключовими запитами — база для порівняння після міграції.
5. Зберегти Core Web Vitals з Search Console за попередні 90 днів.

Таблиця для фіксації:

Зв'яжіться з нами для детального передміграційного аудиту — ми допоможемо виявити всі ризики та скласти план дій.

Мапінг URL та редиректи

Для проекту з 200+ сторінками створюємо таблицю мапінгу: старий URL → новий URL → статус (301, об'єднаний з іншою сторінкою, видалений). Кожен рядок проходить перевірку: чи реально контент переїхав саме сюди.

У Laravel редиректи через конфігураційний файл та middleware, не через .htaccess — це швидше та керованіше. Для WordPress → Next.js: редиректи налаштовуються в next.config.js (статичні) та на рівні Nginx/CDN для динамічних. Старий .htaccess на shared хостингу з 500+ рядками редиректів — особливий ад. Кожен редирект перевіряється послідовно, продуктивність падає. Переносимо в Nginx map директиву або Redis-кеш для динамічного пошуку.

Міграція контенту з різних CMS

WordPress → Headless CMS (Contentful, Strapi, Sanity):
WordPress REST API або WP All Export для експорту постів, метаполів, медіафайлів. Скрипт міграції на Node.js: парсимо експорт, трансформуємо структуру, завантажуємо через API CMS. Медіафайли перевантажуємо в нове сховище, оновлюємо посилання в контенті. Типова проблема — shortcodes в контенті WordPress ([gallery id="123"]): потрібен парсер та трансформація в новий формат.

1С-Бітрікс → сучасний стек:
Бітрікс зберігає контент у нестандартних таблицях з IBLOCK_ELEMENT_PROPERTY. Прямий SQL-експорт через phpMyAdmin або Bitrix API. Трансформація — найдовша частина через специфіку структури даних Бітрікса.

Важкі WYSIWYG → структурований контент:
Роки редагування в FCKEditor/TinyMCE залишають inline-стилі, нестандартні теги, зламані атрибути. HTML sanitize + трансформація в Markdown або Portable Text (Sanity) з ручною перевіркою проблемних сторінок.

SEO-збереження технічних елементів

Структуровані дані (Schema.org) — якщо на старому сайті були Product, Article, BreadcrumbList розмітки, вони повинні бути і на новому. Google Search Console → Enhancement reports покажуть втрату rich snippets.

Sitemap XML: генерується автоматично, відправляється в GSC через день після запуску. Старий sitemap залишається до повної переіндексації.

hreflang для багатомовних сайтів: якщо теги загубилися при міграції, через кілька тижнів почнуться конфлікти між мовними версіями у видачі.

Open Graph та Twitter Card мета-теги — часто забувають при зміні шаблону, сторінки перестають коректно відображатися при шарінгу в соцмережах.

Як контролювати сайт після запуску?

DNS propagation: перемикання DNS займає до 48 годин, плануйте запуск із запасом. Cloudflare як DNS-провайдер — propagation займає хвилини, не години.

Після запуску щоденно моніторимо: Search Console → Coverage (помилки індексації), Analytics → органічний трафік, порівняння з аналогічним періодом минулого року, краулінг сайту на 404-помилки.

Перші 2 тижні — критичний період. Якщо трафік падає на 30%+ — негайний аудит редиректів та порівняння з передміграційним краулом.

Що входить в роботу

Результати, які ви отримуєте:

1. План міграції з мапінгом URL та редиректів у форматі Excel/Google Sheets.
2. Налаштовані 301 редиректи на серверному рівні (Nginx/Cloudflare/Vercel).
3. Перенесений контент з перевіркою цілісності: зображення, мета-поля, посилання.
4. Структуровані дані (Schema.org) на новому сайті, ідентичні старим або покращені.
5. Звіт по SEO: динаміка позицій через 1, 3 та 6 тижнів після запуску.
6. Моніторинг Coverage в Search Console з повідомленнями про помилки.
7. Гарантія збереження позицій: якщо трафік падає більш ніж на 15% протягом першого місяця — безкоштовний аудит та корекція.

Терміни та орієнтири

• Редизайн з міграцією невеликого сайту (до 100 сторінок): 4–8 тижнів.
• Міграція e-commerce з 500+ сторінок товарів: 8–16 тижнів.
• Тільки технічна частина міграції (редиректи, метадані) без редизайну: 1–3 тижні.

Вартість розраховується індивідуально за обсягом. Середня економія клієнта за рахунок збереження трафіку після міграції — суттєва сума для бізнесу.

Отримайте консультацію по вашому проекту — ми відповімо протягом дня. Замовте передміграційний аудит вашого сайту та отримайте точний кошторис з планом редиректів. Зв'яжіться з нами, щоб обговорити деталі.