Недостающее руководство по SEO-миграции доменов

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

Повествование ведется от лица Йоста де Валка, основателя Yoast SEO.

За эти годы я консультировал многих по подобным вопросам. Некоторые в итоге принимают решение оставить все как есть. Многие – нет.

Миграция затрагивает три дисциплины: управление проектами, техническое SEO и инжиниринг. Если какая-либо из них вам незнакома, именно эту дисциплину вам и нужно привлечь.

Хороший и плохой пример

Два реальных случая, оба хорошо задокументированы.

В 2013 году The Guardian перешла с guardian.co.uk на theguardian.com. Спустя шесть месяцев сайт по-прежнему демонстрировал рекордную посещаемость. Я занимался SEO-оптимизацией во время этой миграции; их архитектор ПО написал техническую часть. Вкратце, мы с самого начала рассматривали это как инжиниринг с добавкой SEO, а не как задачу по SEO с прикрепленным к ней инжинирингом.

Когда Topshop объединился с ASOS в начале 2021 года, topshop.com потерял примерно 80% своей видимости в поисковой выдаче и так и не смог её восстановить. Два десятилетия авторитета бренда, перенаправленного с помощью wildcard, а не постранично, испарились в подкаталоге ASOS.

Одна и та же операция, противоположные результаты. В The Guardian миграция рассматривалась как проект с дедлайнами, ответственными лицами и тестами. В Topshop же она воспринималась как поворот тумблера. В этом и заключается вся суть.

Как выглядит «норма»?

Судя по миграциям, над которыми я работал или за которыми внимательно следил, реалистичный ожидаемый уровень потери трафика составляет 30–40% в течение трех-шести месяцев. После этого вы должны вернуться к исходному уровню. Если восстановление после миграции занимает больше времени, значит, что-то пошло не так, и вам следует нанять специалиста, имеющего опыт в подобных проектах. Guardian восстановился за несколько месяцев. Topshop, по оценкам SISTRIX, — нет. Большинство проектов находятся где-то посередине, и то, где вы окажетесь, в основном зависит от того, насколько полно вы выполнили второй этап.

Сколько времени занимает SEO-миграция?

Реалистичный расклад:

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

Средняя категория — это диапазон вариативности. Небольшой сайт с чистыми URL-адресами мигрирует быстро. Десятилетний сайт с тремя CMS, устаревшими паттернами и длинным хвостом забытых поддоменов — миграция займет год. Не обманывайте себя относительно того, к какой категории вы относитесь.

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

Четырехэтапный план

Разобьем миграцию на четыре этапа:

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

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

Этап 1: Принятие решения

Прежде чем писать хоть одно правило перенаправления, ответьте на сложные вопросы.

Зачем вы это делаете?

«Потому что новый домен лучше» — это не причина. Причины, которые выдерживают критику, следующие:

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

Следует отметить, что любая миграция домена — это, по сути, операция по продвижению бренда. SEO-оптимизация — это затраты на её выполнение. «Учредители предпочли использовать новое название» — это не отдельная категория в данном списке. Это просто наиболее честная версия вопроса, с которым рано или поздно сталкивается каждая миграция: стоит ли новое название таких перемен?

Кто руководит миграцией?

Миграция — это сложный процесс, затрагивающий три области:

• Управление проектом. График стейкхолдеров, руководство по откату, решение о том, когда менять DNS.
• Техническая SEO-оптимизация. Канонические ссылки, hreflang lastmod, карта сайта, изменение адреса, правило empty-robots.txt.
• Разработка. Редиректы на периферии сети, тестовая обвязка, обратные вызовы OAuth, релизы SDK.

В большинстве компаний нет одного человека, который бы отвечал за все три направления; нормально, если есть кто-то, кто полностью контролирует миграцию и координирует все остальное.

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

Можете ли вы на самом деле стать владельцем нового бренда?

