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

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

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

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

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

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

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

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

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

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

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

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

В интерфейса са налични следните основни секции:

GO4 включва следните типове проверки:

• HTTP / Page проверка — следи HTTP статус, време за отговор, очакван/забранен текст и по желание допълнителна проверка на съдържание чрез сървърен HTML или браузърен DOM след JavaScript.
• SEO / Canonical / Robots проверка — проверява SEO сигналите на един конкретен URL.
• Shopify симулация на кошница — тества дали избран Shopify продукт може да се добави в количка без финализиране на поръчка.
• Shopify продуктови правила — проверява конкретен Shopify продукт или много продукти, открити от product sitemap; следи тагове, наличност, изображения и variant QA правила, включително ценова консистентност по option names.
• Shopify правила за колекция — може да следи конкретна колекция или много колекции, открити от Shopify sitemap.
• Browser Lab — контролирано браузърно зареждане от GO4 за конкретен URL/path с избран Desktop или Mobile профил, отделно от JS Agent и от одит диагностиките. Включва и преди/след тестове за безопасно сравнение на промяна в app embed, скрипт, таг, плъгин или тема.
• External Radar — следи външни доставчици и ресурси по страниците, показва проблемни URL-и и помага да управлявате доставчици като важни или игнорирани.
• Client-side JS Agent проверка — оценява последното релевантно браузърно събитие от agent.js: сигнал за активност, браузърни SEO сигнали, DOM правила, JS грешки, производителност, cart.js и по желание компактна ресурсна диагностика към запазените събития.
• Sitemap SEO одит — открива много URL-и от sitemap XML, поддържа постоянен URL списък, проверява страниците постепенно, поддържа сървърна и браузърна диагностика, персонални проверки в суров сървърен HTML и може да маркира отделен URL като премахнат от sitemap списък.

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

API или health endpoint може да се следи чрез HTTP / Page проверка, като зададете пълен URL, очакван HTTP статус и по желание текст, който трябва да присъства в отговора.

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

Сайт

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

Примери:

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

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

Организация

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

Проверка

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

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

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

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

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

Изпълнение

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

Статус

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

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

Инцидент

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

Грешка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Сървърни проверки — HTTP/SEO измервания, направени от GO4;
• Browser Lab — контролирани браузърни зареждания на избрани страници от GO4;
• Реални посетители / JS Agent — браузърни сигнали от реални посетители;
• Одит / Shopify — време за Sitemap, Shopify и други одит изпълнения.

Графиката Тренд на здравето на сайтовете има два компактни изскачащи менюта избора: Период и Източник. Изборът се обновява без пълно презареждане на страницата, когато JavaScript е наличен. Периодите са Днес, Вчера, Последните 7 дни и Последните 30 дни. Източниците са Сървърни проверки, Browser Lab — всички, Browser Lab — Desktop, Browser Lab — Mobile, Реални посетители / JS Agent, Одит / Shopify и Всички източници.

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

Всички източници е смесен изглед за обща ориентация. Когато анализирате скорост или забавяне, гледайте конкретния източник: сървърни проверки, Browser Lab — Desktop, Browser Lab — Mobile, реални посетители / JS Agent или одит изпълнения. Много големи единични пикове може да се показват ограничено в графиката, за да остане тя четима; реалната стойност остава видима в История, Browser Lab отчет или JS Agent събитието.

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

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

След това прегледайте:

• Проблеми по тип — показва само типове, при които има активни проблеми; когато няма активни проблеми, показва чисто празно състояние вместо празна таблица;
• Здраве на сайтовете — разделя оперативно здраве, качество, измерено време и тренд за 24 часа;
• Бързи действия — водят към най-честите работни места;
• Отворени инциденти — показва текущите инциденти като отделни карти;
• Последни изпълнения — показва последните проверки и дава връзки към конкретния проблем, Browser Lab отчет или използваното JS Agent събитие, когато е възможно.

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

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

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

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

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 агентът не добавя продукти в количката, не прави финализиране на поръчка и не променя страницата. Той е пасивен слой за мониторинг.

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

5.4. Shopify crawler подпис

Shopify crawler подпис е опционална настройка само за Shopify сайтове. Той използва Shopify Web Bot Auth данни, за да помогне на Shopify да разпознава GO4 при сървърни заявки към конкретния Shopify домейн.

Секцията се показва само когато платформата на сайта е Shopify. При обикновен сайт секцията не се вижда и не се използва.

