Gæstebloggen

SPA-applikationer og SEO

Single page-applikationer (SPA) er det nye sort. Flere og flere vælger at bygge deres applikationer som en SPA. Og det med god grund:

Saxo Merrild, CEO og grundlægger, Pinploy.dk Illustration: Privatfoto

SPA-applikationer giver nemt genbrugelige komponenter, fantastisk dokumentation, nemme at konvertere til native mobile apps mm.

Alle disse fordele var en del af beslutningsgrundlaget for at vælge at bygge en SPA, da vi byggede Pinploy. Men kan anvende frameworks som enten Angular, Vue eller React – og med god grund.

Vi bruger Angular hos Pinploy.dk og er blevet overrasket over den hastighed og agilitet, som frameworket og client rendering leverer.

Imidlertid havde vi overset et vigtigt element: Google er ekstremt dårlig til at indeksere SPA-sider.

På trods af Googles udmelding helt tilbage fra 2014 om, at deres spiders sagtens kan indeksere SPA-sider, måtte vi nikke genkendende til det, som fremgår af mange blogs og debatsites, nemlig at det desværre er langt fra sandheden.

Googles indekseringsrobotter er gode til at læse den html-tekst, som de finder på hjemmesider, men kan ikke opfange teksten, når den - som det sker med SPA-applikationer - bliver injected, efter at siden er indlæst.

Trods deres indsats for, at Google selv står bag frameworks som Angular, er de ikke lykkedes med at bygge en spider, som på effektiv vis kan indeksere siderne.

Problemet med Client-rendered indhold

Inden vi dykker ned i, hvordan vi sikrede at blive indekseret på Google med vores SPA-applikation, giver det mening at tage et hurtigt kig på, hvad årsagen egentlig er til, at Google ikke på god vis kan indeksere SPA-applikationer:

Standard implementationen af SPA apps giver en skal (shell) til browseren, uden at nogen form for meningsfuld indhold er inkluderet. Indholdet bliver så hentet in ‘on demand’ fra serveren med AJAX og bliver tilføjet til siden af JavaScript.

Dette giver brugeren muligheden for at se ‘siderne’ af en SPA app uden sidegenindlæsning, hvilket teoretisk set forbedrer UX.

Illustration: Saxo Merrild

Imens denne arkitektur virker fint for mennesker, som skal se sider i en browser, hvad så med søgemaskine-crawlers? Kan de køre JavaScript? Hvis de kan, venter de så på, at de ‘AJAX calls’, som skal laves, er færdige, inden de crawler siden?

Det korte svar er ja, Google har siden 2014 oplyst, at deres Googlebots prøver at rendere JavaScript, inden den indekserer. Men! Som med alle andre JavaScript engines, er Googlebot ikke uden fejl, og der er mange tilfælde, hvor den ikke kan rendere din side.

Dertil skal det siges, at selvom din side måske indekseres, betyder det ikke nødvendigvis, at den ranker godt. Der er også kommet mange nye API’s siden dengang, som Googlebot ikke kan rendere i dag.

SEO og hvordan Google indekserer sider, er i forvejen en utrolig obskur praksis, og på trods af at der er mange guruer og eksperter, som mener, at de har svaret på, hvordan man nailer SEO, så er virkeligheden, at Googles algoritmer og indekseringsrobotter – eller spiders – konstant udvikler sig og har nye krav til sider.

Sandheden er, at man i høj grad er afhængig af ‘trial and error’, når det kommer til SEO. Så det kan være lidt af en hovedpine, når man dertil tilføjer de udfordringer, som en SPA applikation bringer med sig.

Så hvad gør man egentlig, når man har brugt otte måneder på at udvikle en web-app med et SPA framework, som nægter at lade sig indeksere og ranke på Google?

Pinploy er en online-markedsplads (for praktisk hjælp omkring hjemmet mellem private), som kræver en stor volumen, og derfor er SEO meget vigtigt for os.

Illustration: snipcart.com

SEO-optimér din SPA med en pre-render service

