Изработка на сайт, какво да поискате от изпълнителя

# ЕтикетиWordPressSEOСкорост

Екипът на WPhost21 сеп 202617 мин четене

Готвите се да поръчате изработка на сайт за фирмата си и вече имате няколко оферти. Във всяка пише „SEO оптимизация“ и „бързо зареждане“, а цените са съвсем различни. Тези думи звучат добре, но не казват какво точно ще получите. Разликата обикновено проличава след пускането, когато сайтът се отваря бавно на телефон или когато за всяка смяна на текст трябва да търсите изпълнителя.

В това ръководство ще видите какво да поискате писмено, в офертата и в договора, преди да подпишете. Така ще знаете какво точно купувате, а чеклиста в края можете да изпратите на всеки изпълнител.

Накратко

Поискайте списък на страниците, темата и плъгините и попитайте дали сайтът ще е направен с конструктор като Elementor или Divi.
Запишете в договора резултата в PageSpeed Insights на мобилни, страниците, за които важи, и че при предаването получавате отчета от измерването.
Домейнът, хостингът, кодът и профилите в Google трябва да са на Ваше име, а изпълнителят да има достъп като потребител.
Сайтът се прави в staging, а всеки стар адрес, който се сменя, се пренасочва с 301 към новия.
Уговорете писмено кой обновява сайта след пускането и кой следи за уязвимости.

Какво да съдържа офертата за изработка на сайт

Добрата оферта описва сайта толкова подробно, че друг изпълнител би могъл да го направи по нея. Поискайте в нея да има:

списък на страниците и езиците, например начало, услуги, за нас, контакти и блог, на български и на английски
формите на сайта и къде отиват изпратените данни, например имейл до офиса или запис в админ панела
връзките с други системи, ако Ви трябват, например CRM, счетоводна програма или онлайн записване на часове
кой пише текстовете и кой осигурява снимките
колко кръга корекции на дизайна влизат в цената
какво не влиза, например домейн, хостинг, платени плъгини, поддръжка и реклама

Ако нещо не е записано, приемете, че не е включено. Поискайте и разбивка по етапи (структура, дизайн, изработка, пускане) с това, което одобрявате след всеки от тях. Сроковете зависят от обхвата, затова е по-добре да ги видите за всеки етап поотделно, отколкото като една дата накрая.

Тема, направена за Вас, или конструктор на страници

Темата в WordPress определя как изглежда сайтът и голяма част от кода, който браузърът зарежда. Много оферти стъпват на готова тема от маркетплейс и на конструктор на страници като Elementor, Divi или WPBakery. Конструкторът позволява да подреждате блокове с мишката, но зарежда собствен код, за да може да прави почти всичко, а съдържанието остава свързано с него. Ако по-късно решите да го махнете, страниците обикновено се правят наново.

Другият път е лека тема, направена само за Вашия сайт, с блокове за редактора на WordPress. В нея има само това, което сайтът ползва, и няма конструктор, от който да зависи съдържанието.

Поискайте в офертата да пише:

името на темата и дали е готова, или се прави за проекта
дали ще има конструктор на страници и кой
списък на всички плъгини, безплатни и платени
на чие име са лицензите на платените плъгини и кой ги подновява

Лицензите не са дребна подробност. При много платени плъгини обновленията идват само докато лицензът е активен. Elementor например пише, че без подновяване Elementor Pro вече не може да се обновява. Това е една от причините сайтовете на WordPress, които правим, да са с лека тема, направена за клиента, без Elementor и Divi. Подробно сравнение има в ръководството Готова тема или дизайн по мярка, кое е по-добро за бизнеса.

Каква скорост да поискате и как да се мери

„Бърз сайт“ в офертата не означава нищо, докато не е ясно как се мери. Поискайте да са записани пет неща:

Инструментът, обикновено PageSpeed Insights на Google.
Устройството. Тестът за мобилни е по-строг, защото симулира телефон от среден клас с мобилна връзка.
Страниците, за които важи, например началната и двете най-важни страници за услуги.
Резултатът, например 90 или повече за скорост (Performance).
Кога се мери и какво получавате, например в деня на предаването, с отчета от измерването.

Резултатът в PageSpeed Insights идва от тест с Lighthouse в симулирана среда. Според Google 90 и повече е добър резултат, от 50 до 89 има нужда от подобрение, а под 50 е слаб. Числото се мени при всяко пускане, дори сайтът да не е пипан. Документацията на Lighthouse съветва тестът да се пусне няколко пъти и да се вземе медианата, тоест средният по големина резултат. Уговорете това предварително, за да не спорите за едно случайно измерване.

