Подготовьте карту URL до начала работ

Редизайн затрагивает структуру, навигацию, шаблоны, каталог и адреса материалов. Если прежние страницы уже участвовали в поиске, получали ссылки, приносили заявки или были сохранены пользователями, их нельзя просто удалить. Задача переноса состоит в том, чтобы каждый важный URL получил понятный ответ сервера и вёл посетителя на максимально близкий новый адрес. Именно так сохраняются позиции, переходы и накопленные сигналы качества.

Перед изменениями выгрузите список всех URL из систем аналитики, поисковых панелей, XML-карты, журнала запросов и базы материалов. Отдельно соберите адреса с переходами, внешними ссылками, конверсиями и показами. Для каждого URL укажите целевой адрес, код ответа, приоритет, источник данных и дату проверки. Такая таблица позволит понять, что необходимо перенести, что можно объединить, а что допустимо убрать без потери полезного трафика.

На хостинге beget управление проектом начинается с проверки, какой домен подключён к каталогу и какой каталог используется как public-директория. Убедитесь, что новый шаблон размещён в правильной папке, а файлы html, php, изображения и служебные данные доступны по ожидаемому пути. Ошибка в корневом каталоге приводит к ситуации, когда правило написано правильно, но сервер обрабатывает не тот файл htaccess.

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

Какие адреса включить в таблицу переноса

• главную страницу, варианты с протоколами http и https, а также варианты с www;
• разделы каталога, статьи блога, новости, страницы услуг и материалы поддержки;
• URL с параметрами, метками рекламных кампаний, пагинацией и фильтрами;
• адреса, которые ранее использовали php, html или завершающий слеш;
• устаревшие страницы, для которых требуется подобрать замену либо убрать из индекса;
• поддомены, если при обновлении меняется домен или структура доступа;
• файлы загрузок, изображения, документы и страницы, на которые указывают внешние ссылки.

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

Для аудита используйте сканер, журнал сервера и данные поисковых систем. Сканер покажет внутренние ссылки и коды ответов, журнал выявит редко посещаемые, но ещё востребованные адреса, а панели помогут оценить индексирование. В панели beget также полезно проверить, какие домены привязаны к аккаунту и в какой каталог направлен каждый домен. Это снижает риск, что настройки будут сделаны для неправильного окружения.

Выберите корректный тип перенаправления

Для постоянного переноса обычно используют HTTP 301. Такой ответ сообщает браузерам и поисковым роботам, что документ окончательно изменил адрес. Временный 302 применяют, когда исходная страница должна вернуться: например, при кратком тесте, сезонной акции или техническом обслуживании. Не следует подменять постоянное решение временным кодом, если структура изменена надолго.

Редирект должен выполняться одним шагом. Цепочка из нескольких переходов увеличивает время загрузки, усложняет обход и расходует краулинговый бюджет. Если сначала выполняется переход с http на https, затем с www на вариант без www, после этого меняется путь, правила необходимо объединить. Финальный URL обязан открываться с кодом 200, содержать полезный контент и быть доступен без авторизации.

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

Настройка в панели управления

1. Войдите в панель beget и откройте раздел управления доменами.
2. Выберите домен, который ранее использовался посетителями и поисковыми роботами.
3. Проверьте, что у домена верно настроены DNS-записи, SSL-сертификат и каталог public.
4. Откройте параметры перенаправления и укажите полный целевой URL с протоколом https.
5. Выберите постоянный вариант, если перенос не имеет временного характера.
6. Сохраните изменения и дождитесь применения конфигурации на сервере.
7. Откройте исходный адрес в браузере и проверьте код ответа средствами разработчика.

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

Пример точного правила для одной страницы

RewriteEngine OnRedirect 301 /old-page.html https://example.ru/new-page/

Этот вариант подходит, когда старый URL имеет понятную замену. После добавления откройте исходный адрес в режиме инкогнито и проверьте заголовки. Если ответ показывает 301, а конечный документ возвращает 200, базовая проверка пройдена. Если вместо ожидаемого пути открывается главная, правило нужно убрать и заменить точным соответствием.