Это самый недооцененный вопрос. Если вы еще не занимаете первое место в поисковой выдаче по новому названию бренда, убедитесь в том, что вы сможете это сделать, прежде чем мигрировать. В противном случае миграция обречет вас на неудачу. Люди будут искать ваше новое имя, найдут кого-то другого, и вам придется потратить время на восстановление, объясняя своим клиентам, куда вы перешли.

Это относится и к системам с искусственным интеллектом. Спросите ChatGPT, Claude, Perplexity и Gemini о вашем новом бренде. Если они его не узнают или уверенно опишут другую компанию, ваши клиенты, задающие тот же вопрос, получат тот же неправильный ответ.

Вы не можете обновить обучающие данные замороженной модели, но вы можете повлиять на то, какую информацию будут учитывать будущие модели:

• Явное присутствие в Википедии, если это возможно.
• Схема Organization, которая объединяет название нового бренда и домена.
• Согласованное самоописание в интернете.
• Публикации в прессе, которые связывают новое название с новым доменом.

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

Сейчас самое время продумать свои сильные стороны: всё, что улучшит новый домен в глазах поисковых систем по сравнению со старым. Короткое, понятное имя. Домен верхнего уровня, который воспринимается как международный (.com, .io, .ai, .dev или любой другой домен верхнего уровня, который поисковые системы считают общим). Существующие входящие ссылки, которые можно перенаправить. Более чистая структура URL.

При регистрации доменов зарегистрируйте также очевидные вспомогательные варианты:

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

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

Стоит ли производить разом и другие изменения?

Официальные рекомендации Google гласят: вносите изменения по одному: не переносите домен одновременно со сменой CMS и редизайном сайта. Я с этим не согласен, но с одной важной оговоркой. В ходе миграции, над которой я работал, The Guardian перешла с нескольких устаревших CMS на новую систему в рамках одного переноса домена. И все было отлично.

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

Все решено?

На все вышеперечисленные вопросы даны однозначные ответы? Великолепно, решение принято: давайте начнём. Исправьте прямо сейчас все то, в чем вы не уверены. Каждый пропущенный вами вопрос на первом этапе станет препятствием на втором этапе, а устранение этого препятствия всегда обходится дороже, чем само решение.

Этап 2: Подготовка

Успешная миграция примерно на 90% состоит из подготовки и на 10% из выполнения. Если что-то должно измениться, лучше перенесите дату перехода, а не подготовительную работу. Большинство дат перехода все равно приходится переносить: несколько недель задержки почти всегда обходятся дешевле, чем карта редиректов, которую никто не успел проверить.

Проведите аудит текущего состояния

Вы не можете перенести то, чего не видите. Прежде чем что-либо перенаправлять, вам необходима полная инвентаризация:

• Просканируйте сайт. Используйте Screaming Frog, Sitebulb или аналогичные инструменты. Изучите все поддомены. Экспортируйте каждый URL-адрес с кодом состояния, заголовком, каноническими и внутренними входящими ссылками.
• Обратитесь к Google Search Console. Каждый проиндексированный Google URL-адрес, каждый поисковый запрос, по которому вы ранжируетесь, и данные о кликах и показах за последние 16 месяцев. Это ваша отправная точка. Без этого вы не сможете подтвердить, что потеряли или что приобрели.
• Обратитесь к Bing Webmaster Tools. Bing важнее, чем кажется, особенно в B2B и корпоративном сегменте.
• Получите журналы сканирования сервера. Журналы, которые ваш веб-сервер записывает при обращении к нему ботов, а не экспорт из Screaming Frog. Не смотрите только на Googlebot. Bingbot, ИИ-краулеры, ваши собственные боты мониторинга и краулеры рекламных сетей — все это отображается здесь. Журналы показывают, какие URL-адреса действительно важны для мира.
• Перечислите все поддомены, которые разрешаются. Marketing, docs, app, blog, status, support, staging, dev, demo. Некоторые из них не будут индексироваться никакими поисковыми системами. Получите их из конфигурации DNS.
• Сделайте снимок вашего ИИ-представления. Спросите ChatGPT, Claude, Perplexity и Gemini о вашем бренде прямо сейчас и сохраните то, что они говорят, включая URL-адрес, который каждый из них указывает. Вам понадобится эта базовая информация, чтобы определить, сохранилось ли ваше присутствие ИИ после миграции или незаметно переместилось на страницу конкурента. То же самое относится и к ответам в режиме ИИ в самом поиске Google.
• Проведите инвентаризацию машиночитаемых файлов. Если вы предоставляете версии страниц в формате .md, llms.txt, /.well-known/agent-card.json, эндпоинты MCP или любой другой объект, предназначенный для агентов и поисковых роботов, кроме Googlebot, эти данные также должны быть указаны в карте URL. Легко упустить. Дорого потерять.

