Руководство по SEO-миграции: Как сменить платформу без потери рейтинга (2026)

Переходите ли вы с WordPress на пользовательский PHP, с Shopify на WooCommerce или с любой платформы на другую – риски одинаковы: потеря трафика, падение рейтинга и битые ссылки. Я мигрировал более 30 сайтов – от небольших блогов до интернет-магазинов на 500 000 страниц – и точно узнал, что сохраняет (и часто улучшает) SEO-ценность. Следуйте этому руководству, чтобы избежать распространенных ошибок.

Почему миграции терпят неудачу – Суровая правда

• Изменение структур URL без реализации перенаправлений 301.
• Потеря метаданных (теги заголовков, метаописания, канонические теги).
• Разрыв внутренних ссылок из-за новых шаблонов URL.
• Запуск без тестирования перенаправлений в стейджинг-среде.

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

Фаза 1: Предмиграционный аудит – Зафиксируйте свой SEO-базис

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

1. Просканируйте весь ваш сайт

Используйте Screaming Frog SEO Spider (бесплатно до 500 URL) для извлечения:

• Все внутренние URL (включая изображения, PDF и т.д.).
• Теги заголовков, метаописания и H1 для каждой страницы.
• Канонические теги.
• Коды ответа (200, 301, 404).
• Внутренние и внешние ссылки.

Экспортируйте сканирование в CSV. Это станет вашим главным списком сопоставления URL.

2. Запишите позиции для 50 лучших ключевых слов

Используйте Google Search Console (отчет о производительности) или платный инструмент, такой как SEMrush/Ahrefs. Экспортируйте позиции ключевых слов, показы и CTR за последние 3 месяца.

3. Задокументируйте уровни органического трафика

В Google Analytics (или GA4) запишите последние 30 дней органических сеансов, показателя отказов и данных о конверсиях. Сделайте скриншоты. Вы сравните их после запуска.

4. Скачайте все обратные ссылки

Google Search Console → Ссылки → Внешние ссылки → Экспорт. Сохраните список ссылающихся доменов и страниц. Вам нужно будет убедиться, что эти старые URL правильно перенаправляются.

5. Сохраните XML-карту сайта

Если на вашем старом сайте есть карта сайта (например, `/sitemap.xml`), скачайте ее. Это быстрый список всех индексированных URL.

Фаза 2: Сопоставление URL – Самый критический шаг

Если вы сохраните те же самые пути URL, вы избежите большинства рисков миграции. Но часто вы захотите очистить URL (удалить даты, сократить категории). Создайте сопоставление 1:1 каждого старого URL с его новым эквивалентом.

Примеры правил сопоставления:

<code>/2023/01/why-custom-php → /blog/why-custom-php<br>/category/web-design → /services/web-design<br>/product?id=123 → /products/widget-name<br>/contact-us → /contact (оставьте таким же, если возможно)</code>

Инструменты для создания файла сопоставления:

• Ручной Excel/Google Sheets – для небольших сайтов (<500 URL).
• Скрипт Python с regex – для больших сайтов.
• Экспорт из CMS + формулы электронных таблиц – если у вашей новой платформы есть шаблон.

Сохраните сопоставление как CSV с колонками: old_url, new_url.

Фаза 3: Реализуйте перенаправления 301

Перенаправление 301 сообщает Google: «Эта страница постоянно перемещена». Google передает почти 100% ранжирующей силы старой страницы новому URL. Никогда не используйте перенаправления 302 (временные) для постоянных перемещений.

Вариант A – Apache .htaccess (лучше для < 200 перенаправлений)

<code>Redirect 301 /old-url /new-url<br>Redirect 301 /2023/01/why-custom-php /blog/why-custom-php</code>

Вариант B – PHP-карта перенаправлений (лучше для тысяч перенаправлений)

