Чеклист за презапуск на онлайн магазини, сайтове за резервации и корпоративни уебсайтове.

Предстои ли ти реланс? Честито, че намери тази статия. Следващите изложения може би ще са ключова за теб, за да твоят реланс бъде успешен и да постигнеш чудесен резултат. Защото това не винаги е случая. Аз съм собственик на агенция и ще ти разкрия точно какво може да те доведе в състояние да ме принудиш, подобно на мен, да извършиш изключително добра работа и да избегнеш типичните грешки при релансиране. Нека започнем, обаче, отначало.

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

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

Има обаче няколко по-добри причини защо предприятията или организациите искат да извършат релансиране на уебсайт. Най-важните от тях са:

• Остарял дизайн и/или ребрандинг: Остарялият уебсайт може да предизвика впечатление, че предприятието не е в тренда или вече не е активно. Следователно свеж, модерен дизайн трябва да подобри имиджа. Също така, ако се променя маркетинговият образ или идентичността на компанията, често се желае релансирането на уебсайта, за да отрази новия маркетингов месидж.
• По-добър потребителски опит: Ако потребителското изживяване на уебсайта е лошо, това може да доведе до висока степен на отпадане. Релансирането може да предложи подобрение на потребителския опит и да направи уебсайта по-лесно за навигация.
• Оптимизация за мобилни устройства: Тъй като все повече хора достъпват уебсайтовете чрез мобилни устройства, важно е да се уверите, че уебсайтът функционира добре на различни размери екрани и устройства.
• Оптимизация за търсачки (SEO): Остарял уебсайт може да има проблеми с изпълнението на SEO. Релансирането предоставя възможност за въвеждане на промени, близки до SEO, за подобряване на видимостта в търсачките.
• Актуализация на съдържанието: Ако информацията, услугите или продуктите на предприятието се променят, уебсайтът трябва да се актуализира, за да отрази тези промени.
• Подобрения в сигурността: Старите уебсайтове често са уязвими за сигурностни рискове. Релансирането може да послужи за подобряване на сигурността на уебсайта и защита от кибератаки.
• Технологична актуализация: Използването на остарели технологии може да накърни представянето на уебсайта. Релансирането може да даде възможност за преминаване към актуални уебтехнологии и платформи.
• Достъпност: Подобряването на достъпността е важен аспект за много уебсайтове, за да се гарантира, че те са достъпни за хора с увреждания.
• Конкурентоспособност: За да се запази темпото с конкуренцията, е важно да се има модерен и функционален уебсайт. Релансирането може да помогне за запазването или повишаването на конкурентоспособността.
• Подобрения в аналитиката: Чрез внедряване на по-добри аналитични инструменти и събиране на данни, предприятията могат по-добре да разберат и оптимизират представянето на уебсайта.
• Съответствие с правните изисквания: Законите и правилата в областта на защитата на данните, достъпността и сигурността се променят редовно. Релансирането може да бъде необходимо, за да се уверите, че уебсайтът отговаря на тези изисквания.

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

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

Релансът винаги трябва да бъде подкрепен с факти (напр., техниката е на косъм от невъзможност за обновяване), показатели, както и данни за измерване и сравнение.

Това е първото препоръчване, което искам да направя на този етап: Еволюция пред революция! Избягвай реланса, доколкото е възможно, и опитай да реализираш всички точки, които до този момент са били представени за реланс, поотделно или постепенно. Подобри нещо, пусни го на живо, оцени какво се случва, коригирай отново или се заеми със следващата точка. Най-добрият пример е Amazon, който наистина се променя и подобрява само минимално и вече много години не се отказва от големи реланс-промени.

Релансът винаги е голям риск за твоята видимост в Google. Всички виждат подобренията, но малцина виждат риска. Разбира се, потребителският интерфейс става по-добър, положителното потребителско изживяване се увеличава, техническият аспект отново е актуален. Все пак, ако предприемаческият ти успех зависи от силната органична видимост, релансът е последното средство и само трябва да бъде взето решение, ако болката ти е достатъчно голяма поради комбинация от гореспоменатите причини, които не могат да бъдат оправени поотделно. Защо? Виж тук какво се е случило с онлайн-видимостта след релансите на тези четири уебсайта:

Планирайте внимателно вашата редизайн стратегия и гарантирайте успешното й осъществяване, като използвате чеклист. Особено важно е да си поставите две цели: да запазите онлайн видимостта си и да намерите начини да създадете основата за увеличаване на онлайн видимостта си в рамките на редизайна. Точно за това е този материал, за да ви даде ръководство за редизайн, като ви помогне да ограничите рисковете при редизайна и наистина да постигнете изключително добър резултат с потенциал за устойчиви, органични SEO успехи.

План за редизайн

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

• Анализ на съществуващия уебсайт и записване на състоянието в момента: Първоначално трябва да се направи анализ на съществуващия уебсайт, за да се идентифицират силните и слабите му страни.
• Определете целите: Целите на редизайна на уебсайта трябва да бъдат ясно дефинирани. Те включват подобряване на конверсията, увеличаване на посетителите или преминаването към нова CMS система с подобрено съдържание и поддръжка.
• Развиване на концепция: На база на анализа и целите, както и на анализа на конкурентите, трябва да се разработи концепция за редизайна на уебсайта. Концепцията трябва да включва следните аспекти: дизайн, съдържание, технология и SEO/маркетинг.
• Изпълнение: Концепцията се изпълнява. Това включва разработване на дизайн, създаване/приспособяване на съдържанието и изпълнение на техническите промени.
• Тестване: Преди публикуването на новия уебсайт той трябва да бъде внимателно тестван, за да се гарантира, че функционира безупречно. Това включва и дефинирана чеклиста.
• Публикуване: Следва публикуването на новия уебсайт. И продължава да се тества, преглежда и приспособява на живо.

