Migracja strony internetowej a SEO

Pod koniec 2019 roku miałem przyjemność wystąpić po raz pierwszy w roli prelegenta. Wiedząc, że uczestnicy konferencji WordCamp to głównie osoby związane ze środowiskiem WordPress’a, które zajmują się tworzeniem i administracją stronami internetowymi – uznałem, że ciekawym tematem będzie migracja strony internetowej oraz jej wpływ na widoczność w Google. Aspekty związane ze zmianą strony internetowej, są na tyle rozbudowane, że ciężko było zmieścić się z tym w 18 minutach (co finalnie się nie udało) 🙂 Między innymi z tego powodu postanowiłem stworzyć ten artykuł. 

Dodatkowo zebrałem informacje od organizatorów – pytania zadawane przez aplikację PWA a których nie było czasu zadać na koniec dnia (z uwagi na duża liczbę prelegentów i ogromnym oporem czasu podczas próby go rozciągania – jakby nie próbować, to minuta to tylko 60 sekund 🙂 ). 

Migracja strony internetowej – czym jest i po co to robimy?

Podczas swojego wystąpienia mówiłem, że zanim zaczniemy cokolwiek działać w aspekcie migracji – konieczny jest maksymalnie rozbudowany wywiad na ten temat. Warto dowiedzieć się od zleceniodawcy takich informacji, jak m.in.:

• co jest powodem migracji (zmiana strony na nowszą, zmiana brandu czy może połączenie brandu z innym – każdy powód ma wpływ na nasze dalsze działania)

• czy będziemy przenosili architekturę w identycznej formie (spłycenie architektury ma ogromny wpływ na widoczność serwisu po migracji)

• czy treści zostaną przeniesione na nowy serwis, a jeśli nie to kto odpowiada za tworzenie treści i jaki jest tego plan

• kto bierze udział w procesie migracji? Warto wiedzieć kto należy do zespołu projektowego. Wiedza kto za co odpowiada – bardzo ułatwia koordynację działań

• jakie były dotychczasowe cele na stronie (także w kontekście głównych celów biznesowych)? W przypadku rozbudowanej analityki, konieczne będzie dopilnowanie, że wszelkie analizowane wcześniej zadania i eventy będą przeniesione na nową stronę

• jaka forma raportowania interesuje zleceniodawcę i na jakich parametrach zależy mu najbardziej (coraz rzadziej klienta interesuje tylko utrzymanie ruchu)

Na podstawie tych informacji możemy nie tylko zaplanować działania, ale i uświadomić klienta, na czym będzie polegała migracja, z czym się wiąże oraz jakie niesie ryzyko.

Przygotuj klienta do migracji jego strony internetowej

Bardzo często powodem punktów spornych po migracji jest brak tej wiedzy po stronie zleceniodawcy. Jeśli ktoś nie zajmuje się na co dzień działaniami związanymi z SEO, bardzo często traktuje migrację jako proste działanie – wyłączenie starej strony i włączenie nowej. Szczególnie polecam na samym początku wyprowadzić klienta z błędu.

Jest wiele aspektów, które warto przedyskutować ze zleceniodawcą – przedstawię kilka, które osobiście uważam za ważne.

Na migracji praca się nie kończy

Często spotykam się z opinią, że wystarczy przełączyć stronę i już wszystko gotowe. Możemy od razu wyciągać wnioski – czy aby na pewno? Taka opinie wiąże się z brakiem wiedzy na temat działania wyszukiwarki internetowej, jaką jest Google. Pierwszym powodem tego, że nie dzieje się to od ręki – Google potrzebuje czasu na przeindeksowanie serwisu. 

Teraz czas na ulubione pytanie, czyli – jak szybko Google to zrobi i będzie już stabilnie? W tym momencie następuje ulubiona odpowiedź w branży SEO. Odpowiedź brzmi “to zależy”. Ma na to wpływ m.in.:

• wielkość serwisu

• crawl budżet

Pewne jest to, że nie działa to “od ręki”.

Migracja ma wpływ na ruch

Migracja strony internetowej nie musi, ale może wpłynąć negatywnie na jej widoczność w Google. Od czego to zależy? W mojej ocenie od tego jak wyglądała poprzednia strona, jaka jest nowa oraz na ile się różnią. Dla większości osób to zdanie mówi niewiele, dlatego bardziej to rozpiszę. Czynniki, które mają duży wpływ podczas zmian, to głównie architektura oraz content.

Architektura strony – a po co komu tyle podstron?