Если вы используете какую-либо платформу с API, то инвентаризация значительно выходит за рамки веб-сайта: конечные точки API, веб-хуки, SDK, обратные вызовы OAuth, белые списки CORS, реестры пакетов, страницы состояния, каждый адрес электронной почты на старом домене. Я к этому еще вернусь.

Проведите аудит истории нового домена.

Если у вашего нового домена был предыдущий владелец, проверьте новый домен в Search Console и выполните три действия:

• Устраните все незавершенные вопросы до запуска и, при необходимости, отправьте запрос на пересмотр.
• Проверьте удаленные URL-адреса (URL Removals) от предыдущей команды, которые могут по-прежнему применяться ко всему сайту.
• Проверьте файлы отклоненных ссылок (Disavow files), загруженные предыдущей командой.

Чистая история — это хорошо. Неудачный вариант — запуск домена, который уже находится под санкциями, и выявление этого факта через три месяца, когда позиции в поисковой выдаче так и не выросли.

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

• Легитимные ссылки с сайтов, с которых вы хотели бы получать трафик: сделайте редирект 301 на ближайшую релевантную страницу вашего нового сайта.
• Спамные ссылки: добавьте в файл отклоненных ссылок (Disavow file).
• Совершенно неактуальные: оставьте как 404.

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

Наведите порядок перед переездом

Не стоит переносить ненужные файлы. Самый удобный момент для исправления ошибок на сайте — это этап перенаправления всех URL-адресов. В частности:

• Исправьте внутренние ссылки, ведущие к ошибкам 404 или цепочкам перенаправлений.
• Устраните все ошибки 404 в Search Console: восстановите, перенаправьте ссылки.
• Удалите дубликаты почти идентичных страниц, чтобы не сопоставлять два старых URL-адреса с одним и тем же новым без причины.
• Приведите ваши XML-карты сайта и robots.txt в исправное состояние.
• Найдите URL-адреса, которые вообще не должны индексироваться. Хитрость заключается в том, чтобы вбить запрос site:olddomain.com в Google и перейти на самую последнюю страницу; там находится ненужный мусор. Используйте в сочетании с негативными фильтрами, чтобы быстрее выявлять проблемные участки индекса: `site:olddomain.com -site:https://olddomain.com` находит HTTP-адреса, которые должны быть HTTPS, `site:olddomain.com -site:www.olddomain.com` находит URL-адреса голого домена или поддоменов, которые вышли за рамки вашей канонической стратегии. Используйте любой фильтр, который выявляет проблемные участки вашего индекса. Не переносите ничего лишнего.

Улучшите скорость сайта

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

Если вы откладывали работы по улучшению скорости, лучше сделайте их до миграции, а не после.

Создайте электронную таблицу сопоставления URL-адресов

Это самый ресурсоемкий элемент всего проекта. Одна строка на каждый старый URL:

• Старый URL на исходном домене.
• Код состояния (200, 301, 404).
• Целевой URL на новом домене.
• Действие: перенаправление, слияние или удаление.
• Примечания (например, «направлено на /pricing-eu»).
• Владелец / Проверщик.

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

