A domainnév cseréje technikailag jól körülírható művelet, üzletileg viszont az egyik legkockázatosabb dolog, amit egy működő weboldallal tehetsz. Cégnév-váltás, márkaváltás, tulajdonosváltás vagy egyszerűen egy jobb domain megszerzése után ugyanaz a kérdés jön: hogyan viszed át a régi cím mögött felhalmozott bizalmat úgy, hogy közben a keresőforgalom ne omoljon össze. A rossz hír az, hogy teljes, nulla veszteségű átvezetés nem létezik. A jó hír az, hogy a veszteség nagyságrendje szinte teljes egészében azon múlik, mennyire vagy alapos a váltás előtti két hétben és utána a következő fél évben.
Mitől lesz kockázatos egy domainváltás?
Rövid válasz: attól, hogy a keresők és a válaszmotorok nem a márkádat ismerik, hanem konkrét URL-eket. Minden egyes cím külön entitás, saját előzménnyel, saját hivatkozásokkal, saját indexelési múlttal. Amikor domaint váltasz, egyszerre több ezer ilyen entitást szüntetsz meg, és helyettük több ezer újat hozol létre, amiről a kereső semmit nem tud.
Tovább a témában: Domainváltás vagy platformváltás előtti technikai ellenőrzőlista · Weboldal újratervezés Zalaegerszegen
Hivatalosan igazolt: a Google dokumentációja szerint a 301-es (állandó) átirányítás a helyes eszköz a címváltásra, és az átirányított URL-ek jelzései átszállnak az új címre. Szakmai feltételezés: ez az átszállás nem azonnali és nem is súrlódásmentes, mert az újrafeldolgozás tempója a bejárási gyakoriságtól függ, ami oldalanként nagyon eltérő. Egy naponta bejárt főoldal napok alatt átáll, egy évente egyszer meglátogatott mély aloldal hónapokig a régi címen szerepelhet.
Hogyan készíts teljes URL-térképet a régi oldalról?
Az URL-térkép a váltás gerince: egy táblázat, amiben minden létező régi cím szerepel, mellette a válasz-státuszkóddal, a forgalmával és az új párjával. Ne a CMS exportjából indulj ki, mert az mindig kevesebbet mutat a valóságnál. Öt forrást fésülj össze:
- Crawl (Screaming Frog vagy hasonló) a főoldalról indítva, belső linkek mentén, a képek és PDF-ek is számítanak.
- A régi sitemap.xml minden bejegyzése, akkor is, ha egy része már elavult.
- Search Console Oldalak és Teljesítmény riport, 16 hónapos ablakkal, URL-bontásban exportálva. Itt jönnek elő azok a címek, amiket sehonnan nem linkelsz, mégis hoznak forgalmat.
- GA4 céloldal-riport legalább 12, jobb esetben 24 hónapra visszamenőleg.
- Szerver access log, ha hozzáférsz. Ez mutatja meg, mit jár be ténylegesen a Googlebot, és mit hívogatnak az AI-crawlerek.
Ezt a listát deduplikáld, majd rendezd forgalom szerint. Saját tapasztalat: egy néhány száz oldalas céges weboldalnál jellemzően az URL-ek 15-20 százaléka adja a szerves forgalom 80 százalékát. Ezt a felső réteget kézzel kell végignézni, a többit szabály alapján lehet kezelni. A hivatkozott URL-eket külön oszlopban jelöld a Search Console Linkek riportja alapján, mert ezek akkor is fontosak, ha alig van forgalmuk.
Mit jelent pontosan az 1:1 megfeleltetés?
Azt, hogy minden régi cím olyan új címre mutat, ami tartalmilag ugyanazt a kérdést válaszolja meg. Nem hasonlót, nem kategóriaoldalt, nem főoldalt.
Hivatalosan igazolt: a Google azokat az átirányításokat, amelyek nem releváns célra vezetnek (tipikusan mindent a főoldalra), soft 404-ként kezelheti, vagyis a jelzés-átadás elmarad. Ez a domainváltás leggyakoribb tömeghibája.
Ha az útvonalstruktúra változatlan marad, a munka nagy része egyetlen szabállyal megoldható, és csak a maradékot kell kézzel párosítani. Ha a struktúra is változik, készíts egy két oszlopos leképezési fájlt, és azt töltsd be a szerverbe. Ahol tényleg nincs megfelelő új tartalom, ott a helyes válasz a 410-es státusz, nem az erőltetett átirányítás.
Hogyan állítsd be a 301-es átirányítást szerverszinten?
Szerverszinten, nem plugin szinten. Egy WordPress-bővítmény akkor sem fut le, ha az oldal éppen hibás, a szerverkonfiguráció viszont mindig válaszol. Apache alatt a régi domain gyökerében:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?regidomain\.hu$ [NC]
RewriteCond %{REQUEST_URI} !^/(sitemap\.xml|robots\.txt)$
RewriteRule ^(.*)$ https://ujdomain.hu/$1 [R=301,L]
Nginx alatt ugyanez egy külön szerverblokkban:
server { listen 443 ssl; server_name regidomain.hu www.regidomain.hu; return 301 https://ujdomain.hu$request_uri; }
Négy részlet, ami a gyakorlatban a legtöbbször elromlik:
- A régi domainre is kell érvényes SSL-tanúsítvány. A régi címre mutató linkek jó része https-sel jön be. Tanúsítvány nélkül a látogató és a robot is tanúsítványhibát kap, mielőtt az átirányítás lefutna. Ez a hiba önmagában képes elvinni a váltás hasznát.
- Egy ugrás, ne lánc. A régi http, a régi www és a régi https mind közvetlenül az új végleges címre menjen, ne egymáson keresztül.
- A robots.txt és a sitemap.xml maradjon kivétel a régi domainen, különben a kereső nem tudja újra beolvasni a régi címeket.
- Paraméterek és ékezetes útvonalak maradjanak érintetlenek az átirányítás során. A
$request_uriezt megőrzi, a kézzel összefűzött célcím gyakran nem.
Miért kell átmenetileg két sitemap?
Mert a keresőnek látnia kell a régi URL-eket ahhoz, hogy észrevegye a rajtuk lévő 301-et. Ha a régi sitemap eltűnik, a ritkán bejárt aloldalak esetében hónapokat vársz arra, amit napokban is meg lehetne úszni.
A gyakorlat: az új domainen élesíts friss sitemapot csak az új URL-ekkel, és küldd be a Search Console-ba. A régi domainen hagyd elérhetőnek a régi sitemapot a régi címekkel, és a régi property-ben azt is küldd be újra, hogy friss feldolgozási dátumot kapjon. Saját tapasztalat: 4-8 hét után a régi sitemapból eltűnik a haszon, ekkor nyugodtan levehető. Addig viszont mérhetően gyorsítja a felismerést, főleg a nagyobb, mély struktúrájú oldalaknál.
Mire jó a Search Console címváltoztatás eszköze?
Arra, hogy explicit jelzést adj a Google-nek: ez a két property ugyanaz a weboldal, csak új címen. Hivatalosan igazolt: az eszköz használatához mindkét property-t igazolnod kell ugyanabban a fiókban, és a régi oldalnak már működő 301-gyel kell az újra mutatnia, mielőtt a kérést elküldöd. A jelzés nem örök életű, a dokumentáció szerint hónapokig, nagyságrendileg fél évig segíti az átvezetést, tehát nem helyettesíti a szerveroldali átirányítást, csak megelőzi.
Amire viszont nem való: protokollváltás (http-ről https-re) és www-váltás esetén nem használható, mert azt a Google magától kezeli. Több régi domain összevonásánál mindegyik régi property-hez külön kell beküldeni a kérést.
Kell-e szólni a külső hivatkozóknak?
A legfontosabb 20-50-nek igen, a többinek nem éri meg. A 301 elvégzi a munka nagy részét, a linkfrissítés viszont két dolgot ad hozzá: kiveszi a láncot a rendszerből, és biztosítja, hogy a hivatkozás akkor is éljen, ha a régi domain egyszer mégis eltűnik.
A gyakorlati sorrend: saját tulajdonú felületek először (közösségi profilok, Google cégprofil, e-mail aláírás, számlázó, hírlevélsablon, hirdetési fiókok céloldalai, jelentkezési űrlapok, QR-kódok mögötti linkek), utána a partnerek és szakmai katalógusok, végül a szerkesztőségi említések. Saját tapasztalat: a személyes megkeresésre a katalógusok és partnerek jelentős része javít, a nagyobb hírportálok szinte soha, ezért ott a 301-re kell hagyatkozni. Csak olyan elérhetőségre írj, amit az adott fél maga adott meg.
Meddig kell fenntartani a régi domaint, és mi történik, ha lejár?
Hivatalosan igazolt: a Google azt javasolja, hogy az átirányításokat legalább egy évig tartsd fenn. Saját nézőpont: ez a minimum, nem a cél. A domainváltás legdrágább hibája nem az átirányítás hiánya, hanem a régi domain túl korai elengedése, mert ez az egyetlen lépés, amit később nem lehet visszacsinálni.
Ha a régi domain lejár, a következő történik: az összes régi hivatkozás egyszerre elveszti az értékét, a régi címre mutató könyvjelzők, QR-kódok és nyomtatott anyagok hibára futnak, és a domaint bárki megveheti. Ha felvásárolja egy linkfarm vagy egy versenytárs, a márkanevedre a saját régi címed kezd el idegen tartalmat szolgálni. Ehhez jön a legkellemetlenebb rész: a régi domainre épített e-mail címek. Ha azokkal regisztráltál bárhol (bank, tárhely, hirdetési fiók, közösségi oldal, számlázó), a jelszó-visszaállítás lehetősége is elveszik a domainnel együtt.
Ezért a gyakorlati ajánlás: a régi domaint tartsd meg legalább 3-5 évig, ismert márkanév esetén határozatlan ideig, és regisztráld többéves ciklusra automatikus megújítással. Az átirányítás fenntartása nem igényel külön weboldalt, elég egy minimális tárhely vagy egy DNS-szintű átirányítási szolgáltatás.
Miért fontos ez az AI-válaszmotorok szempontjából?
Szakmai feltételezés: a nyelvi modellek tanítóadata és a válaszmotorok gyorsítótára jóval lassabban frissül, mint a keresőindex, ezért a régi domain még hónapokkal a váltás után is felbukkanhat forrásmegjelölésként vagy szövegbeli említésként. Ilyenkor a felhasználó a régi címre kattint, és pontosan az él 301-en múlik, hogy megérkezik-e hozzád. Ez további érv a régi domain hosszú fenntartása mellett, és amellett is, hogy a leggyakrabban idézett oldalaidnál az új struktúrában is beszédes, stabil URL-eket használj.
Mi legyen az ellenőrzőlistán a váltás napján?
- Az új domain teljes tartalommal, működő SSL-lel, indexelhetően él (nincs
noindex, nincs tiltó robots.txt a fejlesztési fázisból). - Minden kanonikus címke az új domain saját URL-jére mutat.
- A 301-ek élnek, és mintavételesen legalább 30 URL-en ellenőrizve egy ugrásban érnek célba.
- A régi domain SSL-tanúsítványa érvényes.
- A robots.txt és a sitemap.xml kivételként elérhető a régi domainen.
- Új property létrehozva és igazolva a Search Console-ban, új sitemap beküldve.
- A címváltoztatás kérés elküldve a régi property-ből.
- Belső linkek, menük, űrlap-visszairányítások átírva az új abszolút címre.
- Analitika: GA4 adatfolyam és mérőkód ellenőrizve, a régi property megtartva összehasonlításhoz.
- Hirdetési fiókok céloldalai és követő paraméterei frissítve.
- E-mail: SPF, DKIM és DMARC beállítva az új domainre, a régi címekről továbbítás bekapcsolva.
- Strukturált adatok, cégprofil és NAP-adatok frissítve.
Mit ellenőrizz a 30. napon?
- Indexelt oldalak száma az új property-ben (emelkedő), a régiben (csökkenő).
- Az összesített kattintásszám a két property adatait összeadva, nem külön nézve.
- Feltérképezési hibák és soft 404-ek az új property-ben.
- Átirányítási láncok: nulla darab hosszabb, mint egy ugrás.
- A top 50 régi URL mindegyike a helyes új párjára megy, nem a főoldalra.
- A Linkek riport az új property-ben mutatja-e már a hivatkozó domaineket.
- A régi domain megújítási dátuma és automatikus hosszabbítása bekapcsolva.
- A régi sitemap levehető-e, vagy még hoz feldolgozást.
Hogyan néz ki a forgalom természetes visszaesése és visszaépülése?
A minta, amit tiszta technikai kivitelezés mellett jellemzően látni a Search Console-ban, illusztratív számokkal, napi 400 kattintásos kiindulásból (ez modell, nem ígéret és nem konkrét mérés):
- 1-3. nap: a régi property impressziói zuhannak, az új property nulláról indul. Az összesített szám látszólag összeomlik, mert két helyen nézed.
- 1-2. hét: az összesített kattintás jellemzően 10-30 százalékkal a kiindulás alatt, a példában 280-360 körül. A márkanévre és a legerősebb oldalakra érkező forgalom áll vissza először.
- 3-6. hét: a hosszú farok visszaépül, a példában 340-400 közé mászik vissza a napi szám.
- 8-12. hét: stabilizálódás, jó eséllyel a kiindulás közelében vagy kicsit felette, ha közben a tartalom is javult.
Saját tapasztalat: ha a 6-8. hét után sincs érdemi visszaépülés, akkor nem türelemre van szükség, hanem hibakeresésre. A leggyakoribb okok sorrendben: átirányítási lánc, a fejlesztésből bent maradt noindex, a régi domainre mutató kanonikus címkék, hiányzó SSL a régi domainen, és a mindent a főoldalra irányító szabály.
Fontos módszertani pont: a Search Console a régi és az új property adatait soha nem összegzi. Készíts a váltás napjától egy közös táblázatot vagy Looker Studio nézetet, ami a két forrást összeadja, különben a saját riportod fogja azt mutatni, hogy összeomlott a forgalom.
Források és további olvasnivalók
- Google Search Central: Site moves with URL changes
- Google Search Central: Change of Address tool (Search Console súgó)
- Google Search Central: Redirects and Google Search
- Google Search Central: Soft 404 errors dokumentáció
- Google Search Console súgó: Sitemaps report, Links report, Page indexing report
- Schema.org: Organization és WebSite típusok
- W3C / IETF RFC 9110: HTTP Semantics (301 Moved Permanently)
- MDN Web Docs: HTTP redirections
- Minden régi URL-nek konkrét, tartalmilag megfelelő új párja legyen, ne a főoldal.
- A 301 szerverszinten, egyetlen ugrásban vezessen az új cím https-változatára, lánc nélkül.
- A régi domain sitemapját és robots.txt-jét hagyd ki az átirányításból, hogy a Google újra bejárhassa a régi URL-eket.
- A Search Console címváltoztatás eszköze gyorsít, de nem helyettesíti a szerveroldali átirányítást.
- A régi domaint legalább egy évig kötelező, üzletileg viszont évekig érdemes fenntartani, mert a lejárat visszavonhatatlan.
Gyakori kérdések
Meddig kell fenntartani a régi domaint domainváltás után?
A Google hivatalos ajánlása szerint az átirányításokat legalább egy évig fenn kell tartani, de gyakorlati okokból 3-5 év a reális minimum, ismert márkanévnél pedig érdemes határozatlan ideig megtartani. A régi domain elengedése az egyetlen visszafordíthatatlan lépés a folyamatban.
Mi történik, ha a régi domain lejár?
Az összes régi hivatkozás értéke elvész, a régi címekre mutató könyvjelzők és nyomtatott anyagok hibára futnak, és a domaint bárki megveheti, akár versenytárs vagy spam oldal is. A legsúlyosabb következmény általában az e-mail: a régi domainen lévő címekkel regisztrált fiókok jelszó-visszaállítási lehetősége is megszűnik.
Elég, ha mindent a főoldalra irányítok át?
Nem. A Google a nem releváns célra mutató átirányításokat soft 404-ként kezelheti, vagyis a jelzések nem szállnak át. Minden régi URL-nek olyan új címre kell mutatnia, ami tartalmilag ugyanazt a kérdést válaszolja meg, és ahol nincs ilyen tartalom, ott a 410-es státusz a helyes válasz.
Kell a Search Console címváltoztatás eszköz, ha már beállítottam a 301-eket?
A 301 a kötelező elem, a címváltoztatás eszköz pedig egy explicit jelzés, ami gyorsíthatja a felismerést. Használatához mindkét property igazolása és működő átirányítás szükséges, protokoll- vagy www-váltásnál viszont nem használható, mert azt a Google magától kezeli.
Mennyi forgalomvesztésre kell számítani?
Tiszta kivitelezésnél jellemzően átmeneti, egy-két hetes visszaesés látszik, majd néhány héten belül induló visszaépülés, de ez nem garantálható, mert a bejárási tempó és a versenyhelyzet oldalanként eltér. Ha 6-8 hét után sincs javulás, technikai hibát kell keresni, nem tovább várni.
Miért kell átmenetileg meghagyni a régi sitemapot?
Mert a kereső csak akkor látja a régi URL-eken lévő 301-et, ha újra bejárja azokat a címeket. Ehhez a régi sitemap.xml-t (és a robots.txt-t) ki kell venni az átirányítási szabály alól, különben maga a sitemap is átirányítódik, és használhatatlanná válik.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.