SavePearlHarbor

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

—

от автора

admin

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

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

На чем держится интернет

Принято думать, что современный веб сплошь состоит из модных фреймворков. На деле подавляющее большинство интернета держится на «старье»: PHP стоит примерно на 72% всех сайтов с известным серверным языком, а один только WordPress крутит около 43% сайтов планеты. Старый добрый HTML + jQuery тоже живее всех живых. Скучные проверенные технологии дружат с поисковиками из коробки, а вот нейронки любят собирать сайты иначе.

SPA и SSR

Все современные подходы к фронтенду в грубом приближении сводятся к двум лагерям.

SPA, single page application

Одностраничное приложение: сервер отдает браузеру почти пустой HTML-файл и большой JavaScript-бандл, а страница собирается на лету, прямо в браузере пользователя. Подтягиваются блоки, тексты, данные из API.

Кажется, что это что-то из последних лет, но подходу больше двадцати. Первые самодостаточные одностраничники появились еще в 2002-2003 годах: сайт slashdotslash.com студента Кардиффского университета (апрель 2002), патент на реализацию SPA того же года, обсуждения евангелистов Netscape в 2003-м. Массовым подход стал после расцвета AJAX в середине 2000-х (Gmail, Google Maps), а окончательно победил с приходом фреймворков: AngularJS (2010), React (2013), Vue (2014).

Сегодня SPA — это дефолт. Создаешь проект на React или Vue через Vite и получаешь классический одностраничник. Чем SPA хорош, так это бесшовностью: переходы между «страницами» происходят без перезагрузки, все летает, а роутинг просто условность, приложение само подменяет контент. Мы ушли из мира, где index. html, about. html и contacts. php грузились целиком при каждом клике, с белым экраном между переходами.

SSR, server-side rendering

Рендеринг на стороне сервера, в каком-то смысле возвращение к истокам. Сервер собирает страницу целиком, со всеми заголовками, текстами, менюшками и разметкой, и отдает браузеру готовый HTML. Пользователь (и робот!) сразу получает полный контент, а JavaScript потом «оживляет» страницу. Этот процесс называется гидратацией.

Современный SSR при этом не откат в эпоху чистого PHP, каким его иногда представляют: это те же React и Vue, просто в правильной обертке.

  • Next.js: SSR/SSG для React, самый популярный вариант;

  • Nuxt: то же для Vue;

  • SvelteKit: для Svelte;

  • Angular SSR (бывший Angular Universal);

  • Remix / React Router v7: еще один серверный подход для React;

  • Astro: отдельная любовь. По умолчанию генерирует статический HTML, идеален для лендингов и блогов.

Рядом стоит родственник, SSG (static site generation): страницы собираются в готовый HTML один раз, при сборке проекта. Для лендинга, где контент не меняется каждую минуту, это вообще идеал: быстро, дешево, роботы счастливы.

Как поисковый робот смотрит на ваш сайт

Чтобы Google или Яндекс что-то показали в выдаче, им нужно пройти три шага: зайти на страницу (краулинг), понять, что на ней находится (индексация), и решить, кому и когда ее показывать (ранжирование).

Масштабы такие: в мире порядка 1,1-1,4 млрд сайтов, из которых активна меньше пятой части, а индекс Google оценивался примерно в 400 млрд документов. Цифра всплыла на антимонопольном процессе против Google. Одни только файлы robots.txt Google проверяет у 4 млрд хостов ежедневно. При таких объемах каждая лишняя секунда обработки страницы оборачивается горами серверов и мегаваттами электричества. Поэтому роботы торопливы и по возможности «слепы»: в идеале им нужен готовый HTML, из которого можно сразу вытащить контент.

Что видит робот, зайдя на типичный вайб-SPA? Откройте исходный код своей страницы (Ctrl+U). Если там что-то вроде:

<html>  <head>    <title>Моя мастерская</title>  </head>  <body>    <div id="root"></div>    <script src="/assets/index-BfQx3.js"></script>  </body></html>

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

Как с JavaScript у Google и Яндекса

Интернет полон устаревших страшилок в духе «поисковики вообще не видят JavaScript», поэтому дальше по фактам.

Google исполнять JavaScript умеет. С 2019 года Googlebot использует свежий headless Chromium и рендерит страницы. Но делает это в два захода: сначала забирает сырой HTML, а рендеринг ставит в отдельную очередь. Сама очередь, по словам Google, давно быстрая: медианное время около пяти секунд. Проблема в другом. Рендеринг сжирает краулинговый бюджет, а стоит скрипту упасть, API не ответить или странице отдаваться слишком долго, как в индекс уезжает пустая страница. Независимые замеры (Onely) при этом показывали, что заметная часть JS-контента так и остается вне индекса спустя недели после публикации. То есть SPA у Google индексируется, но медленнее, дороже и с рисками. Для свежего сайта без ссылочной массы это лотерея.

