Brak indeksacji po migracji domeny lub adresów URL. Jak ustalić, gdzie pojawia się problem?

Brak indeksacji po migracji domeny lub adresów URL. Jak ustalić, gdzie pojawia się problem?

Lead: Przekierowania 301 lub 308 działają, ale nowe adresy URL pozostają poza indeksem Google? Sprawdź, jak odróżnić problemy z odkrywaniem i skanowaniem stron od błędów kanonikalizacji, jak interpretować statusy Search Console oraz kiedy naprawiać konfigurację, monitorować migrację lub przekazać problem zespołowi technicznemu.

Poprawne przekierowanie nie gwarantuje indeksacji strony docelowej. Google musi odkryć nowy adres, uzyskać dostęp do jego zawartości, przetworzyć ją i ustalić, czy strona powinna znaleźć się w indeksie jako wersja kanoniczna. Nawet obecność w indeksie nie oznacza, że adres będzie uzyskiwał wyświetlenia w wynikach wyszukiwania.

Dlatego diagnostyka po migracji wymaga rozdzielenia kilku zagadnień. Innego działania potrzebuje strona, której Google jeszcze nie zeskanował, innego adres pobrany, ale niezindeksowany, a jeszcze innego strona uznana za duplikat.

Podstawą oceny powinny być dane Google Search Console, aktualna konfiguracja witryny oraz, gdy wymaga tego problem, logi serwera i dane infrastruktury. Sam status w raporcie rzadko wystarcza do jednoznacznego ustalenia przyczyny.

Dlaczego przekierowanie 301 lub 308 nie gwarantuje indeksacji?

Kody HTTP 301 i 308 oznaczają trwałe przeniesienie zasobu. Google traktuje je jako silny sygnał, że adres docelowy powinien zostać uznany za kanoniczny.

Nie oznacza to jednak automatycznego dodania nowego URL do indeksu ani gwarancji zachowania wcześniejszej widoczności strony.

Zgodnie z dokumentacją Redirects and Google Search oba kody należą do przekierowań trwałych. Samo zastosowanie 308 zamiast 301 nie stanowi więc uzasadnionej diagnozy problemu z indeksacją.

Inaczej interpretowane są przekierowania tymczasowe, między innymi 302 i 307. Google może za nimi podążać, ale nie traktuje ich jako sygnału kanoniczności w taki sam sposób jak przekierowań trwałych.

Migracja jest przetwarzana na poziomie poszczególnych adresów. Google musi ponownie odwiedzić stare i nowe zasoby oraz uwzględnić zmianę ich lokalizacji. Tempo zależy między innymi od liczby URL i możliwości serwera.

W dokumentacji How to move a site Google wskazuje, że w przypadku średnich witryn proces stopniowego zastępowania starych adresów nowymi może trwać kilka tygodni lub dłużej. Przy większych serwisach może potrwać jeszcze więcej czasu.

Nie istnieje jednak jeden termin, po którego upływie wszystkie nowe adresy muszą być zaindeksowane.

Trzeba też rozróżnić deklarację, że przekierowania działają, od wyniku rzeczywistej kontroli. Poprawne odpowiedzi kilku starych URL nie potwierdzają poprawności całego mapowania ani indeksowalności stron docelowych.

Co sprawdzić przed analizą statusów indeksowania?

Pierwszym etapem powinna być kontrola konfiguracji, którą można wykonać niezależnie od raportów Google.

Dla reprezentatywnych par starych i nowych adresów należy sprawdzić:

1. Odpowiedź starego URL. Czy serwer zwraca zamierzony kod przekierowania, zwykle 301 lub 308, i wskazuje właściwy adres w nagłówku Location?

2. Docelowy zasób. Czy przekierowanie prowadzi do odpowiednika starej strony, a nie przypadkowego lub niepowiązanego tematycznie adresu?

3. Końcowy status HTTP. Czy strona przeznaczona do indeksowania zwraca prawidłową odpowiedź, zwykle 200, zamiast błędu 4xx, 5xx lub kolejnego nieoczekiwanego przekierowania?

4. Łańcuch przekierowań. Czy stary URL prowadzi bezpośrednio do końcowego zasobu? Google zaleca unikanie niepotrzebnych łańcuchów.

