Co naprawdę znaczy „integracja z ERP, płatnościami i kurierami” w sklepie

W cenniku wykonawcy to często jedna pozycja: „integracja z ERP, płatnościami i kurierami”. W praktyce są to trzy niezależne przepływy, które spotykają się na jednym rekordzie — zamówieniu. Każdy ma inne źródło prawdy i inne tempo zmian.

• Warstwa magazynowa i produktowa (ERP) — stan, cena netto i brutto, jednostka miary, stawka VAT, waga i wymiary paczki. Zmienia się kilka razy dziennie, przy dostawie i przy sprzedaży.
• Warstwa transakcji (operator płatności) — inicjacja płatności, potwierdzenie zaksięgowania, zwrot, czasem raty lub BLIK. Zmienia się w sekundach i wymaga reakcji natychmiastowej, bo od tego zależy, czy zwolnisz towar do wysyłki.
• Warstwa logistyki (kurier) — etykieta, numer przesyłki, statusy (przyjęta, w dostawie, doręczona, awizo, zwrot), pobranie. Zmienia się w godzinach.

Między tymi systemami realnie przepływają: stany magazynowe, ceny, zamówienia z pozycjami, dane klienta i adres dostawy, faktury, etykiety i numery przesyłek, statusy doręczenia, zwroty i korekty. Pominięcie choćby jednego strumienia oznacza, że ktoś musi go domknąć ręcznie.

Integracja a eksport CSV raz na godzinę. Eksport nie jest zły — jest wystarczający, gdy masz 20–30 zamówień miesięcznie, jeden magazyn i jedną osobę, która i tak codziennie weryfikuje stany. Przestaje wystarczać, gdy sprzedajesz ten sam towar na trzech kanałach: plik generuje się o 14:00, a o 14:10 ktoś kupuje ostatnią sztukę, która już nie istnieje.

Przykład liczbowy. Sklep w Toruniu robiący 500 zamówień miesięcznie. Ręczne przepisanie danych do ERP i wystawienie faktury to ok. 2 minuty, etykieta w panelu kuriera 1,5 minuty, sprawdzenie wpłaty 1 minuta, aktualizacja statusu 0,5 minuty — razem ok. 5 minut na zamówienie. Przy 25 zamówieniach dziennie to ponad 2 godziny pracy każdego dnia, około 41 godzin miesięcznie. Do tego dochodzą pomyłki przy przepisywaniu — przy 2% błędów to 10 zamówień w miesiącu do wyjaśniania z klientem. Szerszy opis zakresu znajdziesz w materiale o tym, co obejmują integracje z ERP, płatnościami i kurierami.

Jak wygląda poprawna synchronizacja — mapowanie danych krok po kroku

Klucz łączący rekordy. Zanim cokolwiek zsynchronizujesz, ustal, po czym łączysz produkt w sklepie z towarem w ERP. Trzy kandydatury: SKU, EAN i wewnętrzne ID z ERP. SKU jest wygodne dla ludzi, ale zmienia się przy zmianie dostawcy — po zmianie SKU tracisz powiązanie i tworzysz duplikat. EAN bywa wspólny dla kilku wariantów (np. ten sam kod dla kilku rozmiarów) albo w ogóle nie istnieje dla towarów na wagę. Najstabilniejsze jest ID z ERP — dlatego w sklepie warto trzymać dodatkowe pole erp_id i mapować po nim, a SKU traktować jako pole pomocnicze.

Mapowanie pól — tu wybucha najwięcej wdrożeń. Sprawdź po kolei: jednostkę miary (ERP sprzedaje karton 12 szt., sklep sztuki), stawkę VAT (23/8/5/0 i towary zwolnione), walutę, cenę netto i brutto (ERP trzyma netto — przeliczanie i zaokrąglanie na poziomie sklepu musi być ustalone raz), stany z buforem bezpieczeństwa (np. 2 szt. zapasu, żeby nie sprzedać towaru odłożonego dla klienta stacjonarnego) oraz wagę i wymiary potrzebne do wyceny kuriera.

Kierunek przepływu. ERP jest źródłem prawdy dla stanu i ceny. Sklep jest źródłem prawdy dla zamówienia — nie odwrotnie. Zamówienie idzie do ERP, wraca z numerem dokumentu i danymi do faktury. Nie pozwól, żeby dwa systemy jednocześnie nadpisywały stan.

