Lista kontrolna SEO po wdrożeniu: system triage, nie sterta zadań

TL;DR: Najlepsza lista kontrolna SEO po wdrożeniu jest krótsza, niż się spodziewasz. Wdrożenie rzadko zawodzi z powodu jednej zapomnianej meta description. Zawodzi, gdy Google nie może craw­lować, renderować, ufać lub powiązać nowych adresów URL z dotychczasowymi sygnałami autorytetu. Najpierw sprawdź dostęp, renderowanie, przekierowania, kanonikalizację, analitykę i sitemapę. Jeśli te punkty przejdą, strona prawdopodobnie nie „płonie”. Dopiero wtedy można sprzątać.

Przeprowadzałem wdrożenia stron klientów przez mindnow, przebudowałem vadimkravcenko.com, a teraz tworzę seojuice.io – publiczne strony statyczne plus części aplikacyjne, które nie muszą rankować. Panika po wdrożeniu prawie nigdy nie brzmi „zapomnieliśmy jednego atrybutu alt”. Zazwyczaj to „nowa trasa w React zwraca pusty szkielet”, „mapa starych URL-i ma luki” lub „Search Console pokazuje discovered but not indexed, a nikt nie chce przyznać, że strony są ubogie”.

To jest paradygmat, który trzeba przełamać. Lista kontrolna SEO po wdrożeniu powinna być systemem triage, a nie arkuszem, w którym każdy wiersz ma tę samą wagę moralną. Najpierw zatrzymaj krwotok – potem poleruj.

Lista kontrolna SEO po wdrożeniu to triage, a nie zrzut zadań

Standardowe checklisty spłaszczają ryzyko. Brak meta description i zablokowany plik robots.txt nie znajdują się w tej samej kategorii. Podobnie powolny obraz hero i uszkodzona mapa 301 ze starej strony.

Pierwsza godzina służy weryfikacji (to etap, który większość zespołów pomija). Czy roboty dostają się do stron? Czy Google widzi zamierzony adres URL, canonical, treść i status? Czy stare adresy URL, linki wewnętrzne, analityka i cytowania przetrwały? Dopiero potem zespół przechodzi do fazy ulepszeń.

Dlatego dobry audyt techniczny SEO po wdrożeniu zaczyna się od scenariuszy awarii, a nie ozdobników. Wdrożenia są polityczne. Bez porządku każde spotkanie staje się teatrem.

Co zweryfikować w pierwszych 60 minutach po wdrożeniu

Nie zakładaj, że „strona ładuje się w Chrome” oznacza, iż Google widzi treść. Chrome to twoja przeglądarka. Googlebot to crawler z etapami renderowania, kolejkami crawlu, blokowanymi zasobami i innymi zadaniami.

Zacznij od produkcyjnego robots.txt. Potwierdź, że sekcje, które mają rankować, są dozwolone. Następnie sprawdź meta robots, nagłówki x-robots-tag, kody statusu HTTP i tagi canonical. Strony live powinny zwracać 200. Stałe przekierowania — 301. Usunięte strony — 404 lub 410. Canonicals powinny być samoodwołujące lub celowo konsolidujące.

Następnie użyj Inspekcji URL w Google Search Console. Przetestuj jeden URL z każdego indeksowalnego typu strony: strona główna, kategoria, produkt, artykuł, lokalizacja, strona programatyczna oraz każdy nowy szablon. Pobierz stronę. Sprawdź renderowany HTML. Szukaj głównej treści, linków wewnętrznych, canonical, tytułu i danych strukturalnych.

„Głównym problemem przy CSR jest ryzyko, że jeśli coś pójdzie nie tak podczas transmisji, użytkownik nie zobaczy żadnej treści. To może mieć również skutki SEO.”

To ostrzeżenie Martina Splitta, Developer Advocate w Google, opisuje w prostych słowach problem dnia wdrożenia. Client-side rendering nie jest zły – jest kruchy przy wdrożeniu, bo jeden błędny skrypt, błąd hydracji, problem z trasą czy zablokowany asset potrafi zamienić stronę z treścią w pustą skorupę.

• Zcrawl-uj próbkę szablonów, nie tylko homepage.
• Przetestuj jeden URL z każdego indeksowalnego typu.
• Użyj Inspekcji URL do fetcha i renderowanego HTML.
• Upewnij się, że żadna stagingowa reguła noindex nie trafiła na produkcję.
• Potwierdź, że kluczowa treść pojawia się bez interakcji użytkownika.
• Upewnij się, że linki nawigacyjne to crawl-owalne linki HTML, gdzie to możliwe.