Подписът се използва за GO4 сървърна диагностика, Sitemap SEO одит, Одит на Shopify колекции, Shopify JSON заявки и браузърна диагностика към същия Shopify домейн. Не се изпраща към други домейни.

За всеки Shopify домейн трябва отделен подпис. Ако следите два различни Shopify сайта, настройте подпис поотделно за всеки сайт.

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

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

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

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

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

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

Включи JS агент: Включено, ако ще добавяте agent.js в сайта

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

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

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

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

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

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

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 да я разпредели в нормалните полета на формата.

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

За браузърни проверки избирайте по-рядък интервал, например 10–30 минути, освен ако елементът не е критичен. За блок с отзиви, Instagram feed, галерия или подобен уиджет обикновено е по-точно влиянието да е Предупреждение за качество, не оперативен проблем.

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

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

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

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

URL или път: /

Метод: GET

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

Интервал: 3 или 5 минути

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

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

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

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

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

• Страницата отговаря.
• 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 симулация на кошница

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

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

Тя използва Shopify storefront endpoint-и като:

• /cart/add.js
• /cart.js
• /cart/clear.js, когато е включено изчистване преди/след теста

Важно: това е синтетичен тест от системата за мониторинг. Не добавя продукти в количките на реални клиенти.

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

Използвайте го за Shopify магазини, за да следите дали:

• endpoint-ът за добавяне в кошницата работи;
• избраният вариант може да бъде добавен;
• /cart.js връща очаквания продукт след добавяне;
• кошница системата не е счупена.

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

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

Име на проверката: Симулация на добавяне в кошница

Тип: Shopify симулация на кошница

Variant ID: 49123456789012

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

Изчисти кошницата преди теста: включено

Изчисти кошницата след теста: включено

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

Интервал: 5 минути

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

• /cart/add.js връща успешен отговор;
• /cart.js може да се прочете;
• вариантът се намира в кошница JSON след add;
• quantity е очакваното.

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

• липсва вариант ID;
• /cart/add.js връща грешка;
• вариантът не се намира в /cart.js след добавяне;
• кошница JSON не може да се прочете;
• продуктът е недостъпен или невалиден.

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

1. Проверете дали вариант ID е правилен.
2. Проверете дали продуктът е активен и наличен.
3. Проверете дали storefront/кошница endpoint-ите работят.
4. Проверете дали Shopify app/theme не блокира логиката за добавяне в кошница.
5. Ако продуктът е спрян, сменете тестовия вариант.

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

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

Този тип проверка чете Shopify product JSON и проверява важни продуктови правила. Може да се използва по два начина:

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

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

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

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

Режим „Продукти от sitemap“

В този режим sitemap-ът служи само като източник на продуктови URL-и. Реалната проверка се прави чрез Shopify product JSON за всеки продукт.

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

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

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

Пример 1: продукт само с размери

Продуктът има опция Размер с варианти S, M и L. Очаквате всички размери да са на една цена.

• Обхват: продукти с точно опция „Размер“;
• Цената може да се различава по: оставете празно;
• Резултат: ако един размер е с различна цена, GO4 го показва като проблем.

Пример 2: продукт с модел и размер

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

• Обхват: продукти, които имат опция „Модел“;
• Цената може да се различава по: „Модел“;
• Резултат: GO4 допуска Basic и Premium да са различна цена, но ще предупреди, ако размер L в Basic е различна цена от размер S в Basic.

Пример 3: продукт с цвят и размер

Продуктът има опции Цвят и Размер, но нито цветът, нито размерът трябва да променят цената.

• Обхват: продукти, които имат опции „Цвят“ и „Размер“;
• Цената може да се различава по: оставете празно;
• Резултат: всяка разлика в цената между цветове или размери се показва като проблем.

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

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

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

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

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

Успешен резултат означава, че product JSON е прочетен и включените правила са минали успешно. Ако дадено правило не важи за продукта, може да има конфигурационна бележка, без продуктът да е проблемен.

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

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

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

Тази проверка проверява Shopify JSON на колекцията.

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

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

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

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

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

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

Име на проверката: Колекцията не е празна — Нови продукти

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

URL/path: /collections/new-arrivals

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

Неуспех при празна колекция: включено

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

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

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

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

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

Колекции от sitemap режим

В този режим GO4 използва Shopify sitemap XML файловете като източник на URL-и на колекции. Това е режим в съществуващия тип Shopify правила за колекция.

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

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

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

Основни настройки за sitemap режим

Как се броят продуктите

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

Какво става, ако колекция бъде махната от sitemap-а

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

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

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

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

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

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

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

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

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

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

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

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

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

