PrestaShop offline — trzy sytuacje ukryte pod jednym hasłem

Hasło „prestashop offline” opisuje trzy różne sytuacje. Rozpoznanie własnej zajmuje minutę i oszczędza najwięcej czasu.

• Wariant A — środowisko lokalne. Deweloper albo agencja pracuje nad sklepem na własnym komputerze, bez dostępu do produkcji. Klienci nic nie widzą, sklep produkcyjny działa normalnie. Potrzebny jest stack PHP + MySQL i kopia bazy, a nie przycisk w panelu.
• Wariant B — świadome wyłączenie sklepu dla klientów. Tryb konserwacji w Parametry zaawansowane > Wydajność (PS 1.7 i 8) albo tryb katalogowy w Parametry sklepu > Ustawienia produktu, gdy oferta ma być widoczna, ale bez sprzedaży. To twoja decyzja i cofasz ją w kilka sekund.
• Wariant C — awaria. Sklep przestał odpowiadać, pojawia się błąd 500 albo 503, którego nikt nie zaplanował. Wtedy nie klikasz „wyłącz sklep” — najpierw sprawdzasz logi PHP i serwera WWW.

Najczęstszy błąd to mylenie konserwacji ze środowiskiem lokalnym. Ktoś włącza tryb konserwacji, żeby „przetestować szablon”, zapomina o nim na dwa tygodnie i dziwi się spadkowi ruchu z Google. Tryb konserwacji oznacza, że serwer zwraca kod 503 — zgodnie z semantyką HTTP to stan tymczasowy, ale utrzymywany tygodniami przestaje być neutralny dla widoczności w wyszukiwarce (RFC 9110 — znaczenie kodu 503). Środowisko lokalne nie generuje ruchu publicznego, więc nie ma czego odkręcać.

Zanim włączysz konserwację, ustal kto ma dostęp do podglądu (pole adresów IP konserwacji), czy trwają kampanie reklamowe kierujące na sklep i kto poinformuje klientów B2B. Adres IP z domu zmienia się przy restarcie routera — wpisana raz whitelista przestaje działać i tracisz podgląd frontu. Jeśli szukasz miejsca na całość prac — wdrożenie, przenosiny, utrzymanie — zacznij od przeglądu usług PrestaShop w DropDigital.

Instalacja PrestaShop lokalnie od zera — krok po kroku

Instalacja lokalna to trzy decyzje podjęte przed pierwszym kliknięciem: stack, wersja PHP i baza.

• Stack. Laragon na Windows daje PHP, MySQL i wirtualne hosty .test niemal jednym kliknięciem. XAMPP i MAMP startują szybciej, ale mają przypięte wersje PHP, a ich wymiana bywa ręczna. DDEV albo Docker z osobnymi kontenerami PHP-FPM i MySQL jest najbliżej produkcji i sprawdza się, gdy sklep używa nietypowych rozszerzeń.
• Wersja PHP. PrestaShop 8.x i PrestaShop 9 mają różne wspierane zakresy — PS 9 podnosi minimum do PHP 8.1. Przed stawianiem środowiska sprawdź aktualne wymagania w dokumentacji deweloperskiej PrestaShop. Zbyt nowa wersja PHP kończy się białym ekranem już w instalatorze.
• Baza. MySQL 8 lub MariaDB 10.6+, kodowanie utf8mb4, użytkownik lokalny z hasłem innym niż produkcyjne, nazwa bazy np. sklep_local.

Kroki: pobierz paczkę, rozpakuj do katalogu projektu, wejdź w przeglądarce na adres vhosta. W instalatorze podaj host 127.0.0.1, port 3306, nazwę bazy, użytkownika i hasło, zostaw prefiks ps_. Konto administratora ustaw inne niż na produkcji.

Gdy instalator zwróci błąd połączenia, otwórz app/config/parameters.php. Sprawdzasz klucze database_host, database_port, database_name, database_user, database_password, database_prefix. Najczęstsze pomyłki: wpisanie mysql zamiast 127.0.0.1 poza Dockerem i odwrotnie — w Dockerze hostem jest nazwa usługi z docker-compose.yml, nie localhost — oraz pominięty niestandardowy port.

