Przeniesienie strony internetowej - adresy, treści i przekierowania

Co dokładnie się zmienia, gdy przenosisz stronę

„Przeniesienie strony” oznacza w rozmowach z klientami cztery różne rzeczy. Każda niesie inne ryzyko i wymaga innej listy prac. Zanim zaczniesz planować przekierowania, ustal, który przypadek jest Twój. Czasem jest ich kilka naraz.

Pierwszy przypadek to nowy projekt graficzny na tej samej domenie i w tym samym systemie. Adresy podstron mogą zostać, a migracja sprowadza się do pilnowania, żeby nikt ich nie zmienił po drodze. Drugi to zmiana systemu, na przykład przejście ze starego kreatora na WordPressa albo z WordPressa na własny kod. Tu adresy zmieniają się prawie zawsze, bo każdy system inaczej buduje linki. Trzeci to zmiana domeny po rebrandingu albo połączeniu firm. Czwarty to zmiana hostingu, która pozornie nie dotyka adresów, ale potrafi zepsuć formularze, pocztę i certyfikat.

Jeśli dopiero decydujesz, czy w ogóle budować nową stronę, zacznij od poradnika o tym, kiedy warto przebudować stronę. Ten tekst zakłada, że decyzja zapadła i trzeba ją przeprowadzić bez strat.

Zapisz stan obecnego serwisu, zanim ktokolwiek go dotknie

Przed zmianą zbierz listę adresów, treści, formularzy i plików do pobrania. Menu nie pokazuje całej zawartości serwisu. Na starych stronach żyją podstrony sprzed lat, do których nikt nie linkuje z nawigacji, a które nadal przynoszą wejścia z Google albo wiszą na ulotkach.

Skąd wziąć pełną listę adresów

Jedno źródło nie wystarczy. Zestaw co najmniej trzy. Mapa witryny (plik sitemap.xml) pokazuje to, co system uznaje za publiczne. Raport „Strony” w Google Search Console pokazuje, co Google zaindeksował, w tym adresy, o których firma zapomniała. Narzędzie do skanowania strony przechodzi po linkach i wyłapuje podstrony, obrazy i pliki. Do tego dochodzi raport skuteczności w Search Console z adresami, które dostają kliknięcia, oraz raport stron docelowych w GA4.

Zapisz wszystko w jednym arkuszu. Jedna kolumna na adres, druga na to, co pod nim jest, trzecia na źródło (menu, mapa witryny, Search Console). Kolejne kolumny na kliknięcia i wejścia z ostatnich dwunastu miesięcy. Ten arkusz będzie podstawą mapy przekierowań i listy testów, więc jego jakość decyduje o całej migracji.

Rzeczy, których nie widać w menu

Uwzględnij strony, do których prowadzą kampanie, materiały drukowane albo linki od partnerów. Zdarza się, że adres podstrony z promocją jest wydrukowany na dziesięciu tysiącach ulotek. Kod QR na samochodzie firmowym prowadzi do konkretnego adresu. Stopka maila handlowca linkuje do katalogu PDF. Partner handlowy ma na swojej stronie link do Waszej podstrony z certyfikatami. Żaden z tych adresów nie pojawia się w menu, a każdy z nich po migracji musi gdzieś prowadzić.

Przejdź po firmie z krótką listą pytań. Jakie adresy są w reklamach Google i Meta? Co jest w wizytówce Google jako link do strony i do menu? Jakie pliki wysyłacie klientom mailem? Jakie adresy są w podpisach, na wizytówkach, w katalogach? Co jest podlinkowane w profilach społecznościowych?

Sprawdź też subdomeny i osobne domeny. Sklep pod adresem sklep.firma.pl, stary blog, strona kampanii sprzed dwóch lat na osobnej domenie, wersja niemiecka pod firma.de. Każda z nich ma własne adresy i własne miejsce w Search Console. Jeśli nowa strona ma je połączyć w jeden serwis, każda potrzebuje własnego wiersza w arkuszu i własnej decyzji.

Punkt odniesienia

Wykorzystaj dane Search Console i analityki, żeby rozpoznać strony przynoszące wejścia oraz zapytania. Zapisz je przed wdrożeniem jako punkt odniesienia. Wyeksportuj dane o kliknięciach dla wszystkich stron i zapytań z ostatniego roku, raport stron docelowych z GA4 i liczbę wysłanych formularzy z tego samego okresu. Bez tego po migracji nie odróżnisz zwykłego wahania od awarii.