Запис на съвпадащи събития

Компактният режим пази по-малко OK записи и е подходящ, когато искате да виждате основно проблемите и последното успешно доказателство.

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

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

И двете настройки имат режими: Не записвай, Записвай само при Предупреждение/Неуспех и Записвай при всяко запазено събитие. Ресурсната диагностика не променя статуса на проверката сама по себе си — тя е контекст към вече запазено браузърно събитие.

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 е отделен слой от JS Agent, Sitemap браузърната диагностика и Shopify/Sitemap одитите. Той е подходящ, когато искате GO4 сам да отвори конкретна страница и да измери как се държи тя в контролирана браузърна среда.

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

• за важна начална, продуктова, страница на колекция или кампания;
• за отделно наблюдение на desktop и mobile зареждане, когато мобилната версия има различно меню, банер, app embed, tracking или layout поведение;
• за проверка на време за браузърно зареждане, DOMContentLoaded, HTTP статус и крайния URL;
• за наблюдение на JavaScript грешки и неуспешни ресурси без да чакате реален посетител;
• за контролирано сравнение между сървърни проверки, Browser Lab и JS Agent сигнали;
• за DOM правило само за четене след JavaScript, например дали бутон, уиджет или текст присъства.
• за проверка на lazy уиджети или секции, които се зареждат чак след scroll до тях;

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

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

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

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

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

Browser Lab performance обобщение

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

Обобщеният анализ използва median, min, max, p75, outliers и стабилност. Показва и TTFB reliability: колко от валидните проби са над 1s, 1.5s и 2s. Така по-лесно се различава единичен TTFB/CDN/network пик от повтаряем проблем.

Когато TTFB е висок, но FCP, LCP, DOMContentLoaded и Full load след TTFB остават стабилни, това е сигнал, че забавянето вероятно е преди HTML-ът да стигне до браузъра, а не непременно front-end/theme regression.

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

Визуално доказателство със снимка е опционална настройка на 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 след scroll

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

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

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

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

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

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

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

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

Име: Homepage — Browser Lab — Desktop

Тип: Browser Lab

URL или път: /

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

Интервал: 5–15 минути за критична страница или 15–60 минути за наблюдение

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

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

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

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

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

История: Проблемни + последен OK

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

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

7.8. External Radar

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

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

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

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

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

URL покритие

Покритие показва колко URL-а вече са проверени от всички открити кандидати. Например 97 / 513 означава, че GO4 има последно известно състояние за 97 URL-а, а останалите още не са минали през Radar сканиране.

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

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

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

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

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

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

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

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

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

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

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

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

Тази таблица обобщава безопасен старт за основните типове проверки.

8. Активиране и спиране на проверки

В секция Проверки има превключвател за всяка проверка.

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

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

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

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

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

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

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

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

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

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

• Тип: Shopify продуктови правила
• Източник на продукти: Продукти от sitemap
• Първи правила: задължителни тагове, забранени тагове, наличност и изображения според нуждите
• Размер на групата: 20–50 продукта на изпълнение за начало
• Проверки на вариантите: включете ги след като знаете реалните имена на 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;
• външно мрежово време за изчакване.

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

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

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

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

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

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

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

Когато История се отвори от Табло или от badge в Сайтове, GO4 показва кратка карта с детайлите на drill-down филтъра. Тя обяснява дали гледате период от Dashboard графиката, оперативни проблеми за конкретен сайт или предупреждения за качество.

Browser Lab редовете в История са компактни. Подробните списъци с ресурси, JS сигнали и DOM контекст се отварят през Browser Lab отчет. Когато Browser Lab използва режим Проблемни + последен OK, История остава фокусирана върху проблемните отчети и последния успешен отчет.

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

• OK — проверката е минала без активни незаглушени проблеми.
• Предупреждение — има проблем с качеството или по-мек сигнал, който изисква преглед.
• Неуспех — има по-сериозен проблем според настройките на проверката.
• Активни проблеми — конкретните проблеми, които влияят на статуса/качеството.
• Заглушени грешки — проблеми, които са разпознати, но не влияят на статус, инциденти или известия за избрания обхват.

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

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

При Sitemap SEO и Shopify Collection audit изпълненията История може да показва проблеми от историческия snapshot на самото изпълнение. Бутонът Виж проблемите от изпълнението отваря/разпъва точно този исторически контекст, вместо да ви изпраща сляпо към текущия live audit списък, който вече може да е променен.