Не стоит перенаправлять множество старых URL-адресов на главную страницу только потому, что нет явных целевых URL. Google рассматривает такой паттерн как «мягкую» ошибку 404, и URL-адреса, которые вы «сохранили», перенаправив их, всё равно теряют свой поисковый рейтинг. Если у страницы нет реального аналога на новом сайте, отобразите ошибку 410 (или 404). Это честный сигнал для поисковых роботов; перенаправление в никуда — это ложь.

Используйте ИИ там, где возникают ошибки

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

Для сайта с тысячами URL-адресов таблица сопоставления является узким местом на этапе подготовки. Передайте в LLM все старые URL-адреса с их заголовками, H1 и текстовыми цитатами, а также полную новую карту сайта. Нейросеть автоматически заполнит подавляющее большинство строк наиболее подходящими вариантами; все неопределенные URL будут помечены для проверки человеком. Два года назад эту задачу приходилось решать путем использования регулярных выражений, которые ломались при каждом исключении из правил. Теперь это занимает несколько часов машинной работы, тогда как раньше это требовало несколько недель ручного прохождения.

Есть один нюанс, и он важен: ложные совпадения (200, но неправильная страница) хуже, чем ошибки 404, потому что они невидимы в вашем QA-тесте. Страница, выдающая ошибку 404, отображается немедленно. Страница, которая перенаправляет на неправильный URL с помощью 301-го запроса, проходит дымовой тест (smoke test), индексируется и ранжируется по неправильным запросам. Каждое сопоставление, предложенное LLM, должно иметь оценку достоверности, и строки с низкой достоверностью следует все равно проверять человеку.

Та же логика применима везде. Не позволяйте LLM генерировать правила перенаправления, не проверив каждое из них с помощью curl. Не позволяйте ИИ составлять ваше заявление об изменении адреса (Change of Address). Не доверяйте ИИ оценивать то, достаточно ли важен тот или иной URL-адрес для миграции. Модель предлагает варианты. Вы делаете выводы.

Разработайте стратегию перенаправлений

Три правила и одна рекомендация:

• 301 — всегда. Никогда 302. Никогда не используйте перенаправления JavaScript.
• Никаких цепочек. Если сегодня существует перенаправление /old → /interim → /new, перед миграцией сверните его в /old → /new, а затем сразу же сопоставьте с новым доменом.
• Сделайте редиректы быстрыми. Запускайте перенаправления на периферии: Cloudflare, ваша CDN, выделенный сервер перенаправлений. Перенаправления на периферии быстрее, чем перенаправления из источника, и вашему источнику не нужно их обслуживать. Во время миграции слой перенаправлений сильно нагружается, часто одновременно всеми краулерами.

Рекомендация: добавьте заголовок Redirect-By к каждому перенаправлению, указывающий, какая система его инициировала. Когда после перехода на новую систему что-то пойдет не так (а это обязательно случится), вы сможете узнать с помощью одного запроса curl, какой слой за это отвечает. Я придумал этот заголовок во время миграции на Guardian именно по этой причине. Сейчас он используется примерно на 5,8 миллионах сайтов (около 9,8% сайтов, отслеживаемых WebTechSurvey), и, надеюсь, скоро станет полноценным стандартом.

Подготовка технических основ SEO

Скучные вещи, которые обеспечивают успех миграции:

• DNS TTL. Уменьшите его значение в старой зоне до 300 секунд примерно за 48 часов до переключения, чтобы изменения быстро распространялись.
• Действительные сертификаты на новом домене и каждом переносимом поддомене. Протестируйте с помощью SSL Labs.
• Карты сайта. Сгенерируйте карты для нового домена. Сохраните карту сайта старого домена доступной в течение нескольких недель после переключения, чтобы поисковые системы могли быстрее обнаружить перенаправления. Правильно настройте lastmod и модифицируйте его только тогда, когда контент изменился. Ничто так быстро не снижает ценность карты сайта, как обновление всех lastmod при каждом деплое.
• Канонические ссылки. Каждая страница на новом домене должна иметь каноническую ссылку на свой новый URL (самоканонизируется). Никогда на старый.
• Если у вас есть локализация, каждый тег hreflang должен указывать на свой аналог на новом домене.
• Структурированные данные. Обновите схемы Organization и WebSite, а также все ссылки sameAs, чтобы они отражали новый домен.
• Электронная почта. Не забывайте, что изменение домена влияет на отправку электронных писем. Настройте MX, SPF, DKIM, DMARC на новом домене и постепенно повышайте репутацию отправителя, если вы рассылаете большое количество маркетинговых писем.
• Google Search Console. Верифицируйте оба домена, включая все поддомены, задолго до перехода. Верификацию делайте с помощью записей DNS, а не с помощью HTML-файлов, метатегов или Google Analytics. Все это может сломаться или незаметно перестать работать во время миграции; запись DNS TXT остается верифицируемой, пока она находится в зоне.

Пишите тесты для всего

Каждое преобразование URL, каждая каноническая ссылка, каждая пара hreflang, каждая запись в карте сайта — это предположение о том, как работает ваш домен. Пишите тесты, которые доказывают, что эти предположения выполняются при каждом деплое, навсегда.

Механика проста: передайте CSV-файл с сопоставлением URL в LLM, и ИИ напишет тестовые сценарии за считанные секунды. Просканируйте все старые URL-адреса, проверьте переадресацию 301 на нужную цель, проверьте заголовок Redirect-By, зафиксируйте ошибки.

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

• Канонические ссылки указывают на правильный URL на каждой ключевой странице.
• Пары hreflang симметричны.
• Анализ структурированных данных.
• Карты сайта не содержат ошибок 404.
• Внутренние ссылки не проходят через ваш собственный слой перенаправления.

Бессмысленно запускать эти тесты всего один раз, после чего к ним не возвращаться. Интегрируйте их в CI. Обновление CMS или рефакторинг путей год спустя могут незаметно нарушить перенаправление, и вы этого не заметите, пока не упадете в рейтинге. Миграция — это разовое событие. Тесты, которые вам придется написать, должны сохраниться и после нее.

Отыщите то, что выходит за рамки сайта

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

• API-эндпоинты. Клиенты, обращающиеся к api.olddomain.com, не должны просто получать 301. Тела POST-запросов и заголовки Authorization не сохраняются после 301-го редиректа. Запланируйте четко определенное окно миграции API: используйте старое имя хоста для обслуживания API в течение определенного периода. Сообщите дату прекращения поддержки. Переведите всех клиентов на новое имя хоста до того, как вы прекратите поддержку старого.
• Веб-хуки. Брандмауэры клиентов и списки разрешенных IP-адресов могут быть настроены на ваше старое имя хоста. Сообщите им об этом в письменной форме, прежде чем менять источник.
• SDK и CLI. Для жестко закодированных базовых URL-адресов в ваших клиентских библиотеках потребуется релиз, который по умолчанию будет использовать новый домен. Выпустите этот релиз до перехода. Обновите главную версию, если изменение приводит к несовместимости.
• Обратные вызовы аутентификации и SSO. URI перенаправления для OAuth, SAML и магических ссылок регистрируются у провайдеров идентификации (Identity Provider). Обновите все это заранее.
• Белые списки CORS. Если ваше приложение или любой встроенный контент принимает междоменные запросы, вам нужно добавить новый домен в белые списки.
• Реестры пакетов. Обновите URL-адреса главной страницы в PyPI, npm, Docker Hub, Helm charts. Новые релизы должны отражать новую главную страницу.
• Внешние списки. LinkedIn, X, GitHub org, Crunchbase, G2, Capterra, ProductHunt, агрегаторы ИИ-инструментов, страницы спонсорства конференций, партнерский совместный маркетинг, пресс-релизы и (если у вашей компании есть физическое представительство) профиль Google Business и Apple Maps. Ни один из этих сервисов не обновляется автоматически.
• Внутренние системы. CRM, аналитика, автоматизация маркетинга, рекламные аккаунты, пиксели ретаргетинга, внутренний единый вход (SSO). Все они содержат ссылки на старый домен, которые незаметно перестают работать, если их не проверять.
• Cookies и аутентифицированные сессии. Cookies, заданные на .olddomain.com, не переносятся на новый домен. Зарегистрированные пользователи разлогиниваются при переходе, иногда незаметно. Спланируйте миграцию сессии: либо примите универсальный логаут и предупредите клиентов в коммуникациях, либо запустите кратковременный мост с общей сессией, если ваша система это поддерживает. Та же логика применима ко всему, что считывается из localStorage или IndexedDB, которые также привязаны к источнику.
• Платная поисковая реклама. Ставки по ключевым словам бренда в Google Ads, Bing и любой ретаргетинговой рекламе по-прежнему указывают на старые URL-адреса в тексте объявления и в поле целевого URL. Обновите объявления в день перехода, а не на следующей неделе. Это единственный канал, где перенаправление маскирует проблему, и вы узнаете о ней только из показателей кликабельности (CTR).

