Если вы поменяли структуру постоянных ссылок, перенесли сайт с одного каталога на другой или убрали часть URL-логики из темы, старые адреса обычно продолжают жить в индексе и в истории ссылок. В результате поисковик видит две версии одной и той же страницы: старую и новую. Canonical помогает, но не решает всё, если старый URL отдаёт 200 OK или ведёт на нерелевантную страницу.
Нормальная схема здесь простая: старый адрес должен либо отдавать 301 на новый, либо, если страницы больше не существует, честно отвечать 404/410. Всё остальное — источник дублей, потери ссылочного веса и мусора в отчётах Search Console.
Когда проблема уже есть
Обычно её замечают не сразу. Сайт открывается, записи на месте, но в поиске всплывают старые адреса, а в логах растёт число запросов к несуществующим путям. Иногда после смены структуры ссылок часть старых URL продолжает открываться через редирект-цепочку: сначала HTTP на HTTPS, потом со старого слага на новый, потом ещё через www/non-www. Это уже лишняя нагрузка и лишний шанс на ошибку.
Что проверить в первую очередь
- отдаёт ли старый URL код ответа 301, 302, 404 или 200;
- нет ли цепочки из нескольких редиректов;
- совпадает ли
rel=canonicalс конечным адресом; - не создаёт ли тема или плагин альтернативные URL для той же записи;
- не остались ли старые ссылки в меню, хлебных крошках, XML-карте сайта и внутренних блоках.
Диагностика: где именно ломается логика URL
Самая частая ошибка — пытаться лечить всё только через robots.txt или canonical. Это не убирает старый адрес из обхода, если он уже известен поисковику и доступен по HTTP. Сначала нужно понять, что реально отдаёт сервер.
curl -I https://example.com/old-post-url/Смотрите на три вещи: статус, Location и количество переходов. Если в ответе сразу 301 на новый адрес — это нормально. Если 200 OK на старом URL, значит страница доступна как отдельная сущность, и поисковик будет считать её дублем. Если 404, но в sitemap она всё ещё есть, это тоже проблема: карта сайта должна отражать только актуальные URL.
Для массовой проверки удобно выгрузить список старых адресов из аналитики, Search Console или серверных логов и прогнать их через простой скрипт. Например, так можно быстро увидеть, какие URL ещё живы:
<?php
$urls = file('old-urls.txt', FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES);
foreach ($urls as $url) {
$headers = @get_headers($url, 1);
if (!$headers) {
echo $url . "\tERROR\n";
continue;
}
$status = $headers[0] ?? '';
$location = $headers['Location'] ?? '';
if (is_array($location)) {
$location = end($location);
}
echo $url . "\t" . $status . "\t" . $location . "\n";
}Пошаговое решение: как закрыть старые адреса без хаоса
1. Составьте карту соответствий старый URL → новый URL
Не пытайтесь писать универсальные редиректы «по шаблону», если структура менялась не один раз. Сначала соберите явную таблицу соответствий. Это особенно важно, если у записей менялись и слаги, и рубрики, и вложенность.
Минимальный рабочий вариант — список в CSV или таблице с двумя колонками: старый адрес и новый адрес. Это позволит избежать редиректов на главную страницу, которые поисковики часто воспринимают как soft 404.
2. Настройте 301 на уровне сервера или через WordPress
Если доступен серверный конфиг, редиректы лучше делать там. Это быстрее и надёжнее, чем через PHP. Но если у вас нет доступа к nginx/apache, можно использовать WordPress-хук template_redirect для точечных правил.
<?php
add_action('template_redirect', function () {
$request_uri = isset($_SERVER['REQUEST_URI']) ? wp_unslash($_SERVER['REQUEST_URI']) : '';
$map = [
'/old-post-url/' => '/new-post-url/',
'/old-category/post-name/' => '/new-category/post-name/',
];
if (isset($map[$request_uri])) {
wp_redirect(home_url($map[$request_uri]), 301);
exit;
}
});Этот вариант подходит только для небольшого числа правил. Если редиректов десятки или сотни, лучше использовать серверный уровень или специализированный плагин с таблицей сопоставлений. Иначе вы быстро упрётесь в поддержку кода и риски конфликтов.
3. Уберите старые URL из sitemap и внутренних ссылок
После редиректов проверьте, что старые адреса не остались в XML-карте сайта, в блоках похожих записей, в архивных страницах и в ручных ссылках внутри контента. Если карта сайта генерируется плагином SEO, обновите её и отправьте на переобход. Если ссылки зашиты в шаблон, поправьте их в теме, а не через CSS или JS-обходы.
4. Для удалённых страниц используйте 404 или 410, а не редирект на главную
Если контент действительно удалён и замены нет, не отправляйте пользователя на главную «для удобства». Для поисковика это выглядит как попытка скрыть отсутствие страницы. Лучше вернуть 404, а для заведомо удалённых и неактуальных материалов — 410 Gone. Это честнее и обычно быстрее вычищается из индекса.
Сравнение подходов: плагин, код или сервер
| Подход | Когда уместен | Плюсы | Минусы |
|---|---|---|---|
| Плагин редиректов | Много правил, нужен интерфейс | Удобно править без разработчика | Дополнительная нагрузка, риск конфликтов |
| Код в теме/мини-плагине | Небольшой набор точечных правил | Контроль и предсказуемость | Нужно сопровождение и тестирование |
| nginx/apache | Стабильные массовые редиректы | Быстро, без PHP-слоя | Нужен доступ к серверу и аккуратная настройка |
Если вам ещё нужно чистить дубли, технические хвосты и мусорные параметры, имеет смысл смотреть в сторону комплексной оптимизации. Например, Clearfy Pro закрывает часть типовых SEO-задач и чистки сайта, но редиректы всё равно лучше проектировать отдельно, а не надеяться на один универсальный переключатель.
Проверка результата после внедрения
После настройки не ограничивайтесь открытием пары страниц в браузере. Проверьте цепочку целиком.
- старый URL отдаёт 301 и ведёт сразу на нужную страницу;
- новый URL открывается с кодом 200;
- canonical на новой странице указывает на саму себя;
- старый адрес не попадает в XML sitemap;
- в Search Console уменьшается число страниц с проблемой «страница с перенаправлением»;
- в логах нет бесконечных повторных запросов к старому пути.
Полезно прогнать проверку через curl -I и через браузерный инспектор сети. Если редиректов несколько подряд, вы увидите это сразу по цепочке Location. Чем короче маршрут, тем лучше.
Частые ошибки и как их исправить
Редирект на главную вместо точного аналога
Это самая вредная практика. Поисковик видит несоответствие между старым и новым контентом и часто трактует его как soft 404. Исправление простое: либо точный 301 на релевантную страницу, либо 404/410, если замены нет.
Старый URL всё ещё отдаёт 200 OK
Так бывает, если в теме остался кастомный шаблон или rewrite-правило. Проверьте, не создаёт ли код отдельный endpoint для старого пути. Иногда виноват плагин, который регистрирует CPT или таксономию с прежним слагом.
Редирект-цепочка из трёх и более шагов
Обычно появляется после нескольких миграций подряд. Решение — свести все старые адреса к конечному URL напрямую, без промежуточных переходов. Это снижает задержку и уменьшает риск потери части сигнала.
Canonical указывает не туда
Если canonical на новой странице остался старым, поисковик может продолжать считать старый URL основным. Проверьте SEO-плагин, шаблон head и любые фильтры, которые меняют canonical вручную.
Что делать, если URL меняются регулярно
Если структура сайта ещё не зафиксирована, не плодите редиректы хаотично. Вынесите правила в отдельный мини-плагин или в конфигурацию сервера, ведите таблицу соответствий и не меняйте слаги без причины. Для редакции и контент-команды полезно договориться о правилах именования заранее: один формат для рубрик, один для записей, один для архивов.
И ещё один практический момент: после крупных изменений не полагайтесь только на визуальную проверку. Сверяйте серверные ответы, sitemap и данные в Search Console. Именно там быстрее всего видно, что старые URL ещё не закрыты или закрыты неправильно.
