Szybkość sklepu mierzymy na kilku typach podstron, a nie tylko na stronie głównej. W PrestaShop najwolniejsze bywają kategorie z dużą liczbą produktów i filtrami oraz karty produktów z wieloma kombinacjami, bo tam sklep wykonuje najwięcej zapytań do bazy. Do tego dochodzi koszyk i proces zamówienia, który na telefonie potrafi działać zauważalnie gorzej niż na komputerze.

Core Web Vitals to trzy wskaźniki, które Google zbiera od prawdziwych użytkowników: czas wyświetlenia największego elementu (LCP), opóźnienie reakcji na kliknięcie (INP) i przesunięcia układu podczas ładowania (CLS). W sklepach na PrestaShop LCP najczęściej psuje ciężki baner lub slider na stronie głównej i duże zdjęcia produktów. INP pogarszają skrypty z modułów, czaty, piksele reklamowe i widżety opinii. CLS pojawia się, gdy obrazy nie mają wymiarów albo gdy moduły doklejają elementy po załadowaniu strony.

W PrestaShop optymalizacja szybkości to zwykle kilka mniejszych zmian zamiast jednej dużej: zdjęcia w odpowiednich rozmiarach i nowocześniejszych formatach, leniwe ładowanie obrazów poniżej pierwszego ekranu, mniej skryptów w nagłówku, lokalne czcionki zamiast ładowanych z zewnątrz. Nie obiecujemy konkretnego wyniku w PageSpeed Insights, bo ten wynik zależy także od motywu, hostingu i zewnętrznych skryptów, których czasem nie da się usunąć. Pokazujemy natomiast pomiary przed i po zmianach oraz dane z raportu Core Web Vitals w Search Console.

Pierwsza rzecz, którą sprawdzamy, to serwer. Sklep na starej wersji PHP, bez OPcache i z małym limitem pamięci będzie wolny niezależnie od tego, jak dobrze ustawimy resztę. Patrzymy też na czas odpowiedzi serwera w godzinach, w których sklep ma najwięcej ruchu, bo na tanim hostingu współdzielonym potrafi on rosnąć kilkukrotnie wieczorem. Jeśli serwer jest wąskim gardłem, mówimy to wprost i podpowiadamy, jakie parametry są potrzebne.

W panelu PrestaShop, w zakładce Wydajność, są ustawienia, które mają duży wpływ na czas ładowania. Kompilacja szablonów Smarty powinna być ustawiona tak, żeby sklep nie kompilował ich przy każdym wejściu. Ten tryb często zostaje włączony po pracach programisty i spowalnia każdą podstronę. Cache Smarty i cache sklepu ustawiamy w zależności od serwera, a opcje łączenia i kompresji plików CSS i JavaScript włączamy dopiero po sprawdzeniu, że nie psują działania motywu i modułów.

W PrestaShop optymalizacja cache wymaga ostrożności przy sklepach z promocjami, cenami dla grup klientów i wieloma walutami. Zbyt agresywne ustawienia potrafią pokazać klientowi nieaktualną cenę albo cudzy koszyk. Dlatego takie zmiany testujemy na kopii sklepu i sprawdzamy na kontach testowych różnych grup klientów, zanim trafią na sklep produkcyjny.

• aktualna wersja PHP zgodna z wersją PrestaShop i modułami
• OPcache i kompresja odpowiedzi serwera
• ustawienia Smarty i cache dobrane do sklepu
• łączenie CSS i JS sprawdzone na kopii sklepu

Moduły to najczęstsza przyczyna wolnego sklepu na PrestaShop. Z czasem w sklepie zbiera się ich kilkadziesiąt: część z instalacji, część dodana przy kampaniach, część po testach, po których nikt nie posprzątał. Wiele modułów ładuje swoje skrypty i style na każdej podstronie, nawet jeśli działają tylko w koszyku albo na jednej stronie informacyjnej.

Przeglądamy listę zainstalowanych modułów i ich podpięcia do motywu. Nieużywane wyłączamy i odinstalowujemy, a przy potrzebnych sprawdzamy, czy da się ograniczyć miejsca, w których się ładują. Szukamy też modułów, które robią to samo, na przykład dwóch modułów do opinii albo kilku do śledzenia konwersji. Przy modułach od zewnętrznych dostawców sprawdzamy, czy mają aktualizacje zgodne z Twoją wersją PrestaShop i PHP.

Osobny temat to moduły SEO do PrestaShop. Darmowe moduły, w tym oficjalny moduł mapy witryny, w wielu sklepach w zupełności wystarczą. Płatny moduł SEO ma sens przy dużym katalogu, wielu językach albo gdy trzeba masowo ustawić meta tagi, przekierowania i reguły dla filtrów. Każdy moduł SEO sprawdzamy pod kątem zgodności i wpływu na szybkość, bo zdarza się, że moduł poprawiający SEO jednocześnie spowalnia cały sklep.

PrestaShop zapisuje w bazie dużo danych pomocniczych: statystyki połączeń i odwiedzin, informacje o gościach, wyszukiwania w sklepie, logi, nieodnalezione strony i porzucone koszyki. W sklepie działającym kilka lat te tabele potrafią być większe niż dane o produktach i zamówieniach razem. Efekt to wolniejsze zapytania, dłuższe kopie zapasowe i wolniejszy panel administracyjny.

Przed czyszczeniem robimy kopię bazy i ustalamy z Tobą, jakie dane są potrzebne, na przykład do statystyk czy rozliczeń. Potem usuwamy stare wpisy ze statystyk i logów, porzucone koszyki sprzed określonej daty, pozostałości po odinstalowanych modułach i nieaktualne dane wyszukiwarki sklepu. Sprawdzamy też indeksy tabel, które moduły dodawały bez ładu i składu.

