Outsourcing WordPress dla agencji SEO: jak zlecać development w stałej umowie

Agencja SEO sprzedaje audyty, strategię treści i link building. Po audycie zostaje lista zadań, z których część wymaga zmian w kodzie motywu, wtyczek albo konfiguracji serwera. Bez developera WordPress w zespole ta lista leży, a klient pyta, dlaczego raport z marca nadal nie ma skutków w lipcu. Ten poradnik opisuje, jak zlecić te prace na zewnątrz w stałej umowie miesięcznej: co oddać developerowi, jak dać mu dostęp bez przekazywania kont, co wpisać do umowy i jak sprawdzić, czy praca przynosi efekt.

Fragmenty o prawie autorskim i RODO streszczają przepisy według stanu z 24 października 2026 r. Nie są indywidualną poradą prawną dla twojej agencji.

#W skrócie

• Agencja zostaje przy diagnozie, priorytetach i relacji z klientem. Developer odpowiada za wdrożenie i za to, żeby zmiana nie zepsuła produkcji.
• Dostęp nadajesz osobie, nie firmie: osobny użytkownik w Search Console, osobne konto w WordPressie, osobny klucz SSH. Każdy z nich da się odebrać jednym ruchem.
• W umowie zapisz miesięczny limit godzin, czas pierwszej reakcji (osobno od czasu naprawy), tryb wyceny większych prac, white-label i poufność.
• Kod napisany przez zewnętrznego developera należy do niego, dopóki nie przeniesie praw na piśmie.
• Developer z dostępem do stron z danymi osobowymi jest dalszym podmiotem przetwarzającym, więc potrzebujesz zgody klienta i umowy powierzenia.
• Efekt mierzysz per zadanie: stan przed, data wdrożenia, stan po 28 dniach danych z CrUX albo z Search Console.

#Słownik dla właściciela agencji

#Które zadania z audytu SEO wymagają developera WordPress

Audyt techniczny zwykle kończy się listą znalezisk, a nie listą osób. Pierwszy krok to rozdzielenie, kto co robi. Poniższy podział wynika z tego, gdzie leży zmiana: w treści i ustawieniach panelu, czy w kodzie i na serwerze.

Gdy wysyłasz developerowi zgłoszenie, kolumna “agencja” mówi, czego oczekuje on od ciebie: listy URL-i, danych z Search Console, mapy przekierowań. Zgłoszenie bez tych danych zaczyna się od pytań, a pytania zjadają godziny z pakietu. Szerzej o tym, skąd się biorą tygodnie oczekiwania na proste zmiany, piszemy w tekście dlaczego zmiany na stronie WordPress trwają tygodniami.

#Jak dać developerowi dostęp do Search Console bez przekazywania konta

Search Console ma pięć poziomów dostępu. Ich opis pochodzi z dokumentacji Google o użytkownikach i uprawnieniach (support.google.com).

Developer prawie nigdy nie potrzebuje właściciela. Wystarcza mu pełny dostęp: widzi wszystkie dane, a dodawanie użytkowników i ustawienia zostają u właścicieli.

Przy końcu współpracy łatwo przeoczyć tokeny. Według tej samej strony Google usunięty właściciel traci dostęp, ale jego tokeny weryfikacyjne nie są usuwane ani unieważniane. Jeśli token (plik HTML, meta tag, rekord DNS) nadal jest na stronie albo w domenie, osoba może ponownie zweryfikować usługę. Dlatego zewnętrzny developer nie powinien weryfikować usługi własnym kontem. A jeśli kiedyś to zrobił, przy rozstaniu usuwasz i użytkownika, i jego token. Google ostrzega o tym w panelu: gdy przy usuwaniu pojawia się informacja, że użytkownik może odzyskać dostęp, znaczy to, że jego tokeny wciąż są na miejscu.

Jeśli usunie się wszystkich zweryfikowanych właścicieli, pozostali użytkownicy i właściciele przekazani tracą dostęp po okresie przejściowym. Zweryfikowanym właścicielem powinien więc zostać klient, a agencja i developer korzystają z dostępu, który klient może kontrolować.