<code>&lt;?php<br>$redirects = json_decode(file_get_contents(__DIR__ . '/redirects.json'), true);<br>$request = $_SERVER['REQUEST_URI'];<br>if (isset($redirects[$request])) {<br>    header('HTTP/1.1 301 Moved Permanently');<br>    header('Location: ' . $redirects[$request]);<br>    exit;<br>}<br>?&gt;</code>

Вариант C – Nginx (используйте `map` для множества перенаправлений)

<code>map $request_uri $new_uri {<br>    /old-url      /new-url;<br>    /old-url2     /new-url2;<br>}<br>server {<br>    if ($new_uri) {<br>        return 301 $new_uri;<br>    }<br>}</code>

Важное правило: Никаких цепочек перенаправлений – Никогда не делайте A → B → C. Каждый переход теряет небольшое количество веса ссылки. Всегда перенаправляйте напрямую A → C.

Фаза 4: Сохраните метаданные – Теги заголовков, Метаописания, Канонические теги

Ваш новый сайт должен выводить точно такие же теги заголовков и метаописания, как и старый сайт (или лучше).

• Если вы используете CMS (WordPress, Shopify), экспортируйте метаданные через плагин или CSV.
• Если вы создаете пользовательский PHP-сайт, храните метаданные в таблице базы данных или в PHP-массиве с ключом по URL.

Пример реализации на пользовательском PHP:

<code>&lt;?php<br>$pageMetadata = [<br>    '/services/web-design' => [<br>        'title' => 'Пользовательский веб-дизайн | BuiltToWinWeb',<br>        'description' => 'Сайты на PHP, написанные вручную, которые набирают 100 в Lighthouse.'<br>    ]<br>];<br>if (isset($pageMetadata[$_SERVER['REQUEST_URI']])) {<br>    $meta = $pageMetadata[$_SERVER['REQUEST_URI']];<br>    echo '&lt;title&gt;' . htmlspecialchars($meta['title']) . '&lt;/title&gt;';<br>    echo '&lt;meta name="description" content="' . htmlspecialchars($meta['description']) . '"&gt;';<br>}<br>?&gt;</code>

Фаза 5: Протестируйте все в стейджинг-среде

Перед запуском клонируйте ваш сайт на стейджинг-поддомен (например, `staging.yourdomain.com`). Протестируйте:

• Все перенаправления – используйте Screaming Frog для сканирования старых URL и проверки, что они возвращают 301 на новые URL.
• Метаданные – проверьте выборку страниц на правильность заголовков и описаний.
• Внутренние ссылки – нет битых ссылок на старые URL.
• Core Web Vitals – запустите Lighthouse. Если показатели хуже, чем на старом сайте, выполните отладку.

Фаза 6: День запуска – Переключите DNS и отправьте карту сайта

1. Направьте DNS на ваш новый сервер (TTL должен быть заранее установлен на 300 секунд).
2. Немедленно отправьте вашу новую XML-карту сайта в Google Search Console (Карты сайта → Добавить).
3. Используйте инструмент «Проверка URL», чтобы получить страницу как Google и запросить индексацию для ваших самых важных страниц.
4. Отслеживайте логи в реальном времени на предмет ошибок 404 (используйте просмотрщик логов сервера или такой инструмент, как LogHound).

Фаза 7: Мониторинг после запуска – Первые 30 дней

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

Ежедневные проверки (первая неделя):

• Google Search Console → Покрытие → Ошибки. Есть 404? Исправьте их немедленно (добавьте недостающие перенаправления).
• Google Analytics → В реальном времени, чтобы убедиться, что трафик попадает на новый сайт.

Еженедельные проверки (2‑4 недели):

• Сравните органический трафик с предмиграционным базисом (Google Analytics). Небольшое падение (5‑10%) нормально; любое большее указывает на проблему.
• Повторно запустите отчет по основным ключевым словам. Если позиции упали для конкретных страниц, проверьте, правильно ли перенаправляются эти URL.
• Отслеживайте 404 обратных ссылок – используйте Ahrefs или GSC, чтобы увидеть, не сломались ли внешние ссылки.