Пример переноса раздела каталога

RewriteEngine OnRewriteRule ^catalog/(.*)$ https://example.ru/products/$1 [R=301,L]

Перед применением убедитесь, что новая структура действительно сохраняет хвост URL. Иначе посетитель получит страницу 404, хотя редирект выглядит рабочим. Для сложных систем управления содержимым необходимо учитывать маршруты PHP, обработчики запросов и правила самого фреймворка. Пользовательские правила переноса обычно размещают выше универсального rewrite-маршрута, но после исключений для файлов и административных разделов.

Единый вариант с www и без www

У ресурса должен быть один главный вариант адреса. Если одновременно открываются версии с www и без www, поисковый робот может увидеть дубли. Выберите канонический формат, настройте HTTPS и приведите к нему все альтернативы. Ниже приведён контрольный перечень, который помогает не пропустить важные комбинации.

Не стоит направлять все варианты с www на новый путь отдельными последовательными правилами. Гораздо надёжнее сразу задать конечный протокол, выбранный формат хоста и актуальный путь. Это помогает убрать лишние переходы и делает обработку запросов предсказуемой для браузера, робота и систем аналитики.

Работа с доменом при смене бренда

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

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

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

Для домена с почтой отдельно проверьте MX-записи, SPF, DKIM и доступ к ящикам. Перенаправление веб-запросов не должно затронуть почтовые услуги. Если домен используется для API, webhook или интеграций клиентов, заранее проверьте документацию, уведомите пользователей и оставьте переходный период. Три услуги, которые чаще всего требуют отдельной проверки, — почта, API и платёжные уведомления.

Проверка после публикации

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

Откройте URL в браузере без сохранённых cookies и убедитесь, что редирект срабатывает сразу.
Проверьте заголовок Location и убедитесь, что он ведёт на защищённый адрес.
Уберите внутренние ссылки на прежние страницы из меню, хлебных крошек, карточек и материалов блога.
Уберите старые URL из XML-карты и добавьте в неё новые страницы с ответом 200.
Уберите ссылки на тестовый каталог из шаблонов, баннеров и писем.
Уберите устаревшие правила, которые создают повторный переход.
Уберите дубли метатегов, если после переноса одновременно доступны две версии материала.
Уберите страницы с ошибкой 500 до отправки обновлённой карты поисковым роботам.

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

Если старый путь не имеет релевантной замены, лучше вернуть 410 или 404, чем направлять посетителя на нерелевантный раздел. Массовый редирект на главную воспринимается как плохой пользовательский сценарий. Можно убрать такую страницу из карты, убрать ведущие к ней внутренние ссылки и оставить честный код ответа. Это помогает поисковым системам быстрее обработать изменение.

Типичные ошибки при настройке

Первая ошибка — использовать один редирект для всех URL без проверки соответствия. Вторая — оставить циклический переход между http, https и www. Третья — забыть, что домен может обслуживаться через отдельный каталог или иметь собственный файл htaccess. Четвёртая — удалить старые адреса до того, как поисковые системы увидят постоянный ответ. Пятая — не обновить ссылки в шаблонах, статьях, новостях и карточках.

Необходимо также убрать правила, которые перенаправляют изображения, CSS, JavaScript и служебные файлы на HTML-страницы. Такие изменения ломают оформление и ухудшают скорость. Исключения для каталога public, административной панели и файлов должны быть понятными. Если проект использует php-маршрутизацию, проверьте, что запрос к реальному файлу не попадает в обработчик страниц.

На beget можно обратиться в поддержку, если требуется уточнить путь к каталогу, доступность конфигурации или особенности работы сервера. Для обращения подготовьте домен, пример URL, время проверки, ожидаемый и фактический код ответа, а также содержимое relevant-фрагмента htaccess. Это поможет специалисту быстрее воспроизвести ситуацию и дать точный ответ.

Контрольный план сохранения поискового веса

