Смена структуры URL: когда оправдана, когда убийственна

Практическое руководство для тех, кто собирается «немного поправить адреса на сайте». Разбираем, когда переезд оправдан, когда убивает трафик, и что делать по шагам.

Гайд подготовили: Дмитрий Шейнкман, Роман Романенков, Екатерина Ремезова

Вместо предисловия

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

И знаете, что самое обидное? Разница между этими двумя сценариями почти никогда не в том, «повезло или нет». Она в подготовке. В скучной, нудной, никому не интересной подготовке, на которую в 90% случаев не выделяют времени, потому что «ну это же просто адреса поменять».

Так вот. Это не просто адреса поменять.

Этот гайд — попытка сложить в одно место всё, что я обычно объясняю по кругу каждому новому клиенту, который говорит: «А давай сделаем URL покрасивее».

Часть 1. Что вообще такое «структура URL» и почему все её путают

Разбираем адрес по косточкам

Возьмём типичный URL:

https://www.example.com/catalog/noutbuki/lenovo-thinkpad-x1?color=black&sort=price

Что здесь что:

Смена структуры URL — это когда меняется не один адрес, а правило, по которому строятся все адреса на сайте. Одна строчка в настройках CMS — и у вас поменялось 40 000 адресов.

Вот это и есть переезд. Не «поправили страницу», а «переехал весь дом, и почтальон об этом узнает сам, когда придёт».

Три разных по масштабу события, которые называют одним словом

Люди говорят «мы меняем URL», имея в виду совершенно разные вещи. Разведём:

1. Точечная смена одного-двух адресов. Переименовали статью, поправили опечатку в слаге. Риск: околонулевой, если поставили редирект. Делайте спокойно.

2. Смена структуры внутри домена. Было /blog/2019/05/kak-zhit/, стало /kak-zhit/. Было /product.php?id=553, стало /noutbuki/lenovo-x1/. Домен тот же, адреса — все другие. Вот об этом гайд в первую очередь.

3. Смена домена. old.com → new.com. Сюда же: переезд с поддомена в папку, склейка нескольких доменов, смена региональной зоны. Отдельная песня, но принципы те же плюс несколько специфических шагов (о них ниже).

Часто, кстати, случается страшное: делают всё три пункта сразу, ещё и с редизайном. Об этом будет отдельный абзац с криком души.

Часть 2. Главная мысль, ради которой стоит читать дальше

Запомните эту фразу, она сэкономит вам кучу денег:

Поисковику почти всё равно, как выглядит ваш URL. Ему не всё равно, что ломается, когда вы его меняете.

Разберём обе половины.

Половина первая: сам по себе URL — слабейший фактор ранжирования

Ключевое слово в адресе даёт мизерный эффект. Не нулевой — мизерный. Настолько мизерный, что если ваша единственная причина переезда звучит как «хочу, чтобы в адресе было слово купить», — не делайте этого. Никогда. Вы меняете гарантированный риск на выигрыш, который не измерите приборами.

То же самое про: - длину URL (короче — приятнее людям, но не поисковику); - вложенность (/a/b/c/d/ ранжируется не хуже, чем /d/); - «красоту» и осмысленность слага; - наличие цифр и ID.

Проще говоря: URL — это адрес, а не аргумент. Ни Яндекс, ни Google не ставят вас выше за красивый адрес, ровно как почтальон не носит письма быстрее на улицу с приятным названием.

Половина вторая: а вот что реально ломается при переезде

Когда вы меняете адрес, вы обнуляете (или ставите под угрозу) вот это:

1. Историю страницы. У URL есть возраст, накопленное доверие, история кликов в выдаче, поведенческие сигналы. Это привязано к адресу, а не к «странице» как абстракции. Новый адрес — новый лист.
2. Внешние ссылки. Каждая ссылка с чужого сайта ведёт на старый адрес. Живёт она через редирект, который придётся поддерживать столько, сколько живут эти ссылки.
3. Индекс. Все 40 000 старых адресов надо выбросить из индекса и загнать туда 40 000 новых. Это делается не по кнопке, а по мере обхода. На большом сайте — месяцы.
4. Внутреннюю перелинковку. Если её не переписать, весь сайт ссылается сам на себя через редиректы. Работает, но кривовато и медленно.
5. Всё, что снаружи вашего контроля. Закладки пользователей, ссылки в рассылках, ссылки в старых постах в соцсетях, QR-коды на печатных материалах, UTM-метки в запущенных рекламных кампаниях, интеграции с партнёрами, отзывы на форумах.
6. Аналитику. Все ваши отчёты, дашборды, цели, сегменты, настроенные по URL, — превращаются в тыкву. Год сравнимости данных до/после теряется.

Вот и весь баланс. Слева — эфемерная польза от красивого адреса. Справа — шесть конкретных вещей, которые могут сломаться.

Часть 3. Как поисковик на самом деле переваривает переезд

Тут важно понимать механику, иначе непонятно, почему нельзя «сделать и забыть».

Аналогия с почтой

Представьте: вы переехали. Написали заявление на почте — «всю корреспонденцию с Ленина, 5 пересылайте на Гагарина, 12». Это и есть 301-й редирект.

Что произойдёт дальше:

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

Отсюда три следствия, которые нарушают чаще всего.

Следствие 1: переиндексация занимает время, и оно нелинейно

Ориентиры из практики:

Причём переобход идёт неравномерно: сначала главная и топовые страницы, потом середина, потом длинный хвост. И этот длинный хвост, который обычно и приносит половину трафика, обновляется последним. Отсюда классическая картина: «главные запросы вернулись за неделю, а трафика всё равно на треть меньше». Это не поломка. Это хвост ещё не доехал.

Следствие 2: редиректы снимают по выдаче, а не по календарю

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

Рабочий критерий один: редирект держится до тех пор, пока в выдаче старый адрес не заменится новым. Пока по вашим запросам показывается старый URL, снимать нельзя ни при каких сроках — вы просто отправите живой трафик в 404. Как заменился по всему массиву страниц — редирект своё отработал.

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

