SEO techniczne i optymalizacja szybkości w Toruniu — co realnie decyduje o pozycjach

SEO techniczne w sklepie internetowym to pięć obszarów, które muszą działać razem: indeksacja (co Google widzi i zapisuje), wydajność (serwer, baza danych, frontend), architektura adresów (kategorie, filtry, paginacja, canonical), dane strukturalne (Product, Offer, BreadcrumbList) i bezpieczeństwo (HTTPS, certyfikat, brak mieszanej treści). Poprawa jednego obszaru przy zaniedbanych pozostałych nie daje efektu — dlatego zdarza się sklep z wynikiem 92/100 w PageSpeed, który nadal nie rankuje na żadną frazę kategorii.

Praktycznie warto rozdzielić trzy warstwy:

• Crawl — czy Googlebot w ogóle wchodzi na stronę. Blokada w robots.txt, 5xx z przeciążonego serwera, pętla przekierowań.
• Index — czy Google zapisuje dany URL. Duplikaty z parametrami filtrów, canonical wskazujący w złą stronę, status „Odkryta — obecnie niezaindeksowana”.
• Rank — czy zapisana strona wygrywa. Tu decyduje treść, dopasowanie do intencji zapytania i linki.

Jeśli crawl i index są w porządku, a sklep stoi w miejscu, problem leży w warstwie rank, nie technicznej. I odwrotnie: nawet świetnie napisana karta kategorii nic nie da, gdy przy 20 żądaniach na sekundę serwer zwraca 500.

Optymalizacja szybkości to warunek konieczny, ale niewystarczający. Sklep w Toruniu z LCP 1,8 s i pustym opisem kategorii nie sprzeda, bo nie odpowiada na intencję użytkownika — zasady tworzenia takich treści opisuje dokumentacja Google o tworzeniu treści dla ludzi. Same reguły techniczne są identyczne dla sklepu w Toruniu i w Zamościu — różni się tylko kontekst lokalny: obsadzenie wyników lokalnych, nazwy dzielnic w treściach, frazy typu „sklep zoologiczny Toruń”. Rozwinięcie tematu znajdziesz w części poświęconej SEO technicznemu, a porównanie lokalne w materiale o SEO technicznym i optymalizacji szybkości w Zamościu dla firm.

Audyt techniczny w 60 minut — 12 sygnałów, które sprawdzisz sam

Zanim zlecisz audyt, zrób własny przegląd — 60 minut, bez płatnych narzędzi. Kolejność ma znaczenie: najpierw sprawdzasz, czy Google wchodzi, potem czy zapisuje, na końcu jak wypada wydajność.

Wejdź do Google Search Console → Indeksowanie → Strony i porównaj liczbę adresów zaindeksowanych z wykluczonymi. Powód „Odkryta — obecnie niezaindeksowana” oznacza problem z budżetem crawlowania, a „Zaindeksowana, mimo że zablokowana w pliku robots.txt” — konflikt do naprawy. W Ustawienia → Statystyki crawlowania sprawdź dzienną liczbę żądań Googlebota i udział odpowiedzi 5xx. Nawet 2–3% błędów serwera to sygnał, że maszyna nie wyrabia przy szczycie ruchu.

Potem weź 20 losowych URL-i: 5 produktów, 5 kategorii, 5 stron paginacji i 5 adresów z parametrami filtrów. Sprawdź kody odpowiedzi (`curl -I` albo rozszerzenie do podglądu nagłówków). Szukasz: 5xx, łańcuchów A→B→C→D, 302 na stałych adresach oraz 200 na stronach, które powinny zwracać 404 lub 410.

PageSpeed Insights uruchom dwa razy — na zakładce Mobile i Desktop. Ważniejsza od pojedynczego wyniku jest sekcja Ocena Core Web Vitals z danymi z ostatnich 28 dni, bo to pomiar realnych użytkowników, a nie symulacja.

Wpisz `site:domena.pl` i sprawdź, czy w wynikach pojawiają się adresy z `?page=`, `?sort=`, `?utm_` — to duplikaty rozdrabniające sygnały. Wyłącz JavaScript i obejrzyj kod źródłowy: jeśli nie widać cen, opisów i nazw produktów, Google ma problem z renderowaniem.