Jeśli strona mocno korzysta z JavaScriptu, dodaj przejście JavaScript SEO. View source nie wystarczy. Liczy się renderowany DOM.

Dlaczego przekierowania zasługują na więcej uwagi

Jeśli adresy URL się zmieniły, mapowanie przekierowań jest obowiązkowe. To most między wypracowanymi sygnałami starej strony a nową strukturą.

„Jeśli URL-e się zmieniają i stare nie są poprawnie mapowane na nowe przez 301, strona ryzykuje poważną utratę mocy SEO.”

Glenn Gabe, założyciel G-Squared Interactive, mówi wprost, bo to częsta wpadka. Stare URL-e przekierowują na homepage. Wysyłane są 302 zamiast 301. Łańcuchy przekierowań piętrzą się przez stare ścieżki CMS-a, reguły slash, HTTP → HTTPS i foldery locale (zwykle dlatego, że nikt nie odpowiada za mapę migracji). Adresy z parametrami są porzucane bez sprawdzenia backlinków czy ruchu.

Po wdrożeniu zcrawl-uj listę starych URL-i (nowa strona to ta łatwiejsza połowa). Tam ukrywa się utrata ruchu. Nie crawl-uj tylko nowej strony i nie ogłaszaj sukcesu.

• Stare URL-e powinny prowadzić do najbliższej nowej odpowiednikowej strony.
• Trwałe przeniesienia muszą używać 301.
• Łańcuchy przekierowań należy skracać.
• Linki wewnętrzne mają wskazywać finalne adresy, nie przekierowania.
• XML sitemap nie powinna zawierać przekierowanych i niekanonicznych URL-i.

Google potrafi śledzić przekierowania — celem nie jest testowanie jego cierpliwości. Trzymaj ścieżki bezpośrednie.

Sitemapy i Search Console: przydatne, ale nie magiczne

Większość checklist umieszcza „wyślij sitemapę” na szczycie, jakby wymuszało to indeksację. Google Search Central mówi, że zgłoszenie sitemapy to „jedynie wskazówka” i nie gwarantuje pobrania, crawlowania ani użycia.

Sitemap-y są jednak przydatne — pomagają w odkryciu, ujawniają problemy raportowania i dają Search Console czystą powierzchnię do odczytu. Liczą się szczególnie, gdy strona jest nowa, ma mało linków zewnętrznych, dużo stron lub URL-e trudne do znalezienia przez nawigację.

Raz widziałem sitemapę pełną przekierowanych URL-i, która ukryła prawdziwy problem: nowe strony kanoniczne były słabo podlinkowane.

• Prześlij poprawny indeks XML sitemap w Google Search Console.
• Usuń URL-e ze stagingu, starej domeny, przekierowane, zablokowane i niekanoniczne.
• Dziel pliki przed 50 MB (bez kompresji) lub 50 000 URL-i.
• Ufaj lastmod tylko, jeśli CMS zapisuje ją poprawnie.
• Porównuj zgłoszone vs zaindeksowane według typu szablonu.

Zgłoszenie sitemapy to logistyka. Indeksowanie trzeba sobie zasłużyć.

Jeśli nie możesz zmierzyć wdrożenia, nie naprawisz go

Wszyscy mówią, że tracking działa. A potem psuje się thank-you page, baner zgody, zdarzenie checkout lub odwołanie cross-domain.

Zanim zaczniesz dyskusję o rankingach, upewnij się, że pomiar działa. GA4 powinien odpalać się na każdym publicznym szablonie. Search Console musi być zweryfikowany dla właściwej właściwości (protokół, subdomena i domena mają znaczenie). Bing Webmaster Tools warto dodać, jeśli strona liczy na ruch z Binga, Copilota lub enterprise search.

• Wyeksportuj dane rankingu przed wdrożeniem.
• Wyeksportuj organiczne landing pages według URL, szablonu, kraju i urządzenia.
• Upewnij się, że logi serwera lub CDN są dostępne, gdy crawl spadnie.
• Dodaj adnotację o wdrożeniu w narzędziach analitycznych.
• Przetestuj zdarzenia konwersji po trybie zgody i regułach tag managera.

Czytelnik musi wiedzieć, czy ruch zmienił się przez rankingi, indeksację, pomiar, sezonowość czy złe przekierowanie. Bez bazowej linii spotkanie po wdrożeniu zamienia się w zgadywanie na wykresach.

