Przebudowa strony bez utraty pozycji w Google: adresy, przekierowania i pomiar

Pierwsza decyzja: czy adresy URL w ogóle muszą się zmienić

Od odpowiedzi na to jedno pytanie zależy, czy przebudowa jest dla Google zwykłą aktualizacją strony, czy przeprowadzką, którą trzeba zaplanować adres po adresie.

Google ma na te dwie sytuacje dwa osobne przewodniki. Pierwszy dotyczy zmian infrastruktury, przy których adresy widoczne dla użytkownika zostają takie same: zmieniasz firmę hostingową albo przenosisz stronę na sieć CDN, a pod adresem /oferta/ nadal jest oferta. Drugi dotyczy przeprowadzek ze zmianą adresów, a Google zalicza do nich przejście z HTTP na HTTPS, zmianę domeny, w tym połączenie kilku domen, oraz zmianę ścieżek w tej samej domenie, na przykład z /page.php?id=1 na /widget.

Nowy wygląd, nowy framework i nowy hosting przy niezmienionych adresach to z punktu widzenia wyszukiwarki najmniej ryzykowny wariant, bo nie ma czego przenosić. Każdy adres, który Google zna, nadal działa. Ryzyko przesuwa się wtedy na treść, tytuły, linki wewnętrzne i blokady z wersji testowej.

Dlatego każdą przebudowę zaczynam od pytania, czy zmiana adresów czemuś służy. Jeśli obecne adresy są czytelne i strona ma z nich ruch, zmiana tylko dlatego, że nowy system generuje je inaczej, to koszt bez korzyści. Sprawdź, czy nowy system pozwala ustawić własną ścieżkę dla każdej podstrony. Jeśli tak, odtworzysz stare adresy jeden do jednego i przeprowadzki w rozumieniu Google w ogóle nie będzie.

Google podaje też regułę, która rozstrzyga spór o zakres: zmieniaj jedną rzecz naraz. Przykład z dokumentacji brzmi tak: jeśli chcesz przenieść stronę na nową domenę, zmienić system zarządzania treścią i wprowadzić nowy układ, zrób to po kolei, a nie jednocześnie. Ten sam przewodnik zaleca postawienie nowej strony najlepiej na tym samym systemie, którego używała stara.

W pomocy do narzędzia zmiany adresu Google pisze wprost, czym grozi połączenie wszystkiego w jednym kroku. Zachowanie tej samej architektury witryny pomaga przenieść sygnały bardziej bezpośrednio, a jeśli przeprowadzkę połączysz z przebudową treści i struktury adresów, prawdopodobnie zobaczysz pewną utratę ruchu, bo Google może musieć od nowa poznać i ocenić poszczególne podstrony. Warto pokazać to zdanie każdemu, kto chce „przy okazji” zmienić wszystko.

Rodzaje zmian przy przebudowie strony i to, czego każda wymaga według dokumentacji Google.

Tabela jest szersza niż ekran: przesuń ją palcem w bok.

Czego się spodziewać i ile to trwa według Google

Jeśli wykonawca obiecuje, że po przeprowadzce nic się nie zmieni w wynikach wyszukiwania, obiecuje więcej, niż obiecuje sam Google.

Przewodnik Google o przenoszeniu witryny ze zmianą adresów mówi wprost, że przy każdej istotnej zmianie możesz zobaczyć wahania pozycji, dopóki Google ponownie nie zindeksuje strony. W witrynie średniej wielkości mija kilka tygodni lub więcej, zanim Google zacznie stopniowo pokazywać nowe adresy zamiast starych; w większych jeszcze dłużej. Tempo zależy głównie od liczby adresów i szybkości serwera.

Przeprowadzka dzieje się adres po adresie, a nie naraz. Żeby uznać ją za zakończoną, Googlebot musi odwiedzić każdy adres na starej i nowej stronie co najmniej raz, a stałej częstotliwości odwiedzin nie ma. Podstrona, na którą robot zagląda rzadko, przeniesie się później niż strona główna, i to nie jest błąd.