#Jaką rolę w WordPressie dać zewnętrznemu developerowi

WordPress ma sześć ról domyślnych. Dokumentacja na wordpress.org opisuje je tak: Super Admin zarządza siecią multisite, Administrator ma dostęp do wszystkich funkcji administracyjnych pojedynczej strony, Editor publikuje i zarządza wpisami, także cudzymi, Author publikuje własne wpisy, Contributor pisze, ale nie publikuje, a Subscriber zarządza tylko swoim profilem.

Na pojedynczej instalacji tylko Administrator ma między innymi te uprawnienia: update_core, update_plugins, install_plugins, edit_plugins, edit_themes, edit_files, create_users, delete_users i unfiltered_html. W multisite ma je tylko Super Admin. To oznacza, że developer, który ma aktualizować wtyczki albo instalować nowe, potrzebuje roli Administratora na stagingu i zwykle także na produkcji. Rola Editor nie wystarczy do pracy technicznej.

Skoro konto developera jest kontem administratora, liczy się higiena wokół niego:

• Osobne konto dla każdej osoby. Jedno wspólne “agencja-dev” oznacza, że nie wiesz, kto co zmienił, i nie odbierzesz dostępu jednej osobie bez zmiany hasła wszystkim.
• Wyłączona edycja plików w panelu. Dokumentacja hardeningu WordPressa (developer.wordpress.org) podaje, że define( 'DISALLOW_FILE_EDIT', true ); w wp-config.php odpowiada odebraniu wszystkim użytkownikom edit_themes, edit_plugins i edit_files. Developer i tak powinien wdrażać kod z repozytorium, a nie przez edytor w panelu.
• Staging z oznaczonym środowiskiem. Funkcja wp_get_environment_type() zwraca local, development, staging albo production, a gdy nic nie ustawiono, przyjmuje production (developer.wordpress.org). Ustawienie staging na kopii pozwala kodowi i wtyczkom zachować się inaczej, np. nie wysyłać maili do klientów sklepu.
• SFTP albo SSH zamiast FTP. Ta sama dokumentacja hardeningu zaleca SFTP, bo hasło i dane są szyfrowane w drodze. W praktyce lepiej działa klucz SSH dla każdej osoby osobno: odebranie dostępu to usunięcie jednej linii z authorized_keys, bez zmiany haseł innym. O wdrażaniu przez SSH i Git piszemy w tekście nowoczesne wdrażanie WordPress przez SSH i Git.

Konta w hostingu, rejestratorze domeny, CDN i licencje wtyczek premium powinny należeć do klienta albo agencji. Developer dostaje do nich dostęp jako użytkownik, a nie jako właściciel.

#Jak odebrać dostępy po zakończeniu współpracy

Lista do wykonania w dniu zakończenia umowy, najlepiej dopisana do umowy jako obowiązek obu stron:

1. Search Console: usuń użytkownika i wszystkie jego tokeny weryfikacyjne (plik, meta tag, rekord DNS).
2. WordPress: usuń konta developera na produkcji i stagingu, a wpisy przypisz innemu użytkownikowi.
3. Serwer: usuń jego klucze SSH z authorized_keys, konta SFTP i ewentualne konta bazy danych.
4. Repozytorium: odbierz dostęp do organizacji, kluczy wdrożeniowych i sekretów CI.
5. Hosting, CDN, menedżer DNS, panel płatności: usuń użytkownika, a tam, gdzie konto było wspólne, zmień hasło i klucze API.
6. Narzędzia zewnętrzne: Google Analytics, Tag Manager, monitoring, menedżer haseł.
7. Dane: potwierdzenie na piśmie, że developer usunął albo zwrócił kopie baz i plików z danymi osobowymi (to wymóg z art. 28 ust. 3 lit. g RODO, opisany niżej).

