Błędy kanoniczne w wielojęzycznym sklepie: jak je wykryć

Canonical sklep wielojęzyczny: od czego zacząć sprawdzanie

Jeśli prowadzisz canonical sklep wielojęzyczny, nie sprawdzaj pojedynczego znacznika w oderwaniu od reszty konfiguracji. Dla każdej wersji produktu, kategorii czy strony informacyjnej trzeba porównać adres URL, canonical oraz zestaw wskazań hreflang. Dopiero wtedy widać, czy polska wersja rzeczywiście wskazuje polską wersję jako preferowany adres, a niemiecka lub angielska zachowuje własną relację.

Najczęstszy problem wygląda prosto. Sklep ma adres /pl/produkt, jego niemiecki odpowiednik znajduje się pod /de/produkt, ale w kodzie niemieckiej strony canonical prowadzi przez pomyłkę do /pl/produkt. Hreflang może jednocześnie wskazywać oba adresy jako alternatywne wersje językowe. Taka konfiguracja wymaga sprawdzenia, ponieważ canonical i hreflang pełnią różne funkcje.

Canonical służy przede wszystkim do wskazania preferowanego adresu dla stron będących duplikatami lub bardzo podobnymi wariantami. Hreflang opisuje natomiast relacje między wersjami przeznaczonymi dla różnych języków lub regionów. Google traktuje wskazanie canonical jako sygnał, a nie bezwzględną instrukcję. Dlatego trzeba sprawdzić zarówno to, co znajduje się w kodzie strony, jak i to, jaki canonical ostatecznie wybiera Google.

Jeżeli przy okazji sprawdzania canonicali wychodzą inne problemy techniczne, przydatny będzie także audyt techniczny elementów sklepu, ponieważ błędne wskazania mogą wynikać z konfiguracji CMS, modułu SEO albo szablonu.

Czy każda wersja językowa powinna mieć własny canonical

W typowym sklepie, w którym każda wersja językowa ma własny, indeksowalny URL i własną treść, trzeba zacząć od sprawdzenia, czy każda strona wskazuje właściwy adres kanoniczny dla swojej wersji.

Przykładowo sklep może działać w strukturze:

• https://example.com/pl/produkt
• https://example.com/en/product
• https://example.com/de/produkt

Jeżeli są to rzeczywiście różne wersje językowe tej samej strony, nie należy automatycznie traktować angielskiego adresu jako canonical dla wszystkich wersji. Google wskazuje, że strony w różnych językach nie są uznawane za duplikaty tylko dlatego, że przedstawiają ten sam produkt. Jeżeli główna treść została faktycznie przetłumaczona, poszczególne wersje mogą funkcjonować jako lokalizowane odpowiedniki.

W praktyce najczęściej chcesz więc uzyskać układ, w którym /pl/produkt ma canonical do /pl/produkt, /en/product ma canonical do /en/product, a /de/produkt ma canonical do /de/produkt. Są to canonicale samoodnoszące. Następnie hreflang łączy te adresy jako odpowiednie warianty językowe.

Nie oznacza to jednak, że każda strona w każdym projekcie musi zawsze mieć identyczną konfigurację. Jeżeli dwie wersje są faktycznie duplikatami w tym samym języku albo sklep ma warianty regionalne z bardzo podobną treścią, sytuacja może wyglądać inaczej. Wtedy trzeba ocenić, która strona jest wersją preferowaną i jaką rolę ma hreflang.

Jak znaleźć błędny canonical między językami

Najprościej zacząć od konkretnego URL-a, najlepiej produktu lub kategorii, która występuje we wszystkich wersjach językowych. Otwórz stronę w przeglądarce, wyświetl kod źródłowy i wyszukaj rel="canonical".

Przykładowy poprawny wpis dla polskiej wersji może wyglądać tak:

<link rel="canonical" href="https://example.com/pl/produkt" />

Jeżeli jesteś na stronie /pl/produkt, ale canonical wskazuje /de/produkt, masz wyraźny sygnał do dalszej kontroli. Nie zakładaj jeszcze, że sam tag jest jedyną przyczyną problemu. Sprawdź, czy niemiecki URL jest faktycznie wersją tego samego produktu, czy może system błędnie przypisał adres językowy.

Następnie wykonaj identyczne sprawdzenie dla /en/product i /de/produkt. Zapisz wynik w prostej tabeli. Dzięki temu szybko zobaczysz, czy błąd występuje tylko na jednej stronie, czy został powielony przez cały moduł wielojęzyczny.

Wersja językowa	canonical i oczekiwany URL
Polski	/pl/produkt → /pl/produkt
Angielski	/en/product → /en/product
Niemiecki	/de/produkt → /de/produkt
Francuski	/fr/produit → /fr/produit