Ничего из этого не сложно. Но все это легко упустить из рассмотрения.

Планируйте коммуникации со стейкхолдерами (заинтересованными сторонами)

Люди, узнавшие о проблеме из-за ошибок 404, впоследствии отвалятся от вас. Рабочие сроки:

• За 6 недель: внутреннее общее собрание. Каждый сотрудник компании узнаёт об этом от руководства раньше, чем где-либо ещё.
• За 4 недели: брифинг по работе с ключевыми клиентами один на один, особенно для тех, кто использует API-интеграцию.
• За 3 недели: публичное объявление. Сообщение в блоге и электронное письмо. Мягкий тон: «Мы выполним миграцию в ближайшие недели».
• За 1 неделю: напоминающее письмо клиентам с техническими примечаниями по миграции для тех, кто использует интеграцию.
• В требуемый день: переход. Внутреннее объявление для команды о запуске перенаправлений.
• Через день, через неделю, через месяц: обновления статуса для команды и заинтересованных сторон.

Составление этих документов — это стандартная работа, с которой хорошо справляются LLM. Укажите контекст, аудиторию и сроки. Отредактируйте текст, чтобы он соответствовал вашему стилю.

План отката

План отката — это самый важный документ, который, как вы надеетесь, вам никогда не понадобится. Задокументируйте точные шаги для отката:

• DNS-записи для возврата к исходному состоянию.
• Слой переадресации для отключения.
• Роутинг электронной почты для восстановления.
• Шаблон публичных коммуникаций, готовый к отправке.
• Критерии принятия решения, которые инициируют откат.
• Иерархия подчиненности, санкционированная на выполнение отката.

У кого есть полномочия инициировать откат в 3 часа ночи? Кого они разбудят следующим? Чей номер телефона указан в руководстве для тех, кто непосредственно работает с DNS, периферией сети и роутингом электронной почты? Имена, а не роли. Храните руководство в таком месте, где каждый дежурный сможет быстро его найти.

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

Заранее определите, что именно вызовет запрос об откате, в конкретных терминах:

• Процентное снижение количества проиндексированных страниц.
• Устойчивое снижение трафика по сравнению с заданным базовым уровнем.
• Уровень ошибок 5xx выше указанного порога.

Если критерии записаны, то звонок в 2 часа ночи — это просто выполнение плана, а не его составление.

Другой важный момент — это дежурство. Назначьте ответственного за миграцию на первые 72 часа, с полномочиями передать запрос тому, кто сможет изменить DNS или выполнить откат на периферии сети.

Этап 3: День перехода

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

Предварительные проверки

Прежде чем что-либо менять, проверьте, что у вас должно быть:

• Действительный SSL-сертификат на каждом хосте нового домена.
• Контент на новом домене в окончательном состоянии, с самоканоническими ссылками и чистыми картами сайта.
• Развернутые и протестированные на границе сети правила перенаправления на выборке из более чем 100 URL-адресов.
• Электронная почта на новом домене находится в рабочем режиме и протестирована в обоих направлениях.
• Снимок базовых показателей (трафик, позиции в поисковой выдаче, проиндексированные страницы). Вам необходимо иметь возможность доказать, что именно изменилось.

Порядок действий

1. Измените DNS для маркетингового сайта. Перенаправьте новый домен на новый хост.
2. Активируйте слой перенаправления 301 на каждом старом хосте (главном и поддоменах), чтобы все старые URL теперь имели 301 редирект на свой новый аналог.
3. Очистите файл robots.txt на старом домене (подробнее об этом ниже).
4. Отправьте свежие карты сайта для нового домена в Google Search Console и Bing Webmaster Tools.
5. Зарегистрируйте изменение адреса (Change of Address) в Google Search Console, со старого на новый. Для корректной работы необходимо подтверждение обоих изменений.
6. Обновите внутренние ссылки повсюду. Выполните поиск и замену на новом веб-сайте и в кодовой базе, чтобы удалить все оставшиеся абсолютные URL-адреса, указывающие на старый домен. Для крупных организаций аналогичная проверка распространяется на интранет, внутренние вики, руководства, макросы поддержки и любые встроенные ссылки во внутренних инструментах. Внутренние ссылки никогда не должны проходить через ваш собственный слой перенаправления.
7. Выполните проверку. Просканируйте старый домен извне и убедитесь, что каждый URL возвращает 301 на правильный целевой адрес. Просканируйте новый домен и убедитесь, что каждая внутренняя ссылка, каждая каноническая ссылка и каждая запись в карте сайта относятся к новому домену.

Правило пустого файла robots.txt

Эта ошибка ставит в тупик почти каждую команду, которая раньше не осуществляла миграцию. После перехода на новый домен файл robots.txt на старом домене должен быть либо пустым (allow-all), либо выдавать ошибку 404. Перенаправление не требуется.

User-agent: *

Disallow:

Причина: поисковые системы запрашивают robots.txt, чтобы решить, можно ли им вообще индексировать домен. Если вы используете переадресацию robots.txt с помощью 301, некоторые поисковые роботы воспримут это как сигнал о том, что старый домен удален. Это может подавить краулинг тщательно настроенных вами переадресаций. Им необходимо увидеть разрешительный robots.txt на старом домене, получить URL-адреса на его основе, выполнить переадресацию 301 и обнаружить новый домен. Пустой параметр allow-all — это задокументированный безопасный путь.

И «пустой» действительно означает «пустой». Если в вашем старом robots.txt были Disallow-правила для чего-либо (перенаправления партнерских ссылок в /go/ или /out/, результаты внутреннего поиска, URL-адреса фасетной коммерции, архивы с пагинацией), удалите эти правила и на старом домене. Инстинктивное желание сохранить их вполне оправдано: вы добавили их туда не просто так.

Но после перехода на новый домен эти правила превращаются в ловушку. Заблокированные URL-адреса по-прежнему находятся в индексах поисковых систем. Поисковые роботы не могут их получить, а значит, не видят переадресации 301 и не могут обновить свои данные. Хуже того, эти URL-адреса остаются без контента, но с авторитетными ссылками, указывающими на них, и могут начать занимать более низкие позиции в поисковой выдаче по сравнению со старым доменом. Авторитет без контента — это наихудшее возможное состояние. Примените ваши правила Disallow только к новому домену, где им и место.

Не отказывайтесь от старого домена

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

Чтение логов в режиме реального времени

В первые часы после переключения вы отслеживаете логи серверов и периферийных устройств на предмет всплесков активности 4xx и 5xx. Тысячи строк логов в минуту, иногда больше. Это один из лучших вариантов применения ИИ во время миграции. Вставьте фрагмент лога в выбранный вами LLM и спросите:

• Какие паттерны URL-адресов чаще всего приводят к ошибке 404?
• Есть ли какие-либо пользовательские агенты, которые я не учел?
• Блокируются ли краулеры где-либо неожиданно?

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

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

Предостережение такое же, как и на втором этапе: не доверяйте утверждению модели «все выглядит нормально», не проверив приведенные ею цифры по фактическому лог-файлу. Модели с низкой линейной логикой иногда могут выдавать неверные значения или придумывать закономерности, которых на самом деле нет. Используйте нейросети для выявления потенциальных проблем. Делайте выводы самостоятельно.

Этап 4: После переезда

Переход на новую систему не заканчивается на третьем этапе. Он завершается через двенадцать месяцев.

Недели 1–4

• Ежедневно: трафик, позиции в поисковой выдаче, охват Google Search Console, частота ошибок.
• Еженедельно: анализ логов слоя перенаправления. Есть ли ошибки 404? Какие закономерности?
• Еженедельно: отчет Google Search Console по страницам. Есть ли что-нибудь в разделах «Discovered, not indexed» или «Crawled, not indexed», что должно быть проиндексировано?
• Служба поддержки: есть ли обращения, в которых упоминается старый домен или неработающие интеграции?

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

Месяцы 2–6

• Перейдите с ежедневного на еженедельный график.
• Проанализируйте трафик. К этому моменту вы должны стремиться к устойчивому восстановлению, а не к статистической неопределенности.
• Продолжайте обновлять высокоэффективные обратные ссылки.
• Завершите работу над любой временной параллельной инфраструктурой (старые имена хостов API, переходные поддомены) в соответствии с заранее объявленным графиком.

Хвост обучающих данных

Еще одно изменение с тех пор, как я впервые выступил с этим материалом: поисковые системы — не единственные системы, которые помнят ваш старый домен. Ваш старый домен хранится в обучающих данных LLM. ChatGPT, Claude, Gemini, Perplexity и каждая модель, которая сканировала или лицензировала веб до вашего перехода, — все они хранят его. Когда эти модели показывают вашу компанию в своем ответе, они могут отображать старое имя хоста в течение многих лет после вашей миграции. И в отличие от поисковых систем, нет инструмента, который вы могли бы использовать с моделью, чтобы сообщить ей о вашем переходе:

Для модели, завершившей обучение за год до вашего переезда, форма смены адреса не существует.

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

Первый год и далее

• Сохраняйте старый домен зарегистрированным. Навсегда. Это не обсуждается и не имеет ограничений. Цена — это погрешность округления по отношению к риску, и этот риск сохраняется дольше, чем можно было бы предположить, исходя только из результатов поиска.
• Поддерживайте слой переадресации. Та же логика.
• Поддерживайте старый почтовый клиент в активном состоянии как минимум двенадцать месяцев. Старые контакты, старые поставщики и старые контрагенты будут продолжать использовать старые адреса дольше, чем вы ожидаете.

На самом деле вы никогда не закончите. Поддерживайте оба домена в верифицированном состоянии в Google Search Console и Bing Webmaster Tools как минимум год.

В заключение несколько слов

Когда миграция прошла успешно, инстинктивно хочется поздравить команду с «удачным результатом». Когда же она идёт не так, инстинктивно хочется винить Google.

Ни один из этих подходов не является правильным. Успешные миграции — это те, где кто-то за шесть месяцев до их начала настаивал на том, чтобы в таблице сопоставления URL-адресов для каждой строки был указан владелец. Где кто-то за две недели до этого спрашивал: «Как будет выглядеть robots.txt на старом домене на следующий день после переезда?» Где кто-то спустя шесть месяцев всё ещё изучал логи слоя перенаправлений, чтобы убедиться, что ничего незаметно не переместилось.

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

Этот пост — письменная версия моего доклада, прочитанного на конференции SMX Munich в 2025 году, с учетом перспектив развития ИИ в 2026 году. Я подготовил его на этой неделе, потому что одна из наших компаний планирует собственную миграцию.

Источник: https://joost.blog