?>

Мигрируйте с WordPress на кастомный PHP без потери SEO – Полное руководство в 7 шагах

Переход с WordPress на кастомный PHP снижает TTFB на 70%, устраняет уязвимости плагинов и даёт 100% владение кодом. Но если неправильно настроить редиректы и метаданные, позиции обвалятся. Я мигрировал более 30 сайтов на WordPress – вот точный процесс, который сохраняет (и часто улучшает) SEO.

Зачем мигрировать с WordPress на кастомный PHP?

• Медленная производительность – Даже с кэшированием WordPress загружает 847 КБ+ JavaScript.
• Уязвимости плагинов – 96% взломанных сайтов WordPress скомпрометированы из-за устаревших плагинов.
• Ежемесячные расходы – Премиум-плагины, хостинг под WordPress и обслуживание суммируются.
• Зависимость – Вы не владеете кодом; вы владеете базой данных постов и темой.

Кастомный PHP даёт полный контроль, загрузку менее секунды и нулевые ежемесячные платформенные сборы. Но миграция должна быть безупречной.

Перед началом: аудит перед миграцией

• Экспортируйте все URL – Используйте Screaming Frog (бесплатно до 500 URL) или wget: wget --spider --force-html -r -l 3 https://yoursite.com 2>&1 | grep '^--' | awk '{ print $3 }' > urls.txt
• Зафиксируйте позиции – Экспортируйте топ-100 ключевых слов из Google Search Console (отчёт «Эффективность»).
• Сохраните метаданные – Screaming Frog может экспортировать теги заголовков, мета-описания и H1 в CSV.
• Задокументируйте обратные ссылки – Используйте Search Console → Ссылки → Внешние ссылки или Ahrefs/SEMrush при наличии.

Шаг 1: Обходите старый сайт (подробно о Screaming Frog)

Загрузите Screaming Frog SEO Spider (бесплатно до 500 URL). Настройте для извлечения:

1. Всех внутренних URL.
2. Тегов заголовков и мета-описаний.
3. Канонических тегов.
4. Заголовков H1.
5. Кодов ответа (200, 301, 404).

Экспортируйте в CSV. Этот файл станет вашей картой миграции. Вы будете использовать его для проверки того, что у каждой существующей страницы есть назначение.

Шаг 2: Сопоставьте URL с новой структурой — по возможности оставьте идентичными

Самый безопасный подход: сохранить те же пути URL. Если ваши URL WordPress чистые (например, /services/web-design), их можно переиспользовать. Меняйте структуру только если:

• Ваши URL WordPress содержат /2023/01/post-name/ (даты) – уберите даты.
• У вас дублированный контент из архивов /category/ и /tag/ – откажитесь от них.

Пример маппинга для блога:

/2023/01/why-custom-php → /blog/why-custom-php
/category/performance → /blog/category/performance (необязательно, можно убрать страницы категорий)
/tag/seo → (убрать – страницы тегов часто размывают авторитет)

Создайте CSV с двумя колонками: old_url, new_url. Для страниц, которые вы не воссоздаёте (например, архивы тегов), сделайте редирект на ближайшую релевантную страницу.

Шаг 3: Экспортируйте контент из WordPress

Метод A – WP REST API (проще всего для небольших сайтов)

