TL;DR
- Добрата оферта за изработка на сайт не започва с броя страници, а с проблема, който сайтът трябва да реши.
- „10 страници + WordPress + responsive + форма“ описва технически пакет, но не непременно реалния обхват на конкретния бизнес.
- При съществуващ сайт трябва да се анализират съдържанието, URL адресите, SEO, потребителските пътеки, администрацията и зависимостите преди да се определят срок и цена.
- Планира се не само какво вижда посетителят, а и как екипът ще сменя цени, ще добавя услуги, промоции, съдържание и ще обработва запитвания или поръчки.
- При малък стандартен сайт готов пакет може да е напълно подходящ. При по-сложен проект точната оферта изисква discovery и реално дефиниране на scope-а.
От какво трябва да започне една оферта за изработка на сайт?
От бизнес проблема и начина, по който сайтът трябва да работи — не от въпроса дали ще има 8, 12 или 30 страници.
Броят страници е резултат от анализа. Не е самият анализ.
Когато клиентът казва „искам нов сайт“, зад това могат да стоят напълно различни проблеми:
- хората не намират правилната услуга;
- има трафик, но няма запитвания;
- цените са трудни за откриване;
- една информация трябва да се редактира на няколко места;
- администрацията е прекалено сложна;
- мобилната версия затруднява потребителите;
- старият сайт е натрупвал страници и категории с години;
- рекламният трафик попада на неподходящи landing pages;
- предстои eCommerce, но настоящата структура не го позволява;
- SEO видимостта трябва да бъде запазена при редизайна.
Затова „искам нов сайт“ е начало на разговор, а не техническа спецификация.
При професионалната изработка на сайт първо трябва да стане ясно каква система всъщност изграждаме и какво трябва да постигне тя.
Защо броят страници не е достатъчен, за да се определи цената?
Защото две страници могат визуално да изглеждат сходно и зад тях да стоят коренно различни количества работа.
Страница „Услуга“ може да бъде обикновен текст с изображение. Но може и да използва структурирани данни за:
- варианти на услугата;
- различни цени;
- категории;
- проблеми, които решава;
- зони или приложения;
- свързани специалисти;
- FAQ;
- видео;
- свързани статии;
- текущи промоции;
- CTA според типа потребител.
Същото важи за понятия като „онлайн плащане“, „контактна форма“, „блог“ или „търсачка“.
Какво може да се крие зад едно изречение в офертата?
| Кратко описание | Какво реално трябва да бъде изяснено |
|---|---|
| „Контактна форма“ | Полета, context, получатели, spam protection, SMTP, success flow, Thank You страница, tracking, поведение при грешка |
| „Онлайн плащане“ | Какво се купува, варианти, checkout, gateway, failed payment, refund, partial refund, имейли, роли |
| „Responsive сайт“ | Навигация, sticky CTA, touch targets, форми, таблици, checkout, finder, четимост и performance на телефон |
| „SEO оптимизация“ | Search intent, URLs, taxonomy, internal links, schema, canonical, sitemap, index/noindex и redirect map |
| „Блог“ | Автори, категории, related content, update dates, FAQ, CTA, източници и връзки към услуги |
| „Промоции“ | Начална и крайна дата, promo price, свързани услуги, автоматично изтичане, архив и едновременни кампании |
Точно затова статията ни за цените за изработка на сайт разглежда бюджетите отделно. Преди да говорим за конкретна цена, трябва да знаем какво реално влиза в проекта.
Как се анализира съществуващ сайт преди новата оферта?
При редизайн първата задача не е да копираме старото съдържание в по-модерен дизайн.
Трябва да разберем какво вече съществува.
Одитът може да включва:
- всички URL адреси и типове страници;
- услуги, продукти и категории;
- блог съдържание;
- меню и навигация;
- ценова структура;
- форми и conversion paths;
- mobile UX;
- вътрешно търсене;
- checkout и клиентски профили;
- текущата CMS структура;
- технически зависимости;
- Search Console и органична видимост;
- analytics и поведение на потребителите;
- стари landing pages;
- дублирано или остаряло съдържание;
- backlinks към URL адреси, които предстои да бъдат променени.
Следва content inventory.
За всяка важна страница трябва да бъде взето решение:
Запазваме / Обединяваме / Пренасочваме / Премахваме.
Новият сайт не трябва да бъде старият информационен хаос с нови цветове.
Това е и причината процесът по създаване на уеб сайт да включва много повече от дизайн и development.
User journey не е същото като sitemap
Sitemap-ът показва кои страници съществуват.
User journey показва как човек реално стига до решение.
Например sitemap може да изглежда така:
Home → Услуги → Услуга X → Контакти
Но реалният човек може да премине през:
Google → статия за конкретен проблем → възможни решения → услуга → цена → запитване
Друг потребител може да дойде от реклама:
Google Ads → конкретна услуга → вариант → checkout → покупка
Трети може да знае проблема си, но не и името на услугата. Четвърти търси директно цена. Пети иска първо консултация.
Затова при по-сложни сайтове менюто невинаги е достатъчно. Може да е необходим finder, търсене, филтриране по проблем, категория или друг тип съдържание.
Трябва да се планира и пътят на администратора
Това често остава невидимо в предварителния разговор за сайта, въпреки че определя колко лесно ще се управлява системата години наред.
Добрата архитектура трябва да отговори на въпроси като:
- Как се добавя нова услуга?
- Откъде се променя цената?
- Как се създава промоция?
- Как се добавя нов вариант?
- Как се сменя специалист или автор?
- Как се задават начало и край на анонс?
- Как се добавя видео?
- Как се обработва поръчка?
- Как се прави refund?
- Как се редактира SEO информация?
Администраторът не трябва да се пита: „Къде още трябва да направя същата промяна?“
Цената например трябва да има ясен source of truth. Ако една и съща стойност се въвежда ръчно на три различни страници, рано или късно те ще започнат да си противоречат.
Затова content model-ът се планира преди дизайна, а данните по възможност се отделят от начина, по който се визуализират.
Това позволява един и същ content да бъде показан в различни компоненти, без да бъде въвеждан многократно.
Именно тук е една от съществените разлики между използването на готова техническа основа и заместването на целия анализ с готов шаблон — тема, която разглеждаме подробно в материала за шаблонен WordPress сайт и професионален уебсайт.
Как eCommerce, формите и цените променят реалния scope?
„Ще има WooCommerce“ не е eCommerce спецификация.
Преди да бъде оценен такъв проект, трябва да знаем:
- какво точно се продава;
- има ли варианти;
- има ли физическа доставка;
- как се плаща;
- какво се случва при неуспешно плащане;
- как се променя поръчка;
- кога се прави пълен или частичен refund;
- какви имейли получава клиентът;
- кой от екипа има право да управлява поръчките.
И процесът не приключва с успешната покупка.
В реалния бизнес може да се окаже, че клиентът трябва да премине към друг вариант, да доплати, да получи частично възстановяване или част от процеса да продължи във физически обект.
Същото важи за формите.
„Контактна форма“ не казва какъв context трябва да запише тя, кой получава информацията, какво вижда човекът след изпращането и как бизнесът разбира, ако доставката на имейла се провали.
SEO и бъдещата реклама също се планират преди development
SEO не започва с инсталирането на plugin след завършването на сайта.
Още при архитектурата трябва да бъдат изяснени:
- search intent;
- основни и supporting страници;
- URL структура;
- taxonomy;
- internal linking;
- canonical логика;
- index/noindex правила;
- sitemap;
- structured data;
- старите и новите URL адреси.
При съществуващ сайт това е още по-важно. Ако страници с натрупана органична видимост изчезнат без правилно mapping и redirects, новият дизайн може да струва загуба на SEO актив, изграждан с години.
Сайтът трябва да бъде подготвен и за бъдещите marketing канали, без това да означава, че разработката на сайта и управлението на рекламите са една и съща услуга.
Рекламата може да започне месеци след сайта. Но ако предварително не са предвидени подходящи landing pages, CTA, Thank You flows, conversion points, форми и стабилни URL адреси, често се налага нова разработка точно когато бизнесът иска да стартира кампаниите.
Това важи както за Google Ads, така и за Meta Ads.
По същата причина в AdwayCreative Growth Framework разглеждаме сайта, трафика, tracking-а и оптимизацията като свързани части на една система, а не като независими задачи.
Реален пример: колко голям може да бъде проектът зад думите „нов сайт“?
В един от последните ни redesign проекти започнахме с привидно прост проблем: настоящият сайт беше труден както за използване, така и за администриране.
След инвентаризацията се оказа, че системата съдържа около 80 основни услуги, над 70 проблема и състояния, различни зони, категории, промоции, десетки статии и стотици URL адреси.
Това не означава, че всеки сайт има подобен мащаб. Показва колко различен реален обем може да стои зад едно и също изречение: „Искаме нов сайт“.
Преди да се определи scope-ът, трябваше да бъдат обсъдени взаимосвързани решения:
- как потребителят ще намира правилната услуга;
- как ще се управляват цените;
- как ще работят промоциите;
- как администраторът ще въвежда информацията само веднъж;
- кога има покупка и кога запитване;
- какво се случва след плащане;
- кои URL адреси се запазват;
- кои се обединяват;
- как работят redirects;
- как системата може да се развива без нов rebuild след две години.
Едва след тези решения има смисъл да бъде написана точна оферта.
Означава ли това, че готовите пакети за сайтове са лоши?
Не.
На пазара има различни напълно валидни модели на работа.
При малък и стандартизиран проект предварително дефинирана тема и набор от функционалности могат да бъдат разумно решение. Те позволяват по-бързо изпълнение и по-нисък бюджет.
Разликата е в това дали проектът реално се побира в пакета.
| По-стандартизиран проект | Проект, който изисква по-дълбоко discovery |
|---|---|
| Малък брой ясни услуги | Голям или сложен каталог |
| Няма стара SEO структура за миграция | Стотици съществуващи URL адреси |
| Една проста форма | Различни enquiry flows |
| Без eCommerce логика | Плащания, варианти, refunds, роли |
| Прост admin workflow | Цени, промоции и relations между много entity types |
| Ограничени интеграции | CRM, APIs, payment systems или други зависимости |
Проблемът не е дали се използват WordPress, Elementor, готова тема или друга основа.
Проблемът възниква, когато техническата основа замести анализа и пакетът бъде представен като индивидуално проектирана система, без да е проверено дали покрива реалния бизнес.
След завършване на проекта клиентът трябва и да може да провери какво реално е получил — за което сме подготвили отделен checklist за проверка на изработен сайт.
Колко време отнема да се подготви добра оферта за сайт?
Няма една универсална стойност.
Малък сайт с ясно съдържание и стандартна функционалност може да бъде оценен сравнително бързо.
При съществуващ корпоративен сайт, голям каталог или eCommerce проект обаче:
- discovery разговорите могат да бъдат няколко;
- inventory и audit могат да отнемат часове или дни;
- съдържанието трябва да бъде mapping-нато;
- могат да бъдат открити технически зависимости, които не са били видими в началото;
- архитектурата може да се промени след откриването на нови user или admin scenarios.
Затова при сложен проект самото подготвяне на коректна оферта може да изисква значителна част от работен ден или няколко дни анализ и уточнения.
Това не е административна загуба на време.
Точно този етап намалява риска от ситуацията:
„Това не го бяхме включили в цената.“
Какво трябва да е ясно, преди да има scope, срок и цена?
Преди финалната оферта трябва да има достатъчно яснота поне за:
- ☐ бизнес целта и основния проблем;
- ☐ типовете потребители;
- ☐ основните user journeys;
- ☐ admin workflows;
- ☐ content model;
- ☐ information architecture;
- ☐ функционалностите;
- ☐ mobile UX;
- ☐ search/finder логиката, ако е нужна;
- ☐ ценова архитектура;
- ☐ eCommerce и post-purchase процесите;
- ☐ формите и enquiry flows;
- ☐ legal/privacy изискванията, които трябва да бъдат осигурени;
- ☐ SEO архитектурата;
- ☐ migration и redirect логиката;
- ☐ нуждите на бъдещите рекламни landing pages;
- ☐ performance изискванията;
- ☐ ролите и правата;
- ☐ техническите интеграции;
- ☐ content migration;
- ☐ QA обхвата;
- ☐ отговорностите на клиента и изпълнителя;
- ☐ hosting, licenses, SaaS и други third-party разходи;
- ☐ какво означава поддръжка след launch.
Едва тогава могат коректно да се определят:
scope → dependencies → срок → цена → exclusions.
Ако цената е определена преди тези въпроси да бъдат изяснени, най-често тя е цена на предварително дефиниран пакет, а не оценка на конкретния проект.
И понякога това е напълно достатъчно.
Ключът е клиентът да знае кое от двете купува.
Добрата оферта всъщност е резултат от взети решения
Клиентът не плаща просто за броя страници.
Стойността при по-сложен проект идва от решенията, които трябва да бъдат взети, преди страниците да бъдат изградени: как се организира информацията, как хората я намират, как екипът я управлява, как се измерват резултатите и как системата остава използваема след години.
Когато тази работа бъде направена предварително, офертата вече не е предположение.
Тя се превръща в описание на конкретен проект.
Искате оферта за нов сайт?
Ако планирате нов сайт или редизайн, изпратете ни информация за бизнеса, настоящия сайт, основния проблем и резултата, който искате да постигнете.
Ще започнем от това какво трябва да реши системата, преди да определяме колко страници трябва да има.
Често задавани въпроси за оферта за изработка на сайт
Може ли да получа цена за сайт само по броя страници?
При малък стандартен сайт — понякога да. При по-сложен проект броят страници не показва функционалностите, съдържателния модел, администрацията, SEO миграцията, интеграциите и QA обхвата.
Защо агенцията задава толкова много въпроси преди офертата?
За да установи какво реално трябва да бъде изградено. Без това част от функционалностите могат да останат извън scope-а или да се появят като непредвидени разходи след старта.
Плаща ли се само за дизайна и програмирането?
Не непременно. При професионален проект значителна част от работата може да бъде анализ, UX, архитектура, съдържание, migration planning, SEO, tracking, QA и подготовка на администрацията.
Готовата WordPress тема означава ли непрофесионален сайт?
Не. Готова тема или framework могат да бъдат отлична техническа основа. Важното е решението да бъде адаптирано към бизнеса и да не замества необходимия анализ.
Кога е достатъчна пакетна цена за сайт?
Когато проектът е малък, изискванията са ясни, функционалностите са стандартни и няма сложна миграция, eCommerce логика или множество интеграции.
Трябва ли SEO да се обсъжда преди разработката?
Да. URL структурата, taxonomy, internal linking, indexation и redirects влияят върху самата архитектура на сайта и са особено важни при редизайн на съществуващ домейн.






