GO4 — Как се използва

Практично клиентско ръководство за настройване, използване и разбиране на GO4.

1. Кратко въведение

GO4 е система за наблюдение на сайтове, която комбинира сървърни проверки, контролирани Browser Lab зареждания и браузърни сигнали от реални посетители чрез JS агент.

Целта ѝ е да помага на екипи и клиенти да разберат навреме, когато важна страница, Shopify функционалност, SEO настройка или браузърен сигнал започне да дава проблем.

Системата е подходяща за:

• онлайн магазини;
• Shopify сайтове;
• корпоративни сайтове;
• блогове и медийни сайтове;
• целеви страници;
• други обикновени сайтове.

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

• дали сайтът се отваря нормално;
• дали важна страница връща очакван HTTP статус;
• дали даден текст присъства или не присъства в HTML-а;
• дали Shopify продукт може да се добави в количката;
• дали Shopify продукт има нужните тагове;
• дали Shopify продуктови изображения покриват минимална резолюция;
• дали избрани или автоматично открити Shopify продукти имат очакваните тагове, изображения, наличност и проверки на вариантите;
• дали размер, компонент или друг вариант има неочаквана разлика в цена според зададените правила;
• дали Shopify колекция не е празна;
• дали страница има title, meta description, canonical, robots/noindex и H1;
• как се зарежда конкретна страница в контролирана браузърна среда чрез Browser Lab;
• дали важен потребителски път минава успешно в контролирана браузърна среда, например избор на вариант, добавяне в количка или достигане до checkout страницата;
• дали JS агентът е инсталиран и изпраща браузърни събития;
• дали реални браузъри засичат JavaScript грешки или бавно зареждане;
• кои браузърни ресурси, външни скриптове, медия, видео файлове или fetch/XHR заявки най-често участват в бавни зареждания;
• кои външни доставчици, уиджети от приложения, вградени елементи или tracking/pixel ресурси създават проблеми на конкретни URL-и;
• история на проверките, предупреждения, неуспех състояния и инциденти.

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

2. Какво включва GO4

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

3. Основни понятия

Сайт

Сайт е сайтът, който системата наблюдава.

Примери:

• https://example.com
• https://my-store.com
• https://blog.example.com

Всеки сайт има име, Основен URL, платформа, организация, интервал по подразбиране, активно/неактивно състояние и настройки на JS агента.

Организация

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

Проверка

Проверка е конкретно правило към даден сайт: достъпност на началната страница, SEO на началната страница, Cart API проверка, JS Agent сигнал за активност, Sitemap SEO одит и др.

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

Активна и неактивна проверка

• Вкл. / Активна — проверката участва в автоматичното наблюдение.
• Изкл. / Паузирана — проверката не се изпълнява автоматично.

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

Изпълнение

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

Статус

Влияние върху статуса

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

Инцидент

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

Грешка

Грешка / проблем е конкретната причина: липсва H1, къса meta description, canonical несъответствие, празна Shopify колекция, браузърен DOM предупреждение и др.

Заглушена грешка

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

Конфигурационна бележка

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

При Одит на продукти това често означава, че продуктът е извън обхвата на ценово или variant правило. Бележката помага да разберете покритието на проверката, без системата да създава фалшиви предупреждения.

Конфигурационните бележки не трябва да влияят на статус, инциденти, известия или активни броячи в Табло.

4. Първи стъпки

4.1. Влизане в системата

1. Отворете публичната начална страница на системата.
2. Въведете имейл и парола.
3. Натиснете бутона за вход.
4. След успешен вход ще влезете в интерфейса на GO4.

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

4.2. Първа ориентация в Таблото

След вход първо отворете Табло. Това е контролният център на GO4.

Там ще видите KPI карти, тренд на здравето, проблеми по тип, здраве на сайтовете, бързи действия, отворени инциденти и последни изпълнения. Някои секции се показват само когато има данни или активен проблем.

Когато анализирате конкретен сигнал, отворете съответния източник: сървърни проверки, Browser Lab, JS Agent или одит. Така ще видите детайла зад общото състояние.

4.3. Как да разберете дали всичко работи нормално

Проверете тези места:

1. Сайтове — сайтът трябва да е Активен и Здраве да е OK.
2. Проверки — важните проверки трябва да са Вкл.
3. История — последните изпълнения трябва да имат скорошно време.
4. Инциденти — не трябва да има отворени инциденти.
5. Проверки → JS Agent — ако използвате agent.js, трябва да има браузърни събития и сайтът да показва последна активност.

4.4. Shopify: вграден старт на мониторинга

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

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

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

Growth включва Заяви съдействие за настройката за помощ с първоначалното покритие. Scale включва Заяви преглед на покритието за по-разширен преглед на критичните пътища в магазина. Starter използва самостоятелния процес за настройка и документацията.

Директният GO4 достъп е по желание и не е необходим за използване на GO4 през Shopify. За нов Shopify магазин настройката за директен достъп става налична след активиране на план. След това по желание можете да добавите потвърден имейл и парола за нормален GO4 вход извън Shopify.

5. Добавяне на нов сайт

5.1. Стъпки

1. Отворете Сайтове.
2. Натиснете Добави сайт.
3. Изберете организация.
4. Въведете Име на сайта.
5. Въведете Основен URL.
6. Изберете Платформа: Shopify или обикновен сайт.
7. Настройте Интервал по подразбиране в минути.
8. За Shopify сайт, при нужда добавете валиден Shopify crawler подпис.
9. Изберете дали Сайтът е Активен.
10. Изберете дали JS агентът е включен.
11. Запазете с Запази сайта.

5.2. Основни полета в Сайт

5.3. Настройки на JS агента в Сайт

JS агентът е браузърен скрипт, който може да праща сигнали от реални браузъри към системата.

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

Как работи Процент на извадката

Процент на извадката контролира колко често JS агентът изпраща браузърно събитие към системата.

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

Това не е точна квота. Например ако сайтът има 100 зареждания на страници на ден и Процентът на извадката е 1%, очаквано може да има около 1 събитие, но е възможно в даден ден да има 0 събития или повече от 1 събитие.

Процентът на извадката влияе директно на Client-side JS Agent проверка. Ако процентът на извадката е твърде нисък, проверката може да покаже предупреждение за липса на скорошно браузърно събитие, дори агентът реално да работи.

Практична препоръка: за сайтове с нисък трафик използвайте 100% извадка и по-голям прозорец за Максимум минути без браузърно събитие. Ниски стойности като 1–5% са подходящи основно за сайтове с много висок трафик.

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

За свързан Shopify магазин настройката има две отделни части: първо включете JS Agent в GO4, а след това от Проверки → JS Agent използвайте Open Theme Editor, включете Storefront monitoring в Shopify App embeds и натиснете Save. И двете части трябва да са включени, за да получава GO4 браузърни събития. За този Shopify flow не е нужно да поставяте ръчно script код в темата.

За директно добавен или обикновен сайт — включително Shopify сайт, който не е свързан чрез GO4 Shopify приложението — използвайте показания от GO4 site-specific agent.js snippet и го добавете в сайта по обичайния начин.

След като JS Agent е активен на storefront-а, създайте проверка от тип Client-side JS Agent проверка, която оценява последното релевантно браузърно събитие.

5.4. Shopify crawler access

Shopify crawler access е настройка по желание за свързан Shopify магазин. Тя използва Shopify Web Bot Auth crawler signature, за да помогне на GO4 да прави по-надеждни автоматични проверки на публичния магазин и одити, когато Shopify ограничава автоматични заявки.

В Shopify Admin отворете:

Генерирайте crawler signature. След това отворете настройката за crawler access в GO4: при достъп през Shopify или Shopify full dashboard използвайте Administration → Crawler access; при Direct GO4 login използвайте Сайтове → редакция на съответния Shopify сайт → Shopify crawler access. Проверете Shopify signature domain и поставете Signature, Signature-Input и Signature-Agent точно както Shopify ги показва. Домейнът трябва да съвпада с домейна на публичния магазин, за който е създаден подписът.

След запис използвайте Test crawler access. Нормален успешен отговор потвърждава, че GO4 може да използва настройката за този магазин. Ако заменяте изтекъл подпис, поставете новите стойности; иначе оставете защитените полета празни, за да запазите вече записаните стойности.

GO4 показва дали crawler access е активен, изтича скоро или е изтекъл. При изтичане създайте нов подпис в Shopify, заменете го в GO4 и пуснете теста отново.

5.5. Примерна конфигурация

Име на сайта: My Store

Основен URL: https://example.com

Платформа: Shopify, ако сайтът е Shopify; обикновен сайт, ако не е Shopify

Интервал по подразбиране: 5 минути

Активен: Включено

Включи JS агент: Включено, ако ще използвате JS Agent. При свързан Shopify магазин включете и Storefront monitoring от Shopify App embeds; при директно добавен или обикновен сайт използвайте site-specific agent.js snippet-а от GO4.

Shopify crawler подпис: Включен само за Shopify сайт и само когато имате валиден подпис за домейна

5.6. Как да проверите дали сайтът е добавен правилно

След запазване:

1. Върнете се в Сайтове.
2. Проверете дали сайтът е в списъка.
3. Уверете се, че е Активен.
4. Добавете поне една HTTP / Page проверка за началната страница.
5. Пуснете проверката ръчно от бутона за Изпълнение.
6. Отворете История и проверете резултата.
7. Ако сайтът е Shopify и използва crawler access, отворете Administration → Crawler access при Shopify достъп или Сайтове → редакция на съответния Shopify сайт → Shopify crawler access при Direct GO4 login, проверете статуса и използвайте Test crawler access.

5.7. От сайта към причината за предупреждение

В списъка Сайтове колоните Здраве и Качество служат и като бърз вход към причината за проблема. Когато индикаторът показва Предупреждение или Неуспех, кликът отваря История с филтър за конкретния сайт, подходящото влияние и само проблемните изпълнения.

6. Добавяне на проверки

Проверки се управляват от секцията Проверки.

6.1. Стъпки за добавяне

1. Отворете Проверки.
2. Натиснете Добави проверка.
3. Изберете Сайт.
4. Въведете Име на проверката.
5. Изберете Тип.
6. Изберете Влияние върху статуса.
7. Попълнете нужните полета според типа проверка.
8. Оставете проверката Активен, ако искате да се изпълнява автоматично.
9. Запазете.
10. Пуснете я ръчно с Пусни сега, за да проверите настройките.

6.2. Общи полета за проверки

Клониране на проверка

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

Името на копието получава добавка - copy, а при нужда - copy 2, - copy 3 и т.н. След клониране системата отваря новата проверка за редакция.

Advanced settings JSON и „Приложи JSON към полетата“

Панелът Advanced settings JSON е помощен инструмент за пренасяне или по-бързо попълване на настройки. Той е полезен, когато имате подготвена конфигурация и искате GO4 да я разпредели в нормалните полета на формата.