Na telefonie sprawdź, czy elementy klikalne mają co najmniej 48×48 px i czy pop-up z kodem rabatowym nie zasłania treści od razu po wejściu. Otwórz stronę po `https://`, zweryfikuj kłódkę, a w konsoli przeglądarki (zakładka Network) wyłap ostrzeżenia o mieszanej treści.

Blokujące są: 5xx, brak indeksacji kategorii, blokada w robots.txt, brak HTTPS i treść niedostępna bez JS. Reszta — wolny TTFB, łańcuchy przekierowań, parametry URL — pogarsza wyniki, ale sama nie wykluczy strony z indeksu. Szersze omówienie znajdziesz w przewodniku SEO techniczne i optymalizacja szybkości sklepu.

Core Web Vitals w liczbach: LCP, INP i CLS na Twoim sklepie

Trzy metryki, trzy progi — wszystkie liczone na 75. percentylu. To znaczy: 3 na 4 wizyty muszą zmieścić się w limicie. Pojedynczy zielony wynik z Lighthouse nic nie znaczy, podobnie jak jeden słaby pomiar w raporcie.

Metryka	Dobry	Wymaga poprawy	Słaby	Co najczęściej zawodzi w sklepie
LCP	poniżej 2,5 s	2,5–4,0 s	powyżej 4,0 s	obraz hero, TTFB, blokujący CSS
INP	poniżej 200 ms	200–500 ms	powyżej 500 ms	skrypty koszyka, pop-upy, long tasks
CLS	poniżej 0,1	0,1–0,25	powyżej 0,25	baner cookies, reklamy, fonty

INP zastąpiło FID w marcu 2024 roku. FID mierzył wyłącznie opóźnienie pierwszej interakcji — nie widział, ile czasu strona potrzebuje, żeby faktycznie zareagować. Sklep, w którym „Dodaj do koszyka” odpowiadało po 600 ms, mógł mieć idealne FID i realną stratę konwersji. INP bierze pod uwagę wszystkie interakcje w sesji i raportuje najgorszą z nich.

Nie mieszaj dwóch typów danych. CrUX to pomiar realnych użytkowników Chrome z ostatnich 28 dni — na jego podstawie Google ocenia stronę. Lighthouse to symulacja na jednym urządzeniu o zadanej sieci i CPU: mówi, co poprawić, ale nie pokazuje, jak wypadasz na tle konkurencji. W PageSpeed Insights dane terenowe są u góry, wyniki laboratoryjne niżej. Pełne definicje metryk znajdziesz w materiałach web.dev o Web Vitals.

Słabe LCP najczęściej powodują: obraz hero w PNG ważący 1,5 MB, brak `fetchpriority="high"` i `preload` dla obrazu LCP, TTFB powyżej 1,2 s przez wolne zapytania do bazy na liście kategorii oraz blokujący CSS motywu ładowany przed treścią. Obraz i serwer odpowiadają za większość przypadków — nie JavaScript.

INP psują skrypty koszyka odpalane przy każdym kliknięciu, wtyczki pop-upów i czatów oraz synchroniczne zapytania w JS; long task powyżej 50 ms to już sygnał ostrzegawczy. CLS generują banery cookies bez zarezerwowanego miejsca, reklamy wstawiane nad treścią, fonty bez `font-display: swap` oraz obrazy bez atrybutów `width` i `height`.

Od czego zacząć? Od TTFB — zejście poniżej 0,8 s poprawia jednocześnie LCP i część INP, bo skraca oczekiwanie na każdy zasób. W PrestaShop to OPcache i cache szablonów, przegląd zapytań generowanych przez listę produktów oraz ograniczenie modułów ładujących własny JS na froncie. Licz się z tym, że CrUX aktualizuje się z 28-dniowym opóźnieniem — efekt zobaczysz po kilku tygodniach, nie następnego dnia.

Jak Google widzi Twój sklep — rendering, JavaScript i budżet indeksowania

Google przetwarza stronę w dwóch etapach: najpierw pobiera kod HTML, a dopiero później — jeśli uzna to za potrzebne — uruchamia JavaScript i renderuje stronę. Jeśli nazwa produktu, cena i dostępność są wstawiane przez JavaScript po zapytaniu do API, robot widzi w pierwszym kroku pusty szkielet. Treść trafia wtedy do kolejki renderowania, a to opóźnienie liczy się w godzinach, nie w sekundach.

