Как перенести сайт с WordPress на Astro без потери SEO

Перенос сайта с WordPress на Astro без потери SEO держится на трёх опорах: полная инвентаризация текущих URL и контента до начала работ, точная карта 301-редиректов с permalink-структуры WordPress на файловый роутинг Astro, и перенос контента в Content Collections с типобезопасной схемой вместо реляционной базы данных. При аккуратном исполнении сайт не теряет позиции к 30-му дню после запуска и обычно ускоряется в разы по Core Web Vitals за счёт архитектуры Astro без JavaScript по умолчанию.

По оценке gautamkhorana.com, разбиравшего практику миграций в 2026 году, типовой переезд сайта на 30-100 страниц с WordPress на Astro занимает 6-10 недель и обычно обходится на 30-40% дешевле аналогичного проекта на Next.js - в первую очередь потому что Astro не требует хвостовой JavaScript-инфраструктуры для отдачи статичного контента.

В проектах веб-разработки Exceltic.dev мы регулярно видим одну и ту же причину, по которой команда выбирает именно Astro, а не Next.js, для контентного сайта: у большинства WordPress-сайтов 80-90% страниц - это статичные тексты без интерактивности, и Astro не добавляет туда ни одного лишнего килобайта JavaScript.

Дальше - что теряется при наивном переезде, как устроена архитектура Astro под контентный сайт, пошаговый процесс миграции и реальные диапазоны Core Web Vitals до и после.

Боль здесь ощущает не разработчик, а тот, кто отвечает за органический трафик - CMO или фаундер. WordPress-сайт с 15-20 активными плагинами - это постоянная точка риска: каждое обновление плагина может сломать вёрстку, а каждая неделя простоя из-за уязвимости в устаревшем плагине означает упущенные заявки из поиска. Совет “просто вовремя обновлять плагины” не масштабируется на команду без выделенного технического ресурса - именно поэтому компании ищут архитектуру, где такого риска физически меньше.

Astro: веб-фреймворк для контентных сайтов, который по умолчанию не отправляет в браузер ни строки JavaScript и добавляет интерактивность только там, где она явно нужна - такой подход называется islands-архитектурой.

Почему компании уходят с WordPress на Astro

WordPress - это платформа с серверным рендерингом на каждый запрос: страница собирается через PHP и обращение к базе данных MySQL, если отдельно не настроено кэширование на уровне сервера. При росте трафика или количества плагинов время ответа сервера растёт вместе с LCP.

Astro устроен иначе: HTML собирается один раз на этапе сборки (astro build), а не на каждый визит пользователя. Для сайта, где 80-90% страниц - это блог, документация или маркетинговый контент, такой подход убирает саму причину замедления, а не оптимизирует её постфактум.

Вторая причина - соответствие модели контента. WordPress изначально проектировался вокруг постов и страниц - текста с метаданными. Content Collections в Astro - тот же принцип, но с типобезопасной схемой вместо произвольных полей в базе: ошибка во frontmatter ловится на этапе сборки, а не превращается в пустое поле на проде.

Третья причина - стоимость владения. Managed WordPress-хостинг с приемлемой производительностью (WP Engine, Kinsta) стоит 30-300 долларов в месяц в зависимости от трафика, плюс лицензии платных плагинов. Статичный Astro-сайт на Vercel, Netlify или Cloudflare Pages в большинстве сценариев маркетингового сайта укладывается в бесплатный тариф.

Что теряется, если переезжать на Astro без плана

Наивный переезд - это перенос текстов без карты соответствия URL и без плана на функциональность, которая в WordPress работала через PHP-хуки. Три категории риска здесь специфичны именно для перехода на Astro, а не общие для любой миграции.

Контентная модель. WordPress хранит всё в реляционных таблицах - wp_posts, wp_postmeta, таксономии. При экспорте в Markdown для каждого типа контента нужно спроектировать схему заранее: если не описать кастомные поля ACF (Advanced Custom Fields) явно в схеме коллекции, они потеряются молча при конвертации, а не выдадут ошибку.

