Каждую неделю кто-то приходит с желанием перенести реальный сайт — с трафиком, обратными ссылками, несколькими годами накопленного доверия Google — в ИИ-конструктор. Не свежую идею, не прототип, а действующий бизнес, которому есть что терять. Это совсем другая задача, чем начинать с чистого промпта, и большая часть боли, которую я наблюдал, возникает из-за того, что к ней относятся так же, как к первой.
Есть три способа испортить это дело, которые встречаются настолько часто, что я могу предсказать содержание обращения в поддержку, ещё не дочитав тему письма. Правильный подход не требует особой хитрости — он просто получается сам собой, если перестать делать эти три вещи.
Ошибка первая: перенос старого контента целиком в надежде, что структура сложится сама собой
Инстинкт вполне понятен. У вас есть сайт, на нём есть текст, поэтому вы вставляете этот текст в чат и просите конструктор «сделать его лучше». Результат обычно выглядит как новый сайт, но читается как старый — те же растянутые абзацы об услугах, те же три заголовка, выполняющие работу пятнадцати, только теперь упакованные в более симпатичный шаблон. Конструктор сделал именно то, о чём вы попросили. Вы попросили его переоформить, а не переосмыслить.
Последствия проявляются примерно через шесть недель, когда позиции нового сайта оказываются точно там же, где были у старого, или чуть ниже. Ничего не улучшилось, потому что ничего в реальной архитектуре информации не изменилось — та же единая страница для услуги, которую следовало разбить на три, тот же отсутствующий раздел FAQ, по которому сайт конкурента уже год как занимает позиции. Свежий слой краски на доме с неправильным количеством комнат — всё равно дом с неправильным количеством комнат.
У меня был клиент со страницей «Услуги» на 4000 слов, охватывающей одиннадцать разных предложений. Она хотела перенести её как есть, потому что «она всегда работала». На самом деле она не работала — страница не ранжировалась ни по чему конкретному, потому что была обо всём сразу. Добросовестный перенос просто дал бы более симпатичную версию той же нерабочей страницы.
На практике здесь работает подход к переносу как к аудиту, предшествующему разработке. Загрузите старый контент, но сначала запросите инвентаризацию контента: какие страницы существуют, за что каждая из них на самом деле пытается ранжироваться, где две темы втиснуты в один URL, а где одна тема размазана тонким слоем по пяти. Эта инвентаризация и становится планом. Старый сайт — это источник, а не шаблон.
Ошибка вторая: забыть, что именно URL — это то, чему на самом деле доверяет Google
Это самая дорогостоящая ошибка. Перенос сайта, меняющий структуру URL без сопоставления старых путей с новыми — даже если новый контент объективно лучше, — выбрасывает годы накопленного авторитета. Обратные ссылки указывают на 404. Google приходится заново сканировать и заново зарабатывать доверие к страницам, которым он уже доверял по другому адресу. Прямой трафик со старых закладок и подписей в письмах упирается в тупик.
Я наблюдал, как люди замечали это только после запуска, когда панель аналитики вместо роста показывала обрыв. К этому моменту исправление сводится к добавлению редиректов постфактум, что возвращает часть потерь, но не все — разрыв между «URL изменился» и «кто-то это заметил и исправил» измеряется неделями утраченного веса страниц, которые уже не вернуть.
| Старый подход | Что ломается | Что делать вместо этого |
|---|---|---|
| Позволить конструктору сгенерировать любую структуру URL, подходящую под новый дизайн | Каждая входящая обратная ссылка и закладка теперь указывает на 404 | Сначала выгрузить старую карту сайта, сопоставить каждый существующий URL с его новым эквивалентом ещё до начала разработки |
| Настроить редирект только для главной страницы, оставив внутренние страницы выдавать 404 | Глубокие страницы несут собственный индивидуальный вес ссылок — потеря каждой из них по отдельности накапливается | Настроить 301-редирект для каждого значимого старого URL, даже тех, что объединяются в более общую страницу |
| Добавить редиректы «потом, когда сайт уже заработает» | Краулеры и переходящие по ссылкам пользователи упираются в тупики именно в тот период, когда трафик наиболее нестабилен | Редиректы включаются в тот же момент, когда запускается новый сайт, а не после |
Ничего экзотического здесь нет. Это таблица из двух столбцов, составленная ещё до того, как кто-либо коснётся конструктора. Просто это тот этап, который люди пропускают, потому что он скучный, а сама разработка — то, что по-настоящему увлекает.
Ошибка третья: переход одним махом без пути назад
Третий сценарий провала вообще не связан с контентом или URL — он касается того, как происходит сам переход. Кто-то создаёт новый сайт, ему нравится, как он выглядит в предпросмотре, и в тот же день домен направляется на него. Никакого тестового периода, никакого сравнения бок о бок при реальном трафике, никакого плана на случай, если что-то сломано, а предпросмотр этого не выявил, — например, форма обратной связи, которая незаметно перестаёт работать, процесс оформления заказа, который срабатывает при тестировании, но захлёбывается при реальном объёме платежей, или страница, которая нормально отображается на компьютере, но ломается именно на той модели телефона, которой пользуется половина ваших клиентов.
Разрушения в этом случае наиболее заметны, потому что они происходят мгновенно. Почтовый ящик поддержки переполняется. Кто-то обновляет аналитику каждые десять минут, наблюдая, как график идёт не в ту сторону, а откат назад означает повторную перенастройку DNS, что само по себе занимает время на распространение — а значит, плохой пользовательский опыт сохраняется даже после того, как вы решили всё отменить.
Решение неэффектное: снизьте TTL записи DNS за день-два до переключения, чтобы откат распространялся быстро, если он понадобится; сначала запустите новый сайт на предварительном или тестовом поддомене и действительно используйте его так, как это сделал бы клиент; и держите хостинг старого сайта работающим и нетронутым как минимум пару недель после переключения, вместо того чтобы сносить его сразу после запуска нового. Последний пункт стоит всего несколько долларов хостинга ради настоящей страховки. Люди пропускают этот шаг, потому что отмена старого тарифного плана ощущается как завершение цикла, а завершение циклов кажется прогрессом.
Как выглядит правильный подход
В итоге ничего из этого не требует больше работы, чем неправильные варианты — это тот же объём работы, только в другом порядке. Проведите аудит перед перестройкой. Сопоставьте URL перед запуском. Разверните тестовую версию перед переключением и сохраняйте путь назад в течение пары недель после него. Сайт, который получится в итоге, не просто выглядит новее — он сохраняет всё, что уже заработал старый, а ведь именно в этом и был смысл миграции, а не создания сайта с нуля.