И два случая, когда снимать не стоит даже после замены: если на старый адрес продолжают идти внешние ссылки, которые вы не можете переписать (архивы, PDF, чужие рассылки), и если старые адреса периодически всплывают заново — об этом в следствии 4. В обоих случаях редирект стоит копейки, а его отсутствие стоит трафика.

Здесь я хочу отдельно предупредить о самой недооценённой опасности в этой теме:

Через два года на сайт придёт новый разработчик, будет переезжать на новую CMS/новый хостинг, увидит файл с 40 000 правил редиректа, скажет «это какой-то мусор из прошлого» и удалит.

Я видел это трижды. Один раз — на сайте, который к тому моменту зарабатывал очень серьёзные деньги на органике. Просадка была мгновенной и жестокой, а найти причину неделю никто не мог, потому что «мы же ничего не меняли, только хостинг переехал».

Что делать: положите карту редиректов в репозиторий, добавьте комментарий на человеческом языке («Карта переезда 2026 года. Снимать только после проверки, что старые адреса ушли из выдачи и на них не идут внешние ссылки») и, если есть возможность, автотест, который дёргает 20 случайных старых URL и падает, если они не отдают 301. Снятие редиректов должно быть отдельным осознанным решением, а не побочным эффектом чужого рефакторинга.

Следствие 3: сигналы переезжают, но не телепортируются

Официальная позиция поисковиков — 301 передаёт вес без потерь. Практика чуть менее радужная: вес передаётся, но не мгновенно, и качество передачи зависит от того, насколько новая страница похожа на старую.

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

Следствие 4: старые адреса умеют возвращаться

Это то, чего почти никто не ждёт. Спустя месяцы, а иногда и годы после переезда Яндекс может достать старый адрес из собственной истории — из сохранённых копий, из своей базы известных URL — и снова начать его показывать. Формально страница давно выведена, редирект стоит, всё чисто. И вдруг в выдаче всплывает адрес, о котором вы забыли.

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

Что с этим делать. Первое и главное: редирект должен стоять на момент, когда старый адрес воскреснет. Поэтому не спешите со снятием: если 301 на месте, воскресший адрес просто снова уйдёт в редирект и история закончится сама. Если редирект уже снят — вы получите либо 404 на живом трафике, либо дубль.

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

Третье: если старые адреса всплывают массово, ищите, что их «напомнило» — обычно это ожившая интеграция, восстановленный из бэкапа sitemap или страница-агрегатор со старыми ссылками.

Часть 4. Когда смена структуры ОПРАВДАНА

Теперь по делу. Вот ситуации, в которых я говорю «да, делаем».

1. Переход на HTTPS

Это даже не обсуждается. Технически это смена URL (протокол — часть адреса), но выгода очевидна и безальтернативна. Делайте, если вдруг ещё не.

2. У вас реально ломается техника, а не «некрасиво»

Примеры настоящих поломок:

• Одна страница доступна по пяти адресам. /page, /page/, /Page, /index.php?p=page, /page?utm_source=... — и все отдают 200. Поисковик видит дубли, размазывает сигналы, тратит краулинговый бюджет впустую.
• Фильтры плодят бесконечность. Каталог с фасетным поиском генерирует миллионы комбинаций ?color=red&size=m&brand=x&sort=price&page=17. Робот ходит по этому лабиринту и не доходит до ваших нормальных страниц.
• Динамические параметры вместо нормальных адресов в масштабе, когда система не даёт задать canonical и вы физически не можете управлять индексацией.

Здесь смена структуры — не косметика, а лечение.

Важная оговорка: часто эти проблемы решаются без переезда — каноническими тегами, robots.txt, noindex, настройкой параметров. Всегда сначала проверяйте, нельзя ли вылечить дешевле. Переезд — операция, а не таблетка от головы.

3. Смена домена при реальном ребрендинге

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

Что не является реальным ребрендингом: «маркетологу разонравился домен», «нашли домен на 3 буквы короче», «хотим .io вместо .com, потому что модно».

4. Перенос поддомена в подпапку

blog.example.com → example.com/blog/

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

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

Обратный переезд (из папки на поддомен) — делайте только если есть жёсткая техническая причина.

5. Склейка нескольких доменов в один

Классика: у бизнеса три сайта — firma.ru, firma-moscow.ru, firmashop.ru, — которые конкурируют между собой за одни запросы, каннибализируют трафик и требуют тройной работы. Собрать в один — правильно.

6. Миграция на новую платформу/CMS

Тут смена URL — побочный эффект, а не цель. Но раз уж всё равно ломается, есть соблазн «заодно сделать нормально».

Мой совет: если новая платформа позволяет сохранить старые URL — сохраните их. Даже если они некрасивые. Сделайте один переезд вместо двух. Красоту можно навести потом, отдельным проектом, в спокойное время.

7. Реструктуризация, за которой стоит смена бизнеса

Был сайт услуг для физлиц — стал маркетплейс. Была одна страна — стало пять. Был один продукт — стало три направления. Старая структура физически не вмещает новый бизнес.

Здесь переезд оправдан, потому что альтернатива — вечно лепить костыли поверх структуры, которая не подходит.

8. Добавление языковых версий

Было /uslugi/, стало /ru/uslugi/ + /es/uslugi/ + /en/uslugi/.

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

9. Убрать дату из URL блога

/blog/2019/05/kak-vybrat-noutbuk/ → /blog/kak-vybrat-noutbuk/

Классический запрос. Мой честный ответ: сама по себе выгода минимальна. Свежесть контента поисковик определяет не по адресу. Пользователи, впрочем, дату в адресе видят и иногда действительно закрывают вкладку с мыслью «старьё».

Вердикт: если у вас 50 статей — делайте, риск копеечный. Если 5 000 — трижды подумайте, стоит ли ради этого затевать.

10. Структура откровенно вводит в заблуждение

Товар лежит в /catalog/aksessuary/, а на самом деле это ноутбук. Категорий 40, из них 30 пустых. Вложенность 7 уровней, и в глубине лежат самые продающие страницы, до которых робот доходит через раз.

