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ń.

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 stronie zauważalny od 7 do 10 kwietnia) nie zaburzył nam obrazu.

źródło: Google Analytics

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.

źródło: ustawienia widoczności (WordPress)

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 którego zdjęciu można łatwo zapomnieć podczas przepinania strony.

Stara wersja strony korzystała z autorskiego, stworzonego wiele lat temu CMS-u, 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 jeden z tych wpisów kwalifikował się do ustawienia przekierowania 301 na aktualny odpowiednik, czego dokonałam w kolejnym etapie prac nad stroną za pomocą wtyczki Redirection. Wtyczka ta ma sporo przydatnych opcji i jest systematycznie aktualizowana. 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 zainstalowaniu wersji 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 URL-e?

Pierwszy dylemat, jaki miałam, związany był ze strukturą adresów URL-i, 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 URL-u)

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.

źródło: wtyczka Redirection

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ę, kiedy 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.

źródło: ustawienia adresów URL (WordPress)

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).

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 zalecaną 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, przy czym wtyczka ta była aktualizowana po raz ostatni w 2023 r., dlatego przed skorzystaniem z niej warto zweryfikować, czy nadal działa poprawnie;
• 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. Natomiast w razie usunięcia wpisów (bez ich przekierowywania) najlepiej wyindeksować je, korzystając z formularza dostępnego w zakładce Usunięcia. Jeśli tylko zwracają one nagłówek 404, zostaną usunięte trwale. W przeciwnym wypadku będzie to usunięcie tymczasowe, o czym pisałam już wiele lat w temu we wpisie Powrót do indeksu mimo…

źródło: Google Search Console

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 z narzędzia dostępnego wtedy pod adresem 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ń.

źródło: urlitor.com

Wspomniane tu i widoczne powyżej narzędzie nie jest już dostępne, dlatego aktualnie najczęściej korzystam z zaprezentowanego poniżej https://httpstatus.io/

źródło: httpstatus.io

Skan najlepiej rozpocząć i zakończyć, korzystając z narzędzia ScreamingFrog.

źródło: ScreamingFrog

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. Warto przy okazji zajrzeć do uprawnień do danych w Google Analytics, Google Search Console oraz w innych narzędziach.

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 jest to święto ruchome. Poniżej prezentuję aktualny wykres zmian w ruchu organicznym w porównaniu z poprzednim rokiem.

źródło: Google Analytics

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.

źródło: SeoStation.pl

Monitorowanie wspomnianych wcześniej zmian w podstronach pozwoli na szybkie wyłapanie problemu kanibalizacji na stronie.

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ę 😉

Data pierwszej publikacji wpisu: 11 czerwca 2019 r.
Data ostatniej aktualizacji: 28 lutego 2024 r.