fbpx
Agencja SEO Zgred - Pozycjonowanie stron www

Przebudowa serwisu www krok po kroku czyli jak nie spierdolić sobie SEO

W życiu każdego serwisu przychodzi taki czas, że trzeba podjąć decyzję o jego przebudowie. Najprostszy zawsze jest „redezajn” bo nie trzeba zmieniać struktury adresów URL. Może się czasem zmieni treść ale to zazwyczaj niewiele. Pozycjonowanie serwisu przez lata pozwoliło Tobie na zbudowanie wielu linków zewnętrznych oraz koszmarnie wielkiego i zapewne trudnego do opanowania linkowania wewnętrznego.

0. Migracja na SSL

Migrowanie serwisu z wersji bez certyfikatu na wersję z certyfikatem jest szybka, łatwa i przyjemna (sic!). Teoretycznie sprawa jest prosta:

  • wdrażasz certyfikat
  • kopiujesz pliku z public_html do private_html (o ile to potrzebne)
  • ustawiasz przekierowania 301 z wersji nonSSL na wersję SSL
  • sprawdzasz i ustawiasz poprawnie linki, canonical’e
  • ustawiasz nowe Google Search Console
  • aktualizujesz mapę

i działa. Nie będę się długo rozwodził na ten temat – odsyłam do wpisu Lexy z checklistą związaną z wdrożeniem certyfikatu SSL.

Jednakże grubsza przebudowa, która dotyka:

  • struktury adresów URL – następuje ich jakakolwiek zmiana
  • treści – usuwanie i/lub rozbudowa
  • wymiana usług czy produktów

będzie wymagała zbudowania dużego procesu i zwrócenia uwagi na kilka aspektów, o których traktuję poniżej.

1. Budujemy punkt ZERO

Aby zbudować punkt wyjścia do dalszych prac musimy w tym celu wykorzystać narzędzia, które zbiorą Nam jak najwięcej informacji. W tym celu, z wykorzystaniem Screaming Frog, Sitbulb czy Clusteric, wykonujemy pełen audyt SEO. W przypadku małych serwisów taki audyt będzie trwał „kilka chwil” 😉 natomiast w przypadku dużych systemów e-commerce trzeba na to poświęcić kilka (czasem) dni.

Wykonujemy pełen crawl strony i zbieramy następujące dane:

  • wszystkie meta <title> oraz <description> oraz adresy URL zbieramy w jednym pliku – mogą być potrzebne do importu na nowym serwisie
  • weryfikujemy i budujemy plik z nagłówkami H1
  • w przypadku e-commerce’ów dobrze jest przygotować osobny plik z opisami produktów – przyda się poniżej – uwierzcie
  • zbieramy i poprawiamy linkowanie wewnętrzne dla błędów 404 oraz przekierowań 301 (tutaj uwaga: o ile taka weryfikacja jest potrzebna – czasem przekierowania po prostu muszą być)
  • zwracamy uwagę na wersję http / https i odpowiednio reagujemy
  • sprawdzamy i poprawiamy plik sitemap.xml
  • weryfikujemy liczbę podstron i plików znalezionych przez narzędzie z tym co widzi Google w GSC (to o tyle ważne, że serwis może korzystać z parametryzacji, paginacji, filtrów, sortowania co pociąga za sobą weryfikację canonical’i, przekierowań itd)
  • poprawiamy robots.txt
  • NIE WSTAWIAMY NOINDEX do nagłówka – tak, nadal się to zdarza najlepszym (Mnie też)
  • i inne bliżej nieokreślone rzeczy

Czyli wykonujemy pełen audyt SEO, wdrażamy go. Tym samym mamy wykonane pliki, poprawiony serwis, zaktualizowane GSC i … i teraz wykonujemy backup. Backup jest Nam potrzebny do wykonania punktu powrotnego – w przypadku gdy coś się spierdoli później zawsze mamy backup, który pozwoli Nam w dowolnym momencie wrócić do punktu wyjścia.

Najważniejsze: audyt seo wykaże również elementy, których nie można/nie da się wdrożyć na obecnej wersji strony – dlatego tak ważne jest rozpisanie tego dla dewelopera, który będzie pracował nad nową wersją.

Bez backupu nie ruszamy serwisu. Backupujemy też pliki, wykonane w krokach wskazanych powyżej.

 

2. Stawiamy stronę testową

Stronę testową najlepiej … odtworzyć z bakcupu wykonanego w punkcie pierwszym i pracować na takiej wersji. To marzenie idealistyczne – wiem. Gdyby jednak się udało byłoby super ale nie ma tak dobrze.