Zasada jest krótka: treści krytyczne dla SEO — nazwa produktu, cena, opis, dostępność, marka — muszą być w HTML po pobraniu, nie po hydratacji. Test zajmuje minutę: w Chrome wyłącz JavaScript (DevTools → Ctrl+Shift+P → „Disable JavaScript”), odśwież kartę produktu i sprawdź, czy widzisz cenę. Jeśli nie widzisz, Google w wielu przypadkach też jej nie zobaczy w pierwszym etapie. To fundament SEO technicznego — bez niego pozostałe poprawki pracują na treści, której robot nie czyta.

Analiza logów serwera pokazuje, na co realnie idzie budżet indeksowania. Pobierz access.log z 30 dni, odfiltruj Googlebota i policz wejścia na koszyk, panel klienta, /search, strony wyników filtrów (?q=, ?order=, ?page=) oraz adresy z parametrem sesji. Jeśli połowa wizyt bota dotyczy koszyka i sortowania, budżet ucieka na strony, których nikt nie wyszukuje. Analizator logów pokaże to w kilku widokach, ale wystarczy arkusz i zliczenie po adresach.

Szersze tło znajdziesz w przewodniku po SEO technicznym i optymalizacji szybkości sklepu, a tutaj zapamiętaj dwa limity sitemapy XML: 50 000 adresów i 50 MB na plik bez kompresji. Większy sklep dzieli mapę na kilka plików i wskazuje w Search Console indeks sitemap. Do sitemapy trafiają wyłącznie adresy zwracające 200, kanoniczne i indeksowalne — nie koszyk, nie wyniki wyszukiwania. W robots.txt nie blokuj /themes/, /js/, /css/ ani /modules/: Googlebot renderuje z zablokowanymi zasobami i strona wygląda wtedy jak uszkodzona.

Indeksacja i architektura: kanoniczne, paginacja i nawigacja facetowa

Kategoria z 40 markami i 12 rozmiarami daje teoretycznie ponad 480 kombinacji adresów, a do tego dochodzi sortowanie, widok siatki i listy oraz paginacja. Wszystkie te strony pokazują ten sam zestaw produktów w innej kolejności. Sam link do filtra nie boli — problem zaczyna się wtedy, gdy nawigacja facetowa linkuje setki wariantów, a robot pobiera je wszystkie.

Masz trzy strategie. Blokada w robots.txt (Disallow) sprawdza się dla sortowania i parametrów sesji, ale zablokowany adres może trafić do indeksu bez treści, jeśli coś na niego linkuje. noindex w meta robots (noindex, follow) działa tylko wtedy, gdy bot wejdzie na stronę i przeczyta znacznik — nie łącz blokady z noindex, bo te sygnały się wykluczają. Trzecia opcja jest najlepsza: indeksuj tylko kombinacje z realnym popytem, np. marka + kategoria („/obuwie/nike/”), z własnym H1, opisem i co najmniej kilkoma produktami. Resztę ustaw na noindex, follow.

Najczęstsze błędy w kanonicznych: link do innego produktu, adres z parametrem sesji, kanoniczny wskazujący na stronę z noindex. Domyślnie bezpieczny jest self-canonical. Przy paginacji rel next/prev nie jest już sygnałem — liczy się kolejność i to, że każda strona ma self-canonical; strony 2 nie wskazujesz na stronę 1. Linki do kolejnych stron muszą być w HTML, a nie tylko wywoływane JavaScriptem. Adresy typu /product.php?id_product=123 przekieruj 301 do najbliższego odpowiednika i pilnuj, żeby nie tworzyć łańcuchów przekierowań.

Dane strukturalne produktu i oferty (Product, Offer z ceną, walutą i dostępnością) oraz okruszków (BreadcrumbList) sprawdź w Rich Results Test i w raporcie elementów o strukturze danych w Search Console — lista typów obsługiwanych przez Google jest tu punktem odniesienia. Typowy błąd po promocji: cena w JSON-LD inna niż w HTML.

Kolejność tych prac jest identyczna niezależnie od miasta — przykład wdrożenia opisaliśmy w materiale o SEO technicznym i optymalizacji szybkości w Zamościu dla firm.

