Sklep WooCommerce 'na Kraków' — co to właściwie znaczy

Fraza „sklepy WooCommerce Kraków” ma dwa znaczenia. Pierwsze: szukasz firmy z siedzibą w Krakowie. Drugie: szukasz sklepu, który poprawnie obsłuży klientów z Krakowa i Małopolski. To drugie kryje się za wyszukiwaniem najczęściej — i ono ma realne przełożenie na sprzedaż.

WooCommerce nie nakłada żadnych ograniczeń geograficznych. Instalacja stoi na hostingu, na którym stoi, i sprzedaje do dowolnego regionu. Siedziba w Krakowie nie daje więc przewagi technicznej. Daje przewagę operacyjną: krótszą drogę przy zwrotach, możliwość własnej dostawy, obsługę odbiorów osobistych i szybszą reakcję przy reklamacjach.

Co realnie zmienia lokalizacja:

• Strefy wysyłki (WooCommerce → Ustawienia → Wysyłka → Strefy wysyłki) — osobna strefa dla kodów 30-xxx i 31-xxx, osobna dla 32-xxx.
• Punkty odbioru — gęstość paczkomatów w Krakowie jest wysoka, więc klient oczekuje wyboru punktu, a nie tylko adresu.
• Czas dostawy — przy wysyłce do godziny 12:00 dostawa na następny dzień w Krakowie jest realna, nie deklaratywna.
• Lokalne SEO — frazy typu „[branża] Kraków”, podstrony lokalne i dane strukturalne. Google Search Central opisuje, które typy znaczników obsługuje w wynikach wyszukiwania.
• Przewaga sklepu stacjonarnego — jeśli masz punkt w Krakowie, odbiór osobisty to argument, którego nie przebije żaden kurier.

Kraków jest jednym z największych rynków e-commerce w Polsce. Nie podajemy tu konkretnej liczby, bo publiczne raporty różnią się metodologią i rokiem badania — sięgnij po dane ze źródła, które podaje próbę i zakres.

WooCommerce wygrywa przy katalogu do ~500 SKU, prostych wariantach i standardowych integracjach. Przy 2000+ SKU, rozbudowanych wariantach i logice B2B sensowniejszy bywa PrestaShop — porównanie z wdrożeniem PrestaShop pokazuje, gdzie kończy się wygoda WooCommerce. Kolejność prac przy samym wdrożeniu WooCommerce jest identyczna dla każdego miasta, zmienia się tylko mapa dostaw.

Ile kosztuje sklep WooCommerce — realne widełki 2025

Nie ma jednej ceny sklepu WooCommerce. Jest liczba godzin pomnożona przez stawkę. W polskich agencjach stawka za pracę nad WooCommerce w 2025 roku mieści się zwykle w przedziale 120–200 zł netto za godzinę. Doświadczony freelancer: 80–150 zł/h. To punkt wyjścia do każdej rozmowy o budżecie.

W roboczogodziny wchodzi zawsze: konfiguracja hostingu, SSL, WordPressa i WooCommerce, kopia zapasowa; instalacja i szablonowanie motywu; struktura katalogu, import produktów, warianty, kategorie i filtry; metody płatności (Przelewy24 lub PayU, BLIK, karta, pobranie, przelew); metody wysyłki, integracja Paczkomatów, kurierzy, etykiety; strony informacyjne, regulamin, polityka prywatności; testy mobilne, wydajność, Core Web Vitals; szkolenie i dokumentacja.

Wysyłka do Krakowa i Małopolski: InPost, DPD, DHL

Konfigurację zaczynasz w WooCommerce → Ustawienia → Wysyłka → Strefy wysyłki. Pierwszy błąd to jedna strefa „Polska” na cały kraj. Powinny być co najmniej trzy: Kraków, Małopolska i reszta Polski. Strefa krakowska rozpoznaje kody 30-xxx i 31-xxx, małopolska — 32-xxx.

Płatności: BLIK, Przelewy24, PayU, karty — jak nie stracić koszyka

