Новый дизайн сам по себе не требует менять адреса всех страниц. Сначала определите, что меняется в предложении компании, структуре и содержании. Если полезная страница сохраняет назначение, сохранение её URL может упростить переход. Решение должно приниматься по каждой группе материалов до запуска, а не после появления ошибок.
Для заказчика главный рабочий документ — карта переноса: старый адрес, назначение страницы, решение, новый адрес и результат проверки. Она связывает редакционные решения с настройками разработчика. Ниже — порядок подготовки и учебный пример; это не фактическая миграция CoreWeb или клиента.
Зафиксируйте границы изменений
Отметьте отдельно дизайн, структуру разделов, CMS, домен и языковые версии. Это разные изменения с разными зависимостями. Например, новая CMS может потребовать переноса полей каталога, а новое меню — вообще не затрагивать адрес карточки товара.
Составьте короткую записку: зачем нужен переход, какие страницы входят в первый выпуск, кто согласует содержание и кто принимает технический результат. Если одновременно меняются домен, CMS и предложение, выделите проверки каждого изменения: иначе причину проблемы будет трудно установить.
До карты URL полезно подготовить структуру корпоративного сайта и определить материалы для разработки. Пустой новый раздел ещё нельзя считать полноценной заменой старого.
Соберите инвентаризацию старых адресов
Объедините список страниц из CMS, sitemap, обхода сайта, поисковых кабинетов и аналитики, если к ним есть доступ. В каждом источнике отметьте дату выгрузки и период. Один обход меню может пропустить страницу, на которую люди попадают из поиска или старой внешней ссылки.
Для каждого адреса запишите:
- Тип и назначение: услуга, статья, карточка, документ или другое содержимое.
- Язык и связанный материал на другом языке, если он существует.
- Текущее состояние: доступен, перенаправляется, удалён, требует выяснения.
- Известные входы и ссылки с указанием источника данных.
- Важные элементы: форма, файл, изображения, характеристики, связанные записи.
- Владельца решения и нерешённый вопрос.
Отсутствие визитов в доступном отчёте не доказывает бесполезность страницы: период может быть коротким, доступ неполным, а назначение — поддерживать продажу после личного контакта. Если данных нет, пишите «нет данных», а не ноль. Не удаляйте материал только ради сокращения списка.
Выберите соответствие по смыслу
Сначала решите, куда должна попадать аудитория старой страницы. Новый адрес должен помогать решить ту же задачу. Если две услуги объединяются, новая страница должна объяснять оба направления, а не только иметь удобное название.
Яндекс рекомендует при изменении структуры сопоставлять старые и новые адреса, настраивать перенаправления и обновлять ссылки внутри сайта. Для удалённой страницы важно оценить наличие действительно подходящего раздела. Рекомендации Яндекса по структуре и дизайну.
Учебная карта переноса
Все пути в таблице вымышлены, не являются действующими адресами CoreWeb и показаны как текст. Решения иллюстрируют обсуждение, а не готовую конфигурацию сервера.
| Старый путь | Решение | Цель | Приёмочная проверка |
|---|---|---|---|
/services/audit | Сохранить | Тот же адрес | Актуальная услуга и форма доступны |
/old-consulting | Перенести | /services/consulting | Постоянный редирект, соответствующее содержание |
/services/team-training | Объединить | /services/training | Новая страница объясняет прежнее направление |
/promo/closed-event | Удалить без замены | Нет | Реальный 404 или 410, полезная навигация на странице ошибки |
/files/catalog.pdf | Перенести документ | /documents/catalog.pdf | Открывается правильный файл нужной версии |
/en/services/audit | Сохранить язык | Тот же EN-адрес | Не подменяется русской страницей |
Если подходящей замены нет, не направляйте всё на главную. Google предупреждает о нерелевантных массовых редиректах и допускает 404/410 для удалённого содержимого. Объединённые материалы можно направить на страницу, которая действительно их заменяет. Перенос URL в Google Search.
К таблице реального проекта добавьте ID решения, ответственного, дату согласования и ссылку на доказательство проверки. Для адреса с параметрами отдельно выясните, меняют ли параметры содержимое или лишь описывают источник перехода; не объединяйте варианты автоматически по внешнему сходству.
Проверьте перенаправления и новые страницы
Для постоянного переноса страницы обычно рассматривают серверные 301 или 308; временные изменения требуют отдельного решения. Назначение этих кодов описано в документации Google о редиректах и справке Яндекса.
В приёмке смотрите не только конечную страницу в браузере, но и исходный ответ сервера. Браузер может автоматически пройти несколько перенаправлений и скрыть неправильный промежуточный адрес. Попросите разработчика сохранить статус, Location, конечный URL и результат проверки содержания. Цикл или переход на ошибку не является выполненным переносом.
Проверьте согласованные варианты адреса: язык, завершающий слеш и значимые параметры. Для объединений откройте несколько старых страниц из одной группы; для документов проверьте сам файл, а не только код ответа. По каждому исключению должно быть явное решение, а не молчаливый пропуск.
Сверьте содержание и поисковые настройки
Проверьте, что новые страницы содержат согласованные тексты, изображения, файлы и данные. Наличие заголовка и красивого макета не подтверждает перенос таблицы характеристик или работоспособность формы. Сравнивайте по полям и сценариям, а не только по количеству записей.
Яндекс отдельно рекомендует после обновления убедиться, что содержимое доступно роботу, ссылки актуальны и страницы могут участвовать в поиске. Для проекта оформите проверку доступности как отдельный пункт, не смешивая её с визуальным согласованием. Смена структуры сайта.
Для новых публичных URL проверьте canonical, внутренние ссылки и sitemap; убедитесь, что ограничения тестовой версии не перенесены на страницы, предназначенные для индексации. При смене домена нужен отдельный план: инструмент Change of Address в Google не предназначен для обычной смены путей внутри того же домена. Порядок переноса Google.
Подготовьте бланк приёмки
| Объект проверки | Ожидаемый результат | Что сохранить |
|---|---|---|
| Сохранённый URL | Нужная страница без случайного перенаправления | Адрес, статус и версия сборки |
| Перенесённый URL | Согласованный постоянный переход к замене | Исходный ответ, Location, конечный статус |
| Удалённый материал | Согласованное состояние без ответа 200 с пустотой | Статус и снимок страницы ошибки |
| Контент и документы | Верные поля, изображения и версии файлов | Сверка с реестром материалов |
| Форма обращения | Подтверждённый сценарий доставки тестового запроса | Обезличенное доказательство у получателя |
| Языковая версия | Соответствующий язык и рабочие переходы | Адреса и результат ручной проверки |
| Поисковые настройки | Настройки соответствуют согласованной карте | Проверенные canonical, sitemap и ограничения |
Используйте статусы «прошло», «не прошло», «не проверено». Последний требует причины, ответственного и следующего действия. Недоступный кабинет аналитики не превращается в нулевую посещаемость, а закрытый тестовый контур не доказывает состояние production.
Заранее договоритесь, какие проблемы останавливают запуск, кто принимает решение и как восстанавливать предыдущую версию. Учтите данные, которые поступят после переключения: откат приложения не должен означать потерю новых обращений или редакционных изменений. Условия приёмки можно оформить через карточки проверяемых требований.
Организуйте наблюдение после запуска
Назначьте владельца проверки форм, ошибок и поисковых отчётов. Запишите дату выпуска и версии карты переноса. В первые проверки включите важные входные страницы, новые ошибки, доставку обращений и доступность документов; интервал повторения согласуйте с рисками проекта.
Сопоставляйте одинаковые периоды и учитывайте задержку отчётов, рекламу и изменения предложения. Изменение показов после редизайна ещё не объясняет его причину. Редиректы не следует отключать сразу после выпуска: Google рекомендует сохранять их как можно дольше, обычно не менее года. Поисковая видимость при переносе может колебаться; гарантировать её сохранение нельзя. Наблюдение за переносом.
Если планируется обновление сайта компании, в CoreWeb можно обсудить редизайн и план перехода. Подготовьте текущий адрес, причину изменений, список важных страниц и известные ограничения — это даст основу для предметного обсуждения объёма.
Для последовательности переключения выполните практикум по плану запуска. Он связывает карту переноса с ответственными, проверками и условиями возврата.
Если масштаб изменений ещё не выбран, начните с дерева выбора между редизайном и доработками: оно помогает определить проблему и сравнить варианты до планирования переноса.
Соберите старые и новые адреса в планировщике миграции: зафиксируйте решение по каждой странице, ответственного и доказательство ручной проверки, затем скачайте план.
Разделите миграцию данных, адресов и инфраструктуры. Для каждого постоянного перехода используйте карточку редиректа 301, чтобы проверить исходный ответ и конечную страницу.
При сверке поисковых настроек используйте карточку canonical: сравните выбранный основной URL со значением из готовой страницы и результатом его открытия.