6.3. Планови лимити и индикатори

При Shopify плановете GO4 показва информация за ограниченията директно до настройките, когато дадена стойност е близо до или извън позволения обхват.

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

Промяна към по-нисък Shopify план

Ако за магазина има планирана промяна към по-нисък план, в Plan and billing може да се покаже Преглед на ефекта от downgrade. Текущият план остава активен до датата, на която промяната влиза в сила.

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

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

6.4. Визуален избор на CSS selector в Shopify

При активен Shopify магазин, свързан с GO4 Shopify приложението, до поддържаните CSS selector полета може да виждате бутон Избери елемент. Той отваря storefront-а в отделен таб с toolbar GO4 Element Selector, за да посочите елемент визуално вместо да пишете selector на ръка.

Как се използва „Избери елемент“

1. Изберете правило, което използва CSS selector, и задайте правилния URL или обхват на проверката.
2. Натиснете Избери елемент. GO4 отваря storefront-а в отделен таб.
3. Използвайте Navigate, ако първо трябва да стигнете до друга страница. Когато сте готови, включете Select element и кликнете върху желания елемент.
4. Прегледайте генерирания selector, броя съвпадения и оценката Stable / Contextual / Fragile. За единичен бутон или контрол обикновено е най-добре selector-ът да има 1 match. При списък, галерия или правило с минимален брой елементи няколко съвпадения може да са напълно очаквани.
5. Натиснете Use selector. GO4 връща selector-а точно в полето, от което сте започнали.
6. Прегледайте настройката и натиснете Запази проверката. Визуалният избор сам по себе си не записва проверката.

7. Типове проверки

7.1. HTTP / Page проверка

За какво служи

HTTP / Page проверка проверява дали дадена страница се зарежда нормално.

Може да следи:

• HTTP статус;
• време за отговор;
• дали HTML-ът съдържа очакван текст;
• дали HTML-ът не съдържа нежелан текст;
• допълнителна проверка на съдържание чрез текст или CSS selector;
• проверка в суров сървърен HTML или в браузърен DOM след JavaScript;
• минимален размер на тялото на отговора;
• стандартни шаблони за грешки като 502/504 и, при Shopify, Liquid error.

Кога е полезен

Използвайте го за:

• началната страница;
• продуктова страница;
• страница на колекция/категория;
• страница за контакт;
• важна целева страница;
• basic API / health endpoint, когато връща текстов или JSON отговор.

Основни настройки

Как работи Трябва да съдържа

Трябва да съдържа означава: “този текст трябва да бъде намерен в HTML-а”.

Пример:

• Трябва да съдържа: Добави в количката

Ако текстът присъства — OK.

Ако текстът липсва — Предупреждение/Неуспех според логиката и влиянието.

Как работи Не трябва да съдържа

Не трябва да съдържа означава: “този текст не трябва да бъде намерен в HTML-а”.

Пример:

• Не трябва да съдържа: Liquid error

Ако текстът не присъства — OK.

Ако текстът присъства — проблем.

При Shopify сайтове Liquid error е полезен по подразбиране, защото често означава тема/шаблон проблем. При обикновени сайтове не се добавя автоматично.

Допълнителна проверка на съдържание

Допълнителна проверка на съдържание е по-точно правило за страница, което се изпълнява след нормалната HTTP проверка. Полезно е, когато простото поле „Трябва да съдържа“ не е достатъчно или когато искате да проверите CSS selector, уиджет, галерия, блок с отзиви или елемент, който се появява след JavaScript.

Сървърен HTML срещу браузърен DOM

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

Примери за CSS selector проверки

Примерна настройка

Име на проверката: Достъпност на началната страница

Тип: HTTP / Page проверка

URL или път: /

Метод: GET

Очакван HTTP статус: 200

Интервал: 5 минути или минималният интервал, показан за текущия план.

Време за изчакване: 15 секунди

Не трябва да съдържа: Liquid error за Shopify сайт

Влияние върху статуса: Оперативно / критично

Пример за уиджет проверка: за Instagram/блок с отзиви използвайте Допълнителна проверка на съдържание → Браузърен DOM / след JavaScript → CSS selector трябва да съществува → selector към конкретните елементи на widget-а → Минимален брой според очакваното съдържание, например 2, ако трябва да има поне два елемента → Влияние: Предупреждение за качество.

Какво означава успешен резултат

• Страницата отговаря.
• HTTP статусът е очакваният.
• Няма забранен текст.
• Ако има Трябва да съдържа, текстът е намерен.
• Ако е включена Допълнителна проверка на съдържание, текстът или CSS selector правилото минава успешно.
• Времето за отговор е под прага.

Какво означава проблемен резултат

• сайтът не отговаря;
• HTTP статусът не е очакваният;
• страницата е твърде бавна;
• липсва очакван текст;
• намерен е забранен текст;
• тялото на отговора е твърде малко;
• допълнителната проверка на съдържание не намира очаквания текст/selector или намира забранен текст/selector;
• засечен е шаблон за грешка.

Какво да направите при проблем

1. Отворете страницата ръчно в браузър.
2. Проверете дали URL-ът в проверката е правилен.
3. Проверете дали Очакван HTTP статус е правилен.
4. Ако липсва текст в полето „Трябва да съдържа“, уверете се, че текстът не е сменен в сайта.
5. Ако има Не трябва да съдържа проблем, проверете дали в HTML-а наистина има грешка.
6. Ако използвате Браузърен DOM, проверете дали таймаутът на браузъра и изчакването след зареждане са достатъчни за уиджета.
7. Ако е фалшив сигнал, коригирайте текста, selector-а, източника или настройките.

7.2. SEO / Canonical / Robots проверка

За какво служи

Тази проверка анализира SEO сигналите на един конкретен URL. Тя е подходяща за началната страница, важни целеви страници, продуктови страници, статии или всяка страница, при която искате бърза точкова проверка без пълен sitemap одит.

Проверява:

• title — липсващ, твърде кратък или твърде дълъг;
• meta description — липсваща, твърде кратка или твърде дълга;
• canonical — липсващ, грешен или различен от очаквания URL;
• robots/noindex — неочакван noindex;
• H1 — липсващ или повече от очаквания брой;
• Open Graph полета, когато са включени в настройките.

Кога е полезен

• за най-важните страници, които искате да следите отделно;
• когато не ви трябва пълен sitemap списък;
• за бърз тест след SEO промяна, промяна на theme или редакция на съдържание;
• за URL-и, които трябва винаги да имат конкретен canonical или да не са noindex.

Основни настройки

Canonical режим

Примерна настройка

Име на проверката: SEO на началната страница

Тип: SEO / Canonical / Robots проверка

URL или път: /

Влияние върху статуса: Предупреждение за качество

Изисквай title/meta/canonical: включено

Description min/max: 50 / 170

Заглавие min/max: 20 / 70

H1 min/max: 1 / 1

Отваряй инцидент при активни проблеми с качеството: включете само ако искате тази конкретна SEO проверка да създава инциденти.

Какво означава успешен резултат

Страницата връща очакван HTTP отговор и всички включени SEO сигнали са в зададените граници.

Какво означава проблемен резултат

GO4 е открил липсващ или невалиден SEO сигнал: кратък title, липсваща meta description, canonical несъответствие, noindex или H1 проблем.

В История проблемите се показват като карти с проблеми. Ако проблемът е очакван, можете да го заглушите за тази проверка. Ако е заглушен, ще го видите в кутийката „Заглушени грешки“ и оттам можете да премахнете заглушаването.

Какво да направите при проблем

1. Отворете последното изпълнение в История и вижте конкретните активни проблеми.
2. Проверете дали проблемът е реален в HTML-а на страницата.
3. Ако е реален — поправете title/meta/canonical/robots/H1 в сайта.
4. Ако е очакван за тази страница — заглушете само конкретния проблем, не цялата проверка.
5. Ако искате този тип проблем да отваря инцидент, включете „Отваряй инцидент при активни проблеми с качеството“ и задайте праг за инцидент.

7.3. Shopify Cart API health

За какво служи

Shopify Cart API health е лека сървърна проверка за Shopify кошницата. Тя проверява дали избран вариант може да бъде добавен във временна тестова количка и дали Shopify връща очаквания отговор.

Проверката не тества дизайна на темата, cart drawer-а или бутона Add to cart. За това използвайте Browser Lab Action Journey, защото той отваря магазина като потребител и може да натиска елементи в интерфейса.

Кога е полезен

Използвайте я за Shopify магазини, когато искате бърз сигнал, че основната сървърна cart функционалност работи:

• избраният вариант е валиден и може да бъде използван за тест;
• сървърната функционалност на Shopify количката приема заявката;
• резултатът съдържа очаквания продукт и количество;
• има отделен сървърен сигнал, различен от визуалния cart drawer тест.

Основни настройки

Когато Shopify магазинът е свързан чрез Shopify приложението, GO4 използва връзката с приложението за по-надежден сървърен тест на количката. При директно добавени Shopify сайтове crawler подписът може да помогне за по-стабилни заявки към публичната част на магазина.

Примерна настройка

Име на проверката: Проверка на Cart API

Тип: Shopify Cart API health

Variant ID: 49123456789012

Количество: 1

Влияние върху статуса: Оперативно / критично

Интервал: 15–30 минути за сървърен cart сигнал. За пълен cart drawer или checkout път използвайте отделна Browser Lab Action Journey проверка.

Какво означава успешен резултат

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

Какво означава проблемен резултат

• Variant ID липсва, е грешен или продуктът не е подходящ за тест;
• Shopify отказва добавянето на продукта в тестовата количка;
• отговорът не съдържа очаквания продукт или количество;
• магазинът връща временна грешка, временно ограничение на заявките или друг проблем със сървърната функционалност на количката.

Какво да направите при проблем

1. Проверете дали Variant ID е правилен и продуктът е активен.
2. Уверете се, че продуктът може да бъде добавен в количка в самия магазин.
3. Ако сайтът не е свързан чрез Shopify приложението, проверете дали crawler подписът е актуален.
4. Ако визуалната кошница работи, но тази проверка предупреждава, прегледайте резултата в История и пуснете проверката ръчно още веднъж.
5. Ако искате да тествате темата, cart drawer-а или checkout пътя, създайте Browser Lab Action Journey.

7.4. Shopify продуктови правила

За какво служи

Shopify продуктовите правила проверяват дали важни продукти отговарят на зададените изисквания за тагове, наличност, изображения, варианти и цени.

Проверката може да работи по два начина:

И двата режима се виждат в Одит на Shopify продукти, където има общ преглед, списък с продукти, проблеми и прогрес.

Какво може да проверява