Nowy projekt powinien uwzględniać rolę tych stron, nawet jeśli zmienia się układ nawigacji. Podstrona, która przynosi połowę zapytań, zasługuje na osobne miejsce w nowej strukturze. Nie może zniknąć tylko dlatego, że nie pasuje do nowego menu.

Dopasuj stare adresy do odpowiednich nowych treści

Dla adresów, które mają się zmienić, przygotuj mapę odpowiedników. Podstrona konkretnej usługi powinna prowadzić do treści odpowiadającej tej usłudze. Kierowanie wszystkich starych linków na stronę główną utrudnia klientowi odnalezienie informacji. Google może potraktować takie przekierowanie jak zniknięcie strony, a nie jak jej przeniesienie.

Google zaleca przygotowanie mapowania adresów, wdrożenie odpowiednich przekierowań i monitorowanie migracji. Zmiany mogą powodować przejściowe wahania widoczności. Sam plan nie daje gwarancji zachowania pozycji. Szczegóły opisuje przewodnik Google o przenoszeniu witryny ze zmianą adresów.

Zasady, które stosujemy przy mapowaniu

• Jeden stary adres prowadzi do jednego nowego. Bez rozgałęzień i bez strony „wybierz z listy”.
• Odpowiednik ma odpowiadać treścią, a nie samym tematem. Stary opis montażu pomp ciepła prowadzi do nowego opisu montażu pomp ciepła. Jeśli takiej strony nie ma, prowadzi do najbliższej kategorii, na przykład „instalacje grzewcze”.
• Strony bez odpowiednika i bez ruchu mogą zwrócić kod 410, który mówi Google, że treść zniknęła celowo. To lepsze niż przekierowanie na stronę główną.
• Jeśli stary adres jest dobry i da się go zachować, zachowaj go. Każde przekierowanie to dodatkowe ryzyko, a adres bez przekierowania nie może się zepsuć.
• Pliki do pobrania też dostają odpowiedniki. Katalog sprzed dwóch lat wysłany klientom mailem ma prowadzić do aktualnego katalogu.

Jak wygląda arkusz mapy

Kolumna „uzasadnienie” wydaje się zbędna, dopóki po pół roku ktoś nie zapyta, dlaczego dany adres prowadzi tam, gdzie prowadzi. Kolumna z testem zamienia arkusz w listę kontrolną na dzień publikacji.

Spisanie mapy dla serwisu z trzydziestoma podstronami zajmuje popołudnie. Dla sklepu z tysiącem produktów potrzebna jest reguła zamiast ręcznej listy, na przykład zasada przepisywania adresów kategorii i produktów według wzorca. Reguły testuje się na próbce, a wyjątki dopisuje ręcznie.

301, 302, 404 i 410: który kod kiedy

Przekierowanie to odpowiedź serwera, która mówi przeglądarce i robotowi Google, dokąd pójść zamiast żądanego adresu. Rodzaj odpowiedzi ma znaczenie, bo Google interpretuje każdy kod inaczej. Google opisuje to w dokumentacji przekierowań.

• 301 (stałe) to podstawowe narzędzie migracji. Mówi, że treść przeniosła się na stałe, i prosi Google o przeniesienie sygnałów na nowy adres. Stosuj je do wszystkich zmienionych adresów, które mają zostać.
• 302 (tymczasowe) oznacza, że stary adres wróci. Przydaje się przy chwilowych przekierowaniach, na przykład w czasie prac serwisowych. Użyte przy migracji sugeruje Google, że zmiana jest chwilowa, więc nie służy do przenoszenia strony.
• 404 (nie znaleziono) to naturalna odpowiedź dla adresu, który nigdy nie istniał albo zniknął. Nie jest katastrofą, jeśli dotyczy stron bez wartości. Jest problemem, gdy dotyczy strony, która przynosiła zapytania.
• 410 (usunięto) to jasny sygnał, że strona została świadomie usunięta. Przydaje się przy porządkach w starych aktualnościach i ofertach, które nie wrócą.

Przekierowania techniczne, o których łatwo zapomnieć

Oprócz mapy podstron serwis potrzebuje kilku reguł ogólnych. Wersja z „www” i bez „www” ma prowadzić do jednej. Adres zaczynający się od http ma prowadzić do https. Adres z ukośnikiem na końcu i bez ukośnika ma zwracać tę samą stronę albo jedno przekierowanie, a nie dwie różne wersje. Wielkość liter w starych adresach, jeśli stary system je dopuszczał, też wymaga reguły.