Zwiąż usługi do 127.0.0.1, żeby środowisko nie było widoczne w sieci lokalnej. W Dockerze to zapis 127.0.0.1:8080:80 w sekcji ports i brak publikacji portu MySQL na 0.0.0.0. Kopia bazy produkcyjnej na laptopie zawiera dane osobowe klientów — MySQL wystawiony na firmowe Wi-Fi to realny wyciek. Do debugowania użyj trybu debug w Parametry zaawansowane > Wydajność.

Czego instalacja lokalna nie sprawdzi: wydajności hostingu (NVMe, OPcache, liczba procesów PHP-FPM, czas odpowiedzi), konfiguracji SMTP (mail z localhosta nie wyjdzie — podstaw Mailpit albo MailHog) ani integracji płatniczych i kurierskich, bo potrzebują publicznego adresu dla webhooków. Dotyczy to również integracji InPost w PrestaShop 9, gdzie statusy przesyłek wracają na publiczny URL.

Klon produkcyjnego sklepu na komputer: dump bazy, pliki, podmiana URL

Kolejność ma znaczenie: baza, pliki, parametry, adresy URL, cache. Odwrotna kolejność kończy się błędem 500 przy pierwszym wejściu na front.

1. Zrzut bazy. mysqldump --single-transaction --quick --default-character-set=utf8mb4 -u user -p nazwa_bazy > produkcja.sql. Opcja --single-transaction nie blokuje tabel InnoDB, więc sklep działa dalej.
2. Pliki. rsync -a --exclude 'var/cache' --exclude 'var/logs' --exclude 'img/tmp' --exclude '.git' produkcja/ kopia/. Cache i logi z produkcji to śmieci, które potrafią nadpisać świeżo wygenerowane pliki.
3. Import. mysql -u root -p kopia_lokalna < produkcja.sql. Przy dumpach powyżej 100 MB phpMyAdmin się wykłada.
4. parameters.php. Popraw dane bazy oraz cookie_key i cookie_iv. Bez tego ciasteczka sesji z produkcji potrafią zalogować do kopii, a kopii — do produkcji.
5. Adresy w bazie. W ps_configuration klucze PS_SHOP_DOMAIN i PS_SHOP_DOMAIN_SSL, w ps_shop_url kolumny domain, domain_ssl, physical_uri. W multi-shopie to osobny wiersz dla każdego sklepu.
6. Search-replace z serializacją. Zwykłe „zamień wszystko” w SQL psuje dane serializowane — w serializacji zapisana jest długość łańcucha, więc po skróceniu domeny PHP nie odczyta tablicy z konfiguracji modułu. Użyj narzędzia przeliczającego długości (klasyka: Search-Replace-DB) i przejrzyj ps_configuration oraz ps_module.
7. .htaccess i cache. Usuń plik .htaccess i przegeneruj go, przełączając przyjazne URL dwa razy. Wyczyść cały katalog var/cache, włącznie z var/cache/dev i var/cache/prod.

Stary adres najczęściej zostaje w treściach CMS (ps_cms_lang), opisach produktów i kategorii (ps_product_lang, ps_category_lang), szablonach maili w katalogu mails/, blokach linków w modułach i feedach XML. Przejrzyj je przed testami, bo literówka w linku wygląda potem jak błąd modułu. Jeśli kopia ma służyć do zmian w kodzie, pracuj na nadpisywaniu kodu bez modyfikowania rdzenia — łatwiej przenieść takie zmiany na produkcję.

Czego nie wolno uruchamiać na kopii lokalnej

Kopia lokalna to pełna baza produkcyjna: prawdziwe zamówienia, prawdziwe adresy e-mail, prawdziwe klucze API. Dopóki nie odetniesz kilku rzeczy, pierwsze uruchomienie działa na żywym organizmie, nie na teście. Oto lista, którą przechodzisz, zanim klikniesz „Zapisz”.

