Tag kanoniczny wskazuje błędny adres. Jak wykryć tę pomyłkę w całym serwisie?

Tag kanoniczny to jedna linijka kodu, która mówi wyszukiwarce: „właściwa wersja tej podstrony znajduje się pod tym adresem”. Dopóki adres jest poprawny, nikt o niej nie myśli. Kłopot zaczyna się wtedy, gdy w tej linijce znajdzie się adres strony testowej, strony głównej, wersji bez szyfrowania albo podstrony, której już nie ma. Google dostaje wtedy prośbę, żeby pominąć ważną podstronę i pokazać w wynikach coś innego.

Taka pomyłka rzadko dotyczy jednego adresu. Tag kanoniczny wstawia zwykle szablon albo wtyczka, więc błąd powiela się na dziesiątkach lub setkach podstron jednocześnie, a właściciel firmy widzi tylko skutek: oferta, kategorie sklepu albo wpisy na blogu przestają pojawiać się w Google, chociaż nikt ich nie usuwał.

Ta instrukcja pokazuje, jak rozpoznać problem, jak przejrzeć pod tym kątem cały serwis, a nie tylko jedną podstronę, jak ustalić, skąd wziął się błędny adres, jak go poprawić i po czym poznać, że Google przyjął poprawkę. Wszystkie nazwy raportów i pól podaję w brzmieniu z polskiej wersji Google Search Console.

Po czym poznać, że tag kanoniczny wskazuje zły adres?

Tag kanoniczny to element <link rel="canonical" href="..."> umieszczony w sekcji <head> podstrony. Dla Google jest to wyraźna wskazówka, który adres z grupy podobnych stron ma trafić do wyników. Nie jest to polecenie: wyszukiwarka bierze pod uwagę także przekierowania, mapę witryny i linki wewnętrzne, a potem sama podejmuje decyzję. Podstawy tego mechanizmu opisałem osobno w tekście o tym, jak wskazać Google właściwą wersję podstrony.

Błędny adres w tagu daje jeden z dwóch skutków. Jeżeli wskazana strona jest podobna do tej, na której stoi tag, Google często posłucha i przestanie pokazywać właściwą podstronę. Jeżeli wskazana strona jest zupełnie inna, Google zwykle zignoruje tag i sam wybierze wersję kanoniczną, co wprowadza chaos w raportach i odbiera właścicielowi kontrolę nad tym, co widać w wynikach.

Objawy, które powinny zwrócić uwagę

• Ważna podstrona zniknęła z wyników, a po jej sprawdzeniu w Search Console widać stan „Alternatywna strona zawierająca prawidłowy tag strony kanonicznej”.
• W raporcie „Indeksowanie stron” rośnie liczba adresów w wierszu „Duplikat, wyszukiwarka Google wybrała inną stronę kanoniczną niż użytkownik”.
• Na zapytania, na które wcześniej wyświetlała się podstrona usługi lub produktu, Google pokazuje stronę główną albo zupełnie inną podstronę.
• W wynikach pojawiają się adresy ze starej domeny, z wersji testowej albo zaczynające się od „http://” zamiast „https://”.
• Kolejne strony listy wpisów lub produktów (druga, trzecia i dalsze) nie są indeksowane, a produkty z dalszych stron trudno znaleźć w Google.

Najczęstsze postacie tej pomyłki

W praktyce powtarza się kilka wzorów. Wszystkie podstrony wskazują stronę główną. Tag zawiera adres domeny testowej, która została po budowie serwisu. Adres ma inny protokół, inną wersję z „www” albo inny ukośnik na końcu niż adres faktycznie używany w serwisie. Tag prowadzi do podstrony, która przekierowuje dalej, zwraca błąd 404 albo jest wyłączona z indeksowania znacznikiem noindex.

Osobną grupą są błędy budowy samego tagu: dwa tagi kanoniczne z różnymi adresami na jednej podstronie, adres względny zamiast pełnego albo tag umieszczony poza sekcją <head>. Dokumentacja Google mówi wprost, że element jest brany pod uwagę tylko wtedy, gdy znajduje się w sekcji <head>, i zaleca adresy bezwzględne, czyli pełne, razem z protokołem i domeną.

Jak sprawdzić tag kanoniczny na pojedynczej podstronie?