Częstotliwość i tryb. Płatności i nadania: webhook, reaguj od razu. Wysyłka zamówienia do ERP: kolejka z ponowieniami (retry), żeby awaria ERP nie zgubiła dokumentu. Stany: synchronizacja przyrostowa co 5–15 minut po polu daty modyfikacji plus pełna raz na dobę w nocy. Każde żądanie opisuj kluczem idempotentnym — inaczej przy ponowieniu zdejmiesz stan dwa razy. Techniczne podstawy opisujemy w sekcji o integracjach API.

Strefy czasowe i kodowanie. Trzymaj UTC w bazie i przeliczaj na Europe/Warsaw przy prezentacji; cron ustawiony na 02:30 w dniu zmiany czasu potrafi wykonać się dwa razy albo wcale. Starsze ERP nadal zapisują pliki w Windows-1250 — polskie znaki w nazwach towarów wysypują import, jeśli nie ustawisz kodowania jawnie. Dokumentacja techniczna PrestaShop dla deweloperów opisuje, jak warstwa webservice przyjmuje takie dane.

ERP pod polski e-commerce: Subiekt, Comarch Optima, WF-Mag — co sprawdzić przed wyborem

Nie ma „najlepszego ERP do sklepu”. Jest system, do którego da się bezpiecznie podłączyć. W polskich małych i średnich firmach dominują trzy rodziny: Subiekt (InsERT), Comarch Optima oraz WF-Mag z rodziny InsERT dla samej gospodarki magazynowej. Każdy z nich komunikuje się ze sklepem jedną z trzech dróg.

• Oficjalne API lub biblioteka producenta — najbezpieczniejsza droga, bo operuje na logice systemu, a nie na jego tabelach. Zwykle wymaga wykupionej licencji albo dodatkowego modułu, więc zapytaj o to wprost w cenniku producenta.
• Bezpośredni dostęp do bazy SQL — szybkie i tanie na start, ale każda aktualizacja ERP może zmienić strukturę tabel. Pracuj wyłącznie na widokach i koncie z prawem tylko do odczytu.
• Pliki wymiany (XML, CSV, EPP) — działa nawet ze starymi wersjami programów, ale wprowadza opóźnienie i jest podatne na błędy kodowania.

Wydajność. Baza ERP dzieli zasoby z księgowością. Pełne zapytanie o 20 tysięcy towarów odpalane co minutę potrafi zablokować tabelę i spowolnić wystawianie faktur. Praktyka: synchronizacja przyrostowa po polu daty modyfikacji, maksymalnie jedno zapytanie na sekundę, pełna synchronizacja w nocy. Jeśli system na to pozwala, czytaj z kopii bazy, a nie z produkcyjnej.

KSeF i faktury. Ustal, gdzie faktura ma powstać — i nie rób tego w dwóch miejscach. Jeśli dokument tworzy ERP, sklep przekazuje tylko dane zamówienia i NIP, a ERP wysyła fakturę do KSeF. Jeśli fakturę wystawia sklep, do ERP musi trafić zapis dokumentu, inaczej rozjedzie się magazyn i księgowość. Pilnuj jednego ciągu numeracji — dwie serie numerów to problem przy kontroli. Harmonogram wdrożeń KSeF był przesuwany, więc terminy weryfikuj u swojego biura rachunkowego, nie w artykule z bloga.

Pytanie kontrolne do klienta: kto administruje ERP (wewnętrzny informatyk, biuro rachunkowe, dostawca), czy dostawca systemu udostępni dokumentację integracyjną i środowisko testowe — najlepiej kopię bazy — oraz czy dostęp integracyjny wymaga dodatkowej licencji. Bez odpowiedzi na te trzy pytania wycena wdrożenia jest zgadywaniem. Podobne układy w firmach z sąsiedniego regionu opisujemy przy okazji integracji z ERP, płatnościami i kurierami w Bydgoszczy.

Płatności: BLIK, Przelewy24, PayU, Stripe, tpay — co sprawdzić przed wdrożeniem