Ако за отделен проблем има бутон Виж текущия audit контекст, той отваря съответния audit изглед с по-широк статус филтър, за да може да потърсите URL-а или проблема и когато вече е resolved, muted или не е част от текущите активни проблеми.

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

Изтриване / зануляване в История

Наличните действия в История зависят от ролята:

• Единично изтриване на изпълнение премахва само един запис за изпълнение. Това е подходящо за очевидни тестови или грешно пуснати записи, когато ролята ви го позволява.
• Изтриване на филтрираните изпълнения премахва много исторически записи по текущите филтри и е достъпно само за роли с подходящи права.
• Зануляване на филтрираните изпълнения премахва същата история и занулява последен статус / последно изпълнение / последно време за отговор за засегнатите проверки. Това е силно действие и не е част от обичайната ежедневна работа.

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

12. Инциденти

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

Има два важни типа контекст:

• Оперативен инцидент — сайтът или важна функция може да не работи нормално.
• Инцидент за качество — има проблеми с качеството, например SEO/Sitemap/проблеми с колекции, но това не означава непременно, че сайтът е недостъпен.

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

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

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

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

Настройка за инцидент за качество

Проверки като Sitemap SEO одит, Одит на Shopify колекции и SEO / Canonical / Robots могат да имат настройка Отваряй инцидент при активни проблеми с качеството.

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

Затвори/занули филтрираните

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

Изтриване на филтрираните инциденти

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

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

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

Пример:

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

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

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

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

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

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

14. JS агент

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

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

• URL/path;
• title, meta description, canonical и robots/noindex от DOM-а;
• JavaScript грешки;
• браузърни стойности за производителност;
• viewport/screen размери;
• пасивни Shopify hints и /cart.js статус;
• резултати от безопасни DOM правила, когато има активни Client-side JS Agent проверки, които ги изискват;
• компактни извадки за топ бавни и топ тежки браузърни ресурси, когато конкретна JS Agent проверка е настроена да ги пази.

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

Какво става, ако Client-side JS Agent проверка е изключена

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

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

• не добавя продукти в количката;
• не финализира поръчки и не създава поръчки;
• не променя страницата или потребителската сесия;
• не изпълнява произволен JavaScript, написан в админа;
• не служи като crawler за Sitemap SEO одит или Одит на Shopify колекции.

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

Отворете Проверки → JS Agent. Там се виждат последните браузърни събития, съвпадащите проверки, статусът на събитието, браузърните SEO сигнали, JS грешките, стойности за производителността, cart.js статусът, резултатите от DOM правилата, ресурсната диагностика към конкретно събитие и повтарящите се ресурсни модели за текущите филтри.

KPI карти и агрегирани статистики

Горните KPI карти в раздел Проверки → JS Agent използват агрегирани данни, когато такива са налични. Те дават обща картина за избраните филтри: съвпадащи браузърни събития, предупреждения, средно браузърно зареждане и приблизителен размер на данните на събитието.

Диагностика на ресурси в JS Agent

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

Секцията Най-вероятни причини дава приоритет на ресурси, които най-често си струва да се проверят: външни скриптове, CSS, fetch/XHR, медия/видео и ресурси с високо време. Фонови аналитични и телеметрия заявки се отделят, защото често имат дълго време, но не винаги блокират визуалното зареждане.

Повтарящи се ресурсни модели

Секцията Повтарящи се ресурси групира запазената ресурсна диагностика от текущо филтрираните браузърни събития. Тя помага да видите дали един и същ домейн, конкретен скрипт, Shopify asset, page fetch или медия/видео модел се повтаря в много събития.

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

Използвайте филтрите над таблицата, за да изолирате сайт, JS Agent проверка, статус, тип страница, сигнал или търсене по URL/източник. Така може да проверите дали даден външни домейн, скрипт от приложение, video CDN или Shopify endpoint се повтаря само при конкретен сайт/страница или е общ проблем.

Как се определя статусът на браузърно събитие

Статусът на браузърното събитие показва какво е видял самият браузър при това зареждане. Той може да е OK, Предупреждение или Неуспех според JS грешки, производителност, cart.js, SEO/DOM сигнали и правила за съвпадение.

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

JS Agent събития срещу История / Инциденти

JS грешка настройки и прагове

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

Как Client-side JS Agent проверка използва тези данни

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

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

Сървърната SEO проверка гледа HTML-а, върнат от сървърно извличане. JS Agent гледа DOM и сигнали от реален браузър. Ако има разлика, използвайте Sitemap сравнение сървър/браузър или браузърна диагностика, за да разберете къде се появява проблемът.