Определение на целите и стратегията за редизайн

Определете точно какви цели има редизайна. Целите могат да бъдат (освен горепосочените причини): 

• Подобряване на потребителското преживяване
• Увеличаване на яснотата
• Разширяване на съдържанието
• Модернизиране на дизайна
• Увеличаване на приходите и размера на кошницата 
• Преход към друга CMS система с по-лесна поддръжка на съдържание и техническа поддръжка
• перспективно по-лесно разширяемост и запазване на актуализируемостта.

Предложение: След първите сбирки в екипа на компанията - още преди да започнат разговорите с изпълнителските агенции - всеки участник в проекта трябва да напише целите на вашия редизайн на бележка или във входната си форма във вашия комуникационен инструмент (например Slack). Когато всички покажат едновременно своите цели, ще сте изненадани как различни са мненията, въпреки че целта вече е била обсъдена на срещите. Затова е важно целите също да бъдат зафиксирани писмено. Ако знаете целите си точно, вече в ранен етап може да проверите на прототипа на UI дали те са били концептуално взети под внимание.

Техническа спецификация за поръчката на проекта по време на редизайна

Агенцията се нуждае от обширен брифинг на проекта от клиента, за да изготви оферта. Обикновено компаниите имат документ в Word или PDF формат, където по-малко или повече подробно е описано намерението. След това има анкетни листове или се провеждат работилници, чрез които агенциите по-добре изясняват болките на клиента, за да могат да направят оферта. При по-големите проекти се изготвя технически проект. Колкото по-подробно, толкова по-добре. 

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

• Цели и цел: Описание на основните цели на редизайна, като подобряване на потребителското преживяване, увеличаване на видимостта в търсачките или преминаването към CMS система с актуализиране на дизайна.
• Обем на проекта: Ясно определение на това, какво е включено в рамките на редизайна и какво не. Това може да включва броя на страниците, интеграцията на инструменти на трети лица или преработването на съдържание.
• Изисквания за дизайн: Информация за желаното визуално оформление на уебсайта, включително макетите и спазването на корпоративния дизайн по отношение на цветове, шрифтове и изображения.
• Изисквания за функционалност: Разширяване на желаните функции и взаимодействия на уебсайта, като например контактни форми, търсене, функционалности за електронна търговия и др.
• Технически изисквания: Спецификации за технологиите, които ще се използват по време на редизайна, като избор на система за управление на съдържание (CMS) или внедряване на определени функции. Също така включва използването на съвременни формати за изображения и графики (WebP, AVIF, SVG).
• Ръчни и автоматични резервни копия и прегледи на редакционните изменения.
• Изисквания за съдържание: Ясни насоки за преработка, актуализиране или създаване на съдържание, включително текстове, изображения, видеоклипове и други медии. Работа с мета-данните и структурираните данни.
• Изисквания за SEO: повече по темата в следващия раздел.
• График и мрежа от камъни: График на планираните дати за начало и завършване на редизайна, както и важни моменти по пътя.
• Бюджет: Информация за бюджета за редизайн, включително разходите за дизайн, разработка, хостинг и евентуални услуги от трети лица.
• Осигуряване на качество с тестови инструменти: Описание на тестове и процедури за контрол на качеството, които ще бъдат изпълнени по време на редизайна, за да се гарантира, че уебсайтът функционира безупречно.
• Изисквания за поддръжка и подкрепа: Изисквания за текущата поддръжка и подкрепата на уебсайта след редизайна.

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

Когато планувахме новия рестарт на TutKit.com с пълна смяна на рамката от CodIgniter на Laravel, нашето задание беше 220 страници – не много примамливо предизвикателство за агенцията да се справи с него.

Напомняне: В моя статия не ще се влиза подробно в концепцията, дизайна, функциите и използваните технологии. Новият уебсайт ще изглежда страхотно. Най-големият риск при рестарта всъщност е свързан със злоупотребата на техническото потребителско изживяване и качеството OnPage поради липса на 301 пренасочвания и др., което води до загуба на рангиране и видимост. За да се предотврати това, следва да се обърне специално внимание на осигуряването на успеха на проекта от гледна точка на потребителското изживяване и SEO.

Дефиниция на SEO изискванията за новия уебсайт

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

За Relaunch-Checkliste за Осигуряване на успеха на проекта трябва да се разгледат отделните параграфи от гледна точка на SEO. Възникват специфични SEO изисквания чрез например:

• променяща се URL структура (Карта на пренасочване на URL!) и промени в пътищата към линковете
• променяща се навигация (важно за вътрешно линкуване и линковата хиерархия)
• променящи се технологии (CMS, JavaScript-Framework, сървър, ...)
• променящи се съдържания (възможна загуба на видимост на добре класираните страници)

Страниците се класират добре в Google поради техния съдържателен релевантност, затова е важно да се поставят следните въпроси: дали съществуващите съдържания се променят или сливат, дали съдържанията изчезват и/или нови съдържания биват добавяни? Променя ли се съдържателната структура на категории или страници? От тези точки трябва да бъдат извлечени SEO изисквания, които да бъдат включени в Relaunch-Checkliste.

