32 проверки, преди да платите последната вноска

Новият сайт изглежда добре. Отваряте го на телефона си, кликате из менюто, всичко работи. Одобрявате, плащате остатъка и приключвате. Три месеца по-късно се оказва, че формата за контакт праща в спам, тестовата версия е индексирана в Google, а домейнът е регистриран на името на дизайнера.

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

01Три правила преди самите проверки

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

1. Приемайте на реалния домейн, не на тестовия

   Абсолютни адреси, SSL сертификати, имейл доставимост, пренасочвания, кеширане — всичко това се държи различно на test.agencia.bg/proekt и на вашия домейн. Всяка проверка по-долу се прави на живия сайт.

2. Задръжте последна вноска и запишете срок за приемане

   10 до 20 процента, дължими след успешно приемане, с 7 до 14 дни за проверка от пускането. Не е израз на недоверие, а стандартна практика — и е единственият механизъм, който гарантира, че последните пет процента от работата ще бъдат свършени.

3. Тествайте на истинско устройство и в инкогнито

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

02Собственост и достъпи — 5 проверки

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

• 1. Домейнът е регистриран на вашата фирма.Проверете в whois дали полето Registrant е вашата фирма, а не изпълнителят. Ако е на изпълнителя, това не е дребна подробност за после — вижте какво се случва, когато достъпите са у друг.
• 2. Хостинг акаунтът е на ваше име и имате логин.Не „изпълнителят има достъп и ще прави каквото трябва“. Влезте сами в контролния панел, докато той е на телефона. Ако не можете — не сте приели сайта.
• 3. Имате администраторски достъп до WordPress.Роля Administrator, не Editor. Проверете, че виждате менютата Плъгини и Потребители. Ако не ги виждате, имате редакторски достъп, не администраторски.
• 4. Получили сте пълен архив на свой носител.Архив с всички файлове плюс експорт на базата данни (.sql). Не линк към чужд Google Drive — файл, който е при вас. Това е вашата застраховка срещу всичко останало.
• 5. Analytics и Search Console са ваша собственост.Не „добавен сте като потребител“. Проверете, че вашият имейл е с права на собственик. Ако акаунтът е на агенцията, при раздяла губите цялата историческа статистика.

03Индексиране и SEO хигиена — 6 проверки

Тук са тихите дефекти. Сайтът работи безупречно за посетители и същевременно е частично невидим за търсачките. Никой не забелязва, докато не се запитате защо няма трафик след три месеца.

• 6. robots.txt не блокира сайта.Отворете вашдомейн.bg/robots.txt. Ако видите Disallow: /, сайтът е забранен за обхождане — забравена настройка от разработката. Това е дефект №1 при пускане на нов сайт.
• 7. Няма забравен noindex.В WordPress: Настройки → Прочитане → отметката „Търсачките да не индексират този сайт“ трябва да е празна. После в Search Console → Страници проверете дали някоя важна страница е с причина „Изключена от таг noindex“.
• 8. XML картата на сайта отваря се и връща код 200.Вземете адреса от robots.txt (обикновено /sitemap_index.xml) и го отворете в инкогнито. Трябва да видите XML документ, не 404. Ако е 404, търсачките не могат да открият структурата на сайта — вижте следващия раздел за това колко лесно се случва.
• 9. Картата е подадена в Search Console.Search Console → Карти на сайта. Статусът трябва да е „Успешно“ с брой открити адреси, близък до реалния брой страници.
• 10. Тестовата версия е недостъпна за търсачките.Търсете в Google site: с адреса на тестовия сайт. Ако излизат резултати, имате дублирано съдържание, което се конкурира с реалния ви сайт. Тестовите копия трябва да са със защита с парола или noindex на ниво сървър.
• 11. Една версия на адреса, коректни canonical тагове.Отворете сайта с и без www, с http и https. И четирите варианта трябва да водят до един и същ адрес с пренасочване 301. После вижте в кода на страницата дали rel="canonical" сочи същия адрес, а не друга страница.

04Имейл доставимост — 4 проверки, които почти никой не прави

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

