Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SEO in JavaScript Web Apps

blog.alexmaccaw.com

Post reply on HN
Print view View original

21–30 of 53 posts

Re: SEO in JavaScript Web Apps

#21

Post by blauwbilgorgel »

JohnTHaller wrote: post #13
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…

Honestly, with every worthwhile browser (both desktop and mobile) supporting JavaScript and having it enabled by default, it doesn't make much sense to support browsers with it disabled. The couple million people with NoScript installed who enable it only on specific sites know to enable it if a site doesn't work.

It does make sense to me, because:

- Not all search engines can handle JavaScript, Google is leading the way, but not perfect.

- Those NoScript users could be potential clients or users of your site. I love it when my conversation rate goes up 1%, and that becomes harder when you ignore 1-5% of users.

- Screenreaders generally do not support JavaScript [not true, see comment]. If only one blind user gets to access the content/design I created, then that is worth it to me. I am thinking as front-end engineer here, not as a business owner, where time is money. (Also depending on jurisdiction it may be against the law to be inaccessible).

- Noscript users will likely bounce in large numbers when seeing just a blank page. Simply adding a tag, explaining why you need JavaScript goes a long way.

As a front-end engineer I go for maximum content accessibility. I don't meddle into the politics of things ("If we don't drop IE6 support, the web won't move forward!").

I totally understand the new landscape, where a lot of people have JavaScript on. Some web apps can not use progressive enhancement, because the JavaScript is core to the app. But for "static" content websites like these, it is certainly possible to make a website that is usable by most users, human and robot.

Re: SEO in JavaScript Web Apps

#23

Post by Isofarro »

blauwbilgorgel wrote: post #21
JohnTHaller wrote: post #13

Earlier quoted context omitted.

Honestly, with every worthwhile browser (both desktop and mobile) supporting JavaScript and having it enabled by default, it doesn't make much sense to support browsers with it disabled. The couple million people with NoScript installed who enable it only on specific sites know to enable it if a site doesn't work.

It does make sense to me, because: - Not all search engines can handle JavaScript, Google is leading the way, but not perfect. - Those NoScript users could be potential clients or users of your site. I love it when my conversation rate goes up 1%, and that becomes harder when you ignore 1-5% of users. - Screenreaders generally do not support JavaScript [not true, see comment]. If only one blind user gets to access th…

"Screenreaders in generally do not support JavaScript."

Please stop saying that. It hasn't been true for a good 5 years or so.

* http://www.brucelawson.co.uk/2011/javascript-and-screenreade...

* http://webaim.org/projects/screenreadersurvey4/#javascript

* http://www.w3.org/TR/WCAG20-TECHS/client-side-script.html

Re: SEO in JavaScript Web Apps

#24

Post by blauwbilgorgel »

maccman wrote: post #10
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 c…

>why do you think it's useful for users to read meta descriptions?

It isn't, really. I made a mistake and thought that every page (served to users and search engines) had the same title and description. A user is unlikely to read a meta description, unless he/she is on a search results page.

>How does making this a pure JavaScript web app degrade the end-user's experience?

NoScript users and special need users are unable to access your website's content.

> JS and client-side rendering makes for a much better experience.

Agreed. Progressive enhancement makes this possible and get the best of both worlds: Accessible content for NoScript users, spiffy JS rendering one page app for JavaScript users. RMS can even download your pages through Lynx.

If you go pure JavaScript, you can at least add a where you explain why you need JavaScript to enjoy this site.

Re: SEO in JavaScript Web Apps

#25

Post by blauwbilgorgel »

Isofarro wrote: post #23
blauwbilgorgel wrote: post #21

Earlier quoted context omitted.

It does make sense to me, because: - Not all search engines can handle JavaScript, Google is leading the way, but not perfect. - Those NoScript users could be potential clients or users of your site. I love it when my conversation rate goes up 1%, and that becomes harder when you ignore 1-5% of users. - Screenreaders generally do not support JavaScript [not true, see comment]. If only one blind user gets to access th…

"Screenreaders in generally do not support JavaScript." Please stop saying that. It hasn't been true for a good 5 years or so. * http://www.brucelawson.co.uk/2011/javascript-and-screenreade... * http://webaim.org/projects/screenreadersurvey4/#javascript * http://www.w3.org/TR/WCAG20-TECHS/client-side-script.html