Unikaj łańcuchów. Jeśli adres z 2019 roku przekierowuje na adres z 2022, a ten na nowy z 2026, popraw pierwsze przekierowanie tak, by prowadziło od razu do celu. Każdy skok to wolniejsze ładowanie i dodatkowe miejsce, w którym coś może się zepsuć. Przed migracją sprawdź, jakie przekierowania już istnieją na serwerze. Przy drugiej i trzeciej przebudowie w historii firmy pętle i łańcuchy są regułą, a nie wyjątkiem.

Treści, pliki i formularze, które przechodzą razem z adresami

Adresy to połowa migracji. Druga połowa to wszystko, co pod tymi adresami było. Przy przenoszeniu łatwo skupić się na menu i podstronach usług, a zgubić rzeczy, które ktoś w firmie uważa za oczywiste.

Pliki do pobrania przenieś wszystkie, a potem zdecyduj, które publikować. Katalogi, karty techniczne, certyfikaty, regulaminy, cenniki w PDF. Sprawdź daty i wersje. Jeśli karta produktu jest nieaktualna, nie publikuj starej, tylko zapisz, kto przygotuje nową. Stary plik dostaje przekierowanie do nowego, gdy nowy będzie gotowy.

Formularze wymagają osobnej uwagi, bo zepsuty formularz nie zgłasza błędu. Po prostu przestają przychodzić zapytania, a firma orientuje się po dwóch tygodniach. Zapisz, jakie formularze są na starej stronie, na jakie skrzynki trafiają, czy mają kopie w panelu i czy są podłączone do CRM-u. Nowe formularze mają trafiać w te same miejsca albo w nowe, uzgodnione z osobą, która obsługuje zapytania. Jak zaprojektować formularz, który nie gubi wiadomości, opisujemy w poradniku o formularzu kontaktowym na stronie.

Treści przenoś z decyzją, a nie automatycznie. Usunięcie podstrony tylko dlatego, że nie pasuje do nowego układu, poprzedź oceną jej roli: ile ma wejść, jakie zapytania przynosi, czy ktoś do niej linkuje. Z drugiej strony przenoszenie dwustu aktualności z dziesięciu lat też jest decyzją, która kosztuje czas. Rozsądny środek to przeniesienie wszystkiego, co ma wejścia lub linki, i świadome usunięcie reszty z kodem 410.

Do listy dołącz elementy, które nie są treścią w potocznym sensie. Skrypty analityki i menedżera tagów, baner zgody na cookies, piksel reklamowy, kod weryfikacji Search Console, wpis w robots.txt, dane rejestrowe w stopce. Każdy z nich ma trafić na nową stronę w działającej wersji, a nie w kopii sprzed trzech lat.

Co przenosi się inaczej w różnych firmach

Lista prac wygląda podobnie w każdej migracji, ale miejsca, w których coś ginie, zależą od branży. Poniżej to, na co patrzymy w pierwszej kolejności w zależności od tego, czym firma się zajmuje.

Firma usługowa

Najwięcej wejść przynoszą zwykle podstrony konkretnych usług i podstrony dla miejscowości, jeśli firma takie ma. Przy migracji łatwo je „uprościć” do jednej strony oferty, a razem z tym stracić wejścia z zapytań typu „usługa plus miasto”. Sprawdź też link do strony w wizytówce Google, bo po zmianie domeny albo adresu podstrony kontakt prowadzi w próżnię. Co zmienić w wizytówce, opisuje poradnik o optymalizacji profilu firmy w Google.

Produkcja i B2B

Tu żyją karty techniczne, katalogi i certyfikaty, które klienci mają zapisane w zakładkach i w mailach sprzed lat. Firma z branży przemysłowej potrafi mieć kilkadziesiąt PDF-ów podlinkowanych z ofert, które handlowcy wysyłali przez pięć lat. Każdy z tych plików musi po migracji otwierać się pod starym adresem albo przekierowywać na nowy. Wersje językowe wymagają osobnej mapy, bo niemiecka podstrona o obróbce CNC ma prowadzić do niemieckiej, a nie do polskiej. Jak zaplanować strukturę takiej strony, opisujemy w ofercie stron dla firm produkcyjnych.

Handel i sklep

