#Что происходит и когда применима инструкция
Старый URL возвращает постоянный 301, но ведёт на несуществующий путь нового сайта. Пользователи или поисковые роботы проходят редирект и получают 404. Устранение требует карты соответствий старых и новых адресов, а не пересылки всех запросов на главную.
#Причины: как различить похожие случаи
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Путь не существует на новом сайтеМеханическое перенаправление сохраняет старый путь, а в новой CMS он изменился. | Location указывает на страницу, которая отвечает 404. | Создать таблицу старый URL → соответствующий рабочий новый URL. |
| Правило теряет часть пути или запросаВ rewrite/return неправильно собирается URL, теряется каталог или необходимый параметр. | Только отдельные URL с вложениями/аргументами превращаются в неверные. | Исправить выражение и проверить несколько разных адресов. |
| Несколько промежуточных перенаправленийВеб-сервер, CDN и CMS каждый по-своему перенаправляют страницы. | curl -L показывает цепочку Location, ведущую на неверный финал. | Убрать лишние переходы, оставить короткий путь к целевой странице. |
#Диагностика и пошаговое устранение
- 1. Соберите реальные адреса, возвращающие ошибкуОткройте журналы старого домена или отчёт поисковой системы об ошибках обхода. Запишите несколько точных старых URL: главную, страницу статьи, раздел, адрес с параметром и заведомо удалённую страницу. Не делайте вывод только по главной странице: она может работать, а внутренние — возвращать 404. Убедитесь, что ошибка относится к нужному имени хоста и протоколу.
- 2. Посмотрите цепочку HTTP-ответовВ терминале Linux/macOS/Windows с curl выполните запрос к конкретному старому URL.
-Iпоказывает заголовки,-Lследует редиректам,-vраскрывает промежуточные переходы. Запишите исходный код 301, каждый Location и окончательный код. Для некоторых сайтов HEAD может отвечать не так, как GET; при сомнениях повторите обычный GET без-I.Linux · Терминал (Bash)КомандаЗамените пример реальным старым URL. Если HEAD обрабатывается иначе, проверьте GET.curl -IL --max-redirs 10 https://old.example.com/article/
- 3. Сопоставьте старые и новые страницы по содержаниюВ таблице для каждого старого URL укажите соответствующий новый URL. Проверьте новый адрес обычным браузером и
curlбез перехода со старого сайта: целевая страница должна отдавать 200 с нужным содержимым. Если страница действительно удалена и близкой замены нет, нормальный 404 или 410 может быть корректнее отправки пользователя на главную.
- 4. Проверьте, на каком уровне создаётся 301Если сервер Nginx, администратор по SSH выполнит
sudo nginx -Tи найдёт правилаreturn 301,rewrite, а также proxy_pass. Если перенаправления делает CMS или CDN, изучите их правила в панели. Зафиксируйте порядок правил: конкретные страницы должны обрабатываться до общего переноса, когда он основан на неизменных путях. Не редактируйте одновременно правила на всех уровнях без плана.Linux · Терминал (Bash)КомандаНужен sudoЧитает конфигурацию Nginx; сохраните её в защищённом месте, возможны секреты.sudo nginx -T
- 5. Сохраните конфигурацию и исправьте ошибочное соответствиеСкопируйте файл настроек или экспортируйте правила панели. Для страницы, сменившей путь, добавьте отдельное постоянное перенаправление к существующему релевантному URL, а общее правило оставьте для путей, которые действительно сохранились. Не используйте одиночный 301 всех старых страниц на новую главную: для роботов это может выглядеть как soft 404. Протестируйте перенаправления на подготовленном наборе адресов.
- 6. Проверьте синтаксис и примените изменениеДля Nginx выполните
sudo nginx -t; только при успехе —sudo systemctl reload nginx. Если тест неудачен, восстановите прежнюю копию правил и снова проверьте. Для Apache или панели управления используйте аналогичный штатный тест и безопасное применение; не пытайтесь перезапустить несуществующую на сервере службу.Linux · Терминал (Bash)С осторожностьюНужен sudoВторая строка только после успешного теста, для Nginx под systemd. Команда перезагрузки выполняется только при успешной проверке конфигурации (оператор &&). При ошибке исправьте конфигурацию и повторите проверку; не запускайте перезагрузку вручную.sudo nginx -t && sudo systemctl reload nginxКоманда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
- 7. Проверьте не только одну страницуПовторите запросы HEAD или GET для каждого адреса из таблицы. Корректная цепочка обычно: старый URL отвечает 301 или 308 с финальным Location на новый URL, а тот отвечает 200 либо намеренно 404/410 для действительно удалённого содержимого. Отдельно проверьте HTTP→HTTPS, www↔без www, параметры и файлы; не допускайте циклических редиректов.
- 8. Обновите внутренние ссылки и наблюдайте обходПосле исправления карты переноса обновите ссылки и canonical на новом сайте, карту сайта и данные в панели поисковой системы. Следите за журналами старого и нового сайтов и отчётами обхода: роботы могут возвращаться к старым адресам не сразу. Если 404 сохраняются только у одного робота, сравните ответ для его настоящего запроса и обычного клиента, не отдавайте ложный 200 специально для него.
#Как проверить, что неисправность устранена
В конечной точке реального 301 теперь возвращается ожидаемая страница, внутренние URL не ведут в произвольный 404, в журнале нет новых массовых ошибок переноса. Отсутствие мгновенного обновления индекса поиска не означает, что исправление не сработало.
#Если не получилось и как отменить правки
Восстановите экспорт правил или конфигурацию из резервной копии, проверьте синтаксис и примените. Если новое правило ошибочно, удалите только его и верните старое соответствие. Не отменяйте весь корректный перенос из-за отдельной неисправной страницы.
Если причина не установлена, соберите точный текст ошибки, время, имя домена, результаты проверок без паролей и приватных ключей. Передайте их ответственному администратору или поддержке регистратора, DNS-провайдера либо хостинга. Не повторяйте опасные изменения без резервной копии.