15. Известия

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

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

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

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

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

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

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

Организации

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

Admin с достъп до организация може да вижда секцията Организации само за достъпните организации. Ако има достъп до една организация, GO4 може да го насочи директно към редакцията ѝ; ако има достъп до няколко, вижда списък само с тях. Това не му дава допълнителни системни права.

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

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

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

Потребители

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

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

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 симулация на кошница дава неуспех

1. Проверете вариант ID.
2. Уверете се, че продуктът е наличен.
3. Проверете дали /cart/add.js работи.
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 агентът е включен за сайта.
2. Проверете дали кодът на агента е поставен в сайта.
3. Отворете сайта в браузър и изчакайте няколко секунди.
4. Проверете JS агент секцията за ново събитие.
5. Ако сайтът има малко трафик, увеличете Максимум минути без браузърно събитие.
6. Ако проверката вече има включени правила за качество, проверете конкретната грешка в История: липсва title/meta/canonical, има noindex, JS грешка, бавно зареждане или cart.js проблем.
7. Ако виждате Предупреждение/Неуспех само в JS Agent таблицата, отворете Причини за статуса на браузърното събитие. Това може да е само статус на ниво събитие и да не е инцидент.
8. Ако очаквате инцидент, проверете дали има активна Client-side JS Agent проверка, дали влиянието позволява инциденти и дали прагът на неуспех е достигнат.
9. Ако липсва даден браузърен сигнал, уверете се, че съответното събиране е включено в Настройки на сайта за JS агента.

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

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

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

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

Примери:

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

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

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

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

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

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

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

• Не добавяйте твърде много проверки без нужда.
• Следете най-важните страници по-често.
• Следете второстепенни страници по-рядко.
• Използвайте ясни имена на сайтове и проверки.
• Винаги тествайте нова проверка с Пусни сега.
• Не оставяйте важни проверки спрени.
• Използвайте влияние „Предупреждение за качество“ за SEO и съдържателни предупреждения.
• Използвайте влияние „Оперативно / критично“ за реални достъпност/кошница проблеми.
• Не заглушавайте целия проверка, ако трябва да заглушите само една грешка.
• За Shopify симулация на кошница използвайте стабилен, наличен вариант.
• Поддържайте разумно задържане на JS Agent събития, за да остане историята управляема.
• Преглеждайте периодично История и Инциденти.
• За стар 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 грешка, време за изчакване, липсващ очакван текст, намерен забранен текст, проблем с симулация на кошница или друг грешка.

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

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

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

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

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

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

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

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

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

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

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

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

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

Минимално:

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

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

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

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

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

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

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

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

Не. Браузърни събития се записват в таблицата със JS Agent събития. Проверката се изпълнява според своя интервал и при всяко изпълнение гледа последното събитие. Ако агентът изпрати 500 събития за час, а интервалът на проверката е 15 минути, в История ще има приблизително 4 изпълнения, не 500.

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

Попълнете само Максимум минути без браузърно събитие и оставете title/meta/canonical/noindex/JS грешки/производителност/cart.js правилата празни или изключени.

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

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

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

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

Защо виждам Предупреждение/Неуспех в 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 отчети.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не. Проверка за конкретен продукт е удобна за един важен продукт. Одитът на продукти е за много продукти от sitemap и работи на групи, с отделни изгледи за Products, Problems/Findings и Progress.

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

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

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

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

Какво е External Radar?

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

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

При много 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 се фокусира върху външните доставчици и ресурсите, които се зареждат по страниците.

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

Да. В Операции → Известия добавете канал от тип Slack, въведете Slack webhook URL и изберете дали да има бутони за действие. След запис пълният webhook URL не се показва отново.

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

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

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

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

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

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

• [ ] Създадена е организация.
• [ ] Добавен е Сайт.
• [ ] Сайтът е Активен.
• [ ] Избран е правилен Платформа: Shopify или обикновен сайт.
• [ ] Добавен е Достъпност на началната страница проверка.
• [ ] Добавен е SEO проверка за важна страница.
• [ ] За Shopify магазин е добавен Симулация на добавяне в кошница.
• [ ] За Shopify магазин са добавени продукт/проверки за колекции, ако са нужни.
• [ ] JS агентът е включен, ако ще се използва.
• [ ] Кодът на агента е добавен в сайта, ако се използва JS агент.
• [ ] Проверки са Вкл.
• [ ] Всяка важна проверка е тестван с Пусни сега.
• [ ] Табло показва нормален статус.
• [ ] Клиентът знае къде са История и Инциденти.
• [ ] Клиентът знае какво да изпрати при проблем.
• [ ] Ако се използва Client-side JS Agent проверка, стартирайте първо само режим за сигнал за активност.
• [ ] Ако включвате браузърни правила за качество, потвърдете, че съответните настройки за събиране на данни в сайта са включени.

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. Разширен операторски наръчник

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