Здесь плохая структура вредит не через URL, а через распределение внутреннего веса и краулинг. И вот это уже настоящая причина.

Часть 5. Когда смена структуры УБИЙСТВЕННА

А теперь любимое. Ситуации, в которых я говорю «нет» и, если надо, пишу это в отдельном письме с подписью, чтобы потом было на что сослаться.

1. «Хочу покрасивее»

Самая частая и самая дорогая причина. Эстетика адресной строки не окупает риск. Точка.

Проверочный вопрос, который я задаю: «Сколько денег мы заработаем, если сделаем? Назовите число». Если ответа нет — не делаем.

2. «Надо вставить ключевые слова в URL»

См. часть 2. Эффект — на грани погрешности. Риск — реальный. Это чистый минус.

3. Переезд в высокий сезон

Ноябрь для e-commerce. Февраль для туризма. Август для образования. Конец квартала для B2B.

Просадка после переезда — нормальное явление, и длится она недели. Если эти недели приходятся на 40% годовой выручки, вы не переезжаете — вы поджигаете деньги.

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

4. Переезд «за компанию» с редизайном, сменой CMS и переписыванием контента

Вот это — главный убийца. И самое коварное в нём то, что каждое изменение по отдельности выглядит разумно.

Проблема: когда через месяц трафик упадёт на 45%, вы не сможете понять, из-за чего. Из-за редиректов? Из-за того, что новый дизайн выкинул половину текста? Из-за того, что новая CMS не отдаёт микроразметку? Из-за апдейта поисковика, который случился в ту же неделю?

Вы будете чинить всё сразу вслепую. Это очень дорого и очень долго.

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

Порядок, который я обычно предлагаю: 1. Сначала техническая миграция (URL, редиректы) — контент и дизайн один в один. 2. Пауза, замер, стабилизация. 3. Потом редизайн. 4. Пауза, замер. 5. Потом контент.

5. Переезд с потерей контента

Если на новом адресе контента меньше, чем на старом, — вы не переехали, вы ухудшили страницу и заодно сменили адрес. Просадка будет, и вы решите, что виноват переезд, а виноват контент.

На время миграции контент должен переехать буква в букву. Улучшать будете потом.

6. Редирект всех старых URL на главную

Пишу большими буквами: ЭТО НЕ РЕДИРЕКТ, ЭТО УДАЛЕНИЕ САЙТА.

Поисковик распознаёт такое как «мягкую 404» и выкидывает страницы из индекса. Весь ссылочный вес — в мусор. Пользователи, пришедшие по ссылке за конкретной статьёй, попадают на главную, не находят ничего и уходят.

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

7. Переезд, когда сайт под фильтром или в разгар апдейта

Если вы прямо сейчас проседаете от алгоритмического апдейта — не трогайте структуру. Вы смешаете два процесса и не поймёте ничего.

И отдельно: смена домена не лечит ручные санкции. Они переезжают вместе с вами через редирект. «Убежать на новый домен» — идея из нулевых, сейчас не работает.

8. Сайт с сильным ссылочным профилем именно на внутренних страницах

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

Не запрет. Просто множьте риск на два и требуйте более весомую причину.

9. Много трафика не из поиска

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

10. Нет ресурса на сопровождение после релиза

Вот это, пожалуй, главный стоп-фактор. Переезд — это не событие «запустили в понедельник». Это процесс на 3–6 месяцев, в котором кто-то должен раз в неделю смотреть отчёты, ловить 404 и чинить.

Если у вас есть неделя разработчика на релиз и ноль часов после — не начинайте. Серьёзно. Лучше кривые URL, чем брошенный переезд.

Часть 6. Как принять решение: считаем на салфетке

Не надо сложных моделей. Ответьте на семь вопросов честно.

1. Что мы выигрываем — в деньгах или в измеримой метрике? Нет ответа → стоп.

2. Какая доля выручки приходит из органики? Больше 50% → риск критический, нужна очень весомая причина. 10–50% → умеренный, действуем по протоколу. Меньше 10% → относительно свободны.

3. Сколько страниц переезжает? До 500 → просто. 500–10 000 → нужна нормальная карта соответствий и автоматика. 10 000+ → это отдельный проект с бюджетом и сроком, а не задача на спринт.

4. Можно ли решить проблему без переезда? Каноникалы, noindex, настройка параметров, перелинковка, хлебные крошки. Если да — делайте так.

5. Есть ли ресурс на сопровождение 3–6 месяцев? Нет → стоп.

6. Сейчас сезон? Да → переносим.

7. Мы делаем что-то ещё крупное в те же две недели? Да → разносим.

Простое правило на выходе:

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

Часть 7. Протокол переезда: пошагово

Если решили делать — делайте вот так. Порядок важен.

Фаза 0. Снимок «до» (за 1–2 недели до релиза)

Вы не сможете оценить ущерб, если не с чем сравнивать. Фиксируем:

• Полный краул сайта (Screaming Frog, Netpeak Spider или аналог) — сохраняем выгрузку. Это ваша база: все URL, коды ответа, заголовки, каноникалы.
• Выгрузки из обеих панелей — Яндекс.Вебмастер и Search Console, максимальная доступная глубина, экспорт в файл: после переезда данные по старым URL станут бесполезными.
• Аналитика — Метрика и GA: посадочные, конверсии за год. Отдельно выпишите цели, настроенные по URL: их придётся пересобирать.
• Позиции по вашему списку запросов — снимок на день релиза.
• Ссылочный профиль: выгрузка доноров с разбивкой по целевым страницам. Отдельно — топ-100 самых ценных.
• Логи сервера за 2–4 недели: понять, как робот сейчас ходит по сайту, какие разделы обходит часто, какие — раз в месяц.
• Топ-100 страниц по трафику — отдельным списком. Это ваши VIP. За ними следите вручную.

Фаза 1. Карта соответствий (mapping)

Сердце всего проекта. Таблица из двух колонок: старый URL → новый URL.