Tworzenie nowej wersji strony to bardzo często okazja do pozbycia się wielu podstron serwisu. Właściciele stron przy okazji projektowania nowej strony – często podejmują decyzję, o zbudowaniu dużo mniejszej architektury. W końcu ich klienci często sami wiedzą co chcą kupić lub jaką usługę zlecić. Jeśli wcześniej ktoś napracował się podczas budowania odpowiednich landing page, które generowały ruch organiczny – zastąpienie ich linijką lub nawet akapitem treści w zakładce /oferta, skończy się bardzo źle. 

Przed podjęciem decyzji dt. odwzorowania podstron, sprawdź dokładnie, jakie adresy generowały ruch organiczny. Aby to zrobić wystarczy dostęp do Google Search Console oraz Google Analytics.

Oprócz adresów widocznych w Google Analytics, bardzo wartościowym raportem jest lista najczęściej klikanych adresów w Google Search Console. 

Kwestia tego, czy należy wszystko odbudowywać jest zawsze dyskusyjna. Często przed taką decyzją analizuje się zasadność klikanych adresów i ich wpływ na biznes. Ale by to zrobić, trzeba najpierw przygotować takie dane.

Content w serwisie – a może zastąpić go ładnym banerem?

Nawet gdy zachowamy najważniejsze podstrony starego serwisu, to musimy pochylić nad ich zawartością tekstową. Bez tego możemy i tak utracić ruch. Należy brać pod uwagę, że Google Bot odczytuje zawartość strony po jej treści (widocznej w kodzie HTML). Co to oznacza? To, że jeśli rozbudowaną treść zastąpimy jednym zdaniem (dodatkowo wzbogaconym ładnym banerem czy też infografiką) – mamy duża pewność, że adres ten utraci ruch z wyszukiwarki. 

Ile zatem powinna mieć treść? To sprawa indywidualna i wymaga to dokładnej analizy per adres i weryfikacji jaka jest intencja wyszukiwania. Można to zrobić analizując wyniki SERP oraz badając strony wysoko rankujących serwisów. W przypadku podstrony, która odpowiada zapytaniu o intencji informacyjnym – usunięcie rozbudowanego artykułu, spowoduje gorszą oceną w oczach Google. Zazwyczaj najbezpieczniejszymi migracjami są te, gdzie treść przenoszona jest 1:1.

Oczywiście można pójść inną drogą. W przypadku, gdy stary serwis miał mało treści, a z analizy przypadku wynika, że powinna być ona dłuższa i lepiej zoptymalizowana – możemy we współpracy ze specjalistą SEO, przygotować nową treść. W takim przypadku zmiana treści jest zasadna i powinna pozytywnie wpłynąć na widoczność nowej strony.

Harmonogram prac jest bardzo ważny

Już na etapie przygotowania się do migracji, dowiedzieliśmy się z kim działamy przy tym projekcie (a na pewno powinniśmy). Ta informacja będzie bardzo przydatna przy tworzeniu harmonogramu działań i skonsultowaniu tego z ekipą projektową po stronie zleceniodawcy. Musimy upewnić się, że każdy zna ten harmonogram, potwierdza zaplanowane tam terminy i kolejność działań. Naszym zadaniem jest uświadomienie każdego, jak to ważne. Sytuacja, gdy sami zauważamy na produkcji nową stronę a nie skończyliśmy jeszcze analizy środowiska testowego oraz mapy przekierowań – generuje ogromną frustrację…

Zabezpiecz środowisko testowe

Pierwszym co w mojej ocenie należy wykonać, gdy rozpoczynamy przygotowanie do migracji – odpowiednie zabezpieczenie środowiska testowego przed indeksowaniem w Google.

Tag NOINDEX

Najczęściej wybieranym sposobem, jest w tym przypadku dodanie do sekcji <head> każdej podstrony w serwisie tagu NOINDEX. 

Obecność tego tagu jest respektowanym przez Google sposobem na jasną informację – “nie chcemy, by podstrony znalazły się w indeksie Google”. Google Bot gdy dotrze do środowiska testowego, nie zaindeksuje go. 

Więcej informacja prosto od Google: https://support.google.com/webmasters/answer/93710?hl=pl 

Blokada poprzez hasło

Innym często stosowanym sposobem zabezpieczenia nowo budowanej strony, jest dodanie hasła. Google nie zna hasła i nie dotrze do zawartości serwisu testowego. Nawet, gdy decydujemy się na użycie tagu NOINDEX, to w momencie potrzeby przeanalizowania przypisania do danej taksonomii indeksowania / nieindeksowania – warto przejść na hasło (wyłączając odgórne przypisanie NOINDEX wszędzie). Możemy wtedy użyć crawlera, który obsługuje wejście przez hasło (np. screaming frog) i sprawdzić, czy nie nowa strona nie będzie miała ustawione NOINDEX dla podstron ofertowych.

