Hogyan migrálj domaint anélkül, hogy padlóra küldenéd a keresési rangsorolásaidat

A domainváltás azon kevés SEO-projektek egyike, ahol egy technikailag apró hiba nagyon gyorsan nagyon láthatóvá válhat. Egy hiányzó átirányítás, egy blokkolt feltérképezési útvonal vagy egy elfelejtett kanonikus jelölés egy egyszerű rebrandinget hetekig tartó rangsorolási ingadozássá alakíthat.

Némi mozgás normális. A keresőmotoroknak időre van szükségük ahhoz, hogy feltérképezzék a régi URL-eket, felfedezzék az átirányításokat, feldolgozzák a jeleket, és az új domaint beillesszék az indexbe. A cél nem az, hogy minden visszaesést elkerülj. A cél az, hogy a migráció unalmas legyen: egy régi URL egy vele egyenértékű új URL-re mutat, a szerver egyértelműen válaszol, és semmi fontos nem tűnik el.

Kezdd leltárral, ne átirányítási szabállyal

A leggyakoribb migrációs hiba az, amikor a folyamatot szerverkonfigurációs feladatként kezelik. Nem az. Ez egy információarchitektúra-feladat, amely történetesen szerverkonfigurációban végződik.

Mielőtt hozzányúlnál a DNS-hez, készíts listát a fontos URL-ekről:

• URL-ek, amelyek organikus forgalmat kapnak
• URL-ek külső backlinkekkel
• URL-ek, amelyek konvertálnak, leadeket generálnak vagy kampányokat támogatnak
• A jelenlegi XML sitemapben szereplő kanonikus URL-ek
• PDF-ek, képek és letölthető fájlok, amelyekre külső hivatkozások mutatnak
• Nagy értékű régi URL-ek, amelyek nem feltétlenül jelennek meg a jelenlegi navigációban

Minden régi URL-hez rendelj hozzá egy céloldalt az új domainen. A legtöbb esetben ennek a céloldalnak ugyanannak az oldalnak kell lennie, ugyanazzal a szándékkal. Ha a /pricing ebből https://newdomain.com/pricing lesz, az egyszerű. Ha három régi termékoldalt egy új útmutatóba vonsz össze, dokumentáld ezt a döntést tudatosan.

Kerüld a lusta mintát: mindent az új kezdőlapra irányítani. Kényelmes, de eldobja a relevanciát. A keresőmotorok és a felhasználók egyaránt azt várják, hogy a céloldal ugyanarra az igényre adjon választ, mint az eredeti URL.

Őrizd meg az URL-struktúrát, ahol lehet

A domainmigráció könnyebb, ha az útvonalak stabilak maradnak. Az oldsite.com/blog/example áthelyezése ide: newsite.com/blog/example sokkal tisztább, mint egyszerre megváltoztatni a domaint, a CMS-t, a slugokat, a mappastruktúrát és a tartalmat.

Néha egy redesign vagy CMS-migráció elkerülhetetlenné teszi az URL-változásokat. Ilyenkor válaszd szét a döntéseket:

1. Mi változik azért, mert a domain változik?
2. Mi változik azért, mert a webhely struktúrája változik?
3. Mi törlődik, olvad össze vagy íródik újra?

Minél több változót vezetsz be, annál nehezebb lesz később diagnosztizálni a problémákat. Ha a migráció fontos, és a jelenlegi webhely jól teljesít, érdemes megfontolni, hogy először a domaint költözteted át, és csak később végzed el a redesignt.

Használj végleges, egyugrásos átirányításokat

Valódi domainmigrációhoz használj szerveroldali 301 vagy 308 átirányításokat a régi URL-ekről az új megfelelőikre. Az ideiglenes átirányítások ideiglenes helyzetekre valók. A JavaScript-átirányítások, a meta refresh és a soft redirect gyengébb jelzések, és könnyebben elromlanak.

Az átirányítási célok egyszerűek:

• Minden fontos régi URL végleges átirányítást ad vissza.
• Minden átirányítás közvetlenül a végső célra mutat.
• A HTTP tisztán irányít át HTTPS-re.
• A www és nem www változatok következetesen vannak kezelve.
• Az átirányítások csak akkor függnek törékeny query-string viselkedéstől, ha ez szükséges.

Egy rossz lánc így néz ki:

http://oldsite.com/page → https://oldsite.com/page → https://www.oldsite.com/page → https://newsite.com/page → https://www.newsite.com/page

Ez végül talán a megfelelő oldalra érkezik, de lassú, nehezebben feltérképezhető, és nagyobb eséllyel rejti el a hibákat. Törekedj arra, hogy minden régi változatból egyetlen ugrás vezessen a végső új URL-re.

