Мы не просто сделали сайт: как сайт помог собрать экосистему DETai

Этот пост о том, как создавался наш сайт. О технических и, наверное, отчасти психологических аспектах этого процесса.

Хотя теперь, когда прошло уже достаточно времени, становится понятно, что формулировка «создавался сайт» не совсем точная.

Мы действительно начинали именно с него. Хотели сделать современный сайт DETai: красивый, быстрый, многоязычный, понятный человеку и достаточно хорошо устроенный технически, чтобы потом не приходилось каждые несколько месяцев переделывать всё с самого начала. Казалось бы, задача вполне определённа, но чем дальше мы продвигались в работе над сайтом, тем больше вопросов возникало уже не о сайте.

Что именно относится к DET, а что — к DETai? Где заканчивается направление и начинается продукт? Какие части экосистемы должны иметь собственные страницы? Как связаны исследования, образование, психотерапия, продукты и технологическая платформа? Что является публичной информацией, а что должно оставаться внутри? Какие юридические документы нужны разным поверхностям? Кто владеет данными? Где находится канонический источник определения, а где — его публичная интерпретация? А потом добавились локализации, SEO, GEO, происхождение изображений, даты создания и изменения страниц, идентичности людей и организаций, связи между сущностями и structured data — тот самый почти невидимый слой, который помогает поисковым системам понимать, что именно находится перед ними.

Кто здесь человек, а что — организация. Что является публикацией, что — продуктом, а что — проектом. Когда появилась страница и когда она действительно изменилась. Откуда взялось изображение. Как один объект связан с другим. Для обычного посетителя почти ничего из этого не существует: он открывает страницу и видит текст, изображения, кнопки, а под ней постепенно вырастает второй сайт — тот, который предназначен уже не столько для глаз, сколько для машинного понимания. И где-то примерно на третьем дне очередного такого погружения у меня возник вполне закономерный вопрос: а что, если через полгода половина всего этого станет не нужна? Или даже через две недели.

Google изменит рекомендации, AI-поиск научится понимать сайты каким-нибудь другим способом, Schema.org потеряет часть нынешнего значения, появится новый стандарт, изменится framework, на котором всё работает.

В цифровой среде то, что вчера считалось best practice, завтра вполне может превратиться в историческую справку. Получается, несколько дней можно было просто выбросить? Этот вопрос особенно забавен, если вспомнить, с чего вообще начиналась вся история. Потому что мы собирались просто сделать сайт.

Когда сайт ещё был просто сайтом

В какой-то момент WordPress действительно был почти божеством.

Это сейчас звучит немного иронично, а тогда всё было вполне серьёзно. WordPress позволял человеку без команды разработчиков собрать настоящий сайт, поставить тему, подключить плагины, сделать блог, формы, аналитику, а затем открыть Elementor и внезапно почувствовать себя почти веб-дизайнером.

Для своего времени это была невероятно сильная модель: ты не проектировал отдельный frontend и backend, не думал об инфраструктуре как о наборе взаимодействующих систем — ты собирал сайт. Если нужна новая возможность, почти наверняка существовал плагин; если хотелось поменять внешний вид, была тема или visual builder.

Мы долго жили примерно в этой картине мира, пока постепенно не изменился сам вопрос, который приходится задавать в начале работы.

Раньше он звучал так: «Какой сайт мы хотим собрать?» А сегодня всё чаще приходится спрашивать: «Какую систему мы хотим построить — и какой её частью будет сайт?»

Современная веб-разработка стала компонентной, GitHub превратился в рабочий центр разработки, Next.js позволил соединять свойства обычного сайта и приложения, а Vercel сделал deployment почти естественным продолжением изменения кода. Но настоящий перелом для нас произошёл тогда, когда в этот контур вошёл AI. Раньше граница была довольно понятной: либо ты умеешь программировать сам, либо работаешь внутри тех возможностей, которые для тебя предусмотрели программисты.

С AI эта граница стала заметно менее жёсткой. Это вовсе не означает, что программирование исчезло или внезапно перестало требовать профессиональных знаний. Скорее стало возможно участвовать в инженерной работе на другом уровне: обсуждать структуру данных, ownership, границы систем, интерфейсы между ними, канонические источники конкретных объектов и последствия архитектурных решений, не обязательно при этом собственными руками писать каждую функцию. Постепенно работа стала выглядеть примерно так: эти данные нельзя дублировать; языковые версии должны быть самостоятельными представлениями одного смысла; этот слой принадлежит сайту, этот — Storytelling, а этот — Knowledge Substrate; здесь нужен provider, здесь consumer, а между ними — устойчивый контракт. И вот тут всё окончательно пошло не по первоначальному плану. Потому что план был очень простой: ещё недели две — и сайт будет готов.

