Jeżeli baner cookies nie wyświetla się na WordPressie, najpierw otwórz stronę w nowym oknie incognito jako niezalogowany użytkownik. Jeśli nadal go nie ma, sprawdź kolejno: status wtyczki i połączenia domeny, obecność kodu CMP w źródle strony, żądanie do skryptu w Network, błędy w Console oraz to, czy element banera nie został ukryty przez CSS. Dopiero później wyłączaj optymalizację lub inne wtyczki.
Brak widocznego banera nie oznacza automatycznie, że skrypty analityczne i marketingowe są zablokowane. GA4, Meta Pixel albo inny tracker może nadal działać. Dlatego diagnostyka powinna objąć zarówno interfejs banera, jak i rzeczywiste żądania wysyłane przed wyborem użytkownika.
Najczęstsze przyczyny niewidocznego banera cookies
| Przyczyna | Typowy objaw | Pierwszy test |
|---|---|---|
| zapisana wcześniejsza decyzja | baner nie pojawia się tylko w używanej przeglądarce | nowe okno incognito lub usunięcie danych witryny |
| test jako administrator | baner nie pojawia się po zalogowaniu do WordPressa | wylogowanie i test anonimowy |
| baner jest wyłączony lub konfiguracja nie została aktywowana | brak banera we wszystkich przeglądarkach | ustawienia CMP i status witryny |
| domena nie jest połączona | wtyczka działa, ale SDK nie pobiera konfiguracji | status integracji, domena, klucz API i identyfikator |
| kod CMP nie został dodany do HTML | brak skryptu w źródle strony | wyszukiwanie domeny CDN lub nazwy CMP w źródle |
| cache pokazuje starą wersję | różni użytkownicy widzą różny rezultat | czyszczenie cache WordPressa, serwera i CDN |
| skrypt został opóźniony lub zmieniony | baner pojawia się późno albo wcale | czasowe wyłączenie delay, defer, łączenia i minifikacji JS |
| błąd JavaScript | skrypt jest pobrany, ale interfejs nie powstaje | Console i pierwszy czerwony błąd |
| CSP, firewall lub rozszerzenie blokuje SDK | żądanie ma status blocked, 403 albo nie jest wysyłane | Network, inna przeglądarka i inna sieć |
| konflikt dwóch CMP | brak banera, dwa panele lub sprzeczne stany zgody | lista wtyczek, GTM i kod motywu |
| CSS ukrywa baner | element istnieje w DOM, lecz nie jest widoczny | Inspect, display, visibility, opacity i z-index |
| motyw nie wywołuje hooka WordPressa | skrypty wielu wtyczek nie pojawiają się prawidłowo | kontrola wp_head() i wp_footer() |
| reguły regionalne lub wykluczenia adresów | baner działa tylko w części lokalizacji lub podstron | ustawienia regionów i reguły URL |
Krok 1. Sprawdź, czy baner powinien pojawić się w tej sesji
CMP zazwyczaj zapamiętuje wcześniejszą decyzję. Jeżeli użytkownik zaakceptował, odrzucił albo zapisał własne ustawienia, baner nie musi ponownie zasłaniać strony przy każdym wejściu.
Wykonaj test od początku:
- otwórz nowe okno prywatne lub incognito;
- upewnij się, że nie jesteś zalogowany do WordPressa;
- wyłącz na chwilę rozszerzenia blokujące reklamy i skrypty;
- wpisz adres strony ręcznie;
- sprawdź stronę główną oraz zwykłą podstronę;
- powtórz test na drugim urządzeniu lub w innej przeglądarce.
Jeśli baner pojawia się w incognito, podstawowy mechanizm prawdopodobnie działa, a zwykła przeglądarka ma zapisaną decyzję lub lokalną blokadę. Nie usuwaj od razu wszystkich cookies. Najpierw otwórz DevTools, przejdź do Application i sprawdź dane konkretnej domeny. Pozwoli to potwierdzić przyczynę zamiast tylko czasowo ukryć objaw.
Sprawdź również, czy produkt nie ma świadomego wyjątku dla administratorów, edytora strony, Customizera albo podglądu kreatora. Wynik w Elementorze, Divi lub innym trybie edycji nie jest miarodajnym testem frontendu.
Krok 2. Zweryfikuj status wtyczki, konta i domeny
Sama aktywacja wtyczki nie zawsze uruchamia baner. Rozwiązania chmurowe wymagają połączenia konkretnej domeny z konfiguracją w panelu CMP.
W przypadku CookieStart sprawdź:
- czy wtyczka jest aktywna;
- czy WordPress jest połączony z kontem CookieStart;
- czy wybrano właściwą witrynę i domenę;
- czy status integracji nie pokazuje błędu;
- czy automatyczne wyświetlanie banera jest włączone;
- czy konfiguracja banera została zapisana;
- czy klucz API i identyfikator domeny odpowiadają bieżącej witrynie;
- czy środowisko produkcyjne nie używa danych domeny testowej.
Oficjalna karta CookieStart w WordPress.org wskazuje, że na świeżej instalacji frontendowe SDK nie jest ładowane, dopóki administrator nie połączy domeny i nie skonfiguruje danych CookieStart. Wtyczka udostępnia również status integracji, zarządzanie cache konfiguracji, tryb debugowania i logi.
Porównaj pełny adres, nie tylko główną nazwę domeny. Znaczenie mogą mieć:
www.example.pliexample.pl;httpihttps;- subdomena
sklep.example.pl; - domena tymczasowa hostingu;
- staging i produkcja;
- wersja językowa działająca w osobnej domenie.
Po poprawieniu połączenia wyczyść cache konfiguracji w sposób przewidziany przez używany CMP i rozpocznij nową sesję testową.
Krok 3. Sprawdź, czy kod CMP znajduje się w HTML
Otwórz źródło strony, a nie tylko panel Elements. W Chrome możesz użyć skrótu Ctrl+U, a następnie wyszukać nazwę CMP lub domenę jego CDN.
Dla CookieStart szukaj odwołania do cdn.cookiestart.pl. Zgodnie z dokumentacją wtyczki z tej domeny pobierane jest frontendowe SDK odpowiedzialne za konfigurację i działanie banera.
Skryptu nie ma w źródle
Problem występuje przed uruchomieniem kodu w przeglądarce. Sprawdź:
- aktywację i połączenie wtyczki;
- ustawienie automatycznego wyświetlania;
- warunki wykluczające daną podstronę;
- cache wygenerowany przed włączeniem CMP;
- niestandardowy motyw;
- kod, który usuwa skrypty wtyczek;
- czy oglądasz właściwą domenę i instalację WordPressa.
Skrypt jest w źródle
WordPress dodał kod, ale nie wiadomo jeszcze, czy przeglądarka go pobrała i wykonała. Przejdź do zakładek Network oraz Console.
To rozróżnienie pozwala uniknąć przypadkowych zmian. Wyłączanie minifikacji nie naprawi skryptu, którego WordPress w ogóle nie umieścił w HTML.
Krok 4. Sprawdź żądania w Network
Otwórz DevTools przed odświeżeniem strony, przejdź do Network, włącz zachowanie logu i przeładuj stronę. Panel zapisuje tylko aktywność, która nastąpiła po jego otwarciu. Instrukcję obsługi panelu zawiera dokumentacja Chrome DevTools.
Filtruj po nazwie CMP, cookie, consent lub domenie CDN. Sprawdź:
- czy żądanie do SDK zostało wysłane;
- kod odpowiedzi HTTP;
- adres końcowy po przekierowaniach;
- kolumnę Initiator wskazującą źródło żądania;
- czas rozpoczęcia względem GTM i innych tagów;
- zakładkę Response, jeśli odpowiedź jest dostępna;
- komunikat błędu, gdy przeglądarka oznacza zasób jako zablokowany.
| Wynik w Network | Znaczenie | Następny krok |
|---|---|---|
| brak żądania mimo kodu w HTML | skrypt został usunięty, opóźniony lub zablokowany przed wysłaniem | optymalizacja JS, rozszerzenia i warunki ładowania |
| 200 | plik został pobrany | Console, inicjalizacja i DOM |
| 301 lub 302 | wystąpiło przekierowanie | sprawdź docelowy adres i protokół |
| 401 lub 403 | odmowa dostępu lub błędna autoryzacja | domena, klucz, firewall i konfiguracja usługi |
| 404 | błędny albo nieaktualny adres zasobu | wersja wtyczki, cache i zapisane ustawienia |
| 5xx | błąd serwera lub usługi | zapisz czas, adres i odpowiedź; ponów test przed eskalacją |
| blocked by client | rozszerzenie lub ochrona przeglądarki | test bez rozszerzeń oraz w drugiej przeglądarce |
| blocked by CSP | polityka bezpieczeństwa nie zezwala na zasób | nagłówek CSP i wymagana lista dozwolonych źródeł |
| błąd certyfikatu lub mixed content | konflikt HTTPS albo certyfikatu | popraw protokół i certyfikat, nie omijaj ostrzeżenia |
Jeśli błąd 5xx jest przejściowy, powtórz test i zapisz godzinę. Jeżeli występuje stale na kilku sieciach i urządzeniach, przekaż dokładny adres żądania oraz wynik wsparciu technicznemu.
Krok 5. Odczytaj pierwszy błąd w Console
W Console szukaj pierwszego błędu powstałego po odświeżeniu strony. Kolejne komunikaty mogą być tylko skutkiem pierwotnej awarii.
Najczęstsze grupy błędów:
ReferenceError– kod odwołuje się do obiektu, który nie został utworzony;TypeError– inicjalizacja otrzymała niewłaściwe dane albo wykonała się w złej kolejności;- CSP – przeglądarka odrzuciła skrypt, styl, połączenie lub kod inline;
- CORS – odpowiedź z innej domeny nie spełnia reguł dostępu;
- mixed content – strona HTTPS próbuje pobrać niezabezpieczony zasób;
- błędy połączenia – konfiguracja lub API nie odpowiada;
- błędy innej wtyczki – wcześniejszy wyjątek przerwał wykonywanie kolejnych skryptów.
Content Security Policy może ograniczać źródła skryptów, stylów, ramek i połączeń. Nie wyłączaj całej CSP jako stałego rozwiązania. Ustal, która dyrektywa blokuje wymagany zasób, i dodaj tylko niezbędne źródło zgodnie z dokumentacją CMP. Opis działania dyrektyw zawiera dokumentacja CSP w MDN.
Do zgłoszenia zapisz pełny komunikat, plik, numer linii, adres strony, godzinę testu oraz zrzut zakładek Console i Network.
Krok 6. Wyczyść cache i sprawdź optymalizację JavaScriptu
Po zmianie ustawień banera usuń wszystkie warstwy starej wersji strony:
- page cache w WordPressie;
- object cache, jeśli jest używany;
- cache serwera lub hostingu;
- cache CDN;
- cache przeglądarki albo rozpocznij nową sesję incognito.
Następnie, najlepiej na stagingu, czasowo wyłącz pojedynczo:
- opóźnianie JavaScriptu do pierwszej interakcji;
deferiasyncdodawane automatycznie;- łączenie plików JavaScript;
- minifikację JavaScriptu;
- przenoszenie skryptów z
headdo stopki; - automatyczne usuwanie niewykorzystanego CSS;
- optymalizację kodu inline.
Po każdej zmianie wyczyść właściwy cache i wykonaj ten sam test. Jeśli baner wróci, nie pozostawiaj całej optymalizacji wyłączonej bez potrzeby. Dodaj precyzyjny wyjątek dla plików i kodu inicjalizacyjnego CMP zgodnie z dokumentacją używanych narzędzi.
Kolejność jest ważna. CMP może potrzebować ustawić stan zgody przed GTM i tagami pomiarowymi. Przesunięcie jego inicjalizacji do momentu pierwszego kliknięcia może sprawić, że baner pojawi się za późno albo mechanizm zgód zacznie działać dopiero po uruchomieniu trackerów.
Krok 7. Sprawdź hooki w motywie WordPress
Niestandardowy motyw może nie wywoływać standardowych funkcji WordPressa. Wtedy wtyczka jest aktywna, ale nie ma miejsca, w którym może dodać swój kod.
Sprawdź, czy szablon zawiera:
wp_head()przed zamknięciem</head>;wp_footer()przed zamknięciem</body>.
Dokumentacja WordPressa pokazuje, że te funkcje uruchamiają odpowiednio akcje wp_head i wp_footer, używane przez rdzeń i wtyczki do dodawania zasobów.
Brak hooka zwykle wpływa nie tylko na baner. Mogą nie działać również style, analityka, formularze lub inne elementy. Poprawiaj motyw potomny albo własny motyw, a nie pliki rdzenia WordPressa.
Jeżeli podejrzewasz motyw, przełącz go wyłącznie na stagingu na aktualny motyw domyślny WordPressa. Jeśli baner się pojawi, porównaj szablony nagłówka i stopki oraz filtry usuwające skrypty.
Krok 8. Wyklucz konflikt wtyczek bez ryzyka dla strony
Nie zaczynaj od wyłączenia wszystkich wtyczek na stronie produkcyjnej. Może to zatrzymać formularze, sprzedaż, logowanie albo płatności.
Bezpieczniejsza procedura:
- utwórz aktualny backup;
- odtwórz problem na stagingu;
- najpierw wyłącz inne wtyczki cookies i pozostałe kody CMP;
- sprawdź wtyczki cache, bezpieczeństwa i wstawiania kodu;
- wyłączaj pozostałe dodatki grupami;
- po wykryciu grupy włączaj jej elementy pojedynczo;
- za każdym razem czyść cache i używaj nowej sesji;
- zapisz nazwę oraz wersję dodatku odtwarzającego problem.
Szczególnie często kolidują:
- dwa aktywne CMP;
- stara wtyczka pozostawiona po migracji;
- kod banera dodany jednocześnie przez wtyczkę, motyw i GTM;
- wtyczka cache modyfikująca kolejność;
- wtyczka bezpieczeństwa blokująca kod inline lub zewnętrzny CDN;
- builder zmieniający strukturę szablonu;
- narzędzie do zarządzania nagłówkiem i stopką;
- kod własny usuwający lub przepinający skrypty.
Jeśli nie masz stagingu, użyj kontrolowanego okna serwisowego i funkcji diagnostycznej, która pozwala wyłączać dodatki tylko dla zalogowanego administratora, o ile jest dostępna i została sprawdzona. Nie testuj zmian wpływających na klientów bez planu wycofania.
Krok 9. Sprawdź, czy baner istnieje, ale ukrywa go CSS
W Elements wyszukaj nazwę CMP, tekst przycisku lub charakterystyczny kontener. Jeśli element jest obecny, lecz niewidoczny, sprawdź style obliczone:
display: none;visibility: hidden;opacity: 0;- pozycję poza ekranem;
transformprzesuwający element;- zbyt niski albo ujemny
z-index; overflow: hiddenna elemencie nadrzędnym;- zerową wysokość lub szerokość;
- reguły tylko dla urządzeń mobilnych lub desktopu.
Nie naprawiaj problemu od razu wartością z-index: 999999999. Najpierw ustal, która reguła motywu lub buildera powoduje konflikt. Zbyt wysoki poziom może zasłonić koszyk, menu, formularz albo panel dostępności.
Jeżeli baner pojawia się bez stylów, sprawdź w Network pliki CSS i odpowiedzi CDN. Problemem może być minifikacja, 404, CSP lub cache starej wersji arkusza.
Krok 10. Sprawdź region, adres strony i środowisko
CMP może świadomie nie wyświetlać banera wszystkim użytkownikom. Zweryfikuj:
- ustawienia geolokalizacji;
- reguły dla Unii Europejskiej i pozostałych regionów;
- wykluczone adresy URL;
- osobne ustawienia strony głównej, sklepu i kasy;
- język banera;
- status domeny produkcyjnej i stagingowej;
- zachowanie na subdomenie;
- parametry zgody przekazywane między domenami.
Jeśli wynik zależy od lokalizacji, wykonaj test z udokumentowanym narzędziem symulującym region i porównaj konfigurację z rzeczywistym adresem IP. Nie zakładaj błędu tylko dlatego, że baner nie pokazuje się poza obszarem objętym daną regułą.
Sprawdź też drugą sieć, na przykład internet mobilny. Firmowy firewall, filtr DNS albo system bezpieczeństwa operatora może blokować domenę CDN tylko w jednej sieci.
Drzewo diagnostyczne banera cookies
| Punkt kontroli | Wynik | Wniosek |
|---|---|---|
| nowa sesja incognito | baner się pojawia | wcześniejsza decyzja lub lokalne dane przeglądarki |
| źródło HTML | brak kodu CMP | ustawienia wtyczki, połączenie, cache, hooki lub warunek wyświetlania |
| źródło HTML | kod CMP istnieje | przejdź do Network |
| Network | brak żądania | optymalizacja, rozszerzenie albo warunek JavaScript |
| Network | żądanie zakończone błędem | domena, CSP, CORS, SSL, firewall lub usługa |
| Network | odpowiedź 200 | przejdź do Console i DOM |
| Console | błąd inicjalizacji | kolejność, konfiguracja albo konflikt kodu |
| DOM | brak kontenera | inicjalizacja nie zakończyła się poprawnie |
| DOM | kontener istnieje | sprawdź CSS, pozycję i z-index |
| druga przeglądarka działa | problem lokalny | rozszerzenie, ochrona śledzenia lub pamięć przeglądarki |
| domyślny motyw działa | konflikt motywu | hooki, CSS lub kod szablonu |
| działa bez optymalizacji | konflikt cache lub modyfikacji JS | skonfiguruj precyzyjny wyjątek |
Co przetestować po przywróceniu banera?
Samo pojawienie się interfejsu nie kończy naprawy. W osobnych czystych sesjach sprawdź:
- stan przed podjęciem decyzji;
- akceptację wszystkich kategorii;
- odrzucenie cookies opcjonalnych;
- wybór wyłącznie analityki;
- zmianę i wycofanie wcześniejszej zgody;
- zapamiętanie decyzji na kolejnej podstronie;
- ponowne otwarcie panelu ustawień;
- cookies, local storage i żądania Network;
- działanie GA4, reklam, formularzy, map i filmów;
- wygląd oraz obsługę klawiaturą na telefonie i komputerze.
Sprawdź także, czy opcjonalne skrypty nie uruchamiały się w czasie, gdy banera nie było. Jeżeli problem trwał dłużej, zapisz okres, przyczynę, zakres stron i wprowadzone działania naprawcze. Zakres dalszych działań organizacyjnych lub prawnych należy ocenić dla konkretnej witryny.
Jakie dane przygotować dla wsparcia technicznego?
Zamiast zgłoszenia „baner nie działa” przygotuj:
- dokładny adres strony;
- datę i godzinę testu;
- przeglądarkę, urządzenie i sieć;
- informację, czy test wykonano w incognito i po wylogowaniu;
- wersję WordPressa, PHP, motywu i wtyczki CMP;
- status integracji i domenę przypisaną w panelu;
- informację, czy kod CMP znajduje się w źródle;
- adres oraz status żądania SDK w Network;
- pierwszy błąd z Console;
- listę aktywnych wtyczek cache, bezpieczeństwa i innych CMP;
- wynik testu po czasowym wyłączeniu optymalizacji na stagingu;
- zrzuty ekranu albo plik HAR po usunięciu informacji, których nie należy udostępniać.
Nie przesyłaj publicznie haseł, prywatnych kluczy API, tokenów ani pełnych danych użytkowników. Jeśli wsparcie potrzebuje identyfikatora domeny lub klucza, użyj bezpiecznego kanału wskazanego przez dostawcę.
Najczęstsze pytania
Dlaczego baner cookies nie wyświetla się tylko mnie?
Najczęściej przeglądarka ma zapisaną wcześniejszą decyzję albo rozszerzenie blokuje skrypt CMP. Porównaj wynik w czystej sesji, drugiej przeglądarce, na telefonie i w innej sieci. Jeśli inni użytkownicy widzą baner, nie zmieniaj od razu konfiguracji całej strony.
Dlaczego baner działa po wyłączeniu cache?
Optymalizacja może opóźniać, przenosić, łączyć lub minifikować kod CMP. Ustal, która funkcja powoduje problem, a następnie dodaj precyzyjny wyjątek dla kodu banera. Pozostawienie całego cache wyłączonego nie jest zwykle potrzebne.
Czy baner powinien być widoczny dla administratora?
To zależy od produktu i konfiguracji. Niektóre mechanizmy wyłączają baner lub blokowanie dla zalogowanych administratorów i w trybach edycji. Odbiór wykonuj zawsze także jako anonimowy użytkownik.
Dlaczego baner jest w HTML, ale go nie widać?
Jeśli skrypt i kontener istnieją, najczęściej zawiodła inicjalizacja albo CSS ukrywa element. Sprawdź Console, style obliczone, pozycję, rozmiar, opacity, visibility, display i z-index.
Czy mogę wyłączyć wszystkie wtyczki, aby znaleźć konflikt?
Taką próbę najlepiej wykonać na stagingu. Na stronie produkcyjnej wyłączenie dodatków może zatrzymać formularze, sklep lub płatności. Zacznij od innych CMP, cache, bezpieczeństwa i narzędzi wstawiających skrypty.
Czy brak banera oznacza, że cookies są zablokowane?
Nie. Interfejs może się nie wyświetlić, podczas gdy GA4, piksel reklamowy albo inne skrypty nadal wysyłają żądania. Zawsze sprawdź Application i Network przed podjęciem decyzji, że problem jest wyłącznie wizualny.
Czy ponowna instalacja wtyczki naprawi problem?
Tylko jeśli przyczyną są uszkodzone pliki. Ponowna instalacja nie naprawi błędnej domeny, cache, CSP, zapisanego wyboru, brakującego hooka motywu ani konfliktu CSS. Najpierw ustal etap, na którym ładowanie się zatrzymuje.
Jeśli chcesz sprawdzić, jakie skrypty i cookies działają na stronie przed podjęciem decyzji, zeskanuj stronę z CookieStart.