Przeniesienie strony na WordPressa – checklista

W tym roku przebudowywałam jeden z serwisów contentowych postawionych na WordPressie. Nie licząc pojawiających się od pewnego czasu błędów Google (np. tych, przez które część podstron całkowicie zniknęła w Google), obyło się bez spadków pozycji i tym samym ruchu organicznego, który sięga ok. 500 tys. sesji miesięcznie. Postanowiłam przy tej okazji opublikować krótkie podsumowanie działań.

Czy wiesz, że w ciągu 2 minut możesz uzyskać dostęp do poniższego materiału?
Szkolenie: Zarabiaj na audytach SEO

Nową wersję strony przerzucałam 22 marca 2019 r. i ruch praktycznie nie drgnął mimo zmiany struktury części adresów URL. Poniżej widać wykres ruchu z okresu pełnego miesiąca od 5 marca do 5 kwietnia tak, aby okres błędów Google (na tej konkretnej stronie zauważalny od 7 do 10 kwietnia) nie zaburzył nam obrazu.

Statystyki ruchu organicznego - sesje

1. Prace przygotowawcze

Skrócona lista działań:

  • przygotowanie roboczej wersji strony
  • analiza treści z uwzględnieniem statystyk odwiedzin + jej przeniesienie
  • wybór motywu

Na czas prac na roboczej wersji strony ustawiłam noindex w zakładce Ustawienia -> Czytanie. To była wersja dostępna pod adresem w postaci nazwastrony.iq.pl (akurat na IQ.pl mam tamtą stronę, a dla chętnych podaję link partnerski do rejestracji).

Ustawienia czytania w WordPressie

Są różne sposoby na zabezpieczenie się przed dostępem robotów, jak i użytkowników do danej strony i w tym przypadku uznałam, że to wystarczy na krótki okres prac. Gdyby chodziło o jeden z głównych serwisów, w którym systematycznie wprowadzane są spore zmiany, zdecydowałabym się na osobną domenę z zakazem dostępu ustawionym w pliku .htaccess (tzw. blokada htpass), dzięki czemu jedynie osoby znające dane dostępu mogłyby dostać się na stronę. Wtedy nie byłoby potrzeby stosowania noindex, o zdjęciu którego można łatwo zapomnieć podczas przepinania strony.

Stara wersja strony korzystała z autorskiego, stworzonego wiele lat temu CMSa, więc zaczęłam od przeniesienia wszystkich treści. Część wpisów była już nieaktualna, a pojedyncze nie miały zbytnich szans na pozyskanie ruchu z wyszukiwarek ani nie były również wystarczająco dobre jakościowo, aby zainteresować czytelników. Zdecydowałam się więc na ich usunięcie. Zaledwie 1 z tych wpisów kwalifikował się do ustawienia przekierowania 301 na jego aktualny odpowiednik, czego dokonałam w kolejnym etapie prac nad stroną za pomocą wtyczki Redirection. Dodam, że wtyczka ta ma sporo przydatnych opcji, jest systematycznie aktualizowana i nawet w tej chwili widzę, że ostatnia aktualizacja miała miejsce 3 dni temu. Pamiętam jednak chwilowe błędy, które zostały naprawione przy kolejnych update’ach.

Po dokładnym przeanalizowaniu wszystkich wpisów i przeniesieniu ich na nową wersję strony, prace nad nią wydłużyły mi się przez nieodpowiedni wybór motywu. To niestety częsty problem, ponieważ tam gdzie na pierwszy rzut oka motyw graficzny wydaje się dobrze wyglądać i być elastyczny, może się okazać, że z elastycznością ma on niewiele wspólnego. Wersja, która mi się spodobała, była dostępna zarówno w wersji bezpłatnej, jak i płatnej. Ta pierwsza nie miała w ogóle możliwości dostosowania kolorystyki do własnych potrzeb, natomiast po zakupie płatnej okazało się, że jeden z dodatkowych elementów można wyłączyć jedynie na podstronach, a na stronie głównej jest obowiązkowy. Owszem, wszystko da się zmienić w kodzie, jednak nie o to chodziło, abym bawiła się godzinami w przerabianie motywu, tylko aby w miarę sprawnie przenieść stronę i abym nie traciła zapisanych zmian przy każdej aktualizacji motywu. Nie rozpisując się dłużej na ten temat napiszę tylko, że zaczęłam poszukiwania od nowa i tym razem szybko znalazłam motyw, który wymagał zaledwie kilku zmian kosmetycznych, a wyglądał o niebo lepiej od poprzedniego.

