SEO · Techniczne · Sprint o ustalonym zakresie
Wdrażamy poprawki technicznego SEO, a nie tylko je opisujemy
Jeśli masz niewdrożony audyt lub migrację w kalendarzu, zamieniamy ustalenia lub plan migracji w zgłoszenia z kryteriami akceptacji i sprawdzamy crawlem każdą wdrożoną poprawkę.
Sprint technicznego SEO to współpraca o ustalonym zakresie, która zamienia ustalenia audytu we wdrożone, zweryfikowane poprawki, żeby Google mogło poprawnie crawlować, renderować i indeksować Twój serwis. W pakiecie Szybkie poprawki Twoi deweloperzy wdrażają na podstawie naszych zgłoszeń; od pakietu Naprawa możemy też sami wdrażać zmiany na nadanych przez Ciebie uprawnieniach. Nikt nie może obiecać, że pozycje nie zmienią się podczas migracji: w pakiecie Migracja i skala ryzyko ograniczamy pełną inwentaryzacją przekierowań, crawlem środowiska staging pod kątem zgodności i monitoringiem po starcie, a to, jak szybko Google ponownie przetworzy serwis, zależy od Google.
Stała cena · Zgłoszenia gotowe dla deweloperów · Crawl QA po poprawkach · Firma z UE, RODO · EN/UK/RU/PL
- w programie Google Partner
- od 2015
- klientów od 2015
- 490+
- odpowiadamy na zgłoszenie
- 1 dzień roboczy
Problemy
Gdy raport leży w folderze, a nic się nie zmienia
To sytuacje, które rozwiązujemy bezpośrednio, nie kolejnym dokumentem, lecz wdrożonymi zmianami i potwierdzeniem, że zadziałały. Część, która zaczyna się w wyższym sprincie, oznaczamy w jej opisie.
Audyt leży w folderze, a każde wdrożenie coś psuje
- Masz 40-stronicowy PDF z audytem, a nic tak naprawdę nie zostało naprawione
- Ustalenia były prawdziwe, priorytety jasne, a potem prace utknęły między konkurującymi priorytetami deweloperów, niejasnymi specyfikacjami i brakiem kogoś, kto sprawdziłby, czy poprawka faktycznie weszła. Diagnoza bez wdrożenia to koszt, a nie inwestycja. Wychodzimy od dowolnego istniejącego audytu, przekładamy ustalenia na konkretne specyfikacje i doprowadzamy sprawę do zweryfikowanego crawla po poprawkach.
- Przy każdym wdrożeniu zespół deweloperski coś psuje i nikt nie zauważa, dopóki ruch nie spadnie
- Pozostawiony tag noindex ze środowiska staging, przekierowanie usunięte przy przebudowie nawigacji, robots.txt blokujący kluczową sekcję po aktualizacji CMS. To rutynowe skutki uboczne wdrożeń, które często wychodzą na jaw dopiero, gdy raport Indeksowanie stron w Search Console zaczyna się zmieniać. Ustalamy, co się zepsuło, doprowadzamy do naprawy i potwierdzamy ją crawlem. Pakiet Migracja i skala konfiguruje też punkt odniesienia dla ponownych crawli i reguły wykrywania zmian; ich uruchamianie według harmonogramu po sprincie wyceniamy osobno.
- Serwis wielojęzyczny, gdzie liczy się tylko widoczność w Google, a hreflang i canonical psują się przy każdym wdrożeniu
- Każde wdrożenie to potencjalny punkt awarii: hreflang wskazujący na niewłaściwe wersje językowe, canonical prowadzący w nieoczekiwanym kierunku, noindex pojawiający się na stronach, które powinny być indeksowane. Naprawiamy konfigurację i potwierdzamy ją crawlem. Pakiet Migracja i skala dodaje reguły wykrywania zmian dla tych tagów; ich uruchamianie po sprincie wyceniamy osobno. Istotne dla firm obsługujących kilka języków UE przez Google.
Migracja nadchodzi albo już poszła źle
- Zmieniasz platformę lub domenę i boisz się utraty pozycji
- Zmiany struktury URL, migracje na HTTPS i przejścia na inny CMS to momenty najwyższego ryzyka w życiu serwisu. Mapa przekierowań z lukami, robots.txt ze środowiska staging zostawiony na produkcji albo canonical wskazujący na starą domenę mogą sprawić, że nowy serwis straci pozycje, zanim ktokolwiek to zauważy. Budujemy zabezpieczenia przed przełączeniem i monitorujemy sygnały przez cztery tygodnie po przełączeniu. Pełny scenariusz migracji obejmuje pakiet Migracja i skala.
- Po zmianie platformy lub przeniesieniu domeny ruch spadł, a wykonawca oddał raport i zniknął
- Podejmujemy migrację na dowolnym etapie: odbudowujemy pełną mapę przekierowań, porównujemy crawl środowiska staging z produkcją, śledzimy sygnały w Search Console przez pierwsze cztery tygodnie po starcie i zamykamy znalezione luki tak wcześnie, jak pozwalają na to sygnały. To, jak szybko Google ponownie przetworzy serwis, zależy od Google, więc nie obiecujemy daty powrotu pozycji. Ta praca należy do pakietu Migracja i skala. Istotne dla firm, które w ostatnich latach zmieniły CMS lub domenę.
Google nie crawluje, nie renderuje lub nie indeksuje ważnych stron
- Google nie crawluje nowych stron albo strony wciąż wypadają z indeksu
- Przy dużych serwisach lub takich z nawigacją fasetową Googlebot może przeznaczać dużą część crawlowania na warianty filtrów i URL-e paginacji, zamiast na strony kategorii i produktów, które się liczą. Analiza plików logów pokazuje dokładnie, dokąd trafia crawl, a praca nad crawl budget usuwa marnowanie, by crawl mógł dotrzeć do potrzebnych Ci stron. W małym serwisie przyczyna zwykle leży gdzie indziej, a ekspresowa analiza pozwala nam rozróżnić te przypadki. Analiza plików logów należy do pakietu Naprawa.
- Serwis mocno oparty na JavaScript i nie masz pewności, czy Google faktycznie widzi treść
- Aplikacje jednostronicowe i front-endy headless mogą wyglądać dobrze w przeglądarce, podczas gdy HTML otrzymywany przez Google przy pierwszym pobraniu jest niemal pusty, a treść trafia do indeksu dopiero po wyrenderowaniu strony przez Google. Do problemu przyczyniają się tekst, który nigdy nie trafia na wyrenderowaną stronę, skrypty zablokowane przez robots.txt oraz lazy loading czekający na przewinięcie lub kliknięcie. Diagnozujemy lukę i doprowadzamy do naprawy renderowania, a nie tylko ją dokumentujemy. Praca nad renderowaniem należy do pakietu Naprawa.
- Sklep generuje tysiące śmieciowych URL-i filtrów, a Google indeksuje warianty zamiast kategorii
- Nawigacja fasetowa na platformach takich jak Shoper, IdoSell czy PrestaShop potrafi wygenerować tysiące dostępnych dla crawlerów kombinacji filtrów, marnujących crawl i spowalniających odkrywanie stron kategorii, które powinny się pozycjonować. To zarządzanie indeksem, a nie kolejny audyt: projektujemy i wdrażamy zasady obsługi parametrów, reguły paginacji i reguły noindex, żeby strony napędzające sprzedaż były tymi, które oferujesz Google do indeksowania. Kontrola indeksacji należy do pakietu Naprawa.
Jak je rozwiązujemy
Co dostajesz na koniec sprintu
Każdy sprint zamyka się trzema artefaktami. Nic nie wymaga kolejnej współpracy, by zrozumieć, co zostało zrobione.
-
Uporządkowany według priorytetów backlog poprawek w formie zgłoszeń
Każde zgłoszenie opisuje problem, podaje dokładną specyfikację i kryteria akceptacji. Twoi deweloperzy mogą je wdrożyć bez dopytywania.
-
Crawl QA po wdrożeniu, przed i po
Po wdrożeniu każdej partii poprawek ponownie crawlujemy i porównujemy. Każda poprawka jest zweryfikowana, a nie zakładana.
-
Migawka Search Console z punktem odniesienia sprzed poprawek
Stan wyjściowy dokumentujemy, zanim cokolwiek wejdzie, więc efekt mierzymy w danych, a nie w deklaracjach.
Przykładowe zgłoszenie
Priorytet: WysokiSkonsoliduj zduplikowane URL-e filtrów za jednym canonical
Problem: /category/shoes/ i /category/shoes/?sort=price zwracają 200 i same się kanonizują, rozdrabniając sygnały indeksacji.
Specyfikacja: ustaw w każdym wariancie ?sort= rel=canonical wskazujący na czysty URL kategorii i zostaw parametr dostępny dla crawlera, bo blokada w robots.txt uniemożliwi Google odczytanie tego canonical. Czy parametr zostanie później zamknięty i jakim mechanizmem, rozstrzyga się dla konkretnego serwisu na podstawie logów, a nie jedną regułą pasującą do każdego sklepu.
Kryteria akceptacji: crawl QA pokazuje zero samokanonizujących się wariantów ?sort=; URL-e kategorii pozostają bez zmian i zwracają 200.
Przykład poglądowy, nie rzeczywisty efekt dla klienta.
Co naprawiamy
Część, która zaczyna się w wyższym sprincie, oznaczamy na jej karcie.
Wdrażanie poprawek i specyfikacje gotowe dla deweloperów
Bierzemy ustalenia z Twojego dotychczasowego audytu (naszego lub zewnętrznego) i zamieniamy je w uporządkowane według priorytetów zgłoszenia w formacie gotowym dla Jiry, które Twój zespół deweloperski może zrealizować bez niedomówień: mapy przekierowań, zestawy reguł canonical, dyrektywy robots.txt i zasady dla meta tagów. Po wdrożeniu każdej partii poprawek przez Twoich deweloperów uruchamiamy kontrolny crawl QA, by potwierdzić, że poprawka weszła poprawnie i że nic obok nie zepsuło się przy okazji.
Każdy sprint. Sami wdrażamy zmiany od pakietu Naprawa
SEO przy migracjach serwisu i zmianie platformy
Zmiana domeny, migracja na HTTPS, przejście na inny CMS i przebudowa struktury URL to momenty wysokiego ryzyka: pominięta mapa przekierowań albo robots.txt ze środowiska staging zostawiony na produkcji może uniemożliwić Google crawlowanie nowego serwisu, dopóki ktoś tego nie naprawi. Budujemy pełną inwentaryzację przekierowań przed przełączeniem, robimy crawl środowiska staging, żeby porównać zgodność z obecnym serwisem, i monitorujemy Search Console oraz logi crawla przez pierwsze cztery tygodnie po starcie.
Pakiet Migracja i skala
Analiza plików logów i inżynieria crawl budget
Logi serwera pokazują, jakie adresy Googlebot faktycznie pobiera, a nie to, co zakładasz, że crawluje. Przetwarzamy Twoje surowe pliki logów, by znaleźć marnowanie crawla na URL-ach o niskiej wartości, trafienia w strony przekierowane lub usunięte oraz strony istotne dla pozycji, które rzadko są pobierane. Przy dużych serwisach lub takich z nawigacją fasetową przygotowujemy konkretne rekomendacje dotyczące reguł robots.txt, linków wewnętrznych i sitemap.
Pakiet Naprawa i wyższy
Renderowanie JavaScript i naprawa renderowania
Diagnozujemy dokładnie, w którym miejscu Twoja konfiguracja CSR, SSR lub hydratacji sprawia, że treści brakuje na wyrenderowanej stronie, którą indeksuje Google, albo że pozostaje ona niewidoczna dla robotów niewykonujących JavaScriptu, a potem doprowadzamy do naprawy, zamiast tylko ją opisywać. Praca obejmuje korekty konfiguracji SSR lub prerenderingu, naprawę lazy-loadingu tak, aby treść ładowała się, gdy staje się widoczna, oraz sprawdzenie danych strukturalnych w wyrenderowanym HTML. Preferujemy dane strukturalne w HTML serwera, bo jest to bardziej niezawodne, szczególnie dla ceny i dostępności produktu.
Pakiet Naprawa i wyższy
Kontrola indeksacji na dużą skalę
Nawigacja fasetowa i lawina parametrów w URL mogą wciągnąć w crawlowanie i do indeksu tysiące wariantów o niskiej wartości, podczas gdy strony kategorii, które faktycznie się pozycjonują, dostają mniej uwagi crawla. Projektujemy i wdrażamy zasady obsługi parametrów, reguły paginacji, dyrektywy noindex oraz konfigurację sitemap, świadomie decydując, co powinno, a co nie powinno być indeksowane.
Pakiet Naprawa i wyższy
Monitoring zdrowia technicznego i ochrona przed regresją
Punkt odniesienia dla ponownych crawli, kontrole Search Console i reguły wykrywania zmian sprawiają, że rutynowe ponowne wdrożenie, które przywraca tag noindex, usuwa przekierowanie lub psuje konfigurację canonical, wychodzi na jaw przy następnej kontroli, a nie dopiero w danych o ruchu po tygodniach. Na to, czy Google zdążył do tego czasu ponownie odwiedzić stronę, nikt nie ma wpływu, i właśnie dlatego sprawdzanie odbywa się według harmonogramu, a nie dopiero po spadku.
Konfiguracja: pakiet Migracja i skala. Uruchamianie po sprincie: osobna wycena
Jak wygląda backlog, na podstawie naszego przykładowego rejestru
Każdy problem ma określoną wagę, test wskazujący, kiedy uznajemy go za naprawiony, i osobę odpowiedzialną: to, kto go wdraża, uzgadniamy przed startem sprintu.
Nasza opublikowana próbka, Rejestr problemów technicznych, opiera się na wymyślonej witrynie, za którą nie stoi prawdziwy klient.
-
Dyrektywa blokująca crawl ze środowiska testowego działa na hoście publicznym
KrytycznaKryterium odbioru: Żywy plik robots dopuszcza sekcje publiczne, a reguła blokująca istnieje tylko na środowisku testowym
Właściciel: My, hosting potwierdza
-
Treść w szablonie usługi pojawia się dopiero po hydracji
KrytycznaKryterium odbioru: Pierwszy akapit jest obecny w surowym kodzie HTML na każdej stronie usługi
Właściciel: Programista klienta, my specyfikujemy
-
Stare adresy produktów docierają do celu przez dwa przekierowania
WysokaKryterium odbioru: Każdy stary adres dociera do celu jednym stałym przekierowaniem
Właściciel: My
-
Parametry filtrów tworzą adresy dostępne dla robota, których nikt nie szuka
WysokaKryterium odbioru: Dla robota i indeksu zostają tylko kombinacje wskazane w uzgodnionej polityce parametrów
Właściciel: My z programistą klienta
Dla kogo jest ten sprint, a dla kogo nie
Dobrze pasuje, jeśli masz
- Duży lub fasetowy serwis, gdzie crawl budget i indeksacja wymagają świadomej kontroli
- Front-end mocno oparty na JavaScript i wątpliwości, co Googlebot faktycznie widzi
- Migrację, zmianę platformy lub domeny w kalendarzu, albo taką, która już poszła źle
- Audyt (nasz lub zewnętrzny), który leży niewdrożony
To nie ta strona, jeśli potrzebujesz
- Strategii treści lub linkowania. Żadnej z nich nie sprzedajemy na tej stronie.
- Pogłębionej diagnozy Core Web Vitals. To należy do usługi Audyt SEO strony, która ma narzędzia do izolowania przyczyn LCP, INP i CLS.
- Pracy na poziomie wtyczek WordPress, takiej jak konfiguracja Yoast czy Rank Math. To należy do usługi WordPress SEO.
- Przebudowy samej strony. Od tego jest tworzenie stron internetowych.
Migracje
Jak prowadzimy migrację
Migracje psują się w przewidywalnych miejscach. Praca dzieli się na trzy etapy, a każdy ma własną listę kontrolną. Pełny scenariusz obejmuje pakiet Migracja i skala.
-
Przed przełączeniem
Budujemy pełną inwentaryzację przekierowań, crawlujemy środowisko staging, by zweryfikować zgodność URL-i i logikę canonical, oraz sprawdzamy, czy robots.txt ze środowiska staging nie trafi przypadkiem na produkcję.
-
Dzień startu
Monitorujemy dostęp crawla, zachowanie przekierowań i pierwsze sygnały w Search Console w chwili, gdy nowy serwis rusza, żeby problemy z dostępem crawla i przekierowaniami wychodziły na jaw w dniu startu, a nie po tygodniach.
-
Od 1. do 4. tygodnia po starcie
Śledzimy indeksowanie stron, aktywność crawla i sygnały pozycji, gdy Google ponownie przetwarza serwis. Luki zamykamy, zanim zamienią się w długotrwałe straty.
Ratowanie migracji, która już poszła źle
Migrację możemy podjąć w trakcie projektu lub po starcie: odbudowujemy inwentaryzację przekierowań, porównujemy crawl środowiska staging z produkcją i analizujemy spadki w raporcie Indeksowanie stron w Search Console. Jedno zastrzeżenie zawsze mówimy wprost: tempo odzyskiwania zależy od cyklu ponownego crawla Google, dlatego nigdy nie obiecujemy terminu powrotu pozycji.
Proces
Jak przebiega sprint
-
Ekspresowa analiza
Bezpłatnie, do dwudziestu minut rozmowy lub na czacie. Przyglądamy się Twojemu audytowi lub problemowi, wskazujemy do trzech pierwszych ustaleń lub kroków i mówimy, który sprint pasuje oraz czy najpierw potrzebna jest diagnoza. Na tym etapie nie ma pisemnego raportu.
-
Zakres i uprawnienia na piśmie
Zanim cokolwiek się zmieni, uzgadniamy zgłoszenia objęte zakresem, stałą cenę, kto wdraża każdą zmianę i jakich uprawnień ona wymaga. Gdy wdraża Twój zespół, dostęp do odczytu wystarcza do większości prac.
-
Zgłoszenia i poprawki
Każde zgłoszenie zawiera specyfikację i kryteria akceptacji. W pakiecie Szybkie poprawki wdrażają je Twoi deweloperzy; od pakietu Naprawa możemy je wdrażać sami na nadanych przez Ciebie uprawnieniach.
-
Crawl QA i przekazanie
Po każdej partii ponownie crawlujemy i sprawdzamy kryteria akceptacji. Do crawlowania i analizy używamy własnych narzędzi, Screaming Frog SEO Spider, Google Search Console, Ahrefs i PageSpeed Insights. Sprint zamykamy raportem z crawla QA, migawką Search Console przed i po oraz cofnięciem wszelkich tymczasowych uprawnień.
Przyjrzyjmy się Twojemu backlogowi
Zaczynamy od bezpłatnej ekspresowej analizy z kroku 1. Po niej decyzja należy do Ciebie.
Czego potrzebujemy od Ciebie na start
Nie musisz podawać hasła. Resztę ustalimy podczas bezpłatnej ekspresowej analizy.
- Twój audyt lub jasno określony problem. Nasz lub zewnętrzny. Bez audytu też możemy zacząć, jeśli zadanie jest jasne, na przykład migracja lub znany problem z renderowaniem.
- Dostęp do odczytu w Search Console i Analytics. Przez zaproszenie, nigdy hasłem. Gdy wdraża Twój zespół, ten dostęp i crawl publicznego serwisu wystarczają do większości prac; eksport logów lub dostęp do środowiska staging dodajemy, gdy sprint tego wymaga.
- Uprawnienia do zapisu dla uzgodnionej zmiany, jeśli wdrażamy my. Dokładnie te, których wymaga zgłoszenie, na przykład wgranie jednego pliku robots.txt albo rola redaktora na jednym szablonie, nadane na czas sprintu i cofnięte po jego zamknięciu.
- Eksport surowych logów dostępu do analizy plików logów. Od pakietu Naprawa. Wystarczy eksport z panelu Twojego hostingu albo CDN, z zakresu dat, który wybierzesz. Bez SSH i dostępu administratora.
- Dostęp do środowiska staging i okno startowe przy migracji. W pakiecie Migracja i skala. To, kto wdraża każdą zmianę, my czy Twój zespół, ustalamy przed startem sprintu.
Cena
Cennik sprintów technicznego SEO
Każda współpraca zaczyna się od bezpłatnej ekspresowej analizy. Każdy sprint wprost mówi, kto zmienia kod: pakiet Szybkie poprawki oddaje specyfikację i kontrolę, a wdraża Twój zespół; w dwóch pozostałych możemy wdrażać sami na uprawnieniach nadanych do uzgodnionej poprawki. Tryb pracy i potrzebne mu uprawnienia ustalamy przed startem prac, a nie po nich.
- Uporządkowana według priorytetów lista poprawek z ustaleń Twojego audytu (naszego lub zewnętrznego)
- Zgłoszenia gotowe dla deweloperów: mapy przekierowań, reguły canonical, dyrektywy robots
- Kontrolny crawl QA po poprawkach, by potwierdzić ich poprawne wdrożenie
- Sprawdzenie sygnałów Search Console i crawla po wdrożeniu
- Bezpłatna ekspresowa analiza
- Wszystko z pakietu Szybkie poprawki
- Diagnoza renderowania JavaScript i wdrożenie poprawki
- Analiza plików logów i rekomendacje dostrojenia crawl budget
- Kontrola indeksacji: obsługa parametrów, paginacja, zasady noindex
- 30 dni wsparcia w pytaniach o wdrożenie po dostarczeniu
- Wszystko z pakietu Naprawa
- Pełny scenariusz migracji: inwentaryzacja przekierowań, crawl zgodności na staging, lista kontrolna na dzień startu
- Monitoring po starcie przez cztery tygodnie (Search Console, logi crawla, sygnały pozycji)
- Konfiguracja ochrony przed regresją: punkt odniesienia z zaplanowanym ponownym crawlem i reguły wykrywania zmian
Monitoring po sprincie wyceniamy osobno, jeśli jest potrzebny.
Zamów pakiet Migracja i skalaCo dodaje każdy sprint
Pakiet Szybkie poprawki kosztuje €199 i obejmuje zdefiniowany zestaw ustaleń. Pakiet Naprawa (€399) dokłada pracę nad renderowaniem JavaScript, analizę plików logów i kontrolę indeksacji. Pakiet Migracja i skala (€750) obejmuje pełny scenariusz migracji plus cztery tygodnie monitoringu po starcie oraz konfigurację ochrony przed regresją. Stały monitoring wyceniamy na życzenie po pierwszym sprincie, bo właściwa częstotliwość zależy od wielkości serwisu i harmonogramu wdrożeń.
Wolisz nie wypełniać formularza? Napisz do nas na Telegramie (t.me/cyberlabteam) lub WhatsAppie (+48 668 155 303).
Trzy sposoby współpracy z nami
Tryb 1
Wdrażamy bezpośrednio
Ten tryb wymaga uprawnień do zapisu: dokładnie tych, których wymaga uzgodniona poprawka, na przykład wgrania jednego pliku robots.txt albo roli redaktora na poprawianym szablonie, nadanych na czas sprintu i cofniętych po jego zamknięciu. Sam dostęp do odczytu niczego nie wdroży, a potrzebne uprawnienia nazywamy przy każdym zgłoszeniu, zanim cokolwiek nadasz. Wdrażamy poprawki, robimy crawl QA i przekazujemy wszystko z dokumentacją. Dostępny od pakietu Naprawa.
Tryb 2
Twoi deweloperzy wdrażają, my piszemy specyfikacje i robimy QA
Piszemy zgłoszenia na tyle precyzyjne, by wykonać je bez nas w pokoju, a potem weryfikujemy każde wdrożenie crawlem po deploymencie.
Tryb 3
Monitoring po sprincie, jeśli jest uzasadniony
Jeśli Twoje tempo wdrożeń to uzasadnia, stały monitoring regresji wyceniamy osobno po zamknięciu sprintu. Nie ma automatycznego abonamentu.
Dlaczego my
Nasze doświadczenie
CyberLab.Team OÜ jest Google Partnerem od 2015 roku.
- od 2010 pracujemy z wyszukiwarką i reklamą Google
- 490+ klientów od początku działalności
- 15 krajów, w których działają nasi klienci
- od 2014 w zespole są Google Top Contributors i Product Experts
Nasz zespół ma 9 certyfikatów Google
-
Reklamy w wyszukiwarce Google Ads -
Reklamy wideo Google Ads -
Reklamy displayowe Google Ads -
Reklamy produktowe (Shopping) -
Reklamy aplikacji Google Ads -
Pomiar skuteczności Google Ads -
Optymalizacja konwersji -
Google Analytics -
Display & Video 360
Bez długoterminowych zobowiązań, pracujemy z Twoim obecnym zespołem
Nie wymagamy umowy na stałą obsługę ani żadnego minimum poza sprintem, który zamawiasz. Ekspresowa analiza odbywa się przed jakąkolwiek płatnością: do dwudziestu minut, do trzech pierwszych ustaleń lub kroków, bez pisemnego raportu.
- Zakres i cena ustalone przed startem. Zgłoszenia objęte zakresem i cenę uzgadniamy na piśmie przed startem prac, więc nie ma niespodzianek co do zakresu ani ceny.
- Minimalne uprawnienia lub brak dostępu. Od pakietu Naprawa, jeśli udzielisz nam ograniczonego dostępu, wdrażamy zmiany bezpośrednio; jeśli wolisz pracę własnych deweloperów, przekazujemy specyfikacje na tyle precyzyjne, by wykonać je bez nas. Twój CMS, Search Console i hosting pozostają w pełni pod Twoją kontrolą.
- Firma z UE, RODO. Podmiotem prawnym stojącym za każdą umową jest CyberLab.Team OÜ, estoński numer rejestrowy 14647320. Pracujemy zgodnie z RODO i na życzenie podpisujemy DPA.
- Przejrzysty cennik sprintów. Ceny trzech sprintów podajemy przy pakietach, bez długoterminowej umowy.
Modele współpracy
Dlaczego sprint o ustalonym zakresie
Sprint ma zdefiniowany zakres, opublikowaną cenę i punkt końcowy. Płacisz za określony, zweryfikowany rezultat, a nie za przepracowane godziny. Monitoring po sprincie wyceniamy, gdy jest potrzebny, a nie narzucamy go z góry.
| Sprint o stałym zakresie CyberLab | Typowy abonament agencji | Freelancer na godziny | |
|---|---|---|---|
| Opublikowana cena | Sprint o stałym zakresie CyberLab€199 / €399 / €750, na tej stronie | Typowy abonament agencjiWycena po rozmowie sprzedażowej | Freelancer na godzinyStawka godzinowa, łączna kwota otwarta |
| Zdefiniowany zakres i punkt końcowy | Sprint o stałym zakresie CyberLabStały zakres, kończy się po zweryfikowaniu poprawek | Typowy abonament agencjiOtwarte zobowiązanie miesięczne | Freelancer na godzinyZakres pełznie wraz z godzinami |
| QA po poprawkach | Sprint o stałym zakresie CyberLabCrawl QA po każdej partii poprawek | Typowy abonament agencjiZależnie od agencji | Freelancer na godzinyRzadko wliczone |
| Rejestracja w UE, RODO, DPA | Sprint o stałym zakresie CyberLabFirma z UE, DPA na życzenie | Typowy abonament agencjiRóżnie | Freelancer na godzinyRóżnie |
| Zobowiązanie długoterminowe | Sprint o stałym zakresie CyberLabBrak, jeden sprint na raz | Typowy abonament agencjiZwykle umowa wielomiesięczna | Freelancer na godzinyBrak, ale ciągłość zależy od jednej osoby |
Ogólne typy współpracy dla orientacji, a nie konkretne firmy.
Przykład pracy
Jak to wygląda w praktyce?
Jedno zlecenie: sklep internetowy przyszedł z półrocznym audytem od innego dostawcy. Ustalenia były trafne, ale nic nie zostało wdrożone. Zaczęliśmy od rozmowy o zakresie, świeżym crawlem potwierdziliśmy, które ustalenia wciąż obowiązują, i zamieniliśmy najważniejsze pozycje w zgłoszenia gotowe dla deweloperów: porządkowanie przekierowań, reguły canonical dla URL-i filtrów oraz poprawkę robots.txt, która blokowała sekcję produktów. Deweloperzy sklepu wdrożyli zmiany w dwóch cyklach wydań. Po każdym wydaniu robiliśmy crawl QA, by potwierdzić, że poprawki weszły i że nic obok się nie zepsuło. Zamykający dokument porównał stan Search Console przed i po: zablokowane sekcje znów dostępne dla crawlera, a zduplikowane warianty skonsolidowane.
Zanonimizowany przykład naszego procesu, nie obietnica wyników. Poniższe studium przypadku WaterHub dotyczy pozycjonowania SEO i reklamy sklepu internetowego, a nie sprintu technicznego.
Dowody przed zamówieniem
Pytania
Najczęściej zadawane pytania
Zakres, cena i termin
Ile kosztuje sprint i od czego zależy poziom?
Ile trwa sprint?
Co dokładnie dostajemy, gdy sprint się kończy?
Czy to projekt jednorazowy, czy stała współpraca?
Czy gwarantujecie pozycje albo odzyskanie ruchu po poprawkach?
Czy to właściwa usługa?
Czym to się różni od Waszego audytu SEO serwisu?
Czy przed rozpoczęciem napraw potrzebuję audytu?
Nawigacja fasetowa i URL-e filtrów w sklepie: czy to właściwa usługa?
Czy zajmujecie się Core Web Vitals i szybkością strony?
A co z danymi strukturalnymi i znacznikami schema?
A co z WordPress lub konkretnym CMS?
Czy roboty AI mogą pobrać i przetworzyć mój serwis?
Współpraca z Twoim zespołem i praca nad Twoim serwisem
Czy potraficie pracować z naszymi deweloperami, przygotować zgłoszenia gotowe dla Jira i zrobić QA po wdrożeniu?
Czy faktycznie wprowadzicie zmiany na naszym serwisie, czy tylko przygotujecie więcej dokumentacji?
Czy współpracujecie z naszą obecną agencją SEO albo działacie w modelu white-label dla agencji?
Gdzie przetwarzane są dane i jak bezpiecznie uzyskujecie dostęp do naszego serwisu?
Czy do analizy plików logów potrzebujecie dostępu do serwera?
Migracje, crawlowanie i renderowanie
Jak prowadzicie migrację lub zmianę platformy?
Czy możecie przejąć migrację rozpoczętą przez innego wykonawcę albo naprawić taką, która już się nie udała?
Czym jest crawl budget i czy mój serwis faktycznie ma z nim problem?
Serwis mocno oparty na JavaScript: czy Google widzi moją treść i co naprawiacie?
Nie wiesz jeszcze, co jest zepsute?
Zacznij od usługi Audyt SEO strony: pogłębiona diagnoza techniczna, analiza Core Web Vitals i uporządkowany według priorytetów plan działań. Potem przynieś ten plan tutaj do wdrożenia. Problemy platformy WooCommerce lub WordPress należą do usługi WordPress SEO; widoczność organiczna stron kategorii i produktów w sklepie to SEO e-commerce. Pracujesz na sygnałach z Search Console? Google Search Console Expert obejmuje konfigurację i diagnozę.
Wszystkie usługi SEO znajdziesz w hubie SEO.
Kontakt
Chcesz przekazać nam listę poprawek?
Wyślij adres serwisu i napisz, co wymaga naprawy lub migracji. Zaczynamy od bezpłatnej ekspresowej analizy. Potem Ty decydujesz.
Bez zobowiązań. Odpowiedź w ciągu jednego dnia roboczego.