• Moduły płatności z kluczami produkcyjnymi. PayU, Przelewy24, Stripe i PayPal trzymają dane w bazie, więc kopiujesz je razem z nią. Nieostrożny test kończy się realną autoryzacją na karcie klienta albo chaosem w webhookach produkcji. Wyłącz moduł płatności w panelu, podmień klucze na sandbox i ustaw adres sklepu na localhost, żeby żadne powiadomienie nie poszło na produkcyjny endpoint.
• Wysyłka maili. PrestaShop domyślnie wysyła wiadomości funkcją mail() PHP. W Zaawansowane → E-mail wyłącz wysyłkę albo — lepiej — przekieruj SMTP na lokalny serwer testowy (MailHog, Mailpit, port 1025). Widzisz wtedy każdy mail, a żaden nie leci do klienta.
• Moduły kurierskie. InPost, DPD i DHL po zmianie statusu zamówienia potrafią wygenerować list przewozowy i pobrać numer z realnego konta. Efekt: płacisz za przesyłkę, która nigdy nie wyjedzie. Wyłącz moduł i usuń dane dostępowe — kontekst wdrożenia: InPost w PrestaShop krok po kroku.
• Crony, webhooki i feedy. Zadania cron mogą wypchnąć stany magazynowe, feed nadpisać ceny w Merchant Center, a piksel wysłać zdarzenie z lokalnego adresu. Na czas testów wyłącz crony i moduły integracji — o tym, co w tych integracjach ma sens, piszę w Facebook w PrestaShop: co wdrożyć, a co odpuścić.
• RODO. Kopia bazy to dane osobowe klientów. Trzymaj ją na dysku szyfrowanym, bez publicznego dostępu z internetu (żadnego wystawionego IP ani otwartego phpMyAdmina), a po zakończeniu testów usuń kopię i snapshoty maszyny.
• Override, nie core. Poprawki rób w override. Zmiana w pliku core przepadnie przy najbliższej aktualizacji — jak to zrobić bez błędów: PrestaShop override.

Tryb konserwacji w PrestaShop: jak wyłączyć sklep dla klientów

Tryb konserwacji to jedyny wariant offline, który sam włączasz i sam wyłączasz. Warto zrobić to tak, żeby klient wiedział, co się dzieje, a wyszukiwarka nie uznała sklepu za zamknięty na stałe.

Gdzie to jest. W PrestaShop 1.7 i 8: Ustawienia sklepu → Ogólne → sekcja Konserwacja. W 1.6 nazwa i położenie zakładki są inne — jeśli nie widzisz sekcji w Ogólnych, przejrzyj zakładki Preferencji i szukaj po słowie „Konserwacja”, a nie po ścieżce z tutoriala.

Lista adresów IP. Pole przyjmuje jeden adres na linię. Swoje IP sprawdzisz w kilka sekund, wpisując w wyszukiwarce „moje IP” albo uruchamiając komendę curl ifconfig.me. Bez tego wpisu stronę serwisową zobaczysz także Ty — back office działa, front nie. Uwaga na łącza ze zmiennym IP: po restarcie routera adres się zmienia i tracisz dostęp do frontu, a przy dłuższych pracach wygodniej pracować przez VPN ze stałym adresem.

Kod odpowiedzi. Front powinien zwracać 503 Service Unavailable z nagłówkiem Retry-After, który mówi robotom, kiedy wrócić (definicja w RFC 9110). Sprawdź to jednym poleceniem: curl -I https://twojsklep.pl — w pierwszej linii masz kod.

Kod odpowiedzi	Co komunikuje	Kiedy ma sens
503 + Retry-After	Sklep tymczasowo niedostępny, wróci o wskazanym czasie	Planowana konserwacja
200	Strona działa normalnie	Nigdy w trybie offline — treść o przerwie może zostać zaindeksowana
404	Nie ma tu nic na stałe	Usunięta strona, nie przerwa techniczna
302	Przekierowanie	Zmiana adresu URL, nie wyłączenie sklepu

Strona serwisowa. Domyślny szablon (themes/twoj-motyw/maintenance.tpl) warto podmienić na własny: powód przerwy, data powrotu, telefon i e-mail. Klient, który widzi tylko logo i „przerwa techniczna”, idzie do konkurencji, a nie czeka.

Czego nie robić. Nie blokuj całego serwisu w robots.txt i nie wyłączaj sitemapy. Wpis Disallow: / utrudnia robotowi odczytanie informacji o 503 i potrafi utrzymać się w indeksie długo po zakończeniu prac. Dłuższe okno serwisowe zaplanuj jak wdrożenie, z listą zadań i godziną powrotu — przykład: InPost i PrestaShop 9: organizacja wdrożenia bez przestojów.

Tryb katalogowy — sklep widoczny, ale bez sprzedaży

