Запуск нового сайта и редизайн действующего — два момента, когда бизнес чаще всего теряет накопленные позиции в Google, причём не из-за содержания, а из-за технических деталей, которые визуально незаметны. Сайт может выглядеть даже лучше прежнего и при этом полностью пропасть из поиска на несколько недель. Ниже — чек-лист, который закрывает типичные причины таких провалов, до того как они случились, а не после.
01 Почему сайты теряют трафик при запуске и редизайне
Падение позиций после запуска или редизайна почти никогда не связано с качеством дизайна или контента — Google не умеет оценивать красоту интерфейса. Причина почти всегда техническая, и в большинстве случаев одна и та же схема: старые адреса страниц перестали существовать, а новые для поисковика ещё не существуют.
Три сценария встречаются чаще остальных:
- Сменился адрес страниц без 301-редиректов — старый URL отдаёт 404, накопленный вес и позиции страницы обнуляются;
- Индексацию случайно заблокировали — на новой версии сайта остался noindex или запрет в robots.txt, унаследованный с тестового домена;
- Пропало содержание, за которое страница ранжировалась — при редизайне текст сократили или переписали, и страница перестала отвечать на прежний запрос.
Каждый из этих сценариев предотвращается заранее, а не лечится после того, как трафик уже упал. Если позиции всё же просели и причина неясна, общая диагностика разобрана в статье почему сайт не растёт в Google — этот же чек-лист сужает список причин именно до контекста запуска и редизайна.
02 До запуска: техническое SEO-задание для разработчика
Большинство проблем закладывается на этапе разработки, когда SEO-требования не были письменно зафиксированы и разработчик принимал решения по умолчанию. Техническое задание закрывает это заранее.
В задание для разработчика должны входить как минимум такие пункты:
- тестовая версия сайта (staging) закрыта от индексации паролем или мета-тегом noindex, а не только через robots.txt;
- структура URL совпадает с текущей, если явной причины её менять нет;
- заголовки Title, метаописания, атрибуты alt и структура заголовков H1–H3 переносятся с текущего сайта, а не создаются заново по умолчанию CMS;
- на новой версии настроены канонические адреса без случайных дублей по параметрам URL;
- скорость загрузки и мобильная версия проверены до запуска, а не после жалоб пользователей.
Письменное задание даёт разработчику чёткие критерии приёмки и снимает ситуацию, когда «не терять позиции» остаётся устной договорённостью без конкретных технических требований.
03 Карта 301-редиректов: как её составить
Если структура адресов страниц меняется хотя бы частично, карта редиректов обязательна. Это таблица вида «старый URL → новый URL», по которой сервер автоматически перенаправляет пользователей и поисковых роботов на актуальный адрес, передавая накопленный вес страницы.
Карту составляют в три шага: сначала выгружают полный список текущих URL сайта — из sitemap.xml, логов сервера или отчёта об индексировании страниц в Search Console; затем каждому старому адресу подбирают наиболее близкий по смыслу новый; и в последнюю очередь редиректы тестируют на staging-версии до того, как сайт станет публичным. Официальные рекомендации Google по переносу сайта с изменением адресов подробно разбирают эту логику в документации о переезде сайта с изменением URL.
Частая ошибка — направлять все старые адреса на главную страницу вместо конкретной новой страницы. Формально редирект есть, но он не передаёт релевантность, и Google фактически считает это той же потерей позиций, что и отсутствие редиректа вовсе.
04 Robots.txt, sitemap.xml и canonical на новом сайте
Три технических файла определяют, что поисковый робот вообще увидит на новом сайте. Ошибка в любом из них способна закрыть от индексации весь сайт, даже если внешне он работает идеально.
Что нужно проверить перед публичным запуском:
- robots.txt — не должен содержать директиву Disallow: /, унаследованную с тестового домена; принципы работы файла и его директив описаны в документации Google о robots.txt;
- sitemap.xml — содержит актуальный список новых адресов без старых URL, обновлён и готов к отправке через Google Search Console, а требования к самому файлу описаны в документации по картам сайта;
- canonical — на каждой странице указывает на саму себя или на правильную основную версию при дублях; ошибки здесь Google описывает в материале о объединении дублирующихся URL.
Все три файла стоит проверить именно на staging-версии перед переключением домена, а не после — исправлять индексационную ошибку постфактум всегда дольше и дороже, чем не допустить её.
05 Что проверить в день запуска
В момент переключения домена на новую версию счёт идёт на часы: чем раньше найдена техническая ошибка, тем меньше реальных потерь в индексации.
Минимальный набор проверок сразу после запуска:
- ключевые страницы сайта отдают код ответа 200, а не 404 или 500 — проверяется вручную или через сервис массовой проверки кодов ответа;
- robots.txt новой версии больше не блокирует сканирование;
- ресурс подтверждён в Search Console, а свежий sitemap.xml отправлен через раздел «Файлы Sitemap»;
- выборочные редиректы со старых URL проверены вручную — открываются в браузере и ведут на релевантную новую страницу с кодом 301, а не 302;
- счётчики аналитики и коды конверсий установлены на новой версии и фиксируют события.
Если хотя бы один пункт не выполнен, лучше отложить публичный запуск на несколько часов, чем потом устранять последствия индексационной ошибки, которая уже успела зафиксироваться в поиске.
06 Мониторинг первых 2–4 недель после запуска
Даже при идеально настроенном запуске первые недели требуют более частого контроля, чем обычный режим работы с сайтом, — именно в этот период технические ошибки заметнее всего влияют на индексацию.
В этот период стоит проверять чаще обычного: отчёт об индексировании страниц в Search Console — не растёт ли число страниц со статусом «Обнаружена, но не проиндексирована»; отчёт «Эффективность» — не просели ли показы по ключевым запросам, на которых сайт ранее ранжировался; а также позиции по контрольному списку из 15–20 самых ценных коммерческих запросов, чтобы заметить проблему раньше, чем она станет заметна в выручке.
07 Что делать, если позиции всё же просели
Даже при подготовленном запуске небольшая просадка позиций на 1–2 недели — нормальная реакция поисковика на изменения, а не повод для паники. Тревогу должно вызывать падение, которое не восстанавливается или продолжает нарастать.
Если спустя месяц позиции не вернулись, стоит по порядку проверить: не пропущен ли какой-то старый URL в карте редиректов, не остался ли где-то noindex или Disallow, унаследованный со staging-версии, не изменилось ли по факту содержание страниц, за которое они ранее ранжировались. Полный алгоритм такой диагностики, применимый не только к запуску, а к любому падению трафика, разобран в статье почему сайт не растёт в Google. Если самостоятельно найти причину не получается, дальше требуется полноценный SEO-аудит сайта, который сверяет техническое состояние новой версии с тем, что было до изменений.
После запуска или редизайна отдельные страницы иногда всё равно не индексируются даже при правильно настроенном sitemap — что делать в этом случае, разобрано в статье как ускорить индексацию сайта в Google.
Ещё до запуска чек-листа технической проверки стоит определиться с платформой сайта — от выбора CMS зависит, какие пункты вообще будут доступны для настройки; сравнение платформ — в статье сравнение CMS для SEO: WordPress vs Tilda vs Shopify.
Что бывает, если часть этого чек-листа пропустить при переезде на новый домен, разобрано на иллюстративном примере в статье восстановление трафика после переезда сайта.
08 Частые вопросы
За сколько до запуска нужно готовить SEO-часть?
Минимум за 2–3 недели, если речь о редизайне существующего сайта с уже наработанными позициями: этого времени хватает, чтобы собрать карту редиректов, согласовать её с разработчиком и протестировать на staging-версии. Для сайта без истории в поиске критичной спешки нет, но чек-лист всё равно стоит пройти до, а не после запуска.
Что делать, если сайт уже запустили без карты редиректов?
Составить карту постфактум и добавить 301-редиректы как можно быстрее — потерянный вес страниц частично восстанавливается, если сделать это в течение нескольких недель после запуска. Чем дольше старые URL отдают 404, тем больше накопленного ссылочного веса и позиций пропадает безвозвратно.
Нужно ли закрывать staging-версию сайта от индексации?
Обязательно. Тестовый домен, доступный поисковым роботам, создаёт дубли контента и может случайно проиндексироваться раньше основного сайта. Закрывают его паролем на уровне сервера или мета-тегом noindex, а не через robots.txt — файл сам по себе не запрещает индексацию уже найденных страниц.
Как долго восстанавливаются позиции после редизайна?
При аккуратной миграции с полной картой редиректов заметная просадка обычно не превышает 1–2 недель, а позиции возвращаются к прежнему уровню за 4–8 недель. Если редиректы настроены с ошибками или отсутствуют, восстановление может растянуться на месяцы либо не произойти совсем, потому что накопленный вес страниц теряется безвозвратно.
Обязательно ли менять структуру URL при редизайне?
Нет, и по умолчанию лучше этого не делать. Даже неидеальный на вид адрес страницы уже накопил историю индексации, внешние ссылки и позиции. Менять структуру URL стоит только при явной технической необходимости — и в этом случае обязательно закрывать переход полной картой 301-редиректов.
Кто должен отвечать за SEO-часть запуска — разработчик или SEO-специалист?
Формально ставит задачи SEO-специалист — именно он знает, какие страницы приносят трафик и какие технические требования нельзя нарушать. Но выполняет их разработчик, поэтому техническое SEO-задание должно быть письменным и максимально конкретным, а не устной договорённостью «не потерять позиции».