Canonical wskazuje złą wersję adresu po migracji strony – co sprawdzić i jak to naprawić?

Objaw: Google wybiera inną stronę niż chcesz pozycjonować

Typowy scenariusz wygląda tak: po migracji strony ustawiasz nowe adresy URL, przekierowania 301 i mapę witryny, ale w Google Search Console widzisz, że Google jako kanoniczny wybiera inny adres. Może to być stary URL, kopia z poprzedniego CMS, wersja z domeny technicznej, strona z parametrami filtrowania albo adres o bardzo podobnej treści.

W praktyce oznacza to, że canonical wskazuje złą wersję adresu po migracji strony albo Google nie ufa sygnałom, które mu wysyłasz. Najczęściej problem dotyczy jednej z tych sytuacji:

Dlaczego błędny canonical po migracji jest groźny dla SEO

Migracja strony to moment, w którym Google ponownie interpretuje strukturę serwisu, przekierowania, linkowanie wewnętrzne, mapy XML, treść i sygnały kanoniczne. Jeśli canonical wskazuje złą wersję adresu, wysyłasz sprzeczny komunikat: z jednej strony chcesz, aby Google zaindeksował nowy URL, a z drugiej mówisz mu, że ważniejszy jest inny adres.

Skutki mogą być poważne, szczególnie w serwisach B2B, sklepach internetowych i stronach z rozbudowaną architekturą informacji.

Jeśli problem dotyczy większej części serwisu, warto potraktować go jako krytyczny element SEO technicznego, a nie drobną kosmetykę w kodzie.

Najczęstsze przyczyny błędnego canonical po migracji

Canonical rzadko psuje się przypadkiem. Najczęściej jest efektem niedokończonej migracji, automatycznych ustawień CMS, błędnych szablonów albo niespójności między kilkoma sygnałami SEO.

Diagnostyka krok po kroku

Przy problemie „canonical wskazuje zla wersje adresu po migracji strony” nie wystarczy sprawdzić jednego URL w przeglądarce. Trzeba porównać sygnały z kodu, nagłówków HTTP, mapy XML, linkowania wewnętrznego i danych z Google Search Console.

1. Sprawdź URL w Google Search ConsoleUżyj narzędzia sprawdzania adresu URL. Porównaj pola „Kanoniczny zadeklarowany przez użytkownika” i „Kanoniczny wybrany przez Google”. Jeśli są różne, masz potwierdzenie konfliktu.
2. Zweryfikuj tag canonical w kodzie stronyOtwórz źródło HTML i znajdź rel=”canonical”. Sprawdź, czy adres jest absolutny, aktualny, indeksowalny i zgodny z docelową wersją URL.
3. Przetestuj status HTTP adresu kanonicznegoCanonical powinien wskazywać stronę zwracającą 200 OK. Nie powinien prowadzić do 301, 302, 404, 410, adresu z noindex ani strony zablokowanej w robots.txt.
4. Porównaj canonical z przekierowaniamiSprawdź, czy stary adres przekierowuje bezpośrednio do nowego odpowiednika. Unikaj łańcuchów przekierowań i sytuacji, w której canonical wskazuje adres pośredni.
5. Sprawdź linkowanie wewnętrzneMenu, stopka, breadcrumbs, linki w treści i moduły powiązane powinny prowadzić do wersji, którą chcesz indeksować. Linkowanie jest mocnym sygnałem wyboru kanonicznego URL.
6. Porównaj mapę XML z canonicalMapa witryny powinna zawierać tylko indeksowalne adresy docelowe. Jeśli w sitemapie są stare lub alternatywne URL, Google otrzymuje sprzeczny sygnał.
7. Wykonaj crawl serwisuPrzeskanuj stronę narzędziem crawlerowym i wyeksportuj listę URL z canonical. Szukaj adresów kanonicznych do innej domeny, starych ścieżek, przekierowań i duplikatów.
8. Sprawdź szablony i reguły CMSUstal, czy problem dotyczy pojedynczych podstron, całej grupy typów treści, kategorii, produktów, wpisów blogowych czy wszystkich URL w serwisie.

Tabela diagnostyczna: co sprawdzić i jak interpretować wynik

Jak naprawić canonical wskazujący złą wersję adresu

Naprawa powinna zacząć się od ustalenia docelowego standardu adresów. Musisz wiedzieć, która wersja jest właściwa: https czy http, www czy bez www, z ukośnikiem końcowym czy bez, z jaką strukturą kategorii, języków i parametrów.

1. Ustal jedną wersję kanoniczną dla każdego typu strony

Dla każdej grupy URL określ, który adres ma być indeksowany. Inaczej podejdziesz do stron usługowych, inaczej do kategorii e-commerce, produktów, artykułów blogowych, paginacji i filtrów. W serwisach po migracji przydaje się mapa starych i nowych adresów, która pokazuje relację 1:1.

2. Popraw generowanie canonical w źródle strony

Canonical powinien być generowany dynamicznie dla właściwego adresu, a nie wpisany na sztywno w szablonie. W praktyce trzeba sprawdzić ustawienia CMS, wtyczki SEO, szablonów, pól niestandardowych oraz ewentualnych reguł po stronie aplikacji.

• używaj pełnych adresów absolutnych, na przykład https://domena.pl/adres/;
• unikaj canonical prowadzących do adresów przekierowanych;
• nie wskazuj jako canonical stron z noindex;
• nie ustawiaj jednej strony jako canonical dla wielu różnych intencji wyszukiwania;
• nie zostawiaj canonical do domeny testowej po wdrożeniu produkcyjnym.

