Архитектурные решения: Роутинг, SEO-редиректы и Обработка Ошибок

Дата и время обновления: 03.08.2026 00:39
Проект: LPON.RU (Django 6.0+, Python 3.12)
Статус: Согласованная архитектура

1. Стратегия Роутинга и SEO

Отказываемся от искусственных служебных префиксов в URL (например, /hub/<slug>/). Все статьи, хабы, музыкальные стили и категории живут на первом уровне: lpon.ru/vinyl/, lpon.ru/cassettes/, lpon.ru/about/.
В urls.py в самом конце списка роутов устанавливается универсальный Catch-All роут:
```
path('<slug:slug>/', views.UniversalSlugView.as_view(), name='universal_slug')
```

Проблема Soft 404: Возврат статуса 200 OK для несуществующих слагов с заглушкой ("Страница наполняется") вреден для SEO (поисковики индексируют Soft 404 и пессимизируют сайт).
Решение:
1. Диспетчер ищет slug в TbArticle.
2. Если статья со слагом не найдена ни в основных слагах, ни в истории переименований — сервер ОБЯЗАТЕЛЬНО возвращает честный статус HTTP 404 Not Found.
3. Для обычного пользователя рендерится аккуратная страница ошибки 404 ("Страница не найдена").
4. Для авторизованного администратора (request.user.is_staff) на той же странице 404 выводится специальный информационный блок-подсказка:
  
  "Вы вошли как администратор. По адресу /cassettes/ не найдена статья. Создайте в админке TbArticle со слагом cassettes (тип HUB), и страница оживёт!"

Возможно овер-кил.

Проблема смены слагов: Если администратор переименует слаг статьи (например, с cassettes на audio-cassettes), старые внешние ссылки и поисковые индексы выдадут 404.
Решение (История слагов):
1. В TbArticle ведётся список прошлых слагов (например, в JSON-метаданных j_article_metadata['old_slugs'] или отдельной таблице алиасов).
2. Если запрошенный slug не найден в основном поле s_article_slug, диспетчер проверяет его наличие в истории old_slugs.
3. Если слаг найден в истории — сервер мгновенно возвращает HTTP 301 Permanent Redirect на актуальный канонический URL статьи (/audio-cassettes/).

Если страница найдена по общему роуту /<slug>/, но её l_article_type указывает на строго профильный раздел (например, l_article_type == 'blog', 'read' или 'item'), и у этой сущности есть свой канонический префиксный путь (например, /read/<slug>/ или /item/<slug>/):
- Сервер выполняет HTTP 301 Permanent Redirect с общего пути /<slug>/ на канонический адрес /read/<slug>/.
Зачем это нужно:
- Исключает появление дублей страниц в индексе поисковых систем (Яндекс / Google).
- Чётко разграничивает контентные материалы (новости, статьи) и торговые предложения/хабы.