Dlaczego nie robots.txt?

Podczas migracji często pada pytanie – czy nie wystarczy blokada w robots.txt? Odpowiedź brzmi – nie. To jest tylko sugestia i często jest tak, że Google Bot i tak odwiedza takie strony. Indeksuje je w wyszukiwarce i zamieści pod wynikiem informacje o blokadzie w robots.txt. 

Dokonaj analizy starej strony

Gdy zabezpieczymy odpowiednio środowisko testowe, możemy zająć się obecną stroną klienta. Warto zarówno dokonać jej crawlu, jak i przeanalizować jej parametry w GA, GSC oraz zewnętrznych narzędziach. Wcześniej opisywałem kwestie, które należy ustalić z klientem. Jedną z nich była kwestia celów i oczekiwań. Na tym etapie przygotowań warto przeanalizować na jakim etapie budowania widoczności jest stara strona oraz jak wygląda lista analizowanych w GA czynników – takich jak realizowane cele, wielkość sprzedaży etc.

Mapa adresów URL

W przypadku małych stron firmowych analiza ta kończy się na crawlu serwisu i zapisaniu mapy adresów URL, ich meta tagów (oraz treści) + weryfikacji ruchu w GA i GSC. 

Crawl tak małego serwisu możemy wykonać samodzielnie na darmowej wersji Screaming Frog’a.

Co w przypadku, gdy mamy do czynienia z dużym e-commerce lub rozbudowanym serwisem internetowym? Pomijając fakt potrzeby wykupienia licencji SF (lub wyboru innego crawlera), musi ustalić priorytety. Migrując ogromny serwis ciężko będzie analizować każdą podstronę osobno i budować ogromne mapy przekierowań dla adresów totalnie nieistotnych z punktu widzenia użytkownika i ruchu z Google.

Jeśli szukasz softu do crawlowania stron www, to oprócz Screamin Frog’a jest wiele innych, takich jak np.:

Najważniejsze adresy – ruch i sprzedaż

Pierwsze co powinniśmy zweryfikować, to jakie adresy URL dostarczają ruch. Ja zawsze zaczynam od tych, które mają największy wpływ i przechodzę kolejno do tych mniej istotnych. 

Podobną analizę należy wykonać w kontekście wartości tych adresów (sprzedaż e-commerce oraz realizacja celów). Nie możemy dopuścić do sytuacji, że jakaś podstrona zostanie pominięta z uwagi na dość niski ruch, a przynosiła ona duży dochód.

Analiza linków do serwisu

Dokonanie mapy serwisu jest ważne z uwagi na potrzebę odwzorowania ważnych podstron oraz przekierowania ich na nowe adresy URL. Nie można jednak zapominać tutaj o linkach prowadzących do strony. Ich obecność to bardzo ważny czynnik rankingowy.

Dlaczego należy przekierować adresy, na które wskazują linki zewnętrzne? Jeśli tego nie zrobimy a zmieniła się budowa adresów URL – będą one kierowały do podstron z odpowiedzią serwera 404. Takie linki nie są brane pod uwagę podczas oceny strony przez Google. 

Listę podlinkowanych zewnętrznie adresów możemy wygenerować w oparciu o dane z Google Search Console (zakładka Linki).

Dodatkowo warto posiłkować się także zewnętrznymi narzędziami takimi, jak np. Clusteric, Majestic czy też Ahrefs.

Im więcej narzędzi użyjemy, tym nasza adresów będzie bardziej precyzyjna. 

Skorzystaj z środowiska testowego

Dostęp do środowiska testowego to duża szansa na wyeliminowanie wielu istotnych błędów. Możemy już na tym etapie zweryfikować tak istotne aspekty, jak omawiane wcześniej – architektura, treść czy też przeniesienie ustawień optymalizacyjnych. 

Weryfikacja przed “wrzuceniem na produkcję”

W wielu przypadkach mimo zapisania i przesłania wytycznych dt. w/w parametrów podstron, na środowisku testowym nie jest to przeniesione. Ważne, by wszelkie niedociągnięcia poprawiać jeszcze na etapie środowiska testowego. Poprawki na wersji produkcyjnej to pewna walka z czasem – nawet, gdy zauważymy błędy szybko, Google Bot może być od nas szybszy. 

Przygotowanie mapy przekierowań

