Strona internetowa sklepu — gotowy szablon czy projekt na zamówienie

Dla większości małych sklepów rozsądnym startem jest gotowy szablon, a projekt na zamówienie zaczyna się opłacać dopiero wtedy, gdy szablon blokuje konkretny proces biznesowy albo wydajność, którą da się zmierzyć. Tak wynika z danych o rynku szablonów i o wydajności platform — wbrew obu popularnym radom: „zawsze warto zainwestować w custom design” i „szablon wystarczy każdemu”. Ten artykuł dotyczy wyłącznie projektu i struktury strony internetowej sklepu. Prawo, wybór platformy, koszty i SEO mają w serwisie osobne, szczegółowe artykuły, do których tu odsyłamy.

Strona internetowa sklepu: co musi na niej być niezależnie od wyglądu

Zanim zajmiesz się układem strony głównej, sklep potrzebuje trzech elementów, które nie zależą od wyglądu:

• Regulamin. Usługodawca „nieodpłatnie udostępnia usługobiorcy regulamin przed zawarciem umowy o świadczenie takich usług”, a na jego żądanie — w sposób, który umożliwia „pozyskanie, odtwarzanie i utrwalanie treści regulaminu” (ustawa o świadczeniu usług drogą elektroniczną, art. 8 ust. 1 pkt 2). Stawka jest konkretna: klienta nie wiążą postanowienia regulaminu, które nie zostały mu udostępnione w ten sposób (art. 8 ust. 2).
• Informacje przed zawarciem umowy. Najpóźniej w chwili, gdy konsument wyraża wolę zawarcia umowy na odległość, przedsiębiorca ma obowiązek poinformować go „w sposób jasny i zrozumiały” o całym katalogu informacji, w tym o sposobie i terminie odstąpienia od umowy (ustawa o prawach konsumenta, art. 12 ust. 1). Przy produktach fizycznych dochodzi rozporządzenie GPSR (art. 19): oferta „musi zawierać w sposób jasny i widoczny” dane producenta, a gdy producent nie ma siedziby w UE — dane osoby odpowiedzialnej w UE, informacje identyfikujące produkt (w tym jego obraz) oraz ostrzeżenia i informacje o bezpieczeństwie.
• Strona z zasadami zwrotu. Sama zasada (14 dni na odstąpienie bez podania przyczyny) i mechanika zwrotu płatności mają osobny, dużo szczegółowszy tekst: zwroty i reklamacje. Tu wystarczy, że taka strona istnieje i prowadzi do niej link ze stopki.

Przy projektowaniu łatwo zapomnieć o czwartej stronie: polityce prywatności z informacją o plikach cookie, osobnej od regulaminu. Zbierając dane klienta, sklep musi mu podać m.in. swoją tożsamość, cele przetwarzania i ich podstawę prawną (RODO, art. 13) — także wtedy, gdy dane służą tylko realizacji zamówienia. Zapisywanie plików cookie i podobnych informacji w urządzeniu użytkownika to osobna sprawa: Prawo komunikacji elektronicznej (art. 399) wymaga uprzedniej informacji o celu i zgody użytkownika. Dokładna treść polityki zależy od tego, jakie narzędzia śledzące są na stronie włączone (np. Consent Mode, piksele reklamowe), i to temat na osobny tekst.

Pełny przegląd obowiązków prawnych przy zakładaniu sklepu, z datami (EAA, Omnibus, GPSR, KSeF), znajdziesz w artykule jak założyć sklep internetowy. Własny zestaw obowiązków ma też strona produktu — dane GPSR, zdjęcia, cena przy promocjach — i opisujemy go w osobnym artykule o karcie produktu.

Szablon: co daje i gdzie są jego granice

Gotowy szablon w kilka minut daje to, co w projekcie od zera zajmuje tygodnie: układ strony głównej, karty produktów, koszyk i checkout, responsywność i podstawową dostępność. Skąd go wziąć i ile zapłacisz, zależy od platformy — rozpisujemy to w następnej sekcji.

