Переезд базы знаний: как не потерять поисковый трафик

Для многих продуктов центр помощи — вторая по трафику собственность компании после главной страницы. Годами накопленные статьи «как подключить X» и «почему не работает Y» тихо держат позиции по тысячам низкочастотных запросов, снимают обращения круглые сутки и приводят покупателей, которые начали с поиска решения своей проблемы. Перенос базы знаний, который этого не учитывает, сжигает ценность, накапливавшуюся годами, — и потеря всплывёт через несколько недель, когда отыграть её труднее всего.

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

Сначала измерьте то, что собираетесь переносить

Нельзя защитить трафик, который вы не измерили. До того как сдвинется первая статья:

• Выгрузите последние 12 месяцев из Google Search Console: страницы, запросы, клики и показы. Сохраните файл — это ваша точка отсчёта и ваша страховка.
• Просканируйте старый центр помощи, чтобы получить полный список адресов: страницы категорий, уже существующие редиректы и статьи, о публикации которых никто не помнит.
• Отметьте страницы-кормильцы: 20 статей с наибольшим числом кликов обычно дают подавляющую долю органического трафика. Их проверяют руками на каждом следующем шаге.
• Запишите, какие адреса уже редиректят, — цепочки редиректов остаются классическим способом растерять вес ссылок при переезде.

Решите судьбу адресов до того, как что-то сдвинется

У каждой статьи должен быть осознанный ответ на вопрос «какой у тебя теперь адрес?» — записанный в таблице соответствий: старый URL, новый URL, статус.

• Сохраняйте слаг неизменным везде, где это возможно. Если старая статья жила по адресу /hc/articles/12345-connect-your-inbox, а новая система поддерживает /help/connect-your-inbox — перенесите человекочитаемую часть как есть.
• Если центр помощи переезжает между доменами или поддоменами (скажем, с support.example.com на example.com/help), считайте это переездом сайта: карта редиректов становится ещё важнее, а оба ресурса стоит подтвердить в Search Console.
• Соответствие один к одному — правило. Каждый старый адрес ведёт на свой прямой эквивалент. Свести всё на главную нового центра помощи — самый распространённый способ угробить позиции в выдаче: массовые редиректы на главную поисковики трактуют как soft 404.
• Статьи, которые вы сознательно выводите из обращения, получают редирект на ближайшую выжившую статью или честный 410, если тему не закрывает ничто. Решайте по каждой статье отдельно, а не одним правилом на всех.

Редиректы: то, что не обсуждается

• 301, постоянный. Не 302, не редирект на JavaScript, не meta refresh. Именно редирект 301 говорит поисковику передать сигналы ранжирования на новый адрес.
• Максимум один переход. Со старого адреса сразу на конечный. Если в старом центре помощи уже были редиректы, распрямите цепочки прямо в карте.
• Старый домен или путь отдаёт редиректы минимум год. Поисковики возвращаются медленно: вес ссылок перетекает месяцами, а не днями. Отключить старый поддомен через неделю после переключения — значит оборвать передачу на полпути.
• Проверьте карту программно. Скрипт, который запрашивает каждый старый адрес и убеждается, что оттуда уходит редирект 301 на нужную цель, пишется за час и ловит опечатки, которые иначе тихо стоили бы вам позиций.

Слаги, заголовки и canonical

• У каждой перенесённой статьи на новом адресе стоит canonical на саму себя.
• Если какое-то время оба центра помощи живут параллельно, старые статьи не должны конкурировать с новыми: либо редиректы включаются в момент переключения, либо со старых адресов проставляется canonical на новые. Две живые копии одной статьи делят сигналы ранжирования между собой.
• Оставьте заголовки и H1 без изменений на время переезда. Миграция — неподходящий момент для переписывания: меняйте по одной переменной за раз и дайте смене адресов улечься, прежде чем править тексты.
• В первый же день соберите заново и отправьте XML-карту сайта (sitemap) с новыми адресами, а старую ненадолго оставьте доступной — так роботы быстрее обнаружат редиректы.

Почистите HTML на входе

Старые центры помощи копят долги в разметке, а импорт добросовестно перевозит их вместе со статьями:

• Вырежьте инлайновые стили и классы прежней платформы — они конфликтуют с новой темой и иногда ломают вёрстку на мобильных, а это уже само по себе фактор ранжирования.
• Перепишите ссылки на изображения на файлы, которые вы перезалили к себе: ссылки на CDN прежнего вендора умрут вместе с закрытием аккаунта. Заодно проставьте alt — у большинства старых картинок в базе знаний его просто нет.
• Приведите в порядок иерархию заголовков: старые редакторы обожали прыгать с H1 сразу на H4. Чистая структура помогает и читателю, и попаданию лучших статей в быстрые ответы поиска.
• Уберите мёртвые встроенные виджеты — старые запускалки чата, формы обратной связи и скрипты, которые смотрят на систему, из которой вы уходите.

Внутренние ссылки — тоже часть переезда

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

Отрепетируйте переезд на тестовой копии

Всё перечисленное выше можно проверить до того, как это заметит хотя бы один посетитель. Импортируйте статьи в новый центр помощи неопубликованными (или за тестовым доменом), пройдитесь по нему сканером и сверьте: число статей совпадает с источником, заголовки уцелели, картинки отдаются с нового хоста, а внутренние ссылки ведут на новые адреса, а не на старые. Затем вхолостую прогоните карту редиректов по тестовому хосту тем же скриптом, которым будете проверять её в день запуска. Команды, которые репетируют, находят опечатки в таблице соответствий во вторник после обеда; команды, которые не репетируют, находят их в логе 404 — уже с прицепленным поисковым трафиком. Репетиция обычно занимает полдня и превращает день запуска из события в чек-лист.

После запуска: смотрите на правильные приборы

• Лог 404 — ежедневно первые две недели. Каждая 404 по переходу из поиска — это ошибка в таблице соответствий, которую можно исправить в тот же день.
• Покрытие в Search Console: следите, как новые адреса проходят индексацию, а старые уходят в статус «страница с редиректом». Медленно — нормально, с ошибками — нет.
• Позиции страниц-кормильцев — по той самой выгрузке-точке отсчёта. Умеренные качели на две-шесть недель для аккуратного переезда штатны; обрыв на конкретной странице означает, что у неё неверный редирект или canonical, — с неё и начинайте разбор.
• Полной стабилизации ждите через один-три месяца. Тогда и судите о переезде — по сохранённой точке отсчёта, а не по первой шумной неделе.

При чём здесь MoveDesk

Импорт базы знаний в MoveDesk сделан с оглядкой ровно на этот список: статьи приезжают с сохранённой структурой и флагами видимости, картинки перезалиты, HTML чистый и ложится на новую тему. А поскольку ваша база знаний одновременно служит опорой для ИИ-агента MoveDesk, та же уборка окупается дважды — аккуратные статьи и ранжируются лучше, и точнее отвечают клиентам. Импорт при миграции «под ключ» мы берём на себя; карта редиректов остаётся за вами, потому что живёт она на вашем домене.

До того как переедет первая статья, выгрузите точку отсчёта из Search Console. Всё остальное из этого списка чинится и после переключения — а вот отсутствующую точку отсчёта не починить ничем.