Kanonizacja to prosty mechanizm, który spina wszystkie wersje tej samej treści w jeden, preferowany adres URL. Dzięki rel=”canonical” porządkuję duplikaty, konsoliduję link equity i sprawiam, że Google nie marnuje czasu na warianty z parametrami, sortowaniem czy „drukuj”. To jeden z tych elementów technicznego SEO, który daje szybki, mierzalny efekt, jeśli jest wdrożony poprawnie.
W przewodniku przejdę od definicji i działania linku kanonicznego, przez najlepsze praktyki w HTML i nagłówkach HTTP, aż po scenariusze z życia: e-commerce (filtry, paginacja, UTM), wersje mobilne/AMP i współwydawnictwa. Pokażę też, jak Google interpretuje canonical (to sugestia, nie nakaz) i jak zgrać go z hreflang, sitemapą oraz przekierowaniami 301.
Na końcu dostajesz checklisty QA do szybkiej weryfikacji: gdzie spojrzeć w kodzie, co potwierdzić w Google Search Console, jak wykrywać konflikty (canonical → 3xx/4xx, „noindex” na wersji kanonicznej, wiele tagów na stronie) i jak je naprawić bez ryzyka dla ruchu.
Oto 4 najważniejsze informacje o tagu rel canonical, jeśli nie masz czasu przeczytać całego artykułu:
- Jeden, absolutny canonical (HTTPS) per strona → 200 OK; żadnych blokad w robots.txt ani noindex na URL kanonicznym.
- 301 do unifikacji adresów (HTTP→HTTPS, www↔non-www); canonical uzupełnia, ale nie zastępuje stałych przekierowań.
- E-commerce: parametry filtrów/sortowań i UTM kanonizuj do wersji bazowej; paginacja zwykle ma self-canonical (nie do strony 1).
- Spójność sygnałów = akceptacja przez Google: sitemap tylko kanoniczne URL-e, linkowanie wewnętrzne do tej samej postaci; pamiętaj, że canonical to sugestia, im mniej sprzeczności, tym lepiej działa.
Czym jest link kanoniczny (link rel canonical) i jak działa?
Link kanoniczny (często potocznie nazywany „meta tagiem”) to element w nagłówku HTML, który wskazuje wersję kanoniczną – czyli główną, najbardziej reprezentatywną wersję strony. W praktyce informuje on wyszukiwarki, że ten konkretny adres URL jest preferowanym miejscem konsolidacji treści i sygnałów.
Implementacja jest prosta: w sekcji <head> umieszczam <link rel=”canonical” href=”https://twojadomena.pl/preferowany-url/”>. Atrybut rel=”canonical” mówi, z jakim typem relacji mamy do czynienia, a href wskazuje docelowy URL. Stosuję zawsze pełne (absolutne) adresy i pilnuję, by na stronie był dokładnie jeden link kanoniczny.
Jeżeli masz strony–duplikaty (np. warianty z parametrami, różne kolejności sortowania), każda powinna wskazywać URL kanoniczny, który chcesz indeksować i rankować. Dzięki temu duplikacja treści nie rozprasza widoczności ani „mocy” linków.
Strona oryginalna może (i powinna) mieć samoodwołujący canonical, czyli wskazywać sama na siebie. Taki „self-canonical” stabilizuje sygnały, zwłaszcza gdy istnieją parametry, skróty, wielkie/małe litery czy wersje z/bez ukośnika.
W skrócie: tag kanoniczny to jasna instrukcja dla robotów, którą wersję traktować jako docelową dla indeksowania i rankingu – bez przekierowań i bez utraty użytkowej wersji strony.
Źródło: Canonicalization SEO Mythbusting, Google Search Central. Link: https://www.youtube.com/watch?v=gEWkYTPSEjs.
Dlaczego linki kanoniczne są kluczowe dla SEO
Głównym celem linków kanonicznych jest rozwiązanie problemu duplikacji treści. Kiedy wiele adresów prezentuje ten sam lub bardzo podobny content, rel=”canonical” kieruje roboty do preferowanego URL, co poprawia jakość indeksowania i zapobiega rozproszeniu sygnałów.
Dobrze ustawiona kanonizacja zmniejsza obciążenie crawlowaniem – zamiast indeksować i oceniać dziesiątki wariantów, robot skupia się na jednym, właściwym dokumencie. To realnie oszczędza crawl budget i przyspiesza indeksowanie strony w Google.
Canonical konsoliduje sygnały SEO (linki, sygnały behawioralne, kontekst), dzięki czemu „link juice” nie rozcieńcza się między duplikatami. Efekt dla użytkownika? Spójniejsze wyniki wyszukiwania – jeden mocny wynik zamiast kilku przeciętnych wersji tej samej treści.
W perspektywie widoczności **rel=”canonical” pomaga określić, która wersja ma być indeksowana i rankingowana. W wielu audytach samo uporządkowanie kanonikalizacji dawało wzrost pozycji i stabilniejszy ruch, bo algorytm otrzymywał czytelny sygnał preferencji.
Warto dodać, że duplikacja treści pogarsza ranking i użyteczność: rozprasza zaufanie, utrudnia wybór właściwego wyniku i potrafi kanibalizować frazy. Link kanoniczny jest tu bezpiecznym zaworem, który porządkuje mapę URL-i bez niszczenia istniejącej nawigacji.
W trakcie przeprowadzania audytów SEO online projektuję i wdrażam linki kanoniczne (rel=”canonical”) tak, by konsolidować sygnały SEO, porządkować duplikaty i oszczędzać crawl budget. Pracuję na poziomie szablonów, CMS i CDN, przygotowuję checklisty QA i dbam o to, by kanonizacja, hreflang i paginacja tworzyły spójny system.
| Sytuacja | Co robi rel="canonical" |
Efekt SEO |
|---|---|---|
| Wiele URL-i z tą samą treścią | Wskazuje preferowany, główny adres | Konsoliduje sygnały, zapobiega duplikacji |
| Parametry (sort, filtr, UTM) | Kieruje roboty na czysty URL bez parametrów | Oszczędza crawl budget, porządkuje indeks |
| Wersje mobilne/desktop | Wariant mobilny wskazuje kanoniczny desktop | Brak kanibalizacji, jeden wynik w SERP |
| Strony „drukuj” / lekkie wersje | „Drukuj” kanonizuje do wersji głównej | Unikasz indeksacji słabszych kopii |
| Paginacja listingu | Każda strona paginacji ma self-canonical | Treść z dalszych stron nie znika z indeksu |
Kiedy stosować link rel canonical – typowe scenariusze
W praktyce kanonizację stosuję wszędzie tam, gdzie ten sam content może występować pod różnymi adresami. To szczególnie ważne w e-commerce i rozbudowanych serwisach treściowych.
- Parametry URL (sortowanie, filtrowanie, paginacja wewnętrzna listingu): warianty z parametrami zwykle kanonizują do wersji bazowej listingu.
- Wersje mobilne lub AMP: wersja alternatywna wskazuje canonical do wersji podstawowej, a powiązanie uzupełnia się linkami rel=”amphtml”/alternate.
- Wielojęzyczne wersje strony: każda wersja językowa ma self-canonical i uzupełniające hreflang między sobą (kanonizacja nadal wskazuje wersję samej siebie).
- Wersje do druku i lekkie HTML-e: strony „drukuj” kanonizują do wersji głównej.
- Współdzielenie treści na stronach partnerskich / ponowna publikacja: kopie wskazują canonical do oryginału.
Dalej:
- Strony z sortowaniem powinny mieć canonical do wersji bazowej bez parametru sortowania.
- Strony paginacji najczęściej wskazują canonical na siebie (nie na stronę 1), żeby nie tworzyć powracającej pętli i nie gubić treści z kolejnych stron.
- UTM i inne parametry śledzące generują duplikaty – zawsze kanonizuję do czystego URL-a.
- Testy A/B i aktualizacje treści: warianty testowe oraz kopie robocze kanonizują do wersji docelowej.
- Wiele odmian URL tego samego produktu (np. z/bez końcowego ukośnika, http/https, www/non-www): wszystkie wskazują jeden, konsekwentny canonical.
Na koniec zawsze robię QA kanonizacji: jeden canonical na stronę, absolutny adres, brak konfliktów z przekierowaniami i spójność z sitemapą. Dzięki temu adres kanoniczny faktycznie skupia sygnały SEO i przyspiesza indeksowanie, zamiast tworzyć nowe niejednoznaczności.
rel canonical a wersje mobilne i tag alternate
Jeśli utrzymujesz oddzielne adresy dla desktopu i mobile (np. www. oraz m. lub dynamiczne serwowanie), wersja desktopowa powinna zawierać link rel=”alternate” do odpowiedniej wersji mobilnej. Dzięki temu wyszukiwarka rozumie relację między wariantami i potrafi skierować użytkownika na właściwy URL dla jego urządzenia.
Wersja mobilna powinna wskazywać rel=”canonical” do wersji desktopowej. Ten układ mówi robotom: „to ta sama treść, ale preferowana (kanoniczna) jest wersja desktopowa”. W rezultacie sygnały SEO konsolidują się na jednym adresie, a mobilny wariant nie konkuruje w SERP z podstawową stroną.
Kluczowe jest, aby każda para podstron (mobile ↔ desktop) miała spójne oznaczenia canonical/alternate. Oznacza to relacje jeden-do-jednego dla konkretnych URL-i, a nie do strony głównej lub kategorii. Niespójność (np. alternate do złej podstrony) prowadzi do rozproszenia sygnałów i kanibalizacji.
Jeśli masz w pełni responsywny serwis (jeden URL dla wszystkich urządzeń), nie używasz alternate – wystarczy self-canonical na każdej stronie. Warto to jasno ustalić w wytycznych dla dev i contentu, by nie mieszać modeli wdrożenia (m-dot vs. responsive).
| Typ strony | Przykładowy tag | Uwagi |
|---|---|---|
| Artykuł (self-canonical) | <link rel="canonical" href="https://example.com/artykul/"> |
Adres absolutny, HTTPS, jeden tag na stronę |
| Kategoria (self-canonical) | <link rel="canonical" href="https://example.com/kategoria/buty/"> |
Spójny ukośnik końcowy (z/bez) w całym serwisie |
| Listing z parametrem sortowania | <link rel="canonical" href="https://example.com/kategoria/buty/"> |
Wariant ?sort=price_asc wskazuje bazę |
| Strona mobilna (m-dot) | <link rel="canonical" href="https://example.com/produkt/model-x/"> |
Na desktopie dodaj też rel="alternate" do wersji m. |
| Wersja „drukuj” | <link rel="canonical" href="https://example.com/artykul/"> |
Unikasz indeksacji wersji uproszczonej |
| URL z UTM | <link rel="canonical" href="https://example.com/landing/"> |
Wszystkie warianty UTM kanonizują do czystego URL |
canonical link w HTML – dobre praktyki techniczne
Używaj bezwzględnych (absolutnych) adresów URL w tagu kanonicznym, np.
<link rel=”canonical” href=”https://example.com/kategoria/produkt/”>
To eliminuje dwuznaczności (protokół, domena, ścieżka) i ułatwia konsolidację sygnałów.
Dbaj o spójność zapisu URL: małe litery w ścieżkach, jeden jasny wybór ukośnika końcowego (z lub bez) i konsekwentne stosowanie w całym serwisie. Miksowanie wielkości liter czy losowe końcowe / tworzy quasi-duplikaty, które canonical musi później „sprzątać”.
HTTPS powinien być wersją kanoniczną. Jeśli witryna jest dostępna po HTTP i HTTPS, canonical zawsze wskazuje bezpieczny protokół. Warto to wesprzeć przekierowaniami 301 oraz poprawnym HSTS, by użytkownicy i roboty trafiali tylko na jedną wersję.
Jeden tag kanoniczny na stronę. Wiele tagów canonical (np. dodanych przez motyw i wtyczkę jednocześnie) to sprzeczne sygnały – w audytach od razu je usuwam. Po wdrożeniu robię QA: sprawdzam źródło HTML, nagłówki i kilka reprezentatywnych URL-i.
Dobrą praktyką jest też kanonizacja wewnętrzna linków (np. menu, breadcrumbs) do tej samej, kanonicznej postaci URL, aby nie mnożyć wariantów nawigacyjnych, które crawler musiałby potem normalizować.
Google bierze pod uwagę różne sygnały:
- Link rel=”canonical” – wskazanie w kodzie HTML, który adres URL jest główny.
- Przekierowania (Redirects) – np. 301, które pokazują, gdzie użytkownik i robot wyszukiwarki mają trafić.
- Linkowanie wewnętrzne (Internal linking) – adresy URL, które częściej linkujesz w obrębie własnej strony, są ważniejsze.
- Adresy w pliku sitemap – mapy strony XML wskazują preferowane wersje.
- Adresy HTTPS – Google preferuje bezpieczne strony (https zamiast http).
- Ładniejsze, bardziej czytelne adresy URL – np. bez zbędnych parametrów.
👉 W skrócie: Google porównuje te sygnały i na ich podstawie wybiera jedną, kanoniczną wersję adresu strony, aby uniknąć duplikacji treści i poprawić indeksowanie.
Źródło: Google Search Central, Canonical URLs: How Does Google Pick the One?
Źródło YT grafiki: https://www.youtube.com/watch?v=8j_hxBw5B4E.
link rel canonical w nagłówku HTTP i dla plików
Nie każdy zasób ma <head> – dotyczy to np. PDF-ów, dokumentów, obrazów. W takich przypadkach adres kanoniczny można określić w nagłówku HTTP Link, np.:
Link: <https://example.com/poradnik-online/>; rel=”canonical”
To czytelny sposób, by powiązać plik z jego stroną docelową (HTML), która ma rankować.
Nagłówek HTTP Link z rel=”canonical” może być dodany po stronie serwera, co skaluje wdrożenie na całe katalogi plików. W Apache (przez .htaccess) da się wprowadzić reguły dla rozszerzeń (np. pdf), aby automatycznie doklejać canonical.
Prosty przykład dla .htaccess (koncepcyjnie):
<FilesMatch „\.(pdf)$”>
Header add Link „<https://example.com/poradnik-online/>; rel=\”canonical\””
</FilesMatch>
Pamiętaj, by kierować na właściwą stronę HTML, która reprezentuje plik i zawiera pełny kontekst treści (opis, dane strukturalne, nawigację).
Po wdrożeniu sprawdź nagłówki wybranych plików (curl/DevTools) i zweryfikuj w GSC, czy Google widzi relację kanoniczną. To szczególnie przydatne w serwisach, gdzie PDF-y zdobywają linki zewnętrzne – nie chcesz rozpraszać sygnałów między plik a stronę.
linki kanoniczne a sitemap i indeksacja
Mapa witryny (sitemap) powinna zawierać tylko kanoniczne adresy URL. To jeden z najprostszych sposobów, by nie promować duplikatów – crawler dostaje od razu czysty zestaw docelowych stron do odkrycia i indeksacji.
Pamiętaj jednak, że Google nie gwarantuje uznania adresu z mapy jako kanonicznego. Sitemapa to wskazówka, nie rozkaz. O kanoniczności decyduje zestaw sygnałów: tag canonical, wewnętrzne linkowanie, przekierowania, treść, odnośniki zewnętrzne, sygnały behawioralne.
Dlatego niekanoniczne adresy URL wyklucz z mapy witryny. Nie ma sensu proponować robotowi stron, które i tak wskazują canonical gdzie indziej. Unikasz w ten sposób szumu w crawl i przyspieszasz zrozumienie struktury.
W praktyce po wdrożeniach robię trójtest spójności: (1) czy canonical każdej strony jest poprawny i absolutny; (2) czy sitemap zawiera wyłącznie te same, kanoniczne URL-e; (3) czy linkowanie wewnętrzne prowadzi konsekwentnie do tej samej postaci adresu. Ten zestaw najszybciej stabilizuje indeksację i ranking.
canonical link vs przekierowania 301
rel=”canonical” i przekierowanie 301 to dwa różne narzędzia porządkowania adresów. Canonical konsoliduje sygnały SEO bez zmiany URL-a dla użytkownika (zostaje na miejscu, ale wskazuje wersję preferowaną), a 301 fizycznie przenosi ruch i roboty pod nowy adres – stary z czasem wypada z indeksu. Oba przenoszą wartość SEO, ale 301 jest silniejszym, jednoznacznym sygnałem i rozwiązuje problem u źródła.
W praktyce:
- Przekierowanie 301 przekazuje wartość SEO do wersji kanonicznej i powinno być używane, gdy dany wariant nie ma sensu użytkowego (stare URL-e, zła struktura, zmiany informacji architektonicznej).
- Wersja HTTP → HTTPS: zawsze 301, a canonical wskazuje docelowy HTTPS.
- Wersje z www i bez www: ujednolicamy 301 do jednej, spójnej domeny; canonical wspiera tę decyzję.
Kiedy canonical zamiast 301? Gdy wariant URL jest potrzebny użytkownikom (np. listing z innym sortowaniem) lub nie chcesz zmieniać adresu z powodów technicznych/kampanijnych – wtedy link kanoniczny konsoliduje sygnały bez przekierowania. Reguła kciuka: „stała zmiana adresu = 301, wiele wersji tej samej treści = canonical”.
Jak Google interpretuje rel canonical
Dla Google kanonizacja to proces wyboru „jednego reprezentanta” spośród duplikatów. rel=”canonical” jest silną sugestią, ale nie twardą dyrektywą – Google może ją zignorować, jeśli sygnały z treści, linków czy zachowań wskazują inny adres jako lepszy.
W praktyce drobne różnice listingów (np. inne sortowanie tej samej listy produktów) traktowane są jak duplikaty treści i mogą zostać sklejone do jednego kanonicznego wyniku. Zdarza się też, że strony niekanoniczne pojawią się w SERP w szczególnych przypadkach (np. dopasowanie do bardzo specyficznego zapytania, link bezpośredni, odświeżanie indeksu).
Dlatego poza tagiem dbam o spójny zestaw sygnałów: linkowanie wewnętrzne do wersji preferowanej, sitemap tylko z kanonicznymi URL-ami, brak konfliktów (np. canonical → URL, który przekierowuje). Im mniej sprzeczności, tym większa szansa, że Google zaakceptuje wskazany kanoniczny.
Najczęstsze błędy: link kanoniczny w praktyce
Poniżej lista problemów, które najczęściej naprawiam podczas audytów – każdy z nich rozmywa sygnały SEO albo utrudnia indeksację:
- Brak tagu kanonicznego → rozproszenie sygnałów między wariantami tego samego contentu.
- Uszkodzony tag (zły href, relatywny URL, literówki) → ignorowanie przez wyszukiwarki.
- Wiele rel=”canonical” na jednej stronie → niejednoznaczność indeksowania (Google wybiera po swojemu).
- Blokowanie URL kanonicznego w robots.txt → robot nie może poprawnie zaindeksować wersji docelowej.
- noindex na URL kanonicznym → strona nie zostanie uznana za kanoniczną (sprzeczny sygnał).
- Canonical wskazujący na przekierowanie (3xx) → błąd wdrożeniowy; wskazuj ostateczny, 200 OK.
- URL kanoniczny zwracający 4XX → brak indeksowania i utrata sygnałów.
- Kanonizacja wszystkich stron paginacji do strony 1 lub głównej → zjadanie treści z dalszych stron, problemy z indeksacją.
- Brak połączenia canonical + hreflang w wielojęzycznych serwisach → konkurencja wersji językowych między sobą.
- Canonical w sekcji <body> zamiast w <head> → błąd techniczny, tag może być zignorowany.
- Canonical do treści nieistotnej/słabej → błąd jakościowy; wersją kanoniczną powinna być strona najpełniejsza i najbardziej reprezentatywna.
Dobra praktyka: jeden absolutny canonical per strona, do 200 OK, zgodny z HTTPS/www polityką, spójny z sitemapą i linkowaniem – i bez sprzecznych sygnałów typu noindex czy blokada w robots.txt. Dzięki temu kanonizacja naprawdę konsoliduje sygnały, zamiast tworzyć nowe problemy.
Jak sprawdzać i weryfikować link rel canonical
Najpierw patrzę w kod źródłowy: w sekcji <head> szukam pojedynczego wpisu
<link rel=”canonical” href=”https://twojadomena.pl/preferowany-url/”>. Sprawdzam, czy adres jest absolutny, bez błędów w ścieżce, z właściwą polityką www/HTTPS i zgodny z logiką danej podstrony (np. wariant produktu ≠ kanoniczna kategoria).
Kolejny krok to Google Search Console. W Inspekcji adresu URL widać zarówno „adres kanoniczny zadeklarowany przez użytkownika”, jak i „adres kanoniczny wybrany przez Google”. Jeśli te wartości się różnią, diagnozuję sprzeczne sygnały (linkowanie wewnętrzne, sitemap, przekierowania, noindex). Duplikaty stron wyłapuję też w raporcie „Stan – Wykluczono”, gdzie GSC grupuje przyczyny wyłączenia z indeksu.
Upewniam się, że URL kanoniczny zwraca 200 OK (nie 3xx/4xx) i nie jest blokowany w robots.txt ani oznaczony noindex. To proste, ale często właśnie tu leży błąd wdrożeniowy, przez który wyszukiwarki ignorują canonical.
Do audytu masowego używam narzędzi SEO (np. Screaming Frog, Sitebulb, Ahrefs Site Audit): zrzucam listę URL-i, porównuję deklarowane canonicale z wybranymi przez Google i patrzę na spójność z sitemapą.
Szybka checklista QA (5 minut):
- 1× canonical w <head>, absolutny URL, HTTPS i konsekwencja www/non-www.
- 200 OK na adresie kanonicznym, brak noindex, brak blokady w robots.txt.
- GSC: Inspekcja URL → czy Google akceptuje wskazany kanoniczny?
- Sitemap zawiera wyłącznie kanoniczne adresy; nawigacja linkuje do tej samej postaci.
- Brak canonical → przekierowanie (3xx) i canonical → 3xx/4xx – do poprawy.
E-commerce i parametry: linki kanoniczne w sklepach
Sklepy naturalnie generują duplikaty przez parametry filtrów i sortowania (np. ?color=czarny&sort=price_asc). Zasada bazowa: listing bazowy (bez parametrów) jest kanoniczny, a warianty parametryczne wskazują na niego rel=”canonical”. Dzięki temu sygnały SEO nie rozlewają się po tysiącach kombinacji.
Wyjątki planuję świadomie. Jeśli wybrane kombinacje filtrów mają być strategicznymi landingami SEO (np. „buty do biegania męskie czarne 44”), dostają unikalny content, self-canonical i wsparcie linkowaniem. Reszta wariantów kanonizuje do listingu głównego, by nie marnować crawl budgetu.
Na kartach produktów często spotykam różne odmiany URL (parametry UTM, sesje, wielkość liter, slash na końcu). Wszystkie kanonizuję do jednej, czystej postaci produktu. W przypadkach wariantów (kolor/rozmiar) wybieram model: jeden kanoniczny URL produktu + atrybuty zarządzane na poziomie strony, lub osobne URL-e dla wariantów – ale wtedy każdy ma własny self-canonical i unikalne sygnały.
Paginacja listingu zwykle ma self-canonical na każdej stronie (/kategoria/?p=2 wskazuje na siebie), aby nie konsumować treści dalszych stron przez kanonizację do „1”. Dodatkowo pilnuję, by UTM i inne parametry śledzące zawsze kanonizowały do adresu bez parametrów.
Efekt: czysty, przewidywalny indeks, w którym moc linków i sygnałów skupia się na właściwych adresach – kategoriach i produktach, które mają sprzedawać.
Jak wdrożyć link kanoniczny w CMS (WordPress, OpenCart, Joomla)
CMS-y pozwalają zautomatyzować canonicale: konfiguruję reguły w motywie/wtyczkach i pilnuję spójności z sitemapą.
WordPress: wtyczki SEO (np. Yoast SEO) automatycznie dodają self-canonical. Dla pojedynczej strony/wpisu w Zaawansowanych ustawiam własny adres kanoniczny (np. gdy treść jest współpublikowana). Dbam, by motyw nie dodawał drugiego canonicala. Po publikacji sprawdzam źródło HTML i Inspekcję URL w GSC.
OpenCart: włączam SEO URL i definiuję przyjazne adresy dla produktów/kategorii. W wielu wdrożeniach szablon generuje self-canonical; dla list z parametrami (sort/limit) konfiguruję kanonizację do wersji bez parametrów (często poprzez moduł/OCMOD). QA: czy karta produktu ma stały, kanoniczny adres 200 OK.
Joomla (3+): włączam SEF (Search Engine Friendly URLs), co porządkuje adresy i – w zależności od szablonu/wtyczki SEO – dodaje canonical dla stron technicznych. Jeśli potrzeba, dokładam rozszerzenie SEO, które pozwala ustawić canonical per artykuł/kategorię i wykluczyć parametry. Standardowo weryfikuję jeden canonical w <head> i zgodność z sitemapą.
W każdym CMS dopinam te same zasady: absolutny HTTPS, jeden canonical na stronę, konsekwencja www/slash/małe litery i brak konfliktów (np. canonical do 3xx/4xx lub URL z noindex). Dzięki temu kanonizacja działa przewidywalnie i faktycznie konsoliduje sygnały SEO.
Specjalista SEO z ponad 5-letnim doświadczeniem w marketingu internetowym, od 3 lat ściśle związany z branżą SEO. Na swoim koncie ma dziesiątki zrealizowanych projektów SEO, setki przeprowadzonych audytów stron oraz współpracę z markami z sektora e-commerce i B2B. Na co dzień związany z firmą Webixa Sp. z o.o., gdzie tworzy, rozwija i monitoruje strategie SEO dla klientów. Wykorzystując zdobytą wiedzę i praktykę, postanowił założyć nowoczesną platformę do audytów SEO – audytseo-online.pl, która pomaga firmom rozwijać widoczność w internecie oraz ulepszać i monitorować prowadzone działania SEO.