Granica szablonu jest funkcjonalna, nie tylko wizualna. Dobry szablon obsługuje typowy proces zakupowy. Jeśli jednak Twój sklep ma nietypowy proces — konfigurator produktu, model B2B z cennikami per klient, integrację, której szablon nie przewiduje — właśnie tam szablon zaczyna przeszkadzać. Ile kosztuje cały sklep, a nie tylko szablon, rozpisujemy w artykule ile kosztuje sklep internetowy. Platformy i ich cenniki zestawiamy w porównaniu platform e-commerce — jeśli dopiero wybierasz platformę, zacznij od tamtego tekstu.

Szablony Shoper, Shopify, IdoSell, PrestaShop i WooCommerce — skąd i za ile

Każda platforma ma własne źródło szablonów i własny model płatności, więc cena szablonu sklepu internetowego to pytanie o konkretną platformę, nie o rynek. Poniżej stan z 6 października 2026 roku. Katalogi zmieniają się na bieżąco, dlatego przed zakupem sprawdź cenę u źródła.

Shoper prowadzi katalog szablonów graficznych, w którym darmowe i płatne motywy stoją obok siebie. Na czterech stronach katalogu jest ponad 60 szablonów, w tym ponad 20 darmowych, a płatne kosztują od 499 do 3 499 zł netto (odczyt 6.10.2026). Przykład z górnej części cennika: szablon Dealer za 2 499 zł netto. Shoper zaznacza, że „płatność za wybrany motyw jest jednorazowa” i korzystasz z niego „bez żadnych ograniczeń czasowych i dodatkowych kosztów”. Abonament za samą platformę to osobny koszt — zestawiamy go w porównaniu platform.

Shopify sprzedaje szablony w Theme Store: 24 darmowe i 1 278 płatnych, w cenach od 100 do 500 USD (odczyt 6.10.2026). To stan żywego marketplace'u, a nie oficjalny cennik Shopify. Shopify publikuje też próg techniczny, który szablon musi przejść, żeby trafić do Theme Store: średni wynik Lighthouse co najmniej 60 za wydajność i 90 za dostępność, liczony na stronie głównej, stronie kolekcji (kategorii) i karcie produktu, osobno na komputerze i telefonie (wymagania Theme Store). Testy Shopify prowadzi na własnym zestawie danych testowych, a nie na Twoim katalogu — próg mówi o szablonie, nie o sklepie, który na nim zbudujesz.

IdoSell udostępnia 13 darmowych szablonów. Według wpisu z 14 kwietnia 2026 roku są one „dostępne bezpłatnie dla wszystkich Merchantów”, a wybiera się je w galerii szablonów w panelu administracyjnym, gdzie pomaga asystent wyboru szablonu (blog IdoSell). W publicznej galerii szablonów IdoSell link do wersji demo ma 6 z 13 szablonów (odczyt 6.10.2026).

PrestaShop instaluje się z domyślnym motywem Classic. Po kolejne dokumentacja platformy odsyła do PrestaShop Addons, oficjalnego marketplace'u — strona katalogu motywów w panelu sklepu prowadzi wprost do jego oferty (dokumentacja PrestaShop 8).

WooCommerce działa na WordPressie, więc sklep korzysta z motywów WordPressa. Szablony przygotowane pod sklep sprzedaje oficjalny marketplace WooCommerce, który deklaruje 30-dniową gwarancję zwrotu pieniędzy (odczyt 6.10.2026). Darmowe motywy są w katalogu WordPress.org. Na co patrzeć przed zakupem — okres aktualizacji w licencji, liczbę stron, na których wolno użyć motywu, datę ostatniej wersji — opisujemy w artykule o szablonach WordPress.

Co sprawdzić w demie szablonu przed zakupem

Demo pokazuje szablon w warunkach dobranych przez autora: z jego zdjęciami, bez Twoich aplikacji i skryptów marketingowych. Dlatego sprawdzaj w nim to, co po instalacji raczej się pogorszy, niż poprawi. Cztery kontrole przed zakupem:

• Wydajność na trzech typach stron. Zmierz w teście szybkości strony stronę główną, kategorię i kartę produktu demo — te same trzy typy, na których Shopify liczy swój próg. Wynik demo traktuj jako górną granicę: Twoje zdjęcia, aplikacje i tagi raczej go obniżą, niż podniosą (to nasza interpretacja, nie pomiar). Słabe demo nie zamieni się w szybki sklep.
• Koszyk i checkout na telefonie. Dodaj produkt do koszyka i przejdź tak daleko, jak pozwala demo, na prawdziwym telefonie. Większość kupujących kończy zakup właśnie na nim — dane są w sekcji o urządzeniach niżej.
• Co obejmuje cena. W Shoperze płacisz za szablon raz. Przy motywach do WooCommerce sprawdź, na jak długo licencja daje aktualizacje i na ilu domenach możesz jej użyć.
• Podstawowa dostępność. Kontrast, obsługę klawiatury i widoczny fokus z listy w sekcji o dostępności sprawdzisz na demie, zanim cokolwiek kupisz. Szablon, który tu odpada, będziesz poprawiać w cudzym kodzie.

Szablon kontra wydajność: techniczny dług, który trudno zobaczyć na oko

Uniwersalny szablon musi obsłużyć bardzo różne sklepy, więc często ładuje naraz silnik edycji wizualnej, warstwę zgodności ze starszymi wersjami i miejsce na dowolną liczbę wtyczek czy aplikacji. Tak szablon potrafi pogorszyć Core Web Vitals, zwłaszcza LCP, zanim dodasz własną treść.

HTTP Archive Web Almanac 2025 (rozdział „Ecommerce”, dane z lipca 2025, publikacja w styczniu 2026) mierzy według platformy udział witryn z dobrym wynikiem Core Web Vitals, czyli z zaliczonymi jednocześnie LCP, INP i CLS na 75. percentylu:

• Shopify: 76% na mobile i 76% na desktopie,
• PrestaShop: 50% na mobile i 54% na desktopie,
• WooCommerce: 35% na mobile i 33% na desktopie.

Rozdział nazywa LCP „największym czynnikiem różnicującym” platformy (tłumaczenie własne). U WooCommerce to właśnie LCP jest słabym punktem: 39% dobrych wyników na mobile i 45% na desktopie. INP i CLS wypadają lepiej — na mobile 88% i 85%, na desktopie INP 99%, ale CLS tylko 68%.

To dane globalne dla całej platformy — wszystkie wykryte witryny na danym silniku, bez podziału na kraje — a nie ocena konkretnego szablonu ani instalacji. Odchudzony z niepotrzebnych wtyczek sklep na WooCommerce może wypaść lepiej niż średnia platformy, a zaniedbany sklep na Shopify z dziesiątkami aplikacji — gorzej. Liczby pokazują różnicę między platformami, nie jej przyczynę w konkretnym sklepie. Zasada „im więcej nieskonsolidowanych skryptów i wtyczek, tym trudniej o dobry LCP” to nasza interpretacja mechanizmu, nie wynik pomiaru.

Słaby wynik platformy nie jest też trwały. Poprzednia edycja tego rozdziału (publikacja 11.11.2024, dane mobile) notowała dla WooCommerce dobry LCP zaledwie w 34% witryn — jeszcze mniej niż 39% w edycji 2025. W tym samym czasie inne platformy wyraźnie się poprawiły: Tiendanube z 28% dobrych wyników LCP w 2022 roku do 61% w 2024, a Squarespace z 33% do 60% witryn z dobrym wynikiem całego Core Web Vitals. Wniosek: wydajność nie jest wrodzoną cechą silnika. Słaby LCP platformy dwa lata temu nie przesądza o wyniku dziś — i odwrotnie.

Jeśli szablon blokuje proces albo wydajność, którą sprawdzasz w teście szybkości strony, a poprawki w obrębie szablonu już nie pomagają, kolejnym krokiem jest zwykle inna architektura, a nie inny szablon.