A viselkedés ellenőrzésekor a tényleges HTTP-válaszokat vizsgáld, ne azt, amit a böngésző mutat. A debugging redirects and HTTP headers in production útmutatónk hasznos itt, mert a böngészők túl udvariasak: követik a láncot, és elrejtik a rendezetlen részeket.

Készítsd elő a DNS-t és a tanúsítványokat az indítás előtt

A DNS közvetlenül nem viszi át a rangsorolásokat, de a rossz DNS miatt a migráció hibásnak tűnhet. Az indítási ablak előtt csökkentsd a TTL-értékeket, hogy a változások kiszámíthatóbban terjedjenek. Ellenőrizd, hogy az új domain helyes rekordokkal rendelkezik-e a webes forgalomhoz, az e-mailhez és minden szükséges aldomainhez.

Mindkét domainhez érvényes TLS-tanúsítványokra is szükség van. Ezt könnyű figyelmen kívül hagyni. A régi domainnek a migráció után is HTTPS-átirányításokat kell kiszolgálnia. Ha lejár a tanúsítványa, a felhasználók és a crawlerek böngészőfigyelmeztetésekbe ütközhetnek, mielőtt egyáltalán elérnék az új webhelyet.

Ha a költözés az e-mailt is érinti, ne kezeld utólagos gondolatként. A domainváltozások gyakran eltörik az SPF, DKIM, DMARC, MX rekordokat, a követési linkeket és a tranzakciós leveleket. A fontos rekordok áttekintéséhez lásd fejlesztőbarát útmutatónkat: MX, SPF, DKIM, and DMARC.

Ellenőrizd a kanonikus jelöléseket, a belső linkeket és a sitemapeket

Indítás után az új domainnek úgy kell viselkednie, mintha mindig is ez lett volna a tartalom kanonikus otthona.

Ez azt jelenti:

• A canonical tagek az új URL-ekre mutatnak, nem a régi domainre.
• A belső linkek az új domaint vagy gyökérrelatív útvonalakat használnak.
• Az XML sitemapek csak végleges, indexelhető új URL-eket tartalmaznak.
• A hreflang annotációk, ha vannak, az új URL-ekre hivatkoznak.
• Az Open Graph, a strukturált adatok és az alternatív linkek frissítve vannak.
• A Robots.txt nem blokkol fontos szakaszokat.

Ne publikálj régi URL-ekkel teli sitemapet abban a hitben, hogy az átirányítások majd rendbe teszik. A sitemap olyan URL-ek listája legyen, amelyeket indexeltetni szeretnél. Migráció után ez a végső URL-eket jelenti az új domainen.

Figyelj a kanonikus ellentmondásokra is. Az az oldal, amely a régiről az újra irányít át, de canonical jelöléssel visszamutat a régi domainre, vegyes jeleket küld. A keresőmotorok általában képesek kezelni némi következetlenséget, de nem érdemes ezt kérni tőlük.

Ne változtass meg mindent az indítás napján

Egy migráció önmagában is elég nagy esemény. Ha lehet, kerüld, hogy jelentős tartalomritkítással, sablonok újraírásával, navigációs változtatásokkal, JavaScript-renderelési változásokkal vagy új teljesítményprofillal kösd össze.

Ez nem babona. Ez hibakeresési fegyelem. Ha az indítás után esnek a rangsorolások, tudnod kell, hogy az ok az átirányítási leképezés, a feltérképezési hozzáférés, a megváltozott tartalom, a lassabb renderelés, a hiányzó strukturált adatok vagy valami más volt-e.

Az első indítást tartsd a lehető legközelebb a régi webhelyhez. Amikor az új domain stabil, nagyobb szerkesztői és designváltozásokat kisebb csomagokban végezz.

Mondd el a keresőmotoroknak, mi változott

A Google Search Console-ban igazold mind a régi, mind az új domaint. Ezután használd a Change of Address eszközt, ha a költözés domainszintű változás, és a tartalom új domainre kerül. Indítás után küldd be az új sitemapet.

Ez nem helyettesíti az átirányításokat. Támogatja őket. A keresőmotoroknak továbbra is feltérképezhető, tartós átirányításokra van szükségük ahhoz, hogy megértsék az URL-szintű leképezést.

A Bing és más keresőmotorok esetében használd az elérhető webmaster tools felületeiket. Frissítsd azokat a helyeket is, amelyeket te kezelsz: közösségi profilok, üzleti adatlapok, hirdetési céloldalak, e-mail-láblécek, dokumentáció, partnerlinkek és a szindikált tartalmak kanonikus hivatkozásai.

Nem fog minden külső link frissülni, és ez rendben van. De a legfontosabbaknak érdemes. Ha egy jelentős partner, app marketplace, dokumentációs portál vagy sajtóoldal a régi domainre hivatkozik, kérj frissítést.

Indítás után a megfelelő dolgokat figyeld

A migráció utáni első néhány nap aktív monitorozásról szóljon, ne ünneplésről.