Отделно PageSpeed Insights показва данни от реални посетители в Chrome за последните 28 дни, оценени по трите показателя Core Web Vitals. Добрите стойности са до 2,5 секунди за LCP (кога се показва най-големият елемент), до 200 милисекунди за INP (колко бързо сайтът реагира на клик) и до 0,1 за CLS (колко се разместват елементите). Новият сайт още няма такива данни, а при малко посещения те може изобщо да не се появят. Затова в деня на предаването може да се провери само лабораторният тест.

Уговорете и какво става с външните скриптове. Чатът, рекламните пиксели и другите скриптове, добавени след пускането, свалят резултата. Нека измерването включва всичко, което ще работи от първия ден, например анализа и банера за бисквитки. Как се чете целият отчет, е описано в ръководството Как да измерите скоростта на сайта с PageSpeed Insights.

Техническото SEO, което трябва да е в офертата

„SEO оптимизация“ може да значи почти всичко. Поискайте конкретните неща, които Google описва в документацията си:

Заглавие и мета описание за всяка страница, които можете да редактирате. Google съветва заглавията да са описателни и различни за всяка страница. Мета описанието понякога се показва в резултатите, когато описва страницата по-точно от текста ѝ.
Четими адреси, например /uslugi/remont-na-pokrivi вместо /?p=123. Google препоръчва в адресите да има четими думи вместо дълги номера.
Карта на сайта (XML sitemap). От версия 5.5 WordPress прави такава сам на адрес /wp-sitemap.xml, а някои плъгини за SEO я заменят със своя. Поискайте картата да бъде подадена в Google Search Console.
Структурирани данни, които описват името, адреса и работното време на фирмата по начин, който Google разбира. Google изрично пише, че не гарантира, че по-богатите резултати, които ги ползват, ще се появят в търсенето.
hreflang, ако сайтът е на повече от един език. Всяка езикова версия трябва да сочи себе си и останалите, иначе Google пренебрегва отбелязването.
Отворен сайт при пускането. Докато се работи, в Settings, Reading често е включена отметката „Discourage search engines from indexing this site“. Тя добавя noindex в кода на страниците и спира картата на сайта. Ако остане включена и след пускането, сайтът няма да се появи в Google.

Никой не може честно да обещае първо място в Google. Ако в офертата има такова обещание, попитайте как точно ще бъде постигнато. Всички проверки преди пускане са събрани в ръководството Техническо SEO за WordPress, чеклист преди пускане на сайта.

Чии са домейнът, хостингът, кодът и профилите?

Тази част от договора е най-важна, защото решава доколко ще зависите от изпълнителя. Ако домейнът е регистриран на агенцията, при раздяла с нея ще разчитате на добрата ѝ воля. Поискайте писмено:

Домейнът е на фирмата Ви или на Вас, с Ваш имейл за контакт. Как става това при .bg, е описано в ръководството Как да регистрирате .bg домейн и какво да проверите първо.
Хостингът е на Ваше име и се плаща от Вас, или поне имате пълен достъп до панела му. Ако изпълнителят държи сайта на свой сървър, запишете как ще получите пълно копие и как ще го преместите.
Кодът е Ваш. Темата и всичко, писано за сайта, са в Git хранилище, до което имате достъп, а договорът казва, че получавате кода и правото да го ползвате и променяте.
Вие сте администратор в WordPress. Ролята Administrator има достъп до всички настройки на сайта, а изпълнителят работи със свой отделен профил.
Вие сте собственик в Google Search Console и администратор в Google Analytics. Само собственикът в Search Console може да добавя и да маха потребители, а администраторът в Analytics има пълен контрол над профила. Изпълнителят получава достъп като потребител.

Staging и Git, преди сайтът да стане публичен

Staging е копие на сайта на отделен адрес, например на поддомейн, където се работи и тества, без да се пипа живият сайт. Там виждате новия сайт и го одобрявате, преди да стане публичен. След пускането staging остава и всяко обновяване минава първо през него.

Git пази историята на кода. Всяка промяна е записана с дата и автор и може да бъде върната, ако счупи нещо.

Попитайте изпълнителя:

Ще има ли staging и ще мога ли да го разглеждам?
Защитен ли е с парола? Google съветва съдържанието, което не бива да излиза в търсенето, да се пази с парола.
Какъв е планът за пускане и как се връща старият сайт, ако нещо се обърка?

Последният въпрос често се пропуска. При пускането се сменят DNS записите, а понякога и сървърът, и ако нещо се счупи, трябва предварително да е ясно кой какво прави.

Пренасяне на старото съдържание и пренасочване на адресите

Ако вече имате сайт, Google познава адресите му, а други сайтове водят към тях. Когато новият сайт смени адресите, всеки стар адрес трябва да води към новия си вариант с постоянно пренасочване (301). Иначе посетителите и Google стигат до страница с грешка 404.

