Страницы после миграции сайта не индексируются: полное руководство по восстановлению
Миграция сайта прошла гладко в браузере, но Google с трудом распознаёт новые URL. Поймите критичное 90-дневное окно и устраните проблемы редиректов, канонических тегов и подтверждения, мешающие индексации после миграции.
В этой инструкции
Миграции сайта — одни из самых рискованных операций в SEO. Будь то переезд на новый домен, смена структуры URL, миграция с HTTP на HTTPS, переключение CMS-платформ или объединение нескольких сайтов в один — миграция фундаментально нарушает понимание Вашего сайта Google. Страницы, индексировавшиеся годами, могут внезапно исчезнуть из выдачи. Новые URL, которые должны заменить старые, застревают в очереди сканирования. Позиции падают по всему сайту, пока Google переоценивает Ваш сайт в новой форме.
Первые 90 дней после миграции критичны. В этот период Google активно пересканирует сайт, обрабатывает редиректы, оценивает новые URL и решает, заслуживает ли новая структура того же покрытия индексации и ранжирования, что и старая. Ошибки в этом окне могут обернуться месяцами потерянного трафика. Но даже грамотно проведённые миграции часто переживают пробелы индексации, когда некоторые страницы нового сайта не индексируются, а их аналоги со старыми URL уже убраны из индекса.
Проблемы индексации после миграции отличаются от обычных, потому что они связаны с переходом между двумя состояниями. Google должен одновременно обработать удаление старых URL и добавление новых, передать авторитет со старых страниц на новые через редиректы и согласовать существующее понимание контента сайта с новой структурой. Это создаёт возможности для путаницы, сброса сигналов и пробелов индексации, которых нет в обычной жизни сайта.
Это руководство охватывает конкретные проблемы индексации, возникающие во время и после миграций сайта, диагностические шаги для их выявления и исправления для быстрого решения и минимизации потерь трафика в переходный период.
Критичное 90-дневное окно после миграции
Реакция Google на миграцию сайта разворачивается примерно за 90 дней, хотя точный таймлайн зависит от размера сайта, частоты сканирования и масштаба изменений. Понимание этого таймлайна помогает выставить ожидания и определить, когда задержки индексации нормальны, а когда указывают на проблему.
В первую-вторую неделю после миграции Google начинает обнаруживать изменения. Если Вы настроили 301-редиректы со старых URL на новые, Google встречает их при обычном сканировании старых URL. Каждый редирект сообщает Google, что старый URL окончательно переехал на новое место. Google обрабатывает редиректы и начинает добавлять новые URL в очередь сканирования. В этой фазе в выдаче будет смесь старых и новых URL — это нормально.
В недели со второй по четвёртую Google наращивает сканирование новых URL. Если Вы отправили новую карту сайта с новой структурой URL и подтвердили новый домен в Google Search Console, Google ускоряет исследование нового сайта. Вы должны видеть, как соотношение старых и новых URL в индексе смещается в пользу новых. Часть старых URL ещё будет появляться в выдаче, потому что Google ещё не просканировал и не обработал все редиректы.
В недели с четвёртой по восьмую основная часть перехода должна завершиться. Большинство старых URL должно правильно перенаправляться, большинство новых должно быть в индексе, а позиции начать стабилизироваться около домиграционных уровней. Если позиции существенно ниже прежних, могут быть проблемы с редиректами, изменения контента или технические проблемы на новом сайте, влияющие на сигналы качества.
В недели с восьмой по двенадцатую уверенность Google в новом сайте укрепляется. Любые оставшиеся старые URL, всё ещё индексированные, должны быть обработаны. Позиции должны восстановиться до домиграционных уровней при условии корректно выполненной миграции. Если конкретные страницы всё ещё не в индексе, у них есть индивидуальные проблемы, требующие точечной диагностики.
В течение всех 90 дней избегайте дополнительных серьёзных изменений. Не перерисовывайте новый сайт, не реструктурируйте URL снова и не меняйте существенно контент. Каждое дополнительное изменение сбрасывает часть процесса оценки Google и продлевает срок восстановления. Считайте 90 дней после миграции периодом стабилизации, в котором единственные изменения — исправления проблем, связанных с миграцией.
Цепочки 301-редиректов, петли и пробелы в маппинге
Реализация редиректов — единственный самый важный фактор в индексации после миграции. Каждый старый URL, имевший хоть какие-то позиции, трафик или обратные ссылки, должен перенаправляться на наиболее релевантную страницу нового сайта. Ошибки в редиректах ответственны за большинство сбоев индексации после миграции.
Цепочки редиректов возникают, когда один редирект указывает на другой, который указывает на третий. Например, http://old-domain.com → https://old-domain.com → https://new-domain.com/page. Google может следовать цепочкам, но каждый прыжок вносит задержку и может терять часть ссылочного веса. Google заявлял, что передаёт полный PageRank через единственный 301-редирект, но менее ясно высказывался о цепочках. Лучшая практика — минимизировать цепочки до максимум двух прыжков, идеально — внедрить прямые однопрыжковые 301-редиректы с каждого старого URL на финальное место назначения.
Петли редиректов возникают, когда URL A перенаправляется на URL B, а URL B обратно на A. Это не даёт Google добраться до финальной страницы назначения и приводит к ошибке сканирования. Петли часто случаются, когда HTTP перенаправляется на HTTPS, а HTTPS-версия тоже имеет правило, отправляющее определённые пути обратно на HTTP, или когда конфликтуют редиректы www и без www. Тестируйте редиректы инструментом проверки цепочек, прослеживающим полный путь для каждого URL.
Пробелы в маппинге — это старые URL без редиректа на новый. Когда Google сканирует старый URL и получает 404 вместо редиректа, он убирает URL из индекса. Если эквивалентная страница есть на новом сайте, но не была заложена в план редиректов, у Google нет способа связать авторитет старой страницы с новой. Новая страница должна зарабатывать индексацию с нуля, теряя все накопленные сигналы ранжирования.
Чтобы выявить пробелы в маппинге, сравните полный список старых проиндексированных URL (выгрузите из Google Search Console до миграции или из предмиграционного сканирования) с файлом маппинга редиректов. Любой старый URL без соответствующего редиректа — пробел. Для старых URL, у которых нет прямого эквивалента на новом сайте, перенаправляйте их на наиболее релевантную родительскую страницу или рубрику, а не на 404. Редирект на хоть как-то релевантную страницу всегда лучше 404 с точки зрения ссылочного веса.
После миграции отслеживайте в Google Search Console ошибки сканирования на старых URL. Всплеск ошибок 404 на шаблонах старых URL указывает на отсутствующие редиректы. Проверяйте список ошибок 404 регулярно в первые 90 дней и добавляйте редиректы для любых высокотрафиковых или авторитетных старых URL, возвращающих ошибки.
Подтверждение в Google Search Console и управление картой сайта
Правильная настройка Google Search Console критична для индексации после миграции. Если миграция включает смену домена, структуры URL или протокола, настройки Search Console требуют конкретных обновлений, чтобы помочь Google корректно обработать переход.
Для доменных миграций (old-domain.com → new-domain.com) нужно, чтобы и старый, и новый домен были подтверждены в Google Search Console. Не удаляйте старый доменный ресурс. Он нужен для мониторинга обработки перехода со старых URL и для использования инструмента «Смена адреса». В ресурсе старого домена в Search Console перейдите в «Настройки» и используйте функцию «Смена адреса», чтобы официально уведомить Google о переезде сайта. Это ускоряет обработку смены домена и помогает сохранить сигналы ранжирования при переходе.
Для нового домена подтвердите его как доменный ресурс в Search Console сразу после миграции. Отправьте новую XML-карту сайта, содержащую все новые URL. Новая карта должна перечислять только новую структуру URL. Не включайте старые URL в новую карту. Если старая карта сайта ещё доступна на старом домене, оставьте её на время. Google просканирует старую карту, наткнётся на редиректы по каждому URL и пройдёт по ним к новым URL, что помогает обнаружению.
Для смен структуры URL на том же домене (например, /blog/post-title на /articles/post-title) отправьте обновлённую карту сайта с новыми шаблонами URL. Используйте инструмент «Проверка URL», чтобы запросить пересканирование самых важных новых URL. Google должен обнаружить смены URL через редиректы при обычном сканировании, но отправка карты сайта ускоряет процесс.
Для миграций с HTTP на HTTPS добавьте и подтвердите HTTPS-версию домена в Search Console, если ещё не сделали этого. Отправьте новую карту сайта с HTTPS-URL. Google обычно гладко обрабатывает миграции на HTTPS, но отслеживайте индексацию HTTPS-URL в последующие недели и убедитесь, что они заменяют HTTP-URL в индексе.
Частая ошибка — отправка карты сайта со старыми URL уже с нового сайта. После миграции проведите аудит карты сайта и убедитесь, что каждый URL в ней — валидный, не перенаправляющийся URL на новом сайте. Карта сайта, ссылающаяся на старые URL или перенаправляющиеся URL, посылает Google смешанные сигналы и может задержать индексацию новой структуры.
Изменения контента и шаблонов, влияющие на индексацию после миграции
Многие миграции сайта связаны не только со сменой URL. Они часто совпадают с редизайном, переключением CMS, реструктурой контента или обновлением шаблонов. Эти изменения уровня контента могут самостоятельно вызывать проблемы индексации, усугубляющие вызовы URL-миграции.
Когда смена CMS меняет, как страницы рендерятся, она может вносить проблемы JavaScript-рендеринга, которых раньше не было. Если Вы мигрировали с серверно-рендерящейся CMS вроде WordPress на JavaScript-фреймворк вроде React или Vue, страницы, ранее рендерившиеся на сервере, теперь могут рендериться на клиенте. Google теперь должен дождаться очереди JavaScript-рендеринга, чтобы обработать страницы, которые он раньше индексировал из исходного HTML. Только это может прибавить дни к таймлайну индексации каждой страницы.
Изменения шаблонов могут изменить внутреннюю структуру ссылок сайта. Новый дизайн с другой навигацией, другими виджетами сайдбара, другими ссылками футера или другими секциями связанного контента меняет, какие страницы ссылаются на какие. Если важные внутренние ссылки были убраны при редизайне, часть страниц может стать осиротевшими на новом сайте, даже если у них была сильная внутренняя перелинковка на старом. Просканируйте новый сайт и сравните внутренний ссылочный граф со старым, чтобы выявить страницы, потерявшие поддержку внутренних ссылок.
Изменения контента при миграции, даже с лучшими намерениями, могут влиять на индексацию. Если Вы переписали title, объединили или разделили страницы, добавили или убрали секции контента, изменили структуру заголовков, Google оценивает это как новый контент, а не узнаёт как обновлённую версию старого. Существенные изменения контента могут заставить Google переоценивать качество страницы с нуля, а не переносить авторитет старой страницы через редирект.
Самый безопасный подход к миграции — отделение URL-миграции от миграции контента и дизайна. Сначала мигрируйте URL и редиректы без изменения контента и шаблонов. Дайте Google обработать смену URL и стабилизировать индексацию за четыре-шесть недель. Затем постепенно вносите изменения дизайна и контента. Такой поэтапный подход облегчает диагностику проблем, потому что Вы точно знаете, какое изменение вызвало какой эффект. Делать всё сразу делает разбор практически невозможным, потому что проблемы URL, контента и техники переплетены.
Пошаговое руководство
Проверьте реализацию редиректов для всех старых URL
Выгрузите полный список индексированных URL старого сайта (из предмиграционного сканирования или выгрузки Search Console). Проверьте каждый редирект инструментом массовой проверки. Убедитесь, что каждый старый URL перенаправляется кодом 301 (не 302) на правильный новый URL. Выявите и исправьте цепочки редиректов (больше одного прыжка), петли (циклические редиректы) и пробелы маппинга (старые URL, отдающие 404). В приоритете исправляйте редиректы для страниц с наибольшим трафиком, наибольшим числом обратных ссылок и сильнейшими позициями. Каждый отсутствующий или сломанный редирект — слитый ранжирующий сигнал.
Настройте Google Search Console для нового сайта
Подтвердите новый домен или структуру URL в Google Search Console как доменный ресурс. Сохраните активным ресурс старого домена. При миграции доменов используйте инструмент «Смена адреса» в ресурсе старого домена, чтобы уведомить Google о переезде. Отправьте новую XML-карту сайта в новый ресурс, содержащую только новую структуру URL. Убедитесь, что карта успешно прочитана Google в течение 48 часов после отправки. Проверьте ресурс на отсутствие проблем с безопасностью или ручных мер, которые могли бы заблокировать индексацию.
Проведите аудит новой карты сайта на точность
Скачайте новую карту сайта и проверьте каждый URL в ней. Каждый должен возвращать код 200, не перенаправляться на другой URL и не нести тег noindex. Сопоставьте карту с полным списком страниц нового сайта, чтобы убедиться, что ни одна не пропущена. Уберите из карты любые URL, которые перенаправляются или возвращают ошибки. Если CMS автогенерирует карту сайта, убедитесь, что она настроена на новую структуру URL и не генерирует старые шаблоны. Отправьте очищенную карту в Google Search Console.
Проверьте новый сайт на технические блокировщики
Убедитесь, что robots.txt нового сайта разрешает сканирование всех важных страниц. Проверьте, что не остались глобальные теги noindex со staging- или dev-окружения. Многие CMS-платформы применяют noindex к staging-окружениям, и эта настройка может сохраниться после миграции на production-URL. Протестируйте рендеринг нового сайта инструментом «Проверка URL» на 5–10 страницах в разных секциях. Убедитесь, что контент страниц рендерится корректно и что никакие ошибки JavaScript или загрузки ресурсов не мешают Google видеть контент. Проверьте валидность SSL-сертификата, если мигрируете на HTTPS.
Отслеживайте переход индексации в Search Console
Сразу после миграции отслеживайте отчёт «Страницы» в Google Search Console и по старому, и по новому ресурсу ежедневно первые две недели, затем еженедельно следующие десять недель. Отслеживайте число проиндексированных страниц на новом ресурсе (должно расти), число проиндексированных страниц на старом ресурсе (должно убывать), число ошибок сканирования на обоих ресурсах и любые новые причины «не индексировано». Создайте таблицу с метриками во времени, чтобы выявлять тренды и остановки в процессе перехода.
Запросите индексацию для высокоприоритетных новых URL
Определите топ-50–100 самых важных страниц (наибольший трафик, наибольшая выручка, больше всего обратных ссылок) и проверьте, что они проиндексированы на новых URL. Для ещё не проиндексированных используйте инструмент «Проверка URL», чтобы запросить индексацию по отдельности. Для больших сайтов с сотнями или тысячами важных страниц используйте IndexBolt для массовой отправки новых URL ради быстрой индексации. В приоритете страницы, имевшие сильные позиции до миграции, — на них задержка индексации сильнее всего бьёт по бизнесу.
Расследуйте и исправьте устойчивые пробелы индексации после 30 дней
Через 30 дней любая страница, всё ещё не проиндексированная на новом URL, вероятно имеет специфическую проблему сверх обычного перехода миграции. Для каждой непроиндексированной страницы проверьте: работает ли корректно редирект со старого URL? Возвращает ли новый URL код 200? Существенно ли совпадает контент нового URL со старым? Нет ли новых проблем с каноническими тегами, noindex или рендерингом? Получает ли страница внутренние ссылки с других проиндексированных страниц нового сайта? Решайте каждую проблему индивидуально и повторно отправляйте на индексацию. Страницы, не проиндексированные через 60 дней без выявленных технических проблем, могут нуждаться в улучшении контента, чтобы соответствовать текущим порогам качества.
Частые проблемы и способы их решения
Старые URL продолжают появляться в выдаче через месяцы после миграции
Причина: Google ещё не просканировал и не обработал редиректы для этих URL. Это часто бывает для старых URL, которые редко сканировались до миграции, или для сайтов с очень большим числом URL. Это также может указывать, что редиректы возвращают 302 (временный) вместо 301 (постоянный), из-за чего Google держит старый URL в индексе, трактуя редирект как временный.
Решение: Убедитесь, что редиректы — 301, а не 302. Используйте инструмент «Проверка URL» в ресурсе старого домена в Search Console, чтобы запросить пересканирование устойчивых старых URL — это заставит Google наткнуться на редирект и обработать его. Если используете инструмент «Смена адреса», проверьте, что он настроен корректно. Для больших сайтов используйте IndexBolt для прямой отправки новых URL — это параллельно добавит новые страницы в индекс, пока идёт обработка редиректов.
Новые URL показываются как «Просканирована, но пока не проиндексирована» после миграции
Причина: Google просканировал новые URL, но решил, что они не соответствуют порогу качества для индексации. Это бывает, когда миграция включала существенные изменения контента, когда новый шаблон содержит меньше контента, чем старый (например, убраны секции сайдбара или связанных постов), или когда оценка качества нового сайта Google ниже оценки старого из-за технических проблем вроде медленной скорости страницы или проблем рендеринга.
Решение: Сравните контент на новом URL с кешированной версией старого. Определите, какой контент был удалён или изменён. Восстановите уникальный контент, утраченный при миграции. Проверьте скорость страницы и Core Web Vitals на новом сайте — существенное падение производительности может влиять на сигналы качества. Убедитесь, что внутренняя перелинковка из навигации нового сайта достигает этих страниц. Если контент эквивалентен, отправьте URL через IndexBolt, чтобы подтолкнуть Google к переоценке.
Массовый всплеск ошибок 404 в Search Console после миграции
Причина: Старые URL, которые Google ранее сканировал, теперь возвращают 404, потому что для них не были настроены редиректы. Это часто бывает, когда маппинг редиректов был неполным, покрывая только самые важные страницы вместо всех старых URL. Также бывает, когда старый сервер или хостинг отключают до того, как Google полностью обработал миграцию.
Решение: Проведите аудит списка ошибок 404 в Search Console по ресурсу старого домена. В приоритете реализуйте редиректы для 404-URL с значимым трафиком, обратными ссылками или позициями (сверьтесь с предмиграционными данными). Для URL без трафика и обратных ссылок 404 допустим — Google естественным образом уберёт их из индекса. Держите хостинг и конфигурацию редиректов старого домена активными как минимум полгода после миграции, чтобы у Google было время обработать все редиректы. Не отключайте хостинг старого домена преждевременно.
Позиции существенно упали после миграции и не восстанавливаются
Причина: Это строго не проблема индексации, но падения позиций часто сопровождают проблемы индексации при миграции. Частые причины: цепочки редиректов, разбавляющие ссылочный вес, отсутствующие редиректы для страниц с обратными ссылками, существенные изменения контента, которые Google оценивает менее благосклонно, более медленная скорость страницы на новом сайте, проблемы мобильной юзабилити на новом дизайне и потеря структурированных данных или расширенных результатов, повышавших CTR на старом сайте.
Решение: Проведите всестороннее сравнение старого и нового сайтов. Проверьте глубину цепочек редиректов и исправьте любые цепочки длиннее одного прыжка. Убедитесь, что у всех страниц с обратными ссылками есть прямые редиректы. Сравните Core Web Vitals старого и нового. Сравните реализацию структурированных данных. Сравните мобильную юзабилити. Устраните каждый разрыв. Если новый сайт технически здоров и эквивалентен по контенту, позиции обычно восстанавливаются за 60–90 дней, по мере роста уверенности Google в новом сайте. Устойчивые падения дольше 90 дней указывают на содержательное расхождение качества, требующее расследования.
Страницы одновременно проиндексированы и на старых, и на новых URL
Причина: Google в процессе перехода, но ещё не полностью обработал редирект для этих страниц. В результате один и тот же контент появляется в индексе на двух URL, что может вызывать путаницу в ранжировании и расщепление трафика между старыми и новыми URL. Обычно проходит само за четыре-шесть недель, но может задерживаться, если редиректы реализованы как 302 вместо 301.
Решение: Убедитесь, что все редиректы — 301 (постоянные). Если используются 302-редиректы, немедленно поменяйте на 301. Используйте инструмент «Проверка URL» для обоих URL — старого и нового. Если старый URL показан как индексированный с редиректом, Google его обрабатывает, но переход не завершён. Это нормально в первые недели. Если сохраняется дольше шести недель, запросите пересканирование старого URL, чтобы Google обработал редирект. Убедитесь, что канонические теги на новых URL самореферентные, а не указывают на старые.
Советы профи
Не дайте миграции сайта стереть месяцы SEO-прогресса. IndexBolt отправляет новые URL напрямую в Google, ускоряя переход со старых на новые и минимизируя пробел индексации. Отправьте полный список новых URL сразу после миграции и загоните новые страницы в индекс за часы, а не ждите недели, пока Google обработает каждый редирект.
100 бесплатных кредитов. Без банковской карты. Результаты менее чем за 24 часа.
Часто задаваемые вопросы
Сколько с точки зрения Google должна занимать полная миграция сайта?+
Большинство миграций сайта полностью обрабатываются Google за 60–90 дней. В первые две недели в индексе будет смесь старых и новых URL. К четвёртой неделе большинство новых URL должно быть в индексе, а большинство старых должно перенаправляться. К восьмой неделе переход должен быть в основном завершён, с оставшимися лишь крайними случаями. Очень большие сайты (миллионы страниц) могут занимать больше времени, потому что ёмкость сканирования Google конечна. Если миграция не завершилась существенно в течение 90 дней, скорее всего, есть технические проблемы (сломанные редиректы, заблокированное сканирование или проблемы рендеринга), требующие расследования.
Использовать 301 или 302 редиректы при миграции сайта?+
Всегда используйте 301 (постоянные) редиректы при миграциях. 301-редиректы говорят Google, что переезд постоянный, что заставляет Google передать ранжирующие сигналы новому URL и в итоге убрать старый из индекса. 302 (временные) редиректы говорят, что переезд может быть отменён, из-за чего Google держит старый URL в индексе и не передаёт авторитет полностью. Хотя Google заявлял, что в итоге трактует долгоживущие 302 аналогично 301, использование 301 с самого начала избегает задержек и двусмысленности. Единственная причина использовать 302 — если редирект действительно временный и Вы планируете восстановить старый URL.
Я мигрирую с HTTP на HTTPS. Нужно ли всё равно проделывать все эти шаги?+
Да, хотя миграции с HTTP на HTTPS — самый простой тип, и Google обрабатывает их наиболее гладко. Вам всё равно нужно реализовать 301-редиректы со всех HTTP-URL на HTTPS-эквиваленты, обновить карту сайта на HTTPS-URL, подтвердить HTTPS-ресурс в Google Search Console и обновить канонические теги на HTTPS. Главное преимущество миграции на HTTPS в том, что Google активно её поощряет, и обработка идёт быстрее. Большинство миграций на HTTPS полностью обрабатываются за три-четыре недели. Однако те же требования к маппингу редиректов, карте сайта и мониторингу применимы.
Что происходит с моими обратными ссылками при миграции на новый домен?+
Обратные ссылки на старый домен продолжают передавать ценность новому через 301-редиректы, но при этом есть некоторые потери. Google подтверждал, что 301-редиректы передают большую часть ссылочного веса, но точное значение не разглашается. Некоторые SEO-исследования предполагают потерю 10–15% на каждый прыжок редиректа. Чтобы максимально сохранить ценность обратных ссылок, реализуйте прямые однопрыжковые 301-редиректы с каждого старого URL на новый эквивалент. Для самых важных обратных ссылок (с самых авторитетных доменов) рассмотрите обращение к ссылающемуся сайту с просьбой обновить ссылку напрямую на новый URL, минуя редирект.
Можно ли мигрировать сайт поэтапно, по одному разделу за раз?+
Поэтапная миграция возможна, но добавляет сложность. Миграция по одному разделу (например, сначала `/blog/`, потом `/products/`, потом остальное) означает, что Google должен обрабатывать несколько раундов изменений вместо одного всеобъемлющего. Преимущество — ограничение радиуса поражения от ошибок. Если что-то пойдёт не так с миграцией блога, страницы товаров не затронуты. Недостаток — общий таймлайн миграции длиннее, а управление редиректами становится сложнее, когда часть разделов на новой структуре, а часть ещё на старой. Для большинства сайтов одна хорошо спланированная миграция предпочтительнее поэтапного подхода.