Duplikacja po migracji, kopiach testowych i zmianie CMS – jak nie wpuścić do indeksu roboczych wersji serwisu

Publiczny staging nie jest już środowiskiem testowym. Jest drugim serwisem — tyle że zwykle z roboczymi treściami, błędnymi danymi, niedokończonym formularzem i adresem, którego nikt nie chciał pokazywać klientom.

Problem zaczyna się, gdy ta sama zawartość odpowiada kodem 200 OK pod kilkoma hostami, na przykład:

• www.example.pl,
• staging.example.pl,
• nowa.example.pl,
• old.example.pl,
• starą domeną sprzed migracji,
• technicznym adresem udostępnionym przez wykonawcę.

Google grupuje bardzo podobne strony i wybiera spośród nich wersję kanoniczną. Nie zawsze wybierze tę, którą właściciel serwisu uznaje za produkcyjną. Skutkiem nie musi być klasyczna „kara za duplicate content”. Znacznie częściej pojawiają się: niewłaściwy adres w wynikach, rozproszone sygnały, nieczytelne raporty, marnowanie zasobów na indeksowanie kopii oraz publiczne ujawnienie treści przed premierą.

Najbardziej kosztowne przypadki nie wynikają z zaawansowanej technologii. Zwykle wystarcza jedna niezabezpieczona subdomena, stara mapa XML albo kopia WordPressa, w której nikt nie sprawdził ustawień po przeniesieniu bazy.

Skąd Google bierze adresy stagingu i starych wersji serwisu

Google nie musi „zgadywać” adresu środowiska testowego. W większości przypadków adres zostaje mu podany — przez konfigurację serwisu, mapę witryny, link albo jeden z elementów skopiowanych ze starego CMS-a.

Najczęstsze drogi prowadzące roboczą wersję do indeksu to:

• link ze strony produkcyjnej do stagingu, pozostawiony w menu, stopce, banerze, skrypcie JavaScript albo treści wpisu;
• mapa XML wygenerowana z błędnym adresem bazowym, zawierająca tysiące adresów staging.example.pl;
• błędne oznaczenia rel="canonical" lub hreflang, które wskazują na środowisko testowe;
• odwołania do stagingu w danych strukturalnych, plikach CSS, formularzach, źródłach obrazów albo metadanych og:url;
• publicznie udostępniony adres wersji preview, umieszczony później w dokumencie, zgłoszeniu błędu, repozytorium lub na stronie wykonawcy;
• stara domena, która po migracji nadal zwraca pełne strony z kodem 200, zamiast przekierowywać użytkowników do nowego serwisu;
• kopia bazy CMS-a zachowująca stare adresy domen, ustawienia wtyczek SEO, mapy witryny oraz linki bezwzględne.

Sitemapy i zwykłe linki są podstawowymi sposobami przekazywania robotom informacji o nowych adresach. Sam fakt, że staging nie znajduje się w głównym menu, nie czyni go niewidocznym.

Szczególnie zdradliwy jest scenariusz po zmianie CMS-a. Nowa strona działa już pod właściwą domeną, ale wcześniejszy system pozostaje dostępny jako old.example.pl albo pod technicznym adresem hostingu. Oba serwisy mają ten sam katalog produktów, identyczne opisy i te same artykuły. Nowy CMS tworzy własne mapy XML, a stary nadal publikuje stare. Z punktu widzenia wyszukiwarki są to dwa działające serwisy, nie „archiwum techniczne”.

Kopia dostępna bez logowania i zwracająca kod 200 jest publiczną stroną. Nazwanie jej „dev”, „beta” czy „wersja robocza” nie zmienia sposobu działania protokołu HTTP.

Najgorszym zabezpieczeniem jest samotny wpis:

User-agent: *
Disallow: /

Plik robots.txt steruje crawlowaniem, a nie skutecznie blokuje indeksowanie stron HTML. Jeżeli inne źródło wskazuje dany URL, Google może umieścić sam adres w wynikach nawet bez pobrania jego zawartości. Wynik może być pozbawiony opisu, ale nadal będzie widoczny.