Kolejność metod w koszyku ustawiasz przeciąganiem w WooCommerce → Ustawienia → Płatności. Praktyczny układ: BLIK, karta, szybki przelew (Przelewy24, PayU), a na końcu przelew tradycyjny. Metody, których nie obsługujesz — czek, płatność przy odbiorze dla wysyłek kurierskich — po prostu wyłącz. Każda dodatkowa opcja to jedno pytanie więcej i jedna okazja, żeby klient wyszedł z koszyka.

Prowizje policz przed wdrożeniem, nie po. Operator liczy zwykle procent od transakcji, czasem plus opłatę za wypłatę środków. Przykład: koszyk 149 zł i prowizja 1,5% to 2,24 zł. Przy 800 zamówieniach miesięcznie daje to około 1,8 tys. zł. Różnica 0,3 p.p. między operatorami to już ponad 350 zł miesięcznie. Stawki negocjuje się wolumenem, a nie przyjmuje z cennika — jeśli chcesz porównać to z resztą budżetu, rozkładamy go w artykule o tym, ile realnie kosztuje wdrożenie sklepu.

Webhooki to miejsce, w którym ginie najwięcej zamówień. Klient płaci, wraca na stronę, a w panelu widzisz status pending. Najczęstsze przyczyny:

• powiadomienie zwrotne (IPN/notify) blokuje firewall lub WAF na hostingu — sprawdź, czy operator dostaje odpowiedź 200, a nie 403;
• URL powiadomień nadal wskazuje na adres serwera testowego po migracji;
• wtyczka płatności nie została zaktualizowana po zmianie API operatora.

Diagnostykę zaczynasz od WooCommerce → Status → Logi i panelu operatora. Trwałe rozwiązanie to cron, który po 10 minutach dopytuje operatora o status i sam przestawia zamówienie na „przetwarzane”.

Faktury wystawiaj po statusie „przetwarzane”, nigdy po „oczekiwanie na płatność” — inaczej system księgowy generuje dokumenty do zamówień, które nigdy nie zostały opłacone. Integracje (Fakturownia, inFakt, wFirma, Subiekt) łączy się przez API z regułą „wystaw po zmianie statusu”. KSeF: harmonogram obowiązkowego e-fakturowania był przesuwany, więc termin i zakres dla Twojej firmy potwierdź u księgowego przed wyborem wtyczki.

Pułapka numer jeden: brak obsługi nieudanej płatności. Klient, któremu bank odrzucił transakcję, zostaje z pustym koszykiem i bez żadnej wiadomości — WooCommerce domyślnie powiadamia administratora, nie kupującego. Skonfiguruj mail z linkiem do ponownej płatności (endpoint /checkout/order-pay/{ID}/?pay_for_order=true&key=...) oraz wtyczkę odzyskującą porzucone koszyki.

Hosting i wydajność: żeby sklep nie mulił w Krakowie ani nigdzie indziej

Shared hosting wystarcza małemu sklepowi: do około 100 zamówień i 5 tys. wizyt miesięcznie, katalog poniżej 500 produktów, kilkanaście wtyczek. Powyżej tego progu zaczynają się objawy, które trudno przypisać do jednej przyczyny: panel administracyjny otwiera się po 5–8 sekund, publikacja produktu kończy się timeoutem, a w szczycie sezonu baza zamówień blokuje całą stronę. Pierwszy sensowny przeskok to VPS: 4 vCPU, 8 GB RAM, dysk NVMe, PHP 8.2/8.3 z OPcache i MySQL 8 lub MariaDB 10.6+.

Zanim dołożysz kolejne GB pamięci, włącz w WooCommerce HPOS (High-Performance Order Storage) — zamówienia przenoszą się z tabeli postmeta do dedykowanych tabel i przy kilku tysiącach zamówień różnicę widać gołym okiem. Sprawdź tylko zgodność wtyczek w sekcji Status.

