Canonical nie zmienił się po naprawie? Google wyjaśnia, ile może potrwać ponowna ocena

Google 10 lipca 2026 roku zaktualizowało poradnik dotyczący problemów z kanonizacją, doprecyzowując czas potrzebny na ponowną ocenę stron. Najważniejsza informacja brzmi: nawet po naprawieniu problemów Google może pozostawić strony w tym samym klastrze duplikatów do dwóch tygodni. Wyraźna i znacząca różnica między stronami może przyspieszyć ich rozdzielenie.

Nie jest to jednak czternastodniowe SLA. Google nie gwarantuje, że po dwóch tygodniach wybierze wskazany przez właściciela canonical, zakończy migrację albo zindeksuje osobno wszystkie poprawione URL-e.

W praktyce trzeba rozdzielić cztery etapy:

1. ponowne pobranie URL-a przez Googlebota;
2. przetworzenie pobranej wersji;
3. ponowną ocenę klastra podobnych lub zduplikowanych stron;
4. aktualizację danych widocznych w Search Console i wynikach wyszukiwania.

Dopiero rozdzielenie tych etapów pozwala odpowiedzieć, czy trzeba jeszcze czekać, czy wrócić do diagnostyki technicznej.

TL;DR

• Google 10 lipca 2026 roku doprecyzowało dokumentację dotyczącą czasu ponownej oceny kanonizacji.
• Po poprawieniu problemów strony mogą pozostawać w klastrze duplikatów do dwóch tygodni.
• Dwa tygodnie nie są gwarancją ani uniwersalnym czasem indeksowania.
• Google nie określiło oficjalnego początku tego okresu jako daty ponownego crawlu.
• Samo ponowne pobranie strony nie oznacza, że Google zakończyło ponowną ocenę canonicalu.
• rel="canonical" jest sygnałem, a nie dyrektywą.
• Przekierowania 301 i 308 oraz rel="canonical" są mocnymi sygnałami; obecność w sitemapie jest sygnałem słabszym.
• URL Inspection pokazuje canonical wybrany przez Google w danych indeksu, ale test live nie potrafi przewidzieć przyszłego wyboru.
• Request Indexing warto rezerwować dla najważniejszych URL-i. Wielokrotne zgłaszanie tej samej strony nie przyspiesza crawlu.
• W protokole Samurai SEO przyjmujemy konserwatywny punkt kontrolny liczony od potwierdzonego ponownego pobrania poprawionych wersji. Jest to metoda pomiarowa, a nie zegar zdefiniowany przez Google.

Co dokładnie zmieniło Google 10 lipca?

W oficjalnym changelogu Google Search Central pojawiła się informacja o aktualizacji poradnika „Fix canonicalization issues”. Google wyjaśniło, że zmiana dokumentacji ma pomóc właścicielom stron lepiej ocenić, ile czasu może zająć zastosowanie poprawek kanonizacji.

Aktualny poradnik zawiera dwa ważne doprecyzowania:

• nawet po poprawieniu problemów strony mogą pozostawać w klastrze duplikatów do dwóch tygodni;
• strony są zwykle rozdzielane szybciej, gdy różnica między nową treścią a pozostałymi stronami w klastrze jest jasna i znacząca.

To doprecyzowanie dotyczy ponownej oceny podobieństwa i przynależności stron do klastra. Nie można go automatycznie przenosić na każdą operację indeksowania, migrację domeny czy zmianę pojedynczego tagu.

Google nie wskazuje również, że oficjalny „zegar dwóch tygodni” zaczyna biec dokładnie od ponownego pobrania strony. Data recrawlu może być użytecznym punktem pomiarowym, ponieważ potwierdza, że Google miało możliwość zobaczenia poprawionej wersji, ale pozostaje to metodą diagnostyczną, a nie regułą opisaną przez Google.

