Google zaindeksował stronę pod złą subdomeną: jak to posprzątać

Wpisujesz w Google nazwę firmy, a pod pierwszym wynikiem zamiast www.twojadomena.pl stoi ftp.twojadomena.pl, staging.twojadomena.pl albo goły adres IP serwera. Deweloper zapewnia, że subdomenę już usunął, a wyniki się nie zmieniają. Dokładnie takie pytanie trafiło 23 października 2026 na r/DoSEO i r/TechSEO, a po kwadransie odpowiedział na nie John Mueller z Google. Platforma nie ma tu znaczenia: tak samo kończy WordPress, sklep na Shopify z własną domeną, frontend headless i strona statyczna.

Poniżej znajdziesz kolejność, która działa: najpierw sprawdzasz, co stary host zwraca dziś, potem wybierasz właściwą usługę w Search Console, a na końcu wzmacniasz sygnały domeny głównej. Wszystkie terminy pochodzą z dokumentacji Google Search Central.

#Co dziś zwraca stara subdomena i jak to sprawdzić

Najważniejsza uwaga z wątku dotyczyła diagnozy, nie narzędzi:

Najpierw sprawdź, co faktycznie zwraca dziś stary adres HTTPS: błąd DNS to nie jest 404.

(u/inevidimka, r/DoSEO, 23 października 2026, tłumaczenie własne)

Wystarczą dwa polecenia:

dig +short ftp.example.com
curl -sI https://ftp.example.com/blog/przykladowy-wpis

Pusty wynik dig oznacza, że nazwa już się nie rozwiązuje. Jeśli dig zwraca IP, curl pokaże, czy dostajesz 200 z całą stroną, 404 albo 410, przekierowanie, czy błąd TLS, bo certyfikat nie obejmuje tej nazwy. Sprawdź kilka adresów, które Google faktycznie pokazuje, a nie tylko stronę główną. Google w poradniku o błędach DNS i sieci używa dig w ten sam sposób do sprawdzania rekordów A, CNAME i NS.

Zdanie “deweloper usunął subdomenę” może opisywać każdy z tych stanów. Najczęstsza pułapka: usunięty wirtualny host przy pozostawionym rekordzie DNS. Wtedy odpowiada domyślna witryna serwera, czyli zwykle ta sama strona co na www, i problem wraca w nowej formie.

#Dlaczego Google wybrał subdomenę ftp zamiast www

Autor wątku dobrze opisał to, co pokazało mu sprawdzenie adresu w Search Console. Adres na ftp był zaindeksowany, indeksowanie dozwolone, pobranie udane. Jego odpowiednik na www był dla Google nieznany, bez mapy witryny i bez strony odsyłającej. Kluczowy szczegół:

Kanoniczny adres zadeklarowany przez użytkownika wskazywał na sam adres FTP. Kanoniczny adres wybrany przez Google też był adresem FTP.

(u/Gullible-Winter294, r/DoSEO, 23 października 2026, tłumaczenie własne)

Do takiego wyniku prowadzą trzy warunki naraz. Rekord DNS (ftp, staging albo wildcard) wskazuje ten sam serwer co strona produkcyjna. Serwer odpowiada na tę nazwę stroną produkcyjną, bo jest ona domyślnym hostem wirtualnym. A szablon buduje tag canonical z nazwy hosta w żądaniu zamiast ze skonfigurowanego adresu bazowego, więc każda kopia ogłasza się oryginałem. Google ma dwie identyczne strony, z których każda twierdzi, że jest właściwa, i wybiera jedną z nich.

#Czy kod 404 lub 410 usuwa adresy z Google

Tak. Dokumentacja kodów HTTP mówi, że adresy już zaindeksowane, które zwracają kod 4xx, są usuwane z indeksu. Wszystkie kody 4xx poza 429 Google traktuje jednakowo, więc 404 i 410 działają tak samo, a częstotliwość odwiedzin takich adresów stopniowo spada.

Błąd DNS to inna droga z podobnym skutkiem. Google traktuje błędy DNS, przekroczenia czasu i zerwane połączenia jak błędy serwera 5xx, a poradnik DNS mówi, że nieosiągalne zaindeksowane adresy znikają z indeksu w ciągu kilku dni. W obu przypadkach Google musi najpierw ponownie odwiedzić adres i stąd bierze się czekanie. Jeden z komentujących podał termin:

Google usunie je z indeksu, gdy zobaczy błąd 404. Usuwanie może potrwać do 3 miesięcy

(u/KindlyConnection4420, r/DoSEO, 23 października 2026, tłumaczenie własne)

Google takiej liczby nie publikuje. Adres wypada przy kolejnej wizycie robota, a mało ważny adres na martwym hoście może na nią poczekać. Te trzy miesiące to czyjeś doświadczenie, nie reguła.

