Миграция с WordPress на кастомный сайт без потери SEO

Как перенести сайт с WordPress на кастомную разработку без потери SEO-трафика

Переход с WordPress — это не только про дизайн. Если поисковый трафик важен, миграцию нужно начинать со страниц, которые уже приносят клики, лиды и ссылки. Фраза «как перенести сайт с WordPress на кастомную разработку без потери SEO-трафика» звучит длинно, но сама работа вполне практична: сначала защитить то, что уже ранжируется, а потом перестраивать сайт вокруг этих страниц. Такой порядок избавляет от лишней боли позже.

Одна из частых ошибок — считать все URL одинаково важными. У блога с 200 визитами в месяц и у карточки товара, которая приносит 2000 визитов и десяток обратных ссылок, совсем разный вес. Выберите 10, 20 или 50 самых важных URL и зафиксируйте их до начала любых изменений кода. Список маленький, эффект большой.

1. Определите страницы, которые действительно приносят поисковый трафик

Начните с трёх источников: аналитики, Search Console и данных о ссылках. В аналитике найдите посадочные страницы с органическим трафиком за последние 12 месяцев. В Search Console посмотрите запросы, которые дают показы и клики по этим URL. В данных о ссылках отметьте страницы с самыми сильными внешними ссылками, потому что страница с 5 хорошими ссылками может обойти 50 слабых.

Не полагайтесь на память. Страница, которая «кажется» важной, не всегда та, которой больше всего доверяют поисковики. Иногда именно страница, которую вы почти удалили, держит кластер длиннохвостых запросов и тихо поддерживает выручку. Такое случается достаточно часто, чтобы завести таблицу.

Сделайте простую таблицу с четырьмя колонками: текущий URL, органический трафик, основные запросы и заметки о бизнес-ценности. Если у страницы есть сезонная ценность, отметьте месяц. Если страница влияет на внутреннюю навигацию, отметьте и это. Затем отсортируйте список. Для верхнего уровня нужен самый аккуратный подход к миграции сайта с WordPress без потери трафика.

2. Зафиксируйте текущую SEO-базу до любых изменений кода

До того как разработчик коснётся шаблонов, экспортируйте текущее SEO-состояние. Сохраните снимки позиций, количество проиндексированных страниц, ошибки сканирования, canonical, метаданные, внутренние ссылки и URL XML-карты сайта. По возможности просканируйте сайт WordPress инструментом, который сохраняет коды ответа и заголовки страниц. Вам нужен снимок «до», а не смутные воспоминания.

Сохраните данные Search Console за последний отчётный период. Если у сайта есть дневной паттерн трафика, используйте для сравнения один и тот же день недели. Понедельник к понедельнику лучше, чем понедельник к субботе. Такая мелочь помогает избежать ложных тревог.

Также сохраните копию файла robots.txt и текущий индекс sitemap. Эти файлы выглядят скучно, пока не начинают блокировать поисковики от раздела, который вы хотели оставить. Одна строка в robots.txt может повлиять на сотни URL. Один пропущенный URL в sitemap может скрыть целый раздел на недели.

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

3. Составьте план соответствия URL для каждой важной страницы

Теперь сопоставьте каждый важный URL WordPress с новым кастомным URL. По возможности сохраняйте соотношение один к одному. Если старая страница — /services/seo-audit/, новая не должна превращаться в /what-we-do/consulting/audit/, если на это нет веской бизнес-причины. Чистые соответствия уменьшают сложность редиректов и упрощают проверку миграции.

Отдельные случаи требуют дополнительных строк в плане. Страницы пагинации, архивы категорий, страницы с фильтрами, теги, архивы авторов и URL медиа-вложений могут вести себя по-разному. Что-то нужно редиректить на родительскую страницу. Что-то должно оставаться индексируемым. Что-то стоит убрать из поиска совсем. Проверяйте каждый вариант, а не гадайте.

Здесь хорошо помогает таблица. Добавьте столбцы для старого URL, нового URL, кода ответа, типа редиректа, целевого canonical и решения по индексируемости. Затем назначьте ответственного за каждое решение. Разработчик, SEO-лид и контент-редактор должны смотреть в один и тот же файл и понимать, что произойдёт в день запуска.