Jeśli tej listy nie da się wykonać w godzinę, dostępy były nadawane zbyt szeroko albo na wspólne konta.

#Core Web Vitals: co naprawia developer, a co hosting

Progi podaje web.dev (vitals). Mierzy się je na 75. percentylu odsłon, osobno dla urządzeń mobilnych i komputerów.

INP stał się stabilnym wskaźnikiem Core Web Vitals w 2024 r. i zastąpił FID. Raporty klientów sprzed tej zmiany, które mówią o FID, opisują wskaźnik, którego Google już nie używa w tym zestawie.

Podział odpowiedzialności wynika z tego, z czego składa się każda metryka. LCP obejmuje czas połączenia, przekierowań i odpowiedzi serwera, a dopiero potem ładowanie i wyrenderowanie elementu. Część tego czasu należy do hostingu, część do motywu.

Developer, który przy każdym słabym wyniku odpowiada “to wina hostingu”, nie pokazuje pomiaru. Dobry partner przy wysokim TTFB rozdziela czas na PHP, bazę i sieć i dopiero wtedy wskazuje winnego. Jeśli klient potrzebuje osobnej diagnozy przed decyzją o zmianach, odpowiada na to audyt Core Web Vitals, a same poprawki opisuje strona o przyspieszaniu strony WordPress. Techniczny przegląd metryk znajdziesz w poradniku wydajność WordPress: Core Web Vitals, cache i obrazy.

#Co wpisać do umowy z developerem WordPress na abonament

Stała umowa z developerem sprzedaje dwie rzeczy: zarezerwowany czas i przewidywalną reakcję. Umowa powinna opisywać obie tak, żeby po trzech miesiącach nikt nie musiał zgadywać, co było ustalone.

#Zakres i godziny

Miesięczny limit godzin, sposób ich rozliczania (np. w kwadransach), co wchodzi w pakiet, a co nie. Przykładowe brzmienie:

Wykonawca rezerwuje dla Zamawiającego 24 godziny pracy w każdym miesiącu kalendarzowym. Godziny niewykorzystane w danym miesiącu nie przechodzą na kolejne miesiące.

Brak przenoszenia godzin wygląda na korzyść tylko dla developera, ale ma uzasadnienie po obu stronach. Developer odmawia innym klientom, żeby trzymać ten czas dla agencji. Gdyby godziny kumulowały się bez końca, po pół roku agencja miałaby prawo zażądać kilkudziesięciu godzin w jednym tygodniu, czego nikt nie jest w stanie obsłużyć. Jeśli godziny regularnie zostają, pakiet jest za duży.

#Czas reakcji i czas naprawy

To dwa różne zobowiązania. Czas reakcji to potwierdzenie, wstępna diagnoza i plan. Czas naprawy zależy od przyczyny, a tej przed diagnozą nikt nie zna. Przykładowe brzmienie:

Czas reakcji oznacza potwierdzenie przyjęcia zgłoszenia wraz ze wstępną diagnozą i planem dalszych działań. Czas reakcji liczy się w dni robocze od poniedziałku do piątku, w godzinach pracy według czasu środkowoeuropejskiego. Czas reakcji nie jest terminem usunięcia usterki.

Dopisz też, co oznacza każdy priorytet (np. P1: produkcja albo zamówienia nie działają; P2: blokada wdrożenia; P3: rozwój i optymalizacja) i kto nadaje priorytet. Bez definicji każde zgłoszenie klienta staje się P1.

#Praca po godzinach

Jeśli SLA działa w dni robocze, napisz wprost, że wieczory, weekendy i awarie poza tymi godzinami wymagają osobnego, pisemnego uzgodnienia. Agencja, która obiecuje klientowi dyżur całodobowy, a ma developera w godzinach biurowych, sprzedaje coś, czego nie ma.

#Większe prace poza pakietem

Migracja, nowy typ treści, przebudowa szablonów rzadko mieszczą się w miesięcznym limicie. Umowa powinna mówić, że zadanie powyżej określonej liczby godzin dostaje osobny pisemny zakres, estymację i akceptację przed startem.

