SEO methods in SinglePage Applications
Or how to make your app
Google bot friendly
Вячеслав Потравный
Vyatcheslav Potravnyy

Front-End Team Lead at
http://bit.ly/seo-js
What is a problem?
How SPA works for user?
1. User opens http://blog.ru/index.html#/articles/1
2. Emtpy index.html loading with links on JS
3. User loads an App (all JavaScript code)
4. Router starting - here we know about #/articles/1
5. Models starting and downloads JSON’s
6. Views starting and renders templates
7. PROFIT! User see the content
How SPA works for Google bot?
1. Bot opens http://blog.ru/index.html#/articles/1
2. Emtpy index.html loading with links on JS
What is the solution?
What does Google advice?
1. Bot see URL .../index.html#!/articles/1
2. Bot knows it’s AJAX site, and does not use this URL.
It uses .../index.html?_escaped_fragment_=/articles/1
3. We handle this on server, and send rendered HTML
4. Bot associates this page with original URL
5. PROFFIT!
But if we have no hashbang?
1. Bot downloads page .../index.html
2. Bot sees <meta name="fragment" content="!">
3. Bot downloads .../index.html?_escaped_fragment_=
4. Server rendering
How to render App?
1. Write all on server framework
As webapps used to be written years ago.
2. Write content parts on server
framework (like Twitter)
+ Native solution

- Rewrite a lot

+ User gets content fast

- Duplicate code
- Complexity grows
- Only main content indexed
- No longer a frontend app
3. Run in browser and save HTML
+ Not a lot of work
+ Architecture independed
+ Bot gets the same page

- Slow and hard for server
Manually?! No. Headless browser
❏ HtmlUnit
❏ crawljax
❏ watij
❏ Phantom JS
How does this work?
1. Bot request .../index.html?_escaped_fragment_=/page
2. We filter this request to another route
3. We run headless browser with original URL
4. Let all requests be finished
5. Get final HTML from headless browser
6. Remove <scripts> from HTML
7. Response to Google bot
8. PROFIT!
What can be improved?
1. Rendering delay
a. Make on CRON and save on disk
b. Cache with nginx or Varnish
2. Loading detection
a. Wait for all requests
b. Flag on body
c. App event, handled on Node.js side
What about future?
Full-stack
(aka Isomorphic)
Benefits
1. Both server & client written in one language - JS
2. You can reuse generic code on server & clients
3. Server-side rendering for SEO & performance?
4. Simply create two-way API’s
Derby.js
1. SEO from the box
2. Huge localization abilities
3. Device adaptiveness abilities
4. Production-ready
5. Based on YUI
1. Almost Backbone
2. Very light and flexible
3. SEO from the box
4. Its framework, not a plug-in library
5. Too simple for huge apps
Meteor.js
1. Access to data from everywhere
2. 2-way API with Latency Compensation
3. Simple dive-in
4. Biggest community
5. Own packages instead of NPM
6. SEO through phantom.js
Atma.js
1. SEO from the box
2. Component ideology
3. Complex solution - lot of tools
4. No community yet
5. No documentation yet
Derby.js
1. SEO from the box
2. User gets HTML at very start
3. 2-way API and Realtime Collaboration
4. Most “smart”
5. Built on other open-source components
6. Hard to dive-in
7. Deps Redis & MongoDB
Questions?
Sources:
Google Specification
Backbone Tutorials
The Digital Self
Year of Moo
Derby.js

Vyatcheslav Potravnyy
Happy New Front-end!
by Geeks Lab

(January 18, 2014)

SEO methods in Single Page Applications

  • 1.
    SEO methods inSinglePage Applications Or how to make your app Google bot friendly
  • 2.
  • 3.
  • 4.
    What is aproblem?
  • 5.
    How SPA worksfor user? 1. User opens http://blog.ru/index.html#/articles/1 2. Emtpy index.html loading with links on JS 3. User loads an App (all JavaScript code) 4. Router starting - here we know about #/articles/1 5. Models starting and downloads JSON’s 6. Views starting and renders templates 7. PROFIT! User see the content
  • 6.
    How SPA worksfor Google bot? 1. Bot opens http://blog.ru/index.html#/articles/1 2. Emtpy index.html loading with links on JS
  • 7.
    What is thesolution?
  • 8.
    What does Googleadvice? 1. Bot see URL .../index.html#!/articles/1 2. Bot knows it’s AJAX site, and does not use this URL. It uses .../index.html?_escaped_fragment_=/articles/1 3. We handle this on server, and send rendered HTML 4. Bot associates this page with original URL 5. PROFFIT!
  • 9.
    But if wehave no hashbang? 1. Bot downloads page .../index.html 2. Bot sees <meta name="fragment" content="!"> 3. Bot downloads .../index.html?_escaped_fragment_= 4. Server rendering
  • 10.
  • 11.
    1. Write allon server framework As webapps used to be written years ago.
  • 12.
    2. Write contentparts on server framework (like Twitter) + Native solution - Rewrite a lot + User gets content fast - Duplicate code - Complexity grows - Only main content indexed - No longer a frontend app
  • 13.
    3. Run inbrowser and save HTML + Not a lot of work + Architecture independed + Bot gets the same page - Slow and hard for server
  • 14.
    Manually?! No. Headlessbrowser ❏ HtmlUnit ❏ crawljax ❏ watij ❏ Phantom JS
  • 15.
    How does thiswork? 1. Bot request .../index.html?_escaped_fragment_=/page 2. We filter this request to another route 3. We run headless browser with original URL 4. Let all requests be finished 5. Get final HTML from headless browser 6. Remove <scripts> from HTML 7. Response to Google bot 8. PROFIT!
  • 18.
    What can beimproved? 1. Rendering delay a. Make on CRON and save on disk b. Cache with nginx or Varnish 2. Loading detection a. Wait for all requests b. Flag on body c. App event, handled on Node.js side
  • 19.
  • 20.
    Benefits 1. Both server& client written in one language - JS 2. You can reuse generic code on server & clients 3. Server-side rendering for SEO & performance? 4. Simply create two-way API’s
  • 21.
  • 22.
    1. SEO fromthe box 2. Huge localization abilities 3. Device adaptiveness abilities 4. Production-ready 5. Based on YUI
  • 23.
    1. Almost Backbone 2.Very light and flexible 3. SEO from the box 4. Its framework, not a plug-in library 5. Too simple for huge apps
  • 24.
    Meteor.js 1. Access todata from everywhere 2. 2-way API with Latency Compensation 3. Simple dive-in 4. Biggest community 5. Own packages instead of NPM 6. SEO through phantom.js
  • 25.
    Atma.js 1. SEO fromthe box 2. Component ideology 3. Complex solution - lot of tools 4. No community yet 5. No documentation yet
  • 26.
    Derby.js 1. SEO fromthe box 2. User gets HTML at very start 3. 2-way API and Realtime Collaboration 4. Most “smart” 5. Built on other open-source components 6. Hard to dive-in 7. Deps Redis & MongoDB
  • 27.
    Questions? Sources: Google Specification Backbone Tutorials TheDigital Self Year of Moo Derby.js Vyatcheslav Potravnyy Happy New Front-end! by Geeks Lab (January 18, 2014)