Jeżeli problem polega na tym, że dwie strony mają niemal identyczną treść, samo dodanie self-canonicalu może nie wystarczyć do ich rozdzielenia. Google nadal może uznać je za warianty tego samego materiału.

Z drugiej strony upływ dwóch tygodni nie oznacza, że Google musi zaakceptować canonical preferowany przez właściciela. System może wybrać inny URL, jeżeli uzna go za lepszą reprezentację treści dla użytkowników.

Crawl to nie to samo co ponowna ocena canonicalu

Najczęstszy błąd diagnostyczny wygląda tak:

„Google pobrało stronę po zmianie, ale canonical się nie zmienił, więc poprawka nie działa”.

Takiego wniosku nie da się wyciągnąć wyłącznie z daty ostatniego crawlu.

Zegar 1: ponowne pobranie strony

Najpierw Googlebot musi ponownie odwiedzić zmieniony URL.

Google informuje, że crawl może zająć od kilku dni do kilku tygodni. Zgłoszenie strony do ponownego pobrania nie gwarantuje natychmiastowej wizyty ani późniejszej indeksacji.

Jeżeli po wdrożeniu Google nie pobrało jeszcze strony, nie miało możliwości zobaczenia:

• nowego canonicalu;
• zmienionej treści;
• nowego statusu HTTP;
• poprawionego hreflangu;
• zmienionego linkowania;
• poprawki w renderowaniu JavaScript.

Zegar 2: przetworzenie pobranej wersji

Pobranie odpowiedzi HTTP jest dopiero wejściem do dalszego przetwarzania.

Google musi przeanalizować kod, treść, sygnały techniczne i — gdy jest to potrzebne — wersję po renderowaniu. Data crawlu nie potwierdza, że wszystkie dane indeksu zostały już zaktualizowane.

Zegar 3: ponowna ocena klastra duplikatów

Google grupuje identyczne lub bardzo podobne strony i wybiera reprezentatywny URL.

Jeżeli po poprawce strony nadal są prawie takie same, mogą pozostać w jednym klastrze. Właśnie tego etapu dotyczy doprecyzowana granica „do dwóch tygodni” opisana w poradniku Google.

Zegar 4: aktualizacja Search Console i wyników

Nawet gdy dane indeksu zostały już przeliczone, informacja w Search Console może nie pojawić się natychmiast.

Google zaznacza, że pole Google-selected canonical może być opóźnione o kilka godzin względem aktualnej wartości w indeksie.

Również wygląd wyników wyszukiwania nie jest wiarygodnym zegarem technicznym. Google może w określonych sytuacjach wyświetlić użytkownikowi inny wariant adresu niż canonical zapisany w indeksie, na przykład wersję odpowiednią dla urządzenia.

User-declared canonical a Google-selected canonical

W URL Inspection występują dwa różne pojęcia.

User-declared canonical

To URL wskazany przez stronę lub właściciela witryny jako preferowany.

Może wynikać między innymi z:

• elementu rel="canonical" w HTML;
• nagłówka HTTP;
• sitemap;
• innych obsługiwanych metod.

Google bierze tę preferencję pod uwagę, ale nie gwarantuje jej wyboru.

Google-selected canonical

To URL wybrany przez system Google jako reprezentatywna wersja grupy podobnych stron.

Google może wybrać URL zadeklarowany przez właściciela, ale może również wskazać inną stronę. Informację tę można sprawdzić w indeksowej części URL Inspection w polu Google-selected canonical.

Dlaczego test live nie wystarczy?

Test live sprawdza bieżącą dostępność i aktualnie zwracaną wersję strony. Może pomóc potwierdzić:

• kod odpowiedzi;
• możliwość crawlowania;
• aktualny HTML;
• renderowanie;
• obecność poprawionego canonicalu.

Nie przewiduje jednak, jaki canonical Google ostatecznie wybierze. Taka informacja jest dostępna tylko w danych indeksu.

Pozytywny wynik testu live oznacza więc:

Google-InspectionTool może pobrać i przetworzyć stronę w aktualnym stanie.

Nie oznacza:

Google zaakceptuje wskazany canonical i zindeksuje tę wersję osobno.

Karta obserwacji canonicalu

Poniższa karta jest rekomendacją operacyjną Samurai SEO. Nie jest formularzem Google ani gwarancją wyboru URL-a.

Hipotetyczny zapis

• URL testowany: /buty?kolor=czarny;
• oczekiwany canonical: /buty;
• status obu URL-i: 200;
• canonical w HTML: /buty;
• sitemap: zawiera tylko /buty;
• linkowanie filtrów: nadal prowadzi w wielu miejscach do URL-a parametrycznego;
• ostatni crawl wariantu: przed wdrożeniem;
• decyzja: najpierw poczekać na nowy crawl, nie zmieniać ponownie canonicalu.

W takim przypadku brak nowego wyboru Google nie dowodzi jeszcze nieskuteczności wdrożenia. Google nie pobrało poprawionej wersji wariantu.

Czternastodniowy protokół pomiaru

Poniższy protokół jest autorską ramą Samurai SEO. Nie jest zaleceniem Google, aby zawsze czekać dokładnie 14 dni, ani deklaracją, że Google zakończy proces w tym czasie.

Google podaje, że po naprawieniu problemów strony mogą pozostawać w klastrze duplikatów do dwóch tygodni, ale nie definiuje oficjalnego początku tego okresu jako daty recrawlu.

Na potrzeby tej procedury przyjmujemy konserwatywny punkt kontrolny liczony od dnia, w którym potwierdzono ponowne pobranie poprawionych wersji testowanego URL-a i oczekiwanego canonicalu. Pozwala to uniknąć liczenia okresu obserwacji od chwili, w której Google mogło jeszcze nie znać wdrożonych zmian. Jest to metoda pomiarowa Samurai SEO, nie oficjalny zegar Google.

Dzień 0: zapisz stan przed zmianą

Przed wdrożeniem zapisz:

• oba URL-e;
• statusy HTTP;
• przekierowania;
• canonical w surowym HTML;
• canonical po renderowaniu;
• obecność w sitemapie;
• linki wewnętrzne;
• hreflang;
• daty ostatniego crawlu;
• wartości user-declared i Google-selected canonical;
• próbkę widoczności w Search Console;
• dokładny zakres planowanej zmiany.

Następnie wykonaj poprawkę i zapisz jej godzinę.

Nie zmieniaj jednocześnie wielu niezależnych elementów, jeżeli nie jest to konieczne. Jeżeli w tym samym dniu zmienisz treść, strukturę URL-i, canonicale, przekierowania i hreflang, późniejsza diagnoza będzie trudniejsza.

Dni 1–3: potwierdź działanie techniczne

Sprawdź:

• czy serwer zwraca oczekiwany status;
• czy nie powstał łańcuch przekierowań;
• czy canonical jest w <head>;
• czy kod źródłowy i renderowany DOM nie wskazują różnych adresów;
• czy CMS nie cofa zmiany;
• czy canonical jest bezwzględnym, prawidłowym URL-em;
• czy oczekiwany canonical jest dostępny i indeksowalny.

Na tym etapie można wykonać live test dla ważnych URL-i. Nie należy jednak oczekiwać, że test live pokaże przyszły Google-selected canonical.

Czego nie robić: nie przełączać canonicalu codziennie między różnymi adresami i nie zgłaszać tego samego URL-a wielokrotnie.

Dni 4–7: sprawdź nowe crawle

Porównaj daty ostatniego crawlu obu stron.

Jeżeli Google pobrało tylko canonical, ale nie pobrało duplikatu, ponowna ocena może nadal opierać się na starej wersji strony alternatywnej.

Sprawdź także:

• logi serwera, jeśli są dostępne;
• zmiany w URL Inspection;
• raport indeksowania;
• czy sitemap zawiera wyłącznie preferowane URL-e;
• czy linkowanie wewnętrzne nadal wzmacnia duplikat.

Dozwolone działanie: Request Indexing dla kilku najważniejszych URL-i po potwierdzeniu, że poprawka działa.

Czego nie robić: nie zmieniać sztucznie lastmod bez rzeczywistej aktualizacji i nie zgłaszać masowo URL-i pojedynczo.

Po potwierdzonym ponownym pobraniu obu poprawionych wersji można rozpocząć konserwatywny, czternastodniowy punkt kontrolny stosowany w tym protokole.

Dni 8–14: obserwuj klaster, nie tylko tag

Jeżeli obie strony zostały ponownie pobrane, a sygnały są spójne, przejdź w tryb obserwacji.

Sprawdzaj:

• Google-selected canonical;
• stan indeksowania obu URL-i;
• daty crawlu;
• różnice treści;
• linkowanie;
• statusy HTTP;
• ewentualne zmiany w widoczności.

Nie oceniaj wyniku wyłącznie po tym, czy jeden URL pojawia się w ręcznym zapytaniu Google.

Jeżeli celem było rozdzielenie stron, a ich treść nadal różni się tylko pojedynczym nagłówkiem albo nazwą koloru, problem może nie polegać na czasie. Różnica może być zbyt mała, by Google uznało strony za niezależne.

Po punkcie kontrolnym: 14 dni w tym protokole

Jeżeli w ramach tego protokołu upłynęło 14 dni od potwierdzonego ponownego pobrania poprawionych wersji, a Google nadal wybiera nieoczekiwany canonical, wróć do karty obserwacji.

Nie oznacza to, że Google przekroczyło oficjalny termin. Google nie zdefiniowało takiego zegara od recrawlu. Czternasty dzień jest tu konserwatywnym momentem ponownej diagnostyki przyjętym przez Samurai SEO.

Sprawdź:

1. czy obie strony rzeczywiście zostały pobrane po wdrożeniu;
2. czy źródłowy HTML i DOM są zgodne;
3. czy przekierowania, canonicale, sitemap i linki wskazują ten sam URL;
4. czy strony są wystarczająco różne;
5. czy oczekiwany canonical nie zwraca błędów;
6. czy decyzja biznesowa ma sens.

Możliwy wniosek może brzmieć nie „Google się pomyliło”, lecz:

• strony nie powinny istnieć osobno;
• preferowany URL jest słabszą reprezentacją;
• CMS generuje sprzeczne sygnały;
• migracja wymaga przekierowania, a nie samego canonicalu.

Macierz diagnostyczna

Google wskazuje, że każda wersja językowa lub regionalna powinna zawierać wskazanie na siebie oraz pozostałe wersje. Jeżeli dwie strony nie wskazują się wzajemnie, Google może zignorować takie adnotacje.

Google wymienia również błędne canonicale generowane przez CMS, brak właściwych oznaczeń językowych oraz konfiguracje serwerowe prowadzące do nieoczekiwanego wyboru między domenami jako częste źródła problemów.

Sygnały zgodne i sprzeczne

Google pozwala wskazywać preferowany URL na kilka sposobów. Sygnały mogą się kumulować.

Według dokumentacji:

• przekierowania są mocnym sygnałem;
• rel="canonical" jest mocnym sygnałem;
• obecność w sitemapie jest sygnałem słabym;
• połączenie zgodnych metod zwiększa szansę wyboru preferowanego URL-a.

Google zaleca linkowanie wewnętrzne do URL-a uznawanego za canonical oraz self-canonical na stronie preferowanej. Przy JavaScript najlepszym rozwiązaniem jest jasny canonical w źródłowym HTML i brak późniejszej zmiany przez skrypt.

W migracjach stałe przekierowania serwerowe 301 lub 308 są właściwym sygnałem przeniesienia. Google rekomenduje kierowanie bezpośrednio do finalnego URL-a i ograniczanie łańcuchów.