Przegląd całego serwisu dobrze jest zacząć od ręcznego sprawdzenia trzech lub czterech podstron różnego typu: strony głównej, podstrony usługi lub produktu, kategorii i wpisu. Zajmuje to kilka minut i od razu pokazuje, czy błąd w ogóle występuje i jak wygląda.

1. Otwarcie podstrony w przeglądarce na komputerze i wyświetlenie jej kodu źródłowego. W większości przeglądarek służy do tego skrót klawiszowy Ctrl+U w systemie Windows.
2. Uruchomienie wyszukiwania w kodzie skrótem Ctrl+F i wpisanie słowa canonical.
3. Odczytanie adresu z atrybutu href i porównanie go znak po znaku z adresem widocznym w pasku przeglądarki. Zgadzać się powinny: protokół, obecność lub brak „www”, wielkość liter, ukośnik na końcu oraz brak zbędnych parametrów po znaku zapytania.
4. Policzenie wyników wyszukiwania. Słowo powinno wystąpić w jednym elemencie <link>. Dwa takie elementy z różnymi adresami oznaczają, że szablon i wtyczka wstawiają tag niezależnie od siebie.
5. Sprawdzenie, czy element leży przed znacznikiem zamykającym </head>, a nie w dalszej części kodu.

Prawidłowy tag na podstronie, która sama ma być widoczna w Google, wskazuje jej własny adres. Dla przykładowej podstrony oferty wygląda to tak:

<link rel="canonical" href="https://www.przyklad.pl/oferta/naprawa-dachow/" />

Kod źródłowy nie pokazuje wszystkiego. Tag może zostać zmieniony przez skrypt już po wczytaniu strony albo przesłany w nagłówku HTTP odpowiedzi serwera, co jest częste przy plikach PDF. Dlatego drugim krokiem jest spojrzenie na podstronę oczami Google.

Co widzi Google: narzędzie do sprawdzania adresów URL

W Google Search Console należy wkleić pełny adres podstrony w pole wyszukiwania u góry ekranu i zatwierdzić klawiszem Enter. Po chwili pojawi się wynik z sekcją „Indeksowanie stron”. Po jej rozwinięciu widać dwa pola: „Adres kanoniczny określony przez użytkownika” oraz „Adres kanoniczny wybrany przez Google”.

Pierwsze pole pokazuje to, co Google odczytał z tagu podczas ostatniej wizyty. Drugie pokazuje decyzję wyszukiwarki. Jeżeli w pierwszym polu widnieje adres, którego nikt świadomie nie ustawiał, błąd leży po stronie serwisu. Jeżeli pierwsze pole jest poprawne, a drugie pokazuje inny adres, Google uznał dwie podstrony za duplikaty i postawił na inną z nich.

Te dane pochodzą z ostatnio zindeksowanej wersji podstrony, a nie z tego, co jest w sieci w tej chwili. Aktualny kod pokazuje przycisk „Sprawdź URL wersji opublikowanej”, a po zakończeniu testu „Wyświetl przetestowaną stronę”, gdzie można odszukać tag w pobranym kodzie HTML. Trzeba przy tym wiedzieć, że według pomocy Google wersję kanoniczną da się ustalić tylko na podstawie danych z indeksu. Test wersji opublikowanej nie przewidzi, który adres Google ostatecznie wybierze.

Jak znaleźć błędne tagi w całym serwisie w Google Search Console?

Ręczne sprawdzanie podstrona po podstronie nie ma sensu już przy kilkudziesięciu adresach. Search Console pozwala zobaczyć problem zbiorczo, bez instalowania czegokolwiek, pod warunkiem że serwis jest w niej dodany i zweryfikowany.

1. W menu po lewej stronie należy otworzyć raport „Indeksowanie stron”.
2. Pod wykresem znajduje się tabela „Dlaczego strony nie są indeksowane”. Trzeba odszukać w niej trzy wiersze: „Alternatywna strona zawierająca prawidłowy tag strony kanonicznej”, „Duplikat, wyszukiwarka Google wybrała inną stronę kanoniczną niż użytkownik” oraz „Duplikat, użytkownik nie oznaczył strony kanonicznej”.
3. Kliknięcie wiersza otwiera stronę ze szczegółami i tabelą przykładowych adresów. Tabela jest ograniczona do 1000 wierszy i nie musi zawierać wszystkich adresów z danym stanem.
4. Listę należy pobrać przyciskiem eksportu widocznym w górnej części raportu i otworzyć w arkuszu kalkulacyjnym.
5. W arkuszu trzeba zaznaczyć adresy, które powinny być widoczne w Google: podstrony usług, produktów, kategorii, wpisy. To one wymagają dalszego sprawdzenia.
6. Każdy typ zaznaczonych adresów sprawdza się na dwóch lub trzech przykładach w narzędziu do sprawdzania adresów URL. Do jego otwarcia służy ikona lupy widoczna po najechaniu kursorem na wiersz tabeli.

