SEO in JavaScript Web Apps

#1

Post by maccman » Mon, Jul 22, 2013, 6:26 PM UTC

SEO in JavaScript Web Apps
blog.alexmaccaw.com

Re: SEO in JavaScript Web Apps

#2

Post by blauwbilgorgel » Mon, Jul 22, 2013, 6:52 PM UTC

Another option is to make a website that works without JavaScript. Only dynamically fetch pages when JavaScript is enabled. Progressive enhancement rocks.

Visiting http://monocle.io/posts/how-yield-will-transform-node without JavaScript support yields a blank page.

All page titles are Monocle which isn't very descriptive and the meta description is the same for every page. Only with escaped_fragment can a user see descriptive page titles. For JavaScript users all pages are titled "Monocle".

There are no unique content articles to rank nr. 1 for. The articles are all found on other sites. I don't really see Monocle rank 2 a lot (a quick glance). Those are reserved for other aggregating sites.

The Google guidelines say:

  Make pages primarily for users, not for search engines.
  "Does this help my users? Would I do this if search 
  engines didn't exist?"

I'd extend that to JavaScript apps. Why make escaped_fragment especially for search engines, and then forget to offer this functionality for human users too?

Re: SEO in JavaScript Web Apps

#3

Post by nkuttler » Mon, Jul 22, 2013, 6:53 PM UTC

I find it a little odd that this article focuses on the hash fragment approach and only mentions the HTML5 pushState in passing, and how to avoid it. There are a few scenarios where the hash fragment is more useful (states that don't map well to URLs), but pushState has the huge benefit of looking natural AND working in non-JS browsers in general.

I think it would be good to mention Sinatra in the title.

Re: SEO in JavaScript Web Apps

#4

Post by geetee » Mon, Jul 22, 2013, 6:54 PM UTC

Does it matter that the JS-constructed HTML does not look anything like the spider-friendly version?

We're about to deploy an AngularJS application that is using PhantomJS to generate the spider-friendly content on the server. I'd much prefer to do this simpler method if it works just as well.

Re: SEO in JavaScript Web Apps

#5

Post by Isofarro » Mon, Jul 22, 2013, 6:55 PM UTC

So he starts with a JavaScript only application, then retrofits in a progressive enhancement layer in a Google-specified query string parameter.

He could just as easily done the core experience first with HTML, got a URL structure that is friendlier and RESTful, and then enhanced it with the JavaScript enhancement he needs to turn it into a perception of a one page website.

The bonus of doing it this way is clean URLs for each piece of indexable content.

Because, really, what's the advantage of http://example.com/?_escaped_fragment_=about-us over http://example.com/about-us ?

Re: SEO in JavaScript Web Apps

#6

Post by maccman » Mon, Jul 22, 2013, 6:56 PM UTC

nkuttler wrote: post #3

I find it a little odd that this article focuses on the hash fragment approach and only mentions the HTML5 pushState in passing, and how to avoid it. There are a few scenarios where the hash fragment is more useful (states that don't map well to URLs), but pushState has the huge benefit of looking natural AND working in non-JS browsers in general. I think it would be good to mention Sinatra in the title.

I focus on pushState throughout the article. Unfortunately, to spider a website that uses pushState you have to use a Google spec that was originally designed for the hash fragment.

Re: SEO in JavaScript Web Apps

#7

Post by maccman » Mon, Jul 22, 2013, 7:00 PM UTC

geetee wrote: post #4

Does it matter that the JS-constructed HTML does not look anything like the spider-friendly version? We're about to deploy an AngularJS application that is using PhantomJS to generate the spider-friendly content on the server. I'd much prefer to do this simpler method if it works just as well.

Google's spiders prefer you not to try and 'detect' them and serve different content up to them. However, afaik they're fine with this technique (I mean, they even provide a spec to do so). See their content guidelines on 'Hidden text and links' [1]

> However, not all hidden text is considered deceptive. For example, if your site includes technologies that search engines have difficulty accessing, like JavaScript...

[1] - https://support.google.com/webmasters/answer/66353?hl=en

Re: SEO in JavaScript Web Apps

#8

Post by nkuttler » Mon, Jul 22, 2013, 7:04 PM UTC

maccman wrote: post #6

nkuttler wrote: post #3

I find it a little odd that this article focuses on the hash fragment approach and only mentions the HTML5 pushState in passing, and how to avoid it. There are a few scenarios where the hash fragment is more useful (states that don't map well to URLs), but pushState has the huge benefit of looking natural AND working in non-JS browsers in general. I think it would be good to mention Sinatra in the title.

I focus on pushState throughout the article. Unfortunately, to spider a website that uses pushState you have to use a Google spec that was originally designed for the hash fragment.

No, that's wrong. You just use links to /the/normal/looking/URL and let the browser use JS instead when it can. And obviously you serve the real content at /the/normal/looking/URL instead of behind the obscure hash fragment method.

Re: SEO in JavaScript Web Apps

#9

Post by chaddeshon » Mon, Jul 22, 2013, 7:15 PM UTC

I made a web service that will do javascript SEO for you. Check it out at BromBone.com.

We render your entire page for you a save it has html on a CDN. Then you can just do the simple routing described in this article, but send Google the page from our CDN instead. That way Google sees the exact same thing as your users, but you don't have to code it again.

Re: SEO in JavaScript Web Apps

#10

Post by maccman » Mon, Jul 22, 2013, 7:23 PM UTC

blauwbilgorgel wrote: post #2

Another option is to make a website that works without JavaScript. Only dynamically fetch pages when JavaScript is enabled. Progressive enhancement rocks. Visiting http://monocle.io/posts/how-yield-will-transform-node without JavaScript support yields a blank page. All page titles are Monocle which isn't very descriptive and the meta description is the same for every page. Only with escaped_fragment can a user see de…

Hey, thanks for taking the time to comment.

I certainly could make the titles more useful, in fact due to you suggestion I've just committed a fix to that.

I'm interested though, why do you think it's useful for users to read meta descriptions? Or the raw text used by spiders?

How does making this a pure JavaScript web app degrade the end-user's experience? I think I can effectively argue the opposite - that JS and client-side rendering makes for a much better experience.