mod: доки по роутингу (драфт 1)
This commit is contained in:
+22
-11
@@ -1,6 +1,6 @@
|
||||
# Архитектурные решения: Роутинг, SEO-редиректы
|
||||
# Архитектурные решения: Роутинг, SEO-редиректы и Обработка Ошибок
|
||||
|
||||
**Дата и время создания:** 02.08.2026 23:45
|
||||
**Дата и время обновления:** 03.08.2026 00:39
|
||||
**Проект:** LPON.RU (Django 6.0+, Python 3.12)
|
||||
**Статус:** Согласованная архитектура
|
||||
|
||||
@@ -15,17 +15,28 @@
|
||||
path('<slug:slug>/', views.UniversalSlugView.as_view(), name='universal_slug')
|
||||
```
|
||||
|
||||
### 1.2. Безопасная обработка отсутствующих слагов (HTTP 200 Заглушка)
|
||||
- **Проблема 404:** Если в шапке/подвале/каталоге есть ссылка на раздел (например, `/vinyl/`), но в базе данных соответствующая статья `TbArticle` со слагом `vinyl` ещё не создана, отдавать честную 404-ошибку вредно для SEO (поисковики штрафуют за битые ссылки с главных страниц).
|
||||
### 1.2. Обработка отсутствующих слагов: Настоящий HTTP 404 + Подсказка для Админа
|
||||
- **Проблема Soft 404:** Возврат статуса `200 OK` для несуществующих слагов с заглушкой ("Страница наполняется") вреден для SEO (поисковики индексируют Soft 404 и пессимизируют сайт).
|
||||
- **Решение:**
|
||||
1. Диспетчер ищет `slug` в `TbArticle` (и смежных справочниках).
|
||||
2. Если статья со слагом не найдена — вместо ответа `404 Not Found` возвращается **HTTP 200 OK** со специальным шаблоном-заглушкой (`hub_placeholder.html`).
|
||||
3. Для обычного пользователя отображается аккуратная витрина: *"Раздел находится в процессе наполнения"*.
|
||||
4. Для авторизованного администратора (`request.user.is_staff`) выводится специальное информационное сообщение: *"Настрой, дубинушка, вот такой слаг (`slug`) в админке, и всё починится!"*.
|
||||
1. Диспетчер ищет `slug` в `TbArticle`.
|
||||
2. Если статья со слагом не найдена ни в основных слагах, ни в истории переименований — сервер **ОБЯЗАТЕЛЬНО возвращает честный статус `HTTP 404 Not Found`**.
|
||||
3. Для обычного пользователя рендерится аккуратная страница ошибки 404 ("Страница не найдена").
|
||||
4. Для авторизованного администратора (`request.user.is_staff`) на той же странице 404 выводится специальный информационный блок-подсказка:
|
||||
> *"Вы вошли как администратор. По адресу `/cassettes/` не найдена статья. Создайте в админке `TbArticle` со слагом `cassettes` (тип HUB), и страница оживёт!"*
|
||||
|
||||
### 1.3. SEO-оптимизация и 301 Permanent Redirects для специализированных разделов
|
||||
- Если страница найдена по общему роуту `/<slug>/`, но её `l_article_type` указывает на строго профильный раздел (например, `l_article_type == 'blog'` или `l_article_type == 'item'`), и у этой сущности есть свой канонический префиксный путь (например, `/blog/<slug>/` или `/item/<slug>/`):
|
||||
- Сервер выполняет **HTTP 301 Permanent Redirect** с общего пути `/<slug>/` на канонический адрес `/blog/<slug>/`.
|
||||
### 1.3. Переименование слагов и История Алиасов (HTTP 301 Permanent Redirect)
|
||||
|
||||
Возможно овер-кил.
|
||||
|
||||
- **Проблема смены слагов:** Если администратор переименует слаг статьи (например, с `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/`).
|
||||
|
||||
### 1.4. SEO-оптимизация и Канонические редиректы для Профильных Разделов
|
||||
- Если страница найдена по общему роуту `/<slug>/`, но её `l_article_type` указывает на строго профильный раздел (например, `l_article_type == 'blog'`, `'read'` или `'item'`), и у этой сущности есть свой канонический префиксный путь (например, `/read/<slug>/` или `/item/<slug>/`):
|
||||
- Сервер выполняет **HTTP 301 Permanent Redirect** с общего пути `/<slug>/` на канонический адрес `/read/<slug>/`.
|
||||
- **Зачем это нужно:**
|
||||
- Исключает появление дублей страниц в индексе поисковых систем (Яндекс / Google).
|
||||
- Чётко разграничивает контентные материалы (новости, статьи) и торговые предложения/хабы.
|
||||
|
||||
Reference in New Issue
Block a user