Jeszcze gorsze jest połączenie Disallow: / z tagiem noindex. Robot nie może pobrać strony, więc nie odczyta dyrektywy noindex. Google wprost zaznacza, że noindex działa dopiero po ponownym odwiedzeniu dostępnej strony. Zablokowanie jej w robots.txt może więc opóźnić albo uniemożliwić odczyt sygnału usunięcia.

Adres kanoniczny również nie jest zamkiem na drzwi. Przekierowanie oraz rel="canonical" są silnymi sygnałami kanonikalizacji, a obecność URL-a w mapie witryny — sygnałem słabszym. Google może jednak samodzielnie wybrać inną stronę kanoniczną. Co więcej, canonical ma sens przede wszystkim wtedy, gdy strony są identyczne lub bardzo podobne. Jeśli wersja robocza ma inne nagłówki, brakujące produkty, testowe ceny i zmienioną strukturę, wskazanie produkcji jako canonical nie daje pewności, że staging zniknie z indeksu.

W praktyce przed wdrożeniem trzeba zinwentaryzować nie tylko główną domenę, lecz także:

• wszystkie subdomeny dev, test, stage, staging, beta, new, old, preview i v2;
• domeny techniczne udostępnione przez hosting lub wykonawcę;
• wcześniejsze domeny marki;
• tymczasowe adresy używane podczas akceptacji projektu;
• publiczne adresy przypisane do starych serwerów i poprzedniego CMS-a.

Lista powinna pochodzić z DNS, panelu hostingu, konfiguracji CDN, pipeline’u wdrożeniowego i dokumentacji projektu. Sprawdzenie wyłącznie adresów, które pamięta dział marketingu, zazwyczaj nie wystarcza.

Jak rozpoznać duplikację w Google Search Console i wynikach wyszukiwania

Pierwszy test jest prosty: należy wyszukać każdy znany host osobno.

site:staging.example.pl
site:old.example.pl
site:stara-domena.pl
site:example.pl "fragment roboczego nagłówka"

Dobrze działają też zapytania zawierające dokładne zdanie z wersji testowej, tymczasowy tytuł produktu, nazwę kampanii przed premierą albo tekst typu „Lorem ipsum” czy „Strona w budowie”.

Operator site: jest jednak tylko czujnikiem dymu. Google zaznacza, że nie musi on zwracać wszystkich zaindeksowanych adresów, a kolejność wyników bez dodatkowego zapytania jest w dużej mierze przypadkowa. Brak wyników dla site:staging.example.pl nie jest więc dowodem, że staging nigdy nie trafił do indeksu.

Dokładniejsza kontrola zaczyna się w Google Search Console. Dla głównej domeny najlepiej mieć zweryfikowaną usługę typu domena, obejmującą protokoły i subdomeny. Nie pokaże ona jednak stagingu działającego pod niezależną domeną agencji lub dostawcy. Taki adres trzeba zweryfikować jako osobną usługę albo uzyskać do niej dostęp od właściciela.

W raporcie Indeksowanie stron szczególnej uwagi wymagają następujące komunikaty:

• „Duplikat, użytkownik nie wybrał strony kanonicznej” — Google wykrył podobne strony, ale nie otrzymał spójnego wskazania, która wersja ma być główna.
• „Duplikat, Google wybrał inną stronę kanoniczną niż użytkownik” — deklarowany canonical przegrywa z innymi sygnałami. Trzeba porównać przekierowania, linkowanie wewnętrzne, mapy XML i zawartość stron.
• „Strona alternatywna z prawidłowym tagiem strony kanonicznej” — konsolidacja prawdopodobnie działa, ale w przypadku stagingu nie rozwiązuje problemu publicznego dostępu.
• „Zablokowano przez plik robots.txt” — nie oznacza, że adres został skutecznie usunięty z wyników.
• „Wykluczono przez tag noindex” — dyrektywa została odczytana, ale strona nadal pozostaje publicznie dostępna dla użytkowników znających adres.
• „Strona z przekierowaniem” — na starej domenie jest to zwykle prawidłowy stan, o ile przekierowanie prowadzi bezpośrednio do właściwego odpowiednika.
• „Soft 404” — serwer zwraca kod 200, ale zawartość wygląda jak komunikat o braku strony. Często pojawia się po masowym przekierowaniu nieistniejących adresów na stronę główną.

