SEO w Definition of Done. Jak audytować środowisko dev i współpracować z devami bez wojen

Jeśli Twój proces SEO zaczyna się w dniu wdrożenia, to nie jest proces — to serwis pogwarancyjny. Poniżej: gdzie wpiąć SEO w cykl wytwarzania, jak przeprowadzić audyt środowiska dev, jakie kryteria wpisać do Definition of Done i jak pisać wymagania, których zespół nie odrzuci.

Dlaczego reaktywne SEO przegrywa

Nie dlatego, że specjaliści są słabi albo devowie złośliwi. Z trzech powodów strukturalnych:

Wchodzisz po fakcie, więc każda uwaga jest kosztem, nie wymaganiem. Zmiana renderowania szablonu kategorii przed sprintem to estymata. Ta sama zmiana po wdrożeniu to refactor i rozmowa o tym, kto zawinił.
Nie masz artefaktu, tylko opinię. „Powinniśmy mieć canonical” nie jest zadaniem. Zadaniem jest warunek i sposób jego weryfikacji.
Twoja praca nie ma bramki. Wszystko, co nie ma bramki w procesie, jest opcjonalne. Review kodu ma bramkę. SEO — zwykle nie ma.

Odwrócenie tego nie wymaga nowego etatu ani „zmiany kultury”. Wymaga wpięcia się w trzy artefakty, które zespół już ma: Definition of Ready, pull request i Definition of Done.

Częsty błąd: mylenie „SEO-by-design” z „więcej audytów” To nie jest ten sam audyt, tylko wcześniej. To zmiana jednostki pracy: z raportu na kryterium akceptacji. Raport opisuje stan po fakcie i wymaga, żeby ktoś go przeczytał i uwierzył. Kryterium jest warunkiem zamknięcia zadania i wymaga tylko tego, żeby przeszło albo nie. Pierwsze jest do dyskusji, drugie do odhaczenia.

Trzy punkty wejścia

Etap	Artefakt	Co robisz	Dowód
Refinement	Definition of Ready	Oceniasz wpływ zadania i dopisujesz kryteria przed rozpoczęciem pracy	Story ma sekcję SEO albo świadomy tag „nie dotyczy”
Development	Pull request	Blok kontrolny w szablonie PR, review zmian w nagłówku strony i routingu	Odhaczony blok albo uzasadnione odstępstwo
Przed wdrożeniem	Staging	Audyt środowiska: porównanie z produkcją	Lista różnic i blockerów, nie lista „problemów SEO”

Dwie zasady, bez których ta tabela zostanie na slajdzie.

Nie wchodź we wszystkie trzy naraz. Zacznij od stagingu — tam łapiesz najwięcej za najniższą cenę polityczną. Szablon PR i Definition of Ready dochodzą później, kiedy zespół ma już zaufanie do Twoich sprawdzeń.

Rozdziel „dotyczy SEO” od „nie dotyczy” na wejściu. Zadanie dotyczy SEO, jeśli zmienia adresy URL, routing, zawartość nagłówka strony, renderowaną treść, statusy HTTP albo linkowanie wewnętrzne. Reszta jedzie bez bramki. Jeśli Twoje kryteria wiszą nad każdym ticketem, po miesiącu wszyscy będą je odklikiwać bez czytania.

Audyt środowiska dev — cztery rzeczy

1. Higiena stagingu

Werdykt: jedynym pewnym zabezpieczeniem jest autoryzacja na poziomie serwera — logowanie HTTP albo whitelist IP. Reszta to warstwa druga.

Blokada w robots.txt to instrukcja, żeby nie crawlować, a nie żeby nie indeksować. Adres zablokowany w robots.txt może trafić do indeksu, jeśli ktoś do niego zalinkuje — a wyszukiwarka nie zobaczy Twojego noindex, bo nie wejdzie na stronę, żeby go przeczytać. Klasyczna pułapka: zespół dokłada noindex i blokadę naraz, w przekonaniu, że to podwójny zamek. To dwa zamki, z których jeden blokuje drugi.