Sklep to najtrudniejsza migracja, bo adresów są tysiące, a każdy produkt może mieć linki z porównywarek i reklam. Zamiast ręcznej mapy potrzebne są reguły dla kategorii i produktów oraz lista wyjątków dla produktów, które sprzedają się najlepiej. Do tego dochodzą pliki produktowe do Google Merchant Center i reklam, które po zmianie adresów trzeba wygenerować na nowo. Osobna decyzja dotyczy zamówień złożonych w dniu przełączenia: muszą trafić do nowego systemu albo zostać obsłużone ręcznie.

Gastronomia

Restauracja ma zwykle mało podstron, ale dwa adresy o dużym znaczeniu: menu i rezerwacje. Link do menu jest w wizytówce Google, w profilach społecznościowych i w kodach QR na stolikach. Jeśli menu było plikiem PDF pod konkretnym adresem, ten adres ma dalej działać. System rezerwacji, jeśli jest zewnętrzny, wymaga sprawdzenia, czy osadzony skrypt działa na nowej stronie i czy potwierdzenia nadal przychodzą.

Budowlanka i instalacje

Największą wartością są galerie realizacji, często setki zdjęć w różnych rozmiarach. Przy przenoszeniu trzeba zdecydować, które realizacje zostają, i zadbać o opisy oraz sensowne nazwy plików. Stare adresy realizacji bywają podlinkowane z forów i grup, gdzie klienci polecają wykonawców. Firma budowlana potrzebuje też sprawdzenia formularza wyceny z załącznikami, bo zdjęcie miejsca montażu to połowa zapytania.

Deweloper

Strona dewelopera zmienia się przez cały czas trwania inwestycji: statusy domów, etapy, materiały. Przy migracji liczy się, żeby karty ofert zachowały adresy, bo są podlinkowane z portali ogłoszeniowych i reklam. Do tego dochodzą plany, wizualizacje i prospekty informacyjne. Jeśli strona ma interaktywny wybór domu na planie osiedla, jak w realizacji VPM Development, trzeba sprawdzić, czy dane ofert przenoszą się razem ze statusami. Zakres takich stron opisujemy w ofercie stron dla deweloperów.

Przykład z naszego biurka: przeniesienie strony firmy instalacyjnej

Firma instalacyjna z okolic Nowego Tomyśla miała stronę sprzed kilku lat w starym kreatorze, z adresami kończącymi się na .html. Chciała nowej strony z osobnymi podstronami dla pomp ciepła, fotowoltaiki i klimatyzacji. Opisujemy przebieg bez liczb, bo to typowa migracja małego serwisu, a nie opis wyników.

1. Inwentaryzacja pokazała więcej adresów w Search Console niż w mapie witryny. Różnicę stanowiły stare aktualności i strony galerii, które nadal miały pojedyncze wejścia. Do tego kilka plików PDF, z których część była podlinkowana w stopce maila właściciela.
2. Dane z Search Console wskazały, że najwięcej kliknięć przynosi podstrona o pompach ciepła i podstrona o serwisie klimatyzacji. Tej drugiej nie było w menu, bo ktoś usunął ją z nawigacji dwa lata wcześniej. W nowej strukturze dostała osobne miejsce.
3. Mapa przekierowań objęła wszystkie adresy z inwentaryzacji. Aktualności bez wejść dostały kod 410. Reszta dostała odpowiedniki jeden do jednego. PDF-y z maili dostały przekierowania do nowych wersji plików.
4. Na wersji testowej okazało się, że formularz wyceny odrzuca załączniki większe niż kilka megabajtów, a zdjęcia z telefonu są większe. Limit podnieśliśmy przed publikacją, a nie po pierwszym zgłoszeniu klienta.
5. Przełączenie zrobiliśmy we wtorek rano. Test przekierowań na pełnej liście wykrył dwa adresy z błędem w regule, poprawione od razu. Zgłoszenie testowe dotarło na skrzynkę i do arkusza zgłoszeń.
6. Przez pierwsze tygodnie raport „Strony” pokazywał stare adresy jako przekierowane, co było spodziewane. Podstronę o serwisie klimatyzacji porównywaliśmy co tydzień z punktem odniesienia, bo na niej firmie zależało najbardziej.

Najwięcej czasu zajęła inwentaryzacja i decyzje o treściach, a nie samo wdrożenie przekierowań. Tak jest w większości migracji małych serwisów. Technika jest przewidywalna, decyzje wymagają osoby z firmy.