5. Dyrektywy indeksowania. Czy docelowa strona nie zawiera przypadkowego noindex w HTML lub nagłówku X-Robots-Tag?

6. Dostępność dla Googlebota. Czy robots.txt, system zabezpieczeń, CDN lub WAF nie ograniczają dostępu do strony albo zasobów potrzebnych do jej renderowania?

7. Sygnały kanoniczności. Czy deklaracje rel="canonical", linkowanie wewnętrzne i mapa witryny wskazują właściwe nowe adresy?

8. Zawartość strony. Czy Google może uzyskać dostęp do zasadniczej treści, także gdy jest generowana przez JavaScript?

9. Konfigurację Search Console. Czy dostępne są właściwe usługi dla starej i nowej lokalizacji oraz czy porównywane dane obejmują odpowiednie domeny, hosty i protokoły?

Co zrobić z adresami, które nie mają nowego odpowiednika?

Nie każdy stary URL powinien zostać przekierowany.

Jeżeli zawartość rzeczywiście przeniesiono lub połączono z inną, odpowiadającą jej treścią, właściwe może być trwałe przekierowanie na nowy zasób.

Jeżeli strona została usunięta i nie istnieje odpowiedni zamiennik, należy rozważyć zwrócenie kodu HTTP 404 lub 410.

Masowe przekierowanie niepowiązanych podstron na stronę główną nowej domeny może zostać zakwalifikowane przez Google jako soft 404. Sam kod 301 lub 308 nie czyni takiego mapowania prawidłowym.

Dlaczego robots.txt i noindex nie są zamienne?

Plik robots.txt służy przede wszystkim do zarządzania dostępem robotów do zasobów. Dyrektywa noindex informuje obsługujące ją wyszukiwarki, że dana zawartość nie powinna być indeksowana.

Jeśli Googlebot nie może pobrać strony z powodu blokady w robots.txt, może nie zobaczyć znajdującej się na niej dyrektywy noindex.

Co istotne, adres zablokowany w robots.txt może w określonych okolicznościach nadal pojawić się w wynikach wyszukiwania, na przykład gdy prowadzą do niego linki z innych stron.

Zasady te opisuje dokumentacja Block Search indexing with noindex.

Jak długo utrzymywać przekierowania po migracji?

Google zaleca utrzymywanie przekierowań możliwie długo, zasadniczo przez co najmniej rok.

Okres ten pozwala systemom Google ponownie odwiedzać stare adresy i przetwarzać sygnały związane z ich przeniesieniem. Nie oznacza, że po roku każda migracja zostaje automatycznie zakończona.

Z perspektywy użytkowników warto rozważyć pozostawienie przekierowań nawet bezterminowo, zwłaszcza jeśli stare adresy nadal występują w linkach zewnętrznych.

Jednocześnie linki wewnętrzne i inne kontrolowane odwołania powinny prowadzić bezpośrednio do nowych zasobów, bez zbędnego przechodzenia przez przekierowania.

Kiedy używać narzędzia Zmiana adresu w Google Search Console?

Narzędzie Change of Address służy do określonych migracji między domenami lub subdomenami. Należy używać go po wdrożeniu odpowiednich przekierowań i spełnieniu warunków wskazanych przez Google.

Nie służy natomiast do:

• zwykłej zmiany ścieżek URL w obrębie tej samej domeny,

• przejścia z HTTP na HTTPS,

• zmiany między wariantami www i bez www tej samej domeny,

• zmiany hostingu lub CDN bez zmiany adresów widocznych dla użytkowników.

Narzędzie wymaga odpowiednich uprawnień do usług Search Console. Przy migracji całej domeny trzeba również uwzględnić jej subdomeny i warianty zgodnie z instrukcją Google.

Szczegółowe zasady określa Change of Address tool.

Samo użycie narzędzia nie zastępuje prawidłowych przekierowań, aktualizacji linkowania ani kontroli indeksowania.

Odkrycie URL, skanowanie, kanonikalizacja i indeksacja to różne procesy

W diagnostyce przydaje się uproszczony model:

Odkrycie adresu → pobranie strony → przetworzenie treści → ocena kanoniczności i indeksowania → możliwość wyświetlenia w wynikach wyszukiwania.