Do ustalenia z zespołem:

logowanie albo whitelist IP na całym środowisku,
nagłówek X-Robots-Tag: noindex wysyłany globalnie przez serwer stagingowy — na wypadek, gdyby ktoś zdjął autoryzację „na chwilę”,
plik robots.txt na stagingu identyczny jak produkcyjny, a nie blokujący wszystko,
reguły dla robotów sterowane zmienną środowiskową, nie zawartością pliku w repozytorium.

Ostatni punkt jest najważniejszy i najczęściej pomijany. Najkosztowniejszy wypadek to nie wyciek stagingu do indeksu, tylko wjechanie stagingowej konfiguracji na produkcję razem z wdrożeniem — globalny noindex albo blokada w robots.txt. Jeśli te reguły zależą od pliku, prędzej czy później pojadą. Jeśli od zmiennej środowiskowej — nie.

2. Porównanie produkcji ze stagingiem

To najważniejszy artefakt całego audytu. Nie lista błędów na stagingu — lista różnic względem produkcji.

Błędy obecne na obu środowiskach to backlog. Błędy, które pojawiają się dopiero na stagingu, to blocker wdrożenia. Wrzucenie jednego i drugiego do wspólnego raportu to najszybszy sposób, żeby cała Twoja praca wylądowała w zakładce „przeczytam później”.

Procedura: crawlujesz oba środowiska tą samą konfiguracją, normalizujesz adresy do samych ścieżek i porównujesz. Wynik dzielisz na trzy kategorie — adresy znikające, adresy nowe, zmiany w polach na adresach obecnych po obu stronach.

Pola, które porównuję zawsze:

Pole	Co wykrywa różnica
Zbiór ścieżek	Zniknięte i nowe adresy, osierocone strony
Status HTTP	Nowe błędy 404 i 5xx, zamiana przekierowania stałego na tymczasowe
Indeksowalność i jej powód	Nowe `noindex`, blokada, canonical wskazujący gdzie indziej
Tytuł i H1	Puste, zduplikowane, zaciągnięte z szablonu testowego
Adres kanoniczny	Hostname stagingu na produkcji, brak elementu
Reguły dla robotów	Sprawdzaj meta i nagłówek HTTP, nie tylko meta
Objętość treści w kodzie z serwera	Treść, która zniknęła z renderowania serwerowego
Liczba linków wewnętrznych	Nawigacja przeniesiona do JavaScriptu, wycięte okruszki

Wynik podajesz w jednym zdaniu na kategorię: „po wdrożeniu znika 1 240 adresów paginacji, 380 produktów dostaje noindex, 12 szablonów traci H1″. Na to Product Owner umie zareagować. Na „znaleziono 47 problemów SEO” — nie.

Jedna rzecz, o której się zapomina: zarchiwizuj pełny crawl produkcji przed wdrożeniem. Przy większej zmianie to jedyny punkt odniesienia, kiedy dwa tygodnie później ktoś zapyta, czy dany adres w ogóle wcześniej istniał.

3. Renderowanie

Najdroższe wpadki wdrożeniowe biorą się nie z braku metatagów, tylko z renderowania. Treść jest — tylko pojawia się za późno albo dopiero po interakcji.

Trzy sprawdzenia, bez żadnego narzędzia poza przeglądarką i crawlerem:

Porównaj kod źródłowy z tym, co widać po renderze. W kodzie zwróconym przez serwer mają być: H1, opis kategorii, lista produktów, linki nawigacyjne. Jeśli w źródle jest szkielet, a treść widzisz tylko na renderowanej stronie — masz temat na ticket.
Puść dwa crawle: bez renderowania JavaScriptu i z renderowaniem. Różnica w liczbie znalezionych adresów to Twój wynik.
Sprawdź, czy linki są linkami. Element, który wygląda jak link, ale nie ma adresu docelowego w kodzie, nie prowadzi nigdzie z perspektywy crawlera.