Wklejenie klucza API to kwadrans. Reszta pracy to logika statusów. Pierwsze pytanie do wykonawcy: co zrobi system, gdy ten sam webhook przyjdzie dwa razy? Przelewy24, PayU, tpay i Stripe ponawiają notyfikację, jeśli nie dostaną odpowiedzi 200 w ciągu kilku sekund. Bez idempotencji — czyli bez zapisania identyfikatora transakcji operatora (p24_session_id, order_id w PayU, payment_intent w Stripe) i potraktowania powtórki jako duplikatu — dostaniesz dwa dokumenty w ERP, dwa maile do klienta i podwójną rezerwację towaru.

Druga rzecz: „płatność autoryzowana” to nie „płatność zaksięgowana”. Przy kartach i BLIK-u pieniądze są najpierw blokowane (auth), a rozliczane dopiero przy capture. Faktura i zwolnienie towaru do wysyłki powinny iść po zaksięgowaniu, nie po autoryzacji. To najczęstsze miejsce, w którym rozjeżdża się sklep i ERP.

• Nieudane i porzucone płatności: link do ponownej zapłaty z terminem 24–48 h oraz przypomnienie po 30 minutach i po 24 h. Ustal limit prób na jedno zamówienie, inaczej łapiesz próby fraudowe i zaśmiecasz bazę.
• BNPL i płatności częściowe: PayPo, raty, „zapłać później” — w ERP to nie jedna wpłata, a należność z saldem. Sprawdź, czy operator przekazuje pełną kwotę, czy tylko transzę i kto odpowiada za windykację.
• 3DS/SCA: testuj trzy scenariusze — challenge (klient potwierdza w banku), frictionless (bank przepuszcza bez pytania) i wyjątek dla małych kwot. Sprawdź też, co robi sklep, gdy klient zamknie okno 3DS w połowie.

Harmonogram i kolejność prac dla trzech przepływów opisujemy w materiale o integracjach z ERP, płatnościami i kurierami. Bramki w WooCommerce to wtyczki konfigurowane w panelu — punkt wyjścia znajdziesz w dokumentacji WooCommerce.

Kurierzy: InPost, DPD, DHL — etykiety, statusy, punkty odbioru

Cykl przesyłki wydaje się prosty: etykieta, odbiór, sortownia, doręczenie. Pęka zwykle w czterech miejscach.

Dane do etykiety. API InPost, DPD i DHL wymagają wagi, trzech wymiarów, wybranej usługi, kwoty pobrania wraz z opłatą za pobranie, deklaracji wartości (ubezpieczenie) i telefonu odbiorcy. Uwaga na wagę gabarytową: liczy się jako (długość × szerokość × wysokość) / 6000, u części przewoźników / 5000. Karton 40×30×20 cm to 24 000 cm³, czyli 4 kg gabarytowo — nawet jeśli realnie waży 1,2 kg. Przekroczenie limitu skrytki paczkomatu kończy się dopłatą albo odmową przyjęcia.

Mapowanie metod dostawy. Metoda w sklepie musi wskazywać jedną konkretną usługę: „Paczkomat 24/7” → paczkomat InPost, „DPD Pickup” → punkt DPD, „Kurier DPD” → DPD Classic. Numer punktu waliduj przed wystawieniem etykiety — punkt mógł zostać zamknięty między złożeniem zamówienia a pakowaniem.

Statusy zwrotne. Nie wszystkie zdarzenia są pushowane webhookiem, część usług trzeba odpytować co 15–30 minut. Mapowanie: nadana → „wysłane”, do odbioru w punkcie → „gotowe do odbioru” plus mail, doręczona → „zrealizowane” i rozliczenie pobrania, zwrot do nadawcy → „zwrot” i decyzja, czy wracamy z pieniędzmi, czy wysyłamy ponownie.

Zwroty. Etykieta zwrotna generowana z panelu klienta po numerze zamówienia, z limitem 14 dni i kosztem po stronie sklepu. Bez tego każdy zwrot obsługujesz ręcznie.

Test przed startem: wyślij 5 etykiet — paczkomat, kurier krajowy, punkt Pickup, pobranie, przesyłka zagraniczna. Sprawdź, czy status wrócił do sklepu i do ERP, czy numer listu trafił do maila i czy stan magazynowy się zgodził. Zasady łączenia systemów opisujemy w sekcji o integracjach API, a statusy zamówień w PrestaShop najlepiej mapować zgodnie z dokumentacją dla deweloperów PrestaShop.

Ile to realnie kosztuje — widełki w godzinach, nie w cenniku z sufitu