Статичный вывод по умолчанию. Формы обратной связи, комментарии, живой поиск, блок похожих статей - в WordPress это работает через PHP на каждый запрос. Astro отдаёт готовый HTML, поэтому такая функциональность требует явной замены: либо сторонним сервисом, либо island-компонентом с явной гидратацией.

Оптимизация изображений. WordPress при загрузке автоматически генерирует несколько размеров каждого изображения. В Astro за это отвечает встроенный компонент <Image /> и модуль astro:assets, который оптимизирует изображения на этапе сборки - но старые прямые ссылки на /wp-content/uploads/... нужно либо сохранить, либо явно редиректить, иначе теряется трафик из Google Images.

Более общий список рисков любой миграции - потеря URL, обратных ссылок, метатегов - разбирали отдельно в статье SEO при миграции сайта.

Что проверить до начала переезда

Аудит перед переездом - это инвентаризация контента, SEO-сигналов и технических интеграций текущего сайта, зафиксированная до первой строки кода на новом стеке. Без него карта редиректов строится по памяти и почти всегда получается неполной.

Для перехода именно на Astro в этом списке важны два дополнительных пункта: полный перечень кастомных полей ACF по каждому типу записи (они станут схемой Content Collections) и список PHP-функциональности плагинов, которая должна получить замену - форма, живой поиск, комментарии, калькулятор.

Подробный чек-лист по часам, применимый к любому переезду вне зависимости от целевого стека, есть в статье аудит сайта перед миграцией.

Как устроена архитектура сайта на Astro

Islands-архитектура - ключевое архитектурное решение Astro: каждая страница по умолчанию рендерится в статичный HTML без JavaScript, а интерактивные элементы (форма, карусель, виджет чата) явно помечаются как острова и гидратируются отдельно, не утяжеляя остальную страницу.

Контент вместо базы данных живёт в Content Collections - типизированной файловой структуре с валидацией через Zod-схему. Ошибка в frontmatter (например, отсутствующая дата публикации) ловится на этапе astro build, а не всплывает пустым полем на проде:

import { defineCollection, z } from 'astro:content';

const blog = defineCollection({
  type: 'content',
  schema: z.object({
    title: z.string(),
    publishedAt: z.date(),
    seoTitle: z.string().max(60),
    seoDescription: z.string().max(155),
    heroImage: z.string().optional(),
  }),
});

export const collections = { blog };

Получение данных из коллекции для генерации страниц идёт через getCollection() - функцию, которая возвращает список записей и опционально фильтрует их по полям схемы.

Для сайтов, где часть страниц требует полноценной клиентской логики - личный кабинет, сложные фильтры каталога - Next.js со своими React Server Components остаётся более подходящим выбором; разницу между этими двумя архитектурами для маркетингового сайта мы разбирали в статье миграция с WordPress на Next.js. Но для сайта, где контент - это 80-90% страниц, Astro даёт тот же результат с меньшим объёмом кода и без хвоста клиентского JavaScript.

Пошаговый процесс миграции с WordPress на Astro

Ниже - последовательность, которая на практике снижает риск потери трафика к минимуму при соблюдении порядка шагов.

Шаг 1. Экспортировать контент из WordPress

Выгрузить контент через встроенный экспорт (Инструменты > Экспорт в панели WordPress, WXR-файл) или через REST API (/wp-json/wp/v2/posts), если нужен более гибкий контроль над полями и пагинацией выгрузки.

Шаг 2. Конвертировать в Markdown и описать схему

Инструмент wordpress-export-to-markdown читает WXR-файл и генерирует Markdown-файлы с frontmatter, попутно скачивая изображения. Шорткоды WordPress при этом не конвертируются автоматически - экспортер выводит их как обычный текст, и их нужно вручную заменить на Markdown-разметку или Astro-компоненты.

Шаг 3. Построить карту редиректов

Сопоставить permalink-структуру WordPress (/category/post-slug/ или /post-slug/ в зависимости от настроек постоянных ссылок) с новой файловой маршрутизацией Astro. Редиректы задаются прямо в конфигурации:

export default defineConfig({
  redirects: {
    '/category/wordpress-tips/[slug]': '/blog/[slug]',
    '/wp-content/uploads/[...path]': '/media/[...path]',
  },
});

Astro отдаёт такие редиректы с кодом 301 для GET-запросов. Есть известный нюанс: встроенный redirects в конфиге не всегда корректно обрабатывает варианты URL с завершающим слэшем и без него - в карте редиректов стоит явно прописывать оба варианта и проверять итоговое поведение на staging до запуска.

Шаг 4. Перенести медиабиблиотеку

Изображения из /wp-content/uploads/ либо копируются в public/ с сохранением исходных путей, либо загружаются в CDN. В обоих случаях изображения на страницах контента стоит явно перевести на компонент <Image /> из astro:assets, чтобы получить автоматическую генерацию srcset и современные форматы (WebP, AVIF) уже на этапе сборки, а не полагаться на плагины вроде Smush.

Шаг 5. Пересобрать функциональность плагинов

Формы обратной связи (Contact Form 7, Gravity Forms) заменяются на island-компонент с отправкой через сторонний сервис форм или собственный API-эндпоинт. Комментарии переносятся на встраиваемый сервис (Giscus, Disqus) или отключаются, если их объём был низким. Блок похожих статей пересобирается логикой на основе тегов коллекции через getCollection(), а не переносится вручную.

Шаг 6. Протестировать на staging и запустить

Прогнать staging-версию через Screaming Frog, сверить с исходным списком URL из аудита, убедиться, что ни одна страница из топ-показов Search Console не отдаёт 404. После переключения DNS - отправить новый sitemap.xml в Google Search Console и запросить переиндексацию для самых трафиковых страниц вручную.

Core Web Vitals до и после переезда на Astro

Core Web Vitals: метрики Google, измеряющие реальную скорость и стабильность страницы для пользователя - LCP (загрузка основного контента), CLS (визуальная стабильность) и INP (отклик на взаимодействие). Пороговые значения “хорошо” по данным web.dev: LCP до 2.5 секунд, CLS до 0.1, INP до 200 мс.

В типовом проекте переноса контентного сайта на 100-300 страниц с WordPress на shared-хостинге на Astro с деплоем на статичный хостинг показатели меняются в следующих диапазонах.

• LCP: с 3.5-5.5 секунд до 0.8-1.8 секунд - за счёт полного исчезновения запроса к базе данных на каждый рендер: страница уже собрана в HTML на этапе сборки.
• CLS: с 0.15-0.3 до 0.01-0.06 - за счёт явных размеров изображений через <Image /> вместо динамически подгружаемых рекламных и виджетных блоков.
• INP: с 300-500 мс до 50-150 мс - за счёт архитектурного отсутствия клиентского JavaScript там, где страница не интерактивна: гидратируются только явно помеченные острова, а не весь документ.

Разработчик Кашиф Азиз в разборе собственного переноса блога описывает результат как идеальные 100 баллов Lighthouse после перехода на Astro - показательный, хотя и не универсальный, пример верхней границы диапазона для простого блога без стороннего трекинга. PageSpeed Insights по мобильному трафику в типовых проектах поднимается с 35-55 до 90-99; точная цифра зависит от объёма стороннего JavaScript (аналитика, чаты, пиксели), который переносится вместе с сайтом.

Типичные ошибки при переезде на Astro

Забыли, что шорткоды не конвертируются. Экспортёры Markdown выводят шорткоды WordPress ([gallery], [contact-form-7]) как обычный текст в квадратных скобках - без ручной замены они остаются мусором на странице.

Не учли завершающий слэш в редиректах. Встроенный механизм redirects в Astro исторически хуже обрабатывает несовпадение URL по завершающему слэшу - если WordPress отдавал /post-slug/, а новый роут настроен без слэша, часть переходов может не срабатывать без явной проверки.

Перенесли изображения без сохранения путей. Если старые прямые ссылки на /wp-content/uploads/2024/03/ не редиректят на новое расположение, теряется трафик из Google Images и рвутся внешние ссылки на картинки с других сайтов.