Core Web Vitals po wdrożeniu: mierz teraz, nie czekaj na CrUX

HTTP Archive Web Almanac 2025 pokazuje, dlaczego wydajność zasługuje na uwagę w dzień wdrożenia. HTTPS i title tagi są powszechne: HTTPS ma ok. 91,7 % stron desktopowych i 91,5 % mobilnych, a title tagi – 98,6 % desktop/98,5 % mobile. Core Web Vitals są słabsze: ogólny wskaźnik zaliczonych testów to 56 % na desktopie i 48 % na mobile.

To oznacza, że Core Web Vitals to jedno z najczęstszych miejsc, gdzie wdrożenia zawodzą — zdecydowanie nie poboczny temat.

INP stało się stabilnym Core Web Vital 12 marca 2024, zastępując FID. Progi są proste: 200 ms lub mniej to wynik dobry; 200–500 ms wymaga poprawy; powyżej 500 ms jest słabo. Web Almanac raportuje, że INP zalicza 77 % stron mobilnych i 97 % desktopowych. Tylko 53 % top 1000 stron przechodzi, co mówi sporo o dużych serwisach z ciężkim JS-em.

CrUX używa 28-dniowego okna, więc nowe strony mogą nie mieć od razu danych field. Korzystaj z Lighthouse, lab PageSpeed Insights, WebPageTest, RUM i testów na poziomie szablonów, dopóki dane field nie dojrzeją.

• Testuj mobile first.
• Testuj najwolniejszy szablon, a nie najładniejszą stronę.
• Obserwuj LCP na obrazach hero i czas odpowiedzi serwera.
• Obserwuj INP na menu, filtrach, akordeonach, wyszukiwarce, formularzach i konfiguratorach.
• Obserwuj CLS po załadowaniu fontów, reklam, banerów, embedów i komunikatów cookies.

Jakość treści i linki wewnętrzne: “Discovered, currently not indexed” to nie problem przycisku

Ludzie widzą „Discovered, currently not indexed” i zaczynają ponownie zgłaszać URL-e. To może pomóc Google ponownie znaleźć stronę. Nie sprawi, że będzie warta indeksacji.

„W większości przypadków chodzi jednak o ogólną jakość strony.”

Ta uwaga Johna Muellera, Search Advocate w Google, to przydatny klaps. Większość checklist traktuje indeksowanie jak problem konfiguracyjny. Mueller przekłada to na problem jakości.

Sprawdź, czy ważne strony są podlinkowane z nawigacji, hubów, okruszków lub sekcji related. Szukaj linków w treści, które zniknęły przy redesignie. Przejrzyj cienkie strony lokalizacji, kategorii, tagów czy programatyczne, które rozmnożyły się po wdrożeniu. Upewnij się, że unikalna treść nie jest ukryta pod zakładkami, skryptami czy generycznym hero copy.

Tutaj liczy się strategia linkowania wewnętrznego. Linki wewnętrzne to nie tylko ścieżki crawlu. To priorytet redakcyjny. Jeśli strona nie wskazuje na inny URL, komunikuje wyszukiwarkom, że nie jest on kluczowy.

Sprawdź tytuły, kanoniczne, schemę i metadane — ale ich nie ubóstwiaj

Metadane wciąż są ważne. Po prostu należą do odpowiedniego segmentu.

Web Almanac 2025 znalazł tagi canonical na ok. 68 % stron desktop i 67 % mobile. Tytuły są prawie uniwersalne. HTTPS – standard. To stolikowe stawki, a nie miejsce największych katastrof.

Przy jednej przebudowie stagingowe schema z fikcyjnymi recenzjami trafiło na produkcję. Problem był widoczny dla każdego w view-source.

• Użyj unikalnych title tagów na indeksowalnych szablonach.
• Napisz meta descriptions dla stron, gdzie liczy się CTR.
• Ustaw jeden jasny canonical na każdej indeksowalnej stronie.
• Sprawdź podglądy Open Graph dla stron udostępnianych po wdrożeniu.
• Waliduj structured data dla produktów, artykułów, breadcrumbs, organizacji, lokalnych firm, FAQ i recenzji tam, gdzie to możliwe.
• Testuj hreflang, jeśli istnieją warianty językowe lub regionalne.
• Usuń schemę skopiowaną ze stagingu, starych marek czy złych URL-i.