Правила: - Каждый индексируемый старый URL должен иметь пару. Не «большинство» — каждый. - Соответствие 1:1 и по смыслу. Ноутбук → тот же ноутбук. - Нет прямого аналога → ближайший родитель. Никогда не главная. - Страницы, которые вы сознательно удаляете, отдают 410 (или 404) — это честнее, чем редирект в никуда. Но убедитесь, что на них не идут ценные ссылки. - Проверьте вручную: топ-100 по трафику и топ-100 по ссылкам. Глазами. Каждую. Это займёт день и спасёт вам квартал.

Как делать быстро: выгрузка старых URL + выгрузка новых → сопоставление по слагу/ID формулой или скриптом → ручная вычитка того, что не сматчилось.

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

Фаза 2. Подготовка на тестовом стенде

• Стенд закрыт от индексации — паролем, а не только robots.txt (это грабли из классики: закрыли роботсом, стенд попал в индекс, привет дубли всего сайта).
• Прогоняем краулер по списку старых URL, проверяем: код 301, целевой адрес правильный, ответ конечного адреса — 200, без цепочек.
• Проверяем на выборке: 100% топовых, случайные 200–500 из хвоста.
• Проверяем, что новые страницы не закрыты noindex, не залочены в robots.txt, имеют корректный canonical (сам на себя).
• Проверяем: не сломалась ли микроразметка, hreflang, og:url, канонические в мобильной версии.

Фаза 3. Релиз

Порядок в день Х:

1. Утро вторника (или среды). Не пятница. Не праздники. Вся команда доступна.
2. Выкатываем новую структуру вместе с редиректами. Не «сначала URL, потом через день редиректы» — это гарантированная катастрофа, робот успеет насобирать 404.
3. Обновляем внутренние ссылки — меню, хлебные крошки, ссылки в текстах, футер, sitemap. Внутренние ссылки должны вести на новые адреса напрямую, а не через редирект.
4. Заливаем новый sitemap.xml в обе панели. Старый оставляем доступным ещё на несколько недель — это помогает роботу быстрее найти и переобойти старые адреса.
5. Проверяем robots.txt: старые URL не заблокированы. Если заблокируете — робот не увидит редирект и решит, что страницы просто пропали. Это одна из самых частых и самых обидных ошибок.
6. Если менялся домен — подаём заявку в обеих панелях: «Переезд сайта» в Яндекс.Вебмастере и «Изменение адреса» в Search Console. Важно: они работают только для смены домена или поддомена. Для смены структуры внутри одного домена аналога нет — там всё держится только на редиректах. О разнице между поисковиками — часть 9.
7. Прогоняем краулер по боевому сайту сразу после релиза. Полностью.
8. Не используем инструмент удаления URL. Он временно прячет адреса и мешает нормальной обработке.

Фаза 4. Первые 48 часов

Смотрим часто, руками:

• Коды ответа по топ-100 страницам.
• Логи сервера: сколько 404, куда идёт робот, нет ли всплеска ошибок.
• Живая аналитика: не обвалился ли трафик резко (значит, что-то сломано физически).
• Скорость ответа: редиректы добавляют задержку, а если у вас 40 000 правил в одном файле построчно — сервер может задыхаться. Используйте правила с регулярками или карту в базе/nginx map, а не 40 000 строк подряд.

Фаза 5. Недели 1–8

• Раз в неделю: отчёт по индексации в Search Console. Смотрим, как старые URL уходят, новые приходят.
• Раз в неделю: список 404 из логов и обеих панелей → чиним, дописываем в карту.
• Следим за цепочками: чинили что-то на новом сайте — не появилось ли A → B → C.
• Позиции: сравниваем со снимком «до».
• Пишем письма топ-донорам с просьбой обновить ссылку. Отзываются процентов 20, но это самые ценные 20%.

Фаза 6. Месяцы 2–6

• Ежемесячная сверка «трафик факт vs трафик до переезда с поправкой на сезон».
• Полный краул раз в месяц.
• Долечиваем хвост.
• Только теперь — не раньше — начинаем новые изменения на сайте.

Часть 8. Технические грабли, на которые наступают все

Какой редирект ставить

Ставите 302 при постоянном переезде — вы говорите поисковику «не обновляй книжку, я скоро вернусь». Он и не обновляет.

Цепочки редиректов

A → B → C → D — работает, но плохо. Каждый шаг — задержка, лишний запрос, потерянное время робота. А если где-то в середине окажется битое звено, вся цепь рвётся.

Правило: всегда чиним источник. Если старый A вёл на B, а B теперь стал C, — перепишите правило так, чтобы A → C напрямую.

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

Петли редиректов

A → B → A. Сайт умирает мгновенно. Обычно возникает из-за конфликта двух правил (например, «добавляй слэш» и «убирай слэш» одновременно, или правило www + правило https). Тестируйте на стенде.

Внутренние ссылки

Самая распространённая недоделка: поставили редиректы и решили, что дело сделано. А по сайту ходит меню со ссылками на старые адреса.

Это работает, но: медленнее, тратит краулинговый бюджет, и вы посылаете поисковику двойственный сигнал — «страница переехала, но мы сами ссылаемся на старую».

Внутри сайта все ссылки должны вести на конечные адреса.

Канонические теги

• Каждая новая страница — canonical сама на себя.
• Старые адреса canonical не спасают, если нет редиректа. Каноникал — рекомендация, редирект — команда.
• Не оставляйте canonical, указывающий на старый адрес. Видел и такое.

robots.txt

Не закрывайте старые URL. Робот должен иметь возможность прийти на старый адрес и увидеть 301. Если вы его туда не пускаете, он не узнает о переезде и будет годами держать в индексе мёртвые адреса.

Sitemap

• Новый sitemap — сразу в Вебмастер и Search Console.
• Старый — оставить доступным на несколько недель. Он служит списком «вот эти адреса, сходи проверь, что с ними».
• В новом sitemap только новые адреса, только 200, только canonical-версии.

Картинки