Tryb katalogowy odpowiada na pytanie: co zrobić, jeśli sklep ma zostać online, ale nie może przyjmować zamówień? Front działa, treści i pozycje SEO zostają, znika koszyk i przycisk zamówienia.

Gdzie to włączyć. Ustawienia sklepu → Ustawienia produktów → Tryb katalogowy. Do wyboru: Nie, Tak dla gości (zalogowani klienci nadal kupują) i Tak dla wszystkich. Obok jest opcja ukrycia cen — możesz zostawić strony produktów bez cen, ale z opisami.

Różnica wobec konserwacji. Konserwacja odcina front i zwraca 503. Tryb katalogowy oddaje zwykłe 200, więc opisy, zdjęcia, kategorie i linki nadal pracują na SEO. Tracisz sprzedaż, nie pozycje.

Element	Tryb konserwacji	Tryb katalogowy
Widoczność frontu	Ukryty dla wszystkich poza listą IP	Pełna, dla wszystkich
Kod odpowiedzi	503	200
Koszyk i zamówienie	Brak	Brak
Ceny	Brak (cała strona zastąpiona)	Zależą od opcji ukrycia cen
Powrót do sprzedaży	Wyłączenie trybu konserwacji	Przełączenie na „Nie” i czyszczenie cache

Kiedy ma sens. Przenosiny magazynu, przerwa w dostawach, zmiana systemu fakturowania, sprzedaż wyłącznie zapytaniowa w B2B. W B2B to często stan stały, a nie awaryjny.

Jak wrócić bez utraty pozycji. Ustaw „Nie”, wyczyść cache (Zaawansowane → Wydajność → Wyczyść cache), a potem sprawdź w trybie incognito kartę produktu, kategorię i stronę główną — koszyk bywa w trzech miejscach motywu. Sprawdź też produkty z wariantami, bo tam ceny wracają najpóźniej. Adresy URL się nie zmieniają, więc indeksem nie musisz się zajmować.

Największe ryzyko. Klient, który nie widzi ceny, nie zostawia zapytania — wychodzi. Jeśli na karcie produktu nie ma formularza kontaktowego, a w nagłówku telefonu, tryb katalogowy zamienia ruch w zero leadów. Przed włączeniem sprawdź, czy zapytanie dochodzi i czy ktoś je czyta. Zweryfikuj też dane strukturalne produktów: jeśli nadal zgłaszają ceny i dostępność, lepiej je na czas przerwy wyłączyć, bo rozjazd między znacznikami a stroną szkodzi (zakres na dane strukturalne obsługiwane przez Google).

Sklep PrestaShop nagle offline — diagnoza w 10 minut

Zanim zaczniesz klikać w panelu, sprawdź, co odpowiada serwer. Jedno polecenie: curl -I https://twojadomena.pl. Kod odpowiedzi zawęża obszar szukania do jednej z czterech przyczyn.

Objaw	Prawdopodobna przyczyna	Pierwszy krok
500	błąd PHP: moduł, override, brakująca funkcja	log błędów PHP + var/logs
503	tryb konserwacji albo przeciążenie PHP-FPM	sprawdź, czy konserwacja jest włączona celowo
200 i biały ekran	fatal error przy wyłączonym wyświetlaniu błędów	logi, nie włączanie display_errors
„Nie można połączyć się z witryną”	wygasły certyfikat SSL albo domena	data ważności SSL, WHOIS domeny

Logi PrestaShop leżą w katalogu var/logs (wersje 1.7, 8, 9); starsze wersje trzymały je w log/. To logi aplikacji, ale przy 500 zwykle ważniejszy jest log PHP i serwera WWW: /var/log/php*-fpm.log, /var/log/nginx/error.log lub error_log Apache. Szukaj daty i godziny zgodnej z momentem awarii, nie nazwy sklepu.

Zasoby wyczerpują się po cichu. Sprawdź df -h — pełny dysk to najczęstsza przyczyna 500 połączonego z brakiem możliwości zapisu. Winowajcy: var/cache, var/logs, katalog tymczasowy. Dalej: limit procesów PHP-FPM (pm.max_children, komunikat max children reached w logu puli) oraz limit połączeń MySQL (błąd 1040, Too many connections). Objawy są podobne, leczenie inne.

