WWW a non-WWW

TL;DR — www.example.com i example.com to różne nazwy hostów, często skonfigurowane tak, aby obsługiwały tę samą witrynę. Żaden z tych formatów nie ma wrodzonej przewagi SEO, więc żaden nie jest „lepszy” dla SEO. Jedynym prawdziwym zadaniem jest wybrać jeden, przekierować drugi na niego i być spójnym wszędzie. To, który wybierzesz, zwykle zależy od konfiguracji hostingu i DNS, a nie od SEO.

Czym właściwie są www i non-www

www w adresie internetowym to subdomena — ten sam rodzaj rzeczy co blog.example.com czy shop.example.com. To po prostu bardzo stara konwencja, która zaczęła oznaczać „to jest strona internetowa”. Wersja bez niej — example.com — nazywana jest domeną nagą, domeną wierzchołkową lub domeną główną. Różne nazwy, to samo.

Obie zwykle wskazują dokładnie te same strony. Więc pytanie „www czy nie?” nie naprawdę dotyczy tego, która jest lepszą witryną — chodzi o to, którą chcesz, aby wyszukiwarki i przeglądarki traktowały jako ten adres.

Czy to wpływa na Twoje pozycje?

Nie. To jedno z najbardziej rozstrzygniętych pytań w całym SEO. Google mówi to samo od dwóch dekad: nie ma preferencji między www a non-www, a przełączenie z jednego na drugie — zrobione poprawnie — nie zmienia Twoich pozycji.

Więc nie trać snu z powodu tego, które jest „bardziej przyjazne SEO”. Żadne nie jest. To, co może Ci zaszkodzić, to robienie tego niedbale: pozwalanie, aby obie wersje ładowały się bez wybrania zwycięzcy, tak że ta sama strona istnieje pod dwoma adresami, a wyszukiwarki muszą zgadywać, którą pokazać.

Jak zrobić to dobrze

1. Wybierz jeden — www lub non-www. Oba są w porządku.
2. Przekieruj drugi na niego za pomocą trwałego przekierowania (301), aby każdy, kto odwiedzi zły, trafił na właściwy.
3. Skieruj wszystko na swój wybór — Twoje linki wewnętrzne, Twoja mapa witryny i wszelkie tagi kanoniczne powinny używać tej samej wersji.

To wszystko. Kiedyś istniało ustawienie w Google Search Console, w którym mówiłeś Google bezpośrednio o swojej preferencji, ale Google je usunął — omówię, co je zastąpiło w wersji Advanced.

Rzecz, którą większość ludzi myli

Ludzie traktują to jako decyzję SEO, podczas gdy to naprawdę decyzja techniczna. Powód, dla którego tak wiele witryn kończy na www, nie ma nic wspólnego z pozycjami, a wszystko z tym, jak działają nazwy domen (DNS) w tle — niektóre konfiguracje dosłownie nie mogą wskazać nagiej domeny tam, gdzie potrzebują, bez dodatkowych kroków. Chcesz mechaniki DNS, pułapki certyfikatowej, która gryzie ludzi w trakcie przełączania, i dlaczego stary argument „domena bez ciasteczek” jest martwy? Przełącz się na zakładkę Advanced.

TL;DR — www to subdomena; non-www to domena wierzchołkowa/naga/główna. Google mówi, że nie ma różnicy w pozycjach od 2005 r., potwierdzone przez Muellera w marcu 2024 r. („kiedy kanoniczny URL się zmienia, po prostu się zmienia”). Ustawienie Preferred Domain w GSC zostało usunięte 18 czerwca 2019 r. — zamiennikiem nie jest przełącznik, ale zestaw zgodnych sygnałów: rel=canonical, uwzględnienie w mapie witryny tylko wybranej wersji oraz trwałe przekierowanie z drugiej. Sygnały kanoniczne mogą być ze sobą sprzeczne, więc spójność we wszystkich z nich ma większe znaczenie niż kiedykolwiek jakiekolwiek pojedyncze ustawienie. Prawdziwy powód, dla którego witryny domyślnie używają www, to DNS — rekord CNAME nie może znajdować się na wierzchołku strefy, więc nagie domeny potrzebują A/AAAA lub ALIAS/ANAME/CNAME-flattening. Uważaj na pułapkę TLS/HSTS na wersji, z której przekierowujesz z, pamiętaj, że ciasteczka host-only nie przechodzą między nazwami hostów, chyba że ustawisz Domain na wierzchołek, i porzuć przestarzały argument domeny bez ciasteczek.

www to subdomena; non-www to wierzchołek

Zacznij od punktu definicyjnego, ponieważ wszystko, co dalej, z niego wynika: www to subdomena, strukturalnie identyczna z blog. lub shop.. example.com to domena wierzchołkowa (również „naga” lub „główna”) — wierzchołek strefy, gdzie znajdują się rekordy SOA i NS domeny. To rozróżnienie brzmi pedantycznie, dopóki nie dojdziesz do DNS, gdzie jest całą historią.

Ponieważ www jest subdomeną, kuszące jest sięgnięcie po wszystko, co Google powiedział na temat subdomen, aby odpowiedzieć na pytanie o ranking — ale to niewłaściwy dowód do tego zadania. Często cytowana wypowiedź Muellera, że Google traktuje subdomeny i podkatalogi “tak samo” algorytmicznie, odpowiada na inne pytanie: gdzie organizować naprawdę różne treści, jak blog na blog.example.com versus /blog/. www versus non-www to nie ten rodzaj wyboru — to identyczna treść dostępna pod dwoma nazwami hostów, co jest kwestią kanonizacji, a nie architektury informacji. Bezpośrednie, dotyczące www dowody na “brak różnicy w rankingu” są poniżej.