Thank you! I've been behind the times. I'll start viewing it as a general accessibility issue, not specific to screen readers. But like Steve Klabnik commented, and from http://www.w3.org/WAI/intro/aria.php , there are a few more steps to take to make JavaScript enabled screen readers play nice:

"WAI-ARIA addresses these accessibility challenges by defining how information about this functionality can be provided to assistive technology. With WAI-ARIA, an advanced Web application can be made accessible and usable to people with disabilities."

Re: SEO in JavaScript Web Apps

#26

Post by steveklabnik »

blauwbilgorgel wrote: post #21
JohnTHaller wrote: post #13

Earlier quoted context omitted.

Honestly, with every worthwhile browser (both desktop and mobile) supporting JavaScript and having it enabled by default, it doesn't make much sense to support browsers with it disabled. The couple million people with NoScript installed who enable it only on specific sites know to enable it if a site doesn't work.

It does make sense to me, because: - Not all search engines can handle JavaScript, Google is leading the way, but not perfect. - Those NoScript users could be potential clients or users of your site. I love it when my conversation rate goes up 1%, and that becomes harder when you ignore 1-5% of users. - Screenreaders generally do not support JavaScript [not true, see comment]. If only one blind user gets to access th…

While I'm not going to say that all screen readers don't support JS, in many cases they can: http://words.steveklabnik.com/emberjs-and-accessibility

Re: SEO in JavaScript Web Apps

#27

Post by asdasf »

JohnTHaller wrote: post #13
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…

Honestly, with every worthwhile browser (both desktop and mobile) supporting JavaScript and having it enabled by default, it doesn't make much sense to support browsers with it disabled. The couple million people with NoScript installed who enable it only on specific sites know to enable it if a site doesn't work.

>it doesn't make much sense to support browsers with it disabled

But that is exactly what you are doing anyways, you are just limiting it to googlebot for no reason.

Re: SEO in JavaScript Web Apps

#28

Post by franze »

i will save you a lot of pain: just don't do it. the __escaped_fragment__ is the most idiotic recommendation google has ever given. basically you have to render two views, the user JS view and a server side rendered basic HTML __escaped_fragment__ view. oh yeah, the __escaped_fragment__ view will never be visited by your users and not by yourself - just by googlebot.

and now guess: what view will be less maintained, not up to date and regularly broken?

why? when there is no direct feedback, there is no direct feedback.

if you want to do SEO and as well go down the "but it's faster with JS" road just do "progressive enhancement" and history.pushState. the __escaped_fragment__ spec is a leftover from the ajaxy web2.0 times, and even then it was a bad idea.

Re: SEO in JavaScript Web Apps

#29

Post by nkuttler »

Isofarro wrote: post #18
JohnTHaller wrote: post #13

Earlier quoted context omitted.

Honestly, with every worthwhile browser (both desktop and mobile) supporting JavaScript and having it enabled by default, it doesn't make much sense to support browsers with it disabled. The couple million people with NoScript installed who enable it only on specific sites know to enable it if a site doesn't work.

It's not a question of having JavaScript enabled/disabled. It's a question of whether the JavaScript gets delivered from your server to the client's browser properly and fully in a state that it can be executed successfully. Progressive enhancement is about robustness, being adaptable when the network fails to be perfect. Look at it this way, this __escaped_fragment__ is only supported by Google. No other search engi…

At least Bing supports the hash fragment as well, but it looks like you have to enable it manually http://www.bing.com/blogs/webmaster/f/12248/p/671232/9669509...

Re: SEO in JavaScript Web Apps

#30

Post by steveklabnik »

Isofarro wrote: post #23
blauwbilgorgel wrote: post #21

Earlier quoted context omitted.

It does make sense to me, because: - Not all search engines can handle JavaScript, Google is leading the way, but not perfect. - Those NoScript users could be potential clients or users of your site. I love it when my conversation rate goes up 1%, and that becomes harder when you ignore 1-5% of users. - Screenreaders generally do not support JavaScript [not true, see comment]. If only one blind user gets to access th…

"Screenreaders in generally do not support JavaScript." Please stop saying that. It hasn't been true for a good 5 years or so. * http://www.brucelawson.co.uk/2011/javascript-and-screenreade... * http://webaim.org/projects/screenreadersurvey4/#javascript * http://www.w3.org/TR/WCAG20-TECHS/client-side-script.html

Thank you, now I have more things to point people at than just my blog post.
Post reply on HN