Der er flere måder man kan SEO-forberede en SPA, herunder serverside rendering og prerendering. Serverside ringering skal implementeres i koden, hvor pre-rendering er en middleware, som man nemt kan benytte sig af som en service fra tredjeparts udbydere, som f.eks. Prerender.io.

Hos Pinploy valgte vi at benytte os af en pre-render service, da det efter alt at dømme er den mest sikre måde at få indekseret sin SPA - som det er tiltænkt. Ligeledes er det også langt mindre ressourcekrævende end at implementere server side rendering i sin SPA.

Prerendering er en måde at håndtere rendering logikken ‘pre-deployment’ (f.eks. inden siden bliver vist for Googlebot). Den diskriminerer mellem rigtige brugere og søge-crawlers og spiders.

Din SPA kører som en headless browser og genererer en ‘Googlebot-ready’, fuldt renderet HTML version af din app. Den version bliver gemt på din web server.

Når en forespørgsel (request) rammer den, så tjekker serveren, om det er en rigtig bruger (A) eller en Googlebot (B): A – leverer din SPA med det samme B – leverer de pre-renderede statiske filer.

Prerender.io er et populært værktøj til at gøre netop det med ethvert JS framework. Husk dog, at meget reaktive apps med konstant skiftende data ikke nødvendigvis spiller godt sammen med prerender. Prerender spiller godt med frameworks som React, Vue og Angular.

Det er utroligt nemt at bruge softwaren som tillader, at man enten uploader sine URL’er enkeltvis eller bare uploader hele sin sitemap. Derefter crawler Prerender dine sider og optimerer deres statiske filer med et interval, som du selv bestemmer.

Der findes utallige manualer til at implementere og bruge prerender på nettet, og vi kan personligt anbefale det.

På grafen nedenfor taget fra vores SearchConsole hos Pinploy, kan I se forskellen på vores SEO-resultater før og efter implementering af Prerender.

Så når I skal i gang med at bygge jeres næste SPA-app eller ikke kan forstå, hvorfor I ikke ranker på al jeres fantastiske content, så kan I overveje, om det måske kunne være på tide at SEO-klargøre jeres applikation.

Illustration: Google Seach console
Kommentarer (7)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Martin Dahl

Det var i stenalderen næsten samme teknik, man kunne benytte til at få indexeret et website bygget i Adobe Flash.

  • Byg et CMS i Flash, så alle de features, som HTML manglede, kunne administreres af redaktører.
  • Implementer et Flash frontend website, så alle de besøgende kunne få en oplevelse, som HTML ikke kunne levere dengang.
  • Render usynlige HTML elementer med indhold (tekst, billeder etc) fra CMS databasen på siden hvor Flash vises vises for de besøgende.
  • Implementer en strategi for URLer og navigation, så deling af links, menuer og deep linkning er transparent for både brugere og crawlere.

Såvidt jeg husker, så var Google dengang ikke glad for, at crawlere og besøgende fik serveret forskelligt indhold. Derfor adskilte vi ikke indholdet på webserver-niveau baseret på user agent.

  • 1
  • 0
#3 Saxo Merrild

Hej Dennis.

Da vi startede projektet var Angular Universal simpelthen ikke i god nok stand til at det gav mening ift. resourcer, derfor var prerender et oplagt valg da det på det tidspunkt gav marginalt bedre resultater, og kræver meget få resourcer.

Hvad er dit indrtyk af Angular Universal i dag (2 år senere), er det up to date og rendere på samme nivuea med f.eks. prerender.io ?

  • 0
  • 0
#5 Morten Hartvig

Det er netop det jeg selv gør på et nuværende + et kommende projekt:)

Havde ikke hørt om den prerender service før (da webpack har denne feature indbygget), samt da SSR også er en mulighed out of the box i f.eks. NEXT/NUXT:)

Dog er jeg lidt som skribenten i tvivl om load-impact på serveren, når man muligvis er tvunget til SSR grundet sidens størrelse og SEO hensyn.

Muligvis kommer der langt over 20k undersider på sigt på et af projekterne, og da vil prerender/statisk hosting nok blive for langsommeligt her ift. deployments? :)

  • 1
  • 0
Log ind eller Opret konto for at kommentere