Produkty powiązane w Prestashop

Sekcja „produkty powiązane” w sklepach opartych na Prestashop może być wykorzystana w procesie linkowania wewnętrznego w sposób bardziej i mniej efektywny. Domyślna mechanika zaimplementowana w silniku nie jest zbyt szczęśliwa, dlatego dziś pogadamy o tym, co można z tym zrobić i dlaczego.

W tym materiale będę omawiał mechaniki silnika Prestashop, ale wnioski co do samej sekcji powiązanych produktów możecie adaptować w dowolnym e-commerce.

Zacznijmy od tego, jak w ogóle działa mechanika produktów powiązanych.

Domyślnie, jeśli inaczej nie przewidział tego autor skórki, szablonu, każdy produkt w Prestashop wyświetla tzw. sekcję related products – to zbiór produktów powiązanych z produktem na jakim znajduje się użytkownik. Ta sekcja to dobry sposób, aby dokręcać współczynniki cross-sellingu i up-sellingu – szczególnie, jeśli produkty osadzone w tej sekcji są możliwe do natychmiastowego dorzucenia do koszyka.

Rzecz w tym, że domyślny algorytm, jaki wyświetla produkty osadzone w tym segmencie jest przewidywalny i mało efektywny.

Żebyśmy mieli jasność – będziemy omawiali sobie tę mechanikę w kontekście SEO, a nie zaawansowanych algorytmów rekomendacji.

I teraz tak – domyślnie silnik Presty w tej sekcji zwraca 10 pierwszych produktów z ostatniej kategorii, do której przypisany jest produkt pierwotny (czytaj. podkategorii). Efekt jest taki, że jeśli użytkownik/bot trafi na produkt z 5, 6, nie mówiąc już np. o 30 strony paginacji, to ta sekcja w kółko wyświetla tą samą zawartość – te same linki wewnętrzne do tych samych produktów.

Funkcja wygląda tak:

$products = $category->getProducts((int)Context::getContext()->language->id, 1, ($nb ? $nb : 10));

Jeśli produktów jakimi zarządza Presta jest kilkaset, problem w zasadzie nie istnieje, ale jeśli produktów jest 5-10 tys., to poświęcenie czasu na wypracowanie własnej mechaniki może zasadniczo poprawić indeksowalność każdego z nich. Szczególnie jeśli – a co typowe – nowe produkty w sklepie trafiają najpierw na stronę główną sklepu, potem wiszą na niej przez kilka dni, a następnie spadają na ostatnią stronę paginacji kategorii, do której zostały przypisane przez moderatora.

Istnieje rzecz jasna sporo mechanik, strategii na skuteczne zarządzanie procesem crawlowania i indeksacji nowych oraz starych, archiwalnych produktów. Od zmian na stronie głównej, która ma największy wpływ na rozkład linkjuice’u między podstronami, po zmiany w samym sposobie wyglądu, ekspozycji treści w kategoriach, aż do wydaje się – najprostszych – czyli modyfikacji „polecanych produktów”.

W jednym ze sklepów opartych o e-commerce zmodyfikowaliśmy kod w taki sposób, aby sekcja „polecanych produktów” składała się nie z 10, a 30 produktów i nie 10 pierwszych z podkategorii, a 30 losowo wybranych.

Po wdrożeniu tej mechaniki liczba zaindeksowanych produktów wzrosła o 18 pkt. proc. w ciągu miesiąca od wdrożenia. Organicznie. Bez przeindeksowywania sklepu ręcznie.

18 pkt. proc. to dużo czy mało? Tych 18 pkt. proc. na tamten moment oznaczało dodanie do indeksu Google dodatkowych 700 produktów. I dużo i mało. Oczywiście – te liczby to tylko przykład, jakiego nie powinniście przypisywać swoim sklepom, bo to czy po zmianie sposobu doboru polecanych produktów – indeksacja wzrośnie, to wypadkowa tego, jak w ogóle wygląda u Was architektura informacji, jak dużo linków zewnętrznych prowadzi do kategorii lub pojedynczych produktów. W zasadzie – im gorzej zaplanowana struktura linkowania wewnętrznego w sklepie w ogóle – tym lepsze efekty z wprowadzenia takich zmian. Ale nawet jeśli macie w swoich sklepach wszystkie produkty w indeksie, to zmiana, dywersyfikacja proporcji między produktami, które są najchętniej odwiedzane przez crawlera Google może też pozytywnie wpłynąć na same pozycje, jakie zajmują w wynikach organicznych. Być może w Waszych sklepach też występuje ten problem? A może borykacie się z jeszcze większym wyzwaniem, jakim może być obsługa segmentu „polecanych produktów” przez JavaScript? Bo przecież wiele SaaS’owych rozwiązań, gotowych narzędzi układają zawartość „polecanych produktów” nie ze względu na kontekst SEO, a analitykę, dane o kliencie, czynniki behawioralne, ostatnie zakupy zrealizowane przez klienta i inne, i zawartość polecanych produktów często obsługiwana jest właśnie przez JavaScript. Ale jeśli JavaScript nie był optymalizowany w kontekście crawlingu botów, to nawet z pozoru banalny błąd w kodzie albo nie osadzanie zawartości w DOM mogą być powodami, dla których o crawlingu i poprawnym renderowaniu zawartości możecie zapomnieć. Recz jasna – to nie tak, że JS jest demonem i mielibyście rezygnować z bardziej zaawansowanych mechanizmów rekomendacji, ale jeśli macie wątpliwości co do implementacji zawartości w JS, zawsze możecie albo po prostu unikać JS tam, gdzie nie jest to konieczne lub zweryfikować, jak crawlowana jest Wasza strona, sklep np. w logach serwerowych. Możecie skorzystać z narzędzi dostępnych na Onely i popularnych dodatków do Chrome’a, w tym: View Rendered Source, Quick Javascript Switcher.

Mam nadzieję, że tym materiałem przybliżyłem Wam pokrótce, z jakimi z pozoru banalnymi mechanikami w kontekście SEO mierzą się właściciele e-commerce i jak rozumieć te podstawowe problemy zarządzania linkowaniem wewnętrznym i w konsekwencji – crawl budgetem w przypadku produktów. Jedna prosta zmiana może implikować szereg ważnych zmian rozumieniu procesu indeksacji.