• дали продуктът може да бъде прочетен;
• дали има задължителни тагове;
• дали няма забранени тагове;
• дали има наличен вариант, ако това е изискване;
• дали продуктовите изображения покриват минимална резолюция;
• дали вариантите имат дублирани комбинации;
• дали липсват очаквани комбинации от варианти;
• дали цените и compare-at цените са консистентни според зададените правила;
• дали едно и също SKU не се показва с неочаквано различна цена в различни продукти.

Основни настройки

Автоматично откриване и проверка на групи

При автоматично откриване GO4 поддържа списък с продукти за проверката. При конкретни продукти списъкът идва от въведените от вас URL-и или handles. И в двата случая продуктите се проверяват на групи, за да не се създава излишно натоварване.

Проверки на вариантите и ценовите правила

Тези правила са полезни за продукти с опции като Size, Model, Type, Color, Bundle или Material.

Използвайте Apply price rule to products, когато правилото трябва да важи само за определена продуктова структура. Продукти извън зададения обхват получават информационна конфигурационна бележка, а не активен проблем.

Конфигурационни бележки при продуктови правила

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

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

Успешен и проблемен резултат

Успешен резултат означава, че проверените продукти отговарят на включените правила или няма активни незаглушени проблеми.

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

След корекция в Shopify пуснете проверката ръчно или изчакайте следващото планирано изпълнение. Решените проблеми се затварят при следваща успешна проверка.

7.5. Shopify правила за колекция

За какво служи

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

Проверката може да работи по два начина:

Кога е полезен

Използвайте го за колекции като:

• Нови продукти;
• Най-продавани;
• Разпродажба;
• основни категории;
• кампанийни и сезонни колекции.

Основни настройки

Примерна настройка

Име на проверката: Одит на колекции

Тип: Shopify правила за колекция

Избор на колекции: Автоматично откриване за цял магазин или Конкретни колекции за ограничен списък

Минимален брой продукти: 1

Fail при празна колекция: включено за важни публични колекции

Влияние върху статуса: Предупреждение за качество или оперативно, ако е критична кампания

Какво означава успешен резултат

• проверените колекции са достъпни;
• всяка проверена колекция има поне зададения минимален брой продукти;
• няма активни незаглушени проблеми за проверената група.

Какво означава проблемен резултат

• колекцията не може да бъде прочетена;
• колекцията има по-малко продукти от очакваното;
• колекцията е празна;
• въведеният handle или URL не сочи към валидна колекция.

Автоматично откриване

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

Настройките за автоматично откриване са в отделен сгънат блок. Те са полезни, когато искате да ограничите източниците, да добавите допълнителни source URL-и, да управлявате локализирани URL-и или да пропуснете определени handles.

Режими на Shopify правила за колекция

Проверка на групи

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

7.6. Client-side JS Agent проверка

За какво служи

Client-side JS Agent проверката използва браузърни събития, изпратени от agent.js, и ги превръща в нормален резултат от проверка. Тя не обхожда сайта сама и не създава изпълнение за всяко браузърно събитие.

agent.js в сайта
↓
реален браузър зарежда страница
↓
agent.js изпраща браузърно събитие
↓
Client-side JS Agent проверката се изпълнява по интервал или ръчно
↓
проверката избира последното релевантно събитие за тази проверка
↓
резултатът се вижда в История / Инциденти / Табло

Едно браузърно събитие може да съвпадне с повече от една JS Agent проверка.

Кога е полезен

• когато искате да знаете дали агентът е активен на сайта и изпраща събития;
• когато искате последното релевантно събитие да се оценява за title, meta description, canonical, noindex, JS грешки, скорост или cart.js;
• когато искате да следите конкретни URL-и, кампания/UTM трафик или DOM правила без да създавате crawler;
• когато искате браузърните сигнали да се виждат отделно от сървърните SEO проверки.

Режим само сигнал за активност

За базова проверка дали агентът изпраща събития, попълнете само Максимум минути без браузърно събитие. Оставете останалите правила за качество/браузър празни или изключени.

За сайтове с нисък трафик използвайте по-дълъг прозорец, например 6–12 часа, и по-висок процент на извадката на ниво сайт.

Основни настройки

Shopify планове и JS Agent възможности

При свързан Shopify магазин част от JS Agent настройките зависят от текущия план. GO4 показва допустимото ниво директно до съответните полета.

Ресурсна диагностика в Client-side JS Agent проверка

Client-side JS Agent проверката може по избор да показва кратка диагностика на ресурсите към важните браузърни събития. Това помага да видите кои скриптове, CSS файлове, изображения, видео или заявки участват в бавно зареждане.

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

Canonical режим за JS Agent проверката

Примерна настройка

Само сигнал за активност: Максимум минути без браузърно събитие = 60–720 според трафика; останалите правила изключени.

Браузърно качество за Shopify: включете title/meta/canonical правила, Максимум JS грешки в последното събитие = 0, Максимално време за зареждане в ms = 5000–7000 и Изисквай Shopify cart.js OK.

Фокусирана кампания проверка: задайте правила за съвпадение по URL/UTM и използвайте Записвай Предупреждение / Неуспех + последното OK събитие, за да пазите всички проблеми без да трупате всички нормални OK събития.

Важна разлика със SEO проверката

SEO / Canonical / Robots е сървърна проверка на един URL. Client-side JS Agent е браузърна проверка на последното релевантно събитие от реален браузър. Двете се допълват, но не са взаимозаменяеми.

Важно ограничение

Client-side JS Agent проверката зависи от реални браузърни събития и процент на извадката. Ако няма трафик или процентът на извадката е твърде нисък, липсата на събития не означава непременно, че сайтът е недостъпен.

Проверката не изпълнява произволен JavaScript, не променя DOM-а, не добавя продукти в количката и не променя потребителската сесия.

7.7. Browser Lab

За какво служи

Browser Lab е контролирана браузърна проверка. GO4 отваря избрания URL или path в контролирана браузърна среда и показва основните сигнали за зареждане, без да чака реален посетител. Освен единично зареждане, Browser Lab може да изпълнява и Action Journey - подредени браузърни стъпки за важен потребителски път.

Browser Lab е отделен слой от JS Agent, Sitemap браузърната диагностика и Shopify/Sitemap одитите. Той е подходящ, когато искате GO4 сам да отвори конкретна страница и да измери как се държи тя в контролирана браузърна среда.

Кога е полезен

• за важна начална, продуктова, страница на колекция или кампания;
• за отделно наблюдение на desktop и mobile зареждане, когато мобилната версия има различно меню, банер, app embed, tracking или layout поведение;
• за проверка на време за браузърно зареждане, DOMContentLoaded, HTTP статус и крайния URL;
• за наблюдение на JavaScript грешки и неуспешни ресурси без да чакате реален посетител;
• за контролирано сравнение между сървърни проверки, Browser Lab и JS Agent сигнали;
• за DOM правило само за четене след JavaScript, например дали бутон, уиджет или текст присъства.
• за проверка на lazy уиджети или секции, които се зареждат чак след скрол до тях;
• за проверка на път като collection/product → variant → add to cart → cart drawer;
• за по-рядка проверка дали checkout landing страницата се отваря безопасно;

Основни настройки

Какво измерва Browser Lab

• Браузърно зареждане — основната lab метрика за контролираното зареждане на страницата;
• DOMContentLoaded — кога DOM документът е готов за четене;
• HTTP статус и краен URL — контекст на основната браузърна навигация;
• Браузърен профил и viewport — дали изпълнението е Desktop или Mobile и в какъв размер е отворена страницата;
• Lab-style сигнали за производителност — TTFB, FCP, ориентировъчен LCP, ориентировъчен CLS, дълги задачи, брой заявки и прехвърлени байтове, когато браузърът ги подаде;
• Таймлайн на зареждането — групира ресурси преди готовност на DOM, между готовност на DOM и пълно зареждане и след пълно зареждане;
• JS сигнали — грешки от конзолата/страницата, според избраното влияние;
• Ресурсни сигнали — неуспешни, най-бавни и, при подходящо ниво на детайлност, най-тежки ресурси;
• Блокирани от режима ресурси — ресурси, които избраният режим на браузърните ресурси умишлено не зарежда;
• DOM проверка — ако е включено едно правило само за четене след JavaScript;
• Визуално доказателство — ако е включено, Browser Lab показва снимка към отчета.

Детайлен Browser Lab отчет

Детайлният отчет на Browser Lab е разделен на табове, за да не се смесват бързото обобщение, производителността, ресурсите, JS/DOM сигналите и техническите данни.

Browser Lab обобщение за производителност

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

При сравнение GO4 използва медианните стойности за всяка група и показва диапазона на измерванията, абсолютната и процентната промяна за сигнали като Браузърно зареждане, TTFB, FCP, LCP и DOM след TTFB, дълги задачи (Long Tasks), брой дълги задачи, заявки, прехвърлени байтове, JS грешки и неуспешни ресурси. Това помага да се различи устойчиво влошаване от единично отклонение.

Когато TTFB е висок, но FCP, LCP, DOMContentLoaded и пълното зареждане след TTFB остават стабилни, това е сигнал, че забавянето вероятно е преди HTML-ът да достигне браузъра, а не непременно в темата или клиентската част на сайта.

Персонализирано сравнение A → B

Използвайте Персонализирано сравнение, когато искате да сравните конкретни исторически изпълнения или два периода, които не са непосредствено един след друг. Маркирайте изпълненията в Browser Lab таблицата и ги добавете към A или B, или използвайте период по дата/час. Можете да добавяте избрани изпълнения към една и съща група и от различни страници на историята, а групите не е задължително да съдържат еднакъв брой изпълнения. Бързите избори Днес, Вчера, Последните 24ч и Последните 7 дни помагат да зададете период без да въвеждате датите и часовете ръчно.

Какво се е променило в ресурсите?

При A/B сравнение стойностите за ресурсите се четат като Базова група A → Сравнителна група B. Когато и двете групи имат запазени данни за конкретни ресурси, блокът Промени в конкретни ресурси може да покаже кои отделни ресурси са нови, изчезнали, по-бавни, по-тежки, по-активни или подобрени. Под него общото сравнение на ресурсите показва по-широките промени на ниво групи, а Състав на страницата помага да се видят промени в собствените и външните групи ресурси, както и в скриптове, fetch/XHR заявки и изображения преди пълното зареждане.

Референтно изпълнение

Когато имате добро историческо Browser Lab изпълнение, можете да използвате Запази като референтно. То остава постоянна диагностична отправна точка за Сравни последните с референтното и е отделно от временните Базова група A и Сравнителна група B. Можете по всяко време да го смените или да използвате Премахни референтното.

Референтното изпълнение се запазва между сесиите. Докато е зададено като референтно, GO4 не го премахва при автоматичното почистване на старата история. Ако изрично изтриете историята на тази Browser Lab проверка, референтното изпълнение също вече няма да бъде налично.

Визуално доказателство със снимка

Визуално доказателство със снимка е опционална настройка на Browser Lab проверката. По подразбиране е изключена, защото не всяка проверка има нужда от визуална снимка.