<code>&lt;?php<br>$posts = json_decode(file_get_contents('https://yoursite.com/wp-json/wp/v2/posts?per_page=100&page=1'));<br>foreach ($posts as $post) {<br>    $data = [<br>        'title' => $post->title->rendered,<br>        'slug' => $post->slug,<br>        'content' => $post->content->rendered,<br>        'excerpt' => $post->excerpt->rendered,<br>        'date' => $post->date,<br>        'meta' => [<br>            'title' => get_post_meta($post->id, '_yoast_wpseo_title', true),<br>            'description' => get_post_meta($post->id, '_yoast_wpseo_metadesc', true)<br>        ]<br>    ];<br>    // Вставьте в кастомную таблицу MySQL<br>}<br>?&gt;</code>

Метод B – WP CLI (быстрее всего для крупных сайтов)

<code>wp export --dir=/tmp --post_type=post,page --with_attachments</code>

Метод C – Прямой MySQL (для полного контроля)

<code>SELECT ID, post_title, post_name, post_content, post_date FROM wp_posts WHERE post_status = 'publish' AND post_type IN ('post', 'page');</code>

Затем получите метаданные Yoast SEO из wp_postmeta, где meta_key IN ('_yoast_wpseo_title','_yoast_wpseo_metadesc').

Шаг 4: Перестройте кастомный PHP-сайт с теми же метаданными

• Точно такой же тег <title> (из Yoast или All in One SEO).
• Такое же <meta name="description">.
• Такой же <h1> (хотя небольшое изменение обычно допустимо).

Храните метаданные в вашей базе данных (например, таблица page_meta) или в PHP-массиве. Для динамических сайтов можно даже оставить базу данных WordPress в режиме только для чтения во время перехода — но это добавляет сложность.

Шаг 5: Настройте 301 редиректы (самый критичный шаг)

Редирект 301 сообщает Google: «Эта страница перенесена навсегда». Google передаёт почти 100% ранжирующей силы старой страницы на новый URL.

Для Apache (.htaccess) – лучше всего при менее 200 редиректах

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

Для тысяч редиректов – используйте PHP-карту (не раздувайте .htaccess)

<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>

Для Nginx – используйте директиву map

<code>map $request_uri $new_uri {<br>    /old-url /new-url;<br>    /2023/01/why-custom-php /blog/why-custom-php;<br>}<br>server {<br>    if ($new_uri) {<br>        return 301 $new_uri;<br>    }<br>}</code>

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

Шаг 6: Создайте динамическую XML-карту сайта

Не используйте статическую карту сайта – она устареет. Вместо этого создайте sitemap.php, который динамически генерирует XML:

<code>&lt;?php<br>header('Content-Type: application/xml');<br>echo '&lt;?xml version="1.0" encoding="UTF-8"?&gt;';<br>echo '&lt;urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"&gt;';<br>$pages = getAllPageUrlsFromDatabase(); // ваша кастомная функция<br>foreach ($pages as $url) {<br>    echo '&lt;url&gt;&lt;loc&gt;' . htmlspecialchars($url) . '&lt;/loc&gt;&lt;lastmod&gt;' . date('Y-m-d') . '&lt;/lastmod&gt;&lt;/url&gt;';<br>}<br>echo '&lt;/urlset&gt;';<br>?&gt;</code>

Затем добавьте правило перезаписи в .htaccess:

<code>RewriteRule ^sitemap\.xml$ sitemap.php [L]</code>

Сразу после запуска отправьте карту сайта в Google Search Console.

Шаг 7: Запуск и мониторинг в течение 30 дней

1. Проверьте все редиректы – Используйте краулер (Screaming Frog), чтобы посетить каждый старый URL и убедиться, что он возвращает 301 на новый URL.
2. Ежедневно следите за отчётом «Покрытие» в Google Search Console – Ищите ошибки 404. Для каждой ошибки добавьте недостающий редирект или исправьте неработающую ссылку.
3. Отправьте новую карту сайта – В Search Console перейдите в Карты сайта → Добавить новую карту сайта (sitemap.xml).
4. Следите за Core Web Vitals – В течение недели вы должны увидеть улучшение. Если нет, отлаживайте изображения, CSS или конфигурацию сервера.
5. Сравните позиции через 4 недели – Снова экспортируйте данные GSC. Большинство клиентов видят либо отсутствие изменений, либо небольшое улучшение из-за более быстрой загрузки.

Распространённые ошибки и как их избежать

Ошибка 1: Изменение URL без редиректов

Симптом: ошибки 404 в Search Console.

Решение: Внедрите PHP-карту редиректов до запуска.

Ошибка 2: Забытые мета-описания при миграции

Симптом: Google заменяет ваш сниппет случайным текстом.

Решение: Используйте тот же экспорт метаданных из шага 1.

Ошибка 3: Потеря изображений (медиафайлов)

Симптом: Битые изображения на кастомном сайте.

Решение: Скопируйте всю папку /wp-content/uploads/ в публичный каталог вашего нового сайта. Настройте редирект с /wp-content/uploads/... на /uploads/..., если вы переместили папку.

Ошибка 4: Предупреждения о смешанном контенте (HTTP-изображения)

Симптом: Браузер показывает «небезопасное содержимое» на HTTPS.

Решение: Найдите и замените старые URL изображений в вашей базе данных с http://oldsite.com на https://newsite.com.

Реальный кейс клиента: Миграция бизнес-сайта на 500 страниц

Национальная франчайзинговая сеть имела сайт на WordPress с 500+ страницами локаций, каждая с уникальным контентом. Время загрузки составляло 2,8 с (мобильный), и они платили 300$/месяц за хостинг и плагины.

Процесс:

• Экспортировали все данные локаций с помощью WP CLI.
• Пересоздали кастомный PHP-сайт с единым PHP-шаблоном, подтягивающим данные локаций из MySQL.
• Сохранили структуру URL идентичной (/locations/city-state/).
• Использовали PHP-карту для 301 редиректов (хотя URL не изменились, карту сохранили для надёжности).

Результаты через 60 дней:

• TTFB: 800 мс → 180 мс.
• Lighthouse performance: 58 → 96.
• Стоимость хостинга: $300/мес → $30/мес (стандартный VPS).
• Позиции: Улучшились для 87% страниц локаций (благодаря скорости).
• Органический трафик: +23% за 3 месяца.

Клиент теперь полностью владеет кодом, не платит за плагины и может мгновенно добавлять новые локации через простую загрузку CSV.

Стоит ли мигрировать? Система принятия решений

Мигрируйте на кастомный PHP, если:

• Ваш сайт преимущественно статический или имеет предсказуемый контент (блог + услуги).
• Вы устали от обслуживания плагинов и обновлений безопасности.
• Вы хотите 100% владение кодом и никаких ежемесячных платформенных сборов.

Оставайтесь на WordPress, если:

• Вам нужен продвинутый e-commerce (хотя кастомный PHP с этим справится).
• Вы сильно зависите от расширений WooCommerce.
• Ваша команда нетехническая и привыкла к панели WP.

Готовы сделать переход?

Я мигрировал более 30 сайтов на WordPress на кастомный PHP – от небольших блогов до интернет-магазинов с 2000 страницами. Я беру на себя всё: экспорт контента, маппинг URL, 301 редиректы, сохранение метаданных и мониторинг после запуска.

Ваш кастомный PHP-сайт будет загружаться менее чем за 0,8 с, наберёт 100 в Lighthouse, и вы никогда больше не заплатите за плагины.

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