Wspominałem wcześniej o konieczności mapowania serwisu oraz zapisaniu adresów, które są podlinkowane zewnętrznie. Teraz te wszelkie dane będą potrzebne do przygotowania mapy przekierowań z użyciem przekierowań 301.

Najbardziej optymalną mapą jest ta, z użyciem schematów przekierowań. Jest to jednak dość rzadko spotykane. Możliwe jest to, gdy np. nazwa katalogu zmienia się – np. z /produkty/nazwa-produktu na /oferta/nazwa-produktu . W przypadku, gdy zmienia się element adresu a reszta jest bez zmian, możemy użyć schematu przekierowań w .htaccess . Podczas ładowania strony serwer nie musi sprawdzać adresu po adresie (długiej listy z mapy przekierowań) a jedynie 1 warunek. Jeśli nie da się znaleźć schematu, trzeba budować mapę przekierowań ręcznie.

Po przygotowaniu takiej mapy warto zweryfikować, czy jej wdrożenie jest prawidłowe. Do tego celu możemy użyć dowolny soft, który sprawdza status odpowiedzi serwera i jeśli są tam kroki przekierowań, wyświetli szczegóły. 

Jednym z nich jest program HTTP Status dostępny pod adresem: https://httpstatus.io/ 

Pamiętaj, że wrzucenie na produkcję to nie koniec

Wszelkie analizy na środowisku testowym dają nam szansę ograniczyć ryzyko jakiegoś błędu, ale nigdy “do zera”. W części omawiającej przygotowanie klienta, wspominałem o harmonogramie działań. Jest to ważne, by przestrzegać tam ustalonych terminów. 

Wrzucanie nowej wersji strony na serwer bez konsultacji i ustalenia tego z opiekunem migracji – może wyrządzić wiele szkody. Nie mamy szansy od razu weryfikować, jak migracja wpływa na widoczność. 

Natychmiast po migracji należy prze audytować stronę i sprawdzić m.in.:

Powielamy część działań, które już robiliśmy na środowisku testowym ale naprawdę warto sprawdzić to jeszcze raz. Strona na produkcji może “zachowywać się” inaczej oraz musimy mieć świadomość, że w ostatniej chwili ktoś mógł nanieść ostateczne poprawki. Bywa, że poprawki zaburzają inne funkcjonalności serwisu. 

Jednym z dość często spotykanych błędów podczas migracji, jest przeniesienie serwisu wraz z ustawionym wszędzie tagiem NOINDEX. Skutek tego jest taki, że Google bardzo szybko zacznie wyindeksowywać stronę. To tylko jeden z wielu powodów, z powodu których warto weryfikować serwis zaraz po migracji.

W sytuacji, gdy mamy już wdrożoną stronę i Google ma już do niej dostęp (nie jest ona zablokowana) – mamy możliwość weryfikacji w jaki sposób Google ją renderuje, poprzez sprawdzenie adresu URL w Google Search Console.  

W przypadku serwisów budowanych na technologii, która budzi niepewność co do tego, czy Google sobie poradzi z renderowaniem – warto nie czekać do tego momentu. Więcej na ten temat w części z odpowiedziami na pytanie uczestników WordCamp.

Podsumuj wyniki migracji

Po migracji nadchodzi moment, gdy możemy przeanalizować efekty naszych prac i przygotować z tego raport. Co w nim umieścić? Najlepiej to na czym zależało klientowi i powiedział nam to podczas przygotowań. Właśnie dlatego zawsze warto dokładnie przygotować się do tego procesu. Co najczęściej jest weryfikowane przy stronach innych niż e-commerce (tam dochodzi jeszcze do tego kwestia wpływu na sprzedaż)?

Jeśli dość często zajmujemy się migracjami stron, to warto zautomatyzować proces raportowania. Warto do tego wykorzystać narzędzie Google Data Studio. Dlaczego warto wybrać to rozwiązanie? Daje szansę zebrania i przedstawienia w jednym miejscu danych z wielu źródeł.

Jeśli nie możesz poradzić sobie z konfiguracją lub masz jakieś pytania dt. Google Data Studio – polecam grupę na FB https://www.facebook.com/groups/2306809709574011/ . Jest to miejsce, gdzie znajdziecie wsparcie wielu fachowców od Google Data Studio.

Podsumowanie oraz Q & A