Механизмът е следният: WordPress по подразбиране изпраща имейли през сървърната функция mail(). Тя не се удостоверява по никакъв начин. Съобщението излиза от IP адрес на хостинга, който не е оторизиран да изпраща поща от името на вашия домейн. Формата показва зелено „Съобщението беше изпратено“, а имейлът отива в спам или се отхвърля напълно.

• 12. Изпратете тест от външен адрес и проверете спам папката.Не от служебния си имейл на същия домейн — от Gmail, от телефона на приятел, отвън. После проверете и Входящи, и Спам. Ако е в спам, точката е провалена, дори писмото да е пристигнало.
• 13. Има SPF запис, който включва реалния изпращач.DNS запис от тип TXT, започващ с v=spf1. Той казва на получателите кои сървъри имат право да изпращат поща от ваше име. Ако изпращате през външна услуга, тя трябва да е включена в записа.
• 14. DKIM е конфигуриран.Криптографски подпис, който доказва, че писмото наистина е от вашия домейн и не е променено по пътя. Без него Gmail и Outlook са значително по-подозрителни към съобщенията ви.
• 15. Има DMARC политика.TXT запис _dmarc, който казва на получателите какво да правят със съобщения, непреминали проверките. Започнете с p=none за наблюдение, преди да минете към по-строга политика.

05Скорост и Core Web Vitals — 4 проверки

Тук важното е какво и къде тествате. Резултат 98 за началната страница на настолен компютър не означава почти нищо, ако вашите клиенти влизат от телефон в продуктова страница.

• 16. Тествайте мобилно и на вътрешна страница.Пуснете PageSpeed Insights за най-важната си вътрешна страница в режим Мобилен. Това е числото, което има значение. Началната страница обикновено е най-оптимизираната и най-малко представителната.
• 17. Най-големият видим елемент се зарежда бързо.В отчета вижте кой е LCP елементът. Ако е голямо изображение в горната част, то трябва да е с приоритетно зареждане, а не с отложено — честа грешка при агресивна оптимизация.
• 18. Изображенията са в модерен формат и с посочени размери.WebP или AVIF, с атрибути width и height в кода. Без тях страницата „подскача“ при зареждане, което е директен минус в оценката за стабилност на изгледа.
• 19. Кеширането реално работи.Заредете една и същa страница два пъти в инкогнито. Второто зареждане трябва да е видимо по-бързо. Ако кеширащият плъгин е инсталиран, но не е конфигуриран, разлика няма да има.

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

06Правни изисквания и GDPR — 5 проверки

Тази група е неудобна, защото повечето изпълнители я оставят на клиента, а повечето клиенти предполагат, че е включена. Резултатът е сайт с празни шаблонни текстове.

• 20. Фирмената информация е налична и вярна.Наименование, ЕИК, седалище и адрес за кореспонденция, имейл и телефон — достъпни без затруднение, обикновено във футъра и на страницата за контакт. Проверете, че данните са реалните, а не шаблонните от демото.
• 21. Политиката за поверителност описва реалните инструменти.Отворете я и проверете дали в нея се споменават именно инструментите, които сайтът използва. Ако текстът говори за услуги, които не използвате, или не споменава такива, които използвате, документът не върши работа.
• 22. Съгласието за бисквитки реално блокира скриптове.Това е разликата между истинско решение и декорация. Заредете сайта в инкогнито и без да натискате нищо, проверете в инструментите за разработчици дали вече се зареждат аналитични и рекламни скриптове. Ако да — банерът само информира, но не изпълнява функцията си.
• 23. Формите имат отделно съгласие с работещ линк.Отметка, която не е предварително маркирана, с линк към политиката за поверителност, който се отваря. Проверете и че формата не може да бъде изпратена без нея.
• 24. За онлайн магазини: пълният набор документи.Общи условия, информация за правото на отказ и сроковете, начини на плащане и доставка, данни за подаване на жалби и за алтернативно решаване на спорове. Ако продавате на потребители, това не е опция.

07Сигурност и бекъпи — 4 проверки