Najczęstsze znaleziska: paginacja jako przycisk bez adresu, filtry działające wyłącznie po stronie klienta, opis kategorii doładowywany po przewinięciu. Wszystkie trzy są niewidoczne dla kogoś, kto testuje serwis klikając w przeglądarce.

4. Wydajność

Werdykt: pomiar przed wdrożeniem jest bramką, dane od realnych użytkowników są prawdą. Nie odwrotnie.

Core Web Vitals Google ocenia na danych rzeczywistych — 75. percentyl z okna 28 dni. Progi „dobrego” wyniku, stan na sierpień 2026: LCP do 2,5 s, INP do 200 ms, CLS do 0,1. Dwie konsekwencje, które powiedz zespołowi na głos, zanim zaczniecie:

Przed wdrożeniem nie zmierzysz INP — to metryka wymagająca realnych interakcji. W testach masz tylko wskaźniki zastępcze. Nie mów, że „mierzycie INP”, bo pierwszy dev, który to sprawdzi, przestanie Ci ufać przy każdym kolejnym wymaganiu.

Poprawa wdrożona dziś nie pokaże się w raporcie jutro. Okno 28 dni oznacza, że stare, wolne sesje jeszcze przez tygodnie ciążą na wyniku. Ustal to z Product Ownerem zawczasu, inaczej za dwa tygodnie usłyszysz, że „nie zadziałało”.

Kryteria do Definition of Done

Definition of Done to lista warunków, po spełnieniu których zadanie jest skończone. Jeśli Twojego warunku tam nie ma, Twoje wymaganie jest sugestią.

Poziom globalny — dla każdego zadania oznaczonego jako dotyczące SEO. Maksimum dziesięć pozycji, bo tyle zespół realnie przechodzi:

Adres nie zmienia się bez zaplanowanego przekierowania stałego
Strona zwraca 200; strony błędu zwracają 404 lub 410, nie 200 z komunikatem
Dokładnie jeden nagłówek H1
Tytuł i opis meta z danych, nie z szablonu testowego
Jeden adres kanoniczny, bezwzględny, na właściwym hostnamie
Brak niezamierzonego noindex — w meta i w nagłówku HTTP
Treść krytyczna i linki nawigacyjne w kodzie zwróconym przez serwer
Linki wewnętrzne mają realny adres docelowy
Dane strukturalne poprawne, z wypełnionymi wymaganymi polami
Wydajność zmienionych szablonów w ustalonym budżecie

Poziom warunkowy — zależny od typu zmiany:

Typ zmiany	Dodatkowe kryteria
Nowy szablon	Uzgodniony wzorzec tytułu i adresu kanonicznego; szablon w mapie witryny; dane strukturalne adekwatne do typu
Zmiana struktury adresów	Mapa przekierowań kompletna, bez łańcuchów; linki wewnętrzne na nowe adresy; mapa witryny zaktualizowana
Filtry i facety	Decyzja, które kombinacje są indeksowalne; reszta zablokowana jednym mechanizmem, nie dwoma sprzecznymi
Paginacja	Strony 2+ z własnym tytułem i canonicalem na siebie; linki paginacji z adresem docelowym
Migracja	Brak nierozliczonych różnic w porównaniu prod↔staging; snapshot adresów sprzed migracji; monitoring przez 14 dni
Wersje językowe	Hreflang zwrotny i kompletny; wersja domyślna; canonical w obrębie tej samej wersji

Kryterium ma być sprawdzalne bez wiedzy o SEO. „Canonical zgodny z dobrymi praktykami” — nie do sprawdzenia przez nikogo. „Dokładnie jeden canonical, bezwzględny, ten sam hostname co adres docelowy” — do sprawdzenia w trzy sekundy.

I ma być tam, gdzie zespół pracuje — w szablonie pull requesta, nie w dokumentacji. Blok zaczyna się od furtki: „ten PR nie zmienia adresów, nagłówka strony, statusów, renderowanej treści ani linkowania → zaznacz i pomiń resztę”. Furtka jest ważniejsza niż sama lista.

Współpraca bez wojen

