Как перенести или переделать сайт и не потерять поисковый трафик

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

Поэтому кратковременные колебания позиций возможны даже после аккуратного переноса. Это не означает, что падение неизбежно или что любую потерю трафика можно списать на «переоценку сайта». Большинство серьёзных просадок связано с конкретными ошибками: исчезнувшими страницами, неправильными редиректами, запретом индексации, потерянным контентом или сломанной аналитикой.

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

Что считается переносом сайта

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

• Смена хостинга или сервера. Адреса и содержание остаются прежними, но меняются инфраструктура, скорость ответа, доступность и условия обхода сайта.
• Переход на HTTPS или изменение основного варианта домена. Например, с http на https либо с www на версию без www.
• Смена домена или поддомена. Старые адреса полностью заменяются новыми, поэтому поисковику нужно перенести накопленные сигналы между ними.
• Смена CMS или технологии. Например, переход с конструктора или самописной системы на WordPress либо Next.js.
• Изменение структуры URL. Даже при сохранении домена страницы получают новые адреса, а старые должны быть правильно сопоставлены с ними.
• Редизайн или полная переработка. Меняются шаблоны, HTML, навигация, внутренние ссылки, расположение контента и иногда сами страницы.
• Объединение, разделение или реорганизация сайтов. Несколько доменов или разделов могут собираться в один проект либо, наоборот, расходиться по разным площадкам.

Простой перенос между хостингами обычно безопаснее, чем одновременная смена домена, CMS, структуры и контента. Но даже инфраструктурная миграция требует проверки: сайт может отвечать медленнее, отдавать ошибки части пользователей или стать недоступным для поискового робота.

Почему перенос влияет на позиции, даже когда всё сделано аккуратно

Поисковая система хранит не абстрактное представление о компании, а сведения о конкретных адресах и документах. Она знает, какой URL был доступен, что находилось на странице, куда вели ссылки, какой адрес считался основным и по каким запросам документ показывался раньше.

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

Важно правильно понимать фразу «изменился код». Поисковик не видит репозиторий, компоненты или внутреннюю архитектуру приложения. Он видит ответ сервера, итоговый HTML, ресурсы страницы и результат рендеринга. Если новая версия выдаёт другой HTML, меняет порядок и доступность контента, ссылки, заголовки, микроразметку или способ загрузки, страницу приходится обходить и оценивать заново.

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

Из-за каких ошибок трафик падает сильнее всего

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

Часть страниц исчезла

Разработчик мог перенести только те URL, которые находились в меню или sitemap. В результате старые посадочные страницы, статьи, карточки товаров, изображения и другие документы остаются за пределами новой версии.

Если такие страницы получали показы, переходы или внешние ссылки, сайт теряет не «технический мусор», а уже работающие точки входа из поиска.

Старые адреса ведут не туда

Массовый редирект всех удалённых страниц на главную не сохраняет их смысл. Человек, который открыл старую страницу услуги, ожидает попасть на ту же услугу или на максимально близкую замену. Поисковая система оценивает соответствие похожим образом.

Неподходящие назначения, цепочки из нескольких переходов, циклы и отсутствующие редиректы усложняют перенос сигналов и создают тупики для посетителей.

На рабочую версию попали ограничения тестового сайта

Тестовую площадку обычно закрывают от индексации. Перед запуском эти ограничения необходимо снять. Оставшийся noindex, запрет в robots.txt, защита паролем или закрытый доступ к ресурсам способны сделать новый сайт частично либо полностью невидимым для поиска.

Изменилась структура страницы

При редизайне нередко сохраняют текст, но меняют его окружение. Заголовок становится обычным элементом, важный абзац загружается только после действия пользователя, ссылка превращается в кнопку без доступного адреса, а часть содержания перестаёт попадать в исходный или отрендеренный HTML.

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

Потерялись метатеги, canonical, hreflang или микроразметка

