Переезд мебельной фабрики на бренд-домен за один день без потери SEO

12 мая 2026 я переехал клиента, производство мебели на заказ «Ателье мебели 5+», с временного домена на свежекупленный брендовый. К концу дня старый домен полностью редиректит на новый, SSL выпущен, Я.Вебмастер и Я.Метрика подтянуты, в IndexNow ушли все 478 URL, контент-фабрика и каналы перенастроены. Всё за один рабочий день: без даунтайма, без потерянных страниц, без ручной работы в кабинетах там, где можно через API.

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

Зачем переезжали

mebelsale76.ru это был временный домен на 1.5 месяца. Пока клиент думал над брендом, мы успели:

• собрать сайт на 17 страниц (главная + 11 страниц услуг + блог + кейсы + о нас + контакты)
• залить туда max-pack по SEO-аудиту: HowTo/FAQ schema, WebP, лидмагнит, гео-блок, фавикон, лого
• запустить контент-фабрику с ежедневной публикацией статей через WordPress и Telegraph
• разогнать сайт по IndexNow до приличного состояния в индексе Яндекса

И вот клиент пришёл с готовым именем: atelie-mebeli5.ru. Идея простая: всё переезжаем page-to-page, ничего не теряем, ИКС утаскивает за собой история и блог.

План

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

Фаза 1: подготовка (~30 минут)

Клонировал webroot старого сайта (без .bak-файлов и временного мусора это важно, потом расскажу почему), 17 страниц + блог + assets: около 60 МБ.

Через одну команду sed заменил в 1576 местах:

• https://mebelsale76.ru → https://atelie-mebeli5.ru
• source:'mebelsale76-X' → source:'atelie-mebeli5-X' (атрибуция лидов в Telegram-бот: без неё каждое обращение к менеджеру было бы помечено старым доменом)

Sitemap.xml, robots.txt, llms.txt: обновились автоматически тем же sed.

Поднял nginx-vhost для нового домена в HTTP-only режиме (без SSL пока). Кеш-паттерны как на старом сайте: 30 дней для статики, 60 секунд для HTML главной, gzip с разумным набором mime-типов.

IndexNow-ключ для нового домена: отдельный hex-токен, кладу как в /<key>.txt, так и в кратком файле для API.

Тест: curl --resolve atelie-mebeli5.ru:80:наш_IP http://atelie-mebeli5.ru/: все 8 ключевых URL отдают 200 OK. Сайт готов принимать трафик, как только DNS догонит.

Фаза 2: переключение DNS (~50 минут)

Клиент в reg.ru:

1. Сменил NS с ns1.tildadns.com / ns2.tildadns.com на ns1.reg.ru / ns2.reg.ru
2. После активации зоны добавил A-записи @ и www на наш IP, TTL 300
3. Отвязал домен от Tilda за час до, чтобы не было 502 во время propagation

Реестр .ru подхватил новые NS почти сразу: whois уже показывал ns1.reg.ru. Авторитетные DNS-сервера reg.ru отдавали правильную A-запись. Но публичные DNS-резолверы (8.8.8.8, 1.1.1.1, 77.88.8.8, 9.9.9.9) ещё минут 50 кешировали старую запись Tilda с её TTL.

Первая попытка certbot --nginx в этом окне ожидаемо упала: Let's Encrypt резолвит домен через свои публичные DNS, видел старый IP Tilda, шёл туда за ACME challenge и получал 404. Это не баг сертбота, это естественное состояние пропагации.

Я не стал дёргать сертбот вхолостую: у Let's Encrypt лимит 5 неудачных попыток в час на имя. Просто подождал.

Фаза 3: выкат (~15 минут после готовности DNS)

Когда все четыре публичных DNS-резолвера показали наш IP, запустил мастер-скрипт. Он сделал по шагам:

1. SSL

certbot --nginx -d atelie-mebeli5.ru -d www.atelie-mebeli5.ru --redirect: сертификат на 90 дней, авто-renew настроен, HSTS включён, HTTP → HTTPS-редирект тоже на месте.

2. 301 page-to-page на старом домене

Здесь самая красивая часть переезда. URL-структура нового сайта 1-в-1 повторяет старую, поэтому return 301 https://atelie-mebeli5.ru$request_uri; отправляет с mebelsale76.ru/kuhni-na-zakaz/ ровно на atelie-mebeli5.ru/kuhni-na-zakaz/, со всеми параметрами, без потери глубоких страниц. SSL для редиректа реюзаем старый сертификат mebelsale76.ru: он живой и продолжает обновляться.

3. IndexNow Yandex

Все 478 URL из sitemap нового сайта одним батчем: HTTP 202 ACK, очередь на обход принята.

4. Я.Вебмастер

