Czy Storefront jest lepszy pod SEO od RWD?
Z punktu widzenia możliwości technologicznych Storefront ma obecnie kilka istotnych przewag.
Nie oznacza to jednak, że Google „lubi Storefront bardziej” i po jego włączeniu automatycznie podniesie pozycje sklepu.
Na efekty SEO nadal wpływają między innymi:
- architektura kategorii,
- jakość oferty,
- treści,
- indeksacja,
- linkowanie,
- profil linków zewnętrznych,
- szybkość,
- dane produktowe,
- konkurencja.
Można więc posiadać świetnie zoptymalizowany sklep RWD oraz słabo przygotowany Storefront.
Największa różnica polega na tym, jak poszczególne elementy techniczne są generowane oraz w jaki sposób możemy je modyfikować.
RWD i Storefront wykorzystują inną architekturę szablonu
Klasyczne szablony Shopera przez lata opierały wiele zaawansowanych modyfikacji na edycji plików .tpl.
W praktyce specjalista SEO lub deweloper mógł ingerować między innymi w pliki odpowiadające za:
- listę produktów,
- kartę produktu,
- nagłówki,
- breadcrumbs,
- canonicale,
- sposób wyświetlania opisów.
W starszych sklepach można więc spotkać wiele indywidualnych modyfikacji wykonanych bezpośrednio w kodzie szablonu.
Storefront został zbudowany inaczej. Dużą częścią układu zarządza się przy wykorzystaniu Shoper Visual Editor oraz modułów.
To bardzo ważne podczas audytu.
Najpierw należy sprawdzić, czy określony element jest błędny, a dopiero później zdecydować, w jaki sposób naprawić go w konkretnej technologii.
Kopiowanie kodu znalezionego w poradniku dla RWD do Storefrontu nie jest właściwą metodą.
Storefront daje większą kontrolę nad układem stron bez edycji .tpl
Visual Editor pozwala zarządzać układem wielu typów stron: strony głównej, produktów, kategorii, stron producentów, bloga czy stron informacyjnych.
Z perspektywy SEO jest to przydatne między innymi wtedy, gdy chcemy:
- zmienić położenie treści,
- dodać nagłówek,
- wyświetlić inne moduły na określonych typach stron,
- kontrolować układ na urządzeniach mobilnych,
- rozbudować stronę kategorii bez klasycznej ingerencji w pliki szablonu.
W RWD podobna zmiana częściej wymagała modyfikacji kodu albo użycia rozwiązania charakterystycznego dla konkretnego szablonu.
Nie oznacza to, że Storefront pozwala zmienić z panelu każdy techniczny element SEO. Nadal mogą pojawiać się sytuacje wymagające pomocy dewelopera lub supportu.
H1 - różnica dotyczy przede wszystkim sposobu wdrożenia
Nagłówek H1 jest dobrym przykładem tego, dlaczego nie powinno się mieszać instrukcji dla RWD i Storefrontu.
W standardowej konfiguracji nazwa produktu lub kategorii może pełnić funkcję głównego nagłówka strony. Problem pojawia się wtedy, gdy chcemy pozostawić krótką nazwę w menu, ale zastosować bardziej rozbudowany H1.
W starszych szablonach RWD takie rozdzielenie często wymagało modyfikacji pliku szablonu i wykorzystania dodatkowej zmiennej.
Storefront oferuje znacznie wygodniejsze możliwości zarządzania strukturą strony oraz nagłówkami z wykorzystaniem panelu i modułów.
Zanim jednak zaczniemy dodawać kolejny H1, należy sprawdzić kod źródłowy. Wstawienie dodatkowego nagłówka tylko dlatego, że „H1 jest ważny dla SEO”, może skończyć się niepotrzebnym powieleniem.
Dane strukturalne - tutaj Storefront ma wyraźną przewagę
To obecnie jedna z najważniejszych różnic technologicznych.
Klasyczne szablony RWD wykorzystują przede wszystkim Microdata, czyli znaczniki osadzone bezpośrednio w strukturze HTML.
Storefront korzysta z JSON-LD, w którym dane strukturalne mogą funkcjonować w osobnych blokach i być oddzielone od warstwy wizualnej.
W Storefront zakres przekazywanych informacji jest również znacznie szerszy.
Dla oferty produktowej oprócz podstawowych informacji o cenie, walucie i dostępności mogą pojawiać się dane związane np. ze szczegółami ceny, okresem promocji czy dostawą.
Różnica jest jeszcze większa przy innych elementach serwisu.
RWD i Storefront inaczej obsługują część filtrowania
Filtry to jeden z najważniejszych obszarów technicznego SEO w dużych sklepach.
W klasycznych wdrożeniach Shopera można spotkać rozbudowane adresy URL generowane po wyborze filtrów i sortowania. W części starszych sklepów takie adresy trafiały również do indeksu.
Może to prowadzić do sytuacji, w której kilkaset właściwych kategorii generuje tysiące albo dziesiątki tysięcy dodatkowych wariantów URL.
Storefront inaczej obsługuje adresy aktywnych filtrów i domyślnie ogranicza ich indeksowanie.
Jest to istotna przewaga, ale nie zwalnia z audytu.
Po zmianie szablonu należy sprawdzić:
- jakie adresy są faktycznie generowane,
- czy robot może do nich dotrzeć,
- jakie canonicale otrzymują,
- czy nie istnieją stare indeksowane URL-e,
- czy wartościowe kombinacje filtrów nie powinny posiadać osobnych landing page’y.
Nie warto stosować zasady „każdy filtr jest zły”. Decyzja powinna wynikać z potencjału wyszukiwania.
Warianty produktów mogą zmienić sposób generowania URL
Przy przejściu z RWD na Storefront warto również zwrócić uwagę na warianty.
Shoper wskazuje, że w Storefront warianty produktów mogą otrzymywać własne unikalne adresy URL.
To oznacza, że po zmianie technologii trzeba ponownie sprawdzić, jak Google widzi rodzinę produktów:
- który adres jest główny,
- jakie canonicale są generowane,
- czy warianty powinny być indeksowane,
- czy treść stron jest wystarczająco odmienna,
- jak warianty pojawiają się w linkowaniu wewnętrznym.
Nie należy zakładać, że konfiguracja właściwa dla jednego sklepu będzie właściwa dla każdego.
Meta title i meta description nie znikają po zmianie szablonu
Przejście z RWD na Storefront nie oznacza konieczności tworzenia całej optymalizacji metadanych od początku.
Shoper wskazuje, że ustawione wcześniej meta dane pozostają po zmianie technologii.
To dobra informacja, ale jednocześnie dobra okazja do audytu.
Warto zweryfikować:
- globalne schematy title i description,
- ręczne nadpisania dla najważniejszych kategorii,
- metadane produktów,
- strony producentów,
- strony informacyjne,
- wpisy blogowe,
- paginację.
Jeżeli wcześniejszy sklep posiadał słaby schemat, Storefront go automatycznie nie poprawi.
Treści również trzeba sprawdzić po zmianie szablonu
Sam opis kategorii albo produktu może pozostać w bazie, ale nie oznacza to jeszcze, że po zmianie układu będzie prezentowany dokładnie tak samo.
Trzeba zweryfikować:
- miejsce wyświetlania opisu,
- kolejność H1 i tekstu,
- widoczność treści na mobile,
- nagłówki H2 i H3,
- linki wewnętrzne,
- elementy rozwijane typu „czytaj więcej”,
- dodatkowe moduły znajdujące się przed listingiem.
Z punktu widzenia SEO szczególnie ważne jest zachowanie najwartościowszego contentu podczas zmiany szablonu. Nie ma sensu jednocześnie przechodzić na Storefront i usuwać połowy treści, jeśli później chcemy jednoznacznie ocenić wpływ samej zmiany technologii.
Storefront ułatwia pracę nad wersją mobilną
Storefront daje większą swobodę w określaniu, w jaki sposób elementy mają wyglądać na różnych szerokościach ekranu.
Ma to duże znaczenie w e-commerce.
Długi opis kategorii, który wygląda dobrze na monitorze, może na telefonie przesunąć produkty kilka ekranów w dół. Rozbudowany banner może z kolei zajmować większość pierwszego widoku.
Visual Editor pozwala łatwiej analizować i modyfikować układ w zależności od urządzenia.
Nie oznacza to jednak, że Storefront automatycznie rozwiązuje każdy problem mobile SEO. Nadal należy testować nawigację, filtry, breadcrumbs, formularze i ścieżkę zakupową na prawdziwych urządzeniach.
Storefront może ułatwić optymalizację wydajności, ale nie daje gwarancji dobrych Core Web Vitals
Nowsza technologia i nowoczesna obsługa grafik są atutem Storefrontu. Shoper automatycznie obsługuje między innymi konwersję dodawanych grafik do WebP.
Nadal można jednak spowolnić sklep przez:
- zbyt ciężkie zdjęcia,
- rozbudowane bannery,
- dodatkowe aplikacje,
- czaty,
- skrypty reklamowe,
- zewnętrzne widgety,
- niepotrzebny JavaScript.
Core Web Vitals należy więc badać na konkretnym sklepie, a nie oceniać tylko na podstawie nazwy technologii.
Co z canonicalami i blogiem?
W obu technologiach trzeba analizować efekt końcowy, czyli kod generowany przez sklep.
Szczególnie warto sprawdzić:
- canonicale na kategoriach,
- canonicale na filtrach,
- paginację,
- paginację bloga,
- strony tagów,
- nieaktywne produkty.
Różnica polega głównie na sposobie wprowadzenia ewentualnej poprawki.
W starszym RWD rozwiązanie może wymagać edycji konkretnego pliku .tpl. W Storefront sposób konfiguracji jest inny i trzeba korzystać z możliwości aktualnego szablonu, Visual Editora albo wsparcia technicznego.
Dlatego podczas audytu nie należy pisać rekomendacji „zmodyfikuj product/list.tpl”, zanim nie sprawdzimy, czy sklep w ogóle korzysta z technologii, w której taki plik ma znaczenie.
| Obszar | Klasyczny Shoper RWD | Shoper Storefront | Znaczenie dla SEO |
|---|---|---|---|
| Architektura szablonu | Wiele zaawansowanych zmian wykonywanych bezpośrednio w plikach .tpl |
Inna architektura, oparta w dużej mierze na modułach i Visual Editorze | Przed wdrożeniem rekomendacji trzeba ustalić technologię sklepu. Instrukcje dla RWD nie powinny być automatycznie stosowane w Storefront |
| Edycja układu stron | Częściej wymaga zmian w kodzie lub rozwiązania charakterystycznego dla danego szablonu | Większa część układu może być zarządzana przez Visual Editor | Storefront ułatwia zmianę kolejności elementów, rozbudowę kategorii i dostosowanie układu bez ingerencji w .tpl |
| Nagłówki H1 | Rozdzielenie nazwy kategorii lub produktu od H1 często wymaga modyfikacji szablonu i dodatkowej zmiennej | Wygodniejsze możliwości zarządzania nagłówkami z poziomu panelu i modułów | W obu przypadkach trzeba sprawdzić efekt w kodzie i unikać niepotrzebnego powielania H1 |
| Dane strukturalne | Przede wszystkim Microdata osadzona w HTML | JSON-LD, oddzielone od warstwy wizualnej | Storefront daje szersze możliwości przekazywania uporządkowanych danych wyszukiwarkom |
| Zakres danych strukturalnych | Bardziej podstawowy | Może obejmować m.in. cenę, dostępność, promocje, dostawę, artykuły, autora, datę publikacji, grafiki, FAQ, dane sklepu i zestawy produktów | Storefront ma tutaj wyraźną przewagę technologiczną |
| Filtry i sortowanie | W starszych konfiguracjach mogą generować rozbudowane URL-e, które czasem trafiają do indeksu | Inaczej obsługuje aktywne filtry i domyślnie ogranicza ich indeksowanie | Storefront ogranicza część typowych problemów, ale nadal trzeba analizować crawl, indeksację i canonicale |
| Warianty produktów | Sposób obsługi zależy od konfiguracji starszego sklepu | Warianty mogą otrzymywać własne unikalne URL-e | Po zmianie trzeba sprawdzić adres główny, canonicale, indeksację wariantów i ich linkowanie |
| Meta title i meta description | Można korzystać z globalnych schematów i indywidualnych ustawień | Dotychczasowe metadane pozostają po zmianie technologii | Przejście na Storefront nie poprawia automatycznie słabych schematów — nadal potrzebny jest audyt |
| Treści kategorii i produktów | Sposób wyświetlania często zależy od szablonu i jego modyfikacji | Układem można wygodniej zarządzać przez moduły | Po zmianie trzeba sprawdzić miejsce treści, kolejność H1, nagłówki, linki i widoczność na mobile |
| Wersja mobilna | Zmiany częściej zależą od konstrukcji konkretnego szablonu | Większa swoboda zarządzania układem dla różnych szerokości ekranu | Storefront ułatwia pracę nad mobile UX, ale nadal wymaga testów nawigacji, filtrów i ścieżki zakupowej |
| Wydajność | Zależna od szablonu, kodu i dodatkowych elementów | Nowsza technologia i nowoczesna obsługa grafik, m.in. WebP | Storefront może ułatwiać optymalizację, ale nie gwarantuje dobrych Core Web Vitals |
| Canonicale | Ewentualne poprawki mogą wymagać ingerencji w konkretne pliki .tpl |
Sposób konfiguracji jest inny i zależy od aktualnych możliwości Storefront | W obu technologiach trzeba sprawdzać finalny kod, a nie zakładać poprawności ustawień |
| Blog i paginacja | Starsze rozwiązania mogą wymagać modyfikacji plików szablonu | Konfiguracja odbywa się inaczej, z wykorzystaniem aktualnych mechanizmów Storefront | Szczególnie warto kontrolować canonicale, paginację bloga, tagi i H1 |
| Zakres pracy deweloperskiej | Częściej konieczny przy bardziej zaawansowanych zmianach SEO | Więcej elementów można zmieniać bez edycji .tpl, ale nie wszystko |
Storefront ogranicza część pracy w kodzie, jednak przy nietypowych problemach nadal może być potrzebny deweloper lub support |
| Czy technologia sama daje lepsze pozycje? | Może być bardzo dobrze zoptymalizowana | Ma więcej nowoczesnych możliwości technicznych | Nie. Storefront nie podnosi automatycznie pozycji. Nadal liczą się architektura, treści, indeksacja, linkowanie, szybkość, dane produktowe i konkurencja |
Storefront ma przewagę przede wszystkim w sposobie wdrażania zmian, obsłudze danych strukturalnych, filtrów i zarządzaniu układem strony. Nie oznacza to jednak, że sklep na Storefront automatycznie będzie pozycjonował się lepiej od dobrze zoptymalizowanego sklepu RWD.
Czy warto przechodzić z RWD na Storefront tylko dla SEO?
Nie podejmowałabym takiej decyzji wyłącznie na podstawie jednego argumentu SEO.
Jeżeli istniejący sklep RWD:
- ma dobre pozycje,
- jest szybki,
- posiada poprawną indeksację,
- nie ma problemów z filtrowaniem,
- wykorzystuje prawidłowe dane strukturalne,
- nie ogranicza dalszego rozwoju,
natychmiastowa migracja nie musi być najwyższym priorytetem.
Storefront ma jednak wyraźną przewagę jako technologia rozwijana obecnie przez Shopera. Zapewnia nowocześniejszy sposób zarządzania układem, znacznie bogatsze dane strukturalne oraz większą elastyczność na urządzeniach mobilnych.
Dlatego przy większym redesignie albo rozwoju sklepu warto poważnie rozważyć przejście na Storefront.
Przejście z RWD na Storefront też wymaga kontroli SEO
Zmiana samego szablonu zwykle nie powoduje przebudowy większości podstawowych adresów produktów i kategorii. Nie należy jednak aktywować nowej wersji bez testów.
Dużym błędem byłoby połączenie zmiany RWD na Storefront z jednoczesną przebudową całej struktury kategorii, masową zmianą URL-i i usunięciem dużej części contentu. Jeżeli później pojawi się spadek ruchu, ustalenie jego przyczyny będzie znacznie trudniejsze.
Planujesz przejście z RWD na Storefront albo porównujesz oba szablony pod SEO?
Pomożemy ocenić ryzyka, dane strukturalne i checklistę po zmianie szablonu. Skontaktuj się z nami