Jak czytać trzy wiersze raportu?

Najbardziej mylący jest pierwszy. Stan „Alternatywna strona zawierająca prawidłowy tag strony kanonicznej” oznacza, że podstrona wskazuje inny adres jako kanoniczny, a Google się do tego zastosował. Pomoc Google opisuje ten stan jako niewymagający działania i tak jest, o ile na liście są wersje z parametrami, wydruki czy warianty sortowania. Jeżeli jednak znajdują się tam podstrony oferty, oznacza to, że serwis sam poprosił Google o ich pominięcie. Raport nazywa tag „prawidłowym”, bo działa technicznie, a nie dlatego, że wskazuje słuszny adres.

Wiersz „Duplikat, wyszukiwarka Google wybrała inną stronę kanoniczną niż użytkownik” pokazuje adresy, przy których Google nie zgodził się z tagiem. Według dokumentacji oznacza to, że Google nie uważa sprawdzanej podstrony za duplikat adresu z tagu, tylko za duplikat innej strony. Zdarza się to, gdy tag wskazuje stronę o innej treści, na przykład stronę główną.

Wiersz „Duplikat, użytkownik nie oznaczył strony kanonicznej” zawiera podstrony bez tagu, które Google uznał za kopie innych. Sam w sobie nie jest błędem, ale jeżeli trafiają tam ważne adresy, znaczy to, że tag w ogóle się na nich nie wyświetla.

Jak zawęzić raport do ważnych podstron?

Nad wykresem działa filtr mapy witryny. Domyślna opcja to „Wszystkie znane strony”. Po przełączeniu na „Wszystkie przesłane strony” raport pokazuje wyłącznie adresy z przesłanej mapy witryny, czyli te, które właściciel sam zgłosił jako ważne. Każdy adres z mapy, który ma jeden z trzech opisanych stanów, jest sygnałem sprzeczności: mapa mówi „ten adres jest właściwy”, a tag albo Google mówi co innego.

Ta metoda działa tylko wtedy, gdy mapa witryny jest przesłana i aktualna. Jeżeli jej brakuje, najpierw należy ją dodać. Opisałem to krok po kroku w tekście o zgłoszeniu mapy witryny w Google Search Console.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl. Przeskanuję wtedy cały serwis, wskażę wszystkie podstrony z błędnym tagiem kanonicznym, ustalę przyczynę i dopilnuję poprawki aż do chwili, gdy Google ponownie zindeksuje właściwe adresy.

Jak przeskanować cały serwis, gdy Search Console nie wystarcza?

Search Console ma dwa ograniczenia. Pokazuje stan z ostatniej wizyty Google, więc świeży błąd może być jeszcze niewidoczny, a lista przykładów jest ograniczona. Pełny i aktualny obraz daje program, który odwiedza po kolei wszystkie podstrony serwisu i zapisuje, co znajduje w ich kodzie. Najczęściej używanym narzędziem tego typu jest Screaming Frog SEO Spider, instalowany na komputerze. Wersja niewymagająca opłaty pozwala przeskanować do 500 adresów, co dla wielu stron firmowych jest wystarczające.

1. Po uruchomieniu programu w pole adresu u góry okna wpisuje się adres strony głównej razem z „https://” i uruchamia skanowanie przyciskiem „Start”.
2. Należy poczekać, aż pasek postępu dojdzie do końca. Przy małym serwisie trwa to kilka minut.
3. Następnie trzeba przejść do zakładki „Canonicals”. Program pokazuje w niej wszystkie podstrony razem z adresem odczytanym z tagu kanonicznego.
4. Lista rozwijana z filtrami w tej zakładce dzieli podstrony na grupy. Najważniejsze to: „Canonicalised” (tag wskazuje inny adres niż własny), „Missing” (brak tagu), „Multiple Conflicting” (kilka tagów z różnymi adresami), „Non-Indexable Canonical” (tag wskazuje adres, którego nie da się zindeksować), „Canonical Is Relative” (adres względny) i „Outside <head>” (tag poza sekcją head).
5. Każdą grupę zapisuje się do pliku przyciskiem „Export” i otwiera w arkuszu kalkulacyjnym.