Когато има снимка, тя се вижда в таба Снимка и може да се отвори за по-детайлен преглед. Снимката отразява избрания браузърен профил: Desktop проверка дава desktop изглед, а Mobile проверка дава mobile изглед.

Допълнителна Browser Lab DOM проверка

Browser Lab може да изпълни едно DOM правило само за четене след зареждане на JavaScript. Поддържаните правила са: CSS selector трябва да съществува, CSS selector не трябва да съществува, текст трябва да присъства и текст не трябва да присъства.

По желание преди DOM проверката Browser Lab може да извърши просто действие: да не прави нищо, да скролне до CSS selector или да скролне до долу. Това е полезно за lazy секции, които се зареждат чак когато потребителят стигне до тях.

Пример: Instagram UGC след скрол

Ако целевият selector за скрол не бъде намерен, резултатът показва ясно, че Browser Lab не е успял да стигне до целевата секция. Ако целта е намерен, но DOM selector-ът не мине, това означава, че секцията е достигната, но очакваното съдържание не се е появило навреме или не отговаря на selector-а.

Action Journey - проверка на потребителски път

Action Journey позволява на Browser Lab да изпълни няколко последователни стъпки в един контролиран тест. Използвайте го, когато трябва да проверите реален storefront път, а не само зареждането на една страница.

Практични сценарии: избор на вариант → Add to cart → потвърждение на количката; scroll до lazy widget → проверка на DOM; отваряне на продукт от колекция → проверка на очакван елемент.

Броят стъпки е plan-aware. Ако видите Над лимита, намалете стъпките до показания максимум или разделете сценария на две по-кратки Browser Lab проверки.

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

Visual Builder за Action Journey

Visual Builder е наличен само за Browser Lab Action Journey. В секцията Визуални стъпки натиснете Изгради визуално. GO4 отваря storefront-а на URL-а, зададен в Browser Lab проверката, и зарежда текущия journey draft, ако вече има стъпки.

В актуалния builder интерфейсът е разделен на три компактни части: Start & current page, работна зона за Selected element / Add step и Journey steps.

Видове Action Journey стъпки

Опции на отделна стъпка

Практични Action Journey модели

Как се чете Action Journey резултат

Когато Action Journey е включен, Browser Lab отчетът може да покаже отделен Journey таб. В него се виждат общият статус, колко стъпки са минали, времето на journey-то, крайният URL и таблица със стъпките.

Ако journey-то се провали, започнете от първата неуспешна стъпка. Обикновено причината е липсващ или променен selector, твърде кратко време за изчакване, изскачащ прозорец/overlay, различна продуктова структура или реално счупен потребителски път.

Тестове преди/след промяна

Тестове преди/след промяна е диагностичен работен процес в Browser Lab. Използвайте го, когато планирате ръчно да изключите app embed, плъгин, таг, tracking скрипт, елемент от темата или друг ресурс и искате да сравните измерванията преди и след промяната.

Преди/след тестът използва браузърния профил на конкретната Browser Lab проверка. Ако проверката е Mobile, BEFORE и AFTER сериите са Mobile; ако проверката е Desktop, сериите са Desktop. За сравнение между desktop и mobile създайте две отделни Browser Lab проверки.

За Shopify е най-безопасно да тествате върху чернова тема (draft theme) с публичен preview линк, когато промяната може да засегне публичния сайт. Ако използвате URL с preview параметър, първо проверете в инкогнито прозорец дали GO4 ще вижда същата версия на темата.

Къде се виждат резултатите

• Проверки → Browser Lab — общ изглед с филтри, последен резултат, сигнали, последно изпълнение и действия.
• Детайли за Browser Lab проверка — текущи проблеми, филтрирана история, Browser Lab обобщение за производителност, персонализирано A/B сравнение, референтно изпълнение, управление на историята и бутон към преди/след тестовете за тази проверка.
• Тестове преди/след промяна — отделен работен процес с история на преди/след тестовете, странициране и отделен резултат за всеки тест.
• Детайли за Browser Lab изпълнение — подробен отчет с раздели Преглед, Снимка, Производителност, Таймлайн, Ресурси, JS / DOM и Технически данни според събраните доказателства.
• Табло — Browser Lab е отделен източник в картите за измервания и в графиката за здравето. В графиката може да разглеждате Browser Lab общо или отделно като Desktop и Mobile източник, за да не смесвате двата типа измервания.
• История — показва компактно изпълнение и връзка към Browser Lab отчет, без да раздува реда с тежки списъци с ресурси и JS сигнали.

Примерна настройка

Име: Homepage — Browser Lab — Desktop

Тип: Browser Lab

URL или път: /

Браузърен профил: Desktop

Интервал: използвайте минималния интервал за браузърна проверка, показан от текущия план; за наблюдение може да изберете и по-рядко изпълнение.

Влияние върху статуса: Предупреждение за качество или Оперативно / критично, ако страницата е критична за бизнеса

Праг за предупреждение: 4000–6000 ms

Праг за неуспех: 8000–12000 ms

JS грешки и неуспешни ресурси: Само информация за старт; затегнете до Предупреждение или Неуспех само за страници, при които тези сигнали са важни

Ниво на детайлност: Стандартно

История: Проблемни + последен OK за компактно ежедневно следене на статус; Пази всички изпълнения, когато искате исторически сравнения на производителността и анализ на регресии.

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

Визуално доказателство със снимка: изключено по подразбиране. За важни визуални проверки използвайте Само при Предупреждение/Неуспех и Пълен браузър, ако искате снимката да прилича на реално зареждане с изображения.

Пример: journey до количката

• Тип: Browser Lab
• Browser profile: Desktop или Mobile според важния поток.
• Action Journey: включено.
• Път: от колекция или продукт до Add to cart и видима количка.
• Влияние: Оперативно / критично, ако това е важен checkout funnel сигнал.
• Интервал: по-чест от проверка до checkout страницата, защото не достига checkout.

Пример: Journey до checkout страницата

• Action Journey: включено.
• Проверка от количка до checkout страница: включено (само в Scale).
• Път: продукт или колекция → Add to cart → checkout landing page.
• Проверка: URL съдържа checkout и страницата остава отворена след кратко изчакване.
• Интервал: по-рядък от Add to cart проверката, защото достига checkout страницата.

7.8. External Radar

За какво служи

External Radar помага да следите външните зависимости, които се зареждат по страниците: уиджети от приложения, приложения за ревюта, размери и търсене, вградени елементи, tracking/pixel скриптове, CDN ресурси, медийни и видео ресурси, шрифтове, аналитика и други външни домейни.

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

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

Настройки и избор на страници

External Radar може да работи с Конкретни страници или с Автоматично откриване.

Добра практика: External Radar не е заместител на пълен crawl. Подбирайте представителни шаблони: homepage, продукт, collection, cart/search, blog/landing page и страници с важни app widgets или embeds.

Какво показва

URL покритие

Покритие показва колко страници от текущия избран обхват вече имат записано Radar състояние. Например 32 / 50 означава, че 32 от 50 страници вече са проверени, а останалите ще бъдат обхванати при следващи изпълнения.

Докато покритието не е пълно, обобщенията са на база вече проверените URL-и. Колкото повече представителни страници минат през Radar, толкова по-пълна става картината за външните доставчици и ресурсните сигнали.

Проблеми срещу диагностични сигнали

Проблеми показва URL-и с активен Radar проблем според настройките, важността на доставчика и зададените прагове. URL покритие може да показва и диагностични сигнали като „Бавни“ или „Неуспешни“ ресурси, дори когато тези сигнали са само за наблюдение или са под прага за активен проблем.

Текущо състояние срещу история

Общият изглед и списъците за покритие показват последното завършено състояние. Историята на Radar сканиранията показва отделните изпълнения във времето. Ако един URL е бил бавен в отделно сканиране, но след това е проверен отново и е OK, историята запазва контекста, а текущото обобщение се изчислява по последното състояние.

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

Доставчици и действия

В раздела Доставчици колоната Страници показва на колко вече сканирани URL адреса е засечен съответният доставчик. Това не е общият брой страници в сайта, а броят проверени страници, на които Radar е видял ресурс от този домейн или доставчик.

Какво да направите при проблем

1. Отворете Проблеми и вижте URL-а, доставчика и причината.
2. Проверете страницата ръчно в браузър.
3. Ако искате бърза повторна проверка само за този адрес, използвайте Провери URL.
4. Ако доставчикът е важен, проверете съответното приложение, вграден елемент, настройка на скрипт, CDN или външен доставчик.
5. Ако виждате само бавен диагностичен сигнал, проверете дали се повтаря на много URL-и или е единичен пик.
6. Ако проблемът е очакван и не трябва да влияе на резултата от Radar, използвайте Игнорирай доставчика.
7. Ако сте игнорирали доставчик погрешка, върнете го чрез Отмени игнорирането.

Практични настройки

7.9. Практични настройки по тип проверка

8. Активиране, паузиране и ръчен тест

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

• Вкл. / Активна — участва в автоматичното наблюдение.
• Изкл. / Неактивна — не се изпълнява автоматично и не използва капацитета за автоматично изпълнение.

Неактивна проверка може да се запази, докато я донастройвате. Ако запазените настройки за изпълнение са допустими за текущия Shopify план и ролята ви позволява действие, можете да я пуснете ръчно за тест, без да я активирате.

Кога е разумно да спрете проверка временно

• по време на редизайн или планирана промяна;
• когато URL се сменя;
• когато настройвате ново правило и искате първо ръчни тестове;
• когато кампания или целева страница вече не е активна.

Риск при спряна проверка

Докато проверката е неактивна, GO4 няма да я изпълнява автоматично и няма да ви предупреждава за нов проблем чрез този check. Включете я отново, когато мониторингът трябва да продължи.

9. Примерни готови конфигурации

9.1. Онлайн магазин

Препоръчителни проверки:

1. Достъпност на началната страница
2. SEO на началната страница
3. Достъпност на продуктова страница
4. Симулация на добавяне в кошница
5. Основната колекция не е празна
6. Одит на Shopify продукти
7. JS Agent сигнал за активност / браузърно качество
8. Reviews / Instagram / gallery уиджет
9. Browser Lab Journey до checkout страницата
10. Browser Lab journey до количката
11. Browser Lab за важна страница

Одит на Shopify продукти — препоръчителен старт

• Тип: Shopify продуктови правила
• Източник на продукти: Автоматично откриване
• Първи правила: задължителни тагове, забранени тагове, наличност и изображения според нуждите
• Размер на групата: започнете със стойност в рамките на показаното ограничение за плана и увеличавайте само ако е необходимо.
• Проверки на вариантите: включете ги след като знаете реалните имена на Shopify опциите
• Ценови правила: използвайте отделни проверки за различни продуктови структури, например продукти само с размер и продукти с модел + размер
• Влияние: Предупреждение за качество

