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

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

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

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

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

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

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

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

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

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

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

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

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

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

• HTTP / Page проверка — следи HTTP статус, време за отговор, очакван/забранен текст и по желание допълнителна проверка на съдържание чрез сървърен HTML или браузърен DOM след JavaScript.
• SEO / Canonical / Robots проверка — проверява SEO сигналите на един конкретен URL.
• Shopify Cart API health — тества backend cart функционалността с избран вариант, без да финализира поръчка и без да замества Browser Lab тест на темата.
• Shopify продуктови правила — проверява избрани или автоматично открити продукти; следи тагове, наличност, изображения, варианти, цени, compare-at цени и SKU ценова консистентност.
• Shopify правила за колекция — може да следи избрани колекции или автоматично открит списък с колекции.
• Browser Lab — контролирано браузърно зареждане от GO4 за конкретен URL/path с избран Desktop или Mobile профил, отделно от JS Agent и от одит диагностиките. Включва Action Journey за потребителски път със стъпки, DOM проверка след скрол и преди/след тестове за безопасно сравнение на промяна в 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 на началната страница, Cart API проверка, 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 заявки към публичната част на Shopify магазина на същия домейн, например Sitemap SEO одит, Browser Lab, директно добавени Shopify сайтове и други проверки, които реално отварят публични storefront URL-и. Не се изпраща към други домейни.

За всеки 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 Cart API health

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

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

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

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

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

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

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

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

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

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

Тип: Shopify Cart API health

Variant ID: 49123456789012

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 може да изпълнява и Action Journey - подредени браузърни стъпки за важен потребителски път.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Типични примери са: отваряне на първи продукт от колекция, избор на вариант, натискане на Add to cart, проверка дали се появява панелът или страницата на количката, проверка на lazy уиджет след скрол или достигане до checkout страницата.

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

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

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

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

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

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

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

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

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

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

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

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

• Проверки → Browser Lab — общ изглед с филтри, последен резултат, сигнали, последно изпълнение и действия.
• Детайли за Browser Lab проверка — текущи проблеми, филтрирана история на Browser Lab изпълненията, заглушаване/отглушаване, управление на историята и бутон към преди/след тестовете за тази проверка.
• Тестове преди/след промяна — отделен работен процес с история на преди/след тестовете, странициране и отделен резултат за всеки тест.
• Детайли за 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 или уиджети.

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

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

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

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

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

7.8. External Radar

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

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

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

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

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

В блока Избор на страници определяте как External Radar да изгради представителния списък от страници.

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

При Автоматично откриване можете да включите един или повече източници:

• Начална страница — включва основната страница на сайта;
• URL-и от съществуващи проверки — добавя важни адреси от други активни проверки за същия сайт. Пренасят се само адресите, не настройките или резултатите на другите проверки;
• Съществуващо покритие от Sitemap одит — използва подходящи адреси, които вече са открити от Sitemap SEO одит;
• Нова sitemap извадка — открива представителни страници директно от sitemap източниците.

Лимитът за URL-и от съществуващи проверки е отделен от общия обхват. Практичен старт е около 10–15, за да остане място и за продуктови, колекционни, блог, целеви и други представителни страници.

Какво става при промяна на режима или лимита

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

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

URL покритие

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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-а или проблема и когато е решен, заглушен или не е част от текущите активни проблеми.

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

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

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

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

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

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/източник. Така може да проверите дали даден външни домейн, скрипт от приложение, видео/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 Cart API health дава неуспех

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

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

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

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

1. Проверете дали JS агентът е включен за сайта.
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. Browser Lab Action Journey дава неуспех

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

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

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

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

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

Примери:

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

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

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

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

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

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

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

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

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

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

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

За Shopify

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

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

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

20. FAQ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Минимално:

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

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

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

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

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

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

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

Създава ли 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, но има конфигурационна бележка?

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

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

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

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

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

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

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

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

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

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

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

Какво е External Radar?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Какво е Browser Lab Action Journey?

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

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

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

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

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

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

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

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

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

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

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

• [ ] Създадена е организация.
• [ ] Добавен е Сайт.
• [ ] Сайтът е Активен.
• [ ] Избран е правилен Платформа: 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 пази минали резултати, инциденти и одитни списъци, за да можете да проследявате как се е развивал даден проблем във времето. Тези данни са полезни при сравнение преди/след промяна, при повторен проблем и при работа с поддръжка.

• История / изпълнения показва какво е отчела всяка проверка във времето. Най-важното е да гледате последния резултат, активните проблеми и контекста към инцидентите.
• Важният контекст се пази по-консервативно: последни резултати, последен OK резултат, проблемни изпълнения, отворени инциденти, активни проблеми и Browser Lab доказателства.
• 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 магазините имат Cart API проверка и Одит на колекции, когато е приложимо.
• [ ] 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 правила за колекция. Той показва избраните или автоматично открити колекции, техния статус, проблеми и напредък.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проверки → Одит на продукти показва общия изглед за Shopify продуктови проверки. Той включва проверки с Конкретни продукти и проверки с Автоматично откриване.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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