W dokumentacji Google o przenoszeniu witryny ze zmianą adresów pierwszy punkt listy typowych błędów każe usunąć blokady z robots.txt i reguły noindex, które były potrzebne tylko na czas prac, a w części o rozwiązywaniu problemów Google pisze, że często widzi przekierowania prowadzące do nieistniejących adresów na nowej stronie. Oba błędy są w kodzie i powstają po stronie zespołu, który wdraża sklep.
Programista kontroluje w sklepie to, co robot Google w ogóle dostaje: kody odpowiedzi, linki, wyrenderowaną treść, dane produktowe i mapę witryny. Poniższa lista idzie w tej kolejności i każdy punkt opiera się na aktualnej dokumentacji Google albo platformy sklepowej. Warto ją przejść na środowisku testowym, zanim sklep zobaczy pierwszego klienta, bo po starcie każda poprawka czeka na ponowne odwiedziny robota.
Środowisko testowe i dzień startu
Google zaleca chronić hasłem treści, które nie mają trafić do wyników, a w dokumencie o uruchamianiu sklepu internetowego podaje hasło jako sposób, żeby zablokować Google i jednocześnie wpuścić testerów. Plik robots.txt do tego nie służy: według dokumentacji ogranicza obciążenie serwera, a adres zablokowany w robots.txt może się mimo to pojawić w wynikach, tylko bez opisu, jeśli prowadzą do niego linki z innych stron. Reguła noindex z kolei nie zadziała na stronie zablokowanej w robots.txt, bo robot jej nie przeczyta, a wpisanie noindex do samego pliku robots.txt Google nie obsługuje.
Przed przełączeniem domeny sprawdź kilka rzeczy, które dokumentacja wymienia osobno:
- gotową wersję robots.txt dla produkcji, przygotowaną zawczasu, a nie pisaną w dniu startu,
- brak reguł noindex, także w komponentach, bo Google respektuje meta robots również w sekcji body, a przy sprzecznych regułach stosuje bardziej tę restrykcyjną,
- brak noindex w kodzie źródłowym stron, które mają trafić do indeksu, bo po napotkaniu noindex Google może pominąć renderowanie i usunięcie tej reguły skryptem może nie zadziałać,
- bezwzględne adresy w rel=canonical, bo według Google względne mogą na dłuższą metę sprawiać kłopoty, na przykład gdy robot przypadkiem odwiedzi serwis testowy.
Hasło ma jeden skutek uboczny dla testów. Test wyników z elementami rozszerzonymi nie wejdzie na stronę chronioną hasłem ani za zaporę, więc na środowisku testowym wkleja się do niego kod zamiast adresu.
Adresy, przekierowania i kody odpowiedzi
Jeśli po wdrożeniu digitalk albo inna agencja przejmuje pozycjonowanie sklepu, potrzebuje od programisty listy starych i nowych adresów, bo bez niej nie da się sprawdzić, które przekierowania prowadzą donikąd. Google zaleca stałe przekierowania po stronie serwera, 301 albo 308, a przekierowanie 302 traktuje jako słaby sygnał, że docelowy adres powinien przejąć miejsce starego. Robot przejdzie do dziesięciu kroków w łańcuchu przekierowań, ale dokumentacja radzi kierować od razu do celu, a jeśli się nie da, ograniczyć łańcuch do kilku kroków.
Masowe przekierowanie starych produktów na stronę główną nie jest wyjściem awaryjnym. Google pisze, że wiele starych adresów skierowanych na jeden niezwiązany adres, na przykład na stronę główną nowego serwisu, może zostać potraktowane jako miękki błąd 404. Strona usunięta bez zamiennika powinna zwracać 404 albo 410, a przekierowania na nowe adresy trzeba utrzymać jak najdłużej, według dokumentacji z reguły co najmniej rok.
Platformy sklepowe robią część tej pracy same, i każda inaczej. WordPress ma funkcję przekierowującą stare adresy wpisów na nowe, Shoper opisuje automatyczne przekierowanie przy zmianie przyjaznego adresu, choć dwa jego artykuły pomocy różnią się co do kolejnej zmiany, a IdoSell przekierowuje sam adresy tworzone z nazwy produktu, ale nie te ustawione ręcznie. Zamiast zakładać, jak zachowa się platforma, zmień adres jednego produktu na środowisku testowym dwa razy i sprawdź odpowiedź serwera po każdej zmianie. Dokumentacja Google radzi też zmieniać domenę, system i wygląd po kolei.
Canonical, paginacja i filtry
Adres kanoniczny ustawia się jedną metodą: w elemencie „link” w sekcji head albo w nagłówku HTTP. W mapie witryny nie wskazuje się przy tym innego adresu niż w rel=canonical. Od grudnia 2025 roku dokumentacja o JavaScripcie dodaje, że canonical najlepiej podać w kodzie źródłowym i nie zmieniać go skryptem, a jeśli w kodzie się nie da, to ustawić go tylko skryptem. Wariant produktu z własnym adresem dostaje canonical wskazujący stronę produktu.
Przy listach produktów kusi canonical z każdej kolejnej strony na pierwszą. Google pisze, że to niewłaściwe użycie, i zaleca, żeby każda strona listy miała własny adres kanoniczny, na przykład z parametrem ?page=n. Fragmentu adresu po znaku # Google nie bierze pod uwagę. Elementów „link” z atrybutami next i prev Google już nie używa, więc kolejne strony muszą być połączone zwykłymi linkami, a przycisk „pokaż więcej” bez linku zostaje dla robota zamknięty, bo ten nie klika i zwykle nie uruchamia funkcji wymagających działania użytkownika.
Filtry to osobna decyzja projektowa. Dokumentacja o nawigacji fasetowej daje dwie drogi: jeśli adresy filtrów nie muszą trafiać do indeksu, zablokować ich skanowanie, a jeśli muszą, trzymać się kilku reguł. Parametry oddziela się znakiem &, bo przecinek, średnik czy nawiasy robot gorzej rozpoznaje jako separatory, a kombinacja filtrów bez wyników, z powtórzonym filtrem albo nieistniejącą stroną listy powinna zwracać 404.
JavaScript i to, co widzi robot
Sklep, który buduje strony skryptem w przeglądarce, Google przetwarza w trzech etapach: skanuje, renderuje i indeksuje. Do drugiego etapu trafiają strony z kodem 200, a przy innym kodzie, na przykład na stronie błędu, Google może go pominąć. Choć radzi sobie z JavaScriptem, wciąż zaleca przygotowanie gotowego HTML po stronie serwera albo z wyprzedzeniem, bo strona działa wtedy szybciej, a nie każdy robot uruchamia skrypty.
- Linki robot znajduje tylko w znacznikach <a> z atrybutem href, czyli w zwykłych linkach HTML. Dokumentacja wymienia jako niezalecane między innymi routerLink bez href, element span z atrybutem href oraz wywołania w onclick albo w href zaczynającym się od javascript:.
- Aplikacja jednostronicowa bez osobnych odpowiedzi serwera łatwo produkuje miękkie 404. Google dopuszcza dwa wzorce: przekierowanie skryptem na adres, dla którego serwer zwraca 404, albo dodanie reguły noindex do strony błędu.
- Robot pobiera pierwsze 2 MB pliku HTML, a każdy zasób, na przykład skrypt czy arkusz stylów, osobno, z tym samym limitem.
- Google zapamiętuje pobrane pliki JavaScript i CSS na dłużej, niż wynikałoby z nagłówków ustawionych na serwerze, więc po wdrożeniu nowej wersji może przez jakiś czas renderować stronę ze starymi plikami. Chroni przed tym dodawanie do nazw plików odcisku wersji, na przykład main.2bb85551.js, bo każda zmiana daje nowy adres, który robot musi pobrać od nowa.
- Pliki JavaScript zablokowane w robots.txt nie zostaną uruchomione, więc Google nie zobaczy treści, którą generują.
Wyrenderowany kod pokaże narzędzie do sprawdzania adresów URL w Search Console albo test wyników z elementami rozszerzonymi. Google pisze, że widzi tylko treść obecną w wyrenderowanym HTML, więc nazwa produktu, cena i opis muszą być w wyrenderowanym kodzie od razu, bez klikania w zakładkę.
Dane produktowe i mapa witryny
Strona produktu, na której da się kupić, kwalifikuje się do danych strukturalnych typu merchant listing, a te wymagają nazwy, zdjęcia i oferty z ceną oraz walutą w trzyliterowym formacie ISO 4217. Google zaleca umieszczać dane Product w początkowym HTML, bo znaczniki generowane dynamicznie mogą sprawić, że zakupowe skanowanie będzie rzadsze i mniej niezawodne. Przed startem dobrze jest też ustalić, jak to wygląda po stronie marketingu sklepu, bo według Google dane strukturalne na stronach razem z plikiem produktowym w Merchant Center dają najszersze możliwości wyświetlania i pomagają Google poprawnie zrozumieć i zweryfikować dane. Zasady zwrotów i program lojalnościowy Google radzi opisać osobno, danymi strukturalnymi zagnieżdżonymi w znaczniku Organization.
Mapa witryny ma limit 50 tysięcy adresów albo 50 MB bez kompresji na plik, powinna zawierać wyłącznie bezwzględne adresy kanoniczne i być zapisana w UTF-8. Wartości priority i changefreq Google ignoruje, a z lastmod korzysta tylko wtedy, gdy data jest konsekwentnie i sprawdzalnie zgodna z ostatnią istotną zmianą strony. Mapy nie może blokować robots.txt, a przesłać ją w Search Console może tylko właściciel usługi, więc dostęp warto ustalić przed startem.
Po przełączeniu
Po migracji Google przez jakiś czas skanuje nową stronę intensywniej niż zwykle, a pozycje mogą się chwilowo wahać. Dla średniej wielkości witryny podmiana starych adresów na nowe w wynikach może według dokumentacji potrwać kilka tygodni albo dłużej, a jeśli strony trafiły do grupy duplikatów, Google może je w niej trzymać do dwóch tygodni nawet po poprawce.
Core Web Vitals sprawdza się na danych od prawdziwych użytkowników, z progami dobrego wyniku 2,5 sekundy dla LCP, 200 milisekund dla INP i 0,1 dla CLS. Nowy sklep może przez pierwsze tygodnie mieć w Search Console pusty raport Core Web Vitals, bo baza CrUX nie zebrała jeszcze dla niego wystarczających danych, więc na start sprawdź stronę narzędziami laboratoryjnymi, pamiętając, że raport Google będzie liczył co innego.
Artykuł sponsorowany.