Cena „od 500 zł za integrację” nic nie mówi, bo nie wiadomo, ile godzin pracy jest w środku. Poniżej widełki z projektów dla firm MŚP — rozliczane godzinowo, nie ryczałtem z sufitu.

• Wariant A — gotowa wtyczka plus konfiguracja: 8–20 h. Sklep na PrestaShop lub WooCommerce, popularne ERP z gotowym modułem, jedna bramka płatnicza, jeden kurier. W tej cenie jest instalacja, konfiguracja kont, kilka testów i krótkie szkolenie. Nie ma tu logiki nietypowych statusów ani rozwiązywania konfliktów.
• Wariant B — moduł półwłasny: 40–90 h. Najczęstszy scenariusz w MŚP. Dwa–trzy kanały płatności, dwóch kurierów, ERP z dokumentacją API, ale z własnymi zasadami stanów. Godziny idą na mapowanie statusów, obsługę duplikatów, obsługę błędów i testy na środowisku przedprodukcyjnym.
• Wariant C — integracja pisana pod nietypowe ERP lub wiele magazynów: 100–250 h i więcej. Autorskie ERP bez dokumentacji, kilka lokalizacji, rezerwacje i kompletacja, wielowalutowość, kilka kanałów sprzedaży.

Co podnosi koszt: brak dokumentacji API (reverse engineering albo długie uzgodnienia z dostawcą systemu), nietypowe stany magazynowe, wielowalutowość i przeliczanie kursów, kilka kanałów sprzedaży (własny sklep plus marketplace), stare wersje PHP. Każdy z tych punktów dodaje zwykle 10–40 h.

Dlaczego rozliczamy się za godziny: stawka obejmuje analizę i warsztat mapowania statusów (4–8 h), development (zwykle 60–70% budżetu), testy na sandboxach operatorów, wdrożenie na produkcji w oknie nocnym, dokumentację powdrożeniową i 30 dni wsparcia po starcie. Dla sklepu z 200 zamówieniami miesięcznie, na Subiekcie GT, z Przelewy24 i dwoma kurierami realny zakres to 60–80 h — porównywalne wdrożenie opisaliśmy w materiale o integracjach z ERP, płatnościami i kurierami w Bydgoszczy.

Lista kontrolna wdrożenia — 14 punktów do odklikania przed startem

Punkt kontrolny bez dowodu to tylko dobre intencje. Zamiast pytać wykonawcę „czy to będzie działać?”, zbieraj artefakty: zrzut konfiguracji, log z testu, podpisany dokument z mapowaniem pól. Poniżej 14 punktów, które możesz odklikać niezależnie od tego, kto robi wdrożenie.

1. Środowisko testowe ERP i sklepu — działające minimum 2 tygodnie przed produkcją, na kopii bazy. Testowanie bezpośrednio na sklepie to nie test, a ryzyko.
2. Dwa komplety kluczy API — osobne dla testów i dla produkcji, dwa endpointy, dwa konta w ERP.
3. Dokument mapowania pól — nazwa pola w sklepie, nazwa w ERP, typ, maksymalna długość, czy wymagane.
4. Klucze łączące — SKU (nigdy nazwa produktu), ID zamówienia, ID transakcji płatniczej, numer przesyłki. Jeden klucz = jeden rekord.
5. Słownik statusów — tabela „status w sklepie → status w ERP → status u kuriera”, mapowanie 1:1.
6. Reguły VAT i walut — netto czy brutto, gdzie zaokrąglenie, jaki kurs dla zamówień zagranicznych.
7. Strefa czasowa — serwer sklepu, ERP i kurier w jednym standardzie (np. Europe/Warsaw), daty zapisywane z offsetem.
8. Testy na realnych danych — eksport 300–1000 prawdziwych zamówień i katalog z rzeczywistymi SKU, wagami i wymiarami. Nie 5 produktów demonstracyjnych.
9. Scenariusze brzegowe — anulowanie, zwrot, wysyłka częściowa, brak stanu, dopłata do przesyłki.
10. Test kolejki — celowe zatrzymanie workera i sprawdzenie, czy zadania wracają po retry, a nie znikają.
11. Plan rollback — procedura, kto decyduje i w jakim czasie wracacie do ręcznej obsługi.
12. Osoba dyżurująca w dniu startu — imię, numer telefonu, godziny.
13. Alerty — kolejka starsza niż 15 minut, błędy 5xx na webhooku, brak potwierdzenia płatności.
14. Zamrożenie zmian — 48 godzin przed startem żadnych aktualizacji sklepu, modułów i ERP.