Zrób to. Po prostu nie myl kompletności metadanych z bezpieczeństwem wdrożenia.

Kontrola 2026: zasady dla crawlerów AI i ciągłość cytowań

Polityka crawlerów AI to teraz decyzja dnia wdrożenia (w 2026 nie ma już odwrotu). Web Almanac 2025 znalazł reguły gptbot w 4,5 % stron desktop i 4,2 % mobile, co oznacza ok. 55 % wzrost r/r. Reguły claudebot prawie się podwoiły do 3,6 % desktop/3,4 % mobile.

Nie oznacza to, że pozwolenie GPTBot gwarantuje widoczność w AI search. Oznacza, że robots.txt coraz częściej służy do kontroli dostępu crawlerów AI i zespół wdrożeniowy potrzebuje jednej udokumentowanej polityki.

1. Zdecyduj, czy pozwalasz, czy blokujesz główne crawlery AI przed wdrożeniem.
2. Zachowaj ciągłość cytowań przez przekierowanie starych URL-i z wzmiankami, linkami i referencjami.
3. Utrzymuj spójne sygnały encji: nazwa marki, autorzy, schema organizacji, strony o nas, kontakt, nazwy produktów i kanoniczne strony źródłowe.

Zerwane URL-e mogą zniszczyć ścieżki cytowań, na których polegają systemy wyszukiwania i silniki odpowiedzi. Zachowaj crawl-owalność stron dowodzących, kim jesteście.

7-dniowa pętla monitoringu po wdrożeniu

Dzień 0 to dostęp i rendering. Dzień 1 – przekierowania, analityka i raporty sitemapy. Dni 2–7 to wykrywanie wzorców.

• Przeglądaj pokrycie i indeksowanie w Search Console według szablonu.
• Sprawdzaj błędy serwera i soft 404.
• Ponownie crawl-uj starą listę URL-i pod kątem błędnych przekierowań.
• Znajdź landing pages organic, które zniknęły.
• Sprawdź zapytania brandowe i indeksowanie homepage.
• Obserwuj nowe strony utkwione w discovered lub crawled but not indexed.
• Analizuj skoki lub spadki crawl w logach.
• Przetestuj ponownie tracking konwersji.
• Śledź kluczowe frazy, ale spodziewaj się wczesnej zmienności.

Cierpliwość jest ważna — nie każdy spadek to katastrofa. Ale każdy niemierzony spadek staje się polityczną kłótnią.

Przegląd po 30 dniach: co naprawić, gdy pożar zgasł

Po pierwszym tygodniu przestań szukać tylko krytycznych błędów. Zacznij wzmacniać słabe obszary.

• Przeglądaj field Core Web Vitals, gdy pojawią się dane.
• Znajdź strony z wyświetleniami, ale słabym CTR.
• Dodaj linki wewnętrzne do nowych, strategicznych stron.
• Porównaj indeksowanie według typu szablonu.
• Wyczyść zalegające przekierowane linki wewnętrzne.
• Przejrzyj treści, które straciły pozycje po przepisaniu lub scaleniu.
• Napraw ostrzeżenia schema i problemy z rich results.
• Potwierdź politykę crawlerów AI z działem prawnym i brand.
• Wzmocnij sygnały ekspertyzy, kontekst autorów i treści wspierające.

Wtedy dobre monitorowanie SEO zaczyna się zwracać. Nie oceniasz każdego wyniku w 48 godzin. Oceniasz, czy system zdrowieje.

Lista kontrolna SEO po wdrożeniu – kopiuj i wklej

Dostęp i indeksowalność

• Produkcyjny robots.txt dopuszcza zamierzone sekcje.
• Nie pozostały stagingowe dyrektywy noindex.
• Indeksowalne strony zwracają 200.
• Usunięte strony zwracają 404 lub 410.
• Canonicals wskazują zamierzone URL-e.
• Inspekcja URL potwierdza fetch i render.

Renderowanie i szablony

• Główna treść pojawia się w renderowanym HTML.
• Linki nawigacyjne są crawl-owalne.
• Ważne linki nie są ukryte za akcją użytkownika.
• Błędy JS nie blokują treści strony.
• Każdy główny szablon przetestowany na mobile.

Przekierowania i ciągłość URL

• Stara lista URL-i zcrawl-owana po wdrożeniu.
• Jednoetapowe 301 dla zmienionych URL-i.
• Przekierowania prowadzą do równoważnych stron, nie homepage.
• Linki wewnętrzne wskazują finalne adresy.
• XML sitemap wyklucza przekierowane URL-e.