Program ma interfejs w języku angielskim, dlatego nazwy zakładek i filtrów podaję w oryginale. Inne programy do skanowania serwisów dają podobne zestawienie: tabelę z adresem podstrony i adresem z jej tagu kanonicznego.

Skanowanie obciąża serwer podobnie jak wizyta wielu użytkowników naraz. Przy słabszym hostingu lub dużym sklepie bezpieczniej jest zmniejszyć szybkość skanowania w ustawieniach programu i uruchomić je poza godzinami największego ruchu.

Jak sprawdzić adresy, do których nie prowadzą linki?

Program skanujący chodzi po linkach, więc nie zobaczy podstron, do których nic nie prowadzi. Żeby objąć także je, można przełączyć program w tryb listy (w menu „Mode” opcja „List”) i wgrać adresy z mapy witryny albo z pliku wyeksportowanego z Search Console. Wtedy sprawdzone zostaną dokładnie te adresy, które Google już zna.

Które adresy kanoniczne w tabeli są naprawdę błędne?

Nie każda podstrona, której tag wskazuje inny adres, jest pomyłką. Wersja produktu z parametrem koloru wskazująca produkt podstawowy to poprawne użycie tagu. Dlatego wynik skanowania trzeba przejrzeć według prostego zestawu pytań.

• Czy podstrona, która ma być widoczna w Google, wskazuje samą siebie? Jeżeli nie, jest to błąd, o ile nie istnieje świadomy powód.
• Czy wiele różnych podstron wskazuje jeden i ten sam adres, najczęściej stronę główną? To niemal zawsze błąd szablonu lub wtyczki.
• Czy adres w tagu ma tę samą domenę, protokół i postać z „www” lub bez niej co cały serwis? Inna domena wymaga natychmiastowego wyjaśnienia.
• Czy adres z tagu otwiera się bez przekierowania i bez błędu? Tag powinien prowadzić do działającej podstrony, która odpowiada kodem 200.
• Czy adres z tagu nie jest zablokowany przed indeksowaniem znacznikiem noindex albo w pliku robots.txt?
• Czy adres z tagu zgadza się z adresem w mapie witryny i z tym, do którego prowadzą linki w menu? Dokumentacja Google wprost odradza wskazywanie jednego adresu w mapie, a innego w tagu.

W arkuszu najwygodniej dodać kolumnę z formułą porównującą adres podstrony z adresem z tagu. Wiersze, w których oba adresy są identyczne, można odfiltrować. Pozostałe trzeba posortować według adresu z tagu: grupy z tym samym adresem docelowym zwykle mają wspólną przyczynę i jedną wspólną poprawkę.

Szczególną uwagę warto poświęcić kolejnym stronom list, czyli paginacji. Tag na drugiej i dalszych stronach kategorii wskazujący stronę pierwszą to częsta pomyłka. Te strony nie są duplikatami pierwszej, bo zawierają inne produkty lub wpisy, a taki tag utrudnia Google dotarcie do pozycji z dalszych stron. Każda strona listy powinna wskazywać samą siebie.

Skąd bierze się błędny adres i jak ustalić przyczynę?

Poprawianie tagów bez znalezienia źródła kończy się powrotem błędu po najbliższej aktualizacji. Przyczyn jest kilka i każdą da się rozpoznać po charakterystycznym wzorze w tabeli.

Ustawienia adresu w systemie strony

Jeżeli wszystkie tagi mają zły protokół, złą postać z „www” albo starą domenę, przyczyna leży zwykle w głównym ustawieniu adresu serwisu. W WordPressie są to pola „Adres WordPressa (URL)” i „Adres witryny (URL)” w menu „Ustawienia”, w części „Ogólne”. Wtyczki i szablon budują tag kanoniczny właśnie na podstawie tego adresu.

Zmiana tych pól jest ryzykowna. Literówka potrafi odciąć dostęp do panelu i wyłączyć całą stronę. Przed jakąkolwiek zmianą należy wykonać kopię zapasową plików i bazy danych, a adres przepisać bardzo uważnie, bez ukośnika na końcu.

Wtyczka SEO albo ręcznie wpisany adres

