301, 302 и canonical: когда какой использовать

Три инструмента — три задачи

Выбор неправильного инструмента стоит SEO-позиций.

301 redirect — постоянный переезд

HTTP-ответ: 301 Moved Permanently

Используется, когда:

• Страница навсегда переехала на новый URL
• Старый домен → новый домен
• HTTP → HTTPS
• www → не-www (или наоборот)
• Реструктуризация URL
• Удалённая страница, контент перенесён на похожую

Что делает:

• Старый URL выпадает из индекса
• Новый URL наследует позиции
• 90-99% ссылочного веса передаётся
• Браузеры кешируют редирект (запоминают)

Пример настройки nginx:

location /old-url/ {
  return 301 https://example.com/new-url/;
}

Пример для домена:

server {
  listen 80;
  server_name old-domain.com;
  return 301 https://new-domain.com$request_uri;
}

302 redirect — временный переезд

HTTP-ответ: 302 Found или 307 Temporary Redirect

Используется, когда:

• Страница временно недоступна (техобслуживание, A/B тест)
• Сезонное перенаправление
• Геолокационный редирект (показать русскую версию русским)
• Временный landing для маркетинговой кампании

Что делает:

• Старый URL остаётся в индексе
• Ссылочный вес не передаётся (или минимально)
• Браузеры не кешируют

Главное правило: 302 — только если редирект действительно временный. Если постоянный — используйте 301, иначе позиции теряются.

Canonical — мягкая «каноничность»

<link rel="canonical" href="https://example.com/main-version/" />

Используется, когда:

• Есть дубли с похожим контентом, нужно указать главную
• Параметры фильтров создают разные URL с тем же контентом
• AMP-страница → canonical на обычную
• Категория с разными вариантами сортировки

Что делает:

• Обе версии остаются доступны пользователю
• Поисковик индексирует только каноническую
• Ссылочный вес частично передаётся к канонической

Важное отличие от 301: при canonical обе версии работают, пользователь может зайти на любую. При 301 — только новая.

Дерево решений

Страница навсегда переехала на новый URL?
├─ Да → 301
└─ Нет
    Страница временно недоступна?
    ├─ Да → 302
    └─ Нет
        Есть дубли с похожим контентом?
        ├─ Да → canonical
        └─ Нет → ничего не делать

Типичные сценарии

Сценарий 1: HTTP → HTTPS

# server для http
server {
  listen 80;
  server_name example.com;
  return 301 https://example.com$request_uri;
}

301, потому что HTTPS навсегда.

Сценарий 2: Меняем структуру URL

Было: /products/12345 Стало: /products/macbook-pro-16/

301-редирект со всех старых URL на новые. Через 3-6 месяцев старые URL исчезают из индекса, новые занимают их места.

Сценарий 3: Сезонная категория

«Новогодние подарки» — доступна с октября по январь. Остальное время → 302 на главную каталога.

После Нового года 302 убираем, категория снова доступна.

Сценарий 4: A/B тест

/landing-A → 302 на /landing-A/variant-2 для половины пользователей.

После теста победившая версия → исходный URL. Без 301 — старый URL сохраняет позиции.

Сценарий 5: Фильтры в каталоге

/catalog/?color=red → canonical на /catalog/

Обе версии работают для пользователей, но индексируется только основная.

Сценарий 6: Товар в нескольких категориях

/electronics/laptops/macbook-pro /apple/macbook-pro /best-deals/macbook-pro

Все три ведут на тот же товар → canonical на основной URL (первый).

Анти-паттерны

❌ Цепочки редиректов

/old1 → /old2 → /old3 → /new

При каждом редиректе теряется небольшой процент ссылочного веса. Через 3-4 редиректа — почти ничего не остаётся.

Решение: обновить все промежуточные редиректы напрямую на финальный URL.

❌ 302 для постоянных переездов

Самая частая ошибка. Используют 302 «потому что не знают разницу». Результат: старая страница остаётся в индексе, новая не получает позиций.

❌ Canonical на 404

<link rel="canonical" href="https://example.com/dead-page/" />

Если canonical указывает на 404, поисковик игнорирует разметку. Иногда — игнорирует всю разметку страницы.

❌ Canonical через JavaScript

document.head.appendChild(link);

При первичном обходе Google может не выполнить JS → canonical не виден.

Решение: canonical в серверном HTML.

❌ Циклические canonical

A → canonical на B → canonical на A.

Игнорируется обоими поисковиками.

❌ 301 редирект всех 404 на главную

Иногда DevOps настраивают так, что все 404 редиректят на главную. Это:

• Раздувает индекс «дублями главной»
• Сбивает поисковики с толку
• В конечном итоге Google обнаруживает паттерн и относится скептически

Правильно: для удалённых страниц — настоящий 404 или 410, или 301 на наиболее релевантную страницу.

301 vs 410 для удалённых страниц

410 Gone — «страница удалена навсегда, и не вернётся».

Когда лучше 410 вместо 404:

• Страница точно не вернётся
• Хотите ускорить удаление из индекса
• Нет похожей страницы для 301-редиректа

410 удаляется из индекса быстрее, чем 404. 404 поисковик иногда продолжает обходить «на всякий случай».

Проверка редиректов

1. Через DevTools

F12 → Network → загрузить URL → проверить статус-код.

2. Online tools

• httpstatus.io — проверяет цепочки редиректов
• redirect-checker.org

3. Screaming Frog

Сканирует весь сайт, показывает редиректы и цепочки.

4. curl

curl -I https://example.com/old-url

Видно HTTP-статус и Location.

Чек-лист

• [ ] 301 для постоянных переездов (HTTPS, новый домен, новая URL-структура)
• [ ] 302 только для временных
• [ ] canonical для дублей с одинаковым контентом
• [ ] Нет цепочек редиректов (1 шаг до финала)
• [ ] Canonical в <head> серверного HTML
• [ ] 404 для удалённых, 410 для гарантированно удалённых
• [ ] Не редиректить все 404 на главную
• [ ] Регулярная проверка через Screaming Frog

Итог

301, 302 и canonical — три разных инструмента для трёх разных задач. Перепутать = потерять SEO-позиции. Используйте дерево решений в начале статьи.

Прогнать SEO-аудит с проверкой редиректов →