Czym właściwie jest website builder i czym różni się od CMS-a?

Website builder to pakiet trzech rzeczy w jednej subskrypcji: edytora wizualnego (przeciągnij i upuść), hostingu oraz gotowych szablonów. Nie kupujesz serwera, nie instalujesz niczego, nie masz dostępu do plików na serwerze. CMS działa inaczej: to system z bazą danych (MySQL lub MariaDB), katalogiem wtyczek i kodem, który możesz przenieść na dowolny serwer — hosting współdzielony, VPS albo chmurę.

Po stronie builderów: Wix, Squarespace, Webflow, Shopify. Po stronie CMS-ów: WordPress, WooCommerce (WordPress plus warstwa sklepu) i PrestaShop. Shopify bywa wrzucany do pierwszej kategorii, choć to platforma SaaS z własnym rynkiem aplikacji — kodu nie przeniesiesz na swój serwer. Wix i Squarespace pozwalają wyeksportować treści, ale nie działającą stronę. WordPressa przenosisz razem z plikami i bazą.

Różnica, która decyduje o kosztach po 2–3 latach, nie dotyczy edytora. Dotyczy trzech pytań: kto ma dostęp do kodu, kto ma dostęp do bazy danych i co dokładnie możesz wyeksportować. Jeśli po dwóch latach chcesz zmienić dostawcę, przy CMS zabierasz katalog plików i dump bazy. Przy builderze odtwarzasz stronę od zera, często przepisując treści ręcznie.

Kontrola nad wydajnością jest pochodną tego samego podziału. W builderze o kolejności ładowania skryptów, obrazów i fontów decyduje dostawca — Ty wpływasz na to w ograniczonym zakresie. W CMS możesz włączyć lazy loading, przenieść fonty lokalnie i wyciąć zbędne wtyczki. Metryki, które Google bierze pod uwagę, opisuje dokumentacja Core Web Vitals.

Kiedy website builder wystarczy, a kiedy zaczyna generować koszty

Progi da się zapisać w liczbach. Do około 20 podstron, jednego języka i braku logowania klientów builder wystarcza. Powyżej 50 SKU, drugiego języka albo integracji z ERP — przechodzisz na CMS. Między 20 a 50 podstron i 1–50 SKU jest szara strefa: policz, ile godzin miesięcznie spędzasz na obchodzeniu ograniczeń, i przelicz to na stawkę godzinową.

Sygnały przejścia widać w konkretnych procesach:

• ceny indywidualne dla klientów B2B (rabaty przypisane do konta, cenniki grupowe) — w builderze kończy się to plikiem Excel i ręcznym wystawianiem zamówień,
• stany magazynowe w czasie rzeczywistym — wymagają zapisu do jednej bazy, do której dostęp ma sklep i magazyn,
• kilka metod dostawy z regułami wagowymi albo gabarytowymi (kurier do 30 kg, paleta powyżej) — potrzebujesz silnika reguł, nie pola tekstowego,
• faktury i księgowość — integracja z systemem księgowym przez API,
• wielojęzyczność z osobnymi adresami URL i znacznikami hreflang.

Test 15 minut: wypisz pięć procesów, które strona ma obsłużyć w najbliższych 12 miesiącach (rejestracja klienta B2B, mail po opłaceniu zamówienia, aktualizacja stanów z hurtowni, faktura, zapis do newslettera). Przy każdym sprawdź dwie rzeczy: czy builder udostępnia publiczne API lub webhooki i czy użycie ich nie wymaga płatnej aplikacji. Jeśli trzy z pięciu procesów potrzebują API, a builder go nie ma — decyzja jest podjęta.

Osobny sygnał: kontrola nad danymi strukturalnymi. Przy sklepie chcesz decydować, co trafia do znaczników produktu, a nie akceptować to, co wygeneruje dostawca. Wspierane typy opisuje galeria danych strukturalnych Google.

