Как составить техническое задание на SEO при редизайне сайта? Контрольный список требований к миграции и приёмке

Как совместить сроки проекта и поисковый трафик при редизайне сайта? При подготовке технического задания по SEO для редизайна сайта, например по запросу «cahier des charges seo refonte d'une site», руководителю проекта важно не просто собрать дополнительные рекомендации по оптимизации, а добиться согласованного понимания объёма миграции, зон ответственности и критериев приёмки у команд дизайна, разработки, контента и маркетинга. То, что страницы открываются, — лишь отправная точка. При запуске часто упускают из виду главное: смогут ли пользователи старого сайта найти соответствующие страницы на новом сайте.

До начала работ зафиксируйте активы старого сайта и границы проекта

Не начинайте техническое задание с фразы «новая главная страница должна выглядеть лучше». Сначала уточните, что именно меняется: дизайн, CMS, домен, структура каталогов или несколько элементов одновременно. Если домен и URL-пути остаются прежними, основное внимание может быть уделено содержанию страниц и технической реализации. Если одновременно меняется домен и структура каталогов для разных языков, необходимо отдельно запланировать тестирование миграции и период наблюдения после запуска.

В перечень страниц старого сайта следует включить как минимум существующие URL, типы страниц, заголовки, коды состояния, канонические URL, а также страницы, которые привлекают органический поисковый трафик или помогают получать запросы. Сверьте данные по результатам сканирования сайта, Google Search Console, инструментам веб-аналитики и записям бизнес-команды. Не ориентируйтесь только на недавний трафик: сезонные товары и техническая документация с длительным циклом закупки также могут иметь ценность.

Для страниц, которые планируется удалить, в техническом задании нужно указать причины и способ обработки. Например, если снятый с производства товар имеет модель-замену, можно направить посетителей на соответствующую страницу. Если подходящего контента нет, не следует перенаправлять все такие страницы на главную только ради устранения ошибок. Ответственный за бизнес-направление должен подтвердить соответствие товаров-замен, SEO-специалист — оценить влияние на поиск, а разработчик — выполнить работы. Так удастся избежать споров о том, кто принимает решение, в день запуска.

Сделайте таблицу миграции результатом проекта, а не временным приложением перед запуском

В таблице миграции рекомендуется построчно указать старый URL, новый URL, тип страницы, способ обработки, ответственного и результаты тестирования. По возможности сохраняйте прежние пути страниц. Если изменить их необходимо, настройте прямой постоянный редирект 301 со старого адреса на наиболее релевантный новый, избегая цепочек редиректов и перенаправления разных старых страниц с различным содержанием на главную без разбора.

В техническом задании также нужно определить правила формирования URL: обработку регистра, завершающих косых черт, параметров, пагинации и канонических URL. Редиректы, внутренние ссылки, канонические теги и карта сайта должны указывать на согласованные целевые адреса. Для страниц, удалённых навсегда и не имеющих подходящего контента на замену, можно возвращать код состояния 404 или 410. Конкретный выбор зависит от фактического процесса обслуживания сайта; не каждый ответ 404 следует считать сбоем.

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

Формулируйте технические требования как действия, которые можно проверить

Формулировка «страницы должны быть удобны для поисковых систем» не подходит в качестве критерия приёмки. В техническом задании следует уточнить, доступны ли важные материалы и ссылки, возвращают ли страницы правильные коды состояния, можно ли редактировать заголовки и описания для каждой страницы, а также кто отвечает за генерацию канонических тегов, структурированных данных и карты сайта. В среде разработки следует ограничить доступ поисковых систем, а при запуске по пунктам снять ограничения доступа, правила robots и метки noindex, которые не должны оставаться.

После утверждения макетов проверьте и реальные страницы. Если характеристики товаров, сценарии применения и форма запроса представлены только в виде изображений, пользователям будет неудобно с ними работать, а поддержку контента будет сложнее организовать. Ключевые материалы, загружаемые с помощью скриптов, следует проверить на доступность для поисковых систем. Вместо расплывчатого требования «быстрая загрузка» можно выбрать типовые страницы и тестовую среду, зафиксировать показатели Core Web Vitals до и после запуска и определить, кто отвечает за исправления, если целевые значения не достигнуты.

Если редизайн затрагивает серверы, домен или провайдера подключения в материковом Китае, включите проверку备案 в график проекта. Необходимость оформления备案, внесения изменений или подачи заявки на подключение следует уточнить с учётом конкретной ситуации сайта и требований компетентных ведомств и провайдера. Для коммерческой деятельности также нужно отдельно проверить требования к соответствующим разрешениям. Если нужна помощь в подготовке документов и проверке процедуры, можно ознакомиться с услугами по оформлению ICP-регистрации в Китае, однако сроки проверки не следует считать фиксированной гарантией даты запуска.

Проводите приёмку в два этапа: проверяйте риски до запуска и реальные показатели после

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

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

Не забудьте проверить маркетинговую цепочку. Ссылки в старых рекламных объявлениях, социальных сетях и электронных письмах, а также события аналитики могут по-прежнему указывать на прежние адреса. Даже если страницы успешно перенаправляются, атрибуция форм или отслеживание конверсий могут прерваться. Для проектов, объединяющих разработку сайта, SEO и ведение рекламы, можно взять за основу подход к взаимодействию, используемый такими комплексными сервисами, как 易营宝: включить миграцию URL, ссылки рекламных кампаний и отслеживание запросов в единый чек-лист запуска, а не разбирать проблемы по отдельности уже после падения трафика.

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