Czyszczenie bazy nie jest jednorazowe. Warto ustawić wyłączenie zbędnych statystyk albo cykliczne usuwanie starych danych, żeby problem nie wrócił za rok. Jeśli sklep ma stałą opiekę techniczną, przekazujemy instrukcję, co i jak często czyścić. Stałą obsługę możemy też przejąć w ramach opieki nad stroną.

W sklepie na PrestaShop optymalizacja SEO zaczyna się od panelu. W zakładce Ruch i SEO ustawia się przyjazne adresy URL, schemat adresów dla produktów, kategorii i stron CMS oraz meta tagi dla stron systemowych. Sprawdzamy, czy strona główna, kategorie i najważniejsze produkty mają własne tytuły i opisy meta, a nie jeden szablon z nazwą sklepu powtórzoną wszędzie.

Kolejne elementy to canonicale, robots.txt i mapa witryny. Produkt przypisany do kilku kategorii może być dostępny pod kilkoma adresami, więc canonical musi wskazywać jedną wersję. Plik robots.txt generowany przez PrestaShop warto przejrzeć ręcznie, bo bywa, że blokuje zasoby potrzebne do wyświetlenia strony albo nie blokuje adresów, które powinien. Mapę witryny generujemy modułem, zgłaszamy w Search Console i sprawdzamy, czy nie zawiera adresów z przekierowaniem lub błędem.

Do tego dochodzą dane strukturalne produktów (cena, dostępność, marka, okruszki), poprawne kody odpowiedzi dla produktów wycofanych i niedostępnych oraz linkowanie wewnętrzne z menu i bloków na stronie głównej. Pełną diagnozę tych elementów robimy w ramach audytu SEO sklepu, a szerszy zakres prac na stronach opisujemy przy optymalizacji SEO.

Przyjazne adresy URL włącza się w PrestaShop jednym przełącznikiem, ale na tym praca się nie kończy. Domyślny schemat adresu produktu zawiera numer ID, a czasem także kategorię i atrybuty. Adres z samą nazwą produktu jest czytelniejszy, ale jego zmiana w działającym sklepie oznacza zmianę tysięcy adresów, które Google już zna.

Dlatego zmianę schematu adresów robimy tylko razem z mapą przekierowań 301 ze starych adresów na nowe. Sprawdzamy przy tym, czy nie powstają duplikaty, na przykład dwa produkty o tej samej nazwie, i czy przekierowania nie tworzą łańcuchów. Po wdrożeniu obserwujemy w Search Console błędy 404 i to, jak szybko Google przenosi nowe adresy do indeksu.

Jeśli sklep ma dobrą widoczność i adresy z numerami ID, czasem lepiej ich nie ruszać. Numer w adresie sam w sobie nie przeszkadza w pozycjonowaniu, a każda migracja adresów to ryzyko przejściowego spadku ruchu. Taką decyzję podejmujemy na podstawie danych o ruchu i widoczności, a nie dlatego, że adres „ładniej wygląda”.

Nawigacja fasetowa, czyli filtry po kolorze, rozmiarze, marce czy cenie, pomaga klientom, ale potrafi zaszkodzić SEO. Każda kombinacja filtrów, sortowania i paginacji to osobny adres. W sklepie z kilkoma tysiącami produktów daje to setki tysięcy adresów, z których większość zawiera te same produkty w innej kolejności. Google traci czas na ich przeglądanie, a ważne kategorie i nowe produkty trafiają do indeksu wolniej.

Nie wyłączamy wszystkich filtrów z indeksu, bo część z nich odpowiada na realne zapytania. Kombinacja kategorii i marki albo kategorii i koloru często ma swoje wyszukiwania i może sprzedawać. Takie filtry zamieniamy w pełnoprawne podstrony z własnym tytułem, nagłówkiem i opisem. Resztę, czyli sortowania, zakresy cen, wielokrotne kombinacje i parametry śledzące, wyłączamy z indeksu przez noindex lub canonical, a robots.txt stosujemy tam, gdzie trzeba ograniczyć samo przeglądanie.

Efekt sprawdzamy w raporcie indeksowania stron w Search Console: spada liczba adresów odkrytych i niezaindeksowanych, a rośnie udział kategorii i produktów w indeksie. Szczegóły tej pracy w ramach stałej współpracy opisujemy na stronie pozycjonowanie PrestaShop.

• lista filtrów z wyszukiwaniami, które zostają w indeksie
• noindex lub canonical dla sortowań i kombinacji
• poprawna paginacja kategorii
• kontrola efektu w raporcie indeksowania GSC

Wiele sklepów działa jeszcze na PrestaShop 1.6 lub 1.7. Starsze wersje nie wspierają nowszych wersji PHP, a część modułów i motywów przestała być rozwijana. W pewnym momencie optymalizacja starej wersji przestaje mieć sens i lepiej przejść na PrestaShop 8 lub 9.

Przy migracji najważniejsze dla SEO jest zachowanie adresów albo przygotowanie pełnej mapy przekierowań 301, przeniesienie tytułów, opisów meta i treści kategorii oraz sprawdzenie, czy nowy motyw nie gubi danych strukturalnych i linkowania wewnętrznego. Całość testujemy na kopii sklepu, zanim zmienimy wersję produkcyjną. Po przełączeniu przez kilka tygodni obserwujemy błędy 404, indeks i ruch w Search Console.

Jeśli przy okazji migracji planujesz nowy motyw albo budowę sklepu od nowa, zobacz tworzenie sklepów internetowych. Wtedy SEO techniczne i szybkość ustawiamy od początku, zamiast poprawiać je po fakcie.