Google описва как се прави това. Първо се съставя списък на всички стари адреси и за всеки се посочва новият. Пренасочването се прави на сървъра и е постоянно (301 или 308). Не бива много стари адреси да се пренасочват към една и съща несвързана страница, например началната. Пренасочванията се пазят възможно най-дълго, обикновено поне година. Google предупреждава и че позициите временно се колебаят, докато търсачката обходи сайта отново.

Поискайте в офертата да е записано:

кой пренася текстовете, снимките и публикациите и дали влизат всички, или само част от тях
кой съставя списъка на старите адреси, например от картата на сайта, Search Console и анализа
кой проверява за грешки 404 през първите седмици след пускането

Подробно как минава такава смяна, е описано в ръководството Как да смените сайта, без да загубите позициите си в Google.

Ще можете ли да редактирате сайта сами?

Вие или Ваш служител трябва да можете да смените текст, снимка или цена, без да чакате изпълнителя. Не се задоволявайте с „да, лесно е“. Поискайте в staging да Ви покажат как:

се сменя телефонът в долната част на всички страници
се добавя новина или публикация в блога
се прави нова страница за услуга от готовите блокове
се сменя снимка, без да се развали подредбата

Редакторът на WordPress позволява на изпълнителя да направи блокове и шаблони (patterns) по Вашия дизайн и да ги заключи. Така сменяте съдържанието, без да можете случайно да преместите или изтриете част от подредбата. Темата може да ограничи и цветовете, и размерите на шрифта до тези на марката Ви.

Поискайте кратко ръководство или видео при предаването и отделен профил за всеки човек, с подходяща роля. За публикуване и редакция стига ролята Editor (Редактор), а Administrator дайте само на хората, които наистина управляват сайта.

Google Analytics и съгласието за бисквитки

Много фирмени сайтове мерят посещенията с Google Analytics, а някои добавят и рекламни пиксели. Според правилата в ЕС бисквитките, които не са строго необходими за услугата, поискана от посетителя, могат да се записват едва след неговото съгласие. Оттеглянето на съгласието трябва да е също толкова лесно, колкото даването му. Политиката на Google за съгласие на потребителите в ЕС също изисква такова съгласие, когато ползвате продуктите на Google.

Попитайте:

кой поставя банера за бисквитки и кои инструменти минават през него
чакат ли анализът и пикселите съгласието, преди да се заредят
настроен ли е режимът за съгласие (consent mode) на Google

Режимът за съгласие само съобщава на таговете на Google какво е избрал посетителят. Самото съгласие се иска от банера или от платформа за управление на съгласието. Текста на политиката за бисквитки и въпроса кои от тях изискват съгласие обсъдете с юрист.

Сигурност и поддръжка след пускането

Работата по сайта не свършва в деня на пускането. От версия 3.7 WordPress сам инсталира малките обновления на ядрото, включително тези за сигурност. Плъгините и темите се обновяват автоматично само ако това е включено за всеки от тях, което е възможно от версия 5.5.

Рискът е именно в плъгините. Според годишния доклад на Patchstack, база данни за уязвимости в WordPress, през 2025 г. са открити над 11 000 нови уязвимости, 91% от тях в плъгини и 9% в теми. В ядрото са докладвани само 6, всички с нисък приоритет. При 46% от уязвимостите разработчикът не е пуснал поправка до публичното им обявяване. Затова някой трябва да следи кои плъгини са засегнати и да реагира, като обнови плъгина, смени го с друг или го махне.

Попитайте:

кой обновява WordPress, темата и плъгините след пускането и колко често
минават ли обновяванията първо през staging
има ли бекъпи и проверено ли е, че сайтът се възстановява от тях
кой следи за известни уязвимости (CVE) и какво става, ако сайтът бъде хакнат
влиза ли това в цената, или е отделен договор за поддръжка

Ако никой не поеме тези задачи, сайтът остава без грижа от деня на пускането. Какво можете да направите сами, е описано в ръководството Защита на WordPress сайт с wp-config, .htaccess и Cloudflare.

Чеклист

Офертата изброява страниците, езиците, формите и връзките с други системи.
Знаете коя е темата, кои са плъгините и дали има конструктор на страници.
Резултатът в PageSpeed Insights е записан за мобилни и за конкретни страници, с отчет при предаването.
Заглавията, мета описанията, адресите, картата на сайта и структурираните данни са в обхвата.
Домейнът, хостингът, кодът и профилите в Google са на Ваше име или под Ваш контрол.
Сайтът се прави в staging със защитен достъп и има план за връщане назад при пускането.
Има списък на старите адреси и всеки сменен адрес се пренасочва с 301.
Видели сте как се сменят текст и снимка и как се прави нова страница.
Банерът за бисквитки спира анализа и пикселите до съгласие.
Ясно е кой обновява сайта и кой следи за уязвимости след пускането.