Если у вас меняются и адреса изображений — трафик из поиска по картинкам обнулится и будет восстанавливаться отдельно и медленно. Для интернет-магазинов и медиа это может быть заметная доля.

Совет: не меняйте пути к картинкам без нужды, даже если меняете пути страниц.

Мелочи, которые ломаются тихо

• og:url и Twitter-теги — обновить, иначе превью в соцсетях будут вести на старые адреса.
• Микроразметка (Product, Article, BreadcrumbList) — проверить, что URL внутри неё новые.
• hreflang — все взаимные ссылки между языковыми версиями надо переписать. Односторонний hreflang не работает.
• Пагинация — проверить, что она не осталась на старых адресах.
• Кэш CDN — сбросить, иначе он будет отдавать старые версии страниц ещё сутки.
• Внутренний поиск, фиды, RSS, sitemap для новостей — тоже адреса.
• Рекламные кампании — все конечные URL надо обновить вручную. Редирект их спасёт, но модерация некоторых площадок ругается на редиректы, а отчёты поедут.
• Цели и события в аналитике, настроенные по URL.
• Интеграции: CRM, партнёрские программы, фиды в маркетплейсы, товарные фиды.

Часть 9. Яндекс и Google переезжают по-разному

Почти всё, что пишут про переезды, написано под Google. Если ваш проект живёт в России, вы работаете с двумя поисковиками сразу — и они реагируют на смену адресов настолько по-разному, что один и тот же переезд может пройти идеально в одном и провалиться в другом. Классика из чата сообщества: «в Яндексе всё прошло успешно, в Google четвёртый месяц катастрофа».

Что важно знать про Яндекс

Он мыслит зеркалами. Для Яндекса смена домена — не «перетекание сигналов», а решение о том, какой хост считать главным. Пока зеркала не склеились, вы в подвешенном состоянии, и одних редиректов может не хватить: заявка в Вебмастере нужна почти всегда.

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

Расклеить обратно долго. В чате приводили кейс, где на это ушло около полугода. Планируйте так, будто решение необратимо.

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

Обход по счётчику Метрики ускоряет обнаружение новых адресов после переезда — но так же охотно тащит в индекс всё, что открыто и отдаёт 200. Перед релизом убедитесь, что мусор действительно закрыт.

Clean-param — ваш инструмент против параметров. В отличие от Disallow, эта директива говорит «страница та же, параметр не важен», то есть склеивает сигналы, а не выбрасывает страницу. Для utm-меток, сортировок и идентификаторов вариантов товара это правильнее.

Регион не переезжает сам. После смены домена его нужно назначить заново в Вебмастере, обновить адрес сайта в карточке Яндекс.Бизнеса и на картах. Забыть — значит потерять весь геозависимый трафик и долго не понимать почему.

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

Что важно знать про Google

«Изменение адреса» — только для смены домена. Внутри одного домена инструмента нет: работают исключительно редиректы, внутренние ссылки и карта сайта.

Запрет в robots.txt не равен отсутствию в индексе. Google может держать в индексе адрес, который ему запрещено обходить, — и это ровно тот механизм, который ломает переезды: он видит URL, но не видит на нём ваш 301. В чате разбирали именно такой случай: четыре месяца незавершённого переезда из-за старого домена, закрытого в robots.

Переиндексация идёт хвостом. Топовые страницы возвращаются за недели, длинный хвост доезжает месяцами. Ускоряют внутренние ссылки, sitemap и свежие внешние ссылки на новые адреса — а не многократные запросы на индексирование.

Что это значит для планирования

• Считайте сроки по худшему из двух. Яндекс обычно дольше склеивает, Google дольше переиндексирует хвост. Полное восстановление — по тому, кто медленнее.
• Ведите отчётность раздельно. Общий график трафика скроет ситуацию, когда одна система восстановилась, а вторая нет. Смотрите Яндекс и Google отдельными линиями с первого дня.
• Диагностируйте раздельно. Провал в одной системе при норме в другой — почти всегда локальная техническая причина, а не «алгоритмы»: заявка на переезд, robots, региональность, зеркала.
• Двойная структура удваивает переезд. Если у вас поддомены под Яндекс и папки под Google, при смене структуры вы переезжаете дважды и рискуете дважды.
• Поведенческие важнее там, где их больше. В Яндексе вес поведенческих факторов ощутимо выше, а через 301 они, по опыту участников сообщества, не передаются — метрики копятся заново. Для российского проекта это главный аргумент вообще не трогать адреса ранжирующихся страниц.

Часть 10. Что делать с внешними ссылками

Редиректы вас спасут технически. Но лучший внешний вид — когда донор ссылается напрямую.

Практический подход: 1. Выгрузите доноров, отсортируйте по ценности. 2. Возьмите топ-50–100. 3. Напишите живое короткое письмо: «Здравствуйте, у нас переехал сайт, ваша ссылка на такой-то материал теперь ведёт сюда: [новый адрес]. Всё работает через редирект, но если не сложно — обновите, будем благодарны». 4. Отзывается 15–30%. Это лучшая конверсия на единицу усилий в SEO вообще.

Отдельно: сервисы, где ссылку невозможно обновить (архивы, PDF, чужие рассылки). Именно из-за них редирект часто приходится держать и после того, как выдача полностью обновилась: замена в поиске произошла, а живые переходы по старому адресу остались.

Часть 11. Просадка: что нормально, а что уже тревога

После переезда трафик почти всегда падает. Вопрос — насколько и надолго.

Нормальная картина

• Дни 1–3: нервная болтанка, ±20%. Ничего не значит.
• Недели 1–3: просадка 10–25%. Это ожидаемо. Это норма. Не паникуйте и, главное, не начинайте «срочно чинить» вслепую.
• Недели 4–8: возврат к 90–100% от исходного. Иногда с проскоком выше.
• Месяцы 3–6: доехал хвост, показатели на уровне «до» или лучше.

Тревожные симптомы

Как отличить «мы накосячили» от «был апдейт»

