Всем привет, меня зовут Михаил Одегов.

С 2019 по 2022 год я работал UX/UI‑дизайнером на фрилансе, а затем перешёл во фронтенд. Последние два года занимался довольно сложной админкой для управления зарядными станциями электромобилей в MAESTRO.ECO. Помимо разработки, периодически закрывал задачи дизайнера: в некоторых случаях быстрее было самому спроектировать интерфейс, чем объяснять другому человеку, что именно нужно сделать. Да и банально — экономия бюджета.

К началу 2026 года ситуация на работе стала довольно печальной: задач почти не осталось, с деньгами тоже начались проблемы. Я понял, что пора расширять специализацию. Чистый фронтенд начал казаться мне слишком узким, а многие задачи — однообразными (на тот момент я даже не трогал агентную разработку — с ней на фронтенде вообще не остаётся сложных задач). Хотелось научиться самостоятельно собирать продукт целиком: от интерфейса и API до базы данных и запуска на сервере — к тому же быть эникейщиком сейчас в целом модно.

Так появился проект, который изначально вообще не должен был становиться отдельным продуктом.

Март 2026 года. Обычный учебный проект

Для изучения бэкенда я выбрал Node.js и довольно быстро пришёл к NestJS.

Учебный проект решил сделать максимально стандартным по меркам 2026 года: социальная сеть с публикациями, профилями и сообщениями, плюс подключение по вебсокету (Socket.IO). Ничего революционного — обычный набор функций, на котором удобно разбирать авторизацию, API, базу данных, права доступа и взаимодействие между фронтендом и бэкендом.

Фронтенд написал на Vue, т.к давно работаю с ним и он мне нравится больше React.

По ходу разработки я постоянно обсуждал решения с Дипсиком: какие варианты реализации существуют, какие у них плюсы и минусы, где могут появиться проблемы. Так, например, я случайно узнал, что access‑ и refresh‑токены сейчас принято хранить в httpOnly‑куках.

А вот с базой данных получилось менее осознанно.

PostgreSQL за пять минут у меня не установился, Docker я тогда почти не знал, поэтому выбрал MongoDB. В результате вместо упрощения разработки получил примерно на треть больше работы: многие связи и ограничения, которые в реляционной базе выглядели бы естественно, пришлось контролировать на уровне крудов.

Зато это был полезный способ на практике понять, чем отличаются реляционные и документные базы данных. Теоретические объяснения до этого запоминались намного хуже (постоянно слышал, что монга «документно‑ориентированная», но для меня это были просто слова, которые ничего не говорили о реальной практике).

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

Пользователи могли создавать публикации и короткие записи в редакторе Tiptap, оставлять комментарии и ставить лайки. Работал счётчик просмотров, были светлая и тёмная темы, а интерфейс поддерживал несколько языков.

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

На этом учебный проект можно было считать законченным.

Один вопрос, после которого проект изменился

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

Ответ был примерно таким:

Шанс — один из ста. Но он станет немного выше, если публикации автоматически переводить.

Я решил «докрутить» эту идею до максимума (заодно расширив количество доступных языков с 5 до 90, включая суахили — почему бы и нет)

Просто добавить кнопку «Перевести» было неинтересно. Таких решений много, и они довольно скучные. Я хотел, чтобы альтернативная языковая версия существовала не как временный перевод в интерфейсе читателя, а как почти полноценный объект в базе данных.

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

Главные требования выглядели так:

• отдельный URL;

• независимое от оригинала редактирование;

• сохранение структуры и оформления публикации;

• возможность индексироваться как самостоятельная страница.

То есть я хотел уйти от подхода, при котором перевод существует только внутри интерфейса платформы — как, например, в Reddit, — и почти не контролируется самим автором. В Nneon языковая версия должна была принадлежать автору и оставаться самостоятельной публикацией, а не просто способом удержать читателя внутри сервиса (этот аспект уже начал раздражать многих даже на YouTube)