1. Соберите URL, ссылки, данные аналитики и важные запросы.
2. Определите, какой новый адрес соответствует каждой ценной странице.
3. Создайте резервную копию файлов, базы и текущих настроек.
4. Настройте постоянные правила для точных страниц и разделов.
5. Проверьте домен, сертификат, public-каталог и файл htaccess.
6. Уберите цепочки, циклы, дубли и переходы на нерелевантные материалы.
7. Обновите ссылки, карту сайта, canonical и данные в панелях вебмастеров.
8. Проверьте ответ сервера, логи и ошибки после публикации.
9. Сохраните карту переноса для последующих изменений и аудита.

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

Проверка HTTP-заголовков и кодов ответа

После публикации недостаточно убедиться, что страница визуально открывается в браузере. Необходимо проверить технический ответ сервера для каждого приоритетного URL. Браузер может показать конечный документ, скрыв промежуточные переходы, ошибки сертификата или неверный код. Для SEO важна вся последовательность обработки запроса: исходный адрес, статус, заголовок Location, конечная страница и её доступность для индексации.

Проверку удобно выполнить через инструменты разработчика, консоль, сервис анализа заголовков или сканер. В результате для исходного адреса должен отображаться HTTP 301, а для целевого — HTTP 200. Если вместо этого возвращается 302, 307, 404, 410 либо 500, требуется выяснить причину. Ошибка может находиться в файле htaccess, правилах CMS, настройках CDN, конфигурации сервера или в маршрутах php-приложения.

Минимальный набор проверок

• Старый URL возвращает постоянный редирект без задержки.
• Конечный URL открывается по HTTPS и отдаёт содержательный HTML.
• Страница не содержит запрета в robots и не имеет метатега noindex.
• Canonical указывает на собственный актуальный адрес.
• В цепочке нет повторных переходов между протоколами, папками и версиями адреса.
• Файл robots.txt не блокирует обход нового раздела.
• XML-карта содержит только URL, которые возвращают код 200.
• Внутренние ссылки ведут напрямую на актуальные материалы.

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

Если проверка показывает цикл, сначала определите все правила, участвующие в обработке. Один редирект может менять протокол, второй — путь, третий — формат слеша, а четвёртый — имя домена. В результате посетитель снова возвращается на исходный адрес. Чтобы убрать цикл, задайте единый конечный URL в одном приоритетном правиле и временно отключите пересекающиеся условия.

Внутренние ссылки после редизайна

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

Для сайта важно проверить не только основное меню. Ссылки часто остаются в футере, виджетах блога, комментариях, PDF-файлах, XML-выгрузках, шаблонах рассылок и автоматических уведомлениях. В некоторых CMS старые адреса сохраняются в базе данных, настройках виджетов или полях редактора. Их необходимо найти поиском по базе, заменить и затем повторно проверить сканером.

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

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

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

Работа с файлами htaccess и PHP

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

Размещайте точные правила выше общих. Например, сначала обрабатываются отдельные URL, затем перенос разделов, после этого единый формат протокола и хоста. В конце обычно находятся правила фреймворка, которые передают запрос в index.php. Если поставить общий маршрут слишком высоко, он перехватит запрос раньше, чем отработает нужный редирект.

RewriteEngine OnRewriteCond %{REQUEST_FILENAME} !-fRewriteCond %{REQUEST_FILENAME} !-dRewriteRule ^old-section/$ /new-section/ [R=301,L]

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

Если приложение использует php, убедитесь, что обработчик не формирует собственные перенаправления поверх серверных правил. Такое бывает в CMS, фреймворках, плагинах мультиязычности и модулях авторизации. Временно отключать рабочие компоненты не требуется: достаточно отследить порядок выполнения и убрать дублирующее условие в той части системы, которая не должна отвечать за перенос URL.

На beget полезно проверить права доступа к файлу и соответствие кодировки. Файл htaccess должен быть доступен серверу, не содержать лишних управляющих символов и сохраняться в корректном формате. Если после загрузки появляется ошибка 500, верните резервную версию, затем добавляйте правила по одному. Такой метод позволяет точно определить строку, которая вызывает проблему.

