Вайбкодинг для SEO-специалиста: как собрать свой инструмент без разработчика

Представьте обычный вторник. Нужно сдать клиенту отчёт по техническому аудиту, и в последний момент выясняется: после миграции на новый шаблон часть страниц могла потерять H1 или превратиться в битые ссылки. В sitemap.xml — три с половиной тысячи URL. Проверять их вручную нереально: открывать каждую страницу и смотреть код ответа браузера — работа на несколько дней, которых до дедлайна просто нет, а переносить сдачу отчёта клиент вряд ли согласится.

Экселевская формула для проверки HTTP-статуса не предусмотрена, макрос на VBA вы писали последний раз в институте, а штатный разработчик занят релизом. У него спринт, бэклог и три фичи в работе, и задача «проверить 3500 ссылок» туда не попадает — даже если решить её можно за полчаса между делом. В лучшем случае ответ придёт через неделю, когда отчёт клиенту уже давно сдан руками, построчно, с парой ошибок от усталости на тысячной строке. А если спросить снова через месяц — выяснится, что разработчик уже переключился на другую задачу, и ваш вопрос опять в самом низу приоритетов.

Знакомая ситуация? Это классический разрыв между «слишком маленькая задача, чтобы ставить её в очередь разработки» и «слишком муторная, чтобы делать её руками в Excel каждый раз заново». Собрать все H1 по списку страниц, найти дубли в списке ключевых слов на десять тысяч строк, сравнить два экспорта позиций и понять, что именно пропало после редизайна, автоматически сгруппировать запросы по кластерам, построить отчёт по каннибализации похожих страниц — таких задач у SEO-специалиста десятки, и ни одна не тянет на отдельный тикет в бэклоге разработки.

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

Термин «вайбкодинг» (vibe coding) в начале 2025 года предложил Андрей Карпаты, один из известных исследователей в области глубокого обучения, и формулировка быстро прижилась — она точно описывает новый способ работы с кодом. Смысл в том, что вы не пишете код сами и не разбираете его построчно. Вы описываете словами, что хотите получить, ИИ-агент — например, Claude Code — пишет рабочий код, а вы проверяете результат так, как проверял бы обычный пользователь любого приложения: запускаете, смотрите, что получилось, пробуете на реальных данных. Например, вы говорите: «собери таблицу всех заголовков H1 по этому списку страниц и отметь, где заголовок пустой или дублируется» — и через пару минут получаете готовый рабочий файл, а не фрагмент кода, который ещё предстоит доработать самостоятельно.

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

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

Важная оговорка: вайбкодинг — это не «не глядя скопировать всё, что написал ИИ, и сразу выкатить в прод». Направлять процесс можно, не умея читать код построчно, — но чётко описать задачу и честно проверить результат вы обязаны сами. Это требует дисциплины не меньшей, чем навык программирования, просто другой: не писать код, а точно формулировать требования и внимательно тестировать то, что получилось — и иногда это оказывается сложнее, чем кажется на первый взгляд.

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

Первая версия скрипта почти никогда не оказывается финальной — и это совершенно нормально, а не признак того, что вы плохо составили промпт. Агент может не учесть, что часть страниц сайта отдаёт код 200 вместо 404 (так называемые мягкие ошибки, soft 404), или что sitemap.xml на самом деле ссылается не на страницы напрямую, а на другие sitemap-файлы (sitemap index), и их тоже нужно сначала обойти. Или вдруг окажется, что часть «битых» ссылок на самом деле защищена авторизацией, а не сломана, — это тоже всплывает только на реальных данных. Вы замечаете это не потому, что читаете код построчно, а потому что смотрите на результат: «вот эти десять страниц точно битые, а в списке их нет — почему?» И формулируете это агенту как обычное человеческое наблюдение, без единого технического термина, если они вам не привычны.

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

Вот как может выглядеть первый промпт для конкретной задачи из начала статьи — проверки sitemap на битые ссылки и редиректы. Такой текст можно скопировать и адаптировать под себя, отправив агенту вроде Claude Code или в чат с любой достаточно мощной моделью:

Напиши скрипт на Python для такой задачи:

