Здесь я пишу о дизайне, работе с AI, цифровых продуктах, недвижимости и жизни с семьёй в Дубае. Мне нужен сайт, на котором всё это может существовать вместе: статьи, фотографии, рабочие проекты и интерактивные инструменты.

Сначала был Framer

Первый сайт я собрал на Framer. Он до сих пор доступен на nevskii.me и служит моим портфолио продуктового дизайнера.

Позже я завёл отдельный блог на Ghost Pro. Купил тему Scope у Priority Vision и начал её дорабатывать. Работа с темой шла через GitHub и GitHub Actions. Параллельно я писал и накапливал контент, платя за Ghost Pro $35 в месяц.

Постепенно у сайта появились собственный дизайн и история изменений. При следующем переезде всё это хотелось сохранить.

Концептуальная AI-иллюстрация: Framer-портфолио, блог на Ghost с темой Scope и GitHub Actions вокруг автора за ноутбуком.
У сайта тоже есть история версий. Началась она со Framer и Ghost

Почему я перешёл на Astro

В какой-то момент я решил, что проще собрать сайт на Astro. Я портировал дизайн темы и продолжил работать с ним в коде.

Astro собирает страницы из компонентов и позволяет заранее получить готовый HTML. Для блога это подходит: текст статьи, фотографии и навигация могут приходить в браузер уже свёрстанными. Читателю не нужно ждать, пока JavaScript соберёт страницу на его устройстве.

Переезд потребовал перенести шаблоны статей, списки публикаций, галереи, меню, светлую и тёмную темы. У отдельных страниц могут быть разные композиции. Статья с фотографиями и лента заметок не обязаны выглядеть одинаково.

Внешний вид блога по-прежнему основан на Scope, но его шаблоны теперь работают в Astro. Framer остаётся отдельным портфолио и одним из визуальных ориентиров.

Концептуальная AI-иллюстрация: страницы Framer и Ghost преобразуются в компоненты Astro и готовые HTML-страницы.
Внешне тот же блог, внутри уже Astro. Переезд с сохранением мебели

Почему я отказался от CMS

После Ghost я попробовал EmDash: перенёс туда материалы, переводы и черновики, собрал редактор и связал его с Astro. Этот этап помог сохранить общую структуру материалов, но сама работа оказалась сложнее, чем мне нужно.

Меня не устраивало, что небольшая правка могла превращаться в 40–60 минут подготовки и разбирательств. В отдельный редактор мне тоже не хотелось возвращаться: удобнее объяснить задачу в чате Codex, увидеть результат локально и выпустить изменение.

Теперь тексты и код находятся в одном GitHub-репозитории. Материалы лежат в content/, шаблоны и интерфейсы — в apps/site/. EmDash и база CMS больше не участвуют в редактировании и выпуске действующего сайта. Их история и резервные копии сохранены отдельно.

Концептуальная AI-иллюстрация: рабочее пространство EmDash со статьями, переводами, медиатекой и настройками публикации.
Эксперимент с EmDash остался частью истории сайта. Текущий контент уже хранится в репозитории

Как всё связано

У сайта один источник материалов и несколько представлений: обычные страницы, разговор с AI и терминал.

В content/ хранятся русский оригинал, переводы, черновики, связи материалов и сведения об оформлении. Код Astro читает эти файлы напрямую. Изображения и видео по-прежнему доставляются через cdn.nevsky.ae; перенос текстов не меняет их адреса.

Astro получает опубликованные языковые версии и формирует статические страницы. Из тех же материалов готовятся поиск, данные Ask и терминала, Markdown, RSS, карты сайта и файлы для LLM. Черновики в публичную выдачу не попадают.

Готовый пакет обслуживает один Cloudflare Worker — nevsky-web-root. Он раздаёт статические страницы, обрабатывает Ask и защищённый предпросмотр. Чтение обычной статьи не обращается к CMS или редакционной базе данных.

Путь материала выглядит так:

content/ → Astro → статический пакет → Cloudflare Worker → читатель

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

Концептуальная AI-схема архитектуры сайта: EmDash, Cloudflare D1 и R2, сборка Astro, Workers, CDN и страница читателя.
Схема прежнего этапа с CMS. Теперь источником для Astro служат файлы content/

Перед выпуском определяется, какие страницы и производные данные зависят от правки. Нужные страницы собираются заново, остальные HTML, медиа и шрифты переиспользуются из принятого пакета. Автоматического перехода на полную пересборку нет.