Самое интересное место. У клиента в Я.Вебмастере не было аккаунта на старый домен: он управлялся через другой логин, к которому у меня не было доступа. Решил иначе: добавил mebelsale76.ru в текущий аккаунт через API, запросил верификацию HTML_FILE. Проблема: на сайте уже стоит 301-блок и любой HTML недоступен.

Сделал в nginx 301-блок одно исключение:

location = /yandex_<UIN>.html {
    default_type text/html;
    return 200 '<html><head><meta name="yandex-verification" content="<UIN>" /></head>...</html>';
}
location / {
    return 301 https://atelie-mebeli5.ru$request_uri;
}

Через 30 секунд после запроса верификации статус сменился на VERIFIED. Теперь оба домена в одном аккаунте, и через UI можно в один клик завести «Переезд сайта» с указанием главного зеркала.

Туда же отправил на приоритетный recrawl 8 топ-URL нового домена. Из квоты 470/день потратил 7.

5. Я.Метрика

Клиент решил использовать счётчик «Ателье мебели», а не старый счётчик mebelsale76. Через Metrika Management API:

• установил site=atelie-mebeli5.ru
• добавил mirrors: www.atelie-mebeli5.ru, mebelsale76.ru, www.mebelsale76.ru: теперь даже редиректный трафик через старый домен попадает в правильный счётчик
• на самом сайте: одной командой sed заменил ID счётчика на 502 файлах (HTML + chat-widget.js), 582 вхождения. Бэкапы перенёс в /tmp, чтобы nginx их не отдавал.

6. Контент-фабрика, Telegraph, Telegram-канал, WP-блог

На сервере крутится автопостер: каждый день в 10:00 МСК публикует одну статью с двумя экспертами-ротациями в WordPress-блог + Telegraph + IndexNow. В её config.py поправил AUTHOR.url и TELEGRAPH.author_url: теперь все новые статьи подписаны новым доменом.

За 1.5 месяца фабрика родила в Telegraph 2949 страниц. Через editAccountInfo API обновил author_url на новый домен: теперь и на старых страницах в шапке у автора стоит правильная ссылка.

Telegram-канал @ateliemebeli5plis: через бот-API (бот в админах канала) поставил новое описание со ссылкой на atelie-mebeli5.ru.

WordPress-блог ateliemebeli5-blog.ru: поиск через REST API нашёл один пост с упоминанием старого домена (4 раза в тексте). Через тот же REST API заменил на новый. Дзен-канал тянет RSS из этого блога: обновлённый контент уйдёт автоматически.

Грабли, на которые наступил

Что получилось

Что осталось на клиенте

Не всё можно сделать через API, некоторые вещи только в UI:

1. Я.Вебмастер «Переезд сайта». Публичного API-эндпоинта нет, нужно зайти в кабинет и нажать кнопку «Индексирование → Переезд сайта», указать главное зеркало. После моих автоматических шагов это занимает 1 минуту.
2. Я.Карты / 2ГИС / Google Business Profile. Карточки организации: только через интерфейс. Изменить сайт в карточке на новый домен.
3. Авито / HH-профиль / Miralinks. Везде, где у клиента стоит линк на старый домен, аккуратно заменить.

301 page-to-page и так склеит ссылочный профиль автоматически, но прямые упоминания лучше обновить это ускорит переиндексацию.

Почему такой переезд получился безболезненным

Три вещи:

Один-в-один URL-структура. Если бы новый сайт переписал URL'ы (что часто бывает при ребрендингах), пришлось бы либо вручную писать map старых → новых страниц, либо использовать regex-маски. У меня просто $request_uri, короткая и надёжная.

Один аккаунт Я.Вебмастера на оба домена. Это даёт право заявить переезд через UI в один клик, иначе бы пришлось гонять верификацию через DNS TXT и ждать клиента.

API там, где это возможно. Метрика, Webmaster verify, IndexNow, Telegraph, Telegram, WordPress, VK: у всех есть API, и если есть токен с нужным scope, всё делается за минуты, а не часы кликов.

Что я заберу из этого кейса

Когда в следующий раз буду переезжать чей-то сайт:

1. DNS-gate в любом миграционном скрипте. Без него сертбот превращается в лотерею.
2. Проверка ls -la sites-enabled/ перед reload. Этот один шаг сэкономит 5 минут диагностики.
3. Verification-исключение в 301-блоке через return 200 с inline-HTML: не нужно создавать файл, всё в одной location-директиве. Чисто и обратимо.
4. Master-скрипт фазы 3 с встроенными curl-проверками. На каждом шаге сразу видно: отработало или сломалось.
5. Переносить .bak из webroot в /tmp. Иначе nginx раздаёт их по wildcard это и информационная утечка, и SEO-захламление дублями.