Jeżeli kilkaset produktów ma ten sam schemat błędu, nie poprawiaj ich ręcznie pojedynczo. Sprawdź ustawienia generatora canonicali, mapowanie tłumaczeń oraz sposób, w jaki moduł SEO pobiera adres bazowy produktu.

Przy sklepie na WooCommerce, PrestaShop czy Shoperze problem może pochodzić z różnych warstw. Sam CMS może wygenerować canonical, a dodatkowy moduł SEO może go nadpisać. Do tego dochodzi szablon, cache albo kod JavaScript. Dlatego trzeba ustalić, który element faktycznie wysyła błędny adres.

Canonical hreflang: jak sprawdzić oba elementy razem

Canonical hreflang nie jest jednym znacznikiem. To dwa osobne mechanizmy, które trzeba analizować razem, ale nie wolno ich utożsamiać.

Canonical odpowiada na pytanie: który URL jest preferowaną reprezentacją tej strony lub grupy bardzo podobnych adresów?

Hreflang odpowiada na pytanie: który URL jest odpowiednią wersją dla konkretnego języka lub regionu?

Dla trzech wersji sklepu możesz mieć na przykład taki zestaw:

<link rel="canonical" href="https://example.com/pl/produkt" />
<link rel="alternate" hreflang="pl" href="https://example.com/pl/produkt" />
<link rel="alternate" hreflang="en" href="https://example.com/en/product" />
<link rel="alternate" hreflang="de" href="https://example.com/de/produkt" />

Na stronie angielskiej analogiczny zestaw powinien wskazywać angielski URL jako własną wersję i pozostałe adresy jako alternatywy. Google zaleca, aby każda wersja językowa wskazywała samą siebie oraz wszystkie pozostałe wersje w danym zestawie.

Właśnie tutaj można znaleźć jeden z częstszych błędów. Sklep ma prawidłowy hreflang, ale canonical każdej wersji wskazuje na polską stronę. W kodzie wygląda to pozornie logicznie, bo wszystkie adresy są ze sobą połączone. Problem polega na tym, że canonical mówi coś innego niż właściciel sklepu prawdopodobnie chce osiągnąć.

Jeżeli analizujesz canonical i hreflang razem, sprawdź każdą wersję z obu stron. Polski URL powinien wskazywać angielski jako hreflang="en", a angielski powinien również wskazywać polski jako hreflang="pl". Nie wystarczy sprawdzić tylko jednej strony.

Wielojęzyczne URL i typowe źródła błędów

W praktyce błędne canonicale często powstają podczas wdrażania kolejnego języka. Dodajesz niemiecką wersję sklepu, konfigurujesz tłumaczenia produktów, generujesz nowe adresy, a moduł SEO nadal korzysta z głównego adresu produktu.

Przyczyną może być również niewłaściwe mapowanie tłumaczeń. System rozpoznaje produkt jako jeden rekord, ale nie rozróżnia prawidłowo jego lokalnego URL-a. W efekcie każdy język dostaje canonical wskazujący na adres podstawowy.

Kolejne miejsce do sprawdzenia to przekierowania. Jeśli /de/produkt zwraca przekierowanie do /pl/produkt, sam canonical nie naprawi konfiguracji. Trzeba najpierw ustalić, dlaczego użytkownik i robot nie mogą wejść bezpośrednio na niemiecką wersję.

Sprawdź też protokół i host. http://example.com/pl/produkt, https://example.com/pl/produkt, https://www.example.com/pl/produkt i https://example.com/pl/produkt to różne adresy, które mogą wysyłać sprzeczne sygnały. Google bierze pod uwagę między innymi przekierowania, canonical oraz obecność URL-a w sitemapie przy ustalaniu wersji kanonicznej.

Nie pomijaj również wielkości liter. Jeśli serwer traktuje /PL/produkt i /pl/produkt jako ten sam zasób, a inne elementy witryny korzystają z różnych wariantów, powstaje dodatkowy bałagan w adresach. W dokumentacji Google znajduje się osobna wskazówka dotycząca budowania poprawnej struktury URL, dlatego przy większym sklepie uporządkowanie technicznych problemów przed SEO powinno obejmować także adresy wersji językowych.

Jak zweryfikować canonical w Google Search Console

Kod HTML pokazuje konfigurację, którą wysyła sklep. Nie pokazuje jednak automatycznie tego, jaki adres Google wybrał jako canonical.

Do tego służy kontrola adresu w Google Search Console. Wprowadź konkretny URL, na przykład niemiecką kartę produktu, i sprawdź informacje dotyczące indeksowania oraz canonicala wybranego przez Google.

Porównaj trzy informacje:

1. adres URL, który testujesz,
2. canonical zadeklarowany przez sklep,
3. canonical wybrany przez Google.

Jeśli wszystkie trzy odpowiadają zamierzonej wersji językowej, konfiguracja jest spójna na tym poziomie. Jeśli Google wybrał inny adres, trzeba sprawdzić sygnały wpływające na wybór.

Szczególnie istotne są przekierowania, canonical w kodzie, sitemap oraz sposób linkowania wewnętrznego. Jeśli polska wersja prowadzi linkami wewnętrznymi do polskiego URL-a, sitemap zawiera ten sam adres, a canonical również wskazuje ten adres, sygnały są spójniejsze niż wtedy, gdy każdy element wskazuje inną wersję.

Google podkreśla również, że zadeklarowany canonical jest wskazówką. Nie oznacza to automatycznie, że wyszukiwarka wybierze dokładnie ten adres. Dlatego kontrola w Search Console jest przydatna szczególnie wtedy, gdy sklep zgłasza w indeksowaniu nieoczekiwaną wersję strony.

Błędy canonical w sklepie wielojęzycznym, które trzeba poprawić

Jednym z błędów jest ustawienie jednego canonicala dla wszystkich języków. Jeżeli polski, angielski i niemiecki produkt mają własne wersje treści, nie zakładaj, że polski URL powinien automatycznie być canonicalem dla całego zestawu.

Drugi problem to canonical prowadzący do adresu, który przekierowuje. Jeśli canonical wskazuje URL zwracający przekierowanie, trzeba sprawdzić, czy wskazanie nie powinno zostać zmienione na docelowy adres.

Trzeci błąd pojawia się wtedy, gdy canonical prowadzi do strony z inną treścią niż ta, którą użytkownik właśnie ogląda. Przykładem może być niemiecka karta produktu z canonicalem do polskiej kategorii. Taki wpis może wynikać z błędu w szablonie albo z nieprawidłowego pobierania danych przez moduł SEO.

Czwarty problem to brak zgodności między canonicalem a linkowaniem wewnętrznym. Jeżeli menu językowe, breadcrumbs i linki produktowe prowadzą do jednego URL-a, a canonical wskazuje inny, otrzymujesz sprzeczne sygnały.

Piąty błąd to niepełna sieć hreflang. Jeśli polska wersja wskazuje angielską, ale angielska nie wskazuje polskiej, trzeba sprawdzić generowanie atrybutów na obu stronach. Samo dodanie hreflang do jednej wersji nie zastępuje pełnej konfiguracji.

Jeżeli sklep ma dużo wersji językowych, ręczne szukanie takich przypadków szybko staje się niepraktyczne. Wtedy można wyeksportować URL-e i przeanalizować je grupami, porównując status HTTP, canonical, hreflang oraz adresy alternatywne.

Jak zrobić kontrolę całego sklepu

Zacznij od przygotowania listy reprezentatywnych adresów. Nie ograniczaj się do strony głównej. Uwzględnij produkt, kategorię, stronę producenta, stronę informacyjną i inne typy URL-i, które występują w kilku językach.

Dla każdego adresu sprawdź:

• czy URL jest dostępny bez przekierowania,
• jaki canonical znajduje się w kodzie,
• czy canonical prowadzi do właściwej wersji językowej,
• czy wskazany canonical odpowiada stronie dostępnej dla użytkownika,
• jakie wartości hreflang znajdują się w kodzie,
• czy wersja sama siebie wskazuje w hreflang,
• czy pozostałe wersje wskazują wzajemnie siebie,
• czy sitemap zawiera właściwe adresy,
• czy linki wewnętrzne prowadzą do preferowanych URL-i.

Dobrze jest zapisać wynik w arkuszu. Przy większym sklepie od razu widać wtedy wzorce. Jeśli wszystkie niemieckie produkty mają canonical do polskich produktów, prawdopodobnie problem znajduje się w konfiguracji modułu. Jeśli błąd występuje tylko na kategoriach, trzeba szukać w szablonie kategorii lub mechanizmie generowania adresów.

Przy rozbudowanym sklepie można też połączyć tę kontrolę z analizą szybkości, indeksowania i struktury adresów. Nie ma sensu poprawiać pojedynczego canonicala, jeśli ten sam szablon generuje błędne znaczniki dla całej witryny.

Canonical a sitemap i linkowanie wewnętrzne

Sam canonical nie powinien być analizowany w oderwaniu od pozostałych sygnałów. Jeśli sklep uważa /en/product za właściwą angielską wersję, sprawdź, czy ten sam URL pojawia się w sitemapie oraz czy linki wewnętrzne kierują właśnie do niego.