У Яндекса все осторожнее. В Вебмастере есть бета-функция «Рендеринг страниц JavaScript»: по умолчанию робот сам решает, исполнять ли скрипты, а владелец может это принудительно включить или запретить. При этом сам Яндекс прямо рекомендует запрещать рендеринг, если на сайте реализован SSR или пререндеринг. Читай между строк: «лучше просто отдайте нам готовый HTML». На практике SEO-специалисты стабильно жалуются, что индексация JS-сайтов Яндексом нестабильна.

Итого: SSR и SSG дают видимость с первого захода робота, SPA — лишь надежду, что рендеринг пройдет без сбоев и не затянется.

Почему нейронки лепят именно SPA

Потому что это самый легкий и растиражированный паттерн. Связка React + Vite описана на гитхабе миллионы раз, у моделей горы обучающих примеров, шаблон разворачивается за секунды и красиво выглядит в превью. А сервисы-конструкторы, работающие поверх ужатых моделей, тем более не будут городить серверный рендеринг: их задача быстро и дешево показать красивый результат.

Добавьте сюда то, что нейронки регулярно забывают про мета-теги или вписывают в description откровенную дичь, и получите сайт, который отлично выглядит для человека и абсолютно пуст для машины. Пресные ИИ-тексты, которым не веришь, и которые все равно переписываешь руками, — отдельная больная тема, как-нибудь напишу про нее.

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

ИИ-поисковики: здесь еще жёстче

Отдельная история: оптимизация под ИИ-поиск. Все больше людей вместо Google открывают ChatGPT или Perplexity и просят «найди мне такие-то сайты».

И вот тут SPA получает контрольный выстрел. Совместное исследование Vercel и MERJ проанализировало трафик ИИ-краулеров на сотнях миллионов запросов и показало, что почти никто из крупных ИИ-краулеров не исполняет JavaScript. GPTBot (OpenAI) скачивает JS-файлы примерно в 11,5% случаев, ClaudeBot (Anthropic) почти в 24%, но не запускает их никогда: скрипты читаются как текст для обучения, а не выполняются как код. То же с PerplexityBot, ботами Meta и ByteDance. Исключений два: Gemini, который живет на инфраструктуре Googlebot с ее рендерингом, и Applebot, у которого свой браузерный краулер, честно исполняющий скрипты.

При этом трафик ботов уже огромен: по данным Vercel, GPTBot делал 569 млн запросов в месяц только по их сети, ClaudeBot — 370 млн, а суммарно ИИ-краулеры добрали почти до трети объема Googlebot. Это цифры конца 2024 года, и с тех пор трафик только рос.

На практике это значит вот что. Если сайт — SPA, ИИ-поисковик видит буквально пустую страницу. В лучшем случае он скажет «есть такой сайт», без цен и преимуществ. В худшем молча опустит вас в самый низ приоритета и отдаст лида конкуренту, у которого контент лежит в честном HTML.

llms.txt: карта сайта для нейросетей

Помимо захода на сами страницы, для ИИ придумали отдельный формат подсказок: llms.txt. Это предложение Джереми Ховарда (сооснователь Answer.AI и fast.ai) от сентября 2024 года. Логика такая: у LLM ограниченное контекстное окно и нет желания продираться сквозь HTML с навигацией, рекламой и скриптами. Поэтому кладем в корень сайта markdown-файл, который простым текстом объясняет, что здесь находится. Этакий sitemap для нейросетей.

Структура по спецификации:

# Название проекта> Один абзац: кто вы и что делаете. Единственная обязательная часть.Пара уточняющих абзацев при необходимости.## Основные разделы- [Услуги](https://site.ru/services): что делаем и сколько стоит- [О нас](https://site.ru/about): кто мы такие## Optional- [Блог](https://site.ru/blog): второстепенные материалы

Есть и расширенная версия, llms-full.txt, куда выгружается весь контент сайта одним большим документом (чаще всего так делают с документацией).

Пока все это скорее не работает. Джон Мюллер из Google прямо писал, что ни одна ИИ-система сейчас не использует llms.txt, и сравнивал его с давно мертвым мета-тегом keywords. Ahrefs проверили 137 тысяч доменов: файл завели 28% из них (выборка у Ahrefs смещена в сторону технарей, по всему вебу доля наверняка ниже), но у 97% этих файлов не было вообще ни одного запроса за месяц наблюдений. Их просто никто не читает, ни боты, ни люди. Google официально включил llms.txt в список тактик, которые не влияют ни на выдачу, ни на ИИ-фичи поиска.