Co sprawdzić w wersji przed publikacją

Nowa strona powstaje pod adresem testowym, niedostępnym dla Google i klientów. Na tej wersji sprawdzasz wszystko, co po publikacji byłoby widoczne dla wszystkich. Oto lista, którą przechodzimy przed każdym przełączeniem.

1. Czy dotychczasowa oferta ma odpowiednie miejsce w nowym serwisie? Każda usługa, która miała podstronę, ma ją nadal albo ma świadomie wyznaczonego następcę.
2. Czy linki w tekstach i menu używają docelowych adresów, a nie starych, które będą przekierowywane? Przekierowanie we własnym menu spowalnia stronę i myli Google.
3. Czy formularze wysyłają na właściwe skrzynki, potwierdzają przyjęcie wiadomości i zapisują kopię? Wyślij testowe zgłoszenie z każdego formularza.
4. Czy pliki do pobrania otwierają się i mają aktualne wersje?
5. Czy podstrony mają właściwe tytuły, opisy i adresy kanoniczne? Adres kanoniczny ma wskazywać na docelową domenę, a nie na testową.
6. Czy ustawienia blokujące indeksowanie wersji testowej nie trafią na stronę publiczną? To najczęstsza przyczyna zniknięcia strony z Google po migracji.
7. Czy strona błędu 404 jest czytelna, ma menu i link do oferty?
8. Czy mapa witryny zawiera tylko nowe adresy, a robots.txt nie blokuje katalogów z obrazami i stylami?
9. Czy analityka, menedżer tagów i baner zgody działają, a zdarzenie wysłania formularza jest rejestrowane?
10. Czy certyfikat SSL obejmuje domenę z „www” i bez?
11. Czy wersje językowe mają własne adresy, przełącznik prowadzi do odpowiednika w drugim języku, a kod strony wskazuje, która wersja jest dla którego kraju?

Test przekierowań na liście, a nie na oko

Przekierowań nie da się sprawdzić, klikając w kilka podstron. Potrzebna jest cała lista starych adresów z arkusza inwentaryzacji i narzędzie, które odpyta każdy z nich i zapisze kod odpowiedzi oraz adres docelowy. Na wersji testowej robimy to z tymczasowym podpięciem domeny, a w dniu publikacji powtarzamy na żywym serwisie. Wynik porównujemy z mapą. Każda różnica to wiersz do poprawy.

Zapisz wyniki sprawdzenia i listę elementów wymagających poprawy. Ustal, kto zatwierdza publikację i kto może zareagować na problem po zmianie, włącznie z numerem telefonu do osoby, która ma dostęp do serwera.

Dzień przełączenia i plan wycofania zmiany

Ustal kopię dotychczasowej strony oraz konfiguracji, sposób przeniesienia nowych danych i odpowiedzialność za domenę oraz hosting. Kopia obejmuje pliki, bazę danych, ustawienia serwera i rekordy DNS. Zrób ją tuż przed przełączeniem, a nie tydzień wcześniej, bo w tym tygodniu mogły przyjść zapytania i zamówienia.

Przed przełączeniem

• Sprawdź, kto ma dostęp do panelu domeny i hostingu, i czy loginy działają. Dostęp odkrywany w dniu publikacji to najczęstsza przyczyna przesunięcia terminu.
• Jeśli zmienia się serwer, obniż wcześniej czas ważności rekordów DNS (TTL), żeby zmiana rozeszła się szybciej.
• Ustal porę. Nie przełączaj w piątek po południu ani w dniu wysyłki kampanii. Wybierz dzień, w którym osoba techniczna i osoba od zapytań są dostępne.
• Zamroź zmiany na starej stronie. Każda aktualność dodana po zrobieniu kopii zginie.
• Jeżeli w czasie prac napływają zamówienia lub zapytania, określ, jak uwzględnić je przy uruchomieniu nowej wersji. Do wyboru jest ręczne przepisanie, eksport i import albo chwilowe wyłączenie formularza z komunikatem.

Bezpośrednio po przełączeniu

Przygotuj listę czynności wykonywanych od razu po publikacji. Wejdź na dziesięć najważniejszych adresów. Wyślij testowe zgłoszenie z formularza i sprawdź, czy dotarło. Uruchom sprawdzenie przekierowań na całej liście. Sprawdź, czy strona nie ma znacznika blokującego indeksowanie. Zgłoś nową mapę witryny w Search Console. Sprawdź, czy analityka rejestruje wejścia. Otwórz stronę na telefonie z sieci komórkowej, poza firmowym Wi-Fi.

