Checklista przebudowy strony: co zrobić przed, w trakcie i po
Praktyczna checklista przebudowy strony: audyt treści, mapa przekierowań, kontrola techniczna i monitoring po starcie, które chronią ruch z wyszukiwarki.
Spadki ruchu po przebudowie prawie nigdy nie wynikają z projektu graficznego. Wynikają z adresów zmienionych bez przekierowań, treści, które „uporządkowano” aż do zniknięcia, albo noindex z wersji testowej, który trafił na produkcję.
Oto checklista, którą przechodzimy przy każdej przebudowie.
Przed: zrozum, co już masz
Przecrawluj obecną stronę. Wyeksportuj każdy adres z kodem odpowiedzi, tytułem i liczbą słów. To Twoja inwentaryzacja i źródło do przekierowań.
Pobierz dane z dwunastu miesięcy. Z Search Console: każdą podstronę z wyświetleniami i kliknięciami. Z analityki: każdą podstronę z istotnym ruchem albo konwersjami. Żadnej podstrony z którejkolwiek z tych list nie można bezrefleksyjnie usunąć.
Ustal, co zarabia. Zwykle 10–20% podstron generuje niemal całą wartość z wyszukiwarki. Oznacz je. Te podstrony się chroni, a nie „odświeża dla spójności”.
Wypisz linki przychodzące. Podstrony z linkami z zewnątrz mają wartość, która sama się nie przeniesie. Potrzebują przekierowań, nawet jeśli usuwasz treść.
Zmierz punkt wyjścia wydajności. Core Web Vitals, wagę strony, czas odpowiedzi serwera. Chcesz móc udowodnić, że nowa strona jest szybsza — i zauważyć, jeśli nie jest.
Uzgodnij, po co jest przebudowa. „Wygląda na przestarzałą” to prawdziwy powód, ale niemierzalny. Dodaj coś, co da się sprawdzić po wszystkim: więcej zapytań, lepsza konwersja na telefonach, szybsze publikowanie, mniej porzuceń na stronach usług.
W trakcie: buduj, nie psując
Zachowaj adresy, gdzie się da. Zmiana struktury adresów dla porządku to najdroższa decyzja estetyczna, jaką można podjąć. Zmieniaj je tylko wtedy, gdy jest prawdziwy powód.
Przypisz każdy stary adres do nowego. Jeden do jednego, gdzie to możliwe. Nigdy nie przekierowuj wszystkiego na stronę główną — wyszukiwarki traktują to jak soft 404, a użytkownicy tego nienawidzą.
Zachowaj głębię treści. Jeśli stara podstrona miała pozycje dzięki 1200 słowom odpowiadającym na pytanie, nowa wersja musi odpowiadać co najmniej tak dobrze. Przepisywanie pod projekt graficzny zwykle wycina konkrety, a zostawia przymiotniki.
Przenieś metadane. Tytuły i opisy, które już działają, nie powinny być generowane na nowo z szablonu.
Buduj z myślą o crawlerze. Upewnij się, że treść jest w HTML-u renderowanym na serwerze. Nowoczesne frameworki potrafią renderować wszystko w przeglądarce; wyszukiwarki umieją wykonać JavaScript, ale dokładasz zależność, której nie potrzebujesz.
Trzymaj wersję testową poza indeksem. Zabezpiecz ją hasłem. Sam robots.txt nie chroni niezawodnie przed indeksacją, a publiczna wersja testowa może konkurować z działającą stroną.
Start: kontrola przed lotem
Przejdź przez to rano w dniu startu, a nie wieczorem po nim:
robots.txtpozwala na crawlowanie i wskazuje mapę strony- żadnego zabłąkanego
noindexw szablonach produkcyjnych - tagi kanoniczne wskazują właściwy adres działającej strony na każdym typie podstrony
- mapa strony XML zawiera wyłącznie indeksowalne adresy ze statusem 200
- każde przekierowanie zwraca 301, bez łańcuchów i pętli
- strona 404 zwraca prawdziwy status 404, a nie 200
- HTTPS wszędzie, a HTTP przekierowuje tylko raz
- tylko jedna nazwa hosta — wybierz z www albo bez i przekieruj drugą
- analityka i śledzenie konwersji działają na nowych szablonach
- formularze się wysyłają i trafiają tam, gdzie powinny
- dane strukturalne przechodzą walidację
- Search Console i analityka mają skonfigurowaną nową usługę
Po: obserwuj przez cztery tygodnie
Tydzień pierwszy. Codziennie sprawdzaj raporty indeksowania. Przecrawluj działającą stronę i porównaj z mapą przekierowań. Szukaj błędów 404 w logach serwera — prawdziwe pojawiają się tam wcześniej niż gdziekolwiek indziej.
Tydzień drugi. Porównaj pozycje chronionych podstron. Niewielki spadek, gdy wyszukiwarki ponownie przetwarzają stronę, jest normalny. Utrzymujący się spadek na konkretnym szablonie to sygnał.
Tydzień trzeci i czwarty. Zmierz ponownie Core Web Vitals na danych rzeczywistych, a nie tylko w narzędziach laboratoryjnych. Porównaj konwersję z punktem wyjścia — tu zmiany w projekcie pokazują swój prawdziwy efekt.
Przez cały czas. Zachowaj eksport crawla starej strony. Gdy ktoś zapyta „czy ta podstrona wcześniej istniała?”, odpowiesz w kilka sekund.
Pułapka, w którą wpadają wszyscy
Stare mapy strony, stare linki wewnętrzne i stare adresy wpisane na sztywno w szablony maili, PDF-y i kampanie reklamowe. Obsługują je przekierowania — i właśnie dlatego nikt nie zauważa, gdy przekierowania są błędne. Sprawdź próbkę ręcznie.
Jeśli planujesz przebudowę i chcesz, żeby strona techniczna była zrobiona porządnie, właśnie tym zajmujemy się w ramach technicznego SEO i tworzenia stron internetowych. Jeśli strona już wystartowała, a ruch spadł, audyt SEO zwykle znajduje przyczynę w ciągu jednego dnia.
Oskar Szymczak
Założyciel i inżynier oprogramowania
Odpowiada za techniczną stronę każdego projektu — architekturę, programowanie i decyzje, które później drogo zmieniać.
Więcej o zespolePotrzebujesz w tym pomocy?
To jest praca, którą wykonujemy. Te strony wyjaśniają, jak do niej podchodzimy.