To schemat diagnostyczny, a nie ścisła, zawsze liniowa kolejność wewnętrznych operacji Google.

Odkrycie URL oznacza, że Google uzyskał informację o istnieniu adresu, na przykład z linku, przekierowania lub mapy witryny. Nie oznacza jeszcze pobrania jego zawartości.

Skanowanie (crawling) polega na próbie pobrania zasobu. Udane pobranie nie gwarantuje jego indeksacji.

Przetwarzanie i renderowanie pozwalają systemom Google analizować treść strony. W przypadku witryn wykorzystujących JavaScript potrzebne może być dodatkowe renderowanie przed uzyskaniem pełnej zawartości.

Kanonikalizacja polega na wyborze adresu reprezentującego zbiór stron o identycznej lub bardzo podobnej zawartości. Google uwzględnia deklaracje właściciela witryny, ale nie musi przyjąć wskazanego wariantu.

Indeksacja oznacza uwzględnienie zawartości w indeksie Google. Techniczna możliwość indeksowania nie stanowi gwarancji jej wykonania.

Wyświetlanie w wynikach wyszukiwania zależy od kolejnych warunków, między innymi zapytania użytkownika i systemów ustalania wyników.

Rozdzielenie tych procesów pozwala uniknąć sytuacji, w której każdy brak widoczności zostaje błędnie uznany za problem z indeksacją.

Co oznaczają statusy Google Search Console po migracji?

„Strona wykryta - obecnie niezindeksowana”

Status „Discovered – currently not indexed” oznacza, że według raportowanych danych Google zna adres, ale jeszcze go nie zeskanował.

Dokumentacja Google wskazuje, że częstym powodem odłożenia skanowania jest przewidywane nadmierne obciążenie witryny. Nie oznacza to jednak, że na podstawie samego statusu można potwierdzić przeciążenie konkretnego serwera.

Nie jest to także dowód słabej jakości treści, problemów z autorytetem domeny ani nałożenia kary.

W pierwszej kolejności warto sprawdzić:

• dostępność serwera, DNS i robots.txt,

• statystyki skanowania dostępne w Search Console,

• rzeczywiste żądania Googlebota w logach, jeśli są dostępne,

• linkowanie wewnętrzne prowadzące do nowych adresów,

• aktualność mapy witryny i prawidłowość wskazanych URL.

Należy również pamiętać, że raport może przedstawiać stan opóźniony względem aktualnej konfiguracji strony.

Jeżeli nie stwierdzono błędów technicznych, sam status nie uzasadnia automatycznej przebudowy treści ani konfiguracji całej domeny.

„Strona zeskanowana, ale jeszcze niezindeksowana”

Status „Crawled – currently not indexed” oznacza, że Google pobrał stronę, ale nie uwzględnił jej w indeksie w raportowanym stanie.

Nie należy zatem rozpoczynać diagnostyki od założenia, że wyszukiwarka nie zna adresu.

Dalsza analiza powinna objąć:

• treść i jej podobieństwo do innych stron,

• aktualne dyrektywy indeksowania,

• deklarowany adres kanoniczny,

• adres kanoniczny wybrany przez Google, jeśli dane są dostępne,

• poprawność renderowania,

• dostępność zasobów i działanie szablonu.

Informacje o canonical wybranym przez Google pochodzą z danych indeksowania. Test aktywnego URL nie pozwala przewidzieć ostatecznego wyboru kanoniczności, a nie wszystkie informacje będą dostępne dla każdego badanego adresu.

Status „zeskanowana, ale niezindeksowana” nie ujawnia dokładnej przyczyny decyzji Google. Samodzielnie nie potwierdza problemu jakościowego, niedostatecznego E-E-A-T ani sankcji.

Google wskazuje również, że przy tym statusie nie ma potrzeby rutynowego ponawiania zgłoszeń URL do skanowania.

Oba statusy opisuje dokumentacja Page indexing report.

Test aktywnego URL jest poprawny, ale strony nie ma w indeksie

Narzędzie URL Inspection udostępnia dwa rodzaje informacji:

• dane dotyczące adresu znane systemom indeksowania Google,

• wynik testu aktualnie dostępnej wersji strony.

Te informacje nie muszą być identyczne.