Новая CMS может формировать эти элементы по другим правилам. Один ошибочный шаблон способен затронуть сотни страниц: назначить им одинаковый title, указать неправильный canonical или связать между собой не те языковые версии.

Сломались внутренние ссылки

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

Аналитика перестала собирать данные

Иногда трафик не исчезает — исчезают сведения о нём. После смены шаблонов могут потеряться счётчики, цели, события, согласие на cookies или параметры электронной торговли. Без проверки нельзя отличить реальную просадку от поломанного измерения.

Не всегда нужно сохранять старый сайт любой ценой

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

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

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

Решение зависит не от масштаба редизайна, а от того, есть ли у сайта накопленный результат, который действительно нужно защищать.

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

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

Определить цель и границы проекта

Нужно заранее зафиксировать, что именно меняется:

• домен, хостинг, CMS или только дизайн;
• адреса и структура разделов;
• содержание страниц;
• каталог, фильтры, личный кабинет и другие функции;
• языковые или региональные версии;
• системы аналитики, рекламы и внешние интеграции.

Это не формальность. Если команда считает проект обычным редизайном, а в процессе меняет URL и удаляет разделы, SEO-задачи появляются слишком поздно.

Выбрать подходящее время

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

Для большого проекта полезен поэтапный запуск. Но дробить маленький или средний сайт без причины тоже не всегда выгодно: поисковику и пользователям проще быстрее перейти на одну согласованную версию.

Назначить ответственных

У каждой части должен быть владелец: кто готовит новую версию, кто собирает URL, кто утверждает удаление страниц, кто настраивает редиректы, кто проверяет аналитику и кто принимает решение при критической ошибке.

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

Сделать резервную копию и сохранить исходные данные

Перед запуском сохраняют файлы, базу данных, изображения, тексты, метатеги, настройки и конфигурацию старого сайта. Резервная копия нужна не только для полного отката. Из неё можно восстановить потерянную страницу, сверить старый title или проверить, как раньше работал конкретный элемент.

Откат возможен не всегда. После смены домена, получения новых заказов или изменения данных возвращение старой версии может создать дополнительные проблемы. Поэтому резервная копия — страховка, а не замена предварительной проверке.

Какие показатели сохранить для сравнения

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

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

Сравнение должно учитывать сезонность и дни недели. Показатели понедельника после запуска мало что доказывают, если их сопоставили с воскресеньем или с пиковым месяцем прошлого сезона.

Как собрать полный список страниц сайта

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

Для инвентаризации объединяют несколько источников:

1. сканирование сайта по внутренним ссылкам;
2. действующие и старые XML Sitemap;
3. отчёты Google Search Console;
4. посадочные страницы из веб-аналитики;
5. серверные журналы, если они доступны;
6. выгрузку страниц, товаров и записей из CMS;
7. страницы с внешними ссылками;
8. известные URL из рекламных кампаний, писем и документов.

Сканер хорошо показывает доступную структуру и может быстро подготовить рабочую таблицу страниц. Мы также можем просканировать сайт и передать такой список перед миграцией. Но это не «полная база всего, что когда-либо видел поисковик»: изолированная страница без внутренних ссылок может не обнаружиться при обычном обходе. Поэтому результаты сканирования дополняются данными Search Console, аналитики и самого сайта.

После объединения URL удаляют дубли и для каждой страницы определяют дальнейшее действие: сохранить без изменений, перенести на новый адрес, объединить с другой страницей либо удалить.

Какие страницы нужно защищать в первую очередь

Приоритет нельзя определять только по текущему трафику. Страница может получать мало переходов, но собирать важные заявки, иметь сильные внешние ссылки или поддерживать целый раздел внутренней перелинковкой.

Обычно отдельно отмечают:

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

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

Что переносить, а что можно удалить

Миграция не обязывает копировать каждую старую страницу. Устаревшие дубли, пустые фильтры, технические URL и материалы без самостоятельного смысла можно объединить или убрать.

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

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

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

