Содержание 12 разделов ↘
Что получится: инвентаризация действующих адресов, решение по каждому URL, карта редиректов, SEO-требования для разработчика и список проверок до и после запуска.
Гайд подходит для смены дизайна, архитектуры или CMS действующего сайта. Он не обещает, что трафик совсем не колебнётся: поисковым системам нужно переобойти страницы, а часть изменений может повлиять на видимость. Задача — избежать предотвратимых потерь.
Сначала определите: меняются ли адреса и содержание
Редизайн без изменения URL и содержания обычно проще, чем переезд структуры сайта. Но даже в таком случае можно потерять текст, навигационные ссылки, индексируемые разделы, корректную SSR-разметку или мобильную доступность. Поэтому проверка нужна в любом сценарии.
| Сценарий | Главный риск | Что готовить |
|---|---|---|
| Только новый дизайн | Пропали ссылки, контент или рендер | Сравнение страниц и HTML до/после |
| Изменение структуры разделов | Старые адреса дают открывают страницу ошибки 404 или ведут не по смыслу | Карту старый → новый URL |
| Смена CMS | Технические отличия в canonical, robots, sitemap | Crawl, сверку метаданных и тестовый выпуск |
| Новый домен | Нарушение переезда и потеря связей | Дополнительно отдельный план доменного переезда |
Шаг 1. Снимите состояние старого сайта
До изменения кода сохраните результаты обхода действующего сайта: URL, статус ответа, H1, title, description, canonical, robots, внутренние ссылки, изображения, данные структурированной разметки. Отдельно выгрузите органические посадочные страницы, клики/показы, целевые действия и известные ссылки на сайт.
Включите страницы, которые отсутствуют в текущей карте сайта: старые статьи, карточки товаров, PDF, изображения и адреса с внешними ссылками. Для каждой важной страницы зафиксируйте не только поисковый трафик, но и её задачу: информационная, коммерческая, поддержка существующих клиентов.
Не удаляйте страницу только потому, что она почти не получает кликов сегодня. Проверьте, есть ли у неё полезный контент, внутренние связи, внешние ссылки, сезонный спрос или роль в пользовательском пути.
Шаг 2. Решите судьбу каждого важного адреса
Управляемая миграция строится по таблице: сохранить, перенести, объединить или удалить. Это не решение «чтобы не было 404». Каждый переадресованный URL должен вести на страницу с близким смыслом, а не на главную.
→
→
→
СОХРАНИТЬ: лучше оставить существующий URL, если он понятен, корректен и соответствует задаче. ПЕРЕНЕСТИ: подготовить постоянный серверный редирект 301/308 на близкую новую страницу. ОБЪЕДИНИТЬ: переносить уникальную полезную информацию, а затем направлять старые URL на объединённый материал. УДАЛИТЬ: возвращать корректный 404 или 410, когда содержательной замены нет; это не обязательно ошибка проекта.
/catalog/windows-pvc/ → /windows/pvc/ — допустимый редирект, если товарная категория сохранена. /catalog/windows-pvc/ → / лишь потому, что категорию удалили, — плохое решение: человек и поисковая система попадают на страницу о другом.
Шаг 3. Подготовьте карту URL и критерии соответствия
Не ограничивайтесь парой столбцов. Добавьте тип страницы, SEO-трафик по возможности, решение, целевой URL, новый H1, ответственного, статус проверки и комментарий. При слиянии нескольких старых страниц в одну убедитесь, что новая действительно отвечает на их намерения.
| Старый URL | Решение | Новый URL | Проверка |
|---|---|---|---|
| /services/old-a/ | keep | Тот же адрес | 200, контент сохранён |
| /old-catalog/ | move | /catalog/ | 301 → финальный 200 |
| /article-a/ | merge | /guide-a/ | 301 и перенос уникального смысла |
| /obsolete/ | remove | Пусто | 404/410 без ложного редиректа |
Скачать таблицу миграции URL (.csv) ↗
Шаг 4. Передайте разработчикам SEO-требования до реализации
- Сохранить тексты и смысл важных страниц; не заменять содержательные описания декоративными блоками.
- Оставить один H1 и корректную структуру H2/H3; переносить title и description с необходимой редактурой, а не случайной генерацией.
- Сделать ссылки доступными в HTML с обычным
href, а важный контент — в серверном HTML или предсказуемом рендере. - Проверить canonical: новая индексируемая страница обычно указывает на собственный URL, а не на старую версию.
- Подготовить XML sitemap новых canonical URL, robots.txt, внутренние ссылки, пагинацию и структурированные данные по реальному типу страницы.
- Сохранить полезные изображения и документы, обеспечить перенос их адресов или корректное перенаправление.
Шаг 5. Проверьте staging до переключения
Тестовая версия должна быть закрыта от индексации, но доступна аудитору для проверки без случайных блокировок по сети. Проверьте HTTP-ответы, рендер заголовков, внутренние переходы, мобильные версии, формы и аналитику. На staging может стоять noindex; перед выпуском убедитесь, что этот запрет не попадёт на production.
Сравните ключевые URL старого и нового сайта по содержанию, структуре и типу намерения. Проверьте новый каталог, страницы услуг, материалы, карточки товаров и страницы с большим числом входов.
Шаг 6. Настройте и проверьте редиректы
- Загрузите карту URL в выбранный механизм сервера или CMS.
- Для каждого перенесённого или объединённого адреса проверьте постоянный редирект и конечный ответ 200.
- Найдите циклы, цепочки, 302 там, где нужен постоянный переезд, и редиректы на нерелевантные страницы.
- Проверьте, что внутренние ссылки ведут сразу на новые адреса, а не через 301.
- Проверьте canonical, sitemap и версии со слешем/без слеша, HTTP/HTTPS, www/без www.
- После запуска проверьте не только URL из sitemap, но и известные старые адреса из аналитики и логов.
Google Search Central рекомендует постоянные серверные редиректы на подходящие новые адреса и предупреждает о цепочках; Яндекс Вебмастер также рекомендует 301 при изменении структуры. Не пытайтесь решить миграцию универсальным правилом «всё на главную».
Шаг 7. Выпустите новую версию с контрольными точками
Назначьте человека, принимающего решение о запуске и откате. Сохраните резервную копию базы, версии кода и исходных URL. В момент релиза проверьте 10–20 заранее выбранных критических страниц: HTTP 200, правильный HTML, title, canonical, отсутствие production noindex, рабочие контакты, аналитические события и редиректы.
Если важные страницы возвращают ошибку, а canonical и robots настроены неправильно, не ждите «пока поисковик обновится». Это техническая проблема, которую нужно исправлять сразу.
Шаг 8. Следите за индексацией и коммерческими входами
После запуска регулярно смотрите органические посадочные, ошибки сканирования, рост 404, индексацию и переходы со старых URL. Сопоставляйте прежние и новые страницы через карту соответствий. В первые недели не делайте вывод о качестве редизайна только по дневным колебаниям поискового трафика.
Отдельно отслеживайте коммерческие события: обращения, продажи, конверсию важных разделов. Если позиции сохранены, но заявки упали, проверьте изменения предложения, форм, мобильного UX и доступности товара — SEO не сводится к индексации.
Четыре ошибки, которые особенно дорого обходятся
- Старый сайт удалён до выгрузки списка адресов. Потеряна карта страниц и ориентир для сравнения.
- 301 направляет всё на главную. Невозможно восстановить смысл прежних страниц.
- Оставили noindex со staging. Даже работающий новый сайт может перестать индексироваться.
- Проверили только дизайн. Реальные пользователи видят красивый экран, а сервер отдаёт неполный HTML или форму без доставки заявки.
Финальная проверка миграции
- Сохранены crawl и органические входы старого сайта.
- Для каждого важного URL есть решение keep/move/merge/remove.
- Заведена карта постоянных редиректов без цепочек и циклов.
- Сохранены ключевые тексты, метаданные, canonical и ссылки.
- Проверены sitemap, robots, SSR и schema по реальному содержанию.
- Staging закрыт; production доступен индексации.
- Назначены ответственные за мониторинг и откат.
- Проверяются поисковые и коммерческие показатели после запуска.
Редизайн начинают с карты действующих страниц, а не с макета
У вас есть рабочее задание для SEO, редактора и разработки. По нему можно принимать изменения и разбирать потери на конкретных URL, а не спорить о том, «понравился ли поиску новый сайт».