Трябва ли Ви всичко от списъка?

Ако Ви трябва визитка с няколко страници, която няма да развивате, добре поддържана безплатна тема и няколко внимателно подбрани плъгина може да са достатъчни. Домейна, хостинга и достъпите обаче проверете и тогава, защото те излизат най-скъпо, когато се окажат на чуждо име.

Ако искате всичко от списъка в един договор, изработката на сайт на WordPress при нас е с лека тема, направена за Вас, без Elementor и Divi. Мерим скоростта в PageSpeed Insights на мобилни в деня на предаването и Ви даваме отчета, а резултатът 90 или повече важи при бърз хостинг и проверени от нас плъгини. Сайтът работи на Вашия хостинг, а домейнът и данните остават Ваши. При активна поддръжка всеки ден сверяваме плъгините, темата и WordPress с базите данни за уязвимости и обновяваме навреме през staging.

Често задавани въпроси

Какво трябва да съдържа офертата за изработка на уебсайт?

Офертата трябва да изброява страниците и езиците, формите и къде отиват изпратените данни, връзките с други системи като CRM или счетоводна програма, кой пише текстовете и кой дава снимките. Добре е да пише и колко кръга промени в дизайна включва цената и какво не е включено, например домейн, хостинг, платени плъгини, поддръжка и реклама. Ако нещо не е записано, приемете, че не е включено.

Как да запиша изискването за скорост в договора за сайт?

Поискайте писмено петте неща, които правят обещанието проверимо, тоест инструмента, обикновено Google PageSpeed Insights, устройството, страниците, оценката и кога се мери и какво получавате. Например оценка 90 или повече за Performance на мобилно за началната страница и двете основни страници за услуги, измерена в деня на предаването, с отчета. Оценката се мени от пускане на пускане, затова се уговорете предварително за няколко пускания и медианата.

Каква е разликата между тема, правена за сайта, и редактор на страници като Elementor?

Редактор на страници като Elementor, Divi или WPBakery позволява да подреждате блокове с мишката, но зарежда свой код, за да може да прави почти всичко, а съдържанието остава вързано за него. Ако го махнете по-късно, страниците обикновено трябва да се правят наново. Лека тема, правена само за Вашия сайт, с блокове за редактора на WordPress, съдържа само това, което сайтът ползва.

На чие име трябва да са домейнът, хостингът и кодът на сайта?

На Вашата фирма или на Вас. Домейнът трябва да е с Вашия имейл за контакт, хостингът да е на Ваше име или поне да имате пълен достъп до панела му, а кодът да е в хранилище в Git, до което имате достъп, с право да го ползвате и променяте. В WordPress трябва да сте администратор, а в Google Search Console собственик, като разработчикът работи от отделен акаунт.

Може ли разработчикът да гарантира първо място в Google?

Никой не може честно да обещае първо място в Google. Поискайте вместо това конкретни неща, например заглавие и мета описание за всяка страница, четими адреси, XML sitemap, подаден в Google Search Console, структурирани данни и hreflang за сайт на няколко езика. Ако оферта обещава първо място, попитайте как точно.

Какво става със старите адреси при нов сайт?

Когато новият сайт смени адрес, старият трябва да води към новия си вариант с постоянно пренасочване (301), иначе посетителите и Google попадат на грешка 404. Google съветва всеки стар адрес да се свърже с новия, да не се пращат много стари адреси към една несвързана страница като началната и пренасочванията да се пазят поне година. Запишете в офертата кой мести съдържанието, кой прави списъка със старите адреси и кой следи за грешки 404 в първите седмици.

Ще мога ли да редактирам новия сайт самостоятелно?

Не приемайте „да, лесно е“, а поискайте в staging да Ви покажат как се сменя телефонът във футъра, как се добавя новина, как се прави нова страница за услуга от готовите блокове и как се сменя снимка, без да се счупи подредбата. Редакторът на WordPress позволява разработчикът да заключи блоковете, така че да сменяте съдържанието, без да местите оформлението по грешка. Поискайте и кратко ръководство или видео при предаването.

Кой поддържа сайта след пускането?

Това трябва да е уговорено писмено. От версия 3.7 WordPress слага сам малките обновления на ядрото, но плъгините и темите се обновяват автоматично само ако това е включено за всеки от тях, а според годишния доклад на Patchstack 91% от новите уязвимости през 2025 г. са в плъгини. Питайте кой обновява сайта и колко често, дали обновленията минават първо през staging, дали има бекъпи с проверено възстановяване и кой следи за известни уязвимости (CVE).

Източници