Pozytywny test aktywnego URL oznacza, że narzędzie Google-InspectionTool nie wykryło określonych przeszkód w pobraniu i analizie strony.

Nie oznacza jednak, że adres jest zaindeksowany, zostanie wybrany jako kanoniczny lub na pewno pojawi się w wynikach wyszukiwania.

Test nie sprawdza wszystkich możliwych powodów braku indeksacji. Nie rozstrzyga też ostatecznej oceny jakości strony.

Istotne ograniczenie dotyczy przekierowań. Test aktywnego URL może za nimi podążyć, ale nie pokazuje pełnej ścieżki ani końcowego adresu, który został sprawdzony.

Dlatego weryfikację przekierowań należy wykonywać również niezależnie, na poziomie odpowiedzi HTTP.

Jeżeli po migracji usunięto przypadkowy noindex, test aktywny może już wskazywać poprawny stan, podczas gdy dane indeksowania nadal odzwierciedlają poprzednią wersję strony.

Należy wtedy porównać moment wdrożenia poprawki, datę ostatniego skanowania i informacje dostępne w URL Inspection.

Szczegóły ograniczeń zawiera URL Inspection tool.

Macierz diagnostyczna: obserwacja, dowód, kolejny test i decyzja

Poniższa tabela pozwala ustalić następny krok bez przypisywania każdemu statusowi jednej, z góry założonej przyczyny.

Macierz jest narzędziem interpretacyjnym opartym na dokumentacji Google. Nie przedstawia wyników badania konkretnej migracji.

Jej najważniejszą zasadą jest oddzielenie obserwacji od przyczyny. Dopiero kolejny test powinien potwierdzić lub wykluczyć określony mechanizm.

Google wybrał inną stronę kanoniczną. Czy trzeba to naprawiać?

Po migracji nowy URL może deklarować własny rel="canonical", a mimo to Google wskaże inny adres jako wersję kanoniczną.

Nie każdy taki przypadek wymaga naprawy.

Google traktuje trwałe przekierowania i rel="canonical" jako silne sygnały kanoniczności. Obecność URL w sitemapie jest sygnałem słabszym.

Żaden z tych mechanizmów nie wymusza jednak bezwarunkowo wyboru wskazanego adresu.

Jeżeli dwa URL prowadzą do treści identycznych lub bardzo podobnych, wybranie jednego reprezentatywnego adresu może być prawidłowym zachowaniem.

Problem pojawia się wtedy, gdy strony mają odrębną treść lub funkcję, ale Google traktuje je jako warianty tego samego zasobu albo konfiguracja kieruje go do niewłaściwego adresu.

Diagnostyka powinna obejmować:

1. Porównanie rzeczywistej zawartości obu stron.

2. Kontrolę przekierowań i ich adresów docelowych.

3. Sprawdzenie deklaracji rel="canonical", także w nagłówkach HTTP, jeśli mają zastosowanie.

4. Weryfikację linków wewnętrznych.

5. Kontrolę URL umieszczonych w sitemapie.

6. Sprawdzenie, czy zasoby są dostępne i prawidłowo renderowane.

Po migracji zalecane jest aktualizowanie deklaracji kanoniczności do nowych adresów. Dla nowych stron, które mają być samodzielnymi wersjami kanonicznymi, odpowiednia jest deklaracja wskazująca własny URL.

Nie oznacza to jednak, że automatyczne ustawienie self-canonical na każdej możliwej odmianie adresu rozwiązuje problemy z duplikacją.

Reguły kanonikalizacji opisuje How to specify a canonical URL.

Czy Google ma 14 dni na indeksację po migracji?

Nie istnieje ogólny, czternastodniowy termin indeksacji po migracji.

W dokumentacji Fix Canonicalization Issues Google wskazuje, że po poprawieniu problemów z treścią strony mogą pozostawać w grupie duplikatów nawet przez dwa tygodnie.

Informacja dotyczy ponownej oceny podobnych stron po zmianach w zawartości.

Nie stanowi terminu zakończenia migracji domeny, ponownego pobrania całej witryny ani gwarancji indeksacji.

Nie należy więc interpretować przekroczenia 14 dni jako automatycznego dowodu błędu technicznego. Równie błędne byłoby założenie, że przed upływem tego okresu nie warto naprawiać potwierdzonych problemów.