Дали метаданните на старите съдържания се прехвърлят и се променят ли? Как се извършва поддръжката на съдържанието от редактора и дали съдържанията на страниците са свързани със структурирани данни?

Също така следва да се обърне внимание, че изображенията се съхраняват в съвременни формати за уебсайтове (WebP/Avif) и се отделя внимание на изображенията SEO с говорещи URL-ове на малки букви, така че вместо 1234.jpg => hotel-ostsee-warnemuende_suite-nachtigall.avif.

Също така трябва да се обърне внимание, че файловете с изображения са свързани със структурирани данни (ImageObject) и <meta>-миниатюри, които се предават на Google, за да се увеличи вероятността изображенията да бъдат вградени в Search Snippets и да бъдат включени в списъка на Google Изображения.

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

Също така трябва да се провери как могат да бъдат интегрирани съдържателни секции на страниците, които отговарят на изискванията на Google за Полезно съдържание и за Принципа Е-А-Т.

За Google "Полезното съдържание" е съдържание, което е релевантно и полезно за потребителите. То отговаря на въпросите на потребителите изчерпателно и информативно, предлага решения на проблеми и предоставя добавена стойност, която излиза извън простите рекламни съобщения.

Ето няколко примера за полезно съдържание:

• Уроци и ръководства: Тези съдържания помагат на потребителите да научат нови умения или да решат съществуващи проблеми.
• Рецензии и сравнения: Тези съдържания помагат на потребителите да изберат правилния продукт или услуга.
• Новини и актуализации: Тези съдържания държат потребителите информирани за актуални събития и тенденции.
• Инфографики и диаграми: Тези съдържания могат да помогнат да се визуализират сложни данни и информация.
• Блог публикации и статии: Тези съдържания предлагат по-дълбок поглед върху определена тема.

Google използва различни сигнали, за да разпознае полезното съдържание. Те включват, но не се ограничават до:

• Потребителско поведение: Google наблюдава как потребителите взаимодействат със съдържанията, например колко дълго остават на страница, колко често я споделят и оценяват.
• Сигнали за качество: Google оценява качеството на съдържанието въз основа на фактори като релевантност, пълнота и актуалност.
• Обратна връзка от потребители: Google взема предвид и обратната връзка от потребителите, като оценки и коментари.
• Чрез отчитане на тези сигнали, уебсайтовите собственици могат да увеличат вероятността си съдържанието да бъде оценено като полезно.

Принципът EEAT е концепция, разработена от Google, която оценява качеството на уебсайтове и уебсъдържание. Той представлява Експертност, Опит, Авторитет и Надеждност, с други думи Експертност, Опит, Авторитет и Доверие.

• Експертността се отнася до знанията и опита на хората, които създават съдържанието. Google оценява експертността чрез фактори като образование, професионален опит и награди.
• Опитът се потвърждава, когато съдържанието е създадено с определен опит, например базиран на реалното използване на продукт, посещението на място или описание от човек, който го е изживял?
• Авторитетът се отнася до репутацията на уебсайта или уебсъдържанието. Google оценява авторитета чрез фактори като обратни връзки, дейност в социалните медии и потребителски рецензии.
• Надеждността се отнася до надеждността и доверието в уебсайт или уебсъдържание. Google оценява надеждността чрез фактори като защита на данните, сигурност и прозрачност.

Какви SEO изисквания имат съществуващите и нови Функции свързани с frontend и backend? Тук става въпрос за например:  

• Достъпност за сканиране (съответното съдържание трябва да е видимо и достъпно за сканиране дори без JavaScript)
• Яснота относно целта на уебсайта и яснота за призив към действие (желаното поведение на целевия клиент на страниците)
• Предотвратяване на дублиращо съдържание, например автоматично създадени страници на категории или дублиращи се страници с вариантни артикули
• Осигуряване на висок PageSpeed чрез избягване на прекомерно много JavaScript и CSS файлове, чрез използване на модерни формати за изображения (WebP/AVIF)

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

Определяне на вътрешните и външни участници в проекта

Определете участниците в проекта - тук от гледна точка на клиента или собственика на уебсайта: 

• Кой носи отговорността за управлението на проекта и взема окончателните решения? 
• Кой носи отговорността за координацията и комуникацията с агенцията или с клиента? 
• Кой поема вътрешното управление на проекта?
• Кой подготвя вътрешно съдържанието и помощно материалите за агенцията?
• Кой осъществява дизайн за потребителски опит? 
• Кой осъществява разработката? 
• Кой докладва на клиента от страна на агенцията в определени интервали?
• Кой поема тестовете и гарантира качеството от страна на агенцията/клиента?
• Да се свърже ли външен консултант (например за SEO или правни изисквания)?
• Кой одобрява задачите? Кой взима задачите след обработката в системата с билети?
• Кой трябва да бъде информиран и кога (служители, клиенти, партньори, отговорници за рекламни кампании и др.) 

При избора на външни участници в проекта, четири неща са важни

1. Агенцията е осъществила един или повече проекта от този вид? Има ли справки? Съществуват ли мнения на клиенти и би било възможно и разговор с клиентите на агенцията - което е препоръчително при големи индивидуални разработки?
   