Для больших сайтов такое сопоставление часто вскрывает неприятные сюрпризы. Страница тега WordPress может ранжироваться по полезной теме, даже если никто этого не планировал. Медиафайл может до сих пор приносить визиты из поиска по картинкам. В плане миграции должны быть и такие страницы, потому что поисковикам всё равно, что страница была «просто остатком».

4. Планируйте редиректы, canonical и сигналы индексации вместе

Одних редиректов недостаточно. Если страница редиректит на новый URL, а canonical указывает в другое место, сигналы становятся грязными. Если страница заблокирована в robots.txt, но при этом есть в sitemap, это тоже создаёт путаницу. Поисковики любят один ясный сценарий. Дайте им его.

Задайте 301-редиректы для каждого старого URL, которому нужен новый адрес. Избегайте цепочек редиректов. Один переход — хорошо. Два — ещё допустимо в крайнем случае. Три — это уже место, где начинают теряться трафик и эффективность сканирования. Для более глубокого технического чек-листа см. как настроить 301 редиректы.

Canonical должен указывать на предпочтительную версию каждой страницы на новом сайте. Если фильтрованная страница должна оставаться индексируемой, зафиксируйте это явно. Если страница с параметрами не должна индексироваться, robots-директива и canonical должны совпадать по смыслу. Смешанные сигналы тратят crawl budget и размывают релевантность страницы.

XML-карты сайта должны содержать только те URL, которые должны индексироваться и возвращать ответ 200. Уберите старые WordPress-URL из sitemap в день запуска, а не через неделю. Sitemap с мёртвыми URL — это как карта с дорогами, которые упираются в стену. Поисковые боты это замечают.

Есть простое правило: если страница важна, дайте к ней один понятный путь. Редиректите старые URL, задавайте canonical на финальный URL и публикуйте именно его в sitemap. Три согласованных сигнала всегда лучше трёх противоречивых.

5. Сохраните on-page SEO-элементы при воссоздании шаблонов

Именно на этапе воссоздания шаблонов многие миграции теряют позиции. Дизайнер меняет иерархию заголовков, потому что так «красивее», или разработчик убирает meta description, потому что он будто бы невидим. Но поисковики всё равно читают эти элементы. А пользователи косвенно — через сниппеты и sitelinks.

Соберите title-теги так, чтобы они оставались уникальными и точными для каждой страницы. Сохраните meta description там, где они по-прежнему соответствуют содержимому. Держите одну понятную структуру H2 или H3 на странице вместо хаотичных скачков заголовков. Если старый WordPress-шаблон использовал описательный H1 и поддерживающие H2, перенесите эту логику в кастомную разработку.

Разметке structured data нужен такой же внимательный подход. Если старый сайт размечал статьи, товары, хлебные крошки или FAQ, проверьте, какие типы schema остаются актуальными в новой версии. Отсутствие schema не всегда обрушивает позиции, но удаление валидного типа страницы может снизить шансы на rich results. Это реальная потеря, даже если её трудно измерить.

Атрибут alt у изображений тоже важен. Если на странице WordPress были изображения, которые получали показы в поиске по картинкам, сохраните описательные и конкретные alt-тексты. Не заменяйте «Встреча команды в Берлине» на «image1». Такое изменение быстро обнулит видимость в поиске по изображениям.

Внутренние ссылки тоже часть on-page картины. Если на важную страницу услуг вели ссылки с главной, футера и трёх связанных статей, сохраните их там, где это имеет смысл. Миграция, которая забывает про внутренние ссылки, часто теряет релевантность, даже если сам контент перенесён правильно.

6. Учтите крайние случаи с контентом и медиа, которые WordPress скрывает

WordPress скрывает удивительно много лишнего. Страницы вложений — классический пример. Они могут создавать тонкие URL, которые поисковики обходят, индексируют, а потом игнорируют. Страницы авторов и теги могут вести себя так же. Если они не полезны, уберите их из индексации или объедините с более сильными страницами.