Карта старых и новых URL

Карта редиректов — таблица, в которой каждому старому адресу назначается действие и, при необходимости, новый URL. Она связывает старую поисковую историю с новой структурой.

Минимальный набор колонок выглядит так:

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

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

Постоянные перемещения оформляют серверными редиректами 301 или 308. Цепочки вида «старая страница → промежуточный URL → новая страница» лучше заменить прямым переходом. Это уменьшает задержку и упрощает обработку адресов. Такой подход соответствует рекомендациям Google по постоянным перенаправлениям.

Что проверить на тестовой версии

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

Доступность и коды ответа

Приоритетные страницы должны открываться и возвращать ожидаемый код. Проверяются также изображения, стили, скрипты, документы и API-запросы, без которых страница не работает.

Содержание страниц

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

Итоговый HTML и рендеринг

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

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

Метатеги и поисковые указания

Проверяются title, description, основной заголовок, canonical, robots meta, hreflang для языковых версий и микроразметка. Шаблонные значения сверяются на разных типах страниц, а не только на главной.

Внутренние ссылки

Ссылки должны сразу вести на новые конечные адреса. В меню, хлебных крошках, текстах и карточках не должны оставаться старые URL, лишние редиректы или тупики.

Sitemap и robots.txt

Новый sitemap должен содержать только актуальные канонические страницы с кодом 200. В нём не нужны старые, закрытые и перенаправляемые URL.

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

Скорость и стабильность шаблонов

Проверяется не только главная. Измеряются основные типы страниц: услуги, категории, карточки, статьи и страницы с тяжёлыми интерактивными элементами. Новый дизайн не должен делать ключевой контент заметно медленнее или нестабильнее.

Формы и функции

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

Что делать в день запуска

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

1. Сделать финальную резервную копию и сохранить последние показатели старого сайта.
2. Опубликовать новую версию или переключить домен на новую инфраструктуру.
3. Активировать постоянные редиректы со старых URL.
4. Снять тестовые ограничения индексации с рабочей версии.
5. Проверить robots.txt, robots meta и canonical.
6. Открыть вручную главную и несколько приоритетных страниц каждого типа.
7. Протестировать старые URL и убедиться, что они ведут на правильные новые адреса.
8. Запустить быстрый обход приоритетных страниц, а затем полный технический скан.
9. Проверить работу аналитики, форм, целей и основных функций.
10. Сформировать новый XML Sitemap и отправить его в Google Search Console.
11. Обновить ссылки в рекламе, профилях компании, рассылках и важных внешних сервисах.

Инструмент Change of Address в Google Search Console используется только при переходе на другой домен или поддомен. Для изменения путей внутри того же сайта, перехода с HTTP на HTTPS и смены www он не нужен.

Что контролировать после переноса

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

Сразу после запуска проверяются:

• доступность главной и приоритетных страниц;
• коды ответа старых и новых URL;
• отсутствие случайного noindex и запретов в robots.txt;
• корректность canonical и hreflang;
• новые ошибки 404;
• наличие актуальных страниц в sitemap;
• поступление данных в аналитику;
• работа форм, заказов и других целевых действий.

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

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

Как отличить временные колебания от ошибки

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

Сначала смотрят, как распределилась просадка:

• по всему сайту или только в одном разделе;
• по всем запросам или по отдельной группе;
• только в органическом поиске или во всех источниках;
• исчезли ли страницы из индекса;
• изменилось ли количество показов;
• продолжают ли старые URL получать переходы;
• работают ли редиректы и доступна ли новая версия роботу.

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

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

Что делать, если сайт уже перенесли неправильно

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

Если старые страницы и их назначения удаётся восстановить, можно дополнить карту редиректов, вернуть потерянный контент, исправить доступность и заново связать структуру. Чем раньше обнаружена проблема, тем больше исходных данных обычно остаётся.