Po uruchomieniu strony testowej zwracamy uwagę na następujące rzeczy:

  • jeżeli zmieniamy strukturę adresów URL musza o tym wiedzieć wszyscy zaangażowani w projekt. Wielokrotnie zdarza się, że seowiec nie jest informowany i jakichkolwiek zmianach a jego rola jest tutaj cholernie ważna. Ważniejsza niż Project Managera prowadzącego projekt.
  • jeżeli zmieniamy treści to informujemy o tym seowca oraz contentowca – czyli osoby odpowiedzialne za pozycjonowanie oraz treści na serwisie
  • wykonujemy crawl nowej struktury (z treściami) i wykonujemy (a przynajmniej zaczynamy) mapę przekierowań 301 (żadne tam 302!!! oraz razu robimy 301 bez zbędnego p…)
  • jeżeli w nowej strukturze kasujemy jakieś adresy URL (bez względu na przyczynę) informujemy seowca i wspólnie decydujemy o przekierowaniach 301
  • nie wykonujemy przekierowań na stronę główną – żadnych! Staramy się znaleźć odpowiednie podstrony, gdzie możemy skierować użytkownika w przypadku, gdy trafi na stronę usuniętą

 

Jeśli zmieniałeś (lub nawet nie zmieniałeś) strukturę adresów URL to z przygotowanych plików trzeba zaimportować przede wszystkim meta tagi (title oraz description) oraz z drugiego pliku opisy produktów czy też usług. Dzięki temu szybko masz postawiony goły serwis z usługami czy produktami oraz tymi samymi meta.

I teraz przechodzisz do następnej części czyli…

 

3. Migracja treści do nowego serwisu

Pewnie będziesz miał moje zdanie w głębokim … ale pamiętaj. Jeśli zmieniasz treści w serwisie w trakcie migracji będziesz mieć coś takiego:

Treści przenosimy zawsze jeden do jednego lub rozbudowujesz. Unikamy kasowania lub okrojenia treści bo to się nie zepnie.

W tym kroku:

  • uzupełniasz treściami wszystkie usługi lub produkty z plików (backupu), które wykonałeś w kroku pierwszym
  • przenosisz treści dla strony głównej, kategorii i podkategorii
  • przenosisz bloga i treści tam zawarte
  • weryfikujesz powstałe błędy 404 oraz przekierowania 301 – ogarniasz to na bieżąco w trakcie wgyrwania contentu czy realizji przekierowań 301 z punktu 2

I teraz jeśli najdzie Cię ochota grzebać w contencie to jest to jedyny moment aby to zrobić. I pamiętaj – lepiej rozbudowywać treści niż je usuwać.

 

4. SEO czyli testowanie wersji deweloperskiej

Mając przygotowany serwis testowy w nowej strukturze, z nowymi adresami URL, z przygotowanymi treściami wykonujesz zwykły audyt SEO. W tym kroku, podobnie jak w pierwszym weryfikujesz:

  • meta <title> oraz <descirption> – czy są wszystkie przeniesione, czy są puste, wprowadzasz stosowne poprawki
  • weryfikujesz nagłówki H1
  • sprawdzasz czy są błędy 404 – poprawiasz je
  • weryfikujesz linkowanie wewnętrzne – wykonujesz stosowne przekierowania 301 (ważne: jeśli klikasz w strukturze testowej to naprawiasz strukturę testową – zapisz te przekierowania w pliku, który posłuży do przekierowań docelowych)
  • otwierasz plik z audytem SEO z pierwszego punktu (tam gdzie wykonywałeś audyt dla wersji starej) i usprawniasz te elementy, które wskazywałeś do wykonania na nowym serwerze. Robisz to już teraz

Ważne: w tym punkcie przygotowujesz a właściwie auaktualniasz mapę przekierowań, którą tak naprawdę zacząłeś wykonywać już w punkcie 2  w momencie stawiania wersji testowej serwisu. Końcowa mapa przekierowań jest najbardziej krytycznym elementem całej operacji migracji serwisu. Bez mapy przekierowań w ogóle nie warto brać się za jego przebudowę. Nawet jakbyś płacić miliony.

Teraz generujesz nowy plik sitemap.xml i przygotowujesz go do wgrania do Google Search Console.

Jeżeli w tym momencie podjąłeś decyzję i wszyscy dali zielone światło to … wykonujesz pełny backup nowej struktury testowej. Chodzi o to aby mieć punkt końcowy, który będzie jednocześnie punktem startowym dla dalszych prac deweloperskich.

 

5. Migracja serwisu

Bo dziś jest ten dzień. Czyli:

  • upewniasz się, że masz backup starego serwisu – to ważne
  • uruchamiasz nowy serwis – na nowym serwerze, w nowym miejscu, nadpisujesz na starym – nieważne ale uruchamiasz
  • wgrywasz mapę przekierowań 301 do pliku htaccess
  • wgrywasz nowy plik sitemap.xml do GSC (jeśli uruchamiałeś jednocześnie certyfikat SSL to uruchamiasz nowe GSC)
  • przenosisz kody Google: analytics, gsc, remarketing i inne, które ręcznie instalowałeś
  • zdejmujesz NOINDEX z nagłówka
  • no i… nie tak prędko