#Kiedy można po prostu poczekać

Mueller dopisał wariant, o którym łatwo zapomnieć:

Jeśli to stosunkowo nowa strona, możesz też po prostu nic nie robić i pozwolić, żeby samo się ułożyło. Jeśli adresy już nie działają, same wypadną.

(u/johnmu, r/TechSEO, 23 października 2026, tłumaczenie własne)

To pasuje, gdy stary host już zwraca 404, 410 albo błąd DNS, strona ma mało linków przychodzących, a w wynikach nie ma nic wrażliwego. Jeśli adresy ftp przez lata zbierały linki, bez 301 je stracisz. Jeśli kopia testowa pokazuje ceny albo dane osobowe, nie czekasz.

#Przekierowanie 301 ze starej subdomeny na domenę główną

Jeśli te same wpisy istnieją na domenie głównej, przekierowanie strona do strony jest lepszą naprawą niż usuwanie. Mueller podał je jako wariant:

Ewentualnie: zmień DNS tak, by wskazywał na serwer, na którym zrobisz przekierowanie 301 wszystkich adresów na www, i opcjonalnie zgłoś zmianę adresu w Search Console.

(u/johnmu, r/TechSEO, 23 października 2026, tłumaczenie własne)

Poradnik kanonizacji nazywa przekierowanie silnym sygnałem, że cel ma zostać adresem kanonicznym. Przekierowanie przenosi też linki prowadzące na zły host. Warunki w praktyce:

• Nazwa musi się rozwiązywać i mieć certyfikat ważny dla niej, inaczej robot zatrzyma się na błędzie TLS i nie zobaczy 301.
• Każdy adres kieruj na jego odpowiednik. Przekierowanie wszystkiego na stronę główną gubi sygnał na poziomie podstrony.
• Nie zdejmuj przekierowań. Poradnik przenoszenia witryny mówi o co najmniej roku, a narzędzie do zmiany adresu wymaga co najmniej 180 dni.

Według tego samego poradnika w średniej witrynie pokazanie nowych adresów zamiast starych zajmuje Google kilka tygodni lub dłużej.

#Jak zweryfikować usuniętą subdomenę w Search Console

Mueller zaczął od słów “zweryfikuj przez DNS” (tłumaczenie własne). Narzędzie do usuwania i sprawdzanie adresu działają tylko dla adresów w usłudze, której jesteś właścicielem, a host, który nic już nie serwuje, nie przyjmie pliku weryfikacyjnego HTML. Usługa domeny weryfikowana rekordem DNS (TXT albo CNAME) obejmuje wszystkie subdomeny i protokoły http, https oraz ftp. Zweryfikuj example.com jako usługę domeny, a ftp.example.com, staging.example.com i każda zapomniana subdomena znajdą się w niej, niezależnie od tego, czy stoi za nimi serwer.

Raport Strony w takiej usłudze pokazuje wszystkie hosty naraz, więc przy okazji wyłapiesz inne zabłąkane nazwy w indeksie.

#Narzędzie do usuwania dla całej subdomeny

Narzędzie do usuwania w Search Console pozwala zablokować wszystkie adresy z danym prefiksem. Wpisujesz https://ftp.example.com/ i ukrywasz cały host. Pomoc Google zaznacza, że blokada prefiksu staging nie obejmuje www ani domeny bez www. Termin działania podaje polska wersja pomocy:

Pozytywnie rozpatrzona prośba o usunięcie adresu URL jest ważna tylko przez około 6 miesięcy. Po tym czasie Twoje treści mogą wyświetlać się w wynikach wyszukiwania Google.

Według poradnika o usuwaniu stron prośba zaczyna działać w ciągu doby. Ograniczenia z tej samej strony pomocy:

• Narzędzie ukrywa wyniki, ale nie wstrzymuje indeksowania i niczego nie usuwa na stałe. Trwałe jest dopiero 404 lub 410, hasło albo noindex.
• Jeśli adres w chwili zgłoszenia zwraca 404 lub 502/503, Google uznaje stronę za usuniętą i prośba wygasa.
• Google odradza używanie narzędzia do wyboru właściwej wersji witryny, bo może ukryć wszystkie wersje adresu. Na osobnej subdomenie chroni przed tym reguła prefiksu, ale przy www kontra bez www nie próbuj.

Narzędzie ma sens, gdy złe adresy szkodzą dziś: kopia testowa z próbnymi cenami, host deweloperski z niedokończonymi podstronami, adres IP w wynikach. Przy zdublowanym blogu na ftp., który i tak dostanie 301 albo 404, wystarczy poczekać, jak opisuje sekcja o kodach 404 wyżej, bo narzędzie tylko ukrywa wyniki na pół roku.