Wtyczki do optymalizacji mają przy każdym wpisie i każdej podstronie pole na własny adres kanoniczny, zwykle w ustawieniach zaawansowanych pod edytorem treści. Jeżeli błąd dotyczy pojedynczych, niepowiązanych podstron, najpewniej ktoś wpisał tam adres ręcznie albo podstrona powstała przez skopiowanie innej razem z jej ustawieniami. Rozpoznać to łatwo: pole, które powinno być puste, zawiera adres.

Drugim typowym kłopotem są dwie wtyczki o tym samym przeznaczeniu działające jednocześnie albo wtyczka i szablon, które niezależnie dodają tag. W kodzie widać wtedy dwa elementy z atrybutem canonical.

Pozostałość po budowie lub przenosinach serwisu

Adres domeny testowej w tagach oznacza, że po uruchomieniu serwisu nie podmieniono adresów w bazie danych albo że szablon ma adres wpisany na stałe w pliku. Podobnie bywa po zmianie domeny i po przejściu na szyfrowane połączenie. Jeżeli serwis był niedawno przenoszony, ten trop należy sprawdzić jako pierwszy, razem z resztą czynności, które opisałem w tekście o migracji strony bez utraty pozycji w Google.

Błąd w szablonie

Gdy wszystkie podstrony jednego typu, na przykład wszystkie produkty albo wszystkie strony kategorii, wskazują ten sam adres, winny jest plik szablonu odpowiedzialny za ten typ. Programista wstawił w nim tag ze stałym adresem albo z błędną zmienną. Tu potrzebna jest poprawka w kodzie, nie w treści.

Skrypty, nagłówki serwera i pamięć podręczna

Jeżeli kod źródłowy pokazuje poprawny tag, a Search Console odczytuje inny, tag jest zmieniany po drodze: przez skrypt działający w przeglądarce, przez nagłówek HTTP „Link” dodawany przez serwer albo przez przestarzałą kopię podstrony w pamięci podręcznej lub sieci CDN. Google zaleca, aby tag był ustawiony w kodzie HTML i nie był potem zmieniany skryptem.

Włamanie na stronę

Tag wskazujący obcą domenę, której właściciel serwisu nie zna, to poważny sygnał ostrzegawczy. Dokumentacja Google wymienia wśród typowych przyczyn ataki, w których do kodu trafia tag kanoniczny albo przekierowanie prowadzące do strony ze spamem lub złośliwym oprogramowaniem. W takiej sytuacji poprawienie samego tagu nie wystarczy. Trzeba oczyścić całą stronę, zgodnie z planem opisanym w tekście o zainfekowanej stronie na WordPressie.

Jak naprawić błędne tagi kanoniczne w całym serwisie?

Kolejność ma znaczenie. Najpierw usuwa się źródło, potem poprawia wyjątki, a na końcu porządkuje pozostałe sygnały, żeby wszystkie wskazywały ten sam adres.

1. Wykonanie pełnej kopii zapasowej serwisu i zapisanie wyniku skanowania sprzed zmian. Ten plik posłuży później do porównania.
2. Ustalenie jednej obowiązującej postaci adresów: protokół „https://”, wersja z „www” albo bez niej, ukośnik na końcu albo jego brak. Wszystkie tagi mają być z nią zgodne.
3. Poprawienie przyczyny ogólnej: adresu serwisu w ustawieniach, ustawień wtyczki albo pliku szablonu. Przy szablonie pracę należy zlecić programiście i przekazać mu listę typów podstron z błędem.
4. Poprawienie wyjątków. W ustawieniach każdej podstrony z ręcznie wpisanym błędnym adresem pole adresu kanonicznego należy wyczyścić, tak aby wtyczka sama wstawiła adres własny podstrony.
5. Usunięcie podwójnych tagów przez wyłączenie jednego ze źródeł. Na podstronie ma zostać dokładnie jeden element z atrybutem canonical.
6. Wyczyszczenie pamięci podręcznej wtyczki, serwera i sieci CDN, aby odwiedzający i Google otrzymali nową wersję kodu.
7. Sprawdzenie mapy witryny. Powinna zawierać wyłącznie adresy kanoniczne, w tej samej postaci co w tagach.
8. Poprawienie linków wewnętrznych w menu, stopce i treści, tak aby prowadziły do adresów kanonicznych, a nie do ich wariantów.

Jeżeli pod starymi lub błędnymi adresami nadal otwierają się kopie podstron, na przykład wersja bez szyfrowania, sam tag to za mało. Dokumentacja Google opisuje przekierowanie jako wyraźny sygnał tego, który adres ma być kanoniczny. Zbędne wersje należy więc przekierować na stałe pod właściwy adres.