Jeśli ERP wystawia dane przez webservice, pola zamówienia sprawdzisz w dokumentacji WooCommerce — porównaj je z tym, co faktycznie wysyła sklep, a nie z tym, co obiecuje wykonawca.

7 pułapek i jak je wykryć w 5 minut

Te awarie nie wyglądają spektakularnie. Sklep działa, tylko wieczorem ktoś zauważa, że w ERP brakuje kilkunastu zamówień. Poniżej siedem typowych pułapek i sposób sprawdzenia każdej z nich w kilka minut, bez wchodzenia w kod.

1. Duplikaty zamówień i faktur. Wykrycie: policz zamówienia z ostatniej doby w sklepie i dokumenty w ERP, porównaj też sumy brutto co do grosz. Każda różnica oznacza brak klucza idempotencji po stronie webhooka.
2. Rozjeżdżone stany magazynowe. Wykrycie: weź 10 losowych SKU i porównaj stan sklep vs ERP. Różnica większa niż przyjęty bufor (np. 2% albo 3 sztuki) to sygnał, że kolejka gubi zdarzenia stanowe.
3. Race condition przy dwóch zamówieniach na ostatnią sztukę. Wykrycie: dwa konta, jedna sztuka na stanie, dwa zamówienia w tej samej sekundzie. Jeśli oba przeszły — integracja tylko czyta stan, zamiast go rezerwować w ERP.
4. Zatrzymane kolejki i retry. Wykrycie: licznik zadań nieprzetworzonych starszych niż 15 minut plus logi. Jeśli liczba rośnie i nie spada, worker padł, a retry kręci się w pętli bez backoffu.
5. Timeouty webhooków płatności. Wykrycie: lista zamówień „oczekuje na płatność” starszych niż 15 minut przy potwierdzonej wpłacie u operatora. Sklep odpowiadał zbyt wolno albo zwracał 5xx.
6. Błędy jednostek, VAT i stref czasowych. Wykrycie: raz w miesiącu porównaj ręcznie 3 faktury — stawkę, netto/brutto i datę sprzedaży. Zamówienie z 23:40 łatwo wpada w inny miesiąc i inne rozliczenie.
7. Ciche wyłączenie integracji po zmianie API dostawcy. Wykrycie: sprawdź kody odpowiedzi na starych endpointach (404, 410) i subskrybuj changelog operatora. Dokumentacja deweloperska PrestaShop pokazuje, że endpointy i struktury bywają wersjonowane — po aktualizacji trzeba je przetestować, a nie założyć, że działa.

Praktyka z wdrożeń: integracje z ERP, płatnościami i kurierami w Bydgoszczy najczęściej padają nie na etapie pisania kodu, ale przy pierwszej zmianie po stronie dostawcy. Warto mieć na to procedurę, nie nadzieję.

Opieka po wdrożeniu: SLA, monitoring i co powinno być w umowie

Integracja po starcie jest jak instalacja elektryczna — nikt o niej nie myśli, dopóki nie zgaśnie światło. Różnica jest jedna: prąd włącza się po minucie, a kolejkę zamówień odtwarza się godzinami. Dlatego w umowie powinny znaleźć się cztery rzeczy.

Monitoring z alertem, nie dashboard. Dashboard, na który nikt nie patrzy, nie jest monitoringiem. Alert ma przyjść na telefon, zanim klient napisze „nie dostałem potwierdzenia”. Minimalny zestaw progów: zadanie w kolejce starsze niż 15 minut, jakikolwiek błąd 5xx na webhooku płatności, brak potwierdzenia wpłaty 10 minut po zamówieniu, brak etykiety kurierskiej 30 minut po zmianie statusu na „do wysyłki”.

Czas reakcji to nie czas naprawy. W umowie rozdziel oba pojęcia. Reakcja: potwierdzenie przyjęcia zgłoszenia w ciągu 1 godziny w godzinach 8–18. Naprawa incydentu krytycznego: 4 godziny. Obejście tymczasowe (np. ręczne wystawianie etykiet): do 24 godzin. Incydent krytyczny w sklepie to dokładnie: nie da się złożyć zamówienia, płatności nie księgują się, nie da się wygenerować etykiet albo ceny i stany rozjeżdżają się masowo.