Przy zmianie domeny dodaj nową domenę do Search Console i użyj narzędzia zmiany adresu, które Google opisuje w przewodniku o przenoszeniu witryny. Zaktualizuj link w wizytówce Google, w profilach społecznościowych, w kampaniach reklamowych i w podpisach mailowych. Stara domena ma zostać opłacona i przekierowywać jeszcze długo, o czym piszemy niżej.

Komunikacja z klientami

Przy zmianie domeny albo wyglądu uprzedź stałych klientów. Krótki mail od właściciela z nowym adresem i informacją, gdzie teraz są pliki do pobrania, oszczędza telefonów w pierwszym tygodniu. Zmień adres na fakturach, w ofertach i w szablonach maili. Jeśli klienci logują się do panelu albo sklepu, wyślij osobną wiadomość z informacją, czy hasła zostają. Wpis w mediach społecznościowych to dodatek, a nie podstawowy kanał, bo większość klientów go nie zobaczy.

Plan wycofania

Plan wycofania to decyzja, kiedy wracasz do starej wersji, i instrukcja, jak to zrobić. Ustal próg. Formularz nie działa i nie da się go naprawić w godzinę, strona nie ładuje się na telefonie, połowa adresów zwraca 404. Instrukcja opisuje przywrócenie kopii, zmianę DNS z powrotem i to, kto o tym decyduje.

Plan wycofania powinien uwzględniać także dane przyjęte już przez nową stronę. Jeśli przez trzy godziny nowa wersja zbierała zapytania, po powrocie do starej te zapytania muszą zostać ręcznie przekazane osobie od obsługi. W sklepie dotyczy to zamówień i jest powodem, dla którego powrót do starej wersji bywa gorszy niż naprawa na żywo.

Co obserwować po zmianie i jak długo

Pierwsze dni po migracji to sprawdzanie, czy nic nie jest zepsute. Kolejne tygodnie to obserwacja, jak Google i klienci przyjmują nową wersję. Te dwie rzeczy wymagają innych raportów.

Pierwszy tydzień

Sprawdzaj błędy adresów w raporcie „Strony” w Search Console. Pojawią się tam adresy, które zwracają 404, oraz te z przekierowaniem, i to jest normalne. Nienormalne jest, gdy wśród błędów 404 są strony z mapy, które miały dostać przekierowanie. Sprawdzaj indeksowanie nowych podstron oraz napływ zapytań w porównaniu z tygodniem przed zmianą. Zajrzyj do logów serwera albo raportu błędów, jeśli hosting je udostępnia.

Kolejne tygodnie

Gdy wynik się zmienia, porównaj konkretne strony i źródła wejść. Sama łączna liczba odwiedzin może nie wyjaśnić problemu. Spadek łącznych wejść przy stabilnej liczbie zapytań oznacza zwykle utratę stron, które przynosiły ruch bez wartości. Spadek zapytań przy stabilnym ruchu oznacza problem z formularzem, kontaktem albo treścią oferty. Porównuj adres do adresu, korzystając z arkusza, który zrobiłeś przed migracją.

Wahania pozycji po migracji są spodziewane i Google o tym uprzedza. Trwałe pogorszenie dla konkretnej strony po kilku tygodniach to sygnał, że przekierowanie prowadzi do słabszego odpowiednika albo treść została mocno skrócona. Wtedy wracasz do mapy i poprawiasz pojedynczy wiersz, a nie całą stronę.

Jak długo utrzymywać przekierowania

Google zaleca, żeby przekierowania zostały na serwerze tak długo, jak to możliwe, co najmniej przez rok. Tyle potrzebuje, żeby przenieść sygnały z linków na nowe adresy. W naszym doświadczeniu bezpieczniej jest nie usuwać ich wcale. Stara domena po rebrandingu też ma być opłacana i przekierowywać, bo linki z katalogów branżowych i starych artykułów nie znikną.

Zachowaj dokumentację zmian, żeby łatwiej powiązać obserwacje z wdrożeniem. Data przełączenia, lista przekierowań, lista usuniętych stron i lista rzeczy zmienionych w pierwszym tygodniu. Za rok, przy kolejnej zmianie, ten dokument oszczędzi dzień dochodzenia.

