Jak migrować wielojęzyczną stronę bez utraty SEO

Ruch organiczny zazwyczaj nie znika dlatego, że Google się pogubił. Znika, bo migracja wielojęzycznej witryny została potraktowana jak zwykły redesign – i ktoś zapomniał, że każda wersja językowa ma własne URL-e, sygnały, kanoniczne tagi i ścieżki linków wewnętrznych. Jeśli chcesz migrować wielojęzyczną stronę bez utraty SEO, potrzebujesz planu, który traktuje lokalizację jak architekturę, a nie ozdobnik.

W WordPress robi się z tego szybko niemały bałagan. Jeden plugin przechowuje przetłumaczone URL-e w jeden sposób, inny przepisuje slug-i inaczej, a trzeci wstrzykuje tagi hreflang według własnej logiki. Potem ktoś zmienia strukturę domeny, wypycha nową stronę na produkcję w piątek i przez cały następny miesiąc zastanawia się, dlaczego francuskie strony produktowe przepadły jak kamień w wodę. Żadna z tych sytuacji nie jest zagadkowa. Zazwyczaj po prostu dało się jej uniknąć.

Dlaczego migracje wielojęzyczne tak łatwo psują SEO

Migracja jednojęzycznej strony jest już sama w sobie ryzykowna. Dodaj wiele języków, a nagle przenosisz grupy równoważnych stron, alternatywne URL-e, targetowanie regionalne, przetłumaczone metadane, linki wewnętrzne – i nierzadko sporo treści wyglądających jak duplikaty, które wyszukiwarki rozumieją tylko dzięki otaczającym je sygnałom.

Największy błąd to założenie, że pozycje w rankingach zależą wyłącznie od treści na stronie. Tak nie jest. Zależą od całego ekosystemu – struktury URL, indeksowalności, tagów kanonicznych, hreflang, przekierowań, spójności sitemapy i tego, czy Google wciąż rozumie, która strona angielska odpowiada której wersji hiszpańskiej lub niemieckiej.

Jeśli choćby jeden z tych elementów zawiedzie na dużą skalę, szkody się rozszerzają. Zły tag kanoniczny może zniszczyć cały folder językowy. Brakujące przekierowania mogą uśmiercić stare linki z autorytetem. Nieprawidłowy hreflang może wysłać złą stronę na zły rynek. A jeśli przetłumaczone slug-i zmienią się bez czystej mapy przekierowań, w praktyce prosisz Google, żeby zaczął wszystko od nowa.

Zanim zaczniesz migrację wielojęzycznej strony

Nie zaczynaj od projektu graficznego. Zacznij od inwentaryzacji.

Przeprowadź crawl obecnej witryny i wyeksportuj wszystkie indeksowalne URL-e dla każdego języka. Uwzględnij tytuły, meta description, kanoniczne tagi, kody statusu, odwołania hreflang, wpisy w sitemapie XML i – jeśli Twój crawler na to pozwala – linki wewnętrzne. Jeśli przenosisz się z hostowanej warstwy tłumaczeń lub platformy SaaS, udokumentuj dokładny format URL stosowany obecnie. Chodzi o podkatalogi, subdomeny, parametry, przetłumaczone slug-i, a jeśli są zlokalizowane – również URL-e mediów.

Następnie zmapuj każdy stary URL na nowy adres docelowy. Nie tylko szablony. Każdy URL. Strony kategorii, spaginowane archiwa, strony produktów, wpisy blogowe, strony główne poszczególnych języków, strony kont oraz wszelkie wartościowe landing page'e stworzone z myślą o płatnym lub organicznym ruchu. Jeśli strona ma zostać usunięta, zdecyduj, czy powinna przekierować do bliskiego odpowiednika, zwrócić 410, czy po prostu zniknąć. Zgadywanie w trakcie to najprostsza droga do tworzenia łańcuchów przekierowań i osieroconego ruchu.

To też moment, w którym decydujesz, czego nie zmieniać. Jeśli obecne wielojęzyczne URL-e dobrze rankują – zostaw je. Migracja to nie czas na eksperymenty z czystszymi slug-ami czy nową architekturą językową, chyba że wiąże się z tym realna korzyść. Stabilność wygrywa.