Dla kilku reprezentatywnych adresów należy uruchomić Sprawdzanie adresu URL i porównać:

• canonical zadeklarowany przez właściciela,
• canonical wybrany przez Google,
• datę ostatniego pobrania,
• kod odpowiedzi,
• informację, czy indeksowanie jest dozwolone,
• HTML otrzymany przez Googlebota.

Jeśli Google jako canonical dla produkcyjnego produktu wskazuje staging.example.pl/produkt-x, problem nie znajduje się wyłącznie w jednym tagu. Zazwyczaj kilka sygnałów jednocześnie prowadzi do stagingu: linki wewnętrzne, sitemap, przekierowania albo większa kompletność treści na kopii niż na produkcji. Pole „canonical wybrany przez Google” jest dostępne właśnie w narzędziu sprawdzania adresu.

W raporcie skuteczności trzeba przefiltrować lub wyeksportować adresy stron i wyszukać nazwy hostów oraz charakterystyczne fragmenty, takie jak staging, test, preview, old czy domena poprzedniego wykonawcy. Pojawienie się wyświetleń dla roboczej subdomeny oznacza, że jej URL był już prezentowany użytkownikom, nawet jeżeli nikt jeszcze nie odnotował kliknięcia.

Drugim źródłem są logi serwera. Pokazują, czy Googlebot nadal odpytuje stare hosty, jakie kody odpowiedzi otrzymuje oraz czy po migracji trafia na łańcuchy przekierowań, błędy 404 albo strony odpowiadające kodem 200. Google zaleca monitorowanie zarówno starego, jak i nowego serwisu oraz analizę logów pod kątem aktywności crawlerów i nieoczekiwanych kodów odpowiedzi.

Nie każdy stary URL widoczny w Google oznacza awarię. Po poprawnym wdrożeniu adres może przez pewien czas pozostać w wynikach lub raportach, mimo że zwraca trwałe przekierowanie. Google podaje, że przeniesienie większości stron małego lub średniego serwisu może zająć kilka tygodni; duże portale są przetwarzane dłużej.

Priorytety reakcji powinny wyglądać następująco:

1. Priorytet krytyczny: staging znajduje się w wynikach lub otrzymuje wyświetlenia, jest dostępny bez logowania i odpowiada kodem 200.
2. Priorytet wysoki: stara domena nadal publikuje pełną kopię serwisu albo Google wybiera ją jako canonical.
3. Priorytet średni: stare adresy zwracają prawidłowe przekierowania, ale w serwisie pozostały stare linki, mapy XML lub łańcuchy przekierowań.
4. Monitoring: Search Console pokazuje stare URL-e jako strony z przekierowaniem lub prawidłowe alternatywy kanoniczne, a żaden roboczy host nie jest dostępny publicznie.

Jak zamknąć kopie robocze przed publikacją i posprzątać po wdrożeniu

Kolejność działań ma znaczenie. Najpierw ogranicza się dostęp, później porządkuje sygnały indeksowania, a na końcu przyspiesza usunięcie adresów z wyników. Zaczynanie od robots.txt jest odwróceniem tej kolejności.

1. Aktywny staging trzeba zamknąć mechanizmem dostępu

Domyślnym rozwiązaniem powinno być jedno z poniższych:

• HTTP Basic Authentication na serwerze lub reverse proxy;
• firmowe SSO;
• bramka dostępu, na przykład Cloudflare Access;
• VPN;
• allowlista adresów IP;
• prywatny host dostępny wyłącznie z sieci wewnętrznej.