Projekt na zamówienie: kiedy się opłaca

Projekt od zera ma sens wtedy, gdy konkretny proces albo konkretna metryka wydajności liczy się bardziej niż szybki start — nie jako domyślny wybór „bo wygląda lepiej”. Kosztuje więcej czasu i pracy niż konfiguracja szablonu, dlatego decyzję warto oprzeć na nazwanym ograniczeniu: ten konfigurator nie działa, ta integracja nie istnieje, ten wynik Core Web Vitals nie poprawia się mimo optymalizacji. Wrażenie, że „szablon wygląda zbyt standardowo”, to za mało.

Najdalej idącym wariantem projektu na zamówienie jest headless: front-end (np. na Next.js) zostaje odłączony od silnika platformy e-commerce, który staje się tylko zapleczem danych i zamówień. Taka architektura daje pełną kontrolę nad tym, co trafia do przeglądarki, a więc i nad wydajnością. Płacisz za to utratą części rzeczy, które szablon daje od razu: gotowych integracji z aplikacjami z marketplace'u platformy, aktualizacji bezpieczeństwa po stronie dostawcy silnika i prostoty wdrożenia bez własnego zespołu deweloperskiego. Dlatego headless opłaca się dopiero wtedy, gdy szablon naprawdę nie nadąża — nie jako domyślne ulepszenie. Kiedy ten krok się zwraca, a kiedy jest przerostem formy nad treścią, opisujemy w artykule o headless commerce. Jak mierzyć i poprawiać same metryki — niezależnie od tego, czy zostajesz przy szablonie, czy przechodzisz na headless — wyjaśniamy w tekście Core Web Vitals sklepu.

Struktura strony głównej i nawigacji

Kilka elementów struktury przyda się w każdym sklepie, bez względu na to, czy stronę buduje szablon, czy projekt na zamówienie, bo wynikają z logiki ścieżki zakupowej:

• Propozycja wartości widoczna bez przewijania — klient od razu wie, co kupuje i od kogo.
• Widoczna nawigacja po kategoriach — stała, przewidywalna struktura dostępna z każdej podstrony, nie tylko ze strony głównej.
• Widoczne pole wyszukiwania — w stałym, oczywistym miejscu nagłówka. Co powinna robić sama wyszukiwarka i jak ją mierzyć, opisujemy w artykule o wyszukiwarce produktów.
• Sygnały zaufania blisko góry strony — bezpieczna płatność, zasady zwrotów, prawdziwe opinie klientów, a nie informacje schowane w stopce.
• Stopka z linkami prawnymi — regulamin, polityka prywatności, dane kontaktowe i strona zwrotów, zawsze w tym samym miejscu.

Ta lista opisuje mechanizm, a nie wynik konkretnego badania, więc traktuj ją jako punkt wyjścia do własnych testów użyteczności. Szablon i projekt na zamówienie realizują ją tak samo, różni się tylko koszt zmiany: w szablonie zmieniasz kolejność sekcji w edytorze motywu, w projekcie na zamówienie — w kodzie. Filtry i listy produktów opisujemy osobno: ich UX w artykule o wyszukiwarce produktów, a wpływ nawigacji fasetowej na SEO w pozycjonowaniu sklepu internetowego.

Telefon kontra komputer — dwa osobne pomiary, nie jeden

Dwa popularne wskaźniki „mobile” mierzą różne rzeczy i nie wolno ich sumować ani traktować jako wzajemnego potwierdzenia. Według StatCounter dla Polski we wrześniu 2026 roku desktop miał 56,03%, mobile 43,36%, a tablety 0,62% wyświetleń stron (odczyt 5.10.2026). To ogólny ruch w panelu StatCounter, a nie tylko ruch zakupowy, i nie spis całej populacji.