2. Дали са изпълнени вече всички изисквания относно областта на офертата и техническата реализация (CMS/платформа/рамка), които са свързани с преустройството? Има ли индивидуални функционалности или изисквания, които все още трябва да бъдат програмирани (също чрез плъгин или модул)? Дали има определени услуги, които са изключени или са предвидени за по-късен момент, но са ключови за успеха на проекта? Важно е, че не възникват нови проблеми, по-големи от фактическата причина за преустройството.
   
3. Подхожда ли изпълнителната агенция или доставчикът както по отношение на размера на екипа, така и по отношение на регионалното местоположение и наличието на мобилност на служителите (ако е възможно да се определи чрез рейтингите на Kununu) дългосрочно за бъдещата поддръжка на компанията?
   
4. Дали е възможен пряк контакт с дизайнерско и разработващо екип? Важно е да се запознаете лично с фактическия екип на агенцията. Усмихнатите преповдигатели на небето и продавачите вече не са отговорни. Затова е добре, да се предвиди директен контакт с отговарящия екип за изпълнение.

Четири съвета за собствената си защита в този контекст

1. Като клиент, бих обърнал внимание на използваната технология на агенцията. Това, което е предложено, просто го потърсете в Google с "CMS + Недостатъци" или "CMS + Опити". Трябва да знаеш точно за какво става въпрос. Разумен избор е да се използват отворени решения. Разбирам, че това не винаги е възможно. Най-добре е да се обърне специално внимание на наличието на възможно голяма общност на разработчици за използваната технология, за да не завършите с агенътски индивидуални решения, които само вашата агенция може да обработва, което по някакъв начин в последствие ви довежда до значителни затруднения.
   
2. Обърнете внимание също на факта, че получавате неограничени права за използване и редактиране на услугата на агенцията, за да може винаги да имате правото да продължите да развивате уебсайта вътрешно или външно. Такава клауза трябва да е в договора за изпълнение на работата.
   
3. Ако вашата компания е по-технична и има системни администратори, софтуерни разработчици или подобни в екипа си, е разумно да настроите GIT за управление на версиите и JIRA (или подобен инструмент) за управление на проекта или системата с билети първоначално самостоятелно в собствен акаунт. След това предоставете пълни права за достъп на агенцията и работата може да започне. При по-големи проекти може да се възникнат проблеми. Затова е добре, ако имате контрол над ключовите достъпи и акаунти. Разбирам, че този съвет се съразглежда от само малка част от клиентите по само технически причини.
   
4. Понякога се случва, че агенциите предлагат директно хостинг услуги на клиентите си. Ние сами не сме почитатели на този подход, защото от една страна увеличава зависимостта в клиентските взаимоотношения, а от друга страна смятаме, че хостинг доставчиците са най-добре подготвени за услуги на хостинг, тъй като са специализирани за това. Ние сами сме инсталирали и управлявали сървъри и сме изгубили много човешки и времеви ресурси. Ние сме се отдръпнали обратно. Сега нашите системи се изпълняват на облачни сървъри на един от големите хостинг доставчици в Германия и сме щастливи. При хостинг услугите винаги се уверете, че вече са включени резервни копия на сървъра, които могат да бъдат възстановени с няколко клика.

Определяне на периода и срока за стартиране

Редизайнът се извършва чрез няколко проектни спринтове. Те могат да бъдат според нашето агентствено изживяване:

• Състоянието се документира (чрез тестови инструменти, но също и писмено с впечатления за това, какво работи добре от страна на клиента и къде са необходими подобрения)
• Фаза на изследване с анализ на конкуренцията и изследване на решения/вдъхновение
• Концепция на жичената рамка
• Дизайн на потребителския интерфейс
• Фронтенд и бекенд разработка
• Миграция на данни или импорт на съдържание (автоматизирано/ручно)
• Структурни и съдържателни оптимизации (текст и изображение) & SEO спринт

Проектните спринтове се препокриват, тъй като по време на обработката нови участници в проекта стават активни.

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

За клиента за проекта, ако е по-голям, агенцията създава собствен канал в Slack за по-бърза комуникация?

Един съвет на този етап: Добре е, ако агенцията вече работи с кликабилни прототипи в много ранен етап, т.е. вече по време на концепцията на жичената рамка и още повече при представянето и проверката на дизайна на потребителския интерфейс. По този начин клиентите по-добре разбират усещането за уебсайта. Прости JPG или PNG файлове като предложение за оформление вече не са съвременни. Те трябва да бъдат кликабилни прототипи, които се разработват с Sketch, Figma, Adobe XD или друг професионален инструмент.

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

Тук можем да видим как изглежда такъв прототип за мобилния дизайн на потребителския интерфейс с пътищата за щракане в преглед:

Трябва да се разреши въпросът кога могат да се изпълняват активни тестове от страна на клиента. Разработчиците трябва да тестват своите локални работи след сливането им във Stage-системата. Звучи тривиално, но всеки, който работи с разработчици, веднага разбира какво имам предвид. След това този, който е отговорен за качеството от страната на агенцията, трябва да тестви билета или функцията.След това тази функция става на разположение за тестване от клиента. Клиентът не трябва да се чувства като алфа тестер, а по-скоро да има система, тествана от четири очи. Агенцията е алфа тестер, а клиентът е бета тестер! Има ли въобще достъп до системата за билети на агенцията?

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