Есть нюансы. Файл у себя публикуют Anthropic, Cloudflare, Stripe и куча других серьезных компаний, как дешевую ставку на будущее. Уже сейчас у него есть рабочая ниша: документация для ИИ-инструментов разработки, редакторы вроде Cursor охотно едят llms.txt доков, а платформы вроде Mintlify генерируют его автоматически. И стоит он ноль рублей и десять минут времени.

Так что поставить можно и, пожалуй, стоит. Но llms.txt не заменяет нормальный HTML. Основной механизм у ИИ-поисковиков: прийти по ссылке из обычного поискового индекса и прочитать страницу. Если страница — пустой SPA, никакой текстовый файлик ее не спасет. Нечего читать, нечего и рекомендовать.

Чек-лист

Какой подход для чего

Подход

Что это

Когда брать

SPA

Страница собирается в браузере из JS

Личные кабинеты, дашборды, CRM, админки. Все, что за логином и не должно искаться

SSR

Сервер отдает готовый HTML на каждый запрос

Магазины, каталоги, новостники. Публичный и часто меняющийся контент

SSG

HTML собирается заранее, при сборке проекта

Лендинги, блоги, портфолио, визитки. Идеал для 90% вайб-проектов

База для любого сайта

  • У каждой страницы свой осмысленный <title> и meta description, написанные человеком, а не оставленные на совесть нейронки.

  • Человекочитаемые URL, sitemap.xml, корректный robots.txt (проверьте, что он случайно не блокирует нужных ботов).

  • Open Graph-теги для нормальных превью в мессенджерах и соцсетях.

  • Микроразметка Schema.org: Organization, LocalBusiness, Product, FAQ. Что подходит вашему случаю.

  • Тексты от нейронки переработать руками: пресный ИИ-текст не вызывает доверия ни у людей, ни у алгоритмов.

Если вы на SSR/SSG, правильный путь

  • Просите нейронку прямо в промпте: «сделай на Next.js / Nuxt / Astro с SSR или статической генерацией». Одна формулировка решает все.

  • Проверьте результат: Ctrl+U или curl https://ваш-сайт.ру. Весь ключевой контент (тексты, заголовки, ссылки) должен быть виден в сыром HTML.

  • Мета-теги должны генерироваться на сервере, а не подставляться скриптом после загрузки страницы.

Если очень хочется остаться на SPA

  • Пререндеринг: сервисы вроде Prerender.io или сборка статических снапшотов страниц. Роботу отдается готовый HTML, живым людям SPA.

  • Гибрид: хотя бы главные посадочные страницы вынести в статику или SSR, а SPA оставить для интерактивной части приложения.

  • Смотрите на сайт глазами робота: в Google Search Console это «Проверка URL», затем «Изучить просканированную страницу»; в Яндекс Вебмастере раздел «Рендеринг страниц JavaScript».

  • И помните расклад: у Google JS-контент индексируется дольше и с рисками, Яндекс может не отрендерить вовсе, ИИ-боты (кроме Gemini и Applebot) не отрендерят точно.

Для ИИ-поисковиков

  • Контент в честном HTML. Это правило номер один, все остальное косметика.

  • Не блокируйте в robots.txt поисковых ботов ИИ: OAI-SearchBot и ChatGPT-User (поиск ChatGPT), Claude-SearchBot, PerplexityBot. А вот GPTBot и ClaudeBot краулеры для обучения моделей, пускать их или нет, отдельное осознанное решение владельца.

  • Добавьте llms.txt: дешево, вреда нет, возможно, когда-нибудь выстрелит.

  • Чистая семантика: заголовки h1-h3 по делу, списки, короткие внятные абзацы. ИИ цитирует то, что легко выдернуть из разметки.

Шпаргалка по поисковикам

  • Классика: Google (JS рендерит, очередь быстрая, но индексация JS-контента все равно с задержками и рисками), Яндекс (JS выборочно и в бете, любит готовый HTML), Bing (его индекс к тому же питает поиск ChatGPT).

  • ИИ-поиск: ChatGPT Search, Perplexity, Google AI Overviews / Gemini, Copilot. Из перечисленных JavaScript исполняет только Gemini за счет инфраструктуры Googlebot, остальные читают сырой HTML.

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

Источники

ссылка на оригинал статьи https://habr.com/ru/articles/1062668/