Raport Gemius „E-commerce w Polsce 2026” odpowiada na inne pytanie, na innej próbie: na jakim urządzeniu klient kończy zakup. W ankiecie CAWI (14–22.07.2026, 1874 internautów, odsetki liczone wśród kupujących online) „na telefonie zakupy kończy 58% badanych, z czego 44% robi to w aplikacji”, a na komputerze 35%. Inna populacja (kupujący, nie wszyscy użytkownicy) i inne pytanie (urządzenie, na którym klient finalizuje zakup, a nie udział w ruchu). Praktyczny wniosek z obu źródeł: strona musi działać dobrze na telefonie i na komputerze, ale „dobrze” nie znaczy „identycznie”. Checkout i formularze sprawdź na prawdziwym telefonie, bo większość kupujących finalizuje transakcję właśnie na nim.

Dostępność w szablonie — podstawowe kontrole

Sklepy internetowe od 28 czerwca 2025 roku muszą spełniać wymagania dostępności, chyba że prowadzi je mikroprzedsiębiorca. Obowiązek wynika z ustawy o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług (Dz.U. 2024 poz. 731), która wdraża europejski akt o dostępności (EAA) i obejmuje m.in. usługi handlu elektronicznego. Art. 4 pkt 1 wyłącza z niej usługi świadczone przez mikroprzedsiębiorców. Kto nadzoruje przestrzeganie tych przepisów i jak liczy się kary, opisujemy w hubie UX/UI.

Poniżej lista rzeczy, które warto sprawdzić w samym szablonie przed pełnym audytem dostępności. W nawiasach podajemy odpowiadające im kryteria WCAG 2.2 (rekomendacja W3C z 12 grudnia 2024). Treść zgodna z WCAG 2.2 jest zgodna także z WCAG 2.0 i 2.1 — odwrotnie to nie działa.

• Kontrast tekstu — co najmniej 4,5:1 dla zwykłego tekstu i 3:1 dla dużego (1.4.3), zwłaszcza w wariantach kolorystycznych szablonu, których autor motywu mógł nie sprawdzić.
• Semantyczny HTML — nagłówki w logicznej hierarchii, przyciski jako <button>, a nie <div> z obsługą kliknięcia (1.3.1, 4.1.2).
• Tekst alternatywny na zdjęciach produktów, nie tylko na głównym zdjęciu sklepu (1.1.1).
• Pełna obsługa klawiatury — da się przejść przez nawigację, filtry i formularz zamówienia bez myszy (2.1.1).
• Widoczny fokus na linkach, przyciskach i polach formularza, żeby osoba korzystająca z klawiatury widziała, gdzie jest (2.4.7).
• Etykiety pól — label przy każdym polu formularza zamówienia, a nie tylko placeholder, który znika po kliknięciu (3.3.2).
• Rozmiar celów dotykowych — co najmniej 24 × 24 piksele CSS albo odpowiedni odstęp między mniejszymi elementami (2.5.8), co ma znaczenie przy przyciskach wariantów i ilości na telefonie.

Jak wybrać — checklista

• Wiesz, czy typowy szablon obsługuje Twój proces sprzedaży (konfiguratory, ceny B2B, nietypowe integracje), zamiast zakładać, że „jakoś się dostosuje”.
• Regulamin, informacje wymagane przed zawarciem umowy i strona zwrotów są dostępne z każdej podstrony, nie tylko ze strony głównej.
• Core Web Vitals są zmierzone na Twojej instalacji szablonu (nie jako średnia platformy), zanim zapadnie decyzja o projekcie na zamówienie.
• Checkout i formularze są przetestowane na prawdziwym telefonie, a nie tylko w zwężonym oknie przeglądarki na komputerze.
• Nawigacja, wyszukiwarka i sygnały zaufania są widoczne bez przewijania, a stopka ma komplet linków prawnych.
• Szablon przeszedł podstawowe kontrole dostępności z sekcji wyżej, zanim uznasz, że „wystarczy”.

Jeśli wolisz podjąć tę decyzję z kimś, kto oceni Twój szablon i Twoją instalację, a nie średnią dla platformy, napisz do nas. Ten sam temat jest też jednym z punktów checklisty UX sklepu internetowego.