Дата на стартиране трябва също да бъде уточнена. Според Закона на Паркинсън работата се разширява така, че да използва наличното време за изпълнение, а не независимо от реалната сложност или работните усилия. Планираното завършване трябва да бъде включено в договора. Пренебрежването на срока може дори да бъде предвидено със застрашително обезщетение в договора. Като насоки важат, че застрахователните обезщетения от 0,2 % от цената на поръчката на ден от забавянето и максимум 5 % от цената на поръчката са ефективни. Застрахователното обезщетение не е необходимо задължително да се изисква от страна на клиента, но ви дава възможност да извадите още няколко специални искания от агенцията като компенсация.

Важно: Не стартирайте в петък. Нито между празниците, нито по време на основния работен час на компанията. Ние наистина препоръчваме да стартирате голямите промени в нощта от неделя към понеделник, особено ако IP адресът се променя, за да DNS настройките в повечето доставчици да се актуализират отново в понеделник, което често се случва в края на съботно-вечерния период, ако DNS записът е променен през нощта. Така фактически остават още 4,5 работни дни за животест и отстраняване на грешки при възникнали проблеми.

Документиране на текущото състояние на вашия уебсайт

Състоянието преди началото на работите трябва да бъде установено. В текущото състояние се установява какви са техническите резултати за параметрите. Вляво може да въведете целевите стойности:

В списъка ще намерите Seobility като SEO инструмент, който често използваме за проверка на OnPage-факторите, към които добавих и SEO обучение. Има много алтернативи като Sistrix, Semrush, Ryte, SE Ranking, Screamingfrog и други. За SEO инструмента е важно, основно, да се идентифицират и отстранят типичните грешки на OnPage. Тук те са трите основни области: Техника и Мета, Структура и Съдържание, както Seobility построява оценките си. Подобно на това се намира и при другите SEO инструменти. Важно е, от една страна, винаги да се извършва цялостна проверка, тоест да се крават ВСИЧКИ страници, а не само началната, и от друга страна, да въведете резултат или стойност на грешка за текущото състояние и стойността за целта, която трябва да се постигне след оптимизацията. За Seobility е желателна стойност от 90 или по-голяма. Също така ще намерите алтернативни инструменти за други цели. Важно е да се използва поне един, за да се гарантират изключителни данни.

Например, това е нашата текуща стойност за качеството на страниците:

Сигналите от потребителите могат да бъдат статистически засечени с метрики от Google Analytics 4 като рейтинг на отпадане, страници/посещение, продължителност на престоя и др. При правилното използване на Google Analytics или друг инструмент за анализ, тези данни също трябва да бъдат взети предвид при оценката на текущото състояние.

Трябва да се създаде списък на обратните връзки, който може да се генерира например тук безплатно: https://www.seobility.net/de/backlinkcheck/

Освен това трябва да се съхранява старият sitemap.xml, както и пълен бекъп на страницата. Всички релевантни страници трябва да се прехвърлят като списък в Google Sheet, който служи като основа за Карта за пренасочване на URL адреса. Такъв CSV списък може лесно да се експортира чрез SEO инструмент като Seobility. В Картата за пренасочване на URL адреса се вземат под внимание всички релевантни страници и свързани страници чрез външни обратни връзки (вижте списъка с обратните връзки), които трябва да бъдат пренасочени по-късно поради променящите се URL адреси на страниците. Местата, където URL адресите изчезват, трябва да бъдат пренасочени към новите, съответстващи на старите URL адреси. Важно е да се избегнат верижни пренасочвания! Старите, все още съществуващи пренасочвания трябва директно да бъдат пренасочени към новия крайен URL адрес. Също така трябва да се мисли за PDF файлове и изображения, към които има връзки, така че те да бъдат пренасочени коректно и да не станат 404-линк.

Пренасочването се извършва като 301-пренасочвания на база на Картата за пренасочване на URL адреса в .htaccess, чрез Redirect-Maps чрез Vhost-конфигурация или чрез решение с база данни. Клиентът трябва да може да ги поддържа. Важно е също така да се уверите, че пренасочванията са постоянни.

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

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

Чеклист: Преди Релиз

След като потребителският интерфейс е одобрен и агенцията е в средата на разработката, следният чеклист става важен, изброяващ хронологично най-важните точки преди деня на релийза:

1. Dev-среда с достъп за всички участници е налична за тестване
2. Dev-средата работи на noindex
3. Достъпност за тестови инструменти на Dev-средата (разрешение на IP адрес или http-вход) е направена
4. Конфигурацията на Dev-средата съответства на възможно най-добрата на Животните
5. Структурата на Dev-средата съответства на тази на бъбдещата Живо-Страница
6. Прехвърляне на данните от старата страница е завършено
7. Адаптации на съдържанието са извършени
8. SEO на изображенията е извършено
9. 301-Пренасочвания на базата на Картата за пренасочване на URL адреса са настроени
10. OnPage-проверката с Seobility е завършена, грешките са отстранени, целевите стойности са постигнати
11. Open-Graph данните са валидни
12. Структурираните данни са валидни
13. Проверката на Pagespeed за всички типове страници е влязла, целевите стойности са постигнати
14. Политиката за бисквитки на съдържанието работи
15. Сигурностните заглавия са настроени
16. Бариерната достъпност е налична, целевите стойности са постигнати
17. Hreflang е валиден (при многоезични страници)
18. Правни текстове (ОПЩИ УСЛОВИЯ, ИМПРИТ, ДЕКЛАРАЦИЯ ЗА ОТКАЗ, ЗАЩИТА НА ЛИЧНИТЕ ДАННИ) са актуализирани, съобразно GDPR
19. Актуализация на CMS, Frameworks, използвани плъгини и модули на най-новата версия
20. Финален браузърен тест и функционален тест между изходният и устройствен код не показва грешки
21. Финален статус и известен е денят на старта 
22. Създаден е пълен бекъп