W zleceniu dla programisty wystarczy jedno precyzyjne zdanie: Każda podstrona przeznaczona do indeksowania ma mieć w sekcji head dokładnie jeden tag kanoniczny z pełnym adresem https wskazującym ją samą, zgodnym z adresem w mapie witryny.

Po czym poznać, że naprawa zadziałała?

Sprawdzenie ma dwa etapy. Pierwszy potwierdza, że kod jest poprawny, i można go wykonać od razu. Drugi potwierdza, że Google przyjął zmianę, i wymaga cierpliwości.

1. Ponowne skanowanie serwisu i porównanie z plikiem sprzed zmian. Grupy z błędami powinny być puste albo zawierać wyłącznie świadome wyjątki.
2. Ręczne obejrzenie kodu kilku podstron każdego typu, najlepiej w oknie prywatnym przeglądarki, żeby nie zobaczyć starej kopii.
3. W Search Console wklejenie adresu poprawionej podstrony w pole u góry, kliknięcie „Sprawdź URL wersji opublikowanej”, a potem „Wyświetl przetestowaną stronę” i odszukanie tagu w pobranym kodzie.
4. Dla kilku najważniejszych adresów kliknięcie „Poproś o zindeksowanie”. Obowiązuje dzienny limit takich próśb, dlatego nie należy zgłaszać w ten sposób całego serwisu.
5. W raporcie „Indeksowanie stron” otwarcie wiersza z problemem i kliknięcie „Sprawdź poprawkę”. Pomoc Google prosi, aby nie klikać przycisku ponownie, dopóki weryfikacja się nie zakończy.
6. Po kilku dniach ponowne sprawdzenie ważnych adresów. W obu polach, „Adres kanoniczny określony przez użytkownika” i „Adres kanoniczny wybrany przez Google”, powinien widnieć własny adres podstrony.

Weryfikacja poprawki zajmuje według Google zazwyczaj do 2 tygodni, a czasem znacznie dłużej. Search Console wysyła powiadomienie o jej wyniku. Liczba adresów w raporcie zmienia się także bez weryfikacji, za każdym razem, gdy Google ponownie odwiedzi podstronę ze znanym problemem.

Przy większej liczbie adresów zamiast pojedynczych próśb lepiej przesłać zaktualizowaną mapę witryny. Pomoc Google wskazuje ją jako właściwy sposób zgłaszania wielu zmienionych podstron jednocześnie.

Co zrobić, gdy Google nadal wybiera inny adres?

Poprawny tag nie gwarantuje, że Google się z nim zgodzi. Jeżeli po upływie kilku tygodni pole „Adres kanoniczny wybrany przez Google” nadal pokazuje inną podstronę, trzeba sprawdzić trzy rzeczy.

Po pierwsze, czy obie podstrony nie są zbyt podobne. Google grupuje strony o niemal identycznej treści i wybiera z grupy jedną. Dokumentacja podaje, że nawet po zmianie treści strony mogą pozostawać w takiej grupie do 2 tygodni, a rozdzielenie następuje szybciej, gdy różnica jest wyraźna. Dwie podstrony usług różniące się tylko nazwą miejscowości wymagają więc dopisania własnej, konkretnej treści.

Po drugie, czy pozostałe sygnały nie przeczą tagowi. Linki w menu prowadzące do wariantu adresu, inny adres w mapie witryny albo przekierowanie w przeciwną stronę osłabiają wskazanie z tagu. Wszystkie sygnały mają mówić to samo.

Po trzecie, czy wybór Google nie jest po prostu lepszy. Dokumentacja zachęca, żeby zastanowić się, czy adres wybrany przez wyszukiwarkę nie służy użytkownikom bardziej niż adres wskazany w tagu. Zdarza się, że rozsądniej jest przyjąć ten wybór i dostosować do niego tag, mapę i linki.

Jeżeli wybrany adres należy do obcej domeny, która skopiowała treść bez zgody, pozostaje kontakt z jej właścicielem z żądaniem usunięcia materiału albo zgłoszenie naruszenia praw autorskich do Google. To osobna procedura, przy której nie da się z góry przewidzieć wyniku.

Jakich błędów unikać przy poprawianiu tagów?