Google wskazuje ochronę hasłem jako sposób na zapobieganie pojawianiu się treści w wynikach. Nginx udostępnia w tym celu dyrektywy auth_basic i auth_basic_user_file, a Cloudflare Access pozwala dodać warstwę uwierzytelnienia przed aplikacją działającą pod publicznym hostem.

Takie zabezpieczenie irytuje podczas testów. Trzeba się logować, automaty QA wymagają konta technicznego, a webhooki lub zewnętrzne integracje mogą przestać działać. To realna niedogodność, ale rozwiązaniem są tokeny serwisowe, osobne reguły dla integracji albo kontrolowana allowlista — nie całkowite otwarcie serwisu.

Jeżeli staging zawiera kopię zamówień, klientów lub danych formularzy, publiczny dostęp przestaje być wyłącznie problemem SEO. Taki przypadek powinien zostać od razu przekazany zespołowi bezpieczeństwa i osobom odpowiedzialnym za ochronę danych.

2. Noindex powinien być dodatkową barierą, nie jedynym zabezpieczeniem

Na środowisku testowym dobrze ustawić globalny nagłówek:

X-Robots-Tag: noindex

Najlepiej generować go na poziomie serwera, reverse proxy albo CDN, niezależnie od szablonu CMS-a. Dzięki temu ochrona obejmuje nie tylko strony HTML, lecz także dokumenty PDF i inne zasoby, dla których nie da się dodać tagu w sekcji <head>. Google traktuje noindex w metatagu i nagłówku HTTP jako równoważne mechanizmy.

Schemat powinien być dwuwarstwowy:

• uwierzytelnienie blokuje dostęp do treści;
• X-Robots-Tag: noindex chroni środowisko, gdy reguła dostępu zostanie omyłkowo wyłączona.

Nie należy jednocześnie polegać na noindex i blokować całego stagingu w robots.txt. Gdy robot nie może pobrać strony, nie odczyta nagłówka ani metatagu.

W WordPressie ustawienie „Proś wyszukiwarki o nieindeksowanie tej witryny” generuje dyrektywę dla robotów, ale oficjalna dokumentacja wyraźnie zaznacza, że nie blokuje dostępu do serwisu. Dodatkowo w niestandardowym motywie działanie zależy od prawidłowego użycia mechanizmów nagłówka. Checkbox jest więc zabezpieczeniem pomocniczym, a nie substytutem hasła.

Ten sam checkbox ma jeszcze drugą, nieprzyjemną cechę: po skopiowaniu bazy może pozostać aktywny na produkcji. Dlatego wdrożenie powinno zostać automatycznie zatrzymane, jeśli produkcyjny HTML albo nagłówki zawierają noindex.

3. Wdrożenie powinno mieć twarde testy blokujące publikację

Minimalny test anonimowego dostępu do stagingu:

curl -sI https://staging.example.pl/ \
  | grep -Ei 'HTTP/|location:|x-robots-tag:'

Oczekiwany wynik to:

• 401 Unauthorized,
• 403 Forbidden,
• albo przekierowanie do bramki logowania.

Niepożądany wynik to anonimowe 200 OK z pełną zawartością strony.

Produkcję trzeba sprawdzić osobno:

curl -sI https://www.example.pl/ | grep -i 'x-robots-tag'
curl -s https://www.example.pl/ | grep -Ei 'noindex|staging\.example\.pl|old\.example\.pl'

Oba polecenia powinny nie zwrócić niczego, chyba że analizowany serwis świadomie wyklucza konkretny zasób.

Dla starej domeny:

curl -sI https://stara-domena.pl/oferta \
  | grep -Ei 'HTTP/|location:'

Prawidłowy wynik to 301 lub 308 prowadzący bezpośrednio do odpowiadającej strony w nowym serwisie.

Test należy wykonać przynajmniej dla:

• strony głównej,
• jednej strony kategorii,
• jednego produktu lub usługi,
• artykułu,
• paginacji,
• strony z parametrami,
• dokumentu PDF,
• adresu, który został usunięty,
• adresu wymagającego przekierowania.