#Co zrobić, gdy kopia strony leży na cudzej domenie

Zły host nie zawsze należy do ciebie. Kopia testowa potrafi zostać na subdomenie dawnej agencji albo firmy hostingowej i wtedy nie zweryfikujesz usługi domeny ani nie użyjesz narzędzia do usuwania. Pomoc Google kieruje w takiej sytuacji do narzędzia do zgłaszania nieaktualnych treści, przeznaczonego dla osób, które nie są właścicielami witryny. Według tej samej strony, jeśli podstrony już nie ma, wynik znika z indeksu; jeśli zniknęła tylko część treści, Google przestaje pokazywać stronę dla usuniętego fragmentu. Właściciel widzi takie prośby w osobnej karcie narzędzia.

Warunek jest jeden: kopia musi naprawdę zniknąć. Jeśli host dalej serwuje całą stronę, właściciel domeny musi ją usunąć, zahasłować albo dodać noindex. Poproś o to na piśmie, z listą adresów z testu curl i prośbą o skasowanie rekordu DNS.

Własne prośby w narzędziu do usuwania da się anulować z poziomu historii, która pokazuje bieżące i wygasłe zgłoszenia z ostatnich 6 miesięcy. Przydaje się to, gdy prefiks okazał się szerszy, niż zakładałeś.

#Czy WordPress, Shopify albo Cloudflare Pages same przekierują obcą nazwę hosta

Platformy pilnują zwykle jednego duplikatu, a resztę zostawiają tobie.

WordPress przekierowuje wyłącznie między www a wersją bez www. W kodzie funkcji redirect_canonical() stoi komentarz “Only redirect no-www <=> yes-www”, a dla każdej innej nazwy funkcja zostawia host z żądania. Wejście na ftp.example.com zwraca stronę, nie przekierowanie. Sam tag canonical pochodzi z wp_get_canonical_url(), która wywołuje get_permalink(), więc trzyma się adresu witryny z ustawień. Jeśli kopia na WordPressie wskazuje jako kanoniczny host ftp, szukaj w wp-config.php stałych WP_HOME albo WP_SITEURL składanych z $_SERVER['HTTP_HOST'] albo wtyczki, która nadpisuje canonical. Opcja widoczności dla wyszukiwarek w ustawieniach czytania od WordPressa 5.3 wstawia metatag noindex zamiast Disallow: / w robots.txt, jak opisuje notatka zespołu core. Ta sama notatka wskazuje nagłówek HTTP jako najskuteczniejszy sposób na trzymanie wersji deweloperskich poza indeksem.

Shopify pozwala wybrać domenę, którą widzą klienci, i przekierować na nią wszystkie pozostałe na stronie domen w panelu. Dodatkowa domena albo subdomena bez tego ustawienia to zdublowany host.

Cloudflare Pages dodaje domyślnie nagłówek X-Robots-Tag: noindex do każdego wdrożenia podglądowego. Adres produkcyjny <projekt>.pages.dev to osobny host, a instrukcja Cloudflare o przekierowaniu pages.dev na własną domenę używa reguły Bulk Redirect z kodem 301 i opcjami zachowania ścieżki, czyli dokładnie przekierowania strona do strony.

Astro buduje adresy kanoniczne i mapę witryny z opcji site w astro.config.mjs. Next.js skleja względne adresy w metadanych, w tym alternates.canonical, z metadataBase, a względny adres bez metadataBase kończy się błędem builda. W obu przypadkach na sztywno wpisany adres produkcyjny sprawia, że każda kopia wskazuje produkcję.

#Dlaczego robots.txt na starym hoście tylko szkodzi

Disallow: / na hoście testowym działa odwrotnie, niż się wydaje. Dokumentacja noindex mówi, że strona zablokowana w robots.txt nie zostanie pobrana, więc robot nie zobaczy jej reguły noindex, a strona może dalej pojawiać się w wynikach. Poradnik kanonizacji dodaje, że Google może zaindeksować zablokowane adresy bez treści. Obie strony Google o usuwaniu wymieniają robots.txt jako metodę, której nie należy używać. Zostaw host dostępny, dopóki robot nie odczyta 301, 404 albo noindex.

#Jak zaindeksować adresy z domeny głównej

Usunięcie złego hosta samo nie zaindeksuje właściwego. Adresy na www u autora wątku nie miały mapy witryny ani stron odsyłających, więc Google nie miał powodu ich pobierać. Popraw sygnały na stronie produkcyjnej:

• Generuj canonical ze skonfigurowanego adresu bazowego, żeby strony na www deklarowały www bez względu na to, która nazwa je obsłużyła.
• Umieść adresy z domeny głównej w mapie witryny zgłoszonej w usłudze produkcyjnej. Google nazywa to słabym sygnałem, ale sygnały się sumują.
• Sprawdź, czy linki wewnętrzne, hreflang i adresy Open Graph używają hosta głównego.
• Zrób test na żywo kilku adresów z www w Search Console i poproś o zaindeksowanie najważniejszych.

Poradnik kanonizacji mówi, że metody działają mocniej, gdy się je łączy. Przekierowanie ze starego hosta, poprawny canonical na nowym i mapa witryny to zestaw docelowy. Jeśli zły host pojawił się po zmianie platformy, mapę przekierowań opisują moja usługa migracji i artykuł o tym, dlaczego Google cofa migracje domeny. Raport Strony, na którym śledzisz postęp, wyjaśnia przewodnik po GSC i Indexing API.

#Statusy w raporcie Strony: co oznaczają przy sprzątaniu

Raport indeksowania stron w usłudze domeny pokazuje oba hosty obok siebie. Nazwy i znaczenie statusów pochodzą z dokumentacji raportu:

Ta sama strona dokumentacji zaznacza, że test na żywo w narzędziu do sprawdzania adresu podąża za przekierowaniami i testuje adres docelowy, nie informując o tym. Test starego adresu ftp pokaże więc wynik dla www i może wyglądać tak, jakby przekierowanie nic nie zmieniło.

#Którą naprawę wybrać: tabela decyzji

#Jak nie dopuścić do indeksowania hostów testowych

• Hasło na każdym hoście poza produkcją. Poradnik o kontroli udostępnianych treści mówi, że ochrona hasłem trzyma treść poza wyszukiwarką, a jeśli już się w niej pojawiła, z czasem ją usuwa. Uwierzytelnianie HTTP na serwerze lub w CDN działa na każdej platformie.
• Nagłówek X-Robots-Tag: noindex na hostach testowych. Specyfikacja X-Robots-Tag pozwala wysłać regułę w nagłówku HTTP, więc obejmuje też PDF-y i obrazy. Ustaw go w konfiguracji serwera dla danej nazwy, nie w aplikacji, żeby kopia bazy z testów na produkcję go nie przeniosła.
• Usuwaj rekord DNS razem z hostem. CNAME wskazujący na usługę, z której już nie korzystasz, to klasyczny scenariusz przejęcia subdomeny: MDN opisuje, jak ktoś zakłada porzuconą nazwę u dostawcy i publikuje pod twoją subdomeną własne treści.
• Unikaj rekordu wildcard, jeśli go nie potrzebujesz. Dokumentacja Cloudflare wyjaśnia, że * odpowiada za każdą nazwę bez własnego rekordu. Razem z domyślnym hostem wirtualnym każda literówka w subdomenie serwuje twoją stronę.
• Domyślny host wirtualny powinien odrzucać nieznane nazwy. nginx kieruje żądanie, którego nagłówek Host nie pasuje do żadnego server_name, do serwera domyślnego dla danego portu, czyli pierwszego bloku, o ile żaden nie ma default_server; tak opisuje to dokumentacja przetwarzania żądań. Apache robi to samo z pierwszym hostem wirtualnym na liście, według dokumentacji hostów nazwowych.

Przykładowa konfiguracja nginx: nieznane nazwy dostają zamknięte połączenie, a host testowy hasło i noindex.

server {
    listen 80 default_server;
    listen 443 ssl default_server;
    ssl_reject_handshake on;   # nginx 1.19.4+, odrzuca TLS dla nieznanych nazw
    return 444;                # zamyka połączenie bez odpowiedzi
}

server {
    listen 443 ssl;
    server_name staging.example.com;
    # tu ssl_certificate i ssl_certificate_key dla tej nazwy
    auth_basic "Staging";
    auth_basic_user_file /etc/nginx/.htpasswd;
    add_header X-Robots-Tag "noindex" always;
}

Parametr always jest kluczowy. Dokumentacja modułu nagłówków mówi, że bez niego add_header działa tylko dla odpowiedzi 200, 201, 204, 206, 301, 302, 303, 304, 307 i 308, więc odpowiedź 401 z uwierzytelniania wyszłaby bez noindex. ssl_reject_handshake wymaga nginx 1.19.4 lub nowszego, a kod 444 to niestandardowy sposób nginx na zamknięcie połączenia.

Konfigurację serwera dla hasła i nagłówka noindex pokazuje mój przewodnik po środowisku testowym. Sprawdzenie strony obejmuje przegląd rekordów DNS i zaindeksowanych hostów, a stałe utrzymanie pilnuje tej listy po każdej zmianie serwera albo agencji.