# Безплатен сайт за ВиК услуги: реален case study от програмата ни Category: Програма за безплатен сайт > Първи проект от програмата ни за безплатен сайт: как изградихме ВиК сайт с ясни услуги, директен контакт, реализирани обекти и техническа SEO основа. **Проект:** ВиК Решения **Сайт:** [otpushvane-kanali.com](https://otpushvane-kanali.com/) **Сфера:** ВиК услуги в София и областта **Разработка:** DIMITROV.code **Технологии:** Next.js, Sanity **Програма:** 0 € за договорения development scope **Кандидатстване:** одобрен проект от септември 2026 г. **Време за изработка:** 4 дни Когато започнахме работа по [otpushvane-kanali.com](https://otpushvane-kanali.com/), бизнесът нямаше собствен уебсайт. Нямаше стара структура, страници или съдържание, които просто да прехвърлим в нов дизайн. Трябваше да започнем от основния въпрос: каква информация е необходима на човек, който в този момент търси ВиК услуга? Проектът беше сред одобрените кандидатури от септември 2026 г. в [програмата ни за безплатна изработка на сайт](https://evtinwebsite.com/bezplaten-uebsait). Вместо да направим стандартна онлайн визитка с няколко общи секции, решихме да изградим сайта около реалните ситуации, с които потенциалният клиент идва: теч, запушен канал, ремонт, монтаж или друг конкретен ВиК проблем. Оттам подредихме архитектурата, отделните услуги, начина за контакт и системата за публикуване на реализирани обекти. Изградихме проекта с Next.js и Sanity, добавихме техническа SEO основа и го подготвихме така, че съдържанието да може да се развива и след първоначалното публикуване. ## Започнахме от въпросите на клиента, а не от дизайна При локална ВиК услуга човек рядко отваря сайта просто за да разглежда. Обикновено има конкретен проблем и иска бързо да разбере няколко неща: предлагаме ли подходящата услуга, работим ли в неговия район, има ли реални примери от извършена работа и как може да се свърже. Използвахме точно тези въпроси като основа за структурата на сайта. Началната страница първо показва каква е услугата и къде се предлага. След това насочва посетителя според проблема му към конкретна услуга, реализирани обекти или директен контакт. Вместо всички ВиК дейности да стоят в един дълъг общ списък, отделихме услугите в самостоятелни страници с конкретно съдържание. Например човек с проблем със запушен канал може да тръгне директно от „Имам запушен канал“, да стигне до страницата за отпушване на канали, да разбере какво включва услугата и оттам да се обади. За нас това беше по-смислена отправна точка от класическата структура „Начало → За нас → Услуги → Контакт“. Сайтът трябваше да следва начина, по който човек мисли, когато има проблем, а не просто начина, по който обикновено се подрежда фирмено меню. ## Направихме директния контакт част от целия път При ВиК услуга телефонът не е просто още един елемент в контактната страница. В много случаи това е най-важното действие в целия сайт. Затова не оставихме номера само във футъра. Поставихме ясен начин за обаждане още в началния екран, повторихме го в страниците на услугите и добавихме отделна контактна страница с информация какво е полезно клиентът да уточни още при първия разговор. На мобилен телефон добавихме и плаващ бутон за обаждане. Решихме обаче той да не стои постоянно върху съдържанието. Показва се след началната част на страницата, а когато посетителят стигне до контактната секция или футъра, го скриваме, защото там вече има достатъчно видим начин за връзка. ![Преглед на уебсайта ВиК услуги София на десктоп и мобилно устройство: начален екран с телефон за връзка, бутон „Обади се" и снимка на водопроводчик при работа](https://cdn.sanity.io/images/l2hfyff5/production/74a7c9a89a17f2606443d3f6c9682115a7867bf8-1920x1440.webp) Това е малък UX детайл, но за такъв тип сайт има значение. Целта ни не беше просто телефонният номер да присъства, а човекът да може да стигне до него лесно в момента, в който вече е разбрал, че услугата е подходяща за неговия проблем. ![Мобилен сайт с бутон за обаждане в началния екран и плаващ телефонен бутон при скрол](https://cdn.sanity.io/images/l2hfyff5/production/b7fdd2d56db8ac9a17aed8ecee0b9b2167eadff2-1920x1440.png) Контактната страница също подредихме като част от процеса, а не като формалност. Добавихме насоки каква информация е полезно да бъде дадена по телефона и уточнихме, че посещението на конкретен адрес се договаря при разговора. Така още преди самото обаждане сайтът помага да има по-ясен контекст и за двете страни. ## Реализираните обекти не останаха просто галерия Първоначалното желание на клиента беше сравнително просто: място, където да качва снимки от извършена работа. Ние предложихме да надградим тази идея. Вместо реализираните обекти да останат само като обща галерия, предложихме всеки по-съдържателен случай да може да има собствена страница със снимки, видео, кратко описание и връзка към съответната услуга. Клиентът одобри подхода и така галерията се превърна в отделен тип съдържание, а не просто в колекция от изображения. ![Галерия с реализирани обекти и детайлна страница на един от тях](https://cdn.sanity.io/images/l2hfyff5/production/fbffc5a440089ad2df146e71153f7b0d8a6b114d-1920x1440.png) Причината беше практична. При локална услуга реалните обекти могат да дадат много повече контекст от общо твърдение от типа „имаме опит“. Посетителят може да види какъв проблем е решен, къде е извършена работата и към коя услуга се отнася конкретният случай. Това решение има и дългосрочна стойност за структурата на сайта. Всеки публикуван обект може да добавя нова релевантна страница с конкретен контекст за услуга, тип работа и локация. Това не гарантира по-добро класиране само по себе си, но дава повече реално съдържание, което търсачките могат да обхождат и свързват с останалата част от сайта. Изградихме обща секция за реализирани обекти с филтри и странициране, а за по-подробните случаи предвидихме отделни страници със снимки, видео и описание на извършеното. Всеки обект може да бъде свързан с конкретна услуга, а на началната страница показваме избрани проекти, когато има публикувано съдържание. За управлението на тези обекти избрахме Sanity. Причината беше практична: услугите са сравнително стабилна част от сайта и могат да останат в кода, докато реализираните обекти ще се добавят постепенно с нова работа. Това разделение ни позволи да оставим по-статичната структура под контрол в проекта, а съдържанието, което трябва да се обновява често, да бъде достъпно през CMS. Така нов обект може да бъде публикуван без редакция на React компонент или нов deployment само заради една снимка и описание. За нас това беше по-добро решение от обикновена галерия и по-смислено от вариант, при който целият сайт се управлява през CMS. Дадохме гъвкавост точно там, където клиентът реално ще я използва, а в същото време оставихме възможност сайтът да натрупва стойност с всеки нов публикуван обект. ## SEO архитектурата заложихме още при структурата на сайта Понеже проектът започна от нулата, имахме възможност да подредим техническата SEO основа още преди публикуването, вместо да я добавяме впоследствие върху вече готова структура. Направихме отделни адреси за основните услуги и реализираните обекти, а всяка важна страница получи собствено заглавие, описание и canonical адрес. Генерирахме `sitemap.xml`, който включва основните страници, услугите и публикуваните детайлни страници на обектите, а `robots.txt` сочи към актуалната карта на сайта. Домейнът, който избра клиентът, имаше по-стара история в Google, затова при пускането проверихме и старите адреси, които Search Console беше откривал преди този проект. Потвърдихме, че актуалният sitemap подава правилните URL-и, несъществуващите стари страници връщат 404, а старият `www` вариант води към предпочитания HTTPS адрес. Добавихме и структурирани данни според типа съдържание. Основната информация за сайта и бизнеса е описана чрез `WebSite` и `Plumber`, страниците на услугите използват `Service`, `BreadcrumbList` и `FAQPage`, а отделните реализирани обекти се свързват с услугата, към която се отнасят. За основните страници подготвихме и Markdown версии, свързани чрез `/llms.txt`. Гледаме на това като на допълнителен машинно четим слой върху същото съдържание, а не като на гаранция за по-добро класиране или присъствие в AI отговори. Целта ни беше проста: още при първото публикуване сайтът да има ясна структура за хората, търсачките и [системите, които обработват съдържанието автоматично](https://evtinwebsite.com/blog/mozhe-li-chatgpt-da-prochete-saita-ti-kakvo-vizhdat-ai-sistemite). ## Техническата реализация трябваше да остане бърза и лесна за поддръжка Изградихме сайта с Next.js App Router и разделихме началната страница на отделни секции, за да можем да развиваме проекта без всяка промяна да засяга цялата страница. За услугите използвахме обща структура, но отделни данни и съдържание за всяка услуга. Така запазихме последователен интерфейс, без да превръщаме страниците в копия една на друга. Sanity остана фокусиран върху съдържанието, което реално ще се променя често: реализираните обекти. Публикуваните записи могат да се използват в общата галерия, на началната страница и в самостоятелни детайлни страници, когато конкретният обект има достатъчно съдържание за това. След публикуването проверихме началната страница и с PageSpeed Insights. ![PageSpeed Insights проверка на началната страница на otpushvane-kanali.com, 8 октомври 2026 г. Лабораторният тест отчете 98 Performance на mobile и 100 на desktop.](https://cdn.sanity.io/images/l2hfyff5/production/fd8b69aa349b45f94ec19695562345eba78b0b4c-1920x1440.png) На 8 октомври 2026 г. лабораторният тест отчете: - **Performance: 98 на mobile** - **Performance: 100 на desktop** - **Accessibility: 100** - **Best Practices: 100** - **SEO: 100** Резултатите за Accessibility, Best Practices и SEO са 100 и при двата изгледа. Това е моментна лабораторна проверка на началната страница, затова не я използваме като обещание, че всяка вътрешна страница или всяко реално посещение ще даде същия резултат. Към момента на теста PageSpeed Insights не показваше и достатъчно данни от реални потребители, за да правим изводи за Core Web Vitals в реална употреба. За нас тестът беше най-вече проверка дали техническата основа, която сме изградили, не създава очевидни проблеми още при старта на проекта. ## Какво реално получи бизнесът от проекта Преди този проект бизнесът нямаше собствен уебсайт. След реализацията вече има публично място, в което услугите са разделени ясно, посетителят може да тръгне от конкретния си проблем, да разгледа примери от извършена работа и да стигне директно до контакт. Изградихме отделни страници за услугите, контактна логика с приоритет върху телефонното обаждане и система за публикуване на реализирани обекти. Добавихме и техническата основа, необходима сайтът да бъде обхождан и разбиран нормално от търсачки и други системи, които обработват съдържанието. Проектът вече е свързан с Google Search Console, за да можем да следим как страниците се откриват, индексират и представят в търсенето. Към момента обаче не бихме нарекли това SEO резултат. Самото добавяне в Search Console не означава автоматично индексиране, нито доказва ръст в посещенията или обажданията. Това, което можем да покажем сега, е конкретно: работещ production сайт, ясна структура на услугите, CMS за реализирани обекти, техническа SEO основа и измерено добро състояние на началната страница при лабораторния тест. По-интересната част започва след публикуването. Вече имаме техническата основа, върху която могат да се натрупват реални обекти, Search Console данни и наблюдения как хората използват сайта. ## Колко струва сайтът след изработката Безплатната изработка няма голяма стойност, ако след това бизнесът остане с постоянни разходи за услуги, които не са му необходими. Затова при този проект подбрахме инфраструктура, която позволява сайтът да работи с минимални текущи разходи. Към момента основните разходи изглеждат така: | Услуга | Текущ разход | За какво се използва | | --- | --- | --- | | Домейн otpushvane-kanali.com | $3.80 / първата година | Собственият адрес на сайта | | Cloudflare | 0 € | DNS и инфраструктурни функции | | Google Cloud | ~0 € / месец | Част от hosting/cloud инфраструктурата при текущото използване | | Sanity | 0 € | Управление на реализираните обекти | | Поддръжка от DIMITROV.code | 0 € за първите 30 дни | Техническа гаранция и отстраняване на проблеми в договорения обхват | _Основните разходи след изработката_ С други думи, безплатната изработка не е вход към задължителен платен абонамент след това. При сегашния размер и натоварване на проекта няма задължителен месечен абонамент за CMS или стандартната инфраструктура, която използваме. Няма задължителен абонамент и към DIMITROV.code. След изтичането на включените 30 дни техническа поддръжка клиентът не е обвързан с договор за поддръжка и не е длъжен да продължи да работи с нас. Проектът е изграден така, че бизнесът да запази контрол върху сайта и използваните услуги. Ако в бъдеще реши, може да продължи с нас, да поеме поддръжката сам или да възложи развитието на друг developer. Това беше едно от решенията, които взехме още при архитектурата. Не искахме да създадем сайт за 0 €, който след публикуването изисква няколко платени абонамента само за да остане онлайн. Разходите могат да се променят, ако бизнесът реши в бъдеще да бъдат добавени платени услуги, API интеграции или други външни системи. При текущия проект обаче постоянният инфраструктурен разход е практически сведен до стойността на домейна. Повече за това кои разходи са включени и кои остават външни можеш да видиш в [условията на програмата](https://evtinwebsite.com/bezplaten-uebsait/usloviya). ## Защо направихме този проект за 0 € Този сайт е реализиран като част от [програмата ни за безплатна изработка на сайт](https://evtinwebsite.com/bezplaten-uebsait), в която избираме ограничен брой реални бизнес проекти и поемаме договорения development scope на цена 0 €. Идеята ни не е да правим неограничена безплатна разработка или да създаваме сложни custom системи без ясен обхват. Търсим проекти, при които можем да решим конкретен бизнес проблем, да стигнем до реален production резултат и след това да покажем какви решения сме взели по пътя. При [otpushvane-kanali.com](https://otpushvane-kanali.com/) имахме точно такъв случай. Бизнесът започваше без собствен сайт, услугите можеха да бъдат структурирани ясно, а проектът имаше реална нужда от локално представяне, директен контакт и място за публикуване на извършена работа. За нас стойността на програмата е именно в такива проекти. Получаваме възможност да работим по реални казуси, да проверяваме решенията си в production среда и да натрупваме опит, който не идва от демо страници. Бизнесът от своя страна получава завършен работещ сайт в рамките на предварително определения обхват. Това е и причината след подобен проект да предпочитаме да публикуваме case study като този, вместо още една обща статия за самата програма. Реалният проект показва много повече от обещание какво бихме могли да направим. ## Какво ще следим след публикуването Пускането на сайта не е моментът, в който можем честно да кажем дали той носи повече посещения, обаждания или по-добра видимост в Google. За това трябват реални данни и достатъчно време. Затова след публикуването ще следим първо как Google открива и индексира новите страници, кои услуги започват да получават impressions и clicks в Search Console и дали има URL-и, които се показват по заявки, различни от очакваните. Ще наблюдаваме и как се развива съдържанието с нови реализирани обекти. Това е важна част от проекта, защото сайтът е подготвен да не остане статичен след първоначалното публикуване. С всяка нова реална работа могат да се добавят снимки, описание и връзка към конкретната услуга. Ако започнем да проследяваме конкретни контактни действия, например кликове върху телефонния номер или изпратени запитвания, ще можем да оценяваме и тази част от поведението. Дотогава няма да приписваме на сайта резултати, които още не са измерени. Първият смислен анализ ще бъде след като се натрупат достатъчно данни. Тогава вече ще можем да видим кои страници получават видимост, какво търсят хората и къде има реална причина да подобрим съдържанието или структурата. ## Защо този подход беше правилният за проекта Когато един бизнес няма предишен сайт, имаме възможност да подредим структурата правилно още от самото начало. При този проект решихме да използваме тази свобода не за по-сложен дизайн, а за по-ясна логика около реалните ситуации, в които клиентът търси ВиК услуга. Затова започнахме от конкретните проблеми: теч, запушен канал, ремонт, монтаж, нужда от бърз контакт и желание да се видят реални примери от извършена работа. Оттам изградихме останалата архитектура: самостоятелни страници за услугите, директна контактна логика, реализирани обекти с CMS, техническа SEO основа и структура, която може да се развива с ново съдържание след публикуването. Точно такъв тип проект търсим в [програмата ни за безплатна изработка на сайт](https://evtinwebsite.com/bezplaten-uebsait). Не просто да пуснем още един сайт, а да решим реален бизнес казус, да изградим production проект и да можем ясно да покажем защо сме избрали конкретните решения. Ако имаш бизнес без собствен сайт и проектът ти е с ясен и разумен обхват, можеш да разгледаш [условията на програмата](https://evtinwebsite.com/bezplaten-uebsait/usloviya) и да кандидатстваш. ## За техническите маниаци Ето как можеш сам да провериш машинно четимия слой на сайта. Всички команди са публични. Командите са за bash и са тествани в Linux среда. Повечето работят директно и под WSL или Git Bash. Част от примерите използват GNU `grep`, а проверката на structured data изисква и `jq`. Lighthouse изисква Node.js и Chrome/Chromium. `llms.txt` е индекс към Markdown версиите на основните страници, услугите, реализираните обекти и контактната информация: ```bash curl -sS https://otpushvane-kanali.com/llms.txt ``` Същата логика важи за отделните страници. Например за услугата отпушване на канали: ```bash curl -sS https://otpushvane-kanali.com/uslugi/otpushvane-na-kanali/index.md ``` Markdown версията е декларирана и в HTML на страницата: ```bash curl -sS https://otpushvane-kanali.com/uslugi/otpushvane-na-kanali \ | grep -oiE ']+rel="(canonical|alternate|describedby)"[^>]*>' ``` Връща: ```text ``` HTML страницата остава canonical версията. Markdown представянето и `llms.txt` са само допълнителни ресурси върху същото съдържание. Стандартната search инфраструктура е отделна и разчита на HTML страниците, `sitemap.xml`, canonical адресите и structured data. Можеш да провериш и как sitemap-ът се връща към crawler user-agent: ```bash curl -A "Googlebot" -I https://otpushvane-kanali.com/sitemap.xml ``` Отговорът е `200 OK` с `content-type: application/xml`, тоест sitemap-ът е достъпен и при заявка с Googlebot user-agent. Това обаче само имитира user-agent низа и не доказва как Google действително обхожда сайта. За реалното състояние следим Google Search Console, включително отчетите за sitemap-а и индексирането на конкретните URL-и. Markdown ресурсите и `llms.txt` не заместват стандартното индексиране и не гарантират по-добро класиране или присъствие в AI отговори. Те дават допълнително структурирано и машинно четимо представяне на същото съдържание. Ако те интересува какво реално могат да прочетат AI системите от един сайт, описахме [как проверяваме AI-readability на уебсайт](https://evtinwebsite.com/blog/mozhe-li-chatgpt-da-prochete-saita-ti-kakvo-vizhdat-ai-sistemite). ### Още проверки, които можеш да пуснеш сам **Всички адреси от sitemap-а връщат 200** ```bash curl -s https://otpushvane-kanali.com/sitemap.xml \ | grep -oP '(?<=)[^<]+' \ | while read u; do echo "$(curl -s -o /dev/null -w '%{http_code}' "$u") $u"; done ``` Към 8 октомври 2026 г. всички 22 адреса в картата на сайта \(начална, услуги, реализирани обекти, „За нас" и контакти\) връщат `200`. **Несъществуваща страница връща истински 404** ```bash curl -s -o /dev/null -w "%{http_code}\n" https://otpushvane-kanali.com/nesashtestvuvasha-stranitsa ``` Връща `404`, не пренасочване към началната и не празна страница с код 200. **Основното съдържание присъства в server-rendered HTML** ```bash curl -sS https://otpushvane-kanali.com/uslugi/otpushvane-na-kanali \ | grep -oE ']*>[^<]*' ``` ```text