Search Console i sitemapy

• Zweryfikowano właściwą właściwość.
• Przesłano indeks sitemap.
• Sitemap zawiera tylko kanoniczne, indeksowalne URL-e.
• Monitorowany stosunek zgłoszone vs zaindeksowane według szablonu.
• Sprawdzono ręczne działania i problemy z bezpieczeństwem.

Analityka i tracking

• GA4 odpala na wszystkich publicznych szablonach.
• Zapisano organiczne landing pages.
• Przetestowano konwersje.
• Dodano adnotację o wdrożeniu.
• Wyeksportowano bazowe rankingi i ruch.

Wydajność

• Sprawdzono LCP na kluczowych szablonach.
• INP przetestowano na elementach interaktywnych.
• CLS sprawdzono po załadowaniu banerów, fontów i embedów.
• Użyto narzędzi lab do czasu dojrzewania danych CrUX.
• Najpierw test mobile, potem desktop.

Treść i linki wewnętrzne

• Strony priorytetowe podlinkowane z hubów lub nawigacji.
• Ważne stare treści nie usunięto bez zastępstwa.
• Przejrzano cienkie strony programatyczne.
• Tytuły i nagłówki odpowiadają intencji wyszukiwania.
• Zidentyfikowano strony osierocone.

Dane strukturalne i metadane

• Unikalne tytuły na indeksowalnych stronach.
• Meta descriptions sprawdzone dla kluczowych stron.
• Sprawdzono schema breadcrumbs.
• Przetestowano schema produktów, artykułów, organizacji, lokalnych, recenzji – gdzie dotyczy.
• Przetestowano hreflang, jeśli dotyczy.

AI search i polityka crawlerów

• Udokumentowano reguły robots.txt dla crawlerów AI.
• Przekierowano stare cytowane URL-e.
• Zachowano spójne dane marki i autorów.
• Strony o nas, kontakt i źródłowe pozostają crawl-owalne.
• Zachowano kluczowe strony informacyjne podczas migracji.

Jeśli masz tylko godzinę, sprawdź dostęp crawlu, renderowanie, przekierowania, canonicale, analitykę i sitemapę. Jeśli te punkty przechodzą, wdrożenie raczej nie płonie. Wtedy zaczyna się prawdziwa praca SEO.

FAQ

Kiedy uruchomić listę kontrolną SEO po wdrożeniu?

Sprawdzenia dostępu, renderowania, robots, kodu statusu, canonical, analityki i przekierowań wykonaj w pierwszej godzinie. Sitemapy, Search Console i crawl starej listy URL — pierwszego dnia. Indeksację, logi, rankingi i konwersje obserwuj przez pierwszy tydzień.

Czy wystarczy wysłać sitemapę, by nowa strona została zaindeksowana?

Nie. Google twierdzi, że wysłanie sitemapy to „tylko wskazówka”. Zrób to, bo pomaga w odkryciu i raportowaniu, zwłaszcza dla nowych lub dużych stron. Nie traktuj tego jak przycisku do indeksowania.

Jaki jest największy błąd SEO po wdrożeniu?

Najdroższe wpadki to zablokowany crawl, błędne renderowanie, złe przekierowania, błędne canonicale i brak pomiaru. Błędy metadanych łatwiej naprawić, gdy strona się ustabilizuje.

Czy powinienem sprawdzać stare URL-e, czy tylko nową stronę?

Obie, ale crawl-uj starą listę URL-i po wdrożeniu. Tam wychodzą utracone equity, zerwane backlinki, złe mapowania i przekierowania na homepage. To sedno SEO przy migracji stron.

Kiedy sprawdzić Core Web Vitals po wdrożeniu?

Testuj od razu narzędziami lab i RUM. Dane field CrUX działają z 28-dniowym oknem, więc nowe strony mogą potrzebować czasu, by pojawiły się stabilne raporty.

Potrzebujesz pomocy w znalezieniu problemów wdrożeniowych, które naprawdę mają znaczenie?

SEOJuice pomaga zespołom wyłapać to, co zmienia wyniki: zerwane linki wewnętrzne, słabą priorytetyzację stron, brak kontekstu i problemy SEO po wdrożeniu ukryte pod powierzchnią. Jeśli twoja strona właśnie wystartowała, zacznij od triage powyżej, a potem użyj SEOJuice, by utrzymać tempo sprzątania.