Czy www vs non-www wpływa na ranking? Nie.

To jest pytanie, na które wszyscy naprawdę chcą znać odpowiedź, a odpowiedź jest stabilna dłużej niż prawie wszystko w SEO. Oryginalny post Google z 2005 roku na ten temat już przedstawiał to jako problem zduplikowanych URL-i/konsolidacji, a nie rankingowy. Prawie dwadzieścia lat później, w marcu 2024, John Mueller odpowiedział właścicielowi strony, którego migracja Cloudflare po cichu zmieniła kanoniki z www na non-www: “To nie spowoduje problemów z widocznością w wyszukiwarce / rankingiem / indeksowaniem: gdy kanoniczny URL się zmienia, po prostu się zmienia. Możesz zobaczyć mały zgrzyt, ale szybko wróci do normy.”

Jedynym zastrzeżeniem, które dodaje, jest kluczowe rozróżnienie: “Jedyny raz, kiedy mogłoby to spowodować większe zmiany, to jeśli przełączysz kanoniki na inną domenę… przy przełączaniu www/non-www wszystko jest w obrębie tej samej domeny i powinno być w porządku.” Dlatego to mało dramatyczne: www i non-www to ta sama zarejestrowana domena. Nie zmieniasz domen, wybierasz nazwę hosta.

Więc potraktuj “czy to wpływa na ranking” jako już rozstrzygnięte — nie — i poświęć swój wysiłek na części, które faktycznie wymagają pracy: konfigurację DNS i przekierowanie.

Bądź też precyzyjny co do tego, co daje spójność: wybranie jednej nazwy hosta i wyrównanie swoich sygnałów usuwa niejednoznaczność duplikacji dla robotów indeksujących. To nie gwarantuje rankingu, ruchu ani tego, że AI Overview lub chatbot będzie Cię cytować — nic w poprawnym kanonizowaniu nie obiecuje wyniku, po prostu daje wyszukiwarkom i systemom odpowiedzi AI jeden jasny adres, na który mogą wskazywać, zamiast dwóch.

Historia: ustawienie Preferred Domain w GSC

Przez lata Google Search Console miało ustawienie Preferred domain: mówiłeś Google, czy pokazywać Twoją witrynę jako www czy non-www, a ono się do tego stosowało. To ustawienie, które wiele starszych poradników wciąż każe Ci przełączać. Już go nie ma.

Google ogłosiło jego usunięcie w poście z 18 czerwca 2019 Bye Bye Preferred Domain setting: “W miarę postępów w migracji do nowego doświadczenia Search Console, żegnamy się z jednym z naszych ustawień: preferred domain.” I co kluczowe, przestało honorować stare konfiguracje: “Zauważ, że wraz z wycofaniem nie będziemy już używać żadnej istniejącej konfiguracji preferred domain w Search Console.” Więc nawet jeśli ustawiłeś to lata temu, teraz nie robi to nic.

To, co to zastąpiło, to nie nowy przełącznik — to kombinacja sygnałów, które musisz utrzymywać w zgodzie. Google wymieniło opcje w tym samym poście: “Użyj tagu link rel=“canonical” na stronach HTML / Użyj nagłówka HTTP rel=“canonical” / Użyj mapy witryny / Użyj przekierowań 301 dla wycofanych URL-i.” W praktyce oznacza to:

1. Przekierowanie 301 z wersji, której nie wybrałeś, do tej, którą wybrałeś.
2. Tagi rel=canonical wskazujące na wybraną wersję.
3. Mapa witryny, która zawiera tylko wybraną wersję — wytyczne Google z 2005 roku już ostrzegały, aby nie przesyłać obu: posiadanie obu wymienionych “nie wpłynie na indeksowanie Twojej witryny, o ile prześlesz mapę witryny tylko dla jednej wersji.”

Dlaczego “wskazówka, nie reguła” oznacza, że spójność wygrywa

Oto część, która sprawia, że stare podejście z jednym ustawieniem jest niebezpieczne. Dokumentacja Google dotycząca kanonizacji wprost stwierdza, że wszystkie te elementy to sugestie: „wskazanie preferencji kanonicznej to wskazówka, a nie reguła”. Google bierze pod uwagę kilka czynników — HTTP vs HTTPS, przekierowania, uwzględnienie w sitemapie i adnotacje rel=canonical — i może nadal wybrać wersję, której nie chciałeś, jeśli inne sygnały (linki zwrotne, linki wewnętrzne) przechylają szalę w drugą stronę.

To właśnie dlatego spójność na poziomie każdego sygnału ma większe znaczenie niż kiedykolwiek miało jakiekolwiek pojedyncze ustawienie. Znacznik kanoniczny wskazujący na non-www, podczas gdy połowa linków wewnętrznych i sitemap wskazuje na www, to sprzeczny komunikat. Wybierz jeden i spraw, aby wszystko było z nim zgodne — to ta sama zasada „spójność ważniejsza niż optymalizacja”, która przewija się przez prace nad strukturą URL i kanonizacją w tym klastrze; www vs non-www to tylko jeden z około 40 sygnałów kanonizacji skatalogowanych tam.