Kiedy migracja jest zakończona

Migrację uznajemy za zamkniętą, gdy spełnione są cztery warunki. W raporcie „Strony” nie ma błędów 404 dla adresów z mapy. Nowe podstrony z mapy witryny są zaindeksowane. Liczba zapytań z formularzy i telefonów wróciła do poziomu z punktu odniesienia albo różnicę da się wyjaśnić sezonem. Firma ma dostępy, mapę przekierowań i wie, kto odpowiada za serwer. Do tego momentu obserwacja jest częścią wdrożenia. Później staje się częścią opieki nad stroną, którą ustala się osobno.

Najczęstsze błędy i co kosztują

Każdy z poniższych błędów widzieliśmy przy stronach, które trafiały do nas do naprawy po migracji zrobionej gdzie indziej. Większość wynika z pośpiechu w ostatnim tygodniu.

• Wszystko na stronę główną. Najprostsze do wdrożenia i najgorsze w skutkach. Klient z linku do konkretnej usługi ląduje na ogólnej stronie i wychodzi. Google traktuje to jak zniknięcie strony.
• Blokada indeksowania z wersji testowej na produkcji. Strona wygląda dobrze, formularze działają, a po dwóch tygodniach znika z wyników. Koszt to tygodnie odbudowy widoczności.
• Zapomniane pliki. Katalog PDF z linku w stopce maili handlowców zwraca 404 przez miesiąc, zanim ktoś z klientów to zgłosi.
• Brak dostępu do domeny. Domena jest na koncie dawnego wykonawcy albo byłego wspólnika. Odzyskanie dostępu trwa tygodnie i zatrzymuje publikację gotowej strony. Jak to sprawdzić zawczasu, opisujemy w poradniku o tym, co przygotować przed zleceniem strony.
• Łańcuchy z poprzednich migracji. Trzecia przebudowa w historii firmy dziedziczy przekierowania z dwóch poprzednich. Nikt ich nie sprawdza, a część prowadzi w kółko.
• Zmiana wszystkiego naraz bez potrzeby. Nowy system, nowa domena, nowa struktura i nowe treści w jednym dniu. Gdy coś spada, nie wiadomo, co to spowodowało. Jeśli zmiana domeny nie jest konieczna, zrób ją osobno.
• Analityka na nowej stronie od zera. Nowe konto GA4 zamiast tego samego oznacza brak porównania z okresem sprzed migracji.
• Brak kopii albo kopia sprzed tygodnia. Powrót do starej wersji jest niemożliwy albo gubi tydzień zapytań.
• Przełączenie w piątek. Problem wychodzi w sobotę, a osoba z dostępem do serwera wraca w poniedziałek.

Jak przenosimy strony w ADREAMS

Migrację i przekierowania uwzględniamy w zakresie wdrożenia strony WWW, gdy budujemy nową wersję istniejącego serwisu. Jest to część czterech etapów, które przechodzimy przy każdej stronie. Poniżej to, co w każdym z nich dotyczy przenoszenia.

Cel i zakres

Prosimy o dostęp do Search Console i analityki obecnej strony albo o eksport danych, jeśli wolisz nie dawać dostępu. Robimy inwentaryzację adresów i plików. Pytamy, gdzie poza stroną widnieją jej adresy: reklamy, druki, wizytówka Google, podpisy. Sprawdzamy, kto zarządza domeną i hostingiem. Z tego powstaje lista stron do zachowania i wstępna decyzja o tym, czy adresy się zmienią.

Treści i projekt

Projektując nową strukturę, od razu zapisujemy, dokąd trafi każdy stary adres. Mapa przekierowań powstaje razem z mapą strony, a nie po projekcie. Przy tej okazji decydujemy, które treści przenosimy bez zmian, które przepisujemy, a które usuwamy z kodem 410. Ty zatwierdzasz te decyzje, bo wiesz, które stare podstrony klienci jeszcze dostają od handlowców.

Wdrożenie i sprawdzenie

Wdrażamy przekierowania na serwerze, osobno reguły ogólne i osobno mapę podstron. Na wersji testowej przechodzimy listę kontrolną z tego poradnika, testujemy przekierowania na całej liście adresów i wysyłamy zgłoszenia ze wszystkich formularzy. Dostajesz wersję do obejrzenia i arkusz z wynikami testów.

Publikacja i przekazanie