Например, одна группа публикаций могла выглядеть так:

• /ru/post/article-slug

• /fr/post/article-slug

Автор пишет материал один раз, а затем получает отдельные версии для разных языковых аудиторий.

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

На тот момент я не нашёл платформы, которая объединяла бы всё это в одном продукте. Были сервисы локализации сайтов, переводчики, блоговые платформы и отдельные SEO‑инструменты, но не единая издательская система.

Чтобы поисковики нормально видели содержимое страниц, фронтенд пришлось перенести с обычного Vue на Nuxt.

Так учебная социальная сеть начала превращаться в Nneon.

Первые попытки перевода

Вначале я придерживался довольно очевидной идеи: использовать разные переводчики для разных языков.

Дипсик советовал, например:

• Яндекс — для русского языка;

• DeepL — для европейских языков;

• LLM — для более сложных случаев.

С API Яндекса удалось сохранить структуру публикации, но качество перевода меня не устроило. Что особенно обидно, для доступа к API пришлось положить 5000 рублей — о них я вспомнил, только пока писал данную публикацию.

С DeepL я несколько дней пытался разобраться с доступом и ограничениями (я нахожусь в РФ), но в итоге у меня так и не получилось их обойти.

Затем я нашёл OpenRouter. На тот момент (сейчас они усилили ограничения для РФ) это был очень удобный способ быстро переключаться между моделями, сравнивать ответы и видеть реальную стоимость каждого запроса.

После первых тестов мне казалось, что оптимальное соотношение цены и качества даёт двойной прогон через GPT-4.1. Более дешёвые GPT-4.1 mini и Gemini Flash я планировал использовать для черновиков: такая версия могла быть доступна автору для редактирования, но не публиковаться автоматически.

Главная проблема заключалась в том, что качество переводов я проверял с помощью Дипсика.

Позже выяснилось, что этот проверяющий пропускал ошибки, которые другие модели (GPT 5.6 Sol) замечали сразу. Из‑за этого несколько ранних выводов о качестве оказались ошибочными.

Как продавать переводы, не уходя в минус

Из получавшейся системы вполне можно было сделать B2B‑сервис: подключать существующие сайты и переводить их контент.

Но меня больше интересовала другая идея.

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

Возник вопрос: как оплачивать переводы?

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

Решение я постоянно видел перед собой в интерфейсе OpenRouter: внутренний баланс.

В Nneon у каждого пользователя есть счёт, с которого списывается фактическая стоимость операций с учётом комиссии платформы. Размер комиссии можно менять, например уменьшать за приглашение новых авторов, снижать для активных пользователей, использовать региональные коэффициенты;

Теоретически это, например, позволяет сделать региональные цены по модели Steam. Автор из страны с низкими доходами может платить меньше стандартной цены, даже если платформа почти ничего на этом не зарабатывает.

Для UGC‑платформы важнее сначала получить содержательные публикации и авторов, чем выжимать максимальную маржу с каждой операции.

Культурный контекст и локализация

Довольно быстро стало понятно, что перевод слов — только часть задачи.

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

Например, при переводе немецкого блога на русский язык модель могла объяснить, кто такие швабы. Такое пояснение можно добавить:

• курсивом прямо в текст;

• отдельной сноской;

• коротким примечанием после абзаца.

По тому же принципу можно адаптировать единицы измерения. Например, рядом с километрами показывать мили.

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

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

На момент написания статьи эти возможности я решил отключить. Сначала нужно разобраться с более базовыми вещами: качеством переводов, UX и поведением поисковиков.

Также, я добавил ещё две бесплатных AI‑рекомендации для неопубликованного текста:

• На каких языках материал потенциально может быть востребован.

• В каких странах или языковых средах публикация способна вызвать юридические, физические или иные серьёзные риски.

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

Фрагменты, которые нельзя переводить

Ещё в начале разработки появилась простая система защиты отдельных фрагментов от перевода.

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

