A kérdés akkor kerül elő, amikor a weboldal kinövi az eredeti kereteit: kell egy blog, jön egy webshop egy másik rendszerben, vagy indul egy angol verzió. Ilyenkor el kell dönteni, hova kerüljön az új rész. A döntés nem kozmetikai: évekre meghatározza, hogyan viselkedik a domain a keresőkben, hogyan mérhető a forgalom, és mennyi munkát ad az üzemeltetés.
Mi a különbség aldomain és alkönyvtár között technikailag?
Az alkönyvtár ugyanannak a hosztnévnek egy útvonala, az aldomain viszont önálló hosztnév, saját DNS-rekorddal. A domain.hu/blog/ ugyanaz a gép, ugyanaz a tanúsítvány, ugyanaz a robots.txt. A blog.domain.hu ezzel szemben a webszerver, a böngésző és a keresőrobotok szemében egy másik cím, ami véletlenül hasonlít a főoldalra.
Ami ebből következik a gyakorlatban (ez mind hivatalosan igazolt, a HTTP- és a keresőmotor-dokumentációkból):
- DNS: minden aldomainhez külön A vagy CNAME rekord kell. Ha a szolgáltató máshol van, a rekord máshova mutat, tehát eltérő tárhelyen is futhat.
- Tanúsítvány: az SSL-tanúsítvány hosztnévre szól. Vagy wildcard tanúsítvány kell (
*.domain.hu), vagy minden aldomainre külön kiállított tanúsítvány, saját megújítási ütemezéssel. - robots.txt: hosztnevenként külön fájl. A
domain.hu/robots.txtsemmit nem mond ablog.domain.hutartalmáról, oda saját fájl kell. - Sitemap: egy sitemap alapesetben csak a saját hosztjához tartozó URL-eket tartalmazhatja. Több hoszt egy fájlba pakolása csak akkor működik, ha mindegyik hoszt igazolt tulajdon.
- Search Console: URL-prefix típusú tulajdonnál minden hosztnév külön tulajdon, külön adatokkal. Domain típusú tulajdon összefogja az aldomaineket, de a jelentések nagy része akkor is szétszórtan olvasható.
- Mérés és sütik: a süti hatóköre és a session folytonossága hosztnévhez kötött. Ha külön mérőkód vagy külön property kerül az aldomainre, a felhasználói út két darabra esik szét.
Blog: blog.domain.hu vagy domain.hu/blog legyen?
Ha nincs technikai kényszer, a domain.hu/blog/ a jobb választás. A Google hivatalos álláspontja évek óta az, hogy mindkét szerkezetet fel tudja dolgozni, és nincs kihirdetett rangsorolási bónusz az alkönyvtárra. Ez viszont nem ugyanaz, mint hogy a két megoldás minden szempontból egyenértékű.
Saját tapasztalat: az alkönyvtárban induló blog jellemzően gyorsabban kap indexelést és láthatóságot, mint ugyanaz a tartalom egy frissen létrehozott aldomainen, mert az egész szerkezet a fődomain már bejáratott bejárási útvonalain lóg. Ez nem garantál semmit, de a különbség az első hónapokban látható szokott lenni.
A gyakorlati érvek az alkönyvtár mellett: a blogcikkből egy kattintással, natúr belső linkkel átvihető a látogató a szolgáltatásoldalra; a menü, a fejléc és a lábléc egy helyen karbantartható; a Search Console-ban egy helyen látod, melyik cikk hoz forgalmat a pénzt termelő oldalakra; és a felhasználó nem érzi úgy, hogy átdobták egy másik oldalra.
Szakmai feltételezés: az AI-válaszmotorok forrásmegjelölése jellemzően hosztnév szintjén jelenik meg. Ha a szakmai tartalom egy külön hosztnéven él, a márkaemlítés is megoszlik két név között. Ezt hivatalos dokumentum nem mondja ki, de a forrásmegjelölések formájából logikusan következik.
Hogyan tehetsz alkönyvtárba egy külön rendszeren futó webshopot?
Fordított proxyval: a fődomain webszervere fogadja a kérést, és a háttérben továbbadja a webshop szerverének, miközben kifelé végig egyetlen hosztnév látszik. Ez a leggyakoribb eset, amikor valaki azt hiszi, kénytelen aldomaint használni, pedig nem az.
Egy egyszerű nginx-példa a lényegre: location /shop/ { proxy_pass https://shop-backend.szolgaltato.net/; proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; }. Apache alatt ugyanez ProxyPass és ProxyPassReverse párossal oldható meg, CDN-en pedig útvonal alapú routinggal.
Amire ilyenkor figyelni kell, mert ezeken szokott elcsúszni:
- A háttérrendszer abszolút URL-eket generál-e. Ha a webshop mindenhova a saját eredeti címét írja, a linkek és a canonical tagek kiszivárogtatják a rejtett hosztnevet. A legtöbb bolti motorban van beállítás a nyilvános alapcímre, ezt kell átállítani.
- A statikus fájlok (kép, CSS, JS) útvonala is a proxyzott előtag alá kerüljön, különben vegyes tartalom vagy 404 lesz belőle.
- Útvonalütközés: ha a fő oldal is használ
/adminvagy/apiútvonalat, tisztázni kell, melyik kapja meg. - A régi hosztnév legyen lezárva: 301-es átirányítás az új útvonalra, hogy ne indexelődjön két helyen ugyanaz.
- Egyetlen sitemap-index hivatkozzon a blog és a shop sitemapjére is.
Saját tapasztalat: a proxyzott felállásban a hibák nagy része nem a proxytól jön, hanem attól, hogy a háttérrendszer nem tudja, milyen néven látják kívülről. Ha ezt az egy beállítást rendbe teszed, a többi általában magától a helyére kerül.
Kivétel, amikor mégis marad az aldomain: ha a fizetési folyamatot szándékosan elkülönített infrastruktúrán, szűkített hatókörben akarod tartani, vagy ha a bérelt bolti platform egyszerűen nem enged mást, mint egy CNAME-et.
Idegen nyelvű verzió: alkönyvtár, aldomain vagy külön domain?
Egy márka, egy cég, több nyelv esetén a domain.hu/en/ típusú alkönyvtár a legkevesebb kockázattal járó megoldás. A Google hivatalosan mindhárom szerkezetet támogatja (alkönyvtár, aldomain, országkódos domain), és a nyelvi megfeleltetést a hreflang jelzésekből olvassa ki, nem a szerkezetből.
A hreflang minden nyelvi változat fejlécében szerepeljen, oda-vissza, magára is mutatva: <link rel="alternate" hreflang="hu" href="https://domain.hu/szolgaltatas/" /> és <link rel="alternate" hreflang="en" href="https://domain.hu/en/services/" />, plusz egy hreflang="x-default" a nyelvválasztó vagy az alapértelmezett verzió számára. Ha az egyik oldal nem hivatkozik vissza a másikra, a jelzés érvénytelen.
Külön országkódos domain (például egy .at vagy .de cím) akkor indokolt, ha az adott piac tényleg külön életet él: külön árazás, külön jogi feltételek, külön logisztika, esetleg külön cég. Ilyenkor a domain önmagában is földrajzi jelzés, és a helyi bizalom is számít. Aldomain nyelvi verzióhoz ritkán a legjobb választás: viszi az aldomain összes üzemeltetési terhét, de nem adja meg a külön domain piaci előnyét.
Két hiba, ami sokba tud kerülni: az egyik a gépi fordítás emberi ellenőrzés nélkül, a másik az IP-cím alapján kényszerített automatikus átirányítás. Utóbbit a Google dokumentációja is kifejezetten kerülendőnek nevezi, mert a robotot és a felhasználót is elzárhatja a többi verziótól. Helyette tegyél ki jól látható nyelvválasztót, és hagyd a döntést a látogatóra.
Mikor kényszerít a technológia aldomainre?
Akkor, amikor a szolgáltatás nem engedi az útvonal alapú beillesztést, vagy amikor az elkülönítés szándékos. Tipikus esetek: bérelt tudásbázis vagy ügyfélszolgálati rendszer, ami csak saját hosztnévre állítható be; jegy- és foglalási rendszerek; állapotoldalak; olyan felhasználói fiókfelület, amit biztonsági okból külön süti-hatókörben akarsz tartani; nagy terhelésű, felhasználók által feltöltött tartalom, amit izolálni akarsz a fő oldaltól. Ezekben az esetekben az aldomain nem hiba, hanem józan döntés.
Ha aldomain marad, ezekkel csökkentheted a hátrányát:
- Azonos fejléc, lábléc, logó és navigáció, hogy a látogató ne érezze átdobva magát.
- Kölcsönös, tartalmi belső linkelés a két hoszt között, nem csak menüből.
- Mindkét hosztnév legyen igazolt tulajdon a Search Console-ban, saját sitemappal és saját robots.txt fájllal.
- Egyetlen mérési property, hogy a felhasználói út ne szakadjon ketté.
- Egységes
Organizationstrukturált adat, azonos hivatalos névvel és azonossameAshivatkozásokkal.
Melyik nyer a hat legfontosabb szemponton?
Hat szempont, mindegyiknél az aldomain és az alkönyvtár összevetve. Ez a gyakorlati összehasonlító táblázat, felsorolás formájában:
- Keresőoptimalizálási öröklés: alkönyvtárnál az új rész azonnal a meglévő hosztnév környezetében indul. Aldomainnél a Google szerint is feldolgozható minden, de a felfutás saját tapasztalat szerint lassabb. Előny: alkönyvtár.
- Belső linkelés: alkönyvtárban a linkek természetesen, relatív útvonalon is működnek, és a szerkesztők maguktól linkelnek. Aldomainnél ez külön munka és külön odafigyelés. Előny: alkönyvtár.
- Üzemeltetés: aldomainnél külön DNS-rekord, külön tanúsítvány és külön megújítás. Cserébe a rendszerek függetlenül frissíthetők, egy leállás nem visz mindent. Előny: helyzetfüggő.
- Mérés: alkönyvtárnál egy property, egy tölcsér, egyszerű attribúció. Aldomainnél extra beállítás kell, hogy a session ne szakadjon. Előny: alkönyvtár.
- Márkajelenlét: egyetlen hosztnév egységes képet mutat a felhasználónak és a válaszmotoroknak is. Előny: alkönyvtár.
- Technológiai szabadság: aldomainnel bármilyen stack, bármilyen szerver, bármilyen szolgáltató használható korlátozás nélkül. Előny: aldomain.
Öt szempontból négy az alkönyvtárnak kedvez, egy pedig kifejezetten az aldomainnek. Ezért az álláspontom: technikai kényszer nélkül szinte mindig az alkönyvtár a jobb választás.
Hogyan költöztess utólag aldomainről alkönyvtárba?
Teljes URL-leltárral, 1:1 megfeleltetéssel és tartós 301-es átirányításokkal. A sorrend számít, mert a félkész költözés rosszabb, mint a rossz helyen hagyott aldomain.
- Leltár. Gyűjtsd össze az összes élő URL-t: sitemap, Search Console teljesítményjelentés, szerverlog, és egy teljes bejárás feltérképező eszközzel. Amit nem írsz össze, azt el fogod veszíteni.
- URL-térkép. Készíts táblázatot: régi cím, új cím, státusz. Törekedj 1:1 megfeleltetésre. Ahol nincs pontos megfelelő, a legközelebbi releváns oldal jöjjön, ne a főoldal, mert a tömeges főoldalra irányítást a Google jellemzően puha 404-ként kezeli.
- Új szerkezet felépítése. Az alkönyvtáras verzió épüljön fel és legyen tesztelve, mielőtt bármit átirányítasz. Ellenőrizd a canonical tageket, a hreflanget és a strukturált adatokat.
- Átirányítás. Szerveroldali, 301-es (vagy 308-as) átirányítás, egyetlen ugrással. Kerüld a láncokat: a régi cím egyből a végleges új címre mutasson, ne két-három lépésben.
- Belső linkek átírása. A saját tartalmaidban ne az átirányításra bízd magad, hanem írd át a linkeket a végleges címre. Adatbázisban ez általában egy óvatos kereső-cserélő művelet, biztonsági mentés után.
- Sitemap és robots. Az új sitemap kerüljön be a Search Console-ba. A régi sitemapot érdemes egy ideig elérhetően hagyni, hogy a robot gyorsabban észlelje az átirányításokat.
- Search Console. A címváltoztatás eszköz a hivatalos dokumentáció szerint teljes domainváltásra való. Ha csak egy rész költözik alkönyvtárba, ez az eszköz jellemzően nem használható, tehát a 301-ek és az új sitemap végzik a munkát.
- Külső hivatkozások. A legfontosabb hivatkozó oldalaknál (partnerek, katalógusok, saját közösségi profilok, hírlevélsablonok) kérd meg a link frissítését. Az átirányítás működik, de a közvetlen link tisztább.
Ellenőrzőlista a kapcsoló átbillentése után: minden régi URL 301-gyel válaszol; nincs átirányítási lánc és nincs kör; nincs 404 a régi listából; az új oldalak canonicalja önmagára mutat; a hreflang oda-vissza egyezik; a mérőkód fut az új útvonalon; a robots.txt nem tilt le semmit véletlenül; a régi hosztnév tanúsítványa érvényes marad, különben az átirányítás előtt hibaüzenetet kap a látogató.
Az átirányításokat legalább egy évig tartsd életben. Saját tapasztalat: a költözés utáni két-hat hétben szokott lenni ingadozás a forgalomban, és ez önmagában még nem jelent hibát. Ha viszont négy hét után is folyamatosan romlik a kép, akkor jellemzően a leltár volt hiányos, vagy valahol lánc keletkezett az átirányításokban.
Mit mérj a költözés után?
Négy dolgot érdemes hetente nézni. Az indexelt oldalak számát az új útvonalon (nő-e a lefedettség), a megjelenéseket és kattintásokat a Search Console-ban régi és új tulajdonra egyszerre, a bejárási statisztikát (talál-e a robot még sok régi URL-t), valamint a szerverlogban a 404-es és 5xx-es válaszokat. Ez a négy adat együtt megmutatja, hogy a költözés technikailag rendben van-e, jóval azelőtt, hogy a rangsorok kiegyenesednének.
Források és további olvasnivalók
- Google Search Central: Site moves with URL changes (oldalköltöztetés URL-változással)
- Google Search Central: Managing multi-regional and multilingual sites
- Google Search Central: Sitemaps dokumentáció és a robots.txt specifikáció
- Google Search Console súgó: tulajdontípusok és a címváltoztatás eszköz
- IETF RFC 9110 (HTTP Semantics), a 301-es és 308-as átirányítások definíciója
- Schema.org: Organization és WebSite típusok
- Google Analytics 4 súgó: domainek közötti mérés és hivatkozás-kizárás
- OpenAI dokumentáció: a crawlerek (például GPTBot) viselkedése és robots.txt kezelése
- Az alkönyvtár ugyanaz a hosztnév, az aldomain önálló hoszt: külön DNS, külön tanúsítvány, külön robots.txt és külön Search Console-kezelés.
- A Google hivatalosan mindkét szerkezetet fel tudja dolgozni, de a mindennapi üzemeltetés és a belső linkelés az alkönyvtárral egyszerűbb.
- Külön rendszeren futó webshopot fordított proxyval szinte mindig be lehet emelni a fődomain alá alkönyvtárként.
- Nyelvi verziónál a /en/ típusú alkönyvtár és a helyes hreflang a legkevesebb kockázattal járó megoldás, ha egy márkáról van szó.
- Utólagos költöztetésnél a teljes URL-leltár, az 1:1 301-es átirányítás és a belső linkek átírása dönti el, mennyit veszítesz átmenetileg.
Gyakori kérdések
Rontja a SEO-t, ha aldomaint használok?
Önmagában nem. A Google hivatalosan is kezelni tudja mindkét szerkezetet, és nincs kihirdetett büntetés az aldomainre. A gyakorlati hátrány inkább abból jön, hogy szétesik a belső linkelés, a mérés és a márkajelenlét, ez pedig közvetve visszafoghatja az eredményeket.
A blogot már blog.domain.hu címen indítottam. Megéri átköltöztetni?
Ha a blog kicsi vagy közepes és aktívan fejleszted tovább, jó eséllyel megéri, mert a hosszú távú előny nagyobb, mint az egyszeri kockázat. Ha viszont több ezer indexelt, jól teljesítő cikkről van szó és nincs kapacitás rendes URL-leltárra és 301-ekre, akkor jobb a meglévő szerkezetet megerősíteni.
Kell külön Search Console tulajdon az aldomainhez?
URL-prefix típusú tulajdonnál igen, minden hosztnevet külön kell igazolni. Domain típusú tulajdonnal egyszerre lefedheted a fődomaint és az összes aldomaint, ehhez viszont DNS-alapú igazolás kell.
Lassítja az oldalt a fordított proxy?
Ad hozzá némi késleltetést, mert egy plusz ugrás keletkezik. Jó hálózati útvonallal és megfelelő gyorsítótárazással ez tipikusan pár tíz ezredmásodperc, amit a felhasználó nem érzékel. A CDN-szintű útvonal alapú routing tovább csökkentheti.
A nyelvi verziót átirányíthatom a látogató országa alapján?
Jobb, ha nem. A Google dokumentációja kifejezetten kerülendőnek nevezi az automatikus, észlelt nyelv vagy IP alapján kényszerített átirányítást, mert elzárhatja a látogatót és a keresőrobotot a többi verziótól. Használj inkább jól látható nyelvválasztót, opcionálisan egy elvethető javaslósávval.
Meddig kell fenntartani az átirányításokat költözés után?
Legalább egy évig, de ha nincs technikai akadálya, érdemes tartósan meghagyni. Amíg élnek a régi külső hivatkozások és a régi könyvjelzők, addig hasznuk van.
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.