• Проверьте, не было ли крупного апдейта в те же дни (по любому трекеру волатильности).
• Если просела вся тематика — вероятно, апдейт.
• Если просели только вы и ровно с даты релиза — это вы.
• Если просели отдельные разделы, а другие нет — почти наверняка проблема с редиректами в конкретном разделе. Идите смотреть его карту.

Про откат

Откат — крайняя мера, и он тоже переезд, со своей просадкой. Откатывать имеет смысл только в первые дни и только при явной технической поломке, которую нельзя починить на месте.

Откатывать через месяц «потому что трафик не вернулся» — обычно ошибка: вы платите вторую цену за то же самое.

Часть 12. Короткие ответы на вечные вопросы

Нужно ли ключевое слово в URL? Приятно, но эффект крошечный. Ради этого не переезжают.

Кириллица или транслит? Оба работают. Кириллица в браузере превращается в нечитаемую кашу при копировании — это минус для расшаривания. Я обычно советую транслит.

Слэш в конце или без? Всё равно, но выберите одно и придерживайтесь. Второй вариант должен отдавать 301 на первый.

www или без www? Всё равно. Выберите одно, второе — 301.

Плоская структура или вложенная? Для ранжирования разница минимальна. Вложенность полезна людям и вам самим — для аналитики и понимания сайта. Не стройте 6 уровней там, где хватает двух.

Длина URL? Короче — удобнее людям. Ограничений, о которых стоит переживать, нет. Не пишите роман в адресе, и хватит.

Дефисы или подчёркивания? Дефисы. Исторически безопаснее. Но менять существующие ради этого — нет.

Верхний регистр? Не используйте. Сервер может считать /Page и /page разными адресами → дубли. Всё в нижнем, второй вариант — 301.

Стоит ли убирать .html? Косметика. Ради этого не переезжают.

А как со всеми этими AI-ответами и нейропоиском? Механика примерно та же: их источники берутся из индекса, а индекс обновляется по мере обхода. Плюс есть сторонние кэши и датасеты, которые обновляются реже. То есть переезд для AI-выдачи «доезжает» ещё медленнее. Аргумент в пользу того, чтобы делать это реже и аккуратнее.

Помогает ли переезд выйти из-под фильтра? Нет. Санкции переезжают с вами.

Можно ли сделать переезд «постепенно», по разделам? Да, и часто это отличная идея для больших сайтов. Переезжаете сначала одним небольшим разделом, смотрите две-три недели, что происходит, — и уже с реальными данными решаете, катить ли дальше. Дороже по срокам, дешевле по риску.

Часть 13. Вопросы из чата сообщества

Это не выдуманный FAQ. Всё ниже реально спрашивали в чате «Хороших SEOшников» — разобрали 28 599 сообщений за январь 2023 — август 2026 и вытащили то, что касается адресов, редиректов и переездов. Формулировки вопросов сокращены, ответы сводные: что сказали в чате плюс то, что стоило добавить.

Обновляем логику ЧПУ и хлебных крошек у крупного агрегатора. У части страниц изменятся URL, а они уже в топ-10. Позиции упадут? Можно что-то сделать превентивно? (август 2024)

Главное здесь то, что у вас есть выбор, какие URL менять. Сохраните адреса всех страниц, которые уже ранжируются, даже если новая логика делает их некрасивыми исключениями. Меняйте структуру там, где страниц в топе нет. Всё остальное — 301 один в один.

Превентивно сделать нельзя ничего, кроме подготовки: снимок позиций и трафика до релиза, ручная проверка карты по топовым страницам, релиз не в сезон. И предупредите клиента заранее, что просадка на 2–4 недели — норма, а не повод откатываться. Если сказать об этом после релиза, вам не поверят.

Уже сменили структуру, старые URL отдают 404. Стоит ли ставить 301, если страниц около 2500? И не перегрузят ли редиректы сам сайт? (апрель 2025)

Ставить, и срочно. 2500 живых 404 — это 2500 страниц, которые выпадут из индекса вместе со своей историей и внешними ссылками.

Про нагрузку опасение не пустое, но причина не та. Тормозит не количество редиректов, а способ их описать: 2500 строк подряд в .htaccess Apache перечитывает на каждый запрос — вот это действительно больно. Делайте через map в nginx, RewriteMap в Apache или таблицу в базе с индексом по старому адресу. Тогда разницы между 2500 и 250 000 правил нет.

Сайт на Joomla, старый, позиции хорошие, бренд наработан. Нужен новый дизайн на WordPress. Как правильно: завести новый домен и редиректить, или переезжать на том же? (май 2025)

На том же домене — новый домен здесь это второй переезд поверх первого без единой причины. Схема, которую предложили в чате и с которой я полностью согласен: собираете новый сайт на техническом домене или поддомене, закрытом паролем (не только через robots.txt), переносите контент один в один, сохраняете структуру URL, микроразметку и скорость загрузки — и только потом переключаете боевой домен.

Оттуда же трезвая цифра, которую стоит запомнить: качели в 15–20% трафика в первые недели — нормальная реакция даже на идеально сделанный переезд.

Домен остаётся прежним, меняются только сами адреса страниц. Редиректы вообще нужны? (май 2025)

Нужны. Для поисковика нет никакой разницы между «редирект внутри домена» и «редирект между доменами» — есть старый адрес и новый. Если адрес изменился хоть одним символом, это уже другая страница.

Редирект с адресов без слеша на адреса со слешем настроен больше года назад. А краулер каждый день находит новые страницы без слеша, и они выпадают из индекса с пометкой «Редирект». Откуда они берутся и что делать? (март 2023, март 2025)

Робот не выдумывает адреса — он их где-то нашёл. Ищите источник внутри своего же хозяйства: карта сайта, выгрузка из 1С или другой интеграции, ссылки в шаблоне и в текстах, фиды, старые внешние ссылки. В обоих случаях, что разбирали в чате, виноват был сам сайт: то sitemap, то синхронизация с 1С отдавала адреса в старом формате.

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