Wybierz odpowiednią strategię URL i trzymaj się jej

Rozsądnych opcji dla wielojęzycznego SEO jest niewiele: podkatalogi, subdomeny lub domeny krajowe. W WordPress podkatalogi są najłatwiejsze w zarządzaniu i dobrze zachowują autorytet – ale to nie znaczy, że automatycznie sprawdzą się w każdej konfiguracji.

Najważniejsza w trakcie migracji jest spójność. Jeśli stara strona używa /es/ i /de/, nie zamieniaj tego pochopnie na es.example.com tylko dlatego, że komuś wydaje się to bardziej korporacyjne. To generuje drugi problem migracyjny na górze pierwszego. Ta sama treść, nowa struktura, nowe sygnały, więcej miejsc do pomyłki.

Są sytuacje, w których zmiana URL-i się opłaca. Może stara platforma używała brzydkich ciągów zapytań, albo przetłumaczone strony były proxy-owane w sposób, który nigdy nie dawał Ci prawdziwej własności. W porządku. Ale bądź szczery co do kosztów. Im większa zmiana strukturalna, tym dokładniejsza musi być mapa przekierowań i tym bardziej rygorystyczne QA po wdrożeniu.

Przekierowania to nie zadanie do sprzątania po fakcie

Przekierowania są migracją.

Jeśli zmieniasz nawet jeden wzorzec wielojęzycznych URL-i, przygotuj arkusz przekierowań parujący każdy stary URL z jednym ostatecznym miejscem docelowym. Używaj przekierowań 301. Unikaj łańcuchów przekierowań. Unikaj niezgodności językowych, chyba że nie ma innego wyjścia. Stara hiszpańska strona produktu nie powinna wysyłać użytkowników na angielską stronę główną tylko dlatego, że ekipie migracyjnej skończyło się paliwo.

To ważne zarówno dla użytkowników i crawlerów, jak i dla przychodów. Sklepy WooCommerce z wielojęzycznymi stronami produktów często mają backlinki prowadzące do zlokalizowanych SKU, stron kategorii i treści blogowych. Zgubienie tych ścieżek oznacza nie tylko utratę pozycji. Oznacza marnotrawstwo equity linków, za które już zapłaciłeś treścią, PR-em i czasem.

Jeśli uciekasz z subskrypcyjnej platformy tłumaczeń, upewnij się, że możesz zachować dokładnie te URL-e widoczne dla SEO, które ludzie już odwiedzają. Tu właśnie liczy się własność. Niektóre narzędzia migracyjne, w tym rozwiązania zbudowane wokół TrueLang, są zaprojektowane właśnie po to, by przenosić wielojęzyczne URL-e i zachowywać strukturę SEO w nienaruszonym stanie, zamiast zmuszać Cię do resetowania wszystkiego od zera.

Hreflang, tagi kanoniczne i indeksowalność wymagają dogłębnego audytu

Tu właśnie wiele migracji po cichu upada.

Hreflang musi wskazywać na prawdziwe, indeksowalne odpowiedniki w różnych językach. Każda strona w grupie powinna poprawnie odwoływać się do pozostałych – w tym do samej siebie. Kody języka i regionu muszą być prawidłowe. Jeśli używasz x-default, rób to świadomie, a nie dlatego, że plugin dodał go domyślnie.

Tagi kanoniczne wymagają jeszcze więcej uwagi. Kanoniczny tag na przetłumaczonej stronie powinien zazwyczaj wskazywać na nią samą, a nie na wersję w języku źródłowym. Jeśli Twoja hiszpańska strona ma kanonikalizację do angielskiego oryginału, mówisz Google, że hiszpańska wersja to kopia, którą może zignorować. Ten błąd jest powszechny, dotkliwy i całkowicie do uniknięcia.

Następnie sprawdź indeksowalność na poziomie szablonów. Tagi noindex, zablokowane foldery, pozostałości środowisk stagingowych, przypadkowe zabezpieczenia hasłem i problemy z renderowaniem JavaScript mogą uderzyć w jedną sekcję językową bez dotykania pozostałych. Nie możesz zakładać, że skoro angielska wersja jest crawlowalna, to włoska jest w porządku.

Parytет treści ma większe znaczenie, niż się wydaje