Czy renderowanie JavaScript może utrudniać indeksację po migracji?

Tak. Ma to szczególne znaczenie, gdy migracja obejmowała również zmianę CMS, frameworka lub sposobu renderowania stron.

Kod HTTP 200 potwierdza określoną odpowiedź serwera. Nie dowodzi jednak, że Google uzyskał dostęp do całej właściwej treści strony.

W witrynach opartych na JavaScript początkowy dokument HTML może zawierać jedynie podstawową strukturę aplikacji. Właściwa treść pojawia się dopiero po wykonaniu skryptów.

Google potrafi renderować JavaScript, ale jest to osobny element przetwarzania strony. Problemy z zasobami, wykonywaniem skryptów lub generowaniem zawartości mogą utrudniać uzyskanie oczekiwanego wyniku.

W takiej sytuacji należy:

• sprawdzić początkową odpowiedź HTML,

• porównać ją z wyrenderowaną zawartością,

• sprawdzić podstawową treść, linki i deklaracje canonical,

• przeanalizować błędy JavaScript oraz zasoby niedostępne podczas testu,

• upewnić się, że istotna zawartość nie zależy od interakcji, której Google nie wykonuje.

Test aktywnego URL w Search Console udostępnia, przy spełnieniu odpowiednich warunków, podgląd wyrenderowanej strony, HTML oraz dodatkowe dane diagnostyczne.

Zasady opisuje dokumentacja Understand the JavaScript SEO basics.

Co pokazują Crawl Stats, logi serwera i raporty skuteczności?

Dane wykorzystywane podczas audytu po migracji nie mierzą tych samych zdarzeń.

Ich porównywanie bez zrozumienia definicji metryk i zakresu raportów może prowadzić do błędnych wniosków.

Crawl Stats: aktywność skanowania i stan hosta

Raport Crawl Stats przedstawia statystyki związane ze skanowaniem witryny przez Google, między innymi odpowiedzi serwera, typy pobieranych zasobów i informacje o dostępności hosta.

Umożliwia analizę problemów z połączeniem, DNS oraz pobieraniem robots.txt.

Raport nie jest jednak dostępny dla każdego typu usługi Search Console. Google udostępnia go dla usług obejmujących poziom główny, takich jak właściwość domeny lub właściwość z prefiksem URL na poziomie głównym hosta.

W przypadku migracji między domenami należy uwzględnić zakres poszczególnych usług i nie traktować danych jednej właściwości jako kompletnego obrazu starej i nowej infrastruktury.

Istotne jest również rozumienie liczników.

Crawl Stats raportuje rzeczywiście żądane adresy URL, bez automatycznego przypisywania ich do adresów kanonicznych.

Żądania poszczególnych adresów w łańcuchu przekierowań mogą być liczone oddzielnie.

Google wskazuje też, że łączne wartości mogą uwzględniać próby skanowania porzucone z powodu niedostępności robots.txt, mimo że właściwe pobranie strony nie nastąpiło.

Z kolei nie wszystkie rzeczywiste żądania muszą być uwzględnione w raporcie.

Crawl Stats nie jest więc pełnym odpowiednikiem logów serwera.

Szczegóły podaje Crawl Stats report.

Logi serwera: rzeczywiste żądania i ich ograniczenia

Logi dostarczają informacji o ruchu zarejestrowanym przez określoną warstwę infrastruktury.

W zależności od konfiguracji mogą zawierać:

• datę i godzinę żądania,

• żądany adres lub ścieżkę,

• status HTTP,

• adres IP klienta,

• identyfikator User-Agent,

• czas obsługi żądania.

Podczas analizy ruchu Googlebota nie wystarczy jednak znaleźć wpisy zawierające nazwę Googlebot.

Identyfikator User-Agent może zostać sfałszowany.

Google opisuje dwie metody potwierdzania pochodzenia żądań: weryfikację reverse DNS połączoną z forward DNS oraz sprawdzenie adresów IP względem oficjalnie publikowanych zakresów.

Procedura znajduje się w dokumencie Verify requests from Google crawlers and fetchers.

Trzeba także wiedzieć, gdzie rejestrowany jest ruch.