Сейчас эта фраза уже выглядит почти как исторический анекдот 🙂

Почему мы вообще так долго с ним возились

В какой-то момент пришлось задать ещё один вопрос, и он оказался гораздо важнее технических: почему мы не можем просто остановиться?

Почему нельзя взять уже красивую главную страницу, несколько разделов, нормальную мобильную версию, подключить аналитику — и сказать: всё, сайт существует? Наверное, потому, что постепенно мы начали воспринимать его совсем иначе. Конечно, никакой конкретный сайт не существует «навсегда». Изменится дизайн. Перепишется код. Какие-то страницы исчезнут. Какие-то технологии, которые сегодня кажутся современными, через несколько лет будут выглядеть примерно так же, как сейчас выглядит старая админка WordPress с сорока семью плагинами, из которых никто уже не помнит назначение последних двенадцати. Но роль сайта гораздо долговечнее его текущей реализации.

У DETai может измениться технологический стек, появятся новые продукты, люди, исследования и форматы работы, но место, через которое экосистема представляет себя внешнему миру, скорее всего, останется с ней очень надолго.

Сайт — это одна из главных публичных репрезентаций всей системы.

И если смотреть на него таким образом, задача неожиданно меняется. Уже не нужно пытаться построить сайт, который никогда не понадобится менять — это невозможно. Нужно построить такую его основу, которая сможет долго меняться вместе с экосистемой, не теряя при этом собственной идентичности.

У Stewart Brand в книге How Buildings Learn: What Happens After They're Built есть удивительно точная для этого мысль:

«Здание — это не то, что ты заканчиваешь. Здание — это то, что ты начинаешь».

Brand писал о зданиях, которые продолжают жить после того момента, когда архитектор считает работу законченной: люди меняют их, перестраивают, приспосабливают под новые обстоятельства, и именно способность выдерживать эти изменения во многом определяет качество первоначальной архитектуры. В какой-то момент я поймал себя на мысли, что с сайтом происходит почти то же самое. Мы не строим страницу, которую однажды торжественно объявим завершённой.

Мы запускаем долгоживущую цифровую конструкцию, внутри которой ещё много раз поменяется практически всё.

Когда сайт заставляет ответить на всё

И здесь произошло, пожалуй, самое неожиданное: сайт начал не просто отображать DETai — он начал заставлять нас определять DETai.

Пока экосистема существует в разговорах, отдельных документах, репозиториях и представлениях людей, многие границы можно долго оставлять немного размытыми. Все примерно понимают, о чём идёт речь. Но попробуйте разложить это по страницам.

Что должно находиться в верхнем меню? Что заслуживает собственной страницы, а что является частью другой сущности? Если на странице написано «продукты DETai», что именно мы называем продуктом? Если существует отдельный раздел исследований — где проходит граница между исследовательской деятельностью, методом и технологической платформой? Если у проекта есть собственные пользовательские данные, относятся ли они к общей экосистеме или принадлежат конкретному продукту? Если человек открывает юридический документ, к какой именно поверхности он относится? Если одна и та же идея существует в Knowledge Substrate, публикации и на сайте — где её каноническое определение, а где адаптация для конкретной аудитории?

В какой-то момент выяснилось, что работа над навигацией сайта почти незаметно превращается в работу над онтологией самой экосистемы. Нужно было буквально решить, из каких объектов она состоит и как эти объекты связаны друг с другом. Поэтому дизайн неожиданно потянул за собой архитектуру, а публичные пользовательские маршруты — юридические документы и правила работы с данными.

А необходимость объяснить всё это человеку простым языком заставляла снова возвращаться к архитектуре и спрашивать: а мы сами действительно понимаем, что здесь построили?

Получился довольно интересный цикл: мы пытались описать экосистему с помощью сайта, а необходимость сделать хороший сайт вынуждала нас всё точнее описывать саму экосистему, и в результате сайт стал чем-то вроде интеграционного теста DETai. Если две части системы невозможно понятно связать на публичной странице — возможно, проблема не в странице. Если невозможно объяснить, чем отличаются две сущности, — возможно, мы сами ещё недостаточно хорошо определили их границы. И если непонятно, кому принадлежат данные или откуда должно приходить определение, — красивый UI эту проблему не решит. И, наверное, именно поэтому несколько месяцев работы над «сайтом» в итоге включили и дизайн, и программирование, и семантику, и SEO, и юридическую архитектуру, и локализации, и работу над самой моделью DETai: одна публичная поверхность неожиданно потребовала, чтобы вся система за ней была достаточно определённой.