Po uruchomimeniu serwisu niezbędne jest wykonanie następujacych czynności:

  • wykonanie pełnego crawl serwisu za pomocą narzędzi seo
  • weryfikacja wszystkich błędów 4xx, 5xx oraz przekierowań 3xx – upsrawnienie tego
  • tip: można zostawić starą mapę XML w GSC tylko po to aby Google omiatało nieistniejący serwis co przyspieszy jego reindeksację. Nalezy mieć tylko na względzie fakt, ze to negatywnie pływa na crawl budget (błędy 4xx i przekierowania 3xx nie powinny być w mapach)

Więc jeśli wszystko dobrze poszło to powinno się wszystko utrzymać na tym samym poziomie:

A jesli poszło źle to przywracasz z backupu serwis i wracasz do testów.

 

Czynności pomigracyjne:

  • przejrzenie GSC w poszukiwaniu problemów, zysków i start – na początku co 2 tygodnie, potem raz na kwartał
  • wykonywanie skanów narzedziami w poszukiwaniu błędów 4xx, 5xx

 

Pytania:

  • czy w migracja spowoduje spadki? „TO ZALEŻY” ale tak, może. Stabilizacja wyników następuje w ciągu kilku tygodni – nie ma tak, że od razu ładnie wszystko przejdzie.
  • po migracji widzę stare i nowe adresy czy to normalne? TAK. Taki stan może się utrzymywać nawet kilka miesięcy i nie ma możliwości przyspieszenia wyindeksowania starych adresów.
  • czy przy migracji serwisu mogę uruchomić certyfikat SSL? Tak, oczywiście. Kroki są takie same tylko dochodzi to co opisała Lexy w swoim poradniku (patrz wstępniak do artykułu)
  • obecnie serwis zgłasza się z WWW – czy mogę zmienić to na bez WWW? Oczywiście, że możesz. Tylko wtedy musisz uważać aby mapa przekierowań 301 uwzględniała taką zmianę. Z mojego doświadczenia wynika, że jeśli masz WWW zostań przy WWW, jeśli nie miałeś WWW zostań na schemacie bez WWW – taka zmiana to dodatkowy czynnik ryzyka
  • będę migrować serwis etapami czyli przez pewien czas będziemy mieć nowy i stary serwis – co zrobić? Tak naprawdę to samo co powyżej ale musisz przygotować kilka map przekierowań: jedna na serwerze nowym, kierująca na serwis stary bo tam są jeszcze stare treści, których nie ma na serwisie nowym; jedna na serwerze starym, kierująca na serwis nowy bo na nowym są już nowe treści; wreszcie mapa od strony Internetu obsługująca użytkowników… I od razu powiem aby używac przekierowań 301. Most Syreny stał 15 lat – 302 to tymczasowe przekierowania a Ty będziesz migrować to rok więc lepiej zastosować od razu 301 aby zadbać o prawidłowy przepływ PR.

Jeśli macie jakieś pytania to piszcie. Albo dzielcie się swoimi doświadczeniami w tym zakresie. Starałem się opisać swoje doświadczenie i pokazac pewne kroki. Niektóre z nich są powtarzane wielokrotnie zanim rzeczywiście wszyscy w projekcie dadzą zielone swiatło. Najkrótsza moja migracja trwała blisko 2 miesiąca. Najdłuższa – blisko rok.

Powodzenia 🙂

 

Bibliografia:

 

1 gwiazdka2 gwiazdki3 gwiazdki4 gwiazdki5 gwiazdek (13 głosów, średnia: 4,23 z 5)

Paweł Gontarek

Paweł Gontarek - Zgred - pasjonat SEO, staram się zrozumieć czym jest i jak działa SEM oraz UX.

Komentarzy (7)

  1. Lury
    Listopad 25, 2018

    Świetny tekst Paweł, dzięki za wzmiankę 🙂

  2. zeki
    Listopad 26, 2018

    Chciałbym wywalić z urli „/pl/” – masz na to jakiś sposób żeby nie dziabać każdego urla z osobna tylko załatwić to jednym wpisem w .htaccess?

    • Paweł Gontarek
      Listopad 26, 2018

      Ale musisz koneicznie pozbyć się PL-ki? Mam kilka serwisów pod opieka i nie usuwaliśmy tego.

  3. Marcin Kordowski
    Listopad 26, 2018

    Ciekawa „to do list” z bardzo dużą ilością szczegółów Pawle!
    Czy ta lisa odnosi się też do przebudowy i jednoczesnej integracji dwu, trzech, domen?

    • Paweł Gontarek
      Listopad 26, 2018

      Tak. Może tylko bardziej szczegółowo wymagane jest rozpisanie punktów związanych z przekierowaniami 🙂 Ale darade na pdostawie tego zbudowac harmonogram dla (n+1)^x domen 😉

  4. Eco
    Listopad 28, 2018

    Zapoznałam się i skopiowałam do pliku aby mieć dostęp jakby net padł. Dziękuję.

  5. Bogdan
    Grudzień 3, 2018

    Jeden z lepszych artykułów na ten temat. Bardzo dobrze napisany, jasno i precyzyjnie. Dla osoby która szuka wiedzy na blogach na pewno jest wartościowy.

Zostaw komentarz

Twój adres e-mail nie będzie udostępniony. Wymagane pola są oznaczone *