9.2. Корпоративен сайт

Препоръчителни проверки:

1. Достъпност на началната страница

• HTTP / Page проверка
• URL: /
• Очакван статус: 200

1. Достъпност на страницата за контакт

• HTTP / Page проверка
• URL: /contact
• Трябва да съдържа: Contact или друг стабилен текст

1. SEO на началната страница

• SEO / Canonical / Robots проверка
• Предупреждение за качество

1. Проверка на thank-you страница, ако има такава страница

• HTTP / Page проверка
• URL: /thank-you
• Трябва да съдържа: Thank you

9.3. Блог / новинарски сайт

Препоръчителни проверки:

1. Достъпност на началната страница

• HTTP / Page проверка
• URL: /

1. Достъпност на страница на категория

• HTTP / Page проверка
• URL: /category/news
• Трябва да съдържа: заглавие на категорията

1. Достъпност на статия

• HTTP / Page проверка
• URL: /article/example
• Трябва да съдържа: заглавие на статията

1. SEO на статия

• SEO / Canonical / Robots проверка
• URL: /article/example

9.4. Целева страница

Препоръчителни проверки:

1. Целева страница достъпност

• HTTP / Page проверка
• URL: /campaign
• Очакван статус: 200

1. Проверка на CTA текст

• HTTP / Page проверка
• URL: /campaign
• Трябва да съдържа: Get started или реалния CTA текст

1. Проверка на thank-you страница

• HTTP / Page проверка
• URL: /thank-you
• Трябва да съдържа: Thank you

1. SEO на целева страница

• SEO / Canonical / Robots проверка
• Предупреждение за качество

10. Как да следите системата ежедневно

Какво да гледате първо

1. Табло — започнете от KPI картите: отворени инциденти, активни предупреждения и средно измерено време.
2. Картите за измервания — вижте дали сигналът идва от сървърни проверки, Browser Lab, реални посетители / JS Agent или одит изпълнения. Не третирайте смесения изглед като една универсална скорост.
3. Графиката в Табло — изберете период и източник от изскачащите контроли и проверете дали има спад в оперативното здраве, пик в предупрежденията или необичаен тренд в конкретен източник.
4. Здраве на сайтовете — вижте кой сайт има оперативен проблем, предупреждение за качество или необичаен тренд на измереното време.
5. Последни изпълнения — отворете конкретното изпълнение, Browser Lab отчет или JS Agent събитие, когато има нужда от подробности.

Как да разпознаете реален проблем

Реален проблем е по-вероятен, ако:

• оперативната проверка дава неуспешен резултат;
• проверката дава неуспешен резултат последователно;
• инцидент е отворен;
• началната страница или кошница проверки са неуспех;
• няколко различни проверки към същия сайт дават неуспех едновременно;
• JS агент и сървърни проверки показват проблем около едно и също време.

Как да различите временен проблем от сериозен

Временен проблем може да е:

• единичен бавен отговор;
• едно изпълнение с предупреждение, следван от OK;
• външно мрежово време за изчакване.

Сериозен проблем е:

• няколко поредни неуспешни резултата;
• отворен инцидент;
• началната страница/кошница проверка с неуспешен резултат;
• сайтът не се отваря ръчно;
• Cart API проверка не може да добави продукт;
• noindex се появява на важна публична страница.

Какво означава проверка да се възстанови

Ако след проблем проверката започне пак да връща OK, системата може да затвори/маркира инцидента като разрешен според логиката. В История ще остане история кога е имало проблем и кога е минал успешно.

11. История — изпълнения на проверките

История показва какво е установила дадена проверка при конкретно изпълнение. Това е основното място за отговор на въпроса „защо виждам този статус?“.

Как се чете едно изпълнение

1. Проверете статуса: OK, Предупреждение или Неуспех.
2. Прегледайте краткото обобщение и измереното време.
3. Отворете активните проблеми и вижте конкретната причина.
4. Ако има директна връзка към Browser Lab, Sitemap, Product/Collection Audit или JS Agent, използвайте я за по-пълен контекст.

Действия за проблемите в История

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

12. Инциденти

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

Отворен инцидент

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

Затворен инцидент

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

Инциденти за качество

SEO, одит и други проверки за качество могат да останат само като предупреждения или да отварят инцидент, ако това е включено в настройките. Използвайте инциденти за качество само за сигнали, които реално изискват реакция.

13. Заглушени грешки

Заглушени грешки се използват, когато конкретен проблем е известен, очакван или приемлив за избрания обхват.

Пример:

• Сайт: My Store
• Проверка: SEO на началната страница
• Грешка: Липсва H1

Ако заглушите само тази грешка:

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

Разделът Заглушени грешки има филтри по сайт, проверка, тип източник, състояние, обхват и текст. При проблем от одити контекстният линк води към точния Sitemap/Одит на колекции изглед. При обикновени проверки контекстът води към История с подходящо търсене.

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

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

14. JS Agent

JS Agent е браузърен сигнал от реални посетители. Той допълва сървърните проверки и Browser Lab, но не ги замества.

Какво може да събира

• JavaScript грешки;
• сигнали за производителност;
• SEO сигнали в реалния DOM;
• Shopify cart.js сигнал;
• диагностика на ресурси;
• URL/path и избрани page данни според настройките.

Настройки на сайта срещу настройки на проверката

Настройките на сайта определят какви данни JS Agent може да изпраща. Client-side JS Agent проверката определя как GO4 оценява последното релевантно събитие.

Настройка през свързан Shopify магазин

При магазин, свързан чрез GO4 Shopify приложението, JS Agent се настройва на две отделни стъпки:

1. В Проверки → JS Agent използвайте Включи JS агент, ако агентът още е изключен. С Настрой JS Agent можете да прегледате какви браузърни данни са разрешени.
2. В секцията за storefront installation натиснете Open Theme Editor. Shopify отваря Theme Editor директно при App embeds. Включете Storefront monitoring за GO4 и натиснете Save.

Enable JS Agent в GO4 и Storefront monitoring App Embed в Shopify са две различни настройки. Само едната не е достатъчна: GO4 трябва да е готов да приема събития, а Shopify трябва реално да зарежда агента в storefront-а.

След като отворите публичния магазин и GO4 получи събитие през App Embed-а, секцията показва, че има App Embed activity detected. Ако още няма такова събитие, статусът може да остане App Embed not detected yet; това само по себе си не означава проблем със сайта.

За свързан Shopify магазин не е нужно да редактирате theme code или да поставяте ръчно agent.js snippet. JS Agent не е част от началния Start monitoring wizard и се настройва само ако решите да използвате тази проверка.

Настройка за директен или обикновен сайт

За директно добавени сайтове използвайте показания от GO4 site-specific agent.js snippet. Това важи и за Shopify сайт, който е добавен директно в GO4 и не е свързан чрез GO4 Shopify приложението.

След инсталацията отворете сайта в браузър и проверете Проверки → JS Agent за ново събитие.

Правилата, които определят какво да се оценява — heartbeat, вградени браузърни сигнали и персонални DOM проверки — се настройват в самата Client-side JS Agent проверка. За ограниченията според плана вижте 7.6. Основни настройки.

Heartbeat и sampling

Sampling rate определя каква част от зарежданията изпращат събитие. Heartbeat следи дали има достатъчно скорошен браузърен сигнал. При сайт с нисък трафик използвайте по-висок Sampling rate и по-широк heartbeat прозорец.

Какво не прави

JS Agent не финализира поръчки, не управлява сайта и не е заместител на HTTP, SEO, Browser Lab или одит проверките.

Къде се виждат данните

Отворете Проверки → JS Agent, за да видите последните браузърни събития, грешки, производителност и контекст за ресурсите.

Ресурсна диагностика

Диагностиката на ресурси помага да видите дали външен скрипт, изображение, медия, fetch/XHR заявка или друг ресурс често участва в бавно или проблемно зареждане. Използвайте го като насока за проверка, а не като автоматично доказателство за причината.

Сървърни SEO сигнали срещу браузърен DOM

SEO проверката и Sitemap Audit показват какво вижда директната заявка към страницата. JS Agent показва какви сигнали присъстват в DOM при реално браузърно зареждане. Разлика между двете е полезен сигнал за допълнителна проверка.

15. Известия

Операции → Известия се използва, за да получите сигнал при нов инцидент и при възстановен/затворен инцидент.

При свързан Shopify магазин можете да управлявате известията през Shopify достъпа, като отворите Open full dashboard. Не е необходимо да създавате Direct GO4 account само за да използвате известията. Ако магазинът още няма активен план или валиден пробен период, съществуващите канали могат да се преглеждат, но добавянето и промяната на канали остава заключено до активиране на план.

Поддържат се два типа канали:

Основни полета:

• Организация;
• Име на канала;
• Тип — Telegram или Slack;
• Данни за Telegram бота и chat ID, когато типът е Telegram;
• Slack webhook URL, когато типът е Slack;
• Бутони за действие, когато искате известието да води директно към контекста;
• Активен.

Telegram и Slack известията могат да съдържат бутони към контекста на инцидента: Инцидент, История, Browser Lab отчет, Sitemap одит, Одит на колекции или Одит на продукти, когато такъв контекст е наличен.

При Slack канал по желание може да добавите mention при нов/отворен инцидент. Той не се добавя към съобщения за възстановяване.

15.1. Telegram: Bot Token и Chat ID

За Telegram канал GO4 се нуждае от Bot Token и Chat ID на чата или групата, в която искате да получавате известия.

1. Отворете официалния Telegram bot @BotFather: https://t.me/BotFather.
2. Изпратете командата /newbot и следвайте стъпките за име и username на новия bot. Telegram ще ви даде authentication token.
3. Копирайте token-а и го поставете директно в полето Bot token в Операции → Известия. Не го изпращайте в GO4 Assistant, Support, имейл или screenshot.
4. Отворете новия bot в Telegram и му изпратете съобщение, например /start. Ако известията трябва да отиват в група, добавете bot-а в групата и изпратете команда към него там.
5. За да намерите Chat ID, използвайте официалния Telegram Bot API метод getUpdates след изпращане на съобщението и намерете стойността message.chat.id в последния update. Копирайте само Chat ID в полето Chat ID в GO4.
6. Маркирайте канала като Активен и запазете.

Официална помощ от Telegram:

• BotFather и създаване на bot: https://core.telegram.org/bots/features#botfather
• Telegram Bot API — getUpdates: https://core.telegram.org/bots/api#getupdates

15.2. Slack: Incoming Webhook

За Slack канал GO4 използва Slack Incoming Webhook URL. Най-сигурният начин е да създадете или използвате Slack App за вашия workspace и да активирате Incoming Webhooks.