Logi aplikacji nie muszą zawierać żądań obsłużonych wcześniej przez CDN, reverse proxy lub inne warstwy infrastruktury.

Dlatego brak wpisu w pojedynczym pliku logów nie dowodzi, że Google w ogóle nie próbował pobrać danego zasobu.

Page Indexing i URL Inspection: stan indeksowania

Raport Page Indexing przedstawia informacje o indeksowaniu stron znanych Google w ramach określonej usługi Search Console.

Lista przykładów dla danego statusu jest ograniczona do 1000 adresów. Google zaznacza również, że nie musi ona zawierać wszystkich adresów w danym stanie, nawet gdy przykładów jest mniej niż 1000.

Nie należy traktować tej listy jako kompletnego eksportu wszystkich problematycznych URL.

Dane konkretnej strony warto sprawdzać w URL Inspection, uwzględniając datę ostatniego skanowania i dostępność poszczególnych informacji.

Po zmianie konfiguracji witryny dane indeksowania mogą przez pewien czas odzwierciedlać wcześniejszy stan.

Performance: wyświetlenia i kliknięcia

Raport skuteczności Search Console pokazuje dane dotyczące widoczności witryny w wynikach wyszukiwania Google.

Wyświetlenia, kliknięcia i pozycje są zasadniczo przypisywane adresowi kanonicznemu wybranemu przez Google. Istnieją jednak wyjątki, gdy dane mogą zostać przypisane rzeczywistemu adresowi.

Po migracji trzeba więc zachować ostrożność przy porównywaniu wyników według URL.

W szczególności warto sprawdzić:

• właściwości starej i nowej domeny,

• porównywane okresy,

• filtry adresów,

• kraj,

• urządzenie,

• typ wyszukiwania,

• sposób przypisywania danych do adresów kanonicznych.

Nie wolno utożsamiać braku wyświetleń danego URL w określonym filtrze z brakiem indeksacji.

Definicje metryk opisuje What are impressions, position, and clicks?.

GA4: sesje organiczne nie są tym samym co kliknięcia GSC

Sesja w Google Analytics 4 i kliknięcie w Search Console to różne zdarzenia, mierzone odmiennymi metodami.

Dodatkowo domyślny kanał Organic Search w GA4 może obejmować ruch z różnych wyszukiwarek, natomiast Search Console raportuje dane dotyczące wyszukiwarki Google.

Porównanie wszystkich sesji organicznych GA4 z kliknięciami GSC nie jest więc odpowiednio zawężone.

Aby uzyskać bardziej porównywalne dane, należy w GA4 ograniczyć analizę do sesji ze źródłem google i medium organic, korzystając z wymiarów na poziomie sesji, takich jak Session source i Session medium.

Następnie trzeba uzgodnić okresy, zakres analizowanej witryny i inne istotne filtry.

Nawet wtedy wartości nie muszą być identyczne. Na różnice mogą wpływać między innymi:

• odmienne definicje kliknięcia i sesji,

• konfiguracja analityki,

• ustawienia zgód,

• blokowanie lub brak uruchomienia pomiaru,

• przypisywanie źródeł ruchu,

• różnice w raportowaniu i przetwarzaniu danych.

Jeżeli po migracji sesje google / organic spadły, ale odpowiadający im trend kliknięć GSC nie wykazuje podobnej zmiany, warto w pierwszej kolejności skontrolować pomiar, zanim uzna się to za utratę indeksacji.

Google opisuje takie analizy w Using Search Console and Google Analytics Data for SEO.

Strona jest zaindeksowana, ale nie ma wyświetleń. Co sprawdzić?

Brak wyświetleń w raporcie Performance nie oznacza automatycznie braku indeksacji.

Jeśli URL Inspection potwierdza indeksację, należy najpierw przeanalizować dane skuteczności.

Pierwszym krokiem jest sprawdzenie zakresu dat, filtrów, typu wyszukiwania i adresu kanonicznego, do którego przypisywane są dane.

Następnie warto porównać zapytania oraz adresy odpowiadające wcześniejszej widoczności.

Należy ustalić, czy zmiana dotyczy:

• jednej podstrony,

• określonej kategorii lub szablonu,