Платформа [[[Nneon]]] использует модели [[[OpenAI GPT-5.6 Terra]]]
и сервис [[[OpenRouter]]].

При создании языковой версии содержимое внутри [[[...]]] гарантированно не переводится:

La plateforme Nneon utilise les modèles
OpenAI GPT-5.6 Terra et le serviceOpenRouter.

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

• названия компаний, продуктов и моделей;

• никнеймы и термины, для которых автор заранее выбрал написание;

• код, команды и идентификаторы;

• намеренно непереведённые фразы, названия произведений и пацанские цитаты на латыни.

Без такой защиты модель иногда меняет то, что переводить вообще не следовало: локализует название продукта, исправляет регистр, расшифровывает аббревиатуру или транслитерирует никнейм.

Во время написания статьи отметил, что нужно будет сделать тоже самое и по отношению к полям помимо тела публикации

Необязательно платить за автоматический перевод

Ещё в самом начале разработки я предусмотрел альтернативный сценарий: языковую версию можно создать вообще без обращения к нейросети (кстати, подобный функционал недавно появился у Substack. Но у меня раньше)

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

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

• не индексируется поисковиками;

• не появляется в общей ленте;

• не показывается читателям как готовый перевод.

По сути, это заготовка для ручной локализации.

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

Автоматический перевод поэтому является не обязательным условием публикации, а одним из способов создать новую версию:

Создать через AI → платно и быстро
Создать копию → бесплатно, но заполнить вручную

Мне кажется важным сохранять оба варианта. Иначе платформа искусственно заставляла бы пользователя платить за операцию, которую он способен выполнить самостоятельно.

Как Codex изменил процесс разработки

Во время реализации этих функций я заболел, но проект останавливать не хотелось. Тогда я решил попробовать Codex и перехал в монорепозиторий, чтобы он видел контекст всего проекта.

После этого 100% кода создавал агент, а я отвечал за высокоуровневую архитектуру (у данного подхода есть свои минусы, но для проекта, которым вообще не факт, что будет кто‑то пользоваться, эти минусы оправданы).

Сначала я не оформлял подписку и платил за использование отдельно. Другие модели убеждали меня, что при моём темпе разработки я обязательно упрусь в лимиты подписки.

На практике тарифа примерно за 100 долларов мне оказалось достаточно. Вероятно, до этого я зря потратил ещё около 300 долларов «сверху» на API. Бывает.

Что ещё появилось перед запуском

К продакшену платформа уже умела не только переводить основной текст.

Автор мог задавать:

• meta title;

• meta description;

• alt‑тексты изображений.

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

Описание изображений можно было сгенерировать отдельной моделью, если автор не хотел писать его самостоятельно. Со временем эта функция стала вызывать у меня сомнения: модель нередко описывает изображение формально или добавляет детали, которых там нет. Сейчас я скорее склоняюсь к тому, что генерация alt‑текста — избыточный функционал.

Для инфраструктуры я подключил Cloudflare: кэширование, защиту от ботов и DDoS, а также S3-совместимое файловое хранилище.

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

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

Заметки я добавил буквально за пару запросов к агенту. Особой инженерной гордости здесь нет, но короткий формат может пригодиться пользователям. Заметки не индексируются и не переводятся при создании: перевод выполняется по клику дешёвой моделью. Зато пользоваться ими можно бесплатно.

Поскольку Nneon всё‑таки задумывался как UGC‑платформа, одной автоматической модерации было недостаточно. Я предусмотрел обычную систему жалоб:

• нарушение авторских прав и публикация чужого контента;

• спам;

• незаконные материалы и другие нарушения правил платформы.

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

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

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

К этому моменту платформа стала поддерживает 90 языков. Это относится не только к публикациям: сам интерфейс тоже локализован.

Перевод интерфейса я автоматизировал связкой из скрипта и нейросети. Скрипт подготавливает и проверяет структуру локализаций, а модель переводит текстовые значения. Без автоматизации поддерживать сотни (~900, если быть точнее) JSON файлов вручную было бы практически невозможно.

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

