Я сделал сайт с помощью Claude Code (вместо Tilda, WordPress и ChatGPT), SEO оптимизация и сравнение
Как Claude Code помог полностью переделать сайт с Tilda
Канал с гайдами и контентом по ИИшкам и что с ними можно реализовывать, мы выписываем абсолютно всю базу по ИИ в наш канал и там другие полезные материалы: https://t.me/claudedevolper
Раньше у меня был сайт на Tilda. Дизайнер собирал его на zero-блоках, потому что стандартные шаблоны выглядели слишком скучно и шаблонно. Каждый раз, когда нужно было добавить новый отзыв, блок или страницу, приходилось писать дизайнеру в духе «Привет, добавь это, пожалуйста».Добавлять статьи было чуть удобнее, но тоже далеко не идеально. На WordPress можно просто скопировать материал из Google Docs — и всё вместе с картинками улетает на сайт. На Tilda каждое изображение приходилось загружать вручную. Это быстро начинало бесить.В итоге я понял, что сайт морально устарел и его пора полностью переделывать. Заодно решил сменить платформу — например, переехать на WordPress, к которому я давно привык.Но мне стало интересно: а сможет ли Claude Code самостоятельно сделать полноценный сайт на WordPress? С этим вопросом я к нему и обратился.Claude ответил, что да, в принципе может, но WordPress — это скучно. Гораздо лучше сделать современный сайт на Next.js + headless CMS. На тот момент я даже толком не понимал, что это такое — только слышал краем уха, что на Next.js делают быстрые и удобные проекты. Решил, что будет полезно разобраться и попробовать.
Спойлер: у нас всё получилось. Сайт работает, мне нравится, и даже SEO-трафик после переезда не просел.
Как я строил сайт с Claude Code (рассказываю по шагам)
Расскажу, как всё это происходило на практике.Сразу предупрежу: я не разработчик. Последние 7 лет я управлял контент-агентством, а до этого работал редактором и маркетологом. Полгода назад я увлёкся вайбкодингом, сделал пару кривых, но вполне рабочих сервисов и понял, что нужно разбираться глубже. Не просто кидать задачу в «чёрный ящик» и надеяться, что всё заработает, а хотя бы понимать процесс и управлять им.Вот я и здесь. Понимаю пока довольно поверхностно. Поэтому заранее говорю: в статье могут быть моменты, которые кому-то покажутся максимально наивными или тупыми. Когда-нибудь я сам перечитаю и тоже так подумаю. А пока делаю как умею =)Ладно, хватит предисловий. Давайте уже делать сайт.
Начали с базы знаний (Knowledge base / Memory bank)
Поскольку я слабо ориентируюсь в коде и не могу быстро увидеть ошибку, для меня было критично важно, чтобы Claude Code как можно меньше «тупил» и работал последовательно.Поэтому первые пару часов мы с ним занимались только документацией. Я где-то прочитал про Knowledge base (или Memory bank) — это набор md-файлов с важными знаниями о проекте: архитектура, стек технологий, правила и т.д. В начале каждой новой сессии подсовываешь Claude нужные файлы — и он сразу в теме. В конце сессии просишь обновить документацию.Почему не один большой файл CLAUDE.md, а несколько отдельных?Если засунуть всё в один — он сжирает кучу токенов уже на старте, и модель начинает тупить. Если же выкидывать детали, чтобы сэкономить токены — модель опять тупит, потому что информации не хватает. В итоге у меня получилась такая структура файлов:
- Архитектура — стек технологий, структура папок, почему выбраны именно эти инструменты.
- Паттерны — как называть переменные, как организовывать код, сколько максимум строк в функции (чтобы Claude писал консистентно).
- Деплой — куда и как деплоится сайт, доступы к серверу, Docker-конфиги, CI/CD.
- База данных — как будут храниться данные.
- Git-воркфлоу — правила в стиле «не пушь на main без спроса, всё делай в dev-ветке».
- UX-гайдлайны — цвета, типографика и правило «не придумывай элементы с нуля — бери готовые из shadcn».
- Роадмап — порядок работ, список страниц сайта и т.д.
- Проект — общий контекст: что за сайт, для кого он, какие задачи решает.
Заполняли мы их вместе: я говорил, что хочу, Claude Code всё описывал, я согласовывал и правил, потом сохраняли. Именно на этом этапе мы окончательно решили делать сайт на Next.js + headless CMS, а не на WordPress, как я планировал изначально.Вот небольшой кусочек из моего файла architecture.md (для примера):
Как мы работали с документацией и техзаданиями при создании сайта на Claude Code
Всю документацию мы вели на английском. У него лучше токенизация, чем у русского, поэтому файлы занимают меньше места в контекстном окне модели. Мне это показалось важным с точки зрения экономии токенов. Плюс лишний раз потренировал свой английский.Теперь процесс выглядит так: когда мы берёмся за новую задачу, я сначала кидаю Claude Code нужные файлы из базы знаний. Он их читает — и дальше мы работаем уже с полным пониманием контекста.
Spec driven development — наш главный подход
Ещё одна важная штука, которую я вычитал про вайб-кодинг и разработку в целом: чем детальнее ты опишешь задачу в самом начале, тем выше шанс, что всё сделают нормально и без лишних переделок.Поэтому всю работу над сайтом мы разбили на множество мелких задач. Под каждую пишем отдельный spec — подробное техническое задание. Я объясняю словами, что хочу, Claude Code составляет spec, я его читаю, правлю и согласовываю.Вот примеры задач, которые мы прописали на этапе планирования в Knowledge base:
- Сделать MVP сайта на localhost (чтобы просто открывалась страница с текстом)
- Сделать главную страницу
- Сделать ленту блога
- Сделать шаблон статьи в блоге
- Перенести все статьи со старого сайта
- Добавить тёмную тему
- Настроить деплой main-ветки, привязать домен
И так далее.Когда я говорю: «Давай делать первую задачу, составь по ней spec по шаблону», Claude Code задаёт уточняющие вопросы, при необходимости ищет информацию в интернете и через MCP Context7 пишет готовое техзадание. Я читаю, нахожу непонятные места и прошу объяснить «для тупых» максимально простыми словами. Если вижу дыры в логике — указываю на них. Claude либо доказывает свою правоту, либо соглашается и переделывает.Spec сразу разбивается на атомарные шаги: «в этом файле сделать вот это, потом запустить тесты и проверить, что ничего не сломалось».Вот кусочек техзадания, которое Claude Code написал сам для себя (пример):
А вот пример файла задачи. Spec — это общее описание фичи, которую мы делаем, а внутри у него лежит много отдельных маленьких md-файлов с задачками, которые я скармливаю CC по одной за раз. Опять же, чтобы не забивать ему контекст лишней инфой.
Подготовка занимает 70% всего процесса вайбкодинга с Claude Code
Если честно, вся эта предварительная работа — база знаний, спецификации и планирование — занимает у меня примерно 70% всего времени вайбкодинга. Дальше уже мало что зависит от меня. Claude Code начинает писать код, выполнять команды, а я в этом разбираюсь пока слишком поверхностно, чтобы нормально контролировать процесс в реальном времени.Именно поэтому я стараюсь максимально въедливо отработать этап планирования. Чем лучше проработан план и документация, тем меньше потом будет сюрпризов.Для мелких задачек я не пишу полноценный spec. Просто включаю plan-mode, прошу Claude Code набросать план действий, согласовываю его — и только после этого запускаем работу. Без plan-mode я вообще ничего не делаю: он сильно страхует от типичных «тупняков» модели.
Как выглядит сама разработка сайта с Claude Code
Процесс разработки у меня устроен довольно просто и повторяемо:
- Запускаю новый чат с Claude Code.
- Кидаю ему файл с задачей + ссылки на нужные куски из Knowledge base.
- Claude Code изучает всё, что я прислал, и пишет подробный план действий.
- Я его одобряю (или правлю).
- Начинается работа.
- Я открываю сайт на localhost и смотрю, что получилось.
- Почти всегда с первого раза выходит не то, что нужно, поэтому делаю скриншот, кидаю его в чат и прошу поправить.
И так шаг за шагом закрываем каждую задачку.На каком-то этапе я подключил MCP-сервер с Playwright, чтобы Claude Code мог сам открывать сайт и смотреть результат. Это хорошо помогает при исправлении очевидных багов и технических косяков. Но когда просто «некрасиво» или «не так выглядит» — Playwright не спасает. Приходится делать скриншот и объяснять человеческими словами, что и куда нужно подвинуть.На главную страницу сайта у меня ушёл целый вечер.Я полазил по разным примерам, понял примерное направление, нарисовал простую схему в Figma, скинул её Claude Code и попросил сделать что-то похожее.
Важный момент — мне очень не нравится дизайн, который делают нейронки. Lovable, Gemini, Claude — у всех получается какая-то унылая мазня.
Поэтому я просил CC ничего не изобретать, а просто брать готовые shadcn компоненты. Они уже красивые-аккуратные. Этот совет мне дал сам CC на этапе планирования сайта =)
Сверстали простенькую страницу, а дальше ее «развеселяли». В этот блок давай скриншот добавим, сюда логотипы клиентов, здесь будет вот такая анимация будет и так далее.
Пара часов — и главная полностью готова. В этот момент я уже был в восторге, потому что никакой подрядчик ни разу в жизни не делал мне ничего так быстро. Там счет идет на дни и недели, а тут мы с нейронкой за вечер управились. Причем большая часть вечера — это планирование.
Ссылку на сайт давать не буду, знаю, что модерация это не очень любит. Покажу скриншот. Кому интересно, тот загуглит остальное.
Что получилось в итоге и как прошёл перенос контента
Мне очень понравился результат. Получился простой минималистичный дизайн, сайт грузится мгновенно. А самое приятное — редактировать что угодно теперь можно обычными сообщениями в чате с Claude Code. Никаких zero-блоков, админок и ручной верстки.Конечно, не всегда всё получается идеально с первого раза. Иногда Claude делает хорошо сразу, иногда приходится поправлять 2–3 раза. Но даже с правками это невероятно быстро — особенно если учесть, что я не разработчик, не верстальщик, не дизайнер и до этого вообще не знал Next.js. Всё делал по советам из интернета и подсказкам модели.Ещё один полный день ушёл на перенос остальных страниц, ленты блога и всех статей.Кстати, про перенос контента получилась очень показательная история.Раньше на одном из проектов мы переезжали с Tilda на WordPress. Человек вручную переносил все статьи несколько дней: копировал текст, загружал картинки, расставлял их по местам.Claude Code сделал это за 15 минут. Я просто дал ему sitemap старого сайта. Он сам его распарсил, вытащил все статьи, разбил их на отдельные MDX-файлы, скачал изображения и разложил по правильным папкам проекта.Конечно, не обошлось без мелких косяков: некоторые картинки задублировались, а в отдельных статьях остались ссылки на старый CDN Tilda вместо локальных копий. Но эти проблемы были элементарными — мы их закрыли ещё за полчаса.В итоге весь перенос блога занял примерно час.
Последний день ушел на полировку. Я попросил CC изучить весь код сайта, найти там возможные косяки, уязвимости, неиспользуемые функции. Ну и потом отрефакторить все.
Потом провел такой же аудит по SEO. Claude сам предложил, что надо сделать, добавил robots.txt, сделал sitemap, метатеги и opengraph на всех страницах. Подключили Метрику, Вебмастер и вот это все.
В конце прогнал сайт через PageSpeed Insights, скопировал все его рекомендации и попросил CC доделать.
Результаты неплохие. У старого сайта производительность была в районе 70.
Отказ от Payload CMS: почему админка оказалась не нужна
А теперь самое интересное.По первоначальному плану у сайта должна была быть полноценная админка на Payload CMS. Однако ещё в самом начале Claude Code не смог её нормально установить — постоянно вылезали ошибки. Я решил отложить эту задачу на потом: вдруг сайт вообще не получится и админка не понадобится.Спустя три дня активной разработки я понял неожиданную вещь: админка мне вообще не нужна.Зачем она, если практически любые изменения на сайте может сделать сам Claude Code?
- «Добавь новый отзыв» → добавил
- «Опубликуй эту статью в блог» → опубликовал
- «Поменяй текст на главной» → поменял
- «Измени цвет кнопки» → изменил
- «Обнови description статьи» → обновил
Всё это он делает быстро, с первого-второго раза и практически без багов. Благодаря хорошо проработанной Knowledge base модель точно знает, где и как хранятся статьи, изображения, отзывы и другие данные.Мы с Claude обсудили это и решили полностью отказаться от CMS. Удалили Payload и забыли о нём.Кстати, весь процесс разработки проходил на латвийском VPS. Я подключаюсь к нему по SSH без всяких VPN — очень удобно. А если нужно срочно что-то поправить в дороге, захожу через приложение Termius прямо с телефона.
Что в итоге: 3 дня и полностью новый сайт
На весь проект ушло ровно три дня:
- День 1 — планирование, документация и главная страница
- День 2 — остальные страницы, блог и перенос статей
- День 3 — шлифовка, SEO, исправление багов и перенос на боевой домен
Для сравнения: десять лет назад мой первый сайт на WordPress тоже занял около трёх дней. Только тогда получился унылый кривой сайт, которым я сам был недоволен. А сейчас результат мне действительно нравится — и по внешнему виду, и по скорости работы.Важный плюс: SEO-трафик после переезда вообще не просел. Переезд прошёл чисто, без технических потерь.За эти три дня я узнал кучу нового: наконец-то разобрался, что такое Next.js, shadcn и современная фронтенд-разработка.Теперь любые изменения на сайте я делаю через Claude Code. Просто пишу, что нужно, он вносит правки. Я проверяю результат на localhost, и если всё нормально — прошу запушить изменения в main. После этого сайт автоматически обновляется через Docker.Ещё один большой бонус — теперь сайт полностью мой. Я никак не завишу от Tilda. Даже если с текущим VPS что-то случится, весь код лежит на GitHub. Перенёс репозиторий на другой сервер — и сайт снова работает.