Как подготовить сайт к запуску без потери SEO-трафика

Как подготовить сайт к запуску, не потеряв SEO-трафик

Запуск — это не только про дизайн. Это ещё и про поиск. Если вы планируете, как подготовить сайт к запуску, не потеряв SEO-трафик, самый безопасный подход — не полагаться на память или обещания в духе «проверим потом». Запишите изменения постранично и заранее решите, что останется без изменений до выкладки кода.

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

1. Определите SEO-элементы, которые нельзя менять до запуска

Начните с короткого seo чек лист перед запуском сайта по тем частям страницы, которые могут нести поисковую ценность. Включите URL, title-теги, meta description, заголовки, внутренние ссылки и канонические теги. Список должен быть достаточно коротким, чтобы его можно было прочитать за один подход, но при этом достаточно точным, чтобы разработчик мог отметить каждый пункт как сохранённый, изменённый или удалённый.

Не делайте чек-лист абстрактным. Запишите точный шаблон URL, например /services/ или /blog/post-name/, и укажите, остаётся ли он прежним. Если title-тег переписывают, зафиксируйте старый заголовок и новый. Если канонический тег указывает в другое место, это тоже должно быть отдельной строкой. Здесь важны даже мелочи.

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

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

2. Сопоставьте старый сайт с новым постранично

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

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

Хорошая карта замещения помогает и командам дизайна и контента. Если /pricing-old/ теперь стал /pricing/, никому не нужно гадать. Если три страницы продукта объединяются в одну более сильную страницу, это должно быть очевидно ещё до запуска. Домыслы потом создают хаос с редиректами.

Один практичный приём: распечатайте карту и вручную проведите самые важные 20 URL. Звучит старомодно. Но это работает. На бумаге пропущенные адреса заметнее, чем в перегруженной таблице на 400 строк.

3. Защитите страницы, которые уже приносят поисковый трафик

Используйте данные аналитики и Search Console, чтобы найти страницы, которые уже получают показы, клики и ссылки. Эти страницы — критически важные активы запуска. Относитесь к ним особенно аккуратно, потому что это не просто контент, а источники трафика с историей.

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

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

Здесь же полезен мониторинг. Если вы уже используете платформу для веб-аналитики и мониторинга, сравните последние 30 дней, последние 90 дней и экспорт из Search Console рядом друг с другом. Три взгляда лучше одного: они показывают, какие страницы стабильны, а какие уже хрупкие.

4. Настройте правила редиректов для удалённого, переименованного и объединённого контента

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

Редиректы — это не украшение. Это карта маршрута, по которой поисковые системы и посетители идут после запуска. Цепочка редиректов замедляет работу и может размывать сигналы. Петля может зациклить сканеры. «Мягкая замена», которая выглядит похоже, но имеет другой смысл, на практике может вести как тупик.

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

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

5. Сохраните сигналы индексации в новой версии

Перед запуском проверьте директивы robots, canonical, пагинацию, hreflang и записи в sitemap. Эти сигналы подсказывают поисковым системам, что сканировать и какую версию предпочесть. Если они противоречат друг другу, сканер может довериться не тому сигналу и проигнорировать нужную вам страницу.

Отдельного внимания заслуживают canonical. Страница, которая указывает canonical не на тот URL, может исчезнуть из поисковой выдачи, даже если в браузере всё выглядит нормально. Директивы robots тоже могут быть не менее опасны. Один случайный noindex на шаблонной странице может заблокировать сразу много URL. Это неприятный сюрприз.

Пагинацию нужно тестировать на страницах с несколькими экранами, а hreflang — там, где есть языковые версии. Карта сайта не магия, но она помогает поисковым системам быстрее найти правильные URL после запуска. Убедитесь, что sitemap отражает уже живую структуру, а не старый черновик.

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

6. Проверьте запуск на staging-среде на SEO-регрессии

Просканируйте staging-сайт и сравните его со старым сайтом. Ищите битые ссылки, отсутствующие метаданные, циклы редиректов, дубли страниц и случайные настройки noindex. Именно на staging вы ловите очевидные проблемы до того, как они станут публичными.

Хорошая проверка staging — это не один проход. Если сайт большой, сделайте как минимум два: один по структуре контента и один по отрендеренным страницам. Некоторые проблемы видны только после загрузки JavaScript. Другие — только в исходнике. Это может раздражать, но это важно.

По возможности сравнивайте страницу за страницей. Проверяйте title, descriptions, H1, canonical и коды ответа. Если у старой страницы был чистый 200, а staging-версия отдаёт 302 на staging-URL, она не готова. Если шаблон создаёт дубли страниц фасетной навигации, исправьте это до запуска. После запуска это будет стоить больше времени.

Staging — это также правильное место для проверки систем доставки контента, которые отправляют уведомления после запуска или оповещения пользователям. Если ваша команда также использует слой email, SMS и push-рассылок, убедитесь, что в сообщениях о запуске не стоят черновые URL. Письмо о запуске с мёртвой ссылкой — это маленькая катастрофа, причём публичная.

7. Отслеживайте первый обход после запуска и паттерны трафика

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

Особенно внимательно проверьте первые 24 часа. Затем — ещё раз через 48 часов. Резкое падение показов на одном шаблоне обычно означает структурную проблему, а не сезонность. Всплеск 404 обычно говорит об ошибке сопоставления или пропущенном редиректе. Странный паттерн обхода может указывать на заблокированные ресурсы или плохой canonical-тег.

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

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

8. Заранее подготовьте процесс быстрого исправления на неделю запуска

Назначьте ответственных ещё до дня запуска. За контент должен отвечать один человек, за разработку — один, за SEO — один. Если проблема появится в 10 утра, никто не должен выяснять, кто вообще имеет право это исправлять.

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

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

Если сайт связан с продуктом с большим объёмом контента, держите рядом и команду поддержки. После запуска страницы могут требовать обновлений, и эти обновления не должны ждать следующего спринта. Для дальнейшего сопровождения после релиза см. поддержку сайта после запуска. Один запуск — это событие; окно восстановления — это процесс.

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