curl -sS -D - -o /dev/null "$OLD_URL"

Проследовать по перенаправлениям и просмотреть заголовки всех ответов

curl -sS -L -D - -o /dev/null "$OLD_URL"

Вывести конечный статус и конечный адрес для фиксации результатов

curl -sS -L -o /dev/null
-w 'статус=%{http_code} конечный_адрес=%{url_effective}\n' "$OLD_URL"

В протоколе приемки следует сохранять первый ответ, адрес назначения, конечный ответ и содержимое страницы. Тип правила для постоянного переноса должен подтвердить технический ответственный с учетом фактической среды развертывания. Нельзя делать вывод только на основании того, что в браузере «вроде бы перенаправило».

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

## 5. Как совместно проверять содержимое страниц и canonical?

Возможность открыть адрес — лишь минимальное требование. Рекомендуется выбрать репрезентативные страницы каждого шаблона и проверить полноту заголовка страницы, основного заголовка, текста, альтернативных текстов изображений, внутренних ссылок и кнопок обращения. Это поможет избежать ситуации, когда после импорта остается только оболочка страницы.

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

На многоязычном сайте дополнительно проверьте соответствие между языковыми версиями. Например, страница продукта на китайском языке не должна из-за массовой замены ссылаться на англоязычную главную страницу. Переключение языка, ссылки в подвале и рекомендательные ссылки в тексте нужно проверять фактическим переходом по ним.

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

## 6. Что проверять в карте сайта? Сначала сверьте ее со списком рабочих страниц

Рекомендуется сначала составить «список рабочих страниц, которые планируется открыть для общего доступа и обнаружения поисковыми системами», а затем сопоставить его со сгенерированной картой сайта. Сам факт создания XML-файла не означает, что проверка завершена.

Особое внимание уделите следующим вопросам:

- Принадлежат ли адреса в карте сайта рабочему домену и рабочей среде?
- Включены ли новые пути после миграции в соответствии с планом?
- Не попали ли в карту удаленные адреса, адреса с перенаправлением или страницы, еще не готовые к публикации?
- Совпадают ли страницы, перечисленные в карте, с каноническими адресами, заявленными на этих страницах?
- Не пропущены ли целиком языковые каталоги, страницы пагинации статей или категории продуктов?
- Назначен ли ответственный за обновление карты сайта и повторную публикацию?

Если количество записей в карте изменилось, выясните причину: это запланированное объединение контента, пропуск при импорте или ошибка условий фильтрации? Рекомендуется сохранять копии файлов до и после миграции, чтобы можно было сравнить их поэлементно.

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

## 7. Что проверять в Search Console до и после запуска?

![7. Что проверять в Search Console до и после запуска?](https://we0-frontend.oss-cn-beijing.aliyuncs.com/growth-covers/3ae5ab5b-404e-4812-9473-4305e47b4bb6.png)

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

После запуска рекомендуется проводить проверки и фиксировать результаты в следующем порядке:

1. **Ресурсы и права доступа**: относится ли открытый ресурс к сайту, участвующему в этой миграции, и сохранился ли доступ у ответственного сотрудника?
2. **Репрезентативные URL**: проверьте сканирование, статус индексирования и сведения о канонических адресах ключевых страниц, отделяя исторические данные от последующих изменений.
3. **Карта сайта**: сверьте отправленный файл, статус обработки и связанные сообщения; при обнаружении проблем вернитесь к проверке фактического файла.
4. **Проблемы страниц**: группируйте отклонения по каталогам и шаблонам, а не следите только за общим количеством.
5. **Показатели эффективности**: сравнивайте запросы, клики и показы старых страниц и соответствующих им новых страниц, а не только главной.

Если одновременно меняется домен, отдельно выясните, применимы ли процедуры изменения адреса к вашей ситуации. Не смешивайте смену инструмента создания сайта в пределах одного домена и перенос на другой домен.

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

## 8. Как организовать приемку и откат в день запуска?

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

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

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

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

## 9. Как последовательно искать причины изменений показателей после миграции?

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

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

Также фиксируйте происходящие в тот же период изменения рекламы, редактирование и удаление контента, сезонные кампании и корректировки настроек аналитики, чтобы не приписывать все изменения смене платформы. Рекомендуется за один цикл исправлять одну четко определенную группу проблем и записывать результаты повторной проверки. Это снижает риск того, что несколько одновременных изменений не позволят определить причину.

Единого срока восстановления, подходящего всем сайтам, нет. Для приемки миграции можно установить внутренний график повторных проверок, но не следует представлять этот график как обещанный срок обработки со стороны поисковых систем.

## 10. Как выяснять возможности миграции при выборе ИИ-платформы для создания сайтов?

Создание новых страниц и перенос старого сайта — две разные задачи приемки. На [официальном сайте we0](https://we0.ai/zh) описаны формулирование требований на естественном языке, создание сайта несколькими ИИ-агентами, визуальное редактирование и развертывание на домене. Компания может использовать эту информацию для оценки способа создания сайта, но отдельно следует запросить демонстрацию сохранения старых путей, настройки редиректов и методов проверки после миграции. Нельзя автоматически предполагать, что все эти задачи будут выполнены сами собой.

В качестве примера продукта другого типа на [официальном сайте Readdy](https://readdy.ai/zh) представлены экспорт кода, размещение на домене и инструменты, связанные с SEO и GEO. При закупке следует дополнительно уточнить: кто после экспорта поддерживает настройки развертывания, кто управляет правилами путей и кто разбирается с проблемами. Названия функций не заменяют документ с распределением ответственности по проекту.

[Статья о Ваньсяочжи в сообществе разработчиков Alibaba Cloud](https://developer.aliyun.com/article/1773673) затрагивает диалоговое создание сайта и процесс развертывания, однако на странице указано, что материал предоставлен пользователем. Он подходит для знакомства команды со сценариями создания сайтов, но его не следует считать обязательством поставщика относительно состава работ по миграции именно вашего проекта.

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

## Часто задаваемые вопросы

### Нужен ли чек-лист миграции, если домен остается прежним и меняется только платформа создания сайта?

Да. Рекомендуется проверить, сохранились ли пути, основной текст, заявленные на страницах параметры, внутренние ссылки и процесс обращения. Неизменный домен не означает, что все результаты развертывания автоматически будут соответствовать исходному плану.

### Можно ли перенаправить все старые страницы на главную?

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

### Можно ли считать миграцию завершенной после отправки карты сайта?

Нет. Также необходимо проверить старые точки входа, ключевые страницы и бизнес-сценарии, а затем продолжать фиксировать изменения статусов в Search Console. Отправка карты сайта не заменяет проверку фактической доступности.

## Полезные инструменты

- **Таблица соответствия URL**: управление старыми и новыми путями, способами обработки и ответственными.
- **curl**: просмотр заголовков ответов, цепочки перенаправлений и конечного адреса.
- **Google Search Console**: систематизация результатов проверки статусов сайта и показателей в поиске.
- **Инструменты разработчика в браузере**: повторная проверка загрузки страниц, ссылок и запросов форм.

## Полезные ссылки

- [we0: создание сайта, редактирование страниц и процесс развертывания](https://we0.ai/zh)
- [Readdy: создание сайтов, экспорт кода и инструменты для дальнейшей работы с сайтом](https://readdy.ai/zh)
- [Сообщество разработчиков Alibaba Cloud: обзор сценариев создания сайтов с ИИ-сервисом Ваньсяочжи](https://developer.aliyun.com/article/1773673)

## Итоги

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