Редизайн часто начинается с макетов.
Меняется первый экран, меню становится компактнее, каталог получает новые фильтры, карточки услуг выглядят современнее. Старый сайт постепенно превращается в красивый прототип нового.
А потом возникает вопрос: что делать со всем содержимым старого сайта?
Что переносить?
Страницы, статьи, документы, изображения, формы, таблицы, FAQ и другие материалы.
Что менять?
Устаревшие тексты, структуру, условия, цены, файлы и контент, который больше не решает прежнюю задачу.
Перенести всё? Переписать? Скопировать только основные страницы? Старые статьи удалить? Десятки PDF оставить на прежних адресах? А если две старые страницы в новой структуре превращаются в одну?
Именно на этом этапе редизайн перестаёт быть исключительно дизайнерской задачей.
У существующего сайта уже есть история: страницы, которые находят в Google, ссылки из статей и писем, изображения, документы, формы, инструкции, метаданные, посадочные страницы рекламных кампаний. Часть этого действительно устарела. Другая часть может выглядеть неприметно, но продолжать приносить посетителей, обращения или поддерживать важные разделы сайта.
Контент-миграция – это не копирование старого сайта
Самый простой сценарий выглядит так:
Технически это возможно.
Но вместе с полезными материалами на новый сайт переедут:
- устаревшие страницы;
- дубли;
- тексты, которые давно никто не обновлял;
- ненужные изображения;
- старые PDF;
- страницы бывших услуг;
- неработающие призыв к действию;
- материалы, созданные под прежнюю структуру;
- внутренние ссылки на уже несуществующие разделы;
- контент, назначение которого никто уже не может объяснить.
Получается новый сайт со старым содержимым и старыми проблемами.
Поэтому редизайн – удобная точка для ревизии контента. Новый сайт не обязан повторять старый один в один. Но и терять полезные материалы только потому, что они не поместились в новый макет, тоже нельзя.
Если редизайн является частью полной пересборки проекта, контент-миграцию лучше планировать вместе с архитектурой нового сайта, а не оставлять на последний день перед запуском.
Контент-миграция, SEO-миграция и технический перенос – разные задачи
Эти процессы тесно связаны, поэтому их легко смешать. Но отвечают они на разные вопросы.
Контент-миграция
Что должно переехать на новый сайт: сохранить страницу, обновить текст, объединить материалы, удалить старое или создать новое.
SEO-миграция
Что произойдёт с URL, перенаправлениями, canonical, sitemap, внутренними ссылками, индексированием и поисковой историей.
Техническая миграция
Как выбранное содержание физически переедет в новую CMS: поля, изображения, файлы, категории, связи, формы и компоненты.
Правильная последовательность выглядит примерно так:
Если начать сразу с переноса, разработчики уже мигрируют материалы, судьба которых ещё не определена.
Настройка редиректов, canonical, sitemap, кодов ответа и других последствий смены URL относится уже к технической SEO-оптимизации. Здесь задача другая – определить судьбу самого содержания.
Сначала нужно понять, что вообще есть на старом сайте
Перед редизайном лучше не полагаться ни на меню, ни на карту сайта, ни на память владельца.
Меню показывает только то, что в него добавили. На реальном сайте могут существовать старые посадочные, страницы акций, архивные статьи, PDF, изображения, URL из предыдущих версий сайта и материалы, на которые давно нет обычных внутренних ссылок.
Поэтому первый этап – инвентаризация.
Для каждой найденной страницы желательно собрать хотя бы:
Что это
Старый URL, тип страницы, Title, H1, назначение, текущий статус и дата последнего обновления.
Как используется
Органический трафик, поисковые запросы, конверсии, внешние и важные внутренние ссылки.
Что связано
Изображения, документы, формы и другие функциональные элементы.
Что дальше
Ответственный, решение о судьбе материала, новый URL и статус переноса.
Низкий трафик ещё не означает, что страницу можно удалить
Одна из самых опасных механических схем:
Так принимать решение нельзя.
Представим страницу с 20 переходами из поиска за год. На первый взгляд она бесполезна. Но эти 20 человек могли искать конкретную дорогостоящую услугу. Один из них мог стать клиентом.
Или страница вообще предназначена не для органического поиска. Менеджеры отправляют её потенциальным заказчикам после первого разговора. Другой пример – техническая документация. По ней почти нет трафика, но она нужна существующим клиентам.
Поэтому материал лучше оценивать сразу по нескольким направлениям.
Пользовательская
Решает ли страница реальную задачу посетителя?
Бизнес
Помогает ли продаже, поддержке, работе менеджеров, партнёров или клиентов?
Поисковая
Есть ли трафик, видимость, запросы, внешние ссылки и история URL?
Информационная
Содержит ли материал данные, инструкции, документы или знания, которые нельзя бездумно потерять?
Только после этого принимается решение. Если вопрос упирается в поисковый спрос и распределение интентов по страницам, здесь уже помогает семантическое ядро и карта целевых URL.
СОХРАНИТЬ / ОБНОВИТЬ / ОБЪЕДИНИТЬ / УДАЛИТЬ / СОЗДАТЬ
Для каждой страницы старого сайта назначаем один из пяти статусов. Это не технические команды, а решения о судьбе контента.
Сохранить
Материал выполняет свою функцию и остаётся актуальным: действующая услуга, качественная статья, инструкция, контактная информация или используемый документ. Сохраняется содержание и назначение, а не обязательно старый HTML.
Обновить
Страница нужна, но содержание устарело: изменилась услуга, условия, цены, скриншоты, продукты или поисковый интент. Такой материал актуализируем до переноса или непосредственно в процессе миграции.
Объединить
Несколько старых страниц фактически решают одну задачу. Определяем основной материал, сохраняем полезные фрагменты остальных и собираем одну полноценную целевую страницу.
Не переносить
Истёкшая акция, давно закрытая услуга, тестовая публикация, пустой архив или дубликат без самостоятельной ценности. Решение «Удалить» относится к контенту и ещё не определяет техническую судьбу старого URL.
Создать
Новая структура обнаружила задачу, которой старый сайт вообще не закрывал. Например, важная услуга раньше была спрятана двумя абзацами на главной и теперь получает собственную страницу.
Если нужную страницу приходится создавать заново, её содержание лучше проектировать под конкретный интент и роль в структуре, а не копировать фрагменты из разных старых разделов. Для таких задач на VozniNet отдельно выделена работа с SEO-текстами и контентом.
Решение по контенту и решение по URL – не одно и то же
Допустим, мы присвоили странице статус ОБЪЕДИНИТЬ.
Это означает: её содержание объединяется с другим материалом.
Но дальше нужен отдельный ответ: что происходит с её старым URL?
Поэтому рабочая таблица должна содержать обе колонки.
| Старый URL | Роль | Данные | Решение | Что делаем с контентом | Новый URL | Судьба старого URL |
|---|---|---|---|---|---|---|
| /uslugi/remont | Услуга | Трафик, заявки | СОХРАНИТЬ | Переносим и адаптируем | /remont | Сопоставляем 1:1 |
| /remont-cena | Услуга | Есть запросы | ОБЪЕДИНИТЬ | Цены включаем в основную страницу | /remont | Сопоставляем с основной |
| /akciya-2021 | Акция | Ценности нет | УДАЛИТЬ | Не переносим | – | Отдельное техническое решение |
| /blog/vybor-a | Статья | Трафик | ОБЪЕДИНИТЬ | Полезные фрагменты сохраняем | /blog/kak-vybrat | Сопоставляем с объединённой |
| /blog/vybor-b | Статья | Слабый трафик, хороший материал | ОБЪЕДИНИТЬ | Уникальную часть переносим | /blog/kak-vybrat | Сопоставляем с объединённой |
| /dostavka | Сервисная | Используется клиентами | ОБНОВИТЬ | Актуализируем условия | /dostavka | Сохраняем |
| /catalog.pdf | Документ | Используется | ОБНОВИТЬ | Заменяем актуальной версией | Новый PDF | Проверяем старые ссылки |
| – | Новая услуга | На старом сайте отсутствует | СОЗДАТЬ | Готовим страницу | /novaya-usluga | – |
Вместо фразы «у нас на старом сайте 486 страниц» получаем рабочую картину: сколько сохраняем, сколько обновляем, сколько объединяем, что не переносим и какие материалы нужно создать.
С таким документом уже могут работать редактор, разработчик, SEO-специалист и владелец сайта.
Старая страница → новая структура: строим карту миграции
Карта миграции показывает не абстрактный объём сайта, а конкретный путь каждого материала.
Здесь хорошо видны разные сценарии:
- одна старая страница сохраняется как одна новая;
- несколько старых материалов объединяются в одну целевую страницу;
- материал не получает замены, потому что больше не нужен;
- существующая страница обновляется;
- в новой архитектуре появляется страница, которой раньше вообще не было.
Именно на этом этапе старая структура перестаёт быть обязательным шаблоном для новой. Мы сохраняем ценность, но не обязаны сохранять исторически сложившийся хаос.
Переносить нужно информацию, а не старый HTML
Это особенно важно при смене CMS или серьёзной переработке структуры сайта.
Старая страница могла представлять собой один большой редактор:
На новом сайте тот же материал может состоять из отдельных сущностей:
Если механически скопировать старый HTML, вместе с информацией переедут старая вёрстка, встроенные стили, ненужные классы, старые размеры изображений, лишние контейнеры, неактуальные компоненты и ошибки прежней CMS.
Поэтому при серьёзной миграции полезно сначала определить новую контент-модель.
Содержание
Название услуги, краткое описание, основной текст, преимущества, характеристики, FAQ.
Служебные поля
Изображение, призыв к действию, связанные кейсы, автор, дата обновления, SEO-метаданные.
Самое интересное часто находится не в тексте страницы
Если открыть старый сайт глазами редактора, кажется, что миграция – это тексты и изображения. Но реальный список значительно шире.
Изображения
Какие используются, какие устарели, есть ли оригиналы, нужны ли подписи и alt, есть ли права на использование и не привязаны ли файлы к старой структуре.
PDF и документы
Прайсы, инструкции, каталоги, сертификаты, презентации, техническая документация и бланки. Некоторые файлы могут иметь собственный трафик и внешние ссылки.
Формы и действия
Заявка, расчёт, загрузка файла, призыв к действию. Если перенести текст и забыть главное действие, формально страница мигрировала, фактически – нет.
Метаданные и связи
Title, description, robots, canonical, внутренние ссылки, FAQ, связанные материалы и другие элементы, которые не всегда заметны при визуальном просмотре.
Отдельно проверяем то, что человек обычно не замечает
- изображения;
- документы;
- формы;
- калькуляторы;
- видео;
- таблицы;
- FAQ;
- отзывы;
- контакты сотрудников;
- цены;
- юридические документы;
- подписи;
- alt;
- призыв к действию;
- внутренние ссылки;
- языковые версии;
- данные автора;
- даты публикации и обновления;
- связанные материалы;
- элементы, которые появляются только после взаимодействия.
Иначе может получиться новый сайт, на котором «весь текст перенесён», но половина полезных функций исчезла.
Старая структура не должна автоматически диктовать новую
Допустим, на старом сайте:
При редизайне команда копирует структуру, потому что она уже существует.
Но зачем?
Возможно, пользователю вообще не нужны четыре промежуточных уровня. Или несколько разделов появились исторически: разные подрядчики добавляли новые страницы в разное время.
Если ответ «нет», старое дерево URL не должно становиться техническим заданием для нового.
При этом менять структуру только ради ощущения новизны тоже не стоит. Если существующий URL понятен, работает и соответствует своей задаче, сам факт редизайна не является причиной его менять.
Сначала проверяем миграцию на небольшой выборке
Представим сайт на 5000 страниц. Разработчик написал импорт. Запускаем.
Через два часа получаем 5000 страниц в новой CMS.
А потом выясняется: у таблиц потерялись заголовки; в изображениях неправильные пути; FAQ превратился в обычный текст; PDF ведут на старый домен; в половине статей сломались внутренние ссылки; формы вообще не мигрировали.
Исправлять ошибку после массового переноса значительно дороже.
Поэтому сначала нужна тестовая партия. Причём выбирать лучше не первые десять URL из таблицы, а разные типы контента:
- обычная услуга;
- длинная статья;
- карточка товара;
- страница с таблицей;
- материал с галереей;
- страница с формой;
- страница с PDF;
- материал с FAQ;
- страница со сложными внутренними ссылками.
Для каждой проходим полный путь:
Если разные сценарии отработали нормально, массовый перенос становится значительно предсказуемее.
Сайт продолжает жить, пока мы его переносим
Это одна из самых неприятных миграционных проблем.
Допустим, 1 октября мы сделали полную выгрузку старого сайта. Началась разработка.
- 3 октября менеджер поменял цены.
- 5 октября редактор опубликовал статью.
- 7 октября заменили PDF-каталог.
- 10 октября изменились телефоны.
- 14 октября появилась новая акция.
20 октября новый сайт запускают на основе копии от 1 октября.
И всё, что происходило последние 19 дней, исчезает. Причём технически миграция прошла успешно.
Вариант 1 – Заморозка контента
На определённый период изменения старого сайта прекращаются. Команда знает: после этой даты старый контент больше не редактируем до запуска новой версии.
Вариант 2 – журнал изменений
Если сайт нельзя остановить, после контрольной выгрузки фиксируется каждое изменение: дата → URL → что изменили → кто изменил → перенесено на новый сайт / нет.
Для интернет-магазина или активно обновляемого портала журнал часто реалистичнее полного freeze.
Контент должен иметь ответственного
Есть страницы, про которые разработчик ничего не может решить.
Например: «Доставка по регионам осуществляется в течение 3–5 рабочих дней».
Это ещё актуально?
SEO-специалист не знает. Разработчик не знает. Дизайнер тем более.
Нужен человек со стороны бизнеса.
То же самое касается цен, гарантий, условий оплаты, характеристик, адресов, сертификатов, сотрудников, юридических формулировок и описаний услуг.
Поэтому в большой миграционной таблице полезна колонка: «Ответственный за содержание».
Не тот, кто копирует страницу. А тот, кто может подтвердить:
«Перенесено» ещё не означает «проверено»
В таблице миграции одного статуса недостаточно.
Разработчик может импортировать страницу и поставить «готово». Но редактор обнаружит, что потерялся абзац. SEO-специалист – что изменился важный URL. Менеджер – что указан старый телефон. А владелец продукта – что услуга уже полгода предоставляется на других условиях.
Поэтому технический факт импорта и фактическое принятие материала – разные события.
После переноса сравниваем два реестра
Проверка должна идти не только от нового сайта: «открыли – вроде всё работает».
Гораздо надёжнее взять исходную инвентаризацию и пройти её сверху вниз.
Найден
Сохранённый материал присутствует на новом сайте и выполняет прежнюю задачу.
Найден и обновлён
Актуализированное содержание действительно попало в опубликованную версию.
Найден в целевой странице
Полезная часть старого материала присутствует в объединённом документе.
Отсутствует согласно решению
Материал не исчез случайно, а исключён осознанно.
Новая страница создана
Новый материал существует, заполнен и принят ответственным.
Так можно обнаружить материалы, которые потерялись полностью. Если смотреть только на новый сайт, о них уже некому напомнить.
После такой сверки имеет смысл провести и общую техническую проверку проекта – для этого можно использовать чек-лист проверки сайта.
Как может выглядеть карта миграции небольшого сайта
| Старый URL | Тип | Решение | Что переносим | Новый URL | Ответственный | Статус |
|---|---|---|---|---|---|---|
| /services | Раздел | ОБНОВИТЬ | Структура и полезный текст | /uslugi | Маркетинг | Проверено |
| /service-a | Услуга | СОХРАНИТЬ | Весь актуальный материал | /service-a | Руководитель направления | Принято |
| /service-a-price | Услуга | ОБЪЕДИНИТЬ | Цены и условия | /service-a | Руководитель направления | Проверено |
| /old-service | Услуга | УДАЛИТЬ | Ничего | – | Директор | Принято |
| /blog/article-1 | Статья | ОБНОВИТЬ | Текст, изображения, FAQ | Тот же URL | Редактор | В работе |
| /blog/article-2 | Статья | ОБЪЕДИНИТЬ | Уникальные разделы | /blog/article-1 | Редактор | Не начато |
| /price-2024.pdf | ОБНОВИТЬ | Заменить новым документом | Новый файл | Отдел продаж | Проверено | |
| /contacts | Сервисная | ОБНОВИТЬ | Адреса, карта, форма | /contacts | Администратор | Принято |
| – | Новая услуга | СОЗДАТЬ | Новый материал | /new-service | Маркетинг | В работе |
На реальном проекте колонок будет больше. Но даже такая таблица снимает огромное количество вопросов между дизайнером, разработчиком, SEO-специалистом, редактором и владельцем сайта.
Мини-чек-лист перед редизайном
- Получен полный список существующих URL.
- Учтены изображения, PDF, формы и другие материалы.
- По каждой странице принято решение СОХРАНИТЬ / ОБНОВИТЬ / ОБЪЕДИНИТЬ / УДАЛИТЬ / СОЗДАТЬ.
- Низкий трафик не используется как единственный критерий удаления.
- Старая и новая структура сопоставлены.
- Контент-решение отделено от технического решения по URL.
- Определены ответственные за бизнес-информацию.
- Сделана тестовая миграция разных типов страниц.
- Определён Заморозка контента или журнал изменений.
- После переноса исходный реестр будет сверяться с новым сайтом.
Что в итоге должно получиться
Хорошая контент-миграция не обязана переносить 100% старого сайта.
Это вообще не её цель.
Если на старом сайте было 2000 URL, а после анализа осталось 1400 действительно нужных страниц, это не означает, что потеряно 600 страниц. Возможно, мы избавились от дублей, архивов, устаревших материалов и исторического мусора.
Но верно и обратное.
Если после редизайна стало 1400 страниц только потому, что дизайнеру так удобнее построить меню, это уже опасный подход.
Поэтому качество миграции нельзя измерять процентом перенесённых URL.
Тогда редизайн становится не косметической заменой оболочки, а возможностью привести содержание сайта в порядок.
Частые вопросы о контент-миграции
Нужно ли переносить весь контент старого сайта?
Нет. Перед переносом стоит определить ценность и назначение каждого материала. Часть страниц можно сохранить, часть обновить или объединить, а материалы без актуальной функции – не переносить.
Можно ли удалить страницы, на которых нет трафика?
Отсутствие органического трафика само по себе недостаточно. Страница может использоваться клиентами, менеджерами, рекламой, поддержкой или иметь другую бизнес-ценность.
Нужно ли менять URL при редизайне?
Сам редизайн не является причиной менять работающий адрес. URL имеет смысл менять, когда этого требует новая архитектура или другое обоснованное решение. Техническая обработка изменённых URL относится уже к SEO-миграции.
Что делать, если несколько старых страниц объединяются в одну?
Сначала определяется, какой полезный контент нужно сохранить из каждой страницы. Затем создаётся целевой материал и отдельно составляется карта соответствия старых URL новому адресу.
Нужно ли переносить старые PDF и изображения?
Только после инвентаризации. Нужно проверить актуальность файлов, использование на сайте, внешние и внутренние ссылки, качество, права и необходимость сохранения старых адресов.
Что такое Заморозка контента?
Это период, когда содержимое старого сайта временно перестают изменять, чтобы между контрольной выгрузкой и запуском новой версии не появились данные, которые не попадут в миграцию. Если остановить изменения невозможно, используется журнал всех правок после контрольной выгрузки.
Зачем делать тестовую миграцию?
Чтобы проверить процесс на нескольких разных типах контента до массового импорта. Ошибку в обработке таблиц, изображений, PDF или внутренних ссылок проще обнаружить на десяти страницах, чем после переноса нескольких тысяч.
Кто должен принимать решение об удалении контента?
Это зависит от материала. SEO-данные важны, но для коммерческих условий, цен, документации и описания услуг нужен ответственный со стороны бизнеса. В сложных проектах решение принимается совместно владельцем контента, SEO-специалистом и командой разработки.
Старый сайт – источник материалов, а не шаблон нового
При редизайне легко увлечься тем, каким будет новый сайт.
Но до запуска стоит столь же внимательно разобраться с тем, что останется от старого.
- не переносить всё автоматически;
- не удалять всё старое автоматически;
- не считать отсутствие трафика приговором;
- не превращать старую структуру в обязательный шаблон новой.
Сначала – инвентаризация. Затем – решение по каждому материалу. После этого – карта миграции, тестовый перенос, контроль изменений и проверка результата.
Если сложно разбирать сотни страниц – поможем собрать карту миграции
Проверим старый сайт, определим, что сохранить, обновить, объединить или убрать, сопоставим материалы с новой структурой и отметим то, что нельзя потерять при запуске. Если редизайн уже начался, подключимся на текущем этапе и продолжим работу от фактического состояния проекта.