• większej grupy URL,

• całej witryny.

Spadek wyświetleń może wynikać ze zmiany pozycji, popytu na określone zapytania, sezonowości, zmian w wynikach wyszukiwania lub innych czynników.

Sam związek czasowy z migracją nie dowodzi, że była ona bezpośrednią przyczyną spadku.

Metody analizy przedstawia Debug Google Search Traffic Drops.

Dlaczego warto analizować indeksację na poziomie grup stron?

Łączna liczba niezindeksowanych URL może być myląca.

W raportach mogą znajdować się ważne strony usługowe, produkty, warianty parametrów, adresy alternatywne i duplikaty. Nie wszystkie powinny być odrębnie indeksowane.

Punktem wyjścia jest podział witryny na klasy adresów, na przykład:

• kategorie,

• produkty,

• podstrony usługowe,

• publikacje,

• strony generowane przez określone szablony,

• adresy z parametrami.

Dla każdej klasy warto przygotować celową próbkę obejmującą różne stany indeksowania.

Powinny znaleźć się w niej ważne biznesowo strony, adresy zindeksowane i niezindeksowane oraz przykłady odmiennego wyboru canonical, jeśli takie dane są dostępne.

Taka próbka nie musi być statystycznie reprezentatywna dla całego serwisu. Jej zadaniem jest wykrywanie powtarzalnych mechanizmów i różnic między porównywalnymi stronami.

Przykład hipotetyczny: produkty niezindeksowane po migracji

Załóżmy, że po migracji strony usługowe są indeksowane, natomiast część produktów pozostaje w stanie „Strona zeskanowana, ale jeszcze niezindeksowana”.

Nie ma podstaw, aby od razu przebudowywać konfigurację całej domeny.

Najpierw należy zestawić produkty zindeksowane i niezindeksowane, najlepiej korzystające z tego samego szablonu.

Analiza powinna objąć generowane dyrektywy indeksowania, canonical, zawartość strony, renderowanie oraz linkowanie wewnętrzne.

Jeżeli szablon systematycznie wskazuje niewłaściwy adres kanoniczny, powstaje konkretna hipoteza błędu technicznego, którą trzeba potwierdzić w odpowiedziach stron i dostępnych danych Google.

Jeżeli konfiguracja jest spójna, a produkty mają bardzo podobną zawartość, należy rozważyć, czy ich odrębna indeksacja jest uzasadniona.

Przykład służy wyłącznie przedstawieniu procedury diagnostycznej. Nie opisuje rzeczywistej migracji ani wyniku wdrożenia.

Jak przygotować dane do audytu indeksacji po migracji?

Diagnostyka staje się bardziej przejrzysta, gdy informacje o starych i nowych adresach są gromadzone w jednym zestawieniu.

Przykładowy arkusz może zawierać:

Warto osobno oznaczać obserwacje potwierdzone pomiarem, hipotezy oraz informacje, których nie udało się uzyskać.

Pozwala to uniknąć przypisywania statusowi GSC znaczenia, którego ten status faktycznie nie ma.

Jak crawler SEO pomaga wykrywać błędy po migracji?

Załóżmy, że po migracji serwisu część podstron usługowych nie pojawia się w indeksie Google. Przekierowania ze starych adresów działają, a nowe strony zwracają kod HTTP 200. Na pierwszy rzut oka konfiguracja wygląda poprawnie.

Problem może jednak znajdować się głębiej. Niektóre strony mogą nadal wskazywać stare adresy w rel="canonical", zawierać nieaktualne linki wewnętrzne albo korzystać z szablonu generującego błędne dyrektywy indeksowania.

Ręczne sprawdzanie każdego adresu byłoby czasochłonne. Crawler SEO pozwala zebrać te informacje dla większej grupy stron i porównać wyniki. Dzięki temu można wyodrębnić adresy z niespójną konfiguracją i skierować je do dalszej analizy w Google Search Console.

Przykładem narzędzia przeznaczonego do takiej pracy jest Koqivo, desktopowy crawler SEO rozwijany przez CAJVO. Aplikacja łączy analizę techniczną witryny z integracjami Google Search Console i GA4, umożliwiając zestawianie informacji o strukturze strony z danymi Google.