2. Struktura adresów URL – zostawić starą czy ją przebudować?

Lista spraw do przemyślenia:

  • czy stara struktura była odpowiednia i warto starać się ją zachować?
  • a może wykorzystać tę okazję do ustawienia zupełnie nowej struktury adresów?
  • z jakiej skorzystać wtyczki, aby przekierować wszystkie zmienione URLe?

Pierwszy dylemat, jaki miałam, związany był ze strukturą adresów URLi, ponieważ nie było jak zachować w pełni starej struktury. Dawna struktura prezentowała się następująco:

  • podstrona statyczna: www.domena.pl/podstrona.php
  • podstrona kategorii nadrzędnej: www.domena.pl/kategoria-nadrzedna.php
  • podstrona podkategorii: www.domena.pl/podkategoria.php
  • podstrona wpisu: www.domena.pl/kategoria-nadrzedna/wpis.php LUB www.domena.pl/podkategoria/wpis.php (w dalszej części artykułu napiszę, dlaczego w tym przypadku dostępne były 2 rodzaje formatów adresów)

Dotychczas ciężko było mi analizować w Google Analytics ruch na podstronach samych kategorii nadrzędnych lub podkategorii, a także całego drzewa kategorii, ponieważ miały one identyczną strukturę adresów, a dodatkowo wszystkie adresy miały rozszerzenie .php. Oczywiście dało się to zrobić okrężną drogą, ale biorąc pod uwagę, że przenoszenia dokonywałam przed sezonem, mogłam sobie pozwolić na częściową zmianę adresów URL i tego rodzaju test. Przy zmianie całej struktury miałabym obawę, że pozycje nie zdążą się ustabilizować przed szczytem zainteresowania tą tematyką. To w zasadzie pierwsza taka sytuacja, ponieważ zazwyczaj nastawiałam się na masowe przekierowania 301, nawet jeśli cała struktura ulegała zmianie, ale też inaczej dobierałam czas wprowadzania takich zmian. Tym razem nieco mi się opóźniły, więc to był ostatni dzwonek na tego typu prace na stronie, żeby nie musieć z nimi czekać kilku miesięcy.

Jeśli chodzi o podstrony statyczne, nie miały większego znaczenia pod kątem SEO, więc obojętne mi było, czy adresy ulegną zmianie, czy też nie i nimi w tym wpisie nie będziemy sobie zawracać głowy. Jeśli chodzi o drzewo kategorii, planowałam zlikwidować jedynie rozszerzenie, a zatem kategoria miałaby adres w postaci www.domena.pl/kategoria-nadrzedna natomiast podkategoria – adres w postaci www.domena.pl/podkategoria Z tym jednak byłoby sporo zabawy, aby uwzględnić w adresie alias samej podkategorii, ale BEZ kategorii nadrzędnej. Przetestowałam bodajże 4 różne wtyczki i żadna się nie sprawdziła. Ostatecznie zdecydowałam się na zastosowanie poniższej struktury zawierającej pełną ścieżkę do podkategorii, tj.

  • podstrona kategorii nadrzędnej: www.domena.pl/kategoria-nadrzedna (rezygnacja z samego rozszerzenia .php)
  • podstrona podkategorii: www.domena.pl/kategoria-nadrzedna/podkategoria (rezygnacja z rozszerzenia i dopisanie kategorii nadrzędnej w URLu)

Więcej zagłębień kategorii nie było, więc taka struktura wydawała mi się być idealna.

Do przekierowania drzewa kategorii użyłam wspomnianej już wtyczki Redirection, która umożliwia m.in. grupowanie przekierowań. Osobne grupy zawierają przekierowania na nową strukturę kategorii nadrzędnych (likwidacja rozszerzenia) i podkategorii (utworzenie zagłębienia kategorii nadrzędnej i podkategorii, a także likwidacja rozszerzenia), a osobne – inne nieaktywne podstrony takie jak np. dawne stronicowania.

Przekierowania 301