Пытаюсь склеить дубли главной — index.php, index.html, версию без слеша. Как ни пишу правила в .htaccess, получается цепочка из двух-десяти редиректов вместо одного. (февраль 2025)

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

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

Есть редирект с одного домена на другой. Нужно ли продлевать SSL-сертификат на домене, с которого идёт редирект? (ноябрь 2023)

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

Часто вижу, что при 301 в заголовке Location стоит не полный адрес, а относительный путь без домена и протокола. Это может навредить? (май 2024)

Нет. Относительный путь корректен и работает. Более того, при будущей смене домена такие правила не придётся переписывать. Вредят не относительные пути, а неправильный конечный адрес и цепочки.

Краулер показывает на страницах 302, а при заходе в браузере — 200. Кто врёт? (июль 2023)

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

На лендинг закупили ссылки, а потом решили редиректить его на более релевантную страницу — две страницы бились за один запрос. Что будет со ссылками и стоит ли так вообще делать? (апрель 2024)

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

Сделал всё как положено: постраничные 301 на новый домен, заявку на переезд в панелях, обновил ссылки в соцсетях. Результата нет. Что не так? (март 2025)

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

Срок, после которого пора не ждать, а проверять карту редиректов, — примерно шесть недель без всякой динамики.

В первый день после переезда сайт начал появляться в позициях, на вторые сутки пропал. Могли что-то нарушить при переезде? (август 2024)

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

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

Переезжаем на новый домен — стоит ли пользоваться инструментом «Переезд сайта» в панели вебмастера? (октябрь 2024, март 2025, апрель 2025)

Да. Связка «постраничный 301 + заявка на переезд» отрабатывает заметно бережнее, чем одни редиректы: в чате это подтверждали несколько человек с разными проектами.

Важная оговорка: инструмент существует только для смены домена или поддомена. Для смены структуры внутри одного домена аналога нет — там всё держится на редиректах, внутренних ссылках и карте сайта.

Региональное продвижение: поддомены или папки? И не сделать ли сразу обе структуры? (июль 2023, июнь 2024, январь 2025)

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

И про количество. Сотни поддоменов под все города — решение из прошлого. В чате описан показательный путь: тысяча поддоменов → триста → семьдесят → сорок, и на сорока остановились. Начинайте с крупных городов, а не с полного справочника.

Стоит ли добавлять в URL коммерческие приставки — kupit, zakazat, cena? (май 2024)

Не стоит. Вы искусственно раздуваете адрес, а за спам-повторы слов в URL можно скорее получить минус, чем плюс. Достаточно транслита того, что стоит в H1 страницы. Единственное исключение, о котором говорили в чате: price или skolko-stoit в информационных разделах, где это отражает содержимое, а не пытается подтянуть коммерцию.

В подкатегории приходится повторять слово из родительской категории, иначе слаги конфликтуют с другими разделами. Насколько это некомильфо? (декабрь 2024)

Микропринципиально — в чате сошлись именно на этом, и я согласен. Повтор слова в адресе не стоит ни строчки кода. Уникальность слагов важнее эстетики, а ломать из-за такого структуру нельзя вообще.

Свежее: осень 2025 — лето 2026

Переводим крупный образовательный сервис с плоской структуры URL на иерархическую: главная → раздел → тип работы → предмет → карточка. Получается пять уровней. Насколько рискованна такая вложенность? Постраничные 301 настроим. (июль 2026)

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

В чате ответили резко: процесс неконтролируемый, есть риск потерять трафик и не восстановиться. Я скажу мягче: контролируемый, но только по протоколу и только если вы честно ответили, что выигрываете. И раз опыта таких переездов нет — сделайте пилот на одном разделе, подождите три-четыре недели, посмотрите на реальные цифры, и только потом катите остальное.

После переезда сайта аптеки все позиции из топ-3–5 вылетели за топ-100 и не вернулись за два месяца. Что делать? (июль 2026)

Это уже не «нормальная просадка». Двух месяцев достаточно, чтобы отличить перестройку индекса от поломки: если бы дело было только в переобходе, к этому сроку была бы хотя бы динамика вверх.

Проверять в таком порядке: отдают ли старые адреса 301 (а не 404 и не 302); ведут ли редиректы на смысловые аналоги, а не на главную; не закрыты ли старые адреса в robots.txt; проиндексированы ли вообще новые страницы; не поменялся ли вместе с адресами контент; нет ли на новых страницах noindex или чужого canonical. В девяти случаях из десяти находится один из этих пунктов, а не «алгоритмы разлюбили».

Через 301 передаются поведенческие факторы? Ссылочная масса передаётся, а ПФ? (июль 2026)

Ссылочное передаётся, поведенческие — практически нет. В чате ответили ровно так же: адрес меняется, и метрики копятся заново. Это логично: история кликов и поведения привязана к конкретному URL, а не к абстрактной «странице».

Отсюда очень практичный вывод: страницы с хорошими накопленными поведенческими — последние кандидаты на смену адреса. Если можете оставить их на старых URL — оставьте, даже если это ломает красоту новой схемы.

Сменили название компании и домен. В Яндексе переезд прошёл успешно, в Google катастрофа: четыре месяца статус «переезд выполняется», ни одна страница нового домена не проиндексирована, а старый домен продолжает индексироваться, хотя стоит 301 и он закрыт в robots.txt. (февраль 2026)

Причина в самой последней фразе вопроса. Старый домен закрыт в robots.txt — значит, робот не может на него зайти и увидеть ваш 301. Для него старые адреса просто существуют и недоступны для проверки: он не получает сигнала о переезде, поэтому не переносит сигналы на новый домен и продолжает держать старое в индексе.

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

Настроил 301 с категорий на посадочные полгода назад, всё переиндексировалось как надо. Когда можно удалять старые страницы и редиректы? (декабрь 2025)

Никогда. «Всё переиндексировалось» означает, что поисковики разобрались, — но не означает, что перестали существовать внешние ссылки, закладки, ссылки в старых рассылках, в чужих статьях, в PDF и в архивах. Эти источники будут жить годами.

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