24.1. Карта на данните в системата

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

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

1. Отворете последното изпълнение или проблем от одит.
2. Вижте дали проблемът е оперативен, качествен или само браузърен сигнал.
3. Проверете дали има активни и заглушени проблеми.
4. Ако е реален проблем — поправете сайта.
5. Ако е очаквано поведение — заглушете конкретния проблем.
6. Ако сигналът е шумен — коригирайте праг, включване/изключване шаблон или инцидент настройката.

24.4. Активен сайт, архивиран сайт и неактивна организация

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

24.5. Матрица на състоянията на JS агента

24.6. Заглушени грешки — дълбока логика

Заглушаване не изтрива проблема. То казва: „този конкретен проблем е приемлив за този обхват“. Заглушените проблеми не влияят на броячите за качество, инцидентите и известията. Премахване на заглушаването връща проблема към нормална оценка при следващото изпълнение.

24.7. Препоръчителни JS Agent настройки според трафика

24.8. История и архивни данни

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

• История / изпълнения показва какво е отчела всяка проверка във времето.
• JS Agent събития са отделен браузърен контекст и не са същото като История.
• Sitemap и Shopify одитни списъци съдържат текущи URL-и, проблеми, заглушавания и прогрес. Занулявайте ги само когато искате проверката да изгради списъка наново.
• Инциденти показват жизнения цикъл на проблемите и не трябва да се бъркат с единични изпълнения.

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

24.9. Права и липсващи бутони

Ако даден бутон липсва, най-често причината е липсващо право, не грешка в интерфейса. Това важи за редакция, delete/зануляване, заглушаване/премахване на заглушаване, close инцидент, преоткриване и действия в одитните изгледи.

• Viewer вижда информация, но не извършва действия.
• Operator може да пуска проверки и диагностики, но не редактира и не затваря/заглушава проблеми.
• Manager управлява мониторинга: проверки, единични инциденти, заглушаване, преоткриване и единично изтриване на изпълнение. Не управлява сайтове и не изпълнява масови действия за поддръжка.
• Admin управлява сайтове, проверки, потребители и действия за поддръжка в рамките на достъпа си.

24.10. Примерно разследване на инцидент

1. Отворете инцидента от Табло или Инциденти.
2. Вижте обобщението: колко проблеми и за кои URL-и/колекции.
3. Отворете контекстна връзка към Sitemap одит, Одит на колекции или История.
4. Проверете активни/заглушени проблеми.
5. Поправете сайта или заглушете конкретния очакван проблем.

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

• Предупреждение за качество не означава непременно, че сайтът е недостъпен.
• Браузърен DOM предупреждение не идва от JS Agent, а от браузърен Sitemap диагностика.
• Приемане на браузърния резултат не приема лош браузърен сигнал — той трябва да е валиден според праговете.
• 30 URL групи не винаги означава 30 проблеми; един URL може да има няколко проблеми.

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

• [ ] Има поне една базова HTTP проверка.
• [ ] Важните страници имат SEO / Canonical / Robots или Sitemap SEO покритие.
• [ ] Shopify магазините имат симулация на кошница и Одит на колекции, когато е приложимо.
• [ ] JS Agent е тестван, ако се използва.
• [ ] Инцидент за качество настройките са съобразени с това кои предупреждения наистина трябва да отварят инциденти.
• [ ] Известията са тествани с безопасен тестов инцидент.

25. Sitemap SEO проверка

Sitemap SEO одитът следи SEO качеството на много URL-и, открити от sitemap XML файловете на сайта. GO4 пази постоянен URL списък и проверява страниците постепенно, вместо да обхожда целия сайт наведнъж.

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

25.1. Кога се използва Sitemap SEO одит

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

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

25.3. Как са подредени настройките

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

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

Тази секция позволява да добавите до няколко правила, които се изпълняват само върху URL-и от sitemap списък и само след успешно извличане на сървърен HTML.

Правилата със CSS селектор работят върху суров сървърен HTML / изходен HTML. Те не използват браузърен DOM. Ако даден елемент се появява само след JavaScript рендериране, използвайте браузърна диагностика за преглед, но персонално сървърно правило няма да го счита за намерен.

Условия за пропускане