Ile to realnie kosztuje? Abonament kontra wdrożenie i utrzymanie

Abonament buildera to zwykle 60–200 zł miesięcznie za plan z własną domeną i podstawowym sklepem. To nie jest pełny koszt. Dochodzą: limity ruchu (po przekroczeniu plan przechodzi w wyższy), aplikacje integracyjne płatne osobno za każdą funkcję, prowizje od płatności doliczane ponad opłatę operatora oraz dopłaty za wielojęzyczność i osobne wersje językowe. Wyjdziesz z danymi, ale nie z szablonem — układ odtwarzasz od zera.

WordPress lub WooCommerce to 4–15 tys. zł wdrożenia (zależnie od liczby szablonów, integracji i migracji treści) plus 150–600 zł miesięcznie opieki technicznej: kopie zapasowe, aktualizacje wtyczek i rdzenia, monitoring, poprawki po zmianach w PHP. Osobno hosting, zwykle 30–150 zł miesięcznie, i domena. Przy integracji z systemem zewnętrznym sprawdź, czy platforma ma publiczną dokumentację API — zakres webservice i modułów pokazuje dokumentacja dla deweloperów PrestaShop.

Punkt zwrotny: kiedy łączne opłaty za buildera przekraczają około 250–300 zł miesięcznie, wdrożenie na CMS zwraca się zwykle w 12–18 miesięcy — i zostaje jako składnik majątku firmy, a nie koszt, który przepada z końcem subskrypcji.

Wycena u nas nie startuje od cennika „od strony”. Liczymy godziny: (1) inwentaryzacja procesów, 1–2 h, (2) mapowanie na funkcje — szablon, wtyczka, własny kod — 2–4 h, (3) szacunek godzin per moduł (katalog, koszyk, płatności, integracje, migracja treści), (4) przemnożenie przez stawkę godzinową, (5) osobne oszacowanie opieki technicznej, (6) zapis założeń i wyłączeń. Dostajesz dokument, w którym widać, co jest w zakresie, a co nie — dzięki temu porównujesz oferty po zakresie, a nie po ostatniej linijce.

Website builder a SEO: co działa od razu, a co blokuje wzrost

Website builder domyślnie rozwiązuje podstawy SEO, które kiedyś wymagały konfiguracji serwera. Dostajesz HTTPS (certyfikat Let’s Encrypt odnawiany automatycznie), generowaną sitemap.xml, pola na meta title i description, a hosting często stoi za CDN. Dla prostej strony firmowej o 5–10 podstronach to wystarcza, żeby pojawić się w Google.

Problemy zaczynają się przy wzroście. Pierwszy: wzorzec URL. Buildery często tworzą adresy typu /page/12345 lub doklejają -2 przy duplikacie. Nie ustawisz czystego /uslugi/pozycjonowanie/ ani nie zmienisz struktury bez utraty linków. Drugi: brak dostępu do .htaccess i reguł przekierowań 301. Przy zmianie nazwy podstrony stary adres zwróci 404, a ruch przepadnie. Trzeci: renderowanie treści przez JavaScript. Jeśli tekst nie jest w źródle strony (Ctrl+U), a pojawia się dopiero w DOM po wykonaniu JS, to Google zwykle sobie poradzi, ale inne crawlery (social preview, narzędzia SEO) już nie. Czwarty: dane strukturalne. Builder zwykle wstawia tylko podstawowe schema, a często wcale. Nie dodasz JSON-LD dla FAQ, produktu czy lokalnego biznesu bez obejść.

Jak to zmierzyć? W Google Search Console użyj inspekcji URL: sprawdź, czy adres jest zaindeksowany i czy test wyników z elementami rozszerzonymi widzi dane strukturalne. Osobno otwórz źródło strony i poszukaj kluczowego tekstu. Jeśli go nie ma — treść jest tylko w DOM. Lista formatów danych strukturalnych wspieranych przez Google pomoże ocenić, czego brakuje.

