SEO techniczne i szybkość strony to dwa osobne obszary, które mierzy się inaczej — ale dopiero razem przekładają się na zapytania od klientów. SEO techniczne pilnuje, czy Google widzi i indeksuje Twoje podstrony, szybkość decyduje, czy użytkownik doczeka ich wczytania. W tym tekście znajdziesz progi Core Web Vitals, 12-punktową listę audytu i kolejność prac, która w PrestaShop i WooCommerce daje największy zwrot. Punkt odniesienia: LCP do 2,5 s, INP do 200 ms, CLS do 0,1. Jeśli szukasz szerszego kontekstu, zobacz naszą stronę o SEO technicznym.
SEO techniczne to komplet ustawień i prac, które sprawiają, że Google potrafi odnaleźć Twoje adresy (crawl), wyrenderować ich treść (render), zapisać podstrony w indeksie (indeksacja) i poprawnie odczytać ich znaczenie (struktura, dane strukturalne, sygnały wydajności). W praktyce to robots.txt, sitemap.xml, adresy kanoniczne, przekierowania 301, architektura linkowania wewnętrznego i znaczniki schema.org. Szybkość jest osobnym wymiarem — mierzy się ją w sekundach i milisekundach, nie w pozycjach.
Oba obszary pracują jednak razem. Weź firmę usługową z Torunia, która ma LCP 6 s na telefonie. Użytkownik klika z wyników Google, patrzy kilka sekund na biały ekran, wraca i dzwoni do konkurencji. W Search Console zobaczysz dwa objawy naraz: sporo wyświetleń, niski CTR i wysokie odbicia. Pozycja nie spadnie pierwszego dnia, ale zapytania wyparują — a to one są celem, nie sama pozycja. W sklepie efekt jest bardziej dosłowny: porzucone koszyki i telefony „u was nic się nie otwiera”.
Te trzy kanały mają różne zadania i MŚP najczęściej mieszają je w złej kolejności:
| Obszar | Co realnie robi | Kiedy ma sens | Pierwszy efekt |
|---|---|---|---|
| SEO techniczne i szybkość | Otwiera drogę do indeksu, usuwa błędy, duplikaty i wolne odpowiedzi serwera | Zawsze pierwsze — gdy podstrony nie są indeksowane albo strona ładuje się dłużej niż 3 s | 2–6 tygodni |
| Treść i linkowanie wewnętrzne | Buduje trafność na frazy lokalne typu „usługi Toruń”, „montaż … Toruń” | Gdy indeks działa, ale masz za mało podstron pod konkretne zapytania | 2–4 miesiące |
| Płatne kampanie | Kupuje ruch natychmiast, nie wpływa na indeks ani na szybkość | Gdy potrzebujesz telefonów w tym tygodniu albo testujesz frazy | Od pierwszego dnia, do wyczerpania budżetu |
Progi są publiczne i nie zmieniają się od branży. Poniżej wartości dla telefonów, bo tam ruch z Google jest największy.
Jak sprawdzić to sam w 5 minut:
Różnica między lab a field jest kluczowa. Lighthouse to jedno uruchomienie na serwerze Google z symulacją wolnego łącza i procesora — wskazuje przyczyny, ale nie opisuje Twoich klientów. CrUX to dane prawdziwych użytkowników Chrome z 28 dni, więc strona z małym ruchem może nie mieć żadnej próbki. Pusty raport w GSC nie oznacza „wszystko OK” — po prostu zmierz lab albo wdróż własny monitoring. Definicje metryk znajdziesz w dokumentacji web.dev – Core Web Vitals, a kolejność dalszych prac opisuje nasz przewodnik po SEO technicznym i optymalizacji szybkości.
| Metryka | Dobrze | Wymaga pracy | Blokuje |
|---|---|---|---|
| LCP (największy element) | ≤ 2,5 s | 2,5–4,0 s | > 4,0 s |
| INP (reakcja na klik) | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS (przesunięcia układu) | ≤ 0,1 | 0,1–0,25 | > 0,25 |
| TTFB (odpowiedź serwera) | ≤ 800 ms | 0,8–1,8 s | > 1,8 s |
| Waga strony (mobile) | < 1,5 MB | 1,5–3 MB | > 3 MB |
| Liczba żądań | < 60 | 60–100 | > 100 |
Każdy punkt ma sposób wykrycia, nie tylko nazwę. Idź po kolei i zapisuj, co widzisz — bez tego lista zostaje teorią.
<a href> już w surowym HTML, nie tylko obsługę onclick.Jeśli prowadzisz też firmę w Bydgoszczy, ten sam schemat powtórzysz na drugiej domenie — zobacz SEO techniczne i szybkość strony dla firmy w Bydgoszczy.
Kolejność prac nie jest dowolna. Jeśli zaczniesz od czyszczenia CSS, a serwer odpowiada w 1,2 s, nie zobaczysz tego w LCP. Idziemy od dołu stosu:
Cache-Control: max-age=31536000, immutable dla plików z hashem w nazwie i minimum 30 dni dla pozostałych statyków. Włącz HTTP/2 lub HTTP/3, OPcache i PHP 8.2/8.3 — migracja z 7.4 na 8.2 daje zwykle 20–30% na samym PHP.width i height (główne źródło CLS), loading="lazy" poza pierwszym ekranem, fetchpriority="high" dla obrazu LCP.defer dla skryptów, które nie budują pierwszego renderu.W PrestaShop najwięcej daje: cache włączony w Zaawansowane → Wydajność, kompilacja szablonów ustawiona na „nigdy nie kompiluj ponownie”, CCC (połączenie, kompresja, cache), wyłączenie modułów, których nie używasz — każdy moduł to hooki odpalane na każdej stronie — oraz indeksy w bazie. Brak indeksu na id_lang przy 20 tys. produktów oznacza skan całej tabeli.
W WooCommerce: object cache (Redis), limit autoload w wp_options (trzymaj poniżej ok. 800 KB), liczba wtyczek i pomiar przez Query Monitor. 40 wtyczek to 40 miejsc, w których coś się ładuje.
Pułapka: skrypty marketingowe i czaty. LiveChat, Messenger, Hotjar i piksele dodają 300–600 KB i blokują główny wątek. Ładuj je po pierwszej interakcji użytkownika (scroll, ruch myszą, klik), a kontener tagów odpalaj triggerem „Window Loaded”. Zdarzenia dataLayer nie przepadną, bo kolejka działa też przed inicjalizacją kontenera — ale nie ustawiaj triggerów wcześniej niż sam kontener.
| Krok | Co robisz | Typowy efekt |
|---|---|---|
| 1. Hosting i TTFB | PHP 8.2+, OPcache, serwer z zapasem | TTFB z 800 ms do poniżej 200 ms |
| 2. Cache i kompresja | Brotli, Cache-Control, HTTP/2 lub HTTP/3 | Powtórne wejścia 2–5 razy szybsze |
| 3. Obrazy | WebP/AVIF, wymiary, lazy loading | Największy spadek LCP, CLS blisko zera |
| 4. Krytyczny CSS i JS | Usunięcie nieużywanego CSS, defer | LCP i INP w dół |
| 5. CDN | Dopiero po krokach 1–4 | Stały czas odpowiedzi dla użytkowników spoza regionu |
Sklep z 3 000 produktów i ośmioma atrybutami wygeneruje kilkadziesiąt tysięcy adresów URL samymi filtrami. Google zaindeksuje część z nich i rozmyje budżet crawlowania, który powinien iść na karty produktów i kategorie. Zasada: indeksuj tylko filtry, na które jest realny popyt — w praktyce 2–3 parametry, zwykle marka i jedna kluczowa cecha (rozmiar, pojemność).
?brand=x&size=y) — do robots.txt; to adresy nieskończone i nie chcesz, żeby bot je crawlowal,?orderby=, ?view=) — noindex, follow plus canonical do bazowej kategorii. Uwaga: robots.txt blokuje crawlowanie, więc Google nie odczyta wtedy canonicala — dla stron, które mają przekazywać wartość, używaj noindex, nie disallow,<a href>. Przyciski „wczytaj więcej” i infinite scroll są niewidoczne dla bota, jeśli nie mają zaplecza w linkach. rel=next/prev Google zignorował już w 2019 roku.Strony tagów w WooCommerce zwykle dublują kategorie — wyłącz je albo ustaw noindex. Puste kategorie (0 produktów) usuwaj, nie zostawiaj „na przyszłość”. Całość konfiguracji krok po kroku opisujemy w przewodniku SEO techniczne i optymalizacja szybkości sklepu.
Wydajność listingu: 24 produkty na stronę to rozsądny punkt startowy. 12 to za dużo klików, 48+ podnosi LCP i spłyca crawling. Obrazy poza pierwszym ekranem — loading="lazy", pierwsze 4–6 sztuk bez lazy. Podział na podkategorie robisz, gdy kategoria ma powyżej ok. 200 produktów albo użytkownicy i tak filtrują jedną cechę.
Weryfikacja: tydzień po zmianach porównaj liczbę zaindeksowanych URL-i (Search Console → Indeksowanie stron) z liczbą adresów w sitemapie i sprawdź, czy nie rośnie pozycja „Odkryte – obecnie niezaindeksowane”.
| Typ adresu | Decyzja | Jak ustawić |
|---|---|---|
| Filtr: 1 parametr z popytem (np. marka) | Indeksuj | Canonical do siebie, linki z kategorii nadrzędnej |
| Filtr: 1 parametr bez popytu | Nie indeksuj | noindex, follow |
| Kombinacja 2+ parametrów | Zablokuj crawlowanie | Disallow w robots.txt |
| Sortowanie, widok, orderby | Nie indeksuj | noindex + canonical do kategorii |
| Paginacja | Indeksuj | Zwykłe linki HTML, bez wczytywania na JS |
W Toruniu działa dużo firm usługowych i produkcyjnych B2B, a klient często porównuje 2–3 wykonawców z miasta lub z Bydgoszczy. Dlatego lokalne SEO zaczyna się od wizytówki, nie od tekstu z frazami.
Google Business Profile: jedna kategoria główna, możliwie najbliższa realnej usłudze („Projektowanie stron internetowych”, „Agencja marketingowa”), nie zestaw pięciu kategorii. Obszar działania ustaw tylko wtedy, gdy jeździsz do klienta — jeśli przyjmujesz klientów w biurze, adres ma być widoczny, a obszar pusty. NAP musi się zgadzać co do znaku na stronie (stopka i kontakt), w wizytówce i w katalogach: ta sama nazwa, ten sam numer telefonu, ten sam format adresu.
Schema: LocalBusiness lub ProfessionalService wdrażasz wyłącznie dla lokalizacji, w której faktycznie prowadzisz działalność. Wpisanie adresu w Toruniu, Bydgoszczy i Włocławku „na zapas” to wprowadzanie w błąd — Google weryfikuje to z wizytówką i innymi źródłami. Realnie obsługiwany obszar opiszesz polem areaServed, a nie fałszywymi adresami. Listę typów obsługiwanych przez Google masz w dokumentacji danych strukturalnych Google Search Central.
Strony usług pod frazy lokalne: jedna strona = jedna usługa. Treść ma odpowiadać na to, co klient chce wiedzieć: zakres, przebieg realizacji, czas, co dostaje na koniec, obszar obsługi. Podmiana „Toruń” na „Bydgoszcz” w tej samej treści to thin content — lepiej mieć jedną mocną stronę usługi i drugą, realnie inną dla drugiego miasta. Punkt wyjścia dla sklepów opisaliśmy w materiale SEO techniczne i optymalizacja szybkości sklepu w Toruniu.
Sygnały zaufania B2B: case study z liczbami, dane firmy (NIP, adres), regulamin, polityka prywatności i kontakt do konkretnej osoby z imienia i nazwiska oraz telefonem. Formularz bez nazwiska i adresu obniża konwersję w B2B mocniej niż wolne ładowanie strony.
Bez punktu odniesienia każda rozmowa o efektach kończy się wrażeniami. Dlatego pierwszym krokiem jest baseline: przed jakąkolwiek zmianą zapisujesz eksport z Search Console (Wydajność → eksport danych z ostatnich 3 miesięcy), raport „Indeksowanie → Strony” oraz aktualny pomiar Core Web Vitals dla domeny. Do tego TTFB z logów serwera albo z monitoringu zewnętrznego.
Minimum metryk, które wystarcza w większości firm:
Rytm: kontrola po 7 dniach dotyczy wyłącznie wskaźników technicznych — kodów odpowiedzi, liczby zaindeksowanych adresów, łańcuchów przekierowań, błędów 404 z logów. Core Web Vitals i ruch sprawdzasz po 30–90 dniach, bo okno CrUX to 28 dni i wcześniejszy odczyt pokaże jeszcze stary stan.
Jak odróżnić efekt techniczny od sezonowości? Porównujesz okres rok do roku, a nie miesiąc do miesiąca. Jeśli w kwietniu 2025 sprzedaż była o 30% niższa niż w marcu, to nie znaczy, że coś się zepsuło — to może być normalna sezonowość kategorii. Uważaj też na zmiany w SERP: wejście fragmentu wyróżnionego albo odpowiedzi generowanej potrafi ściąć kliknięcia przy rosnących wyświetleniach.
Fałszywy alert to chwilowy spadek pozycji po przekierowaniach lub zmianie struktury URL. Typowo trwa 1–3 tygodnie. Zanim wycofasz zmiany, sprawdź logi serwera i test na żywo w inspekcji URL — jeśli Google pobiera strony bez błędów, panika jest nieuzasadniona. Szerzej o tym, co obejmuje ten obszar, piszemy w sekcji o SEO technicznym, a praktyczne przypadki z lokalnego rynku opisujemy przy usłudze SEO technicznego i optymalizacji szybkości dla Torunia.
| Metryka | Skąd bierzesz | Kiedy sprawdzasz |
|---|---|---|
| Liczba zaindeksowanych URL-i | GSC → Indeksowanie → Strony | 7 dni po wdrożeniu |
| Kody odpowiedzi, przekierowania | Logi serwera, crawl | 7 dni po wdrożeniu |
| LCP / INP / CLS | CrUX, PageSpeed Insights (dane terenowe) | 30–90 dni |
| Wyświetlenia, kliknięcia, pozycja średnia | GSC → Wydajność, eksport CSV | 30–90 dni, porównanie rok do roku |
| TTFB | Logi serwera, monitoring zewnętrzny | Co tydzień w ramach opieki |
Te osiem sytuacji wraca w audytach najczęściej. Każda jest tania do naprawy, jeśli wykryjesz ją w ciągu kilku dni, i droga, jeśli zostanie na pół roku.
curl -I https://twojadomena.pl i szukasz nagłówka X-Robots-Tag, potem podglądasz źródło strony pod kątem <meta name="robots">. Alternatywa — blokada w robots.txt, np. całe Disallow: / zostawione po testach.curl -IL albo crawlem — docelowo maksymalnie jedno przekierowanie do wersji kanonicznej.Kolejność wykrywania: najpierw noindex i robots.txt, potem przekierowania, na końcu treść i linkowanie. Szersze omówienie kolejności prac znajdziesz w przewodniku po SEO technicznym i optymalizacji szybkości sklepu.
Oferta powinna dać się rozłożyć na trzy warianty. Pierwszy to audyt + plan: raport z listą problemów, priorytetami i szacunkiem pracochłonności. Nie dotykasz produkcji, dostajesz dokument, na podstawie którego możesz zlecić wdrożenie komukolwiek. Drugi to audyt + wdrożenie poprawek: naprawy na środowisku testowym, publikacja na produkcji, weryfikacja po 7 dniach. Trzeci to stała opieka techniczna z SLA: comiesięczny crawl, monitoring Core Web Vitals i dostępności, pula godzin na drobne poprawki i zadeklarowany czas reakcji przy błędach krytycznych, np. 4 godziny w dni robocze dla sklepu, który nie przyjmuje zamówień.
Orientacyjne godziny dla średniego sklepu (kilkaset produktów, kilka tysięcy URL-i):
Jeśli porównujesz oferty, patrz na stawkę za godzinę i zakres, nie na kwotę końcową. Różnica 2 000 zł często oznacza 15 godzin mniej pracy. Przykład kalkulacji dla mniejszego miasta pokazujemy przy usłudze SEO technicznego i optymalizacji szybkości — cena, a przy PrestaShop warto pilnować zgodności z dokumentacją deweloperską PrestaShop, żeby modyfikacje nie zniknęły po aktualizacji.
W umowie muszą być: zakres, czas reakcji, kto robi kopie zapasowe i jak długo je trzyma, dostęp do środowiska testowego, sposób raportowania (np. raz w miesiącu, konkretne metryki z tabeli powyżej) oraz procedura wycofania zmian.
Pytania do wykonawcy przed startem: kto ma dostępy do serwera, GSC i panelu sklepu; jak wygląda rollback, jeśli poprawka zepsuje koszyk; kto odpowiada za regresję po aktualizacji modułu; czy zmiany idą przez repozytorium; co się dzieje, gdy pula godzin w opiece się skończy.
| Wariant | Co zawiera | Orientacyjny czas |
|---|---|---|
| Audyt + plan | Raport, priorytety, szacunek pracochłonności, bez zmian na produkcji | 8–16 h |
| Audyt + wdrożenie | Poprawki na stagingu, publikacja, weryfikacja po 7 dniach | 20–60 h |
| Stała opieka z SLA | Monitoring, crawl, pula godzin, czas reakcji | 5–10 h / miesiąc |
Traktowanie szybkości jako całego SEO technicznego. Firma optymalizuje obrazy, widzi zielone Core Web Vitals i uznaje temat za zamknięty, a połowa podstron nadal nie jest zaindeksowana.
Jak wykryć: W Search Console porównaj liczbę podstron zgłoszonych w sitemapie z liczbą faktycznie zaindeksowanych oraz sprawdź raport „Indeksowanie stron”.
Jak naprawić: Rozdziel dwie checklisty: indeksacja i struktura (crawl, canonical, dane strukturalne) oraz wydajność (LCP, INP, CLS, TTFB). Pracuj na obu równolegle, ale raportuj je osobno.
Audyt oparty wyłącznie na symulacji z Lighthouse, bez danych od realnych użytkowników. Wynik 95/100 w laboratorium przy słabych wynikach na telefonach klientów.
Jak wykryć: W PageSpeed Insights sprawdź, czy widzisz osobną sekcję z danymi użytkowników (CrUX) — jeśli jej nie ma, raport opiera się tylko na symulacji.
Jak naprawić: Oprzyj decyzje na danych polowych: zakładka Core Web Vitals w Search Console i raport CrUX w PageSpeed Insights pokazują realne sesje z ostatnich 28 dni.
Wdrażanie zmian szybkościowych bezpośrednio na produkcji, bez kopii zapasowej i środowiska testowego.
Jak wykryć: Sprawdź, czy zmiany w szablonie i modułach idą najpierw na staging, czy od razu na żywą stronę, oraz czy przed pracami istnieje backup bazy i plików.
Jak naprawić: Zawsze staging + eksport bazy przed edycją. Przy PrestaShop dodatkowo kopia katalogu szablonu i wyłączanie cache tylko na czas testu.
Skrypty marketingowe, piksele i czat wklejone w sekcję head bez odroczenia. Każdy z nich blokuje renderowanie i podnosi LCP.
Jak wykryć: W PageSpeed Insights zobacz raport o wpływie kodu zewnętrznego oraz listę domen trzecich; w DevTools w zakładce Network sprawdź, które skrypty ładują się przed pierwszym renderem.
Jak naprawić: Załaduj skrypty przez jeden menedżer tagów, ustaw async/defer, a czat i widgety uruchamiaj po interakcji użytkownika lub z opóźnieniem. Sprawdź, czy dane analityczne nadal się zbierają.
Nakładanie kilku nakładek na jedną warstwę: dwie wtyczki cache, dwie minifikacje, dwa systemy konwersji obrazów.
Jak wykryć: Sprawdź, czy w kodzie strony są podwójnie dołączone pliki CSS/JS, czy nie pojawiają się konflikty w konsoli i czy obrazy faktycznie ładują się po zmianie wtyczek.
Jak naprawić: Jedna wtyczka na warstwę: jedna do cache, jedna do obrazów, jedna do optymalizacji plików. Resztę wyłącz i przetestuj na stagingu.
Ignorowanie różnicy między wersją mobilną i desktopową. Optymalizacja pod desktop, gdy większość ruchu lokalnego przychodzi z telefonu.
Jak wykryć: W CrUX i w PageSpeed Insights przełącz zakładkę Mobile i Desktop — porównaj LCP, INP i CLS dla obu.
Jak naprawić: Ustaw priorytet dla mobile: mniejsze obrazy, prostszy układ nad zagięciem, mniej skryptów na starcie. Desktop dopracuj po osiągnięciu progów na telefonie.
Traktowanie optymalizacji jako jednorazowego projektu. Po wdrożeniu nikt nie sprawdza, czy nowe moduły i wtyczki nie cofnęły wyników.
Jak wykryć: Porównaj dane CrUX z ostatnich 28 dni z poprzednim okresem w Search Console — bez monitoringu nie zobaczysz regresji.
Jak naprawić: Ustal przegląd co kwartał oraz po każdej większej zmianie na stronie: aktualizacja CMS, nowy wtyczka, nowa kampania z pikselami.
SEO techniczne i szybkość to dwa obszary, które trzeba mierzyć osobno i naprawiać w ustalonej kolejności. Zacznij od indeksacji i TTFB, potem cache i obrazy, a na końcu dopracuj skrypty zewnętrzne — to sekwencja, która daje największy zwrot w najmniejszym czasie. Trzymaj się progów: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 i oceniaj je na danych od realnych użytkowników, nie tylko na symulacji. Jeśli prowadzisz sklep, zajrzyj dodatkowo do materiału o SEO technicznym i optymalizacji szybkości sklepu w Toruniu, a po szerszy obraz sięgnij do przewodnika po SEO technicznym i szybkości.
SEO techniczne zajmuje się tym, czy Google może stronę odkryć, zrozumieć i zaindeksować: crawl, przekierowania, canonical, dane strukturalne, sitemap. Optymalizacja szybkości dotyczy tego, jak szybko strona odpowiada i renderuje się u użytkownika. Google łączy oba obszary w jednym zestawie wytycznych dotyczących Core Web Vitals, ale naprawia się je inaczej i warto raportować je osobno.
Przyjmij LCP ≤ 2,5 s, INP ≤ 200 ms i CLS ≤ 0,1 jako wartości docelowe dla 75. percentyla realnych sesji. Wartości LCP między 2,5 a 4,0 s traktuj jako stan wymagający pracy, a powyżej 4,0 s jako błąd do naprawy w pierwszej kolejności. Pełne definicje i progi znajdziesz w dokumentacji Web Vitals.
Google potwierdza, że sygnały wydajności strony są brane pod uwagę, ale nie są jedynym ani najważniejszym kryterium. Szybkość działa też pośrednio: lepsze LCP i INP to niższy współczynnik odrzuceń i wyższy CTR, a to przekłada się na liczbę zapytań. Nie licz na to, że sama optymalizacja szybkości przeniesie Cię na pierwsze miejsca bez zadbania o treść i strukturę.
Wpisz adres w PageSpeed Insights i sprawdź osobno sekcję z danymi użytkowników oraz wynik symulacji. Następnie otwórz zakładkę Core Web Vitals w Search Console, żeby zobaczyć dane z realnych sesji z ostatnich 28 dni. Różnica jest istotna: symulacja pokazuje warunki laboratoryjne, a dane polowe — to, co faktycznie przeżywają Twoi klienci.
Nie same w sobie — problem zaczyna się, gdy każda kombinacja filtrów tworzy osobny, indeksowalny adres. Ustal, które kombinacje mają realną wartość dla klienta i zostaw je otwarte, a pozostałe wyłącz z indeksowania. Zadbaj też o to, żeby treść kategorii była użyteczna dla ludzi, zgodnie z wytycznymi o treściach tworzonych dla ludzi.
Sklep powinien mieć znaczniki Product i Offer, strona usługowa LocalBusiness, a cała witryna BreadcrumbList dla ścieżek nawigacji. Znaczniki muszą opisywać to, co faktycznie jest na stronie — niezgodność z treścią może skończyć się ręcznym działaniem. Listę obsługiwanych typów znajdziesz w galerii danych strukturalnych Google.
Zmiany techniczne widać w narzędziach szybciej niż w pozycjach: dane polowe w Search Console odświeżają się z opóźnieniem i pokazują średnią z 28 dni. Na efekty w widoczności i zapytaniach trzeba zwykle poczekać kilka tygodni, bo dochodzi ponowne indeksowanie. Efektów nie da się też ocenić bez punktu wyjścia — zmierz progi przed pracami i po nich.
Jeśli chcesz wiedzieć, co konkretnie blokuje Twoją stronę, napisz do nas — sprawdzimy indeksację, Core Web Vitals i hosting, a potem podamy listę prac w kolejności od największego zwrotu. Bez zobowiązań i bez sprzedawania rzeczy, których Twoja firma nie potrzebuje.