Пример за активни продукти: правило .model-sizing-text-wrapper трябва да съществува, но условие за пропускане button[id^="AddToCart--"][disabled] пропуска изчерпаните продукти, защото при тях липсата на блок с информация за модел/размер може да е очаквана.

25.4. Текстова SEO хигиена

Текстовата SEO хигиена проверява дали title, meta description, canonical/robots контекст и други SEO текстове изглеждат чисти за публично показване. Тя е контрол на качеството, не проверка за оперативна недостъпност.

25.5. Откриване, източници и URL списък

GO4 започва от зададените Sitemap URL-и, например /sitemap.xml, открива дъщерни sitemap-и и пази активен URL списък. Include/Exclude шаблони не са самите sitemap източници — те ограничават кои открити page URL-и реално се одитират.

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

25.6. Раздел Sitemaps

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

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

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

• Обнови сървърната диагностика извлича свеж сървърен HTML и може да обнови статус/проблеми за този URL.
• Преглед на сървърния HTML показва преглед на сървърния HTML на живо за преглед, без да служи като отделен crawler.
• Извлечи браузърен DOM пуска браузърна диагностика, когато е налична за URL-а.
• Маркирай като премахнат маркира URL-а като неактивен в активния списък, ако вече не трябва да влияе на обобщението.

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

25.8. Изглед с проблеми

Изгледът с проблеми групира проблемите по URL. Един URL може да има няколко проблеми: липсващ title, canonical несъответствие, липсващ персонален селектор, SEO hygiene предупреждение и др. Всеки конкретен проблем може да се заглуши, ако ролята го позволява.

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

CSV експорт на проблемите

В раздел Проблеми има бутон Експорт, който отваря модал за CSV файл. Можете да изберете обхват на проблемите и кои колони да влязат във файла. Експортът е подходящ за споделяне към SEO, съдържателен или технически екип, без да се дава директен достъп до админ панела.

25.9. Сървърна диагностика и преглед на HTML на живо

Сървърната диагностика показва структуриран диагностична снимка от сървърно извличане: HTTP статус, краен URL, title/meta/canonical/H1, резултати от персонални правила и други сигнали. Прегледът на HTML на живо показва HTML-а, който GO4 вижда при директно извличане на страницата.

Сървърният HTML може да се различава от това, което виждате в браузър с администраторска сесия, preview режим, различен market/currency или след JavaScript рендериране.

25.10. Запазени резултати от сървърна диагностика

Запазеният резултат от сървърна диагностика показва SEO сигналите от конкретната проверка. Когато трябва да видите HTML-а, използвайте ръчния преглед на HTML.

25.11. Диагностична опашка

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

25.12. Браузърна диагностика

Браузърната диагностика отваря страницата в контролиран браузър и вижда DOM-а след зареждане и изпълнение на JavaScript. Тя е полезна за страници с много JavaScript и за сравнение със сървърния HTML.

Това е различно от JS Agent: браузърната диагностика е контролиран браузърен преглед на конкретен URL, докато JS Agent събира събития от реални посетителски браузъри чрез agent.js.

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

25.13. Сравнение сървър/браузър

Сравнението показва къде сървърен HTML и браузърен DOM се разминават: title, description, canonical, robots/noindex, H1 и други SEO сигнали. Това помага да се разбере дали проблемът е сървърен или се появява след JavaScript рендериране.

25.14. Браузърна допълнителна диагностика, приемане и Предупреждения от браузърния DOM

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

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

25.15. Заглушаване, зануляване и логика на списъка

• Заглушен проблем не влияе на обобщението за качество на URL/сайта, инциденти или известия.
• Ако всички проблеми за URL са заглушени, URL-ът може да изглежда OK/без активни проблеми.
• Заглуши избраните проблеми е масово действие за избрани URL-и. То не изтрива проблеми и не заглушава цялата проверка; прилага се само към активните проблеми за избраните URL-и.
• Маркирай като премахнат е безопасен меко премахване за конкретен URL и следващо откриване може да го активира отново, ако URL-ът се върне в sitemap.
• Зануляване данните от одита е силно действие и трябва да се използва само когато искате да започнете списъка на тази проверка отначало.

25.16. Практични Sitemap SEO настройки

25.17. OK, Предупреждение и Неуспех при Sitemap SEO одит

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

• OK — няма активни незаглушени проблеми за текущия URL/check.
• Предупреждение — има проблем с качеството: SEO предупреждение, проблем от персонално правило, проблем с текстовата хигиена, браузърен DOM предупреждение или подобен сигнал.
• Неуспех — има по-сериозен fetch/HTTP/cURL проблем според настройките или страница не може да бъде проверена успешно.

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