Szybkość sklepu: cache, CDN, obrazy, baza i hosting

W PrestaShop wejdź w Zaawansowane parametry → Wydajność i włącz CCC (Combine, Compress, Cache), a kompilację szablonów ustaw na „nigdy nie kompiluj”, gdy motyw jest gotowy. W WooCommerce cache strony to za mało: potrzebujesz object cache (Redis, np. przez wtyczkę Redis Object Cache) i cache stron na poziomie serwera (nginx fastcgi_cache albo LiteSpeed). Pułapka: przy pełnym cache stron mini-koszyk i licznik muszą być ładowane przez AJAX i wyłączone z cache — inaczej klient zobaczy zawartość cudzego koszyka.

Nagłówki: statykom daj Cache-Control: public, max-age=31536000, immutable, HTML-owi krótszy max-age z ETag i stale-while-revalidate, do tego Vary: Accept-Encoding. CDN z kompresją Brotli: darmowy plan odciąża statykę i TLS w mniejszym sklepie, płatny ma sens, gdy potrzebujesz reguł cache dla HTML, WAF i natychmiastowego czyszczenia cache po zmianie ceny. Obrazy: WebP, a AVIF po testach, srcset i sizes, width i height przeciw skokom layoutu, lazy loading tylko poniżej pierwszego ekranu, obraz LCP z fetchpriority="high" i bez lazy.

OPcache: opcache.memory_consumption 256 MB, opcache.max_accelerated_files 20000, w produkcji opcache.validate_timestamps=0 i restart PHP-FPM po wdrożeniu. Baza: indeksy na kolumnach filtrowanych i sortowanych (active, id_category, id_manufacturer, price), usuwanie tabel po odinstalowanych wtyczkach, limit zapytań na kartę produktu. Karta produktu generująca kilkaset zapytań to problem modułu, nie hostingu.

Hosting współdzielony wystarcza przy stałym, umiarkowanym ruchu. Sygnały do VPS: TTFB powyżej 600 ms przy włączonym cache, spadki dostępności podczas kampanii, brak możliwości włączenia Redisa i własnych ustawień OPcache. Ostatnia rzecz: agresywna minifikacja i łączenie plików potrafią rozbić koszyk lub konfigurator. Po każdym włączeniu CCC albo optymalizacji w wtyczce przejdź pełną ścieżkę: koszyk, zmiana ilości, checkout, konfigurator. Punkt odniesienia dla metryk opisuje dokumentacja Web Vitals.

Zakres i koszt takich prac w innym mieście: SEO techniczne i optymalizacja szybkości Szczecin dla firmy oraz SEO techniczne i optymalizacja szybkości w Zamościu — koszt.

SEO lokalne dla sklepu z Torunia — wizytówka, NAP i frazy z intencją lokalną

Wizytówka Google to najtańszy kanał lokalny, ale działa tylko wtedy, gdy jest spójna ze stroną. Zacznij od jednej kategorii głównej — np. „Sklep z narzędziami”, a nie trzech konkurencyjnych, bo Google nie wie wtedy, na co Cię pokazać. Obszar działania ustaw na konkretne miejscowości (Toruń, Bydgoszcz, Włocławek, Grudziądz), nie na całe województwo — zbyt szeroki obszar rozmywa dopasowanie. Dodaj minimum 5 zdjęć (wnętrze, magazyn, zespół, realizacja), a wpisy publikuj co 7–10 dni: wpisy typu „wydarzenie” wygasają szybciej niż zwykłe aktualizacje.

NAP, czyli nazwa, adres i telefon, musi być identyczny znak po znaku: „ul.” kontra „ulica”, „+48 56 000 00 00” kontra „56 000 00 00” — to dla wyszukiwarki dwa różne rekordy. To samo w katalogach firmowych. Na stronie umieść te dane w JSON-LD jako LocalBusiness (pola: name, address, telephone, openingHoursSpecification, areaServed, priceRange). Kody i wymagane pola znajdziesz w dokumentacji Google na temat danych strukturalnych obsługiwanych w wynikach wyszukiwania. Sam kod bez treści na stronie nic nie da.

Podziel frazy na dwie grupy:

• Lokalne („serwis narzędzi Toruń”) — osobna podstrona, osobna intencja, inny czas dostawy i punkt odbioru.
• Ogólnopolskie („szlifierka kątowa 125 mm”) — karta produktu lub kategoria, bez wplatania miasta na siłę.

Podstrony dla Torunia, Bydgoszczy i Włocławka nie mogą być kopią z podmienionym miastem. Daj minimum 40–60% unikalnej treści: zdjęcia z realizacji w danym mieście, opinie klientów stamtąd, konkretny czas dostawy, adres punktu odbioru. Strony z opisem realizacji lokalnej mają własne dowody społeczne — i to jest element, o którym konkurencja zapomina. Całość spina się z SEO technicznym rozumianym szerzej niż szybkość.

Migracja, przekierowania 301 i kolejność wdrożenia

Kolejność ma większe znaczenie niż liczba poprawek. Jeśli wdrożysz 30 zmian naraz, nie będziesz wiedział, która zadziałała, a która zepsuła indeksację.

Priorytet 1 — tydzień 1: błędy 5xx, 404 na adresach linkowanych z zewnątrz, przypadkowe noindex, sprzeczne canonicale, nieaktualna sitemap. To błędy, które fizycznie wycinają karty produktów z indeksu. Sprawdź logi serwera i raport „Indeksowanie stron” w Search Console. Priorytet 2 — tydzień 2–3: TTFB i LCP. Tu wchodzi cache (Varnish, Redis), PHP-FPM z OPcache, kompresja obrazów do WebP/AVIF, lazy loading poniżej pierwszego ekranu. Priorytet 3 — miesiąc 2–3: mikrooptymalizacje CSS i JS, kolejność fontów. Progi, które realnie mierzy Google, opisuje dokumentacja Core Web Vitals w Google Search Central. Pełny zakres prac po kolei znajdziesz w przewodniku SEO techniczne i optymalizacja szybkości sklepu.

Mapa przekierowań przy zmianie domeny, platformy albo struktury URL wygląda tak:

• Wyeksportuj pełną listę adresów (Screaming Frog, sitemap, logi serwera) — nie tylko tych z Search Console.
• Zbuduj arkusz: stary URL → nowy URL → kod 301 → status testu.
• Przekieruj zawsze do najbliższej tematycznie strony. Produkt wycofany → jego kategoria, nie strona główna. Hurtowe 301 na home to najczęstszy błąd i szybka utrata ruchu.
• Sprawdź łańcuchy: maksymalnie jeden przeskok. Testuj przez curl -I na stagingu przed wdrożeniem.

Okres przejściowy to realnie 4–12 tygodni. W tym czasie nie zmieniaj struktury URL, nie wdrażaj nowego layoutu i nie ruszaj masowo tytułów. Trzymaj starą domenę co najmniej 12 miesięcy, zweryfikuj obie wersje w Search Console i użyj narzędzia zmiany adresu. Po wdrożeniu zrób ponowny crawl porównawczy: liczba zaindeksowanych adresów nie powinna spaść.

Ile to kosztuje i jak wygląda praca z deweloperem

Nie wyceniaj całego SEO technicznego jedną kwotą — rozbij je na bloki, bo każdy ma inny czas i inną stawkę. Widełki poniżej to typowe, spotykane na rynku przedziały dla sklepu na PrestaShop lub WooCommerce ze średnim katalogiem (500–5 000 produktów).

Co zrobisz sam w panelu administracyjnym: meta title i description, teksty alt w zdjęciach produktów, opisy, wpisy w wizytówce, eksport listy URL. W PrestaShop do tego dochodzi konfiguracja wydajności (CCC, cache szablonów, kompresja). Co wymaga dostępu do serwera i kodu: php.ini (memory_limit, OPcache), konfiguracja MySQL/MariaDB (innodb_buffer_pool_size, slow query log), Nginx lub Apache, Varnish, modyfikacje szablonów .tpl, nadpisania modułów i dynamicznie generowane dane strukturalne. Bez tego drugiego zestawu uprawnień nie ruszysz TTFB.

Opieka po wdrożeniu powinna mieć trzy zapisane punkty: czas reakcji (typowo 24–48 h w dni robocze), miesięczny budżet zmian w abonamencie (np. 5 h) oraz stały raport: Core Web Vitals, liczba zaindeksowanych adresów, błędy 5xx, TTFB.

