A progresszív webalkalmazások (PWA) egyesítik a weboldal elérését a natív alkalmazás élményével. Ismerd meg, hogyan működnek, és mit jelentenek a SEO szempontjából.

Ezen az oldalon
Összefoglaló
A progresszív webalkalmazást webes technológiákkal építik, de telepített natív alkalmazásként viselkedik: egyetlen kódbázisból fut több eszközön, offline is működik, és a keresésben is megtalálható marad.
Szeretnél többet megtudni? Kérdezd meg
A progresszív webalkalmazások, röviden PWA-k, olyan alkalmazások, amelyeket webes platformtechnológiákkal építenek, és amelyek közel állnak egy adott platformra készült alkalmazás élményéhez. Mint egy weboldal, a PWA is sok platformon és eszközön fut egyetlen kódbázisból. Mint egy natív alkalmazás, telepíthető az eszközre, offline és háttérben is tud működni, és integrálódhat az operációs rendszerrel és más alkalmazásokkal.
Ebben a kombinációban rejlik a vonzereje: a weben megszokott elérést és megtalálhatóságot kapod a natív alkalmazás csiszoltságának nagy részével, anélkül, hogy minden platformhoz külön buildet kellene karbantartani. A marketingesek számára a legfontosabb az, hogy a PWA a lényegét tekintve továbbra is weboldal marad, így még mindig bejárható, indexelhető és megjeleníthető a keresésben.
A PWA olyan webalkalmazás, amely a hagyományos weboldal képességeit ötvözi egy mobilalkalmazás funkcióival és érzetével. A kezdőképernyőről indul, teljes képernyőn futhat böngészősáv nélkül, telepített szoftverként viselkedik, mégis a weben keresztül jut el a felhasználóhoz, nem alkalmazásboltból. A „progresszív” szó azt jelzi, hogy a böngésző és az eszköz által támogatott képességekhez igazodva bővül.
Mivel alul továbbra is a web van, a PWA megtartja a valódi, hivatkozható URL-jeit, így megosztható, könyvjelzőzhető és keresésben megtalálható. Ez a kulcskülönbség egy alkalmazásbolton belül zárt natív alkalmazáshoz képest: a PWA egyszerre él a két világban.
Minden PWA-hoz legalább két dologra van szükség: egy webalkalmazás-manifesztre és egy service workerre. A manifeszt egy JSON-fájl, amely leírja az alkalmazást, olyan elemekkel, mint a név vagy a rövid név, a 192 és 512 pixeles ikonok, a kezdő URL és egy megjelenítési mód, például a standalone. Ezek a tulajdonságok teszik lehetővé, hogy a böngésző felajánlja a telepítést, és natív szoftverként indítsa el az alkalmazást.
A harmadik követelmény a HTTPS. A PWA-t biztonságos kapcsolaton keresztül kell kiszolgálni, részben a felhasználók védelme miatt, részben pedig azért, mert a service workerek biztonságtalan kapcsolaton nem regisztrálódnak. A biztonságos kiszolgálás ezért bármely rendes technikai SEO beállítás alapeleme egy PWA-nál.
A service workerek a PWA motorja. A service worker egy JavaScript-fájl, amely közvetítőként működik a böngésző és a hálózat között. Telepítés után elfogja a hatókörén belüli kéréseket, és gyorsítótárból szolgálhat ki válaszokat, ez teszi lehetővé, hogy a PWA azonnal töltsön be, és offline vagy gyenge kapcsolaton is működjön.
A service workerek a gyorsítótárazásnál többre is képesek. Kezelik a késleltetett feladatok háttérszinkronizálását, a nagy letöltések háttérben történő letöltését és a visszatérő felhasználók értesítését push-üzenetekkel, valamint csendben, a háttérben frissítik az alkalmazást, így a felhasználók mindig a legfrissebb verziót kapják, alkalmazásbolti várakozás nélkül. Ez a megbízhatóság közvetlenül hozzájárul az erős oldalélményhez.
Egy natív alkalmazáshoz képest a PWA olcsóbb építeni és karbantartani, mert egyetlen kódbázisból fut, és kikerüli az alkalmazásboltok kapuőr-szerepét és a felülvizsgálati késedelmeket. A natív alkalmazások még mindig a legmélyebb eszközintegrációban erősebbek, de sok terméknél a PWA a különbség nagy részét behozza. Egy sima weboldalhoz képest a PWA telepíthetőséget, offline támogatást és háttérfunkciókat ad hozzá, amelyeket a sima oldal nem tud nyújtani.
A gyakorlati haszon az elkötelezettség. Mivel a PWA-k a gyors betöltést az alkalmazásszerű viselkedéssel ötvözik, gyakran magasabb elkötelezettséghez és alacsonyabb visszafordulási arányhoz kötik őket a hagyományos mobiloldalakhoz képest, ezért fektettek be bennük a kiskereskedők és a kiadók.
Az alkalmazásboltokba rejtett natív alkalmazásokkal ellentétben a PWA-k megjelennek a keresőmotorokban, és mint bármely weboldal, indexelve vannak. Ez a kettős természet azt jelenti, hogy egyetlen PWA szerepelhet az organikus találatok között, és ugyanakkor a felhasználó kezdőképernyőjén is ülhet, így a kereslet mindkét irányból megfogható. Ezért elengedhetetlen, hogy a tartalom elérhető legyen a keresőrobotok számára, ami a PWA-kat a gondos bejárás és indexelés rendjéhez köti.
A generatív MI esetében ugyanez a logika érvényes. Az MI-asszisztensek azt a tartalmat jelenítik meg, amelyet be tudnak járni és fel tudnak dolgozni, így az a PWA, amely a tartalmát bejárható módon jeleníti meg, az MI-válaszokban is láthatóságot érhet el, a klasszikus keresés mellett. Ha a PWA-t először weboldalként kezeled, és kulcsszókutatással és tartalomtervezéssel párosítod, mindenhol megtalálható marad.
A klasszikus kockázat a kliensoldali renderelés. Mivel a PWA-k gyakran JavaScripttel építik a tartalmat a böngészőben, a korai keresőmotorok nehezen indexelték őket. A modern keresőmotorok már jobban boldogulnak, és támogatják a History API-t a hivatkozható URL-ek létrehozásához, de továbbra is gondoskodnod kell róla, hogy a keresőrobotok lássák a tartalmat, ideális esetben szerveroldali renderelés vagy előrenderelés révén a kritikus oldalakon.
A renderelésen túl minden érdemi nézetnek adj saját, valódi URL-t, tegyél közzé megfelelő címeket és metaadatokat, és ellenőrizd, hogy a fontos oldalak indexelhetők-e. Az a PWA, amely a tartalmát csak az alkalmazáson belüli navigáció mögé rejti, elveszíti a keresési láthatóságot, pedig ez az egyik legnagyobb előnye a natív alkalmazásokkal szemben, és ronthatja a felhasználói élményt azoknak az első látogatóknak, akik keresésből érkeznek.
A PWA-k olyan termékekhez illenek, amelyek mind a webes megtalálhatóságból, mind az alkalmazásszerű elkötelezettségből profitálnak: webáruházak, hír- és médiaoldalak, utazási eszközök és szoftveres irányítópultok. Különösen értékesek ott, ahol a felhasználók ingadozó hálózaton vagy gyengébb eszközön vannak, mert az offline gyorsítótárazás és a könnyű betöltés használhatóvá teszi az élményt.
Erős alternatíva akkor is, ha külön natív alkalmazások építése és karbantartása túl drága. Egyetlen PWA szolgálhat mobilra és asztali gépre, telepíthető igény szerint, és a keresésben is megtalálható, így a natív alkalmazás értékének nagy részét a költség töredékéért adja. Az olyan régebbi megoldásokhoz képest, mint az AMP, a PWA sokkal gazdagabb interaktivitást kínál, miközben megtartja a sebességet.
A progresszív webalkalmazás a web elérését ötvözi a natív alkalmazás élményével: egyetlen kódbázisból épül, telepíthető, offline is működőképes, és a keresésben továbbra is megtalálható. Magja a manifeszt, a service worker és a HTTPS, a natív alkalmazásokkal szembeni legnagyobb stratégiai előnye pedig az, hogy a keresőmotorok és az MI-asszisztensek is be tudják járni, indexelni és megjeleníteni.
Ezt az előnyt úgy védheted meg, ha a tartalmat úgy rendereled, hogy a keresőrobotok el tudják olvasni, minden nézetnek valódi URL-t adsz, és a PWA-t összehangolod a megfelelő oldalélménnyel és a Sorank kutatási és tartalomtervezési eszközeivel. Forrásaink: MDN Web Docs, Positional és Seobility.
Források
A PWA-k jók a SEO szempontjából, ha helyesen készülnek, mert a lényegüket tekintve weboldalak maradnak, és mint bármely oldal, bejárhatók és indexelhetők, szemben az alkalmazásboltba zárt natív alkalmazásokkal. A fő kockázat, hogy a kliensoldali renderelés elrejti a tartalmat a keresőrobotok elől. Használj szerveroldali renderelést vagy előrenderelést, adj minden nézetnek valódi URL-t, és ellenőrizd, hogy a kulcsoldalak indexelhetők-e.
A PWA-hoz minimum webalkalmazás-manifeszt, service worker és HTTPS szükséges. A manifeszt név, ikonok, kezdő URL és megjelenítési mód segítségével írja le az alkalmazást, hogy a böngésző felajánlhassa a telepítést. A service worker teszi lehetővé az offline működést és a háttérfunkciókat, a HTTPS pedig kötelező, mert a service workerek nem regisztrálódnak nem biztonságos kapcsolaton.
A PWA egyetlen webes kódbázisból fut több platformon, és a keresésben megtalálható, a natív alkalmazás viszont platformspecifikus, és alkalmazásboltokon keresztül terjesztik. A PWA-k olcsóbban építhetők és karbantarthatók, és elkerülik az áruházi felülvizsgálati késéseket. A natív alkalmazások továbbra is mélyebb eszközintegrációt kínálnak, de a PWA-k a legtöbb terméknél ezt a különbséget nagyrészt bezárják.
A TE ELŐTTED PRÓBÁLTÁK KI A SORANKOT
