Migracja z WordPressa albo starego hostingu bez utraty pozycji i bez dnia przestoju.
Strona, która ma ruch i nie może go stracić.
Nowa wersja stoi najpierw pod adresem tymczasowym z blokadą indeksowania. Treść, media i stare adresy przenosimy razem, stare ścieżki dostają 301, a domenę przepinamy dopiero po akceptacji. Stara wersja zostaje jako droga odwrotu.
W zakresie jest też to, co zwykle wypada z migracji: audyt wydajności po przeniesieniu i komplet danych strukturalnych, bo nowa strona bez tego traci to, co stara miała wypracowane.
Przeniesienie strony na nowy stack i nowy serwer bez utraty pozycji w wyszukiwarce i bez dnia przestoju.
Nowa strona najpierw stoi pod adresem tymczasowym z blokadą indeksowania. Treść przenosimy razem ze starymi adresami, stare ścieżki dostają przekierowania 301, a domenę przepinamy dopiero wtedy, gdy nowa wersja działa.
Stara zostaje jako droga odwrotu do czasu, aż nikt jej nie potrzebuje. Cztery serwisy przeszły tą drogą z poprzedniego hostingu, trzy z nich z WordPressa.
Co dostajeszMapowanie starych struktur na nowe typy treści, przepisywanie reguł przekierowań, migracja wpisów.
Decyzja, które adresy mają wartość, obsługa krawędzi (końcowe slashe, adresy numeryczne, duplikaty) i sprawdzenie po cutoverze, czy nic nie zniknęło z indeksu.
Metadane, canonical, sitemap, linkowanie wewnętrzne i decyzja o tym, co ma wejść do indeksu, a co nie.
Najczęstszy błąd stron generowanych przez AI: wszystko indeksowalne. Tysiące adresów z filtrów, budżet indeksowania spalony, a strona i tak nie rośnie. Widoki z filtrami dostają u nas `noindex, follow` i canonical na czystą ścieżkę.
Linkowanie wewnętrzne traktujemy jako funkcję, nie jako dobrą wolę redakcji: „inne w tej kategorii”, „poprzedni i następny”, „podobne po tagach” oraz strony-huby kategorii i tagów generują się z danych.
Co dostajeszSzkice meta description, wykrywanie brakujących metadanych, generowanie obrazów OG.
Decyzja, co ma być w indeksie, a co nie — i pilnowanie, żeby linkowanie wewnętrzne wynikało z danych, a nie z pamięci redaktora.
Opis treści w formacie, który rozumieją wyszukiwarki i modele AI. U nas wymóg, nie dodatek.
Jeden graf na stronę. `Organization` i `WebSite` z akcją wyszukiwania siedzą raz w layoucie, a węzły stron linkują do nich przez `@id`. Do tego okruszki i najwęższy typ encji dla danej strony: `Store`, `BlogPosting`, `Event`, `Product` z ofertą, `FAQPage`, `HowTo`, `Person`, `Book`, `VideoObject`.
Twarda zasada: dane strukturalne muszą zgadzać się z tym, co widać na stronie. Model językowy chętnie dopisze do grafu ocenę 4,9 z 87 opinii, których nie ma. To prosta droga do kary od wyszukiwarki, a nie do gwiazdek w wynikach.
Co dostajeszPierwszy przebieg grafu z modelu treści i wykrywanie braków.
Dobór typu do treści i pilnowanie, żeby w grafie nie było niczego, czego nie ma na stronie.
Praca nad szybkością mierzona narzędziem, z zapisem tego, co pomogło i co nie pomogło.
Pomiar tym samym silnikiem co PageSpeed, lokalnie, z flagami odcinającymi artefakt przeglądarki na Macu — bez nich pierwsze malowanie pada około 1,5 s później i cała analiza jest zmyślona. Mediana z kilku przebiegów, nie jeden wynik, bo pojedynczy przebieg mieści się w rozrzucie narzędzia.
Wynik z realnego projektu: telefon 81 → mediana 91 (rozrzut 87–92), waga strony 793 kB → 415 kB, fonty 166 kB → 105 kB i 10 plików → 5, dostępność 96 → 100 na telefonie i 92 → 100 na desktopie.
Co dostajeszPierwszy przebieg optymalizacji i wykrywanie oczywistych strat.
Pomiar, który mówi prawdę, i odrzucanie zmian, które na papierze wyglądają dobrze. Jedna taka „oszczędność 57 kB” dała CLS 0,22 i minus 11 punktów — cofnięta.
Strona, której treść zmieniasz sam: blog, katalog, wydarzenia, produkty. Panel to Strapi 5, front to Next.js.
Dwa osobne repozytoria połączone kontraktem OpenAPI. API publikuje statyczny plik kontraktu, front generuje z niego klienta i trzyma go u siebie w repozytorium.
Brzmi jak szczegół, a decyduje o spokoju: budowanie nie potrzebuje dostępu do API, więc jest deterministyczne, a każdą zmianę modelu treści widać jako zmianę w kodzie frontu — nie jako awarię na produkcji w niedzielę.
Co dostajeszModel treści z opisu domeny, komponenty listy i szczegółu, pola SEO, migracja danych przykładowych.
Granice modelu (co jest relacją, a co komponentem), uprawnienia, wydajność zapytań, unikanie n+1, cache i jego unieważnianie.
Po to jest mapa adresów i przekierowania 301. W jednym z projektów było ich około czterdziestu: końcowe slashe, zmienione slugi i stare adresy numeryczne. Wszystkie spisane w repozytorium.
Zostaje jako droga odwrotu do czasu, aż będzie pewne, że nowa działa. Dopiero potem ją wyłączamy.
Wyceniamy w godzinach, po rozmowie telefonicznej i przeglądzie projektu. Nasze ostatnie projekty zajęły od 15 do 45 godzin.