Dlaczego więc tak wiele witryn domyślnie używa www? DNS.

To pytanie, które pomija prawie każdy inny artykuł, a oto faktyczna odpowiedź: DNS, nie SEO, nie branding.

Rekord CNAME to prosty sposób na wskazanie hostname na CDN lub host: robisz CNAME dla www.example.com na hostname dostawcy i to po prostu działa — i działa dalej, jeśli dostawca zmieni adresy IP. Ale specyfikacja DNS nie pozwala, aby CNAME znajdował się na apeksie strefy. Apeks musi zawierać rekordy SOA i NS, a CNAME musi być jedynym rekordem w swoim węźle — te dwie zasady są sprzeczne, więc goły CNAME na example.com jest niezgodny ze specyfikacją (RFC 1912 / 2181), a większość dostawców DNS go odrzuca.

Aby uzyskać to samo zachowanie „wskaż na mój CDN” na gołej domenie, potrzebujesz jednego z:

• rekordu A/AAAA (wymaga statycznego adresu IP, którego wiele konfiguracji CDN/hostingu nie udostępnia), lub
• rekordu ALIAS / ANAME specyficznego dla dostawcy, lub spłaszczania CNAME w Cloudflare — wszystkie te rozwiązania udają CNAME na apeksie, rozwiązując go po stronie serwera. Nie każdy dostawca DNS je obsługuje.

To tarcie jest bardzo prawdopodobnie faktycznym powodem, dla którego tak wiele platform domyślnie wybiera www: to hostname, który zawsze może przyjąć prosty CNAME. To decyzja hostingowa/DNS ubrana w SEO.

Ciasteczka są ograniczone do wybranego hostname

Wybór hostname ma drugą, łatwą do przeoczenia konsekwencję: zakres ciasteczek. Ciasteczko ustawione bez atrybutu Domain to ciasteczko host-only — jest wysyłane z powrotem tylko do dokładnie tego hosta, który je ustawił. Ustaw ciasteczko sesyjne na www.example.com bez atrybutu Domain, a nigdy nie dotrze do example.com (ani żadnej innej subdomeny) i odwrotnie.

Jeśli chcesz, aby ciasteczko było współdzielone między apeksem a jego subdomenami, ustaw Domain jawnie na apeks — np. Domain=example.com. Zgodnie z RFC 6265, wartość Domain ciasteczka musi odpowiadać bieżącemu hostowi lub jego rodzicowi, więc możesz ustawić Domain=example.com ze strony serwowanej na www.example.com, a ciasteczko będzie wtedy dotyczyć example.com i każdej subdomeny — ale nie możesz ustawić Domain dla niezwiązanej domeny.

Ma to największe znaczenie podczas migracji. Jeśli Twoje ciasteczka sesyjne lub preferencyjne są host-only na wersji, którą wycofujesz, ten stan nie przenosi się przez 301 na nowy hostname — odwiedzający mogą zostać wylogowani lub stracić zapisaną preferencję przy pierwszej wizycie po zmianie. Ustaw Domain na apeks przed migracją, jeśli potrzebujesz ciągłości między oboma hostname, gdy przekierowanie jest aktywne, albo zaplanuj jednorazowe ponowne logowanie w dniu zmiany.

Przestarzały argument o domenie bez ciasteczek

Nadal można spotkać porady, aby używać osobnej domeny bez ciasteczek (często gołej domeny lub dedykowanej subdomeny dla zasobów) dla plików statycznych. To była prawdziwa optymalizacja z czasów HTTP/1.1: każde żądanie do domeny z ciasteczkami wysyłało bajty ciasteczek wraz z nim, nawet dla obrazów i CSS, więc serwowanie zasobów statycznych z hosta bez ciasteczek oszczędzało narzut. GTmetrix i PageSpeed kiedyś to flagowały.

To już w dużej mierze martwe. Kompresja nagłówków HPACK w HTTP/2 oraz niemal powszechne użycie CDN-ów do statycznych zasobów niwelują większość korzyści, a rozdzielenie zasobów na osobny host kosztuje teraz dodatkowe nawiązanie połączenia. Nie wybieraj www vs non-www — ani nie uruchamiaj subdomeny dla zasobów — z tego powodu w 2026 roku.

Pułapka HSTS i certyfikatów

Oto praktyczny haczyk, który łapie ludzi w trakcie przełączania, a który jest naprawdę słabo opisany gdzie indziej. Gdy przekierowujesz jedną nazwę hosta na drugą, nazwa hosta, z której przekierowujesz, nadal potrzebuje własnego ważnego certyfikatu TLS. 301 z https://www.example.com na https://example.com jest wykonywane dopiero po tym, jak przeglądarka zakończy uzgadnianie TLS z www.example.com — więc jeśli www nie ma ważnego certyfikatu (lub certyfikatu, który go nie obejmuje), odwiedzający zobaczy ostrzeżenie bezpieczeństwa na całej stronie zanim Twoje przekierowanie w ogóle zadziała. Obejmij obie nazwy hosta — osobnymi certyfikatami lub jednym certyfikatem SAN/wildcard.