Июль 2026 года. Запуск

В DevOps и CI/CD я тогда разбирался слабо, поэтому не стал изображать универсального специалиста и попросил более опытного друга помочь с инфраструктурой.

Мы подняли отдельный сервер разработки, продакшен, административную панель (в т.ч собирает всякую статистику платформы) и CI/CD‑процесс.

После нескольких месяцев разработки Nneon оказался в продакшене.

Дальше возник очевидный вопрос: что делать, когда у тебя нет аудитории, SEO‑веса и бюджета на маркетинг, а на кредитной карте примерно минус 50 тысяч рублей? Тестировать самостоятельно.

Первые итоги я разделил на три большие темы:

• качество перевода;

• UX/UI;

• индексация языковых страниц в Google.

Начну с перевода.

DeepSeek оказался плохим проверяющим переводов

Проблема проявилась не на первых двух статьях о самой платформе, а на третьем тестовом материале.

Я опубликовал статью о Тренте Резноре — во многом потому, что создавал проект под его музыку. Сам текст был частично сгенерирован по моим идеям: времени на полноценную авторскую статью тогда не было.

На этот раз я решил проверить перевод не через Дипсик, а через GPT-5.6 Sol, ибо в публикацию я вложил какие‑то свои мысли, и мне было важно качество перевода.

Вердикт оказался неприятным: перевод нельзя показывать читателям даже с заметной плашкой о том, что он выполнен автоматически (точнее, так утверждал GPT-5.6 Sol).

Самая запоминающаяся ошибка возникла в испанской версии во фразе:

«Я создавал проект под его музыку.»

Из контекста очевидно, что речь идёт о музыке, которая играла во время работы. Но перевод получился буквальным, будто проект создавался специально «для» музыки как продукт или техническое задание.

С этой фразой справился даже обычный Google Translate. А двойной прогон через GPT-4.1 — нет.

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

Почему второй проход не гарантирует качество

Интуитивно мне казалось, что схема должна работать так:

→ первичный перевод
→ проверка другой моделью
→ исправление
→ хороший результат

На практике всё оказалось сложнее.

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

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

Я перепробовал несколько моделей и вариантов пайплайна, но идеального автоматического перевода не получил. Чат GPT-5.6 Sol почти всегда находил какие‑то проблемы — иногда важные, иногда относящиеся только к оттенкам стиля.

Главный вывод состоял не в том, что все модели плохие.

Проблема в самой постановке задачи:

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

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

К каким выводам я пришёл

Первый вывод: идеальный автоматический перевод недостижим как гарантированный результат.

Рабочий процесс должен выглядеть иначе:

система создаёт первую языковую версию → версия публикуется с явным указанием автоматического перевода → собираются показы и первые просмотры → автор понимает, какие языки действительно востребованы → важные версии редактируются вручную — самостоятельно или вместе с языковой моделью

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

Второй вывод: вместо абстрактных уровней «низкое», «среднее» и «высокое качество» лучше честно показывать автору и читателю конкретную модель.

Сейчас логика выглядит примерно так:

• GPT-5.6 Sol — самый дорогой вариант;

• GPT-5.6 Terra — промежуточный;

• GPT-4.1 — более доступный.

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

Комментарий переводчику

Разметка [[[...]]] хорошо решает однозначную задачу: этот конкретный фрагмент нельзя переводить.

Но она не помогает там, где переводчику нужно понять авторское намерение.

Например, фраза:

Я создавал платформу под его музыку.

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

Для таких случаев во время тестирования появилась возможность оставить комментарий переводчику:

Фраза «создавал платформу под его музыку» означает, что музыка играла во время работы над проектом.

Комментарий передаётся вместе с конкретной задачей на перевод, но не добавляется навсегда в общий системный промпт.

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

В итоге у автора есть два разных инструмента:

[[[Nneon]]]
→ сохранить фрагмент без изменений

