# tema.name — full content index for LLMs > This is the full-content index of all blog articles on tema.name, formatted for direct LLM ingestion (ChatGPT, Claude, Perplexity, Gemini). Each article includes YAML frontmatter (title, URL, language, dates, description, keywords) followed by the full body in Markdown format. Generated: 2026-05-24. Site author: Artem (Russian/English/German/Polish). Contact: https://t.me/tstels1 — see /about pages for full E-E-A-T bio. --- --- title: "Как заказать сайт с AI в 2026: сроки и цена – Артём" url: https://tema.name/blog/kak-zakazat-sayt-s-ai-2026.html language: ru description: "Чем AI-разработка отличается от классической, реальные сроки для лендинга и корпоративного сайта, как формируется цена. Без воды." date_published: 2026-05-21 date_modified: 2026-05-21 tags: ["AI-разработка", "заказать сайт", "Joomla"] --- AI-разработка 21 мая 2026 · 8 мин чтения · Автор: Артём # Как заказать сайт с AI в 2026: подход, сроки, цена Заказать сайт с AI в 2026 значит работать с разработчиком, который использует **Claude, Cursor, ChatGPT** как часть стека — это сокращает сроки на 40–60% и снижает цену на 25–40% против классической разработки. Лендинг: 3–5 рабочих дней, 30–80 тыс. ₽. Корпоративный сайт: 2–3 недели, 80–250 тыс. ₽. Магазин до 1000 SKU: 3–6 недель, 200–500 тыс. ₽. Подход: ТЗ обсуждается голосом, прототип в Figma за 1–2 дня, верстка и интеграции — параллельно. AI пишет 60–70% кода, человек проверяет, рефакторит и отвечает за результат. Главные риски — «AI-фрилансеры» без портфолио и студии, продающие старый процесс по новой цене. В статье — критерии выбора подрядчика, как читать смету, и 6 красных флагов на этапе переговоров. **В этой статье** 1. [Что изменилось в разработке сайтов в 2026](#what-changed) 2. [Какие бывают сайты – и какой нужен именно вам](#types) 3. [Сколько реально занимает разработка](#timeline) 4. [Как формируется цена и от чего зависит](#price) 5. [Что обязательно должно быть в готовом сайте](#whats-inside) 6. [Как выбрать исполнителя и не нарваться](#choose) 7. [Частые вопросы](#faq) ## Что изменилось в разработке сайтов в 2026 Главное отличие сегодняшней разработки от подхода 2020-х – это **AI-pair programming**. Разработчик не пишет код с нуля построчно. Он работает в связке с моделью (Claude, Cursor, ChatGPT): описывает задачу на естественном языке, AI генерирует структуру, разметку, скрипты и даже черновики контента. Разработчик читает каждый блок, проверяет логику, тестирует, отлаживает и собирает финальный продукт. Это не значит, что разработчик «больше не нужен». Наоборот – его роль становится более экспертной: он должен уметь правильно поставить задачу AI, оценить качество выдачи, увидеть, где AI ошибся, и довести проект до рабочего состояния. Если этого слоя нет – сайт получится либо нерабочим, либо красиво выглядящим, но без логики. **Главная мысль:** AI ускоряет разработку в 3-5 раз, но не отменяет необходимости в исполнителе, который отвечает за результат. Вопрос не «человек или AI», а «кто делает финальный QA и берёт ответственность». Для заказчика это означает три практических изменения. **Первое** – сроки сократились в разы. Лендинг, который в студии делали 1.5 месяца, у фрилансера с AI занимает 1-2 недели. **Второе** – цены упали. Та же работа стоит в 3-5 раз дешевле, потому что не нужно содержать команду из 4-6 человек. **Третье** – общение стало проще. Вы говорите напрямую с исполнителем, без менеджеров проектов и недель согласований. ## Какие бывают сайты – и какой нужен именно вам Перед заказом важно понимать формат, который реально решает вашу задачу. Лишний функционал – это лишние деньги и сроки. Недостаточный – впустую потраченный бюджет. ### Лендинг (одностраничный сайт) Когда подходит: одна услуга или один продукт, цель – получить заявку. Например, ремонт квартир под ключ, доставка обедов, частная стоматология. На лендинге всё внимание – на оффере и форме заявки. ### Корпоративный сайт (6-15 страниц) Когда подходит: несколько направлений деятельности, нужно отдельно расписать каждую услугу, добавить команду, кейсы, контакты, страницу «О компании». Например, диджитал-агентство, юридическая фирма, медцентр. ### Контентный сайт с блогом Когда подходит: вы делаете ставку на SEO и хотите регулярно публиковать статьи, привлекая аудиторию из поиска. Например, школа онлайн-обучения, экспертный блог, нишевый журнал. Здесь нужна CMS – чаще всего Joomla или WordPress. ### Интернет-магазин Когда подходит: вы продаёте товары онлайн, нужен каталог с фильтрами, корзина, оплата, личный кабинет. На Joomla это решается компонентами VirtueMart или HikaShop. Для очень больших магазинов (десятки тысяч SKU) часто выгоднее специализированные платформы. **Совет:** не пытайтесь сразу заказать «всё и сразу». Стартуйте с лендинга или мини-сайта, посмотрите на реальный спрос, потом расширяйтесь. Это сэкономит вам бюджет и снимет риск проектировать то, что не понадобится. ## Сколько реально занимает разработка В 2026 году с AI-разработкой реалистичные сроки выглядят так: - **Лендинг:** 1-2 недели от брифа до запуска - **Корпоративный сайт (6-15 страниц):** 2-4 недели - **Контентный сайт с блогом:** от 3 недель - **Каталог с заявкой (без онлайн-оплаты):** 3-5 недель - **Полноценный интернет-магазин:** 4-8 недель - **Telegram-бот для приёма заявок:** 3-5 дней 1. Брифдень 1 2. Прототипдень 3 3. Дизайндень 5 4. Коддень 7-10 5. Запускдень 14 Эти сроки – с учётом того, что вы готовы быстро согласовывать промежуточные результаты. Если на каждый шаг отвечать через 5 дней – проект растянется в 2-3 раза. Поэтому важно заранее обсудить с исполнителем, как часто будут показы и в какие сроки нужны ваши решения. Главная задержка обычно не в коде, а в **контенте**. Если у вас нет готовых текстов, фотографий и описаний услуг – к срокам нужно прибавить время на их подготовку. Хороший исполнитель может помочь с черновиками текстов через AI, но финальное одобрение всё равно остаётся за вами. ## Как формируется цена и от чего зависит Я намеренно не привожу здесь конкретных цифр в рублях или евро – они слишком быстро устаревают и сильно зависят от региона. Но вот рабочая формула, которая поможет ориентироваться в любых ценах: **Цена сайта = (сложность × объём) – фактор AI-ускорения + интеграции** Что влияет на «сложность»: уникальность дизайна (шаблон vs кастом), нестандартная функциональность (калькуляторы, расчёты, личный кабинет), нагрузка (10 посетителей в день или 10 000). Что влияет на «объём»: количество страниц или сценариев бота, сколько текстов нужно адаптировать, сколько форм и интеграций. Что добавляет «интеграции»: подключение CRM (Bitrix24, AmoCRM, Pipedrive, HubSpot), платежных систем, мессенджеров, email-рассылок. Каждая интеграция – дополнительная работа по настройке API и тестированию. **AI-фактор**: если исполнитель работает с AI-инструментами, его цена обычно в 3-5 раз ниже студийной – при том же уровне качества финального продукта. Это не «дешёвка», а другой подход к процессу. **Что НЕ должно быть в смете:** «оплата за каждое слово в тексте», «доплата за мобильную версию» (адаптив – это норма 2026 года, а не опция), «фиксированная плата за каждое обновление контента», «отдельная оплата за SEO-разметку». Если такое встречаете – это попытка увеличить чек на банальностях. ## Что обязательно должно быть в готовом сайте Это базовый чек-лист, по которому можно проверить качество финального продукта. Если чего-то нет – сайт нельзя считать сданным. - **HTTPS**: SSL-сертификат подключён, сайт работает по протоколу https://. В 2026 без этого Google наказывает в выдаче. - **Адаптив**: корректное отображение на мобильных, планшетах и десктопе. Размеры кнопок, читаемость шрифтов, удобство форм. - **Скорость**: PageSpeed Insights – минимум 80 баллов на мобильном и 90+ на десктопе. Если меньше – есть что оптимизировать. - **SEO-разметка**: title, description, заголовки H1-H3, sitemap.xml, robots.txt, разметка Schema.org для нужных типов страниц, hreflang для мультиязычных сайтов. - **Формы с защитой от спама**: honeypot-поле, rate-limit, фильтр по ключевым словам. Заявки приходят в Telegram или email мгновенно. - **Подключённая аналитика**: Яндекс.Метрика с вебвизором, Google Search Console. Видно, откуда приходят клиенты. - **Security-заголовки**: HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy. Это защита от типовых атак. - **Документация и доступы**: вы получаете исходный код, доступы к хостингу, домену, аналитике. Краткая инструкция, как обновлять контент. ## Как выбрать исполнителя и не нарваться Самая частая ошибка заказчика – выбор по «портфолио» без проверки фактов. Красивые скриншоты можно нарисовать, реальное качество видно только в живых проектах. Вот что стоит спросить ДО заказа: 1. **Покажите 2-3 живых проекта, к которым вы имели прямое отношение.** Не «принимал участие», а делал и сдавал. 2. **Какие технологии используете и почему именно их?** Если ответ «работаем со всем, что нужно» – это плохой знак. Хороший исполнитель имеет конкретный стек. 3. **Кто будет лично работать над проектом?** Если это студия, выясните, не будет ли проект передан фрилансеру за половину цены. 4. **Что входит в гарантию?** Стандарт 2026 – 30 дней мелких правок бесплатно, потом по часовой ставке или абонемент. 5. **Кому останутся доступы?** Они должны остаться вам: хостинг, домен, аналитика, исходный код. Если исполнитель «держит сайт у себя» – это форма заложничества. 6. **Используете ли AI в работе?** В 2026 это нормальный вопрос. Если исполнитель скрывает или отрицает – он либо отстаёт от рынка, либо боится, что узнаете об AI и платить не захотите. **Красные флаги:** предоплата 100% до начала работ, отказ показать промежуточные результаты, размытые сроки («как пойдёт»), отсутствие договора или хоть какого-то письменного фиксажа объёма и цены, давление «решайте сегодня, иначе цена вырастет». ## Частые вопросы Можно ли доверить AI разработку сайта целиком? Технически – да, можно сгенерировать код сайта целиком через AI. Но без проверки человеком этого делать нельзя: AI допускает ошибки в логике, иногда придумывает несуществующие методы и не учитывает контекст бизнеса. Правильный подход – AI как ускоритель, человек как контроль качества. Разработчик читает каждый блок, тестирует, отлаживает и отвечает за результат. Сколько реально стоит сайт в 2026 году? Зависит от формата и исполнителя. Лендинг у фрилансера с AI – в 3-5 раз дешевле, чем у студии. Корпоративный сайт – аналогично. Точная цена под ваш проект формируется после короткого брифа. Главное – не цена сама по себе, а соотношение цена/качество и сколько потом стоит поддержка. Какой срок реален для лендинга в 2026? С AI-инструментами лендинг под ключ делается за 1-2 недели: бриф, прототип, дизайн, вёрстка, формы, аналитика, запуск. У классической студии те же работы занимают 4-6 недель – из-за многоступенчатых согласований внутри команды. Что должно быть в готовом сайте обязательно? Минимум: HTTPS, адаптив, формы с защитой от спама, аналитика (Яндекс.Метрика и Google Search Console), SEO-разметка (title, description, sitemap.xml, robots.txt, Schema.org), быстрая загрузка (PageSpeed 90+) и понятная инструкция по обновлению контента. Без этого сайт – не инструмент, а декорация. На что обращать внимание при выборе исполнителя? Спросите: что входит в смету, какие сроки и зависят ли они от вашей готовности контента, кто будет лично делать проект, какие технологии используются, есть ли поддержка после сдачи, кому останутся доступы к сайту и аналитике. Если исполнитель уклоняется или говорит «вам это не нужно знать» – ищите другого. --- --- title: "Joomla vs WordPress vs статика 2026 – какой стек выбрать" url: https://tema.name/blog/joomla-vs-wordpress-vs-statika-2026.html language: ru description: "Сравнение по скорости, безопасности, гибкости и стоимости поддержки. 5 типовых сценариев и таблица выбора стека под задачу." date_published: 2026-05-22 date_modified: 2026-05-22 tags: ["Joomla", "WordPress", "статический сайт"] --- Выбор стека 22 мая 2026 · 10 мин чтения · Автор: Артём # Joomla vs WordPress vs статика в 2026: какой стек выбрать Короткий ответ: **WordPress** — для блогов, новостников и простых корпоративов, где правят редакторы (60% рынка, экосистема плагинов, но 4–6 обновлений безопасности в месяц). **Joomla** — для каталогов, b2b и многоязычных сайтов с тонкими правами доступа (мультиязычность из коробки, ACL на 9 уровней, обновления раз в 2–3 месяца). **Статика** (Astro, Eleventy, Hugo) — для лендингов, документации и портфолио, где нужны 95–100 PageSpeed, нулевая стоимость хостинга (CDN от 0 ₽) и максимальная безопасность. Сроки запуска: статика 2–5 дней, WP 1–3 недели, Joomla 2–4 недели. Стоимость поддержки в год: статика 0–5 тыс. ₽, WP 15–40 тыс. ₽, Joomla 10–25 тыс. ₽. В статье — таблица сравнения по 12 параметрам и привязка к типам задач. **В статье** 1. [Короткий ответ для нетерпеливых](#tldr) 2. [Joomla – для кого и зачем](#joomla) 3. [WordPress – для кого и зачем](#wordpress) 4. [Статика – для кого и зачем](#static) 5. [Сравнение по 7 параметрам](#compare) 6. [5 сценариев: что выбрать](#scenarios) 7. [Частые вопросы](#faq) ## Короткий ответ для нетерпеливых Если нужно одним абзацем: **лендинг или мини-сайт без частых правок** – статика, и забыли. **Корпоративный сайт с несколькими ролями редакторов или каталог-с-формой** – Joomla, особенно если важна аккуратная работа с правами и мультиязычность. **Блог-медиа, где новые статьи каждые 1-3 дня и пять авторов**, – WordPress, потому что вокруг него больше всего шаблонов и плагинов под медийные задачи. **Интернет-магазин** – зависит от размера: до 5000 SKU нормально живёт на VirtueMart/HikaShop в Joomla или WooCommerce в WP; десятки тысяч SKU – отдельные платформы. **Главное:** «лучший CMS» не существует. Существует «CMS под задачу». Если подрядчик утверждает обратное и тянет вас на один стек независимо от проекта – это или ограниченность, или попытка продать то, что он умеет делать. 40% сайтов мира работают на WordPress ~1.5% доля Joomla – нишево, но стабильно 96/100 средний PageSpeed для статики 3-5× ускорение разработки с AI-инструментами Скорость загрузки (PageSpeed Mobile) Усреднённая оценка для типовой сборки без премиум-кэширования и CDN Статика96 Joomla 582 WordPress65 Цифры ориентировочные. С агрессивным кэшированием и CDN WordPress подтягивается до 80+, Joomla до 90+, но базовая «голая» сборка ведёт себя именно так. ## Joomla – для кого и зачем Joomla 5 – это зрелая CMS на PHP 8.x. По данным W3Techs, на ней работает порядка 1.5-2% всех CMS-сайтов мира – нишево, но устойчиво. В русскоязычном сегменте её доля исторически выше: много корпоративных и государственных сайтов сделано именно на ней. **Плюсы:** - **Мультиязычность из коробки** – не нужны платные плагины уровня WPML, чтобы запустить версию на 4 языках. - **Гибкая система прав ACL** – можно сделать редактора, который видит только свой раздел и не лезет в чужой. - **Меньше «зоопарка»** – экосистема плагинов меньше, чем у WP, поэтому проще выбрать качественные расширения и труднее напороться на заброшенный плагин. - **Хорошая модель компонентов** – VirtueMart для интернет-магазина, HikaShop для каталога, K2 для контента-с-полями. Каждый компонент закрывает свою задачу. - **Менее популярная цель для ботов** – массовые атаки чаще нацелены на WordPress, потому что его больше. **Минусы:** - Меньше готовых шаблонов и платных тем на маркетплейсах. - Меньше специалистов на рынке – найти подрядчика «как WordPress на каждом углу» сложнее. - Для блог-медиа с большой редакцией экосистема WP удобнее. Я работаю с Joomla давно и продолжаю выбирать её для проектов, где важна аккуратная архитектура и многоязычность. Помогает AI-pair programming: можно быстро дорабатывать шаблоны, писать кастомные модули, делать интеграции с CRM. Подробнее об этом – [в статье про разработку с AI в 2026](/blog/kak-zakazat-sayt-s-ai-2026.html). ## WordPress – для кого и зачем WordPress – самая популярная CMS в мире, на ней работает порядка 40% всех сайтов. Это даёт два эффекта: огромную экосистему и огромную «целевую группу» для атак. **Плюсы:** - **Гигантская экосистема** – тысячи бесплатных и платных тем, плагины под почти любую задачу. - **Удобный визуальный редактор** (Gutenberg, Elementor) – редактору не нужно знать HTML, чтобы добавить новый блок на страницу. - **Доступность специалистов** – найти WP-разработчика проще и дешевле, чем Joomla-разработчика. - **Подходит под блог-медиа** – система ролей и потока публикации заточена под несколько авторов. - **WooCommerce** – самое популярное решение для интернет-магазина на WP, с массой готовых интеграций под платёжки и доставку. **Минусы:** - **Высокая уязвимость при заброшенности** – большая часть взломов происходит из-за необновлённых плагинов. Любая брошенная WP-сборка через год – мишень. - **«Зоопарк плагинов»** – 30+ плагинов в одной сборке: конфликты, тормоза, дублирование функциональности. - **Платные расширения** – мультиязычность (WPML), серьёзная защита форм, SEO-плагины класса «всё включено» – это подписки, которые накапливаются. - **Визуальные конструкторы раздувают код** – Elementor-сайт без оптимизации легко выдаёт PageSpeed 30-40 на мобилке. ## Статика – для кого и зачем Статический сайт – это HTML, CSS и JS файлы, без базы данных и без PHP. На сервере просто отдаются файлы. Современные генераторы (Hugo, Eleventy, Astro, Jamstack-подход) позволяют писать в Markdown и собирать сайт в HTML-папку, которая потом просто заливается на хостинг или CDN. **Плюсы:** - **Максимальная скорость** – нет обработки на сервере, страница приходит готовая. PageSpeed 95-100 нормальная цифра. - **Безопасность** – взламывать нечего: нет admin-панели, нет БД, нет PHP-уязвимостей. - **Минимальный хостинг** – статика хостится почти бесплатно (Netlify, Cloudflare Pages, GitHub Pages, или обычный shared hosting с папкой). - **Не требует обновлений ядра** – нечего обновлять. - **Идеально для лендингов и портфолио** – где правки редкие и контент не меняется ежедневно. **Минусы:** - **Нет admin-панели** – добавление новой страницы требует правки файла или git-коммита. Не каждому клиенту удобно. - **Динамика – отдельно** – формы, комментарии, поиск, корзина – это уже сторонние сервисы или API. - **Большой каталог болезненный** – генерация 50 000 страниц HTML занимает время, ребилд после правок может длиться минуты. - **Не для частых редакторов без техфона** – пять авторов с одновременным доступом «через окошко» – это уже не статика. **Промежуточный вариант:** «headless CMS + статика». Контент редактируется в админке (например, Strapi или Sanity), сайт собирается генератором при изменении. Это даёт скорость статики и удобство админки, но усложняет архитектуру и стоит дороже, чем чистая статика. Не для каждого проекта оправдано. ## Сравнение по 7 параметрам | Параметр | Joomla | WordPress | Статика | | --- | --- | --- | --- | | Скорость загрузки | Средняя, хорошая при минимуме плагинов | Средняя, требует кэширования | Максимальная | | Безопасность | Высокая при регулярных обновлениях | Высокая при обновлениях, но больше атак | Максимальная по архитектуре | | Удобство редактирования контента | Хорошее, аккуратная админка | Отличное, визуальные конструкторы | Только через файлы или git | | Мультиязычность | Из коробки | Платный плагин (WPML) | Зависит от реализации | | Стоимость поддержки | Средняя | Может быть высокой из-за платных плагинов | Минимальная | | Каталог / интернет-магазин | VirtueMart, HikaShop | WooCommerce | Только через внешние сервисы | | Доступность специалистов | Средняя | Очень высокая | Высокая | ## 5 сценариев – что выбрать ### Сценарий 1: лендинг под одну услугу Например, ремонт квартир под ключ или частный стоматолог. Одна страница, форма заявки, аналитика. Правки раз в квартал. **Рекомендация:** статика. Скорость, безопасность, минимальный хостинг. CMS здесь – оверкилл. ### Сценарий 2: корпоративный сайт компании на 10-30 страниц Несколько услуг, команда, кейсы, контакты, новости. Контент обновляется раз в неделю, мультиязычность нужна. **Рекомендация:** Joomla. ACL под разных редакторов, мультиязычность без доплат, аккуратное управление меню и разделами. ### Сценарий 3: блог-медиа с пятью авторами Контент-проект, статьи каждые 1-3 дня, разные категории, рекламные блоки, подписки. Нужен удобный редактор. **Рекомендация:** WordPress. Экосистема, готовые темы для медиа, удобство для не-технарей. ### Сценарий 4: интернет-магазин до 5000 SKU Каталог с фильтрами, корзина, оплата, личный кабинет, акции, доставка. **Рекомендация:** Joomla с VirtueMart/HikaShop или WordPress с WooCommerce. Выбор зависит от того, нужна ли вам мультиязычность (Joomla удобнее) или огромный выбор готовых тем (WP). От 10 000 SKU я бы смотрел в сторону специализированных платформ – Shopify, OpenCart, или кастомное решение. ### Сценарий 5: каталог-с-заявкой (B2B услуги) Список услуг или продуктов с описаниями, фильтрами, формами заявок. Покупка не онлайн – клиент оставляет лид, менеджер связывается. **Рекомендация:** Joomla с HikaShop в режиме «без корзины» или статика с динамическими формами. Полноценный e-commerce здесь избыточен. **Если у вас уже есть сайт** и встал вопрос «может пересесть на другой стек» – сначала разберитесь, какая боль реально мешает. Тормоза? Часто решаются кэшированием и оптимизацией картинок без миграции. Взломы? Решаются обновлениями и аудитом плагинов. Неудобная админка? Может, дело в неправильной настройке прав. Переезд – это 2-4 недели работы и риски с SEO. Сначала диагноз, потом смена платформы. ## Частые вопросы Joomla ещё актуальна в 2026? Да. Joomla 5 – это современная CMS на PHP 8.x с продуманной системой прав, мультиязычностью «из коробки» и менее агрессивной экосистемой, чем у WordPress. На ней удобно делать корпоративные сайты, каталоги, интернет-магазины через VirtueMart или HikaShop. Для медийных проектов с десятком авторов её используют меньше, чем WP, но в задачах «несколько ролей, аккуратные права, нет визуального редактора-комбайна» она часто выигрывает. Что быстрее: статика, Joomla или WordPress? При прочих равных порядок такой: статика → Joomla → WordPress. Статика выигрывает потому, что нет ни базы данных, ни PHP-обработки запроса. Joomla обычно быстрее WordPress из-за более чистого ядра и меньшего количества плагинов в типовой сборке. WordPress можно ускорить кэшированием и CDN, и тогда разница перестаёт быть критичной для лендинга. На крупном каталоге разница уже видна. Можно ли вести блог на статике? Да, через Jamstack-генераторы (Hugo, Eleventy, Astro) или вручную, как сделан этот блог. Преимущество – скорость, безопасность, минимальная стоимость хостинга. Недостаток – для каждой новой статьи нужна правка файлов или git-коммит, не каждому клиенту это удобно. Если статьи редкие и пишутся одним человеком – статика отличный вариант. Если 5 авторов и обновления каждый день – нужен CMS. Какой стек безопаснее? Статика – безопаснее по архитектуре, потому что взламывать почти нечего: нет БД, нет admin-панели, нет PHP. Joomla и WordPress безопасны при условии регулярных обновлений ядра и плагинов. Большая часть взломов CMS – не уязвимости ядра, а заброшенные сайты с плагинами 3-летней давности. Если сайт обновляется – оба варианта надёжны. Я уже на WordPress. Стоит ли переезжать? Только если есть конкретная боль: тормоза при типовой нагрузке, постоянные взломы из-за зоопарка плагинов, неудобная работа с мультиязычностью. Сам факт «WordPress немодный» – не причина. Переезд – это работа на 2-4 недели плюс риски с SEO. Если сайт работает и приносит лиды, лучше вложиться в его оптимизацию, чем в миграцию. --- --- title: "Telegram-боты для бизнеса 2026: запуск за неделю" url: https://tema.name/blog/telegram-boty-dlya-biznesa-2026.html language: ru description: "Какие задачи решают боты, типы ботов, реалистичный 5-дневный план запуска, что влияет на цену, частые ошибки. Практика без воды." date_published: 2026-05-23 date_modified: 2026-05-23 tags: ["Telegram-боты", "автоматизация", "лиды"] --- Telegram-боты 23 мая 2026 · 10 мин чтения · Автор: Артём # Telegram-боты для бизнеса 2026: от идеи до запуска за неделю Telegram-бот для бизнеса в 2026 запускается за **5 рабочих дней** и стоит **40–150 тыс. ₽** в зависимости от логики. Базовый сценарий: приём заявок, FAQ, рассылки сегментам, интеграция с CRM (Bitrix24, AmoCRM) — 40–70 тыс. ₽. Бот с оплатой через Telegram Payments или ЮKassa — +20–30 тыс. ₽. Бот с AI-ответами на базе Claude/GPT и подключённой базой знаний — 100–150 тыс. ₽. Стек: Python (aiogram 3) или Node.js (grammY), хостинг от 200 ₽/мес на VPS либо бесплатно на Cloudflare Workers. Отклик клиенту — 1–3 секунды против 2–4 часов у живого менеджера. Окупаемость на трафике от 500 диалогов в месяц — 1–2 месяца. В статье — реальные сценарии, разбор цен, чек-лист запуска и 5 типовых ошибок. **В статье** 1. [Зачем бизнесу Telegram-бот в 2026](#why) 2. [Типы ботов с реальными примерами](#types) 3. [Запуск за 5 дней: пошагово](#launch) 4. [Что влияет на цену](#price) 5. [7 типовых ошибок](#mistakes) 6. [Частые вопросы](#faq) ## Зачем бизнесу Telegram-бот в 2026 Если коротко – бот закрывает три дыры, которые сайт и почта закрывают плохо: **скорость отклика, доступность 24/7 и автоматизация повторяющихся вопросов**. Сайт хорош как витрина и SEO-канал, почта – для документов и формальной переписки. А в моменте, когда клиенту нужен ответ «прямо сейчас» – он идёт в мессенджер. 900М+ активных пользователей Telegram в мире (2026) 24/7 доступность бота без выходных и обеда 3-5дн. срок запуска базового бота для приёма заявок 70%+ экономия времени на повторяющихся запросах Конкретные плюсы для бизнеса: - **Лиды без потерь.** Заявка приходит мгновенно в чат менеджера или CRM. Не зарывается в почте. - **Никакой регистрации.** Клиент уже залогинен в Telegram – ему не нужно вспоминать пароль или заполнять форму на 10 полей. - **Push в кармане.** Уведомления о статусе заявки, изменении заказа, новых акциях приходят в мессенджер, который у клиента всегда открыт. - **Никакого спам-фильтра.** Сообщения от бота не теряются в «Промоакциях», как письма. - **Автоматизация FAQ.** Бот закрывает 60-80% типовых вопросов без участия человека: цены, сроки, контакты, условия доставки. ## Типы ботов — с реальными примерами Не все боты одинаковы. От типа зависит сценарий, сроки и цена. Вот основные категории. ### 1. Lead-бот (приём заявок) Самый частый запрос. Бот задаёт 3-7 вопросов, собирает контакт и отправляет заявку в Telegram-чат менеджера или в CRM. Подходит для услуг, консультаций, ремонтов, продажи b2b. *Срок: 3-5 дней.* ### 2. FAQ / поддержка Отвечает на типовые вопросы по меню или через AI-классификацию текста. Передаёт сложные случаи живому оператору. Подходит для онлайн-школ, e-commerce, сервисных компаний. *Срок: 1-2 недели для базы, 2-4 недели с AI-поиском по базе знаний.* ### 3. Бот-калькулятор / квиз Проводит клиента через несколько шагов с выбором опций и в конце выдаёт результат: оценку стоимости, рекомендацию, подходящий тариф. Отличная альтернатива длинной форме на сайте. *Срок: 1-2 недели.* ### 4. Бот для уведомлений Отправляет push-сообщения о событиях в системе: новая заявка, изменение статуса, напоминание о записи, уведомление о доставке. Часто работает в паре с другими ботами. *Срок: 2-5 дней.* ### 5. Бот-каталог с заказом Витрина внутри Telegram: категории, карточки товаров, корзина, оформление заказа. Подходит для небольших магазинов до 100-200 позиций. Для крупных каталогов лучше отдельный сайт. *Срок: 2-4 недели.* ### 6. Бот с AI (RAG, агенты) Бот, который отвечает на вопросы по вашей базе знаний с помощью AI: документы, статьи, инструкции, кейсы. Использует Claude или OpenAI плюс векторную базу (Pinecone, Qdrant). Подходит для сложной поддержки, обучения, внутренних wiki. *Срок: 2-4 недели.* **Не пытайтесь сделать «всё в одном».** Чаще всего бизнесу хватает одного простого сценария на 80% задач. Бот, который и продажи, и поддержку, и каталог, и квиз – обычно делает всё плохо. Начинайте с одного, дополняйте по мере роста. ## Запуск за 5 дней: пошагово Так выглядит реалистичный график запуска базового lead-бота с интеграцией в CRM: 1. Брифдень 1 2. Сценарийдень 2 3. Коддень 3 4. Тестыдень 4 5. Запускдень 5 **День 1 – бриф.** Определяем: что должен делать бот, какие вопросы задавать, куда отправлять данные, как обрабатывать нестандартные сообщения. На выходе – одностраничное ТЗ. **День 2 – сценарий.** Прописываем все ветки диалога: что бот говорит, какие кнопки показывает, как реагирует на ответы. Согласуем с вами в виде блок-схемы или таблицы. Это самый важный день – именно тут закладывается удобство. **День 3 – код.** Пишу бота через Telegram Bot API. Подключаю интеграции: отправка заявок в нужный чат, в Google Sheets или в CRM (Bitrix24, AmoCRM, Pipedrive, HubSpot). Делаю обработку ошибок и логирование. **День 4 – тесты.** Прохожу бота сам по каждой ветке, ловлю краевые случаи (пустые сообщения, длинные тексты, эмодзи, нажатия не в свою кнопку). Параллельно вы тестируете со своей стороны. Чиним то, что неудобно. **День 5 – запуск.** Бот деплоится на ваш сервер или мой VPS. Подключаю мониторинг. Пишу краткую инструкцию для администратора: как смотреть заявки, что делать при сбое, как менять тексты. Передаю токен и все доступы вам. **Важно про доступы.** Токен бота (от @BotFather) и все API-ключи интеграций должны оставаться у вас. Это ваш актив. Если разработчик «держит токен у себя» – это форма привязки. Нормальный исполнитель сразу передаёт всё клиенту. ## Что влияет на цену Конкретных цифр в рублях или евро не даю – они быстро устаревают и сильно зависят от региона. Зато даю работающую формулу, чтобы вы могли оценить любое предложение: **Цена бота = (сложность сценария × количество веток) + интеграции + AI-логика − фактор AI-ускорения** **Сложность сценария:** сколько шагов в диалоге, есть ли ветвление, нужны ли обратные шаги. Линейные сценарии (опросник, заявка) – простые. Бот с динамическим меню по результатам предыдущих ответов – сложнее. **Количество веток:** 3-5 веток – базовый случай. 10-20 веток – средняя сложность. 50+ веток – уже отдельный продукт, нужно проектировать дольше. **Интеграции:** подключение CRM, платёжной системы, базы клиентов, рассылок, внешних API. Каждая интеграция – отдельная работа по настройке и тестам. **AI-логика:** если бот должен отвечать на свободные вопросы с использованием AI – к цене добавляется работа над промптами, контекстом, векторной базой, обработкой ошибок модели. **AI-фактор разработки:** я работаю с AI-pair programming (Claude, Cursor), поэтому код пишется быстрее. Это понижает финальную цену в 2-3 раза по сравнению с классическими студиями при том же качестве. ## 7 типовых ошибок Эти грабли я вижу регулярно – у клиентов, которые делали бота сами или с предыдущим подрядчиком. Если узнаете свою ситуацию, есть смысл переделать. 1. **Бот пытается делать всё.** Один бот – одна основная задача. Лиды, поддержка и каталог в одном меню – путь к сложному, неудобному и нелогичному продукту. 2. **Нет fallback на человека.** Если бот не понял – пользователь должен иметь кнопку «связаться с менеджером» или «оставить сообщение». Иначе клиент уходит. 3. **Слишком длинный сценарий.** 15 вопросов в опроснике – не «глубокое погружение», а раздражение. Спрашивайте только то, что нужно для первого касания. Детали – уже на созвоне. 4. **Бот не маркетится.** Запустили и забыли. Бот должен быть на главной сайта (виджет или ссылка), в подписи писем, в визитках, в карточках Google Maps. Иначе у него ноль входной аудитории. 5. **Нет экспорта данных.** Заявки только в чате – а если чат потеряется или менеджер уволится? Должна быть Google Sheets, CRM или хотя бы регулярная выгрузка в файл. 6. **Никакой аналитики.** Сколько людей дошли до конца сценария? На каком шаге чаще всего бросают? Если не мерить – не улучшить. Минимум – счётчики событий, в идеале – BotFather analytics или собственная. 7. **Бот забыт после запуска.** Telegram Bot API меняется, нужно обновлять зависимости, иногда чинить интеграции с CRM. Бот без обслуживания через 6-12 месяцев начинает «глючить». **Хорошее правило:** начинайте с самой простой версии (MVP), запускайте, смотрите аналитику и реальное поведение клиентов 2-4 недели. Только потом расширяйте функциональность. Это в 5-10 раз эффективнее, чем строить «идеального бота» полгода в вакууме. ## Частые вопросы Зачем бизнесу Telegram-бот, если есть сайт и почта? Бот не заменяет сайт – он работает рядом. Сайт отвечает за SEO, информацию и доверие. Бот закрывает то, что плохо делает сайт: моментальный отклик 24/7, простые сценарии в чате, push-уведомления о статусе заявки, быстрая консультация без созвонов. По данным Telegram, активная месячная аудитория в 2026 превышает 900 миллионов – клиенты уже там. За сколько реально запустить простого бота для приёма заявок? От 3 до 5 рабочих дней с момента готового брифа. Это включает: сценарий, базовый дизайн ответов, код, тестирование, подключение CRM или таблицы, инструкцию для администратора. Сложные сценарии с AI-ответами, мультиязычностью и оплатой – 2-4 недели. Сколько стоит Telegram-бот? Зависит от сценария и интеграций. Базовый бот для приёма заявок стоит в разы дешевле, чем full-stack веб-сайт, потому что нет дизайна страниц, фронтенда и адаптива. Цена растёт с количеством сценариев, интеграциями (CRM, оплата, рассылки) и сложностью AI-логики. Конкретная оценка – после короткого брифа. Можно ли подключить бота к моей CRM (Bitrix24, AmoCRM)? Да. У всех основных CRM есть открытое API. Бот отправляет заявку в CRM в нужном формате, создаёт сделку, назначает ответственного, сохраняет историю переписки. То же самое работает с AmoCRM, Pipedrive, HubSpot, Salesforce. Если CRM собственная – интегрируем через webhook или прямой доступ к базе. Что делать, если бот не справится с нестандартным вопросом? Главное правило: у бота всегда должен быть fallback на живого человека. Если пользователь пишет что-то вне сценария – бот должен либо предложить меню с понятными опциями, либо передать диалог менеджеру в личный чат, либо собрать контакт для перезвона. Бот не должен «зависать» или тупо отвечать «не понимаю». --- --- title: "AI-инструменты для разработчика 2026 – рабочий стек" url: https://tema.name/blog/ai-instrumenty-dlya-razrabotchika-2026.html language: ru description: "Claude, Cursor, ChatGPT, Copilot, Perplexity, Make – рабочий стек 2026 с примерами. Что выбрать новичку, 7 ошибок и FAQ." date_published: 2026-05-24 date_modified: 2026-05-24 tags: ["AI-разработка", "Claude", "Cursor"] --- AI-разработка 24 мая 2026 · 11 мин чтения · Автор: Артём # AI-инструменты для разработчика 2026: рабочий стек Рабочий стек разработчика в 2026: **Claude Code или Cursor** как основная IDE-надстройка (20 $/мес), **ChatGPT Plus** для ресёрча и быстрых ответов (20 $/мес), **GitHub Copilot** на автодополнение в редких случаях (10 $/мес). Общий бюджет — 30–50 $/мес против 0 ₽ ещё три года назад, экономия времени — 30–50% на типовых задачах. Claude закрывает рефакторинг, ревью и сложную логику. Cursor выигрывает в скорости редактирования крупных файлов. ChatGPT — для быстрых вопросов и работы с изображениями. AI плохо справляется с: устаревшими фреймворками без свежей документации, бизнес-логикой без полного контекста, тонкими багами в многопоточном коде. Новичку достаточно одного Claude или Cursor — остальное избыточно. В статье — детальный разбор каждого инструмента, реальные сценарии и где AI не заменяет инженера. **В статье** 1. [Что изменилось в разработке за 2 года](#what-changed) 2. [Мой рабочий стек по категориям](#stack) 3. [Как выглядит день AI-pair programming](#workflow) 4. [Минимум для новичка – с чего начать](#beginner) 5. [7 ошибок, которые я совершил](#mistakes) 6. [Частые вопросы](#faq) ## Что изменилось за 2 года в разработке Если бы я писал такую же статью в 2024 – она бы выглядела совсем по-другому. Тогда AI был «полезной игрушкой»: помогал с regex, объяснял ошибки, иногда выдавал хороший snippet. Сейчас AI – это **основная среда работы**, такая же как IDE или git. 5+ AI-инструментов в ежедневном стеке 3-5× ускорение разработки с AI-pair programming ~$75/мес стоимость базового подписочного стека 0% boilerplate-кода, который я пишу вручную Три ключевых сдвига: - **Контекстное окно выросло.** Claude теперь читает 200K+ токенов за раз – это весь средний проект целиком. AI видит всю кодовую базу, а не один файл. - **Инструменты стали агентами.** Cursor умеет сам запускать команды, читать файлы, делать коммиты. Не просто «отвечает на вопрос», а исполняет цепочки действий. - **Качество кода сравнялось с senior-уровнем** на типовых задачах. AI не «иногда хорошо» – он стабильно хорошо для всего, что не требует уникального бизнес-контекста. ## Мой рабочий стек по категориям ### Категория 1: код-ассистенты ### Claude (Anthropic) $20/мес · мой основной Главный инструмент для длинных контекстов, сложного рефакторинга и архитектурных вопросов. Лучше следует инструкциям, чем GPT, меньше галлюцинирует. Использую через web-интерфейс claude.ai и API в коде. Артефакты – удобная фича для итеративной работы над одним файлом. ### Cursor $20/мес · IDE VSCode-форк со встроенным AI. Cmd+K для inline-правок, Cmd+L для чата с проектом, Composer для многофайловых изменений. Использует Claude Sonnet и GPT-4 под капотом. Самый продуктивный режим работы – пишешь промпт прямо в коде. ### ChatGPT (OpenAI) $20/мес · второй Беру для задач, где нужен поиск по свежей информации (через web-режим) или генерация изображений (DALL-E). Также как «второе мнение», когда Claude даёт спорный ответ. Подписка не обязательная, но удобная для регулярных задач. ### GitHub Copilot $10/мес · inline Tab-автодополнение прямо в редакторе. Меньше «думающий», больше «угадывающий», но на boilerplate-задачах (типовые getter'ы, циклы, формы) экономит часы. В Cursor встроен похожий механизм – если есть Cursor, Copilot может быть избыточен. ### Категория 2: research и факт-чекинг ### Perplexity $20/мес · поиск с источниками AI-поиск с ссылками на источники. Незаменим для research новых библиотек, проверки фактов, поиска решений к редким ошибкам. Бесплатный план даёт ~5 поисков в день – уже полезно. Pro-план снимает лимиты + Sonar модели. ### NotebookLM (Google) бесплатно · документация Загружаешь 5-50 PDF/доков – AI отвечает на вопросы по ним с цитированием. Использую для разбора больших API-документаций, технических спецификаций, юридических документов. Бесплатно с Google-аккаунтом. ### Категория 3: дизайн и UI ### v0.dev (Vercel) от $20/мес · UI-компоненты Описываешь компонент текстом или загружаешь скриншот – получаешь React/Tailwind-код. Не для production «как есть», но как стартовая точка – отлично. Особенно полезен для landing-блоков и dashboard-карточек. ### Midjourney $10/мес · иллюстрации Для иконок, иллюстраций, hero-картинок. Через Discord-бота или web-интерфейс. Альтернатива – DALL-E (входит в ChatGPT Plus). Я предпочитаю Midjourney за стабильность стиля при использовании --sref для брендирования. ### Категория 4: автоматизация и оркестрация ### Make.com от $9/мес · no-code workflows Визуальный конструктор для соединения сервисов: Telegram-бот → парсинг → Google Sheets → email-рассылка. Когда сценарий устаканился – переписываю на Python-скрипт, но Make отлично для прототипа и быстрых решений. ### Кастомные скрипты на Python/Node.js опенсорс · production-логика Когда no-code упирается в потолок (или становится дороже скрипта на хостинге) – пишу свой код через Claude/Cursor. Хостится на VPS или Cloudflare Workers. Полный контроль, минимальные затраты. ### Категория 5: vector-базы и RAG ### Pinecone / Qdrant от $0 (free tier) до $70/мес Vector-базы для AI-поиска по своим документам. Pinecone проще для старта (managed), Qdrant – опенсорс, можно хостить у себя. Используются для RAG-агентов: бот отвечает на вопросы по вашей базе знаний. ### OpenAI / Voyage embeddings копейки за тысячу токенов API для конвертации текста в векторы. OpenAI text-embedding-3-small – отличный baseline. Voyage – чуть точнее на code-search и domain-specific текстах. Стоимость для типового проекта – $1-5 в месяц. **Не путать «AI-инструменты» и «AI-зависимость».** Все эти подписки имеют смысл только если они окупают себя экономией времени. Если вы используете Claude один раз в неделю – платить $20/мес нет смысла, есть бесплатные планы. Начинайте с минимума, расширяйте по мере роста загрузки. ## Как выглядит день AI-pair programming Типовая сессия работы над фичей – 5 этапов. Каждый этап оптимизирован под определённый инструмент. 1. Контекст5-10 мин 2. Промпт2-5 мин 3. Генерация1-3 мин 4. Ревью10-20 мин 5. Тест5-15 мин **Этап 1 – контекст.** Открываю в Cursor нужные файлы (или загружаю в Claude через @-меню). Если задача больше одного файла – собираю «карту» всех зависимостей. Без контекста AI пишет правильный код, который не подходит под ваш проект. **Этап 2 – промпт.** Описываю задачу полностью: что должно получиться, какие edge-cases учесть, на каком стеке, какие соглашения проекта. Хороший промпт – 5-15 строк текста. Плохой промпт – «сделай форму». **Этап 3 – генерация.** AI выдаёт ответ. Не обязательно сразу принимать – часто прошу 2-3 варианта или «теперь то же, но с обработкой ошибок и логированием». **Этап 4 – ревью.** Самый важный этап. Читаю каждую строку, проверяю логику, ищу галлюцинации (несуществующие методы, неправильные импорты), оцениваю соответствие проекту. **Без ревью нельзя коммитить.** **Этап 5 – тест.** Запускаю код, проверяю edge-cases, в идеале пишу или прошу AI написать unit-тесты. Sentry/логи для мониторинга в production. ## Минимум для новичка – с чего начать Если вы только начинаете и не хотите сразу платить $75/мес – вот минимум для входа в AI-разработку: - **Cursor (бесплатный план)** – ограниченное количество запросов в месяц, но достаточно для пет-проектов. *$0* - **Claude или ChatGPT бесплатный план** – оба позволяют ~30-50 сообщений в день. Выбирайте один, постоянно работайте с ним. *$0* - **Perplexity бесплатный план** – 5 Pro-поисков в день, остальное – обычный AI-поиск. *$0* Этого хватит на первые 2-3 месяца, пока вы привыкаете к AI-workflow и понимаете, какие задачи лучше отдаёт каждый инструмент. Когда упираетесь в лимиты – платите за один, два, потом три. По мере того, как AI начинает реально окупать время. **Совет:** не пытайтесь освоить все 10 инструментов сразу. Возьмите ОДИН (рекомендую Claude или Cursor), 2-3 недели работайте только с ним по всем задачам. Когда упрётесь в его ограничения – тогда добавляйте следующий. Так вы научитесь правильно ставить задачи AI, а не «переключаться между окнами». ## 7 ошибок, которые я совершил За 2 года активной работы с AI – вот рекордсмены по тому, что отнимало время и нервы. 1. **Принимал код AI без чтения.** Самая дорогая ошибка – верить, что «AI же умный». Один раз продакшн упал из-за того, что Claude использовал несуществующий метод у библиотеки. С тех пор – каждая строка читается. 2. **Давал слишком короткий контекст.** «Сделай форму регистрации» = плохо. «Сделай форму регистрации на React, мы используем react-hook-form, поля X/Y/Z, валидация Zod, send в /api/register» = хорошо. 3. **Не сохранял удачные промпты.** Когда нашёл рабочий промпт – сохраняй в заметках. Иначе через неделю снова потратишь 20 минут на формулировку. 4. **Использовал AI для архитектурных решений.** AI плохо понимает контекст проекта целиком – он рекомендует «общие лучшие практики», а не «то, что подходит вам». Архитектуру решаю сам, AI помогает с реализацией. 5. **Игнорировал стоимость API при scale.** Один скрипт-парсер делал по 10K запросов в Claude API в день. К концу месяца счёт – $80 вместо привычных $5. Урок: всегда логируй потребление токенов. 6. **Пытался «обойти» AI в задачах, где он сильнее.** Регулярка, SQL-запрос, конфиг для webpack – быстрее спросить AI, чем гуглить 15 минут. Долго привыкал. 7. **Не вёл diff-логи изменений от AI.** Когда работаешь с AI-агентом, который правит несколько файлов сразу – обязательно делай commit перед каждым раундом. Иначе после 3-4 итераций трудно понять, что и где сломалось. **Правило большого пальца:** AI – это младший разработчик, который пишет в 100 раз быстрее меня. Я как тимлид: ставлю задачу, ревьюшу результат, отвечаю за итог. Не «AI делает за меня» – а «я делаю быстрее с AI». Эта разница в мышлении – определяет, будете ли вы расти или превратитесь в копи-пасте-машину. ## Частые вопросы Какой AI-ассистент лучше: Claude или ChatGPT? Они дополняют друг друга. Claude (Anthropic) сильнее в длинных контекстах, сложной логике и аккуратном следовании инструкциям – мой основной инструмент для рефакторинга и архитектурных задач. ChatGPT (OpenAI) лучше для быстрых вопросов, поиска по новой документации, генерации идей. В 2026 разумно платить за оба – $20-40/мес на каждый – и переключаться по задаче. С чего начать новичку – какой минимальный AI-стек? Минимум: Cursor как IDE (бесплатный план для старта) + Claude или ChatGPT для глубоких вопросов в браузере. Этих двух хватит на 80% задач первые 6 месяцев. Когда упрётесь в их ограничения – добавляйте: GitHub Copilot для inline-подсказок, Perplexity для research с источниками, Make.com для автоматизации внешних процессов. Сколько стоят все эти инструменты в месяц? Базовый стек разработчика: Cursor Pro ($20), Claude Pro ($20), ChatGPT Plus ($20), GitHub Copilot ($10) = ~$70/мес. Плюс API-расходы на пет-проекты – обычно $5-30/мес. Итого $75-100/мес. Это меньше, чем стоит один час работы разработчика – окупается в первый же день использования за счёт скорости. Можно ли работать без AI в 2026? Технически да, но это уже как программировать без IDE и без Stack Overflow – не запрещено, но проигрываете в скорости в разы. Каждый месяц, который вы не используете AI, конкурент с AI-стеком закрывает в 3-5 раз больше задач за то же время. Это уже не «преимущество» – это базовая компетенция. AI заменит разработчиков в ближайшие годы? Нет – но изменит роль. AI хорошо генерирует код, но плохо: ставит задачи, понимает бизнес-контекст, принимает архитектурные решения, проводит ревью на здравый смысл, отвечает за результат перед клиентом. Эти задачи остаются человеку. Разработчик 2026 – это эксперт-инженер, который правильно даёт задачи AI и валидирует результат. AI как акселератор, не замена. --- --- title: "SEO для одностраничника без бюджета 2026 – гайд" url: https://tema.name/blog/seo-dlya-odnostranichnika-2026.html language: ru description: "7 обязательных пунктов SEO для лендинга, реалистичные сроки, типичные ошибки. Бесплатные инструменты: GSC, Yandex Webmaster, PageSpeed." date_published: 2026-05-25 date_modified: 2026-05-25 tags: ["SEO", "лендинг", "без бюджета"] --- SEO без бюджета 25 мая 2026 · 11 мин чтения · Автор: Артём # SEO для одностраничника без бюджета в 2026 Продвинуть одностраничник без бюджета в 2026 реально, но потолок ниже многостраничного сайта и работает только на низко- и среднечастотных запросах (до 500–1000 показов/мес). План: **1)** Семантика на 1 ядро из 30–50 ключей вокруг одной интенции через бесплатные Wordstat и Google Trends. **2)** Структура с 5–7 H2-блоками, FAQPage и HowTo разметка Schema.org. **3)** PageSpeed 90+ на мобиле (LCP < 2.5с, CLS < 0.1). **4)** 3–5 экспертных текстов на 1500–2500 символов в смежных блоках. **5)** 5–10 ссылок с тематических площадок (бесплатно — каталоги, отзовики, профильные сообщества). Сроки до первых позиций — 2–4 месяца, до стабильного трафика 50–200 визитов/день — 5–9 месяцев. В статье — конкретный чек-лист действий по дням и 4 ошибки, которые гарантированно сожгут проект. **В статье** 1. [Может ли одностраничник вообще ранжироваться](#can-rank) 2. [7 обязательных пунктов SEO для лендинга](#essentials) 3. [Пошаговый план запуска за неделю](#workflow) 4. [5 мифов о SEO, которые мешают](#myths) 5. [7 типичных ошибок](#mistakes) 6. [Частые вопросы](#faq) ## Может ли одностраничник вообще ранжироваться Да – и в 2026 даже лучше, чем 3 года назад. Google и Yandex научились понимать **намерение пользователя**, а не просто считать слова. Если страница чётко отвечает на конкретный вопрос – она имеет шансы попасть в топ, даже будучи одной страницей. 1 H1 на странице – правило, которое часто нарушают 1500+ слов оптимума для коммерческого лендинга 90+ PageSpeed Mobile для конкурентоспособности 100% SEO-инструментов из этого гайда – бесплатные Но есть нюансы. Одностраничник **проигрывает многостраничным сайтам** на «широких» запросах (типа «купить кроссовки», «ремонт квартир»), где конкурируют сайты с сотнями страниц. Зато **выигрывает** на узких и нишевых запросах – именно там, где обычно и сидит ваш клиент. Реалистичные ожидания: - **Хорошо для**: «название услуги + город» (локальное SEO), нишевые услуги для b2b, конкретные продукты для специфичной аудитории, личные бренды, портфолио. - **Плохо для**: интернет-магазинов (нужны страницы товаров), медиа-проектов (нужны статьи), агрегаторов (нужны категории). ## 7 обязательных пунктов SEO для лендинга Это базовый чек-лист. Без любого из этих пунктов SEO не работает – проверено на десятках проектов. ### 1. Уникальный H1 с целевым запросом Один H1 на странице, и в нём должен быть ваш основной поисковый запрос. Не «Добро пожаловать на сайт компании», а «Разработка сайтов под ключ в Гданьске – Имя/Бренд». Поисковики смотрят на H1 как на главную тему страницы. ### 2. Title и meta description под запрос Title – до 60 символов с основным запросом в начале. Description – до 160 символов, описывает выгоду + повод кликнуть. **Description не влияет на ранжирование**, но влияет на CTR – а CTR влияет. ### 3. Schema.org разметка Минимум: **Organization** или **LocalBusiness** (если есть физический адрес). Для услуг – **Service**. Для FAQ-секции – **FAQPage**. Для отзывов (если реальные) – **AggregateRating**. Schema.org даёт rich results в выдаче – звёздочки, FAQ-аккордеоны, цены. ### 4. Mobile-first + быстрая загрузка Google индексирует мобильную версию первой. PageSpeed Mobile 80+ – минимум, 90+ – конкурентоспособно. Самые частые «убийцы» скорости: тяжёлые картинки (используйте WebP/AVIF + lazy load), много шрифтов (1 семейство достаточно), визуальные конструкторы (Elementor генерит на 400KB больше нужного). ### 5. Sitemap.xml + robots.txt + Search Console Sitemap.xml (хотя бы из одной строки) + robots.txt + регистрация в **Google Search Console** и **Yandex.Webmaster**. Без этого поисковики узнают о вашем сайте через 2-4 недели. С этим – через 1-3 дня. ### 6. Внутренняя структура: H2-H3 как ответы на подвопросы Разбейте контент на секции с H2-H3, отвечающие на конкретные подвопросы клиента. Например: «Что входит в услугу», «Сколько занимает», «Сколько стоит», «Гарантии». Google любит такую структуру и часто выдаёт её как «featured snippet» в выдаче. ### 7. Аналитика – без неё не оптимизировать Yandex.Metrika и/или Google Analytics 4 + Search Console для поисковых запросов. Без аналитики вы не знаете, какие запросы приводят клиентов и где они отваливаются. SEO без данных – это гадание на кофейной гуще. - Уникальный H1 с целевым запросом - Title до 60 символов + description до 160 - Schema.org: Organization/LocalBusiness + Service + FAQPage - Mobile-first дизайн + PageSpeed 90+ - Sitemap.xml + robots.txt + GSC + Yandex.Webmaster - H2-H3 структура под подвопросы клиента - Yandex.Metrika + GA4 + регулярный анализ запросов ## Пошаговый план запуска за неделю Так выглядит реалистичный график настройки SEO для одностраничника: 1. Аудитдень 1 2. Ключидень 2 3. Контентдень 3-4 4. Тех. SEOдень 5 5. Индексациядень 6+ **День 1 – аудит.** Запускаете [PageSpeed Insights](https://pagespeed.web.dev), проверяете H1/title/meta через DevTools, смотрите Schema.org-валидатором что разметка есть. Цель – понять, что уже работает, а что чинить. **День 2 – ключи.** Открываете [Wordstat](https://wordstat.yandex.ru) и Google Keyword Planner (бесплатные). Ищете 1 основной запрос (по которому хотите ранжироваться) + 3-7 long-tail вариаций. Например, основной – «AI-автоматизация для бизнеса», вариации: «AI-агент для клиентов», «AI-чат-бот для FAQ», «автоматизация заявок с AI». **День 3-4 – контент.** Переписываете тексты так, чтобы основной запрос был в H1, title, первом абзаце и 2-3 раза по тексту естественно. Добавляете H2-H3 секции под long-tail запросы. Минимум 1500 слов для коммерческого лендинга – меньше Google считает «недостаточно глубокой» страницей. **День 5 – тех. SEO.** Добавляете Schema.org JSON-LD (LocalBusiness, Service, FAQPage). Прописываете title/description. Проверяете mobile-вёрстку. Сжимаете картинки до WebP. Создаёте sitemap.xml и robots.txt в корне. **День 6+ – индексация.** Регистрируетесь в Google Search Console и Yandex.Webmaster. Сабмитите sitemap. Запрашиваете индексацию вручную («inspect URL» → «request indexing»). Через 1-3 дня страница появится в выдаче по long-tail запросам, через 2-4 недели – по более широким. **Лайфхак:** для ускорения индексации – опубликуйте ссылку на сайт в активной соцсети (LinkedIn, Telegram-канал, Twitter). Поисковики «находят» сайты быстрее, если на них уже есть внешние ссылки. Один пост в LinkedIn = индексация через 1-2 дня вместо 2-4 недель. ## 5 мифов о SEO, которые мешают ### Миф 1: «Нужно много страниц, чтобы ранжироваться» Реальность: для нишевых запросов одна качественная страница часто бьёт сайт из 50 поверхностных страниц. Качество > количество. ### Миф 2: «Чем больше ключевых слов в тексте, тем лучше» Реальность: с 2020 года переоптимизация (keyword stuffing) – фактор понижения. Цель – естественное упоминание основного запроса 3-5 раз на 1500 слов, не больше. ### Миф 3: «Ссылки – главное в SEO» Реальность: в 2026 контент важнее ссылок. Купленные ссылки с бирж – риск бана. 1 ссылка с релевантного отраслевого сайта стоит 100 с ферм. ### Миф 4: «SEO быстро – за 14 дней» Реальность: 2-4 недели до первых показов, 2-3 месяца до стабильных позиций. Кто обещает быстрее – либо использует чёрные методы (банятся), либо обманывает. ### Миф 5: «AI генерит SEO-тексты, можно не писать самому» Реальность: AI – помощник, но Google научился распознавать «полностью AI-сгенерированный» контент и понижает его. Используйте AI для черновика, потом переписывайте под свой опыт и реальные кейсы. ## 7 типичных ошибок Эти ошибки я вижу регулярно – у клиентов, которые пытались делать SEO сами или через дешёвых фрилансеров. 1. **Целить «самый высокочастотный» запрос.** Хочется ранжироваться по «сайт под ключ» (миллион конкурентов). Реалистичнее – «сайт под ключ для b2b в Гданьске» (50 конкурентов, ваш ICP). 2. **Несколько H1 на странице.** Часто бывает, когда логотип обёрнут в `

` плюс ещё `

` в hero. Должен быть строго один. 3. **Title и description скопированы у конкурента.** Google понижает дубликаты. Пишите свои, под свой оффер. 4. **Плохая мобильная версия.** Шрифт меньше 14px, кнопки слипаются, формы неудобные – Google индексирует именно мобилу и понижает за плохой UX. 5. **Не подключена аналитика с самого начала.** Через 3 месяца хотите понять «работает ли SEO» – а данных нет. Подключайте Metrika и Search Console в первый же день. 6. **Ждать роста за 2 недели и забивать через месяц.** SEO – компаунд-эффект. Первый месяц – почти ничего. Третий – заметный рост. Шестой – стабильный поток. Терпение. 7. **Игнорировать Schema.org.** «Это для интернет-магазинов» – нет. LocalBusiness + Service + FAQPage – на каждом коммерческом лендинге обязательны. **Хороший знак прогресса:** в Search Console каждую неделю растёт количество показов (impressions). CTR пока низкий – это нормально, его поднимаете дальше через улучшение title и description. Но если impressions не растут – значит, SEO не работает, и пора смотреть, что не так. ## Частые вопросы Можно ли вообще продвинуть одностраничник в Google? Да, особенно по узким коммерческим запросам. Одностраничник проигрывает многостраничным сайтам только на «широких» запросах (типа «купить кроссовки»), но на нишевых и локальных («ремонт стиральных машин Гданьск» или «AI-автоматизация для b2b в Берлине») легко выходит в топ-10 при правильной оптимизации. Главное – не пытаться целить «всё подряд» одной страницей. Сколько стоит SEO для лендинга без агентства? Базовая оптимизация – 0 рублей. Бесплатные инструменты: Google Search Console, Yandex.Webmaster, PageSpeed Insights, Schema.org Validator, ChatGPT/Claude для проверки текстов. Платить нужно только если хотите профессиональный аудит ($50-200 разово) или бэклинки (отдельная тема, не рекомендую начинать с этого). 95% результата даёт бесплатное. Сколько ключевых слов реально продвигать одной страницей? 1 основной запрос + 3-7 связанных long-tail вариаций. Например, основной – «заказать сайт под ключ», вариации: «сайт под ключ цена», «сайт под ключ срок», «заказать корпоративный сайт». Если пытаться целить 15 разных тем – Google не понимает, о чём страница, и не ранжирует ни по одной. Что важнее в 2026: контент или ссылки? Контент в разы важнее, особенно для одностраничника. Google научился различать «хорошие» бэклинки от мусорных, и сейчас 1 ссылка с авторитетного сайта (Habr, отраслевой блог) стоит 100 ссылок с фермы. Сосредоточьтесь на контенте: чёткий H1, развёрнутые ответы на вопросы пользователя, Schema.org разметка, скорость загрузки. Ссылки придут естественно, если контент полезный. За сколько ожидать первых результатов от SEO? Реалистично: 2-4 недели до первых показов в выдаче, 2-3 месяца до стабильных позиций по long-tail запросам, 4-6 месяцев до позиций по более конкурентным запросам. Если кто-то обещает «топ-10 за 14 дней» – это либо чёрные методы (которые быстро банятся), либо обман. SEO – это марафон, не спринт. --- --- title: "Каталог-с-заявкой на Joomla 2026 – для b2b и услуг" url: https://tema.name/blog/katalog-s-zayavkoy-na-joomla-2026.html language: ru description: "Joomla 5 + HikaShop без корзины: для b2b и услуг с заявкой вместо онлайн-покупки. Срок 3-5 недель, ошибки, FAQ." date_published: 2026-05-26 date_modified: 2026-05-26 tags: ["Joomla", "HikaShop", "каталог b2b"] --- Joomla / b2b 26 мая 2026 · 11 мин чтения · Автор: Артём # Каталог-с-заявкой на Joomla в 2026: для b2b и услуг Каталог-с-заявкой на Joomla в 2026 — оптимальный формат для b2b, услуг и продукции с конфигурацией: **500–5000 SKU**, нет корзины и онлайн-оплаты, лид уходит в CRM. Стек: **Joomla 5 + HikaShop** в режиме quotation (или SP Page Builder + кастомная форма). Срок запуска — **3–5 недель**, стоимость 150–400 тыс. ₽. Карточка товара: 5–8 характеристик в таблице, 3–6 фото, кнопка «Запросить цену» вместо «Купить», калькулятор по параметрам. Фильтрация по 4–8 атрибутам, мультиязычность из коробки (важно для b2b-экспорта), ACL для менеджеров и партнёров. Конверсия в заявку — 3–7% против 1–2% у обычного интернет-магазина в b2b. Преимущество Joomla перед WP: тонкие права доступа и многоязычность без 5 дополнительных плагинов. В статье — структура карточки, настройка HikaShop и 7 типовых ошибок. **В статье** 1. [Кому подходит формат](#who) 2. [Почему Joomla + HikaShop без корзины](#stack) 3. [Запуск за 3-5 недель](#workflow) 4. [Что должно быть в карточке](#card) 5. [7 типичных ошибок](#mistakes) 6. [Частые вопросы](#faq) ## Кому подходит формат Каталог-с-заявкой – это сайт-витрина, где клиент видит все варианты, фильтрует, сравнивает, читает детали, и в конце нажимает **«оставить запрос»**, а не «купить». На запрос менеджер связывается с уточнением деталей, обсуждает индивидуальные условия и закрывает сделку лично. 50-500 типовое количество позиций в каталоге 3-5нед срок запуска с нуля 5-15% конверсия в заявку у правильного b2b-каталога 0руб расходов на платёжные шлюзы (их нет) Конкретные сценарии, где формат работает лучше всего: - **B2B услуги.** Юридическое сопровождение, маркетинговые услуги, IT-аутсорс. Клиент изучает направления, читает кейсы, оставляет запрос на консультацию. - **Продукция под заказ.** Мебель на заказ, металлоконструкции, спецтехника. Клиент видит модельный ряд, но конфигурация и цена обсуждаются. - **Услуги мастеров.** Ремонт, монтаж, обслуживание. Перечень услуг с описанием, форма «заказать выезд». - **Образовательные курсы.** Когда нужно собеседование перед записью, нет фиксированных цен или есть стипендии/рассрочки. - **Медицинские услуги.** Где запись на консультацию важнее, чем «купить кнопкой». - **Промышленное оборудование.** Цена зависит от конфигурации, доставка обсуждается, нужен счёт. Не подходит для: розничной торговли товарами повседневного спроса (там нужен полноценный магазин), услуг с фиксированной ценой и быстрым решением (там лучше лендинг), агрегаторов (нужны личные кабинеты пользователей). ## Почему Joomla + HikaShop без корзины На рынке есть три типичных подхода к каталогу-с-заявкой. Сравним их. | Подход | Плюсы | Минусы | | --- | --- | --- | | Tilda / Конструктор | Быстро запустить, красивый дизайн из коробки | Плохо масштабируется на 50+ позиций, ограничения в фильтрах, нет нормальной ACL | | WordPress + WooCommerce без корзины | Огромная экосистема плагинов | Работа против архитектуры плагина – костыли. Мультиязычность только через WPML ($$) | | Joomla 5 + HikaShop catalog mode | Нативная поддержка «без корзины», мультиязычность из коробки, ACL для нескольких ролей | Меньше готовых тем, чем у WP, нужен разработчик с опытом Joomla | Почему я выбираю Joomla + HikaShop для большинства клиентов: - **HikaShop умеет «catalog mode»** – одна галочка в настройках убирает корзину, оплату, статусы заказа. Остаётся фильтруемая витрина + кнопка «оставить запрос». - **Мультиязычность бесплатна** – Joomla из коробки делает RU+EN+DE+PL без плагинов уровня WPML ($60-100 в год). - **ACL под разные роли** – менеджер видит свои лиды, контент-редактор обновляет описания, админ видит всё. Без плагинов. - **Меньше «зоопарка плагинов»** – Joomla с базовым стеком работает стабильно годами без обновлений каждую неделю. - **Может стать полноценным магазином** – если через год бизнес дорастёт до онлайн-оплат, HikaShop включает корзину тем же тумблером. **Альтернативы:** для совсем маленьких каталогов (10-30 позиций) можно собрать на статике с динамическими формами. Для крупных b2b с интеграциями (1С, SAP, личные кабинеты) – уже отдельный стек (часто Symfony/Laravel + кастомная админка). Joomla работает в среднем диапазоне 50-500 позиций. ## Запуск за 3-5 недель Так выглядит реалистичный график запуска каталога с нуля: 1. Брифнед 1 2. Структуранед 1-2 3. Карточкинед 2-3 4. Формы+CRMнед 3-4 5. Запускнед 4-5 **Неделя 1 – бриф.** Определяем категории, типичную карточку, поля для фильтров, какие данные собирать в форме заявки, куда отправлять лиды (Telegram-чат, CRM, Google Sheets). На выходе – структура каталога одним списком. **Неделя 1-2 – структура.** Устанавливаю Joomla 5, ставлю HikaShop в catalog mode, настраиваю мультиязычность (если нужна), создаю категории и атрибуты. Делаю шаблон под бренд. **Неделя 2-3 – карточки.** Заполняем каталог: описания, характеристики, фото, видео (если есть), документы для скачивания. Этот этап обычно занимает больше всего времени – зависит от готовности контента у клиента. **Неделя 3-4 – формы и интеграции.** Настраиваю формы заявок: общая «оставить запрос», на каждой карточке индивидуальная «спросить про эту позицию». Подключаю интеграции: лиды летят в Telegram-чат менеджера + CRM (Bitrix24, AmoCRM, HubSpot) + Google Sheets как бэкап. **Неделя 4-5 – запуск.** Финальное тестирование на десктопе, мобиле, планшете. Подключаю аналитику (Yandex.Metrika с целями, Google Analytics 4). Регистрирую в Google Search Console и Yandex.Webmaster, отправляю sitemap. Передаю доступы клиенту с краткой инструкцией. ## Что должно быть в карточке Карточка позиции – ключевой элемент каталога. От её качества зависит, оставит ли клиент заявку или уйдёт «подумать». Обязательный минимум: - Название – ёмкое, с ключевым словом (если SEO важно) - 2-3 качественных фото или видео – не stock, а реальные - Короткое описание (1-2 абзаца) – что это, для кого, основная польза - Характеристики таблицей – структурировано, не сплошным текстом - Цена «от» или диапазон – даже примерный, иначе клиент думает «дорого, наверное» - Срок (изготовления, выполнения, поставки) – конкретно, не «обсуждается» - Форма «оставить запрос про эту позицию» – прямо на карточке, не в подвале - Похожие позиции – внизу, для перехода между вариантами Дополнительные элементы, которые повышают конверсию (по моему опыту, добавляют 2-5% к показателю): - **Контекст использования** – «подходит для», «применяется в». Помогает клиенту понять, его ли это вариант. - **Сравнение с похожими** – «чем отличается от модели X». Снижает количество вопросов в форме. - **Кейс или отзыв** – 1-2 предложения от реального клиента, который заказывал именно эту позицию. - **Гарантии** – срок гарантии, условия возврата, что входит в стоимость. - **Документы для скачивания** – PDF-спецификация, сертификаты, инструкция. b2b-клиенты любят «забрать материалы для согласования». **Главный принцип:** карточка должна снимать максимум вопросов до того, как клиент оставит заявку. Чем больше уверенности он получит на карточке, тем выше шанс, что он напишет именно вам, а не пойдёт сравнивать с конкурентами. ## 7 типичных ошибок Эти ошибки я регулярно встречаю – у клиентов, которые делали каталог сами или с предыдущим подрядчиком. 1. **Делать каталог-с-заявкой как полноценный интернет-магазин.** Включают корзину, статусы заказа, всё лишнее. В итоге клиент путается: «кладу в корзину или сразу пишу?». Корзину нужно убирать. 2. **Слишком много категорий.** 15-20 категорий на 50 позиций – перебор. Лучше 4-6 крупных категорий с фильтрами внутри. 3. **Карточка без формы заявки.** Форма только в подвале страницы. Клиент дочитал карточку, увлёкся, хотел нажать – пролистал страницу заново. Часть отваливается. 4. **Без указания цены.** «Цена по запросу» – самый большой убийца конверсии. Указывайте хотя бы диапазон или «от X». Иначе клиент думает «дорого = не для меня». 5. **Один общий контакт-менеджер на всё.** На 50+ позиций нужны разные ответственные. ACL в Joomla позволяет – менеджер «А» видит лиды по категории 1, «Б» по категории 2. 6. **Нет аналитики и целей.** Запустили каталог – «работает ли он» неизвестно. Yandex.Metrika с целями на отправку формы – обязательно с первого дня. 7. **Не подключена CRM.** Лиды летят только в email и теряются. Нужно: Telegram-чат менеджера + CRM + Google Sheets как бэкап. Три точки – ничего не пропадёт. **Лайфхак:** после первых 50-100 заявок проанализируйте, какие позиции получают больше запросов, чем другие. Возможно, стоит вывести их в категорию «топ» или «популярные» – это ещё подтянет конверсию на 5-10%. ## Частые вопросы Чем каталог-с-заявкой отличается от интернет-магазина? В интернет-магазине клиент кладёт товар в корзину, оплачивает онлайн, получает заказ автоматически. В каталоге-с-заявкой клиент изучает варианты, потом оставляет запрос – «хочу обсудить» – и менеджер связывается. Подходит для b2b, услуг с обсуждением, продуктов под заказ, тендерных схем. Технически сложнее: нет онлайн-оплат, нет статусов заказа, есть лид-обработка. Почему именно Joomla, а не Tilda или WordPress? Tilda – для маркетинговых лендингов, плохо масштабируется на 50+ карточек с фильтрами. WordPress + WooCommerce можно настроить «без корзины», но это против архитектуры плагина. Joomla 5 + HikaShop в режиме «catalog mode» – именно под эту задачу, с мультиязычностью из коробки и аккуратным ACL. Для 50-500 позиций это оптимальный стек. Сколько позиций тянет каталог-с-заявкой? Без оптимизации – 50-300 позиций комфортно. С кэшированием и хорошим хостингом – до 5 000. Свыше – нужны отдельные решения: либо специализированная b2b-платформа, либо кастомная архитектура. Если у вас 1 000+ SKU и они активно меняются – обсуждаем отдельно. Как мерить эффективность каталога? Главная метрика – конверсия из просмотра карточки в заявку. Хороший показатель – 5-15% для b2b, 2-5% для услуг массового спроса. Меряется через Yandex.Metrika + цели на отправку формы. Если конверсия меньше 2% – проблема либо в самих карточках (нет конкретики, плохие фото), либо в форме (длинная, страшная). Можно ли потом добавить онлайн-оплату? Да, HikaShop включает корзину обратно через настройки – это переключатель в админке. Также можно подключить платёжные шлюзы (Stripe, PayPal, локальные эквайринги). Архитектура каталога переживает миграцию в полноценный магазин без переделки фронтенда. Это плюс выбора Joomla с самого начала. --- --- title: "AI-агенты с RAG для базы знаний 2026 – гайд" url: https://tema.name/blog/ai-agenty-rag-baza-znaniy-2026.html language: ru description: "Что такое RAG, как работает, компоненты системы, ошибки. Сравнение Pinecone, Qdrant, pgvector. Сроки и стоимость внедрения." date_published: 2026-05-27 date_modified: 2026-05-27 tags: ["AI-агенты", "RAG", "база знаний"] --- AI-агенты / RAG 27 мая 2026 · 12 мин чтения · Автор: Артём # AI-агенты с RAG для базы знаний 2026: гайд по внедрению AI-агент с RAG — это бот, который перед ответом ищет факты в вашей базе знаний и отвечает только по ним, без выдумывания. Внедрение в 2026: **2–6 недель**, стоимость **200–800 тыс. ₽**, окупаемость на саппорте от 500 обращений/мес — 3–6 месяцев. Стек: Claude или GPT-4 для генерации, векторная БД (Qdrant, Pinecone, pgvector), эмбеддинги от OpenAI или Voyage, оркестрация через LangChain или LlamaIndex. Источники: 100–10 000 документов (PDF, DOCX, веб-страницы, Confluence, Notion). Точность ответов на закрытом домене — 85–95% против 40–60% у «голой» LLM. Типовые задачи: саппорт первой линии, внутренний поиск по регламентам, онбординг сотрудников, ассистент менеджера по продажам. Где RAG не работает: задачи с расчётами, многошаговая логика, актуальные курсы и цены без интеграции с API. В статье — архитектура, чек-лист внедрения и 6 ошибок. **В статье** 1. [Что такое RAG и зачем](#what-is) 2. [5 типовых применений](#use-cases) 3. [Компоненты RAG-системы](#components) 4. [Запуск за 2-4 недели](#workflow) 5. [Сравнение vector-баз](#vectordb) 6. [7 типичных ошибок](#mistakes) 7. [Частые вопросы](#faq) ## Что такое RAG и зачем Представьте ChatGPT, который перед каждым ответом читает ваш корпоративный wiki, продуктовую документацию, регламенты, базу решённых тикетов – и даёт ответ **с ссылками на конкретные документы**, откуда взял информацию. Это и есть RAG. 50-5000 типичный размер базы знаний для b2b-задач 2-4нед срок внедрения базового агента 70-90% точность ответов на правильно подготовленных данных $20-300/мес стоимость работы для среднего бизнеса Почему обычный ChatGPT не подходит для большинства бизнес-задач: - **Не знает про ваш продукт.** ChatGPT не читал вашу документацию, не знает специфики, придумает «правдоподобное», но неточное. - **Cut-off дата.** Даже Claude или GPT-4 обучены на данных до определённой даты. Изменения в продукте после – неизвестны. - **Нет ссылок на источники.** Пользователь не может проверить, откуда ответ – доверия меньше. - **Дорого передавать всё в контекст.** Контекстное окно 200K токенов – но 1000 PDF не влезет, и стоимость каждого запроса будет огромной. RAG решает все четыре проблемы. Перед ответом система **ищет 3-7 самых релевантных кусков** в вашей базе и передаёт их LLM как контекст. LLM формирует ответ на основе именно этих кусков, с цитированием источников. **Главное:** RAG не заменяет ChatGPT – он его дополняет. ChatGPT даёт «общие знания мира», RAG даёт «знания вашей конкретной компании, продукта, отрасли». Вместе – мощный инструмент. ## 5 типовых применений ### 1. Саппорт по продуктовой документации Клиент задаёт вопрос в чате на сайте или в Telegram-боте. RAG ищет ответ в документации, FAQ, ранее решённых тикетах. Закрывает 60-80% типовых вопросов без человека. Сложные случаи передаёт оператору с собранной справкой. ### 2. Внутренний поиск по корпоративной wiki Сотрудник новичок не помнит «как у нас оформляется командировка» или «где регламент по работе с клиентами». Спрашивает у RAG-агента. Тот находит в Notion/Confluence/Google Docs нужный документ, цитирует часть, даёт ссылку на полный. ### 3. Sales-помощник по продуктам Менеджер на встрече с клиентом. Клиент задаёт сложный технический вопрос. Менеджер открывает RAG-чат, спрашивает, получает ответ со ссылками на технические спеки, договоры, кейсы. Скорость ответа клиенту – ×3-5. ### 4. Анализ юридических документов Юрист загружает контракт. RAG проверяет его против корпоративных стандартов («наши обязательные пункты», «красные флаги»), выделяет отличия и риски, цитирует прецеденты из базы предыдущих сделок. ### 5. Образовательный ассистент Студент онлайн-курса задаёт вопрос. RAG ищет ответ в материалах курса, презентациях, расшифровках лекций. Снимает 70% типовых вопросов с тьютора, повышает completion rate курса. Это не полный список. Реально RAG применим везде, где есть **большая база полу-структурированного текста** и регулярные вопросы по ней. ## Компоненты RAG-системы RAG – не «один сервис», а pipeline из 6-7 компонентов. Каждый нужно подобрать под задачу. - **Источник данных** – PDF, веб-страницы, Notion, Confluence, Google Docs, SharePoint, CSV/Excel, базы данных. От источника зависит, как извлекать текст. - **Парсер и чанкер** – разбивает документы на куски 300-800 токенов. От размера чанка сильно зависит качество поиска. - **Embeddings-модель** – конвертирует текст в векторы. OpenAI text-embedding-3-small (универсальный), Voyage-large (точнее на коде), Cohere embed-multilingual (мультиязычные). - **Vector database** – хранит векторы и быстро находит «похожие». Pinecone, Qdrant, Weaviate, pgvector в Postgres. - **Retrieval-логика** – ищет top-K кусков, опционально re-ranking (Cohere Rerank, Voyage Rerank) для повышения точности. - **LLM** – формирует финальный ответ на основе найденных кусков. Claude Sonnet (длинные контексты), GPT-4 (универсальный), Mistral/Llama (локальные). - **Prompt-шаблон** – инструкция модели: «ответь только на основе документов ниже, обязательно цитируй источники, если не знаешь – скажи прямо». - **UI или API** – чат на сайте, Telegram-бот, виджет в Notion, или REST API для интеграции в свой продукт. **Без какого-то компонента не получится.** Часто видел: купили Pinecone, загрузили 200 PDF целиком, дали ChatGPT – «не работает». Конечно не работает: чанкера нет, embeddings не выбраны, prompt не настроен. RAG – это pipeline, а не сервис. ## Запуск за 2-4 недели Реалистичный график запуска базового RAG-агента с нуля: 1. Данныедн 1-3 2. Чанкингдн 4-6 3. Embeddingsдн 7-10 4. Retrievalдн 11-16 5. UI+тестыдн 17-21 **Дни 1-3 – данные.** Собираем все источники: что хотим, чтобы агент знал. Чистим: убираем устаревшее, дубликаты, мусорные документы. На этом этапе обычно выясняется, что «нашей документации последний раз обновляли 3 года назад» – часть работы на стороне клиента. **Дни 4-6 – чанкинг.** Парсим документы, разбиваем на куски. Тут много нюансов: PDF с таблицами требует особой обработки, code blocks нельзя резать посередине, заголовки нужно сохранять с контекстом. Не «один универсальный чанкер на всё», а адаптированный. **Дни 7-10 – embeddings.** Подключаем OpenAI или Voyage API, прогоняем все чанки через embeddings-модель. Сохраняем в vector-DB. Для русско-английского контента беру multilingual модели; для чисто английского – text-embedding-3-small достаточно. **Дни 11-16 – retrieval.** Настраиваем поиск: top-K (обычно 5-10), threshold по схожести, опционально re-ranking. Тестируем на 20-30 типовых вопросов: возвращаются ли релевантные куски? Если нет – тюним: меняем размер чанка, embeddings, prompt. **Дни 17-21 – UI и тесты.** Делаем интерфейс: чат на сайте через iframe, Telegram-бот, виджет в Notion, или REST API. Подключаем мониторинг: логи запросов, оценки пользователей (👍/👎), метрики точности. Финальное тестирование с реальными пользователями. ## Сравнение vector-баз От выбора vector-DB зависит стоимость, скорость, удобство масштабирования. Три популярных варианта: | Решение | Плюсы | Минусы | | --- | --- | --- | | Pinecone | Managed, быстрый старт, никаких DevOps | Дороже на росте ($70+ за месяц), vendor lock-in, нельзя self-host | | Qdrant | Опенсорс, self-host бесплатно, или Qdrant Cloud. Высокая скорость | Нужна базовая инфраструктура (Docker) для self-host | | PostgreSQL + pgvector | Если уже есть Postgres – ставите расширение, никакой новой инфры | Чуть медленнее на больших объёмах (10M+ векторов), нужны индексы | | Weaviate | Hybrid search (vectors + keywords), Modules для разных embeddings | Сложнее в настройке, чем Pinecone/Qdrant | Мои рекомендации: - **Прототип / MVP** – Pinecone free tier или Qdrant локально. Быстрый старт, не нужно думать об инфраструктуре. - **Production до 1M векторов** – Qdrant self-hosted на VPS ($10-30 в месяц) или Pinecone starter ($70 в месяц). - **Уже есть Postgres** – pgvector, никакой новой инфраструктуры, удобство для команды. - **Enterprise с 10M+ векторов** – Pinecone enterprise или Qdrant Cloud с replicas. ## 7 типичных ошибок За 2 года активной работы с RAG-системами – вот рекордсмены по проблемам. 1. **Загружать всё подряд.** Мусор на вход = мусор на выход. 80% времени уходит на подготовку данных: чистка, нормализация, удаление устаревшего. Это не «техническая мелочь», а половина успеха. 2. **Слишком большие чанки.** Если чанк – целая страница, модель находит «эту страницу» вместо «конкретного абзаца». Точность падает. Оптимально – 300-800 токенов с overlap 50-100. 3. **Слишком маленькие чанки.** Если чанк – 1 предложение, теряется контекст: «он» не понятно про что. Слишком короткие – тоже плохо. 4. **Один embedding-модель для всех языков.** Если у вас русский+английский контент – нужны multilingual embeddings (Cohere multilingual, OpenAI text-embedding-3-large). Иначе кросс-языковой поиск не работает. 5. **Нет re-ranking.** Top-K из vector-search часто содержит «похожие, но не точные». Re-ranking модель пересортировывает результаты по релевантности к запросу – повышение точности на 15-30%. 6. **Игнорировать citation.** Ответ без ссылок на источники = недоверие. Промпт должен явно требовать цитирования: «приводи источник в квадратных скобках после каждого факта». Пользователь видит ссылку → кликает → проверяет → доверяет. 7. **Не обновлять базу.** Через 3-6 месяцев документация устаревает, ответы становятся ложными. Нужен процесс регулярного re-indexing: автоматический при изменении в Notion/Confluence или по cron-у раз в неделю. **Хороший признак работающего RAG:** пользователи начинают доверять ему больше, чем поиску в wiki. Если за 1-2 месяца после запуска видите, что запросы к агенту растут, а к саппорту – падают – система работает. Если наоборот – проблема в качестве ответов, нужен debug. ## Частые вопросы Чем RAG-агент отличается от обычного ChatGPT? Обычный ChatGPT отвечает на основе данных, на которых был обучен (до даты cut-off). Он не знает про ваш продукт, документы или внутренние процессы. RAG-агент перед ответом ищет релевантные куски в вашей базе знаний (документация, статьи, регламенты) и даёт ответ с опорой на них – с ссылками на источники. По сути это «ChatGPT, который умеет читать ваши документы перед ответом». Сколько стоит развернуть RAG-агента? Базовый агент на 50-500 документов: 2-4 недели разработки + $20-100 в месяц на vector-DB и LLM-API. Для бизнеса со средним потоком обращений (100-500 в день) – ~$100-300 в месяц. Большие enterprise-инсталляции с 10 000+ документов и тысячами запросов в день – от $1000 в месяц. Конкретная оценка – после короткого брифа. Сколько документов реально может обработать RAG? От 10 до миллионов. Технически нет верхнего предела. Для 10-100 документов работает любая vector-DB. От 1000 до 10 000 – managed решения (Pinecone) или self-hosted Qdrant. Свыше 100 000 – нужна оптимизация чанкинга, иерархический retrieval, иногда отдельные индексы по типам контента. В моей практике 500-5000 документов – самый частый размер. Безопасны ли мои данные в OpenAI или Anthropic? API-обращения (платные планы) – ваши данные не используются для обучения, это указано в Terms of Service обоих провайдеров. Для критичных данных есть варианты: enterprise-планы с подписанным DPA, локальные модели (Llama, Mistral) на своём сервере, или гибридная схема. Для большинства b2b-задач API-планов достаточно. Для PII или медицины – локальная модель или enterprise. Что лучше: Pinecone, Qdrant или PostgreSQL+pgvector? Pinecone – быстрый старт, managed, дороже на росте ($70+ в месяц). Qdrant – опенсорс, можно хостить у себя, бесплатный self-hosted, есть Qdrant Cloud. PostgreSQL+pgvector – если у вас уже есть PostgreSQL: добавляете расширение, не нужна отдельная инфраструктура. Для 10-100K векторов – все три работают. Для миллионов – Pinecone или Qdrant Cloud. Для команд без DevOps – Pinecone проще. --- --- title: "Cloudflare Workers для бизнеса 2026: гайд" url: https://tema.name/blog/cloudflare-workers-dlya-biznesa-2026.html language: ru description: "Cloudflare Workers для бизнеса 2026: что это, 5 применений, сравнение с Lambda/Vercel, типовые ошибки. Запуск без своего сервера за минуты." date_published: 2026-05-28 date_modified: 2026-05-28 --- Serverless / Edge 28 мая 2026 · 11 мин чтения · Автор: Артём # Cloudflare Workers для бизнеса 2026: рабочий гайд Cloudflare Workers — это serverless-код, который выполняется на **330+ edge-локациях** в 5–30 мс от пользователя, без своего сервера и DevOps. Тариф: бесплатно до 100 000 запросов/день, далее 5 $/мес за 10 млн запросов — это в **5–10 раз дешевле AWS Lambda** и в 3–4 раза быстрее на холодном старте (0 мс против 200–800 мс). 5 рабочих сценариев для бизнеса: A/B-тесты на CDN без замедления страницы, защита форм от спама, прокси для внешних API с кэшем, A/B-роутинг трафика по гео, кастомные редиректы и SEO-правила. Лимиты: 10 мс CPU на запрос на бесплатном тарифе (50 мс на платном), 128 МБ памяти, нет долгих фоновых задач. Внедрение — от 1 дня до 2 недель, не требует переноса сайта. В статье — 5 готовых сценариев с кодом и сравнение с Vercel Functions и AWS Lambda. **В статье** 1. [Что такое Workers и экосистема](#what-is) 2. [5 применений для бизнеса](#use-cases) 3. [Сравнение с альтернативами](#compare) 4. [Запуск первого Worker за час](#workflow) 5. [7 типичных ошибок](#mistakes) 6. [Частые вопросы](#faq) ## Что такое Workers и экосистема Cloudflare Workers – это **serverless edge compute**. Вы пишете функцию на JavaScript/TypeScript (или Rust/Python через Pyodide), деплоите через CLI или git, и она моментально работает в 330+ городах мира – Cloudflare сам разворачивает её на ближайший к пользователю сервер. 330+ edge-локаций по миру для деплоя кода 100K/день запросов бесплатно на free плане ~5-50ms типичное время ответа Worker $5/мес paid план: 10 млн запросов в месяц Главное отличие от классических облаков: **код выполняется в той же сети, что и CDN**. Нет понятия «инстанс», «региона», «доступности». Холодного старта почти нет – V8 isolate стартует за 5ms. Вокруг Workers Cloudflare построил целую экосистему сервисов: - **KV (Key-Value)** – распределённое хранилище для кэша, сессий, фич-флагов. Бесплатно до 100K чтений в день. - **R2 (Object Storage)** – S3-совместимое хранилище для файлов. Главная фишка: бесплатный egress (с AWS S3 вы платите за каждый отданный байт). - **D1 (SQL Database)** – SQLite на edge. $5/мес за 10GB. Подходит для большинства веб-приложений до 10M запросов. - **Durable Objects** – объекты с консистентным состоянием. Для чат-комнат, очередей, WebSocket-приложений. - **Queues** – очереди сообщений для асинхронной обработки. - **Workers AI** – запуск open-source моделей (Llama, Mistral, embeddings) прямо на edge. Без отправки данных третьим лицам. - **Hyperdrive** – ускоренный коннект к внешним PostgreSQL/MySQL/MongoDB. **Главная мысль:** Workers – не «замена сервера», а другой подход. Вы пишете маленькие функции, которые выполняются рядом с пользователем, без управления инфраструктурой. Для 70-80% бизнес-задач этого хватает. ## 5 применений для бизнеса ### 1. Telegram-бот без своего сервера Самый частый use-case. Telegram-бот через webhook – это HTTP-эндпоинт, который принимает POST-запросы. Worker отлично с этим справляется. Состояние сессии – в KV (бесплатные 100K чтений/день). Интеграции с CRM или OpenAI – через fetch к их API. Никакого VPS, никаких PM2 или systemd – задеплоил и забыл. ### 2. Обработка форм с сайта Форма заявки на статическом лендинге → Worker → отправка в Telegram-чат менеджера / email / CRM. Спам-защита (honeypot, rate-limit) – пара строк на Worker. Один Worker может обслуживать формы 10 сайтов параллельно. Бесплатный план – больше, чем нужно среднему бизнесу. ### 3. AI-прокси для безопасности API-ключей Хотите дать пользователям доступ к ChatGPT/Claude через свой UI? Прямо из браузера обращаться к OpenAI/Anthropic нельзя – API-ключ утечёт. Worker как прокси: фронт обращается к Worker, Worker добавляет API-ключ из переменных окружения и вызывает OpenAI. Ключ никогда не покидает сервер. ### 4. Image optimization on-the-fly Cloudflare Images или собственный Worker с библиотекой Polish: оптимизация картинок «на лету». Вы загружаете оригинал в R2, Worker делает resize, конвертацию в WebP/AVIF, наложение водяного знака – по URL-параметрам. PageSpeed +20-30 очков на сайтах с большим количеством картинок. ### 5. Geo-routing и A/B-тестирование Worker видит страну, регион, язык браузера пользователя. Можно направлять русских на `tema.name/`, немцев на `/de/`, поляков на `/pl/`. Аналогично для A/B-тестов: разные версии страниц без отдельного сервиса. Все «эксперимент = вторая страница» отрабатываются на edge, до прихода на ваш origin. **Не подходит для:** тяжёлой видеообработки (limit 50ms CPU на запрос на paid plan), монолитных Django/Rails приложений с тысячами зависимостей, задач, требующих долгого state (>30 секунд). ## Сравнение с альтернативами | Параметр | Cloudflare Workers | AWS Lambda | Vercel Functions | | --- | --- | --- | --- | | Регионы | 330+ edge-локаций | Один регион (выбираете вручную) | Edge + регионы | | Холодный старт | ~5ms | 200-2000ms (Node.js), хуже на Java | 50-300ms | | Языки | JS/TS/Rust/Python (Pyodide) | Node.js/Python/Go/Java/Ruby/.NET | JS/TS, Python | | Free план | 100K запросов/день | 1M запросов/месяц | 100K запросов/мес | | Стоимость 10M запросов | $5/мес | ~$20/мес + GB-seconds | ~$20/мес | | Привязка | Cloudflare экосистема | AWS экосистема (S3, DynamoDB...) | Vercel + Next.js фокус | | Idle to first request | Мгновенно | До 2 секунд (cold start) | До 300ms | Мои рекомендации: - **Если у вас уже Cloudflare** – Workers «бесплатное расширение» того, что вы уже платите. Меньше билингов, меньше провайдеров. - **Если интенсивный AWS-стек** (RDS, DynamoDB, SQS) – Lambda удобнее, всё в одном VPC. - **Если фронт на Next.js / Nuxt / Astro на Vercel** – Vercel Functions удобнее, серверный код в том же репо. - **Если глобальная аудитория** – Workers выигрывает за счёт edge-локаций (CDN ставит код в ближайший к пользователю DC). ## Запуск первого Worker за час Реалистичный график запуска первого продакшн-Worker с нуля: 1. Setup10 мин 2. Код15 мин 3. Деплой5 мин 4. Routes10 мин 5. Тесты20 мин **Setup (10 мин).** Регистрация Cloudflare-аккаунта (если нет), установка `wrangler` CLI (`npm install -g wrangler`), `wrangler login` – откроет браузер для авторизации. На этом этапе у вас уже есть рабочая среда. **Код (15 мин).** `wrangler init my-worker` создаёт шаблон. Базовый Worker – 10 строк кода на TypeScript: принимает HTTP-запрос, возвращает Response. Для Telegram-бота добавляете обработку JSON и вызов Telegram API через fetch. **Деплой (5 мин).** `wrangler deploy` – Worker сразу доступен по `\*.workers.dev`. Логи через `wrangler tail`. Без Docker, без CI/CD, без Kubernetes. **Routes (10 мин).** Если у вас уже домен на Cloudflare – в дашборде Workers добавляете Route: `api.yourdomain.com/\*` → ваш Worker. С этого момента запросы на этот URL пойдут в Worker. **Тесты (20 мин).** Локальное тестирование `wrangler dev`. Подключаете KV/D1/R2 через `wrangler.toml` bindings. Edge cases: что вернёт Worker на пустой запрос, на огромный, на запрос с битым JSON. Деплой с `wrangler deploy --env production`. **Лайфхак:** для серверной части Telegram-бота на 95% задач хватает одного Worker + KV для состояний. Не нужен Redis, PostgreSQL, Docker. Бот на 1000 пользователей в день влезает в бесплатный план. Когда придёт 10 000 – платите $5/мес. ## 7 типичных ошибок Эти грабли видел у клиентов и сам наступал. 1. **Хранить состояние в глобальной переменной.** Worker stateless – каждый запрос может попасть на разный сервер. Состояние – в KV/D1/Durable Objects, не в переменной. 2. **Игнорировать CPU-лимит.** 10ms на free, 50ms на paid. Тяжёлая криптография или большой JSON.parse могут не успеть. Профилируйте с `wrangler dev --remote`. 3. **Не использовать Wrangler secrets для ключей.** Положить OpenAI API-ключ в код = он попадёт в git. Используйте `wrangler secret put` – ключ хранится зашифрованно у Cloudflare. 4. **Делать sync операции на каждый запрос.** Каждый fetch к внешнему API стоит времени. Кэшируйте в KV или Cache API, повторно использующиеся данные. 5. **Забыть про Origin-headers.** CORS блокирует запросы с фронта. Worker должен явно возвращать `Access-Control-Allow-Origin` – пользователь не увидит ответа, если этого нет. 6. **Деплой без тестов.** Worker идёт в production моментально. Делайте отдельный environment для staging: `wrangler deploy --env staging`. 7. **Не подключать analytics.** В Cloudflare есть бесплатная Workers Analytics – запросы, ошибки, латентность по регионам. Без неё непонятно, что происходит. ## Частые вопросы Что такое Cloudflare Workers простыми словами? Это код, который выполняется на серверах Cloudflare по всему миру, рядом с пользователем. Вы пишете JavaScript/TypeScript функцию, деплоите её, и она работает в 330+ городах мира. Не нужно своего сервера, не нужен Docker, не нужен PM2. Холодного старта почти нет – ответ за 5-50ms. Подходит для API, форм, Telegram-ботов, прокси, авторизации, обработки изображений. Сколько стоит Cloudflare Workers? Free план: 100 000 запросов в день бесплатно, до 10ms CPU на запрос. Этого хватает для большинства проектов до 100K посещений в месяц. Paid план: $5 в месяц за 10 миллионов запросов, до 50ms CPU. Это в разы дешевле AWS Lambda при том же объёме. Чем Workers отличается от AWS Lambda? Lambda работает в одном регионе AWS, Workers – на 330+ edge-локациях. У Lambda холодный старт 200-2000ms, у Workers – меньше 10ms. Lambda – Node.js/Python/Go/Java/Ruby, Workers – JavaScript/TypeScript/Rust/Python (через Pyodide). Для глобальных API и веб-приложений Workers быстрее и проще, для тяжёлых задач (видео-обработка, ML inference) – Lambda гибче. Можно ли подключить базу данных к Workers? Да. У Cloudflare есть собственные сервисы: D1 (SQLite на edge, $5/мес за 10GB), KV (key-value, для кэша и сессий), R2 (S3-совместимое хранилище без egress-комиссий), Durable Objects (state-консистентность). Также можно подключаться к внешним БД через Hyperdrive (ускоренный PostgreSQL) или прямо через connection API. Подойдёт ли Workers для Telegram-бота? Идеально подходит. Telegram-бот через webhook – это HTTP-эндпоинт, который принимает запросы от Telegram API. Workers справляются с такой нагрузкой даже на бесплатном плане до 100K сообщений в день. Состояние сессии можно хранить в KV (бесплатные 100K чтений/день), интеграции с CRM/OpenAI – через fetch к их API. Никакого VPS не нужно. --- --- title: "PageSpeed 100 из 100 в 2026: как и зачем" url: https://tema.name/blog/pagespeed-100-iz-100-2026.html language: ru description: "Как добиться PageSpeed 100/100 в 2026: Core Web Vitals, LCP/INP/CLS, реальный план оптимизации за неделю, 7 типичных ошибок и FAQ." date_published: 2026-05-29 date_modified: 2026-05-29 --- Performance / SEO 29 мая 2026 · 11 мин чтения · Автор: Артём # PageSpeed 100 из 100 в 2026: как и зачем PageSpeed 100/100 в 2026 = **LCP < 2.5с** + **INP < 200мс** + **CLS < 0.1**. Достигается так: критический CSS инлайнится в head (не более 14 КБ), всё остальное — defer. Картинки в AVIF/WebP с правильными размерами и loading="lazy". Шрифты с font-display: swap и preload только для критических глифов. JS-фреймворки заменяются на vanilla или islands-архитектуру где возможно — это снимает 100–300 КБ. Сервер — Brotli + HTTP/2 + immutable cache на год для статики. На реальных проектах mobile-метрика поднимается с 40–50 до 95–100 за **5–7 рабочих дней**, прирост органического трафика — 15–35% за 2–4 месяца. Гнаться за 100/100 не обязательно — 90+ на мобиле уже даёт максимум ранжирующего бонуса. В статье — пошаговый план оптимизации, инструменты замеров и 7 типичных ошибок. **В статье** 1. [Зачем вообще ускорять сайт](#why) 2. [Core Web Vitals: LCP, INP, CLS](#vitals) 3. [7 главных факторов скорости](#factors) 4. [План оптимизации за неделю](#workflow) 5. [7 типичных ошибок](#mistakes) 6. [Частые вопросы](#faq) ## Зачем вообще ускорять сайт Три прагматичных причины – без идеологии «потому что Google так сказал». 90+ PageSpeed Mobile для нормального ранжирования -7% конверсии на каждую +1 секунду загрузки 2.5s максимальный LCP для зелёной зоны 53% пользователей уходят, если страница грузится > 3 секунд - **SEO-фактор.** Google учитывает Core Web Vitals как фактор ранжирования с 2021. На конкурентных запросах быстрый сайт обходит медленный, при прочих равных. - **Конверсия.** Каждые +1 секунды загрузки уменьшают конверсию на 5-7%. На e-commerce – больше. Прямые потери денег. - **Стоимость рекламы.** Google Ads даёт скидку на CPC для быстрых лендингов и наоборот штрафует медленные. Бюджет – реально влияет. **Главное:** цель – не «100/100», а «зелёная зона по всем Core Web Vitals». 90+ Mobile в PageSpeed Insights – это уже отличный результат, который даёт максимум, что Google учитывает в ранжировании. ## Core Web Vitals: LCP, INP, CLS Это три метрики, которые Google измеряет у реальных пользователей через Chrome (CrUX-данные). С 2021 они – часть алгоритма ранжирования. ### LCP (Largest Contentful Paint) За сколько появляется самый большой элемент на первом экране – обычно главное изображение или большой заголовок. **Хорошо: < 2.5s.** Плохо: > 4s. Главные виновники плохого LCP: тяжёлые hero-картинки без `fetchpriority="high"`, отсутствие `preload`, медленный сервер (TTFB), блокирующие скрипты в head. ### INP (Interaction to Next Paint) Заменил FID в 2024. Измеряет, насколько быстро страница реагирует на клик/тап/нажатие клавиши. **Хорошо: < 200ms.** Плохо: > 500ms. Главные виновники плохого INP: тяжёлый JS на main thread, синхронные обработчики событий, длинные `setTimeout` цепочки. Это «современный» хедач: даже если страница быстро загрузилась, она может «залипать» на клик из-за плохого JS. ### CLS (Cumulative Layout Shift) Сумма «прыжков» вёрстки во время загрузки. Когда баннер сверху подгрузился – и весь текст сдвинулся вниз = плохой CLS. **Хорошо: < 0.1.** Плохо: > 0.25. Главные виновники: изображения без указанной width/height, шрифты, которые меняют размер при подгрузке, рекламные блоки, динамически вставляемые элементы. ## 7 главных факторов скорости Это базовый чек-лист. В 90% случаев именно эти пункты дают 70-90% прироста PageSpeed. - **Картинки в WebP/AVIF + lazy load.** 80% «тяжести» страниц – это картинки. Конвертация PNG/JPG в WebP даёт -40-60% по размеру. AVIF ещё лучше, но поддержка немного хуже. - **Минификация и compression (Brotli).** CSS/JS должны быть минифицированы. Сервер должен отдавать с Brotli (или хотя бы gzip). Cloudflare делает это автоматически. - **Удалить неиспользуемый CSS/JS.** Любой `bootstrap.css` или `jquery.js`, если не используется хотя бы 30% – удалить. PurgeCSS + tree-shaking в bundler-е. - **Шрифты с font-display: swap.** Без этого пользователь видит белый экран, пока шрифт грузится 1-2 секунды. С swap – сначала системный шрифт, потом подменяется. - **Preload главного hero-image + preconnect к CDN.** `` уменьшает LCP на 0.5-1.5 секунды. - **CDN (Cloudflare).** Если сайт хостится в России, а клиенты из EU – без CDN страница грузится 3-5 секунд только из-за географии. Cloudflare бесплатно решает эту проблему. - **HTTP/2 или HTTP/3.** Современный протокол с мультиплексированием. Включается одной галочкой на хостинге или в Cloudflare. Без него браузер качает файлы последовательно вместо параллельного. **80/20-правило:** WebP-картинки + Brotli compression + preload hero + Cloudflare CDN дают 80% результата за 20% усилий. Начинайте с этих четырёх. Дальше уже точечные оптимизации. ## План оптимизации за неделю Реалистичный график разгона сайта с 40-50 баллов Mobile до 90+: 1. Аудитдень 1 2. Картинкидень 2-3 3. CSS/JSдень 4 4. CDN/HTTPдень 5 5. Финишдень 6-7 **День 1 – аудит.** Прогон через [PageSpeed Insights](https://pagespeed.web.dev) + Lighthouse в DevTools. Записываете текущие LCP/INP/CLS, TBT, размер страницы. Это базовая точка для замеров. Параллельно – WebPageTest для waterfall-анализа. **День 2-3 – картинки.** Все JPG/PNG конвертируете в WebP (массово через `cwebp` CLI или Squoosh.app). Добавляете `width`/`height` атрибуты ко всем `![]()` (борьба с CLS). Hero-картинку – с `fetchpriority="high"` и preload в ``. Остальные – `loading="lazy"`. **День 4 – CSS/JS.** Минификация (если ещё не сделана). Удаление неиспользуемого CSS через PurgeCSS. Скрипты, которые не нужны в первом экране – с `defer`. Аналитика и счётчики – асинхронно или после `DOMContentLoaded`. **День 5 – CDN и HTTP/3.** Подключаете Cloudflare (если ещё нет) – бесплатно, 5 минут. Включаете Brotli, HTTP/3, Auto Minify, Rocket Loader (осторожно – может ломать JS). Настраиваете cache rules для статики (1 год для assets с hash в названии). **День 6-7 – финиш.** Повторный прогон PageSpeed. Точечные исправления оставшихся проблем: third-party скрипты в iframe, шрифты с font-display, удаление ненужных preconnect. Финальный замер. Если 90+ Mobile – цель достигнута. ## 7 типичных ошибок Видел эти грабли регулярно – у клиентов с предыдущим подрядчиком или после самостоятельных попыток. 1. **Оптимизировать Desktop, забыть про Mobile.** Mobile-first indexing с 2019. Google ранжирует на основе мобильной версии. Desktop 95 + Mobile 45 = ранжируется как 45. 2. **Тестировать только в Lighthouse, не смотреть field-data.** Lighthouse – лабораторные данные. Search Console показывает реальные CWV у реальных пользователей. Они могут отличаться. 3. **«Помогает плагин WP-Optimize, ставим».** Плагины-оптимизаторы часто конфликтуют, делают непредсказуемое. Лучше один грамотно настроенный, чем три «помогающих» друг другу. 4. **Lazy load hero-картинки.** Самая большая ошибка. Lazy load для картинки выше fold = увеличение LCP. Lazy load – только для картинок ниже первого экрана. 5. **Тяжёлые шрифты без preload и font-display.** 800-шрифт с поддержкой 5 языков = 200KB. Без font-display: swap – белый экран 1-2 секунды. С preload – LCP сокращается. 6. **Third-party скрипты в head.** Yandex.Metrika + Google Analytics + Facebook Pixel + Hotjar + ... в head синхронно – TBT (Total Blocking Time) уезжает в красную зону. Перенос в footer или асинхронно. 7. **Игнорировать Server-Side performance.** TTFB (Time to First Byte) – часто проблема серверной стороны: медленный PHP, неоптимизированные SQL-запросы, отсутствие кэширования на сервере. Оптимизация только клиента не поможет, если сервер сам отдаёт за 2 секунды. **Хороший знак, что оптимизация работает:** через 28 дней Search Console в разделе Core Web Vitals переключает страницы из «Poor» / «Needs improvement» в «Good». Не моментально – CrUX-данные собираются за 28-дневный rolling window. ## Частые вопросы Зачем гнаться за PageSpeed 100/100? Не обязательно стремиться к 100/100 любой ценой. Цифра выше 90 (Mobile) уже даёт максимум, что Google учитывает в ранжировании. 95-100 – больше про bragging rights и хорошие Core Web Vitals в Search Console. Реальная цель – пройти зелёную зону: LCP < 2.5s, INP < 200ms, CLS < 0.1. Это то, что Google учитывает как фактор ранжирования с 2021 года. Что такое Core Web Vitals простыми словами? Три метрики, которые Google измеряет у реальных пользователей: LCP (Largest Contentful Paint) – за сколько появляется главный контент, INP (Interaction to Next Paint) – насколько быстро страница реагирует на клики/тапы, CLS (Cumulative Layout Shift) – не прыгает ли вёрстка во время загрузки. С 2024 INP заменил FID. Mobile или Desktop важнее? Mobile. Google использует mobile-first indexing – он ранжирует на основе мобильной версии. Желательно держать Mobile PageSpeed выше 80, идеально – выше 90. Desktop обычно подтягивается сам, если мобильная версия оптимизирована. Сколько времени занимает оптимизация до 90+? Зависит от стартовой точки и стека. Лендинг на статике: 1-3 дня. Корпоративный сайт на Joomla/WordPress: 1-2 недели. Интернет-магазин с тяжёлой логикой: 2-4 недели. Если стартовали с 30-40 баллами Mobile – месяц реалистично. Если с 60-70 – неделя. Влияет ли PageSpeed на конверсию? Прямо. По данным Google и Amazon: +1 секунда загрузки = -7% конверсии на e-commerce. Для лендингов – меньше: +1с = -3-5%. Также медленные сайты получают меньше повторных визитов: пользователь запоминает, что «у них долго грузится» и не возвращается. --- --- title: "Headless CMS vs обычный CMS в 2026: что выбрать" url: https://tema.name/blog/headless-vs-obychnyy-cms-2026.html language: ru description: "Headless CMS vs обычный CMS в 2026: чем отличаются, кому что подходит. Strapi/Sanity/Contentful vs Joomla/WordPress, ошибки и FAQ." date_published: 2026-05-30 date_modified: 2026-05-30 --- Выбор стека 30 мая 2026 · 11 мин чтения · Автор: Артём # Headless CMS vs обычный CMS в 2026: что выбрать Выбор простой: **обычный CMS (Joomla/WordPress)** подходит для 80% бизнес-задач — лендинги, корпоративные сайты, блоги, каталоги и магазины до 5000 SKU. Срок запуска: 2–4 недели, стоимость: 1× базы, редактор учится за час. **Headless (Strapi/Sanity/Contentful)** оправдан, только если у вас несколько фронтенд-каналов одновременно (web + mobile + терминалы + витрины партнёров), команда от 3 человек и бюджет 2–3× выше. Скорость 95–100 PageSpeed из коробки, но кривая обучения для редакторов выше в 3–5 раз и нужны 1–2 разработчика на поддержку. Стоимость инфраструктуры: обычный CMS — 300–1500 ₽/мес на shared-хостинге, headless — от 20–100 $/мес за CMS + хостинг фронта + CDN. ROI на одноканальном проекте у headless отрицательный первые 2 года. В статье — детальное сравнение по 10 параметрам и 7 типичных ошибок при миграции. **В статье** 1. [Что такое headless CMS](#what-is) 2. [Стек и архитектура – сравнение](#stack) 3. [Кому подходит каждый подход](#use-cases) 4. [Strapi vs Sanity vs Contentful](#tools) 5. [7 типичных ошибок](#mistakes) 6. [Частые вопросы](#faq) ## Что такое headless CMS В обычной CMS (Joomla, WordPress, Drupal) есть три слоя, которые связаны намертво: **админка**, где редакторы пишут контент, **база данных**, где он хранится, и **тема (шаблон)**, которая отрисовывает страницы. Меняешь шаблон – меняешь дизайн. Меняешь CMS – меняешь всё. ~5% доля headless среди всех CMS-сайтов в 2026 3-6нед срок миграции с обычной CMS на headless 95+ типичный PageSpeed Mobile у Jamstack-сайтов 2-3× выше стоимость разработки headless vs обычного CMS В **headless CMS** остаются только админка и база. Фронтенд – ваш собственный, на любой технологии. CMS отдаёт контент через REST или GraphQL API. Front-разработчик берёт API и рисует страницы как угодно. Простая аналогия: обычный CMS – это автомобиль с готовым кузовом. Headless – это шасси с мотором, кузов вы ставите сами под свои задачи. Гибкость выше, но и работы больше. ## Стек и архитектура – сравнение | Параметр | Обычный CMS (Joomla, WP) | Headless CMS | | --- | --- | --- | | Что включено | Админка + БД + фронт-темы | Админка + БД + API. Фронт отдельно. | | Кто рисует страницы | Тема CMS (PHP-шаблоны) | Любой фронтенд: React, Vue, Astro, Next.js | | Кто нужен в команде | 1 fullstack-разработчик | Фронт-разработчик + backend (или 1 fullstack) | | Скорость загрузки | 60-85 PageSpeed Mobile из коробки | 95-100 (статический рендер) | | SEO | Из коробки, плагины | Своими руками, но контроль выше | | Мульти-каналы | Только веб | Веб + mobile + цифровые витрины + email | | Стоимость разработки | База (1×) | 2-3× базы | | Стоимость поддержки | Обновления плагинов | Обновление фронта + CMS отдельно | | Кривая обучения для редактора | Простая, привычная | Похожа, но «оторвана» от итогового вида | **Главное:** headless – не «улучшение» обычного CMS, а другая архитектура с другими компромиссами. Выигрываете в гибкости и скорости – проигрываете в простоте поддержки и стоимости разработки. ## Кому подходит каждый подход ### Когда выбирать обычный CMS (Joomla, WordPress) - **Корпоративный сайт 10-50 страниц.** Команда из 1-3 редакторов, разовая разработка, минимум кастомизации. Joomla или WordPress закрывает 95% задач. - **Блог или медиа.** WordPress – де-факто стандарт для контент-проектов. Огромная экосистема, удобный редактор для не-технарей. - **Небольшой e-commerce.** WooCommerce (WP) или VirtueMart/HikaShop (Joomla) до 5000 SKU работают хорошо. - **Локальная небольшая команда.** Если у вас нет фронт-разработчика и нет планов нанимать – обычный CMS выигрывает. - **Быстрый запуск с фиксированным бюджетом.** Из готовых тем + плагинов запустить лендинг за 1-2 недели – проще на обычной CMS. ### Когда headless оправдан - **Несколько каналов потребления.** Контент идёт на сайт + iOS-app + Android-app + цифровые табло в магазинах + email-рассылки. Один источник правды через API. - **Команда уже работает на React/Vue/Next.** Зачем учить новую CMS-тему, если фронт-разработчик может рендерить через Next.js или Astro. - **Performance-критичные сайты.** Если каждые 0.1 секунды загрузки = миллионы рублей выручки (большой e-commerce, реклама с дорогим CPC). - **Сложная кастомизация UI.** Когда стандартные темы не подходят, нужны интерактивные дашборды, кастомные виджеты, real-time данные. - **Команда из 5+ редакторов с разными ролями.** Хорошие headless CMS имеют гибкую систему прав, многоэтапный workflow, версионирование. **Не путайте «headless» и «Jamstack»:** headless – это архитектура CMS (без своего фронта). Jamstack – подход к деплою: статика + JS + API. Можно быть headless без Jamstack (рендер на сервере через SSR) и можно быть Jamstack без headless (статика без CMS вообще). ## Strapi vs Sanity vs Contentful Три самых популярных headless CMS на рынке. Чем отличаются. | Параметр | Strapi | Sanity | Contentful | | --- | --- | --- | --- | | Хостинг | Self-hosted (Docker, VPS) | Managed (cloud) | Managed (cloud) | | Open source | Да, MIT-лицензия | Studio – open source, бэкенд – нет | Нет | | Цена (free) | Бесплатно (только хостинг) | До 10K докум., 100K запросов/мес | До 50K записей | | Цена (paid) | ~$60-$200/мес (cloud) | $99-$1000+/мес | $300+/мес | | Редактор | Базовый, хороший | Очень кастомизируемый (Studio) | Зрелый, для команд | | API | REST + GraphQL | GROQ + GraphQL | REST + GraphQL | | Кому подходит | Команды с DevOps, контроль | Стартапы, гибкость, быстрый старт | Enterprise, большие команды | Мои рекомендации по сценариям: - **MVP или прототип, бюджет ограничен.** Sanity free tier. Запуск за 2-3 дня, схемы редактора в коде, бесплатно достаточно надолго. - **Корпоративный проект, гибкость + контроль.** Strapi self-hosted на собственном VPS или Strapi Cloud. Полный контроль над данными. - **Enterprise с командой и compliance.** Contentful. SLA, поддержка, безопасность из коробки, готовая интеграция с маркетинговыми платформами. ## 7 типичных ошибок 1. **Выбрать headless «потому что модно».** Если у вас 5 редакторов и один сайт – обычный CMS чаще выгоднее. Headless оправдан архитектурно, не «потому что в Твиттере хвалят». 2. **Недооценить стоимость фронт-разработки.** Headless CMS – это только 30% системы. 70% – фронт-приложение. Бюджет на фронт-разработчика и его поддержку – часто больший, чем на саму CMS. 3. **Забыть про preview.** Редактор хочет видеть, как пост будет выглядеть. На обычной CMS это «по умолчанию». На headless preview надо строить отдельно (Next.js Preview Mode, Sanity Visual Editing). 4. **Игнорировать i18n с самого начала.** Если потом потребуется мультиязычность, переезжать сложнее. Закладывайте поддержку с архитектуры – через locale в схемах. 5. **Не настроить кэширование API.** Каждый запрос к headless API – это HTTP-запрос. На пиковых нагрузках без CDN-кэша API падает. Cloudflare R2 / Vercel ISR / Astro static – решение. 6. **Использовать headless для команды без фронт-разработчика.** Если у вас нет постоянного фронта – через 6 месяцев обновлять Next.js и React будет некому. CMS превращается в «висящий проект». 7. **Сразу выбирать enterprise-tier.** Contentful Pro за $300/мес лишний для проекта на 1000 страниц. Начинайте с free / starter, переходите по мере роста. **Промежуточный вариант:** «WordPress как headless». WordPress остаётся в качестве CMS (привычный редактор для команды), но фронт собирается на Next.js или Astro через WP REST API / WPGraphQL. Получаете 80% преимуществ Jamstack без боли переезда. Хороший компромисс для блогов и медиа-сайтов. ## Частые вопросы Что такое headless CMS простыми словами? Это CMS, у которой есть только бэкенд (админка + API), а фронтенд вы делаете сами – на любом фреймворке (React, Vue, Astro, Next.js). В обычном CMS вроде Joomla или WordPress админка и фронтенд связаны намертво. В headless вы получаете контент через REST или GraphQL и рендерите как хотите. Плюс: гибкость, скорость, мульти-каналы. Минус: нужен фронтенд-разработчик. Когда headless лучше обычного CMS? Когда у вас несколько каналов потребления контента (сайт + мобильное приложение + цифровые витрины + email), когда нужна максимальная скорость (Jamstack-подход), когда команда работает с современными фронтенд-фреймворками, или когда нужна тонкая кастомизация UI без ограничений CMS-темы. Для типового корпоративного сайта или блога обычной CMS чаще достаточно. Сколько стоит headless CMS? Зависит от выбора. Strapi self-hosted – бесплатно (только хостинг). Sanity Free tier – до 10K документов и 100K API-запросов в месяц бесплатно. Contentful Free – до 50K записей. Платные планы Sanity/Contentful: $99-$300/мес. Joomla/WordPress – $0 (только хостинг). Headless обычно дороже, потому что нужны фронтенд-разработчик плюс CMS-сервис. Strapi vs Sanity vs Contentful – что лучше? Strapi – self-hosted, open source, максимальный контроль, идеален для команд с DevOps. Sanity – managed, гибкие схемы данных, отличный редактор (Sanity Studio). Contentful – самый зрелый enterprise-вариант, больше плагинов и интеграций, но дороже. Для прототипов и стартапов – Sanity. Для крупного бизнеса – Contentful. Для тех, кто хочет всё у себя – Strapi. Можно ли переехать с WordPress на headless? Да. Можно сохранить WordPress как headless – он имеет REST API и WPGraphQL плагин. Это даёт переходный вариант: команда продолжает работать в WP-админке, а фронт собирается на Next.js или Astro. Это часто оптимальный путь миграции – не ломать процессы, но получить performance Jamstack. Срок миграции – 3-6 недель в зависимости от объёма. --- --- title: "How to Order a Website with AI in 2026 – Artem" url: https://tema.name/en/blog/how-to-order-website-with-ai-2026.html language: en description: "How AI development differs from classic studios, realistic timelines for a landing and corporate site, how price is formed. Practice, no fluff." date_published: 2026-05-21 date_modified: 2026-05-22 --- AI development 21 May 2026 · 8 min read · By Artem # How to order a website with AI in 2026: approach, timing, price Ordering a website with AI in 2026 costs **1.5-3× less** than the classic studio process and takes **1-4 weeks** instead of 2-4 months. A landing page runs $400-800, a corporate site of 8-15 pages costs $1,200-2,500, a catalog with a lead form sits in the $2,000-4,000 range. The savings come from Claude, Cursor and ChatGPT doing the routine code, copy drafting and design-to-HTML conversion. What you still pay a human for: clear technical writing, SEO structure, integration with CRM and Telegram, deployment. The right order: brief on one page, pick a stack (Joomla, WordPress or static), fix-price contract with milestones every 5-7 days. The article covers the exact brief template, red flags in proposals, and how to verify a contractor actually uses AI rather than charges extra for the buzzword. **In this article** 1. [What changed in website development in 2026](#what-changed) 2. [Types of sites – and which one you need](#types) 3. [Realistic development timelines](#timeline) 4. [How price is formed and what affects it](#price) 5. [What must be in a finished site](#whats-inside) 6. [How to choose a contractor without getting burned](#choose) 7. [FAQ](#faq) ## What changed in website development in 2026 The main difference from 2020s development is **AI-pair programming**. The developer doesn't write code from scratch line by line. They work in tandem with a model (Claude, Cursor, ChatGPT): describe the task in natural language, AI generates structure, markup, scripts and even draft content. The developer reads every block, checks logic, tests, debugs, and assembles the final product. This doesn't mean «developers are no longer needed». On the contrary – their role becomes more expert: they need to know how to properly brief AI, evaluate output quality, see where AI erred, and bring the project to working state. Without this layer, the site comes out either non-functional or pretty-but-illogical. **Main idea:** AI speeds up development 3-5x, but doesn't remove the need for an executor responsible for the result. The question isn't «human or AI», but «who does the final QA and takes responsibility». For the client, this means three practical changes. **First** – timelines shrank dramatically. A landing page that took a studio 1.5 months ships in 1-2 weeks with an AI-driven freelancer. **Second** – prices dropped. Same work costs 3-5x less because there's no team of 4-6 people to support. **Third** – communication got easier. You talk directly to the executor, no project managers, no weeks of approvals. ## Types of sites – and which one you need Before ordering, it's important to understand the format that actually solves your problem. Extra functionality means extra money and time. Insufficient means wasted budget. ### Landing page (single-page site) When it fits: one service or one product, goal is a lead. For example, apartment renovation, lunch delivery, a private dental practice. On a landing, all attention is on the offer and lead form. ### Corporate website (6-15 pages) When it fits: multiple business directions, need to detail each service separately, add team, cases, contacts, an «About» page. For example, a digital agency, law firm, medical clinic. ### Content website with blog When it fits: you're betting on SEO and want to regularly publish articles, attracting audience from search. For example, an online school, expert blog, niche magazine. You need a CMS – most often Joomla or WordPress. ### E-commerce store When it fits: you sell products online – need a catalog with filters, cart, payment, customer account. On Joomla this is solved by VirtueMart or HikaShop components. For very large stores (tens of thousands of SKU) specialized platforms are often better. **Tip:** don't try to order «everything at once». Start with a landing or mini-site, watch real demand, then expand. This saves budget and removes the risk of designing what won't be needed. ## Realistic development timelines In 2026 with AI development, realistic timelines look like: - **Landing page:** 1-2 weeks from brief to launch - **Corporate site (6-15 pages):** 2-4 weeks - **Content site with blog:** from 3 weeks - **Catalog with leads (no payments):** 3-5 weeks - **Full e-commerce store:** 4-8 weeks - **Telegram bot for leads:** 3-5 days 1. Briefday 1 2. Prototypeday 3 3. Designday 5 4. Codeday 7-10 5. Launchday 14 These timelines assume you're ready to quickly approve intermediate results. If every step gets 5-day response – the project stretches 2-3x. So discuss in advance how often there will be demos and how fast you need to decide. The main delay is usually not code, but **content**. If you don't have ready texts, photos and service descriptions – add time for prep. A good contractor can help with text drafts via AI, but final approval stays with you. ## How price is formed and what affects it I deliberately don't give specific numbers here in euros or dollars – they get outdated too fast and vary regionally. But here's a working formula for orienting in any prices: **Site price = (complexity × volume) − AI-acceleration factor + integrations** What affects «complexity»: design uniqueness (template vs custom), non-standard functionality (calculators, calculations, customer account), load (10 visitors/day vs 10 000). What affects «volume»: number of pages or bot scenarios, how many texts to adapt, how many forms and integrations. What adds «integrations»: CRM (Bitrix24, AmoCRM, Pipedrive, HubSpot), payment systems, messengers, email broadcasts. Each integration is extra work setting up API and testing. **AI factor**: if the contractor uses AI tools, their price is usually 3-5x lower than studio prices – at the same final product quality. This isn't «cheap», it's a different approach to the process. **What should NOT be in the quote:** «payment per word in text», «extra charge for mobile version» (responsive is the 2026 norm, not an option), «fixed fee for each content update», «separate charge for SEO markup». If you see these – it's an attempt to inflate the bill on basics. ## What must be in a finished site This is the base checklist to verify the final product. If something's missing – the site isn't delivered. - **HTTPS**: SSL certificate connected, site works via https://. In 2026, Google penalises sites without it. - **Responsive design**: correct display on mobile, tablet and desktop. Button sizes, font readability, form convenience. - **Speed**: PageSpeed Insights – minimum 80 on mobile and 90+ on desktop. Below that, there's room to optimise. - **SEO markup**: title, description, H1-H3 headings, sitemap.xml, robots.txt, Schema.org markup per page type, hreflang for multilingual sites. - **Spam-protected forms**: honeypot field, rate-limit, keyword filter. Leads arrive in Telegram or email instantly. - **Connected analytics**: Yandex.Metrica with webvisor, Google Search Console. You see where clients come from. - **Security headers**: HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy. Protection from typical attacks. - **Documentation and access**: you get source code, hosting/domain/analytics access. Brief content-update guide. ## How to choose a contractor without getting burned The most common client mistake is choosing by «portfolio» without fact-checking. Pretty screenshots can be drawn – real quality is only visible in live projects. Ask before ordering: 1. **Show 2-3 live projects you personally worked on.** Not «participated in» – built and shipped. 2. **What technologies do you use and why specifically those?** If the answer is «we work with whatever's needed» – bad sign. A good contractor has a specific stack. 3. **Who will personally work on my project?** If it's a studio, find out whether the project gets passed to a freelancer for half the price. 4. **What's covered by warranty?** 2026 standard – 30 days of small fixes free, then hourly or retainer. 5. **Who keeps access?** It should be you: hosting, domain, analytics, source code. If the contractor «keeps the site at their place» – that's a form of hostage-taking. 6. **Do you use AI in your work?** In 2026 this is a normal question. If the contractor hides or denies it – they're either behind the market or afraid you'll find out about AI and decide not to pay. **Red flags:** 100% prepayment before work starts, refusal to show intermediate results, vague timelines («as it goes»), no contract or any written scope/price commitment, pressure «decide today or the price goes up». ## Frequently asked questions Can AI build a website entirely on its own? Technically yes – you can generate a whole site through AI. But you can't ship it without a human review: AI makes logic errors, sometimes invents non-existent methods, and doesn't grasp business context. The right approach is AI as accelerator, human as quality control. The developer reads every block, tests, debugs, and takes responsibility for the result. How much does a website really cost in 2026? Depends on format and contractor. A landing page with an AI-driven freelancer is 3-5x cheaper than a classic studio. Same for a corporate site. Exact price for your project is calculated after a short brief. What matters isn't the price itself, but the price/quality ratio and ongoing support cost. What's a realistic timeline for a landing page in 2026? With AI tools, a turn-key landing ships in 1-2 weeks: brief, prototype, design, code, forms, analytics, launch. A classic studio takes 4-6 weeks for the same – due to multi-step internal approvals. What must a finished website include? Minimum: HTTPS, responsive design, spam-protected forms, analytics (Yandex.Metrica and Google Search Console), SEO markup (title, description, sitemap.xml, robots.txt, Schema.org), fast loading (PageSpeed 90+), and a clear update guide. Without these, a site is decoration, not a tool. What to check when choosing a contractor? Ask: what's in the quote, what are the deadlines and do they depend on your content readiness, who personally works on the project, what technologies are used, is there support after handover, who keeps access to the site and analytics. If the contractor evades or says «you don't need to know» – find another. --- --- title: "Joomla vs WordPress vs Static 2026 – Which Stack to Choose" url: https://tema.name/en/blog/joomla-vs-wordpress-vs-static-2026.html language: en description: "Comparison on speed, security, flexibility and maintenance cost. 5 typical scenarios and a clear table to pick the right stack for your task." date_published: 2026-05-22 date_modified: 2026-05-22 --- Stack choice 22 May 2026 · 10 min read · By Artem # Joomla vs WordPress vs static in 2026: which stack to choose **Joomla** wins for multilingual catalogs and B2B sites with 50-500 pages: built-in ACL, native multilanguage, no plugin zoo. **WordPress** covers 60% of all websites globally and is the safe pick for blogs, news portals and shops with 1,000-10,000 SKUs — but expect 8-15 plugins and monthly maintenance. **Static** (Astro, 11ty, Hugo) gives 95-100 PageSpeed, zero hosting cost on Cloudflare Pages, and is perfect for landing pages, docs, portfolios up to 50 pages. Launch times: static 3-7 days, Joomla 1-3 weeks, WordPress 1-4 weeks. Yearly cost of ownership: static $0-30, Joomla $50-150, WordPress $100-400. The article breaks down 7 concrete scenarios and which stack to pick for each, including when to combine them. **In this article** 1. [Short answer for the impatient](#tldr) 2. [Joomla – for whom and why](#joomla) 3. [WordPress – for whom and why](#wordpress) 4. [Static – for whom and why](#static) 5. [Comparison across 7 parameters](#compare) 6. [5 scenarios: what to pick](#scenarios) 7. [FAQ](#faq) ## Short answer for the impatient If you want it in one paragraph: **a landing page or mini-site with rare edits** – static, done. **A corporate site with several editor roles or a catalog-with-lead-form** – Joomla, especially if clean permissions and multilingual matter. **A blog/media with new posts every 1-3 days and five authors** – WordPress, because its ecosystem of themes and plugins is most mature for editorial work. **E-commerce** – depends on size: up to 5 000 SKU lives fine on VirtueMart/HikaShop in Joomla or WooCommerce in WP; tens of thousands of SKU means dedicated platforms. **Main idea:** «the best CMS» doesn't exist. «The right CMS for the task» does. If a contractor claims otherwise and pushes you to one stack regardless of project – that's either tunnel vision or an attempt to sell you what they happen to know. 40% of all websites run on WordPress ~1.5% Joomla share – niche but stable 96/100 average PageSpeed for static 3-5× speed-up with AI development tools Load speed (PageSpeed Mobile) Average score for a typical build without premium caching and CDN Static96 Joomla 582 WordPress65 Numbers are indicative. With aggressive caching and CDN, WordPress pulls up to 80+, Joomla to 90+, but a vanilla build behaves like this. ## Joomla – for whom and why Joomla 5 is a mature PHP 8.x CMS. Per W3Techs, it powers roughly 1.5-2% of all CMS sites worldwide – niche, but stable. Its share is historically higher in continental Europe and the post-Soviet space – many corporate and government sites use it. **Pros:** - **Built-in multilingual** – you don't need a paid WPML-class plugin to launch a site in 4 languages. - **Flexible ACL** – you can give an editor access to only their section without touching others. - **Less «plugin zoo»** – the extension ecosystem is smaller than WP's, which makes picking quality extensions easier and abandoned-plugin risk lower. - **Strong component model** – VirtueMart for shop, HikaShop for catalog, K2 for structured content. Each closes its own scope. - **Less of a bot target** – mass attacks usually focus on WordPress because it's bigger. **Cons:** - Fewer ready-made themes and paid templates on marketplaces. - Smaller specialist pool – finding a contractor isn't as easy as «WordPress on every corner». - For editorial sites with many authors, WP's ecosystem is more convenient. I've worked with Joomla for a long time and keep picking it for projects where clean architecture and multilingual matter. AI-pair programming helps: I can quickly tune templates, write custom modules, build CRM integrations. More on that – [in the article on AI development in 2026](/en/blog/how-to-order-website-with-ai-2026.html). ## WordPress – for whom and why WordPress is the world's most popular CMS, powering about 40% of all sites. That gives two effects: a huge ecosystem and a huge attack surface. **Pros:** - **Massive ecosystem** – thousands of free and paid themes, plugins for almost any task. - **Convenient visual editing** (Gutenberg, Elementor) – editors don't need HTML to add a new block. - **Specialist availability** – finding a WP developer is easier and cheaper than a Joomla one. - **Fits editorial sites** – roles and publishing workflow are built around several authors. - **WooCommerce** – the most popular WP e-commerce solution, with many ready integrations for payments and shipping. **Cons:** - **High vulnerability when abandoned** – most hacks come from un-updated plugins. Any WP build left untouched for a year is a target. - **«Plugin zoo»** – 30+ plugins in one site means conflicts, slowness, duplicated features. - **Paid extensions** – multilingual (WPML), serious form protection, all-in-one SEO suites are subscriptions that pile up. - **Visual builders bloat code** – an unoptimised Elementor site easily lands at PageSpeed 30-40 on mobile. ## Static – for whom and why A static site is HTML, CSS and JS files – no database, no PHP. The server just serves files. Modern generators (Hugo, Eleventy, Astro, the Jamstack approach) let you write Markdown and build the site into an HTML folder, which you then upload to hosting or a CDN. **Pros:** - **Maximum speed** – no server processing, the page arrives ready. PageSpeed 95-100 is normal. - **Security** – nothing to hack: no admin, no DB, no PHP vulnerabilities. - **Minimal hosting** – static is hosted almost for free (Netlify, Cloudflare Pages, GitHub Pages, or plain shared hosting). - **No core updates** – nothing to update. - **Perfect for landings and portfolios** – where edits are rare and content rarely changes. **Cons:** - **No admin panel** – adding a page means editing a file or committing to git. Not every client likes that. - **Dynamic features are external** – forms, comments, search, cart – third-party services or APIs. - **Big catalogs are painful** – generating 50 000 HTML pages takes time, full rebuilds may run for minutes. - **Not for frequent non-technical editors** – five authors with simultaneous «window» access is no longer static. **Middle ground:** «headless CMS + static». Content is edited in an admin (Strapi, Sanity), the site is rebuilt on change. Gives you static's speed and admin's convenience, but adds architectural complexity and costs more than pure static. Not justified on every project. ## Comparison across 7 parameters | Parameter | Joomla | WordPress | Static | | --- | --- | --- | --- | | Load speed | Medium, good with few plugins | Medium, needs caching | Maximum | | Security | High with regular updates | High with updates, but bigger target | Maximum by architecture | | Content editing UX | Good, clean admin | Excellent, visual builders | Only via files or git | | Multilingual | Built-in | Paid plugin (WPML) | Depends on implementation | | Maintenance cost | Medium | Can be high due to paid plugins | Minimal | | Catalog / e-commerce | VirtueMart, HikaShop | WooCommerce | External services only | | Specialist availability | Medium | Very high | High | ## 5 scenarios – what to pick ### Scenario 1: a landing page for one service For example, turn-key apartment renovation or a private dentist. One page, lead form, analytics. Edits once a quarter. **Recommendation:** static. Speed, security, minimal hosting. A CMS here is overkill. ### Scenario 2: a corporate site with 10-30 pages Several services, team, cases, contacts, news. Content updated weekly, multilingual needed. **Recommendation:** Joomla. ACL for different editors, multilingual without paid plugins, clean menu/section management. ### Scenario 3: editorial blog with five authors Content project, articles every 1-3 days, multiple categories, ad blocks, subscriptions. A convenient editor is required. **Recommendation:** WordPress. Ecosystem, ready editorial themes, comfortable for non-technical users. ### Scenario 4: an e-commerce store up to 5 000 SKU Catalog with filters, cart, payment, customer account, promotions, shipping. **Recommendation:** Joomla with VirtueMart/HikaShop or WordPress with WooCommerce. Pick depends on whether you need multilingual (Joomla wins) or a huge theme selection (WP). Above 10 000 SKU I'd look at specialised platforms – Shopify, OpenCart, or a custom build. ### Scenario 5: B2B catalog with lead form List of services or products with descriptions, filters, lead forms. No online purchase – the client leaves a request, a manager calls back. **Recommendation:** Joomla with HikaShop in «no-cart» mode or static with dynamic forms. Full e-commerce is overkill here. **If you already have a site** and are wondering whether to switch stacks – first diagnose the real pain. Slowness? Often solved by caching and image optimisation without migration. Hacks? Solved by updates and a plugin audit. Awkward admin? Maybe permissions are misconfigured. Migration is 2-4 weeks of work plus SEO risk. Diagnose first, switch second. ## Frequently asked questions Is Joomla still relevant in 2026? Yes. Joomla 5 is a modern PHP 8.x CMS with a thoughtful permissions system, built-in multilingual support, and a less aggressive ecosystem than WordPress. It's well suited for corporate sites, catalogs, and e-commerce via VirtueMart or HikaShop. For large editorial projects with many authors, WP is more common – but for «several roles, clean ACL, no monster page-builder», Joomla often wins. What's faster: static, Joomla or WordPress? Other things equal, the order is: static → Joomla → WordPress. Static wins because there's no database and no PHP processing of the request. Joomla is usually faster than WordPress thanks to a cleaner core and fewer plugins in a typical build. WordPress can be sped up with caching and CDN, and then the gap stops being critical for a landing page. On a large catalog the difference becomes visible again. Can you run a blog on a static site? Yes – via Jamstack generators (Hugo, Eleventy, Astro) or hand-written, like this blog. Upside: speed, security, minimal hosting cost. Downside: every new article requires editing files or a git commit – not every client finds that convenient. If articles are rare and written by one person, static is excellent. If five authors update daily, you need a CMS. Which stack is more secure? Static is architecturally safer – there's almost nothing to hack: no DB, no admin panel, no PHP. Joomla and WordPress are both secure given regular core and plugin updates. Most CMS hacks aren't core vulnerabilities – they're abandoned sites with 3-year-old plugins. If the site is kept up to date, both options are reliable. I'm already on WordPress. Should I migrate? Only if there's a concrete pain point: slowness under typical load, repeated hacks from a plugin zoo, awkward multilingual workflow. «WordPress is uncool» alone isn't a reason. A migration is 2-4 weeks of work plus SEO risk. If the site works and generates leads, optimising it is usually a better investment than migration. --- --- title: "Telegram Bots for Business 2026 – Launch in a Week" url: https://tema.name/en/blog/telegram-bots-for-business-2026.html language: en description: "What tasks bots actually solve, types of bots, realistic 5-day launch plan, what drives the price, common mistakes. Practice without fluff." date_published: 2026-05-23 date_modified: 2026-05-23 --- Telegram bots 23 May 2026 · 10 min read · By Artem # Telegram bots for business 2026: idea to launch in a week A working Telegram bot for a small or mid-size business launches in **5-10 working days** and costs **$300-1,500** depending on logic. The standard payback window is 1-3 months, mostly through replacing the first line of manual chat with instant 24/7 replies and pushing leads straight into a manager's Telegram with full context. Realistic 2026 use cases: lead capture with 4-7 qualifying questions, FAQ answered by a RAG agent over your docs, appointment booking with calendar sync, order status notifications, mini-catalogs up to 200 items. Stack: aiogram 3 (Python) or grammY (Node.js), webhook on a $5/month VPS, optional Claude or GPT-4o-mini for free-form replies at $0.15-2 per 1,000 dialogues. The article details the 5-day launch plan, pricing logic, and the 6 mistakes that kill bot conversion. **In this article** 1. [Why a business needs a Telegram bot in 2026](#why) 2. [Bot types with real examples](#types) 3. [5-day launch: step by step](#launch) 4. [What drives the price](#price) 5. [7 common mistakes](#mistakes) 6. [FAQ](#faq) ## Why a business needs a Telegram bot in 2026 In one line – a bot closes three gaps that a website and email don't close well: **speed of response, 24/7 availability and automation of repetitive questions**. A site is great as a showroom and SEO channel, email is for documents and formal threads. But when the client needs an answer «right now» – they go to a messenger. 900M+ active Telegram users worldwide (2026) 24/7 bot availability, no breaks or weekends 3-5d typical launch time for a lead bot 70%+ time saved on repetitive requests Concrete benefits for the business: - **Leads never lost.** Requests land instantly in the manager's chat or CRM. Don't get buried in email. - **No signup.** The client is already logged into Telegram – no password recall, no 10-field form to fill. - **Push in their pocket.** Status updates, order changes, promotions go straight to the app the client always has open. - **No spam filter.** Bot messages don't end up in «Promotions» like email does. - **FAQ automation.** A bot closes 60-80% of typical questions without human input: pricing, timelines, contacts, delivery terms. ## Bot types — with real examples Not all bots are equal. The type sets the scenario, timeline and price. Main categories: ### 1. Lead bot (request capture) The most common ask. The bot asks 3-7 questions, captures contact and sends the request to the manager's Telegram chat or to a CRM. Fits services, consulting, repairs, B2B sales. *Timeline: 3-5 days.* ### 2. FAQ / support Answers typical questions via menu or AI text classification. Hands complex cases to a live operator. Fits online schools, e-commerce, service companies. *Timeline: 1-2 weeks for basic, 2-4 weeks with AI search over a knowledge base.* ### 3. Calculator / quiz bot Walks the client through several steps with options and gives a result at the end: price estimate, recommendation, fitting tier. A great alternative to a long form on a website. *Timeline: 1-2 weeks.* ### 4. Notification bot Sends push messages about events in your system: new request, status change, appointment reminder, delivery update. Often pairs with other bots. *Timeline: 2-5 days.* ### 5. Catalog bot with ordering A storefront inside Telegram: categories, product cards, cart, checkout. Fits small shops up to 100-200 SKUs. For larger catalogs, a dedicated site is better. *Timeline: 2-4 weeks.* ### 6. AI bot (RAG, agents) A bot that answers free-form questions based on your knowledge base using AI: docs, articles, manuals, case studies. Uses Claude or OpenAI plus a vector store (Pinecone, Qdrant). Fits complex support, training, internal wikis. *Timeline: 2-4 weeks.* **Don't try to «do it all in one».** Most businesses get 80% of value from a single, simple scenario. A bot that sells, supports, runs a catalog and a quiz all at once usually does each badly. Start with one, expand as you grow. ## 5-day launch step by step Here's a realistic schedule for launching a basic lead bot with CRM integration: 1. Briefday 1 2. Scenarioday 2 3. Codeday 3 4. Testingday 4 5. Launchday 5 **Day 1 – brief.** Define: what the bot should do, what questions to ask, where to send data, how to handle off-script messages. Output: a one-page spec. **Day 2 – scenario.** Write out every dialog branch: what the bot says, what buttons it shows, how it reacts to answers. Reviewed with you as a flow chart or table. This is the most important day – usability is set here. **Day 3 – code.** I build the bot via Telegram Bot API. Integrations: send leads to the right chat, Google Sheets or CRM (Bitrix24, AmoCRM, Pipedrive, HubSpot). Error handling and logging. **Day 4 – testing.** I run every branch myself, catch edge cases (empty messages, long texts, emoji, taps outside buttons). You test on your side in parallel. We fix what feels off. **Day 5 – launch.** Bot deploys to your server or my VPS. Monitoring connected. Brief admin guide: how to view requests, what to do on failure, how to change texts. Token and all access handed over to you. **About access.** The bot token (from @BotFather) and all integration API keys must stay with you. This is your asset. If a developer «keeps the token themselves» – that's a form of lock-in. A solid contractor hands everything to the client immediately. ## What drives the price I deliberately don't put concrete euro or dollar numbers – they age fast and vary by region. Instead, here's a working formula to evaluate any offer: **Bot price = (scenario complexity × number of branches) + integrations + AI logic − AI-acceleration factor** **Scenario complexity:** how many dialog steps, branching, backward paths. Linear scenarios (survey, lead form) are simple. A bot with dynamic menus based on previous answers is harder. **Number of branches:** 3-5 branches – basic. 10-20 – medium. 50+ – a separate product, needs longer design. **Integrations:** CRM, payment system, client database, broadcasts, external APIs. Each is separate setup and test work. **AI logic:** if the bot must answer free-form questions with AI – add work on prompts, context, vector store, model error handling. **AI-development factor:** I work with AI-pair programming (Claude, Cursor), so code ships faster. That cuts the final price 2-3x versus a classic studio at the same quality. ## 7 common mistakes These are the rakes I see regularly – from clients who built the bot themselves or with a previous contractor. If you recognise your situation, it's worth rebuilding. 1. **The bot tries to do everything.** One bot – one core job. Leads, support and catalog in one menu usually means a complex, awkward, illogical product. 2. **No human fallback.** If the bot doesn't get it – the user needs a «contact manager» or «leave a message» button. Otherwise the client leaves. 3. **Scenario too long.** 15 survey questions isn't «deep discovery», it's annoyance. Ask only what's needed for first contact. Details go on the call. 4. **Bot not marketed.** Launched and forgotten. The bot should be on the homepage (widget or link), email signature, business cards, Google Maps cards. Otherwise no inbound audience. 5. **No data export.** Requests only in chat – what if the chat disappears or the manager quits? Google Sheets, CRM or at minimum a regular export are needed. 6. **No analytics.** How many users finish the scenario? Where do they drop? If you don't measure, you can't improve. Minimum – event counters; ideal – BotFather analytics or your own. 7. **Bot abandoned after launch.** Telegram Bot API evolves, dependencies need updating, CRM integrations sometimes break. A bot without maintenance starts «glitching» in 6-12 months. **Good rule:** start with the simplest version (MVP), launch, watch analytics and real client behaviour for 2-4 weeks. Only then expand. That's 5-10x more effective than building the «perfect bot» in a vacuum for half a year. ## Frequently asked questions Why does a business need a Telegram bot if there's already a site and email? A bot doesn't replace a site – it works alongside. The site handles SEO, info and trust. The bot covers what the site doesn't do well: instant 24/7 reply, simple chat scenarios, push notifications about request status, quick consultation without phone calls. Per Telegram, monthly active users in 2026 exceed 900 million – your clients are already there. Realistically, how fast can a simple lead bot launch? 3-5 working days from a finalised brief. That covers: scenario, basic reply design, code, testing, CRM or spreadsheet integration, admin guide. Complex flows with AI replies, multi-language and payments take 2-4 weeks. How much does a Telegram bot cost? Depends on scenario and integrations. A basic lead bot is several times cheaper than a full-stack web site because there are no page designs, frontend or responsive layouts. Price grows with number of scenarios, integrations (CRM, payments, broadcasts) and AI logic complexity. Exact estimate – after a short brief. Can the bot connect to my CRM (Bitrix24, AmoCRM, HubSpot)? Yes. All major CRMs have an open API. The bot sends the request to the CRM in the right format, creates a deal, assigns a manager, saves chat history. Same goes for AmoCRM, Pipedrive, HubSpot, Salesforce. If the CRM is custom – we integrate via webhook or direct DB access. What if the bot can't handle a non-standard question? Main rule: the bot must always have a fallback to a human. If the user writes something outside the scenario – the bot should either offer a clear menu, hand the chat to a manager in DM, or collect a contact for callback. The bot must never «hang» or robotically say «I don't understand». --- --- title: "AI Tools for Developers 2026 – Working Stack" url: https://tema.name/en/blog/ai-tools-for-developers-2026.html language: en description: "Claude, Cursor, ChatGPT, Copilot, Perplexity, Make – my 2026 working stack. What beginners should start with, 7 mistakes and FAQ." date_published: 2026-05-24 date_modified: 2026-05-24 --- AI development 24 May 2026 · 11 min read · By Artem # AI tools for developers 2026: working stack The 2026 working developer stack is **Claude Code or Cursor** for daily coding ($20/month), **ChatGPT Plus or Claude Pro** for architecture and copy ($20/month), **GitHub Copilot** for inline completion ($10/month), and **Perplexity** for docs research ($20/month or free tier). Total: $50-70/month, payback in the first saved workday. Claude 4.5 Sonnet leads in long-context refactors and code reviews; GPT-4o is faster for one-shot snippets and image-to-code; Cursor wins for IDE-native multi-file edits. For juniors: start with Cursor free plus Claude free tier, add paid tools once you can name what each one does better than the others. Where AI doesn't belong: production migrations without human review, regex on untrusted input, credential handling. The article maps every tool to a concrete task and lists what to skip. **In this article** 1. [What changed in development over 2 years](#what-changed) 2. [My working stack by category](#stack) 3. [What an AI-pair programming day looks like](#workflow) 4. [Minimum stack for beginners](#beginner) 5. [7 mistakes I've made](#mistakes) 6. [FAQ](#faq) ## What changed over 2 years in development If I'd written this article in 2024, it would look completely different. Back then AI was «a useful toy»: it helped with regex, explained errors, sometimes shipped a good snippet. Now AI is the **primary working environment**, same as IDE or git. 5+ AI tools in my daily stack 3-5× development speed-up with AI-pair programming ~$75/mo cost of base subscription stack 0% boilerplate code I write by hand Three key shifts: - **Context window grew.** Claude now reads 200K+ tokens at once – that's a whole medium project. AI sees the whole codebase, not one file at a time. - **Tools became agents.** Cursor can run commands, read files, make commits on its own. Not just «answer a question» – execute action chains. - **Code quality matches senior level** on typical tasks. AI isn't «sometimes good» any more – it's consistently good for everything that doesn't require unique business context. ## My working stack by category ### Category 1: code assistants ### Claude (Anthropic) $20/mo · my main Primary tool for long contexts, complex refactoring and architectural questions. Follows instructions better than GPT, hallucinates less. I use it via claude.ai web and API in code. Artifacts is a great feature for iterative work on a single file. ### Cursor $20/mo · IDE VSCode fork with built-in AI. Cmd+K for inline edits, Cmd+L for project chat, Composer for multi-file changes. Uses Claude Sonnet and GPT-4 under the hood. Most productive mode – you write prompts directly in the code. ### ChatGPT (OpenAI) $20/mo · secondary For tasks that need fresh web search or image generation (DALL-E). Also as «second opinion» when Claude gives a debatable answer. Subscription isn't mandatory but useful for daily tasks. ### GitHub Copilot $10/mo · inline Tab autocomplete right in the editor. Less «thinking», more «guessing», but on boilerplate (typical getters, loops, forms) it saves hours. Cursor has a similar built-in mechanism – if you have Cursor, Copilot may be redundant. ### Category 2: research and fact-checking ### Perplexity $20/mo · search with sources AI search with source links. Indispensable for researching new libraries, fact-checking, finding solutions for rare errors. Free plan gives ~5 searches/day – already useful. Pro plan removes limits + Sonar models. ### NotebookLM (Google) free · documentation Upload 5-50 PDFs/docs – AI answers questions about them with citations. I use it to parse large API documentation, technical specs, legal documents. Free with Google account. ### Category 3: design and UI ### v0.dev (Vercel) from $20/mo · UI components Describe a component in text or upload a screenshot – get React/Tailwind code. Not for production «as is» but great as a starting point. Particularly useful for landing blocks and dashboard cards. ### Midjourney $10/mo · illustrations For icons, illustrations, hero images. Via Discord bot or web interface. Alternative – DALL-E (included in ChatGPT Plus). I prefer Midjourney for style consistency when using --sref for branding. ### Category 4: automation and orchestration ### Make.com from $9/mo · no-code workflows Visual builder for connecting services: Telegram bot → parsing → Google Sheets → email broadcast. Once the flow stabilises, I rewrite it as a Python script, but Make is great for prototypes and quick fixes. ### Custom Python/Node.js scripts open source · production logic When no-code hits its ceiling (or becomes more expensive than a hosted script) – I write my own through Claude/Cursor. Hosted on VPS or Cloudflare Workers. Full control, minimal cost. ### Category 5: vector databases and RAG ### Pinecone / Qdrant free tier to $70/mo Vector databases for AI search over your documents. Pinecone is easier to start with (managed), Qdrant – open source, self-hostable. Used for RAG agents: bots that answer questions over your knowledge base. ### OpenAI / Voyage embeddings pennies per thousand tokens API for converting text to vectors. OpenAI text-embedding-3-small is a great baseline. Voyage is slightly more accurate on code search and domain-specific text. Cost for a typical project – $1-5/mo. **Don't confuse «AI tools» with «AI dependency».** All these subscriptions only make sense if they pay for themselves in time saved. If you use Claude once a week – there's no point paying $20/mo, the free plan exists. Start with the minimum, expand as your workload grows. ## What an AI-pair programming day looks like A typical feature session is 5 stages. Each is optimised for a specific tool. 1. Context5-10 min 2. Prompt2-5 min 3. Generation1-3 min 4. Review10-20 min 5. Test5-15 min **Stage 1 – context.** Open relevant files in Cursor (or attach to Claude via @-menu). If the task spans more than one file – collect a «map» of all dependencies. Without context, AI writes correct code that doesn't fit your project. **Stage 2 – prompt.** Describe the task fully: what should result, what edge-cases to handle, what stack, what project conventions. A good prompt is 5-15 lines. A bad prompt is «build a form». **Stage 3 – generation.** AI delivers an answer. Don't accept immediately – often I ask for 2-3 variants or «now the same, but with error handling and logging». **Stage 4 – review.** The most important stage. Read every line, verify logic, look for hallucinations (non-existent methods, wrong imports), assess project fit. **Don't commit without review.** **Stage 5 – test.** Run the code, check edge-cases, ideally write or ask AI to write unit tests. Sentry/logs for production monitoring. ## Minimum stack for beginners If you're just starting and don't want to spend $75/mo right away – here's the entry-level kit for AI development: - **Cursor (free plan)** – limited monthly requests, but enough for side projects. *$0* - **Claude or ChatGPT free plan** – both allow ~30-50 messages/day. Pick one, work with it constantly. *$0* - **Perplexity free plan** – 5 Pro searches/day, the rest is regular AI search. *$0* That covers the first 2-3 months while you get used to the AI workflow and understand which tasks each tool handles best. When you hit the limits – pay for one, then two, then three. As AI starts to genuinely pay back the time. **Tip:** don't try to master all 10 tools at once. Pick ONE (I recommend Claude or Cursor), spend 2-3 weeks doing every task with it. When you hit its ceiling – then add the next one. That way you learn how to brief AI properly, not «switch between windows». ## 7 mistakes I've made Over 2 years of active AI work – here are the top time-and-nerve sinks. 1. **Accepting AI code without reading.** The most expensive mistake – believing «AI is smart». Production went down once because Claude used a non-existent method on a library. Since then, every line gets read. 2. **Giving too short context.** «Build a registration form» = bad. «Build a registration form in React, we use react-hook-form, fields X/Y/Z, Zod validation, POST to /api/register» = good. 3. **Not saving good prompts.** When you find a working prompt – save it. Otherwise next week you'll spend another 20 minutes phrasing it. 4. **Using AI for architecture decisions.** AI doesn't grasp the full project context – it recommends «general best practices», not «what suits you». I decide architecture myself, AI helps with implementation. 5. **Ignoring API costs at scale.** One parser script made 10K Claude API calls per day. End of month – $80 instead of my usual $5. Lesson: always log token consumption. 6. **Trying to «outsmart» AI on tasks it's stronger at.** Regex, SQL query, webpack config – faster to ask AI than google for 15 minutes. Took a while to accept that. 7. **Not keeping diff-logs of AI changes.** When working with an AI agent that edits multiple files at once – always commit before each round. Otherwise after 3-4 iterations it's hard to tell what broke and where. **Rule of thumb:** AI is a junior developer who codes 100× faster than me. I'm the team lead: set tasks, review results, take responsibility for the outcome. Not «AI does it for me» – but «I do it faster with AI». That shift in thinking determines whether you grow or become a copy-paste machine. ## Frequently asked questions Which AI assistant is better: Claude or ChatGPT? They complement each other. Claude (Anthropic) is stronger in long contexts, complex logic and precise instruction-following – my main tool for refactoring and architectural tasks. ChatGPT (OpenAI) is better for quick questions, fresh web search, idea generation. In 2026 it's reasonable to pay for both – $20-40/mo each – and switch by task. Where do beginners start – minimum AI stack? Minimum: Cursor as IDE (free tier to start) + Claude or ChatGPT for deep questions in the browser. These two cover 80% of tasks the first 6 months. When you hit their limits, add: GitHub Copilot for inline suggestions, Perplexity for research with sources, Make.com for automating external processes. How much do all these tools cost per month? Base developer stack: Cursor Pro ($20), Claude Pro ($20), ChatGPT Plus ($20), GitHub Copilot ($10) = ~$70/mo. Plus API costs on side projects – usually $5-30/mo. Total $75-100/mo. That's less than one hour of developer work – it pays for itself the first day from speed alone. Can you work without AI in 2026? Technically yes, but it's like coding without an IDE and without Stack Overflow – not banned, but you lose massive speed. Every month you don't use AI, a competitor with an AI stack closes 3-5x more tasks in the same time. It's no longer an «advantage» – it's a baseline skill. Will AI replace developers in the next few years? No – but it will change the role. AI is good at generating code, but bad at: setting goals, understanding business context, making architectural decisions, sanity-checking output, taking responsibility before the client. Those stay human. A 2026 developer is an expert engineer who briefs AI well and validates the result. AI as accelerator, not replacement. --- --- title: "SEO for a Single-Page Site Without Budget 2026" url: https://tema.name/en/blog/seo-for-single-page-site-2026.html language: en description: "7 SEO essentials for a landing page, realistic timeline, common mistakes. Free tools only: GSC, Yandex Webmaster, PageSpeed Insights." date_published: 2026-05-25 date_modified: 2026-05-25 --- SEO no-budget 25 May 2026 · 11 min read · By Artem # SEO for a single-page site without budget in 2026 A single-page site can rank on page 1 of Google for **3-5 low-competition queries** within **2-4 months**, with zero paid budget — but only if the page covers a narrow, specific topic and you publish 1-2 supporting articles per month. The baseline checklist: one H1 matching the main query, 1,500-2,500 words of useful content, FAQ block with 6-10 questions in `FAQPage` JSON-LD, PageSpeed above 90 mobile, valid `Organization` and `WebSite` schema, an `llms.txt` for AI engines. Then 3-5 backlinks from real industry sites — guest posts, directory submissions, profile pages on GitHub, Behance, Dribbble. What doesn't work in 2026: keyword stuffing, link farms, AI-generated walls of text without editing. The article gives the weekend execution plan, realistic timelines per niche, and 5 ways to get backlinks for free. **In this article** 1. [Can a single-page site even rank](#can-rank) 2. [7 SEO essentials for a landing page](#essentials) 3. [Step-by-step plan: launch in a week](#workflow) 4. [5 SEO myths that hold you back](#myths) 5. [7 typical mistakes](#mistakes) 6. [FAQ](#faq) ## Can a single-page site even rank Yes – and in 2026 even better than 3 years ago. Google and Yandex have learned to understand **user intent**, not just count words. If a page clearly answers a specific question – it has a real shot at top, even as a single page. 1 H1 per page – a rule often broken 1500+ word target for a commercial landing 90+ PageSpeed Mobile for competitive ranking 100% SEO tools in this guide – free But there's a nuance. A single-page site **loses to multi-page sites** on «broad» queries (like «buy sneakers», «apartment renovation»), where sites with hundreds of pages compete. But it **wins** on narrow and niche queries – exactly where your client usually is. Realistic expectations: - **Good for**: «service + city» (local SEO), niche b2b services, specific products for a specific audience, personal brands, portfolios. - **Bad for**: e-commerce stores (need product pages), media projects (need articles), aggregators (need categories). ## 7 SEO essentials for a landing This is the base checklist. Without any of these, SEO doesn't work – proven on dozens of projects. ### 1. Unique H1 with the target query One H1 per page, and it should contain your main search query. Not «Welcome to our company», but «Custom web development in Berlin – Name/Brand». Search engines treat H1 as the page's main topic. ### 2. Title and meta description for the query Title – under 60 characters with the main query at the start. Description – under 160 characters, describing the benefit + reason to click. **Description doesn't affect ranking**, but it affects CTR – and CTR does affect ranking. ### 3. Schema.org markup Minimum: **Organization** or **LocalBusiness** (if you have a physical address). For services – **Service**. For an FAQ section – **FAQPage**. For reviews (if real) – **AggregateRating**. Schema.org gives rich results in search: stars, FAQ accordions, prices. ### 4. Mobile-first + fast loading Google indexes the mobile version first. PageSpeed Mobile 80+ minimum, 90+ competitive. Most common speed killers: heavy images (use WebP/AVIF + lazy load), too many fonts (one family is enough), visual builders (Elementor adds 400KB on top of what's needed). ### 5. Sitemap.xml + robots.txt + Search Console Sitemap.xml (even a one-line one) + robots.txt + registration in **Google Search Console** and **Yandex.Webmaster**. Without this, search engines find your site in 2-4 weeks. With it – in 1-3 days. ### 6. Internal structure: H2-H3 as sub-question answers Break content into sections with H2-H3 answering specific sub-questions. For example: «What's included», «How long it takes», «How much it costs», «Guarantees». Google loves this structure and often surfaces it as a featured snippet. ### 7. Analytics – can't optimise without it Yandex.Metrika and/or Google Analytics 4 + Search Console for search queries. Without analytics you don't know which queries bring clients or where they drop off. SEO without data is fortune telling. - Unique H1 with the target query - Title under 60 chars + description under 160 - Schema.org: Organization/LocalBusiness + Service + FAQPage - Mobile-first design + PageSpeed 90+ - Sitemap.xml + robots.txt + GSC + Yandex.Webmaster - H2-H3 structure for client sub-questions - Yandex.Metrika + GA4 + regular query analysis ## Step-by-step plan: launch in a week Here's a realistic schedule for setting up SEO on a single-page site: 1. Auditday 1 2. Keywordsday 2 3. Contentday 3-4 4. Tech SEOday 5 5. Indexingday 6+ **Day 1 – audit.** Run [PageSpeed Insights](https://pagespeed.web.dev), check H1/title/meta via DevTools, see if Schema.org markup is present via Schema.org validator. Goal – understand what works and what to fix. **Day 2 – keywords.** Open Google Keyword Planner and [Ahrefs free tools](https://ahrefs.com/keyword-difficulty). Find 1 primary query (the one you want to rank for) + 3-7 long-tail variations. For example, primary – «AI automation for business», variations: «AI agent for clients», «AI FAQ chatbot», «lead automation with AI». **Day 3-4 – content.** Rewrite copy so the primary query appears in H1, title, first paragraph, and 2-3 times naturally in the body. Add H2-H3 sections for long-tail queries. Minimum 1500 words for a commercial landing – less and Google considers it «not deep enough». **Day 5 – tech SEO.** Add Schema.org JSON-LD (LocalBusiness, Service, FAQPage). Write title/description. Check mobile layout. Compress images to WebP. Create sitemap.xml and robots.txt at the root. **Day 6+ – indexing.** Register in Google Search Console and Yandex.Webmaster. Submit the sitemap. Request indexing manually («inspect URL» → «request indexing»). Within 1-3 days the page appears for long-tail queries, within 2-4 weeks for broader ones. **Pro tip:** to accelerate indexing – post the site link in an active social channel (LinkedIn, Telegram channel, Twitter). Search engines find sites faster if external links already exist. One LinkedIn post = indexing in 1-2 days instead of 2-4 weeks. ## 5 SEO myths that hold you back ### Myth 1: «You need many pages to rank» Reality: for niche queries, one quality page often beats a site with 50 shallow ones. Quality > quantity. ### Myth 2: «More keywords in the text = better» Reality: since 2020, over-optimisation (keyword stuffing) is a demotion factor. Aim for the main query 3-5 times per 1500 words naturally, no more. ### Myth 3: «Links are everything in SEO» Reality: in 2026 content beats links. Bought links from exchanges – ban risk. 1 link from a relevant industry site is worth 100 from farms. ### Myth 4: «SEO can be fast – 14 days» Reality: 2-4 weeks until first impressions, 2-3 months until stable positions. Anyone promising faster – either uses black-hat (gets banned) or lies. ### Myth 5: «AI generates SEO content, no need to write yourself» Reality: AI is a helper, but Google learned to detect «fully AI-generated» content and demotes it. Use AI for drafts, then rewrite with your own experience and real cases. ## 7 typical mistakes These mistakes I see regularly – from clients who tried SEO themselves or via cheap freelancers. 1. **Targeting «the highest-volume» query.** You want to rank for «buy website» (million competitors). More realistic – «custom website for b2b in Berlin» (50 competitors, your ICP). 2. **Multiple H1s on the page.** Often happens when the logo is wrapped in `

` plus another `

` in the hero. Must be exactly one. 3. **Title and description copied from a competitor.** Google demotes duplicates. Write your own, for your offer. 4. **Bad mobile version.** Font under 14px, buttons stuck together, awkward forms – Google indexes the mobile version and demotes for poor UX. 5. **No analytics from the start.** Three months in, you want to know «is SEO working» – but there's no data. Set up Metrika and Search Console day one. 6. **Expecting growth in 2 weeks, quitting after a month.** SEO is a compound effect. Month one – almost nothing. Month three – noticeable growth. Month six – stable flow. Patience. 7. **Ignoring Schema.org.** «That's for e-commerce» – no. LocalBusiness + Service + FAQPage are required on every commercial landing. **Good progress sign:** in Search Console, impressions grow every week. CTR is still low – that's normal, you raise it by improving title and description. But if impressions don't grow – SEO isn't working, time to check what's wrong. ## Frequently asked questions Can you actually rank a single-page site in Google? Yes, especially for narrow commercial queries. A single-page site loses to multi-page sites only on «broad» queries (like «buy sneakers»), but it easily breaks into the top 10 on niche or local queries («washing machine repair Gdansk» or «AI automation for b2b in Berlin») with proper optimisation. The key is not to try to target «everything» with one page. How much does SEO for a landing cost without an agency? Base optimisation – $0. Free tools: Google Search Console, Yandex.Webmaster, PageSpeed Insights, Schema.org Validator, ChatGPT/Claude for text proofreading. You only need to pay for a professional audit ($50-200 one-off) or backlinks (a separate topic, I don't recommend starting with it). 95% of the result comes from free tools. How many keywords can a single page realistically rank for? 1 primary query + 3-7 related long-tail variations. For example, primary – «order a website», variations: «website cost», «website timeline», «order a corporate website». If you try to target 15 different topics – Google can't tell what the page is about and doesn't rank it for any. What matters more in 2026: content or links? Content matters massively more, especially for a single-page site. Google now distinguishes «good» backlinks from spam, and one link from a strong industry blog is worth 100 from link farms. Focus on content: clear H1, deep answers to user questions, Schema.org markup, load speed. Links come naturally if the content is useful. How soon should I expect SEO results? Realistic: 2-4 weeks until first impressions in search, 2-3 months until stable positions on long-tail queries, 4-6 months for more competitive ones. If someone promises «top 10 in 14 days» – it's either black-hat (gets banned fast) or a scam. SEO is a marathon, not a sprint. --- --- title: "Catalog with Lead Form on Joomla 2026 – for B2B" url: https://tema.name/en/blog/catalog-with-lead-form-on-joomla-2026.html language: en description: "Joomla 5 + HikaShop without cart: for B2B and services where the client requests a quote. 3-5 weeks, common mistakes, FAQ." date_published: 2026-05-26 date_modified: 2026-05-26 --- Joomla / B2B 26 May 2026 · 11 min read · By Artem # Catalog with lead form on Joomla 2026: for B2B and services A catalog with a lead form on Joomla is the right pick when you have **20-500 items**, prices depend on the client, and the goal is a manager call rather than an online checkout. Stack: Joomla 5 + HikaShop with checkout disabled, or a custom component for under 100 items. Launch time **2-4 weeks**, cost **$1,500-3,500**. Each card holds 1-3 photos, a 80-120-word description, key specs, and one CTA: "Request a quote". The form has 4-6 fields and pushes the lead into Telegram and email within 1-2 seconds. Perfect fit: B2B equipment, custom furniture, services with consultation, configurable products, real estate. The article covers the exact card structure, what to write in the description so it ranks, the lead-form fields that increase conversion 2-3×, and 7 mistakes I see on almost every project. **In this article** 1. [Who the format fits](#who) 2. [Why Joomla + HikaShop without cart](#stack) 3. [Launch in 3-5 weeks](#workflow) 4. [What goes in a card](#card) 5. [7 common mistakes](#mistakes) 6. [FAQ](#faq) ## Who the format fits A lead-form catalog is a showcase site where the client sees all options, filters, compares, reads details, and ends with **«request a quote»** instead of «buy». The manager then follows up to clarify details, negotiate individual terms and close the deal personally. 50-500 typical catalog size in items 3-5wk launch from scratch 5-15% conversion to lead on a well-built B2B catalog $0 payment gateway fees (none needed) Specific scenarios where the format works best: - **B2B services.** Legal support, marketing services, IT outsourcing. Client browses, reads cases, submits a consultation request. - **Made-to-order products.** Custom furniture, metal structures, special equipment. Client sees the lineup, but configuration and price are discussed. - **Trade services.** Repairs, installation, maintenance. Service list with descriptions, «book a visit» form. - **Educational courses.** Where an interview is needed before enrolment, or pricing is flexible (scholarships, instalments). - **Medical services.** Where booking a consultation matters more than «one-click buy». - **Industrial equipment.** Price depends on configuration, delivery is negotiated, an invoice is needed. Not a fit for: everyday retail goods (full store needed), services with fixed prices and quick decisions (landing page is better), aggregators (need user accounts). ## Why Joomla + HikaShop without cart There are three typical approaches to a lead-form catalog. Let's compare. | Approach | Pros | Cons | | --- | --- | --- | | Tilda / Builder | Fast launch, nice out-of-box design | Scales poorly to 50+ cards with filters, limited filtering, no proper ACL | | WordPress + WooCommerce without cart | Huge plugin ecosystem | Working against the plugin architecture – hacks. Multilingual only via WPML ($$) | | Joomla 5 + HikaShop catalog mode | Native «no cart» support, multilingual out of the box, ACL for several roles | Fewer ready themes than WP, requires a developer experienced with Joomla | Why I pick Joomla + HikaShop for most clients: - **HikaShop has «catalog mode»** – one setting removes the cart, payment, order statuses. What remains is a filterable showcase + «request a quote» button. - **Multilingual is free** – Joomla supports RU+EN+DE+PL out of the box without WPML-class plugins ($60-100/year). - **ACL for different roles** – manager sees their leads, content editor updates descriptions, admin sees everything. Without plugins. - **Less «plugin zoo»** – Joomla with a base stack runs stable for years without weekly updates. - **Can become a full store later** – if the business grows into online payments in a year, HikaShop toggles the cart back with the same switch. **Alternatives:** for very small catalogs (10-30 items) you can build on static with dynamic forms. For large B2B with integrations (1C, SAP, customer accounts) – a different stack entirely (often Symfony/Laravel + custom admin). Joomla works in the middle range of 50-500 items. ## Launch in 3-5 weeks Realistic schedule for launching a catalog from scratch: 1. Briefwk 1 2. Structurewk 1-2 3. Cardswk 2-3 4. Forms+CRMwk 3-4 5. Launchwk 4-5 **Week 1 – brief.** Define categories, the typical card, filter fields, what data to collect in the request form, where leads go (Telegram chat, CRM, Google Sheets). Output: catalog structure as a single list. **Weeks 1-2 – structure.** Install Joomla 5, set HikaShop to catalog mode, configure multilingual (if needed), create categories and attributes. Build a brand-aligned template. **Weeks 2-3 – cards.** Fill the catalog: descriptions, specs, photos, videos (if any), downloadable documents. This stage usually takes the most time – depends on content readiness from the client. **Weeks 3-4 – forms and integrations.** Configure request forms: a global «leave a request», and per-card «ask about this item». Connect integrations: leads fly into the manager's Telegram chat + CRM (Bitrix24, AmoCRM, HubSpot) + Google Sheets as backup. **Weeks 4-5 – launch.** Final testing on desktop, mobile, tablet. Plug in analytics (Yandex.Metrika with goals, Google Analytics 4). Register in Google Search Console and Yandex.Webmaster, submit sitemap. Hand over access to the client with a short guide. ## What goes in a card The product/service card is the key element of a catalog. Its quality determines whether a client submits a request or leaves «to think about it». Required minimum: - Title – concise, with the key term (if SEO matters) - 2-3 quality photos or videos – not stock, but real - Short description (1-2 paragraphs) – what it is, who it's for, main benefit - Specs in a table – structured, not flowing text - Price «from» or a range – even rough, otherwise client thinks «probably expensive» - Timeline (production, delivery, completion) – specific, not «to be discussed» - «Ask about this item» form right on the card, not just the footer - Related items at the bottom, for navigation between options Extra elements that boost conversion (in my experience, 2-5% lift): - **Use context** – «fits for», «used in». Helps the client decide if it's their option. - **Comparison to similar items** – «how it differs from model X». Reduces questions in the form. - **Case or testimonial** – 1-2 sentences from a real client who ordered this exact item. - **Guarantees** – warranty period, return conditions, what's included in the price. - **Downloadable docs** – PDF spec sheet, certificates, manual. B2B clients love to «grab materials for internal approval». **Core principle:** the card should answer as many questions as possible before the client submits. The more certainty they gain on the card, the higher the chance they'll write to you instead of comparing with competitors. ## 7 common mistakes These mistakes I see regularly – from clients who built the catalog themselves or with a previous contractor. 1. **Building a lead-form catalog as a full online store.** They include cart, order statuses, all the extras. Result: client gets confused – «do I add to cart or write right away?». The cart needs to be off. 2. **Too many categories.** 15-20 categories for 50 items – overkill. Better 4-6 broad categories with filters inside. 3. **No form on the card.** Only in the footer. Client read the card, got hooked, wanted to click – had to scroll back. Some drop off. 4. **No price.** «Price on request» is the biggest conversion killer. Show at least a range or «from X». Otherwise client thinks «expensive = not for me». 5. **One generic contact manager for everything.** 50+ items need different owners. Joomla's ACL allows it – manager A sees leads in category 1, B in category 2. 6. **No analytics and goals.** Launched the catalog – «is it working?» – unknown. Yandex.Metrika with form-submit goals is mandatory from day one. 7. **No CRM connected.** Leads only go to email and get lost. You need: manager's Telegram chat + CRM + Google Sheets as backup. Three points – nothing gets lost. **Pro tip:** after the first 50-100 leads, analyse which items get more requests than others. You may want to surface them as «top» or «popular» – that's another 5-10% lift to conversion. ## Frequently asked questions How is a lead-form catalog different from an online store? In an online store the client adds to cart, pays online, gets the order automatically. In a lead-form catalog the client browses options, then submits a request – «want to discuss» – and a manager follows up. Fits B2B, services requiring discussion, made-to-order products, tender flows. Technically simpler: no online payments, no order statuses, just lead handling. Why Joomla and not Tilda or WordPress? Tilda is for marketing landings, scales poorly to 50+ cards with filters. WordPress + WooCommerce can be configured «without cart», but that's against the plugin's architecture. Joomla 5 + HikaShop in «catalog mode» is exactly for this task, with multilingual out of the box and clean ACL. For 50-500 items it's the optimal stack. How many items can the catalog hold? Without optimisation – 50-300 items comfortably. With caching and decent hosting – up to 5,000. Beyond that, you need dedicated solutions: either a specialised B2B platform, or a custom architecture. If you have 1,000+ SKUs that change actively – let's discuss separately. How do you measure catalog effectiveness? Main metric – conversion rate from card view to lead submission. Good benchmark: 5-15% for B2B, 2-5% for mass-market services. Measured via Yandex.Metrika or GA4 + form-submit goals. If conversion is below 2% – the problem is either the cards (no specifics, bad photos) or the form (long, scary). Can you add online payment later? Yes, HikaShop re-enables the cart via a setting in admin – literally a toggle. You can then connect payment gateways (Stripe, PayPal, local processors). The catalog architecture survives migration to a full store without frontend rebuild. That's a plus of choosing Joomla from the start. --- --- title: "AI Agents with RAG for Knowledge Base 2026" url: https://tema.name/en/blog/ai-agents-rag-knowledge-base-2026.html language: en description: "What RAG is, how it works, system components, common mistakes. Pinecone vs Qdrant vs pgvector. Implementation timeline and cost." date_published: 2026-05-27 date_modified: 2026-05-27 --- AI agents / RAG 27 May 2026 · 12 min read · By Artem # AI agents with RAG for knowledge base 2026: implementation guide A RAG agent over your knowledge base launches in **2-6 weeks** and costs **$1,500-8,000** depending on document volume and integrations. The pipeline: documents (PDF, DOCX, Notion, Confluence) get chunked into 300-800-token pieces, embedded with OpenAI `text-embedding-3-small` or Voyage AI ($0.02-0.13 per 1M tokens), stored in Qdrant, pgvector or Pinecone. On each query the system retrieves the 5-10 most relevant chunks and passes them to Claude or GPT-4o with strict "cite the source" instructions. Hallucination rate drops from 15-30% on a bare LLM to under 3% with a tuned RAG. Realistic 2026 use cases: internal support, customer FAQ, sales enablement, onboarding, regulatory Q&A. The article covers the full architecture, chunking and re-ranking strategies, eval metrics (precision@k, faithfulness), and the 6 mistakes that turn a good RAG into garbage. **In this article** 1. [What is RAG and why](#what-is) 2. [5 typical use cases](#use-cases) 3. [RAG system components](#components) 4. [Launch in 2-4 weeks](#workflow) 5. [Vector database comparison](#vectordb) 6. [7 common mistakes](#mistakes) 7. [FAQ](#faq) ## What is RAG and why Imagine ChatGPT that reads your corporate wiki, product docs, policies, resolved tickets before every answer – and gives a response **with links to specific documents** it sourced from. That's RAG. 50-5000 typical knowledge base size for b2b tasks 2-4wk implementation timeline for a basic agent 70-90% answer accuracy on properly prepared data $20-300/mo operating cost for mid-sized business Why regular ChatGPT doesn't fit most business tasks: - **Doesn't know your product.** ChatGPT hasn't read your docs, doesn't know specifics, will invent «plausible» but inaccurate answers. - **Cut-off date.** Even Claude or GPT-4 are trained on data up to a certain date. Product changes after that – unknown. - **No source citations.** User can't verify where the answer came from – less trust. - **Expensive to dump everything into context.** 200K-token context window – but 1000 PDFs won't fit, and per-query cost would be huge. RAG solves all four. Before responding, the system **finds 3-7 most relevant chunks** in your base and passes them to the LLM as context. The LLM forms an answer based on those chunks, with citations. **Main point:** RAG doesn't replace ChatGPT – it complements it. ChatGPT gives «general world knowledge», RAG gives «knowledge of your specific company, product, domain». Together – a powerful tool. ## 5 typical use cases ### 1. Support over product documentation Client asks in the site chat or a Telegram bot. RAG searches docs, FAQ, resolved tickets. Closes 60-80% of typical questions without a human. Complex cases handed to an operator with a pre-collected summary. ### 2. Internal search across corporate wiki A new hire doesn't remember «how do we handle business travel» or «where is the client communication policy». Asks the RAG agent. It finds the doc in Notion/Confluence/Google Docs, quotes the relevant part, links to the full doc. ### 3. Sales assistant on products A salesperson in a client meeting. Client asks a complex technical question. The salesperson opens the RAG chat, asks, gets an answer with links to tech specs, contracts, cases. Response speed to client – ×3-5. ### 4. Legal document analysis A lawyer uploads a contract. RAG checks it against corporate standards («mandatory clauses», «red flags»), highlights differences and risks, cites precedents from previous deals. ### 5. Educational assistant A student in an online course asks a question. RAG finds the answer in course materials, slides, lecture transcripts. Removes 70% of typical questions from the tutor, improves course completion rate. This isn't an exhaustive list. RAG applies anywhere there's a **large base of semi-structured text** and recurring questions about it. ## Components of a RAG system RAG isn't «one service», it's a pipeline of 6-7 components. Each must be matched to the task. - **Data source** – PDF, web pages, Notion, Confluence, Google Docs, SharePoint, CSV/Excel, databases. The source determines how to extract text. - **Parser and chunker** – splits documents into 300-800 token chunks. Chunk size strongly affects search quality. - **Embeddings model** – converts text to vectors. OpenAI text-embedding-3-small (universal), Voyage-large (more accurate on code), Cohere embed-multilingual (multilingual). - **Vector database** – stores vectors and quickly finds «similar». Pinecone, Qdrant, Weaviate, pgvector in Postgres. - **Retrieval logic** – finds top-K chunks, optional re-ranking (Cohere Rerank, Voyage Rerank) for higher accuracy. - **LLM** – forms the final answer based on found chunks. Claude Sonnet (long contexts), GPT-4 (universal), Mistral/Llama (local). - **Prompt template** – model instruction: «answer only based on documents below, always cite sources, if you don't know – say so directly». - **UI or API** – chat on the site, Telegram bot, Notion widget, or REST API for integrating into your product. **Without any component it won't work.** I often see: bought Pinecone, dumped 200 PDFs whole, gave to ChatGPT – «doesn't work». Of course it doesn't: no chunker, wrong embeddings, no prompt tuning. RAG is a pipeline, not a service. ## Launch in 2-4 weeks Realistic schedule for launching a basic RAG agent from scratch: 1. Datad 1-3 2. Chunkingd 4-6 3. Embeddingsd 7-10 4. Retrievald 11-16 5. UI+testsd 17-21 **Days 1-3 – data.** Gather all sources: what we want the agent to know. Clean: remove outdated, duplicates, garbage. At this point we usually discover «our docs were last updated 3 years ago» – part of the work is on the client side. **Days 4-6 – chunking.** Parse documents, split into chunks. Lots of nuances here: PDF with tables needs special handling, code blocks can't be cut mid-block, headings need to be kept with context. Not «one universal chunker for all», but adapted. **Days 7-10 – embeddings.** Connect OpenAI or Voyage API, run all chunks through the embeddings model. Save to vector-DB. For RU+EN content I use multilingual models; for pure English – text-embedding-3-small is enough. **Days 11-16 – retrieval.** Set up search: top-K (usually 5-10), similarity threshold, optional re-ranking. Test on 20-30 typical questions: does it return relevant chunks? If not – tune: change chunk size, embeddings, prompt. **Days 17-21 – UI and tests.** Build the interface: chat on the site via iframe, Telegram bot, Notion widget, or REST API. Connect monitoring: query logs, user ratings (👍/👎), accuracy metrics. Final testing with real users. ## Vector database comparison Choice of vector-DB affects cost, speed, scaling convenience. Three popular options: | Solution | Pros | Cons | | --- | --- | --- | | Pinecone | Managed, fast start, zero DevOps | More expensive at scale ($70+/month), vendor lock-in, no self-host | | Qdrant | Open source, self-host for free, or Qdrant Cloud. High speed | Needs basic infra (Docker) for self-host | | PostgreSQL + pgvector | If you already have Postgres – install the extension, no new infra | Slightly slower on huge sets (10M+ vectors), needs indices | | Weaviate | Hybrid search (vectors + keywords), modules for different embeddings | More setup complexity than Pinecone/Qdrant | My recommendations: - **Prototype / MVP** – Pinecone free tier or Qdrant locally. Fast start, no infra concerns. - **Production up to 1M vectors** – Qdrant self-hosted on a VPS ($10-30/month) or Pinecone starter ($70/month). - **Already have Postgres** – pgvector, no new infra, convenient for the team. - **Enterprise 10M+ vectors** – Pinecone enterprise or Qdrant Cloud with replicas. ## 7 common mistakes 2 years of active RAG work – here are the top problem causes. 1. **Loading everything indiscriminately.** Garbage in = garbage out. 80% of the work goes to data prep: cleaning, normalisation, removing outdated. Not a «technical detail», but half the success. 2. **Chunks too big.** If a chunk is a whole page, the model finds «this page» instead of «that specific paragraph». Accuracy drops. Optimal – 300-800 tokens with 50-100 overlap. 3. **Chunks too small.** If a chunk is 1 sentence – context is lost: «it» refers to nothing. Too short is also bad. 4. **One embedding model for all languages.** If you have RU+EN content – you need multilingual embeddings (Cohere multilingual, OpenAI text-embedding-3-large). Otherwise cross-language search breaks. 5. **No re-ranking.** Top-K from vector search often contains «similar but not exact». Re-ranking model reorders by relevance – 15-30% accuracy lift. 6. **Ignoring citations.** Answer without source links = no trust. Prompt must require citations explicitly: «put source in brackets after each fact». User sees link → clicks → verifies → trusts. 7. **Not refreshing the base.** After 3-6 months docs become outdated, answers turn false. Need a regular re-indexing process: auto on Notion/Confluence change, or weekly cron. **Good sign that RAG is working:** users start trusting it more than the wiki search. If after 1-2 months you see agent queries growing and support queries dropping – the system works. If the opposite – problem in answer quality, time to debug. ## Frequently asked questions How is a RAG agent different from regular ChatGPT? Regular ChatGPT answers from data it was trained on (up to the cut-off date). It doesn't know your product, documents or internal processes. A RAG agent searches relevant chunks in your knowledge base (docs, articles, policies) before answering – with source citations. Essentially «ChatGPT that reads your documents before answering». How much does it cost to deploy a RAG agent? Basic agent on 50-500 documents: 2-4 weeks of development + $20-100/month on vector-DB and LLM API. For a business with average traffic (100-500 queries/day) – ~$100-300/month. Large enterprise installations with 10,000+ documents and thousands of daily queries – from $1000/month. Exact estimate – after a short brief. How many documents can RAG realistically handle? From 10 to millions. No technical upper limit. 10-100 documents – any vector-DB works. 1,000-10,000 – managed (Pinecone) or self-hosted Qdrant. Over 100,000 – needs chunking optimisation, hierarchical retrieval, sometimes separate indices per content type. In my practice 500-5,000 documents is the most common size. Is my data safe with OpenAI or Anthropic? API calls (paid plans) – your data is not used for training, this is in the Terms of Service of both providers. For sensitive data there are options: enterprise plans with signed DPA, local models (Llama, Mistral) on your server, or hybrid approach. For most b2b tasks API plans are enough. For PII or medical – local model or enterprise. Pinecone, Qdrant or PostgreSQL+pgvector – which is better? Pinecone – fast start, managed, more expensive at scale ($70+/month). Qdrant – open source, self-host for free, or Qdrant Cloud. PostgreSQL+pgvector – if you already have Postgres, add the extension, no new infra. For 10-100K vectors all three work. For millions – Pinecone or Qdrant Cloud. For teams without DevOps – Pinecone is simplest. --- --- title: "Cloudflare Workers for Business 2026: Guide" url: https://tema.name/en/blog/cloudflare-workers-for-business-2026.html language: en description: "Cloudflare Workers for business 2026: what it is, 5 use cases, comparison with Lambda/Vercel, common mistakes. Launch without your own server in minutes." date_published: 2026-05-28 date_modified: 2026-05-28 --- Serverless / Edge May 28, 2026 · 11 min read · Author: Artyom # Cloudflare Workers for business 2026: a practical guide Cloudflare Workers makes sense for business when you need code at the edge with **under 5ms cold start** across **330+ locations**, on a free tier of 100,000 requests per day or $5/month for 10 million. Five concrete uses that pay for themselves in week one: A/B testing with no extra JS, geographic redirects and pricing, lead-form proxy to a CRM with anti-bot filtering, image resizing on the fly, edge auth for paid content. Stack: TypeScript or JavaScript, Wrangler CLI for deploy, KV or D1 for state, R2 for object storage. Compared to AWS Lambda: 10-50× faster cold start, no VPC config, simpler pricing. Compared to Vercel Edge: same V8 isolate model but cheaper at scale and works for non-Next.js stacks. The article covers each use case with working code, the 4 cases where Workers is the wrong tool, and migration tips from Lambda. **In this article** 1. [What Workers is and its ecosystem](#what-is) 2. [5 business use cases](#use-cases) 3. [Comparison with alternatives](#compare) 4. [Launching your first Worker in an hour](#workflow) 5. [7 common mistakes](#mistakes) 6. [Frequently asked questions](#faq) ## What Workers is and the ecosystem Cloudflare Workers is **serverless edge compute**. You write a function in JavaScript/TypeScript (or Rust/Python via Pyodide), deploy it via CLI or git, and it instantly runs in 330+ cities around the world – Cloudflare itself deploys it to the server closest to the user. 330+ edge locations worldwide for code deployment 100K/day requests free on the free plan ~5-50ms typical Worker response time $5/mo paid plan: 10 million requests per month The key difference from classic clouds: **code runs on the same network as the CDN**. There's no concept of "instance", "region", or "availability". There's almost no cold start – V8 isolate starts up in 5ms. Around Workers, Cloudflare has built a whole ecosystem of services: - **KV (Key-Value)** – distributed storage for cache, sessions, feature flags. Free up to 100K reads per day. - **R2 (Object Storage)** – S3-compatible storage for files. The key feature: free egress (with AWS S3 you pay for every byte sent out). - **D1 (SQL Database)** – SQLite at the edge. $5/month for 10GB. Suitable for most web applications up to 10M requests. - **Durable Objects** – objects with consistent state. For chat rooms, queues, WebSocket applications. - **Queues** – message queues for asynchronous processing. - **Workers AI** – running open-source models (Llama, Mistral, embeddings) directly at the edge. Without sending data to third parties. - **Hyperdrive** – accelerated connection to external PostgreSQL/MySQL/MongoDB. **The main point:** Workers isn't a "server replacement" – it's a different approach. You write small functions that run close to the user, without managing infrastructure. For 70-80% of business tasks, that's enough. ## 5 use cases for business ### 1. Telegram bot without your own server The most common use case. A Telegram bot via webhook is an HTTP endpoint that receives POST requests. A Worker handles this perfectly. Session state goes in KV (free 100K reads/day). Integrations with CRM or OpenAI – via fetch to their API. No VPS, no PM2 or systemd – deploy and forget. ### 2. Processing forms from your site A request form on a static landing → Worker → forward to the manager's Telegram chat / email / CRM. Spam protection (honeypot, rate-limit) is a couple of lines on the Worker. One Worker can serve forms for 10 sites in parallel. The free plan is more than enough for the average business. ### 3. AI proxy for protecting API keys Want to give users access to ChatGPT/Claude through your UI? You can't call OpenAI/Anthropic directly from the browser – the API key would leak. A Worker as a proxy: the frontend calls the Worker, the Worker adds the API key from environment variables and calls OpenAI. The key never leaves the server. ### 4. Image optimization on-the-fly Cloudflare Images or your own Worker with the Polish library: image optimization "on the fly". You upload the original to R2, the Worker resizes it, converts it to WebP/AVIF, adds a watermark – via URL parameters. PageSpeed +20-30 points on sites with lots of images. ### 5. Geo-routing and A/B testing A Worker sees the country, region, and browser language of the user. You can route Russians to `tema.name/`, Germans to `/de/`, Poles to `/pl/`. Same for A/B tests: different page versions without a separate service. All "experiment = second page" logic is handled at the edge, before the request hits your origin. **Not suitable for:** heavy video processing (50ms CPU per request limit on the paid plan), monolithic Django/Rails applications with thousands of dependencies, tasks requiring long state (>30 seconds). ## Comparison with alternatives | Parameter | Cloudflare Workers | AWS Lambda | Vercel Functions | | --- | --- | --- | --- | | Regions | 330+ edge locations | One region (you pick manually) | Edge + regions | | Cold start | ~5ms | 200-2000ms (Node.js), worse on Java | 50-300ms | | Languages | JS/TS/Rust/Python (Pyodide) | Node.js/Python/Go/Java/Ruby/.NET | JS/TS, Python | | Free plan | 100K requests/day | 1M requests/month | 100K requests/month | | Cost of 10M requests | $5/month | ~$20/month + GB-seconds | ~$20/month | | Lock-in | Cloudflare ecosystem | AWS ecosystem (S3, DynamoDB...) | Vercel + Next.js focus | | Idle to first request | Instant | Up to 2 seconds (cold start) | Up to 300ms | My recommendations: - **If you're already on Cloudflare** – Workers is a "free extension" to what you already pay for. Fewer bills, fewer providers. - **If you have a heavy AWS stack** (RDS, DynamoDB, SQS) – Lambda is more convenient, everything in one VPC. - **If your frontend is Next.js / Nuxt / Astro on Vercel** – Vercel Functions is more convenient, server code in the same repo. - **If you have a global audience** – Workers wins thanks to edge locations (the CDN places code in the data center closest to the user). ## Launching your first Worker in an hour A realistic timeline for launching your first production Worker from scratch: 1. Setup10 min 2. Code15 min 3. Deploy5 min 4. Routes10 min 5. Tests20 min **Setup (10 min).** Register a Cloudflare account (if you don't have one), install the `wrangler` CLI (`npm install -g wrangler`), `wrangler login` – it opens the browser for authorization. At this stage you already have a working environment. **Code (15 min).** `wrangler init my-worker` creates a template. A basic Worker is 10 lines of TypeScript code: takes an HTTP request, returns a Response. For a Telegram bot you add JSON handling and a call to the Telegram API via fetch. **Deploy (5 min).** `wrangler deploy` – the Worker is immediately available at `\*.workers.dev`. Logs via `wrangler tail`. No Docker, no CI/CD, no Kubernetes. **Routes (10 min).** If you already have a domain on Cloudflare – in the Workers dashboard you add a Route: `api.yourdomain.com/\*` → your Worker. From this point on, requests to this URL go to the Worker. **Tests (20 min).** Local testing with `wrangler dev`. You connect KV/D1/R2 via `wrangler.toml` bindings. Edge cases: what the Worker returns on an empty request, on a huge one, on a request with broken JSON. Deploy with `wrangler deploy --env production`. **Pro tip:** for the server side of a Telegram bot, one Worker + KV for state is enough for 95% of tasks. You don't need Redis, PostgreSQL, or Docker. A bot with 1000 users per day fits within the free plan. When 10,000 come – pay $5/month. ## 7 common mistakes These pitfalls I've seen with clients and stepped on myself. 1. **Storing state in a global variable.** Worker is stateless – each request can hit a different server. State goes in KV/D1/Durable Objects, not in a variable. 2. **Ignoring the CPU limit.** 10ms on free, 50ms on paid. Heavy cryptography or a big JSON.parse may not finish in time. Profile with `wrangler dev --remote`. 3. **Not using Wrangler secrets for keys.** Putting an OpenAI API key in code = it ends up in git. Use `wrangler secret put` – the key is stored encrypted at Cloudflare. 4. **Doing sync operations on every request.** Every fetch to an external API costs time. Cache reusable data in KV or the Cache API. 5. **Forgetting about Origin headers.** CORS blocks requests from the frontend. The Worker must explicitly return `Access-Control-Allow-Origin` – the user won't see the response without it. 6. **Deploying without tests.** The Worker goes to production instantly. Make a separate environment for staging: `wrangler deploy --env staging`. 7. **Not enabling analytics.** Cloudflare has free Workers Analytics – requests, errors, latency by region. Without it you have no idea what's going on. ## Frequently asked questions What is Cloudflare Workers in simple terms? It's code that runs on Cloudflare servers around the world, close to the user. You write a JavaScript/TypeScript function, deploy it, and it works in 330+ cities worldwide. No need for your own server, no Docker, no PM2. There's almost no cold start – response in 5-50ms. Suitable for APIs, forms, Telegram bots, proxies, auth, image processing. How much does Cloudflare Workers cost? Free plan: 100,000 requests per day for free, up to 10ms CPU per request. This is enough for most projects up to 100K visits per month. Paid plan: $5 per month for 10 million requests, up to 50ms CPU. This is many times cheaper than AWS Lambda for the same volume. How is Workers different from AWS Lambda? Lambda runs in one AWS region, Workers – on 330+ edge locations. Lambda has a cold start of 200-2000ms, Workers – less than 10ms. Lambda – Node.js/Python/Go/Java/Ruby, Workers – JavaScript/TypeScript/Rust/Python (via Pyodide). For global APIs and web applications, Workers is faster and simpler; for heavy tasks (video processing, ML inference), Lambda is more flexible. Can you connect a database to Workers? Yes. Cloudflare has its own services: D1 (SQLite at the edge, $5/month for 10GB), KV (key-value, for cache and sessions), R2 (S3-compatible storage with no egress fees), Durable Objects (state consistency). You can also connect to external databases via Hyperdrive (accelerated PostgreSQL) or directly through the connection API. Is Workers suitable for a Telegram bot? It's perfect. A Telegram bot via webhook is an HTTP endpoint that receives requests from the Telegram API. Workers handle this load even on the free plan up to 100K messages per day. Session state can be stored in KV (free 100K reads/day), CRM/OpenAI integrations – via fetch to their API. No VPS needed. --- --- title: "PageSpeed 100 out of 100 in 2026: how and why" url: https://tema.name/en/blog/pagespeed-100-out-of-100-2026.html language: en description: "How to hit PageSpeed 100/100 in 2026: Core Web Vitals, LCP/INP/CLS, a realistic week-long optimisation plan, 7 mistakes and FAQ." date_published: 2026-05-29 date_modified: 2026-05-29 --- Performance / SEO 29 May 2026 · 11 min read · Author: Artem # PageSpeed 100 out of 100 in 2026: how and why PageSpeed 100/100 mobile in 2026 means **LCP under 2.5s**, **INP under 200ms**, **CLS under 0.1**. The recipe: critical CSS inlined in `` capped at 14 KB, the rest deferred. Images in AVIF or WebP with explicit `width`/`height` and `loading="lazy"`. Fonts with `font-display: swap` plus `preload` for the one used above the fold. Heavy JS frameworks swapped for vanilla where the page allows — that alone removes 100-300 KB. Server side: Brotli, HTTP/2 or HTTP/3, immutable cache for 1 year on hashed assets. A real corporate site moves from 45 to 98 mobile in **5-7 working days**, cost $400-1,200. Note: chasing the full 100 past 95 rarely changes rankings — Core Web Vitals only care about the 75th-percentile thresholds. The article gives the step-by-step plan and 7 mistakes that wipe the score. **In this article** 1. [Why speed even matters](#why) 2. [Core Web Vitals: LCP, INP, CLS](#vitals) 3. [7 main speed factors](#factors) 4. [A one-week optimisation plan](#workflow) 5. [7 common mistakes](#mistakes) 6. [FAQ](#faq) ## Why speed even matters Three pragmatic reasons – no ideology, no "because Google said so". 90+ Mobile PageSpeed for proper ranking -7% conversion drop for every extra second of load 2.5s maximum LCP to stay in the green zone 53% of users leave if a page takes > 3 seconds to load - **SEO factor.** Google has counted Core Web Vitals as a ranking factor since 2021. On competitive queries, a fast site beats a slow one, all else equal. - **Conversion.** Every extra second of load drops conversion by 5-7%. On e-commerce it's worse. Direct lost revenue. - **Ad costs.** Google Ads gives CPC discounts for fast landing pages and penalises slow ones. Your media budget literally feels it. **Bottom line:** the goal isn't "100/100", it's "green across all Core Web Vitals". 90+ Mobile in PageSpeed Insights is already an excellent result and delivers the maximum that Google factors into rankings. ## Core Web Vitals: LCP, INP, CLS These are the three metrics Google measures on real users via Chrome (CrUX data). They've been part of the ranking algorithm since 2021. ### LCP (Largest Contentful Paint) How long until the largest above-the-fold element appears – usually the main image or a big heading. **Good: < 2.5s.** Bad: > 4s. Main culprits behind a poor LCP: heavy hero images without `fetchpriority="high"`, no `preload`, a slow server (TTFB), blocking scripts in the head. ### INP (Interaction to Next Paint) Replaced FID in 2024. Measures how fast the page responds to a click/tap/keypress. **Good: < 200ms.** Bad: > 500ms. Main culprits behind a poor INP: heavy JS on the main thread, synchronous event handlers, long `setTimeout` chains. This is the "modern" headache: even if the page loaded quickly, it can still stutter on clicks because of bad JS. ### CLS (Cumulative Layout Shift) The total amount of layout "jumping" during load. A banner at the top loads in and shoves all the text down = bad CLS. **Good: < 0.1.** Bad: > 0.25. Main culprits: images without explicit width/height, fonts that change size when they swap in, ad blocks, dynamically inserted elements. ## 7 main speed factors This is the baseline checklist. In 90% of cases these items alone deliver 70-90% of the PageSpeed gain. - **Images in WebP/AVIF + lazy load.** 80% of page weight is images. Converting PNG/JPG to WebP cuts size by 40-60%. AVIF is even better but support is slightly worse. - **Minification and Brotli compression.** CSS/JS must be minified. The server should serve Brotli (or at least gzip). Cloudflare does this automatically. - **Drop unused CSS/JS.** Any `bootstrap.css` or `jquery.js` that isn't at least 30% used – delete it. PurgeCSS + tree-shaking in your bundler. - **Fonts with font-display: swap.** Without it the user stares at a white screen for 1-2 seconds while the font loads. With swap they see the system font first, then it gets replaced. - **Preload the hero image + preconnect to your CDN.** `` shaves 0.5-1.5 seconds off LCP. - **CDN (Cloudflare).** If the site is hosted in one region but users are global, no-CDN pages load 3-5 seconds purely because of geography. Cloudflare solves this for free. - **HTTP/2 or HTTP/3.** A modern protocol with multiplexing. Toggle one checkbox in your host or Cloudflare. Without it the browser downloads files sequentially instead of in parallel. **The 80/20 rule:** WebP images + Brotli compression + hero preload + Cloudflare CDN deliver 80% of the result for 20% of the effort. Start with those four. Everything after is fine-tuning. ## A one-week optimisation plan A realistic schedule for pushing a site from 40-50 Mobile to 90+: 1. Auditday 1 2. Imagesday 2-3 3. CSS/JSday 4 4. CDN/HTTPday 5 5. Finalday 6-7 **Day 1 – audit.** Run the site through [PageSpeed Insights](https://pagespeed.web.dev) + Lighthouse in DevTools. Record current LCP/INP/CLS, TBT, total page weight. That's your baseline. In parallel – WebPageTest for waterfall analysis. **Day 2-3 – images.** Convert all JPG/PNG to WebP (batch via the `cwebp` CLI or Squoosh.app). Add `width`/`height` attributes to every `` (fights CLS). The hero image gets `fetchpriority="high"` and a preload in the ``. The rest – `loading="lazy"`. **Day 4 – CSS/JS.** Minification (if you haven't already). Strip unused CSS with PurgeCSS. Scripts not needed for the first screen – `defer`. Analytics and trackers – async or after `DOMContentLoaded`. **Day 5 – CDN and HTTP/3.** Hook up Cloudflare (if you haven't already) – free, takes 5 minutes. Enable Brotli, HTTP/3, Auto Minify, Rocket Loader (cautiously – it can break JS). Set cache rules for static assets (1 year for assets with a hash in the filename). **Day 6-7 – final.** Re-run PageSpeed. Targeted fixes for what's left: third-party scripts in iframes, fonts with font-display, removing unnecessary preconnect tags. Final measurement. If you're at 90+ Mobile – mission accomplished. ## 7 common mistakes I see these traps regularly – with clients coming off a previous contractor or after DIY attempts. 1. **Optimising Desktop, forgetting Mobile.** Mobile-first indexing has been the default since 2019. Google ranks based on the mobile version. Desktop 95 + Mobile 45 = it ranks like a 45. 2. **Testing only in Lighthouse, ignoring field data.** Lighthouse is lab data. Search Console shows real CWV from real users. They can differ. 3. **"WP-Optimize plugin helps – let's install it".** Optimiser plugins often conflict and do unpredictable things. One properly configured plugin beats three "helping" each other. 4. **Lazy-loading the hero image.** The biggest mistake. Lazy load on an above-the-fold image = LCP goes up. Lazy load is only for images below the first screen. 5. **Heavy fonts with no preload and no font-display.** An 800-weight font with 5 languages = 200KB. Without font-display: swap – 1-2 seconds of white screen. With preload – LCP drops noticeably. 6. **Third-party scripts in the head.** Yandex.Metrika + Google Analytics + Facebook Pixel + Hotjar + … synchronously in the head – TBT (Total Blocking Time) goes red. Move them to the footer or load them asynchronously. 7. **Ignoring server-side performance.** TTFB (Time to First Byte) is often a backend problem: slow PHP, unoptimised SQL queries, no server-side caching. Client-only optimisation won't save you if the server itself responds in 2 seconds. **A good sign the optimisation is working:** after 28 days, Search Console's Core Web Vitals section moves pages from "Poor" / "Needs improvement" to "Good". Not instant – CrUX data is collected on a 28-day rolling window. ## Frequently asked questions Why chase PageSpeed 100/100? You don't have to push for 100/100 at any cost. A score above 90 (Mobile) already delivers the maximum that Google factors into rankings. 95-100 is more about bragging rights and a clean Core Web Vitals report in Search Console. The real goal is the green zone: LCP < 2.5s, INP < 200ms, CLS < 0.1. That's what Google has been using as a ranking factor since 2021. What are Core Web Vitals in plain English? Three metrics Google measures on real users via Chrome: LCP (Largest Contentful Paint) – how fast the main content appears, INP (Interaction to Next Paint) – how quickly the page responds to clicks/taps, CLS (Cumulative Layout Shift) – whether the layout jumps around while loading. INP replaced FID in 2024. Mobile or Desktop – which matters more? Mobile. Google uses mobile-first indexing – it ranks based on the mobile version. You want Mobile PageSpeed above 80, ideally above 90. Desktop usually catches up on its own once the mobile build is optimised. How long does it take to get to 90+? Depends on the starting point and the stack. Static landing page: 1-3 days. Corporate site on Joomla/WordPress: 1-2 weeks. E-commerce store with heavy logic: 2-4 weeks. Starting from 30-40 on Mobile – a month is realistic. From 60-70 – one week. Does PageSpeed actually affect conversion? Directly. Data from Google and Amazon: +1 second of load time = -7% conversion in e-commerce. For landing pages it's smaller: +1s = -3-5%. Slow sites also get fewer return visits – users remember "that site was sluggish" and don't come back. --- --- title: "Headless CMS vs Traditional CMS in 2026: Which to Choose" url: https://tema.name/en/blog/headless-vs-traditional-cms-2026.html language: en description: "Headless CMS vs traditional CMS in 2026: differences, use cases. Strapi/Sanity/Contentful vs Joomla/WordPress, mistakes, FAQ." date_published: 2026-05-30 date_modified: 2026-05-30 --- Stack choice May 30, 2026 · 11 min read · Author: Artem # Headless CMS vs traditional CMS in 2026: which to choose The decision is straightforward: **traditional CMS (Joomla, WordPress)** fits about **80% of business cases** — landing pages, corporate sites, blogs, shops up to 5,000 SKUs. Launch time 2-4 weeks, cost baseline 1×, one person can run the whole site. **Headless (Strapi, Sanity, Contentful)** only pays off when you have multiple frontend channels at once (web + mobile app + kiosks + smart TV), a dev team of 3 or more, and budget **2-3×** a comparable monolith. The editor learning curve is noticeably steeper, but you get 95-100 PageSpeed by default and clean APIs for any new frontend. Wrong reasons to go headless: "it's modern", "WordPress feels slow", a single React developer on the team. The article covers the detailed stack comparison, who each option suits per business scenario, and the 7 most common migration mistakes. **In this article** 1. [What is a headless CMS](#what-is) 2. [Stack and architecture – comparison](#stack) 3. [Who each approach suits](#use-cases) 4. [Strapi vs Sanity vs Contentful](#tools) 5. [7 common mistakes](#mistakes) 6. [Frequently asked questions](#faq) ## What is a headless CMS In a traditional CMS (Joomla, WordPress, Drupal), there are three layers that are tightly coupled: the **admin panel**, where editors write content, the **database**, where it's stored, and the **theme (template)**, which renders the pages. Change the theme – change the design. Change the CMS – change everything. ~5% share of headless among all CMS-based sites in 2026 3-6wk migration time from traditional CMS to headless 95+ typical PageSpeed Mobile for Jamstack sites 2-3× higher development cost of headless vs traditional CMS In a **headless CMS**, only the admin and the database remain. The frontend is your own, built on any technology. The CMS delivers content via REST or GraphQL API. The frontend developer takes the API and renders pages any way they want. A simple analogy: a traditional CMS is a car with a ready-made body. Headless is a chassis with an engine – you fit the body yourself for your tasks. More flexibility, but more work. ## Stack and architecture – comparison | Parameter | Traditional CMS (Joomla, WP) | Headless CMS | | --- | --- | --- | | What's included | Admin + DB + frontend themes | Admin + DB + API. Frontend separate. | | Who renders pages | CMS theme (PHP templates) | Any frontend: React, Vue, Astro, Next.js | | Team needed | 1 fullstack developer | Frontend developer + backend (or 1 fullstack) | | Load speed | 60-85 PageSpeed Mobile out of the box | 95-100 (static rendering) | | SEO | Out of the box, plugins | Hand-built, but greater control | | Multi-channel | Web only | Web + mobile + digital signage + email | | Development cost | Base (1×) | 2-3× base | | Maintenance cost | Plugin updates | Frontend + CMS updates separately | | Editor learning curve | Simple, familiar | Similar, but "disconnected" from the final view | **The main point:** headless isn't an "improvement" of traditional CMS – it's a different architecture with different trade-offs. You gain flexibility and speed – you lose simplicity of maintenance and pay more for development. ## Who each approach suits ### When to choose a traditional CMS (Joomla, WordPress) - **Corporate website with 10-50 pages.** A team of 1-3 editors, one-off development, minimal customization. Joomla or WordPress covers 95% of tasks. - **Blog or media outlet.** WordPress is the de-facto standard for content projects. Huge ecosystem, convenient editor for non-techies. - **Small e-commerce.** WooCommerce (WP) or VirtueMart/HikaShop (Joomla) work well up to 5000 SKUs. - **Small local team.** If you don't have a frontend developer and no plans to hire one – traditional CMS wins. - **Quick launch on a fixed budget.** Launching a landing page in 1-2 weeks from ready themes + plugins is easier on a traditional CMS. ### When headless is justified - **Multiple consumption channels.** Content goes to the website + iOS app + Android app + digital signage in stores + email newsletters. One source of truth via API. - **The team already works in React/Vue/Next.** Why learn a new CMS theme if the frontend developer can render through Next.js or Astro. - **Performance-critical websites.** If every 0.1 second of load time = millions in revenue (large e-commerce, advertising with expensive CPC). - **Complex UI customization.** When standard themes don't fit, you need interactive dashboards, custom widgets, real-time data. - **Team of 5+ editors with different roles.** Good headless CMSs have flexible permission systems, multi-stage workflows, versioning. **Don't confuse "headless" and "Jamstack":** headless is the CMS architecture (without its own frontend). Jamstack is a deployment approach: static + JS + API. You can be headless without Jamstack (server-rendered via SSR) and Jamstack without headless (pure static without any CMS). ## Strapi vs Sanity vs Contentful The three most popular headless CMSs on the market. How they differ. | Parameter | Strapi | Sanity | Contentful | | --- | --- | --- | --- | | Hosting | Self-hosted (Docker, VPS) | Managed (cloud) | Managed (cloud) | | Open source | Yes, MIT license | Studio – open source, backend – no | No | | Price (free) | Free (only hosting) | Up to 10K docs, 100K requests/month | Up to 50K records | | Price (paid) | ~$60-$200/month (cloud) | $99-$1000+/month | $300+/month | | Editor | Basic, decent | Highly customizable (Studio) | Mature, for teams | | API | REST + GraphQL | GROQ + GraphQL | REST + GraphQL | | Best for | Teams with DevOps, control | Startups, flexibility, quick start | Enterprise, large teams | My recommendations by scenario: - **MVP or prototype, limited budget.** Sanity free tier. Launch in 2-3 days, editor schemas in code, free tier lasts a long time. - **Corporate project, flexibility + control.** Strapi self-hosted on your own VPS or Strapi Cloud. Full control over the data. - **Enterprise with team and compliance.** Contentful. SLA, support, security out of the box, ready integration with marketing platforms. ## 7 common mistakes 1. **Choosing headless "because it's trendy".** If you have 5 editors and one site – traditional CMS is usually more cost-effective. Headless is justified architecturally, not "because Twitter praises it". 2. **Underestimating frontend development cost.** Headless CMS is only 30% of the system. 70% is the frontend application. The budget for a frontend developer and their maintenance is often larger than for the CMS itself. 3. **Forgetting about preview.** Editors want to see how a post will look. On traditional CMS this is "by default". On headless, preview has to be built separately (Next.js Preview Mode, Sanity Visual Editing). 4. **Ignoring i18n from the start.** If you need multilingual support later, migrating is harder. Plan support from the architecture – through locale in schemas. 5. **Not setting up API caching.** Every request to a headless API is an HTTP request. At peak load without CDN cache, the API goes down. Cloudflare R2 / Vercel ISR / Astro static – the solution. 6. **Using headless for a team without a frontend developer.** If you don't have a permanent frontend dev – in 6 months there will be no one to update Next.js and React. The CMS turns into an "abandoned project". 7. **Jumping straight to enterprise tier.** Contentful Pro at $300/month is overkill for a 1000-page project. Start with free / starter and move up as you grow. **Middle-ground option:** "WordPress as headless". WordPress remains as the CMS (familiar editor for the team), but the frontend is built on Next.js or Astro via WP REST API / WPGraphQL. You get 80% of the Jamstack benefits without the pain of migration. A good compromise for blogs and media sites. ## Frequently asked questions What is a headless CMS in simple terms? It's a CMS that has only a backend (admin panel + API), and you build the frontend yourself – on any framework (React, Vue, Astro, Next.js). In traditional CMS like Joomla or WordPress, the admin and frontend are tightly coupled. With headless, you get content via REST or GraphQL and render it however you want. Pros: flexibility, speed, multi-channel. Cons: you need a frontend developer. When is headless better than traditional CMS? When you have multiple content consumption channels (website + mobile app + digital signage + email), when you need maximum speed (Jamstack approach), when your team works with modern frontend frameworks, or when you need fine-grained UI customization without CMS theme limitations. For a typical corporate site or blog, traditional CMS is usually enough. How much does headless CMS cost? It depends on your choice. Strapi self-hosted – free (only hosting). Sanity Free tier – up to 10K documents and 100K API requests per month free. Contentful Free – up to 50K records. Sanity/Contentful paid plans: $99-$300/month. Joomla/WordPress – $0 (only hosting). Headless is usually more expensive because you need a frontend developer plus the CMS service. Strapi vs Sanity vs Contentful – which is better? Strapi – self-hosted, open source, maximum control, ideal for teams with DevOps. Sanity – managed, flexible data schemas, excellent editor (Sanity Studio). Contentful – the most mature enterprise option, more plugins and integrations, but more expensive. For prototypes and startups – Sanity. For large business – Contentful. For those who want everything in-house – Strapi. Can you migrate from WordPress to headless? Yes. You can keep WordPress as headless – it has REST API and the WPGraphQL plugin. This gives a transitional option: the team keeps working in the WP admin, while the frontend is built on Next.js or Astro. This is often the optimal migration path – not breaking processes but getting Jamstack performance. Migration timeline – 3-6 weeks depending on volume. --- --- title: "Website mit KI 2026 bestellen: Zeit, Preis – Artem" url: https://tema.name/de/blog/website-mit-ki-bestellen-2026.html language: de description: "Wie sich KI-Entwicklung von klassischen Studios unterscheidet, realistische Zeitrahmen für Landingpages und Firmensites, Preisbildung. Ohne Floskeln." date_published: 2026-05-21 date_modified: 2026-05-22 --- KI-Entwicklung 21. Mai 2026 · 8 Min. Lesezeit · Von Artem # Wie man eine Website mit KI 2026 bestellt: Ansatz, Zeit, Preis Eine Website mit KI in 2026 zu bestellen bedeutet **AI-Pair-Programming**: Der Entwickler arbeitet im Tandem mit Claude, Cursor oder ChatGPT, was die Entwicklung um **3–5×** beschleunigt. Realistische Zeiten: **Landingpage 5–10 Tage**, Firmen-Website **2–4 Wochen**, Katalog mit Anfrageformular **3–5 Wochen**, Online-Shop bis 5 000 SKU **4–8 Wochen**. Preisspanne 2026: Landingpage **800–2 500 €**, Firmen-Site **2 000–6 000 €**, B2B-Katalog **3 000–8 000 €**. KI ersetzt nicht den Ausführenden, der QA macht und für das Ergebnis haftet — sie ersetzt das manuelle Schreiben von Boilerplate. Pflichtbestandteile einer fertigen Website: PageSpeed Mobile 90+, semantisches HTML mit JSON-LD, SSL-/HTTP/2-Hosting, Backup-Plan, klare Übergabe. Der Artikel zeigt Website-Arten, Zeiten, Preisbildung und worauf bei der Auftragnehmer-Wahl zu achten ist. **In diesem Artikel** 1. [Was hat sich in der Website-Entwicklung 2026 geändert](#what-changed) 2. [Arten von Websites – und welche Sie brauchen](#types) 3. [Realistische Entwicklungszeiten](#timeline) 4. [Wie der Preis gebildet wird und was ihn beeinflusst](#price) 5. [Was eine fertige Website enthalten muss](#whats-inside) 6. [Auftragnehmer wählen, ohne reinzufallen](#choose) 7. [Häufige Fragen](#faq) ## Was hat sich in der Website-Entwicklung 2026 geändert Der Hauptunterschied zur Entwicklung der 2020er Jahre ist **AI-Pair-Programming**. Der Entwickler schreibt Code nicht mehr Zeile für Zeile von Grund auf. Er arbeitet im Tandem mit einem Modell (Claude, Cursor, ChatGPT): beschreibt die Aufgabe in natürlicher Sprache, KI generiert Struktur, Markup, Skripte und sogar Content-Entwürfe. Der Entwickler liest jeden Block, prüft die Logik, testet, debuggt und stellt das Endprodukt zusammen. Das heißt nicht, dass «Entwickler nicht mehr gebraucht werden». Im Gegenteil – ihre Rolle wird expertenmäßiger: Sie müssen wissen, wie man KI richtig briefet, die Qualität der Ausgabe bewertet, sieht, wo KI sich geirrt hat, und das Projekt in einen funktionierenden Zustand bringt. Ohne diese Schicht kommt die Website entweder nicht funktional oder hübsch-aber-unlogisch heraus. **Kernidee:** KI beschleunigt die Entwicklung um 3-5x, aber sie ersetzt nicht die Notwendigkeit eines Ausführenden, der für das Ergebnis verantwortlich ist. Die Frage ist nicht «Mensch oder KI», sondern «wer macht die finale QA und übernimmt die Verantwortung». Für den Kunden bedeutet das drei praktische Änderungen. **Erstens** – die Zeiten sind drastisch geschrumpft. Eine Landingpage, für die eine Agentur 1,5 Monate brauchte, ist bei einem KI-gestützten Freelancer in 1-2 Wochen fertig. **Zweitens** – die Preise sind gefallen. Dieselbe Arbeit kostet 3-5x weniger, weil kein Team von 4-6 Personen finanziert werden muss. **Drittens** – die Kommunikation wurde einfacher. Sie sprechen direkt mit dem Ausführenden, ohne Projektmanager und wochenlange Freigaben. ## Arten von Websites – und welche Sie brauchen Vor der Bestellung ist es wichtig, das Format zu verstehen, das tatsächlich Ihr Problem löst. Überflüssige Funktionalität bedeutet zusätzliches Geld und Zeit. Unzureichende – verlorenes Budget. ### Landingpage (Einseiten-Website) Wenn es passt: eine Dienstleistung oder ein Produkt, Ziel ist ein Lead. Zum Beispiel Wohnungssanierung, Mittagslieferung, eine private Zahnarztpraxis. Auf einer Landingpage liegt die ganze Aufmerksamkeit auf dem Angebot und dem Lead-Formular. ### Firmenwebsite (6-15 Seiten) Wenn es passt: mehrere Geschäftsrichtungen, Sie müssen jede Leistung separat detaillieren, Team, Cases, Kontakte, eine «Über uns»-Seite hinzufügen. Zum Beispiel eine Digital-Agentur, Anwaltskanzlei, medizinische Klinik. ### Content-Website mit Blog Wenn es passt: Sie setzen auf SEO und möchten regelmäßig Artikel veröffentlichen, um Publikum aus der Suche zu gewinnen. Zum Beispiel eine Online-Schule, Experten-Blog, Nischenmagazin. Sie brauchen ein CMS – meist Joomla oder WordPress. ### Online-Shop Wenn es passt: Sie verkaufen Produkte online – Sie brauchen einen Katalog mit Filtern, Warenkorb, Bezahlung, Kundenkonto. In Joomla wird das mit VirtueMart oder HikaShop-Komponenten gelöst. Für sehr große Shops (Zehntausende SKU) sind oft Spezialplattformen besser. **Tipp:** Versuchen Sie nicht, «alles auf einmal» zu bestellen. Beginnen Sie mit einer Landingpage oder Mini-Website, beobachten Sie die echte Nachfrage und erweitern Sie dann. Das spart Budget und beseitigt das Risiko, etwas zu entwerfen, was nicht gebraucht wird. ## Realistische Entwicklungszeiten Im Jahr 2026 mit KI-Entwicklung sehen realistische Zeitrahmen so aus: - **Landingpage:** 1-2 Wochen vom Briefing bis zum Launch - **Firmenwebsite (6-15 Seiten):** 2-4 Wochen - **Content-Website mit Blog:** ab 3 Wochen - **Katalog mit Leads (ohne Bezahlung):** 3-5 Wochen - **Voller Online-Shop:** 4-8 Wochen - **Telegram-Bot für Leads:** 3-5 Tage 1. BriefingTag 1 2. PrototypTag 3 3. DesignTag 5 4. CodeTag 7-10 5. LaunchTag 14 Diese Zeitrahmen setzen voraus, dass Sie bereit sind, Zwischenergebnisse schnell zu genehmigen. Wenn jeder Schritt 5 Tage Antwortzeit bekommt – verlängert sich das Projekt um das 2-3-fache. Besprechen Sie also im Voraus, wie oft es Demos gibt und wie schnell Sie entscheiden müssen. Die Hauptverzögerung ist normalerweise nicht der Code, sondern **Content**. Wenn Sie keine fertigen Texte, Fotos und Leistungsbeschreibungen haben – kalkulieren Sie Zeit für die Vorbereitung ein. Ein guter Auftragnehmer kann beim Erstellen von Textentwürfen mit KI helfen, aber die finale Genehmigung bleibt bei Ihnen. ## Wie der Preis gebildet wird und was ihn beeinflusst Ich gebe hier bewusst keine konkreten Zahlen in Euro oder Dollar an – sie veralten zu schnell und variieren regional. Aber hier ist eine funktionierende Formel, um sich in beliebigen Preisen zu orientieren: **Preis der Website = (Komplexität × Umfang) − KI-Beschleunigungsfaktor + Integrationen** Was «Komplexität» beeinflusst: Einzigartigkeit des Designs (Template vs Custom), nicht standardmäßige Funktionalität (Kalkulatoren, Berechnungen, Kundenkonto), Last (10 Besucher/Tag vs 10 000). Was «Umfang» beeinflusst: Anzahl der Seiten oder Bot-Szenarien, wie viele Texte zu adaptieren sind, wie viele Formulare und Integrationen. Was «Integrationen» hinzufügt: CRM (Bitrix24, AmoCRM, Pipedrive, HubSpot), Bezahlsysteme, Messenger, E-Mail-Versand. Jede Integration ist zusätzliche Arbeit am API-Setup und Testen. **KI-Faktor**: Wenn der Auftragnehmer KI-Tools nutzt, ist sein Preis meist 3-5x niedriger als Agenturpreise – bei gleicher Endqualität. Das ist nicht «billig», sondern ein anderer Prozessansatz. **Was NICHT im Angebot stehen sollte:** «Bezahlung pro Wort im Text», «Aufpreis für mobile Version» (responsive ist 2026 Norm, keine Option), «feste Gebühr für jede Content-Aktualisierung», «separate Gebühr für SEO-Markup». Wenn Sie das sehen – ist es ein Versuch, die Rechnung auf Basisdingen aufzublähen. ## Was muss in einer fertigen Website sein Das ist die Basis-Checkliste zur Prüfung des Endprodukts. Wenn etwas fehlt – ist die Website nicht abgeliefert. - **HTTPS**: SSL-Zertifikat verbunden, Website funktioniert über https://. 2026 straft Google Websites ohne ab. - **Responsives Design**: korrekte Darstellung auf Mobil, Tablet und Desktop. Buttongrößen, Lesbarkeit von Schriften, Bequemlichkeit der Formulare. - **Geschwindigkeit**: PageSpeed Insights – mindestens 80 auf Mobil und 90+ auf Desktop. Darunter gibt es Raum zur Optimierung. - **SEO-Markup**: Title, Description, H1-H3-Überschriften, sitemap.xml, robots.txt, Schema.org-Markup pro Seitentyp, hreflang für mehrsprachige Websites. - **Spam-geschützte Formulare**: Honeypot-Feld, Rate-Limit, Keyword-Filter. Leads kommen sofort in Telegram oder E-Mail an. - **Verbundene Analytics**: Yandex.Metrica mit Webvisor, Google Search Console. Sie sehen, woher Kunden kommen. - **Sicherheitsheader**: HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy. Schutz vor typischen Angriffen. - **Dokumentation und Zugänge**: Sie erhalten Quellcode, Hosting/Domain/Analytics-Zugang. Kurze Anleitung zur Content-Aktualisierung. ## Wie man einen Auftragnehmer wählt, ohne reinzufallen Der häufigste Kundenfehler ist die Wahl nach «Portfolio» ohne Faktenprüfung. Hübsche Screenshots kann man zeichnen – echte Qualität ist nur in Live-Projekten sichtbar. Fragen Sie vor der Bestellung: 1. **Zeigen Sie 2-3 Live-Projekte, an denen Sie persönlich gearbeitet haben.** Nicht «beteiligt» – gebaut und ausgeliefert. 2. **Welche Technologien nutzen Sie und warum genau diese?** Wenn die Antwort lautet «wir arbeiten mit allem, was nötig ist» – schlechtes Zeichen. Ein guter Auftragnehmer hat einen bestimmten Stack. 3. **Wer arbeitet persönlich an meinem Projekt?** Wenn es eine Agentur ist, finden Sie heraus, ob das Projekt für die Hälfte des Preises an einen Freelancer weitergegeben wird. 4. **Was deckt die Gewährleistung ab?** 2026-Standard – 30 Tage kleine Fixes kostenlos, dann stundenweise oder als Wartungsvertrag. 5. **Wer behält die Zugänge?** Sie: Hosting, Domain, Analytics, Quellcode. Wenn der Auftragnehmer «die Website bei sich aufbewahrt» – ist das eine Form von Geiselnahme. 6. **Nutzen Sie KI in Ihrer Arbeit?** 2026 ist das eine normale Frage. Wenn der Auftragnehmer das verheimlicht oder leugnet – ist er entweder hinter dem Markt zurück oder hat Angst, dass Sie von der KI erfahren und nicht zahlen wollen. **Rote Flaggen:** 100% Vorauszahlung vor Arbeitsbeginn, Weigerung, Zwischenergebnisse zu zeigen, vage Zeitrahmen («wie es kommt»), kein Vertrag oder schriftliche Bestätigung von Umfang/Preis, Druck «entscheiden Sie heute oder der Preis steigt». ## Häufig gestellte Fragen Kann KI eine Website komplett alleine bauen? Technisch ja – man kann eine ganze Website über KI generieren. Aber ohne menschliche Prüfung darf sie nicht live gehen: KI macht Logikfehler, erfindet manchmal nicht existierende Methoden und versteht keinen Geschäftskontext. Der richtige Ansatz: KI als Beschleuniger, Mensch als Qualitätskontrolle. Der Entwickler liest jeden Block, testet, debuggt und übernimmt die Verantwortung für das Ergebnis. Was kostet eine Website 2026 wirklich? Hängt vom Format und Auftragnehmer ab. Eine Landingpage bei einem KI-gestützten Freelancer ist 3-5x günstiger als eine klassische Agentur. Gleiches gilt für Firmenwebsites. Der exakte Preis für Ihr Projekt wird nach kurzem Briefing kalkuliert. Wichtig ist nicht der Preis an sich, sondern das Preis-Leistungs-Verhältnis und die laufenden Supportkosten. Wie lange dauert eine Landingpage 2026 realistisch? Mit KI-Tools ist eine schlüsselfertige Landingpage in 1-2 Wochen fertig: Briefing, Prototyp, Design, Code, Formulare, Analytics, Launch. Eine klassische Agentur braucht 4-6 Wochen – wegen mehrstufiger interner Freigaben. Was muss eine fertige Website enthalten? Minimum: HTTPS, responsives Design, Spam-geschützte Formulare, Analytics (Yandex.Metrica und Google Search Console), SEO-Markup (Title, Description, sitemap.xml, robots.txt, Schema.org), schnelles Laden (PageSpeed 90+) und eine klare Anleitung zur Pflege. Ohne diese Dinge ist eine Website Dekoration, kein Werkzeug. Worauf bei der Auftragnehmerwahl achten? Fragen Sie: Was ist im Angebot enthalten, wie lang sind die Fristen und hängen sie von Ihrer Content-Bereitschaft ab, wer arbeitet persönlich am Projekt, welche Technologien werden eingesetzt, gibt es Support nach Übergabe, wer behält den Zugang zur Website und Analytics. Wenn der Auftragnehmer ausweicht oder sagt «das müssen Sie nicht wissen» – suchen Sie einen anderen. --- --- title: "Joomla vs WordPress vs statisch 2026 – Stack-Wahl" url: https://tema.name/de/blog/joomla-vs-wordpress-vs-statisch-2026.html language: de description: "Vergleich bei Geschwindigkeit, Sicherheit, Flexibilität und Wartungskosten. 5 typische Szenarien und klare Entscheidungstabelle für den Stack." date_published: 2026-05-22 date_modified: 2026-05-22 --- Stack-Auswahl 22. Mai 2026 · 10 Min. Lesezeit · Von Artem # Joomla vs WordPress vs statisch 2026: welchen Stack wählen Kurzantwort nach Aufgabe: **Landingpage oder Mini-Site** mit seltenen Änderungen — **statisch**, PageSpeed Mobile durchschnittlich **96/100**, Time-to-Launch 1–2 Wochen. **Firmen-Website mit Redakteur-Rollen oder B2B-Katalog** — **Joomla 5** (Mehrsprachigkeit und ACL ohne Premium-Plugin, Anteil ca. **1,5 %**, nischig aber stabil, PageSpeed nackt ca. 82). **Blog oder Medium** mit Beiträgen alle 1–3 Tage und mehreren Autoren — **WordPress** (**40 %** aller Websites weltweit, reifstes Redaktions-Ökosystem, PageSpeed nackt ca. 65, mit CDN 80+). **E-Commerce**: bis **5 000 SKU** läuft VirtueMart/HikaShop oder WooCommerce gut, darüber lohnen Spezialplattformen wie Shopify oder Magento. Kein Stack ist universell „besser“ — wer das gegensätzlich verkauft, hat Tunnelblick oder verkauft, was er gerade kann. Der Artikel vergleicht die drei Ansätze nach **7 Parametern** und zeigt **5 typische Szenarien**. **In diesem Artikel** 1. [Kurze Antwort für Ungeduldige](#tldr) 2. [Joomla – für wen und warum](#joomla) 3. [WordPress – für wen und warum](#wordpress) 4. [Statisch – für wen und warum](#static) 5. [Vergleich nach 7 Parametern](#compare) 6. [5 Szenarien: was wählen](#scenarios) 7. [Häufige Fragen](#faq) ## Kurze Antwort für Ungeduldige In einem Absatz: **Eine Landingpage oder Mini-Site mit seltenen Änderungen** – statisch, fertig. **Eine Firmenwebsite mit mehreren Redakteur-Rollen oder ein Katalog mit Lead-Formular** – Joomla, besonders wenn saubere Rechte und Mehrsprachigkeit wichtig sind. **Ein Blog/Medium mit neuen Beiträgen alle 1-3 Tage und fünf Autoren** – WordPress, weil dessen Ökosystem aus Themes und Plugins für Redaktionen am ausgereiftesten ist. **E-Commerce** – hängt von der Größe ab: bis 5 000 SKU läuft VirtueMart/HikaShop in Joomla oder WooCommerce in WP gut; Zehntausende SKU erfordern Spezialplattformen. **Kernidee:** «das beste CMS» gibt es nicht. Aber «das passende CMS zur Aufgabe» schon. Wenn ein Auftragnehmer das Gegenteil behauptet und Sie unabhängig vom Projekt auf einen Stack drängt – das ist entweder Tunnelblick oder der Versuch, Ihnen zu verkaufen, was er gerade kann. 40% aller Websites laufen auf WordPress ~1.5% Joomla-Anteil – nischig, aber stabil 96/100 durchschnittlicher PageSpeed für Statik 3-5× Beschleunigung mit KI-Tools Ladegeschwindigkeit (PageSpeed Mobile) Durchschnittswert für eine typische Installation ohne Premium-Caching und CDN Statisch96 Joomla 582 WordPress65 Werte sind Richtwerte. Mit aggressivem Caching und CDN erreicht WordPress 80+, Joomla 90+, aber eine «nackte» Installation verhält sich genau so. ## Joomla – für wen und warum Joomla 5 ist ein ausgereiftes CMS auf PHP 8.x. Laut W3Techs betreibt es etwa 1,5-2% aller CMS-Sites weltweit – nischig, aber stabil. In Kontinentaleuropa und dem postsowjetischen Raum liegt der Anteil historisch höher – viele Firmen- und Behörden-Websites laufen darauf. **Vorteile:** - **Mehrsprachigkeit out of the box** – kein kostenpflichtiges Plugin der WPML-Klasse nötig, um eine Website in 4 Sprachen zu starten. - **Flexibles ACL** – ein Redakteur kann nur seinen Bereich sehen, ohne andere zu berühren. - **Weniger «Plugin-Zoo»** – das Erweiterungsökosystem ist kleiner als das von WP, dadurch fällt die Auswahl qualitativer Komponenten leichter und das Risiko verlassener Plugins ist niedriger. - **Starkes Komponentenmodell** – VirtueMart für Shops, HikaShop für Kataloge, K2 für strukturierten Content. Jede Komponente deckt ihren Bereich ab. - **Weniger Bot-Ziel** – Massenangriffe richten sich meist gegen WordPress, weil es größer ist. **Nachteile:** - Weniger fertige Themes und Templates auf Marktplätzen. - Kleinerer Specialisten-Pool – einen Auftragnehmer zu finden ist nicht so einfach wie «WordPress an jeder Ecke». - Für redaktionelle Sites mit vielen Autoren ist das WP-Ökosystem komfortabler. Ich arbeite seit Langem mit Joomla und wähle es weiterhin für Projekte, bei denen saubere Architektur und Mehrsprachigkeit wichtig sind. AI-Pair-Programming hilft: Templates lassen sich schnell anpassen, eigene Module schreiben, CRM-Integrationen bauen. Mehr dazu – [im Artikel zur KI-Entwicklung 2026](/de/blog/website-mit-ki-bestellen-2026.html). ## WordPress – für wen und warum WordPress ist das weltweit beliebteste CMS und betreibt rund 40% aller Sites. Daraus ergeben sich zwei Effekte: ein riesiges Ökosystem und eine riesige Angriffsfläche. **Vorteile:** - **Riesiges Ökosystem** – Tausende kostenloser und kommerzieller Themes, Plugins für fast jede Aufgabe. - **Bequeme visuelle Bearbeitung** (Gutenberg, Elementor) – Redakteure brauchen kein HTML, um einen neuen Block hinzuzufügen. - **Verfügbarkeit von Spezialisten** – einen WP-Entwickler zu finden ist einfacher und günstiger als einen Joomla-Entwickler. - **Passt zu redaktionellen Sites** – Rollen und Publishing-Workflow sind auf mehrere Autoren ausgelegt. - **WooCommerce** – die populärste E-Commerce-Lösung für WP, mit vielen fertigen Integrationen für Zahlungen und Versand. **Nachteile:** - **Hohe Anfälligkeit bei Vernachlässigung** – die meisten Hacks kommen von nicht aktualisierten Plugins. Jede WP-Installation, die ein Jahr unberührt bleibt, ist ein Ziel. - **«Plugin-Zoo»** – 30+ Plugins in einer Site bedeuten Konflikte, Trägheit, doppelte Funktionalität. - **Kostenpflichtige Erweiterungen** – Mehrsprachigkeit (WPML), ernsthafter Formularschutz, All-in-One-SEO-Suiten sind Abos, die sich summieren. - **Visuelle Builder blähen Code auf** – eine unoptimierte Elementor-Site landet leicht bei PageSpeed 30-40 auf Mobil. ## Statisch – für wen und warum Eine statische Website besteht aus HTML-, CSS- und JS-Dateien – keine Datenbank, kein PHP. Der Server liefert einfach Dateien aus. Moderne Generatoren (Hugo, Eleventy, Astro, der Jamstack-Ansatz) lassen Sie in Markdown schreiben und die Site in einen HTML-Ordner kompilieren, der dann aufs Hosting oder CDN geladen wird. **Vorteile:** - **Maximale Geschwindigkeit** – keine Server-Verarbeitung, die Seite kommt fertig an. PageSpeed 95-100 ist normal. - **Sicherheit** – es gibt nichts zu hacken: kein Admin, keine DB, keine PHP-Lücken. - **Minimales Hosting** – statisch wird fast kostenlos gehostet (Netlify, Cloudflare Pages, GitHub Pages oder einfaches Shared Hosting). - **Keine Core-Updates** – es gibt nichts zu aktualisieren. - **Perfekt für Landings und Portfolios** – wo Änderungen selten sind und Content sich kaum bewegt. **Nachteile:** - **Kein Admin-Panel** – eine neue Seite hinzuzufügen heißt Datei bearbeiten oder Git-Commit. Nicht jeder Kunde mag das. - **Dynamische Features extern** – Formulare, Kommentare, Suche, Warenkorb sind Drittdienste oder APIs. - **Große Kataloge sind schmerzhaft** – 50 000 HTML-Seiten zu generieren dauert, vollständige Rebuilds können Minuten brauchen. - **Nicht für häufige Nicht-Techniker als Redakteure** – fünf Autoren mit gleichzeitigem «Fenster-Zugang» sind keine Statik mehr. **Mittelweg:** «Headless CMS + statisch». Content wird in einer Admin (Strapi, Sanity) bearbeitet, die Site wird bei Änderung neu gebaut. Bietet die Geschwindigkeit der Statik und den Komfort einer Admin, kostet aber mehr Architektur-Komplexität als pure Statik. Nicht für jedes Projekt sinnvoll. ## Vergleich nach 7 Parametern | Parameter | Joomla | WordPress | Statisch | | --- | --- | --- | --- | | Ladegeschwindigkeit | Mittel, gut bei wenigen Plugins | Mittel, braucht Caching | Maximal | | Sicherheit | Hoch bei regelmäßigen Updates | Hoch bei Updates, aber größeres Ziel | Architektonisch maximal | | Content-Bearbeitung | Gut, saubere Admin | Exzellent, visuelle Builder | Nur über Dateien oder Git | | Mehrsprachigkeit | Eingebaut | Kostenpflichtiges Plugin (WPML) | Hängt von der Umsetzung ab | | Wartungskosten | Mittel | Kann durch Paid-Plugins hoch sein | Minimal | | Katalog / E-Commerce | VirtueMart, HikaShop | WooCommerce | Nur über externe Dienste | | Verfügbarkeit von Spezialisten | Mittel | Sehr hoch | Hoch | ## 5 Szenarien – was wählen ### Szenario 1: Landingpage für eine Leistung Beispiel: schlüsselfertige Wohnungssanierung oder eine private Zahnarztpraxis. Eine Seite, Lead-Formular, Analytics. Änderungen einmal pro Quartal. **Empfehlung:** statisch. Geschwindigkeit, Sicherheit, minimales Hosting. Ein CMS ist hier Overkill. ### Szenario 2: Firmenwebsite mit 10-30 Seiten Mehrere Leistungen, Team, Cases, Kontakte, News. Content wöchentlich aktualisiert, Mehrsprachigkeit nötig. **Empfehlung:** Joomla. ACL für verschiedene Redakteure, Mehrsprachigkeit ohne Aufpreis, saubere Menü-/Bereichsverwaltung. ### Szenario 3: Redaktionsblog mit fünf Autoren Content-Projekt, Artikel alle 1-3 Tage, mehrere Kategorien, Werbeblöcke, Abos. Ein bequemer Editor ist Pflicht. **Empfehlung:** WordPress. Ökosystem, fertige Redaktions-Themes, komfortabel für Nicht-Techniker. ### Szenario 4: Online-Shop bis 5 000 SKU Katalog mit Filtern, Warenkorb, Bezahlung, Kundenkonto, Aktionen, Versand. **Empfehlung:** Joomla mit VirtueMart/HikaShop oder WordPress mit WooCommerce. Die Wahl hängt davon ab, ob Sie Mehrsprachigkeit brauchen (Joomla gewinnt) oder eine riesige Theme-Auswahl (WP). Ab 10 000 SKU würde ich auf Spezialplattformen schauen – Shopify, OpenCart oder Eigenbau. ### Szenario 5: B2B-Katalog mit Lead-Formular Liste von Leistungen oder Produkten mit Beschreibungen, Filtern, Anfrageformularen. Kein Online-Kauf – der Kunde hinterlässt eine Anfrage, ein Manager ruft zurück. **Empfehlung:** Joomla mit HikaShop im «Ohne-Warenkorb»-Modus oder statisch mit dynamischen Formularen. Voll-E-Commerce ist hier überflüssig. **Wenn Sie bereits eine Website haben** und überlegen, den Stack zu wechseln – diagnostizieren Sie zuerst den echten Schmerz. Langsamkeit? Oft mit Caching und Bildoptimierung ohne Migration lösbar. Hacks? Lösbar mit Updates und Plugin-Audit. Unbequeme Admin? Vielleicht falsch konfigurierte Rechte. Eine Migration kostet 2-4 Wochen plus SEO-Risiko. Erst Diagnose, dann Wechsel. ## Häufig gestellte Fragen Ist Joomla 2026 noch relevant? Ja. Joomla 5 ist ein modernes CMS auf PHP 8.x mit durchdachtem Rechtesystem, eingebauter Mehrsprachigkeit und einem weniger aggressiven Ökosystem als WordPress. Es passt gut zu Firmenwebsites, Katalogen und E-Commerce über VirtueMart oder HikaShop. Für große redaktionelle Projekte mit vielen Autoren ist WP üblicher – aber bei «mehrere Rollen, sauberes ACL, kein Monster-Page-Builder» gewinnt Joomla oft. Was ist schneller: statisch, Joomla oder WordPress? Bei sonst gleichen Bedingungen: statisch → Joomla → WordPress. Statisch gewinnt, weil weder DB noch PHP-Verarbeitung der Anfrage nötig sind. Joomla ist meist schneller als WordPress dank schlankerem Kern und weniger Plugins in einer typischen Installation. WordPress lässt sich mit Caching und CDN beschleunigen, dann ist der Unterschied bei einer Landingpage nicht mehr kritisch. Bei großem Katalog wird er wieder sichtbar. Kann man einen Blog statisch betreiben? Ja – über Jamstack-Generatoren (Hugo, Eleventy, Astro) oder handgeschrieben, wie dieser Blog. Vorteile: Geschwindigkeit, Sicherheit, minimale Hostingkosten. Nachteil: Jeder neue Artikel braucht eine Dateibearbeitung oder einen Git-Commit – nicht jeder Kunde findet das bequem. Wenn Artikel selten und von einer Person geschrieben werden, ist statisch ausgezeichnet. Bei fünf Autoren mit täglichen Updates braucht es ein CMS. Welcher Stack ist sicherer? Statisch ist architektonisch sicherer – es gibt fast nichts zu hacken: keine DB, kein Admin, kein PHP. Joomla und WordPress sind beide sicher, vorausgesetzt Core und Plugins werden regelmäßig aktualisiert. Die meisten CMS-Hacks sind keine Core-Lücken, sondern verlassene Sites mit 3 Jahre alten Plugins. Wer die Site aktuell hält, ist mit beiden Optionen sicher unterwegs. Ich bin schon auf WordPress. Lohnt sich der Umzug? Nur bei konkretem Schmerz: Langsamkeit bei normaler Last, wiederholte Hacks durch einen Plugin-Zoo, mühsame Mehrsprachigkeit. «WordPress ist uncool» allein ist kein Grund. Ein Umzug bedeutet 2-4 Wochen Arbeit plus SEO-Risiko. Wenn die Site funktioniert und Leads bringt, ist Optimierung meist die bessere Investition als Migration. --- --- title: "Telegram-Bots für Unternehmen 2026 – Launch in 1 Woche" url: https://tema.name/de/blog/telegram-bots-fuer-unternehmen-2026.html language: de description: "Welche Aufgaben Bots wirklich lösen, Bot-Typen, realistischer 5-Tage-Launch-Plan, Preisfaktoren, häufige Fehler. Praxis ohne Floskeln." date_published: 2026-05-23 date_modified: 2026-05-23 --- Telegram-Bots 23. Mai 2026 · 10 Min. Lesezeit · Von Artem # Telegram-Bots für Unternehmen 2026: von Idee bis Launch in einer Woche Ein **Telegram-Bot** schließt drei Lücken im Unternehmen: sofortige Reaktion (statt E-Mail-Wartezeit), **24/7-Verfügbarkeit** ohne Pausen und Automation von **60–80 %** wiederkehrender Fragen — bei einer Reichweite von **900 Mio.+** aktiven Telegram-Nutzern weltweit (2026). Typische Launch-Zeit für einen Lead-Bot: **3–5 Arbeitstage**; ein FAQ-Bot mit CRM-Anbindung und Zahlungsintegration: **2–3 Wochen**. Stack 2026: aiogram 3 oder grammY auf Cloudflare Workers / Node.js, Webhook statt Long-Polling, Daten in Postgres oder D1. Preisfaktoren: Komplexität der Logik, Anzahl externer Integrationen (CRM, Kalender, Zahlung), mehrsprachige Antworten. Bot-Typen mit echtem ROI: Lead-Sammlung, FAQ-Automation, Auftragsstatus-Push, Terminbuchung, interner Mitarbeiter-Helper. Der Artikel zeigt den 5-Tage-Launch Schritt für Schritt, Preisbildung und 7 typische Fehler. **In diesem Artikel** 1. [Warum braucht ein Unternehmen 2026 einen Telegram-Bot](#why) 2. [Bot-Typen mit echten Beispielen](#types) 3. [5-Tage-Launch: Schritt für Schritt](#launch) 4. [Was den Preis beeinflusst](#price) 5. [7 typische Fehler](#mistakes) 6. [Häufige Fragen](#faq) ## Warum braucht ein Unternehmen 2026 einen Telegram-Bot Kurz gesagt: Ein Bot schließt drei Lücken, die Website und E-Mail schlecht abdecken: **Reaktionsgeschwindigkeit, Verfügbarkeit 24/7 und Automatisierung wiederkehrender Fragen**. Die Site ist hervorragend als Schaufenster und SEO-Kanal, E-Mail ist für Dokumente und formelle Korrespondenz. Aber im Moment, in dem der Kunde eine Antwort «sofort» braucht – geht er in den Messenger. 900M+ aktive Telegram-Nutzer weltweit (2026) 24/7 Bot-Verfügbarkeit ohne Pausen oder Wochenenden 3-5T typische Launch-Zeit für einen Lead-Bot 70%+ Zeitersparnis bei wiederkehrenden Anfragen Konkrete Vorteile fürs Unternehmen: - **Keine verlorenen Leads.** Anfragen landen sofort im Chat des Managers oder im CRM. Verschwinden nicht im E-Mail-Posteingang. - **Keine Registrierung.** Der Kunde ist bereits in Telegram eingeloggt – kein Passwort merken, kein 10-Felder-Formular. - **Push in der Tasche.** Status-Updates, Auftragsänderungen, Aktionen gehen direkt in die App, die der Kunde immer offen hat. - **Kein Spam-Filter.** Bot-Nachrichten landen nicht im «Werbung»-Ordner wie E-Mails. - **FAQ-Automation.** Der Bot schließt 60-80% typischer Fragen ohne Mensch: Preise, Termine, Kontakte, Lieferbedingungen. ## Bot-Typen — mit echten Beispielen Nicht alle Bots sind gleich. Der Typ bestimmt Szenario, Zeit und Preis. Die wichtigsten Kategorien. ### 1. Lead-Bot (Anfrageerfassung) Die häufigste Anfrage. Der Bot stellt 3-7 Fragen, erfasst den Kontakt und sendet die Anfrage in den Telegram-Chat des Managers oder ins CRM. Passt zu Dienstleistungen, Beratung, Reparaturen, B2B-Verkauf. *Dauer: 3-5 Tage.* ### 2. FAQ / Support Beantwortet typische Fragen per Menü oder über KI-Textklassifikation. Übergibt komplexe Fälle an einen Live-Operator. Passt zu Online-Schulen, E-Commerce, Service-Unternehmen. *Dauer: 1-2 Wochen Basis, 2-4 Wochen mit KI-Suche über Wissensbasis.* ### 3. Rechner- / Quiz-Bot Führt den Kunden durch mehrere Schritte mit Optionsauswahl und gibt am Ende ein Ergebnis aus: Preisschätzung, Empfehlung, passenden Tarif. Tolle Alternative zu langen Webformularen. *Dauer: 1-2 Wochen.* ### 4. Benachrichtigungs-Bot Sendet Push-Nachrichten zu Ereignissen im System: neue Anfrage, Statusänderung, Termin-Erinnerung, Lieferupdate. Arbeitet oft im Tandem mit anderen Bots. *Dauer: 2-5 Tage.* ### 5. Katalog-Bot mit Bestellung Schaufenster im Telegram: Kategorien, Produktkarten, Warenkorb, Checkout. Passt zu kleinen Shops bis 100-200 SKUs. Für größere Kataloge ist eine eigene Website besser. *Dauer: 2-4 Wochen.* ### 6. KI-Bot (RAG, Agenten) Ein Bot, der freie Fragen anhand Ihrer Wissensbasis mit KI beantwortet: Dokumente, Artikel, Anleitungen, Cases. Nutzt Claude oder OpenAI plus Vektor-Datenbank (Pinecone, Qdrant). Passt zu komplexem Support, Schulung, internen Wikis. *Dauer: 2-4 Wochen.* **Versuchen Sie nicht «alles in einem».** Die meisten Unternehmen holen 80% des Werts aus einem einzigen, einfachen Szenario. Ein Bot, der gleichzeitig verkauft, supportet, einen Katalog führt und ein Quiz macht – macht alles schlecht. Mit einem starten, mit dem Wachstum erweitern. ## 5-Tage-Launch Schritt für Schritt So sieht ein realistischer Zeitplan für den Launch eines einfachen Lead-Bots mit CRM-Anbindung aus: 1. BriefingTag 1 2. SzenarioTag 2 3. CodeTag 3 4. TestsTag 4 5. LaunchTag 5 **Tag 1 – Briefing.** Festlegen: Was soll der Bot tun, welche Fragen stellen, wohin Daten senden, wie auf Off-Script-Nachrichten reagieren. Ergebnis: ein einseitiges Spec-Dokument. **Tag 2 – Szenario.** Alle Dialog-Zweige ausschreiben: was der Bot sagt, welche Buttons er zeigt, wie er auf Antworten reagiert. Abgestimmt mit Ihnen als Flow-Chart oder Tabelle. Das ist der wichtigste Tag – hier wird die Usability gesetzt. **Tag 3 – Code.** Ich baue den Bot über Telegram Bot API. Integrationen: Anfragen in den richtigen Chat, in Google Sheets oder ins CRM (Bitrix24, AmoCRM, Pipedrive, HubSpot). Fehlerbehandlung und Logging. **Tag 4 – Tests.** Ich gehe jeden Zweig selbst durch, fange Edge-Cases (leere Nachrichten, lange Texte, Emoji, Taps außerhalb der Buttons). Sie testen parallel. Wir fixen, was unbequem ist. **Tag 5 – Launch.** Der Bot wird auf Ihren Server oder mein VPS deployed. Monitoring eingerichtet. Kurze Admin-Anleitung: wie Anfragen einsehen, was bei Ausfällen tun, wie Texte ändern. Token und alle Zugänge gehen an Sie. **Zu den Zugängen.** Der Bot-Token (von @BotFather) und alle API-Schlüssel für Integrationen müssen bei Ihnen bleiben. Das ist Ihr Asset. Wenn der Entwickler «den Token bei sich behält» – ist das eine Form von Bindung. Ein solider Auftragnehmer übergibt alles sofort dem Kunden. ## Was den Preis beeinflusst Konkrete Euro- oder Dollar-Zahlen gebe ich bewusst nicht – sie veralten schnell und variieren regional. Stattdessen eine Arbeitsformel, um jedes Angebot zu bewerten: **Bot-Preis = (Szenario-Komplexität × Anzahl Zweige) + Integrationen + KI-Logik − KI-Beschleunigungsfaktor** **Szenario-Komplexität:** wie viele Dialog-Schritte, Verzweigungen, Rückwärts-Schritte. Lineare Szenarien (Umfrage, Lead-Formular) sind einfach. Bot mit dynamischem Menü basierend auf vorherigen Antworten ist schwerer. **Anzahl Zweige:** 3-5 Zweige – Basis. 10-20 – mittel. 50+ – schon ein eigenes Produkt, braucht längeres Design. **Integrationen:** CRM, Zahlungssystem, Kundendatenbank, Broadcasts, externe APIs. Jede Integration ist separate Einrichtungs- und Testarbeit. **KI-Logik:** wenn der Bot freie Fragen mit KI beantworten soll – kommt Arbeit an Prompts, Kontext, Vektor-Store, Modell-Fehlerbehandlung dazu. **KI-Entwicklungsfaktor:** Ich arbeite mit AI-Pair-Programming (Claude, Cursor), Code wird schneller fertig. Das senkt den finalen Preis um Faktor 2-3 gegenüber klassischen Agenturen bei gleicher Qualität. ## 7 typische Fehler Diese Rechen sehe ich regelmäßig – bei Kunden, die den Bot selbst gebaut oder mit einem vorherigen Auftragnehmer gemacht haben. Falls Sie Ihre Situation wiedererkennen, lohnt sich Umbau. 1. **Der Bot versucht alles zu tun.** Ein Bot – eine Kernaufgabe. Leads, Support und Katalog in einem Menü ergeben meist ein komplexes, unbequemes, unlogisches Produkt. 2. **Kein menschlicher Fallback.** Versteht der Bot etwas nicht – braucht der User einen «Manager kontaktieren»- oder «Nachricht hinterlassen»-Button. Sonst geht der Kunde. 3. **Szenario zu lang.** 15 Umfragefragen sind keine «tiefe Erkundung», sondern Genervtheit. Nur fragen, was für den ersten Kontakt nötig ist. Details kommen aufs Gespräch. 4. **Bot nicht beworben.** Gelauncht und vergessen. Der Bot gehört auf die Hauptseite (Widget oder Link), in E-Mail-Signatur, auf Visitenkarten, in Google-Maps-Karten. Sonst null Inbound-Audience. 5. **Kein Daten-Export.** Anfragen nur im Chat – und wenn der Chat verloren geht oder der Manager kündigt? Google Sheets, CRM oder zumindest regelmäßiger Export sind Pflicht. 6. **Keine Analytics.** Wie viele User schließen das Szenario ab? Wo springen sie ab? Wer nicht misst, kann nicht verbessern. Minimum – Event-Counter; ideal – BotFather-Analytics oder eigene. 7. **Bot nach Launch vergessen.** Telegram Bot API entwickelt sich, Dependencies brauchen Updates, CRM-Integrationen brechen manchmal. Ein Bot ohne Wartung «glitcht» nach 6-12 Monaten. **Gute Regel:** Mit der einfachsten Version (MVP) starten, launchen, Analytics und echtes Kundenverhalten 2-4 Wochen beobachten. Erst dann erweitern. Das ist 5-10x effektiver als ein halbes Jahr im Vakuum am «perfekten Bot» zu bauen. ## Häufig gestellte Fragen Warum braucht ein Unternehmen einen Telegram-Bot, wenn es schon Website und E-Mail gibt? Ein Bot ersetzt die Website nicht – er arbeitet daneben. Die Site übernimmt SEO, Information und Vertrauen. Der Bot deckt ab, was die Website schlecht macht: sofortige Antwort 24/7, einfache Chat-Szenarien, Push-Benachrichtigungen zum Anfragenstatus, schnelle Beratung ohne Anrufe. Laut Telegram übersteigt die monatlich aktive Nutzerzahl 2026 die 900 Millionen – Ihre Kunden sind bereits dort. Wie schnell kann ein einfacher Lead-Bot realistisch starten? 3-5 Arbeitstage ab fertigem Briefing. Das umfasst: Szenario, einfaches Antwort-Design, Code, Tests, CRM- oder Tabellen-Anbindung, Admin-Anleitung. Komplexe Flows mit KI-Antworten, Mehrsprachigkeit und Zahlungen brauchen 2-4 Wochen. Was kostet ein Telegram-Bot? Hängt vom Szenario und den Integrationen ab. Ein einfacher Lead-Bot ist mehrfach günstiger als eine Full-Stack-Website, weil weder Seiten-Designs noch Frontend oder Responsive-Layout nötig sind. Der Preis steigt mit der Zahl der Szenarien, Integrationen (CRM, Zahlungen, Broadcasts) und KI-Logik-Komplexität. Konkrete Schätzung – nach kurzem Briefing. Kann der Bot an mein CRM angebunden werden (Bitrix24, HubSpot)? Ja. Alle wichtigen CRMs haben eine offene API. Der Bot schickt die Anfrage im richtigen Format ans CRM, legt einen Deal an, weist einen Verantwortlichen zu, speichert den Chat-Verlauf. Gleiches gilt für AmoCRM, Pipedrive, HubSpot, Salesforce. Bei einem eigenen CRM – Integration via Webhook oder direkten DB-Zugriff. Was passiert, wenn der Bot eine nicht standardmäßige Frage nicht versteht? Hauptregel: Der Bot muss immer einen Fallback zum Menschen haben. Schreibt der Nutzer etwas außerhalb des Szenarios – soll der Bot entweder ein klares Menü anbieten, den Chat einem Manager im DM übergeben oder einen Kontakt für Rückruf erfassen. Der Bot darf niemals «hängen» oder roboterhaft «verstehe nicht» antworten. --- --- title: "KI-Tools für Entwickler 2026 – Arbeits-Stack" url: https://tema.name/de/blog/ki-tools-fuer-entwickler-2026.html language: de description: "Claude, Cursor, ChatGPT, Copilot, Perplexity, Make – mein Arbeits-Stack 2026. Was Anfänger wählen sollten, 7 Fehler und FAQ." date_published: 2026-05-24 date_modified: 2026-05-24 --- KI-Entwicklung 24. Mai 2026 · 11 Min. Lesezeit · Von Artem # KI-Tools für Entwickler 2026: Arbeits-Stack Mein realer 2026-Stack: **Claude (Sonnet 4.5 + Opus 4)** als Haupt-Modell für Architektur und große Refactorings, **Cursor** als IDE-Agent mit voller Codebase im Kontext, **ChatGPT** für schnelle Recherche und Texte, **GitHub Copilot** als Tab-Autocompleter, dazu **v0** für UI-Prototypen. Kosten gesamt: **etwa 75 $/Monat**. Beschleunigung gegenüber 2023 in der Praxis: **3–5×**, Boilerplate schreibe ich praktisch nicht mehr selbst. Drei Verschiebungen treiben das: Kontext-Fenster bis **200K Tokens** (ganze Projekte lesbar), Tools wurden zu Agenten (eigenständige Befehle, Commits, Datei-Operationen) und Senior-Niveau bei Standardaufgaben. Für Anfänger reicht ein Minimum-Stack aus Claude + Cursor für ca. **40 $/Monat**. Der Artikel beschreibt den Stack nach Kategorien, einen AI-Pair-Programming-Tag und 7 Fehler, die ich auf dem Weg gemacht habe. **In diesem Artikel** 1. [Was sich in 2 Jahren in der Entwicklung geändert hat](#what-changed) 2. [Mein Arbeits-Stack nach Kategorien](#stack) 3. [Wie ein AI-Pair-Programming-Tag aussieht](#workflow) 4. [Minimum-Stack für Anfänger](#beginner) 5. [7 Fehler, die ich gemacht habe](#mistakes) 6. [Häufige Fragen](#faq) ## Was sich in 2 Jahren in der Entwicklung geändert hat Hätte ich diesen Artikel 2024 geschrieben, sähe er ganz anders aus. Damals war KI ein «nützliches Spielzeug»: half mit Regex, erklärte Fehler, lieferte gelegentlich ein gutes Snippet. Jetzt ist KI die **primäre Arbeitsumgebung**, genauso wie IDE oder Git. 5+ KI-Tools im täglichen Stack 3-5× Entwicklungs-Beschleunigung mit AI-Pair-Programming ~$75/Mo Kosten des Basis-Abo-Stacks 0% Boilerplate-Code, den ich manuell schreibe Drei zentrale Verschiebungen: - **Kontext-Fenster gewachsen.** Claude liest jetzt 200K+ Tokens auf einmal – das ist ein ganzes mittleres Projekt. KI sieht die ganze Codebase, nicht eine Datei nach der anderen. - **Tools wurden zu Agenten.** Cursor kann selbst Befehle ausführen, Dateien lesen, Commits machen. Nicht nur «Frage beantworten» – Aktionsketten ausführen. - **Code-Qualität auf Senior-Niveau** bei Standardaufgaben. KI ist nicht mehr «manchmal gut» – sie ist konstant gut für alles, was nicht einzigartigen Geschäftskontext erfordert. ## Mein Arbeits-Stack nach Kategorien ### Kategorie 1: Code-Assistenten ### Claude (Anthropic) $20/Mo · mein Haupttool Primäres Tool für lange Kontexte, komplexes Refactoring und Architektur-Fragen. Folgt Anweisungen besser als GPT, halluziniert weniger. Nutze ich über claude.ai im Web und API im Code. Artifacts ist ein tolles Feature für iterative Arbeit an einer Datei. ### Cursor $20/Mo · IDE VSCode-Fork mit eingebauter KI. Cmd+K für Inline-Edits, Cmd+L für Projekt-Chat, Composer für Multi-Datei-Änderungen. Nutzt Claude Sonnet und GPT-4 unter der Haube. Produktivste Arbeitsweise – Prompts direkt im Code. ### ChatGPT (OpenAI) $20/Mo · Zweittool Für Aufgaben, die frische Web-Suche brauchen oder Bild-Generierung (DALL-E). Auch als «zweite Meinung», wenn Claude eine fragwürdige Antwort gibt. Abo nicht zwingend, aber praktisch für regelmäßige Aufgaben. ### GitHub Copilot $10/Mo · Inline Tab-Autocomplete direkt im Editor. Weniger «denkend», mehr «ratend», aber bei Boilerplate (typische Getter, Loops, Formulare) spart es Stunden. Cursor hat einen ähnlichen eingebauten Mechanismus – mit Cursor ist Copilot eventuell überflüssig. ### Kategorie 2: Research und Fakten-Check ### Perplexity $20/Mo · Suche mit Quellen KI-Suche mit Quell-Links. Unverzichtbar für Recherche neuer Bibliotheken, Faktenprüfung, Lösungen für seltene Fehler. Free-Plan gibt ~5 Suchen/Tag – schon nützlich. Pro-Plan entfernt Limits + Sonar-Modelle. ### NotebookLM (Google) kostenlos · Dokumentation 5-50 PDFs/Docs hochladen – KI beantwortet Fragen dazu mit Zitaten. Nutze ich zum Parsen großer API-Dokumentationen, technischer Spezifikationen, juristischer Dokumente. Kostenlos mit Google-Konto. ### Kategorie 3: Design und UI ### v0.dev (Vercel) ab $20/Mo · UI-Komponenten Komponente in Text beschreiben oder Screenshot hochladen – erhalten Sie React/Tailwind-Code. Nicht für Produktion «as is», aber als Startpunkt – exzellent. Besonders nützlich für Landing-Blöcke und Dashboard-Karten. ### Midjourney $10/Mo · Illustrationen Für Icons, Illustrationen, Hero-Bilder. Über Discord-Bot oder Web-Interface. Alternative – DALL-E (in ChatGPT Plus enthalten). Ich bevorzuge Midjourney für Stil-Konsistenz mit --sref für Branding. ### Kategorie 4: Automation und Orchestrierung ### Make.com ab $9/Mo · No-Code-Workflows Visueller Builder zum Verbinden von Diensten: Telegram-Bot → Parsing → Google Sheets → E-Mail-Versand. Wenn der Flow steht, schreibe ich ihn als Python-Script um, aber Make ist toll für Prototypen und schnelle Lösungen. ### Custom Python/Node.js Skripte Open Source · Produktions-Logik Wenn No-Code an die Decke stößt (oder teurer wird als ein gehostetes Script) – schreibe ich eigenen Code über Claude/Cursor. Gehostet auf VPS oder Cloudflare Workers. Volle Kontrolle, minimale Kosten. ### Kategorie 5: Vektor-Datenbanken und RAG ### Pinecone / Qdrant Free Tier bis $70/Mo Vektor-Datenbanken für KI-Suche über Ihre Dokumente. Pinecone ist einfacher zum Starten (managed), Qdrant – Open Source, selbst-hostbar. Verwendet für RAG-Agenten: Bots, die Fragen über Ihre Wissensbasis beantworten. ### OpenAI / Voyage Embeddings Cent-Beträge pro tausend Tokens API zur Konvertierung von Text in Vektoren. OpenAI text-embedding-3-small ist ein toller Baseline. Voyage ist etwas genauer bei Code-Suche und domain-spezifischen Texten. Kosten für ein typisches Projekt – $1-5/Monat. **Nicht «KI-Tools» mit «KI-Abhängigkeit» verwechseln.** All diese Abos haben nur Sinn, wenn sie sich durch gesparte Zeit amortisieren. Wenn Sie Claude einmal pro Woche nutzen – keine $20/Monat, dafür gibt es Free-Plans. Mit Minimum anfangen, mit wachsender Last erweitern. ## Wie ein AI-Pair-Programming-Tag aussieht Eine typische Feature-Session – 5 Phasen. Jede für ein bestimmtes Tool optimiert. 1. Kontext5-10 Min. 2. Prompt2-5 Min. 3. Generierung1-3 Min. 4. Review10-20 Min. 5. Test5-15 Min. **Phase 1 – Kontext.** Relevante Dateien in Cursor öffnen (oder per @-Menü in Claude anhängen). Bei Multi-Datei-Aufgaben – «Karte» aller Abhängigkeiten sammeln. Ohne Kontext schreibt KI korrekten Code, der nicht in Ihr Projekt passt. **Phase 2 – Prompt.** Aufgabe vollständig beschreiben: was soll rauskommen, welche Edge-Cases beachten, welcher Stack, welche Projekt-Konventionen. Guter Prompt – 5-15 Zeilen. Schlechter Prompt – «mach ein Formular». **Phase 3 – Generierung.** KI liefert eine Antwort. Nicht sofort akzeptieren – oft frage ich 2-3 Varianten oder «jetzt dasselbe, aber mit Fehlerbehandlung und Logging». **Phase 4 – Review.** Wichtigste Phase. Jede Zeile lesen, Logik prüfen, Halluzinationen suchen (nicht existierende Methoden, falsche Imports), Projekt-Passung bewerten. **Ohne Review nicht committen.** **Phase 5 – Test.** Code ausführen, Edge-Cases prüfen, idealerweise Unit-Tests schreiben oder KI darum bitten. Sentry/Logs für Produktions-Monitoring. ## Minimum-Stack für Anfänger Falls Sie gerade einsteigen und nicht sofort $75/Mo ausgeben wollen – hier der Einstiegs-Kit für KI-Entwicklung: - **Cursor (Free-Plan)** – limitierte monatliche Anfragen, reicht aber für Side-Projekte. *$0* - **Claude oder ChatGPT Free-Plan** – beide erlauben ~30-50 Nachrichten/Tag. Eins wählen, konstant damit arbeiten. *$0* - **Perplexity Free-Plan** – 5 Pro-Suchen/Tag, Rest ist reguläre KI-Suche. *$0* Das deckt die ersten 2-3 Monate ab, während Sie sich an den KI-Workflow gewöhnen und verstehen, welche Aufgaben welches Tool am besten löst. Bei Limit – für eines zahlen, dann zwei, dann drei. So wie KI anfängt, Zeit echt zurückzuzahlen. **Tipp:** Nicht alle 10 Tools auf einmal lernen. Eins nehmen (ich empfehle Claude oder Cursor), 2-3 Wochen jede Aufgabe damit machen. Erst beim Erreichen der Decke nächstes hinzufügen. So lernen Sie, KI richtig zu briefen – nicht «zwischen Fenstern wechseln». ## 7 Fehler, die ich gemacht habe In 2 Jahren aktiver KI-Arbeit – das sind die größten Zeit- und Nerven-Fresser. 1. **KI-Code ungelesen akzeptiert.** Teuerster Fehler – glauben «KI ist ja klug». Einmal fiel die Produktion aus, weil Claude eine nicht existierende Methode einer Bibliothek nutzte. Seither – jede Zeile lesen. 2. **Zu kurzen Kontext gegeben.** «Bau ein Registrierungs-Formular» = schlecht. «Bau ein Registrierungs-Formular in React, wir nutzen react-hook-form, Felder X/Y/Z, Zod-Validierung, POST nach /api/register» = gut. 3. **Gute Prompts nicht gespeichert.** Wenn Sie einen funktionierenden Prompt finden – speichern. Sonst nochmal 20 Minuten Formulierung in einer Woche. 4. **KI für Architektur-Entscheidungen genutzt.** KI versteht nicht den Projekt-Kontext als Ganzes – sie empfiehlt «allgemeine Best Practices», nicht «was zu Ihnen passt». Architektur entscheide ich selbst, KI hilft bei der Umsetzung. 5. **API-Kosten bei Scale ignoriert.** Ein Parser-Skript machte 10K Claude-API-Aufrufe/Tag. Ende des Monats – $80 statt üblichen $5. Lektion: Token-Verbrauch immer loggen. 6. **KI bei Aufgaben übergehen, wo sie stärker ist.** Regex, SQL-Query, Webpack-Config – schneller KI fragen als 15 Minuten googeln. Lange dauerte es, das zu akzeptieren. 7. **Keine Diff-Logs von KI-Änderungen geführt.** Bei Arbeit mit KI-Agenten, die mehrere Dateien gleichzeitig ändern – immer vor jeder Runde committen. Sonst nach 3-4 Iterationen schwer zu sagen, was wo kaputt ging. **Faustregel:** KI ist ein Junior-Entwickler, der 100× schneller programmiert als ich. Ich bin der Teamlead: Aufgaben stellen, Ergebnis reviewen, Verantwortung für das Resultat tragen. Nicht «KI macht es für mich» – sondern «ich mache es schneller mit KI». Dieser Denkunterschied entscheidet, ob Sie wachsen oder zur Copy-Paste-Maschine werden. ## Häufig gestellte Fragen Welcher KI-Assistent ist besser: Claude oder ChatGPT? Sie ergänzen sich. Claude (Anthropic) ist stärker bei langen Kontexten, komplexer Logik und präzisem Befolgen von Anweisungen – mein Haupt-Tool für Refactoring und Architektur-Aufgaben. ChatGPT (OpenAI) ist besser für schnelle Fragen, frische Web-Suche, Ideen-Generierung. 2026 lohnt es sich, für beide zu zahlen – $20-40/Monat pro Tool – und nach Aufgabe zu wechseln. Wo fangen Anfänger an – minimaler KI-Stack? Minimum: Cursor als IDE (Free-Plan zum Start) + Claude oder ChatGPT für tiefe Fragen im Browser. Diese zwei decken 80% der Aufgaben in den ersten 6 Monaten ab. Wenn Sie an Limits stoßen – fügen Sie hinzu: GitHub Copilot für Inline-Vorschläge, Perplexity für Research mit Quellen, Make.com für die Automatisierung externer Prozesse. Was kosten all diese Tools pro Monat? Basis-Entwickler-Stack: Cursor Pro ($20), Claude Pro ($20), ChatGPT Plus ($20), GitHub Copilot ($10) = ~$70/Monat. Plus API-Kosten für Side-Projekte – meist $5-30/Monat. Gesamt $75-100/Monat. Weniger als eine Stunde Entwickler-Arbeit – es zahlt sich am ersten Tag durch Geschwindigkeit aus. Kann man 2026 ohne KI arbeiten? Technisch ja, aber es ist wie Coding ohne IDE und ohne Stack Overflow – nicht verboten, aber Sie verlieren massiv an Tempo. Jeder Monat, den Sie keine KI nutzen, schließt ein Konkurrent mit KI-Stack 3-5x mehr Aufgaben in der gleichen Zeit. Es ist kein «Vorteil» mehr – es ist Basis-Kompetenz. Wird KI Entwickler in den nächsten Jahren ersetzen? Nein – aber die Rolle wird sich ändern. KI generiert gut Code, aber sie kann nicht: Aufgaben definieren, Geschäftskontext verstehen, Architektur-Entscheidungen treffen, Reviews auf Plausibilität machen, Verantwortung vor dem Kunden übernehmen. Diese Aufgaben bleiben dem Menschen. Ein 2026-Entwickler ist ein Experten-Ingenieur, der KI richtig briefet und das Ergebnis validiert. KI als Beschleuniger, nicht Ersatz. --- --- title: "SEO für Einseiten-Website ohne Budget 2026" url: https://tema.name/de/blog/seo-fuer-einseiten-website-2026.html language: de description: "7 SEO-Pflicht-Punkte für eine Landingpage, realistischer Zeitrahmen, typische Fehler. Nur kostenlose Tools: GSC, Yandex Webmaster, PageSpeed." date_published: 2026-05-25 date_modified: 2026-05-25 --- SEO ohne Budget 25. Mai 2026 · 11 Min. Lesezeit · Von Artem # SEO für Einseiten-Website ohne Budget 2026 Eine **Einseiten-Website** rankt 2026 realistisch, wenn drei Bedingungen stimmen: genau **1 H1** mit der primären Suchphrase, sauberes Schema.org (FAQPage, Organization, BreadcrumbList), **PageSpeed Mobile 90 +**. Für eine kommerzielle Landingpage sollten **1 500 + Wörter** Inhalt vorhanden sein, der die Nutzer-Intention vollständig beantwortet. Erste Bewegung in Google: **4–8 Wochen**, Top-10 bei engen Nischen-Anfragen in **3–6 Monaten**. Was am Wochenende selbst machbar ist: title und meta description, OG-Tags, Bilder als WebP mit alt-Text, semantische Heading-Hierarchie, FAQ-Block, JSON-LD, robots.txt + sitemap.xml. Budget: **0 €** — alle Werkzeuge in diesem Leitfaden sind kostenlos. Gut geeignet für Local SEO, Nischen-B2B, Personal Brands und Portfolios; schlecht für Shops und Medienprojekte. Der Artikel liefert 7 SEO-Pflichtpunkte, einen 1-Wochen-Plan, 5 Mythen und 7 typische Fehler. **In diesem Artikel** 1. [Kann eine Einseiten-Website überhaupt ranken](#can-rank) 2. [7 SEO-Pflicht-Punkte für eine Landingpage](#essentials) 3. [Schritt-für-Schritt-Plan: Start in einer Woche](#workflow) 4. [5 SEO-Mythen, die im Weg stehen](#myths) 5. [7 typische Fehler](#mistakes) 6. [Häufige Fragen](#faq) ## Kann eine Einseiten-Website überhaupt ranken Ja – und 2026 sogar besser als vor 3 Jahren. Google und Yandex haben gelernt, **Nutzer-Intent** zu verstehen, nicht nur Wörter zu zählen. Wenn eine Seite eine konkrete Frage klar beantwortet, hat sie reale Chancen auf Top-Positionen, auch als einzelne Seite. 1 H1 pro Seite – Regel, oft verletzt 1500+ Wörter-Ziel für eine kommerzielle Landingpage 90+ PageSpeed Mobile für wettbewerbsfähiges Ranking 100% SEO-Tools in diesem Leitfaden – kostenlos Aber es gibt eine Nuance. Eine Einseiten-Website **verliert gegen Multi-Page-Sites** bei «breiten» Anfragen (wie «Sneaker kaufen», «Wohnungssanierung»), wo Sites mit hunderten Seiten konkurrieren. Aber sie **gewinnt** bei engen und nischigen Anfragen – genau dort, wo Ihr Kunde meist sitzt. Realistische Erwartungen: - **Gut für**: «Leistung + Stadt» (Local SEO), Nischen-B2B-Services, spezifische Produkte für spezifische Zielgruppe, Personal Brands, Portfolios. - **Schlecht für**: Online-Shops (brauchen Produktseiten), Medienprojekte (brauchen Artikel), Aggregatoren (brauchen Kategorien). ## 7 SEO-Pflicht-Punkte für eine Landingpage Das ist die Basis-Checkliste. Ohne einen dieser Punkte funktioniert SEO nicht – an Dutzenden Projekten bewiesen. ### 1. Eindeutiges H1 mit dem Ziel-Keyword Ein H1 pro Seite, und es muss Ihr Haupt-Suchbegriff enthalten. Nicht «Willkommen bei unserer Firma», sondern «Webentwicklung in Berlin – Name/Brand». Suchmaschinen behandeln H1 als Hauptthema der Seite. ### 2. Title und Meta-Description für die Anfrage Title – unter 60 Zeichen mit dem Haupt-Keyword am Anfang. Description – unter 160 Zeichen, beschreibt den Nutzen + Klick-Anreiz. **Description beeinflusst kein Ranking**, aber sie beeinflusst CTR – und CTR beeinflusst Ranking. ### 3. Schema.org-Markup Minimum: **Organization** oder **LocalBusiness** (bei physischer Adresse). Für Services – **Service**. Für FAQ-Sektion – **FAQPage**. Für Bewertungen (wenn real) – **AggregateRating**. Schema.org bringt Rich Results in der Suche: Sterne, FAQ-Akkordeons, Preise. ### 4. Mobile-first + schnelles Laden Google indexiert die mobile Version zuerst. PageSpeed Mobile 80+ Minimum, 90+ wettbewerbsfähig. Häufigste Geschwindigkeits-Killer: schwere Bilder (WebP/AVIF + Lazy Load nutzen), zu viele Fonts (eine Familie reicht), visuelle Builder (Elementor fügt 400KB Überhang hinzu). ### 5. Sitemap.xml + robots.txt + Search Console Sitemap.xml (auch eine einzeilige) + robots.txt + Registrierung in **Google Search Console** und **Yandex.Webmaster**. Ohne das finden Suchmaschinen Ihre Site in 2-4 Wochen. Damit – in 1-3 Tagen. ### 6. Innere Struktur: H2-H3 als Sub-Fragen-Antworten Brechen Sie Content in Sektionen mit H2-H3 auf, die spezifische Sub-Fragen beantworten. Zum Beispiel: «Was ist enthalten», «Wie lange dauert es», «Was kostet es», «Garantien». Google liebt diese Struktur und zeigt sie oft als Featured Snippet an. ### 7. Analytics – ohne keine Optimierung Yandex.Metrika und/oder Google Analytics 4 + Search Console für Suchanfragen. Ohne Analytics wissen Sie nicht, welche Anfragen Kunden bringen und wo sie abspringen. SEO ohne Daten ist Kaffeesatzlesen. - Eindeutiges H1 mit Ziel-Keyword - Title unter 60 Zeichen + Description unter 160 - Schema.org: Organization/LocalBusiness + Service + FAQPage - Mobile-first Design + PageSpeed 90+ - Sitemap.xml + robots.txt + GSC + Yandex.Webmaster - H2-H3-Struktur für Kunden-Sub-Fragen - Yandex.Metrika + GA4 + regelmäßige Anfragen-Analyse ## Schritt-für-Schritt-Plan: Start in einer Woche So sieht ein realistischer Zeitplan für SEO-Setup einer Einseiten-Website aus: 1. AuditTag 1 2. KeywordsTag 2 3. ContentTag 3-4 4. Tech-SEOTag 5 5. IndexierungTag 6+ **Tag 1 – Audit.** Starten Sie [PageSpeed Insights](https://pagespeed.web.dev), prüfen H1/Title/Meta via DevTools, sehen ob Schema.org-Markup da ist (Schema.org-Validator). Ziel – verstehen, was funktioniert und was zu reparieren ist. **Tag 2 – Keywords.** Öffnen Sie Google Keyword Planner und Ahrefs-Free-Tools. Finden Sie 1 Haupt-Keyword (das Sie ranken wollen) + 3-7 Long-Tail-Variationen. Zum Beispiel: Haupt – «KI-Automation für Unternehmen», Variationen: «KI-Agent für Kunden», «KI-FAQ-Chatbot», «Lead-Automation mit KI». **Tag 3-4 – Content.** Texte so umschreiben, dass das Haupt-Keyword in H1, Title, erstem Absatz und 2-3x natürlich im Body steht. H2-H3-Sektionen für Long-Tail-Keywords hinzufügen. Minimum 1500 Wörter für kommerzielle Landingpage – weniger wertet Google als «nicht tief genug». **Tag 5 – Tech-SEO.** Schema.org JSON-LD hinzufügen (LocalBusiness, Service, FAQPage). Title/Description schreiben. Mobile-Layout prüfen. Bilder auf WebP komprimieren. Sitemap.xml und robots.txt im Root erstellen. **Tag 6+ – Indexierung.** In Google Search Console und Yandex.Webmaster registrieren. Sitemap einreichen. Manuelle Indexierung anfordern («inspect URL» → «request indexing»). Innerhalb 1-3 Tage erscheint die Seite bei Long-Tail-Anfragen, in 2-4 Wochen bei breiteren. **Pro-Tipp:** zur Beschleunigung der Indexierung – posten Sie den Site-Link in einem aktiven Social-Kanal (LinkedIn, Telegram-Kanal, Twitter). Suchmaschinen finden Sites schneller, wenn bereits externe Links existieren. Ein LinkedIn-Post = Indexierung in 1-2 Tagen statt 2-4 Wochen. ## 5 SEO-Mythen, die im Weg stehen ### Mythos 1: «Man braucht viele Seiten, um zu ranken» Realität: bei Nischen-Anfragen schlägt eine Qualitäts-Seite oft eine Site mit 50 oberflächlichen. Qualität > Quantität. ### Mythos 2: «Mehr Keywords im Text = besser» Realität: seit 2020 ist Über-Optimierung (Keyword Stuffing) ein Abwertungs-Faktor. Ziel: Haupt-Keyword 3-5x pro 1500 Wörter natürlich, nicht mehr. ### Mythos 3: «Links sind alles in SEO» Realität: 2026 schlägt Content Links. Gekaufte Links von Börsen – Ban-Risiko. 1 Link von einer relevanten Branchen-Seite ist 100 von Farmen wert. ### Mythos 4: «SEO kann schnell sein – 14 Tage» Realität: 2-4 Wochen bis erste Impressions, 2-3 Monate bis stabile Positionen. Wer schneller verspricht – nutzt entweder Black-Hat (Ban) oder lügt. ### Mythos 5: «KI generiert SEO-Content, man muss nicht selbst schreiben» Realität: KI ist Helfer, aber Google hat gelernt, «komplett KI-generierten» Content zu erkennen und werten ihn ab. KI für Entwürfe nutzen, dann mit eigener Erfahrung und echten Cases überarbeiten. ## 7 typische Fehler Diese Fehler sehe ich regelmäßig – bei Kunden, die SEO selbst gemacht haben oder über billige Freelancer. 1. **Auf die «höchste Volumen»-Anfrage zielen.** Sie wollen für «Website bestellen» ranken (Millionen Wettbewerber). Realistischer – «Custom-Website für B2B in Berlin» (50 Wettbewerber, Ihr ICP). 2. **Mehrere H1 auf einer Seite.** Oft passiert, wenn Logo in `

` plus weiteres `

` im Hero. Muss genau eins sein. 3. **Title und Description vom Wettbewerber kopiert.** Google wertet Duplikate ab. Eigene schreiben, für Ihr Angebot. 4. **Schlechte Mobile-Version.** Font unter 14px, klebrige Buttons, umständliche Formulare – Google indexiert die mobile Version und wertet schlechtes UX ab. 5. **Keine Analytics von Anfang an.** Drei Monate später wollen Sie wissen «funktioniert SEO» – aber keine Daten. Metrika und Search Console am Tag 1 einrichten. 6. **Wachstum in 2 Wochen erwarten, nach einem Monat aufgeben.** SEO ist Compound-Effekt. Monat 1 – fast nichts. Monat 3 – spürbares Wachstum. Monat 6 – stabiler Fluss. Geduld. 7. **Schema.org ignorieren.** «Das ist für E-Commerce» – nein. LocalBusiness + Service + FAQPage sind auf jeder kommerziellen Landingpage Pflicht. **Gutes Fortschritts-Zeichen:** in Search Console wachsen Impressionen jede Woche. CTR ist noch niedrig – das ist normal, man hebt ihn weiter durch besseren Title und Description. Aber wenn Impressionen nicht wachsen – funktioniert SEO nicht, Zeit zu prüfen was schiefläuft. ## Häufig gestellte Fragen Kann eine Einseiten-Website überhaupt in Google ranken? Ja, besonders bei engen kommerziellen Anfragen. Eine Einseiten-Website verliert gegen Multi-Page-Sites nur bei «breiten» Anfragen (wie «Sneaker kaufen»), aber bei nischigen und lokalen Anfragen («Waschmaschinen-Reparatur Berlin» oder «KI-Automation für B2B in München») kommt sie mit richtiger Optimierung leicht in die Top 10. Wichtig: nicht «alles auf einmal» mit einer Seite anpeilen. Was kostet SEO für eine Landingpage ohne Agentur? Basis-Optimierung – 0 €. Kostenlose Tools: Google Search Console, Yandex.Webmaster, PageSpeed Insights, Schema.org Validator, ChatGPT/Claude zur Text-Prüfung. Zahlen müssen Sie nur für ein professionelles Audit (50-200 € einmalig) oder Backlinks (separates Thema, würde ich nicht damit anfangen). 95% des Ergebnisses kommt aus kostenlosen Tools. Wie viele Keywords kann eine einzelne Seite realistisch ranken? 1 Haupt-Keyword + 3-7 verwandte Long-Tail-Variationen. Beispiel: Haupt – «Website bestellen», Variationen: «Website-Kosten», «Website-Zeitplan», «Firmenwebsite bestellen». Wenn Sie 15 verschiedene Themen anpeilen – versteht Google nicht, worum es geht, und rankt sie für nichts. Was zählt 2026 mehr: Content oder Links? Content zählt massiv mehr, besonders bei Einseiten-Sites. Google unterscheidet inzwischen «gute» Backlinks von Spam, und ein Link von einem starken Branchen-Blog ist 100 Links von Farmen wert. Konzentrieren Sie sich auf Content: klares H1, ausführliche Antworten auf Nutzerfragen, Schema.org-Markup, Ladegeschwindigkeit. Links kommen natürlich, wenn der Content nützlich ist. Wann sollte ich SEO-Ergebnisse erwarten? Realistisch: 2-4 Wochen bis zu ersten Impressions in der Suche, 2-3 Monate bis stabile Positionen bei Long-Tail-Anfragen, 4-6 Monate für wettbewerbsintensivere. Wer «Top 10 in 14 Tagen» verspricht – nutzt entweder Black-Hat (wird schnell gebannt) oder lügt. SEO ist ein Marathon, kein Sprint. --- --- title: "Katalog mit Anfrageformular auf Joomla 2026 – für B2B" url: https://tema.name/de/blog/katalog-mit-anfrageformular-joomla-2026.html language: de description: "Katalog mit Anfrageformular auf Joomla 5 + HikaShop ohne Warenkorb: für B2B und Dienstleistungen, wo der Kunde anfragt statt online kauft. 3-5 Wochen, Fehler, FAQ." date_published: 2026-05-26 date_modified: 2026-05-26 --- Joomla / B2B 26. Mai 2026 · 11 Min. Lesezeit · Von Artem # Katalog mit Anfrageformular auf Joomla 2026: für B2B und Dienstleistungen Ein **Anfrage-Katalog auf Joomla 5 + HikaShop** ist eine Schaufenster-Site mit Filter und Vergleich, aber ohne Warenkorb und Online-Zahlung — statt „Kaufen“ klickt der Kunde „Anfrage stellen“. Typische Größe: **50–500 Positionen**, Time-to-Launch **3–5 Wochen**, Conversion zur Anfrage **5–15 %** bei sauberer Struktur, **0 €** an Payment-Gateway-Gebühren. Das Format passt für B2B-Dienstleistungen, Auftragsfertigung, Handwerk, Bildung, medizinische Leistungen und Industriegeräte — überall dort, wo Preis und Konfiguration vom Manager besprochen werden. Joomla + HikaShop liefert Mehrsprachigkeit out of the box, saubere Rechte pro Redakteur und stabiles Komponenten-Modell. Der Artikel zeigt, für wen das Format funktioniert (und für wen nicht), wie eine Produktkarte aufgebaut sein muss und 7 typische Fehler. **In diesem Artikel** 1. [Für wen das Format passt](#who) 2. [Warum Joomla + HikaShop ohne Warenkorb](#stack) 3. [Start in 3-5 Wochen](#workflow) 4. [Was in eine Karte gehört](#card) 5. [7 typische Fehler](#mistakes) 6. [Häufige Fragen](#faq) ## Für wen das Format passt Ein Anfrage-Katalog ist eine Schaufenster-Website, wo der Kunde alle Optionen sieht, filtert, vergleicht, Details liest und am Ende auf **«Anfrage stellen»** klickt statt «kaufen». Der Manager meldet sich dann, klärt Details, verhandelt individuelle Konditionen und schließt den Deal persönlich. 50-500 typische Katalog-Größe in Positionen 3-5Wo Start von Grund auf 5-15% Conversion zur Anfrage bei gutem B2B-Katalog 0€ Payment-Gateway-Gebühren (nicht nötig) Konkrete Szenarien, wo das Format am besten funktioniert: - **B2B-Dienstleistungen.** Rechtsberatung, Marketing-Services, IT-Outsourcing. Kunde durchsucht Bereiche, liest Cases, stellt Beratungs-Anfrage. - **Auftragsfertigung.** Maßmöbel, Metallkonstruktionen, Spezialmaschinen. Kunde sieht Modellpalette, aber Konfiguration und Preis werden besprochen. - **Handwerkerleistungen.** Reparatur, Montage, Wartung. Leistungs-Liste mit Beschreibungen, «Vor-Ort-Termin buchen»-Formular. - **Bildungskurse.** Wenn ein Vorgespräch nötig ist, Preise flexibel sind (Stipendien, Raten). - **Medizinische Leistungen.** Wo Terminbuchung wichtiger ist als «One-Click-Kauf». - **Industriegeräte.** Preis abhängig von Konfiguration, Lieferung verhandelbar, Rechnung nötig. Nicht geeignet für: alltägliche Einzelhandelswaren (voller Shop nötig), Dienstleistungen mit Fixpreis und schneller Entscheidung (Landing besser), Aggregatoren (Nutzerkonten nötig). ## Warum Joomla + HikaShop ohne Warenkorb Es gibt drei typische Ansätze für einen Anfrage-Katalog. Vergleich: | Ansatz | Vorteile | Nachteile | | --- | --- | --- | | Tilda / Builder | Schneller Start, schönes Out-of-Box-Design | Skaliert schlecht auf 50+ Karten mit Filtern, beschränkte Filter, kein richtiges ACL | | WordPress + WooCommerce ohne Warenkorb | Riesiges Plugin-Ökosystem | Gegen die Plugin-Architektur – Workarounds. Mehrsprachigkeit nur via WPML ($$) | | Joomla 5 + HikaShop Catalog Mode | Natives «No-Cart», Mehrsprachigkeit out of the box, ACL für mehrere Rollen | Weniger fertige Themes als WP, benötigt Joomla-erfahrenen Entwickler | Warum ich Joomla + HikaShop für die meisten Kunden wähle: - **HikaShop kann «Catalog Mode»** – ein Schalter entfernt Warenkorb, Bezahlung, Bestellstatus. Bleibt: filterbares Schaufenster + «Anfrage stellen»-Button. - **Mehrsprachigkeit kostenlos** – Joomla unterstützt RU+EN+DE+PL out of the box ohne WPML-Class-Plugins (60-100 €/Jahr). - **ACL für verschiedene Rollen** – Manager sieht seine Leads, Content-Editor aktualisiert Beschreibungen, Admin sieht alles. Ohne Plugins. - **Weniger «Plugin-Zoo»** – Joomla mit Basis-Stack läuft Jahre stabil ohne wöchentliche Updates. - **Kann später voller Shop werden** – wenn das Geschäft in einem Jahr zu Online-Zahlungen wächst, schaltet HikaShop den Warenkorb mit dem gleichen Schalter ein. **Alternativen:** für ganz kleine Kataloge (10-30 Positionen) – Static mit dynamischen Formularen. Für große B2B mit Integrationen (SAP, Kundenkonten) – anderer Stack (oft Symfony/Laravel + Custom-Admin). Joomla arbeitet im mittleren Bereich 50-500 Positionen. ## Start in 3-5 Wochen So sieht ein realistischer Zeitplan für den Katalog-Start von Grund auf aus: 1. BriefingWo 1 2. StrukturWo 1-2 3. KartenWo 2-3 4. Forms+CRMWo 3-4 5. LaunchWo 4-5 **Woche 1 – Briefing.** Kategorien definieren, typische Karte, Filter-Felder, welche Daten im Anfrageformular zu erfassen, wohin Leads gehen (Telegram-Chat, CRM, Google Sheets). Ergebnis: Katalog-Struktur als Liste. **Wochen 1-2 – Struktur.** Joomla 5 installieren, HikaShop auf Catalog Mode setzen, Mehrsprachigkeit konfigurieren (falls nötig), Kategorien und Attribute anlegen. Brand-konformes Template erstellen. **Wochen 2-3 – Karten.** Katalog füllen: Beschreibungen, Specs, Fotos, Videos (falls vorhanden), Download-Dokumente. Diese Phase dauert meist am längsten – hängt von Content-Bereitschaft beim Kunden ab. **Wochen 3-4 – Forms und Integrationen.** Anfrage-Formulare konfigurieren: globales «Anfrage stellen», pro Karte individuelles «zu diesem Item fragen». Integrationen anbinden: Leads fliegen in Manager-Telegram + CRM (Bitrix24, AmoCRM, HubSpot) + Google Sheets als Backup. **Wochen 4-5 – Launch.** Finales Testing auf Desktop, Mobil, Tablet. Analytics anschließen (Yandex.Metrika mit Zielen, Google Analytics 4). In Google Search Console und Yandex.Webmaster registrieren, Sitemap einreichen. Zugänge an Kunden mit Kurzanleitung übergeben. ## Was in eine Karte gehört Die Produkt-/Dienstleistungskarte ist das Schlüsselelement des Katalogs. Ihre Qualität entscheidet, ob der Kunde eine Anfrage stellt oder «zum Nachdenken» geht. Pflicht-Minimum: - Titel – knapp, mit Schlüsselbegriff (wenn SEO wichtig) - 2-3 qualitative Fotos oder Videos – nicht Stock, sondern echt - Kurzbeschreibung (1-2 Absätze) – was es ist, für wen, Hauptnutzen - Specs als Tabelle – strukturiert, nicht Fließtext - Preis «ab» oder Range – auch grob, sonst denkt der Kunde «wahrscheinlich teuer» - Termin (Produktion, Lieferung, Ausführung) – konkret, nicht «zu besprechen» - «Zu diesem Item fragen»-Formular direkt auf der Karte, nicht nur im Footer - Ähnliche Items unten, zur Navigation zwischen Optionen Zusätzliche Elemente, die die Conversion erhöhen (in meiner Erfahrung 2-5% Lift): - **Anwendungskontext** – «passt für», «wird verwendet in». Hilft dem Kunden zu entscheiden, ob es seine Option ist. - **Vergleich zu ähnlichen Items** – «wie es sich von Modell X unterscheidet». Reduziert Fragen im Formular. - **Case oder Testimonial** – 1-2 Sätze von einem echten Kunden, der genau dieses Item bestellt hat. - **Garantien** – Garantiezeit, Rückgabebedingungen, was im Preis enthalten ist. - **Download-Dokumente** – PDF-Datenblatt, Zertifikate, Anleitung. B2B-Kunden lieben es, «Material für interne Freigabe» mitzunehmen. **Kernprinzip:** Die Karte soll so viele Fragen wie möglich beantworten, bevor der Kunde anfragt. Je mehr Sicherheit er auf der Karte gewinnt, desto höher die Chance, dass er Ihnen schreibt statt mit Wettbewerbern zu vergleichen. ## 7 typische Fehler Diese Fehler sehe ich regelmäßig – bei Kunden, die den Katalog selbst oder mit einem vorherigen Auftragnehmer gebaut haben. 1. **Anfrage-Katalog als vollen Online-Shop bauen.** Warenkorb, Bestellstatus, alles Überflüssige inkludiert. Resultat: Kunde verwirrt – «in den Warenkorb oder direkt schreiben?». Warenkorb muss aus. 2. **Zu viele Kategorien.** 15-20 Kategorien für 50 Items – Overkill. Besser 4-6 breite Kategorien mit Filtern intern. 3. **Kein Formular auf der Karte.** Formular nur im Footer. Kunde las die Karte, war interessiert, wollte klicken – musste zurückscrollen. Ein Teil springt ab. 4. **Kein Preis.** «Preis auf Anfrage» ist der größte Conversion-Killer. Mindestens Range oder «ab X» zeigen. Sonst denkt der Kunde «teuer = nicht für mich». 5. **Ein Universal-Manager für alles.** 50+ Positionen brauchen verschiedene Verantwortliche. Joomla-ACL erlaubt das – Manager A sieht Leads in Kategorie 1, B in Kategorie 2. 6. **Keine Analytics und Ziele.** Katalog gestartet – «funktioniert er?» – unbekannt. Yandex.Metrika mit Form-Submit-Zielen ist ab Tag 1 Pflicht. 7. **Kein CRM angebunden.** Leads gehen nur in E-Mail und verschwinden. Brauchen: Manager-Telegram + CRM + Google Sheets als Backup. Drei Punkte – nichts geht verloren. **Pro-Tipp:** nach den ersten 50-100 Anfragen analysieren, welche Items mehr Anfragen bekommen als andere. Eventuell als «top» oder «beliebt» Kategorie hervorheben – weitere 5-10% Conversion-Lift. ## Häufig gestellte Fragen Wie unterscheidet sich ein Anfrage-Katalog von einem Online-Shop? Im Online-Shop legt der Kunde in den Warenkorb, zahlt online, erhält die Bestellung automatisch. Im Anfrage-Katalog durchsucht der Kunde Optionen und stellt dann eine Anfrage – «möchte besprechen» – ein Manager meldet sich. Passt zu B2B, beratungsintensiven Dienstleistungen, Auftragsfertigung, Ausschreibungen. Technisch einfacher: keine Online-Zahlungen, keine Bestellstatus, nur Lead-Bearbeitung. Warum Joomla und nicht Tilda oder WordPress? Tilda ist für Marketing-Landings, skaliert schlecht auf 50+ Karten mit Filtern. WordPress + WooCommerce lässt sich «ohne Warenkorb» konfigurieren, aber das geht gegen die Plugin-Architektur. Joomla 5 + HikaShop im «Catalog Mode» ist genau für diese Aufgabe, mit Mehrsprachigkeit out of the box und sauberem ACL. Für 50-500 Positionen optimaler Stack. Wie viele Positionen verkraftet der Katalog? Ohne Optimierung – 50-300 Positionen komfortabel. Mit Caching und gutem Hosting – bis 5.000. Darüber hinaus braucht es dedizierte Lösungen: entweder eine spezialisierte B2B-Plattform oder eine Custom-Architektur. Bei 1.000+ SKU mit aktiven Änderungen – besprechen wir separat. Wie misst man die Effektivität des Katalogs? Hauptmetrik – Conversion-Rate von Karten-Ansicht zu Anfrage-Eingang. Guter Benchmark: 5-15% für B2B, 2-5% für Mass-Market-Dienstleistungen. Gemessen via Yandex.Metrika oder GA4 + Form-Submit-Ziele. Wenn Conversion unter 2% – Problem entweder in den Karten (keine Details, schlechte Fotos) oder im Formular (lang, abschreckend). Kann man später Online-Zahlung hinzufügen? Ja, HikaShop schaltet den Warenkorb über eine Einstellung im Admin wieder ein – buchstäblich ein Schalter. Dann lassen sich Payment Gateways anbinden (Stripe, PayPal, lokale Abwickler). Die Katalog-Architektur übersteht die Migration zum vollen Shop ohne Frontend-Rebuild. Das ist ein Plus, wenn man Joomla von Anfang an wählt. --- --- title: "KI-Agenten mit RAG für Wissensbasis 2026" url: https://tema.name/de/blog/ki-agenten-rag-wissensbasis-2026.html language: de description: "Was RAG ist, wie es funktioniert, Systemkomponenten, typische Fehler. Pinecone vs Qdrant vs pgvector. Implementierungszeit und Kosten." date_published: 2026-05-27 date_modified: 2026-05-27 --- KI-Agenten / RAG 27. Mai 2026 · 12 Min. Lesezeit · Von Artem # KI-Agenten mit RAG für Wissensbasis 2026: Implementierungs-Guide **RAG (Retrieval-Augmented Generation)** liest vor jeder Antwort Ihre Dokumente und antwortet mit Quellenangaben statt zu halluzinieren. Für typische B2B-Wissensbasen von **50–5 000 Dokumenten** liegt die Antwort-Genauigkeit bei sauberer Datenaufbereitung bei **70–90 %**. Implementierungs-Zeitrahmen für einen Basis-Agenten: **2–4 Wochen**, Betriebskosten für mittelständische Unternehmen **20–300 $/Monat**. Stack 2026: OpenAI- oder Cohere-Embeddings, Vektor-Datenbank (Qdrant, Weaviate oder pgvector), Top-3–7 Chunks pro Anfrage in den LLM-Kontext, Generierung mit Claude oder GPT-4o. Typische Anwendungen: Kunden-Support, interne Suche für Mitarbeiter, Onboarding, Sales-Assistent und Compliance-Auskunft. Anders als reines ChatGPT kennt RAG Ihr Produkt, umgeht das Cut-off-Datum und liefert prüfbare Quellen. Der Artikel zeigt die Architektur, den 2–4-Wochen-Plan, den Vektor-DB-Vergleich und 7 typische Fehler. **In diesem Artikel** 1. [Was ist RAG und wozu](#what-is) 2. [5 typische Anwendungen](#use-cases) 3. [Komponenten eines RAG-Systems](#components) 4. [Start in 2-4 Wochen](#workflow) 5. [Vergleich Vektor-Datenbanken](#vectordb) 6. [7 typische Fehler](#mistakes) 7. [Häufige Fragen](#faq) ## Was ist RAG und wozu Stellen Sie sich ChatGPT vor, der vor jeder Antwort Ihr Corporate-Wiki, Produkt-Doku, Richtlinien, gelöste Tickets liest – und eine Antwort **mit Links zu konkreten Dokumenten** gibt, aus denen er die Information geholt hat. Das ist RAG. 50-5000 typische Wissensbasis-Größe für B2B-Aufgaben 2-4Wo Implementierungs-Zeitrahmen für einen Basis-Agenten 70-90% Antwort-Genauigkeit bei gut vorbereiteten Daten $20-300/Mo Betriebskosten für mittelständische Unternehmen Warum normales ChatGPT für die meisten Business-Aufgaben nicht reicht: - **Kennt Ihr Produkt nicht.** ChatGPT hat Ihre Doku nicht gelesen, kennt keine Spezifika, erfindet «plausible» aber ungenaue Antworten. - **Cut-off-Datum.** Auch Claude oder GPT-4 sind auf Daten bis zu einem bestimmten Datum trainiert. Produkt-Änderungen danach – unbekannt. - **Keine Quellenangaben.** Nutzer kann nicht prüfen, woher die Antwort kommt – weniger Vertrauen. - **Teuer, alles in den Kontext zu packen.** 200K-Token-Kontextfenster – aber 1000 PDFs passen nicht rein, und Kosten pro Anfrage werden riesig. RAG löst alle vier. Vor dem Antworten **findet das System 3-7 relevanteste Stücke** in Ihrer Basis und übergibt sie dem LLM als Kontext. Das LLM bildet die Antwort auf Basis genau dieser Stücke, mit Zitaten. **Kern:** RAG ersetzt ChatGPT nicht – er ergänzt ihn. ChatGPT liefert «allgemeines Weltwissen», RAG liefert «Wissen Ihres konkreten Unternehmens, Produkts, Bereichs». Zusammen – ein mächtiges Werkzeug. ## 5 typische Anwendungen ### 1. Support über Produkt-Dokumentation Kunde fragt im Site-Chat oder Telegram-Bot. RAG sucht in Dokumentation, FAQ, gelösten Tickets. Schließt 60-80% typischer Fragen ohne Mensch. Komplexe Fälle gehen an den Operator mit vorbereiteter Zusammenfassung. ### 2. Interne Suche im Corporate-Wiki Ein neuer Mitarbeiter erinnert sich nicht «wie wird bei uns Dienstreise abgewickelt» oder «wo ist die Richtlinie zur Kundenkommunikation». Fragt den RAG-Agenten. Der findet in Notion/Confluence/Google Docs das passende Dokument, zitiert den relevanten Teil, gibt Link zum vollen Doc. ### 3. Sales-Assistent über Produkte Vertriebler im Kundengespräch. Kunde stellt komplexe technische Frage. Vertriebler öffnet RAG-Chat, fragt, bekommt Antwort mit Links zu Tech-Specs, Verträgen, Cases. Antwortgeschwindigkeit zum Kunden – ×3-5. ### 4. Analyse juristischer Dokumente Anwalt lädt einen Vertrag hoch. RAG prüft ihn gegen Corporate-Standards («Pflichtklauseln», «rote Flaggen»), markiert Unterschiede und Risiken, zitiert Präzedenzfälle aus früheren Deals. ### 5. Bildungs-Assistent Student in einem Online-Kurs stellt eine Frage. RAG findet die Antwort in Kurs-Materialien, Folien, Vorlesungs-Transkripten. Nimmt 70% typischer Fragen vom Tutor weg, erhöht die Course-Completion-Rate. Das ist keine erschöpfende Liste. RAG ist überall einsetzbar, wo es eine **große Basis semi-strukturierten Texts** und wiederkehrende Fragen dazu gibt. ## Komponenten eines RAG-Systems RAG ist nicht «ein Service», sondern eine Pipeline aus 6-7 Komponenten. Jede muss zur Aufgabe passen. - **Datenquelle** – PDF, Webseiten, Notion, Confluence, Google Docs, SharePoint, CSV/Excel, Datenbanken. Quelle bestimmt, wie Text extrahiert wird. - **Parser und Chunker** – teilt Dokumente in 300-800 Token-Chunks. Chunk-Größe beeinflusst Such-Qualität stark. - **Embeddings-Modell** – konvertiert Text in Vektoren. OpenAI text-embedding-3-small (universal), Voyage-large (genauer bei Code), Cohere embed-multilingual (mehrsprachig). - **Vektor-Datenbank** – speichert Vektoren und findet schnell «ähnliche». Pinecone, Qdrant, Weaviate, pgvector in Postgres. - **Retrieval-Logik** – findet Top-K-Chunks, optional Re-Ranking (Cohere Rerank, Voyage Rerank) für höhere Genauigkeit. - **LLM** – bildet die finale Antwort auf Basis gefundener Chunks. Claude Sonnet (lange Kontexte), GPT-4 (universal), Mistral/Llama (lokal). - **Prompt-Template** – Modell-Anweisung: «antworte nur basierend auf Dokumenten unten, zitiere Quellen, sag direkt wenn du etwas nicht weißt». - **UI oder API** – Chat auf der Site, Telegram-Bot, Notion-Widget, oder REST-API zur Integration ins eigene Produkt. **Ohne irgendeine Komponente klappt es nicht.** Habe oft gesehen: Pinecone gekauft, 200 PDFs komplett geladen, ChatGPT gegeben – «funktioniert nicht». Klar nicht: kein Chunker, falsche Embeddings, kein Prompt-Tuning. RAG ist Pipeline, kein Service. ## Start in 2-4 Wochen Realistischer Zeitplan für den Start eines Basis-RAG-Agenten von null: 1. DatenT 1-3 2. ChunkingT 4-6 3. EmbeddingsT 7-10 4. RetrievalT 11-16 5. UI+TestsT 17-21 **Tage 1-3 – Daten.** Alle Quellen sammeln: was soll der Agent wissen. Bereinigen: veraltetes entfernen, Duplikate, Müll-Dokumente. An diesem Punkt entdecken wir meist «unsere Doku wurde zuletzt vor 3 Jahren aktualisiert» – ein Teil der Arbeit liegt beim Kunden. **Tage 4-6 – Chunking.** Dokumente parsen, in Chunks teilen. Viele Nuancen hier: PDF mit Tabellen braucht spezielle Behandlung, Code-Blöcke dürfen nicht mittendurch geschnitten werden, Überschriften müssen mit Kontext erhalten bleiben. Nicht «ein universeller Chunker für alles», sondern angepasst. **Tage 7-10 – Embeddings.** OpenAI- oder Voyage-API anbinden, alle Chunks durch das Embeddings-Modell laufen lassen. In Vektor-DB speichern. Für DE+EN-Content nutze ich multilingual Modelle; für reines Englisch reicht text-embedding-3-small. **Tage 11-16 – Retrieval.** Suche einrichten: Top-K (meist 5-10), Ähnlichkeits-Schwelle, optional Re-Ranking. Auf 20-30 typischen Fragen testen: kommen relevante Chunks zurück? Wenn nicht – tunen: Chunk-Größe, Embeddings, Prompt ändern. **Tage 17-21 – UI und Tests.** Interface bauen: Chat auf der Site via iframe, Telegram-Bot, Notion-Widget, oder REST-API. Monitoring anschließen: Anfrage-Logs, Nutzer-Bewertungen (👍/👎), Genauigkeits-Metriken. Finales Testing mit echten Nutzern. ## Vergleich Vektor-Datenbanken Die Wahl der Vektor-DB beeinflusst Kosten, Geschwindigkeit, Skalierungs-Komfort. Drei populäre Optionen: | Lösung | Vorteile | Nachteile | | --- | --- | --- | | Pinecone | Managed, schneller Start, kein DevOps nötig | Teurer beim Wachstum ($70+/Monat), Vendor-Lock-In, kein Self-Host | | Qdrant | Open Source, kostenloses Self-Hosting oder Qdrant Cloud. Hohe Geschwindigkeit | Braucht Basis-Infra (Docker) für Self-Host | | PostgreSQL + pgvector | Wenn schon Postgres da ist – Extension installieren, keine neue Infra | Etwas langsamer bei riesigen Sets (10M+ Vektoren), Indices nötig | | Weaviate | Hybrid-Search (Vektoren + Keywords), Module für verschiedene Embeddings | Mehr Setup-Komplexität als Pinecone/Qdrant | Meine Empfehlungen: - **Prototyp / MVP** – Pinecone Free Tier oder Qdrant lokal. Schneller Start, keine Infra-Sorgen. - **Production bis 1M Vektoren** – Qdrant Self-Hosted auf VPS ($10-30/Monat) oder Pinecone Starter ($70/Monat). - **Schon Postgres da** – pgvector, keine neue Infra, bequem für das Team. - **Enterprise mit 10M+ Vektoren** – Pinecone Enterprise oder Qdrant Cloud mit Replicas. ## 7 typische Fehler 2 Jahre aktive Arbeit mit RAG-Systemen – hier die Top-Problem-Verursacher. 1. **Alles wahllos laden.** Müll rein = Müll raus. 80% der Arbeit geht in Daten-Prep: Bereinigung, Normalisierung, Veraltetes entfernen. Kein «technisches Detail», sondern die halbe Miete. 2. **Zu große Chunks.** Wenn ein Chunk eine ganze Seite ist, findet das Modell «diese Seite» statt «den konkreten Absatz». Genauigkeit fällt. Optimal – 300-800 Tokens mit Overlap 50-100. 3. **Zu kleine Chunks.** Wenn ein Chunk 1 Satz ist – Kontext geht verloren: «es» bezieht sich auf nichts. Zu kurz ist auch schlecht. 4. **Ein Embedding-Modell für alle Sprachen.** Bei DE+EN-Content brauchen Sie multilingual Embeddings (Cohere multilingual, OpenAI text-embedding-3-large). Sonst funktioniert cross-language Suche nicht. 5. **Kein Re-Ranking.** Top-K aus Vektor-Search enthält oft «ähnlich aber nicht exakt». Re-Ranking-Modell sortiert nach Relevanz – 15-30% Genauigkeits-Lift. 6. **Citations ignorieren.** Antwort ohne Quellenlinks = kein Vertrauen. Prompt muss Zitate explizit verlangen: «setze Quelle in eckige Klammern nach jedem Fakt». Nutzer sieht Link → klickt → prüft → vertraut. 7. **Basis nicht aktualisieren.** Nach 3-6 Monaten veraltet die Doku, Antworten werden falsch. Brauchen regelmäßigen Re-Indexing-Prozess: automatisch bei Notion/Confluence-Änderung oder wöchentlicher Cron-Job. **Gutes Zeichen, dass RAG funktioniert:** Nutzer fangen an, ihm mehr zu vertrauen als der Wiki-Suche. Wenn Sie nach 1-2 Monaten sehen, dass Anfragen an den Agenten wachsen und Support-Anfragen sinken – System funktioniert. Wenn umgekehrt – Antwort-Qualität-Problem, Zeit zum Debug. ## Häufig gestellte Fragen Wie unterscheidet sich ein RAG-Agent von normalem ChatGPT? Normales ChatGPT antwortet aus den Trainingsdaten (bis zum Cut-off-Datum). Es kennt Ihr Produkt, Ihre Dokumente oder internen Prozesse nicht. Ein RAG-Agent sucht vor jeder Antwort relevante Stücke in Ihrer Wissensbasis (Dokumentation, Artikel, Richtlinien) – mit Quellenangaben. Im Kern: «ChatGPT, der Ihre Dokumente vor dem Antworten liest». Was kostet die Implementierung eines RAG-Agenten? Basis-Agent für 50-500 Dokumente: 2-4 Wochen Entwicklung + $20-100/Monat für Vektor-DB und LLM-API. Für Unternehmen mit mittlerem Traffic (100-500 Anfragen/Tag) – ~$100-300/Monat. Große Enterprise-Installationen mit 10.000+ Dokumenten und tausenden täglichen Anfragen – ab $1000/Monat. Konkrete Schätzung – nach kurzem Briefing. Wie viele Dokumente kann RAG realistisch verarbeiten? Von 10 bis Millionen. Technisch keine Obergrenze. 10-100 Dokumente – jede Vektor-DB funktioniert. 1.000-10.000 – managed (Pinecone) oder self-hosted Qdrant. Über 100.000 – braucht Chunking-Optimierung, hierarchisches Retrieval, manchmal separate Indices je Content-Typ. In meiner Praxis sind 500-5.000 Dokumente die häufigste Größe. Sind meine Daten bei OpenAI oder Anthropic sicher? API-Aufrufe (Paid-Pläne) – Ihre Daten werden nicht für Training verwendet, das steht in den Terms of Service beider Anbieter. Für sensible Daten gibt es Optionen: Enterprise-Pläne mit unterschriebener DPA, lokale Modelle (Llama, Mistral) auf eigenem Server, oder Hybrid-Ansatz. Für die meisten B2B-Aufgaben reichen API-Pläne. Für PII oder Medizin – lokales Modell oder Enterprise. Pinecone, Qdrant oder PostgreSQL+pgvector – was ist besser? Pinecone – schneller Start, managed, teurer beim Wachstum ($70+/Monat). Qdrant – Open Source, kostenloses Self-Hosting oder Qdrant Cloud. PostgreSQL+pgvector – wenn Sie schon Postgres haben, Extension installieren, keine neue Infra. Für 10-100K Vektoren funktionieren alle drei. Für Millionen – Pinecone oder Qdrant Cloud. Für Teams ohne DevOps – Pinecone am einfachsten. --- --- title: "Cloudflare Workers für Unternehmen 2026: Guide" url: https://tema.name/de/blog/cloudflare-workers-fuer-unternehmen-2026.html language: de description: "Cloudflare Workers für Unternehmen 2026: was es ist, 5 Anwendungen, Vergleich mit Lambda/Vercel, typische Fehler. Start ohne eigenen Server in Minuten." date_published: 2026-05-28 date_modified: 2026-05-28 --- Serverless / Edge 28. Mai 2026 · 11 Min. Lesezeit · Autor: Artjom # Cloudflare Workers für Unternehmen 2026: praktischer Guide **Cloudflare Workers** ist Serverless Edge Compute: eine JavaScript- oder TypeScript-Funktion läuft in **über 330 Städten** weltweit, Kaltstart ca. **5 ms**, Antwortzeit typisch **5–50 ms**. Der Free-Plan deckt **100 000 Anfragen pro Tag**, der Paid-Plan ab **5 $/Monat** bis 10 Mio. Anfragen. Sinnvoll für 5 typische Fälle: API-Gateway vor Legacy-Backend, A/B-Tests und Geo-Routing am Edge, Webhook- und Telegram-Bot-Handler, Bildoptimierung on the fly sowie Auth- und Rate-Limiting. Datenhaltung am Edge via KV, R2 (S3-kompatibel, kostenloser Egress) und D1 (SQLite, 5 $/Monat für 10 GB). Verglichen mit AWS Lambda spart man Egress-Gebühren und Kaltstart, gegenüber Vercel spart man Vendor-Lock-in. Der Artikel zeigt das Ökosystem, 5 Business-Use-Cases, einen Stunden-Start sowie 7 typische Fehler. **Im Artikel** 1. [Was sind Workers und das Ökosystem](#what-is) 2. [5 Anwendungen für Unternehmen](#use-cases) 3. [Vergleich mit Alternativen](#compare) 4. [Start des ersten Workers in einer Stunde](#workflow) 5. [7 typische Fehler](#mistakes) 6. [Häufige Fragen](#faq) ## Was sind Workers und das Ökosystem Cloudflare Workers ist **Serverless Edge Compute**. Sie schreiben eine Funktion in JavaScript/TypeScript (oder Rust/Python via Pyodide), deployen sie per CLI oder Git, und sie läuft sofort in über 330 Städten weltweit – Cloudflare verteilt sie selbst auf den nächstgelegenen Server zum Nutzer. 330+ Edge-Standorte weltweit für Code-Deployment 100K/Tag Anfragen kostenlos im Free-Plan ~5-50ms typische Antwortzeit eines Workers 5 $/Mon. Paid-Plan: 10 Mio. Anfragen pro Monat Der Hauptunterschied zu klassischen Clouds: **der Code wird im selben Netzwerk wie das CDN ausgeführt**. Es gibt keine Konzepte wie „Instanz“, „Region“ oder „Availability Zone“. Kaltstart ist kaum vorhanden – ein V8-Isolate startet in 5ms. Rund um Workers hat Cloudflare ein ganzes Ökosystem an Diensten aufgebaut: - **KV (Key-Value)** – verteilter Speicher für Cache, Sessions, Feature-Flags. Kostenlos bis 100K Reads pro Tag. - **R2 (Object Storage)** – S3-kompatibler Speicher für Dateien. Der Knaller: kostenloser Egress (bei AWS S3 zahlen Sie für jedes ausgelieferte Byte). - **D1 (SQL Database)** – SQLite am Edge. 5 $/Monat für 10GB. Geeignet für die meisten Webanwendungen bis 10M Anfragen. - **Durable Objects** – Objekte mit konsistentem State. Für Chat-Räume, Queues, WebSocket-Anwendungen. - **Queues** – Message Queues für asynchrone Verarbeitung. - **Workers AI** – Ausführung von Open-Source-Modellen (Llama, Mistral, Embeddings) direkt am Edge. Ohne Datenweitergabe an Dritte. - **Hyperdrive** – beschleunigte Verbindung zu externen PostgreSQL/MySQL/MongoDB. **Kerngedanke:** Workers ist kein „Ersatz für einen Server“, sondern ein anderer Ansatz. Sie schreiben kleine Funktionen, die nahe am Nutzer laufen, ohne Infrastruktur-Management. Für 70-80 % aller Business-Aufgaben reicht das aus. ## 5 Anwendungen für Unternehmen ### 1. Telegram-Bot ohne eigenen Server Der häufigste Use-Case. Ein Telegram-Bot per Webhook ist ein HTTP-Endpoint, der POST-Anfragen empfängt. Ein Worker erledigt das mühelos. Session-State – in KV (kostenlose 100K Reads/Tag). Integrationen mit CRM oder OpenAI – per fetch zu deren APIs. Kein VPS, kein PM2 oder systemd – deployen und vergessen. ### 2. Verarbeitung von Webformularen Kontaktformular auf einer statischen Landingpage → Worker → Versand in den Telegram-Chat des Vertriebs / per E-Mail / in das CRM. Spam-Schutz (Honeypot, Rate-Limit) – ein paar Zeilen im Worker. Ein einziger Worker kann Formulare von 10 Websites parallel bedienen. Der Free-Plan reicht für ein mittelständisches Unternehmen mehr als aus. ### 3. KI-Proxy zum Schutz von API-Schlüsseln Sie wollen Nutzern Zugang zu ChatGPT/Claude über Ihre eigene UI geben? Direkt aus dem Browser an OpenAI/Anthropic gehen ist tabu – der API-Key wäre öffentlich. Worker als Proxy: das Frontend ruft den Worker auf, der Worker hängt den API-Key aus den Umgebungsvariablen an und ruft OpenAI auf. Der Schlüssel verlässt den Server nie. ### 4. Bildoptimierung on-the-fly Cloudflare Images oder ein eigener Worker mit einer Polish-Bibliothek: Bildoptimierung „on the fly“. Sie laden das Original in R2, der Worker macht Resize, Konvertierung in WebP/AVIF, Wasserzeichen – per URL-Parameter. PageSpeed +20-30 Punkte auf Seiten mit vielen Bildern. ### 5. Geo-Routing und A/B-Tests Ein Worker sieht Land, Region und Browsersprache des Nutzers. Russen können auf `tema.name/`, Deutsche auf `/de/`, Polen auf `/pl/` geleitet werden. Analog für A/B-Tests: verschiedene Seitenversionen ohne separaten Dienst. Jedes „Experiment = zweite Seite“ wird am Edge abgearbeitet, bevor die Anfrage Ihren Origin erreicht. **Nicht geeignet für:** aufwändige Videoverarbeitung (Limit von 50ms CPU pro Anfrage im Paid-Plan), monolithische Django/Rails-Anwendungen mit tausenden Abhängigkeiten, Aufgaben mit langem State (>30 Sekunden). ## Vergleich mit Alternativen | Parameter | Cloudflare Workers | AWS Lambda | Vercel Functions | | --- | --- | --- | --- | | Regionen | 330+ Edge-Standorte | Eine Region (manuell gewählt) | Edge + Regionen | | Kaltstart | ~5ms | 200-2000ms (Node.js), schlechter bei Java | 50-300ms | | Sprachen | JS/TS/Rust/Python (Pyodide) | Node.js/Python/Go/Java/Ruby/.NET | JS/TS, Python | | Free-Plan | 100K Anfragen/Tag | 1M Anfragen/Monat | 100K Anfragen/Monat | | Kosten 10M Anfragen | 5 $/Monat | ~20 $/Monat + GB-Seconds | ~20 $/Monat | | Bindung | Cloudflare-Ökosystem | AWS-Ökosystem (S3, DynamoDB...) | Vercel + Next.js-Fokus | | Idle bis erste Antwort | Sofort | Bis zu 2 Sekunden (Cold Start) | Bis zu 300ms | Meine Empfehlungen: - **Wenn Sie bereits Cloudflare nutzen** – Workers ist eine „kostenlose Erweiterung“ dessen, was Sie ohnehin bezahlen. Weniger Rechnungen, weniger Anbieter. - **Bei intensivem AWS-Stack** (RDS, DynamoDB, SQS) – Lambda ist bequemer, alles in einer VPC. - **Wenn das Frontend auf Next.js / Nuxt / Astro bei Vercel läuft** – Vercel Functions ist bequemer, der Servercode liegt im selben Repo. - **Bei globaler Zielgruppe** – Workers gewinnt dank Edge-Standorten (das CDN platziert den Code im nächstgelegenen DC zum Nutzer). ## Start des ersten Workers in einer Stunde Realistischer Zeitplan für den Start des ersten produktiven Workers von Null: 1. Setup10 Min. 2. Code15 Min. 3. Deploy5 Min. 4. Routes10 Min. 5. Tests20 Min. **Setup (10 Min.).** Cloudflare-Konto anlegen (falls nicht vorhanden), `wrangler`-CLI installieren (`npm install -g wrangler`), `wrangler login` – öffnet den Browser zur Authentifizierung. Damit haben Sie eine funktionierende Arbeitsumgebung. **Code (15 Min.).** `wrangler init my-worker` erzeugt eine Vorlage. Ein einfacher Worker – 10 Zeilen TypeScript: nimmt einen HTTP-Request entgegen, gibt eine Response zurück. Für einen Telegram-Bot ergänzen Sie JSON-Handling und Aufrufe der Telegram-API per fetch. **Deploy (5 Min.).** `wrangler deploy` – der Worker ist sofort unter `\*.workers.dev` erreichbar. Logs per `wrangler tail`. Ohne Docker, ohne CI/CD, ohne Kubernetes. **Routes (10 Min.).** Wenn Ihre Domain bereits auf Cloudflare läuft – fügen Sie im Workers-Dashboard eine Route hinzu: `api.yourdomain.com/\*` → Ihr Worker. Ab diesem Moment gehen Anfragen an diese URL in den Worker. **Tests (20 Min.).** Lokales Testen mit `wrangler dev`. Anbindung von KV/D1/R2 über `wrangler.toml`-Bindings. Edge Cases: Was liefert der Worker bei leerer Anfrage, bei extrem großer, bei kaputtem JSON? Deploy mit `wrangler deploy --env production`. **Tipp:** Für die Server-Seite eines Telegram-Bots reichen in 95 % der Fälle ein Worker + KV für den State. Kein Redis, kein PostgreSQL, kein Docker. Ein Bot mit 1.000 Nutzern pro Tag passt in den Free-Plan. Bei 10.000 zahlen Sie 5 $/Monat. ## 7 typische Fehler Diese Stolperfallen habe ich bei Kunden gesehen und selbst erlebt. 1. **State in einer globalen Variable speichern.** Workers sind stateless – jede Anfrage kann auf einem anderen Server landen. State gehört in KV/D1/Durable Objects, nicht in Variablen. 2. **Das CPU-Limit ignorieren.** 10ms im Free-Plan, 50ms im Paid-Plan. Aufwändige Kryptografie oder ein großes JSON.parse können scheitern. Profilieren Sie mit `wrangler dev --remote`. 3. **Wrangler Secrets nicht für Schlüssel nutzen.** Einen OpenAI-API-Key in den Code zu legen heißt: er landet in Git. Nutzen Sie `wrangler secret put` – der Schlüssel wird verschlüsselt bei Cloudflare gespeichert. 4. **Bei jeder Anfrage synchrone Operationen ausführen.** Jedes fetch zu einer externen API kostet Zeit. Cachen Sie wiederverwendete Daten in KV oder per Cache API. 5. **Origin-Header vergessen.** CORS blockiert Anfragen vom Frontend. Der Worker muss explizit `Access-Control-Allow-Origin` zurückgeben – sonst sieht der Nutzer die Antwort nicht. 6. **Deploy ohne Tests.** Der Worker geht sofort in Produktion. Legen Sie eine separate Umgebung für Staging an: `wrangler deploy --env staging`. 7. **Keine Analytics anschließen.** Cloudflare bietet kostenlose Workers Analytics – Anfragen, Fehler, Latenz nach Region. Ohne sie sehen Sie nicht, was passiert. ## Häufige Fragen Was sind Cloudflare Workers in einfachen Worten? Das ist Code, der auf Cloudflare-Servern weltweit ausgeführt wird, nahe am Nutzer. Sie schreiben eine JavaScript/TypeScript-Funktion, deployen sie, und sie läuft in über 330 Städten weltweit. Kein eigener Server, kein Docker, kein PM2 nötig. Kaltstart ist praktisch nicht vorhanden – Antwort in 5-50ms. Geeignet für APIs, Formulare, Telegram-Bots, Proxys, Authentifizierung, Bildverarbeitung. Was kostet Cloudflare Workers? Free-Plan: 100.000 Anfragen pro Tag kostenlos, bis zu 10ms CPU pro Anfrage. Das reicht für die meisten Projekte bis 100K Besuche pro Monat. Paid-Plan: 5 $ pro Monat für 10 Millionen Anfragen, bis zu 50ms CPU. Das ist um ein Vielfaches günstiger als AWS Lambda bei gleichem Volumen. Wie unterscheiden sich Workers von AWS Lambda? Lambda läuft in einer AWS-Region, Workers an über 330 Edge-Standorten. Lambda hat Kaltstarts von 200-2000ms, Workers unter 10ms. Lambda – Node.js/Python/Go/Java/Ruby, Workers – JavaScript/TypeScript/Rust/Python (via Pyodide). Für globale APIs und Webanwendungen sind Workers schneller und einfacher, für schwere Aufgaben (Videoverarbeitung, ML-Inference) ist Lambda flexibler. Kann man eine Datenbank an Workers anschließen? Ja. Cloudflare hat eigene Dienste: D1 (SQLite am Edge, 5 $/Monat für 10GB), KV (Key-Value, für Cache und Sessions), R2 (S3-kompatibler Speicher ohne Egress-Gebühren), Durable Objects (State-Konsistenz). Außerdem kann man externe DBs über Hyperdrive (beschleunigtes PostgreSQL) oder direkt über die Connection-API anbinden. Eignen sich Workers für einen Telegram-Bot? Ideal geeignet. Ein Telegram-Bot per Webhook ist ein HTTP-Endpoint, der Anfragen von der Telegram-API empfängt. Workers bewältigen diese Last selbst im Free-Plan bis zu 100K Nachrichten pro Tag. Den Session-State kann man in KV speichern (kostenlose 100K Reads/Tag), Integrationen mit CRM/OpenAI – über fetch zu deren APIs. Kein VPS nötig. --- --- title: "PageSpeed 100 von 100 in 2026: wie und warum" url: https://tema.name/de/blog/pagespeed-100-von-100-2026.html language: de description: "Wie man PageSpeed 100/100 erreicht: Core Web Vitals, LCP/INP/CLS, realistischer Wochen-Optimierungsplan, 7 Fehler und FAQ." date_published: 2026-05-29 date_modified: 2026-05-29 --- Performance / SEO 29. Mai 2026 · 11 Min. Lesezeit · Autor: Artem # PageSpeed 100 von 100 in 2026: wie und warum **PageSpeed 100/100 in 2026** = **LCP < 2,5 s** + **INP < 200 ms** + **CLS < 0,1**. So erreichbar: Critical CSS im Head inlinen (max. 14 KB), Rest per `defer` nachladen. Bilder in AVIF/WebP mit korrekten Größen und `loading="lazy"`. Fonts mit `font-display: swap` und Preload für den ersten Schnitt. JavaScript-Frameworks durch Vanilla ersetzen, wo möglich — das spart 100–300 KB. Server: Brotli, HTTP/2, Immutable-Cache 1 Jahr. In einem realen Joomla-Projekt steigt der Mobile-Score so in **5–7 Arbeitstagen** von **45 auf 90+**. Conversion-Effekt: jede zusätzliche Sekunde Ladezeit kostet **5–7 %** Conversion, **53 %** der Nutzer verlassen Seiten, die länger als 3 s laden. Ziel ist nicht 100/100 um jeden Preis, sondern die grüne Zone aller Core Web Vitals. Der Artikel zeigt den Schritt-für-Schritt-Plan und 7 typische Fehler. **Im Artikel** 1. [Warum die Website überhaupt beschleunigen](#why) 2. [Core Web Vitals: LCP, INP, CLS](#vitals) 3. [7 Hauptfaktoren der Geschwindigkeit](#factors) 4. [Optimierungsplan für eine Woche](#workflow) 5. [7 typische Fehler](#mistakes) 6. [Häufige Fragen](#faq) ## Warum die Website überhaupt beschleunigen Drei pragmatische Gründe – ohne Ideologie nach dem Motto „weil Google es so sagt". 90+ PageSpeed Mobile für ein normales Ranking -7% Conversion pro +1 Sekunde Ladezeit 2.5s maximales LCP für die grüne Zone 53% der Nutzer verlassen die Seite, wenn sie > 3 Sekunden lädt - **SEO-Faktor.** Google berücksichtigt Core Web Vitals seit 2021 als Ranking-Faktor. Bei wettbewerbsintensiven Keywords schlägt eine schnelle Website eine langsame, bei sonst gleichen Bedingungen. - **Conversion.** Jede zusätzliche Sekunde Ladezeit reduziert die Conversion um 5-7%. Im E-Commerce mehr. Direkte Geldverluste. - **Werbekosten.** Google Ads gewährt einen CPC-Rabatt für schnelle Landing-Pages und bestraft langsame umgekehrt. Das wirkt sich real auf das Budget aus. **Das Wichtigste:** das Ziel ist nicht „100/100", sondern „grüne Zone bei allen Core Web Vitals". 90+ Mobile in PageSpeed Insights ist bereits ein hervorragendes Ergebnis und liefert das Maximum dessen, was Google im Ranking berücksichtigt. ## Core Web Vitals: LCP, INP, CLS Das sind drei Metriken, die Google über Chrome (CrUX-Daten) bei echten Nutzern misst. Seit 2021 sind sie Teil des Ranking-Algorithmus. ### LCP (Largest Contentful Paint) Wie schnell das größte Element im sichtbaren Bereich erscheint – meist das Hauptbild oder eine große Überschrift. **Gut: < 2.5s.** Schlecht: > 4s. Die Hauptursachen für schlechtes LCP: schwere Hero-Bilder ohne `fetchpriority="high"`, fehlendes `preload`, langsamer Server (TTFB), blockierende Scripts im head. ### INP (Interaction to Next Paint) Ersetzte 2024 den FID. Misst, wie schnell die Seite auf Klick/Tap/Tastendruck reagiert. **Gut: < 200ms.** Schlecht: > 500ms. Die Hauptursachen für schlechtes INP: schweres JS im Main Thread, synchrone Event-Handler, lange `setTimeout`-Ketten. Das ist das „moderne" Kopfweh: selbst wenn die Seite schnell geladen wurde, kann sie beim Klick „hängen bleiben" wegen schlechtem JS. ### CLS (Cumulative Layout Shift) Die Summe der „Sprünge" im Layout während des Ladens. Wenn ein Banner oben nachgeladen wird – und der gesamte Text nach unten rutscht = schlechter CLS. **Gut: < 0.1.** Schlecht: > 0.25. Die Hauptursachen: Bilder ohne angegebene width/height, Schriften, die ihre Größe beim Nachladen ändern, Werbeblöcke, dynamisch eingefügte Elemente. ## 7 Haupt-Geschwindigkeitsfaktoren Das ist eine Basis-Checkliste. In 90% der Fälle bringen genau diese Punkte 70-90% des PageSpeed-Zuwachses. - **Bilder in WebP/AVIF + Lazy Load.** 80% des „Gewichts" einer Seite sind Bilder. Die Konvertierung von PNG/JPG zu WebP bringt -40-60% Größe. AVIF ist noch besser, aber etwas schlechter unterstützt. - **Minifizierung und Kompression (Brotli).** CSS/JS müssen minifiziert sein. Der Server sollte mit Brotli ausliefern (oder zumindest gzip). Cloudflare macht das automatisch. - **Ungenutztes CSS/JS entfernen.** Jedes `bootstrap.css` oder `jquery.js`, das nicht zu mindestens 30% genutzt wird – entfernen. PurgeCSS + Tree-Shaking im Bundler. - **Schriften mit font-display: swap.** Ohne das sieht der Nutzer einen weißen Bildschirm, während die Schrift 1-2 Sekunden lädt. Mit swap – zuerst die Systemschrift, dann wird sie ausgetauscht. - **Preload des Haupt-Hero-Bildes + preconnect zum CDN.** `` reduziert das LCP um 0.5-1.5 Sekunden. - **CDN (Cloudflare).** Wenn die Website in Russland gehostet wird und Kunden aus der EU kommen – ohne CDN lädt die Seite 3-5 Sekunden nur wegen der Geografie. Cloudflare löst dieses Problem kostenlos. - **HTTP/2 oder HTTP/3.** Modernes Protokoll mit Multiplexing. Wird mit einem Klick beim Hosting oder in Cloudflare aktiviert. Ohne das lädt der Browser Dateien sequenziell statt parallel. **80/20-Regel:** WebP-Bilder + Brotli-Kompression + Hero-Preload + Cloudflare CDN bringen 80% des Ergebnisses mit 20% Aufwand. Beginnen Sie mit diesen vier. Danach kommen punktuelle Optimierungen. ## Optimierungs-plan für eine Woche Realistischer Zeitplan, um eine Website von 40-50 Punkten Mobile auf 90+ zu beschleunigen: 1. AuditTag 1 2. BilderTag 2-3 3. CSS/JSTag 4 4. CDN/HTTPTag 5 5. FinishTag 6-7 **Tag 1 – Audit.** Durchlauf durch [PageSpeed Insights](https://pagespeed.web.dev) + Lighthouse in den DevTools. Sie notieren die aktuellen LCP/INP/CLS, TBT, Seitengröße. Das ist die Ausgangsbasis für Messungen. Parallel – WebPageTest für die Waterfall-Analyse. **Tag 2-3 – Bilder.** Alle JPG/PNG werden in WebP konvertiert (massenweise über `cwebp` CLI oder Squoosh.app). `width`/`height`-Attribute zu allen `![]()` hinzufügen (gegen CLS). Hero-Bild – mit `fetchpriority="high"` und preload im ``. Die übrigen – `loading="lazy"`. **Tag 4 – CSS/JS.** Minifizierung (falls noch nicht erfolgt). Entfernung von ungenutztem CSS via PurgeCSS. Scripts, die im First-Screen nicht benötigt werden – mit `defer`. Analytics und Counter – asynchron oder nach `DOMContentLoaded`. **Tag 5 – CDN und HTTP/3.** Sie verbinden Cloudflare (falls noch nicht vorhanden) – kostenlos, 5 Minuten. Sie aktivieren Brotli, HTTP/3, Auto Minify, Rocket Loader (vorsichtig – kann JS brechen). Sie richten Cache-Regeln für statische Inhalte ein (1 Jahr für Assets mit Hash im Namen). **Tag 6-7 – Finish.** Wiederholter PageSpeed-Durchlauf. Punktuelle Korrekturen verbleibender Probleme: Third-Party-Scripts in iframe, Schriften mit font-display, Entfernung unnötiger preconnects. Finale Messung. Wenn 90+ Mobile – Ziel erreicht. ## 7 typische Fehler Diese Fehler sehe ich regelmäßig – bei Kunden, die vorher mit anderen Dienstleistern gearbeitet haben oder es selbst versucht haben. 1. **Desktop optimieren, Mobile vergessen.** Mobile-First-Indexing seit 2019. Google rankt auf Basis der mobilen Version. Desktop 95 + Mobile 45 = wird wie 45 gerankt. 2. **Nur in Lighthouse testen, keine Field-Data anschauen.** Lighthouse sind Labordaten. Die Search Console zeigt echte CWV bei echten Nutzern. Sie können sich unterscheiden. 3. **„Das WP-Optimize-Plugin hilft, installieren wir".** Optimierungs-Plugins kollidieren oft, machen Unvorhersehbares. Besser ein gut konfiguriertes als drei, die sich gegenseitig „helfen". 4. **Lazy Load auf Hero-Bilder.** Der größte Fehler. Lazy Load für ein Bild above the fold = LCP-Erhöhung. Lazy Load – nur für Bilder unterhalb des First Screens. 5. **Schwere Schriften ohne preload und font-display.** Schrift mit Gewicht 800 und Unterstützung für 5 Sprachen = 200KB. Ohne font-display: swap – weißer Bildschirm 1-2 Sekunden. Mit preload – LCP verkürzt sich. 6. **Third-Party-Scripts im head.** Yandex.Metrika + Google Analytics + Facebook Pixel + Hotjar + ... synchron im head – TBT (Total Blocking Time) rutscht in die rote Zone. Verschieben in den Footer oder asynchron. 7. **Server-Side-Performance ignorieren.** TTFB (Time to First Byte) – oft ein serverseitiges Problem: langsames PHP, nicht optimierte SQL-Abfragen, fehlendes Server-Caching. Nur die Client-Optimierung hilft nicht, wenn der Server selbst 2 Sekunden braucht, um zu antworten. **Gutes Zeichen, dass die Optimierung wirkt:** nach 28 Tagen wechselt die Search Console im Bereich Core Web Vitals die Seiten von „Poor" / „Needs improvement" auf „Good". Nicht sofort – CrUX-Daten werden über ein 28-Tage-Rolling-Window gesammelt. ## Häufige Fragen Warum sollte man PageSpeed 100/100 anstreben? Es ist nicht zwingend nötig, 100/100 um jeden Preis zu erreichen. Ein Wert über 90 (Mobile) bringt bereits das Maximum dessen, was Google im Ranking berücksichtigt. 95-100 ist eher eine Frage des Prestiges und guter Core Web Vitals in der Search Console. Das eigentliche Ziel ist die grüne Zone: LCP < 2.5s, INP < 200ms, CLS < 0.1. Genau das berücksichtigt Google seit 2021 als Ranking-Faktor. Was sind Core Web Vitals in einfachen Worten? Drei Metriken, die Google bei echten Nutzern misst: LCP (Largest Contentful Paint) – wie schnell der Hauptinhalt erscheint, INP (Interaction to Next Paint) – wie schnell die Seite auf Klicks/Taps reagiert, CLS (Cumulative Layout Shift) – ob das Layout während des Ladens springt. Seit 2024 hat INP den FID ersetzt. Ist Mobile oder Desktop wichtiger? Mobile. Google verwendet Mobile-First-Indexing – das Ranking basiert auf der mobilen Version. Mobile PageSpeed sollte über 80 liegen, idealerweise über 90. Desktop folgt meist von selbst, wenn die mobile Version optimiert ist. Wie lange dauert die Optimierung auf 90+? Hängt vom Ausgangspunkt und Stack ab. Statische Landing-Page: 1-3 Tage. Unternehmens-Website auf Joomla/WordPress: 1-2 Wochen. Online-Shop mit komplexer Logik: 2-4 Wochen. Wenn man bei 30-40 Punkten Mobile startet – ein Monat ist realistisch. Bei 60-70 – eine Woche. Beeinflusst PageSpeed die Conversion? Direkt. Laut Daten von Google und Amazon: +1 Sekunde Ladezeit = -7% Conversion im E-Commerce. Bei Landing-Pages weniger: +1s = -3-5%. Außerdem erhalten langsame Websites weniger Wiederholungsbesuche: Nutzer merken sich, dass die Seite langsam lädt und kommen nicht zurück. --- --- title: "Headless CMS vs traditionelles CMS 2026: Was wählen" url: https://tema.name/de/blog/headless-vs-traditionelles-cms-2026.html language: de description: "Headless CMS vs traditionelles CMS 2026: Unterschiede, Anwendungsfälle. Strapi/Sanity/Contentful vs Joomla/WordPress, Fehler, FAQ." date_published: 2026-05-30 date_modified: 2026-05-30 --- Stack-Auswahl 30. Mai 2026 · 11 Min. Lesezeit · Autor: Artem # Headless CMS vs traditionelles CMS 2026: Was wählen Die Wahl ist pragmatisch: **klassisches CMS (Joomla 5 / WordPress)** deckt **rund 80 %** aller Business-Aufgaben ab — Landingpages, Firmen-Sites, Blogs, Kataloge und Shops bis **5 000 SKU**. Time-to-Launch: **2–4 Wochen**, Kosten 1× Basis. **Headless (Strapi, Sanity, Contentful)** lohnt sich, wenn Sie mehrere Frontend-Kanäle bedienen (Web + Mobile + Kiosk), ein Team ab 3 Entwicklern haben und ein **2–3× höheres Budget** mitbringen. Migration dauert **3–6 Wochen**, dafür **PageSpeed Mobile 95 +** aus der Box und volle Frontend-Freiheit. Anteil von Headless an allen CMS-Websites in 2026: **etwa 5 %** — die brauchen es wirklich, der Rest hört nur den Hype. Der Artikel zeigt den detaillierten Stack-Vergleich, den Strapi-/Sanity-/Contentful-Showdown und 7 typische Migrations-Fehler. **Im Artikel** 1. [Was ist ein Headless CMS](#what-is) 2. [Stack und Architektur – Vergleich](#stack) 3. [Für wen welcher Ansatz geeignet ist](#use-cases) 4. [Strapi vs Sanity vs Contentful](#tools) 5. [7 typische Fehler](#mistakes) 6. [Häufige Fragen](#faq) ## Was ist ein Headless CMS Ein traditionelles CMS (Joomla, WordPress, Drupal) besteht aus drei fest miteinander verbundenen Schichten: dem **Admin-Bereich**, in dem Redakteure Inhalte schreiben, der **Datenbank**, in der diese gespeichert werden, und dem **Theme (Template)**, das die Seiten rendert. Sie ändern das Template – Sie ändern das Design. Sie ändern das CMS – Sie ändern alles. ~5% Anteil von Headless an allen CMS-Websites in 2026 3-6Wo. Migrationsdauer von traditionellem CMS zu Headless 95+ typischer PageSpeed Mobile bei Jamstack-Sites 2-3× höhere Entwicklungskosten Headless vs traditionelles CMS Bei einem **Headless CMS** bleiben nur der Admin-Bereich und die Datenbank. Das Frontend gehört Ihnen, in einer beliebigen Technologie. Das CMS liefert Inhalte über eine REST- oder GraphQL-API. Der Frontend-Entwickler nimmt die API und gestaltet die Seiten beliebig. Einfache Analogie: Ein traditionelles CMS ist ein Auto mit fertiger Karosserie. Headless ist ein Chassis mit Motor, die Karosserie bauen Sie selbst nach Ihren Anforderungen. Mehr Flexibilität, aber auch mehr Arbeit. ## Stack und Architektur – Vergleich | Parameter | Traditionelles CMS (Joomla, WP) | Headless CMS | | --- | --- | --- | | Was ist enthalten | Admin + DB + Frontend-Themes | Admin + DB + API. Frontend separat. | | Wer rendert die Seiten | CMS-Theme (PHP-Templates) | Beliebiges Frontend: React, Vue, Astro, Next.js | | Wer wird im Team benötigt | 1 Fullstack-Entwickler | Frontend-Entwickler + Backend (oder 1 Fullstack) | | Ladegeschwindigkeit | 60–85 PageSpeed Mobile ab Werk | 95–100 (statisches Rendering) | | SEO | Ab Werk, Plugins | Manuell, aber mehr Kontrolle | | Multi-Channel | Nur Web | Web + Mobile + digitale Schaufenster + E-Mail | | Entwicklungskosten | Basis (1×) | 2–3× Basis | | Wartungskosten | Plugin-Updates | Frontend-Updates + CMS separat | | Lernkurve für Redakteure | Einfach, gewohnt | Ähnlich, aber „losgelöst" vom Endergebnis | **Das Wichtigste:** Headless ist keine „Verbesserung" eines traditionellen CMS, sondern eine andere Architektur mit anderen Kompromissen. Sie gewinnen an Flexibilität und Geschwindigkeit – Sie verlieren an Wartungseinfachheit und zahlen mehr für die Entwicklung. ## Für wen welcher Ansatz geeignet ist ### Wann ein traditionelles CMS wählen (Joomla, WordPress) - **Unternehmenswebsite mit 10–50 Seiten.** Team von 1–3 Redakteuren, einmalige Entwicklung, minimale Anpassung. Joomla oder WordPress deckt 95 % der Anforderungen ab. - **Blog oder Medien.** WordPress ist der De-facto-Standard für Content-Projekte. Riesiges Ökosystem, komfortabler Editor für Nicht-Techniker. - **Kleiner E-Commerce.** WooCommerce (WP) oder VirtueMart/HikaShop (Joomla) funktionieren gut bis zu 5000 SKU. - **Kleines lokales Team.** Wenn Sie keinen Frontend-Entwickler haben und auch keinen einstellen wollen – das traditionelle CMS gewinnt. - **Schneller Start mit festem Budget.** Eine Landingpage aus fertigen Themes + Plugins in 1–2 Wochen zu starten – ist mit einem traditionellen CMS einfacher. ### Wann Headless gerechtfertigt ist - **Mehrere Konsumkanäle.** Content geht an Website + iOS-App + Android-App + digitale Anzeigetafeln in Filialen + E-Mail-Newsletter. Eine Quelle der Wahrheit über die API. - **Das Team arbeitet bereits mit React/Vue/Next.** Warum ein neues CMS-Theme lernen, wenn der Frontend-Entwickler über Next.js oder Astro rendern kann? - **Performance-kritische Websites.** Wenn jede 0,1 Sekunde Ladezeit Millionen Euro Umsatz bedeutet (großer E-Commerce, Werbung mit hohem CPC). - **Komplexe UI-Anpassung.** Wenn Standard-Themes nicht reichen, interaktive Dashboards, individuelle Widgets, Echtzeitdaten benötigt werden. - **Team aus 5+ Redakteuren mit verschiedenen Rollen.** Gute Headless CMS haben ein flexibles Rechtesystem, mehrstufige Workflows und Versionierung. **Nicht „Headless" und „Jamstack" verwechseln:** Headless ist eine CMS-Architektur (ohne eigenes Frontend). Jamstack ist ein Deployment-Ansatz: Statik + JS + API. Man kann Headless ohne Jamstack sein (Server-Rendering via SSR) und Jamstack ohne Headless (Statik ohne CMS überhaupt). ## Strapi vs Sanity vs Contentful Die drei beliebtesten Headless CMS auf dem Markt. Wie sie sich unterscheiden. | Parameter | Strapi | Sanity | Contentful | | --- | --- | --- | --- | | Hosting | Self-hosted (Docker, VPS) | Managed (Cloud) | Managed (Cloud) | | Open Source | Ja, MIT-Lizenz | Studio – Open Source, Backend – nein | Nein | | Preis (kostenlos) | Kostenlos (nur Hosting) | Bis 10K Dok., 100K Anfragen/Mon. | Bis 50K Einträge | | Preis (kostenpflichtig) | ~60–200 USD/Mon. (Cloud) | 99–1000+ USD/Mon. | 300+ USD/Mon. | | Editor | Solide, gut | Sehr anpassbar (Studio) | Ausgereift, für Teams | | API | REST + GraphQL | GROQ + GraphQL | REST + GraphQL | | Für wen geeignet | Teams mit DevOps, Kontrolle | Start-ups, Flexibilität, schneller Start | Enterprise, große Teams | Meine Empfehlungen nach Szenarien: - **MVP oder Prototyp, begrenztes Budget.** Sanity Free Tier. Start in 2–3 Tagen, Editor-Schemata im Code, kostenlos lange genug. - **Unternehmensprojekt, Flexibilität + Kontrolle.** Strapi self-hosted auf eigenem VPS oder Strapi Cloud. Volle Kontrolle über die Daten. - **Enterprise mit Team und Compliance.** Contentful. SLA, Support, Sicherheit ab Werk, fertige Integration mit Marketingplattformen. ## 7 typische Fehler 1. **Headless wählen, „weil es modern ist".** Wenn Sie 5 Redakteure und eine Website haben – ist ein traditionelles CMS meist günstiger. Headless ist architektonisch begründet, nicht „weil es auf Twitter gelobt wird". 2. **Kosten der Frontend-Entwicklung unterschätzen.** Headless CMS sind nur 30 % des Systems. 70 % sind die Frontend-Anwendung. Das Budget für den Frontend-Entwickler und dessen Wartung ist oft höher als für das CMS selbst. 3. **Preview vergessen.** Der Redakteur möchte sehen, wie ein Beitrag aussehen wird. Bei einem traditionellen CMS ist das „standardmäßig" vorhanden. Bei Headless muss Preview separat gebaut werden (Next.js Preview Mode, Sanity Visual Editing). 4. **i18n von Anfang an ignorieren.** Wenn später Mehrsprachigkeit benötigt wird, ist die Migration schwieriger. Planen Sie die Unterstützung von der Architektur aus ein – über Locale in den Schemata. 5. **API-Caching nicht konfigurieren.** Jede Anfrage an die Headless-API ist eine HTTP-Anfrage. Bei Spitzenlasten ohne CDN-Cache fällt die API aus. Cloudflare R2 / Vercel ISR / Astro Static – Lösung. 6. **Headless für ein Team ohne Frontend-Entwickler verwenden.** Wenn Sie keinen festen Frontend-Entwickler haben – wer aktualisiert in 6 Monaten Next.js und React? Das CMS wird zum „herumhängenden Projekt". 7. **Sofort den Enterprise-Tier wählen.** Contentful Pro für 300 USD/Monat ist überflüssig für ein Projekt mit 1000 Seiten. Beginnen Sie mit Free/Starter und wechseln Sie mit dem Wachstum. **Zwischenvariante:** „WordPress als Headless". WordPress bleibt als CMS bestehen (gewohnter Editor für das Team), aber das Frontend wird über die WP REST API / WPGraphQL mit Next.js oder Astro gebaut. Sie erhalten 80 % der Jamstack-Vorteile ohne die Schmerzen einer Migration. Guter Kompromiss für Blogs und Medienseiten. ## Häufige Fragen Was ist ein Headless CMS einfach erklärt? Es ist ein CMS, das nur ein Backend hat (Admin-Bereich + API), während Sie das Frontend selbst erstellen – mit einem beliebigen Framework (React, Vue, Astro, Next.js). Bei einem traditionellen CMS wie Joomla oder WordPress sind Admin-Bereich und Frontend fest verbunden. Bei Headless erhalten Sie Inhalte über REST oder GraphQL und rendern sie nach Belieben. Vorteil: Flexibilität, Geschwindigkeit, Multi-Channel. Nachteil: Sie benötigen einen Frontend-Entwickler. Wann ist Headless besser als ein traditionelles CMS? Wenn Sie mehrere Kanäle zur Content-Nutzung haben (Website + mobile App + digitale Schaufenster + E-Mail), wenn maximale Geschwindigkeit benötigt wird (Jamstack-Ansatz), wenn das Team mit modernen Frontend-Frameworks arbeitet oder wenn eine feinkörnige UI-Anpassung ohne CMS-Theme-Beschränkungen erforderlich ist. Für eine typische Unternehmenswebsite oder einen Blog reicht ein traditionelles CMS meistens aus. Wie viel kostet ein Headless CMS? Hängt von der Wahl ab. Strapi self-hosted – kostenlos (nur Hosting). Sanity Free Tier – bis zu 10K Dokumente und 100K API-Anfragen pro Monat kostenlos. Contentful Free – bis zu 50K Einträge. Kostenpflichtige Pläne von Sanity/Contentful: 99–300 USD/Monat. Joomla/WordPress – 0 USD (nur Hosting). Headless ist in der Regel teurer, da sowohl ein Frontend-Entwickler als auch ein CMS-Service erforderlich sind. Strapi vs Sanity vs Contentful – was ist besser? Strapi – self-hosted, Open Source, maximale Kontrolle, ideal für Teams mit DevOps. Sanity – managed, flexible Datenschemata, hervorragender Editor (Sanity Studio). Contentful – die ausgereifteste Enterprise-Variante, mehr Plugins und Integrationen, aber teurer. Für Prototypen und Start-ups – Sanity. Für Großunternehmen – Contentful. Für alle, die alles selbst hosten möchten – Strapi. Kann man von WordPress zu Headless migrieren? Ja. Sie können WordPress als Headless beibehalten – es hat eine REST-API und das WPGraphQL-Plugin. Das bietet eine Übergangsvariante: Das Team arbeitet weiter im WP-Admin, während das Frontend mit Next.js oder Astro gebaut wird. Das ist oft der optimale Migrationspfad – Prozesse nicht stören, aber Jamstack-Performance erreichen. Migrationszeit – 3 bis 6 Wochen, abhängig vom Umfang. --- --- title: "Jak zamówić stronę z AI w 2026 – Artem" url: https://tema.name/pl/blog/jak-zamowic-strone-z-ai-2026.html language: pl description: "Czym produkcja z AI różni się od klasycznej, realne terminy dla landinga i strony firmowej, jak kształtuje się cena. Praktyka, bez ozdobników." date_published: 2026-05-21 date_modified: 2026-05-22 --- Produkcja z AI 21 maja 2026 · 8 min czytania · Autor: Artem # Jak zamówić stronę z AI w 2026: podejście, termin, cena Strona z AI w 2026 zajmuje **2–4 tygodnie** i kosztuje **3 000–12 000 zł** — to 30–50% mniej niż w 2023, ale tylko gdy wykonawca rzeczywiście używa Claude/Cursor/ChatGPT, a nie tylko o nich mówi. Realny zysk z AI: szybsze prototypy (1–2 dni zamiast tygodnia), tańsze CMS-y na bazie Joomla/WordPress, krytyczny CSS i SEO-szablony generowane od ręki, integracja botów Telegram i RAG bez dodatkowego programisty. Co AI *nie* zrobi za Ciebie: nie wymyśli pozycjonowania marki, nie napisze briefu i nie zastąpi testów na realnych użytkownikach. W artykule — etapy zamówienia, na co patrzeć w wycenie i 7 błędów, przez które klient płaci 2× za ten sam wynik. **W artykule** 1. [Co zmieniło się w produkcji stron w 2026](#what-changed) 2. [Rodzaje stron – i którą potrzebujesz](#types) 3. [Realne terminy produkcji](#timeline) 4. [Jak kształtuje się cena i co na nią wpływa](#price) 5. [Co musi być w gotowej stronie](#whats-inside) 6. [Jak wybrać wykonawcę i się nie naciąć](#choose) 7. [Częste pytania](#faq) ## Co zmieniło się w produkcji stron w 2026 Główna różnica względem produkcji z lat 2020. to **AI-pair programming**. Programista nie pisze kodu od zera linijka po linijce. Pracuje w tandemie z modelem (Claude, Cursor, ChatGPT): opisuje zadanie naturalnym językiem, AI generuje strukturę, znaczniki, skrypty, a nawet wstępny content. Programista czyta każdy blok, sprawdza logikę, testuje, debuguje i składa produkt finalny. Nie oznacza to, że «programiści przestali być potrzebni». Przeciwnie – ich rola staje się bardziej ekspercka: muszą umieć poprawnie zbriefować AI, ocenić jakość wyniku, zobaczyć gdzie AI się pomyliło i doprowadzić projekt do stanu działającego. Bez tej warstwy strona wychodzi albo niedziałająca, albo ładna-ale-nielogiczna. **Główna myśl:** AI przyspiesza produkcję 3-5x, ale nie eliminuje potrzeby wykonawcy odpowiedzialnego za rezultat. Pytanie nie brzmi «człowiek czy AI», ale «kto robi finalne QA i bierze odpowiedzialność». Dla klienta oznacza to trzy praktyczne zmiany. **Po pierwsze** – terminy drastycznie się skróciły. Landing page, na którą agencja potrzebowała 1,5 miesiąca, u freelancera korzystającego z AI powstaje w 1-2 tygodnie. **Po drugie** – ceny spadły. Ta sama praca kosztuje 3-5x mniej, bo nie trzeba utrzymywać zespołu 4-6 osób. **Po trzecie** – komunikacja stała się prostsza. Rozmawiasz bezpośrednio z wykonawcą, bez project managerów i tygodniowych akceptacji. ## Rodzaje stron – i którą potrzebujesz Przed zamówieniem ważne jest, by zrozumieć format, który rzeczywiście rozwiązuje Twój problem. Nadmiarowa funkcjonalność to dodatkowe pieniądze i czas. Niewystarczająca – zmarnowany budżet. ### Landing page (strona jednoekranowa) Kiedy pasuje: jedna usługa lub jeden produkt, celem jest lead. Na przykład remont mieszkań, dowóz lunchów, prywatna praktyka stomatologiczna. Na landingu cała uwaga skupia się na ofercie i formularzu lead. ### Strona firmowa (6-15 podstron) Kiedy pasuje: kilka kierunków biznesu, trzeba szczegółowo opisać każdą usługę osobno, dodać zespół, case study, kontakty, sekcję «O nas». Na przykład agencja digital, kancelaria prawna, klinika medyczna. ### Strona contentowa z blogiem Kiedy pasuje: stawiasz na SEO i chcesz regularnie publikować artykuły, ściągając ruch z wyszukiwarki. Na przykład szkoła online, blog ekspercki, magazyn niszowy. Potrzebny CMS – najczęściej Joomla lub WordPress. ### Sklep internetowy Kiedy pasuje: sprzedajesz produkty online – potrzebny katalog z filtrami, koszyk, płatności, konto klienta. W Joomli rozwiązuje to komponent VirtueMart lub HikaShop. Dla bardzo dużych sklepów (dziesiątki tysięcy SKU) często lepsze są platformy wyspecjalizowane. **Wskazówka:** nie próbuj zamówić «wszystkiego naraz». Zacznij od landinga lub mini-strony, obserwuj realny popyt, potem rozszerzaj. To oszczędza budżet i eliminuje ryzyko projektowania czegoś, co nie będzie potrzebne. ## Realne terminy produkcji W 2026 z produkcją AI realne terminy wyglądają tak: - **Landing page:** 1-2 tygodnie od briefu do startu - **Strona firmowa (6-15 podstron):** 2-4 tygodnie - **Strona contentowa z blogiem:** od 3 tygodni - **Katalog z leadami (bez płatności):** 3-5 tygodni - **Pełny sklep internetowy:** 4-8 tygodni - **Bot Telegram do leadów:** 3-5 dni 1. Briefdzień 1 2. Prototypdzień 3 3. Designdzień 5 4. Koddzień 7-10 5. Startdzień 14 Te terminy zakładają, że jesteś gotowy szybko akceptować rezultaty pośrednie. Jeśli każdy krok dostaje 5 dni odpowiedzi – projekt rozciąga się 2-3x. Więc omów z góry, jak często będą dema i jak szybko musisz decydować. Główne opóźnienie zwykle nie pochodzi od kodu, ale od **contentu**. Jeśli nie masz gotowych tekstów, zdjęć i opisów usług – wlicz czas na przygotowanie. Dobry wykonawca może pomóc z draftami tekstów przez AI, ale finalna akceptacja zostaje u Ciebie. ## Jak kształtuje się cena i co na nią wpływa Celowo nie podaję tu konkretnych liczb w euro czy dolarach – zbyt szybko się dezaktualizują i różnią regionalnie. Ale oto działająca formuła do orientowania się w dowolnych cenach: **Cena strony = (złożoność × objętość) − czynnik przyspieszenia AI + integracje** Na «złożoność» wpływa: unikalność designu (szablon vs custom), niestandardowa funkcjonalność (kalkulatory, obliczenia, konto klienta), obciążenie (10 wejść/dziennie vs 10 000). Na «objętość» wpływa: liczba podstron lub scenariuszy bota, ile tekstów do adaptacji, ile formularzy i integracji. Co dodają «integracje»: CRM (Bitrix24, AmoCRM, Pipedrive, HubSpot), systemy płatności, komunikatory, mailingi. Każda integracja to dodatkowa praca przy konfiguracji API i testach. **Czynnik AI**: jeśli wykonawca używa narzędzi AI, jego cena jest zwykle 3-5x niższa od cen agencji – przy tej samej jakości produktu końcowego. To nie jest «tanio», to inne podejście do procesu. **Czego NIE powinno być w wycenie:** «opłata za słowo w tekście», «doliczenie za wersję mobilną» (responsywny design to norma 2026, nie opcja), «stała opłata za każdą aktualizację contentu», «osobna opłata za znaczniki SEO». Jeśli to widzisz – to próba zawyżenia rachunku za podstawy. ## Co musi być w gotowej stronie To podstawowa checklista do weryfikacji produktu końcowego. Jeśli czegoś brakuje – strona nie jest oddana. - **HTTPS**: podłączony certyfikat SSL, strona działa przez https://. W 2026 Google karze strony bez tego. - **Responsywny design**: poprawne wyświetlanie na mobile, tablecie i desktopie. Rozmiar przycisków, czytelność czcionek, wygoda formularzy. - **Szybkość**: PageSpeed Insights – minimum 80 na mobile i 90+ na desktopie. Poniżej tego jest pole do optymalizacji. - **Znaczniki SEO**: title, description, nagłówki H1-H3, sitemap.xml, robots.txt, znaczniki Schema.org dla każdego typu strony, hreflang dla stron wielojęzycznych. - **Formularze z ochroną antyspam**: pole honeypot, rate-limit, filtr słów kluczowych. Leady przychodzą do Telegramu lub na email natychmiast. - **Podłączona analityka**: Yandex.Metrica z webvisorem, Google Search Console. Widzisz, skąd przychodzą klienci. - **Nagłówki bezpieczeństwa**: HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy. Ochrona przed typowymi atakami. - **Dokumentacja i dostępy**: dostajesz kod źródłowy, dostęp do hostingu/domeny/analityki. Krótka instrukcja aktualizacji contentu. ## Jak wybrać wykonawcę i się nie naciąć Najczęstszy błąd klienta to wybór po «portfolio» bez weryfikacji faktów. Ładne screeny można narysować – realna jakość widoczna jest tylko w żywych projektach. Pytaj przed zamówieniem: 1. **Pokaż 2-3 żywe projekty, nad którymi osobiście pracowałeś.** Nie «brałem udział» – zbudowałem i oddałem. 2. **Jakich technologii używasz i dlaczego akurat tych?** Jeśli odpowiedź brzmi «pracujemy z tym, co potrzebne» – zły znak. Dobry wykonawca ma konkretny stack. 3. **Kto osobiście będzie pracował nad moim projektem?** Jeśli to agencja, dowiedz się, czy projekt nie zostanie oddany freelancerowi za pół ceny. 4. **Co obejmuje gwarancja?** Standard 2026 – 30 dni małych poprawek gratis, potem godzinowo lub w abonamencie. 5. **Kto zachowuje dostępy?** Ty: hosting, domena, analityka, kod źródłowy. Jeśli wykonawca «trzyma stronę u siebie» – to forma trzymania w zakładnika. 6. **Używasz AI w pracy?** W 2026 to normalne pytanie. Jeśli wykonawca to ukrywa lub neguje – albo jest za rynkiem, albo boi się, że dowiesz się o AI i nie będziesz chciał płacić. **Czerwone flagi:** 100% przedpłaty przed startem prac, odmowa pokazania wyników pośrednich, mgliste terminy («jak pójdzie»), brak umowy lub pisemnego potwierdzenia zakresu/ceny, presja «decyduj dziś bo cena pójdzie w górę». ## Częste pytania Czy AI może samodzielnie zbudować stronę? Technicznie tak – można wygenerować całą stronę przez AI. Ale nie można jej oddać bez weryfikacji człowieka: AI popełnia błędy logiczne, czasem wymyśla nieistniejące metody i nie rozumie kontekstu biznesu. Prawidłowe podejście to AI jako akcelerator, człowiek jako kontrola jakości. Programista czyta każdy blok, testuje, debuguje i bierze odpowiedzialność za rezultat. Ile naprawdę kosztuje strona w 2026? Zależy od formatu i wykonawcy. Landing page u freelancera korzystającego z AI jest 3-5x tańszy niż klasyczna agencja. To samo dotyczy strony firmowej. Dokładna cena za Twój projekt jest kalkulowana po krótkim briefie. Liczy się nie sama cena, ale stosunek ceny do jakości oraz koszt dalszego wsparcia. Jaki jest realny termin landing page w 2026? Z narzędziami AI landing page pod klucz powstaje w 1-2 tygodnie: brief, prototyp, design, kod, formularze, analityka, start. Klasyczna agencja potrzebuje na to samo 4-6 tygodni – przez wielostopniowe wewnętrzne akceptacje. Co musi znaleźć się w gotowej stronie? Minimum: HTTPS, responsywny design, formularze z ochroną antyspam, analityka (Yandex.Metrica i Google Search Console), znaczniki SEO (title, description, sitemap.xml, robots.txt, Schema.org), szybkie ładowanie (PageSpeed 90+) i jasna instrukcja aktualizacji. Bez tego strona jest dekoracją, a nie narzędziem. Co sprawdzić wybierając wykonawcę? Pytaj: co zawiera oferta, jakie są terminy i czy zależą od Twojej gotowości contentu, kto osobiście pracuje nad projektem, jakie technologie są używane, czy jest wsparcie po przekazaniu, kto zachowuje dostępy do strony i analityki. Jeśli wykonawca unika odpowiedzi albo mówi «to nie Twoja sprawa» – szukaj innego. --- --- title: "Joomla vs WordPress vs statyczna 2026 – wybór stacku" url: https://tema.name/pl/blog/joomla-vs-wordpress-vs-statyczna-2026.html language: pl description: "Porównanie szybkości, bezpieczeństwa, elastyczności i kosztu utrzymania. 5 typowych scenariuszy i tabela decyzyjna do wyboru stacku." date_published: 2026-05-22 date_modified: 2026-05-22 --- Wybór stacku 22 maja 2026 · 10 min czytania · Autor: Artem # Joomla vs WordPress vs statyczna 2026: jaki stack wybrać Krótko: **WordPress** — gdy potrzebujesz dużo treści, bloga, sklepu i wtyczek do wszystkiego (ekosystem 60 000+ pluginów, ale 90% ataków na CMS-y celuje właśnie w WP). **Joomla** — gdy chcesz katalog B2B, witrynę firmową z wielojęzycznością z pudełka, sklep z HikaShop bez 5 dodatkowych wtyczek SEO. **Statyczna (Astro/Eleventy/Hugo)** — gdy liczy się szybkość 95–100 PageSpeed, koszt hostingu 0–20 zł/mies. i Ty *nie* będziesz edytować treści codziennie. Czas wdrożenia: WordPress 2–3 tygodnie, Joomla 2–4 tygodnie, statyczna 1–3 tygodnie, ale każda kolejna zmiana wymaga developera. Koszt bazowy: WP 3 000–8 000 zł, Joomla 4 000–10 000 zł, statyczna 2 000–6 000 zł plus 50–200 zł za każdą edycję. W artykule — porównanie po 8 kryteriach i scenariusze, w których każdy stack wygrywa. **W artykule** 1. [Krótka odpowiedź dla niecierpliwych](#tldr) 2. [Joomla – dla kogo i po co](#joomla) 3. [WordPress – dla kogo i po co](#wordpress) 4. [Statyczna – dla kogo i po co](#static) 5. [Porównanie po 7 parametrach](#compare) 6. [5 scenariuszy: co wybrać](#scenarios) 7. [Częste pytania](#faq) ## Krótka odpowiedź dla niecierpliwych Jednym akapitem: **landing page lub mini-strona z rzadkimi zmianami** – statyczna i koniec tematu. **Strona firmowa z kilkoma rolami redaktorów lub katalog z formularzem** – Joomla, zwłaszcza gdy ważne są czyste uprawnienia i wielojęzyczność. **Blog/medium z nowymi wpisami co 1-3 dni i pięcioma autorami** – WordPress, bo jego ekosystem motywów i wtyczek pod treści redakcyjne jest najbogatszy. **E-commerce** – zależy od rozmiaru: do 5 000 SKU spokojnie obsłuży VirtueMart/HikaShop w Joomli lub WooCommerce w WP; dziesiątki tysięcy SKU to już platformy wyspecjalizowane. **Kluczowa myśl:** «najlepszy CMS» nie istnieje. Istnieje «CMS dopasowany do zadania». Jeśli wykonawca twierdzi inaczej i ciągnie Cię na jeden stack niezależnie od projektu – to albo ograniczenie horyzontów, albo próba sprzedania Ci tego, co akurat umie. 40% stron na świecie działa na WordPressie ~1.5% udział Joomla – niszowo, ale stabilnie 96/100 średni PageSpeed dla statyki 3-5× przyspieszenie produkcji z narzędziami AI Szybkość ładowania (PageSpeed Mobile) Średnia ocena dla typowej instalacji bez premium-cachingu i CDN Statyczna96 Joomla 582 WordPress65 Liczby orientacyjne. Z agresywnym cachingiem i CDN WordPress podciąga do 80+, Joomla do 90+, ale «goła» instalacja zachowuje się właśnie tak. ## Joomla – dla kogo i po co Joomla 5 to dojrzały CMS na PHP 8.x. Według W3Techs napędza ok. 1,5-2% wszystkich CMS-stron na świecie – niszowo, ale stabilnie. W Europie kontynentalnej i regionie postsowieckim jej udział historycznie jest wyższy – wiele stron firmowych i instytucjonalnych działa właśnie na niej. **Plusy:** - **Wielojęzyczność out of the box** – nie trzeba płatnych wtyczek klasy WPML, żeby uruchomić stronę w 4 językach. - **Elastyczne ACL** – można dać redaktorowi dostęp tylko do jego sekcji, bez wchodzenia w cudze. - **Mniej «ogrodu wtyczek»** – ekosystem rozszerzeń jest mniejszy niż w WP, dzięki temu łatwiej wybrać jakościowe komponenty i mniejsze ryzyko porzuconych wtyczek. - **Mocny model komponentów** – VirtueMart do sklepu, HikaShop do katalogu, K2 do treści ze strukturą. Każdy komponent ma swój obszar. - **Mniejszy cel dla botów** – masowe ataki częściej celują w WordPressa, bo jest większy. **Minusy:** - Mniej gotowych motywów i komercyjnych szablonów na marketplace'ach. - Mniejszy pool specjalistów – znalezienie wykonawcy nie jest tak proste jak «WordPress na każdym rogu». - Przy stronach redakcyjnych z wieloma autorami ekosystem WP jest wygodniejszy. Pracuję z Joomlą od dawna i nadal wybieram ją do projektów, gdzie liczy się czysta architektura i wielojęzyczność. Pomaga AI-pair programming: szybkie dopracowanie szablonów, własne moduły, integracje z CRM. Więcej o tym – [w artykule o produkcji z AI w 2026](/pl/blog/jak-zamowic-strone-z-ai-2026.html). ## WordPress – dla kogo i po co WordPress to najpopularniejszy CMS na świecie, napędza około 40% wszystkich stron. To daje dwa efekty: ogromny ekosystem i ogromną powierzchnię ataku. **Plusy:** - **Gigantyczny ekosystem** – tysiące darmowych i komercyjnych motywów, wtyczki pod prawie każde zadanie. - **Wygodna edycja wizualna** (Gutenberg, Elementor) – redaktor nie musi znać HTML, by dodać nowy blok na stronę. - **Dostępność specjalistów** – znalezienie programisty WP jest łatwiejsze i tańsze niż Joomli. - **Pasuje do stron redakcyjnych** – role i workflow publikacji są przystosowane do wielu autorów. - **WooCommerce** – najpopularniejsze rozwiązanie e-commerce na WP, z masą gotowych integracji do płatności i wysyłki. **Minusy:** - **Wysoka podatność przy zaniedbaniu** – większość włamań to nieaktualizowane wtyczki. Każda instalacja WP zostawiona na rok bez ruchu jest celem. - **«Ogród wtyczek»** – 30+ wtyczek w jednej stronie oznacza konflikty, spowolnienia, duplikację funkcji. - **Płatne rozszerzenia** – wielojęzyczność (WPML), poważna ochrona formularzy, pakiety SEO «wszystko w jednym» to abonamenty, które się sumują. - **Wizualne kreatory rozdymają kod** – niezoptymalizowana strona na Elementorze łatwo ląduje na PageSpeed 30-40 na mobile. ## Statyczna – dla kogo i po co Strona statyczna to pliki HTML, CSS i JS – bez bazy danych i bez PHP. Serwer po prostu zwraca pliki. Nowoczesne generatory (Hugo, Eleventy, Astro, podejście Jamstack) pozwalają pisać w Markdown i kompilować stronę do folderu HTML, który potem wgrywa się na hosting lub CDN. **Plusy:** - **Maksymalna szybkość** – brak przetwarzania na serwerze, strona przychodzi gotowa. PageSpeed 95-100 to norma. - **Bezpieczeństwo** – nie ma czego hakować: brak admina, bazy, luk PHP. - **Minimalny hosting** – statyka hostuje się prawie za darmo (Netlify, Cloudflare Pages, GitHub Pages albo zwykły shared hosting). - **Brak aktualizacji core'u** – nie ma czego aktualizować. - **Idealna dla landingów i portfolio** – gdzie zmiany są rzadkie, a content prawie się nie rusza. **Minusy:** - **Brak panelu admina** – dodanie strony to edycja pliku albo commit git. Nie każdy klient to lubi. - **Dynamika osobno** – formularze, komentarze, wyszukiwarka, koszyk to zewnętrzne usługi lub API. - **Duże katalogi bolą** – generowanie 50 000 stron HTML zajmuje czas, pełne rebuildy mogą trwać minuty. - **Nie dla częstych nietechnicznych redaktorów** – pięciu autorów z równoległym dostępem «przez okienko» to już nie statyka. **Wariant pośredni:** «headless CMS + statyka». Content edytowany w panelu (Strapi, Sanity), strona kompilowana przy zmianie. Daje szybkość statyki i wygodę admina, ale dokłada komplikacji architektonicznej i kosztuje więcej niż czysta statyka. Nie każdy projekt to uzasadnia. ## Porównanie po 7 parametrach | Parametr | Joomla | WordPress | Statyczna | | --- | --- | --- | --- | | Szybkość ładowania | Średnia, dobra przy mało wtyczek | Średnia, wymaga cachingu | Maksymalna | | Bezpieczeństwo | Wysokie przy regularnych aktualizacjach | Wysokie przy aktualizacjach, ale większy cel | Maksymalne z architektury | | Wygoda edycji treści | Dobra, czysty panel admina | Świetna, wizualne kreatory | Tylko przez pliki lub git | | Wielojęzyczność | Wbudowana | Płatna wtyczka (WPML) | Zależy od implementacji | | Koszt utrzymania | Średni | Może być wysoki przez płatne wtyczki | Minimalny | | Katalog / e-commerce | VirtueMart, HikaShop | WooCommerce | Tylko zewnętrzne usługi | | Dostępność specjalistów | Średnia | Bardzo wysoka | Wysoka | ## 5 scenariuszy – co wybrać ### Scenariusz 1: landing pod jedną usługę Na przykład remonty mieszkań pod klucz albo prywatny dentysta. Jedna strona, formularz lead, analityka. Zmiany raz na kwartał. **Rekomendacja:** statyczna. Szybkość, bezpieczeństwo, minimalny hosting. CMS to tu armata na muchę. ### Scenariusz 2: strona firmowa z 10-30 podstron Kilka usług, zespół, case studies, kontakty, aktualności. Content aktualizowany co tydzień, potrzebna wielojęzyczność. **Rekomendacja:** Joomla. ACL pod różnych redaktorów, wielojęzyczność bez doplat, czyste zarządzanie menu i sekcjami. ### Scenariusz 3: blog redakcyjny z pięcioma autorami Projekt contentowy, artykuły co 1-3 dni, kilka kategorii, bloki reklamowe, subskrypcje. Wygodny edytor jest obowiązkowy. **Rekomendacja:** WordPress. Ekosystem, gotowe motywy redakcyjne, komfort dla osób nietechnicznych. ### Scenariusz 4: sklep internetowy do 5 000 SKU Katalog z filtrami, koszyk, płatności, konto klienta, promocje, wysyłka. **Rekomendacja:** Joomla z VirtueMart/HikaShop lub WordPress z WooCommerce. Wybór zależy od tego, czy potrzebujesz wielojęzyczności (Joomla wygrywa) czy ogromnego wyboru motywów (WP). Powyżej 10 000 SKU patrzyłbym na platformy wyspecjalizowane – Shopify, OpenCart albo custom. ### Scenariusz 5: katalog B2B z formularzem zapytania Lista usług lub produktów z opisami, filtrami, formularzami leadowymi. Bez zakupu online – klient zostawia zapytanie, kontaktuje się manager. **Rekomendacja:** Joomla z HikaShop w trybie «bez koszyka» albo statyczna z dynamicznymi formularzami. Pełny e-commerce jest tu zbędny. **Jeśli masz już stronę** i zastanawiasz się nad zmianą stacku – najpierw zdiagnozuj realny ból. Spowolnienia? Często do rozwiązania przez caching i optymalizację obrazków bez migracji. Włamania? Aktualizacje i audyt wtyczek. Niewygodny panel? Może źle skonfigurowane uprawnienia. Migracja to 2-4 tygodnie pracy plus ryzyko SEO. Najpierw diagnoza, potem zmiana platformy. ## Częste pytania Czy Joomla jest jeszcze aktualna w 2026? Tak. Joomla 5 to nowoczesny CMS na PHP 8.x z przemyślanym systemem uprawnień, wbudowaną wielojęzycznością i mniej agresywnym ekosystemem niż WordPress. Dobrze sprawdza się przy stronach firmowych, katalogach i sklepach internetowych (VirtueMart, HikaShop). Przy dużych projektach redakcyjnych z wieloma autorami częściej wybiera się WP – ale przy «kilka ról, czyste ACL, bez wielkiego page-buildera» Joomla często wygrywa. Co jest szybsze: strona statyczna, Joomla czy WordPress? Przy innych warunkach równych kolejność to: statyczna → Joomla → WordPress. Statyczna wygrywa, bo nie ma bazy danych ani przetwarzania PHP. Joomla jest zwykle szybsza od WordPressa dzięki czystszemu jądru i mniejszej liczbie wtyczek. WordPress można przyspieszyć cachingiem i CDN – wtedy różnica przy landingu przestaje być krytyczna. Na dużym katalogu znów się ujawnia. Czy można prowadzić bloga na stronie statycznej? Tak – przez generatory Jamstack (Hugo, Eleventy, Astro) lub ręcznie, jak ten blog. Zalety: szybkość, bezpieczeństwo, minimalny koszt hostingu. Wada: każdy nowy artykuł wymaga edycji plików lub commita git – nie każdy klient to lubi. Jeśli artykuły są rzadkie i pisze je jedna osoba, statyczna jest świetna. Jeśli pięciu autorów aktualizuje codziennie, potrzebny CMS. Który stack jest bezpieczniejszy? Statyczna jest architektonicznie bezpieczniejsza – prawie nie ma czego hakować: brak bazy, brak admina, brak PHP. Joomla i WordPress są bezpieczne pod warunkiem regularnych aktualizacji core'u i wtyczek. Większość włamań na CMS to nie luki w jądrze, a porzucone strony z wtyczkami sprzed 3 lat. Jeśli strona jest aktualizowana – oba warianty są niezawodne. Jestem już na WordPressie. Czy warto migrować? Tylko jeśli jest konkretny ból: spowolnienia przy typowym obciążeniu, ciągłe włamania z powodu ogrodu wtyczek, niewygodna wielojęzyczność. Sam fakt «WordPress jest passe» to nie powód. Migracja to 2-4 tygodnie pracy plus ryzyko SEO. Jeśli strona działa i przynosi leady, lepiej zainwestować w jej optymalizację niż w przeprowadzkę. --- --- title: "Boty Telegram dla biznesu 2026 – start w tydzień" url: https://tema.name/pl/blog/boty-telegram-dla-biznesu-2026.html language: pl description: "Jakie zadania realnie rozwiązują boty, typy botów, realistyczny 5-dniowy plan startu, czynniki ceny, częste błędy. Bez ozdobników." date_published: 2026-05-23 date_modified: 2026-05-23 --- Boty Telegram 23 maja 2026 · 10 min czytania · Autor: Artem # Boty Telegram dla biznesu 2026: od pomysłu do startu w tydzień Bot Telegram to praktyczne narzędzie, które zamyka 3 luki: **odpowiada klientom w 1–3 sekundy 24/7**, automatyzuje rutynę (zamówienia, FAQ, powiadomienia) i zbiera leady tam, gdzie użytkownik już jest — w aplikacji, w której spędza średnio 41 minut dziennie. Start MVP: **5–10 dni roboczych**, koszt 2 500–8 000 zł, utrzymanie 50–200 zł/mies. (serwer + ewentualne API). Realne zastosowania w 2026: bot-konsultant z bazą wiedzy (RAG na GPT-4o lub Claude), bot-zamawianie z integracją CRM, bot-powiadomienia dla zespołu, bot-quiz do generowania leadów. Co bot *nie* rozwiąże: braku produktu, słabego pozycjonowania, długich procesów płatności. W artykule — 7 scenariuszy biznesowych, ceny i typowe błędy. **W artykule** 1. [Po co biznesowi bot Telegram w 2026](#why) 2. [Typy botów z prawdziwymi przykładami](#types) 3. [Start w 5 dni: krok po kroku](#launch) 4. [Co wpływa na cenę](#price) 5. [7 typowych błędów](#mistakes) 6. [Częste pytania](#faq) ## Po co biznesowi bot Telegram w 2026 Krótko – bot zamyka trzy luki, których strona i email zamykają słabo: **szybkość reakcji, dostępność 24/7 i automatyzacja powtarzających się pytań**. Strona świetnie działa jako witryna i kanał SEO, email – do dokumentów i formalnej korespondencji. Ale w momencie, gdy klient potrzebuje odpowiedzi «teraz» – idzie do komunikatora. 900M+ aktywnych użytkowników Telegram na świecie (2026) 24/7 dostępność bota bez przerw i weekendów 3-5dn. typowy czas startu bota do leadów 70%+ oszczędność czasu na powtarzających się pytaniach Konkretne korzyści dla biznesu: - **Leady bez strat.** Zgłoszenie trafia natychmiast do czatu menedżera lub CRM. Nie ginie w mailu. - **Brak rejestracji.** Klient jest już zalogowany w Telegramie – nie musi przypominać hasła ani wypełniać formularza z 10 polami. - **Push w kieszeni.** Powiadomienia o statusie zgłoszenia, zmianie zamówienia, akcjach trafiają do messengera, który klient zawsze ma otwartego. - **Brak filtra spamu.** Wiadomości od bota nie trafiają do «Promocji» jak maile. - **Automatyzacja FAQ.** Bot zamyka 60-80% typowych pytań bez człowieka: ceny, terminy, kontakty, warunki dostawy. ## Typy botów — z prawdziwymi przykładami Nie wszystkie boty są równe. Od typu zależy scenariusz, termin i cena. Główne kategorie. ### 1. Lead-bot (zbieranie zgłoszeń) Najczęstsze zapytanie. Bot zadaje 3-7 pytań, zbiera kontakt i wysyła zgłoszenie na czat menedżera lub do CRM. Pasuje do usług, konsultacji, remontów, sprzedaży B2B. *Termin: 3-5 dni.* ### 2. FAQ / wsparcie Odpowiada na typowe pytania po menu lub przez klasyfikację tekstu AI. Trudne przypadki przekazuje żywemu operatorowi. Pasuje do szkół online, e-commerce, firm usługowych. *Termin: 1-2 tygodnie podstawowo, 2-4 tygodnie z wyszukiwaniem AI po bazie wiedzy.* ### 3. Bot-kalkulator / quiz Prowadzi klienta przez kilka kroków z wyborem opcji i na końcu daje rezultat: szacunek ceny, rekomendację, pasujący pakiet. Świetna alternatywa dla długiego formularza na stronie. *Termin: 1-2 tygodnie.* ### 4. Bot powiadomień Wysyła push o zdarzeniach w systemie: nowe zgłoszenie, zmiana statusu, przypomnienie o wizycie, info o dostawie. Często pracuje w parze z innymi botami. *Termin: 2-5 dni.* ### 5. Bot-katalog z zamówieniem Witryna wewnątrz Telegrama: kategorie, karty produktów, koszyk, składanie zamówienia. Pasuje do małych sklepów do 100-200 pozycji. Dla dużych katalogów lepsza dedykowana strona. *Termin: 2-4 tygodnie.* ### 6. Bot z AI (RAG, agenci) Bot, który odpowiada na swobodne pytania w oparciu o Twoją bazę wiedzy z pomocą AI: dokumenty, artykuły, instrukcje, case studies. Wykorzystuje Claude lub OpenAI plus bazę wektorową (Pinecone, Qdrant). Pasuje do złożonego wsparcia, szkoleń, wewnętrznych wiki. *Termin: 2-4 tygodnie.* **Nie próbuj zrobić «wszystko w jednym».** Większość firm dostaje 80% wartości z jednego prostego scenariusza. Bot, który sprzedaje, wspiera, prowadzi katalog i quiz naraz – zwykle wszystko robi źle. Zacznij od jednego, rozszerzaj wraz ze wzrostem. ## Start w 5 dni — krok po kroku Tak wygląda realistyczny harmonogram startu podstawowego bota do leadów z integracją CRM: 1. Briefdzień 1 2. Scenariuszdzień 2 3. Koddzień 3 4. Testydzień 4 5. Startdzień 5 **Dzień 1 – brief.** Określamy: co bot ma robić, jakie pytania zadawać, gdzie wysyłać dane, jak obsługiwać wiadomości poza scenariuszem. Wynik – jednostronicowe TŚP. **Dzień 2 – scenariusz.** Spisujemy wszystkie gałęzie dialogu: co bot mówi, jakie przyciski pokazuje, jak reaguje na odpowiedzi. Uzgadniamy z Tobą jako blok-diagram lub tabelę. To najważniejszy dzień – tu zakładana jest wygoda. **Dzień 3 – kod.** Piszę bota przez Telegram Bot API. Integracje: wysyłka zgłoszeń do odpowiedniego czatu, Google Sheets lub CRM (Bitrix24, AmoCRM, Pipedrive, HubSpot). Obsługa błędów i logowanie. **Dzień 4 – testy.** Sam przechodzę bota po każdej gałęzi, łapię edge-case (puste wiadomości, długie teksty, emoji, kliki poza przyciskami). Ty testujesz równolegle ze swojej strony. Naprawiamy to, co niewygodne. **Dzień 5 – start.** Bot wdraża się na Twój serwer lub mój VPS. Podpinam monitoring. Krótka instrukcja dla administratora: jak oglądać zgłoszenia, co robić przy awarii, jak zmieniać teksty. Token i wszystkie dostępy przechodzą do Ciebie. **Ważne o dostępach.** Token bota (od @BotFather) i wszystkie klucze API integracji muszą zostać u Ciebie. To Twój aktyw. Jeśli wykonawca «trzyma token u siebie» – to forma uzależnienia. Solidny wykonawca od razu przekazuje wszystko klientowi. ## Co wpływa na cenę Konkretnych liczb w euro czy złotówkach nie podaję – szybko się dezaktualizują i mocno zależą od regionu. Zamiast tego daję działający wzór, by ocenić każdą ofertę: **Cena bota = (złożoność scenariusza × liczba gałęzi) + integracje + logika AI − czynnik przyspieszenia AI** **Złożoność scenariusza:** ile kroków dialogu, czy są rozgałęzienia, czy potrzebne kroki wstecz. Liniowe scenariusze (ankieta, formularz lead) są proste. Bot z dynamicznym menu w zależności od poprzednich odpowiedzi – trudniejszy. **Liczba gałęzi:** 3-5 gałęzi – baza. 10-20 – średni. 50+ – to już osobny produkt, wymaga dłuższego projektowania. **Integracje:** CRM, system płatności, baza klientów, rozsyłki, zewnętrzne API. Każda integracja to oddzielna konfiguracja i testy. **Logika AI:** jeśli bot ma odpowiadać na swobodne pytania z AI – dochodzi praca nad promptami, kontekstem, bazą wektorową, obsługą błędów modelu. **Czynnik produkcji z AI:** Pracuję z AI-pair programming (Claude, Cursor), kod powstaje szybciej. To obniża finalną cenę 2-3x wobec klasycznych agencji przy tej samej jakości. ## 7 typowych błędów Te grabie widzę regularnie – u klientów, którzy robili bota sami lub z poprzednim wykonawcą. Jeśli rozpoznajesz swoją sytuację, warto przerobić. 1. **Bot próbuje robić wszystko.** Jeden bot – jedno główne zadanie. Leady, wsparcie i katalog w jednym menu zwykle dają złożony, niewygodny, nielogiczny produkt. 2. **Brak fallbacku do człowieka.** Jeśli bot nie zrozumie – użytkownik musi mieć przycisk «kontakt z menedżerem» lub «zostaw wiadomość». Inaczej klient odchodzi. 3. **Za długi scenariusz.** 15 pytań w ankiecie to nie «głębokie zanurzenie», ale irytacja. Pytaj tylko o to, co potrzebne do pierwszego kontaktu. Szczegóły na rozmowie. 4. **Bot bez promocji.** Wystartowali i zapomnieli. Bot ma być na stronie głównej (widget lub link), w stopce maili, na wizytówkach, w kartach Google Maps. Inaczej zero ruchu wejściowego. 5. **Brak eksportu danych.** Zgłoszenia tylko w czacie – a jeśli czat zniknie albo menedżer się zwolni? Musi być Google Sheets, CRM lub przynajmniej regularny eksport. 6. **Brak analityki.** Ilu użytkowników kończy scenariusz? Gdzie najczęściej odpadają? Bez pomiarów nie ma jak poprawić. Minimum – liczniki eventów, ideał – BotFather analytics lub własne. 7. **Bot zapomniany po starcie.** Telegram Bot API się rozwija, dependencies wymagają aktualizacji, integracje z CRM czasem się psują. Bot bez utrzymania po 6-12 miesiącach zaczyna «glitchować». **Dobra zasada:** zaczynaj od najprostszej wersji (MVP), startuj, obserwuj analitykę i realne zachowanie klientów 2-4 tygodnie. Dopiero potem rozszerzaj. To 5-10x skuteczniejsze niż budowanie «idealnego bota» pół roku w próżni. ## Częste pytania Po co biznesowi bot Telegram, skoro jest już strona i email? Bot nie zastępuje strony – pracuje obok. Strona odpowiada za SEO, informację i zaufanie. Bot zamyka to, co strona robi słabo: natychmiastowa odpowiedź 24/7, proste scenariusze w czacie, push o statusie zgłoszenia, szybka konsultacja bez rozmów telefonicznych. Według Telegram aktywna miesięczna publiczność w 2026 przekracza 900 milionów – Twoi klienci już tam są. W jakim czasie realnie można uruchomić prosty bot do zgłoszeń? Od 3 do 5 dni roboczych od gotowego briefu. Obejmuje to: scenariusz, podstawowy design odpowiedzi, kod, testy, integrację z CRM lub arkuszem, instrukcję dla administratora. Złożone scenariusze z odpowiedziami AI, wielojęzycznością i płatnościami – 2-4 tygodnie. Ile kosztuje bot Telegram? Zależy od scenariusza i integracji. Podstawowy bot do zgłoszeń jest wielokrotnie tańszy niż full-stack strona internetowa, bo nie ma designu podstron, frontendu ani responsive. Cena rośnie z liczbą scenariuszy, integracjami (CRM, płatności, rozsyłki) i złożonością logiki AI. Konkretna wycena – po krótkim briefie. Czy bot może podłączyć się do mojego CRM (Bitrix24, HubSpot)? Tak. Wszystkie główne CRM mają otwarte API. Bot wysyła zgłoszenie do CRM w odpowiednim formacie, tworzy deal, przypisuje odpowiedzialnego, zapisuje historię rozmowy. To samo dotyczy AmoCRM, Pipedrive, HubSpot, Salesforce. Jeśli CRM jest własny – integrujemy przez webhook lub bezpośredni dostęp do bazy. Co zrobić, jeśli bot nie poradzi sobie z niestandardowym pytaniem? Główna zasada: bot zawsze musi mieć fallback do człowieka. Jeśli użytkownik pisze coś poza scenariuszem – bot powinien albo zaproponować menu z jasnymi opcjami, albo przekazać rozmowę menedżerowi w DM, albo zebrać kontakt do oddzwonienia. Bot nigdy nie powinien «zawisać» ani robotycznie odpowiadać «nie rozumiem». --- --- title: "Narzędzia AI dla deweloperów 2026 – stack" url: https://tema.name/pl/blog/narzedzia-ai-dla-deweloperow-2026.html language: pl description: "Claude, Cursor, ChatGPT, Copilot, Perplexity, Make – mój roboczy stack 2026. Co wybrać początkującym, 7 błędów i FAQ." date_published: 2026-05-24 date_modified: 2026-05-24 --- Produkcja z AI 24 maja 2026 · 11 min czytania · Autor: Artem # Narzędzia AI dla deweloperów 2026: roboczy stack Roboczy stack na 2026: **Claude Sonnet 4.5 / Opus** (20 USD/mies., najlepszy do długiego kontekstu i refaktoryzacji), **Cursor** (20 USD/mies., IDE z AI w środku — przyspiesza pisanie kodu o 30–50%), **ChatGPT Plus** (20 USD/mies., do researchu i generowania treści), **GitHub Copilot** (10 USD/mies., autouzupełnianie w czasie rzeczywistym). Dla code review i analizy logów: Claude Projects + plik z konwencjami. Dla RAG i embeddings: OpenAI text-embedding-3-small (0,02 USD za 1M tokenów). Realny koszt komfortowej pracy: **40–60 USD/mies.**, zwraca się w pierwszym dniu. Czego AI *nie* robi: architektura systemów, decyzje produktowe, debugowanie wątków w prodzie. W artykule — który asystent do jakiego zadania i 6 błędów, które kosztują czas. **W artykule** 1. [Co zmieniło się w programowaniu w 2 lata](#what-changed) 2. [Mój roboczy stack po kategoriach](#stack) 3. [Jak wygląda dzień AI-pair programmingu](#workflow) 4. [Minimum dla początkujących](#beginner) 5. [7 błędów, które popełniłem](#mistakes) 6. [Częste pytania](#faq) ## Co zmieniło się w 2 lata w programowaniu Gdybym pisał ten artykuł w 2024, wyglądałby zupełnie inaczej. Wtedy AI było «przydatną zabawką»: pomagało z regexem, tłumaczyło błędy, czasem dawało dobry snippet. Teraz AI to **podstawowe środowisko pracy**, jak IDE czy git. 5+ narzędzi AI w codziennym stacku 3-5× przyspieszenie pracy z AI-pair programmingiem ~$75/mies koszt bazowego stacku subskrypcyjnego 0% boilerplate'a, który piszę ręcznie Trzy kluczowe zmiany: - **Okno kontekstu wzrosło.** Claude czyta teraz 200K+ tokenów naraz – to cały średni projekt. AI widzi całą codebase, a nie jeden plik na raz. - **Narzędzia stały się agentami.** Cursor potrafi sam uruchamiać komendy, czytać pliki, robić commity. Nie tylko «odpowiada na pytanie» – wykonuje łańcuchy akcji. - **Jakość kodu na poziomie seniora** przy typowych zadaniach. AI nie «czasem dobrze» – jest stabilnie dobre dla wszystkiego, co nie wymaga unikalnego kontekstu biznesowego. ## Mój roboczy stack po kategoriach ### Kategoria 1: asystenci kodu ### Claude (Anthropic) $20/mies · moje główne Główne narzędzie do długich kontekstów, złożonej refaktoryzacji i pytań architektonicznych. Lepiej podąża za instrukcjami niż GPT, mniej halucynuje. Używam przez claude.ai web i API w kodzie. Artifacts to świetny feature do iteracyjnej pracy nad jednym plikiem. ### Cursor $20/mies · IDE Fork VSCode z wbudowanym AI. Cmd+K do inline-edycji, Cmd+L do chatu z projektem, Composer do zmian wielu plików. Pod maską Claude Sonnet i GPT-4. Najbardziej produktywny tryb pracy – piszesz prompty bezpośrednio w kodzie. ### ChatGPT (OpenAI) $20/mies · drugi Biorę do zadań, gdzie potrzebne wyszukiwanie świeżych informacji (web-tryb) lub generowanie obrazów (DALL-E). Także jako «druga opinia», gdy Claude daje wątpliwą odpowiedź. Subskrypcja nie obowiązkowa, ale wygodna do regularnych zadań. ### GitHub Copilot $10/mies · inline Tab-autouzupełnianie wprost w edytorze. Mniej «myślący», bardziej «zgadujący», ale na zadaniach boilerplate (typowe gettery, pętle, formularze) oszczędza godziny. W Cursorze jest podobny wbudowany mechanizm – jeśli masz Cursor, Copilot może być zbędny. ### Kategoria 2: research i sprawdzanie faktów ### Perplexity $20/mies · wyszukiwanie ze źródłami AI-wyszukiwarka z linkami do źródeł. Niezbędna do researchu nowych bibliotek, weryfikacji faktów, szukania rozwiązań dla rzadkich błędów. Darmowy plan daje ~5 wyszukiwań Pro dziennie – już użyteczne. Pro-plan zdejmuje limity + modele Sonar. ### NotebookLM (Google) darmowe · dokumentacja Wgrywasz 5-50 PDF-ów/dokumentów – AI odpowiada na pytania z cytowaniem. Używam do analizy dużych dokumentacji API, specyfikacji technicznych, dokumentów prawnych. Darmowe z kontem Google. ### Kategoria 3: design i UI ### v0.dev (Vercel) od $20/mies · komponenty UI Opisujesz komponent tekstem lub wgrywasz screenshot – dostajesz kod React/Tailwind. Nie do produkcji «jak jest», ale jako punkt startowy – świetne. Szczególnie przydatne do bloków landingowych i kart dashboardu. ### Midjourney $10/mies · ilustracje Do ikon, ilustracji, hero-grafik. Przez bota Discord lub web-interfejs. Alternatywa – DALL-E (wchodzi w ChatGPT Plus). Preferuję Midjourney za stabilność stylu z --sref do brandingu. ### Kategoria 4: automatyzacja i orkiestracja ### Make.com od $9/mies · no-code workflows Wizualny builder do łączenia serwisów: bot Telegram → parsing → Google Sheets → rozsyłka email. Gdy scenariusz się ustabilizuje – przepisuję na skrypt Python, ale Make jest świetne do prototypów i szybkich rozwiązań. ### Własne skrypty Python/Node.js opensource · produkcyjna logika Gdy no-code uderza w sufit (lub staje się droższe niż skrypt na hostingu) – piszę swój kod przez Claude/Cursor. Hostowane na VPS lub Cloudflare Workers. Pełna kontrola, minimalne koszty. ### Kategoria 5: bazy wektorowe i RAG ### Pinecone / Qdrant od $0 (free tier) do $70/mies Bazy wektorowe do AI-wyszukiwania po Twoich dokumentach. Pinecone prostsze na start (managed), Qdrant – opensource, do hostowania u siebie. Wykorzystywane do agentów RAG: bot odpowiada na pytania po Twojej bazie wiedzy. ### OpenAI / Voyage embeddings grosze za tysiąc tokenów API do konwersji tekstu na wektory. OpenAI text-embedding-3-small – świetny baseline. Voyage – odrobinę dokładniejszy przy code-search i tekstach domenowych. Koszt dla typowego projektu – $1-5 miesięcznie. **Nie myl «narzędzia AI» z «uzależnieniem od AI».** Wszystkie te subskrypcje mają sens tylko jeśli zwracają się oszczędzonym czasem. Jeśli używasz Claude raz w tygodniu – nie ma sensu płacić $20/mies, są darmowe plany. Zaczynaj od minimum, rozszerzaj wraz z rosnącym obciążeniem. ## Jak wygląda dzień AI-pair programmingu Typowa sesja pracy nad featurem – 5 etapów. Każdy zoptymalizowany pod konkretne narzędzie. 1. Kontekst5-10 min 2. Prompt2-5 min 3. Generowanie1-3 min 4. Review10-20 min 5. Test5-15 min **Etap 1 – kontekst.** Otwieram potrzebne pliki w Cursorze (lub wczytuję do Claude przez @-menu). Jeśli zadanie obejmuje więcej niż jeden plik – zbieram «mapę» wszystkich zależności. Bez kontekstu AI pisze poprawny kod, który nie pasuje do Twojego projektu. **Etap 2 – prompt.** Opisuję zadanie w pełni: co ma powstać, jakie edge-cases uwzględnić, na jakim stacku, jakie konwencje projektu. Dobry prompt – 5-15 linii tekstu. Słaby prompt – «zrób formularz». **Etap 3 – generowanie.** AI daje odpowiedź. Nie zawsze przyjmuję od razu – często proszę o 2-3 warianty albo «teraz to samo, ale z obsługą błędów i logowaniem». **Etap 4 – review.** Najważniejszy etap. Czytam każdą linię, sprawdzam logikę, szukam halucynacji (nieistniejące metody, złe importy), oceniam dopasowanie do projektu. **Bez review nie commituję.** **Etap 5 – test.** Uruchamiam kod, sprawdzam edge-cases, idealnie piszę lub proszę AI o napisanie unit-testów. Sentry/logi do monitorowania w produkcji. ## Minimum dla początkujących Jeśli dopiero zaczynasz i nie chcesz od razu wydawać $75/mies – oto wejście w AI-development: - **Cursor (darmowy plan)** – limit zapytań miesięcznie, ale wystarczy do projektów osobistych. *$0* - **Claude albo ChatGPT darmowy plan** – obaj dają ~30-50 wiadomości dziennie. Wybierz jeden, pracuj z nim stale. *$0* - **Perplexity darmowy plan** – 5 wyszukiwań Pro dziennie, reszta to zwykłe AI-wyszukiwanie. *$0* To wystarczy na pierwsze 2-3 miesiące, podczas których uczysz się AI-workflow i rozumiesz, które zadania najlepiej daje każde narzędzie. Gdy uderzasz w limity – płacisz za jedno, potem dwa, potem trzy. W miarę jak AI zaczyna realnie zwracać czas. **Wskazówka:** nie próbuj opanować wszystkich 10 narzędzi naraz. Weź JEDNO (polecam Claude lub Cursor), 2-3 tygodnie pracuj tylko z nim po wszystkich zadaniach. Gdy uderzysz w jego limit – wtedy dodaj następne. Tak nauczysz się prawidłowo briefować AI, a nie «przełączać między oknami». ## 7 błędów, które popełniłem W 2 lata aktywnej pracy z AI – oto rekordziści w pożeraniu czasu i nerwów. 1. **Przyjmowałem kod AI bez czytania.** Najdroższy błąd – wierzyć «AI jest mądre». Raz produkcja padła, bo Claude użył nieistniejącej metody biblioteki. Od tamtej pory – każda linia czytana. 2. **Dawałem za krótki kontekst.** «Zrób formularz rejestracji» = źle. «Zrób formularz rejestracji w React, używamy react-hook-form, pola X/Y/Z, walidacja Zod, POST do /api/register» = dobrze. 3. **Nie zapisywałem trafionych promptów.** Gdy znajdziesz działający prompt – zapisz w notatkach. Inaczej za tydzień znów stracisz 20 minut na sformułowanie. 4. **Używałem AI do decyzji architektonicznych.** AI słabo rozumie kontekst projektu jako całość – rekomenduje «ogólne best practices», nie «to co pasuje Tobie». Architekturę decyduję sam, AI pomaga z implementacją. 5. **Ignorowałem koszty API przy skali.** Jeden skrypt-parser robił 10K zapytań w Claude API dziennie. Pod koniec miesiąca – $80 zamiast zwykłych $5. Lekcja: zawsze loguj zużycie tokenów. 6. **Próbowałem «obejść» AI przy zadaniach, gdzie jest mocniejsze.** Regexp, zapytanie SQL, konfiguracja webpacka – szybciej zapytać AI niż googlować 15 minut. Długo się przyzwyczajałem. 7. **Nie prowadziłem diff-logów zmian od AI.** Gdy pracujesz z agentem AI, który zmienia kilka plików naraz – obowiązkowo rób commit przed każdą rundą. Inaczej po 3-4 iteracjach trudno zrozumieć, co i gdzie się zepsuło. **Zasada kciuka:** AI to junior-deweloper, który pisze 100 razy szybciej niż ja. Ja jako tech lead: stawiam zadanie, robię review wyniku, biorę odpowiedzialność za rezultat. Nie «AI robi za mnie» – ale «robię szybciej z AI». Ta różnica w myśleniu – decyduje, czy rośniesz, czy stajesz się maszynką do kopiuj-wklej. ## Częste pytania Który asystent AI jest lepszy: Claude czy ChatGPT? Uzupełniają się. Claude (Anthropic) jest mocniejszy przy długich kontekstach, złożonej logice i precyzyjnym podążaniu za instrukcjami – moje główne narzędzie do refaktoryzacji i decyzji architektonicznych. ChatGPT (OpenAI) jest lepszy do szybkich pytań, wyszukiwania świeżych informacji, generowania pomysłów. W 2026 rozsądnie płacić za oba – $20-40/mies. każdy – i przełączać się zależnie od zadania. Od czego zacząć początkującym – minimalny stack AI? Minimum: Cursor jako IDE (darmowy plan na start) + Claude lub ChatGPT do głębszych pytań w przeglądarce. Te dwa pokryją 80% zadań przez pierwsze 6 miesięcy. Gdy dojdziesz do ich limitów – dodaj: GitHub Copilot do inline-podpowiedzi, Perplexity do researchu ze źródłami, Make.com do automatyzacji zewnętrznych procesów. Ile kosztują wszystkie te narzędzia miesięcznie? Bazowy stack dewelopera: Cursor Pro ($20), Claude Pro ($20), ChatGPT Plus ($20), GitHub Copilot ($10) = ~$70/mies. Plus koszty API na projekty osobiste – zwykle $5-30/mies. Łącznie $75-100/mies. To mniej niż jedna godzina pracy dewelopera – zwraca się pierwszego dnia użytkowania przez sam wzrost prędkości. Czy można pracować bez AI w 2026? Technicznie tak, ale to jak programowanie bez IDE i bez Stack Overflow – nie zabronione, ale tracisz mocno na tempie. Każdy miesiąc bez AI – konkurent z AI-stackiem zamyka 3-5x więcej zadań w tym samym czasie. To już nie «przewaga» – to bazowa kompetencja. Czy AI zastąpi deweloperów w najbliższych latach? Nie – ale zmieni rolę. AI dobrze generuje kod, ale słabo: stawia zadania, rozumie kontekst biznesowy, podejmuje decyzje architektoniczne, robi review zdroworozsądkowy, bierze odpowiedzialność przed klientem. Te zadania zostają człowiekowi. Deweloper 2026 to ekspert-inżynier, który dobrze briefuje AI i waliduje wynik. AI jako akcelerator, nie zastępstwo. --- --- title: "SEO dla strony jednoekranowej bez budżetu 2026" url: https://tema.name/pl/blog/seo-dla-strony-jednoekranowej-2026.html language: pl description: "7 obowiązkowych punktów SEO dla landinga, realne terminy, częste błędy. Tylko darmowe narzędzia: GSC, Yandex Webmaster, PageSpeed." date_published: 2026-05-25 date_modified: 2026-05-25 --- SEO bez budżetu 25 maja 2026 · 11 min czytania · Autor: Artem # SEO dla strony jednoekranowej bez budżetu 2026 Landing page do top 10 Google trafia w **2–6 miesięcy** przy konkurencji średniej, **realny budżet 0 zł** — wystarczy weekend pracy własnymi rękami. Konkrety: **1 strona = 1 klucz** (np. „strona z AI dla firmy w Warszawie"), title 50–60 znaków, description 140–160, H1 unikalny, treść 1 200–2 500 słów z odpowiedziami na 5–8 powiązanych pytań, JSON-LD (FAQPage + Organization + BreadcrumbList), PageSpeed 90+ na mobile. Linki: 3–10 z Google Maps, GoWork, branżowych katalogów. Gdzie to *nie* zadziała: zapytania komercyjne typu „kupić iPhone" — tam trzeba budżetu i 100+ stron. W artykule — checklista 14 kroków i błędy, które przez 3 lata blokują indeksację. **W artykule** 1. [Czy strona jednoekranowa w ogóle może się ranking](#can-rank) 2. [7 obowiązkowych punktów SEO dla landinga](#essentials) 3. [Plan krok po kroku: start w tydzień](#workflow) 4. [5 mitów SEO, które przeszkadzają](#myths) 5. [7 typowych błędów](#mistakes) 6. [Częste pytania](#faq) ## Czy strona jednoekranowa może się rankować Tak – w 2026 nawet lepiej niż 3 lata temu. Google i Yandex nauczyły się rozumieć **intencję użytkownika**, a nie tylko liczyć słowa. Jeśli strona klarownie odpowiada na konkretne pytanie – ma realne szanse na top, nawet jako pojedyncza strona. 1 H1 na stronie – reguła często łamana 1500+ słów optymalnie dla komercyjnego landinga 90+ PageSpeed Mobile do konkurencyjnego rankingu 100% narzędzi SEO z tego poradnika – darmowych Ale jest niuans. Strona jednoekranowa **przegrywa z wielostronicowymi** na «szerokich» zapytaniach (typu «kupić buty», «remont mieszkania»), gdzie konkurują strony z setkami podstron. Za to **wygrywa** na wąskich i niszowych zapytaniach – dokładnie tam, gdzie zwykle siedzi Twój klient. Realistyczne oczekiwania: - **Dobre dla**: «usługa + miasto» (SEO lokalne), niszowe usługi B2B, konkretne produkty dla specyficznej publiczności, marki osobiste, portfolia. - **Złe dla**: sklepów internetowych (potrzebne podstrony produktów), projektów medialnych (potrzebne artykuły), agregatorów (potrzebne kategorie). ## 7 obowiązkowych punktów SEO dla landinga To bazowa checklista. Bez któregokolwiek z tych punktów SEO nie działa – sprawdzone na dziesiątkach projektów. ### 1. Unikalne H1 ze słowem kluczowym Jedno H1 na stronie, i musi zawierać Twoje główne zapytanie. Nie «Witamy na stronie firmy», ale «Tworzenie stron pod klucz w Warszawie – Imię/Marka». Wyszukiwarki traktują H1 jako główny temat strony. ### 2. Title i meta description pod zapytanie Title – do 60 znaków z głównym zapytaniem na początku. Description – do 160 znaków, opisuje korzyść + powód kliknięcia. **Description nie wpływa na ranking**, ale wpływa na CTR – a CTR wpływa na ranking. ### 3. Znaczniki Schema.org Minimum: **Organization** lub **LocalBusiness** (jeśli masz adres fizyczny). Dla usług – **Service**. Dla sekcji FAQ – **FAQPage**. Dla opinii (jeśli prawdziwe) – **AggregateRating**. Schema.org daje rich results w wynikach: gwiazdki, akordeony FAQ, ceny. ### 4. Mobile-first + szybkie ładowanie Google indeksuje wersję mobilną pierwszą. PageSpeed Mobile 80+ minimum, 90+ konkurencyjnie. Najczęstsze «zabójcy» prędkości: ciężkie obrazki (używaj WebP/AVIF + lazy load), za dużo fontów (1 rodzina wystarczy), wizualne kreatory (Elementor dodaje 400KB ponad potrzebne). ### 5. Sitemap.xml + robots.txt + Search Console Sitemap.xml (choćby jednolinijkowa) + robots.txt + rejestracja w **Google Search Console** i **Yandex.Webmaster**. Bez tego wyszukiwarki dowiedzą się o stronie za 2-4 tygodnie. Z tym – za 1-3 dni. ### 6. Wewnętrzna struktura: H2-H3 jako odpowiedzi na pod-pytania Rozbij content na sekcje z H2-H3 odpowiadające na konkretne pod-pytania klienta. Na przykład: «Co wchodzi w usługę», «Ile trwa», «Ile kosztuje», «Gwarancje». Google uwielbia tę strukturę i często wyświetla ją jako featured snippet. ### 7. Analityka – bez niej nie ma optymalizacji Yandex.Metrika i/lub Google Analytics 4 + Search Console do zapytań. Bez analityki nie wiesz, które zapytania prowadzą klientów ani gdzie odpadają. SEO bez danych to wróżenie z fusów. - Unikalne H1 ze słowem kluczowym - Title do 60 znaków + description do 160 - Schema.org: Organization/LocalBusiness + Service + FAQPage - Design mobile-first + PageSpeed 90+ - Sitemap.xml + robots.txt + GSC + Yandex.Webmaster - Struktura H2-H3 pod pod-pytania klienta - Yandex.Metrika + GA4 + regularna analiza zapytań ## Plan krok po kroku: start w tydzień Tak wygląda realistyczny harmonogram konfiguracji SEO dla strony jednoekranowej: 1. Audytdzień 1 2. Słowadzień 2 3. Contentdzień 3-4 4. Tech SEOdzień 5 5. Indeksacjadzień 6+ **Dzień 1 – audyt.** Uruchom [PageSpeed Insights](https://pagespeed.web.dev), sprawdź H1/title/meta przez DevTools, zobacz czy Schema.org markup jest na miejscu przez Schema.org-validator. Cel – zrozumieć co działa i co naprawić. **Dzień 2 – słowa kluczowe.** Otwórz Google Keyword Planner i darmowe narzędzia Ahrefs. Znajdź 1 główne zapytanie (na które chcesz się rankować) + 3-7 wariacji long-tail. Na przykład główne – «automatyzacja AI dla biznesu», wariacje: «AI agent dla klientów», «chatbot AI FAQ», «automatyzacja zgłoszeń z AI». **Dzień 3-4 – content.** Przepisz teksty tak, żeby główne zapytanie było w H1, title, pierwszym akapicie i 2-3 razy w tekście naturalnie. Dodaj sekcje H2-H3 pod zapytania long-tail. Minimum 1500 słów dla landinga komercyjnego – mniej Google uznaje za «niewystarczająco głęboką» stronę. **Dzień 5 – tech SEO.** Dodaj Schema.org JSON-LD (LocalBusiness, Service, FAQPage). Napisz title/description. Sprawdź wersję mobilną. Skompresuj obrazki do WebP. Stwórz sitemap.xml i robots.txt w korzeniu. **Dzień 6+ – indeksacja.** Zarejestruj się w Google Search Console i Yandex.Webmaster. Wyślij sitemap. Poproś o indeksację ręcznie («inspect URL» → «request indexing»). W ciągu 1-3 dni strona pojawi się w wynikach na zapytania long-tail, w 2-4 tygodnie na szersze. **Pro-tip:** żeby przyspieszyć indeksację – opublikuj link do strony w aktywnym kanale społecznościowym (LinkedIn, kanał Telegram, Twitter). Wyszukiwarki znajdują strony szybciej, jeśli istnieją zewnętrzne linki. Jeden post LinkedIn = indeksacja w 1-2 dni zamiast 2-4 tygodni. ## 5 mitów SEO, które przeszkadzają ### Mit 1: «Trzeba dużo podstron, żeby się rankować» Rzeczywistość: na zapytaniach niszowych jedna jakościowa strona często bije stronę z 50 powierzchownych. Jakość > ilość. ### Mit 2: «Im więcej słów kluczowych w tekście, tym lepiej» Rzeczywistość: od 2020 nad-optymalizacja (keyword stuffing) to czynnik obniżania. Cel – naturalne wzmianki głównego zapytania 3-5 razy na 1500 słów, nie więcej. ### Mit 3: «Linki to wszystko w SEO» Rzeczywistość: w 2026 content bije linki. Kupione linki z giełd – ryzyko bana. 1 link z odpowiedniej strony branżowej wart 100 z farm. ### Mit 4: «SEO może być szybkie – 14 dni» Rzeczywistość: 2-4 tygodnie do pierwszych wyświetleń, 2-3 miesiące do stabilnych pozycji. Kto obiecuje szybciej – używa metod black-hat (bany) lub kłamie. ### Mit 5: «AI generuje teksty SEO, nie trzeba pisać samemu» Rzeczywistość: AI to pomocnik, ale Google nauczył się rozpoznawać «w pełni AI-wygenerowany» content i obniża go. Używaj AI do szkiców, potem przepisuj pod własne doświadczenie i prawdziwe case'y. ## 7 typowych błędów Te błędy widzę regularnie – u klientów, którzy próbowali robić SEO sami lub przez tanich freelancerów. 1. **Celowanie w «najwyżej-wolumenowe» zapytanie.** Chciałbyś rankować na «zamówić stronę» (milion konkurentów). Realniej – «strona pod klucz B2B w Warszawie» (50 konkurentów, Twój ICP). 2. **Kilka H1 na stronie.** Często bywa, gdy logo opakowane w `

` plus jeszcze `

` w hero. Musi być dokładnie jedno. 3. **Title i description skopiowane od konkurencji.** Google obniża duplikaty. Pisz swoje, pod swoją ofertę. 4. **Słaba wersja mobilna.** Font poniżej 14px, przyciski sklejone, niewygodne formularze – Google indeksuje właśnie mobilę i obniża za zły UX. 5. **Brak analityki od początku.** Po 3 miesiącach chcesz wiedzieć «czy SEO działa» – ale danych brak. Włącz Metrikę i Search Console pierwszego dnia. 6. **Oczekiwanie wzrostu w 2 tygodnie i rezygnacja po miesiącu.** SEO to efekt compound. Pierwszy miesiąc – prawie nic. Trzeci – zauważalny wzrost. Szósty – stabilny strumień. Cierpliwość. 7. **Ignorowanie Schema.org.** «To dla sklepów internetowych» – nie. LocalBusiness + Service + FAQPage – na każdym komercyjnym landingu obowiązkowe. **Dobry znak postępu:** w Search Console każdy tydzień rośnie liczba wyświetleń (impressions). CTR na razie niski – to normalne, podnosisz go dalej przez polepszanie title i description. Ale jeśli impressions nie rosną – SEO nie działa, czas zobaczyć co nie tak. ## Częste pytania Czy można w ogóle wypromować stronę jednoekranową w Google? Tak, szczególnie na wąskich zapytaniach komercyjnych. Strona jednoekranowa przegrywa z wielostronicowymi tylko na «szerokich» zapytaniach (typu «kupić buty»), ale na niszowych i lokalnych («naprawa pralek Gdańsk» lub «automatyzacja AI dla B2B w Warszawie») z łatwością wchodzi w top 10 przy prawidłowej optymalizacji. Klucz – nie celować «wszystko naraz» jedną stroną. Ile kosztuje SEO landinga bez agencji? Bazowa optymalizacja – 0 zł. Darmowe narzędzia: Google Search Console, Yandex.Webmaster, PageSpeed Insights, Schema.org Validator, ChatGPT/Claude do sprawdzania tekstów. Płatne tylko jeśli chcesz profesjonalny audyt ($50-200 jednorazowo) lub backlinki (osobny temat, nie polecam zaczynać od tego). 95% rezultatu daje darmowe. Ile słów kluczowych realnie wypromować jedną stroną? 1 główne zapytanie + 3-7 powiązanych wariacji long-tail. Na przykład główne – «zamówić stronę», wariacje: «strona cena», «strona termin», «zamówić stronę firmową». Jeśli próbujesz celować w 15 różnych tematów – Google nie rozumie o czym jest strona i nie rankuje jej w żadnym. Co ważniejsze w 2026: content czy linki? Content jest dużo ważniejszy, szczególnie na stronie jednoekranowej. Google nauczył się odróżniać «dobre» backlinki od śmieciowych, i 1 link z autorytatywnej strony branżowej jest wart 100 z farm. Skup się na contencie: jasne H1, rozbudowane odpowiedzi na pytania użytkownika, znaczniki Schema.org, szybkość ładowania. Linki przyjdą naturalnie, jeśli content jest użyteczny. Za ile czekać pierwszych wyników SEO? Realnie: 2-4 tygodnie do pierwszych wyświetleń w wynikach, 2-3 miesiące do stabilnych pozycji na zapytaniach long-tail, 4-6 miesięcy do pozycji na bardziej konkurencyjnych. Jeśli ktoś obiecuje «top 10 w 14 dni» – to albo czarne metody (szybko bany), albo oszustwo. SEO to maraton, nie sprint. --- --- title: "Katalog z formularzem na Joomla 2026 – dla B2B i usług" url: https://tema.name/pl/blog/katalog-z-formularzem-na-joomla-2026.html language: pl description: "Katalog z formularzem na Joomla 5 + HikaShop bez koszyka: dla B2B i usług, gdzie klient zostawia zapytanie zamiast kupować online. 3-5 tygodni, częste błędy, FAQ." date_published: 2026-05-26 date_modified: 2026-05-26 --- Joomla / B2B 26 maja 2026 · 11 min czytania · Autor: Artem # Katalog z formularzem na Joomla 2026: dla B2B i usług Katalog B2B z formularzem zapytania na Joomla wdraża się w **2–4 tygodnie** za **4 000–10 000 zł**, idealny do 50–2 000 pozycji bez koszyka i płatności online. Stack: **Joomla 5.x + HikaShop (tryb katalog) + Akeeba Backup + reCAPTCHA v3**. Karta produktu zawiera: 3–5 zdjęć, opis 200–400 słów, charakterystyki w tabeli, cenę „od" lub „na zapytanie", przycisk „Zapytaj o ofertę" z formularzem (imię, telefon, e-mail, komentarz). Lead trafia mailem + do CRM (Bitrix24, HubSpot, Pipedrive) i Telegram. PageSpeed osiągalne: 90–98 mobile. Komu się *nie* opłaca: gdy masz 5 000+ SKU z częstymi cenami online — wtedy raczej sklep lub PIM. W artykule — pełna struktura katalogu i 7 błędów, które tną konwersję. **W artykule** 1. [Dla kogo pasuje format](#who) 2. [Dlaczego Joomla + HikaShop bez koszyka](#stack) 3. [Start w 3-5 tygodni](#workflow) 4. [Co ma być w karcie](#card) 5. [7 typowych błędów](#mistakes) 6. [Częste pytania](#faq) ## Dla kogo pasuje format Katalog z formularzem zapytania to strona-witryna, gdzie klient widzi wszystkie warianty, filtruje, porównuje, czyta detale i na końcu klika **«zostaw zapytanie»** zamiast «kup». Na zapytanie menedżer się odzywa z dopytaniem o szczegóły, omawia indywidualne warunki i zamyka transakcję osobiście. 50-500 typowa liczba pozycji w katalogu 3-5tyg start od zera 5-15% konwersja do zapytania w dobrym katalogu B2B 0zł kosztów bramek płatności (nie są potrzebne) Konkretne scenariusze, gdzie format działa najlepiej: - **Usługi B2B.** Obsługa prawna, usługi marketingowe, IT-outsourcing. Klient przegląda kierunki, czyta case studies, zostawia zapytanie o konsultację. - **Produkty na zamówienie.** Meble na wymiar, konstrukcje metalowe, sprzęt specjalistyczny. Klient widzi modelownię, ale konfiguracja i cena są omawiane. - **Usługi rzemieślnicze.** Remont, montaż, serwis. Lista usług z opisami, formularz «zamów wizytę». - **Kursy edukacyjne.** Gdy potrzebne spotkanie przed zapisem, brak stałych cen lub są stypendia/raty. - **Usługi medyczne.** Gdy zapis na konsultację ważniejszy niż «kup jednym kliknięciem». - **Sprzęt przemysłowy.** Cena zależy od konfiguracji, dostawa omawiana, potrzebna faktura. Nie pasuje do: sprzedaży detalicznej towarów codziennych (potrzebny pełny sklep), usług z ceną stałą i szybką decyzją (lepiej landing), agregatorów (potrzebne konta użytkowników). ## Dlaczego Joomla + HikaShop bez koszyka Na rynku są trzy typowe podejścia do katalogu z formularzem. Porównanie: | Podejście | Plusy | Minusy | | --- | --- | --- | | Tilda / Kreator | Szybki start, ładny out-of-box design | Słabo skaluje się na 50+ kart z filtrami, ograniczenia w filtrach, brak normalnego ACL | | WordPress + WooCommerce bez koszyka | Ogromny ekosystem wtyczek | Praca wbrew architekturze wtyczki – obejścia. Wielojęzyczność tylko przez WPML ($$) | | Joomla 5 + HikaShop catalog mode | Natywne wsparcie «bez koszyka», wielojęzyczność out of the box, ACL dla kilku ról | Mniej gotowych motywów niż WP, wymaga programisty z doświadczeniem Joomla | Dlaczego wybieram Joomla + HikaShop dla większości klientów: - **HikaShop umie «catalog mode»** – jeden przełącznik usuwa koszyk, płatność, statusy zamówienia. Zostaje filtrowalna witryna + przycisk «zostaw zapytanie». - **Wielojęzyczność za darmo** – Joomla out of the box robi RU+EN+DE+PL bez wtyczek klasy WPML (60-100$ rocznie). - **ACL dla różnych ról** – menedżer widzi swoje leady, content-edytor aktualizuje opisy, admin widzi wszystko. Bez wtyczek. - **Mniej «ogrodu wtyczek»** – Joomla z bazowym stackiem działa stabilnie latami bez aktualizacji co tydzień. - **Może stać się pełnym sklepem** – jeśli za rok biznes urośnie do płatności online, HikaShop włącza koszyk tym samym przełącznikiem. **Alternatywy:** dla bardzo małych katalogów (10-30 pozycji) – statyka z dynamicznymi formularzami. Dla dużych B2B z integracjami (1C, SAP, konta klientów) – osobny stack (często Symfony/Laravel + custom admin). Joomla działa w średnim zakresie 50-500 pozycji. ## Start w 3-5 tygodni Tak wygląda realistyczny harmonogram startu katalogu od zera: 1. Brieftyg 1 2. Strukturatyg 1-2 3. Kartytyg 2-3 4. Forms+CRMtyg 3-4 5. Starttyg 4-5 **Tydzień 1 – brief.** Określamy kategorie, typową kartę, pola filtrów, jakie dane zbierać w formularzu zapytania, gdzie wysyłać leady (chat Telegram, CRM, Google Sheets). Wyjście – struktura katalogu jako lista. **Tygodnie 1-2 – struktura.** Instaluję Joomla 5, ustawiam HikaShop w catalog mode, konfiguruję wielojęzyczność (jeśli potrzebna), tworzę kategorie i atrybuty. Robię szablon pod brand. **Tygodnie 2-3 – karty.** Wypełniamy katalog: opisy, charakterystyki, zdjęcia, wideo (jeśli są), dokumenty do pobrania. Ten etap zwykle zajmuje najwięcej czasu – zależy od gotowości contentu u klienta. **Tygodnie 3-4 – formularze i integracje.** Konfiguruję formularze zapytań: ogólny «zostaw zapytanie», na każdej karcie indywidualny «zapytaj o tę pozycję». Podłączam integracje: leady lecą do Telegram-chatu menedżera + CRM (Bitrix24, AmoCRM, HubSpot) + Google Sheets jako backup. **Tygodnie 4-5 – start.** Finalne testy na desktopie, mobile, tablecie. Podpinam analitykę (Yandex.Metrika z celami, Google Analytics 4). Rejestruję w Google Search Console i Yandex.Webmaster, wysyłam sitemap. Przekazuję dostępy klientowi z krótką instrukcją. ## Co ma być w karcie Karta pozycji – kluczowy element katalogu. Od jej jakości zależy, czy klient zostawi zapytanie, czy odejdzie «pomyśleć». Obowiązkowe minimum: - Tytuł – zwięzły, ze słowem kluczowym (jeśli SEO ważne) - 2-3 jakościowe zdjęcia lub wideo – nie stock, ale prawdziwe - Krótki opis (1-2 akapity) – co to jest, dla kogo, główna korzyść - Charakterystyki w tabeli – strukturalnie, nie tekstem ciągłym - Cena «od» lub przedział – nawet orientacyjna, inaczej klient myśli «drogo» - Termin (wykonania, dostawy) – konkretnie, nie «do omówienia» - Formularz «zapytaj o tę pozycję» bezpośrednio na karcie, nie tylko w stopce - Podobne pozycje na dole, do nawigacji między wariantami Dodatkowe elementy podnoszące konwersję (w moim doświadczeniu 2-5% lift): - **Kontekst zastosowania** – «pasuje do», «stosowane w». Pomaga klientowi zdecydować, czy to jego wariant. - **Porównanie z podobnymi** – «czym różni się od modelu X». Redukuje pytania w formularzu. - **Case lub opinia** – 1-2 zdania od realnego klienta, który zamawiał właśnie tę pozycję. - **Gwarancje** – okres gwarancji, warunki zwrotu, co wchodzi w cenę. - **Dokumenty do pobrania** – PDF-specyfikacja, certyfikaty, instrukcja. Klienci B2B uwielbiają «zabrać materiały do uzgodnienia». **Główna zasada:** karta ma zdejmować maksimum pytań przed zostawieniem zapytania. Im więcej pewności klient zdobędzie na karcie, tym wyższa szansa, że napisze do Ciebie, a nie pójdzie porównywać z konkurencją. ## 7 typowych błędów Te błędy widzę regularnie – u klientów, którzy robili katalog sami lub z poprzednim wykonawcą. 1. **Robić katalog z formularzem jak pełny sklep internetowy.** Włączają koszyk, statusy zamówienia, całą resztę. W efekcie klient się gubi: «do koszyka czy od razu pisać?». Koszyk trzeba wyłączyć. 2. **Za dużo kategorii.** 15-20 kategorii na 50 pozycji – przesada. Lepiej 4-6 dużych kategorii z filtrami wewnątrz. 3. **Karta bez formularza.** Formularz tylko w stopce. Klient doczytał kartę, zainteresował się, chciał kliknąć – musiał przewinąć z powrotem. Część odpada. 4. **Brak ceny.** «Cena na zapytanie» – największy zabójca konwersji. Pokaż chociaż przedział lub «od X». Inaczej klient myśli «drogo = nie dla mnie». 5. **Jeden ogólny menedżer do wszystkiego.** 50+ pozycji wymaga różnych odpowiedzialnych. ACL w Joomla pozwala – menedżer A widzi leady w kategorii 1, B w kategorii 2. 6. **Brak analityki i celów.** Uruchomili katalog – «czy działa» nieznane. Yandex.Metrika z celami na wysłanie formularza – obowiązkowo od pierwszego dnia. 7. **Brak podłączonego CRM.** Leady lecą tylko do maila i giną. Potrzeba: Telegram menedżera + CRM + Google Sheets jako backup. Trzy punkty – nic nie zginie. **Pro-tip:** po pierwszych 50-100 zapytaniach przeanalizuj, które pozycje dostają więcej zapytań niż inne. Może warto wystawić je jako «top» lub «popularne» – to kolejne 5-10% lift do konwersji. ## Częste pytania Czym katalog z formularzem różni się od sklepu internetowego? W sklepie internetowym klient wkłada do koszyka, płaci online, dostaje zamówienie automatycznie. W katalogu z formularzem klient przegląda warianty, zostawia zapytanie – «chcę omówić» – i menedżer się odzywa. Pasuje do B2B, usług wymagających omówienia, produktów na zamówienie, schematów przetargowych. Technicznie prościej: bez płatności online, bez statusów zamówienia, jest obsługa leadów. Dlaczego właśnie Joomla, a nie Tilda lub WordPress? Tilda – dla marketingowych landingów, słabo skaluje się przy 50+ kartach z filtrami. WordPress + WooCommerce można skonfigurować «bez koszyka», ale to wbrew architekturze wtyczki. Joomla 5 + HikaShop w trybie «catalog mode» – właśnie pod to zadanie, z wielojęzycznością out of the box i czystym ACL. Dla 50-500 pozycji to optymalny stack. Ile pozycji utrzyma katalog z formularzem? Bez optymalizacji – 50-300 pozycji komfortowo. Z cachingiem i dobrym hostingiem – do 5 000. Powyżej – potrzebne dedykowane rozwiązania: albo wyspecjalizowana platforma B2B, albo architektura custom. Jeśli masz 1 000+ SKU z aktywnymi zmianami – omawiamy oddzielnie. Jak mierzyć efektywność katalogu? Główna metryka – konwersja z wyświetlenia karty do zapytania. Dobry wskaźnik: 5-15% dla B2B, 2-5% dla usług masowych. Mierzy się przez Yandex.Metrika lub GA4 + cele na wysłanie formularza. Jeśli konwersja poniżej 2% – problem albo w samych kartach (brak konkretów, słabe zdjęcia), albo w formularzu (długi, straszny). Czy potem można dodać płatność online? Tak, HikaShop włącza koszyk z powrotem przez ustawienia – to przełącznik w adminie. Można też podłączyć bramki płatności (Stripe, PayPal, lokalne procesory). Architektura katalogu przechodzi migrację do pełnego sklepu bez przebudowy frontendu. To plus wyboru Joomla od początku. --- --- title: "Agenci AI z RAG dla bazy wiedzy 2026" url: https://tema.name/pl/blog/agenci-ai-rag-baza-wiedzy-2026.html language: pl description: "Czym jest RAG, jak działa, komponenty systemu, częste błędy. Pinecone vs Qdrant vs pgvector. Czas wdrożenia i koszty." date_published: 2026-05-27 date_modified: 2026-05-27 --- Agenci AI / RAG 27 maja 2026 · 12 min czytania · Autor: Artem # Agenci AI z RAG dla bazy wiedzy 2026: przewodnik wdrożenia Agent AI z RAG to **asystent, który przed odpowiedzią czyta Twoje dokumenty** (regulaminy, instrukcje, bazę FAQ, oferty PDF) i odpowiada z linkami do źródeł — bez halucynacji. Stack 2026: **OpenAI GPT-4o lub Claude Sonnet 4.5** jako LLM, **text-embedding-3-small** dla wektorów, baza wektorowa Qdrant/Pinecone/pgvector, frontend (web/Telegram/widget). Wdrożenie MVP: **10–20 dni**, koszt 8 000–25 000 zł, utrzymanie 200–800 zł/mies. (LLM-tokeny + hosting). Realne case'y: bot-support z bazą 500 stron dokumentacji, wewnętrzne wyszukiwanie dla zespołu 50+ osób, edukacja, B2B-sprzedaż z odpowiedziami z whitepaperów. Czego RAG *nie* zastąpi: aktualizacji bazy wiedzy (śmieci na wejściu = śmieci na wyjściu). W artykule — architektura, koszty i 6 typowych błędów. **W artykule** 1. [Czym jest RAG i po co](#what-is) 2. [5 typowych zastosowań](#use-cases) 3. [Komponenty systemu RAG](#components) 4. [Start w 2-4 tygodnie](#workflow) 5. [Porównanie baz wektorowych](#vectordb) 6. [7 typowych błędów](#mistakes) 7. [Częste pytania](#faq) ## Czym jest RAG i po co Wyobraź sobie ChatGPT, który przed każdą odpowiedzią czyta Twoje korporacyjne wiki, dokumentację produktu, regulaminy, rozwiązane tickety – i daje odpowiedź **z linkami do konkretnych dokumentów**, z których wziął informację. To właśnie RAG. 50-5000 typowy rozmiar bazy wiedzy do zadań B2B 2-4tyg czas wdrożenia bazowego agenta 70-90% dokładność odpowiedzi na dobrze przygotowanych danych $20-300/mies koszt pracy dla średniego biznesu Dlaczego zwykły ChatGPT nie pasuje do większości zadań biznesowych: - **Nie zna Twojego produktu.** ChatGPT nie czytał Twojej dokumentacji, nie zna specyfiki, wymyśli «wiarygodną» ale nieprecyzyjną odpowiedź. - **Data cut-off.** Nawet Claude czy GPT-4 są wytrenowane na danych do określonej daty. Zmiany w produkcie po – nieznane. - **Brak linków do źródeł.** Użytkownik nie może sprawdzić, skąd odpowiedź – mniej zaufania. - **Drogo przekazywać wszystko w kontekście.** Okno kontekstu 200K tokenów – ale 1000 PDF się nie zmieści, a koszt każdego zapytania będzie ogromny. RAG rozwiązuje wszystkie cztery. Przed odpowiedzią system **znajduje 3-7 najbardziej relewantnych fragmentów** w Twojej bazie i przekazuje LLM jako kontekst. LLM formuje odpowiedź na podstawie właśnie tych fragmentów, z cytowaniem źródeł. **Główne:** RAG nie zastępuje ChatGPT – uzupełnia go. ChatGPT daje «ogólną wiedzę świata», RAG daje «wiedzę Twojej konkretnej firmy, produktu, branży». Razem – mocne narzędzie. ## 5 typowych zastosowań ### 1. Support po dokumentacji produktowej Klient pyta na czacie strony lub w bocie Telegram. RAG szuka odpowiedzi w dokumentacji, FAQ, wcześniej rozwiązanych ticketach. Zamyka 60-80% typowych pytań bez człowieka. Trudne przypadki przekazuje operatorowi z zebraną справką. ### 2. Wewnętrzne wyszukiwanie w korporacyjnym wiki Nowy pracownik nie pamięta «jak u nas załatwia się delegację» lub «gdzie regulamin pracy z klientami». Pyta agenta RAG. Ten znajduje w Notion/Confluence/Google Docs potrzebny dokument, cytuje fragment, daje link do pełnego. ### 3. Asystent sprzedaży po produktach Menedżer na spotkaniu z klientem. Klient zadaje złożone pytanie techniczne. Menedżer otwiera czat RAG, pyta, dostaje odpowiedź z linkami do specyfikacji, umów, case'ów. Szybkość odpowiedzi klientowi – ×3-5. ### 4. Analiza dokumentów prawnych Prawnik wgrywa umowę. RAG sprawdza ją wobec korporacyjnych standardów («nasze obowiązkowe punkty», «czerwone flagi»), wyróżnia różnice i ryzyka, cytuje precedensy z bazy poprzednich transakcji. ### 5. Asystent edukacyjny Student kursu online zadaje pytanie. RAG szuka odpowiedzi w materiałach kursu, prezentacjach, transkryptach wykładów. Zdejmuje 70% typowych pytań z tutora, podnosi completion rate kursu. To nie pełna lista. Realnie RAG pasuje wszędzie, gdzie jest **duża baza semi-strukturalnego tekstu** i regularne pytania do niej. ## Komponenty systemu RAG RAG to nie «jedna usługa», a pipeline z 6-7 komponentów. Każdy trzeba dobrać pod zadanie. - **Źródło danych** – PDF, strony www, Notion, Confluence, Google Docs, SharePoint, CSV/Excel, bazy danych. Od źródła zależy jak wyciągać tekst. - **Parser i chunker** – dzieli dokumenty na fragmenty 300-800 tokenów. Od rozmiaru chunka mocno zależy jakość wyszukiwania. - **Model embeddings** – konwertuje tekst na wektory. OpenAI text-embedding-3-small (uniwersalny), Voyage-large (dokładniejszy na kodzie), Cohere embed-multilingual (wielojęzyczny). - **Baza wektorowa** – przechowuje wektory i szybko znajduje «podobne». Pinecone, Qdrant, Weaviate, pgvector w Postgres. - **Logika retrieval** – szuka top-K fragmentów, opcjonalnie re-ranking (Cohere Rerank, Voyage Rerank) dla zwiększenia dokładności. - **LLM** – formuje finalną odpowiedź na podstawie znalezionych fragmentów. Claude Sonnet (długie konteksty), GPT-4 (uniwersalny), Mistral/Llama (lokalne). - **Szablon promptu** – instrukcja dla modelu: «odpowiedz tylko na podstawie dokumentów poniżej, koniecznie cytuj źródła, jeśli nie wiesz – powiedz wprost». - **UI lub API** – czat na stronie, bot Telegram, widget w Notion, lub REST API do integracji w swój produkt. **Bez któregoś komponentu nie wyjdzie.** Często widzę: kupili Pinecone, wgrali 200 PDF w całości, dali ChatGPT – «nie działa». Oczywiście nie działa: brak chunkera, embeddings nie wybrane, prompt nie skonfigurowany. RAG to pipeline, nie usługa. ## Start w 2-4 tygodnie Realistyczny harmonogram startu bazowego agenta RAG od zera: 1. Danedn 1-3 2. Chunkingdn 4-6 3. Embeddingsdn 7-10 4. Retrievaldn 11-16 5. UI+testydn 17-21 **Dni 1-3 – dane.** Zbieramy wszystkie źródła: co chcemy, żeby agent wiedział. Czyścimy: usuwamy przestarzałe, duplikaty, śmieciowe dokumenty. Na tym etapie zwykle wychodzi, że «naszą dokumentację ostatnio aktualizowaliśmy 3 lata temu» – część pracy po stronie klienta. **Dni 4-6 – chunking.** Parsujemy dokumenty, dzielimy na fragmenty. Tu wiele niuansów: PDF z tabelami wymaga specjalnej obsługi, code blocks nie można przecinać w środku, nagłówki trzeba zachować z kontekstem. Nie «jeden uniwersalny chunker na wszystko», a dostosowany. **Dni 7-10 – embeddings.** Podłączamy OpenAI lub Voyage API, przepuszczamy wszystkie chunki przez model embeddings. Zapisujemy w bazie wektorowej. Dla treści PL+EN biorę modele multilingual; dla czystego angielskiego – text-embedding-3-small wystarczy. **Dni 11-16 – retrieval.** Konfigurujemy wyszukiwanie: top-K (zwykle 5-10), próg podobieństwa, opcjonalnie re-ranking. Testujemy na 20-30 typowych pytaniach: czy wracają relewantne fragmenty? Jeśli nie – tunujemy: rozmiar chunka, embeddings, prompt. **Dni 17-21 – UI i testy.** Robimy interfejs: czat na stronie przez iframe, bot Telegram, widget w Notion, lub REST API. Podpinamy monitoring: logi zapytań, oceny użytkowników (👍/👎), metryki dokładności. Finalne testy z prawdziwymi użytkownikami. ## Porównanie baz wektorowych Od wyboru bazy wektorowej zależy koszt, prędkość, wygoda skalowania. Trzy popularne opcje: | Rozwiązanie | Plusy | Minusy | | --- | --- | --- | | Pinecone | Managed, szybki start, zero DevOps | Droższe przy skali ($70+/mies), vendor lock-in, brak self-host | | Qdrant | Open source, self-host za darmo, lub Qdrant Cloud. Wysoka prędkość | Potrzebna podstawowa infra (Docker) do self-host | | PostgreSQL + pgvector | Jeśli masz już Postgres – stawiasz rozszerzenie, brak nowej infry | Trochę wolniejsze przy ogromnych zbiorach (10M+ wektorów), potrzebne indeksy | | Weaviate | Hybrid search (wektory + keywords), moduły dla różnych embeddings | Bardziej skomplikowane w konfiguracji niż Pinecone/Qdrant | Moje rekomendacje: - **Prototyp / MVP** – Pinecone free tier lub Qdrant lokalnie. Szybki start, bez myślenia o infrastrukturze. - **Production do 1M wektorów** – Qdrant self-hosted na VPS ($10-30/mies) lub Pinecone starter ($70/mies). - **Masz już Postgres** – pgvector, brak nowej infry, wygoda dla zespołu. - **Enterprise z 10M+ wektorów** – Pinecone enterprise lub Qdrant Cloud z replicami. ## 7 typowych błędów Za 2 lata aktywnej pracy z systemami RAG – oto rekordziści problemów. 1. **Ładować wszystko jak leci.** Śmieci na wejściu = śmieci na wyjściu. 80% czasu idzie na przygotowanie danych: czyszczenie, normalizacja, usuwanie przestarzałego. To nie «techniczna drobnostka», a połowa sukcesu. 2. **Zbyt duże chunki.** Jeśli chunk to cała strona, model znajduje «tę stronę» zamiast «konkretnego akapitu». Dokładność spada. Optymalnie – 300-800 tokenów z overlap 50-100. 3. **Zbyt małe chunki.** Jeśli chunk to 1 zdanie, traci się kontekst: «on» nie wiadomo o czym. Zbyt krótkie – też źle. 4. **Jeden model embeddings dla wszystkich języków.** Jeśli masz treść PL+EN – potrzebne multilingual embeddings (Cohere multilingual, OpenAI text-embedding-3-large). Inaczej cross-language search nie działa. 5. **Brak re-ranking.** Top-K z vector-search często zawiera «podobne, ale nieprecyzyjne». Model re-rankingu przesortowuje wyniki po relewantności – wzrost dokładności o 15-30%. 6. **Ignorowanie cytatów.** Odpowiedź bez linków do źródeł = brak zaufania. Prompt musi jawnie wymagać cytowania: «podawaj źródło w nawiasach kwadratowych po każdym fakcie». Użytkownik widzi link → klika → sprawdza → ufa. 7. **Nie aktualizować bazy.** Po 3-6 miesiącach dokumentacja się starzeje, odpowiedzi stają się fałszywe. Potrzebny regularny proces re-indeksacji: automatyczny przy zmianie w Notion/Confluence lub cron raz w tygodniu. **Dobry znak działającego RAG:** użytkownicy zaczynają ufać mu bardziej niż wyszukiwarce w wiki. Jeśli po 1-2 miesiącach widzisz, że zapytania do agenta rosną, a do supportu spadają – system działa. Jeśli odwrotnie – problem z jakością odpowiedzi, czas na debug. ## Częste pytania Czym agent RAG różni się od zwykłego ChatGPT? Zwykły ChatGPT odpowiada na podstawie danych treningowych (do daty cut-off). Nie zna Twojego produktu, dokumentów ani procesów wewnętrznych. Agent RAG przed odpowiedzią szuka relewantnych fragmentów w Twojej bazie wiedzy (dokumentacja, artykuły, polityki) – z linkami do źródeł. W istocie: «ChatGPT, który czyta Twoje dokumenty przed odpowiedzią». Ile kosztuje wdrożenie agenta RAG? Bazowy agent na 50-500 dokumentów: 2-4 tygodnie deweloperki + $20-100/mies na bazę wektorową i LLM API. Dla biznesu ze średnim ruchem (100-500 zapytań/dziennie) – ~$100-300/mies. Duże instalacje enterprise z 10 000+ dokumentów i tysiącami zapytań dziennie – od $1000/mies. Konkretna wycena – po krótkim briefie. Ile dokumentów realnie obsłuży RAG? Od 10 do milionów. Technicznie brak górnej granicy. 10-100 dokumentów – każda baza wektorowa działa. 1000-10000 – managed (Pinecone) lub self-hosted Qdrant. Powyżej 100000 – potrzebna optymalizacja chunkingu, retrieval hierarchiczny, czasem osobne indeksy per typ treści. W mojej praktyce 500-5000 dokumentów to najczęstszy rozmiar. Czy moje dane są bezpieczne w OpenAI lub Anthropic? Wywołania API (płatne plany) – Twoje dane nie są używane do treningu, jest to w Terms of Service obu dostawców. Dla wrażliwych danych są opcje: plany enterprise z podpisanym DPA, modele lokalne (Llama, Mistral) na swoim serwerze, lub podejście hybrydowe. Dla większości zadań B2B plany API wystarczą. Dla PII lub medycyny – model lokalny lub enterprise. Pinecone, Qdrant czy PostgreSQL+pgvector – co lepsze? Pinecone – szybki start, managed, droższy przy skali ($70+/mies). Qdrant – open source, self-host darmowy, lub Qdrant Cloud. PostgreSQL+pgvector – jeśli masz już Postgres, dodaj rozszerzenie, brak nowej infry. Dla 10-100K wektorów wszystkie trzy działają. Dla milionów – Pinecone lub Qdrant Cloud. Dla zespołów bez DevOps – Pinecone najprostszy. --- --- title: "Cloudflare Workers dla biznesu 2026: poradnik" url: https://tema.name/pl/blog/cloudflare-workers-dla-biznesu-2026.html language: pl description: "Cloudflare Workers dla biznesu 2026: czym są, 5 zastosowań, porownanie z Lambda i Vercel, typowe błędy. Wdrożenie bez własnego serwera w minuty." date_published: 2026-05-28 date_modified: 2026-05-28 --- Serverless / Edge 28 maja 2026 · 11 min czytania · Autor: Artem # Cloudflare Workers dla biznesu 2026: praktyczny poradnik Cloudflare Workers to **kod, który wykonuje się w 330+ lokalizacjach edge na świecie**, z opóźnieniem 5–50 ms zamiast 100–500 ms u klasycznego serwera. Cennik: **100 000 requestów dziennie za darmo**, dalej 0,30 USD za 1 mln. Dla biznesu daje to 5 praktycznych zysków: A/B testy bez przeładowania strony, geo-przekierowania (PL/EN/DE), ochrona formularzy przed botami (Turnstile), proxy do API z cache'owaniem, modyfikacja HTML w locie (np. wstrzykiwanie analytics dla wybranych krajów). Porównanie: **Workers ~10× tańsze od AWS Lambda** przy 1 mln+ requestów i mają zimny start poniżej 5 ms zamiast 200–1500 ms. Gdzie się *nie* opłaca: ciężkie obliczenia (limit 30s CPU, 128 MB RAM). W artykule — 5 case'ów, kod startowy i 4 typowe błędy. **W artykule** 1. [Czym są Workers i ekosystem](#what-is) 2. [5 zastosowań dla biznesu](#use-cases) 3. [Porównanie z alternatywami](#compare) 4. [Uruchomienie pierwszego Workera w godzinę](#workflow) 5. [7 typowych błędów](#mistakes) 6. [Częste pytania](#faq) ## Czym są Workers i ekosystem Cloudflare Workers to **serverless edge compute**. Piszesz funkcję w JavaScript/TypeScript (lub Rust/Python przez Pyodide), wdrażasz przez CLI lub git, i natychmiast działa w ponad 330 miastach na świecie – Cloudflare sam rozmieszcza ją na najbliższym użytkownikowi serwerze. 330+ lokalizacji edge na świecie do wdrażania kodu 100K/dzień zapytań za darmo na planie free ~5-50ms typowy czas odpowiedzi Workera $5/mies plan paid: 10 mln zapytań miesięcznie Główna różnica względem klasycznych chmur: **kod wykonuje się w tej samej sieci co CDN**. Nie ma pojęcia „instancja", „region", „dostępność". Zimnego startu praktycznie nie ma – V8 isolate startuje w 5ms. Wokół Workers Cloudflare zbudował cały ekosystem usług: - **KV (Key-Value)** – rozproszony storage dla cache, sesji, feature flag. Za darmo do 100K odczytów dziennie. - **R2 (Object Storage)** – storage zgodny z S3 dla plików. Główna zaleta: darmowy egress (w AWS S3 płacisz za każdy oddany bajt). - **D1 (SQL Database)** – SQLite na edge. 5 USD/mies za 10GB. Nadaje się do większości aplikacji webowych do 10M zapytań. - **Durable Objects** – obiekty ze spójnym stanem. Do pokoi czatu, kolejek, aplikacji WebSocket. - **Queues** – kolejki wiadomości do asynchronicznego przetwarzania. - **Workers AI** – uruchamianie modeli open-source (Llama, Mistral, embeddings) bezpośrednio na edge. Bez przesyłania danych do osób trzecich. - **Hyperdrive** – przyspieszone połączenie z zewnętrznymi PostgreSQL/MySQL/MongoDB. **Główna myśl:** Workers nie są „zamiennikiem serwera", tylko innym podejściem. Piszesz małe funkcje, które wykonują się blisko użytkownika, bez zarządzania infrastrukturą. Dla 70-80% zadań biznesowych to wystarcza. ## 5 zastosowań dla biznesu ### 1. Bot Telegram bez własnego serwera Najczęstszy use-case. Bot Telegram przez webhook to endpoint HTTP, który przyjmuje zapytania POST. Worker świetnie sobie z tym radzi. Stan sesji – w KV (darmowe 100K odczytów/dzień). Integracje z CRM lub OpenAI – przez fetch do ich API. Żadnego VPS, żadnego PM2 czy systemd – wdrożyłeś i zapomniałeś. ### 2. Obsługa formularzy ze strony Formularz zgłoszeniowy na statycznym landingu → Worker → wysyłka do czatu Telegram menedżera / e-mail / CRM. Ochrona przed spamem (honeypot, rate-limit) – kilka linijek w Workerze. Jeden Worker może obsługiwać formularze 10 stron równolegle. Plan free starcza z nawiązką dla średniego biznesu. ### 3. Proxy AI dla bezpieczeństwa kluczy API Chcesz dać użytkownikom dostęp do ChatGPT/Claude przez własny UI? Bezpośrednio z przeglądarki nie można odwoływać się do OpenAI/Anthropic – klucz API wycieknie. Worker jako proxy: front odwołuje się do Workera, Worker dodaje klucz API ze zmiennych środowiskowych i wywołuje OpenAI. Klucz nigdy nie opuszcza serwera. ### 4. Optymalizacja obrazów on-the-fly Cloudflare Images albo własny Worker z biblioteką Polish: optymalizacja obrazków „w locie". Wgrywasz oryginał do R2, Worker robi resize, konwersję do WebP/AVIF, nakładanie znaku wodnego – po parametrach URL. PageSpeed +20-30 punktów na stronach z dużą liczbą obrazków. ### 5. Geo-routing i testy A/B Worker widzi kraj, region i język przeglądarki użytkownika. Można kierować Rosjan na `tema.name/`, Niemców na `/de/`, Polaków na `/pl/`. Analogicznie dla testów A/B: różne wersje stron bez osobnej usługi. Wszystkie „eksperyment = druga strona" obsługiwane są na edge, zanim dotrą do origin. **Nie nadaje się do:** ciężkiego przetwarzania wideo (limit 50ms CPU na zapytanie w planie paid), monolitycznych aplikacji Django/Rails z tysiącami zależności, zadań wymagających długiego stanu (>30 sekund). ## Porównanie z alternatywami | Parametr | Cloudflare Workers | AWS Lambda | Vercel Functions | | --- | --- | --- | --- | | Regiony | 330+ lokalizacji edge | Jeden region (wybierasz ręcznie) | Edge + regiony | | Zimny start | ~5ms | 200-2000ms (Node.js), gorzej w Javie | 50-300ms | | Języki | JS/TS/Rust/Python (Pyodide) | Node.js/Python/Go/Java/Ruby/.NET | JS/TS, Python | | Plan free | 100K zapytań/dzień | 1M zapytań/miesiąc | 100K zapytań/mies | | Koszt 10M zapytań | 5 USD/mies | ~20 USD/mies + GB-seconds | ~20 USD/mies | | Vendor lock-in | Ekosystem Cloudflare | Ekosystem AWS (S3, DynamoDB...) | Vercel + nacisk na Next.js | | Idle to first request | Natychmiast | Do 2 sekund (cold start) | Do 300ms | Moje rekomendacje: - **Jeśli już używasz Cloudflare** – Workers są „darmowym rozszerzeniem" tego, za co już płacisz. Mniej rachunków, mniej dostawców. - **Jeśli masz intensywny stack AWS** (RDS, DynamoDB, SQS) – Lambda jest wygodniejsza, wszystko w jednym VPC. - **Jeśli front na Next.js / Nuxt / Astro na Vercel** – Vercel Functions są wygodniejsze, kod serwerowy w tym samym repo. - **Jeśli globalna grupa odbiorców** – Workers wygrywają dzięki lokalizacjom edge (CDN umieszcza kod w najbliższym użytkownikowi DC). ## Uruchomienie pierwszego Workera w godzinę Realistyczny harmonogram uruchomienia pierwszego produkcyjnego Workera od zera: 1. Setup10 min 2. Kod15 min 3. Deploy5 min 4. Routes10 min 5. Testy20 min **Setup (10 min).** Rejestracja konta Cloudflare (jeśli nie ma), instalacja CLI `wrangler` (`npm install -g wrangler`), `wrangler login` – otworzy przeglądarkę do autoryzacji. Na tym etapie masz już działające środowisko. **Kod (15 min).** `wrangler init my-worker` tworzy szablon. Podstawowy Worker to 10 linii kodu w TypeScript: przyjmuje zapytanie HTTP, zwraca Response. Dla bota Telegram dodajesz obsługę JSON i wywołanie Telegram API przez fetch. **Deploy (5 min).** `wrangler deploy` – Worker jest od razu dostępny pod `\*.workers.dev`. Logi przez `wrangler tail`. Bez Dockera, bez CI/CD, bez Kubernetesa. **Routes (10 min).** Jeśli masz już domenę na Cloudflare – w panelu Workers dodajesz Route: `api.yourdomain.com/\*` → twój Worker. Od tego momentu zapytania na ten URL trafią do Workera. **Testy (20 min).** Lokalne testowanie `wrangler dev`. Podłączasz KV/D1/R2 przez bindings w `wrangler.toml`. Edge cases: co zwróci Worker przy pustym zapytaniu, ogromnym, zapytaniu z uszkodzonym JSON. Deploy z `wrangler deploy --env production`. **Lifehack:** do części serwerowej bota Telegram w 95% zadań wystarczy jeden Worker + KV do stanów. Nie potrzeba Redisa, PostgreSQL, Dockera. Bot na 1000 użytkowników dziennie mieści się w planie free. Gdy przyjdzie 10 000 – płacisz 5 USD/mies. ## 7 typowych błędów Te grabie widziałem u klientów i sam na nie nadepnąłem. 1. **Trzymanie stanu w zmiennej globalnej.** Worker jest stateless – każde zapytanie może trafić na inny serwer. Stan – w KV/D1/Durable Objects, nie w zmiennej. 2. **Ignorowanie limitu CPU.** 10ms na free, 50ms na paid. Ciężka kryptografia lub duży JSON.parse mogą nie zdążyć. Profiluj przez `wrangler dev --remote`. 3. **Nieużywanie Wrangler secrets dla kluczy.** Wpisać klucz API OpenAI do kodu = wyląduje w git. Używaj `wrangler secret put` – klucz jest przechowywany zaszyfrowany u Cloudflare. 4. **Synchroniczne operacje na każde zapytanie.** Każdy fetch do zewnętrznego API kosztuje czas. Buforuj w KV lub Cache API powtarzające się dane. 5. **Zapomnienie o nagłówkach Origin.** CORS blokuje zapytania z frontu. Worker musi jawnie zwracać `Access-Control-Allow-Origin` – użytkownik nie zobaczy odpowiedzi, jeśli tego nie ma. 6. **Deploy bez testów.** Worker idzie na produkcję natychmiast. Rób osobny environment dla staging: `wrangler deploy --env staging`. 7. **Brak analytics.** W Cloudflare jest darmowy Workers Analytics – zapytania, błędy, latencja po regionach. Bez niego nie wiadomo, co się dzieje. ## Częste pytania Czym są Cloudflare Workers w prostych słowach? To kod, który wykonuje się na serwerach Cloudflare na całym świecie, blisko użytkownika. Piszesz funkcję w JavaScript/TypeScript, wdrażasz ją, i działa w ponad 330 miastach na świecie. Nie potrzebujesz własnego serwera, Dockera ani PM2. Zimnego startu praktycznie nie ma – odpowiedź w 5-50ms. Nadaje się do API, formularzy, botów Telegram, proxy, autoryzacji, przetwarzania obrazów. Ile kosztuje Cloudflare Workers? Plan Free: 100 000 zapytań dziennie za darmo, do 10ms CPU na zapytanie. To wystarcza dla większości projektów do 100K odwiedzin miesięcznie. Plan Paid: 5 USD miesięcznie za 10 milionów zapytań, do 50ms CPU. To wielokrotnie taniej niż AWS Lambda przy tej samej ilości. Czym Workers różnią się od AWS Lambda? Lambda działa w jednym regionie AWS, Workers – w ponad 330 lokalizacjach edge. Lambda ma zimny start 200-2000ms, Workers – poniżej 10ms. Lambda: Node.js/Python/Go/Java/Ruby, Workers: JavaScript/TypeScript/Rust/Python (przez Pyodide). Dla globalnych API i aplikacji webowych Workers są szybsze i prostsze, dla ciężkich zadań (przetwarzanie wideo, inferencja ML) – Lambda jest bardziej elastyczna. Czy można podłączyć bazę danych do Workers? Tak. Cloudflare ma własne usługi: D1 (SQLite na edge, 5 USD/mies za 10GB), KV (key-value, dla cache i sesji), R2 (storage zgodny z S3 bez opłat za egress), Durable Objects (spójność stanu). Można też podłączyć zewnętrzne bazy przez Hyperdrive (przyspieszony PostgreSQL) lub bezpośrednio przez connection API. Czy Workers nadają się do bota Telegram? Idealnie się nadają. Bot Telegram przez webhook to endpoint HTTP, który przyjmuje zapytania z Telegram API. Workers radzą sobie z takim obciążeniem nawet na planie free do 100K wiadomości dziennie. Stan sesji można trzymać w KV (darmowe 100K odczytów/dzień), integracje z CRM/OpenAI – przez fetch do ich API. Żaden VPS nie jest potrzebny. --- --- title: "PageSpeed 100 na 100 w 2026: jak i po co" url: https://tema.name/pl/blog/pagespeed-100-na-100-2026.html language: pl description: "Jak osiągnąć PageSpeed 100/100: Core Web Vitals, LCP/INP/CLS, realny tygodniowy plan optymalizacji, 7 błędów i FAQ." date_published: 2026-05-29 date_modified: 2026-05-29 --- Performance / SEO 29 maja 2026 · 11 min czytania · Autor: Artem # PageSpeed 100 na 100 w 2026: jak i po co PageSpeed 100/100 w 2026 = **LCP < 2,5s** + **INP < 200 ms** + **CLS < 0,1**. Osiąga się tak: krytyczny CSS inline w head (do 14 KB), reszta z `defer`, obrazy w AVIF/WebP z poprawnymi rozmiarami i `loading="lazy"`, fonty z `font-display: swap` i preload, frameworki JS zastąpione vanilla tam, gdzie się da — to zdejmuje 100–300 KB. Serwer: Brotli + HTTP/2 + immutable cache na rok. Na realnym projekcie mobile score rośnie z **38 do 98 w 5–7 dni roboczych**, koszt 1 500–4 500 zł. Czy 100/100 jest konieczne dla SEO: nie — od 90+ na mobile Google traktuje stronę jako szybką. Ścigać się o ostatnie 5 punktów warto tylko dla landing page i sklepów. W artykule — plan optymalizacji krok po kroku i 7 typowych błędów. **W artykule** 1. [Po co w ogóle przyspieszać stronę](#why) 2. [Core Web Vitals: LCP, INP, CLS](#vitals) 3. [7 głównych czynników prędkości](#factors) 4. [Tygodniowy plan optymalizacji](#workflow) 5. [7 typowych błędów](#mistakes) 6. [Częste pytania](#faq) ## Po co w ogóle przyspieszać stronę Trzy pragmatyczne powody – bez ideologii „bo Google tak kazał". 90+ PageSpeed Mobile dla normalnego rankingu -7% konwersji za każdą +1 sekundę ładowania 2.5s maksymalny LCP dla zielonej strefy 53% użytkowników odchodzi, jeśli strona ładuje się > 3 sekund - **Czynnik SEO.** Google uwzględnia Core Web Vitals jako czynnik rankingowy od 2021. Przy konkurencyjnych frazach szybka strona wyprzedza wolną, przy pozostałych równych warunkach. - **Konwersja.** Każda +1 sekunda ładowania zmniejsza konwersję o 5-7%. W e-commerce więcej. Bezpośrednie straty pieniędzy. - **Koszt reklamy.** Google Ads daje rabat na CPC dla szybkich landingów i odwrotnie karze wolne. Budżet – realnie wpływa. **Najważniejsze:** celem nie jest „100/100", lecz „zielona strefa we wszystkich Core Web Vitals". 90+ Mobile w PageSpeed Insights to już doskonały wynik, który daje maksimum tego, co Google bierze pod uwagę w rankingu. ## Core Web Vitals: LCP, INP, CLS To trzy metryki, które Google mierzy u rzeczywistych użytkowników poprzez Chrome (dane CrUX). Od 2021 są częścią algorytmu rankingowego. ### LCP (Largest Contentful Paint) Jak szybko pojawia się największy element na pierwszym ekranie – zwykle główny obraz lub duży nagłówek. **Dobrze: < 2.5s.** Źle: > 4s. Główni winowajcy słabego LCP: ciężkie obrazki hero bez `fetchpriority="high"`, brak `preload`, wolny serwer (TTFB), blokujące skrypty w head. ### INP (Interaction to Next Paint) Zastąpił FID w 2024. Mierzy, jak szybko strona reaguje na kliknięcie/dotknięcie/naciśnięcie klawisza. **Dobrze: < 200ms.** Źle: > 500ms. Główni winowajcy słabego INP: ciężki JS na main thread, synchroniczne event handlery, długie łańcuchy `setTimeout`. To „nowoczesny" ból głowy: nawet jeśli strona szybko się załadowała, może „przyklejać się" przy kliknięciu z powodu kiepskiego JS. ### CLS (Cumulative Layout Shift) Suma „skoków" układu podczas ładowania. Gdy baner u góry się doładował – i cały tekst przesunął się w dół = słaby CLS. **Dobrze: < 0.1.** Źle: > 0.25. Główni winowajcy: obrazy bez podanej width/height, fonty zmieniające rozmiar przy doładowaniu, bloki reklamowe, dynamicznie wstawiane elementy. ## 7 głównych czynników prędkości To podstawowa checklista. W 90% przypadków właśnie te punkty dają 70-90% przyrostu PageSpeed. - **Obrazki w WebP/AVIF + lazy load.** 80% „ciężaru" stron to obrazy. Konwersja PNG/JPG do WebP daje -40-60% na rozmiarze. AVIF jest jeszcze lepszy, ale wsparcie jest nieco gorsze. - **Minifikacja i kompresja (Brotli).** CSS/JS powinny być zminifikowane. Serwer powinien serwować z Brotli (lub przynajmniej gzip). Cloudflare robi to automatycznie. - **Usuń nieużywany CSS/JS.** Każdy `bootstrap.css` lub `jquery.js`, jeśli używany jest w mniej niż 30% – usunąć. PurgeCSS + tree-shaking w bundlerze. - **Fonty z font-display: swap.** Bez tego użytkownik widzi biały ekran, dopóki font ładuje się 1-2 sekundy. Ze swap – najpierw systemowy font, potem podmieniany. - **Preload głównego hero-image + preconnect do CDN.** `` zmniejsza LCP o 0.5-1.5 sekundy. - **CDN (Cloudflare).** Jeśli strona jest hostowana w Polsce, a klienci z USA – bez CDN strona ładuje się 3-5 sekund tylko ze względu na geografię. Cloudflare za darmo rozwiązuje ten problem. - **HTTP/2 lub HTTP/3.** Nowoczesny protokół z multipleksowaniem. Włącza się jedną opcją w hostingu lub Cloudflare. Bez niego przeglądarka pobiera pliki sekwencyjnie zamiast równolegle. **Zasada 80/20:** obrazki WebP + kompresja Brotli + preload hero + Cloudflare CDN dają 80% rezultatu przy 20% wysiłku. Zacznij od tych czterech. Dalej już punktowe optymalizacje. ## Tygodniowy plan optymalizacji Realistyczny harmonogram rozpędzenia strony z 40-50 punktów Mobile do 90+: 1. Audytdzień 1 2. Obrazkidzień 2-3 3. CSS/JSdzień 4 4. CDN/HTTPdzień 5 5. Finiszdzień 6-7 **Dzień 1 – audyt.** Przepuszczenie przez [PageSpeed Insights](https://pagespeed.web.dev) + Lighthouse w DevTools. Zapisujesz aktualne LCP/INP/CLS, TBT, rozmiar strony. To punkt bazowy dla pomiarów. Równolegle – WebPageTest do analizy waterfall. **Dzień 2-3 – obrazki.** Wszystkie JPG/PNG konwertujesz do WebP (masowo przez `cwebp` CLI lub Squoosh.app). Dodajesz atrybuty `width`/`height` do wszystkich `![]()` (walka z CLS). Obrazek hero – z `fetchpriority="high"` i preload w ``. Pozostałe – `loading="lazy"`. **Dzień 4 – CSS/JS.** Minifikacja (jeśli jeszcze nie zrobiona). Usunięcie nieużywanego CSS przez PurgeCSS. Skrypty, które nie są potrzebne na pierwszym ekranie – z `defer`. Analityka i liczniki – asynchronicznie lub po `DOMContentLoaded`. **Dzień 5 – CDN i HTTP/3.** Podłączasz Cloudflare (jeśli jeszcze nie ma) – za darmo, 5 minut. Włączasz Brotli, HTTP/3, Auto Minify, Rocket Loader (ostrożnie – może łamać JS). Konfigurujesz cache rules dla statyki (1 rok dla assets z hashem w nazwie). **Dzień 6-7 – finisz.** Ponowne przepuszczenie przez PageSpeed. Punktowe poprawki pozostałych problemów: third-party skrypty w iframe, fonty z font-display, usunięcie zbędnych preconnect. Końcowy pomiar. Jeśli 90+ Mobile – cel osiągnięty. ## 7 typowych błędów Widziałem te grabie regularnie – u klientów po poprzednim wykonawcy lub po samodzielnych próbach. 1. **Optymalizować Desktop, zapomnieć o Mobile.** Mobile-first indexing od 2019. Google ranguje na podstawie wersji mobilnej. Desktop 95 + Mobile 45 = jest rankowany jak 45. 2. **Testować tylko w Lighthouse, nie patrzeć na field-data.** Lighthouse to dane laboratoryjne. Search Console pokazuje realne CWV u rzeczywistych użytkowników. Mogą się różnić. 3. **„Pomaga plugin WP-Optimize, instalujemy".** Wtyczki optymalizujące często konfliktują, robią rzeczy nieprzewidywalne. Lepiej jedna porządnie skonfigurowana niż trzy „pomagające" sobie nawzajem. 4. **Lazy load obrazka hero.** Największy błąd. Lazy load dla obrazka powyżej fold = zwiększenie LCP. Lazy load – tylko dla obrazków poniżej pierwszego ekranu. 5. **Ciężkie fonty bez preload i font-display.** Font 800 z obsługą 5 języków = 200KB. Bez font-display: swap – biały ekran 1-2 sekundy. Z preload – LCP się skraca. 6. **Third-party skrypty w head.** Yandex.Metrika + Google Analytics + Facebook Pixel + Hotjar + ... w head synchronicznie – TBT (Total Blocking Time) jedzie do czerwonej strefy. Przenieś do footera lub asynchronicznie. 7. **Ignorować Server-Side performance.** TTFB (Time to First Byte) – często problem po stronie serwera: wolny PHP, niezoptymalizowane zapytania SQL, brak cache na serwerze. Optymalizacja samego klienta nie pomoże, jeśli serwer sam odpowiada przez 2 sekundy. **Dobry znak, że optymalizacja działa:** po 28 dniach Search Console w sekcji Core Web Vitals przełącza strony z „Poor" / „Needs improvement" na „Good". Nie momentalnie – dane CrUX są zbierane przez 28-dniowe rolling window. ## Częste pytania Po co dążyć do PageSpeed 100/100? Nie trzeba dążyć do 100/100 za wszelką cenę. Wynik powyżej 90 (Mobile) daje już maksimum tego, co Google bierze pod uwagę przy rankingu. 95-100 to bardziej kwestia prestiżu i dobrych Core Web Vitals w Search Console. Realny cel to wejść w zieloną strefę: LCP < 2.5s, INP < 200ms, CLS < 0.1. To jest to, co Google uwzględnia jako czynnik rankingowy od 2021 roku. Czym są Core Web Vitals w prostych słowach? Trzy metryki, które Google mierzy u rzeczywistych użytkowników: LCP (Largest Contentful Paint) – jak szybko pojawia się główna treść, INP (Interaction to Next Paint) – jak szybko strona reaguje na kliknięcia/dotknięcia, CLS (Cumulative Layout Shift) – czy układ strony nie skacze podczas ładowania. Od 2024 INP zastąpił FID. Co ważniejsze – Mobile czy Desktop? Mobile. Google stosuje mobile-first indexing – ranguje na podstawie wersji mobilnej. Warto trzymać Mobile PageSpeed powyżej 80, idealnie – powyżej 90. Desktop zwykle podciąga się sam, jeśli wersja mobilna jest zoptymalizowana. Ile czasu zajmuje optymalizacja do 90+? Zależy od punktu startowego i stacka. Landing na statyce: 1-3 dni. Strona korporacyjna na Joomla/WordPress: 1-2 tygodnie. Sklep internetowy z ciężką logiką: 2-4 tygodnie. Jeśli startujesz z 30-40 punktami Mobile – miesiąc jest realny. Jeśli z 60-70 – tydzień. Czy PageSpeed wpływa na konwersję? Bezpośrednio. Według danych Google i Amazon: +1 sekunda ładowania = -7% konwersji w e-commerce. Dla landingów mniej: +1s = -3-5%. Ponadto wolne strony otrzymują mniej powtórnych wizyt: użytkownik zapamiętuje, że „u nich długo się ładuje" i nie wraca. --- --- title: "Headless CMS vs tradycyjny CMS w 2026: co wybrać" url: https://tema.name/pl/blog/headless-vs-tradycyjny-cms-2026.html language: pl description: "Headless CMS vs tradycyjny CMS 2026: różnice, przypadki użycia. Strapi/Sanity/Contentful vs Joomla/WordPress, błędy, FAQ." date_published: 2026-05-30 date_modified: 2026-05-30 --- Wybór stosu 30 maja 2026 · 11 min czytania · Autor: Artem # Headless CMS vs tradycyjny CMS w 2026: co wybrać Wybór jest prosty: **tradycyjny CMS (Joomla/WordPress)** pokrywa 80% zadań biznesowych — strony lądujące, witryny firmowe, blogi, sklepy do 5 000 SKU, katalogi B2B. Czas wdrożenia: **2–4 tygodnie**, koszt 1× bazy, redaktor klika WYSIWYG. **Headless (Strapi/Sanity/Contentful)** opłaca się dopiero, gdy masz wiele kanałów frontend (web + mobile + kioski + smartwatch), zespół minimum 3 osoby (backend + 2× frontend) i budżet 2–3× wyższy. W zamian: 95–100 PageSpeed od ręki, pełna swoboda projektowa, brak ograniczeń motywów. Krzywa uczenia dla redaktorów stromsza, każda strona wymaga developera. Migracja z WP/Joomla na headless: **4–10 tygodni** i 15 000–60 000 zł. W artykule — porównanie po 8 kryteriach i 7 typowych błędów migracji. **W artykule** 1. [Czym jest headless CMS](#what-is) 2. [Stos i architektura – porównanie](#stack) 3. [Komu odpowiada które podejście](#use-cases) 4. [Strapi vs Sanity vs Contentful](#tools) 5. [7 typowych błędów](#mistakes) 6. [Częste pytania](#faq) ## Czym jest headless CMS W tradycyjnym CMS-ie (Joomla, WordPress, Drupal) są trzy warstwy sztywno ze sobą powiązane: **panel administracyjny**, w którym redaktorzy piszą treści, **baza danych**, w której są one przechowywane, oraz **motyw (szablon)**, który renderuje strony. Zmieniasz szablon – zmieniasz design. Zmieniasz CMS – zmieniasz wszystko. ~5% udział headless wśród wszystkich stron CMS w 2026 3-6tyg czas migracji z tradycyjnego CMS na headless 95+ typowy PageSpeed Mobile dla stron Jamstack 2-3× wyższy koszt rozwoju headless vs tradycyjny CMS W **headless CMS** pozostają tylko panel administracyjny i baza. Frontend – twój własny, w dowolnej technologii. CMS udostępnia treści przez REST lub GraphQL API. Frontend developer pobiera dane z API i renderuje strony tak, jak chce. Prosta analogia: tradycyjny CMS to samochód z gotowym nadwoziem. Headless to podwozie z silnikiem, nadwozie montujesz sam pod swoje potrzeby. Elastyczność większa, ale i pracy więcej. ## Stos i architektura – porównanie | Parametr | Tradycyjny CMS (Joomla, WP) | Headless CMS | | --- | --- | --- | | Co zawiera | Panel + BD + motywy frontu | Panel + BD + API. Front osobno. | | Kto renderuje strony | Motyw CMS (szablony PHP) | Dowolny front: React, Vue, Astro, Next.js | | Kto potrzebny w zespole | 1 fullstack developer | Frontend + backend (lub 1 fullstack) | | Szybkość ładowania | 60-85 PageSpeed Mobile z pudełka | 95-100 (renderowanie statyczne) | | SEO | Z pudełka, wtyczki | Własnoręcznie, ale kontrola większa | | Wiele kanałów | Tylko web | Web + mobile + cyfrowe ekrany + e-mail | | Koszt rozwoju | Baza (1×) | 2-3× bazy | | Koszt utrzymania | Aktualizacje wtyczek | Aktualizacja frontu + CMS osobno | | Krzywa uczenia dla redaktora | Prosta, przyzwyczajenie | Podobna, ale „oderwana” od finalnego wyglądu | **Najważniejsze:** headless to nie „ulepszenie” tradycyjnego CMS, lecz inna architektura z innymi kompromisami. Zyskujesz na elastyczności i szybkości – tracisz na prostocie utrzymania i koszcie rozwoju. ## Komu odpowiada które podejście ### Kiedy wybierać tradycyjny CMS (Joomla, WordPress) - **Strona korporacyjna 10-50 podstron.** Zespół 1-3 redaktorów, jednorazowy rozwój, minimum personalizacji. Joomla lub WordPress zamykają 95% zadań. - **Blog lub portal medialny.** WordPress to de facto standard projektów contentowych. Ogromny ekosystem, wygodny edytor dla osób nietechnicznych. - **Mały e-commerce.** WooCommerce (WP) lub VirtueMart/HikaShop (Joomla) do 5000 SKU działają dobrze. - **Lokalny mały zespół.** Jeśli nie masz frontend developera i nie planujesz go zatrudniać – tradycyjny CMS wygrywa. - **Szybki start z ograniczonym budżetem.** Z gotowych motywów + wtyczek uruchomić landing w 1-2 tygodnie – łatwiej na tradycyjnym CMS-ie. ### Kiedy headless jest uzasadniony - **Kilka kanałów konsumpcji.** Treść trafia na stronę + aplikację iOS + aplikację Android + cyfrowe ekrany w sklepach + newslettery. Jedno źródło prawdy przez API. - **Zespół już pracuje na React/Vue/Next.** Po co uczyć się nowego motywu CMS, skoro frontend developer może renderować w Next.js lub Astro. - **Strony krytyczne pod kątem wydajności.** Jeśli każde 0,1 sekundy ładowania = miliony złotych przychodu (duży e-commerce, reklama z drogim CPC). - **Złożona personalizacja UI.** Gdy standardowe motywy nie wystarczają, potrzebne są interaktywne dashboardy, niestandardowe widgety, dane w czasie rzeczywistym. - **Zespół 5+ redaktorów z różnymi rolami.** Dobre headless CMS mają elastyczny system uprawnień, wieloetapowy workflow, wersjonowanie. **Nie myl „headless” z „Jamstack”:** headless to architektura CMS (bez własnego frontu). Jamstack to podejście do deploymentu: statyka + JS + API. Można być headless bez Jamstack (renderowanie po stronie serwera przez SSR) i można być Jamstack bez headless (statyka bez CMS w ogóle). ## Strapi vs Sanity vs Contentful Trzy najpopularniejsze headless CMS na rynku. Czym się różnią. | Parametr | Strapi | Sanity | Contentful | | --- | --- | --- | --- | | Hosting | Self-hosted (Docker, VPS) | Managed (cloud) | Managed (cloud) | | Open source | Tak, licencja MIT | Studio – open source, backend – nie | Nie | | Cena (free) | Bezpłatnie (tylko hosting) | Do 10K dokum., 100K zapytań/mies. | Do 50K wpisów | | Cena (paid) | ~60-200 USD/mies. (cloud) | 99-1000+ USD/mies. | 300+ USD/mies. | | Edytor | Podstawowy, dobry | Bardzo personalizowalny (Studio) | Dojrzały, dla zespołów | | API | REST + GraphQL | GROQ + GraphQL | REST + GraphQL | | Komu odpowiada | Zespoły z DevOps, kontrola | Startupy, elastyczność, szybki start | Enterprise, duże zespoły | Moje rekomendacje wg scenariuszy: - **MVP lub prototyp, ograniczony budżet.** Sanity free tier. Start w 2-3 dni, schematy edytora w kodzie, free wystarczy na długo. - **Projekt korporacyjny, elastyczność + kontrola.** Strapi self-hosted na własnym VPS lub Strapi Cloud. Pełna kontrola nad danymi. - **Enterprise z zespołem i compliance.** Contentful. SLA, wsparcie, bezpieczeństwo z pudełka, gotowa integracja z platformami marketingowymi. ## 7 typowych błędów 1. **Wybrać headless „bo modne”.** Jeśli masz 5 redaktorów i jedną stronę – tradycyjny CMS częściej się opłaca. Headless jest uzasadniony architektonicznie, nie „bo na Twitterze chwalą”. 2. **Niedoszacować koszt rozwoju frontu.** Headless CMS to tylko 30% systemu. 70% to aplikacja frontend. Budżet na frontend developera i jego utrzymanie często jest większy niż na samego CMS-a. 3. **Zapomnieć o preview.** Redaktor chce widzieć, jak wpis będzie wyglądał. Na tradycyjnym CMS to działa „z automatu”. Na headless preview trzeba budować osobno (Next.js Preview Mode, Sanity Visual Editing). 4. **Ignorować i18n od początku.** Jeśli później potrzebna będzie wielojęzyczność, migracja jest trudniejsza. Zakładaj wsparcie już w architekturze – przez locale w schematach. 5. **Nie skonfigurować cache'owania API.** Każde zapytanie do headless API to żądanie HTTP. Pod szczytowym obciążeniem bez cache CDN API pada. Cloudflare R2 / Vercel ISR / Astro static – rozwiązanie. 6. **Używać headless dla zespołu bez frontend developera.** Jeśli nie masz stałego frontu – za 6 miesięcy nie będzie komu aktualizować Next.js i Reacta. CMS zamienia się w „wiszący projekt”. 7. **Od razu wybierać tier enterprise.** Contentful Pro za 300 USD/mies. to przesada dla projektu na 1000 podstron. Zaczynaj od free / starter, przechodź wraz z rozwojem. **Wariant pośredni:** „WordPress jako headless”. WordPress pozostaje jako CMS (znajomy edytor dla zespołu), ale frontend budowany jest w Next.js lub Astro przez WP REST API / WPGraphQL. Otrzymujesz 80% zalet Jamstack bez bólu migracji. Dobry kompromis dla blogów i stron medialnych. ## Częste pytania Czym jest headless CMS w prostych słowach? To CMS, który ma tylko backend (panel administracyjny + API), a frontend tworzysz samodzielnie – na dowolnym frameworku (React, Vue, Astro, Next.js). W tradycyjnym CMS-ie typu Joomla czy WordPress panel administracyjny i frontend są ze sobą sztywno powiązane. W headless otrzymujesz treści przez REST lub GraphQL i renderujesz je tak, jak chcesz. Plus: elastyczność, szybkość, wiele kanałów. Minus: potrzebny jest frontend developer. Kiedy headless jest lepszy od tradycyjnego CMS? Kiedy masz kilka kanałów konsumpcji treści (strona + aplikacja mobilna + cyfrowe ekrany + e-mail), kiedy potrzebna jest maksymalna szybkość (podejście Jamstack), kiedy zespół pracuje z nowoczesnymi frameworkami frontendowymi lub kiedy potrzebna jest precyzyjna personalizacja UI bez ograniczeń motywu CMS. Dla typowej strony korporacyjnej lub bloga tradycyjny CMS częściej wystarcza. Ile kosztuje headless CMS? Zależy od wyboru. Strapi self-hosted – bezpłatnie (tylko hosting). Sanity Free tier – do 10K dokumentów i 100K zapytań API miesięcznie bezpłatnie. Contentful Free – do 50K wpisów. Plany płatne Sanity/Contentful: 99-300 USD/mies. Joomla/WordPress – 0 USD (tylko hosting). Headless jest zwykle droższy, ponieważ potrzebny jest frontend developer plus usługa CMS. Strapi vs Sanity vs Contentful – co lepsze? Strapi – self-hosted, open source, maksymalna kontrola, idealny dla zespołów z DevOps. Sanity – managed, elastyczne schematy danych, świetny edytor (Sanity Studio). Contentful – najbardziej dojrzała opcja enterprise, więcej wtyczek i integracji, ale droższy. Dla prototypów i startupów – Sanity. Dla dużego biznesu – Contentful. Dla tych, którzy chcą mieć wszystko u siebie – Strapi. Czy można przenieść WordPressa na headless? Tak. Można zachować WordPressa jako headless – ma on REST API oraz wtyczkę WPGraphQL. Daje to wariant przejściowy: zespół nadal pracuje w panelu WP, a frontend budowany jest w Next.js lub Astro. To często optymalna ścieżka migracji – nie psuje procesów, a daje wydajność Jamstack. Czas migracji – 3-6 tygodni w zależności od objętości. --- ## Author & contact - Author: Artem - Job: Web developer and AI automation specialist - Languages: Russian, English, German, Polish - Telegram: https://t.me/tstels1 - Website: https://tema.name/ - Sitemap: https://tema.name/sitemap.xml - llms.txt (overview): https://tema.name/llms.txt - About (RU): https://tema.name/o-mne/ - About (EN): https://tema.name/en/about/ - About (DE): https://tema.name/de/ueber-mich/ - About (PL): https://tema.name/pl/o-mnie/