Използването на структурирани данни (Схемен Маркъп) - вж. точка 12 от списъка - все още не се взема достатъчно под внимание. Запознайте се с темата и прочетете какво Google казва за Маркираните данни в резултатите от търсенето. Google все повече ще оценява валидни данни в рамките на SGE, създадените от Изкуствен интелект резултати от търсене. Също така, Helpful Content Update от Google изисква съдържанието да бъде значително по-верифицирано чрез експертиза, опит, авторитет и доверие. Структурираните данни са част от решението, за да се опрости тази валидация за Google. След вграждането на структурираните данни използвайте Schema-Markup-Validator, но също и проверяйте страниците си с Structed Data Linter, който Google също препоръчва и свързва в PageSpeed Insights. Там ще получите по-изчерпателна информация за грешки в кода, свързани с използването на структурирани данни.

Използването на структурирани данни в уебсайтове вече не е опция, а задължителност. Google иска от вас валидни и достоверни съдържания. Ако не искате да бъдете изоставени от резултатите от търсене, базирани на изкуствен интелект, грижете се за Schema-Markup на страниците си!"

При точка 16 вече се появява за първи път Бариерна достъпност в тази статия. Вече при PageSpeed Insights бариерната достъпност има собствена област и зелените цифри са пожелателни. Тестът дали страницата е бариерно достъпна или не, трябва да се извърши наред с PageSpeed Insights и с помощта на https://www.accessibilitychecker.org и/или https://wave.webaim.org. Особено ако предстои редизайн, тази точка трябва задължително да бъде взета предвид, тъй като за уебсайтовете в сила е законът за укрепване на бариерната достъпност от 2025 година. Проверете с такъв инструмент не само началната страница, а всеки тип страница - важно е същото и за тестовете на страницата!

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

Точка 18 - с актуализацията на CMS, използваните Javascript библиотеки, инсталираните модули и допълнения е също толкова недооценена, колкото и важна. Редизайнът може да се оттегли в продължение на няколко месеца и повече. Със системата WordPress е лесно да се види, че може би преди деня на редизайна вече са налични множество актуализации. Клиентите трябва да се погрижат, че на Гоу-Лайв се използват най-новите версии.  

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

• Импортиране на данни за контакти за бюлетин в новата услуга
• Свързване с услугата за бюлетин на уебсайта във формуляра за регистрация
• AV-договор
• Създаване на нови шаблони за мейлинги
• и така нататък 

През целия период на разработка се извършват постоянни тестове на функциите и т.н. Ефективно е да се направи много подробна контролна точкова листа за тестове, така че нищо да не се забрави. Не е достатъчно както за агенцията за изпълнение, така и за клиента просто да кликат навсякъде. След нашия редизайн на TutKit.com, нашата контролна точкова листа за одобрение със сигурност имаше около 1 000 реда. И така го правим и до ден днешен: след важни големи обновления правим около 70 интеракции чрез контролна точкова листа за Chrome, Safari и Android.

Контролна точкова листа: Денят на редизайна и следващите дни

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

1. Провери robots.txt, че роботите не са блокирани 
2. Индексирането на живата среда е на index, follow.  
3. Canonical-таговете са правилно зададени
4. Проверете изходен код на страницата за абсолютни пътища (линкови пътища на тестовата среда върху страницата в живата среда)
5. Пренасочване от http към https с/без www към целевата страница на началната страница и на подстраниците работи
6. Тествайте пренасочванията чрез URL-Redirect-Map, също така проверете за съществуването на вериги от пренасочвания
7. OnPage проверка на живата страница с помощта на Seobility за Технически & Мета, Структура и Съдържание … особено проверете Noindex-страници, които се виждат чрез Seobility
8. Open-Graph данните са валидни
9. Структурираните данни са валидни
10. Проверка на Pagespeed за всички видове страници е извършена, постигнати са целите стойности
11. Бисквиткена политика с Consent-Cookie-Инструмента работи, както трябва
12. Заглавията на защитите са конфигурирани
13. Бариерната достъпност е гарантирана
14. Проверете hreflang при многоезични уебсайтове (https://app.sistrix.com/de/hreflang-validator)
15. Финален тест на функциите на браузъра и устройството не откри грешки
16. Подновете новата sitemap.xml в Google Search Console
17. Обновете новите целеви страниците в Google-Ads-кампаниите
18. При определени промени в домейна мислете за връзките в социалните медии, мейловите подписи и т.н.

Използваме Mailhog в нашата Dev-среда, за да тестваме имейли локално. В такива случаи е важно да се уверите, че са конфигурирани правилните SMTP данни за Получаване на имейли в реална система, така че имейлите да попадат на мястото, където трябва. Също така трябва да се обърне внимание, че при Платежни доставчици като PayPal в Dev-системата се използва песочницата, докато разбира се в реалната система трябва да се установи правилната връзка.

През следващите дни е важно да се наблюдава Google Search Console. Най-интересното е разбира се как се променят вашият ранглистинг. Съсредоточете се по-специално върху неочаквани промени и съобщения за грешки:

1. Краулинг: Статус на хоста ... Извличане на robots.txt, DNS разрешение, сървърна връзка
2. Статистика на краулинга ... Заявки, големина на изтеглен файл, средно време за реакция
3. Кликове в SERPs
4. Импресии в SERPs
5. Среден CTR в SERPs
6. Средна позиция в SERP
7. Успешност на основните уеб качества

Преди всичко Google Search Console известява за грешки като URL-грешки, Href-Lang грешки, индексиране на страниците с разпространено индексиране/неиндексиране. За неиндексирането трябва да има причина (пренасочване, noindex)...). Вие виждате и дублирано съдържание или други проблеми. Ако Search Console ви сигнализира за проблеми със структурираните данни или основните уеб качества, трябва да ги изследвате. Само чрез живи данни ще разберете, например, че страници от вас, въпреки високия си PageSpeed, имат проблеми с основните уеб качества, например чрез CLS грешки. Тук е добре видно какви подобрения са възможни при промени в уебсайта:

Можете директно да видите лошите или подлежащи на оптимизация URL адреси. Вземете един URL адрес и направете тест на страницата си в PageSpeed Insights. Там ще получите указания защо основните уеб качества не се изпълняват и какво можете да направите, за да ги отстрани. Кликнете на малката стрелка надолу за по-подробна информация. Както правило тези препоръки могат да се изпълнят само от разработчици. Важно е обаче да сте в състояние да идентифицирате проблемите, за да ги решите с помощта на вашето агенство.

Също така, проучете данните си от вашите аналитични инструменти, например от Google Analytics 4. Също така следете мерките, които можете да измерите системно, като например резервации, конверсионен процент, стойност на кошницата, покупки/оборот на ден, броя регистрации за бюлетин, запитвания за контакти, изтегляния на определени съдържания или гледания на видео.

Статистиките за краулинга в Google Search Console са от съществено значение за проверките в следващите дни. Можете да ги видите чрез настройките в менюто вляво. Трябва да има по-голяма активност на краул. Ако това не се случва, дали има грешки на краулинга?

Статусът на хоста ви дава директно видими грешки, например след един редизайн, когато заявките на краулъра за robots.txt не са успели и връзката към сървъра се е прекъсвала отново и отново:

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

Можете да разберете дали вашият сървър, вашият PageSpeed и вашият код са относително добри, когато времето за реакция на страниците ви е под 400. Чим по-близко стойността е до 1000 мс, толкова по-подходящо е да се направят подобрения в PageSpeed, например чрез намаляване на заявките към базата данни и усиление на мощността на сървъра (напр. повече изчислителна мощност, обновяване на най-новия софтуер на сървъра, преминаване към HTTP2 или HTTP3 (при използване на Nginx)).

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

Чеклист за редизайн за изтегляне

Предоставените по-горе чеклисти за редизайн също са налични като PDF файл за изтегляне. Изтеглете ги и си гарантирайте успеха на проекта си!

Изповедите на един собственик на агенция

Изискванията за SEO в чеклиста могат също да включват подробни инструкции като спазване на структурата на заглавията от H1 до H6 и така нататък. Определянето на целеви стойности в тестовите инструменти ще съкрати целия чеклист за редизайн съдържателно, защото постигането на високите цели от тестовите инструменти, споменати в чеклистата, може да се постигне само чрез спазване на чист код, използване на модерна технология, внимание към SEO OnPage факторите и т.н. В противен случай трябва да се формулират най-новите уеб стандарти и технически и SEO изисквания много подробно в техническата спецификация, което клиентите фактически не са в състояние да свършат. Ако агенциите трябва да постигнат високи стойности в тестовите инструменти, те нямат друг избор, освен да работят по най-добрите практики - дори за агенциите е ново преживяване :-)

Е време за една изповед. Определянето на SEO изискванията, както и подходът като чеклист с осигуряване и постигане на целевите стойности в различни тестовите инструменти представлява идеал, който е рядко срещан в реалността. Това зависи от:

• ограничения от страна на клиента с бюджетни ограничения
• интереси за оптимизиране на печалбата от страна на агенцията
• ограничения, свързани с използваните технологии
• и за съжаление също: липса на познание и некомпетентност от двете страни

Не мога да виня клиентите. Те търсят професионална помощ и почти всяка цифрова агенция пише на своя уебсайт и в бели документи, че оптимизацията за търсачки е една от техните ключови компетенции. Винаги има и препоръки, които доказват, че след преизпълнението беше постигнато увеличение на онлайн видимостта със стойности от 3, 5 или 10 пъти. Че от 10 посетители сега идват 100 на ден, е 1000-процентно увеличение, но все още не е успех. Много от успехите в търсачките се дължат на факта, че конкурентите просто са много по-слабо дигитално подготвени.

Агенциите продължават да извършват средни дейности със старомодни методи, защото все още не използват съвременни инструменти за гарантиране на качеството, въпреки че на всяка стъпка в публикациите, препоръките, най-добрите практики и т.н. се твърди, че има SEO компетентност. Вероятно такива агенции са знание-гиганти, но с изпълнение-джуджета. Това звучи строго, но това е правилото. Наистина. Радвам се, че сте готови да го разгледате най-обстойно! Вземете гореизброената чеклиста и посочете най-добрата агенция от региона, от който произлизате, с URL адреса й в гореспоменатите инструменти. И след това вземете най-новата сайт-референция, която намерите от агенцията, и я повторете. Какви резултати ще видите? Точно тези, които трябва да очаквате в сътрудничеството. Също така можете да проверите и нашите собствени референции, като ще откриете, че дори и в нашите клиентски проекти не винаги постигаме най-високите резултати. Този работен процес с позицията на данните-ориентирани за гарантиране на качество нараства от проект в проект и се установи главно чрез нашите усилия в TutKit.com. 