Crawler nie zastępuje Search Console ani nie rozstrzyga samodzielnie, dlaczego Google nie indeksuje konkretnego adresu. Pomaga natomiast wykryć niespójności techniczne i wskazać strony, które wymagają dokładniejszego sprawdzenia.

Kiedy naprawiać, kiedy monitorować, a kiedy eskalować problem?

Po migracji sam upływ czasu nie rozstrzyga, czy potrzebna jest interwencja.

Decyzja powinna wynikać z potwierdzonych obserwacji i wpływu problemu na istotne adresy.

Naprawa: kiedy istnieje potwierdzony błąd

Jeżeli strona docelowa zwraca niewłaściwy status HTTP, zawiera przypadkowy noindex, jest blokowana dla Googlebota lub przekierowanie prowadzi do nieodpowiedniego zasobu, istnieje konkretna podstawa do działania.

Takiej sytuacji nie należy traktować jako zwykłego opóźnienia indeksacji.

Naprawa powinna dotyczyć wykazanego mechanizmu, a nie przypadkowego zestawu ustawień.

Po wdrożeniu zmian należy ponownie sprawdzić odpowiedzi HTTP, dyrektywy indeksowania, sygnały canonical i dostępność właściwej zawartości.

W przypadku witryn opartych na JavaScript potrzebna może być również kontrola wyrenderowanej wersji strony.

Monitorowanie: kiedy nie potwierdzono przeszkody

Jeżeli migracja jest świeża, strony docelowe są dostępne, mapowanie i istotne sygnały pozostają spójne, a raporty nie wskazują potwierdzonej przeszkody, monitorowanie może być uzasadnioną decyzją.

Nie oznacza to biernego oczekiwania przez określoną liczbę dni.

Należy zachować daty kontroli, wyniki testów i stan wyjściowy dla poszczególnych klas stron. Pozwoli to obserwować zmiany w skanowaniu, indeksowaniu i widoczności.

Po istotnej naprawie pojedynczego adresu można rozważyć zgłoszenie go przez URL Inspection.

Dla dużej liczby nowych lub zmienionych stron odpowiednim mechanizmem wspierającym odkrywanie URL jest poprawna mapa witryny.

Zgłoszenie adresu nie gwarantuje jednak indeksacji, a wielokrotne ponawianie żądań nie zastępuje usunięcia rzeczywistej przyczyny problemu.

Eskalacja: kiedy potrzebne są dane infrastrukturalne

Jeżeli Crawl Stats wskazuje problemy z dostępnością hosta, a logi lub inne pomiary potwierdzają błędy odpowiedzi, należy przeanalizować infrastrukturę.

Może to wymagać udziału zespołów odpowiedzialnych za:

• serwer i hosting,

• CDN,

• WAF,

• DNS,

• konfigurację aplikacji,

• wydajność i obsługę zwiększonego ruchu robotów.

Jeżeli nieprawidłowość dotyczy jednego szablonu, właściwym kierunkiem może być analiza CMS albo komponentu odpowiedzialnego za generowanie stron.

Nie należy zmieniać konfiguracji całego serwisu na podstawie mechanizmu wykazanego wyłącznie dla jednej grupy URL.

Brak indeksacji po migracji. Od czego zacząć?

Poprawne przekierowania 301 i 308 wspierają przeniesienie adresów, ale nie przesądzają o indeksowaniu ani widoczności stron docelowych.

Pierwszym zadaniem jest potwierdzenie, że stare URL prowadzą do właściwych nowych zasobów, a te są technicznie dostępne i zawierają oczekiwaną treść.

Następnie należy ustalić, czy Google zna nowe adresy, czy je pobrał, jakie dane o kanonikalizacji są dostępne i czy obserwowany problem rzeczywiście dotyczy indeksowania.

Dopiero na tej podstawie można zdecydować o właściwym działaniu.

Naprawiać należy potwierdzony błąd. Monitorować można stan, w którym nie wykazano przeszkody wymagającej interwencji. Eskalować trzeba problem, którego nie można rozstrzygnąć bez dodatkowych danych technicznych.

Takie podejście ogranicza ryzyko niepotrzebnych zmian oraz pozwala skoncentrować pracę na mechanizmach rzeczywiście wpływających na migrację.