1. На вход скрипт получает URL до sitemap.xml (передаётся как аргумент командной строки).
2. Скрипт скачивает sitemap и достаёт из него все адреса из тегов <loc> — это список URL для проверки.
3. Для каждого URL делает HTTP-запрос и смотрит на итоговый статус-код после всех редиректов.
4. Если статус 404 или другая ошибка (4xx/5xx) — записывает URL, статус-код и короткое описание ошибки в отдельный список.
5. Если был редирект (3xx) — отдельно фиксирует исходный URL, итоговый URL после редиректа и промежуточную цепочку, если она длиннее одного шага.
6. По завершении сохраняет два CSV-файла: errors.csv (битые ссылки) и redirects.csv (редиректы), с понятными заголовками столбцов.
7. Выводит в консоль короткую сводку: сколько URL проверено всего, сколько ошибок, сколько редиректов.

Требования:
- Используй библиотеку requests, обрабатывай таймауты и сетевые ошибки — если URL не ответил за 10 секунд, засчитывай это как ошибку, не ломая весь скрипт.
- Делай паузу 0.5-1 секунда между запросами, чтобы не перегружать сайт.
- Добавь прогресс в консоли — сколько URL уже проверено из скольких.
- В начале файла напиши короткий комментарий с примером команды запуска, с указанием пути к sitemap.xml.

После первого запуска не доверяйте результату вслепую — прогоните скрипт на небольшой выборке, например на 50 URL из своего реального sitemap, и сверьте несколько строк руками: откройте битую ссылку в браузере и убедитесь, что она действительно отдаёт 404, а не что-то с временным сетевым сбоем. Обратите внимание и на редиректы: иногда страница технически отвечает кодом 200, но после нескольких хопов ведёт совсем не туда, куда задумано, — это тоже стоит проверить глазами хотя бы выборочно. Если всё сходится, смело прогоняйте скрипт на полном списке — хоть на те же три с половиной тысячи URL из примера в начале статьи.

Мы не говорим это абстрактно: сама SEO Control во многом собрана именно так — в постоянном диалоге с ИИ-агентом, где каждый шаг тестирует и принимает живой человек. Конкретный пример — прямо перед вами. Система публикации статей, в которой написан этот текст, со схемой блоков (параграф, список, таблица, цитата, код с кнопкой «скопировать», диаграмма, блок вопросов-ответов), не была готовым шаблоном из коробки. Её описали словами, получили рабочую структуру, протестировали на реальном тексте, обнаружили, чего не хватает — например, варианта диаграммы для циклических процессов, который понадобился именно для этой статьи, — и доработали тем же способом. Каждую новую возможность — скажем, ту самую кнопку «скопировать» рядом с блоком кода — сначала описывали словами, а затем проверяли: копируется ли текст целиком, не ломается ли форматирование, работает ли кнопка одинаково в обеих языковых версиях.

Это не значит, что весь продукт написан вайбкодингом без единой строчки, написанной вручную, и не значит, что сложную multi-tenant SaaS-систему можно просто «наговорить» за вечер. Но значительная часть видимых пользователю узлов — включая отдельные части AI Control, продукта, который отслеживает, как бренд и конкуренты упоминаются в ответах ChatGPT, Perplexity, Copilot, Gemini и Google AI, — прошла именно через этот цикл: описать задачу, получить код, проверить его как обычный пользователь, описать, что не так, повторить столько раз, сколько потребовалось.

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

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

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

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

Вайбкодинг — не единственный способ закрыть разрыв между «слишком маленькая задача для разработчика» и «слишком муторная задача для Excel». У SEO-специалиста обычно есть ещё два пути: готовый no-code конструктор (сервисы с визуальными сценариями и готовыми шаблонами) и классический найм разработчика — штатного или на фрилансе. Иногда к этим двум добавляется и третий вариант — отдать задачу фрилансеру-аналитику, который сам напишет нужный скрипт, но по сути это тот же найм разработчика, только разовый и без оформления в штат. Все варианты рабочие, вопрос в том, что важнее для конкретной задачи: скорость, гибкость, стоимость или то, кто и как будет поддерживать результат дальше.

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

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

• Установите один ИИ-агент для кода (например, Claude Code) и попробуйте его на тестовом проекте, а не сразу на боевых данных клиента.
• Выберите для первой попытки маленькую, понятную задачу с чётким результатом — например, проверку списка URL на 404 или сбор всех H1 по sitemap.
• Опишите задачу агенту так, как объяснили бы стажёру: что на входе, что должно получиться на выходе, какие есть ограничения.
• Запустите результат на небольшой выборке и сверьте вручную хотя бы несколько строк, прежде чем доверять скрипту весь список.
• Сохраните рабочий скрипт и промпт, который его породил, — в следующий раз вы просто попросите агента доработать существующий код, а не начнёте с нуля.