D-587P1 · krytyczne
Wtyczki SEO
Ustalamy, która wtyczka SEO zarządza Twoją stroną i czy jej funkcji nie dubluje inny dodatek. Dwie wtyczki generujące meta tagi, mapy witryny lub schema to częsta przyczyna sprzecznych sygnałów dla Google.
Jak to robimy
- Identyfikujemy wszystkie dodatki, które ingerują w meta tagi, canonical, robots i breadcrumbs.
- Porównujemy kod strony z ustawieniami wtyczki, szukając zdublowanych znaczników w sekcji head.
- Sprawdzamy, czy mapa witryny powstaje w jednym miejscu i zawiera tylko indeksowalne adresy.
- Wskazujemy, która wtyczka ma zostać, i przygotowujemy plan wyłączenia zdublowanych funkcji.
Co otrzymujesz
Dostajesz ocenę wtyczki SEO z listą konfliktów i planem ich usunięcia. Po zmianach jeden dodatek odpowiada za metadane, mapę witryny i dane strukturalne.
Kiedy i w jakiej formie: Miesięcznie
D-588P2 · ważne
Wtyczki schema
Weryfikujemy wtyczki odpowiedzialne za dane strukturalne i ich współpracę z motywem. Częsty problem to ten sam typ schema generowany dwa razy: przez motyw i przez osobny dodatek.
Jak to robimy
- Wyciągamy z kodu wszystkie bloki JSON-LD i mikrodane na typowych szablonach stron.
- Ustalamy źródło każdego bloku: motyw, wtyczka SEO, wtyczka schema albo kod dodany ręcznie.
- Porównujemy znaczniki z przyjętą strategią danych strukturalnych dla serwisu.
- Wyłączamy zdublowane źródła i sprawdzamy poprawność pozostałych znaczników w testach Google.
Co otrzymujesz
Każdy typ danych strukturalnych pochodzi z jednego źródła i jest zgodny ze strategią. Otrzymujesz mapę, która pokazuje dla każdego szablonu typ schema i jego źródło.
Kiedy i w jakiej formie: Kwartalnie
D-589P1 · krytyczne
Wtyczki cache i wydajności
Przeglądamy konfigurację wtyczek cache i optymalizacji, bo od nich w dużej mierze zależy szybkość WordPressa. Źle ustawiona minifikacja lub leniwe ładowanie potrafią zepsuć wygląd strony albo opóźnić główny obraz.
Jak to robimy
- Sprawdzamy, czy działa jedna wtyczka cache i czy nie koliduje z cache serwera lub CDN.
- Weryfikujemy minifikację i łączenie plików CSS oraz JS pod kątem błędów w konsoli.
- Kontrolujemy lazy loading, żeby nie opóźniał obrazu odpowiedzialnego za LCP.
- Mierzymy Core Web Vitals przed zmianami i po nich na tych samych adresach.
Co otrzymujesz
Dostajesz opis ustawień cache z listą poprawek i pomiarem przed zmianami i po nich. Punktem odniesienia są progi Core Web Vitals: LCP 2,5 s, INP 200 ms, CLS 0,1.
Kiedy i w jakiej formie: Miesięcznie
D-590P2 · ważne
Wtyczki obrazów
Testujemy wtyczkę, która kompresuje i konwertuje obrazy w Twoim WordPressie. Ma ona zmniejszać wagę plików bez widocznej utraty jakości i bez uszkadzania grafik.
Jak to robimy
- Weryfikujemy, czy wtyczka tworzy wersje WebP lub AVIF i czy przeglądarki je otrzymują.
- Porównujemy jakość skompresowanych obrazów z oryginałami na wybranych podstronach.
- Sprawdzamy, czy generowane rozmiary miniatur odpowiadają temu, co faktycznie wyświetla motyw.
- Kontrolujemy lazy-load i atrybuty wymiarów, które zapobiegają przesunięciom układu strony.
- Szukamy obrazów uszkodzonych po konwersji, na przykład z utraconą przezroczystością lub złymi kolorami.
Co otrzymujesz
Obrazy ładują się w lżejszych formatach, a zbędne miniatury nie zajmują miejsca na serwerze. Dostajesz listę poprawek w ustawieniach wtyczki.
Kiedy i w jakiej formie: Miesięcznie
D-591P1 · krytyczne
Wtyczki bezpieczeństwa
Oceniamy wtyczkę bezpieczeństwa zainstalowaną w Twoim WordPressie i to, jak została skonfigurowana. Sama instalacja nie chroni strony, jeśli firewall, skaner czy limit logowania pozostają wyłączone.
Jak to robimy
- Sprawdzamy, czy firewall aplikacji działa i czy jego reguły są aktualne.
- Weryfikujemy harmonogram skanowania w poszukiwaniu złośliwego kodu i ostatnie wyniki skanów.
- Kontrolujemy limit logowania, wymuszenie 2FA i ustawienia dostępu przez XML-RPC.
- Przeglądamy logi bezpieczeństwa i upewniamy się, że alerty trafiają do właściwej osoby.
- Sprawdzamy, czy wtyczka nie blokuje robotów wyszukiwarek ani nie spowalnia strony.
Co otrzymujesz
Otrzymujesz ocenę konfiguracji wtyczki bezpieczeństwa z listą ustawień do włączenia lub zmiany. Alerty o zagrożeniach trafiają do osoby, która może na nie zareagować.
Kiedy i w jakiej formie: Tygodniowo/miesięcznie
D-592P1 · krytyczne
Wtyczki backup/staging
Kontrolujemy wtyczki odpowiedzialne za kopie zapasowe i środowisko testowe. Kopia musi dać się przywrócić, a staging nie może trafić do indeksu jako duplikat Twojej strony.
Jak to robimy
- Sprawdzamy harmonogram kopii i datę ostatniej udanej kopii w ustawieniach wtyczki.
- Wykonujemy test przywracania wybranej kopii na osobnym środowisku.
- Weryfikujemy, czy staging jest chroniony hasłem i ma blokadę indeksacji.
- Szukamy w Google Search Console i w wynikach wyszukiwania zaindeksowanych adresów stagingu.
- Jeśli kopia stagingu trafiła do indeksu, zgłaszamy jej usunięcie i zamykamy dostęp.
Co otrzymujesz
Wiesz, że kopie działają, a środowisko testowe jest ukryte przed wyszukiwarkami. W raporcie podajemy datę ostatniej kopii i wynik testu przywracania.
Kiedy i w jakiej formie: Miesięcznie
D-593P2 · ważne
Wtyczki UX i integracji
Przeglądamy wtyczki formularzy, zgód na cookies, dostępności, czatu, CRM i automatyzacji marketingu. Każda z nich dokłada skrypty do strony i często przetwarza dane osobowe. Dlatego sprawdzamy jej wpływ na szybkość i zgodność z wyrażonymi zgodami.
Jak to robimy
- Mierzymy, ile czasu ładowania dokładają skrypty czatu, CRM i narzędzi marketing automation.
- Sprawdzamy, czy skrypty śledzące czekają na zgodę użytkownika zgodnie z Consent Mode v2.
- Testujemy formularze: wysyłkę, potwierdzenia i przekazywanie danych do CRM.
- Weryfikujemy wtyczkę dostępności, żeby nie wprowadzała błędów w kodzie ani nie maskowała problemów.
Co otrzymujesz
Dostajesz listę integracji z oceną wpływu na szybkość i poprawności obsługi zgód. Zbędne lub zdublowane skrypty wskazujemy do usunięcia.
Kiedy i w jakiej formie: Kwartalnie
D-594P1 · krytyczne
Release & QA
Ustalamy zasady, według których każde wdrożenie trafia na produkcję. Checklista przed publikacją i po niej wyłapuje błędy SEO, zanim zobaczą je roboty i klienci.
Jak to robimy
- Przygotowujemy checklistę pre i post deploy z testami indeksacji, canonical i przekierowań.
- Dodajemy automatyczny test danych strukturalnych dla zmienianych szablonów.
- Włączamy audyt Lighthouse do procesu CI/CD, czyli automatycznego budowania i publikacji kodu.
- Wymagamy wpisu w dzienniku zmian i opisanego planu wycofania dla każdego wdrożenia.
Co otrzymujesz
Twój zespół dostaje spisany proces wdrożeń z checklistą i testami automatycznymi. Każda zmiana zostawia ślad w dzienniku i ma przygotowaną drogę szybkiego cofnięcia.
Kiedy i w jakiej formie: Każdy release
D-595P2 · ważne
Edge SEO / CDN
Weryfikujemy reguły SEO ustawione na brzegu sieci, czyli w CDN, zanim żądanie dotrze do serwera. Na tym poziomie działają przekierowania, przepisywanie adresów, canonicale i testy A/B, których nie widać w CMS.
Jak to robimy
- Spisujemy reguły redirect i rewrite skonfigurowane w CDN i porównujemy je z rejestrem przekierowań.
- Sprawdzamy canonicale dodawane na brzegu, żeby nie kolidowały z tymi z CMS.
- Weryfikujemy kody 410 dla usuniętych adresów i 451 dla treści wycofanych z powodów prawnych.
- Kontrolujemy ustawienia edge cache oraz testy A/B, żeby roboty dostawały spójną wersję strony.
Co otrzymujesz
Masz pełny obraz reguł działających poza CMS i listę konfliktów do usunięcia. Zmiany na brzegu sieci są opisane w tej samej dokumentacji co reszta serwisu.
Kiedy i w jakiej formie: Kwartalnie
D-596P2 · ważne
RSS/Atom i feedy
Sprawdzamy kanały RSS i Atom Twojego bloga, jeśli służą do dystrybucji treści, monitoringu lub automatyzacji. Kanał z błędami przestaje zasilać czytniki, newslettery i integracje, które na nim polegają.
Jak to robimy
- Walidujemy składnię kanału XML i poprawność kodowania polskich znaków.
- Sprawdzamy, czy kanał zawiera pełne adresy, daty publikacji i autorów wpisów.
- Ustalamy, czy w kanale ma być pełna treść wpisu, czy tylko zajawka z linkiem.
- Upewniamy się, że kanały dla tagów i komentarzy nie tworzą zbędnych adresów w indeksie.
Co otrzymujesz
Blog ma poprawny kanał RSS lub Atom gotowy do wykorzystania w newsletterze i automatyzacjach. Zbędne kanały są wyłączone lub oznaczone noindex.
Kiedy i w jakiej formie: Kwartalnie
D-597P1 · krytyczne
Incident response SEO
Przygotowujemy runbook, czyli instrukcję postępowania na wypadek awarii SEO. Opisuje ona, co robić, gdy nagle pojawia się noindex, blokada w robots.txt albo masowe błędy 5xx.
Jak to robimy
- Spisujemy typowe incydenty: globalny canonical, mapę witryny zwracającą 404, deindeksację i nagłą utratę ruchu.
- Dla każdego incydentu opisujemy objawy, sposób potwierdzenia i pierwsze kroki naprawcze.
- Ustawiamy alerty, które sygnalizują spadek indeksacji lub gwałtowny wzrost błędów.
- Ustalamy, kto po Twojej stronie i po naszej reaguje na każdy typ awarii.
Co otrzymujesz
Dostajesz runbook z opisem incydentów, alertami i listą osób odpowiedzialnych. W razie awarii zespół działa według planu, co skraca czas utraty ruchu.
Kiedy i w jakiej formie: Kwartalnie + przy incydencie
