Събрали сте оферти за изработка на онлайн магазин и на пръв поглед те си приличат. Навсякъде пише WooCommerce с доставка чрез Еконт и Спиди, а често и „бързо зареждане“. Разликите излизат наяве по-късно, когато кампания претовари сървъра или когато обновяване на плъгин спре поръчките.
Ето десет въпроса, които да зададете на всеки изпълнител, преди да подпишете. Отговорите показват какво точно купувате и кой отговаря за магазина след пускането. Накрая има чеклист, в който да отметнете получените отговори.
Как купувачът ще избира офис или автомат на Еконт и Спиди?
Купувачът трябва да може да избере офис или автомат на куриера направо в поръчката и да види цената на доставката, преди да потвърди. Ако трябва да опише офиса в бележка, ще получавате поръчки с грешки и ще уточнявате по телефона.
И Еконт, и Спиди имат собствени модули за WooCommerce, а има и плъгини от други разработчици. Модулът на Спиди например предлага доставка до адрес, офис или автомат, като при автомат опциите за отваряне и тестване на пратката не са позволени. Попитайте изпълнителя:
- кой модул ще използва и защо
- изчислява ли се цената на доставката в самата поръчка
- работи ли модулът с блоковата страница за поръчка, която от WooCommerce 8.3 е по подразбиране в новите магазини
- създават ли се товарителниците автоматично, или ги създавате ръчно
- на чие име са договорите с куриерите и данните за достъп до системите им
Договорите и данните за достъп трябва да са Ваши. Поискайте и тестова поръчка с всеки куриер и всеки вид доставка, преди магазинът да тръгне. Как се настройват двата модула, е описано в ръководството Как да настроите доставка с Еконт и Спиди в WooCommerce.
Какви начини на плащане ще има?
Наложеният платеж е вграден в WooCommerce и може да се ограничи само до методите за доставка с куриер. За плащане с карта Ви трябват договор с платежен доставчик и негов модул за WooCommerce. Договорът е между Вас и доставчика, а изпълнителят свързва модула със сметката Ви.
Попитайте:
- кои начини на плащане ще има при пускането и кой ще ги настрои
- с кой доставчик ще работи плащането с карта и кой подписва договора с него
- могат ли парите при плащане с карта да се връщат от админ панела на WooCommerce
- ще има ли тестово плащане в тестов режим, преди да започнат истинските
- работи ли целият магазин през HTTPS
WooCommerce пише, че повечето платежни модули изискват SSL, и препоръчва HTTPS за целия магазин, не само за страницата за поръчка. Двата начина на плащане и модулите за български магазин са описани в ръководството Наложен платеж и плащане с карта в WooCommerce за България.
Как ще се издават фактурите и другите документи?
Какви документи издавате при поръчка, при наложен платеж и при връщане на пари, зависи от дейността Ви и от закона, затова тук не даваме данъчни съвети. Уговорете документооборота със счетоводителя си, преди да започне изработката, и го опишете писмено за изпълнителя. От него зависи как ще се направят страницата за поръчка, имейлите до купувачите и връзките с други програми.
Когато знаете какво казва счетоводителят, изяснете с изпълнителя:
- ще издава ли документите плъгин в WooCommerce, или поръчките ще отиват в счетоводната Ви програма
- къде купувачът въвежда данните на фирма, ако иска фактура, и кои полета са задължителни
- как се номерират документите и какво става при връщане на пари
- кой поддържа плъгина или връзката, ако счетоводната програма се смени
Помислете и за куриера. Спиди например предлага услуга, при която издава касов бон от Ваше име, но за нея е нужен договор и допълнително споразумение със Спиди. Дали Ви трябва, ще Ви каже счетоводителят.
Как ще влизат продуктите и наличностите от доставчиците?
Ако продуктите са малко, можете да ги въведете ръчно. Ако са стотици или идват от доставчици, попитайте как ще влязат в магазина и как ще се обновяват цените и наличностите.
WooCommerce има вграден инструмент за внос и износ на продукти от CSV файл. С него могат да се обновяват и съществуващи продукти, които се разпознават по ID или по SKU (продуктовия код), а число в колоната за наличност включва следенето на наличността. За редовна връзка с доставчик или със складова програма се ползва готов плъгин за внос или REST API на WooCommerce, през което друга система създава и обновява продукти.
Попитайте:
- кой въвежда първите продукти, описанията и снимките и влиза ли това в цената
- откъде идват данните, например CSV или XML файл от доставчика, и колко често се обновяват
- какво става, ако файлът на доставчика липсва или е сгрешен
- има ли всеки продукт уникален SKU, по който да се сверява
- кой поддържа връзката, когато доставчикът смени формата на файла си
Въпросите за сгрешения файл и за смяната на формата изглеждат дребни, но точно тези случаи трябва да имат отговор, преди връзката да заработи.
Колко бързо ще се отварят продуктите и категориите на телефон?
От търсенето в Google и от рекламите купувачите често попадат направо в категория или в продукт, без да минат през началната страница. Затова поискайте целта за скорост да важи и за поне една категория и един продукт с истински снимки, измерени в PageSpeed Insights на мобилни.
Добрите стойности на Core Web Vitals са до 2,5 секунди за LCP, до 200 милисекунди за INP и до 0,1 за CLS. На продуктовата страница най-големият елемент обикновено е снимката на продукта, а INP има значение при избора на вариант и при добавянето в количката. Според Google резултат 90 и повече в лабораторния тест е добър.
Попитайте отделно за количката и поръчката. WooCommerce пише, че страниците Cart, Checkout и My Account не бива да се кешират, защото показват данни на конкретния купувач. Там кешът не помага и скоростта зависи от сървъра и от кода, затова поискайте да видите как минава поръчка с няколко продукта в количката. Как се чете отчетът, е описано в ръководството Как да измерите скоростта на сайта с PageSpeed Insights.
Какво ще стане със SEO на категориите и със старите адреси?
Хората търсят в Google и конкретни продукти, и видове продукти. Затова всяка категория има нужда от свое заглавие, описание и кратък текст освен решетката със снимки. Попитайте за:
- Структурираните данни на продуктите. С тях Google може да покаже цена, наличност и отзиви в резултатите, а за страниците, от които може да се купи, има отделен вид, наречен merchant listings. Google не гарантира, че резултатът ще се покаже по-богато.
- Адресите. Google съветва в адреса да има описателни думи, например
/obuvki/maratonkiвместо/?cat=17. - Филтрите. Филтрите по цвят, размер или цена могат да създадат безкраен брой адреси, които Google обхожда излишно. Google описва как да се ограничат, затова попитайте как ще бъдат настроени.
- Старите адреси. Ако сменяте магазина, всеки стар адрес на продукт и категория трябва да води с постоянно пренасочване (301) към новия. Google съветва пренасочванията да се пазят поне година и предупреждава за временно колебание в позициите.
Как да мине смяната без загуба на позиции, е описано в ръководството Как да смените сайта, без да загубите позициите си в Google.
Кой ще обновява магазина и ще следи за уязвимости?
WooCommerce, темата и всеки плъгин получават обновления, част от тях за сигурност. Според годишния доклад на Patchstack 91% от новите уязвимости в WordPress през 2025 г. са били в плъгини, а при 46% разработчикът не е пуснал поправка до публичното им обявяване. Магазинът пази данни на клиенти и поръчки, затова тези рискове го засягат пряко.
WooCommerce съветва преди всяко обновяване да има актуален бекъп, обновяването да се тества в staging, когато е възможно, и никога да не се пробва направо на живия магазин. Попитайте:
- кой обновява WooCommerce, темата и плъгините след пускането и колко често
- минава ли всяко обновяване през staging и тестова поръчка
- следи ли някой всеки ден плъгините за известни уязвимости (CVE)
- какво става, ако за уязвим плъгин още няма поправка
- има ли бекъпи с проверено възстановяване
- в офертата ли е всичко това, или в отделен договор за поддръжка
Ще издържи ли магазинът пиковете в трафика?
Кампания, разпродажба, бюлетин или реклама могат да доведат много купувачи наведнъж. Кешът може да поеме разглеждането на продуктите, но количката и поръчката не се кешират и всяка поръчка натоварва сървъра и базата данни. Попитайте:
- на какъв хостинг или в какъв облак ще работи магазинът и кой плаща сметката
- правен ли е тест с натоварване и при колко едновременни посетители
- какво става с поръчка, ако в този момент WooCommerce или сървърът не отговори
- може ли капацитетът да расте бързо и кой го увеличава
Третият въпрос е най-неудобният. Ако отговорът е „купувачът вижда грешка“, тази поръчка най-вероятно е загубена. В headless магазините, които правим, поръчката минава през опашка и не се губи, дори WooCommerce да не отговаря. Кога headless магазинът си струва, е описано в ръководството Класически WooCommerce или headless магазин, как да изберете.
Чии ще са данните, кодът и акаунтите?
Магазинът е Ваш бизнес, затова всичко, от което зависи, трябва да е на Ваше име:
- домейнът и хостингът или облачният акаунт
- Git хранилището с кода и правото да го ползвате и променяте
- профил с роля Administrator в WordPress
- договорите с Еконт, Спиди и платежния доставчик, заедно с данните за достъп до системите им
- собствеността в Google Search Console и администраторският достъп до Google Analytics
Изпълнителят получава потребителски достъп, който можете да спрете по всяко време.
Данните на клиентите и поръчките също са Ваша отговорност. Попитайте къде се пазят бекъпите, кой има достъп до тях и как ще получите пълно копие на базата, ако се разделите с изпълнителя. Ако той ще има достъп до лични данни, уговорете писмено как ги обработва и пази. Дали Ви трябва и отделен договор за обработване на лични данни, ще Ви каже юрист.
Как ще се тестват промените след пускането?
След пускането магазинът продължава да се променя. Нов плъгин, нов начин на плащане или промяна в цените за доставка може да счупи страницата за поръчка, а това обикновено се разбира чак когато поръчките спрат. Попитайте:
- има ли staging копие със същите версии на WordPress, WooCommerce и плъгините
- минава ли всяка промяна през Git и staging, преди да стигне до живия магазин
- прави ли се след промяна тестова поръчка с всеки куриер и всеки начин на плащане, в демо или тестов режим, където го има
- има ли план за връщане назад, ако промяната счупи нещо
- кой проверява първите истински поръчки след промяната
Добрият отговор описва процеса стъпка по стъпка. „Внимаваме“ не е процес.
Чеклист
- Видели сте тестова поръчка с избор на офис или автомат на Еконт и Спиди.
- Знаете кои начини на плащане ще има и кой подписва договора с платежния доставчик.
- Документооборотът е уговорен със счетоводителя и описан писмено за изпълнителя.
- Ясно е как влизат продуктите и как се обновяват цените и наличностите.
- Скоростта се мери на мобилни за категория и продукт, а поръчката е проверена с няколко продукта в количката.
- Категориите имат свои текстове, продуктите имат структурирани данни, а старите адреси се пренасочват с 301.
- Някой обновява магазина през staging и всеки ден следи плъгините за уязвимости.
- Знаете къде ще работи магазинът и какво става с поръчка при претоварване.
- Домейнът, хостингът, кодът, договорите и профилите в Google са на Ваше име.
- Всяка промяна след пускането минава през staging и тестова поръчка, с план за връщане назад.
Каква изработка на онлайн магазин е подходяща за Вас?
Ако продавате няколко десетки продукта и изпращате по няколко пратки седмично, класически WooCommerce с официалните модули на куриерите обикновено е достатъчен. Десетте въпроса пак важат, но отговорите ще са по-кратки.
Когато магазинът расте, препоръчваме headless онлайн магазин. Витрината е на Next.js, а продуктите и поръчките остават в WooCommerce. Спиди и Еконт са в поръчката с избор на офис, а Kubernetes добавя капацитет при пикове в трафика. Стремим се към 90+ за скорост и 100 за SEO в PageSpeed Insights. Ако вече имате бавен магазин на WooCommerce, вижте преработката, при която продуктите, поръчките и профилите на клиентите остават в WooCommerce, а Вие работите от същия админ панел.
Често задавани въпроси
Какво да попитам разработчика преди изработка на онлайн магазин?
Питайте как купувачите ще избират офис или автомат на Еконт и Спиди, кои начини на плащане ще има и как ще се издават фактурите и другите документи. Питайте и как ще влизат продуктите и наличностите от доставчиците, колко бързо ще се отварят категориите и продуктите на телефон и какво става със SEO и старите адреси. Последните въпроси са кой обновява магазина и следи за уязвимости, дали магазинът издържа на пикове в трафика, чии са данните и акаунтите и как се тестват промените след пускането.
Как трябва да избират купувачите офис на Еконт или Спиди?
Направо в страницата за поръчка, като виждат цената на доставката, преди да потвърдят. Ако трябва да описват офиса в бележка към поръчката, ще получавате поръчки с грешки и ще губите време по телефона. Поискайте тестова поръчка с всеки куриер и всеки вид доставка, преди магазинът да тръгне, и проверете дали модулът работи с блоковата страница за поръчка, която е по подразбиране за нови магазини от WooCommerce 8.3.
На чие име трябва да са договорите с куриерите и доставчика на плащания?
На Ваше. Договорът за плащане с карта е между Вас и доставчика, а разработчикът само свързва модула с акаунта Ви. Същото важи за договорите с Еконт и Спиди и данните за достъп до системите им.
Как разработчикът трябва да мери скоростта на онлайн магазина?
В PageSpeed Insights на мобилно, поне за една категория и един продукт с истински снимки, а не само за началната страница. От търсенето в Google и от рекламите купувачите често влизат направо в категория или продукт. Добрите прагове са LCP до 2.5 секунди, INP до 200 милисекунди и CLS до 0.1, а количката и поръчката не се кешират, така че поискайте да видите поръчка с няколко продукта в количката.
Как ще влизат продуктите и наличностите от доставчиците?
WooCommerce има вграден инструмент за внос и износ на продукти като CSV файл, който обновява и съществуващи продукти, като ги разпознава по ID или SKU. За редовно подаване на данни от доставчик или складова система обикновено се ползва плъгин за внос или REST API на WooCommerce. Питайте какво става, ако файлът на доставчика липсва или е грешен, и кой поддържа връзката, когато доставчикът смени формата.
Кой трябва да притежава домейна, кода и акаунтите на магазина?
Вие. На Ваше име трябва да са домейнът и акаунтът за хостинг или облак, хранилището в Git с кода и правото да го ползвате и променяте, акаунт с роля Administrator в WordPress, договорите с Еконт, Спиди и доставчика на плащания и собствеността в Google Search Console и Google Analytics. Разработчикът получава потребителски достъп, който можете да отнемете по всяко време.
Какво става с поръчката, ако сървърът не отговаря по време на кампания?
Зависи от магазина, затова питайте разработчика точно това. Ако отговорът е „купувачът вижда грешка“, тази поръчка най-вероятно е изгубена. В headless магазините, които прави WPHost, поръчката влиза в опашка и не се губи, дори когато WooCommerce не отговаря.
Как трябва да се тестват промените след пускането на магазина?
Поискайте копие в staging със същите версии на WordPress, WooCommerce и плъгините и всяка промяна да минава през Git и staging, преди да стигне до живия магазин. След промяна трябва да се направи тестова поръчка с всеки куриер и начин на плащане, в демо или тестов режим, където има такъв, и да има план за връщане, ако нещо се счупи. Добрият отговор описва процеса стъпка по стъпка, а „внимаваме“ не е процес.
Източници
- Еконт, Econt WooCommerce плъгин на GitHub
- Спиди, ръководство за модула за WooCommerce
- WooCommerce, WooCommerce 8.3.0 Released
- WooCommerce, Cash on Delivery
- WooCommerce, SSL and HTTPS
- WooCommerce, Product CSV Importer and Exporter
- WooCommerce, REST API documentation
- WooCommerce, Configuring caching plugins
- WooCommerce, How to update WooCommerce
- web.dev, Web Vitals
- Google, About PageSpeed Insights
- Google, Product structured data
- Google, Designing a URL structure for ecommerce sites
- Google, Managing crawling of faceted navigation URLs
- Google, Site moves with URL changes
- Google Search Console Help, Managing owners, users, and permissions
- Google Analytics Help, Access and data-restriction management
- Patchstack, State of WordPress Security in 2026