1. Отворете настройките на вашия Slack App или създайте нов Slack App за правилния workspace.
2. В настройките на app-а отворете Incoming Webhooks и включете Activate Incoming Webhooks.
3. Натиснете Add New Webhook to Workspace.
4. Изберете Slack channel-а, в който GO4 трябва да публикува известията, и разрешете достъпа. За private channel трябва да имате достъп до него.
5. Копирайте URL-а от Webhook URLs for Your Workspace. Той трябва да е Slack Incoming Webhook адрес от вида https://hooks.slack.com/services/....
6. Поставете URL-а директно в полето Slack webhook URL в GO4, настройте mention и бутоните за действие по желание, маркирайте канала като Активен и запазете.

Официална помощ от Slack: https://docs.slack.dev/messaging/sending-messages-using-incoming-webhooks/

16. Организации и Потребители

Организации

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

Режим на браузърните ресурси в организацията

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

Потребители

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

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

17. Какво да правите при проблем

17.1. Сайтът не се отваря

1. Отворете История и намерете последните неуспех изпълнения.
2. Проверете HTTP code и съобщение за грешка.
3. Отворете сайта ръчно.
4. Проверете дали проблемът е само от monitor-а или реален за всички.
5. Ако има отворен инцидент, проследете кога е започнал.
6. Изпратете към поддръжка: сайт, име на проверката, време на изпълнение, HTTP code, съобщение за грешка, скрийншот.

17.2. Очакван текст липсва

1. Проверете Трябва да съдържа настройката.
2. Уверете се, че текстът не е променен в сайта.
3. Ако е променен, редактирайте проверката.
4. Ако страницата зарежда друг шаблон, проверете CMS/theme.

17.3. Появява се забранен текст

1. Проверете Не трябва да съдържа.
2. Отворете откъса от отговора.
3. Потърсете текста в HTML/изходния HTML на страницата.
4. Ако е реална грешка, поправете сайта.
5. Ако е фалшив сигнал, прецизирайте текста.

17.4. Shopify Cart API health дава неуспех

1. Проверете вариант ID.
2. Уверете се, че продуктът е наличен.
3. Проверете дали Shopify сървърната cart функционалност работи и дали избраният Variant ID е валиден.
4. Уверете се, че няма app/theme конфликт.
5. Сменете тестовия вариант, ако продуктът е спрян.

17.5. SEO предупреждение

1. Вижте грешката в История.
2. Проверете дали е Липсва H1, canonical несъответствие, noindex или друго.
3. Поправете SEO настройката в сайта.
4. Ако проблемът е умишлен, използвайте Разреши noindex, промяна на H1 min/max или заглушена грешка.

17.6. JS агент няма събития или Client-side JS Agent проверка дава предупреждение

1. Проверете дали JS Agent е включен за сайта в GO4.
2. При свързан Shopify магазин отворете Проверки → JS Agent и проверете storefront installation статуса. Ако още няма App Embed активност, натиснете Open Theme Editor, включете Storefront monitoring в App embeds и натиснете Save.
3. При директно добавен или обикновен сайт проверете дали site-specific agent.js snippet е поставен в сайта.
4. Отворете сайта в браузър и проверете Проверки → JS Agent за ново събитие.
5. Ако Client-side JS Agent проверката още няма първо релевантно събитие за своя URL обхват, тя може да се покаже като Отложено. Това е състояние за настройка/изчакване и не означава, че сайтът е недостъпен.
6. Ако проверката вече е имала релевантна активност, но събитията са спрели или последното събитие е по-старо от Максимум минути без браузърно събитие, предупреждението означава, че трябва да проверите защо браузърният сигнал е прекъснал.
7. При нисък трафик увеличете Sampling rate и/или прозореца за Максимум минути без браузърно събитие.
8. Ако използвате Include/Exclude URL patterns, отворете страница, която реално попада в обхвата на проверката.
9. Ако има включени правила за качество, отворете История и проверете конкретния проблем: title/meta/canonical, noindex, JS грешка, бавно зареждане, cart.js или персонално DOM правило.
10. Ако виждате Предупреждение/Неуспех само в JS Agent таблицата, прегледайте причините за статуса на браузърното събитие. Статусът на единично събитие не отваря сам по себе си инцидент.

17.7. Проверка е спряна/неактивна

1. Отворете Проверки.
2. Намерете проверката.
3. Проверете превключвателя Вкл./Изкл..
4. Ако проверката трябва да следи, включете го Вкл.
5. Пуснете Пусни сега за тест.

17.8. Browser Lab Action Journey дава неуспех

Action Journey неуспех означава, че една от стъпките в потребителския път не е минала успешно. Това може да е реален проблем в сайта или настройка, която вече не съвпада с HTML структурата.

Какво да направите:

• Отворете Browser Lab отчета и вижте първата неуспешна стъпка.
• Проверете дали CSS selector-ът на тази стъпка все още съществува и е достатъчно стабилен.
• Проверете дали продуктът, вариантът или бутонът, който проверявате, реално е наличен.
• Ако има изскачащ прозорец, cookie banner или друг overlay, проверете дали той не пречи на стъпката за клик.
• Ако става дума за проверка до checkout страницата, пуснете ръчен тест и проверете дали checkout страницата се отваря нормално.

17.9. Получава се фалшив сигнал

Фалшив сигнал означава, че системата отчита проблем, но реално ситуацията е очаквана.

Примери:

• страницата умишлено няма H1;
• страницата е noindex умишлено;
• текст в полето „„Трябва да съдържа“ е бил променен;
• JS грешката е от шумен външен скрипт.

Какво да направите:

• коригирайте проверка настройката;
• използвайте заглушаване за конкретната грешка;
• добавете шаблон за игнорирана JS грешка;
• сменете влияние на Само информация, ако проблемът е само информационен.

17.10. External Radar показва проблем с доставчик

Когато External Radar покаже проблем или ресурсен сигнал, започнете от конкретния URL и доставчика, а не от общото състояние на сайта.

• Отворете Проблеми, ако има активен Radar проблем, или URL покритие, ако гледате диагностични сигнали като бавни/неуспешни ресурси.
• Проверете дали доставчикът е важен за страницата: плащане, търсене, ревюта, размери, аналитика, app widget или друг видим UX блок.
• Ако искате да потвърдите конкретния адрес, използвайте Провери URL за повторна проверка само на този URL.
• Ако доставчикът е важен, проверете приложението, embed-а, настройката на скрипта, CDN-а или външния доставчик.
• Ако сигналът е очакван шум, използвайте Игнорирай доставчика, вместо да спирате цялата проверка.
• Ако вече е игнориран, използвайте Отмени игнорирането, когато искате отново да влияе на резултата от Radar.

18. Добри практики

• Не добавяйте твърде много проверки без нужда.
• Следете най-важните страници по-често.
• Следете второстепенни страници по-рядко.
• Използвайте ясни имена на сайтове и проверки.
• Винаги тествайте нова проверка с Пусни сега.
• Не оставяйте важни проверки спрени.
• Използвайте влияние „Предупреждение за качество“ за SEO и съдържателни предупреждения.
• Използвайте влияние „Оперативно / критично“ за реални достъпност/кошница проблеми.
• Не заглушавайте целия проверка, ако трябва да заглушите само една грешка.
• За Shopify Cart API health използвайте стабилен, наличен вариант.
• Използвайте разумен режим за видимата история на JS Agent събитията, за да остане списъкът четим.
• Преглеждайте периодично История и Инциденти.
• За проверка само за сигнал за активност оставете браузърните правила за качество празни или изключени.
• Не правете Client-side JS Agent проверка твърде строг веднага на работещ сайт; първо наблюдавайте няколко дни браузърни събития.
• За сайтове с нисък трафик използвайте по-голям Максимум минути без браузърно събитие, за да избегнете фалшиви сигнали.
• Използвайте сървърна SEO проверка за основни SEO правила, а JS Agent проверка като браузърно допълнение.

19. Примерни имена на проверки

За общи сайтове

• Достъпност на началната страница
• Достъпност на страницата за контакт
• Целева страница достъпност
• Thank-you page достъпност
• API здравето endpoint
• SEO на началната страница
• SEO на статия
• Достъпност на страница на категория

За Shopify

• Достъпност на началната страница
• SEO на началната страница
• Достъпност на продуктова страница
• Продукт тагове — основен продукт
• Продукт изображение качество — основен продукт
• Симулация на добавяне в кошница
• Колекция „Нови продукти“ не е празна
• Колекция „Разпродажба“ не е празна
• JS Agent сигнал за активност
• JS Agent браузърно качество
• JS Agent cart.js браузърна проверка
• JS Agent мониторинг на JS грешки
• External Radar — външни доставчици

За проверки на съдържание

• Добави в количката проверка на бутон
• Проверка на текст във форма за контакт
• Кампания — проверка на CTA текст
• Проверка на thank-you потвърждение
• Мониторинг за текст на грешка

20. FAQ

Колко често се изпълняват проверките?

Всяка проверка има собствено поле Интервал в минути. Автоматичният работен процес пуска проверки, когато им е дошло времето. Например проверка с интервал 5 минути може да се изпълнява приблизително на всеки 5 минути, ако е активна.

Какво означава неуспешна проверка?

Означава, че проверката не е минала успешно. Причината може да бъде HTTP грешка, време за изчакване, липсващ очакван текст, намерен забранен текст, проблем с Cart API проверка или друг грешка.

Мога ли временно да спра проверка?

Да. В Проверки използвайте превключвател Вкл./Изкл.. Спряна проверка не се изпълнява автоматично.

Как да разбера дали сайтът ми е недостъпен?

Проверете Таблото, Сайтове, История и Инциденти. Ако началната страница HTTP проверката дава неуспешен резултат последователно и сайтът не се отваря ръчно, вероятно има реален недостъпен сайт.

Какво да направя при SSL предупреждение?

Проверете сертификата в hosting/CDN контролния панел, DNS/CDN настройките и автоматичното подновяване. Ако HTTPS заявката не може да бъде изпълнена, съответната HTTP / Page проверка може да отчете неуспех.

Как да добавя нов сайт?

Отидете в Сайтове → Добави сайт, попълнете Организация, Име на сайта, Основен URL, Платформа и запазете.

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

Отидете в Проверки, намерете проверката и натиснете edit иконката. След промяната натиснете Запази проверката.

Как да изтрия проверка?

В Проверки, ако ролята ви позволява, ще видите delete/trash бутон. Използвайте го внимателно. Изтриването на проверка може да премахне свързана история или да спре важна проверка.

Какви проверки са най-важни за онлайн магазин?

Минимално:

• Достъпност на началната страница;
• важна Достъпност на продуктова страница;
• Симулация на добавяне в кошница;
• важна Колекцията не е празна;
• SEO на началната страница;
• JS Agent сигнал за активност, ако сте избрали да използвате JS Agent и storefront installation е активна.

Какво е Предупреждение за качество?

Предупреждение за качество е проблем, който не означава, че сайтът е паднал. Например Липсва H1, canonical несъответствие или продукт без очакван таг.