HSTS to zaostrza. Polityka HSTS jest specyficzna dla hosta — polityka ustawiona na example.com nie chroni automatycznie www.example.com i odwrotnie. includeSubDomains propaguje się tylko w jednym kierunku (polityka rodzica może obejmować jego subdomeny; polityka subdomeny nigdy nie obejmuje rodzica). Jeśli więc jesteś na liście preload HSTS lub wymuszasz HTTPS, upewnij się, że historia certyfikatów i HSTS jest spójna na obu nazwach hosta, w przeciwnym razie krok wymuszonego HTTPS ujawni ostrzeżenie o brakującym certyfikacie przed przekierowaniem.

Bing nie ma odpowiednika Preferred Domain

Bing nigdy nie miał przełącznika preferred domain. W praktyce Bing Webmaster Tools traktuje www, non-www oraz każdą kombinację HTTP/HTTPS jako osobne właściwości do weryfikacji i raportowania — więc nawet po wybraniu kanonicznej wersji i przekierowaniu reszty, będziesz zarządzać wariantami jako odrębnymi właściwościami. Mechanizm konsolidacji jest taki sam jak w Google: ustaw 301 po stronie serwera, utrzymuj kanoniki i adresy URL w mapie witryny zgodne z Twoim wyborem.

Jak faktycznie wybrać jedną i się jej trzymać

1. Wybierz na podstawie rzeczywistości DNS/hostingu, a nie SEO. Jeśli Twój hosting/CDN wymaga CNAME, a Twój dostawca DNS nie obsługuje ALIAS/spłaszczania, www jest ścieżką najmniejszego oporu. Jeśli Twój DNS obsługuje spłaszczanie apex i wolisz czystszą gołą domenę, wybierz non-www. Preferencja marki jest dobrym kryterium rozstrzygającym — to prawdziwy remis.
2. Przekieruj drugą wersję za pomocą 301 — stałe 301, nie 302. (302 sygnalizuje „tymczasowe” i nie konsoliduje tak, jak chcesz.)
3. Spraw, aby tagi kanoniczne, mapa witryny i linki wewnętrzne były zgodne co do zwycięzcy.
4. Sprawdź, czy ciasteczka logowania/preferencji są ograniczone do hosta. Jeśli potrzebujesz sesji lub zapisanych preferencji, które przetrwają przełączenie, ustaw Domain na apex przed włączeniem przekierowania — w przeciwnym razie przygotuj się na to, że odwiedzający zostaną wylogowani raz.
5. Upewnij się, że obie nazwy hosta mają ważne certyfikaty, aby przekierowanie nigdy nie wywołało ostrzeżenia.
6. Dodaj/zweryfikuj właściwości w Google Search Console (właściwości Domain obejmują wszystkie warianty) i Bing Webmaster Tools (zweryfikuj warianty osobno).

Potem zostaw to w spokoju. Jak przy ogólnej zmianie adresów URL, ponowne rozważanie www vs non-www na działającej stronie to wysiłek bez zysku w rankingu.

Podsumowanie AI

Skrócona wersja wersji zaawansowanej:

• Definicje: www to subdomena; example.com to domena główna (apex / bare / root). Obie serwują tę samą treść, więc jest to wybór kanonizacji, a nie rankingowy.
• Brak różnicy w rankingu — Google mówi to od 2005 roku; Mueller (marzec 2024): gdy kanon zmienia się w obrębie tej samej domeny, „to po prostu się zmienia” — może być krótki spadek. Ryzyko występuje przy zmianie na inną domenę, nie przy www/non-www. (Osobna wypowiedź Muellera o subdomenach i podkatalogach traktowanych „tak samo” odpowiada na pytanie o organizację treści, nie o ranking — nie myl tych dwóch kwestii.) Spójność nie jest też gwarancją pozycji, ruchu ani cytowań AI — po prostu daje crawlerom i silnikom odpowiedzi jeden jasny adres.
• Ustawienie Preferred Domain w GSC zostało usunięte 18 czerwca 2019 r., a stare konfiguracje nie są już honorowane. Zastępuje je zestaw zgodnych sygnałów: rel=canonical + sitemap wymieniający tylko wybraną wersję + 301 z drugiej.
• Sygnały kanonizacji to wskazówka, nie reguła — Google może wybrać wersję, której nie chcesz, więc wszystkie sygnały muszą być zgodne. www/non-www to jeden z ~40 sygnałów kanonizacji.
• Prawdziwy powód, dla którego strony domyślnie używają www, to DNS: rekord CNAME nie może znajdować się w strefie głównej (konflikt SOA/NS, RFC 1912/2181), więc domeny gołe wymagają A/AAAA lub ALIAS/ANAME/spłaszczania CNAME. www zawsze może użyć prostego CNAME.
• Ciasteczka są ograniczone do hosta: ciasteczko host-only (bez atrybutu Domain) nie przechodzi z www na non-www ani z powrotem; ustaw Domain=example.com przed migracją, jeśli sesje lub preferencje mają przetrwać zmianę.
• Argument o domenie bez ciasteczek jest przestarzały po HTTP/2 (HPACK + CDN).
• Pułapka TLS/HSTS: hostname, z którego przekierowujesz, nadal potrzebuje ważnego certyfikatu, w przeciwnym razie ostrzeżenie bezpieczeństwa pojawi się przed 301. HSTS jest specyficzny dla hosta; includeSubDomains działa tylko z rodzica na subdomenę.
• Bing nie ma przełącznika preferowanej domeny — traktuje www/non-www/HTTP/HTTPS jako osobne właściwości.
• Zalecenie: wybierz jedną na podstawie DNS/hostingu, ustaw 301 (nie 302) dla drugiej, dopasuj kanoniki/sitemap/wewnętrzne linki, certyfikuj oba hostname i przestań to zmieniać.