Object cache (Redis) włączasz wtedy, gdy wąskim gardłem jest baza: katalog z filtrami i koszyki zalogowanych klientów generują setki zapytań na jedno żądanie. Cache stron to inna sprawa — musi omijać /koszyk, /zamowienie, /moje-konto oraz ciastka woocommerce_items_in_cart i wp_woocommerce_session_*. Bez tego klient po dodaniu produktu zobaczy pusty koszyk, a przy błędnie ustawionym Varnishu — koszyk innej osoby.

Core Web Vitals mierz na danych rzeczywistych, nie w Lighthouse: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1 na 75. percentylu. Dane znajdziesz w Search Console i w PageSpeed Insights w sekcji „Dane użytkowników”. Największy zysk daje konwersja zdjęć do WebP lub AVIF — to typowo 25–35% mniej bajtów przy porównywalnej jakości. Nie lazy-loaduj zdjęcia LCP i dodaj mu fetchpriority="high".

Hosting w USA bez CDN to dodatkowe kilkadziesiąt do około 150 ms na każde połączenie; przy kilkudziesięciu żądaniach i kilku rundach DNS/TCP/TLS robią się z tego sekundy. I ostatnia rzecz: kopia zapasowa trzymana na tym samym VPS to nie kopia. Baza i pliki powinny lecieć codziennie do zewnętrznego storage (S3, Backblaze B2), z retencją 30 dni i testem odtworzenia raz na kwartał. Co jeszcze warto uszczelnić, opisujemy w tekście o administracji serwerami w Krakowie i błędach, które kosztują.

SEO lokalne dla sklepu obsługującego Kraków

Frazy lokalne, które realnie konwertują, są konkretne: „sklep [kategoria] Kraków”, „dostawa tego samego dnia Kraków”, „wysyłka 24h Kraków”, plus nazwy dzielnic — Nowa Huta, Podgórze, Krowodrza, Dębniki, Prądnik — w opisie strefy dostawy i punktów odbioru. Nie upychaj „Kraków” w każdym zdaniu. Lepiej raz, ale z informacją, której klient szuka: od jakiej kwoty dostawa jest darmowa, ile trwa realizacja do kodów 30- i 31-, gdzie są punkty odbioru.

Google Business Profile ma sens także bez sklepu stacjonarnego, ale tylko jeśli realnie obsługujesz klientów z Krakowa. Ustawiasz profil jako „obszar działania”, ukrywasz adres i wskazujesz zasięg (np. Kraków i 30 km wokół). Jeśli prowadzisz odbiór osobisty, pokaż adres i godziny — bez tego Google nie ma podstaw, żeby traktować Cię jako firmę lokalną.

Dane strukturalne: Product z Offer (cena, waluta, dostępność) to podstawa, bo to one dają cenę i status dostępności w wynikach. AggregateRating dodawaj wyłącznie przy realnych opiniach — fałszywe oznaczenia kończą się ręcznym działaniem. LocalBusiness lub Store tylko wtedy, gdy masz punkt obsługi klienta. Waliduj wszystko w Rich Results Test i pilnuj raportu wzbogaconych wyników w Search Console; Google pokazuje wyłącznie znaczniki zgodne ze specyfikacją (dane strukturalne obsługiwane przez Google).

Treści lokalne trzymaj na stronie kategorii (300–600 znaków nad lub pod listą produktów) oraz na osobnej stronie o dostawie. Nie twórz strony „sklep [kategoria] Kraków”, która dubluje kategorię — to prosta droga do kanibalizacji. Opis producenta możesz wykorzystać jako specyfikację, ale dopisz własne 2–3 zdania. Warianty produktu (rozmiar, kolor) potrzebują odrębnych opisów albo canonicala na wariant główny.

Linkowanie wewnętrzne: z artykułu poradnikowego prowadź 2–4 linki do kategorii i konkretnych produktów, z opisową kotwicą („kurtki puchowe z dostawą w Krakowie”), nigdy „zobacz więcej”. Te same zasady sprawdzają się przy wdrożeniu sklepu WooCommerce w Warszawie — zmienia się tylko mapa dostaw.

Migracja z innej platformy do WooCommerce — kolejność kroków