Если вы видите падение:

• Проверьте, не заблокировали ли вы случайно robots.txt или не добавили теги `noindex`.
• Убедитесь, что новый сайт быстрее (Core Web Vitals). Улучшения скорости часто компенсируют небольшие потери при перенаправлении.
• Повторно отправьте карту сайта и используйте «Проверить URL» на нескольких ключевых страницах.

Распространенные ошибки миграции (и как их избежать)

• Ошибка: Переход с HTTP на HTTPS без перенаправления всех HTTP-URL. Решение: Добавьте глобальное перенаправление HTTP→HTTPS на уровне сервера.
• Ошибка: Миграция на новый домен и отсутствие обновления свойства Google Search Console. Решение: Добавьте новый домен как свойство и отправьте смену адреса.
• Ошибка: Потеря URL изображений (битые изображения). Решение: Сохраните ту же структуру пути для `/wp-content/uploads/` или создайте перенаправления для URL изображений.
• Ошибка: Внутренние ссылки, указывающие на старые URL (жестко закодированные). Решение: Выполните поиск и замену в вашей базе данных или кодовой базе перед запуском.

Пример из практики: Миграция интернет-магазина на 50 000 страниц – 0% потери трафика

Крупный онлайн-ритейлер перешел с Magento на пользовательскую PHP-платформу. Задача: 50 000 URL товаров должны были измениться с `/catalog/product/view/id/123/` на `/products/widget-name/`.

Процесс:

• Экспорт всех старых URL из базы данных Magento.
• Генерация новых SEO-дружественных слагов на основе названий товаров.
• Создание CSV-сопоставления с 50 000 строк.
• Использование PHP-карты перенаправлений (JSON-файл) для обработки 301 – без раздувания .htaccess.
• Сохранение всех метаданных (заголовков, описаний) путем их хранения в пользовательской таблице с ключом по новому URL.
• Стейдинг и тестирование перенаправлений с помощью краулера – покрытие 99,8%.

Результаты:

• Нулевая потеря органического трафика в первые 30 дней.
• Через 60 дней трафик увеличился на 12% благодаря более быстрой загрузке страниц (пользовательский PHP против Magento).
• Ни одной ошибки 404 в Search Console после первой недели.
• Доход от органического поиска вырос на 18% в течение 3 месяцев.

Теперь клиент владеет кодом, не платит лицензионные сборы Magento и может мгновенно обновлять URL.

Контрольный список миграции (Резюме для печати PDF)

• ☐ Предмиграция: краулинг, позиции, трафик, обратные ссылки, карта сайта.
• ☐ Сопоставление URL: CSV 1:1 старого → нового.
• ☐ Реализовать перенаправления 301 (без цепочек).
• ☐ Сохранить метаданные (заголовки, описания, канонические теги).
• ☐ Протестировать в стейджинге (краулинг Screaming Frog, Lighthouse).
• ☐ Запуск: DNS, отправить карту сайта, проверить URL.
• ☐ Ежедневно мониторить GSC в течение 30 дней, исправлять 404.
• ☐ Через 30 дней сравнить позиции и трафик.

Готовы к миграции без стресса?

Я мигрировал более 30 сайтов – от небольших бизнес-блогов до корпоративного электронной коммерции. Я беру на себя весь процесс: сопоставление URL, реализацию перенаправлений, миграцию метаданных, тестирование в стейджинге и мониторинг после запуска. Вы сохраните свои позиции и часто увидите повышение производительности.

Давайте поговорим о вашей миграции. Я предоставлю бесплатный, ни к чему не обязывающий план миграции и смету.

Данные из реальных миграций клиентов, выполненных BuiltToWinWeb. Индивидуальные результаты могут варьироваться в зависимости от сложности сайта и существующего SEO-здоровья.