Planując temat wystąpienia oraz opisując to w tym artykule – chciałem naświetlić pewien problem. Mimo, iż świadomość dotycząca zasad działania Google oraz podstaw SEO (koordynacje migracji i konsultowanie tego ze specjalistą SEO, uważam za absolutne podstawy) wciąż rośnie – nadal dostrzegam totalne lekceważenie oraz objawy braku wiedzy. Moim zdaniem zupełnie bez sensu jest stracić podczas migracji efekty wielu lat działań SEO i ogromu pieniędzy w to zainwestowanych. Mam nadzieję, że poprzez moje wystąpienie oraz ten artykuł, udało mi się uchronić kogoś przed błędnymi decyzjami.

Odpowiedzi na pytania z aplikacji PWA

Poniżej zawarłem odpowiedzi na zadane pytania po moim wystąpienia.

1.Jakiego narzędzia/programu warto użyć do mapy przekierowań?

Na to pytanie miałem szansę odpowiedzieć jeszcze w dniu prezentacji ale uznałem, że zamieszczę ją także w artykule. Pytanie jest na tyle ogólne, że bez wiedzy kto je zadał i dopytania – ciężko sprecyzować, o jakie wsparcie narzędziem chodzi. Wraz z innymi prelegentami doszedłem do wniosku, że może chodzić o wykorzystanie jakiegoś programu do uruchomienia przekierowań. 

W mojej ocenie najlepszy do tego arkusz kalkulacyjny (kolumna ze starymi adresami oraz ich nowymi wersjami) a potem wykorzystania tego podczas wdrażania tego np. poprzez .htaccess. Jeśli nie mamy wystarczającej wiedzy na temat tego pliku, warto skorzystać z pomocy osoby, która się w tym specjalizuje. Wystarczy popełnić mały błąd (np. literówka) i strona przestaje działać. To co mogę poradzić, to wykonaj zawsze kopię zapasową .htaccess 🙂

W poszukiwaniu wiedzy na temat ustawienia przekierowań w .htaccess – polecam poradniki wielu firm hostingowych np. https://www.kei.pl/pomoc/przekierowanie-301-htaccess . Dobrym pomysłem jest też skontaktowanie się z supportem naszego hostingodawcy. Często są to specjaliści, którzy służa pomocą.

Jest też alternatywne rozwiązanie, gdy mamy stronę na WordPress. Możemy wtedy użyć takich wtyczek, jak np. https://pl.wordpress.org/plugins/redirection/ .

Należy jednak pamiętać, że nie mamy wpływu na ciągłość funkcjonowania i wsparcia dla wtyczek. Dziś działają, ale mogą być z czasem niewspierane i przestać działać. Jak już chcesz korzystać z wtyczek, zapisuj gdzieś każde dodane przekierowanie. W przypadku jakiejś awarii masz szansę szybko wdrożyć przekierowania w inny sposób.

2.Jak nie stracić punktów SEO, gdy tworzymy nowa stronę pod tą samą domeną?

Myślę, że najlepszą odpowiedzią na to pytanie – będzie właśnie ten artykuł 🙂 

3.Googlebot bardzo różnie radzi sobie z indeksacją treści generowanych przez JS. Ma też problem z Reactem (bez SSR). Proponujesz analizę kodu indeksowanego przez Google w GSC dopiero po uruchomieniu na produkcji. Czy nie uważasz, że to zdecydowanie za późno, żeby dowiedzieć się o tak poważnym problemie? Czy znasz sposób na sprawdzenie jak Google będzie widział stronę bez konieczności jej indeksacji w wersji testowej?

To pytanie jest bardzo trafne i poruszające bardzo istotny aspekt – zdolność Google Bota do renderowania stron, które opierają się na technologii JS. Aby odpowiedzieć na to pytanie, należałoby wykonać test danego rozwiązania lub oprzeć się na takich wcześniejszych analizach, jak https://www.onely.com/blog/javascript-seo-experiment/ . Warto jednak brać pod uwagę ciągły rozwój Google. To, że opisana w w/w artykule technologia podczas testu nie umożliwiała dotarcia do zawartości Google Bot’owi – nie oznacza, że nadal tak jest.

Najlepszym sposobem jest zrobienie kopii budowanego serwisu. Tworząc e-sklep, budujemy tylko przykłady adresów z każdej taksonomii. Tworzymy np.:

• stronę główną

• kategorie

• karty produktu

• strony informacyjne

• wpisy blogowe

etc.

Oczywiście zupełnie zmieniamy treści, by nie było to potem duplicate content. Chodzi o to, by postawić testową stronę, która oparta jest o tą samą technologię. Taki testowy serwis możemy zweryfikować w Google Search Console i sprawdzić w jaki sposób się renderuje i czy Google dociera do treści oraz nawigacji.