Przekierowania 301 w .htaccess podczas migracji domeny

Gdy ktoś szuka .htaccess 301, zwykle ma bardzo konkretny problem:

• stary URL ma wskazywać nowy
• HTTP ma przejść na HTTPS
• stara domena ma zostać przeniesiona na stałe

Dla kilku reguł .htaccess nadal bywa wystarczające. Problem zaczyna się wtedy, gdy ten sam nawyk rozciąga się na pełną migrację domeny.

Praktyczna odpowiedź zwykle wygląda tak:

• dla małego zestawu stabilnych przekierowań 301 .htaccess może wystarczyć
• dla migracji domeny, rebrandu, relaunchu lub dużej mapy przekierowań szybko staje się źródłem ryzyka operacyjnego

Jeśli migracja już trwa, trzymaj też pod ręką checklistę migracji strony z przekierowaniami. Ten tekst skupia się na typowym punkcie startowym: 301 w .htaccess.

Krótka odpowiedź

Prosta reguła może wyglądać tak:

Redirect 301 /stara-strona https://www.przyklad.pl/nowa-strona

A pełne przeniesienie domeny z zachowaniem ścieżki zwykle kończy się na mod_rewrite:

RewriteEngine On
 
RewriteCond %{HTTP_HOST} ^stara-domena\.pl$ [OR]
RewriteCond %{HTTP_HOST} ^www\.stara-domena\.pl$
RewriteRule ^(.*)$ https://www.nowa-domena.pl/$1 [R=301,L]

To odpowiada na pytanie o składnię. Nie odpowiada na pytanie operacyjne:

[!TIP] Czy dalej zarządzasz kilkoma regułami, czy już workflowem migracyjnym, który potrzebuje walidacji, ownership i rollbacku?

Kiedy .htaccess nadal ma sens

Zwykle wtedy, gdy:

• liczba przekierowań jest mała
• Apache jest jedyną aktywną warstwą
• żaden CDN, proxy ani middleware nie nadpisuje ruchu
• logika ścieżek jest prosta
• ownership jest jasny

Gdzie zaczyna się psuć

1. Aktywnych jest kilka warstw przekierowań

W realnym stacku przekierowania potrafią pochodzić z:

• .htaccess
• pluginów CMS
• Nginx albo load balancerów
• Cloudflare
• middleware aplikacji

Wtedy prosta migracja zamienia się w:

http://stara-domena.pl/produkt-a
  -> https://stara-domena.pl/produkt-a
  -> https://www.stara-domena.pl/produkt-a
  -> https://www.nowa-domena.pl/sklep/produkt-a

To może jeszcze działać, ale dalej jest słabym wynikiem migracji.

2. Ścieżki i query robią się nieczytelne

Wiele zespołów testuje tylko homepage. Później okazuje się, że deep linki, docs albo UTM-y nie docierają tak, jak powinny.

3. Wildcardy przestają wystarczać

Reguła typu:

/blog/* -> /artykuly/*

wygląda porządnie, dopóki:

• kategorie nie zostały scalone
• część produktów nie zniknęła
• nie pojawiają się wyjątki

Wtedy potrzebujesz:

• jawnych mapowań
• priorytetów
• walidacji
• mapy przekierowań, którą da się zreviewować

4. Zmiany są trudne do audytu

Merge w pliku konfiguracyjnym nie jest audytem migracji.

Dość szybko zespół chce wiedzieć:

• kto zmienił co
• które reguły są nowe
• które usunięto
• gdzie są konflikty
• jak wygląda rollback

Sama .htaccess daje na to słabą odpowiedź.

Najczęstsze błędy

Rozbijanie hosta, HTTPS i celu końcowego na kilka hopów

Źle:

http://stara-domena.pl/docs/api
  -> https://stara-domena.pl/docs/api
  -> https://www.stara-domena.pl/docs/api
  -> https://www.nowa-domena.pl/docs/api

Lepiej:

http://stara-domena.pl/docs/api
  -> https://www.nowa-domena.pl/docs/api

Testowanie homepage, a pomijanie ważnych URL-i

Homepage wygląda poprawnie, ale produkty, artykuły, docs i stare adresy organiczne już nie.

Gubienie parametrów

Jeśli pomiar zależy od maili, QR, paid social albo partnerów, znikające utm_ zamieniają migrację jednocześnie w problem SEO i reportingowy.

Trzymanie prawdziwej mapy przekierowań poza warstwą live

Jeśli prawda biznesowa żyje w arkuszu, a reguły live w pliku serwera, rosną martwe pola.

Kiedy trzeba zmienić workflow

Ten moment zwykle nadchodzi, gdy:

• migrujesz setki albo tysiące URL-i
• kilka zespołów albo agencji zmienia reguły
• potrzebujesz importu CSV
• konflikty trzeba sprawdzić przed go-live
• rollback ma być jasny
• nie chcesz deployować originu przy każdej zmianie

Wtedy UrlEdge zaczyna mieć sens:

• bulk URL management dla dużych map
• redirect management dla ownership i rolloutu
• permanent 301 redirects dla trwałych migracji

Podsumowanie

Prawdziwe pytanie nie brzmi, czy .htaccess jest dobra czy zła.

Prawdziwe pytanie brzmi:

Czy twoja migracja nadal mieści się w kilku ręcznie utrzymywanych regułach serwera, czy jest już projektem routingu z zależnościami SEO, kampanii i kilku zespołów?

Jeśli to drugie, sam snippet nie jest już pełnym rozwiązaniem.