Konflikt SEO–dev prawie nigdy nie dotyczy merytoryki. Dotyczy formy, w jakiej wymagania przychodzą.

Cztery powody, dla których Twoje zadania są odrzucane:

Nie mają kryterium akceptacji, więc nie da się ich wycenić. Zadanie bez estymaty nie wchodzi do sprintu.
Przychodzą hurtem, po fakcie. Audyt przeklejony jako 47 ticketów w jeden poniedziałek to zrzucenie własnego backlogu na cudzy zespół.
Są uzasadnione autorytetem, nie skutkiem. „Bo tak się robi w SEO” nie jest argumentem dla kogoś, kto w tym samym sprincie ma zadanie z policzalnym wpływem na konwersję.
Nie mają priorytetu. Jeśli oznaczasz 47 rzeczy jako blockery, Twoje kolejne „blocker” nie znaczy nic.

Wszystkie cztery to problemy formy. Wszystkie rozwiązuje szablon zadania: tytuł ze skutkiem („brak dostępu do stron 2+ dla robotów”, nie „błąd w paginacji”), skala (ile szablonów, ile adresów), reprodukcja możliwa do powtórzenia bez Twoich narzędzi, stan oczekiwany z zaznaczeniem, co można zostawić bez zmian (bez tego dostaniesz estymatę na przepisanie całego komponentu), trzy do pięciu warunków binarnych i priorytet, który coś znaczy, bo nie jest przyklejony do wszystkiego.

Do tego pięć zasad na spotkania:

Przynoś dowód, nie opinię. Dyskusja o dowodzie trwa minutę, o opinii — pół spotkania.
Podawaj koszt w liczbach, które zespół rozumie. Nie „stracimy pozycje”, tylko „6 400 produktów zostaje bez linkowania wewnętrznego”.
Rozdzielaj wymaganie od preferencji jawnie. Jeśli wszystko brzmi tak samo, zespół uzna, że wszystko jest preferencją.
Nie omijaj Product Ownera. Ustawienie sprawy z deweloperem „na boku” działa raz.
Bądź na refinemencie, nie na demo. Na demo możesz już tylko komentować.

Właścicielem SEO w Definition of Done jest Product Owner Nie specjalista SEO, nie tech lead. SEO dostarcza kryteria i sposób weryfikacji, tech lead odpowiada za wykonalność, ale to PO decyduje, co wchodzi do DoD, i broni tego przy priorytetyzacji. Jeśli właścicielem jest ktoś spoza zespołu, każde kryterium jest zewnętrznym żądaniem — a te przegrywają z wewnętrznymi zawsze.

Antywzorce, które kosztują najwięcej: audyt w PDF wrzucony do systemu zadań, „best practice” jako uzasadnienie, wrzutka w piątek przed wdrożeniem i osobny „backlog SEO” obok backlogu produktu. Ten ostatni jest najgorszy, bo wygląda na sukces — a backlog, którego nie priorytetyzuje Product Owner, nie zostanie zrobiony nigdy.

Od czego zacząć

Krok 1. Zrób pierwsze porównanie produkcji ze stagingiem przed najbliższym wdrożeniem i pokaż wynik zespołowi. Nie proponuj jeszcze procesu — pokaż, ile rzeczy da się wyłapać przed, zamiast po.

Krok 2. Uzgodnij higienę stagingu: autoryzacja plus reguły dla robotów sterowane zmienną środowiskową. To jedna rozmowa i jedna zmiana konfiguracji, a zdejmuje najkosztowniejszy pojedynczy błąd wdrożeniowy.

Krok 3. Dopisz blok SEO do szablonu pull requesta — z furtką „brak wpływu”. Dopiero kiedy to działa przez kilka sprintów, wchodź do Definition of Ready.

Jeśli na którymkolwiek kroku zespół odrzuca zmianę, nie przyspieszaj — cofnij się i uprość. Krótsza lista, którą ktoś naprawdę przechodzi, jest warta więcej niż kompletna, którą wszyscy odklikują.