Что такое вайбкодинг и откуда взялся термин
Вайбкодинг (от английского vibe coding, пишут и «вайб-кодинг») — способ разработки, при котором человек описывает задачу обычным языком, а программный код генерирует нейросеть. Слово придумал исследователь ИИ Андрей Карпатый в посте в начале февраля 2025 года. Его версия радикальна: полностью отдаться «вайбу» и забыть, что код вообще существует. Правки модели он принимал не читая, сообщения об ошибках вставлял в чат без комментариев, а баг, который не чинился, просто обходил.
В том же посте есть оговорка, которую пересказы часто опускают: для одноразовых проектов на выходные такой подход, по его словам, сойдёт (в оригинале — «not too bad for throwaway weekend projects»). В исходном смысле вайбкодинг — для проектов, которые не жалко выбросить, а не для сайта, который годами приводит клиентов из поиска.
По строгому определению моя работа — не совсем вайбкодинг. Код за меня генерирует ИИ-агент, чаще всего Claude Code. Но что делать, решаю я, а правки принимаю не на глаз, а после замеров. Для сайта, который должен быть виден в поиске, именно эта разница и важна.
Чем кодинг-агент отличается от конструктора «сайт за минуту»
Конструктор с нейросетью собирает сайт из своих блоков и держит у себя, а кодинг-агент пишет обычный код сайта, который остаётся у вас. Кодинг-агентом называют инструмент, который работает в папке проекта: читает код, правит файлы и запускает команды. Так описан и Claude Code в собственной документации.
| Конструктор с ИИ | Кодинг-агент | |
|---|---|---|
| Что получается | Блоки платформы, правки — в её редакторе | HTML, CSS, JavaScript, PHP — обычный исходный код проекта |
| Где живёт сайт | На платформе: закроется сервис — сайт придётся пересобирать | На вашем хостинге, переносится на любой другой |
| Что можно поменять для SEO | Что разрешает платформа; адреса, robots.txt и микроразметка доступны не везде | Всё: адреса, перенаправления, шаблоны, микроразметку, коды ответа |
| Кто отвечает за техническую часть | Платформа: обновления, безопасность, хостинг | Вы или разработчик, который ведёт сайт |
| Когда удобнее | Простой лендинг или визитка, которую нужно запустить сегодня | Сайт под задачу, переезд с другой CMS, проект, который будет расти |
У конструктора честное преимущество: техническую часть держит платформа, и сломать её труднее. Обратная сторона свободы агента — сломать можно всё, включая видимое поисковику.
Что можно сделать с ИИ: новый сайт и переезд
Оба варианта — новый сайт с нуля и переезд готового на новую основу — я делал с кодинг-агентом. Новый сайт услуг агент собрал без CMS: PHP-шаблоны, без сборки и внешних зависимостей.
Переезд был на другом, уже работающем сайте: 26 сентября 2026 года его за один день перевели с WordPress на код без CMS. До переезда я снял эталон — исходный код всех 119 адресов живого сайта. После переезда приёмка запросила все адреса уже нового сайта прямо с сервера и сравнила ответы с эталоном:
- 116 страниц, 0 расхождений в title, description, canonical (указании основного адреса), robots, разметке Open Graph для соцсетей, наборе микроразметки JSON-LD, H1, числе ссылок и тексте, причём совпадение побуквенное;
- в карте сайта 115 адресов с прежними датами изменения (lastmod);
- зеркала с http и www и адреса без слеша на конце отдают перенаправление 301, служебные каталоги закрыты;
- вёрстка сверена по размерам: высота главной до и после одинаковая — 17 190 px.
Дня хватило потому, что шаблоны почти не зависели от WordPress: вызовов его функций было около 1 680, и 1 625 из них приходились на шесть функций. Переписывать 104 шаблона я не стал, а сделал слой совместимости — код, который подменяет вызовы WordPress. После переезда WordPress удалён полностью, папка сайта на хостинге уменьшилась примерно с 350 до 23 МБ. Перед удалением я проверил бэкап распаковкой.
Почему поисковик видит результат, а не код
Поисковому роботу всё равно, кто создавал код: он получает ответ на запрос, читает HTML и при необходимости выполняет скрипты. Сайты на JavaScript Google обрабатывает в три этапа — обход, отрисовка и индексирование. Адреса с кодом 200 встают в очередь на отрисовку, её выполняет Chromium без интерфейса, и в индекс идёт уже отрисованный вариант.
У Яндекса выполнение JavaScript по умолчанию «на усмотрение робота»: он сам решает, рендерить ли документ, и может сравнить полноту страницы со скриптами и без них. Если у сайта есть серверная отрисовка, справка Вебмастера советует рендеринг запретить. Надёжнее всего, когда содержимое, заголовки и ссылки есть уже в исходном коде, а не появляются после работы скрипта: тогда не важно, станет ли робот выполнять скрипты.
Где ломается SEO при вайбкодинге: шесть случаев
На новом сайте услуг из раздела выше SEO ломалось в шести местах: вес шрифтов, копии адресов, пример конфигурации, отрисовка, параметры от тестов и даты в микроразметке. Все поломки нашлись замерами, а не глазами, и почти каждая снаружи выглядела как «всё работает». Все шесть случаев пришлись на октябрь 2026 года.
| Когда | Что сломалось | Как лечится |
|---|---|---|
| 04.10.2026 | Шрифты грузились по четыре раза: 28 файлов на 994 КБ вместо 8 уникальных на 292 КБ — генератор сохранил один вариативный шрифт (все начертания сразу) под разными именами | Убрать копии и оставить 8 уникальных файлов: главная стала весить 606 КБ вместо ≈850 КБ |
| 04.10.2026 | Адреса вида /razdel/index.php отдавали код 200 и были копиями: перенаправление было только для корня сайта | Перенаправление 301 на основной адрес |
| 04.10.2026 | Служебный пример конфигурации исполнялся на живом сайте | Закрыт правилом сервера |
| 09–10.10.2026 | На английской версии текст блока — белый по мятному фону, контраст 1,07, его не видно совсем; на двух страницах слиплись абзацы | Цвет текста, контрастный фону, и отступы между абзацами; найти помог замер контраста в браузере |
| 10.10 → 26.10.2026 | Браузерные тесты открывали URL с параметром против кэша, и эти адреса попали к роботу Яндекса — 16 английских дублей в поиске | Директива Clean-param в robots.txt |
| 14.10.2026 | Поле dateModified в микроразметке бралось из времени выкладки: весь сайт разом «обновлялся» | Явная дата правки вместо даты файла |
Замер 04.10.2026
Увеличить
Зелёная приёмка и невидимый текст
Зелёная приёмка кода не значит, что надписи видно. На английской версии сайта приёмка по HTML дала 57 «зелёных» проверок из 57, а надпись одного блока при этом была белой по мятному фону с контрастом 1,07; стандарт доступности WCAG требует для обычного текста не меньше 4,5:1. Приёмка смотрела разметку, а не отрисовку, поэтому ничего не заметила. Поймал это замер в браузере: контраст каждой надписи к фону, который под ним на самом деле.
Для поиска это важно: Яндекс прямо называет страницы с невидимым или слабовидимым текстом среди примеров, к которым алгоритмы могут применить ограничения, а в правилах Google о спаме первый пример скрытого текста — белый на белом фоне. Спамом Google считает скрытие ради манипуляции. Умысла там не было, но выяснять на своём сайте, как алгоритм отличит ошибку вёрстки от умысла, не стоит.
Тесты сами создают адреса
Браузерные тесты открывали адреса с хвостом ?cb=…, чтобы обойти кэш. Счётчик аналитики передал эти адреса роботу Яндекса: в справке Вебмастера счётчик Метрики прямо назван одним из источников, из которых робот узнаёт о страницах сайта. В итоге 16 дублей английских адресов попали в поиск, а нашлись они только через 16 дней.
Часть служебных параметров — utm-метки, ysclid — Яндекс может отбросить сам, но параметра тестов в этом списке не было. Лечение — директива Clean-param в robots.txt: она сообщает роботу Яндекса, что параметр не меняет содержимое. Google её не читает — в robots.txt он поддерживает только user-agent, allow, disallow и sitemap, — для него основной адрес подсказывает rel="canonical".
Дата обновления, которая врёт
Самая незаметная поломка: поле dateModified в микроразметке бралось из даты файла. Каждая выкладка обновляет эту дату, и весь сайт разом становился «обновлённым» — ложный сигнал свежести. Лечение — задавать дату правки у статей явно, а у остальных разделов сайта это поле убрать. По документации Google даты в микроразметке должны описывать публикацию или обновление документа, а lastmod в карте сайта — последнюю существенную правку; смена года в копирайте к таким не относится.
Что Google и Яндекс говорят о сайтах, сделанных с ИИ
Ни Google, ни Яндекс не запрещают делать сайт с помощью ИИ: оба оценивают итог. Google с 2023 года формулирует это прямо: важно качество контента, а не инструмент, которым он сделан, и уместное использование ИИ или автоматизации его правил не нарушает. Нарушение — автоматизация, нужная прежде всего для манипуляции ранжированием, а генерация множества страниц без пользы для читателя может подпасть под правило о массовом создании контента.
Для вайбкодинга важна деталь из руководства Google по генеративному контенту: всё, что создал ИИ, нужно вручную проверить на точность до публикации, причём не только статьи, но и title, description, микроразметку и alt у картинок. При сборке сайта агент генерирует всё это вместе с кодом — значит, и принимать это нужно вместе с кодом.
Яндекс в справке Вебмастера приводит среди примеров, к которым алгоритмы могут применить ограничения, сайты с автоматически сгенерированным и бесполезным для пользователя контентом.
В описании нарушения о малополезном контенте нейросети названы прямо: «Нередко такой контент создается с помощью нейросетей, машинного перевода или шаблонных методик». Признак нарушения — контент, который выглядит сгенерированным или не несёт пользы, а нейросеть — лишь частый способ его получить. Отдельных требований к сайтам, чей код создал ИИ, я не нашёл ни у Google, ни у Яндекса. Технический минимум Google один для всех: робот не заблокирован, адрес отдаёт код 200 и на нём есть индексируемый контент.
Чек-лист проверки сайта, сделанного с ИИ, перед запуском
В списке — пункты из разобранных выше поломок и минимум из документации Google и Яндекса; каждый закрывается запросом или замером, а не взглядом. Пройдите его до того, как откроете сайт для индексации, или впишите в задание исполнителю.
Коды ответа и адреса
- Каждая страница отдаёт 200, несуществующий адрес — 404, а не главную и не пустую заглушку с кодом 200.
- Зеркала с http и www, адреса без слеша и копии вида /index.php ведут перенаправлением 301 на один основной адрес.
- Служебные адреса, примеры конфигурации и тестовые разделы закрыты, а не исполняются.
- С тестовой копии сайта (стенда) сняты временные запреты — Disallow для всех роботов и noindex; Google отдельно напоминает об этом в руководстве по переезду сайта.
Исходный код
- У каждого адреса свои title и description, один H1, canonical указывает на нужный URL, случайного noindex нет.
- Содержимое, заголовки и ссылки есть в исходном HTML, без выполнения JavaScript.
- Микроразметка проходит валидатор и не противоречит видимому тексту.
- dateModified и lastmod в карте сайта меняются только при реальной правке.
- Для параметров, которые не меняют содержимое, есть Clean-param — включая параметры собственных тестов.
- robots.txt открывает сайт нужным роботам; отдельный файл для нейросетей не обязателен — в логах трёх сайтов ИИ-боты llms.txt не запрашивали.
Отрисовка
- Контраст надписей к фактическому фону не ниже 4,5:1 для обычного шрифта; мерить у каждого блока, включая другие языковые версии.
- На ширине мобильного экрана нет горизонтальной прокрутки, абзацы не слиплись, между ними есть отступы.
- В списке загружаемых ресурсов нет повторов шрифтов и картинок под разными именами. Для скорости у Google есть ориентир: LCP — время, за которое появляется самый крупный блок первого экрана, — в пределах 2,5 секунды.
Если сайт переезжает
- До переезда снят эталон: исходный код всех адресов живого сайта.
- После — сверка с эталоном по title, description, canonical, robots, микроразметке, H1, ссылкам и содержимому, а не выборочный просмотр.
- Старую систему удаляют, только когда бэкап успешно распакован.
Кому подходит вайбкодинг сайта, а где сильнее команда разработки
Вайбкодинг с замерами хорошо подходит для сайта услуг, лендинга, блога, небольшого каталога и для переезда такого проекта со старой CMS. Хуже — для сложных проектов, где цена ошибки — не позиции, а деньги и данные: приём оплаты, хранение персональных данных клиентов, интеграция с 1С или CRM, высокая нагрузка. Для них сильнее команда разработки, где код проверяют коллеги и есть тестирование.
Если сайт с ИИ уже сделан, начать стоит с технического аудита: индексацию, дубли и скорость загрузки я проверяю на всех страницах, а не на выборке. Если нужен новый сайт или доработка готового, это моя услуга разработки и доработки сайта с ИИ. Как я вношу правки на работающих сайтах и чем подстрахована каждая выкладка — в разделе о контроле до и после выкладки.