Dostęp do dewelopera, który pisał integrację. Jeśli między tobą a autorem kodu stoi pośrednik, każde zgłoszenie nabiera jednego–dwóch dni opóźnienia na przekazanie kontekstu. W szczycie sezonu to tysiące złotych. W umowie wpisz prawo do rozmowy z autorem i obowiązek przekazania dokumentacji mapowania pól.

Utrzymanie kontra przestój. Koszt godziny przestoju policz na własnych danych: liczba zamówień na godzinę × średnia wartość zamówienia × marża, plus koszt obsługi reklamacji i zwrotów. Porównaj to z roczną opieką — dopiero wtedy widać, czy warto oszczędzać. Kiedy dokupić rozwój? Gdy pojawia się nowy kurier albo nowy kanał sprzedaży — wyceniaj za punkty (kontrakt API, mapowanie statusów, etykieta, testy), nie za „pakiet”. Zamawiaj poza sezonem. Kontekst techniczny rozwijamy w sekcji o integracjach API.

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

Lista kontrolna do odklikania

• Administrator ERP i dostęp do dokumentacji — Ustal, kto administruje systemem i czy dostawca udostępni dokumentację API oraz środowisko testowe. Bez tego wdrożenie zamienia się w zgadywanie.
• Kanał komunikacji z ERP — Zapytaj, czy integracja pójdzie przez oficjalne API, bezpośredni dostęp do bazy SQL, czy pliki wymiany (XML/CSV/EPP). Każda droga ma inne ryzyko i inny koszt utrzymania.
• Klucz łączący rekordy — Sprawdź, czy dane w sklepie i ERP mają spójny SKU lub EAN. Przetestuj to na 20–30 produktach z różnych kategorii, zanim ruszysz z całością.
• Bufor stanów magazynowych — Ustal, ile sztuk ma być odejmowane od stanu realnego i od jakiego poziomu produkt staje się niedostępny w sklepie.
• Ceny netto i brutto oraz VAT — Zweryfikuj, w jakiej formie ceny są przechowywane w ERP i jak przeliczane w sklepie. Błąd w tym miejscu kosztuje więcej niż całe wdrożenie.
• Kierunek przepływu danych — ERP jest źródłem prawdy dla stanu i ceny, sklep dla zamówienia i danych klienta. Zapisz to wprost w umowie, żeby uniknąć nadpisywania danych w obie strony.
• Miejsce wystawiania faktury i KSeF — Zdecyduj, gdzie powstaje dokument i jak trafia do KSeF. Sprawdź, czy sklep nie wystawia równolegle własnej faktury.
• Idempotencja powiadomień o płatności — Zapytaj, co się stanie, gdy ten sam webhook dotrze dwa razy. Poproś o test: ręczne wysłanie powtórzonego powiadomienia na środowisku testowym.
• Mapowanie statusów płatności — Ustal różnicę między płatnością autoryzowaną a zaksięgowaną i przypisz oba stany do konkretnych statusów zamówienia w sklepie i ERP.
• Płatności odroczone i częściowe — Sprawdź, jak system rozpozna płatność odroczoną (BNPL) lub częściową wpłatę i czy nie zostanie potraktowania jako zamówienie nieopłacone.
• Metody dostawy a usługi kuriera — Zmapuj każdą metodę w sklepie na konkretną usługę u kuriera (paczkomat, punkt odbioru, kurier, pobranie) i przetestuj etykietę dla każdej z nich.
• Waga i gabaryty do etykiety — Ustal, skąd biorą się wymiary i waga przesyłki oraz co się dzieje, gdy dane w kartotece produktu są niekompletne.
• Statusy zwrotne i zwroty — Sprawdź, czy statusy „nadana”, „doręczona”, „do odbioru” i „zwrot do nadawcy” automatycznie zmieniają status zamówienia i czy zwrot wraca jako korekta stanu do ERP.
• Monitoring i logi — Ustal, kto i jak zauważy, że synchronizacja padła — alert po błędzie, codzienny raport rozjazdów, kontakt do osoby odpowiedzialnej.

Najczęściej zadawane pytania

Źródła i materiały

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