Oficjalna dokumentacja

Dokumentacja źródłowa od wyszukiwarek.

Google

• Koniec ustawienia Preferred Domain (2019) — usunięcie funkcji 18 czerwca 2019 r. i dokładna lista jej następców: tag lub nagłówek kanoniczny, mapa witryny i 301s.
• Czym jest kanonikalizacja URL — czynniki uwzględniane przez Google (HTTP/HTTPS, przekierowania, mapa witryny, rel=canonical) oraz zasada „wskazówka, nie reguła”.
• Konsolidowanie zduplikowanych adresów URL — artykuł pomocy wskazany we wpisie z 2019 r. jako instrukcja deklarowania preferowanej wersji.
• Wersje witryny z www i bez www (2005) — historyczny wpis założycielski, dziś oznaczony przez Google banerem o nieaktualnej treści.
• Przewodnik SEO dla początkujących — ogólne omówienie zduplikowanych URL-i i ich konsolidacji.

Bing / Microsoft

• Bing Webmaster Guidelines — ogólne stanowisko Binga w sprawie kanonizacji; brak przełącznika preferowanej domeny.
• Better than canonical: URL Normalization — podejście Binga do normalizacji (301 preferowane, rel=canonical drugorzędne).

Cytaty ze źródła

Oficjalne wypowiedzi Google. Każdy link to link bezpośredni, który przeskakuje do cytowanego fragmentu na stronie źródłowej.

Google, 2005 — oryginalne ujęcie