Сайт, который перестал быть только сайтом

Сам сайт при этом, конечно, никуда не исчез. Наоборот, постепенно он стал одной из главных публичных поверхностей DETai: через него можно войти в метод, исследования, образование, продукты, команду, события, публикации и документацию. Эта роль сейчас уже отдельно зафиксирована в Knowledge Substrate на странице проекта «Сайт DETai»: сайт — это публичный web-слой экосистемы, который объясняет её устройство, показывает взаимосвязи и ведёт человека к продуктам, знаниям и участию.

Но именно поэтому он всё меньше похож на контейнер, куда мы просто складываем готовый контент. Возьмём обычную публикацию: она может начаться с мысли или голосовой заметки, затем превратиться в текст, пройти редактуру, получить изображения, метаданные, языковые версии и несколько representations для разных каналов — и только после этого оказаться на сайте или в Telegram. Получается, сайт уже не является местом рождения объекта и не владеет всем его жизненным циклом — он становится одной из форм его присутствия.

Поэтому рядом с сайтом постепенно вырос Storytelling — отдельный Publication Core, отвечающий за подготовку и движение публикаций; Knowledge Substrate остаётся пространством для устойчивых определений, архитектурных границ, ownership, policies и версий; отдельные продукты сохраняют собственную логику и данные, а сайт собирает для человека связный публичный образ всей этой конструкции.

И, наверное, именно здесь появляется формулировка, которая мне сейчас нравится больше всего: сайт постепенно превратился в систему присутствия. DETai должна существовать для человека, поисковой машины и AI-агента не как набор случайно связанных URL, а как различимая структура, в которой понятно, что это, зачем это существует и как это связано со всем остальным.

И вот здесь начинается очередная ирония: чем понятнее становится архитектура, тем сильнее видно, сколько в ней ещё можно улучшить.

Проект, у которого нет точки «готово»

У сложных систем есть довольно неприятное свойство: пока их почти нет, они кажутся очень простыми. Когда существует только идея будущего сайта, задача выглядит конечной — сделать страницы и закончить. Потом появляются страницы, и вместе с ними всё новые слои. Состояние «готово» всё время как будто отступает на несколько шагов вперёд.

Можно посмотреть на это как на прекрасный бесконечный проект, который невозможно закончить 😅 А можно однажды заметить другую вещь: возможно, сама идея окончательной готовности была ошибкой.

И тут мы снова возвращаемся к вопросу, с которого всё начиналось: если значительная часть сегодняшней работы всё равно когда-нибудь устареет, то не получается ли, что усилия были потрачены зря?

У меня здесь почему-то возникает очень простая аналогия с тренировками.

Когда человек долго занимается, результат выглядит вполне материальным: мышцы, сила, форма. Но все прекрасно знают, что достаточно надолго прекратить тренировки — и значительная часть этого результата начнёт исчезать. Можно тогда спросить: а зачем вообще были нужны все эти подходы, если их эффект не остаётся навсегда?

Ответ кажется довольно очевидным именно потому, что результат тренировки никогда не исчерпывался мышцами. Вместе с ними формировалась способность выдерживать нагрузку, возвращаться после перерывов, соблюдать режим, делать ещё один подход без особого желания и не зависеть каждый раз от вдохновения. Даже если конкретная форма исчезает, человек, который однажды научился её создавать, уже немного отличается от человека, который пока только собирается начать.

С технологиями, кажется, происходит что-то очень похожее. Можно выбросить конкретный код, заменить framework, переписать deployment, полностью поменять модель данных и однажды вообще перестроить сайт с нуля — но навык разбираться в незнакомой системе, видеть связи, выдерживать сложность и доводить её до работающего состояния не удаляется вместе с repository.

Ещё совсем недавно многие вещи, с которыми сегодня приходится работать почти буднично, находились где-то за пределами привычного языка. Не потому, что существовал хитрый план освоить ещё пять профессий, а потому, что каждый следующий слой проекта требовал понять чуть больше предыдущего. И в какой-то момент происходит довольно забавная инверсия: сначала страшно открыть код и что-нибудь там случайно сломать; потом страшно становится трогать архитектуру; а ещё через какое-то время возникает совершенно обратная ситуация — иногда гораздо страшнее не изменить её, когда уже видишь, что старое решение перестало соответствовать системе.

