From f6bd5c58614d79b4cba2f8032394240f95a28c1a Mon Sep 17 00:00:00 2001 From: erjemin Date: Mon, 3 Aug 2026 07:09:33 +0300 Subject: [PATCH] =?UTF-8?q?mod:=20=D0=B4=D0=BE=D0=BA=D0=B8=20=D0=BF=D0=BE?= =?UTF-8?q?=20=D1=80=D0=BE=D1=83=D1=82=D0=B8=D0=BD=D0=B3=D1=83=20(=D0=B4?= =?UTF-8?q?=D1=80=D0=B0=D1=84=D1=82=201)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- _prj_blueprint/ROUTING.md | 33 ++++++++++++++++++++++----------- 1 file changed, 22 insertions(+), 11 deletions(-) diff --git a/_prj_blueprint/ROUTING.md b/_prj_blueprint/ROUTING.md index 867ea10..bea77c3 100644 --- a/_prj_blueprint/ROUTING.md +++ b/_prj_blueprint/ROUTING.md @@ -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('/', 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 для специализированных разделов -- Если страница найдена по общему роуту `//`, но её `l_article_type` указывает на строго профильный раздел (например, `l_article_type == 'blog'` или `l_article_type == 'item'`), и у этой сущности есть свой канонический префиксный путь (например, `/blog//` или `/item//`): - - Сервер выполняет **HTTP 301 Permanent Redirect** с общего пути `//` на канонический адрес `/blog//`. +### 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-оптимизация и Канонические редиректы для Профильных Разделов +- Если страница найдена по общему роуту `//`, но её `l_article_type` указывает на строго профильный раздел (например, `l_article_type == 'blog'`, `'read'` или `'item'`), и у этой сущности есть свой канонический префиксный путь (например, `/read//` или `/item//`): + - Сервер выполняет **HTTP 301 Permanent Redirect** с общего пути `//` на канонический адрес `/read//`. - **Зачем это нужно:** - Исключает появление дублей страниц в индексе поисковых систем (Яндекс / Google). - Чётко разграничивает контентные материалы (новости, статьи) и торговые предложения/хабы.