Какво е Оперативен проблем?

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

Какво прави заглушаване?

Заглушаването скрива конкретна грешка, така че тя да не влияе на статусите, инциденти и известия. Не трие историята.

Създава ли Client-side JS Agent проверка изпълнение за всяко браузърно събитие?

Не. Браузърните събития се виждат в Проверки → JS Agent. Самата Client-side JS Agent проверка се изпълнява според своя интервал и оценява последното релевантно събитие. Ако агентът изпрати много събития между две изпълнения, това не създава отделно изпълнение за всяко събитие.

Как да оставя Client-side JS Agent проверка само като сигнал за активност?

Попълнете само Максимум минути без браузърно събитие и оставете title/meta/canonical/noindex/JS грешки/производителност/cart.js правилата празни или изключени. Докато няма първо релевантно събитие за тази проверка, тя може да остане Отложено като част от настройката. След първата релевантна активност heartbeat прозорецът се използва, за да засече спиране или остарял браузърен сигнал.

Client-side JS Agent проверка замества ли SEO проверката?

Не. SEO / Canonical / Robots проверката е сървърна и остава основният SEO контрол. Client-side JS Agent проверка показва браузърни сигнали от последното реално браузърно събитие и е допълнение към SEO проверката.

Процентът на извадката гарантира ли точен брой събития?

Не. Процентът на извадката е вероятност при всяко зареждане на страница, не точна квота. Например 1% не гарантира точно 1 събитие на 100 зареждания. При нисък трафик може дълго да няма събитие, затова използвайте по-висок Sampling rate или по-голям прозорец за Максимум минути без браузърно събитие. Ако проверката още няма първо релевантно събитие, това е състояние за настройка/изчакване; предупреждение за липса на скорошни събития е важно след като вече е имало релевантна активност.

Защо виждам Предупреждение/Неуспех в JS Agent, но няма инцидент?

Защото статусът в JS Agent таблицата е статус на отделно браузърно събитие. Той показва какво е видял браузърът при конкретно зареждане, но сам по себе си не отваря инцидент. Инцидент може да се отвори само от активен Client-side JS Agent проверка, който създава изпълнение според своя интервал и има подходящ влияние/прагът на неуспех.

Каква е разликата между “Максимум JS грешки за запис” и “Максимум JS грешки в последното събитие”?

Максимум JS грешки за запис е на ниво сайт лимит: колко JS грешки да се пазят от едно браузърно събитие. Максимум JS грешки в последното събитие е check-level праг: колко JS грешки са позволени, преди Client-side JS Agent изпълнението на проверката да стане проблемно. Празно поле в проверката означава, че тази проверка не гледа броя JS грешки.

Browser Lab същото ли е като JS Agent?

Не. Browser Lab е контролирано браузърно зареждане от GO4. JS Agent е пасивен браузърен слой от реални посетители. Двата източника се показват отделно в Табло.

Защо Browser Lab историята показва по-малко OK редове?

Когато проверката използва Проблемни + последен OK, видимата Browser Lab история е ориентирана към проблемите и последния нормален OK отчет. GO4 може да пази леки точки за тренд в Таблото, но те не са пълни Browser Lab отчети и не всички стари OK изпълнения остават налични за пълно историческо A/B сравнение.

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

Как да сравня конкретни Browser Lab изпълнения или два периода?

Отворете детайлите на Browser Lab проверката → Обобщен анализ → Персонализирано сравнение. Добавете избраните изпълнения към Базова група A и Сравнителна група B, или задайте два периода по дата/час. Можете да добавяте изпълнения към една и съща група и от различни страници на историята; двете групи не е задължително да са с еднакъв брой изпълнения. След това използвайте Сравни A → B. Когато и двете групи имат нужните данни, сравнението може да покаже и конкретни ресурси, които са се появили, изчезнали, станали по-бавни, по-тежки или по-активни. За исторически анализ е най-подходящ режимът Пази всички изпълнения.

Какво е референтно Browser Lab изпълнение?

Това е едно избрано добро историческо изпълнение, което служи като постоянна диагностична отправна точка. Използвайте Запази като референтно, а по-късно Сравни последните с референтното. То е отделно от временните A/B групи и може да бъде премахнато с Премахни референтното. Докато е зададено като референтно, автоматичното почистване на старата история не го премахва; при изрично изтриване на Browser Lab историята то също се премахва.

Защо Browser Lab снимката е без изображения?

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

Влияят ли Browser Lab преди/след тестовете на Табло и инцидентите?

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

Как да проверя дали размер има различна цена?

Използвайте Одит на продукти с включена проверка за консистентност на цените. Ако продуктите имат само опция „Размер“ и всички размери трябва да са една цена, задайте обхват за продукти с точно тази опция и оставете полето „цената може да се различава по“ празно.

Така GO4 ще предупреди, ако един размер е с различна цена от останалите.

Защо продуктът е OK, но има конфигурационна бележка?

Защото бележката не е активен проблем. Тя означава, че дадено правило не е било приложимо към този продукт. Например правило за продукти с опция „Модел“ няма да се приложи към продукт, който има само „Размер“.

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

Дублират ли се обхватът на правилото и опциите за ценова разлика?

Не. Обхватът избира кои продукти да бъдат проверени. Опциите за ценова разлика избират вътре в тези продукти по кои опции цената може нормално да е различна.

Например: при продукт с „Модел“ и „Размер“ може да позволите цената да се различава по „Модел“, но не по „Размер“.

Одитът на продукти замества ли проверката за конкретен продукт?

Не. Проверка за конкретен продукт е удобна за един важен продукт. Одитът на продукти е за избрани или автоматично открити продуктови списъци и работи на групи, с отделни изгледи за Продукти, Проблеми и Прогрес.

Защо едно Browser Lab изпълнение е бавно, а следващото е нормално?

Понякога единично изпълнение има висок TTFB, пик от CDN/мрежа или бавен външен ресурс, без това да означава траен front-end проблем. Отворете Browser Lab обобщението за производителност и използвайте Обобщен анализ върху последните N изпълнения. Гледайте TTFB пикове над 1s, 1.5s и 2s, както и дали FCP/LCP/DOM след TTFB остават стабилни.

Как да проверя lazy уиджет, който се зарежда след скрол?

Създайте Browser Lab проверка с DOM assertion, изберете Действие преди DOM проверка → Скролни до CSS selector, задайте selector на секцията, изчакайте 5000–8000 ms след скрол и проверете selector, който доказва реално заредено съдържание.

Какво е External Radar?

External Radar е проверка за външни доставчици и ресурси, които се зареждат по страниците: уиджети от приложения, вградени елементи, tracking/pixels, CDN ресурси, скриптове и други външни домейни. Тя помага да видите кои URL-и и доставчици създават проблем или повтарящи се ресурсни сигнали.

Защо External Radar не се вижда в менюто?

Отделната секция се показва, когато имате достъп до поне една External Radar проверка. Първата проверка се създава от Проверки → Всички проверки → Добави проверка.

Как да избера страниците за External Radar?

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

Какво става, когато намаля максималния Radar обхват?

След запазване текущото URL покритие се свива до новия лимит. Извадените страници вече не участват в текущите обобщения, а по-старите Radar сканирания могат да останат в историята като контекст.

Защо External Radar покритието не е 100% веднага?

Radar проверява страниците постепенно според настройката Максимум URL-и на изпълнение. Покритието показва колко страници от текущия избран обхват вече имат записано Radar състояние. Докато покритието не е пълно, обобщенията са на база вече проверените URL-и.

Защо виждам бавни сигнали, но няма активен проблем?

Бавните или неуспешни ресурси могат да са диагностични сигнали. Те остават видими в URL покритие и при доставчиците, но стават активен Radar проблем само когато настройките, праговете и важността на доставчика го изискват.

Каква е разликата между текущо състояние и история на Radar сканиранията?

Текущото състояние показва последното завършено състояние за вече проверените URL-и. Историята показва отделните Radar сканирания във времето. Старо сканиране може да показва бавни ресурси, дори ако по-късна проверка вече е изчистила текущия статус.

Какво прави „Провери URL“ в External Radar?

„Провери URL“ пуска фокусирана повторна проверка за конкретния адрес, вместо да чакате той да попадне в следващия нормален пакет. Използвайте го след промяна по приложение, доставчик, скрипт или конкретна страница.

Какво прави „Игнорирай доставчика“?

Игнорирането оставя доставчика видим като контекст, но проблемите от него вече не се броят като активни проблеми в Radar. Можете да отмените игнорирането по-късно.

External Radar замества ли Browser Lab или Sitemap SEO?

Не. External Radar допълва останалите проверки. Browser Lab показва контролирано браузърно зареждане на конкретна страница, Sitemap SEO одитът следи SEO сигнали по много URL-и, а External Radar се фокусира върху външните доставчици и ресурсите, които се зареждат по страниците.

Как да взема Telegram Bot Token и Chat ID?

