Jak wdrażamy audyt SEO od agencji w sklepie WooCommerce

Wdrożenie audytu SEO w sklepie WooCommerce zaczynamy od sprawdzenia każdej pozycji na żywej stronie, bo część zgłoszeń opisuje stan sprzed ostatnich zmian albo liczy rzeczy, których przeglądarka w ogóle nie pobiera. Dopiero potem szukamy przyczyny i wdrażamy poprawkę w kodzie, na serwerze albo w bazie. Poniżej pokazujemy ten proces na sklepie KwiatyDonice, dla którego agencja SEO przygotowywała kolejne audyty z Screaming Froga, a my je wdrażaliśmy. Pięć przykładów: obrazy powyżej 100 kB, nofollow kontra przycisk, srcset w galerii, linki przez przekierowania i import meta z pliku CSV.

Kto wdraża audyt SEO przygotowany przez agencję?

Agencja SEO zna strategię, frazy i klienta, ale rzadko ma dostęp do kodu motywu, konfiguracji nginx czy bazy danych, a właśnie tam leży większość poprawek technicznych z typowego audytu. Audyt trafia więc do programisty, który zna sklep, albo do zewnętrznego zespołu takiego jak nasz.

Podział, który u nas działa: agencja odpowiada za audyt, priorytety i raport dla klienta, my za wdrożenie. Przy każdej pozycji odsyłamy jedno z trzech: wdrożone i zmierzone, nieaktualne (z dowodem), świadomie pominięte (z powodem). Agencja dostaje odpowiedź, której nie musi zgadywać z kolejnego crawla.

Masz audyt SEO do wdrożenia? Sprawdzimy każdą pozycję na żywym sklepie, wdrożymy poprawki w kodzie, na serwerze i w CMS, a agencji oddamy raport, co zrobiliśmy i co było nieaktualne. Wdrożenie audytu SEO →

Od czego zacząć wdrażanie audytu SEO w WooCommerce?

Od porównania dwóch dat: kiedy powstał crawl i kiedy weszło ostatnie wdrożenie. W KwiatyDonice trzy audyty z rzędu opisywały stan sprzed wdrożenia, choć pliki z crawla powstawały kilka godzin po wejściu poprawek, bo crawler dostawał stronę z cache, a nie świeżą odpowiedź serwera. Sprawdzenie dat na początku oszczędziłoby nam trzech pełnych analiz.

Drugi krok to pomiar na żywo, z pominięciem cache. W tym sklepie stronę trzymały aż trzy warstwy:

• WP Rocket, czyli pliki HTML generowane przez wtyczkę;
• fastcgi cache w nginx, który ignorował nagłówki Cache-Control z PHP i trzymał odpowiedź przez 60 minut;
• Cloudflare, który cache'ował także HTML i przekierowania 301.

Przy odczycie przez Cloudflare patrzymy na cf-cache-status i age. HIT z dużym age znaczy, że czytasz kopię sprzed wdrożenia. Raz pokazało nam to wszystkie warianty produktu bez pola size, choć serwer generował je poprawnie.

Trzecia pułapka: dopasowanie po fragmencie adresu. Szukając w sitemapie produktu zwracającego 410, dostaliśmy trafienia, bo ten sam ciąg występował w kilkunastu innych, zdrowych adresach. Porównanie pełnych permalinków pokazało zero kolizji.

Dlaczego audyt pokazuje 15 892 obrazy powyżej 100 kB?

Bo Screaming Frog znalazł pliki. Nie sprawdzał, co pobiera przeglądarka. Rozbiliśmy listę z raportu na kategorie, zanim ktokolwiek zaczął zmieniać ustawienia kompresji:

Z 8 836 „brakujących” plików 7 590 to ten sam obrazek po konwersji formatu przez Imagify, np. z AVIF na WebP. Crawl był starszy niż stan sklepu. Zalecenie, żeby obniżyć jakość AVIF, też nie miało pokrycia: miniatura 600×600 na liście kategorii ważyła 54 kB, a cała strona kategorii 745 kB przy 54 obrazkach.

Prawdziwy problem siedział w miejscu, którego raport nie nazwał. W galerii produktu przeglądarka pobierała oryginał zamiast miniatury.

Czy zmiana sizes wystarczy, gdy galeria pobiera za duże zdjęcia?

Nie, co dobrze widać w pomiarach. Kontener galerii miał 759 px szerokości, więc ekran o gęstości pikseli 2 potrzebował obrazka około 1520 px, a takiego kandydata w srcset nie było i przeglądarka brała największy dostępny plik, czyli oryginał uploadu.

Pierwszy testowany wariant zmieniał tylko atrybut sizes z 600 na 760 px. Transfer karty produktu: 824 kB przed zmianą, 825 kB po. sizes nie decyduje o niczym, gdy w srcset brakuje kandydata co najmniej tak dużego jak sizes razy gęstość pikseli. Przeglądarka i tak bierze wtedy największy plik.

Zadziałało ograniczenie max_srcset_image_width do 1024 px. Oryginał wypadł z listy kandydatów, galeria pobiera rozmiar 1024×1024: średnio 129 kB zamiast 171 kB na zdjęcie. Na próbce 311 zdjęć z 60 losowych produktów transfer spadł z 51,2 MB do 37,1 MB, czyli o 28%. Zoom dalej pokazuje pełny oryginał, bo nie korzysta z srcset.

