Sok magyar oldal még mindig két külön címen él. A www a desktopot szolgálja ki, az m. aldomain a telefonokat, és a két készlet évek óta külön életet él. A tartalom szétcsúszott, a mérés kettévált, minden fejlesztés duplájába kerül. Az egyesítés egyetlen reszponzív oldalra technikailag nem bonyolult feladat, mégis itt látom a legtöbb elvesztett organikus forgalmat, mert a csapatok az átirányítás megírását tekintik a munkának, a párosítást pedig nem.
Saját tapasztalat. A projekt sikere egyetlen táblázaton múlik, azon, amelyik megmondja, hogy az m. aldomain minden egyes URL-je pontosan melyik egyesített URL-re megy. Ahol ez a tábla hiányos, ott születik meg a klasszikus veszteség, a mindent a főoldalra terelő gyűjtőszabály.
Miért kockázatos örökölt mobil aldomaint üzemeltetni?
Azért, mert a két készlet szinte mindig elcsúszik egymástól, és a keresők a mobil változatot látják elsődlegesnek. Hivatalosan igazolt. A Google 2023 októbere óta minden webhelyet mobile-first módon indexel, vagyis a Googlebot okostelefonos változata járja be az oldalakat, és az így látott tartalom kerül az indexbe. Ha az m. verzió évek óta csonka, ha hiányoznak belőle a leírások, a GYIK-blokkok vagy a strukturált adatok, akkor a kereső régóta a szegényebb változatot értékeli.
A másik költség a karbantartás. Két sablonkészlet, két tanúsítvány, két mérési tulajdon, kétféle sütibanner. Ahogy nő az AI-alapú válaszmotorok szerepe, ez tovább romlik, mert a hivatkozás hol az egyik, hol a másik hoston landol, és a kettő között nem mindig van rendezett kapcsolat.
Szakmai feltételezés. Az AI-válaszokban felbukkanó forrás-URL-ek lassabban frissülnek, mint a klasszikus keresési index, ezért egy régi m. hivatkozás jóval tovább él, mint gondolnád. Ez önmagában nem mérhető kívülről, de óvatosságra int az aldomain kikapcsolásának időzítésénél.
Hogyan készíts teljes URL-leltárt a két készletről?
Úgy, hogy legalább öt független forrásból gyűjtesz, mert egyetlen forrás sem teljes. A sitemap csak azt tartalmazza, amit a CMS tud, a crawler csak azt találja meg, amire van belső link, a naplófájl viszont megmutatja azokat az árva oldalakat is, amelyekre még mindig érkezik látogató.
- Mindkét hoston a
sitemap.xmlés minden hivatkozott al-sitemap. - Teljes belső crawl a
wwwés azm.hoston külön futtatva, redirectek követésével. - Szerver access log legalább 90, ideálisan 180 napra visszamenőleg, státuszkóddal együtt.
- Search Console Oldalak riport mindkét tulajdonról, az indexelt és a nem indexelt bontással.
- Analytics céloldal-export ugyanerre az időszakra, hosztnév szerinti bontásban.
- Hivatkozás-export, hogy lásd, mely régi URL-eknek van külső linkje.
A gyűjtés után jön a normalizálás, ami nélkül a párosítás használhatatlan. Egységesítsd a protokollt, a www előtagot, a záró perjelet, a kis- és nagybetűket, és vágd le a nyomkövető paramétereket. Ami marad, az a kanonikus útvonal, és ezen a szinten lehet két listát egymáshoz rendelni.
Hogyan épül fel a párosítási táblázat?
Soronként egy régi URL, oszloponként az a néhány adat, amitől a döntés védhető lesz. Ez a tábla a projekt gerince, érdemes megosztott munkalapon vezetni, mert több ember fog benne dolgozni.
- Régi URL az
m.hoston. - Javasolt új URL az egyesített oldalon.
- A párosítás típusa, tehát pontos, részleges vagy hiányzó.
- Mi támasztja alá, például azonos slug, azonos cím, azonos H1, azonos termékazonosító.
- Organikus kattintás az elmúlt 90 napban.
- Hivatkozó domainek száma.
- Döntés, tehát 301 a párra, 301 a szülőkategóriára, 410, vagy új oldal készül.
- Állapot és felelős.
A gépi párosítást slug-egyezéssel és cím-hasonlósággal indítsd, ez a sorok nagy részét megoldja. Az automata találatokat viszont ne fogadd el vakon. Saját tapasztalat. Kézzel azokat a sorokat nézd át, amelyek az elmúlt negyedév organikus kattintásainak nagyjából nyolcvan százalékát adják, plusz mindaz, amire külső link mutat. Ez a lista általában sokkal rövidebb, mint amitől a csapat tart, és pont ez a néhány száz sor hozza a forgalom zömét. A hosszú farokra maradhat a szabályalapú, mintázatra épülő átirányítás.
Mit kezdj azokkal az aloldalakkal, amelyeknek nincs pontos párja?
Négy különböző esetet kell szétválasztani, mert mindegyik más kezelést kíván, és a kényelmes közös nevező itt drágul be igazán.
Az első, amikor a tartalom csak a mobil verzión létezik. Ilyenkor nem átirányítási feladatod van, hanem tartalmi. Emeld át a szöveget az egyesített oldalra, és csak utána élesítsd a 301-et. Ha fordítva csinálod, olyan célra irányítasz, amelyik nem válaszolja meg a kérdést, amiért a látogató odament.
A második, amikor a mobil változat csonkított, például nincs rajta a részletes leírás vagy a paramétertáblázat. Itt a desktop tartalom a gazdagabb, tehát a cél rendben van, de érdemes ellenőrizni, hogy a mobilon is megjelenik-e az egész szöveg, nem rejti-e el a sablon.
A harmadik a valóban megszűnt oldal. Ha nincs tartalmilag közeli utód, a 410 tisztességesebb megoldás, mint egy erőltetett átirányítás. Hivatalosan igazolt. A Google dokumentációja szerint a tartalmilag nem releváns célra mutató átirányítást a kereső soft 404-ként kezelheti, vagyis a link- és relevanciajel nem adódik át. Ettől a főoldalra terelő tömeges 301 nem hibaüzenetet ad, hanem csendben elnyeli az értéket, és emiatt veszik észre olyan későn.
A negyedik a kategóriaszintű összevonás. Ha öt régi mobil aloldal tartalma egyetlen új oldalon fut össze, mind az öt mehet ugyanarra a célra, ez nem hiba. A hiba az, ha ez a cél a főoldal, és nem a téma szerinti gyűjtőoldal.
Milyen jelöléseket kell eltávolítani, és milyen sorrendben?
A külön mobil URL-es felállásnak három hivatalos árulkodó jele van, és mindhármat vissza kell bontani, de csak az átirányítás élesítése után.
- A desktop oldalakon a
<link rel="alternate" media="only screen and (max-width: 640px)" href="https://m.pelda.hu/...">sor. - A mobil oldalakon a desktop változatra mutató
<link rel="canonical">. - Dinamikus kiszolgálásnál a
Vary: User-Agentfejléc.
A sorrend azért fontos, mert a jelölés tartja össze a két készletet addig, amíg mindkettő elérhető. Ha előbb veszed ki az alternate és canonical párost, de az m. még kiszolgál, akkor egy ideig két majdnem azonos, összekötés nélküli oldalkészleted lesz. Kapcsold ki ugyanekkor a felhasználói ügynök alapján dobó régi logikát is, azt, amelyik a telefonokat automatikusan az aldomainre küldte. Ha ez bent marad, miközben az m. már visszairányít, körkörös átirányítást kapsz, és a mobil forgalom egésze elérhetetlenné válik. Ez a hiba percek alatt megtörténik, és egy egyszerű mobil user agenttel futtatott curl -sIL azonnal kimutatja.
Milyen átirányítási rendet érdemes építeni?
Listavezéreltet, egy ugrással, megőrzött query stringgel. A párosítási táblából generálj gépi leképezést, ne kézzel írj szabályokat, mert a kézi szabályok között mindig marad átfedés.
Egy nginx-példa, ahol a párosítás külön fájlból jön, és a nem szereplő cím nem landol vakon a főoldalon.
map $uri $cel { include /etc/nginx/parositas.map; default ""; }
server { listen 443 ssl; server_name m.pelda.hu; if ($cel != "") { return 301 https://www.pelda.hu$cel$is_args$args; } return 410; }
A parositas.map tartalma soronként egy régi és egy új útvonal, például /termekek/kerti-pad /kert/butor/kerti-pad; alakban. A $is_args$args viszi tovább a paramétereket, ez tartja életben a gclid, az fbclid és az UTM-jelölést, ami nélkül a fizetett forgalom mérése egy szempillantás alatt szétesik.
Élesítés előtt futtass batch-ellenőrzést az összes régi URL-re, és három dolgot nézz. Az első kérés 301-et adjon, a lánc egyetlen ugrásból álljon, és a végállomás 200-at adjon. A több lépcsős lánc működik, de lassít és linkértéket szór szét, a 302 pedig ideiglenes jelzést küld, amit ilyenkor nem akarsz.
Mi a teendő a Search Console-tulajdonokkal?
Tartsd meg mindkettőt, és ne töröld a régit. Hivatalosan igazolt. A címváltoztatás eszköz akkor használható, ha a forrás- és a céltulajdon is igazolt, és a régi címről 301-es átirányítás mutat az újra, aldomain közti költözésnél is. A teljesítményadatok 16 hónapra visszamenőleg érhetők el, ezért a régi tulajdon törlése azt az összehasonlítási alapot venné el, amiből az egész projekt eredménye kiolvasható.
Az élesítés napján érdemes az m. hoston a régi URL-eket tartalmazó sitemapet még beküldeni, mert ez segíti a bejárót abban, hogy gyorsabban találkozzon az átirányításokkal. Ez átmeneti lépés, néhány hét után kivezethető. Mintavételszerűen futtass URL-ellenőrzést is a legfontosabb régi címekre, itt látod visszaigazolva, hogy a Google valóban átirányításként értelmezi a választ.
A mérésnél gondolj a hosztnév szerinti bontásra. Ha a két oldal eddig külön tulajdonban vagy külön adatfolyamban mért, az egyesítés után a történeti adat nem lesz összefűzve magától, ezért érdemes az utolsó teljes hónapot mindkét forrásból kimenteni, mielőtt bárki hozzányúl a beállításokhoz.
Meddig tartsd életben a mobil aldomaint?
Legalább egy évig, és utána is csak akkor kapcsold ki, ha a mérés indokolja. Hivatalosan igazolt. A Google költözési útmutatója legalább egyéves fenntartást javasol a 301-ekre. Saját tapasztalat. A gyakorlatban ennél tovább éri meg, mert az aldomain fenntartása egy DNS-rekordba és egy tanúsítványba kerül, miközben a régi címekre évekig érkezik forgalom nyomtatott anyagokból, QR-kódokból, régi hírlevelekből és külső hivatkozásokból.
Itt van a projekt leggyakoribb utólagos bukása. A tanúsítvány megújítása kimarad az m. hosztnévre, mert a csapat fejében az oldal már nem él. Ettől a 301 nem hibásodik meg, de a böngésző tanúsítványfigyelmeztetést dob a látogatóra, mielőtt bármi átirányulna. Vedd fel a tanúsítvány megújítási listájára az aldomaint, és tedd be egy figyelőbe, ami hetente ellenőrzi, hogy egy minta-URL még mindig 301-et ad.
A kikapcsolás akkor időszerű, ha a naplóban hónapok óta elhanyagolható a régi hosztra érkező kérés, és a hivatkozó domainek közül a fontosak már az új címre mutatnak.
Hogyan kövesd utána a forgalmat az élesítés után?
Előre rögzített rendben, mert utólag mindenki mást emlékszik a kiindulási számokra. Mentsd ki az élesítés előtti 28 nap organikus kattintását, megjelenését és a legfontosabb céloldalak listáját, és ehhez hasonlíts.
- Az első héten naponta nézd a 404-es és 410-es naplósorokat, az új mintázatok itt jönnek elő.
- A második héttől heti bontásban figyeld az indexelt oldalak számát az új tulajdonban.
- Négy hét után hasonlítsd össze a legjobb ötven céloldal teljesítményét, oldalanként, nem összesítve.
- Nézd meg a mobil oldalbetöltési mérőszámokat, mert az egyesített sablon néha desktopra méretezett képeket küld telefonra.
- Ellenőrizd a hirdetési végső URL-eket, a Google cégprofilt, a hírlevélsablonokat és a közösségi profilok linkjeit.
Szakmai feltételezés. Átmeneti ingadozás az első két-négy hétben szokásos, mert a kereső újra kell hogy értékelje a készletet. Ez nem garancia arra, hogy minden pozíció visszaáll, és nem is jelenti azt, hogy a negyedik hét után már nincs teendő. Ha egy oldalcsoport nyolc hét után sem áll vissza, szinte mindig a párosítás minőségénél van a hiba, nem a szerverbeállításnál, tehát oda menj vissza, ne a redirectet írd újra.
Források és további olvasnivalók
- Google Search Central, Site move with URL changes útmutató
- Google Search Central, Mobile site and mobile-first indexing dokumentáció
- Google Search Central, Redirects and Google Search
- Google Search Console súgó, Change of address tool
- Google Search Console súgó, Teljesítmény riport és adatmegőrzés
- Schema.org, strukturált adat szótár
- W3C, Mobile Web Best Practices
- MDN Web Docs, HTTP redirections és a Vary fejléc leírása
- Az egyesítés minősége a párosítási táblázaton múlik, nem a szerverkonfiguráción.
- Minden m. URL kapjon egyedi, tartalmilag illeszkedő célt, a gyűjtő főoldalas átirányítás pazarlás.
- A canonical és alternate jelöléseket csak akkor vedd ki, amikor az átirányítás már él.
- A régi Search Console-tulajdont ne töröld, ott látod, hogyan olvad le a régi URL-készlet.
- A 301-eket legalább egy évig tartsd életben, a tanúsítvány megújításával együtt.
Gyakori kérdések
Elég, ha minden m. URL-t a főoldalra irányítok?
Nem érdemes. A Google a tartalmilag nem releváns célra mutató átirányítást soft 404-ként kezelheti, vagyis a régi oldal jelei nem adódnak át. A gyűjtő főoldalas szabály a leggyakoribb veszteségforrás ezekben a projektekben.
Mi legyen azzal az aloldallal, ami csak a mobil verzión létezik?
Először emeld át a tartalmát az egyesített oldalra, és csak utána élesítsd rá az átirányítást. Ha fordítva csinálod, olyan célra küldöd a látogatót, ahol nincs meg a keresett válasz.
Használjam a Search Console címváltoztatás eszközét aldomain esetén?
Igen, használható, ha a régi és az új tulajdon is igazolt, és a régi címekről 301-es átirányítás mutat az újra. A régi tulajdont ettől függetlenül tartsd meg, mert az adatok ott 16 hónapig visszanézhetők.
Mikor vegyem ki a canonical és alternate jelöléseket?
Csak az átirányítás élesítése után. Amíg mindkét készlet elérhető, ezek a jelölések tartják össze a párokat, előbb eltávolítva egy ideig két összekötetlen, majdnem azonos oldalkészlet marad.
Meddig kell fenntartani az átirányításokat?
A Google legalább egy évet javasol, a gyakorlatban viszont érdemes tovább tartani, mert a régi címekre évekig érkezik forgalom nyomtatott anyagokból és külső hivatkozásokból. A tanúsítvány megújítását is folytatni kell az aldomainre.
Mennyi visszaesésre kell számítani az egyesítés után?
Átmeneti ingadozás az első két-négy hétben szokásos, de ez nem garantálja, hogy minden pozíció visszaáll. Ha egy oldalcsoport nyolc hét után sem rendeződik, a párosítási táblát nézd át újra, jó eséllyel ott van a hiba.
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.