Наверное, это один из важнейших результатов работы над DETai, которого вообще невозможно увидеть на сайте.

То, чего на сайте не видно

К вечеру того самого третьего дня голова уже совершенно не хотела видеть ни JSON-LD, ни canonical, ни provenance, ни даты, идентификаторы и связи между сущностями. После полного рабочего дня оставалась обычная физическая усталость, и где-то уже по дороге на велосипеде возникло неожиданно спокойное ощущение: сегодня что-то стало лучше.

Не навсегда — и это здесь, наверное, самая важная оговорка.

Постепенно куда-то исчезает сама идея, что смысл работы обязательно должен заключаться в создании чего-то такого, что больше никогда не понадобится менять. Меняется сайт, компания, профессия, тело, технология и сам человек, который всем этим занимается.

Устойчивость, как ни странно, возникает не тогда, когда система перестаёт меняться, а тогда, когда она приобретает способность меняться и при этом не терять себя.

Для DETai это вообще получается довольно естественным парадоксом. Мы строим технологическую экосистему вокруг человеческой практики и одновременно не хотим позволить технологии подменить саму практику; создаём довольно строгие архитектурные границы именно для того, чтобы система могла свободнее развиваться; фиксируем канонические знания в Knowledge Substrate, но оставляем публикациям право быть живым снимком конкретного момента; используем AI, чтобы двигаться быстрее, и одновременно всё сильнее понимаем ценность человеческой ответственности за смысл.

Поэтому история сайта в итоге оказалась, кажется, совсем не столько рассказом о Next.js, Vercel, GitHub, Schema.org или AI. Все эти технологии важны, но каждая из них остаётся инструментом конкретного времени.

Самое интересное произошло на другом уровне.

Мы начинали с желания сделать сайт, а постепенно научились думать о системе. Начинали с отдельных страниц — и пришли к связям между объектами. Начинали с вопроса «что увидит человек?», а теперь параллельно спрашиваем «что поймёт машина?». Пытались представить уже существующую экосистему — а в процессе обнаружили, что сама необходимость её представить заставляет гораздо точнее понять, из чего она вообще состоит.

И поэтому первоначальный вопрос — «а вдруг всё это однажды окажется впустую?» — теперь звучит уже немного иначе.

Конкретный результат действительно может исчезнуть. Код можно переписать, стандарт заменить, технологию забыть, сайт полностью перестроить — и, скорее всего, когда-нибудь именно это с ним и произойдёт. Но если Stewart Brand прав и здание — это не то, что однажды заканчивают, а то, чему однажды дают начало, то, возможно, с цифровыми системами стоит обращаться примерно так же: не пытаться угадать их окончательную форму, а строить так, чтобы они могли пережить собственную первоначальную архитектуру.

И, может быть, именно поэтому в конце очень тяжёлого рабочего дня иногда возникает странное и довольно приятное чувство: сил почти нет, голова устала, завтра всё продолжится — а внутри при этом хорошо.

Потому что есть усталость от бессмысленного движения. А есть совсем другая усталость — та, которая появляется, когда сегодня удалось стать способным на чуть более сложную вещь, чем вчера.

И, пожалуй, именно в такие моменты особенно ясно ощущается одна простая мысль:

жизнь — это когда ты рад, что ты устал.

Источники и материалы

1. Brand, Stewart. How Buildings Learn: What Happens After They're Built. Viking Press, 1994. Книга об архитектуре как системе, продолжающей изменяться после завершения строительства; отсюда приведена цитата «A building is not something you finish. A building is something you start».
   https://www.penguinrandomhouse.com/books/320919/how-buildings-learn-by-stewart-brand/

2. Google Search Central — Introduction to structured data markup in Google Search. О том, как structured data помогает поисковой системе получать явные сведения о значении и типе содержимого страницы.
   https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data

3. Schema.org. Открытый словарь типов, свойств и отношений для структурированных данных в интернете.
   https://schema.org/

4. DETai Knowledge Substrate — «Сайт DETai». Каноническое описание роли сайта как публичного web-слоя экосистемы, его границ и отношений с продуктами, знаниями и Storytelling.
   https://docs.detai-x.com/ru/ecosystem/DETai/Platform_DETai/E2-Brand/sites/

5. DETai Knowledge Substrate — «Storytelling — Publication Core». Каноническое описание публикационного контура DETai и разделения ответственности между подготовкой материала и площадками его доставки.
   https://docs.detai-x.com/ru/ecosystem/STORYTELLING/