3. Uporządkuj przekierowania po migracji

Przekierowania 301 powinny prowadzić ze starych URL bezpośrednio do nowych odpowiedników. Jeśli stary adres A przekierowuje do B, B przekierowuje do C, a canonical na C wskazuje jeszcze D, Google dostaje serię niespójnych sygnałów. To zwiększa ryzyko, że wybierze inną wersję niż planowana.

4. Zaktualizuj linkowanie wewnętrzne

Jeśli menu, linki w treści, stopka i breadcrumbs nadal prowadzą do starych adresów, Google może uznać, że to one są ważniejsze. Po migracji warto wykonać crawl i znaleźć wszystkie linki wewnętrzne do URL, które przekierowują, są nieindeksowalne lub mają inny canonical.

To szczególnie istotne, jeśli równolegle prowadzisz pozycjonowanie i chcesz utrzymać autorytet najważniejszych podstron sprzedażowych. Linkowanie wewnętrzne powinno wzmacniać te adresy, które faktycznie mają rankować.

5. Wyczyść mapę XML i zgłoś ją ponownie

Mapa XML nie powinna zawierać starych, przekierowanych, zablokowanych ani alternatywnych wersji adresów. Po poprawkach wygeneruj aktualną sitemapę i zgłoś ją w Google Search Console. Nie wymusi to natychmiastowej zmiany, ale ułatwi Google ponowne przetworzenie struktury serwisu.

6. Rozwiąż problem duplikacji treści

Jeśli Google wybiera inną stronę niż ta, którą chcesz pozycjonować, przyczyną może być nie tylko tag canonical, ale też zbyt podobna treść. Dotyczy to często stron ofertowych dla podobnych usług, kategorii e-commerce, wariantów produktów, parametrów filtrowania oraz artykułów przeniesionych z poprzedniego CMS.

• scal strony, jeśli obsługują tę samą intencję wyszukiwania;
• rozbuduj treść, jeśli różnice między URL są zbyt małe;
• ustaw noindex dla podstron, które nie powinny trafiać do wyników;
• zablokuj indeksację technicznych parametrów tylko wtedy, gdy rozumiesz wpływ na crawl;
• użyj canonical jako elementu strategii, a nie jako obejścia bałaganu w architekturze.

7. Poczekaj na ponowne przetworzenie i monitoruj efekty

Po wdrożeniu zmian Google musi ponownie odwiedzić adresy, przetworzyć przekierowania, zaktualizować sygnały i wybrać wersję kanoniczną. W zależności od wielkości serwisu oraz częstotliwości crawlowania może to potrwać od kilku dni do kilku tygodni.

Jeśli chcesz sprawdzić, czy problem jest częścią szerszych błędów migracyjnych, dobrym krokiem jest techniczny audyt SEO, obejmujący indeksację, crawl budget, przekierowania, canonical, mapy XML, robots.txt i linkowanie wewnętrzne.

Lista kontrolna po wdrożeniu poprawek

Po naprawie nie kończ pracy na zmianie jednego tagu. Sprawdź, czy cały ekosystem sygnałów SEO jest spójny.

• Canonical na każdej ważnej podstronie wskazuje finalny adres 200 OK.
• Adres kanoniczny nie jest zablokowany przez robots.txt.
• Adres kanoniczny nie ma meta robots noindex.
• Stare URL mają bezpośrednie przekierowania 301 do nowych odpowiedników.
• Nie ma łańcuchów i pętli przekierowań.
• Mapa XML zawiera wyłącznie aktualne, indeksowalne adresy.
• Linkowanie wewnętrzne prowadzi do docelowych wersji URL.
• Menu, breadcrumbs, stopka i moduły automatyczne nie używają starych adresów.
• Google Search Console pokazuje zgodność między canonical zadeklarowanym a wybranym przez Google.
• Duplikaty treści zostały scalone, zróżnicowane lub objęte właściwą strategią indeksacji.
• Wersje językowe mają poprawne relacje canonical i hreflang.
• Warianty http, https, www i bez www są konsekwentnie obsłużone.

Kiedy warto skonsultować problem z ekspertem?

Nie każdy błąd canonical wymaga dużego projektu SEO. Jeśli problem dotyczy pojedynczej podstrony i wiesz, skąd wynika, często wystarczy korekta ustawień w CMS. Inaczej wygląda sytuacja po migracji domeny, zmianie struktury adresów, wdrożeniu nowego sklepu lub przeniesieniu serwisu na inny system.

Warto skonsultować problem z ekspertem, gdy:

W RankHero analizujemy canonical w kontekście całej migracji, a nie jako oderwany fragment kodu. Sprawdzamy, dlaczego Google wybiera inną stronę niż ta, którą chcesz pozycjonować, i wskazujemy konkretne poprawki do wdrożenia przez zespół techniczny.

Warto wiedzieć przed kolejną migracją

Najlepszym sposobem na uniknięcie problemów z canonical jest przygotowanie migracji przed wdrożeniem, a nie gaszenie pożaru po spadkach widoczności. Plan powinien obejmować mapowanie adresów, reguły przekierowań, test canonical na środowisku przedprodukcyjnym, kontrolę robots.txt, aktualizację sitemap i crawl porównawczy starej oraz nowej wersji serwisu.

Jeśli chcesz uporządkować pojęcia związane z indeksacją, kanonicznością, przekierowaniami i architekturą SEO, zajrzyj do naszego słownika pojęć. Przy migracjach technicznych precyzyjne rozumienie tych elementów ułatwia rozmowę między marketingiem, SEO i zespołem developerskim.