diff --git a/hypn0/hypn0/settings.py b/hypn0/hypn0/settings.py
index c5bf902..89035b3 100644
--- a/hypn0/hypn0/settings.py
+++ b/hypn0/hypn0/settings.py
@@ -95,6 +95,7 @@ TEMPLATES = [
                 'django.template.context_processors.request',
                 'django.contrib.auth.context_processors.auth',
                 'django.contrib.messages.context_processors.messages',
+                'hypn0_site.context_processors.site_context',
             ],
         },
     },
diff --git a/hypn0/hypn0_site/context_processors.py b/hypn0/hypn0_site/context_processors.py
new file mode 100644
index 0000000..bb26a24
--- /dev/null
+++ b/hypn0/hypn0_site/context_processors.py
@@ -0,0 +1,58 @@
+from django.conf import settings
+from django.http import HttpRequest
+
+# Имя куки, которая ставится клиенту, когда он СОГЛАСИЛСЯ на отслеживание
+# (Google Tag Manager, Яндекс.Метрика и т.п.). Если кука присутствует —
+# предупреждение о трекинге больше не показываем.
+ALLOW_TRACKING_COOKIE_NAME = "allow_tracking"
+
+
+def site_context(request: HttpRequest) -> dict:
+    """
+    Общий (универсальный) контекст-процессор Django для всего проекта.
+
+    ЗАЧЕМ ЭТО НУЖНО:
+        Автоматически добавляет во ВСЕ шаблоны проекта переменные, которые
+        нужны почти на каждой странице, без необходимости передавать их
+        вручную в контексте каждой вьюхи. Контекст-процессор необходимо
+        зарегистрировать в settings.py: TEMPLATES['OPTIONS']['context_processors']
+
+    ПОЧЕМУ ОДИН УНИВЕРСАЛЬНЫЙ ПРОЦЕССОР, А НЕ НЕСКОЛЬКО РАЗНЫХ:
+        И DEBUG-флаг, и флаг согласия на трекинг — это одинаковые по сути
+        "сквозные" данные: маленькие, не завязанные на конкретную вьюху,
+        нужные почти во всех шаблонах (в _base.html). Заводить под каждую
+        такую мелочь отдельный контекст-процессор — это лишний файл и лишняя
+        строка регистрации в settings.py на ровном месте. Если в будущем
+        появится много разнородных "сквозных" переменных — тогда, возможно,
+        стоит разнести их по смыслу (например, отдельно cookies-consent,
+        отдельно debug/env), но пока их всего две — держим вместе.
+
+    ПОЧЕМУ НЕ штатный django.template.context_processors.debug (для IS_DEBUG):
+        Штатный context-processor отдаёт переменную `debug` только если
+        ОДНОВРЕМЕННО: settings.DEBUG == True И IP клиента входит в
+        settings.INTERNAL_IPS (сверяется по request.META['REMOTE_ADDR']).
+        В проекте с Docker/reverse-proxy — REMOTE_ADDR может быть не 127.0.0.1,
+        а IP шлюза docker-сети, и потому штатный контекстный-процессор ненадёжен.
+
+    ПРО ALLOW_TRACKING:
+        Читаем куку request.COOKIES.get(ALLOW_TRACKING_COOKIE_NAME) — её
+        ставит клиентский JS (или сервер) ПОСЛЕ того, как пользователь
+        согласился с предупреждением об отслеживании (Google Tag Manager,
+        Яндекс.Метрика и т.п.). Если кука присутствует (независимо от её
+        значения — само наличие куки уже означает согласие) — предупреждение
+        в шаблоне больше не показываем, а также можно подключать сами
+        счётчики трекинга ({% if ALLOW_TRACKING %}...{% endif %}).
+
+    :return
+        dict: словарь с ключами:
+            IS_DEBUG (bool) — режим отладки Django (settings.DEBUG);
+            ALLOW_TRACKING (bool) — согласился ли клиент на отслеживание
+                (определяется по наличию куки "allow_tracking").
+        Обе переменные доступны во всех шаблонах:
+              {% if IS_DEBUG %}...{% endif %}
+              {% if ALLOW_TRACKING %}...{% endif %}
+    """
+    return {
+        "IS_DEBUG": settings.DEBUG,
+        "ALLOW_TRACKING": ALLOW_TRACKING_COOKIE_NAME in request.COOKIES,
+    }