Sklep na builderze: płatności, kurierzy i ERP w polskich realiach

Sklep na builderze w polskich realiach rozbija się o trzy rzeczy: płatności, dostawę i ERP. Zacznijmy od płatności. Przelewy24, PayU, tpay i BLIK mają gotowe moduły do Shopify, Wix czy Squarespace — ale nie wszystkie. BLIK często wymaga pośrednictwa bramki, a prowizje bywają wbudowane w builder (np. Shopify pobiera 2% za transakcje poza Shopify Payments). Sprawdź, czy moduł obsługuje zwroty i kody rabatowe — to nie zawsze działa.

Dostawa: InPost Paczkomaty, DPD, DHL. Wtyczka do generowania etykiet to jedno, ale masowe nadawanie przesyłek (np. 50 paczek dziennie) wymaga wywołań API — InPost ShipX, DPD WebAPI. Builder rzadko pozwala na własne webhooki i kolejkowanie zadań. Zostaje ręczne klikanie.

ERP: Subiekt GT/nexo, Comarch Optima, WF-Mag. Synchronizacja stanów, cenników i faktur działa albo przez gotowy integrator (np. BaseLinker), albo przez API. Builder bez webhooków oznacza ręczne wpisywanie stanów po każdej sprzedaży. Przy 200 zamówieniach miesięcznie to etat dla pół osoby.

Najczęstszy powód, dla którego sklep nie da się przenieść bez przepisania: brak możliwości modyfikacji checkoutu i logiki koszyka. Nie ustawisz rabatu łączonego, progu darmowej dostawy per kategoria czy niestandardowego pola w koszyku. Jeśli planujesz rosnąć, lepiej od razu wybrać platformę z dostępem do kodu — np. PrestaShop daje pełną kontrolę nad koszykiem i checkoutem.

Wydajność i Core Web Vitals — jak zmierzyć stan zamiast zgadywać

Core Web Vitals mierzy się dwiema metodami: laboratoryjnie i na rzeczywistych danych. Progi Google są stałe: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1. W PageSpeed Insights (Lighthouse) testujesz w kontrolowanych warunkach — jeden przebieg, emulacja 4G, bez rozszerzeń. W raporcie CrUX widzisz dane od prawdziwych użytkowników Chrome z ostatnich 28 dni. Dlatego wyniki się rozjeżdżają: lab pokaże 1,8 s, a CrUX 3,4 s, bo użytkownicy mają słabsze łącza, starsze telefony i włączone blokery.

Co zrobić, gdy builder nie pozwala usunąć blokujących skryptów apek? Po pierwsze, sprawdź w PageSpeed Insights sekcję „Eliminate render-blocking resources”. Jeśli nie możesz usunąć, spróbuj przenieść skrypty na koniec (atrybut defer lub async — jeśli builder na to pozwala). Po drugie, włącz lazy loading dla obrazów poniżej ekranu (loading="lazy") i dla iframe’ów. Po trzecie, kompresuj obrazy do WebP lub AVIF — to zwykle 30–50% mniejszy plik niż JPG. Wiele builderów robi to automatycznie, ale nie wszystkie. Sprawdź w raporcie CrUX w Search Console > Core Web Vitals, które adresy wypadają najgorzej.

Pamiętaj, że definicje i progi Core Web Vitals zmieniały się w czasie (INP zastąpił FID w marcu 2024), więc nie sugeruj się starymi poradnikami.

Vendor lock-in: 6 sygnałów, że nie masz kontroli nad swoją stroną

Vendor lock-in nie objawia się na fakturze. Objawia się w dniu, w którym chcesz zmienić narzędzie i okazuje się, że nie masz czym wyjechać. Poniżej sześć sygnałów. Sprawdzaj je na swoim koncie, nie w materiałach sprzedawcy.