Тази секция е бърз “какво да направя” наръчник за нов потребител.

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

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

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

Отворете Проверки → Одит на колекции. Списъкът с общ преглед показва достъпните проверки за колекции в sitemap режим. В детайлите на конкретна проверка има директен селектор, с който можете да смените към друг одит на колекции без да се връщате през менюто.

27.2. Как се чете таблицата за общ преглед

27.3. Раздели в детайлите

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

Филтри и експорт в одита на колекции

В режим Колекции от sitemap разделът Колекции може да се филтрира по състояние на списъка: активни, премахнати от sitemap и всички запазени. Разделът Проблеми по подразбиране показва Активни проблеми — нерешени и незаглушени проблеми. Отделният филтър Заглушени проблеми показва нерешените заглушени проблеми, които остават видими като контекст, но не влияят на статуси, инциденти и известия.

В раздел Проблеми има модал за CSV експорт с избор на обхват и колони. Експортът с текущите филтри следва избрания изглед — например активни или заглушени проблеми. Това е удобно, когато трябва да изпратите списък с празни или проблемни колекции за преглед извън GO4.

27.4. Добра практика за Shopify магазин

27.5. Зануляване и премахнати колекции

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

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

27.6. Логика за броя продукти

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

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

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

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

Този модул е за магазини с много продукти. Вместо да създавате отделна проверка за всеки продукт, GO4 открива продуктовите URL-и от Shopify sitemap, пази списък с тях и ги проверява на контролирани групи.

28.2. Как се чете общият изглед

28.3. Раздели в детайлите

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

28.5. Проверки на вариантите в Одит на продукти

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

Най-важното е да разделите две неща:

1. Към кои продукти важи правилото? Това е обхватът на ценовото правило.
2. Вътре в тези продукти по кои опции цената може нормално да се различава? Това е списъкът с опции, по които цената има право да се променя.

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

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

Пример: имате ценово правило за продукти с опция „Модел“, но даден продукт има само опция „Размер“. GO4 няма да сравнява цената по грешна логика. Вместо това ще покаже бележка, че правилото е пропуснато за този продукт.

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

28.7. Добра практика за Shopify магазин

• Започнете с умерен размер на групата, например 20–50 продукта на изпълнение.
• Първо включете най-важните правила: наличност, задължителни тагове и изображения.
• Добавете ценови правила чак когато сте сигурни как са именувани Shopify опциите в продуктите.
• За различни продуктови структури използвайте отделни проверки, например една за продукти само с размер и друга за продукти с модел/тип + размер.
• Заглушавайте конкретен проблем само когато е очакван. Ако много продукти дават една и съща бележка, по-вероятно е да трябва настройка на обхвата.
• Не увеличавайте агресивно броя продукти на изпълнение при голям магазин. По-добре е одитът да се движи стабилно на групи.

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

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

29.1. Какво показва Диагностика

29.2. Как се използва при забавена проверка

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

29.3. Временни паузи и отложени проверки

GO4 може временно да отложи автоматични заявки към даден сайт при 429, bot challenge, временни 5xx отговори, мрежов проблем или прекалено много заявки към един host. Това пази наблюдавания сайт от излишно натоварване и намалява фалшивите аларми при кратки външни ограничения.

Състояния като Host fetch paused: rate_limited_429 и page_fetch_deferred не са SEO проблеми сами по себе си. Ако настройката за влияние на отложените проверки върху статуса е изключена, тези състояния не трябва да отварят нормален инцидент и не трябва да променят последния реален статус на проверката.

29.4. Shopify crawler подписи в Диагностика

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

Потребители с роля Manager могат да виждат статуса на подписите, но не редактират Shopify crawler подпис от Диагностика. Редакцията е част от управлението на сайта и се показва само на роли, които имат право да редактират сайта.

29.5. Какво не показва този раздел

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

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

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

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

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

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

1. Създайте или редактирайте проверка с ясно име.
2. Оставете Отваряй инцидент при активни проблеми с качеството изключено, ако още тествате.
3. Пуснете ръчно изпълнение и отворете резултата в История.
4. Ако тествате Sitemap браузърен DOM — първо разгледайте Сравнение сървър/браузър.
5. Ако сигналът е полезен, включете отварянето на инцидент за качество и задайте праг за инцидент.
6. Ако има очаквано изключение, заглушете само конкретния проблем.

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

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

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

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