Így nyesi vissza a megosztható linkeket a Chrome

Google nem volt túl bőbeszédű a Chrome 64-ben bemutatkozott "linknyíró" funkció kapcsán, annyira nem, hogy hivatalos bejelentést nem is tett ezzel kapcsolatban. A cég ugyancsak ebben a főverzióban debütált hirdetésblokkolója árnyékában vélhetően nem érezte szükségét, hogy részletesen kitérjen az újításra. Azt mindenesetre több portál is kiszúrta, hogy a böngésző megosztás funkcióját használva, az az eredetinél számottevően rövidebb URL-t küld tovább a címzett felé, egyes elemeket - mint az oldal aktuális görgetési pozícióját jelölő tageket - akár le is hagyva a linkből.

Ez rögtön komoly kérdéseket vetett fel: honnan szedi a Chrome, hogy az URL-nek mely részei fontosak az oldal számára, és melyek mellőzhetőek? Minden weboldal másképp működik, van, ahol a triviálisnak és kihagyhatónak számító mező fontos adatot ad át a szervernek, mellőzésével azonban nem oda érkezik alátogató, ahová szeretett volna. Így webfejlesztőktől (a HWSW-s kommentekben is) jogos kérdés: hogyan gyomlál a Chrome?

Bozótvágó nélkül

A böngésző changelogját végigböngészve ugyanakkor kiderül, hogy valójában nem arról van szó, hogy a Chrome nekiáll kompaktabb verzióra faragni a szóban forgó hivatkozásokat és saját hatáskörben elkezdi kidobálni a különböző, URL-ben foglalt címkéket. A megoldás sokkal prózaibb: a mobilos böngésző megosztáskor egyszerűen az oldal fejlesztője által korábban megadott, úgynevezett "canonical", vagy "gyűjtőlinkeket" másolja a vágólapra.

A gyűjtőhivatkozások korántsem új keletűek, azokat a Google már több mint kilenc éve használja, a linkek elsődleges feladata pedig, hogy a rel=canonical komponenssel egyértelművé tegyék, hogy az adott oldal nem egészen egyedi, hanem egy oldal egy speciális verziójáról van szó. Ezzel segíthető a keresőmotorok munkája, kiszűrhetők az esetleges duplikált, vagy egymáshoz hasonló tartalmakból adódó problémák, vagyis bebiztosítható, hogy az online keresések valóban a fejlesztő által kiválasztott verziót hozzák felszínre - SEO szempontból tehát már évek óta komoly szerepe van a canonical linkeknek. Erre a problémára tipikus példa lehet, ha egy blogmotor automatikusan több URL-ként tárolja el ugyanazt az anyagot, mikor a szerző azt több rovatba is besorolta, de már az is megkavarhatja a keresőmotor dolgát, ha egy szerver ugyanazt a tartalmat jeleníti meg a www előtaggal ellátott vagy anélküli, illetve a http és https változatok esetében - és persze a mobil és asztali oldalak közötti átjárhatóságot is biztosítja.

Ha nincs gyűjtő-URL megadva, a Googlebot az adott webhely indexelése során a látszólag azonos, vagy nagyon hasonló tartalommal rendelkező oldalak közül maga jelöl ki canonical oldalt, és a későbbiekben is ezt térképezi majd fel nagyobb rendszerességgel. Ha tehát a fejlesztő a canonical linkkel nem ad maga útjelzőt a robot számára, megeshet, hogy a keresési eredmények között nem a kívánt oldal jelenik majd meg. A mobiloldalak egyes esetekben kivételt képezhetnek a keresések során, mobileszközről ugyanis akkor is utóbbiakat dobhatja fel a Google keresési eredményként, ha a fejlesztő az asztali verziót jelölte meg gyűjtőoldalként. A Google a canonical linkek kapcsán egyébként részletes leírást is kínál a fejlesztők számára.

A gyűjtőoldalak nem csak a SEO feladatokat könnyíthetik meg, de egyszerűbbé válhat velük bizonyos tartalmak vagy akár termékek mutatóinak követése, kezelhetővé válnak általuk a más webhelyekre terjesztett tartalmak, illetve csökkenthető az ismétlődő oldalakhoz tartozó feltérképezési idő. Nem véletlen egyébként, hogy a Facebook is használja ezt a címkét, a közösségi oldalon megosztott linkeket nem eredeti formájában fogadja be az oldal, hanem a kanonikus linket használva olvassa be annak tartalmát, készít belőle előnézetet címmel-képpel, stb.

Nagyjából hasonló történik most a Chrome 64-gyel is: a böngészőből indított megosztáskor nem az éppen aktív URL-t küldi tovább a Chrome, hanem a kanonikus linket fogja meg és adja át más alkalmazásoknak. Ezt pedig maga a fejlesztő adja meg az oldal HTML-jében, a böngésző így értelemszerűen semmilyen döntést nem végez el, ez továbbra is a fejlesztők által kijelölt canonical hivatkozást osztja meg a címzettekkel.

Hlács Ferenc, 2018. február 23. 12:39