• “Two URLs to a site—one that is prefaced with www and one that is not (for instance, https://www.example.com/ and https://example.com/)—often point to the same location on a server. But depending on the server configuration, they may point to different locations, so search engines can’t assume they are the same.” (tłumaczenie) „Dwa adresy URL witryny — jeden z prefiksem www, drugi bez — często wskazują to samo miejsce na serwerze. Zależnie od konfiguracji mogą jednak prowadzić do różnych miejsc, dlatego wyszukiwarki nie mogą zakładać, że są identyczne”. — Vanessa Fox, Google. Przejdź do cytatu
• “Note that having both versions of the site’s URL listed in your account won’t affect the indexing of your site as long as you have submitted a Sitemap for only one version—the version you want to be indexed.” (tłumaczenie) „Obecność obu wersji URL-a witryny na koncie nie wpłynie na jej indeksowanie, o ile prześlesz mapę witryny tylko dla jednej wersji — tej, którą chcesz indeksować”. — Vanessa Fox, Google. Przejdź do cytatu

Google, czerwiec 2019 — usunięcie preferowanej domeny

• “As we progress with the migration to the new Search Console experience, we will be saying farewell to one of our settings: preferred domain.” (tłumaczenie) «W miarę postępów migracji do nowego Search Console pożegnamy się z jednym z naszych ustawień: preferowaną domeną.» — Daniel Waisberg, Google. Przejdź do cytatu
• “Note that with the deprecation we will no longer use any existing Search Console preferred domain configuration.” (tłumaczenie) «Zauważ, że wraz z wycofaniem nie będziemy już używać żadnej istniejącej konfiguracji preferowanej domeny w Search Console.» — Daniel Waisberg, Google. Przejdź do cytatu
• “Use rel=“canonical” link tag on HTML pages” — pierwsza z czterech opcji zastępczych (tag kanoniczny, kanoniczny nagłówek HTTP, sitemap, przekierowania 301). Przejdź do cytatu

Google — kanonikalizacja to wskazówka, nie reguła

• “There are a handful of factors that play a role in canonicalization” (tłumaczenie) „W kanonikalizacji uczestniczy kilka czynników” — lista Google obejmuje HTTP i HTTPS, przekierowania, obecność mapy witryny oraz adnotacje rel=canonical; “indicating a canonical preference is a hint, not a rule.” (tłumaczenie) „wskazanie preferencji kanonicznej jest wskazówką, a nie regułą”. Przejdź do cytatu
• “The canonical page will be crawled most regularly; duplicates are crawled less frequently in order to reduce the crawling load on sites.” (tłumaczenie) „Strona kanoniczna będzie crawlowana najczęściej; duplikaty są crawlowane rzadziej, aby ograniczyć obciążenie witryn”. Przejdź do cytatu

John Mueller, Google — marzec 2024, o zmianie kanonikali www ⇄ non-www

• “This won’t cause problems with search visibility / rankings / indexing: when the canonical URL switches, it just switches. You might see a little blip, but it goes to normal very quickly.” (tłumaczenie) „Nie spowoduje to problemów z widocznością w wyszukiwarce, pozycjami ani indeksowaniem: gdy zmienia się kanoniczny URL, po prostu następuje zmiana. Możesz zauważyć niewielkie wahnięcie, ale sytuacja bardzo szybko wraca do normy”. — John Mueller, Reddit.
• “The only time it would cause bigger changes is if you switch canonicals to a different domain, and the domains have something different set up… with a www/non-www switch it’s all within the same domain and you should be fine.” (tłumaczenie) „Większe zmiany mogłyby wystąpić tylko przy przełączeniu adresów kanonicznych na inną domenę, gdy domeny mają odmienną konfigurację… przy zmianie www na non-www wszystko pozostaje w tej samej domenie i powinno być w porządku”. — John Mueller, Reddit. Oba cytaty pochodzą z odpowiedzi Muellera na Reddicie, opisanych przez Barry’ego Schwartza w Search Engine Roundtable 19 marca 2024 r. Oryginalny wątek nie został niezależnie pobrany ponownie, dlatego źródłem referencyjnym pozostaje SERoundtable.

John Mueller, Google — subdomeny traktowane tak samo (kontekst pomocniczy, nie specyficzny dla www)

• “In general, we see these the same… I would personally try to keep things together as much as possible… Use subdomains where things are really kind of slightly different.” (tłumaczenie) „Zasadniczo traktujemy je tak samo… Osobiście starałbym się utrzymywać wszystko razem w największym możliwym stopniu… Subdomen używaj tam, gdzie elementy rzeczywiście nieco się różnią”. — John Mueller o subdomenach i podkatalogach. Przeczytaj omówienie To odpowiedź na pytanie o organizację różnych treści w subdomenach lub podkatalogach, a nie o wpływ www/non-www na pozycje. Cytat pokazuje jedynie, że www jest strukturalnie subdomeną jak każda inna; twierdzenie o braku różnicy rankingowej opiera się na wpisie z 2005 r. i odpowiedzi Muellera z 2024 r. przytoczonej wyżej.

Który wybrać — i jak?

Nie ma tu odpowiedzi SEO-owej, więc ten schemat prowadzi Cię przez rzeczywistość DNS/hostingu, a następnie podaje kroki egzekwowania. Zacznij od góry.

Lista kontrolna konsolidacji www/non-www

Przejście, aby potwierdzić, że jedna wersja jest kanoniczna, a druga czysto przekierowana:

• Wybrano jedną wersję jako kanoniczną (www lub non-www) — wybór podyktowany rzeczywistością DNS/hostingu, a nie wyimaginowaną przewagą SEO.
• DNS poprawnie rozwiązuje domenę główną — A/AAAA, lub ALIAS/ANAME/ spłaszczanie CNAME (goły CNAME na poziomie głównym jest nieprawidłowy i zostanie odrzucony).
• Pojedyncze 301 (stałe, nie 302) z niepreferowanego hosta na preferowany, zdefiniowane w dokładnie jednym miejscu (bez sprzecznych reguł → bez pętli przekierowań).
• Oba hosty prezentują ważny certyfikat TLS (SAN lub wildcard obejmujący www i non-www), aby przekierowanie nigdy nie wywoływało ostrzeżenia bezpieczeństwa w przeglądarce.
• HSTS jest spójny na obu hostach — pamiętaj, że includeSubDomains działa tylko z rodzica na subdomenę.
• Ciasteczka ustawiają Domain=example.com (nie pozostają tylko dla hosta) przed migracją, jeśli sesje lub preferencje mają przetrwać zmianę.
• rel=canonical na każdej stronie wskazuje wybraną wersję.
• Mapa witryny XML zawiera tylko URL-e wybranej wersji — nie przesyłaj obu.
• Linki wewnętrzne konsekwentnie używają wybranej wersji (bez bezwzględnych linków do drugiego hosta).
• Brak subdomeny z zasobami bez ciasteczek utworzonej tylko z przestarzałego powodu z epoki HTTP/1.1.
• Google Search Console — dodano właściwość Domeny (obejmuje wszystkie warianty).
• Bing Webmaster Tools — warianty zweryfikowane jako osobne właściwości.
• Nie planujesz zmiany działającej konfiguracji dla SEO — nie ma zysku.

www vs non-www — ściągawka

Decyzja w skrócie

Rzeczywistość DNS: strefa główna vs www

Szybkie fakty

• Preferowana domena usunięta: 18 czerwca 2019 (a stare konfiguracje nie są już honorowane).
• Sygnały kanonikalizacji: ~40, a www/non-www jest jednym z nich.
• Statyczna domena bez ciasteczek: przestarzała po HTTP/2 (HPACK + CDN).
• Ciasteczka tylko dla hosta: nie przechodzą między www ↔ non-www, chyba że ustawiono Domain=example.com.
• HSTS includeSubDomains: propaguje od rodzica tylko do subdomen.

Przekieruj jedną wersję na drugą

Wybierz wersję kanoniczną, a następnie przekieruj drugą do niej za pomocą 301. Konfiguracja dla trzech popularnych serwerów WWW — dostosuj kierunek do swojego wyboru.

Apache (.htaccess) — przekierowanie non-www → www

RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]

Apache (.htaccess) — przekierowanie www → non-www

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com [NC]
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]

Nginx — przekierowanie non-www → www (osobny blok serwera, bez wykonywanego przy każdym żądaniu if)

server {
    listen 443 ssl;
    server_name example.com;
    # This host still needs a valid cert, or the 301 never fires:
    ssl_certificate     /etc/ssl/example.com.pem;
    ssl_certificate_key /etc/ssl/example.com.key;
    return 301 https://www.example.com$request_uri;
}

Nginx — redirect www → non-www

server {
    listen 443 ssl;
    server_name www.example.com;
    ssl_certificate     /etc/ssl/www.example.com.pem;
    ssl_certificate_key /etc/ssl/www.example.com.key;
    return 301 https://example.com$request_uri;
}