• Blokowanie duplikatów w pliku robots.txt. Google odradza używanie tego pliku do wyboru strony kanonicznej, bo robot nie odczyta wtedy tagu z zablokowanej podstrony.
• Łączenie tagu kanonicznego wskazującego inny adres ze znacznikiem noindex na tej samej podstronie. Google nie zaleca noindex jako sposobu na wybór wersji kanonicznej.
• Sięganie po narzędzie do usuwania adresów w Search Console. Ukrywa ono w wynikach wszystkie wersje adresu, także tę właściwą.
• Wskazywanie w tagu adresu z fragmentem po znaku „#”. Google zasadniczo nie obsługuje takich adresów jako kanonicznych.
• Zgłaszanie do ponownego indeksowania setek adresów pojedynczo zamiast przesłania mapy witryny.
• Wielokrotne klikanie „Sprawdź poprawkę” przed zakończeniem trwającej weryfikacji oraz uruchamianie jej, zanim błąd zniknie ze wszystkich podstron. Weryfikacja zatrzymuje się, gdy Google znajdzie choć jedno pozostałe wystąpienie problemu.
• Zmienianie tagów co kilka dni w oczekiwaniu na szybki efekt. Każda zmiana wydłuża czas, w którym Google ustala właściwą wersję.

Uważam, że największym błędem jest jednorazowa naprawa bez późniejszej kontroli. Aktualizacja szablonu albo wtyczki potrafi przywrócić stary stan, dlatego skanowanie pod kątem tagów kanonicznych dobrze jest powtarzać po każdej większej zmianie w serwisie. Wygodnie włączyć je do stałej listy kontrolnej serwisu.

Najczęstsze pytania

Czy każda podstrona musi mieć tag kanoniczny?

Nie jest to obowiązkowe. Według dokumentacji Google brak wskazania nie jest błędem, bo wyszukiwarka sama ustali najlepszą wersję. Zalecane jest jednak, aby każda podstrona przeznaczona do indeksowania wskazywała samą siebie, ponieważ ogranicza to ryzyko, że Google wybierze wariant adresu z parametrem.

Czy Google zawsze stosuje się do tagu kanonicznego?

Nie. Tag jest wyraźną wskazówką, ale decyzję podejmuje wyszukiwarka na podstawie wielu sygnałów. Jeżeli wskazana strona nie jest podobna do tej, na której stoi tag, Google nie wybierze jej jako kanonicznej.

Ile trzeba czekać na efekt po poprawieniu tagów?

Nie ma jednego terminu. Zmiana staje się widoczna dopiero po ponownej wizycie Google na danej podstronie. Weryfikacja poprawki w Search Console trwa zazwyczaj do 2 tygodni, a przy dużych serwisach powrót wszystkich adresów do indeksu może zająć więcej czasu.

Czy tag kanoniczny może wskazywać adres w innej domenie?

Może, i bywa to celowe, na przykład gdy ten sam serwis działa pod dwiema domenami. Jeżeli jednak właściciel nie zna wskazanej domeny albo nie planował takiego ustawienia, należy to potraktować jako możliwy ślad włamania i sprawdzić całą stronę.

Czy stan „Alternatywna strona zawierająca prawidłowy tag strony kanonicznej” wymaga naprawy?

Zależy, jakie adresy się w nim znajdują. Warianty z parametrami, wersje do druku i podobne kopie są tam na swoim miejscu. Podstrony oferty, produktów lub wpisów nie powinny się tam znaleźć, a ich obecność oznacza błędny tag.

Czy błędny tag kanoniczny powoduje karę od Google?

Nie jest to kara. Skutek jest jednak dotkliwy: podstrona, która wskazuje inny adres, może zostać pominięta w wynikach. Po poprawieniu tagu i ponownym zindeksowaniu podstrona ma szansę wrócić, choć nikt nie zagwarantuje, że na te same pozycje.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

Szukanie jednej błędnej linijki kodu na kilkuset podstronach bywa żmudne, zwłaszcza gdy równocześnie trzeba prowadzić firmę. Chętnie przejmę tę pracę w całości: przeskanuję serwis, przygotuję listę podstron z błędnym tagiem kanonicznym, ustalę, czy winna jest wtyczka, szablon czy ustawienia, wprowadzę poprawkę albo przekażę programiście gotowe wytyczne, a potem dopilnuję weryfikacji w Search Console.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony. Odpowiem, co widać w serwisie i od czego należy zacząć.