Zdecydowanie największy ruch od zawsze generowały podstrony z wpisami, dlatego zależało mi na tym, aby nic na nich nie zmieniać. Problem w tym, że w starych wpisach miałam mały bałagan i do pewnego momentu do adresu wpisu był dodawany alias podkategorii, a z czasem – kategorii nadrzędnej. W pierwszej kolejności musiałam więc ustawić w zakładce Ustawienia -> Bezpośrednie odnośniki domyślną strukturę dla wpisów, która miała zawierać alias z kategorii nadrzędnej i alias z nazwy posta, z uwzględnieniem rozszerzenia .php Zapewne część czytelników zada sobie w tym miejsce pytanie – po co rozszerzenie i czemu akurat takie? Szczerze mówiąc nadal lubię, jeśli podstrony wpisów mają jakiekolwiek rozszerzenie w przeciwieństwie do drzewa kategorii, a .php akurat znajdowało się w starej strukturze (od kilkunastu lat), więc tak było najwygodniej.

Pozostały jeszcze wpisy, które – z powodu wspomnianych już błędów i niekonsekwencji – różniły się od siebie i nie można ich było „załatwić” jednym globalnym ustawieniem. Z pewnych względów zdecydowałam się wykorzystać do tego Permalink Managera, w którym mogłam wygodnie i w zupełnie dowolny sposób edytować wszystkie adresy bez konieczności zwiększania liczby przekierowań. Zmieniłam więc te, których struktura nie była zgodna z globalnie ustawioną (z podkategoriami w aliasie), aczkolwiek docelowo zamierzałam te pozostałe również przekierować, tyle że po sezonie. Zastosowałam także wtyczkę No Category Base (WMPL), aby pozbyć się z adresów stałego elementu „category” (lub innego w przypadku zmienionej nazwy).

Tak naprawdę kilka błędów popełnionych przeze mnie podczas przebudowy tej strony wynikała z tego, że odzwyczaiłam się grzebania w kodzie czy ustawieniach, a także miałam presję tego, aby szybko zmierzać do celu. W ostatnich latach skupiałam się na bardziej koncepcyjnej pracy, a tego typu robótki zlecałam na zewnątrz albo zostawiałam koledze z zespołu. To głównie z tego powodu zdecydowałam, aby wykorzystać okazję do przypomnienia sobie wszystkiego i wykonać wszystko samodzielnie. Jestem pewna, że osoby systematycznie pracujące nad wieloma stronami na WordPressie znalazłyby mniejszą liczbę wtyczek do uzyskania tego samego efektu. Ja jednak poradziłam sobie z tym tak, a nie inaczej, przez co uznałam, że warto podzielić się tymi informacjami w szczególności z mniej zaawansowanymi webmasterami/seowcami.

3. Przenosiny strony

Tak naprawdę punkt 2 realizowałam dopiero po przenosinach, jednak zdecydowałam się opisać go w pierwszej kolejności ze względu na to, że pojawiły się z nim pewne komplikacje. Aby finalna wersja strony działała, wykonałam następujące czynności:

  • zmiana kierowania domeny na nowy folder – strona miała pozostać na tym samym serwerze, co było wygodną i łatwą opcją, bo wystarczyło zmienić w ustawieniach domeny jej kierowanie na inny (roboczy dotychczas) folder, bez konieczności czekania na propagację DNSów domeny, co byłoby niezbędne przy przenosinach na inny serwer;
  • zmiana adresu strony w ustawieniach WordPressa – tego musiałam dokonać z poziomu PHPMyAdmina, do czego niezbędna była zmiana w 2 miejscach;
  • zmiana wersji PHP z 5.2 na 7.1 i sprawdzenie, czy wszystko poprawnie działa;
  • zdjęcie noindex – jedno z ważniejszych 😉
  • ustawienie wtyczek Redirection i Permalink Manager – szczegóły opisane w punkcie 2;
  • wstawienie kodu Google Analytics (w ustawieniach wtyczki All In One SEO Pack) i Google AdSense (to akurat zrobiłam we wtyczce do emisji reklam – Advanced Ads);
  • wstawienie pixela FB;
  • jednorazowe przeskanowanie linków wtyczką Link Checker, którą później wyłączyłam. Pozwoliła ona znaleźć błędne linki;
  • wgranie starego, zaktualizowanego pliku robots.txt;
  • aktualizacja zapisów w pliku .htaccess.

Aby przyspieszyć indeksację zmian, warto po wygenerowaniu mapy strony wgrać ją do Google Search Console, a w razie usunięcia wpisów (bez ich przekierowywania) wyindeksować je za pomocą tych narzędzi.