#Okres startowy i wypowiedzenie

Na początku współpracy część czasu idzie na poznanie stron klientów, dostępów i procesu agencji. Dlatego sensowny jest dłuższy pierwszy okres, a potem umowa miesięczna z określonym wypowiedzeniem.

#White-label, poufność i nieprzejmowanie klienta

Umowa poufności podpisana przed przekazaniem nazw klientów i dostępów. Zasada, że developer komunikuje się z klientem końcowym tylko wtedy, gdy agencja tego chce. Zakaz składania klientowi końcowemu własnej oferty w trakcie współpracy i przez określony czas po niej.

#Definicja gotowego zgłoszenia

Zgłoszenie zawiera oczekiwany rezultat, URL-e, środowisko, dane do odtworzenia problemu i kryterium akceptacji. Zgłoszenie, które tego nie ma, wraca do agencji z pytaniami, a czas na nie liczy się z pakietu albo nie. To też trzeba zapisać.

Jeśli wybierasz partnera na całą stronę, a nie na abonament godzinowy, przyda się nasz tekst o tym, jak wybrać agencję WordPress. Stałe utrzymanie pojedynczej strony bez rozwoju opisuje oferta utrzymania stron WordPress.

#Kto ma prawa autorskie do kodu napisanego dla klienta agencji

Polska ustawa o prawie autorskim i prawach pokrewnych (tekst jednolity Dz.U. 2025 poz. 24) chroni programy komputerowe jak utwory literackie (art. 74 ust. 1). Wyjątek dla zatrudniających jest wąski. Art. 74 ust. 3 mówi, że prawa majątkowe do programu stworzonego przez pracownika w wyniku wykonywania obowiązków ze stosunku pracy przysługują pracodawcy. Developer na umowie B2B nie jest pracownikiem, więc ten przepis go nie obejmuje.

Prawa przechodzą więc tylko umową, a o jej skuteczności decydują te przepisy:

Dla programów komputerowych pola eksploatacji wynikają z art. 74 ust. 4: trwałe lub czasowe zwielokrotnienie programu, jego tłumaczenie, przystosowanie i inne zmiany, a także rozpowszechnianie. Ogólną listę pól daje art. 50 (utrwalanie i zwielokrotnianie, obrót egzemplarzami, publiczne udostępnianie). W umowie z developerem warto je wypisać wprost, łącznie z prawem do dalszych zmian w kodzie przez inne osoby i prawem do przeniesienia praw na klienta końcowego. Bez tego ostatniego agencja może mieć prawa, ale nie móc ich oddać.

Przykładowe brzmienie, do sprawdzenia przez prawnika agencji:

Z chwilą podpisania protokołu odbioru za dany miesiąc Wykonawca przenosi na Zamawiającego autorskie prawa majątkowe do kodu wytworzonego w tym miesiącu, na polach eksploatacji: trwałe i czasowe zwielokrotnianie w całości i w części, tłumaczenie, przystosowywanie, zmiana układu i wszelkie inne zmiany, rozpowszechnianie, w tym publiczne udostępnianie w sieci, oraz z prawem dalszego przeniesienia tych praw na klientów Zamawiającego.

Umowa nie obejmuje samego WordPressa. Jest on wydany na licencji GPLv2 lub późniejszej, a WordPress.org uważa wtyczki i motywy za utwory zależne, które dziedziczą GPL (wordpress.org). Przeniesienie dotyczy kodu, który developer napisał dla agencji. Ten kod powinien od pierwszego dnia trafiać do repozytorium agencji albo klienta. Prawa na papierze niewiele dają, jeśli kod leży tylko na laptopie developera.

Nowelizacja z 4 września 2026 r. (Dz.U. 2026 poz. 1296, wchodzi w życie 6 listopada 2026 r.) zmienia w tej ustawie tylko art. 22¹ ust. 3. Przepisy cytowane wyżej pozostają bez zmian.

