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

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

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

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

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

Формулировку, объясняющую суть, даёт справка одного из таких конструкторов, Bolt:

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

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

Что видит поисковый робот, когда открывает вашу страницу

Технически это выглядит как одна строчка вида <div id="root"></div> и подключённый рядом файл с кодом. Всё осмысленное - заголовки, тексты, навигация, описания - появляется после того, как код отработает.

Практик Ян-Виллем Боббинк описывает это так: всё значимое содержимое существует только после выполнения скриптов в браузере. Отсюда следствие для индексации: страница формально доступна, отдаёт код ответа 200, но с точки зрения робота она пустая.

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

Как за тридцать секунд проверить, что видит робот

Для этой проверки ничего не нужно устанавливать.

1. Откройте страницу сайта - главную или любую внутреннюю.
2. Нажмите Ctrl+U (Windows) или Cmd+Option+U (Mac). Откроется вкладка с исходным кодом страницы.
3. Нажмите Ctrl+F и вставьте фразу из видимого текста страницы - например, кусок заголовка или первого абзаца.
4. Смотрите результат. Фраза найдена - робот видит текст, техническая часть в порядке. Не найдена - содержимое рисуется скриптами.
5. Проверьте <title> и <meta name="description"> на двух-трёх разных страницах. Совпадают - метатеги не настроены.

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

Google умеет читать скрипты, но с очередью

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

Цифра, которую называл представитель Google Мартин Сплитт ещё в 2019 году, - медиана пять секунд. Медиана означает, что половина страниц ждёт дольше, и хвост этого распределения бывает длинным.

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

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

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

Яндекс не обещает выполнять скрипты вообще

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

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

Что важно знать:

• Режим по умолчанию - «на усмотрение робота». Робот сам определяет, выполнять ли код: например, может сравнить качество и полноту содержимого страницы со скриптами и без и загрузить ту версию, которая полезнее посетителю.
• Статус функции - бета. В справке она помечена значком β.
• Предупреждение о нагрузке - при выполнении кода робот может создавать дополнительную нагрузку на ваш сервер.
• Прямой совет Яндекса - запретить рендеринг, если на сайте уже сделан серверный рендеринг или пререндеринг.
• Свой механизм для отложенного содержимого - объект window.YandexRotorSettings, которым сайт сообщает роботу, что контент подгружается с задержкой. У Google такого механизма нет.

Сведём разницу в таблицу, потому что она определяет решение.

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

Нейросети не выполняют скрипты никогда

С нейросетями ситуация жёстче, чем с поисковиками.

В переводе: результаты последовательно показывают, что ни один из крупных ИИ-роботов сегодня не выполняет JavaScript. В том же исследовании: роботы ChatGPT подгружают файлы со скриптами примерно в 11,5% запросов, Claude - в 23,8%, но не исполняют их. Отдельно отмечено исключение: Gemini использует инфраструктуру робота Google и рендерит полноценно.

Что из этого следует. У Google есть очередь: сегодня не отрендерил - отрендерит через неделю. У ИИ-роботов ChatGPT, Claude и Perplexity очереди нет, потому что нет самой стадии выполнения кода. Ваш сайт для них пустой всегда.

Разница между поиском и ИИ-ответами тут принципиальная. Google для своих ИИ-ответов требует всего лишь, чтобы страница была проиндексирована и могла показываться со сниппетом, - никакой особой разметки не нужно. Но чтобы попасть в ответ ChatGPT или Perplexity, ваш текст должен лежать в исходном коде страницы. Проверить это - те же тридцать секунд из третьего раздела.

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

Какие конструкторы делают видимый сайт, а какие нет

Разберём по именам, потому что от этого зависит, что вам делать.

Lovable. В документации прямо описаны две эпохи: приложения, созданные с 13 мая 2026 года, используют TanStack Start с серверным рендерингом, а более старые приложения на React и Vite получают пререндеринг по запросу, который отдаётся только проверенным поисковым и ИИ-роботам. Там же оговорка, важная для диагностики: сторонние SEO-сканеры и прочие непроверенные агенты видят обычное одностраничное приложение. И отдельно в справке сказано: карты сайта, robots.txt, метаданные и другие элементы не всегда создаются сразу.

Bolt. Здесь вендор документирует ограничение сам. Функция SEO Boost отдаёт роботам заранее отрендеренную версию страниц - и в справке написано, что по умолчанию она выключена, а для включения нужен собственный домен. То есть типовая ситуация «собрал и опубликовал на поддомене конструктора» означает, что роботы получают страницу без пререндера.

v0 от Vercel и Replit. Здесь честный ответ - «неизвестно». Оба вендора описывают совместимость со стеками, но прямого утверждения о том, что генерируется по умолчанию, в их документации нет. Значит, судить о своём сайте по названию инструмента нельзя: смотрите исходный код страницы способом из третьего раздела.

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