1. Eksport treści bez struktury. Dostajesz plik HTML albo PDF z podstronami, ale bez pól: tytuł, opis, kategoria, cena. Z takiego pliku nie zrobisz importu — czeka Cię ręczne przeklejanie 200 podstron.
2. Brak eksportu danych klientów. Konta klientów, historia zamówień i zgody marketingowe to Twoje dane. Jeśli panel daje tylko ekran z listą i przycisk „drukuj”, nie masz nic.
3. Brak eksportu zamówień w CSV. Konkretny test: filtr po dacie, eksport do CSV, sprawdzenie, czy w pliku są pozycje zamówienia, adresy dostawy i statusy płatności. Bez tego księgowość i magazyn pracują na kopiuj-wklej.
4. Limity API. Na przykład 60 zapytań na minutę albo brak webhooków. Wtedy synchronizacja z ERP kończy się kolejką błędów, a nie automatyzacją.
5. DNS i domena na cudzym koncie. Jeśli rekordy A i CNAME oraz abonent domeny są po stronie wykonawcy, to on decyduje, czy Twoja strona istnieje.
6. Brak dostępu do poczty i analityki. Google Analytics, Search Console, poczta na domenie — konta muszą być założone na firmowy adres, nie na prywatny e-mail wykonawcy.

Własność ustal na piśmie przed startem: kto jest abonentem domeny, kto ma rolę administratora w DNS, analityce i poczcie oraz na jakich zasadach przekazuje dostępy po zakończeniu współpracy.

Test przed zakupem: uruchom darmowy plan, dodaj 3 produkty, a potem spróbuj wyeksportować zamówienia i listę adresów URL. Zajmuje to 20 minut i mówi więcej niż cała strona cennika.

Migracja z website buildera na PrestaShop lub WooCommerce krok po kroku

Migracja to nie „przepisanie strony”. To przeniesienie treści, klientów i ruchu z jednego systemu do drugiego bez utraty pozycji. Kolejność działań ma większe znaczenie niż wybór platformy.

Co przenosi się bez strat: treści i zdjęcia, o ile masz pliki źródłowe, a nie tylko podgląd; adresy URL — przez mapę przekierowań 301; dane klientów i zamówień — z eksportu CSV. Co trzeba odtworzyć od zera: koszyk i proces zamówienia, reguły dostawy i progi darmowej wysyłki, integracje płatności i kurierów, dane strukturalne oraz logika cenowa B2B (grupy klientów, rabaty progowe, ceny netto i brutto).

Kolejność działań: audyt i eksport z buildera, mapa URL (stary → nowy, relacja 1:1), środowisko staging na subdomenie z blokadą noindex, migracja treści i produktów, konfiguracja płatności i testy w trybie sandbox, wdrożenie przekierowań 301, monitoring błędów 404 przez 30 dni.

Zabezpieczenie pozycji: nie wyłączaj starej strony, dopóki nowe URL-e nie odpowiadają kodem 200 i nie są zaindeksowane. Sprawdź to w Search Console, w raportach pokrycia i mapy witryny. Dopiero potem przekieruj domenę.

Dane strukturalne dla produktów generujesz od nowa — w builderach zwykle ich nie było, a to one odpowiadają za prezentację ceny i dostępności w wynikach wyszukiwania. Warto od razu zaplanować je w obsługiwanych przez Google typach danych strukturalnych, a nie dokładać po miesiącach.

Budować samemu czy z zespołem wdrożeniowym? Jak wygląda dobra wycena

Samodzielna konfiguracja ma sens, gdy spełniasz wszystkie trzy warunki: strona wizytówkowa lub prosty blog, jeden język, zero integracji — bez płatności online, magazynu i ERP. Wtedy builder za 30-60 zł miesięcznie i 10-15 godzin pracy to realny plan.

Zespół wdrożeniowy potrzebny jest wtedy, gdy pojawia się którakolwiek z tych rzeczy: sklep z magazynem i stanami, integracja z ERP lub systemem księgowym, więcej niż jeden kurier, wymagane SLA (na przykład reakcja w 4 godziny w dni robocze) oraz konkretny termin — kampania, sezon, umowa z klientem.