Подобни проверки могат да бъдат направени с почти всяка агенция, защото само малка част реално работи с данни при гарантирането на качеството, защото никоя не се задържа на пазара със свои проекти през годините и не се съревновава в остра битка за онлайн видимост с международните играчи и защото за агенциите почти е без значение дали проектът е успешен или не, докато се плаща фактурата на агенцията и клиентите могат да празнуват с красиви (но качествено средни) уебсайтове в своите публикации и с награди. Особената ирония в това: След гореспоменатите тестови инструменти често се оказва, че точно SEO агенциите със своите собствени уебсайтове се представят най-лошо, защото често като единичен номер предлагат само такава методология ... пакет със съдържание, изградено около ключовите думи на клиента за уебсайта. За другите технически изисквания често липсват компетентните разработчици.

Предимство е също ако агенцията е на друго място и клиента не го срещаше по време на пазаруването в хипермаркета като отговорен служител на агенцията, който просто преподнася намаление на видимостта на двуцифрен процент след преизпълнението. Но такова намаление на видимостта клиентите все още рядко проверяват, защото всички имат банер за съгласие с бисквитки, но малцина наистина оценяват цифрите и изваждат действия за изпълнение. Ако се налага, трябва да се увеличи бюджетът за реклама. Че днес ранжирането чрез органични резултати презлавга от предложението на сходни уебсайтове с високо съдържание от технически параметри, сигнали от потребителите (все още) и обратни връзки, клиентите щастливо не го знаят. И с AI инструменти за текст уебсайтовете се ще подобрят по отношение на съдържание в никога до този момент количествено и качествено и скоро ще приветстваме много нови уебсайтове от чужбина на нашия език в резултатите от търсенето, защото с помощта на AI инструменти за превод стана все по-лесно да се превеждат онлайн магазини, портали, SAAS и други уебсайтове и да нападат дигиталния домашен пазар. Ето че се готвим за трудна конкуренция. Тя само сега започва ...

Заключение за данните-ориентирания чеклист за релансиране на уебсайт

Този вид чеклист е един от малкото ефективни начини да се накарат агенциите задължително да работят добре. Дори е препоръчително да се направи постигането на определени стойности в инструментите за тестове за критерии за приемане. Трябва да се регулира по договор, че част от плащането може да бъде изискано след четири седмици след преизпълнението, ако всички важни данни са налице и потвърждават успешното постигане на високите стойности (като например основни визуални и валидирани продуктови парчета след Schema-Markup в Search Console). С помощта на този работен процес - както е описан в тази публикация - загубата ви на видимост след реалнс със силни съдържателни, структурни и технически промени ще остане ограничена и ще създадете основата, за да Google скоро да рангира по-високо уебсайта ви или вашия онлайн магазин.

Ако статията ви е интересна, нямайте колебание да проверите и другите съдържания от нас:

1101,908,1066,1086

Какво?	Кратко описание	Тестов инструмент	Текуща стойност	Целева стойност
Техника & Мета	Заглавие на страницата, заглавия, мета данни, текстове за алтове, …	Seobility
Структура	Пренасочвания, грешни връзки, карти на сайтове, ...	Seobility
Съдържание	Сравнение на ключовите думи, правописни грешки, твърде малко текстове, ...	Seobility
SEO на изображения	Говорещи URL адреси, модерни уеб формати (WebP/AVIF), <мета>-тумбнейлчета	няма
Имплементирани данни от OG	Отворени графични данни за социални медии	Open Graph Checker
Структурирани данни (Schema Markup)	Schema-Markup / структурирани данни	Schema.org
PageSpeed за началната страница	PageSpeed за мобилния/десктоп	PageSpeed Insights
PageSpeed за страницата за кацане	PageSpeed за мобилния/десктоп	PageSpeed Insights
PageSpeed за страницата на категория	PageSpeed за мобилния/десктоп	PageSpeed Insights
PageSpeed за продуктовата страница	PageSpeed за мобилния/десктоп	PageSpeed Insights
PageSpeed за страницата на блога	PageSpeed за мобилния/десктоп	PageSpeed Insights
Достъпност за хора с увреждания спрямо типовете страници	Гарантиране на достъпност за засегнати потребителски групи	Accessibility Checker и/или wave.webaim.org
Проверка на Hreflang	За многоезичните уебсайтове	Hreflang Validator
Заглавия за сигурност	Доверие и сигурност	SecurityHeaders.com
Health-Check	Доверие и сигурност	Security Audit (Astra)
Проверка на браузъри и устройства	Edge, Firefox, Safari, Chrome десктоп & мобилни устройства, iOS & Android	Dev-Tools / Lambdatest
Политика за бисквитките и GDPR	Съгласие - политика за бисквитките и съобразност с GDPR	Cookie Metrix
Crawling: Статус на хоста	Заявка за robots.txt, DNS резолюция, свързаност със сървъра	Google Search Console
Статистика за Crawling	Заявки, размер на изтеглените файлове, средно време за реакция	Google Search Console
Кликвания в SERP	За времеви период (месечно/90 дни, ...)	Google Search Console