Uzgadniamy dzień i godzinę przełączenia, robimy kopię, przełączamy i przechodzimy listę „bezpośrednio po publikacji”. Zgłaszamy mapę witryny i, przy zmianie domeny, nowy adres w Search Console. Przez pierwsze tygodnie sprawdzamy raporty błędów i porównujemy najważniejsze adresy z punktem odniesienia. Przekazujemy dostępy, mapę przekierowań i instrukcję obsługi. Opiekę po publikacji, w tym dalszą obserwację, ustalamy osobno.

Pytania, które możesz zadać każdemu wykonawcy

1. Jak zrobicie listę obecnych adresów i skąd weźmiecie dane o ruchu?
2. Czy dostanę mapę przekierowań do zatwierdzenia przed wdrożeniem?
3. Jak przetestujecie przekierowania: ręcznie czy na całej liście?
4. Co z plikami PDF i obrazami, do których linkują maile i materiały drukowane?
5. Kto robi kopię przed przełączeniem i jak wygląda powrót do starej wersji?
6. Kto będzie dostępny w dniu przełączenia i dzień później?
7. Co dostanę po publikacji: listę przekierowań, dostępy, instrukcję?
8. Jak długo i w jakim zakresie obserwujecie stronę po zmianie?

Jeśli wykonawca odpowiada „przekierowania zrobią się same” albo „to sprawa pozycjonera”, zakres migracji nie jest w ofercie. Ogólny obraz zamawiania strony w regionie znajdziesz w przewodniku po stronach internetowych dla firm z Wielkopolski. Jeśli zmiana systemu jest częścią decyzji, pomocny będzie też poradnik WordPress czy własny kod.

Słownik pojęć z migracji

• Adres (URL): pełna ścieżka do podstrony lub pliku, na przykład adreams.pl/uslugi/strony-www. Zmiana choćby jednego znaku tworzy nowy adres.
• Przekierowanie 301: stała odpowiedź serwera, która wysyła przeglądarkę i Google na nowy adres i prosi o przeniesienie sygnałów.
• Przekierowanie 302: tymczasowa wersja przekierowania. Nie służy do migracji.
• Kod 404: strona nie istnieje. Kod 410: strona została celowo usunięta.
• Łańcuch przekierowań: adres A prowadzi do B, a B do C. Spowalnia ładowanie i gubi sygnały.
• Adres kanoniczny: wskazanie w kodzie strony, która wersja adresu jest właściwa, gdy ta sama treść jest dostępna pod kilkoma.
• Mapa witryny (sitemap.xml): plik z listą adresów, które Google ma odwiedzić. Po migracji ma zawierać tylko nowe adresy.
• robots.txt: plik z regułami, które katalogi roboty mogą odwiedzać. Blokada skopiowana z wersji testowej potrafi wyłączyć całą stronę z wyników.
• noindex: znacznik w kodzie strony, który prosi Google o nieindeksowanie. Na wersji testowej konieczny, na publicznej groźny.
• DNS i TTL: system, który tłumaczy nazwę domeny na adres serwera, oraz czas, przez jaki ta informacja jest zapamiętywana. Niski TTL przed zmianą serwera przyspiesza przełączenie.
• Google Search Console: bezpłatne narzędzie Google, które pokazuje, jak Google widzi stronę: zaindeksowane adresy, błędy, kliknięcia z wyników.
• Wersja testowa (staging): kopia nowej strony pod adresem niedostępnym dla klientów i Google, na której robi się testy.

TL;DR

• Ustal, czy zmieniasz projekt, system, domenę czy hosting. Każdy przypadek ma inną listę ryzyk.
• Zrób inwentaryzację adresów z trzech źródeł i zapisz dane o ruchu i zapytaniach jako punkt odniesienia.
• Każdy stary adres dostaje jeden nowy odpowiednik z treścią, a nie stronę główną. Adresy, które można zachować, zachowaj.
• Do migracji służy 301. Strony usunięte celowo dostają 410. Unikaj łańcuchów.
• Pliki, formularze, skrypty i zgody przechodzą razem z adresami i są testowane osobno.
• Przekierowania testuj na całej liście, a blokadę indeksowania zdejmij przed publikacją.
• Zrób kopię tuż przed przełączeniem, ustal próg wycofania i co zrobić z danymi przyjętymi przez nową stronę.
• Po publikacji porównuj adres do adresu, a przekierowania zostaw na serwerze co najmniej rok.

FAQ