Сначала решите, что происходит со старой страницей
Если прежняя услуга окончательно переехала, постоянное направление обычно соответствует намерению. Если временно показывается другой маршрут, решение может быть временным. Объединение двух материалов и удаление предложения — разные ситуации: одинаковый статус не делает любую цель релевантной.
В учебном примере /old-service/ заменена равнозначной /new-service/ на одном вымышленном сайте. Старый URL не нужен как отдельный документ. Перенаправление всех удалённых услуг на главную не воспроизводит этот пример: главная может не отвечать вопросу посетителя.
Небольшой пример 301 в Nginx
В действующем server-блоке Nginx точное правило для одного маршрута может выглядеть так: location = /old-service/ { return 301 /new-service/; }. Оно относится только к указанному пути. Пример предполагает, что новая страница уже существует и корректно обслуживается тем же сайтом.
Это фрагмент для понимания настройки, а не замена конфигурации сервера. Исполнитель сначала проверяет текущие location, прокси и правила CMS на стенде, сохраняет исходную конфигурацию и проверяет синтаксис штатным способом. При неизвестном окружении безопаснее передать задачу администратору, чем вставлять чужой полный конфиг.
Если форма отправляет POST на старый адрес, перенаправление требует отдельного разбора метода и данных. Нельзя автоматически применять образец страницы GET к платёжному, авторизационному или заявочному обработчику. Различие 307/308 и 301/302 в обработке метода учитывают по HTTP-документации.
| Ситуация | Учебное решение | Что проверить |
|---|---|---|
| Услуга окончательно переехала | 301 на равнозначную страницу | Назначение и конечный 200 |
| Временное направление | 302 по согласованной причине | Срок и будущий возврат |
| Два правила подряд | Устранить лишний промежуточный переход | Полную цепочку |
| Форма POST | Отдельное техническое решение | Сохранность метода и данных |
Как проверить редирект через curl
Для заголовков GET используйте curl -sS -D - -o /dev/null https://example.com/old-service/ . Ожидаемый результат примера — статус 301 и Location, ведущий к /new-service/. example.com здесь зарезервирован для примеров; замените его собственным тестовым URL, не запускайте команды настройки по чужому сайту.
Проверка цепочки: curl -sS -L -D - -o /dev/null --max-redirs 5 https://example.com/old-service/ . В выводе должны быть понятны переходы и конечный 200. Код 200 сам по себе недостаточен: отдельно откройте назначение и убедитесь, что там нужная услуга, а не пустая заглушка.
Запрос curl -I использует HEAD. Он удобен, но сервер иногда обрабатывает HEAD иначе, поэтому при расхождении проверьте GET. Не принимайте скриншот адресной строки за полную проверку HTTP-поведения.
После настройки исправьте собственные ссылки
Меню, карточки, sitemap и связанные статьи должны постепенно ссылаться на конечный основной URL, а не постоянно создавать лишний переход. Сохраните перечень исходных адресов и проверьте, нет ли петли A→B→A. Отдельно сравните canonical конечной страницы с назначением переноса.
Затем наблюдайте конкретные страницы в поисковых инструментах и обычной выдаче. Корректный редирект поддерживает переход, но не гарантирует прежние позиции или включение новой страницы в индекс к назначенной дате. При полноценной смене домена используйте отдельный план миграции.
Продолжить: Проверить старый и новый адрес услуги; Программа видимости: состав и условия работы