Jeśli 500 pojawia się tylko na jednej podstronie, podejrzewaj moduł lub override — zwłaszcza gdy ktoś niedawno wgrywał zmiany. Warto wtedy przejrzeć sposób nadpisywania kodu: PrestaShop override: jak nadpisywać kod bez błędów.

Tryb debug (_PS_MODE_DEV_ w config/defines.inc.php) włączaj na 5–10 minut, na zamkniętym dostępie (hasło na katalogu, filtr po IP), i wyłączaj od razu. Publicznie widoczny stos błędów pokazuje ścieżki plików i wersje bibliotek — to gotowa instrukcja dla atakującego.

PrestaShop offline a SEO — jak nie stracić pozycji i wrócić online

Kod 503 oznacza „tymczasowo niedostępne”. Dla wyszukiwarki to sygnał, że adres żyje i ma wrócić — dokument RFC 9110 definiuje 503 jako stan przejściowy, w odróżnieniu od 404, który mówi „tego już nie ma”. Trzecia możliwość jest najgorsza: przekierowanie całego sklepu na stronę główną. Google widzi wtedy serię adresów, które nie odpowiadają na zapytanie użytkownika, i po dłuższym czasie zaczyna traktować je jak usunięte. Tryb konserwacji w PrestaShop domyślnie zwraca 503 — sprawdź to jednym poleceniem curl -I https://twojadomena.pl, zanim uznasz, że wszystko jest w porządku. Zdarza się konfiguracja, w której strona serwisowa zwraca 200, a to już zupełnie inny przekaz.

Nagłówki mają znaczenie. Retry-After mówi robotowi, kiedy wrócić — wartość 86400 (doba) przy krótkiej przerwie jest bezpieczna. Cache-Control ustaw tak, żeby przeglądarki i CDN nie zapamiętały strony serwisowej na tygodnie. I najważniejsze: nie dokładaj do niej na sztywno noindex. Jeśli zapomnisz to zdjąć po powrocie sklepu do sieci, wypadniesz z indeksu na własne życzenie. Sam 503 wystarcza, żeby robot nie indeksował treści.

Jak długo można utrzymywać 503? Nie ma magicznej liczby dni, ale im dłużej, tym większe ryzyko wypadania URL-i z indeksu i tym szybciej konkurencja przejmuje frazy transakcyjne. Kilka dni to niski koszt. Przerwa liczona w tygodniach wymaga już kontaktu z klientami i planu powrotu.

Lista kontrolna przed zdjęciem trybu konserwacji:

• cache wyczyszczony (Parametry zaawansowane > Wydajność),
• kolejka maili sprawdzona — zaległe potwierdzenia zamówień potrafią wyjść tygodniami,
• stany magazynowe zgodne z rzeczywistością, produkty niedostępne wyłączone z widoku,
• płatności przetestowane jedną transakcją w trybie testowym,
• integracje kurierskie aktywne (dobre tło: InPost i PrestaShop 9: organizacja wdrożenia bez przestojów).

Po powrocie online: sprawdź kluczowe URL-e, wyślij sitemapę ponownie, przejrzyj statystyki indeksowania w Search Console po 24, 72 godzinach i tygodniu. Dopiero wtedy widać, czy przerwa coś kosztowała.

Ile to zajmuje i kiedy zlecić to zewnętrznie

Widełki poniżej to czas realnej pracy, nie czas „od zgłoszenia do zamknięcia ticketa”. Zakładają sklep na sprawdzonym hostingu i osobę, która wie, gdzie szukać.

Zadanie	Czas pracy	Kiedy zlecać
Postawienie lokalnego środowiska zgodnego z wersją sklepu	3–5 h	gdy brakuje dostępu do serwera
Bezpieczny klon produkcji z podmianą URL i wyłączeniem integracji	4–8 h	przed gruntowną zmianą na żywym sklepie
Tryb konserwacji z własną stroną serwisową i dostępem po IP	2–4 h	przed migracją lub wdrożeniem
Diagnoza i naprawa po awarii	zwykle 2–8 h	gdy sklep stoi dłużej niż godzinę