Но у восстановления есть предел. Если старая версия удалена, список URL не сохранён, контент потерян, а поисковые системы уже заменили прежние данные новыми, вернуть сайт «как было» одной настройкой невозможно.

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

Можно ли перенести сайт самостоятельно

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

Риск становится выше, когда:

• меняется домен или большая часть URL;
• сайт уже получает заметный поисковый трафик;
• есть каталог, фильтры, регионы или несколько языков;
• часть страниц нужно объединить или удалить;
• меняются CMS, шаблоны и способ рендеринга;
• работают оплаты, личные кабинеты и внешние интеграции;
• у проекта нет полного списка страниц и технической документации.

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

Краткий чек-лист безопасного переноса

До разработки

• определить цель и полный состав изменений;
• зафиксировать трафик, позиции и конверсии;
• собрать URL из нескольких источников;
• выделить приоритетные страницы;
• решить, что сохраняется, объединяется и удаляется;
• подготовить резервную копию;
• назначить ответственных и порядок отката.

На тестовой версии

• сопоставить старые и новые URL;
• настроить и проверить редиректы;
• сравнить содержание и назначение страниц;
• проверить итоговый HTML и доступность контента;
• проверить title, description, canonical, hreflang и микроразметку;
• обновить внутренние ссылки;
• проверить sitemap и будущий robots.txt;
• протестировать скорость, формы и основные функции;
• убедиться, что тестовый сайт закрыт от индексации.

В день запуска

• сохранить последнюю копию старого сайта;
• включить постоянные редиректы;
• снять тестовые ограничения с рабочей версии;
• проверить важнейшие старые и новые URL;
• запустить технический скан;
• проверить аналитику и целевые действия;
• отправить новый sitemap;
• при смене домена использовать Change of Address;
• обновить рекламу и важные внешние ссылки.

После запуска

• следить за ошибками обхода и 404;
• проверять индексацию новых URL;
• сравнивать трафик и позиции с исходными данными;
• контролировать приоритетные страницы отдельно;
• исправлять причины отклонений, а не маскировать их новыми изменениями;
• не отключать старую инфраструктуру и редиректы раньше времени.

Обязательно ли после переноса упадут позиции?

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

Можно ли сохранить SEO при полной переработке сайта?

Можно сохранить большую часть накопленной основы: адреса или их соответствия, содержание, внутренние связи, метатеги и доступность страниц. Однако новый HTML и структура всё равно будут повторно оцениваться. Поэтому корректный перенос снижает риск, но не превращает позиции в гарантированно неизменную величину.

Нужно ли сохранять все старые URL?

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

Можно ли перенаправить все старые страницы на главную?

Нет. Главная обычно не отвечает на тот же вопрос, что старая услуга, статья или товар. Массовые нерелевантные редиректы неудобны пользователям и могут восприниматься поисковой системой как мягкие ошибки 404.

Как долго хранить редиректы?

Google рекомендует сохранять редиректы как можно дольше и как минимум около года. Для пользователей часто разумно оставлять их постоянно, особенно если на старые адреса продолжают вести внешние ссылки.

Нужно ли закрывать тестовую версию в robots.txt?

Тестовый сайт действительно нужно защищать от попадания в поиск, но одного robots.txt не всегда достаточно. Надёжнее ограничить доступ паролем или использовать согласованный набор запретов. Перед запуском обязательно проверяют, что ограничения не перешли на рабочую версию.

Поможет ли повторная отправка страниц быстрее вернуть позиции?

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

Что делать, если после миграции прошло много времени?

Нужно сравнить доступные старые данные с текущим сайтом и понять, какие страницы и сигналы ещё можно восстановить. Если исходная версия уже утрачена, проект лучше не называть продолжающимся переносом: проводится аудит текущего состояния и составляется новый план SEO-работ.

Перенос должен сохранять результат, а не только файлы

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

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

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