Редиректы, 404 и инструменты разработчика
Финальный урок: как переезжать без потери позиций, правильно отдавать 404 и какими инструментами всё проверять.
301 (Moved Permanently) — постоянный редирект: «страница навсегда переехала», передаёт накопленные сигналы. 302 (Found) — временный: «пока смотри здесь», сигналы остаются на старом URL.
301 vs 302 — выбирайте осознанно
Это главная развилка при переездах. При смене URL, объединении страниц, переезде на HTTPS — нужен 301: он говорит поисковику «обнови индекс на новый адрес» и переносит вес. 302 — только для реально временных ситуаций (A/B-тест, временная заглушка), иначе старый URL так и останется в индексе.
| Ситуация | Код |
| Сменили URL страницы навсегда | 301 |
| Переехали на HTTPS / новый домен | 301 |
| Объединили две страницы в одну | 301 |
| Временная заглушка / A-B тест | 302 |
| Страница удалена навсегда | 404 или 410 |
Миграция без потери позиций
При переезде сайта или смене структуры URL ключевое — карта соответствия «старый URL → новый URL» и 301 по ней:
# Nginx: точечные 301 при смене структуры
location = /old-blog/seo-tips {
return 301 /tutorials/seo;
}
Правила миграции: 301 напрямую на финальный URL (без цепочек A→B→C), редирект на релевантную страницу (а не всё на главную), обновлённый sitemap с новыми URL, контроль в Search Console.
404 и 410: как удалять страницы
Удалили страницу — отдавайте честный 404 (не найдено) или 410 (удалено навсегда), а НЕ 200 с пустой страницей (soft 404) и не 301 всего подряд на главную. Страница 404 для пользователя должна быть полезной (поиск, ссылки), но сервер обязан вернуть именно код 404.
Инструменты разработчика
- Google Search Console — главный пульт: статус индексации, ошибки, отчёт Core Web Vitals, проверка конкретного URL (что увидел бот), отправка sitemap.
- Яндекс.Вебмастер — то же для Яндекса.
- Lighthouse — аудит производительности, SEO-чеклист, доступность (в DevTools или CLI).
- Rich Results Test — проверка валидности структурированных данных и предпросмотр rich result.
- Schema Markup Validator — детальная проверка JSON-LD.
Как работает под капотом: классификация кодов
def explain(status):
table = {
200: "OK — рабочая страница, индексируется",
301: "Постоянный редирект — передаёт вес на новый URL",
302: "Временный редирект — вес остаётся на старом URL",
404: "Не найдено — можно убрать из индекса",
410: "Удалено навсегда — сигнал убрать быстрее, чем 404",
500: "Ошибка сервера — бот придёт позже, плохо при массовости",
}
return table.get(status, "неизвестный код")
for code in [200, 301, 302, 404, 410, 500]:
print(code, "->", explain(code))
Вывод:
200 -> OK — рабочая страница, индексируется 301 -> Постоянный редирект — передаёт вес на новый URL 302 -> Временный редирект — вес остаётся на старом URL 404 -> Не найдено — можно убрать из индекса 410 -> Удалено навсегда — сигнал убрать быстрее, чем 404 500 -> Ошибка сервера — бот придёт позже, плохо при массовости
Топ технических ошибок, убивающих SEO
Disallow: /или массовыйnoindex, случайно уехавший со стейджинга на прод.- 302 вместо 301 при постоянном переезде — позиции не переносятся.
- Цепочки редиректов и редирект всего на главную.
- Soft 404 (код 200 на несуществующем).
- Контент только в JS без SSR; мета-теги и canonical на клиенте.
- Дубли без canonical; canonical всех страниц на главную.
Итог
- Постоянный переезд —
301(переносит вес), временный —302; удаление — честный404/410. - Мигрируйте по карте «старый→новый» без цепочек, на релевантные страницы, с обновлённым sitemap.
- Проверяйте всё через Search Console, Lighthouse и Rich Results Test; берегитесь случайного noindex/Disallow с прода.