Създайте bot чрез официалния @BotFather (https://t.me/BotFather) с /newbot. След като изпратите съобщение към новия bot или към групата, в която е добавен, официалният Telegram Bot API метод getUpdates може да покаже message.chat.id. Подробните стъпки и официалните Telegram links са в 15.1. Telegram: Bot Token и Chat ID. Никога не изпращайте Bot Token към GO4 Assistant или Support.

Мога ли да получавам известия в Slack?

Да. В Операции → Известия добавете канал от тип Slack и поставете Incoming Webhook URL. Ако още нямате такъв URL, следвайте 15.2. Slack: Incoming Webhook. Официалната Slack помощ е https://docs.slack.dev/messaging/sending-messages-using-incoming-webhooks/. При свързан Shopify магазин можете да управлявате известията през Open full dashboard без Direct GO4 account, след като има активен план или валиден пробен период. След запис пълният webhook URL не се показва отново и не трябва да се изпраща към GO4 Assistant или Support.

Как се използва „Избери елемент“?

До поддържано CSS selector поле натиснете Избери елемент, при нужда стигнете до правилната страница с Navigate, включете Select element, кликнете върху целта и натиснете Use selector. Selector-ът се връща в точното GO4 поле, но проверката не се записва автоматично. За единичен бутон или контрол обикновено търсете 1 match; при списък или правило за минимален брой елементи няколко съвпадения може да са правилни. Функцията е налична за активни Shopify магазини, свързани с GO4, в HTTP / Page content assertions, Sitemap custom selector rules, JS Agent Custom DOM assertions, Browser Lab DOM/scroll selectors и selector полетата на Action Journey стъпките.

Как се използва Visual Builder за Action Journey?

Пълният Visual Builder е само в Browser Lab → Action Journey → Визуални стъпки → Изгради визуално. Той отваря storefront-а на Journey start URL-а, позволява да избирате елементи и да добавяте, редактирате, пробвате и подреждате стъпки. Navigate е само за настройка и не се записва; при нужда използвайте Set as start. Try пробва само конкретната стъпка и не replay-ва предишните. Checkout preview се отваря в отделен tab и е наличен само когато Проверка от количка до checkout страница е позволена за текущия план. Накрая натиснете веднъж Use journey in GO4, прегледайте върнатия URL и стъпките в оригиналната Browser Lab форма и запазете проверката.

Какво е Browser Lab Action Journey?

Това е Browser Lab проверка с подредени стъпки. Тя може да отвори страница, да натисне елемент, да избере вариант, да изчака количка или да провери дали даден текст, елемент или URL се появява.

Защо проверката до checkout страницата е по-добре да е по-рядка?

Защото достига checkout страницата и е по-дълбока проверка. GO4 не попълва полета и не изпраща поръчка, но самото достигане до checkout може да се вижда в аналитика или funnel отчети.

Какво да направя при неуспешна Action Journey стъпка?

Отворете раздел Journey в Browser Lab отчета, вижте първата неуспешна стъпка и проверете нейния selector, време за изчакване, очакван текст или URL. След промяна пуснете проверката ръчно, преди да разчитате на автоматичния интервал.

21. Каква информация да изпратите към поддръжка

При проблем изпратете:

• име на сайта;
• име на проверката;
• URL/path;
• последен статус;
• HTTP code, ако има;
• време за отговор или Browser Lab измерено време;
• съобщение за грешка/проблем;
• скрийншот от История, Инциденти или Browser Lab отчета;
• линк към конкретния Browser Lab отчет, Sitemap/Shopify одит или изпълнение в История, ако е наличен;
• при Browser Lab проблем с производителността — дали Обобщеният анализ показва повтаряем TTFB spike и дали времето след TTFB е стабилно;
• кога е започнал проблемът;
• дали проблемът се вижда и при ръчно отваряне на сайта.

Това помага проблемът да се провери по-бързо и с правилния контекст.

22. Финален чеклист за въвеждане

Преди да започнете да разчитате на мониторинга, проверете:

• [ ] Сайтът е наличен в GO4 и е Активен.
• [ ] За свързан Shopify магазин има активен план или валиден пробен период и сте използвали Start monitoring, ако началният setup е бил наличен, вместо да добавяте дублиращ сайт.
• [ ] Има поне една основна HTTP / Page проверка за достъпност.
• [ ] Има SEO проверка или Sitemap SEO одит за важните SEO сигнали.
• [ ] За Shopify магазин има Cart API health и/или Browser Lab Action Journey, ако кошницата е критичен път.
• [ ] Product Audit и Collection Audit са добавени, ако са нужни за каталога.
• [ ] JS Agent е включен и инсталиран, ако ще използвате браузърни сигнали от реални посетители.
• [ ] Ако използвате Client-side JS Agent проверка, има поне едно релевантно браузърно събитие за нейния обхват или разбирате, че Отложено може да е нормално състояние по време на първоначалната настройка.
• [ ] Важните проверки са Активни и са тествани с Пусни сега.
• [ ] Няма неволни индикатори Над лимита или Под минимума в plan-aware настройките.
• [ ] Табло показва очаквано състояние и знаете къде са История и Инциденти.
• [ ] Известията са настроени, ако искате Telegram или Slack сигнали.
• [ ] Ако използвате Client-side JS Agent проверка, започнете с heartbeat и добавяйте по-строги правила постепенно.
• [ ] Знаете каква информация да изпратите към поддръжката и кои чувствителни стойности никога да не изпращате.

23. Бърз старт за 5 минути

1. Влезте в системата.
2. Отворете Сайтове.
3. Натиснете Добави сайт.
4. Въведете:

• Име на сайта: My Store
• Основен URL: https://example.com
• Платформа: Shopify или обикновен сайт

1. Запазете сайта.
2. Отворете Проверки.
3. Натиснете Добави проверка.
4. Създайте първа проверка:

• Тип: HTTP / Page проверка
• Име на проверката: Достъпност на началната страница
• URL/path: /
• Очакван HTTP статус: 200
• Интервал: 5 минути или минималният интервал, показан за текущия план
• Влияние върху статуса: Оперативно / критично
• Активна: Вкл.

1. Запазете проверката.
2. Натиснете Пусни сега.
3. Отворете История и проверете резултата.
4. Ако е OK, сайтът вече има основен мониторинг за достъпност.
5. Добавете SEO проверка и допълнителни важни проверки според типа сайт.

24. Практично ръководство за работа

Тази секция събира най-полезните правила за ежедневна работа и бърза ориентация при проблем.

24.1. Как да изберете правилно Влияние

24.2. Решение при проблем за 60 секунди

1. Отворете Табло и вижте дали проблемът е оперативен или е свързан с качество.
2. Отворете конкретното изпълнение или проблем.
3. Проверете страницата ръчно или използвайте съответния модул — Browser Lab, Sitemap, Product/Collection Audit, External Radar или JS Agent.
4. Ако проблемът е реален, коригирайте го и пуснете повторна проверка.
5. Ако е очакван, коригирайте правилото или заглушете само конкретния проблем.

24.3. Чести грешни интерпретации

• Едно бавно Browser Lab изпълнение не доказва постоянен проблем с производителността — сравнете няколко изпълнения.
• External Radar показва вероятен външен фактор, не автоматично доказана причина.
• JS Agent предупреждение не означава непременно, че целият сайт е недостъпен.
• Конфигурационната бележка не е активен Product Audit проблем.
• Заглушеният проблем остава видим за контекст, но не трябва да се третира като активен сигнал.

24.4. Критерии за добро въвеждане

• има поне една базова проверка за достъпност;
• ключовите Shopify пътища имат подходящ сървърен или браузърен сигнал;
• SEO и одит проверките са настроени без излишен шум;
• Процентът на извадката на JS Agent е подходящ за трафика;
• известията водят до ясно действие;
• плановите индикатори във формите са прегледани и няма неволни настройки Над лимита или Под минимума.

25. Sitemap SEO одит

Sitemap SEO Audit открива URL-и от sitemap и ги проверява постепенно за важни SEO сигнали. Подходящ е за масов контрол, а не само за единична страница.

25.1. Кога е полезен

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

25.2. Какво проверява

• title и meta description;
• canonical;
• robots/noindex;
• H1;
• други включени SEO и content правила.

25.3. Основни настройки

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

25.4. Откриване и URL списък

GO4 поддържа URL списък от sitemap източниците. В него виждате кои страници са открити, проверени, чакащи или имат проблем.

25.5. Как се чете URL таблицата

Използвайте статус, последна проверка и броя проблеми, за да намерите URL-и, които изискват внимание. Отворете конкретния URL за подробности.

25.6. Проблеми

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

25.7. Сървърна и браузърна диагностика

Когато има разлика между директно получения HTML и съдържанието след JavaScript, използвайте наличната сървърна/браузърна диагностика, за да сравните сигналите. Това е особено полезно при SEO елементи, които се променят след зареждане.

25.8. Добра практика

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

25.9. OK, Предупреждение и Неуспех

OK означава, че включените правила са изпълнени. Предупреждение означава SEO отклонение, което трябва да бъде прегледано. Неуспех означава по-сериозен проблем според зададената сериозност.

26. Практически сценарии

27. Одит на Shopify колекции

27.1. Къде се намира

Отворете Проверки → Одит на колекции. Там виждате всички Shopify Collection Audit проверки.

27.2. Как работи

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

27.3. Какво виждате

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

27.4. Празни колекции и колекции под минимума

Задайте минимален очакван брой продукти и сериозност за колекции под този минимум. Ако Fail при празна колекция е включено, празната колекция се третира като по-сериозен проблем.

27.5. Проблеми и възстановяване

Проблемите остават видими, докато колекцията не бъде проверена успешно отново. След като коригирате продуктите или collection настройките в Shopify, следващата успешна проверка затваря проблема и историята остава като контекст. Колекция, която вече не е в текущия открит списък, може да остане видима като исторически контекст, но не влияе на текущия статус.

27.6. Размер на групата и ограничения на плана

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

28. Одит на Shopify продукти

28.1. Къде се намира

Отворете Проверки → Одит на продукти. Модулът показва проверки за избрани продукти и проверки с автоматично откриване.

28.2. Как работи

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

28.3. Какво проверява

• задължителни и забранени тагове;
• наличност;
• изображения и минимална резолюция;
• варианти и комбинации;
• цени и compare-at цени;
• едно и също SKU с различна цена в различни продукти.

28.4. Основни действия

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

28.5. Проверки на варианти и цени

28.6. Конфигурационни бележки

Конфигурационната бележка е информационен запис, че конкретно правило не е приложено към продукта. Това не е активен проблем и не трябва да се третира като Предупреждение или Неуспех.

28.7. Добра практика

Включвайте само правила, които отразяват реалната продуктова структура. За голям каталог използвайте автоматично откриване и Максимум продукти на изпълнение в рамките на лимита, показан във формата. След промяна в Shopify пуснете конкретния продукт ръчно или оставете следващата проверка да потвърди възстановяването.

29. Диагностика на проверките

Диагностика е помощен изглед, когато дадена проверка се забавя или достъпът до Shopify storefront-а има временен проблем.

29.1. Какво да гледате

• дали сайтът е активен и достъпен;
• дали има временно ограничение или пауза за заявки към домейна;
• дали Shopify crawler access е активен, ако е настроен;
• дали конкретният одит има собствен диагностичен изглед за проблемния URL.

29.2. Какво да направите при забавена проверка

1. Отворете последното изпълнение и вижте кратката причина.
2. Проверете страницата ръчно.
3. Ако Shopify временно ограничава автоматичните заявки, прегледайте crawler access.
4. При Sitemap проблем отворете конкретния URL в Sitemap SEO одита.
5. Пуснете ръчна повторна проверка, когато временният проблем е отминал.

29.3. Shopify crawler access

Ако crawler access е изтекъл или липсва и Shopify ограничава автоматичните заявки, създайте нов подпис от Online Store → Preferences → Crawler access. В GO4 го поставете в Administration → Crawler access при Shopify достъп или в Сайтове → редакция на съответния Shopify сайт → Shopify crawler access при Direct GO4 login.

30. Препоръчителни комбинации от проверки

31. Експерименти и безопасно тестване

Когато въвеждате ново правило, започнете спокойно: първо наблюдавайте сигнала, после затягайте сериозността и поведението за инциденти.

31.1. Безопасен модел за експерименти

1. Клонирайте работеща проверка или създайте нова с ясно име.
2. Оставете я неактивна или с по-меко влияние, докато настройвате правилото.
3. Пуснете ръчен тест и прегледайте резултата.
4. Коригирайте selector-а, прага, обхвата или размера на групата при нужда.
5. Когато сигналът е стабилен, активирайте автоматичния мониторинг и поведението за инциденти, ако е необходимо.

31.2. Практични експерименти

32. Карта на настройките

33. Къде да отида според ситуацията