Dobra wiadomość: według Google przekierowania 301 i inne przekierowania stałe nie powodują utraty PageRank. Skoro samo przekierowanie nie odbiera mocy linków, ryzyko leży gdzie indziej: w adresach bez przekierowania, w przekierowaniach do stron o innej treści i w blokadach, przez które Google nie widzi nowej strony. Na te trzy rzeczy masz pełny wpływ, na to, jak szybko Google ponownie przetworzy witrynę, nie masz.

Po zmianie domeny stare adresy mogą jeszcze pojawiać się w wynikach. Google śledzi oba adresy, jeden uznaje za kanoniczny, a drugi za jego alternatywną nazwę, którą czasem pokazuje, gdy zapytanie sugeruje, że użytkownik bardziej ufa staremu adresowi. Dokumentacja opisuje to jako zjawisko normalne, które wygasa samo.

Jedna rzecz może nie wrócić. Jeśli świadomie usuwasz treść albo scalasz kilka podstron w jedną, zapytania, na które odpowiadała usunięta treść, mogą przestać prowadzić do Twojej strony. To decyzja biznesowa, a nie błąd techniczny, i warto ją podjąć na podstawie danych z Search Console, a nie gustu.

Nie podam liczby tygodni, po której ruch „wraca”, bo Google jej nie podaje, a każda taka liczba bez Twojej strony byłaby zgadywaniem. W dokumentacji są natomiast terminy poszczególnych etapów, zebrane w tabeli. Opisują typowy przebieg, a nie gwarancję. Jeśli po tych terminach stare adresy wciąż są w indeksie, a nowe nie, wróć do statusów z raportu Indeksowanie stron, zamiast przebudowywać coś jeszcze raz.

Terminy podane w dokumentacji Google, stan na 22 września 2026 r.

Tabela jest szersza niż ekran: przesuń ją palcem w bok.

Spis starych adresów, zanim ktokolwiek ruszy kod

Mapy przekierowań nie zrobisz z pamięci ani z menu strony. Adresy, które mają znaczenie, siedzą w miejscach, których menu nie pokazuje.

Google podpowiada, skąd brać listę. Zacznij od adresów, które liczą się najbardziej: z mapy witryny, bo najważniejsze adresy prawdopodobnie zgłosiłeś właśnie przez nią w Search Console, z logów serwera albo narzędzia analitycznego, bo tam widać adresy z największym ruchem, oraz z raportu Linki w Search Console, który pokazuje podstrony z linkami wewnętrznymi i zewnętrznymi. Pełną listę podstron zwykle wyeksportujesz z systemu zarządzania treścią, a logi pokażą adresy odwiedzone choćby raz w ostatnim czasie; okres dobierz z uwzględnieniem sezonowości.

Dokumentacja przypomina też o osadzonych plikach. Obrazy, filmy, pliki JavaScript i CSS oraz pliki do pobrania, na przykład PDF z katalogiem, trzeba przenieść tak samo jak podstrony, bo mogą mieć własny ruch i własne linki.

Wszystko ląduje w jednym arkuszu: jeden wiersz to jeden stary adres, a kolumny to kod odpowiedzi, tytuł, canonical, kliknięcia i wyświetlenia z Search Console, nowy adres i decyzja. Ten arkusz jest potem mapą przekierowań, listą kontrolną po starcie i punktem odniesienia przy pomiarze.

1. Wyeksportuj dane z raportu SkutecznośćKliknięcia, wyświetlenia, CTR i średnia pozycja. Raport domyślnie pokazuje ostatnie trzy miesiące, więc wydłuż zakres i wyeksportuj dane osobno według stron i według zapytań.
2. Zbierz adresy z mapy witryny i z systemuTo lista podstron, które strona sama uznaje za ważne. Punkt wyjścia, nie całość.
3. Dołóż adresy z logów serweraStare kampanie, dawne wpisy, adresy z parametrami. Nie ma ich w menu, ale każdy może mieć link z innej strony.
4. Dopisz pliki i mediaPDF-y, obrazy i filmy. Jeśli zmieniają adres, potrzebują przekierowania tak samo jak podstrony.
5. Przeskanuj starą stronę crawleremCrawler to program, który przechodzi po wszystkich linkach strony i zapisuje, co pod nimi znalazł, na przykład Screaming Frog. Zbierz nim kody odpowiedzi, tytuły, nagłówki i canonical każdej podstrony. Po starcie ten zapis będzie jedynym dowodem, co było na starej stronie.
6. Zapisz, kto linkuje do starych adresówGoogle zaleca zachowanie tej listy z raportu Linki. Po starcie poprosisz właścicieli tych stron o aktualizację linków.