Комментарий переводчику:
«Под его музыку» означает «слушая её во время работы»
→ правильно интерпретировать смысл

Первый инструмент управляет формой, второй — пониманием контекста.

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

Как интерфейс изменился после собственного использования

До запуска я в основном проверял платформу как разработчик: создавал тестовые записи, переносил чужие тексты, нажимал кнопки и смотрел, не разваливается ли приложение.

После запуска ситуация изменилась. Я начал писать собственные публикации, в которые уже действительно вкладывал время и какие‑то мысли.

Это оказалось совсем другим видом тестирования.

Когда создаёшь условный lorem ipsum или переносишь чужую статью, многие неудобства кажутся несущественными. Когда создаёшь длинный текст сам, оплачиваешь его перевод и затем исправляешь языковые версии, каждая лишняя кнопка и неочевидное действие начинают раздражать.

После нескольких полных циклов публикации я внёс ряд изменений.

Для каждого языка теперь можно выбирать свою модель

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

Значимость разных версий может отличаться. Например, английский для большинства публикаций является наиболее важным международным языком, поэтому для него я обычно выбираю Terra или Sol. Для менее приоритетной версии можно использовать более доступную модель.

Теперь настройки могут выглядеть так:

• English — GPT-5.6 Sol

• Deutsch — GPT-5.6 Terra

• Español — GPT-4.1

• Français — GPT-4.1

Это позволяет не платить максимальную цену за все переводы сразу и направлять бюджет на те языки, от которых автор ожидает аудиторию.

Английская версия имеет ещё одно особое значение внутри платформы. Если пользователь выбрал определённый язык интерфейса, но публикации на этом языке не существует, в ленту может попасть её английская версия (а это, кроме всего прочего, поможет её проиндексировать).

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

Собственный slug

Раньше адрес публикации автоматически строился из заголовка на языке оригинала.

Это удобно, пока сгенерированный slug получается коротким и понятным. Но длинные заголовки, изменения названия и особенности транслитерации быстро показали ограничения такого подхода.

Теперь автор может задать адрес самостоятельно:

/ru/post/translate-website-content-platforms

Вместо автоматически полученного и не всегда удачного варианта (слаг на русском не имеет смысла, например).

Это небольшая функция, но при публикации реального материала она даёт больше контроля над тем, как ссылка будет выглядеть в поиске, социальных сетях и переписке.

Предварительный расчёт стоимости

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

Поэтому перед запуском платформа теперь показывает примерную стоимость:

Предварительная стоимость: $3,42

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

Финальная стоимость может немного отличаться (разные языки будут иметь разное количество символов + нужно закреплять тестированием + стоимость частично зависит от настроения Сэма Альтмана), но пользователь хотя бы понимает порядок суммы до того, как нажмёт кнопку.

Для сервиса с внутренним балансом это обязательная функция. Особенно когда один перевод может стоить несколько центов, а другой — больше доллара.

На данный момент наиболее разумным по соотношению цены и качества мне кажется GPT-4.1 с дополнительным проходом (вернулся к тому, с чего начал). Но даже такой перевод нельзя считать профессионально вычитанным. Как и любой автоматический результат, он требует ручной проверки там, где точность действительно важна.

Связанные публикации

Во время создания материала теперь можно выбрать уже опубликованные статьи, связанные с новой.

Читателю это поможет видеть общий контекст повествования.

Для поисковиков это даёт внутреннюю перелинковку. Новая публикация не остаётся изолированной страницей, найденной только через sitemap: на неё и с неё ведут обычные ссылки внутри сайта.

Соавторы

По той же логике появилась возможность добавлять соавторов.

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

Что делать с переводами после изменения оригинала

Редактирование опубликованной группы оказалось сложнее первоначального создания.

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

Поэтому после редактирования оригинала появились три действия.

Сохранить только оригинал

Изменяется исходная публикация. Все переводы остаются в прежнем состоянии. Это подходит для небольших исправлений, которые автор не хочет автоматически переносить на остальные языки.