Różnica między pracą bezpośrednio z deweloperem a agencją z podwykonawcami jest głównie czasowa. Bezpośrednio decyzja zapada na jednym spotkaniu. Przy łańcuchu każda zmiana przechodzi przez 2–3 osoby i dodaje dni. Zapytaj wprost, kto fizycznie wykona prace — to pytanie ucina połowę nieporozumień. Przykład naszego podejścia do wyceny, bez kwot oderwanych od zakresu, opisaliśmy przy okazji wyceny SEO technicznego dla sklepu. Napisz, jaki masz sklep, ile produktów i co Cię blokuje — odpowiemy zakresem w godzinach, nie obietnicą „pierwszej strony”.

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

Lista kontrolna do odklikania

• Weryfikacja własności w Google Search Console — Sprawdź to na starcie. Bez potwierdzonej własności nie zobaczysz statusu indeksacji ani danych zapytań. Zweryfikuj też wersję z www i bez www.
• Raport Page Indexing — Otwórz Indexing → Pages. Zapisz liczbę adresów w grupach Indexed i Not indexed oraz nazwy powodów, które dominują. To punkt wyjścia do każdej dalszej decyzji.
• Crawl Stats z 90 dni — Zakładka Settings → Crawl stats. Sprawdź średni czas odpowiedzi, rozkład kodów HTTP i typy pobieranych plików. Duży udział 5xx lub pobierania obrazków zamiast stron to sygnał blokujący.
• Kody odpowiedzi HTTP dla 20 losowych adresów — Weź 20 adresów z sitemapy i kart produktów. Szukaj 5xx oraz łańcuchów przekierowań dłuższych niż jedno ogniwo. Jeden łańcuch to jeszcze drobiazg, kilkanaście — problem.
• PageSpeed Insights: mobile i desktop osobno — Uruchom test dla tego samego adresu na obu profilach. Różnica powyżej sekundy w LCP oznacza, że problem leży w warstwie mobilnej i tam trzeba szukać przyczyn.
• Core Web Vitals z ostatnich 28 dni — Zakładka Experience → Core Web Vitals w GSC. Interesuje Cię wartość na 75. percentylu dla mobile i desktop oddzielnie. Zielony wynik Lighthouse przy czerwonych danych terenowych oznacza, że testujesz nie to, co trzeba.
• TTFB serwera — Sprawdź czas do pierwszego bajtu dla strony głównej, kategorii i karty produktu. Jeśli przekracza 0,8 s, najpierw napraw hosting, cache i bazę danych — to naprawia kilka metryk naraz.
• Zapytanie site: i kontrola parametrów — Wpisz site:twojadomena.pl i przejrzyj pierwsze kilkadziesiąt wyników. Szukaj adresów z parametrami, zdublowanych wersji kategorii i stron, które nie powinny być zaindeksowane.
• Treść widoczna bez JavaScriptu — Wyłącz JS w przeglądarce albo obejrzyj kod źródłowy pod kątem treści i linków. Jeśli w źródle nie ma nazw produktów, cen ani linków wewnętrznych, robot może nie zobaczyć tego, co widzi użytkownik.
• Test mobilny pod kątem klikalności — Sprawdź na telefonie: rozmiar przycisków, odstępy, czytelność ceny, działanie koszyka. Osobno sprawdź, czy przy wejściu nie wyskakuje pop-up zasłaniający treść.
• Certyfikat SSL i mieszana treść — Otwórz kilka podstron i sprawdź, czy adres nie przełącza się na http oraz czy konsola przeglądarki nie zgłasza ostrzeżeń o mieszanej treści. Sprawdź też datę wygaśnięcia certyfikatu.
• robots.txt i sitemapa — Otwórz oba pliki i upewnij się, że robots.txt nie blokuje sekcji, które mają być indeksowane, a sitemapa zawiera wyłącznie adresy kanoniczne i zwraca kod 200.
• Dane strukturalne na karcie produktu — Sprawdź znaczniki Product, Offer i BreadcrumbList w narzędziu Google. Brak danych strukturalnych nie zablokuje indeksacji, ale ogranicza sposób prezentacji wyniku w wyszukiwarce.

Najczęściej zadawane pytania

Źródła i materiały

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