Mapa „stary → nowy”: odpowiednik, a nie strona główna

Dla każdego starego adresu podejmujesz jedną z czterech decyzji: adres zostaje, przekierowuje na odpowiednik, przekierowuje na stronę, do której scaliłeś treść, albo znika z kodem 404 lub 410.

Pierwsza zasada ma w dokumentacji Google osobne ostrzeżenie: nie przekierowuj wielu starych adresów na jeden niepasujący adres, taki jak strona główna. Myli to użytkowników i może zostać potraktowane jako soft 404 (w polskiej Search Console: pozorny błąd 404), czyli strona, która udaje, że istnieje, choć treści, której szukał odwiedzający, już nie ma. Wyjątek jest jeden: jeśli treść z kilku podstron scaliłeś w jedną nową, możesz przekierować wszystkie stare adresy właśnie na nią.

Przekierowanie przenosi adres, a nie treść. Jeśli stara podstrona o przeglądach kotłów przekierowuje na ogólną stronę „Usługi”, na której o przeglądach jest jedno zdanie, formalnie wszystko działa, ale pytanie, na które odpowiadała stara podstrona, zostaje bez odpowiedzi. Dlatego w arkuszu obok nowego adresu zapisuję, czy nowa strona pokrywa ten sam temat. Jeśli nie pokrywa, problem leży w planie treści, a nie w konfiguracji serwera.

Dla treści usuniętej bez zastępstwa Google zaleca kod 404 albo 410. Dla wyszukiwarki różnica jest niewielka: dokumentacja kodów odpowiedzi mówi, że wszystkie błędy 4xx poza 429 są traktowane tak samo, a już zaindeksowany adres wypada z indeksu. Wybierz kod zgodny z tym, co się stało, i nie trać czasu na spór 404 czy 410.

Łańcuchy przekierowań powstają najłatwiej na stronach po drugiej albo trzeciej przebudowie, bo stare reguły wskazują adresy, które same właśnie dostają przekierowanie. Googlebot przejdzie najwyżej 10 przekierowań w łańcuchu, ale Google radzi kierować od razu na adres docelowy, a jeśli to niemożliwe, trzymać łańcuch krótko: najlepiej nie więcej niż trzy, a na pewno mniej niż pięć. Jeśli stara strona ma już własne reguły przekierowań, przepisz je tak, żeby od razu wskazywały nowy adres.

Nowy system potrafi też po cichu zmienić konwencję adresów: ukośnik na końcu albo jego brak, wielkie litery, kolejność parametrów. Technicznie /oferta i /oferta/ to dwa różne adresy. Wybierz jedną formę, przekieruj na nią drugą i trzymaj się jej w linkach, w canonical i w mapie witryny.

Decyzje w mapie przekierowań i kody odpowiedzi, które im odpowiadają.

Tabela jest szersza niż ekran: przesuń ją palcem w bok.

Przekierowanie 301, 302 czy 308 i gdzie je ustawić

Dla odwiedzającego wszystkie przekierowania wyglądają tak samo. Dla Google różnią się tym, który adres pokaże w wynikach wyszukiwania.

Google dzieli przekierowania na stałe i tymczasowe. Stałe, czyli 301 i 308, sprawiają, że w wynikach pokazuje się nowy adres, a system indeksowania traktuje przekierowanie jako sygnał, że cel ma być adresem kanonicznym. Tymczasowe, czyli 302, 303 i 307, zostawiają w wynikach adres źródłowy; cel może mimo to zostać zaindeksowany, jeśli wskazują na to inne sygnały kanoniczności. Dokumentacja kodów odpowiedzi nazywa 301 silnym sygnałem, a 302 słabym.

Przy przebudowie, która zmienia adresy na stałe, wybór jest więc prosty: 301 albo 308. Przekierowanie 302 ustawione „na razie” i zapomniane oddaje decyzję o tym, który adres pokazać, innym sygnałom zamiast Tobie.