Сохранить группу без запуска перевода

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

Сохранить и перезапустить переводы

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

Отдельные настройки запуска переводов

Также появилась специальная кнопка «Настройки запуска переводов».

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

То есть перезапуск больше не работает по принципу «удалить всё и перевести заново». Например, автор может:

• English — перегенерировать через Sol

• Deutsch — оставить как есть

• Español — добавить через Terra

• Français — удалить

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

Язык публикации и язык интерфейса — разные вещи

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

То есть пользователь с русским интерфейсом открывал французский перевод — и меню, кнопки и служебные сообщения тоже становились французскими.

Во время реального использования стало понятно, что это неправильно, а ещё очень сильно мешает редактировать альтернативные версии.

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

Поэтому два состояния были разделены:

• Язык публикации: французский

• Язык интерфейса: русский

При этом для поисковиков языковые версии остаются полноценными отдельными страницами:

• /ru/post/article

• /fr/post/article

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

Одновременно рядом с каждым языком стала показываться модель, с помощью которой была создана версия.

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

Что произошло с индексацией спустя месяц

Если ответить одним предложением: Google действительно индексирует языковые версии.

Не мгновенно, не все сразу и не с одинаковым приоритетом — но сама архитектура работает.

Например, я опубликовал статью о сервисах и платформах, которые переводят публикации и сайты целиком. Её немецкая версия начала получать около 30 показов в поисковой выдаче.

Это пока не означает 30 переходов на сайт. Речь именно о показах: Google включал страницу в результаты поиска, но пользователи могли её не открыть.

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

Для молодого сайта без ссылочного веса это ожидаемо. На данном этапе важнее сам факт, что Google:

• обнаружил отдельные языковые URL;

• не объединил все версии в одну страницу;

• начал показывать их по запросам на соответствующих языках.

Пожалуй, самый наглядный тест получился случайно.

Я ввёл в Google собственный ник и увидел несколько десятков страниц, переведённых и опубликованных через Nneon.

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

Особенно с учётом исходных условий: домену было около месяца, о платформе почти никто не знал, а внешних ссылок практически не было. При этом большая часть контента была переведена автоматически, а восемь исходных публикаций уже разрослись примерно до 400 URL.

Для первого месяца результат я считаю хорошим.

Но 90 индексируемых версий одной публикации оказались ошибкой

Технически платформа умеет работать с 90 языками. Из этого я первоначально сделал неправильный продуктовый вывод: раз версия может быть создана, значит её можно сразу открыть для поисковиков. Одна публикация могла почти мгновенно породить десятки отдельных URL.

В результате сайт создавал новые страницы быстрее, чем Google успевал приоритетно их обходить. В Search Console часть адресов долго оставалась в статусах:

Обнаружена, не проиндексирована или URL неизвестен Google

При этом страницы находились в sitemap и были технически доступны.

Я сначала называл это исчерпанным краулинговым бюджетом. Формально для сайта из нескольких сотен страниц это не тот crawl budget, который обычно обсуждают применительно к огромным каталогам. Точнее будет сказать так:

новый домен создавал URL быстрее, чем получал достаточный приоритет их сканирования.

Google видел sitemap, но не считал необходимым немедленно обходить все несколько сотен страниц неизвестного сайта. Поэтому я ограничил количество индексируемых языков одной публикации десятью (а в идеале вообще сделать три индексируемых языка, и увеличивать их доступное количество по мере появления интереса к публикации).

Платформа по‑прежнему поддерживает 90 языков. Но автору не нужно создавать 90 поисковых страниц только потому, что такая техническая возможность со стороны платформы существует.

Новая логика выглядит разумнее:

• 90 поддерживаемых языков

• до 10 индексируемых версий одной публикации

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

Ограничение в 35 тысяч символов тоже стоит пересмотреть

Первоначально я разрешил публикации длиной до 35 тысяч символов (а для альтернативных языковых версий в полтора раза больше, на всякий случай).