W większym serwisie ręczne sprawdzenie kilku URL-i nie wystarczy. Pipeline powinien przetestować całą mapę przekierowań oraz reprezentanta każdego szablonu.

4. Przed publikacją trzeba usunąć wszystkie odwołania do hostów roboczych

Kontrola nie może ograniczać się do rel="canonical". Trzeba przeszukać:

• linki wewnętrzne,
• canonicale,
• oznaczenia hreflang,
• mapy XML,
• dane strukturalne, zwłaszcza pola url, @id, image i logo,
• formularze i ich adresy docelowe,
• metadane społecznościowe,
• odwołania do obrazów i dokumentów,
• konfigurację API,
• pliki JavaScript,
• przekierowania po logowaniu i zakupie,
• wiadomości transakcyjne generowane przez CMS.

W serwisach headless i aplikacjach renderowanych przez JavaScript trzeba porównać źródłowy HTML z wersją po renderowaniu. Google zaleca umieszczanie canonicala w źródle HTML i unikanie sytuacji, w której JavaScript zastępuje go innym adresem.

Najczęstszy błąd to jedna zmienna środowiskowa typu BASE_URL, używana przez mapy XML, canonicale, API i linki w szablonie. Jeżeli po wdrożeniu pozostanie ustawiona na staging, jeden błąd rozlewa się na cały serwis.

5. Stara domena wymaga przekierowań, nie noindex

Jeżeli stary adres ma bezpośredni odpowiednik, powinien zwracać trwałe przekierowanie 301 lub 308. Google zaleca utrzymywanie przekierowań możliwie długo, generalnie co najmniej przez rok. Z perspektywy użytkowników i istniejących linków często rozsądne jest pozostawienie ich bezterminowo.

Przekierowanie powinno prowadzić prosto do miejsca docelowego. Googlebot potrafi obsłużyć do 10 kolejnych przekierowań, ale rekomendowane są trasy bezpośrednie; gdy nie da się ich uniknąć, najlepiej nie przekraczać trzech i pozostać poniżej pięciu. Każdy dodatkowy skok wydłuża odpowiedź również dla użytkownika.

Nie wolno automatycznie kierować wszystkich starych podstron na stronę główną. Jeżeli nie istnieje sensowny odpowiednik, właściwą odpowiedzią jest 404 albo 410. Masowe, niepowiązane przekierowania mogą zostać potraktowane jako soft 404.

6. Gdy staging już trafił do indeksu, trzeba działać w tej kolejności

1. Natychmiast ograniczyć dostęp. Jeżeli środowisko nadal jest potrzebne, należy założyć uwierzytelnienie. Jeżeli zostało wycofane, powinno zwracać 301, 404 lub 410 — zależnie od tego, czy istnieje odpowiednik.
2. Usunąć wszystkie linki do stagingu z produkcji, sitemap, canonicali, hreflang, danych strukturalnych i dokumentacji publicznej.
3. Zweryfikować staging jako usługę w Search Console.
4. Skorzystać z narzędzia Usunięcia, wybierając konkretny URL albo wszystkie adresy rozpoczynające się od prefiksu stagingu.
5. Utrzymać docelowy mechanizm usunięcia: hasło, noindex, 301, 404 albo 410.
6. Monitorować wyniki, Search Console i logi aż do zaniku wyświetleń roboczego hosta.

Wniosek w narzędziu Usunięcia jest zwykle przetwarzany w ciągu jednego dnia i może objąć cały prefiks. Usunięcie https://staging.example.pl/ nie blokuje głównego https://example.pl/. Jest to jednak tylko tymczasowe ukrycie na około sześć miesięcy. Bez trwałego zabezpieczenia adres może wrócić do wyników.

Narzędzia nie należy używać do „wybierania” właściwej wersji kanonicznej ani jako standardowego elementu migracji starej domeny. Może ukryć więcej wariantów, niż zakładał administrator, a po wygaśnięciu wniosku problem wróci.

