Audyt z Screaming Froga ma kilkadziesiąt zakładek i kilka tysięcy wierszy, a w firmie nie ma nikogo, kto zna kod sklepu.
Programista poprawił część rzeczy, a kolejny raport pokazuje te same liczby. Nikt nie wie, czy crawl był przed wdrożeniem, czy po.
Zalecenie brzmi „dodaj nofollow” albo „obniż jakość obrazków”, ale nie wiadomo, czy to w ogóle rozwiąże zgłoszenie.
Część poprawek wymaga zmian w nginx, w cache albo w bazie, a agencja nie ma dostępu do serwera.
Masowa zmiana adresów URL albo meta z pliku CSV bez kopii zapasowej to ryzyko, którego nikt nie chce brać na siebie.
Zadania z audytu wiszą tygodniami, bo każde wymaga osobnej diagnozy, a w zespole nikt nie ma na nie czasu.
Każdą pozycję raportu sprawdzamy na produkcji. Porównujemy datę crawlu z datą ostatniego wdrożenia i czytamy stronę z pominięciem cache, żeby nie poprawiać czegoś, co już działa.
Szukamy miejsca, w którym problem powstaje: szablon, wtyczka, treść w bazie, reguła przekierowania, warstwa cache. Rada z audytu jest punktem wyjścia, nie gotową instrukcją.
Zmiany w kodzie idą przez repozytorium, zmiany w bazie i na serwerze z kopią zapasową i skryptem do cofnięcia. Przed produkcją testujemy lokalnie.
Po wyczyszczeniu cache sprawdzamy wynik w działającym sklepie i oddajemy raport per pozycja: wdrożone, nieaktualne albo świadomie pominięte, z uzasadnieniem. Potem prosimy o ponowny crawl.
W sklepie, w którym wdrażaliśmy kilka kolejnych raportów, trzy audyty z rzędu opisywały stan sprzed wdrożenia. Pliki z crawla powstawały kilka godzin po wejściu poprawek, ale crawler dostawał stronę z cache. Gdybyśmy pracowali tylko na raporcie, poprawialibyśmy coś, co już działało.
Druga rzecz to rady, które brzmią dobrze, ale nie usuwają zgłoszenia. Screaming Frog raportuje każdy link z atrybutem href, więc dopisanie rel="nofollow" niczego w raporcie nie zmienia. Zmienia to dopiero usunięcie samego linku tam, gdzie nie jest potrzebny.
Bywa też odwrotnie: audyt nazywa objaw, a przyczyna leży gdzie indziej. Z listy prawie 16 tysięcy „ciężkich” obrazków tylko 297 było miniaturami, a realny problem, oryginały pobierane w galerii produktu, nie był w raporcie nazwany. Opisaliśmy to krok po kroku w artykule jak wdrażamy audyt SEO w sklepie WooCommerce.
Import tysięcy wierszy do Rank Math albo Yoast z kontrolą pliku, kopią starych wartości i trybem rollback.
Porządkujemy reguły w nginx, w Rank Math i w motywie, przepinamy linki na adresy końcowe, skracamy łańcuchy do jednego skoku.
Usuwamy sprzeczne dyrektywy robots, linki do adresów blokowanych i błędne canonicale, np. przy wielkich literach w adresie.
Schema Product i ProductGroup, warianty, czas dostawy, SKU, które przechodzą walidację. Jeden blok JSON-LD na stronie zamiast dwóch.
Alt z kontekstu produktu i kategorii, width i height, rozmiary w srcset dobrane tak, żeby galeria nie pobierała oryginałów.
Sitemap bez adresów, które nie powinny być indeksowane, i 410 dla produktów, które naprawdę zniknęły z oferty.
Agencja zna strategię i klienta, ale zwykle nie ma dostępu do kodu motywu, konfiguracji nginx ani bazy. My wchodzimy w tę lukę: przyjmujemy raport w formie, w jakiej powstał, i rozliczamy się z każdej pozycji.
Sklep WooCommerce z roślinami i doniczkami, hurt i detal w jednym serwisie. Agencja SEO dostarczała audyty z Screaming Froga, my sprawdzaliśmy je na produkcji i wdrażaliśmy.
| Zgłoszenie | Co ustaliliśmy i wdrożyliśmy |
|---|---|
| Nowe title i description z pliku agencji, 2265 wierszy | 2247 title i 2265 description wgranych z kopią i rollbackiem 1:1; 18 wierszy z przesuniętymi kolumnami zgłoszonych agencji |
| 26 629 linków do adresów blokowanych w robots.txt, zalecenie: nofollow | nofollow nie usuwa wpisu z raportu; linki zamienione na przyciski, zero takich <a href> na stronie głównej, kategorii i karcie produktu |
| 15 892 obrazy powyżej 100 kB | 98% listy to oryginały uploadu, nie obrazki z frontu; realny problem w galerii: 129 kB zamiast 171 kB na zdjęcie |
| Linki wewnętrzne przez przekierowania | 721 reguł wskazujących na adres, który sam przekierowywał, przepiętych na cel; zero starych linków na 210 stronach źródłowych |
| 2278 obrazów bez alt i 304 bez wymiarów | Zero braków w działającym sklepie: strona główna 85 obrazków, kategoria 54, karta produktu 70 |
| 8 problemów w mapie witryny | 6 nieaktualnych (stara kopia w cache); poprawiona strona /sklep/: noindex, follow |
| Struktura URL: podkreślenia, wielkie litery, parametry | 1556 aktualnych adresów bez problemów, masowe zmiany zbędne; naprawione sprzeczne meta robots |
| Linki do produktów zwracających 410 | Przyczyną były ręczne reguły przekierowań, nie moduł z raportu; 410 dostaje 28 produktów wycofanych z obu kanałów sprzedaży |
Cały sklep: case study KwiatyDonice. Dane produktów dla Google i asystentów AI opisujemy w ofercie pozycjonowanie w AI.
Nie obiecujemy wzrostu ruchu ani pozycji. Odpowiadamy za to, żeby audyt był wdrożony poprawnie i sprawdzony po wdrożeniu, a pozycje nieaktualne opisane z dowodem. W KwiatyDonice nie mamy porównania ruchu sprzed i po wdrożeniu, więc nie podajemy takich liczb.
Gdy wąskim gardłem jest szybkość sklepu, a nie meta czy przekierowania, zaczynamy od optymalizacji WooCommerce.

Polecam ! Wszystko perfekcyjnie !
Współpracowałam z Kamilem przy kodowaniu Landing Pages. Mogę polecić go z uwagi na jego otwartość, chęć rozwoju współpracy i wytrzymałość na moją perfekcję pikselową