Nie twórz sytuacji, w której sitemap zawiera /en/product, canonical wskazuje /pl/produkt, a menu językowe prowadzi do trzeciego adresu. Takie rozbieżności utrudniają interpretację struktury sklepu.

Sitemap nie zastępuje canonicala. Jest jednym z sygnałów używanych przez Google przy ustalaniu preferowanej wersji URL. Z kolei linkowanie wewnętrzne pomaga pokazać, które adresy są faktycznie używane w strukturze witryny.

Warto również sprawdzić, czy adresy w sitemapie nie zawierają przypadkowo parametrów, starej wersji domeny, HTTP zamiast HTTPS albo nieaktualnej struktury językowej. Przy migracji językowej takie pozostałości potrafią zostać długo niezauważone.

Co zrobić, gdy canonical wskazuje inny język

Najpierw ustal, czy różne wersje rzeczywiście są odrębnymi wersjami językowymi. Następnie sprawdź źródło HTML, konfigurację CMS, moduł SEO oraz ewentualne nagłówki HTTP.

Jeżeli polska strona wskazuje canonical na niemiecką, odpowiedz sobie na kilka pytań. Czy niemiecka strona jest faktycznie preferowaną wersją? Czy polska treść jest duplikatem niemieckiej? Czy niemiecki URL zwraca kod sukcesu? Czy hreflang poprawnie opisuje obie strony? Czy sitemap i linkowanie wewnętrzne wskazują te same adresy?

Jeżeli odpowiedzi pokazują, że każda wersja powinna być samodzielnym adresem, popraw generator canonicali tak, aby każda wersja wskazywała właściwy URL. Następnie sprawdź hreflang i wykonaj ponowną kontrolę kilku reprezentatywnych stron.

Nie zmieniaj masowo tagów bez ustalenia przyczyny. Jeśli problem generuje moduł, ręczna korekta kodu HTML może zostać nadpisana przy aktualizacji albo przy kolejnym generowaniu strony. Przy większym sklepie lepiej znaleźć miejsce, w którym powstaje błędny adres, i poprawić źródło problemu.

Jeżeli po uporządkowaniu kodu Google nadal wybiera inną wersję canonical, sprawdź przekierowania, sitemapę, linkowanie oraz podobieństwo treści. Google może wybrać własny canonical, gdy dostępne sygnały wskazują inną stronę jako bardziej reprezentatywną.

Canonical w sklepie wielojęzycznym: szybka lista kontroli

Przed zamknięciem audytu przejdź przez konkretną listę. Dla każdej wersji językowej sprawdź, czy:

• adres jest właściwy dla danego języka,
• canonical wskazuje oczekiwany URL,
• canonical nie prowadzi przez przekierowanie,
• canonical nie wskazuje przypadkowo innego języka,
• hreflang zawiera własny adres,
• hreflang wskazuje pozostałe odpowiednie wersje,
• inne wersje wskazują wzajemnie badaną stronę,
• sitemap zawiera właściwy URL,
• linkowanie wewnętrzne korzysta z właściwej wersji,
• Search Console nie pokazuje innego canonicala niż oczekiwany.

Taki przegląd pozwala rozdzielić dwa problemy. Pierwszy dotyczy tego, co sklep deklaruje w kodzie. Drugi dotyczy tego, jak Google interpretuje dostępne sygnały. To rozróżnienie jest szczególnie istotne przy diagnozowaniu błędów canonical w sklepie wielojęzycznym.

Jeśli potrzebujesz sprawdzić całą konfigurację sklepu zamiast pojedynczych adresów, audyt sklepu internetowego pod kątem SEO i techniki obejmuje analizę elementów, które mogą wpływać na indeksowanie i interpretację adresów.

Podsumowanie

Wielojęzyczny sklep wymaga osobnego spojrzenia na URL, canonical i hreflang. Jeżeli każda wersja językowa ma własną treść i własny adres, zacznij od sprawdzenia, czy canonical nie przenosi preferencji na inną wersję językową bez uzasadnienia.

Następnie porównaj canonical z hreflang, sitemapą, linkowaniem wewnętrznym i informacją z Search Console. Gdy te elementy wskazują różne adresy, nie poprawiaj przypadkowo pojedynczego znacznika. Najpierw znajdź mechanizm, który generuje błędną konfigurację.

W praktyce właśnie taka kontrola pozwala odpowiedzieć na pytanie czy każda wersja językowa powinna mieć własny canonical. W typowym układzie odrębnych, przetłumaczonych wersji URL każda strona powinna wskazywać właściwy dla siebie canonical, a hreflang powinien opisywać relacje między wersjami. Wyjątki wynikają z konkretnej struktury witryny, duplikacji i wariantów regionalnych, dlatego konfigurację trzeba oceniać na poziomie rzeczywistych URL-i.