• 25. Бекъпите работят и са тествани за възстановяване.Ключовата дума е тествани. Непроверен бекъп не е бекъп. Поискайте демонстрация на възстановяване или поне вижте последния успешен архив с дата. Архивите трябва да се пазят и извън същия сървър.
• 26. SSL е валиден и се подновява автоматично.Проверете срока на валидност и че цялото съдържание се зарежда по https — включително изображения и шрифтове. Едно смесено съдържание сваля катинарчето в браузъра.
• 27. Няма очевидни слабости в достъпа.Няма потребител с име admin, паролите са силни, включена е двуфакторна автентикация, а списъкът с потребители не съдържа забравени тестови акаунти с администраторски права.
• 28. Демо съдържанието е изчистено.Няма страници Lorem ipsum, няма примерни продукти, няма деактивирани плъгини, оставени „за всеки случай“. Деактивираният плъгин също получава уязвимости — той просто не се обновява.

08Съдържание и достъпност — 4 проверки

• 29. Страницата за грешка 404 е смислена.Отворете нарочно невалиден адрес. Трябва да получите страница с меню и търсачка, а не празен екран или сървърна грешка.
• 30. Заглавията и описанията са уникални.Всяка важна страница има собствено заглавие и мета описание. Ако десет страници имат едно и също заглавие, това е дефект в настройката на SEO плъгина, а не в съдържанието.
• 31. Смислените изображения имат алтернативен текст.Описателен, не запълнен с ключови думи. Декоративните изображения могат да останат без — не всичко трябва да е описано.
• 32. Сайтът е използваем с клавиатура.Минете началната страница само с клавиша Tab. Трябва да виждате къде се намирате и да достигате менюто и формите. Това е и изискване за достъпност, и добър индикатор за качеството на кода.

09Приемо-предавателен протокол: минималният вариант

Няма законово изискван формат. Смисълът е двоен: фиксира какво е предадено и от кога тече гаранцията. Един лист е достатъчен.

ПРИЕМО-ПРЕДАВАТЕЛЕН ПРОТОКОЛ
Проект: [домейн]        Дата: [дата]

ПРЕДАДЕНИ АКТИВИ
[ ] Домейн, регистрант: [фирма, ЕИК]
[ ] Хостинг акаунт на името на: [фирма]
[ ] WordPress администратор: [имейл]
[ ] Пълен архив: файлове + база данни
[ ] Собственост в Analytics и Search Console
[ ] Лицензи за теми и плъгини: [списък]
[ ] Изходен код / хранилище: [ако е приложимо]

ПРОВЕРЕНИ ФУНКЦИОНАЛНОСТИ
[ ] Форма за контакт — тестван имейл, получен извън спам
[ ] Карта на сайта отваря се, код 200, подадена в GSC
[ ] Пренасочвания от старите адреси: [брой]
[ ] Мобилна скорост, ключова страница: [резултат]

ОТВОРЕНИ ТОЧКИ
1. [описание] — срок: [дата]

Гаранционен срок: [X] месеца от датата на този протокол.
Гаранцията покрива отстраняване на дефекти в
договорения обхват, не нови функционалности.

Приел: ______________   Предал: ______________

Обърнете внимание на раздела „Отворени точки“. Той е причината протоколът да работи: позволява да приемете сайта и да платите, без да се преструвате, че всичко е перфектно. Две отворени точки със срок са много по-добра позиция от неподписан протокол и неплатена фактура.

→Какво всъщност проверявате

Тридесет и две точки изглеждат много, но повечето отнемат под минута и се провалят рядко. Реалната стойност на чеклиста е в няколко конкретни точки — 8, 10, 12 и 22 — които се провалят често и се откриват късно.

И една честна забележка към колегите: ние минахме този списък върху собствения си сайт и се провалихме на точка 8. Затова чеклистът не е за преценка на изпълнителя, а инструмент, който работи и в двете посоки. Ако тепърва избирате с кого да работите, вижте как подхождаме към изработка на сайт, или заявете технически одит на вече готов проект.