Rzetelna wycena ma cztery cechy:

• rozbicie na godziny i zakres, na przykład: 80-110 h, w tym 20 h na integrację płatności, 15 h na migrację danych, 10 h na testy — a nie jedna kwota bez pozycji,
• widełki zamiast jednej liczby, bo zakres zwykle doprecyzowuje się po audycie, a nie po podpisaniu umowy,
• jasne SLA po wdrożeniu: czas reakcji, kanał zgłoszeń, liczba godzin w pakiecie serwisowym,
• kontakt bezpośrednio z deweloperem, który pisze kod — bez pośredników przekazujących ustalenia mailem.

Poproś też o pomiar wskaźników Core Web Vitals przed i po wdrożeniu. To kryterium mierzalne, którego nie da się zapisać „na słowo”, a jednocześnie łatwe do porównania między ofertami.

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• Liczba podstron — Policz podstrony istniejące i planowane na najbliższe 12 miesięcy. Do około 20 podstron builder zwykle wystarcza, bez względu na to, jak ładny ma edytor.
• Liczba SKU — Sprawdź liczbę produktów teraz i prognozę na rok. Powyżej około 50 SKU zaczynają się problemy z zarządzaniem katalogiem i cenami.
• Liczba języków — Sprawdź, czy dwa języki mieszczą się w planie, który wybrałeś, i jak wyglądają ich adresy URL. To wpływa na SEO i na koszt abonamentu.
• Logowanie klientów — Sprawdź, czy potrzebujesz strefy klienta z historią zamówień i fakturami. Brak logowania to jeden z filarów progu builder niezbędny.
• Ceny indywidualne dla B2B — Sprawdź, czy ceny zależą od klienta, grupy lub progu ilościowego. Jeśli tak, potrzebujesz silnika reguł cenowych, a nie edytora stron.
• Stany magazynowe w czasie rzeczywistym — Sprawdź, czy stan ma się zgadzać między sklepem, magazynem i hurtownią. Synchronizacja co godzinę zwykle nie wystarcza przy sprzedaży wielokanałowej.
• Metody dostawy i reguły wagowe — Sprawdź, czy koszt dostawy zależy od wagi, wymiarów lub liczby paczek. Każda reguła to dodatkowa logika po stronie sklepu.
• Integracja z ERP — Sprawdź, czy faktury, cenniki i stany mają być pobierane z Subiekta, Optimy lub WF-Mag. Bez API po stronie narzędzia temat się zatrzymuje.
• Metody płatności — Sprawdź, czy potrzebne bramki mają gotowe moduły i jakie prowizje są wbudowane w rozliczenie buildera.
• Eksport treści i danych — Sprawdź na testowym koncie, co dokładnie da się wyeksportować: strony, produkty, klientów, zamówienia. Zrób to przed startem, nie po dwóch latach.
• Własność domeny i DNS — Sprawdź, czy domena jest zarejestrowana na Twoją firmę i czy masz dostęp do strefy DNS. Bez tego zmiana dostawcy strony oznacza przestój.
• Dostęp do przekierowań 301 — Sprawdź, czy możesz ustawić przekierowanie ze starego adresu na nowy. Jeśli nie, każda zmiana struktury będzie kosztować pozycje w Google.
• Limity ruchu i transferu — Sprawdź, co się dzieje po przekroczeniu limitu odwiedzin w danym planie. To najczęstsza niespodzianka przy kampanii reklamowej.
• Koszt łączny po 24 miesiącach — Zsumuj abonament, aplikacje, dopłaty i prowizje za dwa lata. Powyżej około 250–300 zł miesięcznie porównaj tę kwotę z wdrożeniem na CMS-ie.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – Core Web Vitals
• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – dane strukturalne
• web.dev – Core Web Vitals
• PrestaShop – dokumentacja dla deweloperów