Migracja wielojęzyczna to nie tylko techniczna hydraulika. Wyszukiwarki porównują odpowiedniki. Jeśli stara niemiecka strona miała zoptymalizowane tagi tytułu, treść, FAQ i linki wewnętrzne, a nowa to maszynowe tłumaczenie z obciętym formatowaniem i brakującymi metadanymi – pozycje mogą spaść, nawet jeśli przekierowania są perfekcyjne.

Nie oznacza to, że każde słowo musi odpowiadać starej wersji. Czasem odświeżenie pomaga. Ale intencja, struktura i optymalizacja on-page powinny zostać zachowane. Zachowaj przetłumaczone pola SEO tam, gdzie dobrze performują. Zachowaj tekst alternatywny obrazów tam, gdzie jest istotny. Zachowaj dane strukturalne, jeśli istnieją w każdym języku. Zachowaj linki wewnętrzne wewnątrz przetłumaczonych treści – zwłaszcza jeśli prowadzą do zlokalizowanych stron docelowych.

To jeden z powodów, dla których wielu właścicieli stron w ogóle porzuca rozbudowane platformy. Zdają sobie sprawę, że w rzeczywistości nie posiadają czystego, edytowalnego wielojęzycznego setupu. Wynajęli go. I wtedy migracja zamienia się w archeologię.

Dzień startu to czas weryfikacji, nie nadziei

Gdy nowa strona wychodzi na produkcję, sprawdzaj live URL-e natychmiast. Nie jutro. Nie po weekendzie.

Przetestuj listę przekierowań pod kątem rzeczywistych odpowiedzi. Przeprowadź crawl nowej strony według języków. Sprawdź output hreflang. Zweryfikuj tagi kanoniczne. Zwaliduj sitemapę XML. Upewnij się, że stare URL-e przekierowują poprawnie, a nowe strony zwracają kody statusu 200. Wyrywkowo sprawdź linki wewnętrzne w menu, przełącznikach języków, breadcrumb-ach, produktach, blogach i ścieżkach transakcyjnych takich jak koszyk i checkout.

Następnie otwórz Search Console i obserwuj zmiany w pokryciu indeksem, anomalie crawlowe i błędy hreflang. Porównaj liczby zaindeksowanych URL-i w poszczególnych sekcjach językowych. Jeśli jeden rynek zaczyna nieproporcjonalnie spadać – działaj szybko. W wielojęzycznym SEO małe błędy implementacyjne rzadko pozostają małe.

Spodziewaj się też pewnych fluktuacji. Nie każdy spadek oznacza porażkę. Jeśli zmieniłeś architekturę, treści, hosting i narzędzia tłumaczeniowe jednocześnie, Google potrzebuje czasu na ponowne przetworzenie sygnałów. Celem nie jest zerowy ruch. Celem jest kontrolowany ruch z jasnym wytłumaczeniem.

Czego unikać, jeśli chcesz zachować pozycje w rankingach

Nie migruj, przeprojektowuj i przepisuj każdej strony jednocześnie, chyba że lubisz debugować trzy zmienne naraz.

Nie pozwalaj pluginowi automatycznie generować przetłumaczonych slug-ów inaczej niż Twoje istniejące zaindeksowane URL-e, chyba że masz plan przekierowań dla każdego z nich z osobna.

Nie kieruj wszystkich usuniętych zlokalizowanych stron na jedną ogólną stronę główną danego języka. To leniwe rozwiązanie, a wyszukiwarki to widzą.

Nie ufaj, że hreflang jest poprawny, bo plugin deklaruje obsługę wielojęzycznego SEO. Obsługa to nie to samo, co poprawny output na Twojej konkretnej stronie.

I nie traktuj własności jako kwestii drugorzędnej. Jeśli Twoje przetłumaczone strony, metadane i URL-e żyją w cudzym wynajętym systemie, ryzyko migracji rośnie. Zawsze.

Mądra strategia jest nudna: zachowaj to, co już działa, udokumentuj każdy URL, zmapuj każde przekierowanie, zweryfikuj każdy sygnał i odmawiaj improwizacji po wdrożeniu. Tak się migruje bez dramatów. I tak przestajesz płacić za czyjś lock-in, zachowując pozycje, na które zapracowałeś.