Сколько времени занимает «расклейка» доменов, если что-то пошло не так? (февраль 2026)

Долго. В чате приводили кейс, где на это ушло около полугода. Это к вопросу о том, почему склейку и переезд нельзя делать «на пробу»: откатить такое решение получится не за неделю, а за сезон.

Переносим обучающую платформу с отдельного домена на основной. Подпапка site.com/platform/ или поддомен platform.site.com? И не размоет ли релевантность технический мусор — страницы входа, личные кабинеты, пустые разделы? (март 2026)

Подпапка, если нет технических препятствий: она консолидирует авторитет в одном домене, а поддомен поисковик во многом воспринимает как отдельный сайт.

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

Проектируем новостной агрегатор с федеральными и региональными разделами. Что лучше: /sport/kazan или /kazan/sport? И не будет ли пессимизации и каннибализации от тысяч малотрафиковых страниц «рубрика + город»? (август 2025)

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

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

У сайта кириллический домен. Canonical указывать в punycode или можно кириллицей? (июнь 2026)

Надёжнее punycode. Ещё надёжнее — относительный путь без домена: домен подставится сам, и вы не ошибётесь с кодировкой. Если и путь на кириллице — тоже кодируйте. Это как раз к вопросу, почему я обычно советую транслит.

В Search Console «Ошибка переадресации» при переезде с сайта А на сайт Б. Цепочек нет, петель нет, логи чистые, на Б стоит антибот. Куда копать? (март 2026)

В антибот. Логи вы смотрите по своим запросам, а робот может получать не редирект, а страницу проверки или капчу — для него это и есть «ошибка переадресации». Проверьте поведение конечного адреса при чужом user-agent и с IP вне вашей страны, посмотрите, не режет ли защита краулеров поисковиков, и добавьте их в исключения.

После ухода Cloudflare из России перенесли сайты на свои прокси, и переезды перестали проходить: 301 стоит, а поисковик его будто не видит. Раньше переезжали за двое суток. (ноябрь 2025)

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

Есть два сайта: первый старше и на него куча ссылок, второй лучше конверсит и быстрее растёт. Склеить первый со вторым или оставить как есть? (август 2025)

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

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

Часть 14. Пять типичных историй

Магазин, который захотел покрасивее. Было /product/553-lenovo-x1, стало /noutbuki/lenovo-thinkpad-x1. Причина — «ID в адресе выглядит непрофессионально». Карту соответствий сгенерировали скриптом, вручную не проверили. Оказалось, у 8% товаров совпадали слаги — скрипт склеил их в один адрес. Минус треть трафика, полтора месяца разбора, часть позиций не вернулась. Выигрыш от «красоты»: ноль.

Блог, который переехал с поддомена. blog.company.com → company.com/blog/. Сделали по протоколу: карта 1:1, контент не трогали, релиз во вторник в январе. Просадка 15% на три недели, через два месяца — плюс 20% к исходному. Тот самый случай, когда переезд оправдан.

Ребрендинг перед сезоном. Смена домена в начале ноября, потому что «презентация бренда назначена на эту дату». Просадка совпала с пиком сезона. Технически всё сделали правильно, трафик вернулся за пять недель — но эти пять недель стоили примерно как годовой бюджет на маркетинг.

Тихая смерть через два года. Переезд сделали идеально. Через два года меняли хостинг, новый подрядчик не перенёс конфиг с редиректами. Просадка 25%, искали причину девять дней, потому что «мы же ничего не меняли».

Всё сразу. Новая CMS + новый дизайн + новая структура URL + переписанные тексты, одним релизом. Трафик минус 45%. Три месяца команда не могла определить, что именно сломалось, потому что сломалось четыре вещи одновременно, и каждая маскировала остальные. В итоге откатывали дизайн, потом заново.

Часть 15. Чек-лист на одну страницу

Перед решением - [ ] Сформулирована конкретная поломка или конкретный измеримый выигрыш - [ ] Проверено, что проблему нельзя решить без переезда - [ ] Не сезон - [ ] Нет других крупных изменений в те же 4–6 недель - [ ] Выделен ресурс на сопровождение 3–6 месяцев

Подготовка - [ ] Полный краул «до» сохранён - [ ] Выгрузки Вебмастера и Search Console сохранены - [ ] Выгрузка аналитики и позиций сохранена - [ ] Выгрузка ссылочного профиля сохранена - [ ] Карта соответствий 1:1 составлена, покрытие 100% - [ ] Топ-100 по трафику и топ-100 по ссылкам проверены вручную - [ ] Стенд закрыт паролем, редиректы протестированы

Релиз - [ ] Новая структура и редиректы выкатываются одновременно - [ ] 301, не 302 - [ ] Нет цепочек и петель - [ ] Ничего не редиректит на главную без причины - [ ] Внутренние ссылки, меню, хлебные крошки переписаны - [ ] Новый sitemap загружен, старый оставлен доступным - [ ] robots.txt не блокирует старые адреса - [ ] Canonical, hreflang, микроразметка, og-теги обновлены - [ ] Кэш CDN сброшен - [ ] Заявка на переезд подана в Вебмастере и Search Console (если менялся домен) - [ ] Регион в Вебмастере переназначен, карточка Яндекс.Бизнеса обновлена - [ ] Счётчик Метрики и цели по URL перенастроены - [ ] Рекламные кампании, фиды, интеграции обновлены - [ ] Карта редиректов в репозитории с пометкой, при каких условиях её можно снимать

После - [ ] Краул сразу после релиза - [ ] Мониторинг логов и 404 — ежедневно первую неделю, дальше еженедельно - [ ] Письма топ-донорам отправлены - [ ] Еженедельный отчёт по индексации и позициям - [ ] Никаких новых крупных изменений минимум 4–6 недель

Три правила напоследок

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

Правило второе. Если переезжаете — переезжайте один раз, целиком и по протоколу. Половинчатый переезд, растянутый на три релиза с недоделанной картой, хуже и кривой структуры, и чистого переезда.

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

Удачного переезда. И пусть он вам не понадобится.

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

← Все материалы