Jak przekierować domenę bez utraty ścieżki i parametrów UTM

Jeśli chcesz przekierować domenę z zachowaniem ścieżki i parametrów query, warstwa przekierowań musi przenosić cały request URI, a nie tylko sam hostname. W praktyce oznacza to, że żądanie takie jak:

stara-marka.example/cennik?plan=pro&utm_source=email

powinno trafić do:

nowa-marka.example/cennik?plan=pro&utm_source=email

Jeśli konfiguracja przenosi wyłącznie samą domenę, gubisz dokładną ścieżkę, o którą użytkownik poprosił. To rozwala linki kampanii, deep linki, docs i często także SEO całej migracji.

Jeśli taki ruch jest częścią większej migracji serwisu, zacznij od checklisty przekierowań przy migracji strony, a dopiero później wróć do samego mechanizmu przekierowania domeny.

Co naprawdę znaczy „zachować ścieżkę i parametry query”

Kiedy ktoś mówi o przekierowaniu domeny, może mieć na myśli bardzo różne rzeczy.

Host-only forwarding

Każde żądanie ląduje na jednej nowej stronie głównej:

stara-marka.example/* -> nowa-marka.example/

To jest proste, ale wyrzuca kontekst.

Path-preserving forwarding

Ścieżka po domenie zostaje zachowana:

stara-marka.example/blog/wpis-1 -> nowa-marka.example/blog/wpis-1

To jest dokładnie to, czego potrzebuje większość prawdziwych migracji.

Query-preserving forwarding

Parametry kampanii i śledzenia zostają:

stara-marka.example/cennik?utm_source=x -> nowa-marka.example/cennik?utm_source=x

Bez tego analityka kampanii i atrybucja potrafią bardzo szybko przestać być wiarygodne.

Jeśli już wiesz, że parametry kampanii są ważne, wpisz to do specyfikacji przekierowania od razu, zamiast traktować jako notatkę do późniejszego QA.

Dlaczego sam DNS nie wystarczy

To jeden z najczęstszych punktów nieporozumienia.

Rekordy DNS, takie jak CNAME czy rekordy A, mówią internetowi dokąd wysłać ruch. Same z siebie nie wystawiają jednak przeglądarce przekierowania HTTP 301 ani 302.

Jeśli chcesz, by użytkownik i crawler trafili na nowy URL, potrzebujesz warstwy HTTP, która zwróci:

• właściwy kod statusu
• właściwy adres docelowy
• opcjonalne zachowanie ścieżki
• opcjonalną obsługę parametrów query

Dlatego domain forwarding to nie tylko zadanie DNS-owe. To zadanie routingowe.

Jeśli nadal zastanawiasz się, czy zmiana jest trwała czy tymczasowa, przeczytaj najpierw 301 vs 302 vs 307 vs 308, zanim cokolwiek opublikujesz.

Najbezpieczniejszy wzorzec dla realnej migracji domeny

W większości migracji dobry punkt wyjścia wygląda tak:

1. wybierz finalny canonical hostname
2. wymuś HTTPS
3. przekieruj każdą sensowną starą ścieżkę do nowego odpowiednika
4. zachowaj ważne parametry query
5. trzymaj liczbę skoków na poziomie jednego

Przykład:

http://stara-marka.example/docs/api?ref=partner
  -> https://nowa-marka.example/docs/api?ref=partner

To jest dużo lepsze niż:

http://stara-marka.example/docs/api
  -> https://stara-marka.example/docs/api
  -> https://www.nowa-marka.example/docs/api
  -> https://nowa-marka.example/docs/api

Gdzie zachowanie ścieżki ma największe znaczenie

Migracje strony

Jeśli przenosisz serwis na nową domenę albo nowy stack, zachowanie ścieżki utrzymuje użyteczność starych backlinków i zaindeksowanych URL-i.

Dokumentacja i knowledge base

Użytkownik docsów rzadko zaczyna od strony głównej. Najczęściej ląduje na konkretnym artykule. Zrzucenie wszystkiego na / psuje doświadczenie od razu.

Kampanie płatne

Jeśli ktoś kliknie reklamę z pięcioma parametrami śledzącymi, a przekierowanie je zgubi, raportowanie przestaje być wiarygodne jeszcze przed końcem pierwszego dnia kampanii.

Linki z bio i shortlinki

Wiele markowych linków to tak naprawdę małe reguły routingu. Jeśli ginie ścieżka celu, ginie też logika całego systemu linków.

Czysty model wildcard forwarding

Najprostszy model myślenia wygląda tak:

source:      stara-marka.example/*
destination: nowa-marka.example/$1

To oznacza:

• weź wszystko po slashu
• wstaw to do ścieżki celu
• zachowaj strukturę żądania

Przykładowo:

Jeśli dodatkowo zachowujesz query string, to:

/cennik/enterprise?utm_source=partner

pozostaje:

/cennik/enterprise?utm_source=partner

Jeżeli aktualny plan przekierowań robi dwa albo trzy skoki, napraw to przed premierą. Wskazówki znajdziesz w artykule o łańcuchach i pętlach przekierowań.

Cztery kontrole, które zapobiegają większości błędów

1. Najpierw ustal finalny hostname

Wybierz dokładnie jeden host końcowy:

• nowa-marka.example
• albo www.nowa-marka.example

Nie zostawiaj tej decyzji „na później”. To właśnie w ten sposób tworzą się łańcuchy typu http -> https -> www -> final.

2. Świadomie wybierz kod statusu

Jeśli zmiana jest trwała, użyj trwałego kodu, np. 301.

Jeśli zmiana jest tymczasowa, użyj kodu tymczasowego, np. 302.

Jeśli chcesz odświeżyć sobie zasady, wróć do 301 vs 302 vs 307 vs 308.

3. Ustal politykę parametrów query

Nie zakładaj, że każdy dostawca automatycznie zachowuje query string. Trzeba to sprawdzić.

Używaj realnych przykładów:

curl -I 'https://stara-marka.example/cennik?plan=pro&utm_source=email'

Potem upewnij się, że nagłówek Location rzeczywiście zawiera oczekiwaną ścieżkę i parametry.

4. Testuj root i głębokie URL-e

Bardzo wiele przekierowań działa dla /, a wykłada się na głębszych ścieżkach, takich jak:

• /docs/api
• /blog/slug-wpisu
• /cennik/enterprise
• /stara-kategoria/produkt-123

HTTPS i SSL są częścią przekierowania

Jednym z najgorszych scenariuszy migracyjnych jest sytuacja, w której:

• sama logika przekierowania jest poprawna,
• ale stara domena nie potrafi domknąć HTTPS bez błędu,
• więc użytkownik widzi problem z certyfikatem jeszcze zanim przekierowanie zadziała.

To dlatego automatyczny SSL ma znaczenie. Przepływ przekierowania zaczyna się od pierwszego żądania, a nie dopiero w momencie, gdy logika routingu dostała idealne warunki do działania.

Jeśli chcesz mieć to obsłużone jako managed layer, darmowe przekierowanie UrlEdge obejmuje automatyczny HTTPS i forwarding wildcard.

Najczęstsze błędy

Przekierowanie tylko strony głównej

To klasyczny błąd „na homepage działa”. Prawdziwi użytkownicy nie odwiedzają wyłącznie /.

Pominięcie non-www i domeny głównej

Trzeba przemyśleć:

• stara-marka.example
• www.stara-marka.example
• ewentualne subdomeny, jeśli są w scope migracji

Zgubienie parametrów kampanii

Nawet jeśli SEO wygląda dobrze, atrybucja może rozjechać się z dnia na dzień.

Tworzenie wielu skoków

Path forwarding traci sens, jeśli żądanie odbija się po drodze przez dwa albo trzy hosty pośrednie.

Mieszanie HTTP i HTTPS bez spójnej logiki

Jeśli stary host nie radzi sobie z HTTPS, użytkownik może zobaczyć błąd bezpieczeństwa jeszcze zanim dotrze do nowego celu.

Praktyczny wzorzec konfiguracji w UrlEdge

Dla typowej trwałej migracji:

1. podłącz starą domenę
2. włącz HTTPS
3. utwórz regułę wildcard
4. zachowaj ścieżkę
5. zachowaj wymagane parametry query
6. przetestuj najważniejsze strony przez Redirect Checker

To szczególnie wygodne, jeśli chcesz przeprowadzić migrację bez budowania logiki przekierowań w Nginx, Apache albo app middleware.

FAQ

Czy mogę przekierować domenę główną i zachować ścieżkę?

Tak, jeśli warstwa przekierowań obsługuje forwarding dla root domeny i zachowanie ścieżki. To bardzo częsty wzorzec przy migracjach.

Czy zawsze warto zachowywać query string?

Nie zawsze, ale trzeba to robić świadomie. Zachowuj parametry śledzące, kampanijne i funkcjonalne, które mają znaczenie. Parametry-śmieci odrzucaj tylko wtedy, gdy masz pewność, że nic nie zepsują.

Czy wildcard forwarding wystarczy przy każdej migracji?

Nie. Niektóre migracje wymagają mapowania jeden do jednego dla zmienionych ścieżek. Wildcard działa świetnie wtedy, gdy struktura URL jest w większości zachowana.

Czy mogę to przetestować, zanim zmienię DNS dla wszystkich?

Tak. Najpierw przetestuj wszystko na stagingu albo hostach kontrolowanych, a dopiero potem zweryfikuj próbkę realnych ścieżek przed pełnym cutoverem.

Powiązane materiały UrlEdge

• Free Redirect Service
• Permanent 301 Redirects
• Dokumentacja DNS
• Website migration redirect checklist

Rzetelne źródła

• Google Search Central: site move with URL changes
• MDN: Redirections in HTTP