Планируем перенос сайта, URL и контента так, чтобы снизить риск потери органического трафика при редизайне, смене CMS или переходе на новую архитектуру.
До запуска фиксируем индексируемые страницы, ценные URL, новую структуру, redirect, canonical, sitemap, внутренние ссылки и план проверки после релиза.
Аудит и план миграции — от 100 000 ₽. Полный перезапуск сайта оценивается после инвентаризации текущей структуры.
SEO-миграция нужна, если существующие страницы уже индексируются, получают переходы или должны быть корректно перенесены в новую структуру.
Сайт нужно обновить визуально или структурно, но часть страниц уже приводит посетителей и заявки. Мы инвентаризируем текущие URL, определяем страницы, которые нельзя потерять, проектируем новую структуру и готовим карту перехода до разработки нового сайта.
Существующий сайт переезжает на новую CMS или frontend-архитектуру. Мы собираем текущую структуру страниц и метаданных, определяем правила переноса, готовим redirect для изменяющихся URL и проверяем техническую доступность нового сайта для поисковых систем.
Компания пересобирает направления, страницы услуг, региональные посадочные или языковые версии. Мы определяем, какие URL сохранить, какие перенести, какие объединить и какие убрать из новой структуры; готовим redirect, canonical, sitemap и hreflang там, где он нужен.
После запуска изменились URL, появились 404, потерялись страницы, redirect настроены неполно или поисковые системы получают некорректные сигналы. Мы проводим техническую диагностику, составляем список исправлений и восстанавливаем корректную структуру обхода и перенаправлений там, где это возможно.
Минимальный необходимый контур — инвентаризация URL, решение по каждой важной странице, redirect для изменяющихся адресов и проверка после запуска.
Собираем индексируемые и доступные URL, sitemap, страницы с органическими переходами, ключевые метаданные, внутренние ссылки, ответы сервера и ошибки обхода. При наличии доступов используем данные Search Console, Яндекс Вебмастера и аналитики клиента.
Для каждой важной страницы фиксируем решение: сохранить URL, перенести на новый URL, объединить с другой страницей или убрать из новой структуры. Для изменяющихся адресов готовим карту постоянных redirect и проверяем, что новая страница соответствует назначению старой.
Проверяем indexability публичных страниц, метаданные, canonical, robots, sitemap, внутренние ссылки, redirect и hreflang при наличии языковых версий. Производительность и Core Web Vitals учитываем как часть технического качества и сравниваем с текущей версией на ключевых шаблонах.
После запуска проверяем redirect, 404, sitemap, canonical, доступность ключевых страниц, формы и аналитику. При наличии доступов отслеживаем сообщения и изменения в Google Search Console и Яндекс Вебмастере. Период проверки и формат отчётности фиксируются в scope проекта.
Передаём карту URL и redirect, технический чек-лист запуска, описание canonical и sitemap-логики, список проверок после релиза и документацию по контентной структуре, если новая версия сайта входит в scope.
Если действующий URL уже соответствует новой странице и имеет ценность, его можно сохранить. Если структура мешает развитию сайта, адрес можно изменить с корректным redirect на релевантную новую страницу. Решение принимается отдельно по ключевым страницам, а не одинаково для всего сайта.
Не все старые страницы должны автоматически переехать в новую структуру. Для каждой значимой страницы проверяем назначение, трафик, контент и место в новой архитектуре. Удаление или объединение страниц фиксируется до запуска вместе с redirect-логикой.
После релиза проверяем ответы сервера, redirect, 404, canonical, sitemap, внутренние ссылки и формы. При наличии доступов отслеживаем данные Search Console, Яндекс Вебмастера и аналитики. Проверка после запуска нужна для поиска технических ошибок, а не как гарантия сохранения текущих позиций.
Финальная оценка зависит от количества индексируемых страниц, объёма изменений URL, CMS, контента, языковых версий и необходимости разработки новой версии сайта.
Инвентаризация текущих страниц, решение по ключевым URL, redirect-логика, технические риски и scope следующего этапа.
Для сайта услуг или небольшого B2B-сайта, где нужно перенести страницы, форму обращения и базовую SEO-структуру на новую реализацию.
Для B2B-сайта или сайта услуг с несколькими направлениями, посадочными страницами, CMS и более сложной внутренней структурой.
Для сайта с большим количеством индексируемых страниц, несколькими разделами, языковыми версиями или существенным изменением информационной архитектуры.
Для сайта, где после релиза появились массовые 404, неправильные redirect, ошибки canonical, исчезнувшие страницы или другие технические проблемы миграции.
Для сайтов, которым после миграции нужна техническая проверка новых ошибок, redirect, sitemap, indexability, форм и аналитики.
До редизайна и разработки собираем текущие страницы, метаданные, внутренние ссылки и данные об органических переходах, если они доступны клиенту.
Страница может сохранить адрес, переехать, объединиться с другой или быть исключена из новой структуры. Решения фиксируются до запуска и проверяются после публикации.
Redirect, canonical, robots, sitemap, hreflang, внутренние ссылки и доступность страниц проверяются как часть запуска, а не после появления проблем.
Если сайт приводит заявки, проверяем не только обход страниц, но и работу форм, аналитики и передачи обращений после перезапуска.
Карта URL, правила redirect, список проверок и техническая документация передаются клиенту для дальнейшей поддержки сайта.
Несколько решений, которые часто создают проблемы при переносе сайта. У нас — нет.
Каждый — реальный проект из нашей практики. Подробности по техническим решениям и архитектуре — в самих кейсах.
Платформа гибких офисов с публичным каталогом, статически сгенерированными страницами объектов, динамическим sitemap, JSON-LD structured data и метаданными на каждой публичной странице. Стек: Next.js App Router, TypeScript, Supabase.
Открыть кейс→
B2B-платформа с публичным сайтом, кабинетом клиента и рабочим пространством команды. Публичный слой собран с SEO-структурой под запросы о финансировании и контентные кластеры. Стек: Next.js, TypeScript, Neon/PostgreSQL.
Открыть кейс→
Цифровая платформа адвокатской практики. Публичный слой собран под профильные юридические запросы со структурированным входом в обращение, метаданные и schema на ключевых страницах. Стек: Next.js, TypeScript, Neon, Prisma.
Открыть кейс→
SaaS для динамических QR-связанных страниц с маркетинговым сайтом, регистрацией и продуктовым слоем. Стабильные публичные URL с edge-кэшированным рендерингом, ограничение функций по тарифу на сервере. Стек: Next.js, TypeScript, Supabase.
Открыть кейс→Нет. Поисковые системы самостоятельно переобходят и переоценивают страницы после изменений. Наша задача — снизить технические риски: сохранить важные URL там, где это разумно, корректно настроить redirect для изменившихся адресов, перенести необходимые метаданные и контент, проверить canonical, sitemap, внутренние ссылки и доступность ключевых страниц после запуска.
Если на сайте есть индексируемые страницы, по которым уже идут переходы из поиска или приходят заявки. В этих случаях редизайн или смена CMS без подготовки увеличивают риск технических ошибок, ломающих обход и индексацию. Если органического трафика практически нет, отдельная миграция может не понадобиться — достаточно базового технического контроля при запуске нового сайта.
Для каждого значимого URL фиксируется решение: сохранить адрес, перенести на новый URL, объединить с другой страницей или убрать из новой структуры. Для изменяющихся адресов готовится список постоянных redirect, проверяется соответствие новой страницы назначению старой и отсутствие лишних цепочек. Карта документируется и применяется на уровне сервера или фреймворка.
Да. Если действующий адрес уже соответствует новой странице и имеет ценность для обхода и переходов, его можно сохранить. Решение принимается отдельно по ключевым страницам, а не одинаково для всего сайта.
Удаляемые страницы получают постоянный redirect на наиболее близкую по смыслу новую страницу или, при отсутствии релевантной альтернативы, корректный ответ 410. Объединяемые страницы переезжают на одну консолидированную новую страницу с redirect со всех предыдущих адресов. Решения по удалению и объединению фиксируются на этапе карты миграции.
Да. Мы анализируем структуру текущего сайта, метаданные и контент, готовим правила переноса, redirect для изменяющихся URL и проверяем техническую доступность нового сайта для поисковых систем после запуска. Конкретный целевой стек обсуждается отдельно под задачу клиента.
Ответы сервера на ключевые URL, redirect, 404, canonical, sitemap, внутренние ссылки, доступность ключевых страниц, работа форм и аналитики. При наличии доступов отслеживаются сообщения и изменения в Google Search Console и Яндекс Вебмастере. Период проверки и формат отчётности фиксируются в scope.
Да. Формат «Аудит и карта миграции» от 100 000 ₽ — это самостоятельная услуга. На выходе вы получаете список значимых URL, карту решений по страницам, redirect-логику для изменяющихся адресов и список технических рисков. Документ остаётся у вас и может использоваться с любой командой разработки.
Проверим текущие страницы, определим, какие URL сохранять или переносить, зафиксируем redirect, canonical, sitemap и проверки после релиза. Если отдельная миграция не нужна и достаточно точечной доработки текущего сайта, скажем об этом до начала проекта.
