Piotr Maćkówka
Wszystkie wpisy

2 czerwca 2026

Migracja domeny bez utraty SEO — z subdomeny Netlify na własny adres

  • SEO
  • Netlify
  • Astro
  • DevOps

Gdy przenosiłem to portfolio z piotrm.netlify.app na własną domenę pmdata.pl, miałem jedną obawę: że przez jakiś czas obie wersje będą żyły równolegle, Google zobaczy dwie identyczne strony i potraktuje to jako duplicate content. Obawa była słuszna — ale rozwiązanie okazało się prostsze, niż się spodziewałem. Pod warunkiem, że zrobi się cztery rzeczy w kodzie i trzy w Search Console. I że ominie się kilka pułapek, których nie ma w żadnym poradniku.

Na czym polega problem

Subdomena hostingu (*.netlify.app, *.vercel.app) nie znika, gdy podepniesz własną domenę. Działa dalej i serwuje tę samą treść. Dwa adresy, identyczna zawartość — klasyczny duplicate content. Google sam zdecyduje, którą wersję indeksować, i niekoniecznie wybierze tę, na której Ci zależy.

Celem migracji jest więc nie tylko „żeby działało pod nową domeną”, ale żeby cała wartość SEO przeszła na nowy adres, a stary przestał z nim konkurować.

Plan: cztery zmiany w kodzie

Projekt to statyczna strona w Astro hostowana na Netlify. Konfiguracja adresu siedzi w kilku miejscach:

1. Kanoniczny URL. W Astro to jedno pole site w astro.config.mjs. Z niego generują się tagi <link rel="canonical">, Open Graph i sitemap — zmiana w jednym miejscu propaguje się wszędzie.

// astro.config.mjs
export default defineConfig({
  site: 'https://pmdata.pl', // było: piotrm.netlify.app
});

2. Sitemap w robots.txt. Wpis Sitemap: musi wskazywać nową domenę, inaczej kierujesz boty pod stary adres.

3. Przekierowanie 301 z subdomeny — to jest sedno. W netlify.toml:

[[redirects]]
  from = "https://piotrm.netlify.app/*"
  to = "https://pmdata.pl/:splat"
  status = 301
  force = true

4. Przekierowanie www → domena główna — dla pewności, choć Netlify robi to sam dla domeny primary (patrz Pułapka 1). Dokładam regułę jawnie, żeby konfiguracja była czytelna i przenośna, gdybym kiedyś zmienił hosting.

Pułapka 1: www Netlify ogarnia sam, subdomeny .netlify.app — nie. Gdy ustawisz domenę jako primary, Netlify automatycznie przekierowuje www na wersję bez www. Ale subdomeny *.netlify.app nie przekierowuje — to musisz zrobić ręcznie regułą w netlify.toml. I akurat bez tej reguły Change of Address w Search Console by nie przeszło (o tym niżej).

Canonical sam nie wystarczy. <link rel="canonical"> to dla Google sugestia, nie rozkaz. Przy świeżej stronie bez backlinków zadziała, ale naprawdę czystym rozwiązaniem jest twardy 301 — fizyczne przekierowanie, które nie zostawia miejsca na interpretację.

Pułapka 2: zmiana nazwy projektu Netlify nie usuwa subdomeny. Pierwszy odruch, żeby pozbyć się starego adresu, to zmienić nazwę projektu w Netlify (piotrm → coś innego). To nic nie daje — dostajesz po prostu nową subdomenę (nowa-nazwa.netlify.app), a duplicate content zostaje. Subdomeny *.netlify.app nie da się wyłączyć. Jedyne wyjście to 301, nie zmiana nazwy.

Trzy kroki w Google Search Console

Kod to połowa roboty. Druga połowa to powiedzenie Google’owi, że się przeprowadzasz.

1. Nowa property dla domeny. Dodaj pmdata.pl jako property typu Domain (nie URL-prefix) — pokrywa od razu http/https i www/bez-www. Weryfikacja przez rekord TXT w DNS.

Pułapka 3: GTM nie zweryfikuje property typu Domain. Jeśli masz wpięty Google Tag Manager, kuszące jest zweryfikować przez niego własność. Ta metoda działa jednak tylko dla property typu URL-prefix. Dla Domain jedyna opcja to rekord TXT. A jeśli DNS trzyma hosting (u mnie Netlify DNS), rekord dodajesz w panelu hostingu, nie u rejestratora domeny.

2. Prześlij sitemap. W nowej property: Mapy witryn → pełny URL https://pmdata.pl/sitemap-index.xml.

3. Change of Address. Najważniejszy krok — oficjalnie sygnalizuje Google „ta witryna się przeprowadza” i przyspiesza przeniesienie sygnałów rankingowych. W ustawieniach starej property (URL-prefix subdomeny) → Zmiana adresu → wskaż nową domenę.

Pułapka 4: Change of Address wymaga DZIAŁAJĄCEGO 301. Narzędzie nie zadziała, dopóki stary adres faktycznie nie przekierowuje 301 na nowy — i to musi być już na produkcji. U mnie najpierw wyrzuciło „weryfikacja się nie udała”, bo redirect nie był jeszcze zdeployowany. Kolejność jest sztywna: najpierw wdróż 301, poczekaj na deploy (curl -I na starym adresie powinno zwrócić 301 i location: z nowym URL-em), dopiero potem uruchom Change of Address.

Na koniec, dla małej strony, ręcznie zażądaj zaindeksowania najważniejszych adresów (homepage, /artykuly/) przez „Sprawdzenie adresu URL” → „Żądaj indeksowania”. Resztę podstron Google znajdzie sam przez sitemap.

Czego nie usuwać

Starej property w Search Console nie kasuj od razu. Change of Address wymaga, żeby obie istniały, a po migracji Google rekomenduje trzymać starą jeszcze kilka miesięcy — do monitorowania przenoszenia ruchu i zachowania danych historycznych.

Checklist migracji

  • site w konfiguracji frameworka → nowa domena
  • Sitemap: w robots.txt → nowa domena
  • 301 z subdomeny hostingu → nowa domena
  • deploy + weryfikacja, że stary adres zwraca 301 (curl -I)
  • nowa property (Domain) w Search Console + weryfikacja TXT
  • sitemap przesłany w nowej property
  • Change of Address w starej property
  • żądanie indeksowania homepage
  • stara property zostaje (nie kasować)

Ta checklista jest jednorazowa — odhaczasz raz i zamykasz temat. Spójność SEO po migracji to inna bajka: trzeba bez końca pilnować linkowania wewnętrznego, metadanych i martwych linków. U siebie oddałem to self-review loopowi z hookami, zamiast polegać na własnej pamięci.

Podsumowanie

Migracja domeny bez utraty SEO sprowadza się do dwóch zasad: jeden twardy 301 ze starego adresu na nowy i jeden wyraźny sygnał do Google przez Change of Address. Canonical pomaga, ale to 301 robi robotę. Reszta to pilnowanie kolejności — bo połowa pułapek bierze się z tego, że coś sprawdza się, zanim deploy zdąży wejść.

Powiązane wpisy