Klon produkcji jest droższy od środowiska lokalnego i to normalne. Trzeba zsynchronizować bazę i pliki, wyłączyć płatności, wysyłkę maili, integracje kurierskie i crony, podmienić URL we wszystkich tabelach konfiguracyjnych i sprawdzić, czy nie ma zahardkodowanych adresów w modułach i szablonie. Pominięcie któregokolwiek kroku kończy się wysyłaniem prawdziwych maili z klonu albo podwójnym importem zamówień.

Diagnoza po awarii wyceniana jest po diagnozie, nie przed. Nie da się uczciwie powiedzieć „to będzie 3 godziny”, jeśli nie wiadomo, czy padł moduł, czy wyczerpał się dysk, czy ktoś nadpisał plik rdzenia. Przyczyna „brak miejsca na dysku i logi rosnące od miesięcy” to godzina pracy z czyszczeniem i zabezpieczeniem auto-rotacji. Przyczyna „kilka modułów konkuruje o ten sam hook po aktualizacji” to spokojnie 6–8 godzin.

Model wyceny jest prosty: stawka godzinowa razy liczba godzin. Bez widełek z sufitu, bez „od X zł, zobaczymy”. Zakres ustalamy przed startem i trzymamy się go — rozszerzenie zakresu to nowa decyzja, nie automatyczny dopisek do faktury.

Kiedy zlecać zewnętrznie: gdy sklep pracuje w sezonie i każda godzina przestoju to utracone zamówienia; gdy nie masz dostępu do serwera (tylko hosting „przekaże zgłoszenie”), bo połowa diagnozy to logi; gdy wolisz rozmawiać bezpośrednio z osobą, która pisze kod, a nie przez pośredników i handlowców. Punkt startowy znajdziesz tutaj: wdrożenia i utrzymanie PrestaShop.

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

Lista kontrolna do odklikania

• Ustal, który to wariant — Praca lokalna, konserwacja czy awaria — od tego zależy, czy w ogóle wolno ruszać produkcję. Zajmuje to minutę i zapobiega największym stratom.
• Sprawdź status HTTP sklepu — 200 oznacza działanie, 503 świadomą konserwację, 500 lub 502 najczęściej awarię. Rozróżnienie zmienia kolejność działań.
• Zapisz wersję PHP i wersję PrestaShop — Zakresy wsparcia dla PHP różnią się między PS 8.x i PS 9 — potwierdź je w dokumentacji deweloperskiej, zanim uruchomisz instalator.
• Zabezpiecz zrzut bazy — Dump zawiera dane klientów. Trzymaj go na zaszyfrowanym dysku i tylko na czas testów, a po zakończeniu prac usuń.
• Sprawdź parameters.php — Dane bazy i cookie_key kopii muszą być inne niż na produkcji, inaczej sesje i konfiguracje się mieszają.
• Podmień domenę w bazie — PS_SHOP_DOMAIN i PS_SHOP_DOMAIN_SSL w ps_configuration oraz domain, domain_ssl i physical_uri w ps_shop_url. Bez tego panel i front odwołują się do produkcji.
• Ustaw usługę na 127.0.0.1 — Środowisko lokalne nie powinno być widoczne w sieci lokalnej ani z internetu — sprawdź binding serwera WWW i bazy.
• Wyłącz wysyłkę maili — Zrób to, zanim klikniesz złożenie zamówienia w teście. Inaczej potwierdzenie poleci do prawdziwego klienta.
• Dezaktywuj moduły płatności — Produkcyjne klucze na kopii to ryzyko realnej transakcji. Wyłącz moduł albo użyj piaskownicy dostawcy.
• Wyłącz moduły kurierskie — Żadnych listów przewozowych z kopii. Integrację testuj na koncie sandboxowym operatora.
• Odłącz crony, webhooki i feedy — Porównywarki, piksele i Merchant Center mogą przyjąć dane z kopii jako prawdziwe i zaburzyć statystyki.
• Wyczyść var/cache i przegeneruj .htaccess — Zrób to przed pierwszym wejściem na front — stary cache i wpisy z produkcji powodują białe strony i błędy klas.
• Przeskanuj treści CMS i szablony maili — Stary adres zostaje najczęściej właśnie tam, mimo poprawnej podmiany w bazie i konfiguracji.
• Ustal powrót na produkcję — Kto wdraża, w jakim oknie czasowym i kto potwierdza, że sklep działa. Zapisz to przed startem prac.

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
• RFC 9110 – HTTP Semantics