Где используется Svelte

Svelte используется в интерактивных интерфейсах главной, разговора с AI и терминала. Здесь можно переключать разделы, искать материалы, задавать вопросы и читать сайт через команды.

Astro позволяет подключать такие компоненты отдельно. Статья остаётся обычной HTML-страницей, а интерактивный блок получает свой JavaScript там, где он нужен. Svelte не загружается на каждую страницу основного блога.

Меню, переключение темы и другие небольшие элементы могут работать на обычном JavaScript. Для них не требуется отдельный компонент Svelte.

Концептуальная AI-иллюстрация: статическая HTML-статья рядом с интерактивными фильтрами и поиском на Svelte.
Не каждой кнопке нужен фреймворк. Svelte оставил там, где есть настоящая интерактивность

Один материал на семи языках

Сайт поддерживает русский, английский, арабский, китайский, французский, немецкий и испанский языки. Русский служит исходным языком материалов.

У каждого материала своя папка. В ней находятся общая структура, сведения о публикации и языковые файлы. У изображений и блоков сохраняются постоянные ID, а заголовки, абзацы, подписи и SEO-поля имеют переводы.

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

У страниц есть ссылки на соответствующие переводы и разметка hreflang для поисковых систем. Арабская версия учитывает письмо справа налево. Переключатель языка ведёт к переводу текущего материала, когда он опубликован.

Концептуальная AI-иллюстрация: общий макет статьи синхронно представлен на русском, английском, арабском, китайском, французском, немецком и испанском.
Семь языков, один документ. Переставлять одну фотографию семь раз я больше не собираюсь

Дизайн и код

В основе оформления остались типографика и структура Scope. Общие цвета, кнопки и другие повторяющиеся элементы описаны в дизайн-системе.

Основной акцентный цвет сейчас #46a758. На сайте используются локальные шрифты Geist и Geist Mono, светлая и тёмная темы, иконки Remix Icon. Стили написаны на обычном CSS.

Палитра и образцы компонентов собраны на публичной странице дизайн-системы. Технические правила и токены описаны в design.md, чтобы новые страницы использовали те же цвета, размеры и состояния кнопок.

Концептуальная AI-иллюстрация: дизайн-система сайта с палитрой, Geist, CSS-токенами, иконками и библиотекой компонентов.
Geist, Remix Icon и мой зелёный #46a758. Наконец-то всё живёт по одним правилам

Технический стек на октябрь 2026

В текущей сборке используются Astro 7.4.1, Svelte 5.57.2 и TypeScript 6.0.3. В зависимостях закреплена интеграция @astrojs/cloudflare 14.4.1. Версии зафиксированы в lockfiles проекта на 22 октября 2026 года.

Astro отвечает за шаблоны и HTML, Svelte — за интерактивные интерфейсы, content/ — за материалы. Cloudflare Worker обслуживает готовую выдачу и серверные функции. Дизайн собран на обычном CSS: переменные, адаптивные сетки, состояния компонентов и несколько повторяемых вариантов вёрстки.

Почему именно такой стек

Большая часть блога известна до запроса читателя: заголовки, тексты, фотографии и списки публикаций можно собрать заранее. Поэтому основной сайт отдаёт готовый HTML из Cloudflare Workers Assets. Для редактирования и сборки текущей версии D1 тоже больше не требуется.

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

Редакционный документ как модель данных

Модель материала сохранила общее дерево блоков, стабильные ID и привязки оформления. Теперь она хранится в файлах репозитория. Структура и медиа общие для языков, текстовые значения разделены по переводам; у языковой версии есть собственный адрес и статус.

При правке важно сохранить ID, порядок блоков, ссылки и связь с переводами. Обновление русского текста не должно незаметно менять структуру материала или публиковать черновик. Проверки перед выпуском следят за этими границами.

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

Работа с материалами из чата

Основной рабочий интерфейс для меня теперь — чат Codex внутри проекта. Я описываю правку, агент находит материал и меняет нужный текст в репозитории. Локальная версия использует те же материалы, шаблоны и интерфейсы, что и выпускаемый сайт.

Для оформления есть несколько Astro-шаблонов: изображение слева или справа, заголовок с вводным текстом и боковой информацией, заголовок над изображением. Более сложную композицию можно сначала проработать во Framer и перенести в код. Новый редактор CMS для этого не нужен.