Особенности переноса материалов и каталогов

Для сайта с услугами важно сопоставить прежние посадочные страницы с новыми. Если одна услуга была объединена с другой, выберите документ, который действительно раскрывает прежнюю тему, стоимость, условия и порядок обращения. Не следует отправлять трафик на общий каталог, когда существует более точная страница. Тематическая близость влияет и на удобство посетителя, и на передачу сигналов из поиска.

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

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

Для сайта с архивом новостей проверьте даты, пагинацию и теги. Иногда новая CMS формирует адреса в другом формате, например без года, месяца или расширения html. В такой ситуации массовый шаблонный редирект уместен только после проверки нескольких десятков URL. Нужно убедиться, что дата и идентификатор действительно преобразуются одинаково для всех публикаций.

Изменение имени домена

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

Проверьте настройки домена у регистратора и на хостинге: DNS-записи, SSL-сертификат, привязку каталога, почтовые записи и правила обработки HTTP. Новый адрес не должен открываться только частично. Если главная страница работает, а внутренние URL возвращают ошибку, поисковый робот не сможет корректно обработать перенос.

При работе с доменом полезно заранее подготовить список критичных интеграций. В него входят формы, CRM, платёжные сервисы, API, почтовые уведомления, аналитика, коллтрекинг и виджеты поддержки. Некоторые сервисы разрешают запросы только с определённого адреса. После изменения необходимо обновить разрешённые URL, ключи, callback-адреса и настройки безопасности.

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

Сотрудники поддержки beget смогут быстрее помочь, если обращение содержит домен, пример исходного и конечного URL, время ошибки, скриншот либо текст HTTP-заголовков, а также фрагмент настроек. Не публикуйте пароли, ключи доступа и персональные данные клиентов. Для диагностики обычно достаточно технической информации о маршруте и коде ответа.

Контроль индексации и аналитики

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

Сравнивайте данные по группам страниц, а не только суммарные показатели. Отдельно анализируйте каталог, блог, услуги, статьи справочного раздела и новостные материалы. Так проще понять, какая часть сайта потеряла видимость и на каком этапе возникла проблема. Если один раздел просел, проверьте его карту URL, правила, ссылки, canonical и содержимое.

Для анализа запросов используйте данные поисковых панелей и системы статистики. Сопоставьте популярные запросы до и после запуска, определите страницы входа и посмотрите, не изменился ли тип трафика. При необходимости обновите Title, Description, заголовки и текст новой страницы, но не меняйте всё одновременно. Сначала убедитесь, что техническая переадресация выполнена без ошибок.

Переадресацию следует контролировать не один день. В первые часы проверяют доступность и коды. Через неделю анализируют 404, цепочки и первые результаты обхода. Через месяц сравнивают позиции, показы, переходы и конверсии. Такой график помогает своевременно убрать неактуальные правила, исправить ошибочные маршруты и сохранить стабильность.

Практический чек-лист перед завершением работ

• Сделать резервную копию файлов, базы данных и конфигурации.
• Сделать выгрузку старых URL из аналитики, логов и поисковых панелей.
• Настроить постоянные правила для всех приоритетных адресов.
• Проверить, как сервер обрабатывает HTTP, HTTPS и альтернативные варианты адреса.
• Убрать из меню, шаблонов и публикаций ссылки на старые URL.
• Убрать из XML-карты адреса с кодами 301, 302, 404 и 500.
• Убрать дубли canonical, метатегов и страниц пагинации.
• Убрать тестовые каталоги, служебные страницы и открытые копии проекта.
• Убрать переходы, которые ведут на нерелевантный материал.
• Убрать лишние правила, если они создают второй или третий переход.
• Убрать устаревшие записи в настройках CMS после подтверждения корректной работы.
• Убрать ссылки на старое имя домена в письмах, документах и рекламных объявлениях.

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