Kiedy Request Indexing ma sens?

Request Indexing ma sens po spełnieniu trzech warunków:

1. poprawka została wdrożona i przetestowana;
2. URL jest ważny biznesowo;
3. potrzebujesz zwrócić uwagę Google na kilka stron, a nie tysiące adresów.

Google wskazuje, że funkcja podlega limitom i powinna być rezerwowana dla najważniejszych URL-i w diagnozie kanonizacji.

Wielokrotne zgłoszenie tej samej strony nie przyspieszy jej pobrania. Google może potrzebować od kilku dni do kilku tygodni, a request nie gwarantuje indeksacji.

Dla większej liczby zmian należy wykorzystać prawidłową sitemapę. Nie należy jednak traktować sitemap jako mocniejszego sygnału od przekierowania albo rel="canonical".

Kiedy przestać czekać i wrócić do diagnostyki?

Czekanie ma sens, gdy:

• Google pobrało poprawione wersje;
• statusy HTTP są prawidłowe;
• sygnały są zgodne;
• nie ma błędów renderowania;
• treści zostały rzeczywiście rozdzielone;
• od ostatniego crawlu nie minął przyjęty okres obserwacji.

Wróć do diagnostyki, gdy:

• po wdrożeniu nie ma nowych crawlów;
• CMS zmienia canonical;
• HTML i DOM są sprzeczne;
• sitemap, linki i canonicale wskazują różne strony;
• oczekiwany URL zwraca błąd;
• występują soft 404;
• wersje językowe nie mają pełnych i wzajemnych adnotacji hreflang;
• strony są praktycznie identyczne;
• migracja opiera się wyłącznie na canonicalu zamiast na 301/308;
• preferowany URL nie jest najlepszą stroną dla użytkownika.

Google zaleca przed rozpoczęciem naprawy rozważyć także, czy canonical wybrany przez system nie ma większego sensu niż URL preferowany przez właściciela.

Checklista wdrożeniowa

Przed zmianą

• [ ] Zapisz testowany URL i oczekiwany canonical.
• [ ] Sprawdź statusy HTTP.
• [ ] Zapisz łańcuch przekierowań.
• [ ] Sprawdź canonical w HTML i DOM.
• [ ] Zapisz user-declared i Google-selected canonical.
• [ ] Sprawdź daty crawlu obu stron.
• [ ] Skontroluj sitemapę, linkowanie i hreflang.
• [ ] Określ, czy strony mają być połączone, czy rozdzielone.

Po wdrożeniu

• [ ] Potwierdź poprawkę testem live.
• [ ] Sprawdź, czy CMS jej nie cofnął.
• [ ] Dla ważnych URL-i rozważ Request Indexing.
• [ ] Nie zgłaszaj wielokrotnie tego samego URL-a.
• [ ] Czekaj na ponowny crawl obu stron.
• [ ] Nie zmieniaj nerwowo sygnałów w trakcie obserwacji.
• [ ] Jeżeli korzystasz z protokołu Samurai SEO, zapisz datę potwierdzonego ponownego pobrania poprawionych wersji.

Po okresie obserwacji

• [ ] Sprawdź Google-selected canonical w danych indeksu.
• [ ] Potwierdź zgodność wszystkich sygnałów.
• [ ] Oceń rzeczywistą różnicę treści.
• [ ] Sprawdź błędy serwera i renderowania.
• [ ] Pamiętaj, że 14-dniowy punkt kontrolny protokołu nie jest oficjalnym terminem Google.
• [ ] Podejmij decyzję: czekać, naprawić, rozdzielić, przekierować albo zrezygnować z URL-a.

FAQ

Czy Google musi zmienić canonical w ciągu 14 dni?

Nie. Google informuje, że strony mogą pozostawać w klastrze duplikatów do dwóch tygodni po poprawieniu problemów. Nie jest to gwarancja wyboru wskazanego canonicalu.

