Упал SEO-трафик после редизайна или переезда сайта: как найти причину и вернуть позиции
Заявки из поиска пропали после редизайна? Показываем, как отличить реальную потерю позиций от сбоя аналитики или форм, что проверить в первые 24 часа и почему исправления не гарантируют возврат трафика.
Сначала разделите потерю видимости, данных и заявок
Когда после редизайна падает число заявок из поиска, восстановление позиций после редизайна начинается с выяснения того, что изменилось: видимость в поиске, сбор данных или конверсия в заявки. Каждая проблема требует своего решения. В Webdelo мы сравниваем данные Search Console, аналитики и CRM, прежде чем рекомендовать технические изменения.
В этом руководстве разобраны проверки первого дня, частые ошибки при переносе сайта и порядок восстановления, которому могут вместе следовать маркетологи и разработчики. Исправление ошибок не гарантирует возврата позиций, трафика или продаж. Ваша команда отвечает за исправления, а Google решает, когда повторно обойти и обработать затронутые страницы.
Почему упал трафик после редизайна или переезда сайта
Редизайн может нарушить связь между старыми URL и новыми страницами, привести к потере полезного контента или закрыть Google доступ к страницам. Кажущееся падение SEO-трафика после редизайна или переезда также может быть вызвано отсутствием тегов аналитики. Если посещаемость из поиска остаётся стабильной, а обращения исчезают, проверьте конверсию и передачу заявок.
- Видимость в поиске: отсутствующие редиректы, удалённый контент, неработающие внутренние ссылки или ограничения индексации могут мешать обнаружению страниц и влиять на позиции.
- Сбор данных: отсутствующие теги GA4, изменённые настройки согласия пользователей или недостающие ключевые события могут привести к падению трафика и конверсий в отчётах.
- Конверсия: неработающая форма, непонятный призыв к действию или сбой связи с CRM могут снизить число зарегистрированных заявок, даже если посетители по-прежнему приходят.
Например, форма может показывать сообщение об успешной отправке, но не создавать запись в CRM. В таком случае нужно проверить интеграцию, а не переписывать текст страницы для поиска. И наоборот, если прежняя страница услуги возвращает 404, нужно проверить URL и контент.
Обычные колебания позиций и критические проблемы при переносе
Пока Google обрабатывает перенос сайта, возможны временные колебания позиций. Резкое падение показов по всему сайту, массовые неожиданные ошибки 404 или выпадение важных страниц из индекса требуют немедленной проверки. Не рассчитывайте, что эти симптомы исчезнут сами, если подождать.
В руководстве Google по диагностике падения поискового трафика рассматриваются технические проблемы, угрозы безопасности, меры, принятые вручную, обновления алгоритмов ранжирования и изменения поискового спроса. Падение вскоре после запуска ещё не доказывает, что его вызвал перенос.
| Симптом | Возможное объяснение | Действие |
|---|---|---|
| Постепенные изменения позиций по отдельным запросам | Возможны повторный обход и колебания позиций | Отслеживайте затронутые запросы и посадочные страницы в Search Console. |
| Резкое падение показов по всему сайту | Возможны проблемы с доступом, индексацией или сервером | Немедленно проверьте robots.txt, директивы noindex и ошибки сервера. |
| Падение сосредоточено в отдельных разделах | Возможны пропуски в настройке редиректов или изменения контента | Сравните старые и новые URL и контент в этих разделах. |
| Число сеансов в GA4 падает, а число кликов в Search Console остаётся стабильным | Вероятна проблема со сбором данных | Проверьте теги, работу механизма согласия пользователей и настройки отчётов. |
| Число кликов из поиска остаётся стабильным, а заявок становится меньше | Возможны проблемы с конверсией или передачей заявок | Протестируйте формы и передачу данных в CRM, затем изучите поведение посетителей на посадочных страницах. |
| Падение соответствует сезонной или рыночной тенденции | Возможно изменение спроса | Сравните результаты с прошлым годом и оцените общую динамику поискового спроса. |
Сравните равные периоды до и после запуска в отчёте "Эффективность" Search Console. Рассмотрите группы страниц и запросы отдельно, чтобы понять, затронуло ли падение весь сайт или определённый шаблон. Также проверьте отчёты "Меры, принятые вручную" и "Проблемы безопасности".
Что проверить в первые 24 часа
Сначала выясните, в какой системе видно падение. Затем проверьте ограничения индексации на всём сайте, сбои сервера и редиректы с важных старых URL. Одновременно сразу протестируйте формы: из-за сбоя передачи данных обращения могут теряться, пока продолжается SEO-диагностика.
| Инструмент или проверка | Диагностика | Приоритет |
|---|---|---|
| Google Search Console | Изучите клики, показы, индексацию страниц и проблемы обхода. Проверьте типичные примеры затронутых URL. | Критический |
| GA4 | Проверьте теги на каждом новом шаблоне, работу механизма согласия пользователей и ключевые события, связанные с заявками. | Высокий |
| Редиректы | Убедитесь, что старые URL перенесённых страниц возвращают редиректы 301 или 308 на соответствующие новые страницы. | Критический |
| Noindex | Проверьте исходный код страниц и HTTP-заголовки на наличие директив тестовой среды, запрещающих индексацию. | Критический |
| Robots.txt | Убедитесь, что важные страницы рабочего сайта доступны Googlebot. | Критический |
| XML-карты сайта | Укажите в карте сайта новые URL, выбранные каноническими, и отправьте её через Search Console. | Высокий |
| Ошибки сервера | Проверьте журналы и Search Console на наличие ответов 5xx, превышений времени ожидания и проблем с доступностью. | Критический |
| Формы | Отправьте тестовую заявку и убедитесь, что в CRM создана нужная запись и назначен ответственный. | Критический |
Мы начинаем с этих базовых препятствий, потому что одна настройка рабочего сайта может затронуть все страницы на одном шаблоне. Правило robots.txt запрещает обход, а директива noindex указывает роботу не индексировать страницу. Google должен иметь возможность обойти страницу, чтобы увидеть, что директива noindex удалена.
Прежде чем что-либо менять, сохраните дату и время запуска, текущие настройки и журналы, относящиеся к сбою. Назначьте ответственного за инцидент, который будет координировать исправления и фиксировать изменения, чтобы команды не перезаписывали работу друг друга.
10 ошибок SEO при переносе сайта, которые вредят позициям
Проблемы при переносе сайта часто связаны с сопоставлением старых и новых URL, директивами индексации и удалением контента без плана замены. Эти ошибки могут закрыть доступ к страницам или дать противоречивые сигналы о том, какие URL должны появляться в поиске.
- Неполная карта соответствия URL. Для важных старых страниц не указан новый адрес, поэтому посетители и поисковые роботы неожиданно попадают в тупик.
- Неподходящие редиректы для постоянного переноса. Серверные редиректы 301 или 308 прямо сообщают о постоянном переносе. Код 302 указывает на временный перенос, а редиректы JavaScript требуют дополнительной обработки.
- Цепочки и циклы редиректов. Цепочки добавляют лишние переходы. Циклы не дают загрузить конечную страницу.
- Все старые URL перенаправляются на главную. Несвязанные с исходной страницей адреса могут запутать посетителей и восприниматься как soft 404. Это означает, что Google считает их страницами ошибок, несмотря на код ответа.
- Директивы noindex из тестовой среды остаются на рабочем сайте. Директива на уровне шаблона может исключить из поиска целый раздел.
- Robots.txt блокирует страницы рабочего сайта. Google не может обойти контент, необходимый для понимания переноса.
- Теги canonical указывают неверные URL. Тег canonical обозначает предпочтительную версию страницы. Ссылка на устаревший URL создаёт противоречивый сигнал.
- Связи hreflang нарушены. Hreflang указывает языковые или региональные версии. Старые адреса и отсутствие обратных ссылок между версиями могут нарушить эту связь.
- Полезный контент исчезает. При упрощении дизайна могут пропасть пояснения, которые раньше отвечали на вопросы пользователей поиска.
- Во внутренних ссылках и картах сайта остаются старые URL. Роботы и посетители продолжают переходить по устаревшим адресам вместо нужных новых страниц.
Мы не перенаправляем все страницы на главную, потому что это скрывает нерешённые вопросы сопоставления URL. Используйте соответствующую замену, если она есть. Если контент действительно удалён и равноценной замены нет, подходящий ответ 404 или 410 понятнее, чем переход на несвязанную страницу.
Как проверить редиректы при переносе сайта и восстановить SEO-сигналы
Аудит редиректов проверяет, ведёт ли каждый ценный URL перенесённой страницы прямо на наиболее подходящую замену через постоянный серверный редирект. Конечная страница должна работать и быть доступной для индексации. Google всё равно потребуется обойти страницы и обработать связь между ними.
Соберите список старых URL из архивных карт сайта, выгрузок Search Console, аналитики и данных об обратных ссылках. Включите страницы, ценные для бизнеса, даже если их трафик был небольшим. В документации Google по переносу сайта описан базовый порядок сопоставления URL, настройки постоянных редиректов и мониторинга после переноса.
Для каждого перенесённого URL проверьте ответ 301 или 308, переход без промежуточных редиректов и соответствие конечной страницы исходной. Убедитесь, что конечная страница возвращает 200, допускает индексацию и содержит canonical на саму себя, если именно она выбрана канонической. Редирект, который ведёт к другой ошибке или заблокированной странице, остаётся нерешённой проблемой.
Обновите внутренние ссылки, карты сайта, теги canonical и ссылки hreflang, чтобы везде использовались новые URL. При смене домена, соответствующей требованиям Google, включите инструмент Search Console "Изменение адреса" в процесс переноса. Эти действия помогают Google понять перенос, но не гарантируют возврата прежних позиций.
Как измерить потерю органического трафика и заявок
Оценивайте инцидент по видимости в поиске, действиям на сайте и результатам для бизнеса. Search Console показывает показы и клики в поиске Google, GA4 фиксирует учтённые посещения и поведение, а CRM показывает полученные заявки. Сопоставление этих источников помогает отличить потерю спроса от потери данных.
- Используйте сопоставимые периоды. Сравнивайте отрезки одинаковой длины с совпадающими днями недели. Для оценки сезонности изучите аналогичный период прошлого года.
- Разделите потери по сегментам. Объедините старые URL с соответствующими новыми, затем сравните разделы услуг, запросы, устройства и рынки.
- Оцените влияние на бизнес. Изучайте качественные заявки из органического поиска и их посадочные страницы, если доступна атрибуция. Не считайте каждое событие отправки формы потенциальной продажей.
Клики в Search Console и сеансы в GA4 не совпадут полностью, потому что системы измеряют разные показатели. Сравнивайте тенденции с одинаковыми фильтрами и учитывайте задержки в отчётах. Подтверждённое падение в Search Console может установить факт потери поискового трафика, даже если сбор данных в аналитике не работает.
Если число кликов из поиска остаётся стабильным, а учтённых сеансов становится меньше, сначала проверьте сбор данных. Если оба показателя стабильны, а заявок в CRM становится меньше, проследите путь отправки через форму и интеграцию. Затем изучите поведение, влияющее на конверсию, и качество заявок.
Восстановление позиций после редизайна: 7 шагов
Чтобы восстановить позиции после переноса сайта, сначала займитесь доступом и индексацией, а затем менее значимыми доработками. Последовательность ниже даёт ответственному за инцидент практический порядок действий. Если сбои форм или сбора данных уже подтверждены, поручите их исправление параллельно.
- Определите, где произошёл сбой. Сравните динамику Search Console, GA4 и CRM в период запуска. Зафиксируйте, какие группы страниц и бизнес-показатели изменились.
- Устраните препятствия для индексации и доступа. Исправьте непреднамеренные директивы noindex, ограничения robots.txt и сбои сервера. После публикации изменений проверьте ответ рабочего сайта.
- Исправьте карту редиректов. Добавьте для перенесённых URL редиректы 301 или 308 на соответствующие страницы без промежуточных переходов. Протестируйте всю карту, а не несколько примеров с главной страницей.
- Восстановите контент и связанные сигналы. Верните полезные материалы, потерянные при редизайне. Приведите теги canonical, ссылки hreflang и внутренние ссылки в соответствие с нужными новыми страницами.
- Исправьте сбор данных и передачу заявок. Проверьте сбор данных GA4 при предусмотренных настройках согласия пользователей. Убедитесь, что заявки из форм доходят до CRM и ответственных сотрудников отдела продаж.
- Помогите Google обнаружить изменения. Отправьте обновлённые карты сайта и запросите индексацию отдельных важных URL в Search Console. Запросы не гарантируют ни индексацию, ни конкретный срок обработки.
- Отслеживайте результаты по группам страниц. Сравнивайте индексацию, клики и качественные заявки с исходными показателями. Разбирайтесь с группами, где проблема сохраняется, вместо того чтобы снова и снова менять весь сайт.
Для каждой задачи восстановления назначьте ответственного, определите проверочный тест и зафиксируйте время публикации изменений. Это позволит отличить технически неудачное исправление от уже работающего изменения, которое Google ещё не обработал повторно.
Кто отвечает за потерю поискового трафика?
Ответственность за работу зависит от того, кто обязался сформулировать, выполнить и проверить каждое требование к переносу. Договор и документы о приёмке помогают установить эти роли. SEO-расследование может зафиксировать сбои и задачи без ответственных, но не определяет юридическую ответственность.
| Проблема | Кто отвечает за проверку | Какие подтверждения изучить |
|---|---|---|
| Отсутствуют редиректы | Назначенный ответственный за карту соответствия URL и исполнитель настройки редиректов | Техническое задание, утверждённая карта редиректов, результаты тестов, журнал релизов |
| Остались noindex или ограничения robots.txt из тестовой среды | Ответственный за релиз и приёмку рабочего сайта | Чек-лист публикации изменений, изменения конфигурации, журнал релизов |
| Исчез важный контент | Ответственный за контент и руководитель проекта, утвердивший новую структуру | Утверждённая карта сайта, список контента, история правок |
| Перестал работать сбор данных | Ответственный за аналитику и команда внедрения | План настройки тегов, документы о приёмке, история конфигурации |
| Не работают формы или передача данных в CRM | Разработчик и ответственный за CRM в рамках согласованного объёма работ | Результаты сквозных тестов, журналы интеграции, объём работ по договору |
Если SEO при переносе не входило в согласованный объём работ, это указывает на пробел в планировании, а не доказывает вину одной из сторон. Отделите срочное восстановление от споров об оплате. Юридические вопросы требуют рассмотрения квалифицированным юристом.
Предоставляйте каждому специалисту только тот доступ, который нужен для аудита, особенно при проверке передачи заявок в CRM. Наш материал про защиту клиентской базы при работе с IT-подрядчиком пригодится, когда вы предоставляете временный доступ к записям о заявках и системам интеграции.
Сколько времени занимает восстановление SEO?
У восстановления два отдельных срока: техническое исправление и обработка исправленного сайта Google. Ваша команда может оценить срок выполнения после изучения проблемы. Она не может обещать, когда Google повторно обойдёт страницы и как изменятся их позиции.
| Проблема | Исправление | От чего зависят сроки |
|---|---|---|
| Ограничение robots.txt или noindex | Удалить непреднамеренное ограничение и проверить доступ для обхода. | Техническое исправление зависит от доступа к публикации изменений и конфигурации. Реакция Google зависит от повторного обхода и обработки. |
| Отсутствующие редиректы | Настроить и протестировать редиректы 301 или 308 по карте соответствия URL. | Техническое исправление зависит от числа URL и конфигурации сервера. Google должен повторно посетить старые URL и обработать конечные адреса. |
| Потерянный контент | Восстановить или улучшить соответствующие материалы. | Техническая и редакционная работа зависит от доступных архивов и ресурсов для работы с контентом. Предсказать дату завершения переоценки в поиске нельзя. |
| Сбой сбора данных | Исправить теги, интеграцию механизма согласия пользователей или сбор событий. | Исправление зависит от доступа для внедрения и тестирования. Новый сбор данных можно проверить после публикации изменений, но пропущенные события за прошлые периоды нельзя просто воссоздать. |
Некоторые страницы могут не вернуть прежние позиции, особенно если изменились их контент, страницы конкурентов или поисковый спрос. Отчитывайтесь о выполненных технических исправлениях отдельно от наблюдаемого восстановления в поиске. Так руководство увидит прогресс и не примет публикацию изменений за восстановление результатов.
Как предотвратить потерю трафика при будущих редизайнах
Чек-лист SEO при переезде сайта работает, когда у каждого требования есть ответственный и приёмочный тест. Сделайте сохранение связи между URL, доступность для индексации и передачу заявок обязательными условиями запуска. Продолжайте мониторинг после публикации, когда роботы и реальные посетители начнут пользоваться новым сайтом.
- До запуска: сохраните исходные показатели отчётов, составьте список ценных URL, утвердите карту редиректов и протестируйте запланированное поведение в тестовой среде.
- При запуске: проверьте настройки индексации рабочего сайта, редиректы, сбор данных аналитики и передачу заявок из форм в CRM. Опубликуйте обновлённую карту сайта.
- После запуска: отслеживайте ошибки индексации, результаты поиска и качественные заявки по группам страниц. Назначьте ответственных за разбор отклонений в последующие недели.
Включите эти критерии приёмки в объём работ по разработке сайтов до начала реализации. Совместное описание обязанностей по переносу сайта и SEO уменьшает неопределённость при согласовании релиза.
Для постоянного мониторинга тоже нужен назначенный ответственный за поддержку. Понимание того, что входит в поддержку сайта и сколько она стоит, помогает определить, относятся ли проверки индексации, аналитики и интеграций к регулярной поддержке или отдельным работам.
Как Webdelo проводит аудит неудачного переноса сайта
При проверке переноса Webdelo разделяет сбои видимости, сбора данных и конверсии, прежде чем расставлять приоритеты изменений. Мы совмещаем технический SEO-аудит после переноса с проверкой форм и CRM. Цель - план восстановления на основе подтверждённых данных, а не предположение, что нужен ещё один редизайн.
"После редизайна сайта сначала нужно выяснить, что именно изменилось: видимость в поиске, учёт посещений или конверсия в заявки. Только сравнив данные Google Search Console, аналитики и CRM, можно определить причину падения и составить обоснованный план восстановления. Технические ошибки нужно исправлять, но само по себе это не гарантирует возврата прежних позиций."
Наш SEO-аудит сайта даёт техническую основу для такого плана. При проблемах с переносом проверка связывает наблюдаемые симптомы с затронутыми URL и конкретными ошибками реализации.
- Сопоставление данных: выясняем, что изменилось в результатах поиска, сборе данных аналитики и полученных заявках.
- Техническая проверка: изучаем редиректы, индексацию, теги canonical, hreflang и ответы сервера.
- Проверка конверсии: прослеживаем путь тестовых заявок от браузера до получения в CRM.
- План восстановления с приоритетами: ранжируем найденные проблемы по влиянию на бизнес и трудоёмкости исправления, назначаем ответственных и критерии проверки.
Webdelo разрабатывает программное обеспечение для B2B с 2006 года и оказывает услуги по техническому и международному SEO, включая SEO-продвижение сайтов, наряду с разработкой и поддержкой продуктов. Такое сочетание помогает связать проблемы в поиске с шаблонами, настройками публикации и интеграциями, которые нужно исправить.
Закажите в Webdelo независимый SEO-аудит переноса сайта и план восстановления с приоритетами. Сообщите дату запуска и затронутые группы страниц, чтобы проверка была сосредоточена на инциденте и его влиянии на бизнес.
Стройте восстановление на данных и проверенных исправлениях
Падение после редизайна требует диагностики, прежде чем можно брать на себя обязательства по восстановлению. Установите, затрагивает ли сбой видимость в поиске, сбор данных или конверсию в заявки. Затем назначьте ответственных за наиболее важные исправления и определите приёмочные тесты.
Отслеживайте завершение технических работ отдельно от повторного обхода Google и изменений позиций. Проверенное исправление - существенный шаг вперёд, но редиректы и другие изменения не гарантируют возврата прежнего трафика, позиций или продаж.
Часто задаваемые вопросы
Почему после переноса сайта упали позиции и что значит полная потеря трафика?
Позиции после переноса обычно падают из-за отсутствующих или неверных редиректов, удалённого контента, битых внутренних ссылок, ошибочных canonical или запретов индексации. Почти полная потеря трафика по всему сайту чаще всего указывает на общий блокер: тег noindex, оставшийся с тестовой среды, правило robots.txt, закрывающее рабочие страницы, или ошибки сервера. Сначала проверьте Search Console: если показы и клики стабильны, а GA4 показывает ноль визитов, проблема, скорее всего, в аналитике, а не в поиске.
Можно ли полностью вернуть позиции и трафик после неудачного переноса сайта?
Во многих случаях восстановление возможно, но честно гарантировать его никто не может. Команда отвечает за технические исправления, а Google сам решает, когда заново обойти и обработать страницы и как их ранжировать. Часть страниц может не вернуть прежние позиции, особенно если изменились их контент, конкуренты или спрос. Отчитывайтесь о выполненных исправлениях отдельно от фактического восстановления в поиске.
Как проверить, правильно ли работают 301-редиректы после переноса сайта?
Соберите список старых URL из архивных карт сайта, выгрузок Search Console, аналитики и данных об обратных ссылках, затем проверьте каждый краулером или HTTP-чекером. Каждый перенесённый URL должен отдавать 301 или 308 за один переход на релевантную замену, а не на главную. Целевая страница должна отвечать 200, быть открытой для индексации и иметь canonical на саму себя. Рабочие редиректы помогают Google понять переезд, но не гарантируют возврат прежних позиций.
Почему новые страницы не индексируются после редизайна?
Частые причины: тег noindex, оставшийся с тестовой среды, правила robots.txt, закрывающие рабочие страницы, ошибки сервера, canonical на старые URL и карта сайта со старыми адресами. Проверьте типичные URL инструментом проверки в Search Console, а также исходный код страниц и HTTP-заголовки. После исправления отправьте обновлённую карту сайта и запросите индексацию важных страниц, учитывая, что запрос не гарантирует ни индексацию, ни сроки.
Стоит ли откатиться на старую версию сайта, если после запуска упал трафик?
Откат не должен быть автоматической первой реакцией. Сначала выясните, что пострадало: видимость в поиске, сбор данных или конверсия в заявки, ведь многие инциденты вызваны несколькими исправимыми настройками вроде noindex, robots.txt или отсутствующих редиректов. Возврат старого сайта снова меняет URL и сигналы, поэтому такое решение стоит принимать вместе с SEO-специалистами и разработчиками на основе данных, а не в панике.
Кто платит за исправление потери SEO-трафика после редизайна?
Это зависит от того, кто взял на себя постановку, реализацию и проверку каждого требования к переносу. Это видно из договора, ТЗ, утверждённой карты редиректов, результатов тестов и журнала релизов. Если SEO при переносе вообще не входило в согласованный объём работ, это пробел в планировании, а не доказательство вины одной стороны. Отделяйте срочное восстановление от спора об оплате, а юридические вопросы передавайте квалифицированному юристу.
Когда бизнесу стоит заказать независимый аудит переноса сайта?
Независимый аудит стоит рассмотреть, если заявки из поиска продолжают падать после запуска и команда не находит причину, если данные Search Console, GA4 и CRM противоречат друг другу или если работа исходного подрядчика вызывает вопросы. Независимая проверка сопоставляет данные, проверяет редиректы, индексацию, canonical, hreflang и доставку заявок из форм в CRM и даёт приоритизированный план восстановления с ответственными. Цель - обоснованные исправления, а не очередной редизайн по умолчанию.