Liczy się też miejsce, w którym przekierowanie powstaje. Google układa metody według tego, jak pewnie je rozpoznaje, i na pierwszym miejscu stawia przekierowania po stronie serwera: reguły w pliku .htaccess na Apache, dyrektywę return 301 w konfiguracji NGINX albo nagłówek ustawiany przez skrypt, na przykład funkcją header() w PHP. Platformy takie jak Shopify czy Blogger mogą mieć własne, wbudowane mechanizmy przekierowań. Jeśli przenosisz sklep, osobno opisałem, co dzieje się z adresami przy zmianie platformy.

Gdy serwer nie pozwala na przekierowania, zostaje meta refresh: natychmiastowy Google traktuje jak stały, opóźniony jak tymczasowy. Przekierowanie w JavaScript to ostatnia deska ratunku, bo Google wykonuje skrypty dopiero przy renderowaniu, a jeśli renderowanie się nie uda, przekierowania po prostu nie zobaczy.

Jak długo je trzymać? Przewodnik o przeprowadzkach mówi: tak długo, jak to możliwe, zwykle co najmniej rok, bo tyle czasu pozwala przenieść wszystkie sygnały, łącznie z linkami z innych stron; z perspektywy użytkowników Google sugeruje rozważenie utrzymania ich bezterminowo. Każda reguła to jedna linijka konfiguracji, więc przekierowania zostawiam na stałe, dopóki domena należy do firmy.

Przekierowania trzeba przetestować, zanim zrobi to Google. Narzędzie Sprawdzanie adresu URL w Search Console pokaże, czy Google dociera do strony docelowej, ale kodu przekierowania z niego nie odczytasz: test wersji opublikowanej przechodzi przez przekierowanie, nie pokazując go. Kody odpowiedzi sprawdzisz poleceniem curl albo crawlerem, a przy większej liczbie adresów skryptem; Google wymienia tu Screaming Frog i dodaje, że często widzi przekierowania prowadzące na błędne, nieistniejące adresy nowej strony. Test jest prosty: stary adres ma zwrócić 301 lub 308, a adres z nagłówka Location ma odpowiedzieć kodem 200 i być tym, który zapisałeś w mapie.

Canonical, mapa witryny i linki wewnętrzne po nowemu

Przekierowania mówią Google, dokąd coś się przeniosło. Canonical, mapa witryny i linki wewnętrzne mówią, który adres jest teraz właściwy. Wszystkie muszą mówić to samo.

Każdy nowy adres powinien mieć tag link rel="canonical" wskazujący jego własny adres. Google układa sygnały kanoniczności według siły: przekierowanie i rel="canonical" to sygnały silne, obecność w mapie witryny to sygnał słaby. Sygnały się sumują, a dokumentacja wprost odradza wskazywanie różnych adresów różnymi metodami, na przykład jednego w mapie witryny, a innego w canonical.

Google zaleca adresy bezwzględne w canonical, czyli z protokołem i domeną, i uzasadnia to przykładem, który pasuje do przebudowy: adresy względne mogą narobić problemów, gdy przez przypadek dopuścisz do indeksowania stronę testową. Po uruchomieniu przekierowań sprawdź, czy canonical wskazuje nowe adresy, a nie domenę testową albo starą domenę z szablonu. Na stronach renderowanych w JavaScript Google radzi podać canonical w źródle HTML i nie pozwalać skryptom go zmieniać, a na stronach wielojęzycznych zaktualizować adnotacje hreflang.

Mapa witryny ma zawierać nowe, pełne adresy, bo Google próbuje pobrać je dokładnie tak, jak je wpisałeś. Zgłoś ją w raporcie Mapy witryn w Search Console albo dopisz linię Sitemap w robots.txt. Google ignoruje wartości priority i changefreq, a lastmod bierze pod uwagę tylko wtedy, gdy jest konsekwentnie zgodna z prawdą. Samo zgłoszenie mapy jest wskazówką, a nie gwarancją.

Według Google mała strona, około 500 podstron lub mniej i dobrze podlinkowana, może się bez mapy obejść. Przy przeprowadzce i tak ją zgłoś, bo przewodnik o przenosinach wymienia mapę jako sposób na szybsze wykrycie nowych adresów. Do monitorowania dokumentacja podsuwa dwie mapy: w starej liczba zaindeksowanych adresów z czasem spada do zera, w nowej rośnie, a ostrzeżenia o przekierowaniach przy starej są normalne.