Ellenőrizd:

• Szervernaplókat a régi és új domaineken zajló feltérképezési aktivitáshoz
• 404-es és váratlan 5xx hibákat
• Átirányítási láncokat és hurkokat
• Indexelési állapotot a Search Console-ban
• Sitemap-felfedezést és -feldolgozást
• Organikus érkező oldalakat és lekérdezési mintákat
• Konverziós útvonalakat, amelyek régi URL-ektől függenek
• Analytics-szűrőket és hivatkozási kizárásokat

Számíts jelentési zajra. Egyes analytics eszközök az új domaint új tulajdonként kezelik, ha nincsenek megfelelően konfigurálva. Egyes dashboardok a régi domain forgalmát hasonlítják az új domain forgalmához, és rosszabbnak mutatják a migrációt, mint amilyen valójában.

A keresési láthatóság néhány hétig ingadozhat. Amit nem szeretnél látni, az olyan minta, ahol a nagy értékű régi URL-eket ismételten feltérképezik, de nem irányítják át megfelelően, vagy ahol az új oldalakat felfedezik, de a régi domain duplikátumaiként jelölik meg.

A teljesítményt sem szabad figyelmen kívül hagyni. Ha az új domain nehezebb sablonokkal, hibás gyorsítótárazással vagy nem optimalizált assetekkel indul, a felhasználók lassulásként érzékelhetik a migrációt. Ha a Lighthouse is része az ellenőrzéseidnek, prioritásokkal a fejedben olvasd; a how to read a Lighthouse report without panicking cikkünk elmagyarázza, hogyan válaszd el a valóban fontos problémákat a zajtól.

Tartsd meg a régi domaint hosszú ideig

Ne hagyd lejárni a régi domaint azután, hogy a migráció „működik”. Tartsd regisztrálva, tartsd érvényben a tanúsítványokat, és futtasd az átirányításokat ameddig csak lehet. A gyakorlatban ez gyakran éveket jelent.

A régi linkek tovább élnek blogbejegyzésekben, könyvjelzőkben, dokumentációban, PDF-ekben, e-mailekben és közösségi posztokban. Az átirányítások jelentik a hidat a történeti lábnyom és az új domain között. Ha túl korán kikapcsolod őket, megszakítod a felhasználók útvonalait, és elpazarolod a felhalmozott jeleket.

Őrizd meg az átirányítási térkép és az indítási jegyzetek egy példányát is. Hat hónappal később, amikor valaki megkérdezi, miért viselkedik egy legacy URL egy bizonyos módon, örülni fogsz, hogy dokumentáltad.

<!-- tool-cta:start -->

💡 Próbálja ki ezt: Az átállás után kövesse végig a régi URL-jeit a Redirect Checker segítségével, hogy megerősítse, mindegyik egyetlen 301-es ugrással a megfelelő új oldalra fut be.

<!-- tool-cta:end -->

Ésszerű migrációs ellenőrzőlista

Indítás előtt:

• Igazold mindkét domaint a Search Console-ban.
• Térképezd fel a jelenlegi webhelyet, és exportáld a fontos URL-eket.
• Építs egy-egy megfeleltetésű átirányítási térképet.
• Csökkentsd a DNS TTL-eket.
• Készítsd elő a TLS-tanúsítványokat a régi és az új domainhez.
• Frissítsd a kanonikus jelöléseket, a belső linkeket, a hreflanget, a strukturált adatokat és a sitemapeket.
• Teszteld az átirányításokat stagingben vagy kontrollált környezetben.

Az indítás napján:

• Élesítsd az átirányításokat.
• Ellenőrizd a HTTP-ről HTTPS-re váltás viselkedését.
• Tesztelj fontos URL-mintákat minden sablontípusból.
• Küldd be az új sitemapet.
• Használd a Change of Address eszközt, ahol indokolt.
• Figyeld a szerverhibákat, az átirányítási hurkokat és a blokkolt erőforrásokat.

Indítás után:

• Monitorozd a feltérképezési hibákat és az indexelési jelentéseket.
• Frissítsd a fontos külső linkeket, ahol tudod.
• A forgalmat érkező oldali szándék szerint hasonlítsd össze, ne csak domainösszesítések alapján.
• Tartsd életben az átirányításokat határozatlan ideig.
• Halaszd el a nem kapcsolódó redesignt vagy tartalmi kísérleteket, amíg a költözés stabilizálódik.

A domainmigrációk nem kockázatmentesek, de kezelhetők. A rangsorolások általában akkor sérülnek, amikor a migráció nem egyértelmű jeleket küld: hiányzó átirányítások, megváltozott tartalom, ellentmondó kanonikus jelölések, blokkolt crawlerek vagy elfelejtett régi domain. Adj a keresőmotoroknak és a felhasználóknak tiszta térképet, és a költözés sokkal kevésbé lesz drámai.