Это подходит для больших лонгридов, но создаёт сразу несколько проблем:

• высокая стоимость перевода и долгое выполнение запросов;

• больше вероятность локальных ошибок модели — сложнее ручная проверка;

• одна публикация может создать десятки очень больших страниц;

• первые авторы получают слишком высокий порог входа.

Сейчас я думаю уменьшить стандартный лимит примерно до 15 тысяч символов.

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

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

Статистика Google Search Console внутри платформы

Постоянно открывать Google Search Console и вручную сопоставлять URL с публикациями оказалось неудобно. Особенно когда одна исходная статья существует сразу в нескольких языковых версиях.

Поэтому я подключил данные Google Search Console непосредственно к странице статистики Nneon.

Теперь автор может прямо в Nneon увидеть, какие публикации уже появились в Google хотя бы на одном языке и сколько отдельных языковых версий попало в индекс. Платформа также показывает общее количество показов и переходов из поиска, среднюю позицию и отдельную статистику по каждой публикации.

Например, на момент одного из замеров Google обнаружил пять из шести опубликованных материалов. При этом из 60 выбранных для отслеживания языковых версий в индексе находились 14. Они получили 142 показа, один переход, а средняя позиция составляла 25,6.

Для каждой публикации отдельно показывается её текущее состояние:

• полностью или частично находится в индексе;

• только обнаружена Google;

• сколько языковых версий уже проиндексировано;

• сколько было показов и переходов из поиска.

Что получилось в итоге

В целом эксперимент я считаю удачным.

Удалось подтвердить, что отдельные языковые страницы индексируются и могут независимо появляться в поисковой выдаче Google. Автоматический перевод при этом можно встроить не просто в кнопку «Перевести», а в полноценный издательский процесс: выбирать модель и стоимость отдельно для каждого языка, отслеживать первые результаты и вручную улучшать те версии, которые действительно нашли аудиторию.

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

Особенно интересны материалы, основанные на личном опыте:

• дневники разработки и разборы собственных проектов;

• профессиональные истории и авторские блоги;

• исследования, эссе и узкие практические наблюдения;

• также актуальны гайды по собственным it‑проектам

Общие гайды и информационные выжимки сегодня относительно легко генерирует нейросеть. Ещё один текст «Десять способов повысить продуктивность» или «Установка и безопасная настройка Redis» сам по себе почти ничего не доказывает.

Субъективный опыт устроен иначе. Модель может помочь его оформить или перевести, но ей неоткуда взять именно те события, решения, ошибки и выводы, через которые прошёл конкретный человек.

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

Что в итоге представляет собой Nneon

Изначально я собирался просто изучить NestJS и сделать очередную учебную социальную сеть.

В результате получилась платформа, в которой:

• публикация существует как группа независимых языковых версий, каждая из которых редактируется отдельно с сохранением структуры Tiptap‑документа;

• вместе с содержимым переводятся метаданные и описания изображений;

• для каждого языка можно выбрать отдельную модель, а примерная стоимость рассчитывается до запуска;

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

Главным открытием первых месяцев стало то, что технически вызвать модель и сохранить перевод довольно просто.

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

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

Ну и разумеется, у меня есть не очень большой, но бюджет, чтобы пополнить внутренний баланс автора, который захочет что‑нибудь опубликовать. Само собой, контент с нуля создавать я не прошу — достаточно взять уже написанную публикацию (при условии, что она принадлежит именно вам), которую в теории может кто‑то почитать на другом языке. И сделать репост куда‑нибудь в социальные сети.

Перед публикацией данной статьи поставил 3 доллара первичный баланс для новых пользователей. Нужно будет больше — пишите. Но я должен предупредить, что публикации проходят ручную модерацию лично мной, стоит ограничение на 1 публикацию в день, а ссылки на странице публикации помечаются как nofollow. А ещё, для работы с сайтом, нужен VPN из‑за Cloudflare.