#Czy zewnętrzny developer to podmiot przetwarzający w RODO

Prawie zawsze tak, jeśli ma dostęp do baz z danymi osobowymi: zamówień WooCommerce, formularzy kontaktowych, kont użytkowników, list newslettera. Układ wygląda zwykle tak: klient agencji jest administratorem, agencja jest podmiotem przetwarzającym, a developer, któremu agencja zleca pracę na tych danych, jest dalszym podmiotem przetwarzającym.

Art. 28 ust. 2 RODO (EUR-Lex) mówi: “Podmiot przetwarzający nie korzysta z usług innego podmiotu przetwarzającego bez uprzedniej szczegółowej lub ogólnej pisemnej zgody administratora.” Przy ogólnej zgodzie agencja informuje klienta o każdym planowanym dodaniu lub zastąpieniu dalszego podmiotu, a klient może się sprzeciwić. Art. 28 ust. 4 wymaga, żeby na dalszy podmiot nałożono umową te same obowiązki ochrony danych, jakie agencja ma wobec klienta. Jeśli developer ich nie dopełni, pełna odpowiedzialność wobec klienta spoczywa na agencji.

W praktyce oznacza to trzy dokumenty:

1. W umowie agencji z klientem: zgoda (szczegółowa albo ogólna) na korzystanie z dalszych podmiotów przetwarzających, z nazwą developera albo z mechanizmem informowania.
2. Umowa powierzenia między agencją a developerem, która powtarza obowiązki z art. 28 ust. 3: przetwarzanie tylko na udokumentowane polecenie, poufność osób z dostępem, środki bezpieczeństwa z art. 32, pomoc przy żądaniach osób, usunięcie albo zwrot danych po zakończeniu usług, udostępnienie informacji do audytu.
3. Zasada pracy na danych: staging z danymi zanonimizowanymi albo ograniczonymi, kopia produkcyjnej bazy tylko wtedy, gdy zadanie tego wymaga, i usunięcie jej po zamknięciu zgłoszenia.

Przykładowe brzmienie klauzuli o danych na stagingu:

Wykonawca nie przenosi kopii produkcyjnej bazy danych poza infrastrukturę wskazaną przez Zamawiającego. Jeżeli zadanie wymaga pracy na kopii danych, Wykonawca usuwa ją w ciągu 7 dni od zamknięcia zgłoszenia i potwierdza to w zgłoszeniu.

#Jak mierzyć efekty pracy developera w abonamencie

Raport godzin mówi, ile czasu zużyto. Nie mówi, czy strona klienta działa lepiej. Mierzenie trzeba więc zaplanować przy każdym zadaniu, zanim developer zacznie pracę.

Dla zadań wydajnościowych źródłem są dane terenowe. CrUX API podaje 28-dniową średnią kroczącą zagregowanych metryk i aktualizuje się codziennie około 04:00 UTC (developer.chrome.com). Do zbioru trafiają tylko strony publicznie wykrywalne i z dostateczną liczbą odwiedzin, więc mała podstrona może nie mieć danych na poziomie URL-a, tylko na poziomie całej domeny. Raport Core Web Vitals w Search Console korzysta z tych samych danych CrUX, grupuje podobne URL-e i nadaje grupie status najsłabszej metryki. Po wdrożeniu poprawki przycisk rozpoczęcia śledzenia uruchamia 28-dniowe okno: jeśli problem nie pojawi się w tym czasie w żadnym URL-u, Google uznaje go za naprawiony (support.google.com).

Z tego wynika rytm: pomiar przed, data wdrożenia, pomiar po co najmniej 28 dniach. Raport po tygodniu pokazuje mieszankę starych i nowych odsłon.

Dla zadań SEO (przekierowania, indeksacja, dane strukturalne) pomiarem są raporty Search Console: stan indeksowania wskazanych URL-i, raport ulepszeń dla danego typu danych strukturalnych, wyniki wyszukiwania dla grupy stron przed i po zmianie.