Pomiar odsłonił kolejną rzecz: w 21% przypadków miniatura 1024 była cięższa od oryginału, bo oryginał miał już AVIF, a miniatura została JPEG-iem. Dogenerowaliśmy AVIF dla 6642 miniatur, z kopią metadanych i skryptem do cofnięcia. Transfer tych miniatur spadł o 22%.

Czy rel="nofollow" usuwa linki do adresów zablokowanych w robots.txt?

Nie usuwa. Audyt zgłosił 26 629 linków wewnętrznych do adresów blokowanych w robots.txt i zalecił dopisanie rel="nofollow", tymczasem większość tych linków już ten atrybut miała. Screaming Frog raportuje każde <a href>, niezależnie od rel.

Raport mylił się też co do źródła. Parametr ?orderby=popularity nie pochodził z sortowania w treści kategorii, tylko z linku „Bestsellery” w megamenu: 17 634 linki, 66% całego wolumenu. Ten link, przycisk konta w nagłówku i link do konta w stopce zamieniliśmy na przyciski, które przenoszą użytkownika skryptem, bez href.

Kolejny raport zgłosił 25 792 takie linki z adnotacją „bez zmian”. Trzy z czterech pozycji były już naprawione. Został jeden prawdziwy link w stopce, wpisany w polu ACF. Znaleźliśmy za to coś, czego raport nie wykrył: przycisk „Do koszyka” miał martwy href z ?add-to-cart=, adresem blokowanym w robots.txt. Usunęliśmy go po teście, że dodawanie do koszyka i zdarzenie add_to_cart w dataLayer działają bez zmian. Na stronie głównej, kategorii i karcie produktu nie ma dziś żadnego <a href> do adresów blokowanych.

Jak naprawić linki wewnętrzne prowadzące przez przekierowania 301?

Najpierw trzeba wiedzieć, gdzie powstają przekierowania. W tym sklepie były trzy warstwy: kilka tysięcy reguł w nginx, reguły Rank Math i kod motywu, który zwraca 410 dla produktów wycofanych ze sprzedaży. Do tego Cloudflare przekierowywał adresy z www.

Co wdrożyliśmy:

• 721 reguł nginx wskazywało na adres, który sam przekierowywał. Przepięliśmy je na adres końcowy.
• 639 reguł łapało tylko adres ze slashem na końcu. Po zmianie obsługują też adres bez niego, zamiast oddawać go Rank Mathowi.
• Linki w treści 54 wpisów i w opisie kategorii wskazują teraz finalne adresy.
• Przekierowanie z www na domenę główną odbywa się w jednym kroku.

Weryfikacja: pobraliśmy 210 stron źródłowych z eksportu Screaming Froga i nie znaleźliśmy na nich żadnego starego linku. Przy innym zgłoszeniu, 151 linków do 15 adresów, okazało się, że 88 linków prowadzi już do stron zwracających 200. Zalecany UPDATE ... REPLACE w treści wpisów nie miał czego podmienić, bo linki generowały bloki produktów, a nie treść.

Co może pójść źle przy imporcie meta title i description z CSV?

Sam plik. Agencja przysłała 2265 wierszy z nowymi tytułami i opisami dla produktów, kategorii, wpisów na blogu i strony głównej, więc zanim cokolwiek wgraliśmy, skrypt dopasował każdy wiersz do konkretnej strony w bazie. Wyszły dwa błędy:

• 18 wierszy miało przesunięte kolumny, bo brakowało komórki z nowym tytułem. Tytuły z tych wierszy przepadły, opis udało się odzyskać. Dla tych kategorii zmieniliśmy tylko description, a brakujące tytuły zgłosiliśmy agencji.
• 17 adresów bloga miało przecinki w slugu, których nie było w WordPressie. Skrypt dopasował je po znormalizowanym slugu.

Import ma cztery tryby: sprawdzenie, kopia starych wartości, zapis i cofnięcie. Najpierw cały cykl przeszedł na lokalnej kopii sklepu, łącznie z cofnięciem zmian, a dopiero potem na produkcji. Wgraliśmy 2247 tytułów i 2265 opisów, a rollback przywraca stan 1:1.

Jak sprawdzić, że audyt został wdrożony?

Lista, którą przechodzimy przy każdej pozycji:

1. Wyczyść cache po wdrożeniu, nie przed nim, inaczej Cloudflare zdąży zapisać starą wersję.
2. Sprawdź stronę prosto z serwera i przez CDN, porównaj wyniki.
3. Dopasowuj pełne adresy, nie fragmenty.
4. Mierz na kilku typach stron: strona główna, kategoria, karta produktu, wpis.
5. Opisz agencji, co zrobione, co nieaktualne, co pominięte, i poproś o ponowny crawl.

Po wdrożeniu altów i wymiarów obrazków zmierzyliśmy na żywo: strona główna 85 obrazków, kategoria 54, karta produktu 70, zero braków. Na tę pozycję audyt zgłaszał 2278 obrazów bez alt i 304 bez wymiarów. Jeśli kolejny crawl pokaże podobne liczby, pierwsze pytanie brzmi: czy czytał cache?

O wzroście ruchu nie piszemy, bo nie mamy dla tego sklepu porównania danych z Search Console sprzed i po wdrożeniu. Wdrożony audyt usuwa błędy techniczne, a efekt w ruchu trzeba zmierzyć osobno i w dłuższym okresie.