Migracja z PrestaShop, Shopera czy autorskiego CMS-a do WooCommerce ma jedną wspólną zasadę: dane traci się nie na etapie kopiowania produktów, a na etapie adresów URL i wariantów. Dlatego kolejność prac jest sztywna.

1. Audyt starego sklepu (1–3 dni). Eksport produktów, klientów, zamówień i treści (kategorie, opisy, blog, strony statyczne) plus pełna lista adresów URL — z sitemap.xml i z crawla (Screaming Frog w wersji darmowej obsłuży do 500 adresów). Zapisz, które URL-e mają ruch i linki zewnętrzne. Import pliku CSV w WooCommerce ma konkretny wymóg: kolumny muszą odpowiadać nazwom pól produktu, więc surowy eksport z innej platformy i tak trzeba przemapować — opisuje to dokumentacja WooCommerce (https://woocommerce.com/documentation/woocommerce/).
2. Mapowanie SKU i wariantów. Tu ginie najwięcej danych. Jeśli w starym sklepie wariant był osobnym produktem („Koszulka M”), a w WooCommerce ma być variation w produkcie zmiennym, import 1:1 rozsypie stany magazynowe i zdjęcia. Przygotuj arkusz: stare ID/SKU → nowe SKU → typ (prosty/zmienny) → atrybuty. Sprawdź duplikaty i puste SKU — WooCommerce je przyjmie, ale kolejne aktualizacje stanów będą trafiać w zły produkt.
3. Przekierowania 301 z każdego starego URL-a. Arkusz mapowania: stary URL → nowy URL → 301. Zasada: produkt → produkt, kategoria → kategoria, a gdy odpowiednika nie ma — na najbliższą kategorię lub wyniki wyszukiwania, nigdy hurtem na stronę główną. Wgraj przekierowania wtyczką (np. Redirection) lub w .htaccess i przetestuj losowo 20–30 adresów.
4. Testy na stagingu przed przełączeniem DNS. Płatności w trybie piaskowym, wysyłka (Kraków 30-xxx i 31-xxx, punkty odbioru, koszt przy różnych progach), e-maile transakcyjne, faktury.
5. Okno migracji. Najniższy ruch — zwykle niedziela 2:00–5:00. Zamroź zamówienia w starym sklepie i zrób eksport różnicowy z tego okna.
6. Monitoring po starcie (14 dni). Logi 404 w Search Console i na serwerze, raport indeksacji, ręczny test koszyka i checkoutu na Androidzie, iPhonie, desktopie i w trybie incognito.

Dalsza część procesu — konfiguracja, strefy dostaw, integracje — wygląda identycznie jak w naszej liście kroków dla Łodzi: organizacja wdrożenia WooCommerce krok po kroku.

Utrzymanie i opieka techniczna: co powinno być w SLA

Wdrożenie kończy się w dniu startu. Od tego momentu sklep pracuje 24/7 i to opieka decyduje, czy w Black Friday koszyk się nie wysypie. Sensowna umowa SLA ma sześć konkretnych punktów — nie trzydzieści stron ogólników.

1. Aktualizacje. WordPress, WooCommerce i PHP — raz w miesiącu, krytyczne łatki bezpieczeństwa w 48–72 h od publikacji. Wtyczki aktualizuj partiami po 2–3, najpierw na stagingu, nigdy wszystkie na produkcji w piątek po południu. Po każdej zmianie test: dodanie do koszyka, przejście checkoutu, e-mail z zamówieniem, logowanie do panelu.
2. Monitoring dostępności. Sprawdzanie co 1–5 minut (UptimeRobot, Better Stack). W SLA rozdziel czas reakcji (kiedy człowiek potwierdzi awarię) od czasu naprawy (kiedy sklep znowu sprzedaje). Realnie: reakcja 30–60 min w godzinach pracy, naprawa 4–8 h. Bez tego rozróżnienia SLA jest fikcją — podpisujesz zobowiązanie, którego nikt nie mierzy.
3. Backupy. Baza, pliki i konfiguracja — minimum raz dziennie, retencja 30 dni, kopia poza serwerem produkcyjnym (inny dostawca albo storage S3). Raz na kwartał test odtworzenia na stagingu. Nieodegrany backup nie jest backupem.
4. Bezpieczeństwo. WAF przed sklepem, limit prób logowania (np. 5 na 15 minut), 2FA dla administratorów, wyłączony XML-RPC, skanowanie malware. W umowie musi być jasne, kto za to odpowiada — Ty czy wykonawca.
5. Raport miesięczny. Jedna strona: uptime, Core Web Vitals, liczba zamówień versus błędy checkoutu, wykonane aktualizacje, incydenty i czas reakcji. Nie lista commitów z repozytorium.
6. Cena. Orientacyjne widełki rynkowe w Polsce: mały sklep (do ~200 produktów, jedna płatność) 300–700 zł netto/mc; średni (2–3 tys. produktów, kurierzy, kilka płatności, magazyn) 800–2000 zł; rozbudowany (wielojęzyczny, B2B, ERP, własne moduły) 2500–6000 zł i wyżej. To widełki, nie wycena — ostateczna zależy od liczby wtyczek i integracji.

Jak opieka składa się na cały budżet projektu, rozpisaliśmy w tekście o cenach sklepów internetowych w 2025. Jeśli sklep stoi na własnym serwerze, przed podpisaniem SLA przejdź też checklistę błędów w administracji serwerami.

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

Lista kontrolna do odklikania

• Strefy dostaw — Sprawdź w Ustawienia → Dostawa, czy kody 30-xxx i 31-xxx mają własny cennik i próg darmowej dostawy. Weryfikuj przy każdej zmianie cennika kuriera.
• Waga i wymiary SKU — Zważ próbkę produktów z opakowaniem i porównaj z kartą produktu. Powtórz po każdej zmianie opakowań.
• Mapka InPost — Przejdź ścieżkę zakupu na telefonie: punkt musi dać się wybrać przed podsumowaniem, a koszyk nie może przepuścić zamówienia bez wybranego punktu.
• Limity punktów odbioru — Sprawdzaj przed Black Friday i świętami — wtedy punkty zapełniają się najszybciej i najczęściej wracają błędy.
• Kolejność płatności — BLIK i szybki przelew na górze, przelew tradycyjny na końcu. Sprawdź po każdej aktualizacji pluginu płatności.
• Webhooki i statusy — Testowe zamówienie każdą metodą raz w miesiącu — status powinien zmieniać się automatycznie, bez ręcznego klikania.
• Etykiety i powiadomienia — Wygeneruj etykietę testową i sprawdź, czy klient dostaje mail lub SMS z numerem przesyłki i linkiem do śledzenia.
• Próg darmowej dostawy — Sprawdź, czy przy zamówieniu łączącym tanie i drogie produkty nie robi się luka w marży. Przelicz po każdej zmianie cennika.
• Dostawa lokalna po Krakowie — Policz koszt kilometra i czasu kierowcy. Wdrażaj tylko wtedy, gdy dziennie zbiera się sensowna liczba zamówień z miasta.
• Wersje PHP i kopie zapasowe — Ustal, kto aktualizuje WooCommerce i pluginy oraz kiedy robicie kopię przed aktualizacją. Temat rozwijamy w artykule o administracji serwerami w Krakowie.
• Dane strukturalne — Sprawdź, czy produkt i dane firmy mają poprawne znaczniki. Lista obsługiwanych typów: Google Search Central – dane strukturalne.
• Core Web Vitals — Zmierz LCP i INP po wdrożeniu szablonu oraz po dodaniu mapki InPost — mapka potrafi wyraźnie spowolnić kartę produktu. Progi opisuje web.dev – Web Vitals.
• Aktualizacje szablonu — Sprawdź, czy motyw był aktualizowany w ostatnich miesiącach. Porzucone szablony łamią koszyk po aktualizacji WooCommerce.
• Kontakt i zwroty — Ustal, kto odpowiada na maile i w jakim czasie. Klient z Krakowa może chcieć oddać towar osobiście — przygotuj procedurę.

Najczęściej zadawane pytania

Źródła i materiały

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