Linki wewnętrzne zmień na nowe adresy według mapy, zamiast zdawać się na przekierowania, które spowalniają każdą wizytę. Google zaleca linkowanie do adresu kanonicznego i zasadniczo przechodzi tylko po linkach, które są elementem a z atrybutem href; zapisy w rodzaju routerLink bez href albo przejście wywoływane wyłącznie przez onclick odradza. Tekst linku ma opisywać stronę docelową, a nie brzmieć „kliknij tutaj”.

Po starcie przychodzi kolej na linki spoza strony. Google radzi poprosić o aktualizację witryny z zapisanej wcześniej listy, zaczynając od tych, z których przychodzi najwięcej wizyt, i zmienić linki w profilach w mediach społecznościowych oraz adresy docelowe kampanii reklamowych.

Blokady noindex i robots.txt, które przeżywają start

Google otwiera listę typowych błędów przy przeprowadzce właśnie od blokad noindex i robots.txt, które miały chronić wersję testową, a zostały na produkcji.

Część właścicieli blokuje na czas budowy robotom dostęp do całej strony w robots.txt albo dodaje regułę noindex. Google radzi w takim wypadku przygotować zawczasu docelową wersję robots.txt i listę adresów, z których usuniesz noindex w dniu startu, a w części o rozwiązywaniu problemów powtarza: nie zapomnij usunąć blokad potrzebnych tylko na czas migracji.

Te dwie blokady działają różnie. Robots.txt steruje tym, co robot może pobrać, a nie tym, co trafi do indeksu: Google może zaindeksować zablokowany adres bez jego treści, jeśli prowadzą do niego linki. Reguła noindex, w meta tagu robots albo w nagłówku HTTP X-Robots-Tag, usuwa stronę z wyników, ale działa tylko wtedy, gdy robot może stronę pobrać. Strona zablokowana w robots.txt i jednocześnie oznaczona noindex to najgorsze połączenie, bo robot nie zobaczy reguły, którą mu zostawiłeś. Reguły noindex w samym robots.txt Google nie obsługuje.

Przy nowym frameworku jest pułapka niewidoczna w przeglądarce. Według dokumentacji Google o JavaScript, gdy robot zobaczy noindex w kodzie strony, może pominąć renderowanie, więc usunięcie tagu noindex skryptem może nie zadziałać. Jeśli strona ma być w indeksie, noindex nie może być w HTML zwracanym przez serwer. Nagłówka X-Robots-Tag nie widać w źródle wcale: ustawia go serwer albo hosting, na przykład jedną regułą dla domeny testowej, która może trafić na produkcję razem z konfiguracją.

Na WordPressie źródłem blokady bywa jedno pole. Opcja „Proś wyszukiwarki o nieindeksowanie witryny” w Ustawienia → Czytanie, w polu Widoczność dla wyszukiwarek (w angielskiej wersji: Settings → Reading, Discourage search engines from indexing this site), od wersji 5.3 dodaje do strony meta tag robots z wartością noindex, nofollow, a zaznaczona na czas budowy łatwo przechodzi na produkcję razem z bazą danych.

Sam plik robots.txt potrafi wstrzymać pobieranie całej witryny, nawet jeśli nie ma w nim żadnej blokady. Według specyfikacji Google, jeśli plik zwraca błąd 5xx, przez pierwsze 12 godzin Google wstrzymuje pobieranie stron z witryny, a potem do 30 dni korzysta z ostatniej poprawnej wersji pliku. Błąd 4xx, z wyjątkiem 429, oznacza brak ograniczeń, więc jeśli pliku nie masz, adres ma zwracać zwykłe 404.

Najpewniej jest nie mieć czego usuwać. Przewodnik Google o zmianie hostingu podsuwa środowisko testowe z dostępem ograniczonym do wybranych adresów IP. Buduję to tak, że wersja testowa jest za hasłem albo filtrem IP na poziomie serwera, a produkcja nie ma w kodzie żadnego przełącznika, który trzeba pamiętać wyłączyć.