AI помогает готовить тексты, переводы и код. Русский материал и переводы можно обсудить в ChatGPT, затем передать в Codex для работы с файлами. Подготовку и вычитку текста я отделяю от команды публикации: локальное сохранение само по себе ничего не выпускает.

Концептуальная AI-иллюстрация: редакционный документ, блоки со стабильными ID и проверки плагинов nevsky-multilingual и nevsky-grid.
Плагины были частью эксперимента с CMS. Общая модель блоков и переводов сохранилась в файлах

Как устроены сборка и выпуск

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

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

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

GitHub, локальная работа и Cloudflare

Код, материалы и история изменений находятся в одном GitHub-репозитории. Сначала я работаю с локальной копией сайта. Готовые изменения публикуются напрямую с рабочего компьютера через терминал, без запуска GitHub Actions для каждой правки.

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

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

Концептуальная AI-иллюстрация: GitHub, проверка сборки и Cloudflare в схеме выпуска сайта с ручным подтверждением публикации.
Выпуск идёт через терминал: затронутые страницы, переиспользование готового пакета и сохранённый откат

Техническое SEO как часть сборки

У каждой опубликованной языковой версии есть собственный URL, canonical, lang и ссылки на соответствующие переводы через hreflang. Для языка по умолчанию задаётся x-default. Арабские страницы получают dir="rtl". Заголовки, descriptions, Open Graph и Twitter metadata берутся из того же файлового материала, что и видимый текст.

JSON-LD описывает WebSite и конкретный тип страницы: BlogPosting для статьи, ProfilePage для автора, CollectionPage для подборки и WebPage для обычной страницы. Авторство и даты читаются из данных материала; карты сайта и RSS — из опубликованного каталога. При правке проверяются затронутые адреса и связи, а действительные результаты для неизменных входов переиспользуются.

Контент для LLM

Из опубликованных материалов автоматически формируются Markdown-версии страниц, а также llms.txt и llms-full.txt на семи языках. Короткий файл даёт профиль, языки и ссылки на материалы, полный содержит расширенную текстовую выдачу. У машиночитаемой версии тот же редакционный источник, что у сайта: я не веду отдельную биографию для роботов.

Это даёт AI-инструментам текст с заголовками, ссылками и адресами источников, который удобно читать без разбора интерфейса страницы. При сборке выпуска обновляется весь связанный комплект. Здесь для меня сходятся редакция, SEO и работа с нейронками: материал нужно одинаково аккуратно представить человеку, поисковому роботу и модели.

Концептуальная AI-иллюстрация: статья раздаётся читателю, поисковику и языковой модели через HTML, SEO-метаданные, Markdown и файлы llms.txt.
Человек читает HTML, поисковик разбирает разметку, LLM получает Markdown. Источник у всех один

Доставка медиа и проверка изменений

Медиа обслуживаются отдельно от HTML. Существующие изображения, их варианты и шрифты не нужно заново обрабатывать из-за исправленной фразы. У нового медиа или нового набора символов есть свои зависимости и проверки. Geist, Geist Mono и Remix Icon остаются частью общего оформления сайта.

Проверки зависят от изменения. Для кода нужны проверки его потребителей и рисков поведения. Для текста при неизменном коде переиспользуются действующие результаты; отдельно проверяются область выпуска, новый текст, целостность пакета, аккаунт и текущая production-версия. У аудита зависимостей есть срок действия. После публикации проверяется уже сайт, а не только локальная сборка.

Как я продолжаю работать с сайтом

Я работаю с сайтом из чата Codex: редактирую материалы, меняю компоненты и смотрю результат локально. Style Guide помогает сохранять общее оформление. Framer остаётся инструментом для поиска сложной композиции, а Astro-шаблоны — её рабочей реализацией.

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

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

Что я могу собрать на этой основе

Я могу спроектировать и собрать подобный сайт для автора, студии или бизнеса: перенести материалы из прежней CMS, сохранить адреса, настроить несколько языков и подобрать понятный рабочий процесс. Для каталога или сложной подачи можно добавить интерактивные компоненты и отдельные композиции страниц.

В этой работе соединяются мой опыт продуктового дизайнера и разработка с AI. Я могу пройти весь путь: определить структуру материалов, собрать интерфейс, настроить выпуск и проверить опубликованный результат. Если вам нужен такой сайт, напишите мне в Telegram и покажите, что вы хотите публиковать и как с этим собираетесь работать.