Prosty format miesięcznego raportu, który agencja może przekazać klientowi pod własną marką:

Pola liczbowe wypełnia się danymi z narzędzi, nie szacunkami. Kolumna “status pomiaru” chroni przed raportowaniem sukcesu, którego jeszcze nie widać.

#Po czym poznać złego partnera white-label

Sygnały ostrzegawcze przy wyborze developera albo firmy, która ma pracować pod twoją marką:

• Nielimitowane zgłoszenia za stałą opłatę. Ktoś w końcu płaci za brak limitu: zwykle kolejka, w której twoje zgłoszenie czeka bez terminu.
• Brak pisemnego czasu reakcji. “Odpowiadamy szybko” nie jest zobowiązaniem. Zapytaj o czas reakcji dla priorytetu krytycznego i o godziny, w których obowiązuje.
• Obietnica czasu naprawy dla każdej awarii. Nikt nie zna przyczyny przed diagnozą. Gwarancja naprawy w 2 godziny bez zastrzeżeń znaczy, że umowa nie została przemyślana.
• Godziny, które przechodzą bez końca. Brzmi korzystnie, ale tworzy dług czasu, którego partner nie będzie w stanie spłacić naraz.
• Brak stagingu. Developer, który wdraża zmiany od razu na produkcji klienta, przenosi ryzyko na twoją agencję.
• Wspólne konta i jedno hasło dla zespołu. Nie da się ustalić, kto co zmienił, ani odebrać dostępu jednej osobie.
• Weryfikacja Search Console własnym kontem developera. Przy rozstaniu zostają tokeny, a z nimi możliwość powrotu.
• Kod tylko na serwerze, bez repozytorium agencji lub klienta. Prawa autorskie na papierze nie pomogą, jeśli nie masz kodu.
• Brak umowy powierzenia. Jeśli partner nie pyta o dane osobowe, nie myśli o odpowiedzialności, którą agencja ponosi za niego wobec klienta.
• Partner, który chce kontaktu z klientem końcowym od pierwszego dnia. White-label oznacza, że to agencja decyduje, kiedy i czy do tego dojdzie.

#Jak działa Agency Development Desk

Agency Development Desk to nasza stała usługa dla agencji SEO, brandingowych i projektowych, które nie mają własnego developera WordPress i WooCommerce. Zasady są te same, które ten poradnik opisuje jako bezpieczne:

• trzy pakiety z miesięcznym limitem godzin: Desk Flex (10 h), Desk Core (24 h) i Desk Embedded (48 h), każdy z pisemnym czasem pierwszej reakcji zależnym od priorytetu;
• SLA działa w dni robocze CET, a praca wieczorna, weekendowa i awaryjna wymaga osobnego pisemnego uzgodnienia;
• reakcja oznacza potwierdzenie, wstępną diagnozę i plan, a nie gwarancję naprawy w tym samym czasie;
• niewykorzystane godziny nie przechodzą na kolejny miesiąc, bo ta pojemność była zarezerwowana dla agencji;
• pierwszy okres trwa dwa miesiące, potem pakiet działa miesięcznie z jednomiesięcznym wypowiedzeniem;
• większe sprinty dostają osobny pisemny zakres, estymację i akceptację;
• NDA przed przekazaniem dostępów, praca white-label pod procesem agencji i zasada nieprzejmowania klienta zapisana w umowie;
• kod trafia do repozytorium kontrolowanego przez agencję albo klienta, a konta i licencje nie zależą od nas.

Zadania przyjmujemy pisemnym zgłoszeniem z oczekiwanym rezultatem, linkami, środowiskiem i kryterium akceptacji, bez obowiązkowych spotkań. Ceny pakietów są na stronie usługi. Żeby ocenić dopasowanie, wystarczy mail z typem obsługiwanych klientów, stackiem, przykładowym backlogiem z ostatniego audytu i oczekiwaną liczbą godzin w miesiącu.