1. robots.txt na produkcjiBez reguły Disallow: / z wersji testowej, z kodem 200 albo 404, nigdy 5xx, i z linią Sitemap z nowym adresem mapy.
2. noindex w kodzie i w nagłówkachNa stronie głównej i kluczowych podstronach wyszukaj noindex w źródle zwracanym przez serwer i sprawdź nagłówki odpowiedzi pod kątem X-Robots-Tag, także dla plików PDF.
3. CanonicalBezwzględny, na produkcyjnej domenie, wskazujący ten sam adres, pod którym stoi strona.
4. Próbka przekierowańKilkadziesiąt adresów z arkusza, w tym te z największym ruchem: jeden krok, właściwy cel, cel odpowiada kodem 200.
5. Weryfikacja Search ConsolePlik HTML albo meta tag weryfikacji musi przetrwać przebudowę. Google przypomina o tym w obu przewodnikach, o przeprowadzce i o zmianie hostingu.
6. Test wersji opublikowanejUruchom go w narzędziu Sprawdzanie adresu URL (w angielskiej wersji: live test) dla strony głównej i kilku kluczowych podstron. Pokaże, czy Google może pobrać stronę i czy widzi noindex.

Zmiana domeny i narzędzie zmiany adresu w Search Console

To narzędzie służy do jednego: do przenosin z jednej domeny albo subdomeny na inną. Przy przebudowie w tej samej domenie nie masz go do czego używać.

Pomoc Search Console wymienia, kiedy go nie używać: przy przejściu z HTTP na HTTPS, bo Google sam rozpozna zmianę; przy przenoszeniu podstron w obrębie witryny, gdzie wystarczą przekierowania i aktualna mapa witryny; przy przejściu między wersją z www i bez www, gdzie wystarczy canonical albo przekierowania; oraz przy zmianie hostingu bez zmiany adresów. Działa natomiast przy przenosinach z domeny do ścieżki w innej domenie.

Warunki są konkretne. Musisz być właścicielem obu usług w Search Console i zarządzać nimi z tego samego konta Google. Narzędzie działa tylko dla usług obejmujących całą domenę lub subdomenę, na przykład example.com albo m.example.com, a nie ścieżkę w niej, i nie przenosi subdomen, w tym www, więc Google każe zgłosić zmianę dla wszystkich wariantów starej domeny, także nieużywanych, i mieć je wszystkie zweryfikowane. Wszystkie protokoły przenosi natomiast razem: zgłoszenie dla wersji z HTTP obejmuje też wersję z HTTPS.

Przed zgłoszeniem ustaw przekierowanie 301 ze starej strony głównej na nową, a najlepiej także z kanonicznych podstron. Narzędzie sprawdza, czy jesteś właścicielem obu witryn, i sprawdza przekierowania na kilku podstronach; błąd krytyczny blokuje zgłoszenie, niekrytyczny kończy się ostrzeżeniem.

Po zgłoszeniu Google przez 180 dni priorytetowo traktuje indeksowanie nowej witryny, przekazuje do niej sygnały ze starej i przy wyborze adresów kanonicznych preferuje nową. Starej nie usuwa z indeksu: jej adresy mogą dalej pojawiać się w wynikach, jeśli nie mają odpowiednika na nowej stronie. Przez te 180 dni zgłoszenie da się anulować, a po tym okresie Google nie widzi już związku między witrynami.

Dwie rady z tej samej pomocy zapobiegają kłopotom na lata. Utrzymuj opłacaną starą domenę co najmniej rok, żeby nikt jej nie kupił i nie wykorzystał w złych celach. Nie łącz też przeprowadzek w łańcuch: po zgłoszeniu przenosin z A do B nie zgłosisz od razu przenosin z B do C, a łączenie kilku witryn w jedną lepiej rozłożyć w czasie.

Jeśli nowa domena miała wcześniej innego właściciela, przewodnik Google każe sprawdzić w Search Console, czy nie ma na niej ręcznych działań za spam i czy nie zostały po nim prośby o usunięcie adresów, zwłaszcza obejmujące całą witrynę.

Nowy silnik strony: JavaScript, kody odpowiedzi i serwer

Przebudowa bywa zmianą technologii, a nie tylko wyglądu. Wtedy ta sama treść może wyglądać dla Google zupełnie inaczej niż dla Ciebie w przeglądarce.

