Занимаясь сайтами и SEO уже 20 лет научился отличать «всё готово» от «всё поломано» по первому скриншоту. Но устал разбирать снова и снова сформированный нарратив — от заказчиков, от коллег, от тех, кто только пришёл в веб.
О каких проблемах я говорю?
1. Иллюзия доступности
Вайб‑кодинг продаёт простую идею: тебе не нужно знать код. Тебе не нужно понимать архитектуру. Тебе не нужно проектирование. Ты просто описываешь — и получаешь работающий продукт.
Это правда. Наполовину.
Да, ты получишь работающий прототип. Да, он откроется в браузере. Да, кнопки будут нажиматься. Но открывается в браузере — это единственный критерий, который доступен для проверки человеку без инженерного бэкграунда. И именно на этом критерии строится вся иллюзия качества.
Отдавать сайт в вакууме, а потом ждать, когда в нём появятся гравитация и воздух – типичный вайб‑код.
Вот здесь вступает в силу мой главный тезис, который я повторяю уже 20 лет: Если мы взяли трендовую технологию, платформу, фреймворк, конструктор — у нас будет правильный сайт.
Это убеждение не новое.
В 2005 году оно звучало как WordPress = правильный сайт.
В 2012 — как Tilda = правильный сайт.
В 2018 — как React = правильный сайт.
В 2024 — как Cursor / Claude = правильный сайт.
Каждый раз технология обещала решить проблему качества. Каждый раз она решала проблему скорости. Но скорость ≠ качество.
Вайб‑кодер не может проверить код. Он может только проверить, что сайт открывается. И этого ему достаточно.
А бизнесу — недостаточно.
2. Что именно ломается: SEO‑аудит вайб‑сайта
Давайте посмотрим на конкретные проблемы, которые я вижу в работе. Не теоретические — те, что я нахожу в live‑аудитах сайтов, сделанных вайб‑кодерами.
2.1. Meta‑теги: я не просил — ты не делай
Вайб‑кодер получает промпт: сделай лендинг для юридической компании. Он генерирует HTML. В нём есть заголовок, текст, кнопки, футер.
Но в нём нет meta description. Нет og:title. Нет og:description. Нет canonical. Нет robots. Нет JSON‑LD.
Потому что об этом никто не попросил. И вайб‑кодер не знает, что об этом нужно спросить. Не потому что он глупый. А потому что он не знает, чего не знает.
Разработчик с опытом знает, что каждый тип страницы должен иметь свой набор meta‑тегов и разметки. Вайб‑кодер этого не знает. LLM тоже не знает — если не сказано, она наоборот скажет ты молодец!
Результат: сайт открывается. Все блоки на месте. Но в поиске он выглядит как пустая страница без описания. Без превью в соцсетях. Без понимания для поисковика, о чём эта страница.
2.2. Canonical и дубли: ну они же одинаковые
Вайб‑кодер генерирует сайт с www и без www. С http и без http. С // и без. Каждая комбинация — отдельный URL. Каждая — отдельная страница с одинаковым контентом.
Разработчик знает, что нужен canonical. Что www и non‑www должны редиректиться друг на друга. Что // — это вопрос консистентности. Вайб‑кодер этого не знает.
Результат: поисковик видит четыре URL — четыре версии одной и той же трагикомедии…
2.3. Schema.org: а что это?
JSON‑LD разметка — это не дополнительная опция. Это язык, на котором сайт говорит с поисковиками. Product schema, FAQPage, LocalBusiness, Article — каждый тип страницы должен говорить на этом языке.
Вайб‑кодер не знает про schema.org. Не потому что не хочет — а потому что не знает, что это вообще существует. LLM может добавить, если попросить. Но кто попросит? Заказчик не знает. Вайб‑кодер не предложит.
Результат: сайт есть в поиске. Но без расширенных сниппетов. Без звёзд рейтинга. Без FAQ прямо в выдаче. Без rich results. Конкурент с разметкой забирает весь CTR.
2.4. Кэширование и производительность: работает же
Страница без gzip‑сжатия весит на 30–70% больше. Без кэширования — каждый запрос обрабатывается заново. Без Cache‑Control — сервер тратит ресурсы впустую.
Вайб‑кодер генерирует HTML. Он не настраивает сервер. Он не знает про nginx. Он не знает про CDN. Он не знает про Content‑Encoding.
Результат: сайт открывается. Но медленно. Google Core Web Vitals — красный. Пользователи уходят. Поисковик понижает позиции.
2.5. H1, структура заголовков, иерархия: я вижу заголовок — значит он H1
Вайб‑кодер может поставить h1 один раз на странице. А может — ни разу. Или поставить три. Или вставить h1 внутри JS‑компонента, который curl не видит.
Для поисковика H1 — один из главных сигналов о теме страницы. Для пользователя — ориентир. Для вайб‑кодера — ну там где крупный текст — значит заголовок.
Результат: поисковик не понимает структуру страницы. Пользователь не понимает, что ему читать. SEO‑инструменты показывают нет H1 или несколько H1.
2.6. Внутренние ссылки и навигация: сделай меню
Меню с пятью пунктами — это не навигация. Это декорация. Внутренние ссылки — это то, что распределяет вес страниц, что помогает поисковику понять иерархию, что ведёт пользователя к конверсии.
Вайб‑кодер делает меню. Но не делает внутреннюю перелинковку. Не думает о структуре. Не думает о якорях. Не думает о том, что важная страница должна быть в трёх кликах от главной.
Результат: поисковик не может пройти по сайту. Важные страницы не индексируются. Пользователь теряется.
Список можно продолжать, и да можно было бы решить часть проблем за счёт навыков, вот только никто из вайб‑кодеров даже тестов не делает / смок или мутантное… Они тупо спрашивают — нам нужны тесты? Вот ещё токены / время тратить.
3. Почему заказчик не заметит проблему сразу
Вот здесь начинается самое интересное. И самое печальное.
Никого кроме SEO первые два месяца после подписания актов не интересует, что в интернете висит кривой сайт.
Акты подписаны. Деньги заказчика потрачены. Вайб‑кодер сдал проект. Заказчик открыл сайт — он открывается. Всё хорошо.
Теперь можно начать крутить Директ.
Через два месяца приходит SEO‑специалист (или заказчик нанимает кого‑то, кто наконец посмотрит на поисковую выдачу и панели веб-мастера). И видит:
— Сайт не индексируется.
— Страницы нет в выдаче.
— Те, что есть — на позициях 50+.
— Конкуренты с аналогичным контентом — на первых страницах.
— Нет расширенных сниппетов.
— Нет трафика.
— Нет конверсий.
И заказчик спрашивает: А почему?
Ответ: потому что сайт открывается — но он не работает для бизнеса.
3.1. Ловушка ТЗ
А новые ошибки и проблемы? Этого не было в ТЗ
Это классика. ТЗ на вайб‑кодинг — это промпт. Сделай лендинг для юридической компании. В нём нет ни слова про canonical, про schema, про meta, про robots, про кэширование, про gzip, про внутреннюю перелинковку.
Потому что заказчик не знает, что это нужно. Вайб‑кодер не предлагает. LLM не добавляет без запроса.
И когда через два месяца выясняется, что сайт не работает в поиске — виноват тот, кто не указал это в ТЗ. Не вайб‑кодер. Не LLM. А заказчик.
Да, это несправедливо. Но это так.
3.2. Ловушка я же не программист
Заказчик говорит: Я не программист. Я не могу написать ТЗ про canonical и schema.org. Я плачу за результат — чтобы сайт работал.
Да, но сайт открывается ≠ сайт работает. Сайт может открываться и не работать — не индексироваться, не приносить трафик, не конвертировать.
Проблема в том, что заказчик не может проверить то, что не знает. И вайб‑кодер не обязан объяснять то, о чём не знает, что заказчик не знает.
4. SEO‑проектирование как единственная защита
Так всегда было и будет. Если в процессе работы не было SEO‑проектирования и технадзора.
Это не пессимизм. Это констатация факта за 20 лет.
SEO‑проектирование — это не подкрутить meta‑теги. Это процесс, который начинается до написания первого символа кода.
4.1. Что такое SEO‑проектирование
Это ответы на вопросы: — Какие страницы нужны? — Какие запросы они будут закрывать? — Как они будут связаны между собой? — Какая структура URL? — Какие meta‑теги на каждой странице? — Какая schema.org разметка? — Как будет настроен robots.txt и sitemap? — Как будет настроено кэширование и сжатие?
Эти вопросы должен задать до начала разработки. Не вайб‑кодер. Не LLM. А человек, который понимает, как сайт будет работать в поиске.
4.2. Что такое технадзор в SEO
Это проверка каждого этапа разработки. Не в конце — в процессе.
— Сделали главную — проверили meta, canonical, H1, schema. — Сделали каталог — проверили структуру, перелинковку, фильтры. — Сделали блог — проверили тип контента, schema, дубли. — Выкатили на прод — проверили robots, sitemap, кэширование, gzip.
Технадзор — это не посмотреть, что получилось. Это проверить, что сделано правильно и всё то, что забыли и не предусмотрели.
4.3. Почему вайб‑кодинг несовместим с технадзором
Потому что вайб‑кодер не хочет технадзор. Ему мешают. Технадзор замедляет процесс. А вайб‑кодинг продаёт скорость.
Заказчик, который нанял вайб‑кодера, тоже не хочет технадзор. Он хочет быстро и дёшево. Технадзор — это дополнительные деньги и время (экспертиза).
Но без технадзора — сайт будет кривой. Всегда.
5. Что делать бизнесу
Если ты заказываешь сайт — и не хочешь, чтобы он оказался открывается, но не работает — вот что нужно сделать:
5.1. Найми SEO‑специалиста до начала разработки
Не после. Не через два месяца. До.
Твой SEO‑специалист должен: — Составить структуру сайта. — Определить целевые запросы для каждой страницы. — Написать ТЗ на meta‑теги, canonical, schema. — Определить, какие страницы будут дублями и как их обработать. — Проверить ТЗ на соответствие SEO.
5.2. Требуй технадзор
Не сделай и сдай. А сделай и покажи, я проверю.
Каждый этап — отдельная проверка. Не в конце, а в процессе.
5.3. Не смотри на открывается
Сайт может открываться и быть бесполезным. Открывание — это минимальный порог. Не критерий качества.
5.4. Если уже есть кривой сайт
Не паникуй. Большинство проблем решаются. Canonical, meta, schema, robots, sitemap, кэширование — всё это правится. Но это не задача вайб‑кодера. Это задача SEO‑специалиста + разработчика.
Заключение
Вайб‑кодинг — это не зло. Это инструмент. Как любой инструмент, он хорош, когда им пользуется тот, кто понимает, что делает.
Проблема не в нейросетях. Проблема в том, что вайб‑кодинг создал иллюзию: ты не должен ничего знать. Ты просто опиши — и всё будет хорошо.
Но сайт открывается — это не сайт работает. Это как сказать машина заводится — значит она исправна. Заводится — да. Но тормоза могут не работать.
За 20 лет в SEO я видел, как каждая новая технология обещала решить проблему качества. WordPress, Tilda, React, Vue, Next.js, Cursor, Claude Code. Каждая решала проблему скорости. Ни одна — проблему качества без проектирования и надзора.
Вайб‑кодер — не враг. Вайб‑кодер — индикатор. Он показывает, что бизнесу нужна скорость. И это нормально. Но скорость без качества — это не преимущество. Это долг. И этот долг придётся платить.
Так всегда было. Так и будет. Пока кто‑то не начнёт делать SEO‑проектирование до написания первого символа кода.
ссылка на оригинал статьи https://habr.com/ru/articles/1053804/