Jeżeli zawartość stagingu jest poufna, nie należy ponownie otwierać jej dla robotów tylko po to, aby Google odczytał noindex. Bezpieczniejsza ścieżka to uwierzytelnienie oraz tymczasowe usunięcie w Search Console. Gdy problem ma wyłącznie charakter SEO, a treść nie jest wrażliwa, można udostępnić crawlerowi stronę z noindex, ale trzeba liczyć się z tym, że ponowne odwiedzenie mało istotnego URL-a może zająć nawet kilka miesięcy.

Reguła wyboru rozwiązania jest prosta:

• aktywny staging: uwierzytelnienie plus X-Robots-Tag: noindex jako zabezpieczenie awaryjne;
• wycofany staging z odpowiednikami: przekierowania 301 lub 308;
• wycofana kopia bez odpowiedników: 404 lub 410;
• publiczne duplikaty potrzebne biznesowo: spójna kanonikalizacja, linkowanie i mapy witryny;
• adres już widoczny w Google: narzędzie Usunięcia plus jeden z mechanizmów trwałych.

FAQ: staging, stare domeny i kopie serwisu w indeksie

Czy samo Disallow: / w pliku robots.txt wystarczy do ochrony stagingu?
Nie. Może zatrzymać crawling, ale nie gwarantuje usunięcia adresu z wyników. Google może pokazać sam URL bez opisu. Staging należy zabezpieczyć hasłem, SSO, VPN-em albo kontrolą adresów IP.

Czy można jednocześnie ustawić Disallow: / i noindex?
Nie należy opierać na tym ochrony strony HTML. Blokada w robots.txt uniemożliwia robotowi pobranie strony i odczytanie noindex. Jeżeli potrzebne jest usunięcie za pomocą noindex, URL musi być dostępny dla crawlera.

Czy canonical ze stagingu do produkcji rozwiązuje problem?
Nie w pełni. Canonical jest silnym sygnałem, ale nie blokuje dostępu i nie gwarantuje wyboru wskazanego adresu. Przy aktywnym stagingu podstawą powinno być uwierzytelnienie.

Jak szybko staging zniknie z Google po dodaniu noindex?
Dopiero po ponownym odwiedzeniu adresu przez Googlebota. Może to potrwać od kilku dni do wielu tygodni, a dla rzadko crawlowanych stron nawet kilka miesięcy. W pilnych przypadkach trzeba równolegle użyć narzędzia Usunięcia.

Czy po migracji należy usuwać starą domenę narzędziem Usunięcia?
Nie jako standardowe działanie. Jeżeli stare URL-e mają odpowiedniki, powinny zwracać 301 lub 308. Narzędzie Usunięcia nie zastępuje przekierowań i nie służy do przenoszenia sygnałów między domenami.

Co zrobić ze starą stroną, dla której nie ma odpowiednika?
Zwrócić 404 lub 410. Przekierowanie kilkuset niepowiązanych adresów na stronę główną nie pomaga użytkownikom i może zostać rozpoznane jako soft 404.

Co z kopią działającą pod domeną agencji lub wykonawcy?
Główna usługa domenowa w Search Console jej nie obejmie. Trzeba uzyskać dostęp do osobnej usługi, zażądać zamknięcia kopii i potwierdzić kod odpowiedzi samodzielnie. Usunięcie linków z własnej strony nie wystarczy, jeżeli kopia nadal odpowiada kodem 200.

Czy duplikacja stagingu zawsze powoduje karę algorytmiczną?
Nie należy sprowadzać problemu do „kary”. Google grupuje podobne strony i wybiera wersję kanoniczną. Ryzykiem jest wybór złego hosta, ujawnienie treści roboczych, niepotrzebne crawlingowanie kopii oraz utrata kontroli nad tym, który URL pojawia się w wynikach.

Od czego zacząć kontrolę serwisu?
Spisz wszystkie domeny i subdomeny używane w projekcie, a następnie wykonaj anonimowe żądanie curl -I do każdej z nich. Najpierw napraw host, który zwraca 200 OK z pełną kopią serwisu bez logowania. Dopiero później zajmuj się canonicalami, raportami i przyspieszaniem usunięcia z indeksu.