4. Monitorowanie błędów, zmian w ruchu i w pozycjach

Lista do monitorowania:

  • sprawdzenie listy TODO przygotowanej przed rozpoczęciem prac nad stroną;
  • monitorowanie stanu indeksacji;
  • monitorowanie błędów;
  • monitorowanie zmian w ruchu i pozycjach strony.

Aby mieć pewność, że nie pominęliśmy niczego ważnego, najlepiej jeszcze przed rozpoczęciem prac nad stroną spisać sobie wszystkie informacje na temat struktury strony (u mnie kilka podstron było stworzonych „ręcznie” ze względu na nietypowe potrzeby, więc nie były one dostępne w panelu administracyjnym), ustawień celów w GA (przy zmianie struktury adresów należy zaktualizować ścieżki celów), kodów śledzących, a w przypadku gdy weryfikacja własności strony w Google Search Console została wykonana poprzez wgranie pliku na dysk, trzeba pamiętać o jego zachowaniu. Samo zerknięcie do folderu głównego starej wersji strony pozwoli znaleźć dodatkowe pliki, które powinniśmy przenieść na nową wersję.

Do sprawdzenia stanu indeksacji i tego, czy udało nam się odpowiednio wdrożyć przekierowania, korzystam ze strony www.urlitor.com w połączeniu z rozszerzeniem do Google Chrome o nazwie Scraper. Listuję najpierw adresy wszystkich zaindeksowanych podstron, po czym masowo sprawdzam ich nagłówki HTTP, przy czym wspomniane narzędzie pokaże od razu ewentualne łańcuchy przekierowań.

Monitorujmy także pojawiające się na niej błędy, w wykryciu których pomogą niektóre wtyczki do WordPressa, sporo chodźmy po stronie i testujmy ją w taki sposób, jak gdyby był to nowy serwis i jakbyśmy musieli sprawdzić na nim każdy detal łącznie z poprawnym działaniem zapisu na newsletter czy z aktualizacją widocznego pod nim linka do polityki prywatności. Jeśli do strony miało dawniej dostęp kilka osób, na WordPressie warto skorzystać z możliwości nadania różnych uprawnień każdej z nich.

Następnie przez pewien okres należy szczególnie dokładnie analizować ruch na stronie z naciskiem na ewentualne spadki ruchu w różnych rodzajach podstron. Może się okazać, że są problematyczne rodzaje stron, np. drzewo kategorii, które jednak zostały nieprawidłowo lub nie w pełni przekierowane albo jednocześnie są dostępne zarówno pod starym, jak i nowym adresem. Nie da się przewidzieć działania i błędów w niektórych wtyczkach, a te lubią występować w szczególności, jeśli kilka wtyczek nadpisuje swoje ustawienia. Przy sezonowych serwisach najlepiej porównywać ruch organiczny do odpowiedniego okresu rok wcześniej, a nie jedynie do ostatniego miesiąca bądź kilku. Niezbyt dobrym pomysłem jest przeprowadzanie takich analiz w okolicach ruchomych świąt, ponieważ zaburza to widok i analizy, jeśli rok wcześniej Święto zaczynało się np. 2 tygodnie wcześniej. Poniżej prezentuję aktualny wykres zmian w ruchu organicznym w porównaniu z poprzednim rokiem.

Pisząc o analizie zmian w ruchu, w szczególności organicznym, nie mogę nie wspomnieć o analizie zmian w pozycjach strony z naciskiem na frazy powiązane z podstronami, których adresy uległy zmianie. Na SeoStation można włączyć wyświetlanie na wykresie informacji o zmianach podstron, a oprócz tego na wykresach grupowych warto sprawdzać zmiany pozycji dla wielu fraz naraz. Na poniższym wykresie widać adnotacje o zmianach podstron (żółte kropki) i w tym przypadku to były chwilowe zmiany pomiędzy adresem kategorii z i bez rozszerzenia. Nie miało to na szczęście wpływu na wahania pozycji.

Przenosiny serwisu, w ramach których przede wszystkim została zmieniona platforma (z autorskiego skryptu na WordPress), zakończyła się sukcesem i nie odbiła się czkawką w wynikach wyszukiwania. Moje obawy, w związku z którymi zdecydowałam się jedynie na częściowe przekierowania, nie sprawdziły się 😉

KATEGORIE: Case study, Optymalizacja stron

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Copyright 2017 Lexy's SEO blog. All Right Reserved.