Что ещё обычно не сделано на сайте, собранном нейросетью

Список того, что проверяется за полчаса:

1. robots.txt не запрещает обход - открывается по адресу вашсайт.ру/robots.txt.
2. Карта сайта существует и передана в оба вебмастера.
3. Собственный домен вместо служебного адреса конструктора.
4. Уникальные заголовок и описание на каждой странице.
5. Канонические адреса, если одна страница доступна по нескольким ссылкам.
6. Один заголовок первого уровня на страницу.
7. Структурированная разметка - служебные пометки в коде страницы, по которым поисковик понимает, где цена, где вопрос, а где ответ. Нужна там, где вы хотите расширенный сниппет: карточку в выдаче с рейтингом, ценой или списком вопросов.
8. Страница «О компании» с настоящим юрлицом и контактами.
9. Подпись автора у статей и разборов.

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

Как проверить сайт в Вебмастере и Search Console

Google Search Console. Введите адрес страницы в инструмент проверки URL, нажмите «Проверить страницу на сайте», затем «Изучить проверенную страницу». Появятся вкладки с кодом, который вернул сервер, и со скриншотом того, как Google отрисовал страницу. Там же видно ресурсы, недоступные роботу, и сообщения консоли. Расхождение между скриншотом и кодом - это ровно ваш диагноз.

Яндекс Вебмастер. Откройте «Проверка ответа сервера», укажите адрес страницы и выберите робота, чтобы проверить его доступ. Инструмент покажет код ответа и доступность. В справке есть честная оговорка: ответ может отличаться от реального ответа роботу, потому что у инструмента другой IP-адрес.

Отдельно зайдите в раздел индексирования и найдите настройку рендеринга страниц с JavaScript, помеченную бетой. Посмотрите, что у вас выставлено. Если сайт отдаётся готовым с сервера, Яндекс советует выполнение скриптов запретить.

Чем это лечится и сколько стоит

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

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

Когда дешевле пересобрать, чем чинить

Прямых исследований на тему «во сколько обходится довести сайт, собранный нейросетью, до рабочего» найти не удалось. Есть одна публичная ценовая привязка: команда, которая занимается расчисткой такого кода, берёт 10 000 долларов за неделю работы трёх опытных инженеров. Целевой показатель они формулируют так: сократить условные 100 тысяч строк до 35 тысяч при той же функциональности - и оплата привязана к достижению этой цели. Это ориентир по договору, а не отчёт о выполненном проекте.

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

Признаки, по которым проще начать заново:

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

Даже видимый сайт не приводит клиентов сам по себе

Починив рендеринг, вы попадаете в индекс - и обнаруживаете, что там уже лежат миллиарды страниц.

Исследование Ahrefs на выборке около 14 миллиардов страниц их индекса даёт цифру: 96,55% не получают из Google ни одного перехода. Ещё 1,94% получают от одного до десяти визитов в месяц. Оговорки есть в самом исследовании: это оценки по их собственному индексу, охватывающему часть интернета, и относятся они к Google.

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

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

Чем прототип отличается от продукта

Эта часть догоняет всех, кто пошёл дальше визитки.

Безопасность. Компания Veracode в отчёте от 30 июля 2025 года по итогам тестирования более ста языковых моделей сообщает, что 45% образцов кода не прошли проверки безопасности и внесли уязвимости из списка OWASP Top 10. В феврале 2026 года издание The Register описало случай приложения, собранного на Lovable: исследователь нашёл 16 уязвимостей, а наружу оказались доступны 18 697 записей пользователей, из них 14 928 с уникальными адресами почты.

Поддерживаемость. Компания GitClear, проанализировав 623 миллиона изменений кода за 2023-2026 годы, зафиксировала рост дублирования блоков на 81% и падение доли переработанного кода с 13% до 3,8%. Проще говоря, кода становится больше, а порядка в нём меньше.

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

Отрезвляющий взгляд со стороны. Разработчик Ибрагим Диалло описал судьбу приложений своих друзей-непрограммистов так:

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

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

Что сделать на этой неделе

1. Откройте исходный код двух-трёх страниц и поищите в нём свой текст. Это ваш диагноз.
2. Заведите сайт в Яндекс Вебмастер и Google Search Console, если этого ещё нет, и посмотрите, сколько страниц в индексе.
3. Проверьте robots.txt и карту сайта. Отсутствие карты - обычное дело для сайта, собранного нейросетью.
4. Переведите сайт на свой домен, если он живёт на адресе конструктора.
5. Пропишите уникальные заголовки и описания хотя бы для главных страниц.
6. Выберите способ починки рендеринга из таблицы выше и оцените, что для вас дешевле в горизонте года.
7. Добавьте страницу о компании с реальными контактами и подпись автора у материалов.

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

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