Google przetwarza strony oparte na JavaScript w trzech fazach: pobranie, renderowanie i indeksowanie. Strony z kodem 200 trafiają do kolejki renderowania i czekają w niej kilka sekund, a czasem dłużej; treść generowana przez skrypty jest widoczna dopiero potem. Dokumentacja pisze, że renderowanie po stronie serwera albo wstępne renderowanie nadal jest świetnym pomysłem, bo nie każdy robot wykonuje JavaScript. Strony buduję tak, żeby treść, tytuł, canonical i linki były w HTML zwracanym przez serwer.

Aplikacje jednostronicowe mają dwie własne pułapki. Pierwsza to adresy z fragmentem, w rodzaju /#/oferta: Google radzi zamiast nich History API. Druga to pozorny błąd 404 (soft 404): jeśli serwer na każdy adres zwraca ten sam plik aplikacji, nieistniejąca podstrona dostaje kod 200 i pusty widok. Google proponuje przekierowanie skryptem na adres, dla którego serwer zwraca 404, albo dodanie meta tagu noindex do stron błędu.

Kody odpowiedzi muszą mówić prawdę. Kod 2xx nie gwarantuje zaindeksowania, adresy zwracające 4xx wypadają z indeksu, a błędy 5xx i 429 każą robotom zwolnić; adresy, które uporczywie zwracają błąd serwera, są usuwane z indeksu. Strona z przerwami w działaniu w dniu startu traci więc nie tylko odwiedzających.

Serwer musi też wytrzymać większy ruch robota. Google uprzedza, że po migracji robot przez jakiś czas pobiera nową stronę intensywniej niż zwykle, bo dochodzą przekierowania ze starej. Sprawdź zaporę i ochronę przed atakami DoS: Google opisuje przypadki, w których systemy ochronne blokują Googlebota, bo wysyła więcej zapytań niż człowiek.

Przy zmianie hostingu Google radzi co najmniej tydzień wcześniej obniżyć TTL rekordów DNS, na przykład do kilku godzin, i nie wyłączać starego serwera, dopóki logi nie pokażą zerowego ruchu. Przewodnik o przeprowadzkach ze zmianą adresów dokłada ogólną radę: jeśli ruch jest sezonowy albo spada w określone dni tygodnia, zaplanuj start na taki spadek.

Małe i średnie witryny Google radzi przenosić w całości naraz, bo pomaga to algorytmom szybciej wykryć przeprowadzkę. Duże mogą przenosić się po sekcjach, ale Google zastrzega, że test na jednej sekcji nie jest w pełni reprezentatywny dla przenosin całości.

Co zmierzyć przed startem i po nim

Bez zapisanego stanu sprzed przebudowy nie odróżnisz przejściowego wahania od awarii, bo nie będziesz miał do czego porównać.

Przed startem potrzebujesz trzech zapisów: eksportu z raportu Skuteczność według stron i zapytań, skanu starej strony z kodami odpowiedzi, tytułami i canonical oraz liczby zaindeksowanych stron z raportu Indeksowanie stron. To wystarczy, żeby po starcie odpowiedzieć, czy spadek dotyczy całej strony, czy konkretnych podstron.

Po starcie najwięcej powie raport Indeksowanie stron; nazwy statusów podaję tak, jak wyświetla je polska wersja Search Console, a w nawiasie po angielsku. Część z nich jest po przeprowadzce oczekiwana: stary adres ze statusem Strona zawierająca przekierowanie sam nie jest indeksowany, i o to chodzi; cel przekierowania może, ale nie musi, trafić do indeksu. Google wskazuje też objaw wart osobnej uwagi: jeśli liczba zaindeksowanych stron spada, a błędów nie przybywa, możliwe, że blokujesz dostęp przez robots.txt, noindex albo wymóg logowania.

Narzędzie Sprawdzanie adresu URL pokaże adres kanoniczny wybrany przez Google, ale tylko w danych z indeksu; test wersji opublikowanej tego nie przewidzi. Liczba sprawdzeń na usługę jest dziennie ograniczona, a według Google wielokrotna prośba o zindeksowanie tego samego adresu go nie przyspieszy.

