Новый сайт должен сохранить поисковый трафик, который вы уже заработали

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

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

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

Определите, что именно меняется

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

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

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

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

До дизайна: сохраните данные и полезные страницы

Подготовьте инвентаризацию, которая переживёт старый сайт

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

Для важных адресов зафиксируйте статус ответа, Title, H1, meta description, canonical, правила индексации, основной контент, внутренние ссылки и применимую структурированную разметку. Включите PDF, изображения и другие материалы, привлекающие посетителей или помогающие клиентам. Сохраните скриншоты типовых страниц, но не используйте их вместо резервной копии контента.

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

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

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

Выберите сопоставимые завершённые периоды и сохраните доступный сезонный контекст. Для компании в США отделите американский результат от мирового. Изменение географии трафика может скрыть потерю видимости нужного рынка за нормальным общим итогом.

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

Заранее определите судьбу каждой страницы

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

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

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

До запуска: сопоставьте адреса и проверьте новый сайт

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

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

Проверьте карту редиректов списком

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

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

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

Воспроизводимая проверка редиректов в Screaming Frog

Названия элементов интерфейса сверены с официальной документацией 8 октября 2026 года; они могут отличаться в другой версии или локализации. Запишите ожидаемый адрес до проверки: фактический результат не должен незаметно стать вашим критерием успеха.

1. Переключитесь в Mode > List. В расширенных настройках сканирования включите следование всем редиректам - Always Follow Redirects, чтобы проверить адрес назначения за пределами загруженного списка.
2. Через Upload вставьте старые URL или загрузите сохранённый список. Начните с важных клиентских маршрутов, затем проверьте инвентаризацию миграции. Для закрытого тестового сайта может понадобиться разрешённый доступ; не снимайте защиту рабочего сайта ради сканирования.
3. Экспортируйте отчёт всех редиректов через Reports > Redirects > All Redirects. Сопоставьте конечный адрес и ответ с планом. Отдельно изучите цепочки и циклы: конечный статус 200 не делает неверное назначение правильным.
4. Откройте важные конечные страницы и проверьте содержание, canonical, robots meta и HTTP-заголовки индексации. Повторите тест списка после запуска на рабочем сайте и сохраните экспорт с датой проверки.

См. официальный процесс миграции и документацию режима списка. Сохраните настройки доступа и рендеринга вместе с экспортом: они влияют на охват проверки.

Это условные маршруты, а не результаты клиентов W-MAX. Фиксируйте старый URL, ожидаемый и фактический адрес, переходы, конечный HTTP-статус, canonical, инструкции индексации, проверку контента, ответственного, время и ссылку на доказательство. Закрывайте ошибку только после новой проверки исправления.

Сравните контент и метаданные по шаблонам

Title и H1 должны описывать конкретную страницу. Meta description должен оставаться полезным, а не превращаться в одинаковое значение CMS повсюду. Метаданные не составляют всю SEO-стратегию, но сломанный импорт часто указывает и на другие потерянные поля.

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

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

Защитите тестовую среду и не перенесите её запреты в production

Закрывайте приватный staging авторизацией или ограничением доступа. Если публичная тестовая страница использует noindex, Google должен иметь возможность её просканировать и прочитать инструкцию. Один запрет robots.txt не является надёжным исключением URL из поиска. Google объясняет условие работы noindex.

Составьте отдельный список рабочих страниц, которые должны индексироваться. Проверяйте robots в HTML и заголовках ответа. X-Robots-Tag на сервере или CDN влияет на страницы даже при правильной галочке в CMS.

Проверьте robots.txt каждого хоста. Просмотрите canonical, языковые аннотации при их использовании, адреса ресурсов и sitemap на упоминания тестового сайта. Новый сайт не должен объявлять staging основным местом контента. Авторизация остаётся на тестовой среде, публичные рабочие страницы получают согласованные правила доступа и индексации.

Проверьте навигацию и результат рендеринга

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

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

Если меняется JavaScript-рендеринг, сравните исходный HTML с отрендеренным результатом. Проверьте текст, ссылки, canonical и обработку ошибок. При доступности используйте проверку URL для типовых страниц, а не только отключение JavaScript в собственном браузере. Руководство Google по JavaScript SEO разбирает обход и рендеринг.

Фраза «Google умеет выполнять JavaScript» не отменяет проверку. Работа в браузере и надёжное обнаружение с корректным рендерингом в поиске являются разными критериями приёмки.

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

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

Кроме скорости проверьте управление клавиатурой, мобильное меню, смещения блоков, читаемость и видимость связи. В статье W-MAX о page experience есть дополнительный контекст. Актуальные рекомендации Google не обещают высокие позиции только за хороший пользовательский опыт.

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

Search Console: сначала данные индекса, затем проверка текущей страницы

1. Выберите нужный ресурс и введите точный рабочий URL в строку проверки. Сначала изучите отчёт об индексе: это сохранённые Google сведения, включая последний обход и выбранный canonical, если они доступны.
2. Запустите Test live URL - проверку текущего URL. Изучите доступность для обхода и возможность индексации. В сведениях о проверенной странице просмотрите полученный HTML и результат рендеринга, если доступны; убедитесь, что ответ об услуге и важные ссылки сохранились.
3. При расхождении сохраните оба результата и время проверки. Успешный текущий тест не означает, что страница уже в индексе, Google выберет ваш canonical или позиции защищены.
4. После исправления повторите текущую проверку. При необходимости и доступности функции запросите индексацию, затем отслеживайте данные индекса. Запрос не задаёт срок и не гарантирует результат.

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

Принимайте запуск по доказательствам, а не по фразе «всё красиво»

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

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

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

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

День запуска: снова проверьте рабочую среду

Приёмка staging не доказывает работу production. Настройки хоста, кеш, редиректы и переменные среды меняют результат. Сразу после релиза выполните короткую проверку публичного сайта.

1. Доступ: важные страницы, сертификаты и ожидаемые HTTP-ответы.
2. Индексация: рабочий robots.txt, robots в HTML и заголовки основных шаблонов.
3. Назначения: повторный тест старых URL и критичных конечных страниц.
4. Контент: список наблюдения против согласованной версии, включая мобильный вид и рендеринг.
5. Обнаружение: внутренние ссылки, canonical, языковые маршруты и sitemap.
6. Бизнес: тестовые заявки, звонки и заказы, их доставка и отслеживание.
7. Мониторинг: доступ к Search Console, аналитике, CRM и техническим журналам.

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

При подходящей смене домена подтвердите ресурсы и выполните инструкцию Change of Address. Этот инструмент не нужен при обычном изменении оформления или перестройке путей без смены домена.

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

Первые 24-72 часа: отделите срочные сбои от неполных данных

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

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

Резкое падение трафика после релиза требует проверки измерения вместе с SEO. Исчезновение тега Analytics не доказывает исчезновение посетителей. Сравните Search Console, запросы сервера и фактические обращения. Если формы перестали доставляться, восстановите клиентский путь параллельно поисковой диагностике.

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

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

Первые 2-4 недели: следите за группами, а не только главной

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

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

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

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

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

Закрывайте миграцию, когда это подтверждают результаты

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

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

Частые вопросы

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