Редизайн сайта без потери трафика из поиска: что проверить до и после запуска
Новый сайт может выглядеть лучше, но при этом потерять переходы из поиска. Часто причина находится в деталях: изменившийся адрес статьи, исчезнувшая ссылка в меню, запрет индексации из тестовой версии. Виталий Левицкий разбирает в Pressfeed.Журнале, как проверить перенос и организовать приёмку вместе с разработчиками.
- 1. Отделите смену оформления от смены адресов
- 2. Соберите страницы, которые нельзя потерять
- 3. Сопоставьте старые и новые URL по смыслу
- 4. Проверьте содержание и навигацию новой версии
- 5. Защитите тестовую версию и подготовьте её к запуску
- 6. Примите запуск по заранее выбранной выборке
- 7. Наблюдайте за страницами, а не только за общей посещаемостью
- Что передать команде перед релизом
1. Отделите смену оформления от смены адресов
Сначала запишите, что именно меняется. Новый цвет кнопок и новый адрес каталога — разные задачи. Если URL, содержание и навигация сохраняются, проверка будет короче. Если вместе с дизайном меняются CMS, домен и структура разделов, понадобятся карта переноса и отдельный план запуска.
Маркетологу нужен список изменений с понятными последствиями. Например: «Статьи переезжают из /articles/ в /journal/; прежние адреса должны перенаправлять на соответствующие материалы». Запись «обновляем блог» не даёт возможности принять работу: невозможно понять, какой результат проверить.
Регистрируйся на Pressfeed – получи 3 питча в подарок
Промокод покажем сразу после регистрации.
Назначьте человека, который отвечает за список страниц, и человека, который исправляет технические ошибки. Заранее согласуйте, где будете вести замечания. В каждой задаче оставляйте адрес, ожидаемый результат, фактическое поведение и ответственного.
2. Соберите страницы, которые нельзя потерять
Выгрузите адреса из CMS и карты сайта. Добавьте посадочные страницы из веб-аналитики, страницы из отчётов поисковых панелей и URL, на которые ведут важные внешние ссылки. Эти списки могут различаться: материал уже исчез из меню, но всё ещё приносит посетителей или открыт по ссылке из старого письма.
Приоритет определяют не только просмотры. Страница с небольшим трафиком может давать заявки. Файл с инструкцией может быть нужен действующим клиентам. Публикация, которую цитируют партнёры, может иметь ценность даже без высокой посещаемости. Отметьте назначение каждой важной страницы, чтобы при сокращении сайта не удалить полезный материал по ошибке.
В рабочую таблицу достаточно добавить пять колонок:
- прежний адрес;
- назначение страницы;
- новый адрес или решение об удалении;
- ожидаемое поведение после запуска;
- результат проверки.
Сохраните также заголовки, описания страниц, основные тексты, изображения и документы. Это позволит разобраться, блок исчез при переносе или его убрали намеренно.
3. Сопоставьте старые и новые URL по смыслу
Если адрес сохраняется, посетитель должен получить рабочую страницу. Если адрес меняется, укажите конкретного преемника. Учебный пример: прежняя статья /articles/kak-vybrat-crm/ переезжает на /journal/vybor-crm/. Человек, открывший старую ссылку, должен попасть на эту статью, а не на главную страницу блога.
Отдельно разберите объединённые и удалённые материалы. Для объединения выберите страницу, которая действительно отвечает на прежний вопрос. Когда замены нет, не назначайте случайный адрес ради заполненной таблицы. Согласуйте удаление с владельцем контента и проверьте, как сайт показывает ошибку и помогает посетителю продолжить работу.
В карте перенаправлений не должно быть циклов и случайных пересечений. Если два разработчика независимо меняют правила, один старый адрес может сначала вести на промежуточный URL, а затем на конечный. Попросите проверить цепочки и по возможности убрать ненужные промежуточные переходы. Тип постоянного перенаправления и настройки сервера согласует техническая команда.
Проверяйте не только адресную строку в браузере, но и ответ сервера. Для небольшой выборки это можно сделать в инструментах разработчика, для большого списка — краулером или скриптом команды. В отчёте должны быть видны исходный URL, код ответа и конечный адрес.
4. Проверьте содержание и навигацию новой версии
Откройте важные страницы рядом со старой версией. Смотрите, сохранился ли ответ на вопрос читателя: условия услуги, инструкция, состав продукта, цены, способ обращения. Перенос заголовка при исчезнувшей таблице или инструкции нельзя считать полным переносом материала.
Проверьте заголовок вкладки, основной заголовок страницы, метаописание и указанный канонический адрес. Значения должны относиться к текущей странице и публичному сайту. Особенно легко пропустить адрес тестового домена, оставшийся в canonical после копирования шаблона.
Пройдите путь читателя: меню, карточка раздела, статья, связанные материалы, форма. Нажмите на ссылки внутри текста. Старые адреса, восстановленные через перенаправление, могут работать, но внутренние ссылки лучше вести на актуальные страницы.
Отдельная выборка — изображения и файлы. Откройте PDF-инструкции и другие документы, которые люди могли сохранить в закладках. Проверьте, что ссылка ведёт на нужный файл и его можно скачать. Если файл заменили, у нового документа должны быть понятные название и дата версии.
5. Защитите тестовую версию и подготовьте её к запуску
Тестовый стенд может попасть в поиск раньше готового сайта. Согласуйте с разработчиками способ ограничения доступа: например, авторизацию на стенде. Не путайте запрет сканирования в robots.txt и запрет индексации. Они решают разные задачи; робот должен иметь возможность прочитать директиву noindex, чтобы учесть её.
Составьте отдельный список временных настроек. В него попадут ограничения доступа, noindex в HTML или заголовках ответа, тестовые адреса в canonical, отключённые формы и тестовые интеграции. Напротив каждого пункта укажите, что должно произойти при запуске и кто проверяет результат.
После публикации откройте сайт из нового окна браузера, без доступа к стенду. Так легче заметить, что посетителю всё ещё предлагают авторизоваться или показывают заглушку. Затем проверьте настройки индексации уже на публичных страницах. Сайт может прекрасно открываться для человека и одновременно запрещать индексирование поисковому роботу.
6. Примите запуск по заранее выбранной выборке
Выберите страницы до релиза: главную, важные услуги, несколько статей, форму, страницу с файлом и несколько изменённых адресов. Для большого сайта добавьте по одному представителю каждого шаблона и раздела. Выборку согласуйте заранее, чтобы после запуска не ограничиться просмотром главной страницы.
Проверьте сайт с компьютера и телефона. Убедитесь, что форма действительно принимает обращение и сообщение приходит в нужное место. Проверяйте через тестовый сценарий, согласованный с командой: реальному клиенту не должны уходить случайные письма из приёмки.
Убедитесь, что веб-аналитика установлена на новых шаблонах и получает нужные события. Если раньше заявка фиксировалась после открытия страницы благодарности, а теперь форма работает без перехода, прежняя настройка может перестать считать обращения. Зафиксируйте дату и время запуска, а также изменения в измерении событий. Без этой записи падение числа целей легко принять за падение спроса.
Сохраните результаты приёмки. Таблица с отметкой «проверено» полезна только тогда, когда ясно, какую страницу открывали и какой сценарий прошли. Для ошибок приложите снимок экрана и точный адрес.
7. Наблюдайте за страницами, а не только за общей посещаемостью
После запуска сравнивайте одинаковые периоды и одинаковые показатели. Отдельно смотрите поисковые переходы, заявки и технические ошибки. Рост посещений из рекламы может скрыть снижение органического трафика, а сбой счётчика — создать видимость потери аудитории.
Если адреса изменились, анализируйте старую страницу вместе с её новым преемником. Иначе отчёт по прежнему URL покажет падение, хотя посетители уже переходят на новый. Для важных страниц сохраните соответствие адресов в таблице и пользуйтесь им при сравнении отчётов.
Проверьте, где именно произошёл спад: во всём сайте, в одном разделе, на мобильных устройствах или только в данных аналитики. Сопоставьте наблюдение с датой запуска и списком изменений. Например, исчезнувшие события формы требуют проверки измерения, а массовые ошибки старых URL — проверки перенаправлений.
Поисковые системы обрабатывают изменения не мгновенно. Один день или одна позиция по одному запросу не дают полной картины. При этом явные ошибки — недоступные страницы, случайный запрет индексации, сломанные формы — стоит исправлять сразу после обнаружения. Не устанавливайте универсальный срок «восстановления»: он зависит от масштаба изменений и самого сайта.
Что передать команде перед релизом
У маркетолога и разработчиков должны быть четыре общих документа: список важных страниц, карта переноса адресов, список временных настроек и сценарии приёмки. После запуска к ним добавляются результаты проверки и журнал исправлений. Эти документы помогают искать конкретную причину изменения трафика и сохраняют договорённости, которые иначе остаются в переписке.
Редизайн не заканчивается в момент, когда вы увидели новый экран. Работа завершается после проверки адресов, содержания, обращений и измерения результатов. Подготовленная приёмка позволяет заметить ошибку раньше и исправить её без спора о том, что именно входило в запуск.
Комментарии