W raporcie Skuteczność stary i nowy adres to dwa osobne wiersze, więc żeby porównać podstronę przed i po, zsumuj je według mapy z arkusza. Trend oglądaj w widoku tygodniowym albo miesięcznym, które według pomocy Search Console wygładzają dzienne wahania. W logach serwera patrz na wizyty Googlebota i adresy, które niespodziewanie zwracają błędy.

Przy stronie firmowej mającej kilkadziesiąt podstron nie potrzebujesz rozbudowanego zestawu narzędzi. Wystarczą raporty Indeksowanie stron, Mapy witryn i Skuteczność, narzędzie Sprawdzanie adresu URL, logi serwera i arkusz z mapą adresów, do którego wszystko porównujesz.

Statusy w raporcie Indeksowanie stron po przeprowadzce i jak je czytać.

Tabela jest szersza niż ekran: przesuń ją palcem w bok.

Kiedy przebudowa to zły pomysł i kiedy nie potrzebujesz wykonawcy

Nie każda strona, która przestała się podobać, wymaga przebudowy, i nie każda przebudowa wymaga zlecenia.

Jeśli strona przynosi zapytania i ma pozycje, a problemem jest wygląd, zmień wygląd i zostaw adresy, treść i tytuły tak, jak są. Przepisywanie tekstów stron, które dziś ściągają ruch, zrób osobnym krokiem, po ustabilizowaniu się nowej wersji, i mierz efekt na konkretnych podstronach.

Jeśli masz stronę na WordPressie albo sklep na platformie i zmieniasz tylko motyw, a adresy zostają, najpewniej poradzisz sobie sam z listą kontrolną z sekcji o blokadach. Wtedy nie potrzebujesz mnie ani nikogo innego. Sprawdź tylko, czy motyw nie zgubił tytułów, nagłówków i canonical, czy w Ustawienia → Czytanie pole „Proś wyszukiwarki o nieindeksowanie witryny” jest odznaczone i czy menu prowadzi do tych samych podstron.

Jeśli plan zakłada zmianę domeny, systemu, wyglądu i treści jednocześnie, rozłóż go na etapy, tak jak radzi Google, i przyjmij, że każdy etap ma własny okres wahań. Gdy zrobisz wszystko naraz, nie dowiesz się, która zmiana odpowiada za spadek, i nie cofniesz jej osobno.

Wykonawca ma sens, gdy adresów jest dużo i część trzeba wyciągać z logów, gdy strona przechodzi na inną technologię, gdy zmienia się domena albo gdy przenosisz sklep z inną strukturą adresów. Przebudowę strony zaczynam od przeglądu obecnej witryny, jej treści i funkcji, a na tej podstawie proponuję zakres razem z planem zachowania ważnych adresów i przekierowań. Przeniesienie treści ze starej strony jest w cenniku na liście rzeczy, które podnoszą wycenę; resztę kosztów opisuję w przewodniku ile kosztuje strona internetowa. Jeśli nie wiesz, czy potrzebujesz strony, czy aplikacji, zajrzyj do porównania aplikacja webowa a strona internetowa.

Jeśli zlecasz przebudowę, mnie albo komukolwiek innemu, przed startem wymagaj pięciu rzeczy. Bez nich o błędzie w przeprowadzce dowiesz się dopiero ze spadku w Search Console.

• Arkusz mapy przed startemKażdy stary adres z decyzją i nowym celem, do Twojego wglądu, zanim cokolwiek trafi na produkcję.
• Wynik testu przekierowańLista adresów z kodem odpowiedzi i celem, wygenerowana skryptem albo crawlerem, a nie zapewnienie, że „działa”.
• Lista blokad do usunięciaGdzie w wersji testowej są robots.txt, noindex i X-Robots-Tag oraz kto je usuwa. Najlepsza odpowiedź: nigdzie, bo wersja testowa jest za hasłem.
• Search Console zostaje w firmieUsługi w Search Console, także dla starej domeny, należą do firmy. Wykonawca dostaje dostęp, a nie własność.
• Zapis stanu sprzed przebudowyEksport z raportu Skuteczność i skan starej strony, przekazane Tobie. Bez nich nie ma z czym porównać wyników.

Pytania i odpowiedzi