Dylemat help center subdomena czy katalog rzadko rozstrzyga sam algorytm, bo Google oficjalnie dopuszcza oba warianty. O wyniku decydują linki wewnętrzne, kontrola nad plikiem robots.txt i ograniczenia platformy do bazy wiedzy. Przy równych możliwościach technicznych katalog (firma.pl/pomoc) jest bezpieczniejszym wyborem domyślnym, ale na większości platform SaaS wymaga odwrotnego proxy.
W skrócie
- Google nie preferuje formalnie żadnego wariantu, różnice wynikają z mechaniki działającej osobno dla każdego hosta.
- Subdomena bez linków do strony głównej i produktu zatrzymuje autorytet, który zdobywają artykuły pomocy.
- Zendesk, Intercom i Help Scout natywnie obsługują adres własny tylko na subdomenie.
- Producenci modeli nie publikują danych o przewadze katalogu w cytowaniach, liczy się dostępność dla botów i jakość fragmentu.
- Migracja to przekierowania 301 URL do URL, utrzymywane co najmniej 180 dni.
Help center subdomena czy katalog: co realnie się zmienia?
Zmienia się host, a wraz z nim wszystko, co jest konfigurowane osobno dla hosta. John Mueller z Google powiedział w materiale wideo z 2018 roku, że wyszukiwarka radzi sobie z obiema strukturami, a zmiany struktury URL potrzebują czasu na ustabilizowanie, więc warto wybrać układ na dłużej. Subdomenę Google musi nauczyć się skanować osobno, ale Mueller nazwał to formalnością na pierwsze dni. Wybór nie jest więc obojętny, tylko różnice są głównie operacyjne.
| Obszar | Subdomena (help.firma.pl) | Katalog (firma.pl/pomoc) |
|---|---|---|
| robots.txt | Osobny, działa tylko dla tego hosta | Wspólny z całą domeną |
| Wdrożenie na SaaS | Rekord CNAME, standardowa ścieżka | Odwrotne proxy albo własny front |
| Nawigacja i linki | Zwykle osobny szablon, linki trzeba dodać celowo | Łatwiej współdzielić nagłówek i stopkę |
| Awaria platformy | Nie dotyka głównej strony | Proxy to dodatkowy punkt awarii na głównym hoście |
| Wdrożenia i cookies | Niezależne, łatwa izolacja | Wymagają koordynacji z zespołem strony |
| Koszt utrzymania | Niski | Wyższy przy SaaS, porównywalny przy własnym CMS |
Jak płynie autorytet i dlaczego decydują linki wewnętrzne?
Autorytet przepływa po linkach, więc kluczowe pytanie brzmi, czy baza wiedzy linkuje do stron, które mają zarabiać. Artykuły pomocy zbierają naturalne linki z forów, repozytoriów kodu i blogów klientów, bo ludzie podają je jako rozwiązanie konkretnego problemu. Jeśli szablon pomocy nie linkuje do produktu ani cennika, ta wartość zostaje na miejscu.
W katalogu wspólna nawigacja rozwiązuje problem niejako przy okazji. Na subdomenie trzeba zadbać o to świadomie:
- nagłówek i stopka z odnośnikami do produktu, cennika i bloga;
- link z każdego artykułu do strony funkcji, której dotyczy;
- linki z głównej strony do najważniejszych instrukcji, a nie tylko do strony startowej pomocy.
Publikowane studia migracji z subdomeny do katalogu bywają pozytywne, ale to zwykle obserwacje bez grupy kontrolnej, często połączone z przebudową treści. Nie należy traktować ich jako gwarancji wzrostu.
Czy Search Console i indeksacja działają inaczej?
Raportowanie jest w obu wariantach równie dobre, o ile właściwość założono świadomie. Właściwość domeny obejmuje wszystkie subdomeny, a właściwość z prefiksem URL można założyć zarówno na https://help.firma.pl/, jak i na https://firma.pl/pomoc/. Bazę wiedzy warto mieć jako osobną właściwość w każdym układzie, bo raport strony głównej inaczej miesza dane pomocy z ruchem sprzedażowym.
Prawdziwa różnica leży w robots.txt, który według dokumentacji Google obowiązuje wyłącznie na hoście, na którym się znajduje. Reguły z firma.pl nie chronią ani nie otwierają help.firma.pl. Jest też skutek uboczny: wolna platforma na subdomenie nie spowalnia głównej strony, natomiast w katalogu za proxy każde jej opóźnienie trafia do wspólnego hosta.
Czy domena źródła ma znaczenie dla cytowań w modelach?
Nie ma publicznych danych potwierdzających, że modele wolą katalog od subdomeny. Ani Google, ani OpenAI, ani Perplexity nie opisują takiego sygnału, więc przeciwne twierdzenia należy czytać jako hipotezy. Pewne są za to warunki wstępne: strona musi być osiągalna dla botów, a w przypadku AI Overviews zaindeksowana przez Google.
Układ ma więc znaczenie pośrednie. Na subdomenie trzeba osobno sprawdzić, czy robots.txt nie blokuje OAI-SearchBot, PerplexityBot lub Googlebota, a na SaaS nie zawsze da się ten plik swobodnie zmieniać. Potem o cytowaniu przesądza sam fragment, czyli to, czy dokumentacja podaje ceny, limity i integracje wprost, oraz czy changelog ma daty i jednoznaczną strukturę.
Na co pozwalają platformy SaaS do help center?
Popularne platformy prowadzą wprost do subdomeny, a katalog jest obejściem. Poniższe zestawienie opiera się na dokumentacji i forach producentów według stanu z listopada 2026, więc przed decyzją warto je sprawdzić u dostawcy.
| Platforma | Adres własny natywnie | Katalog |
|---|---|---|
| Zendesk | Tylko subdomena (mapowanie hosta) | Bez wsparcia w mapowaniu, proxy możliwe z zastrzeżeniami |
| Intercom | Tylko subdomena | Bez natywnego wsparcia, na forum opisywane są konfiguracje CloudFront i nginx |
| Help Scout Docs | Tylko subdomena (CNAME) | Bez natywnego wsparcia |
| Własny CMS lub generator statyczny | Dowolnie | Pełna kontrola |
Zendesk w opisie mapowania hosta wyklucza katalog na zewnętrznej stronie. W osobnym artykule o odwrotnym proxy firma ostrzega przed problemami z pamięcią podręczną (usunięte artykuły mogą być widoczne dłużej) i wymaga przekazywania nagłówków bez zmian. W przypadku Intercomu podstawą jest odpowiedź pracownika na forum firmy z 2025 roku, a konfiguracje proxy pochodzą głównie od użytkowników. Kto chce pełnej kontroli, może przenieść bazę wiedzy na własny front, choć architektura headless na WordPressie ma własne koszty renderowania i utrzymania.
Jak przenieść help center z subdomeny do katalogu bez utraty ruchu?
Podstawą są permanentne przekierowania po stronie serwera z każdego starego adresu na jego odpowiednik. Google podaje w przewodniku po przenoszeniu witryn, że przekierowania 301 nie powodują utraty PageRanku. Reguły są podobne jak przy zmianie domeny z .pl na .com, tyle że dotyczą jednej sekcji.
- Inwentaryzacja. Zbierzcie URL-e z mapy witryny, Search Console, logów i raportów linków zwrotnych, razem z wersjami językowymi.
- Mapa 1:1. Każdy artykuł dostaje własny cel. Przekierowanie wszystkiego na stronę startową pomocy kasuje wartość tych adresów.
- Kontrola przekierowań na starym hoście. Sprawdźcie, czy platforma pozwala na 301. Jeśli nie, subdomena musi przejść na własny serwer lub CDN, który je wyda.
- Test. Sprawdźcie canonical, hreflang, robots.txt, tagi noindex oraz wydajność, bo po przeniesieniu Google przez pewien czas skanuje nowy adres intensywniej.
- Przełączenie. Uruchomcie 301 i nową mapę witryny, a linki wewnętrzne, odnośniki w aplikacji i szablony maili zmieńcie na adresy docelowe, aby uniknąć łańcuchów.
- Monitoring. Przez kolejne tygodnie śledźcie raport indeksowania, błędy 404 i ruch na starych adresach.
Przekierowania utrzymajcie co najmniej 180 dni, a lepiej dłużej, bo stare adresy mogą przez długi czas krążyć w odnośnikach zewnętrznych i odpowiedziach modeli. Narzędzie do zmiany adresu działa na właściwościach domeny lub subdomeny, a nie na ścieżkach. Dokumentacja opisuje przeniesienie na ścieżkę w innej domenie, a nie w tej samej, dlatego w tym scenariuszu podstawą pozostają 301.
Który wariant wybrać w konkretnej sytuacji?
Najprościej zacząć od platformy, a dopiero potem porównywać argumenty SEO. Trzy typowe scenariusze rozstrzygają większość przypadków:
- Nowa baza wiedzy na własnym CMS: katalog, bo nie kosztuje dodatkowo i od początku współdzieli nawigację z główną stroną.
- Baza wiedzy na SaaS bez zespołu od infrastruktury: subdomena z dopracowanym linkowaniem, bo proxy bez opieki szybko staje się źródłem awarii.
- Działająca subdomena z ruchem: najpierw linkowanie i dostęp dla botów, a migracja dopiero przy zmianie platformy, gdy koszt przekierowań i tak trzeba ponieść.
Jakie błędy najczęściej psują ten wybór?
- Migracja dla samego SEO, gdy prawdziwym problemem jest brak linków z bazy wiedzy do produktu.
- Proxy bez właściciela po stronie zespołu technicznego, który odpowiada za pamięć podręczną i awarie.
- Zostawienie noindex lub blokady w robots.txt po testach na nowej ścieżce.
FAQ
Czy subdomena dziedziczy autorytet głównej domeny?
Nie ma na to automatycznej gwarancji ani publicznej formuły Google. Praktycznie autorytet przekazują linki, dlatego subdomena powinna dostawać odnośniki z głównej strony i linkować do niej z powrotem. Bez tego help.firma.pl działa jak osobna, słabo powiązana sekcja, nawet jeśli należy do tej samej firmy.
Kiedy subdomena jest lepszym wyborem?
Gdy baza wiedzy działa na SaaS bez wsparcia dla katalogu, zespół nie ma zasobów na utrzymanie proxy albo pomoc ma działać niezależnie od głównej strony. Zadbany help center na subdomenie, z mocnym linkowaniem i otwartym robots.txt, jest lepszy niż niestabilny katalog za źle skonfigurowanym proxy.
Czy warto migrować istniejącą subdomenę do katalogu?
Dopiero po sprawdzeniu tańszych działań, przede wszystkim linkowania do produktu i poprawy indeksacji. Migracja ma sens, gdy i tak zmieniacie platformę lub macie własny front. Trzeba wtedy liczyć się z przejściowymi wahaniami widoczności oraz stałym kosztem utrzymania przekierowań i proxy.
Jak długo trzymać przekierowania ze starego help center?
Google zaleca co najmniej 180 dni, a dłużej, jeśli stare adresy wciąż dostają ruch z wyszukiwarki. W bazie wiedzy warto przyjąć dłuższy horyzont, bo stare linki zostają w zgłoszeniach, mailach, wątkach na forach i dokumentach klientów. Domenę utrzymujecie i tak, więc koszt pozostawienia reguł jest niewielki.