Отпушване на канали, сифони, мивки и тоалетни в София

``` Върнатият HTML съдържа основния `h1` директно, без да е необходимо първо браузърът да изпълни JavaScript, за да се появи заглавието на страницата. **Структурирани данни по тип** ```bash curl -s https://otpushvane-kanali.com/uslugi/otpushvane-na-kanali \ | grep -oP '(?<=)' \ | jq -r '.. | .["@type"]? // empty' | sort | uniq -c | sort -rn ``` Страницата съдържа `WebSite`, `Plumber`, `Service`, `BreadcrumbList` и `FAQPage` с пет въпроса и отговора. **Време за отговор на сървъра** ```bash curl -so /dev/null --compressed -w "HTTP/%{http_version}\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\nSize: %{size_download} bytes\n" https://otpushvane-kanali.com/ ``` ```text HTTP/2 TTFB: 0.049461s Total: 0.053484s Size: 20791 bytes ``` От нашата машина: HTTP/2, TTFB около 0,05 s и целият HTML response е получен за около 0,06 s, с transfer размер около 20 KB. Това е еднократно измерване от една локация и при теб стойностите ще бъдат различни. **Lighthouse, който всеки може да повтори** ```bash npx lighthouse https://otpushvane-kanali.com --preset=desktop \ --only-categories=performance,accessibility,seo,best-practices \ --chrome-flags="--headless" --output=json --output-path=report.json --quiet jq -r '.categories | to_entries[] | "\(.key): \(.value.score * 100)"' report.json ``` ```text performance: 100 accessibility: 100 best-practices: 100 seo: 100 ``` Резултатът е за началната страница, desktop профил, измерен на 8 октомври 2026 г. от локална машина. Mobile профилът \(с throttling\) е по-строг, затова там PageSpeed Insights отчете 98 за Performance. Резултатите варират между пускания и според машината, така че не ги четем като гаранция за всяка страница. Всички резултати са към 8 октомври 2026 г. Ако командите върнат нещо различно по-късно, това е нормално: сайтът се развива. ## Често задавани въпроси ### Наистина ли сайтът е изработен безплатно? Да. Проектът е реализиран по програмата ни за безплатна изработка на сайт, като договореният development scope е на цена 0 €. Външни разходи като домейн или бъдещи платени услуги остават отделни, ако са необходими. ### Има ли задължителен абонамент след това? Не. След изтичането на включените 30 дни техническа поддръжка клиентът не е обвързан със задължителен абонамент към DIMITROV.code и не е длъжен да продължи да работи с нас. ### Защо реализираните обекти имат отделни страници? Първоначално клиентът искаше галерия, но предложихме по-структурирано решение. По-подробните обекти могат да имат собствена страница със снимки, описание и връзка към конкретната услуга. Това дава повече контекст за посетителите и позволява сайтът да натрупва реално съдържание с времето. ### Може ли всеки бизнес да получи безплатен сайт? Не. Кандидатстването не означава автоматично одобрение. Избираме ограничен брой реални проекти с ясен и разумен обхват, които могат да бъдат реализирани като production сайт в рамките на програмата. > Автор: [Борислав Димитров](https://www.linkedin.com/in/borislav-dimitrov-fizer/) > Full Stack Developer > Next.js • SEO • AI Visibility --- Source: https://evtinwebsite.com/blog/bezplaten-sait-za-vik-uslugi-realen-case-study-ot-programata-ni