IIS (web.config) — przekierowanie non-www → www

<rule name="Redirect to www" stopProcessing="true">
  <match url="(.*)" />
  <conditions>
    <add input="{HTTP_HOST}" pattern="^example\.com$" />
  </conditions>
  <action type="Redirect" url="https://www.example.com/{R:1}"
          redirectType="Permanent" />
</rule>

Trzymaj regułę tylko w jednym miejscu — druga reguła wskazująca w przeciwnym kierunku (we wtyczce, CDN lub ustawieniu CMS) to klasyczna przyczyna pętli przekierowań www/non-www.

Zweryfikuj przekierowanie i oba certyfikaty

macOS / Linux — potwierdź pojedyncze, bezpośrednie przekierowanie 301 oraz ważny certyfikat na obu hostach:

# Follow the redirect chain — you want ONE 301 to the canonical host
curl -sIL https://example.com/ | grep -Ei 'HTTP/|^location:'

# Check the cert on the host you redirect FROM (must be valid, or the 301 never fires)
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -dates

Windows (PowerShell)

# Inspect the redirect without auto-following it
Invoke-WebRequest -Uri "https://example.com/" -MaximumRedirection 0 `
  -ErrorAction SilentlyContinue | Select-Object StatusCode, Headers

Jeśli nagłówek Location wskazuje wybraną wersję z kodem 301, a oba hosty prezentują ważny certyfikat, gotowe.

Czego nie robić

Obsługa obu wersji bez przekierowania. Jedyny naprawdę szkodliwy scenariusz: każda strona dostępna zarówno pod www, jak i bez www, bez skonsolidowania. Wtedy wyszukiwarki widzą zduplikowane adresy URL i muszą zgadywać kanoniczny. To — nie sam wybór www/non-www — powoduje problemy.

Użycie 302 zamiast 301. 302 oznacza „tymczasowe”. Chcesz trwałej konsolidacji i przeniesienia autorytetu przez 301. Zarezerwuj 302 dla naprawdę tymczasowych przenosin.

Dwie reguły przekierowań walczące ze sobą. Reguła w CMS-ie wysyła non-www → www, a reguła CDN wysyła www → non-www — nieskończona pętla przekierowań („zbyt wiele przekierowań”). Wymuś wybór dokładnie w jednej warstwie.

Zapomnienie o certyfikacie na hoście przekierowującym. Przekierowanie www → non-www, ale certyfikowanie tylko gołej domeny oznacza, że odwiedzający https://www. zobaczą ostrzeżenie bezpieczeństwa przed wykonaniem 301. Obejmij oba hosty.

Zmienianie działającej, skonsolidowanej konfiguracji „dla SEO”. Nie ma zysku w rankingu, tylko niewielkie ryzyko nieudanego przekierowania lub chwilowego problemu. Jeśli działa, nie ruszaj.

Gonienie starego ustawienia GSC Preferred Domain. Zniknęło w czerwcu 2019, a stare konfiguracje są ignorowane. Podążanie za poradnikiem, który każe je przełączyć, marnuje czas i daje fałszywe poczucie, że zadanie jest zrobione — prawdziwa praca to 301 + canonical + sitemap.

Tworzenie poddomeny bez ciasteczek dla zasobów w celu przyspieszenia. Ten trik z ery HTTP/1.1 jest przestarzały po HTTP/2; dziś dodatkowe połączenie zwykle kosztuje więcej, niż oszczędzają usunięte bajty ciasteczek.

Mieszanie sygnałów. Tag canonical wskazujący na non-www, podczas gdy sitemap i linki wewnętrzne wskazują na www, to sprzeczna wskazówka. Ponieważ kanonikalizacja to wskazówka, a nie reguła, upewnij się, że wszystkie sygnały są zgodne.

Typowe błędy kanonikalizacji hosta

Oba hosty zwracają 200

Objaw: www.example.com/page i example.com/page ładują się niezależnie. Prawdopodobna przyczyna: DNS wskazuje oba hosty na witrynę, ale nie jest wymuszone przekierowanie preferowanego hosta. Rozwiązanie: Wybierz ustalony host, trwale przekieruj alternatywny w jednym skoku i dopasuj canonical, linki wewnętrzne oraz sitemapy.

Alternatywny host pokazuje błąd certyfikatu

Objaw: HTTPS zawodzi, zanim przeglądarka może podążyć za przekierowaniem. Prawdopodobna przyczyna: Certyfikat obejmuje tylko preferowany host. Rozwiązanie: Utrzymuj ważny DNS i pokrycie TLS na hoście przekierowującym; połączenie HTTPS musi się powieść, zanim można otrzymać przekierowanie HTTP.

Żądania hosta zapętlają się lub tworzą łańcuch

Objaw: Żądania przeskakują między hostami lub przechodzą przez osobne skoki HTTP, HTTPS, hosta i ukośnika. Prawdopodobna przyczyna: Reguły CDN, origin i aplikacji nie zgadzają się co do miejsca docelowego. Rozwiązanie: Zdefiniuj jedną politykę finalnego URL i spraw, aby każda alternatywna trasa prowadziła bezpośrednio do niego na najwcześniejszej kontrolowanej warstwie.

Przejrzyj plan migracji hosta

Wklej rekordy DNS, nazwy hostów certyfikatów, reguły przekierowań, próbki canonical, hosty sitemap, konfigurację analityki i reprezentatywną mapę URL:

Audit this www/non-www migration plan. Identify contradictions between DNS, TLS,
redirects, canonicals, internal links, sitemaps, and measurement. For every issue,
state the observed evidence, the likely user or crawler impact, the exact check to
run, and whether it blocks launch. Do not claim one hostname has an SEO ranking
advantage. Return a pre-launch table and a post-launch verification sequence.

Narzędzia do wyboru i egzekwowania jednego hosta

• Redirect Chain Mapper — śledź zmiany HTTP/HTTPS, www/non-www, ukośnika i ścieżki razem, aby kończyły się na jednym URL w jednym skoku.
• Canonicalization Checker — znajdź strony, których host canonical koliduje z odpowiedzią lub finalnym celem przekierowania.
• Redirect Checker — sprawdź pasujące ścieżki na obu hostach po zmianie konfiguracji.
• Narzędzia do inspekcji DNS i TLS — potwierdź, że oba hosty rozwiązują się i prezentują ważne certyfikaty, w tym host istniejący tylko do przekierowania.
• Pełny crawler witryny — znajdź linki wewnętrzne, canonical, adnotacje hreflang i adresy URL sitemap, które nadal emitują alternatywny host.

Zweryfikuj równoważne adresy URL na obu hostach

Test do wykonania: Prześlij pasujące ścieżki www i non-www do Redirect Chain Mapper. Oczekiwany wynik: Preferowany host ładuje się poprawnie, a alternatywny trwale przekierowuje na tę samą ścieżkę na preferowanym hoście w jednym skoku. Interpretacja błędu: Brakujące reguły, odwrotny kierunek lub odrzucanie ścieżek i zapytań. Okno monitorowania: Natychmiast po wdrożeniu. Wyzwalacz wycofania: Pętle przekierowań, szerokie przekierowania strony głównej lub błędy na preferowanym hoście.

Weryfikacja TLS i emitowanych sygnałów

Test do wykonania: Połącz się z obydwoma hostami HTTPS, a następnie przeszukaj kanoniki, wewnętrzne linki i adresy URL z sitemap. Oczekiwany wynik: Oba certyfikaty są prawidłowe, a każdy emitowany sygnał SEO używa preferowanej nazwy hosta. Interpretacja błędu: Alternatywa nie może dostarczyć przekierowania lub szablon/konfiguracja nadal używa starego hosta. Okno monitorowania: Natychmiast dla TLS; po pełnym przeszukaniu dla sygnałów ogólnowitrynnych. Wyzwalacz wycofania: Błędy certyfikatu lub pojawienie się dużej liczby konfliktowych kanoników.

Sprawdź się: WWW vs. Non-WWW

Pięć szybkich pytań o to, czym naprawdę jest wybór www/non-www i jak go egzekwować. Wybierz odpowiedź na każde, a następnie sprawdź.

Zasoby warte Twojego czasu

Moje powiązane teksty

• Google używa około 40 sygnałów kanonikalizacji — szerszy kontekst www/non-www, w tym sposób ważenia przekierowań, adresów kanonicznych i map witryn.
• Przekierowania w SEO: prosty, ale kompletny przewodnik — przechodzenie między wersjami za pomocą 301s bez utraty wartości.
• Końcowy ukośnik: używać czy nie? — ta sama zasada „wybierz jeden wariant i konsekwentnie go egzekwuj” zastosowana do innego sygnału kanonikalizacji.
• Przewodnik dla początkujących po technicznym SEO — miejsce kanonikalizacji i konsolidacji nazw hostów w szerszym obrazie.

Moje wystąpienia

• Jak działa wyszukiwarka (SlideShare) — moje omówienie crawlowania, renderowania, indeksowania i rankingu, czyli procesu zasilanego przez kanonikalizację. Obowiązuje moje stałe zastrzeżenie: “This is my understanding of systems… not going to be 100% complete or accurate.” (tłumaczenie) „Tak rozumiem te systemy… opis nie będzie w 100% kompletny ani dokładny”.

Z branży

• Koniec ustawienia Preferred Domain (Google Search Central) — usunięcie funkcji w czerwcu 2019 r. i jej następcy, opisani u źródła.
• Czym jest kanonikalizacja URL (Google Search Central) — zasada „wskazówka, nie reguła” oraz czynniki uwzględniane przez Google.
• Google: przejście z WWW na non-WWW nie wpłynie na pozycje (Search Engine Roundtable, Barry Schwartz) — odpowiedź Muellera z marca 2024 r.: “it just switches” (tłumaczenie) „po prostu następuje zmiana”.
• WWW czy non-WWW: co jest lepsze dla SEO? (Search Engine Journal, Winston Burton) — omówienie zasady: brak istotnej różnicy, wybierz jeden wariant, a drugi skieruj do niego przekierowaniem 301.
• Dlaczego domena główna nie może być rekordem CNAME — i inne informacje o DNS (freeCodeCamp) — proste wyjaśnienie ograniczenia apex/CNAME.
• Spłaszczanie CNAME (dokumentacja Cloudflare DNS) — sposób, w jaki dostawca symuluje CNAME w domenie apex.
• Przekierowania HSTS: WWW do non-WWW i HTTP do HTTPS (Sentinel Stand) — pułapka certyfikatu i HSTS podczas przekierowań między hostami.

Dziennik zmian