Od kiedy Google liczy okres dwóch tygodni?

Dokumentacja nie definiuje oficjalnego początku tego okresu jako daty wdrożenia ani recrawlu. W protokole Samurai SEO używamy potwierdzonego ponownego pobrania poprawionych wersji jako konserwatywnego punktu pomiarowego, ale nie jest to zegar ustanowiony przez Google.

Czy rel="canonical" jest dyrektywą?

Nie. Jest mocnym sygnałem, który Google bierze pod uwagę. System może wybrać inny URL.

Czy nowy crawl oznacza, że canonical został już przeliczony?

Nie. Crawl jest pierwszym etapem. Później następuje przetwarzanie i ponowna ocena klastra.

Dlaczego test live nie pokazuje Google-selected canonical?

Test live bada aktualną wersję strony, ale nie przewiduje wyboru canonicalu. Google-selected canonical jest dostępny w danych indeksu.

Czy warto codziennie używać Request Indexing?

Nie. Funkcja ma limity, a wielokrotne zgłoszenia nie przyspieszają crawlu. Należy ją rezerwować dla ważnych URL-i.

Czy sitemap może wymusić canonical?

Nie. Obecność w sitemapie jest słabszym sygnałem niż przekierowanie lub rel="canonical".

Czy w migracji wystarczy canonical ze starego URL-a na nowy?

Jeżeli stary URL został trwale zastąpiony, Google rekomenduje stałe przekierowanie serwerowe, takie jak 301 lub 308. Canonical nie zastępuje pełnego mapowania migracyjnego.

Czy adnotacje hreflang muszą być wzajemne?

Każda wersja powinna wskazywać siebie i pozostałe wersje językowe lub regionalne. Jeżeli dwie strony nie wskazują się wzajemnie, Google może zignorować ich adnotacje hreflang.

Podsumowanie

Aktualizacja dokumentacji z 10 lipca 2026 roku daje użyteczny punkt odniesienia: po poprawieniu problemów strony mogą pozostawać w klastrze duplikatów do dwóch tygodni.

Nie oznacza to jednak, że należy przez 14 dni biernie obserwować błędną konfigurację ani że Google uruchamia oficjalny zegar od daty recrawlu.

Najpierw trzeba potwierdzić:

1. czy Google pobrało poprawione strony;
2. czy przetwarzana wersja zawiera właściwy canonical;
3. czy HTML i JavaScript są zgodne;
4. czy redirecty, sitemap, linki i hreflang wskazują ten sam URL;
5. czy strony są naprawdę różne;
6. czy wybrana forma konsolidacji odpowiada celowi biznesowemu.

Dopiero potem czas staje się właściwym elementem diagnozy.

W protokole Samurai SEO stosujemy konserwatywny punkt kontrolny: obserwację 14 dni od potwierdzonego ponownego pobrania poprawionych wersji. Nie jest to termin, SLA ani metoda liczenia opisana przez Google. Jest to sposób uporządkowania pomiaru, aby nie oceniać ponownej kanonizacji przed potwierdzeniem, że Google zobaczyło zmiany.

Najbezpieczniejszy model pracy to karta obserwacji, jednoznaczna data wdrożenia, ograniczona liczba zmian i kontrola po przyjętym okresie. Jeżeli po potwierdzonym recrawlu, spójnych sygnałach i czternastodniowym punkcie kontrolnym stosowanym w tej procedurze Google nadal wybiera inny URL, należy wrócić do przyczyny — nie dokładać kolejnego przypadkowego tagu.

Powiązane materiały

• Search Console mierzy Instagram, TikTok, X i YouTube
• Core Web Vitals w Shopify: diagnostyka LCP, INP i CLS
• Kiedy widać efekty SEO: etapy i wskaźniki
• Optymalizacja pod funkcje AI w Google
• Polityka źródeł Samurai SEO