Не спроектировали схему коллекции заранее. Content Collections валидируют frontmatter по Zod-схеме - если схема написана постфактум, под уже сконвертированные файлы, легко пропустить поле, которое было важным кастомным атрибутом в WordPress.

Оставили автогенерируемые SEO-теги без проверки. Title, description, canonical и Open Graph, которые в WordPress собирал Yoast или Rank Math, в Astro нужно явно прописать в каждой коллекции - иначе страницы уходят в продакшн с дефолтными или пустыми метатегами.

Кому подходит миграция на Astro

Переезд на Astro оправдан для маркетингового или контентного сайта, где подавляющее большинство страниц - это текст: блог, документация, кейсы, лендинги без сложной клиентской логики. Компании от 15-20 сотрудников, у которых WordPress уже упирается в производительность или стоимость поддержки, а команда готова взять разработку контента через Markdown-файлы в репозитории вместо визуального редактора, получают максимум выгоды от архитектуры.

Хуже подходит сценарий, где сайту нужны сложные интерактивные разделы - личный кабинет, многошаговые формы с состоянием, каталог с десятками фильтров. Такую логику Astro тоже умеет реализовать через острова, но объём кастомного кода в этом случае сближается с Next.js, и выбор чаще смещается в его сторону.

Часто задаваемые вопросы

Сколько времени занимает миграция с WordPress на Astro?

Для сайта на 50-100 страниц с типовым набором контента миграция обычно занимает 4-8 недель, включая аудит, разработку, тестирование и наблюдение за индексацией после запуска. Сайты с нестандартной функциональностью плагинов - калькуляторы, сложные фильтры, личные кабинеты - требуют больше времени на воссоздание логики как island-компонентов, а не на перенос текста.

Что будет с позициями в Google сразу после переезда?

При корректной карте редиректов и сохранённых технических сигналах краткосрочная просадка обычно минимальна - Google обрабатывает 301-редиректы в течение нескольких дней-недель. Более заметное и длительное падение возникает, если часть URL остаётся без редиректа или если завершающий слэш в новых маршрутах не совпадает со старой permalink-структурой.

Можно ли оставить WordPress как источник контента, а Astro использовать только для фронтенда?

Да, это рабочий вариант headless-связки: WordPress остаётся привычной панелью для редакторов, а Astro забирает контент через REST API или WPGraphQL на этапе сборки. Этот путь снимает часть рисков конвертации контента, но не снимает зависимость от PHP-инфраструктуры и связанных с ней уязвимостей.

Astro или Next.js - что выбрать для переезда с WordPress?

Если 80-90% сайта - это статичный контент без сложной интерактивности, Astro обычно даёт более быстрый результат с меньшим объёмом кода за счёт islands-архитектуры. Next.js более оправдан, если на сайте есть значительная клиентская логика - личный кабинет, динамические дашборды, авторизация. Подробное сравнение архитектур мы разбирали в статье о миграции с WordPress на Next.js.

Как перенести формы и комментарии на статичный Astro-сайт?

Форма реализуется как island-компонент, который отправляет данные на сторонний сервис форм или на собственный serverless-эндпоинт - сама форма остаётся интерактивной, но окружающая её страница статична. Комментарии обычно переносятся на встраиваемый сервис вроде Giscus, который хранит данные во внешней системе и подгружается отдельным island-компонентом, не требуя серверной части на стороне Astro.

Что делать дальше

• Проведите аудит текущего сайта: полный список URL, кастомные поля ACF, PHP-функциональность плагинов, требующая замены.
• Спроектируйте схему Content Collections до конвертации контента, а не после - это защитит от молчаливой потери кастомных полей.
• Постройте карту редиректов с учётом завершающего слэша и протестируйте её на staging до переключения DNS.
• Замените статичную функциональность плагинов (формы, комментарии, related posts) island-компонентами или сторонними сервисами заранее, а не в последний момент перед запуском.

Если вы сейчас оцениваете переезд с WordPress на Astro - опишите команде Exceltic.dev объём сайта и список ключевой функциональности на плагинах. Разберём карту рисков миграции именно под Astro и дадим честную оценку сроков.