Allt eftersom JavaScript blir allt mer integrerat med HTML på webben måste SEO:are utveckla en förståelse för hur man gör JavaScript-webbplatser sökbara.
Vi täckte några grundläggande SEO-metoder för JavaScript i ett tidigare inlägg. Ett komplext ämne förtjänar dock en djupgående behandling. Så låt oss ta en titt på detaljerna bakom popupen #! /snapshot-metod för JavaScript-webbplatser.
Behöver du ens göra detta?
Sökmotorer bearbetar mer och mer JavaScript varje dag. Det betyder dock inte att din AngularJS-webbplats kommer att indexeras och rankas. Motorerna analyserar nu en del JavaScript, men fullständig indexering av alla JavaScript-webbapplikationstillstånd verkar långt borta. Om ditt JavaScript körs i webbläsaren och hämtar innehåll från databasen, kommer motorerna förmodligen inte att se det.
Förrendering av en ögonblicksbild av sidan och botspecifik publicering
Detta är kanske den mest populära metoden för JavaScript SEO-problem på klientsidan. Grundflödet är som följer:
- Upptäck sökmotorrobotar antingen genom att titta på URL:en om du använde #! (“hashbang”) eller helt enkelt kontrollera användaragenten för begäran.
- Om boten upptäcks, omdirigera begäran till den renderingsmotor du väljer, till exempel PhantomJS. Denna motor måste vänta tills allt AJAX-innehåll har laddats.
- När den har laddats, ta den renderade sidkällan och skicka den till boten.
Ironiskt nog är detta en form av cloaking: att skicka specifikt innehåll till bots, ofta ett nej i SEO. Denna typ av cloaking anses dock vara “etisk” eftersom innehållet är praktiskt taget detsamma som användarna skulle se. Därför är sökmotorer okej med det.
Google har en komplett AJAX-krypningsspecifikation som täcker de praktiska aspekterna. Grundtanken är att man lägger till #! identifierare för dina webbadresser eller inkludera HTML-koden [meta name=”fragment” content=”!”] tagga till sidhuvudet. Detta varnar Google om att sidan använder URL-fragment och får dem att indexera sidan.
Som jag nämnde i mitt tidigare inlägg är History.pushState ett annat alternativ för att skapa indexerbara AJAX-webbadresser. PushState har problem, bland annat att det inte stöds i IE 9, som fortfarande är en ganska utbredd webbläsare.
Potentiella problem med förrendering
Det finns ett par saker att tänka på om du bestämmer dig för förrendering:
- Botdetektering. Se till att du betjänar alla bots, inte bara Googlebot (dvs. Bingbot, et al).
- Timing för ögonblicksbilder. Tänk på att dina JavaScript-element kan ta ett tag att rendera genom PhantomJS. Du kan behöva skapa en fördröjning för att tillåta allt innehåll att laddas innan sidan cachelagras. Annars kan din ögonblicksbildsida vara ofullständig eller delvis återgiven.
- Sidans laddningstid. På liknande sätt, om du kör processen för ögonblicksbildsidan vid tidpunkten för botens URL-begäran, kan sidan laddas långsamt. Sidans laddningshastighet är en allt viktigare SEO-rankningsfaktor, så om din sida ser ut att laddas långsamt för boten kan du påverkas negativt. Det är därför det är önskvärt att cache sidor i förväg. Detta har den extra fördelen att din webbplats ser snabbare ut för motorer än för användare.
- Satsvis bearbetning. Om du har många sidor kanske du vill köra ögonblicksbildsprocessen vid en viss tidpunkt utanför kontorstid eller på din egen server. Processen kan vara resurskrävande.
Kontrollerar ögonblicksbildsidor
Eftersom du använder botdetektering är det svårare att verifiera att din process faktiskt fungerar. Ett sätt att verifiera ditt arbete är att använda funktionen “Sök som Google” i Googles verktyg för webbansvariga. Ange webbadressen till en ögonblicksbildsida (den kan skilja sig från den live-URL som visas för användare) i GWT och kontrollera om Google kan hämta den korrekt. Detta kräver en livesida, så planera därefter.
För närvarande stöder Utforska som Google #! men inte URL pushState. Om dina webbadresser ser statiska ut kommer du inte ha några problem.
Förrepresentationstjänster
Att bygga en komplett förrenderingskapacitet kanske inte är trivialt. För en större webbplats kan det handla om att sätta upp en cachningsserver, en databas för innehåll, en tjänst för cachning av samtal, en schemaläggare och ett administrativt verktyg. Lyckligtvis har flera företag kommit med lösningar för att ta itu med delar av eller hela pre-rendering-metoden. Flera som jag är bekant med inkluderar:
- Prerender.io. Prerender.io kör en tjänst som drivs av PhantomJS för att vara värd för och servera ögonblicksbildsidor. De eliminerar huvudvärken med att köra din egen förrenderingsserver. De är rimligt prissatta baserat på antalet sidor som är värd och hur ofta ögonblicksbilder tas.
- Brombone.com. Brombone kör en liknande tjänst där ögonblicksbildsidor kan genereras baserat på tidsstämpeln för webbadressen i webbplatskartan eller kan anpassas schemalagda.
- Ajax ögonblicksbilder. AjaxSnapshots erbjuder en förrenderingstjänst med några bra konfigurationsalternativ. För tillfället listar deras hemsida priset som gratis (åtminstone för nu), så det finns det.
Betald sökning och målsidor
JavaScript-sajter har utmaningar med såväl betald sökning som SEO. Till exempel bestämmer AdWords kvalitetsresultatet baserat på bland annat innehållet som AdWords-boten ser på sidan. En metod är att visa ögonblicksbildsidan för Google AdsBot (en fullständig lista över Googles sökrobotar och användaragenter finns här).
Om dina produkter eller produktinnehåll finns i en ensidig app kan det dessutom vara svårt att tvinga fram detta tillstånd via destinationsadressen för betald sökning. Skapar #! Eller statiska webbadresser är praktiskt taget ett krav här.
Eftersom betalda sökningsmålsidor ofta måste vara mycket personliga för att konvertera bra, kan det i det långa loppet vara bättre att skapa dedikerade sidor för dina PPC-kampanjer, vilket överlåter din grundläggande JavaScript-webbupplevelse till användare och SEO.
Slutsats
JavaScript-tunga sajter är här för att stanna. Även om det kanske inte är trivialt att skapa en JavaScript-sajt som fungerar bra inom SEO, är det ännu mer jobb att försöka fixa en befintlig sajt som skapades utan SEO i åtanke. Tills ramverk och verktyg har förbättrats för att göra det enklare att införliva SEO-krav måste SEO:are arbeta nära utvecklare för att se till att SEO beaktas. Att få SEO och JavaScript att leva i harmoni kanske inte är lätt, men det är värt det.
Tack till Vladimir Katz, Senior Engineer på Huge, för att du bidragit till det här inlägget.
Hemsidesbild via Flickr.