К медиа-URL нужен особенно аккуратный подход. Отдельный файл изображения мог сам по себе получить трафик, особенно если на сайте есть контент за много лет. Проверьте, должны ли такие адреса оставаться доступными или лучше редиректить их на страницу, где изображение используется. Если у файла есть входящие ссылки, оставить его сломанным — плохая сделка.

Ещё одна ловушка — осиротевший контент. В WordPress страница может оставаться в базе данных ещё долго после того, как она исчезла из навигации. При миграции её легко забыть, потому что никто не видит её в меню. Но поисковики всё ещё могут её видеть. Сделайте выгрузку контента, которая включает каждый публикуемый URL, а не только страницы, которые вы помните по названию.

Для больших редакционных сайтов этап очистки может также выявить дубли или почти дублирующиеся публикации. Часть из них стоит объединить. Другим может понадобиться тег noindex. Принимайте решение на основе трафика, ссылок и релевантности, а не только редакционных предпочтений. Поисковики не сентиментальны.

Если на этом этапе вам нужен дополнительный контекст по безопасности, безопасность сайта стоит пересмотреть до запуска. Миграция — не время оставлять старые файлы, открытые загрузки или слабые права доступа без внимания.

7. Проверьте запуск с помощью QA, ориентированного на поисковые системы

QA нужно проводить дважды: на staging и после запуска. Просканируйте staging-сайт по тем же правилам, которые планируете открыть публично. Проверьте коды ответа, canonical, внутренние ссылки, метаданные и вывод sitemap. Убедитесь, что старые URL WordPress отдают нужный 301-ответ, а целевая страница отвечает 200.

Ищите циклы редиректов, смешанные протоколы и случайные noindex-теги. Страница, которая должна ранжироваться, но помечена noindex, не восстановится сама по себе. Страница, которая редиректит с HTTP на HTTPS, а затем на другой путь, может формально работать для пользователей, но это добавляет риск. Цель — один чистый редирект.

Сравните staging с базой, которую вы зафиксировали ранее. Изменилось ли заметно количество индексируемых URL? Не потеряла ли главная canonical? Остались ли внутренние ссылки на старые слаги? Эти проверки скучные. Но они дешевле, чем падение трафика.

Полезно смотреть QA и через краулер, и глазами. Краулер находит пропущенные теги. Человек замечает странные шаблоны, необычные заголовки и сломанную иерархию контента. Разработчик может решить, что страница в порядке, потому что она загружается. Но поисковики учитывают куда больше, чем просто факт загрузки.

8. Отслеживайте SEO-сигналы после запуска и быстро исправляйте потери

После запуска в первые 2–4 недели ежедневно смотрите Search Console. Отслеживайте покрытие индекса, ошибки сканирования, изменения позиций и трафик на посадочные страницы. Если страница, которая раньше ранжировалась, исчезла из поиска, сначала проверьте редирект, title-тег, canonical и внутренние ссылки.

Некоторые потери простые. Страница могла быть перенаправлена не туда. Некоторые — нет. Раздел мог просесть, потому что слишком много старых URL ведут на общую главную вместо подходящей замены. Поисковики любят точность, а не обходные пути.

Сломанные посадочные страницы заслуживают первоочередного внимания, потому что они могут одновременно потерять и трафик, и конверсии. Если страница с сильными обратными ссылками начала отдавать 404, восстановите её или правильно перенаправьте. Если URL страницы изменился, а старый адрес всё ещё ранжируется, обновите внутренние ссылки, чтобы сайт перестал поддерживать неправильный путь.

Следите и за поведением сканирования. Если Googlebot тратит время на малозначимые URL, ужесточите sitemap и пересмотрите правила индексации. Если вам нужен более широкий взгляд на затраты на измерения после запуска, сколько стоит веб-аналитика поможет спланировать бюджет на мониторинг. Для команд, которые хотят поддерживать новый сайт в хорошем состоянии со временем, сколько стоит обслуживание сайта — полезное дополнение.

И ещё одна привычка сильно помогает: ведите журнал изменений для каждого редиректа, корректировки canonical и обновления шаблона после запуска. Если на 9-й день позиции просядут, вам нужно будет понять, что изменилось на 6-й. Такой журнал превращает панику в диагностику, а диагностику — в исправление, которому можно доверять.