«Я думала, что “настроить редиректы для SEO” — это просто прописать пару строк в .htaccess, а потом чуть не убила весь трафик: рассказываю, как грамотно настроила редиректы на Timeweb и не потеряла позиции»

У меня был сайт мебельного магазина: около 800 страниц, хороший органический трафик, позиции по ключевым запросам. Клиент сказал: «Мы меняем структуру каталога: категории переименовываем, старые URL больше не нужны. Надо всё перекинуть на новые адреса». Я кивнула, а внутри всё сжалось: в голове крутились страшные сценарии. «А если я сделаю 302 вместо 301 — поисковик решит, что страницы временно переехали, и не перенесёт вес. Или сделаю цепочку редиректов, и позиции просядут. Или случайно зациклю редирект, и сайт станет недоступен».

До этого я делала редиректы по статьям из интернета: копировала примеры в .htaccess и надеялась, что «всё сработает». И пару раз это действительно ломало сайт: страницы открывались с ошибкой 500, а в консоли были бесконечные переадресации. Тогда я впервые всерьёз задумалась: надо делать это системно, с бэкапами, проверками и пониманием, что именно делает каждая строка.

Чего я боялась больше всего

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

Сделать 302 вместо 301. Боялась, что поисковики не поймут, что переезд постоянный, и обнулят вес старых страниц.
Создать цепочку редиректов. Например: старая страница → промежуточная → новая. Это убивает передачу ссылочного веса и ухудшает индексацию.
Зациклить редирект. Одна неправильная строка — и браузер бесконечно перекидывает пользователя, а сайт получает статус «недоступен».
Потерять трафик с внешних ссылок. Если на старые страницы ведут ссылки с других сайтов, а я их не перекину на актуальные, люди будут попадать на 404.
Не успеть откатиться, если сайт «ляжет». Если .htaccess будет с ошибкой, сайт может вообще перестать открываться.

С этим списком я пошла в панель Timeweb и составила план: сначала тест на копии, потом точечные редиректы, потом проверка инструментами.

Шаг 1: сделать бэкап и развернуть тестовую версию

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

Потом создала тестовый поддомен redirect-test.site.ru и развернула туда копию сайта: отдельная папка, отдельная база с префиксом. Именно на этой версии я планировала тестировать все редиректы. Это сразу сняло половину паники: если что‑то пойдёт не так, основной трафик не пострадает.

Шаг 2: собрать список старых и новых URL

Без списка делать редиректы — это лотерея. Я выгрузила все старые адреса из карты сайта (sitemap.xml) и из Яндекс Вебмастера, а рядом прописала, на какие новые страницы они должны вести.

Пример таблицы:

Старый URL	Новый URL	Тип редиректа
`/old-category/sofa/`	`/new-catalog/divans/`	301
`/blog/article-old-name/`	`/articles/new-name/`	301
`/promo-2023/`	`/catalog/sale/`	301

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

Шаг 3: написать правила редиректов в .htaccess

В панели Timeweb я открыла файловый менеджер, зашла в корневую папку сайта и отредактировала .htaccess. Перед этим я сохранила старую версию файла — ещё одна страховка.

Для точечных редиректов я использовала директиву Redirect:

Это самый простой и безопасный вариант: он делает именно то, что нужно, и почти не даёт ошибок.

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

Критично: флаг [L] означает «остановиться здесь». Без него правила могут срабатывать дальше и создавать цепочки.

Все правила я сначала внесла в тестовый .htaccess на поддомене и проверила, что они работают.

Шаг 4: проверить редиректы вручную и инструментами

На тестовой версии я сделала три проверки:

Вручную: открыла старый URL — он должен сразу вести на новый, без промежуточных страниц. В адресной строке должен быть именно целевой URL.
Через консоль браузера: нажала F12 → Network, обновила страницу со старым URL и посмотрела статус: должен быть 301, а не 302 и не ошибка.
Через сервисы проверки редиректов: вбила старый URL в инструмент типа Redirect Checker — он показал один шаг 301 и финальный адрес.

Так я убедилась, что нет цепочек и циклов, а редиректы ведут именно туда, куда нужно.

Шаг 5: перенести правила на основной сайт и проверить индексацию

Когда на тестовой версии всё было готово, я:

Сделала ещё один ручной бэкап основного сайта.
Перенесла правила из тестового .htaccess в основной.
Проверила 10–20 самых важных старых URL — все корректно вели на новые страницы.
Обновила sitemap.xml и отправила новую карту сайта в Яндекс Вебмастер и Google Search Console.
Проверила robots.txt: убедилась, что новые страницы не закрыты от индексации.

Это важно: поисковики должны понять, что старые страницы переехали, а новые — это их преемники.

Шаг 6: следить за ошибками и трафиком после переезда

Первые 2–4 недели я регулярно проверяла:

Ошибки 404 в Вебмастере: если они есть, значит, какие‑то старые URL не перекинуты.
Трафик по старым страницам: он должен плавно перетекать на новые.
Позиции по ключевым словам: если позиции просели, возможно, где‑то есть цепочка редиректов или 302 вместо 301.

В моём случае просадки не было: позиции и трафик сохранились, потому что редиректы были корректными и точечными.

Где я чуть не ошиблась (и что панель подсказала)

Хотела сделать редирект всех страниц категории на главную. Хорошо, что сначала подумала: это ухудшит UX и SEO. Я сделала точечные редиректы на релевантные страницы.
Пыталась использовать сложные регулярные выражения без теста. Написала правило, которое должно было перекинуть всю папку, но из‑за ошибки создало цикл. На тестовом поддомене это сразу стало видно.
Забыла добавить протокол и домен в целевой URL. Если писать просто /new-page/, при некоторых настройках это может вести не туда. Я всегда пишу полный URL: https://site.ru/new-page/.
Не проверяла статус в Network. Думала: «Открывается новая страница — значит, всё ок». Но без проверки статуса можно не заметить, что стоит 302 или есть цепочка.
Не обновила карту сайта. Если оставить старые URL в sitemap, поисковик будет их проверять и фиксировать ошибки. Поддержка подсказала: «Сначала настройте редиректы, потом обновите sitemap и отправьте в вебмастера».

Что реально помогло на Timeweb

Бэкапы в один клик. Я могла откатиться за минуты, если .htaccess ломал сайт.
Файловый менеджер. Быстро редактировала .htaccess и проверяла, нет ли синтаксических ошибок.
Возможность развернуть тестовую копию. Это дало безопасную площадку для всех правок.
Поддержка. Когда сомневалась, правильно ли составлен RewriteRule, в чате ответили за пару минут и даже прислали безопасный пример.
Панель с понятными статусами. Видно, какие файлы изменены, когда и кем — проще контролировать изменения.

Практические советы, чтобы редиректы не убили трафик

Если вы тоже планируете менять URL, вот что реально спасает:

Всегда делайте бэкап перед правкой .htaccess. На Timeweb это пара кликов, а откатиться можно за минуты.
Тестируйте редиректы на тестовом поддомене. Это лучшая страховка от падения сайта.
Используйте 301 для постоянного переезда. 302 — это «временно», и он не передаёт вес страниц.
Делайте точечные редиректы. Каждая старая страница должна вести на максимально релевантную новую.
Избегайте цепочек редиректов. Один шаг 301 от старого URL к новому — идеальный вариант.
Проверяйте статус через Network или специальные инструменты. Убедитесь, что стоит именно 301 и нет циклов.
Обновляйте sitemap.xml и отправляйте в вебмастера. Так поисковики быстрее узнают о новых адресах.
Следите за ошибками 404 и динамикой трафика. Это поможет вовремя заметить проблемы.

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